> I'm currently working with a few others to get GNOME 3.30.x in some
> working order on core-updates. I'll keep this issue in mind while
> testing. Thanks for bringing this issue to our attention!
That would be great. Thank you very much. Btw, I made a SUMMARY which
one can find as a recent
Raghav Gururajan writes:
> Hello Guix!
>
> I wanted let folks know that, whoever is/will-be working on gnome
> 3.30.x, could try to integrate with the report #35586 (https://issues.g
> uix.gnu.org/issue/35586)? Just a suggestion. ☺
>
> Thank you!
>
> Regards,
> RG.
Hi Raghav!
I'm currently
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_DIRECTORY environment variable to
/lib/modules
Jakob L. Kreuze writes:
> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
>> Well, we can pick and choose which exceptions we continue on. For
>> services not being started, we can probably carry on with the
>> deployment. I think, ideally, in the situations where 'guix deploy'
>>
Hi Ludo,
> I’ve committed an improved version of doc/build.scm as
> ccadafdcefee012c261513e9d8663a22704bc496.
>
> It expects to be used from a Git checkout like so:
>
> guix build -f doc/build.scm
>
> Hopefully it addresses the issues you had before, Ricardo.
It does! It’s really great. I
zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:
> Well, we can pick and choose which exceptions we continue on. For
> services not being started, we can probably carry on with the
> deployment. I think, ideally, in the situations where 'guix deploy'
> should stop, we should try to
Hi Ricardo,
Ricardo Wurmus writes:
> The remote’s Guix is pretty old, so it’s likely that Ludo is right.
> So, I actually reconfigured these machines semi-successfully, eh?
> Neat!
Yeah! Neat for me, too. I find it mind-blowing that this tool I made is
already seeing some use
>
Guix,
guix-comm...@gnu.org wrote:
nckx pushed a commit to branch master
in repository guix.
commit 0971f8bd884b6e92b77d9e12030cd58279699183
Author: Tobias Geerinckx-Rice
Date: Mon Jul 8 16:09:46 2019 +0200
gnu: Remove r-biocinstaller.
It requires R < 3.6 and is no longer
Hello Guix!
I wanted let folks know that, whoever is/will-be working on gnome
3.30.x, could try to integrate with the report #35586 (https://issues.g
uix.gnu.org/issue/35586)? Just a suggestion. ☺
Thank you!
Regards,
RG.
Hi Jakob,
> Ricardo Wurmus writes:
>
>> I tried again and it started building things but then aborted like
>this: […]
>> guix/remote.scm:66:17: In procedure %remote-eval:
>> Throw to key `srfi-34' with args `(#> [service: user-homes action: start key: match-error
>> args: ("match" "no
Dear all,
https://nlnet.nl/PET/ has small grants to work on Free and Open Source
software (up to EUR 50,000).
The overall mission of the Next Generation Internet initiative is to
re-imagine and re-engineer the internet for the third millennium and
beyond to shape a value-centric, human and
Ricardo Wurmus writes:
> I tried again and it started building things but then aborted like this:
>
> …
> offloading '/gnu/store/x1q848ra6lm3y0ma9n2i73k8ic1gfyz9-references.drv' to
> '141.80.167.145'...
> @ build-remote /gnu/store/x1q848ra6lm3y0ma9n2i73k8ic1gfyz9-references.drv
>
Hi Robert,
Robert Vollmert writes:
> Hi all,
>
> I realize this isn’t generally an aim for guix proper, but I’d like
> to be able to build a package from a local git repository (or
> optionally from a local tar ball). In my specific case, it’s while
> working out the packaging of a project I
Mark H Weaver writes:
> The problem is that (guix self) has its own logic, independent of the
> *.am files, to determine the set of modules to be compiled and
> installed. That logic needs to be updated when adding a new module
> directory.
>
> I just pushed commit
Robert Vollmert writes:
> Hi all,
>
> I realize this isn’t generally an aim for guix proper, but I’d like
> to be able to build a package from a local git repository (or
> optionally from a local tar ball). In my specific case, it’s while
> working out the packaging of a project I intend to
On 7/8/19 11:23 AM, Jonathan Brielmaier wrote:
> As I (also) per ordered a Librem 5, I dream as well from running Guix
> system on it. Maybe I'll open a tracker bug to track all the things we
> need to run Guix on Librem 5 :)
I just went ahead, feel free to add stuff there:
Hi all,
I realize this isn’t generally an aim for guix proper, but I’d like
to be able to build a package from a local git repository (or
optionally from a local tar ball). In my specific case, it’s while
working out the packaging of a project I intend to publish but
haven’t published yet.
What
Efraim Flashner wrote:
'guix size git' => 411 MiB
'guix size git pcre' => 413 MiB
'guix size grep' => 71.4 MiB
'guix size grep pcre' => 71.4 MiB
I take this as a clear ‘no -minimal needed’? PCRE is already
core-updates material, so no reason there.
Looks like a good idea to me.
Hi,
I’m currently writing some slightly repetitive mcron jobs
in my config.scm that use gexps / program-file. I’m wondering
whether there’s a better way to share code between these than
writing a separate scheme file and importing that via
with-imported-modules?
That approach works, but it’s a
On 7/7/19 11:40 PM, Jonathan Frederickson wrote:>> So there are two
options from here:
>> - bring meson to install libglade-handy.so to the libhandy package
>> - don't intall libglade-handy.so at all
>
> Is the former the usual method for providing libraries like this? If
> I'm interpreting this
On 5. Jul 2019, at 23:41, Ludovic Courtès wrote:
> Robert Vollmert skribis:
>
>>> On 1. Jul 2019, at 12:28, Ludovic Courtès wrote:
>>>
>>> Hello,
>>>
>>> Robert Vollmert skribis:
>>>
I’d like to improve the debug output here more generally: At (high enough)
debug level, it seems
Hi,
On 6. Jul 2019, at 03:08, Timothy Sample wrote:
> Ludovic Courtès writes:
>> Robert Vollmert skribis:
>>> * I’m a bit unclear on where to file the various new
>>> ghc-* packages. Currently it’s more or less aribtrarily spread
>>> across a bunch of modules, compare the github link above.
On Sun, Jul 07, 2019 at 02:20:52PM +0200, Pierre Neidhardt wrote:
> Hi!
>
> Quite a few packages depend on grep to have PCRE support (e.g. freebayes).
>
> Similarly, some packages (magit-todos) depend on git to be built with
> PCRE support.
> Compiling Git with USE_LIBPCRE2 would fix this.
>
>
23 matches
Mail list logo
