Hi Rutherther, Thanks for the issue link. I have also run into issues updating the store since switching to the unprivileged daemon on these Ubuntu VMs. I get an error stating that there are issues with read-only files in the store. I fixed this by restarting the guix-daemon on these VMs since that seems to unmount and remount the /gnu/store read-only after making it available to the guix-daemon process for writing. This behavior is quite mysterious and not good for my current CI/CD pipeline. I hope the bug is resolved on the master branch soon.
Cheers, Gary Rutherther <[email protected]> writes: > Hey, > > My wild guess would be you are running into similar issue as > <https://codeberg.org/guix/guix/issues/5891> as you are likely using > unprivileged daemon on Ubuntu and privileged on Guix System. > > You can try switching to unprivileged daemon on your Guix System and try > building like that. I suspect you will hit the issue on both systems > afterwards. > > Rutherther > > On February 5, 2026 3:37:52 PM GMT+01:00, Gary Johnson > <[email protected]> wrote: >>Thanks for the debugging help, Daniel. I'll take a look and see if I can spot >>why this function is crashing on my packages. >> >>~Gary >> >>Daniel Littlewood <[email protected]> writes: >> >>> Hi Gary, >>> >>> At first I was surprised to see gnu-build-system in the traceback, but >>> it turns out copy-build-system is implemented in terms of >>> gnu-build-system (I did not know this, maybe you did). Looking at the >>> procedure install-license-files in gnu-build-system, there are a >>> couple of calls to match which could be failing. If I'm reading the >>> traceback correctly, it points to line 881, which is the call to match >>> in find-source-directory, quoted below. >>> >>> (define (find-source-directory package) >>> ;; For an out-of-source build, guess the source directory location >>> ;; relative to the current directory. Return #f on failure. >>> (match (scandir ".." >>> (lambda (file) >>> (and (not (member file '("." ".." "build"))) >>> (file-is-directory? >>> (string-append "../" file))))) >>> (() ;hmm, no source >>> #f) >>> ((source) ;only one other file >>> (string-append "../" source)) >>> ((directories ...) ;pick the most likely one >>> ;; This happens for example with libstdc++, which lives within >>> the GCC >>> ;; source tree. >>> (any (lambda (directory) >>> (and (string-prefix? package directory) >>> (string-append "../" directory))) >>> directories)))) >>> >>> This procedure is apparently only called when out-of-source? is true, >>> and I am not sure what that means. Regardless, if (match (scandir >>> ...)) does not match the given patterns, it must not be returning a >>> list (and the traceback confirms this; it is in fact returning #f). I >>> suppose this indicates that scandir failed for some reason, for >>> instance that .. is not readable. Indeed my copy of the guile manual >>> (page 743) confirms this (it cannot be the case that .. is some other >>> type of file, so it must be an unreadable directory). >>> >>>> Return #f when name is unreadable or is not a directory. >>> >>> This explains the error at least - the match call does not handle #f. >>> This does however leave open some questions I do not have an answer >>> for. I am not sure what .. is in this context. Perhaps /gnu/store? I >>> think that can't be it, because searching the entire store for a >>> license file in one package would be terribly wasteful. I guess .. >>> must be the checked out source tree. But then how can it not be >>> readable? >>> >>> I hope this debugging is helpful, although I am still confused. >>> >>> Best wishes, >>> >>> Dan >>> >>> On 28/01/2026 14:10, Gary Johnson wrote: >>>> Hi Guix, >>>> >>>> I recently installed Guix onto a new Ubuntu VM using the standard >>>> guix-install.sh script. Now on this VM, I cannot successfully build >>>> packages that do build correctly on my own machine. >>>> >>>> While one might expect that I am just running different versions of Guix >>>> on each machine, this shouldn't be the case because I am using the same >>>> channels.scm file on both computers via the `guix time-machine` command. >>>> I've never seen different behavior between two machines running the same >>>> Guix version and building the same packages before, so I am utterly >>>> mystified. >>>> >>>> Here's the error I get on my new VM when building a package: >>>> >>>> =========================================================================== >>>> >>>> starting phase `install-license-files' >>>> error: in phase 'install-license-files': uncaught exception: >>>> match-error "match" "no matching pattern" #f >>>> phase `install-license-files' failed after 0.0 seconds >>>> Backtrace: >>>> 9 (primitive-load "/gnu/store/mbyp0pi1lbcqzw22mv0bjpabqis…") >>>> In guix/build/gnu-build-system.scm: >>>> 972:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) >>>> In ice-9/boot-9.scm: >>>> 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) >>>> In srfi/srfi-1.scm: >>>> 634:9 6 (for-each #<procedure 71ac5e089d40 at guix/build/gnu-b…> …) >>>> In ice-9/boot-9.scm: >>>> 1752:10 5 (with-exception-handler _ _ #:unwind? _ # _) >>>> In guix/build/gnu-build-system.scm: >>>> 993:23 4 (_) >>>> 889:7 3 (install-license-files #:outputs _ #:license-file-regexp …) >>>> 881:4 2 (_) >>>> In ice-9/boot-9.scm: >>>> 1685:16 1 (raise-exception _ #:continuable? _) >>>> 1685:16 0 (raise-exception _ #:continuable? _) >>>> >>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >>>> Throw to key `match-error' with args `("match" "no matching pattern" #f)'. >>>> build process 11 exited with status 256 >>>> >>>> =========================================================================== >>>> >>>> Here is one of the many offending files that are all failing for me like >>>> this: >>>> >>>> (define geoserver-css-plugin >>>> (package >>>> (name "geoserver-css-plugin") >>>> (version "2.19.6") >>>> (source (origin >>>> (method url-fetch) >>>> (uri (string-append >>>> "https://sourceforge.net/projects/geoserver/files/GeoServer/"; version >>>> "/extensions/geoserver-" version >>>> "-css-plugin.zip")) >>>> (sha256 (base32 >>>> "06h2avzqps4dv9lwpck14v4cpk511z1mh13d3w5ii1153rcqdihb")))) >>>> (build-system copy-build-system) >>>> (arguments '(#:install-plan '(("." "./" #:exclude >>>> ("environment-variables"))))) >>>> (native-inputs (list unzip)) >>>> (home-page >>>> "https://docs.geoserver.org/latest/en/user/styling/css/install.html";) >>>> (synopsis "GeoServer CSS Plugin") >>>> (description "The GeoServer CSS Plugin enables you to write layer >>>> styles using CSS instead of SLD.") >>>> (license gpl2))) >>>> >>>> In order to get them to build I have to modify their build phases like so: >>>> >>>> (define geoserver-css-plugin >>>> (package >>>> (name "geoserver-css-plugin") >>>> (version "2.19.6") >>>> (source (origin >>>> (method url-fetch) >>>> (uri (string-append >>>> "https://sourceforge.net/projects/geoserver/files/GeoServer/"; version >>>> "/extensions/geoserver-" version >>>> "-css-plugin.zip")) >>>> (sha256 (base32 >>>> "06h2avzqps4dv9lwpck14v4cpk511z1mh13d3w5ii1153rcqdihb")))) >>>> (build-system copy-build-system) >>>> (arguments '(#:phases (modify-phases %standard-phases >>>> (delete 'install-license-files)) >>>> #:install-plan '(("." "./" #:exclude >>>> ("environment-variables"))))) >>>> (native-inputs (list unzip)) >>>> (home-page >>>> "https://docs.geoserver.org/latest/en/user/styling/css/install.html";) >>>> (synopsis "GeoServer CSS Plugin") >>>> (description "The GeoServer CSS Plugin enables you to write layer >>>> styles using CSS instead of SLD.") >>>> (license gpl2))) >>>> >>>> Does anybody have any idea what could be going on here? >>>> >>>> Thanks, >>>> Gary >>>> >> -- GPG Key ID: C4FBEDBD Use `gpg --search-keys [email protected]' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Why is HTML email a security nightmare? See https://useplaintext.email/ Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
