<str1ngs>not really if you are using guix.git and you pull/merge/rebase then you may very well need to do these things
<str1ngs>./pre-inst-env uses modules from the guix.git tree. which could very well need building or have changes depending on the branch state.
<nckx>I'm very familiar with guix from git, I don't use anything else. We're just talking about different things.
<nckx>Meanwhile, I wonder where lispmacs is off to… 🙂
<str1ngs>no we are not, if the autotools changes between merges or pulls you may very well need to bootstrap and rebuild. so as subjective as it maybe it safer to suggesting a environment which provides everything you might need.
<str1ngs>also I wont go into how guile macro's may very well need cleaning and a complete rebuild. most users might not use them. but it's an important distinction
<str1ngs>nckx: i've shown zero aggression. your reasoning is flawed is you refuse to admit you are wrong. while I have valid points. please take this scenario into account. if pre-inst-env.in had been modified will merging or pulling. pre-inst-env will not be updated so your point of stating this has nothing to do with pre-inst-env is flawed. since that is substitute by configure.
<leoprikler>If your pre-inst-env is ducked, you should find a way of fixing it.
<str1ngs>in this case it's not ducked it just not upto date sine it requires a configure.
<leoprikler>Building stuff from the new guix is the only way of doing QA, however minimal that is.
*nckx goes back to fighting random RAID drive numbering. One of these boots…
<str1ngs> yours was an opinion I've been backing mine up refuting facts. even leoprikler has been backing his argument with facts
<leoprikler>Reading pre-inst-env, there is really nothing of it that relies on the current guix environment.
<nckx>And I'd like you to stop refuting facts. It's confusing for newer users when you say something that's almost true but not quite (they have no way of knowing). This is the 3rd or 4th time I've had to mention this.
<nckx>It's also stressful for those trying to help said users, because it's yet another thing to address.
<str1ngs>not directly but it's implied since if pre-inst-env.in changes you need to reconfigure which requires an environment
<str1ngs>nckx: if you can't defend your opinion that do throw your opinions around.
<leoprikler>Just because you need autotools to build the thing doesn't mean you need autotools to run the thing.
<nckx>Hence my ‘we're talking about different things’ (many things could be implied or interesting fun facts, but they were not relevant to the discussion at hand). Your response was an aggressive denial of that.
<str1ngs>leoprikler: but he didnt say that. and nobody can know what a users guix.git stat is in. what if regular git pull or merge or switch branches
<nckx>lispmacs: It uses a union in /run/booted-system/profile/lib/udev/rules.d.
<leoprikler>Of course, I will git stash apply on top of a cherry-pick on top of a rebase into a merge commit just to spite myself.
<str1ngs>leoprikler: just because one user has run into zero issue with ./pre-inst-env because only rely on one change in gnu/packages does not mean there are not scenarios where that is not going to work
<nckx>str1ngs: You're literally claiming that I said something else than what I said, that I don't know what I said, and was clueless of the context of a discussion I was taking part in. Don't do that.
<leoprikler>I think it is fairly safe to say, that a user who can run ./pre-inst-env in either environment will be succesful in the other.
<lispmacs>nckx: a union? is it a special file system, or does it just build that on reconfigure?
<nckx>lispmacs: It's not a virtual file system, just created by Guix at (I think) boot time.
<str1ngs>nckx: not the dicussion was orginally between lispmacs and myself. your the one adding your 2c into ever discussion in #guix. hence your need to be seen as all knowing
<nckx>lispmacs: The authoritative answer is in gnu/services/base.scm.
<lispmacs>nckx: it looks like udev-shepherd-service proc figures out a udev-rules-union. I'm not clear yet if this is somehow done at boot or on reconfig. Make I could just add a rule, reboot computer, and see what happens
<str1ngs>leoprikler: again I've pointed out two scenarios where it's implied you will need an environment. fairly safe is not that definitive
<nckx>str1ngs: You seem to forget that this is a public channel. You can't claim things that aren't true without looking, well, a little silly.
<leoprikler>It's 2:20 and I don't want to think too hard into propagated inputs atm.
<lispmacs>str1ngs: I created a shell C program with guile embedded it in, and it was controlling my HackRF
<lispmacs>it could read from the HackRF, save to files, and display FFT plot through GnuPlot
<str1ngs>lispmacs: nice, as I recall #guile you needed to access some shared memory from libguile
<nckx>lispmacs: Given the hour, I am about 92% sure that the union is created at boot time by udev-shepherd-service, not simply copied over from the store. I don't know if that's relevant though. Does it matter?
<lispmacs>str1ngs: that was not necessary with the shell approach, since all the functions were running inside the C/Guile shell
<leoprikler>str1ngs: Your two scenarios really don't address anything other than your own paranoia. The assumptions is that you're running Guix after you've built it. Anything else is silly conjecture.
<lispmacs>str1ngs: that was basically working as an approach, but I realized that my control/data passing functions were not modular, i.e., I needed some kind of block programming model, like gnu radio has
<str1ngs>leoprikler: it's not paranoia to not assume the state of a end users guix.git
<lispmacs>which led be down a very long rabbit trail involving 8sync and the actor model
<str1ngs>leoprikler: in regards to my own guix.git I can determine it's state before merging/pull. though with the speed of commit in guix even that could be over looked.
<lispmacs>I got lost somewhere in the beginning of the rabbit trail, and in the meantime switch my desktop OS to Guix
<str1ngs>leoprikler: I also don't apprciate the ad hominem from you and nckx. so I won't be discussing this anymore.
<nckx>str1ngs: You've made your points. It's not clear to me what you hope to achieve by further guixsplaining Guix to people who have run it from git exclusively for, in my case, years.
<lispmacs>not going to be just dropping anything in that
<nckx>str1ngs: You gave no facts, just opinions. Please, stop.
<nckx>lispmacs: Oh, no, that was never an option I'm afraid. Sorry that I missed that.
<nckx>lispmacs: You can *ask* Guix to drop things there in your system .scm, though.
<nckx>That's really all (udev-configuration (rules …)) does.
<str1ngs>lispmacs: yes I'm not a fan of using shared memory myself. as I recall the orginall code was using that. but using guile should make that easier. though you still might need to use a mutex
<brettgilio>leoprikler: I got your email. I am a bit tired, so I will review it tomorrow. I like your idea, superficially though. The method probably does need some work though to handle files with special permissions like we ran into. It's an odd issue. Thank you for your work though.
<nckx>lispmacs: They are ‘magically’ pulled from the /lib/udev/whatwasitrules.d? directory in the packages you pass it. That's why it was important that we installed the udev files to the right place earlier.
<brettgilio>nckx: I am doing pretty well. This kid is just keeping me up all hours of the day. Haha. Signing commits is a privilege for when he is actually sleeping.
<brettgilio>I want to say goodnight. But knowing my current situation I will probably be awoken by a baby only to sit there in the dark continuing to patch an updated emacs-clojure-mode's failing test and figure out the permission issue in Leo's patch.
<leoprikler>I'd do an `ls -l` after unpack, printf debugging sounds like the most reasonable thing here :)
<leoprikler>Had I only picked something Guix-related for my thesis :(
<bandali>brettgilio, btw, i wonder if you saw my reply from earlier
<brettgilio>nckx: I am working in formal methods, verification and deterministic software synthesis. A friend of mine introduced me to Guix and it interested me because of the kind of loosely-related interest in functional design principles.
*janneke updates wip-bootstrap; slowly getting there
<valignatev>Hey Guix! I'm trying to package alacritty and here's my definition so far: https://pastebin.com/spwmPkiM. I know it's not complete, but current error that I see when I'm trying to build it is quite confusing: https://pastebin.com/prLiMzGT. I was expecting an error about some missing inputs, but not this. `cargo build --release` in the cargo git repository works. What does this error actually mean?
<sneek>Welcome back valignatev, you have 1 message.
<sneek>valignatev, bandali says: would you please ping me whenever you're around? got a couple questions about your emacs-git package?
<bandali>valignatev, i'm around btw, if you have some time :)
<bandali>1. your (snippet ...) field seems pretty much identical to the original one from the emacs package. any reason to not pull those in like you did for (modules ...) ?
<bandali>2. for modify-phases, what's the purpose of make-compressed-files-writable?
<bandali>3. what's the purpose of each of the new native-inputs?
<valignatev>1. delete-file section in the snippet doesn't have ("eshell/esh-groups.el") entry because current emacs master doesn't have them. So I basically copy-pasted existing snippet and removed it. I'm a total scheme noob so I don't know if there's a more elegant way besides extracting this bit as a procedure
<valignatev>2. There's a phase called "reset-gzip-timestamps" and if gzip files aren't writable then it throws a permission error. I've found multiple existing examples in the guix repo that make them writable before proceeding with this phase, or remove the phase altogether
<valignatev>3. Autoconf is definitely needed - Emacs refuses to compile without it. It fails with something like "can't find autoconf". Rest of native inputs might not be needed actually. I was having a trouble with making compilation work, I've noticed some warnings about missing perl, python and rc (I think they came from tests) and I added them
<valignatev>I think they aren't actually mandatory to compile Emacs.
<bandali>cheers! i'll try to put together a version in my local channel and test things out, and if all goes well, i'll send a patch to guix proper for emacs-next :) i'll include copyright lines for both you and myself
<valignatev>Cool! I think leoprikler should be mentioned as well because leoprikler is responsible for restore-emacs-pdmp piece
<efraim>valignatev: you're having trouble with alacritty because you don't have any of the inputs you need
<valignatev>efraim: So it is indeed an error that I'm expecting, it's just a bit cryptic :)
<PotentialUser-63>Hi #guix :), I'm trying to get slim login to work, but I think I'm running to the issue described in the docs: https://guix.gnu.org/manual/en/html_node/X-Window.html "Note: You must install at least one window manager in the system profile or in your user profile. Failing to do that, if auto-login-session is false, you will be unable to log in."
<PotentialUser-63>Unfortunately I'm not sure how to add a window manager to /etc/config.scm, nor am I familiar with user profiles, so I'm a not sure how to proceed
<PotentialUser-63>Can someone point me in the right direction? On a similar note, I'd like to add as much to user profiles as possible.. but @ the start it's probably easiest to use the system profile
<PotentialUser-63>janneke: thank you! I'm excited to get guix off this vm and onto my desktop :)
<janneke>every user automagically gets user profile once they install any package
<PotentialUser-63>I've been trying to go config only so far... so all my packages are in /etc/config.scm so far. Like I said eventually I want that to be as small as possible, then add most things to my user profile, but I don't know enough about all this yet to do that
<janneke>so saying, as a user: guix package -i i3-wm
<PotentialUser-63>ohh, so as a user I cannot use the stuff from /etc/config.scm? I added the wm to the package list there
<janneke>PotentialUser-63: on the contrary, packages in /etc/config.scm are appended to the user profile
<PotentialUser-63>also do you have any reading for me? I'm looking to fully understand user profiles, what I can and can't do there (no services, right? but I can do sets of packages, and I can sort of enter environments where I have more packages?)
<janneke>PotentialUser-63: so, adding `i3-wm' to the `packages' section also works
<PotentialUser-63>hmm... but I still need to install a wm as the user to use it w/slim login?
*vagrantc thought the display managers only saw desktop environments installed in the system profile
<janneke>no, no need to install it in both places -- you can, but it won't have much effect
<janneke>PotentialUser-63: be safe and take vagrants advice before experimenting ;-)
<PotentialUser-63>janneke: hmm, but I'm still having troubles logging in. If try as a normal user it fails right away... if I try to log in as root it says "Logging in..." and hangs. Nothing great in /var/log/Xorg.0.log except a glamor error, but I think that's stale
<PotentialUser-63>ohh and I'm trying to use xmonad (ideally no greeter, but slim seems minimal enough), so that's probably similar to exwm? I haven't used that one before though
<vagrantc>and i switched away from using the display managers once sway became usable :)
<vagrantc>so i just login from the console and "exec sway"
<vagrantc>if you have video that can support wayland and you like i3, sway might be an option as well. :)
<janneke>PotentialUser-63: that config looks okay -- so slim is not picking-up xmonad for you?
<str1ngs>PotentialUser-63: you can enter environments with additional packages. eg guix environment --ad-hoc bash. once in the environment which -a bash.
<PotentialUser-63>I'm not familiar w/i3 yet. trying to get my old xmonad setup to work, then may experiment later. wayland sounds amazing and I've been following some of the sway development from afar and it looks really cool
<PotentialUser-63>janneke: it says on the login screen that the wm is xmonad.. but I can't log in (hangs as root, kicks me back to the login screen as anyone else)
<PotentialUser-63>str1ngs: that seems really useful, and you can store them in files, right? and compose them? in my ideal setup everything is version controlled, and some environments (e.g. java) I'd keep just for times I need them
<PotentialUser-63>appreciate everyone's time and help :). I need to read more about all this..
<str1ngs>PotentialUser-63: yes environment also takes -m so you can create sub-set manifest files for environment as well
<PotentialUser-63>and I'm guessing I could write some guile to choose those @ startup, right? eventually I'll do that w/the ones I use by default, then use the others ad-hoc
<str1ngs>PotentialUser-63: i'ts probably easier create one manifest that you use via guix package -m
<PotentialUser-63>I'll try to get xmonad working w/o slim. There was a different error before (with exec xmonad), and I tried to solve that with slim
<str1ngs>slim needs special consideration. it might be easier to use gdm and xfce first then slowly swith to slim and xmonad
<PotentialUser-63>hmm. is there an easy way to just use startx? my .xinitrc currently just has exec xmonad, but previously had some services in it, that I'd like to add back after getting the minimal setup to work
<str1ngs>PotentialUser-63: not on guix, I spend sometime trying to use xinit with not much success
<str1ngs>PotentialUser-63: that was sometime ago, it might be possible now
<str1ngs>PotentialUser-63: it's probably best to start with something like ./gnu/system/examples/lightweight-desktop.tmpl
<bricewge>PotentialUser-63: Does your xmoad have a .desktop?
<bricewge>« If false, a session described by one of the available .desktop files in /run/current-system/profile and ~/.guix-profile will be used. »
<PotentialUser-63>bricewge: not sure, I think so based on what shows up on the slim login screen
<PotentialUser-63>but I take your point. eventually I want a really small system profile and whatever else I can fit in my user profile. just need to read/learn a lot
<str1ngs>PotentialUser-63: it's possible that when using xmonad installing ghc to the system is ideal. but I don't use xmonad so not sure. I'm just thinking it will save you additional system profiles if you use your user profile to test.
<PotentialUser-63>all right! now I just need xmonad-contrib and I think I'll be off to the races!
<nixo_>has anybody looked at packaging dart? I think there's the usual chicken-and-egg problem (dart requiring dart to compile). The way to proceed is to explore the git repo until I find a version that does not have this requirement, right?
<efraim>sneek: later tell ng0 sure I can test the gnurl bug later, i'm not at home ATM
<roptat>imagine you want to add a syntaxic sugar. you add it to the coffeescript code, compile it. Now you have a compiler that understands the syntactic sugar, so why not change the compiler to add some sugar, compile it and commit the result?
<roptat>they lose some intermediate compilers that way
<jahor>Hello. I'm an absolute newbie from NixOS. I feel that guix pull and guix system reconfigure are being run a way too long in comparison with NixOS. Is it normal behavior for GuixSD? And can it be caused by VM being used instead of usual PC-setup?
<brettgilio>jahor: it is usually because of guile being a tad bit slow. Guile 3 is due to be released in less than a month with SIGNIFICANT performance gain. The compiler has a new JIT/parser/lexer. So it will get faster.
<brettgilio>In the mean time, you can pass "-M n" where n is a number of parallel jobs to work around some of the slowness.
<wehlutyk>I'm trying something like this https://0x0.st/z0ou.txt , to which `guix system` says `config.scm:10:3: error: syslog-configuration-config-file: unbound variable`, and indeed I don't see how I can get access to that without in fact changing `gnu/services/base.scm` directly in guix
<wehlutyk>so how can I change the pid-file-timeout for shepherd services without maintaining a small fork of guix?
<wehlutyk>(this is all on Arch, so I also don't know why this problem crops up. Supposedly it happens to the poster in that thread because they're using OSX)
<nckx>alextee[m]: You need specification->package+output.
<valignatev>Hey! Am I using #:cargo-inputs correctly? There's a certain package (alacritty) that requires "clap". Apparently, cargo-build-system can't resolve the dependency itself, so I have to explicitly specify it as an input. It notices "clap" when I add it as an (input `(("clap" ,rust-clap-2))), but fails if I try to use (arguments `(#:cargo-inputs (("clap" ,rust-clap-2)))).
<efraim>Interesting, it's supposed to find it like that with the second one
<valignatev>And if I add it to (inputs) then I get "error: no matching package named `atty` found" which is an optional dependency of clap. So it suggest me to explicitly specify all the transitive dependencies as well
<efraim>So with inputs it fails when trying to build rust-clap
<valignatev>Just to be clear, I'm trying to "./pre-inst-env guix build alacritty" where alacritty is the definition I'm working on: https://pastebin.com/WQ93QjjB. Sorry, it's a mess because at this point I'm basically playing a guessing game :)
<valignatev>Hm, maybe there's something specific about alacritty 0.4.4 that cargo-build-system can't handle
<valignatev>I'll try to build alacritty 0.3.3 with my half-specified definition to see if that's the case
<valignatev>Actually, clap in #:cargo-inputs doesn't really gets ignored. I've looked closely to the configure phase and saw that clap source code gets pulled to the guix-vendor dir. So it really can't find it during the build phase
<efraim>There might be something up with it. I ran into problems with replacing crates in librsvg-next
<vagrantc>oops... seems like diffoscope supported zstd for several releases! should've paid more attention on my last uploads...
<valignatev>Keep you all updated on my cargo adventures. I'm sure you're all interested X_X. So apparently cargo-build-system does something wrong when url-fetch method of obtaining the source is used. The very same package definition, but with git-fetch method works
<valignatev>I'll try to play more and if I can reliably reproduce it, then I'll submit the issue, I guess
<mbakke>What could cause (substitute* "/tmp/foo" (("foobar") "baz")) to throw 'ERROR: Wrong type to apply: "foobar"' when using it in trivial-build-system? O.o