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#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, 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#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#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#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#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#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#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#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#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#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#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#960341: swi-prolog-core,swi-prolog-core-packages: missing Breaks+Replaces: swi-prolog-nox (<< 8.1.30)
Hi, Пн 11 мая 2020 @ 22:56 Andreas Beckmann : > Package: swi-prolog-core,swi-prolog-core-packages > Version: 8.1.30+dfsg-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. > It installed fine in 'sid', then the upgrade to 'experimental' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces these changes are in git already. So, pending... Cheers! Lev Lamberov
Bug#960131: swi-prolog: flaky autopkgtest: test set "file" ... aborted
Hi, Сб 09 мая 2020 @ 20:59 Paul Gevers : > Source: swi-prolog > Version: 8.1.29+dfsg-2 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > You package has an autopkgtest, great. However, it seems to regularly > fail [1] on both amd64 and arm64. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. Please either fix the test to be more robust, or use the "flaky" > restriction for the offending test until a solution has been found. > > I copied the output at the bottom of this report. All the failing tests > that I inspected look like it. > > I'll have the migration software ignore the results of your autopkgtest > until this bug is fixed. > > Paul > > [1] https://ci.debian.net/user/britney/jobs?package=swi-prolog > > https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/5373683/log.gz > > Running test set "file" > (2329).(2332).(2335).(2338).(2341).(2343).(2346).(2348).(2350).(2353).(2357)[Thread > 1 (main) at Fri May 8 15:26:09 2020] > /build/swi-prolog-Chg12z/swi-prolog-8.1.29+dfsg/src/os/pl-os.c:1093: > deleteCanonicalDir: Assertion failed: 0 > C-stack trace labeled "assert_fail": > [0] PL_strtod() at ??:? [0x7f51fc9d36f1] > [1] __assert_fail() at ??:? [0x7f51fc991e16] > [2] PL_get_file_nameW() at ??:? [0x7f51fc9bd6a0] > [3] PL_get_file_nameW() at ??:? [0x7f51fc9bdba9] > [4] PL_get_file_nameW() at ??:? [0x7f51fc9bde80] > [5] FreeMemory() at ??:? [0x7f51fc9bee4b] > [6] PopTty() at ??:? [0x7f51fc9c0307] > [7] PL_get_file_name() at ??:? [0x7f51fc9bb48f] > [8] PL_next_solution() at ??:? [0x7f51fc907836] > [9] pl_skip_list3_va() at ??:? [0x7f51fc9465cf] > [10] pl_skip_list3_va() at ??:? [0x7f51fc946e3b] > [11] PL_initialise() at ??:? [0x7f51fc989a9c] > [12] /usr/bin/swipl(+0x10a7) [0x55ca1e9350a7] > [13] __libc_start_main() at ??:? [0x7f51fc71be0b] > [14] /usr/bin/swipl(+0x10fa) [0x55ca1e9350fa] > Aborted this should be fixed in 8.1.30+dfsg-1 currently in NEW queue. It was uploaded to experimental due to introduction of some changes to packaging, but upload to unstable will follow shortly after it gets accepted. Cheers! Lev
Bug#949537: (no subject)
Hi, Since elfeed 3.3.0-2 elfeed-web is shipped in contrib, not main, so I downgrade this bug report to normal. In future, when all elfeed-web dependencies will be available in main, this bug may be closed. Regards, Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Чт 30 апр 2020 @ 14:56 Jan Wielemaker : > On 4/30/20 2:50 PM, Jonas Smedegaard wrote: >> Quoting Lev Lamberov (2020-04-30 14:40:53) >>> Чт 30 апр 2020 @ 14:06 Jan Wielemaker : >>> >>>> On 4/30/20 1:41 PM, Jonas Smedegaard wrote: >>>>> I think we can use the format almost as-is - just replacing the >>>>> leading "swipl-" with "swi-prolog-abi-". >>>> >>>> I think adding "abi" makes sense. I can replace "swipl" with the >>>> package name, which is "swi-prolog" for Debian. >>> >>> I'm thinking about something like as follows: >>> >>> Provides: swi-prolog-abi-$(swipl:ABI) >>> >>> where $(swipl:ABI) will be set in d/rules in override_dh_gencontrol >>> target, so actually it doesn't matter what is the original output of >>> swipl --abi_version, since we have sed and other tools to make it as >>> we like. What do you think, Jonas? >> >> I agree with Lev. That is what I tried to say above as well (that we >> can _take_ it as-is and will need to massage it only slightly), but I >> see now that it can just as easily be read as meaning the opposite (that >> we would need a slightly different format). >> >> So to (try) clarify: I think it is *perfect* usable for Debian that >> upstream code emits "swipl-2-67-792e14f8-de23899e" when asked for its >> ABI. > > I did change it now to be $SWIPL_PKG_NAME-abi-*, where the default > SWIPL_PKG_NAME is derived from $SWIPL_INSTALL_DIR if it contains > something usable and "swipl" otherwise (some installations set this > to "."). > > I don't think you care too much. Unless there is a real need to > change I'll keep it that way. It is nicely informative. If you > just want the numbers you can delete `^.*-abi-`. Sure, that's what we need. Thanks, Jan! Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Чт 30 апр 2020 @ 14:06 Jan Wielemaker : > On 4/30/20 1:41 PM, Jonas Smedegaard wrote: >> I think we can use the format almost as-is - just replacing the leading >> "swipl-" with "swi-prolog-abi-". > > I think adding "abi" makes sense. I can replace "swipl" with the > package name, which is "swi-prolog" for Debian. I'm thinking about something like as follows: Provides: swi-prolog-abi-$(swipl:ABI) where $(swipl:ABI) will be set in d/rules in override_dh_gencontrol target, so actually it doesn't matter what is the original output of swipl --abi_version, since we have sed and other tools to make it as we like. What do you think, Jonas? Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Чт 30 апр 2020 @ 12:42 Jonas Smedegaard : > Quoting Jan Wielemaker (2020-04-30 11:40:32) >> On 4/28/20 5:26 PM, Jonas Smedegaard wrote: >> > Quoting Jan Wielemaker (2020-04-28 16:56:30) >> >> >> That is worth a try. I guess that implies that generating >> >> SWI-Prolog (as package) also generates this hash. What kind of >> >> support would be needed from SWI-Prolog to make this work? Some >> >> script/command to create this hash for a particular system? >> > >> > Thanks for your interest in this challenge :-) >> > >> > Yes, if ABI is computed during build then what would be helpful is >> > to extend that to expose the computed ABI as a single string. Maybe >> > add it as an additional note in output of "swipl --version"? >> > >> > Or if possible to (re)compute at runtime then just document that, >> > for us distribution maintainers to integrate into our packaging >> > routines. >> >> I think I cover this nicely now: >> >> janw (linux; master) 68_> swipl --abi_version >> swipl-2-67-792e14f8-de23899e >> >> There is a section in the docs explaining the various binary ABIs and >> what aspects rely on them. There is a new function PL_version() in >> the C api that can be used to query the versions individually. >> The above says: >> >>- 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. >> >> Does this adequately solve your problems? Do you see other >> requirements? >> >> Can you test on this, or would you rather wait for an official >> 8.1.30? I can create that now if that is useful to speedup >> stabilizing stuff to get at 8.2.0. > > That sounds really great. Thanks! > > I _think_ above described interfaces and documentation is enough for > implementing the most elegant packaging that I can imagine. > > @Lev, would you be willing to make a development snapshot (e.g. targeted > Debian experimental) then I am fine playing with that for refining an > elegant packaging mechanism. Or if you would prefer only releasing > official code then please say so. Or say if you are too busy to playing > with this now - there is no hurry from my side :-) I would prefer next release, 8.1.30, but since I will have time for it only next week (or maybe on coming Sunday) there's no hurry for Jan too (I mean to tag 8.1.30). Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Hi, Чт 30 апр 2020 @ 11:40 Jan Wielemaker : > Hi Jonas, > > On 4/28/20 5:26 PM, Jonas Smedegaard wrote: >> Quoting Jan Wielemaker (2020-04-28 16:56:30) > >>> That is worth a try. I guess that implies that generating SWI-Prolog >>> (as package) also generates this hash. What kind of support would be >>> needed from SWI-Prolog to make this work? Some script/command to >>> create this hash for a particular system? >> >> Thanks for your interest in this challenge :-) >> >> Yes, if ABI is computed during build then what would be helpful is to >> extend that to expose the computed ABI as a single string. Maybe add it >> as an additional note in output of "swipl --version"? >> >> Or if possible to (re)compute at runtime then just document that, for us >> distribution maintainers to integrate into our packaging routines. > > I think I cover this nicely now: > > janw (linux; master) 68_> swipl --abi_version > swipl-2-67-792e14f8-de23899e > > There is a section in the docs explaining the various binary ABIs > and what aspects rely on them. There is a new function PL_version() > in the C api that can be used to query the versions individually. > The above says: > >- 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. That's nice. Thanks for your work! Jonas, what do you think about the format? I looked into your examples (uwsgi-plugin-php and asterisk-espeak), these packages use alphanumeric strings as hashes; and IIRC haskell packages also use alphanumeric hashes (but significantly shorter). Of cource we can drop dashes and 'swipl' from the output of swipl --abi_version during build. Or it's better to have alphanumeric string as output of swipl --abi_version? Jan, is this hash computed only for Core_system cmake component or other components are involved too? Please, could you take a look into #959027. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959027 Jan, in case you'd like to contribute into discussion of #959027, please let's keep it separate from this (#958419) bug report. In this case please CC 958...@bugs.debian.org. Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Jan, Вт 28 апр 2020 @ 16:56 Jan Wielemaker : >> Debian packaging of Asterisk and uWSGI uses such ABI hash towards third >> party plugins, to alow them to be rebuilt as infrequently as possible. >> See e.g. https://packages.debian.org/buster/uwsgi-plugin-php and >> https://packages.debian.org/buster/asterisk-espeak (notice they depend >> only indirectly on uwsgi/asterisk through a virtual ABI package name). > > That is worth a try. I guess that implies that generating SWI-Prolog > (as package) also generates this hash. What kind of support would be > needed from SWI-Prolog to make this work? Some script/command to create > this hash for a particular system? > >> Let me emphasize that I do *not* consider this an important issue: Makes >> sense if you simply consider your upstream official release version _is_ >> the "ABI", and if we in Debian choose to carry a patch which breaks that >> "ABI" then that's our headache, not yours. > > In practice, surely for now, this is just as good. The next version > packaged with Debian is typically the next stable release, which almost > always breaks full compatibility of the ABI wrt the previous stable. Do you mean stable branches (like 8.0.x vs. 8.2.x) or revisions of a given stable branch (8.0.1 vs. 8.0.2 vs. 8.0.3)? I personally would expect no changes of ABI in a given stable branch and I think it is what is typically expected. I mean no new features => no ABI change, no? Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Вт 28 апр 2020 @ 16:30 Lev Lamberov : > Вт 28 апр 2020 @ 13:11 Jan Wielemaker : > >> Hi Lev, >> >> I most wanted to get Jos in the loop as the developer of eye. Packagers >> working together with developers/maintainers saves a lot of work :) > > Awww... so, CCing Jos De Roo. > > Jos, could you be so kind to take a look at the #958561 Debian bug > report concerning swi-prolog and eye. You can find it there: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958561 Oops! Sorry, I sent a wrong link. The relevant bug report is #958419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958419 >> On 4/28/20 12:49 PM, Lev Lamberov wrote: >>> Hi Jan, >>> >>> Вт 28 апр 2020 @ 11:22 Jan Wielemaker : >>> >>>> Hi Lev, Jos, >>>> >>>> For Jos, the problem is that eye installs as a SWI-Prolog saved state, >>>> which is highly version dependent and this is difficult to deal with >>>> given the Debian dependency and upgrade policy (Lev, hope this is the >>>> right summary, please correct if not). >>>> >>>> I has a little look at eye and I wonder why we need the state. eye.pl >>>> isn't that big and loads in about 0.12 sec on my machine. Without a >>>> state, eye seems to run easily using the simple script >>>> >>>> swipl -g main /path/to/eye.pl "$@" >>>> >>>> Or by installing eye.pl as the actual executable and start is using >>>> >>>> #!/bin/env swipl >>>> >>>> and use somewhere in the file >>>> >>>> :- initialization(main,main). >>>> >>>> Would it make sense to go this route? If not, why not? Is the >>>> somewhat longer startup time an issue? >>>> >>>>Thanks --- Jan >>> >>> I'm sending your message to the bug report and to Jonas Smedegaard. >>> Please, send your further replies to 958...@bugs.debian.org >>> >>> Cheers! >>> Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Вт 28 апр 2020 @ 13:11 Jan Wielemaker : > Hi Lev, > > I most wanted to get Jos in the loop as the developer of eye. Packagers > working together with developers/maintainers saves a lot of work :) Awww... so, CCing Jos De Roo. Jos, could you be so kind to take a look at the #958561 Debian bug report concerning swi-prolog and eye. You can find it there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958561 > On 4/28/20 12:49 PM, Lev Lamberov wrote: >> Hi Jan, >> >> Вт 28 апр 2020 @ 11:22 Jan Wielemaker : >> >>> Hi Lev, Jos, >>> >>> For Jos, the problem is that eye installs as a SWI-Prolog saved state, >>> which is highly version dependent and this is difficult to deal with >>> given the Debian dependency and upgrade policy (Lev, hope this is the >>> right summary, please correct if not). >>> >>> I has a little look at eye and I wonder why we need the state. eye.pl >>> isn't that big and loads in about 0.12 sec on my machine. Without a >>> state, eye seems to run easily using the simple script >>> >>> swipl -g main /path/to/eye.pl "$@" >>> >>> Or by installing eye.pl as the actual executable and start is using >>> >>> #!/bin/env swipl >>> >>> and use somewhere in the file >>> >>> :- initialization(main,main). >>> >>> Would it make sense to go this route? If not, why not? Is the >>> somewhat longer startup time an issue? >>> >>> Thanks --- Jan >> >> I'm sending your message to the bug report and to Jonas Smedegaard. >> Please, send your further replies to 958...@bugs.debian.org >> >> Cheers! >> Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Jan, Вт 28 апр 2020 @ 11:22 Jan Wielemaker : > Hi Lev, Jos, > > For Jos, the problem is that eye installs as a SWI-Prolog saved state, > which is highly version dependent and this is difficult to deal with > given the Debian dependency and upgrade policy (Lev, hope this is the > right summary, please correct if not). > > I has a little look at eye and I wonder why we need the state. eye.pl > isn't that big and loads in about 0.12 sec on my machine. Without a > state, eye seems to run easily using the simple script > > swipl -g main /path/to/eye.pl "$@" > > Or by installing eye.pl as the actual executable and start is using > > #!/bin/env swipl > > and use somewhere in the file > > :- initialization(main,main). > > Would it make sense to go this route? If not, why not? Is the > somewhat longer startup time an issue? > > Thanks --- Jan I'm sending your message to the bug report and to Jonas Smedegaard. Please, send your further replies to 958...@bugs.debian.org Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Hi, I've got the following response from swi-prolog upstream about the issue: Вс 26 апр 2020 @ 09:30 Jan Wielemaker : > Need to think a bit about the ABI issue. Basically, saved states are > incompatible between versions, although you can have some luck on > closely related versions. There are two sources of trouble: change to > the VM instruction set and changed interfaces for internal foreign > predicates that require matching changes to the Prolog layer. > > Applications can ship themselves as .qlf file instead of saved states to > avoid the second, although that may be complicated. The first is > unavoidable unless I would go for strictly backward compatible changes > to the VM. I don't think that is going to happen soon. The VM detects > the incompatibility by adding a hash of the VM instructions and their > declarations to the state. > > The normal way to deal with this (I guess) would be to distribute as > source and do the saved state generation as part of the installation > process. > > Finally, you can enable versioned lib directories such that SWI-Prolog > is installed in /usr/lib/swipl- and you can have multiple > versions installed (and have the links from /usr/bin for swipl, etc > select the current version). States though can depend on a particular > version. This is much like Java, no? Cheers! Lev
Bug#958419: fixed in eye 20.0411.2226~ds-1
Чт 23 апр 2020 @ 14:15 Jonas Smedegaard : >> Ohhh, I see. Let me upload (source-only) 8.1.29 to unstable. Will be OK >> for you? > > If I understand the situation correctly, then this is a bug in how eye > is packaged: A prolog image is dumped during build and shipped as the > executable for eye. That image makes starting eye faster, but requires > same version of prolog. > > My current thinking is that no change is needed from prolog: Instead, > eye must be tightened to depend on same version of prolog as was used to > build the image (and then each new release of prolog needs a binNMU of > eye). > > Does that sound correct to you? Looks like you're correct. Another thing that disturb me is that eye downloads test data from github repository while testing. So, change in tests upstream may break stuff in Debian even without any change in the Debian archive. But maybe I'm wrong about volatility of upstream test data. What do you think? Regards, Lev
Bug#958419: fixed in eye 20.0411.2226~ds-1
Чт 23 апр 2020 @ 13:05 Jonas Smedegaard : > Quoting Jonas Smedegaard (2020-04-23 12:56:23) >> Quoting Lev Lamberov (2020-04-23 12:15:12) >> > Чт 23 апр 2020 @ 11:58 Jonas Smedegaard : >> > >> > > Quoting Lev Lamberov (2020-04-23 11:38:36) >> > >> > >> Чт 23 апр 2020 @ 10:59 Paul Gevers : >> > >> > >> > [Release team member hat on] >> > >> > >> > >> > On 21-04-2020 23:48, Debian FTP Masters wrote: >> > >> >> eye (20.0411.2226~ds-1) unstable; urgency=medium >> > >> >> . >> > >> >>[ upstream ] >> > >> >>* new release(s) >> > >> >> + FIXED: process_create/3: stderr was sent to stdout. >> > >> >>closes: Bug#958419, thanks to Paul Gevers >> > >> > >> > >> > It seems that this fix works with swi-prolog in unstable, but not >> > >> > with swi-prolog in testing. Which means that you're missing a >> > >> > versioned (test) dependency somewhere. Now *both* packages are not >> > >> > migrating. If this is *only* an autopkgtest issue, I'm willing to >> > >> > trigger the combination manually, but I prefer you fix the (test) >> > >> > dependencies. >> > >> >> > >> one of the reasons why swi-prolog does not migrate to testing is >> > >> binary upload, I will prepare source-only upload of the latest >> > >> upstream version in the next couple of days. >> > > >> > > That would be nice, but seems unrelated to the issue with eye. >> > > >> > > @Lev: Do you have an ida why eye fails like this: >> > > >> > > incompatible VM-signature (file: 0xde23899e; Prolog: 0x10c53d6a)] >> > > >> > > See bottom of >> > > https://ci.debian.net/data/autopkgtest/testing/amd64/e/eye/5106659/log.gz >> > >> > Hmmm... I'm not sure, but my guess is as follows. Since (1) parts of >> > tests are downloaded during testing, and (2) as I can see upstream >> > developers of eye recently changed tests to comply with swi-prolog >> > 8.1.28 (see, upstream commit >> > eb3f074a11c8be9d82950f7a98c5d1d12fcc0254), (3) testing currently >> > contains swi-prolog 8.0.3 and autopkgtests fail with it, and (4) eye >> > in unstable (with swi-prolog 8.1.28) passes autopkgtests, then I think >> > that to fix it we need newer swi-prolog in testing. >> >> Ohh, the test failure I reference was for _testing_ - I thought it was >> for _unstable_ and was puzzled why it also failed there. >> >> Yes, I agree that this looks like just an autopkgtest issue (but makes >> me wonder if eye should include Build-Using:). > > No wait: It causes "FATAL ERROR" of "incompatible VM-signature" when an > image shipped with eye was produced by a different version of swi-prolog > than is currently installed. That's a different issue which requires > eye to tighten its dependency on swi-prolog-nox. Ohhh, I see. Let me upload (source-only) 8.1.29 to unstable. Will be OK for you? Regards, Lev
Bug#958419: fixed in eye 20.0411.2226~ds-1
Чт 23 апр 2020 @ 11:58 Jonas Smedegaard : > Quoting Lev Lamberov (2020-04-23 11:38:36) >> Чт 23 апр 2020 @ 10:59 Paul Gevers : >> > [Release team member hat on] >> > >> > On 21-04-2020 23:48, Debian FTP Masters wrote: >> >> eye (20.0411.2226~ds-1) unstable; urgency=medium >> >> . >> >>[ upstream ] >> >>* new release(s) >> >> + FIXED: process_create/3: stderr was sent to stdout. >> >>closes: Bug#958419, thanks to Paul Gevers >> > >> > It seems that this fix works with swi-prolog in unstable, but not >> > with swi-prolog in testing. Which means that you're missing a >> > versioned (test) dependency somewhere. Now *both* packages are not >> > migrating. If this is *only* an autopkgtest issue, I'm willing to >> > trigger the combination manually, but I prefer you fix the (test) >> > dependencies. >> >> one of the reasons why swi-prolog does not migrate to testing is >> binary upload, I will prepare source-only upload of the latest >> upstream version in the next couple of days. > > That would be nice, but seems unrelated to the issue with eye. > > @Lev: Do you have an ida why eye fails like this: > > incompatible VM-signature (file: 0xde23899e; Prolog: 0x10c53d6a)] > > See bottom of > https://ci.debian.net/data/autopkgtest/testing/amd64/e/eye/5106659/log.gz Hmmm... I'm not sure, but my guess is as follows. Since (1) parts of tests are downloaded during testing, and (2) as I can see upstream developers of eye recently changed tests to comply with swi-prolog 8.1.28 (see, upstream commit eb3f074a11c8be9d82950f7a98c5d1d12fcc0254), (3) testing currently contains swi-prolog 8.0.3 and autopkgtests fail with it, and (4) eye in unstable (with swi-prolog 8.1.28) passes autopkgtests, then I think that to fix it we need newer swi-prolog in testing. Regards, Lev
Bug#958419: fixed in eye 20.0411.2226~ds-1
Hi, Чт 23 апр 2020 @ 10:59 Paul Gevers : > [Release team member hat on] > > On 21-04-2020 23:48, Debian FTP Masters wrote: >> eye (20.0411.2226~ds-1) unstable; urgency=medium >> . >>[ upstream ] >>* new release(s) >> + FIXED: process_create/3: stderr was sent to stdout. >>closes: Bug#958419, thanks to Paul Gevers > > It seems that this fix works with swi-prolog in unstable, but not with > swi-prolog in testing. Which means that you're missing a versioned > (test) dependency somewhere. Now *both* packages are not migrating. If > this is *only* an autopkgtest issue, I'm willing to trigger the > combination manually, but I prefer you fix the (test) dependencies. one of the reasons why swi-prolog does not migrate to testing is binary upload, I will prepare source-only upload of the latest upstream version in the next couple of days. Regards, Lev
Bug#955979: does not work with magit in Debian
Вс 05 апр 2020 @ 13:40 Antoine Beaupre : > magit-todos, as packaged in Debian, does not work. It seems to assume > a magit version that is not present in Debian. When I run "M-x > magit-todos" I get the error: > >magit-todos-list-internal: Symbol’s function definition is void: > magit-setup-buffer Hmm... I mean hitting M-x magit-todos-mode runs fine and TODOs are listed in magit status correctly, but I agree that magit-todos-list throws the error as you specified. Regards, Lev
Bug#955979: does not work with magit in Debian
Hi Antoine, Вс 05 апр 2020 @ 13:40 Antoine Beaupre : > Package: elpa-magit-todos > Version: 1.5.2-1 > Severity: grave > > magit-todos, as packaged in Debian, does not work. It seems to assume > a magit version that is not present in Debian. When I run "M-x > magit-todos" I get the error: > >magit-todos-list-internal: Symbol’s function definition is void: > magit-setup-buffer > > The debugger trace is this: > > Debugger entered--Lisp error: (void-function magit-setup-buffer) > magit-setup-buffer(magit-todos-list-mode) > magit-todos-list-internal("/home/anarcat/src/tor/tsa-misc/") > magit-todos-list(nil) > funcall-interactively(magit-todos-list nil) > call-interactively(magit-todos-list record nil) > command-execute(magit-todos-list record) > execute-extended-command(nil "magit-todos-list" nil) > funcall-interactively(execute-extended-command nil "magit-todos-list" nil) > call-interactively(execute-extended-command nil nil) > command-execute(execute-extended-command) > > I reported this in the ITP but it seems that problem was either > disregarded or overlooked: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951450#10 > > It's also been reported upstream: > > https://github.com/alphapapa/magit-todos/issues/87 > > The response there was: > >> Unfortunately, that doesn't matter. Magit is a moving target, and >> it's not feasible for me to produce "stable" versions in sync with >> Magit "stable" versions. Magit does not coordinate its changes with >> me. So when Magit suddenly breaks this package for 99% of users >> without warning, I have to fix it, and that means breaking things >> for older Magit versions. >> >> If you insist on not upgrading Magit, you could use a version of >> this package from before that change was made. > > It's too bad this newer version was packaged instead of a working > version because now it would be difficult to reverse this without > adding an epoch to the version number. > > In any case, this is definitely broken right now in Debian, unless we > install magit from *outside* Debian. If that's what is expected of > magit-todos users, the package does not belong in main (because it > requires packages outside of main) but rather contrib. > > Alternatively, maybe we can just hope magit will be released upstream > (as it's been promised since november) and that this will fix itself > when it lands in Debian (#952560), but I have kind of stopped hoping > for that at this point... :/ I use Emacs and Emacs packages only from the Debian archive. No packages are installed from MELPA or _any_ other source. And... magit-todos works for me just fine. I'm not sure why, but I simply cannot reproduce this bug report. Regards, Lev
Bug#955359: swi-prolog: FTBFS on mips: error due to ATOMIC
Package: swi-prolog Version: 8.1.26+dfsg-2 Severity: serious Dear Maintainer, current development version of swi-prolog fails to build from source [log]: [ 84%] Building C object packages/xpce/CMakeFiles/plugin_pl2xpce.dir/swipl/pcecall.c.o cd /<>/build/packages/xpce && /usr/bin/cc -Dplugin_pl2xpce_EXPORTS -I/<>/build/packages/xpce -I/<>/packages/xpce/src -I/usr/include/freetype2 -I/<>/src/os -I/<>/src -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -DHAVE_CONFIG_H -DSWI -D__SWI_PROLOG__ -o CMakeFiles/plugin_pl2xpce.dir/swipl/pcecall.c.o -c /<>/packages/xpce/swipl/pcecall.c [ 84%] Linking C shared module pl2xpce.so cd /<>/build/packages/xpce && /usr/bin/cmake -E cmake_link_script CMakeFiles/plugin_pl2xpce.dir/link.txt --verbose=1 /usr/bin/cc -fPIC -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -shared -o pl2xpce.so CMakeFiles/plugin_pl2xpce.dir/src/adt/area.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/atable.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/attribute.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/bool.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/chain.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/chaintable.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/constant.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/date.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/dict.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/dictitem.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/hashtable.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/number.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/point.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/real.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/region.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/sheet.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/size.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/tuple.c.o CMakeFiles/plugin_pl2xpce.dir/src/adt/vector.c.o CMakeFiles/plugin_pl2xpce.dir/src/ari/equation.c.o CMakeFiles/plugin_pl2xpce.dir/src/ari/expression.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/clickgesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/conngesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/event.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/eventnode.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/eventtree.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/gesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/handler.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/handlergroup.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/modifier.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/movegesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/mvolgesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/popupgesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/recogniser.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/resizegesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/rzolgesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/edittextgest.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/browserselgesture.c.o CMakeFiles/plugin_pl2xpce.dir/src/evt/resizetabslice.c.o CMakeFiles/plugin_pl2xpce.dir/src/gnu/getdate.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/arc.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/arrow.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/bitmap.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/box.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/circle.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/colour.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/connection.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/cursor.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/device.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/ellipse.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/figure.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/font.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/format.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/graphical.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/handle.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/image.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/joint.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/line.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/link.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/listbrowser.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/node.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/path.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/postscript.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/scrollbar.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/text.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/tree.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/visual.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/pixmap.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/elevation.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/pen.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/draw.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/colourmap.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/bezier.c.o CMakeFiles/plugin_pl2xpce.dir/src/gra/hsv.c.o CMakeFiles/plugin_pl2xpce.dir/src/itf/c.c.o CMakeFiles/plugin_pl2xpce.dir/src/itf/host.c.o CMakeFiles/plugin_pl2xpce.dir/src/itf/interface.c.o CMakeFiles/plugin_pl2xpce.dir/src/itf
Bug#954673: (no subject)
Looks like, the bug is caused by openssl. Tests run fine with openssl 1.1.1d, but fail with openssl 1.1.1e (currently in unstable). Moreover, looks like openssl 1.1.1e causes lots of regressions in other packages [regressions]. [regressions] https://qa.debian.org/excuses.php?package=openssl
Bug#954673: (no subject)
The problem is caused by ssl test. Disabling it makes build successful. Unfortunately, I was not able to find Debian CI logs (typical URLs and search for swi-prolog at [CI] give 404) for swi-prolog to figure out which change led to the bug. [CI] https://ci.debian.net/
Bug#952126: (no subject)
Hmmm, looks like the bug is caused by undo-tree, since when elpa-undo-tree 0.6.4-3 is installed tests are passed correctly. Moreover, when new upstream version of undo-tree is used (0.7.4, not currently in Debian) tests also are passed correctly.
Bug#952126: emacs-bind-map: FTBFS: Errors while processing: elpa-evil sbuild-build-depends-main-dummy
Tags: help Hi, Вс 23 фев 2020 @ 13:56 Lucas Nussbaum : > Source: emacs-bind-map > Version: 1.1.1-4 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200222 ftbfs-bullseye > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): >> +--+ >> | Install package build dependencies >> | >> +--+ >> Install elpa-evil for emacs >> install/evil-1.2.12: Handling install of emacsen flavor emacs >> install/evil-1.2.12: byte-compiling for emacs >> Loading ‘evil-common’: unescaped character literals `?(', `?)', `?[', `?]' >> detected! >> >> In toplevel form: >> evil-commands.el:557:1:Warning: unescaped character literals `?(', `?)' >> detected! >> evil-commands.el:562:1:Warning: unescaped character literals `?(', `?)' >> detected! >> >> In evil-jump-to-tag: >> evil-commands.el:719:33:Warning: ‘find-tag’ is an obsolete function (as of >> 25.1); use ‘xref-find-definitions’ instead. >> evil-commands.el:723:20:Warning: ‘find-tag’ is an obsolete function (as of >> 25.1); use ‘xref-find-definitions’ instead. >> evil-commands.el:1131:1:Warning: unescaped character literals `?(', `?)' >> detected! >> evil-commands.el:1136:1:Warning: unescaped character literals `?(', `?)' >> detected! >> >> In evil-get-register: >> evil-common.el:2027:35:Warning: ‘x-get-selection’ is an obsolete function (as >> of 25.1); use ‘gui-get-selection’ instead. >> >> In evil-set-register: >> evil-common.el:2112:6:Warning: ‘x-set-selection’ is an obsolete function (as >> of 25.1); use ‘gui-set-selection’ instead. >> evil-common.el:2112:33:Warning: ‘x-set-selection’ is an obsolete function (as >> of 25.1); use ‘gui-set-selection’ instead. >> evil-common.el:3626:1:Warning: unescaped character literals `?(', `?)', `?[', >> `?]' detected! >> Loading ‘evil-commands’: unescaped character literals `?(', `?)' detected! >> >> In toplevel form: >> evil.el:137:1:Error: Wrong type argument: number-or-marker-p, nil >> ERROR: install script from elpa-evil package failed >> dpkg: error processing package elpa-evil (--configure): >> installed elpa-evil package post-installation script subprocess returned >> error exit status 1 >> dpkg: dependency problems prevent configuration of >> sbuild-build-depends-main-dummy: >> sbuild-build-depends-main-dummy depends on elpa-evil; however: >> Package elpa-evil is not configured yet. >> >> dpkg: error processing package sbuild-build-depends-main-dummy (--configure): >> dependency problems - leaving unconfigured >> Errors were encountered while processing: >> elpa-evil >> sbuild-build-depends-main-dummy >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> apt-get failed. > The full build log is available from: >http://qa-logs.debian.net/2020/02/22/emacs-bind-map_1.1.1-4_unstable.log evil-el was updated since then, but I'm experiencing strange problem here: rebuilding against evil-el 1.12.17-1 fails both in sbuild and pbuilder environments. The relevant part of build log is as follows: make[1]: Leaving directory '/build/emacs-bind-map-1.1.1' dh_elpa_test emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -l bind-map-tests.el --eval \(ert-run-tests-batch-and-exit\) Wrong type argument: number-or-marker-p, nil dh_elpa_test: error: emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -l bind-map-tests.el --eval \(ert-run-tests-batch-and-exit\) returned exit code 255 make: *** [debian/rules:4: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 But running tests on real hardware with the same versions of packages is successful, see: $ dh_elpa_test emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -l bind-map-tests.el --eval \(ert-run-tests-batch-and-exit\) Running 6 tests (2020-02-24 11:35:36+0500) passed 1/6 bind-map-test-global-keys passed 2/6 bind-map-test-major-inheritance passed 3/6 bind-map-test-major-mode-keys passed 4/6 bind-map-test-minor-inheritance passed 5/6 bind-map-test-minor-mode-keys passed 6/6 bind-map-test-multiple-declarations Ran 6 tests, 6 results as expected (2020-02-24 11:35:36+0500) So, I'm a bit lost and appreciate any h
Bug#921450: (no subject)
> > I've tried to downgrade to fetchmail 6.4.0~beta4-1 (from > > snapshot.debian.org), tried to upgrade to glibc 2.28-6, tried to reboot > > with another version of Linux kernel, and the problem is still there. > > Do you mean 6.4.0~beta4-1 worked right previously? Ouch, sorry for misleading comment. Version 6.3.26-3 worked properly and it still works properly now (I've downgrade to it). I thought that 6.4.0~beta4-1 was in testing, but it was only in experimental. Regards, Lev Lamberov
Bug#921450: (no subject)
Hi, I have the same problem, I run testing + some bits from unstable on this machine. $ env LC_ALL=C fetchmail -v -v -v --nodetach --nosyslog -b 2 Old UID list from mail.riseup.net: Scratch list of UIDs: fetchmail: removing stale lockfile fetchmail: 6.4.0.beta4 querying mail.riseup.net (protocol POP3) at Wed Feb 6 11:42:01 2019: poll started Trying to connect to 198.252.153.22/110...connected. fetchmail: POP3< +OK howdy, ready. fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< CAPA fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< PIPELINING fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< STLS fetchmail: POP3< SASL fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK Begin TLS negotiation now. fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: COMODO CA Limited fetchmail: Issuer CommonName: COMODO RSA Certification Authority fetchmail: Subject CommonName: COMODO RSA Certification Authority fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: COMODO CA Limited fetchmail: Issuer CommonName: COMODO RSA Certification Authority fetchmail: Subject CommonName: COMODO RSA Domain Validation Secure Server CA fetchmail: Server certificate: fetchmail: Issuer Organization: COMODO CA Limited fetchmail: Issuer CommonName: COMODO RSA Domain Validation Secure Server CA fetchmail: Subject CommonName: *.riseup.net fetchmail: Subject Alternative Name: *.riseup.net fetchmail: Subject Alternative Name: riseup.net fetchmail: mail.riseup.net key fingerprint: A6:13:14:09:4D:61:97:D9:D0:A1:E1:C7:2D:F4:4E:6E fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES128-GCM-SHA256, 128/128 secret/processed bits fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< CAPA fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< PIPELINING fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< USER fetchmail: POP3< SASL PLAIN LOGIN fetchmail: POP3< . fetchmail: mail.riseup.net: upgrade to TLS succeeded. fetchmail: POP3> USER dogsleg fetchmail: POP3< +OK fetchmail: POP3> PASS * fetchmail: POP3< +OK Logged in. fetchmail: selecting or re-polling default folder fetchmail: POP3> STAT fetchmail: POP3< +OK 29 272396 29 messages for dogsleg at mail.riseup.net (272396 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 6319 fetchmail: POP3> RETR 1 fetchmail: POP3< +OK 6319 octets reading message dogs...@mail.riseup.net:1 of 29 (6319 octets) About to rewrite Return-Path: ... ...rewritten version is Return-Path: . About to rewrite From: Paul Wise ... ...rewritten version is From: Paul Wise . About to rewrite To: debian-de...@lists.debian.org... ...rewritten version is To: debian-de...@lists.debian.org. About to rewrite Resent-From: debian-de...@lists.debian.org... ...rewritten version is Resent-From: debian-de...@lists.debian.org. About to rewrite Resent-Sender: debian-devel-requ...@lists.debian.org... ...rewritten version is Resent-Sender: debian-devel-requ...@lists.debian.org. Trying to connect to ::1/25...connection failed. fetchmail: connection to localhost:smtp [::1/25] failed: Connection refused. Trying to connect to 127.0.0.1/25...connected. fetchmail: SMTP< 220 urfu-thinkpad ESMTP Exim 4.92-RC5 Wed, 06 Feb 2019 11:42:05 +0500 fetchmail: SMTP> EHLO mail.riseup.net fetchmail: SMTP< 250-urfu-thinkpad Hello mail.riseup.net [127.0.0.1] fetchmail: SMTP< 250-SIZE 52428800 fetchmail: SMTP< 250-8BITMIME fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-CHUNKING fetchmail: SMTP< 250-PRDR fetchmail: SMTP< 250 HELP fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM: BODY=8BITMIME SIZE=6319 fetchmail: SMTP< 250 OK fetchmail: SMTP> RCPT TO: fetchmail: SMTP< 250 Accepted fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself #** fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 OK id=1grGuL-0002s8-Oa flushed fetchmail: POP3> DELE 1 fetchmail: POP3< +OK Marked to be deleted. Segmentation fault I've tried to downgrade to fetchmail 6.4.0~beta4-1 (from snapshot.debian.org), tried to upgrade to glibc 2.28-6, tried to reboot with another version of Linux kernel, and the problem is still there. Since the problem is a recent one, I've tried to investigate, which packages were upgraded on my machine recently: $ which-pkg-broke fetchmail perl-base Tue Feb 5 11:20:26 2019 libdb5.3:amd64 Wed Feb 6 11:02:03 2019 libc6:amd64Wed Feb 6 11:20:43 2019 fetchmail Wed Feb 6 11:41:49 2019 Changes in libc6 reflect my attempts to upgrade to glibc 2.28-6 and changes in fetchmail reflect my attempts to downgrade (which I mentioned before). With regards, Lev Lamberov
Bug#919476: swi-prolog stopped building on s390x
Hi Matthias, this bug is closed now, but I'd still like to clarify a bit on the topic. First of all, 8.0.0 release of SWI-Prolog is a new stable release. It will receive only security updates. Previous stable release, 7.6.4 (the last revision of stable branch 7.6.0), was released in Jan 2018. It will not be supported anymore. And branch 8.0.0 is claimed by upstream to be much more stable than 7.6.0. Second, when it comes to s390x I'd like to stress that SWI-Prolog cannot be built on it because it build-depends on libunwind, which is not built for s390x since some time ago. Old binaries on s390x was removed, and now swi-prolog don't list s390x as a target architecture (s390x is not listed as a target architecture for libunwind either). Third, about rdeps. Problems arose for ppl and logol. Problems for logol were resolved, but the problem of ppl is more complicated. The last release of ppl was in Feb 2016, and I don't think they closely track SWI-Prolog releases. Regards, Lev
Bug#916807: (no subject)
I've ran tests against the source code from upstream's repository and got even more failures: Ran 532 tests, 523 results as expected, 7 unexpected, 2 skipped (2019-01-06 01:42:08+0500) 122 expected failures 7 unexpected results: FAILED haskell-cabal-compute-checksum-1 FAILED haskell-cabal-compute-next-prev-section-1 FAILED haskell-cabal-enum-targets-1 FAILED haskell-cabal-enum-targets-2 FAILED haskell-cabal-get-field-1 FAILED haskell-process-type-test-1 FAILED haskell-process-type-test-2 2 skipped results: SKIPPED haskell-indent-in-comment-1 SKIPPED haskell-indentation-altj-comment Please, find the check-ert log attached. Regards, Lev ===File /home/dogsleg/tmp/haskell-mode/check-ert.log $ emacs --version GNU Emacs 26.1 Copyright (C) 2018 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 make check-ert EMACS check-ert Running 532 tests (2019-01-06 01:40:45+0500) passed1/532 backward-sexp passed2/532 bos-270 passed3/532 commented-out-import-parse Process is not running, so running directly. passed4/532 do-cabal-no-process passed5/532 empty-buffer passed6/532 file-structure passed7/532 fill-comment-1 failed8/532 fill-comment-10 passed9/532 fill-comment-11 passed 10/532 fill-comment-12 passed 11/532 fill-comment-2 passed 12/532 fill-comment-3 passed 13/532 fill-comment-4 passed 14/532 fill-comment-5 passed 15/532 fill-comment-6 passed 16/532 fill-comment-7 failed 17/532 fill-comment-8 failed 18/532 fill-comment-9 passed 19/532 fill-comment-haddock-1 passed 20/532 fill-comment-haddock-2 passed 21/532 forward-sexp-function-1 passed 22/532 forward-sexp-function-2 passed 23/532 full-import-parse Could not… passed 24/532 goto-first-error-after Could not… passed 25/532 goto-first-error-before Could not… passed 26/532 goto-first-error-between No further notes from Haskell compiler. passed 27/532 goto-next-error-after Could not… passed 28/532 goto-next-error-before Could not… passed 29/532 goto-next-error-between Could not… passed 30/532 goto-prev-error-after No further notes from Haskell compiler. passed 31/532 goto-prev-error-before Could not… passed 32/532 goto-prev-error-between passed 33/532 haskell-backward-sexp passed 34/532 haskell-c2hs-alignof-hook passed 35/532 haskell-c2hs-basic-import-hook passed 36/532 haskell-c2hs-class-hook passed 37/532 haskell-c2hs-const-hook failed 38/532 haskell-c2hs-enum-define-hook failed 39/532 haskell-c2hs-enum-hook passed 40/532 haskell-c2hs-full-context-hook passed 41/532 haskell-c2hs-full-pointer-hook passed 42/532 haskell-c2hs-get-hook passed 43/532 haskell-c2hs-nongnu-hook passed 44/532 haskell-c2hs-offsetof-hook passed 45/532 haskell-c2hs-pointer-hook-1 passed 46/532 haskell-c2hs-pointer-hook-2 passed 47/532 haskell-c2hs-pure-call-hook passed 48/532 haskell-c2hs-pure-fun-hook passed 49/532 haskell-c2hs-qualified-import-hook passed 50/532 haskell-c2hs-set-hook passed 51/532 haskell-c2hs-sizeof-hook passed 52/532 haskell-c2hs-type-hook passed 53/532 haskell-c2hs-typedef-hook passed 54/532 haskell-c2hs-unsafe-call-hook passed 55/532 haskell-c2hs-unsafe-fun-hook failed 56/532 haskell-cabal-add-dependency-01 passed 57/532 haskell-cabal-add-dependency-02 passed 58/532 haskell-cabal-add-dependency-03 passed 59/532 haskell-cabal-add-dependency-04 Test haskell-cabal-compute-checksum-1 backtrace: file-name-directory(nil) (let ((scriptDir (file-name-directory (or (symbol-file 'haskell-caba (closure (t) nil (let ((scriptDir (file-name-directory (or (symbol-f ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name haskell-cabal-compute-checksum-1 :doc ert-run-or-rerun-test(#s(ert--stats :selector t :tests [#s(ert-test ert-run-tests(t #f(compiled-function (event-type &rest event-args) # ert-run-tests-batch(nil) ert-run-tests-batch-and-exit() command-line-1(("--eval" "(add-to-list 'load-path (expand-file-name command-line() normal-top-level() Test haskell-cabal-compute-checksum-1 condition: (wrong-type-argument stringp nil) FAILED 60/532 haskell-cabal-compute-checksum-1 Test haskell-cabal-compute-next-prev-section-1 backtrace: file-name-directory(nil) (let ((scriptDir (file-name-directory (or (symbol-file 'haskell-caba (closure (t) nil (let ((scriptDir (file-name-directory (or (symbol-f ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name ha
Bug#911626: Explicit dependency on elpa-s
Чт 01 ноя 2018 @ 14:51 David Bremner : > - add versioned depends on elpa-f to force it to upgrade to buster first Hmmm, by the way... Maybe it's a good idea to always add versioned depends (like >=) on other elpa-packages automatically by dh_elpa? Like if during a given build there is, say 1.0-1 of elpa-foo dependency is available in unstable, then the resulting package will depend on elpa-foo (>= 1.0-1).
Bug#911626: Explicit dependency on elpa-s
Sorry, for delay with my answer. > I'm not sure I see the whole picture yet, but I guess that > > 1) elpa-f in stretch depends on s-el (instead of elpa-s) > 2) elpa-vimish-fold in buster is a new style dh_elpa using package > that only looks at elpa packages for depends. > > Maybe an explicit depends on elpa-s by elpa-vimish-fold would help? Since vimish-fold do not depend on s directly (but f does, and vimish-fold depends on f) this bug concerns rather f, not vimish-fold. But I agree that probably it is easier to explicitly add elpa-s as a dependency of vimish-fold. I can upload an updated package if there are no objections or other proposals. Regards, Lev
Bug#887155: swi-prolog FTBFS on armel/armhf/mipsel: Not enough resources: no_memory
Hi Benjamin, Пт 27 апр 2018 @ 17:06 Benjamin Lorenz : > It seems a fix for this bug was merged into the upstream stable > repository some time ago: > https://github.com/SWI-Prolog/swipl/commit/3923765d56e5 > > I have an unstable i386 VM where I could reproduce these memory errors > and adding this to the patches resolves it. > > Since there is still no new upstream release and to avoid the > autoremoval of this (+ a few downstream packages [1]), could you try to > create a new debian release for 7.6.4 with this patch and the one for > #893421. > > With these two patches the package was successfully built with java 9 on > the VM where I previously had these memory errors. Thank you for the information! I'll upload the fixed package in the next couple of hours. Regards, Lev
Bug#893421: swi-prolog FTBFS with openjdk-9
Hi Benjamin, Ср 04 апр 2018 @ 12:31 Benjamin Lorenz : > The configure script of the swi-prolog jpl package only checks whether > lib/$arch/server or jre/lib/$arch/server exists but the $arch > subdirectory was removed in openjdk9. Because of the failed check the > LDFLAGS are missing the correct directories for libjava.so and related > libraries. > I have created a pull request to for this: > https://github.com/SWI-Prolog/packages-jpl/pull/8 I see your fix was merged upstream. Thanks for your contribution! > I have tried this on i386 and the package now compiles but make check > then fails with the same errors as in #887155. Yes, #887155 is a tricky one. Hope it will be better in the next upstream release. Cheers! Lev
Bug#893421: swi-prolog FTBFS with openjdk-9
Dear Jan, building of SWI-Prolog with openjdk-9 fails with the error below. I haven't yet looked into it, just want to let you know. I'll try to find some time for it in the next few days. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/swi-prolog.html https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/swi-prolog_7.6.4+dfsg-1.rbuild.log ... /usr/bin/make -C packages/jpl DESTDIR=/build/1st/swi-prolog-7.6.4+dfsg/debian/swi-prolog-java PL=/build/1st/swi-prolog-7.6.4+dfsg/src/swipl.sh PLEXE=/build/1st/swi-prolog-7.6.4+dfsg/src/swipl.sh PLBASE=/usr/lib/swi-prolog/ install < /dev/null make[2]: Entering directory '/build/1st/swi-prolog-7.6.4+dfsg' make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. gcc -shared -rdynamic -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -pthread -L/build/1st/swi-prolog-7.6.4+dfsg/src/../lib/amd64 -o libjpl.so src/c/jpl.o -ljava -lverify -ljvm -lswipl /usr/bin/ld: cannot find -ljava /usr/bin/ld: cannot find -lverify /usr/bin/ld: cannot find -ljvm collect2: error: ld returned 1 exit status make[2]: *** [Makefile:44: libjpl.so] Error 1 Regards, Lev
Bug#887155: swi-prolog FTBFS on armel/armhf/mipsel: Not enough resources: no_memory
Hi Adrian, Вс 14 янв 2018 @ 16:06 Adrian Bunk : > *** 10 tests failed *** > Makefile:418: recipe for target 'check' failed > make[2]: *** [check] Error 1 thanks for your report! The problem is already known and forwarded upstream. Upstream also faced the same problem in their Ubuntu's PPAs. Regards, Lev Lamberov
Bug#886161: auto-complete-el: extremely outdated, blocks packaging of new Emacs packages
Package: auto-complete-el Severity: grave Justification: renders package unusable Dear Maintainer, Debian ships auto-complete-el package version 1.3.1. It was firstly uploaded in July 6th, 2010. The package was not anyway significantly updated for more than 7 years. Since 2010 upstream moved development of auto-complete to GitHub [0] and released three new versions (the latest version for now is 1.5.1, released on March 30th, 2016). Moreover two of these versions (1.4.0 and 1.5.0) contained significant changes, that break backwards compatibility with 1.3.0 branch. Most of the Emacs packages which depend on auto-complete and are available on MELPA require auto-complete version >1.4.0. It makes auto-complete in Debian completely useless, it may also introduce conflicts and unexpected behavior on the systems with auto-complete installed from the Debian archive together with auto-complete installed from, say, MELPA. Having outdated version of auto-complete in Debian makes integration of new Emacs packages (which depend on auto-complete) impossible or at least troublesome. The most notable examples are jedi [1], ein [2], and spacemacs [3], which was requested to be packaged for Debian. Since the mentioned Emacs packages depend on auto-complete version >1.4.0, having outdated auto-complete package in Debian blocks the whole process of their integration. Moreover auto-complete package in Debian uses the obsolete installation mechanisms, where better mechanisms are available with the help of dh_elpa and dh_elpa_test [4]. The package uses deprecated debhelper compat version [5]; has outdated (and non-working) watch file [6]; depends on Emacs versions, which are unavailable anymore in Debian versions (emacs22, emacs23) [7], which previously caused problems with the removal of these versions of Emacs (see referenced bugreport). The version of auto-complete in the Debian archive may work for some outdated and/or obsolete code (Emacs configurations and Emacs packages), but not for the new and modern one. I have not went through the commit history of the auto-complete upstream, but notably that GitHub Issues contains information on more than 200 closed issues (remember, that migration to GitHub happend after the upload of auto-complete 1.3.1 to the Debian archive). Even in the case that only 25% of these issues were real bugs we have about 50 bugs non-fixed in the Debian package. Which is a grave, so to speak. With regards, Lev Lamberov [0] https://github.com/auto-complete/auto-complete/ [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829589 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695278 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828154 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872616 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873389 [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872614 [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689312 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores) 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) Versions of packages auto-complete-el depends on: ii emacs 47.0 auto-complete-el recommends no packages. auto-complete-el suggests no packages.
Bug#881756: swi-prolog: FTBFS on mips: Build killed with signal TERM
Hi James, Пт 17 ноя 2017 @ 17:15 James Cowgill : > IMO the best solution is to remove all the ATOMIC_GENERATION_HACK code > and use libatomic, but this will take some porting work because > swi-prolog uses the old __sync primitives everywhere. > > I have attached a hack which marks _generation and _last_generation as > volatile. This seems to work but isn't a long term solution. Thanks for your input! I've informed upstream about the issue you found and your suggestions. Regards, Lev
Bug#881756: swi-prolog: FTBFS on mips: Build killed with signal TERM
Hi Adrian, Ср 15 ноя 2017 @ 08:06 Adrian Bunk : > On Wed, Nov 15, 2017 at 12:55:12AM +0500, Lev Lamberov wrote: >>... >> The most strange thing is that 7.6.1-1 built successfully on mips. The >> only difference between 7.6.1-1 and 7.6.1-2 is that java tests (only >> tests) are disabled now (via debian/rules). > > 7.3.33+dfsg-1 failed the same way a year ago: > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=mips > > I would not rule out that this might be an old bug causing random build > failures, that either just happened twice in the row or became more > likely due to some change somewhere. In the past there were some wierd build problems from time to time. You can find logs and build history in usual place. These build problems were unreproducible and were typically resolved with rebuilding. Not that time. >> Note that the 7.6.1-2 >> version builds successfully on mipsel and mips64el (little-endian), but >> fails on mips (big-endian). > >> The similar problem occures on powerpc [1][2], which also works in >> big-endian mode: >>... > > Same randomness on powerpcspe, and both have it already with 7.6.1+dfsg-1: > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpc > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpcspe True. And as I can see powerpcspe also works in big-endian mode. I've informed upstream about the issue. Their answer is as follows: > Interesting. I doubt this is due to big/little endian. The main issue > seems to be weaker read/write ordering constraints that break our > lock-free data structures, resulting in more or less random bugs. A > number of the tests stress these parts of the system. The test_cgc > is one of them, while I'm pretty sure there are no endian issues in > that code. > > Keri and I did a lot of stress-testing and code reviewing for this after > we discovered this was the reason for a crash on ARM. The same problem > easily reproduced on powerpc. After the fixes for 7.6.1, a couple of > runs of the test suite passed ok on powerpc. I only ran many iterations > for tests that causes problems before. Upstream will try to run these stress tests on powerpc and mips again, but they claim that they were not able to reproduce some issues with these tests in 7.6.1. Guess the issue may be related to Debian build environment. At least, I cannot think of any other reason that 7.6.1-1 was built successfully on mips and 7.6.1-2 failed, where the only one change is disabling Java tests (due to CVE-2017-1000364). I've uploaded 7.6.1-2 on the next day after 7.6.1-1 upload. Cheers! Lev
Bug#881756: swi-prolog: FTBFS on mips: Build killed with signal TERM
Package: swi-prolog Version: 7.4.2+dfsg-2 Severity: serious Justification: fails to build from source The mips build of swi-prolog failed: Running scripts from core ... E: Build killed with signal TERM after 360 minutes of inactivity The bug can be reproduced on mips porterbox. Hitting Ctrl+X gives: Interrupted test cgc:shift_cgc at /home/dogsleg/swi-prolog-7.6.1+dfsg/src/Tests/core/test_cgc.pl:102 The most strange thing is that 7.6.1-1 built successfully on mips. The only difference between 7.6.1-1 and 7.6.1-2 is that java tests (only tests) are disabled now (via debian/rules). Note that the 7.6.1-2 version builds successfully on mipsel and mips64el (little-endian), but fails on mips (big-endian). The similar problem occures on powerpc [1][2], which also works in big-endian mode: Running scripts from core Makefile:418: recipe for target 'check' failed make[2]: *** [check] Terminated [1] https://buildd.debian.org/status/fetch.php?pkg=swi-prolog&arch=powerpc&ver=7.6.1%2Bdfsg-2&stamp=1510047696&raw=0 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869701 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) 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) Versions of packages swi-prolog depends on: ii swi-prolog-nox 7.4.2+dfsg-2 ii swi-prolog-x7.4.2+dfsg-2 swi-prolog recommends no packages. swi-prolog suggests no packages. -- no debconf information
Bug#873372: anything-el: package is outdated and obsolete, removal required
Package: anything-el Severity: grave Dear Maintainer, the last upload of the package in question was in Nov 2014 (version 1.287-2.1), which was a NMU upload, but the last maintainer's upload was in Mar 2011 (version 1.287-2). Since then upstream renamed anything-el [0] to helm and released 2.8.2 in Aug 2017 [1]. Moreover, since anything-el was not maintained for a long time, helm was packaged separately in Feb 2016 using new dh-elpa infrastructure, and currently is team-maintained by pkg-emacsen [2]. The anything-el package is heavily outdated (as the indication in its source code says it is tested only with Emacs 22/23, where there's Emacs 25 in stretch, and Emacs 24 will be removed from the archive soon), don't use the modern Emacs addons infrastructure. Since according to popcon there are some (47) users of the package [3], it should become a transitional dummy package, which should depend on elpa-helm, and after some time should be removed from Debian. Alternative approach would be to remove anything-el, and build transitional dummy package from helm source package to allow migrations. Cheers! Lev Lamberov [0] https://www.emacswiki.org/emacs/Anything [1] https://github.com/emacs-helm/helm [2] https://tracker.debian.org/pkg/helm [3] https://qa.debian.org/popcon.php?package=anything-el -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) 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)
Bug#854609: swi-prolog: FTBFS on mips
Hi Sébastien, 11.02.2017 14:22, Sébastien Villemot пишет: > If swi-prolog is removed from stretch, then several reverse > dependencies will also go away (in particular sagemath and ppl > maintained by the Debian Science Team, which is what prompted me to fix > #852892). > > So I think you should not remove swi-prolog unless there is no other > option. Dropping swi-prolog-java on mips seems a reasonable fix for the > FTBFS on that arch. > > IMO, the only reason why you may want to drop swi-prolog from stretch > is if it is impossible to provide security support. If you are unsure > about this, you may want to contact the Debian Security Team. OK, I see your point. I'll drop swi-prolog-java on mips (for version 7.2.3). Cheers! Lev signature.asc Description: OpenPGP digital signature
Bug#854609: swi-prolog: FTBFS on mips
Package: swi-prolog Version: 7.2.3+dfsg-5.1 Severity: serious Justification: FTBFS Hi, something broke swi-prolog in Debian (see #852892), but it revealed another problem. Java tests fail on mips with segmentation fault. Unfortunately, 7.2 branch of swi-prolog is almost at its end of life stage and it is not supported by upstream in an appropriate manner. Currently, upstream works heavily on releasing 7.4 branch (7.4-rc1 was released two weeks ago), which as upstream puts it will be supported by security fixes for a long time and in an appropriate manner. I've tried to play with build flags, but (unfortunately!) my attempts to fix the bug were unsuccessful. So, there are simply two options: 1. Do not build swi-prolog-java on mips (as it already done on armel and armhf), and let swi-prolog enter stretch. 2. Do not let 7.2.3 version of swi-prolog enter stretch. As for me I vote for the second option, because I don't think that it is a good idea to let dead (= without upstream support and without enough competent contributors in Debian, who is interested to keep it alive) branch of some piece of software enter stable release and stay there for 2 or more years. It simply will _not_ have any good support, which I'd consider as a bad thing. My suggestion, as partly stated above, is to have that RC bug open to not let swi-prolog enter stretch. But after stretch release 7.4 (moreover 7.4 should have OpenSSL 1.1 support, which is absent in 7.2) branch of swi-prolog will be ready and I'll upload it to backports. But if there are anyone who _really_ need swi-prolog in stretch, I'm open to your suggestions and can manage with the first option. (In this case, please, do not expect good level of support of swi-prolog in stretch.) Cheers, Lev Lamberov -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages swi-prolog depends on: ii swi-prolog-nox 7.2.3+dfsg-5.1 ii swi-prolog-x7.2.3+dfsg-5.1 swi-prolog recommends no packages. Versions of packages swi-prolog suggests: pn prolog-el -- no debconf information
Bug#852892: swi-prolog: FTBFS: Test failures
Hi Sébastien, 05.02.2017 22:11, Lev Lamberov пишет: > 05.02.2017 22:02, Sébastien Villemot пишет: >> Hi Lev, >> >> Le dimanche 05 février 2017 à 20:03 +0500, Lev Lamberov a écrit : >> >>> 05.02.2017 18:37, Sébastien Villemot пишет: >>>> On Sat, 28 Jan 2017 09:27:37 +0100 Lucas Nussbaum >>>> >>>> >>>> wrote: >>>>> Source: swi-prolog >>>>> Version: 7.2.3+dfsg-5 >>>>> Severity: serious >>>>> Tags: stretch sid >>>>> User: debian...@lists.debian.org >>>>> Usertags: qa-ftbfs-20170128 qa-ftbfs >>>>> Justification: FTBFS on amd64 >>>>> During a rebuild of all packages in sid, your package failed to >>>>> build >>>> >>>> on >>>>> amd64. >>>>> >>>>> Relevant part (hopefully): >>>>>> Failed to invoke suite():java.lang.UnsatisfiedLinkError: >>>> >>>> /<>/swi-prolog-7.2.3+dfsg/packages/jpl/libjpl.so: >>>> libjsig.so: >>>> cannot open shared object file: No such file or directory >>>> >>>> I have uploaded to DELAYED/10 an NMU that fixes the issue. The >>>> debdiff >>>> is attached. >>>> >>>> Don’t hesitate to tell me if I should delay it longer (or instead >>>> shorten the delay). >>> >>> Thank you very much for your help! >>> >>> Sébastien, please, shorten the delay. Let the fix enter sid asap. ;-) >>> Thanks! >> >> Done. >> >> Unfortunately the new version FTBFS on mips. At this stage, I don't >> know if this is another manifestation of the nasty #844227, or if it is >> a genuine problem with swi-prolog. > > Thanks! > > Well, FTBFS sometimes happens with swi-prolog on mips. I'll try to > reproduce it on porterbox. In case I will not be able to reproduce it, > I'll ask to rebuild swi-prolog on mips. Unfortunately, I has able to reproduce it on mips porterbox (tried twice in a raw). So it is a real bug. A bit latter I'll try to build swi-prolog on mips porterbox without -Wl,--gc-sections. In case it will be successful, then it is really related to #844227. Best, Lev signature.asc Description: OpenPGP digital signature
Bug#852892: swi-prolog: FTBFS: Test failures
05.02.2017 22:02, Sébastien Villemot пишет: > Hi Lev, > > Le dimanche 05 février 2017 à 20:03 +0500, Lev Lamberov a écrit : > >> 05.02.2017 18:37, Sébastien Villemot пишет: >>> On Sat, 28 Jan 2017 09:27:37 +0100 Lucas Nussbaum >>> >>> >>> wrote: >>>> Source: swi-prolog >>>> Version: 7.2.3+dfsg-5 >>>> Severity: serious >>>> Tags: stretch sid >>>> User: debian...@lists.debian.org >>>> Usertags: qa-ftbfs-20170128 qa-ftbfs >>>> Justification: FTBFS on amd64 >>>> During a rebuild of all packages in sid, your package failed to >>>> build >>> >>> on >>>> amd64. >>>> >>>> Relevant part (hopefully): >>>>> Failed to invoke suite():java.lang.UnsatisfiedLinkError: >>> >>> /<>/swi-prolog-7.2.3+dfsg/packages/jpl/libjpl.so: >>> libjsig.so: >>> cannot open shared object file: No such file or directory >>> >>> I have uploaded to DELAYED/10 an NMU that fixes the issue. The >>> debdiff >>> is attached. >>> >>> Don’t hesitate to tell me if I should delay it longer (or instead >>> shorten the delay). >> >> Thank you very much for your help! >> >> Sébastien, please, shorten the delay. Let the fix enter sid asap. ;-) >> Thanks! > > Done. > > Unfortunately the new version FTBFS on mips. At this stage, I don't > know if this is another manifestation of the nasty #844227, or if it is > a genuine problem with swi-prolog. Thanks! Well, FTBFS sometimes happens with swi-prolog on mips. I'll try to reproduce it on porterbox. In case I will not be able to reproduce it, I'll ask to rebuild swi-prolog on mips. Best, Lev signature.asc Description: OpenPGP digital signature
Bug#852892: swi-prolog: FTBFS: Test failures
Hi Sébastien and Adrian, 05.02.2017 18:37, Sébastien Villemot пишет: > Control: tags -1 + patch pending > > Dear Maintainer, > > On Sat, 28 Jan 2017 09:27:37 +0100 Lucas Nussbaum > wrote: >> Source: swi-prolog >> Version: 7.2.3+dfsg-5 >> Severity: serious >> Tags: stretch sid >> User: debian...@lists.debian.org >> Usertags: qa-ftbfs-20170128 qa-ftbfs >> Justification: FTBFS on amd64 >> During a rebuild of all packages in sid, your package failed to build > on >> amd64. >> >> Relevant part (hopefully): >>> Failed to invoke suite():java.lang.UnsatisfiedLinkError: > /<>/swi-prolog-7.2.3+dfsg/packages/jpl/libjpl.so: libjsig.so: > cannot open shared object file: No such file or directory > > I have uploaded to DELAYED/10 an NMU that fixes the issue. The debdiff > is attached. > > Don’t hesitate to tell me if I should delay it longer (or instead > shorten the delay). Thank you very much for your help! Sébastien, please, shorten the delay. Let the fix enter sid asap. ;-) Thanks! Cheers! Lev Lamberov signature.asc Description: OpenPGP digital signature
Bug#845030: swi-prolog: configure does not find libssl, builds without OpenSSL support
Hi Hilko, 19.11.2016 22:11, Hilko Bengen пишет: > Source: swi-prolog > Version: 7.2.3+dfsg-4 > Severity: serious > Tags: patch > > Dear Maintainer, > > after searching for "AC_CHECK_LIB(ssl, SSL_library_init" using > codesearch.debian.net and rebuilding with OpenSSL 1.1, I found that the > OpenSSL is no longer detected and thus no longer built into the package. > > The rebuild was done on a regular sbuild setup using Debian > unstable/amd64. > > Something like the following should be enough to fix the OpenSSL > detection, however, there may be other changes necessary due to the > changed API in OpenSSL 1.1. > > - AC_CHECK_LIB(ssl, SSL_library_init, [ > + AC_CHECK_LIB(ssl, SSL_new, [ Thanks for your report! In fact it is not so easy to fix. Actually upstream already works on full OpenSSL 1.1 support, but it will surely take some time. Moreover, they need to support OpenSSL in range from 0.9.8 to 1.1, which is somewhat hard task. Cheers! Lev signature.asc Description: OpenPGP digital signature
Bug#841012: swi-prolog: FTBFS on armel/armhf: segmentation fault during the tests
17.10.2016 02:00, Emilio Pozuelo Monfort пишет: > make[3]: Leaving directory > '/«BUILDDIR»/swi-prolog-7.2.3+dfsg/packages/jpl/src/java' > if [ -r jpltest.jar ]; then \ > > LD_LIBRARY_PATH="/usr/lib/jvm/java-8-openjdk-armel/jre/lib/arm/server:/usr/lib/jvm/java-8-openjdk-armel/jre/lib/arm" > ../swipl.sh -q -f test_jpl.pl -g run_tests,halt -t 'halt(1)' ; \ > else \ > echo "No jpltest.jar; maybe junit is not installed?" ; \ > fi > JUNIT=/usr/share/java/junit.jar JAVA=java > JAVA_PRELOAD=/usr/lib/jvm/java-8-openjdk-armel/jre/lib/arm/libjsig.so > ./test-java.sh > Welcome to SWI-Prolog (Multi-threaded, 32 bits, Version 7.2.3) > Copyright (c) 1990-2015 University of Amsterdam, VU Amsterdam > SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software, > and you are welcome to redistribute it under certain conditions. > Please visit http://www.swi-prolog.org for details. > > For help, use ?- help(Topic). or ?- apropos(Word). > > > % halt > Segmentation fault Disables java support for armel and armhf. Moreover, found out that upstream do not support 32-bit architectures that do not implement 64-bit atomic increment/decrement operations. Upstream developers are not sure that it should be fixed at all. Probably, they will drop (whole) support of 32-bit platforms. Cheers! Lev signature.asc Description: OpenPGP digital signature
Bug#841012: swi-prolog: FTBFS on armel/armhf: segmentation fault during the tests
Hi Emilio, 17.10.2016 02:00, Emilio Pozuelo Monfort пишет: > Source: swi-prolog > Version: 7.2.3+dfsg-1 > Severity: serious > > Your package failed to build on armel/armhf during a rebuild: > > make[3]: Leaving directory > '/«BUILDDIR»/swi-prolog-7.2.3+dfsg/packages/jpl/src/java' > if [ -r jpltest.jar ]; then \ > > LD_LIBRARY_PATH="/usr/lib/jvm/java-8-openjdk-armel/jre/lib/arm/server:/usr/lib/jvm/java-8-openjdk-armel/jre/lib/arm" > ../swipl.sh -q -f test_jpl.pl -g run_tests,halt -t 'halt(1)' ; \ > else \ > echo "No jpltest.jar; maybe junit is not installed?" ; \ > fi > JUNIT=/usr/share/java/junit.jar JAVA=java > JAVA_PRELOAD=/usr/lib/jvm/java-8-openjdk-armel/jre/lib/arm/libjsig.so > ./test-java.sh > Welcome to SWI-Prolog (Multi-threaded, 32 bits, Version 7.2.3) > Copyright (c) 1990-2015 University of Amsterdam, VU Amsterdam > SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software, > and you are welcome to redistribute it under certain conditions. > Please visit http://www.swi-prolog.org for details. > > For help, use ?- help(Topic). or ?- apropos(Word). > > > % halt > Segmentation fault > > Full logs at https://buildd.debian.org/status/package.php?p=swi-prolog Thanks for reporting! Sometimes it happens with SWI-Prolog on "non-mainstream" architectures. Will take a look at it. Regards, Lev signature.asc Description: OpenPGP digital signature
Bug#818954: (no subject)
And here is the full log after cold start right before suspend, as reported with journalctl -b. boot.tar.gz Description: application/gzip
Bug#818954: linux-image-4.4.0-1-amd64: kernel 4.4 completely hangs right after wakeup
Package: src:linux Version: 4.4.6-1 Severity: critical Justification: breaks the whole system Dear Maintainer, running on HP Probook 655 G1 with the latest BIOS in legacy mode (not using UEFI) I experience the following problem. If I close lid, the system correctly suspends (seems like so, because of indicating lights), but after lifting up the lid it starts to resume (initializes dvd drive with a corresponding sound, turns on display and renders desktop, querying for password as usual), but some time after it completely hangs and do not respond to keyboard; only holding power button works, so it is possible only to power off the system. Before 4.4 I used to run Linux kernel 4.3 and it works perfectly (I still have 4.3 installed, because 4.4 is simply non-usable because of that problem with suspend). -- Package-specific info: ** Version: Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 20160307 (Debian 5.3.1-11) ) #1 SMP Debian 4.4.6-1 (2016-03-17) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-amd64 root=UUID=ae787034-89c4-45a8-ba05-00a348f037a1 ro quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [3.140268] radeon :00:01.0: fence driver on ring 3 use gpu addr 0x3c0c and cpu addr 0x88042b034c0c [3.140271] radeon :00:01.0: fence driver on ring 4 use gpu addr 0x3c10 and cpu addr 0x88042b034c10 [3.157922] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [3.157927] [drm] Driver supports precise vblank timestamp query. [3.157934] radeon :00:01.0: radeon: MSI limited to 32-bit [3.158811] radeon :00:01.0: radeon: using MSI. [3.159103] Bluetooth: hci0: BCM: chip id 63 [3.159498] [drm] radeon: irq initialized. [3.175910] Bluetooth: hci0: BCM20702A [3.177872] Bluetooth: hci0: BCM20702A1 (001.002.014) build [3.177903] bluetooth hci0: firmware: failed to load brcm/BCM20702A1-0a5c-21f1.hcd (-2) [3.177948] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-21f1.hcd failed with error -2 [3.177951] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-21f1.hcd not found [3.224477] wlan0: Broadcom BCM4359 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334) [3.226989] [drm] ring test on 0 succeeded in 2 usecs [3.227002] [drm] ring test on 3 succeeded in 4 usecs [3.227009] [drm] ring test on 4 succeeded in 3 usecs [3.274080] [drm] ring test on 5 succeeded in 1 usecs [3.293133] tpm_tis 00:08: TPM is disabled/deactivated (0x7) [3.295935] [drm] UVD initialized successfully. [3.298004] AVX version of gcm_enc/dec engaged. [3.298009] AES CTR mode by8 optimization enabled [3.405285] [drm] ring test on 6 succeeded in 17 usecs [3.405299] [drm] ring test on 7 succeeded in 3 usecs [3.405301] [drm] VCE initialized successfully. [3.406293] [drm] ib test on ring 0 succeeded in 0 usecs [3.406868] [drm] ib test on ring 3 succeeded in 0 usecs [3.407647] [drm] ib test on ring 4 succeeded in 0 usecs [3.424214] kvm: Nested Virtualization enabled [3.424219] kvm: Nested Paging enabled [3.428172] [drm] ib test on ring 5 succeeded [3.448867] acpi-cpufreq: overriding BIOS provided _PSD data [3.563918] input: HP WMI hotkeys as /devices/virtual/input/input25 [3.569491] wl :03:00.0 wlo1: renamed from wlan0 [3.587367] cfg80211: World regulatory domain updated: [3.587371] cfg80211: DFS Master region: unset [3.587373] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [3.587376] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [3.587378] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [3.587380] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [3.587383] cfg80211: (517 KHz - 525 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (N/A) [3.587385] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (0 s) [3.587387] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [3.587389] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [3.587390] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [3.699142] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) [3.722055] systemd-journald[241]: Received request to flush runtime journal from PID 1 [3.723315] random: nonblocking pool is initialized [3.749112] systemd-journald[241]: File /var/log/journal/9dabc51e933a4d5f82047453cd040775/system.journal corrupted or uncleanly shut down, renaming and replacing. [3.802884] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) [3.896574] r8169 :01:00.0: firmware: direct-loading fir
Bug#814431: tests fail on i386
Hi Mattias, 11.02.2016 19:38, Matthias Klose пишет: > Package: src:swi-prolog > Version: 7.2.3-1 > Severity: serious > Tags: sid stretch > > tests fail on i386: > > ERROR: /«PKGBUILDDIR»/packages/jpl/test_jpl.pl:1185: > test threads3: received error: jpl:jFindClass/2: Undefined > procedure: jpl:jni_func/3 > ERROR: /«PKGBUILDDIR»/packages/jpl/test_jpl.pl:1203: > test jref1: received error: plunit_jpl:'unit body'/2: Undefined > procedure: jpl:jni_term_to_jref/2 > ERROR: /«PKGBUILDDIR»/packages/jpl/test_jpl.pl:1213: > test jref2: received error: plunit_jpl:'unit body'/2: Undefined > procedure: jpl:jni_term_to_jref/2 > Makefile:60: recipe for target 'check_pl' failed > make[2]: *** [check_pl] Error 1 > make[2]: Leaving directory '/«PKGBUILDDIR»/packages/jpl' > debian/rules:134: recipe for target 'override_dh_auto_test' failed > make[1]: *** [override_dh_auto_test] Error 2 > make[1]: Leaving directory '/«PKGBUILDDIR»' > debian/rules:70: recipe for target 'build-arch' failed > make: *** [build-arch] Error 2 > Hmmm... As I can see it cannot find libjpl.so, because on i386 it fails to build that library, see: gcc -shared -rdynamic -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -pthread -L/«PKGBUILDDIR»/src/../lib/i386 -o libjpl.so src/c/jpl.o -ljava -lverify -ljvm -lswipl /usr/bin/ld: cannot find -ljava /usr/bin/ld: cannot find -lverify /usr/bin/ld: cannot find -ljvm collect2: error: ld returned 1 exit status Makefile:43: recipe for target 'libjpl.so' failed make[4]: *** [libjpl.so] Error 1 make[4]: *** Waiting for unfinished jobs And compare it to log for amd64: gcc -shared -rdynamic -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -pthread -L/«PKGBUILDDIR»/src/../lib/amd64 -L'/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server' -L'/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64' -o libjpl.so src/c/jpl.o -ljsig -ljava -lverify -ljvm -lswipl Something wrong with Makefile generation on i386. Will look at it. Thanks! Lev Lamberov signature.asc Description: OpenPGP digital signature
Bug#739992: linux-image-3.13-1-amd64: discrete video card not available, sometimes hangs on boot
Package: src:linux Version: 3.13.4-1 Severity: critical Justification: breaks the whole system Dear Maintainer, after installing 3.13.4-1 linux kernel I found out that discrete video card is not available. During the boot process I experience a long delay at Waiting for /dev to be fully populated stage and can see something like pciehp :00:03.0:pcie04: Device :02:00.0 already exists at :02:00, cannot hot-add After succesful booting lspci doesn't show my discrete video card and xrandr --listproviders shows only integrated video card. Sometimes kernel hangs at boot during Waiting for /dev to be fully populated stage. With 3.12.9-1 linux kernel everything works OK. Cheers! Lev Lamberov -- Package-specific info: ** Version: Linux version 3.13-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-14) ) #1 SMP Debian 3.13.4-1 (2014-02-22) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.13-1-amd64 root=UUID=1257503e-04c4-40f9-b35e-bdc8ef96c279 ro quiet radeon.audio=1 radeon.dpm=1 nmi_watchdog=0 ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 20.920652] power level 1sclk: 4 mclk: 9 vddc: 1000 vddci: 0 [ 20.920653] power level 2sclk: 6 mclk: 9 vddc: 1000 vddci: 0 [ 20.920654] status: r [ 21.038536] [drm] radeon: finishing device. [ 21.038546] [drm] Disabling audio 0 support [ 21.047750] [ cut here ] [ 21.047785] WARNING: CPU: 0 PID: 162 at /build/linux-YhyeNj/linux-3.13.4/drivers/gpu/drm/drm_mm.c:578 ttm_bo_man_takedown+0x29/0x60 [ttm]() [ 21.047789] Memory manager not clean during takedown. [ 21.047793] Modules linked in: snd_hda_codec_hdmi joydev hp_wmi sparse_keymap evdev kvm_amd kvm uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core arc4 rt2800pci rt2800mmio rt2800lib rt2x00pci rt2x00mmio rt2x00lib eeprom_93cx6 mac80211 psmouse serio_raw videodev media edac_mce_amd edac_core snd_hda_codec_idt k10temp cfg80211 rtsx_pci_ms snd_hda_intel snd_hda_codec snd_hwdep btusb bluetooth snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer snd sp5100_tco i2c_piix4 radeon ttm wmi drm_kms_helper drm hp_accel battery video lis3lv02d soundcore acpi_cpufreq input_polldev i2c_algo_bit processor button ac i2c_core memstick crc_ccitt rfkill shpchp ext4 crc16 mbcache jbd2 sd_mod crct10dif_generic sg sr_mod cdrom crc_t10dif crct10dif_common rtsx_pci_sdmmc mmc_core ehci_pci ahci libahci libata ohci_pci ohci_hcd ehci_hcd xhci_hcd scsi_mod usbcore usb_common thermal thermal_sys rtsx_pci mfd_core r8169 mii [ 21.047907] CPU: 0 PID: 162 Comm: kworker/0:2 Not tainted 3.13-1-amd64 #1 Debian 3.13.4-1 [ 21.047912] Hardware name: Hewlett-Packard HP Pavilion dv6 Notebook PC/164B, BIOS F.21 09/13/2011 [ 21.047923] Workqueue: pciehp-3 pciehp_power_thread [ 21.047927] 0009 814a08cd 880213c95c28 8105ba72 [ 21.047935] 88021685da40 880213c95c78 880214c4a848 8802141ab300 [ 21.047941] 8105bad7 a02afb80 0018 [ 21.047947] Call Trace: [ 21.047958] [] ? dump_stack+0x41/0x51 [ 21.047966] [] ? warn_slowpath_common+0x72/0x90 [ 21.047972] [] ? warn_slowpath_fmt+0x47/0x50 [ 21.047988] [] ? ttm_bo_force_list_clean+0x3c/0xb0 [ttm] [ 21.048001] [] ? ttm_bo_man_takedown+0x29/0x60 [ttm] [ 21.048042] [] ? radeon_ttm_fini+0xaa/0x170 [radeon] [ 21.048077] [] ? radeon_bo_fini+0x9/0x20 [radeon] [ 21.048121] [] ? evergreen_fini+0x9a/0xc0 [radeon] [ 21.048150] [] ? radeon_device_fini+0x31/0x100 [radeon] [ 21.048181] [] ? radeon_driver_unload_kms+0x44/0x60 [radeon] [ 21.048201] [] ? drm_dev_unregister+0x21/0xd0 [drm] [ 21.048219] [] ? drm_put_dev+0x32/0x60 [drm] [ 21.048228] [] ? pci_device_remove+0x2e/0xa0 [ 21.048237] [] ? __device_release_driver+0x75/0xf0 [ 21.048244] [] ? device_release_driver+0x19/0x30 [ 21.048250] [] ? pci_stop_bus_device+0x8d/0xb0 [ 21.048257] [] ? pci_stop_and_remove_bus_device+0x9/0x20 [ 21.048264] [] ? pciehp_unconfigure_device+0xa0/0x1a0 [ 21.048270] [] ? pciehp_disable_slot+0x5b/0x1f0 [ 21.048277] [] ? pciehp_power_thread+0x79/0xe0 [ 21.048285] [] ? process_one_work+0x16d/0x420 [ 21.048291] [] ? worker_thread+0x116/0x3b0 [ 21.048298] [] ? rescuer_thread+0x330/0x330 [ 21.048304] [] ? kthread+0xc1/0xe0 [ 21.048310] [] ? kthread_create_on_node+0x180/0x180 [ 21.048318] [] ? ret_from_fork+0x7c/0xb0 [ 21.048324] [] ? kthread_create_on_node+0x180/0x180 [ 21.048328] ---[ end trace 00e1bbb9390f5a6f ]--- [ 21.048337] [drm] radeon: ttm finalized [ 21.048343] vga_switcheroo: disabled [ 29.070286] EXT4-fs (sda1): re-mounted. Opts: (null) [ 29.453793] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 29.705845] device-mapper: uevent: version 1.0.3 [ 29.705921] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-de...@redhat.com [ 30.390362] fuse init (API version
Bug#711415: this affects jessie but not wheezy, right?
2013/6/7 Holger Levsen > control: tags -1 + moreinfo > thanks > > Hi, > > you wrote "[wicd-curses] was working before some update, now it doesn't > work." > - just to confirm: it worked under wheezy still, but some update in the > last > days broke it. Right? > Right, some update in the last days. I think that it worked last week. Cheers! Lev > cheers, > Holger, wanting to know if wheezy is affected > >
Bug#711415: wicd-curses: crashes upon start
Package: wicd-curses Version: 1.7.2.4-4 Severity: grave Justification: renders package unusable Dear Maintainer, When starting wicd-curses I'm getting the following message: ~$ wicd-curses Traceback (most recent call last): File "/usr/share/wicd/curses/wicd-curses.py", line 1063, in main() File "/usr/share/wicd/curses/wicd-curses.py", line 995, in main ui.run_wrapper(run) File "/usr/lib/python2.7/dist-packages/urwid/raw_display.py", line 242, in run_wrapper return fn() File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper return func(*args, **kargs) File "/usr/share/wicd/curses/wicd-curses.py", line 1003, in run app = appGUI() File "/usr/share/wicd/curses/wicd-curses.py", line 548, in __init__ self.wiredCB = urwid.Filler(WiredComboBox(wiredL)) File "/usr/share/wicd/curses/wicd-curses.py", line 378, in __init__ self.__super.__init__(use_enter=False) File "/usr/share/wicd/curses/curses_misc.py", line 352, in __init__ self.focus = focus AttributeError: can't set attribute It was working before some update, now it doesn't work. Fortunately, wicd-cli and wicd by itself work properly. I expect it to start and do its work. Cheers! Lev Lamberov -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wicd-curses depends on: ii python2.7.3-5 ii python-urwid 1.1.1-1 ii wicd-daemon 1.7.2.4-4 Versions of packages wicd-curses recommends: ii sudo 1.8.5p2-1+nmu1 wicd-curses suggests no packages. Versions of packages wicd-cli depends on: ii python 2.7.3-5 ii wicd-daemon 1.7.2.4-4 Versions of packages wicd-cli recommends: ii sudo 1.8.5p2-1+nmu1 Versions of packages wicd-daemon depends on: ii adduser 3.113+nmu3 ii dbus 1.6.10-1 ii debconf 1.5.50 ii ethtool 1:3.9-1 ii iproute 20120521-3+b4 ii iputils-ping 3:20121221-1 ii isc-dhcp-client 4.2.4-7 ii lsb-base 4.1+Debian11 ii net-tools1.60-25 ii psmisc 22.20-1 ii python 2.7.3-5 ii python-dbus 1.2.0-1 ii python-gobject 3.8.2-1 ii python-wicd 1.7.2.4-4 ii wireless-tools 30~pre9-8 ii wpasupplicant1.0-3+b2 Versions of packages wicd-daemon recommends: ii rfkill 0.4-2 Versions of packages wicd-daemon suggests: ii pm-utils 1.4.1-9 Versions of packages python-wicd depends on: ii python 2.7.3-5 -- debconf information: * wicd/users: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org