IRC channel logs

2023-11-14.log

back to list of logs

<lechner>dthompson / i had Guix working on Linode (but then bought a static IP)
<lechner>dthompson / i followed gnucode's instructions (and made some edits that were not accepted) https://guix.gnu.org/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html
<peanuts>"Running Guix on a Linode Server (GNU Guix Cookbook)" https://guix.gnu.org/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html
<lechner>dthompson / https://issues.guix.gnu.org/55105
<peanuts>"[PATCH] Guix on Linode update" https://issues.guix.gnu.org/55105
<gnucode>lechner: seems like a good edit
<lechner>gnucode / dthompson would be a good arbiter
<Kolev>What does `guix system image --volatile` do?
<gnucode>arbiter for what?
<mange>Looks like a "volatile" system is one where a RAM-backed overlayfs is added to the root partition mount, to let you play around without changing the actual image. I'm basing that off the comments in the manual in "(guix) image Reference".
<Kolev>mange, so "volatile" is a normal ISO where your changes aren't saved across boots?
<mange>I think so, yeah.
<lechner>gnucode / whether my suggestions are useful
<crole>Has there ever been a program where code was suggested to a person based on the signature of the function and the documentation strings above it?
<ieure>crole, That's pretty much what happens any time you write code that conforms to an interface.
<gnucode>lechner: I think they are useful. It should be merged. :)
<crole>ieure: That's how I feel, though it's not EXACTLY true. This channel's probably the most divergent one to ask in, because most programmers are still tinkerers who never learn their language.
<crole>The way I learned in How to Design Programs feels so utterly different that it almost makes it obvious how much programming is just work. ;D
<crole>Many other people have mystified and therefore gamified programming: Code to them is a little adventure of hoping and then getting the skinner box to give them something they wanted.
<Kolev>I'm making a more comfortable live image to install from. I'm going to be in it for a while. 🙁
<crole>Kolev: a live image for guix?
<Kolev>crole, yeah, I modded the installer to have GNOME, and WeeChat.
<crole>Kolev: How does it feel?
<zororg>May I know, how to get connected with Arun issac (from genenetwork) ?
<KE0VVT>jpoiret: I think the install issue may indeed be connection. I'm tethering from a mobile.
<futurile>Morning Guixers
<KE0VVT>futurile: Morning!
<KE0VVT>Is it safe to re-do `guix system init` several times?
<civodul>Hello Guix!
<isaneran>yo
<zororg>Hey!
<efraim>o/
<civodul>KE0VVT: it should be, but warranty void :-)
<efraim>is there a way to run ldconfig in a low-memory configuration?
<KE0VVT>Gah! Still get "substitute died" on thsi new connection!
<civodul>KE0VVT: could you paste the last 20 lines or so?
<civodul>efraim: what do you mean? is ldconfig too memory-hungry?
<KE0VVT>civodul: I'm in a TTY on the live installer. Does the live installer have a paste program?
<efraim>civodul: llvm-15 fails on make-dynamic-linker-cache on i686-linux but llvm-for-mesa doesn't
<efraim>llvm-15 and 16 on armhf seems to be just fine, haven't tested powerpc-linux recently
<civodul>efraim: oh wait, i don’t think it’s ldconfig :-)
<civodul>we discussed it before, no?
<efraim>probably, I don't remember it though
<efraim>it's been happening for a while
<civodul> https://issues.guix.gnu.org/59365
<peanuts>"make-dynamic-linker-cache OOMs for LLVM 15 on i686-linux" https://issues.guix.gnu.org/59365
<efraim>I've tried before to delete 'make-dynamic-linker-cache for i686 on llvm-15 but not on llvm-for-mesa and wasn't successful
<efraim>I'll look around some more, see if anyone else has this issue
<sneek>Welcome back janneke :)
<futurile>Q: is there a simple method to list all the source 'methods' that are supported? something like 'guix shell -- repl; import source; list-the-methods' ??
<futurile>I'm currently grepping the source files which doesn't feel very efficient
<civodul>futurile: the valid ‘method’ values for origins, right?
<civodul>there’s https://guix.gnu.org/manual/devel/en/html_node/origin-Reference.html#index-url_002dfetch but that’s about it
<peanuts>"origin Reference (GNU Guix Reference Manual)" https://guix.gnu.org/manual/devel/en/html_node/origin-Reference.html#index-url_002dfetch
<civodul>the “methods” are regular procedures so one cannot distinguish them programmatically
<futurile>civodul: OK, thank-you. Reading!
<gabber>i get errors in phase `strip' because libraries cannot be found in RUNPATH - even though i added them to native-inputs. do they belong somewhere else?
<civodul>gabber: is this in the ‘strip’ phase or in the ‘validate-runpath’ phase?
<gabber>of course it's in the validate-runpath phase (:
<civodul>gabber: ok :-) so you need to make sure these libraries are in ‘inputs’, and then i would check the build log to see how programs are being linked against them
<civodul>normally libraries passed as “-lxyz” are automatically added to the RUNPATH of the resulting binary by the “ld wrapper”
<crole>What is everyone else using for media keys on their keyboards?
<efraim> https://git.sr.ht/~efraim/guix-config/tree/master/item/3900XT.scm#L22-33,118-120 https://git.sr.ht/~efraim/guix-config/tree/master/item/sway-config#L254-255
<peanuts>"~efraim/guix-config: 3900XT.scm - sourcehut git" https://git.sr.ht/~efraim/guix-config/tree/master/item/3900XT.scm#L22-33,118-120
<peanuts>"~efraim/guix-config: sway-config - sourcehut git" https://git.sr.ht/~efraim/guix-config/tree/master/item/sway-config#L254-255
<futurile>Q: I'm trying to build java-bouncycastle - when I try to build it locally it fails because the source hash is wrong (and I can see Greg Hogan sent a patch in July), but I can also see that the CI system is successfully building it (https://data.qa.guix.gnu.org/repository/2/branch/master/latest-processed-revision/package/java-bouncycastle/1.67?locale=en_US.UTF-8). How can the CI system build
<futurile>something, that I can't build locally?
<crole>Thank you, efraim
<cbaines>futurile, are you using substitutes from bordeaux.guix.gnu.org?
<cbaines>that should have substitutes for the built java-bouncycastle as you're seeing, as well as the source
<cbaines>you can always try and directly substitute something by doing: guix build ... e.g. guix build /gnu/store/z7bkxsfn28hcclmpg21x06pxcnsj925g-java-bouncycastle-1.67-checkout
<futurile>cbaines: hmm didn't know you could do that.
<futurile>man this library is messed up - we say it's version 1.69, the docs say it's release v1.77 - but the interface versions are all over the shop - I give up.
<vivien>ACTION f'ed up issues 67162–67170
<dthompson>lechner: your diff for the guix on linode cookbook page look good to me. I had to make that same swap-space update.
<dthompson>it's just a bummer that there's seemingly no way to avoid starting with some other OS. I'd really like to be able to generate the initial image on my own computer and start with Guix right away.
<gabber>i think i stumbled over some swap-space operating-system field issue as well - might be worth investigating a bit further (i think it was in the raspberry-pi example)
<civodul>dthompson: where does Linode take its initial image? would the Guix System image need to be in a specific registry?
<efraim>civodul: I've narrowed down the heap OOM to the library-path definition in 'make-dynamic-linker-cache
<civodul>efraim: yes, that’s the thing that loads ELF file one by one in memory
<djon>@search elixir
<dthompson>civodul: you can upload your own image. they say it needs to be a gzipped raw disk image. the problem I'm having is that it doesn't recognize the root partition as being ext4.
<dthompson>but I read the guix source for this and it is indeed creating an ext4 partition in the image
<dthompson>I'm trying to find a tool that will explain a .img file to me so I can check some stuff
<gabber>dthompson: you can use $(fdisk /path/to/image) for that
<dthompson>gabber: ah this is very helpful, thanks!
<civodul>weird!
<gabber>HTH! i think [g]parted works as well -- this has a little more information IIRC
<dthompson>gparted is more helpful! I didn't realize you could just open a disk image file with these tools
<dthompson>gparted shows that the partition is ext4
<gabber>UNIX is weird ;)
<aldum>here's the magic trick: when you open a 'normal' disk with it, that's also a (special) file
<dthompson>I don't understand what's going on... I know that I'm now on their happy path of using packer of qemu-img directly
<dthompson>aldum: yeah I know that I just didn't realize they were the same things
<dthompson>but I guess that what it means to be a "raw" disk image
<dthompson>gparted is tellling me this though: "e2label: No such file or directory while trying to open /tmp/guix.img1 Couldn't find valid filesystem superblock."
<gabber>that's suspicious!
<gabber>can you mount the partition(s)?
<dthompson>I'll try to do that...
<gabber>what's wrong with these lines? where do i have to quasi-quote/unquote gexp/ungexp? https://termbin.com/pwunt
<voroskoi>vivien: https://debbugs.gnu.org/server-control.html
<peanuts>"GNU bug system - control mail server commands" https://debbugs.gnu.org/server-control.html
<dthompson>yeah mounting fails...
<dthompson>mount: /tmp/mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
<aldum>is loop0 correct though? shouldn't there be a partition?
<dthompson>I have no idea why it's saying that
<jpoiret>gabber: what's the error?
<jpoiret>btw we have the target-...? helpers in (guix utils)
<aldum>dthompson: let's take it from the top, what did fdisk -l say?
<dthompson>fdisk output looks good. shows a bootable linux partition
<aldum>so there is a partition
<aldum>then set up the loop device first, and try to mount the partition, not the whole disk
<cnx>what is a workflow for writing a service? i mean how does one test it
<dthompson>aldum: when I mount the disk image I do indeed see ext4 file systems as I expect
<dthompson>not sure what the heck is up with what linode is doing
<aldum>do they expect a whole disk?
<dthompson>the docs are not particularly clear about all the requirements
<aldum>>Raw disks or disks that have been formatted using other file systems are not supported.
<aldum>so no, it should be the single ext4 partition
<dthompson>haven't seen that anywhere
<aldum> https://www.linode.com/docs/products/tools/images/#technical-specifications
<peanuts>"Custom Images Product Documentation |
<dthompson>requirements are listed here https://www.linode.com/docs/products/tools/images/guides/upload-an-image/
<aldum>first bullet point links to the other one
<dthompson>hmm well I guess I could try mounting the output of 'guix system image' and then use dd to make an image of just the root partition
<aldum>or you can just dd your loop0p1
<dthompson>like to image my own system?
<dthompson>I don't want to image the running system, but rather a much more minimal system.
<aldum>I thought you had the image already, it just didn't work on linode
<dthompson>I've been making images with 'guix system image'
<efraim>probably want disk-image
<dthompson>aha I think this may have worked... still waiting for the rebuild but I see an ext4 partition in the linode console now
<dthompson>efraim: isn't that what 'guix system image' does? it lets you choose from a variety of image types.
<dthompson>back in the day there used to be separate vm-image and disk-image subcommands
<efraim>I guess that explains why I can't find the disk-image option anymore
<efraim>e74baa124592428f05b17562f180469e405037f3 it's been almost 3 years
<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e74baa124592428f05b17562f180469e405037f3
<efraim>peanuts: wow, I didn't think that would work
<peanuts>efraim: Hi, for comments please contact my maintainers at https://codeberg.org/lechner/irc-helper-bot
<dthompson>this isn't great but a step in the right direction! 'Kernel panic - not syncing: No working init found'
<dthompson>used to be a panic for not finding the root fs
<dthompson>even closer now... had to change linode config to boot with grub 2.
<dthompson>now it's complaining that /boot/grub/fonts/unicode.pf2 isn't found... indeed it isn't in the image.
<dthompson>the existing guix on linode instructions say to override the installer field of the bootloader to not actually install grub on disk, but I think I need it to get the files that its complaining about.
<dthompson>okay I have a working linode!
<dthompson>I'm trying to think of how to generalize what I did so that it can be a new image format for 'guix system image'
<dthompson>thanks for the help aldum
<dthompson>this new image type would produce an image of just the root file system, it wouldn't be an entire disk with partitions.
<dthompson>maybe "root-fs-raw" would be a decent name... open to suggestions :)
<pkill9>is there a way to rebuild the guix database?
<pkill9>i'm getting guix gc: error: executing SQLite query: database disk image is malformed on guix pull, and also when running guix gc --verify=repair
<dthompson>pkill9: uh oh... I hope someone here knows how to repair it because I have never messed with the database
<pkill9>i've had various issues with the databse every now and then, i wish there was a way to just rebuild it fresh (the nuclear option)
<pkill9>only option currenlty seems to be to reinstall guix
<podiki>hi guixers
<podiki>if anyone has essential packages or ones they like to check on big merges, please do check if they have built for mesa-updates
<jackhill>dthompson: that's exciting! I'll have to take a look at what you came up with!
<Kolev>civodul, here is the error message -
<Kolev> https://share.csh.snikket.chat/upload/sNGYRkEkqG4r9ZCCg32xnWnb/Guix_install_error_2023-11-14_0910.jpg
<civodul>why me? :-)
<civodul>Kolev: that’s the 1.4.0 installation image?
<Kolev>civodul, you asked for the full "20 lines" earlier.
<Kolev>civodul, yes, it's 1.4.0... 🙁
<Kolev>I'll try again with latest, but I don't think it will solve anything.
<dthompson>jackhill: I will try to write a quick blog post about it and share it here. I'd like to figure out how we can integrate a "just works" solution into 'guix system image' after.
<civodul>Kolev: bummer; we do have a bug report for this, but it seemed rare and hard to reproduce: https://issues.guix.gnu.org/56320
<peanuts>""write_wait_fd: unimplemented" error from 'guix substitute'" https://issues.guix.gnu.org/56320
<Kolev>civodul, I'm running this on a ThinkCentre.
<Kolev>I'll try again on latest.
<Kolev>Shouldn't the Guix website just recommend the ISO latest?
<gabber>jpoiret: thanks for that hint!
<civodul>hey samplet :-)
<podiki>what do we want to see from substitute coverage before merging a branch?
<podiki>I think mesa-updates is pretty much built for x86(_64), a bit on other arch but I know they can really lag behind
<Kolev>ACTION downloads ISO latest.
<podiki>unfortunately qa page not populated since I just merged in master; but was around 95% x86_64, 88% i686, and then next best was maybe aarch or arm at ~50% on bordeaux?
<gabber>how can i satisfy a dependency on libusb-0.1.so.4, libstdc++.so.6, libgcc_s.so.1 or ld-linux-x86-64.so.2? i've tried adding glibc, libusb-compat, gcc, libusb-0.1 to the inputs but that does not satisfy any of them...
<podiki>gabber: satisfy for what? in a package build?
<gabber>yes
<podiki>what is the error you are getting?
<jackhill>podiki: is https://issues.guix.gnu.org/64981 something that can be fixed in mesa-updates?
<peanuts>"GTK4 applications broken (missing libGLESv2)" https://issues.guix.gnu.org/64981
<podiki>jackhill: it should be done already! which reminds me I forgot to ping all the issues where I included patches in mesa-updates, I should do that
<gabber>this is the build log: https://termbin.com/ks7m
<podiki>jackhill: https://issues.guix.gnu.org/65375 was included in that branch
<peanuts>"[PATCH] gnu: libepoxy: Hardcode paths to GLES libraries." https://issues.guix.gnu.org/65375
<podiki>gabber: and the package definition? is this being built or just copy-build-system?
<jackhill>podiki: wooo! thanks! yeah, keeping the tickets updated is like weeding a garden.
<gabber>podiki: it's just copy-build-system
<podiki>jackhill: I had them all open, in a list, applied all the patches....and then just didn't send the emails
<podiki>gabber: yeah, so essentially a binary/pre-built then. You'll need to patch the runpath (patchelf for instance) or there is a build system for that in another channel
<gabber>ahh, i se
<gabber>*see
<gabber>i thought that was what the strip phase did (it seems i erred)
<gabber>thanks for the clarification!
<podiki>you can also maybe wrap with LD_LIBRARY_PATH or something, but I think that validate phase will fail (so you can remove it)
<podiki>or rather, delete the phase so it "builds" and see if it runs. likely it will need LD_LIBRARY_PATH wrapping to find libraries to work
<podiki>and/or use guix shell --emulate-fhs
<Kolev>Is there an option in (operating-system) to customize the MOTD?
<podiki>issue? https://guix.gnu.org/en/manual/devel/en/html_node/operating_002dsystem-Reference.html
<peanuts>"operating-system Reference (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/devel/en/html_node/operating_002dsystem-Reference.html
<podiki>meaning the "issue" field
<samplet>Hi civodul!
<sneek>samplet, you have 1 message!
<sneek>samplet, janneke says: have you seen this very new make in guile? -- https://codeberg.org/lechner/bespoke
<peanuts>"lechner/bespoke: A Make tool in GNU Guile - bespoke - Codeberg.org" https://codeberg.org/lechner/bespoke
<dthompson>hey also samplet
<Kolev>Hm, looks like (operating-system) does not have a (motd).
<Kolev>podiki, MOTD and issue are slightly different.
<podiki>ah
<podiki>I supposed you can use the various simple file services to make the file (I assume it is a file somewhere)
<gabber>(gnu system) on line 944 there's this string that gets displayed when you log in "This is the GNU system. Welcome." which is displayed where i'd expect the MOTD?
<samplet>janneke: I had not seen Bespoke. It looks cool. I’m familiar with the linked Zuo, which I believe has some lessons for us Schemers doing bootstrapping.
<janneke>samplet: i figured you might like it. i've taken a stab at make in guile a looong while ago and it didn't amount to much, then there's potato make by spike121, but bespoke looks promising
<janneke>prolly way to much on our plates, but it's always nice to see inspiring things ;)
<janneke>(sneek's message must have been quite old tho, ;)
<samplet>My IRC usage is pretty intermittent. I’m always happy when I do connect, but I often simply forget!
<janneke>haha, np
<janneke>just reset mes wip, thanks!
<samplet>Oh good. I’m digging into that system call now.
<samplet>By the way, I got the basics of ‘syntax-case’ going. There’s a lot of work to do getting it working with both the evaluator code and modules, though.
<janneke>Oh my!
<janneke>Let's finish and release wip[-gash-utils] as mes-0.26 though and see about improvements later?
<janneke>i've got some experiments resurrecting building mes on the hurd and initial modularizing and updating to latest nyacc slated for 0.27 in progress, looking pretty good as well, but for 0.27 too afaic
<samplet>Agreed. I just wanted to share. :)
<janneke>yeah, it's really great news. makes me remember to share this with you too:
<janneke>scheme compiler https://github.com/uhollerbach/wile
<peanuts>"GitHub - uhollerbach/wile: A small simple scheme compiler" https://github.com/uhollerbach/wile
<Kolev>Franciman, using latest ISO. See if that helps my issue.
<Franciman>good luck Kolev-sama
<Franciman>you are my teacher, you won't fail
<Kolev>Franciman, did you check out my Guix config? https://codeberg.org/csh/dotfiles
<peanuts>"csh/dotfiles: My public configuration files. - dotfiles - Codeberg.org" https://codeberg.org/csh/dotfiles
<Franciman>yes
<Kolev>Installing with ISO latest.
<gabber>how can i refer to the package that produces the /gnu/store/<hash>-gcc-11.3.0-lib store item?
<podiki>in a package, `(,gcc "lib")
<podiki>from a guix shell -e '(list (@@ (gnu packages commencement) gcc) "lib")'
<gabber>thanks!
<podiki>welcome
<mirai>what do I need in order for gpg to pickup 'pinentry'? I'm getting “Error changing the PIN: No pinentry”
<apteryx>it needs to be installed to your user profile
<apteryx>else configured in the gpg config file
<podiki>apteryx: hi! any thoughts on when I should merge in mesa-updates? substitute coverage looks good on x86_64 and i686, our other architectures lagging though (next highest was around 55% I forget which since QA page hasn't caught up)
<podiki>some leaf packages will need to be fixed though I tried to get to what I saw
<podiki>I'm aware php fails some tests, I can mention that in an email to guix-devel updating on the branch status
<Andronikos>nckx: You mean with ddrescue not doing it, that it is not the software itself but the hardware. Does that mean the HDD itself or which hardware and what exactly does the kernel do? I always used "dd" and in this case as well. Though I ask just to be sure it is still the best way to do it.
<Andronikos>nckx: https://logs.guix.gnu.org/guix/2023-11-13.log#191418 context
<peanuts>"IRC channel logs" https://logs.guix.gnu.org/guix/2023-11-13.log#191418
<Andronikos>futurile: Clonezilla was my first thought as well but it is cumbersome booting a whole distribution. Also I needed a clone as a file that is on a physical drive (e.g. backup.img), since I needed some files to copy over to the original HDD. I don't know if Clonezilla can do that. I only used it for mirroring whole drives which worked flawlessly.
<Andronikos>I guess it is not possible to calculate with gzip what the new compressed file size would be? I don't have much storage left and don't know if I have enough free space to store the backup as well as the compressed backup at the same time.
<gabber>Andronikos: i doubt that's a linear calculation... most modern compression algos do kinda smart stuff at times - and depending on the content of your files compressed size can vary much
<vivien>lilyp, apteryx, did you get a notification for #67162–67170?
<peanuts>"[PATCH] gnu: epiphany: Update to 44.7." https://issues.guix.gnu.org/67162
<lilyp>I got 66814
<vivien>I initially sent these to guix-patches without adding the gnome team in CC, and I sent a v2 with the Debbugs-CC but I don’t know if it worked
<lilyp>got them now, debbugs CCs sadly land in spam too ofte
<lilyp>will look at them tomorrow
<vivien>There’s no rush, I’m iterating down the 44.6 GNOME release (https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions), I am currently at gnome-boxes
<vivien>Every time I have a few webkits to rebuild (or just an inkscape and a few gtks, if I’m lucky), so I’m progressing slowly :)
<apteryx>vivien: as long as you use 'git send-email', the CCs are automated so you don't need to worry about them, unless someone not in GNOME team joins the conversation
<apteryx>you can also use 'mumi send-email *.patch', which also includes participants in CC
<vivien>I use magit to do the format-patch
<apteryx>that doesn't matter; the CC'ing automation is done at sending time (git send-email)
<vivien>Too bad I don’t use git send-email
<apteryx>I see :-) otherwise 'mumi send-email' is a simpler wrapper above git send-email. You'll still need to have an SMTP server configured in your ~/.gitconfig though
<vivien>Last time I sent a WIP patch without checking it first, so I’ll just accept that I have many things to think about
<vivien>(it did not build)
<vivien>Between build, reproducible build, lint, style, checking the patches, trying to detect unwanted dependencies, formatting the commit messages, there are already a lot of things I often forget
<vivien>I’m also bad at a lot of these points
<vivien>Then I have to reorder the commits to send them, not forget the prefix (PATCH gnome-team), check which revision I have to use, add the gnome-team CC (but magit remembers it so I don’t have to type them), check the issue number, make a cover letter, and send the patches
<vivien>Sure some of these could be automated
<apteryx>for the long haul you may be interested in learning some patman tags you can put in your top series commit, to remember things like the associated issue number
<apteryx>it's another tool that automates git send-email
<apteryx>with some sugar like embedding metadata as git trailers (e.g. Series-to: NNNNN@debbugs.gnu.org)
<apteryx>info '(u-boot) Patman patch manager'
<ulfvonbelow>trying to update numpy locally and it seems that having both gfortran and the implicit gcc input is causing issues with include files, specifically fenv.h
<ulfvonbelow>the include_next sees the gfortran header, which is an exact copy of the gcc header, which makes it think it's already been included, so it stops. Consequently, the glibc fenv.h never gets included.
<ulfvonbelow>what's the proper way to handle that?
<ulfvonbelow>does it even make sense for gfortran to include C headers?
<vivien>Oh also I forgot to mention, check the .pc files for propagated-inputs
<vivien>That could be a "guix lint" item