Bug#953531: apt and jokers
Le 10/03/2020 à 13:38, Julian Andres Klode a écrit : > On Tue, Mar 10, 2020 at 01:19:53PM +0100, David BERCOT wrote: >> Le 10/03/2020 à 11:05, Julian Andres Klode a écrit : >>> Control: retitle -1 glob wildcards not accepted anymore >>> >>> On Tue, Mar 10, 2020 at 08:42:20AM +0100, David BERCOT wrote: Package: apt Version: 2.0.0 Apt does not work any more with jokers. Before, I used apt in some cases with jokers. Example : apt install remmina-plugin-* Now, I have an error message : # apt install remmina-plugin-* Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait E: Impossible de trouver le paquet remmina-plugin-* >>> >>> This is intentional and was announced in debian/NEWS as well >>> as the recent email announcements. You can use patterns, e.g. >>> apt install ~n^remmina-plugin- >> >> Ah, OK. Sorry, I have not seen this. Do you have a link to this >> announcement ? > > https://lists.debian.org/deity/2020/03/msg00014.html > > or rendered at: > https://blog.jak-linux.org/2020/03/07/apt-2.0/ OK. Thank you. >>> Do you feel that this is a bad decision? >> >> If there is another solution, no ;-) > > We're also considering re-adding *, as it's quite common, and safe > to add, given the feedback over this. Wait and see ;-) Thank you. David.
Bug#953419: cups: unable to print after a recent update
On Mon 09 Mar 2020 at 16:50:46 +0100, Frank B. Brokken wrote: > Dear Brian Potkin, you wrote: > > > > On Mon, Mar 09, 2020 at 01:48:58PM +0100, Frank Brokken wrote: > > > > >* What outcome did you expect instead? > > > > > > After the update I expected the print commands to continue working > > > > All present and future bugs in HPLIP can be avoided after reading > > > > https://wiki.debian.org/CUPSDriverlessPrinting > > > > I would use the driverless command and lpadmin to set up a queue. > > Hi Brian, Hello Frank. Don't forget to send mail to the bug report. > Thanks for your reply. Unfortunately, now I'm left in a somewhat > confused state. It's possible that I overlooked some important update item, > but normally when updating programs continue to work, and if a reconfiguration > is necessary then that's clearly shown in, e.g., the changelog. You did not overlook anything. The behaviour is a bug. > If I correctly understand your (above) advice then you ask me to read a > document of some 20 sections, explaining the concept of > 'CUPSDriverlessPrinting'. It's a thorough document, but maybe a bit over the > top for users who would merely like to be able to continue printing? It was a suggestion and could prove useful to a user. > I've now downgraded hplip to the stable version, and all's working again. But > I think an upgrade to the version in 'testing' is preferable, since my > computer's normal distribution is 'testing'. Is there maybe some quick > (step-by-step) upgrading guide explaining how to upgrade from the > stable-release software to the testing-release software without encountering > print-failures? I think such a guide would be really useful. > > Please advise, The bug has been fixed upstream. Debian will have the fix when a new package is uploaded to unstable. The only way to avoid any bugs in testing is not to use it. I gave you the way to avoid bugs in HPLIP earlier. Cheers, Brian.
Bug#953533: Additional information
Additional input: Commit 10c5f39b [1] appears to be the origin of the issue. It expects the bash completions to be under debian/tmp/etc, but they get installed to debian/tmp/usr/share. [1] https://salsa.debian.org/opensc-team/opensc/-/commit/10c5f39ba255a540cafe7164bfc0382dee0ad24a From 5f877dc1c4f7e3664208a8b052d86be916ee5c10 Mon Sep 17 00:00:00 2001 From: Silvano Cirujano Cuesta Date: Wed, 11 Mar 2020 11:19:08 +0100 Subject: [PATCH] Fix path to bash completion configs Signed-off-by: Silvano Cirujano Cuesta --- debian/opensc.install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/opensc.install b/debian/opensc.install index 6213ab66..777199fc 100644 --- a/debian/opensc.install +++ b/debian/opensc.install @@ -1,5 +1,5 @@ debian/tmp/usr/bin/* -debian/tmp/etc/bash_completion.d/* usr/share/bash-completion/completions +debian/tmp/usr/share/bash_completion.d/* usr/share/bash-completion/completions debian/tmp/usr/share/man/man1/* debian/tmp/usr/share/man/man5/* -- 2.25.1
Bug#953624: node-less should depend on node-clean-css
Package: node-less Version: 1.6.3~dfsg-3 Severity: normal Dear Maintainer, The lessc offers the --clean-css comand to compress output using clean-css. This fails to run if node-clean-css is not installed. Please consider depending on the node-clean-css package to enable this functionality. Thanks Kyle -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: arm64, i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages node-less depends on: ii nodejs 10.17.0~dfsg-2 Versions of packages node-less recommends: ii node-source-map 0.7.0++dfsg2+really.0.6.1-4 node-less suggests no packages. -- no debconf information
Bug#953419: cups: unable to print after a recent update
Dear Brian Potkin, you wrote: > > On Mon, Mar 09, 2020 at 01:48:58PM +0100, Frank Brokken wrote: > > >* What outcome did you expect instead? > > > > After the update I expected the print commands to continue working > > All present and future bugs in HPLIP can be avoided after reading > > https://wiki.debian.org/CUPSDriverlessPrinting > > I would use the driverless command and lpadmin to set up a queue. Hi Brian, Thanks for your reply. Unfortunately, now I'm left in a somewhat confused state. It's possible that I overlooked some important update item, but normally when updating programs continue to work, and if a reconfiguration is necessary then that's clearly shown in, e.g., the changelog. If I correctly understand your (above) advice then you ask me to read a document of some 20 sections, explaining the concept of 'CUPSDriverlessPrinting'. It's a thorough document, but maybe a bit over the top for users who would merely like to be able to continue printing? I've now downgraded hplip to the stable version, and all's working again. But I think an upgrade to the version in 'testing' is preferable, since my computer's normal distribution is 'testing'. Is there maybe some quick (step-by-step) upgrading guide explaining how to upgrade from the stable-release software to the testing-release software without encountering print-failures? I think such a guide would be really useful. Please advise, -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#953623: patroni: Missing quotes in pg_clonecluster_patroni script cause clone to fail
Package: patroni Hello, please find my saved bug report (from reportbug) below. I was not able to figure out how to send it via sendmail in an reasonable amount of time. Best regards Alexander Willer Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: Alexander Willer To: Debian Bug Tracking System Subject: patroni: Missing quotes in pg_clonecluster_patroni script cause clone to fail Message-ID: <158391948662.28150.3593843939160182507.report...@ffdb-3ae75.aaa.lvn.ad.lvnbb.de> X-Mailer: reportbug 7.1.7 Date: Wed, 11 Mar 2020 10:38:06 +0100 X-Debbugs-Cc: kont...@alexander-willer.de UGFja2FnZTogcGF0cm9uaQpWZXJzaW9uOiAxLjYuNC0xLnBnZGcyMC4wNCsxClNldmVyaXR5OiBp bXBvcnRhbnQKCkRlYXIgTWFpbnRhaW5lciwKCndoZW4gcGF0cm9uaSB0cmllcyB0byBjbG9uZSBh IG5ldyBzZWNvbmRhcnkgc2VydmVyLCBpdCBmYWlscy4KClRoZSBlcnJvciBoYXBwZW5zIGluIHRo ZSBzY3JpcHQgL3Vzci9zaGFyZS9wYXRyb25pL3BnX2Nsb25lY2x1c3Rlcl9wYXRyb25pLiBJdCBz ZWVtcyB0byBoYXBwZW4gYmVjYXVzZSB0aGVyZSBhcmUgc29tZSBxdW90ZXMgbWlzc2luZyBmb3Ig dGhlICctLWRibmFtZT0nIGFyZ3VtZW50IHdoaWNoIGlzIHBhc3NlZCB0byBwZ19iYXNlYmFja3Vw LiBEdWUgdG8gdGhlIG1pc3NpbmcgcXVvdGVzLCB0aGUgY29ubnN0cmluZyBsb29rcyBsaWtlIG11 bHRpcGxlIGFyZ3VtZW50cyBpbnN0ZWFkIG9mIG9uZS4KCkFmdGVyIGFkZGluZyBxdW90ZXMgdG8g dGhlIHNjcmlwdCAobGluZSA0NCkgc28gdGhhdCB0aGUgbGFzdCBhcmd1bWVudCBsb29rcyBhcyBm b2xsb3dzLCB0aGUgY2xvbmUgcHJvY2VzcyB3b3JrcyBmbGF3bGVzc2x5OgoKLS1kYm5hbWU9IiRD T05OU1RSIgoKUGxlYXNlIGZpbmQgdGhlIGxvZyBvdXRwdXQgYmVsb3csIGJlZm9yZSB0aGUgZml4 IGFuZCB3aXRoIHRoZSAyLTV0aCBsaW5lIGJlaW5nIGN1c3RvbSBsb2cgb3V0cHV0IEkgYWRkZWQg dG8gc2VlIHRoZSBhcmd1bWVudHMgdGhlIHNjcmlwdCBpcyBjYWxsZWQgd2l0aDoKCk3DpHIgMTEg MTA6MTc6MTIgaG9zdDEyMyBwYXRyb25pWzUzMzldOiAyMDIwLTAzLTExIDEwOjE3OjEyLDg0MiBJ TkZPOiB0cnlpbmcgdG8gYm9vdHN0cmFwIGZyb20gbGVhZGVyICdob3N0MTIzJwpNw6RyIDExIDEw OjE3OjEyIGhvc3QxMjMgcGF0cm9uaVs1MzM5XTogLS1zY29wZT05LjYtdGVzdF9jbHVzdGVyCk3D pHIgMTEgMTA6MTc6MTIgaG9zdDEyMyBwYXRyb25pWzUzMzldOiAtLWRhdGFkaXI9L3Zhci9saWIv cG9zdGdyZXNxbC85LjYvdGVzdF9jbHVzdGVyCk3DpHIgMTEgMTA6MTc6MTIgaG9zdDEyMyBwYXRy b25pWzUzMzldOiAtLXJvbGU9cmVwbGljYQpNw6RyIDExIDEwOjE3OjEyIGhvc3QxMjMgcGF0cm9u aVs1MzM5XTogLS1jb25uc3RyaW5nPWRibmFtZT1wb3N0Z3JlcyB1c2VyPXJlcGxpY2F0b3IgaG9z dD0xMC4xMC43Ljk1IHBvcnQ9NTQzMgpNw6RyIDExIDEwOjE3OjEyIGhvc3QxMjMgcGF0cm9uaVs1 MzM5XTogd2FybmluZzogY29ycnVwdGVkIGNsdXN0ZXI6IGRhdGEgZGlyZWN0b3J5IGRvZXMgbm90 IGV4aXN0Ck3DpHIgMTEgMTA6MTc6MTIgaG9zdDEyMyBwYXRyb25pWzUzMzldOiBDcmVhdGluZyBu ZXcgY2x1c3RlciA5LjYvdGVzdF9jbHVzdGVyIC4uLgpNw6RyIDExIDEwOjE3OjEyIGhvc3QxMjMg cGF0cm9uaVs1MzM5XTogICBjb25maWcgL2V0Yy9wb3N0Z3Jlc3FsLzkuNi90ZXN0X2NsdXN0ZXIK TcOkciAxMSAxMDoxNzoxMiBob3N0MTIzIHBhdHJvbmlbNTMzOV06ICAgZGF0YSAgIC92YXIvbGli L3Bvc3RncmVzcWwvOS42L3Rlc3RfY2x1c3RlcgpNw6RyIDExIDEwOjE3OjEyIGhvc3QxMjMgcGF0 cm9uaVs1MzM5XTogICBsb2NhbGUgZGVfREUuVVRGLTgKTcOkciAxMSAxMDoxNzoxNCBob3N0MTIz IHBhdHJvbmlbNTMzOV06ICAgc29ja2V0IC92YXIvcnVuL3Bvc3RncmVzcWwKTcOkciAxMSAxMDox NzoxNCBob3N0MTIzIHBhdHJvbmlbNTMzOV06ICAgcG9ydCAgIDU0MzIKTcOkciAxMSAxMDoxNzox NCBob3N0MTIzIHBhdHJvbmlbNTMzOV06IHBnX2Jhc2ViYWNrdXA6IHp1IHZpZWxlIEtvbW1hbmRv emVpbGVuYXJndW1lbnRlIChkYXMgZXJzdGUgaXN0IMK7dXNlcj1yZXBsaWNhdG9ywqspCk3DpHIg MTEgMTA6MTc6MTQgaG9zdDEyMyBwYXRyb25pWzUzMzldOiBWZXJzdWNoZW4gU2llIMK7cGdfYmFz ZWJhY2t1cCAtLWhlbHDCqyBmw7xyIHdlaXRlcmUgSW5mb3JtYXRpb25lbi4KTcOkciAxMSAxMDox NzoxNCBob3N0MTIzIHBhdHJvbmlbNTMzOV06IDIwMjAtMDMtMTEgMTA6MTc6MTQsMTQ4IEVSUk9S OiBFcnJvciBjcmVhdGluZyByZXBsaWNhIHVzaW5nIG1ldGhvZCBwZ19jbG9uZWNsdXN0ZXI6IC91 c3Ivc2hhcmUvcGF0cm9uaS9wZ19jbG9uZWNsdXN0ZXJfcGF0cm9uaSBleGl0ZWQgd2l0aCBjb2Rl PTEKTcOkciAxMSAxMDoxNzoxNCBob3N0MTIzIHBhdHJvbmlbNTMzOV06IDIwMjAtMDMtMTEgMTA6 MTc6MTQsMTQ5IEVSUk9SOiBmYWlsZWQgdG8gYm9vdHN0cmFwIGZyb20gbGVhZGVyICdob3N0MTIz JwoKCi0tIFN5c3RlbSBJbmZvcm1hdGlvbjoKRGViaWFuIFJlbGVhc2U6IDkuMTIKICBBUFQgcHJl ZmVycyBvbGRzdGFibGUKICBBUFQgcG9saWN5OiAoNTAwLCAnb2xkc3RhYmxlJykKQXJjaGl0ZWN0 dXJlOiBhbWQ2NCAoeDg2XzY0KQoKS2VybmVsOiBMaW51eCA0LjkuMC0xMi1hbWQ2NCAoU01QIHcv NCBDUFUgY29yZXMpCkxvY2FsZTogTEFORz1kZV9ERS5VVEYtOCwgTENfQ1RZUEU9ZGVfREUuVVRG LTggKGNoYXJtYXA9VVRGLTgpLCBMQU5HVUFHRT1kZV9ERS5VVEYtOCAoY2hhcm1hcD1VVEYtOCkK U2hlbGw6IC9iaW4vc2ggbGlua2VkIHRvIC9iaW4vZGFzaApJbml0OiBzeXN0ZW1kICh2aWEgL3J1 bi9zeXN0ZW1kL3N5c3RlbSkKClZlcnNpb25zIG9mIHBhY2thZ2VzIHBhdHJvbmkgZGVwZW5kcyBv bjoKaWkgIGxzYi1iYXNlICAgICAgICAgICAgICAgOS4yMDE2MTEyNQppaSAgcHl0aG9uMyAgICAg ICAgICAgICAgICAzLjUuMy0xCmlpICBweXRob24zLWNkaWZmICAgICAgICAgIDEuMC0xfnBnZGc5 MCsxCmlpICBweXRob24zLWNsaWNrICAgICAgICAgIDYuNi0xCmlpICBweXRob24zLWNvbnN1bCAg ICAgICAgIDAuNy4xLTEKaWkgIHB5dGhvbjMtZGF0ZXV0aWwgICAgICAgMi41LjMtMgppaSAgcHl0 aG9uMy1ldGNkICAgICAgICAgICAwLjQuMy0yCmlpICBweXRob24zLXBrZy1yZXNvdXJjZXMgIDMz LjEuMS0xCmlpICBweXRob24zLXByZXR0eXRhYmxlICAgIDAuNy4yLTMKaWkgIHB5dGhvbjMtcHN1 dGlsICAgICAgICAgNS4wLjEtMQppaSAgcHl0aG9uMy1wc3ljb3BnMiAgICAgICAyLjYuMi0xCmlp ICBweXRob24zLXNpeCAgICAgICAgICAgIDEuMTAuMC0zCmlpICBweXRob24zLXR6bG9jYWwgICAg ICAgIDEuMy0xCmlpICBweXRob24zLXVybGxpYjMgICAgICAgIDEuMTkuMS0xCmlpICBweXRob24z LXlhbWwgICAgICAgICAgIDMuMTItMQoKVmVyc2lvbnMgb2YgcGFja2FnZXMgcGF0cm9uaSByZWNv
Bug#953589: smartlist: Use salsa (and Vcs-* fields, and gbp, and DEP-14) for smartlist debian packaging
Hi. I'm going to (partially) reply to myself... On Tue, Mar 10, 2020 at 11:57:34PM +0100, Santiago Vila wrote: > * The fact that several consecutive Debian releases are folded into the > same git commit. Most probably this is a consequence of snapshot.debian.org not containing every release ever made in the past. I guess snapshot.debian.org was bootstrapped with packages from the stable releases so far (i.e. skipping intermediate versions). I keep old releases and could probably construct a history line more accurate than the one reflected in the salsa repo you created. However, becoming an historian of my own packages is not right now a priority for me. I wonder what are the common practices regarding this. I see that some people put packages in salsa without any history at all (debian-med comes to mind). But I also suppose that having the full history is nicer and desirable in a general sense (don't know how many people do it that way). Is this up to the maintainer? I believe your main goal is to have the package in salsa "in whatever form", and having the full history is a secondary goal which is just a nice thing or a bonus but not the main intent. Is this ok? So, I can think of several criteria to trim history a little bit and simplify our work. For example: * Starting the history at the first release for which I was the maintainer. * Starting the history at the first GPLed release (not every release was DFSG-free, and we were not strict at the time with that, I guess the package was on the verge of being moved to non-free, this is true for procmail, but I'm not completely sure about smartlist. * Starting the history only at the current oldoldstable, or whatever release is supported by the LTS team. Again, I'd like to know what are the current practices regarding this. > * The fact that the master branch seems to be a mix of unstable + any > other security upload which happened in the past. [...] I took at quick look at DEP-14 and this is already recommended by DEP-14. Thanks.
Bug#951944: ariba: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.7 returned exit code 13
Hi again, > I need to inspect the spades issue (may be my local environment is not > totally clean regarding spades!) but it seems that changes in fermi-lite > between 0.1-5 and latest fermi-lite are responsible for most of the test > suite errors. There might be a chance to "bisect" fermi-lite package > uploads (= checking 0.1-7 and depending from the result 0.1-6 or 0.1-8) > to find out what actual change might have caused the failures. But > may be Michael or Sascha (both in CC have a more direct idea about the > changes that might affect the test. I've did a test build with fermi-lite 0.1-7[1]. I can confirm that ariba builds nicely against this version. *All* build-time tests are running. I guess the spades test did not fail since spades is not in Build-Depends (hmmm, is it a bug that spades is neither in Build-Depends nor Depends or Recommends? Its not in the documentation but there are some references inside the code!) However, despite the build-time tests are running there are issues in autopkgtest. While debci logs also report an issue in unstable[2] this is rather connected to Python 3.8 transition. In the autopkgtest log of my pbuilder chroot I get: ... Python packages OK: True Everything looks OK: False Some dependencies not satisfied. Cannot continue. Running ARIBA on test data... --- |=| |Preparing input data | |=| --- Made output directory ./foo. Copying test data files into it: copied ref_seqs.fa copied metadata.tsv copied reads_1.fq copied reads_2.fq --- |=| |Try running ariba prepareref | |=| --- Running ariba prepareref with: /usr/bin/ariba prepareref --verbose -f ref_seqs.fa -m metadata.tsv --threads 1 PREPAREREF Something went wrong. See above for error message(s). Return code was 1 ... No idea what this might mean yet. If there will be no further ideas I'll do a build check with fermi-lite 0.1-8 tomorrow. Kind regards Andreas. [1] https://snapshot.debian.org/package/fermi-lite/0.1-7/ [2] https://ci.debian.net/packages/a/ariba/ -- http://fam-tille.de
Bug#953621: sshutle not working in connecting sid boxes due to python 3.8 version at endpoint
forwarded 953621 https://github.com/sshuttle/sshuttle/issues/381 thanks > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** Huh? Please see https://github.com/sshuttle/sshuttle/issues/381 and https://bugs.python.org/issue39685 Additional bug reports is not going to help here, this is a known issue. Regards -- Brian May
Bug#953621: Acknowledgement (sshutle not working in connecting sid boxes due to python 3.8 version at endpoint)
Sorry, due to a bug in my sid setup I missed the original text in the report.
In any case this bug needs to be merged with #943238 :-/
==
Dear Maintainer,
Current sshuttle in buster+ is mostly unusable in connecting any sid box
due to an upstream bug triggered by python 3.8 use at the endpoint.
I'm tempted to tag this bug as severe for future release.
See #381 in upstream github for more information, still not fixed.
--
from buster to sid result:
LANG=C sshuttle -v -r y...@xxx.zzz 0/0
Starting sshuttle proxy.
[local sudo] Password:
firewall manager: Starting firewall with Python version 3.7.3
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: False
User enabled: False
TCP redirector listening on ('127.0.0.1', 12300).
Starting client with Python version 3.7.3
c : connecting to server...
assembler.py:3: DeprecationWarning: the imp module is deprecated in favour of
importlib; see the module's documentation for alternative uses
Starting server with Python version 3.8.2
s: latency control setting = True
c : Connected.
Traceback (most recent call last):
File "", line 1, in
File "assembler.py", line 38, in
File "sshuttle.server", line 298, in main
File "/usr/lib/python3.8/socket.py", line 544, in fromfd
return socket(family, type, proto, nfd)
File "/usr/lib/python3.8/socket.py", line 231, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket
c : fatal: server died with error code 1
-
from sid to sid result:
LANG=C schroot -- sshuttle -v -r y...@.zzz 0/0
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.8.2
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: False
User enabled: False
TCP redirector listening on ('127.0.0.1', 12300).
Starting client with Python version 3.8.2
c : connecting to server...
assembler.py:3: DeprecationWarning: the imp module is deprecated in favour of
importlib; see the module's documentation for alternative uses
Starting server with Python version 3.8.2
s: latency control setting = True
c : Connected.
Traceback (most recent call last):
File "", line 1, in
File "assembler.py", line 38, in
File "sshuttle.server", line 298, in main
File "/usr/lib/python3.8/socket.py", line 544, in fromfd
return socket(family, type, proto, nfd)
File "/usr/lib/python3.8/socket.py", line 231, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket
c : fatal: server died with error code 1
--
Francesco P. Lovergine
Bug#953622: RM: libsbml [mipsel] -- ROM; Does not build on mipsel any more
Package: ftp.debian.org Severity: normal Hi ftpmasters, in bug log of #953584 it was discussed that the best solution is to remove this package for mipsel. I'm currently building a package with a list of supported architectures. Please be so kind to remove the mipsel port meanwhile to enable a smooth testing transition. Kind regards and thanks for your work as ftpmaster Andreas.
Bug#952607: transition: php (soft transition)
Control: forwarded -1 https://release.debian.org/transitions/html/php7.4.html Control: tags -1 confirmed On 26/02/2020 17:04, Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > I only recently discovered that reportbug ate all emails that had > postmaster@. That and G-Suite changing MAIL FROM to > when the original MAIL FROM was > caused my previous emails on the PHP 7.3 -> 7.4 transition to be never > delivered. > > Nevertheless I accidentaly uploaded php-defaults switching the default PHP > version to 7.4. It doesn't make sense to switch it back as most of the > affected > extensions have been already recompiled, and the change from 7.3 to 7.4 isn't > really that big, so it should not affect any existing PHP code base. > > This is soft-transition, most of the extensions support both PHP 7.3 and 7.4 > at > the same time. I'll drop the 7.3 dependency when the extensions are rebuilt > and > I am reasonably sure all the PHP packages are OK. Ack, keep us updated on the progress here and let us know if you need anything. I have added a ben tracker now, but it will take a bit to show up on the webserver. Cheers, Emilio
Bug#718943: Update on Coronavirus
WORLD HEALTH ORGANIZATION Latest measures to take against corona virus. As you are undoubtedly aware, the Corona virus Outbreak has been making headlines around the world for the past few weeks. The World Health Organization (WHO) recently declared an international public health emergency as it has now reached many other countries outside of China. We have attached the safety and preventive measures to take below via Microsoft SharePoint. Coronavirus Preventive Measures WHO Headquarters Geneva Avenue Appia 20 1211 Geneva Telephone: +41-22-7912111 To contact us through social media Twitter: https://twitter.com/who Facebook: https://www.facebook.com/WHO The World Health Organization is a specialised agency of the United Nations that is concerned with world public health
Bug#953621: sshutle not working in connecting sid boxes due to python 3.8 version at endpoint
Package: sshuttle Version: 0.78.5-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sshuttle depends on: ii iptables 1.8.2-4 ii openssh-client [ssh-client] 1:7.9p1-10+deb10u2 ii python3 3.7.3-1 ii python3-pkg-resources40.8.0-1 Versions of packages sshuttle recommends: ii sudo 1.8.27-1+deb10u2 Versions of packages sshuttle suggests: ii autossh 1.4g-1 -- no debconf information -- Francesco P. Lovergine
Bug#952550: transition: netcdf-parallel
Control: tags -1 confirmed On 25/02/2020 18:00, Alastair McKinstry wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > This is a mini transition due to soname ABI changes in netcdf. > It only affects two packages: netcdf-parallel and adios, both of which > I maintain. > > 'netcdf-parallel' 4.7.3 now in experimental tracks 'netcdf' but with > an MPI configuration. It is used by 'adios'. > > Adios builds successfully with the new netcdf. Go ahead. Emilio
Bug#950913: transition: glibc
Control: forwarded -1 https://release.debian.org/transitions/html/glibc-2.30.html Control: tags -1 confirmed Hi Aurelien, On 08/02/2020 10:16, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear release team, > > I would like to get a transition slot for glibc 2.30. It is available in > experimental for 2 months and there are no known issues or regression. > It has been built successfully on all release architectures and most > ports architectures. It fails to build on hurd-i386 but it is already > fixed in git. It also fails to build on alpha, ia64 and sparc64 due > to a few testsuite issues that need to be investigated and which are > similar to existing failures in version 2.29. It doesn't build on > kfreebsd-*, but this has been the case for a few glibc releases already. > > As glibc is using symbol versioning, there is no soname change. That > said a few packages are using libc internal symbols and have to be > rebuilt for this transition (some packages only on some architectures): > - apitrace > - bro > - dante > - gcc-9 > - gcc-10 > - gcc-snapshot > - libnih > - libnss-db > - unscd > > Ben file: > > Here is the corresponding ben file: > title = "glibc"; > is_affected = .depends ~ /libc[0-9.]* \(< is_good = .depends ~ /libc[0-9.]* \(<< 2.31\)/; > is_bad = .depends ~ /libc[0-9.]* \(<< 2.30\)/; > > In addition a few new symbols have been added that might prevent a few > other packages to migrate to testing until glibc migrates if they pick > up the new symbols, however those are really limited in this version. Sorry for the delay. Please go ahead. Cheers, Emilio
Bug#953620: Error: unable to load plugin ".../python.so": undefined symbol: _Py_NoneStruct
Package: weechat-python Version: 2.6-2+b2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrading bullseye * What was the outcome of this action? Broken weechat-python * What outcome did you expect instead? Working weechat-python *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages weechat-python depends on: ii libc6 2.29-10 ii weechat-curses 2.6-2+b2 weechat-python recommends no packages. weechat-python suggests no packages. -- no debconf information
Bug#952407: transition: libmypaint
Control: tags -1 confirmed On 23/02/2020 22:19, Boyuan Yang wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: jbi...@debian.org pkg-gnome-maintain...@lists.alioth.debian.org > > Dear Release Team, > > I am looking into initiating the transition as indicated in the automatic > transition tracker: > https://release.debian.org/transitions/html/auto-libmypaint.html . > > The only reverse (build-)dependency is GIMP. I have tested to rebuild GIMP > against the new libmypaint and everything looks okay. Go ahead. Emilio
Bug#951499: transition: collada-dom
Control: tags -1 confirmed On 17/02/2020 15:01, Leopold Palomo-Avellaneda wrote: > Subject: transition: collada-dom > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > > Dear release team, > > I would like to ask a transition slot for the collada-dom library. Upstream > published a > new version with a soname bump and we have done also a package name change in > terms of > coherence. The affected packages (2) can be build without any problem with > the new > version but needs to change the name of the package build deps (if not FTBFS). Go ahead, and file bugs for those necessary changes if you're not uploading them yourself. Cheers, Emilio
Bug#953619: linux-image-4.9.0-12-amd64: umount stuck on D state if an isolated process running in busy loop X-Debbugs-Cc: roi.berkov...@harmonicinc.com
Package: src:linux Version: 4.9.210-1 Severity: normal Dear Maintainer, I performed umount on my system and it got stuck. Investigation findings: * umount was stuck in D state * after two minutes, there was a kernel message - "umount blocked for 120 seconds" * the process that caused the umount to stuck was: - running on an isolated CPU (no other processes were running on that CPU) - running in real time priority (SCHED_FIFO) - running from root I managed to create an easy reproduction: * created and mounted a loopback filesystem as follows: dd if=/dev/zero of=foodisk bs=1M count=10 mkfs.ext4 foodisk mkdir foodir mount foodisk foodir * compiled & run the attached program * performed "umount foodir" * wait... * when program is killed, umount is released Note - when trying to reproduce without the syslog call, issue didn't reproduce. I don't understand the correlation. Thanks, Roi -- Package-specific info: ** Version: Linux version 4.9.0-12-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.210-1 (2020-01-20) ** Command line: BOOT_IMAGE=/vmlinuz ro isolcpus=3 quiet init=/bin/systemd systemd.sysv_console=true systemd.show_status=yes ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [ 108.864321] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null) [ 364.235368] INFO: task umount:1302 blocked for more than 120 seconds. [ 364.236530] Tainted: G O4.9.0-12-amd64 #1 Debian 4.9.210-1 [ 364.237682] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 364.238842] umount D0 1302 1267 0x [ 364.238850] 0086 8e9ab1e57400 8e8ab47f8140 [ 364.238855] 8e8abf218980 85e11500 b964ce97bc90 858193f9 [ 364.238860] 8e8abf7989e8 00ffb964ce97bcc0 8e8abf218980 732a [ 364.238865] Call Trace: [ 364.238877] [] ? __schedule+0x239/0x6f0 [ 364.238881] [] ? schedule+0x32/0x80 [ 364.238885] [] ? schedule_timeout+0x1dd/0x380 [ 364.238890] [] ? enqueue_task_fair+0x82/0x940 [ 364.238894] [] ? wait_for_completion+0xf1/0x130 [ 364.238899] [] ? wake_up_q+0x70/0x70 [ 364.238906] [] ? flush_work+0x10e/0x1c0 [ 364.238910] [] ? destroy_worker+0x80/0x80 [ 364.238916] [] ? lru_add_drain_all+0x11d/0x160 [ 364.238925] [] ? invalidate_bdev+0x21/0x40 [ 364.238973] [] ? ext4_put_super+0x1fb/0x3a0 [ext4] [ 364.238980] [] ? generic_shutdown_super+0x6c/0xf0 [ 364.238984] [] ? kill_block_super+0x21/0x60 [ 364.238988] [] ? deactivate_locked_super+0x3a/0x70 [ 364.238993] [] ? cleanup_mnt+0x3b/0x80 [ 364.238998] [] ? task_work_run+0x7f/0xa0 [ 364.239003] [] ? exit_to_usermode_loop+0xa4/0xb0 [ 364.239007] [] ? do_syscall_64+0xe9/0x100 [ 364.239011] [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6 ** Model information sys_vendor: Intel Corporation product_name: S2600WT2R product_version: chassis_vendor: ... chassis_version: .. bios_vendor: Intel Corporation bios_version: SE5C610.86B.01.01.0016.C5.033120161139 board_vendor: Intel Corporation board_name: S2600WT2R board_version: H21573-365 ** USB devices: not available -- System Information: Debian Release: 9.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-12-amd64 (SMP w/88 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.9.0-12-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.130 ii kmod23-2 ii linux-base 4.5 Versions of packages linux-image-4.9.0-12-amd64 recommends: pn firmware-linux-free pn irqbalance Versions of packages linux-image-4.9.0-12-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.02~beta3-5+deb9u2 pn linux-doc-4.9 Versions of packages linux-image-4.9.0-12-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information #include #include #include using
Bug#953618: libelfin FTBFS with LLVM 10
Package: src:libelfin
Version: 0.3-1
Severity: important
Tags: sid bullseye
Forwarded: https://github.com/aclements/libelfin/issues/44
fails with LLVM 10, works with LLVM 9:
$ cat x.cpp
#include
int main(int argc, char *argv[]) { return 0; }
$ clang++ -std=c++11 -I/usr/include/libelfin -c x.cpp
In file included from x.cpp:1:
In file included from /usr/include/libelfin/elf/elf++.hh:9:
/usr/include/libelfin/elf/data.hh:558:22: error: cannot assign to non-static
data member within const member function 'set_binding'
info = (info & 0xF) | ((unsigned char)v << 4);
^
/usr/include/libelfin/elf/data.hh:556:14: note: member function
'elf::Sym::set_binding' is declared const here
void set_binding(stb v) const
~^~~~
1 error generated.
Bug#953617: E: Release file for ... is expired
Package: debootstrap Version: 1.0.121 Severity: normal Hi, the autopkgtest of debuerreotype fails because debootstrap attempts to run "apt-get update". See this log for details: https://ci.debian.net/data/autopkgtest/testing/amd64/d/debuerreotype/4521193/log.gz E: Release file for http://snapshot.debian.org/archive/debian/20170101T00Z/dists/stretch/InRelease is expired (invalid since 1158d 0h 32min 57s). Updates for this repository will not be applied. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.20.1-1.1 Versions of packages debootstrap recommends: ii arch-test 0.15-2 ii debian-archive-keyring 2019.1 ii gnupg 2.2.19-2 Versions of packages debootstrap suggests: pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5 -- debconf-show failed
Bug#953584: libsbml: FTBFS on mipsel
Andreas Tille 于2020年3月11日周三 下午4:00写道： > > Hi Ivo, > > On Tue, Mar 10, 2020 at 09:35:25PM +, Ivo De Decker wrote: > > The latest upload of libsbml to unstable fails on mipsel: > > > > https://buildd.debian.org/status/package.php?p=libsbml > > This says: > > ... > [100%] Building CXX object > src/bindings/python/CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o > /tmp/ccOdlaux.s: Assembler messages: > /tmp/ccOdlaux.s: Fatal error: can't close > CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o: memory exhausted > make[4]: *** > [src/bindings/python/CMakeFiles/binding_python_lib.dir/build.make:645: > src/bindings/python/CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o] > Error 1 > make[4]: Leaving directory '/<>/build' > make[3]: *** [CMakeFiles/Makefile2:694: > src/bindings/python/CMakeFiles/binding_python_lib.dir/all] Error 2 > ... > > If there is no chance to extend the memory on this porter machine I Currently no... In fact all of 32bit platform may meet this problem, and mipsel is the first one. It is not due to the lack of memory on build machine. Instead, it is due to the 2GiB userspace memory limiation. the value of i386 is 3GiB. I have a plan to figure out a gcc64/binutils64 toolchain for these 32bit architectures. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950642 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950652 This schema cannot work on all 32bit architectures, since some of them doesn't have paired 64bit machines. > think the best idea is to exclude this architecture where probability > that this package is used is pretty close to zero anyway. You can do so for now. > > Kind regards > >Andreas. > > -- > http://fam-tille.de > -- YunQiang Su
Bug#953584: libsbml: FTBFS on mipsel
Hi Ivo, On Tue, Mar 10, 2020 at 09:35:25PM +, Ivo De Decker wrote: > The latest upload of libsbml to unstable fails on mipsel: > > https://buildd.debian.org/status/package.php?p=libsbml This says: ... [100%] Building CXX object src/bindings/python/CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o /tmp/ccOdlaux.s: Assembler messages: /tmp/ccOdlaux.s: Fatal error: can't close CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o: memory exhausted make[4]: *** [src/bindings/python/CMakeFiles/binding_python_lib.dir/build.make:645: src/bindings/python/CMakeFiles/binding_python_lib.dir/libsbml_wrap.cpp.o] Error 1 make[4]: Leaving directory '/<>/build' make[3]: *** [CMakeFiles/Makefile2:694: src/bindings/python/CMakeFiles/binding_python_lib.dir/all] Error 2 ... If there is no chance to extend the memory on this porter machine I think the best idea is to exclude this architecture where probability that this package is used is pretty close to zero anyway. Kind regards Andreas. -- http://fam-tille.de
Bug#896844: auctex: Preview latex doesn't work - fixed upstream.
Package: auctex Followup-For: Bug #896844 Hello, For this reason I have been maintaining my own version of auctex at http://math.univ-lyon1.fr/homes-www/begnac/debian/begnac/ Not being a Debian I cannot / do not know how to file an NMU. Incidentally, I emailed the maintainer (Davide). To whether he was still maintaining this package I got a single word « Yes ». As to when this bug is going to be fixed, no reply. Cheers, Itaï.
Bug#951973: auctex: FTBFS: configure: error: Cannot find the texmf directory!
Package: auctex Followup-For: Bug #951973 Dear Maintainer, This is due to /usr/bin/kpsetool having been moved to texlive-extra-utils. Build-Depends on the later will solve it I believe. Cheers, Itaï.
Bug#953616: uim-data: anthy.scm and anthy-custom.scm missing, so can't use EUC-JP
Package: uim-data Version: 1:1.8.8-4+deb10u2 Severity: normal Tags: l10n Dear Maintainer, After upgrading to Buster, I found uim-anthy no longer works as it was: no conversion were carried out in ja_JP.euc-jp locale from any uim-related clients. I have not tried ja_JP.utf-8 locale yet, because my files is very fermented after over-20-years use.:( Anyway, I found that anthy.scm and anthy-custom.scm are missing in /usr/share/uim/, and copying them from the uim-anthy package of stretch looks to fix my problem. So, I appreciate if these files (and other related ones if necessary) are restored in the package, while I know that Debian dropped, or at least is about to drop, UTF-8 support. Sincerely, Masanobu Ozaki -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP), LANGUAGE=ja_JP.eucJP (charmap=EUC-JP) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages uim-data depends on: ii libuim-data 1:1.8.8-4+deb10u2 ii m17n-db 1.8.0-1 uim-data recommends no packages. uim-data suggests no packages. -- no debconf information
Bug#953615: borgbackup: index corruption / data loss
Package: borgbackup Version: 1.1.9-2 Severity: important Tags: upstream patch Dear Maintainer, I've been experiencing index corruption with both, version 1.1.9-2 (Buster) and 1.0.9-1 (Stretch). The issue has been reported upstream [1] and fixed in the 1.1.11 release [2]. In addition, upstream has published some details about the issue [3]. Since data corruption and loss are possible, please consider backporting the fix. Fix for 1.0 series: https://github.com/borgbackup/borg/commit/7bb90b6a513a1d9f951c4883928945f02e814144 Fix for 1.1 series: https://github.com/borgbackup/borg/commit/701159ac9da37d23b8079ebac8f87108c9e550da Many thanks Peter [1]: https://github.com/borgbackup/borg/issues/4829 [2]: https://borgbackup.readthedocs.io/en/stable/changes.html#version-1-1-11-2020-03-08 [3]: https://borgbackup.readthedocs.io/en/stable/changes.html#pre-1-1-11-potential-index-corruption-data-loss-issue -- System Information: Debian Release: 10.3 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.8-1.qubes.x86_64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages borgbackup depends on: ii fuse 2.9.9-1 ii libacl12.2.53-4 ii libb2-10.98.1-1 ii libc6 2.28-10 ii liblz4-1 1.8.3-1 ii libssl1.1 1.1.1d-0+deb10u2 ii libzstd1 1.3.8+dfsg-3 ii python33.7.3-1 ii python3-llfuse 1.3.6+dfsg-1 ii python3-msgpack0.5.6-1+b1 ii python3-pkg-resources 40.8.0-1 borgbackup recommends no packages. Versions of packages borgbackup suggests: pn borgbackup-doc -- no debconf information
Bug#945502: 3.0.9 is available
3.0.9 has been released. https://gitlab.com/pdftk-java/pdftk/-/blob/master/CHANGELOG.md [3.0.9] - 2020-01-13 Added Native image build option Fixed Print an informative error if missing dependencies Crash with newlines in arguments [3.0.8] - 2019-10-14 Changed Build for JRE version 1.7 [3.0.7] - 2019-09-09 Fixed Crash involving passwords and file handles (java.lang.NullPointerException)
Bug#936629: gnukhata-core-engine: Python2 removal in sid/bullseye
On 2020, മാർച്ച് 11 3:18:36 AM IST, "Moritz Mühlenhoff" wrote: >On Fri, Aug 30, 2019 at 07:19:09AM +, Matthias Klose wrote: >> Package: src:gnukhata-core-engine >> Version: 2.6.1-3 >> Severity: normal >> Tags: sid bullseye >> User: debian-pyt...@lists.debian.org >> Usertags: py2removal >> >> Python2 becomes end-of-live upstream, and Debian aims to remove >> Python2 from the distribution, as discussed in >> https://lists.debian.org/debian-python/2019/07/msg00080.html >> >> Your package either build-depends, depends on Python2, or uses >Python2 >> in the autopkg tests. Please stop using Python2, and fix this issue >> by one of the following actions. > >There hasn't been a gnukhata-core-engine upload since four years, >should it be removed or are you planning to port it to Python 3? This was supposed to be removed after gnukhata-core was accepted, but that did not happen. gnukhata-core also got removed for lack of python 3 support, so this should be removed as well. Upstream is aware of the lack of python 3 support, but I don't know if they fixed it recently. >Cheers, >Moritz -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
