<mehlon>well that's fine, the issue can just stay open until someone decides to work on it <nckx>mehlon: I'm sure it will be accepted if you submit a patch, I just don't think someone will do it for you. <mehlon>ah, I'll have to learn that nix language <mehlon>I might try packaging this tomorrow(?) <mehlon>I'd have to learn to use nix first, and also learn how to compile guix <mehlon>so far I'm having great fun with nix <nckx>I'm happy to hear that 🙂 <nckx>They seem to be doing well. <lispmacs>what is the easiest way to install my package definition in my profile, before submitting the patch to guix? <lispmacs>I mean, install the package, not the definiton <lispmacs>do I have to use a channel? I tried guix package -f but that doesn't seem to evaluate correctly <nckx>lispmacs: I don't use it, but guix package -f should be analogous to guix build -f. <lispmacs>nckx: error: cannot install non-package object: #<unspecified> <nckx>lispmacs: Yet build -f works? <lispmacs>error: #<unspecified>: not something we can build <str1ngs>probably you need to add the package name to the tail of the package file. <lispmacs>str1ngs: oh, is that supposed to be there? <nckx>I thought you knew this yesterday, but I might be messing up names again 🙂 <str1ngs>lispmacs: yes it needs something to evaluate <nckx>lispmacs: Yes, just add ‘hackrf’ (if that's the variable name) as the last line. <lispmacs>str1ngs: right, but is it supposed to be in the patch as well <nckx>lispmacs: Wait, which file is this in? <str1ngs>I think this can be improved since it means you cant' use that file both as a module and with -f <lispmacs>files is in ~/Repos/guix/gnu/packages/hackrf.scm <nckx>Then you should test it with ./pre-inst-env guix package -i hackrf. <str1ngs>in this cause yous pre-inst-env assuming this is guix.git proper <nckx>If that doesn't work you'd be submitting a broken patch anyway. <str1ngs>it will keep people on there toes! lol <lispmacs>nckx: do I do that from within the [env] or outside of it (I'm following the video tutorial) <nckx>I'm of a different opinion. After you've bootstrapped and build Guix it really doesn't matter. <str1ngs>it kinda matters if autotools changes and you need to ./bootstrap and ./configure neither is guaranteed to work unless you have the environment to do it <nckx>Then we're talking about different things. <nckx>I'm talking about ./pre-inst-env guix. <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 <nckx>None of that affects ./pre-inst-env guix. <str1ngs>I've given my points do with it what you will. as I recall I used the term preferred so it's subjective. I argue that one is safer than the other though. <lispmacs>the hackrf utilities seem to be working, but they cannot find the HackRF. The HackRF leds say the USB communication is not yet established <lispmacs>I'm thinking I need to install the udev rules <str1ngs>lispmacs: I was going to ask if HackerRF is a USB devics <str1ngs>lispmacs: do you need udev rules on other distros like android devices? <lispmacs>does guix allow per-user udev rules some how...? <lispmacs>str1ngs: they had to be installed on Debian 9, when I was using that <str1ngs>lispmacs: I don't know about per use. but there is android-udev-rules package which might help for creating the rules you need. <lispmacs>or, I assume they did, I didn't try not install them <str1ngs>this is assuming it needs rules at all ***Server sets mode: +cnt
<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. <str1ngs>leoprikler: correct that is why I said using an environment is the preffered way to call ./pre-inst-env. <lispmacs>the hackrf udev rules include vendor and product ids, a symlink name, as well as group perms, so I guess they must be necessary <lispmacs>android-udev-rules package indicates that after package is install, you have to link to it in your system config <str1ngs>leoprikler: maybe I misunderstood docked I thought you meant fubar. I guess out I was thinking out of state <str1ngs>well less say its' state could be ducked? <leoprikler>In either case, you would (inside a pure environment) ./configure and then make <leoprikler>You can do your git stuff in a second shell outside of an environment. <lispmacs>I wonder if there is a quick way to test if the udev rules are needed. Can I just create an /etc/udev/rules.d? <str1ngs>lispmacs: you could try to get the rules file and just a etc-service-type <str1ngs>lispmacs: manually might be okay, but that could cause issues on reconfigure <lispmacs>does guix udev look for stuff in /etc/udev/rules.d? <str1ngs>lispmacs: where does the android-udev-rules suggest putting the symlink? <lispmacs>str1ngs: it just says "this package is intended to be added as a rule to the <lispmacs>@code{udev-service-type} in your @code{operating-system} configuration. <lispmacs>Additionally, an @code{adbusers} group must be defined and your user added to <lispmacs>the rule goes in %output/lib/udev/rules.d <leoprikler>str1ngs: oh, and just so you know, ./pre-inst-env should (once it has been configured) give you the same results inside or outside of the env <str1ngs>leoprikler: assuming pre-inst-env.in has not been changed yes <nckx>leoprikler: Don't bother. <str1ngs>leoprikler: also there is the potentially for anything using guile macros need rebuilding should the macros change. that's probably a rarer scenario but still feasible <nckx>I don't mind your occasional… different opinions here but please don't state them as fact when people ask for help. *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: sure but if pre-ins-env.in the pre-inst-env is out of state. this particular example can be fixed if the substitution was moved to Makefile.am vs configure.ac <nckx>Take this elsewhere. #guix is not where people must defend their opinions to str1ngs. <str1ngs>leoprikler: but even if it was move to Makefile.am it would then require make to be run. and again back to an environment <leoprikler>moving it into makefile.am makes things even worse, because that would have to be parsed twice before actually generating the file <nckx>str1ngs: You're free to believe whatever you want. Just don't mislead others. That is what I am asking, and have asked multiple times in the past. <str1ngs>regradless pre-inst-env need an environment <str1ngs>and your not addressing guile macros <leoprikler>Guile macros have nothing to do with pre-inst-env tho <nckx>str1ngs: Guile macros are irrelevant here. <str1ngs>nckx: there is nothing misleading about using an environment when working with guix.git <nckx>This has been explained to you multiple times. Please just let this rest. <str1ngs>leoprikler: if they need rebuild then you need an environment so again back to environments are more sane when working with guix.git therefore it's more sane and preffered <nckx>Personal preferences are great. <nckx>Like ‘does anyone ever actually use ,bournish oh god the horror it burns’. <str1ngs>leoprikler: actuyally macros are harder to deal with because you actually have to clean then rebuild ***catonano_ is now known as catonano
<leoprikler>nckx: I actually was forced to use bournish once, when I installed Guix over an old distro (dirtily) and had to remove stuff from /etc to make it work <leoprikler>nckx is not talking about "when do you need to recompile some stuff" or "when do you have to nuke your entire build" <leoprikler>what nckx said, is that pre-inst-env (assume unchanged and configured) can be used with or without environment, whichever way you prefer <str1ngs> lispmacs: nckx: do I do that from within the [env] or outside of it (I'm following the video tutorial) <lispmacs>does anybody know where guix udev looks for rules? <leoprikler>meaning you could for instance do `guix environment guix -- ./bootstrap && ./configure && make; ./pre-inst-guix whatever` <str1ngs>there was not context as per the users request. so the preferred way would suggest an environment is since there was no context <lispmacs>like, does it still use any default paths? <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. <nckx>Oh no, it's 2:20 I was wrong as always. <nckx>All hail the night owls. <lispmacs>it is 16:20 in Alaska, if you want to know <leoprikler>Sounds like a good afternoon to be configuring a config.scm :) <nckx>It's probably always a good afternoon in Alaska. <str1ngs>lispmacs: how did your shared memory libguile project go btw? <lispmacs>um... long story, that eventually brings me back to what I'm doing now <str1ngs>I wondered if the two were related lispmacs <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. <nckx>str1ngs: #guix is not a place for people to defend their ideas in vigourous debate with str1ngs. It is also not the place where you own the conversation after jumping in at the end of the day. <nckx>str1ngs: I'm glad to hear that. Plenty of other things to discuss 🙂 <str1ngs>then drop it. I'm not pushing any opion I have given fact. if you disagree then that on you not me <lispmacs>nckx: hmm, it seems that /run/booted-system just points to a gnu-store directory <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>Nothing that hasn't happened before. Let's let sleeping dogs get their well-deserved rest. <nckx>(Hint hint 🙂 Hope you're well.) <lispmacs>nckx: they would need to be pulled from a package, though, right? <leoprikler>A debate. I actually wanted to go to bed right after sending that mail, but alas, here I am in it. <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. <nckx>leoprikler: Wanna help kick a raid array? <lispmacs>okay, I just figured out from base.scm that they are supposed to be in /lib/udev/rules.d <nckx>brettgilio: Obvs. Don't want him peeking at your passphrase. <nckx>lispmacs: Yes… isn't that the same as we discussed earlier? Or am I going mad. <leoprikler>nckx: Not really. I'm living out in the boonies, here a 'raid array' refers to a group of pretty aggressive hedgehogs. <lispmacs>nckx: earlier you said /etc/udev/rules.d <nckx>(lispmacs: I grepped the logs and actually did say /lib consistely but I will never feel comfortable amiably correcting anyone ever again. Your package did want to install them in /etc, though.) *leoprikler always ends up in such a miserable state when sleep-deprived. <nckx>leoprikler: Now I'm picturing a Viking raid of hedgehogs. <nckx>lispmacs: No, see, I didn't… argh. All sucks. <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 :) <nckx>leoprikler: And how long have you been using? <nckx>Guix is a drug. We all know it. <brettgilio>nckx: true. I feel empty and lost on machines without it. <leoprikler>I basically resurrected one of my old laptops to run Stepmania on it. <nckx>We have the best release codenames. <brettgilio>I remember I tried getting a lot of people to try guix right at that time when the CI was broken for like 10 weeks straight. <brettgilio>Before it was renamed ci.guix.info or wtvr. I don't remember anymore <leoprikler>I've Scheme'd for at least a year and used Emacs Lisp before that. <brettgilio>leoprikler: I'm gonna be nosey but age and education background? <nckx>brettgilio: How did you come to Guix? <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. <nckx>brettgilio: That's really cool. <bandali>i'm 25, on my way out of a master's :p <brettgilio>bandali: that's why I am working on packaging tons of Standard ML stuff for guix rn. <bandali>i'm currently dealing with java-based tools like alloy and rodin (event-b) <bandali>(in terms of packagability for guix) <leoprikler>Well, I learned some of it, given that I took ITSec. <bandali>i wonder if guix has a tla-toolbox package <bandali>yeah it's cool; though i personally like tla better <leoprikler>But I didn't get to apply them yet for reasons better not inspected too closely. <bandali>i'll be trying to get into Coq and Lean soon again, once i wrap up my thesis <bandali>we have the french to thank for Coq's name <leoprikler>It would not be better had the Brits called it rooster. <brettgilio>Goodnight all. I should rest so I don't make ill-formed commit messages. <leoprikler>I still have to learn commit message discipline myself as well. <brettgilio>bandali: nice meeting you. Feel free to email anytime. brettg@posteo.net <leoprikler>I have to commit stronger to commit discipline, as it were :) <bandali>brettgilio, nice meeting you too! and same, feel free to email me at my nick @gnu.org :) <lispmacs>nckx: I'm out of time to continue working on this project today, but I posted the package definition to my blog: <leoprikler>Well, I should probably head to bed now as well. Goodnight. <nckx>lispmacs: Thanks! I'm currently manually typing store paths but will definitely take a look when my sanity returns. <nckx>leoprikler, lispmacs: o/ <nckx>I should probably go to bed too. Good night. <nckx>bandali: Take good care of the night geeks. <Minall>I'm having some problems with a package 'lollypop' which should allow me to fetch and listen tracks from youtube inside the program using youtube-dl <Minall>I know it works since I tried it in other distros, but on guix I get the error 'can't find this track on youtube' when trying to listen to a track <Minall>How can I check if a package has optional packages to install? <Minall>I can't open the next browser after installing, trying to run the process in a terminal gives me some lisp code... <wdkrnls>Lollypop wasn't working for me at all in the past. Now it's working for playing music. Never tried the youtube feature. <wdkrnls>I just upgraded my packages and next appears to be starting "normally". <A[m]3>thank you, I'll check it later. <roptat>I'm trying to setup offloading, but "guix offload test" says "guix offload: erreur : impossible de se connecter à « #<input-output: channel (open) 7fe68f0953c0> » : Erreur de protocole" <janneke>roptat: hmm, it's been some time that i setup and debugged that... <janneke>roptat: does this work: ssh <build-machine> -- "guile -c '(use-modules (guix))'" <roptat>and after installing guile, no module named (guix) <leoprikler>How do you offload builds to a machine without guile or guix? <roptat>guix offload test tells me guix is usable on the remote machine before failing <roptat>now the error is "guix offload: erreur : unknown error while sending files over SSH" <janneke>i think you need guix and guile-ssh in the profile -- but could be wrong <roptat>ok, guix offload test passed, thank you! <roptat>mh... so with offloading, I can't use substitutes? <roptat>why does guix build hello want to rebuild everything? <janneke>yes, you can use substitutes; that should work <roptat>but why didn't it use a substitute for hello? <roptat>also, can I have a build on the remote machine and on the local machine at the same time? <janneke>does the build server accept substitutes (guix key registered?) <rekado>roptat: yes, you can have builds on both machines. I think you’d just have to add the local machine to /etc/guix/machines.scm <rekado>it would then “offload” to the local machine. <janneke>roptat: "hello" is always a great package to play with; gc -D from local and build-server store, try again etc <janneke>be sure to notice wether what's built is not just a graft *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>re 1. as far as i saw, emacs.git doesn't have any files matching the first two regexps either <valignatev>Hope they're helpful. I didn't knew much when I was doing it (not that I know a lot now, heh) <bandali>but i wonder if we could just leave those snippets in <bandali>i don't think they'd fail if they don't match any files to be deleted <valignatev>bandali: Right, I think this snippet might be relevant for tarball that comes with precompiled lisp files, but not for a git repo <bandali>and your explanations certainly are helpful, thanks! for 2 specifically, i'll probably add a comment mentioning it <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 <janneke>"vagrantc thought the display managers only saw desktop environments installed in the system profile" <PotentialUser-63>ohh. yeah that's what I'm doing, right? Sorry, I'm very inexperienced in guix land *janneke tries to be helpful, but only really uses exwm <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 <str1ngs>tough xmonad should work with gdm no? <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>I'm trying to avoid %desktop-services, as that adds things like NetworkManager.. but I think that's causing most of my pain here <str1ngs>PotentialUser-63: %desktop-services can be modified. <str1ngs>PotentialUser-63: did you try with --recompile? <PotentialUser-63>yeah I'd need to look through it. ideally would whitelist (build up a config) rather than take things out of one that will potentially grow (blacklist) <str1ngs>it's trying to exec a program that does not exist it seems <PotentialUser-63>ok, so here's my config so far: http://ix.io/24w7. Do I need to add ghc or guix package -i xmonad as my user? I thought I could just have this as root and use these programs as "me" <str1ngs>what is the output of which -a ghc ? <str1ngs>try then adding ghc to your user profile <str1ngs>it might only need ghc at build time and for recompiling custom user xmonad files <str1ngs>PotentialUser-63: I would first test in your user profile before adding to system packages <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! <PotentialUser-63>ohh it's ghc-xmonad-contrib. sorry for the noise and thanks again for all your help! ***ishmael is now known as finfin
<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 <nixo_>efraim: thanks, I'll give this a try then <roptat>nixo_, yes, but sometimes it's not enough :/ <roptat>like if you go back in time, at some point scala was built using a non free language and compiler <nixo_>roptat: I read somewhere that some old release of dart was compiled from C <roptat>or some commits of coffeescript cannot be built with the previous commit <roptat>I'm trying the same thing with kotlin. I think I've found the right commit to start from, but then I'm having troubles finding the correct version of dependencies... <nixo_>roptat: how is that possible (for coffeescript)? <nixo_>I mean, they used some _intermediate_ version (between commits)? <roptat>the reason is simply that the repo has the coffeescript code of the compiler, and the compiled executable javascript code <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. <jahor>Oh, that is nice. Thanks for your answer. <leoprikler>Will guix be ported quickly or will it take another c-u round? <brettgilio_>leoprikler: I think they have been working on it as the prereleasss have been happening. But idk for sure. <nixo_>roptat: wow, I'm back to 2011 reading pages on the wayback machine. Time travel is a thing ***lurch is now known as optima
<vagrantc>info-reader is failing to build ... is not allowed to refer to path '/gnu/store/ziin...-perl-5.30.0' <vagrantc>last version that worked for me was 6e10ac07 *vagrantc guesses a13116b or 614a1e3f <smithras>vagrantc: weird, texinfo.scm hasn't been changed in months, maybe a perl change? <vagrantc>other than the two commits to texinfo.scm today? <smithras>vagrantc: I did git fetch instead of git pull.... <efraim>The second fixed a 'guix pull' issue with the first, but it's possible there's something wrong with the non-cross compile logic <brettgilio>bandali: I responded to your email just a little bit ago. <bandali>brettgilio, heya, got it, am currently writing a reply :p also got your mail at webmasters@; you'll hopefully get a reply about that from one of the webmasters soon <brettgilio>bandali: I appreciate your help with that by the way. <brettgilio>bandali: Do you do much prolog? I notice we share that on our whois. Also youre a srht user too? Very cool. <bandali>brettgilio, ah :) i did some prolog back in my undergrad, not a lot lately unfortunately. but i'd love to get back into it again when i have some more free time <bandali>and yup, i'm on sr.ht indeed :) i quite like it <brettgilio>bandali: Have you seen Mercurylang? It's like a combo prolog syntax with haskell behavior. <bandali>and with #guix, you and i seem to share a good number of interests haha <bandali>ha, i don't think i have; but it sounds interesting! <brettgilio>I thought about writing a de Bruijn style naive proof assistant in it. <bandali>and i'd love to hear about that if you do get around to doing it <brettgilio>bandali: There is a built in mercury mode in emacs, which is a wrapper around prolog-mode. But it is broken beyond belief. <dig>what does ...info-reader-6.6') is not allowed to refer to path `/gnu/store/...-perl-5.30.0' means? <dig>guix install info-reader is the simplest command that fails, after successfull compile of the package <alextee[m]>how do i add a specific output in the "specification->package" thing in /etc/config.scm? <dig>brettgilio: in general i've booted usb and trying to do custom install, but never seen that kind of error before <wehlutyk>Hello everyone! I'm fairly new to guix and trying to use it to create VMs/containers/docker containers on a home server <wehlutyk>And would be in need of a little help with a specific problem <wehlutyk>syslogd doesn't start (in fact, as described in the thread), it sometimes does start but takes more than 5 seconds so shepherd doesn't detect it <wehlutyk>so the ssh server I would like to use also doesn't start <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 :) <efraim>For cargo-inputs it's not package-source, it's just ,rust-clap-2 <valignatev>efraim: Yeah, I've tried just ,rust-clap-2, nothing changes <valignatev>(package-source ,rust-clap-2) is a part of a guessing game I'm playing with a cargo-build-system. My scheme knowledge is not enough to understand how it works unfortunately :() <valignatev>Specifically, I want to understand why it ignores cargo-inputs <valignatev>guix man says that the package in the cargo-source must evaluate to a path to a gzipped tarball which includes a "Cargo.toml" at its root or it'll be ignored. <valignatev>Clap does have Cargo.toml at its root, but maybe rust-clap-2 doesn't evaluate to a correct format <valignatev>Also, if cargo-build-system ignores it for any reason, it seems like doing it silently because -v 2 verbosity doesn't include any additional info <valignatev>bricewge: Whoa that's cool, thanks! Although I don't see anything suspicious that is very different from what I'm doing. <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 <mbakke>Interesting, then I get "ERROR: Wrong type to apply: #<syntax-transformer substitute*>" <rekado>mbakke: you may need to import the utils module first. I’m not sure if it’s available in the trivial-build-system by default. <mbakke>rekado: I have (usemodules ((guix build utils))) and copy-recursively etc works fine. <nixo_>Hi! I'm getting this strange erro when running make in the guix dir: automake-1.16: error: cannot open < ./doc/guix.de.texi: No such file or directory <nixo_>any idea on what is causing it? I mean, also make clean is not working <rekado>nixo_: did you bootstrap and configure first? <nixo_>rekado: yes, it's the folder I've always worked in. I've done it again now (and it's running) but I didn't want to wait for the full build. Nevermind, thanks <brettgilio>bandali: I think you will like my most recent message on the WIP Mlton issue. Give it a read when you get a moment :) <brettgilio>rekado: you've been hard at work today with those R packages. haha <brettgilio>btw, did you know the changes to EMACSLOADPATH borks your guile-studio? <rekado>I heard, but I haven’t been able to check yet. <brettgilio>rekado: Basically your nifty autoloads method no longer works. <rekado>is guile-studio doing something silly, or should this really be possible? <brettgilio>I only know this because I actually stole your autoloads method for my own emacs-on-guix distribution and that change Maxim made broke it. <brettgilio>So, all packages now have to be done by propagation it seems. <rekado>well, that’s not good for guile-studio. <rekado>I don’t want these packages to be installed in a way that makes them available to Emacs in general. <rekado>I’m not sure I understand what’s going on <rekado>when I start guile-studio I get an error about wrong number of arguments <rekado>guile-studio calls guix-emacs-autoload-packages with all of the directories of its inputs as arguments. <rekado>I can work around this and set EMACSLOADPATH in the wrapper <leoprikler>But what do you think about putting emacs + elisp libraries into a single union package and pointing EMACSLOADPATH to that (kinda like sdl-union)?