Re: Guix release broken without substitutes on ungrafted openssl
Leo Famulari skribis: > On Wed, Feb 15, 2023 at 12:15:21PM -0500, Greg Hogan wrote: >> Installing guix from source fails on the build of openssl@1.1.1l. I >> see the same error on my working system (log attached) when executing >> the command below. The issue looks to be caused by OpenSSL's expired >> test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s >> but it seems grafts are not part of the bootstrap process (substitutes >> disabled). >> >> If this is the correct diagnosis then we should be ungrafting before >> future releases any bootstrap dependencies relating to build failures >> (not necessarily for security updates). >> >> My personal fix was to adapt my installation script to iteratively set >> back then reset the clock, as openssl only builds in the past but >> diffutils-boot0 then fails due to newly created files being older than >> distributed files. > > Thanks for the notes. > > I do believe this has been discussed previously, to be found in the > archives! Here: https://issues.guix.gnu.org/58650 I think the most viable/easily feasible option would be to run OpenSSL’s tests under ‘datefudge’, as discussed in the issue above. Ludo’.
Re: [Internship][Discussion] Do we want to run our own internship program?
Hi! Gábor Boskovits skribis: > 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. [...] >> 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. I think that might be challenging, but we should check applicable rules in each of our countries. BTW, my employer would happily take a student for a 2–4 month internship on Guix-related work; in practice that’s typically for someone already living in France or nearby because the stipend barely covers living expenses, unfortunately. Anyway, not an internship “program” by any stretch, but if someone’s interested, lemme know! Ludo’.
Re: Merging core-updates?
Hi! Leo Famulari skribis: > On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote: >> As discussed at Guix Days before Fosdem, we haven't merged core-updates >> in a very long time. I'd volunteer to lead this effort, but I don't >> know what steps I should follow. Do we have some documentation about >> that? > > The process could be considered "free form". > > Basically, you can try to reconfigure your system on core-updates. It > will fail, many build failures will have to be fixed, and eventually it > will work. Before you get to that point, there are probably more basic tests to do, as people pointed out. Overall, “leading the effort” IMO will be largely about (1) monitoring the status, and (2) sending weekly (?) status updates to bug the relevant people, with the understanding that it’ll take a few weeks before the dust settles down. Ludo’.
Re: ’inherit’ and list-dependent (was Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.)
Hi, Simon Tournier skribis: > 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. In effect that means keeping back the chain of inherited objects, which would lead to space leaks. > Many of us are bitten by this. I remember a recent update of Git which > also missed the dependency of git-minimal. :-) I agree it’d be nice to solve. I can’t think of a good way to do that though. Thoughts? Ludo’.
Re: Using Guix inside a Guix container
Hello!
Konrad Hinsen skribis:
> 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.
That’s an interesting use case! I guess we have a hard-enough time
getting the message through regarding the environment of tasks that we
didn’t really consider the environment of the “driver”.
(Well, in a way, GWL and Guix-Jupyter sidestep the issue by integrating
the mechanism to declare task environments.)
> 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 /
I wasn’t sure ‘--expose=/gnu/store’ would even work… but it does! Kinda
by chance though.
The thing is that ‘-C’ bind-mounts just the subset of the store that’s
needed. To support nested containers, we need to bind-mount the whole
store because new store items may pop up in there over time.
I’d be inclined to add a new ‘-W’ (say) option to (1) share the whole
store, and (2) share the daemon socket. That would be the documented
way to create a container with support for nested containers.
[...]
> 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
That one’s interesting. Reported here:
https://issues.guix.gnu.org/61690
At least there’s a workaround: using ‘-CN’ in the nested container.
Ludo’.
Shepherd news + planned feature removal
Hello Guix! I recently pushed an updated and rebased variant of ‘wip-service-monitor’ in the Shepherd, previously discussed here: https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00350.html I’m going to merge it real soon if there are no objections, with the goal of using it as the basis for 0.10.x and hopefully soonish 1.0.x. The main news are: • Services can now be in one of 4 states: stopped, starting, started, and stopping. (Previously it was just started/stopped.) • ‘herd status SERVICE’ reports those new states. • ‘start’ waits if the service was already starting; ‘stop’ waits if the service was already being stopped. • Services are now started in parallel, to the extent possible. Internally, the big change is that, in addition to a “service registry” actor (a fiber and associated channel where it receives requests), each service has an associated actor (likewise, a fiber) that handles service-specific operations such as ‘start’ and ‘stop’. I find it aesthetically pleasing and fun to work with; incidentally, it should sound familiar to the goblins among us. :-) There’s a couple of shepherd features that I’d like to remove: “persistency” (sic), and the “unknown” service. These things were added in the early days of dmd ca. 2003 but they’re totally untested, likely broken, and probably useless. If you have objections, now’s the time to let it be known. Feedback welcome! Ludo’.
Re: Thoughts on committers pushing simple changes from other committers?
On 2023-02-21, Christopher Baines wrote: > So probably in part due to the recent changes to the commit policy [1] I > think there are more "simple" changes being sent to guix-patches by > committers, which I think is good, but that's got me thinking about the > process for these changes. > > 1: > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9aa2b7419854306b7ae78d4c4f7684316b834b1d > > Generally, I don't push changes for other committers, but I wonder if > that would be helpful now. As someone who submitted a patch a few weeks ago: https://issues.guix.gnu.org/60940 ...which was very recently ACKed, I would definitely welcome someone pushing it! There is also no sign like "this has been reviewed by N people" better than one person authoring it and another person pushing and signing it, with some Reviewed-by or other relevent tags in the commit. For some patches (60940 took a few months of on-again, off-again work, testing, and poking at it), by the time it lands as a submitted patch, I might be a little tired of staring at it. :) Even with a quick (e.g. a couple days) response to a submitted patch, I likely have moved onto other things, it may not be fresh in my mind, the right things may not be in my /gnu/store anymore to quickly re-test it, it may take a bit to apply the patch on the right branch... In this particular case, not only has my attention shifted to other things for a while (e.g. Debian freeze cycle and things entirely outside of computer realms) ... to top it off the machine I tested the changes on ceased to exist! A lot can happen in a few days, or weeks, etc. Obviously, for someone else to push a "my" patch, they may have to go through a lot of the same sorts of issues... but if they have freshly reviewed it, maybe they are more in a state of "working on guix" and it might be less of a context switch? Or maybe not... I guess one way might be to be more explicit about intentions and access when submitting or reviewing patches: "Reviews definitely appreciated, but please let me push it myself when it is ready." "On reviewing this patch, it looks good to me, but I cannot push it myself right now. Push when you can or maybe another committer can do it." "Thanks for the patch, I will push in X days unless you beat me to it!" "Reviewers, if you like this patch, go ahead and push it, as I do not have commit access." "I am so *done* with this patch, any reviewers please consider pushing directly if you think it is ready!" Just a few ideas, could maybe formalize and document it a bit with some specific recommended tags or keywords or whatever... Maybe QA could even look up the committers by email and compare against the submitter to determine if they have commit access or not, and display that information on the patch review pages? No need to be perfect, just more right than not. :) live well, vagrant signature.asc Description: PGP signature
Re: Thoughts on committers pushing simple changes from other committers?
On Tue, Feb 21, 2023 at 03:57:10PM +0100, Andreas Enge wrote: > Concerning other people's patches, what makes this policy a bit complicated > is that I think we do not have a list of committers on the web. Commit access is controlled via membership of the Savannah project: https://savannah.gnu.org/project/memberlist.php?group=guix Thus, that is the list.
Re: Thoughts on committers pushing simple changes from other committers?
On Tue, Feb 21, 2023 at 12:54:32PM +, Christopher Baines wrote: > Thoughts? I think it's fine to push other people's patches. Already, we push the patches of non-committers. It's no big deal to push committers' patches.
Re: Python (was: Merging core-updates?)
Hello, Am Sun, Feb 19, 2023 at 11:24:44PM +0100 schrieb Andreas Enge: > python-graphviz does not pass its tests any more in core-updates, and > I can trace it back to your commit 3d388fe3d0475f2e991ae061cc1364529a97af42. > Adding python-mock back to native-inputs fixes it. I opted for this fix and could compile python-graphviz; this enables me to test the build of icecat now. Andreas
Re: Python (was: Merging core-updates?)
Am Sun, Feb 19, 2023 at 12:30:42PM +0100 schrieb Andreas Enge: > And another one: python-ecdsa This just built. Strange, but I will not complain! Andreas
Re: Python
Am Sun, Feb 19, 2023 at 09:31:44PM +0100 schrieb Andreas Enge: > And yet another one: python-testtool > FAIL: testtools.tests.test_testresult.TestNonAsciiResults.test_syntax_error > FAIL: > testtools.tests.test_testresult.TestNonAsciiResultsWithUnittest.test_syntax_error This is reported upstream here: https://github.com/testing-cabal/testtools/issues/333 No patch yet. Andreas
Re: Python
Am Sun, Feb 19, 2023 at 03:10:03PM + schrieb Attila Lendvai: > weirdly enough, upstream uses one git repo for multiple projects, and uses > prefixed tag names for them. > FYI, there's this long-pending patchset to update the trezor-agent (something > i can test myself): > https://issues.guix.gnu.org/58437#4 > it's been pending so long, maybe it should be updated again. Feel free, but I would say this is independent of core-updates. Well, except that python-trezor-agent does not build in core-updates, but this is due to its dependencies python-ecdsa (already reported in a different message), and, as I just saw, python-configargparse: == FAIL: testBasicCase2 (tests.test_configargparse.TestBasicUseCases) -- Traceback (most recent call last): File "/tmp/guix-build-python-configargparse-1.2.3.drv-0/ConfigArgParse-1.2.3/tests/test_configargparse.py", line 250, in testBasicCase2 self.assertRegex(self.format_help(), AssertionError: Regex didn't match: 'usage: .* \\[-h\\] --genome GENOME \\[-v\\] -g MY_CFG_FILE\n?\\s+\\[-d DBSNP\\]\\s+\\[-f FRMT\\]\\s+vcf \\[vcf ...\\]\n\n(.+\\s+)(.+\\s+)(.+\\s+)(.+\\s+)(.+\\s+)(.+\\s+)(.+\\s+)(.+\\s+)(.+\\s+)positional arguments:\n vcf \\s+ Variant file\\(s\\)\n\noptional arguments:\n -h, --help \\s+ show this help message and exit\n --genome GENOME \\s+ Path to genome file\n -v\n -g MY_CFG_FILE, --my-cfg-file MY_CFG_FILE\n -d DBSNP, --dbsnp DBSNP\\s+\\[env var: DBSNP_PATH\\]\n -f FRMT, --format FRMT\\s+\\[env var: OUTPUT_FORMAT\\]\n' not found in "usage: setup.py [-h] --genome GENOME [-v] -g MY_CFG_FILE [-d DBSNP] [-f FRMT]\nvcf [vcf ...]\n\nArgs that start with '--' (eg. --genome) can also be set in a config file\n(/etc/settings.ini or /home/jeff/.user_settings or /tmp/guix-build-python-\nconfigargparse-1.2.3.drv-0/tmprdqc6hnh or specified via -g). Config file\nsyntax allows: key=value, flag=true, stuff=[a,b,c] (for details, see syntax at\nhttps://goo.gl/R74nmi). If an arg is specified in more than one place, then\ncommandline values override environment variables which override config file\nvalues which override defaults.\n\npositional arguments:\n vcf Variant file(s)\n\noptions:\n -h, --help show this help message and exit\n --genome GENOME Path to genome file\n -v\n -g MY_CFG_FILE, --my-cfg-file MY_CFG_FILE\n -d DBSNP, --dbsnp DBSNP\n[env var: DBSNP_PATH]\n -f FRMT, --format FRMT\n[env var: OUTPUT_FORMAT]\n" and many more. It would be nice if someone actually using Python could sort out the mess... Andreas
Re: Python (was: Merging core-updates?)
Am Sun, Feb 19, 2023 at 10:59:35PM + schrieb Kaelyn: > It was mentioned recently that python-pycryptodome is / should be a drop-in > replacement for python-pycrypto (it is also says that in the package > description); Apparently it is not, as Lars wrote. And in any case, it does require some patching: I tried to compile python-potr with either of python-pycryptodome and python-pycryptodomex, and it fails in the check phase, where it tries to download pycrypto via pip. > perhaps replace the python-pycrypto input with python-pycryptodome for > python-potr, with a snippet to change the pycrypto dependency to pycryptodome > in python-potr's setup.py? Indeed this would be an alternative; but then here, I would still argue that it is not a "drop-in replacement" for python-potr (in C, one could imagine a separate project creating a library with the same soname). > After taking a peek at the poezio and python-potr git repos, the main > alternative I can see to patching the dependency is to remove python-potr > from poezio's inputs since python-potr is listed as an optional dependency in > poezio's setup.py (for its OTR plugin). But without python-potr, the tests fail... So it may be optional, but not for the tests. I took the liberty to update poezio while keeping the python-potr dependency, as it does not worsen the situation, and could be argued to improve it. Andreas
Re: Ungoogled-chromium in core-updates
Am Mon, Feb 20, 2023 at 09:41:23PM +0100 schrieb Andreas Enge:
> It is also in the Debian patches as fixes/clang-and-gcc11.patch.
It helps to go further, new patch attached.
Now I get until the message below.
[45812/52515] CXX
obj/third_party/blink/renderer/core/core/attribution_src_loader.o
FAILED: obj/third_party/blink/renderer/core/core/attribution_src_loader.o
fatal error: error in backend: IO failure on output stream: No space left on
device
22GB of free space are not enough :-(
I may give it a try on bayfront.
Andreas
>From 203cc1bdaaf614a3a99d60d79daa4cd280bc617c Mon Sep 17 00:00:00 2001
From: Andreas Enge
Date: Mon, 20 Feb 2023 21:17:48 +0100
Subject: [PATCH] gnu: ungoogled-chromium: Adapt patches.
* gnu/packages/chromium.scm (%debian-revision): Move to a later release
for Debian patches.
(%ungoogled-origin): Update hash accordingly.
(%debian-patches): Enable "fixes/clang-and-gcc11.patch".
---
gnu/packages/chromium.scm | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/chromium.scm b/gnu/packages/chromium.scm
index e321ae3fe6..47153e3531 100644
--- a/gnu/packages/chromium.scm
+++ b/gnu/packages/chromium.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019-2023 Marius Bakke
;;; Copyright © 2019 Alex Griffin
+;;; Copyright © 2023 Andreas Enge
;;;
;;; This file is part of GNU Guix.
;;;
@@ -318,7 +319,9 @@ (define %blacklisted-files
(define %chromium-version "109.0.5414.119")
(define %ungoogled-revision (string-append %chromium-version "-1"))
-(define %debian-revision "debian/102.0.5005.61-1")
+(define %debian-revision "debian/103.0.5060.53-1")
+ ;; This is the first release supporting openjpeg@2.5 in openjpeg.patch;
+ ;; it still includes jsoncpp.patch, which also appears to be needed.
(define %arch-revision "a0b214b3bdfbc7ee3d9004a70494a2b9e3da2c80")
(define %ungoogled-origin
@@ -342,7 +345,7 @@ (define %debian-origin
((_ version) version
(sha256
(base32
- "1ln6r1qzlr7dsgvcbssvvc34my4mpkwv9hmvlb2dhjncs7isp65j"
+ "0bmbp1y0cykcbjhvsk330d11f7qnwmapcwxv76vdbl8cjfb6h60w"
(define (origin-file origin file)
(computed-file
@@ -355,7 +358,8 @@ (define (debian-patch name)
(define %debian-patches
(map debian-patch
- '("system/jsoncpp.patch"
+ '("fixes/clang-and-gcc11.patch"
+ "system/jsoncpp.patch"
"system/zlib.patch"
"system/openjpeg.patch")))
--
2.39.1
Re: Thoughts on committers pushing simple changes from other committers?
Am Tue, Feb 21, 2023 at 12:54:32PM + schrieb Christopher Baines: > Generally, I don't push changes for other committers, but I wonder if > that would be helpful now. Personally I prefer to push my own changes. And let other people push theirs if they can. Actually I think we are responsible of the patches we push, and less so of the patches we author :) This is consistent with the signatures as well. Concerning other people's patches, what makes this policy a bit complicated is that I think we do not have a list of committers on the web. So I might accidentally push another committer's patch, or conversely not push someone's patch who I erroneously assume to be a committer. Andreas
Thoughts on committers pushing simple changes from other committers?
Hey! So probably in part due to the recent changes to the commit policy [1] I think there are more "simple" changes being sent to guix-patches by committers, which I think is good, but that's got me thinking about the process for these changes. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9aa2b7419854306b7ae78d4c4f7684316b834b1d Generally, I don't push changes for other committers, but I wonder if that would be helpful now. Take #61416 [2] as an example, I replied saying the change looked good to me, but maybe it would be easier if I'd just pushed it along with the changes I was pushing for non-committers? 2: https://issues.guix.gnu.org/61416 Obviously I think this wouldn't apply to all changes, just the simpler ones (for some vauge definition of simpler). Thoughts? Thanks, Chris signature.asc Description: PGP signature
Re: Error booting aarch64 installation image
Hi Roman, Roman Scherer writes: > I think you need to use --image-type=efi-raw for this to work. Unfortunately, this doesn't build and produces yet another errors. > I actually installed my Guix system from another distro. I roughly > followed this guide here: > > https://guix.gnu.org/blog/2019/guix-on-an-arm-board/ Thank you! I spent all day yesterday playing with this idea. And it actually works. For me the steps were like this: 1. Launch Debian ARM image. 2. Install Guix on it as package manager 3. Attach an empty qcow image as a storage device (/dev/vdb for me) 4. Partition and format /dev/vdb 5. Mount root and boot efi partitions. 6. Edit file-system entries in lightweight-desktop.scm and save it as /mnt/etc/config.scm 7. Run: guix system init /mnt/etc/config.scm /mnt 8. Reboot And this works! Now I've just discovered in guix-cookbook that there is a special linux-libre-arm64-generic kernel for ARM boards and that u-boot is usually used to boot them. But in my case it works with grub and a default kernel. Are there any advantages of switching to linux-libre-arm64-generic kernel?
