Re: Using Guix inside a Guix container
Konrad Hinsen wrote:
> Hi Guix,
>
> I have been playing with nested Guix containers recently, with some
> suprising findings, and I am wondering if what I am doing is considered
> officially supported or not.
>
> First: why? My use case is scientific workflows, for example using
> snakemake. I want to run my workflows in Guix containers, for
> reproducibility plus other reasons. But my workflows run other programs
> in their tasks (basically just "shelling out"), and those tasks may use
> their own Guix containers.
>
> Superficially, this works fine if I add the "guix" package to my "outer"
> container and expose the store plus the daemon's socket:
>
> guix shell -C guix \
> --expose=/var/guix/daemon-socket/socket \
> --expose=/gnu/store \
> -- \
> guix shell -C coreutils -- ls /
>
> But now for the first surprise:
>
>$ guix describe
>Generation 35 janv. 19 2023 12:34:57 (current)
> guix 8221cb6
>repository URL: https://git.savannah.gnu.org/git/guix.git
>branch: master
>commit: 8221cb6d2ae5624829bf514d25ae234c073e35d5
>
>$ guix shell -C guix -- guix describe
> guix 9fe5b49
>repository URL: https://git.savannah.gnu.org/git/guix.git
>branch: master
>commit: 9fe5b490df83ff32e2e0a604bf636eca48b9e240
>
> The Guix in my container is an older one, apparently the 1.4.0 release.
> Why? Can I change this?
Makes sense to me, because the guix package definition was only updated
with the new release (see 'guix edit guix'). Maybe you can try:
guix shell -C guix --with-version=guix=VERSION -- guix describe
Or --with-commit etc.
>
> My first attempt was time-machine:
>
> guix shell -C -N guix nss-certs \
> --expose=/var/guix/daemon-socket/socket \
> --expose=/gnu/store \
> -- \
> guix time-machine -C channels.scm -- describe
>
>Updating channel 'guix' from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
>Authenticating channel 'guix', commits 9edb3f6 to 8221cb6 (331 new
> commits)...
>Computing Guix derivation for 'x86_64-linux'... |
> guix 8221cb6
>repository URL: https://git.savannah.gnu.org/git/guix.git
>branch: master
>commit: 8221cb6d2ae5624829bf514d25ae234c073e35d5
>
> Great! Except that every time I run this command, it does the channel
> update from scratch, so it's prohibitively slow. Sharing
> ${HOME}/.cache/guix seems to fix that. So... finally...
>
> guix shell -C -N guix nss-certs \
> --expose=/var/guix/daemon-socket/socket \
> --expose=/gnu/store \
> --share=${HOME}/.cache/guix \
> -- \
> guix time-machine -C channels.scm \
> -- \
> shell -C coreutils \
> -- \
> ls /
>
> guix shell: error: mount: mount "none" on
> "/tmp/guix-directory.vpOEDC/sys": Operation not permitted
Maybe --expose tmp is needed in the outer container.
--
Re: [Internship][Discussion] Do we want to run our own internship program?
Hi Gábor, On lun., 13 févr. 2023 at 21:13, Gábor Boskovits wrote: > So, the question is: do we want to run our own? By “our own”, do you mean something like “Guix Summer of Code”? Or whatever other season. :-) Similar to: https://summer.nixos.org/ https://summer.haskell.org/news/2017-04-05-getting-ready.html If yes, doing that under the French law is not straightforward and it would require some paperwork. Well, maybe not. Cheers, simon
’inherit’ and list-dependent (was Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.)
Hi, On dim., 12 févr. 2023 at 01:14, Ludovic Courtès wrote: >> There is an idea to update guix refresh --list-dependent to handle the >> case with inherited packages as well. WDYT? > > Unfortunately, it’s not possible because inheritance info isn’t > available at run time. Well, with the current implementation of ’inherit’, which is just copy/paste at the record level, indeed it is not possible to detect some relationship. However, we could imagine to use ’package/inherit’ or another variant instead of plain ’inherit’ for creating these inherited packages. Doing so, we could collect some information, e.g., in the field ’properties’, which could be used then by --list-dependent. Many of us are bitten by this. I remember a recent update of Git which also missed the dependency of git-minimal. :-) For sure, QA helps a lot. Somehow, braces and belt. ;-) Cheers, simon
Suggestion: adding version information to Emacs packages
Dear Guix Developers,
I would like to suggest adding version information to the Guix packages for
Emacs.
This would make it easier to know which version is installed,
upgrade/downgrade easily, and avoid confusion with version set to 0.0.0.
This is an example I'm using the version in Guix package to Emacs.
--8<---cut here---start->8---
(arguments
`(#:phases
(modify-phases %standard-phases
(add-after
'unpack 'fix-version
(lambda _
(substitute*
(string-append (string-drop ,name (string-length "emacs-"))
".el")
(("^;; Version: ([^/[:blank:]\r\n]*)(.*)$")
(string-append ";; Version: " ,version "\n"
--8<---cut here---end--->8---
Best regards,
--
Giap Tran
GnuPG/0xE655BF766A56995D
Rust team branch (was Re: Discussion notes on releases and branches)
On Thu, Feb 09, 2023 at 01:19:28PM +0100, Andreas Enge wrote: > Attached are the notes of our discussion at the Guix Days concerning > releases, branches, teams and related matters. > > Andreas > > BRANCHES > > Suggestion: > - Spin off a stable branch from master with security fixes, maybe important > backports; after 6 months, branch a new stable branch from master; this > is almost like a release, but continued into some future. > > Counter-suggestion: > - Create branches with a few patches or patchsets; in any case with > a "semantic" description of the changes. The branches could be > shortlived. Feature branches are one incarnation of the concept. > - The numerical criteria for staging and core-updates is outdated: > Even non-core packages may create an enormous number of rebuilds. > - Negative point: There is a risk of churn, by not regrouping world- > rebuilding changes - but two non related world rebuilding changes > might be difficult to review. > > Before creating new branches, we need to clarify how the old branches > are handled! > > - Smaller branches could be taken care of by dedicated persons > responsible for pushing them forward. For instance by teams. > - Some people already do this for a feature branch on their local > machine for medium-sized updates (ocaml), or even on ci (haskell, > kernel updates). > - Branch creators should fix a goal and tentative timeline. > - We need a mapping between branches and maintainers responsible > for the merge. This could be a team leader, if such a role is created. > A wiki could be used to keep track of the branches. > - There is discussion whether we need a core-updates branch. > Core updates concern the toolchain, build phase changes, everything > that has big ramifications all over the system. It would be important > to not have several "parallel" branches with related (for instance, > but not exclusively, core-update) changes, which in fact should come > one after the other. Either they could be collected in one branch, > or would require coordination of branch creation (inside a team, say). > - "Merge trains" of gitlab are mentioned, as a way of merging several > branches at the same time. > - Grafts can also be handled in feature branches: The graft is applied > to master; the graft is applied to a different branch, directly followed > by an ungrafting commit and an update of the corresponding package; > once the branch is built it is merged back to master. > - Minor drawback: If qa has treated a world-rebuilding patch, the > substitutes will be available on bordeaux, but not on berlin; people > who have installed a long time ago and not authorised bordeaux might > be affected. If there are complaints, they can be handled on the > mailing list. > - Moving fast poses problems for non-x86 architectures, but the build farm > situation has improved for aarch64 and armhf sufficiently to keep up > with master. Handling feature branches remains an unsolved problem. > - Currently there is a cap on qa, only patches with at most 300 dependents > are treated. This cap could be increased. Or it could be weighed with > the build times of the packages. > > > TEAMS > > - Issues could be tagged more often with responsible teams, or with > severity information (blocking bug or not). > - Each module should be covered by a team; otherwise it would be > difficult to get important updates through a feature branches. On behalf of the Rust Team™¹ we'd like to check our rust source tarballs for any hidden binaries² and to do a mass upgrade of many of the crates. Currently there are many crates queued up in the staging branch but we'd like to pull them out and run a rust-team branch. As a project we haven't setup anything for starting the team-based branches and upgrades, and the Rust Team volunteers to go first. Although the rust team would consider adding librsvg (and python-cryptography) to our list of packages, we'd like to not touch it this round, to keep it "small" (as far as rust goes) as a test. ¹ Help wanted ² https://issues.guix.gnu.org/61352 -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Licence of the Guix blog posts
Hello, I agree for my contribution to the blog posts with the license under CC-BY-SA 4.0 and GFDL version 1.3 or later. Regards, Cyril Roelandt
Re: Using Guix inside a Guix container
James Thomas wrote: > guix shell -C guix --with-version=guix=VERSION -- guix describe Or even: guix shell -C -p /var/guix/profiles/per-user/.../current-guix -- guix describe --
Re: Merging core-updates?
On Mon, Feb 13, 2023 at 09:36:17PM +, Kaelyn wrote: > --- Original Message --- > On Monday, February 13th, 2023 at 8:04 PM, Efraim Flashner > wrote: > > > > > > On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote: > > > > > Hi, > > > > > > --- Original Message --- > > > On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge andr...@enge.fr > > > wrote: > > > > > > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller: > > > > > > > > > And I was able to rebuild (with --check) patch-mesboot. The error > > > > > looks > > > > > a lot like https://issues.guix.gnu.org/49985. We should fix that > > > > > indeed > > > > > :) > > > > > > > > Ah indeed, that looks like deal breaking; maybe someone from MES can > > > > have > > > > a look? > > > > > > > > What is the magic incantation with double "@@" to build this package? > > > > Ah, here we go, for reference to self: > > > > guix build -e '(@@ (gnu packages commencement) patch-mesboot)' > > > > > > > > Andreas > > > > > > While not directly related to the patch-mesboot error, I want to mention > > > that there is also https://issues.guix.gnu.org/58719 blocking i686 builds > > > on core-updates (and x86_64 builds of certain packages like wine64, which > > > has i686 dependencies) since the update to glibc 2.35. > > > > > > It may also need assistance from the MES folks to fix, since the error > > > message is about an undefined symbol in glibc-mesboot's libpthread.so.0: > > > > > > make[2]: Entering directory > > > '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic' > > > ../src/file -C -m magic > > > /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup > > > error: > > > /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0: > > > undefined symbol: h_errno, version GLIBC_PRIVATE > > > make[2]: *** [Makefile:863: magic.mgc] Error 127 > > > > > > Cheers, > > > Kaelyn > > > > > > I think I found where this is coming from. %boot3-inputs added > > ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in > > glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs > > to see if that's enough to make that final file build. Hopefully it'll > > also fix the final tar for i686, which I found was also failing for me. > > Interesting! Since my last email, I was able to fix the issue with file by > adding "--disable-xzlib" to the file package in gnu/packages/commencement.scm > (after discovering it when noticing "--disable-bzlib" was being passed to the > configure script), but hadn't sent in a patch yet because I hit a subsequent > test failure while building tar. I thought to disable xz support because I > traced the source of the glibc-mesboot libpthread.so in the error message to > xz-mesboot being detected by the configure script and linked in even though > file itself was being linked against a newer glibc and had no explicit > dependencies. (I think the error after upgrading to glibc 2.35 from 2.33 was > an abi compatibility between the newer glibc and the old pthread being pulled > in via xz-mesboot.) > > Cheers, > Kaelyn I ended up going a different route and moving xz from the finalize packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in %boot6-inputs. I also tracked down the issue in tar and adjusted the testsuite so it shouldn't be a problem on 32-bit systems. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Substitute fetching in installer iso's default origin very slow. Do you need more bandwidth?
Substitute fetching in installer iso's default origin very slow. Do you need more bandwidth? Best wishes TTT My pubkey: -BEGIN PGP PUBLIC KEY BLOCK- mDMEY+u0BBYJKwYBBAHaRw8BAQdA6QcD8NB84W7zT4rzWeDDHLo49h4F7ghroDoY aMurA1K0O1RhaW50ZWQgVG90b3JvIFRvYXN0ZXIgPHRhaW50ZWRfdG90b3JvX3Rv YXN0ZXJAbmljZW1haWwuZXU+iJUEExYKAD0WIQTmGAUSFihqRK64li3R99zu5Gx3 vQUCY+u0BAIbAwUJAeEzgAQLCQgHBRUKCQsCBRYAAgMBAh4FAheAAAoJENH33O7k bHe9FqUA/jsU2nBicr/8a7DqJQUn9bsIP8PbyR9UPS6b6RnYcbL0AP42y+RXxFZ+ D0kWKnNlVg3qWaqBXVCkl1AVJubLvqmPCLg4BGPrtAQSCisGAQQBl1UBBQEBB0Cj 8xIxhmInavoNvcvfLFeUJPLR5QACQtfrVahXJJB/dAMBCAeIfgQYFgoAJhYhBOYY BRIWKGpErriWLdH33O7kbHe9BQJj67QEAhsMBQkB4TOAAAoJENH33O7kbHe9IgEA /1wgomwE6/CP9cQjCVuwLZ++hETA7Wa70VclZB923E2rAP9ZnTtQZWrenCaPdBY5 n7sgS096s73RtvQcw1Zi1pO1Cg== =RDAN -END PGP PUBLIC KEY BLOCK-
Re: Architecture support [was: Re: Merging core-updates?]
Hello, Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner: > Aarch64 and armhf are getting stuck at gcc-cross-boot0. I got to hello on my aarch64, which is very encouraging! I will have to try again with your latest changes to core-updates, but am rather optimistic. Andreas
Re: Rust team branch
Am Tue, Feb 14, 2023 at 12:14:04PM +0200 schrieb Efraim Flashner: > On behalf of the Rust Team™¹ we'd like to check our rust source tarballs > for any hidden binaries² and to do a mass upgrade of many of the crates. > Currently there are many crates queued up in the staging branch but we'd > like to pull them out and run a rust-team branch. By "pull out" you mean revert them in staging and apply them on a separate branch? That would also delay #61475 and maybe ease merging of the staging branch. Would it make sense to wait with the creation of the feature branch until after the core-updates merge? > As a project we haven't setup anything for starting the team-based > branches and upgrades, and the Rust Team volunteers to go first. > ¹ Help wanted Splendid! I suppose that increasing the team size beyond 1 would be a first important goal, call out to volunteers! Andreas
Re: Rust team branch (was Re: Discussion notes on releases and branches)
Efraim Flashner writes: > As a project we haven't setup anything for starting the team-based > branches and upgrades, and the Rust Team volunteers to go first. Leo has attempted[1] to setup a branch for Go, but we're waiting to hear from sysadmins on why there's a build error. [1] https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00131.html -- Katherine
Re: Architecture support [was: Re: Merging core-updates?]
Could we get berlin to evaluate a small set of core packages (mpc, hello, …)? Are the changes intended to fix the issue with bordeaux's machines? Is it configured to build core-updates? Le 14 février 2023 17:30:32 GMT+01:00, Andreas Enge a écrit : >Hello, > >Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner: >> Aarch64 and armhf are getting stuck at gcc-cross-boot0. > >I got to hello on my aarch64, which is very encouraging! I will have to >try again with your latest changes to core-updates, but am rather optimistic. > >Andreas > >
Re: Substitute fetching in installer iso's default origin very slow. Do you need more bandwidth?
Hi, Tainted Totoro Toaster writes: > Substitute fetching in installer iso's default origin very slow. Do you > need more bandwidth? I don't think it's just a matter of bandwidth, the main substitute server has pretty bad peering with some areas of the world. Being able to change the default substitute server on the installer image could be considered though. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Merging core-updates?
Am Mon, Feb 13, 2023 at 11:31:15PM +0200 schrieb Efraim Flashner: > Looks like you might be able to drop openjdk-10-hotspot-stack-size.patch > from openjdk-19.0.1. Maybe. What is strange is that we have the same openjdk package on master, apparently with the patch. I will give it a try nevertheless. Andreas
Re: Moving forward with teams and feature branches (was: Discussion notes on releases and branches)
On Mon, Feb 13, 2023 at 03:07:58PM +0100, Andreas Enge wrote: > Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret: > > 4. staging merge happens, and the branch gets deleted. > > I failed to compile my profile on staging, since rust-rav1e, a dependency > of ffmpeg, failed to build; see bug #61475. If this can't be fixed quickly, my recommendation would be to remove the dependency. Rust-rav1e is an AV1 video encoder, but FFmpeg also has this functionality via libaom, which is the reference implementation and considered to be very high quality.
Re: [Internship][Discussion] Do we want to run our own internship program?
Hello, Simon Tournier ezt írta (időpont: 2023. febr. 14., K 13:24): > Hi Gábor, > > On lun., 13 févr. 2023 at 21:13, Gábor Boskovits > wrote: > > > So, the question is: do we want to run our own? > > By “our own”, do you mean something like “Guix Summer of Code”? Or > whatever other season. :-) > Yes, exactly. > Similar to: > > https://summer.nixos.org/ > https://summer.haskell.org/news/2017-04-05-getting-ready.html > > > If yes, doing that under the French law is not straightforward and it > would require some paperwork. Well, maybe not. > Yes, that is part of the know-how I referred to. > Cheers, > simon > Regards, g_bor >
Re: ’inherit’ and list-dependent (was Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.)
Hello, Simon Tournier ezt írta (időpont: 2023. febr. 14., K 13:25): > Hi, > > On dim., 12 févr. 2023 at 01:14, Ludovic Courtès wrote: > > >> There is an idea to update guix refresh --list-dependent to handle the > >> case with inherited packages as well. WDYT? > > > > Unfortunately, it’s not possible because inheritance info isn’t > > available at run time. > My idea here was to rescan the source with a minimal scanner and build up an inheritance aware dependency graph. We could then make this information available in some way, but about that part I did not think about too much yet. Another thing that could possibly work is to enrich the package with inheritance information, but I am not sure that this can be done in a backwards compatible way. Wdyt? > > Well, with the current implementation of ’inherit’, which is just > copy/paste at the record level, indeed it is not possible to detect some > relationship. > > However, we could imagine to use ’package/inherit’ or another variant > instead of plain ’inherit’ for creating these inherited packages. Doing > so, we could collect some information, e.g., in the field ’properties’, > which could be used then by --list-dependent. > > Many of us are bitten by this. I remember a recent update of Git which > also missed the dependency of git-minimal. :-) > > For sure, QA helps a lot. Somehow, braces and belt. ;-) > > > Cheers, > simon > Regards, g_bor > > > >
Re: Rust team branch
On Tue, Feb 14, 2023 at 05:36:13PM +0100, Andreas Enge wrote: > Am Tue, Feb 14, 2023 at 12:14:04PM +0200 schrieb Efraim Flashner: > > On behalf of the Rust Team™¹ we'd like to check our rust source tarballs > > for any hidden binaries² and to do a mass upgrade of many of the crates. > > Currently there are many crates queued up in the staging branch but we'd > > like to pull them out and run a rust-team branch. > > By "pull out" you mean revert them in staging and apply them on a separate > branch? That would also delay #61475 and maybe ease merging of the staging > branch. I was thinking more of cherry-picking them into a branch, not necessarily reverting them on staging. > Would it make sense to wait with the creation of the feature branch > until after the core-updates merge? Normally I'd say yes, but it might be a while until we can get core-updates merged in. > > As a project we haven't setup anything for starting the team-based > > branches and upgrades, and the Rust Team volunteers to go first. > > ¹ Help wanted > > Splendid! I suppose that increasing the team size beyond 1 would be > a first important goal, call out to volunteers! > > Andreas > > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Rust team branch (was Re: Discussion notes on releases and branches)
On Tue, Feb 14, 2023 at 09:36:46AM -0700, Katherine Cox-Buday wrote: > Efraim Flashner writes: > > > As a project we haven't setup anything for starting the team-based > > branches and upgrades, and the Rust Team volunteers to go first. > > Leo has attempted[1] to setup a branch for Go, but we're waiting to hear from > sysadmins on why there's a build error. > > [1] https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00131.html Second is also good :) Also I don't think there's a lot of overlap between go and rust so we can probably have both going at the same time. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Architecture support [was: Re: Merging core-updates?]
On Tue, Feb 14, 2023 at 05:30:32PM +0100, Andreas Enge wrote: > Hello, > > Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner: > > Aarch64 and armhf are getting stuck at gcc-cross-boot0. > > I got to hello on my aarch64, which is very encouraging! I will have to > try again with your latest changes to core-updates, but am rather optimistic. It might just be my machines then. My pinebook pro doesn't have a lot of space available for building and my pine64 only has 2GB of ram. Also I made a typo in the tar fix, so I'll push a fix for that after I confirm that it actually skips the broken test. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Merging core-updates?
--- Original Message --- On Tuesday, February 14th, 2023 at 2:50 PM, Efraim Flashner wrote: > [snip] > > I ended up going a different route and moving xz from the finalize > packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in > %boot6-inputs. > > I also tracked down the issue in tar and adjusted the testsuite so it > shouldn't be a problem on 32-bit systems. I just tried building wine-minimal from core-updates at commit da7d615629, and I think you may have be missing a "!" with the new flag for the tar test suite (i.e. it needs to be "-k '!tricky time stamps'"). Based on the build log, right now only the failing test is being run: ## - ## ## Test results. ## ## - ## ERROR: 1 test was run, 1 failed unexpectedly. ## ## ## Summary of the failures. ## ## ## Failed tests: GNU tar 1.34 test suite test groups: NUM: FILE-NAME:LINE TEST-GROUP-NAME KEYWORDS 151: time01.at:20 time: tricky time stamps time time01 Cheers, Kaelyn > > -- > Efraim Flashner efr...@flashner.co.il אפרים פלשנר > > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted
Re: Golang go-updates feature branch?
Hi Leo, Leo Famulari writes: > And there is a diff for 'build-aux/cuirass/evaluate.scm', so that I can > test it with `make cuirass-jobs`. > > But, `make cuirass-jobs` crashes with this manifest and I don't know > why: The inferior that's used in 'build-aux/cuirass/evaluate.scm' is built from the current check-out by first adding the checkout to the store and then building it the usual way. However, that copy only selects files that belong to the git tree using the git-predicate. If you add the manifest to the git checkout by first committing it, it should proceed happily (at least it did over here). Best, -- Josselin Poiret signature.asc Description: PGP signature
Licence of the Guix blog posts
Yes, I agree for my contribution to the blog posts to be published under the licenses CC-BY-SA 4.0 and GFDL version 1.3 or later (with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts).
Re: Merging core-updates?
--- Original Message --- On Tuesday, February 14th, 2023 at 8:29 PM, Kaelyn wrote: > > --- Original Message --- > On Tuesday, February 14th, 2023 at 2:50 PM, Efraim Flashner > efr...@flashner.co.il wrote: > > [snip] > > > I ended up going a different route and moving xz from the finalize > > packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in > > %boot6-inputs. > > > > I also tracked down the issue in tar and adjusted the testsuite so it > > shouldn't be a problem on 32-bit systems. > > > I just tried building wine-minimal from core-updates at commit da7d615629, > and I think you may have be missing a "!" with the new flag for the tar test > suite (i.e. it needs to be "-k '!tricky time stamps'"). Based on the build > log, right now only the failing test is being run: > > ## - ## > ## Test results. ## > ## - ## > > ERROR: 1 test was run, > 1 failed unexpectedly. > > ## ## > ## Summary of the failures. ## > ## ## > Failed tests: > GNU tar 1.34 test suite test groups: > > NUM: FILE-NAME:LINE TEST-GROUP-NAME > KEYWORDS > > 151: time01.at:20 time: tricky time stamps > time time01 I wanted to give a quick update: once I fixed the test exclusion for tar, I was successful in building wine-minimal on core-updates (which is 32-bit package on x86_64 as well). > Cheers, > Kaelyn > > > -- > > Efraim Flashner efr...@flashner.co.il אפרים פלשנר > > > > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > > Confidentiality cannot be guaranteed on emails sent or received unencrypted
