<bone-baboon>nckx: I have not seen this behavior before. Would it be an issue with Emacs, Guix or Linux-libre? <bone-baboon>At least I have a work around by pasting the entire path into the prompt for `C-x C-f`. <nckx>I don't know. I use emacs in a terminal-centric way, not as my os, so I type ‘emacs /foo’ far more often that ‘C-x C-f /foo’. <nckx>Such a blatant bug in Emacs seems so unlikely, but it's the least unlikely of those 3. <nckx>The most likely being a wrong/forgotten assumption somewhere. <nckx>bone-baboon: Are the permissions sane all the way up the path? r+x on all directories etc.? <bone-baboon>nckx: I have not changed the permissions. So I guess they would be whatever Guix created. I can also open the log without an special permissions. I am going to ask about it in #emacs. <nckx>bone-baboon: It's easy to (accidentally) set permissions in such a way that you can easily view /file/you/have/the/full/path/to.bz2 while not being allowed to list the contents of intermediate directories like /file/you/have/the. It could be a bug in Guix after all, or something changed them behind its back. <nckx>ls -ld /var{,/log{,/guix{,/drvs}}} should return drwxr-xr-x root:root for each component. <bone-baboon>nckx: Yes it returns that for each component of /var/log/guix/drvs/. <nckx>And the 2-character subdirectories? Then I'm stumped. <nckx>I'll await enlightenment in #emacs. <tophullyte>quick question, how is the support for f2fs doing ? i've been trying to install the system manually and i'm greeted with an invalid uuid error <nckx>I'm not a user myself but thought it was simply ‘supported’ now. <bone-baboon>nckx: ls -ld /var/log/guix/drvs/21/ says: "ls: cannot access '/var/log/guix/drvs/21/': no such file or directory". <nckx>tophullyte: ...so, to be clear, bug reports are certainly welcome! <tophullyte>what service do u peeps recommend for pasting logs <nckx>tophullyte: If this is about reporting a bug, it's best to send mail to bug-guix at gnu.org. It'll get a nice number & show up at issues.guix.gnu.org so we can keep track of it. <nckx>Screenshot attachments are welcome if not ridiculously (megabytes+) huge. <nckx>But to answer your question: paste.debian.net, when it's up. It's only for text. <nckx>I don't know which imagebin to recommend that doesn't do nasty cookie/script stuff. <tophullyte>im trying to migrate from void linux and it's more likely i've made a typo than anything else tho i don't kno where <nckx>I'm gearing up for bed. I hope you get unstuck, tophullyte. o/ <bone-baboon>tophullyte: Have you tried the Guix graphical installer? It works well and would allow you to try Guix out. Then if you like it you could try to do a manual install again if you wanted. <tophullyte>ive tried the graphical installer a few times but it freaks out as soon as i select a f2fs volume ;' <bone-baboon>tophullyte: You could try the manual install the instructions in the Guix manual for a manual install are good. The Guix manual install has many similarities to a Void install. <maxxcan>hello everybody. Do someone tell me a webpage with more information about make the file config.scm? The oficial information isn't sufficient for me <maxxcan>maybe I have to ask to mail list first <bone-baboon>maxxcan: You can look at the Guix manual. There are examples in the section System Configuration > Using the Configuration System. <bone-baboon>maxxcan: If you are doing a manual install you could also look at the examples in /etc/configurations/ for examples. See the System Instalation > Manual Installation > Proceeding with the Install section of the maniol. <cronopio>i'm about to format my laptop and start with a clean install of ubuntu (which i have used for +10 years and know already well), but i'm very tempted by guix, specially because of how everything is coded in guile <cronopio>but i don't know if it will be practical for my purposes: is there something equivalent to kxstudio in guix? <cronopio>or some other noob friendly way of having all audio through jack <pkill9>there are music production tools packaged in guix, including ardour, lmms, and guitarix <cronopio>yes, i've been taking a look a the package list <pkill9>i think you just need to run the jack daemon <pkill9>dunno if there's any other setup <cronopio>but having to configure audio by hand scares me a bit <cronopio>also, say there is some lv2 instrument i need, most likely it will be a .deb <cronopio>does this mean i will have to compile it from source? <pkill9>well write a package definiution <OriansJ>cronopio: we don't discuss that around here. <OriansJ>FSF projects tend to take a hardline on it. <cronopio>i've noticed. it does make sense, but i wonder sometimes how practical it is (not that i mean to discuss that anyway) <OriansJ>well entire workflows for people exist without non-free software. Some people around here even eliminate binary blobs in their firmware and bios to be more free. <drakonis>there are some situations, like nvidia drivers, that require a bit more patience, sweat and blood <drakonis>active hostility to users that requires effort to get around, it sucks but them's the breaks <cronopio>90% of my workflow is free, but i work with people who use windows or mac <OriansJ>So it is entirely practical for some people; other people have more problems because of previous choices made. (such as hostile hardware vendors, work required software and other pain points) <drakonis>i have hostile hardware vendors on my current desktop that i'm actively going to avoid for my next build <cronopio>ah, that's another thing i forgot to ask <drakonis>gotta love having to patch all of my mesa requiring packages to use nvidia's libraries instead <cronopio>i don't even know if i'll have wifi in my lenovo yoga <OriansJ>and binary substitutes really help speed up that process for the people who don't have the patience to do binary builds from source all the time. <drakonis>ambrevar has a few guix posts that will help sell it <tophullyte>i wait for the day i can get my hands on a power9 or risc v based laptop TuT <cronopio>(looks like my wifi chip is not supported) <OriansJ>fortunately there are a few RYF certified USB wifi dongles <cronopio>well, i'm still tempted by guix and it really looks like a beautiful project, and having everything config'd in scheme is beautiful <OriansJ>nixos tends to have the driver support you might need <cronopio>but it's the first distro i'll try whenever i have some more free time and a new laptop <cronopio>can you install nixos packages from guix? <OriansJ>you can also install guix ontop of ubuntu too <cronopio>but then it's just guix as a package manager, not an OS, right? <OriansJ>correct but you can basically install everything but a new kernel and drivers using guix <OriansJ>(user management is also not there but eh) <OriansJ>like a gentle introduction to guix; without having to go all in at the start <OriansJ>everything will be installed in /gnu/ not /bin or /usr <cronopio>well, i think i'll give it a try tomorrow <cronopio>yes, i think a gentle introduction to guix is maybe the best choice for now <cronopio>after all, guix feels like it's the future, but too soon for noobs like me ***iskarian_ is now known as iskarian
***iyzsong-- is now known as iyzsong-w
<tophullyte>i had `(device (uuid "redacted" 'f2fs))` instead of `(device (uuid "redacted"))` <davidl>So I need to install a hidden package with the lib output. Whats the best way (or any way) I can accomplish that? <Ikosit>There isn't a package for stack (Haskell) yet, is there? <tissevert>I don't think so… but I think its use would be different than on other distros : I used cabal and now I keep it in my environment only to generate .cabal files when I start a new project <vivien_>Hello, I have a question. The local-file function copies a file or directory locally to the store, because in a build environment you can’t just do things with files outside of the store. I have a local git repo, and I’d like to put a particular checkout of it to the store to build stuff with it. I’m currently doing: chdir #$(local-file ...) and then git checkout-index --prefix (string-append #$output "/") -a, but it c <vivien_>opies the entire git repo to the store because of local-file. Is there a way to avoid that? <civodul>vivien_: hi! you could pass local-file just the sub-directory that you want? <vivien_>I want a full checkout of a local git repo <vivien_>I have a git repository that I’m hacking, and I’d like to replace make check by cloning the local repo, extract the curent index or commit, and build it <vivien_>The problem is, I don’t know the hash of it so it’s awkward to use packages <vivien_>And if I have partially staged changes I can’t use guix hash <vivien_>I could run git checkout-index from a script, but I would prefer using gexps <zzappie>I wonder how does wip merge request style development works with path mails. Or everyone just works in semi-private and sends a huge patch? <efraim>i sometimes use semi-private wip branches <efraim>most of the time I'll create a patch, mail it off and then use 'git reset --hard origin/master' since I have a copy of it in $HOME <zzappie>I discovered git worktrees recently, pretty usefull when you want to make a mess <efraim>I have the staging, core-updates, and keyring branches checked out in worktrees at all times <zzappie>yeah and its cool that stash is shared among them preety easy to move code between worktrees *civodul added .guix-authorizations in maintenance.git <brendyyn>does anyone look at Nix's libstore/libutil code to see if there are any changes or bug fixes that should be pulled in to guix? ***MJCD is now known as MacAndCheese4Eva
<nckx>efraim: Then I made two (though identical) typos in another typo fix. Lesson: the universe demands typo equilibrium. *tissevert is amazed to see that #guix is secretly a french-speaking chan <brendyyn>its because of french people that we have to pronounce it geeeks *nckx speaks the minimum amount of French demanded by law. *tissevert is thinking about a good shiboleth to let people in: «ok, say "tarte tatin"» <nckx>Belgium is a kind of very small Canada in a way. <tissevert>gosh, got confused by the «13:48: Morning, Guix.» <tissevert>brendyyn: «geeeks» ? how is that supposed to be pronounced ? <brendyyn>when i first read guix i said it like gwiks <roptat>the u is confusing for non-French speakers :) <roptat>but the manual defines the pronunciation as being the same as geeks <tissevert>well because it's a french thing to require a 'u' only to alter the prononciation of 'g' *tissevert is relieved to see she was saying it right <andreas-e>Does anyone speak Catalan? There "guix" means a mineral. In the beginning, that is what I found when searching Wikipedia. Nowadays we are so fanmous that GNU Guix comes first :) <andreas-e>But I wonder how it is pronounced in Catalan. <nckx>When I went to Barcelona in ~2015 there was a big rock with ‘Guix’ on it. I was climbing it for a photo op but then the po-po came to chase me away. The end. <nckx>(Except now people still point it out, and lines are spent explaining UGT instead 😉) <civodul>andreas-e: i think it's pronounced goo-ish <civodul>it's also a relatively common Catalan family name apparently <civodul>we should get in touch and try to team up <nckx>Who used to SEO a lot better than they do now. Due to us. Oops. Sorry. <civodul>"Dear Mr Guix, we have an offer for you." <civodul>"Icing on the cake: we bring you a Chapman stick player." <civodul>"And a couple of top-notch lyricists." <nckx><we have to pronounce it geeeks> ‘geeeks’ sounds like you're shaking your fist at meddling kids. <tissevert>nckx: ^^ well UGT sounds the most reasonable thing to do, indeed *tissevert sets /etc/timezone to UGT <nckx>tissevert: BTW I always assumed it was pronounced ‘tarte tatin’, now you've filled my heart with doubt. How otherwise? <tissevert>you're joking but can you pronounce it properly ? ; ) *nckx descends into caramelised madness. <nckx>OK, unless there's some mandatory gesticulation not denoted in the IPA, I'm good. <nckx>tarte *make a french sound* tatin. <nckx>I use DuckDuckGo to input emojis. <nckx>Popular pals get added to HexChat's ‘auto replace’ list. <tissevert>I still have to figure out why my applications won't use ibus' current input mode *zzappie uses DuckDuckGo to lookup emojis <zzappie>why still dont have a uinicode-square-blob emoji? <zzappie>that would be a perfect universe prank on me ***zap1 is now known as zzappie
<nckx>zzappie crashed their client with weird input. ***MacAndCheese4Eva is now known as MJCD
<nckx>zzappie: � exists, but you probably mean something like ࡰ. <nckx>Where � is future-proof, ࡰ isn't. <andreas-e>This is the one I am used to from icecat, before installing fonts and more fonts. <nckx>We came all this way to reinvent ‘space’, poorly. <zzappie>andreas-e: yeah this holds strong connection with icecat for me too :) *nckx senses some pulp-quality sci-fi short story taking form about outreachy aliens building a computer to calculate a common language understandable across the universe, only to get back that the only common code point... is silence. <nckx>andreas-e: Is one font no longer enough? <nckx>I thought one of DejaVu or Bitstream Vera sufficed. <brendyyn>i just installed every package that starts with font- <nckx>YOLO, considering some of those aren't even fonts at all. *zzappie ࢠ -- arabic letter beh with v below looks totaly gnu <civodul>apteryx: should we do an RC2 like real soon? <civodul>so we can plan for a release Wed. or so? <leoprikler>IOW we should start packaging gtkmm 4 and keep those gtkmm-3 stuffs separate? <apteryx>civodul: hello! Yeah, I'll push a rc2 tonight I think; although it seems we've fixed mostly papercuts rather than blockers since rc1 ? <apteryx>could Monday still be doable? At this point only things remaining is completing the release announcement material (blog post, mail, NEWS) <civodul>apteryx: there aren't serious blockers left, IMO <civodul>there's the UUID thing, but we don't have enough info unfortunately :-/ <sneek>mothacehe was in #guix 6 days ago, saying: "Failed to add ... to store" messages in /var/log/cuirass-remote-server.log typically. <apteryx>civodul: yeah, things are looking good so far! <apteryx>civodul: I noticed some problems with spice-vdagent in my testing yesterday, namely, it'd fail to start when its socket file was left behind (it'd only work the first time!). <apteryx>I figured how to fix that, and also added the xf86-video-qxl module which provides better scaling support; I'll send 3 patches shortly if you'd like to review/test <apteryx>another random observation: our out-of-the-box font hinting is not as good as other distributions <apteryx>perhaps we could also slip wget in the vm image; it was requested a couple times on our tracker ***pocketroid_ is now known as pocketroid
<freeguy>they are using not only the openbsd kernel but by default all stuff <freeguy>they are using not only the openbsd kernel but by default all openbsd stuff <cbaines>freeguy, this seems offtopic for #guix ? <cbaines>why? because you're not talking about Guix <freeguy>but i am talking about a free distro <cbaines>right, but the free distro under discussion here is Guix <nckx>freeguy: <really> Yes. The plan is to eventually support running Guix [System] on both the Hurd and Linux-Libre. <freeguy>linux-libre is nothing without linux <freeguy>and why the heck they using GPLv2 and not GPLv3 <nckx>But the Something that Linux-Libre lacks is mostly lacking from Hurd as well, being closely tied to popularity and its trappings. <civodul>strictly speaking, "linux-libre" without "linux" is "libre" <nckx>freeguy: Because the GPLv3 didn't exist in 1992, and it's physically impossible to relicence Linux, ever. You'd need permission from every contributor ever. Even with free Ouija boards for everyone that's not going to happen. As to why ‘GPL2+’ wasn't chosen, I'm sure Linus has answered that somewhere on the 'net. <nckx>I hope so. I have no idea. <jackhill>nckx: there are Free ouija borads‽ We should package one for Guix! <nckx>If they don't, that's the end of Linux-Libre. They don't have the headcount to fork Linux. <freeguy>that is why i am saying that linux-libre is nothing without linux <freeguy>nckx linux is licensed under GPLv2 or new so they can <vagrantc>if none of the existing kernels fit your needs ... write a new one! :) <nckx>freeguy: It's really not. <freeguy>and do u think all developers agree to change license <vagrantc>didn't gcc require copyright assignment? that would make it realtively easy to change, if they did it right <nckx>freeguy: <and do u think all developers agree to change license> They did. All 1: the FSF. <nckx>GCC has 1 copyright holder. Linux has thousands. <rekado>some files in Linux are GPLv2+, but the presence of many GPLv2-only means that it will stay at GPLv2 forever. <vagrantc>keep the hate in check, it'll break you eventually :P <nckx>+1. Linux doesn't care, so it's pointless. <vagrantc>freeguy: you might ask the individual projects, rather than google, about why their licensing is the way it is ... <nckx>freeguy: Again, like Linux, the Hurd predates GPL3. However, unlike Linux, it's already ‘GPL2+’ so you can distribute it under the GPL3 if you like. <vivien_>Too bad we can’t really write a kernel in guile <nckx>freeguy: This is #guix, not #hurd. <nckx>And I'm all out of Ouija boards. <vagrantc>wow, i didn't think changing gnu/packages/aux-files/linux-libre/5.11-arm64.conf would require guix pull to rebuild all it's modules ... but surprise, it does :) <nckx>vivien_: The Scheme machine dream lives on. <freeguy>i know one thing it is going to be slow <freeguy>why u want to make a slow operating system <vagrantc>because good things come to those who have patience <freeguy>one from other corner someone build OS from python <nckx>freeguy: Why do you think it would be slow? <terpri>it needn't be slow. opengenera is reasonably speedy despite running on a hacked-together emulator, for example <apteryx>Python is about 30X slower than C. Scheme is more around 3X as slow as C, depending on the implementation you're looking at, IIRC <freeguy>nckx because this is not application, this is OS which always runinng <terpri>(i don't see any great benefit to a scheme kernel right now, but speed wouldn't be my primary worry) <nckx>s/always running/running far less than applications/. Your OS does less, not more. *nckx does one hundred GNU/Maries. <apteryx>freeguy: not that it matters currently as the Scheme bits are mostly used in the configuration and deployment of the system rather than in its operation <apteryx>with the exception of the init system, perhaps (Shepherd); and it's not like Shepherd has much to do after the system has boot <vagrantc>personally, i pretty much only like that guix is written in guile because there's a wonderful community around it ... not particularly fond of guile, when it comes down to it. :) <nckx>Sadly OpenGenera is non-free, but if it were, everybody should have to fire up that janky VM floating around the 'net at least once to see what once was and could have been... <freeguy>their is no need for scripting language, u can always make your own <terpri>i still haven't petitioned the US federal government to liberate opengenera (post-2018, they have full rights to the software since so much of it was publicly funded) <terpri>i expect the response to be a polite "fuck off" but who knows <terpri>i vaguely remember mzscheme (now racket) running on something called oskit, but that must've been decades ago <nckx>terpri: IA so extremely NAL, but I didn't know it was possible for the US government to have full rights to something whilst retaining its restrictive licence. <vagrantc>my mind always boggles when it turns out my system configuration has php somewhere in it's dependencies *nckx deletes *more* private jet spam from the mailing list queue. They know their audience too well. <terpri>nckx, well, symbolics can still sell it, but essentially the mixed public/private funding means the government gets unlimited rights, which means just what it sounds like wrt redistribution, licensing, etc. <terpri>...after a period of limited "government use rights"; normally the waiting period is 5 years, symbolics appears to have negotiated 30 <vagrantc>i think they missed the boat for their marketing window <civodul>jackhill: this Go kernel is an interesting experiment but it also looks surprisingly boring <tissevert>leoprikler: I have no context but I totally second that one <leoprikler>tissevert: It's the good old "every sufficiently advanced program implements half of common lisp" thingy *apteryx just sent 3 patches toward enabling spice in our 1.3.0 VM image, if someone is interested to review/test <iskarian>why is it desirable to explicitly bring in a language's package ecosystem (so we end up with hundreds of e.g. go-github-com-... packages)? it seems to clutter things up quite a bit, and possibly make updates more brittle <vagrantc>iskarian: got a better way to package go software? <iskarian>as a naive-to-guix user, I would expect it to work similarly to debian: most end user software being packaged in a standalone manner directly from the language's package manager <vagrantc>you mean use use the native package manager and don't actually package things? <iskarian>e.g. in the case of go, executing go get package@version and then packaging the result (since dependencies are only build-time in go) <vagrantc>as a design principle, guix doesn't allow network access during build as that could create non-deterministic inputs <vagrantc>so, "go get" in the guix build environment would fail <davexunit>guix also builds from source, pulling in someone else's binaries violates a core principal. <vagrantc>i also believe, with my @debian.org hat on, that debian doesn't allow that either, at least by policy <iskarian>davexunit, as far as I know, go get actually downloads source and builds locally <davexunit>ah okay. it still violates other core guix principals, though. <iskarian>but yes, I forgot about no network access... I suppose if guix has to generate the dependency graph itself anyway and download all those sources itself, it makes *some* sense to package all those dependencies <iskarian>It just seems awfully... cluttery and labor-intensive <davexunit>there's lot of complications that you may not be considering. <iskarian>oh, I'm sure there are! that's why I'm asking <davexunit>such as what non-go software must be present in order for the package to install correctly <vagrantc>iskarian: those systems that only allow that kind of development process *are* cumbersome to maintain <vagrantc>i think rust is pretty similar in that regard <davexunit>language-specific package management is a very frustrating trend <iskarian>hmm, I've got to go eat, but I will think on that <iskarian>davexunit, it very much is (from our perspective anyway) <vagrantc>both frustrating, and understandable, depending on what perspective you're looking at it from <davexunit>it's frustrating on the other side of it, too. *vagrantc blames computers <davexunit>being a developer and trying to install stuff and having it fail over and over because you need to install libfoo-dev, etc. from the system package manager <davexunit>and then there's being a more senior developer that helps other developers setup their development environments and having to play this game of whack-a-mole to save the more junior people from experiencing the frustration... <davexunit>it sucks as an upstream package dev because you have users who can't figure out how to install your software because they are missing a system dependency and then you have to deal with that problem for a bunch of OSes and distros. <davexunit>it only works on the narrow happy path where there are no C libraries being wrapped or other software being called via exec, etc. <leoprikler>That may very well be true, but as an ad-hoc solution to that issue, language-specific package managers still function quite poorly. <pineapples>I see our substitution infrastructure is doing exceptionally well today: "gnome-settings-daemon-3.34.1 2.51GiB/s" :') <iskarian>If any dependencies have to be modified to work on guix, I can definitely see them being explicitly in the system package manager would be very helpful <roptat>once I managed to download a debian package at a few Tb/s... on a Gb ethernet :p <iskarian>I wonder if it would make sense for some language ecosystems, to have invisible auto-generated packages for dependencies if they are not already packaged. <roptat>it would make sense, but that would actually be less ideal for guix: we wouldn't be able to check licenses as easily, that they are not doing anything nasty during the build, etc <roptat>also, you'd lose reproducibility: if you go back in time and use the same generation of guix, you end up with a different state of the world, and different package versions as dependents <roptat>but at some point I'd like to try something like that for OCaml, probably in a separate channel <roptat>basically, it would be running the importer on the fly to construct the packages from the state of opam (or whatever package manager for your language) <roptat>opam is pretty nice because they declare external dependencies most of the time, and opam (the tool) is able to find and install them automatically using the package manager it detects <roptat>not sure it would work well for other languages <iskarian>"<roptat> ... different package versions as dependents" this issue also presents itself for languages which allow you to use specific versions of dependencies <iskarian>Do you package every version explicitly? Or do you create a package which offers pseudo-versions? <roptat>in guix we usually package only one version, unless we need multiple versions for different packages <iskarian>it's very common in language package managers to require a specific version (and dependencies may require their own specific version!) <roptat>but what I mean is, at t0, you get a set of dependents for your package, and at t1, even though it's the same guix package, if you depend on the state of the world, you get different versions for dependents, and you have no way to get the exact same package as at t0 <roptat>ah, maybe that's the case, I'm more used to opam, usually dependencies are named, but no version is provided, so you use the latest and hope for the best... <iskarian>I've seen npm packages with 4 different versions of the same dep in the dependency tree... <roptat>or you get version ranges, like >= 0.14 < 0.15 <roptat>eh, that's not a problem, we also have multiple versions of the same thing in some dependency trees in guix too :) <roptat>(usually for bootstrappability reasons) <vagrantc>ok, got the "regular" linux-libre working for pinebook-pro <vagrantc>ok, time to file my "there really should be better module handling in the initramfs" wishlist bug. <civodul>they're doing really nice things, on Emacs also <fjl>Hi, I would be grateful if someone could take mi out of the dark corner. I cloned guix repo, run `./bootstrap` and `./configure` and tried to run `./pre-int-env guix` but got hit by `./pre-inst-env: line 55: exec: guix: cannot execute: is directory` What am i doing wrong? <iskarian>On that note, the manual really isn't super clear what the steps are, since they're all embedded in prose <iskarian>I also messed up building from source a couple times because I missed steps <acrow>I tried to install sonivoc-eas this morning and found it would no longer build. Digging into it, I was again able to build it after a trivial upgrade and I've sent in a patch. I think the problem was caused by the upgrade of a package input, drumstick. Does that make sense? <zzappie>fjl: yeah there is section in Guix Reference info manual "Contributing" you will find all the steps there if look carefully. You also need to provide --localstatedir argument to ./config <mroh>for 'guix system' there is --skip-checks. Is there a way to get this param to 'guix deploy' so that the system-checks are skipped on the deployed machine? (my kernel config always fails in some initrd checks, but works well...) <fjl>Right, I missed that. Thanks! Too much jumping between different subsections of the manual. <zzappie>rekado: yes :) I went to findout whether I got "localstatedir" right to find that I spelled configure wrong <zzappie>fjl: world is so small. I think i used your emacs config to setup go dev environment recently :) <fjl>I do not have any special emacs config, I'm using pretty default spacemecs so It must have been someone else <admas>Does anyone have any issues with watching videos with nouveau graphics driver? I'm noticing noticeable slowdown when watching YouTube. I have 6 cores and 32GB of ram so I think it's the driver but cant say for certain <adfeno>Hi there, in foreign distros, should where should I put environment variables? <adfeno>I saw some places where they advise to put on .bashrc, .bash_profile, and so on, but I tested in both of those and .profile seems to be the best one for all places. <adfeno>Because otherwise the desktop environment doesn't pick most of the things. <leoprikler>rc is evil, putting it in any profile is file as long as that profile is read <adfeno>I find it confusing since the documentation doesn't make that clear, it does recommend using .bash_profile (or any file read by a shell to load the profile), but that is misleading if some parts of the desktop environment aren't picking this up. <vagrantc>it should get installed from the binary installation script, as i understand it <vagrantc>but maybe that doesn't handle all the variables <ruffni>what's the easy way to get the location (like "basename `which iptables`") of an input within a package definition? the package build script looks for iptables but can't find it in the usual directories. <rekado>ruffni: (assoc-ref inputs "iptables"), where “inputs” is bound in a build phase <rekado>if it’s outside of a build phase use the magic %build-inputs instead