IRC channel logs


back to list of logs

<mirai>looks like my shell-fu idea to autotranslate these .sty files into package names might not work as well as I thought <> 😅
<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.
<ngz>err "texlive.tlpdb"
<mirai>there's something odd here, texlive-microtype has been added yet… <>
<mirai>cool, TIL
<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>it's failing due to this
<mirai> <>
<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
<vagrantc> ... do these "missing derivation" infrastructure failures get rescheduled? can someone do it manually?
<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
<mirai>(added it to native-inputs)
<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>on master
<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
<apteryx>I found it last discussed in 2014
<mwette>I have a doc that requires npm from the node package. "node run build" crashes with "no such file:". Any ideas how to resolve?
<vagrantc>eeyk. more missing derivations from
<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)
<mirai>no pull, nothing
<sneek>janneke: wb!!
<mirai>and it stopped working
<mirai>so… ???
<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
<janneke>sneek: botsnack
<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 ?
<ngraves>dan: There's a series of blog articles "Dissecting Guix" in the blog for your second question
<dan>@ngraves thanks
<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
<jpoiret>dan: yes
<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)?
<lechner>Locally, the profile of the 'shell' command does not include the Guile module (bespoke make) that was patched to contain an absolute path to b3sum, even though the build appears to be correct
<lechner>apteryx / are you hitting ?
<lechner>apteryx / which would be the same as this
<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 / do you use Guix Home?
<lechner>apteryx / i would be happy to try them except my Guix is patched. it would allow us to correlate whether the issues are related
<dcunit3d>no, i'm trying to get there :)
<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)
<lechner>dcunit3d / what keeps you on Arch?
<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
<dcunit3d>thanks guys
<apteryx>system tests have been broken since
<apteryx>no evaluations on Cuirass
<apteryx>I'll apply the reworked presto
<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>this is the file
<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))
<andreas-e>With a guix pulled yesterday.
<lechner>andreas-e / thanks so much! i get (let* ((port (open-pipe* OPEN_READ "b3sum" "--no-names" path)) and have such discrepancies often
<PotentialUser-98>help me
<PotentialUser-98>system not install, subtitute: updating from 0%
<PotentialUser-98> not answer for me
<PotentialUser-98>PING ( 56(84) bytes of data.
<andreas-e>PotentialUser-98: Did you enable as a substitute server?
<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?
<PotentialUser-98>ok, i try to replace server
<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 am not sure that's what happened here. i filed some time ago, but it was a won't fix. how may i figure out if my store is "broken" please?
<lechner>i always run 'guix home reconfigure' after gc to make sure there is profile for me
<lechner>a prifule
<lechner>a profile
<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
<lechner>andreas-e ^
<lechner>sorry, you would also have to clone
<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!
<andreas-e>My pleasure!
<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.
<lechner>rekado / you have big disks
<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>gabber`, the html email body is also confusing. (those "Attachment: file" parts)
<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.14, base64-bytestring >= && <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
<attila_lendvai>anyone with the commit bit? the mumi link in the manual needs to be updated to (now it points to this broken link:
<attila_lendvai>or the gitweb link, whichever is preferred:
<rekado> ( works)
<rekado>but it’s been transferred to savannah/guix, so the URL should be updated
<rekado>attila_lendvai: I’ll replace it
<attila_lendvai>thank you rekado!
<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 ?
<lechner>did you 'guix pull'?
<lechner>please do
<lechner>it may take a little while
<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
<lechner>so no 'sudo guix pull' please
<dan>yes, because user stays the same
<dan>ok ill do that
<dan>Im trying to understand the system
<lechner>me too
<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>that'll keep you busy for a while
<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,
<attila_lendvai>graywolf, i doubt
<lechner>dan / i also aspire to that goal
<dan>thanks for your answers lechner
<lechner>didn't do much, but you're welcome
<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?
<lechner>this is for shutdowns?
<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
<graywolf>shutdowns and clean service restarts.
<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
<graywolf>so I*
<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>at least today
<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
<lechner>i think fork is more common
<graywolf>Right, so I will just add sleep at the end of the shell script and use fork+exec or what it was.
<graywolf>Will give it a try, thx.
<dan>i dont know exactly whats best in guix
<dan>too new to it
<dan>Im using link agregations on wireless , wired and wwan to make it work on a linux with systemd
<dan>with failovers
<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
<dan>tty12 is syslog ?
<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
<apteryx>gnucode: fun :-)
<gnucode>super fun!
<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 …)))
<apteryx>mirai: looks inconsistent
<lechner>Guest38 / I do
<mirai>apteryx: which part exactly bothers you?
<lechner>Guest38 / like this
<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
<Guest38>lechner: But this is alls NGINX
<unmatched-paren>evening, guix :)
<apteryx>mirai: the mixture of objects and symbols?
<apteryx>(more importantly, what use case would it support?)
<lechner>Guest38 / Apache should be similar
<mirai>apteryx: actually making some file-systems depend on some shepherd service?
<mirai>e.g. 'networking, 'my-link-local-interface
<mirai>a chance to get NFS working
<mirai>I guess an additional field could be added (like (shepherd-requirement …)) but I think it also fits within the dependencies field
<unmatched-paren>would anyone here right now be able to help answer this question?
<apteryx>mirai: I see!
<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)
<unmatched-paren>ah, the manual's Package Reference seems to answer my question :)
<apteryx>yay, qemu 8.1.0 built
<mirai>while the build failure topic is still hot, could this get reviewed? <>
<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?
<vagrantc>probably not hard to do ... :)
<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>ah! I just changed tree
<apteryx>branch, rather... not sure if it can explain it
<apteryx>tests would be nice...
<apteryx>seems easy enough to fix
<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
<nckx>mirai: Mind a PM?
<mirai>nckx: not at all, what's up?
<nckx>Srs bsns. (Not.)
<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 ?
<attila_lendvai>ngz, yep, thanks!