Hi Danny,
Danny Milosavljevic writes:
[...]
> A user package (for example if referred to by a system service) would
> propagate-input the kernel module package it requires.
Yes! \O/
[...]
> The limitation of it not be possible for a regular user to add kernel
> modules is OK I think.
When I
Hello fellow Guix,
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.
The bad news is that IceCat
Hi Kei and Florian,
"pelzflorian (Florian Pelz)" writes:
> On Sat, Oct 19, 2019 at 11:29:33PM -0400, Kei Kebreau wrote:
>> I've pushed my changes to the following repository for anyone who wants
>> to take a look:
>>
>> https://notabug.org/kei/guix-gnome-updates
>
> I tried reproducing your fai
Hi John,
John Soo writes:
> I have packaged PureScript in a channel and I would like to merge it
Cool!
> Some of its dependencies are from hackage and are much newer than
> those in the stackage snapshot we use. So my question is where should
> the dependencies belong?
Maybe we should just b
Mathieu Othacehe writes:
> Hello Christopher,
>
>> +(define* (main #:optional (args (command-line)))
>> +
>> + ;; Always have stdout/stderr line-buffered.
>> + (setvbuf (current-output-port) 'line)
>> + (setvbuf (current-error-port) 'line)
>
> I must admit I've not been following very closely
A patch to guix master which
* Puts the kernel modules (including any other packages that have "lib/modules"
inside their derivation) into /run/booted-system/profile/lib/modules
* Ensures that depmod is invoked on that
* Makes the modprobe wrapper use it
is provided below.
The case when there's
Pierre Neidhardt writes:
> Ricardo Wurmus writes:
>
>> It’s one thing to install all files that the plain text database says
>> should be installed. They all exist in the SVN repo. It’s quite
>> another to generate them all from their respective sources.
>
> Nix separates them all, it provid
Hi guix,
I have packaged PureScript in a channel and I would like to merge it Some of
its dependencies are from hackage and are much newer than those in the stackage
snapshot we use. So my question is where should the dependencies belong?
Thanks!
John
Ricardo Wurmus writes:
> It’s one thing to install all files that the plain text database says
> should be installed. They all exist in the SVN repo. It’s quite
> another to generate them all from their respective sources.
Nix separates them all, it provides the 2000+ packages.
--
Pierre Nei
Pierre Neidhardt writes:
> Ricardo Wurmus writes:
>
>> I’m afraid the texlive importer will have much less of an impact than
>> we’d all wish.
>
> Hmm... it seems to work for Nix though. Am I mistaken?
It’s one thing to install all files that the plain text database says
should be installed.
I just thought of a better way.
Represent the Linux kernel (including out-of-tree-modules) as a profile,
most probably just the system profile (which already exists--extend it).
A user package (for example if referred to by a system service) would
propagate-input the kernel module package it requ
Hi,
On Tue, 09 Jul 2019 00:50:10 +0200
Jelle Licht wrote:
> I have verified this way of loading modules to work, but was wondering
> whether we should rather provide a `out-of-tree-kernel-module' service
> of sorts to do this.
>
> To resolve out-of-tree kernel module dependencies, I guess we wo
Pierre Neidhardt writes:
> Ricardo Wurmus writes:
>
>> Jelle Licht writes:
>>
>>> I've noticed some time ago that the biber version that we currently have
>>> is incompatible with the texlive revision we have packaged.
>> […]
>>> Thoughts?
>>
>> We should update texlive. The latest tagged re
ping :-)
Jelle Licht writes:
> Hello Guix,
>
> Not too long ago, the linux-module-build-system was introduced. I ran
> into some code in the wild written by Alex Griffin that defines a
> shepherd service that does the following for a given kernel-module
> package:
>
> - set the LINUX_MODULE_DI
Jelle Licht writes:
> I've noticed some time ago that the biber version that we currently have
> is incompatible with the texlive revision we have packaged.
[…]
> Thoughts?
We should update texlive. The latest tagged release according to
https://tug.org/svn/texlive/tags/ is “texlive-2019.3”.
Hi, everybody!
After taking a deeper look into our (guix's) grub installation
procedure, I have the thought that it could be a neat idea to make the
boot directory an actual derivation instead something of the global
status.
From what I currently understand:
- boot.img/core.img and load.cfg: T
Guix,
I've noticed some time ago that the biber version that we currently have
is incompatible with the texlive revision we have packaged.
Incidentally, since the latest core-updates merge, biber does not pass
its test suite anymore due to the hardcoded
`perl-unicode-collate'-related hashes. I th
On Sat, Oct 19, 2019 at 11:29:33PM -0400, Kei Kebreau wrote:
> I've pushed my changes to the following repository for anyone who wants
> to take a look:
>
> https://notabug.org/kei/guix-gnome-updates
I tried reproducing your failure but webkitgtk failed to build.
make[2]: Leaving directory '/tmp
Hi Ludo,
>>> At the API level, there’s ‘inferior-for-channels’ which does that +
>>> registers a GC root + maintains a cache so that the second time you use
>>> a given instance of Guix it’s immediately available.
>>
>> Just what I need...
>
> Awesome, let us know how it goes!
Not so well...
If
Hi Ricardo,
For a test of an external system, like something I develop at work, I
don't want/need to have Guix with all modules compiled present.
I don't want unnecessary steps if they are not necessary.
Please refer to my first mail with an example of running a test standalone.
I'd like some
Hi Ludo’,
El Mon, 29 Apr 2019 09:56:25 +0200
Ludovic Courtès escribió:
> Hi Miguel,
>
> Thanks a lot for this work.
I've been quite silent about this because I wanted to solve the issue
with .mo files in a better way, but my current understanding is that
the best way to go with that is to make
Hello,
Tanguy Le Carrour ezt írta (időpont: 2019. okt. 21.,
Hét 11:24):
> Hi Marius,
>
>
> Le 10/18, Marius Bakke a écrit :
> > Tanguy Le Carrour writes:
> > > In Guix, we have Pytest 4.4.2, but the latest release is 5.2.1.
> > > In that case, would it make sense to define a new "versionned" pu
Hello Christopher,
> +(define* (main #:optional (args (command-line)))
> +
> + ;; Always have stdout/stderr line-buffered.
> + (setvbuf (current-output-port) 'line)
> + (setvbuf (current-error-port) 'line)
I must admit I've not been following very closely your work on Guix Data
Service. Howe
Hi Marius,
Le 10/18, Marius Bakke a écrit :
> Tanguy Le Carrour writes:
> > In Guix, we have Pytest 4.4.2, but the latest release is 5.2.1.
> > In that case, would it make sense to define a new "versionned" public
> > variable for python-pytest? Would I create python-pytest5? Or would I
> > rena
Hey Tobias,
> It doesn't look like you've added anything to this file in the past,
> either. All right to remove this line again?
Yes I'll remove it!
Thanks,
Mathieu
Le 10/18, Diego Nicola Barbato a écrit :
> Tanguy Le Carrour writes:
> >(service slim-service-type
> > (slim-configuration
> > (xorg-configuration
> >(xorg-configuration
> > (keyboard-layout keyboard-layout))
> >
> >
> > I
26 matches
Mail list logo
