Bug#1078511: RFP: spoofdpi -- simple and fast anti-censorship tool
Package: wnpp Severity: wishlist * Package name: spoofdpi Version : 0.10.6 Upstream Author : xvzc * URL or Web page : https://github.com/xvzc/SpoofDPI * License : Apache-2.0 Programming lang: Go Description : simple and fast anti-censorship tool A simple and fast anti-censorship tool. It sets up a local proxy to circumvent censorship by bypassing DPI (Deep Packet Inspection).
Bug#1077351: (no subject)
Control: tags 1077351 = moreinfo unreproducible Hi, I tried to reproduce this locally in clean sbuild (unstable) environment with no luck. Let's see what Debian CI will show. Regards, Lev
Bug#1075839: swi-prolog-doc: file missing since Debian 10.x ("buster"): /usr/share/doc/swi-prolog-doc/Manual/index.html
Hi Alan, Сб 13 июл 2024 @ 16:58 "Alan D. Salewski" : > On 2024-07-12 21:46:06, Lev Lamberov spake thus: > [...] >>Thanks for your report. >> >>Unifortunately, I have no idea why you faced the bug you reported. > > Hi Lev, > > Thanks for looking into it. I've done a little bit more digging and > am able to reproduce it. The problem seems to be in the doc-base > triggers when upgrading from swi-prolog-doc 5.6.59-2 to > 8.2.4+dfsq-1. Thanks for your input. > So uninstalling and then re-installing 'swi-prolog-doc' is a > workaround. Hmmm... Probably adding Conflicts and/or Breaks to d/control against earlier versions of swi-prolog-doc is still required. The swi-prolog-doc package previously was built from a separate source package, and previously newer swi-prolog-doc had these fields in d/control. But I don't think that Debian supports such a huge upgrade jumps through several stable releases at once. My guess is that the correct way is to upgrade to each stable release in between swi-prolog-doc 5.6.59-2 and 8.2.4+dfsg-1. Cheers! Lev
Bug#1075839: swi-prolog-doc: file missing since Debian 10.x ("buster"): /usr/share/doc/swi-prolog-doc/Manual/index.html
Control: tags + unreproducible
Dear Alan,
Thanks for your report.
Unifortunately, I have no idea why you faced the bug you reported.
These two directories /usr/share/doc/swi-prolog-doc/{Manual,packages} is
in fact a symlink to ../../swi-prolog/doc/{Manual,packages}. If you
download, say, swi-prolog-doc_8.2.4+dfsg-1_all.deb and navigate through
it with the help of, say, mc, you'll see that everything is in the
correct place and symlinks are properly created. I'd like to stress that
apt-file doesn't show symlinks properly and so reports
/usr/share/swi-prolog/doc/Manual as an empty directory. My guess is that
you faced a kind of race condition while updating doc-base or improper
work of dpkg/apt/whatever installs packages on your machine.
Regards,
Lev Lamberov
Bug#1068673: (no subject)
Hi, I can confirm this. It looks like what is reported at [this] Reddit thread. I guess there is a library version mismatch or some dependencies are not declared properly. [this] https://www.reddit.com/r/OpenShot/comments/1buvrho/exported_video_has_audio_no_video/ Regards, Lev
Bug#1073044: RM: nose-el -- ROM; obsolete, depends on python3-nose which is going to be removed
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: nose...@packages.debian.org Control: affects -1 + src:nose-el User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please, remove nose-el from unstable. It is obsolete and depends on python3-nose which is going to be removed soon (see, #1071179). Regards, Lev Lamberov
Bug#1070036: proofgeneral: Error loading 50proofgeneral: Invalid read syntax: ")", 19, 29
Package: proofgeneral Version: 4.5-1 Severity: normal X-Debbugs-Cc: none, Lev Lamberov Dear Maintainer, When starting GNU Emacs I'm getting the following error message (as extracted from *Messages* buffer): Loading /etc/emacs/site-start.d/50proofgeneral.el (source)... Loading /usr/share/emacs/site-lisp/proofgeneral/generic/proof-site.el (source)...done Error while loading 50proofgeneral: Invalid read syntax: ")", 19, 29 Regards, Lev -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages proofgeneral depends on: ii emacs 1:29.2+1-2 ii emacs-gtk [emacs] 1:29.2+1-2 proofgeneral recommends no packages. Versions of packages proofgeneral suggests: ii proofgeneral-doc 4.5-1 ii prooftree 0.13-3 -- no debconf information
Bug#1069135: org-bullets: please consider switching to a more up-to-date upstream
Hi, Сб 27 апр 2024 @ 16:34 Aymeric Agon-Rambosson : > If you are looking for replacements for org-bullets, there is also > org-modern (https://github.com/minad/org-modern), from Daniel > Mendler. > > I've been using it happily for quite some time now. > > Generally, Daniel Mendler's projects are very well implemented and > maintained. I maintain 4 or 5 of his projects in Debian and I have > very little work. > > Le mercredi 17 avril 2024 à 13:02, Léon Lamberov > a écrit : > >> Hi Nicholas, >> >> Вт 16 апр 2024 @ 18:13 Nicholas D Steeves : >> >>> Source: org-bullets >>> Version: 0.2.4-3 >>> Severity: normal >> >>> I noticed some deprecation warnings in org-bullets' >>> native-compilation log, so searched for an upstream fix. What >>> I found was that our current upstream source is a decade old: >>> >>> https://github.com/sabof/org-bullets >>> >>> and that MELPA provides their users with a package from this >>> fork, which has activity from four years ago: >>> >>> https://github.com/integral-dw/org-bullets >>> >>> It looks like integral-dw's fork might now the defacto >>> upstream, because sabof's project looks dead. Maybe a PR/MR >>> for some of those compilation warnings could be a useful way to >>> test for a living and responsive upstream? >> >> Thanks for your investigation! >> >> As I can see, org-super-star-mode (also from integral-dw) has >> more >> features than org-bullets and better support (last commit was in >> Jan >> 2023). So, I guess, we could update org-bullets to integral-dw's >> version >> and also package org-super-star-mode, and then, probably, >> deprecate >> org-bullets in favor of org-super-star-mode. What do you think >> of the >> proposal? >> >> [super-star] https://github.com/integral-dw/org-superstar-mode I've just uploaded integral-dw's clone of org-bullets. But I'm not going to close the bug, since we probably still need to migrate to some alternative. Thanks to Nicolas and Agon-Rambosson : > If you are looking for replacements for org-bullets, there is also > org-modern (https://github.com/minad/org-modern), from Daniel > Mendler. > > I've been using it happily for quite some time now. > > Generally, Daniel Mendler's projects are very well implemented and > maintained. I maintain 4 or 5 of his projects in Debian and I have > very little work. > > Le mercredi 17 avril 2024 à 13:02, Léon Lamberov > a écrit : > >> Hi Nicholas, >> >> Вт 16 апр 2024 @ 18:13 Nicholas D Steeves : >> >>> Source: org-bullets >>> Version: 0.2.4-3 >>> Severity: normal >> >>> I noticed some deprecation warnings in org-bullets' >>> native-compilation log, so searched for an upstream fix. What >>> I found was that our current upstream source is a decade old: >>> >>> https://github.com/sabof/org-bullets >>> >>> and that MELPA provides their users with a package from this >>> fork, which has activity from four years ago: >>> >>> https://github.com/integral-dw/org-bullets >>> >>> It looks like integral-dw's fork might now the defacto >>> upstream, because sabof's project looks dead. Maybe a PR/MR >>> for some of those compilation warnings could be a useful way to >>> test for a living and responsive upstream? >> >> Thanks for your investigation! >> >> As I can see, org-super-star-mode (also from integral-dw) has >> more >> features than org-bullets and better support (last commit was in >> Jan >> 2023). So, I guess, we could update org-bullets to integral-dw's >> version >> and also package org-super-star-mode, and then, probably, >> deprecate >> org-bullets in favor of org-super-star-mode. What do you think >> of the >> proposal? >> >> [super-star] https://github.com/integral-dw/org-superstar-mode I've just uploaded integral-dw's clone of org-bullets. But I'm not going to close the bug, since we probably still need to migrate to some alternative. Thanks to Nicolas and Agon-Rambosson : > If you are looking for replacements for org-bullets, there is also > org-modern (https://github.com/minad/org-modern), from Daniel > Mendler. > > I've been using it happily for quite some time now. > > Generally, Daniel Mendler's projects are very well implemented and > maintained. I maintain 4 or 5 of his projects in Debian and I have > very little work. > > Le mercredi 17 avril 2024 à 13:02, Léon Lamberov > a écrit : > >> Hi Nicholas, >> >> Вт 16 апр 2024 @ 18:13 Nicholas D Steeves : >> >>> Source: org-bullets >>> Version: 0.2.4-3 >>> Severity: normal >> >>> I noticed some deprecation warnings in org-bullets' >>> native-compilation log, so searched for an upstream fix. What >>> I found was that our current upstream source is a decade old: >>> >>> https://github.com/sabof/org-bullets >>> >>> and that MELPA provides their users with a package from this >>> fork, which has activity from four years ago: >>> >>> https://github.com/integral-dw/org-bullets >>> >>> It looks like integral-dw's fork might now the defacto >>> upstream, because sabof's project looks d
Bug#1059417: ed: diff for NMU version 1.20.1-1.1
Hi, Сб 27 апр 2024 @ 22:35 Chris Hofstaedtler : > Lev, > > * Sven Joachim [240427 19:48]: >> On 2024-04-17 14:26 +0200, Chris Hofstaedtler wrote: >> > I've prepared an NMU for ed (versioned as 1.20.1-1.1) and >> > uploaded it to DELAYED/7. Please feel free to tell me if I >> > should delay it longer. >> >> Seems your NMU was ignored and reverted in the latest upload. :-( > > I'm guessing you didn't see the bug-mail / NMU so far? Are you going > to upload the patch yourself? Ahhh... Right, I missed the bug report somehow. I'll apply the patch to the latest version and upload it. Regards, Lev
Bug#1069135: org-bullets: please consider switching to a more up-to-date upstream
Hi Nicholas, Вт 16 апр 2024 @ 18:13 Nicholas D Steeves : > Source: org-bullets > Version: 0.2.4-3 > Severity: normal > I noticed some deprecation warnings in org-bullets' native-compilation log, > so searched for an upstream fix. What I found was that our current upstream > source is a decade old: > > https://github.com/sabof/org-bullets > > and that MELPA provides their users with a package from this fork, which has > activity from four years ago: > > https://github.com/integral-dw/org-bullets > > It looks like integral-dw's fork might now the defacto upstream, because > sabof's project looks dead. Maybe a PR/MR for some of those compilation > warnings could be a useful way to test for a living and responsive upstream? Thanks for your investigation! As I can see, org-super-star-mode (also from integral-dw) has more features than org-bullets and better support (last commit was in Jan 2023). So, I guess, we could update org-bullets to integral-dw's version and also package org-super-star-mode, and then, probably, deprecate org-bullets in favor of org-super-star-mode. What do you think of the proposal? [super-star] https://github.com/integral-dw/org-superstar-mode Cheers! Lev
Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated
Hi, Вс 14 янв 2024 @ 04:34 gregor herrmann : > On Sat, 13 Jan 2024 22:04:20 +, Jeremy Sowden wrote: > >> > This package fails its autopkgtest checks with Perl 5.38 >> > (currently in unstable.) > >> I've pushed a fix to Salsa: >> >> https://salsa.debian.org/emacsen-team/dh-make-elpa/-/commit/b6840bdc3b2a02ca07a2a601deff2a3947001368 Cool! Thanks! > Great! (And congratulations on finding out what this smartmatch > operation was supposed to do, which I didn't manage :)) > > In case you have troubles finding someone from the team to upload, > please shout, I'm happy to help. I've just looked into the bug report and commited changes, and uploaded the updated package. Cheers! Lev
Bug#1058522: (no subject)
Hi Jeremy, Сб 30 дек 2023 @ 11:28 Jeremy Sowden : > On 2023-12-24, at 10:00:26 +0500, Lev Lamberov wrote: >> Чт 21 дек 2023 @ 15:06 Jeremy Sowden: >> > On 2023-12-21, at 11:21:48 +, Jeremy Sowden wrote: >> >> On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote: >> >> > Since I cannot reproduce the bug, I'm downgrading the severity of >> >> > this bug report. >> >> >> >> I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and >> >> reproduced it (log attached). I'll see if I can work out what's going >> >> on. >> >> Thanks for your input. I double checked this bug report both under >> git-pbuilder and sbuild. E. g., here is the sbuild environment: >> >> $ sudo sbuild-shell unstable >> I: /bin/sh >> # bash >> (unstable-amd64-sbuild)root@shakva:/# du --version >> du (GNU coreutils) 9.4 >> Copyright (C) 2023 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> <https://gnu.org/licenses/gpl.html>. >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> >> Written by Torbjörn Granlund, David MacKenzie, Paul Eggert, >> and Jim Meyering. >> (unstable-amd64-sbuild)root@shakva:/# exit >> >> But I still cannot reproduce the bug. Don't know... > > First things first, do you see the following in your chroot? > > (unstable-amd64-sbuild)root@ulthar:~# d=$(mktemp -d) > (unstable-amd64-sbuild)root@ulthar:~# du -sb $d > 0 /tmp/tmp.qay80HZ09w > > This is the cause of the problem. If your du is not reporting zero size > for an empty directory, that would explain the discrepancy and the rest > of this e-mail is irrelevant. :) It is zero for me. I was able to reproduce the bug in a clean schroot environment. Will figure out what to do next in the coming days. Happy New Year! Cheers! Lev
Bug#1058522: (no subject)
Hi Jeremy, Чт 21 дек 2023 @ 15:06 Jeremy Sowden : > On 2023-12-21, at 11:21:48 +, Jeremy Sowden wrote: >> On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote: >> > Since I cannot reproduce the bug, I'm downgrading the severity of >> > this bug report. >> >> I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and >> reproduced it (log attached). I'll see if I can work out what's going >> on. Thanks for your input. I double checked this bug report both under git-pbuilder and sbuild. E. g., here is the sbuild environment: $ sudo sbuild-shell unstable I: /bin/sh # bash (unstable-amd64-sbuild)root@shakva:/# du --version du (GNU coreutils) 9.4 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Torbjörn Granlund, David MacKenzie, Paul Eggert, and Jim Meyering. (unstable-amd64-sbuild)root@shakva:/# exit But I still cannot reproduce the bug. Don't know... Best, Lev
Bug#1058522: (no subject)
Hi, Since I cannot reproduce the bug, I'm downgrading the severity of this bug report. Cheers! Lev
Bug#1058522: (no subject)
Hi, Hmmm... strange. I cannot reproduce this. I tried to (1) run tests locally with dh_elpa_test, (2) run tests locally as autopkgtest supposed to with dh_elpa_test --autopkgtest, (3) run tests during build from scratch under sbuild, (4) run tests with autopkgtest under sbuild. Tests were successful everywhere. Guess, it is a false positive, but will keep the bug report open for some time. Cheers! Lev
Bug#1052580: swi-prolog: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Hi Vladimir, Пн 20 ноя 2023 @ 09:09 Vladimir Petko : > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > > Best Regards, > Vladimir. > > [1] https://salsa.debian.org/debian/swi-prolog/-/merge_requests/3 In fact, this was fixed upstream (but the fix is still not entered swipl stable repository) by bumping Java compatibily to 8. Please, see this [commit]. I'll look into it soon. [commit] https://github.com/SWI-Prolog/packages-jpl/commit/c05e51bae51511fa6d69b9b6cca25bbaad4ee084 Cheers! Lev
Bug#1019202: dh-make-elpa: crashes with: Can't locate object method "gecos"
Hi Richard, Чт 19 окт 2023 @ 22:42 Richard Lewis : > On Mon, 16 Oct 2023 at 09:00, Lev Lamberov wrote: >> Вс 15 окт 2023 @ 19:37 Richard Lewis : >> > On Mon, 05 Sep 2022 19:44:27 -0300 David Bremner >> > wrote: >> >> Lev Lamberov writes: > >> > I also see this bug in bookwork: dh-make-elpa doesnt work at all >> > unless DEBFULLNAME (and maybe DEBEMAIL) is set. > >> > I could send a patch to mention these variables in the man-page > >> That would be great. > > It turned out that i could do even better! > > Have fixed the whole bug, and improved the detection of both name and > email address. > I've also added some tests, and refreshed the lintian overrides and > standards-version > > MR is here > https://salsa.debian.org/emacsen-team/dh-make-elpa/-/merge_requests/3 Cool! Thanks! I'll take a look into your MR in the coming days. Cheers! Lev
Bug#1019202: dh-make-elpa: crashes with: Can't locate object method "gecos"
Hi Richard, Вс 15 окт 2023 @ 19:37 Richard Lewis : > On Mon, 05 Sep 2022 19:44:27 -0300 David Bremner wrote: >> Lev Lamberov writes: > >> >> yes I did cd (just did again to double check). I don't have DEBFULLNAME >> set, maybe that makes a difference. > > I also see this bug in bookwork: dh-make-elpa doesnt work at all > unless DEBFULLNAME (and maybe DEBEMAIL) is set. Without that you get > > Can't locate object method "gecos" via package "$USER" (perhaps you > forgot to load "$USER"?) at > /usr/share/perl5/DhMakeELPA/Command/Packaging.pm line 127. > > (I ran without the --pkg-emacsen argument) > > I could send a patch to mention these variables in the man-page since > they seem to be obeyed, and useful for the user to know about, even if > the underlying bug is fixed That would be great. Cheers! Lev
Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid
Пт 15 сен 2023 @ 14:25 David Bremner : > Lev Lamberov writes: > >>> elpa-hl-todo has a versioned depends which is wrong. >> >> It is not wrong. It is as it is stated in the code, and as it is >> detected by dh-elpa. >> >> Personally, I don't see any problem here. The hl-todo-el package is just >> waiting for the latest upstream version of complat-el. There's no hurry >> to make its way into testing right now. From my point of view there is >> only a wishlist bug requesting the latest upstream version of compat-el >> to be uploaded into unstable. > > Yeah, I see what you mean, but the versioned depends is unsatisfiable in > unstable, so it doesn't make sense to upload the package to unstable, > unless there is something weird like a circular dependency. > > I don't think it's OK for packages in unstable to be uninstallable in > unstable. It certainly meets the textbook definition of a release > critical bug, since nobody can actually use the package. Unstable is... well, unstable. Sometimes things break there. ¯\_(ツ)_/¯ There's no point in removing either compat-el or hl-todo-el from testing because of this. Regards, Lev
Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid
Hi, Пт 15 сен 2023 @ 11:24 David Bremner : > Control: severity -1 important > > David Bremner writes: > >> Andreas Beckmann writes: >> >>> Package: compat-el >>> Version: 29.1.4.1-2 >>> Severity: serious >>> >>> elpa-hl-todo/sid is currently uninstallable since it depends on >>> elpa-compat (>= 29.1.4.2). >>> >>> >>> Andreas >> >> Maybe it doesn't matter, but I don't think this is a serious bug in >> compat.el. It's not like a it's a regression. It's a serious bug in the >> package which is uninstallable. > > Addendum: it does matter, there are a bunch of rdepends and unless they > all don't work with current elpa-compat, then it is needlessly > disruptive to auto-remove elpa-compat (or even to mark it for > auto-removal). > > elpa-hl-todo has a versioned depends which is wrong. It is not wrong. It is as it is stated in the code, and as it is detected by dh-elpa. Personally, I don't see any problem here. The hl-todo-el package is just waiting for the latest upstream version of complat-el. There's no hurry to make its way into testing right now. From my point of view there is only a wishlist bug requesting the latest upstream version of compat-el to be uploaded into unstable. Regards, Lev
Bug#1051748: RFP: pdf2htmlex -- convert PDF to HTML without losing text or format
Hi, Вт 12 сен 2023 @ 13:01 Johannes Schauer Marin Rodrigues : > Hi, > > On Tue, 12 Sep 2023 10:57:57 +0500 Lev Lamberov wrote: >> Package: wnpp >> Severity: wishlist >> >> * Package name: pdf2htmlex >> Version : 0.18.8rc1 >> Upstream Author : Lu Wang and other contributors >> * URL or Web page : https://github.com/pdf2htmlEX/pdf2htmlEX >> * License : GPL-3+ >> Description : convert PDF to HTML without losing text or format >> > > you are aware that pdf2htmlex used to be part of Debian? It is still in > old-old-stable. It was removed with this bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921471 > > Are you sure it is wise to include that package into Debian again? The issue > tracker is very low on activity: > > https://github.com/pdf2htmlEX/pdf2htmlEX/issues > > Thanks! Well, the upstream is indeed not very active (the latest commit is on 13 Mar this year). I admit that it looks more like an abandonware, but probably someone™ could step forward and care for it (I personally lack the relevant competence). Recently I had to convert LaTeX source (XeTeX, in fact) to HTML and in fact the best result I got was with LaTeX->PDF->HTML, where the last convertion was done with this pdf2htmlex. It produced HTML document which looks exactly like PDF produced by LaTeX. So, I thought that this tool can be of use to someone else. Cheers! Lev
Bug#1051748: RFP: pdf2htmlex -- convert PDF to HTML without losing text or format
Package: wnpp Severity: wishlist * Package name: pdf2htmlex Version : 0.18.8rc1 Upstream Author : Lu Wang and other contributors * URL or Web page : https://github.com/pdf2htmlEX/pdf2htmlEX * License : GPL-3+ Description : convert PDF to HTML without losing text or format pdf2htmlEX renders PDF files in HTML, utilizing modern Web technologies. It aims to provide an accurate rendering, while being optimized for Web display. Text, fonts and formats are natively preserved in HTML. Mathematical formulas, figures and images are also supported. pdf2htmlEX is also a publishing tool: almost 50 options make it flexible for many different use cases: PDF preview, book/magazine publishing, personal resume, etc. pdf2htmlEX is optimized for modern web browsers such as Mozilla Firefox & Google Chrome.
Bug#994171: 0.2.8+git20220410.81c5a42-1: unable to set up jediepcserver, permission denied
Control: retitle -1 unable to set up jediepcserver, permission denied Hi, I've uploaded 0.2.8+git20220410.81c5a42-1, which contains all upstream changes. Now emacs-jedi is compatible with jedi in Debian (the API was updated to jedi 0.18). Unfortunately, there's another problem, now due to permissions. Namely, as follows: Running: pip install --upgrade /usr/share/emacs/site-lisp/elpa/jedi-core-0.3.0/...Done deferred error : (error "Deferred process exited abnormally: command: /home/dogsleg/.emacs.d/.python-environments/default/bin/pip exit status: exit 1 event: exited abnormally with code 1 buffer contents: \"Processing /usr/share/emacs/site-lisp/elpa/jedi-core-0.3.0 Preparing metadata (setup.py) ... [?25l- done [?25hCollecting argparse (from jediepcserver==0.3.0) Using cached argparse-1.4.0-py2.py3-none-any.whl (23 kB) Requirement already satisfied: epc>=0.0.4 in /usr/lib/python3/dist-packages (from jediepcserver==0.3.0) (0.0.5) Requirement already satisfied: jedi>=0.11.0 in /usr/lib/python3/dist-packages (from jediepcserver==0.3.0) (0.18.2) Requirement already satisfied: setuptools in ./.emacs.d/.python-environments/default/lib/python3.11/site-packages (from jediepcserver==0.3.0) (68.0.0) Building wheels for collected packages: jediepcserver Building wheel for jediepcserver (setup.py) ... [?25l- error error: subprocess-exited-with-error × python setup.py bdist_wheel did not run successfully. │ exit code: 1 ╰─> [5 lines of output] running bdist_wheel running build running build_py creating build error: could not create 'build': Permission denied [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. ERROR: Failed building wheel for jediepcserver [?25h Running setup.py clean for jediepcserver Failed to build jediepcserver ERROR: Could not build wheels for jediepcserver, which is required to install pyproject.toml-based projects \"") Looks like it tries to set up the Python environment in some system's drectory, not in user's HOME. Currently, I don't have time to invest into this, patches are welcome. The severity is still grave, because the package is not usable, but I'm retitling the bug report (instead of closing and submitting a new one) to reflect this new problem. Regards, Lev
Bug#1042902: system-packages-el and #1042902
Hi, As reported in #1042902 system-packages-el in some configurations sets its system-packages-package-manager variable to a wrong value. The upstream documentation says that The package attempts to guess which package manager you use. If it guesses wrong (or you'd like to set it manually), you may modify the variable =system-packages-package-manager=. Typically one uses apt/apt-get in Debian, so I think it is justified to set the variable to apt by default. I can imagine someone who uses other package managers in Debian, but guess these users are not our primary target audience so to say. What the team thinks about the issue? Should the variable be set to apt by default in Debian? If yes, where would you suggest to set it? Regards, Lev
Bug#1033942: nmu: ppl_1:1.2-8.1
Hi Paul, Чт 06 апр 2023 @ 12:05 Paul Gevers : > On 05-04-2023 07:38, Lev Lamberov wrote: >> Вт 04 апр 2023 @ 21:42 Paul Gevers : >>> On 04-04-2023 15:05, Lev Lamberov wrote: >>>> Please, rebuild ppl against swi-prolog 9.0.4+dfsg-2 in unstable. The >>>> ppl package in unstable and testing was build against the older >>>> swi-prolog version, containing older library. For more information, >>>> please see this swi-prolog [bug]. >>>> >>>> [bug] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033636 >>> >>> It's a shame we discussed this in bug 1022253 [1]. Do you know what was >>> flawed in our assessment? >>> >>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022253#24 >> >> Yes, turns out I was wrong. > > I've scheduled the binNMU's, but as discussed in bug 1033636, please fix > this properly after the bookworm release. Following standard workflows > prevents this particular problem. Thank you! Regards, Lev
Bug#1033942: nmu: ppl_1:1.2-8.1
Hi Paul, Вт 04 апр 2023 @ 21:42 Paul Gevers : > Control: tags -1 moreinfo > > Hi Lev, > > On 04-04-2023 15:05, Lev Lamberov wrote: >> Please, rebuild ppl against swi-prolog 9.0.4+dfsg-2 in unstable. The >> ppl package in unstable and testing was build against the older >> swi-prolog version, containing older library. For more information, >> please see this swi-prolog [bug]. >> >> [bug] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033636 > > It's a shame we discussed this in bug 1022253 [1]. Do you know what was > flawed in our assessment? > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022253#24 Yes, turns out I was wrong. Regards, Lev
Bug#1033942: nmu: ppl_1:1.2-8.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:ppl Hi, Please, rebuild ppl against swi-prolog 9.0.4+dfsg-2 in unstable. The ppl package in unstable and testing was build against the older swi-prolog version, containing older library. For more information, please see this swi-prolog [bug]. [bug] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033636 The command is as follows: nmu ppl_1:1.2-8.1 . ANY . unstable . -m "Rebuild against swi-prolog 9.0.4+dfsg-2" With regards, Lev Lamberov
Bug#1033636: swi-prolog ships shared libraries, breaks partial upgrades
Hi Steve, Ср 29 мар 2023 @ 00:49 Steve Langasek : > Source: swi-prolog > Version: 9.0.4+dfsg-1 > Severity: serious > > The swi-prolog core package ships a shared library, libswipl.so. The soname > of this library has changed between stable and testing, from libswipl.so.8 > to libswipl.so.9. > > While swi-prolog-core declares many "ABI" virtual packages, it doesn't > declare one saying what the soname is, which is the most standard way of > expressing dependencies in Debian packages. > > As a result, logol-bin in stable has dependencies on: > > swi-prolog-core (>= 8.4.2+dfsg), swi-prolog, swi-prolog-abi-binary-68 > > And these dependencies are satisfied by the swi-prolog-core in testing BUT > installing the swi-prolog-core from testing with the logol-bin from stable > is broken. > > This was correctly detected by the ci.debian.net infrastructure back in > December (though the logs from those runs have now been discarded). > https://ci.debian.net/packages/l/logol/testing/amd64/ > > swi-prolog should: > - make sure there is a real or virtual package libswipl9 > - make sure there is a shlibs or symbols file pointing to libswipl9, so that > packages which have an ELF dependency on this library also have that > expressed as a package dependency > - declare a Breaks: on logol-bin (<< 1.7.9+dfsg-6) so that older versions > which depend on a different SONAME aren't broken by partial upgrades. > > logol should then be rebuilt to pick up a dependency on libswipl9. Thanks for reporting! I've tagged this bug report with 'help'. I'm a bit overwhelmed at the moment and don't think I will have time for it or any other Debian stuff in the coming weeks. NMU is most welcome. Regards, Lev Lamberov
Bug#700467: Fix for UTF-8 problem
Hi, Looks like there is a fix here [utf-8]. It would be great if someone™ could apply the patch to the package in the Debian archive. [utf-8] https://ikiwiki.info/bugs/po:_buggy_UTF-8_support_with_po4a_0.58+/ Regards, Lev Lamberov
Bug#1030114: picom: new upstream release
Package: picom Version: 9.1-1 Severity: wishlist X-Debbugs-Cc: none, Lev Lamberov Dear Maintainer, Upstream published several new releases since 9.1. Namely, (as of today) 10, 10.1, and 10.2. Please, consider updating the package. Regards, Lev -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages picom depends on: ii libc62.36-8 ii libconfig9 1.5-0.4 ii libdbus-1-3 1.14.4-1 ii libev4 1:4.33-1 ii libgl1 1.6.0-1 ii libpcre3 2:8.39-15 ii libpixman-1-00.42.2-1 ii libx11-6 2:1.8.3-3 ii libx11-xcb1 2:1.8.3-3 ii libxcb-composite01.15-1 ii libxcb-damage0 1.15-1 ii libxcb-glx0 1.15-1 ii libxcb-image00.4.0-2 ii libxcb-present0 1.15-1 ii libxcb-randr01.15-1 ii libxcb-render-util0 0.3.9-1+b1 ii libxcb-render0 1.15-1 ii libxcb-shape01.15-1 ii libxcb-sync1 1.15-1 ii libxcb-xfixes0 1.15-1 ii libxcb-xinerama0 1.15-1 ii libxcb1 1.15-1 ii python3 3.11.1-2 picom recommends no packages. picom suggests no packages. -- no debconf information
Bug#1029750: python3-upstream-ontologist: should depend on python3-ruamel.yaml and python3-breezy
Package: python3-upstream-ontologist
Version: 0.1.30-2
Severity: important
Tags: newcomer
Dear Maintainer,
I decided to give upstream-ontologist a try and installed it on my
machine for testing. It was a fresh install. But on the first run I
got the following:
$ guess-upstream-metadata
Traceback (most recent call last):
File "/usr/bin/guess-upstream-metadata", line 33, in
sys.exit(load_entry_point('upstream-ontologist==0.1.30', 'console_scripts',
'guess-upstream-metadata')())
File "/usr/lib/python3/dist-packages/upstream_ontologist/__main__.py", line
37, in main
import ruamel.yaml
ModuleNotFoundError: No module named 'ruamel'
And then after manually installing python3-ruamel.yaml I've got the
following:
$ guess-upstream-metadata
Traceback (most recent call last):
File "/usr/bin/guess-upstream-metadata", line 33, in
sys.exit(load_entry_point('upstream-ontologist==0.1.30', 'console_scripts',
'guess-upstream-metadata')())
File "/usr/lib/python3/dist-packages/upstream_ontologist/__main__.py", line
104, in main
metadata = guess_upstream_metadata(
File "/usr/lib/python3/dist-packages/upstream_ontologist/guess.py", line
2337, in guess_upstream_metadata
return summarize_upstream_metadata(
File "/usr/lib/python3/dist-packages/upstream_ontologist/guess.py", line
2315, in summarize_upstream_metadata
fix_upstream_metadata(upstream_metadata)
File "/usr/lib/python3/dist-packages/upstream_ontologist/guess.py", line
3580, in fix_upstream_metadata
url = sanitize_vcs_url(url)
File "/usr/lib/python3/dist-packages/upstream_ontologist/vcs.py", line 528,
in sanitize_url
url = sanitizer(url)
File "/usr/lib/python3/dist-packages/upstream_ontologist/vcs.py", line 328,
in fixup_rcp_style_git_repo_url
from breezy.location import rcp_location_to_url
ModuleNotFoundError: No module named 'breezy'
So, I manually installed python3-breezy and now it works as expected.
Cheers!
Lev
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-upstream-ontologist depends on:
ii python33.10.6-3+b1
ii python3-debian 0.1.49
ii python3-debmutate 0.63
Versions of packages python3-upstream-ontologist recommends:
ii perl-doc 5.36.0-7
ii python3-bs4 4.11.1-3
ii python3-distro-info 1.3
ii python3-docutils 0.19+dfsg-6
ii python3-dulwich 0.21.2-1
ii python3-lxml 4.9.2-1
ii python3-markdown 3.4.1-2
ii python3-setuptools 65.6.3-1
ii python3-toml 0.10.2-1
ii python3-tomlkit 0.11.6-1
Versions of packages python3-upstream-ontologist suggests:
pn python3-breezy
pn python3-ruamel.yaml
-- no debconf information
Bug#1027132: git-doc: Error in `/usr/share/doc-base/git-doc.git-index-format', line 9: all `Format' sections are invalid
Package: git-doc Version: 1:2.39.0-1 Severity: minor Tags: newcomer Dear Maintainer, While upgrading git-doc from 1:2.35.1-1 to 1:2.39.0-1 I got the following error message: Processing 13 changed doc-base files... Error in `/usr/share/doc-base/git-doc.git-index-format', line 9: all `Format' sections are invalid. Note: `install-docs --verbose --check file_name' may give more details about the above error. Cheers! Lev Lamberov -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled git-doc depends on no packages. git-doc recommends no packages. Versions of packages git-doc suggests: ii git1:2.39.0-1 pn git-cvs pn git-email pn git-svn ii gitk 1:2.39.0-1 pn gitweb -- no debconf information
Bug#1026794: nmu: logol_1.7.9+dfsg-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: lo...@packages.debian.org Control: affects -1 + src:logol nmu logol_1.7.9+dfsg-6 . ANY . unstable . -m "Rebuild against swi-prolog 9.0.3+dfsg-1" Hi, Please, binNMU logol 1.7.9+dfsg-6 (currently in unstable) against swi-prolog 9.0.3+dfsg-1 (currently in unstable) to fix autopkgtests failures and make transition to testing possible. Thanks! Cheers! Lev
Bug#1026056: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1026056: fixed in logol 1.7.9+dfsg-6)
Hi Paul, Чт 15 дек 2022 @ 21:10 Paul Gevers : > On 14-12-2022 10:15, Debian Bug Tracking System wrote: >> * rebuild against new swi-prolog (Closes: #1026056) > > I can't but feel a bit uneasy by this "solution". Apparently it's not > properly tracked by dependencies, so it doesn't show up on the Release > Teams auto transition trackers [1] (which would typically trigger the > Release Team to trigger binNMU's, but if nothing else at least would put > it on the radar). For C based libraries this "solution" typically hides > real problems. Do we believe we can improve the logol/swi-prolog > situation in a similar way, or is the effort really not worth it > (apparently autopkgtest catches the issue, but the solution isn't > visible from the failure). > [1] https://release.debian.org/transitions/ Thanks for your attention! Yes, I should have initiated transition. Guess, I will do this in the future. There are not so much packages depending on swi-prolog, just logol and eye. Only these packages require rebuilding with a major upgrade of swi-prolog. Anyway, transitions are preferable way, I agree. Cheers! Lev
Bug#1025336: (no subject)
Hi Manuel, Thanks for your patch! I've just added it to the repository and will upload the next revision with your changes soon. Cheers! Lev
Bug#1023890: nmu: logol_1.7.9+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu logol_1.7.9+dfsg-5 . s390x . unstable . -m "Rebuild against swi-prolog 8.4.3+dfsg-2" Hi, Please, trigger binNUM for logol (in unstable) on s390x. It is needed to fix #1022253 due to changes in swi-prolog handling of endianness. Regards, Lev Lamberov
Bug#1021912: (no subject)
Contorol: reopen -1 Hi, Thanks for your work on the broadcom-sta package! Looks like the last upload of it (on 2022-10-23) was not full enough (it misses build on all) and so currently is not in unstable despite it was accepted. Since it is non-free it, as I understand, its upload should include build for all architecture. I reopen the bug, since it is not in fact fixed in any Debian branch. Its migration to unstable is blocked, see [issues] at the Debian Package Tracker. [issues] https://tracker.debian.org/pkg/broadcom-sta Regards, Lev
Bug#1022253: swi-prolog breaks logol autopkgtest on s390x
Hi Paul, Вс 23 окт 2022 @ 10:10 Paul Gevers : > Hi Lev, > > On 23-10-2022 09:40, Lev Lamberov wrote: >> I'm not sure it is the solution, it needs testing. The change in >> swi-prolog concerns pre-compiled prolog source code, when there is no >> pre-complied prolog code rebuilt is not needed. SWI-Prolog supports >> three different kinds of pre-compilation, at least one of them was >> affected and another was not. The mentioned endiannes bug can be found >> in BTS, #1006818 [bts]. > > I just ran the autopkgtest with a rebuild logol on s390x, see below. > Does that help? > > @logol maintainers, those ERRORs look scary if the test passes with it. > Is that just noise, or are real problems ignored? Given the answer from Étienne looks like it *is* the solution. Thanks for your work on it! Cheers! Lev
Bug#1022253: swi-prolog breaks logol autopkgtest on s390x
Вс 23 окт 2022 @ 09:16 Paul Gevers : > Hi Lev, > > On 23-10-2022 09:08, Lev Lamberov wrote: >> Сб 22 окт 2022 @ 21:27 Paul Gevers : >>> With a recent upload of swi-prolog the autopkgtest of logol fails in >>> testing when that autopkgtest is run with the binary packages of >>> swi-prolog from unstable. It passes when run with only packages from >>> testing. In tabular form: >> >> I've tried to build the logol package against swi-prolog in unstable on >> s390x porterbox and it was successful. I'm not sure whether it runs the >> same tests as during the autopkgtest testing. Unfortunately, I cannot >> test these rebuilt logol packages on s390x at the moment. The last >> change in the swi-prolog package was related to a bug concerning broken >> handling of endiannes (the bug was seen on s390x indeed, but not on >> other architectures). Now swi-prolog should correctly handle it. >> Probably, logol needs to be rebuilt against this new swi-prolog. > > If rebuilding is "the" solution, the change in swi-prolog feels like an > ABI breakage (on big endian architectures), right? If that's true, what > about the other reverse build dependencies of swi-prolog? Should all of > them be rebuild? ... Hmm, we're only talking about ppl in addition to > logol here. I'm not sure it is the solution, it needs testing. The change in swi-prolog concerns pre-compiled prolog source code, when there is no pre-complied prolog code rebuilt is not needed. SWI-Prolog supports three different kinds of pre-compilation, at least one of them was affected and another was not. The mentioned endiannes bug can be found in BTS, #1006818 [bts]. As I can see, ppl provides pretty simple prolog-interface to libppl, and it does not rely to pre-compiled prolog code. [bts] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006818 Cheers! Lev
Bug#1022253: swi-prolog breaks logol autopkgtest on s390x
Hi, Сб 22 окт 2022 @ 21:27 Paul Gevers : > With a recent upload of swi-prolog the autopkgtest of logol fails in > testing when that autopkgtest is run with the binary packages of > swi-prolog from unstable. It passes when run with only packages from > testing. In tabular form: I've tried to build the logol package against swi-prolog in unstable on s390x porterbox and it was successful. I'm not sure whether it runs the same tests as during the autopkgtest testing. Unfortunately, I cannot test these rebuilt logol packages on s390x at the moment. The last change in the swi-prolog package was related to a bug concerning broken handling of endiannes (the bug was seen on s390x indeed, but not on other architectures). Now swi-prolog should correctly handle it. Probably, logol needs to be rebuilt against this new swi-prolog. Cheers! Lev
Bug#1020193: (no subject)
This bug is fixed in the upstream repository, but the fix requires a.el, which is in NEW at the moment. I'll upload fix for pcre2el when a-el gets accepted. Regards, Lev
Bug#1021731: ITP: a-el -- functions for dealing with associative structures
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: a-el Version : 1.0.0 Upstream Author : Arne Brasseur * URL or Web page : https://github.com/plexus/a.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : functions for dealing with associative structures Library for dealing with associative data structures: alists, hash-maps, and vectors (for vectors, the indices are treated as keys). This library is largely inspired by Clojure, it has many of the functions found in clojure.core, prefixed with `a-'. All functions treat their arguments as immutable, so e.g. `a-assoc' will clone the hash-table or alist it is given. Keep this in mind when writing performance sensitive code. This is a new dependency of pcre2el, needed to fix RC bug. The package will be maintained under Debian Emacsen team umbrella.
Bug#1006818: eye: (autopkgtest) failure on non-amd64
Ср 28 сен 2022 @ 18:59 Jonas Smedegaard : > Quoting Lev Lamberov (2022-09-28 09:35:00) >> Since now SWI-Prolog in Debian supports setting an arch-independent path >> to the interpreter (8.4.3+dfsg-1, uploaded on 2022-09-18, in testing >> since 2022-09-21), I'm reassigning this bug report to eye. The eye >> package needs rebuild against the mentioned new swi-prolog version using >> something like this command: >> >> swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl > > Hmm - seems I will need some additional guidance - the above does not > work for me. > > This is the command that was used previously: > > swipl -q -f eye.pl -g main -- --image eye.pvm > > I tried replacing with the following command: > > swipl -q -c eye.pl -g main --emulator=/usr/bin/swipl -o eye.pvm > > ...but that did *not* generate file "eye.pvm" but instead "a.out" which > did not behave as expected (running `./a.out --help` ended in some > prompt - I guess a SWI-Prolog prompt). > > I then tried this command: > > swipl -o myexe --emulator=/usr/bin/swipl -c eye.pl > > ...which generated expected file, but again it offered some prompt not > expected eye interface. > > Can you help suggest a command? Probably the command you need is /usr/bin/swipl -o eye.pvm --emulator=/usr/bin/swipl -g main -c eye.pl -- --image eye.pvm Cheers! Lev
Bug#1006818: eye: (autopkgtest) failure on non-amd64
Control: reassign -1 eye 22.0203.1955~ds-1 Hi, Since now SWI-Prolog in Debian supports setting an arch-independent path to the interpreter (8.4.3+dfsg-1, uploaded on 2022-09-18, in testing since 2022-09-21), I'm reassigning this bug report to eye. The eye package needs rebuild against the mentioned new swi-prolog version using something like this command: swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl Cheers! Lev Вс 18 сен 2022 @ 23:23 Lev Lamberov : > Hi Jonas, > > Вт 06 сен 2022 @ 16:10 Jonas Smedegaard : > >> Quoting Lev Lamberov (2022-09-06 14:00:55) >>> Hi Jonas, >>> >>> Сб 03 сен 2022 @ 21:19 Jonas Smedegaard : >>> >>> >> The autopkgtest caught that the package is not functional on !amd64: >>> >> >>> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm >>> >> /usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: >>> >> not found >>> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ >>> >> >>> >> Changing Architecture: from "all" to "any" might be a reasonable option. >>> > >>> > In my understanding, this is a bug in SWI Prolog, in that when >>> > generating a so-called "intermediate code file" it embeds an >>> > arch-specific path to the interpreter instead of the arch-independent >>> > symlink in PATH: /usr/bin/swipl >>> > >>> > @Lev: What do you think? Is it possible to patch SWI Prolog to embed an >>> > architecture-agnostic path for executing intermediary files? >>> >>> SWI-Prolog supports three different pre-compiled formats: qlf, boot.prc, >>> and user created states. The first two do not include paths to the >>> interpreter. Looks like eye relies on the third one. I've asked upstream >>> about the possibility to embed an arch-independent path to such user >>> created states and got the answer that sometimes it is not a good idea, >>> because these states may differ due to conditional compilation. I've >>> looked into eye and looks like it does not (at least curretly, or I was >>> not able to spot it) use conditional compilation on various >>> architectures. So, I think it is probably save to embed arch-independent >>> path to the interpreter. SWI-Prolog upstream pushed a commit to support >>> this feature, but one should enable it explicitely with a command-line >>> option when running swipl to generate pre-compiled file of this kind >>> (like, swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl). I will >>> add this patch to the swi-prolog in Debian in the near future (probably, >>> I will have some time for it on the coming weekend, also I plan to >>> finish packaging a new upstream stable release, 8.4.3, where Debian is >>> at 8.4.2 at this point). I'll let you know when you can experiment with >>> eye concerning this change. >> >> Cool! Thanks a lot! > > Finally, I've just uploaded swi-prolog 8.4.3 including patch to allow > setting path to the interpreter. > > Cheers! > Lev
Bug#1006818: eye: (autopkgtest) failure on non-amd64
Hi Jonas, Вт 06 сен 2022 @ 16:10 Jonas Smedegaard : > Quoting Lev Lamberov (2022-09-06 14:00:55) >> Hi Jonas, >> >> Сб 03 сен 2022 @ 21:19 Jonas Smedegaard : >> >> >> The autopkgtest caught that the package is not functional on !amd64: >> >> >> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm >> >> /usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: >> >> not found >> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ >> >> >> >> Changing Architecture: from "all" to "any" might be a reasonable option. >> > >> > In my understanding, this is a bug in SWI Prolog, in that when >> > generating a so-called "intermediate code file" it embeds an >> > arch-specific path to the interpreter instead of the arch-independent >> > symlink in PATH: /usr/bin/swipl >> > >> > @Lev: What do you think? Is it possible to patch SWI Prolog to embed an >> > architecture-agnostic path for executing intermediary files? >> >> SWI-Prolog supports three different pre-compiled formats: qlf, boot.prc, >> and user created states. The first two do not include paths to the >> interpreter. Looks like eye relies on the third one. I've asked upstream >> about the possibility to embed an arch-independent path to such user >> created states and got the answer that sometimes it is not a good idea, >> because these states may differ due to conditional compilation. I've >> looked into eye and looks like it does not (at least curretly, or I was >> not able to spot it) use conditional compilation on various >> architectures. So, I think it is probably save to embed arch-independent >> path to the interpreter. SWI-Prolog upstream pushed a commit to support >> this feature, but one should enable it explicitely with a command-line >> option when running swipl to generate pre-compiled file of this kind >> (like, swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl). I will >> add this patch to the swi-prolog in Debian in the near future (probably, >> I will have some time for it on the coming weekend, also I plan to >> finish packaging a new upstream stable release, 8.4.3, where Debian is >> at 8.4.2 at this point). I'll let you know when you can experiment with >> eye concerning this change. > > Cool! Thanks a lot! Finally, I've just uploaded swi-prolog 8.4.3 including patch to allow setting path to the interpreter. Cheers! Lev
Bug#1006818: eye: (autopkgtest) failure on non-amd64
Hi Jonas, Сб 03 сен 2022 @ 21:19 Jonas Smedegaard : >> The autopkgtest caught that the package is not functional on !amd64: >> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm >> /usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: not >> found >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ >> >> Changing Architecture: from "all" to "any" might be a reasonable option. > > In my understanding, this is a bug in SWI Prolog, in that when > generating a so-called "intermediate code file" it embeds an > arch-specific path to the interpreter instead of the arch-independent > symlink in PATH: /usr/bin/swipl > > @Lev: What do you think? Is it possible to patch SWI Prolog to embed an > architecture-agnostic path for executing intermediary files? SWI-Prolog supports three different pre-compiled formats: qlf, boot.prc, and user created states. The first two do not include paths to the interpreter. Looks like eye relies on the third one. I've asked upstream about the possibility to embed an arch-independent path to such user created states and got the answer that sometimes it is not a good idea, because these states may differ due to conditional compilation. I've looked into eye and looks like it does not (at least curretly, or I was not able to spot it) use conditional compilation on various architectures. So, I think it is probably save to embed arch-independent path to the interpreter. SWI-Prolog upstream pushed a commit to support this feature, but one should enable it explicitely with a command-line option when running swipl to generate pre-compiled file of this kind (like, swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl). I will add this patch to the swi-prolog in Debian in the near future (probably, I will have some time for it on the coming weekend, also I plan to finish packaging a new upstream stable release, 8.4.3, where Debian is at 8.4.2 at this point). I'll let you know when you can experiment with eye concerning this change. Cheers! Lev
Bug#1019202: dh-make-elpa: crashes with: Can't locate object method "gecos"
Hi David, Пн 05 сен 2022 @ 09:51 David Bremner : > Package: dh-make-elpa > Version: 0.19.1 > Severity: important > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > % git clone -o upstream https://github.com/legoscia/srv.el > % dh-make-elpa --pkg-emacsen > Can't locate object method "gecos" via package "bremner" (perhaps you forgot > to load "bremner"?) at /usr/share/perl5/DhMakeELPA/Command/Packaging.pm line > 127. > > Probably doesn't depend on the repo. It doesn't get very far with the > packaging, crashes part way through generating debian/changelog. Hmm... have you changed directory to srv.el before running dh-make-elpa? Because I cannot reproduce this, see: $ git clone -o upstream https://github.com/legoscia/srv.el $ cd srv.el/ $ dh-make-elpa --pkg-emacsen I: couldn't generate d/docs: not fully implemented $ ls debian srv.el $ ls debian/ changelog control copyright elpa gbp.conf rules source watch Cheers! Lev
Bug#1016166: riseup-vpn: wrong values of Vcs-{Browser,Git} fields in d/control
Package: riseup-vpn
Version: 0.21.11+ds-3
Severity: minor
Tags: newcomer
Dear Maintainer,
Vcs-{Browser,Git} fields in d/control are set to
https://salsa.debian.org/med-team/bitmask-vpn{,git}, which is wrong
since the package's Salsa repository is under Go Packaging team, not
Debian Med team.
Cheers!
Lev
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages riseup-vpn depends on:
ii libc62.33-8
ii libgcc-s112.1.0-7
ii libqt5core5a 5.15.4+dfsg-4
ii libqt5gui5 5.15.4+dfsg-4
ii libqt5qml5 5.15.4+dfsg-4
ii libqt5widgets5 5.15.4+dfsg-4
ii libstdc++6 12.1.0-7
ii openvpn 2.6.0~git20220518+dco-2
ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7+b1
ii python3 3.10.5-3
ii qml-module-qt-labs-platform 5.15.4+dfsg-2
ii qml-module-qtquick-controls2 5.15.4+dfsg-2
ii qml-module-qtquick-dialogs 5.15.4-2
ii qml-module-qtquick-extras5.15.4-2
ii qml-module-qtquick2 5.15.4+dfsg-4
riseup-vpn recommends no packages.
riseup-vpn suggests no packages.
-- no debconf information
Bug#1016108: RFP: minuimus -- file optimiser utility script
Package: wnpp Severity: wishlist * Package name: minuimus Version : 3.5.1 Upstream Author : Codebird aka CorvusRidiculissimus * URL : https://birds-are-nice.me/software/minuimus.html * License : GPL-3 Programming Lang: C, Perl Description : file optimiser utility script Minuimus is a file optimiser utility script: You point it at a file, and it makes the file smaller without compromising the file contents. File optimisers are able to do this using a variety of file-specfic optimisations, most of which involve decompressing data within a compressed file and recompressing it in a more efficient manner. The process could be compared directly to extracting a ZIP file, then recompressing it at the most demanding setting. It uses many of the same techniques used by other optimisers such as Papa's Best Optimizer. The exact space saving achieved by this level of file optimisation is highly dependent upon the file being optimised. As is expected for any file optimiser, even after extensive testing, the results are too inconsistent to easily quantify. A collection of PDF files sampled from the-eye.eu was reduced in size to 90% of the input, while a half-terabyte sample taken from the archive.org 'computermagazine' collection was reduced with greater success to 78% of the input size. A collection of epub files from Project Gutenberg was reduced to a mere 95%, as these files are light on images, and ZIP files with no files inside which can be recursively optimised are reduced only very slightly, typically to around 97%.
Bug#1014742: riseup-vpn: should depend on qml-module-qtquick-controls
Package: riseup-vpn Version: 0.21.11+ds-3 Severity: important Dear Maintainer, Thanks for your work on riseup-vpn. Typically, I don't use QT and/or QML, so I don't have any related packages installed. After I installed riseup-vpn, I faced the following problem. It started correctly, connected, and showed MOTD message, but after closing the message I have only a blank window without any controls. The output in console gives the clue: qrc:/components/MainView.qml:101:5: Type Dialog unavailable file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultDialogWrapper.qml:41:1: module "QtQuick.Controls" version 1.2 is not installed After that I manually installed qml-module-qtquick-controls, and now it is possible to use riseup-vpn. So, I guess, riseup-vpn should depend on qml-module-qtquick-controls. Cheers! Lev -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages riseup-vpn depends on: ii libc62.33-7 ii libgcc-s112.1.0-2 ii libqt5core5a 5.15.4+dfsg-3 ii libqt5gui5 5.15.4+dfsg-3 ii libqt5qml5 5.15.4+dfsg-4 ii libqt5widgets5 5.15.4+dfsg-3 ii libstdc++6 12.1.0-2 ii openvpn 2.6.0~git20220518+dco-2 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7+b1 ii python3 3.10.4-1+b1 ii qml-module-qt-labs-platform 5.15.4+dfsg-2 ii qml-module-qtquick-controls2 5.15.4+dfsg-2 ii qml-module-qtquick-dialogs 5.15.4-2 ii qml-module-qtquick-extras5.15.4-2 ii qml-module-qtquick2 5.15.4+dfsg-4 riseup-vpn recommends no packages. riseup-vpn suggests no packages. -- no debconf information
Bug#963727: dh-make-{elpa,perl}: move duplicate code to a library
Hi gregor,
Mon 23 May 2022 @ 16:54 gregor herrmann :
> On Fri, 26 Jun 2020 11:38:48 +0500, Lev Lamberov wrote:
>
>> Hi,
>
> Sorry for replying so late, somehow this bug fell throught the
> cracks.
>
>> dh-make-elpa is heavily based on dh-make-perl (thanks to all who
>> were/are involved into whis nice tool). Both share the same
>> object-oriented structure and some code. Recently, dh-make-elpa was
>> untied from dh-make-perl, so now the former doesn't depend on the
>> latter. But this was done by copying some code from dh-make-perl without
>> changes. The better option would be to move duplicate code to a library.
>
> Makes sense.
>
>> It would be nice to identify those methods which may be useful for
>> various (possible) implementations of dh-make- and are
>> unlikely to change significantly in the future. Those methods could be
>> moved to, say, DhMake::Packaging.
>
> Agreed.
>
>> I would like to implement changes for both dh-make{elpa,perl}, but first
>> we should discuss what should be done and in which way. So, CCing Debian
>> Perl Group mailing list, but I think that it's better to keep the
>> discussion in one place, that is, in this bug report.
>
> From a dh-make-perl perspective I think we are happy with everything
> which "only" moves functionality around without breaking anything.
> So if you are still planning to work on this task, please go ahead
> and send patches/merge requests.
Thanks for the update. Hope, I will have some time during the coming
summer.
Cheers!
Lev
Bug#1010128: (no subject)
I can confirm the problem. Please, find the build log attached. Cheers! Lev Lamberov ===File /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log=== DKMS make.log for broadcom-sta-6.30.223.271 for kernel 5.17.0-1-amd64 (x86_64) Чт 28 апр 2022 14:11:12 +05 CFG80211 API is prefered for this kernel version Makefile:89: Neither CFG80211 nor Wireless Extension is enabled in kernel KBUILD_NOPEDANTIC=1 make -C /lib/modules/5.17.0-1-amd64/build M=`pwd` make[1]: предупреждение: сервер заданий недоступен: используется -j1. Добавьте «+» к правилу в родительском make. make[1]: вход в каталог «/usr/src/linux-headers-5.17.0-1-amd64» warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc-11 (Debian 11.2.0-20) 11.2.0 You are using: gcc-11 (Debian 11.3.0-1) 11.3.0 CFG80211 API is prefered for this kernel version Using CFG80211 API Kernel architecture is X86_64 CC [M] /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.o CC [M] /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o In file included from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:81: /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_iw.h:73: warning: "isprint" redefined 73 | #define isprint(c) bcm_isprint(c) | In file included from /usr/src/linux-headers-5.17.0-1-common/include/linux/string_helpers.h:6, from /usr/src/linux-headers-5.17.0-1-common/include/linux/seq_file.h:7, from /usr/src/linux-headers-5.17.0-1-common/include/linux/seq_file_net.h:5, from /usr/src/linux-headers-5.17.0-1-common/include/net/net_namespace.h:183, from /usr/src/linux-headers-5.17.0-1-common/include/linux/netdevice.h:37, from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:69, from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:27: /usr/src/linux-headers-5.17.0-1-common/include/linux/ctype.h:30: note: this is the location of the previous definition 30 | #define isprint(c) ((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0) | In file included from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/osl.h:79, from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:28: /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In function ‘wl_attach’: /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:650:43: warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 650 | bcopy(&wl->pub->cur_etheraddr, dev->dev_addr, ETHER_ADDR_LEN); /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linux_osl.h:156:49: note: in definition of macro ‘bcopy’ 156 | #define bcopy(src, dst, len)memcpy((dst), (src), (len)) | ^~~ In file included from /usr/src/linux-headers-5.17.0-1-common/include/linux/string.h:253, from /usr/src/linux-headers-5.17.0-1-common/include/linux/bitmap.h:11, from /usr/src/linux-headers-5.17.0-1-common/include/linux/cpumask.h:12, from /usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/cpumask.h:5, from /usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/msr.h:11, from /usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/processor.h:22, from /usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/timex.h:5, from /usr/src/linux-headers-5.17.0-1-common/include/linux/timex.h:65, from /usr/src/linux-headers-5.17.0-1-common/include/linux/time32.h:13, from /usr/src/linux-headers-5.17.0-1-common/include/linux/time.h:60, from /usr/src/linux-headers-5.17.0-1-common/include/linux/stat.h:19, from /usr/src/linux-headers-5.17.0-1-common/include/linux/module.h:13, from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:40, from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:27: /usr/src/linux-headers-5.17.0-1-common/include/linux/fortify-string.h:212:37: note: expected ‘void *’ but argument is of type ‘const unsigned char *’ 212 | __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size) | ~~^ In file included from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/osl.h:79, from /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:28: /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In function ‘wl_set_mac_address’: /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:1861:39: warning: passing argument 1 of ‘memcpy’ discards ‘co
Bug#1005887: unixodbc-dev does not contain unixodbc_conf.h
Package: unixodbc-dev Version: 2.3.9-4 Severity: important X-Debbugs-Cc: dogs...@debian.org Dear Maintainer, unixodbc-dev does not ship unixodbc_conf.h (at least, on amd64 and i386). The version in stable does ship it, but the version in testing and unstable does not. It breaks builds of some packages, e. g. build of swi-prolog fails for 32-bit architectures. 32-bit platforms support 64-bit integers and actually all should as SWI-Prolog cannot work without them. There is a suggestion that somehow SQLBIGINT is not configured correctly. More specifically, the missing unixodbc_conf.h should contain either both or one of #define HAVE_LONG_LONG 1 #define SIZEOF_LONG_INT 8 With regards, Lev Lamberov (Sorry, I'm writing it from Ubuntu, so the following system information is not relevant.) -- System Information: Debian Release: 11.0 APT prefers impish-updates APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 'impish'), (100, 'impish-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-28-generic (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unixodbc-dev depends on: ii libltdl-dev 2.4.6-15 ii libodbc1 2.3.6-0.1build2 ii odbcinst1debian2 2.3.6-0.1build2 unixodbc-dev recommends no packages. unixodbc-dev suggests no packages.
Bug#1002982: Acknowledgement (elpa-org: post-installation script subprocess returned error exit status 1)
And here is Emacs debug output:
Debugger entered--Lisp error: (error "Invalid version syntax: ‘N/A’ (must start
with a n...")
signal(error ("Invalid version syntax: ‘N/A’ (must start with a n..."))
error("Invalid version syntax: `%s' (must start with a nu..." "N/A")
version-to-list("N/A")
version<("N/A" "9.0")
(if (version< (org-version) "9.0") (with-no-warnings (org-add-link-type
"elfeed" #'elfeed-link-open) (add-hook 'org-store-link-functions
#'elfeed-link-store-link)) (with-no-warnings (org-link-set-parameters "elfeed"
:follow #'elfeed-link-open :store #'elfeed-link-store-link)))
(lambda nil (if (version< (org-version) "9.0") (with-no-warnings
(org-add-link-type "elfeed" #'elfeed-link-open) (add-hook
'org-store-link-functions #'elfeed-link-store-link)) (with-no-warnings
(org-link-set-parameters "elfeed" :follow #'elfeed-link-open :store
#'elfeed-link-store-link()
funcall((lambda nil (if (version< (org-version) "9.0") (with-no-warnings
(org-add-link-type "elfeed" #'elfeed-link-open) (add-hook
'org-store-link-functions #'elfeed-link-store-link)) (with-no-warnings
(org-link-set-parameters "elfeed" :follow #'elfeed-link-open :store
#'elfeed-link-store-link)
(lambda nil (funcall '(lambda nil (if (version< (org-version) "9.0")
(with-no-warnings (org-add-link-type "elfeed" #'elfeed-link-open) (add-hook
'org-store-link-functions #'elfeed-link-store-link)) (with-no-warnings
(org-link-set-parameters "elfeed" :follow #'elfeed-link-open :store
#'elfeed-link-store-link))()
eval-after-load-helper("/usr/share/emacs/site-lisp/elpa/org-9.5.2/org.elc")
run-hook-with-args(eval-after-load-helper
"/usr/share/emacs/site-lisp/elpa/org-9.5.2/org.elc")
do-after-load-evaluation("/usr/share/emacs/site-lisp/elpa/org-9.5.2/org.elc")
require(org)
byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\207"
[require cl-lib org grep seq async dash f hl-todo magit pcre2el s] 2)
require(magit-todos nil t)
(not (require 'magit-todos nil t))
(if (not (require 'magit-todos nil t)) (display-warning 'use-package (format
"Cannot load %s" 'magit-todos) :error) (condition-case err (progn
(magit-todos-mode) t) ((debug error) (funcall use-package--warning47 :config
err
(condition-case err (if (not (require 'magit-todos nil t)) (display-warning
'use-package (format "Cannot load %s" 'magit-todos) :error) (condition-case err
(progn (magit-todos-mode) t) ((debug error) (funcall use-package--warning47
:config err ((debug error) (funcall use-package--warning47 :catch err)))
eval-buffer(# nil "/home/dogsleg/.emacs.d/init.el" nil t) ;
Reading at buffer position 25241
load-with-code-conversion("/home/dogsleg/.emacs.d/init.el"
"/home/dogsleg/.emacs.d/init.el" t t)
load("/home/dogsleg/.emacs.d/init" noerror nomessage)
startup--load-user-init-file(#f(compiled-function () #) #f(compiled-function () #) t)
command-line()
normal-top-level()
Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1
Package: elpa-org Version: 9.5.2+dfsh-1 Severity: grave X-Debbugs-Cc: none, Lev Lamberov Dear Maintainer, While updating elpa-org (9.4.0+dfsg-1 -> 9.5.2+dfsh-1, in testing) I faced a problem with post-installation, which is still there even in case of completely removing elpa-org and then reinstalling it. Please, see the followin apt output: * Purging $ LC_ALL=C.UTF-8 sudo apt purge elpa Reading package lists... Done Building dependency tree... Done Reading state information... Done E: Unable to locate package elpa 10:43:17-dogsleg@shakva:~$ LC_ALL=C.UTF-8 sudo apt purge elpa-org Reading package lists... Done Building dependency tree... Done Reading state information... Done The following package was automatically installed and is no longer required: elpa-htmlize Use 'sudo apt autoremove' to remove it. The following packages will be REMOVED: elpa-org* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 5214 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 486521 files and directories currently installed.) Removing elpa-org (9.5.2+dfsh-1) ... Remove elpa-org for emacs remove/org-9.5.2: Handling removal of emacsen flavor emacs dh-elpa: purging flavor specific files for emacs * Installing again $ LC_ALL=C.UTF-8 sudo apt install elpa-org Reading package lists... Done Building dependency tree... Done Reading state information... Done Suggested packages: ditaa The following NEW packages will be installed: elpa-org 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/949 kB of archives. After this operation, 5214 kB of additional disk space will be used. Selecting previously unselected package elpa-org. (Reading database ... 486388 files and directories currently installed.) Preparing to unpack .../elpa-org_9.5.2+dfsh-1_all.deb ... Unpacking elpa-org (9.5.2+dfsh-1) ... Setting up elpa-org (9.5.2+dfsh-1) ... tsort: -: input contains a loop: tsort: elpa-htmlize tsort: emacsen-common Install elpa-htmlize for emacs install/htmlize-1.56: Handling install of emacsen flavor emacs install/htmlize-1.56: byte-compiling for emacs Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs Install elpa-org for emacs install/org-9.5.2: Handling install of emacsen flavor emacs install/org-9.5.2: byte-compiling for emacs Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-agenda.el:50:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-archive.el:31:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-attach-git.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-attach.el:38:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-capture.el:51:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-clock.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-colview.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-ctags.el:141:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-datetree.el:33:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-element.el:64:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-feed.el:91:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-goto.el:25:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-habit.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org version correctly. Check installation! In toplevel form: org-id.el:73:1:Error: Invalid version syntax: ‘N/A’ (must start with a number) Warning (emacs): Could not define org vers
Bug#1002922: minetest-mod-worldedit: please update package to the newer upstream version
Package: minetest-mod-worldedit Severity: normal X-Debbugs-Cc: none, Lev Lamberov , Debian Games Team Dear Maintainer, Currently the version of minetest-mod-worldedit in Debian is 0.6. It was not updated since its initial upload in 2013. Please, consider updating the package. Also, it would be nice not to depend on minetest itself, since it make the package rather problematic to use on headless servers. Please, depend on minetest | minetest-server. Cheers! Lev Lamberov -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1001687: ITP: pyim-el -- Chinese input method support quanpin, shuangpin, wubi, cangjie and rime
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: pyim-el Version : 3.9.5 Upstream Author : Feng Shu * URL or Web page : https://elpa.gnu.org/packages/pyim.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : Chinese input method support quanpin, shuangpin, wubi, cangjie and rime pyim is a Chinese input method in the Emacs environment. The code of pyim is derived from Emacs-eim, which development stopped after 2008. Although the external input method is powerful, it can't cooperate with Emacs tacitly, which greatly damages the feeling of Emacs. Features: - pyim supports Quanpin, Shuangpin, Wubi and Cangjie, among which Quanpin is the best; - pyim optimizes the input method by adding thesaurus; - pyim uses the text lexicon format, which is convenient for processing; - pyim can be used as the front end for rime.
Bug#1001688: ITP: pyim-basedict-el -- default pinyin dict for pyim
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: pyim-basedict-el Version : 0.5.0 Upstream Author : Feng Shu * URL or Web page : https://elpa.gnu.org/packages/pyim-basedict.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : default pinyin dict for pyim pyim-basedict is the default lexicon of pyim input method, and the lexicon data source is the libpinyin project. Note: The number of entries in this thesaurus is about 10, which is a *relatively small* thesaurus. It only ensures pyim can work normally. If users want to make pyim more comfortable, they need to add other additional thesaurus.
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Nicholas, Чт 29 апр 2021 @ 13:54 Nicholas D Steeves : > Antoine Beaupré writes: > >> That didn't work, but I manually bisected my .emacs.d/init.el file and >> came up with this minimal reproducer: >> >> (when (require 'package nil t) >> (setq-default >>load-prefer-newer t >>package-enable-at-startup nil) >> (package-initialize) > > I wonder if this "(package-initialize)" line, while using Emacs >= 27 is > exposing a bug in lsp-mode? Since Emacs 27 now automatically runs > package-initialize in between the new early-init.el and the classic > .emacs.el/init.el/etc, maybe lsp-mode has an autoload cookie that gets > evaluated twice, leading to the broken state of the lsp sentinel? > Alternatively, maybe lsp-mode now assumes we live in a post-Emacs 27 > world where all users have already dropped package-initialize from their > configs? > > These Emacs >= 27 changes also affect the point in emacs init where > package-enable-at-startup can be set: > > If non-nil, packages are made available before reading the init file > (but after reading the early init file). This means that if you > wish to set this variable, you must do so in the early init file. > > I think this bug is still valid and actionable even if removing > package-initialize from the minimum reproducer, and/or after moving > package-enable-at-startup to early-init.el makes the bug unreproducible. > If nothing else, it seems like our src:emacs might need a NEWS entry on > the topic, but that said, my suspicion is that lsp-mode could be more > defensive. That's interesting! Thanks for your input. I've tried Antoine's minimal configuration and can confirm that commenting out (package-initialize) resolves the problem. So, it really means that lsp-mode has an autoload cookie which when evaluated twice causes the bug. But now I wonder to which package should we assign the bug report, lsp-mode, emacs, some other package?.. Cheers! Lev
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Ср 28 апр 2021 @ 14:30 Antoine Beaupré :
> On 2021-04-28 23:07:26, Lev Lamberov wrote:
>> Ср 28 апр 2021 @ 11:44 Antoine Beaupré :
>>
>>> On 2021-04-28 20:34:26, Lev Lamberov wrote:
>>>> It makes it a bit trickier. There another package, elpa-bug-hunter
>>>> [elpa-bug-hunter], which automatically debug and bisect your init.el or
>>>> .emacs file. It may be worth t try it with your config.
>>>>
>>>> [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter
>>>
>>> Actually, do you know how I would use bug-hunter and esup together? It
>>> seems they *both* start a separate emacs process to debug the startup,
>>> and thus would be in conflict with each other...
>>
>> Guess, you may start Emacs as usual, then edit your configuration to run
>> esup (that is, run it as a last line of your config), and then run
>> bug-hunter. Probably, it will work. Or not. At least, it's worth a try.
>
> That didn't work, but I manually bisected my .emacs.d/init.el file and
> came up with this minimal reproducer:
>
> (when (require 'package nil t)
> (setq-default
>load-prefer-newer t
>package-enable-at-startup nil)
> (package-initialize)
> (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/";)
> ("melpa" . "https://melpa.org/packages/";)))
> ;; in elpa-use-package debian package since stretch
> (unless (package-installed-p 'use-package)
> (package-refresh-contents)
> (package-install 'use-package)))
>
> (eval-when-compile
> (require 'use-package)
> (setq-default
>use-package-always-defer nil
>use-package-always-ensure t))
>
> (use-package lsp-mode
> :commands (lsp lsp-deferred)
> :demand t
> ;;:init
> ;;(setq lsp-keymap-prefix "C-c l")
> ;; TODO: https://emacs-lsp.github.io/lsp-mode/page/performance/
> ;; also note re "native compilation": <+varemara> it's the
> ;; difference between lsp-mode being usable or not, for me
> :config
> (setq lsp-auto-configure t))
>
> It could probably be trimmed down more, and i suspect the 'lsp-mode' bit
> is a red-herring: any package would probably trigger it.
I installed elpa-lsp-mode and tried the config you provided and I can
confirm the bug. In *Messages* I can see the following:
esup process started on port 44801
at 1
error in process sentinel: slot-value: Wrong type argument: (or eieio-object
class), nil, obj
error in process sentinel: Wrong type argument: (or eieio-object class), nil,
obj
But when I tried with other packages (both one by one and together) I
cannot reproduce the bug. That is, I commented out lsp-mode part of your
config and tried, then tried with several other packages (namely,
ansi-color, eyebrowse, anzu, beacon, and undo-tree). I cannot reproduce
the bug with any of the mentioned packages neither when I use just one
of them instead of lsp-mode, nor any set of these packages instead of
lsp-mode. And I tried to remove my custom.el and started with sane
configuration of GNU Emacs.
Cheers!
Lev
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Ср 28 апр 2021 @ 11:44 Antoine Beaupré : > On 2021-04-28 20:34:26, Lev Lamberov wrote: >> It makes it a bit trickier. There another package, elpa-bug-hunter >> [elpa-bug-hunter], which automatically debug and bisect your init.el or >> .emacs file. It may be worth t try it with your config. >> >> [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter > > Actually, do you know how I would use bug-hunter and esup together? It > seems they *both* start a separate emacs process to debug the startup, > and thus would be in conflict with each other... Guess, you may start Emacs as usual, then edit your configuration to run esup (that is, run it as a last line of your config), and then run bug-hunter. Probably, it will work. Or not. At least, it's worth a try. Cheers! Lev
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Ср 28 апр 2021 @ 08:50 Antoine Beaupré : > Control: severity -1 normal > > On 2021-04-28 09:00:46, Lev Lamberov wrote: >> Hi Antoine, >> >> Вт 27 апр 2021 @ 13:53 Antoine Beaupre : >> I have elpa-esup installed for a long time and I cannot reproduce the >> bug on my machine. Running esup starts another GNU Emacs session and >> gives me a proper report on startup like the following excerpt: > > Oh interesting! Maybe that's why it works, since the bytecode is older? Well, each update of GNU Emacs and at least sometimes updates of dh-elpa trigger recompilation of all installed packages. On my machine file /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup.elc starts with ``` ;ELC^W^@^@^@ ;;; Compiled ;;; in Emacs version 27.1 ;;; with all optimizations. ``` That is, it was recompiled at least with installation of GNU Emacs 27.1, which was first uploaded to unstable on 2020-10-24, but I still remember that there were more recompilation of all installed packages recently (probably, even on 2021-04-07 when Emacs 1:27.1+1-3.1 entered testing). >> ``` >> Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total >> GC Time: 0.065sec >> >> package.elc:16 0.134sec 37% >> (byte-code "\301\302!\210\301\303!\210 [...] >> ``` >> >> I wonder how recompiling could fix the problem you face, since >> installing/reinstalling the package or GNU Emacs itself should trigger >> recompilation of it along with all other installed Emacs packages. > > Yeah, as I said I haven't tried to recompile myself, that's just what > the upstream bug report says. If anything, maybe it's the opposite and > if *you* recompile you'll trigger the bug? No idea. I've tried to reinstall elpa-esup, which caused recompilation and still I cannot reproduce your bug both with my config and with emacs -q. >> So, may it be a bug in dh-elpa or GNU Emacs itself? > > Maybe! This is way beyond my elisp-fu unfortunately. > > One key information I have just discovered is that I can't reproduce > with `emacs -q`. So this is probably an interaction with my .emacs.d > configuration and the package, unfortunately. Downgrading severity. It makes it a bit trickier. There another package, elpa-bug-hunter [elpa-bug-hunter], which automatically debug and bisect your init.el or .emacs file. It may be worth t try it with your config. [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter Cheers! Lev
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Antoine, Вт 27 апр 2021 @ 13:53 Antoine Beaupre : > Package: elpa-esup > Version: 0.7.1-3 > Severity: grave > Tags: upstream > > This package is unusable in Debian 11 bullseye in its current > state. In my Emacs 1:27.1+1-3.1 session, i run M-x esup and I get: > > error in process sentinel: Wrong type argument: (or eieio-object class), nil, > obj > > *Messages* has this: > > Loading /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup-autoloads.el > (source)...done > Starting esup... > esup process started on port 37851 > at 1 > error in process sentinel: slot-value: Wrong type argument: (or eieio-object > class), nil, obj > error in process sentinel: Wrong type argument: (or eieio-object class), nil, > obj > > This is the upstream bug: https://github.com/jschaf/esup/issues/85 > > It looks like it is a packaging issue, since, according to the above > bug report, recompiling the .el files fixes the problem (haven't tested). Thanks for reporting, investigating and forwarding! Is it a fresh install of elpa-esup? I have elpa-esup installed for a long time and I cannot reproduce the bug on my machine. Running esup starts another GNU Emacs session and gives me a proper report on startup like the following excerpt: ``` Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total GC Time: 0.065sec package.elc:16 0.134sec 37% (byte-code "\301\302!\210\301\303!\210 [...] ``` I wonder how recompiling could fix the problem you face, since installing/reinstalling the package or GNU Emacs itself should trigger recompilation of it along with all other installed Emacs packages. The package does not contain any pre-compiled files: ``` $ apt-file show elpa-esup elpa-esup: /usr/lib/emacsen-common/packages/compat/elpa-esup elpa-esup: /usr/lib/emacsen-common/packages/install/elpa-esup elpa-esup: /usr/lib/emacsen-common/packages/remove/elpa-esup elpa-esup: /usr/share/doc/elpa-esup/README.md elpa-esup: /usr/share/doc/elpa-esup/changelog.Debian.gz elpa-esup: /usr/share/doc/elpa-esup/copyright elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-autoloads.el elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-child.el elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-pkg.el elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup.el ``` So, may it be a bug in dh-elpa or GNU Emacs itself? Cheers! Lev
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
By the way here is the relevant output from *Message* on my machine: ``` Starting esup... esup process started on port 45217 at 1 esup finished ``` Cheers! Lev
Bug#883337: [Pkg-iscsi-maintainers] Bug#883337: open-isns: [INTL:ru] Russian translation of debconf template
Hi Ritesh, Вт 22 дек 2020 @ 19:14 Ritesh Raj Sarraf : > On Sat, 2017-12-02 at 20:24 +0500, Lev Lamberov wrote: >> Dear Maintainer, >> >> please find attached the Russian debconf translation for open-isns. > > I've just stepped in to fill in for Christian, while he's MIA. I've > added your patch and it will be part of the next upload. Thanks for your work! Cheers! Lev
Bug#973855: pentobi: should depend on qml-module-qtqml
Hi Juhani, Thanks for your work on pentobi. Сб 14 ноя 2020 @ 21:03 Juhani Numminen : > Thanks for the report. > > pe 6. marrask. 2020 klo 7.45 Lev Lamberov (dogs...@debian.org) kirjoitti: >> Dear Maintainer, >> >> pentobi should depend on qml-module-qtqml, it doesn't work without >> this package: >> >> $ pentobi >> QtWebEngine::initialize() called with QCoreApplication object already >> created and should be call before. This is depreciated and may fail in the >> future. >> Attribute Qt::AA_ShareOpenGLContexts must be set before QCoreApplication is >> created. >> QQmlApplicationEngine failed to load component >> qrc:/qml/Main.qml:7:1: module "QtQml" is not installed > > I tried today and am not seeing this error, even with qml-module-qtqml > uninstalled. I'm guessing it may be > related to the new qt version 5.15 vs 5.14. Can you try again with the > newer qt packages? I've tried with qt 5.15 and can confirm that the reported problem is gone. That is, qml-module-qtqml is no longer required to run pentobi. Regards, Lev
Bug#973855: pentobi: should depend on qml-module-qtqml
Package: pentobi Version: 17.3-1+b1 Severity: important Tags: newcomer Dear Maintainer, pentobi should depend on qml-module-qtqml, it doesn't work without this package: $ pentobi QtWebEngine::initialize() called with QCoreApplication object already created and should be call before. This is depreciated and may fail in the future. Attribute Qt::AA_ShareOpenGLContexts must be set before QCoreApplication is created. QQmlApplicationEngine failed to load component qrc:/qml/Main.qml:7:1: module "QtQml" is not installed Its dependencies on Qt libraries do not pull it either. Regards, Lev Lamberov -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pentobi depends on: ii libc6 2.31-4 ii libgcc-s1 [libgcc1] 10.2.0-16 ii libqt5core5a5.14.2+dfsg-6 ii libqt5gui5 5.14.2+dfsg-6 ii libqt5qml5 5.14.2+dfsg-3 ii libqt5quick55.14.2+dfsg-3 ii libqt5quickcontrols2-5 5.14.2+dfsg-2 ii libqt5webview5 5.14.2-2 ii libstdc++6 10.2.0-16 ii qml-module-qt-labs-folderlistmodel 5.14.2+dfsg-3 ii qml-module-qt-labs-settings 5.14.2+dfsg-3 ii qml-module-qtquick-controls25.14.2+dfsg-2 ii qml-module-qtquick-layouts 5.14.2+dfsg-3 ii qml-module-qtquick-window2 5.14.2+dfsg-3 ii qml-module-qtquick2 5.14.2+dfsg-3 ii qml-module-qtwebview5.14.2-2 pentobi recommends no packages. Versions of packages pentobi suggests: pn pentobi-kde-thumbnailer -- no debconf information
Bug#973527: [Debian FTP Masters] Accepted swi-prolog 8.2.2+dfsg-1.1 (source) into unstable
Ср 04 ноя 2020 @ 14:07 Sebastian Andrzej Siewior : > On 2020-11-04 16:43:53 [+0500], Lev Lamberov wrote: >> Sebastian, thank you very much! > > You are welcome. However autopkgtest isn't happy according to > > https://ci.debian.net/data/autopkgtest/testing/i386/s/swi-prolog/7945032/log.gz Yes, I see. I've reported it upstream. Looks like another regression on 32-bits architectures (the same is for armhf). So, I'll reopen the bug report. > I just re-run it here and I see the same part so it is not just a > glitch: > |Running scripts from table_tests .DIFFERS: 24 common, 1 extra, 1 missing > |EXTRA: > | < remaining(2) > |MISSING: > | > remaining(0) > |ERROR: /usr/lib/swi-prolog/test/Tests/xsb/table_tests/xsb_test_tables.pl:80: > | test abol_test3b: failed > | > |.. > |Script /usr/lib/swi-prolog/test/Tests/xsb/table_tests/xsb_test_tables.pl > failed > >> Cheers! >> Lev > > Sebastian
Bug#973527: swi-prolog: regression on 32-bits architectures
Hi Sebastian, Вт 03 ноя 2020 @ 21:59 Sebastian Andrzej Siewior : > On 2020-11-01 15:59:19 [+0500], Lev Lamberov wrote: >> there is a regression on 32-bits architectures [regression]. It should >> be fixed upstream (in b218a30b5e4bb92ddd399238666448a102117bad), but the >> fix is not tested yet. And currently I'm running low on time, so it >> would be nice if someone could at least test the fix, prepare fixed >> package for upload, or even upload NMU (in this case, please, also push >> your changes to the Salsa repository). > > I applied the patch, built i386 and can confirm that the patch you > mentioned did solve the problem by running debian/tests/runtests. > I'm attaching the NMU. > Feel free to either grab the needed pieces or telling to NMU it. thanks for you work on it. Please, go ahead and upload NMU and push your changes to Salsa repository. Thanks! Regards, Lev
Bug#973527: swi-prolog: regression on 32-bits architectures
Package: swi-prolog Version: 8.2.2+dfsg-1 Severity: important Tags: help newcomer X-Debbugs-Cc: none, Lev Lamberov Hi, there is a regression on 32-bits architectures [regression]. It should be fixed upstream (in b218a30b5e4bb92ddd399238666448a102117bad), but the fix is not tested yet. And currently I'm running low on time, so it would be nice if someone could at least test the fix, prepare fixed package for upload, or even upload NMU (in this case, please, also push your changes to the Salsa repository). Cheers! Lev [regression] https://ci.debian.net/data/autopkgtest/testing/i386/s/swi-prolog/7866315/log.gz -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages swi-prolog depends on: ii swi-prolog-doc 8.2.2+dfsg-1 ii swi-prolog-nox 8.2.2+dfsg-1 ii swi-prolog-x8.2.2+dfsg-1 swi-prolog recommends no packages. swi-prolog suggests no packages. -- no debconf information
Bug#972862: swi-prolog: FTBFS with OpenSSL 1.1.1h
Hi Kurt, Вс 25 окт 2020 @ 13:30 Kurt Roeckx : > Package: swi-prolog > Version: 8.2.1+dfsg-2 > Severity: serious > > Hi, > > swi-prolog fails to build using OpenSSL 1.1.1h. See > https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz > for a log. > > I've filed an upstream bug about this at: > https://github.com/SWI-Prolog/packages-ssl/issues/158 Thanks for your report and for submitting it upstream too. Cheers! Lev
Bug#896458: RFH: SWI-Prolog in Debian
Пт 16 окт 2020 @ 18:40 Brett Gilio : > I was hoping to help keep it upto date, and triage any bugs against it. > Additionally, I was able to get SWIPL to build reproducibly when I > packaged it for GNU Guix (where I also maintain SWIPL), and was wanting > to be able to do the same for Debian. OK, I see. Reproducibility is indeed a very nice feature. So, looking forward to your patches. Cheers! Lev
Bug#896458: RFH: SWI-Prolog in Debian
Hi Brett, > Hello all. If there is still interest in needing co-maintenance on this > package, I would be willing to help. yes, there is still an interest in help with swi-prolog in Debian. What do you plan to do? If you're not quite sure for now, you can start by triaging bugs reported to Debian BTS. But honestly, there are not so much of them. Cheers! Lev
Bug#970768: torbrowser-launcher: error while checking version number after TorBrowser 10.0 release
Hi Roger, Чт 24 сен 2020 @ 01:43 Roger Shimizu : > Dear Lev, > > Thanks for your report! > > On Wed, Sep 23, 2020 at 4:00 PM Lev Lamberov wrote: >> >> Package: torbrowser-launcher >> Version: 0.3.2-13 >> Severity: grave >> Tags: upstream >> Justification: renders package unusable >> >> Dear Maintainer, >> >> because of faulty version number check, torbrowser-launcher cannot >> correctly handle TorBrowser 10.0 release. Now it shows the following >> error message: >> >> The version of Tor Browser you have installed is earlier than it >> should be, which could be a sign of an attack! >> >> Seems that because of this error it is not possible to install the new >> release of TorBrowser, and installation of it is run everytime when >> running torbrowser-launcher. So, torbrowser-launcher simply doesn't do >> what it should (install and run TorBrowser), which make it unusable. >> >> There is an upstream issued already reported, see #498 [#498], and >> merge request submitted. >> >> [#498] https://github.com/micahflee/torbrowser-launcher/issues/498 > > I just uploaded 0.3.2-14~exp1 to experimental. > Since I cannot launch TBB after downloading it. > (I'm using buster + backports) > Can you kindly help to confirm it works on your side? Thanks! I've installed torbrowser-launcher from experimental and can confirm that it works properly for me. Thanks for you work on it! Cheers! Lev
Bug#970768: Acknowledgement (torbrowser-launcher: error while checking version number after TorBrowser 10.0 release)
I've tested the patch proposed in upstream merge request and it solves the problem. Cheers! Lev
Bug#970768: torbrowser-launcher: error while checking version number after TorBrowser 10.0 release
Package: torbrowser-launcher Version: 0.3.2-13 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, because of faulty version number check, torbrowser-launcher cannot correctly handle TorBrowser 10.0 release. Now it shows the following error message: The version of Tor Browser you have installed is earlier than it should be, which could be a sign of an attack! Seems that because of this error it is not possible to install the new release of TorBrowser, and installation of it is run everytime when running torbrowser-launcher. So, torbrowser-launcher simply doesn't do what it should (install and run TorBrowser), which make it unusable. There is an upstream issued already reported, see #498 [#498], and merge request submitted. [#498] https://github.com/micahflee/torbrowser-launcher/issues/498 Cheers! Lev -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages torbrowser-launcher depends on: ii ca-certificates 20200601 ii gnupg 2.2.20-1 ii libdbus-glib-1-2 0.110-5 ii python3 3.8.2-3 ii python3-gpg 1.14.0-1 ii python3-pyqt5 5.15.0+dfsg-1+b1 ii python3-requests 2.23.0+dfsg-2 ii python3-socks 1.6.8+dfsg-2 Versions of packages torbrowser-launcher recommends: ii tor 0.4.4.5-1 Versions of packages torbrowser-launcher suggests: ii apparmor 2.13.4-3 -- no debconf information
Bug#969103: [Pkg-emacsen-addons] Bug#969103: elpa-flycheck: causes leak in GNU Emacs 27.1
Сб 05 сен 2020 @ 16:17 Sean Whitton : > Hello Lev, > > Thanks for the report and testing. New version uploaded. > > -- > Sean Whitton Thanks for communication with upstream and upload, Sean.
Bug#969103: seq.el: requesting an update to the version in GNU ELPA
Hi Stefan, Сб 29 авг 2020 @ 07:52 Stefan Kangas : > Stefan Kangas writes: > >> I have bumped the version of seq.el to 2.22 on the Emacs master branch. >> >> IIUC, the new version will be automatically picked up by the GNU ELPA >> scripts and available for installation within 24-48 hours. > > It turns out that seq.el is a special case where we have some > compatibility code for Emacs 24, so it needs manual intervention. > > The attached patch compiles without warnings on Emacs 26 and 27. > Unfortunately, I don't have Emacs 25 or 24 available for testing. > Could someone please help check that it's okay before I install it? Sorry for delay and thanks for your patch. I've applied your patch to seq from the ELPA git repository and tested it both in GNU Emacs 24 and GNU Emacs 25 from the Debian archive (stretch release). Here is the output: - GNU Emacs 24 $ emacs --version GNU Emacs 24.5.1 Copyright (C) 2015 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. $ LANG=C.UTF-8 emacs -batch -L . -l tests/seq-tests.el --eval "(ert-run-tests-batch-and-exit)" Loading 00debian-vars... Running 34 tests (2020-09-04 10:36:18+) passed 1/34 test-seq-concatenate passed 2/34 test-seq-contains passed 3/34 test-seq-count passed 4/34 test-seq-difference passed 5/34 test-seq-drop passed 6/34 test-seq-drop-while passed 7/34 test-seq-empty-p passed 8/34 test-seq-every-p passed 9/34 test-seq-filter passed 10/34 test-seq-find passed 11/34 test-seq-group-by passed 12/34 test-seq-intersection passed 13/34 test-seq-into passed 14/34 test-seq-into-and-identity passed 15/34 test-seq-let passed 16/34 test-seq-map-indexed passed 17/34 test-seq-mapcat passed 18/34 test-seq-mapn passed 19/34 test-seq-mapn-circular-lists passed 20/34 test-seq-min-max passed 21/34 test-seq-partition passed 22/34 test-seq-position passed 23/34 test-seq-random-elt-signal-on-empty passed 24/34 test-seq-random-elt-take-all passed 25/34 test-seq-reduce passed 26/34 test-seq-remove passed 27/34 test-seq-reverse passed 28/34 test-seq-some passed 29/34 test-seq-sort passed 30/34 test-seq-sort-by passed 31/34 test-seq-subseq passed 32/34 test-seq-take passed 33/34 test-seq-take-while passed 34/34 test-seq-uniq Ran 34 tests, 34 results as expected (2020-09-04 10:36:18+) - GNU Emacs 25 $ emacs --version GNU Emacs 25.1.1 Copyright (C) 2016 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of GNU Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. $ LANG=C.UTF-8 emacs -batch -L . -l tests/seq-tests.el --eval "(ert-run-tests-batch-and-exit)" Loading 00debian-vars... seq-25.el: ‘seq-contains’ is an obsolete generic function (as of 27.1); use ‘seq-contains-p’ instead. Running 34 tests (2020-09-04 10:41:15+) passed 1/34 test-seq-concatenate passed 2/34 test-seq-contains passed 3/34 test-seq-count passed 4/34 test-seq-difference passed 5/34 test-seq-drop passed 6/34 test-seq-drop-while passed 7/34 test-seq-empty-p passed 8/34 test-seq-every-p passed 9/34 test-seq-filter passed 10/34 test-seq-find passed 11/34 test-seq-group-by passed 12/34 test-seq-intersection passed 13/34 test-seq-into passed 14/34 test-seq-into-and-identity passed 15/34 test-seq-let passed 16/34 test-seq-map-indexed passed 17/34 test-seq-mapcat passed 18/34 test-seq-mapn passed 19/34 test-seq-mapn-circular-lists passed 20/34 test-seq-min-max passed 21/34 test-seq-partition passed 22/34 test-seq-position passed 23/34 test-seq-random-elt-signal-on-empty passed 24/34 test-seq-random-elt-take-all passed 25/34 test-seq-reduce passed 26/34 test-seq-remove passed 27/34 test-seq-reverse passed 28/34 test-seq-some passed 29/34 test-seq-sort passed 30/34 test-seq-sort-by passed 31/34 test-seq-subseq passed 32/34 test-seq-take passed 33/34 test-seq-take-while passed 34/34 test-seq-uniq Ran 34 tests, 34 results as expected (2020-09-04 10:41:15+) Cheers! Lev
Bug#969462: elpa-pdf-tools: annotation editing broken with emacs 27.1
Чт 03 сен 2020 @ 10:13 David Bremner : > 3) replace the definition of display-buffer-split-below-and-attach > > (defun display-buffer-split-below-and-attach (buf alist) > "Display buffer action using `pdf-util-window-attach'." > (let ((window (selected-window)) > (height (cdr (assq 'window-height alist))) > newwin) > (when height > (when (floatp height) > (setq height (round (* height (frame-height) > (setq height (- (max height window-min-height > (setq newwin (window--display-buffer > buf > (split-window-below height) > 'window alist)) > (pdf-util-window-attach newwin window) > newwin)) I also confirm that the proposed workaround works for me. Regards, Lev
Bug#969462: elpa-pdf-tools: annotation editing broken with emacs 27.1
Hi, I can confirm the problem. When trying to add new annotation I'm getting wrong-number-of-arguments error. Please, find the debug log below: Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 5) window--display-buffer(# # window ((inhibit-same-window . t) (window-height . 0.25)) nil) display-buffer-split-below-and-attach(# ((inhibit-same-window . t) (window-height . 0.25))) display-buffer(# ((display-buffer-reuse-window display-buffer-split-below-and-attach) (inhibit-same-window . t) (window-height . 0.25))) pdf-annot-edit-contents(((buffer . #) (page . 8) (edges 0.080065 0.223485 0.19281 0.25) (type . squiggly) (id . annot-8-2) (flags . 0) (color . "#ffa500") (contents . "") (modified 24400 57626) (label . "Lev Lamberov") (subject) (opacity . 1.0) (popup-edges) (popup-is-open) (created) (markup-edges (0.080065 0.223485 0.19281 0.25 pdf-annot-default-activate-handler(((buffer . #) (page . 8) (edges 0.080065 0.223485 0.19281 0.25) (type . squiggly) (id . annot-8-2) (flags . 0) (color . "#ffa500") (contents . "") (modified 24400 57626) (label . "Lev Lamberov") (subject) (opacity . 1.0) (popup-edges) (popup-is-open) (created) (markup-edges (0.080065 0.223485 0.19281 0.25 pdf-annot-activate-annotation(((buffer . #) (page . 8) (edges 0.080065 0.223485 0.19281 0.25) (type . squiggly) (id . annot-8-2) (flags . 0) (color . "#ffa500") (contents . "") (modified 24400 57626) (label . "Lev Lamberov") (subject) (opacity . 1.0) (popup-edges) (popup-is-open) (created) (markup-edges (0.080065 0.223485 0.19281 0.25 pdf-annot-add-annotation(squiggly ((0.08607594936708861 0.23679060665362034 0.1949367088607595 0.24266144814090018)) ((color . "orange") (label . "Lev Lamberov")) 8) pdf-annot-add-markup-annotation(((0.08607594936708861 0.23679060665362034 0.1949367088607595 0.24266144814090018)) squiggly nil nil) pdf-annot-add-squiggly-markup-annotation(((0.08607594936708861 0.23679060665362034 0.1949367088607595 0.24266144814090018))) funcall-interactively(pdf-annot-add-squiggly-markup-annotation ((0.08607594936708861 0.23679060665362034 0.1949367088607595 0.24266144814090018))) #(pdf-annot-add-squiggly-markup-annotation nil nil) apply(# pdf-annot-add-squiggly-markup-annotation (nil nil)) call-interactively@ido-cr+-record-current-command(# pdf-annot-add-squiggly-markup-annotation nil nil) apply(call-interactively@ido-cr+-record-current-command # (pdf-annot-add-squiggly-markup-annotation nil nil)) call-interactively(pdf-annot-add-squiggly-markup-annotation nil nil) command-execute(pdf-annot-add-squiggly-markup-annotation) Regards, Lev
Bug#969103: elpa-flycheck: causes leak in GNU Emacs 27.1
Package: elpa-flycheck
Severity: critical
X-Debbugs-Cc: none, Lev Lamberov
User: debian-emac...@lists.debian.org
Usertags: emacs27
Dear Maintainer,
elpa-flycheck causes leak in GNU Emacs 27.1 from the Debian archive
(1:27.1+1-1, currently from experimental).
Excerpt from debug log:
Debugger entered--Lisp error: (error "Lisp nesting exceeds
‘max-lisp-eval-depth’")
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
[..]
byte-code("\302\303\304\10\305\306#\11#\207" [flycheck-error-list-format
flycheck-error-list-padding seq-reduce #f(compiled-function (offset fmt)
#) seq-subseq 0 -1] 6)
(defconst flycheck--error-list-msg-offset (byte-code
"\302\303\304\10\305\306#\11#\207" [flycheck-error-list-format
flycheck-error-list-padding seq-reduce #f(compiled-function (offset fmt)
#) seq-subseq 0 -1] 6)
("/usr/share/emacs/site-lisp/elpa/flycheck-32snapsho..." . 171725))
autoload-do-load((autoload "flycheck" "Minor mode for on-the-fly syntax
checking.\n\nWhen c..." t nil) flycheck-mode)
desktop-load-file(flycheck-mode)
With regards,
Lev
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#963727: dh-make-{elpa,perl}: move duplicate code to a library
Package: dh-make-elpa
Version: 0.18
Severity: wishlist
Hi,
dh-make-elpa is heavily based on dh-make-perl (thanks to all who
were/are involved into whis nice tool). Both share the same
object-oriented structure and some code. Recently, dh-make-elpa was
untied from dh-make-perl, so now the former doesn't depend on the
latter. But this was done by copying some code from dh-make-perl without
changes. The better option would be to move duplicate code to a library.
Fully duplicate code is in DhMake{ELPA,Perl}::Command::Packaging. That
is, duplicates are the following methods: main_file, debian_file,
get_user, get_email, get_name, get_developer, fill_maintainer, get_wnpp,
create_rules, write_source_format, backup_file, _file_r, and _file_w.
Currently, these methods are fully identical between dh-make-elpa and
dh-make-perl.
It would be nice to identify those methods which may be useful for
various (possible) implementations of dh-make- and are
unlikely to change significantly in the future. Those methods could be
moved to, say, DhMake::Packaging.
Probably, it may be beneficial to design a core functionality for
DhMake::Config too, and then refactor both dh-make-elpa and dh-make-perl
to use it and base on it. But it requires more work, and I guess should
be done rather gradually. Therefore, it is may be a goal for some
(probably, distant) future.
I would like to implement changes for both dh-make{elpa,perl}, but first
we should discuss what should be done and in which way. So, CCing Debian
Perl Group mailing list, but I think that it's better to keep the
discussion in one place, that is, in this bug report.
Cheers!
Lev
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8),
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-make-elpa depends on:
ii dh-elpa 2.0.4
ii dh-make-perl0.112
ii libarray-utils-perl 0.5-1
ii libfile-find-rule-perl 0.34-1
ii libfile-grep-perl 0.02-1
ii libgit-repository-perl 1.324-1
ii libtrycatch-perl1.003002-2+b6
ii perl5.30.3-4
Versions of packages dh-make-elpa recommends:
ii devscripts 2.20.3
dh-make-elpa suggests no packages.
-- no debconf information
Bug#963617: python-certbot: [INTL:ru] Russian translation of debconf template
Source: python-certbot Severity: wishlist Dear Maintainer, please find attached the Russian translation of debconf template. Cheers! Lev Lamberov -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled ru.po Description: Russian translation of debconf template
Bug#962819: RFP: foliate -- simple and modern GTK eBook reader
Hi Jonathan, Пн 15 июн 2020 @ 21:20 Jonathan Carter : > On 2020/06/14 18:17, Lev Lamberov wrote: >> * Package name: foliate > > An ITP for this package already exists: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945270 Yep, I saw merge request by Sean Whitton. > Some initial work: > https://salsa.debian.org/debian/foliate Thanks for your work on it! > I've been meaning to get to it, but have been really busy recently, if > you'd like to finish it up please go ahead. Unfortunately, I don't feel competent to mess with Javascript. Sorry. I sent my RFP request as a possible user of Foliate, not maintainer. Cheers! Lev
Bug#962819: RFP: foliate -- simple and modern GTK eBook reader
Package: wnpp Severity: wishlist * Package name: foliate Version : 2.2.1 Upstream Author : John Factotum * URL or Web page : https://johnfactotum.github.io/foliate/ * License : GPL-3+ Programming Lang: Javascipt Description : simple and modern GTK eBook reader A simple and modern GTK eBook viewer, built with GJS and Epub.js. Its features: - Supports EPUB, Mobipocket, Kindle, FictionBook, and comic book archive formats - Single-column, two-column, or continuous scrolling layouts - Adjust font, line-spacing, and margins - Customize colors and brightness - Auto-hyphenation - Skeuomorphic mode - Auto-hide cursor and window controls - Supports right-to-left and vertical text - Table of contents menu or sidebar - Find in book - Progress slider, with chapter marks - Reading time estimates - Zoom in on and rotate images - Open footnotes in popovers - Trackpad gestures—use two-finger swipe to turn the page - Open multiple books at the same time, or open the same file in multiple windows - Reading progress, bookmarks, and annotations stored in your XDG data directory as plain JSON files, so you can backup or sync them easily - Learn More - Search annotations - Export annotations to plain text, HTML, Markdown, and more - Look up words in Wiktionary, Wikipedia, or offline DICT and StarDict dictionaries - Translate passages with Google Translate - Text-to-speech with eSpeak NG, Festival, or other engines - Get books online from OPDS feeds
Bug#962599: ITP: adaptive-wrap-el -- smart line-wrapping with wrap-prefix
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: adaptive-wrap-el Version : 0.7 Upstream Author : Stephen Berman , Stefan Monnier * URL or Web page : https://elpa.gnu.org/packages/adaptive-wrap.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : smart line-wrapping with wrap-prefix This package provides the `adaptive-wrap-prefix-mode' minor mode which sets the wrap-prefix property on the fly so that single-long-line paragraphs get word-wrapped in a way similar to what you'd get with M-q using adaptive-fill-mode, but without actually changing the buffer's text.
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas,
Сб 06 июн 2020 @ 23:02 Jonas Smedegaard :
> Quoting Lev Lamberov (2020-06-03 12:20:14)
>> Пн 25 мая 2020 @ 12:32 Jonas Smedegaard :
>>
>> > Quoting Lev Lamberov (2020-05-25 12:19:07)
>> >> I've just got some news from Jan Wielemaker. The next stable
>> >> release of swi-prolog, branch 8.2, is almost ready. How are your
>> >> experiments with depending on swi-prolog virtual packages going? I
>> >> would like to package the current latest version and upload it into
>> >> unstable for testing it with more installations, just to make sure
>> >> there are no serious bugs and blockers for the release of 8.2
>> >> branch.
>> >
>> > Sorry, I have not played with it at all, yet.
>> >
>> > Hope to find/make time for it later today. Will let you know when I
>> > do!
>>
>> A couple days ago I uploaded new stable release of swi-prolog, 8.2.0,
>> into unstable. This branch of swi-prolog will stay for a long period
>> of time. Quite possible that it will be in Debian stable, since I
>> don't think we'll see another stable release of swi-prolog before the
>> coming freeze.
>>
>> Could you please upload eye rebuilt against swi-prolog 8.2.0?
>> Currently swi-prolog are going to be removed from testing on June 22
>> because of RC bug in 8.1.29, and there are some other packages
>> depending on swi-prolog which are going to be removed too.
>>
>> Also, it would be nice if you can switch dependency on swi-prolog to
>> one of its virtual packages. There are
>> swi-prolog-abi-2-67-4369f15b-de23899e and swi-prolog-abi-foreign-2
>> provided by swi-prolog-core. You may find more information about ABI
>> versions in its NEWS.Debian and mentioned there upstream
>> documentation.
>
> Eye updated now, using the new virtual ABI package, but unfortunately
> couldn't move to lighter dependency than the -nox package as that has a
> needed pcre module.
>
> I hope others will benefit from the package split. Speaking of which, I
> suggest to have the core packages only suggest (not recommend) the -doc
> package.
Thanks!
Guess we still need to ask for force migration, since as I can see eye
is marked as migrating _after_ swi-prolog.
Also, it would be nice to figure out which part of swi-prolog ABI
version matters for eye. As Jan wrote there are
> 2-67-792e14f8-de23899e
>
> - Backward compatibility version of the foreign interface is 2
> - Saved state file format can be loaded when not older than 67
> - 792e14f8 is a fingerprint for the C-defined foreign predicate
> signatures.
> - de23899e is a fingerprint of the VM instructions and their
> signatures.
IIRC this version are for 8.1.30, and for 8.2.0 (currently in Debian)
the version is 2-67-4369f15b-de23899e, that is foreign predicate
signatures were changed.
IIRC eye contains some saved state files to make it run faster. So, does
just saved state format matter for eye? If so, I'll make swi-prolog-core
provide something like swi-prolog-abi-states-${...}. Cause the latter
hashes are rather volatile, if I'm correct.
Jos, Jan, could you give a hint on what matters for eye and which kind
of Provides is better to have for it? The goal is to make swi-prolog
updates possible without the need to rebuild eye each time, but rebuild
still should be required in case there are some incompatible changes in
swi-prolog (which should be reflected in its ABI).
Cheers!
Lev
Bug#828154: RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim
Hi, recently I rewrote a bit my ugly spacemacs_pkg script [spacemacs_pkg] to get a list of Spacemacs packages and mark those that are maintained by Debian Emacsen team in Debian as done. Switched to parsing use-package declarations, which made it possible to get a list of packages not just in Spacemacs [spacemacs], but also in Doom Emacs [doomemacs]. Also, added some jinja2 templating, so now it outputs an HTML rather then DSV (as was required for the team's old wiki). You may look at the output at my page [my-page]. [spacemacs_pkg] https://salsa.debian.org/dogsleg/spacemacs-pkgs [spacemacs] https://github.com/syl20bnr/spacemacs [doomemacs] https://github.com/hlissner/doom-emacs [my-page] https://pimentola.ru/spacemacs/ Later I'll switch to marking as done those packages that have elpa- prefix, so statistics will be a bit better (say, agda2-mode is marked as todo because it is maintained not by the Debian Emacsen team). But I first need to find a better way to get a list of packages in unstable, which will not require changing /etc/apt/source.list and will be able to work automatically. Unfortunately, Spacemacs and Doom Emacs use use-package declarations also for loading built-in packages. Currently, I'm not quite sure what is the best way of excluding the built-in packages from the output of spacemacs_pkgs. Probably, fetching GNU Emacs source code and getting all the filenames in its lisp directory. So, need to figure out what to do. After resolving these difficulties I plan to automatically run the script on one of my server machines, so we'll have a more of less up-to-date todo list concerning packaging Spacemacs and Doom Emacs. Honestly, I don't think it's a good idea to package them as whole, but such a list still can be used as a source of interesting packages which may be added to Debian. If you have any suggestions, please let me know. Comments and patches are welcome. Cheers! Lev
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas, Пн 25 мая 2020 @ 12:32 Jonas Smedegaard : > Quoting Lev Lamberov (2020-05-25 12:19:07) >> I've just got some news from Jan Wielemaker. The next stable release >> of swi-prolog, branch 8.2, is almost ready. How are your experiments >> with depending on swi-prolog virtual packages going? I would like to >> package the current latest version and upload it into unstable for >> testing it with more installations, just to make sure there are no >> serious bugs and blockers for the release of 8.2 branch. > > Sorry, I have not played with it at all, yet. > > Hope to find/make time for it later today. Will let you know when I do! A couple days ago I uploaded new stable release of swi-prolog, 8.2.0, into unstable. This branch of swi-prolog will stay for a long period of time. Quite possible that it will be in Debian stable, since I don't think we'll see another stable release of swi-prolog before the coming freeze. Could you please upload eye rebuilt against swi-prolog 8.2.0? Currently swi-prolog are going to be removed from testing on June 22 because of RC bug in 8.1.29, and there are some other packages depending on swi-prolog which are going to be removed too. Also, it would be nice if you can switch dependency on swi-prolog to one of its virtual packages. There are swi-prolog-abi-2-67-4369f15b-de23899e and swi-prolog-abi-foreign-2 provided by swi-prolog-core. You may find more information about ABI versions in its NEWS.Debian and mentioned there upstream documentation. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Пн 01 июн 2020 @ 12:36 Nikos Tsipinakis : > On 31/05, Lev Lamberov wrote: >> Please, finalize your work, add tags and ping me. I'll upload it to the >> Debian archive. > > Merged, tagged, and pushed. Should ready to be uploaded now. Thanks for your work! Just uploaded it. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Вс 31 мая 2020 @ 17:29 Nikos Tsipinakis : > On 31/05, Lev Lamberov wrote: >> Yep, but as I understand they are in situation where some distributions >> picked their fork at the times it was not renamed to picom. Now this >> causes troubles. So the rename and migration plan. Since in Debian we >> are starting from scratch, I don't think we need these hacks. Anyway, >> migrating from compton to picom will require manually installing a new >> package, so users are already know that they need to learn about that >> new thing and to change their configuration. Alternatively, I'd choose >> update-alternatives way, but since there are almost no alternatives in >> terms of maintained X11 compositors, I personally don't think it >> deserves any time investment. > > Makes sense, will leave as-is then. > >> Ouch! And tags are also missing from your repository. Since you use gbp, >> then gbp push is to the rescue. > > That's intentional, since I'm not sure which revision will end up uploaded > currently I haven't tagged it yet to avoid force updates. > >> Will look again at the picom package this evening. > > Looking forward to it :) So, I looked into the package. Did some tweaks to d/copyright, you'll find them in MR. I think the package is ready to be uploaded. In fact, it is quite good. Thanks for your contribution! Please, finalize your work, add tags and ping me. I'll upload it to the Debian archive. Congrats! Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Вс 31 мая 2020 @ 13:27 Nikos Tsipinakis : > On 31/05, Lev Lamberov wrote: >> Good. Could you update your Salsa repository too? > > Whoops, forgot to push, updated with all the recent changes. Ouch! And tags are also missing from your repository. Since you use gbp, then gbp push is to the rescue. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Hi Nikos, Вс 31 мая 2020 @ 13:27 Nikos Tsipinakis : > On 31/05, Lev Lamberov wrote: >> Good. Could you update your Salsa repository too? > > Whoops, forgot to push, updated with all the recent changes. > >> Your d/watch needs some tweaks, because currently it detects 7.5 as the >> latest upstream version, where there is 8 (which you package). > > Fixed. > >> I'd recommend using pristine-tar. >> >> And I have a question. Why don't you import upstream versions as >> archives and not use upstream branch to track upstream master? The >> latter could make cherry-picking patches much more easy. > > This reminds me of the discussion on d-devel about the myriad ways of using > git > for debian patching. The disappointing answer is "that's the way I've done it > this far", however I haven't taken the time to explore all the different > workflows, which I do aim on doing soon. That's understandable and I'm not insisting on having upstream branch tracking upstream master. Whatever work for you. >> I: picom: spelling-error-in-binary usr/bin/picom everytime every time >> I: picom: spelling-error-in-manpage usr/share/man/man1/picom.1.gz everytime >> every time > > Fixed. > >> P: picom source: file-contains-trailing-whitespace debian/control (line 50) >> P: picom source: package-uses-old-debhelper-compat-version 12 >> P: picom source: rules-requires-root-missing > > Fixed. Cool! Thanks for your work! >> Also, do we really need to have symlinks (compton and compton-trans) >> and corresponding desktop files? Since it is a new Debian package, >> probably we can drop these. What do you think? > > You're right, for now they serve no purpose so I removed them. However, > upstream > seems to have a full migration plan from compton[1] and it looks like they do > intend on keeping backwards compatibility to some degree. So, it might be > worth > looking into the possibility of going through a migration to picom, given that > compton is unmaintained, and will inevitably bitrot. > > [1] https://github.com/yshui/picom/#migration Yep, but as I understand they are in situation where some distributions picked their fork at the times it was not renamed to picom. Now this causes troubles. So the rename and migration plan. Since in Debian we are starting from scratch, I don't think we need these hacks. Anyway, migrating from compton to picom will require manually installing a new package, so users are already know that they need to learn about that new thing and to change their configuration. Alternatively, I'd choose update-alternatives way, but since there are almost no alternatives in terms of maintained X11 compositors, I personally don't think it deserves any time investment. Will look again at the picom package this evening. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Hi Nikos, Сб 30 мая 2020 @ 13:34 Nikos Tsipinakis : > On 26/05, Lev Lamberov wrote: >> Then you could compare your packages and somehow merge them, taking best >> pieces. > > I took a look at that package and cherry-picked some improvements from there, > also added Fritz to d/copyright. I think it's ready to be uploaded now, I've > put it on mentors[1]. > > Upstream symlinks compton to picom and also installs a compton.desktop file, > so > rather than override that I opted to set a Conflict/Replaces for compton. > > [1] https://mentors.debian.net/debian/pool/main/p/picom/picom_8-1.dsc Good. Could you update your Salsa repository too? Your d/watch needs some tweaks, because currently it detects 7.5 as the latest upstream version, where there is 8 (which you package). I'd recommend using pristine-tar. And I have a question. Why don't you import upstream versions as archives and not use upstream branch to track upstream master? The latter could make cherry-picking patches much more easy. There are some lintian stuff to deal with: lintian -L ">=pedantic" ../*.changes W: picom: binary-without-manpage usr/bin/compton W: picom: binary-without-manpage usr/bin/compton-trans I: picom: desktop-entry-lacks-icon-entry usr/share/applications/picom.desktop I: picom: spelling-error-in-binary usr/bin/picom everytime every time I: picom: spelling-error-in-manpage usr/share/man/man1/picom.1.gz everytime every time I: picom source: testsuite-autopkgtest-missing P: picom source: file-contains-trailing-whitespace debian/control (line 50) P: picom source: package-uses-old-debhelper-compat-version 12 P: picom source: rules-requires-root-missing At the very least, please, add the following changes: (1) migrate to debhelper-compat=13 (in d/control), (2) add Rules-Requires-Root: no (in d/control), (3) remove trailing whitespaces from d/*. Also, do we really need to have symlinks (compton and compton-trans) and corresponding desktop files? Since it is a new Debian package, probably we can drop these. What do you think? And I have not looked into d/copyright yet. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Вт 26 мая 2020 @ 14:24 Nikos Tsipinakis : > On 26/05, Lev Lamberov wrote: >> Would be nice if you could work together on preparing picom for Debian. >> I propose Nikos to look at your current work and base on it. Then, >> please, let me know when you think it's ready, and I'll take a look. >> Please, keep me posted. > > That reached me a bit too late sadly, I've already used compton as a base to > get > a workable picom package. What remains now is the copyright file. The > complexity > here comes from the random spread of the 2 licenses. Some files are MIT from > the > compton authors, and others are MPL which is the license upstream uses now. > > Upstream uses 'SPDX-License-Identifier: [MPL-2.0 | MIT]' to specify the > license > for each file, sadly however licensecheck doesn't appear to recognize it. Then you could compare your packages and somehow merge them, taking best pieces. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Hi Fritz, Пн 25 мая 2020 @ 20:25 Fritz Reichwald : > I started to work on some packaging for it a month ago because I wanted > to try that particular piece of software. > > https://salsa.debian.org/fiete-guest/picom > > Still needs some work especially regarding the Licenses (looks not that > easy from my perspective) but works so far on my machine. > > Perhaps it helps with packaging it. Haven't looked for a sponsor by now. > But also working on other projects at the moment. Would be nice if you could work together on preparing picom for Debian. I propose Nikos to look at your current work and base on it. Then, please, let me know when you think it's ready, and I'll take a look. Please, keep me posted. Cheers! Lev
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas, I've just got some news from Jan Wielemaker. The next stable release of swi-prolog, branch 8.2, is almost ready. How are your experiments with depending on swi-prolog virtual packages going? I would like to package the current latest version and upload it into unstable for testing it with more installations, just to make sure there are no serious bugs and blockers for the release of 8.2 branch. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Hi Nikos, Вс 24 мая 2020 @ 19:24 Nikos Tsipinakis : > My initial thought was that the compton maintainer should be the one to take > this over, but it looks like[1] compton was orphaned as its maintainer moved > on > to wayland. > > In which case, I'm interested in packaging this. Looks like picom changed significantly after forking from compton, so they even changed the name, in which case I believe that it should be a separate package. By the way, I can help with it to some extent, like sponsoring uploads. Cheers! Lev
Bug#961432: RFP: picom -- lightweight compositor for X11
Package: wnpp Severity: wishlist * Package name: picom Version : 8 Upstream Author : Yuxuan Shui * URL or Web page : https://github.com/yshui/picom * License : MIT, MPL-2.0 Programming Lang: C Description : lightweight compositor for X11 picom is a composition manager for the X11, which allows clients to modify what is drawn to the screen before it happens. This composition manager implements shadows, fading, proper translucency, and more. This is forked from the original compton (which in turn is forked from xcompmgr) because it seems to have become unmaintained.
Bug#960922: O: emacs-jedi -- Python auto-completion for Emacs
Package: wnpp Severity: normal I intend to orphan the emacs-jedi package. The package description is: The package provides a Python auto-completion package for Emacs. It aims at helping your Python coding in a non-destructive way. It also helps you to find information about Python objects, such as docstring, function arguments and code location. It's better to keep it under Debian Emacsen team umbrella, so in case of adopting just change the Uploader field.
