Re: New mumi www and mumi compose subcommands
Hi Ludo, Ludovic Courtès writes: > Won’t work with Gnus, but nice still. ;-) You should be able to customize `url-mail-command`, see "(url) mailto". Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix pull: avoiding "Computing Guix derivation"
Hi everyone,
Edouard Klein writes:
> I think my misunderstanding boils down to a bad mental model of how guix
> works.
>
> What I imagine the "Computing guix derivation" step to be is no
> different than building a package whose inputs are the channels'
> sources, guile, and the current guix, and whose output is the new guix.
>
> Simon and Richard pointed out that the combinatorial combination of all
> possible input combination makes this hard to substitute, but I don't
> understand how its result, once in the store, can't lead to a simple
> linking from the profile to the store, instead of re-running the
> "Computing guix derivation" step when guix pull is called with the same
> inputs.
>
> Surely my mental model is wrong somehow ?
You might be interested in this thread [1], which tries to explain the
terrible performance of `guix pull`.
[1] mid:87wmxe3vsa@jpoiret.xyz
https://yhetil.org/guix/87wmxe3vsa@jpoiret.xyz/
Best,
--
Josselin Poiret
signature.asc
Description: PGP signature
Re: Core updates status
Hi Ludo, Ludovic Courtès writes: > I’m in favor of whatever allows us to move forward more quickly, so > temporarily stashing away the pkgconf changes sounds good to me. > > In that case, when time permits, could you push a ‘core-updates-new’ (?) > branch, (partially) rebased and without the pkgconf changes, and a > separate ‘wip-pkgconf’ branch? Does that seem doable to you? I did that partially yesterday, moved the old borked core-updates to old-core-updates and pushed the cleaned-up version at core-updates. I haven't pushed the pkgconf patches anywhere yet, but we should probably focus on c-u for now and worry about that later. > It would be great if you could also explain at which commit you started > rebasing ‘core-updates’¹ and which method/script you used. I started rebasing at the very first commit of core-updates that wasn't reachable from master (it is a rebase after all). I wrote a little script (attached) that basically filters `git rev-list` output, removing commits for which a commit with the same name appears on master after 1.4. #!/usr/bin/env -S guile -s !# (use-modules (ice-9 popen) (ice-9 textual-ports)) (define (check name) (let* ((input+output (pipe)) (pid (spawn "git" (list "git" "log" "-n1" "v1.4.0..origin/master" "-F" (string-append "--grep=" name)) #:output (cdr input+output (close-port (cdr input+output)) (define res (let loop ((n 0)) (if (eof-object? (get-line (car input+output))) n (loop (+ 1 n) (close-port (car input+output)) (waitpid pid) (> res 0))) (check "gnu: Add glirc.") (let ((port (open-input-pipe "git rev-list --no-merges origin/master..origin/core-updates --pretty=oneline"))) (define res (let loop ((acc '())) (let ((line (get-line port))) (if (eof-object? line) acc (loop (cons line acc)) (close-pipe port) (for-each (lambda (line) (unless (check (string-drop line 41)) (format #t "~a~%" line))) res)) ;; (unless (check (string-drop line 41)) ;; (format #t "~a~%" line)) The one thing that we need to do right now is update glibc 2.39 with all the fixes from the upstream release/2.39/master branch. I don't think we've done this before significantly, but since we have an occasion this time we might as well. We can't really use git-fetch for glibc, so imo the only feasible option is like what Debian does [1], which is keeping a diff of the 2.39 tag and the release branch and applying it as a patch. We'll then probably need to add autotools to glibc builds, but this is doable even in commencement because we have them already available at that point. The own downside of this is that the patch name will not include the fixed CVEs, so guix lint won't be aware that the CVEs have been patched. [1] https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/git-updates.diff WDYT? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Core updates status
Hi Maxim, Maxim Cournoyer writes: > Hi Josselin, > > Josselin Poiret writes: > > [...] > >> However, as you can see, these are non-local failures: build failures >> have to be fixed in a dependency, which incurs a lot of rebuilding. >> I've fixed a couple of them locally, but here's a nasty one I just got >> stuck on: curl has a .la file with "-lnettle -lhogweed -lgssapi_krb5", >> which leads to a build failure for... flatpak :( So fixing this properly >> would lead to a world rebuild. >> >> I'm worried this will keep accumulating a bunch of world rebuilds, >> slowing down c-u some more. I'd vote to keep the pkgconf switch for >> later and focus on merging the rest of what c-u has to offer. > > I don't mind too much; when we re-enable the change we should add a > phase to the gnu-build-system automatically deleting/moving the libtool > archives. so that we're covered. I agree, although we'll have to be careful since some packages might need them if they don't use pkg-config! Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Core updates status
Hi everyone, I've just cleaned up the c-u branch locally (removing all the duplicated commits) and rebased it on master since we're going to have to rewrite history anyways. I'm trying to build a bit with it to double check that nothing got messed up in the process, so I haven't pushed that anywhere yet. Efraim Flashner writes: > Seeing that librsvg has rust-pango (and some others) in cargo-inputs, > and therefore needs pango to build, I think it's safe to move pango (and > others as needed) to propagated inputs. Make sure to make the necessary > changes to librsvg-2.40 also. > > I haven't had any problems building the rust based librsvg on > core-updates, so I'd suggest leaving that alone for now. Basically, the issue is that libtool+pkg-config used to overlink, leading to libtool dependencies being fulfilled without needing them to be actually present as inputs. Now, because there are recent commits replacing pkg-config with pkgconf, libtool is requiring more libraries than needed at link time. The option then is to just remove .la (libtool archive) files in package outputs, so that their dependents don't try to use them (and it usually just works). Removing them in librsvg makes guile-rsvg build again. However, as you can see, these are non-local failures: build failures have to be fixed in a dependency, which incurs a lot of rebuilding. I've fixed a couple of them locally, but here's a nasty one I just got stuck on: curl has a .la file with "-lnettle -lhogweed -lgssapi_krb5", which leads to a build failure for... flatpak :( So fixing this properly would lead to a world rebuild. I'm worried this will keep accumulating a bunch of world rebuilds, slowing down c-u some more. I'd vote to keep the pkgconf switch for later and focus on merging the rest of what c-u has to offer. WDYT? -- Josselin Poiret signature.asc Description: PGP signature
Re: Status of ‘core-updates’
Hi Ludo, Ludovic Courtès writes: > What’s the status of ‘core-updates’? What are the areas where help is > needed? Disclaimer: I've been quite busy with work recently and haven't been able to work on core-updates that much (having to build the world locally doesn't help). Currently, the desktop system image doesn't build anymore because we've also integrated patches to use pkgconf instead of pkg-config. I think the effort to actually make that work with all of our packages is going to be a bit too much to handle right now. IMO, we should probably revert/branch out before then so that we can push core-updates past the finish line. A feature branch to integrate pkgconf properly could then be worked on later. Other than that, I was able to get a working desktop before the aforementioned patches but with some locale errors that I fixed with ae07bc2dd0124b625acf70e594ccc90d6d128562, so I'm not expecting too much trouble. We'll probably have to add libxcrypt as an input to some other packages that I haven't tested yet, but that's quite trivial. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Contribute or create a channel?
Hi Attila, Attila Lendvai writes: >> > channels are a step towards this, but they are not enough in their >> > current form to successfully accommodate for such a setup. an obvious >> > thing that is missing is a way to formally express inter-channel >> > dependencies, including some form of versioning. >> >> >> Do we not have this? The manual documents a mechanism for channel >> dependencies in "(guix) Declaring Channel Dependencies". >> >> I haven't used it, but it looks like the dependencies are declared as >> channels, which can have the usual branch/commit specifications to tie >> them to specific versions. > > good point, thanks! > > i looked briefly at the code just now. it's not trivial, and it seems to > treat the guix channel specially (because i don't need to specify it as a > dependency in my channel's .guix-channel file), and i'm not sure how it > behaves when e.g. two channels depend on the same channel, but pick two > different commits... or all the other convoluted situations. The situation you describe where two channels pick different commits for a channel dependency *cannot* be made to work, at least using Guile. I think what would currently happen is that either: 1) Guix refuses to build (unlikely); 2) Guix just chooses one commit that it then uses to build all dependent channels, contrary to the requirements; 3) Guix does build each channel with the proper dependencies, but the final Guix will have profile collisions. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: G-exps: thunk instead of top-level references?
Hi Hartmut,
Hartmut Goebel writes:
> Hi Ludio,
>
> I'd like to get some advice:
>
> In commit 84c3aafb5a18ad278bbb36df7b70849fe05789c8 "trytond: Avoid top-level
> references to other modules"
> your turned a top-level variable which defines into a thunk:
>
> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=84c3aafb5a18ad278bbb36df7b70849fe05789c8>
>
> -(define %standard-trytond-native-inputs
> +(define (%standard-trytond-native-inputs)
> `(("python-dateutil" ,python-dateutil)
>
> and the users:
>
> (native-inputs
> - `(,@%standard-trytond-native-inputs
> + `(,@(%standard-trytond-native-inputs)
> ("trytond-purchase" ,trytond-purchase)))
>
> I'm about to change the uses into G-exprs (see below) and wonder whether
> "%standard-trytond-native-inputs"
> should still be a thunk or can be turned pack into a top-level variable.
>
> -(define (%standard-trytond-native-inputs)
> - `(("python-dateutil" ,python-dateutil)
> +(define %standard-trytond-native-inputs
> + (list python-dateutil
>
> and uses
>
> -(native-inputs (%standard-trytond-native-inputs))
> +(native-inputs
> + (cons* trytond-account-payment-clearing
> +%standard-trytond-native-inputs))
>
Yes it still needs to be a thunk for the same reason: no top-level
references to packages in other modules. By the way, (list ...) is not
a G-exp, it's rather the new input style.
Best,
--
Josselin Poiret
signature.asc
Description: PGP signature
Re: [PATCH 2/2] gnu: grub: Modernize.
Hi Fabio, Fabio Natali writes: > On 2024-03-03, 17:42 +0100, Josselin Poiret wrote: >> From: Josselin Poiret >> >> * gnu/packages/bootloaders.scm (grub-minimal, grub-coreboot, grub-efi32, >> grub-hybrid): Use G-Exps. >> (grub-efi): Use G-Exps. Also use OVMF to test. > > Hi Josselin, > > This is brilliant, thanks. > > I'll see how far I can go with this and get back to you. I might reach > out to you on IRC, maybe, in case I need some guidance? > > Thanks, cheers, Fabio. Of course, I'm known as jpoiret there. I use a bouncer, so even if I'm online I might not be available, but will definitely read your message later if that's the case. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: on the bug tracker (Re: Guix Days: Patch flow discussion)
-- Giovanni Biscuolo writes: > Hi Josselin, > > Josselin Poiret writes: > > [...] > >> One thing I would like to get rid of though is debbugs. > > given that a significant part of the Guix infrastructure is provided by > the GNU project, including the bug/issue tracker, and I don't think that > GNU will replace https://debbugs.gnu.org/ (or the forge, Savannah) with > something else, I suggest to concentrate the Guix community efforts in > giving contributors better user interfaces to Debbugs, e.g Mumi (web and > CLI) instead of trying to get rid of it. We can re-use some other tool as well, no need to code our own in Guile though. Also note that the choice of bug-tracking tool is not benign, as most other tools (Mumi, but also QA) have to adapt to its idiosyncrasies. > In other words: the "problem" it's not the tool, it's the *interface*. I don't agree: see below for the two examples of where the tool design itself is problematic. > Please also consider that if (I hope not) the Guix would decide to adopt > a different bug/issue tracker system then Someome™ will have to > administrate it, and currently there are other pieces of core > infrastructure that need more resources, e.g. QA. > > Speaking of interface features, I simply *love* the email based > interface provided by Debbugs [1]; also the web UI is not bad, and the Mumi > one (https://issues.guix.gnu.org/) it's even better. I prefer a public-inbox web frontend for browsing emails personally. >> It causes a lot of pain for everyone, eg. when sending patchsets, it >> completely breaks modern email because it insists on rewriting >> DMARC-protected headers, thus needing to also rewrite "From:" to avoid >> DMARC errors. > > I don't understand what "completely breaks modern email" means: please > could you point me to a document where this issue/bug is documented? I don't think there's a "public" discussion of this, but I've conversed with the mailman maintainers in private about this: because Debbugs relies on modifying the mail message itself, it clashes with modern email features that authentify received emails. DKIM authentifies a subset of mail headers by signing them with a private key, among which the "From" header is mandatory. DMARC is a policy mechanism for domains that can enforce DKIM (and/or SPF) for all mails with a corresponding "From:". Together, they prevent email impersonation. So Debbugs modifies a protected header (e.g. Subject) -> DKIM fails -> if DMARC is set to enforce DKIM, DMARC fails -> mail is not received. To avoid this issue, Mailman (the mailing daemon overseeing the debbugs-managed MLs) also rewrites the From: header of such mails to a debbugs-controlled domain, so that DKIM headers can be re-signed and a different DMARC policy be used. This is why you often see "via guix-patches" in From: headers, and if you look at the email it's a generic one. I've also mentioned this before, but not being able to simply send a full patchset without having to go through hoops is, put simply, a problem. Even prospective contributors used to email-based workflows will be turned off by this. In general, the problem with Debbugs is that it insists on *taking over* emails, rather than just consuming them. >> I've been following the Linux kernel development a bit closer this past >> year, and while there are things that need to improve (like knowing the >> status of a patchset in a maintainer's tree), they at least have a lot >> of tools that I think we should adopt more broadly: > > you mention: b4/lei and patchwork but they are not bug/issue trackers. Yes, I was mentioning general tools. > I personally like the idea that the bug/issue tracker is _embedded_ > (integrated?) in the DVCS used by the project, Git in Guix case. > > For this reason I find Tissue https://tissue.systemreboot.net/ an > interesting project for *public* issue/bug tracking systems, also > because Tissue is _not_ discussion-oriented: this means that > discussions are managed "somewhere else", because «It's much better to > have a clear succinct actionable issue report. This way, the issue > tracker is a list of clear actionable items rather than a mess of > unreproducible issues.» [2] I like this separation as well, and Tissue seemed interesting the last time I looked at it. I liked how it uses standard tools and can be consulted/modified off-line. It basically checks all of the boxes :) Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Bugs and Patches---or rather, bugs or patches?
Hi Felix, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Hi, > > We track bugs and patches separately. Does the distinction serve a > purpose? May I combine them? What do you mean by tracking them separately and combining them? They're on two different lists, right? I don't like the separation between both MLs, sure, but that's it. What would be the pros/cons of such a merge? Best, -- Josselin Poiret signature.asc Description: PGP signature
[PATCH 2/2] gnu: grub: Modernize.
From: Josselin Poiret
* gnu/packages/bootloaders.scm (grub-minimal, grub-coreboot, grub-efi32,
grub-hybrid): Use G-Exps.
(grub-efi): Use G-Exps. Also use OVMF to test.
Change-Id: Ic9c73753004739d6027b8426eb46c114a6a31051
---
gnu/packages/bootloaders.scm | 286 +++
1 file changed, 152 insertions(+), 134 deletions(-)
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 1327055484..39b98b0876 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -307,20 +307,18 @@ (define-public grub-minimal
'(list "PYTHON=true"))
((#:tests? _ #t)
#f)
- ((#:phases phases '%standard-phases)
-`(modify-phases ,phases
- (replace 'patch-stuff
- (lambda* (#:key native-inputs inputs #:allow-other-keys)
- (substitute* "grub-core/Makefile.in"
- (("/bin/sh") (which "sh")))
-
- ;; Make the font visible.
- (copy-file (assoc-ref (or native-inputs inputs)
- "unifont")
- "unifont.bdf.gz")
- (system* "gunzip" "unifont.bdf.gz")
-
- #t
+ ((#:phases phases #~%standard-phases)
+#~(modify-phases #$phases
+(replace 'patch-stuff
+ (lambda* (#:key native-inputs inputs #:allow-other-keys)
+(substitute* "grub-core/Makefile.in"
+ (("/bin/sh") (which "sh")))
+
+;; Make the font visible.
+(copy-file (assoc-ref (or native-inputs inputs)
+ "unifont")
+ "unifont.bdf.gz")
+(system* "gunzip" "unifont.bdf.gz")
(define-public grub-coreboot
(package
@@ -328,64 +326,64 @@ (define-public grub-coreboot
(name "grub-coreboot")
(synopsis "GRand Unified Boot loader (Coreboot payload version)")
(arguments
- `(,@(substitute-keyword-arguments (package-arguments grub)
- ((#:phases phases '%standard-phases)
-`(modify-phases ,phases
- (add-before 'check 'disable-broken-tests
- (lambda _
- (setenv "DISABLE_HARD_ERRORS" "1")
- (setenv
-"XFAIL_TESTS"
-(string-join
- ;; TODO: All the tests below use grub shell
- ;; (tests/util/grub-shell.in), and here grub-shell uses
- ;; QEMU and a Coreboot image to run the tests. Since we
- ;; don't have a Coreboot package in Guix yet these tests
- ;; are disabled. See the Guix bug #64667 for more details
- ;; (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64667).
- (list
- "pata_test"
- "ahci_test"
- "uhci_test"
- "ehci_test"
- "example_grub_script_test"
- "ohci_test"
- "grub_script_eval"
- "grub_script_echo1"
- "grub_script_test"
- "grub_script_leading_whitespace"
- "grub_script_echo_keywords"
- "grub_script_vars1"
- "grub_script_for1"
- "grub_script_while1"
- "grub_script_if"
- "grub_script_comments"
- "grub_script_functions"
- "grub_script_continue"
- "grub_script_break"
- "grub_script_shift"
- "grub_script_blockarg"
- "grub_script_return"
- "grub_script_setparams"
- "grub_cmd_date"
- "grub_cmd_sleep"
- "grub_cmd_regexp"
- "grub_script_not"
- "grub_cmd_echo"
- "grub_script_expansion"
- "grub_script_gettext"
- "grub_script_escape_comma"
- "help_test"
- "grub_script_strcmp"
- "test_sha512sum"
- "grub_cmd_tr"
- "test_unset"
- "file_filter_test&qu
[PATCH 1/2] gnu: grub: Update to 2.12.
From: Josselin Poiret
* gnu/packages/bootloaders.scm (grub): Update to 2.12.
Change-Id: I5d9ae3952b61b47418cb571fc0bcb5318e72
---
gnu/packages/bootloaders.scm | 182 ---
1 file changed, 102 insertions(+), 80 deletions(-)
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 986f0ac035..1327055484 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -103,94 +103,113 @@ (define unifont
(define-public grub
(package
(name "grub")
-(version "2.06")
+(version "2.12")
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnu/grub/grub-" version ".tar.xz"))
(sha256
(base32
-"1qbycnxkx07arj9f2nlsi9kp0dyldspbv07ysdyd34qvz55a97mp"))
+"1ahgzvvvwdxx7rl08pv5dyqlgp76jxz0q2cflxvsdsn4yy8p7jgk"))
(patches (search-patches
"grub-efi-fat-serial-number.patch"
-"grub-setup-root.patch"))
- (modules '((guix build utils)))
- (snippet
- '(begin
- ;; Adjust QEMU invocation to not use a deprecated device
- ;; name that was removed in QEMU 6.0. Remove for >2.06.
- (substitute* "tests/ahci_test.in"
-(("ide-drive")
- "ide-hd"))
+"grub-setup-root.patch"
(build-system gnu-build-system)
(arguments
- `(#:configure-flags
- ;; Counterintuitively, this *disables* a spurious Python dependency by
- ;; calling the ‘true’ binary instead. Python is only needed during
- ;; bootstrapping (for genptl.py), not when building from a release.
- (list "PYTHON=true")
- ;; Grub fails to load modules stripped with --strip-unneeded.
- #:strip-flags '("--strip-debug" "--enable-deterministic-archives")
- #:phases
- (modify-phases %standard-phases
- (add-after 'unpack 'patch-stuff
- (lambda* (#:key native-inputs inputs #:allow-other-keys)
- (substitute* "grub-core/Makefile.in"
- (("/bin/sh") (which "sh")))
-
- ;; Give the absolute file name of 'mdadm', used to determine the
- ;; root file system when it's a RAID device. Failing to do that,
- ;; 'grub-probe' silently fails if 'mdadm' is not in $PATH.
- (when (assoc-ref inputs "mdadm")
- (substitute* "grub-core/osdep/linux/getroot.c"
- (("argv\\[0\\] = \"mdadm\"")
- (string-append "argv[0] = \""
- (assoc-ref inputs "mdadm")
- "/sbin/mdadm\""
-
- ;; Make the font visible.
- (copy-file (assoc-ref (or native-inputs inputs)
- "unifont")
-"unifont.bdf.gz")
- (system* "gunzip" "unifont.bdf.gz")
-
- ;; Give the absolute file name of 'ckbcomp'.
- (substitute* "util/grub-kbdcomp.in"
- (("^ckbcomp ")
-(string-append
- (search-input-file inputs "/bin/ckbcomp")
- " ")
- (add-after 'unpack 'set-freetype-variables
- ;; These variables need to be set to the native versions of the
- ;; dependencies because they are used to build programs which are
- ;; executed during build time.
- (lambda* (#:key native-inputs #:allow-other-keys)
- (when (assoc-ref native-inputs "freetype")
- (let ((freetype (assoc-ref native-inputs "freetype")))
- (setenv "BUILD_FREETYPE_LIBS"
- (string-append "-L" freetype
-"/lib -lfreetype"))
- (setenv "BUILD_FREETYPE_CFLAGS"
- (string-append "-I" freetype
-"/include/freetype2"))
- (add-before 'check 'disable-flaky-test
- (lambda _
- ;; This test is unreliable. For more information, see:
- ;; <https://bugs.gnu.org/26936>.
- (substitute* "Makefile.in"
- (("grub_cmd_date grub_cmd_set_date grub_cmd_sleep")
-"grub_cmd_date grub_cmd_sleep"
- (add-before 'check 'disable-pixel-perfect-test
- (lambda _
- ;; This test compar
Re: LUKS2 support in Guix
Hi Fabio and everyone, Fabio Natali writes: > On 2024-03-02, 10:41 +0300, Oleg Pykhalov wrote: >> I also lost some time due to this incorrect statement. > > Brilliant, thanks Felix and Oleg. > > FWIW, micro-patch submitted here⁰. > > Let's see what the patch reviewer thinks. I'm not terribly happy about > "downgrading" the manual's recommendation from LUKS2 to LUKS1, but if > LUKS2 is really not supported, then of course that needs to be reflected > in the docs. > > Best wishes, Fabio. > > > ⁰ Ticket 69507 on debbugs.gnu.org. I wanted to link to the relevant page > on https://lists.gnu.org/archive/html/guix-patches/2024-03/index.html > but it seem it's taking a while for the mail to pass moderation. The reason why it hasn't been spelled out in the manual is because I thought that we could simply upgrade to Grub 2.12, which would solve the issue as it supports LUKS2 properly. I have a patch locally upgrading Grub, but it's not in upstreaming shape yet and I haven't had much time to work on it recently. I am running it though, and it's working quite well. Would anyone be interested in cleaning it up and sending it upstream? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Feedback of the GNU Guix manual
Hi Matt, Matt writes: > The explanation of "a self-contained tarball providing binaries for Guix and > for all its dependencies" was reduced to the simpler "archived binaries." > Generally, "tarball" is imprecise, hence the need to explain what it contains > in this context. Further, it's jargon, may not be familiar to some readers, > and isn't relevant to the point of the introduction, that Guix may be > installed without needing to compile and why that might be desirable. > > Specific mention of installing Guix's dependencies was removed. Guix being > installed implies that its dependencies are also installed. I don't agree here: it's often the case in Linux-land that binary archives are provided without their dependencies included, assuming that the user already has them, often by installing them via their own package manager. Keeping the mention that it is self-contained and that the dependencies are also included might clarify the situation for some users. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Core-updates coordination and plans
Hi again everyone, Thanks for the feedback! So in the meantime I chose to go ahead and try with 2.39 (how hard could it be?). The main visible change for us in 2.39 is the removal of the crypt library, with a replacement being the external libxcrypt. This wasn't too bad to fix in most places, you can find that work on core-updates-glibc-2.39. I am able to build up to Gnome, but trying to build the desktop.tmpl vm image, I stumbled upon a quite annoying issue: Guix recommends using Guile's (crypt ...) function, which is included only if libcrypt is available during the build. However, Guile appears very early in the dependency graph, and you can't just add libxcrypt to its dependencies without causing some cycle. Should commencement's guile-final be a minimal version of Guile without libcrypt, while guile-3.0 includes it? Do we want to be able to use (crypt ...) in g-exps? I don't really know what the answer to those questions should be, but it probably involves a world rebuild :(. Anyone have an idea/opinion about this conundrum? Other than that, I think that branch is in a pretty ok shape, I've also included a couple of patches that were requested. WDYT? -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Simon, Simon Tournier writes: > PS: *agree on B4 although there is tricky bugs as reported here: > <https://github.com/mricon/b4/issues/4>. I think b4's ML is more active than the GitHub issues, I have already sent some bug reports and patches there that were picked up quite fast. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Felix, Felix Lechner writes: > 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. See e.g. [1], where my reply should have the subject “Re: bug# ...”, but Debbugs doesn't like that and so changes it to just “bug#nnn ...”. This modification in turn invalidates DMARC because From is protected, so it *has* to rewrite it to another domain to make it pass DMARC. [1] mid:87eddk630t@jpoiret.xyz (https://yhetil.org/guix/87eddk630t@jpoiret.xyz/) Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)
Hi Romain, Romain writes: > IIRC, grub doesn't take the keymap into account unless the `at_keyboard` > module is loaded. It is not the case at the moment. > Also there seems to be an incompatibility between this module and some laptop > keyboards (for example I have a Thinkpad X220 with libreboot/seabios payload > and the keyboard stopped working after loading this module). > [...] > Even in the BIOS case, as far as I understood the code, the grub image > installer function doesn't have access to `bootloader-configuration` data. I > think that passing it down to this function would require some changes in the > way the bootloader is installed. But I might have overseen something, that I > why I was hoping for someone knowledgeable to jump in the discussion :) No, you're right, that's the kind of refactoring I was thinking about. It's not conceptually hard but kind of annoying to do. Same for the at_keyboard module, although I'm wondering how the current situation works for you then. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Felix, Felix Lechner writes: > 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? Why “in addition” though? As long as Debbugs is modifying mails on the MLs it's being troublesome. >> 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? That might introduce too much complexity: what we probably want is just a bug tracker that maps bug IDs to Message-IDs, then consumers just use whatever tool they'd prefer, be it browsing a public-inbox instance through a browser, their local mail, etc. Debbugs could include a public-inbox instance, or just interact with one (preferred so that efforts are not duplicated). Just having the header part of e.g. bugzilla would be nice, maybe with a log of mails that caused a state change, and a list of relevant threads (there could be multiple, for example if there are multiple versions of a patchset, or for the bug report and the ensuing fix). Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Felix, Felix Lechner writes: > 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? To me, an ideal solution would be a service that 1) Doesn't modify any incoming mail; 2) Provides a way to look-up the bugs related to a thread and their status, preferably using Message-ID, so that it can be used in conjunction with other mail-based tools without disturbing them. Your proposed modification would be a first step in that direction, but would still not solve 1 and 2 perfectly. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)
Hi Felix, Felix Lechner writes: > 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] We could move it up and that would solve it for people not using encrypted /boot I believe. However, for people using encrypted /boot, the keymap would never be loaded instead of loaded after unlocking the volume. The solution for that is to embed the keymap in the GRUB image, so that it can always be found. I believe we don't use grub-mkimage directly for the efi case for now, which is the command we want to use to be able to include arbitrary files in the image, hence my comment about the code needing some refactoring. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: On the road to the next release: testing the installer
Hi Romain, Romain writes: > Hi, > > On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret > wrote: >>We don't try to embed the required keymap in the GRUB image and load it >>early on. It shouldn't be too hard, but would require a bit of >>refactoring. >> > > I started looking at this issue as I am also using full encryption with Guix > system. > If someone familiar with the grub-bootloader module would give me a few > pointers, I'd be happy to work on fixing it. AFAIR, I couldn't figure out how > to access to the grub configuration in the code installing the grub image on > disk. The grub configuration is generated by make-grub-configuration in gnu/bootloader/grub.scm. The idea would be to add the generated keyboard layout to the initial grub image, and make sure that keyboard-layout-config appears first in the generated config. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: On the road to the next release: testing the installer
Hi Tanguy, Tanguy LE CARROUR writes: > Grub asked me right away my passphrase and… it did not work! > After several attempts, I figured out that the keyboard layout > was apparently set to `qwerty` even though I had selected `bépo AFNOR` > during the configuration. When I eventually typed my passphrase > in `querty` Grub started and boot my system and… I had to type the > passphrase a second time, but, fortunately this time in `bépo`! > I checked the `config.scm` and the layout was properly set in the > bootloader declaration. We don't try to embed the required keymap in the GRUB image and load it early on. It shouldn't be too hard, but would require a bit of refactoring. > I then reconfigured my `guix home` and logged back and… the script > that runs on first login failed for `XDG_RUNTIME_DIR` was not set! > I checked and `/run/user/1000` was not even present. This is usually a symptom of elogind's PAM module not running/working. Did you use %desktop-services as a base for services? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi again Sunhail, Josselin Poiret writes: > Hi Sunhail, > >> Josselin Poiret writes: >> >>> One thing I would like to get rid of though is debbugs. It causes a >>> lot of pain for everyone, eg. when sending patchsets, it completely >>> breaks modern email because it insists on rewriting DMARC-protected >>> headers, thus needing to also rewrite "From:" to avoid DMARC errors. >> >> Thank you for sharing (what seems to be) a technical limitation of >> Debbugs. Could you please explain what the consequences of the above >> are? Specifically, how does the rewriting of above headers affect the >> contributors' workflow? > > Every reply to one of your mails ends up creating a new thread in my > mail client, because the In-Reply-To chain ends up being broken. Ah, whoops, I thought you were asking about the Message-ID problem I also reported to you, not my above paragraph, sorry. One big consequence: mails containing patches can often have bogus From: headers, which are used by git for the commit author. Thus, we end up with commits in the repo authored by eg. "Josselin Poiret via Guix-patches via ". We added a default gitconfig entry that also puts the From: in the body of the message so that it is not corrupted to circumvent this. 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, and have to resort to hacks like the CLI `mumi` tool uses. I can't just send a patchset and be done with it, I have to wait a couple minutes. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Sunhail, > Josselin Poiret writes: > >> One thing I would like to get rid of though is debbugs. It causes a >> lot of pain for everyone, eg. when sending patchsets, it completely >> breaks modern email because it insists on rewriting DMARC-protected >> headers, thus needing to also rewrite "From:" to avoid DMARC errors. > > Thank you for sharing (what seems to be) a technical limitation of > Debbugs. Could you please explain what the consequences of the above > are? Specifically, how does the rewriting of above headers affect the > contributors' workflow? Every reply to one of your mails ends up creating a new thread in my mail client, because the In-Reply-To chain ends up being broken. >> b4/lei is a nice example (we already have yhetil.org as a back-end, >> but maybe a more blessed one would be better) of a tool that lets you >> completely automate applying a patchset to a branch. >> >> patchwork is a nice tool to gather up and track patchsets, with status >> indicators like "under review", "accepted", etc. Chris already >> deploys one as part of QA, more integration with it would be nice. > > It seems (based on above) that "patchwork" can co-exist with debbugs. > Is that also the case with b4/lei? Specifically, are the > users/reviewers able to benefit from using the above tools at present? > Or are there some reasons (over and above their lack of familiarity with > the above tools) that would prevent them from doing so? They both can co-exist with debbugs, and for now the patchwork instance of QA is not usable for status tracking (because it is not meant to be used as such for now). One can already use both of them, but using both supercedes debbugs, and gets rid of its limitations. I've been using b4/lei with the yhetil public-inbox instance, with piem.el as an interface, and it's really useful. With a properly configured b4, one could simply run `b4 shazam some-msg-id` and it would automatically apply the corresponding patchset. And before you ask why I'm so intent on getting rid of Debbugs, I believe that mailing lists should be just that, mailing lists. Anything that tries to rewrite incoming mail is asking for trouble nowadays. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Sunhail, Your mailing system is sending out emails that contain an invalid Message-ID header (missing right part of the msgid as specified in [1]), which causes erratic behavior from other participants (the gmail smtp servers for example just rewrite the message id to indicate it is malformed, breaking the reply chain). Could you please fix this? This is quite on-topic in a discussion about the mail-based workflow :) [1] https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4 Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Days: Patch flow discussion
Hi Hartmut, Hartmut Goebel writes: > Anyhow, all of this has been discussed several times already. And as > long as vocal (and active :-) members of the community insist on being > able to work via e-mail — while also not adopting modern e-mail-capable > forges — this situation will not change. While I agree with your assessment of what's missing in this workflow, I'm not sure I know of any e-mail-capable forges that resolve those particular pain points… People often think that eg. sr.ht works better for this, but I don't think the sr.ht MLs have any more structure than what we have. For smaller projects, it works okay, but once you get to the scale of something like Guix, it doesn't offer anything more. One thing I would like to get rid of though is debbugs. It causes a lot of pain for everyone, eg. when sending patchsets, it completely breaks modern email because it insists on rewriting DMARC-protected headers, thus needing to also rewrite "From:" to avoid DMARC errors. I've been following the Linux kernel development a bit closer this past year, and while there are things that need to improve (like knowing the status of a patchset in a maintainer's tree), they at least have a lot of tools that I think we should adopt more broadly: b4/lei is a nice example (we already have yhetil.org as a back-end, but maybe a more blessed one would be better) of a tool that lets you completely automate applying a patchset to a branch. patchwork is a nice tool to gather up and track patchsets, with status indicators like "under review", "accepted", etc. Chris already deploys one as part of QA, more integration with it would be nice. One advantage of this is that we would benefit from upstream's bigger user-base and dev time, and also from the fact that these tools are made to work together (b4 can automatically mark patchsets as accepted)! Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: guix installation why internet connection required?
Hi Giovanni, Giovanni Biscuolo writes: > Sorry I don't understand the problem, could you expand please? > > The guix (and daemon) versione are those of the channel used when > creating the install .iso image; booting the 1.40 installer we get a > "guix version" and "guix describe" value of 989a391... Not exactly, to include Guix inside the installer image, it somehow needs to refer to itself. The way it used to be done was by using the `guix` package, which necessarily is older than the current commit. However, we also implemented the `current-guix` hack that basically uses a guix checkout at the current guix version as the source for the guix package. In both cases though, we shouldn't see any differences in other package's derivations… Best, -- Josselin Poiret signature.asc Description: PGP signature
Core-updates coordination and plans
Hi everyone, Since we're a couple people working on core-updates at the same time, it might be a good idea to coordinate a bit (of course, other volunteers welcome :) ). One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and 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. glibc 2.39 should hopefully release tomorrow (01/02/2024) What is everyone's opinion regarding those? IMO, option 2 is the one I'd like to avoid, and between 1 and 3 I'd ideally prefer 3 but we don't know yet if there is going to be a lot of breakage because of that (feels like usually it's toolchain updates, not glibc updates that cause them the most). Also, I see that most of the patches that were requested to be merged into c-u (like the big pages for jemalloc) actually got pushed, are there any other (well-tested) ones we can go for at the same time as the glibc rebuild? I will stress that this is about *core* packages now, I feel that it's too late to introduce more complications and delay the update any longer. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: An update on ‘core-updates’
Hi everyone, Ludovic Courtès writes: > I don’t think I can commit to coordinating the stabilization effort > though as I’m busy with other things this month. Would anyone like to > take the lead on this? I've been slowly building up to gnome on c-u locally, with a couple of additional patches I'll try to send soon. I'd be happy leading the effort and merging the branch. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: problems installing on LUKS2 encrypted device
Hi both of you, Kaelyn writes: > About halfway through the email, your use of LUKS2 with Grub was tickling my > brain about what I remembered reading regarding Grub's LUKS2 support being > limited. While searching for references for that--and subsequently seeing > that you were already using PBKDF2--I came across > https://savannah.gnu.org/bugs/?55093 which seems to hold the answer. > According to the newest comment, Grub 2.06 has a seemingly-undocumented > additional requirement for working with LUKS2 of needing to use sha256 as the > keyslot hash. That's it: the GRUB userspace tools don't properly detect LUKS2 mapped devices and so don't include the modules needed to decrypt them. This is fixed in the newly released 2.12 (by yours truly), but we haven't packaged it yet. Using that would simply be the better solution, and I'll look into updating it in Guix soon. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Heisenbug
Hi Felix, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Hi, > > Running 'make' in a hacked Guix, I get this error the first time around: > > [ 84%] LOAD gnu/tests/ldap.scm > [ 84%] LOAD gnu/tests/linux-modules.scm > [ 84%] LOAD gnu/tests/mail.scm > [ 84%] LOAD gnu/tests/messaging.scm > [ 84%] LOAD gnu/tests/networking.scm > [ 84%] LOAD gnu/tests/package-management.scm > [ 84%] LOAD gnu/tests/pam.scm > [ 85%] LOAD gnu/tests/reconfigure.scm > ice-9/eval.scm:293:34: error: label: unbound variable > hint: Did you forget a `use-modules' form? > > make[2]: *** [Makefile:7104: make-system-go] Error 1 > make[2]: Leaving directory '/lcl/lechner/guix/git' > make[1]: *** [Makefile:6152: all-recursive] Error 1 > make[1]: Leaving directory '/lcl/lechner/guix/git' > make: *** [Makefile:4268: all] Error 2 > > When I run 'make' a second time, the error changes to: > > [ 77%] LOAD gnu/artwork.scm > [ 77%] LOAD gnu/bootloader.scm > [ 77%] LOAD gnu/bootloader/grub.scm > [ 77%] LOAD gnu/bootloader/extlinux.scm > [ 77%] LOAD gnu/bootloader/u-boot.scm > [ 77%] LOAD gnu/bootloader/depthcharge.scm > [ 77%] LOAD gnu/ci.scm > error: profile: source expression failed to match any pattern > > make[2]: *** [Makefile:7104: make-system-go] Error 1 > make[2]: Leaving directory '/lcl/lechner/guix/git' > make[1]: *** [Makefile:6152: all-recursive] Error 1 > make[1]: Leaving directory '/lcl/lechner/guix/git' > make: *** [Makefile:4268: all] Error 2 > > What's a good way to debug this, please? Where is my error? Thanks! Usually, these Heisenbugs come from the lack of dependency tracking in Guile: module dependencies have changed but their dependents weren't rebuilt. I would usually suggest `make clean-go` then `make`, and if the error happens again then you most likely are in front of the “actual” error. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
Hi everyone, Simon Tournier writes: > Hi, > > Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19 > november for Capitole du Libre: > [...] > Concretely, if you are planning to come, let synchronize and share the > fun. Andreas and I will be there. Who is in? Do not be shy and drop > an email; off-list possibly. I will be there! When will you arrive in Toulouse? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: [RFC]: Skipping rust crate tests by default
Hi Felix, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > In summary, I believe that #:test? should be turned off for all build > systems. Guix should instead test installed versions like Debian's > autopkgtest. Let me just chime in and say that I agree: tests should not be a part of a build. This would: 1) avoid time bombs in tests breaking builds; 2) gain a lot of time when iterating package definitions; 3) let us control the testing environment more precisely, use containers, mock stuff more precisely, etc. However, this would require refactoring *all* guix package definitions, after first coming up with a satisfying testing strategy and system. I don't think this will ever happen unfortunately. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: IDEA: missing-tests-pypi-error? condition
Hi jgart, > Is there a way to open the guix manual directly? > > Not sure why info opens a "main page" with all my texinfo manuals when > I give it doc/guix.info as an argument... 閭 You want `info -f doc/guix.info`. HTH, -- Josselin Poiret signature.asc Description: PGP signature
Re: Implementing the guix-dameon in Guile
Hi Chris, Christopher Baines writes: > Hey! > > I think this has been talked about for a while [1], but I want to make it > happen. Currently the guix-daemon is still similar to the nix-daemon > that it was forked from, and is implemented in C++. I think that a Guile > implementation of the guix-daemon will simplify Guix and better support > hacking on and around the daemon to add new features and move Guix > forward. > > 1: > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/ROADMAP.org#n71 > > My plan is to focus on this over the next year. I left my previous day > job quite a few months ago now to take a bit of a break, that's the main > reason I've been able to spend more time trying to push forward some of > the QA stuff. With some monetary support from NLNet [2], I'm planning to > continue this break and focus for the next year on getting a Guile > implementation of the guix-daemon written and adopted. Great and ambitious project! I am also interested in it and am willing to work on it (although at a much slower pace than you might). > 2: https://nlnet.nl/project/GuixDaemon-Guile/ > > Rewrites are risky because you only get the value right at the end, > therefore the priority is to get a minimal but viable implementation in > Guile that can be switched to, and not to get distracted on adding or > improving functionality unnecessarily. That is better done once the new > implementation has been adopted. > > While I think there's a substantial amount of work to do, progress > towards a Guile guix-daemon has already been made. There was a least one > GSoC project which did make progress, and there's Guile implementations > of some of the functionality in Guix already. > > Still though, I'd like to hear what people think about which direction > the implementation should go, and what features they'd like to see. Even > if those are not essential to make the Guile implementation viable, it > still might inform the direction to take. I think the #1 feature for me would be to have it completely unpriviledged using mount namespaces, so that you could still build software without needing to run the daemon on the system. You won't be able to run the built software without using namespaces as well though, but that still a step in the right direction imo. WDYT? -- Josselin Poiret signature.asc Description: PGP signature
Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)
Hi, Maxim Cournoyer writes: > That's no longer true, as of libgit2 v1.7.0 [0]. I already have it > packaged in a branch, but I need to iron out dependent breakages. > > [0] https://github.com/libgit2/libgit2/releases/tag/v1.7.0 > > So given there's no technical reasons not to use libgit2, I'd use that > and keep the closure size down. There's still the `git gc` problem though. My opinion is that the preferred API for Git is still the UNIX one via plumbing commands. Anything else is trying to catch up to it, and then we get into this conundrum that we want to do everything in Scheme, but we're unable to do it as well as Git itself. If I had to choose, a Guile library wrapping the Git commands would be the best, especially since we're managing long-living checkouts, something libgit2 doen't seem too interested in. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Building from git
Hi both of you (I'm replying to both at the same time), wolf writes: On 2023-09-08 11:47:56 +0200, Wojtek Kosior wrote: > Hello Josselin > > > wolf writes: > > > > > Hmm, but the recipe for the authenticate rule comes from the (possibly) > > > compromised source, no? So the attacker can just modify the recipe > > > instead of > > > the command going the authentication. Am I missing something? > > > > You can use a previously trusted guix to do the authentication. `make > > authenticate` is here for committers to check that their commits are all > > properly signed before pushing (it's used as a pre-push hook). > > From my understanding of the documentation, `make authenticate` is not > just for committers but for all people who do a `git pull` in Guix tree > and want to verify that the newly pulled commits do come from the > committers. It it is not the case, then the documentation should > probably be modified to make it clear. > > The recipe is not from an untrusted source mecause the Makefile is not > tracked by git. Rather, it gets generated when first building Guix. And > — as the documentation instructs — the initial checkout gets > authenticated with `guix git authenticate` rather than with `make > authenticate` so it can't get compromised that easily. If you've already authenticated the initial check-out, what is the point of `make authenticate` then? Maybe the manual isn't that clear, but as wolf points out `make authenticate` itself cannot be a guarantee as it requires trust in the Makefiles, creating a chicken-and-egg problem . > I mean, if make authenticate is just for the convenience of the committers, > then > this is completely fine. But the documentation does not currently read that > way. Yes, I believe this should then be clarified. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Building from git
Hi, wolf writes: > Hmm, but the recipe for the authenticate rule comes from the (possibly) > compromised source, no? So the attacker can just modify the recipe instead of > the command going the authentication. Am I missing something? You can use a previously trusted guix to do the authentication. `make authenticate` is here for committers to check that their commits are all properly signed before pushing (it's used as a pre-push hook). Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix pull speed
-- Simon Tournier writes: > Do it copy on the fly? I mean, is it first written somewhere then moved? It just copies the output of the building process, which shouldn't be too big. It's waiting for build output though, hence why it's taking so much time. >> It's building the same! Just that building the derivation takes way >> longer because it has first to load a bunch of uncompiled guile files. > > Well, I am not sure to follow. Is your point not about why it > takes longer? > > If it is the same, these 5 seconds is not why “guix pull” is slow, no? It's the same process, but in one case it's done with an already compiled tree, so loading the files is instantaneous, but on `guix pull` the tree is not compiled yet (that's the whole point of `guix pull`!) and so loading these 300+ guile files is extremely slow. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix pull speed
Hi Simon, Simon Tournier writes: > Hi Josselin, > > On Tue, 29 Aug 2023 at 13:58, Josselin Poiret wrote: > >> After looking a bit more into guix pull speed, or to be more precise the >> "Computing Guix derivation..." step, which is not substitutable. I've >> come to the conclusion that the thing that takes the majority of the >> time is loading the files that define the packages that the new Guix >> needs to build itself. > > Well, on my machine, the bigger bottleneck seems the procedure name > ’proxy’ which copies stuff around, IIUC. See [1]. Proxy is on the helper script side, it's just waiting for the actual build script to do its thing. >> These files are not compiled yet, and worse, >> loading just (gnu packages guile) ends up loading 361 other package >> files. You can generate a package graph in GraphML with `guix graph -t >> module -b graphml guile`, and use e.g. networkx to analyze it. > > Hum, is this ’graphml’ something you have not submitted? Or am I > missing a point? Last time I played with “guix graph”, I wrote a small > script for bridging with networkx. See [2]. I've committed it pretty recently, and should work OOTB now. >> You can compare with a compiled check-out of guix by just running the >> following in a `guix repl`: >> --8<---cut here---start->8--- >> (use-modules (guix self) (guix monad-repl)) >> ,run-in-store (guix-derivation (getcwd) "0.0-git" #:pull-version 1) >> --8<---cut here---end--->8--- >> which takes at most 5 seconds on my laptop. > > Yeah, that’s fast. :-) > > For comparing, what would be the corresponding derivations that “guix > pull” is building? It's building the same! Just that building the derivation takes way longer because it has first to load a bunch of uncompiled guile files. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
Hi Lily, Liliana Marie Prikler writes: > Instead, we have seen in this thread appeals to age, appeals to > perceived lack of personal benefit, and now appeals to typing effort, > none of which really make that great of an argument against the > ChangeLog style, especially when they come in combination with a > refusal to make use of already provided tools. I think we're starting > to see the moving of the goal post as the actual game here. This seems to me like an unwarranted accusation. The OP and numerous other users/contributors have reported that they have actual frustrations with the process here, and I don't think this is an healthy interaction. > Maybe it's time to take a step back and instead of asking “How can we > decrease the cognitive overhead for contributors?”, we should perhaps > ask “For which contributors do we want to/can we decrease the cognitive > overhead?” We have drifted much from the original post that discussed > moms with full-time jobs, who struggle to do “difficult” tasks > (simplified wording; may change the meaning of the OP a little). Now, > I personally struggle to see how your personal preference for > communication media, commit message style, and other things that were > discussed in any of the preceding threads actually correlate with being > a parent. However, I do know that with its 150 million users, most > people of the world don't have a Github account. Being one of the 4 > billion email users out there is a comparably low barrier of entry > imho. So, whose cognitive overhead do you want to reduce (besides the > obvious "my own", which everyone always tries)? We could try to time how long it takes to set up the email vs. forge workflow and do a first contribution, I can bet the former is much longer than the latter. Especially if your email host has funky authentication systems. I don't think the number of users of each system is a compelling argument either: you're not going to say that mowing your lawn with a knife is inherently better because more people have knives compared to lawnmowers. Regarding the “mom argument”, I would disagree and say that this is completely related: interruptions are more costly, you're more likely to have less attention span, and overall you probably don't want to commit to 20 steps just to send a contribution. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: 03/08: build: Add dependency on guix script for help2man targets.
Hi Maxim, Maxim Cournoyer writes: > This changes appears to break building my tree, like this: > > --8<---cut here---start->8--- > help2man: can't get `--help' info from guix home > Try `--no-discard-stderr' if option outputs to stderr > make[2]: [Makefile:7131 : doc/guix-home.1] Erreur 1 (ignorée) > --8<---cut here---end--->8--- > > It doesn't happen with 'make as-derivation' though, so it seems to have > to do with some shenanigan in my checkout. Any idea how I could fix my > checkout without running 'git clean -xfdd' ? I had the same issue in my local checkout, but it was because of another change I committed that was then reverted: it changed the ABI, and so a lot more files had to get recompiled. You can try to manually run `guix home --help` and see what the error is, if it's an ABI error I usually run `grep -Rl "" --include '*.go' . | xargs rm`. Best, -- Josselin Poiret signature.asc Description: PGP signature
Guix pull speed
Hi everyone, After looking a bit more into guix pull speed, or to be more precise the "Computing Guix derivation..." step, which is not substitutable. I've come to the conclusion that the thing that takes the majority of the time is loading the files that define the packages that the new Guix needs to build itself. These files are not compiled yet, and worse, loading just (gnu packages guile) ends up loading 361 other package files. You can generate a package graph in GraphML with `guix graph -t module -b graphml guile`, and use e.g. networkx to analyze it. You can compare with a compiled check-out of guix by just running the following in a `guix repl`: --8<---cut here---start->8--- (use-modules (guix self) (guix monad-repl)) ,run-in-store (guix-derivation (getcwd) "0.0-git" #:pull-version 1) --8<---cut here---end--->8--- which takes at most 5 seconds on my laptop. One idea I had was to move all the packages that are looked up in (guix self) to their own little bubble, to avoid having to load extra stuff. However, this is not currently possible because some of them do have non-trivial dependency graphs. I've identified these problematic inputs: guile-avahi guile-ssh guile-git guile-gnutls guix-daemon (it pulls in all other dependencies itself) po4a graphviz What could be done about this? Another solution would be to somehow build Guix without any of the dependencies and then add them in later, similar to what is done with build-aux/build-self.scm to be able to load (guix self) in the first place. That seems quite complex though. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
Hi everyone, Maxim Cournoyer writes: > Texinfo is mostly just plain text until you learn about a few decorators > :-). It gives us the info manuals that I find very nifty (it's like a > man page, but with hyperlinks and advanced navigation capabilities!) and > used across many GNU projects (e.g. coreutils, Emacs, Bash, GCC, GNU > Make, etc.) I see it as a strength more than a weakness for the > project. I agree with Maxim here, I think the texinfo markup is important to be able to generate such a nice manual: the Guix and Guile manuals are among the nicest to browse because of all the formatting that you have available, and the hyperlinks. I've also not had any issues adding stuff to the manual while not knowing anything about the format, just mimicking stuff found nearby. YMMV though, depending on what changes you might want to make. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
Hi everyone, Katherine Cox-Buday writes: > I have no love for Git's CLI (that's one of the reasons the email-based > workflow grates on me; I use magit for everything), but I found it > interesting that here you present a valid argument against having to > learn Git in one way, and elsewhere people are making arguments for > learning the git send-email command. I draw no conclusions from that, > but it caught my eye! > > FWIW, the git command you could use is: > > git log --grep=foo -- the/file/path.scm Just to add my 2 cents, any editor with decent support for git (eg. emacs with magit) will have git blame and git log for regions support baked in, I regularly use that to look at changes. I don't think I've ever used git grep with ChangeLog style commits. Sometimes I like reading commit explanations for complicated commits, but I feel like they're a bit orthogonal to the requirements that the ChangeLog format imposes on us. With the git tools we have, I'm not sure the ChangeLog format is really needed, it dates back to an era where they didn't exist. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Updates for Go
Hi Felix, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > From my experience of packaging Gocryptfs in Debian and here, perhaps > some reconsideration should be given to the widely unpopular idea of > using more package functions in Guix. Ending in asterisks, they would > allow packagers, and perhaps even automated tools, to select exactly > the particular versions or commits specified for each prerequisite in > go.mod. Package functions are really nice, but they don't mesh well with CLI usage, as well as CI: you'd need to also export a "default" version of each package for those two to work properly. Also, while having pinned versions of dependencies upstream seems like the consensus, I'm not sure we'd like doing that, be it for the exponential CI work that would be required. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: [bug#62047] [PATCH 0/2] '--with-input' & co. no longer replace hidden packages
Hi Greg, Greg Hogan writes: > This has broken, for example, building clang with a newer version of > gcc using package-input-rewriting/spec. What do you think of adding a > hidden? property to enable the old behavior? Since you're mentioning package-input-rewriting/spec, I assume you're doing this in Guile? If so, package-input-rewriting doesn't have that same behavior, and still replaces hidden packages! HTH, -- Josselin Poiret signature.asc Description: PGP signature
Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]
Hi everyone, Maxim Cournoyer writes: > I'm not a 'git log' expert myself, but intuitively like you, I'd expect > the --no-merges one to be useful to hide merge commits! The doc seems > to confirm that: > > --no-merges > Do not print commits with more than one parent. This is > exactly the same as --max-parents=1. > > Thanks for finding that option. I used these kinds of options for the last core-updates merge, and this one only hides the merge commits themselves, not the merged commits. For that, you need to use --first-parent. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Ideas for ocaml-team
Hi everyone, DABY-SEESARAM Arnaud writes: > Do you plan on including coq.scm in the upgrade plan, as it also depends > on dune? If so, would coq-packages also be upgraded, or should that be > done after the ocaml-team branch has been merged with master? > > Anyway, I am new to Guix, but will try to help if I can (time- and > competence-wise) ! :) I can also give a hand regarding Coq and libraries, since I have a vested interest in having everything up-to-date :) Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: 02/03: gnu: openblas: Update architectures we provide substitutes for.
Hi everyone, Efraim Flashner writes: > It seems I was wrong, changing the #:substitutable? flag _does_ change > the derivation of the package. Is this expected/something that should be fixed? It does seem to me that this shouldn't happen, but maybe there's a good reason for this behavior. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: qtbase 6.3.2 FTBFS
Hi Andreas, Andreas Enge writes: > on the lastest master commit, qtbase@6 is available as a substitute > (I did not check whether from berlin or bordeaux). Right, that's mostly why I was asking. It could be a transient failure as well, which should probably be fixed then (unless it's something like OOM). Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: qtbase 6.3.2 FTBFS
Hi Felix, Does this happen on master? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Should commit signing always be required for local work? [was Re: bug#63261: Recent changes to git config cause errors for non-committers]
Hi Maxim and Leo, Maxim Cournoyer writes: > Thanks for voicing your thoughts on this. I originally thought the > included fragments (via the 'include.path' git config option) could we > overridden by a user but it seems they can't, making the change more > intrusive than it should have been. Just FYI, it seems that it was possible to override that behavior by making sure the include was before the overriding gpgsign = false in the repo's .git/config. Still, it's probably best to let users judge what their workflow should be. I'm curious Leo, in general (not Guix because we have a pre-push hook), how do you make sure you always publish signed commits? I don't want to put unsigned commits anywhere except locally, but it feels like I might just forget to sign them before pushing. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: What's needed to get things building for i586-gnu (the hurd) post core-updates?
Hi Efraim, Efraim Flashner writes: > If all you need is to remove coreutils-boot0 from the origin then you > could create a similar boot0 package specifically for the hurd and make > the fix there, and then use the current package or your new one as an > input in later packages based on the architecture. Unfortunately, it is used in an origin snippet, and there you can't really case over the target system. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: What's needed to get things building for i586-gnu (the hurd) post core-updates?
Hi Ludo and Chris, Ludovic Courtès writes: > Hello! > > Probably the main issue is that childhurds now fail to boot: > > https://issues.guix.gnu.org/62307#23 > > We can still build “new” i586-gnu binaries on an “old” childhurd, of > course, but to me that’s doing that is less of a priority. [1] should fix this. We have at least three important failures regarding native compilation now: - coreutils doesn't build. This is because our bootstrap glibc doesn't contain all the kernel headers, and coreutils tries to use some of them directly. This should be fixable by adding an additional bootstrap input for the Hurd with the missing kernel sources, I'm trying to get one right now. While discussing with janneke, we also figured out that coreutils-boot0 was probably unneeded as it's only used to rm a file in an origin later on that could be removed with pure Guile. That would be a world rebuild though so let's leave that for later. - m4 and findutils both have some failing tests, and they seem to be crashing. I haven't investigated this yet. [1] https://issues.guix.gnu.org/63501 -- Josselin Poiret signature.asc Description: PGP signature
Small presentation from a new committer
Hello everyone, I'm happy to announce that as of today I have been granted commit access to the Guix repository! With this, I plan on helping push more contributions past the finish line, by reviewing and committing them whenever they are in good shape. My key's fingerprint is 3924 8CD8 41C6 3CC3 36DC AF2F 505E 40B9 1617 1A8A, and you can find it either at [1], attached here or on your favorite keyserver! You can find me on IRC (my nick is jpoiret), where I try to help people with any issues they might run into with Guix, or working on Guix core packages and internals. By day I'm also a mathematician working on type theory, proof assistants, logic and higher categories, and I happen to use Guix to work on Agda, although it hasn't caught on quite yet :) [1] https://jpoiret.xyz/jpoiret.pub See you soon, -- Josselin Poiret jpoiret.pub Description: My PGP key signature.asc Description: PGP signature
Re: Tooling for branch workflows
Hi Chris and Andreas, Christopher Baines writes: > I too would like to see improved tooling for managing changes. I've been > working on the qa-frontpage for smaller changes, but I think this can be > extended to large changes too. > > [...] > > This is something I'd like to see too. I've been thinking about this > already and want to spend more time working on at least making it easier > for more people to get involved. Let me know if you have any specific > requests! Maybe it would be a good time to create an infrastructure/CI team, and set some clear goals for it? I think it might motivate people (me included) to get more involved in GBC development if there is something to build towards. Also, I kind of agree with Andreas about the bus factor of Cuirass and GBC, and wonder whether it makes sense to duplicate development effort across both. It seems to me that Cuirass is working properly as a generic CI tool, but it's not super well adapted to Guix, something which the GBC seems to be much better at. Is replacing Cuirass by GBC on berlin for Guix CI something that is a future goal, or is it understood that Cuirass will be running there for the foreseeable future? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: evince: Is this a bug?
Hi Lars, Lars-Dominik Braun writes: > I’ve noticed this too with several GTK+ programs. The > problem seems to be that GDK_PIXBUF_MODULE_FILE is set to > /home//.config/guix/current/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache. > When I change it to refer to ~/.guix-profile instead it works. Not sure > how ~/.config/guix got in there though… You might need to explicitely add gdk-pixbuf to your profile, otherwise this environment variable is not set as you experienced. It should be propagated by enough packages to appear by itself, but that might not be true for everyone's choice of packages. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: bug#63267: gcc-toolchain is missing libstdc++.so
Hi Kaelyn, Kaelyn via Bug reports for GNU Guix writes: > Thanks! A small side note: I have glibc in there mainly so ldd is available > for debugging problems or getting new binaries working (I think the comment > with it is a remnant of an older version of the manifest from before "-F" was > added to "guix shell"). Small note: `ldd` is only a wrapper around setting `LD_TRACE_LOADED_OBJECTS=1`, so you don't really need to pull in all of glibc just for this. There's also LD_DEBUG with possible values explained by LD_DEBUG=help, which I use quite often. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: What's needed to get things building for i586-gnu (the hurd) post core-updates?
Hi Chris, Christopher Baines writes: > I think the use of coreutils-boot0 in the source for gcc-boot0 is a > problematic change introduced in core-updates [2], at least > coreutils-boot0 fails to build. Just to recap, as you mentioned on IRC, the coreutils configure phase seems to miss hurd.h, even though it is included in the bootstrap glibc. It might be due to the coreutils upgrade, since I don't see what else could've changed this derivation. I don't have a childhurd at the moment (because a cross-compiled Hurd fails to run), so I can't really test native compilation as above :( Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Help! Having troubles testing my generalization of home-redshift-service
Hi Gabriel, Gabriel Wicki writes: > Hi y'all! > > I've been working on a patch on generalizing the > home-redshift-service-type to also work under wayland. I've created the > following patch but am now running into difficulties testing it. > > I've created two minimalist system configurations (one for i3 and one > for sway) and run them like so: > $ $(./pre-inst-env guix system vm sys-i3-minimal.scm) > > In that VM i am unable to > $ guix home reconfigure my-config.scm > due to `home-night-time-service-type` allegedly being an "unbound > variable". Investigating with `guix repl` and just importing the > patched module I find a home-redshift-service-type but not my > home-night-time-service-type. > > Having never really hacked home services I am somewhat puzzled. It > certainly feels like I'm missing something essential here. > > Any ideas? The Guix that is included inside the `guix vm` corresponds to the guix package definition in guix, not the current guix checkout you're using! You could try to modify the guix-service-type's configuration to use (current-guix) instead, as done in gnu/system/install.scm. HTH, -- Josselin Poiret signature.asc Description: PGP signature
Re: proot-static build failures (master and core-updates)
Hi Ludo, Ludovic Courtès writes: > Josselin mentioned on IRC that they’d reported it upstream: > > https://github.com/proot-me/proot/issues/352 > > Do these tests reveal a real issue, or should we just skip them until a > fix lands upstream? From what I understand of the failing test it looks like an actual regression. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: [Rust Team] Status post core-updates merge
Hi Efraim (and the rest of the Rust team), Efraim Flashner writes: > Now that core-updates has been merged into master it's time for a status > update from the rust team. > > Currently rust supports (in the order of gaining support) x86_64, > aarch64 and riscv64. GDB-11 doesn't currently build on aarch64 or > riscv64, so we're removing gdb-11 entirely and using a new gdb-12 as > gdb/pinned for the test suite. This is expected to fix rust building on > aarch64. Is there any hope for the other architectures? I'm thinking i686 mostly, but s390x, powerpc and mips are all on the radar. > rust-bootstrap currently fails to build on riscv64. I've been testing > solutions by building on an x86_64 machine to see what builds pass and > what fails, and I think I've found a solution with minimal changes. > > Once I'm able to successfully build rust-bootstrap on x86_64 and riscv64 > I'll push the update to the rust-team branch and let the CI build it > out. > > As a quick overview, this push moves our rust package to rust-1.67 and > updates many of our rust packages. We've had some more unbundling of > bundled library sources and precompiled libraries and updated a number > of rust programs, mostly so they build with the newer version of rust. Very impressive! I only watch from afar and complain about the rust situation whenever I can, but this is giving me hope. With Rust getting further and further down into the dependency chain, this is vital work, and you all seem to be handling it very well. I'm also curious, since you're "early adopters": how are you managing with the team workflow? Any tips, remarks or impressions that you could share with other teams? Best, --- Josselin Poiret signature.asc Description: PGP signature
Re: `mumi send-email' means no more debbugs dance to send multiple patches
Hi Arun, Arun Isaac writes: > Could you link to the specific email message that you tried sending with > `mumi send-email'? Debbugs provides the complete email message in mbox > format. The email headers should have timestamps we can look at to > ascertain how long it took. I am hoping that this was a one-off spurious > delay somewhere in the email system. I would certainly encourage you to > try using `mumi send-email' again to see if the problem persists. If it > does, we should certainly try and do something about it. Thanks for looking into it. I have tried twice now, with the same issue both times, with [1] and [2]. [1] mid:cover.1682364024.git@jpoiret.xyz https://yhetil.org/guix/cover.1682364024.git@jpoiret.xyz/ [2] mid:cover.1682452738.git@jpoiret.xyz https://yhetil.org/guix/cover.1682452738.git@jpoiret.xyz/ Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: `mumi send-email' means no more debbugs dance to send multiple patches
Hi Arun, Arun Isaac writes: > Hi Josselin, > > Ouch! Unfortunately, timeouts can happen. I was just hoping it would be > unlikely. Did you wait out the full 15 retries of `mumi send-email'? Yes, I did wait until it completely timed out. > This is admittedly a somewhat fragile system, but it is the best we can > do considering debbugs' limitations. Given email's asynchronous store > and forward design and all the polling we do, a `mumi send-email' > timeout is possible. Do you think increasing the number of times `mumi > send-email' retries would help? Did the email you sent using `mumi > send-email' finally reach debbugs and the mumi server? How long did it > take? How long do your emails typically take to reach debbugs and the > mumi server? My mails usually take less that 30 seconds to get a reply from debbugs. I don't remember how long it took yesterday for the issue to appear on mumi though, but more than the 15 retries of mumi send-email (I manually checked). > Thanks for the feedback, and happy hacking! :-) Thanks for your tool! Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Setuid handling?
Hi Felix, Felix Lechner writes: > $ command -v su > /home/lechner/.guix-home/profile/bin/su This is the crux of the issue here, it should be /run/setuid-programs/su. Are you on Guix system? /run/setuid-programs/ should be at the top of your PATH. The default /etc/profile should ensure that, but if you do anything else with env variables it might get shadowed. I am not too sure of how guix home deals with this, you might have to dig deeper there. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Core-updates merge
Hi Andreas, Andreas Enge writes: > Hello all, > > I have just merged core-updates into master and deleted the branch! > This has been a long adventure, which became particularly intensive > after the last Guix Days in February. First and foremost many thanks to > everyone who contributed to the branch, be it by commits, discussions or > by working on the infrastructure. Great work and congrats! Thank you for taking care of this, especially with the time it took. Hopefully we'll never have to do this again :) > Each and every package is not yet in shape; please feel free to submit > patches for your favourite packages that fail to build. In particular: > - python-yubikey-manager does not build currently; work to correct this > is underway. > - R on powerpc does not build; this will also be corrected soon; > - aarch64 has very few substitutes; I think this is mainly due to the build > farm catching up and not so much to packages not building, but this is > difficult to know. The graphical installer is also broken, but that should be adressed by my recent patchset. > Every end of a story is the beginning of many new ones. Several areas of > work have already been identified; I will summarise what came up on the > mailing list and who expressed interest to work on it - please feel free > to join if a topic interests you, or launch another initiative if you > want to work on a different subject! > [...] I also want to add something to the list: working out how we can best implement the team-driven workflow. We're currently lacking a lot of documentation for it, and one thing I would really love to see is what each team's current goals are. Following the MLs/IRC is one thing, but not everyone is able to read up on everything. Should intra-team communication be on guix-devel for everyone to see? Should we display the teams on the website? How should we approach merging feature branches to master? Also, we have the new release on the horizon (I don't really remember how far in the future it is), so we could maybe try to create a calendar for it, and set team goals accordingly? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Setuid handling?
Hi, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Hi, > > After reconfiguring today (see below) I can no longer invoke a > familiar set of setuid executables: > > $ su - > su: Not setuid and you are not root, expect this to fail > root's password: > > $ mailq > mailq: need root privileges > > Has the handling for such executables changed? What is `command -v su`, and `ls /run/setuid-programs/`? Have you rebooted since reconfiguring? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: `mumi send-email' means no more debbugs dance to send multiple patches
Hi Arun, Arun Isaac writes: > Hi all, > > mumi, the software powering our debbugs frontend at > https://issues.guix.gnu.org/, now also comes with a command-line > interface. At the moment, the new command-line interface allows > searching for issues, and sending patches. Most notably, it frees us > from the debbugs dance required for sending multiple patches! > > To try it out, install mumi from the latest guix pull, perhaps using > `guix shell'. This looks great! Thank you so much for your work! I've just tried it out, but unfortunately mumi didn't receive the mail in time and it just timed out sending the replies :( is there anything that could be done on that front? Does mumi use IMAP IDLE? Best, -- Josselin Poiret signature.asc Description: PGP signature
[PATCH] gnu: python-shiboken-2: Do not rely on _Py_Mangle being available.
* gnu/packages/patches/python-shiboken-2-compat.patch: Fix the patch according
to upstream.
---
.../patches/python-shiboken-2-compat.patch| 29 +--
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/gnu/packages/patches/python-shiboken-2-compat.patch
b/gnu/packages/patches/python-shiboken-2-compat.patch
index 0c7de64395..48aa74173b 100644
--- a/gnu/packages/patches/python-shiboken-2-compat.patch
+++ b/gnu/packages/patches/python-shiboken-2-compat.patch
@@ -1,16 +1,15 @@
-Provide a declaration that's missing in Python 3.10.
+Backport a fix from 5.15.9, mentioned in [1].
pyside-setup-opensource-src-5.15.8/sources/shiboken2/libshiboken/sbkpython.h
2023-04-19 23:14:11.415337435 +0200
-+++
pyside-setup-opensource-src-5.15.8/sources/shiboken2/libshiboken/sbkpython.h
2023-04-19 23:18:09.055605606 +0200
-@@ -108,6 +108,11 @@ extern "C" {
- #if PY_MAJOR_VERSION >= 3
- #define IS_PY3K
-
-+extern "C" {
-+ /* In Python 3.10 this declaration is not provided by . */
-+ extern PyObject* _Py_Mangle(PyObject *p, PyObject *name);
-+}
-+
- #define PyInt_Type PyLong_Type
- #define PyInt_Check PyLong_Check
- #define PyInt_CheckExact PyLong_CheckExact
+[1] https://bugreports.qt.io/browse/PYSIDE-2176
+
+---
pyside-setup-opensource-src-5.15.8/sources/shiboken2/libshiboken/pep384impl.cpp
2023-04-24 11:05:48.770934499 +0200
pyside-setup-opensource-src-5.15.8/sources/shiboken2/libshiboken/pep384impl.cpp
2023-04-24 11:04:51.566943936 +0200
+@@ -751,7 +751,7 @@
+ #endif // IS_PY2
+ Shiboken::AutoDecRef privateobj(PyObject_GetAttr(
+ reinterpret_cast(Py_TYPE(self)),
Shiboken::PyMagicName::name()));
+-#ifndef Py_LIMITED_API
++#ifdef IS_PY2
+ return _Py_Mangle(privateobj, name);
+ #else
+ // PYSIDE-1436: _Py_Mangle is no longer exposed; implement it always.
base-commit: 827df9d1dde4f4a06e1789ec17cf0586602aa121
--
2.39.2
Re: Core-updates, the last metres
-- John Kehayias writes: > Hi Guillaume, > > On Sun, Apr 23, 2023 at 08:00 PM, Guillaume Le Vaillant wrote: >> Here are a few leaf packages that don't build because of some >> failing dependencies: >> - blender is blocked by opencolorio > > Not sure what is wrong here (error for a null pointer...) and it is > quite out of date. Looks like it'll need more than a quick fix to > update it, though admittedly I didn't try. Apparently fixed now! >> [...] >> - freecad is blocked by python-pyside-2 >> > > Didn't look much here yet, looks like part of the Python QT bindings > ecosystem. Maybe someone familiar with this can see a quick fix. I thought it would be an easy fix: Ludo fixed python-shiboken-2 previously but the fix is erroneous, see the following patch. However, I'm still getting a build error that boils down to the following: --8<---cut here---start->8--- import importlib importlib.machinery --8<---cut here---end--->8--- errors out with python-minimal@3.10, but not with python@3.10! I don't really understand how this could happen, does anyone have an idea? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: PSA for LUKS users
It would probably be doable to run a very small Linux EFI stub as a bootloader on x86, that way you can side-step the lacking grub support. Integrating it with Guix would surely be a bit harder though. kiasoc5 writes: > Argon2 support was slated to be in the next release of Grub (2.12) but > apparently this is not realistic: As for LUKS2 support in Grub, as long as you use PBKDF2 it should now be supported by HEAD. Best, -- Josselin Poiret signature.asc Description: PGP signature
[PATCH core-updates] gnu: python-pytest: Fix failing test_raising_repr.
* gnu/packages/patches/pytest-fix-unstrable-exception-test.patch: Add new patch from upstream. * gnu/packages/check.scm (python-pytest): Use it. * gnu/local.mk (dist_patch_DATA): Register it. --- Hey Andreas and Kaelyn, This should also fix it without bumping python-pytest to a new version (since it has so many dependents, don't want to introduce new breakage now). Best, Josselin gnu/local.mk | 1 + gnu/packages/check.scm| 3 +- .../pytest-fix-unstrable-exception-test.patch | 34 +++ 3 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/pytest-fix-unstrable-exception-test.patch diff --git a/gnu/local.mk b/gnu/local.mk index e29e09b688..73756a8c49 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -1730,6 +1730,7 @@ dist_patch_DATA = \ %D%/packages/patches/pybugz-stty.patch \ %D%/packages/patches/pygpgme-disable-problematic-tests.patch \ %D%/packages/patches/pyqt-configure.patch\ + %D%/packages/patches/pytest-fix-unstrable-exception-test.patch \ %D%/packages/patches/python-2-deterministic-build-info.patch \ %D%/packages/patches/python-2.7-adjust-tests.patch \ %D%/packages/patches/python-2.7-expat-compat.patch \ diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm index f388eb82a7..d072edbf51 100644 --- a/gnu/packages/check.scm +++ b/gnu/packages/check.scm @@ -1253,7 +1253,8 @@ (define-public python-pytest (uri (pypi-uri "pytest" version)) (sha256 (base32 - "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg" + "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg")) + (patches (search-patches "pytest-fix-unstrable-exception-test.patch" (build-system python-build-system) (arguments (list diff --git a/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch new file mode 100644 index 00..4d77786b77 --- /dev/null +++ b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch @@ -0,0 +1,34 @@ +From b55e264a675f7621b8351e227b93742f19e01c7d Mon Sep 17 00:00:00 2001 +From: Daniel Valenzuela +Date: Wed, 9 Nov 2022 19:43:10 -0300 +Subject: [PATCH] Fix test_raising_repr test + +Closes #10473 + +Python <3.11 versions depend on `exceptiongroup>=1.0.0rc8`, and they released version `1.0.1` +6 days ago (2022/11/03) that as a side-effect changed the output of exceptions. +--- + testing/test_assertion.py | 10 +- + 1 file changed, 1 insertion(+), 9 deletions(-) + +diff --git a/testing/test_assertion.py b/testing/test_assertion.py +index d8844f2e41..7574592210 100644 +--- a/testing/test_assertion.py b/testing/test_assertion.py +@@ -1664,15 +1664,7 @@ def test_raising_repr(): + """ + ) + result = pytester.runpytest() +-if sys.version_info >= (3, 11): +-# python 3.11 has native support for un-str-able exceptions +-result.stdout.fnmatch_lines( +-["E AssertionError: "] +-) +-else: +-result.stdout.fnmatch_lines( +-["E AssertionError: "] +-) ++result.stdout.fnmatch_lines(["E AssertionError: "]) + + + def test_issue_1944(pytester: Pytester) -> None: base-commit: 7ccf9943029747d4ba97160214f895b365511278 -- 2.39.2
Re: A Joyous Core-Updates Week-End
Hi John, John Kehayias writes: > Question on procedure: are we going to be posting every patch to guix-patches > and waiting > for QA to build? Or only for not trivial (whatever that means) patches? I > guess I'm asking > if this will be a sort of sprint weekend and larger changes/cleanup in the > aftermath? This > depends on context of course, but in light of recent discussions on patch > pushing, QA, and > teams (that I need to catch up on) I wanted to see what we were doing here. Good question. My personal opinion on this is that fixes for dependencies that impact multiple packages could be reviewed on the spot while leaf packages could wait until later. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: staging merge into master
Hi Maxim, Maxim Cournoyer writes: > Hello, > > I'm planning to merge staging into master soon (tomorrow or friday), > unless someone has a problem with it. It includes at least two CVE > fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg, > qt 5, python-cryptography and a few others, and seems to be close to > master in terms of coverage (currently 68% for staging vs 73% for > master, according to https://ci.guix.gnu.org/). > > I was able to reconfigure my system with it, and haven't seen issues so > far. Testing welcome! I'm a bit conflicted on this one, as: + this could let us get rid of staging as well! + this might fix some build issues and package errors on core-updates (as well as fix CVEs!) - this might create some build issues and package errors on core-updates - we might not have time for a full CI run on core-updates before this week-end. I don't have a particularly strong opinion either way, but if you do merge it, could you make sure to also merge master into c-u and launch a CI evaluation right afterwards? Thanks for taking care of staging! Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: rrdtool hash mismatch
Hi, Aleksandr Vityazev writes: > Hi, > > rrdtool package has not been updated for several years and according to > ci.guix.gnu.org builds normally, but if you run: > > ./pre-inst-env guix build --no-substitutes --check --no-grafts rrdtool > > it outputs an error > sha256 hash mismatch for > /gnu/store/icyq4d3fsbbf2yw3dmg7cxgb05qzfd3q-rrdtool-1.7.2.tar.gz: > expected hash: 1nsqra0g2nja19akmf9x5y9hhgc35ml3w9dcdz2ayz7zgvmzmm6d1 > actual hash: 029r3h7l06m3sy9q0hr2krvinhzkqvyl14wj7qjck79bm7rdvp48 > > which looks strange to me. Maybe it's not, but I haven't figured out > why? The upstream-provided tarball has probably been changed on the server without a version bump. The reason why you can still use it with substitutes is that Guix just uses the version that's built with the old tarball because we know its hash. When you try to download it from upstream, Guix rightfully complains that the hash has changed and refuses to go forward! Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: i686 core-updates failure.
Hi Kaelyn, Kaelyn writes: > I call the dependency chain odd in that pulseaudio--which is near the heart > of a lot of Linux software that supports audio--is failing because > inkscape--a graphical vector editor--is a dependency of a tool designed to > extract API documentation from source code. I agree that this is quite a "heavy" dependency chain for pulseaudio, but this is also the case for most programs which produce documentation. In the end, they also don't retain references to inkscape, so once they're built on CI, anyone using substitutes wouldn't need to download all of that part of the dependency chain. Best, -- Josselin Poiret signature.asc Description: PGP signature
[PATCH] WIP upgrade qt 6 to 6.5.0
---
gnu/packages/qt.scm | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index acf2d70736..46fbdb2368 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -68,6 +68,7 @@ (define-module (gnu packages qt)
#:use-module (gnu packages cmake)
#:use-module (gnu packages compression)
#:use-module (gnu packages cpp)
+ #:use-module (gnu packages crypto)
#:use-module (gnu packages cups)
#:use-module (gnu packages curl)
#:use-module (gnu packages databases)
@@ -593,29 +594,28 @@ (define-public qtbase-5
(define-public qtbase
(package/inherit qtbase-5
(name "qtbase")
-(version "6.3.2")
+(version "6.5.0")
(source (origin
(inherit (package-source qtbase-5))
(uri (qt-urls name version))
(sha256
(base32
-"19m9r8sf9mvyrwipn44if3nhding4ljys2mwf04b7dkhz16vlabr"))
+"1vzmxak112llvnx9rdgss99i9bc88rzsaxn59wdyqr5y9xxsmqgx"))
(modules '((guix build utils)))
(snippet
;; corelib uses bundled harfbuzz, md4, md5, sha3
'(with-directory-excursion "src/3rdparty"
(for-each delete-file-recursively
-;; The bundled pcre2 copy is kept, as its headers
-;; are required by some internal bootstrap target
-;; used for the tools.
-(list "double-conversion" "freetype" "harfbuzz-ng"
- "libpng" "libjpeg" "sqlite" "xcb"
"zlib"))
+(list "blake2" "double-conversion" "freetype"
+ "harfbuzz-ng" "libpng" "libjpeg" "pcre2"
+ "sqlite" "xcb" "zlib"))
(build-system cmake-build-system)
(arguments
(substitute-keyword-arguments (package-arguments qtbase-5)
((#:configure-flags _ ''())
`(let ((out (assoc-ref %outputs "out")))
- (list "-DQT_BUILD_TESTS=ON"
+ (list "-GNinja"
+ "-DQT_BUILD_TESTS=ON"
(string-append "-DINSTALL_ARCHDATADIR=" out "/lib/qt6")
(string-append "-DINSTALL_DATADIR=" out "/share/qt6")
(string-append "-DINSTALL_DOCDIR=" out "/share/doc/qt6")
@@ -759,9 +759,6 @@ (define-public qtbase
;; The 'tst_qfilesystemwatcher' installs a watcher on
;; '/home', which doesn't exist in the build container.
"tst_qfilesystemwatcher"
- ;; Not all of the tested formats are supported by our
- ;; build of openssl; 871 passed, 122 failed.
- "tst_qsslkey"
;; The 'mockplugins' test fail following error: "Unknown
;; platform linux-g++", and the other plugin tests
;; depend on it.
@@ -848,14 +845,21 @@ (define-public qtbase
'("device_config.prf" "moc.prf"
"qt_build_config.prf"
"qt_config.prf"))
(("\\$\\$\\[QT_HOST_DATA/get\\]") archdata)
-(("\\$\\$\\[QT_HOST_DATA/src\\]") archdata)
+(("\\$\\$\\[QT_HOST_DATA/src\\]") archdata)
+(replace 'build
+ (lambda* _
+(invoke "cmake" "--build" ".")))
+(replace 'install
+ (lambda* _
+(invoke "cmake" "--install" ".")))
(native-inputs
(modify-inputs (package-native-inputs qtbase-5)
- (prepend wayland-protocols
+ (prepend ninja
+wayland-protocols
xvfb-run)))
(inputs
(modify-inputs (package-inputs qtbase-5)
- (prepend bash-minimal coreutils-minimal libxcb md4c)
+ (prepend bash-minimal coreutils-minimal libb2 libxcb md4c)
(replace "postgresql" postgresql))) ;use latest postgresql
(native-search-paths
(list (search-path-specification
base-commit: ac8b2a0469a4884353ac5c0f0854012da0b04fda
--
2.39.2
Re: [core-updates] qtbase 6 ssl tests fail.
Hi Ricardo, I see you've fixed this by disabling the qssl tests, however I think this is a shortcoming on our part. Qt 6.4 has a fix for this, so I wanted to upgrade our Qt to 6.5.0. Upstream only supports the Ninja CMake generator, so I also adapted the package definition to it. One issue is that one file takes 4G of RAM to build on my computer, and so gets terminated on a parallel build. What would be the usual policy with such a problem? Disabling parallel builds for Qt 6 would massively slow the whole build, so I'm not sure this is a solution either. Here's the patch I have for now. Best, -- Josselin Poiret signature.asc Description: PGP signature
A Joyous Core-Updates Week-End
Hello everyone, It's that time of the year again! Merging core-updates! Do you *want* glibc 2.35, gcc 11 as default, mesa 22, python 3.10, and more?! Here's your chance! What is core-updates you ask? It's the big branch where all changes that affect significant parts of the dependency graph are pushed, to avoid world rebuilds, and also to test them out. This branch is then merged back into the main one periodically, and of course, this is never painless, as upgrading important dependencies like glibc or gcc are going to cause issues. Note that this workflow might change in the near future though, see [1]. Some people have been hard at work fixing most of the build issues, and we have most of the big changes sorted out now. However, it's impossible for the usual suspects to cover every single package, so we would like to ask the wider community for their help with the merge. Anyone can help, and in various ways (you don't need to know how to code in Guile!). This week-end (15–16 April), let's get everyone together and work on core-updates! Here's what you can do to help: 1) Use `guix time-machine` to test out your packages. If you have a package manifest lying around (you can get one out of your profile by using `guix package --export-manifest`), you can see which packages are available by doing `guix time-machine --branch=core-updates -- weather -m MANIFEST.SCM`! You can also test the packages themselves by doing `guix time-machine --branch=core-updates -- shell YOUR-PACKAGE`, at which point you'll be in a shell with the new package available. You can then try it out to see if it works properly! 2) Hack on `core-updates`. This is better to do beforehand: add a new worktree for core-updates (you don't want to prune all of the .go files when switching between master and core-updates, don't you?) using `git worktree add ../core-updates/ core-updates`. You can then enter that directory and follow the instructions from the manual, at "(guix)Building from Git". You will have a checkout ready to work on core-updates! You can then try to build your manifest from the checkout and see if everything builds, and try fixing the ones that don't. 3) Hang out on #guix and on the MLs. Follow what fellow members of the community are doing and struggling with, cheer them on and/or offer them your assistance! Feel free to reply to this if you have any questions about the process, or with your attempts, struggles and successes! See you this week-end. [1] https://gitlab.com/pjotrp/guix-days-fosdem-2023/-/blob/main/releases-branches.txt Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: [core-updates] qtbase 6 ssl tests fail.
Hi again Ricardo, I just saw that you disabled these tests with 03580b5f1d997df066a5119cf0a242f827354ba8, by saying that not all key types are supported by our build of OpenSSL. Wouldn't this be an issue on our part, especially if Qt expects these to be available? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: [core-updates] qtbase 6 ssl tests fail.
Hi Ricardo, Ricardo Wurmus writes: > Hi Guix, > > on core-updates qtbase 6.3 fails its test suite. > > The tst_QSslKey group of tests has 122 failures that all look like > this: > > FAIL! : tst_QSslKey::passphraseChecks(DES) '!key.isNull()' returned FALSE. () >Loc: > [/tmp/guix-build-qtbase-6.3.2.drv-0/qtbase-everywhere-src-6.3.2/tests/auto/network/ssl/qsslkey/tst_qsslkey.cpp(626)] > > The tst_QSslKey failures are the only tests that fail. > > I’m currently working on upgrading linphone-desktop (I’ve upgraded all > its dependencies already, but haven’t pushed them yet) and the current > version needs Qt 6. > > Is anyone of you working on Qt 6 on core-updates? I also got bitten by this when building my own package manifest (for qpwgraph). The fact that it needs quite a lot of time was quite discouraging so I just abandoned the idea of doing it myself. I might revisit it by just building in a `guix shell -C` instead. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Building more of ‘core-updates’ on ci.guix
Hi Andreas and everyone, Andreas Enge writes: > Ludovic and Chris have corrected a problem in dune.scm in commit >01d9859821c5df6cc76c59e48fddd3c8cfa88ff0 > Now all of core-updates is being built, and the dashboard is back. > Thanks a lot! > > This means that people can now work on repairing their favourite missing > package, while having substitutes available from berlin (there are also > some on bordeaux). Should we organize a code sprint soon to bring the community together and try and get this finally merged? I can take care of sending a mail to guix-devel, as long as we have enough helping hands for the fateful day(s). If so, would next week-end (15-16 april) work? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging
Hi Andreas, Andreas Enge writes: > Am Fri, Apr 07, 2023 at 05:24:41PM -0400 schrieb Maxim Cournoyer: >> Reviewing the list of newly broken things, there was a flaky test spot >> in python-pyopenssl (IIRC!) that led me to attempt to upgrade >> python-cryptography, which is a bit more involved than I'd like. > > Okay, so I cherry-picked your staging commits for extra-cmake-modules > and kcodecs to core-updates, which should bring us further in building KDE > (once gtk+ is sorted out). Is gtk+@3 not sorted out? I have it built on my machine. gtk@4 is also available from bordeaux. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Time travel accident
Hi Konrad, Konrad Hinsen writes: > I guess there is nothing we can do retroactively to fix this, but can we > do something to prevent such issues in the future? > > One idea is to allow disabling tests at the command line. I'd then run > "guix build" for that specific package with tests disabled, and > continue. That should be doable with a suitable package transformation. We have --without-tests=package already, see --help-transform for all available package transformations. The one annoying thing is that disabling tests will change the derivation and you thus will not recover the same store item (it might be bit-for-bit equivalent, but its path will not be the same), preventing you from using substitutes either. Though, I'm not sure it will help you here because openssl is built as part of the `guix time-machine`'s build process, which afaik cannot be transformed. By the way, we can also "fix the past" by using guix/quirks.scm. Since that version of openssl doesn't build anymore, I wonder if we could just change its derivation retroactively to at least make it build. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: [core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)
Hi everyone, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Hi Leo, > > On Tue, Apr 4, 2023 at 7:49 PM Leo Famulari wrote: >> >> See <https://issues.guix.gnu.org/issue/49817>, which was never applied >> anywhere. > > According to the Debian Bug for this issue [1] the upstream commit > with the fix is here. [2] > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991496#5 > [2] > https://github.com/libsndfile/libsndfile/commit/deb669ee8be55a94565f6f8a6b60890c2e7c6f32 > >> I guess it's enough to update libsndfile to 1.1.0 on core-updates. > > The upstream commit [2] shows that the issue was fixed in libsndfile's > master branch as part of their merge request #713, which made it into > these versions: > > 1.2.0 > 1.1.0 > 1.1.0beta2 > 1.1.0beta1 > > It may therefore be better to upgrade directly to 1.2.0, except I > think there was an understanding that no new features should be > allowed on our core-updates branch at this time. > > In that context, I will mention that Repology shows Guix as shipping a > defective version [3] while NIST scored the vulnerability as "8.8 > HIGH" [4] although we seem to have company. > > Kind regards > Felix Lechner > > [3] https://repology.org/project/libsndfile/versions > [4] https://nvd.nist.gov/vuln/detail/CVE-2021-3246 Maybe we could graft it on master, and ungraft it after core-updates has been merged? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Syntax and gexp for ff5f34ae757d709987896d6164bf125319a0f764
Hi Leo and Andreas, Leo Famulari writes: > On Thu, Mar 30, 2023 at 08:49:43PM +0200, Josselin Poiret wrote: >> Usually errors which involve # somewhere are caused >> by stale .go files (guile doesn't know how to recompile dependent .scm >> files). I would suggest a good old `grep -Rl --include '*.go' >> perl-extutils-pkgconfig ./gnu | xargs rm`. > > I saw this error too, but it went away after `make clean-go && make`. Don't want to praise myself too much, but the above command should only delete .go files which contain references to perl-extutils-pkgconfig, thus avoiding a rebuild of all go files! Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Syntax and gexp for ff5f34ae757d709987896d6164bf125319a0f764
Hi Maxim, Maxim Cournoyer writes: > I've seen this too, but it disappears if you byte-compile the project. > I'm not sure what that means, although it does seems sub-optimal that we > rely on byte-compilation for the code to evaluate correctly. The problem actually comes from stale byte-compiled files. If you were to interpret everything, it would work properly. The issue is when a variable becomes a syntax-transformer, ie. a macro: then it should get expanded at compile-time, but guile doesn't recompile dependents (because it doesn't know about them). Hence, in dependent .go files, the variable didn't get expanded, and is then used at runtime, hence the error. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Syntax and gexp for ff5f34ae757d709987896d6164bf125319a0f764
Hi Andreas,
Andreas Enge writes:
> Hello,
>
> it looks as if commit ff5f34ae757d709987896d6164bf125319a0f764 breaks
> building of at least one package, perl-gd, depending on
> perl-extutils-pkgconfig.
>
> The latter is now defined as
> (define-syntax perl-extutils-pkgconfig
> (identifier-syntax (perl-extutils-pkgconfig-for-target
> (%current-target-system
> which apparently does not play well with what is written in the former as
> (native-inputs
> (list perl-extutils-pkgconfig)) :
> guix package: error: gnu/packages/gd.scm:103:2: package `perl-gd@2.73' has an
> invalid input: ("_" #)
Usually errors which involve # somewhere are caused
by stale .go files (guile doesn't know how to recompile dependent .scm
files). I would suggest a good old `grep -Rl --include '*.go'
perl-extutils-pkgconfig ./gnu | xargs rm`.
Best,
--
Josselin Poiret
signature.asc
Description: PGP signature
Re: A friendlier API for operating-system declarations
Hi Edouard, Edouard Klein writes: > #+begin_src scheme > (-> > (minimal-ovh "ssh-rsa AAASomethingSomething== root@minimal-ovh") > (http-static-content "sub2.example.com" #:to-dir "/srv/sub2") > (http-static-content "sub1.example.com" #:to-dir "/srv/sub1/") > (add-services my-db)) > #+end_src > > The code of the function is on my channel: > https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm > > After a few months of experience, and positive feedback from my clients, > my question to you guys is: would you be interested in mainlining this, > or should I keep my development efforts separate in my channel ? I am quite in favor of using operating-system transformations rather than inheritance, because they're composable! This could be leveraged to get a nice CLI API as well. > I do think this API is easier than manipulating services, and although > extendable services are awesome and a very nifty piece of engineering, > they require quite a good knowledge of scheme and take a while to be > used to, while this new API, while way less powerful, lowers the barrier > to entry for newcomers. By this, do you mean that there's no way with your syntax to modify a given service? Is there a reason for this? It does seem to me that it could probably be done. > They are an easy way to maintain a declarative whole operating system > configuration, with a syntax similar enough to docker and ansible that > sysadmins familiar with it can quickly get up and running, thus exposing > more people to Guix. > > What do you think ? You've got me interested :) especially since you already have customer feedback! Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: more package transformations: overrides
Hi Ricardo, Ricardo Wurmus writes: > Hi Guix, > > when using package transformations the command line can become crowded > very quickly. Sometimes I would like to be able to provide a file > containing a set of alternative packages that are used recursively in > the package dependency graph, as some sort of override. Seems like a good idea! Cc'ing Sarthak as they might be also interested in implementing this, as a good first experience with package transformations. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Interest in Participating for GSoC '23
Hi Sarthak, Just chiming in on one of your questions. Sarthak Shah writes: > Hi Ludovic, > Thank you for your suggestions! > I've decided to focus on parameterized packages for my GSoC Application. > Owing to mid semester exams, I have not been able to contribute much to > Guix up until recently, and as such my only contributions are a simple > patch and two packages. I am currently in the process of working on a > script similar to NixOS' command-not-found that relies on guix index (which > is yet to be merged). > I have four questions with regards to my application and I'd appreciate > answers from individuals in the mailing list; > 1. Are there any specific issues I could work on to develop a better > understanding of package transformations and also prove my skills I think the issue mentioned in the last message at [1] could be a good start, though it may require some knowledge of Guix, mostly through its G-Expressions! You would have to extend the transformation to consider the case where the source is not a directory. > 2. What is expected from a project proposal > 3. Is there a soft deadline for submitting the draft proposal > 4. Would anyone here be interested in co-mentoring this project I unfortunately don't think I can co-mentor the project, but I'll always be happy to answer questions whenever I'm available :) [1] https://issues.guix.gnu.org/61684#16 Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Gnome dans core-updates
Hi Andreas, Andreas Enge writes: > Ah, it makes me super nervous. I now did for the first time ever... > There were a few problems with openjdk, where the automatic merge took > the wrong things from core-updates, instead of from master; hopefully > I worked it out correctly. At worst, we can always revert... Thanks for taking care of it! I should've also told you I ended up fixing a couple of things locally for qemu-minimal to build (since I was working on the Hurd and disk images). I also fixed u-boot-tools not building on Python 3.10 (even though it's a swig bug that is fixed in newer releases, but updating swig would cause a world rebuild). Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Gnome dans core-updates
Hi Andreas, Andreas Enge writes: > Am Sun, Mar 19, 2023 at 10:20:27AM +0100 schrieb Josselin Poiret: >> The project does seem functional, they just seem to not care about >> making new releases, since they direct users to official builds of HEAD >> [1]. Maybe we could just point there as well? >> [1] https://github.com/ipxe/ipxe/discussions/679 > > Well, I am loath to this attitude "just take the latest master", and it is > not what we normally do. A software writer cannot expect distros (nor end > users, as they seem to prefer) to follow each and every of their commits. > And it does not reflect well on their quality assurance processes if they > are unable to single out a commit from time to time that has undergone more > thorough scrutiny. > > That said, if just backporting one fix does not solve the problem, we may > have to go this route... I agree with you, but given that upstream has already closed a discussion on this topic with a clear stance, I don't really want to re-open anything. We could go with that solution for now? -- Josselin Poiret signature.asc Description: PGP signature
Re: Gnome dans core-updates
Hi Andreas, Andreas Enge writes: > This looks like >https://github.com/ipxe/ipxe/issues/359 > And has apparently been fixed following a different issue related to > ARM assembly (?!): >https://github.com/ipxe/ipxe/pull/373 > > The project has had its latest release in December 2020, with more > than 400 commits since then. Difficult to assert that the release is > actually functional! Does it have to be a transitive input of gnome? > And a help-guix question: How do I retrace the part of the dependency > graph that links ipxe-qemu to gnome? The project does seem functional, they just seem to not care about making new releases, since they direct users to official builds of HEAD [1]. Maybe we could just point there as well? [1] https://github.com/ipxe/ipxe/discussions/679 Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Core-updates and cross-compilation
-- Andreas Enge writes: > Hello, > > Am Sat, Mar 11, 2023 at 01:56:27PM +0100 schrieb Josselin Poiret: >> I've been looking at the state of most failures for the CI jobset for >> core-updates, and we have a couple of problems: >> - gcc < 9 and gcc == 12 never cross-compile. >> - we can't build the cross toolchain for the hurd, because the glibc >> upgrade to 2.35 would require newer gnumach headers > > are these new issues compared to master? There we also have gcc@9 and @12, > so my guess would be no, at least for the first one. The first one no, the second one yes. >> Should we consider these blockers for a core-updates merge? > > If the situation is not worse than on master, my answer will be a firm "no". > Otherwise I am less sure. I think we might still want to merge core-updates > first and handle these cross compilation issues in a later feature branch > of the core team. I'm working on building Hurd atm, and it's been taking longer than I would've liked. We needed an update to mig, which cascaded into updates to gnumach and hurd, but they also shouldn't be too recent as we'd need a newer libc. I thought the git tags in the repos would be a safe bet, but they don't build by themselves, and lots of patches need to be backported as well :) maybe after this upgrade is over we could offer some help with releases/CI. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: State of core-updates
Hi Andreas, Roman Scherer writes: > Hi Andreas, > > could we please add the jemalloc package that supports transparent huge > page sizes on aarch64 (which is currently waiting in core-updates) to > this list? At the moment any substitute which involves jemalloc isn't > useable on Linux kernels with a page size > 4K and requires building the > whole rust chain to Icecat working. Since jemalloc is indeed a dependency of icecat, it would also get built by the CI job if the latter is added. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Caching test results separately?
Hi, "Dr. Arne Babenhauserheide" writes: > Hi, > > A large part of the build time is being consumed by tests … could we > separate those phases so a package whose tests succeeded once does not > have to be rebuild just because its package got garbage collected? > > (⇒ keep the test result (boolean) longer than the build result) > > Keeping just a boolean that says whether the tests for a given hash > succeeded could make that pretty cheap and it could avoid half the build > time for packages that got garbage collected before. As it stands it's really not possible, as 1) testing is part of the build process itself and 2) we can't look-up any stateful info like this from the building process (of course!) But I would really like for tests to move out of build phases, the advantages would be twofold: less build time for a lot of packages, and better environment management for tests (we could rely on better interaction with other packages, more complicated mocking, use linux namespaces to their fullest extent, etc.). That would require a huge change to Guix though, so it's more of a dream than anything concrete. Best, -- Josselin Poiret signature.asc Description: PGP signature
