IRC channel logs
2024-03-14.log
back to list of logs
<old>civodul: great article! <civodul>may be that ‘load-profile’ didn’t exist back then <civodul>working around it may be tedious tho <civodul>you’d need to set PATH, CPATH, and all that <vagrantc>civodul: yes, i guix 1.2.0 ... which is in debian "oldstable" <vagrantc>not a deal-breaker if it can't be done ... but would be nice :) <vagrantc>i have successfully tested local builds of the debian packages based on 1.4.0 and the reproducer and all that. <vagrantc>which is in debian/stable ... slightly more important and significantly more current :) <vagrantc>civodul: We managed to corrupt /gnu/store/ms3fdpsra3mjq03v4z714j4py13xp7py-derivation-that-exfiltrates-fd-65f2395f-15758, meaning that YOUR SYSTEM IS VULNERABLE! <oriansj>looks like the build of f58k22wxj2il4qi7363xqbqr2bg0p7m3-ghc-8.10.7 is broken <oriansj>with libraries/ghc-compact/tests/T16992.run T16992 [bad exit code (99)] <apteryx>I have a librsvg 2.56 failure on core-updates <apteryx>signal: 11, SIGSEGV: invalid memory reference that happens during the check phase <hapst3r>roptat: is there a way to See all your blog posts? I just found one from 07/2022 and but the blog.html shows only the 5 most recent ones methinks <efraim>apteryx: send the librsvg build through again, it happens when the machine is under load <efraim>I've thought about wrapping the 'check phase to run a second time with #:parallel-tests? #f if it fails the first time <efraim>llvm-16 builds without problems on riscv64, so it was just llvm-17 that needed help <Guest50>Hello guix. I am beginner at packaging and I am trying to package python library used in reinforcement learning (a sub-field of Machine Learning). The package is called stable-baselines3 and is well known in the field (and it is MIT Licensed). I managed to pass the check stage and install it on my machine by removing some tests that demanded <Guest50>features not yet implemented (atari games and gpu dependencies mainly) this should not be a problem to use most of the features of the library. There are however two things I am still uncertain about: <Guest50>1) For whatever reason that I do not understand, the check phase pass but the sanity-check does not pass. Error is some torch requirement problem that I do not understand (python-pytorch is in the propagated inputs of the package). <Guest50>Exact error is ...checking requirements: ERROR: stable-baselines3==2.2.1 ContextualVersionConflict(torch 1.13.0a0+gitunknown (/gnu/store/8s0xhjy0apa8vz60cdmb8y7i853wvsaz-python-pytorch-1.13.1/lib/python3.10/site-packages), Requirement.parse('torch>=1.13'), {'stable-baselines3'}) <Guest50>2) the tests take around 1 hour on my laptop, this may be a lot for the CI, do I keep these expensive tests or do I skip tests to keep check time manageable? <dcunit3d>is there a simple way to get a shepherd service to not autostart? <civodul>dcunit3d: there’s no general mechanism for that, but some services have an ‘auto-start?’ field <dcunit3d>i found the build-machine-shepherd service. <dcunit3d>can i extract the value for a service-type record, modify it to add auto-start and then a new service with it? <civodul>hmm i see what you mean; doing that currently is a bit tedious though <civodul>you would need to “redirect” the service type to extend my-own-shepherd-service-type, and that thing would add (auto-start? #f) and pass it on to ‘shepherd-root-service-type’ <zilti>What does it mean if my contribution patch shows up on issues.guix.gnu.org, but on qa.guix.gnu.org it says "Issue not found"? <cbaines>zilti, assuming that you sent the patches a little while ago, they might be old enough now that QA isn't looking at them <cbaines>you can resend the patches to the same issue, and that'll prompt QA to take a look <zilti>cbaines: okay. I sent it on Jan 31st. <dcunit3d>ah ok, thanks civodul. i still need a bit of help working through some of the details for guix internals. this service involves networking, and i still need to find out the best way to modify ip routes & ip tables when i start it. so i'd like to start it manually until then <zilti>cbaines: there's a few, but e.g. 68844 <cbaines>zilti, yeah, that's just a bit too old unfortunately for QA to see currently <cbaines>hopefully in the future we'll have the resources to have QA process more patches (and have less patches waiting around) <dokma>Can I use GUIX to install a package for a fixed duration? Like: "Install package for 10 days and then remove it automatically" ?? <dcunit3d>dokma, the simplest way would be to update the system in 10 days. you could also use `guix deploy` but that's still under development and requires ssh. <efraim>often I'll just use a package from a guix shell, like whenever I need ldd or strace or even curl <dcunit3d>you could also write an mcron service to update the system with a specified system definition, perhaps retrieving that. that should work, but if you've updated the system in the meantime, the system spec would need to be updated as well. <dokma>I'm evaluating switching from Devuan/apt to GUIX <dokma>Hopefully GUIX systems are not married to systemd? <dcunit3d>one last option would be to add a task to mcron that: reads the running system definition from /run/current-system/configuration.scm, deleting lines associated to the package, save to file and run update-system. <dcunit3d>no. it doesn't use systemd at all. it uses shepherd to manage services for the system and for guix home. <dcunit3d>i would suggest running Guix in a VM first. it's very easy to build images that run on various platforms, including docker and qemu. <dcunit3d>there may be better ways of handling timed updates though <dcunit3d>since the system configuration is a lisp file, it can be read into quoted symbols by either scheme or emacs-lisp, mutated and saved to a file. that can be a bit advanced though. <cbaines>nutcase, are you either of the two people involved on that issue? (#65711) <evilsetg>Does anyone know how to give shepherd actions arguments beside the running value of a service? The shepherd manual mentions this is possible but I can't find documentation of how to do that. <flypaper-ultimat>If you look at "guix system edit jami" theres the `enable-account-action' which passes its argument (USERNAME) to the enable-acctount function. <flypaper-ultimat>it also seems to be documented under the section of of `shepherd-action' of "info '(guix) Shepherd Services'" <dcunit3d>evilsetg: if you run herd --help it says `herd [options] ACTION SERVICE [ARG...]` <evilsetg>Thanks, the shepherd-action section in the guix manual had what I was looking for. So the extra herd arguments just get appended to the arguments of `prodecure` in `shepherd-action`. <dcunit3d>i see, yeh flypaper-ultimat already got to it. i just came across the jami service <evilsetg>I'll also check out the jami service, thank you! <apteryx>efraim: seems to happen every time I build with 24 cores on hydra-guix-129 <moesasji>I'm trying to figure out setting up a shepherd service for keyd, which needs a config file in /etc. Is there an example service that does something like this? <efraim>IIRC there are some interesting ctest flags, like rerunning failing tests a certain number of times until they pass <evilsetg>moesasji: The `syslog-service-type` in base.scm does something like that. It extends `etc-service-type`. <moesasji>Thanks evilsetg; that points me in the right direction (I think). Looking at the code for syslog-service-type it looks like I failed to understand how the extension is supposed to work. <dcunit3d>moesasji: nslcd-service-type has %nslcd-activation which modifies permissions in /etc. and nfs-service-type uses etc-service-type to serialize a list for /etc/exports <apteryx>efraim: ah! "under load" really was key! <apteryx>building just librsvg alone, it passed <Googulator>How would one go about reproducing the bootstrap binaries currently used by Guix? The current make-bootstrap.scm seems to build newer versions than the ones downloaded during a Guix bootstrap. <Googulator>Specifically, the static guile tarball built today is 2.0.14, while the bootstrap is rooted in 2.0.9 <civodul>Googulator: hi! these bootstrap tarballs are no longer used on x86 <civodul>and are about to vanish from other architectures as well <civodul>to reproduce the exact same, you’d need to go maybe 8 years back or so <henk_guix1>Hello guix, I'm writing a manifest for a python package that uses rust for building. I can't get it to work, trying to use cargo-io but I can't use any inputs from that <efraim>I'd suggest taking a look at python-pydantic-core. You'll have to mix the cargo-build-system with another build system <h3>How to set `ungoogled-chromium`/`icecat` organization policy plug-ins/add-ons? <old>congrat to the authors! <h3>How to set `ungoogled-chromium`/`icecat` organization policy plug-ins/add-ons in /etc/config.scm? <Googulator>civodul: I'm pretty sure bootstrap-guile is still used, just not the others (gcc, etc.) <RavenJoad>Is there a convenient way to append multiple file-like objects' final strings together? I am trying to build an mcron job for my emails. #~(job (...) #$(string-join (list (file-append mbsync "/bin/mbsync") (file-append next-command)))) <RavenJoad>Also, just to confirm. When inside of a build environment, (invoke) uses the current value of $PATH, right? <lispmacs[work]>just curious, is there some kind of limit on the number of grafts added onto a package? some reset point? <mekeor>ACTION doesn't know any reason why there should be an upper bound for grafts <lispmacs[work]>somebody here was talking earlier about the downsides of grafts when it comes to garbage collection <lispmacs[work]>something like that the GC can see the connection between the original source and the grafted packaged <lispmacs[work]>I did a GC the other day, and then this upgrade has mean re-downloading a few GBs of material and applying thousands of grafts <efraim>there's also the packages needed for the profile hooks <RavenJoad>Nevermind my question about $PATH and invoke. I was double-quoting when I did not need to. <jpoiret>lispmacs[work]: the un-grafted version is locally needed to even compute the derivation for the grafted one, hence why you need to redownload gc'd stuff just to realize the grafted version is already in the store <jpoiret>ungrafting (ie. replacing the original package with the fixed version) is supposed to happen regularly, but we're quite late on the core-updates branch this time around <mik3d>substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <apteryx>I'm getting this locally on core-updates: TESTFAIL: These test cases failed: 1474 <apteryx>--- log/check-expected 2024-03-14 16:50:12.526543235 +0000 <apteryx>+++ log/check-generated 2024-03-14 16:50:12.498544099 +0000 <jpoiret>apteryx: have you run into any other issues with pkgconf? I was a bit busy earlier this week but I should have a bit of time in the next days. Do we drop the pkgconf patches for now and keep them in a separate branch? <jpoiret>as opposed to the libxcrypt changes, the thing I'm worried about here is that we can only if something is wrong once we build (some) dependents, so it might incur a long fix-rebuild cycle for each change <apteryx>jpoiret: I'd say lets keep the patches; breakage seem very rare, and easily fixed. I've only found librsvg that needs the 'remove-libtool-archives' phase, but I'm hitting a bunch of random test failures that make building core-updates a bit of a pain <apteryx>see my previous messages about that one <jpoiret>yeah, i've ran into a couple as well <jpoiret>i don't even think these are specific to c-u <apteryx>we should probably run the 'test-nonflaky' check target of curl <apteryx>I'll do that and push a commit for curl on cu <apteryx>(1474 is marked as flaky in curl sources) <apteryx>it's funny that they let downstream figure the default is to run flaky tests for themselves <lispmacs[work]>curious - do you guys try to integrate your emacs configuration files into your guix home configuration, or keep those separate? <RavenJoad>lispmacs[work]: I keep mine separate. I do not want to have to rebuild some heavy-weight packages just to add a new defun. <RavenJoad>It also keeps the Emacs config portable between other systems I work on. <lispmacs[work]>RavenJoad: that is currently my thinking. though the only downside is I find my list of installed emacs packages (from guix) getting out of sync with what is in my init.el (across systems) <RavenJoad>I install my Emacs packages through Emacs and straight.el too. The only Emacs package Guix provides for me (besides Emacs itself), is emacs-guix. <apteryx>RavenJoad: I'd encourage you to submit the packages you use to Guix's collection <apteryx>mixing and matching can cause problems (and it somewhat defeats Guix's purpose) <apteryx>elisp packages definitions are typically straightforward <RavenJoad>apteryx: I don't really use any special ones. I barely mix-and-match. I just keep Emacs completely separate because I also work on Ubuntu servers and straight.el can get what I want there as well as on Guix. <apteryx>I don't know about straight.el, but you can use Guix on top of Ubuntu, too. <ieure>lispmacs[work], I put my home config in the same repo as my pre-Home dotfiles, which included my Emacs config. Guix Home installs it. Haven't come up with a good solution for the non-Guix case, though. Have to support it because work makes everyone use MacBooks. <apteryx>that seems a good excuse to walk away <RavenJoad>apteryx: straight.el is just Nix/Guix for Emacs specifically. I know about Guix on Ubuntu, but I am not the only user of these servers and don't always have admin access. These are servers I don't have sudo-access on these servers. It's just easier to maintain Guix home & Emacs separately. <ieure>apteryx, You're saying I should quit my job because they make programmers use Macs? <apteryx>not should, just that it's one option :-) <ieure>Tough to get hired out there these days, I'm grateful to have a job that's not some LLM/blockchain/adtech/military trash. <lispmacs[work]>I think I just got what I wanted by putting the emacs packages in a separate file, stored in my emacs configure repo, and then LOADing that from the home configuration file <ieure>I ask about that in every interview, zero of the 20+ places I applied to last year would let me run Linux. About 50% of my past jobs have supported it. Always something I look for. <RavenJoad>Is there a convenient way to append multiple file-like objects' final strings together? I am trying to build an mcron job for my emails. #~(job (...) #$(string-join (list (file-append mbsync "/bin/mbsync") (file-append next-command)))) <mik3d>so i fixed that issue, have now the subs. now i am getting this error <mik3d>bash ./pre-inst-env guix build guile-bootstrap <mik3d> /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash <mik3d> /gnu/store/lgi9x15a0w35mcpd7g1kb9274r6wy4pv-guile-bootstrap-2.0 <mik3d>guix build: error: reading file `/gnu/store/g08l2msvnivyi6x5nw52ak8n17sw9lzr-guile-bootstrap-2.0.drv': No such file or directory <mik3d>how can i rebuild that from source or download it? <mik3d>bash ./pre-inst-env guix gc --verify saved me <mik3d>```ice-9/boot-9.scm:1676:22: In procedure raise-exception: <mik3d>substitution of /gnu/store/rln3p3ds89wv3cww1jimcvhd2kg7qsvw-bash-static-5.1.\ <mik3d>guix build: error: corrupt input while restoring archive from #<closed: file\ <mik3d>going to checkout the last releast of guix and test that now it might be just too new code. <freakingpenguin>Hi Guix. When submitting a patch for something reported on bug-guix, do you still submit the patch to guix-patches? Or in reply to the existing bug issue #? <jpoiret>mik3d: corrupt input while restoring archive is most likely a transient failure of substitution <mik3d>substition is working now the download schema code seems broken <jpoiret>freakingpenguin: submitting the patch to guix-patches will be better because QA will check it <mik3d> 1676:22 5 (raise-exception _ #:continuable? _) <mik3d> 1802:13 4 (_ #<&compound-exception components: (#<&assertion-failure> #<&\ <mik3d>origin origin: #f> #<&message message: "Wrong type to apply: ~S"> #<&irritan\ <mik3d>ts irritants: (#f)> #<&exception-with-kind-and-args kind: wrong-type-arg arg\ <mik3d>s: (#f "Wrong type to apply: ~S" (#f) (#f))>)>) <mik3d> 1676:22 3 (raise-exception _ #:continuable? _) <mik3d> 1674:22 2 (raise-exception _ #:continuable? _)``` <freakingpenguin>jpoiret: Thanks. Is there a preferred method to link the issue and patch? Just put "Fixes blah" in the commit message? <jpoiret>the Fixes: part is good, yes. You can look in the commit log for examples (not everyone does that though) <jpoiret>it's nice to record that in the commit message for future perusers of the git log <nutcase>Dear all, is there any possibility to support someone to merge patch(es) into Guix's master? I am particularly asking because of this one, I'd like to see merged: #65711 <freakingpenguin>Okay, sounds like there's no weird debbugs "you must type this and precisely this" behavior. <jpoiret>mik3d: that requires a log-in, paste.debian.net is preferred <mik3d>i am now rebuilding from the release <jpoiret>freakingpenguin: in general it's better to put a colon after Fixes <jpoiret>most metadata embedded in commit messages follow this format <jpoiret>i think we have a bit of automation around this, ie. when the patch is committed the bug is automatically closed (I think?) <jpoiret>or at least there was some discussion around this in September (iirc) <freakingpenguin>Mailing lists are somehow simultaneously more simple and esoteric compared to what I'm used to. <mik3d>maybe my configuration is borked. <mik3d>so looking at strace of the guix server, one of the sub process is looking for zstd.go and cannot find it <mik3d>wow maybe i just missed that in my build? <mik3d>you would think there would be a check <PotentialUser98>Has anyone ever encountered an error like "suspicious ownership or permission on `/gnu/store/gxj1a7n7a3s8xbyqvk8ax3pa651p59dc-config.scm'; rejecting this build output"? I'm suspecting this is an issue with using EFS drives on AWS. <mik3d>that was it, there is a hidden dependency on zstd that is not caught in the autoconf <mik3d>ok sending a mail to the bugs list <mik3d>"/usr/lib/liblz.so" is the next one i see in the errors :/