Katherine Cox-Buday writes:
Sorry, I had a bug in my format one-liner which gave versions parenthesis. This
should be copy/pastable:
--8<---cut here---start->8---
scheme@(guix import go)> (for-each (lambda (p) (format #t "gui
Demis Balbach writes:
> Hello, I was wondering what the "correct" way would be to get grammars
> for the tree-sitter library available in Guix when using tree-sitter
> with Emacs 29+.
>
> There is https://github.com/emacs-tree-sitter/tree-sitter-langs, but I
> don't think it has been packaged in
Gottfried writes:
> Is this the normal process if one package can't be buld locally?
This is what I do because only one or two packages fail to build for me
at a time, but I think you can try `guix package -u --keep-going` (I've
never used it, so I'm not positive).
--
Katherine
phodina via writes:
> Hi Guix,
Hey Petr, thanks for having a go at packaging this! It would be awesome
to have Grafana in Guix!
I was able to troubleshoot this a little. I agree with the sentiment[1][2]
that the Guix importer should just use Go tooling; however, I don't
think it's at fault
Olivier Dion writes:
> On Sun, 15 May 2022, Katherine Cox-Buday wrote:
>> At some point, after a long time with no problems, my system began
>> taking an unreasonably long time to boot. I only reboot my system
>> ~1/week for updates, so I never took the time
raingloom writes:
> On Sun, 15 May 2022 18:06:41 -0500
> Katherine Cox-Buday wrote:
>
>> At some point, after a long time with no problems, my system began
>> taking an unreasonably long time to boot. I only reboot my system
>> ~1/week for updates, so I never took th
At some point, after a long time with no problems, my system began
taking an unreasonably long time to boot. I only reboot my system
~1/week for updates, so I never took the time to debug the problem, and
therefore, I couldn't really connect the issue with any changes that
either I or Guix had
Wil deBeest writes:
>
> Wil deBeest writes:
>
>>
>> Benjamin Slade writes:
>>
>>> I'm trying to run my long-standing stumpwm init.lisp on a recent Guix
>>> install, using the packaged stumpwm, however when it launches, it
>>> fails to process the init.lisp and gives me an "Don't know how
Benjamin Slade writes:
> Are there any good examples of writing a Guix package definition using dpkg?
I'm not sure if this helps, but I had to consume a deb and wrote a package that
unpacks it to get the binary:
Maxim Cournoyer writes:
> I'd like to bring your attention to a change to the current Guix
> maintainers collective; in a nutshell, Ludovic and Marius are stepping
> down from maintainer-ship while Efraim is joining.
Thank you very much for your guidance, support, and hard work, Ludovic and
Edouard Klein writes:
I also don't know the canonical way, but I do it a different way. I'm wondering
what the simpler way to do things is? I know nothing about rlwrap. But here's
how I do things:
Depending on the project, I may have a =guix.scm= package defined for it or
not. This only
Hello again, François! I've redirected this thread to guix-devel, and
the bug since we've begun discussing implementation details.
JOULAUD François writes:
> First is to use vendored dependencies (when upstream provides them). This
> one has the merits of simplicity (as we just have to download
Guillaume Le Vaillant writes:
> Guillaume Le Vaillant skribis:
>
>> Katherine Cox-Buday skribis:
>>
>>> Sometime recently, the way Common Lisp code is compiled was changed (for
>>> the better, I think), and now my StumpWM contrib modules won't load.
>
Is it possible to define an operating-system which runs DHCP on one NIC,
and has a static address on the other?
I'm getting:
guix system: error: service 'networking' provided more than once
if i try and define service for dhcp-client-service-type and
static-networking-service.
--
Katherine
Sometime recently, the way Common Lisp code is compiled was changed (for
the better, I think), and now my StumpWM contrib modules won't load.
Here's why:
StumpWM looks[1] for .asd files to determine what is a module. Guix's
Common Lisp build system used to combine an entire system into a single
Pierre Neidhardt writes:
> Konrad Hinsen writes:
>
>> That sounds good, as does getting rid of ADSF bundles. I have more or
>> less given up on numcl, for example, which fails to compile to a bundle
>> in recent versions but seems to work find via fasls (at least it works
>> fine with
Adam Kandur via writes:
> Maybe somebody had same issue with common lisp packaging?
We've got a few lispers around with packaging experience (Pierre being
an awesome one!). In the future, please consider directing packaging
questions to guix-de...@gnu.org.
--
Katherine
Christopher Lemmer Webber writes:
> Ludovic Courtès writes:
>
>> We are thrilled to announce the release of GNU Guix 1.0.0!
>
> Massive congrats to the whole Guix community! Woohoo :)
Congratulations, everyone! Thank you for all of your hard work. Guix has
a great community, and awesome tech.
Giovanni Biscuolo writes:
> synoacl? I cannot find that mount option: are you on a Synology NAS?
Yes.
> AFAIK stripe=32 should not have any impact on mtime, nor data=writeback
>
> I'm using Guix on Debian and my store is in a LV too:
>
> /dev/mapper/vg01-gnu on /gnu type ext4 (rw,relatime)
Ricardo Wurmus writes:
> Maybe. But subsequent calls to “guix pull” should give you new store
> items anyway, and those should be fine.
That's odd. I have definitely run `guix pull` several times on this machine.
> Is there anything special about your setup perhaps? E.g. running the
> daemon
Ricardo Wurmus writes:
> Katherine Cox-Buday writes:
>
>> Gosh, I am embarassed. The compiled files are indeed in the path Guile
>> was helpfully trying to point me at:
>>
>> #+BEGIN_EXAMPLE
>> $ ls -a
>> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-g
Andreas Enge writes:
> Hello,
>
> On Wed, Apr 10, 2019 at 09:31:03AM -0500, Katherine Cox-Buday wrote:
>> Ricardo Wurmus writes:
>>
>> > You said that there are no .go files, yet Guile keeps saying that the
>> > source file
>> > /gnu/store/cd
Ricardo Wurmus writes:
> You said that there are no .go files, yet Guile keeps saying that the
> source file
> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm
> is newer than the compiled
>
Ricardo Wurmus writes:
> Oh, well, that’s definitely not right. Guix does not download
> individual files when fetching packages — it downloads archives that
> definitely do contain the .go files. So the question is… where did they
> go once “guix pull” finished?
Yeah, I don't know! Mostly
Ricardo Wurmus writes:
> This is really odd and I cannot reproduce this. I wonder if this might
> be related to some unusual file system choices or settings that cause
> Guile to think that the source files are more recent.
I have accepted that I have somehow gotten myself into a dark corner
I was wondering if anyone had any ideas? This is not blocking me from
doing anything, but it does cause a lot of spam, and it slows operations
down a lot.
Katherine Cox-Buday writes:
> Ricardo Wurmus writes:
>
>> Katherine Cox-Buday writes:
>>
>>> I'm not using
Ricardo Wurmus writes:
> Katherine Cox-Buday writes:
>
>> I'm not using Guix from a source checkout. I've issued `guix pull` (both
>> under the root account and as my user account) a few times with no
>> change.
>
> Hmm, this should never leave you with an uncom
Ricardo Wurmus writes:
> Katherine Cox-Buday writes:
>
>> I have a Guix installation on a foreign distro, and with most any Guix
>> command I receive this message for different packages (depending on what
>> command is run). I looked at one package and found that ther
I have a Guix installation on a foreign distro, and with most any Guix
command I receive this message for different packages (depending on what
command is run). I looked at one package and found that there were no
`.go` files for the `.scm` files which are listed.
I tried a few different things
29 matches
Mail list logo
