<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).
<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
<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…
<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>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
<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>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>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
<ardon>Very newbie question here. I want to test out this patch https://issues.guix.gnu.org/55776#2-lineno15 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?
<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
<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?
<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.
<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>(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
<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 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"?
<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.
<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/...partition.img.drive" 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!
<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>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
<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, example.com, i comment the last line and uncomment the previous section; then i use the file via guix deploy
<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: https://paste.debian.net/plainh/ff959cea — 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.
<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>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>(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.
<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
<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.
<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>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
<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)
<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
<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
<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