IRC channel logs
2025-07-16.log
back to list of logs
<apteryx>hm, I'm looking at pharo, and it seems to bootstrap itself using pre-generated C source files, which were generated with pharo. <sneek>Welcome back apteryx, you have 3 messages! <sneek>apteryx, ekaitz says: 21aa23d5 broke sioyek :) <sneek>apteryx, ekaitz says: i updated sioyek, so no need to worry <apteryx>is a source file bootstrap acceptable in Guix? It sure is better than a binary bootstrap, but still isn't the ideal scenario. <sovrcat>working on migrating from broken gentoo install to guix <apteryx>I'm rebooting berlin, as its shepherd had become unresponsive <futurile>nutcase: interesting range of topics at guix social last night, even though there were only 4 of us heh heh <ekaitz>we entered another bot loving period? <nutcase>futurile: yes, indeed. Time passed quickly. <abbe>how to update utmp in guix ? At a glance, I see we have no utempter. <zilti>I'm having a bit of an issue with my Guix install, and I am not quite sure what it is. It boots to loading kernel modules, then starts fsck.fat. It gets to "Writing changes. /dev/sda1: 4 files, 20/63961 clusters" and is stuck there forever. <zilti>I already booted from a USB stick and ran both fsck.fat for the EFI partition as well as xfs_repair for the root partition. The boot loader still gives lots of "not a correct inode" messages though <futurile>zilti: so you booted from a USB stick and you found errors in the underlying filesystems, or there were no errors? <zilti>futurile: there apparently weren't any. at least neither fsck.fat nor xfs_repair told me otherwise <futurile>zilti: mm seems odd that it's not finding it from usb stick and is at boot time <zilti>futurile: I don't think those are the issue, though. I've had those xfs errors in the bootloader for weeks. <zilti>Maybe it's time to copy off my home dir and reinstall <lilyp>apteryx: hey, can you help me getting guile-gnutls to build over at gnome-team? <lilyp>I'm currently bisecting, and it seems the gnutls changes broke it <futurile>zilti: it probably is time to redo things, it's one reason I always keep my home in a separate partition. Nothing on issues.guix.gnu.org showing a similar problem people are having? <zilti>futurile: I haven't seen anything, but really it's a hard-to-search-for issue <Rutherther>luca: no, because git fetcher removes the .git folder for reproducibility <Rutherther>you need to provide the information yourself instead <luca>Ok. In that case I'll just not bother :P Thanks! <futurile>luca: if the package is just for you, you could write some Guile code to pull them out <futurile>luca: assuming you have them - which isn't kept - but if you're building from your own source tree <luca>futurile: nah, I'm trying to do this as right as I can be bothered. And in this case I think it's more correct to not have them at all <luca>I don't really see how commits and dates are not reproducible though. Isn't that a big part of git? <futurile>luca: applications often write timestamps into places, so even if you get the same version of something, a timestamp may have been written. That change will mean guix will consider it nonreproducible - any change in the checksum <futurile>luca: I don't know about git specifically, but that's often why something isn't 'reproducible' as far as Guix is concerned <luca>Sure. I know some build systems take the timestamp from git though. So a given commit will always have the same timestamp <futurile>luca: yes, but here we're talking about the .ssh directory being excluded - so it must write something there that means it's not reproducible <luca>Oh you mean if a build process choses to manipulate the .git directory it is not reproducible. Write operations that is. While read is fine <futurile>end of my knowledge - I should probably see if I can find out why we exclude it in the source <luca>All right, thanks! For the info <apteryx>lilyp: probably the upgrade to gnutls <apteryx>I doubt the other changes could affect its API <lilyp>there's guile-gnutls 4.0.1 and 5.0.0, we might want to update to either <apteryx>someone already posted a patch for that, and I reviewed it but haven't merged yet <apteryx>we could try it, perhaps it resolves the issue already <PotentialUser-25>I'm trying to add some stuff to my bashrc using `home-bash-configuration`, but I'm afraid I can't quite understand the documentation. <ekaitz>PotentialUser-25: what part are you having trouble with? <PotentialUser-25>ekaitz: The real problem is that I'm just not that experienced with Scheme, or programming in general. I would greatly benefit from examples, but unfortunately the Guix manual isn't example-driven. <ekaitz>PotentialUser-25: in the cookbook you have a scheme crash-course <PotentialUser-25>ekaitz: I mean, I'm not a complete beginner, either! I can understand enough Scheme to look at others' code, get how (most) stuff works, and hack away at my system. <identity>PotentialUser-25: is there something specific you would like some help on, or? <PotentialUser-25>What I don't understand is what is a `file-like` object, or what is a `text-config`, or what does the `specifications->package` procedure exactly do, etc. <ekaitz>PotentialUser-25: when it mentions file-like objects says -> see G-expressions <identity>PotentialUser-25: file-like is any object that represents something in the store, or something that is going to be put there. you can get them with ‘local-file’ or ‘file-append’, see G-expressions indeed <ekaitz>PotentialUser-25: the first part of the G-expression section in the docs shows you a couple of examples, but if you think the documentation can be improved, please let us know how and we'll try <identity>PotentialUser-25: ‘specification->package’ does the same thing that the guix cli does with specifications, for example it transforms "package:output" to (list package "output") <ekaitz>futurile-lunch: I don't run wayland. What is for lunch? <PotentialUser-25>ekaitz Some parts have adequate examples, and some seem to lack. For example, I still haven't found a way to use mpv's in-built profiles (without re-defining them) with `make-mpv-configuration`. <luca>Personally this file-like thing I found it easier to learn what returns file-like and use those. In particular for my case plain-file and local-file <futurile>PotentialUser-25: you're other option is to just link in an existing .bashrc and not try configuring it through the services api <futurile>PotentialUser-25: if you don't want to learn all about 'file-like' etc then that's a good option - it's just like any other dotfile manager <apoorv569>When is the neovim package getting the update from rust-team branch? <identity>apoorv569: when the rust-team branch is merged? <ekaitz>identity: any news on that though? <identity>ekaitz: it seems it is 5th in the merge q, so no sooner than core-packages-team merge <janneke>my M-RET (shell-resync-dirs) is broken since a week or so, ring any bells? <janneke>=> Couldn’t cd: (wrong-type-argument stringp nil) <futurile>Q: anyone know what determines whether you have a 'manual merge' button or a 'close' button on Codeberg? <csantosb>janneke: I get `(wrong-type-argument processp nil)` instead <andreas-e>futurile: The manual merge button appears after pushing and reloading the page. <andreas-e>Somehow codeberg then sees that the patch has been merged and makes the suggestion. <csantosb>Could someone check where the `file` command is ? `guix locate file` would make it <identity>‘shell-dirstack-query’ is nil by default, so it ends up invoking (shell-eval-command (concat shell-dirstack-query "\n")), or (shell-eval-command "\n"), which prompts the (wrong-type-argument processp nil) error <csantosb>I don't have it, as I'm using Guix on top of another distro <futurile>andreas-e: oh so because I had the PR's open in different tabs I didn't get it on one that didn't refresh <futurile>andreas-e: OK, so I need to reload them and through the magic of the Web it will figure out to give me the 'manual merge' button <identity>‘file’ is not installed by default, though arguably it should be, or at least substite* a path to it in the emacs package so dired can find it… i really should find time to submit a patch for that <janneke>csantosb: my installation is from july 5 <janneke>IWBN if a new emacs didn't make it into master if such an essential functionality was broken... <csantosb>No idea what `shell-dirstack-query` must be; tryed "pwd", "dirs -l" ... <janneke>yeah, and default-directory is set, weird <avalenn>hello, I have a python venv and install via pip some python dependencies which need shared lib <avalenn>and of course it does not manage to find those libs <futurile>avalenn: have you tried guix shell --emulate-fhs <futurile>then you can export filesystems to the container <futurile>avalenn: if it's not packaged in Guix, then your library is going to look for the 'standard locations', these are the ones in FHS. So that's why you need FHS or you have to start playing with LD_LIBRARY paths <podiki>some good stuff on that site, thanks for sharing! <civodul>futurile: load is extremely high due to ‘btrfs balance’ processes <futurile>no - but it does make it a good time to get out of my chair and go for a walk! <civodul>still, would be nice to avoid those ‘btrfs balance’ processes <luca>What's data.qa.guix.gnu.org? Does it run checks on a given PR that it can build correctly? <civodul>it’s the service that collects info about patches (and now PRs) that need to be built <luca>Well I don't understand it, but it looks really good <pastor>Hello, does Guix have a timeout for substitute servers that are unreacheable? <Kolev>Can I build apps with Guix, then bundle it for use on a non-Guix GNU/Linux system? <ieure>Kolev, Yes, `guix pack' does that. <ieure>Kolev, Or, you can put a whole Guix operating-system into a Docker container or VM image. <Kolev>ieure, what packing format would you recommend? Container? <Kolev>The tarball format seems to be dirty, as it messes with the root filesystem a lot. <Kolev>ieure, I've heard about using Guix inside Distrobox, but it's experimental still. <ieure>Kolev, Depends on the application. If you want to run a daemon-type thing, `guix system image' is the best way to do that. Stuff an end-user will interact with should be created with `guix pack', the specific format depends on who's going to use it. AppImage might be the simplest to use. <ekaitz>Kolev: you can also pack them as a debian package <ekaitz>the weird (but also great) part is that it's going to store the packages in the /gnu/store, isolated from the rest of your system <Kolev>So it will package the latest Guile and everything? That's great. <Kolev>ekaitz, but packaging it as RPM/deb will let it uninstall cleanly? <ekaitz>Kolev: yes, it will install *EVERYTHING* <ekaitz>package is kind of very large though <ekaitz>or better `guix pack --list-formats` <Kolev>I don't care how large it is; I'm transferring it over the LAN from my server to my laptop. <ieure>Kolev, They do, you're probably looking at the 1.4.0 ones instead of the current manual. <Kolev>This is great. Not a Flatpak, but RPM is doable. <Kolev>Well, at least if you're not on Silverblue, which I'm not. <Kolev>Anyway, this is great! I can build on my server (which has disk space for Guix) and then deploy to my laptop (which doesn't.) <ekaitz>or you could just use guix on your laptop and be happy <ekaitz>building the substitutes for everything in your server <Kolev>ekaitz, my laptop is a Chromebook. Audio doesn't work with System. <Kolev>Though recently, I was able to install Fedora on my Chromebook, and audio worked without using a special script. Maybe audio works nowadays? Is there a live system I can use to test the latest Guix? <ieure>Kolev, I don't think there is a current live image. I'm surprised that Fedora works and the sof-firmware didn't solve the issue. <ieure>But, yeah, if your audio hardware needs firmware blobs, that is a hassle. <ekaitz>Kolev: there are channels with proprietary firmware, or you could package yours <ekaitz>i packaged proprietary firmware that manjaro had for a guix system and made it work (not that I'm proud of that, but...) <Kolev>Maybe I could just install Guix on top of Fedora. <Kolev>Not sure how hard that will be on disk space, though. <ekaitz>not much really if you are careful <Kolev>Run `guix gc` every day before running backups? Haha. <ieure>You only need to gc after deleting some generations. <ieure>Guix makes it real easy not to back up the OS stuff. <Kolev>ieure, I only have 25 GB of disk space free on this Chromebook. Is that bad for Guix? <ieure>Kolev, It's on the small side for sure. You'd need to pretty aggressively GC for it to work, if not, you'll run out of disk quickly. <ieure>I'd keep at most two generations at a time. <ekaitz>if you are careful it could be done <ieure>And potentially GC the previous generation as soon as I rebooted into the new one, if things seemed to work. <ieure>Every pull and reconfigure adds stuff to the store, and GC isn't automatic. So if you don't GC, you'll fill the disk quickly. <Kolev>When does /tmp get cleared? Maybe I could have a hook to gc whenever /tmp is cleared. <jlicht>I can't seem to use the --keep-failed option on core-updates-team when building pass-otp (which fails) <jlicht>s/core-updates-team/core-packages-team <ieure>Kolev, Unless you delete generations by hand, gc won't reclaim much space. ex. `guix pull --delete-generations=1..NUMBER-BEFORE-CURRENT', `sudo guix system delete-generaitons 1..NUM-BEFORE-CURRENT`, and `guix home delete-generations 1..NUMBER-BEFORE-CURRENT'. <ieure>And I don't think you want to delete generations automatically. <identity>this conversation kind of prompts the question of netbooting Guix System <Kolev>identity, that sounds intriguing. <ieure>identity, I've wondered about that before myself. Debian has a really great setup for running a lab full of netbooted machines. <Kolev>Although my laptop doesn't always have internet. <ieure>You'd boot off a machine on your LAN. <Kolev>Any specific things I ought to do, to install Guix on top of Fedora? Like turn off SELinux? <csantosb>Kolev: Have a look at etc/guix-gc.service, to keep your store healthy <csantosb>You may fine tune it, see "For instance, to guarantee that at least 5 GB are available on your disk, simply run: guix gc -F 5G" <csantosb>Do you have nscd service in Fedora ? (I don't, in Arch) <Kolev>csantosb, so it's just a simple binary? Cool. <csantosb>Other than this, privilege etc/guix-install.sh over yum install or whatever it is called now <csantosb>ekaitz: Thanks for packaging sioyek, I didn't about that one, and look really useful <Kolev>csantosb, so guix-install.sh + nsncd. Got it. <ekaitz>it was broken for a little, but I managed to fix it <csantosb>You have a typo in propagated-inputs of qt3d, by the way <Kolev>Maybe we could have guix-install.sh auto install nsncd. <Kolev>I don't like how guix-install.sh privileges Debian. <Kolev>luca, well, it expects nscd, which newer distros like Arch and Fedora don't have, and it throws a bunch of SELinux errors unless you turn off SELinux. <ekaitz>it should just not be there, right? <ekaitz>and what is the typo? the fact that the line exists? <ekaitz>doesn't that create an empty list? <ekaitz>which would result in the same thing, but it's not the same thing <ekaitz>in any case, the line can just be removed <ekaitz>the package is not inheriting anything <ekaitz>i started making the package inheriting from other and i forgot to remove that <csantosb>Ok. I learnt something new today, at last ! <xtls>I had a problem with bootstrapping GCC, mes->tcc->gcc <xtls>Could anyone take a look at this? <xtls>+ sh /usr/local/bin/mescc -S -o tccpp.s -I mes/lib -I mes/include -D BOOTSTRAP=1 -I . -D TCC_TARGET_X86_64=1 -D inline= -D 'CONFIG_TCCDIR="/usr/local/lib/tcc"' -D 'CONFIG_TCC_CRTPREFIX="/usr/local/lib:{B}/lib:."' -D 'CONFIG_TCC_ELFINTERP="/mes/loader"' -D 'CONFIG_TCC_LIBPATHS="/usr/local/lib:{B}/lib:."' -D 'CONFIG_TCC_SYSINCLUDEPATHS="mes/include:/usr/local/include:{B}/include"' -D 'TCC_LIBGCC="/usr/local/lib/libc.a"' -D CONFIG_TCCBOOT=1 -D CONFIG_TCC_STATIC=1 -D <xtls>CONFIG_USE_LIBGCC=1 -D TCC_MES_LIBC=1 -D 'TCC_LIBTCC1_MES="libtcc1-mes.a"' tccpp.c <xtls>./tcc.h:519: parse failed at state 356, on input "Elf64_Addr" <ekaitz>csantosb: are you comfortable with scheme? <luca>don't paste everything here <ekaitz>xtls: i think i have seen that before <ekaitz>are you running all this manually? <xtls>no, i am using the 'bootstarp.sh' in tcc <ekaitz>xtls: it's been a while since I don't work on that... but i'm not sure if mes is able to deal with 64 bits properly <ekaitz>xtls: you could take a look to what gnu/packages/commencement.scm does in tcc-boot0 <xtls>so, i run mes on a x86_64 machine <xtls>and i run that on fedora, not guix <ekaitz>take a look to what the guix process does, or read live-bootstrap <ekaitz>and tcc-boot 0.9.26-1149-g46a75d0c <ekaitz>maybe there's a regression in mes <ekaitz>janneke is the Mes maintainer, he might know <xtls>humm, He's nickname is online <csantosb>ekaitz: comfortable is not the right word; let's say that I spend more time on it that what i'm payed for. <ekaitz>csantosb: if you need to learn scheme or so, i can try to help with that <ekaitz>i'm working on a scheme interpreter right now... <ekaitz>xtls: you should be able to find mes 0.25.1 somewhere else to test at least <ekaitz>try with the 0.25.1 and if that continues to have the error... we might need to ask janneke <ekaitz>if it doesn't we should report to janneke too hehe <csantosb>ekaitz: i'm using elisp for scripting in replacement of tcl; guile is next on the lisp. List, sorry. <ekaitz>csantosb: i have taught scheme to several people, if you need to increase the counter, I'd be happy <ekaitz>xtls: the error reporting is weird in mes <ekaitz>you might need to compile the thing for x86_32 <xtls>so i need to create a 32bit vm? or sth else? <ekaitz>you x86_64 computer can run x86_32 code <ekaitz>but I'm not sure about how that is handled by mes, it should do that by default <ekaitz>(i worked in the riscv support, not in x86) <xtls>So, are you saying that the RISC-V machine is working properly? and x86 may not? <ekaitz>no, but in the past mes prioritized the x86_32 support over x86_64 because the second can run the first <ekaitz>and maybe you are trying to build for the second <ekaitz>in risc-v it should work, because we spent a looooong time with it <ekaitz>i don't remember if the x86_64 support was added, honestly <xtls>I should probably ask the author of Mes <ekaitz>xtls: try this: --host=i686-linux-gnu <ekaitz>and follow what the gnu/packages/commencement.scm does -> that works 100% <ekaitz>and yes, in the commencement file it checks if the current-system is x86_64 and if it is it sets the host to i686 <cbaines>civodul, I'd deploy a commit, that's what I do when testing changes <futurile-afk>it's also an answer on how to run a mainline guix repo but with your own alterations (I believe) <ekaitz>this picnoir guy is so crazy... <3 <futurile-afk>heh, well they've sqeezed a lot into a small mastodon post <janneke>ACTION apparently missed something :) <janneke>xtls: mes for x86_64 does not support building a functional tcc, afaik <janneke>the bootstrap for x86_64 uses a 32bit mes and tcc; please note that currently gcc-2.95.3, which is 32bit, is also still part of the bootstrap, so yeah <xtls>So, I have a new problem..umm <janneke>xtls: running bootstrap in 32bit should be fine? <xtls>32bit mes compiled successfully, but it seems that there are still some problems compiling tinycc, is it also an arch problem? <janneke>xtls: hard to tell; currently guix uses nyacc-1.00.2, is that what you using too? <janneke>ISTM that nyacc produces an unexpected/unsupported parse tree that mescc chokes on