IRC channel logs
2023-10-13.log
back to list of logs
<TehBoss>how would i setup a service to run `emacs --fg-daemon` on login? <ryblade>TehBoss: maybe put it in your .bashrc? <TehBoss>ryblade: that doesn't really work for me since it takes a while for emacs to execute my whole config <TehBoss>if thats not when the user logs in, would i be able to add a shepherd command to my .bashrc to add a login target <lilyp>TehBoss: If you autostart shepherd on login (e.g. via bash_profile or other autostart features) then you can have emacs as a user shepherd service <TehBoss>also i dont wanna start shepherd every time i open a shell <podiki>TehBoss: there's shepherd as system services and shepherd for user; for a user it doesn't start automatically unless e.g. as mentioned added to start on login for instance <TehBoss>i don't want to start shepherd every time i start a shell <podiki>TehBoss: well you'd put it in the right file that is only for a login? or autostart when you start your wm/de? there's lots of options, just like starting anything else <TehBoss>podiki: does shepherd not just autostart the user services like systemd does <podiki>TehBoss: xinitrc or xprofile, your shell profile file, wm/de autostart, etc. <podiki>there is shepherd that is run as root (system services) and if a user wants services they run shepherd as user <TehBoss>shell profile should get executed whenever a new shell is started thought right? <podiki>profile is for login shell if I remember <podiki>anyway, shepherd run as user is the same as starting anything else, so you can put it in lots of places <podiki>there's a difference between login and interactive (and non-interactive non-login) shells; check what you use for the right files and what goes where, i usually look it up if i haven't been tweaking them recently <podiki>so, shepherd as pid 1 is always run (it is the system), after that it is up to the user <podiki>("what you use" meaning e.g. bash, zsh, etc.) <TehBoss>i suppose i could move the things from .profile to .bashrc <podiki>i don't remember the details, best to look up what goes in which file as it is an easy thing to confuse and mangle your shell environment a bit <jpoiret>TehBoss: your bashrc is not supposed to call .profile <jpoiret>as you highlighted one is sourced on login, the other on each new interactive shell <jbnote>hi, is the contents of /gnu/store/.links hardlinked? Can I safely trash the directory after adding --disable-dedup as a flag? <jpoiret>jbnote: general note, you should never touch /gnu/store yourself, all warranties void if you do <jbnote>jpoiret: I understand this, and that my warranty is void even if I follow advice from here :) <jbnote>jpoiret: I'm trying to switch from the store's dedup system to btrfs + duperemove. There's a flag in guix-daemon to avoid doing dedup explicitly. <graywolf>Can I write a service that install a package? So for example I make a service foo-service-type, and it will both do some configuration AND install the package foo so that it is in the $PATH? <cbaines>install a package in what profile graywolf? <graywolf>The system one? Basically I want to have a service that does the equivalent of (operating-system ... (packages foo ...) ...) <graywolf>(Sorry I am unsure what that profile is actually called) <snape>can you describe your use-case more precisely? <snape>why do you want the package to be installed? <snape>you want to be able to call the executable from a shell? <graywolf>I want to make an emacs-service-type, that would configure emacs as I like it, but that will not be that useful if emacs is not in the $PATH. I *can* add it separately, but I would like to be able to do reduce the chance to forget that when I am making a config for a new machine. <graywolf>Emacs is not the only example, basically I would like to be able to make a "feature" service that adds some capability into a system, in this case configured editor launchable from shell. <graywolf>But I need this for both home and system parts, so I wanted to start with the system <graywolf>But if it is doable only in home, better than nothing :) <cbaines>graywolf, you can add packages to the system profile in a service by extending the profile-service-type <graywolf>cbaines: Ah, great, thank you very much, will look into it. <civodul>apteryx: hey! i noticed that on berlin we run ‘guix gc’ (without ‘-F’) everyday <civodul>i remember there were discussions, but i forgot: what was the reasoning for not having a threshold? <rekado>I think it’s because everything we need is in substitutes. <rekado>there’s no point in keeping a copy in /gnu/store when we want to hold on to substitutes in the cache for as long as possible <rekado>ci.guix.gnu.org fetches substitutes from itself, so we refill /gnu/store with what’s needed on demand. <weidtn>Hello, is there any reason distrobox is not 1.5 already? I was not able to find anything in the irc chat logs or git regarding this. Is changing the version number enough? <snape>weidtn, no particular reason, usually changing version and hash is enough <weidtn>can somebody else do this? I have no access to guix right now but want to install it as soon as distrobox is available in 1.5 <snape>why don't you try to do update it? it's not that difficult <weidtn>I just told you. I have no guix right now. So I would need to install it to a vm just to do this. Maybe somebody else already uses distrobox and its easier for them? <snape>if you don't have guix you can't really use it either... <snape>there is something I don't get ^^ <Altadil>weidtn: I’m not an expert, but I think you can make changes to guix from another distro. You can work directly from your copy of the git repo. <weidtn>I want to install guix on my computer. But I need distrobox 1.5 So I can use the --nvidia flag. If this does not work, there is no point in installing guix right now. I don't know how to do it and it seems like a lot of work for something that might not work in the end. But it's probably 5 minutes for somebody who is already used to doing this. <Altadil>weidtn: I don’t know distrobox, but I understand right, you are trying to install guix inside distrobox ? <weidtn>other way around. I want a stable reproducible system that is guix. And then run distrobox for stuff that is not available/working in guix. Things like cuda and games that need the 1.5 version of distrobox so i can pass my nvidia gpu to it. <Altadil>oh, I see. Then my guess (again, I’m a noob here ^.^) is that the shortest path is to still install guix first, and then install distrobox using an option to manually change the version. See part 10.1.2 Package Transformation Options of the Guix manual. <snape>this person didn't even say "please" <graywolf>Hm, guix deploy does not have --allow-downgrades. Any ideas? <civodul>graywolf: hi! you can specify it via the ‘allow-downgrades?’ field of ‘machine-ssh-configuration’ <civodul>unbelievable: only 8 jobs queued on ci.guix.gnu.org \o/ <weidtn>Okay I have a guix vm now. Is there any guide how to bump the version of a package? <rekado>civodul: so your most recent fix finally fixed the build farm? <rekado>it’s so good to no longer see the build farm idle when it’s not supposed to be idle <rekado>re aarch64: maybe we should buy a few more nodes <weidtn>okay so I found guix refresh distrobox --update. But it does not work for a system package I guess? sudo -i does not work <Altadil>weidtn: oh, sorry, I could I forget to mention guix refresh ! You want to use it on a git checkout : see parts 22.1 Building from Git and 22.2 Running Guix Before It Is Installed of the manual <graywolf>civodul: ah, that is great, thank you :) <snape>weidtn: i suspect it will be more complicated than just changing version + hash <civodul>rekado: yes, looks like it fixed at least the scheduling issue where workers would eventually become idle even though there’s work to be done <civodul>the “missing .drv” issue still needs more work though, it seems <civodul>also, re missing guix-binary.tar.xz, one problem is that mcron job that removes it periodically… <weidtn>snape: I am still stuck cloning guix, just to try to do this version bump. Why do you think this will not work? <civodul>efraim: dear Rust team :-), the ‘rust-team’ jobset on ci.guix is done! <snape>because i tried and there is some error with newuidmap being not found <snape>plus the search and replace regexp that doesn't work anymore (but this is easiliy fixed) <weidtn>Okay, so I guess I just wasted 2 hours. I don't know how to fix any of that. Seems like I have to wait to install guix on my main machine until somebody who knows what he is doing is fixing that. <jaeme>Oh god, rust 1.73 already got released <jaeme>These crab people are too fast <jaeme>I wonder if they made compilation any faster? :p <rekado>weidtn: if the package definition for distrobox had been written a little more carefully you would have been able to do “guix build distrobox --with-commit=distrobox=1.5.0.2” <rekado>but since there’s a pdf file now that the build phase will try to patch this won’t work <snape>(delete-file-recursively "docs") does the job I guess <civodul>or “guix build --with-latest=distrobox distrobox” <weidtn>snape: I suspect this will not work with what civodul just wrote? I have to modify the package definition, i guess? <rekado>weidtn: or you could run “guix pull”, which gets you commit dcfd4d9c4827ca6bfebeec46fe6bb8373c425a1c <RavenJoad>Is it expected that LaTeX compile times increase when using a texlive-scheme? Compile times for a simple exam documentclass have noticably increased after switching from texlive to texlive-scheme-full. <avalos>Help, I can't reconfigure my home! It says it can't build the directory of Info manuals. <avalos>I did the reconfigure after running `guix pull` a few minutes ago. <rrobin>avalos: whats in the log /var/log/guix/drvs/7z/nhbgx9by804g0kjwh8zpvy79bwa52h-info-dir.drv.gz <rrobin>if this becomes a problem, you can always rollback that pull <dthompson>trying to compile guix locally for the first time in awhile and I'm getting errors like "guix-cookbook.ko.texi:572: @menu reference to nonexistent node `A ``Hello World'' package'" <podiki>I see things around the docs at times, sometimes need to clear out those files/reset them and the bootstrap, make clean-go though i'm not sure it helps here <dthompson>I re-bootstrapped. I ran 'make clean'. I just did a 'guix pull' and re-did the first two steps just in case. <rekado>dthompson: recently there was a need to upgrade po4e or related tools. You’d need a new “guix shell -D guix” with a Guix that has the up-to-date definition of the “guix” package. <dthompson>I ran 'guix pull' and then did 'guix shell -D guix' and ran into the same issue <cbaines>dthompson, you might need to ./bootstrap; ./configure; make <dthompson>I have a fully up-to-date guix via guix pull and 'guix search guix' returns version 1.4.0-13.e863274qw which is from the 5th so I should have sufficiently fresh stuff <avalos>rrobin: In execvp of /gnu/store/5mvsq0p6pwfl9lvaixmc0yb58fz2cv35-texinfo-6.8/bin/install-info: Exec format error <avalos>That's the only line of that log file. <podiki>i'm always guessing with the texi file errors that pop up, i think deleting all the generated files and redoing bootrstrap (which creates placeholders) does it <podiki>although I would hope a make clean gets rid of them, i don't think it did last I tried that <dthompson>yeah it seems make clean is not cleaning up properly <dthompson>gonna start deleting stuff and see what happens... <podiki>i think I've just deleted the whole doc directory and then restored via git to get to a clean state <dthompson>I deleted the entire doc/ directly, restored the files that are checked into git, re-bootstrapped, re-configured, and now make is proceeding further than it has <podiki>this is my usual procedure of more and more drastic steps <podiki>so that means we need a make target that resets the doc <podiki>(or part of make clean, or make clean-doc to be less invasive) <dthompson>well at least I'm building again. thanks for the help podiki <dthompson>I am going to update guile-next to reflect the latest commit in guile's main branch <podiki>happy to have thrown my usual haphazard steps for consumption <dthompson>I was told awhile ago that such updates could be done freely as its a leaf package <jbnote>Hello, i've got a newbie question about system declarations. I'm trying to write a fcgiwrap block in an nginx configuration and I need the full store path to a binary in order to assemble the nginx configuration string. I know how to translate a package name to a string in a gexp context ($#). Can you do the same (package to store path) outside of a gexp in a system declaration? If so, how? <podiki>dthompson: I don't know about that specific case, but I would say yes, generally the -next packages are for that reason (no dependents) <podiki>jbnote: you should be able to use gexps in your system config as well, it is built as a derivation like anything else <dthompson>well guile-next isn't exactly a leaf package but it only has a few dependents <jbnote>podiki: You mean a gexp can be a value, it is not necessarily a function? Ok, i'll try. <dthompson>guile-hoot 0.1.0 is in the oven and having an up-to-date guile-next is a pre-req for packaging it. <dthompson>so I'll update guile-next and make sure its few dependent packages build for me. <podiki>jbnote: i'm not sure what you mean exactly, but yes try :) the idea of using a gexp to get a store path to use in e.g. string-append in a configuration all sounds good to me <podiki>gexp and ungexp are like quote and unquote <podiki>ACTION has to run, happy gexp-ing all! <civodul>(BTW couldn’t stay till the end of the stream but i enjoyed what i heard!) <dthompson>civodul: oh I'm glad you were able to tune in for a bit! stream had a rough start and died a few minutes in, but despite the issues it was a good time. <rrobin>avalos: sounds like that binary is broken somehow, i assume the same thing happens if you try to run it. what do you see if you call: file /gnu/store/5mvsq0p6pwfl9lvaixmc0yb58fz2cv35-texinfo-6.8/bin/install-info ; or run it directly <civodul>dthompson: yeah, i found the new link and was able to follow once it had restarted, it was nice! <civodul>i wonder why it never occurred to me before <dthompson>all this time and I hadn't seen programmatic usage of package transformations <civodul>there’s nothing clever here but it could get us pre-testing of package upgrades <ulfvonbelow>anyone else find that icu4c@73.1 fails to build due to a failing TestHebrewCalendarInTemporalLeapYear test? <jbnote>Hi, I need help understanding the magic behind (file-append ...). If I use it in some context, for instance to initialize a structure field, it works. If substitute for it a (format ...) call with the same (file-append ...) call as an argument, it prints the procedure. If I use (string-append ... ) with the same (file-append ...) as an argument, it tells me that I have the wrong type. What happens? Is there a way to coerce the output <jbnote>(file-append ...) to a proper string? <ulfvonbelow>file-append is a procedure that produces a <file-append> object. When this object is expanded in a gexp, it produces the resulting string. <jbnote>ok, thanks. I also just got this from gexp.scm. I just don't understand why in what looks to me like identical places, but in slightly different contexts (function arguments VS more-or-less direct value) it seems to behave so very differently. And i'm at a loss how to write things in a way that I get the behaviour I want. <jbnote>would the difference I observe be the switch in define-gexp-compiler ? <ulfvonbelow>a file-like object is represented differently in the "build side" than on the "host side". For example, (string-append (file-append somepackage "/bin/blah") "-suffix") will fail because a <file-append> object isn't a string. However, #~(string-append #$(file-append somepackage "/bin/blah") "-suffix") will succeed if, for example, that gexp is used in a computed-file, or #:phases of a package, etc. <jbnote>ulfvonbelow: Thanks for taking the time to educate me :) I think I understand the examples you gave. However here, at the same place -- where a string is required, a (file-append git "/bin/git") will yield the desired result (and the correct string) while a (string-append "CGI_SCRIPT=" (file-append git "/bin/git")) will not work. At the very same place. I'm at a complete loss to understand why. <jbnote>ulfvonbelow: or to put it in another way, I don't understand why in one case, i'm on the build side, and in the other, on the host side. The expression is just transitioning from being the function called to being an argument of a function call. <jbnote>ulfvonbelow: I would think they'd be in the same 'context' <ulfvonbelow>file-append doesn't actually "do" the file append; it just creates a record (specifically, a <file-append> record) with the arguments it was called with, so that when that record is substituted into a gexp and that gexp is expanded, it expands to the desired result. Wherever you are putting that <file-append> object, it's ending up being expanded later on down the road. In other words, when it works, it goes like this: (file-append git <ulfvonbelow>"/bin/git") --> evaluates to some <file-append> object --> that <file-append object> gets stored somewhere --> something expands it. But it doesn't work when it goes like this: (file-append git "/bin/git") --> evaluates to some <file-append> object --> (string-append "CGI_SCRIPT=" <that <file-append> object>) --> type error! <ulfvonbelow>if you share more about where the <file-append> object is getting stored and used down the road we could more precisely trace what's happening