How to use Guix with sssd, not nscd, on a foreign distro?

Hi, The Guix manual recommends running nscd: https://guix.gnu.org/manual/en/html_node/Application-Setup.html However, Fedora intends to remove it: https://fedoraproject.org/wiki/Changes/RemoveNSCD The document says: "The hosts cache will automatically be replaced by the one provided by

Re: License of your contributions to the blog at guix.gnu.org

Hi, Ludovic Courtès writes: > Hello, > > I am emailing you on behalf of the GNU Guix project because you are the > author or coauthor of one or more articles to the blog at > . > > With a few exceptions, these articles do not have a clear license, which > we would

Re: version-1.4.0 branch updated

Hi Maxim, I've CC'd Mathieu on this email because he sent an email recently asking for help with the 1.4.0 release, and Ludo because he was working on bug 52752. Maxim Cournoyer writes: > Hi Maxime, > > Maxime Devos writes: > >> Efraim Flashner schreef op di 11-01-2022 om 12:39 [+0200]: >>>

Re: guix fails to build on aarch64

Hi Pierre, Thank you very much for the details! I have added this information to the existing bug report: https://issues.guix.gnu.org/52943 Please direct further discussion regarding this bug there, so that people looking at the bug report will see an accurate record of the investigation so

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Maxim, Maxim Cournoyer writes: > Hello Chris, > > Chris Marusich writes: > >> Maxim Cournoyer writes: >> >>> About the current status, I'm nearing on pushing a version-1.4.0 branch >>> which is based on master with a few more (core-ish) up

Re: Release v1.4 (or 2.0): process and schedule ?

Maxim Cournoyer writes: > About the current status, I'm nearing on pushing a version-1.4.0 branch > which is based on master with a few more (core-ish) updates. There's > still a few days ahead of that, so if you manage to get many of this > kind of problems fixed & merged in master they can

Re: bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Thiago Jung Bauermann writes: > GDB uses the shell to launch the debugged program. That is probably where > ‘/bin/sh’ is entering the picture here. I don’t know whether that has any > relation to your foreign distro’s libc being used. > > The output of `help run` in GDB mentions that the shell

Re: bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Hi Kaelyn, Thank you for the reply. Kaelyn writes: > Are you using Guix on a foreign distro? This line looks like your > distro's normal libc.so was being used and it was from glibc-2.31 or > older. The x86-64 systems I have that run pure Guix don't have any > /lib*/ directories. You might try

Re: bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Hi, I need a little help figuring out how to use gdb in Guix for bug 48941: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48941 Here's the situation. A libfaketime test hangs forever. Upstream suggested I debug it. I'm trying to, but gdb errors out. What am I doing wrong? It's probably

Re: bug#49337: Guix pull fails on my Talos II

Hi Tobias, Were you able to "guix pull" successfully? -- Chris signature.asc Description: PGP signature

Re: Debbugs Usertags - which user to use?

Maxim Cournoyer writes: > Hello, > > Chris Marusich writes: > > [...] > >> Yes, my understanding is that the user "guix" would also work. >> >> I think it would be fine to use the user "guix" instead of >> "guix-devel@gnu.o

Re: bug#49337: Guix pull fails on my Talos II

Hi, FYI, I was able to successfully "guix pull" from 83f8b6d (Apr 09) to c33e200 (Jul 02) just now on my own POWER9 machine (a Blackbird). -- Chris signature.asc Description: PGP signature

Re: bug#49337: Guix pull fails on my Talos II

Hi Tobias, Tobias Platen writes: > /gnu/store/vc2j3816jx9z4vgrw6zmk357xrka3zy0-texlive-latex-amsmath-51265.drv > wird erstellt … > \ „build“-PhaseBacktrace: > 13 (primitive-load > "/gnu/store/y5sniqlw2x5aaixyk4bw162v2a7bwdpl-compute-guix-derivation") > In ice-9/eval.scm: > 155:9

Debbugs Usertags - which user to use? (Was: Re: GNU Guix 1.4.0 in September?)

Hi Maxim, Maxim Cournoyer writes: > Hello Chris, > > Chris Marusich writes: > > [...] > >> I intend to try to get POWER9 working on core-updates before the next >> release. Hopefully the recent upgrade to GCC 10 will make it easier. > > Neat! > >&

Re: Debbugs user tags

Ludovic Courtès writes: >> * doc/contributing.texi (Contributing): Update the short description of the >> "Tracking Bugs and Patches" chapter in the menu. >> (Tracking Bugs and Patches): Split this section into three new subsections, >> titled "Debbugs", "Debbugs User Interfaces", and "Debbugs

Re: Authenticating maintenance.git

Chris Marusich writes: > Hi Ludo, > > Ludovic Courtès writes: > >> It looks like you’re missing a local ‘keyring’ branch for that repo, no? >> >> I think you need to run: >> >> git fetch >> git branch --track keyring > > This works,

Re: Debbugs user tags

150658/ > > Should we add some text (and conventions?) to “Tracking Bugs and > Patches” in the manual about usertags? Sounds like it could be useful. How's this? -- Chris From f640132745b26b19bd163bc67482e8aea041881b Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Tue, 22 Jun 2021

Re: Authenticating maintenance.git

Hi Ludo, Ludovic Courtès writes: > It looks like you’re missing a local ‘keyring’ branch for that repo, no? > > I think you need to run: > > git fetch > git branch --track keyring This works, basically. Thank you! Details: When master is currently checked out, that "git branch" command

Re: Freezing ‘core-updates’ soon?

Ludovic Courtès writes: > Hello Guix! > > What about finally merging that ‘core-updates’ branch? :-) > > The main things to decide on are: > > • Upgrading to GCC 10? I know Marius has spent time looking at it and > fixing build failures caused by the upgrade. Can we do it? > > •

Re: GNU Guix 1.4.0 in September?

Maxim Cournoyer writes: > Perhaps we can aim for the next release mid-September (core-updates). > I'm not too sure of the status of core-updates right now, but last time > I worked on it was in a rather good state. I intend to try to get POWER9 working on core-updates before the next release.

Re: Authenticating maintenance.git

Ludovic Courtès writes: > Hello Guix! > > I’ve added a ‘.guix-authorizations’ file in maintenance.git, at last! > We can now authenticate the repository we’ve checked out: > > guix git authenticate 8a7e10b447b574279a7016ae6ea15bc7bcd46253 \ > "3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A

Re: GNU Guix 1.3.0rc2 available for testing!

Hi Maxim, Maxim Cournoyer writes: > Sorry for the delayed answer. No worries! I've waited even longer in replying to you now, so we're even. :-) > The go importer depends on a recent version of guile-lib (0.2.7), which > added a new #:strict argument to the HTML parser. We should probably

Re: GNU Guix 1.3.0rc2 available for testing!

Hi, Maxim Cournoyer writes: > A second RC for the upcoming 1.3.0 release is now available for testing: Thank you for preparing it! I tested the binary installation using the guix-install.sh script for 1.3.0 (not the rc2 candidate, but the actual 1.3.0 release, which I noticed was on the FTP

Re: The purpose of the "license" list of a Guix package

Chris Marusich writes: > In the end, I think a packager is expected to be operating in good > faith, in accordance with the FSDG. This means that packagers look for > freedom issues and address them when found. It does not mean that > packagers are expected to provide a de

The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)

Hi, Leo Famulari writes: > On Sun, May 02, 2021 at 12:53:07AM -0400, Mark H Weaver wrote: >> My understanding is that the 'license' field of a package in Guix has >> _always_ been meant to summarize the license restrictions associated >> with the package source (the output of "guix build

Re: bug#47615: [PATCH 1/9] gnu: bootstrap: Add support for powerpc-linux.

Chris Marusich writes: > Efraim Flashner writes: > >> On 923bb70a1bff657125c3008f119a477e5cb57c2b >>gnu:glibc-for-bootstrap: Fix patch. >> >> Run >> ./pre-inst-env guix build --target=powerpc-linux-gnu bootstrap-tarballs g

Re: GNU Guix 1.3.0rc1 available for testing!

Maxim Cournoyer writes: > A first RC for the upcoming 1.3.0 release is now available for testing I tested the binary for powerpc64le-linux on a Debian 10 ppc64el system. It seems to be behaving as well as I expected it to. Thank you for preparing it! On powerpc64le-linux, the installation

Re: Leaving the GNU Guix community

Hi Léo, I'm sorry to hear that you feel that you need to leave the community. I can understand why you feel that way, but I hope you'll remember that (to my knowledge) nobody has said that they don't want you here. I realize that in this moment, it must sting terribly to have your commit rights

Re: bug#47615: [PATCH 3/9] gnu: binutils: Adjust test suite on powerpc-linux.

Efraim Flashner writes: >> If it's a test failure, has the issue been reported upstream? > > I'll check to see if I can find something upstream. If not I'll report > it. FWIW Debian disables the test suite for powerpc. > https://sources.debian.org/src/binutils/2.36.1-6/debian/rules/#L537 How

Re: bug#47615: [PATCH 3/9] gnu: binutils: Adjust test suite on powerpc-linux.

Chris Marusich writes: > (define binutils-boot0 > (package > (inherit binutils) > (source (bootstrap-origin (package-source binutils))) > (name "binutils-cross-boot0") > (arguments > `(#:guile ,%bootstrap-guile >#:implicit-inpu

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

Efraim Flashner writes: > * gnu/packages/base.scm (binutils)[arguments]: Add phase on > powerpc-linux to adjust the test suite. > * gnu/packages/commencement.scm (binutils-boot0)[arguments]: Move custom > phases after inherited arguments. Add phase on powerpc-linux to adjust > the test suite.

Re: bug#47615: [PATCH 2/9] gnu: guile-3.0: Fix building on powerpc-linux.

Efraim Flashner writes: > * gnu/packages/guile.scm (guile-3.0)[arguments]: On powerpc add two > phases to adjust for 32-bit big-endian systems. > --- > gnu/packages/guile.scm | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) > > diff --git a/gnu/packages/guile.scm

Re: bug#47615: [PATCH 1/9] gnu: bootstrap: Add support for powerpc-linux.

Efraim Flashner writes: > On 923bb70a1bff657125c3008f119a477e5cb57c2b >gnu:glibc-for-bootstrap: Fix patch. > > Run > ./pre-inst-env guix build --target=powerpc-linux-gnu bootstrap-tarballs > > Producing > > /gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0 > > With

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

Efraim Flashner writes: > * gnu/packages/debug.scm (american-fuzzy-lop): Add case for > powerpc-linux. > (qemu-for-american-fuzzy-lop): Same. > --- > gnu/packages/debug.scm | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/gnu/packages/debug.scm b/gnu/packages/debug.scm > index

Re: Please review blog post draft: powerpc64le-linux support

Hi, Chris Marusich writes: > This is the final draft, I think. I intend to commit it to the "posts" > directory in guix-artwork on Monday morning, USA time, at which point I > believe it will automatically show up on the blog. I have pub

Re: Please review blog post draft: powerpc64le-linux support

et me know. -- Chris From e4300631958b75d996b9b57c595e74539da5f938 Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Tue, 6 Apr 2021 00:10:35 -0700 Subject: [PATCH] website: drafts: Add powerpc64le-linux announcement. * website/drafts/new-system-powerpc64le-linux.md: New file. --- .../drafts/

Re: Please review blog post draft: powerpc64le-linux support

Hi Tobias, Thank you very much for taking the time to review the blog post! Tobias Platen writes: > On Fri, 09 Apr 2021 00:59:44 +0200 > Léo Le Bouter wrote: > >> On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote: >> > They also say in that Twitter thread: "

Re: Please review blog post draft: powerpc64le-linux support

Vincent Legoll writes: > Why only speaking of Talos and not about the 3rd option: the blackbird ? > Maybe just concentrate on the vendor, more than on particular models... I specifically avoided speaking about the Blackbird, only because it's not yet RYF-certified. However, perhaps I'm being

Re: Please review blog post draft: powerpc64le-linux support

I think it's just about done! -- Chris From 4d9133e51fc666f14074c1da18bb16af0d76066f Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Tue, 6 Apr 2021 00:10:35 -0700 Subject: [PATCH] website: drafts: Add powerpc64le-linux announcement. * website/drafts/new-system-powerpc64le-linux.md: New fi

Re: Please review blog post draft: powerpc64le-linux support

Hi Léo, Léo Le Bouter writes: > It's been mostly you here Chris, thank you so much for writing it, as > others said, it is really beautifully written! Unfortunately I havent > felt enough peace of mind to write like you did :-( You've been busy! It's totally understandable. The encouragement

Re: Please review blog post draft: powerpc64le-linux support

Hi Joshua, Joshua Branson writes: > Awesome! Great work! I read the below draft blog post like a Harry > Potter novel! It is superbly written. And it makes a lot of sense! Thank you for the kind words, and your feedback! >> +### Why Is This Important? >> + >> +This is important because it

Please review blog post draft: powerpc64le-linux support

!). The secondary goal is to explain some of the details about what we did, and invite people to get involved. Your feedback would be highly appreciated! -- Chris From 8900d918106f6a70b20df461c5f086b5275773cc Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Tue, 6 Apr 2021 00:10:35 -0700 Subject

Re: Security related tooling project

Christopher Baines writes: > Chris Marusich writes: > >> Christopher Baines writes: >> >>> In terms of looking at security from a project perspective, I'm thinking >>> about these kinds of needs/questions: >>> >>> - What security iss

Re: Security related tooling project

Christopher Baines writes: > In terms of looking at security from a project perspective, I'm thinking > about these kinds of needs/questions: > > - What security issues affect this revision of Guix? (latest or otherwise) > > - How do Guix contributors find out about new security issues that >

Re: I have merged wip-ppc64le-for-master to master

Ludovic Courtès writes: > Chris Marusich skribis: > >> FYI, I have merged wip-ppc64le-for-master to master and closed bug >> 47182. I have also deleted the wip-ppc64le-for-master branch. > > Yay, congrats! \o/ > > I now have access to the OSUOSL POWER9 ma

I have merged wip-ppc64le-for-master to master

Hi, FYI, I have merged wip-ppc64le-for-master to master and closed bug 47182. I have also deleted the wip-ppc64le-for-master branch. Later this week, I will update the manual to mention that powerpc64le-linux is supported, and I will update the "release" target of the Makefile so that we can

Re: Let's include powerpc64le-linux in the next release, Re: Let's include powerpc64le-linux in the next release

Tobias Geerinckx-Rice writes: > Ludovic Courtès 写道： >> Like Efraim wrote, the person who makes the release (I’m afraid >> it’ll be >> me) needs to be able to offload to a “trustworthy” machine for that >> platform. > > Define trustworthy? The project has access to an 8-core POWER9 VM > from

Re: Release 1.2.1: status

Hi simon, zimoun writes: > First, thanks to Chris and folks, powerpc64le-linux will be [1] in the > next release, great! Isn’t it? :-) I'm very excited about this! Efraim was able to rework our patches so they could be applied to master without rebuilding the entire world. The patches are

Re: I've rebased wip-ppc64le onto core-updates, Re: Release on April 18th?

Hi Ludo, Ludovic Courtès writes: > Maybe you could “formally” ask for a review of the branch when you think > it’s ready (perhaps even git-send-emailing the patches to guix-patches, > for convenience), and then we can merge in ‘core-updates’ (if/when that > matches other branch scheduling

Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

Hi, I have good news! Chris Marusich writes: > Subject: [PATCH] syscalls: mount: Fix a matching bug. If there are no concerns about this patch, I will commit it to master (with the "mount" typo fixed so it reads "mounts") in the next few days. > Efraim Flashner wr

Re: Release on April 18th?

Chris Marusich writes: > Subject: [PATCH] syscalls: mount: Fix a matching bug. In the patch message, "mount" should be "mounts". Sorry for the typo! -- Chris signature.asc Description: PGP signature

Re: Release on April 18th?

orking on getting you access to ppc64le hardware or a VM. Andreas Enge writes: > Am Fri, Mar 12, 2021 at 12:33:18AM -0800 schrieb Chris Marusich: >> The proc man page has this to say about column 7: >> (7) optional fields: zero or more fields of the form "tag[:value]" >

Re: Release on April 18th?

Hi Efraim and Ludo, Efraim Flashner writes: > My plan was absolutely to merge master into core-updates after and then > integrate all the changes into their affected packages. I'd also make > sure to bump gcc to 8 (assuming we don't go straight to 9). Sounds good. If we can get

Re: Release on April 18th?

Vincent Legoll writes: > I'm all for that, what can I do to help ? Thank you for offering to help! > I don't have a Talos, though... > > So only cross- or emulated- stuff... > > Willing to help, but needs directions. I can probably also set you up with a temporary multi-core VM for testing,

Re: Release on April 18th?

Hi Efraim, Efraim Flashner writes: > I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master, > which cherry-picked (I think) all of the powerpc64le commits and > adjusted them to work against master WITHOUT affecting other > architectures. It looks like you modified "gnu: glibc:

Re: I've rebased wip-ppc64le onto core-updates

Hi, I've rebased wip-ppc64le again just now onto the latest core-updates. There were no conflicts. Because I committed 5d2863dfe4613d5091e61800fcd5a48922c8ce4e and 001fc29b43fd0beb365d536774fae96624309413 directly to core-updates before rebasing, I removed some similar commits from wip-ppc64le

Re: Release on April 18th?

Hi, zimoun writes: > Is it doable to have core-updates merged in the next weeks? Or not at > all. Do we plan to upgrade GCC? This is required for the powerpc64le-linux port; see below for details. The wip-ppc64le branch, which ports Guix to an architecture that can be run on

Re: core-updates: Emacs is only supported on x86_64-linux?

Chris Marusich writes: > How about a patch like the following - would it be acceptable to you? Actually, I've realized that that patch wasn't quite right. I've attached a corrected version to this email. Although the %current-system parameter will look like "x86_64-linux" becaus

Re: core-updates: Emacs is only supported on x86_64-linux?

Hi, Mark H Weaver writes: > Ugh. I'd prefer to avoid removing 'gtk+' from the inputs to 'emacs' on > any system, because the distinguishing characteristic of that package > (compared with the other Emacs variants) is that it's the Gtk+ variant > of Emacs. How about a patch like the following

Re: core-updates: Emacs is only supported on x86_64-linux?

t you actually have to also do it for gtk+, too, since rust gets pulled in via gtk+ also. So, something like this: From 649c89e5862e1ed887f5fd863ef7bb32f97bbe74 Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Sun, 7 Mar 2021 17:42:37 -0800 Subject: [PATCH] gnu: emacs: Use librsvg and gtk+ o

core-updates: Emacs is only supported on x86_64-linux?

Hi, I've noticed that the emacs package only supports x86_64-linux, at least on core-updates. Is that intended? I noticed because it caused "make check" to fail on the wip-ppc64le branch (which is based on core-updates). I fixed one failing test on the wip-ppc64le branch by using coreutils

I've rebased wip-ppc64le onto core-updates

Hi Léo and others, I just wanted to let you know that I've rebased the wip-ppc64le branch onto core-updates. The wip-ppc64le branch head used to be 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's df5d633db7acf6389ca9d444b8f5784a0da5ac5d. I wanted to inform you so you don't get caught

Re: 02/03: tests: gremlin: Skip file-needed/recursive if DT_NEEDED is empty.

Hi Ludo, Ludovic Courtès writes: > guix-comm...@gnu.org skribis: > >> +++ b/tests/gremlin.scm >> @@ -61,7 +61,12 @@ >> (elf-dynamic-info-needed dyninfo)) >> >> (unless (and %guile-executable (not (getenv "LD_LIBRARY_PATH")) >> - (file-needed

Re: Branch management, wip-ppc64le, and POWER9

Hi, Christopher Baines writes: > I think rebasing introduces issues with commit signatures, since you'd > then be signing others commits. If multiple people are committing to the > branch, I'd treat it like staging/core-updates, and merge rather than > rebasing. Leo Famulari writes: > The

Re: Emacs and URLs in Git commit messages

Hi, Thank you for the replies! Maxime Devos writes: > I don't known any emacs command for that, but you inspired me to write > such a command myself: [1]. > > Maxime. > [1]: > https://notabug.org/mdevos/things/commit/b0400ba06b6f031e88f1f89b47079c3c6d7dcac4 zimoun writes: > I am not

Branch management, wip-ppc64le, and POWER9

Hi, Since I'm now making commits on wip-ppc64le to add support for POWER9 machines like the Talos II and Blackbird from Raptor Computing Systems, I'd like to understand more about how I am expected to manage that branch. Before I touched it, it sat with just one lonely commit, essentially

Emacs and URLs in Git commit messages

Hi, Many Guix commits look like this: commit f9978346e73359ac1d8b88c9ed874edc7225582b Author: Ludovic Courtès Date: Fri Dec 18 18:10:04 2020 +0100 avahi: Remove poll timeout when possible. Fixes . * guix/avahi.scm

PowerPC: reference to static-bash-for-glibc in binutils-final

Hi Efraim, The other day, I asked on IRC why it's OK for binutils-final to refer to static-bash-for-glibc on powerpc architectures, like in commit 2da8fcfdee7cfde8110a68806f3c4d497f217fe5, but it isn't OK on other architectures. You said, "there's an extra file that's a bash script specific to

Re: guix build -d with a target causes many builds

Hi Chris, Christopher Baines writes: > Grafts. > > → guix build --no-grafts -d --target=powerpc64-linux-gnu -e '(@@ (gnu > packages make-bootstrap) %gcc-static)' > /gnu/store/i5wn3xl6p0zw1vglscgk0bs9dwc6hdh6-gcc-static-5.5.0.drv > > They're on by default, so when you use -d without

Re: guix build -d with a target causes many builds

Chris Marusich writes: > Hi, > > I've noticed that Guix builds many things when I ask it to instantiate a > derivation in the following way: > > [0] [env] marusich@garuda-lan:~/guix/repos/guix-worktrees/wip-ppc64 > $ guix build -d --target=powerpc64-linux-gnu -e '(@@

guix build -d with a target causes many builds

Hi, I've noticed that Guix builds many things when I ask it to instantiate a derivation in the following way: [0] [env] marusich@garuda-lan:~/guix/repos/guix-worktrees/wip-ppc64 $ guix build -d --target=powerpc64-linux-gnu -e '(@@ (gnu packages make-bootstrap) %gcc-static)' The following

Re: [bug#45252] [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le., [bug#45252] [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le., [bug#45252] [PATCH] gn

's truly no extra burden, then you could change "--batch" to > "--force" on line 69 of libffi.c (in the "powerpc-*" case). OK. I've made this change on master in commit 662e7e28d576ada91fc9dec7d27c100666114f03. Mark H Weaver writes: > Hi Chris, > > C

Re: [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.

Hi Mark, Mark H Weaver writes: > Earlier, I wrote: >> When invoking 'patch' in Guix, you should *always* use "--force" instead >> of "--batch". > > (See for my earlier message). Thank you for letting me know about this. I didn't know about the difference

Re: Makefile logic to create Guix documentation

Hi Julien, Julien Lepiller writes: > Not sure for the rest, but .dot.eps: is similar to: > > %.eps: %.dot > > You often find .c.o in Makefiles for instance. Ohhh, I see! With this info, I was able to determine that the relevant information is documented, but I just missed it (see: (make)

Helping with powerpc64-linux

Hi Léo, As you know, I'm still investigating why the powerpc64-linux bootstrap binaries (really just GCC) are not reproducible [1]. Eventually, if we can't figure it out, we might want to just bite the bullet and use the non-reproducible bootstrap binaries to get started, but I'm hopeful we can

Makefile logic to create Guix documentation

Hi Ludo, I was reading through the Makefile that creates the documentation, and I came across some parts I couldn't understand, even though I spent a few hours trying to figure it out. I thought you might know the answers to my questions off the top of your head, since I think you wrote it.

Re: Request to verify powerpc64-linux bootstrap binaries

Hi Vincent, Jack, and Maxim, Thank you for the quick replies! OK, so gcc differs for each of us: * Chris: 8aca7f332a1ba8e3c2225c161a7545b0a04ddd690d164dc97afee9c9ea067b0c49bc155e9f06d285c22e24cdd16d91e59730af5f1dd9efcda13a26bede5948a2 * Vincent:

Request to verify powerpc64-linux bootstrap binaries

Hi everyone! Thanks to Léo's help, as of commit 8159ce1970d91567468cf1bacac313099a009d2a, the master branch now contains all the changes necessary to cross-compile powerpc64-linux bootstrap binaries. I've done this without substitutes by running the following commands on an x86_64-liinux

Re: G-Expressions and Scope Preservation

Hi Ludo, Ludovic Courtès writes: > Hello! > > Chris Marusich skribis: > >> In your paper "Code Staging in GNU Guix" [1], you use the following >> example to illustrate how G-Expressions are hygienic ("they preserve >> lexical scope acro

Re: G-Expressions and Scope Preservation

zimoun writes: > the Unison language Thank you for sharing the link! I only read the overview, but I can see why this makes you think of G-Expressions. It's always interesting to read about how content addressability can make some problems easier. > I cannot wait for your presentation at

G-Expressions and Scope Preservation

Hi Ludo, In your paper "Code Staging in GNU Guix" [1], you use the following example to illustrate how G-Expressions are hygienic ("they preserve lexical scope across stages"): (let ((gen-body (lambda (x) #~(let ((x 40)) (+ x #$x) #~(let ((x 2))

Re: Documenting Yubikey setup

Hi Martin, Martin Becze writes: > For a user to access a Yubikey an udev rule needs to be added. This can > be done by using the udev rules found in libu2f-host package. To use the > rules the following should be added to your config.scm > > (use-modules (gnu packages security-token)) > > ... >

Re: Overhauling the cargo-build-system

Hi, Ludovic Courtès writes: > What I would have liked is to somehow replace the #:cargo-inputs > argument (which is build-system-specific and thus “opaque”) with regular > ‘native-inputs’ or ‘inputs’ field. That would be nice. However, it doesn't seem possible to express Cargo's

Re: New POWER9 machines for the Guix build farm?

Tobias Geerinckx-Rice writes: > Fellow Guix, > > The Guix sysadmins are considering buying shiny hardware for the > ci.guix.gnu.org build farm, and it would be awesome if that included > our first POWER9 machine(s)! > > However, few (if any) Guixers have any hands-on experience with this >

Re: guix pull failed after 8 hours

Konrad Hinsen writes: > Hi Ludo and Chris, > >> Could it be that those old systems were talking to hydra.gnu.org and >> thus not getting any substitutes? >> >> https://lists.gnu.org/archive/html/info-guix/2019-06/msg1.html > > That's what happened to me on my oldest Guix installation

Re: guix pull failed after 8 hours

Hi Giovanni and everyone, Giovanni Biscuolo writes: > Chris Marusich writes: > > [...] > >> Has anyone run "guix pull" successfully recently? I have been trying >> for days without success. > > I was also able to run guix pull on a foreign system a fe

guix pull failed after 8 hours

Hi, After 8 hours of waiting, "guix pull" failed with this message: srfi/srfi-1.scm:592:17: In procedure map1: Throw to key `srfi-34' with args `(#)'. guix pull: error: You found a bug: the program '/gnu/store/cgwq319bn468wr2vrnfih4l7k9wdiqi8-compute-guix-derivation' failed to compute the

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Mark H Weaver writes: > I have good news and bad news. The good news is that thanks to the > heroic efforts of Amin Bandali , a recently appointed > co-maintainer of GNU IceCat, there now exists a preliminary version of > IceCat 68 that builds successfully and works on Trisquel. I'm subscribed

Re: Multiseat in Guix

Brendan Tildesley writes: > I don't know how to do this but I've always been fascinated by it, so I > just wanted to bump this and say that I think it's a really important > feature to get working (eventually), because for example schools can set > up a computer lab of 30 workstations using only

Multiseat in Guix

Hi, Guix does not seem to have multiseat support. What would it take to add it? Is anyone on the list familiar with how multiseat is achieved in other distros, such as Fedora? Here is an example of a problem that happens because we don't have good multiseat support: When I launch virt-manager

Re: fftwf tests running for 25+ hours - is this normal?

Hi Bengt, Matteo, and others, I've stopped the build. The process ran for 73 hours and didn't complete. I've also noticed that there are no recent builds in Cuirass, so I wonder: has anyone built fftwf successfully recently? I was trying to build fftwf based off of what is currently in the

Re: fftwf tests running for 25+ hours - is this normal?

Hi Bengt and Matteo, Bengt Richter writes: > Have you checked sensors for overheating that might induce CPU clock > throttling? Actually, yes, I happened to be watching dmesg output at the time, and I did notice these messages (no similar messages have been printed since then, which was many

fftwf tests running for 25+ hours - is this normal?

Hi, I've been trying to reconfigure my system on my x200 laptop. It's been a day or two, and I've found that my computer has spent the last 25 hours running fftwf tests. I know my laptop is rather weak (2 cores, 8 GB of memory, an SSD) compared to most desktops today, but still, 25 hours seems

Re: i686-linux GCC package on x86_64

Ricardo Wurmus writes: > Chris Marusich writes: > >> That said, I am curious about something. If I want to make a >> cross-compiler available for the purpose of hacking around on some code >> and cross-compiling it, is there an equivalent to "guix package -i >

Re: i686-linux GCC package on x86_64

Danny Milosavljevic writes: > On Fri, 04 Oct 2019 17:46:43 +0200 > Jelle Licht wrote: > >> Mathieu Othacehe writes: >> >> > >> > --8<---cut here---start->8--- >> > (native-inputs >> > `(,@(if (not (string-prefix? "i686" (%current-system))) >> >

Re: Maintainer needed for Linux-libre and IceCat packages

Hi Mark, Mark H Weaver writes: > I need to take a break from Guix. I'm not sure if I'll be back or not. > Someone else should take over maintenance of the Linux-libre and IceCat > packages, starting with the recent kernel updates for 4.4.192, 4.9.192, > 4.14.143, 4.19.72, and 5.2.14. Thank

Re: 01/01: services: Add ‘/usr/bin/env’ special file.

Hi everyone, Ricardo Wurmus writes: > Using a custom script with a /usr/bin/env shebang is pretty common. You > don’t need to be a power user for that, and certainly not a *Guix* power > user. > > [...] > > Personally, I think it’s a good idea to default to having /usr/bin/env > shebangs just

Re: bug#36855: guix system switch-generation doesn't

Hi Robert, Robert Vollmert writes: > On 8. Aug 2019, at 18:40, Chris Marusich wrote: >> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: >> >>> 'switch-to-system-generation' doesn't call out to >>> 'upgrade-shepherd-services'. I'm not sure if thi

Re: "python setup.py test" is deprecated

Marius Bakke writes: > Pythons setuptools are deprecating the "python setup.py test" command: > > https://github.com/pypa/setuptools/issues/1684 > > As you may know, "python setup.py test" is what python-build-system does > during the 'check' phase. > > I'm not sure what we should do about it,

Re: bug#36855: guix system switch-generation doesn't

Hi Jakob, zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: > 'switch-to-system-generation' doesn't call out to > 'upgrade-shepherd-services'. I'm not sure if this was an intentional > decision or not It is intentional, but only because there is currently no way to call

  1   2   3   4   5   6   7   >