Re: Value in adding Shepherd requirements to file-systems entries?
Hi Richard, On Tue, Apr 23 2024, Richard Sent wrote: > I submitted a patch [..] at https://issues.guix.gnu.org/70542. If this > winds up merged I believe your code could be rewritten [as] > > --8<---cut here---start->8--- > (file-system >(device "wallace-server.local:/acct") >(mount-point "/acct") >(type "nfs") >(requirement '(avahi-daemon)) ;resolve .local >;; (flags '(no-atime no-dev no-exec read-only)) >;; (options "proto=tcp6,timeo=300,nolock") >(check? #f) >(mount-may-fail? #t) >(create-mount-point? #t)) > --8<---cut here---end--->8--- Wow, that works! Since this short form is optional and I can always switch back to the previous version, v2 of that patch should be merged without further delay. Thank you for your most valuable contribution! Kind regards, Felix P.S. The code above should read (requirements ...) in the plural.
API for rewriting package fields ?
Is there an interface to rewrite / update a field from a series of packages easily? What I get from the change in python-team last change for the pyproject-build-system is that we need to add python-setuptools or python-wheel to all packages that will complain about it, when trying to build. The errors are very easy to diagnose (a string match in stderr: ModuleNotFoundError: No module named 'setuptools' or error: invalid command 'bdist_wheel' is enough to know what's wrong). The logical thing to do here IMO would be to have a script running, reading stderr when it fails and programmatically replacing where it's needed, since it's done for 2-3k packages basically. I know some work has been done with the guix refresh command to rewrite based on package field location, but I'm not sure it provides a convenient-enough API to simply say in guile "add this package to native-inputs of this package in place". Would love some counselling here, thanks! -- Best regards, Nicolas Graves
Re: Python's native-inputs
Hi Guix, Just to let you know, I just added a working patch series that does this job on (guix build, guix import pypi, guix lint). This is not the full patch series, which I have rebased on python-team, but it should be good enough 1) to test it 2) to review it for a v2 that would be more guixy It's in 70570. Cheers, Nicolas On 2024-04-22 16:40, Ricardo Wurmus wrote: >> TL;DR : >> - patch series in big progress, not done yet because I don't really >> know where to stop and massive rebuilds. > > Please take a look at the python-team branch, which contains changes to > the build system. -- Best regards, Nicolas Graves
Re: Python's native-inputs
On 2024-04-22 16:40, Ricardo Wurmus wrote: >> TL;DR : >> - patch series in big progress, not done yet because I don't really >> know where to stop and massive rebuilds. > > Please take a look at the python-team branch, which contains changes to > the build system. I'll rebase on it, thanks. -- Best regards, Nicolas Graves
Re: Value in adding Shepherd requirements to file-systems entries?
Hi Richard, On Mon, Apr 22 2024, Richard Sent wrote: > NFS is allegedly supported Someone once gave me this service [1] to mount a file-system declared with (mount? #f). [2] It's been working ever since. Kind regards Felix [1] https://codeberg.org/lechner/system-config/src/commit/0131082ff0eb3f1262544f7799d291324ba08282/host/lechner-desktop/operating-system.scm#L209-L222 [2] https://codeberg.org/lechner/system-config/src/commit/0131082ff0eb3f1262544f7799d291324ba08282/host/lechner-desktop/operating-system.scm#L130-L139
Re: Python's native-inputs
Answer in two different emails.
On 2024-04-18 22:07, Maxim Cournoyer wrote:
> Hi Nicolas,
>
> Nicolas Graves via "Development of GNU Guix and the GNU System
> distribution." writes:
>
>> Hi Guix,
>>
>> On some languages, there are a lot of unused native-inputs that are
>> development & linting dependencies much more than packages that are
>> actually used to build or test a package (I'm thinking at least Python
>> and Rust). These fall in the category of tools "useful" at run time, but
>> unecessary at build time.
>
> Indeed.
One more argument: it's important for user experience using python to
have these packages up-to-date, because users will want to have an
up-to-date lsp client and utilities.
>
>> Is there a clear policy about their removal? I've seen the case of
>> pre-commit in Python, and I've commited a series yesterday regarding
>> pylint, but there are a whole lot of them in Python, at least :
>
> [...]
>
>> These packages make a lot of sense when considering things like
>> `guix shell -D` but they are hampering some progress on Python packages
>> since they are everywhere and a small update in their inputs rebuilds
>> the whole python world (even though it has NO influence on the
>> functionality of any other package).
>>
>> What are the guidelines in this case?
>
> There aren't really any guidelines. It's easy to avoid the linters, it
> makes sense to avoid them, but sometimes upstream makes it difficult to
> avoid running a linter as part of there test suite, in which case I
> think it's acceptable to keep them as native-inputs rather than come up
> with more patches to maintain.
>
>> I can propose a huge patch series (currently ~300 patches, and not
>> finished), to remove them, lint against them and remove them from the
>> importer as a default, but that's a big decision to make. IMO we should
>> have a dev-inputs field to handle these cases, but that's even more work.
>
> The situation is similar as for other test inputs such as pytest; it has
> an enormous amounts of dependents and thus cannot be easily upgraded on
> the master branch. At least more up-to-date variants can be added since
> these are not in the transitive closure of any packages.
That's true for some very essential packages (setuptools, pytest...)
which would make the case to only update these packages once we want to
update the whole python chain, i.e. when we update python. But IMO it
shouldn't be the case for a package like black, isort or flake8.
>
> I don't think we should go out of our way to address annoyances that
> upstream have caused -- that'd be too much work to maintain in the long
> run.
I think it depends on the case. For a package like python-dateutil,
having pytest-cov as a native-input is bad, because it causes a rebuild
of the whole chain (guix refresh -l python-pytest-cov went from ~2500
to ~15 packages with the whole series, but in particular that was a big
part of dependency removal). Now for small leaf packages, having
pytest-cov as a native-input is not a big issue indeed, I agree in
those cases we would better ignore it than fix it in the meantime.
While making the patches, I realized it's not often that we need a
convoluted patch. Most of the time, adding "-c" "/dev/null" to
test-flags will do the trick to remove python-pytest-cov and it's even
less annoyance for black, flake8 or mypy, if not other cases are often
handled with a simple removal of the native-input in pyproject.toml, or
setup.py. What's annoying is when packages are flagged as required when
they're not.
It could possibly even be handled in the build-system in the case of
pytest, to avoid these "-c" "/dev/null". This is untested, but I think
it'll work.
;; Add a pytest plugin for the pyproject-build-system to filter out some
;; arguments we want to be able to ignore.
;; (define (pytest-ignore-options group-options-alist)
;; "This function converts an alist of (group . options) in a string that can
;; be instantiated as a python pytest plugin."
;; (string-join
;;(cons*
;; "import pytest"
;; (map
;; (match-lambda
;;((group . options)
;; (string-append
;; (format #f "def pytest_addoption(parser):
;; group = parser.getgroup(~s,'Guix ignored options')
;; options = [~{~s, ~}]
;; for option in options:
;; group.addoption(option, action='count')"
;; group
;; options
;; group-options-alist))
;;"\n\n"))
;; (let ((cov-alist
;;'(("cov" . ("--cov" "--cov-reset" "--cov-report" "--cov-config"
;;"--no-cov-on-fai
Re: Shepherd timers
Hi Ludo' On Fri, Apr 19 2024, Ludovic Courtès wrote: > that’s already possible with the #:user argument of ‘command’. While 'command' works and was in your initial example, I had trouble tracking down the documentation for it. Is it a record entry destined for 'shepherd-command'? Spoiled by Guix's seamless Guile integration, I don't shell out much anymore. Will 'command' accept a thunk? Kind regards Felix
Re: No public interface for shepherd-package
On Fri, Apr 19 2024, Ludovic Courtès wrote: > Is ‘shepherd’ among your channels? Sorry, it works fine. My message was borne from a terrible desperation after one of my most important machines refused to reconfigure for a week. As so often with technical systems, it was an operator error. [1] Kind regards Felix [1] https://mail.gnu.org/archive/html/guix-devel/2024-04/msg00210.html
Re: System can no longer be reconfigured
Hi Ludo' On Fri, Apr 19 2024, Ludovic Courtès wrote: > Is it not hanging during Shepherd service upgrade? Yes, thank you! It was hanging during the Shepherd system upgrade due to an invalid calendar-event specification. In a service that uses both #:days-of-month as well as #:days-of-week, I got confused because the count starts with one in one, and with zero in the other. [1] Thank you for your kind pointer in another forum! The issue is now solved. On this occasion, please allow me to mention for everyone's benefit that your support level for the Shepherd is very generous---especially when the complaints involve repeated user errors by the people bothering you. > If that is the case, (1) that is not preventing upgrade from happening > since that’s the very last step (it just means you’ll have to reboot), Yes, but 'reboot' and 'halt' also stop working, which meant that I issued 'sync' a few times and then, crossing my fingers, pressed the reset button a few hundreds of a second later. I wish there were a way to force a reboot. > (2) it’s a shepherd-related bug for which perhaps there are clues in > /var/log/messages? Thank you for that pointer, too. I'm still learning about where to look for error messages, whose destination is not always obvious to me. Kind regards Felix [1] https://codeberg.org/lechner/system-config/commit/8639339dbd3ad4c51ceba239bf4aadc56223fb4a
Re: A capture-stdout wrapper procedure in (guix build utils)?
Hi Fabio, On Sat, Apr 20 2024, Fabio Natali wrote: > do you think it might be worth to add it (or a variation thereof) to > '(guix build utils)'? I use this [1] which gives the caller access to the exit status and is also slightly shorter: (define (command-with-output-to-string/status* command) (let* ((input-pipe (apply open-pipe* OPEN_READ command)) (output (get-string-all input-pipe)) (exit-val (status:exit-val (close-pipe input-pipe (values output exit-val))) It may be better, however, to finally fix Guile's 'system' and 'system*' to work with 'with-output-to-string'. [2] Kind regards Felix [1] https://codeberg.org/lechner/preambled-exec/src/commit/c5c498c3890f22cda070fe35b314f01982ebc885/test/simple-variable.scm#L28-L32 [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43364
Re: Fallout from recent nss-certs changes
Hi, On Sat, Apr 20 2024, Ian Eure wrote: > If an operating-system’s packages includes `(specification->package > "nss-certs")', this causes breakage, because that form selects version > 3.98, but %base-packages includes 3.88.1, which causes an error on the > next `guix system reconfigure' due to conflicting package versions in > the profile. Why does the unversioned stringy selector (specification->package "nss-certs") resolve to a version different from the unversioned variable nss-certs? Is that a bug? Kind regards Felix P.S. I hoped to use the word "reified" but did not know how it fit in.
Re: Distributed GNU Shepherd NLNet Grant
Hi Juli, On Thu, Apr 18 2024, Juliana Sims wrote: > I submitted an application for an NLNet grant to fund porting our > beloved Shepherd to Spritely Goblins Wow, I'm not sure what that will do just yet, but I can't wait to hear more! > I am happy to announce that this grant application was approved! Congratulations! Kind regards Felix P.S. Please have a look at ZeroMQ for your sockets, if you haven't.
System can no longer be reconfigured
Hi, I can no longer reconfigure a system with any of these methods: 1. "guix deploy" which I use almost exclusively 2. "guix system reconfigure" after a recent pull 3. "./pre-inst-env guix system reconfigure" with a recent Git checkout. Guix hangs during the system activation step. Any ideas? Kind regards Felix
File name component is not a directory "/var/run/dbus"
Hi,
Guix compiled from Git (and with very minor modification) cannot
activate a system because /var/run/dbus is not a directory. The error
message is below.
On mine, the folder is a symbolic link to /run/dbus. Any ideas?
Did something change recently there?
Kind regards
Felix
* * *
switched from generation 463 to 463
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
making '/var/guix/profiles/system-463-link' the current system...
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/rnng9ihdvrf9q0b1617n4yv0nf69h40b-etc...
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
Backtrace:
In ice-9/eval.scm:
619:8 19 (_ #(#(#)))
In guix/ui.scm:
2326:7 18 (run-guix . _)
2289:10 17 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
859:3 15 (_)
839:4 14 (call-with-status-report _ _)
In ice-9/boot-9.scm:
1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
661:37 12 (thunk)
In ice-9/boot-9.scm:
1747:15 11 (with-exception-handler # …)
In unknown file:
10 (primitive-load "/var/guix/profiles/system-463-link/act…")
In ice-9/boot-9.scm:
260:13 9 (for-each # _)
In unknown file:
8 (primitive-load "/gnu/store/1x975c8prbmb09gaymr583bgy7b…")
In ice-9/eval.scm:
619:8 7 (_ #f)
In gnu/build/activation.scm:
103:2 6 (mkdir-p/perms "/var/run/dbus" #("messagebus" "x" 988 …) …)
In ice-9/boot-9.scm:
1747:15 5 (with-exception-handler # …)
1747:15 4 (with-exception-handler # …)
1747:15 3 (with-exception-handler # …)
In gnu/build/activation.scm:
78:6 2 (_)
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:
file name component is not a directory "/var/run/dbus"
No public interface for shepherd-package (Was: Shepherd service logging)
Hi Attila, On Tue, Dec 05 2023, Attila Lendvai wrote: > AFAIU that will lead to quite some local recompiling that are not necessary. > you can just set the shepherd package of the shepherd-root-service-type to a > custom package. > > e.g. this will use the latest shepherd from the shepherd channel: > > (operating-system > ... > (essential-services >(modify-services (operating-system-default-essential-services > this-operating-system) > (shepherd-root-service-type > config => > (shepherd-configuration >(inherit config) >(shepherd (@ (shepherd-package) shepherd))) I have been using that code to get access to the timers in the Shepherd's development branch. Unfortunately, one of my servers can no longer be reconfigured via 'deploy' or 'system reconfigure'. Following podiki's and jab's kind advice on IRC yesterday, I recompiled Guix locally. I also provided all channels locally via -L. That 'system reconfigure' failed too, however. The error message was: Module named (shepherd-package) has no public interface. Is your way of using the latest Shepherd version still recommended, or should I be doing that differently now? Thanks! Kind regards Felix
Re: Status of ‘core-updates’
Hi Maxim, On Wed, Apr 17 2024, Maxim Cournoyer wrote: > The solution is to hunt the libtool .la files Would my old web-based file finder, which I could resurrect, help with locating such files? Kind regards Felix
Python's native-inputs
Hi Guix, On some languages, there are a lot of unused native-inputs that are development & linting dependencies much more than packages that are actually used to build or test a package (I'm thinking at least Python and Rust). These fall in the category of tools "useful" at run time, but unecessary at build time. Is there a clear policy about their removal? I've seen the case of pre-commit in Python, and I've commited a series yesterday regarding pylint, but there are a whole lot of them in Python, at least : - black and extensions - codecov - coveralls - coverage - pytest-cov - pycodestyle - mypy and extensions - isort and extensions - flake8 and extensions - possibly virtualenv and extensions and I'm probably forgetting some. These packages make a lot of sense when considering things like `guix shell -D` but they are hampering some progress on Python packages since they are everywhere and a small update in their inputs rebuilds the whole python world (even though it has NO influence on the functionality of any other package). What are the guidelines in this case? I can propose a huge patch series (currently ~300 patches, and not finished), to remove them, lint against them and remove them from the importer as a default, but that's a big decision to make. IMO we should have a dev-inputs field to handle these cases, but that's even more work. -- Best regards, Nicolas Graves
Re: Functional package interface
On 2024-04-16 01:17, spacecadet wrote:
> Hi Nicolas
>
>> Isn't what you're trying to do already in Guix? Have a look at
>> package-inputs-rewrite right there :
>> https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html
>
> I want to have this but more powerful, I'd like to do something like
> define an operating system with all instances of a package replaced.
> Maybe something like that is already possible, but I haven't figured
> out a way.
>
> As far as I know, with package-input-rewriting you would still have to
> manually add it to all the services in your operating-system
> definition. Or just use module-set! and manage the environment state
> some other way.
>
> You also only have access to the input fields of packages, this is
> something parameterize packages tackles too, being able to add inputs
> that go anywhere in the package definition. Build phases for example,
> to enable common compile options across multiple packages more easily.
>
>> I've also been working on general package propagation in RDE, it's still
>> a work in progress, but it's not far from it :
>> https://lists.sr.ht/~abcdw/rde-devel/patches/49956
>
> I'll take a look. I knew there had to be more people working on this idea,
> but it's not always easy to find these projects.
In the code there, the function propagate-packages will indeed try and
propagate every package through the graph node.
Four tricky points though :
- propagating some packages that are used in build-systems will trigger
massive rebuilds (e.g. go, emacs, python, ocaml, texlive), you'll
probably have to be smart about what you want to avoid to propagate, but
it's great because guix can already hide a package to
package-inputs-rewriting using (hidden-package {package-name}). There are some
examples in the series.
- some packages are present under different names (emacs has
emacs-minimal, emacs, emacs-pgtk, emacs-wide-int...) and that is not
handled by this function.
- this has a cost. I haven't timed it yet, but the slowdown is
noticeable, though still quite usable.
- you of course have to get the packages into the function from a
profile. Here's it's done in RDE's code, but that should be quite
doable in Guix too.
>
> - sc
--
Best regards,
Nicolas Graves
Re: Functional package interface
Hi spacecadet! Isn't what you're trying to do already in Guix? Have a look at package-inputs-rewrite right there : https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html I've also been working on general package propagation in RDE, it's still a work in progress, but it's not far from it : https://lists.sr.ht/~abcdw/rde-devel/patches/49956 Best regards, Nicolas On 2024-04-14 07:02, spacecadet wrote: > Hi guix > > I started working on a "functional interface" to guix packages, as an > approach to globally modifying packages in an environment, similar to > nix overlays or the parameterization project. > Right now it's just a syntax rule that you can wrap a bunch of package > definitions in with some inputs in the style of a let. > > > (define-syntax define-public-package-set >(syntax-rules () > ((define-public-package-set pkgset >((input ...) > ...) >(package-name package-def) >...) > (begin > (define-public pkgset > (lambda* (#:optional packages > #:key (input ...) > ... > #:allow-other-keys) > (define package-name package-def) > ... > (cond ((and packages (list? packages)) >(map (lambda (package) > (cond ((eq? package 'package-name) > `(package-name . ,package-name)) > ...)) > packages)) > (packages > (cond ((eq? packages 'package-name) >package-name) > ...)) > (else > `((package-name . ,package-name) > ...) > (set-procedure-property! pkgset 'package-set? #t) > (define-public package-name > (pkgset 'package-name)) > ... > > > Tried rewriting the guile packages module with it, link to the full > code further down but here's a snip: > > > ;; existing module > (define-module (gnu packages guile) >#:use-module ((guix licenses) #:prefix license:) >#:use-module (gnu packages) > ... > > ;; package-set definition > (define-public-package-set gnu-packages-guile >((bash-minimal bash-minimal) ;; inputs > (gawk gawk) > (gmp gmp) > ... > (url-fetch url-fetch)) > >;; packages >(guile-1.8 > (package >(name "guile") > ... > > > You end up with a public "gnu-packages-guile" function that takes > keyword-argument inputs like: > > (gnu-packages-guile #:gawk (@ (gnu packages bioinformatics) bioawk)) > ;; => all the packages in gnu/packages/guile.scm, but every instance > ;; of awk is replaced with bioawk > > > Then returns an alist of all the packages in the set with the inputs > appropriately "modified". For the keys in the alist I'm using the > variable names as symbols instead of the package names like in inputs, > because I feel that's more generally appropriate in the case where a > package-set might contain something that's not a package record. > Will probably write a helper function that spits out input pairs. > > It can also take a single symbol or list of symbols as an optional > argument to produce either a single package or list of requested > packages: > > > (gnu-packages-guile 'guile-3.0) > ;; => # (gnu-packages-guile '(guile-2.2 guile2.2-json)) > ;; => (# > > Packages still get define-public'd, I assume in a way that would > preserve the existing working condition of the repository (although > there is one issue right now, more below) so this could hopefully turn > into a drop-in addition after some more work. I tried to make very few > changes necessary to the existing code to for the same reason. > > Eventually, the goal is to be able to create an operating system > definition (or manifest, or anything else) using this, with a > hypothetical case like: > > > (use-package-modules base network etc.) > > (define my-package-set >(packaget-set-append gnu-packages-base > gnu-packages-network ...)) > > (with-package-set >(my-package-set #:mesa something-else) >(operating-system > (...))) > > > Adapting more complicated package modules would probably be a task, but > I'm invested enough to keep working on it. > > There are also a few problems with the current implementation, and I > think they all boil down to one issue: > If packages A and B are both in the same module, and B is an input to > A, I can't replace B. > There may be a solution, it might be as simple as providing a dummy > input for each package in the module, I don't know, open to ideas. > > Another more minor problem is that it won't pull: > > > In ice-9/boot-9.scm: > 222:29 19 (map1 _) > 222:29 18 (map1 _) > 222:29 17 (map1 _) > 222:29 16 (map1 _) > 222:29 15 (map1 _) > 222:17 14 (map1
Re: Shepherd timers
Hi Ludo' On Wed, Apr 10 2024, Ludovic Courtès wrote: > Could you share this service or at least the (calendar-event …) bit? It was my error. The iota in (calendar-event #:minutes '(iota 12 3 5)) should not have been quoted. The service definition was part of the message to which you responded. [1] My apologies. > Feedback & suggestions welcome! As a feature request, it would be nice to run timers as users other than root. The situation is somewhat aggravated because 'runuser' is not being built or shipped in 'util-linux' in order to avoid a dependency on linux-pam. The natural replacement su from the same package, which does nearly the same thing except it is setuid root, can only be found---as a working program---in the non-reproducible path /run/setuid-programs/su. The only other way may be to resort to the fork/wait functionality in GNU Guile. * * * To encourage adoption of these timers among Guix user, I'll also share some of my timers: Btrbk Snapshot [2] Mdadm Resync service [3] Guix Garbage Collector service [4] Debbugs Config Sync service [5] Debbugs Bug Data Sync service [6] Borg Backup service [7] A variation of the Mdadm Resync service should probably run on all Guix systems. It prevents bitrot on MD arrays from cosmic rays or heat by writing good copies of all sectors to all array elements once a month. The Borg Backup service currently requires a modified version of Guix to find SSH. Alternatives are the environment variable BORG_RSH or the command line variable --rsh, but I believe our version should be modified to find ssh for automated use. Kind regards Felix [1] https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00256.html [2] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L664-L714 [3] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L716-L755 [4] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L757-L778 [5] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L780-L827 [6] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L829-L956 [7] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L556-L662
Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file
Hi Nicolas, On Fri, Apr 12 2024, Ludovic Courtès wrote: > Emacs supports systemd-style socket activation so, instead of using a > PID file, you could use ‘make-systemd-constructor’. Ludo' may have meant to write "Shepherd" instead of Emacs. Here are a few examples for how you might use that beautiful constructor. [1][2][3] Alas, I don't much like the name, which refers to the true daemon called systemd. Instead I would prefer "make-socket-listener-constructor" or similar. Kind regards Felix [1] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L958-L987 [2] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L989-L1018 [3] https://codeberg.org/lechner/system-config/src/commit/db9edb46caf36fe15bc6f8abc5d1df184b6d5c5f/host/wallace-server/operating-system.scm#L1020-L1047
Re: bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx
Hi Carlo, Thanks for fixing the Cc: addresses. I should not have included the bug filing address in my reply. On Sun, Apr 14 2024, Carlo Zancanaro wrote: > We could avoid generating unnecessary self-signed certificates by first > checking if we already have certificates from certbot, and creating the > symlink straight away if we can. That would seem wise to me. > The current code uses the rsa-key-size from the > , or 4096 if that is unset (the default). This > is probably [excessive] given we don't actually need, or want, to use > the initial certificates. > > We could instead use the smallest key size that openssl supports (512?). Like you, I asked myself why those self-signed certificates, which are mostly useless, would be 4096-bit strong. I am more offended, however, that they were generated with a lifetime of just one day. What happens if certbot is not yet configured, and the sysadmin forgot to do so for a few days? A long time span, such as ten years (3650 days) might be more appropriate for the fallback certificates. By the way, in Debian we call them "snake oil". I believe they are present on all systems. Kind regards Felix
Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file
On 2024-04-12 22:38, Ludovic Courtès wrote:
> Hi Nicolas,
>
> Nicolas Graves skribis:
>
>> As promised to Stefan a few months ago, here's a use case of
>> Shepherd/Emacs implementation that we developped in RDE.
>
> Would be nice to have it in Guix Home!
Something like this seems to work:
(define (emacs-shepherd-service config name)
(shepherd-service
(documentation
(format #f "Emacs server. Use ~a to connect to it."
(if (eq? 'server name)
"@code{emacsclient}"
(format #f "@code{emacsclient -s ~a}" name
(provision `(,(symbol-append 'emacs- name)))
(requirement '(emacs))
(modules '((shepherd support))) ;for '%user-runtime-dir'
(start #~(make-systemd-constructor
(list #$(file-append
(home-emacs-configuration-emacs config)
"/bin/emacs") #$(format #f "--fg-daemon=~a" name))
(list (endpoint
(make-socket-address
AF_UNIX
(string-append %user-runtime-dir
"/emacs/" #$(symbol->string name)))
#:name '#$(format #f "emacs-~a" name)
#:socket-directory-permissions #o700))
#:log-file (string-append
(getenv "XDG_STATE_HOME") "/log"
"/emacs-" #$(symbol->string name) ".log")))
(stop #~(make-systemd-destructor
But I'm not sure it's better regarding user experience. On RDE we
implemented a notifier that parses the result of
herd eval root "(and=> (lookup-service 'emacs-server) service-status)"
thus giving a nice "Emacs is currently starting" notification.
This evaluation doesn't seem to work using make-systemd-constructor,
although it has its advantages (indeed launches a frame when available).
It would be nice if service-status could "sync" with
make-systemd-constructor in this case.
I would be happy to send such a patch for Guix (is there already some
patch series on which to graft this?), WDYT @Ludo?
I can also send this in RDE, it simplifies a lot although I'm still not
sure it yields a better user experience. @Andrew?
>> We're using the --daemon option on the Shepherd side to launch the
>> server in the background, include code in Emacs configuration to make it
>> create a pid-file as soon as the server has started, and redefine
>> kill-emacs to be managed by the Shepherd.
>
> Emacs supports systemd-style socket activation so, instead of using a
> PID file, you could use ‘make-systemd-constructor’.
>
> Now, that code in emacs.c is unfortunately implemented via libsystemd
> and thus disabled in Guix. Using libsystemd in this case is unnecessary
> (and increases the attack surface, as we’ve seen with the xz backdoor):
> it could read the ‘LISTEN_FDS’ and ‘LISTEN_PID’ environment variables
> instead of calling the sd_* functions.
>
> https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html
>
> https://www.gnu.org/software/shepherd/manual/html_node/Service-De_002d-and-Constructors.html#index-make_002dsystemd_002dconstructor
>
> Thanks,
> Ludo’.
--
Best regards,
Nicolas Graves
Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file
On 2024-04-13 16:20, Nicolas Graves wrote: > On 2024-04-12 22:38, Ludovic Courtès wrote: > >> Hi Nicolas, >> >> Nicolas Graves skribis: >> >>> As promised to Stefan a few months ago, here's a use case of >>> Shepherd/Emacs implementation that we developped in RDE. >> >> Would be nice to have it in Guix Home! > > I am commited to merge RDE contributions upstream when this is possible, > I will when it's mature enough / adapted for Guix ;) > >> >>> We're using the --daemon option on the Shepherd side to launch the >>> server in the background, include code in Emacs configuration to make it >>> create a pid-file as soon as the server has started, and redefine >>> kill-emacs to be managed by the Shepherd. >> >> Emacs supports systemd-style socket activation so, instead of using a >> PID file, you could use ‘make-systemd-constructor’. >> >> Now, that code in emacs.c is unfortunately implemented via libsystemd >> and thus disabled in Guix. Using libsystemd in this case is unnecessary >> (and increases the attack surface, as we’ve seen with the xz backdoor): >> it could read the ‘LISTEN_FDS’ and ‘LISTEN_PID’ environment variables >> instead of calling the sd_* functions. >> >> https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html >> >> https://www.gnu.org/software/shepherd/manual/html_node/Service-De_002d-and-Constructors.html#index-make_002dsystemd_002dconstructor > > Thanks Ludo, that is precisely the feedback I was looking for. > > Maybe some feedback on the Emacs side about this? There are indeed very > few places where systemd sd_* functions are called in emacs.c, should we > try and re-implement them instead of using the library as is? Would that > be a contribution Emacs devs would be interested in? That would > definitely be beneficial for Emacs on Guix as highlighted by Ludo'. For the Guix side: it seems to be possible without Emacs source code change and by using elogind instead of systemd, there seems to be some code in configure.ac to handle this case. Will try this. > >> >> Thanks, >> Ludo’. -- Best regards, Nicolas Graves
Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file
On 2024-04-12 22:38, Ludovic Courtès wrote: > Hi Nicolas, > > Nicolas Graves skribis: > >> As promised to Stefan a few months ago, here's a use case of >> Shepherd/Emacs implementation that we developped in RDE. > > Would be nice to have it in Guix Home! I am commited to merge RDE contributions upstream when this is possible, I will when it's mature enough / adapted for Guix ;) > >> We're using the --daemon option on the Shepherd side to launch the >> server in the background, include code in Emacs configuration to make it >> create a pid-file as soon as the server has started, and redefine >> kill-emacs to be managed by the Shepherd. > > Emacs supports systemd-style socket activation so, instead of using a > PID file, you could use ‘make-systemd-constructor’. > > Now, that code in emacs.c is unfortunately implemented via libsystemd > and thus disabled in Guix. Using libsystemd in this case is unnecessary > (and increases the attack surface, as we’ve seen with the xz backdoor): > it could read the ‘LISTEN_FDS’ and ‘LISTEN_PID’ environment variables > instead of calling the sd_* functions. > > https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html > > https://www.gnu.org/software/shepherd/manual/html_node/Service-De_002d-and-Constructors.html#index-make_002dsystemd_002dconstructor Thanks Ludo, that is precisely the feedback I was looking for. Maybe some feedback on the Emacs side about this? There are indeed very few places where systemd sd_* functions are called in emacs.c, should we try and re-implement them instead of using the library as is? Would that be a contribution Emacs devs would be interested in? That would definitely be beneficial for Emacs on Guix as highlighted by Ludo'. > > Thanks, > Ludo’. -- Best regards, Nicolas Graves
Re: bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx
Hi Clément, On Tue, Jan 30 2024, Clément Lassieur wrote: > Carlo's solution allows to have a working nginx even when certbot > fails. I just upgraded a server to the latest Guix version, which I think includes a version of this patch. To my surprise OpenSSL, which I saw in proced, generated a lot of certificates in /etc/certs. I am talking about pages and pages of asterisk, plusses, and dots for a system with twenty or so certificates. Is it possible that they were generated as a result of the patch? It would be unfavorable to create such certificates when they are not needed. It reduces valuable server entropy. Kind regards Felix
[Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file
Hi Guix, Emacs,
As promised to Stefan a few months ago, here's a use case of
Shepherd/Emacs implementation that we developped in RDE.
We're using the --daemon option on the Shepherd side to launch the
server in the background, include code in Emacs configuration to make it
create a pid-file as soon as the server has started, and redefine
kill-emacs to be managed by the Shepherd.
Originally I asked Stefan because I wasn't happy with the current
Emacs/Shepherd interaction possibilities, as Emacs doesn't provide a
native --pid-file option. He advised me to share once we found a
solution to highlight the situation, here it is.
Cheers,
Nicolas
Start of forwarded message
From: Nicolas Graves
To: ~abcdw/rde-de...@lists.sr.ht
Cc: ngra...@ngraves.fr
Subject: [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with
shepherd and pid-file
Date: Thu, 11 Apr 2024 01:48:13 +0200
---
src/rde/features/emacs.scm | 42 -
src/rde/home/services/emacs.scm | 9 ---
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/src/rde/features/emacs.scm b/src/rde/features/emacs.scm
index 7d055377..74ba306e 100644
--- a/src/rde/features/emacs.scm
+++ b/src/rde/features/emacs.scm
@@ -440,7 +440,47 @@ Prefix argument can be used to kill a few words."
;; Configure ediff for window manager.
(setq ediff-diff-options "-w"
ediff-split-window-function 'split-window-horizontally
- ediff-window-setup-function 'ediff-setup-windows-plain))
+ ediff-window-setup-function 'ediff-setup-windows-plain)
+
+ ;; Configure emacs background server.
+ ,@(if (get-value 'emacs-server-mode? config)
+ `((add-hook
+'emacs-startup-hook
+(lambda ()
+ (when server-mode
+(advice-add
+ 'kill-emacs :override
+ (lambda ( arg restart)
+ "\
+Make GNU Shepherd kill the Emacs server.
+
+If RESTART is non-nil, instead of just exiting at the end, herd will restart
+an Emacs server. ARG is ignored.
+
+Note: This is added through RDE. Redefining a primitive is not advised in
+Emacs, but this one is high-level (present in few other functions), and
+tested."
+ (interactive)
+ (if restart
+ (call-process-shell-command
+(concat "herd restart emacs-" server-name)
+nil 0)
+ (call-process-shell-command
+(concat "herd stop emacs-" server-name)
+nil 0
+;; Tell shepherd that emacs is started through pid-file.
+(with-temp-file (concat (getenv "XDG_RUNTIME_DIR")
+"/emacs/" server-name ".pid")
+(insert (number-to-string (emacs-pid)))
+ (add-hook
+'kill-emacs-hook
+(lambda ()
+ (when server-mode
+(let ((pidfile (concat (getenv "XDG_RUNTIME_DIR")
+ "/emacs/" server-name ".pid")))
+ (when (file-exists-p pidfile)
+(delete-file pidfile)))
+ '()))
#:summary "General settings, better defaults"
#:commentary "\
It can contain settings not yet moved to separate features."
diff --git a/src/rde/home/services/emacs.scm b/src/rde/home/services/emacs.scm
index 9b0b37af..95156a4d 100644
--- a/src/rde/home/services/emacs.scm
+++ b/src/rde/home/services/emacs.scm
@@ -188,11 +188,14 @@ Same as @code{init-el}, but result will go to
@file{early-init.el}."))
(start #~(make-forkexec-constructor
(list #$(file-append
(home-emacs-configuration-emacs config)
- "/bin/emacs") #$(format #f "--fg-daemon=~a" name))
+ "/bin/emacs") #$(format #f "--daemon=~a" name))
#:log-file (string-append
(getenv "XDG_STATE_HOME") "/log"
- "/emacs-" #$(symbol->string name) ".log")))
- (stop #~(make-kill-destructor
+ "/emacs-" #$(symbol->string name) ".log")
+ #:pid-file (string-append (getenv "XDG_RUNTIME_DIR") "/emacs/"
+ #$(symbol->string name) ".pid")))
+ (stop #~(make-kill-destructor))
+ (respawn? #f)))
(define (add-emacs-shepherd-service config)
(if (not (null? (home-emacs-configuration-emacs-servers config)))
--
2.41.0
End of forwarded message
Start of forwarded message
From: Andrew Tropin
To: Nicolas Graves , ~abcdw/rde-de...@lists.sr.ht
Cc: ngra...@ngraves.fr
Subject: Re:
Re: The `channels' field of `operating-system' record
Hi Nathan, On Mon, Apr 08 2024, Nathan Dehnel wrote: > I don't think you're supposed to edit /etc/guix/channels.scm directly, > I think it's generated by guix system reconfigure. As Ludo' pointed out on Mastodon recently [1] the system channels can also be customized, if needed. [2] Kind regards Felix [1] https://toot.aquilenet.fr/@civodul/112235132695871431 [2] https://guix.gnu.org/manual/devel/en/html_node/Customizing-the-System_002dWide-Guix.html
HEPiX Spring 2024 in Paris, France
Hi, An event for system administrators in high-energy physics may still be looking for for talks for next week in Paris: https://indico.cern.ch/event/1377701/overview The event is called HEPiX: https://www.hepix.org/ Just thought I'd pass it on. I am stateside and did not recognize any of the participants as Guix contributors. Kind regards Felix
Re: [python-team] Weird python-notebook test failures
Hi Ricardo, On Sat, Apr 06 2024, Ricardo Wurmus wrote: > Any ideas what might be going on here? Could it be "ModuleNotFoundError: No module named 'jupyter_server'"? Kind regards Felix
Re: Should we include nss-certs out of the box?
Hi Maxim, On Wed, Apr 03 2024, Maxim Cournoyer wrote: > I applaud the idea to have the users make a conscious decision Who does? > It apparently even makes it impossible to run 'guix pull' More than that, the references to online sources in our package declarations are useless. Would it be possible to install nss-certs from source? > [nss-certs would] be in the basic set of an operating-system packages That strikes me as rational but it would be valuable to hear from the other side---if there is one. Kind regards Felix
Re: Shepherd timers
Hi Ludo' On Sun, Mar 24 2024, Ludovic Courtès wrote: > you can do anything you can do with a service: stop it, unload it, > load a replacement, and so on. Wow, do I love those timers! I just converted my system Mcron jobs to Shepherd timers. The user jobs are next. What a great new feature! One small suggestion: Could calendar-event please offer a symbolic interface for days-of-week? I'm thinking of 'monday, 'tuesday, and so on instead of numbers. In Europe, the week starts on Mondays. In the US, it starts on Sundays. Cron and its descendants made an error in settling on a particular numbering. We can fix it now. With my tongue in cheek, at least one disputed but very old tradition we received recorded that the world was completed on a Friday, at some time before sunset. I could therefore see starting the count on Saturday or, if anyone would like to have a day of rest, on Sunday, but there is scant precedent for a start on Monday. That choice goes back less than a hundred years. It was only made official for some parts of the world in 1988. That was less than forty years ago. [1][2] A symbolic interface for the days of the week would, on the other hand, be more intuitive and equitable towards competiting traditions. Symbols would also avoid the ordering that elevates one of the weekdays into the first position and above its peers. I'd be happy to suggest a patch, if needed. Thanks for this great work! Kind regards Felix [1] https://www.timeanddate.com/calendar/days/first-day-of-the-week.html [2] https://www.calendarr.com/united-states/first-day-of-the-week/
Re: Shepherd timers
Hi Ludo' On Thu, Mar 28 2024, Ludovic Courtès wrote: > I start, restart, reload, restart, etc. and it seems fine. Okay, this works fine now. I had quoted the 'iota'. The status seems a bit bungled, though. I now use a lambda, i.e. no 'command', with a fresh pull from 'devel'. Thanks! Kind regards Felix * * * $ herd status rsync-debbugs Status of rsync-debbugs: It is running since 07:14:44 (4 minutes ago). Timed service. Periodically running Scheme code. It is enabled. Provides (rsync-debbugs). Requires (networking file-systems). Will be respawned. Recent messages: 2024-04-02 07:18:00 receiving incremental file list 2024-04-02 07:18:00 2024-04-02 07:18:00 sent 23 bytes received 1,244 bytes 844.67 bytes/sec 2024-04-02 07:18:00 total size is 144,672 speedup is 114.18 Upcoming timer alarms: Backtrace: 8 (primitive-load "/run/current-system/profile/bin/herd") In shepherd/scripts/herd.scm: 796:9 7 (main . _) In ice-9/boot-9.scm: 1747:15 6 (with-exception-handler # _ #:unwind? _ # _) In shepherd/scripts/herd.scm: 727:11 5 (_) In srfi/srfi-1.scm: 634:9 4 (for-each # ((service (version 0) (# (#)) # ?))) In shepherd/scripts/herd.scm: 323:19 3 (display-timer-events #< seconds: (0) minutes: (3 8 13 18 23 28 33 38 43 48 53 58) h?> ?) In shepherd/service/timer.scm: 253:21 2 (next-calendar-event #< seconds: (0) minutes: (3 8 13 18 23 28 33 38 43 48 53 58) ho?> ?) 233:18 1 (week-days->month-days #f 4 _) In unknown file: 0 (memv 1 #f) ERROR: In procedure memv: In procedure memv: Wrong type argument in position 2 (expecting list): #f
Re: Shepherd timers
Hi Dale, On Sun, Mar 31 2024, Adam Faiz wrote: > Could the Shepherd depend on mcron for the timer functionality? I know you your name isn't Dave. Sorry! Kind regards Felix
Re: Shepherd timers
Hi Adam, On Sun, Mar 31 2024, Adam Faiz wrote: > Could the Shepherd depend on mcron for the timer functionality? Since > mcron already handles scheduling commands to run at a certain time, > there would be no need to reimplement it again. I don't wish to speak for the Mcron maintainer Dave, who reads this list, or for Ludo', to whom your message was addressed, but the Shepherd's scheduler [1] strikes me as potentially superior as it may avoid this calendaring issue in Mcron. [2] Kind regards Felix [1] https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service/timer.scm?h=devel#n149 [2] https://lists.gnu.org/archive/html/bug-mcron/2023-12/msg0.html
Re: Backdoor in upstream xz-utils
Hi Ryan, On Fri, Mar 29 2024, Ryan Prior wrote: > I'm reading today that a backdoor is present in xz's upstream tarball > (but not in git), starting at version 5.6.0. Source: > https://www.openwall.com/lists/oss-security/2024/03/29/4 Thanks for sending this! This is an extremely serious vulnerability with criminal intent. I cc'd guix-secur...@gnu.org just in case you haven't. > Guix currently packages xz-utils 5.2.8 as "xz" using the upstream > tarball. [...] Should we switch from using upstream tarballs to some > fork with more responsible maintainers? Guix's habit of building from tarballs is a poor idea because tarballs often differ. For example, maintainers may choose to ship a ./configure script that is otherwise not present in Git (although a configure.ac might be). Guix should build from Git. > Is there a way we can blacklist known bad versions? Having said all that, I am not sure Guix is affected. On my systems, the 'detect.sh' script shows no referece to liblzma in sshd. Everyone, please send additional reports. Kind regards Felix
Hang on 'sending 0 store items'
Hi, When trying to 'deploy' the command hangs for one piece of my equipment with the perplexing message: guix deploy: sending 0 store items (0 MiB) to 'FQDN'... Has anyone seen it before? Is there a cure? Thanks! Kind regards Felix
Re: Shepherd timers
Hi Ludo',
On Sun, Mar 24 2024, Ludovic Courtès wrote:
> I pushed to the ‘devel’ branch of the Shepherd a new module that
> implements “timers”
Wow, that's super exciting! I promptly reconfigured my channels to pull
in the Shepherd branch. (Anyone who wants to do the same, please reply
here for info.) For me, Shepherd timers will allow the temporary
stoppage of individual cron jobs.
For a server that can make debugging much easier.
> (command '("sh" "-c" "echo Hi from $PWD.; sleep 20; echo done")))
The simple example worked great, but my more complex attempt to convert
an mcron job seems to have failed. Do you know why?
--8<---cut here---start->8---
(define (rsync-debbugs-shepherd-service config)
(shepherd-service
(provision '(rsync-debbugs))
(requirement '(networking file-systems))
(modules '((shepherd service timer)
(srfi srfi-1)))
(start #~(make-timer-constructor
(calendar-event #:minutes '(iota 12 3 5))
(command `(,#$(file-append rsync "/bin/rsync")
"-4"
"--delete"
"-av"
"--password-file=/root/secrets/var-lib-debbugs.rsync"
"debbugs-...@debbugs.gnu.org::var-lib-debbugs"
"/var/lib/debbugs/"
(stop #~(make-timer-destructor))
(documentation "Timer to rsync Debbugs bug details to this machine.")))
(define rsync-debbugs-service-type
(service-type
(name 'rsync-debbugs)
(description
"Rsync Debbugs bug details to this machine.")
(extensions
(list
(service-extension shepherd-root-service-type
(compose list rsync-debbugs-shepherd-service
(default-value #f)))
--8<---cut here---end--->8---
and then later
--8<---cut here---start->8---
(service rsync-debbugs-service-type)
--8<---cut here---end--->8---
At the bottom of this message is the log from my Eshell session. The
first funny thing was that the old timer info still showed in 'herd
status'. That's probably because some services are not reloaded
automatically. I can never figure out which are and which aren't.
More important, however, I was unable to get status information from the
more complex timer service. What did I do wrong, please?
Thanks for this excellent work, especially in calender-event. The
Shepherd is a super cute piece of software!
Kind regards
Felix
* * *
guix deploy: successfully deployed wallace-server
#[STATUS] End time 2024-03-25 14:02:35, duration 86.932s
[~]
> cd /ssh:root@wallace-server.local:/srv/patchwise
(root@wallace-server.local)[/s/srv/patchwise]
> herd status rsync-debbugs
Status of rsync-debbugs:
It is running since 13:44:40 (19 minutes ago).
Timed service.
Periodically running: sh -c "echo Hi from $PWD.; sleep 20; echo done".
It is enabled.
Provides (rsync-debbugs).
Requires (networking file-systems).
Will be respawned.
Recent runs:
2024-03-25 14:03:06 Process exited with code 1.
2024-03-25 14:03:14 Process exited with code 1.
2024-03-25 14:03:21 Process exited with code 1.
2024-03-25 14:03:29 Process exited with code 1.
2024-03-25 14:03:44 Process exited with code 1.
Recent messages:
2024-03-25 14:03:44 exec of "sh" failed: No such file or directory
2024-03-25 14:03:44
2024-03-25 14:03:44 Some deprecated features have been used. Set the
environment
2024-03-25 14:03:44 variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
2024-03-25 14:03:44 program to get more information. Set it to "no" to
suppress
2024-03-25 14:03:44 this message.
Upcoming timer alarms:
14:04:00 (in 15 seconds)
14:04:07 (in 22 seconds)
14:04:15 (in 30 seconds)
14:04:22 (in 37 seconds)
14:04:30 (in 45 seconds)
#[STATUS] End time 2024-03-25 14:03:45, duration 1.430s
(root@wallace-server.local)[/s/srv/patchwise]
> herd restart rsync-debbugs
Service user-homes has been started.
Starting service rsync-debbugs...
Service rsync-debbugs started.
Service rsync-debbugs running with value #< channel: #< getq:
# getq-gc-counter: # putq: #
putq-gc-counter: #> event:
#< seconds: (0) minutes: (iota 12 3 5) hours: (0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23) days-of-month: (1 2 3 4 5 6 7 8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31) months: (1
2 3 4 5 6 7 8 9 10 11 12) days-of-week: #f> action: #< arguments:
("/gnu/store/1g0gk9pcymgc0bb1dh115swakmh438p6-rsync-3.2.7/bin/rsync" "-4"
"--delete" "-av" "--password-file=/root/secrets/var-lib-debbugs.rsync"
"debbugs-...@debbugs.gnu.org::var-lib-debbugs" "/var/lib/debbugs/") user: #f
group: #f environment-variables: ("HOME=/" "TERM=linux"
"BOOT_IMAGE=/gnu/store/psn2jwyrvr8jxb1nrndxf3h7kg8vvfwa-linux-6.6.2/bzImage"
Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)
> IMHO This is a quiet egocentric point of view. > What are you implying with the "loud" minority here? Hi, "Quiet" is a funny typo here. Also, "peace on Earth and goodwill toward [all]." [1] Please [1] https://www.youtube.com/watch?v=74ocbvwam7c
Re: Patch review session tomorrow (Thursday 7th March)
Hi, On Wed, Mar 06 2024, Steve George wrote: > 18:00 UTC, 18:00 GMT (London), 19:00 CET (Paris), 13:00 EST (New York) As one of the weirdos out in California, I'll add 10 AM Pacific. Please join! Kind regards Felix
Re: How would you feel about this derivative logo for Nonguix?
Hi Felipe, On Wed, Mar 06 2024, Luis Felipe wrote: > That page also mentions the reasoning behind the derivative logo. Absolutely gorgeous! I like A1, although in a fit of disrespect I might have placed the horns upside down like a scorpion... Great work. The project is very lucky to have you! Kind regards Felix P.S. Please do not use Nonguix if you can avoid it.
Bugs and Patches---or rather, bugs or patches?
Hi, We track bugs and patches separately. Does the distinction serve a purpose? May I combine them? Thanks! Kind regards Felix
Re: LUKS2 support in Guix
Hi Fabio, On Fri, Mar 01 2024, Fabio Natali wrote: > could it be worth to amend the manual to say that it has to be LUKS1 Based on the many folks who trip over this, especially on IRC, that seems like a great idea! Kind regards Felix
Re: A basic Shepherd bug?
Hi Attila, On Fri, Mar 01 2024, Attila Lendvai wrote: > you `guix system reconfigure` into a new shepherd version, and after > that the currently running shepherd init process went 100% CPU, > i.e. it was busy looping in one thread? Yes, I used 'guix deploy.' I did so several times before noticing the unusual load. I don't usually reboot when changing services, but have to when adding new ones. I'm so lazy about it, sometimes it seems we should keep track of kernel and Shepherd versions separately from other features of the system. In effect, we would have two types of "system generations," namely: A. Kernel/PID 1 generation B. Features generation (not using the word "services" here) > a quick and dirty solution It was just a thought. Ideally, it would appear in a bug tracker so someone can think about it with the benefit of hindsight later. > interesting thoughts on migration and staged computation I just wished for an alert when the code deployed as PID 1 had changed, but no worries, please. There is so much to do. Thanks for your (and Ludo's) hard work on the Shepherd. I love it! Kind regards Felix
LWN: A look at Nix and Guix
Hi everyone, LWN published an article about Nix and Guix: https://lwn.net/SubscriberLink/962788/4127dcbb2cf72474/ It raises our public profile, although I am a bit more enthusiastic than the author. I think we are the next Debian. Do we have a PR department? Just kidding... Kind regards Felix P.S. LWN requires a subscription but they encourage the distribution of free links to project mailing lists. [1] That way, potential subscribers can sample their content. If you find LWN interesting, please ask your employer for a subscription to LWN. [1] https://lwn.net/op/FAQ.lwn#slinks
Re: A basic Shepherd bug?
Hi Attila On Sun, Dec 24 2023, Attila Lendvai wrote: > you should follow the instructions in [1]; namely: > > https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00018.html > > together with "Installing development snapshots with Guix" in > shepherd's README to add shepherd's channel. I did so on a production system which I do not reboot often. Two days ago, I reconfigured and saw a new Shepherd version being deployed. It used up a lot of CPU cycles until I rebooted. It makes sense that upgrading the Shepherd requires a reboot, but maybe a warning somewhere would be appropriate, if possible. Maybe an email to root? Kind regards Felix
Re: Rust team branch merged
Hi Rust Team, On Wed, Feb 28 2024, Andreas Enge wrote: > Congratulations to the Rust team (aka Efraim) for this big endeavour! How timely are your good news! Please let this article brighten your day. https://www.infoworld.com/article/3713203/white-house-urges-developers-to-dump-c-and-c.html Kind regards Felix
Re: Core-updates coordination and plans
Hi Andreas, On Tue, Feb 27 2024, Andreas Enge wrote: > a time-based approach sounds like a good idea How about the second Monday and Tuesday of every month? That is a slow time for contributors who have more time on weekends. > It might still be good to do it in a separate branch instead of > master, and to merge it after substitutes are available. While it is good practice to build and test changes, I have a better proposal for a better availability of substitutes, below. > Since "guix pull" takes the latest commit from the master branch, > users could otherwise end up with a world-rebuild commit without > substitutes. In a nod to Vagrant's remark, I would accept the "moving target" and instead publish the substitute coverage for each commit. A good algorithm could figure out from a user's system configuration which most recent commit provides all the required packages. For more general use, a "prebuilt" branch could track commits that provide 100% universal coverage. That should be our goal, even if it sounds elusive today. > So maybe we could have a time window, but also discuss and prepare before- > hand which big changes we would like to push? Please have hope humankind. Why not a free for all? Most people will feel uncomfortable with the freedom, anyway. The fear of messing up will drive them to the mailing lists. > Having a team or a dedicated individual (in both senses of the terms, > a designated person with a lot of dedication) to shepherd this through > would also be good. I like the idea of you taking charge! You would bring experience, credibility and an agreeable personality---all in nearly perfect harmony. Are you available? Kind regards Felix
Re: Core-updates coordination and plans
Hi Andreas, On Wed, Jan 31 2024, Andreas Enge wrote: > We should be able to do a world-rebuild not once or twice a year, but > at least every month How about a 48-hour period every month in which commits are permitted even if they cause "world rebuilds"? We could pause the substitute builders during that period. It would get rid of core-updates forever. Kind regards Felix
Re: (almost) deterministic patchsets
This is basically done in https://git.sr.ht/~ngraves/dotfiles/commit/bd542512dfad2beccb4a6cdb2468f79aa869a55b Maybe some things need some polish, but the PoC is definitely here. Feel free to reuse this in upstream guix if you want. On 2024-02-13 14:35, Nicolas Graves wrote: > Hi ! > > I've written this (gpl3+) that should be able to fetch patchsets for > both guix and rde. This should be robust enough for guix/rde use IMO. > > (define-module (guix mbox-download) > #:use-module (guix packages) > #:use-module ((guix self) #:select (make-config.scm)) > #:use-module (guix modules) > #:use-module (guix monads) > #:use-module (gnu packages guile) > #:use-module (gnu packages tls) > #:use-module (gnu packages version-control) > #:use-module (guix store) > #:use-module (guix gexp) > #:use-module (guix records) > #:export (mbox-fetch > mbox-reference)) > > (define-record-type* > mbox-reference make-mbox-reference > mbox-reference? > (type mbox-reference-type) > (id mbox-reference-id) > (version mbox-reference-version)) > > (define* (mbox-fetch ref hash-algo hash #:optional name > #:key (system %current-system) guile) > > (define uri > (format > #f > (assoc-ref > '((gnu . > "https://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=~a;mbox=yes;) > (rde . "https://lists.sr.ht/~~abcdw/rde-devel/patches/~a/mbox;)) >(mbox-reference-type ref)) > (mbox-reference-id ref))) > > (define modules > (cons `((guix config) => ,(make-config.scm)) > (delete '(guix config) > (source-module-closure '((guix build download) >(guix build utils)) > > (define build > (with-extensions (list guile-json-4 guile-gnutls) > (with-imported-modules modules > #~(begin > (use-modules (guix build utils) (guix build download)) > (let ((mbox #$(match-record ref > (type id version) > (format #f "~a-~a-~a.mbx" type id version > (setenv "TMPDIR" (getcwd)) > (setenv "XDG_DATA_HOME" (getcwd)) > (invoke #$(file-append b4 "/bin/b4") > "-d" "-n" "--offline-mode" "--no-stdin" > "am" "--no-cover" "--no-cache" > "--use-local-mbox" > (url-fetch #$uri "mbox" #:verify-certificate? #f) > "--use-version" > (number->string #$(mbox-reference-version ref)) > "--no-add-trailers" > "--outdir" "." > "--mbox-name" mbox) > (install-file mbox #$output)) > > (mlet %store-monad ((guile (package->derivation (or guile (default-guile)) > system))) > (gexp->derivation (or name > (match-record ref > (type id version) > (format #f "~a-~a-~a-mbox" type id version))) > build > ;; Use environment variables and a fixed script name so > ;; there's only one script in store for all the > ;; downloads. > #:system system > #:local-build? #t ;don't offload repo cloning > #:hash-algo hash-algo > #:hash hash > #:recursive? #t > #:guile-for-build guile))) > > > This can be used in such an example : > > (use-modules (guix mbox-download) (guix packages) (guix gexp) > (guix monads) (guix store) (guix derivations)) > > (with-store store > (run-with-store store > (mlet* %store-monad > ((drv (origin->derivation >(pk 'o (origin > (method mbox-fetch) > (uri (mbox-reference > (type 'rde) > (id 44893) > (version 4))) > (sha256 > (base32 > "1rs09wxvdaxrk2zh6g23s9min76wjm9lw0a5pjklc7cfraasi7s9"))) > (return drv > > Is guix interested in this, should I send a patch? What about renaming > this to patchset-reference instead of mbox-reference? > > My end-goal here is to use this to extend channels to channels with > patches, with something like this : > > (define* (instantiate-channel ch) > (match ch > ((name url ref patches) > (primitive-eval > `(channel > (name ',name) > ,@(if (null? patches) > `((url ,(find-home url))) > `((url ,(patched-source >(symbol->string name) >(git-checkout > (url (find-home url)) > (commit ref)) >(search-patches patches) > ,@(if ((@ (guix git) commit-id?) ref) > `((commit ,ref)) > `((branch ,ref))) >
Re: [RFC] proposal for refactoring bootloaders
Hi Lilah, On Fri, Feb 16, 2024 at 02:33:02AM -0600, Lilah Tascheter wrote: > > one more quick change that I've realized will be necessary I made some changes to my bootloader locally and believe the commit series here [1] could be useful to you. It removes a lot of the confusion that arises when the boot-parameters are rewritten on the fly. Kind regards Felix [1] https://debbugs.gnu.org/69343
How do I report bugs or feature requests in Mumi?
Hi everyone, >From now on, please use bug-m...@gnu.org [1] to report bugs in Mumi. You may also use Debbugs directly, if you are comfortable. Please do not use the Guix reporting channels anymore. Your Mumi bugs will still be visible in Mumi. You can focus on them exclusively with a filter selection of "package:mumi". The new mailing list works exactly like guix-patches@. It automatically creates new issues. The list should be available on Kyle's yhetil.org (although I presently see it only in the Atom feed). A gmane.io registration is pending. Thanks for helping to make Guix better. Please report bugs! On behalf of all Mumi contributors---past, future and present, Felix [1] https://lists.gnu.org/mailman/listinfo/bug-mumi
Re: Supporting sssd, preparing for nscd sunset
Hi, On Fri, Feb 23 2024, Ludovic Courtès wrote: > The solution would be interesting for use on Guix System ... but I > don’t see it helpful on other distros ... (We can’t really ship > ourselves because it has to be linked against the host libc.) To read more about nscd's significance on foreign distros, please see our manual. [1] Carlos O'Donnell also referenced it in his messsage. Kind regards Felix [1] https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Name-Service-Switch-1
RE: Proposal to turn off AOT in clojure-build-system
Hey Maxime, On Thu, Feb 22 2024, Maxime Devos wrote: > familiarity with good manners Sometimes it's better to admit defeat. Maybe you find this apology [1] helpful, although it was imperfect. Kind regards Felix [1] https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00141.html
Re: Proposal to turn off AOT in clojure-build-system
Hey, On Thu, Feb 22 2024, Andreas Enge wrote: > Am Thu, Feb 22, 2024 at 03:57:41PM +0100 schrieb Maxime Devos: >> Yes. It appears you are unfamiliar with (...) >> It also appears you are unfamiliar with (...) > > May I suggest to not make assumptions about what other people are familiar > with or not? There is no point in claiming that others are less knowledge- > able than you; they may know as much or even more than you Asking questions can avoid any such conclusions. It's my favorite thing. Here, I might have asked: "Do you know about...?" Goodwill toward all, Felix
Re: cannot boot after installation on VPS (via rescue system)
> > On one VPS of mine (which also happens to have Guix installed via > > rescue mode) the root is mounted from /dev/vda1. > > Out of curiosity: what's the hoster, please? https://rapiddc.pl/ It's a result of a long search for a decent Europe-based provider. I didn't choose any of the mainstream providers because of their ToS (even well-reputed Gandi had somewhat customer-hostile ToS; the requirement to purchase an insurance finally convinced me not to use them). 1984 was pretty fair but offered a DPA in horribly broken english (I still use them for non-business needs). The one I chose isn't perfect, either. As you can see, they have GDPR-incompliant Google spyware on their website (though it causes no legal risk to their customers) and they rely on nonfree JS. I couldn't find a provider who does everything perfectly so I chose based on priorities. From my PoV it's a domestic provider which also makes things easier for me (and possibly harder for others who'd like to use this message as some kind of recommendation). Good to see you solved your issue :) Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Thu, 22 Feb 2024 08:25:57 +0100 Giovanni Biscuolo wrote: > > On one VPS of mine (which also happens to have Guix installed via > > rescue mode) the root is mounted from /dev/vda1. > > Out of curiosity: what's the hoster, please? pgp_WRV10AA06.pgp Description: OpenPGP digital signature
Re: Guix Days: Patch flow discussion
Hi Vagrant, On Sun, Feb 11 2024, Vagrant Cascadian wrote: > Are there other downsides to allowing a multiple patches in a single > email? Is it perhaps more difficult to apply those patches? Kind regards Felix
Re: cannot boot after installation on VPS (via rescue system)
> --8<---cut here---start->8--- > > Scanning for Btrfs filesystems > ice-9/boot9.scm:1685:16: In procedure raise-exception: > In procedure mount: No such file or directory > GRUB loading... > Entering a new prompt. Type ',bt' for a backtrace or ',q' to continue. > [...] > scheme@(guile-user)> ,bt > In gnu/build/linux-boot.scm: > 637:8 3 (_) > 435:8 2 (mount-root-filesystem "/dev/sda3" "btrfs" # _ #:flags ?) > In unknown file: >1 (mount "/dev/sda3" "/root" "btrfs" 0 "compress=zstd") > In ice-9/boot9.scm: > 1685:16: 0 (raise-exception _ #:continuable? _) > > --8<---cut here---end--->8--- Maybe the device file is called different from /dev/sda3? On one VPS of mine (which also happens to have Guix installed via rescue mode) the root is mounted from /dev/vda1. > In particular, I don't understand why the boot script is trying to mount > the root filesystem at "/root" and not at "/" as it should: am I missing > something? Linux-based systems typically start with initrd filesystem mounted at /. They then mount the real root at some subdirectory of / and use either chroot or pivot-root system call to make the processes see it as if it were mounted at / in the first place. I'm not an expert in early boot process so please forgive me any mistakes I might have made in this explanation :) Best, Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Wed, 21 Feb 2024 10:54:16 +0100 Giovanni Biscuolo wrote: > From: Giovanni Biscuolo > To: guix-devel@gnu.org > Subject: cannot boot after installation on VPS (via rescue system) > Date: Wed, 21 Feb 2024 10:54:16 +0100 > Sender: guix-devel-bounces+koszko=koszko@gnu.org > Organization: Xelera.eu > > Hello, > > following the good guidelines from (info "(guix-cookbook) Running Guix > on a Kimsufi Server") and (info "(guix-cookbook) Running Guix on a > Linode Server") I'm developing a shell script to automate the "manual" > installation of Guix on bare metal and VPS, you can find it attached to > this email as bootstrap-guix.sh or at this git repo URL: > https://gitlab.com/softwareworkers/swws/-/blob/master/infrastructure/hosts/cornouiller/bootstrap-guix.sh?ref_type=heads > > > [bootstrap-guix.sh text/x-sh (11954 bytes)] > > > The main purpose of the script is to allow me to install Guix on > machines (bare metal or virtual) hosted by vendors who do not offer Guix > in their OS installation options, since almost all vendors provides a > rescue system that can be used to "manually" set up the environment, > partition the target disk and lastly "guix system init..." > > I've extensively tested the script locally (on bare metal and QEMU VMs), > both booting the machines via grml [1] and Guix install image and it > works as expected; I've also used it to install Guix on some bare metal. > > Now I'm trying to use it on two VPS from two different vendors, booted > in rescue mode, but after the installation (via bootstrap-guix.sh) when > I reboot the VPS I get the usual grub menu but the boot process suddenly > fails with this error (manually copied from web console, sorry for > possible typos): > > --8<---cut here---start->8--- > > Scanning for Btrfs filesystems > ice-9/boot9.scm:1685:16: In procedure raise-exception: > In procedure mount: No such file or directory > GRUB loading... > Entering a new prompt. Type ',bt' for a backtrace or ',q' to continue. > [...] > scheme@(guile-user)> ,bt > In gnu/build/linux-boot.scm: > 637:8 3 (_) > 435:8 2 (mount-root-filesystem "/dev/sda3" "btrfs" # _ #:flags ?) > In unknown file: >1 (mount "/dev/sda3" "/root" "btrfs" 0 "compress=zstd") > In ice-9/boot9.scm: > 1685:16: 0 (raise-exception _ #:continuable? _) > > --8<---cut here---end--->8--- > > In particular, I don't understand why the boot script is trying to mount > the root filesystem at "/root" and not at "/" as it should: am I missing > something? > > I suspect that the issue depends on how the rescue system root is > mounted (overlay filesystem) but I'm not sure; I cannot find a solution. > > I'm also attaching: > > - bootstrap-config.scm: automatically generated by the script and used > by "guix system init..." > > > [bootstrap-config.scm text/x-script.guile (2097 bytes)] > > > - bootstrap-mount-points.txt: automatically collected during installation > > > [bootstrap-mount-points.txt text/plain (2833 bytes)] > > > You can find all the files also here: >
Re: Non-bootstrappable NPM packages
On 2024-02-20 20:04, Jelle Licht wrote: > Nicolas Graves writes: > >> On 2019-07-24 15:41, Jelle Licht wrote: >> >>> Timothy Sample writes: >>> >>> [snip] >>> I’ve come to think that bootstrapping JavaScript might be easier than it looks. As time goes on, Node gets better at the newer JavaScript features. This removes the need for things like Babel or Rollup, since with some care, Node can run the source directly with out any transformations or bundling. That being said, TypeScript looks to be a major issue, as it is used in many fundamental JavaScript packages and it is not bootstrappable. >>> >>> Very recently (IE about 94 minutes ago), I found out something >>> interesting that might be helpful; Sucrase[0] is, among other things, a >>> typescript transpiler that does not do any type checking, and it only >>> has some runtime dependencies. >>> >>> I created some “fiio”-packages as well [1] , and I have confirmed that >>> it actually works! My next step was of course to compile TypeScript >>> proper, and this worked with one tiny snag that I reported at [2]. After >>> manually fixing these problems in the TypeScript source tree, I was able >>> to transpile the TypeScript sources using guix-packaged >>> `node-sucrase-bootstrap'. >> >> Hi Jelle! >> >> Did someone made some progress on the build-system since that to allow >> for this to be taken into account? If you still have it, could you share >> your "fiio" packages once again? The paste link is expired. Thanks! > > I don't have them anymore, but I could re-generate them. > Are you still interested, or am I too slow in responding, and are your > other node-related emails more relevant by now? I was going the esbuild route instead of the sucrase one, so that's not a need anymore. Both are viable however, this choice is questionnable. There are the packages from Wojtek in answer to this email that also bootstrap sucrase, so don't bother ;) I feel tests / native-inputs for Node is a bigger issue than the one of bundlers now. > > KR, > - Jelle > -- Best regards, Nicolas Graves
Re: Non-bootstrappable NPM packages
Hi there not sure if this was mentioned here but in case it wasn't — there was a proof of concept packaging of sucrase and jQuery as early as in 2022. You can see the relevant thread here[1]. So, yes, it's definitely easier than it seems (and easier than some used to describe it) — the only problem is that nobody seems to have picked up that work done by zamfofex ¯\_(ツ)_/¯ Wojtek [1] https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00191.html -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Tue, 20 Feb 2024 20:04:33 +0100 Jelle Licht wrote: > Nicolas Graves writes: > > > On 2019-07-24 15:41, Jelle Licht wrote: > > > >> Timothy Sample writes: > >> > >> [snip] > >> > >>> I’ve come to think that bootstrapping JavaScript might be easier than it > >>> looks. As time goes on, Node gets better at the newer JavaScript > >>> features. This removes the need for things like Babel or Rollup, since > >>> with some care, Node can run the source directly with out any > >>> transformations or bundling. That being said, TypeScript looks to be a > >>> major issue, as it is used in many fundamental JavaScript packages and > >>> it is not bootstrappable. > >> > >> Very recently (IE about 94 minutes ago), I found out something > >> interesting that might be helpful; Sucrase[0] is, among other things, a > >> typescript transpiler that does not do any type checking, and it only > >> has some runtime dependencies. > >> > >> I created some “fiio”-packages as well [1] , and I have confirmed that > >> it actually works! My next step was of course to compile TypeScript > >> proper, and this worked with one tiny snag that I reported at [2]. After > >> manually fixing these problems in the TypeScript source tree, I was able > >> to transpile the TypeScript sources using guix-packaged > >> `node-sucrase-bootstrap'. > > > > Hi Jelle! > > > > Did someone made some progress on the build-system since that to allow > > for this to be taken into account? If you still have it, could you share > > your "fiio" packages once again? The paste link is expired. Thanks! > > I don't have them anymore, but I could re-generate them. > Are you still interested, or am I too slow in responding, and are your > other node-related emails more relevant by now? > > KR, > - Jelle > > pgphCMQ9QLveP.pgp Description: OpenPGP digital signature
Re: Guidelines for bootstrapping with lots of inputs
On 2024-02-20 15:11, Adam Faiz wrote: >> WDYT? Are there guidelines somewhere about how to do proper bootstrapping in >> these cases where hundreds of packages are involved? > > Not really, but your idea to rewrite inputs for the bootstrapping process > does simplify things a lot. > > How is typescript bootstrapped? Even though you'll have to repeat the trial > and error process again, I think using sucrase is easier for bootstrapping > typescript: > https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00122.html Timothy claimed that building typescript with esbuild has been done (by singpolyma) in guixrus and it indeed seems it is. https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00123.html https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/javascript/typescript.scm What I've done currently is to bootstrap tape (but not all packages using tape as a native-input in the process). The idea is to build tap and typescript from there. -- Best regards, Nicolas Graves
Guidelines for bootstrapping with lots of inputs
Hi Guix! I've just managed to bootstrap the node-tape package using some of the helpers I introduced in 68941 (WIP). I want to use and reproduce the method I applied for phpunit in 67092, but it's a long method and I haven't had any input on it before now, so I'd like to at least validate the method before reproducing it. It consists in the following : - defining packages in an alphabetical order, in their final form (so using native-inputs that might not exist yet). - defining those potentially missing native inputs in a recursive way using package inheritance, by disabling tests and emptying native-inputs for all inputs. In the case of PHP, this only includes the PHPunit package, in patch 95 of 67092. In the case of node, I'll probably need to do that on several packages (tape, tap, typescript at least). There are some upsides compared to an approach where we explicitely define ...-bootstrap packages : - way less code - way more clarity about how the package is actually being bootstrapped. - we don't have to define packages twice, and that matters for PHP/Rust/JS where we have hundreds of packages for bootstrapping basic test native-inputs. But there are also big downsides : - stability in time : I don't have much worry due to centralization logic in PHP, not too much either for Rust, but in JS, bootstrapped packages for tape might gain typescript as an input, making regular headaches about how to bootstrap from there, if not using pinned versions. - computationally more intensive : updating a package could often mean rebuilding the whole bootstrap chain. This is also the case for unpinned inheriting ...-bootstrap packages. I've actually done a lot of bootstrapping with a more traditionnal approach with ...-bootstrap packages while working on the antioxidant/rust build-system and that is quite cumbersome. WDYT? Are there guidelines somewhere about how to do proper bootstrapping in these cases where hundreds of packages are involved? The actual inputs for PHPunit (patch 95 of 67092) : (inputs (letrec* ((package-list (list php-sebastian-version php-sebastian-type php-sebastian-cli-parser php-sebastian-recursion-context php-sebastian-resource-operations php-sebastian-object-enumerator php-sebastian-global-state php-sebastian-exporter php-sebastian-environment php-sebastian-diff php-sebastian-comparator php-sebastian-code-unit php-phpunit-php-timer php-phpunit-php-text-template php-phpunit-php-invoker php-phpunit-php-file-iterator php-phpunit-php-code-coverage php-phpspec-prophecy php-phar-io-version php-phar-io-manifest php-myclabs-deep-copy php-doctrine-instantiator)) (rewrite (lambda (p) (package (inherit p) (arguments '(#:tests? #f)) (native-inputs '()) (inputs (map (compose rewrite cadr) (package-inputs p))) (map rewrite package-list))) -- Best regards, Nicolas Graves
NPM packaging questions
Hi! I'm currently delving in the subject of node packaging, I have a few ideas that I might be interested in sending patches for, but I need some input before. 1) IIRC, most build-systems (except cargo at least) will not fail if some native-inputs are not present. They will fail if they are indeed necessary to build the package, but not by construction. This is not the case currently in the node-build-system. This forces us to use the delete-dependencies function very extensively, but there are a lot of cases (linters in a broad sense) where this is not necessary. Should we do like in other build-systems and add a step that would use this delete-dependencies function for all packages that are simply not node packages in inputs / native-inputs / propagated-inputs? Or sould we rather keep this explicit declaration with a need to probably also include it and a list of linters to ignore when generating a package with a potential importer? 2) Node tests will fail if there are no "test" script present. Based on the code in node-acorn, we can define a utility function that can at least check and filter-out a script in package.json. Based on this, we could avoid the need to manually enter #:tests? #f when tests are not present. 3) Likewise, the "prepare" step in an input is run in the configure phase from packages that use this input. This is probably never correct, since the input's output is fixed in the store. Using the same utility as in (2), we could add a step that would a) warn the user that a prepare step is being removed and output the content of this step. b) filter-out this step. These, and in particular (1) should make it more easy to tackle writing node packages until we can come up with a correct importer that could handle recursive import. I don't think introducing the binary importer in guix is a good idea since typescript and gulp have been successfully imported in guixrus. -- Best regards, Nicolas Graves
Re: Guix Days: Patch flow discussion
Hi Simon, On Thu, Feb 15 2024, Clément Lassieur wrote: > May I add too, that you can add "Message-ID" in gnus-visible-headers. The author of Debbugs.el, Michael Albinus, said this was likely the best solution. To request a feature in Debbugs.el, please file a bug against the "debbugs.gnu.org" package on debbugs.gnu.org. Thanks! Kind regards Felix
Re: Guix Days: Patch flow discussion
Hi Josselin, On Tue, Feb 13 2024, Josselin Poiret wrote: > As long as Debbugs is modifying mails on the MLs it's being > troublesome. Will you please show an example? You mentioned it before but I cannot find your message. Thanks! Kind regards Felix P.S. With a bug tracker, our discussion could be off-list. It would reduce the reading burden for folks who do not care about the topic.
(almost) deterministic patchsets
Hi ! I've written this (gpl3+) that should be able to fetch patchsets for both guix and rde. This should be robust enough for guix/rde use IMO. (define-module (guix mbox-download) #:use-module (guix packages) #:use-module ((guix self) #:select (make-config.scm)) #:use-module (guix modules) #:use-module (guix monads) #:use-module (gnu packages guile) #:use-module (gnu packages tls) #:use-module (gnu packages version-control) #:use-module (guix store) #:use-module (guix gexp) #:use-module (guix records) #:export (mbox-fetch mbox-reference)) (define-record-type* mbox-reference make-mbox-reference mbox-reference? (type mbox-reference-type) (id mbox-reference-id) (version mbox-reference-version)) (define* (mbox-fetch ref hash-algo hash #:optional name #:key (system %current-system) guile) (define uri (format #f (assoc-ref '((gnu . "https://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=~a;mbox=yes;) (rde . "https://lists.sr.ht/~~abcdw/rde-devel/patches/~a/mbox;)) (mbox-reference-type ref)) (mbox-reference-id ref))) (define modules (cons `((guix config) => ,(make-config.scm)) (delete '(guix config) (source-module-closure '((guix build download) (guix build utils)) (define build (with-extensions (list guile-json-4 guile-gnutls) (with-imported-modules modules #~(begin (use-modules (guix build utils) (guix build download)) (let ((mbox #$(match-record ref (type id version) (format #f "~a-~a-~a.mbx" type id version (setenv "TMPDIR" (getcwd)) (setenv "XDG_DATA_HOME" (getcwd)) (invoke #$(file-append b4 "/bin/b4") "-d" "-n" "--offline-mode" "--no-stdin" "am" "--no-cover" "--no-cache" "--use-local-mbox" (url-fetch #$uri "mbox" #:verify-certificate? #f) "--use-version" (number->string #$(mbox-reference-version ref)) "--no-add-trailers" "--outdir" "." "--mbox-name" mbox) (install-file mbox #$output)) (mlet %store-monad ((guile (package->derivation (or guile (default-guile)) system))) (gexp->derivation (or name (match-record ref (type id version) (format #f "~a-~a-~a-mbox" type id version))) build ;; Use environment variables and a fixed script name so ;; there's only one script in store for all the ;; downloads. #:system system #:local-build? #t ;don't offload repo cloning #:hash-algo hash-algo #:hash hash #:recursive? #t #:guile-for-build guile))) This can be used in such an example : (use-modules (guix mbox-download) (guix packages) (guix gexp) (guix monads) (guix store) (guix derivations)) (with-store store (run-with-store store (mlet* %store-monad ((drv (origin->derivation (pk 'o (origin (method mbox-fetch) (uri (mbox-reference (type 'rde) (id 44893) (version 4))) (sha256 (base32 "1rs09wxvdaxrk2zh6g23s9min76wjm9lw0a5pjklc7cfraasi7s9"))) (return drv Is guix interested in this, should I send a patch? What about renaming this to patchset-reference instead of mbox-reference? My end-goal here is to use this to extend channels to channels with patches, with something like this : (define* (instantiate-channel ch) (match ch ((name url ref patches) (primitive-eval `(channel (name ',name) ,@(if (null? patches) `((url ,(find-home url))) `((url ,(patched-source (symbol->string name) (git-checkout (url (find-home url)) (commit ref)) (search-patches patches) ,@(if ((@ (guix git) commit-id?) ref) `((commit ,ref)) `((branch ,ref))) (introduction ,(assoc-ref channels-introductions name))) in the hypothesis where patched-source is exported from (guix transformations). -- Best regards, Nicolas Graves
Re: Guix Days: Patch flow discussion
Hi Josselin, On Mon, Feb 12 2024, Josselin Poiret wrote: > 1) Doesn't modify any incoming mail; What if, in addition, Debbugs were to publish bug reports and their comments via public-inbox? > 2) Provides a way to look-up the bugs related to a thread and their > status, preferably using Message-ID What if those bug reports were available for your consumption via IMAP folders or NNTP news groups whose idenfier is the initial Message-Id? Kind regards Felix
Re: Guix Days: Patch flow discussion
Hi Clément, On Sun, Feb 11 2024, Clément Lassieur wrote: > On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU > System distribution." wrote: > > Each email has its own message id, so how would you group them? As author, I'll respond. I was thinking of the In-Reply-To: or the References: fields from RFC 2822. [1] Kind regards Felix [1] https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4
Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)
[unable to locate Romain's original message] Hi Josselin, On Sat, Feb 10 2024, Josselin Poiret wrote: > The idea would be to ... make sure that keyboard-layout-config appears > first in the generated config. I do not suffer from the issue described here but rewrote the bootloader code locally for more flexibility (and may be able to contribute it). Could we simply move the reference to keyboard-layout-config here up by a few lines? [1] On a side note, should issues like this be discussed in bugs on Debbugs/Mumi? Kind regards Felix [1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/bootloader/grub.scm#n515
Re: Guix Days: Patch flow discussion
Hi Josselin, On Wed, Feb 07 2024, Josselin Poiret wrote: > The fact that you have to wait for Debbugs's response after the first > mail to get the proper mail to reply to means that we can't automate > sending whole patchsets Could a modified version of Debbugs group submissions by Message-IDs instead of bug numbers? Would it allow subsequent emails to be sent before the initial message was acknowledged? Kind regards Felix
How to file Mumi bugs
Hi, An effort is under way to bring Mumi [1] and Debbugs [2] closer together. It's like a giant tongue twister! Bugs filed against Mumi are in the process of being re-assigned from 'guix' to the 'mumi' package in Debbugs. For the time being, those bugs may not show up in Mumi anymore, but only in Debbugs. They may appear in Mumi again in the future. Please continue to submit patches and bug reports intended for Guix the way you have. Those filings are not affected. For issues with Mumi or its command-line tool, however, please send bugs to sub...@debbugs.gnu.org with a first line that reads Package: mumi Filing instructions are also available here: https://debbugs.gnu.org/Reporting.html Please do not send Mumi bug reports to bug-g...@gnu.org anymore. For help, please reply narrowly to this message (i.e. pick a list). Thank you! Kind regards on behalf of the Debbugs and Mumi maintainers, Felix [1] https://debbugs.gnu.org [2] https://issues.guix.gnu.org [3] https://debbugs.gnu.org/Reporting.html
Re: Non-bootstrappable NPM packages
On 2019-07-24 15:41, Jelle Licht wrote: > Timothy Sample writes: > > [snip] > >> I’ve come to think that bootstrapping JavaScript might be easier than it >> looks. As time goes on, Node gets better at the newer JavaScript >> features. This removes the need for things like Babel or Rollup, since >> with some care, Node can run the source directly with out any >> transformations or bundling. That being said, TypeScript looks to be a >> major issue, as it is used in many fundamental JavaScript packages and >> it is not bootstrappable. > > Very recently (IE about 94 minutes ago), I found out something > interesting that might be helpful; Sucrase[0] is, among other things, a > typescript transpiler that does not do any type checking, and it only > has some runtime dependencies. > > I created some “fiio”-packages as well [1] , and I have confirmed that > it actually works! My next step was of course to compile TypeScript > proper, and this worked with one tiny snag that I reported at [2]. After > manually fixing these problems in the TypeScript source tree, I was able > to transpile the TypeScript sources using guix-packaged > `node-sucrase-bootstrap'. Hi Jelle! Did someone made some progress on the build-system since that to allow for this to be taken into account? If you still have it, could you share your "fiio" packages once again? The paste link is expired. Thanks! > >> I’m not sure in what capacity I want to pursue this. It’s been sitting >> dormant on my computer for while, so I thought sharing it would be >> better than letting it fall by the wayside. I hope it proves useful one >> way or another. >> >> If you got this far, thanks for reading! :) > Thank you for sending this informative email :) >> >> >> -- Tim > > [0]: https://github.com/alangpierce/sucrase > [1]: https://paste.debian.net/1092893/ > [2]: https://github.com/alangpierce/sucrase/issues/464 -- Best regards, Nicolas Graves
Debbugs update (Was: Guix Days: Patch flow discussion)
Hi Hartmut & Josselin, On Mon, Feb 05 2024, Hartmut Goebel wrote: > Am 05.02.24 um 10:39 schrieb Steve George: > > [order of quotations reversed] > > The current mail-based workflow is too complicated ... which has been > discussed several times already without any result: Well, that's not totally true. After hearing the plight last year, I offered the FSF to assume responsibility for debbugs.gnu.org. [1] I also packaged and deployed on GNU Guix (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4] (B) the modern Debbugs version deployed at debian.org [5][6][7] (C) and a custom version of Mumi for my own bug fixes [8][9] Together with the official debbugs.gnu.org, which runs on Debian 8, and issues.guix.gnu.org, I am now working to fold all five deployments into one. On Tue, Feb 06 2024, Josselin Poiret wrote: > One thing I would like to get rid of though is debbugs. I can do little to appease the hardcore Debbugs haters, but I have a vision for a bug tracking system that, written in GNU Guile, will attract less wholesale criticism and more constructive contributions from from the Emacs and Guix communities, which are the primary users of debbugs.gnu.org. Both groups are already in love with the lambda calculus. Mumi made great steps in that direction but has so far not attracted the contributions it deserves. In another piece of the puzzle, Michael Albinus wrote and maintains an excellent Emacs package called Debbugs.el. It allows bug work to take place in Gnus and Org Modes [10] rather than in a web browser. With that package, Emacs could become a favorite way to work on our bugs and patches, similar to what Magit did for Git. At Guix, folks also do not use Debbugs to its full potential. Git hooks are an example. Mumi obscures some features. I know because I worked on Debian's bugs for many years. I am committed to Debbugs because I'm not sure interactions between people can be audited properly on modern development forges. For many years, I worked with Salsa, Debian's Gitlab instance. While convenient, it was difficult to find past conversations and code snippets, although like Josselin I'm watching what the kernel folks are doing. The databases in forges are also complicated to maintain. Plus, projects experience immediate vendor lock in. My primary hurdle with modernizing Debbugs, if anyone cares, is that the FSF is reluctant to deploy GNU Guix. They insist on Trisquel plus Ansible [11] which is what they have been using for some time. Thank you, everyone, for your hard work on GNU Guix! Kind regards Felix [1] https://lists.nongnu.org/archive/html/help-debbugs/2023-10/msg3.html [2] https://debbugs.juix.org/cgi/bugreport.cgi?bug=66703 [3] https://codeberg.org/lechner/juix/src/commit/5fffdb0053b18b4b28adadbbebb79a1d9bfe2337/juix/deploy/debbugs.scm#L1046-L1184 [4] https://codeberg.org/lechner/debbugs-gnu [5] https://better.juix.org/cgi/bugreport.cgi?bug=66703 [6] https://codeberg.org/lechner/juix/src/commit/5fffdb0053b18b4b28adadbbebb79a1d9bfe2337/juix/deploy/debbugs.scm#L1186-L1364 [7] https://salsa.debian.org/debbugs-team/debbugs [8] https://mumi.juix.org/66703 [9] https://codeberg.org/lechner/mumi [10] https://elpa.gnu.org/packages/doc/debbugs-ug.html [11] https://lists.nongnu.org/archive/html/help-debbugs/2024-01/msg00049.html
Re: Guix Days: Patch flow discussion
Hi Suhail, On Mon, Feb 05 2024, suh...@bayesians.ca wrote: > Felix Lechner via writes: > > Is your position that First off, I'm sorry I write so much today. For a project the size of Guix, it's not good for one person to belabor a point repeatedly. I am responding to your request for a clarification. > 1. this never happens today and thus, should happen some times when >warranted. Or that, > > 2. it happens far too rarely today, and should happen more often. Or >that, > > 3. committers should never ask for revisions? None of the above. I believe committers should commit only changes they are comfortable with. Otherwise, they should leave a bug to folks with more experience, perhaps tagging it along the way. I think there should be a hundred people who do nothing but add new packages. They would free up valuable capacity for the people experienced with build systems, Guix services and their configuration, the user interface, the daemon, cross-compilation and other more difficult speciality areas. Kind regards Felix
Re: Guix Days: Patch flow discussion
On Mon, Feb 05 2024, Clément Lassieur wrote: > On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU > System distribution." wrote: > > I see no evidence here. And I'm unsure which plan you are talking > about (the plan?). Two people can look at the same thing and reach different conclusions. I see no evidence that large numbers of non-committers are eager to review patches. > What do you mean with "bottom"? I'm sorry to put words into your mouth. I meant to quote an executive at a bank who explained that strategy to me. The word "bottom" was his and should have been a quote. The executive referred to people without the authority to act on behalf of the group. I believe Guix would be better off to delegate responsibility (rather than competency) by handing out commit access more generously but imposing limits as to the type of changes a person may make. The honor system will work fine. > Reviewing != Closing Maybe they should be the same. Two people looking at a patch (submitter and committer) are more efficient than three people, i.e. a submitter, a reviewer, and a committer. It's one of several bottlenecks at Guix. Another is that committers should commit what they think is right rather than ask for revised patches. Please give authorship to the submitter. Kind regards Felix
Re: Guix Days: Patch flow discussion
Hi Clément, On Mon, Feb 05 2024, Clément Lassieur wrote: > I don't think reviewers have to be committers. How much more evidence does the project need to see in order to realize that the plan is not working? I'll spare the list a lengthy analysis of the social dynamics but the delegation of competency to the bottom is an unsuccessful practice in many places. Maintainers must close bugs in service to the public. There is no other way. Kind regards Felix
TODO Delete branch snapper.
The snapper branch is here with no activity for quite some time. There's a patch for snapper in 57311, maybe we can start by deleting the branch. -- Best regards, Nicolas Graves
Re: Issues with issues.guix.gnu.org (502 Bad Gateway)
Hi Christina, On Sat, Feb 03 2024, Christina O'Donnell wrote: > connecting to https://issues.guix.gnu.org/ results in ... a 502 bad > gateway. You are welcome to use my Mumi clone at mumi.juix.org. Kind regards Felix
Introducing Guix "Features"! (Was: Syntactic Diabetes)
On Thu, Nov 30 2023, Attila Lendvai wrote: > the use of 'service' to describe two rather different abstractions: a > component of an OS vs. a deamon process run by shepherd. Indeed, the use of 'service' in much of Guix appears to be a grand misnomer. It probably occurred because the meaning expanded over time. It's like we are looking back in time at the Big Bang. Our "services" are the microwave echoes of Guix's initial, creative spark! Please consider a recent, helpful reply to help-guix. [1] Carlo mentioned the term "service" eleven times, but none of them referred to what I believe most readers of this message would call a service in other contexts. What's a newbie on help-guix to think? Should Guix services instead be called "features"? Those "features" are central to any operating system definition. Other choices like "provider" may not fully capture our collective uses throughout the code and the documentation. I am especially thinking about 'modify-features' and '%base-features'. Kind regards Felix [1] https://lists.gnu.org/archive/html/help-guix/2024-01/msg00213.html
Eudev in gnome-team [Was: Core-updates coordination and plans]
Hi Vivien, > The eudev package has been touched on gnome-team I reviewed the patches but do not believe they solve Bug#63508 or Bug#63787. That issue, stated succinctly, arises because configure.ac sets the Makefile variable $(udevrulesdir) to the store output [1] while custom rules like mine [2] live in the global folder /etc/udev/rules.d. After some analysis, the upstream sources are best patched here. [3] A explanation for why the flags to ./configure are ineffective can be found here. [4] > Could you try and rebase your work on gnome-team, to see whether it > works? Unfortunately, that rebuild takes two days on my system. Absent an insight that your patches will fix the bug, it is too much effort. Kind regards Felix [1] https://github.com/eudev-project/eudev/blob/611b6fbae2cca9ceeacb820befb3a0e8caec88b8/configure.ac#L180 [2] https://codeberg.org/lechner/system-config/src/commit/a6962d1414d11040072f0e79ffde354fa523137a/service/udev-rules-net-name-mac.scm#L4-L9 [3] https://github.com/eudev-project/eudev/blob/611b6fbae2cca9ceeacb820befb3a0e8caec88b8/src/udev/Makefile.am#L10 [4] https://issues.guix.gnu.org/63508#26
Re: Core-updates coordination and plans
Hi Josselin,
On Wed, Jan 31 2024, Josselin Poiret wrote:
> One conundrum we have for now: glibc 2.38 has a couple of new CVEs
The authors describe CVE-2023-6246, which is probably the most serious
of the four vulnerabilities, as "significant" [1] and Red Bat ranks it
as "8.4 (HIGH)" under the new CVD scale. [2]
Most important, "This flaw allows local privilege escalation, enabling
an unprivileged user to gain full root access, as demonstrated in Fedora
38." [again, 1]
> we have three options:
> 1) change glibc to track the 2.38 release branch → world rebuild.
> 2) graft glibc → bad user experience (and we're not supposed to graft
> outside of master).
> 3) switch to 2.39 → world rebuild + possibly more work fixing new build
> failures.
Personally, I would go straight to Glibc 2.39.
I am not sure it's helpful to obsess about "world rebuilds." The fear
and cost of rebuilding in Guix is real, but it is a necessary
consequence of the way Guix works. The fear is also a dominant and
persistent mental obstacle to making Guix better. [3]
> I'd ideally prefer 3 but we don't know yet if there is going to be a
> lot of breakage
Your argument that more work may be needed is well-placed, however.. We
won't know until we get there. Perhaps we can revert to version 2.38
prior to your merge if the problems are severe.
> glibc 2.39 should hopefully release tomorrow (01/02/2024)
Fortunately, your merge schedule conincides more or less with Glib's
release cycle. There should be plenty of data from around the world
about the new Glibc version's performance in two or three weeks.
> most of the patches ... got pushed, are there any other ... ?
I don't know whether eudev is a core-package but I personally find it
irresponsible that my patch to fix the use of MAC-based addresses for
network interfaces [4][5] has not been accepted in some form.
In a functional OS like Guix, no administrator should rely on device
enumerations provided by the BIOS, by UEFI or by the Linux kernel. The
fix is a one-liner. [6]
I used 'regexp-quote' to avoid Guile's quoting madness. [7] As an
alternative, we could quote the literals with the old Perl::Critic trick
that avoids escapes for metacharacters: [8]
(substitute* "src/udev/Makefile.am"
(("[$][(]udevrulesdir[)]") "/etc/udev/rules.d"))
Either way, I'd appreciate if Eudev could please be fixed in this
core-updates cycle. The fix has been available for more than half a
year.
The fix was furthermore deployed on all my systems, including the one
running the test deployment of Debbugs in Guix, which is available at
debbugs.juix.org. The fix works. Thanks!
Kind regards
Felix
[1]
https://blog.qualys.com/vulnerabilities-threat-research/2024/01/30/qualys-tru-discovers-important-vulnerabilities-in-gnu-c-librarys-syslog
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-6246
[3] https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00243.html
[4] https://issues.guix.gnu.org/63508
[5] https://issues.guix.gnu.org/63787
[6] https://issues.guix.gnu.org/63508#12-lineno51
[7] https://www.gnu.org/software/guile/manual/html_node/Backslash-Escapes.html
[8]
https://metacpan.org/pod/Perl::Critic::Policy::RegularExpressions::ProhibitEscapedMetacharacters
Re: [PATCH v2 0/4] Make certbot play more nicely with nginx
I sympathize with your approach (I, too, have been supplementing Certbot with self-signed certs for some time). What would also be cool is not to have `certbot-service-type` depend on `nginx-service-type` in the first place. So that one can more easily use another HTTP server. It can of course be achieved with `remove-service-extensions` from `(gnu services)`, it's just less elegant than having it supported directly. Perhaps some variant of the "dependency inversion principle" would fit here? How about the following set of service types? - certbot-tool-service-type — does what `certbot-service-type` used to do until now except it doesn't extend `nginx-service-type` and can itself be extended with not just ``s but also `` - certbot/nginx-service-type — takes in ``, extends both `certbot-tool-service-type` and `nginx-service-type` - certbot/httpd-service-type — takes in ``, extends both `certbot-tool-service-type` and `httpd-service-type` - certbot-service-type — deprecated, functions as an alias for `certbot/nginx-service-type` Your proposals are of course useful as well, regardless of this being done Best :) Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Wed, 31 Jan 2024 08:48:54 +1100 Carlo Zancanaro wrote: > Hi Felix, > > On Tue, Jan 30 2024, Felix Lechner wrote: > > On Tue, Jan 30 2024, Carlo Zancanaro wrote: > >> certbot can't produce certificates without a functional nginx > > > > Yes, it can. The option is called --standalone. [1] > > You are correct, of course. If I had been more precise I would > have said "with our current configuration, certbot can't produce > certificates without a functional nginx". > > > Maybe another way to bootstrap the certificates would be to hold > > off on starting Nginx or Apache until all certificates are > > obtained? > > This could work, but I see a few downsides. > > As Clément has already mentioned, this would make nginx dependent > on certbot. This causes problems for servers disconnected from the > general internet, but it also shifts complexity into the nginx > service without much benefit over the patch series I'm proposing. > We'd need to add more configuration on the nginx side to control > whether to delay startup based on whether we actually want > certificates. This would delay the startup of the whole nginx > process, even if some server configurations don't require new > certificates. > > For renewal, we would also have two options: (1) use --standalone, > and require a period of downtime for our web server; or (2) use > --webroot, and maintain two code paths for the two cases. I think > it's a bad idea for Guix to make a decision that requires downtime > of user systems if there's an alternative, so I don't like (1). > Maintaining two "similar but different" code paths for (2) doesn't > seem like a clear advantage over the patch series I'm proposing. > > > Anyway, that's what I do manually. > > I use the DNS challenge type, with hooks which automatically > create/remove DNS records. This solves all the problems I'm > bringing up (i.e. doesn't require nginx, doesn't involve downtime, > has a single code path), but I don't think Guix can assume that > all users have the ability to do this. My aim with this patch > series is to make the default certbot configuration work for the > common case of a simple web server, without manual intervention. > > Carlo > pgpSZ531cwTun.pgp Description: OpenPGP digital signature
Re: [PATCH v2 0/4] Make certbot play more nicely with nginx
Hi Carlo, On Tue, Jan 30 2024, Carlo Zancanaro wrote: > certbot can't produce certificates without a functional nginx Yes, it can. The option is called --standalone. [1] Maybe another way to bootstrap the certificates would be to hold off on starting Nginx or Apache until all certificates are obtained? Anyway, that's what I do manually. Kind regards Felix [1] https://eff-certbot.readthedocs.io/en/latest/using.html#standalone
Re: Git-LFS or Git Annex?
On 2024-01-28 18:32, Giovanni Biscuolo wrote: > Hi Nicolas, > > Nicolas Graves writes: > > [...] > >> This is not always true. Git-LFS also has the concept of Custom Transfer >> Agents, which in some cases do not need a running server. One example is >> lfs-folderstore, which can simply use a remote directory as a LFS >> remote. > > thanks, i didn't know about custom transfer agents, the use withous an > API server is documented here: > > --8<---cut here---start->8--- > > In some cases the transfer agent can figure out by itself how and where > the transfers should be made, without having to query the API server. In > this case it's possible to use the custom transfer agent directly, > without querying the server, by using the following config option: > > lfs.standalonetransferagent, lfs..standalonetransferagent > > Specifies a custom transfer agent to be used if the API server URL > matches as in "git config --get-urlmatch lfs.standalonetransferagent > ". git-lfs will not contact the API server. It instead sets > stage 2 transfer actions to null. "lfs..standalonetransferagent" > can be used to configure a custom transfer agent for individual > remotes. "lfs.standalonetransferagent" unconditionally configures a > custom transfer agent for all remotes. The custom transfer agent must be > specified in a "lfs.customtransfer." settings group. > > --8<---cut here---end--->8--- > (https://github.com/git-lfs/git-lfs/blob/main/docs/custom-transfers.md#using-a-custom-transfer-type-without-the-api-server) > > some examples: > > 1. git-lfs-agent-scp: A custom transfer agent for git-lfs that uses scp >to transfer files. This transfer agent makes it possible to use >git-lfs in situations where the remote only speaks ssh. This is >useful if you do not want to install a git-lfs server. (MIT license, >written in C, URL: https://github.com/tdons/git-lfs-agent-scp) > > 2. git-lfs-rsync-agent: The rsync git-lfs custom transfer agent allows >transferring the data through rsync, for example using SSH >authentication. (MIT license, written in Go, URL: >https://github.com/excavador/git-lfs-rsync-agent) > > 3. git-lfs-agent-scp-bash: A custom transfer agent for git-lfs that uses >scp to transfer files. This is a self-contained bash script designed >for seamless installation, requiring no prerequisites with the >exception of the external command scp. It enables to use git-lfs even >if you can not use http/https but ssh only. (MIT License, written in >bash, URL: https://github.com/yoshimoto/git-lfs-agent-scp-bash) > > So yes: we could use git-lfs without a git-lfs server and set an rsync > or scp transfer agent for each remote (documenting it for users, since > this must be done client-side) > > It's not at all as powerful as the location tracking features of > git-annex but... doable :-) One downside however : For some reason, Custom Transfer Agents are rarely well written, well supported projects. I had to write one myself for my use-case, I now have a good understanding of the protocol which is definitely simple, but it's a necessary thing to note that despite this rather easy extensibility, few CTAs are good/reliable in the long run. > > [...] > >>> Another important limitation of Git-LFS is that you cannot delete >>> (remotely stored) objects [1], with git-annex is very easy. >> >> Probably true, haven't encountered the use-case yet. > > IMHO this is a very important feature when you have to manage media > archives. Depends on the use-case! If you're just looking for an archival tool of a media with one unmutable version which you want to support for an indefinite amount of time, doesn't matter that much. Gitlab and Github documentation say it's possible with the git-filter-repo extension, but that is indeed not easy. https://docs.gitlab.com/ee/topics/git/lfs/#removing-objects-from-lfs > > [...] > >> Just a note on upsides of Git-LFS : >> - integration with git is better. A special magit extension to use >> git-lfs is not needed, whereas it is with git-annex. > > true :-D > >> - less operations: once I know which files will be my media files, I >> have less headaches (basically the exact git experience, you don't have >> to think about where I should `git add` or `git annex add` a file). > > it's the same with git-annex, you just have to configure/distribute a > .gitattributes file, i.e.: > > --8<---cut here---start->8--- > > * annex.largefiles=(largerthan=5Mb) > * annex.largefiles=(not(mimetype=text/*)) > > --8<---cut here---end--->8--- > > see https://git-annex.branchable.com/tips/largefiles/ for a description > of this feature Nice! I haven't experimented with this. Funny how it's one extension of a git extension that provides what LFS does natively. > >> It's indeed less copyleft though. Simpler, but also maybe less
Re: Git-LFS or Git Annex?
I've left git-annex for git-lfs, I'll just add a few points about git-lfs. On 2024-01-24 18:39, Giovanni Biscuolo wrote: > Hi Ludo’ > > Ludovic Courtès writes: > > [...] > >> The question boils down to: Git-LFS or Git Annex? >> >> From a quick look (I haven’t used them), Git-LFS seems to assume a >> rather centralized model where there’s an LFS server sitting next to the >> Git server¹. Git Annex looks more decentralized, allowing you to have >> several “remotes”, to check the status of each one, to sync them, etc.² >> Because of this, Git Annex seems to be a better fit. This is not always true. Git-LFS also has the concept of Custom Transfer Agents, which in some cases do not need a running server. One example is lfs-folderstore, which can simply use a remote directory as a LFS remote. > > I've never used Git-LFS for my media repository (and will never use it, > never). > > AFAIK this two advantages of git-annex vs Git-LFS are still valid today: > > --8<---cut here---start->8--- > > A major advantage of git annex is that you can choose which file you > want to download. > > You still know which files are available thanks to the symlinks. > > For example suppose that you have a directory full of ISO files. You can > list the files, then decide which one you want to download by typing: > git annex get my_file. This is true, but 1) you can still adapt your filters to ignore certain files, although more inconvenient, it's not impossible 2) in practice, I think most uses don't need to. I just now that all .lz files in a directory are to LFS, no questions asked. > > Another advantage is that the files are not duplicated in your > checkout. With LFS, lfs files are present as git objects both in > .git/lfs/objects and in your working repository. So If you have 20 GB of > LFS files, you need 40 GB on your disk. While with git annex, files are > symlinked so in this case only 20 GB is required. True. > > --8<---cut here---end--->8--- > (https://stackoverflow.com/a/43277071, 2018-10-23) > > So, AFAIU, with Git-LFS you can have all your media or no media, you > cannot selectively choose what media to get. > > Another important limitation of Git-LFS is that you cannot delete > (remotely stored) objects [1], with git-annex is very easy. Probably true, haven't encountered the use-case yet. > >> Data point: guix.gnu.org source is hosted on Savannah, which doesn’t >> support Git-LFS; > > to host a Git-LFS service a Git-LFS server implementation (one that > reply to GIT_LFS API) is needed: > https://github.com/git-lfs/git-lfs/wiki/Implementations See my point on custom transfer agents. > > AFAIU we dont't have one packaged (I'd save some precious time trying to > package one of them). > > AFAIK Savannah do not support git-annex also, so we need to set up a > Guix git-annex server [3], I suggest using gitolite [4]: I can help with > this task if needed! > >> the two other web sites above are hosted on GitLab instances, which I >> think do support Git-LFS. > > Yes, Git-LFS is supported on GitLab.com and included in the Community > Edition [2] since late 2015. > > git-annex repository support was available on GitLab.com in 2015/16 but > was removed in 2017 [5] > >> What’s your experience? What would you suggest? > > I've no experience with Git-LFS (and will never have) but from what I > read I definitely suggest git-annex: it's more efficient, it's more > flexible, can be hosted everywhere with a little bit of effort... can be > hosted on a Guix System host! :-) > > As a bonus, git-annex have a plenty of super cool features that will > make us very happy, i.e.: > > - special remotes: https://git-annex.branchable.com/special_remotes/ > (including rclone > https://git-annex.branchable.com/special_remotes/rclone/) > > - location tracking > (https://git-annex.branchable.com/location_tracking/) > > - manage metadata of annexed files > > HTH! Gio' Just a note on upsides of Git-LFS : - integration with git is better. A special magit extension to use git-lfs is not needed, whereas it is with git-annex. - less operations: once I know which files will be my media files, I have less headaches (basically the exact git experience, you don't have to think about where I should `git add` or `git annex add` a file). It's indeed less copyleft though. Simpler, but also maybe less adapted to this use-case. > >> Thanks, >> Ludo’. >> >> ⁰ >> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n193 >> ¹ https://github.com/git-lfs/git-lfs/wiki/Tutorial >> ² https://git-annex.branchable.com/walkthrough/ > > > [1] https://github.com/git-lfs/git-lfs/wiki/Limitations > > [2] GitLab Community Edition > > [3] > https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/ > > [4] https://git-annex.branchable.com/tips/using_gitolite_with_git-annex/ > > [5] >
Re: SSH key management for Guix cloud machines
Hi Fabio, On Fri, Jan 19 2024, Fabio Natali wrote: > How does the publishing happen exactly You can query SSH server keys remotely [1] but I would deploy keys I know already. Kind regards Felix [1] https://serverfault.com/a/1033095
Re: December/January update on QA and related things
Hi Chris, On Sat, Jan 20 2024, Christopher Baines wrote: > I hopefully mitigated the port encoding issue [3] by switching from > using the display procedure to log to using string->utf8 and > put-bytevector. > > [...] > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62590 Could the error be due to the 7-bit encoding in HTTP headers? [1] The "84" is EILSEQ from errno.h. [2] Wingo added the functionality here. [3] I left that comment in your bug, and in Bug#59510. [4] I also submitted a patch to resolve the errno in the future. [5] Then I wrote here in case anyone sees the error again. Thank you for your hard work on the Guix infrastructure! Your generous contributions serve as inspirations to many. Kind regards Felix [1] https://lists.gnu.org/archive/html/guile-user/2020-09/msg00015.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/errno.h#n67 [3] https://git.savannah.gnu.org/cgit/guile.git/commit/?id=43b6feeb1adafe54170304e7cc3c29a15c1d3808 [4] https://issues.guix.gnu.org/59510 [5] https://debbugs.gnu.org/68624
Re: SSH key management for Guix cloud machines
Hi Fabio, On Fri, Jan 19 2024, Fabio Natali wrote: > Is there any mechanism that would allow to access the server without > having to trust-on-first-use the server's fingerprint? I publish my server-side keys via SSHFP records in a domain secured by DNSSEC. When I add 'VerifyHostKeyDNS yes' to the client configuration file, there is no prompt. [1] Kind regards Felix [1] https://aye.sh/blog/sshfp-verification
Re: Helping with abandoned patches
On Wed, Jan 17 2024, Greg Hogan wrote: > Is it appropriate to make the recommended changes and submit an > updated patch? Yes, absolutely! Kind regards Felix
Re: Guix CLI, thoughts and suggestions
Hi Ian, On Mon, Jan 15 2024, Ian Eure wrote: > What do you all think? The pain is not yet great enough to make changes. Also, the interface may have more basic issues. [1] Kind regards Felix [1] https://issues.guix.gnu.org/58908
Re: When is check-system run?
Hi Tomas, On Fri, Jan 12 2024, Tomas Volf wrote: > it seems like at least some of them are broken. Can someone check > whether that is case even on their machine? Yes, some are broken. > Do they all pass for you? No. > when exactly are the those tests run and where are the failures > reported to? I believe they run before 'guix pull' is finalized, but I cannot point to how they are invoked. So far I have written four of them. (Cachefilesd should pass; the other three are pending and have not been accepted yet.) Sorry, that's all I have. Kind regards Felix
Module unavailable on build side
Hi, How may I make code from a channel available inside 'modify-phases', please? I tried #:modules, but it says "no code for (x y z)." Thanks! Kind regards Felix
Re: [PATCH 00/48] Extend bag-build to gexps.
Here's a more complete proof of concept: The attached file guix.scm, when run a checkout of emacs branch emacs-29 with guix build -f guix.scm will : - compile everything as if run locally but with the patches provided by guix sources. - a local edit and the rerun of guix build -f guix.scm will only compile new / changed code. Now I can try developping emacs without worring about huge compilation times and without the developping issues that would happen if I ran the build-system by hand without the patches. We could even imagine adding an option to guix shell -D that could drop such a file for any package, since most of the code is reproducible (although applying a derivation this way is still quite hacky). guix.scm Description: Binary data Cheers! Nicolas On 2024-01-08 08:51, Nicolas Graves wrote: > Rationale: > Almost all build-systems are defined with gexpressions in functions > that return derivations. Derivations are not easily extensible while > gexps are. An example usage is given below. > > This is a pretty big rewrite that should recompile almost all packages, > but a lot of grafting happens such as I could rebuild my system quickly. > > I was trying to get the build-phases of an existing package to apply to > a local repository, because guix as a development tool for heavy packages > (emacs, ungoogled-chromium) is tedious, and there are precious info in > build-phases that can be applied in a local repository. I'm not aware of > prior work on this particular issue. > > These patches allow to do extensions such as: > > (build-system > (name 'local-gnu) > (description "GNU Build System applied in the current directory") > (lower >(lambda* args > (let ((old-bag (apply > (build-system-lower > (package-build-system emacs-pgtk)) > args))) >(bag > (inherit old-bag) > (build > (lambda* build-args > (mlet %store-monad > ((builder (apply (bag-build old-bag) build-args))) > (return (with-imported-modules '((guix build utils)) > #~(begin > (use-modules (guix build utils)) > (with-directory-excursion #$(getcwd) > #$builder > > Of course this type of build-system isn't directly applicable because of > the chroot of the builder, but this other trick makes it happen : > > ;; We can't use package->derivation directly because we want the user rather > ;; than the daemon to build the derivation. > (with-store store > (run-with-store store > (mlet* %store-monad ((bag -> (package->bag pkg)) >(drv(bag->derivation bag pkg))) > ;; ensure inputs are in the store. > (built-derivations (derivation-inputs drv)) > (with-environment-excursion > (apply invoke (derivation-builder (pk 'd drv)) > (derivation-builder-arguments drv)) > > This isn't polished yet, but could serve as an handy way to develop > heavy packages locally while taking advantage of the code that's > already in guix build phases. > > > Nicolas Graves (48): > guix: packages: Extend bag-build to support gexp. > build-system: gnu: Improve gnu-cross-build style. > build-system: gnu: Redefine gnu-build and gnu-cross-build. > build-system: agda: Redefine agda-build. > build-system: android-ndk: Redefine gnu-build. > build-system: ant: Redefine ant-build. > build-system: asdf: Redefine asdf-build. > build-system: cargo: Redefine cargo-build and cargo-cross-build. > build-system: chicken: Redefine chicken-build. > build-system: clojure: Redefine clojure-build. > build-system: cmake: Redefine cmake-build and cmake-cross-build. > build-system: composer: Redefine composer-build. > build-system: copy: Redefine copy-build. > build-system: dub: Redefine dub-build. > build-system: dune: Redefine dune-build. > build-system: elm: Redefine elm-build. > build-system: emacs: Redefine emacs-build. > build-system: font: Redefine font-build. > build-system: glib-or-gtk: Improve glib-or-gtk-cross-build style. > build-system: glib-or-gtk: Redefine glib-or-gtk-build functions. > build-system: go: Redefine go-build and go-cross-build. > build-system: guile: Redefine guile-build and guile-cross-build. > build-system: haskell: Redefine haskell-build. > build-system: julia: Redefine julia-build. > build-system: linux-module: Redefine linux-module-build functions. > build-system: maven: Redefine maven-build. > build-system: meson: Redefine meson-build and meson-cross-build. > build-system: minify: Redefine minify-build. > build-system: mix: Redefine mix-build. > build-system: node:
Re: How/where/when to ask for a patch review?
Hi Ludo' On Wed, Jan 10 2024, Ludovic Courtès wrote: > I have to admit I have a hard time keeping up. You work too hard! Jethro the Midianite high priest [1] liked to focus on the "grand design": https://www.youtube.com/watch?v=oG0a9WFkgzU More practically, Jethro said: (13) It came about on the next day that Moses sat down to judge the people, and the people stood before Moses from the morning until the evening. When Moses' father in law saw what he was doing to the people, he said, "What is this thing that you are doing to the people? Why do you sit by yourself, while all the people stand before you from morning till evening?" Moses said to his father in law, "For the people come to me to seek God. If any of them has a case, he comes to me, and I judge between a man and his neighbor, and I make known the statutes of God and His teachings." Moses' father in law said to him, "The thing you are doing is not good. You will surely wear yourself out both you and these people who are with you for the matter is too heavy for you; you cannot do it alone. Now listen to me. I will advise you, and may the Lord be with you. [You] represent the people before God, and you shall bring the matters to God. And you shall admonish them concerning the statutes and the teachings, and you shall make known to them the way they shall go and the deed[s] they shall do. But you shall choose out of the entire nation men of substance, God fearers, men of truth, who hate monetary gain, and you shall appoint over them [Israel] leaders over thousands, leaders over hundreds, leaders over fifties, and leaders over tens. And they shall judge the people at all times, and it shall be that any major matter they shall bring to you, and they themselves shall judge every minor matter, thereby making it easier for you, and they shall bear [the burden] with you. If you do this thing, and the Lord commands you, you will be able to survive, and also, all this people will come upon their place in peace." Moses obeyed his father in law, and he did all that he said. Moses chose men of substance out of all Israel and appointed them as heads of the people, leaders of thousands, leaders of hundreds, leaders of fifties, and leaders of tens. And they would judge the people at all times; the difficult case they would bring to Moses, but any minor case they themselves would judge. [1] Kind regards Felix [1] https://www.chabad.org/library/bible_cdo/aid/9879/jewish/Chapter-18.htm#v13
OpenSMTPd and the "smuggling" attack
Hi, Due to the popularity of OpenSMTPd here, I thought the group might appreciate that MTA is not affected by the "SMTP smuggling" attack [1] like the other mail servers. [2] According to #opensmtpd, our MTA does not support pipelining and is therefore not vulnerable. Some additional patches for hardening are being tested but they do not currently play nice with all others.[3] Kind regards Felix [1] https://marc.info/?l=oss-security=170316959409269=2 [2] https://marc.info/?l=oss-security=170341041116636=2 [3] https://marc.info/?l=openbsd-tech=170306668710940=2
[PATCH 00/48] Extend bag-build to gexps.
Rationale: Almost all build-systems are defined with gexpressions in functions that return derivations. Derivations are not easily extensible while gexps are. An example usage is given below. This is a pretty big rewrite that should recompile almost all packages, but a lot of grafting happens such as I could rebuild my system quickly. I was trying to get the build-phases of an existing package to apply to a local repository, because guix as a development tool for heavy packages (emacs, ungoogled-chromium) is tedious, and there are precious info in build-phases that can be applied in a local repository. I'm not aware of prior work on this particular issue. These patches allow to do extensions such as: (build-system (name 'local-gnu) (description "GNU Build System applied in the current directory") (lower (lambda* args (let ((old-bag (apply (build-system-lower (package-build-system emacs-pgtk)) args))) (bag (inherit old-bag) (build (lambda* build-args (mlet %store-monad ((builder (apply (bag-build old-bag) build-args))) (return (with-imported-modules '((guix build utils)) #~(begin (use-modules (guix build utils)) (with-directory-excursion #$(getcwd) #$builder Of course this type of build-system isn't directly applicable because of the chroot of the builder, but this other trick makes it happen : ;; We can't use package->derivation directly because we want the user rather ;; than the daemon to build the derivation. (with-store store (run-with-store store (mlet* %store-monad ((bag -> (package->bag pkg)) (drv(bag->derivation bag pkg))) ;; ensure inputs are in the store. (built-derivations (derivation-inputs drv)) (with-environment-excursion (apply invoke (derivation-builder (pk 'd drv)) (derivation-builder-arguments drv)) This isn't polished yet, but could serve as an handy way to develop heavy packages locally while taking advantage of the code that's already in guix build phases. Nicolas Graves (48): guix: packages: Extend bag-build to support gexp. build-system: gnu: Improve gnu-cross-build style. build-system: gnu: Redefine gnu-build and gnu-cross-build. build-system: agda: Redefine agda-build. build-system: android-ndk: Redefine gnu-build. build-system: ant: Redefine ant-build. build-system: asdf: Redefine asdf-build. build-system: cargo: Redefine cargo-build and cargo-cross-build. build-system: chicken: Redefine chicken-build. build-system: clojure: Redefine clojure-build. build-system: cmake: Redefine cmake-build and cmake-cross-build. build-system: composer: Redefine composer-build. build-system: copy: Redefine copy-build. build-system: dub: Redefine dub-build. build-system: dune: Redefine dune-build. build-system: elm: Redefine elm-build. build-system: emacs: Redefine emacs-build. build-system: font: Redefine font-build. build-system: glib-or-gtk: Improve glib-or-gtk-cross-build style. build-system: glib-or-gtk: Redefine glib-or-gtk-build functions. build-system: go: Redefine go-build and go-cross-build. build-system: guile: Redefine guile-build and guile-cross-build. build-system: haskell: Redefine haskell-build. build-system: julia: Redefine julia-build. build-system: linux-module: Redefine linux-module-build functions. build-system: maven: Redefine maven-build. build-system: meson: Redefine meson-build and meson-cross-build. build-system: minify: Redefine minify-build. build-system: mix: Redefine mix-build. build-system: node: Redefine node-build. build-system: ocaml: Redefine ocaml-build. build-system: perl: Redefine perl-build and perl-cross-build. build-system: pyproject: Redefine pyproject-build. build-system: python: Redefine python-build. build-system: qt: Redefine qt-build and qt-cross-build. build-system: r: Redefine r-build. build-system: rakudo: Redefine rakudo-build. build-system: rebar: Redefine rebar-build. build-system: renpy: Redefine renpy-build. build-system: ruby: Improve ruby-cross-build style. build-system: ruby: Redefine ruby-build. build-system: scons: Redefine scons-build. build-system: texlive: Redefine texlive-build. build-system: tree-sitter: Redefine tree-sitter-build functions. build-system: vim: Redefine vim-build. build-system: waf: Improve waf-build style. build-system: zig: Redefine zig-build. build-system: trivial: Redefine trivial-build functions. guix/build-system.scm | 2 +- guix/build-system/agda.scm | 8 +-
Re: How/where/when to ask for a patch review?
Hello, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > On Sat, Jan 06 2024, Tomas Volf wrote: > >> what is the proper channel to ask for a patch review and how long >> should one wait before doing so. I think it is reasonable to bump the bug report associated to your patch after a week, or possibly two during a winter break. Note that committers generally wait for a green flag in the QA page <https://qa.guix.gnu.org/patches>. Unfortunately, I noticed it had some hiccups recently. > Please don't waste your time waiting. The process of patch review and > acceptance here is erratic. I won't go into reasons; the project > understands the problem and is trying several solutions but I'm not sure > they are working. Please go ahead and maintain your own fork of Guix. It is certainly a pragmatic answer, but hopefully, we can do better. > No chance. I run about a hundred patches on top of stock and build half > of all packages myself (mainly due to a defective eudev in Guix). In > another month, I'll be at two hundred. IMHO, at this point, you should ask for write access to the project, This would certainly help everyone involved. Regards, -- Nicolas Goaziou
Re: How/where/when to ask for a patch review?
Hi Tomas, On Sat, Jan 06 2024, Tomas Volf wrote: > what is the proper channel to ask for a patch review and how long > should one wait before doing so. Please don't waste your time waiting. The process of patch review and acceptance here is erratic. I won't go into reasons; the project understands the problem and is trying several solutions but I'm not sure they are working. Please go ahead and maintain your own fork of Guix. They will take what they want. > PS: This patch being ignored was the last push I needed to start my personal > fork This one? [1] > I would like to diverge as little as possible. No chance. I run about a hundred patches on top of stock and build half of all packages myself (mainly due to a defective eudev in Guix). In another month, I'll be at two hundred. Again, they will take what they want. Please don't wait. It's an unreasonable expectation vis-a-vis the group. Kind regards Felix [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67546
Re: Suggestion for a guix shell feature.
Tried to use to antioxydant build system, I cannot seem to add it as a channel but was able to clone the repo and authenticate it manually.. then guix build -L . -f antioxidant-packages.scm fails to run with error, ice-9/eval.scm:223:20: In procedure proc: error: rust-sequoia-ipc-0.26: unbound variable hint: Did you forget a `use-modules' form? I think I am going to stick to adding libs to LD_LIBRARY_PATH manually as it works even though I know you said its wrong. -- Sent with Tuta; enjoy secure & ad-free emails: https://tuta.com Jan 3, 2024, 17:57 by maxim.courno...@gmail.com: > Hi, > > Apoorv writes: > >> OK, it was my bad I had an older copy of guix.scm file I was passing >> that, it didn't have cargo-build-system. But now I'm getting so many >> other errors related to cargo deps missing or version mismatch, I >> tried adding those deps spent like 1-2 hours but something dep was >> still missing or version mismatch, finally I gave up. I'm not sure how >> many deps I have to add like this.. this is getting way to complicated >> then it needs to be. >> > > cargo/rust is poorly integrated in Guix, as there's some impedance > mismatch between package handling by Guix and Cargo itself, which would > rather take care of it. > > I'd expect most Rust developpers using Guix only do so to provide > Rust/Cargo, and let Cargo take care of the rest. Otherwise you'd need > to replicate the pain the cargo-build-system goes through to make it > work. > > A more future-proof approach if you'd like to improve Rust integration > into Guix would be to continue integrating the 'antioxydant' build > system effort started by Maxime Devos [0], which doesn't rely on Cargo > to build Rust crates (and supports dynamic linking of Rust libraries, I > think?). > > [0] https://notabug.org/maximed/cargoless-rust-experiments > > -- > Thanks, > Maxim >
Re: Why is it acceptable to have digital-ocean-configuration in the Guix?
Hi Dave, On Thu, Jan 04 2024, Thompson, David wrote: > On Thu, Jan 4, 2024 at 5:34 AM Tomas Volf <~@wolfsden.cz> wrote: > > Guix also downloads a lot of source code from GitHub. Is this an issue? I agree with you, but together with the new Copilot key [1] that should serve as a warning to us all. Long live the GPL! Kind regards Felix [1] https://www.theverge.com/2024/1/4/24023809/microsoft-copilot-key-keyboard-windows-laptops-pcs
