IRC channel logs
2024-04-10.log
back to list of logs
<lfam>Nevertheless, it's fixed in the source <lfam>Yes, there is an "up to date" manual and a "stale manual" <vagrantc>for an ostensibly rolling release, hanging onto the last "released" version seems to do a bit more harm than help <lfam>Or we could have a "stable branch" and fix typos <vagrantc>if there was a corresponding stable branch, that might make sense :) <apteryx>ieure: for the record, adding myself to the 'input' group made my controller usable in zsnes (and I suppose other games) <mgd>Hello. I'm really having a hard time deciding on Nix or Guix. Has anyone used both and can describe why they picked one over the other? <attila_lendvai>mgd, i moved over from nix to guix. i was trying to manage a non-trivial, multi-process service and it was a pain in nix. the underlying infrastructure of guix was much more flexible. the nix language was also an unnecessary obstacle for me. <mgd>where you used to lisp code before this? <etienne_r>I have been pondering about nix vs guix as well; I am not sure I understand the fundamental differences. <etienne_r>In my head, nix is more about transactional packaging (and perhaps reproducibility comes as a side product?) <etienne_r>whereas guix cares more about reproducibility? <mgd>I'm trying to learn more but struggling. I've used the graphical install with exwm for now <rekado>both Nix and Guix are implementations of functional package management. <rekado>Nix directly exposes the concept of a function; there really are no packages. <rekado>Guix on the other hand introduces convenient abstractions (such as packages and services) that compile down to derivations. <rekado>the core concepts are the same, but there are differences: the stack on top of these concepts; the interpretation of the implications for packaging; the commitment to bootstrapping, reproducibility, and quality control; the means of abstraction and composition; the community and the values it imprints on the software artefacts. <rekado>irrespective of the differences, Nix and Guix are closer to each other than any other pairing. This also shows in communalities in problems unique to breaking FHS assumptions. <mgd>Does anyone use it for work or as a daily driver? <rekado>I might not be anyone, but I do. <rekado>I use it on all my machines (except my grubby old mobile phone) <rekado>I maintain a large-scale shared installation at the research institute where I work. <mgd>That's interesting. Did you build your machines with Hardware that respects freedom? <rekado>my x86_64 work laptop: no. The aarch64 living room "server" and the i686 netbook: yes. <rekado>(the laptop has coreboot, but comes with a WiFi card that has no free driver) <Altadil>mgd: for what my limited experience is worth, I daily-drive Guix on my home PC as a "not very technical person", and I really like it. :D <mgd>so are you using ethernet with the laptop? I'm looking for a wifi card for an X220 with a free driver <mgd>Altadil Are you learning how to do things from the documentation or anywhere else? And did you set up your PC for hardware that respects freedom? <Altadil>mgd: my main sources are the official documentation and this channel and the mailing list (both have archives you can search). Unfortunately, my hardware is still partly freedom-denying :( <etienne_r>rekado: Is there any documentation you know of, that goes a bit deeper in what you describe? <mgd>Altadil if you don't mind me asking, what did you like about it as a non-technical person? Had you tried any other distros before this? <jakef>Hi rekado, in case Github didn't notify you again, I responded to your comments on the geant4 PR to guix-science <Altadil>mgd: well, to be more precise, I’m still more technical than the average of the general population, but way less than the average here. ^^ I was using Ubuntu and wanted something more advanced, rolling-release and more free. <mgd>etienne_r sorry which question? I directed my last one to Altadil <etienne_r>I don't think I qualify as "a non-technical person", but it is true that I don't do as much techy/coding things as many others here. I am a researcher and focus on reproducibility. <etienne_r>Hehe, two (same) responses for the price of one. <mgd>I think I'm liking this community more at least :) <etienne_r>and same here, I weekly-drive guix OS on home PC, and typically use guix on Debian/Ubuntu vms. I have also managed to convinced our IT people to install guix on our vm system and compute cluster. <rekado>jakef: a saw a bunch of email notifications this time, but I haven't looked yet <rekado>(my laptop needs to be sent in for repairs, so I'm even worse than usual in responding to messages now) <rekado>etienne_r: documentation for what in particular? <etienne_r>rekado: all of these different features that you described earlier: ultimately I am a researcher who is really keen to identify the right tools for the right purpose. <etienne_r>.. and I would really like to be able to understand the differences between the only two platforms that claim a level of reproducibility. <apteryx>podiki: any update on that nss graft? <podiki>apteryx: I thought you said you were going to do it? I can do it later today if not <podiki>seeing a bunch of "could not build missing derivation" for mesa-updates, annoying <podiki>anyone familiar with the openimageio stuff? it can't find the updated openexr (on mesa-updates branch) but not sure what changed in openexr <podiki>ah, openexr depends on libdeflate now, and for some reason when cmake is trying to find openexr it needs libdeflate too not sure why? <podiki>ah, libdeflate in requires.private of openexr .pc, so it should be propagated <rekado>I only noticed this today (perhaps it's been like this for a little while now), but Guix seems a lot slower, e.g. with commands like "guix home reconfigure" or "guix system build" producing no output for a minute before doing anything at all. <rekado>it spends a lot of time reading and stat'ing Guix files <rekado>"time guix home reconfigure --dry-run" tells me that it takes 1m46s/2m51s/0m1.4 real/user/sys time <podiki>just tried mine, said about 7 seconds, but output for checking substitutes was maybe 2 seconds to my eye <rekado>hmm, I think it might be this replacement laptop <trig_function>I want to install eclipse. But I get: ./idea.sh: line 176: /home/.../Downloads/idea-IU-241.14494.240/jbr/bin/java: No such file or directory even though it is there. Is this guix related? <podiki>you just downloaded a binary? then the ld-loader won't know where to look for stuff in guix <rekado>trig_function: this binary java is linked with stuff you don't have on your Guix system. It also embeds the linker/loader location that doesn't exist on Guix <cbaines>has anyone seen Guix tests appear to run more than once in the logs? <podiki>well a tar archive containing a binary :) <trig_function>yeah. Well sorry for my stupid questions. I'm not that experienced when it comes to Linux. Can how would I download those required dependencies? <Kolev>Application Setup on Trisquel wrecks my system. I can't log in to MATE and I can't log in to Profanity. <podiki>trig_function: it is not as simple as just getting dependencies, as that downloaded file still won't know where to look at it <rekado>Kolev: check if XDG_* variables are set; unset them if they are <podiki>trig_function: options: use flatpak (if eclipse is on there), guix shell --container --emulate-fhs (adding dependencies and sharing stuff from host, requires some work), or manually with maybe patchelf <Kolev>rekado: Application Setup said to define XDG vars <podiki>i may just push it in a few days since it should be pretty low impact and is a needed fix <rekado>podiki: it must be this laptop's hardware. iostat tells me throughput hovers at around 2MB/s. Not quite the speed I'd expect from an NVMe SSD :) <Kolev>rekado: trisquel Profanity works but i hope guix haunt will still work works <podiki>rekado: ouch. is the drive nearly full? even a slow nvme should not be the bottleneck i would hope <trig_function>Ok. I don't use guix long yet. That's why I have not configured guix home or anything yet. I don't use containers either. I just install everything with guix install.. Which is kind of pathetic. But yes, I've used flatpak on arch for a few things, so that might be a good option. <Kolev>So *don't* do Application Setup on foreign distro? Maybe add this to docs or remove Application Setup. <rekado>Kolev: no, it's just to try if that fixes your immediate problem. <rekado>podiki: I moved the nvme from my regular laptop to another (because my daily driver needs repairs). Must be something wrong with that replacement laptop. <Kolev>rekado: commenting out the export xdg lines and starting a new shell fixed it <rekado>so the Application Setup section probably should be amended <podiki>rekado: maybe some bios setting in the laptop? for what mode it uses for a drive. but yeah, something fishy <RavenJoad>So I went through and updated kdelib4support to its last tagged release (5.115.0) and all of the other Qt libraries that needed the same update. But, tests are still failing. Does anyone on the Qt/KDE teams know if kdelibs4support is still needed for plasma-service-type? It is blocking a system upgrade for me. <apteryx>RavenJoad: I'd report the failing test upstream, and skip them (via ctest's -E option) with comments including links to upstream reports. <RavenJoad>apteryx: I would, but, kdelibs4support is now deprecated. Its page in the KDE/Qt org is not emptied. <civodul>so, *cough*, what do we do with ‘core-updates’? <civodul>i’m a bit concerned that everyone of many months has ran out of steam <janneke>civodul: it would help if the build farm would build all dependencies needed to build a bare-bones system <janneke>ACTION ran out of steam rebuilding 100s of packages over and over <apteryx>then I guess the comment can be 'XXX: these tests fail for unknown reasons, not worth investigating given this package is deprecated in later version of KDE' <apteryx>should lib/ be in the CMAKE_PREFIX_PATH? <apteryx>some packages put their includes there, e.g.: /gnu/store/6wxhjjgg82ia1krdivzsw45j252m37ny-gtk+-2.24.33/lib/gtk-2.0/include/gdkconfig.h <apteryx>at least FindGTK2.cmake is broken out of the box because of that <civodul>janneke: ok, but maybe we have to stash the pkgconf changes first, IIUC? <civodul>i really have no idea what to do at this point <apteryx>ACTION gives a try to build the desktop image on core-updates to assess the pkgconf damage <civodul>jpoiret seemed to believe the issues were hard to address, but i don’t know the details <apteryx>if it's too annoying to hunt down the .la files to remove, I'll send a patch adding this as a phase to our gnu-build-system <apteryx>it's fun, it's the new pkgconf optimizing away some extraneous entries from the baked RUNPATHs, which get then triggered as missing dependencies because of libtool wanting to link the whole transitive dependencies <apteryx>that's why removing the libtool archives (.la) files, as most distros do, fixes that <apteryx>if we are to believe linuxfromscratch, only imagemagick's .la files are important for runtime (it uses some libtool-provided dlopen scheme) <apteryx>could these be related to our old friend #54447 <janneke>anyway, great news on reproducible source tarball, pelzflorian managed to create a tarball only differing in german month names in doc/stamp-N <janneke>vagrantc: sure, the fix was trivial with this bug report <janneke>before, I only had LC_ALL=C, but apparently people set all kinds of other LANG/LC_ variables :) <janneke>and the good news is that no other tools produced something different with their locale settings <attila_lendvai>something has replaced my /etc/guix/channels.scm with a link to a store item. this is something new, what has changed? <ieure>attila_lendvai, Sure thing, happened to see that skimming the list the other day. <vagrantc>janneke: hopefully nothing reading LANGUAGE :) <janneke>vagrantc: hehe, resetting that too :) <janneke>`we've got a lovely choice of variables for you to reset' <vagrantc>janneke: what's weird is for some of them, it is not clear that C is even valid <vagrantc>i think LANGUAGE doesn't accept C, technically <janneke>very glad pelzflorian tested and found this for us, tho <attila_lendvai>civodul, thanks for the time on my shepherd commits. i'm yet to process it, but meanwhile: should i rebase my commits on top of devel instead of main? <podiki>apteryx: a bunch of "failed to build missing derivation" on last few evaluations of mesa-updates; i've just been restarting jobs as i see them but it is tedious <apteryx>civodul, janneke re core-updates, so far I got a failure in /var/log/guix/drvs/wp/zlk8lsla9vl3lpn9sw0rkkzkmrssq4-librsvg-2.56.4.drv.gz <apteryx>which seems some pkgconf-unrelated rust problem <apteryx>error: failed to get `anyhow` as a dependency of package `librsvg v2.56.4 (/tmp/guix-build-librsvg-2.56.4.drv-0/librsvg-2.56.4)` <podiki>librsvg is due for an update as well <apteryx>civodul janneke I'm building off hydra-guix-129, in case you'd like to reuse its store items <apteryx>I guess the last cargo error is the most accurate; if true, that'd be: EOF while parsing a value at line 1 column 1004 <apteryx>I guess the cargo version is new enough that our librsvg uses obsolete cargo.toml syntax or something <apteryx>does someone know why /etc/udev/rules.d/70-uaccess.rules doesn't work with our elogind package? <apteryx>joysticks are not user-accessible unless we add ourselves to the 'input' group <apteryx>this works for systemd systems such as Debian <podiki>what type of joystick? i'm not in the input group but haven't had issues with gamepads, joysticks, etc. <podiki>i do use a udev rules package, steam-devices-udev-rules which probably includes most any joystick/gamepad/etc. <podiki>it provides a 60-steam-input.rules and 60-steam-vr.rules <podiki>efraim: have you looked at i686 on mesa-updates at all? any idea why coverage is so low? i just fixed openexr at least <apteryx>podiki: it's a very 'standard' logitech dual action gamepad <apteryx>ah, perhaps your udev rules takes care of it <podiki>yeah that package should cover all those sorts of things <apteryx>but that should already be the case for all input devices, according to systemd-shipped udev rules and debian users accounts <apteryx>not sure why it works differently with our elogind package, which ships the same <podiki>so we have the same rules but they don't seem to be applied? <apteryx>I think 'udevadm' could be of help here, but I don't know how to use it on Guix <podiki>so perhaps something up with how we are setting up our defaults? <podiki>i guess you didn't test this before the gnome-team eudev updates? <apteryx>pretty sure it would have been the same <apteryx>there are reports on the net from 2020 from other systems not using systemd, they have to resort to the same solution (add themselves to the 'input' group) <podiki>oh, so maybe more upstream than us <apteryx>not sure why, I thought nix uses systemd <apteryx>it'd be nice if this just worked out of the box, like on mainstream systems <podiki>yeah, some basic functionality like that should work by default i would think; udev is always a bit complicated to me though <apteryx>which user XDG prefix would make sense for read-only game data? <apteryx>reading /etc/udev/rules.d/70-joystick.rules, it depends on the hwdb file <apteryx>perhaps our version is too old... but I doubt it as my gamepad is ancient <podiki>XDG_DATA_DIRS? no idea. games tend to put things in random locations from what i've seen <apteryx>re XDG prefix, I guess that'd be ~/.local/share, aka XDG_DATA_HOME <podiki>yeah, data_dirs for system it seems <zeropoint>Hello guix, does anybody have tips/guides for debugging boot issues? Like booting into a repl shell and running steps one by one or something? or debug flags? My login manager isn't showing up after a recent guix pull. <civodul>i switched to sddm and reconfigured/rebooted just fine a few days ago <gabber>is there a log for when home-services fail to start and nothing gets written into the service's log file? <zeropoint>podiki: gdm (I think, whatever the default for guix is) <zeropoint>I haven't dug too deeply into this, but I can enter passwords to decrypt my drives just fine, but after the last one, the boot sequence just hangs :/ <civodul>gabber: ~/.local/state/log/shepherd.log may have more info <podiki>i also had sddm failing to start, but didn't look into it, and hadn't updated in a while <podiki>civodul: any thoughts on the latest version of https://issues.guix.gnu.org/63393 ? i think the patch i sent (simon's first patch than super simple just add gcc:lib to gcc-toolchain) would be good. and then i can stop answering where is gcc:lib here every few days :) <gabber>how can i set environment variables specifically for a home-service (that i have written myself)? neither (fork+exec-command "SOME_VAR=foo" "command" "arg1") nor (setenv "SOME_VAR" "foo") (fork+exec-command "command" "arg1") do the trick <johnabs>Hi everyone! Has anybody here happened to use cl-indentify for autoformatting common lisp code? I'm having some difficulties with the guix package and was hoping to get some guidance if anyone has some time to help me diagnose the issue. I wanted to look at the source, but it seems the package explorer website isn't working for me for with a [504 <civodul>podiki: i hadn’t noticed but i’ve just replied: LGTM! <podiki>civodul: great, will take care of that, thanks! <johnabs>Also, to clarify my prior question, the CLI formatter seems to be missing from the package, though I could be wrong in this regard. <gabber>johnabs: i don't think you need the "package explorer" website for that. `guix edit PACKAGE-NAME` should open the package definition, from where you can see what source is used. with `guix build --source` guix automatically downloads the source for the build, no need to do anything manually here ;) <johnabs>Oh, I didn't know that was a thing, thanks for the tip! Also, I figured out (at least part of) the problem: no roswell, and it seems that's how the package is "supposed" to be built by the maintainer, so now I've got to figure out how to compile this from SBCL to a CLI app...yay, lol