IRC channel logs
2024-08-21.log
back to list of logs
<abbe__>I'm trying to build a Go 1.21.5 dependent package on arm64 guix, and getting following error about missing ld <abbe__>I'm using go-build-system, and I noticed that go-build-system has native-inputs set to (list binutils-gold) for aarch64 target <abbe__>The error goes away, if I add binutils-gold to native-inputs <abbe__>maybe it rings bell for someone :) <robin>old, searching for "guix" "virtiofsd", i see you also ran into the "Unable to find a satisfying virtiofsd" problem. did you find any fixes or maybe just used another file-sharing method? <robin>ACTION tries 9p (supposedly windows uses this for wsl) <robin>winscp is fine i guess, short of attaching an ntfs disk image <robin>(looking forward to reverse-engineering this scanner's usb protocol when i have time :)) <old>robin: nope .. I used a vm on another distros instead .. <old>wish someone could fix this <old>seems like Nix had some similar problem <AwesomeAdam54321>PuercoPop: Both inline and attachments are fine, what's important is that the patches are in plain text and not hard wrapped <PuercoPop>AwesomeAdam54321: Thanks. The attachment was generated by git so I don't think it gmail will mess with it đ€ <lilyp>hey, does anyone know where the plainurl.bst is in? <lilyp>alright, found it in texlive-urlbst <fnat>Hm, so using guix repl with any additional channels is not exactly straightforward if I understand it correctly? Any other work around, other than what reported here https://issues.guix.gnu.org/61343 ? <worni>What's a good way to set up a rust development environment in guix?? I want to learn rust but I'm pretty lost and can't even get cargo to run a new project set up with `cargo new`. Or should I set up a guix container to run rustup in? <worni>it doesn't work for me, I don't know what to do here, if I install rust, I cant even link rust programs. The linker tries to find a "-lrt" directory? What's going on this is a complete out of the box installation <jakef>i see magit 4.0 still has the transient bug and the transform still fixes it <ngz>jakef: What transform? <lilyp>ngz: using your own emacs to natively compile it, transient, etc. <ngz>So Magit is picking up an outdated transient <jakef>ngz: --with-input=emacs-minimal=emacs <ngz>I usually evaluate manually `transient-prefix-object' definition to work around the issue. Low tech. <lilyp>I have a WIP patchset that makes applying the transformation a little easier â it'd still be nice to solve the shadowing problem tho <lynn_sh>hello. when i use a tool such as fastfetch, it lists packages under guix-system, guix-user, and now guix-home. what is the difference between guix-user and guix-home? I believe I want all my packages under guix-home, as that is my declarative config, right? <lilyp>lynn_sh, unlink ~/.guix-profile and you ought to be good to go; perhaps garbage-collect if you also want the /var symlinks gone <lynn_sh>thanks lilyp, that's what I thought but i didn't want to have to go time-machine just incase i was wrong <lilyp>if you don't want to time-machine, just wait with the gc <lynn_sh>that makes sense. thanks for the quick response, it's a bit of a new experience at every corner with guix. <lilyp>upon initialization, guix home ought to have captured everything from your guix-profile, but do double-check by running guix package -I (capital eye) <ngz>lilyp: What do we know about this shadowing problem? <lilyp>the gist is that we name the natively compiled libraries foo.eln (as opposed to foo.elc and foo.el for the non-native ones) <lilyp>upstream uses hashes in the file name, but that would break grafts, so we can't really do that <ngz>Yes, and each package put them in "$output/lib/emacs-native-lisp/" <lilyp>there are no real other checks (anything based on times is moot on guix anyway) <ngz>Indeed. I read the explanation in the manual. This is needed for grafts. <lilyp>I think perhaps we can record the original file name (i.e. the "/gnu/store/âŠ" path) in the eln files and check it <ngz>Are our .eln files loaded with this change? <ngz>I mean, without the hash in the file name <lilyp>they are loaded â there's a check to ensure that for emacs itself and you can experimentally verify it for other packages <lilyp>(particularly transient đ) <ngz>So they are loaded, and then, they are loaded again in and old version? <ngz>i.e., in the version provided by the Emacs package. <ngz>If I look into `native-comp-eln-load-path', only the last directory, i.e., Emacs package location in the store, contains a "transient.eln" file. Shouldn't I also get one in "~/.guix-profile/lib/emacs/native-site-lisp/"? <lilyp>not quite; the first thing it finds in its load paths gets loaded, with native-comp being preferred over byte-comp <lilyp>you don't get a native-site-lisp, because we use emacs-minimal rather than the actual emacs for compilation currently <ngz>So, if I simplify it a bit, Emacs finds both "transient.elc" from emacs-transient, and "transient.eln" from emacs, and prefers to load the latter. Am I right? <lilyp>i would have to debug the loader to be sure; it might be that it directly goes to transient.eln, but IIRC it first finds the .elc and then "chooses" the .eln because it matches <ngz>lilyp: It seems so according to (info "(elisp) Library Search") <lilyp>ahh, yes, official sources are indeed preferable to folklore <ngz>When building Emacs, could we specifically delete ".eln" files which are bound to introduce such problems. There shouldn't be many of them. It only means these libraries will not benefit from native compilation unless the external package is specifically built with it. <ngz>Or let building a package with emacs-minimal still create a fake ".eln" file. <lilyp>not sure how that fake .eln file would look like <ngz>a symlink to the ".elc" <lilyp>not sure if that'd work â .eln is supposed to contain native code <ngz>Yup, but sometimes Emacs is naive. Let me check. <lilyp>I think unbundling emacs would be the rightâą solution, but I'm unsure if that opinion is shared widely. <ngz>It doesn't work: "/tmp/transient.eln: en-tĂȘte ELF invalide" <ngz>Unbundling Emacs is a solution. What about native-compiling also with emacs-minimal? <lilyp>that won't do; the abi hash is different between configurations <lilyp>though tbf we could native-compile with emacs-minimal if we're going to native-compile on CI anyway <ngz>And using a special emacs (non minimal) flavor for all compilations in the emacs-build-system, not configurable? <peterpolidoro>does anyone know if wxwidgets is being compiled with EGL support? If so, can we add a wxwidgets package variant that is compiled without EGL support? I think it may be causing some issues with a package I am trying to upgrade <lilyp>If I knew how to CI magic, I could probably also do without defining all the non-necessary package variants <ngz>If I use, let's say, emacs-XXX, I need every package to be natively-compiled with emacs-XXX or not native-compiled at all, right? <lilyp>well, you can use emacs-YYY instead, but it will be loaded as though you used emacs-minimal (assuming bytecomp is the same across all emacs-YYY) <lilyp>and if you don't native compile while having a native-comp emacs, you get the transient problem or the graft problem <lilyp>of course, we could disable native-comp during build and let the users JIT, but that may also lead to machine-dependant problems <ngz>IMO, we can solve the transient problem by blacklisting ".eln" files from emacs package, which is an order of magnitude easier than properly unbundling external Elisp packages from it. <ngz>blacklisting = deleting ".eln" files we are providing in a external package. <lilyp>sure, let's do that for the time being <lilyp>you might want to add some lines to the comp-integrity.el aux-file to check that transient, org, etc. are byte-compiled <sneek>I think I remember jab in #guix 7 years ago, saying: is anyone else having the problem with guix deploy silently failing? It will look like it worked, but "guix system describe" is not updated even after a reboot.. <nckx>sneek: You remember both well and poorly, silly bot. Botsnack. <rhuijzer>Does guix have a manpower issue? I like the distro a lot but a lot of packages are outdated, and getting patches reviewd as an outsider takes very long <fnat>rhuijzer: The review process can be a bit slow at times. It might be useful to note that every Guix user, regardless of whether they have commit access, can help with reviews. It's possible to review a patch and leave comments, this typically helps the final reviewer. <Rutherther>fnat i see a calendar there with sessions, but I get 404 when I load register on Meetup. Any ideas? <Rutherther>Oh, thanks, I did not check that as I am on phone and I would have to click on url <fnat>Rutherther: True! Thanks for spotting that. I should be able to fix it. Hang on. <nckx>(And it was by me, and it was because I made a silly mistake when pushing.) <fnat>Rutherther rhuijzer: Link now fixed. :) <nckx>nikolar: Your fix is on the 'core-updates' branch now because it caused too many rebuilds. It will be merged into master in time, but at-spi2-core is deep in the dependency graph for 'master'. <nikolar>nckx: ah yeah figured something like that happened <nckx>nikolar: What I did was not think about checking because I thought at-spi2-thingy was some niche package, not a core desktop component. I should have checked regardless. My bad. <nikolar>yeah and i should've probably mentioned that :/ <Rutherther>Is there an estimate for when will core updates get merged? <civodul>anyone looking into the lib2geom issue on i686-linux? <sneek>AwesomeAdam54321: Greetings! <civodul>#:instal-source? missing an âlâ? <bost>Hi. I have a problem rebooting my machine. `sudo reboot` does nothing. Ugh. Any idea what to do? I run guix on an old desktop, which has been offline for ~1 month. And today after starting it the I had to load BIOS defaults. After that it started well so I tryid to run `guix system reconfigure` which wasn't terminating and now I'm trying to run `sudo reboot` which doesn't "terminate" either. Hmm. <ieure>bost, Resetting BIOS defaults sounds like your CMOS battery is dead. <ieure>bost, I have noticed that `sudo reboot' is pretty unreliable on Guix System, I think it's waiting for processes to terminate, and they don't, so it wedges. Would recommend manually killing as many procs are you can and trying again. <Rutherther>ieure what about halt, does that also wait for processes to terminate? <ieure>Rutherther, Same deal, yeah. <ieure>ex. if I'm logged into an X session in one VT, then switch to a Linux console, log in, and `sudo reboot' -- the system never reboots. But if I log out of the X session first, it works. <Rutherther>That explains why my computer sometimes doesnt want to switch off <bost>`sudo halt` behaves the same - it does nothing. <bost>`sudo herd stop xorg-server` doesn't work either. <bost>Hmm. I'm gonna try to power-off and power-on using a button. <bost>Huh that worked. And it seems like that `guix system reconfigure` actually did it work, i.e. it reconfigured my system, without properly terminating. <civodul>bost: hi! when you say âsudo haltâ does nothing, you mean it hangs? <civodul>what shepherd version are you running? <duncan>What is the expected behaviour of execl? Should the entire script halt/fork if it succeeds? <bost>civodul: yes, it was hanging and not halting my system. <duncan>what *seems* to be happening is it gets the real user's shell by running the target session's arguments, withe execl (since it has /sbin/nologin as shell), but I can't get past the execl bit. <civodul>duncan: âexeclâ returns only if execution fails <civodul>bost: and what shepherd version? :-) <bost>civodul: the machine is already (manually) rebooted. Now `herd --version` shows me 0.10.5. Do you want me to `guix system roll-back` and check the `herd --version`? <civodul>jonsger: maybe thatâs because itâs looking at a subset of the packages? <civodul>itâs computing derivations for packages of the nonguix channel, so it doesnât see the faulty package in the âguixâ channel <bost>Aaaargh the machine is disconnected from the internet. Hmm. <vagrantc>civodul: is the new guile-zlib expected to be largely backwards-compatible? dare i try to build guix 1.4.0 against it? :) <lynn_sh>ran into an issue; i prefer using fish as my default shell. in the guix home documentation, it says if you have a non POSIX shell guix will handle sourcing things properly, but if you are on a foreign distro you have to do it manually. im on guixSD with fish installed via home and it does not seem to be properly sourcing the home setup. is this <duncan>actually, this is further to trying to get tcsh to work at all (there's something funky with gnome-session), which was why i was customising that <duncan>what I came up with was to pipe the commands into `tcsh -l', but that doesn't seem to work (but it neither works with /bin/sh either, so it's not a tcsh thing) <dariqq>hi, i am about to send a patch that would cause lots of rebuilds (reworking cmake cross building). Is there something i should be aware of? <Rutherther>I've noticed home-redshift-shepherd-service does set DISPLAY variable like this https://termbin.com/1tmt. But according to shepherd code the default environment is (environ), which should take the current environment of shepherd. What's the (getenv "DISPLAY") then for? <nckx>dariqq: What do you mean by piping? How will the newly set variables get from {tc,}sh to fish? <nckx>Is the {,tc}sh immediately exec'ing fish? That should work. <dariqq>nckx: i think this is for duncan? <duncan>I don't know anything about fish, the point I want to get to is to have my user shell set as tcsh and for gnome-session to actually launch <duncan>bash (and zsh, i think) accept both a --login and --command (it might be called just -c) argument, whereas a few other shells don't. they accept a single option, and to run a command under a non-interactive mode, one pipes to it <nckx>It was actually for lynn_sh, but I managed to read duncan's message as part of it. Sheesh. <duncan>e.g. `echo "ls -laph" | tcsh -l' is valid, `tcsh -l -c "ls -laph"`' is not <llano>Hmm, what am I doing wrong. I have a .guile file with a few use-modules (ice-9 readline/colorized) but doing: guix repl does not load them? <llano>Mmm, answer is: the .guile file must be in your home directory? That seems strange <llano>I would have though it looks to current working directory <nckx>I think that would be too weird (which programme apart from direnv does this? and direnv is named for the weird if useful thing it does) and executing arbitrary code from PWD could easily lead to security nasties. <nckx>OK, git does this, in a way, and probably plenty of other stuff, but⊠that's still different. <llano>All good points. I'm just starting out on my guix journey, so its more about stumbling through these learning blocks <nckx>No, I get it, I think. But .guile isn't meant as a context-based âprojectâ file, it's just a configuration file, but you could easily add a snippet to your ~/.guile that loads a file from (getcwd) if you want. <nckx>It doesn't get more opt-in than that. <llano>Oo, great idea! And you're right; I was thinking of it more like a project file <Rutherther>I would like to make a shepherd service A, and have multiple other services depend on this one, X, Y, Z... A has auto-start? #f, so I can start it manually. I want X, Y, Z started automatically when A starts. Is this possible with shepherd? When I tried simply putting requirement '(A) for X, X doesn't get started when I start A... <olndrxyz>bost: if it is, it could be ntpd that hangs sheperd when updating the time upon boot. I experienced this issue recently. I replaced the cmos battery and everything is working fine now. <Rutherther>does the auto-start functionality of shepherd services have effect only on shepherd itself starting? <Rutherther>maybe solution to my problem could be by creating a custom herd command for searching all services that have requirement on A,and starting them? Something like "herd start-dependent A"? does that make sense? <civodul>Rutherther: indeed, âherd start Aâ starts A a nothing else currently <civodul>so youâd have to start the others manually <civodul>maybe we should add an option to start the dependents of a service <mirai>Rutherther: you can add a custom shepherd action that can be used to start the others in the meantime?