bug#48552: mesa 20.2.4 is not reproducible

[Bone Baboon via Bug reports for GNU Guix]

When I run `guix challenge` it shows that these versions of mesa are not
reproducible.

```
/gnu/store/2lyzzw7ybsm3s2n7fgqm17n33n62dl7c-mesa-20.2.4
/gnu/store/k72zqqiysk3qcwqj917hmlbvqs8shj0x-mesa-20.2.4
```

This looks like it could also be related to bug#43849.

`guix describe` outputs:

```
Generation 24   May 12 2021 18:06:24(current)
  guix d6aeebb
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d6aeebb23639258311fdfb9dbf5f903079fde51a
```

`guix challenge mesa` outputs:

```
/gnu/store/9624kmpsr9mcx0qb1zvbk5hpxymgk0s4-mesa-20.2.4 contents differ:
  local hash: 0ca468jgq1sgw0llsjrmk1jjny08ndhs4634yp9m9aajr4p0g8q1
  
https://ci.guix.gnu.org/nar/lzip/9624kmpsr9mcx0qb1zvbk5hpxymgk0s4-mesa-20.2.4: 
1kp0l03bdinmnzkn2xqyrl6gymzy9qrh5kbq2i8fbgxb0c1j54m7
  differing files:
/lib/dri/iris_dri.so
/lib/dri/nouveau_drv_video.so
/lib/vdpau/libvdpau_nouveau.so.1.0.0
/lib/libXvMCnouveau.so.1.0.0
/lib/libOSMesa.so.8.0.0
/lib/libvulkan_radeon.so
/lib/libxatracker.so.2.5.0

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
```

Attached is the diffoscope output.


diffoscope-mesa.txt.lz
Description: Binary data

bug#48336: kicad cannot see libngspice

[Guillaume Le Vaillant]

Christopher Howard  skribis:

> In Kicad Eeschema, if I try to use the Tools >> Simulator menu entry, I
> get an error in a pop-up window that libngspice cannot be found, and
> then the whole Kicad application closes. I see that libngspice is a
> dependency of kicad so I'm not quite sure what is wrong.
>
> I asked at #kicad at they said that Kicad does not have any gui-
> adjustable path settings for ngspice or libngspice, so I don't think I
> have the application configured wrong.

Fix pushed as f7d2ae57543ae6afe14434877d7480b15dcbb5b7.
I checked that the libngspice library is detected and that the
simulation window opens correctly, but I have not tried making
simulations of electronic circuits.
Please open another bug if you find a problem.


signature.asc
Description: PGP signature

bug#48536: ‘emacs-org-super-agenda’ is broken.

[Nicolas Goaziou]

Hello,

Xinglu Chen  writes:

> Subject: [PATCH] gnu: emacs-org-super-agenda: Disable failing test.

That was quick! :)

Applied. Thank you!

Regards,
-- 
Nicolas Goaziou

bug#48549: Can't change keyboard layout in Xfce

[Maxim Cournoyer]

Hello,

In a VM image such as the one we offer for download here:
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2
or manually built with

$ guix system image --image-size=20G -t qcow2 gnu/system/examples/vm-image.tmpl

it is not possible to switch the keyboard layout (it sticks to the
default English US one) via the provided GUI (xfce4-keyboard-settings).

Looking at dbus-monitor, we can see that it sends the following D-Bus
messages to xfconf, the configuration manager of Xfce:

--8<---cut here---start->8---
method call time=1621544143.298985 sender=:1.31 -> destination=:1.3 serial=21 
path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; member=SetProperty
   string "keyboard-layout"
   string "/Default/XkbLayout"
   variant   string "us,ara,et"
method call time=1621544143.299068 sender=:1.31 -> destination=:1.3 serial=22 
path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; member=SetProperty
   string "keyboard-layout"
   string "/Default/XkbVariant"
   variant   string "dvorak,,"
method return time=1621544143.299121 sender=:1.3 -> destination=:1.31 
serial=425 reply_serial=21
signal time=1621544143.299139 sender=:1.3 -> destination=(null destination) 
serial=426 path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; 
member=PropertyChanged
   string "keyboard-layout"
   string "/Default/XkbLayout"
   variant   string "us,ara,et"
method return time=1621544143.299192 sender=:1.3 -> destination=:1.31 
serial=427 reply_serial=22
signal time=1621544143.299209 sender=:1.3 -> destination=(null destination) 
serial=428 path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; 
member=PropertyChanged
   string "keyboard-layout"
   string "/Default/XkbVariant"
   variant   string "dvorak,,"
--8<---cut here---end--->8---

There doesn't seem to be a problem up to this point.

We'd need to continue the investigation with what xfconf does following
the received D-Bus messages.

Thanks,

Maxim

bug#48536: ‘emacs-org-super-agenda’ is broken.

[Xinglu Chen]

On Thu, May 20 2021, Nicolas Goaziou wrote:

> Hello,
>
> Xinglu Chen  writes:
>
>> Commit 71045f4e6425a686667cf30252a2a71cff36308b (“gnu: emacs-org: Update
>> to 9.4.6.”) seems to break a test in ‘emacs-org-super-agenda’[1], this
>> also breaks three other packages that depend on it.
>>
>> Any ideas why this happens?
>
> Not really. It seems like a capitalization problem. Maybe we should skip
> the failing test.
>
> WDYT?

Yeah, that sounds good to me.

I have done that in the attached patch.

From 6a17f3a38be2df199ef003f101fcd1445e1ccfbf Mon Sep 17 00:00:00 2001
Message-Id: <6a17f3a38be2df199ef003f101fcd1445e1ccfbf.1621542224.git.pub...@yoctocell.xyz>
From: Xinglu Chen 
Date: Thu, 20 May 2021 22:18:31 +0200
Subject: [PATCH] gnu: emacs-org-super-agenda: Disable failing test.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/packages/emacs-xyz.scm (emacs-org-super-agenda)[arguments]<#:phases>:
Disable the “org-super-agenda-test--:auto-tags” test.  The test failure was
caused by commit 71045f4e6425a686667cf30252a2a71cff36308b.
---
 gnu/packages/emacs-xyz.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 2af42f8842..294ed92981 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -16169,7 +16169,7 @@ as well as functions for navigating between these headings.")
  ;; The following test fail (see:
  ;; https://github.com/alphapapa/org-super-agenda/issues/183).
  (substitute* "test/test.el"
-   ((".*org-super-agenda-test--:auto-map.*" all)
+   ((".*org-super-agenda-test--:auto-(map|tags).*" all)
 (string-append all "  (skip-unless nil)\n")))
  #t)
 (native-inputs

base-commit: 7ff515aa511afbaf177a8bde68bde6a3878ca447
-- 
2.31.1



signature.asc
Description: PGP signature

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Maxim Cournoyer]

Hi,

Mark H Weaver  writes:

> Hi Maxim,
>
> Maxim Cournoyer  writes:
>
>> Mark H Weaver  writes:
>>
>>> Earlier, I wrote:
 However, I've noticed that in Dillo with CSS disabled, generating a
 'pre' for each line makes the line spacing larger than would be ideal.
 It seems that some vertical padding or margins are added around each
 'pre'.  It's likely that many browsers do this in their default styling
 for 'pre'.  With this in mind, it would perhaps be better to wrap a
 single 'pre' around each message.  Then you could either (1) leave the
 lines as 'span's and add a raw CR-LF after each line (which would make
 the HTML source code more readable) or (2) change the 'span's to 'div's
 as in your proposed patch.
>>>
>>> Actually, I just found by experimentation that option (2) above doesn't
>>> work well in either Lynx or Dillo.  Option (1) works well in the simple
>>> browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.
>>>
>>>Mark
>>
>> Friendly ping; it seems not much is missing to close this issue? :-).
>
>  is still essentially unreadable in
> Emacs Eww and Lynx, as well as Dillo when CSS is disabled, because there
> are many missing line breaks.

OK, thanks for the update, Mark.

Maxim

bug#47641: Ongoing difficulities after linphoneqt -> linphone-desktop transition

[Christopher Howard]

Just sent another message a few minutes ago. Clients shows all messages
are sent, but have not been seen by recipient.

-Original Message-
From: Raghav Gururajan 
To: Christopher Howard , Maxim Cournoyer <
maxim.courno...@gmail.com>
Cc: 47...@debbugs.gnu.org
Subject: Re: bug#47641: Ongoing difficulities after linphoneqt ->
linphone-desktop transition
Date: Fri, 14 May 2021 12:04:38 -0400

Hi Christopher,
> Raghav, I have sent you an instant message from my account. I am
> currently still using the old version of linphone.

I didn't receive it. Could you please retry?
Linphone Account: raghavgurura...@sip.linphone.org

Regards,RG.

bug#48536: ‘emacs-org-super-agenda’ is broken.

[Nicolas Goaziou]

Hello,

Xinglu Chen  writes:

> Commit 71045f4e6425a686667cf30252a2a71cff36308b (“gnu: emacs-org: Update
> to 9.4.6.”) seems to break a test in ‘emacs-org-super-agenda’[1], this
> also breaks three other packages that depend on it.
>
> Any ideas why this happens?

Not really. It seems like a capitalization problem. Maybe we should skip
the failing test.

WDYT?

Regards,
-- 
Nicolas Goaziou

bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[Maxim Cournoyer]

This can be verified on a system where the jami-daemon (libring) has not
yet been installed (commonly via propagation from one of the jami
clients):

$ guix environment --ad-hoc jami-gnome -- jami-gnome

Attempt to run it:

$ jami-gnome

It should fail with the following message: "Could not rec-connect to the
Jami daemon (dring). Jami will now quit."


as the currently running dbus session doesn't know about
the newly installed D-Bus service, as it only look under a few
hard-coded places.

For this particular instance, a workaround is to run jami via the
dbus-run-session utility, which launches the client in an ad-hoc d-bus
session which knows about the dring D-Bus service (through the
XDG_DATA_DIRS variable set by glib's search path).

$ guix environment --pure --ad-hoc jami-gnome dbus glib \
 -- dbus-run-session jami-gnome

The glib package is added for its XDG_DATA_DIRS search path.  It works
because the client doesn't really care about being able to talk to
anything else but its daemon over D-Bus.

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Mark H Weaver]

Hi Maxim,

Maxim Cournoyer  writes:

> Mark H Weaver  writes:
>
>> Earlier, I wrote:
>>> However, I've noticed that in Dillo with CSS disabled, generating a
>>> 'pre' for each line makes the line spacing larger than would be ideal.
>>> It seems that some vertical padding or margins are added around each
>>> 'pre'.  It's likely that many browsers do this in their default styling
>>> for 'pre'.  With this in mind, it would perhaps be better to wrap a
>>> single 'pre' around each message.  Then you could either (1) leave the
>>> lines as 'span's and add a raw CR-LF after each line (which would make
>>> the HTML source code more readable) or (2) change the 'span's to 'div's
>>> as in your proposed patch.
>>
>> Actually, I just found by experimentation that option (2) above doesn't
>> work well in either Lynx or Dillo.  Option (1) works well in the simple
>> browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.
>>
>>Mark
>
> Friendly ping; it seems not much is missing to close this issue? :-).

 is still essentially unreadable in
Emacs Eww and Lynx, as well as Dillo when CSS is disabled, because there
are many missing line breaks.

  Thanks,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Leo Prikler]

Am Donnerstag, den 20.05.2021, 15:24 +0300 schrieb Andrew Tropin:
> > > In other words, no particular thought was given to -pkg.el. It
> > > was
> > > simply dropped along with many other files. So, if consensus is
> > > reachedthat keeping -pkg.el is a good idea, there is no reason to
> > > not
> > > do that.
> > Thanks for clearing that up.  In that case, I don't have any qualms
> > about including them either.
> 
> Cool, seems we can get -pkg.el files back.
Yes, we can.

> > Multi-profile Emacs should be supported, but this also breaks on
> > foreign distros with foreign distro ELPA.  Again, hacking variables
> > is not the solution (and even if it was, it'd be better to patch
> > the emacs default value, not that this is a good idea either).
> 
> Yep, the last snippet supports multi-profile Emacs.  
While that's better, I still don't think it's sufficient.

> Installing packages for Emacs via a few different package manager
> sounds like a very bad practice) I agree that current implementation
> with updating variables isn't perfect and it doesn't cover the use
> case, which I expect to be rare (packages from Guix will be listed in
> list-packages, files from foreign distro PM won't).  I can dive into
> package.el implementation and spend some time next week providing a
> different workaround.
I think this is common practice on other distros.  For example your
system provides auctex, but it doesn't provide dash.el.  What do you
do?  Install it through ELPA.

Now let's say, you have Guix installed.  Guix provides packages for
some of ELPA, but not what you want.  You could hack together a Guix
package based on the ELPA importer, but perhaps upstream is slow in
accepting it or perhaps you've fetched the package from a shady source,
that Guix won't accept.  So you have foreign distro system packages +
Guix + personal ELPA.

As far as getting Guix packages to work without affecting the rest of
package.el or user configuration, I think an advice, that runs after
package-load-all-descriptors might be necessary.  As for the candidates
to check for this advice, you can read all subdirs.el files you find
inside load-path.  When they're formatted 
  (normal-top-level-add-to-load-path (list P1 ... PN))
they were likely added by Guix (even if not, one should probably
consider them important) and P1 ... PN should be scanned for
descriptors.

> BTW, can you remind me why we do not place packages under
> site-lisp/elpa/NAME-VERSION? It seems almost the same as
> site-lisp/NAME-VERSION, but everything related to describe-package
> and other functions will work out of the box.  This way it will work
> even with a foreign distro use case.
Again, Guix is not ELPA and calling it ELPA would be misleading.  As
for why we don't put stuff in any other site-lisp/ directory, e.g.
site-lisp/guix.d/NAME-VERSION, doing that led to rather tricky issues,
which is why we've decided to use site-lisp "directly".  The current
way of handling things is a bit of a compromise.  It gives you per-
package directories like ELPA, but unlike ELPA can easily be handled at
Emacs startup.

bug#48540: Non-recursive Git checkout with submodules breaks SWH download

[Timothy Sample]

Hi!

When trying to recover the ‘non-sequencer’ source from SWH, Guix fails
with a hash mismatch:

expected hash: 1cljkkyi9dxqpqhx8y6l2ja4zjmlya26m26kqxml8gx08vyvddhx
actual hash:   1xrrczqx4ll276g449nqiq0ip6lpika9hs4z4xgxaa6ayw60v29f

The reason is that the checkout includes submodules, and the way that
Guix treats submodules differs from the way that SWH treats them.  Note
that this is not a recursive checkout (which is also broken, but more
clearly a “known limitation”).  In particular, Guix leaves the submodule
as an empty directory, while SWH turns it into a symlink pointing to the
submodule’s commit hash:

$ readlink ./f20fa6babec52bbf703bad6c1c92fa845b781f7e/lib/ntk
1e3f5106d404562902bed2983403301db24a3f78

This is clearly a rare edge case, but it should be pretty easy to fix.
Perhaps it’s as easy as just opening “.gitmodules” and replacing the
symlink at each submodule path with an empty directory.


-- Tim

bug#48538: D-Bus services not working on foreign distributions/non-user profiles

[Maxim Cournoyer]

Hello,

On Guix System, the D-bus session service honors D-Bus service
definitions found under ~/.guix-profile/share.  That is not the case on
foreign distributions, breaking applications such as Jami (where the
daemon is normally auto-launched via D-Bus at the time the client
attempts to use it).

The same problem occurs on Guix System when attempting to use D-Bus
services from a non-user profile (such as with 'guix environment
--ad-hoc').

We should try to find a way to make this work; either automatically
(seems a tough nut to crack) or through manual, documented steps.

Thanks,

Maxim

bug#47592: [WIP Emacs] Emacs packages, that fail to build on master

[Leo Prikler]

Hi Maxim,

Am Donnerstag, den 20.05.2021, 08:44 -0400 schrieb Maxim Cournoyer:
> Hi Leo,
> 
> Leo Prikler  writes:
> 
> > I'm currently in the process of verifying, that all Emacs packages
> > build in the wip-emacs branch.  To that end, I'm running a manifest
> > generated from all emacs-xyz exports, which will fail for some
> > package,
> > that I've broken, then rinse and repeat.
> > However, there are some build failures, that exist not only in wip-
> > emacs.
> > 
> > In order not to generate too many bug numbers, I'm filing this as
> > some sort of meta bug.  Fixes could likely be pushed directly to
> > master, but if it's fine for everyone to wait a little, I'd send
> > them through wip-emacs first.
> > 
> > Regards, 
> > Leo
> > 
> > - BEGIN BUILD FAILURES -
> > 
> > emacs-nodejs-repl has a non-deterministic error in its test suite. 
> > Trying to complete "Error" sometimes yields nil for no apparent
> > reason.
> > 
> > emacs-org-generate fails with the following:
> > 
> > starting phase `check'
> > Loading /gnu/store/36ypaaqlmdqi3srzw892d3ppxm5hd6qi-emacs-mustache-
> > 0.23/share/emacs/site-lisp/mustache-render.el (source)...
> > Loading /gnu/store/36ypaaqlmdqi3srzw892d3ppxm5hd6qi-emacs-mustache-
> > 0.23/share/emacs/site-lisp/mustache-lex.el (source)...
> > Package cl is deprecated
> > Loading /gnu/store/36ypaaqlmdqi3srzw892d3ppxm5hd6qi-emacs-mustache-
> > 0.23/share/emacs/site-lisp/mustache-parse.el (source)...
> > Eager macro-expansion failure: (wrong-type-argument sequencep
> > :equal)
> > Eager macro-expansion failure: (wrong-type-argument sequencep
> > :equal)
> > Wrong type argument: sequencep, :equal
> > command "emacs" "--batch" "--quick" "--directory=." "--load=org-
> > generate-tests.el" "--funcall=cort-test-run" failed with status 255
> > 
> > emacs-picpocket fails with the following:
> > 
> > 37 unexpected results:
> >FAILED  picpocket-add-tag-delete-file
> >FAILED  picpocket-copy-all
> >FAILED  picpocket-delete-from-beginning
> >FAILED  picpocket-delete-from-the-middle-and-end
> >FAILED  picpocket-delete-redundant-tagged-file
> >FAILED  picpocket-delete-unique-tagged-file
> >FAILED  picpocket-empty-undo-buffer-test
> >FAILED  picpocket-external-file-sha-change
> >FAILED  picpocket-file-list-dot-file
> >FAILED  picpocket-file-list-symlink-loop
> >FAILED  picpocket-files-in-list-test
> >FAILED  picpocket-hardlink-all
> >FAILED  picpocket-insert-after-current
> >FAILED  picpocket-insert-before-current
> >FAILED  picpocket-move-all
> >FAILED  picpocket-single-undelete-test
> >FAILED  picpocket-tag-to-all
> >FAILED  picpocket-test-compute-filter-index
> >FAILED  picpocket-test-compute-filter-match-count
> >FAILED  picpocket-test-jump
> >FAILED  picpocket-test-pic-by-index
> >FAILED  picpocket-tree-add-and-clear-tag
> >FAILED  picpocket-tree-add-tag-to-all
> >FAILED  picpocket-tree-copy-within-tree
> >FAILED  picpocket-tree-file-list
> >FAILED  picpocket-tree-files
> >FAILED  picpocket-tree-make-list-with-tags
> >FAILED  picpocket-tree-make-list-with-tags2
> >FAILED  picpocket-tree-move-outside-tree
> >FAILED  picpocket-tree-move-within-tree
> >FAILED  picpocket-undelete-all-test
> >FAILED  picpocket-undo-add-tag-test
> >FAILED  picpocket-undo-buffer-test
> >FAILED  picpocket-undo-copy-test
> >FAILED  picpocket-undo-move-test
> >FAILED  picpocket-undo-remove-tag-test
> >FAILED  picpocket-undo-rename-test
> > 
> > command "emacs" "--batch" "-l" "picpocket-test.el" "-f" "ert-run-
> > tests-
> > batch-and-exit" failed with status 1
> > builder for `/gnu/store/6217gnljvphffsllvn9d8s9sl284ms7w-emacs-
> > picpocket-40.drv' failed with exit code 1
> 
> Pardon me for not checking myself, but I thought perhaps you had
> taken care of these issues on the recently merged wip-emacs branch?
> 
> If so, let's close it!
> 
> Thank you,
> 
> Maxim
Sadly, I did not.  I merely documented that it wasn't wip-emacs which
broke them.  However, I don't think this bug is useful to keep around
now that wip-emacs is merged.  If anyone has a fix to a breaking emacs-
package, that warrant's it's own bug/patch thread.

Regards,
Leo

bug#48519: texlive-bin cannot be installed in a profile

[Ricardo Wurmus]

raid5atemyhomework  writes:

In recent commits, `texlive-bin` cannot be installed in a 
profile. […]


This should be fixed with commit 
bd8e7621b880c529cc69102bd6817d79257526ee.


Only the presence of “texlive-base” triggers the profile hook now. 
This is acceptable because any TeX Live subset will need to 
include “texlive-base”.


--
Ricardo

bug#48536: ‘emacs-org-super-agenda’ is broken.

[Xinglu Chen]

Hi,

Commit 71045f4e6425a686667cf30252a2a71cff36308b (“gnu: emacs-org: Update
to 9.4.6.”) seems to break a test in ‘emacs-org-super-agenda’[1], this
also breaks three other packages that depend on it.

Any ideas why this happens?

--8<---cut here---start->8---
Test org-super-agenda-test--:auto-tags backtrace:
  signal(error ("Test failed for body:a5c8edc0db4a93c039964c5762e70...
  error("Test failed for body:%s\nDIFF:\n %s" "a5c8edc0db4a93c039964c5
  (or (equal stored-result new-result) (if (and stored-result new-resu
  (let ((stored-result (gethash body-groups-hash org-super-agenda-test
  (if org-super-agenda-test-show-results nil (let ((stored-result (get
  (let ((body-groups-hash (secure-hash 'md5 (format "%S" (list '(org-a
  (progn (if (> (hash-table-count org-super-agenda-test-results) 0) ni
  (setq value-129 (progn (if (> (hash-table-count org-super-agenda-tes
  (unwind-protect (setq value-129 (progn (if (> (hash-table-count org-
  (if (unwind-protect (setq value-129 (progn (if (> (hash-table-count 
  (let (form-description-130) (if (unwind-protect (setq value-129 (pro
  (let ((value-129 (gensym "ert-form-evaluation-aborted-"))) (let (for
  (closure (t) nil (let ((value-129 (gensym "ert-form-evaluation-abort
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name org-super-agenda-test--:auto-tags :do
  ert-run-or-rerun-test(#s(ert--stats :selector t :tests ... :test-map
  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" "(message \"Org version: %s\" (org-version)
  command-line()
  normal-top-level()
Test org-super-agenda-test--:auto-tags condition:
(error "Test failed for body:a5c8edc0db4a93c039964c5762e70420
DIFF:
 @@ -10,6 +10,12 @@
  Tags: @town, personal
   test:   Scheduled:  TODO [#C] Get haircut
   :personal:@town:
 
+ Tags: Emacs, computers, elisp, programming, software
+  ideas:  Scheduled:  SOMEDAY Rewrite Emacs in Common Lisp 
   :Emacs:elisp:computers:software:programming:
+
+ Tags: Emacs, website
+  test:   Deadline:   CHECK /r/emacs   
:website:Emacs:
+
  Tags: ambition, meetings, universe, world
   ambition:   Sched. 1x:  TODO [#A] Skype with president of Antarctica 
:universe:ambition:world::meetings:
 
@@ -35,15 +41,9 @@
  Tags: bills, spaceship
   test:   In  27 d.:  TODO [#A] Spaceship lease
  :bills:spaceship:
 
- Tags: computers, elisp, emacs, programming, software
-  ideas:  Scheduled:  SOMEDAY Rewrite Emacs in Common Lisp 
   :Emacs:elisp:computers:software:programming:
-
  Tags: dinner, food
   test:   18:00.. Scheduled:  TODO Order a pizza   
  :food:dinner:
 
- Tags: emacs, website
-  test:   Deadline:   CHECK /r/emacs   
:website:Emacs:
-
  Other items
   test:7:02.. Sunrise (12:04 of daylight)
8:00.. 
")
   FAILED   7/66  org-super-agenda-test--:auto-tags (0.076881 sec)
--8<---cut here---end--->8---

[1]: https://ci.guix.gnu.org/build/391929/details


signature.asc
Description: PGP signature

bug#48335: Emacs is broken

[Maxim Cournoyer]

Hi,

Checking with a `guix build emacs` built from master:

--8<---cut here---start->8---
$ ldd 
/gnu/store/lnwgc4ww47vkq2wv2ay3rdm0ppnmgyfy-emacs-27.2/bin/.emacs-27.2-real | 
grep libm17n
libm17n-core.so.0 => 
/gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-core.so.0
 (0x7faa39623000)
libm17n-flt.so.0 => 
/gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-flt.so.0 
(0x7faa39617000)
--8<---cut here---end--->8---

So it seems at least on current master things are good?

If you cannot reproduce this issue on current master, I suggest we close
it.

Thanks,

Maxim

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Maxim Cournoyer]

Hello,

Mark H Weaver  writes:

> Earlier, I wrote:
>> However, I've noticed that in Dillo with CSS disabled, generating a
>> 'pre' for each line makes the line spacing larger than would be ideal.
>> It seems that some vertical padding or margins are added around each
>> 'pre'.  It's likely that many browsers do this in their default styling
>> for 'pre'.  With this in mind, it would perhaps be better to wrap a
>> single 'pre' around each message.  Then you could either (1) leave the
>> lines as 'span's and add a raw CR-LF after each line (which would make
>> the HTML source code more readable) or (2) change the 'span's to 'div's
>> as in your proposed patch.
>
> Actually, I just found by experimentation that option (2) above doesn't
> work well in either Lynx or Dillo.  Option (1) works well in the simple
> browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.
>
>Mark

Friendly ping; it seems not much is missing to close this issue? :-).

Thank you,

Maxim

bug#47116: emacsy-minimal build failure

[Maxim Cournoyer]

Hello,

Maxime Devos  writes:

> On Fri, 2021-03-12 at 15:16 -0900, Christopher Howard wrote:
>> When trying to build nomad, emacsy-minimal build dies with this
>> failure:
>> 
>> [...]
> This should be fixed by this patch (not yet applied):
> .
>
> Apparently, this issue has been reporter earlier:
> .

The two above issues/patches have been closed/merged.

Sadly, emacsy still fails to build:

--8<---cut here---start->8---
PASS: test/advice.scm
PASS: test/text.scm
FAIL: test/klecl.scm
FAIL: test/kbd-macro.scm
FAIL: test/minibuffer.scm
PASS: test/help.scm
FAIL: test/core.scm
PASS: test/window.scm
XFAIL: test/windows.scm

Testsuite summary for Emacsy 0.4.1

# TOTAL: 19
# PASS:  14
# SKIP:  0
# XFAIL: 1
# FAIL:  4
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to guile-u...@gnu.org

make[3]: *** [Makefile:1497: test-suite.log] Error 1
make[3]: Leaving directory '/tmp/guix-build-emacsy-0.4.1.drv-0/emacsy-0.4.1'
make[2]: *** [Makefile:1605: check-TESTS] Error 2
make[2]: Leaving directory '/tmp/guix-build-emacsy-0.4.1.drv-0/emacsy-0.4.1'
make[1]: *** [Makefile:1807: check-am] Error 2
make[1]: Leaving directory '/tmp/guix-build-emacsy-0.4.1.drv-0/emacsy-0.4.1'
make: *** [Makefile:1809: check] Error 2

Test suite failed, dumping logs.

--- ./test-suite.log 


   Emacsy 0.4.1: ./test-suite.log


# TOTAL: 19
# PASS:  14
# SKIP:  0
# XFAIL: 1
# FAIL:  4
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test/core
===

WARNING: (guile-user): imported module (emacsy core) overrides core binding 
`map'
WARNING: (guile-user): `map' imported from both (guile) and (emacsy core)
WARNING: (guile-user): imported module (emacsy core) overrides core binding 
`map'
WARNING: (guile-user): `map' imported from both (guile) and (emacsy core)
WARNING: (guile-user): imported module (emacsy core) overrides core binding 
`map'
WARNING: (guile-user): `map' imported from both (guile) and (emacsy core)
WARNING: (guile-user): imported module (emacsy core) overrides core binding 
`map'
WARNING: (guile-user): `map' imported from both (guile) and (emacsy core)
Backtrace:
   5 (primitive-load "/tmp/guix-build-emacsy-0.4.1.drv-0/ema…")
In ice-9/eval.scm:
619:8  4 (_ #(#(#) (let* (#) …) …))
   293:34  3 (_ #(#(#(#) (# # …) …) …))
   182:19  2 (proc #(#(# (…)) …))
   142:16  1 (compile-top-call # …)
In unknown file:
   0 (%resolve-variable (7 . map) #)

ERROR: In procedure %resolve-variable:
Unbound variable: map

(eval-expression (quote (+ 1 2))) => 33 ; correct

(let* ((symbols (quote (aa ab c d (let-values (((to-string from-string) 
(object-tracker symbol->string))) (map from-string (all-completions "a" (map 
to-string symbols) => FAIL test/core.scm (exit status: 1)

FAIL: test/kbd-macro


RAW-READ-EVENT #

RAW-READ-EVENT #

WARNING: (guile-user): imported module (emacsy kbd-macro) overrides core 
binding `map'
WARNING: (guile-user): `map' imported from both (guile) and (emacsy kbd-macro)
WARNING: (guile-user): imported module (emacsy kbd-macro) overrides core 
binding `map'
WARNING: (guile-user): `map' imported from both (guile) and (emacsy kbd-macro)
WARNING: (guile-user): imported module (emacsy kbd-macro) overrides core 
binding `map'
WARNING: (guile-user): `map' imported from both (guile) and (emacsy kbd-macro)
Backtrace:
   5 (primitive-load "/tmp/guix-build-emacsy-0.4.1.drv-0/ema…")
In ice-9/eval.scm:
619:8  4 (_ #(#(#) (map # #) # …))
   293:34  3 (_ #(#(#(#) (map …) …) …))
   182:19  2 (proc #(#(#)))
   142:16  1 (compile-top-call # …)
In unknown file:
   0 (%resolve-variable (7 . map) #)

ERROR: In procedure %resolve-variable:
Unbound variable: map

test-command-called => 0 ; correct
RECORDING #a is undefined.RECORDING #b is undefined.
test-command-called => 0 ; *** failed ***
 ; expected result: 1

(map command-char last-kbd-macro) => FAIL test/kbd-macro.scm (exit status: 1)

FAIL: test/klecl


Backtrace:
   5 (primitive-load "/tmp/guix-build-emacsy-0.4.1.drv-0/ema…")
In emacsy/agenda.scm:
   167:10  4 (%update-agenda #< time: 1 segments: (#<)
155:4  3 (flush-queue! (() . #f))
In emacsy/coroutine.scm:
64:13  2 (_)
In ice-9/eval.scm:
   626:19  1 (_ #(#(#)))
In emacsy/klecl.scm:
   148:12  0 (read-event _)

emacsy/klecl.scm:148:12: In procedure read-event:
Throw to key `read-event-eof' with args `()'.

last-event => #f ; correct
FAIL test/klecl.scm (exit status: 1)

FAIL: 

bug#47458: Terrible UX upgrading Emacs in Guix

[Maxim Cournoyer]

Maxim Cournoyer  writes:

This should be fixed with the recently merged changes from Leo.  See
commit 307a2d2e2a833c2e1f7a79f46e4c6945c618cd8c. Thank you!

Closing.

Maxim

bug#47592: [WIP Emacs] Emacs packages, that fail to build on master

[Maxim Cournoyer]

Hi Leo,

Leo Prikler  writes:

> I'm currently in the process of verifying, that all Emacs packages
> build in the wip-emacs branch.  To that end, I'm running a manifest
> generated from all emacs-xyz exports, which will fail for some package,
> that I've broken, then rinse and repeat.
> However, there are some build failures, that exist not only in wip-
> emacs.
>
> In order not to generate too many bug numbers, I'm filing this as some
> sort of meta bug.  Fixes could likely be pushed directly to master, but
> if it's fine for everyone to wait a little, I'd send them through wip-
> emacs first.
>
> Regards, 
> Leo
>
> - BEGIN BUILD FAILURES -
>
> emacs-nodejs-repl has a non-deterministic error in its test suite. 
> Trying to complete "Error" sometimes yields nil for no apparent reason.
>
> emacs-org-generate fails with the following:
>
> starting phase `check'
> Loading /gnu/store/36ypaaqlmdqi3srzw892d3ppxm5hd6qi-emacs-mustache-
> 0.23/share/emacs/site-lisp/mustache-render.el (source)...
> Loading /gnu/store/36ypaaqlmdqi3srzw892d3ppxm5hd6qi-emacs-mustache-
> 0.23/share/emacs/site-lisp/mustache-lex.el (source)...
> Package cl is deprecated
> Loading /gnu/store/36ypaaqlmdqi3srzw892d3ppxm5hd6qi-emacs-mustache-
> 0.23/share/emacs/site-lisp/mustache-parse.el (source)...
> Eager macro-expansion failure: (wrong-type-argument sequencep :equal)
> Eager macro-expansion failure: (wrong-type-argument sequencep :equal)
> Wrong type argument: sequencep, :equal
> command "emacs" "--batch" "--quick" "--directory=." "--load=org-
> generate-tests.el" "--funcall=cort-test-run" failed with status 255
>
> emacs-picpocket fails with the following:
>
> 37 unexpected results:
>FAILED  picpocket-add-tag-delete-file
>FAILED  picpocket-copy-all
>FAILED  picpocket-delete-from-beginning
>FAILED  picpocket-delete-from-the-middle-and-end
>FAILED  picpocket-delete-redundant-tagged-file
>FAILED  picpocket-delete-unique-tagged-file
>FAILED  picpocket-empty-undo-buffer-test
>FAILED  picpocket-external-file-sha-change
>FAILED  picpocket-file-list-dot-file
>FAILED  picpocket-file-list-symlink-loop
>FAILED  picpocket-files-in-list-test
>FAILED  picpocket-hardlink-all
>FAILED  picpocket-insert-after-current
>FAILED  picpocket-insert-before-current
>FAILED  picpocket-move-all
>FAILED  picpocket-single-undelete-test
>FAILED  picpocket-tag-to-all
>FAILED  picpocket-test-compute-filter-index
>FAILED  picpocket-test-compute-filter-match-count
>FAILED  picpocket-test-jump
>FAILED  picpocket-test-pic-by-index
>FAILED  picpocket-tree-add-and-clear-tag
>FAILED  picpocket-tree-add-tag-to-all
>FAILED  picpocket-tree-copy-within-tree
>FAILED  picpocket-tree-file-list
>FAILED  picpocket-tree-files
>FAILED  picpocket-tree-make-list-with-tags
>FAILED  picpocket-tree-make-list-with-tags2
>FAILED  picpocket-tree-move-outside-tree
>FAILED  picpocket-tree-move-within-tree
>FAILED  picpocket-undelete-all-test
>FAILED  picpocket-undo-add-tag-test
>FAILED  picpocket-undo-buffer-test
>FAILED  picpocket-undo-copy-test
>FAILED  picpocket-undo-move-test
>FAILED  picpocket-undo-remove-tag-test
>FAILED  picpocket-undo-rename-test
>
> command "emacs" "--batch" "-l" "picpocket-test.el" "-f" "ert-run-tests-
> batch-and-exit" failed with status 1
> builder for `/gnu/store/6217gnljvphffsllvn9d8s9sl284ms7w-emacs-
> picpocket-40.drv' failed with exit code 1

Pardon me for not checking myself, but I thought perhaps you had taken
care of these issues on the recently merged wip-emacs branch?

If so, let's close it!

Thank you,

Maxim

bug#42224: Emacs currently requires bash and gzip to be propagated to load core functionality

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> It was discovered while troubleshooting an issue on help-guix [0] that
>> Emacs cannot currently load its subr-x module (there are probably many
>> more) when used in a pure environment (or container) that doesn't
>> propagate bash and gzip, which it uses to decompress the said module.
>
> D’oh!
>
>> The fix would be to patch Emacs' sources so those programs are referred
>> by their absolute store paths rather than simply being looked in PATH.

I believe this was fixed by Leo Prikler in their commit
d13b46fae46fe0e0d529e67ffc7f4074440d1b6e (gnu: emacs: Add coreutils and
gzip to PATH).

Closing!

Maxim

bug#48534: gtk+ 3.24.24 is not reproducible

[Bone Baboon via Bug reports for GNU Guix]

Bone Baboon via Bug reports for GNU Guix writes:
>   differing file:
> /share/icons/hicolor/icon-theme.cache

This is the same file that was reported as not being reproducible in
.

bug#48534: gtk+ 3.24.24 is not reproducible

[Bone Baboon via Bug reports for GNU Guix]

`guix challenge` shows that these versions of gtk+ are not
reproducible.

```
/gnu/store/5y1z0cl6g8ds86xhn2h9n1pk2hrjhh1h-gtk+-3.24.24
/gnu/store/8057xmgbnb8qkb1fn6jw3xcjx81fs92h-gtk+-3.24.24
/gnu/store/f354nhi011n2sz5vh266h8ss3rhadi1g-gtk+-2.24.32
```

`guix describe` outputs:

```
Generation 24   May 12 2021 18:06:24(current)
  guix d6aeebb
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d6aeebb23639258311fdfb9dbf5f903079fde51a
```

`guix challenge gtk+` outputs:

```
/gnu/store/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk+-3.24.24 contents differ:
  local hash: 0g3h3d6djx3jhmgg2aawqdxj3hpq0ciyv64drhikflrpqqbmrrwh
  
https://ci.guix.gnu.org/nar/lzip/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk%2B-3.24.24:
 09963h5b7j19xq3rl1p3kk85shj9yvknlagp0jwfy9saj88m20kn
  differing file:
/share/icons/hicolor/icon-theme.cache

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
```

`guix challenge --diff=diffoscope gtk+` outputs:

```
/gnu/store/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk+-3.24.24 contents differ:
  local hash: 0g3h3d6djx3jhmgg2aawqdxj3hpq0ciyv64drhikflrpqqbmrrwh
  
https://ci.guix.gnu.org/nar/lzip/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk%2B-3.24.24:
 09963h5b7j19xq3rl1p3kk85shj9yvknlagp0jwfy9saj88m20kn
--- /tmp/guix-directory.0OZAet
+++ /gnu/store/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk+-3.24.24
│   --- /tmp/guix-directory.0OZAet/share
├── +++ /gnu/store/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk+-3.24.24/share
│ │   --- /tmp/guix-directory.0OZAet/share/icons
│ ├── +++ /gnu/store/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk+-3.24.24/share/icons
│ │ │   --- /tmp/guix-directory.0OZAet/share/icons/hicolor
│ │ ├── +++ 
/gnu/store/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk+-3.24.24/share/icons/hicolor
│ │ │ │   --- /tmp/guix-directory.0OZAet/share/icons/hicolor/icon-theme.cache
│ │ │ ├── +++ 
/gnu/store/ayk8rab96lw7kx69rvfkhd6dp9p2v9ny-gtk+-3.24.24/share/icons/hicolor/icon-theme.cache
│ │ │ │┄ xxd not available in path. Falling back to Python hexlify.
│ │ │ │ @@ -7,11 +7,11 @@
│ │ │ │  00050004000400040003000400020004
│ │ │ │  00010004000400fc011067746b33
│ │ │ │  2d7769646765742d666163746f7279060005000400040004
│ │ │ │  0003000400020004000100040004
│ │ │ │  0150016c67746b332d64656d6f2d73796d626f6c
│ │ │ │  69632e73796d626f6c6963060005000400040004
│ │ │ │  0003000400020004000100040004
│ │ │ │ -000601bc01cc01d801e401f001fc32353678   
│ │ │ │ -3235362f6170707331367831362f6170707332347832342f6170   
│ │ │ │ -707333327833322f6170707334387834382f6170707332327832   
│ │ │ │ +000601bc01c801d801e401f001fc33327833   
│ │ │ │ +322f61707073323536783235362f6170707331367831362f6170   
│ │ │ │ +707334387834382f6170707332347832342f6170707332327832   
│ │ │ │  322f61707073

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
```

bug#48515: ell 0.40 test failure

[Maxim Cournoyer]

To clarify, this only happens on a machine with a Ryzen 3900X CPU that
has 24 cores.  I cannot reproduce on an older Q6700 4 cores machine.
Efraim was also able to reproduce on a similar Ryzen 3900XT CPU.

I tried reproducing on berlin but wasn't able to.

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Leo Prikler]

Am Donnerstag, den 20.05.2021, 16:09 +0530 schrieb Arun Isaac:
> > > [Adding Arun Isaac to CC.  Their commit d8796851 is the first one
> > > to
> > > drop -pkg.el, but without explanation.]
> > 
> > Commit d8796851 was an attempt to not install too many unnecessary
> > files
> > and be closer to how MELPA packaged emacs packages. See
> > https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00274.html
> >  for
> > the detailed discussion.
> 
> In other words, no particular thought was given to -pkg.el. It was
> simply dropped along with many other files. So, if consensus is
> reachedthat keeping -pkg.el is a good idea, there is no reason to not
> do that.
Thanks for clearing that up.  In that case, I don't have any qualms
about including them either.

Cheers!

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Andrew Tropin]

> That looks like it'd mess with people's installed ELPA packages.  In
> general, hacks based on package-directory-list don't feel very stable.

If you talk about ~/.emacs.d/elpa, it won't, because there is a separate
package-user-dir variable for that.

The problem can arise if we have emacs installed in a few profiles, I'm
not sure if it is a good idea to do so, but it is possible, in such a case
we will have a few items in the package-directory-list.  A fix for that:

(setq package-directory-list
  (mapcar (apply-partially 'string-remove-suffix "/elpa")
  package-directory-list)))

> Also, this seems to rely on us not deleting the -pkg.el, but probably
> won't work for packages, that don't ship it, e.g. emacs-howm.

It's true, but it seems relatively easy to implement a build phase,
which will generate -pgk.el in case it is missing.

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Arun Isaac]

>> [Adding Arun Isaac to CC.  Their commit d8796851 is the first one to
>> drop -pkg.el, but without explanation.]
>
> Commit d8796851 was an attempt to not install too many unnecessary files
> and be closer to how MELPA packaged emacs packages. See
> https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00274.html for
> the detailed discussion.

In other words, no particular thought was given to -pkg.el. It was
simply dropped along with many other files. So, if consensus is reached
that keeping -pkg.el is a good idea, there is no reason to not do that.

Cheers!


signature.asc
Description: PGP signature

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Arun Isaac]

> [Adding Arun Isaac to CC.  Their commit d8796851 is the first one to
> drop -pkg.el, but without explanation.]

Commit d8796851 was an attempt to not install too many unnecessary files
and be closer to how MELPA packaged emacs packages. See
https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00274.html for
the detailed discussion.

Cheers!


signature.asc
Description: PGP signature

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Leo Prikler]

Am Donnerstag, den 20.05.2021, 13:01 +0300 schrieb Andrew Tropin:
> > That looks like it'd mess with people's installed ELPA
> > packages.  In general, hacks based on package-directory-list don't
> > feel very stable.
> 
> If you talk about ~/.emacs.d/elpa, it won't, because there is a
> separate package-user-dir variable for that.
> 
> The problem can arise if we have emacs installed in a few profiles,
> I'm not sure if it is a good idea to do so, but it is possible, in
> such a case we will have a few items in the package-directory-
> list.  A fix for that:
> 
> (setq package-directory-list
>   (mapcar (apply-partially 'string-remove-suffix "/elpa")
>   package-directory-list)))
Multi-profile Emacs should be supported, but this also breaks on
foreign distros with foreign distro ELPA.  Again, hacking variables is
not the solution (and even if it was, it'd be better to patch the emacs
default value, not that this is a good idea either).

> > Also, this seems to rely on us not deleting the -pkg.el, but
> > probably won't work for packages, that don't ship it, e.g. emacs-
> > howm.
> 
> It's true, but it seems relatively easy to implement a build phase,
> which will generate -pgk.el in case it is missing.
Generating our own -pkg.el should work, still waiting for Maxim or Arun
on a statement as to why we exclude it.

*Always* generating a -pkg.el (disregarding the upstream one if it
exists) might further be a reasonable thing to do if we decide, that
those -pkg.el files are useful.

Regards,
Leo