IRC channel logs


back to list of logs

<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?
<ric342[m]>Does Guix have an equivalent to ? I e , different grub entries for different kernels, configurations, etc.
<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]>Maybe it's still possible but undocumented?
<ric342[m]>It's quite a nice feature
<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>rekado_: woohoo!
<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
<flatwhatson>Andronikos: ^^
<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 $(./etc/teams.scm cc-members origin/master HEAD) 0000-cover-letter.patch doesn't work for me
<apteryx>I get: fatal: ambiguous argument ''': unknown revision or path not in the working tree.
<apteryx>more context:
<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>it's an executable Guile script
<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
<the_tubular>Every command I try isn't working ...
<Aurora_v_kosmose>the_tubular: /sys/class/net/$devname/address
<Aurora_v_kosmose>You can cat it.
<Aurora_v_kosmose>...right that's jsut the MAC... well now I'm not sure again.
<the_tubular>Yeah, that seems to be just the mac :/
<Aurora_v_kosmose>I was sure there was some sysfs way to do it but I can't recall it.
<the_tubular>Same lol
<apteryx>rekado: if you want to test --symlink for 'guix shell', see :-)
<the_tubular>I should have noted it somewhere ...
<apteryx>'ip a' ?
<Aurora_v_kosmose>I assumed those tools wouldn't be working considering earlier command mentions.
<the_tubular>Command not found
<apteryx>even our bare-bones.tmpl guix system template has iproute in %base-packages
<apteryx>(which provides ip)
<Aurora_v_kosmose>Something wrong with PATH then?
<the_tubular>No, I removed %base-packages
<the_tubular>I must be able to find it with netcat :P
<the_tubular>Damn it don't have netcat on host
<the_tubular>Can I see ICMP packets with netcat on listen mode or something ?
<the_tubular>Got it!
<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*)))))
<Aurora_v_kosmose>If you can get Guile open.
<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 or loopback address.
<Aurora_v_kosmose>Hmmm... well seems like it's not fail-proof. One of my VMs still answered with loopback.
<Aurora_v_kosmose>Ah... that 'car bit is the issue. If you have multiple interfaces...
<Aurora_v_kosmose>So map on that instead.
<apteryx>$12 = ("" "" "") :-D
<apteryx>that was for my host name
<Aurora_v_kosmose>...well damn
<Aurora_v_kosmose>My guile-fu has failed me
<apteryx>'nmcli con', but if you don't have %base-packages, I doubt you have that one either
<flatwhatson>ooh the online manual got a facelift, nice work :)
<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>currently, the patch series seems like an awesome work, made by kaelyn, and it's actually an improved version of, which is already pushed to the update-vulkan-headers-staging branch for ci test.
<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
<unmatched-paren>morning guix!
<lilyp>it's not quite that easy since the series targets c-u
<lilyp>so you have a lot of manual builds
<Lumine>Good morning #guix
<jeko>Good morning Guiiiiiiiiiiiixters !
<linj>brendyn: Is this what you mean by "pull from the local repo"?
***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.
<brendyn>linj, --disable-authentication
***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
<daviwil_>Following up on my question about using Emscripten SDK on Guix yesterday:
*qzdlns[m] uploaded an image: (146KiB) < >
<qzdlns[m]>o/ hi guix; I'm seeing a derivation error for hashes of go-gopkg-in-yaml-v3 (; in replicating this and looking for context, it seems the tagging situation in the mother repo is whacked out (
<qzdlns[m]>I'm seeing this from the current HEAD of guix; 95d44c0586873d79e897e1f84f7644bdd4696a58 (
<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 tag spec `@TAG`
<antipode>What would those be used for?
<antipode>'git-fetch' is a Guix thing, not a thing
<qzdlns[m]>they come from the upstream, only really useful if we're doing url-fetch > git-fetch (
<antipode>I am not following.
<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 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 tag spec `@TAG`'
<qzdlns[m]>ah right; I meant that there is a greater resolution from gopkg available, if a commit isn't used [ | ]
<qzdlns[m]>but this is still inferior to using some CID like a commit
<qzdlns[m]>anyway, this is a dependency to docker, which is failing to build on my metal -- guix ci is passing, likely because this hasn't received an update so is using the version of this yaml gopkg from it's store
<antipode>qzdlns[m]: AFAICT the @TAG from is not any more or less precise than the TAG from the underlying git repository.
<antipode>I mean, v3.0.0 = v3.0.0.
<antipode>Unless 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>I don't mean that.
<antipode>However you order your version strings, their tags remain mutable.
<qzdlns[m]>yeah.. clearly
<antipode>I meant, maybe if v3.0.0 initially points to deadbeef and then imports the repo, and later v3.0.0 points to cabba9e, then keeps pointing to deadbeef and doesn't switch to cabba9e.
<qzdlns[m]>this is just the semantics of git tagging
<qzdlns[m]>>I meant, maybe if v3.0.0 initially points to deadbeef....
<qzdlns[m]>I think this is exactly what they did with their tagging
<antipode>AFAICT, they did the opposite going by their reply.
<antipode>"There was only aever one single tag on v3.0.0"
<antipode>* aever -> ever
<antipode>Though maybe they meant something else.
<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]>* v3, and -> v3, and tags
<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>"ld -lc --verbose" output
<jamesw>ld: mode elf_x86_64
<jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib64/ 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/ 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/ failed
<jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib/libc.a failed
<jamesw>ld: cannot find -lc
<jamesw>attempt to open /gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/x86_64-unknown-linux-gnu/lib64/ 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/ 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/ 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.
<tricon>jamesw: please use for long lines.
<xd1le>jamesw, use a paste service
<tricon>xd1le: jinx.
<jamesw>could you help me on this issue?
<jamesw>would anybody here plesae help me?
<tricon>first, run: ls -al $(which ld)
<tricon>jamesw: ^
<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
<jamesw>its output is the above
<tricon>(one moment, work thing...)
<antipode>Why not use gcc instead?
<antipode>"gcc -o abscall abscall.o" (assuming that's how you pass .o to gcc)
<jamesw>let me try it..
<jamesw>$ gcc -o abscall abscall.o
<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>Did you define a 'main' function?
<antipode>(with proper visibility -- I don't know how that works in assembly)
<jamesw>my simpe assembley source is :
<jamesw>       .globl _start
<jamesw>        .section .text
<jamesw>        ## Fisrt parameter is -5
<jamesw>        movq $-5, %rdi
<jamesw>        ## Call the function
<jamesw>        call abs
<jamesw>        ## Result is in %rax, move to %rdi for the exit syscall
<antipode>I don't know assembly.
<jamesw>        movq %rax, %rdi
<jamesw>        movq $60, %rax
<jamesw>        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>So why link against -lc then.
<jamesw>call abs
<jamesw>abs() function
<antipode>Right, didn't notice that.
<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>per said in the GUIX manual
<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 ?
<jamesw>in Guix
<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.
<rekado>that’s the right ld
<gnucode>hey guix friends!
<jamesw>        .globl main
<jamesw>        .section .text
<jamesw>        movq $-5, %rdi
<jamesw>        ## Call the function
<jamesw>        call abs
<jamesw>        ret
<jamesw>===compile command and output==
<jamesw>$gcc absmain.s -static -o absmain
<jamesw>ld: cannot find -lc
<jamesw>collect2: error: ld returned 1 exit status
<jamesw>$ guix package --list-installed
<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
<zinc[m]>omg. use pastebin
<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. :)
<jamesw>is it right ?
<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?
<unmatched-paren>afternoon guix! :)
<rekado>jamesw: check where your “ld” comes from. You’re using the wrong ld.
<jamesw>echo $(which ld)
<unmatched-paren>jamesw: better ``command -v ld''
<gnucode>howdy unmatched-paren
<unmatched-paren>(the echo is redundant, and which isn't optimal)
<unmatched-paren>gnucode: hi!
<jamesw>is there something wrong for this "ld" ?
<jamesw>james@T30 ~$ which ld
<jamesw>james@T30 ~$ which gcc
<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>the assembly source file:
<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>nckhexen, rekado ^
<rekado>as good as any
<apteryx>OK! I'll do so now.
<apteryx>should be back up in ~20 min...
<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?
<fredg>hello o/
<jamesw>The issue of " ld: cannot find -lc" for  abscall.s  ==>
<jamesw>your help , please...
<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
<jamesw>rekado: $echo $LIBRARY is null
<apteryx>ah, so it does make it easier for us
<apteryx>to rotate things. neat
<rekado>jamesw: LIBRARY_PATH
<rekado>it’s set when gcc-toolchain is installed
<apteryx>what should our anonymized log retention be? 3 months sounds decent to me.
<jamesw>let me try
<apteryx>the machine is back up, but the web pages are still down
<apteryx>according to 'herd status', nginx is down:
<apteryx>along anonip*
<rekado>check that the files that anonip uses are in fact FIFOs
<jamesw>rekado: not be fixed == >
<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'
<sneek>Got it.
<rekado>apteryx: I’m connected over SSH
<rekado>load is pretty high
<apteryx>yeah SSH is back
<apteryx>it was just the load
<apteryx>seems the nginx log files aren't FIFOs, right?
<apteryx>just plain files
<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
<rekado>it should create them by itself
<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 removed them
<apteryx>13T /var/log/anonip/ :-D
<rekado>not these
<rekado>ls /var/run/anonip
<rekado>nginx has started
<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.
<antipode> [...] Thus, the FIFO special file has no contents on the filesystem; the filesystem entry merely serves as a reference point so that processes can access the pipe using a name in the filesystem.
<apteryx>why can't I access rottlog info manual in my Emacs? It's at /run/current-system/profile/share/info/, and M-x getenv INFOPATH has /run/current-system/profile/share/info, among others.
<apteryx>antipode: thanks :-)
<GaliantGazelle>Are .iso images reproducible?
<GaliantGazelle>or should I build from source?
<GaliantGazelle>especially interested in pinebook pro image
<GaliantGazelle>Question 2, pinebook pro has support for xfce or iw3m?
<apteryx>GaliantGazelle: hopefully yes! else it's a bug
<GaliantGazelle>apteryx  yes for question 1 or 2?
<kaelyn>janneke: Not sure if you've seen the bug yet, but over the weekend I filed 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.
<apteryx>GaliantGazelle: question 1
<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>in that case people would want to build iso themselves
<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
<unmatched-paren>i3 should run on pretty much anything that can run X
<GaliantGazelle>problem with rpi, doesn't it rely on closed source binary blobs for GPU?
<clever>GaliantGazelle: there is open source replacements
<GaliantGazelle>wow I must have been out of touch for a while
<GaliantGazelle>that was the one reason I disliked rpi
<clever>GaliantGazelle: allows the pi2 and pi3 to boot into linux headlessly
<unmatched-paren>i think the rpi gpu firmware is very wip though
<clever>but the internal design was a bit limiting, so i ported all of the useful features to
<GaliantGazelle>very clever
<clever>unmatched-paren: yeah, lk-overlay lacks hdmi init code, so the only video out you have, is either dpi or composite
<clever>composite can do ntsc or pal
<clever>dpi can be converted into vga
<unmatched-paren>GaliantGazelle: I'm sure the pinebook has plenty of nonfree firmware to be paranoid about :)
<unmatched-paren>Probably in the wifi card, cpu microcode, etc...
***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
<GaliantGazelle>what is "open source blob"?
<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>antipode: yep
<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?
<pkill9>hello guix
<unmatched-paren>pkill9: evening
<unmatched-paren>lunabee: sometimes it can take a while, because there are a lot of patches and not many reviewers
<unmatched-paren>but if you point me to the patch, i'll take a look :)
<lunabee>unmatched-paren: yeah, that's completely fair. patch is thank you so much!
<unmatched-paren>okay, i'll apply and test those now :)
<unmatched-paren>i won't be able to push them, though, since i don't have commit access
<lunabee>alright! thanks again :)
<gnucode>unmatched-paren: you are probably in the top 10 of people to get commit access soon. :)
<unmatched-paren>gnucode: i don't have 50 commits yet :)
<gnucode>unmatched-paren only because your pending commits have yet to be committed. :)
<unmatched-paren>I have 39 commits so far
<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....
<gnucode>what the heck are those?
<unmatched-paren>it allows you to have multiple working trees, basically
<unmatched-paren>i've never used it, but it seems pretty useful! :)
<lunabee>unmatched-paren: oml that looks so useful
<gnucode>unmatched-paren: yeah I just searched for it...
<clever>and they share the .git
<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/
<Andronikos>Is it possible in guix shell container to share /proc instead of subdirectories int it or even / itself?
<apteryx>--share=/ I think
<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
<lunabee>unmatched-paren: thanks!
<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
<apteryx>info-dir-file, rather
<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
<unmatched-paren>lunabee: Okay, I've replied to them all :)
***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)
<unmatched-paren> <- could somebody please review this? :)
<apteryx>unmatched-paren: can't we simply mark the guix package as hidden?
<apteryx>the same as 'gcc' is hidden, sa
<unmatched-paren>apteryx: we can't because of ``guix shell guix'', ``guix shell -D guix'', etc
<apteryx>ah! I see.
<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''
<unmatched-paren>(we debated this earlier)
<z4kz>hi #guix geeks
<unmatched-paren>z4kz: evening!
<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>i'm pretty sure it is
<apteryx>then I miss their point
<unmatched-paren>hmm, no, actually i don't think it is
<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've done a small review
<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)
<apteryx>does someone know how to make build-derivations show the build log at the REPL? This is what I see:
<unmatched-paren>apteryx: guix package -m manifest.scm doesn't seem to error out...
<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.
<unmatched-paren>awesome, pyproject-build-system's been merged :)
*vagrantc wishes for "guix refresh --list-dependent | guix build" to work
<vagrantc>or ... guix refresh --build-dependent ? :)
<nckhexen>That's too weird.
<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.)
<unmatched-paren>I like awk and I don't understand why so many people don't.
<nckhexen>Oh, I don't dislike it!
<unmatched-paren>I didn't know about cut -d though, thanks :)
<nckhexen>Just the hammer you know, & all that, and never taking the time to properly learn awk.
<nckhexen>Er, -f2, but that aside.
<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.
<nckhexen>(100% impressed, though.)
<apteryx>perhaps this one:
<vagrantc>does guix refresh never list PACKAGE:debug PACKAGE:someweirdinput ?
<nckhexen>vagrantc: No.
<vagrantc>e.g. can you reliably split on : ?
<unmatched-paren>the gawk gnu manual is pretty good
<nckhexen>vagrantc: Yes, but good question.
<vagrantc>but sure, guix build $(guix refresh --list-dependent --only-the-packages-please)
<unmatched-paren>vagrantc: i wondered that too, hence -F ': ' instead of -F :
<unmatched-paren>``guix refresh --list-dependent=packages''?
<vagrantc>seems reasonable to me.
<vagrantc>but i run this on debian from guix shell with an ancient guix-daemon
<unmatched-paren>i was expecting that awk tetris script to be massive
<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.
<unmatched-paren>it's only 444 lines, even more impressive :)
<nckhexen><--list-dependent=packages> unmatched-paren++
<apteryx>vagrantc: perhaps you can try something of interest here:
<vagrantc>sounds worth a feature request
<unmatched-paren>AHAHA WHAT.
<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>I agree
<apteryx>unmatched-paren: we should package these ;-)
<vagrantc>apteryx: but your is very nice. :)
<vagrantc>this is all basically yak-shaving resulting from ...
<unmatched-paren>i'll try implementing that in a moment
<nckhexen>After editing it to fix the key bindings: that termmaze thing is mwah.
<unmatched-paren>--list-dependent=packages, i mean
<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: oh, great!
<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. ;)
<unmatched-paren>Sorry, gnrl 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 in /lib64 so  that cross compiler toolchain installed by platformio can run. For this I am using (extra-special-file "/lib64/" (file-append gcc "/lib/")).
<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/"), I get an error gcc:lib unbound variable
<lechner>unmatched-paren: thanks!
<lechner>vagrantc: did you catch swftools already (found via guix package --search="allows to")
<unmatched-paren>mbkamble: i think what you want is guix shell -CF
<unmatched-paren>or, in long form, guix shell --container --emulate-fhs
<unmatched-paren>or just package that toolchain for guix :)
<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/")
<mbkamble>ok. thanks for pointing me in that direction.
<unmatched-paren>apteryx: maybe we could add a #:output argument?
<unmatched-paren>(file-append gcc "/lib/..." #:output "lib")
<apteryx>its API is currently accepting any args as things to concat to base
<apteryx>(base . suffix)
<apteryx>so to preserve the API you'd want to filter out '(#:output $value) from suffix or something
<unmatched-paren>done :)
<mbkamble>running into syntax errors:
<mbkamble>using (extra-special-file "/lib64/" #~(string-append #$gcc:lib "/lib/")) throws the error:
<mbkamble>wrong type (expecting string): (string-append "/gnu/store/6d0p-blah-gcc-10.3.0.lib" "/lib/")
<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/") a try
<unmatched-paren>...I forgot the copyright line. It's always the copyright line.
<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/")
<antipode>OOps, incomplete message: #$(file-append gcc "/lib/whatever"):the-output
<antipode>mbkamble = mbakke?
<apteryx>my build-derivations output problem seems to be related to guile; they go away when I use 'guix repl' at the terminal
<mbkamble>nope. I am not mbakke.
<mbkamble>(extra-special-file "/lib64/blah" #$(file-append gcc "/lib/blah"):lib) also throws an syntax error:
<mbkamble>error: ungexp: unbound variable
<vagrantc>unmatched-paren: thanks!