version-1.4.0 branch merged into master and removed (for now)
Hello gentlefolks, As you may have noticed, the version-1.4.0 that underwent a world rebuild to fix a flaw in the sitecustomize.py has now been merged into master. Since there appears to be some more fixes needing to come to master for other some architectures before we can issue our first RC, I propose that we work directly on stabilizing master for now. I've deleted the version-1.4.0 branch for now to avoid any confusion. When the moment is ripe for our first RC, I'll recreated the version-1.4.0 branch. Thank you! Maxim
Re: version-1.4.0 branch updated
Hello again! Chris Marusich writes: [...] > On aarch64-linux, on master, bug 52943 prevents the "guix" package from > building successfully. I've committed a fix for this on the master > branch in commit 24c3485bb3ffc05e687ef6513ac287b8d3048bab. However, I > haven't yet updated the "guix" package, since Ludo mentioned here that > he wanted to update the "guix" package to include a different fix (for > bug 52752), but I'm not sure that he's done that yet: > > https://issues.guix.gnu.org/52752#2 It seems there may be more to fix for Guix to build on i686, according to the above (Denis reported 3 failures in their latest attempt). > I figured we could coordinate and update the "guix" package at the right > time, all at once. Sounds like a good idea! > It would be good to ensure that the "guix" package builds successfully > on aarch64-linux for the 1.4.0 release. Therefore, I'd like to get the > fix for 52943 included in the version-1.4.0 branch, but I don't want to > step on anyone's toes. What can I do to get the fix included in the > release? There have been many smaller integration fixes coming after the version-1.4.0 merge of today; I guess we should recreate the version-1.4.0 when we deem we're ready for an RC or when the need arises. I've deleted it now to avoid confusion, and will diffuse a message about it on guix-devel. We can work on stabilizing master some more while also getting the dist machinery ready. I guess when the times come ripe for the first RC we can recreate the release branch. Thanks, Maxim
Re: Release v1.4 (or 2.0): process and schedule ?
Hi Chris, Chris Marusich writes: [...] > With Ludo's feedback, I was able to fix 52940 without rebuilding the > world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master. Can > you try merging master into your version-1.4.0 branch? Awesome! As you may have noticed, today version-1.4.0 was merged back into master. > At this point in time, I'm unaware of any issues that would be > show-stoppers for for powerpc64le-linux. As a reminder, issues > important to powerpc64le-linux can be seen by searching for issues > tagged with the "guix" user's powerpc64le-linux Debbugs usertag: > > https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix > > I'll keep my eye out for other potential powerpc64le-linux issues and > see what I can do to help in the days/weeks to come. Thanks for keeping these powerpc64le issues in check! Cheers, Maxim
Re: Celebrating ten years of Guix
Hello, Pjotr Prins writes: > On Wed, Jan 12, 2022 at 03:27:32PM +0100, Ludovic Courtès wrote: >> Hello Guix! >> >> This year marks the tenth anniversary of Guix; what if we used that as a >> pretext to join forces and organize “special events” throughout the >> year? Obviously the Guix Days are already a great start! Good idea! Perhaps we could sprinkle ad-hoc presentations on topics of interest throughout the year. I'm not that much of a presentation person, but it seems it'd liven the year which will probably see us more contained than we'd like. Maxim
Re: WARNING: Git merges are tricky. Rebasing is better?
Leo Famulari writes: > On Mon, Jan 17, 2022 at 05:26:08PM -0500, Kyle Meyer wrote: >> Fwiw I don't think Git automatically resolved that conflict: >> >> $ git checkout 276f40fdc349d2ad62582b23ea55e061b689cfc0^ >> $ git merge 276f40fdc349d2ad62582b23ea55e061b689cfc0^2 > [...] >> ++<<< HEAD >>+"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs")) >>+ (patches >>+ (search-patches >> "epiphany-update-libportal-usage.patch" >> ++||| d91de53caa >> ++ >> "0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs" >> ++ >> ++=== >> + >> "0k7b22zq3z1kllzqxgwsvwb1lp0j6rjb3k1hvhna3i573wc4mpji" >> + >> ++>>> 276f40fdc349d2ad62582b23ea55e061b689cfc0^2 > > So, you think it was a mistake made when resolving conflicts by hand? I > can certainly understand that. Yes. > Either way, it's bad that the Git history doesn't show these types of > changes. Right, inspecting merge results can be confusing. By default that change is pruned from diffs as "uninteresting" because the merge result matched the content in one of the parents (discussed in the "COMBINED DIFF FORMAT" section of git-diff's manpage and the --diff-merges description of git-show's manpage). $ git show 276f40fd | grep 0r7m34xzz $ git show --diff-merges=combined 276f40fd | grep 0r7m34xzz +"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
Re: WARNING: Git merges are tricky. Rebasing is better?
On Mon, Jan 17, 2022 at 05:26:08PM -0500, Kyle Meyer wrote: > Fwiw I don't think Git automatically resolved that conflict: > > $ git checkout 276f40fdc349d2ad62582b23ea55e061b689cfc0^ > $ git merge 276f40fdc349d2ad62582b23ea55e061b689cfc0^2 [...] > ++<<< HEAD >+"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs")) >+ (patches >+ (search-patches "epiphany-update-libportal-usage.patch" > ++||| d91de53caa > ++"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs" > ++ > ++=== > + "0k7b22zq3z1kllzqxgwsvwb1lp0j6rjb3k1hvhna3i573wc4mpji" > + > ++>>> 276f40fdc349d2ad62582b23ea55e061b689cfc0^2 So, you think it was a mistake made when resolving conflicts by hand? I can certainly understand that. Either way, it's bad that the Git history doesn't show these types of changes.
Re: WARNING: Git merges are tricky. Rebasing is better?
Leo Famulari writes:
> --
> $ git show 276f40fdc349d2ad62582b23ea55e061b689cfc0:gnu/packages/gnome.scm |
> grep "define-public epiphany" -A11
> (define-public epiphany
> (package
> (name "epiphany")
> (version "41.2")
> (source (origin
> (method url-fetch)
> (uri (string-append "mirror://gnome/sources/epiphany/"
> (version-major version) "/"
> "epiphany-" version ".tar.xz"))
> (sha256
>(base32
> "0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
> -- ^
> *This is the hash of Epiphany 40.3, the old version!*
>
> Git's automatic merge conflict resolution algorithm did the wrong thing
> here. And Git does not show the reversion in `git log`, hiding it from
> review.
>
> My guess is that commit f7afefba0 ("gnu: epiphany: Fix build with
> libportal-0.5."), which happened on the master branch while the
> version-1.4.0 branch was forked off, made Git think that this line was
> more "up to date" on master than on version-1.4.0, causing it to select
> the old hash when faced with the conflict.
Fwiw I don't think Git automatically resolved that conflict:
$ git checkout 276f40fdc349d2ad62582b23ea55e061b689cfc0^
$ git merge 276f40fdc349d2ad62582b23ea55e061b689cfc0^2
$ git status -- gnu/packages/gnome.scm
HEAD detached at b2f6b6f6b9
You have unmerged paths.
Unmerged paths:
both modified: gnu/packages/gnome.scm
no changes added to commit
$ git diff -- gnu/packages/gnome.scm
diff --cc gnu/packages/gnome.scm
index d8d34c89ed,6c63b8bc59..00
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@@ -6433,13 -6415,10 +6421,12 @@@ supports playlists, song ratings, and a
name "-" version ".tar.xz"))
(sha256
(base32
- "0ddjwcd77nw0rxb5x5bz5hd671m8gya9827p8rsnb58x103kpai8"
+ "0ddjwcd77nw0rxb5x5bz5hd671m8gya9827p8rsnb58x103kpai8"))
+;; XXX: Remove when upgrading to 42.0
+(patches (search-patches "eog-update-libportal-usage.patch"
(build-system meson-build-system)
(arguments
- `(#:meson ,meson-0.59 ;positional arguments error with meson
0.60
- #:configure-flags
+ `(#:configure-flags
;; Otherwise, the RUNPATH will lack the final 'eog' path component.
(list (string-append "-Dc_link_args=-Wl,-rpath="
(assoc-ref %outputs "out") "/lib/eog"))
@@@ -6798,9 -6776,8 +6784,17 @@@ a secret password store, an adblocker,
"epiphany-" version ".tar.xz"))
(sha256
(base32
++<<< HEAD
+"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
+ (patches
+ (search-patches "epiphany-update-libportal-usage.patch"
++||| d91de53caa
++"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"
++
++===
+ "0k7b22zq3z1kllzqxgwsvwb1lp0j6rjb3k1hvhna3i573wc4mpji"
+
++>>> 276f40fdc349d2ad62582b23ea55e061b689cfc0^2
(build-system meson-build-system)
(arguments
`(#:glib-or-gtk? #t
WARNING: Git merges are tricky. Rebasing is better?
Take note that Git merges can be tricky and hide mistakes! Please
consider using a rebasing workflow instead of a merging workflow for
your branches.
For example, today we merged the version-1.4.0 branch into the master
branch, with commit 276f40fdc349d2ad62582b23ea55e061b689cfc0.
After the merge, we got a report on the #guix IRC channel [0] that the
Epiphany package's source hash was incorrect. It was using the hash of
the previously packaged version of Epiphany.
Using Git, we can see that in commit 291c4fa0ba, Epiphany was updated to
version 41.2, with a correct change in hash:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=291c4fa0baf24b9d600872fce99441f5471cdb40
Later, the version-1.4.0 branch was merged into master.
View the Git log from the commit where Epiphany was updated through the
merge:
$ git log --patch 291c4fa0baf^..276f40fdc34 gnu/packages/gnome.scm
It does not show that the update of Epiphany's source hash was reverted.
And to be sure that something is wrong, we can examine the file based on
the merge commit:
--
$ git show 276f40fdc349d2ad62582b23ea55e061b689cfc0:gnu/packages/gnome.scm |
grep "define-public epiphany" -A11
(define-public epiphany
(package
(name "epiphany")
(version "41.2")
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnome/sources/epiphany/"
(version-major version) "/"
"epiphany-" version ".tar.xz"))
(sha256
(base32
"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
-- ^
*This is the hash of Epiphany 40.3, the old version!*
Git's automatic merge conflict resolution algorithm did the wrong thing
here. And Git does not show the reversion in `git log`, hiding it from
review.
My guess is that commit f7afefba0 ("gnu: epiphany: Fix build with
libportal-0.5."), which happened on the master branch while the
version-1.4.0 branch was forked off, made Git think that this line was
more "up to date" on master than on version-1.4.0, causing it to select
the old hash when faced with the conflict.
Once again, consider using a workflow based on rebasing instead of
merging for forked branches that will live for weeks to a month or two.
This type of mistake cannot be obscured when rebasing.
[0] http://logs.guix.gnu.org/guix/2022-01-17.log#195313
Expat 2.4.3 with security fixes released
Hello everyone! Expat 2.4.3 with security fixes has been released. There is a summary blog post [1] and the change log [2] with more details. If you have patches for Expat that are still required with version 2.4.3, please send them my way. Thank you! Best Sebastian [1] https://blog.hartwork.org/posts/expat-2-4-3-released/ [2] https://github.com/libexpat/libexpat/blob/R_2_4_3/expat/Changes
Re: Profile definition, was Re: bug#53224: Cookbook recipe about profile collisions
On Mon, Jan 17, 2022 at 12:56:20PM -0500, Matt wrote: > Leo is 100% correct that my understanding is still rather weak. I'll do my > best despite that to help make the documentation better. I hope you will not feel too bad about that. Remember, everyone begins by not knowing anything. Your situation is not unique at all. Rather, your energy for improving the documentation for yourself and others is exemplary, and will improve Guix in the long run. Overall, this highlights a case where there is tension between when an implementation detail doesn't matter, and when it does. That is, the ideal situation is that the implementation details of profiles do not matter. However, when there are "profile collisions", it does matter.
Profile definition, was Re: bug#53224: Cookbook recipe about profile collisions
On Mon, 17 Jan 2022 09:16:28 -0500 Ludovic Courtès wrote
> > This person spent a lot of time trying to understand the situation and
> > writing the blog post, but their understanding is still rather weak.
>
> To be fair, the person didn’t look for “profile” in the manual. I’m not
> blaming—mentioning it to clarify what it is we’re trying to fix.
With all respect, I *did* look at "profile" in the manual. I spent a lot of
time looking and trying to understand things. I hear you say you're not trying
to blame me and I trust that's not your intent. However, what was said *does*
blame me. It says what I did and did not do, independent of reality: you are
not me and you were not present. Unfortunately, what was said carries all
sorts of judgments and implications (ouch!) which, opposite to your intent, is
not fair.
I see you want clarification on what we're trying to fix. May I suggest instead
asking, "What problem are we trying to solve?"
I see several problems beyond what I've already said. However, I'll try to
stick to just one that I encountered with the documentation. Leo is certainly
working toward something specific which I suspect is different from what I see.
I'll let them speak for themselves.
I'm going to assume that you probably wanted to ask something like, "It looks
to me like the manual adequately explains profiles. But, since I'm the main
architect of this system, maybe I have knowledge that someone new doesn't have.
Person who is confused, are you able to say where you're confused?"
I would reply:
There are several places I've been confused. Let me give you a specific example.
The manual has at least four places that "profile" is defined:
1.
[[https://guix.gnu.org/en/manual/en/html_node/Getting-Started.html#Getting-Started][(guix)
Getting Started]] says,
#+begin_quote
"A profile is a directory containing installed packages"
#+end_quote
2.
[[https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-package.html#Invoking-guix-package][(guix)
Invoking guix package]] says,
#+begin_quote
"a directory of installed packages"
#+end_quote
and 3, yet in the guix package options:
#+begin_quote
'-p PROFILE'
Use PROFILE instead of the user's default profile.
PROFILE must be the name of a file that will be created upon
completion. Concretely, PROFILE will be a mere symbolic link
("symlink") pointing to the actual profile where packages are
installed:
#+begin_example
$ guix install hello -p ~/code/my-profile
...
$ ~/code/my-profile/bin/hello
Hello, world!
#+end_example
#+end_quote
Elsewhere in (guix) Features is a 4th which says,
#+begin_quote
users have their own “profile”, which points to the packages that they actually
want to use
#+end_quote
So, is the profile a directory or a pointer file (e.g. symlink)? I tend to
think of a directory as a container, like a manilla folder that contains
papers. To me, something that points is a file that contains a path to another
location. I see that I used the word "contains" to describe both file and
directory, so maybe that's a sign to me I'm missing something there.
Regardless, I hope you can see that it's not always clear whether a profile is
a directory or a file. Yes, on Unix-like systems, directories are files. But
Guix throws an error if you call =guix package -p= with a directory:
: guix package: error: rename-file: Is a directory
If you follow the symlinks, the profile is indeed a directory; it is a
directory in the store. But the way users interact with profiles is
GUIX_PROFILE="$HOME/.guix-profile"
. "$GUIX_PROFILE/etc/profile"
which is a file. And there are a bunch of symlinks in general. Those appear to
be implementation details. But I think it's reasonable to say the abstraction
isn't airtight and that, as a user, I have to interact with the implementation
details at some level. Certainly at the documentation level.
Leo is 100% correct that my understanding is still rather weak. I'll do my best
despite that to help make the documentation better.
Re: Parallel guix builds can trample?
Hi, Phil Beadling schreef op ma 17-01-2022 om 17:23 [+]: > For each build that is kicked off in quick succession the local cache > of the repo required updated by update-cached-checkout > * https://github.com/guix- > mirror/guix/blob/9f526f5dad5f4af69d158c50369e182305147f3b/guix/git.sc > m#L476 > * https://github.com/guix- > mirror/guix/blob/9f526f5dad5f4af69d158c50369e182305147f3b/guix/git.sc > m#L279 Maybe 'latest-repository-commit' and 'update-cached-checkout' commit can be modified to not use 'switch-to-ref', and instead directly ask libgit ‘what's the tree structure of commit cabba9e’ and call a procedure like 'add-file-tree-to-store'. That would avoid lock files, creating separate directories for concurrent checkouts, ... Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: Parallel guix builds can trample?
Hi Ricardo, all, I think we’ve worked out what the issue is, and have a proposed workaround, and perhaps a case for solving the problem in Guix itself (depending on what you people think!). The issue is that despite each build being performed in its own isolated container, these containers are fed by the same per-user cached source directory. In the case where *different* versions of the *same* repo are built at once, this results in a race condition. In our case we have one Linux account that does a lot of automated Guix builds for us. One example is this account watches our source control and automatically rebuilds all outstanding Pull Requests (PRs) on a repo, after a separate successful merge to our integration branch. PRs are uniquely identified as monotonically increasing PR numbers eg, PR-1, PR-2, PR-3 and so on. Each is a different branch on the same Repo with slightly different candidate changes in it. They are automatically kept up to date with the integration branch. To do this our watcher fires off (near) instantaneously dozens of guix builds, each with their own local channel customized for the PR it is building. Doing them in parallel is important to make the system usably responsive. Each fired process does this: - Clone the channel containing the package into a local directory - Modify the commit id of the package to the new merged head of the PR - Modify the package version to some dummy version containing the PR number - Build the modified package using the local channel - Report the result (the build is effectively discarded; it is never used for anything) What we think is happening is the following: - For each build that is kicked off in quick succession the local cache of the repo required updated by *update-cached-checkou*t - https://github.com/guix-mirror/guix/blob/9f526f5dad5f4af69d158c50369e182305147f3b/guix/git.scm#L476 - https://github.com/guix-mirror/guix/blob/9f526f5dad5f4af69d158c50369e182305147f3b/guix/git.scm#L279 - The problem with this is because each version is using the same cached repo --- before one has a chance to take a copy of the updated checkout, that checkout can be changed by a separate build process Thus there is a race condition in this scenario. We can provide a longer test script to demo this if required – it’s quite straightforward to reproduce just with a bash script, now we know what is causing it. Our workaround has been to change XDG_CACHE_HOME for each PR build we do. But this is a bit unsatisfactory as it effects processes beyond Guix – it casts too wide of a net, but it does resolve the problem for the time being. Do people think this is enough of an issue to make a switch available in Guix to prevent sharing of cached clones? This would be easy enough to implement – a crude solution would be that each cache directory name would simply be generated using a SHA of a string which includes the PID or similar to ensure a unique name, and because it is never going to be reused it could be deleted immediately after the build. Whilst this is unlikely to happen at the console, as people script guix build use-cases to fit their own problems (in particular building lots of variations of a single piece of software) – I can see this causing a headache? I think at least the manual should make it clear that you cannot build 2 packages referencing the same repo at the same time with the same user (unless I’ve missed this bit I don’t think it’s made explicitly clear?). An even simpler change would be introduce a lock file that refused the 2nd build and at least preventing the race condition happening, and ensuring referential transparency, or simpler still just placed a warning on stderr? If people are amenable to adding a switch or other config option, we’d be happy to look writing the patch? Any thoughts/comments/advice? Cheers! Phil. On Wed, 12 Jan 2022 at 09:37, Phil wrote: > Hi - more details below. > > Ricardo Wurmus writes: > > > > > How are you using Guix with this? Do you generate Guix package > > expressions? Do you use “guix build --with-commit”? > > > > The situation is like this - if we had a directory of clones of my > channel: > > - pr-1 > - pr-2 > - pr-3 > - pr-4 > ... and so on > > Initially all the clones are taken from the master branch of my > channel and are all identical - but we change the version and commit to > match the head of each PR branch as per below. > > Each clone looks like this: > - pr-1 > - my-package.scm > - pr-2 > - my-package.scm > and so on > > Each my-package.scm has a package like below - the inital packages are all > identical, but my system effectively seds the version and commit values > like the below. These values are never committed back to master they > are used only as local channels to build each PR to test each build > still passes. > > (define-public my-package > (package >
Re: using an SRFI that is not available in Guile
> I forgot to include "guile" ("guix shell" needs that to know
> "GUILE_LOAD{,_COMPILED}_PATH"), try
>
> ./pre-inst-env guix shell guile guile-srfi-189 -- guile
that this works indeed, thanks!
i have sent the guile-srfi-189 patch as:
https://issues.guix.gnu.org/53317
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Without self knowledge, without understanding the working and functions of his
machine, man cannot be free, he cannot govern himself and he will always remain
a slave.”
— George Ivanovich Gurdjieff (1877–1949)
packages: [PoC] Expand range of objects 'add-input-label' can label
Hey Guix! This is me grubbing around with internals I know nothing about. Here is a quick and dirty proof-of-concept patch that extends 'add-input-label' to use the 'name' property of plain-file, program-file, etc. In addition, it also labels auxiliary files, using the same path string one provides to search-auxiliary-file. This part is the dirtiest, especially since we cannot make use of %auxiliary-files-path from (gnu packages) since that would introduce a circular dependency. The motivation for this arose while recently munging a package to use new-style inputs. The package's inputs include an auxiliary file and custom program-file gexp; however, with new-style inputs there is no obvious way to get get access to these input paths within the build phases: - Both get the default "_" label; and - search-input-file only finds files inside store path *directories*. There potentially a workaround using file-union, but it's clearly friction. Naive package-writing me wanted one of two things: 1) Ability to mix old, explicit labels with the new labelless inputs, or 2) Labels that come from the gexp name. The first option is much more general, but somehow I stumbled across the add-input-label procedure, so went with 2. What are your thoughts? Clear unknows to me: - Is add-input-label in a fast path? This patch significantly increases the cases supplied to 'match', which feels like it has the potential to hit performance in a bad way. - Using the 'name' property is kind of obvious, but add-input-label looks deliberatly small. Was using 'name' intentionally avoided for some reason? - Are there other implicit concerns/constraints within guix/packages.scm that I am oblivious to? - etc? Anyway, by no means do I expect this to get merged, mostly just hoping to learn something. Cheers, B. Wilson From 3b8e7fa8fbd58e7e164e3730c708419f612b8549 Mon Sep 17 00:00:00 2001 From: "B. Wilson" Date: Sun, 16 Jan 2022 23:54:51 +0900 Subject: [PATCH 1/2] packages: Expand range of objects 'add-input-label' can label To: guix-patc...@gnu.org * guix/packages.scm (%auxiliary-files-subpath-dir): New variable. (add-input-label): Support labels from the name property of objects that have one. Also, name auxiliary files from their subpath. --- guix/packages.scm | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/guix/packages.scm b/guix/packages.scm index 9d5b23eb8a..4feea8ad5f 100644 --- a/guix/packages.scm +++ b/guix/packages.scm @@ -7,6 +7,7 @@ ;;; Copyright © 2019 Marius Bakke ;;; Copyright © 2020, 2021 Maxim Cournoyer ;;; Copyright © 2021 Chris Marusich +;;; Copyright © 2022 B. Wilson ;;; ;;; This file is part of GNU Guix. ;;; @@ -569,6 +570,10 @@ (define-record-type* (default (current-definition-location)) (innate))) +;; Note: This morally imports from gnu/packages.scm, but since they import us, +;; we define here instead. +(define %auxiliary-files-subdir-path "/gnu/packages/aux-files") + (define (add-input-label input) "Add an input label to INPUT." (match input @@ -576,7 +581,24 @@ (define (add-input-label input) (list (package-name package) package)) (((? package? package) output);XXX: ugly? (list (package-name package) package output)) -((? gexp-input?) ;XXX: misplaced because 'native?' field is ignored? +((? local-file? local-file) + (list (local-file-name local-file) local-file)) +((? plain-file? plain-file) + (list (plain-file-name plain-file) plain-file)) +((? computed-file? computed-file) + (list (computed-file-name computed-file) computed-file)) +((? program-file? program-file) + (list (program-file-name program-file) program-file)) +((? scheme-file? scheme-file) + (list (scheme-file-name scheme-file) scheme-file)) +((? string? path) + (let* ((regex (string-append %auxiliary-files-subdir-path "/(.*)")) +(match (string-match regex input))) + `(,(if match + (match:substring match 1) + "_") + ,input))) +((? gexp-input?) ;XXX: misplaced because 'native?' field is ignored? (let ((obj(gexp-input-thing input)) (output (gexp-input-output input))) `(,(if (package? obj) -- 2.34.0
Guix Packaging Meetup Next Sunday (January 23)
Hi Guixers, I want to invite you to another Guix packaging meetup next Sunday, Jan. 23, 2022. The meetup will take place on Big Blue Button at the following room: https://meet.nixnet.services/b/jga-rtw-ahw-yky I want to thank nixnet for hosting the BBB! The meeting will start at 11:30 AM ET (4:30 PM UTC). Hope to see you there! jgart gemini://whereiseveryone.srht.site/ https://whereiseveryone.srht.site/
