Bug#1067293: singular: FTBFS: cfModGcd.cc:1809:37: error: cannot convert ‘fq_nmod_ctx_struct*’ to ‘const fq_nmod_mat_struct*’
Hello Lucas, thanks for the report. The issue appeared to be fixed in version 4.3.2-p16. I am on my way to bring this new version to experimental. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056186: texlive-binaries: zlib library mismatch
Hello Hilmar, thanks for your prompt reply. To clarify things, the message is not only irritating but also aborting: the package tex-common cannot currently configure. Best wishes, Jerome PS: I merged my report with the first report, and I redirected the first report to texlive-binaries. On 18/11/2023 15:28, Preuße, Hilmar wrote: On 18.11.2023 14:57, Jerome Benoit wrote: Hi, Hi, the issue appeared to me within a Sid schroot environment at postinstallation time of tex-common. I traced it back to texlive-binaries by looking the logfile at the fmutils stage. The issue seems to originate from the recent migration from zlib 1.2.13 to zlib 1.3. For short, the following command-line $ luatex -ini -jobname=luatex -progname=luatex luatex.ini gives PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) aborted Already reported, but on the wrong package. I'll try, whether a simple rebuild of the package solves the issue, but I'm afraid it won't. The message "zlib library version does not match - header: 1.2.13, library: 1.3" is irritating, but I know that behavior from other packages too (e.g. proftp). I understand this warning: "expect trouble ahead". Hilmar -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1056186: texlive-binaries: zlib library mismatch
Package: texlive-binaries Version: 2023.20230311.66589-7 Severity: grave Justification: renders package unusable X-Debbugs-Cc: calcu...@rezozer.net Hi, the issue appeared to me within a Sid schroot environment at postinstallation time of tex-common. I traced it back to texlive-binaries by looking the logfile at the fmutils stage. The issue seems to originate from the recent migration from zlib 1.2.13 to zlib 1.3. For short, the following command-line $ luatex -ini -jobname=luatex -progname=luatex luatex.ini gives PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) aborted Best wishes, Jerome -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-0.deb11.6-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages texlive-binaries depends on: ii libc6 2.37-12 ii libcairo2 1.18.0-1 ii libfontconfig1 2.14.2-6 ii libfreetype62.13.2+dfsg-1 ii libgcc-s1 13.2.0-6 ii libgraphite2-3 1.3.14-1 ii libharfbuzz0b 8.0.1-1 ii libicu7272.1-4 ii libkpathsea62023.20230311.66589-7 ii libmpfr64.2.1-1 ii libpaper1 1.1.29 ii libpixman-1-0 0.42.2-1 ii libpng16-16 1.6.40-2 ii libpotrace0 1.16-2 ii libptexenc1 2023.20230311.66589-7 ii libstdc++6 13.2.0-6 ii libsynctex2 2023.20230311.66589-7 ii libteckit0 2.5.11+ds1-1+b1 ii libtexlua53-5 2023.20230311.66589-7 ii libx11-62:1.8.7-1 ii libxaw7 2:1.0.14-1 ii libxi6 2:1.8-1+b1 ii libxmu6 2:1.1.3-3 ii libxpm4 1:3.5.17-1 ii libxt6 1:1.2.1-1.1 ii libzzip-0-130.13.72+dfsg.1-1.1 ii perl5.36.0-9 ii t1utils 1.41-4 ih tex-common 6.18 ii zlib1g 1:1.3.dfsg-2 Versions of packages texlive-binaries recommends: pn dvisvgm ii texlive-base 2023.20231007-1 Versions of packages texlive-binaries suggests: pn hintview pn texlive-binaries-sse2 Versions of packages tex-common depends on: ii ucf 3.0043+nmu1 Versions of packages tex-common suggests: ii debhelper 13.11.8 Versions of packages texlive-binaries is related to: ih tex-common6.18 ii texlive-base 2023.20231007-1 -- no debconf information
Bug#1054706: e-antic: FTBFS: ../../../libeantic/test/main.cpp:4:10: fatal error: catch2/catch.hpp: No such file or directory
Hello, as the migration to catch2 v3 appeared not simple, I finally used the catch2 material provided by the e-antic upstream team. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1054706: e-antic: FTBFS: ../../../libeantic/test/main.cpp:4:10: fatal error: catch2/catch.hpp: No such file or directory
Hi Lucas, thanks for your report. I can reproduce the issue on my box. The issue is due to the recent migration in Sid from catch2 v2 to catch2 v3. I am on my way to write a migration patch with respect to the document /usr/share/doc/catch2/docs/migrate-v2-to-v3.md.gz [ or https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md ] Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
Hell All, I have just made singular independent from brial. Otherwise it must be keep in mind that Sage is mostly umbrella software. That means that the dependency of brian on sage material is odd. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1034769: singular: build-dependencies unsatifiable on architectures where sagemath is unavailable.
Hello Again, I think that something is wrong with the package brial. Sage is an umbrella software which involves brial, so it makes no sense that brial depends on a sage package. This is my first remark. I will have a closer look on the dependency of singular on brial. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1034769: singular: build-dependencies unsatifiable on architectures where sagemath is unavailable.
Hi Peter, thanks for your report. I will have a look soon. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1020747: Fwd: Python 3.11 is now a supported release in unstable
Thanks for the reply. On 11/11/2022 13:49, stefa...@debian.org wrote: Hi Jerome (2022.11.11_12:23:42_+) Fixing the #1020747 may avoid FTBFS for some packages. I proposed a solution to fix it, however I cannot say if it optimal. That patch looks reasonable to me. I'd have done the [:3] inside the tuple(), but that's not exactly a problem. I will try to step forward by the end of the week-end if no one else do it before. Cheers, Jerome SR -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1020747: AM_PATH_PYTHON
control: reassign -1 autoconf-archive
control: tags -1 patch
I have just doublechecked: the bug does lie in autoconf-archive .
The faulty code was introduce in commit df89f6cdaade38f3c1c9987be0c5a57c96fc1730
https://github.com/autoconf-archive/autoconf-archive/commit/df89f6cdaade38f3c1c9987be0c5a57c96fc1730
The current code tuple(sys.version_info) gives the 5-tuple (3, 10, 7, 'final',
0) while
the former code sys.version.split()[0] would give the 3-tuple (3, 10, 7).
So, at first glance, the current code tuple(sys.version_info) should be
replaced by
tuple(sys.version_info)[:3].
A patch that applied to the current ax_python_devel serial 32 is attached.
Best wishes,
Jerome
On Fri, 30 Sep 2022 14:31:47 + Bastien =?ISO-8859-1?Q?Roucari=E8s?=
wrote:
control: reassign -1 automake
control: affects -1 autoconf-archive
Hi,
The macro AM_PATH_PYTHON dos not support 3 level python version...
The bug lie in automake not autoconf-archive
Could be workarround by a little sed script in order remove micro version on graph tool
side
Bastien
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
--- ax_python_devel.m4-s32.original 2022-10-01 17:42:46.0 +0200
+++ ax_python_devel.m4 2022-10-16 18:40:38.873380357 +0200
@@ -125,7 +125,7 @@
return tuple(map(int, s.strip().replace("rc", ".").split(".")))
def __init__(self):
import sys
-self.vpy = tuple(sys.version_info)
+self.vpy = tuple(sys.version_info)[[:3]]
def __eq__(self, s):
return self.vpy == self.vtup(s)
def __ne__(self, s):
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1020747: AM_PATH_PYTHON
Hello Bastien, thanks for your reply. On Fri, 30 Sep 2022 14:31:47 + Bastien =?ISO-8859-1?Q?Roucari=E8s?= wrote: control: reassign -1 automake control: affects -1 autoconf-archive Hi, The macro AM_PATH_PYTHON dos not support 3 level python version... The `configure.ac' of graph-tool passes a 2 level python version to AM_PATH_PYTHON. The bug lie in automake not autoconf-archive Could be workarround by a little sed script in order remove micro version on graph tool side Can you please more specific here ? Are you referred to the PYTHON_FULL_VERSION set up in `configure.ac' ? If so, it was working well before ax_python_devel serial 32 went. Second, I am not sure that removing micro version for devel stuff is a good idea. Best wishes, Jerome Bastien -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1020747: autoconf-archive: ax_python_devel serial 32 fails with current Sid python3
Package: autoconf-archive Version: 20220903-1 Severity: serious Tags: upstream Justification: causes FTBFS issues Dear Maintainer, it appears that ax_python_devel serial 32 provided by this package can cause FTBFS issues. I experienced it with the package grap-tool (#101). A closer look reveals that the ad hoc python module ax_python_devel_vpy.py fails with the current Sid Python. My understanding is that the tuple vpy contains an unexpected string. Unfortunately I am no familiar with Python to get further. Cheers, Jerome
Bug#1016296: flint: FTBFS: dh_auto_test: error: make -j8 check
ping -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1017727: autoconf-archive: ax_cc_maxopt.m4 change breaks code due to syntax error
Hello, the issue was fixed in the upstream version, serial 23 : https://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_cc_maxopt.m4 hth, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#994992: libpam-ssh: pam-ssh picks the from agent socket after login with ssh -A
Hello Stephan, thanks for your report. I guess that your issue is related to issue #995452 . I haved just merged them. Attached patch fixes the problem by omiting `session optional pam_ssh.so` from /etc/pam.d/sshd. Thanks for the patch. However note that it is not applicable because /etc/pam.d/sshd is actually distributed along the package `openssh-server` (you can check this wit apt-file(1)). For a working (but hopefully temporary) workaround you can have a look to the aforementionned bugreport. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#998413: gap-float: autopkgtest regression: object must be an MPFR, not a integer
Fixed in package version 1.0.2+ds-1. -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
Hello Michael, On Fri, 01 Oct 2021 14:37:44 +0200 Michael Schindler wrote: x On the client machine with libpam-ssh installed, however, this functionality is broken: Instead of forwarding the agent from the server, it sets the environment variables SSH_AUTH_PID and SSH_AUTH_SOCK then point to the freshly started ssh-agent on the client, which has no keys charged. Thus, the login to the next client fails. Basically you say that there a competition between sshd and libpam-ssh. And in fact that this competition is actually not well managed. Actually, I think that there is no policy at all for this situation. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
On Mon, 29 Nov 2021 11:19:36 +0100 Jerome BENOIT wrote: Thanks for sharing your file. I will have a closer look soon, Cheers, Jerome ping, cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
Thanks for sharing your file. I will have a closer look soon, Cheers, Jerome OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
On Sun, 3 Oct 2021 03:25:54 +0300 Matti Kurkela wrote: Dear Kurkela, thanks for your report. I apologies for my late reply. Actually I agree with your comments. My current set up on my main computer follows your comment below. So far I can remember, I have never revisited the pam-auth-update(8) configuration file of this package since I begun to maintain it. Meanwhile, note that I put some warning in the README.Debian file. Can you share your /etc/pam.d/login and /etc/pam.d/*dm files so that I can compare with my set up ? The workaround/fix for this would be to not let pam-auth-update add pam_ssh.so into common-auth and common-session, but add the necessary lines *selectively* only to services that handle local logins like /etc/pam.d/login and /etc/pam.d/*dm, but *not* to /etc/pam.d/sshd. That should allow libpam-ssh to start the agent on initial login, but leave the SSH sessions and their agent forwarding alone. If you need the "authentication by SSH key passphrase" functionality on SSH connections, you could add only the "auth optional pam_ssh.so try_first_pass" line to /etc/pam.d/sshd. (Note that this line should not be the first authentication module, to prevent an information leak, as described in the pam_ssh(8) man page.) Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
On Mon, 1 Nov 2021 20:49:58 +0100 Paul Gevers wrote: Hello Paul, Is this run on all cores? Our armhf worker has 160 cores, so you may be running into limits you didn't expect. The upstream maintainer would like to know the number of cpus from a Python shell. import multiprocessing as mp; print(mp.cpu_count()); Can you get this information ? In fact, I am curious to know it as well. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
On Mon, 1 Nov 2021 20:49:58 +0100 Paul Gevers wrote: Hello Paul, Is this run on all cores? Our armhf worker has 160 cores, so you may be running into limits you didn't expect. I can reproduce the issue on my amd64 box by substituting mp.cpu_count() by 160 in the called function. We are progressing. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
On Mon, 1 Nov 2021 20:49:58 +0100 Paul Gevers wrote: Hello Paul, Is this run on all cores? Our armhf worker has 160 cores, so you may be running into limits you didn't expect. This would be a surprising bug, indeed. I will have a closer look. But I think I have ultimately to contact the upstream author. Otherwise, is there a way to limit the number of cores to use through an environment variable (or something along this way) ? Cheers, Jerom -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
I am working on it. OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: closed by Debian FTP Masters (reply to Jerome Benoit ) (Bug#995021: fixed in osmnx 1.1.1+ds-3)
Hello, a closer look on the log files shows that actually the failed test (elevation) download a corrupted data file on the armhf CI box by comparison against the size of the same data file downloaded on the other CI boxes. It sound pretty much as a subtle bug form some of the dependencies. Jerome OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: closed by Debian FTP Masters (reply to Jerome Benoit ) (Bug#995021: fixed in osmnx 1.1.1+ds-3)
Hi, it appears that I cannot reproduce the issue on the armhf porterbox amdahl.debian.org . Cheers Jerome OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: Restriction not respected
Hello Paul, it seems that the Restriction needs-internet is not respected. Cheers, Jerome -- Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net https://www.rezozer.net/ OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
Hello Paul, thanks for pointing out the issue.
I will try to have a look this week-end.
Cheers,
Jerome
On 24/09/2021 22:23, Paul Gevers wrote:
Source: osmnx
Version: 1.1.1+ds-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of osmnx the autopkgtest of osmnx fails in testing
on armhf when that autopkgtest is run with the binary packages of osmnx
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
osmnx from testing1.1.1+ds-2
all others from testingfrom testing
I copied some of the output at the bottom of this report. On top of the
failure, you test seems to be sending requests to the internet, please
use the needs-internet restriction [0] to mark is as such.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0]
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
[1] https://qa.debian.org/excuses.php?package=osmnx
https://ci.debian.net/data/autopkgtest/testing/armhf/o/osmnx/15474259/log.gz
=== FAILURES
===
test_elevation
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/lib/python3.9/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "/usr/lib/python3.9/multiprocessing/pool.py", line 51, in starmapstar
return list(itertools.starmap(args[0], args[1]))
File
"/tmp/autopkgtest-lxc.2hzrzn35/downtmp/build.elV/src/osmnx/elevation.py", line
49, in _query_raster
return zip(nodes.index, values)
TypeError: iteration over a 0-d array
"""
The above exception was the direct cause of the following exception:
def test_elevation():
G = ox.graph_from_address(address=address, dist=500,
dist_type="bbox", network_type="bike")
rasters = list(Path("tests/input_data").glob("elevation*.tif"))
# add node elevations from a single raster file (some nodes will
be null)
G = ox.elevation.add_node_elevations_raster(G, rasters[0], cpus=1)
# add node elevations from multiple raster files
G = ox.elevation.add_node_elevations_raster(G, rasters)
/usr/share/doc/python-osmnx-doc/examples/tests/test_osmnx.py:201:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
osmnx/elevation.py:98: in add_node_elevations_raster
results = sma.get()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = , timeout = None
def get(self, timeout=None):
self.wait(timeout)
if not self.ready():
raise TimeoutError
if self._success:
return self._value
else:
raise self._value
E TypeError: iteration over a 0-d array
/usr/lib/python3.9/multiprocessing/pool.py:771: TypeError
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
OpenPGP_signature
Description: OpenPGP digital signature
Bug#993269: RFS: e-antic 0.1.8+ds-2
Hello, thanks for the update. I will apply the patch by tomorrow. Cheers, Jerome On 22/09/2021 12:46, Torrance, Douglas wrote: Control: tags -1 pending e-antic and its reverse dependencies (macaulay2, normaliz, polymake, pynac, and singular) are currently scheduled for autoremoval on 2021-10-12 due to RC bug #993269. Peter Green tracked down a fix and submitted a patch, which I've pushed to Salsa, along with a couple other minor things. Would anyone be able to review/sponsor, or alternatively, grant me DM upload permissions for e-antic? https://salsa.debian.org/science-team/e-antic Thanks! Doug -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#991025: merkaartor build depends on both libqt5webkit5-dev and qtwebengine5-dev but uses neither
Hello Bas, thanks for letting me know that version 0.19 is now out. I will package it by the week-end. Best wishes, Jerome On 27/08/2021 17:34, Sebastiaan Couwenberg wrote: Jérôme, Are you going to fix this issue and the related issue about not migrating to testing (#993126), e.g. while packaging the 0.19.0 release? If not, merkaartor will be removed from Debian again. Kind Regards, Bas -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Dennis, thanks for your reply. I was rather wondering if setting Rules-Requires-Root to yes in d/rules will ask to bbuild to act as "needs-root" for autopkgtest. Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear all, > The autopkgtest probably will have to specify "needs-root" to set > unprivileged_userns_clone=1 (unless the VM image already has that set > up), but the test suite itself needn't run as root.w Will set Rules-Requires-Root to yes in d/rules solve the issue ? Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Paul Gevers, please consider to tag #982719 as bullseye-ignore given that the issue is not a package issue but it seems rather related to an chroot issue. Best regards, Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Dennis, thanks for your message. I think that the issue is actally not a firehol issue. But I cannot figure out to where the issue can be redirected. For now, I am reluctant to neutralize the tests. @Lucas: do you have any hint ? Thanks, Jeromr -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Hi Dennis, thanks for confirming. May I simply neutralize the involved test temporarily ? Cheers, Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Lucas, thanks for your report. I can not reproduce the issue on a Sid schroot a the time of writing. Please, can you confirm the issue on your side ? Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#970497: igraph: FTBFS on mips64el
On Thu, 28 Jan 2021 07:33:56 +0100 Jerome BENOIT wrote: > Hello, > > I am currently isolating the faulty code on the porter Eller. > > The issue seems to appear after the call to arpack functions, > so it does not look as an arparck issue. Finally I isolated the place where the issue emerge. It is indeed an arpack issue. In src/arpack.c in function igraph_arpack_rssolve the dsaupd_ loop works fine in the sense that the loop keeps giving the same output when the random seed is fixed. The issue emerges at the postamble of the loop, dseupd_ gives random output in the same conditions. I am on my way to write a small piece of arpack code to confirm this. If confirmed, I will submit the bug to the arpack debian maintainer. Best wishes, Jerome > > Best wishes, > Jerome > > -- > Jerome BENOIT | calculus+at-rezozer^dot*net > https://qa.debian.org/developer.php?login=calcu...@rezozer.net > AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B > > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#970497: igraph: FTBFS on mips64el
Hello, I am currently isolating the faulty code on the porter Eller. The issue seems to appear after the call to arpack functions, so it does not look as an arparck issue. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#974104: merkaartor FTBFS: error: field ‘thePath’ has incomplete type ‘QPainterPath’
On Tue, 10 Nov 2020 06:10:41 +0100 Sebastiaan Couwenberg wrote: > This is likely caused by the recent update to Qt 5.15.1, and seems to be > fixed upstream: > > > https://github.com/openstreetmap/merkaartor/commit/e72553a7ea2c7ba0634cc3afcd27a9f7cfef089c > > Jerome, will you take care of this? I will soon. Best, Jerome > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#957464: libpam-ssh: ftbfs with GCC-10
Thanks for the report. I am working on it soon. Best, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#957186: evolver: ftbfs with GCC-10
Thanks for the report. I am working on it soon. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#963338: sagemath: FTBFS: RuntimeError: Aborted
Thanks for the report. Meanwhile the Sagemath Debian team take a summer break. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#963290: e-antic: FTBFS: error: #error FLINT 2.5.2 or 2.5.3 required
Hello Lucas, thanks for the report. I am working on it. Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#960143: sagetex: FTBFS in unstable
Hello, I have just pushed a fix at Salsa. Please can someone make a team upload as my Debian key is expired (I did not send keyring.debian.org in due time, my mistake). Thanks in adavance, Jerome On 11/05/2020 10:30, Hilmar Preuße wrote: > Am 11.05.2020 um 00:21 teilte Hilmar Preuße mit: > > Hi, > >> - tkz-berge.sty does not exist in Debian any more. >> > Simply replacing tkz-berge.sty by tkz-base.sty does not solve the issue. > Leaving out debianization-examples.patch at least solves the issue. > >> - you need to declare a BD on sagetex itself, else the sagetex.sty >> is not available. >> > This is of course non-sense: the sagetex.sty is created during package > build. > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello Again, I am on my way to push a fix at Salsa. Jerome On 11/05/2020 10:30, Hilmar Preuße wrote: > Am 11.05.2020 um 00:21 teilte Hilmar Preuße mit: > > Hi, > >> - tkz-berge.sty does not exist in Debian any more. >> > Simply replacing tkz-berge.sty by tkz-base.sty does not solve the issue. > Leaving out debianization-examples.patch at least solves the issue. > >> - you need to declare a BD on sagetex itself, else the sagetex.sty >> is not available. >> > This is of course non-sense: the sagetex.sty is created during package > build. > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello, On 11/05/2020 10:30, Hilmar Preuße wrote: > Am 11.05.2020 um 00:21 teilte Hilmar Preuße mit: > > Hi, > >> - tkz-berge.sty does not exist in Debian any more. We can read at https://ctan.org/pkg/tkz-berge?lang=en This package has been taken temporarily out of circulation to give the author time to investigate some problems. So let do the same with this patch. Cheers, Jerome >> > Simply replacing tkz-berge.sty by tkz-base.sty does not solve the issue. > Leaving out debianization-examples.patch at least solves the issue. > >> - you need to declare a BD on sagetex itself, else the sagetex.sty >> is not available. >> > This is of course non-sense: the sagetex.sty is created during package > build. > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello Hilmar, On 10/05/2020 14:06, Hilmar Preuße wrote: > Am 10.05.2020 um 08:46 teilte Jerome BENOIT mit: > > Hi Jerome, > >> Hello Graham, thanks for the report. >> It sounds a Depends issue. >> > I guess some style files moved to another Debian package and hence they > are missing now. I guess something like that. Do you need help by fixing the issue? Thanks, I will fix it as soon as my renewed key reach Debian. Thanks, Jerome > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello Graham, thanks for the report. It sounds a Depends issue. I will fix it as soon as my extended key reaches the Debian keyring. Best, Jerome On 10/05/2020 01:01, Graham Inggs wrote: > Source: sagetex > Version: 3.4+ds-1 > Severity: serious > Tags: ftbfs > > Hi Maintainer > > Sagetex currently FTBFS in unstable [1]. > I've copied what I hope is the relevant part of the log below. > > Regards > Graham > > > [1] > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagetex.html > > > kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 > tcrm1000 > mkdir: cannot create directory '././nonexistent': Permission denied > mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; > nonstopmode; input tcrm1000 > This is METAFONT, Version 2.7182818 (TeX Live 2020/Debian) (preloaded base=mf) > > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/tcrm1000.mf > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/exbase.mf) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/tcrm.mf > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txsymb.mf > Ok (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/exaccess.mf > Ok) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txpseudo.mf > Ok) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txaccent.mf > Ok [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [27] [29]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txgen.mf > Ok [100] [109] [98] [99] [108]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txsymbol.mf > Ok [13] [18] [21] [22] [23] [24] [25] [26] [28] [31] [32] [36] [39] [44] > [45] [46] [42] [47] [60] [61] [62] [77] [79] [87] [110] [91] [93] [94] [95] > [96] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] > [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] > [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] > [162] [163] [164] [165] [166] [167] [168] [169] [171] [172] [173] [174] > [175] [177] [176] [180] [181] [182] [183] [184] [187] [191] [214] [246]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txromod.mf > Ok [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txrsuper.mf > Ok [185] [178] [179] [170] [186]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txrfract.mf > Ok [188] [189] [190]) ) ) ) > (some charht values had to be adjusted by as much as 0.06943pt) > Font metrics written on tcrm1000.tfm. > Output written on tcrm1000.600gf (128 characters, 23548 bytes). > Transcript written on tcrm1000.log. > mktexpk: /tmp/texfonts/pk/ljfour/jknappen/ec/tcrm1000.600pk: > successfully generated. > make[2]: Leaving directory '/build/1st/sagetex-3.4+ds' > /usr/bin/make example.pdf TEXOPTS="-interaction batchmode" > TEXINPUTS=".:_build/DEBIAN/usr/share/texmf/tex/latex/sagetex:_build/:" > PYTHONPATH=_build/DEBIAN/usr/lib/python3.8/dist-packages > VPATH=_build/DEBIAN/usr/share/texmf/tex/latex/sagetex:_build/DEBIAN/usr/lib/python3.8/dist-packages > DOT_SAGE=/build/1st/sagetex-3.4+ds/_test/DOT_SAGE > MPLCONFIGDIR=/build/1st/sagetex-3.4+ds/_test/MPLCONFIGDIR > MAXIMA_USERDIR=/build/1st/sagetex-3.4+ds/_test/MAXIMA_USERDIR > make[2]: Entering directory '/build/1st/sagetex-3.4+ds' > pdflatex -interaction batchmode example.tex > This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) > (preloaded format=pdflatex) > restricted \write18 enabled. > entering extended mode > make[2]: *** [Makefile:21: example.pdf] Error 1 > make[2]: Leaving directory '/build/1st/sagetex-3.4+ds' > make[1]: *** [debian/rules:59: override_dh_auto_test] Error 2 > make[1]: Leaving directory '/build/1st/sagetex-3.4+ds' > make: *** [debian/rules:28: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#958495: gap-io: please update for new GAP ABI
Dear Bill, thanks for your message.
I understand that GAP comes now with an official ABI.
Currently the package gap-io depends for building on gap and gap-dev,
while the package itseld depends only on gap.
You asked to make it depends on gap-kernel-7.
My understanding is that gap-kernel-7 is not a package.
I could build the package gap-io on a sane Sid environment (schroot)
without modification. But, the resulting gap-io package still depends
only depends on gap.
Do you mean that I must add by hand libgap7 to the list of dependencies
(as ${shlibs:Depends} does not add it) ?
Best,
Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
signature.asc
Description: OpenPGP digital signature
Bug#951236: osmnx fails the remote autopkg test (access blocked)
Dear Matthias, thanks for your report. I have just send an email to the Nominatim system administrator to see what we can do. Best, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#947720: sollya ftbfs with libfplll6
Dear Paul, thanks for your report. I can reproduce the issue on my box. I am working on it. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#941463: 3dldf: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended
Hello, On 01/10/2019 14:41, Norbert Preining wrote: > On Tue, 01 Oct 2019, Hilmar Preuße wrote: >> Fixed on salsa, tag pending. We could do an upload, but it will FTBFS >> anywayI guess. > > Completely FTBFS :-( > > parser.y++ does not exist > touch parser.y++ > bison -y --debug -d -o parser.cxx parser.y++ > parser.y++:147.1-8: warning: POSIX Yacc does not support %defines [-Wyacc] > 147 | %defines > | ^~~~ > parser.y++:152.1-12: warning: POSIX Yacc does not support %pure-parser > [-Wyacc] > 152 | %pure-parser > | ^~~~ > parser.y++:152.1-12: warning: deprecated directive, use '%define api.pure' > [-Wdeprecated] > 152 | %pure-parser > | ^~~~ > parser.y++:156.1-8: warning: POSIX Yacc does not support %verbose [-Wyacc] > 156 | %verbose > | ^~~~ > parser.y++: warning: 731 shift/reduce conflicts [-Wconflicts-sr] > parser.y++: warning: 1 reduce/reduce conflict [-Wconflicts-rr] > parser.y++: warning: fix-its can be applied. Rerun with option '--update'. > [-Wother] > ./check_scan_parse_output.sh parser.cxx parser.c++ > parser.c++ does not exist > ./check_scan_parse_output.sh parser.hxx parser.h++ > parser.h++ does not exist > touch parser.h++ > g++ -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/build/3dldf-2.0.3+dfsg=. -fstack-protector-strong > -Wformat -Werror=format-security -std=gnu++98 -c -o main.o main.c++ > main.web:109:10: fatal error: loader.h++: No such file or directory > 109 | #include "loader.h++" > | ^~~~ > compilation terminated. > > > That needs serious work. I am not sure Jerome is willing to put that > into it. > > I am more and more tempted to request removal of this package. Me too. It seems no more maintained upstream while C++ is constantly evolving. Best, Jerome > > Best > > Norbert > > -- > PREINING Norbert http://www.preining.info > Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#940274: python3-sagetex: update fails due to file conflicts (missing replace)
Hello Nordert, thanks for the report. I will fix it next week-end. Cheers, Jerome. -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#934089: closed by Jerome BENOIT (reply to calcu...@rezozer.net) (firehol fails to use iptables-restore)
Dear Jean Louis, On 16/08/2019 13:02, Jean Louis wrote: > Dear Jerome, > > Are you using firehol? Yes. On all my boxes. > > So just upgrade and watch if it is going to upgrade. I encountered no issue at upgrade time. > > If that is hard for you, you can install Debian VPS with previous > version, install firehol, and upgrade from inside, it costs maybe 0.00 > cent for 1 hour VPS. > > That is exactly where I am using firehol since years. > > The problem lays probable in the switch related to iptables in Debian > 10. This was supposed to be fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926784 > > I have switched to ufw, because firehol is not usable. > > So who shall do the above process to make it usable? > > If I should do it, you let me know, and I will give you whole record > of it. Please. Thanks, Jerome > > * Jerome BENOIT [2019-08-16 09:02]: >> >> >> On 16/08/2019 10:24, Jean Louis wrote: >>> I do not understand your reasoning. >> >> At the very upgrade stage, in general, some transitions do not go smoothly. >> >> On my side, everything was fine. I cannot reproduce the issue. >>> >>> Package is unusable on Buster 10.0 >>> >>> Of course it is upgrade issue, as from upgrade from previous Debian >>> to 10.0 it does not work. >>> >>> So if you close the bug for that reason, you leave that open, there is >>> no improvement for users. >> >> >> >>> >>> I had to remove firewall, which I used for years due to this. >> >> firewall or firehol ? >> >> What the following command >> >> /usr/sbin/firehol nofast try >> >> gives on your side ? >> >> Have you tried to re-start FireHOL instead ? >> >> Jerome >> >>> >>> Jean >>> >>> * Debian Bug Tracking System [2019-08-16 06:45]: >>>> This is an automatic notification regarding your Bug report >>>> which was filed against the firehol package: >>>> >>>> #934089: firehol fails to use iptables-restore >>>> >>>> It has been closed by Jerome BENOIT (reply to >>>> calcu...@rezozer.net). >>>> >>>> Their explanation is attached below along with your original report. >>>> If this explanation is unsatisfactory and you have not received a >>>> better one in a separate message then please contact Jerome BENOIT >>>> (reply to calcu...@rezozer.net) by >>>> replying to this email. >>>> >>>> >>>> -- >>>> 934089: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934089 >>>> Debian Bug Tracking System >>>> Contact ow...@bugs.debian.org with problems >>> >>>> Date: Fri, 16 Aug 2019 08:26:22 +0400 >>>> From: Jerome BENOIT >>>> To: 934089-cl...@bugs.debian.org >>>> Subject: firehol fails to use iptables-restore >>>> Organization: ReZoZeR >>>> >>>> Dear All, >>>> >>>> I am closing because I guess it is simply a upgrade issue. >>>> >>>> Jerome >> >> -- >> Jerome BENOIT | calculus+at-rezozer^dot*net >> https://qa.debian.org/developer.php?login=calcu...@rezozer.net >> AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B >> > > > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#934089: closed by Jerome BENOIT (reply to calcu...@rezozer.net) (firehol fails to use iptables-restore)
On 16/08/2019 10:24, Jean Louis wrote: > I do not understand your reasoning. At the very upgrade stage, in general, some transitions do not go smoothly. On my side, everything was fine. I cannot reproduce the issue. > > Package is unusable on Buster 10.0 > > Of course it is "upgrade" issue, as from upgrade from previous Debian > to 10.0 it does not work. > > So if you close the bug for that reason, you leave that open, there is > no improvement for users. > > I had to remove firewall, which I used for years due to this. firewall or firehol ? What the following command /usr/sbin/firehol nofast try gives on your side ? Have you tried to re-start FireHOL instead ? Jerome > > Jean > > * Debian Bug Tracking System [2019-08-16 06:45]: >> This is an automatic notification regarding your Bug report >> which was filed against the firehol package: >> >> #934089: firehol fails to use iptables-restore >> >> It has been closed by Jerome BENOIT (reply to >> calcu...@rezozer.net). >> >> Their explanation is attached below along with your original report. >> If this explanation is unsatisfactory and you have not received a >> better one in a separate message then please contact Jerome BENOIT >> (reply to calcu...@rezozer.net) by >> replying to this email. >> >> >> -- >> 934089: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934089 >> Debian Bug Tracking System >> Contact ow...@bugs.debian.org with problems > >> Date: Fri, 16 Aug 2019 08:26:22 +0400 >> From: Jerome BENOIT >> To: 934089-cl...@bugs.debian.org >> Subject: firehol fails to use iptables-restore >> Organization: ReZoZeR >> >> Dear All, >> >> I am closing because I guess it is simply a upgrade issue. >> >> Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#934089: firehol fails to use iptables-restore
Dear Jean Louis, thanks for your report. Have you tried, as suggested in the FireHOL message, /usr/sbin/firehol nofast try Please let me know the output of this action, if possible. Thanks in advance, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#932356: autotest fail with gap 4.10.2
Hello Bill, On 18/07/2019 14:54, Bill Allombert wrote: > Source: gap-guava > Version: 3.14+ds-1 > Severity: serious > > Dear Debian Science Maintainers, > > gap-guava 3.14+ds-1 is failing the autotest with gap 4.10.2. > Please rebuild the package for the new GAP version. I will have a look this week end. Jerome > > Cheers, > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#929788: e-antic: test suite fails on 32 bit architectures
Package: e-antic Version: 0.1.2+ds-2 Severity: serious Tags: upstream Justification: fails to build from source FTBFS on 32 bit architectures. Jerome -- System Information: Debian Release: Stretch* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#924832: bliss: FTBFS: make[3]: *** [Makefile:6: refman.pdf] Error 1
Hello Lucas, I have tried to reproduce the issue on a clean buster chroot environment: the package builds without trouble. Can you please confirm that the issue is fixed on your side ? Thanks, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#921779: doxygen: FTBFS (LaTeX error)
Dear All, I think there is a major issue with doxygen: #921802 , #921776, #921789, and certainly other seem affected by a recent bug that affect doxygen. For #921776, I cannot compose the PDF in a Sid environment, but I can compose it on my Stretch box. Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#918913: nbconvert 5.4 breaks nbsphinx: fix upstream
Hello, please can you apply the patch that fixes the issue [1,2] ? [1] https://github.com/spatialaudio/nbsphinx/issues/202 [2] https://github.com/jupyter/nbconvert/pull/924 Thanks, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#910856: sollya: test fails on most architectures
Thanks Adrian ! -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#918079: pandas: FTBFS: B-D on python-nbsphinx which is no longer installable nor built any more
Hello, On 07/01/2019 00:24, Paul Gevers wrote: > On Thu, 3 Jan 2019 02:39:12 + (UTC) Thorsten Glaser > wrote: >> See #917418 for “python-nbsphinx (0.4.1+ds-1) is not installable”. >> >> src:nbsphinx (0.4.1+ds-3) now only builds the py3k package. >> >> python-nbsphinx (= 0.3.5+ds-1) is installable and usable, but no >> longer in Debian, so please move to python3-nbsphinx instead. > > Please don't forget to update your autopkgtest as well. It is currently > blocking multiple migrations due to this as your test depends on > pyton-nbsphinx as well. > > Paul I am considering to provide Python 2 support for nbsphinx again for Buster. I am sorry for my mistake. Please give some time. Jerome > > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#918342: sagetex FTBFS: RuntimeError: MAXIMA_USERDIR and MPLCONFIGDIR must be set within nonexistent HOME environment
On 05/01/2019 17:30, Jerome BENOIT wrote: > Hello, > > it appears that both MAXIMA_USERDIR and MPLCONFIGDIR do not take into account > the environment variable DOT_SAGE . What I meant here is that sagemath should set MAXIMA_USERDIR (maxima-sage(1)) and MPLCONFIGDIR wrt DOT_SAGE. > > For now, MAXIMA_USERDIR and MPLCONFIGDIR are set at building time (for > testing purposes). > Note MAXIMA_USERDIR that must be set with an absolute path, while > MPLCONFIGDIR and DOT_SAGE accept path relative > to the working directory. > > Cheers, > Jerome > Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#918342: sagetex FTBFS: RuntimeError: MAXIMA_USERDIR and MPLCONFIGDIR must be set within nonexistent HOME environment
Hello, it appears that both MAXIMA_USERDIR and MPLCONFIGDIR do not take into account the environment variable DOT_SAGE . For now, MAXIMA_USERDIR and MPLCONFIGDIR are set at building time (for testing purposes). Note MAXIMA_USERDIR that must be set with an absolute path, while MPLCONFIGDIR and DOT_SAGE accept path relative to the working directory. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#918342: sagetex FTBFS: RuntimeError: ECL says: Could not create directory "/sbuild-nonexistent"
Hello All,
On 05/01/2019 15:13, Adrian Bunk wrote:
> Source: sagetex
> Version: 3.0+ds-7
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=sagetex=all=3.0%2Bds-7=1546636202=0
>
> ...
> This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian)
> (preloaded format=latex)
> restricted \write18 enabled.
> entering extended mode
> sage sagetex.sagetex.sage
> Traceback (most recent call last):
> File "sagetex.sagetex.sage.py", line 53, in
> """, globals(), locals(), False)
> File
> "/<>/sagetex-3.0+ds/_build/DEBIAN/usr/lib/python2.7/dist-packages/sagetex.py",
> line 202, in commandline
> result = eval(preparse(splitup[i][2]), globals, locals)
> File "", line 1, in
> File "sage/symbolic/expression.pyx", line 11568, in
> sage.symbolic.expression.Expression.solve
> (build/cythonized/sage/symbolic/expression.cpp:64298)
> return solve(self, x, multiplicities=multiplicities,
> File "/usr/lib/python2.7/dist-packages/sage/symbolic/relation.py", line
> 1045, in solve
> return _solve_expression(f, x, explicit_solutions, multiplicities,
> to_poly_solve, solution_dict, algorithm, domain)
> File "/usr/lib/python2.7/dist-packages/sage/symbolic/relation.py", line
> 1283, in _solve_expression
> m = ex._maxima_()
> File "sage/symbolic/expression.pyx", line 817, in
> sage.symbolic.expression.Expression._maxima_
> (build/cythonized/sage/symbolic/expression.cpp:8074)
> return super(Expression, self)._interface_(maxima)
> File "sage/structure/sage_object.pyx", line 734, in
> sage.structure.sage_object.SageObject._interface_
> (build/cythonized/sage/structure/sage_object.c:5637)
> nm = I.name()
> File "sage/misc/lazy_import.pyx", line 322, in
> sage.misc.lazy_import.LazyImport.__getattr__
> (build/cythonized/sage/misc/lazy_import.c:3610)
> return getattr(self.get_object(), attr)
> File "sage/misc/lazy_import.pyx", line 189, in
> sage.misc.lazy_import.LazyImport.get_object
> (build/cythonized/sage/misc/lazy_import.c:2271)
> return self._get_object()
> File "sage/misc/lazy_import.pyx", line 221, in
> sage.misc.lazy_import.LazyImport._get_object
> (build/cythonized/sage/misc/lazy_import.c:2536)
> self._object = getattr(__import__(self._module, {}, {}, [self._name]),
> self._name)
> File "/usr/lib/python2.7/dist-packages/sage/interfaces/maxima_lib.py", line
> 113, in
> ecl_eval("(set-pathnames)")
> File "sage/libs/ecl.pyx", line 1326, in sage.libs.ecl.ecl_eval
> (build/cythonized/sage/libs/ecl.c:11017)
> cpdef EclObject ecl_eval(str s):
> File "sage/libs/ecl.pyx", line 1341, in sage.libs.ecl.ecl_eval
> (build/cythonized/sage/libs/ecl.c:10956)
> o=ecl_safe_eval(o)
> File "sage/libs/ecl.pyx", line 350, in sage.libs.ecl.ecl_safe_eval
> (build/cythonized/sage/libs/ecl.c:5928)
> raise RuntimeError("ECL says: {}".format(
> RuntimeError: ECL says: Could not create directory "/sbuild-nonexistent"
> C library error: "Permission denied"
> Processing Sage code for sagetex.tex...
> Inline formula 0 (line 236)
> Initializing plots directory
> Plot 0 (line 261)
> Inline formula 1 (line 518)
> Inline formula 2 (line 747)
> Sage example 3 (line 797)
> Inline formula 3 (line 797)
> Sage commandline 0 (line 845)
> Sage commandline 1 (line 864)
>
> Error in Sage code on line 867 of sagetex.tex! Traceback follows.
>
> Running Sage on sagetex.sage failed! Fix sagetex.tex and try again.
> make[2]: *** [Makefile:14: sagetex.pdf] Error 1
>
>
> See also
> https://www.debian.org/doc/debian-policy/ch-opersys.html#non-existent-home-directories
I suspect that matplotlib does not take into account DOT_SAGE .
Tobias, can you confirm ?
>
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
signature.asc
Description: OpenPGP digital signature
Bug#896289: python-sagetex: sagetex fails to import
Dear Helmut, thanks for the report. At last I have some time before me to have a look. Can you send a simple script that reproduce the issue ? Thanks in advance, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#859054: libpam-ssh: Please migrate to openssl1.1 in buster
Thanks for the remainder, I will have a look this week-end, Jerome On 19/12/2018 05:32, John Stamp wrote: > On 05/22/18 08:52 PM, Jerome BENOIT wrote: >> Hello, >> >> >> >> On 22/05/18 23:52, Moritz Muehlenhoff wrote: >>> Hi Jerome, >>> >>> On Fri, Oct 13, 2017 at 07:05:26PM +0400, Jerome BENOIT wrote: >>>> Dear Sebastian, thanks for your warning. >>>> >>>> The amount of change might be too heavy for me. >>>> Second, pam_ssh seems no more maintained. >>>> >>>> I have just contacted the upstream maintainer. >>> >>> Did you get a reply? >> >> No. >> >> I will have a look if time permit. >> And, of course, any patch is welcome. >> >> Cheers, >> Jerome > > OpenSUSE has an OpenSSL 1.1 patch in their package: > > > https://build.opensuse.org/package/view_file/openSUSE:Factory/pam_ssh/pam_ssh-openssl11.patch > > Changelog here: > > https://build.opensuse.org/request/show/547009 > > I'm attaching the patch. It will try to modify `configure' which isn't > in Debian's source tarball, but if you remove that bit, it applies > cleanly. It seems to work OK on my locally-built package. > > John > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken
On 13/11/2018 16:33, Jerome BENOIT wrote: > > > On 13/11/2018 16:23, Russel Winder wrote: >> >>> It does not look as a solution anyway. >>> And the issue does not seem to be a FireHOL issue. >>> I guess that we have to stick to package 3.1.6+ds-4 for a while. >> >> I've held all but one machine on 3.1.6+ds-4 but now need to revert the one >> test machine. Aptitude is telling me there is only 3.1.6+ds-5. Can this >> version be removed from the repository and 3.1.6+ds-4 reinstated, or do I >> just >> have to manually grab the packages and install them? > > It is a building environment issue: I would build the debian package from > source, > and them install it. > > I have just submitted the issue to the debian-devel debian list (I CCed to > you). > As temporary solution, I can submit a package built from a local chroot > environment. I have just ask for suggestions to the upstream maintainer. Jerome > > Jerome > > >> > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken
On 13/11/2018 16:23, Russel Winder wrote: > >> It does not look as a solution anyway. >> And the issue does not seem to be a FireHOL issue. >> I guess that we have to stick to package 3.1.6+ds-4 for a while. > > I've held all but one machine on 3.1.6+ds-4 but now need to revert the one > test machine. Aptitude is telling me there is only 3.1.6+ds-5. Can this > version be removed from the repository and 3.1.6+ds-4 reinstated, or do I just > have to manually grab the packages and install them? It is a building environment issue: I would build the debian package from source, and them install it. I have just submitted the issue to the debian-devel debian list (I CCed to you). As temporary solution, I can submit a package built from a local chroot environment. Jerome > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken
On 13/11/2018 12:24, Russel Winder wrote: > >> Package: usrmerge >> Description-en: Convert the system to the merged /usr directories scheme > > That seems like the beastie, and it is a once and for all time thing it seems. > I have not installed this. At least not as yet. I am hesitant to do this as it > is clearly not Debian Sid standard and it is not reversible. > > It does not look as a solution anyway. And the issue does not seem to be a FireHOL issue. I guess that we have to stick to package 3.1.6+ds-4 for a while. Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken
On 12/11/2018 22:42, Cristian Ionescu-Idbohrn wrote: > You don't happen to have that "move everything from /bin, /sbin, /lib > to /usr/..." package installed? Do know have the short name (or regular name) of this package ? Thanks in advance, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken
On 12/11/2018 15:30, Russel Winder wrote: > Hi, > >> No assumption, everything is configured with configure.ac > > I was hoping it was generated rather than manual! :-) > >> I rebuilt the package in schroot environment , and the path for mktemp is >> correct. >> >> Can you determine from which package version the faulty install.config come >> from ? >> > > |> dpkg -S /usr/lib/firehol/install.config > firehol-common: /usr/lib/firehol/install.config > > |> dpkg -S /bin/mktemp > coreutils: /bin/mktemp > Can you get te version og the ffirehol package ? Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken
On 12/11/2018 13:32, Russel Winder wrote: > Hi, > >> It looks weird. >> >> Is MKTEMP_CMD defined as expected in /usr/lib/firehol/install.config ? >> > > |> grep -i mktemp /usr/lib/firehol/install.config > MKTEMP_CMD="/usr/bin/mktemp" > > I think the file assumes everything that isn't in /usr/sbin is in /usr/bin, > but Debian has mktemp in /bin not /usr/bin. No assumption, everything is configured with configure.ac I rebuilt the package in schroot environment , and the path for mktemp is correct. Can you determine from which package version the faulty install.config come from ? Thanks in advance, Jerome > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken
Hi Again, sorry for that. It looks weird. Is MKTEMP_CMD defined as expected in /usr/lib/firehol/install.config ? Jerome On 12/11/2018 12:36, Russel Winder wrote: > Package: firehol > Version: 3.1.6+ds-5 > Severity: important > > Dear Maintainer, > > The upgrade of firehol from 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol in a > broken state. > > > Setting up firehol (3.1.6+ds-5) ... > Job for firehol.service failed because the control process exited with error > code. > See "systemctl status firehol.service" and "journalctl -xe" for details. > invoke-rc.d: initscript firehol, action "restart" failed. > ● firehol.service - Firehol stateful packet filtering firewall for humans >Loaded: loaded (/lib/systemd/system/firehol.service; enabled; vendor > preset: enabled) >Active: failed (Result: exit-code) since Mon 2018-11-12 08:29:33 GMT; 4ms > ago > Docs: man:firehol(1) >man:firehol.conf(5) > Process: 7766 ExecStop=/usr/sbin/firehol stop (code=exited, > status=1/FAILURE) > Process: 7799 ExecStart=/usr/sbin/firehol start (code=exited, > status=1/FAILURE) > Main PID: 7799 (code=exited, status=1/FAILURE) > > Nov 12 08:29:33 lavaine systemd[1]: Starting Firehol stateful packet > filtering firewall for humans... > Nov 12 08:29:33 lavaine firehol[7799]: /usr/sbin/firehol: line 1043: > /usr/bin/mktemp: No such file or directory > Nov 12 08:29:33 lavaine firehol[7799]: ERROR: Cannot create temporary > directory in /var/run/firehol. Make sure you have a working mktemp. > Nov 12 08:29:33 lavaine systemd[1]: firehol.service: Main process exited, > code=exited, status=1/FAILURE > Nov 12 08:29:33 lavaine systemd[1]: firehol.service: Failed with result > 'exit-code'. > Nov 12 08:29:33 lavaine systemd[1]: Failed to start Firehol stateful packet > filtering firewall for humans. > dpkg: error processing package firehol (--configure): > installed firehol package post-installation script subprocess returned error > exit status 1 > > > I am assuming this is a script problem: > > > root@lavaine:~# ll /var/run/firehol > total 0 > drwx-- 2 root root 60 Nov 11 18:44 ./ > drwxr-xr-x 28 root root 780 Nov 12 08:30 ../ > -rw--- 1 root root 0 Nov 11 18:44 firehol.lck > > > root@lavaine:~# ll /usr/bin/mktemp > ls: cannot access '/usr/bin/mktemp': No such file or directory > > > root@lavaine:~# which mktemp > /bin/mktemp > > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) (ignored: > LC_ALL set to en_GB.UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages firehol depends on: > ii firehol-common 3.1.6+ds-5 > ii lsb-base9.20170808 > > Versions of packages firehol recommends: > pn fireqos > > Versions of packages firehol suggests: > ii firehol-doc3.1.6+ds-5 > pn firehol-tools > pn ulogd2 > > -- Configuration Files: > /etc/firehol/firehol.conf changed [not included] > > -- no debconf information > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#913447: Fwd: Bug#913447: libgap-sage: Depends on nbs version of gap
Hello, I guess that we have to remove libgal-sage-4 sooner or later: please let me know when we can remove it. Thanks, Jerome Forwarded Message Subject: Bug#913447: libgap-sage: Depends on nbs version of gap Resent-Date: Sat, 10 Nov 2018 23:39:01 + Resent-From: Jeremy Bicha Resent-To: debian-bugs-d...@lists.debian.org Resent-CC: calcu...@rezozer.net, Debian Science Maintainers Date: Sat, 10 Nov 2018 18:36:55 -0500 From: Jeremy Bicha Reply-To: Jeremy Bicha , 913...@bugs.debian.org To: submit Source: libgap-sage Version: 4.8.8+6+20181010g0581647+dsx-1 Severity: serious X-Debbugs-CC: calcu...@rezozer.net libgap-sage-4 has this dependency: Depends: gap (>= 4r8p8), gap (<< 4r8p9) But the version of gap in unstable is 4r9p3-3. I've filing this as serious since version 4r8p8 is no longer built from source (NBS) in unstable. Thanks, Jeremy Bicha signature.asc Description: OpenPGP digital signature
Bug#905191: libecm1-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Hi, On 14/10/18 14:11, Andreas Beckmann wrote: > On 2018-10-14 11:37, Tobias Hansen wrote: >> It looks like it's just a typo in the maintscript. The path is >> /usr/share/doc/libecm1-dev-common but the mainscript file is: >> >> symlink_to_dir /usr/share/doc/libecm1-dev /usr/share/doc/libecm1-common-dev >> 7.0.4+ds-2~ Aaaah ! > > Thanks Tobias, that seems to be the plausible cause. Didn't have much > time recently to dig into that, was still on my todo list. > > Don't forget to bump the version in the maintscript when uploading the > fix, should probably be 7.0.4+ds-4~ I will fix it as sson as I can. Thanks, Jerome > > > Andreas > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#905191: libecm1-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Hi Andreas, I thought that I fixed this issue. The difficulty here is that I am blind here: how can I reproduce the issue on my own ? Thanks, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#882287: xul-ext-noscript: new upstream version
Please consider to the new upstream version 10 given that the current version of noscript provided in Stretch does not work with firefox-esr 60.2 recently brought in Stretch. Thansk, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#901102: firehol-doc,firehol-tools-doc,fireqos-doc: fails to install, trying to overwrite other packages files
Dear Anbe, so far I cannot reproduce the issue with piupart 0.87~bpo9+1 on my Strecth box: what would be the command that reproduces the issue ? Thanks, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#859054: libpam-ssh: Please migrate to openssl1.1 in buster
Hello, On 22/05/18 23:52, Moritz Muehlenhoff wrote: > Hi Jerome, > > On Fri, Oct 13, 2017 at 07:05:26PM +0400, Jerome BENOIT wrote: >> Dear Sebastian, thanks for your warning. >> >> The amount of change might be too heavy for me. >> Second, pam_ssh seems no more maintained. >> >> I have just contacted the upstream maintainer. > > Did you get a reply? No. I will have a look if time permit. And, of course, any patch is welcome. Cheers, Jerome > > Cheers, > Moritz > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#894494: singular: FTBFS: coeffs_test fails on arm*, mips* and s390x architecture
Package: singular Version: 1:4.0.3-p3+ds-5 Severity: serious Tags: upstream Justification: FTBFS It appears that coeffs_test fails on most of official architectures: the issue was reported to upstream: https://github.com/Singular/Sources/issues/862 Thanks, Jerome -- System Information: Debian Release: Stretch* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages singular depends on: ii singular-data 1:4.0.3-p3+ds-5 ii singular-modules 1:4.0.3-p3+ds-5 ii singular-ui 1:4.0.3-p3+ds-5 singular recommends no packages. singular suggests no packages. -- no debconf information
Bug#889584: fpylll: FTBFS on 32-bit architectures: test failures: OverflowError, SystemError
Control: forward -1 https://github.com/fplll/fpylll/issues/114 thanks signature.asc Description: OpenPGP digital signature
Bug#888758: marked as pending
tag 888758 pending thanks Hello, Bug #888758 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/python-modules/packages/fpylll.git/commit/?id=b6c8e16 --- commit b6c8e1612e8201206eff3dca6eed769445ace8d1 Author: Jerome Benoit <calcu...@rezozer.net> Date: Fri Feb 2 19:04:08 2018 +0400 Debian patch 0.3.0+ds1-2 diff --git a/debian/changelog b/debian/changelog index 5354a8a..896edb7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +fpylll (0.3.0+ds1-2) experimental; urgency=medium + + * RC fix release (Closes: #888758), complete copyright for s/f/gmp/* . + + -- Jerome Benoit <calcu...@rezozer.net> Fri, 02 Feb 2018 14:59:25 + + fpylll (0.3.0+ds1-1) experimental; urgency=medium * Debianization:
Bug#888606: marked as pending
tag 888606 pending thanks Hello, Bug #888606 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/python-modules/packages/cysignals.git/commit/?id=393c0ef --- commit 393c0efc81d9bac3738190f28c784427659da9b1 Author: Jerome Benoit <calcu...@rezozer.net> Date: Mon Jan 29 08:52:48 2018 +0400 Debian patch 1.6.6+ds-3 diff --git a/debian/changelog b/debian/changelog index 6c09f61..9c51b49 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cysignals (1.6.6+ds-3) unstable; urgency=medium + + * Upload to unstable (Closes: #888606). + + -- Jerome Benoit <calcu...@rezozer.net> Sun, 28 Jan 2018 17:05:11 + + cysignals (1.6.6+ds-2) experimental; urgency=medium * Debianization:
Bug#888606: Fwd: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build target
Hello, this issue was fixed in 1.6.6+ds-2 which is current in experimental: can we migrate cysingals 1.6.6+ds-2 to unstable ? Thanks, Jerome Forwarded Message Subject: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build target Resent-Date: Sat, 27 Jan 2018 17:51:02 + Resent-From: Niels Thykier <ni...@thykier.net> Resent-To: debian-bugs-d...@lists.debian.org Resent-CC: Jerome Benoit <calcu...@rezozer.net> Date: Sat, 27 Jan 2018 18:44:34 +0100 From: Niels Thykier <ni...@thykier.net> Reply-To: Niels Thykier <ni...@thykier.net>, 888...@bugs.debian.org To: Debian Bug Tracking System <sub...@bugs.debian.org> Source: cysignals Version: 1.6.5+ds-2 Severity: serious Tags: patch Hi, The cysignals package FTBFS with debhelper/11.1 as it has an empty build target. This is caused by debhelper had a bug in its handling of "explicitly defined rules targets" that has now been fixed. Previously, this happened to work because dpkg-buildpackage would invoke "debian/rules build" (which would be a no-op) followed by "fakeroot debian/rules binary". During the binary target, dh's suboptimal handling would run the build commands. The solution is trivial but less pretty; explicitly define "build" with the same content as the "%:" target (or rename the "build" folder and drop the ".PHONY" target). I have attached a patch for this. More details can be found in: * #886901 comment #35 * #887688 comment #37 * #880840 Apologies for the inconvenience. Thanks, ~Niels From 3a57538b93ca415f235feb04b19395a576dfc60f Mon Sep 17 00:00:00 2001 From: Niels Thykier <ni...@thykier.net> Date: Sat, 27 Jan 2018 17:43:04 + Subject: [PATCH] Avoid empty build target The dh sequencer as of debhelper/11.1 is stricter with this in order to solve #880840 (where debhelper would fail to handle such targets correctly). Signed-off-by: Niels Thykier <ni...@thykier.net> --- debian/rules | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/rules b/debian/rules index 4872a50..bfd28fb 100755 --- a/debian/rules +++ b/debian/rules @@ -18,6 +18,12 @@ default: %: dh $@ --with autoreconf --with python2 --with sphinxdoc --buildsystem=pybuild +# The build target must not be empty. Sadly because of how make +# works, we have do duplicate the target in this case. +build: + dh $@ --with autoreconf --with python2 --with sphinxdoc --buildsystem=pybuild + + override_dh_auto_configure-arch: $(call adhoc_dh_auto_configure_do,bare) $(call adhoc_dh_auto_configure_do,pari) -- 2.15.1 signature.asc Description: OpenPGP digital signature
Bug#888560: mpfi dependencies inconsistency
Hello Tobias, thanks for the hint. I have just upload a corrected version.
Jerome
On 27/01/18 17:19, Tobias Hansen wrote:
> On 01/27/2018 01:41 PM, Jerome BENOIT wrote:
>> Hello Vincent, thanks for your bugreport.
>>
>>
>>
>> On 27/01/18 06:31, Vincent Lefevre wrote:
>>> Package: src:mpfi
>>> Version: 1.5.3+ds-1
>>> Severity: serious
>>> Justification: Policy 7.2
>>>
>>> The current libmpfi-dev version is 1.5.3+ds-1+b1, which has:
>>>
>>> Depends: libmpfi0 (= 1.5.3+ds-1+b1), libmpfi-dev-common (= 1.5.3+ds-1),
>>> libmpfr-dev, libgmp-dev
>>>
>>> but libmpfi-dev-common 1.5.3+ds-1 has:
>>>
>>> Recommends: libmpfi-dev (= 1.5.3+ds-1)
>>>
>>> This is inconsistent.
>> This true.
>>
>> Do you have any idea from where comes the +b1 ?
>>
>> Thanks,
>> Jerome
>
> Hi,
>
> the +b1 was appended to the binary version for the rebuild against libmpfr6.
> This is a matter of using (=${binary:Version}) vs. (=${source:Version}) in
> debian/control.
>
> Best,
> Tobias
>
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
signature.asc
Description: OpenPGP digital signature
Bug#888560: mpfi dependencies inconsistency
Hello Vincent, thanks for your bugreport. On 27/01/18 06:31, Vincent Lefevre wrote: > Package: src:mpfi > Version: 1.5.3+ds-1 > Severity: serious > Justification: Policy 7.2 > > The current libmpfi-dev version is 1.5.3+ds-1+b1, which has: > > Depends: libmpfi0 (= 1.5.3+ds-1+b1), libmpfi-dev-common (= 1.5.3+ds-1), > libmpfr-dev, libgmp-dev > > but libmpfi-dev-common 1.5.3+ds-1 has: > > Recommends: libmpfi-dev (= 1.5.3+ds-1) > > This is inconsistent. This true. Do you have any idea from where comes the +b1 ? Thanks, Jerome > > -- System Information: > Debian Release: buster/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, > 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) > Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > libmpfi-dev-common depends on no packages. > > Versions of packages libmpfi-dev-common recommends: > ii libmpfi-dev 1.5.3+ds-1 > > libmpfi-dev-common suggests no packages. > > -- no debconf information > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#881869: FTBFS: recipe for target 'test-/5x5PF.diff' failed
Dear Aaron M. Ucko, thanks for your report. I have already filled an issue about it: https://github.com/Normaliz/Normaliz/issues/161 I hope it will be fixed quickly. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#877210: normaliz FTBFS on i386/armhf: Some error in the normaliz input data detected: Error while reading grading (a 1x2 matrix) !
Hello Folks, it appears that the latest version also shows up issues on i386 arch. An issue ticket has been emitted: https://github.com/Normaliz/Normaliz/issues/156 . Thanks, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#877210: normaliz FTBFS on i386/armhf: Some error in the normaliz input data detected: Error while reading grading (a 1x2 matrix) !
Dear bunk, thanks for your report. I have just realized that d/watch is obsolete and that normaliz has evolved a lot since the last packaging. I am on my way to package the latest version (3.4.0). So, let see what will happen with this new version. Thanks, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#860664: primesieve: FTBFS on i386: dh_auto_test: make -j64 check VERBOSE=1 returned exit code 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, unfortunately I cannot reproduce the issue on the Debian porter barriere. I am on my way to ask to the uptream maintainer. Thanks, Jerome -BEGIN PGP SIGNATURE- iQQcBAEBCgAGBQJY+wh4AAoJED+SGaZ/NsaLSsAf/3+6IEoFEFJwG2aqE2VKv2Z8 71sm1lmWkbmfRiCfo94OoGaanAH+jnEMIVuoc53WVhUVKv+eILh1lWV98EB1iaJ8 DhAPTqpWsadtqknvfdGDtVRwuLZTZMcPowODW2RoH9NQ52EEMhRNjnC3UipBONth q6f4Qx28edJPQMm5Vuz4hg1Zo05LeKVa3h1ARdonKqIFeP/ZnMKDESXODipCfWVp eRnxVzXfwsbhQ+QdJBljpOobNviKpiD6xn8UhSQsy3hIifJsRKrleZbAgOrOTUrJ S/kSDqBQBMn+JPx4qcdvlewETnovalQwnr3q7Pf+FSzIudw3vL6nyaeE8oR3Vct0 2PYx/QN6mXsMYc0C7HRf1RC416NKxVxdt8MEbyJ7eKst1Qn9f6aywbPAEdC+jbEw yywaAPLZ/vkzz4163aD5h3yZFl7v57kQpZsC70YjntYt3TwZZ67UoUKxl825lu3e 7aWrYVsn4iMiY88wv0u5C9+ovNHmWkEXbfvFfc1i4FMF8qNgBAJHKxolkYDtXtMn i1LU1T/fg9BO24nczoP9GdwowTnW7A2iQXzd2RH4aGORwfrvuqyXCTVEEDofFEXm XYL8Zk/aAgLe4R/YmUVNtQ9cBMdKjaXszVkw2CZx3EFnAX/dTOEPm11rlys1LSmw gS3OIX9orJAGAOu6NWsIvUQlNaiLg7Bs2/7K3jB2U+5NL+8AcMqWJd+Lx1lEkTvA A40oOhfgqdGcP5DIKCxa42NahPJmUym+TeVa5oSh8r3KJlT409AD4L1kObWBn7vf ePYtoF9o3qM2tzYDMXPP8EMMBHaw2uc7bvOU715KwJQEzPBnOtZW5bCocIZgMtr9 CFH+3M87kVbaqaCWciJ+DQAAanXiiJP1tr6QTGsgQqU0+1tBWf6i6KA48iPmvaFA F5KKP+4of2v7HfR7OwtTT/mRlb7UqT23RowzPgIrodzz1w8ce6mwCjrOslQxVyM8 zjeo2tI0mqrFqCS3VpPTdZpt4HV5GpX8hkyld1ObtOm1nBSJX3pG8g2xXfYNOuWl tNW4YdbX5Iwll/iQONiZAkNDck6pjvUadTWu2FBfT3zhrN4o5eF+pmTtiLCQhn4T hcVk04Dw8fGIVmNYvafJ1Oy2SSUSU6I/njRvqwKnFUJgx46E18c50wWV4twlB72v XEsmgxmi4Okbsq2SgImaGigrWr+3Gfa32kuPCra7PYRxVqA7i1C8rUrIlCXuvNQT 576TnVG48IcrpG9Tx5eKZSYYO6dsCpNrRtiGgMlCoDxcYGdqZyXUWhnKw55owIB6 ByCm0YwXn6mguhDJ8md6cLdc9kTo+RnIbGp4N7ST5wgAqqr/sOQlnXqQ/6tzGTw= =CaVZ -END PGP SIGNATURE-
Bug#855615: tachyon: not binNMU safe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks, now I can reproduce the issue. Jerome On 22/02/17 14:08, James Cowgill wrote: > Hi, > > On 22/02/17 07:01, Jerome BENOIT wrote: >> Dear James, thanks for your report. >> I am looking for reproducing the issue. So far, I cannot. >> Where can we get the binMMUed source material ? >> Cheers, Jerome > > Starting from tachyon 0.99~b6+dsx-7: > $ dch --bin-nmu test > $ dpkg-buildpackage -B -us -uc > > Or alternatively using sbuild: > $ sbuild -m'test <t...@example.com>' --make-binNMU=test --binNMU=1 > tachyon_0.99~b6+dsx-7 > > Thanks, > James > > > - -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B -BEGIN PGP SIGNATURE- iQQcBAEBCgAGBQJYrXq1AAoJED+SGaZ/NsaLytwf/1/+s2kWcTI+D0lKksSEItqR LvE68gKFPsSP82uWf6tXzbhSoDWXrQqBOX0pxbSVukyUogdczw1ZAxttFrN3ZRJI N5v+0UZTyhrbIem0BgxZeOWAZhhsWZQoddF10AFVLq04EIsNc687kdQqqFzAKM6M DglNeAv4HRBCXqcgNPZqeMEoOz385khL9gMCE4gKsuEXRQZNUKuCSxTVH5wdpOZY OcfiXowQeZkXAtszBqjNf0kVHHwTUJLEuTRg+0B3nkG0DGRtd9di72wTpiRlb6oY 8NztEKV0H0Kmx+a4oBHDk5LwiGvzZ1mlMxFIjVVGrKegFoHlRmiGarMoG77Fy0Jo uzcbJHq1OtUsz4vMi/jU0FDNoj9vVREuyG//CvNisZ8GAhqMbgMyLPn2qOB4smtb xwoyktLWXfPhaxghBBg8nvrpwxoztvSSjUOBQ+cQq0sOCtbyn5Iuv56865XZmdq9 kkrEb/LmrtP3rRVi7gAqAMUUDUg1253t/Hg8n3vcSMVQqd1MDGkZzbYWodnanFEM BrJKymf8HaNqRgxX2wPfmnYj9SRIu0+suTctY1OlWTrmoTX3vyxKJaXGeO0Ns9Tu SEhrIMIP9lF4ILGKTlXsGF4MziakSvlY9SzVh00853igEU/Dpwz9mbZDOPXPe6NB VdcK/nuyCnk9YO6eYBOFECdBV5vTSLNwmcWGH21lkl87gzaj2QiOPWGR4EElKv51 DKVfj7G2V+gdQE3ItQeCOjce21Ux9bY2Mf50bZgIeQ7jEGh2Qdy0v9UT6nAjtW3g fXDh1plYrUu2bt8CH004W2syyPSnuSZgotUTRSAfWQg3pW2uiUPNX8giZ+ly2FsW JXef7zSBmzh6d/UN4cWSLMizSS7XGZ/KOw6lI2Vv6mTC6pO/jXZgR5TcF1gKbiug 1eyEWG5Hvrzdp5zUVqfD5o9fyuzyrs9IwltgJbFz6KXW99MpgZ7b4TFlt/AO+YA6 GOOAh5RYqBQOVjZNlLlya36IEKcuia2MmEqEde6+pIE/XXbyX4wyB8qaxyoo+gji 9au6HKFV++TfRnkDjzsiE0y0GyPjsnzSA2YGzewXbgeGIOQ6k+nL5GlErJcSzZsc ijol+dISUZa9Kb2FgHhX0bParAcMfrU5JTG3yEBJ8HKuyaofGbmfLBvZuH4IOfn0 2m0okf/0ncLDrc1iLwPZbl2cpuFpiOLXaQje00a2LXvgJ3rTJq8+WyoPZKpqPyjx e3iWgDbB2LUKHL6mDP5eNzZV4vDdP2fOy+U/6q5Wfse2ZVu7fcQsJE4g3A5+q/7X W+YpP3wD44w2kqnE6SweS4zoUg84+R884Y42zgCeZUz2r71F0wMTyNJ1/onMrZw= =oo5G -END PGP SIGNATURE-
Bug#855615: tachyon: not binNMU safe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear James, thanks for your report. I am looking for reproducing the issue. So far, I cannot. Where can we get the binMMUed source material ? Cheers, Jerome On 20/02/17 23:42, James Cowgill wrote: > Source: tachyon > Version: 0.99~b6+dsx-7 > Severity: serious > > Hi, > > tachyon was recently binNMUed on mips* as part of fixing the fallout of > the binutils symbol table bug (#844227) but unfortunately it is now > uninstallable on mips. > > Multiple packages are affected, but for example the Depends line of > libtachyon-mpich-0-dev contains this on mips which is obviously > unsatisfiable: > > Depends: libtachyon-dev-common (= 0.99~b6+dsx-7), libtachyon-mpich-0 (= > 0.99~b6+dsx-7+b1), libtachyon-dev-common (= 0.99~b6+dsx-7+b1) > > This is likely caused by the use of dh_installdocs --link-doc (see > #747141) > > Thanks, > James > > > - -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B -BEGIN PGP SIGNATURE- iQQcBAEBCgAGBQJYrTc9AAoJED+SGaZ/NsaL1+UgANMdjPsRAQLaI3aktjExBSxv +w1xZ+BhxtB1MKCxwbI9Oikr6/BgB3j14mtFldyr9dHEMaHyNuqkRbYCKct7AwGf l4JfW4AHJ/TZEkxIuWio23wt25DNywfjKrCXRstDfRvvXwH940YYOZR5dwDMHKJM 5ueSaRirSj1Dbrg26b6cAwZ1ZWcT4fgVn8v5xsYDAiKumjIXnvweqDq04PH9nWFs rNGWbHrhPdV3JtUqrpezbbV1Tfi7e0W0ZPYfgbGY9IkQ32HuHcCL77DlFmyP4chW O5OnxO3QpjZR/v0dF+NbzvhTBlGT/CBhj+O3t96fJIi11YLtRkd0vUKW1vfvI3Zg z7Xk+KORk2l9UzEVZh7hsb64JxSis+wqG41T1L6yauY/bplvdQglvv/zgkeByAMl gVdf9WTKkrnsEiPYKNDRIt5YaKBc8ENHm52ZXy/7c3SY2L2p2G1LdZa58UmzfCHy xgjGw1qO9c26TKKjZCyBcn25/kEzThcPTDfomo7+l8AZUkn+/TE7din9xhqxqss8 H5TFDkzOdS8H8QG6JtryGy5t9gzv5uxZB8nrD6rJtdd/UfoNNQx2agu3F+1d00ot nCkrV2JPQoBoXmDBVaIKffUyzqUYJoark9V3XuDPSleG/7YGZ/hH6n6jwohBruFz JJ88L39GSArOss60661HOamXxIR1slEVSenn6+tfoj+VZ5k4A3gWsb+MVMgYVttu +YwdH0UOfMhBKdj1ovMn75nOrcsMZGhXgri8tNjA+PODkV4bcGVryNfC9mAuiyzo sjvz/SjL1WHUmD1YEWjMxvFqFJ8MCFO2+53nWMUZyUiR6Hm90xs7K78rbOC88uzJ sPHb4zX9+EH0s9MxlQ+M4ahmunpIa07AaTbyphZHaVxRH8gTFiDbzZgNbgGw0UjG J+Ahp1ZvO8iRVV3/5vKPVpFIKTxZmgIk4mgzbXmqSC3jqogFWrYL5NkxcxeVeNlp P3m7wjlzk2PsVq4FIMSgVygPuFxz0IH5jQFJyVlU5V+7z4CK08jAbGeE5ipIXP5y jZPBza+vV7MJV57L88jKjisUShCVkQZojchPs7MdXrI/K+8662Ju5HYwBcqbMRys hRuqub7jjdZpHyIrqCXS1UTSdudp6uNnWs7T1Sy6IgFC6AZDMTiffOmZmkbp3NJ1 ryC5LJVQtB8laXriePVFsT4rNhOKue6ZiHrF4GdfaIIc8pyolH6kCy83w3tf9p5s FIx52v6Ao84NTzDXViPxpx9y4XC+OEZHecvwGANB1yAtfKeGubJa+3E1/TJdVVNK VKqSiaoekNZ5W5k9cJ/JAfLGhS6CNIGCUiRspOh70xF7gSfa9YaIhBh/y6th7wE= =z8iO -END PGP SIGNATURE-
Bug#850929: FTBFS: sage tries to create a directory in HOME
Package: sagetex Version: 3.0+ds-3 Severity: serious Justification: fails to build from source Dear Sate[TeX] enthusiasts, it appears that sage creates directory in HOME, what sbuild forbids I am on my way to fix it. Thanks, Jerome -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sagetex depends on: ii dpkg 1.18.3 ii imagemagick 8:6.8.9.9-5+deb8u6 ii python-sagetex 3.0+ds-1~sage7 ii tex-common 5.03 ii texlive-font-utils 2014.20141024-1 ii texlive-latex-extra 2014.20141024-1 sagetex recommends no packages. Versions of packages sagetex suggests: ii sagetex-doc 3.0+ds-1~sage7 -- no debconf information
Bug#849661: gap-guava: FTBFS with some SHELLs(?): cd: too many arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello GUAVA enthusiasts, @Chris, thanks for report the issue. On 29/12/16 16:08, Chris West (Faux) wrote: > Source: gap-guava > Version: 3.13+ds-1 > Severity: serious > Justification: fails to build from source > Tags: sid stretch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build: > > gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/build/gap-guava-3.13+ds/2nd=. > -fstack-protector-strong -Wformat -Werror=format-security > -Wno-unused-result -Wl,-z,relro -Wl,-z,now -o leonconv leonconv.c > cd leon make > /bin/sh: line 0: cd: too many arguments > Makefile:14: recipe for target 'all' failed > I can reproduce the FTBFS within a schroot Sid environment on my amd64 box with bash as sh. This shell issue is rather disturbing. > > There's definitely an error in the Makefile: > https://sources.debian.net/src/gap-guava/3.13%2Bds-1/src/Makefile/#L14 > > all : $(FILES) > cd leon make > This code looks insane. I am on my way to attempt to harden it, > > The variation appears to be that most shells treat this is "cd leon" > (and ignore the rest of the arguments), whereas some shells reject it as > an error: > > % mkdir -p foo bar; for s in bash zsh dash posh sh; do $s -c 'cd foo bar'; > done > zsh:cd:1: string not in pwd: foo > posh: cd: too many arguments > > (the others succeed) > > I have no idea what upstream intended there. > > A full build log can be seen on the reproducible-builds builders, which > vary the shell (between bash and.. some sh): > https://tests.reproducible-builds.org/debian/unstable/amd64/gap-guava > Thanks, Jerome - -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B -BEGIN PGP SIGNATURE- iQQcBAEBCgAGBQJYZvAWAAoJED+SGaZ/NsaLJBAgALNPE1jQx+vhGMGWTiFUJytV U9s3YDlwrnWN0BC+XIKOYouz7PXxgqZ7n5j4vbFhD2bUARxizYXjedWs7ClidGig PR2vFyuNHz63PP2NOyDDr+VPr2deIPSSsA1M3V5lJ1jzP6KJeK/JdrWRfMxgmwJT MdQZoLJsLADbJm+gY05iiK3juKwLkwS3TBRf1YVj9Qk1w+G226c2NLZu/8HylE0y cJCGUgAMJxiVViwoS6ycVcQ3GE0stAbtIw/Str7sDtAzcylweD6DEwkxg3/sNowT YB5yXpnELUPOBbM94nwRMOnIXbBjtCjpNS0Rv3ULBiFb/VgNdAijhIdRF+Xh/QxU ltkvcCmuV6jx7Kp2tKv0xQyktBvEoCq2RWxOsvOKqW3j/7HHa25OWno+icddslUE 6l9sJsN12NO6hQcmJKwNciof6+f7vkTtq6AT5iDWFjlfx6tCVQY1NBJU9EPX/C+P BvXbXzXtAvP4izAByyTbNiHaylDc8LaXGXMk8AWu1ZWWStI86L8wrL0L3AqF2V2l 648BvPIMgnOc0ljlEN+8ITOSpyzDEtPnNz/jPdIKcuIJ+o8RnAvgQ0xvaFzRz69k a1IFSeIkAXkNmW06hUN1oTJH8clTsnMCNRmr7QvjbGM9IyWXkCrZz1yQxLfAkQdg U4fHZmuOl92TyEIePO7V85C/GDB//+1fA2mf//QFFSvN5tfVhY6tXWgRhkLLsi3C JceuMQl0CIQZIksznlJCT0uO99F6JOdeYuYq5nfXtZriaJCtiLhoAuZmjoUnrind Iiy7tC6jErgCQ0fluCbCw3sey9joUKKePR8BwDMhZKpvDo4+KU6+gYD8aasqSeaw euDZi5b73g4eoM7Xz2g9arCLBFnIn8Fd7h9LFHXNtSmK4jsDcL0Pa4TDcsmC9faX TIj2EZLi9lG0SSU5ChwZ294wegeETw4y9chFYANNyBf/67ixICJtonJUjKDOHEj7 yQCxD9zivwCxMJZyHC1N3aJM/vpQiBAGpQ4H7NgK2KWfjXHkmZSGsaF7MbQLJfqF iWOAQFyEoeb54gLcZ5rAgy6IdrJ4FzlqL2FKFl9AyvcLGQIg5w6Hl0M3zYwHuyaP lh6+IDy32tTAgWCWf6L9UWbhK3M5jwcZCsK8OJUhMfSNNtAS2j2wS6M37bI6JAlj FyD3rkrCXHsZKIBuxvmtwG/zWJ/tGs737aoGlBepNPmTE4R6/s7NtdYOz5tmG2EZ o+aH9Bhzn0kF6SOBBWtgKbYHuPUpbeCru50m55w7fFd3PJ9vNFJHc9X8dP0KJJbs BnfqDtLhMy6L7ywRtqVKU+V23Asg1TeQkRLYaXLq1Ox3XU1VM4omRuusXTMlgRc= =YI3F -END PGP SIGNATURE-
Bug#848131: libmpich.so.12: cannot open shared object file: No such file or directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
I can reproduce the issue in schroot Sid environment on an amd64 box.
The Depends fields for the libraries is
${shlibs:Depends}, ${misc:Depends}
and it works fine except for mpich. Before to add it by hand, I want
to understand why dpkg-shlibdep does not make properly its job.
$ dpkg-shlibdeps
debian/libtachyon-mpich-0/usr/lib/x86_64-linux-gnu/libtachyon-mpich-openmp.so.0
gives something interesting:
dpkg-shlibdeps: warning: /usr/lib/libmpich.so.12 has an unexpected SONAME
(libmpi.so.20)
dpkg-shlibdeps: error: no dependency information found for
/usr/lib/libmpich.so.12 (used by
debian/libtachyon-mpich-0/usr/lib/x86_64-linux-gnu/libtachyon-mpich-openmp.so.0)
And, more interestingly,
ls -l /usr/lib/libmpich.so.12
gives
/usr/lib/libmpich.so.12 -> libmpi.so
libmpi.so coming from libopenmpi-dev while
Installing only libmpich-dev on a fresh schroot gives similar output:
it looks as a mpich building error.
Thanks,
Jerome
- --
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-
iQQcBAEBCgAGBQJYUss5AAoJED+SGaZ/NsaLK1QgALlj2ZJXzdAxOmWpHKKVruY/
kCKyohDtPF5GhJJMQdH/rx2DUK8OXyNBO0mQfFPg4yEcqcO90xedVjnQdC/Zly79
SGP7UWyA0EX+qiIQsFXBFBVI53SOCDLBPoXN7YQBFio7kC7Cd33PpwceGVBkNb76
vkk2yonI54XP0HdpDvrodX+mxjiSVScNEj+6aWTvLLtvCfQ9JL6ZmAW1RXzSO2fS
qLZ+k73QUW5AdgTetpRTrPDZ/OjNJjxyeKvnOkUT4OFfUG/By/fAReeLKY6OGpQa
/MmciVqDm+cQftoqdjT94PJH9i+lamUM/qfUebjZ//cjlqNxmTz/uO3Za0tt8cxP
73+fXk4h+dc5SITx5/fV+U+Kuk76hCXr+W4Z4HoA4hhSmJ6viRNLeQVxsXajcqeH
AsRIjFgPQFw8cfabCTycimbAud0UaSZUKdU1yrDIWjsmet8Cq7yMiJTnNrvWZnP3
85+YWPXulNuoeWWxBGSucJjsE/ytIXDBYMxGpNVjvoDSthh95ov0Q9UotTkSO9yO
WAWUy9Jpa78+Xu+ZvFHm0/7cLWWPHkTojnUiHBhjNWFfA1KLFaMef4w2KKg6fjzp
wa6idHQdmzz1W3o+ZL7ws7PeFFFgbFG18K4UX4wA5aaY6jiALGebh/iZBESKBAD3
Hke6SP6Y0df8Sq0ThXr+1PlNFnwBEzeReT3ktvjBAtOUy6USEK/JkiL0FBGQ4+F0
ttJQjm81n98LkZvjT/nxc2atZC0jF1ECtYej1b/Ws+KauGuX5KaRHDstafistIPB
Art/UOCOMM/qD39kXaSv0vtl2n22VH+/pg4Z1w+BbndjYTVXlY6c7HD3YrFrWwCG
eYtQvuH+GK+r9W4eFKdN1sDs6Ob/RpPknTbzyQStiWUZBioyEzWKtALpkFCps4lF
tF0cKztNQCZXBKaJGksNHlnpB96h4z2XQcUSLynBlqEWM5zuobOWP8v0wSPWxz3S
ARBd0/qlqJJybwP0v4id8ovvJg6bxZ4uBKZyEk1e/NIajs1Tbr7e7UBo1tBF+BCE
MT6KC3bRP+DgdY++ibq6pLPipqTj9ereDxwdZOkTbQsb0PubcTVPsBOBlhvQLAwn
2hptW7kDQbLsafFzoPuj7qQ9JOgwCO4cplWlEoK48ziilJAudFLXHSLhQPORh9RC
s/KyuoQ4lNb3xBs+OAU8zAUeg6+K6R47Jf7dRhHuhrFqcfT0vj7XNephZM20QMRR
QlDdne1hGTPPX23Tl3InMYvFKnIIWjdpkQAZuF351WBJ/qODdzqrPAR4aqffyyrq
DqH2+DJSCWq8JfjxQVXjs6HJKjhXhUZQg7p5JpPqtUJ/f6fYna/Sl6wyRiMydVE=
=ZczI
-END PGP SIGNATURE-
Bug#840397: stretch should not ship with readline6: really ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Matthias, I have noticed that the package libreadlin6-dev no more exist. The migration time was really short, not to say vanishing. It appears that one of my package, singular, emit a segfault when it is built against readline7 but not against readline6 [1]: so, in practise, there is certainly some incompatibility. Please, can you consider to reintroduce libreadlin6-dev the time necessary to fix transition issues ? Thanks in advance, Jerome [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840481 - -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B -BEGIN PGP SIGNATURE- iQQcBAEBCgAGBQJX/vTBAAoJED+SGaZ/NsaLuxYf/RaJ4UJ0K11tEGar8BBYOeEe eGtNYp+Jt2s9JLV3RyJm9xNEK7md4fmBR9qtc3vwiikNg98/A+9DJg4hZszT+GAx gz/1i9vD1XogiCLHfgYZ+sYA5/WDRJvolweRyhwiOHKpOtEBpy2jVFwxsNzrIHrt YUW9uKti5HGBr2tQsVdCqGEFhtFki0fnpZdoe+BAt9sNI+5cYH0r5w8oLypvqaKS r0KGyXIpr7C2Q21Ls2FTcWxpYTyB1QyWLhu0nf65x2kqWWVGPhOFqdocX/IcCOoH jNeEGHx+zCHuOVTZGsOMH93P362xeMfGtg/tTFuB0bTuPw1fq/5oD8NpFvpjTUHM 2gv8Mdj5YtIU+0OP7M0nc1Bsrbvp7uOZd4SCYgy6ZOz3l8L1LQGSOIirCwv8vKIZ zSmQUrBCMYctALbRt2t6a9fZQcG0LNV7x5BUnN/bPd1+8PoKvBdFUbddmvEpLFtL 2+GSDsqLk3uwbjeH3gF6g5gOsXWrpkeViiUrTk1Y8wH62neH24V/GP4rUE/FLNG6 0tSf37hKoZbFrdr060sd/iph4OPnlo80Pan6mnFSnrxvPhSDuY5YQdVL3tZou9e1 eFXCSl1DIPBLYUgQkjDceXB6mXb6e7JZutal4iOEXIaiahO3eQh1499hKRHzUaIg w/xNRH16yHG74YxEiny6NwpYr2b73cPloGJppf9736SVB2MR+btZBS9poefngKms wPb24/eK035I9kSfZIpEORAh3nPCTx68vSCXP85r+QFlBoSq2mR48cME9jsxDEea fNi332G7c2yAXVyeWQxAXdPw/DW3k0KjEVOkV/7UTCZzQtghY+XGg7Gqurlg66d2 n2BdBgABGIjWkkpFHHV7tGrUfXEhPMpUWgklcv0iXuk+OfSDc5zwpS1/ubiH0sxl cbr5BDqJjOLmegIUDytO5NIWzFlfY4ls42qEhFAwp9xHOD+yQaIPcnqwjngDveMo nxHImWvUvLXR6EISzdEKGhSLqjfb+mqkQU9RTkElpgbflryd5UXZPb035cm+2szd G864zja3efg0C/m/7FHLv/dZStqVo+qp6Rz4wQy1MTnP4tI0w59nnKqf/mCTk8cQ Ikb56UhPsIgqzYnu6R3lpc3pP5ySpE3gVncyD3QSgFmQkiRghFKbNWMHg0UwoFSx gWlWTCXCd/scEpJi9orK8udCoL1igg/tn298+QWkuT/Z72VfvG5GceOuFecjbQUy Cv5VAtPpDIgzVRDRogY0vEu6Zq3pxe1E4NgAYiz4AVpBntjTdKNJhlhMFZxHz1BO 9fsbe02xOe483PQnZU6lF1L/G3+O4eyfxvtdNwz8oNLsjRdSpHV4i5qzhpksxSk= =N4Nl -END PGP SIGNATURE-
Bug#840017: marked as pending
tag 840017 pending thanks Hello, Bug #840017 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=python-modules/packages/cysignals.git;a=commitdiff;h=5c8c673 --- commit 5c8c673d88be0e9c97bf73c57a8ae7b8930cc8f2 Author: Jerome Benoit <calcu...@rezozer.net> Date: Sat Oct 8 03:25:45 2016 +0100 RC bug #840017 fix diff --git a/debian/changelog b/debian/changelog index 95a15e0..a303c1e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,16 @@ +cysignals (1.1.1+ds-2) unstable; urgency=medium + + * RC bug fix release (Closes: #840017): +- debian/rules, conditionalize use of --with sphinxdoc appropriately, + thanks to Aaron M. Ucko <a...@alum.mit.edu> for the hint; +- debian/patches/: + - d/p/upstream-documentation-make-user_friendly_check-soften.patch, +introduce and submitted (hidden bug); +- debian/control, move help2man from Build-Depends-Indep to Build-Depends + (hidden bug). + + -- Jerome Benoit <calcu...@rezozer.net> Sat, 08 Oct 2016 02:23:57 + + cysignals (1.1.1+ds-1) unstable; urgency=medium * Initial release (Closes: #834232).
Bug#837016: singular: FTBFS: aminclude.am:35: error: DX_COND_doc does not appear in AM_CONDITIONAL version graph
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks a lot, I will fix it asap. Jerome On 29/09/16 00:23, Graham Inggs wrote: > Control: tags -1 patch > > > Hi Maintainer > > The attached patch fixes the FTBFS with recent ax_prog_doxygen.m4. > Note the build-dependency on autoconf-archive should be bumped to (>= > 20160320) as well. > > --- a/control > +++ b/control > @@ -5,7 +5,7 @@ > Uploaders: Jerome Benoit <calcu...@rezozer.net> > Build-Depends: > debhelper (>= 9), > - autotools-dev, autoconf-archive, dh-autoreconf, libtool, help2man, > + autotools-dev, autoconf-archive (>= 20160320), dh-autoreconf, > libtool, help2man, > libreadline6-dev, > libgmp-dev, libmpfr-dev, libglpk-dev, libcdd-dev, libflint-dev, libntl-dev, > graphviz, 4ti2, normaliz, surf-alggeo, > > > Regards > Graham > > > - -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B -BEGIN PGP SIGNATURE- iQQcBAEBCgAGBQJX7FaVAAoJED+SGaZ/NsaL+C4gANbZ/XF6mdyBISlWmI42JSFH +XpZukHTBJvew1IiOVqVj8exMhHSHwkup7nNj9gGOVd8zq4EDLZm18Y0wM8ubksZ 5y3VDo7DweURJVyWDwUyla98DW4r1G44FUpksTRzzfO4bFx+QB+54vGWXY9HKNM6 dAicZJeTzuA0SwaA7vB8GZ9p7txwSaCztTWCixJus7ybvVSgOFXfmeXPDtvomno0 +c1JaHJrIrvpnbyR27eGc2RAyWpsPb7fbiPRX/5QDUDRRT10fLITmAzcK0uFb+7D e0maZ/ey9OSOnDK1wZu1Y57dy3649izvXl7v0q1wME26oXhN9Lb2kEPXYsQbNMzK 5CQOcx571ceKYY1dtdpKpcVSucnK9VAfFhcXVpdgTQSCNn5DSOIgas8RFn/knwxv SxnfpP4Zr1ofN/oHYEL+mesiMkolBFkHkqMJPwyDx7vO5nwWm3s3SGsPntuRt9sA /jnYvxfkFa1lDYxH+wJ+Lu3DoNnG3vYdxrxll90lgNPY4cPcusTWiTbc34u9Uwgu SsRfOUxxegBiJGxqNCTjGslllzXZIkaiWJaqygrAXcBQKfEVoTKn++KtTjg4VVhc GOPebgk25ocWhK5mCoKMGHZi2nWVBfmp4J7ntkcQcspcR1YvQMo5S9J8xahxz1Oa Yif0l7bjRCXA0/NyZoz075vHV87Bzk2GZSO1Y563JHcEm4DEB6slmwo86IrzGERm Ixj1HpLUM+IDhpGLeccRXMw+dgmZ+gMMF0wNaIjuFylZYf/2yPCtqa8pT1wHxkFO bll7EWW6248KnKZ+mFyzbPa2sgx9x+g5G+VMcnbRr1PA3y5Q/4oOKCNAZp1onZsz 1TjoFfqrQpmL+SJXowBq46WuOraGIxTsiDZ1C6fth8FUBW+858WEULqlYvoBf+p6 VlpgYLqkbcMK0KUZdkMxmCSw80+VqREZVGydK1bj2gDLQeaP2jxbUPoVKWoY9pXz cqkStNaZiUU2CBole8ODId18hm0yjnAooabbApN5cWNT6PAkVrsD1/PO+TnO/pH1 02aCBsK0SdGxieo5QwDmkUfc1mFsmHzTu2/QXRwIdn0CG3vUVyZZ8n9OWFLCiZGv MBYe38g5oCCzHhodKFwZ8eyxX9XwlJDmrhM4+Od+fpbS+dQSeAy5mqaPF4Z2IK8U ai1/FcuJ19seVoXtELl98ZDpFKkjzfz4OGK0GjA1sgzmsNPvI1qpipFG0rGj3y9e kT8swi1hYkFEDTXQQ3dBMSKbcQ4gy6+BqLi/j9pxdWTZ19WIJduOIDx9qDlVlrIG AYc3faUMrtGJxzVDVKKaNGiFsdYSakw6h5ATtqPDl4GVeCueVD0QrBD1p3h5RfA= =nnyd -END PGP SIGNATURE-
