Re: Potential security weakness in Guix services

> > I’m not sure I understand the threat model. If Knot has a RCE > > vulnerability, it can be exploited to run anything on behalf of the > > ‘knot’ user. > > > > At that point, all the state associated with Knot in /var/lib should be > > considered tainted; new keys should be generated, and so

Re: Installing a wrapper guile script in /bin

> Anyway, thanks for the pointers! They motivated me to keep pushing until > something worked. Glad I could help you! signature.asc Description: This is a digitally signed message part

Re: Emacs and URLs in Git commit messages

On Thu, 2021-02-04 at 00:38 -0800, Chris Marusich wrote: > Regarding the URL, do people just type it all out, including the opening > and closing brackets (<>)? Or is there an Emacs command that does it > for you? I've briefly looked on the Internet, but this is the kind of > thing that seems

Re: An idea regarding Guix Profiles

oader to install. (It doesn't make sense to install multiple bootloaders after all). Thoughts? Maxime -- Maxime Devos PGP Key: C1F3 3EE2 0C52 8FDB 7DD7 011F 49E3 EE22 1917 25EE Freenode handle: mdevos signature.asc Description: This is a digitally signed message part

Re: Potential security weakness in Guix services

On Tue, 2021-02-02 at 14:07 +0100, Ludovic Courtès wrote: > OK, I see. Roughly, this symlink chown story would be a local exploit > that the attacker can take advantage of after exploiting the RCE to > potentially get root access. > > ‘mkdir-p/perms’ could check that the directory is not a

Re: Potential security weakness in Guix services

> I'll look into writing a concrete proposal for *at in guile. > I'll post a link to the guile mailing list message when it has > been composed and sent. Here it is: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46258 I'm not familiar with guile's code base and conventions and my TODO list is

Re: Installing a wrapper guile script in /bin

> Say I have a script that reads /proc/cpuinfo and runs my executable with the > correct flags to load the library with the best CPU features possible. How can > I embed such a script in the package definition (as a gexp?) and install it > under /bin/? Let's presume the binary is called $X. What

Re: Installing a wrapper guile script in /bin

> The script contents are not what I'm confused about. I don't know how to turn > my gexp script into a file under /bin/. This is conceptually what I want: > > (package > (name "foo") > ... > (arguments >`(... > #:phases > (modify-phases

Re: Authenticating maintenance.git

Chris Marusich schreef op wo 23-06-2021 om 18:01 [-0700]: > Although I was now able to run the pre-push hook, it seems unaware of my > PGP key. I tried making the attached change to the README and testing a > push via "git push -n origin", and it complained about the signature: > >

Re: Freezing ‘core-updates’ soon?

Ludovic Courtès schreef op di 15-06-2021 om 10:52 [+0200]: > Hello Guix! > > What about finally merging that ‘core-updates’ branch? :-) > > The main things to decide on are: [...] > > Anything else? Any patches pending review? * Fixing cross-compilation I sent a patch series fixing some

Re: What’s next?

Ludovic Courtès schreef op za 15-05-2021 om 19:47 [+0200]: > [...] > Here’s my wish list of things that look achievable within 4 to 6 months > (I hope to help on some of these): > > • [...] > > • Merging ‘core-updates’, perhaps with a switch to GCC 10? Perhaps > with support for

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

Leo Prikler schreef op za 08-05-2021 om 12:16 [+0200]: > [... something about dependencies and copyleft ...] > [...] > However, compliance is not *that* simple. If you're dealing with > copyleft, providing the source is not enough, you also need to license > your own work under that copyleft

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

Leo Prikler schreef op zo 09-05-2021 om 01:04 [+0200]: > > and insteads prefers something with basically no licenses. I meant to write ‘and instead prefers something with basically no restrictions at all’. here. > > I would find it interesting to know if some ‘legal people’ have > > worked

Re: Expat 2.3.0 has been released

0, but it needs some testing. Greetings, Maxime. From f87aa1ef0ecfcda27c798ecfd140ce3b33218ddc Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sun, 9 May 2021 11:05:14 +0200 Subject: [PATCH] gnu: expat: Add graft for 2.3.0 [security fixes] There will be security fixes in the upcoming 2.4.0 release.

Re: Expat 2.3.0 has been released

I see Leo Prikler has already sent a patch (48...@debbugs.gnu.org). signature.asc Description: This is a digitally signed message part

Re: Expat 2.3.0 has been released

Leo Famulari schreef op zo 09-05-2021 om 10:07 [-0400]: > On Sun, May 09, 2021 at 02:53:09PM +0200, Sebastian Pipping wrote: > > The related soversions are: > > > > 2.2. 9 = 7:11:6 -> libexpatso.1.6.11 (GUIX today) > > 2.2.10 = 7:12:6 -> libexpatso.1.6.12 > > 2.3. 0 = 8: 0:7 ->

Re: What’s next?

Ludovic Courtès schreef op za 15-05-2021 om 19:47 [+0200]: > Hello Guix! > > So, now that 1.3.0 is out the door, what’s next?! > > Here’s my wish list of things that look achievable within 4 to 6 months > (I hope to help on some of these): [...] Distributing substitutes over IPFS. The original

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

Ludovic Courtès schreef op do 06-05-2021 om 18:30 [+0200]: > BTW, a dream of mine was to implement RPCs in Scheme. That is, you’d > have a macro that would essentially do the same work as MiG (the Mach > Interface Generator), and then we’d pass the bytes directly to > ‘mach_msg’. The lisp

Re: [PATCH RFC 0/4] Getting rid of input labels?

Ludovic Courtès schreef op do 20-05-2021 om 16:58 [+0200]: > Hello Guix! > > Here’s a proposal for a soft revolution: getting rid of input labels > in package definitions. Instead of writing: [...] > > one can write: > > (native-inputs (list autoconf automake pkg-config guile-3.0)) >

Re: [PATCH RFC 0/4] Getting rid of input labels?

Ludovic Courtès schreef op wo 26-05-2021 om 15:43 [+0200]: > Hi Maxime, >[...] > In many cases, you don’t need the ability to refer to a specific input; > you just need all the inputs to contribute to search path environment > variables, and that’s enough. A “label collision” does not matter at >

Re: Question: wrap-program without #:sh can be ok even when cross-compiling?

Leo Prikler schreef op zo 06-06-2021 om 09:39 [+0200]: > I think we might want to export a utility procedure > (patch-shebangs files inputs) This procedure already exists, but is undocumented and unexported. It is in (guix build gnu-build-system). (define* (patch-shebangs #:key inputs

Question: wrap-program without #:sh can be ok even when cross-compiling?

About (the ‘wrap-program #:sh’ patch series): While looking at guix/build/gnu-build-system.scm, I noticed the 'patch-shebangs' phase, which is run after the install phase. IIUC, this phase is for changing shebangs ... #!/usr/bin/stuff to ...

Re: Adding Substitute Mirrors page to installer

raid5atemyhomework schreef op ma 31-05-2021 om 09:42 [+]: > bump > > bump To me it seems all questions have been addressed, though I was not involved in the discussion. So, maybe time to merge? See for the patches.

Re: Effectively force all GNOME users to locally compile ZFS?

Mark H Weaver schreef op za 03-07-2021 om 15:33 [-0400]: > [...] > > gnu: libvirt: Support ZFS. > > * gnu/packages/virtualization.scm (inputs): Add zfs. > --8<---cut here---end--->8--- > > If I understand correctly, this will effectively force all

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

Joshua Branson schreef op za 01-05-2021 om 11:04 [-0400]: > Hey guix people, > > I just ran across a pretty recent thread in bug-hurd land. Apparently > there is a VERY WIP effort to get some guile-scheme bindings for GNU > Mach and the Hurd. > > Since it might be of interest to guixy people, I

Re: [bug#47615] [PATCH v2 09/12] gnu: mercurial: Skip tests on powerpc-linux.

Efraim Flashner schreef op do 22-04-2021 om 10:59 [+0300]: > * gnu/packages/version-control.scm (mercurial)[arguments]: Skip tests on > powerpc-linux. > --- > gnu/packages/version-control.scm | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > Unchanged since last patchset, IMO not

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

Ludovic Courtès schreef op zo 02-05-2021 om 22:51 [+0200]: > > [...] moved it to ;. > > Nice! I knew of the Common Lisp effort this is based on, and the idea > of reusing the .lisp code unchanged is smart. Looks promising! The initial idea was to keep

Re: ZFS on Guix

On Mon, 2021-02-08 at 09:32 +, raid5atemyhomework wrote: > > * the shepherd services defined in `configuration.scm` > > seem one-shot services to me, so maybe add '(one-shot? #t)'. > > I was wary of making the `zfs-scan` one-shot, since there is a dependent > service on top of it. Not to

Re: ZFS on Guix

Hi raid5atemyhomework, I can't help you with ZFS, but I think I've found some small issues with the configuration file: * the shepherd services defined in `configuration.scm` seem one-shot services to me, so maybe add '(one-shot? #t)'. * in the 'stop' of zfs-automount, the code changes the

Re: Potential security weakness in Guix services

On Fri, 2021-02-05 at 13:20 +0100, Maxime Devos wrote: > On Fri, 2021-02-05 at 10:57 +0100, Ludovic Courtès wrote: > > [...] > [...] > > I'll try to implement this API in Scheme (using the FFI), and post > it at https://notabug.org/mdevos/things. I'll post a follow-up

Re: Potential security weakness in Guix services

On Fri, 2021-02-05 at 10:57 +0100, Ludovic Courtès wrote: > Hi Maxime, > > > I don't know how I should implement this properly in Guile, though. > > In C, I would use loop using openat with O_NOFOLLOW, in combination > > with stat, but Guile doesn't have openat or O_NOFOLLOW. > > In this case

Re: Potential security weakness in Guix services

On Fri, 2021-01-29 at 14:33 +0100, Maxime Devos wrote: > Hi Guix, > [...] > > Below is a summary of their messages, including a mitigation proposal. > > Your feedback is requested! > > I'm writing a patch right now. It's a little more elaborate than my > mkdir-p/

Re: Potential security weakness in Guix services

Hi Guix, On Thu, 2021-01-28 at 16:53 -0500, Leo Famulari wrote: > On January 19 2021, we received a message from Maxime Devos describing a > potential attack vector on Guix System. > > If an attacker can exploit a remote code execution vulnerability (RCE) > in a program used by

Re: Bring KDE into Guix easily

On Sun, 2021-01-31 at 17:15 +0100, Hartmut Goebel wrote: > Hello everybody, > > are you interested in getting KDE into Guix? > Not much of a KDE user myself (except kcachegrind, a drawing application I forgot the name of and manuskript), but more packages are nice! > I prepared a repo providing

Re: Specify runtime dependencies with propagated-inputs or wrapper scripts

On Fri, 2021-03-26 at 20:36 +0100, Léo Le Bouter wrote: > Hello! > > I often meet problems where some packages don't work out of the box > because they have some runtime dependencies like themes or third party > programs. > > I solved these problems on occasion by making commits such as this: >

Re: [PATCHES] ImageMagick security updates without grafting

On Sat, 2021-03-27 at 09:09 -0400, Mark H Weaver wrote: > Hello Guix, > > Here's a proposed patch set that will henceforth enable us to freely > update ImageMagick (and dblatex, and gtk-doc) on our 'master' branch > without grafts. This is done by adding variables 'imagemagick/stable', >

Re: Packaging

Hi, On Sat, 2021-03-27 at 07:37 +, mecqor labi wrote: > Please package shadowsocks-rust for Guix! Is there any reason the "shadowsocks" package is not usable for you? Also, feel free to package it yourself (See the manual for how) and note the folks at guix-devel@gnu.org don't (often) take

Re: [PATCHES] ImageMagick security updates without grafting

On Sat, 2021-03-27 at 20:01 -0400, Mark H Weaver wrote: > [...] > Maxime wrote: > > What does ‘guix refresh --list-dependent imagemagick@6.9.11-48’ > > output now? > When I last checked, it reported on the order of 2400 dependent package > rebuilds. I should have written imagemagick@6.9.12-4

Re: Packaging

Please keep guix-devel@gnu.org in CC: or To:. On Sun, 2021-03-28 at 10:18 +, mecqor labi wrote: > Thanks for your help, > The Shadowsocks package does not work in Guix at all, and this has been > reported over the developers of Guix, but it has never been solved. > About Tor, this is not

Re: Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting)

On Sun, 2021-03-28 at 18:33 -0400, Mark H Weaver wrote: > Earlier, I wrote: > > One thing to be very careful about is to only use 'gtk-doc/stable', > > 'dblatex/stable', and 'imagemagick/stable' in native-inputs, and > > moreover to make sure that no references to these */stable packages > >

Re: [PATCHES] ImageMagick security updates without grafting

On Sun, 2021-03-28 at 17:37 -0400, Mark H Weaver wrote: > Maxime Devos writes: > > > On Sat, 2021-03-27 at 20:01 -0400, Mark H Weaver wrote: > > > [...] > > > Maxime wrote: > > > > What does ‘guix refresh --list-dependent imagemagick@6.9.11-48’ >

Re: Petition to remove hidden flag from cmake-minimal package

On Wed, 2021-03-31 at 13:17 -0400, Tom Hiller wrote: > Could cmake-minimal be made publicly available as a version of cmake > without the documentation dependencies? I believe the only thing > preventing this is the hidden flag inherited from cmake-bootstrap. Technically, yes, but why? What's

Re: Petition to remove hidden flag from cmake-minimal package

On Thu, 2021-04-01 at 16:36 -0400, Tom Hiller wrote: > I am using it with pack I assume as "guix pack cmake other-package ..."? This seems a valid use case, although there is a case to be made to only make the ‘fully capable’ packages visible. In any case, you can work around this with guix

Re: Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting)

On Sun, 2021-04-04 at 16:14 -0400, Mark H Weaver wrote: > Maxime Devo wrote: > > * In some places we have the following pattern: > > > > [...] > I don't understand this. Why would it need to be made unconditional? I don't understand either anymore. > [...] > > At the present time, I'm more

Re: Commit pushed to master with unauthorised signature

On Thu, 2021-03-11 at 00:15 +0100, Taylan Kammer wrote: > [...] > Damn, sorry about that. I assumed of course that an improperly signed > commit would not be accepted, so I didn't pay any special mind. > > However, I also assumed that adding a new GPG key to my savannah.gnu.org > account would

Re: A Critique of Shepherd Design

On Fri, 2021-03-19 at 17:33 +, raid5atemyhomework wrote: > GNU Shepherd is the `init` system used by GNU Guix. It features: > > * A rich full Scheme language to describe actions. > * A simple core that is easy to maintain. > > However, in this critique, I contend that these features are

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

On Tue, 2021-03-16 at 15:29 -0400, Leo Famulari wrote: > > [...] > > No, sorry :) Someone else (maybe an i686 user?) will have to find the > time to test it. I haven't tried the patch, but note that x86-64 systems are also i686 systems, so users of x86-64 systems can try ./pre-inst-env guix

Re: TOCTTOU race

On Tue, 2021-02-23 at 16:30 +0100, Ludovic Courtès wrote: > Hi, > > Maxime Devos skribis: > > > Is all addressed now? (Aside from the TOCTTOU.) > > Yes, thank you! If all is addressed now, could you apply the patch? I don't see it in master yet and I don't have c

Re: Test failures on new build

On Mon, 2021-04-12 at 20:50 -0500, Stephen Paul Weber wrote: > > Could you attach tests/guix-git-authenticate.log? > > Likewise. > > Likewise. > > Likewise. > > Attached. Can you verify the directory of your guix checkout is "/home/singpolyma/src/guix"? * tests/guix-git-authenticate.sh: This

Re: Test failures on new build

On Sun, 2021-04-11 at 21:29 -0500, Stephen Paul Weber wrote: > [...], but I get these failures: > > FAIL: tests/guix-git-authenticate.sh Could you attach tests/guix-git-authenticate.log? > PASS: tests/workers.scm > make[4]: *** [Makefile:5605: tests/derivations.log] Error 1 Likewise. > make[4]:

Re: [Outreachy] - Guix Data Service - Set a more informative page title

On Tue, 2021-04-13 at 18:56 +0300, Canan Talayhan wrote: > [...] > After sending the patch I've turned the patch like below. > (title ,(if title > `,(string-append title " - Guix Data Service") > '("Guix Data Service"))) A little more simplification is possible:

Re: [Outreachy] - Guix Data Service - Set a more informative page title

On Tue, 2021-04-13 at 12:01 +0300, Canan Talayhan wrote: > Hi everyone, Welcome! > My name is Canan. I'm an Outreachy applicant. I'm working on the introductory > task for > Guix Data Service. Is this ‘introductory task’ publicly available? If so, could you post a link? I'm not up-to-date with

Re: Potential security weakness in Guix services

On Sat, 2021-02-06 at 22:28 +0100, Ludovic Courtès wrote: > Maxime Devos skribis: > > I just remembered this subtlety: during bootup, the activation code is > evaluated by the Guile that’s in the initrd, which is a > statically-linked Guile, and thus we can’t use ‘dyn

TOCTTOU race (was: Potential security weakness in Guix services)

asic cups"'. I couldn't test all affected services, unfortunately, due to lack of system tests. Thoughts? Greetings, Maxime. From ad10c577eb1f13b9b66ea387648671df33b869d7 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sun, 14 Feb 2021 12:57:32 +0100 Subject: [PATCH] services: prevent f

Re: TOCTTOU race

ected now. Please take note that I didn't correct all potentially insecure activation gexps. These should ideally be done by someone who knows how to use the particular service and have a system to test it on. (My changes to nscld-service-type and knot-activation are untested.) Greetings, Maxime

Re: TOCTTOU race

Maxime. From 395208e1e8e1ab6dd3eb5739b2726f06a49e0041 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sun, 14 Feb 2021 12:57:32 +0100 Subject: [PATCH] services: Prevent following symlinks during activation. This addresses a potential security issue, where a compromised service could trick

Re: How did you handle making a GNU/Linux distribution?

Sage Gerard schreef op za 21-08-2021 om 16:43 [+]: > Hi folks, > > My name is Sage. I wrote a cross-platform Guix-like package manager > called Xiden. It applies functional package management to the Racket > ecosystem. [...] > I'd greatly appreciate learning how you all built Guix's

Re: Regarding copyright assignment to FSF

Damien Zammit schreef op do 12-08-2021 om 12:18 [+1000]: > Hi Ludo, I'm not Ludo, but here's my response anyway. (I'm interested in doing some small and larger things with the Hurd, but I keep being occupied by other things and I'm having a hard time understanding the inner workings ...) > On

Re: How did you handle making a GNU/Linux distribution?

Sage Gerard schreef op ma 23-08-2021 om 18:24 [+]: > Thank you for the links! > > > I miss which problem Xiden is solving and how it does. > > You are not the first to say so, and I'm happy to learn more about why. > > I'll try to explain in a different way here, so forgive the text wall.

[PATCH] Allow choosing the nl_NL.UTF-8 locale.

It's 100% translated according to . Warning: I don't have a Guix Data Service to test this with. * guix-data-service/model/package-metadata.scm (locales): Add nl_NL.utf-8 --- guix-data-service/model/package-metadata.scm | 1 + 1 file

Re: Can we find a better idiom for unversioned packages?

Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]: > Hello Guix, > > Currently, there are about 1500 packages defined like this: > > --8<---cut here---start->8--- > (define-public sbcl-feeder > (let ((commit

Re: packaging go-ethereum, and ultimately bee (of ethswarm.org)

Hi, Warning: I haven't actually ever touched a go package. Take my mail with a huge grain of salt. Much of this you've probably already heard at . Attila Lendvai schreef op ma 30-08-2021 om 21:52 [+]: > [...] > so, regarding

Re: Wireguard

crodges schreef op zo 29-08-2021 om 14:53 [-0700]: > Hello everyone, > > Let me start thanking you for developing such a interesting project in GNU > Guix. Also, I don't want to take up anyone's time, so you can just point to > documentation or other resource succinctly and I'll do my best. I'm

Re: Can we find a better idiom for unversioned packages?

> > (define-public sbcl-feeder > > (name "sbcl-feeder") > > (version (extended-version > > (base "1.0.0") > > (revision 1) > > (commit "b05f517d7729564575cc809e086c262646a94d34"))) > > (source > > (origin > > (method git-fetch) > > (uri

Re: Can we find a better idiom for unversioned packages?

Liliana Marie Prikler schreef op wo 01-09-2021 om 15:33 [+0200]: > Hi > > Am Dienstag, den 31.08.2021, 23:20 +0200 schrieb Maxime Devos: > > Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]: > > > Hello Guix, > > > > > > Currently,

Re: packaging go-ethereum, and ultimately bee (of ethswarm.org)

Attila Lendvai schreef op wo 01-09-2021 om 14:29 [+]: > On Wednesday, September 1st, 2021 at 00:21, Maxime Devos > wrote: > > > Hi, > > > > Warning: I haven't actually ever touched a go package. Take my mail > > with a huge grain of salt. > > Muc

Re: Can we find a better idiom for unversioned packages?

Liliana Marie Prikler schreef op wo 01-09-2021 om 23:47 [+0200]: > > https://guix.gnu.org/manual/en/html_node/Invoking-guix-download.html > Imo the only thing awkard about guix download is that it only handles > tarballs when a large chunk of packages use some sort of version > control. We might

Re: Can we find a better idiom for unversioned packages?

> > > > > 2. We cannot get at the source location for the definition of > > > > > 'commit' or 'revision'. This would be useful for updating > > > > > these > > > > > packages with `guix refresh -u`. There is a proposed patch [0] > > > > > to > > > > > work around this, but it *is* a workaround.

Re: Can we find a better idiom for unversioned packages?

Liliana Marie Prikler schreef op do 02-09-2021 om 16:20 [+0200]: > Am Donnerstag, den 02.09.2021, 16:09 +0200 schrieb Maxime Devos: > > > > > > > 2. We cannot get at the source location for the definition > > > > > > > of > > > > > &g

[bug#50347] [RFC PATCH] lint: Warn about kernel modules with a suspect license.

a GPL violation?) at <https://issues.guix.gnu.org/45692#43>. Greetings, Maxime. From 851cf20b7d5aed45c3331781afef8de3961f4bb4 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Thu, 2 Sep 2021 23:30:15 +0200 Subject: [PATCH] lint: Warn about kernel modules with a suspect license. * guix/lint.

Re: [bug#50347] [RFC PATCH] lint: Warn about kernel modules with a suspect license.

I've discussed this with dstolfa on IRC: https://logs.guix.gnu.org/guix/2021-09-02.log#234707 https://logs.guix.gnu.org/guix/2021-09-03.log Greetings, Maxime. signature.asc Description: This is a digitally signed message part

PEP 668 -- Graceful cooperation between external and Python package managers

See . I haven't looked closely into this myself. It might be relevant to Guix. For LWN subscribers, there is an article about the PEP: . Greetings, Maxime. signature.asc Description: This is a digitally signed message

Re: Rethinking propagated inputs?

Liliana Marie Prikler schreef op zo 05-09-2021 om 18:50 [+0200]: > [...] > > (Feel free to suggest a more concise name.) > Since "propagated" is already given by propagated-inputs, what about > simply having #:by? > E.g. something like: [...] > (define glib > (package > (name "glib")

Re: Rethinking propagated inputs?

Liliana Marie Prikler schreef op zo 05-09-2021 om 21:37 [+0200]: > > > I must admit that this solution appears to have some surface > > > elegance, but what exactly would go in the "build" output of a > > > package? You mentioned pkg-config files (obviously), but those > > > don't suffice to

Re: Rethinking propagated inputs?

Liliana Marie Prikler schreef op za 04-09-2021 om 20:24 [+0200]: > Hi Guix, > > some while ago we made the decision to propagate inputs, that are > mentioned in pkg-config files, the rationale being that those > propagated inputs will be needed in packages in order to compile. This > has saved

Re: Why linux-libre source code is not in sources.json

Hi, > [...] > > where ’make-linux-libre-source’ returns a ’computed-origin-method’. And > the ’origin-uri’ of ’linux-libre-5.14-pristine-source’ is a ’gexp’. > Then inside this ’gexp’, you can read the ’%upstream-linux-source’ URL: > > --8<---cut

Re: Transform options: check if applied or not

zimoun schreef op do 09-09-2021 om 00:29 [+0200]: > Why? It is fixed-output so I was expecting the same thing. And the > same as: > > --8<---cut here---start->8--- > $ guix download https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz > > Starting download

Re: gcc: build all languages at once?

Ludovic Courtès schreef op wo 08-09-2021 om 23:08 [+0200]: > > We could also possibly reuse the 'core' parts of GCC between language > > frontends, saving some space. (This is what distros seem to do.) > > That’d be ideal, but I’m not sure it’s feasible. It’s feasible for FHS > distros that

Re: avoid wrapper scripts when possible

Hi, Attila Lendvai schreef op di 07-09-2021 om 18:52 [+]: > pardon me for reviving a years old discussion, but i'm facing the same > problem once again. > > i have updated trezor support, and i wanted to test generating a new gpg key: > > $ trezor-gpg init "foobar " > > leading to:

Re: avoid wrapper scripts when possible

Attila Lendvai schreef op wo 08-09-2021 om 09:20 [+]: > thanks for the ideas Maxime! > > > > You could patch trezor-agent with something like > > > > Python syntax might be incorrect > > > > > > if sys.argv[0] == ".trezor-gpg' > > sys.argv[0] = "trezor-gpg"

Re: How to solve "abiI-check: recompilation needed"

Maxim Cournoyer schreef op vr 17-09-2021 om 16:03 [-0400]: > Hello, > > Ricardo Wurmus writes: > > > Hartmut Goebel writes: > > > > > Hi, > > > > > > quite often, after "git pull" I'm facing this error when running > > > "make-make-go": > > > > > > $ make make-go > > > Compiling Scheme

Re: Python Site Package Syntax Runtime Error

Antwane Mason schreef op di 07-09-2021 om 13:39 [-0400]: > Has anyone come across the following runtime error when running a python-based > application in guix? I'm wondering if something went wrong during the package > build > for python-onlykey-agent that messed up the PYTHONPATH export for

Re: On the naming of System and Home services modules.

Andrew Tropin schreef op wo 15-09-2021 om 11:47 [+0300]: > *** Confusion > I already mentioned that I see a lot of confusion between System and > Shepherd services and I expect some confusion between home and system > services, it will be especially true if we place them in the same > namespace. >

Re: Rethinking propagated inputs?

Liliana Marie Prikler schreef op zo 05-09-2021 om 23:10 [+0200]: > Am Sonntag, den 05.09.2021, 22:27 +0200 schrieb Maxime Devos: > > Liliana Marie Prikler schreef op zo 05-09-2021 om 21:37 [+0200]: > > > > > I must admit that this solution appears to have some surface >

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

Xinglu Chen schreef op vr 24-09-2021 om 17:39 [+0200]: > [...] > I didn’t know about the parent mechanism; that could be an approach to > take. But since ‘define-configuration’ is based on (guix records), > would it make sense to adapt (guix records) to (rnrs records syntactic) > instead of

Temporarily unavailable for hacking on guix

Hi guix, TL;DR: I won't be available for a while, so please remove me from guix-security and http://guix.gnu.org/en/security/ and don't expect replies on existing issues. The computer I usually use (where the usual gpg, e-mail, git, IRC, guix itself ... is all set-up) (no worries, there

Re: Wireguard

crodges schreef op wo 06-10-2021 om 09:28 [-0700]: > [...] > I was able to create and run the vm. How can I build a .iso image with my > code > changes to install in a vps? I tried to change the code, compile, run > > guix system image -t iso9660 gnu/system/install.scm Don't forget

Re: Wireguard

crodges schreef op wo 22-09-2021 om 09:03 [-0700]: > On Wednesday, September 1, 2021 12:07:43 A.M. PDT Maxime Devos wrote: > > crodges schreef op zo 29-08-2021 om 14:53 [-0700]: > > > Hello everyone, > > > > > > Let me start thanking you for developing such a i

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]: > Maxime Devos skribis: > > > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]: > > > Hi, > > > > > > Joshua Branson skribis: > > > > > > > Apologies if I'm speaki

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

Ludovic Courtès schreef op ma 04-10-2021 om 16:32 [+0200]: > Maxime Devos skribis: > > > Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]: > > > Maxime Devos skribis: > > > > > > > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]: > On Thu, Sep 23 2021, Ludovic Courtès wrote: > > > Hi, > > > > Xinglu Chen skribis: > > > > > Some services might be useful to have in both Guix System and Guix Home; > > > for instance, Guix System currently has a service for configuring

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]: > Hi, > > Joshua Branson skribis: > > > Apologies if I'm speaking for something I know very little > > about...Wouldn't it be nice if guix home services would accept a user > > and a group field? For the syncthing service, perhaps the

bug#52284: Partially unifying packages and inferior packages

X-Debbugs-CC: guix-devel@gnu.org Hi guix, There have been some bug reports with as root cause that inferior packages aren't packages. I think that root cause is a bug. To resolve this, there was some talk on using GOOP classes, or define-gexp-compiler-style polymorphism for

Re: Commit ‘gnu: ghc-8.10: Disable failing test on i686.’ has a cross-compilation bug

Lars-Dominik Braun schreef op za 06-11-2021 om 12:07 [+0100]: > Hi Maxime, > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=89de1924cb535fc2c97d3654e21badaebd43518e > > > > > +   ,@(if (string=? "i686-linux" (%current-system)) > > […] > > > > Barring any reports of the

Commit ‘gnu: ghc-8.10: Disable failing test on i686.’ has a cross-compilation bug

Hi, About this commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=89de1924cb535fc2c97d3654e21badaebd43518e > + ,@(if (string=? "i686-linux" (%current-system)) > + '((add-after 'skip-more-tests 'skip-failing-tests-i686 > + (lambda _ > +

Re: Commit ‘gnu: ghc-8.10: Disable failing test on i686.’ has a cross-compilation bug

Lars-Dominik Braun schreef op zo 07-11-2021 om 11:17 [+0100]: > Hi Maxime, > > > Currently, non-Linux is not supported by the GHC package.  However, > > people learn how to package things by example (and by reading > > documentation, etc.), so I'd prefer to avoid (accidentally) > > teaching > >

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

Vagrant Cascadian schreef op vr 22-10-2021 om 14:15 [-0700]: > [...] > Though, it is *possible* that various u-boot-BOARD in some cases > doesn't > include any openssl code at all in the resulting binaries, but builds > some tools used during the build process, that are then used to > produce >

Assisting reviewing & committing with tags?

Hi guix reviewers and committers, WDYT of tagging reviewed patches that look good with a usertag, e.g. 'reviewed-looks-good': https://debbugs.gnu.org/cgi/pkgreport.cgi?tag=reviewed-looks-good=guix then if a committer doesn't have much time to review and hence doesn't subscribe to guix-patches@,

Re: Return back original implementation for text-config serialization

Andrew Tropin schreef op zo 09-01-2022 om 12:12 [+0300]: > [...] There is another less generalized example, which demonstrates > how > serialization of sway configuration works right now. > > --8<---cut here---start->8--- > `((include ,(local-file

Re: Return back original implementation for text-config serialization

Andrew Tropin schreef op zo 09-01-2022 om 12:12 [+0300]: > [...] There is another less generalized example, which demonstrates > how > serialization of sway configuration works right now. > > --8<---cut here---start->8--- > `((include ,(local-file

  1   2   3   4   5   >