pefully we can get a
discussion going there!
Cheers,
Nicolas
On 2025-04-24 23:33, Sergio Pastor Pérez wrote:
> Nicolas Graves writes:
>> Made some progress and I'll rework on the patches tonight.
>
> I'm looking forward to it!
>
>> Current workflow is the fol
Ping ;)
Next steps here?
I can resubmit a clean 68315 with this change too if this helps.
In the previous mail response, I made the point that 68315 is probably a
requirement for the following patch to be actually useful.
Cheers,
Nicolas
On 2025-04-26 01:12, Nicolas Graves wrote
eases" but stopped
publishing them, even though some later tags exist. IMHO, the better
developpement experience would be to use the latest tag when it's
greater than the latest "release".
--
Best regards,
Nicolas Graves
commit between 7ff20b9e94 and dd2172a054, it might be easier to
see where such an error might have occured (that is, if the error you
observe is indeed gexp-related).
--
Best regards,
Nicolas Graves
next python-team iteration.
backtrace
Description: Binary data
--
Best regards,
Nicolas Graves
rom 9895ecb13110bcfaec189d3e029566d060d69889 Mon Sep 17 00:00:00 2001
Message-ID: <9895ecb13110bcfaec189d3e029566d060d69889.1745622542.git.ngra...@ngraves.fr>
From: Nicolas Graves
Date: Tue, 18 Mar 2025 06:13:05 +0100
Subject: [PATCH] build-system: Add modules field.
---
gnu/packages/boot
On 2025-04-25 10:57, Ludovic Courtès wrote:
> Hello,
>
> Nicolas Graves writes:
>
>> Actually the thunk was not necessary because args were already passed to
>> the build-bag procedure, and modules and imported-modules were already
>> used in every bag-build proc
On 2025-04-25 00:23, Nicolas Graves wrote:
> Also, I'll try to split the
> https://lists.sr.ht/~ngraves/devel/%3c20250319173238.7969-1-ngra...@ngraves.fr%3E
> patch series :
>
> 1) some patches are improvements independent of wherever I try to do with
> partial build
On 2025-04-24 20:02, Nicolas Graves wrote:
> On 2025-04-24 19:16, ngra...@ngraves.fr wrote:
>
>> On 2025-04-15 19:01, Ludovic Courtès wrote:
>>
>>> Instead of procedure properties (which are a hack, really), you could
>>> add one or two fields to and b
s almost as
far-fetched as using procedure properties IMHO.
--
Best regards,
Nicolas Graves
tion.patch"
>> failed with status 1
>> guix build: error: exception thrown: #<&invoke-error program:
>> "/gnu/store/xv4cd7qz4yan93zkjisbmbpxfz78hah2-guile-3.0.9/bin/guile"
>> arguments: ("--no-auto-compile" "-L"
>> "/gnu/store/q7lrzwpnhjp4s1jrgg78vikqk8gx5mgq-module-import" "-C"
>> "/gnu/store/qafn8iflzfq18j8wn9pz0z4ycrsply0v-module-import-compiled"
>> "/gnu/store/rrxc0kv0k1mblr660smligw4scrab7yl-emacs-pgtk-29.4-builder")
>> exit-status: 1 term-signal: #f stop-signal: #f>
>> --8<---cut here---end--->8---
>>
>> I've seen that the latest patch series revision is from last month. Is
>> the provided 'guix.scm' example outdated?
>>
>> Is there any way we can help you to bring this feature to Guix proper?
>>
>>
>> Best regards,
>> Sergio.
>>
>
--
Best regards,
Nicolas Graves
Maybe the recent work of Noé makes it simpler to implement as an
extension?
https://codeberg.org/cons-town/guile-debugger/src/branch/main/shepherd-nrepl/
On 2025-04-21 19:03, Ludovic Courtès wrote:
> Hi Nicolas,
>
> Nicolas Graves writes:
>
>> I recently tried to us
4 (map1 ((escaped "\\") (escaped "r") "?" (escaped "…") …))
586:17 3 (map1 ((escaped "r") "?" (escaped "\\") (escaped "n") …))
In guix/build/toml.scm:
399:19 2 (failure)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" (escaped
"r"))'.
build process 18 exited with status 256
--
Best regards,
Nicolas Graves
index 00..79c620921c
--- /dev/null
+++ b/guix/import/conan.scm
@@ -0,0 +1,186 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2025 Nicolas Graves
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modi
GNU
+;;; Copyright © 2025 Nicolas Graves
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License
/~ngraves/devel/%3c20250319173238.7969-1-ngra...@ngraves.fr%3E
--
Best regards,
Nicolas Graves
Avec pas mal de retard mais beaucoup plus de maturité sur le sujet, j'ai
mis à jour la présentation que j'ai faite sur les extensions Guix :
https://github.com/nicolas-graves/guix-extensions/blob/main/presentation.org
J'ai ajouté notamment pas mal d'exemples et une clarifica
m." is clear enough.
A recent example that happened to me (not a binary though but a
guix-related bug):
https://github.com/anticomputer/age.el/issues/15 was fixed with
https://github.com/anticomputer/age.el/pull/16/commits/a1c9d0a7911e603e6574daf1ee6d602d1e932842
Not writing "Guix" anywhere, but it makes it clear that something is
missing on the system.
--
Best regards,
Nicolas Graves
he absence of its input in a
Guix-understandable way? Does adding the input fix the issue?
- Both yes : (c)
- At least a No: Submit a patch to the upstream package to ensure both
yes.
--
Best regards,
Nicolas Graves
On 2025-03-21 11:20, Sergio Pastor Pérez wrote:
>
> The version 2 has less patches. Do I need to apply only v2?
Yes, I merged some patches because my mail are capped to 200/hour and I
reached that in v1.
--
Best regards,
Nicolas Graves
" or some branch focused on that.
>
> 2. This is built and merged every month (?) or once a certain number of
> ungrafts/package rebuilds are needed (insert favorite arbitrary number),
> whichever comes first.
>
> Maybe this needs a proper GCD? I think we could just try something as
> this is more basic build management than a change to the project,
> because right now we keep falling behind and easily spend more time
> grafting than building on user systems.
I also agree on the ungrafting part, I like the idea!
--
Best regards,
Nicolas Graves
us mailing list or RSS
> flow with security fixes that a Guix security team is monitoring and
> applying.
--
Best regards,
Nicolas Graves
, so that we can quickly handle them.
--
Best regards,
Nicolas Graves
task ~a!~%" other)))
(define (run-next-task!)
"Run the next queued task."
(and (not (null? queue))
(let* ((rev (reverse queue))
(id (car rev))
(command (cadr rev)))
(set! queue (reverse (cdr rev)))
(perform-service-action transient-service 'spawn command
--
Best regards,
Nicolas Graves
ion (I don't think Nix would be able to have these kind of
helpers around, whereas it seems doable in Guix).
(This is not against moving to codeberg, but more about being mindful of
what we might loose on this aspect).
--
Best regards,
Nicolas Graves
tem itself ;)
--
Best regards,
Nicolas Graves
u wish to build everything in a file
and then update that file, you could as well... do it in a cargo
workspace! i.e. Inject all inputs, let cargo do its thing, and have a
single output. Only care in guix about the final package
description/version and everything. No strings attached, no need to
support hundreds of lines we don't care about! (I still vomit writing
package descriptions for -impl crates).
--
Best regards,
Nicolas Graves
You might want to take a look at 76436 v2 :)
--
Best regards,
Nicolas Graves
ith (json) in node build system:
> https://issues.guix.gnu.org/74900
> - Bumping node-lts in guix from 22.12.0 to 22.14.0
> (no patch yet, still building locally)
--
Best regards,
Nicolas Graves
strap.scm module.
--
Best regards,
Nicolas Graves
On 2025-02-13 14:53, Jelle Licht wrote:
> Hi Nicolas,
>
> Nicolas Graves writes:
>
>> Hi guix,
>>
>> I was wondering if a node-team would be useful to make the work towards
>> making a few applications available in Guix.
>
> Agreed! I've slightl
esitate to take a look if you have some time for that :)
--
Best regards,
Nicolas Graves
slation-server sans aws-sdk. I think this
is doable but I need some foresight on how this can happen (i.e. Would I
tackle that alone and should I eventually setup GPG or (my preference)
can I do that in close collaboration with a new node-team member ?)
--
Best regards,
Nicolas Graves
On 2025-02-03 16:43, Simon Tournier wrote:
> Hi,
>
> On Fri, 17 Jan 2025 at 22:44, Nicolas Graves wrote:
>
>> I recently started a guix extension to help manage complexities of
>> maintaining guix soft-forks.
>
> [...]
>
>
>> https://git.sr.ht/~ngraves/g
Since they are packaged but shouldn't be recommended, my solution would
be to move them from guix to the guix-past channel. Is that the right
thing to do ?
--
Best regards,
Nicolas Graves
sed it yet, and I'm fine
authenticating locally for now. I mainly focus on reproducibility of
patches sent (recording where patches are sent to be able to generate a
list of patches from a repo) and pulling from patched channels.
There still some work ahead before I can even advertise it properly, but
feel free to take a look! There's no doc yet.
https://git.sr.ht/~ngraves/guix-stack
--
Best regards,
Nicolas Graves
On 2025-01-06 21:18, Suhail Singh wrote:
> Nicolas Graves writes:
>
>> This is because the current channel-builds-system is only able to
>> build a guix channel, rather than any channel.
>
> Perhaps this is obvious to others, but for the benefit of others (such
> a
either from channel metadata dependencies or from inputs.
WDYT? Do you already know of a way to do this?
--
Best regards,
Nicolas Graves
n be found at
https://git.sr.ht/~ngraves/dotfiles/tree/main/item/channels.scm
--
Best regards,
Nicolas Graves
this branch at CI, so it was indeed probably
> just a transient error for the person building locally.
>
> Andreas
>
>
--
Best regards,
Nicolas Graves
> https://issues.guix.gnu.org/search?query=tag%3Aeasy+AND+%28is%3Aclosed+OR+is%3Adone%29
>
> (It would be great to have little explanation and/or an example under the
> Hint and/or Help https://issues.guix.gnu.org/help#search)
>
> Cheers Bost
--
Best regards,
Nicolas Graves
of QA? I guess this is
something we would want to fix.
--
Best regards,
Nicolas Graves
ci like bordeaux both seem down, maybe it has something to do with this
commit ? Hopefully not.
--
Best regards,
Nicolas Graves
On 2024-10-28 12:02, Andreas Enge wrote:
> Am Mon, Oct 28, 2024 at 10:59:29AM +0100 schrieb Nicolas Graves:
>> Sorry I should have thought about it with the patch, let me know if
>> you'd wish I write this patch + news item.
>
> Well, I wondered whether or not to apply t
e thought about it with the patch, let me know if
you'd wish I write this patch + news item.
> Andreas
>
--
Best regards,
Nicolas Graves
On 2024-10-26 17:08, Ludovic Courtès wrote:
> Hi,
>
> Nicolas Graves skribis:
>
>> I was wondering about handling a cpe-vendor property to handle such
>> cases, since cpe-name won't help here.
>
> Yes, we need that. (guix cve) currently blissfully ignores t
help and we'll still have to fill
hidden-lint-cve (since most of these packages have no CVEs and therefore
are not in the database at all, despite having similarly-named
packages).
--
Best regards,
Nicolas Graves
th space gains and maintainability : replace a few big library
dependencies but leave a few small ones not present elsewhere in Guix in
the source (ungoogled-chromium does that for instance).
--
Best regards,
Nicolas Graves
On 2024-09-26 15:43, Ludovic Courtès wrote:
> Hi,
>
> Nicolas Graves skribis:
>
>> Has there already been some discussion about custom hash updaters? I
>> have written an import module for libreoffice, and we have access to the
>> sha256 h
to update without having to download 267MiB
of data twice.
However, %method-updates doesn't seem to allow such a flexibility for
now. Maybe a custom field for a function in could be
possible? WDYT?
--
Best regards,
Nicolas Graves
%load-path)))
(search-patches
;;patches created from github issues
"lxappearence-gtk3-01-only-do-x11-on-x11.patch"
"lxappearence-gtk3-02-set-some-settings-gsettings.patch")))
This is allows you to put patches quite conveniently in a channel.
--
Best regards,
Nicolas Graves
51 matches
Mail list logo