<leoprikler>i think typically you'd add it to your os packages, but other than that no
<lispmacs[work]>nirnam: anyway, to answer your original question, `guix environment` exposing packages into your environment variables. This that you install normally get linked into a profile in ~/.guix-profile
<lispmacs[work]>you can also make additional profiles if you don't want to pollute ~/.guix-profile with project dependencies
<lispmacs[work]>nirnam: anyway, to answer your original question, `guix environment` exposes packages through your environment variables. On the other hand, things that you install normally with `guix install` get linked into a profile tree in ~/.guix-profile
<nirnam>there's alot of change from my daily distro, this might not be the easy hop I hope it would be
<nirnam>I'll play around with it in vm for abit, and problaby getting into troubles immediately, and I'll come around asking again
<lispmacs[work]>it is a new paradigm, for sure, but a lot of features of guix are especially helpful for people who like to build things from source or modify things built from source, once you learn the basics
<nirnam>funny stories actually, I love source base distro because it keeping me away from acutually building it myself
<nirnam>portage been a help, put flags into makefile and valar thing are build exactly how I want it
<lispmacs[work]>it is not something I do often personally, but as others have indicated, there are a lot of tools in Guix to modify existing packages on the fly - add flags, and what not
<roptat>finally managed to fix the build of libziparchive (a dependency of fastboot) at the latest version! That soong-build-system is starting to look good :)
<iskarian>What's the policy for grouping changes into one commit when, for example, changing a package name, or making an input propagated and then removing it from a downstream package? Should they still be split, or kept in one commit so that all commits work?
<lfam>Make all commits work in that case, iskarian
<mjsb>maximed: i'll try that! Thanks for the advice!
<pkill9>it's a nice feeling when you want to build some piece of software that was finnicky, then you find you made an almost complete package definition ages ago for it and it just needs some wrapping to complete it
<pkill9>in this case it's sc-controller, a configuration gui for the steam controller
<pkill9>which is a much nicer controller than i thought back when i got it
<pkill9>and i got it on sale for 5 quid plus 8 quid shipping when it was discontinued
<pkill9>thanks for coming to my TED talk, please clap
<sneek>Rohit, nckx says: You can always *try* to request a package :) Very rarely, it even works. However, micro-editor is written in ‘Go’, a low-quality language that makes packaging zero fun, so its chances of being packaged are slim.
<Rohit>Does Guix have a unstable branch like Nix have unstable branch?
<dstolfa>leoprikler: ah, irc and its pinging whenever a name is mentioned... :)
<dstolfa>Rohit: well, guix is a rolling release to begin with, so even the master branch is unstable in that sense (kernels change and so on). however, there are some policies around upgrading packages that many other packages depend on, and that usually happens in other branches (see core-updates, various wip branches and so on)
<Rohit>Why some packages like gnome are so old, and is there a way to update them to latest version?
<abrenon>I don't understand your last remark about the missing comma
<abrenon>is that a syntax rule of english ? I noticed I tended to do this often: separate the "and" conjunction from what's before with a comma, but I got criticized several times for doing this in my natice language, french
<abrenon>I then learnt to restrain from doing so and thought it was the same in english
<abrenon>granted, it could group with "others", but that is then disproved by the later occurrence of "will" that prevents from parsing the sentence in that case
<abrenon>I agree with you, it's much more readable with the comma, but the way you put it made me fear I had broken a syntax rule I ignored, and I wanted to make sure it was only a matter of personal taste
<yoctocell>yeah, I was a little terse, sorry about that
<abrenon>no, no, not at all ! I'm just a bit insecure with english at times
<yoctocell>I think it it's better to be a little more explicit in this case :)
<abrenon>I don't agree with the s/must/should/ though
<abrenon>if the user wants the importer to behave like she wants, she *has to* pass the repositories in her preference order
<abrenon>I hesitated with "Repositories are assumed to be", to express that no matter what the user prefers this is the way the importer will work with what it receives
<yoctocell>hmm, I felt like "must" sounded a bit too strong, but it's probably the right word in this case
<Fare>OMG, I still can't print anything. It was a huge pain getting the right PPD on NixOS, which I managed to do... twice, as CUPS at one point started rejecting the PPD I crafted. Upgrading to Nix, and neither of the previous PPDs work. WTF?
<roptat>abrenon, thanks for all you did! I'll push the new importer this evening when I get home :)
<abrenon>you mean you think it's ready ? that's great news !!
<Fare>Aha, on NixOS, my current setup involves some special filter program from Brother. Sigh.
<rekado_>I’m using brlaser with my Brother printer. Works fine.
<Fare>rekado_, does not look like it's working for me. What printer do you have, with which driver?
<Fare>(I have a MFC9970CDW. I once crafted a PPD with no filters, it used to work fine. Then stopped when I upgraded cups, so instead I used the mfcl8960cdwcupswrapper on NixOS, which uses a 32-bit binary wrapper from Brother.
<Fare>Now I'm trying on Guix. The old PPD still doesn't work, but the binary wrapper isn't in guix, and I don't know what to do. If I understood what made cups stop working with the unfiltered thing, I'd fix it.
<Fare>It could be something very very stupid like it used to have a trivial header or footer that is now not included, or vice versa.
<roptat>abrenon, mh, if you don't think it's ready, I'll read it once more and try it, but I didn't have any more comments on that patch
<roptat>is there anything I should pay close attention to?
<abrenon>no, nothing particular, it's just it was a long process and there always seemed to be something else to improve, so now I'm worried we might have overlooked something ^^
<abrenon>the only major thing you haven't seen so far is the removal of the "redundant" warning
<abrenon>actually, explaining the behaviour of my changes to yoctocell made me realize it wasn't redundant !
<roptat>ok, I'll let you submit a new version then :)
<lispmacs[work]>char: I think that ld must not use $LIBRARY_PATH. LD(1) manual page does not make it clear
<lispmacs[work]>LD(1) says that the paths searched are based on the "emulation", whatever that means
<roptat>then I'll read the patch again, give some feedback if I have any or push :)
<ruffni>i'm installing guix on a rockpro64 (yay). but it compiles linux-libre, and (i guess) pretty much everything (which takes quite some time). am i doing it wrong? is ARM64!=aarch64? are there no substitutes (though cuirass shows 100% coverage for aarch64 on channel guix)?
<cbaines>on ci.guix.gnu.org, it's the master specification that builds packages I believe
<cbaines>the substitute availability is actually quite high, 60.6% for the revision I checked
<cbaines>bordeaux.guix.gnu.org has 85.1% substitute availability though, so it's more likely to have built the things you want
<ruffni>thanks for clarification! now, that's a red image! not sure i really get it, though. WDYM with "master specification that builds packages"? would i have to do anything special to get substitutes from bordeaux? i installed guix (on debian host), did a `guix pull` and now a `guix system reconfigure config.scm`
<ruffni>cbaines: how recent should guix be? is 1.3.something enough or like *really* up to date? and is it possible to add the substitute key before system installation? bordeaux should be among the default substitutes (if i understand the manual correctly)
<muradm>i have similar question actually, i have guix system on my laptop, now i have separately cloned and compiled source code of guix, pre-inst-env works, i wander if i can do "guix system reconfigure"?
<dongcarl>That I don't know since I don't use guix system
<muradm>to reconfigure my system not with "guix pull && guix system reconfigure" but "cd ~/devel/guix && git pull && guix system reconfigure" or something like that
<bricewge>muradm: Yes, you can reconfigure form pre-inst-env
<muradm>bricewge: so it will apply to my system? any precautions?
<muradm>bricewge: yes, goal was to make user unaware of pam-mount configuration by greetd
<bricewge>I'll try to test your patch set during the weekend if I can find the time
<muradm>so it is hidden, and in the future can be replaced with something else different
<muradm>i was thinking about something like pam-xdg.so
<muradm>which will do what pam_systemd.so but only very minimal necessary stuff to provide xdg environment
<muradm>bricewge: there is a test case in gnu/tests/desktop.scm in last update :)
<muradm>should be helpful to make things clear on what greetd/seatd does
<muradm>i think all this work will be usefull in next release of sway when they drop (e)logind support
<muradm>another thing i think is that technically/logically greetd should be in gnu/services/base.scm and seatd might be in gnu/services/desktop.scm
<muradm>currently both are in gnu/services/desktop.scm
<muradm>another thing to note, is that i also implemented a graphical login with greetd
<muradm>but i'm not very satisfied on how it works in general at the moment
<muradm>so i decided to keep only terminal greeter at the moment, once this seatd/greetd will make to guix, we can add other greeters incrementaly including tuigreeter (which prompts interactivelly what to run), graphical greeter
<muradm>i just sent 03/10 again with fixed subject line, just in case