IRC channel logs


back to list of logs

<fnstudio>when i launch guix system reconfigure, is it possible to do that from a "control" server?
<vagrantc>haven't used it, but there's guix system deploy for that sort of thing, i think
<fnstudio>i mean for example from my local machine, by "pointing" the reconfigure against the remote server
<fnstudio>vagrantc: ah i see
<nckx>* guix deploy, for whatever reason.
<fnstudio>brill, will try that
<fnstudio>thanks both
*the_tubular aliases guix deploy to guix system deploy
<nckx>Heed, friend, the warning in the manual: ‘ The functionality described in this section is still under development and is subject to change.’
*nckx aliases guix system reconfigure to ‘r’, why not go full hog.
<nckx>…oh you weren't serious were you.
<the_tubular>Not really :P
<nckx>I meant I do so locally. I'm not going to add it to the defaults or anything.
<the_tubular>nckx, any clue what the latest commit about iso-codes is doing ?
<fnstudio>nckx: noted re things being a bit dynamic on the guix deploy side, tx
<nckx>the_tubular: I thought I answered that one already.
<the_tubular>Must have missed it :/
<nckx>Can happen. It removes the… dubious ‘Taiwan (Province of China)’ claim. Guix has many ambitions but promoting territorial claims ain't one.
<nckx>It was presented rather prominently in the Guix System installer, for example.
<the_tubular>Umm, that's not really what I was asking
<the_tubular>Why are iso-codes "known" to guix ?
<nckx>I don't understand the question.
<the_tubular>Nevermind, it's probably a dumb question then
<nckx>I genuinely have no idea.
<nckx>the_tubular: As implied (but not explained) above: Guix uses these codes rather prominently when you first boot the installer, and you select your language and region (or whatever order it uses). It's a huge list, so we don't maintain it ourselves, but use the iso-codes package from Debian (which itself is just ISO data packaged in usable form).
<the_tubular>Haa got it
<the_tubular>Thanks :)
<nckx>Sorry for misunderstanding the question.
<the_tubular>It's fine, my english is a bit broken
<nckx>The installer has always used the list, this is just a tiny tweak (and a variant so people running ‘guix install iso-codes’ still get the ‘official’ data, which for whatever reason I thought was important when I wrote the patch :)
<nckx>s/the list/the iso-codes package/ to be clear. The commit didn't ‘add’ it.
<nckx>the_tubular: I always assumed English your native language purely because of that nick; now I'll have to adjust.
<vagrantc>what would cause "guix build PACKAGE" to spit out a path in the store, but then that path is not actually there?
<lilyp>For the record, commit 54d2664339a4a44678372a4ff582c649bb568696 broke python-flake8
<lilyp>Can someone add a pyflakes-2.3 variant so that we can refer to it?
<lilyp>I'd like to do it myself, but I'm busy repairing my store
<vagrantc> for the above ...
<lilyp>vagrantc: try `guix build --repair'
<lilyp>though normally you would have an empty directory at least
<vagrantc>returns instantly
<vagrantc>and problem persists
<lilyp>hmm, can you manually gc it?
<vagrantc>i just gc'ed everything ... guix build --repair PACKAGE ?
<lilyp>try listing referrers first
<lilyp>yes, --repair PACKAGE and it requires super-user powers
<lilyp>though it should also work with STORE_PATH
<lilyp>and DERIVATION for that matter
<vagrantc>thanks ... never encountered this sort of thing before
<vagrantc>i did once have a corrupt grub ... that was fun!
<vagrantc>$ guix gc /gnu/store/kinpj568qrjdafjqaxbyrgcgv297lr1b-sendmail-8.15.2
<vagrantc>guix gc: error: extraneous arguments: /gnu/store/kinpj568qrjdafjqaxbyrgcgv297lr1b-sendmail-8.15.2
<mroh>sendmail means trouble.
<vagrantc>heh. well, that's besides the point, it's happened to at least one other package
<vagrantc>i am actively working on the packages affected, it's not with arbitrary packages...
<nckx>vagrantc: Missing -D ?
<vagrantc>i've played around with countless combinations of --rounds=N and --check with all these packages ...
<vagrantc>what are /gnu/store/*-builder files?
<vagrantc>well, no idea what's going on ... but maybe i can build it by renaming the phase i added :/
<vagrantc>the new name is better anyways. :)
<nckx>vagrantc: The build scripts. You can read one or even pretty-print it; it's Guile.
<nckx>Did guix gc -D ITEM not work?
<nckx>But yay for better names!
<vagrantc>nckx: i used --delete, but no, it did not work.
<the_tubular>Umm, guix pull is crashing with 52cb6e6310b908d29948064d060b2abe0b576c0c
<vagrantc>well, i used it to delete the .drv mentioned by --referals ... --refusers? --refuelers? whatever.
<vagrantc>but that .drv is so reproducible, it just kept recreating it.
<nckx>Did you try it on the phantom output directory? Just curious what would've happened.
<vagrantc>i normalyl don't say this with guix ... but i'm a little scared to try
<nckx>OK, don't.
<vagrantc>well, i deleted it ... but i'm currently in the middle of testing the new-and-improved-phase-name branch
<vagrantc>guix gc --delete /gnu/store/kinpj568qrjdafjqaxbyrgcgv297lr1b-sendmail-8.15.2 ... didn't act like it was deleting the thing that wasn't there ... so ... that's ... good?
<lechner>Hi, and sorry to interject! Should installing 'libreoffice' provide an executable named 'lowriter'?
<nckx>Not here.
<nckx>I always start it with ‘soffice’ but there's also a ‘libreoffice’. That's all.
<nckx>lechner: Do you mean we should change the package to provide it?
<nckx>‘libreoffice is a shell script that sets up the environment and passes the command line arguments to the soffice.bin binary. Alternatively, the following helper scripts start the respective module: sbase, scalc, sdraw, simpress, smath, sofficerc, swriter’ — so, hardly likely to be derided as bloat…
<nckx>Perhaps best to rewrite as a phase.
<nckx>the_tubular: Not here.
<the_tubular>Umm, weird
<nckx>It's not the kind of commit that should break other channels during guix pull, either.
<nckx>I can't speak for the preceding commits, of course.
<lechner>nckx: thanks! i'm fine using soffice; just did not know about it
<nckx>I don't use a desktop with icons so it's all I know.
<nckx>I'll look into installing the wrappers.
<vagrantc>soffice ... takes me back to the early aughts!
*nckx → 😴💤
<the_tubular>\ 'sanity-check' phasebuilder for `/gnu/store/khh67agxwf3rvbrrph2m4x0ki7b0my2c-python-flake8-3.9.2.drv' failed with exit code 1
<the_tubular>build of /gnu/store/khh67agxwf3rvbrrph2m4x0ki7b0my2c-python-flake8-3.9.2.drv failed
<the_tubular>Night nckx
<johnjaye>what are some things that might cause guix reconfigure to fail?
<johnjaye>slow internet or maybe something else?
<johnjaye>failed yesterday on a guix VM so trying again today. guix pull going now
<oriansj>johnjaye: insufficient RAM and insufficient Disk space are the most common
<johnjaye>this vm has 50G of free space and 2G of ram
<johnjaye>but it froze and then failed with some error about a derivation
<oriansj>yeah 2GB isn't enough if you are building some software
<johnjaye>what do you recommend for guix then
<oriansj>well a couple gigs of swap if you want to keep using 2G of RAM
<johnjaye>do i need to tell guix to use swap? or does it automatically do it
<oriansj>swapon is sufficient to turn swap on
<johnjaye>it says i have a 3.2GB swap partition in the vm
<oriansj>johnjaye: depends very heavily on what you need it to build
<johnjaye>i'm building guix
<johnjaye>that is the name of the system isn't it
<oriansj>8GB should be enough
<johnjaye>ok. if this fails i will remake the vm with an 8GB swap partition
<oriansj>you can use swapfiles
<oriansj>to test that assumption
<yewscion>the_tubular: I've just submitted a patch with some changes that fixes the issue You mentioned (I ran into it too). Looks like one of the inputs for python-flake8 was upgraded recently, and that upgrade made the test case fail solely because of the higher version number. Upgrading python-flake8 and python-pycodestyle to the latest upstream version
<yewscion>fixed the issue (I've also made sure those two packages now respect `--without-tests` for future issues like this).
<vagrantc>this gets virtuoso-ose building reproducibly, but it looks a bit ugly, any suggestions?
<johnjaye>yewscion: when you patch do you mean a literal patch file or a PR on github
<johnjaye>i ran into this the other day. you can submit changes to a project with a git command which emails a .patch file. but i think people don't mean that when they say patch now
<vagrantc>johnjaye: i don't think guix takes submissions via github
<yewscion>johnjaye: I don't use github except as a mirror, I meant a patch patch.
<johnjaye>correct. they use the git email command to litearlly send a .patch file
<johnjaye>ok. i think this is a genuine ambiguity now.
<johnjaye>as in hey let me submit a patch could mean multiple things now
<vagrantc>it's context dependent ... i woudl assume whatever patches are sent are sent in a way the project can recieve them :)
<johnjaye>heh. i asked someone on a project the other day about it. because the wiki had a vague paragraph about "sending patches". but they are github only
<johnjaye>so he explained patch didn't mean a literal patch there it just meant a PR on github
<johnjaye>next i'll have to ask someone what their definition of 'diff' is too
<yewscion>Slightly O/T: To whoever will eventually review my patch: If there are any issues, please let me know so I can fix them. I am still pretty new to contributing to Guix, but also more than happy to put in the work and learn something new.:)
<johnjaye>it's building gnutls-3.7.2.drv right now
<johnjaye>so hopefully that's a good sign.
<raghavgururajan>Hello Guix!
<jpoiret>do we have search-native-input-file?
<tissevert>hi guix
<r0man>10:03 *** NAMES @ChanServ \f _ctb _ether_ A_Dragon aartaka achow101 aeka agnem ahills ahlk akonai alanz Aleci[m] alethkit amk andi-[m] andrey_ angelos[m] anticomputer apoorv569[m] ardon ArneBab ashkitte1 astrisk0[m] atw Aurora_v_kosmose avalenn averell avoidr avp_ aweinstock AwesomeAdam54321 bandali barocio[m] bayfront-log bdju benevolentone[m] benjaminwil benoitj_ bingulo bitspook[m] bjc blackbeard bonz060 book` Br
<r0man>andong[m] breavyn brettgilio bricewge burst[m] bweezil califax cap catern catonano[m] cbaines cdegroot cedb cehteh char[m] chexum chipb Christoph[m] clacke clemens3 clone1 cmack cnx cocomeat4[m] colbyhub colemickens cols CompanionCube cwebber cyrozap danderson Daniel[m] darosior das5435[m] data68 davidl daviid daviwil deesix defaultxr denna[m] df dgcampea dhruvin DigitalKiwi dirtcastle distopico djeis dominicm dongc
<r0man>arl donofrio dragestil drakonis DrCat dubsm[m] duds- EdwardIII ees-mobile efraim eichin emacsen emacsomancer emacsomancer[m] EmmanuelMSmith[m englishm enzuru erhandsome Exa f1refly Fd9a FennecCode fiesh finktank[m] florhizome[m] fluffyballoon fnstudio fnurkla fps fredkid[m] fredmanglis_ ft fvio[m] Gamayun GardantaSpirito[ GavinFreeborn[m] ggoes gmodena gnoo GNUmoon GNUtoo GNUverkty[m] Gooberpatrol66 GreenLlama gry[m
<r0man>] Guest9533 hendi herlocksholmes heyarne[m] hibiki Hkon[m] horizoninnovatio hpfr htsr[m] hub idahotoken131[m] IdjaiQuincy[m] ifs[m] indieterminacy[m irfus Irvise itd iyzsong-w iyzsong[m] jackhill jacobk jadzi jakesyl___ janneke javbit[m] jbv1[m] jespada jess jetomit jfb4 jfred jfred-linode jgart[m] jgibbons[m] jladd jmcantrell jmes johnhamelink johnjaye jonsger[m] jorge[m] josibake_ jpoiret jsoo kaelyn Kalq[m] katco
<r0man> Keele Kimapr kinote KiranShila[m] kitty1 kitzman kodmin kristianpaul Kuschelyagi lagash lechner lembrun[m] les lh Lightsword lilyp lispmacs[work] litharge lizog luckyluke luhux[m] luke-jr Lumine m3tam3re[m] madage makx matijja meena mekeor[m] meo metamuffin[m] michel micro midgardian[m] midgardian[m]1 mikolajw minikN mnhrdt monadgauge mroh munksgaard murmr____ MysteriousSilver nalaginrut namtsui nckx nckx` ndjlj[m]
<r0man> nfbyte NinjaTrappeur Noisytoot noisytoot[m] noptys notzmv nullman Obydux[m] oriansj P1d0f[m] PacMiam parkgidoong[m] pashencija[m] patched[m] patrick paulapatience PaulePanter pdg pfd phodina[m] pie__ pinoaffe piyo pkill9 planglois playsolarroulett podiki[m] polykernel[m] PrinceMyshkin PurpleSym pushcx qzdlns[m] r0man raghavgururajan Rampoina rdrg109_ regtur rekado_ reproducible Reventlov rewine[m] reyman reza[m] rg
<r0man>herdt rheaplex richardhuxton risu robin roptat roptat[m] roscoe_tw rotty rovanion ryanprior[m] sabx SAIHAZE[m]1 sailorCat sajith sandb0y scisssssssors_ sebbu SeerLite[m] sheertj shiroikuma[m] silicius[m] singpolyma sjs sleepydog slep smashgrab sneek son0p sqrtminusone ss2 sss1 stampirl stfnbms strigo[m] stryan swaraj-[m] szgyg taeaad taiju[m] talos tbss[m]1 Tcache[m] Telc[m] teythoon thatoo[m] the_tubular theruran t
<r0man>immy tino[m] tinybronca[m] Tirifto tissevert toluene tom42 tongong Tril[m] ulfvonbelow unmatched-paren unwired user3456 V vito Vitor[m]1 vivien vlorentz voroskoi vup w1gz wehlutyk[m] whereiseveryone wigust willykin[m] wingo wisp wolfshappen wose Xe xgqt xMopx yjftsjthsd3 ylet[m] yuu[m] z572[m] zacchae[m] ZhuAisi[m] zirpu[m] zxtx
<lilyp>jpoiret: search-input-file (or native-inputs inputs)
<pie__>someone accidentally their emacs irc
<jpoiret>lilyp: teehee
<jpoiret>i feel dumb
<lilyp>happens to the best of us :)
<tinybronca[m]>I got pinged hmmmm
<indieterminacy[m>somebody is behaving a little creepy and smallminded.
<indieterminacy[m>Do they realise how uncivil they are being?
<indieterminacy[m>very uncouth indeed
<fnstudio>hey! when using guix deploy i seem to hit this error "guix deploy: error: unauthorized public key:"
<fnstudio>i did create a key on the coordinator machine (where i launch guix deploy from), using guix archive
<fnstudio>on the server (that i'm launching guix deploy against) i imported the key, also with guix archive
<fnstudio>if i look at /etc/guix/acl on the server, i can see the coordinator key listed among the authorised keys
<fnstudio>running guix deploy will result in the coordinator connecting to the server (so that part works) and performing a bunch of tasks (i.e. pulling i guess), up to the point that the changes need to be applied, and that's when i get the error
<fnstudio>this command works fine, instead: "guix deploy os.scm --execute -- uname -a"
<fnstudio>i have a vague feeling...
<fnstudio>i've added the authorised key to the server manually
<fnstudio>my os.scm file doesn't include the key, so my feeling is that as soon as the new system is being applied the key is removed from the authorised keys and the script ends up logging itself out, if that makes sense?
<fnstudio>i might need to add a guix-service-type as part of my os.scm file?
<fnstudio>ok, i've just found this that seems relevant
<fnstudio>lol, i can't believe it... it worked!!!
<fnstudio>guix deploy: successfully deployed test-server
<fnstudio>the issue was the lack of authorisation key in the OS definition
<fnstudio>the link above put me on the right track
<fnstudio>is running "guix deploy os.scm" similar to ssh-ing onto the server and running "guix reconfigure os.scm" from there? (the two os.scm wouldn't be exactly the same i guess)
<civodul>fnstudio: yes, it's equivalent
<fnstudio>thanks civodul!
<civodul>(though the file passed to "guix deploy" must return a list of machines, not an OS)
<lilyp>we need flatkill 2022
<fnstudio>is there a clear separation between the part of the OS that's modified vs left untouched by reconfigure/deploy?
<fnstudio>eg, i'll still have my files in /home/user/ after a guix deploy
<fnstudio>but the system will be otherwise updated
<fnstudio>i'll still have my system logs (in /var/log?) i suppose?
<lilyp>it only touches your system config and what's spawned from it
<lilyp>(and the gnu store of course)
<littlebo1eep>lilyp: Yes I would like to see 2022 assessment
<fnstudio>lilyp: thanks, yes, makes sense
<vivien>Since the configuration file returns a list of machines, the unattended upgrade service won’t work on the machine.
<vivien>Or has it been fixed?
<lilyp>unattended upgrade and guix deploy are kinda conflicting ideas, no?
<lilyp>like update from remote and update without any input are different things
<fnstudio>hm interesting, i'm trying to guix deploy a new os definition, which includes an nginx server
<fnstudio>i get a warning "an error occurred while upgrading services on ..." but then at the end i'm told that "guix deploy: successfully deployed ..."
<jpoiret>the error while upgrading services is when trying to restart the newly updated services, no? i might be wrong on that
<fnstudio>jpoiret: yeah, that makes sense, i'm still moving my first steps here...
<fnstudio>i also seem to notice that guix deploy doesn't uninstall software that had been guix-installed manually on the machine, is that expected? or am i doing something wrong?
<fnstudio>so for example, if my os.scm definition doesn't contain emacs but that had been installed manually, then emacs will survive a guix deploy
<fnstudio>(and therefore same for a guix reconfigure launched locally)
<fnstudio>oh my... how many questions as i continue exploring... i'm debugging things locally via "herd start nginx"
<fnstudio>this throws an error "herd: exception caught while executing 'start' on service 'nginx'"
<fnstudio>and some more info follows
<fnstudio>but it just says that there's an issue with the nginx config file, it doesn't say what or where exactly - any way to make it more verbose
<fnstudio>oh, easier than i thought... the full command is reported, which can be launched from the cli to view the full output
<fnstudio>ok, debugged, it was an issue with the nginx.conf generated by my web.scm
<fnstudio>the "listen" property defaults to 80 and 443, as explained here but i wasn't providing a TLS cert
<fnstudio>all working fine now - which is pretty incredible
<munksgaard>PurpleSym: Hi Lars, great job with the haskell fixes! I took a look at your suggestion to use `guix refresh`, and I think a good way forward would be to make sure both the hackage- and stack-updater work with the current packages. Running `guix refresh -t hackage` (and the equivalent stackage command) reveal some more cases we need to handle
<PurpleSym>munksgaard: Most failures I’ve seen so far were related to inconsistent indentation. Can you see other reasons for import failures?
<munksgaard>PurpleSym: I haven't tried with your latest changes, let me get back to you in a minute.
<PurpleSym>While we’re at it, I should probably rebase wip-haskell onto master and bump to Stackage 19.10.
<munksgaard>Another thing I noticed though, there are some packages that fail to build (after successfully importing) because the format of the generated description field is not compatible with what guix expects. OneTuple is one such package
<munksgaard>PurpleSym: Yeah, good idea
<PurpleSym>You mean because of the extra @-characters?
<munksgaard>PurpleSym: Yes, exactly
<ham5urg>Why can a 'guix pull' use a longer time to update the 'repository-information' (in Deb.-terminology)?
<ham5urg>E.g. calculating a derivation
<PurpleSym>The easy path would be to add some regular expressions and call it a day, but a proper haddock parser would be nicer, I guess. Is `lalr-parser` the best we can do in Guile Scheme?
<rekado_>(ice-9 peg) is another option.
<PurpleSym>munksgaard: I rebased wip-haskell on top of master.
<PurpleSym>rekado_: I’ll look into that, thanks!
<nckx>Morning, Guixs.
<fnstudio>hm... so i created a guix image and i'm using it as a custom image to spin guix VPSs via my hosting provider dashboard
<fnstudio>the image boots fine (you might have read the verbose accounts of my progress here ahah)
<fnstudio>but i now rebooted it and it seems there's some kind of filesystem error
<fnstudio>if i connect to the machine via a remote console (not ssh of course, the console web provided by the hosting provider), it says:
<fnstudio>e2fsck: bad magic number in super-block while trying to open /dev/vda1
<fnstudio>i'm tempted to think it's something i'm doing wrong as opposed to a read FS hw issue
<mroh>Good morning!
<fnstudio>(it also says "/dev/vda1 contains a vfat file system labelled 'GNU-ESP'")
<jpoiret>ham5urg: cause `guix pull` simply recompiles the whole of guix
<jpoiret>some of that part can be substituted, eg you can get the result of the compilation steps, but actually determining what the computation steps are takes some time
<jpoiret>(and if you guix pull right after someone has committed something, the CI won't have compiled guix itself, so your computer will take even more time doing that)
<ardon>fnstudio: You rebooted to the ISO or your os.scm? Have you removed the ISO from the custom ISO settings?
<nckx>fnstudio: Who's invoking e2fsck? The Guix System boot process?
<apteryx>jpoiret: I had issues with LUKS2 + pbkdf2 on top of Btrfs RAID; had to revert to LUKS1
<jpoiret>what kind of issues?
<nckx>Strange that it's dispatching e2fsck on a FAT partition, even if it is looking at the ‘wrong’ disc. Do you know if vda1 is supposed to be the ESP?
<apteryx>it wouldn't detect the file system
<apteryx>would complain the disk was missing or similar
<ZhuAisi[m]>I'm disappointed with the translation file(e.g.,, guix.zh_CN.texi. etc.), it's generated by bootstrap script and not managed by Makefiles.
<jpoiret>right, did you have /boot on a LUKS2 drive?
<ZhuAisi[m]>when the translation is updated, these files will be in a broken state, and I cannot clean it via `make clean`
<apteryx>boot is itself on the same LUKS + Btrfs RAID file system
<ZhuAisi[m]>I have to delete it manually
<ardon>Very newbie question here. I want to test out this patch for a dependency of clojure-tools which currently causes it to fail, is my best bet to simply override the package definition in my personal config?
<ZhuAisi[m]>How do you deal with these translation files when it become invalidated?
<jpoiret>well yes, that the main GRUB+LUKS2 issue we're talking about here apteryx
<jpoiret>there's a patch to the doc inside that bug that would add a warning
<fnstudio>ardon: that's a good point re the custom image, i'll check that out but i think it should be ok, i actually see the guix grub starting as expected
<apteryx>I'd suggest simply suggesting to use LUKS1 for now
<ZhuAisi[m]>ardon: you can clone the guix repo, then applied the patch, and `make && ./pre-inst-env guix do-something`
<fnstudio>nckx: yes, the guix system boot process
<apteryx>that'll spare some confusion until all the LUKS2 quirks are ironed out in GRUB
<apteryx>also, is this GRUB issue known upstream?
<apteryx>the patch links to a Guix issue
<apteryx>it'd be nice to be able to track upstream resolution
<jpoiret>yes, but there's no "clear" account anywhere
<jpoiret>ie isn't closed
<jpoiret>there are people talking about it on the mls though
<nckx>fnstudio: And you don't explicitly mark vda1 as ext* in your file-systems field?
<apteryx>jpoiret: I see
<fnstudio>ardon: yes, thanks, the machine seems to be booting from the hd, so there shouldn't be any problem with the custom image but thanks for suggesting that
<apteryx>I'm also getting something new since migrating to a larger file system (2.5 TiB -- 5 disks in RAID10): "error: attempt to read or write outside of disk `proc'". From what I've read, that could be a limitation of my BIOS when attempting to read past 2 TiB to access /boot
<fnstudio>nckx: i think i do make it as ext4, i'm doing something roughly along the lines of in terms of device, target, ...
<apteryx>the suggestion is to use EFI (can't) or use a separate /boot partition located near the beginning of the disk
<nckx>Refreshing my memory of mount-file-system: it doesn't look like Guix ever tries to auto-detect file system types, so somehow you're marking vda1 as ext* when it should be vfat.
<jpoiret>that would solve both problems then apteryx
<apteryx>jpoiret: OK! I'll be trying that, although it's painful because I need to repartition the disks
<nckx>fnstudio: Well, does your layout actually match theirs? Clearly, fsck thinks *your* vda1 is vfat.
<jpoiret>since there are people who might be tempted to use LUKS2, i'm more inclined to keep the long-winded explanations in the manual in the meantime
<fnstudio>nckx: oh, i see, i wonder how i ended up having a vfat partition thought, since i think ext4 was there already when i first created an image out of that system definition
<jpoiret>i initially worked on grub because many people on IRC reported that they couldn't get LUKS2 to work with grub
<ardon>ZhuAisi[m]: Thanks, I guess this is meant to be a temporary workaround until the patch lands in Guix? Meaning, if I used ./pre-inst-env to build clojure-tools, would I be able to target the fixed build in my manifests, for instance?
<apteryx>jpoiret: OK! Fair enough.
<nckx>fnstudio: I see. Too many unknowns for me to speculate usefully, I'm afraid. I'd boot a rescue system and take a look at the actual layout if possible.
<fnstudio>nckx: yeah, absolutely, thanks, i'll do so and report back :)
<ham5urg>jpoiret, thanks for the info
<jpoiret>ham5urg: the part that you'll always end up doing locally is the "Computing Guix derivation for XXXX [spinner]"
<jpoiret>then you'll either get substitutes for those derivations, or build them locally
<munksgaard>PurpleSym: Here's the result of running `./pre-inst-env guix refresh -t hackage` on the latest master:
<munksgaard>Those are all obvious candidates for something to fix, I think?
<munksgaard>I don't have time the next couple of days, unfortunately, but I'd be willing to help out at some point.
<PurpleSym>munksgaard: Ew, that backtrace at the end is pretty bad. I can have a look, but I’m also very short on time, so progress will be slow.
<fnstudio>is there anything i can do from the guile prompt i get when grub fails booting my machine? e.g. can i manually mount things from there?
<jpoiret>theoretically yes, but in practice it's pretty hard
<jpoiret>given that there's no readline support even
<jpoiret>i'm not sure if you have access to the local variables of the boot procedure
<PurpleSym>munksgaard: The most common issues I see are a) no terminating newline at the end of the file and b) mismatched indentation.
<fnstudio>jpoiret: understood, that's fine, thanks
<PurpleSym>There’s also still issues with bracketed values.
<munksgaard>PurpleSym: Yeah, you're right
<fnstudio>i see two partitions in my /dev/vda device... vda1 seems to be vfat (unexpectedly so); i imagine the bootloader ended up in vda1 while ext4 ended up in vda2, although i've no clear understanding/recollection of how this could have happened
<fnstudio>sorry, by ext4 i mean the main OS partition, the ext4-formatted one, the one i thought was sitting in /dev/vda1
<fnstudio>ok, i rebooted and let grub boot from an older option, it boots fine from that - i might have changed the bootloader config in my os.scm at some point, without realising it
<nckx>fnstudio: It wouldn't be unexpected if this VPS boots using UEFI (which itself is common). The example you're following doesn't use UEFI, so you can't just copy-paste all of it.
*nckx got interrupted, that reply's a tad stale.
<fnstudio>nckx: hey, thanks, i need to figure out if i belong to the UEFI case - i assume that's at the hosting provider level?
<jpoiret>hmmm, any guile heads here? if i use a parameter (eg %current-target-system) in a top-level (define var xxxx) block, it won't capture the right value since it'll be eval'd in the wrong dynamic extent, right?
<nckx>Does /sys/firmware/efi exist, fnstudio? If so, you booted Linux in UEFI mode.
<jpoiret>i'd need to make it a 0ary procedure, no?
<fnstudio>nckx: nope, i can only see acpi, dmi, memmap under /sys/firmware
<nckx>fnstudio: Do you have /run/booted-system/configuration.scm ? That should correspond to the system configuration you've currently booted, presumably ‘good’, which you can then diff with your current /etc one.
<fnstudio>so it must be bios instead of uefi? am i right?
<fnstudio>cool, let me see
<nckx>I… guess. But then why do you have a vfat partition at all? It must always have been there.
<nckx>I'm a bit confused, as you can tell.
<fnstudio>(that also answers another question i was going to ask re where do i found the current configuration! so double-thanks)
<nckx>What I'd do would be to reconfigure using the ‘old’ configuration but with a new Guix, to rule out any regressions in the initrd boot code. If that works, you know the error must have been introduced in your own system configuration changes since the currently booted working generation, and can discount upstream Guix bugs.
<fnstudio>no /run/booted-system/configuration.scm on my machine, but i see a parameters in that same folder?
<fnstudio>re guix bugs, i'd say that still extremely unlikely, i think it smells of some mistake of mine
<ham5urg>This is for an simple client, did someone set up an server?
<ham5urg>*This example
<nckx>fnstudio: Damn. That file (symlink) is created by operating-system-with-provenance which I guess isn't included in %base-services. (Might not be a bad addition…)
<nckx>Paste-o: provenance-service-type
<nckx>fnstudio: You don't have any back-ups of previous system configuration files?
<fnstudio>eheh i was looking for a possible backup right now!
<fnstudio>nckx: no backup i'm afraid... is it possible to inspect the guix image to retrieve some info?
<nckx>fnstudio: No judgment at all, but you don't remember editing your file-systems field or bootloader-configuration at all? I would.
<fnstudio>nckx: it's likely i edited it, yes. i have no certainty though, as i've made many attempts, i literally started working on this last night
<fnstudio>the image i generated out of the os definition with "guix system image ..."
<nckx>To make sure my understanding is correct: you're booting from a ‘regular’ Guix System installation to a hard drive, because you have older generations you can successfully roll back to (which you wouldn't have if you were writing an image to vda each time), right?
<nckx>Or: wrong? :)
<nckx>Or are your ‘generations’ here older images that you're insterting into some virtual control panel CD drive?
<fnstudio>nckx: my understanding is that i'm booting from a harddrive - where i initially installed guix using a custom image (uploaded to my hosting provider account via the hosting provider web interface)
<fnstudio>at boot time i have a grub panel popping up that i can see if i connect to the machine via a special console provided by the hosting provider
<nckx>But you installed Guix System as you would install it on a PC: by booting into the live image, then running ‘guix system init … /mnt’, and then your booted into the system and have been modifying it in place? Or are you deploying a new image from scratch each time?
<fnstudio>the grub panel gives me a few options (all pertaining to the same kernel but if i choose the oldest option the system boots fine)
<nckx>fnstudio: You could mount/boot the image and look for /gnu/store/*-configuration.scm or /gnu/store/*-image.scm, that's what I have here (but they might also be created by some service you lack).
<fnstudio>what do you mean when you say "a new image from scratch each time"?
<fnstudio>every time i reboot the machine?
<ham5urg>Is it correct to assume that any services are located under ?
<ZhuAisi[m]>ardon: If you need to persistence it, it's better to create your own channel, or override it in your configuration
<nckx>fnstudio: Something like that. You mentioned ‘guix system image’ earlier, that's where I'm getting the word.
<nckx>fnstudio: Did you use ‘guix system init … /mount-point-of-dev-vdaN’ to install this system?
<nckx>ham5urg: (You know that's a very old random copy of the official git repository, right?) In Guix proper: yes, all services are put there by convention. But other channels can put services wherever they like.
<fnstudio>nckx: no, i just uploaded the image to the provider, created a machine "out of" that image (which i suppose means the image is copied over to a drive for me)
<fnstudio>once the machine is booted it behaves as a (already installed) system
<fnstudio>subsequent reboots, i'm pretty sure, are giving me the same machine with the same drive (i.e. i'm not rebooting from the image)
<nckx>Pff. That's a workflow that I'm totally unfamiliar with and is kind of… too magical for my liking. But OK. So it boots successfully at least when freshly deployed.
<fnstudio>yeah, very magical, true, i've almost pulled an all-nighter for the excitment
<nckx>Which image type did you choose when running ‘guix system image’? That's cleary where the ESP (EFI System Partition) came from.
<nckx>Well, not clearly, but the alternative would be that the hosting provider magically added one to an image with a BIOS bootloader, which would be insane, so let's not assume that.
<fnstudio>(i've just launched a new machine from the same original image, so i should be able to investigate things better)
<nckx>OK. That sounds like a good place to start.
*nckx has to AFK a while, good luck.
<fnstudio>nckx: this is how i create the image: guix system image --image-type=qcow2 --image-size=20GB base.scm
<fnstudio>nckx: sure, thanks for now!! speak later
<fnstudio>no trace of "/run/booted-system/configuration.scm" in my system unfortunately
<fnstudio>"df -h" clearly says that root is on /dev/vda2
<fnstudio>it remains to see whether that's due to me using /dev/vda2 in an earlier version of the os definition, or if there's anything suspicious otherwise going on
<fnstudio>i think this can be double-checked by recreating an image from my current os definition (where, well, i'm sure i'm using /dev/vda1 instead of /dev/vda2) and see what happens when i upload it to the hosting provider
<fnstudio>i don't seem to have any /gnu/store/*configuration*scm or /gnu/store/*image*scm in my store, i.e. in the store of a machine booted from my guix image
<fnstudio>on a different note, when creating my image with "guix system image --image-type=qcow2 ..." i see that two derivations named "/gnu/store/" are created
<fnstudio>should that make me think that i get two partitions, one for vda1 and one for vda2?
<fnstudio>(which wouldn't be consistent with my os definition i suppose, since only use vda1 there)
<fnstudio>ok, i've now created a new guix image, where root is mounted onto vda1, according to my os definition
<fnstudio>i'm uploading it to my hosting provider and will be soon creating a new machine out of it
<zamfofex>fnstudio: Maybe you need ‘--save-provenance’
<fnstudio>zamfofex: oh, when i create the image with guix system image? right... good tip!
<jlicht>hey guix!
<zamfofex>Hello, jlicht!
<fnstudio>ah! i can confirm the following: i have a os definition with root mounted on vda1; i create an image out of it, upload it to a hosting provider, and spin up a VPS out of it; "mount" shows that root is mounted on vda2 instead
<fnstudio>this is weird... (to me)
<jpoiret>you use device paths?
<fnstudio>let me see
<jpoiret>is that standard for cloud servers (since you may not be able to rely on UUIDs)?
<fnstudio>jpoiret: here's the relevant snippet from my os definition:
<jpoiret>i take it you're not able to use partition labels or UUIDs?
<jpoiret>i've no clue in any case
<fnstudio>jpoiret: i'm not able as in "i wouldn't know how to do it" :D but i can look into that, thanks for suggesting it; not sure if i'm able to do it as in "i can do it in the given circumstances of using my hosting provider"
<jpoiret>since you were talking about having a base image that's copied, i'm not 100% sure you'd be able to do it
<fnstudio>ok, at least i'm able to reproduce the problem now
<fnstudio>once i "guix deploy" the same os definition onto the machine again, if i then try to reboot it, it breaks as it looks for root on vda1 but that seems to be VFAT
<fnstudio>i'm cautiously starting thinking there might be something wrong on guix' side
<fnstudio>or at least some slight inconsistency on how things are handled by guix system image vs reconfigure vs deploy
*nckx ret.
<fnstudio>if the issue were merely on the hosting provider side, the image wouldn't boot at all; or it would boot and continue doing so after a reconfigure
<nckx>fnstudio: Would you mind sharing your system.scm (if you haven't done so yet)? This should be reproducible in QEMU then.
<fnstudio>nckx: hey! i've some nice update! managed to make some progress. of course, no prob, very glad to share the system.scm, hang on a sec
<nckx>Yup, reading the backlog in the meantime.
<fnstudio>this is used for creating the image first; once a machine has been launched which is based on that image and reachable at, say,, i comment the last line and uncomment the previous section; then i use the file via guix deploy
<apteryx>GNUtoo: the issue with the submit button in h-client has been resolved (; it was a server-side issue.
*nckx waits for guix pull to complete.
<fnstudio>the deploy command works fine, provided that i configure the ssh fingerprint correctly
<nikola_>I have a question about dual booting guix, is there a way to install it without overwriting already existing grub installation
<tribals>I'm trying to use origin as a package input. It is downloaded properly. But how to refer to it then? Eg. in some build system's argument? #:install-plan of copy-build-system? #:modify-phases of other build systems?
<nckx>nikola_: Yes. You override the bootloader's installer to do nothing, successfully: — this will still create a /boot/grub/gruf.cfg [so make sure it doesn't overwrite what you have] with all the Guix generations in it, which you can then ‘configfile’ from your existing GRUB installation.
<nikola_>What if it's an MBR system
<nckx>tribals: What I (still) do is use old-style input labels, then (assoc-ref inputs label).
<nckx>nikola_: Modulo the -efi- part of course :)
<nikola_>I'll try that, thanks :)
<tribals> Hmm, if I'm not set explicit label, then which one will be assigned?
<nckx>That's what I don't know.
<nckx>You can always find out by adding (pk inputs) to a phase, but I wouldn't rely on it as API just yet.
<nckx>These inputs are captured by writing (lambda* (#:key inputs […] #:allow-other-keys) …) by the way.
<tribals>I'm also didn't understand clearly how to refer to inputs from where or there. Eg, i'm using copy-build-system, it takes #:install-plan argument with list of `(src dst)` plans. Could I use my inputs in src? In dst? How? `(stirng-append ...)`? `(file-append ...)`? What is the difference?
<maximed>tribals: with #$(file-append (this-package-input "foobar...") "/bin/something")
<maximed>string-append is a Guile procedure that appends strings. It knows nothing about G-exps or packages
<maximed>(this-package-input ...) takes an input from the package definition, returning it as a package
<maximed>(package != string)
<tribals>> When a high-level object such as a package or derivation is unquoted inside a gexp, the result is as if its output file name had been introduced.
<maximed>(file-append PACKAGE FILE-NAME) refer to FILE-NAME in PACKAGE -- the result is not yet a string, but some lowerable object
<tribals>What's confusing me. I understand it as: "whenever you need to refer to store path of some gexp as as string, unquote gexp"
<maximed>#$lowerable-object puts it in the G-exp, such that when the G-exp is actually run, it sees the object as a string
<maximed>tribals: Sounds correct.
***jesopo is now known as jess
<maximed>except for 'unquote gexp' -> 'unquote-gexp'
<tribals>That's lead me to: IF you need that path, you need to write gexp somewhere first, probably in other gexp. And finally, it leads to: are build-system arguments a gexps?
<tribals>Eg, in copy-build-system's #:install-plan, can I use them here? If so, then which form: one usable for `(file-append ...)`, or another, usable in `(string-append ...)` ?
<maximed>(1): ‘if you need that path, you need to write gexp somewhere’ -> not necessarily, there are some procedures for actually compiling a package object and returning it as a string (no gexps involved, except behind the scenes)
<maximed>That's never required in package definitions though AFAICT
<maximed>(only when writing things like "guix challenge", "guix build" or "guix shell")
<maximed>(2): depends on the build system and the argument
<maximed>The #:phases and #:configure-flags argument are gexps (they can be set to a sexp, but then it will be converted to a gexp automatically)
<maximed>possibly #:install-plan is a G-exp too, but I'm not familiar with copy-build-system
<maximed>However, #:tests? is just a boolean.
<maximed>(In principle it can be a G-exp which will be evaluated during the build, but no package does that or has a need to do that AFAIK)
<maximed>likewise for #:out-of-source?, #:tests?, #:strip-binaries? #:validate-runpath?
<maximed>tribals: Use string-append if you need string-append, use file-append if you need file-append.
<tribals>Hmm... When do I need string-append?
<maximed>tribals: When you want to append strings.
<maximed>(string-append "foo" "bar") -> "foobar"
<maximed>(string-append (assoc-ref inputs "foo-input") "/bin/bar") -> "/gnu/store/.../bin/bar"
<maximed>(string-append #$(this-package-input "foo") "/bin/bar")
<maximed>(the last one can also be written as #$(file-append (this-package-input "foo") "/bin/bar"))
<nckx>fnstudio: ‘guix system image --image-type=qcow2’ always creates an image with 2 partitions, one ESP, one ext2 root. That's just part of the definition of Guix's ‘qcow2’ image type. Furthermore, ‘guix system image’ completely *ignores* (well, overrides) the file-systems field of the operating-system you pass it. This is also by design, to allow you to specify any --image-type on the command line and having it just work, like a compressed iso9660 bootabl
<nckx>e CD with 2 ‘hybrid’ GRUBs so you can dd it to a USB drive (…phew), even if the o-s defines a completely different partition & file system layout. This is why the image boots: you could write whatever you want in place of (device "/dev/vda1"), even "/bogus/file", because it's never used. When you deploy, that file-system field suddenly becomes used and its bogosity is revealed.
<nckx>All this to say: if your / in the VPS is vda2, doesn't replacing vda1 with vda2 in your system.scm suffice to fix it?
<nckx>You're almost there; you're just taking ‘the initial image boots’ as a ‘my system.scm is correct’ signal, which it isn't.
<nckx>It would boot no matter what.
<nckx>(I… really hope that's clear, I'm out of words.)
<fnstudio>nckx: hey, it's very clear, thank you so much for taking the time to investigate this for me and to get back to me with such a thorough explanation
<nckx>s/ext2/ext4/ above, ahum, much modern distro.
<tribals>Thanks, seems to work
<fnstudio>nckx: i can definitely update my system.scm, s/vda1/vda2/ will do it as you suggest - on a more general level, i'm wondering... is there any facility as part of "guix system image" to have to provide any user feedback or any warning?
<tribals>How to specify named input directly from origin, though? :D
<tribals>Ie, for packages, it is: `("foo" ,foo)`
<fnstudio>i'm wondering whether it might be worth to let the user know that the filesystem section is being partially ignored or overwritten, rightfully so as a consequence of qcow2 also being passed
<tribals>For, origin, should it be: `("foo" ,(origin ...))` ?
<ardon>ZhuAisi[m]: Hey, sorry to ping you again. I've specified the overriding package (java-plexus-component-metadata-1.7) in my channel with the patch, but when trying to rebuild my home configuration, how can I be sure that maven-core will use the overriding package instead of the original one?
<nckx>fnstudio: That's probably better asked on a mailing list. I'm not an image or deploy user myself.
<nckx>It sounds reasonable.
<fnstudio>nckx: sure, thanks - will send an email there
<podiki[m]>fnstudio: that's true for certain image formats (like making a live usb disk) and I don't think is explicitly mentioned anywhere, would be good to
<maximed>tribals: that should work (modulo the long term goal of eliminating input labels)
<fnstudio>podiki[m]: super, will raise this in the ML
<maximed>you can also do #$(origin ...) directly in the #:install-plan or #:phases
<podiki[m]>I need guix everywhere! on my arch server: just figured out a bizarre error (one postgresql database operation causing a segfault), traced down to an incomplete/failed update due to disk space...wouldn't happen with guix's transacational updates
<nckx>podiki[m]: ‘Even’ for qcow2 where it's less immediately obvious (although equally logical once you think about it). There's a tension between ‘turn this o-s into a USB live system that just works’ and ‘I want to use this o-s long-term, and deploy/reconfigure it’. It's cool that Guix invites such broad use cases but it can expose cracks…
<nckx>*broad variation in
<podiki[m]>so maybe some clear indications in the manual/guix system output, to note what is not being used in an image
*nckx nods.
<lechner>Hi, why does this autoconf macro fail in my standard user profile even though Guile is installed and available, please? PKG_CHECK_MODULES([GUILE], [guile-3.0])
<podiki[m]>perhaps too intrusive to write in the system config for an image a comment above sections that were ignored in creating that system image?
<nckx>lechner: That's hard to answer? For example, pkg-config *could* be missing.
<nckx>podiki[m]: To which output file?
<podiki[m]>the system configuration .scm in the store, or explicitly /etc/config.scm in the disk image
<podiki[m]>although I don't remember what is saved in the system image produced offhand, but somewhere the config must be there?
<nckx>Doesn't seem to be…
<nckx>But that could easily be remedied. I'm just not as optimistic as you that adding comments there will notify a significant number of humans.
<podiki[m]>true, I think manual and output info is more important
<nckx>A classic warning: message at run-time would, at the cost of being mildly annoying.
<nckx>Then we'd have people asking what's ‘wrong’ with their file, the answer being nothing, sigh.
<nckx>…or why a discussion/brainstorm thread is needed :)
<podiki[m]>It doesn't really have a negative effect, say the bootloader config being ignored in producing an image, more the opposite direction, if you then wanted to use that for a regular system where you might assume it will work already
<podiki[m]>but not sure how to do anything for the reverse, that's just standard system config writing and understanding
<podiki[m]>I do think it is useful in the manual for creating images, so one doesn't have to spend time writing things that aren't used
<podiki[m]>a warning saying "you have a filesystem section that will be ignored" is educational at least
<nckx>I haven't actually tested (file-systems #f) [it may run afoul of some validation that happens before building] but it would make a clear example in the manual. Agreed.
<podiki[m]>this is also all to say the quick cookbook entry I wanted to write on creating live usb images with guix system could be made unnecessary with this info being in the manual :-)
<nckx>s/#f/'()/ if the former offends anyone :)
<podiki[m]>all good for a newcomer I'd say: see how you can create a quick and custom system image, try it out on your own hardware like you would other distro images
<lechner>nckx: pkg-config is there
<podiki[m]>I never remember which lisps and other languages have #f = or != to '() and such
<nckx>'() is true in Guile.
<podiki[m]>in summary: thanks fnstudio for bringing up this topic!
<fnstudio>podiki[m]: ahah thank you and nc
<nckx>Yep. And introducing me to a new use case for guix system image!
<fnstudio>and nckx for all your help!!
<nckx>I've only used it to make ‘rescue’ ISOs that I then upload & boot from to run ‘guix system init’ to a blank drive, old school, your method sounds more cloudy & modern.
<podiki[m]>I made the live USB image to test some hardware, see if Guix (linux-libre) would work by default
<fnstudio>i've always been intrigued by guix' devops possibilities and potential
<nckx>lechner: What are you building?
*nckx gets called away, sorry. o/
<maximed>lechner: on pkg-config and Guile: I remember some complications when there are multiple versions of Guile in $PATH of $PKG_CONFIG_PATH, so I recommend a --pure environment
<fnstudio>and i love the idea of orchestrating a cloud infrastructure just by running guix commands in a CLI (or even in an emacs buffer!)
<podiki[m]>fnstudio: I think as a portable distro in your pocket type (and with guix deploy) it can be very nice, especially as you can coordinate and keep synced system configurations between systems
<podiki[m]>yup! all seems very modern and reasonable to me
<maximed>antioxidated-drill now builds! (required a patch to support updating rust-tokio@0.2.20 to rust-tokio@1.18.2)
<lilyp>nckx: you should a random element to your faketime wrapper
<fnstudio>sorry, suppose i have a os definition in a file, and want to create another one in another file that builds on / extends the former definition, how would i do that?
<fnstudio>very much guile 101 i know, but would anyone be able to point me in the right direction?
<fnstudio>example os definition that i'd like to extend
<fnstudio>i know how to extend it by the way, by creating a section in the same file
<jpoiret>i'd say, use modules: if your file is named thing.scm, use (define-module (thing) #:export (my-os)) at the top (and optionally add #:use-module statements there instead of (use-modules ...))
<fnstudio>excellent, thanks!!
<jpoiret>then in another file other.scm, you can (use-modules (thing)) and use the my-os variable
<jpoiret>this is all modulo possible load path issues, i've never tried with loose .scm files
<jpoiret>you may need to add -L /your/directory to the command line for the modules to be usable
<apteryx>odd, fill-paragraph on a description in Emacs 28 doesn't always honor my 'fill-column setting (78)
<apteryx>fill-region works though, after selecting the text
<jpoiret>apteryx: maybe because of emacs-lisp-docstring-fill-column
<jpoiret>which you should set to nil
<apteryx>oh, is this a recent addition in Emacs?
<jpoiret>no idea, i don't see a 'added in emacs nn' part in the description
<the_tubular>You could try emacs-next ?
<jpoiret>it's in emacs 28.1 iirc
<vagrantc>sneek: botsnack
<nckx>lilyp: That's how it used to be. Why? Do you also judge me for my GitHubby graphy thing?
<apteryx>jpoiret: perhaps we should set emacs-lisp-docstring-fill-column to nil in our .dir-locals file
<apteryx>(we already set fill-column)
<jpoiret>does it affect other lisps? i remember having the issue but i don't remember if it was in Guile
<jpoiret>if so then definitely
<apteryx>would it matter if "it affected other lisps" ? the variables in .dir-locals.el are buffer local, if I recally correctly
<apteryx>so it'd only affect the Lisp (Scheme) files within the Guix checkout
<jpoiret>yes, but the emacs-lisp- would suggest that it only applied to emacs-lisp-mode. i just checked and it applies to lisp-mode in general, so yes
<apteryx>lilyp: python-flake8 doesn't build for me, commit b9c8c3585b
<the_tubular>same apteryx
*apteryx attempts to move to 4.0.1
<vagrantc>huh, bordeaux and ci seem to potentially run with different userid/groupid ... seems to have been embedded in a recent autogen build
<maximed>vagrant: normally shouldn't matter because of user mappings (at least for Linux, not implemented for the Hurd yet)
<apteryx>every now and then, when I offload builds, it goes on trying to build the rust toolchain... then I stop it and retry... and things are OK again. Weird, no?
<vagrantc>maximed: yes, i was surprised to see uid/gid matter at all
<vagrantc>maximed: from a "guix challenge autogen"
<vagrantc>i can workaround it in autogen ... think i found the place where that matters
<mitchell>hello guix. Can someone help me figure out how to get the git info pages installed? There are links to git pages in the guix info pages but installing git doesn't seem to install them.
<maximed>mitchell: Where are they in the guix info pages?
<maximed>I wouldn't expect Git to have an info manual.
<lilyp>apteryx: not my fault tho, I merely pushed a commit that worked before python-pyflakes got updated
<mitchell>maximed: under section 19.6 "submitting patches"
<mitchell>maximed: it links to a section for "submitting patches to a project (git)"
<maximed>mitchell: note Telling Git your name:
<maximed>(git)telling git your name.
<mitchell> i don't understand
<lechner>Hi, would someone please help me understand why on some of my equipment /sbin/knotc is in my personal profile, but not on others? Both machines serve DNS via knot-service-type and sudo guix system describe list-installed | fgrep knot comes up empty. knotc is in my personal profile on one but not the other
<mitchell>perhaps its an error in the way emacs is parsing the page?
<maximed>mitchell: it's also in 'info' (outside emacs)
<maximed>It was introduced in
<mitchell>So there are no git info pages
<maximed>The TeXinfo is: pxref{telling git your name,
<maximed>+, Telling Git your name, git, Git User Manual}
<lilyp>there's a patch sitting in the ml which bumps it, you might want to try your effort there
<maximed>I guess the , git, partn needs to be removed
<maximed>mitchell: I sent a bug report
<vagrantc>lechner: i think services aren't necessarily "installed" into the system profile in a way
<mitchell>maximed: Thank you! I am trying to educate myself on how to contribute
<vagrantc>lechner: though you can explicitly install knot in your system profile, if you want ... or just install it in appropriate user profiles if you need the utilities provided in it
<lechner>vagrantc: thanks! that was it. i'm still getting the hang of the different profiles. on unrelated equipment, i cannot use sudo and maintain three profiles (system, root and myself). it requires some training
<apteryx>lilyp the_tubular I have a fix locally, will build their dependents and push if all is OK
<Aurora_v_kosmose>Ah, erc ping.
<lechner>Hi, gdm is giving me delays I think even though I do not actually use GNOME. What's everyone second-favorite display manager, please? Also, is anyone else interested in greetd?
<mitchell>what is that?
<unmatched-paren>mitchell: greetd is a daemon that allows people to write display managers without any of the complex backend code (which is all handled by the daemon)
<unmatched-paren>lechner: i just use the tty to log in :)
<mitchell>unmatched-paren: 'ole reliable
<lechner>unmatched-paren: i would do that except my X does not start
<unmatched-paren>lechner: with startx? sorry, i'm a wayland myself
<mitchell>unmatched-paren: Is it much better than X? I've been thinking of giving it a go but i'm not eager to learn a whole new thing when X works well enough
<unmatched-paren>mitchell: you hardly notice any difference, if you can find a compositor that works like your current wm
<unmatched-paren>wayland is a lot simpler tho
<unmatched-paren>you just run the compositor, no `startx` or `xinit` or anything
<lechner>yeah, or sx from suckless. wayland is much better, but i'x experimenting with wms
<unmatched-paren>which wm do you prefer?
<unmatched-paren>there's probably an equivalent wayland compositor
<mitchell>good to know
<unmatched-paren>mitchell: yes, i'm using sway
<mitchell>will it run with my current i3 config?
<unmatched-paren>mitchell: maybe. they are *almost* compatible
<unmatched-paren>symlink it to ~/.config/sway/config and try it!
<mitchell>Mine isn't that complicated, just fixed the weird *almost* vim keys
<unmatched-paren>hmm, actually, can i see the i3 config first?
<unmatched-paren>ah, k
<unmatched-paren>it will work then
<unmatched-paren>mitchell: although sway uses exactly-vi-like keys by default
<unmatched-paren>not the shifted vi keys like i3
<unmatched-paren>default config
<unmatched-paren>`foot(1)` is the recommended terminal emulator
<unmatched-paren>so, all you need is to install `sway`, `foot`, and `swaylock`
<unmatched-paren>oh, i just remembered: you also need to make swaylock setuid
<unmatched-paren>and swayidle too... these programs really should be propagated-inputs of sway
<unmatched-paren>default bar is dmenu, but if you want something wayland-native use bemenu
<jackhill>I think there's a screen-locker-service for the swylock case (rather than doing setuid "manually")
<mitchell>ok. On a related note, my i3 keybindings for launching slock don't work. But launching it from dmenu does. slock is a setuid program and works as expected. Any ideas? I added it to the system profile so I'm pretty sure i3 should be able to find itd
<unmatched-paren>jackhill: ah, k
<unmatched-paren>jackhill: guess i should switch to that :)
<nikola`>lechner: what's sx
<unmatched-paren>nikola`: i think it's an alternative to startx
<unmatched-paren>synopsis: Start an xorg server
<unmatched-paren>description: `sx' is a simple alternative to both
<unmatched-paren>+ `xinit' and `startx' for starting an Xorg server.
<nikola`>Right, i couldn't find it
<lechner>nikola`: sorry, not suckless
<vagrantc>does (substitute* "somefile" (("@SOMETHING@") "@SOMETHINGELSE@") need to escape the @ ?
<vagrantc>on both sides, or just one?
<lechner>vagrantc: i think on both, but i'm very new
<vagrantc>i've admittedly been using .SOMETHING. instead of figuring out how to escape it, after checking that it's not likely to match anything else
<lilyp>Is @ even a Guile regexp thing?
<lilyp>I think you'd only need to escape it in autoconf, but when you do, simply write [@]
<vagrantc>i just know that when i use substitute with @ in it, it goes poorly
<maximed>you could try "\\@SOMETHING\\@" I guess?
<maximed>vagrantc: (string-match "@SOME@" "a@SOME@a") -> a match
<maximed>a guess: maybe "somefile" is a generated and patching it in a source snippet leads to Autoconf/Automake being confused about timestamps?
<tribals>Could someone please help me write proper package definition?
<unmatched-paren>tribals: sure!
<tribals>Feel free to comment right on gist
<unmatched-paren>why not use #:install-plan?
<unmatched-paren>seems perfectly appropriate for this
<civodul>so, are we merging 'staging' yet? looks pretty much ready to me
<tribals>unmatched-paren: Yes, I thought same at first. But I don't know how to reference file from input's origin in #:install-plan
<tribals>Please, take a look at updated gist: previous has an error
<unmatched-paren>tribals: Hmm... There's probably some implicitly-declared variable that you can use with gexps to get input paths.
<tribals>For now build fails with a message: In procedure copy-file: Not a directory
<unmatched-paren>like `inputs` in phases.
<unmatched-paren>oh, it's this-package-input, ok :P
<unmatched-paren>ah, i think i know the problem
<unmatched-paren>did your #:install-plan look like:
<tribals>Can't figure out: *what* is not a directory? Error message is very unhelpful, sadly
<unmatched-paren>`(("license.scm" "bin/") ((string-append #$(this-package-input "wtfpl") "/copying") "/usr/src/COPYING.WTFPL"))?
<unmatched-paren>it should be:
<tribals>Yes, it is currently commented out in gist (updated version)
<unmatched-paren>#~`(("license.scm" "bin/") (,#$(string-append (this-package-input "wtfpl") "/copying") "/usr/src/COPYING.WTFPL"))
<unmatched-paren>i think this will work
<unmatched-paren>or actually
<unmatched-paren>#~`(("license.scm" "bin/") (,(string-append #$(this-package-input "wtfpl") "/copying") "/usr/src/COPYING.WTFPL"))
<unmatched-paren>you forgot gexp+unquote :)
<the_tubular>lechner Do you use that with guix ?
<the_tubular>Looks interresting
<the_tubular>Altought startx comes with x by default correct ?
<maximed>the_tubular: it is part of 'xinit'
<lechner>the_tubular: I use Guix System, but sx does not work properly. i have no input devices.
<tribals>unmatched-paren: In procedure string-append: Wrong type (expecting string): (quasiquote (((unquote string-append) (ungexp (this-package-input "wtfpl")) "/copying") "/usr/src/COPYING.WTFPL"))
<unmatched-paren>tribals: you've got unquote in the wrong place i think
<unmatched-paren>you're doing (,string-append ...)
<unmatched-paren>instead of ,(string-append ...)
<oriansj>stikonas: your untar patch has been merged
<vagrantc>is there a way when doing ... guix build --rounds=2 PACKAGE ... to have it run diffoscope on the two differing things ... much like guix challenge --diff=diffoscope PACKAGE
<oriansj>sorry wrong window
*unmatched-paren \o
<unmatched-paren>s/\o/leaving, bye :)/
<unmatched-paren>s/leaving/got to go/
<apteryx>vagrantc: guix build -K --rounds=2 (or --check --no-grafts)
<tribals>Could I suggest complete example directly in gist, with proper indentation, please? I've tried #~`,((string-append #~`(,(string-append #~((,string-append - nothing worked
<apteryx>then diffoscope /path/to/failed-build{,-check}
<tribals>unmatched-parent: sorry. You provide, not me
<vagrantc>apteryx: yeah, but none of those run diffoscope ... i'm left to manually screen-scrape the output, mangle it, and pass the /gnu/store paths to diffoscope manually
<vagrantc>apteryx: it would be nice to automate some of those steps, like with guix challenge
<vagrantc>... guix build: error: derivation `/gnu/store/dn50zya4d1zh21q6s3nh7f394s7ksknv-autogen-5.18.16.drv' may not be deterministic: output `/gnu/store/04byv4py1firka28h3nl70bj1g0a3n6k-autogen-5.18.16' differs from ?/gnu/store/04byv4py1firka28h3nl70bj1g0a3n6k-autogen-5.18.16-check?
<vagrantc>i sometimes end up accidentally grabbing the .drv ... sometimes i grab the -check url, or line-wrapping makes it trickier to grab one or the other ... and i have no idea how one would automate that without a trained monkey
<tribals>In unknown file:
<tribals> 2 (copy-file "/gnu/store/sa1ac8ag8zqay4fwij9m7p8f6j0a3k5…" …)
<tribals>That's annoying. Should I guess which file is not copied?
<vagrantc>bah. i keep ending up in a state where ./pre-inst-env guix build PACKAGE ... ends up thinking there's a /gnu/store/xzy123-PACKAGE-VERSION ... but it's not
<oriansj> to start a call to action for getting rid of pregenerated files being used in Builds
<nckx>oriansj: Nice (and rewritten, I think…? For the better.)
*vagrantc suspects some crazy combinations of: guix build --keep-failed --rounds=2 --check
<vagrantc>or maybe i need to rebuild my guix.git checkout with ./bootstrap && ./configure --localstatedir=/var ...
<ulfvonbelow>is zstd supposed to install some cmake stuff?
<civodul>ulfvonbelow: "guix graph --path -t bag zstd cmake-minimal" says no
<ulfvonbelow>hmm, well some other packages seem to think that some "libzstd_shared" cmake target should be defined
<civodul>ah sorry, i misunderstood the question
<civodul>zstd:lib provides a .pc file though
<ulfvonbelow>yeah, I saw that, but apparently cmake's find_package procedure thingy doesn't consult pkg-config, instead insisting on some "FindZstd.cmake" or similarly-named file
<ulfvonbelow>... which presumably are themselves supposed to consult pkg-config I guess
<vagrantc>ok, guix gc --delete /gnu/store/HASH-PACKAGE-VERSION ... when it does not actually exist does appear to get it to rebuild the package
<vagrantc>but ... but ... why is this happening to me? :)
<vagrantc>hrm. i should probably dig out my behemoth aarch64 machine out of the closet and test staging...
<vagrantc>though i'm not sure i'm game for building all the things
<apteryx>vagrantc: it'd be nice if guix build --check --rounds=N didn't produce corrupted store items, too :-)
<vagrantc>apteryx: if that is indeed what it is...
<vagrantc>any suggestions to make this less ugly?
<vagrantc>other than making a better name for the phase... maybe splitting it into two phases
<vagrantc>also would seem error-prone on updates to miss new things...
<vagrantc>new files or something
<vagrantc>maybe some find_files ...
<apteryx>you could process all the files if with (find-files ".") if you wanted, but it's fine the way it is
<apteryx>up to you :-)
<vagrantc>that might not be as crazy a suggestion
<GNUtoo>apteryx: thanks a lot for the information