IRC channel logs
2023-08-30.log
back to list of logs
<ngz>mirai: :) The manual has good advice to find out what package contains a given file: `guix shell texlive-bin -- tlmgr info thefile.sty' <ngz>To automate the task, it is even preferable to download "texlive.tlpdp" and extract information from it with a script. <mirai>would have saved so much grief when I was tinkering with the dblatex package <ngz>I don't understand the microtype warning either. <ngz>It may be an error in the package you're building. <mirai>ngz: I've replicated manually the commands ./configure is performing <mirai>to check for the presence of the sty's <mirai>when I try this with texlive-listings (and adjust the test file accordingly) it returns code 0 <mirai>but it looks like the missing microtype.sty message is a red herring <ngz>mirai: So you need texlive-etoolbox, too. <mirai>so it should be added manually? (it seems to make more sense to have it propagated but I'm no texpert here) <ngz>Yes, you need to add it to native-inputs <ngz>Ideally, microtype should propagate it, but TeX Live didn't specify it. <ngz>It isn't a big issue, tho. Users would simply install texlive-collection-latexrecommended and forget about it. <mirai>I've added it and ./configure now happily detects microtype <ngz>So you're now missing two packages from "tex-team" <apteryx>mirai: it's a nice opportunity to debug :-D <apteryx>why does 'git describe' thinks 1.3.0 is closer to HEAD than 1.4.0 ? <apteryx>vagrantc: are you in a position to petition for Guile support in Debian's packaging of GNU Make? <vagrantc>apteryx: not any more than anyone else ... <vagrantc>apteryx: not sure how active the maintainer is, either <mwette>I have a doc that requires npm from the node package. "node run build" crashes with "no such file: libuuid.so.1". Any ideas how to resolve? <vagrantc>eeyk. more missing derivations from ci.guix.gnu.org <RavenJoad>Why does cuirass's evaluation of a specification's channels take so long? I have a spec for building an empty common lisp project, and evaluation has not finished in >10 minutes. <RavenJoad>Also, does guix count deleted store items correctly? My last guix gc collected 240ish GiB on a 256GiB disk, where only 95GiB is used now. Is it double-counting hard links? <mirai>apteryx: all I did was rebooting (without an upgrade) <ulfvonbelow>Well that was a proper confusing debugging session. Apparently guix will assume that any string starting with "/gnu/store" in any expression is a reference to... something... in the store. That's confusing enough behavior, but it does it inconsistently: only when you splice a non-gexp expression containing said string into a gexp. <ulfvonbelow>so if you're like me and happened to have an old local package around that uses plain old quoted forms and that contains `(format #t "/gnu/store top: ~%~a~%" (scandir "/gnu/store"))' in a phase, and now you're trying to apply a transformation to that that modifies the phases by wrapping them in a gexp, you'll get weird stuff like: guix build: error: path `/gnu/store top: ~%~a~%' is not in the store <ulfvonbelow>are there any cases where we actually substitute an expanded gexp into another gexp? <ngraves>Hi Guix ! Does someone know if there's a way to reload a guile load-path from within a guile script ? <ngraves>Let's say the first half of a script changes the symlink to the load-path, how can I ensure the second half will use the right reloaded code ? <rekado>ngraves: is there shared state between the two halves of the script? <ngraves>rekado: I don't really use any state in this script. The symlinks I talk about point to the store though, but since we want to reload them, it isn't state. <andreas-e>ngraves: Since you are around, what is your stance on moving to a more recent scilab? Would you still need the 5 version, or would switching to 6 be okay? <sneek>Welcome back andreas-e, you have 1 message! <sneek>andreas-e, rekado says: hdf5@1.8 is used by the old java-cisd-jhdf5, which is an input to fastqc. I donāt know if itās possible to upgrade it, because thereās no newer version of java-cisd-jhdf5. <jpoiret>ngraves: not sure how that would work esp. if you have things that depend on definitions in the module you're trying to replace <ngraves>andreas-e: I can always freeze a manifest, so I don't really care. The program I use with scilab is not really easy to move to scilab 6 though. And there might be substantial compilation / package definition changes with scilab 6. Go ahead if you wantĀ ;) <andreas-e>rekado: This is unfortunate, but thanks for the analysis! There is a newer version of fastqc, but I suppose it will also need the older Java library. I did not find anything to convince me of the contrary in the changelog. <ngraves>jpoiret: What about delayed evaluation? Is there any chance it might work? <andreas-e>ngraves: Okay, this does not provide a lot of motivation! I am indeed afraid it would be a major hassle to upgrade the package definition. Some of my motivation is that it is one of the few dependents of hdf5@1.8. <ngraves>andreas-e: IIRC, the major change for compilation is that they moved away from fortran and included more CPP. I remember having tried quickly but unsucessfully, don't remember where I got stuck. But that was a long time ago. <dan>So, guys hi. guix hangs for me a lot at system at "guix system reconfigure" towards the last phases after updatng grub, and at "shutdown" where shepher prolly hangs and no shutdown ever happens <dan>are there any videos showing how to debug issues in guix and how to set up some introspection into the system ? <dan>and maybe videos showing the data flow in a system from package spec to derivation to build artefacts ? <jpoiret>dan: debugging shepherd is quite a bit harder imo, although if you still have access to shepherd you can now start a repl with `sudo herd repl` iirc <jpoiret>ah, doesn't seem to exist on my computer, I might be misremembering stuff <kjartan>I think the REPL service isn't registered by default. <kjartan>According to the manual your shepherd config needs to include: <kjartan>(use-modules (shepherd service repl)) <kjartan>(register-services (list (repl-service))) <apteryx>hm, 'make check-system' gives me: guix build: error: service 'term-tty6' provided more than once <dan>@jpoiret and @kjartan thank you both <apteryx>dan: for your info, you don't need the '@' on IRC; clients highlight replies by matching the nickname in the text :-) <dan>most awesome. thanks <dan>since shepherd is using a cooperative fiber model t, in theory a service which doesnt cooperate can block it forever, no ? both at startup and at shutdown <lechner>Hi, should a profile provided by guix shell -f guix.scm always refer to the store folder obtained from guix build -f guix.scm (instead of another)? <dcunit3d>how do i uninstall a package in the ~/.guix-profile ? <dcunit3d>on arch, it's also installed guix/guile to this profile, so my load path is not quite correct inside emacs. i don't actually load this profile on arch, but i think something it /etc/profile.d from the guix-installer package on arch is doing it. <apteryx>lechner: looks like it could be related, yes! <apteryx>are the system tests broken the same way for others? <lechner>dcunit3d / 'guix remove' does not work? <dcunit3d>working across both arch and guix system has been very confusing, esp since the geiser/guile repl requires different set up for each system. i took doom emacs out of the mix (which uses straight to download guix.el, which causes issues with where your guile deps come from) <dcunit3d>woops. let me try that. i've been focusing on a lot of other things recently, but i'm trying to resolve this geiser/guile load path stuff once and for all, so i can build packages/systems/profiles in the repl. <dcunit3d>i just worry about lib64 problems. i looked into those as well, trying to get an appimage to run. it's close. the easiest ways around the lib64 issues are docker/vm's <apteryx>dcunit3d: Geiser load-path should be preconfigured out of the box if you accept the .dir-locals.el content <dcunit3d>i just occasionally need to run software like that. that's the only major issue. also, i have a great AMD gpu and i worry about not being able to run machine learning. <dcunit3d>apteryx: i've been looking into that, but i source other channels as well (sorry if this is bordering on discussion of non-free software) <apteryx>it's fine to source many channels; we need not know what's in them <dcunit3d>my ~/.config/guix/current/etc/profile doesn't modify GUILE_LOAD_PATH/etc, which contains the *.go files for my channel list <dcunit3d>i have a git-repo XML that allows me to grab all the channels at once, so I could modify the .dir-locals.el to add them to the load path. AFAIK, after building my guix checkout, then running code in geiser would simply build them when needed. <dcunit3d>i was considering that as an alternative workflow, esp since I would like to contribute where I can. I enjoy learning about new build systems. <dcunit3d>that set of paths for the git-repo would maybe be the easiest way to have consistent paths across all my systems. one potential issue is that the guix checkout build isn't necessarily updated when I update my system. <apteryx>nckx: hello! had you had any luck in fixing the system test failures? did you dump the state of things of your investigation somewhere I could read? <dcunit3d>i also may have customized the arch /etc/profile.d because it doesn't have the content in guix-install.sh <lechner>Hi, would someone please run guix shell -f guix.scm on this file and tell me if your $GUIX_ENVIRONMENT/share/guile/site/3.0/bespoke/make.scm refers to b3sum by an absolute path? This command will tell grep b3sum $GUIX_ENVIRONMENT/share/guile/site/3.0/bespoke/make.scm <lechner>apteryx / i still get that error: guix build: error: service 'term-tty6' provided more than once <andreas-e>lechner: Looks okay here. I get this from "grep": <andreas-e>(let* ((port (open-pipe* OPEN_READ "/gnu/store/96ryy0swbacnjy9p7z6gq8gkxab2y9cd-b3sum-0.3.8/bin/b3sum" "--no-names" path)) <lechner>andreas-e / thanks so much! i get (let* ((port (open-pipe* OPEN_READ "b3sum" "--no-names" path)) and have such discrepancies often <lechner>andreas-e / wow, did you run guix shell just like I asked? now I get guix shell: warning: no packages specified; creating an empty environment <andreas-e>It works for me, but may depend on where you are in the world. We often get reports from China that the download speed is abysmal. <lechner>as well as the unhelpful guix shell: error: readlink: No such file or directory <andreas-e>lechner: Yes, I just copy-pasted your command. Is your store broken somehow? <lechner>andreas-e / i ran guix gc -D on the older unpatched version that I did not wish guix shell to find <lechner>by my home is encrypted via FUSE and unreadable by root. i think gc may not be able to read all of my roots <lechner>andreas-e / how may i diagnose, please? <lechner>maybe that's why my guix shell has issues <andreas-e>lechner: Are the roots not in /var/guix/gcroots? There should not be links towards your $HOME, only from your $HOME. <lechner>they are but gc looks at $HOME to see if they are still being used, doesn't it? <andreas-e>Actually, this is wrong. I do have /var/guix/gcroots/auto with a symlink to $HOME/.cache/guix/profiles/... <andreas-e>lechner: Maybe, I do not know. You mean the "removing stale roots" phase? <lechner>i always run 'guix home reconfigure' after gc to make sure there is profile for me <andreas-e>lechner: I thought of "guix gc --verify=repair", but maybe this has nothing to do with your problem. I just wondered because of the missing file. <lechner>how can removing a stale build artifact break my store? <andreas-e>I do not use guix home and am afraid I will not be of much further help. <lechner>actually, i just want to tell ludo about bespoke. could you please run that guix shell command one more time, and then cd examples/hello as well as ./make -d 3 ? Please note the ./ before make <andreas-e>lechner: Actually it could be that your setup breaks "guix shell". I think these links (there are many actually) from/var/guix/gcroots/auto to $HOME/.cache/guix/profiles/... may be cached "guix shell"s. This is what makes the command fast the second time. <lechner>andreas-e / thanks, i was just looking at that. you explained a lot! <lechner>not sure why this crowd would think it would be reasonable to grant root read permissions to $HOME :) <andreas-e>lechner: So I think your "guix gc" removed items in /gnu/store to which your profiles in $HOME/.cache/guix/profiles/ point, making them invalid. <lechner>i wish guix shell would tell me which link <andreas-e>On the positive side, you should be able to remove this directory after "guix gc" and then "guix shell" should work (because it recreates the store items). <lechner>all of $HOME/.cache/guix/profiles/ ? <andreas-e>Yes, the only overhead would be that your next "guix shell"s might be slower (but actually work...) <lechner>thanks i did that. maybe the use of that cache could be optional (i.e. configurable). <lechner>by the way, my Make reimagined in Guile is working now. thanks so much for your assistance! <lechner>i'll have a look at the guix shell code at some point <andreas-e>Your commands seem to work. The end result of "./make -d 3" is "Done with all top-level targets: ("hello")" <lechner>andreas-e / thanks so much for confirming! <rekado>āguix gcā deleting things that are referenced from (unaccessible) $HOME is a problem in cluster installations. <rekado>itās why I donāt run āguix gcā at work. <gabber`>ACTION feels a little like bernie in the meme <gabber`>hi there! does anybodey have any ideas on how to speed up the merging of my patch-set #61869? <attila_lendvai>gabber`, using git send-email would help. also, you're not following the contibutor's guidelines. read up on resending new versions of multi-commit patches in the manual! <attila_lendvai>gabber`, the result is that it's hard to construct the latest state of your commits from reading the issue <attila_lendvai>ACTION just realizes that the 0003-foo-bar filename does not mean that it's 3 commits. it's only one commit. <gabber`>yeah, sorry for my email formatting. i'm bound to (one of) the worst email providers here at work (which is where i'll be needing the patchset from). <apteryx>provider shouldn't matter, as long as you have the SMTP information to use git send-email <apteryx>does the ganeti system test fails for others too? <apteryx>cabal: Encountered missing or private dependencies:\nattoparsec >=0.10.1.1 && <0.14, base64-bytestring >=1.0.0.1 && <1.2, lens >=3.10 && <5.0 <apteryx>ah, ganeti's build itself is broken :-/ <gabber`>apteryx: it's less about the SMTP than the (apparent) need for OAuth2 and the reports i've read that it does not work as smoothly as i'd like it to.... <gabber`>it's ok from the perspective that i see certain dinosaurs of our realms questioning their hatred towards the enemy - and me getting new fuel by simply being forced to use their "technologies" <lechner>andreas-e / Hi, I think I encountered a bug in that 'guix shell' attempted to follow a link that did not correspond to the newer guix.scm that patched for b3sum. Do you agree? <andreas-e>No idea, I just blindly executed your requests. <lechner>andreas-e / would you mind removing the whole #:phases stanza and run that grep one more time? <andreas-e>(let* ((port (open-pipe* OPEN_READ "/gnu/store/96ryy0swbacnjy9p7z6gq8gkxab2y9cd-b3sum-0.3.8/bin/b3sum" "--no-names" path)) <lechner>that does not correspond to the package definition <andreas-e>Yes, it gives the same output with or without the phases. <lechner>it's the other way around if you build it without the phases first <rekado>but itās been transferred to savannah/guix, so the URL should be updated <rekado>attila_lendvai: Iāll replace it <dan>so, after a fresh install sudo guix system reconfigure resuted into a "guix system: aborting reconf.. because comit hash of channel guix is not a descendant of hash " <dan>hint: Use --alow-downgradea <dan>Why does this happen ? <lechner>dan / sanity check that you don't need <dan>can you details please ? <dan>ok , but what confuses me here is that usually operations done on behalf of my user do not affect system only my profile <dan>doesnt a system reconfigure updates guix itself too ? <lechner>in fact, 'sudo guix' runs your personal version of Guix <dan>yes, because user stays the same <dan>Im trying to understand the system <dan>now, right after a fresh install Id like to inspect the glbal store and see why a certain package ended on mmy drive <lechner>please remember that the store is no indication of what's available to you or any other user <dan>yes I got that already <dan>in fact i had a functional system and besides some guix hangs all worked super cool <dan>i reinstalled to understand all that plumbing that go down there <graywolf>Is #:stop ever called for #:one-shot? shepherd services? <dan>so I can build it exactly as i want, <dan>thanks for your answers lechner <graywolf>attila_lendvai: Hm, so if I want to have the ability to "clean up" after a one shot service, I need to *not* use one-shot, and instead have regular service who's command will basically be one-shot + sleep inf? <lechner>graywolf / that does not sound like a one-shot <attila_lendvai>graywolf, why don't you put the cleanup at the end of the start gexp? <graywolf>I confused. If I did that, the clean up would run when the one-shot service starts, no? <attila_lendvai>graywolf, your start GEXP needs to launch whatever needs to be started. then add code that waits for that process to quit/finish, and then run your cleanup code <lechner>attila_lendvai / i respectfully disagree with that recommendation <graywolf>Well, #:start sets up a networking interfaces, do I wanted to have #:stop to tear them down <attila_lendvai>graywolf, so, it's a one-shot service that runs indefinitely long, but when it dies by itself, then it shouldn't be restarted? <lechner>graywolf / can you clean up in the gexp *before* you start the service <dan>networking shouldnt be a one shot in the first place, but a loong run <dan>too many devices powering up and down all the time, roaming, tethering on and off, location changes <graywolf>dan: I see, so the service should basically just call "sleep inf" and therefore not be one-shot <graywolf>Right, so I will just add sleep at the end of the shell script and use fork+exec or what it was. <dan>i dont know exactly whats best in guix <dan>Im using link agregations on wireless , wired and wwan to make it work on a linux with systemd <dan>and I want to experimet with routing domains too to automate as much as possible from my networking needs on laptop <graywolf>This is a virtual machine, so once running nothing will change, so I thought the one-shot would be enough, but as noted above, I did run into issues how to do the cleanup with #:one-shot <apteryx>ACTION is updating qemu with their 2006 desktop <apteryx>interesting, "System emulation on 32-bit x86 hosts has been deprecated" <gnucode>morning guix people! (I am chatting on the Debian/GNU Hurd running X (i3) on real hardware: A T43). <andreas-e>That sounds exciting! Hopefully you will be able to change to Guix soon. <mirai>dan: you'll need to read the shepherd manual <mirai>there's some more advanced stuff that might do what you want <Guest38>Can I useĀ the certbot service for an Apache HTTP as well? <mirai>Would it be too controversial to have symbols as well within the file-system dependency field? i.e. (file-system (dependencies another-file-system some-mapped-device 'a-shepherd-symbol ā¦))) <mirai>apteryx: which part exactly bothers you? <mirai>I guess you could do some bizarre things like inserting 'file-system-/foo/mount instead of specifying the foo-mount object directly but that's more on the operator <apteryx>mirai: the mixture of objects and symbols? <apteryx>(more importantly, what use case would it support?) <mirai>apteryx: actually making some file-systems depend on some shepherd service? <mirai>e.g. 'networking, 'my-link-local-interface <mirai>I guess an additional field could be added (like (shepherd-requirement ā¦)) but I think it also fits within the dependencies field <apteryx>I'm pretty sure this has been discussed before <apteryx>it's probably worth re-reading past discussions on guix-devel <podiki>got a mac from work, guess it's time to figure out guix on there (for packages) <apteryx>mirai: perhaps it'd be time for you to get commit rights :-) <apteryx>did I break 'git send-email' with the teams.scm changes? <apteryx>it says: Throw to key `match-error' with args `("match" "no matching pattern" #<<regexp*> pat: "^gnu/packages/haskell(-.+|)\\.scm$" flag: 1 rx: #<regexp 7f7c045441c0>>)'. <apteryx>branch, rather... not sure if it can explain it <apteryx>mirai: LGTM with minor comments (incomplete changelog messages) <mirai>apteryx: I'd have to improve my emacs&git-fu then :-) <mirai>thanks, I'll amend it and send a v2 <mirai>nckx: not at all, what's up? <attila_lendvai>remind me please, what is that strangely called debug print function that prints its first argument and returns it? <ngz>attila_lendvai: pk ?