Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

Вс 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

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

Ср 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

[Lev Lamberov]

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

[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

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

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 version correc

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Lev Lamberov]

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"

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

Сб 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

[Lev Lamberov]

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

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

Чт 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

[Lev Lamberov]

Чт 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

[Lev Lamberov]

Чт 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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

Вт 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

[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

> 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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

Чт 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

[Lev Lamberov]

Чт 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

[Lev Lamberov]

Чт 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

[Lev Lamberov]

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

[Lev Lamberov]

Вс 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

[Lev Lamberov]

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

[Lev Lamberov]

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 

Bug#954673: (no subject)

[Lev Lamberov]

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)

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

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 

Bug#921450: (no subject)

[Lev Lamberov]

> > 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)

[Lev Lamberov]

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

[Lev Lamberov]

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)

[Lev Lamberov]

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  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 

Bug#911626: Explicit dependency on elpa-s

[Lev Lamberov]

Чт 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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

Hi Adrian,

Вс 14 янв 2018 @ 16:06 Adrian Bunk <b...@debian.org>:
> *** 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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

Hi Adrian,

Ср 15 ноя 2017 @ 08:06 Adrian Bunk <b...@debian.org>:
> 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=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=powerpc
> https://buildd.debian.org/status/logs.php?pkg=swi-prolog=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

[Lev Lamberov]

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=powerpc=7.6.1%2Bdfsg-2=1510047696=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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

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 <lu...@debian.org
>>>>>
>>>>
>>>> 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

[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 <lu...@debian.org
>>>>
>>>
>>> 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

[Lev Lamberov]

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 <lu...@debian.org>
> 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

[Lev Lamberov]

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

[Lev Lamberov]

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

[Lev Lamberov]

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)

[Lev Lamberov]

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

[Lev Lamberov]

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 

Bug#814431: tests fail on i386

[Lev Lamberov]

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

[Lev Lamberov]

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]  [814a08cd] ? dump_stack+0x41/0x51
[   21.047966]  [8105ba72] ? warn_slowpath_common+0x72/0x90
[   21.047972]  [8105bad7] ? warn_slowpath_fmt+0x47/0x50
[   21.047988]  [a02ca6dc] ? ttm_bo_force_list_clean+0x3c/0xb0 [ttm]
[   21.048001]  [a02cf6a9] ? ttm_bo_man_takedown+0x29/0x60 [ttm]
[   21.048042]  [a0353e2a] ? radeon_ttm_fini+0xaa/0x170 [radeon]
[   21.048077]  [a03547e9] ? radeon_bo_fini+0x9/0x20 [radeon]
[   21.048121]  [a039cd1a] ? evergreen_fini+0x9a/0xc0 [radeon]
[   21.048150]  [a0339e31] ? radeon_device_fini+0x31/0x100 [radeon]
[   21.048181]  [a033bc04] ? radeon_driver_unload_kms+0x44/0x60 
[radeon]
[   21.048201]  [a028af61] ? drm_dev_unregister+0x21/0xd0 [drm]
[   21.048219]  [a028b042] ? drm_put_dev+0x32/0x60 [drm]
[   21.048228]  [812a1cde] ? pci_device_remove+0x2e/0xa0
[   21.048237]  [81354845] ? __device_release_driver+0x75/0xf0
[   21.048244]  [813548d9] ? device_release_driver+0x19/0x30
[   21.048250]  [8129c0ad] ? pci_stop_bus_device+0x8d/0xb0
[   21.048257]  [8129c1c9] ? pci_stop_and_remove_bus_device+0x9/0x20
[   21.048264]  [812b47d0] ? pciehp_unconfigure_device+0xa0/0x1a0
[   21.048270]  [812b411b] ? pciehp_disable_slot+0x5b/0x1f0
[   21.048277]  [812b4329] ? pciehp_power_thread+0x79/0xe0
[   21.048285]  [81074c2d] ? process_one_work+0x16d/0x420
[   21.048291]  [810757f6] ? worker_thread+0x116/0x3b0
[   21.048298]  [810756e0] ? rescuer_thread+0x330/0x330
[   21.048304]  [8107bae1] ? kthread+0xc1/0xe0
[   21.048310]  [8107ba20] ? kthread_create_on_node+0x180/0x180
[   21.048318]  [814ada4c] ? ret_from_fork+0x7c/0xb0
[   21.048324]  [8107ba20] ? kthread_create_on_node+0x180/0x180
[   21.048328

Bug#711415: this affects jessie but not wheezy, right?

[Lev Lamberov]

2013/6/7 Holger Levsen hol...@layer-acht.org

 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

[Lev Lamberov]

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 module
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