Bug#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Jochen Sprickerhof]

Control: tags 989344 + patch
Control: tags 989344 + pending


Dear maintainer,

I've prepared an NMU for ogre-1.12 (versioned as 1.12.10+dfsg2-1.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

I've chosen a short delay as this needs to pass the NEW queue, hope that 
is fine. The release team said would still consider this for bullseye.


Regards.

diff -Nru ogre-1.12-1.12.10+dfsg2/debian/changelog ogre-1.12-1.12.10+dfsg2/debian/changelog
--- ogre-1.12-1.12.10+dfsg2/debian/changelog	2021-01-01 09:04:19.0 +0100
+++ ogre-1.12-1.12.10+dfsg2/debian/changelog	2021-06-12 16:37:07.0 +0200
@@ -1,3 +1,10 @@
+ogre-1.12 (1.12.10+dfsg2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library package to match Soname (Closes: #989344)
+
+ -- Jochen Sprickerhof   Sat, 12 Jun 2021 16:37:07 +0200
+
 ogre-1.12 (1.12.10+dfsg2-1) unstable; urgency=medium
 
   [ Simon Schmeisser ]
diff -Nru ogre-1.12-1.12.10+dfsg2/debian/control ogre-1.12-1.12.10+dfsg2/debian/control
--- ogre-1.12-1.12.10+dfsg2/debian/control	2021-01-01 09:04:19.0 +0100
+++ ogre-1.12-1.12.10+dfsg2/debian/control	2021-06-12 16:37:00.0 +0200
@@ -39,7 +39,7 @@
 Section: libdevel
 Architecture: any
 Depends: ${misc:Depends},
- libogre-1.12 (= ${binary:Version})
+ libogre1.12.10 (= ${binary:Version})
 Conflicts: libogre-dev, libogre-1.8-dev, libogre-1.9-dev
 Suggests: ogre-1.12-doc
 Description: 3D Object-Oriented Graphics Rendering Engine (development files)
@@ -52,12 +52,14 @@
  .
  This package contains the headers needed to develop with OGRE.
 
-Package: libogre-1.12
+Package: libogre1.12.10
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Breaks: libogre-1.12 (<<1.12.10+dfsg2-1.1)
+Replaces: libogre-1.12 (<<1.12.10+dfsg2-1.1)
 Description: 3D Object-Oriented Graphics Rendering Engine (libraries)
  OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible
  3D engine written in C++ designed to make it easier and more intuitive for
diff -Nru ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.install ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.install
--- ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.install	2021-01-01 09:04:19.0 +0100
+++ ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.install	1970-01-01 01:00:00.0 +0100
@@ -1,5 +0,0 @@
-usr/lib/*/libOgre*.so.*
-usr/lib/*/OGRE/*.so.*
-usr/share/OGRE/*.cfg
-usr/share/OGRE/GLX_backdrop.png
-usr/share/OGRE/Media/*
diff -Nru ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.install ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.install
--- ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.install	1970-01-01 01:00:00.0 +0100
+++ ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.install	2021-06-12 16:08:14.0 +0200
@@ -0,0 +1,5 @@
+usr/lib/*/libOgre*.so.*
+usr/lib/*/OGRE/*.so.*
+usr/share/OGRE/*.cfg
+usr/share/OGRE/GLX_backdrop.png
+usr/share/OGRE/Media/*
diff -Nru ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.lintian-overrides ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.lintian-overrides
--- ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.lintian-overrides	2021-01-01 09:04:19.0 +0100
+++ ogre-1.12-1.12.10+dfsg2/debian/libogre-VERSION.lintian-overrides	1970-01-01 01:00:00.0 +0100
@@ -1,3 +0,0 @@
-package-name-doesnt-match-sonames *
-# Bug reported #690084, no simple way to untangle
-embedded-library usr/lib/*/OGRE*/RenderSystem_GL.so.*: glew
diff -Nru ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.lintian-overrides ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.lintian-overrides
--- ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.lintian-overrides	1970-01-01 01:00:00.0 +0100
+++ ogre-1.12-1.12.10+dfsg2/debian/libogreVERSION.lintian-overrides	2021-06-12 16:08:14.0 +0200
@@ -0,0 +1,3 @@
+package-name-doesnt-match-sonames *
+# Bug reported #690084, no simple way to untangle
+embedded-library usr/lib/*/OGRE*/RenderSystem_GL.so.*: glew
diff -Nru ogre-1.12-1.12.10+dfsg2/debian/rules ogre-1.12-1.12.10+dfsg2/debian/rules
--- ogre-1.12-1.12.10+dfsg2/debian/rules	2021-01-01 09:04:19.0 +0100
+++ ogre-1.12-1.12.10+dfsg2/debian/rules	2021-06-12 16:37:07.0 +0200
@@ -25,8 +25,7 @@
 
 
 # Use this variable to define the particular version of OGRE that we're building
-OGRE_VERSION=1.12
-OGRE_VERSION_ABI_CHANGE=$(OGRE_VERSION)
+OGRE_SOVERSION=1.12.10
 
 OGRE_CHANGELOG = Docs/ChangeLog.md
 
@@ -67,8 +66,8 @@
 
 override_dh_install-arch:
 # Copy files from template for this particular version
-	cp -f debian/libogre-VERSION.install debian/libogre-$(OGRE_VERSION_ABI_CHANGE).install
-	cp -f debian/libogre-VERSION.lintian-overrides debian/libogre-$(OGRE_VERSION_ABI_CHANGE).lintian-overrides
+	cp -f debian/libogreVERSION.install debian/libogre$(OGRE_SOVERSION).install
+	cp -f debian/libogreVERSION.lintian-overrides debian/libogre$(OGRE_SOVERS

Bug#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Jochen Sprickerhof]

Hi Olek,

* Olek Wojnar  [2021-06-13 15:15]:

Are you also planning to file an unblock bug or would you like Simon (or
me) to take care of that?


I'm happy to take care of it.


On Sat, Jun 12, 2021 at 3:27 PM  wrote:


I'm sorry for messing this up, this is my first official debian package.
Your patch looks good. Could you please also open a MR on salsa for it? Or
commit it right away if you have the permissions.
I'm currently on vacation but can do further cleanup if required and an
update to 1.12.12 starting 25.06. when I'm back home


Hi Simon, I guess your mail got blocked by SPF, sorry I should really 
look into that at some point..


No worries with your package, I remember asking the release team for 
last minute changes in my first packages as well. I will open a MR with 
the change. Enjoy your vacation!


Just to be sure, note that Ogre 1.12.12 has a new Soversion so you need 
to change the package name and do a library transition (once bullseye is 
released). Please upload new versions only to experimental for now.



As Simon's sponsor, I'd like to point out that his packaging was rather
reasonable for a typical library. It is *extremely unusual* for a package
to lose backwards-compatibility across _bugfix versions_! As I recall,
upstream notified us of their rather unusual backwards-compatibility policy
quite recently and I believe I recommended to Simon to not make a major
versioning change like that this close to release. I was also not aware at
the time that another package depended on the 1.12.x series of OGRE. So,
for the record, I certainly bear a good part of the responsibility for this
being an issue so close to release.


I agree that library that change the Soname with every release don't 
sound like the best idea. Normally lintian should warn you if library 
and package name don't match, but that's disabled for ogre-1.12. Maybe 
it makes sense to add some documentation to d/Readme.source or tests in 
d/rules so you don't forget next time.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#989064: curl: output of -w accidentally in microseconds

[Jochen Sprickerhof]

Hi Paul,

* Paul Gevers  [2021-06-22 20:54]:

On 22-06-2021 20:43, Bernd Zeimetz wrote:

Any hints before I find them myself are welcome.



are your changes and/or the build output somewhere online?


Sorry, yes:
http://debomatic-amd64.debian.net/distribution#unstable/curl/7.74.0-1.3/buildlog


I guess you've put the patch at the wrong line in d/patches/series:

https://sources.debian.org/src/curl/7.74.0-1.2/debian/patches/series/#L11

see the use of quilt in d/rules:

https://sources.debian.org/src/curl/7.74.0-1.2/debian/rules/#L32

I've attached my version of the NMU which compiles and tests fine. Feel 
free to upload yours instead if you want.


Cheers Jochen
diff --git a/debian/changelog b/debian/changelog
index 1d4fada0..ebe76f7a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+curl (7.74.0-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch bc7ecc7 so curl -w times shown as seconds with
+fractions (Closes: #989064)
+
+ -- Jochen Sprickerhof   Tue, 22 Jun 2021 22:23:35 +0200
+
 curl (7.74.0-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/16-too-_writeout-fix-the-w-time-output-units.patch b/debian/patches/16-too-_writeout-fix-the-w-time-output-units.patch
new file mode 100644
index ..b37797ca
--- /dev/null
+++ b/debian/patches/16-too-_writeout-fix-the-w-time-output-units.patch
@@ -0,0 +1,85 @@
+From: Daniel Stenberg 
+Date: Tue, 15 Dec 2020 08:09:29 +0100
+Subject: =?utf-8?q?too=C4=BA=5Fwriteout=3A_fix_the_-w_time_output_units?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Fix regression from commit fc813f80e1bcac (#6248) that changed the unit
+to microseconds instead of seconds with fractions
+
+Reported-by: 不确定
+Fixes #6321
+Closes #6322
+---
+ src/tool_writeout.c | 22 +++---
+ 1 file changed, 15 insertions(+), 7 deletions(-)
+
+diff --git a/src/tool_writeout.c b/src/tool_writeout.c
+index c12738c..8b9f590 100644
+--- a/src/tool_writeout.c
 b/src/tool_writeout.c
+@@ -106,6 +106,14 @@ static const struct writeoutvar variables[] = {
+0, JSON_NONE}
+ };
+ 
++static void us2sec(FILE *stream, curl_off_t us)
++{
++  curl_off_t secs = us / 100;
++  us %= 100;
++  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU ".%06" CURL_FORMAT_CURL_OFF_TU,
++  secs, us);
++}
++
+ void ourWriteOut(CURL *curl, struct per_transfer *per, const char *writeinfo)
+ {
+   FILE *stream = stdout;
+@@ -190,41 +198,41 @@ void ourWriteOut(CURL *curl, struct per_transfer *per, const char *writeinfo)
+   case VAR_REDIRECT_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_REDIRECT_TIME_T, ))
+-  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++  us2sec(stream, offinfo);
+ break;
+   case VAR_TOTAL_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_TOTAL_TIME_T, ))
+-  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++  us2sec(stream, offinfo);
+ break;
+   case VAR_NAMELOOKUP_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_NAMELOOKUP_TIME_T,
+  ))
+-  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++  us2sec(stream, offinfo);
+ break;
+   case VAR_CONNECT_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_CONNECT_TIME_T, ))
+-  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++  us2sec(stream, offinfo);
+ break;
+   case VAR_APPCONNECT_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_APPCONNECT_TIME_T,
+  ))
+-  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++  us2sec(stream, offinfo);
+ break;
+   case VAR_PRETRANSFER_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_PRETRANSFER_TIME_T,
+  ))
+-  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++  us2sec(stream, offinfo);
+ break;
+   case VAR_STARTTRANSFER_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_STARTTRANSFER_TIME_T,
+  ))
+-  fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++  us2sec(stream, offinfo);
+ break;
+   case VAR_SIZE_UPLOAD:
+ if(CU

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Jochen Sprickerhof]

* Alejandro Colomar (man-pages)  [2021-06-21 17:35]:
Maybe Debian could write separate pkg-config files, and maybe offer 
them to upstream OpenCV (I offer myself to help write them if you 
decide it's a good idea).


It's easier if you talk to upstream about this directly. Adding them to 
Debian only would be incompatible with other distros and be of limited 
use.


Yes, for linking against the shared libraries, that's all you need: 
link against the module you want.  BUT, if you want to try to link 
against the static library (and now I'm talking from memory (it's been 
a year since I tried to do that, and I don't remember the result, I 
only remember a bunch of errors)), you'll need to know which libraries 
you need, which is the magic of pkg-config.


Static linking should work fine without pkg-config as well, except that 
you would have to list all dependencies, but looking at the opencv4.pc I 
guess they are incomplete anyhow ;).


Cheers Jochen


signature.asc
Description: PGP signature

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Jochen Sprickerhof]

Control: severity -1 wishlist

Hi Alejandro,

* Alejandro Colomar  [2021-06-16 17:31]:

None of them contain the needed pkg-conig files for their use, making
necessary to install 'libopencv', and making useless the separation into
smaller packages.


You don't need to use pkg-config to build against an OpenCV module, just 
running gcc with the flags you need will work. Adjusting severity 
accordingly.



If you can't install that file in every binary package, you may
create a new binary package that only contains the .pc file,
let's say libopencv-pc, and make all packages depend on it.


This sounds overly complicated to me. I think we should move all 
development files into one libopencv-dev if we want to fix this.

But that's choice of the maintainers.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#990164: RM: libopencv-core4.2 -- ROM; superseeded by libopencv-core4.5

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal


Please remove the old opencv 4.2 packages, I believe this should be:

libopencv4.2-java
libopencv4.2-jni
libopencv-calib3d4.2
libopencv-contrib4.2
libopencv-core4.2
libopencv-dnn4.2
libopencv-features2d4.2
libopencv-flann4.2
libopencv-highgui4.2
libopencv-imgcodecs4.2
libopencv-imgproc4.2
libopencv-ml4.2
libopencv-objdetect4.2
libopencv-photo4.2
libopencv-shape4.2
libopencv-stitching4.2
libopencv-superres4.2
libopencv-video4.2
libopencv-videoio4.2
libopencv-videostab4.2
libopencv-viz4.2

I guess these are not automatically remove due to a circular dependency
between libopencv-superres4.2 and libopencv-contrib4.2 (#963890) fixed
in unstable with #979809.

Thanks!

Jochen

Bug#990193: RM: libdart6* -- RoQA; replaced by libdart-*6

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal

Hi,

please clean up dart version 6.9.2-3 from unstable, the binaries where
renamed to match the soname and dak didn't do it automatically.

Thanks!

Jochen

Bug#990194: RM: libphonenumber|geocoding7 -- RoQA; replcaed by libphonenumber|geocoding8

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal

Hi,

please clean up libphonenumber 7.1.0-7 from unstable, it got replaced by
version 8 and dak did not clean up the old libraries.

Thanks!

Jochen

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

Hi,

friendly ping on the sagemath issue as it will be dropped from testing 
on the 18., otherwise.
As far as I read there are a number of proposals (downgrade, ignore test 
results..) besides fixing the tests. I'm happy to help with this but 
leave it to the maintainers how to approach this.


Cheers Jochen

* Tobias Hansen  [2021-05-19 15:01]:

Hi,

On 5/18/21 8:25 PM, Jochen Sprickerhof wrote:


I think there are a number of problems:
- Tests not being executed due to the open file limit ("Killing test" in   the 
log). If you want to use the tests as an indicator if the build   works, you should make 
sure the all tests are executed, otherwise 200   tolerated failures is arbitrary.



I have been struggling with this for quite a while and I don't know how to fix 
it. It comes and goes and does not seem to affect vanilla upstream builds. This 
has impacted progress on the package since one cannot properly work on it when 
the test suite crashes. I tried asking upstream for help here and provided more 
details:

https://groups.google.com/g/sage-packaging/c/1G_3JiIcbvY



- I found a number of segfaults in the tests, like:
  sage -t --long --random-seed=0 src/sage/interfaces/singular.py  # Killed due 
to segmentation fault
- Looking at the amd64 log of the buildd:
  Error: 202 tests failed, up to 200 failures are tolerated
  Yes: 202 tests failed, up to 400 failures are tolerated for rerun
  Success: 192 tests failed, up to 200 failures are tolerated
  does that mean we ran the test twice and it passed the second time   cause 
there where 10 failures less? Can we be sure that this always   succeeds? 192 
is really close to 200.
- I still see cython: not found in the logs, so there are definitely   tests 
broken due to that. Maybe it makes sense to define tests which   are allowed to 
break and other which should succeed?



I agree, segfaults and the cython issue should be fixed. The number of failed 
tests always grows with time when dependencies change and sagemath is not 
adapted accordingly.

Best,

Tobias


signature.asc
Description: PGP signature

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

Hi Julien,

* Julien Puydt  [2021-05-18 07:56]:

1) Upstream itself uses the testsuite in the sense of "shouldn't have
too many failing tests", and it still allows to detect when a build is
utterly broken, so we shouldn't disable it.


Debian doesn't necessarily need to do the same as upstream here.


2) It's not an FTBFS, since the sources actually build to a set of
packages.


I did a diff of the logs from EC2 and RB and found this only on RB:
Killing test src/sage/misc/cython.py
(14 in total)

That's this line:

https://sources.debian.org/src/sagemath/9.2-2/sage/src/sage/doctest/forker.py/#L1999

So if we add a

except: before the finally: we get:

EXCEPTION: [Errno 24] Too many open files

so running the build with a higher file limit:

ulimit -n 10240

will produce:

Error: 1940 tests failed, up to 200 failures are tolerated

Cheers Jochen


signature.asc
Description: PGP signature

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

* Julien Puydt  [2021-05-18 17:47]:

Upstream manages to ship version with no error because they ship
hundreds of deps to an exact version for which they fitted the
testsuite to pass. We ship those deps as separate packages, because
they're actually not sagemath-specific [look at the list, it's pretty
telling : https://people.debian.org/~thansen/debian-sage-status.html ],
so we might not have the exact same version, and that's enough to
trigger artificial failures.

I don't think we'll ever hit zero. At least not while their testsuite
framework is so... so like it is.

If we keep it with an allowed error rate, we detect the package is
*really* broken before shipping ; if we don't, we detect it is broken
after shipping, because it hurts the users and they complain.


I totally understand your point but please keep in mind that we need to 
be able to rebuild packages in Debian as well. If we rebuild a package 
and it FTBFS, we can't publish security updates, for example.
Also if the tests depend on so many external dependencies, changing one 
of them could render sagemath FTBFS due to hitting the test limit. Would 
you then simply bump the limit?



Sagemath is definitely not bug-free, the Debian package for it isn't
bug-free either, but it is working and useful to users, and this
(bringing useful software to users) is what Debian is about.


Totally agreed here, I would like to see sagemath in stable as well.


If I look at the title of this bug, I think "Oh, just patch
src/bin/sage so it calls cython3 and not cython" (see my message #20),
but if you look at the exchange, then it's not clear at all what the
problem actually is.

The buildd logs (
https://buildd.debian.org/status/package.php?p=sagemath=bullseye
), John Cross (message #10), myself (message #25) and the triggered RB
rebuild (message #30) all conclude the package doesn't FTBFS.

I would like to fix the problem, but at that point, I have no clue what
it really is about...


I think there are a number of problems:
- Tests not being executed due to the open file limit ("Killing test" in 
  the log). If you want to use the tests as an indicator if the build 
  works, you should make sure the all tests are executed, otherwise 200 
  tolerated failures is arbitrary.

- I found a number of segfaults in the tests, like:
  sage -t --long --random-seed=0 src/sage/interfaces/singular.py  # Killed due 
to segmentation fault
- Looking at the amd64 log of the buildd:
  Error: 202 tests failed, up to 200 failures are tolerated
  Yes: 202 tests failed, up to 400 failures are tolerated for rerun
  Success: 192 tests failed, up to 200 failures are tolerated
  does that mean we ran the test twice and it passed the second time 
  cause there where 10 failures less? Can we be sure that this always 
  succeeds? 192 is really close to 200.
- I still see cython: not found in the logs, so there are definitely 
  tests broken due to that. Maybe it makes sense to define tests which 
  are allowed to break and other which should succeed?


I am honestly not sure what the best way forward would be but I think 
just downgrading the bug priority is not helping. On the other hand 
given the current freeze policy and what will be the policy in stable, 
what would be your actions if sagemath FTBFS there? Would you say at 
some point it is unfit for a stable release or would you retry the build 
and ignore the errors? Maybe it would make sense to ignore the tests 
results for the version in stable?


Cheers Jochen


signature.asc
Description: PGP signature

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

Hi Julien,

* Julien Puydt  [2021-05-17 09:01]:

I tried to create a testing sbuild and compile sagemath 9.2-2 with it,
and it worked so unless I made a mistake in my setup, something made
that bug go away...

Can someone independently give it a try?


I triggered reproducible-builds again:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagemath.html

Success: 40 tests failed, up to 200 failures are tolerated
Success: 5 tests failed, up to 200 failures are tolerated

so not much changed comparing to two weeks ago and my conclusion still 
holds:


* Jochen Sprickerhof  [2021-05-04 13:22]:

Success: 41 tests failed, up to 200 failures are tolerated
Success: 5 tests failed, up to 200 failures are tolerated

The 200 is set in debian/rules:

https://salsa.debian.org/science-team/sagemath/-/commit/6088e9f2abc7ae99a8d07760ceee6fb6aac7bb54

and sounds a little arbitrary. Sadly the state upstream seems not to 
be much better:


https://github.com/sagemath/sage/tree/9.2

13 failing, 17 cancelled, and 70 successful checks

(I did not look into them.)

So I think the question is rather if the test suite gives an 
appropriate view on the quality of the software. If it does, I assume 
it is not appropriate for a Debian stable release. Contrary if we 
assume the test suite being broken, we could disable it completely 
rather then producing random FTBFS.



Cheers Jochen


signature.asc
Description: PGP signature

Bug#989302: mmdebstrap: busybox-based chroot example misses mktemp

[Jochen Sprickerhof]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: minor

Hi Josch,

I just tried the sub-essential busybox-based chroot example from the man
page on an up to date sid and got:

/var/lib/dpkg/info/base-passwd.postinst: line 1: mktemp: not found

Adding mktemp to the setup-hook ln loop fixes it.

In addition it probably makes sense to add something like this below:

The same can be archived by:
--hook-dir=/usr/share/mmdebstrap/hooks/busybox

Or maybe replace the example?

Similar for the merged-/usr via symlinks example above:

The same can be archived by:
--hook-dir=/usr/share/mmdebstrap/hooks/

Thanks for the great tool!

Cheers Jochen

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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.2.3
ii  perl 5.32.1-4
ii  python3  3.9.2-3

Versions of packages mmdebstrap recommends:
ii  arch-test0.17-1
pn  fakechroot   
ii  fakeroot 1.25.3-1.1
ii  gpg  2.2.27-2
pn  libdistro-info-perl  
ii  mount2.36.1-7
ii  uidmap   1:4.8.1-1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.2.3
pn  apt-transport-tor  
ii  apt-utils  2.2.3
ii  binfmt-support 2.2.1-1
ii  ca-certificates20210119
ii  debootstrap1.0.123
ii  distro-info-data   0.47
ii  dpkg-dev   1.20.9
pn  perl-doc   
pn  proot  
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  

-- no debconf information

Bug#989302: mmdebstrap: busybox-based chroot example misses mktemp

[Jochen Sprickerhof]

* Johannes Schauer Marin Rodrigues  [2021-05-31 16:34]:

I fixed it like this:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/594ea3c72e7af26b680d2bfb696c0271839b731d


Looks good to me, only the merged-/usr may need an extra paragraph as 
the directory is a little non obvious:


--hook-dir=/usr/share/mmdebstrap/hooks/

Alternatively move the setup00-merged-usr.sh to hooks/merged-usr/ maybe?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#989344: rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot open shared object file: No such file or directory

[Jochen Sprickerhof]

Hi Leo,

* Leopold Palomo-Avellaneda  [2021-06-02 08:43]:
It's strange and I think that it's more a misunderstanding from 
upstream than a packaging name error.


I agree with Jochen that for Bullseye with just a binNMU should be 
enough. However, I would like to know if it's binary incompatible 
1.12.5 and 1.12.10. Because, if the are compatible, maybe with just 
patch Ogre to have soversion with major.minor instead complete version 
should be more appropriated.


For that the ABI would need to be the same, let's test:

$ sudo apt install abigail-tools wget

$ wget 
http://snapshot.debian.org/archive/debian/20201120T031928Z/pool/main/o/ogre-1.12/libogre-1.12_1.12.5%2Bdfsg1-1%2Bb1_amd64.deb
$ wget 
http://snapshot.debian.org/archive/debian-debug/20201120T030320Z/pool/main/o/ogre-1.12/libogre-1.12-dbgsym_1.12.5%2Bdfsg1-1%2Bb1_amd64.deb
$ wget 
http://snapshot.debian.org/archive/debian/20200419T033910Z/pool/main/o/ogre-1.12/libogre-1.12-dev_1.12.5%2Bdfsg1-1_amd64.deb
$ wget 
https://deb.debian.org/debian/pool/main/o/ogre-1.12/libogre-1.12_1.12.10+dfsg2-1_amd64.deb
$ wget 
https://deb.debian.org/debian-debug/pool/main/o/ogre-1.12/libogre-1.12-dbgsym_1.12.10+dfsg2-1_arm64.deb
$ wget 
https://deb.debian.org/debian/pool/main/o/ogre-1.12/libogre-1.12-dev_1.12.10+dfsg2-1_amd64.deb

$ dpkg-deb -x libogre-1.12_1.12.5+dfsg1-1+b1_amd64.deb 5
$ dpkg-deb -x libogre-1.12-dbgsym_1.12.5+dfsg1-1+b1_amd64.deb 5
$ dpkg-deb -x libogre-1.12-dev_1.12.5+dfsg1-1_amd64.deb 5
$ dpkg-deb -x libogre-1.12_1.12.10+dfsg2-1_amd64.deb 10
$ dpkg-deb -x libogre-1.12-dbgsym_1.12.10+dfsg2-1_arm64.deb 10
$ dpkg-deb -x libogre-1.12-dev_1.12.10+dfsg2-1_amd64.deb 10

$ abidiff --stat --debug-info-dir1 5/usr/lib/debug/ --debug-info-dir2 
10/usr/lib/debug/ --headers-dir1 5/usr/include/OGRE/ --headers-dir2 
10/usr/include/OGRE/ 5/usr/lib/x86_64-linux-gnu/libOgreMain.so.1.12.5 
10/usr/lib/x86_64-linux-gnu/libOgreMain.so.1.12.10
ELF SONAME changed
Functions changes summary: 214 Removed (5 filtered out), 0 Changed, 0 Added 
functions
Variables changes summary: 3 Removed, 0 Changed, 0 Added variables
Function symbols changes summary: 1 Removed, 170 Added function symbols not 
referenced by debug info
Variable symbols changes summary: 11 Removed, 40 Added variable symbols not 
referenced by debug info

(we can't use abipkgdiff due to the Soname bump.)

So yes, the Soname bump was correct and we should not patch Ogre.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#989482: unblock: htmlmin/0.1.12-3

[Jochen Sprickerhof]

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

Please unblock package htmlmin

[ Reason ]
htmlmin/0.1.12-2 was build with an old toolchain using pkg_resources
instead of importlib.

[ Impact ]
htmlmin does not work with python3-pkg-resources not installed (#959508).

[ Tests ]
I made sure that htmlmin now works without python3-pkg-resources
installed.

[ Risks ]
This is a no change rebuild of an arch all package, I only left some
metadata changes from git in there.

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

unblock htmlmin/0.1.12-3
diff -Nru htmlmin-0.1.12/debian/changelog htmlmin-0.1.12/debian/changelog
--- htmlmin-0.1.12/debian/changelog 2019-08-10 20:37:03.0 +0200
+++ htmlmin-0.1.12/debian/changelog 2021-06-04 23:58:00.0 +0200
@@ -1,3 +1,22 @@
+htmlmin (0.1.12-3) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Debian Janitor ]
+  * Set upstream metadata fields: Bug-Database.
+  * Set upstream metadata fields: Bug-Submit.
+
+  [ Ondřej Nový ]
+  * d/control: Update Maintainer field with new Debian Python Team
+contact address.
+  * d/control: Update Vcs-* fields with new Debian Python Team Salsa
+layout.
+
+  [ Jochen Sprickerhof ]
+  * No changes rebuild to use importlib instead of pkg_resources (Closes: 
#959508)
+
+ -- Jochen Sprickerhof   Fri, 04 Jun 2021 23:58:00 +0200
+
 htmlmin (0.1.12-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru htmlmin-0.1.12/debian/control htmlmin-0.1.12/debian/control
--- htmlmin-0.1.12/debian/control   2019-08-10 20:37:03.0 +0200
+++ htmlmin-0.1.12/debian/control   2021-06-04 23:56:54.0 +0200
@@ -1,5 +1,5 @@
 Source: htmlmin
-Maintainer: Debian Python Modules Team 

+Maintainer: Debian Python Team 
 Uploaders:
  Adrian Vondendriesch ,
 Section: python
@@ -7,8 +7,8 @@
 Build-Depends: dh-python, python3-setuptools, python3-all, debhelper-compat (= 
9), help2man
 Standards-Version: 4.1.2
 Homepage: https://htmlmin.readthedocs.org/en/latest/
-Vcs-Git: https://salsa.debian.org/python-team/modules/htmlmin.git
-Vcs-Browser: https://salsa.debian.org/python-team/modules/htmlmin
+Vcs-Git: https://salsa.debian.org/python-team/packages/htmlmin.git
+Vcs-Browser: https://salsa.debian.org/python-team/packages/htmlmin
 
 Package: python3-htmlmin
 Architecture: all
diff -Nru htmlmin-0.1.12/debian/upstream/metadata 
htmlmin-0.1.12/debian/upstream/metadata
--- htmlmin-0.1.12/debian/upstream/metadata 1970-01-01 01:00:00.0 
+0100
+++ htmlmin-0.1.12/debian/upstream/metadata 2021-06-04 23:45:32.0 
+0200
@@ -0,0 +1,2 @@
+Bug-Database: https://github.com/mankyd/htmlmin/issues
+Bug-Submit: https://github.com/mankyd/htmlmin/issues/new

Bug#989522: unblock: trscripts/1.18+nmu2 xfonts-bolkhov/1.1.20001007-8.2

[Jochen Sprickerhof]

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

Please unblock package trscripts and xfonts-bolkhov

[ Reason ]
The awk script generated by trscripts used a non deterministic for-in
loop resulting in the russian letter 'у' displayed as latin u with the
xfonts-bolkhov-misc font. This was reported as #979599 and #979710.

[ Impact ]
Font rendering would be wrong without the patch.

[ Tests ]
run: xfontsel -sampleUCS у -pattern "-rfx-*" and look at the displayed
symbol.

[ Risks ]
The change in trscripts is minimal, just using a different for loop
style. xfonts-bolkhov is a no change rebuild, just bumping the
dependency on trscripts.

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

unblock trscripts/1.18+nmu2
unblock xfonts-bolkhov/1.1.20001007-8.2
diff -Nru trscripts-1.18+nmu1/debian/changelog 
trscripts-1.18+nmu2/debian/changelog
--- trscripts-1.18+nmu1/debian/changelog2021-01-07 15:01:30.0 
+0100
+++ trscripts-1.18+nmu2/debian/changelog2021-06-05 20:08:15.0 
+0200
@@ -1,3 +1,12 @@
+trscripts (1.18+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make trbdf awk script portable (Closes: #979599).
+POSIX awk does not specify the order in a for(i in array) loop, so
+switching to a for loop with an increment.
+
+ -- Jochen Sprickerhof   Sat, 05 Jun 2021 20:08:15 +0200
+
 trscripts (1.18+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru trscripts-1.18+nmu1/gen_trbdf trscripts-1.18+nmu2/gen_trbdf
--- trscripts-1.18+nmu1/gen_trbdf   2009-05-02 12:43:11.0 +0200
+++ trscripts-1.18+nmu2/gen_trbdf   2021-06-05 20:08:15.0 +0200
@@ -312,15 +312,15 @@
 EOF
 
 if [ "$usefb" = yes ]; then
-printf "   split(tu[i] \" \" alt1[tu[i]] \" \" alt2[tu[i]], a);\n"
+printf "   an = split(tu[i] \" \" alt1[tu[i]] \" \" alt2[tu[i]], a);\n"
 printf "   split(0 \" \" weight1[tu[i]] \" \" weight2[tu[i]], w);\n"
 else
-printf "   split(tu[i] \" \" alt1[tu[i]], a);\n"
+printf "   an = split(tu[i] \" \" alt1[tu[i]], a);\n"
 printf "   split(0 \" \" weight1[tu[i]], w);\n"
 fi
 
 cat <<"EOF"
-   for(j in a)
+   for(j=1; j <= an; ++j)
  {
if(ut[a[j]]!="")
  {
@@ -339,7 +339,7 @@
  }
  }
k=0;
-   for(j in a)
+   for(j=1; j <= an; ++j)
  {
if(ut[a[j]]!="")
  {
@@ -356,7 +356,7 @@
printf "\";\n";
  }
k=0;
-   for(j in a)
+   for(j=1; j <= an; ++j)
  {
if(ut[a[j]]!="")
  {
diff -u xfonts-bolkhov-1.1.20001007/debian/changelog 
xfonts-bolkhov-1.1.20001007/debian/changelog
--- xfonts-bolkhov-1.1.20001007/debian/changelog
+++ xfonts-bolkhov-1.1.20001007/debian/changelog
@@ -1,3 +1,11 @@
+xfonts-bolkhov (1.1.20001007-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dependency on trscripts to fix generated fonts when using mawk, cf.
+#979599.
+
+ -- Jochen Sprickerhof   Sat, 05 Jun 2021 23:47:31 +0200
+
 xfonts-bolkhov (1.1.20001007-8.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u xfonts-bolkhov-1.1.20001007/debian/control 
xfonts-bolkhov-1.1.20001007/debian/control
--- xfonts-bolkhov-1.1.20001007/debian/control
+++ xfonts-bolkhov-1.1.20001007/debian/control
@@ -3,7 +3,7 @@
 Section: fonts
 Priority: optional
 Standards-Version: 3.6.2
-Build-Depends: debhelper (>=9~), trscripts (>= 1.13), xfonts-utils
+Build-Depends: debhelper (>=9~), trscripts (>= 1.18+nmu2), xfonts-utils
 
 Package: xfonts-bolkhov-75dpi
 Architecture: all

Bug#989344: rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot open shared object file: No such file or directory

[Jochen Sprickerhof]

Control: reassign -1 libogre-1.12 1.12.10+dfsg2-1
Control: affects -1 rviz
Control: retitle -1 libogre-1.12: package name does not match soname

Hi,

* Johannes Schauer Marin Rodrigues  [2021-06-01 15:32]:

when trying to run rviz I get:

rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot 
open shared object file: No such file or directory

But all my system has is /usr/lib/x86_64-linux-gnu/libOgreOverlay.so.1.12.10


Rviz was compiled against libogre-1.12 1.12.5+dfsg1-1+b1 which provided
libOgreOverlay.so.1.12.5. The upload of version 1.12.10+dfsg2-1 moved to
libOgreOverlay.so.1.12.10. This is due to Ogre having the complete version as
its soversion:

https://sources.debian.org/src/ogre-1.12/1.12.10+dfsg2-1/CMakeLists.txt/#L68

Following Debian policy 8.1 the package should probably be named
libogre1.12.10 but that's probably too late for bullseye.


Maybe a binNMU is needed? A rebuild of rviz in current Debian unstable
fixed the problem for me.


As rviz is the only reverse dependency of libogre-1.12, I will ask the release
team to schedule a binNMU and ignore this bug for bullseye.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#989357: nmu: ros-rviz_1.14.4+dfsg-3

[Jochen Sprickerhof]

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

Hi release team,

libogre-1.12 bumped it's soname and library names without changing the package
name, breaking rviz (#989344). As rviz is the only dependency, would you be ok
with a binNMU, let it into bullseye and ignore the bug for bullseye?

nmu ros-rviz_1.14.4+dfsg-3 . ANY . unstable . -m "rebuild against new 
libogre-1.12 soname"

Thanks!

Jochen

Bug#990632: unblock: fdroidserver/2.0.3-1

[Jochen Sprickerhof]

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

Please unblock package fdroidserver

[ Reason ]
fdroidserver has successful autopkgtests but fails on ppc64el due to
zipalign not being available on that platform (Not a regression). I
believe that is #980087.

For the patch itself, it fixes two warnings in the linting part of
fdroidserver. ruamel deprecated one function and a restriction for the
Version field in the F-Droid metadata was lifted.

Note that I opted for a new upstream version cause adding those two
change would have resulted in basically the same patch plus/minus the
version noise. Hope that is fine.

[ Impact ]
bullseye users would would get a lot of false warnings when linting a
metadata file.

[ Tests ]
I tested the new version manually. Also upstream is using it in
production.

[ Risks ]
The code change for the Version field is only changing a regex so it
seems trivial to me. For ruamel the deprecated function was replaced by
it's content.

[ Checklist ]
  [X] all changes are documented in the d/changelog (through upstream
  changelog)
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock fdroidserver/2.0.3-1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 99a5f430..945e237c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -4,7 +4,21 @@ All notable changes to this project will be documented in this 
file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
-## [2.0.1] - 2020-03-09
+## [2.0.3] - 2021-07-01
+
+### Fixed
+
+* Support AutoUpdateMode: Version without pattern
+  [931](https://gitlab.com/fdroid/fdroidserver/-/merge_requests/931)
+
+## [2.0.2] - 2021-06-01
+
+### Fixed
+
+* fix "ruamel round_trip_dump will be removed"
+  [932](https://gitlab.com/fdroid/fdroidserver/-/merge_requests/932)
+
+## [2.0.1] - 2021-03-09
 
 ### Fixed
 
@@ -18,7 +32,7 @@ The format is based on [Keep a 
Changelog](https://keepachangelog.com/en/1.0.0/)
 * checkupdates: set User-Agent to make gitlab.com happy
 * Run push_binary_transparency only once
 
-## [2.0] - 2020-01-31
+## [2.0] - 2021-01-31
 
 For a more complete overview, see the [2.0
 milestone](https://gitlab.com/fdroid/fdroidserver/-/milestones/10)
diff --git a/PKG-INFO b/PKG-INFO
index 1c5616cd..3188aba8 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: fdroidserver
-Version: 2.0.1
+Version: 2.0.3
 Summary: F-Droid Server Tools
 Home-page: https://f-droid.org
 Author: The F-Droid Project
diff --git a/debian/changelog b/debian/changelog
index 59e519f1..d45c4c20 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+fdroidserver (2.0.3-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream version 2.0.3
+
+ -- Jochen Sprickerhof   Thu, 01 Jul 2021 14:48:57 +0200
+
 fdroidserver (2.0.1-1) unstable; urgency=medium
 
   * New upstream version 2.0.1
diff --git a/fdroidserver.egg-info/PKG-INFO b/fdroidserver.egg-info/PKG-INFO
index 1c5616cd..3188aba8 100644
--- a/fdroidserver.egg-info/PKG-INFO
+++ b/fdroidserver.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: fdroidserver
-Version: 2.0.1
+Version: 2.0.3
 Summary: F-Droid Server Tools
 Home-page: https://f-droid.org
 Author: The F-Droid Project
diff --git a/fdroidserver/checkupdates.py b/fdroidserver/checkupdates.py
index f5d0d450..b9e723df 100644
--- a/fdroidserver/checkupdates.py
+++ b/fdroidserver/checkupdates.py
@@ -492,7 +492,7 @@ def checkupdates_app(app):
 logging.warning("Can't auto-update app with no CurrentVersionCode: 
" + app.id)
 elif mode in ('None', 'Static'):
 pass
-elif mode.startswith('Version '):
+elif mode.startswith('Version'):
 pattern = mode[8:]
 suffix = ''
 if pattern.startswith('+'):
diff --git a/fdroidserver/metadata.py b/fdroidserver/metadata.py
index 6c3c4815..8b27c991 100644
--- a/fdroidserver/metadata.py
+++ b/fdroidserver/metadata.py
@@ -448,7 +448,7 @@ valuetypes = {
["AntiFeatures"]),
 
 FieldValidator("Auto Update Mode",
-   r"^(Version .+|None)$",
+   r"^(Version.*|None)$",
["AutoUpdateMode"]),
 
 FieldValidator("Update Check Mode",
@@ -964,7 +964,9 @@ def write_yaml(mf, app):
 return builds
 
 yaml_app = _app_to_yaml(app)
-ruamel.yaml.round_trip_dump(yaml_app, mf, indent=4, block_seq_indent=2)
+yaml = ruamel.yaml.YAML()
+yaml.indent(mapping=4, sequence=4, offset=2)
+yaml.dump(yaml_app, stream=mf)
 
 
 build_line_sep = re.compile(r'(?

Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf

[Jochen Sprickerhof]

Hi Hideki and Vincent,

just some information from a bystander. Also Ccing the bug author for 
more information. @Vincent: would be great to get your answers as well.


* Hideki Yamane  [2021-06-28 22:35]:

On Sun, 14 Feb 2021 14:12:17 + Vincent Arkesteijn  
wrote:

Firefox is killed with SIGILL shortly after startup:
$ firefox-esr -safe-mode
Illegal instruction


Can you reproduce it on freshly installed bullseye sytem?


I guess this is still possible given:


The referenced (NEON?) register Q8 is not available here, nor even the 
VFPv3-D32 registers D16-D17 that it maps to.


I only found this reference for NEON on armhf:

"NEON and VFP/VFP2/VFP3 remain an optional part of the architecture."

https://wiki.debian.org/ArmHardFloatPort#VFP

There are strings like -DBUILD_ARM_NEON=1 and -DHAVE_ARM_NEON=1 in the 
buildd logs here:


https://buildd.debian.org/status/fetch.php?pkg=firefox-esr=armhf=78.11.0esr-1=1622606659=0

(I didn't look what they actually do.)

If this is still reproducible, I see two options:
- Disable NEON code.
- Depend on the neon-support dummy package.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armhf (armv7l)


However,


Kernel: Linux 3.5.7-14-ARCH (PREEMPT)


It seems that is not the kernel bullseye provides.


And it maybe help to provide its hardware information, too.


The bug author wrote:


This is on a Marvell Dove system, with VFPv3-D16. From /proc/cpuinfo:
Features: swp half thumb fastmult vfp edsp iwmmxt thumbee vfpv3 
vfpv3d16 tls


Cheers Jochen


signature.asc
Description: PGP signature

Bug#990494: texlive-latex-extra: missing dependency on texlive-science for invoice.sty

[Jochen Sprickerhof]

Package: texlive-latex-extra
Version: 2020.20210202-3
Severity: normal

Hi TeX Team,

texlive-latex-extra contains invoice.sty which depends on siunitx from
the texlive-science package but does not declare a dependency.
Without texlive-science installed:

$ latex  -recorder examples.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./examples.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-01-09> xparse <2020-03-03>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)) (./invoice.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/calc.sty)

! LaTeX Error: File `siunitx.sty' not found.


##
A minimal example.tex:

\documentclass{article} 
\usepackage{invoice} 
\begin{document} 
Foo
\end{document}


##
 List of ls-R files

lrwxrwxrwx 1 root root 31 Feb 17 21:30 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Feb 13 08:36 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 17 21:30 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 17 21:30 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3106 Jun 30 17:50 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jul 31  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Feb 13 08:36 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-extra depends on:
ii  libcommons-logging-java1.2-2
ii  libpdfbox-java 1:1.8.16-2
ii  preview-latex-style12.2-1
ii  python33.9.2-3
ii  tex-common 6.16
ii  texlive-base   2020.20210202-3
ii  texlive-binaries   2020.20200327.54578-7
ii  texlive-latex-recommended  2020.20210202-3
ii  texlive-pictures   2020.20210202-3

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2020.20210202-3
pn  texlive-plain-generic  

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python3-pygments2.7.1+dfsg-2.1
pn  texlive-latex-extra-doc 

Versions of packages tex-common depends on:
ii  dpkg  1.20.9
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.3.4

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.16
ii  texlive-binaries  2020.20200327.54578-7

-- no debconf information

Bug#990359: python3-websockify: rebind.so not found (when used in program wrapper mode)

[Jochen Sprickerhof]

Control: -1 patch

Hi Thomas,

the attached patch fixes this for me, can you take care of uploading or 
should I?


Cheers Jochen

* Mike Gabriel  [2021-06-27 05:08]:

Package: python3-websockify
Severity: important
Version: 0.9.0+dfsg1-2+b1

Hi,

I played with websockify and NoVNC recently and discovered that 
websockify's program wrapper mode is currently broken in Debian 11:


```
[sunweaver@sunobo ~]$ websockify 127.0.0.1:9898 -- x11vnc -noipv6 -display :0
Traceback (most recent call last):
 File "/usr/bin/websockify", line 33, in 
   sys.exit(load_entry_point('websockify==0.9.0', 'console_scripts', 
'websockify')())
 File "/usr/lib/python3/dist-packages/websockify/websocketproxy.py", 
line 725, in websockify_init

   server = WebSocketProxy(**opts.__dict__)
 File "/usr/lib/python3/dist-packages/websockify/websocketproxy.py", 
line 306, in __init__

   raise Exception("rebind.so not found, perhaps you need to run make")
Exception: rebind.so not found, perhaps you need to run make

```

The directory /usr/lib/websockify has this content here:

```
root@sunobo:/usr/lib/websockify# LANG=C ls -al
total 44
drwxr-xr-x   2 root root  4096 Jun 27 07:01 .
drwxr-xr-x 182 root root 12288 Jun 24 15:44 ..
-rw-r--r--   1 root root 14304 Nov 19  2020 
rebind.cpython-39-x86_64-linux-gnu.so

-rw-r--r--   1 root root 11776 Nov 19  2020 rebind.o
```

My work-around for the above error is putting a symlink into this 
directory, like this:


```
root@sunobo:/usr/lib/websockify# LANG=C ls -al
total 44
drwxr-xr-x   2 root root  4096 Jun 27 07:05 .
drwxr-xr-x 182 root root 12288 Jun 24 15:44 ..
-rw-r--r--   1 root root 14304 Nov 19  2020 
rebind.cpython-39-x86_64-linux-gnu.so

-rw-r--r--   1 root root 11776 Nov 19  2020 rebind.o
lrwxrwxrwx   1 root root37 Jun 27 07:05 rebind.so -> 
rebind.cpython-39-x86_64-linux-gnu.so


```

Please, possibly fix this for Debian 11. If more help is needed, 
please let me know.


Greets,
Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de




From 1306ee39a0f6019dcb2906a70e89bdb5be158c1e Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Mon, 12 Jul 2021 08:05:28 +0200
Subject: [PATCH] Don't multiarchivy rebind.so

rebind.so is used as LD_PRELOAD, not as a Python library.
Also add a d/clean for it.

Closes: #990359
---
 debian/clean | 2 ++
 debian/rules | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 debian/clean

diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..cc058d7
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1,2 @@
+rebind.o
+rebind.so
diff --git a/debian/rules b/debian/rules
index c89017f..e5ea90c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,4 +34,4 @@ override_dh_installmenu:
 	rm -rf $(CURDIR)/debian/python3-websockify/usr/share/man
 
 override_dh_python3:
-	dh_python3 --shebang=/usr/bin/python3
+	dh_python3 --shebang=/usr/bin/python3 --no-ext-rename
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990627: python3-torchaudio: torchaudio import aborts

[Jochen Sprickerhof]

Control: tags -1 moreinfo

Hi John,

* John O'Hagan  [2021-07-03 12:48]:

The line "import torchaudio" at the python interactive shell or in a python
script or imported file results in the progra aborting with the following
output:


I tried this on a fresh amd64 bullseye installation and was not able to 
reproduce it. Can you make sure that all installed files are ok with 


sudo dpkg -V

and that you don't have any additional files installed (like torch or 
tensorflow from pip), also check 


$HOME/.local/lib/python3*/site-packages

and 


/usr/local/lib/python3*/dist-packages

Cheers Jochen


signature.asc
Description: PGP signature

Bug#990734: sbuild: option --build-dir is ignored in source directory

[Jochen Sprickerhof]

Package: sbuild
Version: 0.81.2
Severity: normal

steps to reproduce:

$ apt source hello
$ cd hello*/
$ sbuild --build-dir=/tmp
$ ls /tmp/hello* ../hello*  # all output files are in ../

whereas building the .dsc

$ cd ..
$ sbuild --build-dir=/tmp/ hello*.dsc
$ ls /tmp/hello*  # files are in /tmp

This is due to:

https://sources.debian.org/src/sbuild/0.81.2/bin/sbuild/#L231

changing it to:

$conf->_set_default('BUILD_DIR', $dscdir);

$ sbuild --build-dir=/tmp
$ ls /tmp/hello*  # files are now in /tmp

Sadly the change breaks autopkgtests:

$ cd hello*/
$ sbuild --build-dir=/tmp/ --run-autopkgtest
[..]
Unexpected error:
Traceback (most recent call last):
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 739, in mainloop
command()
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 668, in command
r = f(c, ce)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 602, in cmd_copydown
copyupdown(c, ce, False)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 490, in copyupdown
copyupdown_internal(ce[0], c[1:], upp)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 517, in 
copyupdown_internal
copydown_shareddir(sd[0], sd[1], dirsp, downtmp_host)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 472, in 
copydown_shareddir
shutil.copy(host, host_tmp)
  File "/usr/lib/python3.9/shutil.py", line 418, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.9/shutil.py", line 264, in copyfile
with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/hello_2.10.orig.tar.gz'


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

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

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.81.2
ii  perl5.32.1-4

Versions of packages sbuild recommends:
ii  autopkgtest  5.16
ii  debootstrap  1.0.123
ii  schroot  1.6.10-12

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.46.2-2
ii  kmod   28-1
ii  wget   1.21-1+b1

-- no debconf information

Bug#990627: python3-torchaudio: torchaudio import aborts

[Jochen Sprickerhof]

Control: severity -1 minor
Control: tags -1 - moreinfo + wontfix

* John O'Hagan  [2021-07-06 14:19]:

and that you don't have any additional files installed (like torch or
tensorflow from pip), also check

$HOME/.local/lib/python3*/site-packages



This was the problem, thank you. torch 1.9 was pulled into that
directory by torch.hub.load('ultralytics/yolov5', ). Renaming or
removing the torch subdirectory allows torchaudio to import normally.


Sounds like the upstream version is not compatible with the rest of your 
system.



The requirements file from the ultralytics repo only specifies torch >=
1.7, which is available in my distro, so I'm not sure why it pulls in
1.9.

Is this still to be regarded as a (perhaps different) bug?


I don't know enough about torchaudio to say how much this influences the 
usage of it but I can imagine that others run into the same problem. 
Given that you would need to load a version from elsewhere I mark this 
as minor and wontfix, Feel free to change if you think this is not 
appropriate.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#990016: Debian installer images missing ASpeed video driver

[Jochen Sprickerhof]

Control: reassign -1 src:linux

Hi Timothy,

* Timothy Pearson  [2021-06-17 15:46]:

The current Bullseye installer images don't include the "ast" video driver, 
making it impossible to install Debian on systems that don't have a fallback VGA BIOS 
(anything non-x86, e.g. ARM/OpenPOWER).

Ubuntu fixed this issue almost 5 years ago:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1514711

Please include the "ast" kernel module, which does not require any proprietary 
firmware to function, in the Debian installer CD images.


The module is part of the fb-modules-5.10.0-7-arm64-di:

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/installer/modules/arm64/fb-modules#L3

and fb-modules-5.10.0-7-loongson-3-di:

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/installer/modules/mipsel-loongson-3/fb-modules#L5

Additionally CONFIG_DRM_AST is enabled for ppc64:

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-powerpc/config-arch-64#L94

and x86:

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-x86/config#L519

So I assume it should be easy to add the module to the corresponding 
udebs. Reassigning to the linux package, accordingly.


I guess it would help if you could be more specific on which 
architectures it would be useful.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#990734: sbuild: option --build-dir is ignored in source directory

[Jochen Sprickerhof]

Control: tags -1 patch

* Jochen Sprickerhof  [2021-07-05 22:53]:

Sadly the change breaks autopkgtests:

$ cd hello*/
$ sbuild --build-dir=/tmp/ --run-autopkgtest
[..]
Unexpected error:
Traceback (most recent call last):
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 739, in mainloop
   command()
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 668, in command
   r = f(c, ce)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 602, in cmd_copydown
   copyupdown(c, ce, False)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 490, in copyupdown
   copyupdown_internal(ce[0], c[1:], upp)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 517, in 
copyupdown_internal
   copydown_shareddir(sd[0], sd[1], dirsp, downtmp_host)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 472, in 
copydown_shareddir
   shutil.copy(host, host_tmp)
 File "/usr/lib/python3.9/shutil.py", line 418, in copy
   copyfile(src, dst, follow_symlinks=follow_symlinks)
 File "/usr/lib/python3.9/shutil.py", line 264, in copyfile
   with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/hello_2.10.orig.tar.gz'


Actually this also happens when using the .dsc so it is an unrelated 
bug. I have opened a merge request here:


https://salsa.debian.org/debian/sbuild/-/merge_requests/13

Tagging this as patch accordingly.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf

[Jochen Sprickerhof]

(somehow my message didn't made it to the BTS, sorry for double post.)

Hi Hideki and Vincent,

just some information from a bystander. Also Ccing the bug author for 
more information. @Vincent: would be great to get your answers as 
well.


* Hideki Yamane  [2021-06-28 22:35]:

On Sun, 14 Feb 2021 14:12:17 + Vincent Arkesteijn  
wrote:

Firefox is killed with SIGILL shortly after startup:
$ firefox-esr -safe-mode
Illegal instruction


Can you reproduce it on freshly installed bullseye sytem?


I guess this is still possible given:


The referenced (NEON?) register Q8 is not available here, nor even the 
VFPv3-D32 registers D16-D17 that it maps to.


I only found this reference for NEON on armhf:

"NEON and VFP/VFP2/VFP3 remain an optional part of the architecture."

https://wiki.debian.org/ArmHardFloatPort#VFP

There are strings like -DBUILD_ARM_NEON=1 and -DHAVE_ARM_NEON=1 in the 
buildd logs here:


https://buildd.debian.org/status/fetch.php?pkg=firefox-esr=armhf=78.11.0esr-1=1622606659=0

(I didn't look what they actually do.)

If this is still reproducible, I see two options:
- Disable NEON code.
- Depend on the neon-support dummy package.


-- System Information:
Debian Release: bullseye/sid
 APT prefers testing
 APT policy: (500, 'testing')
Architecture: armhf (armv7l)


However,


Kernel: Linux 3.5.7-14-ARCH (PREEMPT)


It seems that is not the kernel bullseye provides.


And it maybe help to provide its hardware information, too.


The bug author wrote:


This is on a Marvell Dove system, with VFPv3-D16. From /proc/cpuinfo:
Features: swp half thumb fastmult vfp edsp iwmmxt thumbee vfpv3 
vfpv3d16 tls


Cheers Jochen


signature.asc
Description: PGP signature

Bug#987364: [Pkg-javascript-devel] Bug#987364: /usr/bin/node: segfaults regularly in node-opencv autopkgtest on ppc64el

[Jochen Sprickerhof]

Control: reassign -1 node-opencv

Hi,

* Jérémy Lal  [2021-04-22 18:38]:

(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:235
#1  0x70145254 in memcpy (__len=4, __src=,
__dest=0x7fffc779d480) at
/usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:34
#2  cv::PngDecoder::readDataFromBuf (_png_ptr=0x7fffbd20,
dst=0x7fffc779d480 "\226\341l\204", size=4) at
../modules/imgcodecs/src/grfmt_png.cpp:138
#3  0x7fffdb5799ac in png_read_data (png_ptr=,
data=, length=) at pngrio.c:37
#4  0x7fffdb581b2c in png_crc_error (png_ptr=0x7fffbd20) at
pngrutil.c:275
#5  0x7fffdb581c70 in png_crc_finish (png_ptr=0x7fffbd20,
skip=) at pngrutil.c:229
#6  0x7fffdb5882a8 in png_read_IDAT_data (png_ptr=0x7fffbd20,
output=, avail_out=) at pngrutil.c:4351
#7  0x7fffdb57608c in png_read_row (png_ptr=0x7fffbd20,
row=0x7fffc697c300 "", dsp_row=0x0) at pngread.c:623
#8  0x7fffdb5782d8 in png_read_image (png_ptr=0x7fffbd20,
image=0x7fffb000b910) at pngread.c:833
#9  0x70145fc8 in cv::PngDecoder::readData (this=0x7fffbc20,
img=...) at ../modules/imgcodecs/src/grfmt_png.cpp:284
#10 0x70128e4c in cv::imdecode_ (buf=..., flags=flags@entry=1,
mat=...) at ../modules/imgcodecs/src/loadsave.cpp:860
#11 0x70129a70 in cv::imdecode (_buf=..., flags=) at
../modules/imgcodecs/src/loadsave.cpp:900
#12 0x70539ec8 in AsyncImDecodeWorker::Execute (this=0x100253b00)
at /usr/include/opencv4/opencv2/core/mat.inl.hpp:92
#13 0x70530ba4 in Nan::AsyncExecute (req=) at
../../../../usr/lib/nodejs/nan/nan.h:2284
#14 0x760aac84 in uv__queue_work (w=) at
../deps/uv/src/threadpool.c:321
#15 0x760aad9c in worker (arg=0x0) at
../deps/uv/src/threadpool.c:122
#16 0x754a956c in start_thread (arg=0x7fffc779f140) at
pthread_create.c:477
#17 0x753b8044 in clone () at
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:82


This is in the async version of node-opencv cleaning up the buffer 
during the memcpy. I was not able to reproduce it anymore with the 
attached hack (you probably want to commit a clean version).


Cheers Jochen
diff --git a/src/OpenCV.cc b/src/OpenCV.cc
index b9f779c..f84f249 100755
--- a/src/OpenCV.cc
+++ b/src/OpenCV.cc
@@ -37,6 +37,7 @@ public:
 cv::Mat mbuf(len, 1, CV_64FC1, buf);
 outputmat = cv::imdecode(mbuf, flags);
 success = 1;
+free(buf);
   } catch(...){
 success = 0;
   }
@@ -224,8 +225,10 @@ NAN_METHOD(OpenCV::ReadImageAsync) {
 // async
 uint8_t *buf = (uint8_t *) Buffer::Data(Nan::To(info[0]).ToLocalChecked());
 unsigned len = Buffer::Length(Nan::To(info[0]).ToLocalChecked());
+uint8_t *buf_new = (uint8_t *)malloc(len);
+memcpy(buf_new, buf, len);
 Nan::Callback *callback = new Nan::Callback(cb.As());
-Nan::AsyncQueueWorker(new AsyncImDecodeWorker(callback, buf, len, flags));
+Nan::AsyncQueueWorker(new AsyncImDecodeWorker(callback, buf_new, len, flags));
 return;
   }
   // WILL have returned by here unless exception


signature.asc
Description: PGP signature

Bug#987429: unblock: fdroidcl/0.5.0-3

[Jochen Sprickerhof]

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

Please unblock package fdroidcl

[ Reason ]
The F-Droid metadata json format changed slightly moving the App name to
the localized part. The update adds a upstream accepted patch to prefer
that over the general field in case that is empty. It is basically a
copy and paste of what is already done for the summary and description
fields in the lines below the patch.

[ Impact ]
The name of an app is not shown:
$ fdroidcl show org.fdroid.fdroid | grep "^Name"
Name :

[ Tests ]
I tested the change manually.

[ Risks ]
Code change is trivial and popcon is low.

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

unblock fdroidcl/0.5.0-3
diff --git a/debian/changelog b/debian/changelog
index a061ba6..d52170b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+fdroidcl (0.5.0-3) unstable; urgency=medium
+
+  * Add patch in case the app name is empty
+
+ -- Jochen Sprickerhof   Fri, 23 Apr 2021 18:42:52 +0200
+
 fdroidcl (0.5.0-2) unstable; urgency=medium
 
   * bump policy and debhelper versions
diff --git 
a/debian/patches/0002-Use-English-app-name-if-the-other-is-empty.patch 
b/debian/patches/0002-Use-English-app-name-if-the-other-is-empty.patch
new file mode 100644
index 000..2dc860a
--- /dev/null
+++ b/debian/patches/0002-Use-English-app-name-if-the-other-is-empty.patch
@@ -0,0 +1,30 @@
+From: Jochen Sprickerhof 
+Date: Fri, 23 Apr 2021 18:34:00 +0200
+Subject: Use English app name if the other is empty
+
+---
+ fdroid/index.go | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/fdroid/index.go b/fdroid/index.go
+index 1716c19..119ea7e 100644
+--- a/fdroid/index.go
 b/fdroid/index.go
+@@ -59,6 +59,7 @@ type App struct {
+ }
+ 
+ type Localization struct {
++  Namestring `json:"name"`
+   Summary string `json:"summary"`
+   Description string `json:"description"`
+ }
+@@ -274,6 +275,9 @@ func LoadIndexJSON(r io.Reader) (*Index, error) {
+   english, enOK = app.Localized["en-US"]
+   }
+ 
++  if app.Name == "" && enOK {
++  app.Name = english.Name
++  }
+   // TODO: why does the json index contain html escapes?
+   app.Name = html.UnescapeString(app.Name)
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 0890fce..08f194a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-Drop-main_test.go.patch
+0002-Use-English-app-name-if-the-other-is-empty.patch

Bug#988088: unblock: libica/3.2.0-4

[Jochen Sprickerhof]

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

Please unblock package libica

[ Reason ]
The package fails to build with GCC 10 due to multiple definitions of
variables in the test suite (#987614).

[ Impact ]
libica is a transitive build dependency of simple-tpm-pk11 on s390x.

[ Tests ]
I successfully tested the build and test suite on zelenka.

[ Risks ]
As the changes are only in the test suite and rather simple I don't see
a risk.

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

[ Other info ]
The upstream website moved to Github, so I updated the homepage filed,
hope that's fine.

unblock libica/3.2.0-4
diff -Nru libica-3.2.0/debian/changelog libica-3.2.0/debian/changelog
--- libica-3.2.0/debian/changelog   2019-03-12 05:04:53.0 +0100
+++ libica-3.2.0/debian/changelog   2021-05-05 09:27:48.0 +0200
@@ -1,3 +1,11 @@
+libica (3.2.0-4) unstable; urgency=medium
+
+  * QA upload.
+  * Add multiple_defines.patch, fixes a FTBFS with gcc 10 (Closes: 987614).
+  * Update homepage field.
+
+ -- Jochen Sprickerhof   Wed, 05 May 2021 09:27:48 +0200
+
 libica (3.2.0-3) unstable; urgency=medium
 
   * QA upload.
diff -Nru libica-3.2.0/debian/control libica-3.2.0/debian/control
--- libica-3.2.0/debian/control 2019-03-12 05:04:50.0 +0100
+++ libica-3.2.0/debian/control 2021-05-05 09:27:48.0 +0200
@@ -4,7 +4,7 @@
 Build-Depends: debhelper (>= 10), dh-autoreconf, libssl-dev, autoconf-archive
 Standards-Version: 4.1.0
 Section: libs
-Homepage: http://sourceforge.net/projects/opencryptoki/files/libica/
+Homepage: https://github.com/opencryptoki/libica
 
 Package: libica-dev
 Section: libdevel
diff -Nru libica-3.2.0/debian/patches/multiple_defines.patch 
libica-3.2.0/debian/patches/multiple_defines.patch
--- libica-3.2.0/debian/patches/multiple_defines.patch  1970-01-01 
01:00:00.0 +0100
+++ libica-3.2.0/debian/patches/multiple_defines.patch  2021-05-05 
09:27:48.0 +0200
@@ -0,0 +1,29 @@
+Description: Remove multiple definitions in the test suite
+ Fixes the build with gcc 10.
+Author: Jochen Sprickerhof 
+Bug-Debian: https://bugs.debian.org/987614
+Forwarded: not-needed
+Last-Update: 2021-05-05
+
+--- libica-3.2.0.orig/src/tests/libica_sha_test/include/sha_tests.h
 libica-3.2.0/src/tests/libica_sha_test/include/sha_tests.h
+@@ -23,5 +23,4 @@ int sha3_256_api_test(test_t * test);
+ int sha3_384_api_test(test_t * test);
+ int sha3_512_api_test(test_t * test);
+ 
+-int silent;
+ #endif
+--- libica-3.2.0.orig/src/tests/libica_sha_test/sha_tests.c
 libica-3.2.0/src/tests/libica_sha_test/sha_tests.c
+@@ -8,9 +8,9 @@
+ #include "queue_t.h"
+ #include "sha_tests.h"
+ #include "critical_error.h"
+-#define VERBOSE_EXTERN
++#define VERBOSITY_EXTERN
+ #include "../testcase.h"
+-#undef VERBOSE_EXTERN
++#undef VERBOSITY_EXTERN
+ 
+ #define SHA1_BLOCK_SIZE   (512 / 8)
+ #define SHA224_BLOCK_SIZE (512 / 8)
diff -Nru libica-3.2.0/debian/patches/series libica-3.2.0/debian/patches/series
--- libica-3.2.0/debian/patches/series  2017-10-04 11:28:19.0 +0200
+++ libica-3.2.0/debian/patches/series  2021-05-05 09:27:48.0 +0200
@@ -1 +1,2 @@
 test-suite.patch
+multiple_defines.patch

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

Hi Scott,

* John Scott  [2021-05-03 00:35]:

Has anyone been able to reproduce this? Attempting to build Sage in a
fresh unstable environment succeeds for me; perhaps the build failure
was spurious.


I triggered reproducible builds yesterday:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagemath.html

The problem Lucas found is:

* Lucas Nussbaum  [2021-04-07 08:51]:

make[4]: Entering directory '/<>'
Error: 210 tests failed, up to 200 failures are tolerated
make[4]: *** [debian/rules:165: had-few-failures] Error 1


whereas the RB runs above produced:

Success: 41 tests failed, up to 200 failures are tolerated
Success: 5 tests failed, up to 200 failures are tolerated

The 200 is set in debian/rules:

https://salsa.debian.org/science-team/sagemath/-/commit/6088e9f2abc7ae99a8d07760ceee6fb6aac7bb54

and sounds a little arbitrary. Sadly the state upstream seems not to be 
much better:


https://github.com/sagemath/sage/tree/9.2

13 failing, 17 cancelled, and 70 successful checks

(I did not look into them.)

So I think the question is rather if the test suite gives an 
appropriate view on the quality of the software. If it does, I assume 
it is not appropriate for a Debian stable release. Contrary if we assume 
the test suite being broken, we could disable it completely rather then 
producing random FTBFS.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#987652: surf does not start

[Jochen Sprickerhof]

Control: severity -1 normal
Control: tags -1 = moreinfo unreproducible

Hi,

I was not able to reproduce this on testing nor unstable.

* Aymeric Agon-Rambosson  [2021-04-27 03:18]:

$ /usr/bin/surf

output :

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed
web process terminated: crashed


Can you attach a gdb and send a backtrace?


The problem can be traced back to this specific upstream commit : 
e92fd1aa5f38c399f8fc5d263026fbd9d34ddfbb

Which can be found at 
https://git.suckless.org/surf/commit/e92fd1aa5f38c399f8fc5d263026fbd9d34ddfbb.html


That is there since over a year and I'm not aware of any issues with it, 
probably a red herring. How did you test that?



-- Configuration Files:
/etc/apparmor.d/usr.bin.surf changed:


Probably unrelated but maybe a good idea to reset this to the default.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#987652: surf does not start

[Jochen Sprickerhof]

* Aymeric Agon-Rambosson  [2021-04-27 03:18]:

$ /usr/bin/surf

output :

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed
web process terminated: crashed


Also, can you check if you have a custom webext-surf.so in your ~/.surf 
or elsewhere in your ld path?


signature.asc
Description: PGP signature

Bug#982547: RM: nanoblogger-extra -- RoQA; depends on removed nanoblogger

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal

Hi,

nanoblogger was removed in #981498 making nanoblogger-extra
not installable. Please remove it as well.

Cheers Jochen

Bug#957124: db5.3: diff for NMU version 5.3.28+dfsg1-0.7

[Jochen Sprickerhof]

Control: tags 957124 + patch
Control: tags 957124 + pending


Dear maintainer,

I've prepared an NMU for db5.3 (versioned as 5.3.28+dfsg1-0.7) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru db5.3-5.3.28+dfsg1/debian/changelog db5.3-5.3.28+dfsg1/debian/changelog
--- db5.3-5.3.28+dfsg1/debian/changelog	2019-03-12 05:16:54.0 +0100
+++ db5.3-5.3.28+dfsg1/debian/changelog	2021-01-29 13:27:20.0 +0100
@@ -1,3 +1,10 @@
+db5.3 (5.3.28+dfsg1-0.7) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patches for GCC 10 (Closes: #957124)
+
+ -- Jochen Sprickerhof   Fri, 29 Jan 2021 13:27:20 +0100
+
 db5.3 (5.3.28+dfsg1-0.6) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru db5.3-5.3.28+dfsg1/debian/patches/0012-Don-t-expo-progname-symbol.patch db5.3-5.3.28+dfsg1/debian/patches/0012-Don-t-expo-progname-symbol.patch
--- db5.3-5.3.28+dfsg1/debian/patches/0012-Don-t-expo-progname-symbol.patch	1970-01-01 01:00:00.0 +0100
+++ db5.3-5.3.28+dfsg1/debian/patches/0012-Don-t-expo-progname-symbol.patch	2021-01-29 12:45:00.0 +0100
@@ -0,0 +1,32 @@
+From: Jochen Sprickerhof 
+Date: Sat, 23 Jan 2021 19:37:02 +0100
+Subject: Don't expo progname symbol
+
+Fixes:
+
+/usr/bin/ld: .libs/TestDbTuner.o:(.data.rel.local+0x0): multiple definition of `progname'; .libs/Runner.o:(.bss+0x0): first defined here
+---
+ test/c/suites/TestDbTuner.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/test/c/suites/TestDbTuner.c b/test/c/suites/TestDbTuner.c
+index 21954c2..b84bfd8 100644
+--- a/test/c/suites/TestDbTuner.c
 b/test/c/suites/TestDbTuner.c
+@@ -33,7 +33,6 @@ int open_db(DB_ENV **, DB **, char *, char *, u_int32_t, int);
+ int run_test(CuTest *, u_int32_t, int, int, int, int, int);
+ int store_db(DB *, int, int, int, int);
+ 
+-const char *progname = "TestDbTuner";
+ int total_cases, success_cases;
+ 
+ int TestDbTuner(CuTest *ct) {
+@@ -201,7 +200,7 @@ open_db(dbenvp, dbpp, dbname, home, pgsize, duptype)
+ 	*dbenvp = dbenv;
+ 
+ 	dbenv->set_errfile(dbenv, stderr);
+-	dbenv->set_errpfx(dbenv, progname);
++	dbenv->set_errpfx(dbenv, "TestDbTuner");
+ 
+ 	if ((ret =
+ 	dbenv->set_cachesize(dbenv, (u_int32_t)0,
diff -Nru db5.3-5.3.28+dfsg1/debian/patches/0014-Use-one-object-for-shqueue.h-test.patch db5.3-5.3.28+dfsg1/debian/patches/0014-Use-one-object-for-shqueue.h-test.patch
--- db5.3-5.3.28+dfsg1/debian/patches/0014-Use-one-object-for-shqueue.h-test.patch	1970-01-01 01:00:00.0 +0100
+++ db5.3-5.3.28+dfsg1/debian/patches/0014-Use-one-object-for-shqueue.h-test.patch	2021-01-29 12:45:00.0 +0100
@@ -0,0 +1,185 @@
+From: Jochen Sprickerhof 
+Date: Fri, 29 Jan 2021 12:00:31 +0100
+Subject: Use one object for shqueue.h test
+
+shqueue.h uses pointer arithmetic to store the relative offsets of the
+elements. This is only allowed in an array object.
+---
+ test/c/suites/TestQueue.c | 38 ++
+ 1 file changed, 18 insertions(+), 20 deletions(-)
+
+diff --git a/test/c/suites/TestQueue.c b/test/c/suites/TestQueue.c
+index b5bc1ab..02f6f41 100644
+--- a/test/c/suites/TestQueue.c
 b/test/c/suites/TestQueue.c
+@@ -44,6 +44,9 @@ const char *failure_reason_names[] = {
+ 	"expected to be at the head of the list"
+ };
+ 
++// longest ops[i].final
++#define TEST_QUEUE_LEN 5
++
+ SH_LIST_HEAD(sh_lq);
+ struct sh_le {
+ 	char content;
+@@ -79,14 +82,15 @@ sh_l_init(items)
+ {
+ 	const char *c = items;
+ 	struct sh_le *ele = NULL, *last_ele = (struct sh_le*)-1;
+-	struct sh_lq *l = calloc(1, sizeof(struct sh_lq));
++	struct sh_lq *l = calloc(1, sizeof(struct sh_lq) + TEST_QUEUE_LEN * sizeof(struct sh_le));
++	size_t i = 0;
+ 
+ 	SH_LIST_INIT(l);
+ 
+ 	while (*c != '\0') {
+ 		if (c[0] != ' ') {
+ 			last_ele = ele;
+-			ele = calloc(1, sizeof(struct sh_le));
++			ele = (struct sh_le*)[sizeof(struct sh_lq) + i++ * sizeof(struct sh_le)];
+ 			ele->content = c[0];
+ 			if (SH_LIST_EMPTY(l))
+ SH_LIST_INSERT_HEAD(l, ele, sh_les, sh_le);
+@@ -106,8 +110,6 @@ sh_l_remove_head(l)
+ 	struct sh_le *ele = SH_LIST_FIRST(l, sh_le);
+ 
+ 	SH_LIST_REMOVE_HEAD(l, sh_les, sh_le);
+-	if (ele != NULL)
+-		free(ele);
+ 
+ 	return (l);
+ }
+@@ -126,7 +128,6 @@ sh_l_remove_tail(l)
+ 
+ 	if (ele) {
+ 		SH_LIST_REMOVE(ele, sh_les, sh_le);
+-		free(ele);
+ 	}
+ 	return (l);
+ }
+@@ -153,7 +154,7 @@ sh_l_insert_head(l, item)
+ 	struct sh_lq *l;
+ 	const char *item;
+ {
+-	struct sh_le *ele = calloc(1, sizeof(struct sh_le));
++	struct sh_le *ele = (struct sh_le*)[sizeof(struct sh_lq) + (TEST_QUEUE_LEN-1) * sizeof(struct sh_le)];
+ 
+ 	ele->content = item[0];
+ 	SH_LIST_INSERT_HEAD(l, ele, sh_les, sh_le);
+@@ -174,11 +175,11 @@ sh_l_insert_tail(l, item)
+ 			last_ele = SH_LIST_NEXT(last_ele, sh_les, sh_le);
+ 
+ 	if (last_ele == NULL) {
+-		ele = calloc(1, sizeof(struct sh_le));
++		ele = (struct sh_le*)[sizeof(struct sh_lq) + (TEST_QUEUE_

Bug#985750: unblock: gazebo/11.1.0+dfsg-6

[Jochen Sprickerhof]

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

Please unblock package gazebo

[ Reason ]
The version in testing was build with an old version of protobuf so
software using libgazebo-dev and the current protobuf version in testing
fail to build, like gazebo_ros (not in Debian). The fix is to rebuild
against the current protobuf API version and to depend on that to make
sure it is rebuild automatically in future.

The gazebo package only builds on amd64 and i386 and was blocked from
migration due to britney not being smarter. Discussing this in
#debian-devel, elbrus proposed to mark the only autopkgtest as
superficial as it not really testing enough of the package. So the diff
includes this as well.

[ Impact ]
The protobuf headers in libgazebo-dev would not be usable.

[ Tests ]
There are no automated tests, compiling gazebo_ros manually works after
the rebuild.

[ Risks ]
There is no risk, as the libgazebo-dev already depends on
libprotobuf-dev which provides the protobufapi package.

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

unblock gazebo/11.1.0+dfsg-6
diff --git a/debian/changelog b/debian/changelog
index 6ee8a113..7e75fc8b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+gazebo (11.1.0+dfsg-6) unstable; urgency=medium
+
+  * Team upload.
+  * Mark test superficial
+
+ -- Jochen Sprickerhof   Mon, 22 Mar 2021 22:21:38 +0100
+
+gazebo (11.1.0+dfsg-5) unstable; urgency=medium
+
+  * Team upload.
+  * libgazebo-dev Depends on Protobuf API version (Closes: #985660)
+
+ -- Jochen Sprickerhof   Sun, 21 Mar 2021 22:21:29 +0100
+
 gazebo (11.1.0+dfsg-4) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 161cefd4..5ac5de9b 100644
--- a/debian/control
+++ b/debian/control
@@ -172,7 +172,8 @@ Depends: libtbb-dev,
  libgazebo11 (= ${binary:Version}),
  gazebo-common (= ${source:Version}),
  gazebo-plugin-base (= ${binary:Version}),
- ${misc:Depends}
+ ${misc:Depends},
+ ${protobuf:API},
 Breaks: libgazebo7-dev, libgazebo9-dev (<< 11.0.0+dfsg-1~)
 Replaces: libgazebo7-dev, libgazebo9-dev (<< 11.0.0+dfsg-1~)
 Description: Open Source Robotics Simulator - Development Files
diff --git a/debian/rules b/debian/rules
index c5b852a6..7268f462 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,11 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# see #985660
+# extract the protobuf API version package and add it to d/control
+# Needed because protobuf generated headers are only compatible with that 
version
+protobufapi := $(shell dpkg-query -W -f '$${Provides}' libprotobuf-dev | grep 
-o 'protobuf-api-[^ ]*')
+
 override_dh_auto_configure:
dh_auto_configure -- \
 -DUSE_HOST_CFLAGS:BOOL=False \
@@ -18,6 +23,9 @@ override_dh_install:
# Remove old script
rm -f debian/gazebo/usr/bin/gzprop
 
+execute_before_dh_gencontrol:
+   echo 'protobuf:API=$(protobufapi)' >> debian/libgazebo-dev.substvars
+
 # Tests needs an X server running and GPU acceleration
 override_dh_auto_test:
 
diff --git a/debian/tests/control b/debian/tests/control
index 3a872e84..9de62eb0 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,3 @@
 Tests: build
 Depends: @, pkg-config, build-essential
+Restrictions: superficial

Bug#986115: unblock: java3d/1.5.2+dfsg-17

[Jochen Sprickerhof]

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

Please unblock package java3d

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
java3d FTBFS on i386 due to conflicting typedefs.

[ Impact ]
A number of packages are removed from testing.

[ Tests ]
Only type checking carried out by the compiler.

[ Risks ]
I assume it is low as the type was just wrong before.

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

unblock java3d/1.5.2+dfsg-17
diff --git a/debian/changelog b/debian/changelog
index dfd20e2..2430b73 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+java3d (1.5.2+dfsg-17) unstable; urgency=medium
+
+  * Team upload.
+  * Update patch for GLsizeiptr typedef (Closes: #983760)
+  * Update homepage (Closes: #911055)
+
+ -- Jochen Sprickerhof   Mon, 29 Mar 2021 20:11:36 +0200
+
 java3d (1.5.2+dfsg-16) unstable; urgency=medium
 
   * No longer build the applet to fix the build failure with Java 11
diff --git a/debian/control b/debian/control
index 8285988..b0804c8 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Build-Depends:
 Standards-Version: 4.2.1
 Vcs-Git: https://salsa.debian.org/java-team/java3d.git
 Vcs-Browser: https://salsa.debian.org/java-team/java3d
-Homepage: http://java3d.java.net
+Homepage: https://www.oracle.com/java/technologies/javase/java-3d.html
 
 Package: libjava3d-java
 Architecture: all
diff --git a/debian/patches/0011-Fix-definition-of-GLsizeiptr.patch 
b/debian/patches/0011-Fix-definition-of-GLsizeiptr.patch
new file mode 100644
index 000..e9f384d
--- /dev/null
+++ b/debian/patches/0011-Fix-definition-of-GLsizeiptr.patch
@@ -0,0 +1,40 @@
+From: Jochen Sprickerhof 
+Date: Mon, 29 Mar 2021 19:48:13 +0200
+Subject: Fix definition of GLsizeiptr
+
+---
+ j3d-core/src/native/ogl/glext.h | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/j3d-core/src/native/ogl/glext.h b/j3d-core/src/native/ogl/glext.h
+index 2519a6c..71ff798 100644
+--- a/j3d-core/src/native/ogl/glext.h
 b/j3d-core/src/native/ogl/glext.h
+@@ -43,6 +43,8 @@ extern "C" {
+ #define GLAPI extern
+ #endif
+ 
++#include 
++
+ /*/
+ 
+ /* Header file version number, required by OpenGL ABI for Linux */
+@@ -3390,14 +3392,14 @@ typedef char GLchar;   /* native 
character */
+ 
+ #ifndef GL_VERSION_1_5
+ /* GL types for handling large vertex buffer objects */
+-typedef ptrdiff_t GLintptr;
+-typedef ptrdiff_t GLsizeiptr;
++typedef khronos_intptr_t GLintptr;
++typedef khronos_ssize_t GLsizeiptr;
+ #endif
+ 
+ #ifndef GL_ARB_vertex_buffer_object
+ /* GL types for handling large vertex buffer objects */
+-typedef ptrdiff_t GLintptrARB;
+-typedef ptrdiff_t GLsizeiptrARB;
++typedef khronos_intptr_t GLintptrARB;
++typedef khronos_ssize_t GLsizeiptrARB;
+ #endif
+ 
+ #ifndef GL_ARB_shader_objects
diff --git a/debian/patches/series b/debian/patches/series
index 4ceba7b..f6a7960 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,6 +5,6 @@
 05_pic_amd64.patch
 05_pic_i586.patch
 06_java-compat.patch
-typedef.patch
 07_java9_compatibility.patch
 08_java10_compatibility.patch
+0011-Fix-definition-of-GLsizeiptr.patch
diff --git a/debian/patches/typedef.patch b/debian/patches/typedef.patch
deleted file mode 100644
index 942057e..000
--- a/debian/patches/typedef.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From: Markus Koschany 
-Date: Sat, 22 Nov 2014 23:54:59 +0100
-Subject: typedef
-
-Define GLsizeiptr and GLintptr explicitly to prevent a FTBFS.
-This patch may be removed in the future when
-https://bugs.debian.org/765933 gets fixed.
-
-Bug: https://bugs.debian.org/769301
-Forwarded: no

- j3d-core/src/native/ogl/gldefs.h | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/j3d-core/src/native/ogl/gldefs.h 
b/j3d-core/src/native/ogl/gldefs.h
-index bf4434f..d20de17 100644
 a/j3d-core/src/native/ogl/gldefs.h
-+++ b/j3d-core/src/native/ogl/gldefs.h
-@@ -65,6 +65,8 @@
- #include 
- #include 
- 
-+typedef ptrdiff_t GLsizeiptr;
-+typedef ptrdiff_t GLintptr;
- #include 
- #include 
- #ifdef Java3D_undef__glext_h_

Bug#985455: python3-pkg-resources: fails to upgrade from 'buster': ValueError: not enough values to unpack (expected 4, got 3) in /usr/bin/py3compile

[Jochen Sprickerhof]

Hi,

I can reproduce the bug when upgrading python3-joblib before 
python3-minimal. This sounds related to #954403.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#984779: ITP: xsct -- X11 set color temperature

[Jochen Sprickerhof]

Hi Mike,

* Mike Gabriel  [2021-03-08 11:24]:

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

* Package name: xsct
 Version : 0+git20210308
 Upstream Author : Fabian Foerg 
* URL : https://github.com/faf0/sct
* License : Public Domain Mark 1.0
 Programming Lang: C
 Description : X11 set color temperature

Xsct (X11 set color temperature) is a UNIX tool which allows you to set
the color temperature of your screen. It is simpler than Redshift and
f.lux.
.
Original code was published by Ted Unangst:
http://www.tedunangst.com/flak/post/sct-set-color-temperature
.
This package will probably become relevant for a new Ayatana System
Indicator being provided in Debian soon: ayatana-indicator-display.


There is already:

https://tracker.debian.org/pkg/setcolortemperature

What's the difference?

Maybe it makes sense to combine the effort.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#987186: unblock: imagemagick/8:6.9.11.60+dfsg-1.1

[Jochen Sprickerhof]

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

Please unblock package imagemagick

[ Reason ]
imagemagick creates wrong images making gscan2pdf FTBFS.

[ Impact ]
gscan2pdf would FTBFS in bullseye and imagemagick be broken.

[ Tests ]
I checked that the correct image is generated again and also gscan2pdf
builds successfully and autopkgtests work.

[ Risks ]
The code change is rather minimal, just sanitizing a size of 0, so the
risk is low. Also there are a lot of tests and autopkgtest in other
packages, which all pass and the diff is taken from upstream.

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

unblock imagemagick/8:6.9.11.60+dfsg-1.1
diff -Nru imagemagick-6.9.11.60+dfsg/debian/changelog 
imagemagick-6.9.11.60+dfsg/debian/changelog
--- imagemagick-6.9.11.60+dfsg/debian/changelog 2021-02-01 17:22:02.0 
+0100
+++ imagemagick-6.9.11.60+dfsg/debian/changelog 2021-04-13 20:58:45.0 
+0200
@@ -1,3 +1,10 @@
+imagemagick (8:6.9.11.60+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Import upstream patch to fix font size (Closes: #980202).
+
+ -- Jochen Sprickerhof   Tue, 13 Apr 2021 20:58:45 +0200
+
 imagemagick (8:6.9.11.60+dfsg-1) unstable; urgency=high
 
   * New upstream version
diff -Nru 
imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch
 
imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch
--- 
imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch
   1970-01-01 01:00:00.0 +0100
+++ 
imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch
   2021-04-13 20:58:25.0 +0200
@@ -0,0 +1,32 @@
+From 650f0f7ecfaee42b3da89a04b92b05f27fe786e9 Mon Sep 17 00:00:00 2001
+From: Cristy 
+Date: Sat, 10 Apr 2021 12:15:54 -0400
+Subject: [PATCH] https://github.com/ImageMagick/ImageMagick6/issues/145
+
+---
+ magick/annotate.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/magick/annotate.c b/magick/annotate.c
+index 29c8bbe74..20fbf7bb1 100644
+--- a/magick/annotate.c
 b/magick/annotate.c
+@@ -1484,6 +1484,15 @@ static MagickBooleanType RenderFreetype(Image 
*image,const DrawInfo *draw_info,
+   metrics->pixels_per_em.y=face->size->metrics.y_ppem;
+   metrics->ascent=(double) face->size->metrics.ascender/64.0;
+   metrics->descent=(double) face->size->metrics.descender/64.0;
++  if (face->size->metrics.ascender == 0)
++{
++  /*
++Sanitize buggy ascender and descender values.
++  */
++  metrics->ascent=face->size->metrics.y_ppem;
++  if (face->size->metrics.descender == 0)
++metrics->descent=face->size->metrics.y_ppem/-3.5;
++}
+   metrics->width=0;
+   metrics->origin.x=0;
+   metrics->origin.y=0;
+-- 
+2.31.0
+
diff -Nru imagemagick-6.9.11.60+dfsg/debian/patches/series 
imagemagick-6.9.11.60+dfsg/debian/patches/series
--- imagemagick-6.9.11.60+dfsg/debian/patches/series2021-02-01 
17:20:25.0 +0100
+++ imagemagick-6.9.11.60+dfsg/debian/patches/series2021-04-13 
20:58:35.0 +0200
@@ -20,3 +20,4 @@
 0020-Fix-a-typo-in-manpage.patch
 0021-Finalize-fixing-error-in-html.patch
 0022-FIx-error-in-new-upstream-html.patch
+0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch

Bug#980202: imagemagick: diff for NMU version 8:6.9.11.60+dfsg-1.1

[Jochen Sprickerhof]

Control: tags 980202 + patch
Control: tags 980202 + pending


Dear maintainer,

I've prepared an NMU for imagemagick (versioned as 8:6.9.11.60+dfsg-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru imagemagick-6.9.11.60+dfsg/debian/changelog imagemagick-6.9.11.60+dfsg/debian/changelog
--- imagemagick-6.9.11.60+dfsg/debian/changelog	2021-02-01 17:22:02.0 +0100
+++ imagemagick-6.9.11.60+dfsg/debian/changelog	2021-04-13 20:58:45.0 +0200
@@ -1,3 +1,10 @@
+imagemagick (8:6.9.11.60+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Import upstream patch to fix font size (Closes: #980202).
+
+ -- Jochen Sprickerhof   Tue, 13 Apr 2021 20:58:45 +0200
+
 imagemagick (8:6.9.11.60+dfsg-1) unstable; urgency=high
 
   * New upstream version
diff -Nru imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch
--- imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch	1970-01-01 01:00:00.0 +0100
+++ imagemagick-6.9.11.60+dfsg/debian/patches/0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch	2021-04-13 20:58:25.0 +0200
@@ -0,0 +1,32 @@
+From 650f0f7ecfaee42b3da89a04b92b05f27fe786e9 Mon Sep 17 00:00:00 2001
+From: Cristy 
+Date: Sat, 10 Apr 2021 12:15:54 -0400
+Subject: [PATCH] https://github.com/ImageMagick/ImageMagick6/issues/145
+
+---
+ magick/annotate.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/magick/annotate.c b/magick/annotate.c
+index 29c8bbe74..20fbf7bb1 100644
+--- a/magick/annotate.c
 b/magick/annotate.c
+@@ -1484,6 +1484,15 @@ static MagickBooleanType RenderFreetype(Image *image,const DrawInfo *draw_info,
+   metrics->pixels_per_em.y=face->size->metrics.y_ppem;
+   metrics->ascent=(double) face->size->metrics.ascender/64.0;
+   metrics->descent=(double) face->size->metrics.descender/64.0;
++  if (face->size->metrics.ascender == 0)
++{
++  /*
++Sanitize buggy ascender and descender values.
++  */
++  metrics->ascent=face->size->metrics.y_ppem;
++  if (face->size->metrics.descender == 0)
++metrics->descent=face->size->metrics.y_ppem/-3.5;
++}
+   metrics->width=0;
+   metrics->origin.x=0;
+   metrics->origin.y=0;
+-- 
+2.31.0
+
diff -Nru imagemagick-6.9.11.60+dfsg/debian/patches/series imagemagick-6.9.11.60+dfsg/debian/patches/series
--- imagemagick-6.9.11.60+dfsg/debian/patches/series	2021-02-01 17:20:25.0 +0100
+++ imagemagick-6.9.11.60+dfsg/debian/patches/series	2021-04-13 20:58:35.0 +0200
@@ -20,3 +20,4 @@
 0020-Fix-a-typo-in-manpage.patch
 0021-Finalize-fixing-error-in-html.patch
 0022-FIx-error-in-new-upstream-html.patch
+0001-https-github.com-ImageMagick-ImageMagick6-issues-145.patch


signature.asc
Description: PGP signature

Bug#986727: pexpect: flaky and superficial? autopkgtest

[Jochen Sprickerhof]

Hi,

I looked into this bug but was not able to reproduce it locally.
But it looks like that the autopkgtests only rerun the unit tests with 
the local source code and don't test the installed package at all. I was 
able to run the tests successfully without having the package installed.
As those tests are run during the package build already, I would propose 
to remove the autopkgtests.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#955095: cyrus-sasl2: diff for NMU version 2.1.27+dfsg-2.1

[Jochen Sprickerhof]

Control: tags 955095 + patch
Control: tags 955095 + pending


Dear maintainer,

I've prepared an NMU for cyrus-sasl2 (versioned as 2.1.27+dfsg-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru cyrus-sasl2-2.1.27+dfsg/debian/changelog cyrus-sasl2-2.1.27+dfsg/debian/changelog
--- cyrus-sasl2-2.1.27+dfsg/debian/changelog	2019-12-26 15:48:32.0 +0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/changelog	2021-02-07 10:43:14.0 +0100
@@ -1,3 +1,10 @@
+cyrus-sasl2 (2.1.27+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix Sphinx errors (Closes: #955095)
+
+ -- Jochen Sprickerhof   Sun, 07 Feb 2021 10:43:14 +0100
+
 cyrus-sasl2 (2.1.27+dfsg-2) unstable; urgency=medium
 
   [ Salvatore Bonaccorso ]
diff -Nru cyrus-sasl2-2.1.27+dfsg/debian/patches/0022-Fix-sphinx-error.patch cyrus-sasl2-2.1.27+dfsg/debian/patches/0022-Fix-sphinx-error.patch
--- cyrus-sasl2-2.1.27+dfsg/debian/patches/0022-Fix-sphinx-error.patch	1970-01-01 01:00:00.0 +0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/patches/0022-Fix-sphinx-error.patch	2021-02-07 10:43:04.0 +0100
@@ -0,0 +1,74 @@
+From: Andreas Hasenack 
+Date: Sun, 7 Feb 2021 10:32:30 +0100
+Subject: Fix sphinx error
+
+---
+ docsrc/exts/sphinxlocal/builders/manpage.py | 1 -
+ docsrc/exts/sphinxlocal/roles/saslman.py| 1 -
+ docsrc/exts/sphinxlocal/writers/manpage.py  | 9 +++--
+ 3 files changed, 3 insertions(+), 8 deletions(-)
+
+diff --git a/docsrc/exts/sphinxlocal/builders/manpage.py b/docsrc/exts/sphinxlocal/builders/manpage.py
+index a6281f7..126839e 100644
+--- a/docsrc/exts/sphinxlocal/builders/manpage.py
 b/docsrc/exts/sphinxlocal/builders/manpage.py
+@@ -21,7 +21,6 @@ from docutils.frontend import OptionParser
+ from sphinx import addnodes
+ from sphinx.errors import SphinxError
+ from sphinx.builders import Builder
+-from sphinx.environment import NoUri
+ from sphinx.util.nodes import inline_all_toctrees
+ from sphinx.util.console import bold, darkgreen
+ from sphinx.writers.manpage import ManualPageWriter
+diff --git a/docsrc/exts/sphinxlocal/roles/saslman.py b/docsrc/exts/sphinxlocal/roles/saslman.py
+index f881d98..bcafeec 100644
+--- a/docsrc/exts/sphinxlocal/roles/saslman.py
 b/docsrc/exts/sphinxlocal/roles/saslman.py
+@@ -18,7 +18,6 @@ from string import Template
+ import re
+ 
+ def setup(app):
+-app.info('Initializing saslman plugin')
+ app.add_crossref_type('saslman', 'saslman', '%s', nodes.generated)
+ return
+ 
+diff --git a/docsrc/exts/sphinxlocal/writers/manpage.py b/docsrc/exts/sphinxlocal/writers/manpage.py
+index 13864e0..e8e9c3a 100644
+--- a/docsrc/exts/sphinxlocal/writers/manpage.py
 b/docsrc/exts/sphinxlocal/writers/manpage.py
+@@ -13,8 +13,9 @@
+ """
+ 
+ from docutils import nodes
++from time import strftime
++
+ from sphinx.writers.manpage import (
+-MACRO_DEF,
+ ManualPageWriter,
+ ManualPageTranslator as BaseTranslator
+ )
+@@ -22,7 +23,6 @@ from sphinx.writers.manpage import (
+ 
+ from sphinx import addnodes
+ from sphinx.locale import admonitionlabels, _
+-from sphinx.util.osutil import ustrftime
+ 
+ class CyrusManualPageWriter(ManualPageWriter):
+ 
+@@ -67,15 +67,12 @@ class CyrusManualPageTranslator(BaseTranslator):
+ if builder.config.today:
+ self._docinfo['date'] = builder.config.today
+ else:
+-self._docinfo['date'] = ustrftime(builder.config.today_fmt
++self._docinfo['date'] = strftime(builder.config.today_fmt
+   or _('%B %d, %Y'))
+ self._docinfo['copyright'] = builder.config.copyright
+ self._docinfo['version'] = builder.config.version
+ self._docinfo['manual_group'] = builder.config.project
+ 
+-# since self.append_header() is never called, need to do this here
+-self.body.append(MACRO_DEF)
+-
+ # overwritten -- don't wrap literal_block with font calls
+ self.defs['literal_block'] = ('.sp\n.nf\n', '\n.fi\n')
+ 
diff -Nru cyrus-sasl2-2.1.27+dfsg/debian/patches/0023-Fix-more-sphinx-errors.patch cyrus-sasl2-2.1.27+dfsg/debian/patches/0023-Fix-more-sphinx-errors.patch
--- cyrus-sasl2-2.1.27+dfsg/debian/patches/0023-Fix-more-sphinx-errors.patch	1970-01-01 01:00:00.0 +0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/patches/0023-Fix-more-sphinx-errors.patch	2021-02-07 10:43:07.0 +0100
@@ -0,0 +1,59 @@
+From: Jochen Sprickerhof 
+Date: Sun, 7 Feb 2021 10:33:45 +0100
+Subject: Fix more sphinx errors
+
+---
+ docsrc/conf.py  | 2 +-
+ docsrc/exts/sphinxlocal/builders/manpage.py | 5 -
+ 2 files changed, 1 insertion(+), 6 deletions(-)
+
+diff --git a/docsrc/conf.py b/docsrc/conf.py
+index ba1833c..b22ac3b 100644
+--- a/docsrc/conf.py
 b/docsrc/conf.py
+@@ -294,7 +294,7 @@ for tuple in pathset:
+ except OSError as e:
+ continue
+ for rstfile in glob.glob("*.rst"):
+-a

Bug#982652: apt: ship systemd.timer disabled by default

[Jochen Sprickerhof]

Package: apt
Version: 2.1.20
Severity: wishlist

Hi,

please ship apt-daily.timer and apt-daily-upgrade.timer disabled by
default and have unattended-upgrades enable them in postinst.

As just discussed in #debian-devel.

Thanks!

Bug#994605: ITP: python-lsp-mypy -- Mypy plugin for the Python Language Server

[Jochen Sprickerhof]

Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-lsp-mypy
  Version : 0.5.2
  Upstream Author : Richard Kellnberger, Tom van Ommeren
* URL : https://github.com/Richardk2n/pylsp-mypy
* License : Expat
  Programming Lang: Python
  Description : Mypy plugin for the Python Language Server

Plugin to support the Mypy static type checker in editors that support
the Python Language Server.

I intent to maintain the package as part of the Debian Python team here:

https://salsa.debian.org/python-team/packages/python-lsp-mypy

Bug#994608: ITP: python-lsp-flake8 -- Flake8 plugin for the Python Language Server

[Jochen Sprickerhof]

Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-lsp-flake8
  Version : 0.4.0
  Upstream Author : Randy Eckman
* URL : https://github.com/Richardk2n/pylsp-flake8
* License : Expat
  Programming Lang: Python
  Description : Flake8 plugin for the Python Language Server

Plugin to support the flake8 code checker in editors that support the Python 
Language Server.

I intent to maintain the package as part of the Debian Python team here:

https://salsa.debian.org/python-team/packages/python-lsp-flake8

Bug#994606: ITP: python-lsp-isort -- Isort plugin for the Python Language Server

[Jochen Sprickerhof]

Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-lsp-isort
  Version : 0.2.2
  Upstream Author : Florian Mounier
* URL : https://github.com/paradoxxxzero/pyls-isort
* License : Expat
  Programming Lang: Python
  Description : Isort plugin for the Python Language Server

Plugin to support the isort import sorter in editors that support the
Python Language Server.

I intent to maintain the package as part of the Debian Python team here:

https://salsa.debian.org/python-team/packages/python-lsp-isort

Bug#969373: xfonts-terminus: diff for NMU version 4.48-3.1

[Jochen Sprickerhof]

Dear maintainer,

I've prepared an NMU for xfonts-terminus (versioned as 4.48-3.1) and
uploaded it. Hope this is fine with you.

Cheers Jochen
diff -Nru xfonts-terminus-4.48/debian/changelog xfonts-terminus-4.48/debian/changelog
--- xfonts-terminus-4.48/debian/changelog	2020-05-25 11:16:29.0 +0200
+++ xfonts-terminus-4.48/debian/changelog	2021-09-19 21:54:17.0 +0200
@@ -1,3 +1,12 @@
+xfonts-terminus (4.48-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove unused bdf2psf build dependency (Closes: #969373)
+  * Rebuild against trscripts 1.18+nmu3 to fix powerline symbols (cf.
+#767442).
+
+ -- Jochen Sprickerhof   Sun, 19 Sep 2021 21:54:17 +0200
+
 xfonts-terminus (4.48-3) unstable; urgency=medium
 
   * In order to ensure smoother upgrade, xfonts-terminus now recommends
diff -Nru xfonts-terminus-4.48/debian/control xfonts-terminus-4.48/debian/control
--- xfonts-terminus-4.48/debian/control	2020-05-25 10:09:19.0 +0200
+++ xfonts-terminus-4.48/debian/control	2021-09-19 21:46:28.0 +0200
@@ -3,7 +3,7 @@
 Section: fonts
 Priority: optional
 Standards-Version: 4.5.0.2
-Build-Depends: debhelper (>=12), trscripts (>= 1.16), xfonts-utils, bdf2psf, fontforge
+Build-Depends: debhelper (>=12), trscripts (>= 1.16), xfonts-utils, fontforge
 
 Package: fonts-terminus-otb
 Architecture: all


signature.asc
Description: PGP signature

Bug#767442: trscripts: diff for NMU version 1.18+nmu3

[Jochen Sprickerhof]

Hi Anton,

* Anton Zinoviev  [2021-09-20 11:48]:

On Sun, Sep 19, 2021 at 09:34:44PM +0200, Jochen Sprickerhof wrote:


I've prepared an NMU for trscripts (versioned as 1.18+nmu3) and
uploaded it. I also took the freedom to modernize the package, hope that is
fine with you.


The changes a somewhat too big for a NMU.  So I must ask you if you
want to take over this package?  Do you want to become its maintainer?


Sorry for providing such a big (and unclean) diff, I hope you don't mind 
me working on the package.

Thanks for the maintainer offer, I don't intent to put more work into it
currently but if you want to pass maintainership I would propose to move 
it to the Debian Fonts Task Force (Cced) and have both of us as 
uploaders. What do you think?


Cheers Jochen


signature.asc
Description: PGP signature

Bug#991724: unblock: python-fakeredis/1.4.5-4

[Jochen Sprickerhof]

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

Please unblock package python-fakeredis

[ Reason ]
The last upstream release of Redis (with security updates) changed the
semantics of the SINTER[STORE] commands. This broke the autopkgtests of
python-fakeredis which compared the results against the real Redis.

[ Impact ]
Currently the security update of Redis is blocked from migrating to
testing and would need help..

[ Tests ]
fakeredis has a big test suite and I did some manual tests as well.

[ Risks ]
The change is a behaviour change but Redis upstream considers it more
correct:
https://github.com/redis/redis/issues/9273
Given that fakeredis tries to mimic the Redis behaviour and the change
is pretty minimal, I think the risk is rather small.
I've tested the only reverse build dependency in the archive (cachy) to
build fine with the new fakeredis version.
Also fakeredis upstream acknowledged the patch:
https://github.com/jamesls/fakeredis/pull/303

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

unblock python-fakeredis/1.4.5-4
diff --git a/debian/changelog b/debian/changelog
index 820c656..0aad551 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+python-fakeredis (1.4.5-4) unstable; urgency=medium
+
+  * Team upload.
+  * Bump tests dependency for new Redis behaviour
+
+ -- Jochen Sprickerhof   Fri, 30 Jul 2021 22:40:47 +0200
+
+python-fakeredis (1.4.5-3) unstable; urgency=medium
+
+  * Team upload.
+  * Add patch for new Redis 6.0.15 SINTER behaviour (Closes: #991451)
+
+ -- Jochen Sprickerhof   Fri, 30 Jul 2021 14:32:28 +0200
+
 python-fakeredis (1.4.5-2) unstable; urgency=medium
 
   * Lift pytest version cap.
diff --git a/debian/patches/0002-SINTER-STORE-requires-keys-to-be-sets.patch 
b/debian/patches/0002-SINTER-STORE-requires-keys-to-be-sets.patch
new file mode 100644
index 000..0e3fccb
--- /dev/null
+++ b/debian/patches/0002-SINTER-STORE-requires-keys-to-be-sets.patch
@@ -0,0 +1,56 @@
+From: Jochen Sprickerhof 
+Date: Fri, 30 Jul 2021 13:50:25 +0200
+Subject: SINTER[STORE] requires keys to be sets
+
+Starting with Redis 6.0.15 this behaviour changed.
+The definition of SINTER[STORE] states:
+
+"Keys that do not exist are considered to be empty sets."
+
+At the same time SINTER only accepts set:
+
+"intersection of all the given sets"
+
+Both quotes from: https://redis.io/commands/sinter.
+
+The behaviour of Redis 6.0.14 was that it ignored the type of later keys
+if it found an empty set and returned that. Radis 6.0.15 changed this
+behaviour to return a WRONGTYPE if it finds a non set key in the
+arguments.
+
+Example to reproduce:
+
+127.0.0.1:6379> FLUSHALL
+OK
+127.0.0.1:6379> SINTER a b
+(empty array)
+127.0.0.1:6379> SET b something
+OK
+127.0.0.1:6379> SINTER a b
+(error) WRONGTYPE Operation against a key holding the wrong kind of value
+
+Cf. https://github.com/redis/redis/issues/9273.
+---
+ fakeredis/_server.py | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/fakeredis/_server.py b/fakeredis/_server.py
+index f408ab7..a4f8599 100644
+--- a/fakeredis/_server.py
 b/fakeredis/_server.py
+@@ -1866,13 +1866,11 @@ class FakeSocket:
+ def sdiffstore(self, dst, *keys):
+ return self._setop(lambda a, b: a - b, False, dst, *keys)
+ 
+-# The following keys can't be marked as sets because of the
+-# stop_if_empty early-out.
+-@command((Key(set),), (Key(),))
++@command((Key(set),), (Key(set),))
+ def sinter(self, *keys):
+ return self._setop(lambda a, b: a & b, True, None, *keys)
+ 
+-@command((Key(), Key(set)), (Key(),))
++@command((Key(), Key(set)), (Key(set),))
+ def sinterstore(self, dst, *keys):
+ return self._setop(lambda a, b: a & b, True, dst, *keys)
+ 
diff --git a/debian/patches/series b/debian/patches/series
index d448f15..87b0361 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 skip-flaky-test.patch
+0002-SINTER-STORE-requires-keys-to-be-sets.patch
diff --git a/debian/tests/control b/debian/tests/control
index 91f1d97..9e7c574 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -12,6 +12,6 @@ Depends:
  python3-setuptools,
  python3-six,
  python3-sortedcontainers,
- redis-server,
+ redis-server (>= 5:6.0.15),
 Restrictions: allow-stderr, isolation-container
 Test-Command: set -e; for py in $(py3versions -i); do echo "[*] testing on 
$py:"; $py -Wd -m pytest -v -x --ignore=test/test_aioredis.py 2>&1; done

Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError

[Jochen Sprickerhof]

Control: reassign -1 python-fakeredis
Control: affects -1 redis
Control: forwarded -1 https://github.com/jamesls/fakeredis/pull/303

I've proposed a fix upstream and will upload to Debian later today.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#996013: transition: poco

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition the new POCO version. The auto generated ben
file looks fine and I have rebuild all reverse dependencies
successfully.

Cheers Jochen

Bug#996014: transition: orocos-kdl

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition orocos-kdl. The auto generated ben file looks
fine and I've rebuild all reverse dependencies successfully.

Cheers Jochen

Bug#996080: transition: pcl

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition pcl. The autogenerated ben file looks fine
and ros-perception-pcl builds against the new version. For python-pcl I
will upload a fixed version myself.

Cheers Jochen

Bug#996615: transition: ros-geometric-shapes

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition ros-geometric-shapes. The autogenerated Ben
file is ok and I've tested the downstream dependency successfully.

Cheers Jochen

Bug#996619: transition: ros-ros-comm

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: jspri...@debian.org

Hi release team,

I would like to transition ros-ros-comm. The auto generated ben file
is ok and I've rebuild all reverse dependencies successfully.

Cheers Jochen

Bug#995685: dictionaries-common: Failed to upgrade from 1.28.7

[Jochen Sprickerhof]

Hi Agustin,

* Agustin Martin  [2021-10-04 13:53]:

Do not know why your mail took this long to reach the BTS.


That's a known problem between my provider and the BTS. Normally I send 
through master.d.o because of that seems like I broke that config 
recently.



In the
meantime 1.28.11 was uploaded and I think should fix this problem.
Please check.


Looks good to me, thanks for fixing the issue and sorry for the noise.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#995685: dictionaries-common: Failed to upgrade from 1.28.7

[Jochen Sprickerhof]

Control: tag -1 patch

Hi,

* Nelson A. de Oliveira  [2021-10-04 00:15]:

While upgrading dictionaries-common from 1.28.7 to 1.28.10:

=
Configurando dictionaries-common (1.28.10) ...
dmihd: No hunspell dir passed or available
dpkg: error processing package dictionaries-common (--configure):
installed dictionaries-common package post-installation script subprocess 
returned error exit status 2
(…)
dpkg: dependency problems prevent configuration of aspell-pt-br:
aspell-pt-br depende de dictionaries-common (>= 1.23~); porém:
 Pacote dictionaries-common não está configurado ainda.

dpkg: error processing package aspell-pt-br (--configure):
problemas de dependência - deixando desconfigurado
(…)
Erros foram encontrados durante o processamento de:
dictionaries-common
aspell-pt-br
E: Sub-process /usr/bin/dpkg returned an error code (1)
=


I ran into the same problem on a system with no hunspell dictionaries 
installed. The attached patch fixes the problem for me.


Cheers Jochen
diff --git a/scripts/perl5/Debian/DictionariesCommon.pm.in b/scripts/perl5/Debian/DictionariesCommon.pm.in
index 48edc11..e3ac624 100644
--- a/scripts/perl5/Debian/DictionariesCommon.pm.in
+++ b/scripts/perl5/Debian/DictionariesCommon.pm.in
@@ -425,8 +425,8 @@ sub dc_merge_installed_hunspell_dicts {
   my $hunspelldir = shift;
   my $main_dicts  = shift;
 
-  die "dmihd: No hunspell dir passed or available\n" unless ( -d $hunspelldir);
   $main_dicts = {} unless $main_dicts;
+  return $main_dicts unless ( -d $hunspelldir);
 
   my @hunspell_aff = <$hunspelldir/*.aff>;
   my $parsed_dicts = {};


signature.asc
Description: PGP signature

Bug#1000780: eigen3 breaks pybind11 autopkgtest on ppc64el: inlining failed in call to ‘always_inline’

[Jochen Sprickerhof]

Control: affects -1 src:mrpt 


* Paul Gevers  [2021-11-28 21:25]:
With a recent upload of eigen3 the autopkgtest of pybind11 fails in 
testing when that autopkgtest is run with the binary packages of 
eigen3 from unstable. It passes when run with only packages from 
testing. In tabular form:


  passfail
eigen3 from testing3.4.0-1
pybind11   from testing2.7.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of eigen3 to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?



[..]
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h: In 
function ‘Eigen::internal::storeAccumulatorlong, 0, 0, 1>, long, double __vector(2), 2l>(long, long, 
Eigen::internal::blas_data_mapper const&, 
double __vector(2) const&, __vector_quad*)void’:
/usr/include/eigen3/Eigen/src/Core/util/BlasUtil.h:227:46: error: 
inlining failed in call to ‘always_inline’ 
‘Eigen::internal::blas_data_mapper1>::storePacketBlock(long, long, 
Eigen::internal::PacketBlock const&) 
constvoid’: target specific option mismatch
 227 |   EIGEN_DEVICE_FUNC EIGEN_ALWAYS_INLINE void 


mrpt seems to be have the same problem:

In file included from 
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProduct.h:18,
 from /usr/include/eigen3/Eigen/Core:350,
 from 
/<>/3rdparty/nanogui/include/nanogui/common.h:30,
 from 
/<>/3rdparty/nanogui/include/nanogui/opengl.h:16,
 from 
/<>/3rdparty/nanogui/include/nanogui/glutil.h:15,
 from /<>/3rdparty/nanogui/src/glutil.cpp:12:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h: In function 
‘Eigen::internal::ploadRhsMMA(float const*, float 
__vector(4)&)void’:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductCommon.h:215:28: error: 
inlining failed in call to ‘always_inline’ ‘Eigen::internal::ploadRhs(float const*)float __vector(4)’: target specific
option mismatch
  215 | EIGEN_ALWAYS_INLINE Packet ploadRhs(const Scalar* rhs)

https://buildd.debian.org/status/fetch.php?pkg=mrpt=ppc64el=1%3A2.2.0-2%2Bb1=1638024874=0

Cheers Jochen


signature.asc
Description: PGP signature

Bug#996563: ITP: ifcfg -- Python cross-platform network interface discovery (ifconfig/ipconfig/ip)

[Jochen Sprickerhof]

Hi Jose,

* Jose Luis Rivero  [2021-10-15 14:36]:

* Package name: ifcfg
 Version : 0.22
 Upstream Author : BJ Dierkes
* URL : https://github.com/ftao/python-ifcfg
* License : BSD
 Programming Lang: Python
 Description : Python cross-platform network interface discovery 
(ifconfig/ipconfig/ip)

Ifcfg is a cross-platform library for parsing ifconfig and ipconfig output in
Python. It is useful for pulling information such as IP, Netmask, MAC Address,
Hostname, etc.


I'm not sure this should be part of Debian. Parsing command line tools 
is known to be brittle and ifconfig is a well known example for this.
There is `ip -json` to provide a more machine readable output but it 
does not seem to be used by ifcfg.


Also there is already python3-psutil and python3-netifaces in Debian, 
providing the same information.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1002570: replace which by command -v in wrapper script

[Jochen Sprickerhof]

Package: thunderbird
Version: 1:91.4.1-1
Severity: minor
Tags: patch
X-Debbugs-Cc: jspri...@debian.org

Hi Carsten,

$ thunderbird
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

Can you please apply the attached patch to fix this?

Thanks!

Jochen

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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.5-1
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-3
ii  libbotan-2-182.18.2+dfsg-1
ii  libbz2-1.0   1.0.8-5
ii  libc62.33-1
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-3
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-13
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.30-4
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.32-3
ii  libnss3  2:3.73.1-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-13
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.4-1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

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

Versions of packages thunderbird suggests:
ii  apparmor  3.0.3-6
ii  fonts-lyx 2.3.6-1
ii  libgssapi-krb5-2  1.18.3-7

-- no debconf information
>From 8e004cce32987ea275677b22cfe529623fde1a39 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Fri, 24 Dec 2021 13:11:51 +0100
Subject: [PATCH] Use POSIX command -v in wrapper

which is deprecated.
---
 debian/thunderbird-wrapper.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird-wrapper.sh b/debian/thunderbird-wrapper.sh
index 13eeec1f9dc..b3f7c2e7b73 100755
--- a/debian/thunderbird-wrapper.sh
+++ b/debian/thunderbird-wrapper.sh
@@ -32,7 +32,7 @@ fi
 
 # some global variables
 MOZ_APP_NAME=thunderbird
-MOZ_APP_LAUNCHER=$(which "$0")
+MOZ_APP_LAUNCHER=$(command -v "$0")
 MOZ_LIBDIR=/usr/lib/${MOZ_APP_NAME}
 ID_PROFILE_FOLDER=${HOME}/.icedove
 TB_PROFILE_FOLDER=${HOME}/.thunderbird
-- 
2.34.1

Bug#1002063: libvtk9.1: missing Breaks+Replaces: libvtk9 (<< 9.1.0+really9.1.0)

[Jochen Sprickerhof]

Hi Andreas,

thanks for taking care of QA, I always appreciate your bug reports.


libvtk9.1: missing Breaks+Replaces: libvtk9 (<< 9.1.0+really9.1.0)


While I agree that both packages conflict, I'm not sure if proposing a 
Breaks+Replaces is the proper solution here (and in general). Normally 
we want to have the library packages to be coinstallable and thus the 
packages only provide non conflicting files. Could you maybe adopt your 
template to mention that this hints to a problem in the package and 
propose to look into resolving the conflict as an alternative solution?



There are a lot of conflicting files:
/usr/lib//vtk/hierarchy/VTK/vtk*.txt


These seem to dumps of the provided symbols. I did a quick test with 
pcl_viewer from the pcl-tools package and removing the hierarchy/ folder 
doesn't change the behaviour, So I assume we can drop the folder (or 
move it to the -dev package, maybe).


Cheers Jochen

* Andreas Beckmann  [2021-12-21 09:27]:

Package: libvtk9.1
Version: 9.1.0+really9.1.0+dfsg2-3~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid 'installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

From the attached log (scroll to the bottom...):

 Preparing to unpack .../libvtk9.1_9.1.0+really9.1.0+dfsg2-3~exp1_amd64.deb ...
 Unpacking libvtk9.1:amd64 (9.1.0+really9.1.0+dfsg2-3~exp1) ...
 dpkg: error processing archive 
/var/cache/apt/archives/libvtk9.1_9.1.0+really9.1.0+dfsg2-3~exp1_amd64.deb 
(--unpack):
  trying to overwrite 
'/usr/lib/x86_64-linux-gnu/vtk/hierarchy/VTK/vtkChartsCore-hierarchy.txt', 
which is also in package libvtk9:amd64 9.1.0+really9.0.3+dfsg1-4+b1
 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
 Errors were encountered while processing:
  /var/cache/apt/archives/libvtk9.1_9.1.0+really9.1.0+dfsg2-3~exp1_amd64.deb

There are a lot of conflicting files:
/usr/lib//vtk/hierarchy/VTK/vtk*.txt

cheers,

Andreas




--
debian-science-maintainers mailing list
debian-science-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers




signature.asc
Description: PGP signature

Bug#1002063: libvtk9.1: missing Breaks+Replaces: libvtk9 (<< 9.1.0+really9.1.0)

[Jochen Sprickerhof]

* Andreas Beckmann  [2021-12-21 21:19]:

On 21/12/2021 10.07, Jochen Sprickerhof wrote:
While I agree that both packages conflict, I'm not sure if proposing 
a Breaks+Replaces is the proper solution here (and in general). 
Normally we want to have the library packages to be coinstallable 
and thus the packages only provide non conflicting files. Could you 
maybe adopt your template to mention that this hints to a problem in 
the package and propose to look into resolving the conflict as an 
alternative solution?


What about

In case of shared library packages where the conflicting files do not 
contain the SOVERSION in their name or path, please also consider 
alternative solutions for solving the conflict and avoiding 
Breaks+Replaces for easier upgrades in the future. Ideally shared 
libraries of different SOVERSIONs should only contain non-conflicting 
files and thus be co-installable for smooth upgrades.


Sounds good :).


signature.asc
Description: PGP signature

Bug#1002049: Please add Provides: libfreetype6-dev to allow transition

[Jochen Sprickerhof]

Package: libfreetype-dev
Version: 2.11.0+dfsg-1
Severity: minor
Tags: patch
X-Debbugs-Cc: jspri...@debian.org

Hi,

please apply the attached patch to allow replacing libfreetype6-dev by
libfreetype-dev in versioned dependencies like libcairo2-dev or
libfontconfig-dev.

Cheers Jochen


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

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

Versions of packages libfreetype-dev depends on:
ii  libbrotli-dev  1.0.9-2+b3
ii  libc6-dev [libc-dev]   2.33-1
ii  libfreetype6   2.11.0+dfsg-1
ii  libpng-dev 1.6.37-3
ii  zlib1g-dev [libz-dev]  1:1.2.11.dfsg-2

libfreetype-dev recommends no packages.

Versions of packages libfreetype-dev suggests:
pn  freetype2-doc  

-- debconf-show failed
>From 98908723b8e06cfd16856e7d0912f42b350dc971 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Mon, 20 Dec 2021 23:43:43 +0100
Subject: [PATCH] Have libfreetype-dev provide 6-dev to ease transition

As documented in https://wiki.debian.org/RenamingPackages.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 1434eb0e..240679a4 100644
--- a/debian/control
+++ b/debian/control
@@ -70,6 +70,7 @@ Depends:
 Suggests: freetype2-doc (= ${binary:Version})
 Replaces: libfreetype6-dev (<< 2.10.1)
 Breaks: libfreetype6-dev (<< 2.10.1)
+Provides: libfreetype6-dev (= ${binary:Version})
 Description: FreeType 2 font engine, development files
  The FreeType project is a team of volunteers who develop free,
  portable and high-quality software solutions for digital typography.
-- 
2.34.1

Bug#979098: Bug#995843: abook: complete d/copyright file

[Jochen Sprickerhof]

Hi Rhonda,

I've seen that you pushed some commits to your repo and Salsa, great :).
Do you still plan to upload them to Debian (tesing removal would be 
tomorrow)?


I've also seen that you force pushed away some commits.. just wondering.

And yes I would be happy if you add me to the repo members, thanks!

Jochen

* Rhonda D'Vine  [2021-11-02 12:54]:

   Hey Jochen,

resolving would need to enhance the copyright file so that it fulfills
all the required information.  Bastian already did a good job and likely
the patch provided should be sufficient for that.  I haven't gotten
around yet to upload that, but plan to do so in the next few days.

I likely will move the packaging from my private git instance to salsa,
and if you are still interested I can add you to the repository indeed.

Thanks for your interest,
Rhonda


* Jochen Sprickerhof  [2021-11-02 08:20:15 CET]:

Hi Rhonda,

abook is marked for autoremoval in two days due to this bug, can you comment
on how to resolve it?

I would be happy to help maintain abook, if you need help.

Cheers Jochen

* Bastian Germann  [2021-10-13 14:40]:
> Control: tags -1 patch
>
> Hi,
>
> A copyright file for abook with the necessary fixes for this bug is enclosed.
> Please include it in a new package revision.
>
> Thanks,
> Bastian

> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Upstream-Name: abook
> Upstream-Contact: Jaakko Heinonen 
> Source: http://abook.sourceforge.net/
>
> Files: *
> Copyright: 2005, Jaakko Heinonen 
> Comment: No license version is specified for most of the code.
> Some GPL-2+ files make the project as a whole GPL-2+.
> License: GPL-2+
>
> Files: abook.1 abookrc.5
> Copyright: Alan Ford 
> License: GPL-2+
>
> Files: aclocal.m4 config.rpath Makefile.in m4/*
> Copyright: (see individual files)
> Comment: Some files come with the disclaimer, some do not.
> License: FSFULLR
>
> Files: config.guess config.sub
> Copyright: 1992-2013 Free Software Foundation, Inc.
> License: GPL-3+ with Autoconf exception
>
> Files: depcomp
> Copyright: 1999-2013 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: getname.c
> Copyright: This code was taken from hypermail
>   modified by Jaakko Heinonen 
>   .
>   For strcpymax() function:
>   Copyright (C) 1994, 1995 Enterprise Integration Technologies Corp.
>   VeriFone Inc./Hewlett-Packard. All Rights Reserved.
> Comment: See https://bugs.debian.org/979098 for details on assuming GPL-2+
> License: GPL-2+
>
> Files: getopt*
> Copyright: 1987-1997 Free Software Foundation, Inc.
> License: LGPL-2+
>
> Files: install-sh
> Copyright: 1994 X Consortium
> License: X11
>
> Files: ldif.c
> Copyright: 1992-1996 Regents of the University of Michigan.
> Comment: adapted to use with abook by JH 
> License: Michigan
> Redistribution and use in source and binary forms are permitted
> provided that this notice is preserved and that due credit is given
> to the University of Michigan at Ann Arbor. The name of the University
> may not be used to endorse or promote products derived from this
> software without specific prior written permission. This software
> is provided ``as is'' without express or implied warranty.
>
> Files: mbswidth.?
> Copyright: 2000-2002 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: misc.c
> Copyright: Jaakko Heinonen
>   1994 Lars Wirzenius
> Comment: BSD-2-clause covers the getaline() function.
> License: GPL-2+ and BSD-2-clause
>
> Files: missing
> Copyright: 1996-2013 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: po/fr.po po/it.po po/sv.po
> Copyright: 2005 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: vcard.c
> Copyright: 2012, Raphaël Droz 
> License: GPL-2+
>
> Files: views.c
> Copyright: Cedric Duval
> License: GPL-2+
>
> Files: xmalloc.c
> Copyright: 2005 Jaakko Heinonen
> License: BSD-2-clause
>
> Files: debian/*
> Copyright: 2000, Alan Ford 
>   2003, Rhonda D'Vine 
>   2015, Denis Briand 
> License: WTFPLv2
>
> License: GPL-2+
>This program is free software; you can redistribute it and/or modify
>it under the terms of the GNU General Public License as published by
>the Free Software Foundation; either version 2 of the License, or
>(at your option) any later version.
>.
>This program is distributed in the hope that it will be useful,
>but WITHOUT ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>GNU General Public License for more details.
>.
>You should have received a copy of the GNU General Public Li

Bug#999749: $PATH is reset because of Debian patch

[Jochen Sprickerhof]

Package: fish
Version: 3.3.1+ds-1
Severity: normal
X-Debbugs-Cc: jspri...@debian.org

Hi,

thanks for uploading the new fish version. Sadly it has a regression for
me due to the patch for #985153.
I set $PATH in my ~/.xsession¹ so all fish open below it will get it
from the environment. The patch for #985153 in /etc/fish/config.fish
resets $PATH so this does not work anymore.

You can reproduce the same with:

$ PATH="/tmp:$PATH" fish -c 'echo $PATH'
/usr/local/bin /usr/bin /bin /usr/local/games /usr/games

The patch can be disabled with FISH_UNIT_TESTS_RUNNING=1:

FISH_UNIT_TESTS_RUNNING=1 PATH="/tmp:$PATH" fish -c 'echo $PATH'
/tmp /usr/local/bin /usr/bin /bin /usr/local/games /usr/games

Whereas other shells:

$ PATH=/bin dash -c 'echo $PATH'
/bin
$ PATH=/bin bash -c 'echo $PATH'
/bin

This is because /etc/profile is only read for login shells:

$ PATH=/bin:/usr/bin dash -l -c 'echo $PATH'
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

So we should encapsulate the patch in `if status is-login`.

Also /usr/share/fish/vendor_conf.d is probably a better home then
/etc/fish/config.fish.

I will test this locally tomorrow and upload a new version (due to
LowNMU) if you don't disagree.

Also, the new version is missing the man pages, I will try to recover
them as well.

Cheers Jochen

¹: Actually I set it in ~/.profile and use a variable to make sure it is
only set once but that should not matter for this bug report.

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

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

Versions of packages fish depends on:
ii  bc  1.07.1-3+b1
ii  chromium [www-browser]  93.0.4577.82-1
ii  dpkg1.20.9
ii  firefox [www-browser]   94.0-2
ii  fish-common 3.3.1+ds-1
ii  libc6   2.32-4
ii  libpcre2-32-0   10.39-2
ii  libstdc++6  11.2.0-10
ii  libtinfo6   6.3-1
ii  lynx [www-browser]  2.9.0dev.10-1
ii  man-db  2.9.4-2
ii  python3 3.9.7-1
ii  python3-distutils   3.9.8-1
ii  w3m [www-browser]   0.5.3+git20210102-6

Versions of packages fish recommends:
pn  xsel  

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#997504: terminator: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Jochen Sprickerhof]

Control: reassign -1 terminator 2.1.0-2

Hi Timo,

* Timo Röhling  [2021-11-05 14:51]:

On Sat, 23 Oct 2021 22:41:30 +0200 Lucas Nussbaum  wrote:

collecting ... Trace/breakpoint trap
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=133: cd 
/<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest 
--doctest-modules
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 
returned exit code 13

I investigated this failure a bit and found that there seems to be a
segfault on instantiating terminal.Terminal(), which looks like it
is caused by the bindings in python3-gi.

I assume so because I found that the error also occurs with older
terminator versions in unstable, but not with the latest terminator
version in a bullseye chroot.

For reference, the error in unstable can be reproduced in an interactive
Python session (I ran "gdb /usr/bin/python3" to get a stacktrace):

 >>> from terminatorlib import terminal
 /build/terminator-2.1.0/terminatorlib/terminal.py:9: PyGIWarning: Pango was 
imported without specifying a version first. Use gi.require_version('Pango', 
'1.0') before import to ensure that the right version gets loaded.
   from gi.repository import GLib, GObject, Pango, Gtk, Gdk, GdkPixbuf
 /build/terminator-2.1.0/terminatorlib/terminal.py:9: PyGIWarning: Gtk was 
imported without specifying a version first. Use gi.require_version('Gtk', 
'3.0') before import to ensure that the right version gets loaded.
   from gi.repository import GLib, GObject, Pango, Gtk, Gdk, GdkPixbuf
 >>> t = terminal.Terminal()
 (.:106187): Gtk-CRITICAL **: 13:00:40.235: 
_gtk_style_provider_private_get_settings: assertion 
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
 (.:106187): Gtk-CRITICAL **: 13:00:40.235: 
_gtk_style_provider_private_get_settings: assertion 
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
 (.:106187): Gtk-CRITICAL **: 13:00:40.235: 
_gtk_style_provider_private_get_settings: assertion 
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
 Program received signal SIGSEGV, Segmentation fault.
 0x75a98a80 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
 (gdb) bt
 #0  0x75a98a80 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0


[..]

You can get a meaningful backtrace by enabling debug symbols, either by 
installing the dbgsym packages or by:


export DEBUGINFOD_URLS="https://debuginfod.debian.net;

With this I get:

#0  _gtk_settings_get_screen (settings=0x0) at 
../../../../gtk/gtksettings.c:3360
#1  0x75a2de84 in gtk_css_value_icon_theme_compute (icon_theme=, 
property_id=, provider=, style=, 
parent_style=)
at ../../../../gtk/gtkcssiconthemevalue.c:84
#2  0x75a4f658 in gtk_css_static_style_compute_value (style=0xbc4090, provider=0x0, 
parent_style=, id=3, specified=0x760d1e20 , 
section=0x0) at ../../../../gtk/gtkcssstaticstyle.c:237
#3  0x75a39dca in _gtk_css_lookup_resolve 
(lookup=lookup@entry=0xbc3100, provider=provider@entry=0x0, 
style=style@entry=0xbc4090, parent_style=parent_style@entry=0x0) at 
../../../../gtk/gtkcsslookup.c:122
#4  0x75a4f528 in gtk_css_static_style_new_compute (parent=0x0, 
matcher=0x0, provider=0x0) at ../../../../gtk/gtkcssstaticstyle.c:195
#5  gtk_css_static_style_get_default () at 
../../../../gtk/gtkcssstaticstyle.c:164
#6  0x75a3a712 in gtk_css_node_init (cssnode=0xbc0510) at 
../../../../gtk/gtkcssnode.c:667
#7  0x7778aae3 in g_type_create_instance (type=) at 
../../../gobject/gtype.c:1923
#8  0x77770cbd in g_object_new_internal (class=class@entry=0xbc3000, 
params=params@entry=0x0, n_params=n_params@entry=0) at 
../../../gobject/gobject.c:1939
#9  0x777721fd in g_object_new_with_properties (object_type=11724208, 
n_properties=0, names=names@entry=0x0, values=values@entry=0x0) at 
../../../gobject/gobject.c:2108
#10 0x77772bb1 in g_object_new (object_type=, 
first_property_name=first_property_name@entry=0x0) at ../../../gobject/gobject.c:1779
#11 0x75a5800b in gtk_css_widget_node_new 
(widget=widget@entry=0xbc1140) at ../../../../gtk/gtkcsswidgetnode.c:302
#12 0x75c41dd9 in gtk_widget_init (instance=0xbc1140, g_class=0xbc0800) 
at ../../../../gtk/gtkwidget.c:4468
#13 0x7778aae3 in g_type_create_instance (type=) at 
../../../gobject/gtype.c:1923
#14 0x77770cbd in g_object_new_internal (class=class@entry=0xbc0800, 
params=params@entry=0x0, n_params=n_params@entry=0) at 
../../../gobject/gobject.c:1939
#15 0x777721fd in g_object_new_with_properties (object_type=10410752, 
n_properties=n_properties@entry=0, names=names@entry=0x0, 
values=values@entry=0x0) at ../../../gobject/gobject.c:2108
#16 0x77900e17 in pygobject_object_new_with_properties (values=0x0, 
names=0x0, n_properties=0, object_type=) at gi/gimodule.c:1019
#17 pygobject_constructv (self=self@entry=0x753eafc0, 
n_properties=n_properties@entry=0, names=names@entry=0x0, 
values=values@entry=0x0) at 

Bug#1000736: bullseye-pu: package poco/1.10.0-6

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jspri...@debian.org

[ Reason ]
Compared to old-stable, libpoco-dev installs the cmake modules into
multi arch directories but I introduced a bug with it by installing them
into /usr/lib//cmake/cmake/Poco, i.e. with a second cmake in
the path and cmake can't find them there. This is reported in #1000656.

[ Impact ]
Poco is not found by cmake.

[ Tests ]
I tested it manually with:

find_package(Poco COMPONENTS Foundation REQUIRED)

[ Risks ]
I see the risk as low as the cmake modules are currently not usable
because the are at the wrong place. Even more, even if made available to
cmake manually, say by extending CMAKE_MODULE_PATH, they are not usable
cause the exported paths to the shared objects are wrong and they depend
on a missing FindPCRE.cmake.

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

[ Changes ]
The changes are twofold:
1. The install path of the cmake modules is corrected in the cmake
source, using GNUInstallDirs. This fixes the exported paths to the
shared objects as well.
2. d/libpoco-dev.install is adopted to the new cmake modules location
and to install the FindPCRE.cmake as well.
>From 0b20519c8c4df22c6f5fffac9d977c8eea4799c5 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Sun, 28 Nov 2021 08:25:35 +0100
Subject: [PATCH] Fix cmake files

---
 debian/changelog  |  9 +++
 debian/libpoco-dev.install|  3 +-
 ...tall-cmake-files-into-multiarch-dirs.patch | 62 +++
 debian/patches/series |  1 +
 4 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 
debian/patches/0013-Install-cmake-files-into-multiarch-dirs.patch

diff --git a/debian/changelog b/debian/changelog
index f055dcf1..d9068772 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+poco (1.10.0-6+deb11u1) bullseye; urgency=medium
+
+  * Fix cmake files (Closes: #1000656).
+ - Drop duplicated cmake/ in path so they are discoverable by cmake.
+ - Fix cmake logic to export correct paths of shared objects.
+ - Install FindPCRE.cmake, needed by PocoFoundationConfig.cmake.
+
+ -- Jochen Sprickerhof   Sun, 28 Nov 2021 08:18:29 +0100
+
 poco (1.10.0-6) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --git a/debian/libpoco-dev.install b/debian/libpoco-dev.install
index 2ab89382..68f197b8 100644
--- a/debian/libpoco-dev.install
+++ b/debian/libpoco-dev.install
@@ -1,3 +1,4 @@
 usr/include/*
 usr/lib/*/lib*.so
-usr/lib/cmake usr/lib/${DEB_HOST_MULTIARCH}/cmake
+usr/lib/*/cmake
+cmake/FindPCRE.cmake usr/lib/${DEB_HOST_MULTIARCH}/cmake/Poco/
diff --git a/debian/patches/0013-Install-cmake-files-into-multiarch-dirs.patch 
b/debian/patches/0013-Install-cmake-files-into-multiarch-dirs.patch
new file mode 100644
index ..afe6c036
--- /dev/null
+++ b/debian/patches/0013-Install-cmake-files-into-multiarch-dirs.patch
@@ -0,0 +1,62 @@
+From: Jochen Sprickerhof 
+Date: Sun, 28 Nov 2021 08:16:05 +0100
+Subject: Install cmake files into multiarch dirs
+
+---
+ CMakeLists.txt | 3 ++-
+ cmake/PocoMacros.cmake | 6 +++---
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index e9d144e..2c4b716 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -438,12 +438,13 @@ write_basic_package_version_file(
+ )
+ 
+ configure_file(cmake/${PROJECT_NAME}Config.cmake.in 
"${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}/${PROJECT_NAME}Config.cmake" @ONLY)
++include(GNUInstallDirs)
+ install(
+ FILES
+ 
${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}/${PROJECT_NAME}Config.cmake
+ 
${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}/${PROJECT_NAME}ConfigVersion.cmake
+ DESTINATION
+-"lib${LIB_SUFFIX}/cmake/${PROJECT_NAME}"
++"${CMAKE_INSTALL_LIBDIR}/cmake/${PROJECT_NAME}"
+ COMPONENT
+ Devel
+ )
+diff --git a/cmake/PocoMacros.cmake b/cmake/PocoMacros.cmake
+index 652fc7d..7070f9c 100644
+--- a/cmake/PocoMacros.cmake
 b/cmake/PocoMacros.cmake
+@@ -235,18 +235,19 @@ configure_file("cmake/Poco${target_name}Config.cmake"
+ 
+ set(ConfigPackageLocation "lib/cmake/${PROJECT_NAME}")
+ 
++include(GNUInstallDirs)
+ install(
+ EXPORT "${target_name}Targets"
+ FILE "${PROJECT_NAME}${target_name}Targets.cmake"
+ NAMESPACE "${PROJECT_NAME}::"
+-DESTINATION "lib${LIB_SUFFIX}/cmake/${PROJECT_NAME}"
++DESTINATION "${CMAKE_INSTALL_LIBDIR}/cmake/${PROJECT_NAME}"
+ )
+ 
+ install(
+ FILES
+ 
"${CMAKE_BINARY_DIR}/${PROJECT_NAME}/${PROJECT_NAME}${target_name}Config.cmake"
+ 
"${CMAKE_B

Bug#1000641: RM: libopencv4.2-java -- ROM; superseeded by libopencv4.5-java

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: jspri...@debian.org

Hi ftp masters,

Please remove libopencv4.2-java from unstable.
I believe it was not removed automatically because the package switched
from arch:all to arch:any with libopencv4.5-java.

Thanks!

Jochen

Bug#1000611: libvtk9{,-qt}: soname change without library transition

[Jochen Sprickerhof]

Hi Anton,

* Anton Gladky  [2021-11-25 22:07]:

thanks for the bug report. It was really an accidental upload into
unstable instead of experimental. Yes, I will rename the package
and upload it ASAP.


What about uploading the old 9.0.3+dfsg1-3 as 9.1.0+really9.0.3+dfsg1-3 
in the meantime to fix unstable?


Cheers Jochen


Am Do., 25. Nov. 2021 um 22:03 Uhr schrieb Adrian Bunk :


Package: libvtk9
Version: 9.1.0+dfsg2-2
Severity: serious
Control: affects -1 libvtk9-qt src:vtk9

https://ci.debian.net/data/autopkgtest/testing/amd64/f/freecad/16980590/log.gz

...
ERROR: TestFemApp (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: TestFemApp
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File "/usr/share/freecad/Mod/Fem/TestFemApp.py", line 33, in 
from femtest.app.test_mesh import TestMeshCommon as FemTest07
  File "/usr/share/freecad/Mod/Fem/femtest/app/test_mesh.py", line 33, in 

import Fem
ImportError: libvtkFiltersExtraction-9.0.so.1: cannot open shared object file: 
No such file or directory
...


The soname of the vtk9 libraries is not 9, it is 9.0 for VTK 9.0
and 9.1 for VTK 9.1:

$  objdump -p /usr/lib/x86_64-linux-gnu/libvtkChartsCore-9.1.so.1 | grep SONAME
  SONAME   libvtkChartsCore-9.1.so.1
$

In bullseye libvtk9 and libvtk9-qt should have been named
libvtk9.0 and libvtk9.0-qt, but this alone is harmless.

Not harmless is that the libraries must transition to the new
soname in 9.1, renaming the packages to libvtk9.1 and libvtk9.1-qt.

--
debian-science-maintainers mailing list
debian-science-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers


signature.asc
Description: PGP signature

Bug#999594: libyaml-cpp-dev: empty YAML_CPP_LIBRARIES in yaml-cpp-config.cmake

[Jochen Sprickerhof]

Control: forwarded -1 https://github.com/jbeder/yaml-cpp/issues/774
Control: tag -1 + patch

* Sebastian Ramacher  [2021-11-13 01:18]:

Based on what I can tell from 0.6.3-10,
/usr/lib/*/cmake/yaml-cpp/yaml-cpp-config.cmake should have
YAML_CPP_LIBRARIES set to yaml-cpp. With the current version this is no
longer the case. I think this issue causes at least ros-rviz and
dcm2niix fail to build


Seems like there is an upstream bug for it for some time.
I've attached a simple patch to fix this.
See also my comment in the upstream PR:

https://github.com/jbeder/yaml-cpp/pull/1037/files#r748763058

Cheers Jochen
Description: Fix empty YAML_CPP_LIBRARIES
 The new version does not set EXPORT_TARGETS. As the value should be yaml-cpp
 anyhow, just set it directly.
Author: Jochen Sprickerhof 
Bug: https://github.com/jbeder/yaml-cpp/issues/774
Bug-Debian: https://bugs.debian.org/999594
Forwarded: https://github.com/jbeder/yaml-cpp/pull/1037
Last-Update: 2021-11-13

--- yaml-cpp-0.7.0+dfsg.orig/yaml-cpp-config.cmake.in
+++ yaml-cpp-0.7.0+dfsg/yaml-cpp-config.cmake.in
@@ -11,4 +11,4 @@ set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTA
 include("${YAML_CPP_CMAKE_DIR}/yaml-cpp-targets.cmake")
 
 # These are IMPORTED targets created by yaml-cpp-targets.cmake
-set(YAML_CPP_LIBRARIES "@EXPORT_TARGETS@")
+set(YAML_CPP_LIBRARIES "yaml-cpp")


signature.asc
Description: PGP signature

Bug#1000608: buster-pu: package ros-ros-comm/1.14.3+ds1-5+deb10u2

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jspri...@debian.org

[ Reason ]
CVE-2021-37146 was published with a denial of service against
ros-ros-comm.

[ Impact ]
The impact is rather low as the ROS middleware has no authentication nor
security features implemented and should only be used behind a firewall.
Still would be good to get it fixed in old-stable.

[ Tests ]
The patch adds a unit test and I ran manual tests using the relay
command from the topic-tools package.

[ Risks ]
Except for one new method (nextTagData) I see the code as rather simple,
and the risk as low.
For nextTagData the difference is that it is more strict in parsing only
the next xml tag which should be fine in the defined domain. Also this
is part of the upstream releases and also in unstable since some time.

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

[ Changes ]
The patches add three things:
- Null pointer checks in XmlRpc.
- Add and update unit tests for the new changes.
- A new nextTagData method. This is an improved version of the old
  parseTag version. Both methods extract the data inside of a given xml
  tag in a string. The old parseTag used find to search for the
  requested tag. The new nextTagData only allows space characters in
  front of the expected xml tag.

[ Other info ]
I kept the individual patches as upstream merged them, hope that is
fine.
>From 1e0c5a384e036b2b4ee513c3f8514de3a8f77c9f Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Wed, 20 Oct 2021 21:44:38 +0200
Subject: [PATCH] 1.14.3+ds1-5+deb10u3 (CVE-2021-37146)

---
 debian/changelog  |   6 +
 .../0015-Fix-oversize-string-test.patch   |  25 +
 ...fensive-checks-for-offset-being-NULL.patch |  45 ++
 ...-tests-for-XML-tag-utility-functions.patch | 653 ++
 ...18-Add-implementation-of-nextTagData.patch | 167 +
 ...h-structFromXml-to-using-nextTagData.patch |  22 +
 debian/patches/series |   5 +
 7 files changed, 923 insertions(+)
 create mode 100644 debian/patches/0015-Fix-oversize-string-test.patch
 create mode 100644 
debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch
 create mode 100644 
debian/patches/0017-Add-unit-tests-for-XML-tag-utility-functions.patch
 create mode 100644 debian/patches/0018-Add-implementation-of-nextTagData.patch
 create mode 100644 
debian/patches/0019-Switch-structFromXml-to-using-nextTagData.patch

diff --git a/debian/changelog b/debian/changelog
index 420c997..c3cc30a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-ros-comm (1.14.3+ds1-5+deb10u3) buster; urgency=medium
+
+  * Add https://github.com/ros/ros_comm/pull/2186 (Fix CVE-2021-37146)
+
+ -- Jochen Sprickerhof   Wed, 20 Oct 2021 21:43:47 +0200
+
 ros-ros-comm (1.14.3+ds1-5+deb10u2) buster; urgency=high
 
   * Add https://github.com/ros/ros_comm/pull/2065 (Fix CVE-2020-16124)
diff --git a/debian/patches/0015-Fix-oversize-string-test.patch 
b/debian/patches/0015-Fix-oversize-string-test.patch
new file mode 100644
index 000..489b651
--- /dev/null
+++ b/debian/patches/0015-Fix-oversize-string-test.patch
@@ -0,0 +1,25 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 14:34:14 +
+Subject: Fix oversize string test.
+
+It claims to be "well-formed", but the closing tag was wrong.
+Fix that here.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/test/TestValues.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utilities/xmlrpcpp/test/TestValues.cpp 
b/utilities/xmlrpcpp/test/TestValues.cpp
+index acd79c2..48730fd 100644
+--- a/utilities/xmlrpcpp/test/TestValues.cpp
 b/utilities/xmlrpcpp/test/TestValues.cpp
+@@ -180,7 +180,7 @@ TEST(XmlRpc, testOversizeString) {
+   try {
+ std::string xml = "";
+ xml += std::string(__INT_MAX__, 'a');
+-xml += "a";
++xml += "a";
+ int offset;
+ 
+ offset = 0;
diff --git 
a/debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch 
b/debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch
new file mode 100644
index 000..b0e024b
--- /dev/null
+++ b/debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch
@@ -0,0 +1,45 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 17:23:39 +
+Subject: Add defensive checks for offset being NULL.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/src/XmlRpcUtil.cpp | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp 
b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+index ab0991d..a964b94 100644
+--- a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
 b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+@@ -108,6 +108,7 @@ void XmlRpcUtil

Bug#1000607: bullseye-pu: package ros-ros-comm/1.15.9-ds1-7

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jspri...@debian.org

[ Reason ]
CVE-2021-37146 was published with a denial of service against
ros-ros-comm.

[ Impact ]
The impact is rather low as the ROS middleware has no authentication nor
security features implemented and should only be used behind a firewall.
Still would be good to get it fixed in stable.

[ Tests ]
The patch adds a unit test and I ran manual tests using the relay
command from the topic-tools package.

[ Risks ]
Except for one new method (nextTagData) I see the code as rather simple,
and the risk as low.
For nextTagData the difference is that it is more strict in parsing only
the next xml tag which should be fine in the defined domain. Also this
is part of the upstream releases and also in unstable since some time.

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

[ Changes ]
The patches add three things:
- Null pointer checks in XmlRpc.
- Add and update unit tests for the new changes.
- A new nextTagData method. This is an improved version of the old
  parseTag version. Both methods extract the data inside of a given xml
  tag in a string. The old parseTag used find to search for the
  requested tag. The new nextTagData only allows space characters in
  front of the expected xml tag.

[ Other info ]
I kept the individual patches as upstream merged them, hope that is
fine.
>From 5f40cf6d70e063b1684651794cfb75aaca68bee3 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Wed, 20 Oct 2021 21:27:15 +0200
Subject: [PATCH] 1.15.9+ds1-7+deb11u1 (CVE-2021-37146)

---
 debian/changelog  |   6 +
 .../0010-Fix-oversize-string-test.patch   |  25 +
 ...fensive-checks-for-offset-being-NULL.patch |  45 ++
 ...-tests-for-XML-tag-utility-functions.patch | 653 ++
 ...13-Add-implementation-of-nextTagData.patch | 167 +
 ...h-structFromXml-to-using-nextTagData.patch |  31 +
 debian/patches/series |   5 +
 7 files changed, 932 insertions(+)
 create mode 100644 debian/patches/0010-Fix-oversize-string-test.patch
 create mode 100644 
debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch
 create mode 100644 
debian/patches/0012-Add-unit-tests-for-XML-tag-utility-functions.patch
 create mode 100644 debian/patches/0013-Add-implementation-of-nextTagData.patch
 create mode 100644 
debian/patches/0014-Switch-structFromXml-to-using-nextTagData.patch

diff --git a/debian/changelog b/debian/changelog
index 057deda..a4d8cf2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-ros-comm (1.15.9+ds1-7+deb11u1) bullseye; urgency=medium
+
+  * Add https://github.com/ros/ros_comm/pull/2185 (Fix CVE-2021-37146)
+
+ -- Jochen Sprickerhof   Wed, 20 Oct 2021 21:28:10 +0200
+
 ros-ros-comm (1.15.9+ds1-7) unstable; urgency=medium
 
   * Fix Breaks+Replace
diff --git a/debian/patches/0010-Fix-oversize-string-test.patch 
b/debian/patches/0010-Fix-oversize-string-test.patch
new file mode 100644
index 000..2c4d781
--- /dev/null
+++ b/debian/patches/0010-Fix-oversize-string-test.patch
@@ -0,0 +1,25 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 14:34:14 +
+Subject: Fix oversize string test.
+
+It claims to be "well-formed", but the closing tag was wrong.
+Fix that here.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/test/TestValues.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utilities/xmlrpcpp/test/TestValues.cpp 
b/utilities/xmlrpcpp/test/TestValues.cpp
+index ce51bce..3cd0ade 100644
+--- a/utilities/xmlrpcpp/test/TestValues.cpp
 b/utilities/xmlrpcpp/test/TestValues.cpp
+@@ -214,7 +214,7 @@ TEST(XmlRpc, testOversizeString) {
+   try {
+ std::string xml = "";
+ xml += std::string(__INT_MAX__, 'a');
+-xml += "a";
++xml += "a";
+ int offset;
+ 
+ offset = 0;
diff --git 
a/debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch 
b/debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch
new file mode 100644
index 000..6426089
--- /dev/null
+++ b/debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch
@@ -0,0 +1,45 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 17:23:39 +
+Subject: Add defensive checks for offset being NULL.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/src/XmlRpcUtil.cpp | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp 
b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+index 111737a..c203a91 100644
+--- a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
 b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+@@ -108,6 +108,7 @@ void XmlRpcUtil::error(const char* fmt, ...)
+ std::string 
+ XmlRpc

Bug#979098: Bug#995843: abook: complete d/copyright file

[Jochen Sprickerhof]

Hi Rhonda,

abook is marked for autoremoval in two days due to this bug, can you 
comment on how to resolve it?


I would be happy to help maintain abook, if you need help.

Cheers Jochen

* Bastian Germann  [2021-10-13 14:40]:

Control: tags -1 patch

Hi,

A copyright file for abook with the necessary fixes for this bug is enclosed.
Please include it in a new package revision.

Thanks,
Bastian



Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: abook
Upstream-Contact: Jaakko Heinonen 
Source: http://abook.sourceforge.net/

Files: *
Copyright: 2005, Jaakko Heinonen 
Comment: No license version is specified for most of the code.
Some GPL-2+ files make the project as a whole GPL-2+.
License: GPL-2+

Files: abook.1 abookrc.5
Copyright: Alan Ford 
License: GPL-2+

Files: aclocal.m4 config.rpath Makefile.in m4/*
Copyright: (see individual files)
Comment: Some files come with the disclaimer, some do not.
License: FSFULLR

Files: config.guess config.sub
Copyright: 1992-2013 Free Software Foundation, Inc.
License: GPL-3+ with Autoconf exception

Files: depcomp
Copyright: 1999-2013 Free Software Foundation, Inc.
License: GPL-2+

Files: getname.c
Copyright: This code was taken from hypermail
  modified by Jaakko Heinonen 
  .
  For strcpymax() function:
  Copyright (C) 1994, 1995 Enterprise Integration Technologies Corp.
  VeriFone Inc./Hewlett-Packard. All Rights Reserved.
Comment: See https://bugs.debian.org/979098 for details on assuming GPL-2+
License: GPL-2+

Files: getopt*
Copyright: 1987-1997 Free Software Foundation, Inc.
License: LGPL-2+

Files: install-sh
Copyright: 1994 X Consortium
License: X11

Files: ldif.c
Copyright: 1992-1996 Regents of the University of Michigan.
Comment: adapted to use with abook by JH 
License: Michigan
Redistribution and use in source and binary forms are permitted
provided that this notice is preserved and that due credit is given
to the University of Michigan at Ann Arbor. The name of the University
may not be used to endorse or promote products derived from this
software without specific prior written permission. This software
is provided ``as is'' without express or implied warranty.

Files: mbswidth.?
Copyright: 2000-2002 Free Software Foundation, Inc.
License: GPL-2+

Files: misc.c
Copyright: Jaakko Heinonen
  1994 Lars Wirzenius
Comment: BSD-2-clause covers the getaline() function.
License: GPL-2+ and BSD-2-clause

Files: missing
Copyright: 1996-2013 Free Software Foundation, Inc.
License: GPL-2+

Files: po/fr.po po/it.po po/sv.po
Copyright: 2005 Free Software Foundation, Inc.
License: GPL-2+

Files: vcard.c
Copyright: 2012, Raphaël Droz 
License: GPL-2+

Files: views.c
Copyright: Cedric Duval
License: GPL-2+

Files: xmalloc.c
Copyright: 2005 Jaakko Heinonen
License: BSD-2-clause

Files: debian/*
Copyright: 2000, Alan Ford 
  2003, Rhonda D'Vine 
  2015, Denis Briand 
License: WTFPLv2

License: GPL-2+
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.
   .
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
   .
   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
   MA 02110-1301 USA.
   .
On Debian GNU/Linux systems, the complete text of the GNU General
Public License version 2 can be found in `/usr/share/common-licenses/GPL-2',
later versions can be found in the same directory.

License: GPL-3+ with Autoconf exception
This file is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.
.
You should have received a copy of the GNU General Public License
along with this program; if not, see .
.
As a special exception to the GNU General Public License, if you
distribute this file as part of a program that contains a
configuration script generated by Autoconf, you may include it under
the same distribution terms that you use for the rest of that
program.  This Exception is an additional permission under section 7
of the GNU General Public License, version 3 ("GPLv3").
.
On Debian GNU/Linux systems, the 

Bug#998605: krita: FTBFS: sip: /usr/lib/python3/dist-packages/PyQt5/bindings/QtCore/QtCoremod.sip:23: syntax error

[Jochen Sprickerhof]

Hi Dmitry,

* Dmitry Shachnev  [2021-11-05 00:28]:

Hi,

On Thu, Nov 04, 2021 at 08:49:47PM +0100, Lucas Nussbaum wrote:

During a rebuild of all packages in sid, your package failed to build
on amd64.

Relevant part (hopefully):
> sip: /usr/lib/python3/dist-packages/PyQt5/bindings/QtCore/QtCoremod.sip:23: 
syntax error


It looks like a result of recent pyqt5 update — it broke compatibility with
SIP 4.


Agreed, this also affects src:ros-rviz, src:qgis and src:pyqwt3d, in 
#998561, #998567 and #998595. I didn't reassign the bugs as sip4 is 
deprecated.



This issue was discussed on PyQt mailing list yesterday [1], but the upstream
developer said he is not going to rush to fix this.

I don't know what this means, but if there is a fix at least in upstream Vcs
or snapshots, I will cherry-pick it.


The easy fix would be to revert the change in

/usr/lib/python3/dist-packages/PyQt5/bindings/QtCore/QtCoremod.sip:23

for now, i.e.:

- %Module(name=PyQt5.QtCore, call_super_init=True, default_VirtualErrorHandler=PyQt5, 
keyword_arguments="Optional", use_limited_api=True, py_ssize_t_clean=True)
+ %Module(name=PyQt5.QtCore, call_super_init=True, default_VirtualErrorHandler=PyQt5, 
keyword_arguments="Optional", use_limited_api=True)

Alternatively we could add py_ssize_t_clean to the sip4 parser, see the 
attached patch.


I've verified that both fix ros-rviz.

Looking at

https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=mitya57%40debian.org=sip5

I guess we want to src:ros-rviz and src:qgis to the list.
Do you have any documentation on how to port from sip4 to sip6?
Esp how to do code generation like /usr/bin/sip with sip6.

Cheers Jochen
diff --git a/sipgen/metasrc/lexer.l b/sipgen/metasrc/lexer.l
--- a/sipgen/metasrc/lexer.l
+++ b/sipgen/metasrc/lexer.l
@@ -174,6 +174,7 @@ SIP_QOBJECT {return TK_QOBJECT;}
 timestamp{return TK_TIMESTAMP;}
 type {return TK_TYPE;}
 use_argument_names   {return TK_USEARGNAMES;}
+py_ssize_t_clean {return TK_PYSSIZETCLEAN;}
 use_limited_api  {return TK_USELIMITEDAPI;}
 all_raise_py_exception   {return TK_ALLRAISEPYEXC;}
 call_super_init  {return TK_CALLSUPERINIT;}
diff --git a/sipgen/metasrc/parser.y b/sipgen/metasrc/parser.y
--- a/sipgen/metasrc/parser.y
+++ b/sipgen/metasrc/parser.y
@@ -389,6 +389,7 @@ static scopedNameDef *fullyQualifiedName(scopedNameDef *snd);
 %token  TK_TIMESTAMP
 %token  TK_TYPE
 %token  TK_USEARGNAMES
+%token  TK_PYSSIZETCLEAN
 %token  TK_USELIMITEDAPI
 %token  TK_ALLRAISEPYEXC
 %token  TK_CALLSUPERINIT
@@ -2012,6 +2013,18 @@ module_arg: TK_KWARGS '=' TK_STRING_VALUE {
 $$.call_super_init = -1;
 $$.def_error_handler = NULL;
 }
+|   TK_PYSSIZETCLEAN '=' bool_value {
+$$.token = TK_PYSSIZETCLEAN;
+
+$$.c_module = FALSE;
+$$.kwargs = defaultKwArgs;
+$$.name = NULL;
+$$.use_arg_names = FALSE;
+$$.use_limited_api = FALSE;
+$$.all_raise_py_exc = FALSE;
+$$.call_super_init = -1;
+$$.def_error_handler = NULL;
+}
 |   TK_USELIMITEDAPI '=' bool_value {
 $$.token = TK_USELIMITEDAPI;
 


signature.asc
Description: PGP signature

Bug#997530: mrpt: FTBFS

[Jochen Sprickerhof]

Control: reassign 997519 catkin
Control: reassign 997527 catkin
Control: reassign 997530 catkin
Control: forcemerge 997519 997527 997530
Control: affects 997519 src:ros-image-pipeline src:ros-opencv-apps src:mrpt

Hi José,

* José Luis Blanco-Claraco  [2021-10-24 05:20]:

I've investigated this and found that the error comes from building
against a version of the package "cv_bridge" (libcv-bridge-dev) which
wasn't yet rebuilt against the latest opencv 4.5.4, but for the older
4.5.3.


It is actually a regression in catkin, a patch was dropped by accident. 
I will upload a fixed version soon and also give libcv-bridge-dev a 
rebuild.



Does this still qualify as a FTBFS error in mrpt? "libcv-bridge-dev"
is already listed in d/control... (?).


Well, mrpt currently dos not build in in unstable, so FTBFS is correct. 
I've reassigned the bug and added affects according to my comment above.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1001051: texlive-base postinst uses which

[Jochen Sprickerhof]

Package: texlive-base
Version: 2021.20211127-1
Severity: normal
Tags: patch
X-Debbugs-Cc: jspri...@debian.org

Hi,

installing textlive-base gives:

$ sudo apt install texlive-base
[..]
Setting up texlive-base (2021.20211127-1) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

The attached patch fixes this.
You can also just press merge here:

https://github.com/debian-tex/texlive-nonbin/pull/3

Answering your question from there:

> According to the CTTE decision the "which" command will continue to exist. 
> Should we nevertheless prepare for the removal of it.

The CTTE stated that "For the Debian 12 release, we expect which(1) to
be in either an Essential package or a transitively Essential package"
this does not mean that which(1) will be there indefinitely. Contrary to
which, command -v is specified by POSIX and meant to stay. So this patch
is to help for a future transition.
>From eebe6baf1b311c6f4fd01e788f8f4769712de071 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Wed, 1 Dec 2021 23:35:27 +0100
Subject: [PATCH] Use command -v instead of which

---
 texlive-base/debian/texlive-base.postinst.pre | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/texlive-base/debian/texlive-base.postinst.pre 
b/texlive-base/debian/texlive-base.postinst.pre
index 640e11c..05fbc13 100644
--- a/texlive-base/debian/texlive-base.postinst.pre
+++ b/texlive-base/debian/texlive-base.postinst.pre
@@ -34,7 +34,7 @@ case "$1" in
 rm -f $file.ucf-new
 rm -f $file.ucf-dist
 ucf --purge $file
-if test -x "`which ucfr`" ; then
+if command -v ucfr ; then
   ucfr --purge texlive-base $file
 fi
   done

Bug#1001541: run-time shared lib not placed in package with proper name

[Jochen Sprickerhof]

Package: ecl
Version: 21.2.1+ds-1
Severity: critical
X-Debbugs-Cc: jspri...@debian.org

Hi,

according to policy:

"The run-time shared library must be placed in a package whose name
changes whenever the SONAME of the shared library changes."

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

This breaks unrelated software, for example sagemath:

$ sage -c "solve(x, x)"
Traceback (most recent call last):
  File "/usr/share/sagemath/bin/sage-eval", line 10, in 
eval(compile(s,'','exec'))
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sage/symbolic/relation.py", line 1044, 
in solve
return _solve_expression(f, x, explicit_solutions, multiplicities, 
to_poly_solve, solution_dict, algorithm, domain)
  File "/usr/lib/python3/dist-packages/sage/symbolic/relation.py", line 1283, 
in _solve_expression
m = ex._maxima_()
  File "sage/symbolic/expression.pyx", line 1015, in 
sage.symbolic.expression.Expression._maxima_ 
(build/cythonized/sage/symbolic/expression.cpp:7931)
  File "sage/structure/sage_object.pyx", line 680, in 
sage.structure.sage_object.SageObject._interface_ 
(build/cythonized/sage/structure/sage_object.c:5480)
  File "sage/misc/lazy_import.pyx", line 329, in 
sage.misc.lazy_import.LazyImport.__getattr__ 
(build/cythonized/sage/misc/lazy_import.c:3870)
  File "sage/misc/lazy_import.pyx", line 191, in 
sage.misc.lazy_import.LazyImport.get_object 
(build/cythonized/sage/misc/lazy_import.c:2435)
  File "sage/misc/lazy_import.pyx", line 228, in 
sage.misc.lazy_import.LazyImport._get_object 
(build/cythonized/sage/misc/lazy_import.c:2842)
  File "sage/misc/lazy_import.pyx", line 224, in 
sage.misc.lazy_import.LazyImport._get_object 
(build/cythonized/sage/misc/lazy_import.c:2704)
  File "/usr/lib/python3/dist-packages/sage/interfaces/maxima_lib.py", line 92, 
in 
from sage.libs.ecl import EclObject, ecl_eval
ImportError: libecl.so.20.4: cannot open shared object file: No such file or 
directory


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

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

Versions of packages ecl depends on:
ii  gcc   4:11.2.0-2
ii  libatomic-ops-dev 7.6.12-1
ii  libc6 2.32-5
ii  libffi-dev3.4.2-3
ii  libffi8   3.4.2-3
ii  libgc-dev 1:8.0.6-1.1
ii  libgc11:8.0.6-1.1
ii  libgmp-dev2:6.2.1+dfsg-3
ii  libgmp10  2:6.2.1+dfsg-3
ii  libncurses-dev [libncurses5-dev]  6.3-1
ii  libncurses5-dev   6.3-1

ecl recommends no packages.

Versions of packages ecl suggests:
pn  ecl-doc  
pn  slime

-- no debconf information

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Jochen Sprickerhof]

Hi Alejandro,

* Alejandro Colomar (man-pages)  [2021-07-03 19:13]:

It seems that they decided long ago to drop support for pkg-config
files.  See
 and


Their only response is "consider using cmake's `find_package()`", which
is not an option for me, and BTW not an option also in many other
important projects.


I talked to them and the agreed to accept patches if the pkg-config 
files are generated automatically. Would you be interested to provide a 
patch? There is some code in PCL for this you could borrow, maybe.



What should we do about it?  Maintain our pkg-config files in Debian?


I think that would be to big of a patch.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#991407: unblock: pppoeconf/1.21+nmu2

[Jochen Sprickerhof]

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

Please unblock package pppoeconf

[ Reason ]
pppoe-discovery from the ppp package dropped the -A option in a recent
version. As the option had no function in old version, I dropped it from
the pppoeconf call to pppoe-discovery (#990978).

[ Impact ]
Without this change pppoeconf in bullseye is broken as it will not find
any modem.

[ Tests ]
I was able to reproduce the bug and also that it does not happen anymore
with the new version.

[ Risks ]
The patch only removes an old noop option in a shell script. I don't see
a risk.

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

[ Other info ]
I've added a patch with two typo fixes for the man page which I found in
the BTS.

unblock pppoeconf/1.21+nmu2
diff -Nru pppoeconf-1.21+nmu1/debian/changelog 
pppoeconf-1.21+nmu2/debian/changelog
--- pppoeconf-1.21+nmu1/debian/changelog2021-01-01 16:42:10.0 
+0100
+++ pppoeconf-1.21+nmu2/debian/changelog2021-07-22 20:51:01.0 
+0200
@@ -1,3 +1,14 @@
+pppoeconf (1.21+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove -A option from pppoe-discovery (Closes: #990978).
+It had no function anymore and was removed in new versions.
+Thanks: Michael Prokop
+  * Apply two manpage corrections (Closes: #814354).
+Thanks: Christoph Biedl
+
+ -- Jochen Sprickerhof   Thu, 22 Jul 2021 20:51:01 +0200
+
 pppoeconf (1.21+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru pppoeconf-1.21+nmu1/pppoeconf pppoeconf-1.21+nmu2/pppoeconf
--- pppoeconf-1.21+nmu1/pppoeconf   2013-12-27 03:07:24.0 +0100
+++ pppoeconf-1.21+nmu2/pppoeconf   2021-07-22 20:49:37.0 +0200
@@ -190,7 +190,7 @@
 
 touch $TMP/pppoe.scan
 ip link set $iface up
-($DISCOVERY_PROGRAM $mmm -A -I $iface > $TMP/$iface.pppoe ; rm 
$TMP/pppoe.scan) &
+($DISCOVERY_PROGRAM $mmm -I $iface > $TMP/$iface.pppoe ; rm 
$TMP/pppoe.scan) &
 
 ( time=0 ; while test -f $TMP/pppoe.scan ; do time=`expr $time + 
6`; echo $time; sleep 1; done ) | $DIALOG --title "$title" --gauge "$text 
$mmode" 10 60 0
 
diff -Nru pppoeconf-1.21+nmu1/pppoeconf.8.sgml 
pppoeconf-1.21+nmu2/pppoeconf.8.sgml
--- pppoeconf-1.21+nmu1/pppoeconf.8.sgml2013-12-27 03:07:24.0 
+0100
+++ pppoeconf-1.21+nmu2/pppoeconf.8.sgml2021-07-22 20:50:22.0 
+0200
@@ -70,12 +70,12 @@
 DESCRIPTION
 
 The  program is user-friendly dialog
- based setup tool for pppd (and pppoe
- if needed). It will look for existing ethernet cards and look for ADSL
+ based setup tool for pppd (and 
pppoe if
+ needed). It will look for existing ethernet cards and look for ADSL
  hardware connected to one of them. You can add an interface name
  iface to force  to use it. Then it will get
  some login info and do some minor modifications to make working
- settings. Note that you can use ESC key to exit program when you 
wan.
+ settings. Note that you can use ESC key to exit program when you 
want.
 
   
   

Bug#991404: pppoeconf: diff for NMU version 1.21+nmu2

[Jochen Sprickerhof]

Package: pppoeconf
Version: 1.21+nmu1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for pppoeconf (versioned as 1.21+nmu2) and
uploaded it. I will also ask the release team to accept this into 
bullseye.


Regards

Jochen
diff -Nru pppoeconf-1.21+nmu1/debian/changelog pppoeconf-1.21+nmu2/debian/changelog
--- pppoeconf-1.21+nmu1/debian/changelog	2021-01-01 16:42:10.0 +0100
+++ pppoeconf-1.21+nmu2/debian/changelog	2021-07-22 20:51:01.0 +0200
@@ -1,3 +1,14 @@
+pppoeconf (1.21+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove -A option from pppoe-discovery (Closes: #990978).
+It had no function anymore and was removed in new versions.
+Thanks: Michael Prokop
+  * Apply two manpage corrections (Closes: #814354).
+Thanks: Christoph Biedl
+
+ -- Jochen Sprickerhof   Thu, 22 Jul 2021 20:51:01 +0200
+
 pppoeconf (1.21+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru pppoeconf-1.21+nmu1/pppoeconf pppoeconf-1.21+nmu2/pppoeconf
--- pppoeconf-1.21+nmu1/pppoeconf	2013-12-27 03:07:24.0 +0100
+++ pppoeconf-1.21+nmu2/pppoeconf	2021-07-22 20:49:37.0 +0200
@@ -190,7 +190,7 @@
 
 touch $TMP/pppoe.scan
 ip link set $iface up
-($DISCOVERY_PROGRAM $mmm -A -I $iface > $TMP/$iface.pppoe ; rm $TMP/pppoe.scan) &
+($DISCOVERY_PROGRAM $mmm -I $iface > $TMP/$iface.pppoe ; rm $TMP/pppoe.scan) &
 
 ( time=0 ; while test -f $TMP/pppoe.scan ; do time=`expr $time + 6`; echo $time; sleep 1; done ) | $DIALOG --title "$title" --gauge "$text $mmode" 10 60 0
 
diff -Nru pppoeconf-1.21+nmu1/pppoeconf.8.sgml pppoeconf-1.21+nmu2/pppoeconf.8.sgml
--- pppoeconf-1.21+nmu1/pppoeconf.8.sgml	2013-12-27 03:07:24.0 +0100
+++ pppoeconf-1.21+nmu2/pppoeconf.8.sgml	2021-07-22 20:50:22.0 +0200
@@ -70,12 +70,12 @@
 DESCRIPTION
 
 The  program is user-friendly dialog
- based setup tool for pppd (and pppoe
- if needed). It will look for existing ethernet cards and look for ADSL
+ based setup tool for pppd (and pppoe if
+ needed). It will look for existing ethernet cards and look for ADSL
  hardware connected to one of them. You can add an interface name
  iface to force  to use it. Then it will get
  some login info and do some minor modifications to make working
- settings. Note that you can use ESC key to exit program when you wan.
+ settings. Note that you can use ESC key to exit program when you want.
 
   
   


signature.asc
Description: PGP signature

Bug#990816: python3-nosehtmloutput: nosetests3 --with-html fails with RuntimeWarning

[Jochen Sprickerhof]

Control: tags -1 patch

Hi,

this was fixed upstream in:

https://opendev.org/openstack/nose-html-output/commit/71d12999b06908bbb019f69c89361bd44bec316c

Which is basically the only change in version 0.7. I would propose to 
upload that and ask for an unblock. @Thomas: can you take care or should 
I do a NMU?


Cheers Jochen

* Enrique  [2021-07-08 11:27]:

Package: python3-nosehtmloutput
Version: 0.0.5-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: cqu...@arcor.de

Dear Maintainer,

I have installed python3-nosehtmloutput package but it seems as if the plugin
has a problem and it is not possible to use the --with-html option of
nosetests3  that would activate the plugin:

$ nosetests3 --with-html
/usr/lib/python3/dist-packages/nose/plugins/manager.py:394: RuntimeWarning:
Unable to load plugin html-output = htmloutput.htmloutput:HtmlOutput: No module
named 'version'
 warn("Unable to load plugin %s: %s" % (ep, e),
Usage: nosetests3 [options]

nosetests3: error: no such option: --with-html

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

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

Versions of packages python3-nosehtmloutput depends on:
ii  python3   3.9.2-3
ii  python3-nose  1.3.7-7

python3-nosehtmloutput recommends no packages.

python3-nosehtmloutput suggests no packages.


signature.asc
Description: PGP signature

Bug#991432: unblock: freeradius/3.0.21+dfsg-2.1

[Jochen Sprickerhof]

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

Please unblock package freeradius

[ Reason ]
Misleading comment in systemd service file about how to get capabilities
for privileged ports: #985967.

[ Impact ]
Users could have a hard time how to use freeradius.

[ Tests ]
To test manually:
$ sudo apt install freeradius-dhcp
$ sed 's/port = 6700/port = 67/' /etc/freeradius/3.0/sites-available/dhcp > 
/etc/freeradius/3.0/sites-enabled/dhcp
$ systemctl restart freeradius

[ Risks ]
This only changes a commented line in a service file, I don't see a
risk.

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

[ Other info ]
Send upstream as
https://github.com/FreeRADIUS/freeradius-server/pull/4150

unblock freeradius/3.0.21+dfsg-2.1
diff -Nru freeradius-3.0.21+dfsg/debian/changelog 
freeradius-3.0.21+dfsg/debian/changelog
--- freeradius-3.0.21+dfsg/debian/changelog 2020-08-24 10:46:49.0 
+0200
+++ freeradius-3.0.21+dfsg/debian/changelog 2021-07-23 13:19:03.0 
+0200
@@ -1,3 +1,13 @@
+freeradius (3.0.21+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix capabilities in service file.
+As freeradius is not run as root we need to request extra capabilities
+wiht AmbientCapabilities instead of limiting the set with
+CapabilityBoundingSet. (Closes: #985967)
+
+ -- Jochen Sprickerhof   Fri, 23 Jul 2021 13:19:03 +0200
+
 freeradius (3.0.21+dfsg-2) unstable; urgency=medium
 
   * Cherry-Pick upstream fixes to build with Python3.8 (Closes: #966860)
diff -Nru freeradius-3.0.21+dfsg/debian/freeradius.service 
freeradius-3.0.21+dfsg/debian/freeradius.service
--- freeradius-3.0.21+dfsg/debian/freeradius.service2020-08-24 
10:46:49.0 +0200
+++ freeradius-3.0.21+dfsg/debian/freeradius.service2021-07-23 
13:13:11.0 +0200
@@ -41,7 +41,7 @@
 NoNewPrivileges=true
 
 # Allow binding to secure ports, broadcast addresses, and raw interfaces.
-#CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST 
CAP_NET_RAW CAP_SETUID CAP_SETGID CAP_CHOWN CAP_DAC_OVERRIDE
+#AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST 
CAP_NET_RAW CAP_SETUID CAP_SETGID CAP_CHOWN CAP_DAC_OVERRIDE
 
 # Private /tmp that isn't shared by other processes
 PrivateTmp=true

Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError

[Jochen Sprickerhof]

Hi Chris,

* Chris Lamb  [2021-07-25 10:01]:

I'd be happy to report this to Redis upstream, but I have no evidence
that this indicates an actual bug in Redis itself or any kind of "When
I see X we see Y but we should see Z". I lack knowledge about what
python-fakeredis is actually testing here (as well as how Hypothesis
works!) to determine which package is buggy. Could the fakeredis
maintainer chime in perhaps?


I had a look into this and extracted this minimal example:

$ sudo apt install redis-server python3-redis
$ python3 -c "import redis; \
  r = redis.StrictRedis('localhost', port=6379); \
  r.execute_command('set', b'\x00', b''); \
  r.execute_command('sinter', b'', b'\x00')"

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/redis/client.py", line 901, in 
execute_command
return self.parse_response(conn, command_name, **options)
  File "/usr/lib/python3/dist-packages/redis/client.py", line 915, in 
parse_response
response = connection.read_response()
  File "/usr/lib/python3/dist-packages/redis/connection.py", line 756, in 
read_response
raise response
redis.exceptions.ResponseError: WRONGTYPE Operation against a key holding the 
wrong kind of value

Same for:

r.execute_command('sinterstore', b'', b'', b'\x00')

Both work for redis-server 5:6.0.14-1 and break for 5:6.0.15-1.
As far as I read https://redis.io/topics/data-types-intro this should be 
allowed, but I don't really no Redis. Can you report this to upstream if 
you agree?


Hope this helps

Jochen


signature.asc
Description: PGP signature

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Jochen Sprickerhof]

* Alejandro Colomar (man-pages)  [2021-07-25 21:38]:

I think that would be to big of a patch.


Yes.  What is Fedora doing?  Do you know?


They provide a opencv.pc:

https://fedora.pkgs.org/rawhide/fedora-x86_64/opencv-devel-4.5.3-1.fc35.x86_64.rpm.html

The opencv4.pc is a symbolic link:

https://src.fedoraproject.org/rpms/opencv/blob/rawhide/f/opencv.spec#_350

Cheers Jochen


signature.asc
Description: PGP signature

Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError

[Jochen Sprickerhof]

* Chris Lamb  [2021-07-25 16:37]:

Chris Lamb wrote:


Sure thing -- I've forwarded this upstream here:

  https://github.com/redis/redis/issues/9273


Okay, so the latest reply there suggests that this is (now) the
expected and behaviour of Redis going forward.

I still don't quite grasp what it is that fakeredis is testing though,
so I can't state with any authority whether it definitely is fakeredis
that needs to be addressed, but reverting this behavioural change in
Redis does not seem the right way to go at all (!).


I have no idea about Redis/Fakeredis, adding Ondřej as he did all the 
uploads, lately.


What I got from looking at the code was that Hypothesis is a library to 
do extensive testing, so testing with 0 or empty strings sounds like a 
common way. I haven't looked how much work it would be to adopt 
Fakeredis to the new Redis behavior, but in case we want to only silence 
the tests for bullseye this would be a minimal change:


--- test/test_hypothesis.py.org 2021-07-26 07:54:36.151227815 +0200
+++ test/test_hypothesis.py 2021-07-26 07:54:38.599225613 +0200
@@ -257,8 +257,8 @@
 set_commands = (
 commands(st.just('sadd'), keys, st.lists(fields,))
 | commands(st.just('scard'), keys)
-| commands(st.sampled_from(['sdiff', 'sinter', 'sunion']), st.lists(keys))
-| commands(st.sampled_from(['sdiffstore', 'sinterstore', 'sunionstore']),
+| commands(st.sampled_from(['sdiff', 'sunion']), st.lists(keys))
+| commands(st.sampled_from(['sdiffstore', 'sunionstore']),
keys, st.lists(keys))
 | commands(st.just('sismember'), keys, fields)
 | commands(st.just('smembers'), keys)


Cheers Jochen


signature.asc
Description: PGP signature

Bug#991602: unblock: freeradius/3.0.21+dfsg-2.2

[Jochen Sprickerhof]

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

Please unblock package freeradius

[ Reason ]
freeradius-ldap fails to install if freeradius is stopped (#991561).

[ Impact ]
Upgrading with a stopped freeradius breaks.

[ Tests ]
None.

[ Risks ]
This only changes the postinst to ignore if the restart fails, I don't
see a risk.

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

[ Other info ]
This includes the changes already acked in #991432, they almost made
it to testing.. :)

unblock freeradius/3.0.21+dfsg-2.2
diff --git a/debian/changelog b/debian/changelog
index 53910a5..fed7e9f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+freeradius (3.0.21+dfsg-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't fail postinst if daemon is not running (Closes: #991561, #932113)
+
+ -- Jochen Sprickerhof   Wed, 28 Jul 2021 12:28:32 +0200
+
+freeradius (3.0.21+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix capabilities in service file.
+As freeradius is not run as root we need to request extra capabilities
+wiht AmbientCapabilities instead of limiting the set with
+CapabilityBoundingSet. (Closes: #985967)
+
+ -- Jochen Sprickerhof   Fri, 23 Jul 2021 13:19:03 +0200
+
 freeradius (3.0.21+dfsg-2) unstable; urgency=medium
 
   * Cherry-Pick upstream fixes to build with Python3.8 (Closes: #966860)
diff --git a/debian/freeradius-dhcp.postinst b/debian/freeradius-dhcp.postinst
index af32395..b8f2c7c 100644
--- a/debian/freeradius-dhcp.postinst
+++ b/debian/freeradius-dhcp.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 
 if [ -z "$2" ]; then
   for module in dhcp; do
diff --git a/debian/freeradius-iodbc.postinst b/debian/freeradius-iodbc.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-iodbc.postinst
+++ b/debian/freeradius-iodbc.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-krb5.postinst b/debian/freeradius-krb5.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-krb5.postinst
+++ b/debian/freeradius-krb5.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-ldap.postinst b/debian/freeradius-ldap.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-ldap.postinst
+++ b/debian/freeradius-ldap.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-memcached.postinst 
b/debian/freeradius-memcached.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-memcached.postinst
+++ b/debian/freeradius-memcached.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-mysql.postinst b/debian/freeradius-mysql.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-mysql.postinst
+++ b/debian/freeradius-mysql.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-postgresql.postinst 
b/debian/freeradius-postgresql.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-postgresql.postinst
+++ b/debian/freeradius-postgresql.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-python3.postinst 
b/debian/freeradius-python3.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-python3.postinst
+++ b/debian/freeradius-python3.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-redis.postinst b/debian/freeradius-redis.postinst
index eacd565..6a7608d 100644
--- a/debian/freeradius-redis.postinst
+++ b/debian/freeradius-redis.postinst
@@ -5,7 +5,7 @@ set -e
 
 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+invoke-rc.d freeradius force-reload || true
 ;;
 esac
 
diff --git a/debian/freeradius-rest.postinst b/debian/freeradius-rest.postinst
index eacd565..6a7608d 100644
--- a/debi

Bug#1001541: run-time shared lib not placed in package with proper name

[Jochen Sprickerhof]

Hi Tobias,

* Tobias Hansen  [2022-01-10 20:49]:

from debian/README.Debian:

"The libecl.so file is changing too quickly and
is integrated with the ecl binary to such extend
that, after consultation with upstream,  I will
not create a libecl package.

If ecl will reach a stable release (1.0 or so) and
some guarantees with respect to API stability
can be make I will reconsider this decision."

This is still true 13 years later. ecl is using its version (which is based on 
the year) as SONAME...

And sagemath is not unrelated software: maxima-sage and sagemath are the only 
packages in Debian with Depends: ecl. We are always making sure that 
maxima-sage and sagemath are rebuilt with every new ecl version, however 
sagemath 9.2 in Debian was already so broken that it didn't matter (look at the 
number of bugs fixed by sagemath 9.4-1).

Creating a library package for ecl would just mean that it would have to go 
through NEW for every new version with no real benefit.

Do you insist that I do that?



according to policy:

"The run-time shared library must be placed in a package whose name
changes whenever the SONAME of the shared library changes."

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html


This is a must according to our policy and not a question on what 
someone insist on. Note that the policy also advices for libraries that 
are fast moving, for example by using a static library. Though looking 
at the recent changelog I think it should be fine to go through new 
every other year, I usually find it quiet fast.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#977006: packages.debian.org: file list broken for some Sid packages

[Jochen Sprickerhof]

* Vipul Kumar  [2021-11-10 11:12]:
The "filelist" feature on packages.debian.org is still broken for some 
Sid's packages. Patch indeed worked for Bullseye and Bookworm (neither 
of which worked before), but somehow not for Sid. For example, https://packages.debian.org/bookworm/all/golang-github-oklog-ulid-dev/filelist 
is working, but https://packages.debian.org/sid/all/golang-github-oklog-ulid-dev/filelist 
is not.


This seems due to a division by zero in the script, I've opened a MR 
with a patch:


https://salsa.debian.org/webmaster-team/packages/-/merge_requests/24

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1007792: nmu: fdroidcl_0.5.0-3+b3

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: jspri...@debian.org

nmu fdroidcl_0.5.0-3+b3 . ANY . unstable . -m "rebuild with new golang version"

Bug#1007716: RFA: python-pluggy -- plugin and hook calling mechanisms for Python - 3.x

[Jochen Sprickerhof]

Package: wnpp
Severity: normal
X-Debbugs-Cc: jspri...@debian.org, debian-pyt...@lists.debian.org
Control: affects -1 src:python-pluggy

I request an adopter for the python-pluggy package.

The package description is:
 pluggy is the cristallized core of plugin management as used by some 150
 plugins for pytest.
 .
 This is the Python 3 library.

I've just pushed a new version but would prefer if someone closer to
pytest would maintain this.

Bug#1006838: RM: camitk [i386] -- RoQA; insighttoolkit5 is no longer build for i386

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: jspri...@debian.org

Bug#1006839: RM: gazebo [i386] -- RoQA; insighttoolkit5 is no longer build for i386

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: jspri...@debian.org

Bug#1006140: New version can't load old databases

[Jochen Sprickerhof]

Hi Markus,

now that Ubuntu Jammy is out of the way, I would like to plan for the 
future of h2. Sadly the upstream of jameica/hibiscus declined to upgrade 
it for now as it would involve multiple plugins and projects.


Currently we have these users of h2 in the repo:

$ apt rdepends libh2-java
libh2-java
Reverse Depends:
  Suggests: libh2-java-doc (same package)
  Depends: mediathekview (will move to SQLite)
  Depends: jameica

$ build-rdeps libh2-java
Reverse Build-depends in main:
--

commons-csv (only used in one unit test)
hibiscus (part of jameica)
jverein (part of jameica)
libhibernate3-java (only used in unit tests, I think)
mediathekview
undertow (seems to not use it and builds fine without)

So once mediathekview is updated the only relevant usage of h2 in Debian 
is jameica and plugins. Note that jameica does not use the console 
interface of h2 so it should not be affected by the security bugs.


I see two ways forward:

- Keep the current (old) version of h2 in Debian till jameica is 
  updated, given that jameica is the only user.


- Upload the old version of h2 as jameica-h2database and move the jar to 
  /usr/share/jameica. That would basically mark the package as jameica 
  only and would free up the h2database package to move to a newer 
  version.


What do you think?

Cheers Jochen


* Markus Koschany  [2022-02-19 23:39]:

Am Samstag, dem 19.02.2022 um 23:13 +0100 schrieb Jochen Sprickerhof:

* Markus Koschany  [2022-02-19 22:38]:
> Ok. Did you file an upstream bug report already?

I did not yet. Upstream bundles the old binary version so I don't think
I can convince them to do a quick migration.
But I will open a bug to get it fixed there.

> The old version of H2 is already present in Ubuntu or Debian stable. You
> could
> either ask users to execute all those commands manually (README.Debian,
> Debian.NEWS) or there could be some kind of pre/post hook script that does
> all
> that automatically.

Asking users to install packages from other releases does not sound
convincing. We can't use the pre/post maintainer scripts as the database
files could be stored anywhere on disk (default is in $HOME but could
even be on a thumb drive). So we can only hook into the jameica
executable. I don't think doing this before the Ubuntu jammy freeze is
feasible.


I believe there is a misunderstanding somewhere. We don't need to ask users to
install anything. They simply upgrade from an older version to a newer one.
There must be some sort of logic for the database storage. It is possible to
move a file to a different location but your program will always look in the
same place. If your database isn't there, then a good script would ask where it
is, you enter the new location and the program proceeds.


> For a quick solution you could upload 1.4.197 again based on the version in
> Bullseye

Thanks, I will do that, i.e. I will upload 2.1.210+really1.4.197-1 =
1.4.197-4+deb11u1 as proposed in my initial bug report.

> but this doesn't really solve the problem.

Can you explain what you mean here?



You only fix your single use case. You keep an unsupported and buggy version of
the H2 database in Debian and this is not how we usually solve problems in
Debian.



> As I said we don't need multiple H2 versions in Debian.

Can you give reasons why you think so? As I stated multiple times I
don't see a way not to have multiple versions available in one release
to support the migration.


You don't need multiple version of H2 in Bookworm. We ship 1.4.197 in Bullseye
and 2.x in Bookworm, that's it. When users upgrade from Bullseye to Bookworm,
they either have to perform some manual migration steps, or the package takes
care of them automatically. That's how it works for every package in Debian. We
also don't ship multiple Tomcat or Jetty, MariaDB or PostgreSQL versions in
stable releases because we support only one of them for their life cycle. This
is because of security and maintenance reasons, otherwise we would have
multiple versions of every piece of Java software in Debian and we could stop
using system libraries and instead bundle everything together in fat jars. At
one point you have to upgrade to a newer H2 database, that's a fact and it
should happen before we freeze for Bookworm.


> You should only do that if you are willing to
> support an officially unsupported piece of software for the next Debian 12
> LTS
> cycle until the year 2028. And that means taking care of all other libh2-
> java
> dependencies too, dealing with people who request an upgrade to 2.x because
> their use case depends on it, etc. And you and the rest of the users should
> be
> fine with the disabled H2 console and all the other bugs in that version.

That would be fine with me.


Ok, that's your choice but please add yourself to the list of Uploaders and
keep an eye on all H2 bug reports from now on because I won't. ;>







signature.asc
Description: PGP signature

Bug#1006140: New version can't load old databases

[Jochen Sprickerhof]

Package: libh2-java
Version: 2.1.210-1
Severity: important
X-Debbugs-Cc: jspri...@debian.org, Markus Koschany 
Control: -1 affects mediathekview jameica hibiscus

Hi,

the new version of libh2-java uses a new SQL syntax and file format and
is not able to read old data or work with the old syntax:

https://h2database.com/html/migration-to-v2.html

This renders all it's users, i.e. mediathekview and jameica/hibiscus,
unusable.

Given that there is no online conversion available, the H2MigrationTool
actually contains jars of the different version, I would propose to
upload the v2 version with a new source and binary package name and
upload the v1 version to unstable again with a +really version number:

2.1.210+really1.4.197-1

based on the git tag debian/1.4.197-4+deb11u1.

Given that this affects all linked programs and that v2 already
transitioned to testing as well as the next Ubuntu version (which will
stop importing from Debian soon) I would like to get this fixed fast.

I'm planning to upload the +really version tomorrow unless someone
disagrees.

Cheers Jochen

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

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

libh2-java depends on no packages.

libh2-java recommends no packages.

Versions of packages libh2-java suggests:
pn  libjts-java  
pn  liblucene8-java  
ii  libslf4j-java1.7.32-1

-- no debconf information

Bug#1006140: New version can't load old databases

[Jochen Sprickerhof]

Hi Markus,

thanks for your quick reply.

* Markus Koschany  [2022-02-19 21:01]:

That means only hibiscus/jameica require our attention. I would try to remove
the obsolete connection setting mentioned in #1005838.


Tried that already, did not solve the problem.


You could also try to
dump the SQL database with the current version in stable and then try to re-
import the SQL tables with H2 in unstable. That should actually work because
the SQL syntax will not have changed. (See also the Upgrading paragraph here
https://h2database.com/html/migration-to-v2.html)


That would be the plan, yes. But for that we would need to provide both 
versions to our users, thus I propose to upload the new version as a new 
source and binary package.


Also the SQL syntax did change.


I would advise against that plan because

a) jameica/hibiscus is the only affected package

b) the grave security issues would be present again #1003894.

I have fixed the most severe ones in stable releases by disabling the H2
console and JNDI lookups. There are probably more issues mentioned by upstream
here:

https://github.com/h2database/h2database/issues/3360#issuecomment-1018351050

However users would want an up-to-date version of H2 in the future. At some
point an upgrade is inevitable.

c) two source packages make only sense if we talk about an (important) library
that is incompatible and breaks many reverse-dependencies. H2 is a database and
affects only 2 packages.

d) versions 1.4.xxx are no longer supported. 1.4.197 is already four years old.
That makes security support or any support in general not feasible if we want
to release this version again for Bookworm.


I would contact jameica/hibiscus upstream and report this issue as a bug. A
database dump and re-import should be possible in any case and depending on a
supported version of H2 is surely desirable for all parties.


Can you explain how you want to implement this re-import feature then?

I would really appreciate a quick solution here so users of the next 
Ubuntu version would not be locked out of their homebanking system.


I'm happy to help with uploading new versions and NEW is rather empty 
currently so I don't see the point in not doing a proper transition 
here.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1005838: jameica: Unsupported connection setting "MVCC" [90113-210]

[Jochen Sprickerhof]

Control: reassign -1 libh2-java
Control: forcemerge 1006140 -1

Hi Thomas,

thanks for opening the bug and sorry for not answering earlier. I have 
uploaded a reverted version (2.1.210+really1.4.197-1) of the h2database 
to unstable as part of #1006140 so jameica should work again for you. It 
could be that you need to load a backup of the database, jameica should 
instruct you in that case.


I'm planing to implement a migration strategy before uploading the new 
h2 version again.


Cheers Jochen


* Thomas Renard  [2022-02-15 21:14]:

Package: jameica
Version: 2.10.1+dfsg-1
Severity: important

Dear Maintainer,

Jameica/Hibiscus starts up but has a break with error:

Unsupported connection setting "MVCC" [90113-210]

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

  * What led up to the situation?
  according to  https://github.com/h2database/h2database/issues/2198
  probably todays update of libh2-java to 2.1.210-1
  * What exactly did you do (or not do) that was effective (or
ineffective)?
* apt upgrade
* startup jameica from desktop
* log in to you hibiscus session
* jameica window opens
  * What was the outcome of this action?
  No hibiscus environment but the error message above
  * What outcome did you expect instead?
  Hibiscus starts up as normal.

*** End of the template - remove these template lines ***


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

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

Versions of packages jameica depends on:
ii  libactivation-java1.2.0-2
ii  libbcpkix-java1.68-5
ii  libbcprov-java1.68-5
ii  libcommons-cli-java   1.4-2
ii  libcommons-collections3-java  3.2.2-2
ii  libcommons-lang-java  2.6-9
ii  libcommons-logging-java   1.2-2
ii  libeclipse-core-commands-java 3.10.100+eclipse4.21-1
ii  libeclipse-core-runtime-java  3.20.100+eclipse4.19-1
ii  libeclipse-jface-databinding-java 1.13.0+eclipse4.21-1
ii  libeclipse-osgi-java  3.17.0+eclipse4.21-1
ii  libeclipse-ui-forms-java  3.11.200+eclipse4.21-1
ii  libequinox-common-java3.14.100+eclipse4.19-1
ii  libgeronimo-annotation-1.3-spec-java  1.3-1
ii  libh2-java2.1.210-1
ii  libicu4j-java 68.2-2
ii  libistack-commons-java3.0.6-5
ii  libjameica-datasource-java2.8.1+dfsg-4
ii  libjameica-util-java  2.8-3
ii  libjaxb-api-java  2.3.1-1
ii  libjaxb-java  2.3.0.1-10
ii  libmariadb-java   2.7.4-1
ii  libmckoisqldb-java1.0.6-4
ii  libnanoxml2-java  2.2.3.dfsg-9
ii  liboro-java   2.0.8a-14
ii  libpaperclips-java1.0.4-3
ii  libswt-cairo-gtk-4-jni4.20.0-2
ii  libswtcalendar-java   0.5-3
ii  libtxw2-java  2.3.0.1-10
ii  velocity  1.7-6

jameica recommends no packages.

jameica suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1008836: Broken with Python 3.10

[Jochen Sprickerhof]

Package: weechat-matrix
Version: 0.3.0-3
Severity: important
Tags: patch
X-Debbugs-Cc: jspri...@debian.org

Hi Kyle,

can you please add this patch so weechat-matrix works with Python 3.10:

https://github.com/poljar/weechat-matrix/commit/4e585d5f4628e6fbeba9ec4560b440d731e076f5

(I can do a NMU if you want)

Cheers 

Jochen

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.16.0-2-armmp (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages weechat-matrix depends on:
ii  python3-aiohttp   3.8.1-4
ii  python3-atomicwrites  1.4.0-2
ii  python3-future0.18.2-5
ii  python3-logbook   1.5.3-4+b2
ii  python3-magic 2:0.4.25-1
ii  python3-matrix-nio0.19.0-2
ii  python3-openssl   21.0.0-1
ii  python3-pygments  2.11.2+dfsg-2
ii  python3-requests  2.27.1+dfsg-1
ii  python3-webcolors 1.11.1-1

Versions of packages weechat-matrix recommends:
pn  weechat  

weechat-matrix suggests no packages.

-- no debconf information