<sneek>mrprofessor, you have 1 message! <sneek>mrprofessor, nckx says: Good morning/evening to you. <roptat>tomorrow, I'll try to add support for routes, and I'll call that 1.0 :) ***sorki is now known as srk
<pkill9>i like that you can create filesystems in files <pkill9>i made a btrfs filesystem within a file <shcv>suppose I want personal mcron jobs (specifically for fetching mail with mbsync); what's the best way to set that up with guix? <pkill9>shcv: what do you mean by personal? <pkill9>if you mean for just your user, then you can install the mcron package and run it as a daemon with your user <pkill9>and add the cron job using either normal cron syntax or mcron's scheme syntax <shcv>I think that's probably what I want; but how do I set it up with shepherd to start automatically? <pkill9>you could just add an mcron job to the mcron service, though it would run it as root, although I think you can change this <pkill9>if I was to do it in a more fancy way, I would make a service that launches a user instance of shepherd, and then make a cron service for my user's shepherd, which would automatically start <pkill9>(and add the cron job to the user's mcron) <shcv>the latter sounds good, I think <shcv>I guess I can look to see how to start a service as a user <shcv>maybe somehow customize the shepherd service? <pkill9>i think you can pass it as an option actually <pkill9>then again the mcron service itself will run as root <pkill9>you could just use sudo to have it do whatever as your user <lle-bout>the worse performance of emacs-vterm compared to xfce4-terminal actually slows down builds of some GNU Guix packages due to printing output really significantly <i1l>neovim has good term.. <lle-bout>it's also fast in emacs-vterm, just not as fast as xfce4-terminal :-| <i1l>well, i will see. i just realized emacs-vterm is some package i didn't ever used. <i1l>not M-x shell or ansi-term <lle-bout>I am thinking it may have been the guix-prettify-mode I had on <lle-bout>efraim: so everything works out alright on your branch, can we push then? <lle-bout>efraim: how can you ensure the hashes didnt change on other archs? Like do we have a command to run to check that? <lle-bout>efraim: I guess I can just try building hello and see if it actually does anything more than printing my existing store item <lle-bout>efraim: it prints my hello store item! so all good and awesome! <lle-bout>it shows it's possible to make entire ports of GNU Guix without having to go through core-updates :-D <i1l>sneek: is marusich currently down or only for me? <apteryx>lle-bout`: xterm with fastScroll enabled is hard to beat for raw performance I think ***lle-bout` is now known as lle-bout
<i1l>xorg + xterm = xterm. rust1 + rust2 + ... rust3x + alacritty = alacritty. latter need to be built first. <efraim>lle-bout: awesome. Do the tests pass? <lle-bout>At least on top of my Fedora ppc64le system <lle-bout>efraim: so we just need to do that and then update the guix package and we're done? <lle-bout>efraim: then we can work through adding cuirass? <efraim>I think so. I only got 4 hours of sleep last night so I'm a bit foggy right now <lle-bout>efraim: the machine you've got access to is from OSUOSL <lle-bout>efraim: alright, do you think the patches need further review or..? <efraim>I'll probably go over them again and make sure they're really good <marusich>efraim, lle-bout I'm still doing "guix pull" - there was a failure in libgc which appears to be a non-deterministic test failure (perhaps due to running the tests in parallel). I'm still building stuff. I'd like to wait until someone confirms that guix pull works, and the pulled guix can continue to work. <marusich>however, i was able to upgrade the package fine in my local checkout and build the release binary, which is great <marusich>FWIW, I applied the patch I sent to ludo in my last email (syscalls: mounts: Fix a matching bug.), but I guess it might work even without it - as long as guix pull etc. doesn't rely on that new procedure, which I don't think it does. <marusich>anyway, i'm going to do something else while it builds. <efraim>lle-bout: unzip-case-insensitive.patch seems to be missing ***apteryx_ is now known as apteryx
<lle-bout>efraim: it failed to apply and I didnt bother so much <lle-bout>efraim: oh.. I named it wrong in local.mk or something? <lle-bout>okay then it did apply and thanks for fixing it. <lle-bout>efraim: I did test my changes though, since it built <lle-bout>efraim: on i686-linux: error: invalid zip file with overlapped components (possible zip bomb) <lle-bout>so it means the CVE-2019.. patches are wrong <lle-bout>and since Fedora doesnt test i686 anymore.. <efraim>with some emulation it also fails on armhf but not aarch64 <lle-bout>efraim: we should probably use code from that fork instead of relying on an upstream that doesnt publish any releases anymore <lle-bout>uhm nevermind it may not actually have that goal <lle-bout>(to replace unzip upstream, just zipbomb fixes) <hapster>can someone tell me which is the right channel for emacs-lisp? <davidl>Hi, the recent (since a few months) updates to cuirass have broken my config which is essentially just a copy of the one in the manual. How am I supposed to write the equivalent configuration as what's currently described in the manual? <davidl>For example, #:proc-file . "build-aux/cuirass/gnu-system.scm" doesn't exist in the guix repo anymore but is mentioned in the manual. <lle-bout>davidl: it also will interest me to see your full configuration once you've converted it, since I would also very much like to run Cuirass and do not currently. <davidl>lle-bout: Ill try and remember. It may take a long time for me though to get it done and tested. <davidl>lle-bout: we'll see who finishes first with a working config :-) <avichi>Hello world! Any idea how to solve "missing" BBB02DDF2CEAF6A80D1DE643A2A06DF2A33A54FA key at $guix pull (the key is in .guix-authorizations)? <lle-bout>avichi: what error are you getting? we had an incident earlier, where some committer signed a commit with a key not registered in the keyring, maybe you're affected by that? If so you could run with --allow-downgrades exactly once but not sure that's your issue - you're using 'guix pull', not a local clone? <avichi>getting "guix pull: error: could not authenticate commit 9edb3f66fd807b096b48283debdcddccfea34bad: key BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA is missing" <avichi>I am very confused by this commit authentication story: is the $gpg --recv-keys required on this key? will guix consult ~/.gnupg for pubkey for this signature? where can I read about how this architecture is supposed to work? <nckx>‘commit [...]bad:’, hum. <nckx>avichi: No, no, and probably in ‘6.8 Specifying Channel Authorizations’ if anywhere. Guix itself is, mostly, just another channel. <avichi>well I was a bit put off by this 9edb*bad commit, but I am currently suspecting something is messed up in origin/keyring. why is this an unrelated branch and not a separate repo? <nckx>If you're building/pulling from your own repository, you need to keep the ‘keyring’ branch up to date. <avichi>I bootstrapped latest guix from git on ubuntu, does $guix-daemon look at ~/.cache repo for package info, but takes origin/keyring from the repo it was bootstrapped from? <nckx>I don't think so; authenticate-repository takes a single repository parameter, both as the one being authenticated & the one providing the keyring. <avichi>yes, I don't see any accesses to bootstrapping repo in strace. Still, even removing ~/.cache/guix does not solve the issue somehow, then I get Git error: cannot locate local branch 'origin/keyring' <avichi>shall I branch 'keyring' branch to local 'origin/keyring' manually?? <profmakx>anyone else have the problem that emacs segfaults in guix? <nckx>avichi: ‘guix show origin/keyring’ must show commit 3da8e4a6587d05145d1cad94ef6183d34bac7555. <nckx>How you do it depends on your set-up, but Guix assumes that your ‘upstream’ remote is called origin (git's default name). <avichi>guix show: error: origin/keyring: package not found <avichi>ok, so 'origin/keyring' is not a branch, but should really be branch 'keyring' from 'origin'? <avichi>if I checkout 'keyring' from 'origin' then it should the right key(s), why does $guix pull then complain? <avichi>its totatlly messed up: if I start with "clean" keyring from origin containing keys, the next $guix pull messes it up with the mainline branch (master) which no longer contains keys <NieDzejkob_>eh, it's not guix show origin/keyring but git show origin/keyring ;) <lle-bout`>davidl: thanks, but recently it was removed I think <nckx>avichi, NieDzejkob_: I literally can't type ‘git <thing that is also a guix command>’ anymore. <narispo>nckx: grammars are defined in JSON afaict <nckx>‘Tree-sitter grammars are written in JavaScript, and Tree-sitter uses Node.js to interpret JavaScript files’ <narispo>Someone asked in the talk I watched and they wrote some grammars in Emacs Lisp without JavaScript or node involvrd <nckx>Weird. My quote was also from their home page. <avichi>ok $git shows origin/keyring = 3da8e4a6587d05145d1cad94ef6183d34bac7555, but still $guix pull does not work until I do $git switch -c origin/keyring but then the keys are not there <narispo>avichi: so you guix pull from a custom repo <nckx>avichi: That sounds like you created a new branch called literally "origin/keyring", instead of a "keyring" branch on the "origin" remote. <nckx>Delete it with ‘git branch -D "origin/keyring"’ before it gets too messy. <avichi>even if I do $git branch -D keyring and then do $git switch keyring (which shows the keys), the next $guix pull messes up keyring again <nckx>‘guix pull messes up keyring’ -- guix pull can't write to your repository, so what the hell are you doing 😃 <nckx>Are you mucking about in ~/.cache? <avichi>it can write, I tried already multiple times to remove stuff from ~/.cache/guix and start from scratch <nckx>avichi: It cannot write anywhere but ~/.cache. <avichi>ok, but why does it try to checkout origin/keyring into m?aster <nckx>It sounds like you're doing something very weird (like modifying ~/.cache/guix/checkouts/...). <nckx>avichi: Where is your local Guix repository directory, and how are you pulling from it? <avichi>you mean ~/.cache/guix? yes it uses that <narispo>so it should work already, or, you were affected by the earlier bug or then someone is MITM'ing you <nckx>Why are you modifying ~/.cache? That's guaranteed to break things. <avichi>I don't modify it, but guix pull does not work out of the box. I checked out guix from that repo in /usr/local/src, bootstrapped that and started guix-daemon <avichi>then I do guix pull and that fails <avichi>then I go to ~/.cache/guix/checkout/pf* and do <nckx>So /usr/local/src/<something> is your local Guix repository. <avichi>then I reset with $git checkout master <avichi>but if I strace guix it never accesses /usr/local/src <nckx>Just rm -rf ~/.cache/guix, nothing good will come from this. <nckx>Yeah, but then you clobbered it by hand again. <avichi>I get: guix pull: error: Git error: cannot locate local branch 'origin/keyring' <narispo>It will not work better by touching it <nckx>avichi: <never accesses /usr> That sounds plausible. How would Guix know where to look? <avichi>I configured it with default settings, which prob means it uses ~/.cache/guix <narispo>It would look in that /usr/local/src/guix repo if you somehow did: guix pull --url=file:///usr/local/src/guix <nckx>The problem is you're doing something very custom, without understanding exactly what, and it's hard for us to figure out exactly what too. <avichi>just wanted to play with it, by using latest sources <avichi>the only custom thing was to do --prefix=/usr/local, I guess <narispo>you shouldnt get that key error if all you did was installing GNU Guix from source then run 'guix pull' <nckx>avichi: You added --localstatedir=/var as well? <nckx>OK, as long as that's the only localstatedir you've used on that machine it should still work. <avichi>yeah, my thinking too. what can go wrong? <nckx>Maybe TTYL. Good luck in any case. <narispo>avichi: describe all steps precisely you did to install GNU Guix <avichi>(this included installation of various guile libs from git/apt sources) <narispo>how can you run guix-daemon if it's not compiled yet <avichi>5. guix pull (results in cannot locate local branch 'origin/keyring' ) <avichi>I have no other guix on the system <narispo>anything special in your gpg config? <narispo>passed build users group to guix-daemon? <avichi>guile-gcrypt-0.2.1, guile-json-3.2.0, etc. <avichi>yes, I am using my own group for that <avichi>the strangest thing is that out-of-the box, keyring branch is correct. but once I do $guix pull and inspect keyring again, it is clobbered <narispo>avichi: when you go in that .cache guix checkout, what's the last commit hash on top when you run: guix log origin/keyring? <avichi>git log, you mean? guile-git-0.3.0 <avichi>git log origin/keyring = 3da8e4a6587d05145d1cad94ef6183d34bac7555 <avichi>guix pull: error: Git error: cannot locate local branch 'origin/keyring' <avichi>but the branch is there, since I can checkout it <narispo>don't checkout anything ever in guix cache repos, git log is a non-intrusive operation, use that <narispo>delete /usr/local/var/guix and .cache/guix <narispo>if you try: guix pull --url=file:///usr/local/src/guix - does it work? <avichi>its still pulling from savannah, a bit slow I guess. will try the other url thereafter.. <avichi>what's the reasoning behind maintaining these keys in an unrelated branch rather than in a separate repo? <avichi>its the same error: cannot locate local branch 'origin/keyring' <narispo>you ran git fetch --all in that local clone? <avichi>so far I did nothing to ~/.cache <narispo>Never touch the .cache/var things ever manually <avichi>no, it was from savannah. now its updating from /usr/local/src/guix, but I don't understand why its so slow, since HEAD is identical <avichi>I only starting touching those out of desperation;-) <narispo>guix pull compiles GNU Guile code so <narispo>git fetch --all and git remote -v in that /usr/local/src/guix repo what does it say? <narispo>looks like you are getting the wrong error message for another hidden issue more and more <narispo>are you having a problematic network? <narispo>now, try using --localstatedir=/var in addition to your --prefix just to make sure of something <narispo>if it still doesnt work, it's some bug somewhere <avichi>nothing special about the network ok, call it a day for now, will try with --localstatedir=/var and report back <narispo>open a bug at bug-guix@gnu.org after that <narispo>I monitor help channels daily so it's new <nckx>Seriously? I just returned. <nckx>narispo: Did they do the equivalent of ‘git checkout keyring && git checkout master’ in /usr/local/src/whatever? <narispo>nckx: they git fetch --all and the remote was called origin so it's definitinely there <narispo>I made them use --url=file:///usr/local/src/guix <nckx>Hmkay... still feel like something obvious went wrong at some point. <narispo>so in my opinion it's misleading error <narispo>initially they didnt say missing keyring branch <narispo>but we are missing elements, they didnt describe precisely what they did <nckx>I think it's hard to say whether it was misleading (you may well be right!) since (a) the error did change to something expected and (b) we don't know exactly what weird state the cached checkout was in before it did. <narispo>maybe they misconfigured some dep lib and it causes that error <Aurora_v_kosmose>Any plans on making recursive fallback an option? The current build --fallback option seems to only affect the direct top-level invocation, rather than every part of the dependency tree that might need local building. <efraim>there was a recent change with guile-git needing to be a newer version than what is is debian <Aurora_v_kosmose>I'd managed to get a few pulls working by specifically manually invoking "guix build --fallback $failed_deriv" before pulling again. <Aurora_v_kosmose>But the thing is, since I'm also adding --fallback to "guix pull", shouldn't what I did not have been necessary? <nckx>narispo: <I made them use --url=file:///usr/local/src/guix> and <they git fetch --all and the remote was called origin so it's definitinely there>: That's not enough, though <nckx>If you ‘git clone https://git.savannah.gnu.org/git/guix.git $HOME/g && guix pull --url=file://$HOME/g’ you'll get “guix pull: error: Git error: cannot locate remote-tracking branch 'origin/keyring'”. It doesn't matter that ~/g has a remote called ‘origin’ that itself has a ‘keyring’ branch. <nckx>You need to (cd ~/g && git checkout keyring) for it to work. <nckx>Indeed, we're missing too much info. <smartineng>hello is it normal that inside "guix environment --container" there is no /usr/bin/env ? <apteryx>smartineng: it's how it is now, yes. And it's annoying, yes <apteryx>but it matches closely what's available in the guix build container <smartineng>apteryx: but is it suppose to be like that by design or it's just yet another temporary annoying thing to fix in the future? <nckx>smartineng: It's by design. You can use --expose= to add it if you want. <smartineng>nckx: you right I forgot about that option thx :) <apteryx>I think one nice feature that guix environment -C could have would be some transformation options similar to 'guix pack', where we could require some profile location to be linked somewhere; eg. --symlink=bin/env=/usr/bin/env <apteryx>nckx: the gripe I have with --expose is that it uses stuff from the host; if you build a container for another system that doesn't help much, or it's a kludge at best (--expose=$(guix build -s armhf-linux coreutils)/bin/env=/usr/bin/env) ? <nckx>I think sharing some things with pack makes sense. <ennoausberlin>Hello. I'd like to install guix on a foreign distro (armbian aarch64), but the store should not reside on the internal emmc, but on an nvme partition. What is the best way to accomplish this? <ennoausberlin>Aurora_v_kosmose: I did this a few minutes ago, but I vaguely remember, that I had problems the last time I am doing this. It was two years ago. <Aurora_v_kosmose>I wasn't very involved with Guix back then, I can't guess what went wrong or why. <nckx>I'd recommend btrfs but ext4 is fine. <Aurora_v_kosmose>If it goes wrong, do mention it, as that shouldn't happen and would need to be fixed. <nckx>It's safer. The two must be kept in sync, and the risk of $something going wrong are greater when there's no single file system to enforce that. <ennoausberlin>Aurora_v_kosmose: I dont have any experience with btrfs. I use it on a Garuda vm, but did neither tuning nor special management there. <ennoausberlin>I better create a second partition for the /var/guix directory <ennoausberlin>What size might fit? At the moment its almost empty. Less than 50 MB. <nckx>ennoausberlin: On my laptop, /var/guix is 372M (72G store), on a build server (bigger store) it's 1.8G. <nckx>I wonder if bind mounts would work. They work on any file system unlike subvolumes, but I haven't tested whether guix-daemon like ro-re-bind-mounting a bind mount. <Aurora_v_kosmose>nckx: I mainly brought up subvolumes due to "the risk of $something going wrong are greater when there's no single file system to enforce that", as there would now be a single filesystem keeping watch. <nckx>Aurora_v_kosmose: And you were right to do so. Bind mounts are ‘the same file system’ from a VFS perspective as well. <lambdanon>Hey all, I'm trying to learn how to use the copy-build-system. The documentation says that a keyword called #:install-plan is used to exposed to make it easy to copy files, but I'm getting an invalid field specifier error when I use it <lambdanon>Ah, forgot a pair of parens, a source, and a home-page. <lambdanon>What happens when the source is included with the package definition? I want my package.scm and my init.el in the same repo ***jx97 is now known as jx96
<Aurora_v_kosmose>ar: /gnu/store/cijcw7rch7w3qa726yd7d2payz94603p-ecl-split-sequence-2.0.0/lib/common-lisp/ecl/split-sequence/split-sequence.a: Permission denied. <marusich>lambdanon, it isn't clear to me what you're trying to do. Although it may not be relevant to your question, I see you wrote #:install-plan '(("init.el" "$HOME/.emacs.d/")), which seems incorrect because $HOME will not refer to anything meaningful in the build environment. <lambdanon>marusich: My goal is to make my own channel so that, on my laptop, I can just include the channel and do guix install blueberry-emacs-config. It'll install my emacs packages and copy my init.el into ~/.emacs.d <nckx>Aurora_v_kosmose: Something is trying to make ‘ar’ write to /gnu/store, which is read-only. Something needs to not do that, using whatever means necessary. <lambdanon>Once I know how to make a channel, I'll make packages other configs, like my XFCE config, my GTK themes, my custom zsh prompt, etc <marusich>I haven't done something like that before, so I'm not sure what a good way to do it is, but I think that you can't use $HOME to directly copy something like that from the store to your home directory in the package definition. <nckx>Possible! Not a CL person. <marusich>lambdanon, no, the argument to a build system can change how the build works, e.g. adding a phase to patch a file before or after the build, but it happens in the chroot-like build environment that the guix-daemon sets up. You can't access the outside world (unless you are running guix-daemon in an unusual configuration like with --disable-chroot, which is not recommended because it defeats the purpose of using an isolated build environment) <marusich>Alternatively, if you can arrange to put everything you need into a single emacs package, you might be able to do write some elisp to just load that one package on start-up, and maybe that would be good enough. <marusich>Like, maybe if you put your init.el into a package, and then load it from your actual ~/.init.el, then perhaps you would be a in a position where you could just do "guix package -m my-manifest.scm" which contains my-init (your package) and all the other emacs-whatever packages you want, and the init file from my-init would automatically be used, which would configure everything else. <lambdanon>That's generally what I'm trying to do, but the problem I found with just using a manifest was that, when I tried to use a manifest for all my emacs packages, it uninstalled everything else, like pidgin, krita, kicad, etc.; meaning I'd need to make some kind of hierarchical appending of packages <lambdanon>So I thought "If I can't just use a manifest to install my packages without it encroaching on my other stuff, I'll make my emacs config into a package and have the relevant emacs packages as dependencies" <marusich>So that's a question of "how can i install a subset of packages without altering what i already have installed?" you can probably do that by declaring the inputs to be propagated-inputs, so you can install your one pacakge and it will install all the ones it needs, too. Or you could just put your emacs packages in a separate profile, and manage it independently. <marusich>Either way, Guix doesn't generally manage things besides items in the store (/gnu/store by default). There are a few exceptions: it manages its database in /var/guix (or wherever you installed it), and it will create/modify symlinks in places like ~/.guix-profile to provide atomic upgrade/rollback of profiles. But that's about it. On Guix System, it does more when you run "guix system reconfigure," like setting up /etc/passwd and so forth, too. <marusich>I don't do what you are trying to do, so I can't recommend a way to do it, but if I were going to try, I would think about looking at the guix home manager, I would try using a separate profile for my emacs stuff, and I would try manually crafting a minimal ~/.emacs file that loads my custom init package if it's present, so that I can put all my customization into a custom init package (maybe with propagated-inputs) and then just install it and <lambdanon>If I point the (source ...) declaration, it depands I have a hash. How do I calculate a hash from a git repo? <apteryx>guix refresh -l python-sphinx returns ~400 packages; is sphinx really fit to be updated on master? <mdevos>lambdanon: one possible method: enter a bogus hash. "guix build" will complain with "X does not match Y" or something. Copy the hash <mdevos>alternatively, there is "guix hash -rx" <lambdanon>I entered "what" as a hash, did guix build, and it returned nothing <mdevos>Nothing at all? I'm assuming you're defining a new package <mdevos>did you do "guix build $THE_PACKAGE", "guix build -f package.scm", ...? <nckx>apteryx: Is the question ‘is sphinx really fit to be updated on staging’? <lambdanon>mdevos: Ok, I tried the latter. I'm copy-build-system incorrectly, so I have bigger problems rn <nckx>lambdanon: Try a valid hash like 1yad211gcm5zmmm6a7ng5bbpsl73yf0qbpczzgl4vgbq0qfy29mx . <nckx>(sha256 "what") should never work. <lambdanon>How am I supposed to use copy-build-system? It says that #:install-plan is provided to copy files, but doesn't specify where to put #:install-plan <lambdanon>I tried (build-system (copy-build-system #:install-plan '(("init.el" "~/.emacs.d/)))), but that's incorrect <apteryx>nckx: I somehow thought many more packages would depend on it <lambdanon>I'm just going to use gnu-build-system and make a makefile that just consists of all: cp init.el ~/.emacs.d <nckx>apteryx: You're probably right to be sceptical, but I don't see any suspicious inheritance, and python{2,}-sphinx combined are still only 476. <ennoausberlin>Aurora_v_kosmose: I installed guix on nvme, but I am a little bit nervous, because I had to edit the install script, which tests for the existence of a former guix installation by checking /gnu and /var/guix <nckx>lambdanon: I've never chosen copy-build-system over gnu-build-system with e.g. 'configure and/or 'build removed. Some of its default phases are still nice to have & I've never packaged pure data that didn't benefit from them. <nckx>Just use whatever (sane...) works now, refine later. <ennoausberlin>I removed the tests and replaced the mv command with cp -R but now the timestamps of the store objects look different. They should be unixtime Zero or not? <lambdanon>Got a problem with the hashing system. Invalid-base32-character: #\e. <lambdanon>The sha256 hash is correct, but I'm not using the right struct. I'm currently doing (sha256 (base32 "<my-hash>")) <nckx>ennoausberlin: They should be, but it's easy enough to ‘find /gnu/store -exec touch -d @0 {} +’ or so. I mean, I don't understand why you're working from an existing store, but you've come this far. <nckx>You've probably lost deduplication (so your store uses more space than needed) but that's not fatal. <mdevos>"touch a; stat a; cp a b" results in different timestamps for a and b, so "cp" can't be used as-is for copying the store I think <ennoausberlin>nckx: I do not work from an existing store, but had to mount the partitions to /gnu and /var/guix. So the installer thought there was an existing guix already <nckx>No, you'd best use rsync. <nckx>But since everything has timestamp 0 you can easily recover from cp. <nckx>ennoausberlin: Oh. Hm. Weird. <nckx>lambdanon: base32 implies no ‘e’. Are you using a hash you got by running some other base32 tool? Guix's (=Nix's) ‘base32’ != other ‘base32’s! <nckx>Use guix hash to get Guix's base32 version. <lambdanon>When I wrote that i got the hash by running find . -type f -exec sha256sum {} \; | sha256sum <lambdanon>After that, I tried running guix hash -H sha256 blueberry-emacs-config.scm <lambdanon>After trying the latter, I put the output into (sha256 "The output of that previous command") <ennoausberlin>nckx: I will try to touch every file in the store with -d @0 <nckx>lambdanon: Odd, ‘guix hash -H sha256’ is equal to ‘guix hash’ which is correct. <lambdanon>nckx: Am I supposed to apply it to the whole directory? <nckx>lambdanon: What is the URL of your source field? <lambdanon>when I put the correct hash into the declaration, the hash of the file changes, and so the hash in the file no longer matches the hash of the file. How do I stop this cat-and-mouse game? <nckx>Oh. Oh no. Oh no that won't ever work. <nckx>You can't put a file's hash into itself. <lambdanon>The URL is a git repo which contains the package declaration itself <nckx>I can't think of a way to make that work. <lambdanon>Do I need to put the package declaration and my init.el into separate git repos? <lambdanon>What happens when you want your package declaration to be in the same repo as the stuff it's supposed to be packaged with? *nckx AFK for several hours now. <leoprikler>Now that we have 4d00185d66c9bd047dfe3077ed89a6a6129429ee, should we rewrite most of our crates-*.scm? <leoprikler>in particularly moving #:cargo-inputs to inputs and #:cargo-development-inputs to native-inputs <efraim>I just tried poking rust-minisign, walked away pretty quickly <efraim>I might try a few of alacritty's dependencies first, or switching librsvg-next or newsboat away from cargo-build-system <efraim>It'll take some planning to get right <thomassgn>Hi guix! What does "guix system: error: corrupt input while restoring archive from #<closed: file 7f65209f35b0>" mean? I keep getting it when I run build commands (packages or system). I've been getting these for a while now, even though I run guix pull before the system reconfigure command. <thomassgn>I ran some guix gc commands now and it gave the same error with a different store item <leoprikler>As far as I understand Guix either reads from a port or dies trying. <efraim>Can you tell if they're gzip substitutes? <leoprikler>shcv: you simply add a line to your ~/.profile, or a shepherd autostart to GNOME or… <pkill9>make a simple service and specifiy #:user <shcv>how do you specify #:user? I finally found one example of a service that passes it to make-fork-exec-constructor; is there an easier way for modifying the existing shepherd-root-service? <leoprikler>if you do so, then root shepherd will launch your user shepherd at boot <thomassgn>hmm, it's a .tar.bz2 But I saw the line above it says it got a 404 from bayfront. I thought it should fall back to building from source then, especially since I gave it the --fallback option... <leoprikler>Okay, what was the magic to deal with "ext4_dx_add_entry:2344: Directory (ino: 4980740) index full, reach max htree level"? ***jx97 is now known as jx96
<jackhill>I seem to often build a lot of …module-import-compiled.drv derivations. While I'm sure the exact set of modules varies for each one, ther must be a lot of overlap. I wonder if it would be more efficient to build all the modules one time, and then just copy them into module-import-compiled <NieDzejkob_>jackhill: That conflicts with minimizing rebuilds of other derivations that depend on these modules <lambdanon>I've noticed that my Guix SD box is compiling ungoogled-chromium from source. Isn't Guix SD supposed to download substitutions by default? <leoprikler>chromium rarely has substitutes due to being a huge ass browser needing two days to compile <lambdanon>btw is there a channel for getting tor browser to work? Last time I tried it on my guix SD box, I had a problem where it said "32-bit or 64-bit?" <lambdanon>leoprikler: Last time I tried installing guix SD, icecat took only a few seconds to install. At that time, I used config.scm to install it. Second time round, I'm installing it as a regular user, and it's going to take hours <leoprikler>That's the difference between building an icecat, that's literally months old vs. a fresh one. <lambdanon>That's odd... It only took a few seconds again. <lfam>The first time you ran the command, Guix did not find that a substitute was available <lfam>The second time, it came to a different conclusion <lfam>It's annoying but it happens <lfam>It's somewhat complicated on the other end, the server that you get substitutes from <lfam>It would be great if it was more deterministic but, for now, that's just how it is <lfam>It's not related to using config.scm vs `guix install`, or anything else like that <lambdanon>So it's like a cache miss but on the scale of a network? Would this be solved with more redundancy? <lfam>I don't know exactly what happened in this case <lfam>But, if you try to install something and you aren't happy with what Guix plans to do (build vs download), I recommend waiting a few minutes and then trying again <lfam>In the meantime, the server's cache may have been populated <lfam>And also, your local Guix will cache 'cache misses' for a few minutes <lfam>There's definitely room for improvement but it's not obvious what to change <jackhill>Anyone have ideas about how I can track down my spookly problem where building a derevation fails on one of my machines, but works everwhere else? https://issues.guix.gnu.org/47115 (lfam this is the same grub/cairo problem from earlier)? <lfam>jackhill: I was reading the thread again just now <lfam>Can you clarify, when it works on other machines, is it the same derivation? That is, is it building the exact same file-name? <lfam>In general, I don't think the discussion has included a clear method for trying to reproduce the bug <lfam>And I also recommend describing the difference between the machines where it succeeds and fails. Like, maybe one of them has 64 cores, and one of them has 2 cores <jackhill>lfam: yes, same file. I guess I'm not really sure how to reproduce it. It only seems to happen with reconfigure, not guix system build, and even then not on every host. <lfam>It doesn't make sense to me that it only happens with reconfigure and not build. I guess you mean that `guix system build` doesn't try to build the derivation that fails? <jackhill>right, guix system build. guix build ….drv does fail <lfam>In terms of a reproducer, we need `guix describe`, config.scm, and a complete command line invocation that triggers the bug <lfam>Off the top of my head, I don't know how to create this grub-image.png derivation easily. It's sort of deep-down in the dependency graph <lfam>Ideally, the reproducer would just require building that, and not an entire system <lfam>Otherwise, you might have trouble getting help <jackhill>lfam: indeed, I'm not sure how to create it either. It also doesn't seem to be build by ci.guix.gnu.org. <lfam>I don't know if it's something that is normally substituted or not <Rovanion>Guix the package manager has a fantastic terminal UI, except for this one thing: If I want a shell with python in it I don't write `guix environment python`, that gives me a shell with the dependencies to build Python. I have to user the flag --ad-hoc in order to get what I'm after. This behaviour seems backwards to me. Getting a shell with the listed packages should be the default and getting a <Rovanion>shell with the build-environment for the listed packages should be kept behind a flag, perhaps named --build-env. <pkill9>i think that was being planned to be swapped <lfam>This has been discussed recently on the mailing lists Rovanion. I don't remember the conclusion of the discussion, but you might search for it to check the status <lfam>The command was designed to provide development environments, which it does <lfam>Personally, I hope we don't start reversing things in the UI. That would probably be even more confusing <jackhill>ok, I've added some more information to the bug. I guess my primary question at this point is not how to solve it (although that is of course the ultimate goal), but where else should I be looking to spot differences. <lfam>jackhill: Have you told us what kind of hardware you're using? <jackhill>lfam: I'm not sure, I'm certinally willing to. Can you be more specific about what you mean by what type of hardware. lscpi? <lfam>CPU type, core count, etc <lfam>I'm not sure we even know if it's x86_64, aarch64, wetc <civodul>hmm i have 31317 unread messages in my guix-ci@gnu.org folder <jackhill>I included the contents of /proc/cpuinfo <lfam>civodul: Bob Proulx talked to mothacehe about this <lfam>I'm not sure what they concluded civodul <lfam>Yes, maybe only read the most recent 10000 messages <cbaines>lfam, I think the take away from that conversation was that spam checking won't happen for those messages, since that's taking a lot of resources <lfam>So, the volume may not decrease <lfam>Personally I don't use the guix-commits and guix-ci MLs <lfam>I am subscribed to guix-commits but I don't read it <lfam>I guess I read the git log instead <bdju>has anyone experimented with using assets from openarena with ioquake3? mainly because openarena isn't packaged yet <lfam>Hey roptat, I have a followup question about that sysctl service I'm working on, if you are interested in looking at it: <lfam>Basically, since this service will create some defaults for Guix System, I want users to be able to change those defaults. But, I can't figure out how to either remove the defaults service, or modify it <lfam>I understand if you don't have time or energy to look into it <roptat>if it's one of the default services, you can use modify-services to chaneg the defaults <lfam>I've been trying that, but struggling with the syntax <roptat>oh right, it doesn't have a proper service type if that's a simple-service <lfam>That's what I struggled with <lfam>I (display)-ed the services block and say that it has a type of 'base-sysctl-settings', which is the name of the simple-service. But this is not exported from (gnu services sysctl), so I can't refer to it, nor does it seem to be something that can be exported <lfam>I meant to write, "... and saw that it has a type of ..." <roptat>well, it does, but it's not easy to use with modify-services <lfam>Also, I meant to say that it's not exported from (gnu services base) <lfam>I wonder if I should approach this task of setting defaults in another way <roptat>right, because it's created inside the simple-services procedure <lfam>Yeah, I was reading it pretty closely <roptat>it creates a new type (service-type (name name) (extensions ...)) <roptat>that's the value you should use in modify-services iiuc, but you can't guess it from the outside <roptat>so, it would be easier to create a proper service type and export it, then you can use it with modify-services <lfam>I was starting to understand why special-files-service-type and extra-special-files are the way they are, even though that interface seems backwards to me <lfam>I also thought, maybe it's not our problem if people want to change these defaults, as they seem to be universally applied across all distros. But that's not very friendly <roptat>also, I wonder why you can't use sysctl-service-type directly? <lfam>I found that it prevents the use of other instances of sysctl-service-type in config.scm <roptat>well yes, but you could use a simple-service in your config, or modify-services :) <lfam>I may have been doing it wrong <lfam>Those are workable options but, to be honest, they are really too hard to use for most people <lfam>sysctl-service-type is easy to understand even if you don't know Scheme <lfam>I think the difficulty of Guix services keeps a lot of people (including me) on other distros <roptat>but if you want to compose, you can create something like (define-public base-sysctl-service-type (service (name 'base-sysctl-settings) (extensions (list (service-extension sysctl-service-type identity)))) and add (service base-sysctl-service-type default-settings) to %base-services <roptat>basically, you explicitly create the service as simple-service would do it, but you export it <roptat>then you can use base-sysctl-service-type in modify-services <lfam>I appreciate your advice roptat <Rovanion>lfam: Tried to find the thread but I'm growing sleepy so I should probably just go to bed and try again tomorrow. Night! <lfam>Sorry Rovanion. I'll find it and use the sneek bot to send it to you here <lfam>sneek: later tell Rovanion: It's in the discussion at <https://bugs.gnu.org/38529>, along with some other suggestions for changing the `guix environment` UI <lfam>jackhill: I checked out commit bb5d84a0489a629d30b, which is the one you identified as bad. I did `guix system build ...`, but it doesn't result in me having that grub-image.png.drv in my store <cbaines>I've finally managed to do some work on the Guix Data Service again this evening, and there are a couple of new experimental pages <lfam>jackhill: Have you shared the drv file itself? <cbaines>For the first page, I'm hoping that will help with spotting changes/breakages in system tests, although that requires the Guix Data Service to have the build information. It's also better of course to not have any breaking changes. <lfam>The system tests are really expensive though. I almost never ran them until I got access to a powerful server <cbaines>For the second page, that might be useful for spotting when patches have been sent to update a particular package, or if a new version if available on core-updates/staging. I'm unsure about how to visualise that though, and haven't tried with many packages <jackhill>lfam: yeah, my expericne is that guix system reconfiugre is needed. <jackhill>lfam: I've also poked around a little more, trying to run the builder from that derivation by hand at the repl. On the "bad" host autocompilation of (gnu build svg) fails, which seems suspicious: https://issues.guix.gnu.org/47115#11 <lfam>Yeah, I thought that was suspicious too <jackhill>So I've narrowed down the reproducer a little bit, but still only on the one machine which is odd <lfam>I'm testing on a Thinkpad x200 (very old Core 2 Duo), so it's not that similar <lfam>But it will at least provide some anecdata <lfam>I wonder if it's that Guile bug that Mark mentioned <lfam>Since Mark chimed in, I'd be surprised if it was a grafting issue. Mark is the expert on proper grafting <jackhill>Yeah, I must admit I don't really understand the implications of that bug <lfam>And the patches do look graftable <lfam>I did `guix build /gnu/store/0yf1b1l19h7c3...-grub-image.png.drv --rounds=10` and it works for me <lfam>I'll try it on another more powerful computer too <lfam>That's a powerful AMD EPYC machine <jackhill>Interesting, but I guess that's not too suprising given the other things we know so far.