Hello!
"Philip McGrath" skribis:
> Much to my surprise, I discovered I can avoid the problem by changing code
> for #:make-flags like this:
>
> ```
> #~(string-append "ZUO="
> #$(this-package-native-input "zuo")
> "/bin/zuo"))
Hello!
"Philip McGrath" skribis:
> Much to my surprise, I discovered I can avoid the problem by changing code
> for #:make-flags like this:
>
> ```
> #~(string-append "ZUO="
> #$(this-package-native-input "zuo")
> "/bin/zuo"))
Hi,
Felix Lechner via skribis:
> On Mon, Jul 25, 2022 at 2:52 AM Gottfried wrote:
>>
>> The manual says that it is dangerous to use: "guix gc"
>> because it can delete too much.
>
> I agree that 'guix gc' deletes too much, but it's probably not
> dangerous. You will just see some downloads and
Hi jgart,
jgart skribis:
> How can I "uninstall" guix home or have it not manage my dotfiles or a
> particular subset of dotfiles that I no longer want managed?
Good question; I don’t think there’s an easy way to escape, it’s a bit
of a trap. :-)
What I would do is something like this (untes
Hi,
Andy Tai skribis:
> Can a guix pack be partial? By that I meant one package that is not
> completely stand alone but only contains a subset of needed software,
> bundled libraries. for example, one that bundles specific version of
> gtk+ but not glibc? Of course such a package depends on
Hi Phil,
Phil skribis:
> My own experience is that whilst it doesn't require a PhD to setup Guix
> for the enterprise, it is a non-trivial journey, and it does require
> a fair amount of time and effort to create something that regular
> developers/scientists (i.e. non-Guix converts who just wan
Hello Nicolas,
Thanks for your message. Patch review is overall rather slow due to a
mixture of Guix being a victim of its success and (perhaps more
importantly) having too few people devoting time to patch review, and
too few committers committing.
This was discussed recently on guix-devel and
Vagrant Cascadian skribis:
> On 2022-08-06, Tobias Geerinckx-Rice wrote:
>> On 2022-08-06 20:48, Tobias Geerinckx-Rice wrote:
>>> guix pull: error: commit 39465409f0481f27d252ce25d2b02d3f5cbc6723
>>> not signed by an authorized key:
>>> 2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0
>>
>
Hi,
I've encountered an issue with GIO_EXTRA_MODULES from my Guix profile
preventing binaries from my foreign distro (Kubuntu 22.04) from running.
The initial symptom was that running e.g. `/usr/bin/flatpak list` would
terminate with the error:
> /usr/bin/flatpak: symbol lookup error:
> /gnu/s
On 2022-08-09 22:54, Ludovic Courtès wrote:
> This was discussed recently on guix-devel and I hope we can collectively
> improve on that. The new teams that we devised (see ‘etc/teams.scm’)
> should help, though we have yet to document them and publicize them.
Thanks for your answer, I'll check
Let's do this! My partners and I are fired up about the idea and we would like
this to be developed, along the way we continue to serve customers (or
co-creators, in our worker coop world😄).
Realistic, step by step implementation, niche to niche, until we make it big! 😄
-Yasu
> On Aug 10, 202
Hi,
On Tue, Aug 9, 2022 at 1:57 PM Ludovic Courtès wrote:
>
> Yes, this is something we should do.
For what it's worth, I now use 'history' for primary development
branches when possible. To me, it establishes a preeminence among
branches by function rather than name. Plus, I like writing "It wa
Hi,
On Tue, Aug 9, 2022 at 1:57 PM Ludovic Courtès wrote:
>
> Yes, this is something we should do.
For what it's worth, I now use 'history' for primary development
branches when possible.
For me, it establishes a preeminence among branches by function rather
than name. Plus, I like writing "It
Hi,
Why was this defined as a vector instead of a list?
(define %colors
;; See colortbl.h in Graphviz.
#("red" "magenta" "blue" "cyan3" "darkseagreen"
"peachpuff4" "darkviolet" "dimgrey" "darkgoldenrod"))
14 matches
Mail list logo
