bug#69735: [BUG] Error running any docker-composse command

[Arun Isaac]

Hi John,

> I would suggest we revert commit
> d084fb4b04a1cebb59959633660013fff495cd0d and/or use the previous version
> 6.1.3 until we can have docker compose with v2 support. As it is, this
> makes docker-compose unusable on Guix without some manual downgrade.
>
> Arun, what do you think?

Reverted, thanks for reporting!

Regards,
Arun

bug#64833: [mumi] mumi send-email does not handle complex refs

[Arun Isaac]

Sorry, I am really constrained for time and not working on this
actively. But, I am happy to review patches if any.

bug#65858: mumi crashes

[Arun Isaac]

Hi Chris and Maxim,

>> I think this is kind of expected. If NGinx hits the proxy_read_timeout
>> it'll return a 504 to the client and close the connection to Mumi I
>> think. I think what you're seeing here is Mumi trying to respond to a
>> request from NGinx that NGinx has closed.

Thanks for the tip. This indeed makes a lot of sense!

But, I don't understand why a proxy read timeout happens. The requests
in question seem to be very simple requests that shoud be processed
quickly. Should we increase nginx's proxy_read_timeout?

> If it's expected, we should handle it and produce a useful warning
> instead of crashing, right?

A couple of weeks ago, I put in a mechanism to better catch and report
errors.

https://git.savannah.gnu.org/cgit/guix/mumi.git/commit/?id=7a71c12a1f7f033ae93f26fb09387f6c04c143ba

I'm not sure this is working correctly, though. I have used `guard` in the
commit above. Does `guard` catch all exceptions correctly, or should I
instead use `catch`?

Also, I believe the logs are written in parallel by fibers. This may
mangle up the logs a bit, but I'm not sure if we're actually see
requests rapid enough for this to happen.

Regards,
Arun

bug#65858: mumi crashes

[Arun Isaac]

Hi Maxim,

I have made a number of changes to mumi and reconfigured berlin with the
latest mumi. Here is a quick summary of the main changes to mumi.

- We now log the complete URI and the response code for every request to
  mumi.
- We now handle HEAD requests correctly. This should eliminate some of
  the crashes we saw in the mumi log.

Regards,
Arun

bug#65858: mumi crashes

[Arun Isaac]

Hi Maxim,

Thanks for monitoring mumi. I'm not sure why these mumi crashes are
happening. I can think of two leads to start working on.

1. I see many lines such as those below that warn of garbage collection
issues with "repeated allocations of large blocks". I am not sure, but
this sounds like some limitation of the guile garbage collector. I
suspect these warnings arise because the guile-email parser thrashes the
garbage collector too much. I could look into rewriting parts of
guile-email to be more careful with memory use.

--8<---cut here---start->8---
2023-09-09 16:21:00 GC Warning: Repeated allocation of very large block (appr. 
size 16777216):
2023-09-09 16:21:00 May lead to memory leak and poor performance
2023-09-09 16:30:24 GC Warning: Repeated allocation of very large block (appr. 
size 16138240):
2023-09-09 16:30:24 May lead to memory leak and poor performance
2023-09-09 16:39:11 GC Warning: Repeated allocation of very large block (appr. 
size 16781312):
2023-09-09 16:39:11 May lead to memory leak and poor performance
--8<---cut here---end--->8---

2. If there is a specific query that causes mumi to crash, I'd like to
find out. This could be a GraphQL query. Unfortunately the actual
GraphQL document lives in the query part of the URI, and we don't log
the query part. I can patch mumi to log the query part.

WDYT?

Regards,
Arun

bug#65809: mumi: Add msg number and subject in search results when searching for subject:

[Arun Isaac]

>> Notice how the search term "database" is highlighted in the search
>> results. This is relatively easy to do with Xapian, and indeed I do
>> plan to implement this at some point.
>
> OK: can we consider this bug report (wishlist) as the "official" one for
> that feature? :-)

Sure!

> Can I retitle it to better reflect the upcoming implementation and
> assign it to you?

Yes, please!

> Actually I dont' know if there is some written or unwritten convention
> in Guix or GNU about bug assignment, I don't want to put pressure on
> you!

No problem! I do intend to implement this feature at some point
anyway. Even if I don't do it, it's good to list this as an issue so
that someone interested can try and hack on it.

bug#65809: mumi: Add msg number and subject in search results when searching for subject:

[Arun Isaac]

Hi Gio,

Sorry for my late reply. I have been travelling the last week and am
just catching up on all my email.

> When searching for "subject:" it would be useful to have a speficic
> message number and subject along with (or in place of) the bug title.

This is actually difficult to do because of the way we index issues as
Xapian "documents".

First, a quick Xapian primer. Xapian has a bunch of documents each
associated with a set of terms. When a search query comes in, Xapian
decomposes the query into a list of terms and retrieves documents that
match those terms.

In our case, we index entire issues as Xapian documents; we don't index
each individual email message as its own Xapian document. This means
that an issue is the smallest unit we can address. We cannot address
each individual email message. So, localizing a subject to a specific
email message is difficult.

Maybe what you are looking for is some context in the search results to
know why that particular search result was produced. This can be done by
displaying a snippet of text from the issue with the search terms
highlighted. For a working demo of what I mean, see for example,
https://issues.genenetwork.org/search?query=database=all . Notice
how the search term "database" is highlighted in the search
results. This is relatively easy to do with Xapian, and indeed I do plan
to implement this at some point.

WDYT? Would this meet your needs?

Regards,
Arun

bug#65809: [mumi] [wishlist] Allow searching subject prefix

[Arun Isaac]

Hi Gio,

Thanks for this feature request! It's always gratifying to know that
someone is using mumi, especially its more advanced features! :-)

> IMO is useful to be able to search for "subject:foo", it's a different
> search than searching for foo in the body

It looks like we implement this already. See
https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/xapian.scm#n141
A search for "subject:foo" should work already.

Cheers!
Arun

bug#64833: [mumi] mumi send-email does not handle complex refs

[Arun Isaac]

`mumi send-email' only works with patch files. For example, `mumi
send-email foo.patch bar.patch'. It would be nice if it could also
handle refs like `mumi send-email HEAD~5'.

Here's one way to achieve this.

1. When passed a ref, `mumi send-email' must run `git format-patch'
internally to produce patch files, preferably in a temporary directory.

2. Then, `mumi send-email' must send those patches as usual and clean up
the temporary directory.

bug#63936: mumi GraphQL endpoint errors out on non-existent issues

[Arun Isaac]

The mumi GraphQL endpoint errors out with an "Internal Server Error"
when queried for an issue that does not exist. It should error out with
a meaningful error response.

bug#63378: [PATCH] teams: Fix script to produce a single X-Debbugs-Cc header.

[Arun Isaac]

> It's string-contains without ?, apparently.

Ah, yes. That one always trips me up.

> The change is now installed; thanks for the review!

Thank you! :-)

bug#63378: [PATCH] teams: Fix script to produce a single X-Debbugs-Cc header.

[Arun Isaac]

Hi Maxim,

Thank you for the updated patch! :-) It LGTM. Please push.

> OK!  I opted for simplicity and double-quoted all the names.

Fair enough. Though a check is only one condition away! ;-)

(if (string-contains? (person-name member) ",")
(string-append "\"" (person-name member) "\"")
(person-name member))

Regards,
Arun

bug#63378: [PATCH] teams: Fix script to produce a single X-Debbugs-Cc header.

[Arun Isaac]

Hi Maxim,

When a patch relates to no teams, I get the empty header output
"X-Debbugs-Cc: ". For such patches, it would be nicer to not add any
header instead of adding an empty header.

> +(define (team->members team)
> +  "Return the list of members in TEAM."
> +  (sort (team-members team)
> +(lambda (m1 m2)
> +  (string +
> +(define (member->string member)
> +  "Return the 'email ' string representation of MEMBER."
> +  (format #false "~a <~a>" (person-name member) (person-email
> member)))

When person name contains a comma, it should be escaped by surrounding
in double quotes. Else, the comma would interfere with the
comma-separated list that we are constructing for
X-Debbugs-Cc. Admittedly, none of our current team members have commas
in their person names. But, some people like to have a name like
"LastName, FirstName". We should protect against that edge case in the
interest of futureproofing.

> + (format #true "X-Debbugs-Cc: ~{~a~^,~}"
> + (append-map (compose (cut map member->string <>)
> +  team->members
> +  find-team)
> + (patch->teams patch-file

A very nitpicky suggestion: Maybe, separate multiple persons by ", "
instead of just ",". ", " looks slightly better cosmetically. Likewise
in other places where this occurs.

Thanks for all the hard work! :-)

Regards,
Arun

bug#63378: A single X-Debbugs-CC header must be used

[Arun Isaac]

> Now, I don't think the GNU Debbugs instance is kept up-to-date with
> Debbugs upstream, having its own set of changes, so I think the patch
> here should still be applied in the meantime.

I agree. And, even otherwise, it is nice for X-Debbugs-Cc to mirror the
Cc header and use a comma-separated list. So, I'm all in favour of this
patch. Specific comments about the patch itself follow in a separate
email.

I will work on a similar patch for `mumi send-email' and send it
sometime later this week. As discussed earlier, I will make `mumi
send-email' invoke `git config sendemail.headerCmd' to find out about
etc/teams.scm.

bug#61627: Cannot start a container built with `guix system container --network'.

[Arun Isaac]

> Pushed as 42fbe62d52a82d1003c3d7039d3c4a46806c5cee

Thank you, Pierre! :-)

bug#61627: Cannot start a container built with `guix system container --network'.

[Arun Isaac]

> I'm inclined to keep it in %network-configuration-files just to be
> safe.

I agree. I don't really understand the implications of removing
/etc/hosts from %network-configuration-files. I would err on the side of
caution and leave it there for now.

@Pierre: Could you make a patch of the fix you suggested earlier
(removing hosts-service-type when the --network flag is provided) and
push it? Thank you!

bug#61627: Cannot start a container built with `guix system container --network'.

[Arun Isaac]

Hi Bruno,

> /etc/hosts is created by hosts-service-type, so if you remove that service
> it shouldn't be present anymore.

That makes sense.

There's one more question, though. Now that we are handling /etc/hosts
using hosts-service-type, should /etc/hosts still be in
%network-configuration-files? I believe this is what Pierre was asking.

Thanks,
Arun

bug#61627: Cannot start a container built with `guix system container --network'.

[Arun Isaac]

Hi Bruno and Ludo,

This bug seems related to your commit
802ea1f3a43e5fb8d0b8bd2882954d8a6e49cde6 . Could you weigh in?

https://issues.guix.gnu.org/61627

Thanks!
Arun

bug#49115: [PATCH 0/1] Do not check for MIME encoded words

[Arun Isaac]

Hi Ricardo,

I have an additional small improvement. guile-email transparently
handles MIME encoded words. We need not check for them. Patch follows.

Regards,
Arun

Arun Isaac (1):
  debbugs: Do not check for MIME encoded words in subject.

 mumi/debbugs.scm | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

-- 
2.38.1

bug#49115: [PATCH 1/1] debbugs: Do not check for MIME encoded words in subject.

[Arun Isaac]

guile-email transparently handles MIME encoded words. We do not have
to check for them.

* mumi/debbugs.scm (bug-status): Do not check for MIME encoded words
in subject.
---
 mumi/debbugs.scm | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/mumi/debbugs.scm b/mumi/debbugs.scm
index 16bff8e..7e95ddf 100644
--- a/mumi/debbugs.scm
+++ b/mumi/debbugs.scm
@@ -1,5 +1,6 @@
 ;;; mumi -- Mediocre, uh, mail interface
 ;;; Copyright © 2020 Ricardo Wurmus 
+;;; Copyright © 2023 Arun Isaac 
 ;;;
 ;;; This program is free software: you can redistribute it and/or
 ;;; modify it under the terms of the GNU Affero General Public License
@@ -280,10 +281,10 @@ defaults to 30 days."
  (assoc-ref properties "Submitter")
  (assoc-ref properties "Owner")
  (or (assoc-ref properties "Severity") "normal")
- (let ((subject (or (assoc-ref properties "Subject") "")))
-   (if (string-contains subject "=?UTF-8?Q?")
-   (match (parse-email-headers (string-append 
"Subject: " subject "\n"))
- ((('subject . sub) . rest) sub)
- (other subject))
-   subject))
+ (assq-ref
+  (parse-email-headers
+   (string-append "Subject: "
+  (or (assoc-ref properties "Subject") "")
+  "\n"))
+  'subject)
  (assoc-ref properties "Tags"
-- 
2.38.1

bug#49115: Mumi inserts spurious underscore in bug title

[Arun Isaac]

Hi Ricardo,

Thanks for the bug report!

It's very strange, but I'm not able to reproduce this. I tried the
following. bug_49114.mbox is downloaded from
https://debbugs.gnu.org/cgi/bugreport.cgi?mbox=yes;bug=49114

--8<---cut here---start->8---
(use-modules (email email))

(pk
 (parse-email-headers "Subject: bug#49114: =?UTF-8?Q?=E2=80=98guix_?= 
=?UTF-8?Q?lint=E2=80=99?= should catch certificate validation exceptions
"))

(for-each (lambda (bv)
(pk (assoc-ref (email-headers (parse-email bv))
   'subject)))
  (call-with-input-file "bug_49114.mbox"
mbox->emails))
--8<---cut here---end--->8---

Even at https://issues.guix.gnu.org/49114 , only the "bug title" has the
spurious underscore. The subject of the first message does not. Is the
bug title something stored in the xapian index? Could it be that this
was an older bug that has corrupted the xapian index?

If I understand correctly, mumi does not rebuild its xapian index. I
think it should do so from time to time. It would help prevent old bugs
from getting persisted in storage.

Cheers, and wish you a Happy New Year! :-)
Arun

bug#53519: python-seaborn build failure

[Arun Isaac]

Closing since python-seaborn now builds successfully on the latest
master.

I have also sent a new patch updating python-seaborn to
0.12.0. https://issues.guix.gnu.org/58466

bug#57864: rust-zstd-sys bundles zstd

[Arun Isaac]

Hi Maxime,

> X-Debbugs-CC: Arun Isaac 
>
> ^ author of the commit adding the rust-zstd-sys
>
> I noticed that the package 'rust-zstd-sys' bundles a copy of zstd.  This 
> is against policy for the reasons documented in the manual.  This 
> package was added in commit 4402eb48cdd18aed8072696496362f2e774e973f.
>
> I'll try unbundling it in antioxidant.

Sorry for the trouble. Thanks for working on this!

Regards,
Arun

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

> I fixed it in 67a6828b2bb821274757f686f7c685b664339a96 using the same
> trick as earlier.

Works now, thank you!

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

Hi zimoun,

> Well, it appears to me easier if bug#57306 remains closed since ’guix
> time-machine’ is fixed; as it was the subject.

I think you mean that bug #56441 should remain closed. Bug #56441 was
about guix time-machine. Bug #57306 is the current bug about guix pull.

Regards,
Arun

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

Hi zimoun,

> I do not think it is related to guix-daemon and I think it is expected;
> indeed it could be considered as a bug.  The command-line,
>
> guix pull --commit=xyz -p /tmp/test
>
> writes /tmp/test/manifest using the current Guix (say manifest 4) and
> not using Guix at commit xyz (say manifest 3).  Contrary to “guix
> time-machine --commit=xyz”.

Ah, that makes sense! Any ideas as to how this issue might be fixed?

Thanks,
Arun

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

Thanks, Josselin! I have asked at #56441 whether it may be reopened.

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

>> Commit 4ff12d1de7cd617b791996ee7ca1240660b4c20e introduced that bug,
>> which was fixed in c9fbd40785a99e13a59d8e530830ce85220a9871:

The failing commit 6f75565b4ec3b8a7247699c327a3b3196c787f76 is not in
that range, if that's what you are saying.

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

When I guix pull to 6f75565b4ec3b8a7247699c327a3b3196c787f76, activate
the profile and run guix describe, it fails with an "unsupported
manifest format" error.

--8<---cut here---start->8---
$ guix pull --commit=6f75565b4ec3b8a7247699c327a3b3196c787f76 -p
/tmp/test
$ source /tmp/test/etc/profile
$ guix describe
guix describe: error: unsupported manifest format
--8<---cut here---end--->8---

This happens because my guix-daemon writes a version 4 manifest and the
guix from commit 6f75565b4ec3b8a7247699c327a3b3196c787f76 only
understands a version 3 manifest.

This may be related to https://issues.guix.gnu.org/56545

bug#54950: Connecting to remote guix daemon with encrypted SSH key fails

[Arun Isaac]

Hi Maxim,

> I'm curious as to how SSH clients typically trigger 'pinentry' to
> prompt; perhaps Guile-SSH is lacking some feature here.

Exactly my point! :-)

> I hope someone in the know can tip in!  In the meantime, you've already
> found a workaround (the use of an SSH agent).

Yup.

Thanks,
Arun

bug#54950: Connecting to remote guix daemon with encrypted SSH key fails

[Arun Isaac]

Hi Maxim,

I normally use neither OpenSSH's ssh-agent nor gpg-agent's ssh-agent
feature. But, when I do, it works. I didn't run into any pinentry issues
like you described. But, that's only because a passphrase entry is not
required at the time of `guix build'. Passphrase entry is required only
at the time of `ssh-add' when I am adding the key to the ssh-agent. Just
to be clear, here are the exact steps I used to set up gpg-agent.

Enable gpg's ssh-agent feature

$ echo use-agent >> ~/.gnupg/gpg.conf
$ echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf

pkill and restart gpg-agent (command not shown). Then, add the key to
gpg's ssh-agent. A passphrase is prompted at this point.

$ ssh-add ~/.ssh/id_ecdsa

guix build with remote daemon. A passphrase is not prompted at this
point because it was already added into the ssh-agent in the last step.

$ SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
GUIX_DAEMON_SOCKET=ssh://foo guix build -v3 hello

So, with an ssh-agent, guix build on a remote daemon works. But, I'd
like it to work without an ssh-agent. Is that possible?

Regards,
Arun

bug#54950: Connecting to remote guix daemon with encrypted SSH key fails

[Arun Isaac]

Hi Maxim,

> I suspect this is due to changes in OpenSSH *client* that now refuse
> older RSA keys for security reasons.

This doesn't seem to be. Here's why: I have another machine that I ssh
to using an unencrypted RSA key. I am able to connect to the Guix daemon
on that machine without any trouble. What's more, the machine with an
encrypted key, whose Guix daemon I'm unable to connect to, uses an ECDSA
key.

> Could you retry with the following option: 'StrictHostKeyChecking no'
> applied to the host in your ~/.ssh/config?

Adding 'StrictHostKeyChecking no' makes no difference. The unencrypted
key still works, and the encrypted doesn't.

Cheers!
Arun

bug#55765: [mumi] Xapian SWIGy issue

[Arun Isaac]

Hi Ludo,

While I'm pretty sure it won't help this issue, I just released the long
overdue guile-xapian 0.2.0 and updated the Guix package as well. See
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e614cf2907105d1d41653c2316b96d29d807baa8

Regards,
Arun

bug#55765: [mumi] Xapian SWIGy issue

[Arun Isaac]

Hi Ludo,

> --8<---cut here---start->8---
> 2022-06-02 15:04:45 GET /issue/54065/raw/12
> 2022-06-02 15:04:45 GET /issue/43096/raw/2
> 2022-06-02 15:04:45 GET /issue/45676/raw/10
> 2022-06-02 15:09:09 GET In procedure delete-Database: Wrong type argument in 
> position 1: #
> 2022-06-02 15:09:21 In procedure delete-Database: Wrong type argument in 
> position 1: #
> --8<---cut here---end--->8---
>
> Does that ring a bell, Arun?

That doesn't immediately ring a bell, but I could investigate. Do you
have any way to reproduce this issue? Also, which version of mumi and
guile-xapian is this?

Thanks!
Arun

bug#54950: Connecting to remote guix daemon with encrypted SSH key fails

[Arun Isaac]

I have an SSH key encrypted with a passphrase. When I try connecting to
a remote guix daemon with that encrypted SSH key, it fails with the
following error message.

--8<---cut here---start->8---
$ GUIX_DAEMON_SOCKET=ssh://foo guix build -v3 hello
guix build: error: SSH authentication failed for 'foo': Access
denied for 'publickey'. Authentication that can continue: publickey
--8<---cut here---end--->8---

I expected some kind of prompt asking me for the passphrase, but did not
get any. The same command works if I set up ssh-agent and add the
relevant key to it.

bug#53519: python-seaborn build failure

[Arun Isaac]

Hi Bonface,

It looks like this problem is due to matplotlib 3.5.x and is known
upstream. See
https://github.com/mwaskom/seaborn/issues/2663 . We might have to wait
for an upstream release or cherry pick commits.

Regards,
Arun


signature.asc
Description: PGP signature

bug#44096: failed to build wesnot

[Arun Isaac]

Hi,

Tobias communicated off-list that it is ok to close this issue. I am
closing it now.

Thanks,
Arun


signature.asc
Description: PGP signature

bug#44096: failed to build wesnot

[Arun Isaac]

Hi,

I just pushed a patch upgrading wesnoth to 1.16.0, and I confirm that it
builds successfully. Can we close this issue?

Regards,
Arun


signature.asc
Description: PGP signature

bug#50919: [PATCH] gnu: Update zfs to 2.1.1.

[Arun Isaac]

Hi,

Thanks for the patch! Unfortunately, this is a duplicate of
https://issues.guix.gnu.org/50744 . Sorry about that! I'm closing this
bug now.

Thanks,
Arun


signature.asc
Description: PGP signature

bug#44678: Set a Firefox user agent for our Icecat build

[Arun Isaac]

Hi Maxim,

> I thought the default user agent was already that of Firefox for Windows
> (!), purportedly to make it less unique (thus making fingerprinting of
> browsers/users more difficult).

Sorry, I'm replying rather late. I just disabled the "User-Agent
Switcher" addon in my Icecat, and found that the default user agent is
"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Firefox/78.0". So, I guess this bug is addressed.

Thank you,
Arun


signature.asc
Description: PGP signature

bug#49233: gmnisrv: missing mime.types

[Arun Isaac]

Hi,

I believe commits b459c39adb725822916a8e21ee250fb408d2e2f8 and
e17f063627f826b4dd0dda77ede48fc7a535414b address this issue. So, closing
this issue.

Thanks,
Arun


signature.asc
Description: PGP signature

bug#48457: linkchecker 9.4.0 fails to build

[Arun Isaac]

Hi,

Version 10.0.1 (the latest version) of linkchecker supports python 3,
and I updated the package a month or so ago. Closing this bug report
now.

Cheers,
Arun


signature.asc
Description: PGP signature

bug#45571: Support stable uids and gids for system accounts in a container

[Arun Isaac]

Hi all,

For many services, extending the activation-service-type with a gexp
that can chown the necessary files is a good enough solution. This is
how I work around the problem of unstable uids/gids in my guix system
containers.

Regards,
Arun


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.

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#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

[Arun Isaac]

Hi,

> @Arun, does this sound familiar to you?

Thanks for the bug report! It was indeed a regression in guile-email. I
have fixed it, and added a test. See
https://git.systemreboot.net/guile-email/commit/?id=ca0520a33c9042a68691d85c6849f88412ca8357

Cheers!


signature.asc
Description: PGP signature

bug#46154: Not able to get Hindi "Input Method" to add in listing of available input methods in non-gnome wm like stumpwm

[Arun Isaac]

Hi,

I don't know much about the state of ibus in Guix. When last I checked a
few years ago, I couldn't get it to work for Tamil. So, I tried uim and
it worked. Perhaps, just as an immediate workaround until this bug is
addressed, maybe you could try uim?

My uim setup is as follows. You probably need similar.

Contents of ~/.uim
--8<---cut here---start->8---
(define default-im-name 'm17n-ta-tamil99)
--8<---cut here---end--->8---

Relevant environment variables in ~/.bashrc
--8<---cut here---start->8---
export 
GUIX_GTK3_IM_MODULE_FILE=~/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache
export 
GUIX_GTK2_IM_MODULE_FILE=~/.guix-profile/lib/gtk-2.0/2.10.0/immodules-gtk2.cache
--8<---cut here---end--->8---

Regards,
Arun


signature.asc
Description: PGP signature

bug#44553: Exim has no authenticators

[Arun Isaac]

Hi,

Thanks for your patch. I pushed to master with the following minor
changes.

- added copyright header for you
- made minor style change in code
- modified the commit message

Cheers!


signature.asc
Description: PGP signature

bug#45015: [mumi] 44964 cannot be displayed

[Arun Isaac]

>> I have fixed this bug in the latest guile-email master, and added
>> tests to prevent regression. See
>> https://git.systemreboot.net/guile-email/commit/?id=37e245539bc9e27db35731e7b517cdde397834e2
>> and
>> https://git.systemreboot.net/guile-email/commit/?id=907a5d678c58eff653133df441aeecd3b7025e37
>
> Thank you!  You are always very fast and thorough; I appreciate this a
> lot!

Thank you, I really appreciate the acknowledgement! :-)


signature.asc
Description: PGP signature

bug#45015: [mumi] 44964 cannot be displayed

[Arun Isaac]

> For some reason “Jorge P. de Morais Neto ” is
> not split up into name and address parts but remains a single string.

I have fixed this bug in the latest guile-email master, and added
tests to prevent regression. See
https://git.systemreboot.net/guile-email/commit/?id=37e245539bc9e27db35731e7b517cdde397834e2
and
https://git.systemreboot.net/guile-email/commit/?id=907a5d678c58eff653133df441aeecd3b7025e37

I thought “Jorge P. de Morais Neto ” was an
invalid email address due to the period character, but apparently it is
supported by the obsolete addressing specification of RFC5322 (see
https://tools.ietf.org/html/rfc5322#section-4). I hadn't implemented the
obsolete parts of the specification until now.

> Mumi commit 6fd49e9341d5673b70edfb333a4e5fa0a44128d2 works around this
> problem, which I suspect might be a bug in guile-email.

guile-email should guarantee the parsed From header is an alist of the
appropriate form. So, I vote for reverting this commit, thus reducing
complexity on mumi's end. But, I understand that guile-email is not yet
doing a great job of providing these strong guarantees.

Cheers!


signature.asc
Description: PGP signature

bug#45015: [mumi] 44964 cannot be displayed

[Arun Isaac]

Hi,

This is likely a bug in guile-email. It shouldn't have returned the
unparsed From address. It was likely triggered by "Jorge P. de Morais
Neto " being an invalid address. The period
character is not allowed in the name and should have been quoted like
"\"Jorge P. de Morais Neto\" ". I will
investigate and come up with some fix within 24 hours.

Meanwhile, do CC me or guile-em...@systemreboot.net on anything
guile-email related. That would help me take note sooner. I found this
bug report almost by chance.

Thanks,
Arun


signature.asc
Description: PGP signature

bug#44678: Set a Firefox user agent for our Icecat build

[Arun Isaac]

Hi,

Many sites---jitsi among many others---don't work properly when they see
an Icecat user agent. Instead, when the user agent is set to a Firefox
user agent, these sites work as expected. Users can do this manually by
installing user agent switching extensions such as uaswitcher, but it
would be much better if our Icecat package, by default, came with a
Firefox user agent, and everything worked normally without any user
intervention.

This bug report arose out of a discussion on help-guix. See
https://lists.gnu.org/archive/html/help-guix/2020-11/msg00082.html

I would normally volunteer a patch, but building Icecat takes too long
(> 24 hours) on my slow computer. It would be nice if someone with a
faster build machine handled this.

Thanks,
Arun

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> It kept spitting the error during the check phase, but I was
> time-machined some months into the past. Maybe with current Guix version
> the issue does not occur. I will check it out this or the next week.

Sure, check it out and let me know.

> Thank you for your work on this issue.

My pleasure! :-)


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

Hi,

I pushed to master, my commit replacing proj.4 with proj. This fixes the
segfault issue. I also updated the package. If the issue with the check
phase still persists, please open a separate issue.

Cheers!

bug#42212: [PATCH v2 1/1] Use nearest tag as the version string in documentation.

[Arun Isaac]

* guix/channels.scm (latest-channel-instance): Write nearest tag into .version
of the checkout.
* guix/self.scm (info-manual): Use nearest tag from .version as the version
string while generating documentation.
---
 guix/channels.scm | 13 -
 guix/self.scm | 10 ++
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/guix/channels.scm b/guix/channels.scm
index ad2442f50e..e8941bb28e 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2018, 2019, 2020 Ludovic Courtès 
 ;;; Copyright © 2018 Ricardo Wurmus 
 ;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen 
+;;; Copyright © 2020 Arun Isaac 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -393,7 +394,17 @@ thus potentially malicious code."
 (when (guix-channel? channel)
   ;; Apply the relevant subset of PATCHES directly in CHECKOUT.  This is
   ;; safe to do because 'switch-to-ref' eventually does a hard reset.
-  (apply-patches checkout commit patches))
+  (apply-patches checkout commit patches)
+
+  ;; Write into .version, the nearest tag without the "v" prefix.
+  (call-with-output-file (string-append checkout "/.version")
+(lambda (port)
+  (display (substring
+(describe-format
+ (describe-workdir (repository-open checkout))
+ (make-describe-format-options #:abbreviated-size 0))
+1)
+   port
 
 (let* ((name (url+commit->name (channel-url channel) commit))
(checkout (add-to-store store name #t "sha256" checkout
diff --git a/guix/self.scm b/guix/self.scm
index f70b1ecdd8..58ca4386f1 100644
--- a/guix/self.scm
+++ b/guix/self.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2017, 2018, 2019, 2020 Ludovic Courtès 
+;;; Copyright © 2020 Arun Isaac 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -459,16 +460,17 @@ a list of extra files, such as '(\"contributing\")."
 (with-imported-modules '((guix build utils))
   #~(begin
   (use-modules (guix build utils)
+   (rnrs io ports)
(ice-9 match))
 
   (mkdir #$output)
 
-  ;; Create 'version.texi'.
-  ;; XXX: Can we use a more meaningful version string yet one that
-  ;; doesn't change at each commit?
+  ;; Create 'version.texi'. Use nearest tag written in .version as the
+  ;; version string.
   (call-with-output-file "version.texi"
 (lambda (port)
-  (let ((version "0.0-git"))
+  (let* ((version (call-with-input-file (string-append #$source 
"/.version")
+get-string-all)))
 (format port "
 @set UPDATED 1 January 1970
 @set UPDATED-MONTH January 1970
-- 
2.26.2

bug#42212: [PATCH v2 0/1] Use nearest tag as the version string in documentation

[Arun Isaac]

The new guile-git based patch follows. Thanks!

Arun Isaac (1):
  Use nearest tag as the version string in documentation.

 guix/channels.scm | 13 -
 guix/self.scm | 10 ++
 2 files changed, 18 insertions(+), 5 deletions(-)

-- 
2.26.2

bug#42212: [PATCH 1/1] self: Use nearest tag as the version string in documentation.

[Arun Isaac]

> I would rather not call out to ‘git-version-gen’ and instead use (git
> describe) or similar.

Sure, I'll do that. Then, perhaps we should even rewrite git-version-gen
using (git describe). It would be nice to have that in guile too. WDYT?

> However, unless I’m mistaken, the output of ‘git-version-gen’ changes at
> each commit, so we’d be rebuilding the manual at every commit, which is
> what we should avoid here.

Yes, but I discard the commit part of git-version-gen's output. I keep
only the tag part.

But, like zimoun, I didn't understand why we can't rebuild the manual
every commit. Rebuilding the manual is quite cheap. So, substituting it
shouldn't be a problem, right?

> One way to avoid that would be to look at the latest commit that touch
> doc/ instead of the latest commit overall (I think that’s what zimoun
> was suggesting).  Roughly run ‘git describe’ on ‘git log doc/’, so to
> speak.  (Using Guile-Git.)

This sounds good. I'll try it and get back to you.


signature.asc
Description: PGP signature

bug#42212: [PATCH 1/1] self: Use nearest tag as the version string in documentation.

[Arun Isaac]

* guix/channels.scm (latest-channel-instance): Write nearest tag into .version
of the checkout.
* guix/self.scm (info-manual): Use nearest tag from .version as the version
string while generating documentation.
---
 guix/channels.scm | 15 ++-
 guix/self.scm | 11 +++
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/guix/channels.scm b/guix/channels.scm
index bbabf654a9..d35cbc42cf 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2018, 2019, 2020 Ludovic Courtès 
 ;;; Copyright © 2018 Ricardo Wurmus 
 ;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen 
+;;; Copyright © 2020 Arun Isaac 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -40,6 +41,7 @@
   #:use-module (guix sets)
   #:use-module (guix store)
   #:use-module (guix i18n)
+  #:use-module (guix build utils)
   #:use-module ((guix utils)
 #:select (source-properties->location
   
@@ -56,9 +58,11 @@
   #:autoload   (guix quirks) (%quirks %patches applicable-patch? apply-patch)
   #:use-module (ice-9 format)
   #:use-module (ice-9 match)
+  #:use-module (ice-9 popen)
   #:use-module (ice-9 vlist)
   #:use-module ((ice-9 rdelim) #:select (read-string))
   #:use-module ((rnrs bytevectors) #:select (bytevector=?))
+  #:use-module (rnrs io ports)
   #:export (channel
 channel?
 channel-name
@@ -397,7 +401,16 @@ thus potentially malicious code.")))
 (when (guix-channel? channel)
   ;; Apply the relevant subset of PATCHES directly in CHECKOUT.  This is
   ;; safe to do because 'switch-to-ref' eventually does a hard reset.
-  (apply-patches checkout commit patches))
+  (apply-patches checkout commit patches)
+
+  ;; Write nearest tag into .version.
+  (with-directory-excursion checkout
+(let ((version
+   (call-with-port
+(open-pipe* OPEN_READ "./build-aux/git-version-gen" 
".tarball-version")
+get-string-all)))
+  (call-with-output-file ".version"
+(cut put-string <> version)
 
 (let* ((name (url+commit->name (channel-url channel) commit))
(checkout (add-to-store store name #t "sha256" checkout
diff --git a/guix/self.scm b/guix/self.scm
index f70b1ecdd8..8c94efa7de 100644
--- a/guix/self.scm
+++ b/guix/self.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2017, 2018, 2019, 2020 Ludovic Courtès 
+;;; Copyright © 2020 Arun Isaac 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -459,16 +460,18 @@ a list of extra files, such as '(\"contributing\")."
 (with-imported-modules '((guix build utils))
   #~(begin
   (use-modules (guix build utils)
+   (rnrs io ports)
(ice-9 match))
 
   (mkdir #$output)
 
-  ;; Create 'version.texi'.
-  ;; XXX: Can we use a more meaningful version string yet one that
-  ;; doesn't change at each commit?
+  ;; Create 'version.texi'. Use nearest tag written in .version as the
+  ;; version string.
   (call-with-output-file "version.texi"
 (lambda (port)
-  (let ((version "0.0-git"))
+  (let* ((tag (call-with-input-file (string-append #$source 
"/.version")
+get-string-all))
+ (version (substring tag 0 (string-index-right tag #\.
 (format port "
 @set UPDATED 1 January 1970
 @set UPDATED-MONTH January 1970
-- 
2.26.2

bug#42212: [PATCH 0/1] Use nearest tag as the version string in documentation.

[Arun Isaac]

We can't actually use (guix config) since it doesn't have a useful version
number in this stage of the build process. See the use of make-config.scm in
build-program of build-aux/build-self.scm.

We need to use the nearest tag but that requires the git repo and we drop that
in the channel checkout. See use of dot-git? in latest-channel-instance of
(guix channels). To remedy this, I am generating .version before discarding
the git repo.

WDYT?

Arun Isaac (1):
  self: Use nearest tag as the version string in documentation.

 guix/channels.scm | 15 ++-
 guix/self.scm | 11 +++
 2 files changed, 21 insertions(+), 5 deletions(-)

-- 
2.26.2

bug#42212: Guix version rendered as 0.0-git in info manual

[Arun Isaac]

> The “0.0-git” string comes from (guix self).  As noted there, we can’t
> really afford to change the version string at each commit, or we’d have
> to rebuild the manual at each commit.
>
> We could perhaps choose a more meaningful version string, though, maybe
> by looking at the closest tag or something.

That sounds good, and `git describe` could provide us with the closest
tag. Unfortunately, (git) doesn't seem to be available during `guix
pull`. I'm trying to come up with workarounds. Do you have any ideas?


signature.asc
Description: PGP signature

bug#42212: Guix version rendered as 0.0-git in info manual

[Arun Isaac]

In the info manual, the Guix version is rendered as 0.0-git. For
example, in "(guix) The Store", see "The ability to connect to remote
build daemons is considered experimental as of 0.0-git". I am running
the Guix standalone system. Any idea what's going wrong?

Thanks,
Arun


signature.asc
Description: PGP signature

bug#25235: Wrapped python programs get native-inputs in PYTHONPATH

[Arun Isaac]

Hi,

> Have you been able to figure out why some of the items differ in the
> two lists?

The two lists are the same if `guix build' is invoked with the
`--no-grafts' flag. I don't understand grafts very well and am not sure
how that can be fixed. Any ideas?

See different output below with and without the `--no-grafts' flag.

$ guix build python-mock

--8<---cut here---start->8---
`build-time-inputs' is
(/gnu/store/dhs3v8rfzazq9cb37pqs7fdm5hd7zmf0-python-unittest2-1.1.0)

`path' is
(/gnu/store/v70qcgga1r2m6scnard8s61dqh859mn2-python-unittest2-1.1.0/lib/python3.7/site-packages
/gnu/store/w408dkc1lynq5kqi2cxkvikalp6w35qw-python-pbr-minimal-3.0.1/lib/python3.7/site-packages
/gnu/store/bwqidwykphzv10n454kxv3hfippq8qrx-python-six-1.12.0/lib/python3.7/site-packages
/gnu/store/78w7y0lxar70j512iqw8x3nimzj10yga-python-3.7.4/lib/python3.7/site-packages
/gnu/store/k4a9433nghpjhs101cm9v8k64bmd8iqf-python-traceback2-1.4.0/lib/python3.7/site-packages
/gnu/store/3nl9hk7f59vsxgr7xmnqgc15y9c3rwpg-python-linecache2-1.0.0/lib/python3.7/site-packages)

`(remove build-time-dependency? path)' is
(/gnu/store/v70qcgga1r2m6scnard8s61dqh859mn2-python-unittest2-1.1.0/lib/python3.7/site-packages
/gnu/store/w408dkc1lynq5kqi2cxkvikalp6w35qw-python-pbr-minimal-3.0.1/lib/python3.7/site-packages
/gnu/store/bwqidwykphzv10n454kxv3hfippq8qrx-python-six-1.12.0/lib/python3.7/site-packages
/gnu/store/78w7y0lxar70j512iqw8x3nimzj10yga-python-3.7.4/lib/python3.7/site-packages
/gnu/store/k4a9433nghpjhs101cm9v8k64bmd8iqf-python-traceback2-1.4.0/lib/python3.7/site-packages
/gnu/store/3nl9hk7f59vsxgr7xmnqgc15y9c3rwpg-python-linecache2-1.0.0/lib/python3.7/site-packages)
--8<---cut here---end--->8---

$ guix build --no-grafts python-mock

--8<---cut here---start->8---
`build-time-inputs' is
(/gnu/store/m01qbb9sgymxh2xqwpnbv58h60yl4pz0-python-unittest2-1.1.0)

`path' is
(/gnu/store/m01qbb9sgymxh2xqwpnbv58h60yl4pz0-python-unittest2-1.1.0/lib/python3.7/site-packages
/gnu/store/9k5hyd9d7b3r4yzadd6phphf12l2mfc8-python-pbr-minimal-3.0.1/lib/python3.7/site-packages
/gnu/store/p8p65yd0pf95yn50iib0jw05p0n4mr9p-python-six-1.12.0/lib/python3.7/site-packages
/gnu/store/78w7y0lxar70j512iqw8x3nimzj10yga-python-3.7.4/lib/python3.7/site-packages
/gnu/store/dvn1fz82ccjg7dnqqmkxhwp720wnmriw-python-traceback2-1.4.0/lib/python3.7/site-packages
/gnu/store/vnbk5jswscv68qasfbhmh7wqlsibyism-python-linecache2-1.0.0/lib/python3.7/site-packages)

`(remove build-time-dependency? path)' is
(/gnu/store/9k5hyd9d7b3r4yzadd6phphf12l2mfc8-python-pbr-minimal-3.0.1/lib/python3.7/site-packages
/gnu/store/p8p65yd0pf95yn50iib0jw05p0n4mr9p-python-six-1.12.0/lib/python3.7/site-packages
/gnu/store/78w7y0lxar70j512iqw8x3nimzj10yga-python-3.7.4/lib/python3.7/site-packages
/gnu/store/dvn1fz82ccjg7dnqqmkxhwp720wnmriw-python-traceback2-1.4.0/lib/python3.7/site-packages
/gnu/store/vnbk5jswscv68qasfbhmh7wqlsibyism-python-linecache2-1.0.0/lib/python3.7/site-packages)
--8<---cut here---end--->8---

Regards,
Arun


signature.asc
Description: PGP signature

bug#25235: (no subject)

[Arun Isaac]

> Have you been able to figure out why some of the items differ in the two 
> lists?

Hi! Are you asking me? I haven't worked on this in a very long
time. But I'll give it another shot now and get back to you.


signature.asc
Description: PGP signature

bug#40393: Use ngettext to internationalize plural in guix/lint.scm

[Arun Isaac]

In the check-description-style function in guix/lint.scm, the string
"sentences in description should be followed ..." should be pluralized
using ngettext, not ~p as it is now. ~p only adds an 's' if the
corresponding argument is greater than 1. Needless to say, there are
many languages that don't follow this pattern.


signature.asc
Description: PGP signature

bug#39924: Issue tracker display multiple times the same issues

[Arun Isaac]

> No, I cannot reproduce any more, it looks like this is fixed, thanks !

Thanks! I'm closing this issue now.


signature.asc
Description: PGP signature

bug#39924: Issue tracker display multiple times the same issues

[Arun Isaac]

Hi,

This problem seems to have been addressed after Ricardo's recent update
of our mumi issue tracker instance.

https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00205.html

Are you still able to reproduce it?

Regards,
Arun


signature.asc
Description: PGP signature

bug#39794: AVR-Toolchain-5 avr/io not found

[Arun Isaac]

>> arm-none-eabi-toolchain is conflicting with avr-toolchain since both are
>> setting the CROSS_* environment variables. See the output of `avr-gcc -E -v 
>> -` below.
>>
>> This should probably be considered a bug. But I have no idea how to fix
>> this. :-( What do you think?
>
> I agree. The problem I see here is the environment variable game we have here.
> One option is to create cross compilers with the include paths inserted on 
> them instead of taking environment variables as a default.

Or, we could have separate environment variables CROSS_AVR_C_INCLUDE_PATH
and CROSS_ARM_C_INCLUDE_PATH. But that sounds like too many environment
variables! :-P

> If they had the correct directories in their default includepaths
> everything would work correctly.
>
> I never did this before but it should be possible, probably affecting
> cross-gcc's configure step.

Something like this is possible too.

> We can start by pushing it and then keep solving the conflict issue
> and the upgrades to gcc-9.

Agreed.

>> Also, our avr-gcc package should probably be updated to the latest
>> avr-gcc-9.
>
> Once the current fix is applied next fixes should be possible.
> Why wasn't the patch included in the project?

I don't know. I have asked Danny at bug 24416 to push the patch. Let's
wait for a response.

Once Danny's patch is pushed, I'll open a new bug reporting the arm avr
conflict.

Also, I'm closing this bug report now since this issue is handled by
24416.

Thanks! :-)


signature.asc
Description: PGP signature

bug#24416: [PATCH] gnu: avr-gcc: Fix compiler lookup paths.

[Arun Isaac]

> * gnu/packages/avr.scm (avr-gcc-4.9): Use CROSS_C*_INCLUDE_PATH (like
> cross-base does).
> (avr-gcc-5)[source]: Apply patch "gcc-cross-environment-variables.patch".

Hi,

I verified that this patch works[1]. Could you please push to master?

Thanks! :-)


signature.asc
Description: PGP signature

bug#39794: AVR-Toolchain-5 avr/io not found

[Arun Isaac]

> I can replicate what you did and it works.

Nice! :-)

> May it be conflicting with other packages?

arm-none-eabi-toolchain is conflicting with avr-toolchain since both are
setting the CROSS_* environment variables. See the output of `avr-gcc -E
-v -` below.

--8<---cut here---start->8---
Using built-in specs.
Reading specs from 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
Target: avr
Configured with: 
Thread model: single
gcc version 5.5.0 (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-specs=device-specs/specs-avr2'
 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/libexec/gcc/avr/5.5.0/cc1
 -E -quiet -v - -mn-flash=6 -mskip-bug
ignoring nonexistent directory 
"/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/../../../../avr/sys-include"
ignoring nonexistent directory 
"/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /gnu/store/1bcgk0mwxwsgjpaybvb8h4dd1xp3x19x-profile/arm-none-eabi/include
 /gnu/store/1bcgk0mwxwsgjpaybvb8h4dd1xp3x19x-profile/avr/include
 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/include
 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/include-fixed
End of search list.
--8<---cut here---end--->8---

This should probably be considered a bug. But I have no idea how to fix
this. :-( What do you think?

Also, our avr-gcc package should probably be updated to the latest
avr-gcc-9.


signature.asc
Description: PGP signature

bug#39794: AVR-Toolchain-5 avr/io not found

[Arun Isaac]

> ```
> QMK Firmware 0.7.163
> Making helix/rev2 with keymap default 
>  [ERRORS]
> In file included from drivers/avr/pro_micro.h:28:0,
>  from keyboards/helix/rev2/matrix.c:33:
> /gnu/store/gq69j5j0458dcc4jp5ymq62wgnd0mscl-profile/avr/include/avr/pgmspace.h:1456:25:
>  error: unknown type name 'uint_farptr_t'
>  extern size_t strlen_PF(uint_farptr_t src) __ATTR_CONST__; /* program memory 
> can't change */
> ```

I'm not able to reproduce this error. Could you provide the exact steps
you did? Here's what I did.

After applying the patch, drop into an environment with the new avr-toolchain.

--8<---cut here---start->8---
$ ./pre-inst-env guix environment --ad-hoc avr-toolchain
--8<---cut here---end--->8---

Check the version of avr-gcc.

--8<---cut here---start->8---
$ avr-gcc --version

avr-gcc (GCC) 5.5.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--8<---cut here---end--->8---

Check avr-gcc include paths.

--8<---cut here---start->8---
$ avr-gcc -E -v -

Using built-in specs.
Reading specs from 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
Target: avr
Configured with: 
Thread model: single
gcc version 5.5.0 (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-specs=device-specs/specs-avr2'
 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/libexec/gcc/avr/5.5.0/cc1
 -E -quiet -v - -mn-flash=6 -mskip-bug
ignoring nonexistent directory 
"/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/../../../../avr/sys-include"
ignoring nonexistent directory 
"/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /gnu/store/siwsk54afs7i2g04vmqmxzj69b4rb1rg-profile/avr/include
 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/include
 
/gnu/store/cwsiyrcm1c4c25dw0zrgajjnr9mf5k3g-avr-gcc-5.5.0/lib/gcc/avr/5.5.0/include-fixed
End of search list.
^C
--8<---cut here---end--->8---

Navigate to qmk-firmware and clean previous build results.

--8<---cut here---start->8---
$ cd qmk-firmware
$ make clean
--8<---cut here---end--->8---

I'm checking out 0.7.163 and building helix since that's what you seem
to be doing.

--8<---cut here---start->8---
$ git checkout 0.7.163
$ make helix

QMK Firmware 0.7.163
WARNING:
 Python 3 is not installed. It will be required by a future version
 of qmk_firmware.

 Please run util/qmk_install.sh to install all the dependencies QMK requires.

WARNING: Some git submodules are out of date or modified.
 Please consider running make git-submodule.

Making helix/rev2 with keymap default   
   [OK]
Making helix/rev2 with keymap edvorakjp 
   [OK]
Making helix/rev2 with keymap five_rows 
   [OK]
Making helix/rev2 with keymap five_rows_jis 
   [OK]
Making helix/rev2 with keymap froggy
   [OK]
Making helix/rev2 with keymap led_test  
   [OK]
Making helix/rev2 with keymap xulkal
   [OK]
Making helix/rev2 with keymap yshrsmz   
   [OK]
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#39794: AVR-Toolchain-5 avr/io not found

[Arun Isaac]

Hi,

I tried the last patch at bug 24416 [1] and it does fix the issue. Can
you confirm?

Regards,
Arun.

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24416#17


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> First, your patch does not apply. Because it should be line 21 and not
> 18 for the addition of your Copyright.

Sorry, I should have rebased with master.

> But as we have talked before, there is an issue about the upstream
> test suite of the package (point 1. of [1]). So I am investigating...

Ah, I understand our miscommunication now. You have been talking about
point 1 (bug in upstream test suite) and I've been talking about point 2
(segmentation fault when loading vector data). Yes, replacing proj.4
with proj only addresses point 2, not point 1.


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

Let's try to debug the problem you are facing. After applying the
attached patch, please provide the complete outputs of the following
commands. If the output is too long, feel free to send it as an email
attachment.

$ ./pre-inst-env guix build r-gdal

$ ./pre-inst-env guix environment --container --ad-hoc r r-rgdal -- Rscript -e 
'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; 
ogrInfo(dsn=dsn, layer="cities")'

Thank you for your patience! Cheers! :-)

From 7b2430788c2d168bd2a8a848e488a0e03140057b Mon Sep 17 00:00:00 2001
From: Arun Isaac 
Date: Sun, 23 Feb 2020 00:46:32 +0530
Subject: [PATCH] gnu: r-rgdal: Replace proj.4 with proj.

* gnu/packages/cran.scm (r-rgdal)[inputs]: Replace proj.4 with proj.
---
 gnu/packages/cran.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
index b731ddc29e..05759459af 100644
--- a/gnu/packages/cran.scm
+++ b/gnu/packages/cran.scm
@@ -18,6 +18,7 @@
 ;;; Copyright © 2018, 2019 Brett Gilio 
 ;;; Copyright © 2019 Nicolò Balzarotti 
 ;;; Copyright © 2019 Wiktor Żelazny 
+;;; Copyright © 2020 Arun Isaac 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -15907,7 +15908,7 @@ effect size.")
 (build-system r-build-system)
 (inputs
  `(("gdal" ,gdal)
-   ("proj.4" ,proj.4)
+   ("proj" ,proj)
("zlib" ,zlib)))
 (propagated-inputs
  `(("r-sp" ,r-sp)))
-- 
2.23.0



signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> You mean:
>
>   guix build --with-input=proj.4=proj r-rgdal
>
> then it compiles a lot... and I do not understand why gdal is
> recompiled. Anyway!

Your command recursively replaces proj.4 with proj. So, some dependency
of gdal might have been modified resulting in a rebuild of gdal.

> So after some CPU burning, I get:
>
> --8<---cut here---start->8---
> Testing examples for package ‘rgdal’
> Running specific tests for package ‘rgdal’
>   Running ‘srs_rendering.R’
>   comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
> 5c5
> < [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
> ---
>> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
> 7c7
> < [1] "GDAL 3.0.2, released 2019/10/28"
> ---
>> [1] "GDAL 2.4.0, released 2018/12/14"
> 11c11
> <
>scot_BNG
> ---
>>  
>> 
>> trin_inca_pl03
> 12c12
> < "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40
> +y_0=-10 +ellps=airy +units=m +no_defs"
> ---
>>  
>>  
>>NA
> 13c13
> <
>  trin_inca_pl03
> ---
>>  
>>   
>> kiritimati_primary_roads
> 14c14
> <
>  NA
> ---
>>  
>>"+proj=utm +zone=4 +datum=WGS84 +units=m 
>> +no_defs "
> 16c16
> <
> "+proj=longlat +datum=WGS84 +no_defs"
> ---
> <
>kiritimati_primary_roads
> ---
>>  
>>  
>>  scot_BNG
> 18c18
> <   "+proj=utm
> +zone=4 +datum=WGS84 +units=m +no_defs"
> ---
>> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40 +y_0=-10 
>> +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 
>> +units=m +no_defs "
> 22c22
> < [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
> +towgs84=0,0,0,0,0,0,0 +no_defs"
> ---
>> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
> 24c24
> < [1] "+proj=utm +zone=23 +south +ellps=aust_SA
> +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
> ---
>> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 
>> +units=m +no_defs "
> 26c26
> < [1] "+proj=longlat +datum=WGS84 +no_defs"
> ---
>> [1] "+proj=longlat +datum=WGS84 +no_defs "
> 28c28
> < [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
> +k_0=0.99987742019 +x_0=60 +y_0=220.0032
> +ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
> +no_defs"
> ---
>> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.999877420193 
>> +x_0=60 +y_0=220.00325 +a=6378249.2 +b=6356515.00472 
>> +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
> 40c40
> < file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.7
> +lon_0=-88.3 +k=0.75 +x_0=152400.30480061 +y_0=0
> +ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.66 
>> +lon_0=-88.33 +k=0.7499 +x_0=152400.3048006096 
>> +y_0=0 +datum=NAD27 +units=us-ft +no_defs
> 41c41
> < file:  cea.tif , SRS:  +proj=cea +lat_ts=33.75
> +lon_0=-117. +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> ---
>> file:  cea.tif , SRS:  +proj=cea +lon_0=-117. +lat_ts=33.75 
>> +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> 42c42
> < file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30
> +lon_0=-82.16667 +k=0. +x_0=20 +y_0=0 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30 
>> +lon_0=-82.17 +k=0. +x_0=20 +y_0=0 +ellps=GRS80 
>> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> 43c43
> < file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +ellps=WGS84
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
> ---
>> file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +datum=WGS84 +units=m 
>> +no_defs
>   Running ‘test_proj.R’
>   comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
>Running ‘tests.R’
>   comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
>   Running ‘tripup.R’
>   comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
> 266c266
> <  coords FALSE
> ---
>>  coords TRUE
> 267c267
> <  holes FALSE
> ---
>>  holes TRUE
> 273c273
> <  coords FALSE
> ---
>>  coords TRUE
> 274c274
> <  holes FALSE
> ---
>>  holes TRUE
> Running vignettes for 

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> For other packages than r-rgdal depending on proj.4:
>  - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
>  - not ok: libspatialite and libosmium

Indeed, all packages don't yet support proj. We'll have to keep proj.4
around until their upstreams adds support for proj.

> And some packages do not build at all with the default (proj.4):
> mapnik and spatialite-gui. Well, it is more than on my machine. ;-)

These will have to be fixed too. Do open separate bug reports for
those. Please provide patches if possible.

Thanks!


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

>> >  2. a regression of r-rgdal introduced by your commit
>> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>>
>> Replacing proj.4 with proj in the r-rgdal package seems to fix this
>> regression. Can you confirm?
>
> Maybe, but it is not what the user expects. Upstream explicitly
> mentions proj.4, see [1].

> [1] https://cloud.r-project.org/web/packages/rgdal/index.html

No, upstream says that both proj (aka proj6) and proj.4 are
supported. Quoting [1],

"From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..."

> The question is: why proj instead of proj.4 in libgeotiff?
> The bug [1] cannot be solved using proj.4, why?

proj and proj.4 are different versions of the same software, with proj
being the newer version. See
https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
deprecate our proj.4 package and replace all occurrences of proj.4 with
proj.

WDYT?


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> There is 2 issues in this bug report:
>
>  1. the `check' phase is failing but the build ends with "success".

I haven't investigated why this is happening.

>  2. a regression of r-rgdal introduced by your commit
> f9d328833fc1f5d0fb76b61b12d1a3cb013932e6

Replacing proj.4 with proj in the r-rgdal package seems to fix this
regression. Can you confirm?

Thanks!


signature.asc
Description: PGP signature

bug#38715: Issue with guile-email: unbound variable

[Arun Isaac]

> My best guess is that this has something to do with a circular
> reference between guile modules, but I am not certain on how to easily
> debug (and fix) this.

I updated the guile-email package two days ago. I hope that is not what
introduced this problem, and I don't see how it could have. Even `guix
build guile-email` on the terminal fails with a guile-email unbound
variable error.


signature.asc
Description: PGP signature

bug#38663: postgis is not reproducible

[Arun Isaac]

> It seems that version 3.0.0 is out for two months. I will try to
> update this first, then have a look at reproducibility. Wdyt?

I have a patch updating postgis as well as many other packages in
geo.scm. Please see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38149


signature.asc
Description: PGP signature

bug#37735: Ansible package build/installation failing

[Arun Isaac]

I felt pretty sure about this patch. So, I pushed it to
master. Meanwhile, I also updated ansible to the latest 2.8.5. I am
closing this bug report now. Please feel free to open a new bug report
in case there are any further problems.

Thanks!


signature.asc
Description: PGP signature

bug#34211: error running container: mingetty cannot find ttys

[Arun Isaac]

> so it's possible to "manually" remove the unneeded mingetty and
> console-fonts services from containers
>
> how could it be automated?  should it be automated? (IMHO yes)

I too believe it should be automated. But, I'll leave the others on this
thread to come to a decision.


signature.asc
Description: PGP signature

bug#34211: error running container: mingetty cannot find ttys

[Arun Isaac]

>> You should do something along the lines of the following:
>>
>> (remove (lambda (service)
>>   (let ((type (service-type-name (service-kind service
>> (or (eq? type 'mingetty)
>> (eq? type 'console-fonts
>> %base-services)
>
> thank you for your suggestion but this does not work

You need to use remove from (srfi srfi-1), not from (rnrs lists).

In your container-minimal.scm, replace

(use-modules (rnrs lists))

with

(use-modules (srfi srfi-1))


signature.asc
Description: PGP signature

bug#34211: error running container: mingetty cannot find ttys

[Arun Isaac]

> please any hint on how to "manually" remove those two failing services?

You should do something along the lines of the following:

(remove (lambda (service)
  (let ((type (service-type-name (service-kind service
(or (eq? type 'mingetty)
(eq? type 'console-fonts
%base-services)

Notice the function call to service-type-name.


signature.asc
Description: PGP signature

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Arun Isaac]

> The current ansible package is still brokenin the same way.

FWIW, I fixed our ansible package in
https://issues.guix.info/issue/33777 . This is not a general solution,
but at least our ansible package works at the moment.


signature.asc
Description: PGP signature

bug#34144: guix import github crash

[Arun Isaac]

> This looks fine to me.  Thanks!

Pushed, thanks!


signature.asc
Description: PGP signature

bug#34144: guix import github crash

[Arun Isaac]

I've attached a patch addressing this issue. May I push it?

From 57fa15ef15d1fdb0896ce139e1e02c459b285743 Mon Sep 17 00:00:00 2001
From: Arun Isaac 
Date: Sun, 20 Jan 2019 22:18:32 +0530
Subject: [PATCH] import: github: Check if git URIs are GitHub URIs.

This fixes a regression introduced in 9a5091d0c181453d0f31ce97f96a4e577a25e796
whereby packages with git origin URIs not hosted on GitHub would be wrongly
detected as being covered under the github updater.
Reported by Efraim Flashner .

* guix/import/github.scm (updated-github-url): Check if git URIs are GitHub
URIs.
---
 guix/import/github.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/guix/import/github.scm b/guix/import/github.scm
index b287313d98..e17ef0b840 100644
--- a/guix/import/github.scm
+++ b/guix/import/github.scm
@@ -98,7 +98,9 @@ false if none is recognized"
   (updated-url source-uri))
  ((source-uri ...)
   (find updated-url source-uri
- ((eq? fetch-method download:git-fetch)
+ ((and (eq? fetch-method download:git-fetch)
+   (string-prefix? "https://github.com/;
+   (download:git-reference-url source-uri)))
   (download:git-reference-url source-uri))
  (else #f
 
-- 
2.19.2



signature.asc
Description: PGP signature

bug#24192: Gajim fails with locale.Error

[Arun Isaac]

I'm closing this issue since it is not relevant anymore. Gajim is now
version 1.0.3, as opposed to 0.16.5 when this issue was reported. At
least as far as I can tell, this locale issue does not seem to exist
anymore.

bug#32478: pcscd service activation causes boot failure

[Arun Isaac]

> Commit de30205ba0f63eb987097a9f47b6e4fd38cd9044 added a pcscd service
> (hooray!).  However, its activation procedure doesn't always work.  The
> system test passes, and the activation procedure works the first time
> you boot, but if you reboot, it will fail because the symlink it creates
> already exists.  The attached patch fixes the problem.

Thanks for catching and fixing this! I am still in the process of
building and testing your patch. I ran out of memory and had to `guix
gc' and rebuild again. As you said, it takes a while. But, your patch
LGTM. Please go ahead and push to master at your discretion, after
addressing Ludo's feedback.

bug#32341: EXWM full screen mode broken

[Arun Isaac]

Hi Diego,

Thank you for your report. I just patched our emacs-exwm to include the
upstream fix.

Regards,
Arun.

bug#29429: Version number missing in info page

[Arun Isaac]

At (info "(Guix)Top"), the first line says "This document describes GNU
Guix version , a functional ...". The version number is
missing. However, the manual at the URL
https://www.gnu.org/software/guix/manual/guix.html has the version
0.13.0 correctly mentioned.


signature.asc
Description: PGP signature

bug#27491: Indentation issue in emacs

[Arun Isaac]

Ricardo Wurmus writes:

> Alex Kost <alez...@gmail.com> writes:
>
>> Arun Isaac (2017-06-27 11:44 +0530) wrote:
>>
>>> Ok, fixed! :-)
>>>
>>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2482c02f3b23b2490a6647e0717cf8a4ccf3f6a8
>>>
>>> However, I think this is a hack, and the better solution would be to
>>> actually fix the underlying indentation issue. But, I am too lazy to
>>> find out how. :-P
>>
>> I'm not sure what you mean by a "fix".  This is an Emacs issue, and it
>> was there since... I don't know, always.  Moreover, I don't think it's a
>> bug; it's just how Emacs finds a beginning of the top-level sexp – it
>> "sees" a leading parenthesis on a line and it considers it to be a
>> beginning of the sexp.
>
> I consider this a bug.  Surely Emacs could do better here — especially
> since this is a lisp mode!
>
> @Arun, would you like to report this as a bug to the Emacs developers?

Sure, I'll do that.

bug#27491: Indentation issue in emacs

[Arun Isaac]

> I'm not sure what you mean by a "fix".  This is an Emacs issue, and it
> was there since... I don't know, always.

Oh, my bad. I thought it was something related to guix-devel-mode or the
.dir-locals.el

> Moreover, I don't think it's a bug; it's just how Emacs finds a
> beginning of the top-level sexp – it "sees" a leading parenthesis on a
> line and it considers it to be a beginning of the sexp.

bug#27491: Indentation issue in emacs

[Arun Isaac]

Ok, fixed! :-)

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2482c02f3b23b2490a6647e0717cf8a4ccf3f6a8

However, I think this is a hack, and the better solution would be to
actually fix the underlying indentation issue. But, I am too lazy to
find out how. :-P

bug#27491: Indentation issue in emacs

[Arun Isaac]

I'm not entirely sure this is the right place to report this
bug. If I should report this bug elsewhere, please direct me.

When I indent the `emacs-which-key' package definition in
gnu/packages/emacs.scm using `indent-region', the description gets
indented wrongly. The "(or as many as space allows given your settings)"
part of the description string gets indented as though it were an
S-expression.

bug#27222: [PATCH] emacs-build-system install phase doesn't honor directory hierarchy

[Arun Isaac]

Pushed! :-)

Made a few minor modifications to the commit message...

bug#27222: [PATCH] Fix ert-runner regression

[Arun Isaac]

> Sorry I haven’t closely followed this discussion.  Arun: Could you merge
> it if that looks good to you?  I trust your judgment, comrades.  :-)

The patches are fine by me. Alex Kost is reviewing this patch. So, I
think he should push. Thanks!

bug#27222: [PATCH] emacs-build-system install phase doesn't honor directory hierarchy

[Arun Isaac]

Alex Kost writes:

> Sure, I didn't mean I was ignored, I just wanted to say that I got the
> same thought about those arguments as Maxim.

No hard feelings! :-) debbugs can be a pain to read. I thought you
missed that message from me.

> As I said, I think this duplication can be avoided simply by removing
> the values of 'include'/'exclude' arguments from 'install' procedures of
> (guix build emacs-build-system) module.

I tried something similar when I wrote the original patch, but I
couldn't get it working. Probably something to do with all the quotes
and build side/host side stuff. I didn't pursue it further when I
noticed that even the gnu-build-system duplicates default arguments.

bug#27222: [PATCH] emacs-build-system install phase doesn't honor directory hierarchy

[Arun Isaac]

> this might have to do with the fact that until recently most Elisp
> projects were organized as a single file of thousands of lines of code
> ;).

Exactly! :-)

> I've also factorized out the default args of the include and exclude
> option of the emacs-build-system install phase. Please see the two
> patches attached.

Thanks! Both patches LGTM. I just have a few doubts and minor comments.

>  (define-module (guix build-system emacs)
> +  #:use-module ((guix build emacs-build-system)
> +#:select (%default-include %default-exclude))

Interesting solution to the problem. I didn't think of this
earlier. Importing host side to build side would be a problem, but you
are importing build side to host side, and I think that's ok.

>#:use-module (guix store)
>#:use-module (guix utils)
>#:use-module (guix packages)
> @@ -28,7 +30,10 @@
>#:use-module (srfi srfi-26)
>#:export (%emacs-build-system-modules
>  emacs-build
> -emacs-build-system))
> +emacs-build-system)
> +  #:re-export (%default-include ;for convenience
> +   %default-exclude))

What is this re-export for? ert-runner seems to build fine without
this. I don't understand what you mean by "convenience" here.

Also, perhaps we should deduplicate default values of arguments in the
gnu-build-system as well. But, I don't know if it is worth deduplicating
simple default values like #t. WDYT?

@Alex Kost:

Please make any other changes you think are necessary, and push. Thanks!

bug#27222: [PATCH] emacs-build-system install phase doesn't honor directory hierarchy

[Arun Isaac]

> As far as I understand it, it was done for purpose: some packages
> include "uninteresting" (for tests, maintenance, etc.) *.el files in
> subdirs, that's why they are excluded by default.  So probably a better
> solution would be to fix 'ert-runner' package (as it is done in commit
> b1d32ec0e23bfec1dab4c56909228a494b2b0d60, for example).  WDYT?

I agree. The solution is to fix the ert-runner package, not the
emacs-build-system.

> This change also doesn't prevent excluding subfolders if they are truly
> unnecessary (such as tests subfolder), but this should happen due to
> explicit regexp in the exclude option, not because *all* subfolders are
> excluded.

We adopted the policy of excluding *all* subfolders from MELPA. From
their "Recipe Format" section at https://github.com/melpa/melpa

"Note that elisp in subdirectories is never included by default, so you
might find it convenient to separate auxiliiary files such as tests into
subdirectories to keep packaging simple."

I think this is a good policy. If we include subfolders by default,
we'll have to modify many packages with #:exclude arguments to get rid
of unnecessary subfolders. However, if we exclude subfolders by default,
we'll only have to modify fewer packages with #:include arguments.

> I also think these arguments are redundant!  I suggested to remove this
> duplication at:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26559#41

And, I did respond at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26559#53

> ... but I think the include/exclude arguments need to be duplicated in
> two places. For example, look at arguments #:strip-flags and
> #:strip-directories in the `strip' phase of the gnu-build-system. Even
> there, the default values of the arguments are repeated in two places.

Do you know of some way in which we can avoid duplication of the
arguments? Even the gnu-build-system duplicates default values of
arguments.

bug#27003: [PATCH 0/3] Generalized wrap phase for perl, python.

[Arun Isaac]

> I cannot currently make guarantees on when I'll be able to wrap my head
> around the entire problem, so if you come to conclusions for next steps
> on the basis of your testing, we should go with those.
>
> Else I will revisit this issue when I have time (which might be a
> while).

I don't have any ideas on how to fix this. And, I don't understand Guix
internals very well. So, I'll wait for you or someone else to come up
with a solution. But, I can help with testing patches.