<rekado_>successfully built /gnu/store/m3n2y2dkqh5c9bbsx0v2vjncxp4mwgcq-ghc-6.0.drv <tribals>Do I need to restart shepherd itself or it's services when I did reconfigure? <jab>looks like I need to learn about currying <jab>ric342[m]: I do not believe so... <jab>ric342[m]: It does have grub entries for previous system generations, but that doesn't seem to be what you are asking <ric342[m]>Yeah, that's not what I was looking for exactly <ric342[m]>I guess like guix profiles except for the whole system <Andronikos>How can I passthrough my GPU in a guix shell --container? <old>Andronikos: GPU devices are usually under /dev/dri. So I guess `guix shell --container --share=/dev` <Andronikos>old: Does not work. I don't know why but /dev/dri does work at least it will create the container. Is that really it or do I need more like specific packages for HW accel? <old>Hmm. Package like ROCM, OpenCL and OpenGL will open devices under /dev/dri and do some ioctl magic on them <old>Are you using something that require the GPU specifically? What is your use case here? <apteryx>congrats, and hats of to your perserverence! ***bjc` is now known as bjc
***mirai_ is now known as mirai
<mirai>How can I use the 'define-configuration' to write (serialize) each field to individual files? <jab>mirai what's the difference between serialize and non-serialize? <Andronikos>old: I tested the new -F option in guix shell if it could work with this program (proprietary) which creates a chromium gpu-process that crashes and I was not certain if it is an issue with the GPU or something else. Probably is something else since the driver of the GPU works totally fine. <old>Oh neat I did not know about this new option <old>My advice, run your program with strace to see which syscall is failing <old>You might be lucky and see which file is being open and failed <Andronikos>Well I tried that out but no idea how I can run strace on a process that is created by the initial program. <dsmith>Andronikos: You can pass the pid to strace... <old>indeed stace can attach to any process. Anything that ptrace can do strace do <old>Well any process, that depend on the Yama policy on the system, but you the the gist <old>s/you the the/you get the <old>so something like: `strace -f -p PID` should work <flatwhatson>it's the "-f" option which is important for following child processes <flatwhatson>launching with strace directly is more useful if it's failing during startup <flatwhatson>i usually do something like "strace -o trace.log -s 256 -f my-command my-args ..." <flatwhatson>that prints more of the string argument so you can actually read the insanely long guix filenames 8) <flatwhatson>and redirects to a file on disk so you can do post-facto grep analysis, and not blow up your scrollback buffer <Andronikos>Thanks for the help guys. Now strace delivers more information to debug and I am pretty sure I can make it work. <Andronikos>But now it is time to sleep. Good night everyone. <pkill9>got a new battery so now I can use uix on the go <apteryx>I think I have some shell quoting issue; git send-email --to=guix-patches@gnu.org $(./etc/teams.scm cc-members origin/master HEAD) 0000-cover-letter.patch doesn't work for me <apteryx>I get: fatal: ambiguous argument 'some-address@gmail.com'': unknown revision or path not in the working tree. <zpiro>apteryx: you sure?, no idea what is in team.scm, but it certainly isn't an executeable? <zpiro>may be sourcing that thing in shell. <zpiro>apteryx: so aeh, are you using a git command that needs to run guix in a subhsell for team.scm? <zpiro>I.E. all the input to the git send-email is taken for team.scm that may need a shebang that is not shell or a command in front? <zpiro>I'm just guessing really, and don't know if it your emnail or someone elses that is "redacted". <zpiro>never used that command, quite frankly, but saying something is less than uselessly saying nothing and reading it when nobody else does. <apteryx>after checking with the fine folks in #bash, the issue is one of quoting <apteryx>when a command substitution is made, the quotes appearing in its output are not interpreted, thus they end up as literals in the values <apteryx>and they get split in odd ways, leading to the problem I have <apteryx>so, it's a bug in our documentation. the invocation proposed is not valid currently <zpiro>apteryx: mbakke is a walkking git encyclopedia and shell expert if you nag him. <zpiro>I would probably work around it if urgent or important, but sure mbakke fixes git and shell on direct requests in spite of other drives. <the_tubular> I'm stuck on a guix machine with no internet and I'd liek to get it's internal IP <Aurora_v_kosmose>I assumed those tools wouldn't be working considering earlier command mentions. <apteryx>even our bare-bones.tmpl guix system template has iproute in %base-packages <the_tubular>Can I see ICMP packets with netcat on listen mode or something ? <apteryx>it reads a bit as shooting oneselves in the foot, eh :-) <Aurora_v_kosmose>(inet-ntop AF_INET (sockaddr:addr (addrinfo:addr (car (getaddrinfo *some-hostname-string*))))) <apteryx>zpiro: I've created a Guix bug issue for it, we'll see! <apteryx>where the host name string would be localhost right? <Aurora_v_kosmose>apteryx: More like the assigned name for the machine, otherwise you'll get some 0.0.0.0/0 or loopback address. <Aurora_v_kosmose>Hmmm... well seems like it's not fail-proof. One of my VMs still answered with loopback. <apteryx>$12 = ("127.0.0.1" "127.0.0.1" "127.0.0.1") :-D <apteryx>'nmcli con', but if you don't have %base-packages, I doubt you have that one either <lizog>hello guix, would like to have an up-to-date version of vulkan sdk on guix, so that i could completely switch my daily development environment to guix! <lizog>it would be really helpful if contributors could review the patch series and push it, so i could work on packing other parts of the vulkan sdk. <brendyn>lizog, perhaps you can help by testing it yourself. you would have to install git, clone the repo, apply the patches and then pull from the local repo to test them <lilyp>it's not quite that easy since the series targets c-u <lilyp>so you have a lot of manual builds <jeko>Good morning Guiiiiiiiiiiiixters ! ***mark_ is now known as mjw
<brendyn>linj, you can do that, or you can also "guix pull" from your own local modified repo. both work <linj>brendyn: If I "guix pull" from my local fork, I need to setup "channel introduction", right? Is there a way to disable channel auth? I am new to guix. ***wielaard is now known as mjw
<brendyn>linj, sometimes --allow-downgrades is also useful ***Dynom_ is now known as Guest3535
<brendyn>hmm, gtk@4 has both pango and pango-next in its closure <antipode>This is the reason why I would prefer putting the commit itself in the 'commit' field instead of the (mutable) tag name pointing to the commit. <antipode>Also, that package could be named go-gopkg-in-yaml -- Guix supports having multiple versions of the same package. <qzdlns[m]>yeah totally, or at least to use the gopkg.in tag spec `@TAG` <antipode>'git-fetch' is a Guix thing, not a Gopkg.in thing <antipode>What is your proposal for how things would look like in Guix after whatever change you are proposing? <antipode>-- on that web page, I do not see any mentions of commits. <qzdlns[m]>it's just a git tag, so it's in transparent and mutable, but a better resolution than just the gopkg uri -- the commit, being content addressable, is the best option for sure <antipode>What'ts this git tag you are referring to? <antipode>I only see vN.M.O git tags in the Git repo. <antipode>Er, that package definition downloads from the go.pkg.in mirror instead of the standard upstream location. <qzdlns[m]>I was talking for any such tag -- this referencing line is a non-sequitur from the initial issue, which can just be fixed with a patch <antipode>I was proposing to move away from those vN.M.O tags, so I don't follow the 'yeah totally, or at least to use the gopg.in tag spec `@TAG`' <qzdlns[m]>but this is still inferior to using some CID like a commit <antipode>qzdlns[m]: AFAICT the @TAG from gopkg.in is not any more or less precise than the TAG from the underlying git repository. <antipode>Unless gopkg.in does some 'oldest use of v3.0.0 wins'. <qzdlns[m]>yeah I think they just order DESC on vN.M.O (or the full version string); I'm glad I don't know in this case haha <antipode>However you order your version strings, their tags remain mutable. <antipode>I meant, maybe if v3.0.0 initially points to deadbeef and gopkg.in then imports the repo, and later v3.0.0 points to cabba9e, then gopkg.in keeps pointing to deadbeef and doesn't switch to cabba9e. <qzdlns[m]>>I meant, maybe if v3.0.0 initially points to deadbeef.... <antipode>AFAICT, they did the opposite going by their reply. <antipode>"There was only aever one single tag on v3.0.0" <qzdlns[m]>to add to the complexity this "single tag" was created after we (guix) packaged the thing <qzdlns[m]>and I suppose if we're only ever reading this package from the store on CI then it would fly until someone is cleanbuilding docker (me) <antipode>I assume that, given that Guix has packaged this v3.0.0 before this tagging business, this "single tag" existed before we packaged it. <antipode>Though possibly this "single tag" was mutated later. <antipode>I mean, there's "guix time-machine", but Guix still can't travel into the future. <qzdlns[m]>sure, my reading is that there is a branch `v3`, and `v3.0.[0 | 1]`; we ref `v3` in the package, which is now the master branch, so has the latest version <qzdlns[m]>I will make a patch to just 3.0.1 by it's SHA -- thanks antipode <jamesw>I have an assembly program( abscall.s/abscall.o)which calls C libary, but when I input "ld -o abscall -lc abscall.o " in the command line. <jamesw>get "ld: cannot find -lc" and failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib64/libc.so failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib64/libc.a failed <jamesw>attempt to open /no-ld-lib-path/libc.so failed <jamesw>attempt to open /no-ld-lib-path/libc.a failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib/libc.so failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib/libc.a failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib64/libc.so failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib64/c.a failed <jamesw>attempt to open /no-ld-lib-path/libc.so failed <jamesw>attempt to open /no-ld-lib-path/c.a failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib/libc.so failed <jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib/c.a failed <jamesw>seem ld try to find libary, but failed. <jamesw>could you help me on this issue? <jamesw>would anybody here plesae help me? <tricon>we need to figure out how ld and such are looking for libc. <jamesw>lrwxrwxrwx 1 root root 71 Jan 1 1970 /home/james/.guix-profile/bin/ld -> /gnu/store/0dbscs8zq4bdg8vbn9jkdgynjcn3s01p-gcc-toolchain-12.2.0/bin/ld <antipode>"gcc -o abscall abscall.o" (assuming that's how you pass .o to gcc) <jamesw>ld: abscall.o: in function `_start': <jamesw>ld: /home/james/.guix-profile/lib/crt1.o: in function `_start': <jamesw>(.text+0x20): undefined reference to `main' <jamesw>collect2: error: ld returned 1 exit status <antipode>(with proper visibility -- I don't know how that works in assembly) <jamesw> ## Result is in %rax, move to %rdi for the exit syscall <antipode>My guess is that there is some auto-generated default _start function (which tries to call main, but also does some libc setup). <antipode>Also, in your assembly source, you aren't using anything of the C library. <jamesw>after "gcc -o abscall abscall.o" , gcc out something like "...main..." <antipode>I don't really know assembly, but if you intend to use the C library, I expect you need to define 'main' instead of '_start'. <jamesw>actually, it is a demo program in an assembly programming book. I am just learning some assembly programming.. <antipode>Your demo intends to use the C library, then. <tricon>jamesw: else, if you're just trying to manually link, you need to set your ld paths so that they can find libc and any necessary libs; but antipode is on to something. <jamesw>yes. assembly prog to call/use c lib <jamesw>trincon: what is of ld paths, how to find it/them? <jamesw>I think the issue is that ld can't find the path of libc <jamesw>as GUIX coded Path...for functional package management... <rekado>did you install binutils and gcc and glibc? You should only have gcc-toolchain installed. <jamesw>james@T30 ~/Documents/pasm/Learn_to_Program_with_Assembly$ guix package --list-installed <jamesw>texinfo 6.7 out /gnu/store/22n2s0vfvqg9v0as9h7fpdn1i9dmryvi-texinfo-6.7 <jamesw>recutils 1.9 out /gnu/store/88519v163ygwqgi85vvdyvkpp2v79g5g-recutils-1.9 <jamesw>emacs 28.2 out /gnu/store/95a2ahl48q27rbljh37pjzdwzw7vqka9-emacs-28.2 <jamesw>gdb 12.1 out /gnu/store/zsqfy3hrngxkl76jir3cnq6920myzf4y-gdb-12.1 <jamesw>vpnc 0.5.3 out /gnu/store/a63nll1nc45a1bd2lgiybk0j7sdiwd4n-vpnc-0.5.3 <jamesw>ccls 0.20210330 out /gnu/store/ca3arjjksbjbk10mf5jxd5zkm65xszvv-ccls-0.20210330 <jamesw>git 2.38.0 out /gnu/store/w5clpycyw01in35kff2ack7my7bs8a8j-git-2.38.0 <jamesw>texlive 20210325 out /gnu/store/k99pr3cnsak50w7bdlnl6gjbxrbrbhv9-texlive-20210325 <jamesw>make 4.3 out /gnu/store/xijziz8r87baiz87vc9sm04lwadwf4ls-make-4.3 <jamesw>rekado: I only install gcc-toolschain <jamesw>binunitls, gcc are included into this package. <jamesw>I can use as to compile assembly source , and ld to link those compiled file successffuly <rekado>(please use a paste site instead of pasting many lines here) <rekado>I don’t see gcc-toolchain in the above output <rekado>(it’s just “Guix”, by the way. Not “GUIX”.) <jamesw>gcc-toolchain 12.2.0 out /gnu/store/0dbscs8zq4bdg8vbn9jkdgynjcn3s01p-gcc-toolchain-12.2.0 <rekado>we use an ld-wrapper; perhaps you are not using it. <jamesw>rekaddo: what's ld-wrapper.. how to use it ? <rekado>jamesw: when I do “guix shell gcc-toolchain -- /bin/sh -c 'readlink -f $(which ld)'” I get /gnu/store/s2pg5k98fl2g2szg9dykxyd9zl3xihv9-ld-wrapper-0/bin/ld. <jamesw>$gcc absmain.s -static -o absmain <jamesw>collect2: error: ld returned 1 exit status <jamesw>emacs 28.2 out /gnu/store/95a2ahl48q27rbljh37pjzdwzw7vqka9-emacs-28.2 <jamesw>gdb 12.1 out /gnu/store/zsqfy3hrngxkl76jir3cnq6920myzf4y-gdb-12.1 <jamesw>git 2.38.0 out /gnu/store/w5clpycyw01in35kff2ack7my7bs8a8j-git-2.38.0 <jamesw>make 4.3 out /gnu/store/xijziz8r87baiz87vc9sm04lwadwf4ls-make-4.3 <jamesw>would anybody here help me on this issue ? <jamesw>sorry I don't know how to use "pastebin", I am via brower chat.. <gnucode>zinc[m] you can do a quick online search for debian pastebin. It's super easy to use. :) <rekado>jamesw: did you see my earlier message about the ld wrapper? <jamesw>I am lost from the connection in the prevous session.. sorry... <jamesw>rekado: soplease kindly explain how to fix the 'cannot find -lc ' issue with the ld wrapper? <rekado>jamesw: check where your “ld” comes from. You’re using the wrong ld. <jamesw>"/home/james/.guix-profile/bin/ld" <jamesw>is there something wrong for this "ld" ? <rekado>can you reproduce this with the “guix shell” command I used? <rekado>i.e. “guix shell --pure gcc-toolchain” and then run your ld command. <jamesw>if you have guix, better to replicate it. to check if the same problem happens... <apteryx>is now a good time to reboot berlin? <apteryx>later tell civodul shepherd on node 129 is also using a lot of memory: 659.4m 436.7m 0.0 0.2 137:37.14 S shepherd <apteryx>regarding anonip usage of files... I'm not sure how that all works, but normally to rotate nginx logs we have to send nginx a signal so that it resets writing to a new log file <apteryx>otherwise even if the file is moved (rotated), it would continue writing to it <apteryx>does using anonip somehow make this requirement go away? <apteryx>rekado: the question w.r.t. anonip was directed to you above in case you know <rekado>jamesw: use “ld -L$LIBRARY_PATH -lc” <rekado>you need to tell ld where to look for libraries <rekado>apteryx: anonip provides a fifo; nginx writes to it, anonip reads from it and writes out the filtered log file. <rekado>the filtered log file that comes out at the end can be rotated as usual <apteryx>ah, so it does make it easier for us <rekado>it’s set when gcc-toolchain is installed <apteryx>what should our anonymized log retention be? 3 months sounds decent to me. <apteryx>the machine is back up, but the web pages are still down <rekado>check that the files that anonip uses are in fact FIFOs <apteryx>hm... can't ssh to the box anymore (it froze?) <rekado>sneek: later tell jamesw guix shell --pure gcc-toolchain glibc glibc:static -- /bin/sh -c 'ld -static -L$LIBRARY_PATH -lc' <apteryx>seems the nginx log files aren't FIFOs, right? <apteryx>should I delete them and recreate them with 'mkfifo'? <rekado>apteryx: Oct 27 17:51:04 localhost shepherd[1]: '/var/run/anonip/http.access.log' is not a FIFO; bailing out <apteryx>this was when I tried 'herd start nginx' manually post boot <rekado>just moving them out of the way and restarting the anonip services should be enough <rekado>this directory contained a bunch of empty files instead of fifos <apteryx>can we make it so that these files are recreated at on restart to guard against this? <rekado>that’s what the anonip service does <rekado>question is what created these zero-length files <apteryx>no idea, I simply rebooted. Perhaps a fifo becomes an empty file when rebooting? <apteryx>that doesn't sound very likely/logical though *apteryx knows next to nothing about named pipes <antipode>If you do "echo a > fifo", then it will block until some other process accepts it. <apteryx>why can't I access rottlog info manual in my Emacs? It's at /run/current-system/profile/share/info/rottlog.info.gz, and M-x getenv INFOPATH has /run/current-system/profile/share/info, among others. <apteryx>GaliantGazelle: hopefully yes! else it's a bug <kaelyn>janneke: Not sure if you've seen the bug yet, but over the weekend I filed https://issues.guix.gnu.org/58719 about 'file failing to build for i686-linux. The error is for an undefined symbol in glibc-mesboot-2.16.0, and I'd be <kaelyn>happy to help debug it further or work on a fix, given a few pointers on where to start. <GaliantGazelle>thank you, there was no documentation I saw claiming that iso is reproducible. Does anyone actually audit that it is? How can I verify that iso is reproducible for pinebook image? <apteryx>to be honest, I'd be surprised if it actually is reproducible, but that's what Guix aims for, so non-reproducibility should be considered a bug. <apteryx>any single one package which suffers from a non-reproducibility problem in the image could jeopardize the result <GaliantGazelle>I know that reproduciblity is done within guix for packages, but whether the initial image is or not, I do not know. <GaliantGazelle>Unless I can be convinced iso is reproducible I'm going to try to build iso from source. By the way, ARM cpu is the way, because intel and amd cpu have backdoors and built in spy chips. <lilyp>You can convince yourself that the iso is reproducible by building it from source ;) <GaliantGazelle>unless arm cpu has similar issues I lack awareness of. Pinebook Pro is also a stateless laptop possibly, since uboot is on the installation media itself. You can pull out the SD card that has OS installed when away from laptop to help mitigate evil maid attack <GaliantGazelle>I just need to now find out if I can use xfce or iw3m on Pinebook Pro. Anyone have experience with that who can confirm? <clever>GaliantGazelle: the rpi 0 to 3 are the same, all firmware is on the SD card, which you could then remove, but the open firmware is still an in-progress thing <unmatched-paren>GaliantGazelle: i haven't checked, but you almost certainly will be able to use i3, at least <GaliantGazelle>problem with rpi, doesn't it rely on closed source binary blobs for GPU? <clever>GaliantGazelle: there is open source replacements <clever>unmatched-paren: yeah, lk-overlay lacks hdmi init code, so the only video out you have, is either dpi or composite <unmatched-paren>GaliantGazelle: I'm sure the pinebook has plenty of nonfree firmware to be paranoid about :) ***mark_ is now known as mjw
<clever>this code uses nix to build all of the needed rpi firmware, and packages it up into both tar and deb forms <clever>if you dont mind open-source blobs, you could just configure guix to unpack that tar and copy the files to the right paths <clever>if you do mind open source blobs, youll have to port the vc4 cross-compiler to guix first <clever>GaliantGazelle: a pre-compiled binary, where the full source is available <clever>and your only using the pre-compiled binary, to avoid having to setup the compiler <antipode>+ source modifiable, redistributable, modified source redistributable, I assume <clever>but all of the directions assume you have nix, not guix <clever>so you would need to either adapt them, or install nix <GaliantGazelle>so open source blob unless reproducible, relies on trust of the person that compiled? <clever>GaliantGazelle: if you install nix, you can reproduce them yourself, and even use blobs youve built yourself <clever>i also tend to build with repeat enabled in nix, so nix builds everything twice, and fails if the duplicate is not bit identical <clever>`nix build github:cleverca22/rpi-nixos#dist` should build the tar <lunabee>hey if I submitted a patch a while ago and nobody's reviewed it, how long should I wait before asking/bumping? <unmatched-paren>lunabee: sometimes it can take a while, because there are a lot of patches and not many reviewers <unmatched-paren>i won't be able to push them, though, since i don't have commit access <gnucode>unmatched-paren: you are probably in the top 10 of people to get commit access soon. :) <gnucode>unmatched-paren only because your pending commits have yet to be committed. :) <gnucode>that's probably 37 or so more than I have. :) <gnucode>unmatched-paren: I complained to someone about switching git branches a few times, then I have to recompile guix all over again...then they strongly recommended git work trees.... <lunabee>unmatched-paren: oml that looks so useful <gnucode>unmatched-paren: yeah I just searched for it... <clever>so you dont have to pay the cost of a new clone <gnucode>apparently that will avoid the constant guix recompilation. <gnucode>I should probably try to learn about it at some point... <gnucode>I am pleasantly surprized to see that define-configuration now has some documenation in the guix manual. That's awesome! ***jesopo is now known as jess-o-lantern
<gnucode>I think I might convert my current service to use define-configuration. It just seems sooo much better than what I've got. <apteryx>weird. grep rottlog /run/current-system/profile/share/info/dir turns nothing <apteryx>but 'info rottlog' has it and it lives at /run/current-system/profile/share/info/rottlog.info.gz <Andronikos>Is it possible in guix shell container to share /proc instead of subdirectories int it or even / itself? <apteryx>(not really useful as a containerization strategy, but :-)) <Andronikos>If I do that it says "guix shell: error: mount: mount "/" on "/tmp/guix-directory.5Y3DVt//": Invalid argument" <apteryx>ah. I think these are limitations of bind mounts, although I don't haven't investigated enough to have a clear understanding <nckhexen>apteryx: Thanks! But compress → compress-force is a strange choice, considering your previous concerns? ***AndroUser is now known as dabbede
<nckhexen>apteryx: …ah, the change is inverted; the commit message is a lie^Wtest. *apteryx reported a bug for info-dir-entry <dabbede>dear all, can someone point me to a good tutorial on how to walk through guix code using emacs and geiser? <sadmax2>apteryx: The emacs manual is quite good <dabbede>Other IDEs are possible too, as I'm not familiar with emacs anyway ***maximed is now known as antipode
<apteryx>is there an equivalent to ,module or ,m (Guile REPL) for programmatic use? <apteryx>I want to write down my repro recipe and be able to execute it later <apteryx>i'll just rebind with (@@ (the module) private-proc) <apteryx>unmatched-paren: can't we simply mark the guix package as hidden? <unmatched-paren>apteryx: we can't because of ``guix shell guix'', ``guix shell -D guix'', etc <apteryx>is downgrading the error into a warning as suggested by zimoun OK with you? <unmatched-paren>i don't think there's any reason whatsoever to do ``guix install guix'' <apteryx>unmatched-paren: what is the use case that zimoun suggests? are guix library not already available for a guix user? <apteryx>(without having to 'guix install guix' <unmatched-paren>echo $GUILE_LOAD_PATH -> /home/paren/.guix-home/profile/share/guile/site/3.0 /run/current-system/profile/share/guile/site/3.0 <unmatched-paren>but i don't think it really matters; someone who wants to use it can just do ``guix shell guix'' <apteryx>I'm not sure if my suggestion to use an exception makes sense, but you could try 'guix install guix' and 'guix package -m manifest.scm' where guix is in the manifest and see if the error handlers generate the same thing when using the CLI (it should) <nckhexen>unmatched-paren, apteryx: Like you, I don't really understand the objection, so I can't really counter it (I tried here and it got a bit intense, probably due to bandwidth loss). I don't want to ignore it and just push, but it seems like apteryx at least agrees with keeping it as an error? <nckhexen>My attitude is also: try to DTRT the first time, but if this turns out to break a (legitimate) unforeseen use case, we can always downgrade it to a warning later; it's not the end of the world. <nckhexen>The make-compound-condition suggestion is a good one that wouldn't have occurred to me. *vagrantc wishes for "guix refresh --list-dependent | guix build" to work <vagrantc>or ... guix refresh --build-dependent ? :) <unmatched-paren>vagrantc: ``guix refresh --list-dependent PKG | awk -F ': ' '{print $2}' | xargs guix build''? <nckhexen>Having some option (which in retrospect should have been the default) to ‘guix refresh -l’ not to print the ‘friendly’ header would suffice to make $() work. <nckhexen>OK you pipe-obsessed maniacs, I give up. <nckhexen>(cut -d: -f1 is what I use, but that's because awk scares me.) <nckhexen>Just the hammer you know, & all that, and never taking the time to properly learn awk. <apteryx>did you know there's a tetris game written in awk? <unmatched-paren>all you really need to know to do many things is BEGIN { ... } is run at the start of a file, END { ... } is run at the end, { ... } is run for each line, $N is bound to the Nth field of the line (which is split with the -F delimiter, whitespace by default), and /REGEX/ { ... } only acts on lines that match REGEX. <nckhexen>apteryx: I didn't, but I'm 0% surprised. <vagrantc>does guix refresh never list PACKAGE:debug PACKAGE:someweirdinput ? <vagrantc>but sure, guix build $(guix refresh --list-dependent --only-the-packages-please) <vagrantc>but i run this on debian from guix shell with an ancient guix-daemon <nckhexen>vagrantc: Note that in practice I use ‘-f2-’, but that's more habit/overcaution, it really shouldn't happen with the current code. And since inputs aren't bound to outputs but to packages, it never should. <nckhexen><--list-dependent=packages> unmatched-paren++ <vagrantc>i mean, yes, i've definitely mangled with cut and/or awk before ... but it seems inelegant that something that is basically really input to guix build would require such shenanigans <apteryx>unmatched-paren: we should package these ;-) <vagrantc>apteryx: but your command-line-hacks.sh is very nice. :) <nckhexen>After editing it to fix the key bindings: that termmaze thing is mwah. <vagrantc>e.g. in order to test that it wasn't debian-specific, i updated guile-ssh and libssh in guix and had the same problem :) <vagrantc>unmatched-paren: feel free to CC me or whatever :) <vagrantc>not that i've got much in the way of review, but i can run it through a spellchecker or something. :) <unmatched-paren>vagrantc: I'm sure it's much easier to get Scheme through a spellchecker than other languages, given its general aver. to abbrs. ;) <vagrantc>yeah, there are a few inscrutible "allows to" and "This packages" that debian's lintian still complains about. I can't find them. <vagrantc>nckhexen found one in emacs-xyz.scm ... and there's another which might just be a false positive <lechner>Hi, what does this mean when building a Guile program via gnu-build-system, please? failed to create path for auto-compiled file "pam-misc.scm" <unmatched-paren>lechner: i think you need to add #:make-flags #~(list "GUILE_AUTO_COMPILE=0") <mbkamble>Hello. I wish to create a link to libstdc++.so.6 in /lib64 so that cross compiler toolchain installed by platformio can run. For this I am using (extra-special-file "/lib64/libstdc++.so.6" (file-append gcc "/lib/libstdc++.so.6")). <sneek>Welcome back mbkamble, you have 1 message! <sneek>mbkamble, jpoiret says: using manifests is orthogonal to provenance <mbkamble>But that does not work, because gcc has multiple outputs (out, lib, debug), and I need to specify the lib output. How do I achieve that? If I use (file-append gcc:lib "/lib/libstdc++.so.6"), I get an error gcc:lib unbound variable <lechner>vagrantc: did you catch swftools already (found via guix package --search="allows to") <vagrantc>lechner: odd, i remember actually fixing that one, but must have stashed it or left it in an abandoned branch, thanks! :) <mbkamble>unmatched-paren, yes I agree that creating the link in /lib64 is a hack. I haven't understood "guix shell" concepts well enough to use it. I was creating the above link in my system.scm file. <mbkamble>Nevertheless, for my understanding of gexp, can you show me what is the correct syntax to specify a output qualifier for the object when using the file-append function whose signature is (file-append OBJ SUFFIX) <apteryx>mbkamble: file append doesn't support outputs, but you could replace it with a gexp: #~(string-append #$gcc:lib "/lib/libstdc++.so.6") <mbkamble>ok. thanks for pointing me in that direction. <apteryx>its API is currently accepting any args as things to concat to base <apteryx>so to preserve the API you'd want to filter out '(#:output $value) from suffix or something <mbkamble>using (extra-special-file "/lib64/libstdc++.so.6" #~(string-append #$gcc:lib "/lib/libstdc++.so.6")) throws the error: <mbkamble>wrong type (expecting string): (string-append "/gnu/store/6d0p-blah-gcc-10.3.0.lib" "/lib/libstdc++.so.6") <mbkamble>The outer structure of the code in system.scm is: <mbkamble>(services (append (list (service gnome-desktop-service-type) (some-more-service-types) (extra-special-file ....)))) <antipode>mbakke, apteryx: You could give #$(file-append gcc "/lib/libstdc++.so.6") a try <antipode>Also, I'm not sure IIRC, but maybe 'gexp-input' has an output argument <mbkamble>how do I qualify the gcc with "lib" for the #$(file-append gcc "/lib/libstdc++.so.6") <antipode>OOps, incomplete message: #$(file-append gcc "/lib/whatever"):the-output <apteryx>my build-derivations output problem seems to be related to guile; they go away when I use 'guix repl' at the terminal <mbkamble>(extra-special-file "/lib64/blah" #$(file-append gcc "/lib/blah"):lib) also throws an syntax error: 