Bug#1069904: Autopkgtests failed

[Elena ``of Valhalla'']

On 2024-05-21 at 17:18:59 +0200, Jochen Sprickerhof wrote:
> I have opened a MR to fix this:

Thanks!

I really hope to be able to look into this in the next few days

-- 
Elena ``of Valhalla''

Bug#1071561: python-gnupg: DPT as package maintainer?

[Elena ``of Valhalla'']

On 2024-05-21 at 11:39:25 +0200, Timo Röhling wrote:
> I noticed that your package uses the so-called "weak team maintainer" model, 
> [...]
> Is this a deliberate decision or merely an artifact of some packaging helper 
> tool [...]

Thanks for looking into this.

It is a deliberate decision: this package is somewhat quirky and in
the past I've had to say no to suggestions that would have fixed some
issue, but caused problems elsewhere, so I'd prefer to keep the weak
team maintainer model (as long as it is in a wide-scope team).

Of course the typical team-wide changes are much welcome, but those
usually don't trigger a new upload.

This should be the only package I maintain that uses the weak team
maintainer model, all of the other ones should be already using the team
as the Maintainer (if they don't, *that* is an artifact of something,
and if I'll notice it I'll fix it)

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#1070813: src:camelot-py: fails to migrate to testing for too long: autopkgtest failure on ppc64el

[Elena ``of Valhalla'']

Thanks for the hint on the *right* way to deal with this, it was really
helpful
-- 
Elena ``of Valhalla''

Bug#1066646: Proposed patch

[Elena ``of Valhalla'']

The attached patch should re-enable looking just for image files on all
partitions; it does work on our usecase (but I don't know live-boot well
enough to test for every other one).

Thanks in advance,
-- 
Elena ``of Valhalla''
From 4873cd2e22a2107836d442ed9d98edb5a5325182 Mon Sep 17 00:00:00 2001
From: Elena  Grandi 
Date: Thu, 28 Mar 2024 10:35:07 +0100
Subject: [PATCH] Look for persistence files also on blacklisted devices

---
 components/9990-misc-helpers.sh | 42 -
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/components/9990-misc-helpers.sh b/components/9990-misc-helpers.sh
index 122014f..cac5e96 100755
--- a/components/9990-misc-helpers.sh
+++ b/components/9990-misc-helpers.sh
@@ -1104,6 +1104,31 @@ find_persistence_media ()
 			fi
 		fi
 
+		# Probe for directory with matching name on mounted partition
+		if is_in_comma_sep_list directory ${PERSISTENCE_STORAGE}
+		then
+			result=$(probe_for_directory_name "${overlays}" ${dev})
+			if [ -n "${result}" ]
+			then
+ret="${ret} ${result}"
+continue
+			fi
+		fi
+
+		# Close luks device if it isn't used
+		if [ -z "${result}" ] && [ -n "${luks_device}" ] && is_active_luks_mapping "${luks_device}"
+		then
+			cryptsetup luksClose "${luks_device}"
+		fi
+	done
+
+# It is however fine to look for persistence *files* on the black
+# listed partitions.
+	for dev in $(storage_devices "" "")
+	do
+		local result luks_device
+		result=""
+
 		# Probe for files with matching name on mounted partition
 		if is_in_comma_sep_list file ${PERSISTENCE_STORAGE}
 		then
@@ -1136,23 +1161,6 @@ find_persistence_media ()
 continue
 			fi
 		fi
-
-		# Probe for directory with matching name on mounted partition
-		if is_in_comma_sep_list directory ${PERSISTENCE_STORAGE}
-		then
-			result=$(probe_for_directory_name "${overlays}" ${dev})
-			if [ -n "${result}" ]
-			then
-ret="${ret} ${result}"
-continue
-			fi
-		fi
-
-		# Close luks device if it isn't used
-		if [ -z "${result}" ] && [ -n "${luks_device}" ] && is_active_luks_mapping "${luks_device}"
-		then
-			cryptsetup luksClose "${luks_device}"
-		fi
 	done
 
 	if [ -n "${ret}" ]
-- 
2.43.0



signature.asc
Description: PGP signature

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

[Elena ``of Valhalla'']

Thanks for the patch!

I see that the patch is marked as 

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

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


signature.asc
Description: PGP signature

Bug#1061181: python-gnupg: please package a new version to allow django-dbbackup update

[Elena ``of Valhalla'']

Thanks for reminding me that I should bump up the priority of this in my
TODO list :)
-- 
Elena ``of Valhalla''

Bug#1055224: ITP: endesive

[Elena ``of Valhalla'']

Thanks for working on this.

I'm packaging fpdf2, which can optionally use this to manage signatures,
and I'm looking forwards to have endesive in debian and being able to
add it to the recommends of fpdf2.
-- 
Elena ``of Valhalla''

Bug#1050005: ITP: pdftopng -- Convert PDF to PNG

[Elena ``of Valhalla'']

You're right, I thought I remembered this to be just a python wrapper
around pdftoppm, so I didn't see a reason to patch camelot-py to avoid
this package, but I've now looked at it in more detail and realized that
it would probably have to be patched to use the original pdftoppm rather
than their own patched version, so there is no real point to this.

And for some reason, camelot-py is using it through subprocess rather
than using the python library, so I hope that maintaining the patches
isn't going to be too problematic .
-- 
Elena ``of Valhalla''

Bug#882374: ITP: python-fpdf2

[Elena ``of Valhalla'']

After talking with Ondrej Tuma in private we've agreed that I will
package this under the Python Team.

Some work has already been started, at:

https://salsa.debian.org/python-team/packages/fpdf2
-- 
Elena ``of Valhalla''

Bug#882374: ITP: python-fpdf2

[Elena ``of Valhalla'']

Hello

Are you still interested in packaging this?

I see that this bug has not been renamed RFP, but there have been no
updates since 2017, and I would be interested in packaging this myself
(under the Python Team)

I've checked on salsa and I saw no repository: has any work already been
done?
-- 
Elena ``of Valhalla''

Bug#1038452: bepasty: 500 Internal Server Error when displaying text

[Elena ``of Valhalla'']

This is caused by an incompability with Pygments-2.12.0 that has been
fixed upstream in version 1.1.0.
-- 
Elena ``of Valhalla''

Bug#1020947: ITP: confusable-homoglyphs -- Detect confusable usage of unicode homoglyphs

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla'' 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: confusable-homoglyphs
  Version : 3.2.0
  Upstream Author : Victor Felder 
* URL : https://github.com/vhf/confusable_homoglyphs
* License : MIT
  Programming Lang: Python
  Description : Detect confusable usage of unicode homoglyphs

a homoglyph is one of two or more graphemes, characters, or glyphs with
shapes that appear identical or very similar
.
This python library helps detect cases where Unicode homoglyphs can be used
for malicious purposes.

This is a dependency for python-django-registration and I intend to
maintain this under the python team.

Bug#1020496: games-finest: Please add a selection of minetest mods

[Elena ``of Valhalla'']

Package: games-finest
Severity: wishlist

Dear Maintainer,

the metapackage installs just the bare the package minetest with the
bare game; for the best enjoyment however a selection of mods is
required: could you please add them to the metapackage?

alternatively, the minetest source package could build a metapackage
like “minetest-mods-finest”, and that could be installed by
games-finest.

As for the selection of which mods to include, I defer to the choice of
the maintainer (I see as a start that minetest Suggests
minetest-mod-moreblocks, minetest-mod-moreores, minetest-mod-pipeworks,
minetest-server, minetestmapper; personally I tend to add a few more)

thanks

Bug#1009759: RFP: web-archives -- Reader for ZIM files (offline dumps of websites like wikipedia)

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist

* Package name: web-archives
  Version : 0.4.1
  Upstream Author : Birros 
* URL : https://github.com/birros/web-archives
* License : GPLv3
  Programming Lang: Vala
  Description : Offline reader for ZIM files 

Web Archives is an offline reader for dumps of online contents like
Wikipedia, Wikisource etc., suitable both for desktop and mobile form
factors.

I've found the app on
https://linuxphoneapps.org/apps/com.github.birros.webarchives/ (which is
where I take the “suitable for mobile” data from).

While Debian already has kiwix, on mobile (modian / pinephone) it has
some UI issues, so it would be nice to have another option.

Also, having an alternative ZIM reader (as opposed to both 0 and 10) is
useful to get a hint whether some issue in certain ZIM files come from
the file itself or a bug in the reader.

Bug#1009623: ITP: python-hazwaz -- a python3 library to write command line scripts.

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla'' 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-hazwaz
  Version : 0.0.1
  Upstream Author : Elena ``of Valhalla'' Grandi 
* URL : https://sr.ht/~valhalla/hazwaz/
* License : AGPLv3+
  Programming Lang: Python
  Description : a python3 library to write command line scripts.

This library helps reducing the copypasted boilerplate code used to
write argparse based command line programs, substituting it with tested
code that includes testing helpers.

This will become a dependency of the next version of lesana, and I will
maintain it together with it in the Python Team.

Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1

[Elena ``of Valhalla'']

On 2022-02-28 at 15:31:58 -0500, nick black wrote:
> agreed, so long as it's not required by most outputs (i.e. you
> can run pypandoc without it and it works).

Latex is only used for pdf output, and even there it's just the default
option, but there is support for other engines as well.

If that wasn't the case, I agree that it should be a dependency, but it
should be a dependency of pandoc rather than pypandoc.

The issue here is that the tests of pypandoc do try to generate a pdf
(as it is a pretty common usecase), and thus they do need latex
installed, but that's only a requirement for the tests.

> alrightie. this was my NM application bug; i guess i will find
> another one. have a good day!

I'm even more sorry about having wasted your time then :(

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1

[Elena ``of Valhalla'']

On 2022-02-28 at 10:20:10 -0500, nick black wrote:
> lmodern needed be listed as a regular Depends, not just a
> Build-Depends, in order for the autopkgtests to successfully
> run. I have added it, and verified that this fixes the
> autopkgtests on the testing distribution.

Thanks for working on it!

However, I don't think that adding lmodern to the package Depends is the
right solution, as that would lead to parts of tex (admittely, a small
part, but still) having to be installed on the system, which is not
required by pandoc itself.

The right solution, I believe, is to add lmodern to the tests/control
Depends, and I've just realized that I prepared that in git, but I never
actually did the upload (ups), and was wondering why it wasn't
working.

I will do the upload myself in the next few days, since I have an
up-to-date copy of the repo locally (and salsa is down).

sorry.

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

[Elena ``of Valhalla'' Grandi]

On 2021-09-06 at 22:58:54 +0200, Diederik de Haas wrote:
> I wanted to print the Debian Social Contract, which turned out to be WAY
> more difficult then I expected and then it should be.
> [...]
> Then I went looking for a PDF version and didn't find anything.

There is a PDF version in the Debian Flyers website:
https://debian.pages.debian.net/debian-flyers/

only English, French and Italian are currently available, but the
sources used to generate that PDF are on
https://salsa.debian.org/debian/debian-flyers

would this be useful?

(I agree that making this easier to discover would be a good idea)

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#991701: unblock: python-a38/0.1.3-2

[Elena ``of Valhalla'']

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-a38

[ Reason ]
The attached debdiff provides a fix for bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991648 , a test suite
failure caused by an expired certificate that causes an FTBFS.

Upstream fixed this by updating the certificate used by the tests, but
as in this context a certificate with no expiration wouldn't work they
also added code to let the tests be skipped when even that certificate
expires.

Since backporting that patch resulted in an unwieldy debdiff, I opted to
just skip the affected tests in the resulting package.

Both upstream and me are sure that this is purely a broken test issue,
and not a hint of a problem in the code.

[ Tests ]
[ Risks ]
The change only affects the unit tests of the package, and won't change
the behaviour of the library.

The only risk I can see is that this would make the automated tests less
effective at detecting potential future breakage, but I'd expect that to
happen in testing rather than stable, and I intend to upload a version
that re-enables the tests (by using the upstream fix) as soon as
development for bookworm starts.

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

[ Other info ]
thanks in advance

unblock python-a38/0.1.3-2
diff -Nru python-a38-0.1.3/debian/changelog python-a38-0.1.3/debian/changelog
--- python-a38-0.1.3/debian/changelog   2020-12-18 11:44:31.0 +0100
+++ python-a38-0.1.3/debian/changelog   2021-07-30 12:01:58.0 +0200
@@ -1,3 +1,9 @@
+python-a38 (0.1.3-2) unstable; urgency=medium
+
+  * Skip tests that fail because of an expired certificate. (Closes: #991648)
+
+ -- Elena Grandi   Fri, 30 Jul 2021 12:01:58 +0200
+
 python-a38 (0.1.3-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru 
python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
 
python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
--- 
python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
 1970-01-01 01:00:00.0 +0100
+++ 
python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
 2021-07-30 12:01:58.0 +0200
@@ -0,0 +1,30 @@
+From: Elena Grandi 
+Date: Fri, 30 Jul 2021 12:00:27 +0200
+Forwarded: not-needed
+Subject: Skip tests that fail because of an expired certificate.
+
+---
+ tests/test_p7m.py | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/tests/test_p7m.py b/tests/test_p7m.py
+index e955bd4..fe982e7 100644
+--- a/tests/test_p7m.py
 b/tests/test_p7m.py
+@@ -1,4 +1,4 @@
+-from unittest import TestCase
++from unittest import TestCase, skip
+ import tempfile
+ from contextlib import contextmanager
+ import os
+@@ -39,7 +39,9 @@ WGPH+t5X7ZMMERXn8Z/2LTYWuj9w1+WeieY=
+ 
+ CA_CERT_HASH = "af603d58.0"
+ 
+-
++# The following tests are failing because of an expired certificate, and
++# a certificate with no expiration wouldn't work in this context.
++@skip("certificate expired")
+ class TestAnagrafica(TestCase):
+ @contextmanager
+ def capath(self):
diff -Nru python-a38-0.1.3/debian/patches/series 
python-a38-0.1.3/debian/patches/series
--- python-a38-0.1.3/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ python-a38-0.1.3/debian/patches/series  2021-07-30 12:01:58.0 
+0200
@@ -0,0 +1 @@
+0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch

Bug#988122: RFP: python3-blinka -- CircuitPython API for devices running CPython

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist

* Package name: python3-blinka
  Version : 6.6.2
  Upstream Author : Adafruit Industries 
* URL : https://github.com/adafruit/Adafruit_Blinka
* License : MIT
  Programming Lang: Python
  Description : CircuitPython API for devices running CPython

blinka provides code to emulate the main CircuitPython packages on
supported Single Board Computers such as the Raspberry Pi.

A list of supported boards is at 
https://github.com/adafruit/Adafruit_Blinka/tree/master/src/adafruit_blinka/board

This provides a beginner-friendly environment to program the GPIO pins
available on such boards.

I think this package can fall under the scope of the Python Team.

Bug#985462: ModuleNotFoundError: No module named 'fido2._pyu2f' when running solo

[Elena ``of Valhalla'']

Package: solo-python
Version: 0.0.27-2
Severity: important
Tags: upstream

Dear Maintainer,

When running the solo command on an updated debian testing, e.g. with
``solo --help`` I get a python traceback:

$ solo --help
Traceback (most recent call last):
  File "/usr/bin/solo", line 5, in 
from solo.cli import solo_cli
  File "/usr/lib/python3/dist-packages/solo/cli/__init__.py", line 17, in 

from solo.cli.key import key
  File "/usr/lib/python3/dist-packages/solo/cli/key.py", line 24, in 

import solo.fido2
  File "/usr/lib/python3/dist-packages/solo/fido2/__init__.py", line 3, in 

import fido2._pyu2f
ModuleNotFoundError: No module named 'fido2._pyu2f'

My version of python3-fido2 (as mentioned below) is 0.9.1-1 and I see
that upstream there is already an issue[1] for a failure with fido2 version
0.8.1, but I don't think this one has already been reported.

Thanks in advance

[1] https://github.com/solokeys/solo-python/issues/49

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages solo-python depends on:
ii  python3   3.9.2-2
ii  python3-click 7.1.2-1
ii  python3-cryptography  3.3.2-1
ii  python3-ecdsa 0.16.1-1
ii  python3-fido2 0.9.1-1
ii  python3-intelhex  2.1-2.2
ii  python3-requests  2.25.1+dfsg-2
ii  python3-serial3.5~b0-1
ii  python3-usb   1.0.2-2

solo-python recommends no packages.

solo-python suggests no packages.

-- no debconf information

Bug#977199: lists.debian.org: Please create a new list: debian-localgroups

[Elena ``of Valhalla'']

Package: lists.debian.org
Severity: wishlist

Dear Maintainer,

please create a new mailing list for the local groups team.

name: debian-localgroups
rationale: 
the recently started local groups team needs a place where members
of the local groups can ask for support and the team can provide
guidance and material support.
short description:
Local Groups Team
long description:
Support for the organization of local events and other local group
activities.
category: Miscellaneous Debian
subscription policy: open
post policy: open
web archive: yes

Thanks

Bug#974205: [Pkg-xmpp-devel] Bug#974205: Bug#974205: Disconnects when sending specific character sequences on private chat

[Elena ``of Valhalla'']

On 2020-11-11 at 10:58:04 +0100, Martin wrote:
> On 2020-11-11 10:22, cacat...@tuxfamily.org wrote:
> > I can reproduce it every time by inputting ALT+F1, ALT+Fn keys in a
> > private message window, and sending it.
> ...
> > ALT+Fn keys are meant to switch window but don't seem to work on my
> > setup (I can switch with the other regular ways).
> 
> Maybe this is some speciality of your desktop environment or window manager?
> Which one is it and is it configured in some special way?
> In mine (xfce4), nothing happens, when I press ALT+Fn.

I can reproduce something similar in my desktop environment¹ by pressing
[esc]+[any arrow] (``^[OD`` gets entered on the command line) followed
by enter to send it

¹ fluxbox + urxvt + ssh + screen, which is probably why some keypresses
result in “odd” characters.

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#973204: python-gnupg: FTBFS: AssertionError: Failed doctest test for gnupg.GPG.encrypt

[Elena ``of Valhalla'']

I've tried, but I can't reproduce this test failure elsewhere, either
during the build of the package nor for the standalone source code, so
I'm lowering the severity.

One thing that makes me suspicious is that the failures are when running
the tests with python 3.8, while the new 3.9 is run earlier and ends
with a success: this would make me think about a failure to run the
tests twice in a row, but even that is running correctly when I try it
locally.

If anybody else is able to reproduce this and can explain how I'd be
happy to investigate more.
-- 
Elena ``of Valhalla''

Bug#971894: ITP: lesana -- manage collection inventories through yaml files

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla'' 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: lesana
  Version : 0.6.1
  Upstream Author : Elena Grandi 
* URL : https://lesana.trueelena.org/
* License : GPL-3+
  Programming Lang: Python
  Description : manage collection inventories through yaml files

lesana is a Python library and a command line interface to manage collection
inventaries in a format that is compatible with being store in a git
repository.

I intend to maintain this inside the Debian Python Team. Since I'm also
upstream I wouldn't mind a co-maintainer, but it is not required.

This is usable on its own (from the command line), but also a dependency
of https://git.sr.ht/~fabrixxm/Collector , a Gtk3 frontend that is
currently being developed and works nicely on Mobian.

Bug#968821: bepasty: Syntax highlighting not working

[Elena ``of Valhalla'']

Thanks for noticing this

The cause is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951715
and indeed I had forgotten about it: in the next few days I'll try to
prepare a patch and/or ping the pygments maintainer.

-- 
Elena ``of Valhalla''

Bug#718591: Current status and new upstream dependencies

[Elena ``of Valhalla'']

Considering how this ITP has turned into an RFP am I correct in assuming
that nobody is working on this anymore?

If I'm not mistaken what had been done can be found on

https://anonscm.debian.org/git/3dprinter/packages/octoprint.git/

which points to 

https://salsa.debian.org/3dprinting-team/octoprint

and has a last commit from 2014.

I looked into the new upstream version and I've seen that a few more
dependencies have been added: the following aren't in debian and
for which wnpp-check didn't give any result:

https://pypi.org/project/cachelib/
https://pypi.org/project/sarge/
https://pypi.org/project/lru/
https://pypi.org/project/semantic-version/
https://pypi.org/project/awesome-slugify/
https://pypi.org/project/emoji/

Plus one for which there is already an ITP

https://pypi.org/project/filetype/
http://bugs.debian.org/953523

I don't think I'm ready to commit to pick up an ITP for octoprint, but
I wanted to document what I had found and I may start to work at least
on some of the dependencies in the next few weeks.

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#961119: ansible: Ansible fails to work on a minimal system (missing python 2 dependency)

[Elena ``of Valhalla'']

Package: ansible
Version: 2.7.7+dfsg-1
Severity: important

Dear Maintainer,

on a minimal stable (buster) installation, ansible fails to run (at
least on the machine itself) because of a lack of the python (2)
interpreter.

To reproduce, debootstrap an image (but installing from netinst without
adding things with tasksel also works):

# mkdir buster
# debootstrap buster buster/
# mount -t devtmpfs udev buster/dev/
# chroot buster

# ansible -i localhost, -m setup -c local all

localhost | FAILED! => {
"changed": false,
"module_stderr": "/bin/sh: 1: /usr/bin/python: not found\n",
"module_stdout": "",
"msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
"rc": 127
}

Installing python (2) of course fixes the issue.

I've noticed that it seems to be hardcoded as such in quite a few
modules:

# grep -r '/usr/bin/python$' /usr/lib/python3/dist-packages/ansible | wc -l
2083

but I've also checked that in sid the original command is working, while
those files still have an hardcoded python2 executable, so I'm not sure
what is going on there.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ansible depends on:
ii  openssh-client1:8.2p1-4
ii  python3   3.8.2-3
ii  python3-crypto2.6.1-13.1+b1
ii  python3-cryptography  2.8-4
ii  python3-distutils 3.8.2-2
ii  python3-dnspython 1.16.0-2
ii  python3-httplib2  0.14.0-3
ii  python3-jinja22.10.1-2
ii  python3-netaddr   0.7.19-4
ii  python3-paramiko  2.6.0-2
ii  python3-yaml  5.3.1-1+b1

Versions of packages ansible recommends:
ii  python3-argcomplete  1.8.1-1.3
ii  python3-jmespath 0.9.5-1
ii  python3-kerberos 1.1.14-3.1+b1
ii  python3-libcloud 2.8.0-1
ii  python3-selinux  3.0-1+b3
ii  python3-winrm0.3.0-2
ii  python3-xmltodict0.12.0-2

Versions of packages ansible suggests:
ii  cowsay   3.03+dfsg2-7
ii  sshpass  1.06-1+b1

-- no debconf information

Bug#956027: libjs-popper.js: Upgrading libjs-popper.js buster -> bullseye results in an empty /usr/share/javascript/popper.js

[Elena ``of Valhalla'']

Package: libjs-popper.js
Version: 1.16.0+ds2-1
Severity: important

Dear Maintainer,

When upgrading libjs-popper.js from buster to bullseye, an empty
/usr/share/javascript/popper.js/ directory is left and prevents the
creation of the symlink to ../nodejs/popper.js/dist , thus breaking
anything that expects files in /usr/share/javascript/

To reproduce, it's enough to install libjs-popper.js on a buster system
(e.g. a freshly debootstrapped one) and upgrade it to bullseye.

Removing manually the directory and reinstalling (apt install
--reinstall libjs-popper.js) fixes the problem, as it does removing and
installing again the package.

Thanks in advance

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libjs-popper.js depends on:
ii  javascript-common  11

Versions of packages libjs-popper.js recommends:
pn  node-jquery  

libjs-popper.js suggests no packages.

-- no debconf information

Bug#952576: dput-ng: does not show the stderr of post_upload_command (silent failures when uploading)

[Elena ``of Valhalla'']

Package: dput-ng
Version: 1.29
Severity: normal

Dear Maintainer,

I'm using dput with a profile that sets a post_upload_command and I've
noticed that whatever that command writes on stderr gets suppressed;
this leads to uploads that silently fail.

To reproduce, you can e.g. set::

   "post_upload_command": "echo 'this will appear on dput output'",

to see that stdout is correctly written in the dput output and::

   "post_upload_command": "python --version",

to see how stderr is suppressed instead.
(note: python3 can't be used because it prints its version on stdout,
and so do the other commands I tried before python; of course anything
else that prints something on stderr would do.)

Thanks in advance,

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dput-ng depends on:
ii  python3   3.7.5-3
ii  python3-dput  1.29

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- no debconf information

Bug#950721: ITP: bepasty -- binary pastebin / file upload service

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla'' 

* Package name: bepasty
  Version : 0.5.0
  Upstream Author : Bepasty team
* URL : 
https://github.com/bepasty/bepasty-server/blob/master/AUTHORS
* License : BSD-2-Clause
  Programming Lang: Python
  Description : binary pastebin / file upload service

bepasty is like a pastebin for all kind of files (text, image, audio, video,
 documents, ..., binary).

AFAIK there is no other pastebin server inside debian, and this looks
simple enough to be reasonably mainteinable as a package.

I plan to maintain this inside the python-apps team

Bug#949685: Please drop dependencies on python3-pip / python3-wheel

[Elena ``of Valhalla'']

Thanks for spotting this

I will do it at the first opportunity
-- 
Elena ``of Valhalla''

Bug#945402: [Pkg-phototools-devel] Bug#945402: feh: Please add dcraw to the Suggests (or even Recommends) of the package

[Elena ``of Valhalla'']

On 2019-11-25 at 21:27:04 +0100, László Böszörményi (GCS) wrote:
> On Mon, Nov 25, 2019 at 9:03 PM Elena ``of Valhalla''
>  wrote:
> > On 2019-11-25 at 17:28:32 +0100, László Böszörményi (GCS) wrote:
> > done the upgrade, the same thing is happening.
>  While I can reproduce the problem, for me the displayed messages are these:

yes, I didn't mention the warnings that were already present in buster,
i.e.:

> TIFFReadDirectory: Warning, Photometric tag is missing, assuming data is 
> YCbCr.
> TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, applying
> correct SamplesPerPixel value of 3.
> OJPEGSubsamplingCorrect: Warning, Subsampling tag is not set, yet
> subsampling inside JPEG data [2,1] does not match default values
> [2,2]; assuming subsampling inside JPEG data is correct.
> OJPEGSetupDecode: Warning, Depreciated and troublesome old-style JPEG
> compression mode, please convert to new-style JPEG compression and
> notify vendor of writing software.

then there is:

> OJPEGWriteHeaderInfo: jpeg_start_decompress() returned image_width =
> 4272 and image_height = 2848, expected 4272 and -1.

which I can confirm is the same message I'm getting since updating
(sorry, when I tested earlier I checked that the image wasn't being
opened, and didn't notice that the message had changed).
 
> > At first I thought it was a regression in libimlib2 (and was going to
> > open a bug on that package), but after reading the manpage of feh I
> > started to think that it was never supposed to work the way it did.
>  For me this seems to be tiff checks that became stricter to prevent
> accidental crashes due to images not conforming the standards.
> As such the warnings show the sign of badly written OJPEG format that
> don't conform the standard.

Indeed, that's why I started to think that maybe it was the files' fault
and not the tool.

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#945402: [Pkg-phototools-devel] Bug#945402: feh: Please add dcraw to the Suggests (or even Recommends) of the package

[Elena ``of Valhalla'']

On 2019-11-25 at 17:28:32 +0100, László Böszörményi (GCS) wrote:
>  I think it was a regression due to an other package. Can you please
> do a full upgrade of your Bullseye installation and re-test your image
> with feh? Maybe share that file in private somehow?

done the upgrade, the same thing is happening.

At first I thought it was a regression in libimlib2 (and was going to
open a bug on that package), but after reading the manpage of feh I
started to think that it was never supposed to work the way it did.

As for the file, I have some that can be shared even in public; they are
between 15 and 20 MB so I'm not sure on the best way to do so (I'll try
to send you a private download link).

>  I think it should go to Suggests. I use Recommends if that extends
> the package in some way.

fine

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#945402: feh: Please add dcraw to the Suggests (or even Recommends) of the package

[Elena ``of Valhalla'']

Source: feh
Severity: normal

Dear Maintainer,

Up to buster, feh was able to open (a preview of) the raw files
generated by my camera (Canon EOS 1100D); after upgrading to bullseye it
fails with the following error::

OJPEGDecodeRaw: Inconsistent number of MCU in codestream.
feh WARNING: 20171230/141140-img_5195.cr2 - No Imlib2 loader for that file 
format

However, after a number of attempts, reading the manpage I noticed that
there is a better way to show raw files in feh, by using dcraw.

I think that having dcraw available in the Suggests of the package would
have helped me find this option much earlier, as that's the first thing
I checked, to see if I was missing some optional dependency.

I'm not sure if it's worth adding to the Recommends instead, as enabling
the use of dcraw is not automatic anyway (it requires the option
--conversion-timeout X with non-negative X, in case somebody finds this
report while having the same issue.)

Thanks for your work on feh

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#939678: prosody-modules: Please add mod_bookmarks

[Elena ``of Valhalla'']

Package: prosody-modules
Version: 0.0~hg20190203.b54e98d5c4a1+dfsg-1
Severity: wishlist

Dear Maintainer,

Please consider adding mod_bookmarks_ which helps upgrading from Private
XML to PEP bookmarks and is recommended by
https://compliance.conversations.im

.. _mod_bookmarks: https://modules.prosody.im/mod_bookmarks

Bug#929954: what about just uploading relevant patch for now?

[Elena ``of Valhalla'']

Yaroslav Halchenko  wrote:
> If new version building is problematic, why not to upload just a patched
> version?

That would only delay the removal a bit: I'm sure that the current
version doesn't work with python3, so it's going to be removed sooner or
later from the archive.

Uploading the new upstream would also be python2 only, at least at the
beginning, but at least there is hope that it can be made to work also
with python3.

I don't expect the new version to be problematic, but it will involve a
bit of yak shaving, and and see #876681 (RFH: rst2pdf) on how this
package is pretty low on my priorities.

-- 
Elena ``of Valhalla''

Bug#826908: python3 support

[Elena ``of Valhalla'']

I've updated the forwarded-to-address (hopefully :) ) to the new
upstream ticket, which is closed as implemented.

the setup.py and readme, however, are still claiming that rst2pdf is
still python2 only, so I guess that running under py3 is still not
officially supported (but may work, by patching the setup.py and
possibly some other file).
-- 
Elena ``of Valhalla''

Bug#929954: Status of this issue WRT freeze

[Elena ``of Valhalla'']

On 2019-07-22 at 21:12:34 +0200, Sebastiaan Couwenberg wrote:
> Hi Elena,
> 
> On Fri, 7 Jun 2019 09:21:22 +0200 Elena ``of Valhalla'' wrote:
> > Of course after the release the severity can be raised back, as then it
> > would apply to the majority of users indeed (but I'd just upload the
> > new version of the package and be done with it).
> 
> With the buster release and severity increase behind us, now would be a
> good time to upload the new version.
> 
> Anything preventing you from doing that?

only the fact that the new version has quite a few changes, is not
currently building correctly, and while I have worked on it I haven't
had time to finish fixing everything that needed fixing.

I have pushed the commits I was sure about, but I still have some
uncommitted changes I was trying, so please if you decide to help let me
know and we can cohordinate.

Also, I'm wondering if it is worth doing this work when the package is
at risk of being dropped anyway with the removal of py2 (not
immediately, since it has reverse-(build-)dependencies, but probably
before the bullseye release). (See also #826908)

-- 
Elena ``of Valhalla''

Bug#929954: Status of this issue WRT freeze

[Elena ``of Valhalla'']

Hello

I've given a look at the code, and I expect that what happened is an
implicit import that changed inside reportlab, but I agree that the
right place to fix this is in rst2pdf.

Since we are in freeze, however, I'd like to know whether the changed
reportlab is meant to enter buster or not: I suspect not, since it is a
new upstream release and I couldn't find any unblock bug.

If that is the case, I'd prefer not to do any upload in sid until the
buster release, but I would do as follows:

* lower the severity to important, since the package is still usable for
  the majority of users (those on buster) (unless it can be tagged as
  buster-ignore or there is another way to prevent it from being
  autoremoved from testing, where the package is working);
* check that this issue is still present in the latest upstream version
  of the package and in that case forward it upstream;
* on a lower priority, upload the new upstream version to experimental,
  if needed with a patch for this issue.

Of course after the release the severity can be raised back, as then it
would apply to the majority of users indeed (but I'd just upload the
new version of the package and be done with it).

Any objection to this plan?
-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#929835: infinoted: -c is given as a shortcut both for --config-file and --certificate-file

[Elena ``of Valhalla'']

Package: infinoted
Version: 0.6.7-2
Severity: normal
Tags: upstream

Dear Maintainer,

in the infinoted manpage one reads:

   -c, --config-file=CONFIG-FILE
  Load  the  given  configuration  file  instead of looking at the
  standard locations.

   [...]

   -c, --certificate-file=CERTIFICATE-FILE
  The server's certificate

The program interpreters -c as --certificate-file, but at a glance it's
very easy to try to use it for --config-file, leading to unexpected and
hard to debug failures.

infinoted --help only shows -c for --certificate-file and does not list
any option for --config-file (which would be pretty convenient to have).

Thanks in advance

Bug#651944: Status of friendica packaging

[Elena ``of Valhalla'']

Hello

Are there any updates on the status of this package? Is it still being
considered for the freedombox?

Is there something blocking the packaging, or just lack of time?

thanks
-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#928646: libguestfs-tools: virt-builder --ssh-inject does not accept public keys with cardno:NNNN

[Elena ``of Valhalla'']

Package: libguestfs-tools
Version: 1:1.40.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

I tried to create an image using ``virt-builder [various parameters]
--ssh-inject root:string:"$(ssh-add -L)"`` and a key whose secret part
is saved on a smartcard, and got an error:

   virt-builder: error: invalid ssh-inject selector ‘string:ssh-rsa
   [my public key] cardno:; see the man page

I tried again by copypasting the string itself and manually changing the
last bit to a fake user@host and it worked.

I think that keys in the former format should be supported as well.

Thanks,

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libguestfs-tools depends on:
ii  curl   7.64.0-2
ii  libc6  2.28-10
ii  libconfig9 1.5-0.4
ii  libfuse2   2.9.9-1
ii  libguestfs-perl1:1.40.2-2
ii  libguestfs01:1.40.2-2
ii  libintl-perl   1.26-2
ii  libjansson42.12-1
ii  liblzma5   5.2.4-1
ii  libncurses66.1+20181013-2
ii  libpcre3   2:8.39-12
ii  libreadline7   7.0-5
ii  libstring-shellquote-perl  1.04-1
ii  libsys-virt-perl   5.0.0-1
ii  libtinfo6  6.1+20181013-2
ii  libvirt0   5.0.0-2
ii  libwin-hivex-perl  1.3.18-1
ii  libxml22.9.4+dfsg1-7+b3

Versions of packages libguestfs-tools recommends:
ii  gnupg  2.2.12-1

libguestfs-tools suggests no packages.

-- no debconf information

Bug#927076: RFP: xournalpp -- hand note taking software

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist

* Package name: xournalpp
  Version : 1.0.10
  Upstream Author : ?
* URL : https://github.com/xournalpp/xournalpp
* License : GPL
  Programming Lang: C++
  Description : hand note taking software

Xournal++ is an application for notetaking, sketching and
keeping a journal using a stylus. It can also be used to
add annotations to PDF files.

This is a rewrite of xournal which maintains a decent amount of
backwards compatibility and is currently under active development.
It is mentioned on the xournal homepage itself.

It would be nice to have it in Debian together with xournal (or instead
of xournal, in case the latter will end up being removed because of its
age).

Bug#923794: ITP: python-a38 -- Library to generate Italian Fattura Elettronica

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla'' 

* Package name: python-a38
  Version : 0.1.0
  Upstream Author : Enrico Zini 
* URL : https://github.com/Truelite/python-a38
* License : Apache 2.0
  Programming Lang: Python
  Description : Library to generate Italian Fattura Elettronica

This library implements a declarative data model similar to Django
models, that is designed to describe, validate, serialize and parse
Italian Fattura Elettronica data.
.
The library can generate various kinds of fatture that pass validation,
and can parse all the example XML files distributed by fatturapa.gov.it

I intend to maintain this inside the python-modules team, and Enrico
will be a co-uploader.

Of course this is meant for Debian Bullseye and beyond.

Bug#920414: tahoe-lafs: Please package new upstream version 1.13.0

[Elena ``of Valhalla'']

Source: tahoe-lafs
Version: 1.12.1-5
Severity: wishlist

Dear Maintainer,

I've noticed that a few months ago upstream released a new version of
the package:

https://tahoe-lafs.org/pipermail/tahoe-dev/2018-August/009923.html

I realize that there would be very little time, but do you think it
would be possible to have it in debian buster before the freeze?

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#911369: libvirt0: Virtual machines no longer see storage / network devices

[Elena ``of Valhalla'']

Package: libvirt0
Version: 4.7.0-1+b1
Severity: important

Dear Maintainer,

after a kernel update (4.18.10-1 -> 4.18.10-2) the machines I created
with virt-manager and QEMU/KVM are no longer able to boot because they
can't find /dev/vda1.

I played around with other storage buses (e.g. SCSI), to no avail.

I then tried to create a new machine from scratch with the stretch
netinstall and discovered it wasn't able to find any ethernet device.

Rebooting the host with the previous kernel resulted in the virtual
machines correctly working.

Please, let me know if I have to try something else to help you
reproduce the bug

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt0 depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.13-8
ii  libaudit1   1:2.8.4-2
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libc6   2.27-6
ii  libcap-ng0  0.7.9-1
ii  libcurl3-gnutls 7.61.0-1
ii  libdbus-1-3 1.12.10-1
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libgcc1 1:8.2.0-7
ii  libgnutls30 3.5.19-1
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libsasl2-2  2.1.27~rc8-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2
ii  libxml2 2.9.4+dfsg1-7+b1
ii  libyajl22.1.0-3

Versions of packages libvirt0 recommends:
ii  lvm2  2.02.176-4.1

libvirt0 suggests no packages.

-- no debconf information

Bug#905159: error message

[Elena ``of Valhalla'']

To help searches to point to this issue: the error message one gets when
trying to encrypt a message is:

sh: 1: /usr/libexec/neomutt/pgpewrap: not found
Press any key to continue...

(while, as mentioned in the above message, pgpewrap is in
/usr/lib/neomutt/pgpewrap)

-- 
Elena ``of Valhalla''

Bug#907036: e2fsprogs: Please also accept y when asking y/n questions in a non-english locale

[Elena ``of Valhalla'']

Package: e2fsprogs
Version: 1.44.3-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

I've just stumbled on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897593 (which is still
happening in italian, related bug is coming).

I've noticed that other programs (e.g. apt) also accept the english
defaults 'y' and 'n' when asking yes/no questions even in other locales;
this would help prevent similar errors in the future (and also helps
the muscle memory of people who deal with systems in different languages
:) )

I don't know how apt and other programs deal with languages where the
local word for 'yes' starts with n or viceversa.

Could this be done?

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages e2fsprogs depends on:
ii  libblkid12.32.1-0.1
ii  libc62.27-5
ii  libcom-err2  1.44.3-1
ii  libext2fs2   1.44.3-1
ii  libss2   1.44.3-1
ii  libuuid1 2.32.1-0.1

Versions of packages e2fsprogs recommends:
ii  e2fsprogs-l10n  1.44.3-1

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-21+b1

-- no debconf information

Bug#907034: e2fsprogs: mkfs.ext4 asks for "y/N" but requires a different char in some locales

[Elena ``of Valhalla'']

Package: e2fsprogs
Version: 1.44.3-1
Severity: normal

Dear Maintainer,

This is probably a similar issue to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897593 : when using
the italian locale mkfs.ext4 asks for (y,N), but expects 's' as an
answer, and otherwise exists doing nothing.

I'm opening a new bug as that one is already marked as fixed to ask if
it would be possible to try to keep the label printed and the required
character aligned.

I've checked the german (de_DE) and french (fr_FR) locales and those are
correctly translated, but I suspect that there may be others that
aren't, so just fixing the italian translation is probably not going to
be a complete solution.

Thanks

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages e2fsprogs depends on:
ii  libblkid12.32.1-0.1
ii  libc62.27-5
ii  libcom-err2  1.44.3-1
ii  libext2fs2   1.44.3-1
ii  libss2   1.44.3-1
ii  libuuid1 2.32.1-0.1

Versions of packages e2fsprogs recommends:
ii  e2fsprogs-l10n  1.44.3-1

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-21+b1

-- no debconf information

Bug#905012: RFP: matterbridge -- Bridge between many chat systems / protocols

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist

* Package name: matterbridge
  Version : 1.11.0
  Upstream Author : 42wim
* URL : https://github.com/42wim/matterbridge
* License : Apache 2.0
  Programming Lang: go
  Description : Bridge between many chat systems / protocols

a simple bridge between IRC, XMPP, Gitter, Mattermost, Slack, Discord,
Telegram, Rocket.Chat, Hipchat(via xmpp), Matrix, Steam, ssh-chat and
Zulip Has a REST API.

As far as I know there are no other similar tools inside Debian with
support for such a list of systems.

Packaging this would help people work around the issues caused by
https://xkcd.com/1810/ (proliferation of incompatible chat systems).

To package it, quite a few go dependencies would need to be packaged,
listed at https://github.com/42wim/matterbridge#thanks

I think that pkg-go would be the right place to maintain the libraries,
and either that or pkg-xmpp may be interested in the package itself.

Bug#902834: goldendict: zim support doesn't seem to be working

[Elena ``of Valhalla'']

On 2018-07-01 at 22:42:21 +0200, Elena ``of Valhalla'' wrote:
> The files are pretty big (the smallest is 1.2G): could it be the reason?
> Tomorrow CEST I can try downloading some other smaller dumps from the
> site above (there are some that are ~100MB).

no difference even with a smaller file (122M, regular file in a
directory of its own).

-- 
Elena ``of Valhalla''

Bug#902834: goldendict: zim support doesn't seem to be working

[Elena ``of Valhalla'']

Package: goldendict
Version: 1.5.0~rc2+git20180412+ds-1
Severity: normal

Dear Maintainer,

I've seen in the changelog that you are enabling zim support in
goldendict, which is strongly appreciated.
This is also mentioned in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763321#48

However, I can't seem to be able to make it actually work: I have a
directory with a few zim files (downloaded from http://www.kiwix.org/ ),
add it to goldendict under Edit - Dictionaries and hit Rescan now, but
nothing new appears in Dictionaries.

I have installed libzim2 manually, as it wasn't listed among the
dependencies, but that didn't help.

I have run goldendict from the command line, but stdout doesn't seem to
be mentioning anything relevant.

The files are pretty big (the smallest is 1.2G): could it be the reason?
Tomorrow CEST I can try downloading some other smaller dumps from the
site above (there are some that are ~100MB).

The files are also symbolic links, but I've tried to copy one of them
elsewhere as a regular file, and that didn't help.

I may be doing something wrong, but I can't understand what.

Please let me know if you need me to check anything else.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages goldendict depends on:
ii  libao4 1.2.2+20180113-1
ii  libavcodec57   7:3.4.2-2+b2
ii  libavformat57  7:3.4.2-2+b2
ii  libavutil557:3.4.2-2+b2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.27-3
ii  libeb164.4.3-12
ii  libgcc11:8.1.0-8
ii  libhunspell-1.6-0  1.6.2-1+b1
ii  liblzo2-2  2.10-0.1
ii  libopencc2 1.0.5-1
ii  libqt5core5a   5.10.1+dfsg-7
ii  libqt5gui5 5.10.1+dfsg-7
ii  libqt5help55.10.1-2
ii  libqt5multimedia5  5.10.1-2
ii  libqt5multimedia5-plugins  5.10.1-2
ii  libqt5network5 5.10.1+dfsg-7
ii  libqt5printsupport55.10.1+dfsg-7
ii  libqt5svg5 5.10.1-2
ii  libqt5webkit5  5.212.0~alpha2-9+b1
ii  libqt5widgets5 5.10.1+dfsg-7
ii  libqt5x11extras5   5.10.1-2
ii  libqt5xml5 5.10.1+dfsg-7
ii  libstdc++6 8.1.0-8
ii  libtiff5   4.0.9-5
ii  libvorbisfile3 1.3.6-1
ii  libx11-6   2:1.6.5-1
ii  libxtst6   2:1.2.3-1
ii  zlib1g 1:1.2.11.dfsg-1

goldendict recommends no packages.

Versions of packages goldendict suggests:
pn  goldendict-wordnet  

-- no debconf information

Bug#902535: bpython: Missing dependency (or recommend) on less

[Elena ``of Valhalla'']

Source: bpython
Severity: normal

Dear Maintainer,

running bpython(3) inside a minimal installation and trying to read the
help of some module or function results in an ``OSError: [Errno 2] No
such file or directory`` | ``FileNotFoundError: [Errno 2] No such file
or directory: 'less'`` (python 2 or 3 respectively) because the pager of
choice (which seems to be less) can't be found.

Manually installing less results in the correct behaviour.

I agree that running bpython(3) on a system where less is not installed
is a niche case (it took me years of using bpython before I ever met
this issue), but I think that less should be added to the Recommends: of
both bpython and bpython3, as I consider reading help quite a common
activity inside an interactive interpreter. (not a Depends:, as it isn't
required for basic functionality, however).

To reproduce:

* debootstrap a chroot, forget to install basic tools such as less :)
* install bpython or bpython3 inside the chroot and run it::

>>> import this
[...]
>>> help(this)
Traceback (most recent call last):
  File "", line 1, in 
help(this)
  File 
"/usr/lib/python3/dist-packages/bpython/curtsiesfrontend/_internal.py", l
ine 60, in __call__ 
   
return super(_Helper, self).__call__(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/bpython/_internal.py", line 24, in 
__call
__  
   
self.helper(*args, **kwargs)
  File "/usr/lib/python3.5/pydoc.py", line 1853, in __call__
self.help(request)  
  File "/usr/lib/python3.5/pydoc.py", line 1906, in help
else: doc(request, 'Help on %s:', output=self._output)
  File "/usr/lib/python3.5/pydoc.py", line 1640, in doc   
pager(render_doc(thing, title, forceload)) 
  File 
"/usr/lib/python3/dist-packages/bpython/curtsiesfrontend/_internal.py", l
ine 53, in pager
   
self._repl.pager(output)
  File "/usr/lib/python3/dist-packages/bpython/curtsiesfrontend/repl.py", 
line 1
699, in pager   
   
self.focus_on_subprocess(command + [tmp.name])
  File "/usr/lib/python3/dist-packages/bpython/curtsiesfrontend/repl.py", 
line 1
684, in focus_on_subprocess 
   
stdout=sys.__stdout__) 
  File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
restore_signals, start_new_session) 
  File "/usr/lib/python3.5/subprocess.py", line 1282, in _execute_child
raise child_exception_type(errno_num, err_msg) 
FileNotFoundError: [Errno 2] No such file or directory: 'less'

Thanks for your job maintaining bpython

Bug#897635: pdfposter: please move pdfposter from python2 to python3

[Elena ``of Valhalla'']

On 2018-05-03 at 13:39:23 -0400, Daniel Kahn Gillmor wrote:
> Package: pdfposter
> Version: 0.6.0-2
> Severity: wishlist
> 
> It would be great if pdfposter didn't have any python2 dependencies.
> i believe python3-pypdf2 is already available, so it should just be a
> matter of ensuring that pdfposter itself i is python3-compliant and
> shifting the dependencies directly.

python3 support has been added upstream about one year ago, in 

https://gitlab.com/pdftools/pdfposter/commit/663081f71bf855273aa22a211e7f1151347e191c

but is still not in a release.

As you already know[1] :) I had pinged upstream for a release, but it's
still pending (thanks for the further ping, btw)

[1] https://gitlab.com/pdftools/pdfposter/issues/5#note_71467160

the patch does look pretty simple, but I don't believe that it applies as
is to the old code in the packaged version, so I would prefer to wait
for the new upstream release to deliver code that has been actually
tested on py3.

-- 
Elena ``of Valhalla''

Bug#873329: Any news?

[Elena ``of Valhalla'']

I've seen that love has been autoremoved from testing because of this
bug, which seems to be fixed in the next upstream version.

Are there news on its packaging? is it still waiting for a review of the
copyright file or was there some blocking issues found?

I'm not interested in maintaining this package, but maybe I could give
some one-off help

-- 
Elena ``of Valhalla''

Bug#892065: flashrom: Please package new upstream version 1.0

[Elena ``of Valhalla'']

Package: flashrom
Version: 0.9.9+r1954-1+b1
Severity: wishlist

Dear Maintainer,

After a couple of years, upstream has released a new version, 1.0.

It doesn't have huge changes (https://www.flashrom.org/Flashrom/1.0),
but it would be nice to have it packaged in debian.

Thanks for your work.

Bug#890006: make the testsuite more verbose, so it doesn't time out

[Elena ``of Valhalla'']

I've tried to apply the patch (or variants of it), but having all
messages at DEBUG level printed on stderr leads to an unreadable log
that is going to actually hurt debugging in case tests will fail in the
future, and I couldn't find a good in-between amount of logging.

Since the main issue is already tracked on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874720
and that AFAIK debian infrastructure is able to build this package,
I'm going to close this bug as nonfix in the hope to be able to work on
a proper fix in the future.

-- 
Elena ``of Valhalla''

Bug#880915: Backport uploaded

[Elena ``of Valhalla'']

Hello

debacle did the backport of the version currently in testing with
support for gnupg2.1 and uploaded it to stretch-backport; do you think
that we can consider this bug closed?
-- 
Elena ``of Valhalla''

Bug#889903: python-gnupg needs an explict b-d on 2to3

[Elena ``of Valhalla'']

On 2018-02-08 at 16:31:05 +0100, Matthias Klose wrote:
> python-gnupg needs an explict b-d on 2to3. The binary is now provided in a
> separate package.

will do it asap, thanks

> Please could you also run the testsuite with verbosity=2 ?

I can't think any reason why not, so I will probably also do this in the
same upload

-- 
Elena ``of Valhalla''

Bug#876681: RFH: rst2pdf -- ReportLab-based reStructuredText to PDF renderer

[Elena ``of Valhalla'']

On 2018-01-07 at 16:31:58 +0100, Andrew Shadura wrote:
> On 7 January 2018 at 16:13, Elena ``of Valhalla''
> <valhall...@trueelena.org> wrote:
> > On 2017-09-25 at 07:31:29 +0200, Andrew Shadura wrote:
> >> I think I can have a look at it :) I'll let you know later today if
> >> I'm really interested.
> >
> > Can I assume that you're not interested?
> >
> > rst2pdf is going to be autoremoved from testing because of #866477, and
> > right now I'm more likely to just let it be removed rather than working
> > on it only to have the package removed a little later because of a lack
> > of py3 support (unless somebody else is interested in the package, of
> > course).
> 
> Sorry, I completely forgot about this. I will *indeed* jave a look later 
> today.
> 
> -- 
> Cheers,
>   Andrew

Update 1: thanks to Andrew I realized that #866477 wasn't rightfully
release critical and brought it back to normal (so the package shouldn't
get autoremoved.

Update 2: upstream is currently working, apparently on tests
https://github.com/rst2pdf/rst2pdf/commits/master and they seem to have
a release planned https://github.com/rst2pdf/rst2pdf/milestones
so maybe the only thing that is needed is to ping them a bit on python3
support https://github.com/rst2pdf/rst2pdf/issues/537 where activity
seems stalled (and it's not in any release milestone).

I believe that having working automated tests is considered necessary
for the port, but I don't know what's the current status of them.

-- 
Elena ``of Valhalla''

Bug#866477: python-imaging package will be dropped

[Elena ``of Valhalla'']

On 2018-01-07 at 19:10:58 +0100, Andrej Shadura wrote:
> In fact, the binary package only Suggests: python-imaging, isn't this a
> normal severity bug then?

You're right.

I misremembered it as a build-dependency, but there isn't one.

Severity changed back to normal.

-- 
Elena ``of Valhalla''

Bug#866477: python-imaging package will be dropped

[Elena ``of Valhalla'']

See also 

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

(upstream is not completely dead and one day may end up doing a more
modern release, but if there are no pressing needs for this old version
to remain in testing / next stable I'll just let it be autoremoved while
waiting for upstream)
-- 
Elena ``of Valhalla''

Bug#876681: RFH: rst2pdf -- ReportLab-based reStructuredText to PDF renderer

[Elena ``of Valhalla'']

On 2017-09-25 at 07:31:29 +0200, Andrew Shadura wrote:
> I think I can have a look at it :) I'll let you know later today if
> I'm really interested.

Can I assume that you're not interested?

rst2pdf is going to be autoremoved from testing because of #866477, and
right now I'm more likely to just let it be removed rather than working
on it only to have the package removed a little later because of a lack
of py3 support (unless somebody else is interested in the package, of
course).

-- 
Elena ``of Valhalla''

Bug#884577: cura: Crashes at startup

[Elena ``of Valhalla'']

Package: cura
Version: 2.5.0-1
Severity: important

Dear Maintainer,

I've just installed cura from sid on a testing system by temporarily
enabling the sid repository.

running ``cura`` leads to a splash screen briefly appearing, followed by
the program crashing with the attached traceback on stderr.

I also attach the stdout, in case it has useful informations as it has
opengl autodetect result.

Please let me know if I should try anything to help diagnosing the
problem.

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cura depends on:
ii  cura-engine 1:3.0.3-2
ii  fonts-open-sans 1.11-1
ii  python3 3.6.3-2
ii  python3-pyqt5   5.9.2+dfsg-1
ii  python3-pyqt5.qtopengl  5.9.2+dfsg-1
ii  python3-savitar 3.0.3-3
ii  python3-serial  3.4-1
ii  python3-uranium 3.0.3-1
ii  qml-module-qt-labs-folderlistmodel  5.9.2-3
ii  qml-module-qt-labs-settings 5.9.2-3
ii  qml-module-qtqml-models25.9.2-3
ii  qml-module-qtquick-controls 5.9.2-2
ii  qml-module-qtquick-dialogs  5.9.2-2
ii  uranium-plugins 3.0.3-1

Versions of packages cura recommends:
ii  fdm-materials 3.0.3-3
ii  python3-zeroconf  0.19.1-1

cura suggests no packages.

-- no debconf information
2017-12-17 09:16:03,343 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin ConsoleLogger
2017-12-17 09:16:03,358 - ERROR - UM.Logger.logException [76]: Exception: 
Unable to find the required plugin.json file for plugin CuraEngineBackend
2017-12-17 09:16:03,359 - ERROR - UM.Logger.logException [80]: Traceback (most 
recent call last):
2017-12-17 09:16:03,359 - ERROR - UM.Logger.logException [80]:   File 
"/usr/lib/python3/dist-packages/UM/PluginRegistry.py", line 409, in 
_populateMetaData
2017-12-17 09:16:03,359 - ERROR - UM.Logger.logException [80]: with 
open(metadata_file, "r") as f:
2017-12-17 09:16:03,359 - ERROR - UM.Logger.logException [80]: 
FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/cura/plugins/CuraEngineBackend/plugin.json'
2017-12-17 09:16:03,364 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin SimpleView
2017-12-17 09:16:03,372 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin LocalFileOutputDevice
2017-12-17 09:16:03,372 - WARNING - UM.PluginRegistry.loadPlugin [200]: Plugin 
ConsoleLogger was already loaded
2017-12-17 09:16:03,376 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin OBJWriter
2017-12-17 09:16:03,381 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin STLWriter
2017-12-17 09:16:03,386 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin OBJReader
2017-12-17 09:16:03,395 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin STLReader
2017-12-17 09:16:03,398 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin FileLogger
2017-12-17 09:16:03,406 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin MirrorTool
2017-12-17 09:16:03,417 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin ScaleTool
2017-12-17 09:16:03,425 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin TranslateTool
2017-12-17 09:16:03,432 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin CameraTool
2017-12-17 09:16:03,440 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin RotateTool
2017-12-17 09:16:03,445 - INFO - UM.PluginRegistry.loadPlugin [238]: Loaded 
plugin SelectionTool
2017-12-17 09:16:03,448 - ERROR - UM.Logger.logException [76]: Exception: 
Unable to find the required plugin.json file for plugin ChangeLogPlugin
2017-12-17 09:16:03,449 - ERROR - UM.Logger.logException [80]: Traceback (most 
recent call last):
2017-12-17 09:16:03,449 - ERROR - UM.Logger.logException [80]:   File 
"/usr/lib/python3/dist-packages/UM/PluginRegistry.py", line 409, in 
_populateMetaData
2017-12-17 09:16:03,449 - ERROR - UM.Logger.logException [80]: with 
open(metadata_file, "r") as f:
2017-12-17 09:16:03,449 - ERROR - UM.Logger.logException [80]: 
FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/cura/plugins/ChangeLogPlugin/plugin.json'
2017-12-17 09:16:03,452 - ERROR - UM.Logger.logException [76]: Exception: 
Unable to find the required plugin.json file for plugin ChangeLogPlugin
2017-12-17 09:16:03,452 - ERROR - UM.Logger.logException [80]: Traceback (most 
recent call last):
2017-12-17 09:16:03,452 - ERROR - UM.Logger.logException [80]:   File 
"/usr/lib/python3/dist-packages/UM/PluginRegistry.py", line 409, in 
_populateMetaData
2017-12-17 09:16:03,452 - ERROR - UM.Logger.logException 

Bug#883103: ITP: proxmoxer -- Python Wrapper for the Proxmox 2.x API

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla'' <valhall...@trueelena.org>

* Package name: proxmoxer
  Version : 1.0.0
  Upstream Author : Oleg Butovich <obutov...@gmail.com>
* URL : https://github.com/swayf/proxmoxer
* License : MIT
  Programming Lang: Python
  Description : Python Wrapper for the Proxmox 2.x API

Proxmoxer is a wrapper around the `Proxmox REST API v2
<https://pve.proxmox.com/wiki/Proxmox_VE_API>`_
which allows to programmatically create / delete / manage instances of
proxmox managed virtual machines and containers.

It is also used by the proxmox module for ansible 
http://docs.ansible.com/ansible/latest/proxmox_module.html
(and thus a python2 version will be needed, together with the py3 one).

I plan to maintain this package inside the Python Modules Team.

Bug#881721: RFP: swift-im -- Easy to use XMPP client

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist

* Package name: swift-im
  Version : 3.0
* URL : http://swift.im/
* License : GPL, 3rd party components under BSD variants that
need checking
  Programming Lang: C++
  Description : An elegant, secure, adaptable and intuitive XMPP Client.


This package was recommended to me as a good XMPP client for newcomers,
and from the screenshots it does look like it is.
As I'm more of an irssi-like-UI person, I'm not personally interested in
using, nor maintaining it, but I'm opening this RFP to keep track of
interest from other people.

In case it was packaged I would install it and, if it correspond to
expectations, recommend it to other users who are more prone to use
conventional UIs.

At a quick glance, I've noticed that the source repository includes some
3rd party components that may require splitting out, see e.g. 
http://swift.im/git/swift/tree/COPYING.thirdparty
http://swift.im/git/swift/tree/COPYING.dependencies

Bug#880990: widelands: Segmentation fault on loading a game

[Elena ``of Valhalla'']

On 2017-11-11 at 19:38:55 +0100, Markus Koschany wrote:
> thank you for reporting this issue. I can confirm that widelands
> segfaults in Testing. After some investigation I have found out that
> libsdl2 in Testing is the root cause for this problem and widelands is
> only affected. I can't reproduce it with the latest version in Sid
> though hence I'm going to mark this issue as fixed in libsdl2 version
> 2.0.7+dfsg1-3.

I've installed the version of libsdl2-2.0-0 from sid on my testing and I
can confirm that the issue is fixed and widelands is running again.

Thanks!

-- 
Elena ``of Valhalla''

Bug#880990: widelands: Segmentation fault on loading a game

[Elena ``of Valhalla'']

Package: widelands
Version: 1:19+repack-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I have installed widelands on a buster amd64 system and found the sad
surprise that it is no longer working: opening any game (tutorial,
campaign or game) results in a segfault with the attached output.
I didn't try multiplayer games.

Originally I tried with an existing ~/.widelands directory, but I moved
it away and could still reproduce the behaviour.

Please let me know if there is any other information I can provide: I
have all of the free time saved by not playing widelands that I can use
to help investigate this issue :)

The following are the last few lines of ``strace widelands``:

[ENOENT on files in ~/.widelands as far as my eyes[esc]bdwabacklog can see]

stat("/usr/share/games/widelands/data/world/critters/fox/fox_walk_nw_20.png", 
0x7ffe463be940) = -1 ENOENT (No such file or directory)
stat("/home/valhalla/.widelands/sound/animals", 0x7ffe463be220) = -1 ENOENT 
(No such file or directory)
stat("/usr/share/games/widelands/data/sound/animals", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/home/valhalla/.widelands/sound/animals", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
open("/usr/share/games/widelands/data/sound/animals", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 18
fstat(18, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(18, /* 46 entries */, 32768)   = 1488
getdents(18, /* 0 entries */, 32768)= 0
close(18)   = 0
stat("/home/valhalla/.widelands/sound/animals/coyote_01.ogg", 
0x7ffe463be170) = -1 ENOENT (No such file or directory)
stat("/usr/share/games/widelands/data/sound/animals/coyote_01.ogg", 
{st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
stat("/usr/share/games/widelands/data/sound/animals/coyote_01.ogg", 
{st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
open("/usr/share/games/widelands/data/sound/animals/coyote_01.ogg", 
O_RDONLY) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
fstat(18, {st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
lseek(18, 28672, SEEK_SET)  = 28672
read(18, 
"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 676) = 
676
lseek(18, 0, SEEK_SET)  = 0
read(18, 
"OggS\0\2\0\0\0\0\0\0\0\0\320S(t\0\0\0\0006~\352\315\1\36\1vor"..., 28672) = 
28672
read(18, 
"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 4096) = 
676
close(18)   = 0
brk(0x55fb3b0f8000) = 0x55fb3b0f8000
mmap(NULL, 33329152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x7f5e59837000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffe463c5000} 
---
+++ killed by SIGSEGV +++
Segmentation fault


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages widelands depends on:
ii  libboost-regex1.62.0  1.62.0+dfsg-4+b2
ii  libboost-test1.62.0   1.62.0+dfsg-4+b2
ii  libc6 2.24-17
ii  libgcc1   1:7.2.0-12
ii  libgl10.2.999+git20170802-5
ii  libgl1-mesa-glx   17.2.4-1
ii  libglew2.02.0.0-5
ii  libicu57  57.1-8
ii  libminizip1   1.1-8+b1
ii  libpng16-16   1.6.34-1
ii  libsdl2-2.0-0 2.0.6+dfsg1-4
ii  libsdl2-image-2.0-0   2.0.1+dfsg-4
ii  libsdl2-mixer-2.0-0   2.0.1+dfsg1-3
ii  libsdl2-net-2.0-0 2.0.1+dfsg1-3
ii  libsdl2-ttf-2.0-0 2.0.14+dfsg1-2
ii  libstdc++67.2.0-12
ii  widelands-data1:19+repack-4
ii  zlib1g1:1.2.8.dfsg-5

widelands recommends no packages.

widelands suggests no packages.

-- no debconf information
This is Widelands Version build-19 (Release)
Set home directory: /home/valhalla/.widelands
There's no configuration file, using default values.
Adding directory: /usr/share/games/widelands/data
selected language: (system language)
using locale en_IE.UTF-8
Graphics: Try to set Videomode 800x600
Graphics: OpenGL: Version "2.1 Mesa 17.2.4"
Graphics: SDL_GL_RED_SIZE is 8
Graphics: SDL_GL_GREEN_SIZE is 8
Graphics: SDL_GL_BLUE_SIZE is 8
Graphics: SDL_GL_ALPHA_SIZE is 0
Graphics: SDL_GL_BUFFER_SIZE is 24
Graphics: SDL_GL_DOUBLEBUFFER is 1
Graphics: SDL_GL_DEPTH_SIZE is 24
Graphics: SDL_GL_STENCIL_SIZE is 8
Graphics: SDL_GL_ACCUM_RED_SIZE is 0
Graphics: SDL_GL_ACCUM_GREEN_SIZE is 0
Graphics: SDL_GL_ACCUM_BLUE_SIZE is 0
Graphics: SDL_GL_ACCUM_ALPHA_SIZE is 0
Graphics: SDL_GL_STEREO is 0
Graphics: SDL_GL_MULTISAMPLEBUFFERS is 0
Graphics: SDL_GL_MULTISAMPLESAMPLES is 0
Graphics: 

Bug#592159: Status update?

[Elena ``of Valhalla'']

Hello

I've seen that the required dependencies that blocked this bug have been
uploaded, so I wonder: what is the status of this ITP?

Is there any other dependency that is missing? or are there other
issues?

As somebody that is still looking for a great text-based xmpp client I'd
love to try poezio.

BTW, I've noticed that the homepage for it has changed: now it's 
https://poez.io/en/

Thanks for your packaging work.
-- 
Elena ``of Valhalla''

Bug#880915: python3-gnupg: Fails to import keys, exception "KEY_CONSIDERED"

[Elena ``of Valhalla'']

On 2017-11-05 at 19:56:07 +0100, deb...@activityworkshop.net wrote:
> Thanks very much for looking at this so promptly, and sorry for the
> incompleteness of the description.

it's fine, thanks for answering back promptly with the clarifications.

> On 2017-11-05 18:22, Elena ``of Valhalla'' wrote:
> > > from gpg import GPG
> > 
> > is this a typo for ``from gnupg import GPG``?
> Yes, you're right, sorry.

NP, just wanted to be sure before spending time on a wild chase :)

> [...]
> Unfortunately when I tried it again with a fresh keyring I realised that I'd
> made a mistake earlier, and the GPG construction wasn't what I had thought.
> I was actually doing this:
> gpg = GPG(gnupghome="/path/to/keyring", gpgbinary="gpg")
> [...]

then I know what the issue is:

the version of python3-gnupg currently in stretch has known issues with
gnupg version 2.1+: it had support for gnupg 2.0, but there were enough
changes in 2.1 that some features broke and they weren't fixed in time
for the freeze, so python(3)-gnupg was configured to default on gpg1 as
the gpgbinary.

The difference between stable and oldstable is that in jessie the binary
gpg was provided by gnupg 1.4, while in stretch this is gnupg 2.1, with
a significant interface difference.

> I need to do some reading about gpg1 and gpg2 and presumably just take the
> default instead of trying to specify one (I don't yet understand the
> differences).  I had thought that specifying the gpgbinary was necessary
> because on non-linux platforms it wouldn't necessarily be called "gpg".

I'm sorry that I don't know enough of non-linux platforms to help on
this point, but in the upstream code of this module there is already a
default set on gpgbinary to be 'gpg', so I believe that you probably
don't need to set it unless you need to do so in a platform-dependant
way in the cases where it has to differ from the default.

As for the choice between gpg1 and 2, python(3)-gnupg tries to
autodetect what it's working with and do the right thing, so if you
don't need the features provided by gpg2 you are probably fine just
using the default as that will work the same way on jessie, stretch and
buster even if the backend gpg changes.

It is true, however, that debian is migrating towards gnupg2, so if you
(or anybody else) don't want to be stuck with both versions for another
release what I can do is to provide a backport of the version currently
in testing, as that one has gone back to use gpg as the gpgbinary.
In that case, if you don't specify a gpgbinary yourself the users of
your program can choose whether to install the dependency from stable
(and live with both versions of gnupg installed) or use the one in
backports and be able to be rid of gnupg1.

(A note to myself, so that I don't forget about it: before uploading the
backport I need to check that it does not break gajim and act
appropriately if it does.)
-- 
Elena ``of Valhalla''

Bug#880915: python3-gnupg: Fails to import keys, exception "KEY_CONSIDERED"

[Elena ``of Valhalla'']

I've done a trivial attempt at reproducing this on testing (buster)¹ and
importing seems to work, so I have a couple of questions before I
investigate more in depth on a stretch.

On 2017-11-05 at 16:55:38 +0100, activityworkshop wrote:
> from gpg import GPG

is this a typo for ``from gnupg import GPG``? otherwise this is probably
not the right package (maybe python3-gpg?)

> gpg = GPG(gnupghome="/path/to/keyring")
> result = gpg.import_keys(strKey)
> 
> where strKey is a string containing a private key.

I've tried to reproduce it by exporting a secret key both by armouring
it and reading it as a string (``with open('somekey.asc') as fp: strKey
= fp.read()``) as well as exporting the same secret key unarmoured and
reading it as bytes (``with open('somekey.gpg', 'rb') as fp: strKey =
fp.read()``); which method are you using?

¹ the version currently in buster is more recent than the one in stable,
so that can easily be the reason for the non reproduction of this issue.

-- 
Elena ``of Valhalla''

Bug#879385: installation-reports: Mele A1000 successful installation with customized netinst sd image

[Elena ``of Valhalla'']

Package: installation-reports
Severity: normal

Dear Maintainer,

Installation was successful, I'm reporting it because this board is listed
as not tested yet on https://wiki.debian.org/InstallingDebianOn/Allwinner

-- Package-specific info:

Boot method: SD with custom uboot
Image version: 
http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/
 30-Sep-2017
Date: 2017-10-21 16:00

Machine: Mele A1000
Partitions: 
 Disk /dev/mmcblk0: 3.8 GiB, 4089446400 bytes, 7987200 sectors
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: dos
 Disk identifier: 0xb752a329

 Device Boot   Start End Sectors  Size Id Type
 /dev/mmcblk0p1 *   2048  458751  456704  223M 83 Linux
 /dev/mmcblk0p2   458752 763 6541312  3.1G 83 Linux
 /dev/mmcblk0p3  7002110 7985151  983042  480M  5 Extended
 /dev/mmcblk0p5  7002112 7985151  983040  480M 82 Linux swap / Solaris

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[ ]
Overall install:[O]

Comments/Problems:

I've created the image file by dd-ing on an SD a concatenateable image using
firmware.A10-OLinuXino-Lime.img.gz 

For the image file I've taken:

* firmware.A10-OLinuXino-Lime.img.gz and partition.img.gz from
  
http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/
  concatenated and put on an SD card.

* a self-compiled uboot from the mainline git repository (appears as ``U-Boot
  2017.11-rc2 (Oct 21 2017 - 11:23:50 +0200) Allwinner Technology`` at boot).

Installation proceeded as usual when using the concatenateable images for a
supported board.

After the installation, /boot/dtb points correctly to
/boot/dtbs/4.9.0-4-armmp/sun4i-a10-a1000.dtb

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u2"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux melevisione 4.9.0-4-armmp #1 SMP Debian 4.9.51-1 (2017-09-28) 
armv7l GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: USB2.0 Hub [05e3:0608]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 02: 802.11n WLAN Adapter [0bda:8176]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Realtek
usb-list:Interface 00: Class ff(vend.) Subclass ff Protocol ff Driver 
rtl8192cu
usb-list: 
usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: dm_mod103409  0
lsmod: md_mod120936  0
lsmod: jfs   174500  0
lsmod: btrfs1146126  0
lsmod: xor 4718  1 btrfs
lsmod: zlib_deflate   20290  1 btrfs
lsmod: raid6_pq   

Bug#878360: debdate: Change package description to eg "Convert Gregorian dates to Debian Release dates"

[Elena ``of Valhalla'']

Package: debdate
Severity: wishlist

As discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877404
there is a request not to use a name that is suggestive of a monarchy.

Of course, I agree that having a king would be pretty bad for Debian,
altought considering what the release names are this package would refer
at most to a mostly harmless puppet king.

Chris Lamb wrote that:

> "Regnal" is really quite an esoteric English word these days.

This was, however, precisely by design, as this method of dating is
quite an esoteric one that has passed in disuse (for quite a number of
good practical reason).

I've tried to look for another name for this kind of dating, but it
seems to me that at least on the historical articles on wikipedia
"regnal" is the standard name used, even in cases like the roman 
consules that wheren't kings (nor, during the empire, rulers).

Another term that occurs in those articles is "era name", which could be
made to fit, altought it is less precise.

So, if there is a proposal that I've missed that doesn't involve kings
but evokes the same feel of "out of an history wikipedia page" I would
be happy to hear it and change the short description, otherwise I can
try to use something with "era name" or keep the "regnal" one.

In the long description I would continue to use "regnal date" and add
"release date", to ease searching.

Bug#877444: python3-docutils: rst2man warning on multiparagraph copyright field that is correctly recognised

[Elena ``of Valhalla'']

Package: python3-docutils
Version: 0.14+dfsg-1
Severity: minor

Dear Maintainer,

Trying to convert the attached file to a manpage I get a warning:

   debdate.1.rst:11: (WARNING/2) Cannot extract compound bibliographic field 
"Copyright".

This probably comes from line 460 in the file:
/usr/lib/python3/dist-packages/docutils/transforms/frontmatter.py

>From the specs it isn't clear whether multiple paragraphs are supported
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#bibliographic-fields
so it could be an error in the source document.
The reason I'm opening this bug, however, is that in the resulting man
page the second paragraph is correctly recognised and rendered, so the
warning is somewhat misleading.

Since the generated manpage includes the warning, a workaround is to
build it with --report=error to silence warnings.

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

Kernel: Linux 4.12.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-docutils depends on:
ii  docutils-common  0.14+dfsg-1
ii  python3  3.5.3-3
ii  python3-roman2.0.0-2

Versions of packages python3-docutils recommends:
ii  libpaper-utils1.1.24+nmu5
ii  python3-pil   4.2.1-1
ii  python3-pygments  2.2.0+dfsg-1

Versions of packages python3-docutils suggests:
ii  docutils-doc0.14+dfsg-1
ii  fonts-linuxlibertine [ttf-linux-libertine]  5.3.0-2
ii  texlive-lang-french 2017.20170818-1
ii  texlive-latex-base  2017.20170818-1
ii  texlive-latex-recommended   2017.20170818-1

-- no debconf information
=
 debdate
=


 Convert Gregorian dates to Debian Regnal dates


:Author: valha...@trueelena.org
:Date:   2017-07-14
:Copyright:  2017 Elena Grandi

 Released under the terms of the Do What The Fuck You
 Want To Public License, Version 2, as published by Sam
 Hocevar. http://www.wtfpl.net/
:Manual section: 1

SYNOPSIS


debdate [-h] [-d DATE | -s SECONDS] {test} ...

DESCRIPTION
===

``debdate`` is a fundamental tool for anybody who follows the debian
calendar where the years are named after the current stable release.

OPTIONS
===

  -h, --help   show this help message and exit
  -d DATE, --date DATE A gregorian date
  -s SECONDS, --seconds SECONDSA date as seconds from the Unix Epoch

EXAMPLES


``debdate``

Print the debian regnal date for today.

``debdate -d 2017-06-18``

Print the debian regnal date for the day of the release of Stretch.

``debdate -s 1497736800``

Print the same date as above.

``debdate -d 'Jul 18 2017'``

Print again the same date as above, passed in an illogical format.
Any string that is recognised as a valid date by dateutil can be used.

SEE ALSO


* date(1)
* ddate(1)
* https://dateutil.readthedocs.io/en/stable/

Bug#877430: RFS: debdate/0.20170714-1 [ITP] -- Convert Gregorian dates to Debian Regnal dates

[Elena ``of Valhalla'']

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "debdate"

* Package name: debdate
  Version : 0.20170714-1
  Upstream Author : Elena Grandi 
* URL : http://git.trueelena.org/cgit.cgi/software/debdate/about/
* License : WTFPL
  Section : utils

It builds those binary packages:

  debdate- Convert Gregorian dates to Debian Regnal dates

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/debdate/debdate_0.20170714-1.dsc

The packaging is currently on collab-maint:

  https://anonscm.debian.org/git/collab-maint/debdate.git (clone)
  https://anonscm.debian.org/cgit/collab-maint/debdate.git (browse)

Changes since the last upload:

This would be the first upload, closing the ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877404

Regards,
 Elena Grandi

Bug#877404: ITP: debdate -- Convert Gregorian dates to Debian Regnal dates

[Elena ``of Valhalla'']

Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla'' <valhall...@trueelena.org>

* Package name: debdate
  Version : 0.20170714
  Upstream Author : Elena Grandi <valha...@trueelena.org>
* URL : http://git.trueelena.org/cgit.cgi/software/debdate/
* License : WTFPL
  Programming Lang: Python
  Description : Convert Gregorian dates to Debian Regnal dates

Displays the Debian Regnal date of a given date, where the years are
named after the current stable release.

This is, admittely, a program or very minor importance, but also one
that should take very little effort to develop and maintain.
AFAIK there are many alternative programs to show dates the command
line, but none of them use the *proper* calendar like this one does.

Considering the topic, I believe that all of the potential users will
appreciate having a package, even if running the program from source is
easy.

I've already checked that, by using data from distro-info-data, it will
give the right answers even on the .0 release of a new stable, with no
additional effort from myself nor the project.

I plan to maintain this package in collab-maint, with the aim to move it
to PAPT as soon as the svn -> git migration is done.

I will need a sponsor for the first upload(s), but I'm a DM and can
receive upload permission for the (sporadical) updates.

Bug#786402: New repository on github

[Elena ``of Valhalla'']

On 2017-09-20 at 11:04:00 +0200, Carlo Stemberger wrote:
> what's the difference between the two projects? Why the original author has
> forked the code? I can't find any news about the reason.

I couldn't find a clear description of the situation either; I've posted
the links with the relevant info that I could find, but I agree that
they don't have the complete picture.

My understanding is that the original author will no longer develop the
program (at least not as a FLOSS project) and that the only surviving
FLOSS project is the forked one, but I may be mistaken.

The name change also seems to be done more as a courtesy to the original
author than for a pressing need to distinguish two project, but again, I
only know what I found on the forum and linked above.

-- 
Elena ``of Valhalla''

Bug#876681: RFH: rst2pdf -- ReportLab-based reStructuredText to PDF renderer

[Elena ``of Valhalla'']

Package: wnpp
Severity: normal

I request assistance with maintaining the rst2pdf package.

The package description is:
 The usual way of creating PDF files from reStructuredText is by going through
 LaTeX. This tool provides an alternative by producing PDF directly using the
 ReportLab library.

rst2pdf currently only supports python2 (#826908); there was an effort
from upstream to resume developement and an issue to track supporting
python3, but apparently they have stopped again in 2016.

Since sooner or later python2 will be dropped from Debian, rst2pdf will
have to follow, unless somebody cares about it enought to solve the
situation.

I believe that rst2pdf is currently being used as a build-dependency by
the following packages, whose maintainers I'm cc-ing:

* apcupsd
* davical
* pdal

Right now, I'm not really using this package, so in case there is a need
for an upstream fork I'm not the right person do do it, but if upstream
resumes working or there is a new upstream I would be glad to continue
maintaining the package.

Bug#876679: RFH: pyrrd

[Elena ``of Valhalla'']

Package: wnpp
Severity: normal

pyrrd, a python interface for RRD, currently only supports python2
(#830790) and its upstream developement seems to have stopped quite some
years ago.

Since sooner or later python2 will be dropped from Debian, pyrrd will
follow, unless somebody cares about it enough to solve the situation,
probably by forking upstream and continuing developement.

Right now I'm not really using it, so I don't think I'm the right person
to start doing upstream work, altought I would be glad to continue
working on the packaging.

Currently in debian there is just one open (upstream) bug with an easy
workaround, so I don't think there is a pressing need for a premature
removal of this package, but I'd expect that it's better to start
forking upstream early instead of under a close deadline.

Bug#874721: [pkg-gnupg-maint] Bug#874721: gnupg: the option --debug-quick-random seems to be ignored

[Elena ``of Valhalla'']

On 2017-09-09 at 19:06:10 +0200, Werner Koch wrote:
> Your problem is that the keys are generated by gpg-agent.  Thus you
> would need to use --debug-quick-random in gpg-agent.conf.  However, this
> is not possible because we need to switch libgcrypt into quick random
> mode as early as possible and thus gpg-agent detects it only when given
> on the command line.  Now, gpg-agent is started on demand by gpg and
> thus we need a way to put it on the command line.  If you put this into
> the gpg.conf [...]

Thanks for your quick answer!

This probably gives me a solution for python-gnupg (I'm looking at the
options to see what's easier to implement and will do another upload).

As for this bug, I don't know if there is a place to add this info as
documentation, otherwise for me it can just be closed.

-- 
Elena ``of Valhalla''

Bug#876390: minetest-mod-homedecor: Chrashes at startup with "attempt to index global 'unifieddyes' (a nil value)"

[Elena ``of Valhalla'']

Package: minetest-mod-homedecor
Version: 0.4.16-2
Severity: important

Dear Maintainer,

Thanks for your quick fix for 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875984

Unluckily, installing version 0.4.16-2 and opening a world where
homedecor was enabled resulted in a crash with the following traceback:

2017-09-21 18:16:12: WARNING[Main]: NodeDefManager: Ignoring CONTENT_IGNORE 
redefinition
2017-09-21 18:16:12: WARNING[Main]: Undeclared global variable 
"unifieddyes" accessed at 
...share/games/minetest/mods/homedecor/lrfurn/longsofas.lua:45
2017-09-21 18:16:12: ERROR[Main]: ModError: Failed to load and run script 
from /usr/share/games/minetest/mods/homedecor/lrfurn/init.lua:
2017-09-21 18:16:12: ERROR[Main]: 
...share/games/minetest/mods/homedecor/lrfurn/longsofas.lua:45: attempt to 
index global 'unifieddyes' (a nil value)
2017-09-21 18:16:12: ERROR[Main]: stack traceback:
2017-09-21 18:16:12: ERROR[Main]:   
...share/games/minetest/mods/homedecor/lrfurn/longsofas.lua:45: in main chunk
2017-09-21 18:16:12: ERROR[Main]:   [C]: in function 'dofile'
2017-09-21 18:16:12: ERROR[Main]:   
/usr/share/games/minetest/mods/homedecor/lrfurn/init.lua:69: in main chunk
2017-09-21 18:16:12: ERROR[Main]: Check debug.txt for details.

I could reproduce this by creating a world and enabling just homedecor
and unifieddyes.

I don't know if it's related, but I've noticed that both homedecor_i18n
and unifieddyes have an optional dependency on intllib, which however I
couldn't find as a package (I may have missed it if it's not named in
the obvious way as minetest-mod-intllib, however).

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

Kernel: Linux 4.12.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages minetest-mod-homedecor depends on:
ii  minetest  0.4.16+repack-4
ii  minetest-mod-unifieddyes  0.4.15-1
ii  minetest-server   0.4.16+repack-4

minetest-mod-homedecor recommends no packages.

minetest-mod-homedecor suggests no packages.

-- no debconf information

Bug#786402: New repository on github

[Elena ``of Valhalla'']

More info.

The original author has left_ the project, it has been migrated over
to github_ and they are thinking to change_ the name.

.. _left: https://forum.valentina-project.org/t/i-am-leaving-the-project/1628
.. _github: https://github.com/valentina-project/vpo2
.. _change: https://forum.valentina-project.org/t/new-name-for-valentina/1839
-- 
Elena ``of Valhalla''

Bug#875984: minetest-mod-homedecor: Fails to load: missing dependency on homedecor_i18n

[Elena ``of Valhalla'']

Package: minetest-mod-homedecor
Version: 0.4.16-1
Severity: normal

Dear Maintainer,


I've installed minetest and a few mods including minetest-mod-homedecor
on a clean computer; starting a world where homedecor is enabled now
leads to the following errors:

ERROR[Main]: mod "building_blocks" has unsatisfied dependencies:  
"homedecor_i18n"
ERROR[Main]: mod "chains" has unsatisfied dependencies:  "homedecor"
ERROR[Main]: mod "computer" has unsatisfied dependencies:  "homedecor_i18n"
ERROR[Main]: mod "fake_fire" has unsatisfied dependencies:  "homedecor"
ERROR[Main]: mod "homedecor" has unsatisfied dependencies:  "unifieddyes" 
"homedecor_i18n" "building_blocks"
ERROR[Main]: mod "inbox" has unsatisfied dependencies:  "homedecor_i18n"
ERROR[Main]: mod "itemframes" has unsatisfied dependencies:  
"homedecor_i18n"
ERROR[Main]: mod "lavalamp" has unsatisfied dependencies:  "homedecor_i18n" 
"unifieddyes"
ERROR[Main]: mod "lrfurn" has unsatisfied dependencies:  "homedecor_i18n" 
"unifieddyes"
ERROR[Main]: mod "plasmascreen" has unsatisfied dependencies:  "homedecor"

I can't seem to find homedecor_i18n among the available mods in the
configuration screen.

(please ignore the mentions of unifieddyes: this was a test world with
just homedecor configured, but I tried enabling unifieddyes and it does
not solve the issue).

Thanks in advance

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

Kernel: Linux 4.12.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages minetest-mod-homedecor depends on:
ii  minetest  0.4.16+repack-4
ii  minetest-mod-unifieddyes  0.4.15-1
ii  minetest-server   0.4.16+repack-4

minetest-mod-homedecor recommends no packages.

minetest-mod-homedecor suggests no packages.

-- no debconf information

Bug#874791: gajim: Crash on startup with python-gnupg >= 0.4 without gpg1

[Elena ``of Valhalla'']

On 2017-09-14 at 09:29:48 +0200, Antonio Ospite wrote:
> A workaround is to install the gnupg2 package (if this is your preferred
> solution then gajim should depend on the gnupg2 package), but I am not
> sure this is the right solution, maybe setting GPG_BINARY = 'gpg' is
> better? The original reporter of this bug was suggesting this too.
> 
> IIUC the versioned dependency on python-gnupg (>= 0.4.1) should assure
> that the installed gnupg package (as an indirect dependency) is indeed
> version 2.x and that the 'gpg' binary is indeed gpg2.
> 
> Ideally python-gnupg could make this clearer adding a versioned
> dependency on gnupg (>= 2) but it's not a big deal.

Actually, python-gnupg is (now¹) happy to run with either versions of
gnupg, and will try its best to provide the same api no matter what the
backend is.
Now that I think about it giving it a dependency on 'gnupg|gnupg1' may
just be the right thing to do to make this situation explicit.

If GPG_BINARY isn't used elsewhere in the gajim code (something that I
haven't checked yet) IMHO it can just be dropped, and python_gnupg
called without a binary name, so that it will use whatever gpg is the
default and (hopefully :) ) work out of the box even if that changes.

Otherwise, if gajim is forcing the use of one specific gpg version
through GPG_BINARY I believe that the right thing to do would be to add
an explicit dependency to the package that provides that version, as
puython-gnupg itself can't be trusted to provide it (as it has happened
in this case)

¹ the previous version could run with gnupg 2.0, but failed with gnupg
2.1, but that has been fixed upstream.

-- 
Elena ``of Valhalla''

Bug#659905: Short key collisions

[Elena ``of Valhalla'']

This ticket has remained open for a few years; nowadays short-ids are
getting more and more deprecated, with the interfaces moving forwards
towards using long-ids and full fingerprint.

Could the bug be closed as no longer really relevant in the way gnupg
should be currently used?

> I find strange that when I ask for a key what is returned is actually a
> *master* key as well as all the possible *subkeys*.  This obviously
> means that the possibility of a collision is bigger.

Personally I find it convienent to be able to download a key by giving
the id of a subkey as that is what is displayed e.g. by mutt when an
email is signed by an unavailable key.

-- 
Elena ``of Valhalla''

Bug#874721: gnupg: the option --debug-quick-random seems to be ignored

[Elena ``of Valhalla'']

Package: gnupg
Version: 2.1.18-6
Severity: normal

Dear Maintainer,

When running tests for python-gnupg (e.g. at build time) I use the
option --debug-quick-random to use /dev/urandom instead of /dev/random
to be able to complete the tests in a reasonable time (as it is
generating keys that will be dropped later).

With gnupg 1.4 the corresponding option --quick-random had the desidered
effect, but since the move gnupg 2.1 this seems to be ignored, to the
serious detriment of build times (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874720 )

This can be reproduced by monitoring
/proc/sys/kernel/random/entropy_avail while generating keys, especially
on a machine without entropy generating tokens or the like.

Please let me know if I'm using the option in the wrong way, in which
case this would become a whishlist bug asking for better documentation.

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.18-6
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u1
ii  libgcrypt201.7.6-2+deb9u1
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.16.2-5
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnupg recommends:
ii  dirmngr 2.1.18-6
ii  gnupg-l10n  2.1.18-6

Versions of packages gnupg suggests:
ii  parcimonie  0.10.2-4
pn  xloadimage  

-- no debconf information

Bug#483724: transition has happened

[Elena ``of Valhalla'']

The transition to gnupg 2.1 as the default gpg has happened and has
reached stable (stretch): could this bug be closed?
-- 
Elena ``of Valhalla''

Bug#874720: python-gnupg: Blocks on lack of entropy during build with gnupg 2.1 (potential FTBFS on servers etc.)

[Elena ``of Valhalla'']

Source: python-gnupg
Version: 0.4.1-1
Severity: normal

Since I've turned the package back to use gpg by default (now pointing
to gnupg 2.1) the option to use urandom for key generation doesn't seem
to do anything, and thus running the package tests (e.g. at build time)
can take a lot of time (easily hours), depending on the entropy
availability on the machine where it is built.

Keeping the severity normal because Debian infrastructure has been able
to build the package (from a source-only upload) and users are probably
also able to build it as long as they don't set a timeout.

Bug#873174: Ticket on conversations

[Elena ``of Valhalla'']

This is a relevant issue on Conversations, which I believe can give
more informations

https://github.com/siacs/Conversations/issues/2612
-- 
Elena ``of Valhalla''

Bug#868891: witalian: /var/lib/dictionaries-common/wordlist/witalian is missing

[Elena ``of Valhalla'']

Package: witalian
Version: 1.8
Severity: normal

Dear Maintainer,

Updating a system from jessie to stretch dictionaries-common is
complaining that italian is not a valid value; this seems to be caused
by the fact that the new version of witalian is no longer providing the
file /var/lib/dictionaries-common/wordlist/witalian.

I've checked and other similar packages are still providing the
corresponding file (e.g. wfrench)

Bug#852261: upstream patch

[Elena ``of Valhalla'']

I'm attaching a quilt patch that applies to version 0.5.0-0.1 with the
two commits from the upstream repo that solve the issue.

I've tried to build it: it does and it seems to be working fine on my
armhf board.

I'm not attaching a full debdiff because as far as I understand it
upstream is only waiting for confirmation from Jack Henschel that the
code is also working for him before closing the issue, and then it would
be available in the next upstream release, which I expect is probably
worth waiting for (at least for a while) at this stage, since it's going
to end up in buster anyway.

I did build on a machine with an UTF-8 locale, however.
-- 
Elena ``of Valhalla''
Index: profanity-0.5.0/src/common.c
===
--- profanity-0.5.0.orig/src/common.c	2016-09-15 23:53:43.0 +0200
+++ profanity-0.5.0/src/common.c	2017-05-29 22:21:35.722237804 +0200
@@ -509,13 +509,25 @@
 return *result;
 }
 
-if (g_str_has_prefix([offset], needle)) {
+gchar *haystack_curr = g_utf8_offset_to_pointer(haystack, offset);
+if (g_str_has_prefix(haystack_curr, needle)) {
 if (whole_word) {
-char *prev = g_utf8_prev_char([offset]);
-char *next = g_utf8_next_char([offset] + strlen(needle) - 1);
-gunichar prevu = g_utf8_get_char(prev);
-gunichar nextu = g_utf8_get_char(next);
-if (!g_unichar_isalnum(prevu) && !g_unichar_isalnum(nextu)) {
+gchar *needle_last_ch = g_utf8_offset_to_pointer(needle, g_utf8_strlen(needle, -1)- 1);
+int needle_last_ch_len = mblen(needle_last_ch, MB_CUR_MAX);
+
+gunichar before = NULL;
+gchar *haystack_before_ch = g_utf8_find_prev_char(haystack, haystack_curr);
+if (haystack_before_ch) {
+before = g_utf8_get_char(haystack_before_ch);
+}
+
+gunichar after = NULL;
+gchar *haystack_after_ch = g_utf8_find_next_char(haystack_curr + strlen(needle) - needle_last_ch_len, NULL);
+if (haystack_after_ch) {
+after = g_utf8_get_char(haystack_after_ch);
+}
+
+if (!g_unichar_isalnum(before) && !g_unichar_isalnum(after)) {
 *result = g_slist_append(*result, GINT_TO_POINTER(offset));
 }
 } else {
@@ -523,8 +535,9 @@
 }
 }
 
-if (haystack[offset+1] != '\0') {
-*result = prof_occurrences(needle, haystack, offset+1, whole_word, result);
+offset++;
+if (g_strcmp0(g_utf8_offset_to_pointer(haystack, offset), "\0") != 0) {
+*result = prof_occurrences(needle, haystack, offset, whole_word, result);
 }
 
 return *result;
Index: profanity-0.5.0/tests/unittests/test_common.c
===
--- profanity-0.5.0.orig/tests/unittests/test_common.c	2016-09-15 23:53:43.0 +0200
+++ profanity-0.5.0/tests/unittests/test_common.c	2017-05-29 22:21:29.225862420 +0200
@@ -444,6 +444,13 @@
 assert_true(_lists_equal(prof_occurrences("boothj5", "boothj5, hi",  0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
 g_slist_free(expected); expected = NULL;
 
+expected = g_slist_append(expected, GINT_TO_POINTER(0));
+assert_true(_lists_equal(prof_occurrences("我能吞下玻璃而", "我能吞下玻璃而",  0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
+assert_true(_lists_equal(prof_occurrences("我能吞下玻璃而", "我能吞下玻璃而 hi",   0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
+assert_true(_lists_equal(prof_occurrences("我能吞下玻璃而", "我能吞下玻璃而: hi",  0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
+assert_true(_lists_equal(prof_occurrences("我能吞下玻璃而", "我能吞下玻璃而, hi",  0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
+g_slist_free(expected); expected = NULL;
+
 expected = g_slist_append(expected, GINT_TO_POINTER(6));
 assert_true(_lists_equal(prof_occurrences("boothj5", "hello boothj5",0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
 assert_true(_lists_equal(prof_occurrences("boothj5", "hello boothj5 there",  0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
@@ -451,6 +458,12 @@
 g_slist_free(expected); expected = NULL;
 
 expected = g_slist_append(expected, GINT_TO_POINTER(6));
+assert_true(_lists_equal(prof_occurrences("我能吞下玻璃而", "hello 我能吞下玻璃而",0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
+assert_true(_lists_equal(prof_occurrences("我能吞下玻璃而", "hello 我能吞下玻璃而 there",  0, TRUE, ), expected)); g_slist_free(actual); actual = NULL;
+assert_true(_lists_equal(prof_occurrences("我能吞下玻璃而", "heyy @我能吞下玻璃而, there", 0, TRUE, ), expected)); 

Bug#853052: widelands: Wrong names for some buildings (e.g. Ranger's Hut)

[Elena ``of Valhalla'']

Package: widelands
Version: 1:19+repack-2
Severity: important

Dear Maintainer,

After the save format change, I've restarted playing the widelands
campaigns from the beginning and got stuck on the start of the first one
at not being able to build a Ranger's Hut, the only ones available being
Quarry, Woodcutter's Hut and Fishermanr's Hut (sic).

Trying to start from the tutorial (where all of the barbarian building
are available, and the actual Fisherman's Hut is there), I've then
realized that the Fishermanr's Hut icon was actually the one of the
Ranger's Hut, and that only the name was wrong.

Looking around further, I also found that the basic Coal Mine is called
Deep Coal Mine (but works as the right one, and can then be updated to
Deep Coal Mine as it should).

I'm giving this an important severity because a new player wouldn't know
the icon for a Ranger's Hut in advance, and thus would easily get stuck
and be unable to learn the basics of the game.

I will now play a bit further, *purely* for QA reasons, and I will add
to this bug if I notice other wrong names.

(just before sending this bug I realised that maybe this was because of
the en_GB locale, and indeed setting it to en_US I had the correct
names).

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages widelands depends on:
ii  fonts-dejavu-core 2.37-1
ii  fonts-dejavu-extra2.37-1
ii  fonts-freefont-ttf20120503-6
ii  fonts-hosny-amiri 0.107-1
ii  fonts-lklug-sinhala   0.6-3
ii  fonts-nakula  1.0-3
ii  fonts-wqy-microhei0.2.0-beta-2
ii  libboost-regex1.62.0  1.62.0+dfsg-4
ii  libboost-test1.62.0   1.62.0+dfsg-4
ii  libc6 2.24-8
ii  libgcc1   1:6.2.1-5
ii  libgl1-mesa-glx [libgl1]  13.0.3-1
ii  libglew2.02.0.0-3
ii  libicu57  57.1-5
ii  libminizip1   1.1-8
ii  libpng16-16   1.6.28-1
ii  libsdl2-2.0-0 2.0.5+dfsg1-2
ii  libsdl2-image-2.0-0   2.0.1+dfsg-2+b2
ii  libsdl2-mixer-2.0-0   2.0.1+dfsg1-1
ii  libsdl2-net-2.0-0 2.0.1+dfsg1-2
ii  libsdl2-ttf-2.0-0 2.0.14+dfsg1-1
ii  libstdc++66.2.1-5
ii  widelands-data1:19+repack-2
ii  zlib1g1:1.2.8.dfsg-4

widelands recommends no packages.

widelands suggests no packages.

-- no debconf information

Bug#737106: Ping?

[Elena ``of Valhalla'']

On 2017-01-21 at 23:36:30 +0100, gregor herrmann wrote:
> > On the PC using right click to go through the states in
> > the opposite direction looks to me like a natural interface to work
> > around the problem (and it would work on the Pandora / Pyra, even if
> > it's a bit less natural); 
> 
> Implemented by my co-author Philipp in Git.

tried, it works nicely!

When doing that in the Favourites view it is a bit annoying that the
view gets refreshed and the list folded back into the list of times, but
that can be tolerated, especially this close to FOSDEM :)

> > I'm not sure how well it would work on other
> > mobile devices (maybe long tap? I don't know how easy/hard it would be
> > to do it with QT).
> 
> AFAIK at least on Maemo it's the system qt which re-maps right-click
> to long tap. So I hope this will Just Work™ (have to test it
> tomorrow).

good!

-- 
Elena ``of Valhalla''

Bug#737106: Ping?

[Elena ``of Valhalla'']

On 2017-01-21 at 00:59:18 +0100, gregor herrmann wrote:
> > What is not clear to me after thinking a bit about this new feature
> > is how it would work from a UI point of view: Should this be a third
> > icon/button next to alarm/clock and favourite/star, and should the
> > favourite-star turn into a tri-state button (grey/pink/red or
> > grey/half-red/full-red for no-favourite, soft-favourite,
> > hard-favourite)? 

I've been thinking a bit about it without reaching any definite idea

> It looks like we something working in git; we finally went for the
> tri-state solution if the fav button (no / weak / strong).
> 
> I'll try to get something out tomorrow; unless you want to try and
> build from git yourself to take a look:
> http://git.toastfreeware.priv.at/toast/confclerk.git

That's great, thanks!

I've only stumbled on one UI issue: when something is half-starred and
you're browsing it from the favourites view there is no way to turn it
into a full star, because clicking on the star goes through the
unstarred phase and removes it from the view.

On the PC using right click to go through the states in
the opposite direction looks to me like a natural interface to work
around the problem (and it would work on the Pandora / Pyra, even if
it's a bit less natural); I'm not sure how well it would work on other
mobile devices (maybe long tap? I don't know how easy/hard it would be
to do it with QT).

Anyway, you've just made my fosdem experience MUCH smoother, THANKS!

-- 
Elena ``of Valhalla''

Bug#838631: Maybe related to #833930

[Elena ``of Valhalla'']

On 2016-11-28 at 20:58:42 +0100, Elena ``of Valhalla'' wrote:
> I'm not sure it is related, but on both computers where I've had this
> issue I'm also suffering from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833930

I've just tried again, and apparently on my computer it is fixed.

I will try with the other computers later and report back if I find
anything significant.

-- 
Elena ``of Valhalla''

Bug#737106: Ping?

[Elena ``of Valhalla'']

is it too late to remind you about this in time for this year's FOSDEM?

(being this close to the freeze probably doesn't help, but last year I
was reminded of this bug too late for a ping)
-- 
Elena ``of Valhalla''

Bug#850023: ImportError when importing ruamel.yaml

[Elena ``of Valhalla'']

On 2017-01-06 at 22:51:55 +, Chris Lamb wrote:
> > ImportError when importing ruamel.yaml
> 
> So, the binary package is missing a Depends on `python-typing`.

uh, thanks, I didn't think to check of typing for a backport to py2.

That's indeed easy to workaround

-- 
Elena ``of Valhalla''

Bug#838164: New upstream from the git repository

[Elena ``of Valhalla'']

X-Debbugs-CC: deba...@debian.org,j...@openmailbox.org

I've noticed that in the git repository on 

https://anonscm.debian.org/cgit/collab-maint/profanity.git/

there is a branch with the packaging of the new upstream release done by
Jack Henschel (added to the CCs)

Could it be used to provide an updated version of the package in time
before the freeze? (Altought, I notice that it creates new packages, so
it may already be too late for that).

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#850023: ImportError when importing ruamel.yaml

[Elena ``of Valhalla'']

Package: python-ruamel.yaml
Version: 0.13.4-1
Severity: grave

Importing ruamel.yaml fails with the following traceback:

$ bpython
bpython version 0.16 on top of Python 2.7.13 /usr/bin/python
>>> import ruamel.yaml
Traceback (most recent call last):
  File "", line 1, in 
import ruamel.yaml
  File "/usr/lib/python2.7/dist-packages/ruamel/yaml/__init__.py", line 81, 
in 
from ruamel.yaml.main import *  # NOQA
  File "/usr/lib/python2.7/dist-packages/ruamel/yaml/main.py", line 6, in 

from typing import List, Set, Dict, Tuple, Optional, Union, BinaryIO, 
IO, Any  # NOQA
ImportError: No module named typing

Note that doing the same under python3 works, this only applies to the
python2 version:

$ bpython3
bpython version 0.16 on top of Python 3.5.2+ /usr/bin/python3
>>> import ruamel.yaml
>>>

(Using bpython is not relevant: the same error occours with the standard
python interpreter)
-- 
Elena ``of Valhalla''