Re: Core-updates merge
Hi John! John Kehayias writes: > Bringing back up an old thread, but > > On Fri, Apr 28, 2023 at 05:55 AM, John Kehayias wrote: > >> Dear Andreas and fellow Guix-ers, >> >> On Tue, Apr 25, 2023 at 04:09 PM, Andreas Enge wrote: >> > [...] >>> Each and every package is not yet in shape; please feel free to submit >>> patches for your favourite packages that fail to build. In particular: >>> - python-yubikey-manager does not build currently; work to correct this >>> is underway. >> >> I've just submitted <https://issues.guix.gnu.org/63139> which does a bit >> more than just fix that package and would be good for a Python feature >> branch. I'll send the cover letter to this list for wider visibility, >> though the Python team was cc'ed on the series. I suppose I should add >> myself to the team after this. >> > > Thanks to Pierre Langlois python-yubikey should now finally be fixed > on master, without all the big python build changes. (Poetry is still > broken.) This was via <https://issues.guix.gnu.org/63354>. Unfortunately > I managed to clobber the author line in the git log after editing and > testing locally, sorry about that! (Anything that can be done to fix > that?) Thank you for picking up the series! I admit I had forgotten I had sent it, I don't have too much time for Guix these days I'm afraid. Attribution is always nice of course, but mistakes happen, especially with git, so I wouln't worry about it in this instance! At least personnally I don't mind :-), just happy that the patches went in. Thanks, Pierre signature.asc Description: PGP signature
Re: Getting tree-sitter grammars in Guix
Hi all! Simon Tournier writes: > Hi, > > On sam., 04 févr. 2023 at 20:27, Demis Balbach wrote: > >> My understanding is that I need to provide emacs with tree-sitter >> support as an input for this to work, which I did, but it'll fail with >> >> --8<---cut here---start->8--- >> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such >> file or directory" "treesit") >> --8<---cut here---end--->8--- >> >> Maybe someone can help me here. I tried looking at other package >> definitions, but I don't know if there are any emacs packages that >> require tree-sitter packaged in Guix yet. > > Could you share your definition of Emacs variant allowing tree-sitter? > > Please note it is not clear for me if the tree-sitter parsers should be > provided by Guix since 1. they are auto-generated and so it is against > the effort to debootstrap and 2. they are often very large. Seeing this discussion just now, you'll probably want to take a look at the series I've been working on which addresses this (at least I hope so, reviews on the source-only bootstrapping welcome!). https://issues.guix.gnu.org/49946#215 I still need to work on it and address feedback, however I've not had any time for Guix the last couple of months. Hope this helps avoid work duplication! If people need this work in sonner than later and I'm not able to see it through in time, I'm happy for someone else to pick it up. Although hopefully I'll have some time next weekend. Thanks! Pierre > > Cheers, > simon
Re: Docker 19.x eol
Hi there, zimoun writes: > Hi, > > On Sun, 08 May 2022 at 17:33, Pier-Hugues Pellerin wrote: > >> Is there anyone working on updating the docker packages to 20.x I >> believe Guix ships with 19.x this is EOL if I remember it’s EOL. If >> someone working on it I will be happy to help. > > Indeed, Docker 19.03.15 does not seem updated [1]. Well, I do not find > any EOL mention tough. Anyway. > > Last time I have checked, the upgrade was not straightforward but I hope > you will be luckier than me. ;-) I actually sent a series to update docker here: https://issues.guix.gnu.org/52790#7. I haven't felt confident enough to push it yet, I think it needs a review, but it should be pretty straight-forward. I only tested it with a my simple use-case of a single casual ubuntu container. Hope this helps! I'll check if it needs a rebase actually. Thanks, Pierre signature.asc Description: PGP signature
Re: guix fails to build on aarch64
Hi there,
Akira Kyle writes:
> Ricardo Wurmus writes:
>> > test-name: file-needed/recursive
>> > location:
>> > /tmp/guix-build-guix-1.3.0-14.2a621f1.drv-0/source/tests/gremlin.scm:70
>> > source:
>> …
>> > + (and (zero? (close-pipe pipe))
>> > + (lset= string=?
>> > + (pk 'truth ground-truth)
>> > + (pk 'needed needed)
>> > actual-value: #f
>> > result: FAIL
>
>> Did the logs not contain the values for truth and needed? That would
>> mean that the test already failed to close the pipe.
>
> I've been trying to debug failing guix tests on aarch64. At the end of
> logfile for the gremlin test suite there's the following which may be
> related to why the truth and needed values were not printed:
>
> a.out: stripping RUNPATH to
> ("/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/gcc/aarch64-unknown-linux-gnu/10.3.0/../../.."
> "/gnu/store/40lx91wz35qci25qzi9xfqvxwby85xha-profile/lib") (removed
> ("/foo" "/bar"))
> a.out: warning: RUNPATH contains bogus entries:
> ("/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/gcc/aarch64-unknown-linux-gnu/10.3.0/../../.."
> "/gnu/store/40lx91wz35qci25qzi9xfqvxwby85xha-profile/lib")
> a.out: error: depends on 'libgcc_s.so.1', which cannot be found in RUNPATH ()
> WARNING: (test-gremlin): imported module (guix build utils) overrides
> core binding `delete'
I've also been trying to fix this test but without much luck. It
does look similar to this issue for ppc64 [0], where the `ldd/ld.so'
beaviour isn't the same as what the gremlin guile module does. However
the patch proposed there isn't fixing the issue for me either on
aarch64.
[0]: https://issues.guix.gnu.org/52940,
Maybe we can compare notes and a solution will come up :-). So the test
fails because 'truth', the result from `ldd', has ld-linux-aarch64.so
listed while 'needed', from the gremlin guile module doesn't:
--8<---cut here---start->8---
(truth ;; result from `ldd libguile.so'
("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1"
"/gnu/store/...-glibc-2.33/lib/ld-linux-aarch64.so.1" ;; This isn't
;; in gremlins
"/gnu/store/...-glibc-2.33/lib/libc.so.6"
"/gnu/store/...-glibc-2.33/lib/libcrypt.so.1"
"/gnu/store/...-glibc-2.33/lib/libdl.so.2"
"/gnu/store/...-glibc-2.33/lib/libm.so.6"
"/gnu/store/...-glibc-2.33/lib/libpthread.so.0"
"/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1"
"/gnu/store/...-libffi-3.3/lib/libffi.so.7"
"/gnu/store/...-libgc-8.0.4/lib/libgc.so.1"
"/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2"))
(needed ;; result from gremlin
("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1"
"/gnu/store/...-glibc-2.33/lib/libc.so.6"
"/gnu/store/...-glibc-2.33/lib/libcrypt.so.1"
"/gnu/store/...-glibc-2.33/lib/libdl.so.2"
"/gnu/store/...-glibc-2.33/lib/libm.so.6"
"/gnu/store/...-glibc-2.33/lib/libpthread.so.0"
"/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1"
"/gnu/store/...-libffi-3.3/lib/libffi.so.7"
"/gnu/store/...-libgc-8.0.4/lib/libgc.so.1"
"/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2"))
--8<---cut here---end--->8---
Digging a bit more I started comparing x86_64 and aarch64 binaries and
noticed that libguile.so didn't have the same dynamic section:
--8<---cut here---start->8---
# On aarch64:
$ objdump -x
/gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0
/gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0:
file format elf64-littleaarch64
...
Dynamic Section:
NEEDED libgc.so.1
NEEDED libpthread.so.0
NEEDED libffi.so.7
NEEDED libunistring.so.2
NEEDED libcrypt.so.1
NEEDED libdl.so.2
Re: Signing emails with Emacs 27.1
Giovanni Biscuolo writes:
> Hello Pierre,
>
> thanks to your recent commit (852ae64e11 gnu: Remove emacs-seq package.)
> I was able to upgrade to emacs 27.1: kudos \O/ !
>
> I'm using notmuch as MUA and experienced this signing problem too:
>
> --8<---cut here---start->8---
>
> mml-secure-epg-sign: Couldn’t find any signer names; try setting
> `mml-secure-smime-sign-with-sender'.
>
> --8<---cut here---end--->8---
>
> when trying to sign **with openpgp**, non with S/MIME (aka I use the #secure
> method=pgpmime mode=sign" tag)
>
> Pierre Langlois writes:
>
> [...]
>
>> Right, it works with these variables set:
>>
>> (setq mml-secure-openpgp-signers '("KEYID"))
>
> No need to explicitly set this if:
>
>> (setq mml-secure-opengpg-sign-with-sender t)
>^ s/gpg/pgp
oooh yes that works, thanks! GPG vs PGP was always confusing to me, if
I'm thinking about one then I'm generally typing the other... :-).
Thanks,
Pierre
signature.asc
Description: PGP signature
Re: Signing emails with mu4e (was Re: Hello, new committer here!)
Amin Bandali writes: > Pierre Neidhardt writes: > >> This is what I do to sign all my messages: >> >> (add-hook 'message-setup-hook 'mml-secure-sign-pgpmime) >> > [...] > > A word of caution: at least with Gnus, doing something like this might > "downgrade" the security of a message, by changing it to only sign the > message you're composing when normally it would have been both signed > and encrypted. It typically happens when replying to an encrypted > message. > > For that reason, I set the message to be signed only when it's not being > signed+encrypted: > > (add-hook 'gnus-message-setup-hook > (lambda () > (unless (mml-secure-is-encrypted-p) > (mml-secure-message-sign > > For non-Gnus users, I'd imagine replacing `gnus-message-setup-hook' with > `message-setup-hook' would work. That looks pretty useful, thanks for the tips! For some reasons I still have to set `mml-secure-openpgp-signers' for emacs to find the key when I press send (C-c C-c). I'm not sure what's going on, oh well, it works anyway :-). Thanks, Pierre signature.asc Description: PGP signature
Re: Signing emails with mu4e (was Re: Hello, new committer here!)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Pierre Langlois writes:
> Pierre Langlois writes:
>
>> Hello Guix,
>>
>> So, as indicated in our contributing process on the manual, I'm happy to
>> announce maintainers have agreed to give me commit access, thank you
>> everybody!
>>
>> I believe I need somebody to add my GPG keys to the Guix keyring before
>> I can push my first commit. Which I think is going to be
>> https://issues.guix.gnu.org/43138 (although, if this one is urgent,
>> don't hesitate to push it for me!).
>>
>> If I'm not mistaken, since I'm using a subkey as a signing key, it
>> should be this way (that's what I've had to do sign a personal channel):
>>
>> (;; primary: "41CA 12EA DE0C F33F 6885 A58F 5719 6E37 E00B 77FD"
>> "72D5 3D81 8CB6 F4A1 7258 374C A8FC 9E44 7F4F 7D54"
>> (name "planglois")
>
> Huh, it looks like the email signature got messed up. I'm using mu4e but
> it wasn't finding my key as it used to. I rolled-back to emacs 26 and
> that seemed to have worked, except the email sent wasn't signed
> properly.
>
> So, with this email, if I do `M-x mml-secure-message-sign-pgpmime' and
> try and send, I get a backtrace:
>
> ```
> Debugger entered--Lisp error: (error "Couldn’t find any signer names; try
> setting `mml-s...")
> signal(error ("Couldn’t find any signer names; try setting `mml-s..."))
> error("Couldn't find any signer names%s" "; try setting
> `mml-secure-smime-sign-with-sender'.")
> mml-secure-epg-sign(OpenPGP t)
> mml2015-epg-sign((part (sign . "pgpmime") (tag-location . 477) (contents .
> "Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
> mml2015-sign((part (sign . "pgpmime") (tag-location . 477) (contents .
> "Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
> mml-pgpmime-sign-buffer((part (sign . "pgpmime") (tag-location . 477)
> (contents . "Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
> mml-generate-mime-1((part (sign . "pgpmime") (tag-location . 477) (contents
> . "Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
> mml-generate-mime(nil nil)
> message-encode-message-body()
> message-send-mail(nil)
> message-send-via-mail(nil)
> message-send(nil)
> message-send-and-exit(nil)
> ```
>
> I've tried setting `mml-secure-smime-sign-with-sender' to `t' that's not
> helping. I'm not sure what's going on, are there any mu4e users here
> that can sign emails? I wonder if it's do to with the recent gnupg
> update instead of emacs.
Right, it works with these variables set:
(setq mml-secure-openpgp-signers '("KEYID"))
(setq mml-secure-opengpg-sign-with-sender t)
And using '<#secure method=gpg mode=sign>'
I'm not sure what's broken, this used to "just work" by default without
having to tell emacs where to find the signer key. mmm
-BEGIN PGP SIGNATURE-
iQEzBAEBCgAdFiEEctU9gYy29KFyWDdMqPyeRH9PfVQFAl9OPsAACgkQqPyeRH9P
fVRc5wgAyc0kPz83JHW2hel9lxD5t7ejhtjjUdGwVtHEF0kWcyt4vkfnKPL4RlwA
raZR9jGZ9siy/L6eizwhqhXs8obxOKgetiXrVhpOGBmMfKmeyjiJ1/SrgryIDoXc
826K1jzlTMcxKvF80YDrT5btmZkPHuOgDir/AMh9mCZB5nJtY75qGJzimzXHrOmN
KZiIEe0QZdB9zY+k4LSjI80QBGi8Wyj8OxlpFyr4U3dIUdyN6OVKutD6ezfP/xXY
U+HcU8KizXhiAwZxJ/9MOvL9ZPZT1T73xScTOaiUFe9i78i9bFvF/brAOGINUK/s
1TDhhRKZAys+d1t94IS5NDQgmvmqcg==
=lha/
-END PGP SIGNATURE-
Signing emails with mu4e (was Re: Hello, new committer here!)
Pierre Langlois writes:
> Hello Guix,
>
> So, as indicated in our contributing process on the manual, I'm happy to
> announce maintainers have agreed to give me commit access, thank you
> everybody!
>
> I believe I need somebody to add my GPG keys to the Guix keyring before
> I can push my first commit. Which I think is going to be
> https://issues.guix.gnu.org/43138 (although, if this one is urgent,
> don't hesitate to push it for me!).
>
> If I'm not mistaken, since I'm using a subkey as a signing key, it
> should be this way (that's what I've had to do sign a personal channel):
>
> (;; primary: "41CA 12EA DE0C F33F 6885 A58F 5719 6E37 E00B 77FD"
> "72D5 3D81 8CB6 F4A1 7258 374C A8FC 9E44 7F4F 7D54"
> (name "planglois")
Huh, it looks like the email signature got messed up. I'm using mu4e but
it wasn't finding my key as it used to. I rolled-back to emacs 26 and
that seemed to have worked, except the email sent wasn't signed
properly.
So, with this email, if I do `M-x mml-secure-message-sign-pgpmime' and
try and send, I get a backtrace:
```
Debugger entered--Lisp error: (error "Couldn’t find any signer names; try
setting `mml-s...")
signal(error ("Couldn’t find any signer names; try setting `mml-s..."))
error("Couldn't find any signer names%s" "; try setting
`mml-secure-smime-sign-with-sender'.")
mml-secure-epg-sign(OpenPGP t)
mml2015-epg-sign((part (sign . "pgpmime") (tag-location . 477) (contents .
"Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
mml2015-sign((part (sign . "pgpmime") (tag-location . 477) (contents .
"Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
mml-pgpmime-sign-buffer((part (sign . "pgpmime") (tag-location . 477)
(contents . "Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
mml-generate-mime-1((part (sign . "pgpmime") (tag-location . 477) (contents .
"Pierre Langlois writes:\n\n> Hello Guix,\n>\n> So, as ...")))
mml-generate-mime(nil nil)
message-encode-message-body()
message-send-mail(nil)
message-send-via-mail(nil)
message-send(nil)
message-send-and-exit(nil)
```
I've tried setting `mml-secure-smime-sign-with-sender' to `t' that's not
helping. I'm not sure what's going on, are there any mu4e users here
that can sign emails? I wonder if it's do to with the recent gnupg
update instead of emacs.
Thanks,
Pierre
Hello, new committer here!
Hello Guix, So, as indicated in our contributing process on the manual, I'm happy to announce maintainers have agreed to give me commit access, thank you everybody! I believe I need somebody to add my GPG keys to the Guix keyring before I can push my first commit. Which I think is going to be https://issues.guix.gnu.org/43138 (although, if this one is urgent, don't hesitate to push it for me!). If I'm not mistaken, since I'm using a subkey as a signing key, it should be this way (that's what I've had to do sign a personal channel): (;; primary: "41CA 12EA DE0C F33F 6885 A58F 5719 6E37 E00B 77FD" "72D5 3D81 8CB6 F4A1 7258 374C A8FC 9E44 7F4F 7D54" (name "planglois") Thanks, Pierre smime.p7s Description: S/MIME cryptographic signature
Re: U-boot update revert.
Hi Vagrant and Mathieu, Vagrant Cascadian writes: > On 2020-04-23, Vagrant Cascadian wrote: >> On 2020-04-23, Mathieu Othacehe wrote: >>> I reverted the U-Boot update to 2020.04 because it breaks the build of >>> u-boot-tools package. Could you please have a look? >> >> Hrm. Pretty sure it worked locally when I committed it... >> >> Unfortunately, won't have a chance to debug till next week; if anyone >> else could look into it sooner that would be great! > > I did take the time to look at the failed build log: > > https://ci.guix.gnu.org/build/2602399/details > > But the log just cuts off for no apparent reason during the unpack > phase... I don't think the new u-boot is at fault there. > > > It built successfully on i686, armhf and aarch64 ... and the failed > x86_64 test is mysteriously absent? hrm: > > https://ci.guix.gnu.org/search?query=u-boot-tools-2020.04 > > But that's not hugely surprising, given that tests are not run on those > architectures. > > Honestly, the most of the test suite run for u-boot-tools is a generic > test suite for u-boot sandbox platforms, and most of the tests are > unrelated to what u-boot-tools actually provides, so I wonder if it's > even appropriate to run many of the tests as part of u-boot-tools... > > I'm not really sure the best way forward here. I noticed the revert today and got a chance to take a look, it seems u-boot-tools can't find sdl2: ``` make[2]: sdl2-config: Command not found make[2]: sdl2-config: Command not found make[2]: sdl2-config: Command not found make[2]: sdl2-config: Command not found ../arch/sandbox/cpu/sdl.c:10:10: fatal error: SDL2/SDL.h: No such file or directory #include ^~~~ compilation terminated. ``` Switching u-boot's dependency on sdl to sdl2 fixed it for me locally! I can send a patch tomorrow if nobody beats me to it :-) Thanks, Pierre
Re: Help needed fixing linux-libre-5.2 on aarch64
Pierre Langlois writes:
>> And if I remove it then the error goes away! The build hasn't finished
>> yet for me, but it's gone past the offending xor-neon.c file so we
>> /should/ be good.
>>
>> I'm not really sure why though, do you know why this phase was required
>> at the time? I haven't tested that linux-libre still builds on x86 with
>> this phase removed yet, trying it now.
>
> OK, I've now built kernels with the attached patch on the kernel-updates
> branch for x86_64 and aarch64! I've also tested with
> --system=armhf-linux on the softiron and --system=i868-linux on my x86
> desktop, it all looks good!
> * gnu/packages/linux.scm (make-linux-libre)[arguments]: Remove
> 'work-around-gcc-7-include-path-issue phase.
> ---
> gnu/packages/linux.scm | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index 41991c9e45..d63755d791 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -35,6 +35,7 @@
> ;;; Copyright © 2019 Tim Gesthuizen
> ;;; Copyright © 2019 Maxim Cournoyer
> ;;; Copyright © 2019 Stefan Stefanović
> +;;; Copyright © 2019 Pierre Langlois
Whoops, I hadn't realized I had edited this file before, see attached
for a fixed patch.
>From 1f855451dfd4c3068eebcc09cacf79bb6df97cc8 Mon Sep 17 00:00:00 2001
From: Pierre Langlois
Date: Sun, 14 Jul 2019 12:47:06 +0100
Subject: [PATCH] gnu: linux-libre: Fix build on aarch64.
* gnu/packages/linux.scm (make-linux-libre)[arguments]: Remove
'work-around-gcc-7-include-path-issue phase.
---
gnu/packages/linux.scm | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 41991c9e45..c1a5bbebc0 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -30,7 +30,7 @@
;;; Copyright © 2018 Pierre-Antoine Rouby
;;; Copyright © 2018 Brendan Tildesley
;;; Copyright © 2018 Manuel Graf
-;;; Copyright © 2018 Pierre Langlois
+;;; Copyright © 2018, 2019 Pierre Langlois
;;; Copyright © 2018 Vasile Dumitrascu
;;; Copyright © 2019 Tim Gesthuizen
;;; Copyright © 2019 Maxim Cournoyer
@@ -355,11 +355,6 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
(substitute* (find-files "." "^Makefile(\\.include)?$")
(("/bin/pwd") "pwd"))
#t))
- (add-before 'configure 'work-around-gcc-7-include-path-issue
- (lambda _
- (unsetenv "C_INCLUDE_PATH")
- (unsetenv "CPLUS_INCLUDE_PATH")
- #t))
(replace 'configure
(lambda* (#:key inputs native-inputs target #:allow-other-keys)
;; Avoid introducing timestamps
--
2.22.0
Re: Help needed fixing linux-libre-5.2 on aarch64
> And if I remove it then the error goes away! The build hasn't finished
> yet for me, but it's gone past the offending xor-neon.c file so we
> /should/ be good.
>
> I'm not really sure why though, do you know why this phase was required
> at the time? I haven't tested that linux-libre still builds on x86 with
> this phase removed yet, trying it now.
OK, I've now built kernels with the attached patch on the kernel-updates
branch for x86_64 and aarch64! I've also tested with
--system=armhf-linux on the softiron and --system=i868-linux on my x86
desktop, it all looks good!
>From db0cd6773c54d9a8f9dd332cb20abab770e29a51 Mon Sep 17 00:00:00 2001
From: Pierre Langlois
Date: Sun, 14 Jul 2019 12:47:06 +0100
Subject: [PATCH] gnu: linux-libre: Fix build on aarch64.
* gnu/packages/linux.scm (make-linux-libre)[arguments]: Remove
'work-around-gcc-7-include-path-issue phase.
---
gnu/packages/linux.scm | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 41991c9e45..d63755d791 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -35,6 +35,7 @@
;;; Copyright © 2019 Tim Gesthuizen
;;; Copyright © 2019 Maxim Cournoyer
;;; Copyright © 2019 Stefan Stefanović
+;;; Copyright © 2019 Pierre Langlois
;;;
;;; This file is part of GNU Guix.
;;;
@@ -355,11 +356,6 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
(substitute* (find-files "." "^Makefile(\\.include)?$")
(("/bin/pwd") "pwd"))
#t))
- (add-before 'configure 'work-around-gcc-7-include-path-issue
- (lambda _
- (unsetenv "C_INCLUDE_PATH")
- (unsetenv "CPLUS_INCLUDE_PATH")
- #t))
(replace 'configure
(lambda* (#:key inputs native-inputs target #:allow-other-keys)
;; Avoid introducing timestamps
--
2.22.0
Re: Help needed fixing linux-libre-5.2 on aarch64
Hi Mark! Mark H Weaver writes: > The 'kernel-updates' includes a preliminary commit to update linux-libre > to version 5.2. Berlin has built it successfully on all supported > architectures except for aarch64, where it fails: > > https://ci.guix.gnu.org/build/1448778/details > > I would be grateful if someone with access to aarch64 hardware could > debug this and propose a fix. Until then, I'm reluctant to push this > update to 'master'. > > See below for the relevant excerpt from the build log. > > Thanks, >Mark > > > --8<---cut here---start->8--- > CC [M] arch/arm64/lib/xor-neon.o > In file included from > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:34:0, > from > /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33, > from ./arch/arm64/include/asm/neon-intrinsics.h:33, > from arch/arm64/lib/xor-neon.c:11: > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-intn.h:27:19: > error: conflicting types for 'int64_t' > typedef __int64_t int64_t; >^~~ > In file included from ./include/linux/list.h:5:0, > from ./include/linux/module.h:9, > from arch/arm64/lib/xor-neon.c:10: > ./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was > here > typedef s64 int64_t; >^~~ > In file included from > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:37:0, > from > /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33, > from ./arch/arm64/include/asm/neon-intrinsics.h:33, > from arch/arm64/lib/xor-neon.c:11: > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-uintn.h:27:20: > error: conflicting types for 'uint64_t' > typedef __uint64_t uint64_t; > ^~~~ > In file included from ./include/linux/list.h:5:0, > from ./include/linux/module.h:9, > from arch/arm64/lib/xor-neon.c:10: > ./include/linux/types.h:112:15: note: previous declaration of 'uint64_t' was > here > typedef u64 uint64_t; >^~~~ > make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o] Error 1 > make: *** [Makefile:1071: arch/arm64/lib] Error 2 > --8<---cut here---end--->8--- I have access to some hardware at the moment so I thought I'd give this a shot and yeah, I can reproduce it! I have access to a softiron board (that's the same as what's on berlin.guixsd.org right?) running Ubuntu with guix installed on top. The strange thing is, the failure only happens with building using guix, I can build linux on the board from source just fine: ``` # From a local checkout of linux (not linux-libre) ~/linux ((v5.2))$ guix environment -C linux-libre ~/linux [env]$ make defconfig ~/linux [env]$ make -j8 # OK ``` Whereas with `guix build linux-libre` I can see the error. And it still happens if I keep the build around with `guix build -K linux-libre`: ``` /tmp/guix-build-linux-libre-5.2.drv-0/linux-5.2$ source ../environment-variables /tmp/guix-build-linux-libre-5.2.drv-0/linux-5.2$ make -j8 CALLscripts/atomic/check-atomics.sh CALLscripts/checksyscalls.sh CHK include/generated/compile.h ./scripts/mkcompile_h: line 47: hostname: command not found CC [M] arch/arm64/lib/xor-neon.o In file included from /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:34:0, from /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu /7.4.0/include/arm_neon.h:33, from ./arch/arm64/include/asm/neon-intrinsics.h:33, from arch/arm64/lib/xor-neon.c:11: /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-intn.h:27:19: error: conflicting types for 'int64_t' typedef __int64_t int64_t; ^~~ In file included from ./include/linux/list.h:5:0, from ./include/linux/module.h:9, from arch/arm64/lib/xor-neon.c:10: ./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was here typedef s64 int64_t; ^~~ In file included from /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:37:0, from /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu /7.4.0/include/arm_neon.h:33, from ./arch/arm64/include/asm/neon-intrinsics.h:33, from arch/arm64/lib/xor-neon.c:11: /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-uintn.h:27:20: error: conflicting type s for 'uint64_t' typedef __uint64_t uint64_t;
Re: building from local (or private) git repository
Hi Robert, Robert Vollmert writes: > Hi all, > > I realize this isn’t generally an aim for guix proper, but I’d like > to be able to build a package from a local git repository (or > optionally from a local tar ball). In my specific case, it’s while > working out the packaging of a project I intend to publish but > haven’t published yet. > > What I have working so far uses local-file, as below: > > (define-public puzzledb-tools > (package > (name "puzzledb-tools") > (version "20190625-git") > (source > (local-file > "/home/rob/puzzledb/tools" > #:recursive? #t)) > … > > That’s a bit annoying because it includes stale files that happen > to be in the directory, it doesn’t check the hash, etc. Using a > git origin with a local path doesn’t work for reasons I don’t > completely understand — I think it’s because the guix-daemon builds > in a namespace without access to the local filesystem. Perhaps there’s > a way to link the git repository into that namespace? > > Any hints appreciated! If you're running the Guix system, you can setup a local git daemon that serves your user's repos. Here's what I have in my config: ``` (git-daemon-service #:config (git-daemon-configuration (export-all? #t) (user-path ""))) ;; To allow access to '~rob/puzzledb/tools' ``` And then I /think/ you should be able to do something like: ``` (origin (method git-fetch) (uri (git-reference (url "git://localhost/~rob/puzzledb/tools") (commit ""))) (sha256 (base32 ""))) ``` Note that's off the top of my head, I personally use this publish channels in my local network rather than package sources, but I can't think why this wouldn't work too! Pierre
