<Formbi>and some thing use different versions of stuff <kmicu>Noclip: there are many reasons but mostly: old versions let us rollback and some closures are not optimized for size. <nckx>Guix has (within reason) a maximalist approach to features: we tend to --enable- everything that sounds useful by default. <nckx>Thank you for your work on the FSD. <GNUtoo>I've looked at the documentation and the cookbook, but I didn't manage to understand how to generate the sha256 for a git repository at a given hash <GNUtoo>nckx: FSD is the Free software Directory? <GNUtoo>I didn't remember contributing to it, but I may have (I contribute to too much things) <Noclip>alextee: How big is your guix store? Are you using the Guix system? <nckx>GNUtoo: What have you tried? cd git.repo && git checkout <id> (or git reset --hard <id>) && guix hash -rx . is the standard way. <nckx>GNUtoo: My mistake, I meant H-node. <GNUtoo>(The manual points to some guix downloaad command) <alextee[m]>but when i clean it it's usually around 20G or something <nckx>I was on there the other day & you were 9 of the 10 most recent contributors đ <GNUtoo>nckx: I still need to ping the mailing list to change "Laptop" in "Computer" there <nckx>GNUtoo: That's for single files like tarballs. <kmicu>Isnât the standard way to put wrong hash, then guix tells us the good* hash, and then we put the good hash in place of the wrong hash? xD <GNUtoo>indeed, thanks I'll try guix hash <nckx>kmicu: Sssh that is level 33 knowledge. <nckx>We don't teach that until all your thetans are illuminati's. <nckx>Also you must donate $5 to the FSF. <Noclip>alextee: Do you have a lot of packages for developement installed? <alextee[m]>Noclip: c/cpp development libs and lots of big stuff like obs, chromium, etc <vagrantc>i've often wondered about including signed tarball checking ... not strictly needed for someone just using guix, but if you're updating a package definition, it might be good to more easily check that the tarball (or git tag?) is signed <nckx>You're not alone. Go for it. <nckx>Someone (re)suggested that on the ML yesterday or so. <Formbi>I was thinking about it today too xD <nckx>I can't think of any counter-arguments. The only one I've heard was unconvincing; âbut that will make packages lazy, they need to check manuallyâ â no, packagers, being mostly human, already are lazy and now simply do nothing. <GNUtoo>ah now I've hash mismatch, but it tells me the new hash <hendursaga>nckx: About that maximalist approach, I take it if you want to have smaller binaries and whatnot, you'd create your own channel with those packages with less features enabled? <nckx>& the power of inheritance means you'll only have to do change them when your changes become incompatible with upstream, not for every new version. <Noclip>alextee: "but when i clean it it's usually around 20G or something" <Noclip>That might not even be that bad considering that my System uses around 12G (without counting flatpaks and guix packages). And I have nearly no developement software installed in comparison to you. <nckx>Again, all will be revealed after your donation is confirmed. <nckx>You won't find out I'm a lizard until level 34. <GNUtoo>hmmm, openssl is both a license and a package <GNUtoo>WARNING: (#{ g129}#): `openssl' imported from both (guix licenses) and (gnu packages tls) <pkill9>normally a prefix is added so it's license:openssl <Noclip>How does a linux system (indipendent of guix/nix) react to a full disk? Will it just fail to write to it or might it try to free some disk space on it's own? <vagrantc>it will fail to write any attempt that exceeds the available space <nckx>Writes will fail. Very few programmes handle that well. Many assume writes always succeed and either silently throw away data or crash. <nckx>Don't go near it if you can help it. <GNUtoo>Noclip: it depends on the filesystem, <GNUtoo>Noclip: for ext2/3/4 you have a reserved id for more space <GNUtoo>Reserved blocks uid: 0 (user root) <GNUtoo>Reserved blocks gid: 0 (group root) <GNUtoo>So if you're root on my laptop, you can still write while users can't if that partition is too full <nckx>In practice that just as often means that root's valuable syslog noise gets saved to disc, while your user's worthless hour of work does not. <GNUtoo>Too full is defined by a percentage <Noclip>I got my home nearly full a while ago without noticing it and suddenly Element (Riot) told me that it had lost all it's login details due to the limited storage amount. <GNUtoo>For instance on some of my machines I add Tor in there so it can still start if the disk is full, to enable me to ssh into the machine through Tor and fix it <GNUtoo>guix package: warning: only 3.1 GiB of free space available on /gnu/store *GNUtoo is nearly out of space it seems <Noclip>It must had something to do with electron because Element said "my browser" would have deleted that data. <nckx>GNUtoo: That exact warning saved a client's system from going down today. I ran âguix pullâ & just happened to see it scroll by. The space usage wasn't even Guix's fault, but I was grateful for the heads up. <Noclip>Well I think I should just make my lvm partition a bit bigger xD <nckx>They're paying for monitoring now đ *GNUtoo is just trying to build some software through GuiX and was warned right now <NieDzejkob>gah, guix environment on core-updates wants to build lots of extra stuff <GNUtoo>Ah I understand now why it gave me the openssl warning, the cookbok has that on the more advanced example: <GNUtoo> #:use-module ((guix licenses) #:prefix license:) <NieDzejkob>also, wow, so many things pull in x11 stuff through python <ornxka><Noclip> I got my home nearly full a while ago without noticing it and suddenly Element (Riot) told me that it had lost all it's login details due to the limited storage amount. <ornxka>this exact thing happened to me not two hours ago <ornxka>i dont understand why it deletes stuff thats already there in an out of space scenario <ornxka>the browser already uses half my memory, it couldnt just buffer a few megabytes for this case? <Noclip>I assume that the chromium browser (electron) doesn't know what it is actually storing and so just threw some of it's storage data away to make space for some new data. <NieDzejkob>I had a bug like this in my program, where when it tried to write an updated version of a file, open() succeeded, overwriting the old version, but then write() failed <Formbi>the Telega thingy works like a charm <GNUtoo>Guix supports Android.mk, right? <Noclip>I'm a bit afraid of extending my lvm partition as I currently don't have a backup of my data. <vagrantc>extending is pretty hard to get wrong unless you start passing --force arguments <Noclip>I could alternatively just copy the guix store over to my data partition as I've a lot of free storage on it. *GNUtoo is unsure how to use that <GNUtoo>I just learned about android-make-stub by looking at guix sourece <Noclip>Would that work?: 1. Stop the guix daemon, 2. manually move over the whole store data, 3. replace /gnu by a symbolic link, 4. Start the guix daemon again. <NieDzejkob>guix doesn't like symlinks in the path to the store <NieDzejkob>there's also some clever stuff to make the store mostly immutable, even when you're root. Not sure how that works <GNUtoo>My use case is that GuiX has some support for Android, so I was thinking of using that to build locally libsamsung-ril (an Android component) to make testing way faster. I've already managed to package locally one of its dependency which has autotools, remains libnetutils libpower which aren't yet in GuiX + some includes. However when building it, <GNUtoo>/gnu/store/9nys9hz54r5j7wmv6dkgdqjsffihnw5y-libsamsung-ril-0.1 has only include/ with some headers. <GNUtoo>And I didn't find any documentation yet, or find how it worked by reading the source code <GNUtoo>For instance how does it pick which LOCAL_MODULE to build? <Noclip>NieDzejkob: How about using bindmount instead of a symlink? <GNUtoo>And is it possible to run some make command manually? <nckx>Noclip: Bind-mount /gnu. <nckx>That shouldn't interfere with /store. <nckx>If it does, it might be a fixable bug. <lfam>I'm trying `./pre-inst-env guix package -u isync` and it returns "guix package: error: Unbound variable: ~S" <nckx>Grr, Guix has suddenly forgot how to offload. It regularly freezes while or before copying the built items back, with both hosts seemingly idle. <nckx>lfam: I can reproduce that. <lfam>I'm guessing it's related to translations <nckx>Y'know, in case you forgot what the error you just reported looks like. <lfam>I think it said "guix package: error: Unbound variable: ~S" <lfam>Or maybe changes in (guix ui) <lfam>Well I'm going to try `make clean-go` now ***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<brettgilio>My new website will be up in a few days, will cover formal methods, guix, functional programming, and random other stuff I care about. :) <nckx>blackbeard[m]: I'm fine, thanks đ <akoppela>Anyone uses Guix at their company for anything? <bavier[m]1>nothing in production, but I use it to provide a bunch of development tools for myself and my group, via `guix pack` <GNUtoo>Hmmm, I've tried to narrow down the issue and tried to compile libsamsung-ipc with the ndk, and it packages only headers too <GNUtoo>make: Nothing to be done for 'all'. <GNUtoo>There is that in the ndk build system: <GNUtoo> (modify-phases gnu:%standard-phases <GNUtoo>install runs 'make install', but what make is it running? <GNUtoo>And what does it expects? a Makefile? <GNUtoo>Maybe I need to make the LOCAL_MODULE <bavier[m]1>there's an implicit `make` package in the inputs, it'll run that, which will expect either a `Makefile` or `GNUMakefile` <GNUtoo>make: Nothing to be done for 'all'. <GNUtoo>So I try to override the default target <GNUtoo>bavier[m]1: thanks, for some more background, I'm trying to understand how the android ndk build system works <GNUtoo>So there is probably a Makefile but the project that I'm building for trying that has none <GNUtoo>So it's probably some wrapper like android-make-stub that is used somehow but I've a hard time understanding how it all work <GNUtoo>(I'm just trying to use it to build some software locally without the huge Android dependencies) <GNUtoo>hmmm, /share/android/build/core/main.mk might be used <GNUtoo>ahh I need to sed to have stuff like BUILD_HOST_STATIC_LIBRARY <GNUtoo>(there are comments about cross compile not being supported) <GNUtoo>I've /gnu/store/kxcbsaydl87xi3r1jw2asgh8l4x4kbg2-libsamsung-ipc-android-0.1/lib/libsamsung-ipc.so.0 as an output <GNUtoo>Good, now I get the gist of it so I can try to package more stuff <GNUtoo>As the .scm I have is far from being ready to send upstream, I'll try to document and publish what I did in the meantime on the Replicant wiki somehow as soon as I've something <GNUtoo>(I use the last revisions for the software I'm packaging, and ideally I'd need to make a release to get a good revision) <nefix>hello! Is it possible to create a Guix image for Google Cloud? ***malaclyps2 is now known as malaclyps
***apteryx is now known as Guest93646
***apteryx_ is now known as apteryx
<kmicu>âShepherd exists for no good reason?â xD <efraim>civodul: works for me. Debian (and I assume others) have a patch for it but I was never motivated to make it work <efraim>it's not officially supported upstream <civodul>efraim: ok, i'll remove it from 'supported-systems' then <civodul>i will not comment the alternative sentence ;-) ***sputny1 is now known as sputny
<civodul>roptat: there is a typo in the latest fr PO file: "@comand" instead of "@command" <efraim>for the zram-device-service-type, I'm NOT documenting that (* 512 1000 1000) or (expt 2 30) works, just "512M" or 1024000 <apteryx>mbakke: I could successfully build inkscape for i686-linux. I think you said the build was failing on ARM? <apteryx>right, I think arm was affected as well. <apteryx>efraim: I've pushed a fix for plotutils (one of Inkscape dependencies) on master last night. We can fix it on master, then we'll have to merge master into staging before effecting the inkscape@0.92 to inkscape@1.0 replacement <apteryx>so you're welcome to give it a try on master :-) <NieDzejkob>qemu-binfmt builds are hanging for me. Things like sed or bash suddenly break and rack up 10 minutes of CPU time <civodul>efraim: just document it as "the size in bytes" <Tirifto>Hello! I installed Jami with Guix on a foreign distro (Parabola), but it crashes on start because it canât connect to the Jami daemon (dring). Has anyone else tried the latest Jami from Guix and did it work for you? <pkill9>it did that for me when i last tried it too <Tirifto>Do I reckon well that thanks to Guix being functional, the same Jami package working for someone would indicate a problem with the system, rather than the package? <Tirifto>Nice! Now to see if someone like that exists. :) <Tirifto>Great! pkill9 and Formbi, what OSâs are you running Guix on? <pkill9>it was updated within the last week <pkill9>i haven't tested the new package, i'll test it <hendursaga>What's a concise way of upgrading all the packages in my current, user profile? <hendursaga>I'm running guix pull and guix system reconfigure every day and not sure what other commands I should be running to keep my system up-to-date. <efraim>there's also 'guix upgrade' to upgrade packages in your profile <GNUtoo>hi, why are certain guix package in the source code but not available with guix package? <hendursaga>I'm running the garbage collector every few days, too. <GNUtoo>Example: git grep android-libcutils => gnu/packages/android.scm but guix package -s android-libcutils => nothing <pkill9>Tirifto: I got the error when running jami in a guix environment without having installed it to my guix profile, then i installed it to my guix profile and ran it and it worked, and when i rolled back my profile and killed the dring daemon, it again failed to find dring <roptat>GNUtoo, android-libcutils is not exported <roptat>usually this is for internal packages that a user don't need, for instance if it's a variant of an already existing package <Tirifto>Interesting⊠pkill9, Jami should be in my profile, but still crashes. Is your version â20200710.1.6bd18d2â? <GNUtoo>here too I can't install or see it <GNUtoo>For android-libcutils, i'll most probably change setup and use what is advised to use in the packaging videos to do modifications in git directly <roptat>mh... I can install, see and build it <lisbeths>My computer does not support libre-boot. <lisbeths>It does not have drivers on a libre kernel. <lisbeths>I need to install guix but put a nonfree kernel on it because I have no cohice because of money. <lisbeths>last time I asked to do this the people in here were very rude and said 'well we don't support nonfree software' <lisbeths>I hope that person dies peacefully in their sleep. <nckx>lisbeths: Please don't be rude. <apteryx>lisbeths: that's a worst thing to say. Please be kind to others. <lisbeths>I have escalated it to dying after a light cough. <lisbeths>It is not your business what my computing needs are on my own computer. <lisbeths>That is antithetical to software freedom. <nckx>That's why nobody was rude to you (I was here then đ), they simply excercised their freedom not to help you do something they think is bad for you. <lisbeths>Alright then I will continue to wait for a BSD version of your bullshit so I don't have to deal with your woke cuck soy attitudes. <nckx>Lol, now they're trolling word salad in #freebsd. <nckx>Is anyone else having trouble with (reliably) offloading lately? Transferring the build result at the end regularly hangs. <apteryx>nckx: July 20th Guix on my local machine, July 21st on my remote offload, works alright here. <nckx>This didn't start after an upgrade but I'll update everything just in case. <roptat>nckx, I had to disable offloading here because it made builds really slow to start (it would just hang before doing anything), but it could be that the machine I offload to is taking a long time to respond <apteryx>My wifi adapters doesn't show up anymore on a x200 laptop (using a ath9 based dongle). dmesg reports the USB dongle adapter fine. Anything else I should check? <nckx>apteryx: Try downgrading your kernel. The newest still has a bug that affects ath9ks. <apteryx>nckx: oh! that would explain it. I'll try rebooting in a previous generation. <nckx>apteryx: It's just a guess, but good luck. I'm sceptical that you'd run into this now since it's not a very new bug. <bandali>fwiw i did run into it on another distro with a recent kernel <bandali>i seem to remember that a fix was written and it'll be in an upcoming release <apteryx>civodul: I think I had redi from #gcc reply to your original question on the GCC mailing list :-) <apteryx>and were discussing it in #gcc, if you're interested <civodul>the answer above is kinda dismissive and not very informative :-) <apteryx>hmm, I think it's going back to the issue we had with ordering, where GCC devs consider it wrong that the GCC's own headers should appear in C{,PLUS}_INCLUDE_PATH. GCC knows to find its own headers without the help of adding them to the C{,PLUS}_INCLUDE_PATH (defined relatively to the configured --prefix and such), so adding them to C{,PLUS}_INCLUDE_PATH can only cause problems. <apteryx>here the problems is that the xgcc is looking up C{,PLUS}_INCLUDE_PATH for its own headers (it seems to override its internal known paths), which causes problems. <apteryx>and it picks up those of GCC@7 instead of its own <civodul>xgcc is built against the host gcc's libstdc++ <civodul>so that libstdc++-v3/configure script we're talking about is not looking for its own libstdc++, precisely because it's not built yet <apteryx>eh, if I understand correctly, only the host GCC (gcc@7 in our case) should need to know the location of libstdc++ headers, and it shouldn't need C{,PLUS}_INCLUDE_PATH to find those as it knows its location from the time it was built. ***ChanServ sets mode: +b *lisbeths*!*@*
***lisbeths was kicked by ChanServ (Banned: one of those cuck people)
<apteryx>and having exposed to even xgcc globally vial C_{,PLUS}_INCLUDE_PATH causes some unwanted interference with xgcc's own headers (which it should use). <apteryx>it seems we need a mechanism to stripe the headers GCC refers to internally (its own, probably glibc's, others?) from our system search paths <apteryx>that's not currently possible (or easy/cleanly doable) with our search-path-specification abstraction, IIUC. <civodul>and the thing is GCC is several packages in one: gcc itself, libstdc++, gomp, asan, etc. <civodul>GNUtoo: neat, it'd be great if this could be useful for Replicant! <apteryx>civodul: in #gcc redi suggests to "use options like --with-gmp to say where to find the host headers, instead of the env var". <GNUtoo>civodul: the thing is that we have huge issues with the Android build system as it cannot wrap software build system like autotools or Kconfig <apteryx>perhaps we could special case GCC and unset the C_INCLUDE_PATH/CPLUS_INCLUDE_PATH during its build, and explicitly specify the host includes locations. <GNUtoo>So ideally we'd like to ditch all that build system and replace it with something like Guix instead, but the issue is that (1) we're too busy to do it now, so it'll probably be attempted later if we can find time to do that <GNUtoo>(2) it would need maintenance, so we would need to bring many more communities onboard to help co-maintain it <GNUtoo>The huge advantage is that it would allow to mix Android and GNU/Linux way more easily <nefix>is there any way to only guix pull a specific channel? <GNUtoo>So in the meantime I'll try to use it to test parts of the stack <GNUtoo>And it's also due to the fact that I'm really attracted to Guix because everything seem to be done in the right way <GNUtoo>For instance in Parabola we have issues that are harder to fix because of the underlying design <GNUtoo>There are no wrappers class for build systems, instead you just add commands in a function, the advantage is the huge simplicity, so you can bring many more people onboard <GNUtoo>But you have less flexibility in general <GNUtoo>so some issues are harder to fix because of that <nefix>roptat: I've been doing some things to guix-home-manager, should I make a PR? <apteryx>civodul: but playing with the search paths inside the build phases is not ideal because it means we can't rely on the search paths computed by the search-path-specification mechanism to be correct (e.g., 'guix environment gcc' would no longer provide a correct environment to build GCC from sources) <civodul>GNUtoo: you're not the first one willing to build Android apps with Guix; if you come up with a proof of concept, that might be a good starting point for others to jump in <civodul>apteryx: i think we can special-case C_INCLUDE_PATH/CPLUS_INCLUDE_PATH in a build phase of gcc <civodul>i'm still not sure about the libstdc++-v3/configure issue though <apteryx>civodul: I was thinking trying to extend the search-path-specification so that we can filter based on package names <nefix>how am I supposed to fix a hash mismatch? <civodul>i like the simplicity of declarative search paths <apteryx>yeah, that's the downside. The upside being that search-paths for GCC would be sane everywhere. <apteryx>another approach we could take would be patching incpath.c <civodul>one could argue that GCC is not very sane when it comes to its build system, though :-) <civodul>i mean, it's a problem that we can't build the pieces separately <civodul>you want gfortran? you have to build the c/c++ frontends, libstdc++, a bunch of other libs, and finally the fortran frontend <civodul>it's ok for FHS distros: they just move files around <apteryx>we could patch the register_include_chains in incpath.c to give precedence to its stdinc, rather than append it after things coming from CPATH and the likes. <apteryx>that way it'd use the components it "knows" about itself. But yeah that seems to work only on FHS <apteryx>It's not clear to me; GCC is made up of many components, but in Guix, are these things living under the same place in /gnu/store, or not? <civodul>apteryx: i'm wary of fiddling with include search orders <civodul>experience has showed that it's risky ;-) <nefix>I've seen the guix download command, but it doesn't seem to support git :/ <civodul>apteryx: but we're not changing the logic <NieDzejkob>nefix: then you need to replace the hash in your package definition with the one guix prints as correct :P <roptat>nefix, send a PR, or send me a patch by email, whatever works best for you <nefix>NieDzejkob: hash mismatch for store item '/gnu/store/zv0cfa9lr0rnhw3gn0137jzmd1s3n474-vim-go-1.23-checkout' <nefix>NieDzejkob: it doesn't show anything else <NieDzejkob>nefix: huh, that's weird. Could you link to your package definition? <apteryx>civodul: I agree that having something consistent everywhere is nice, but it seems GCC is a snow flake w.r.t. how it handles includes dir (and perhaps excusably so... it uses a compiler to build another one) <nefix>NieDzejkob: I've pushed now, sorry <NieDzejkob>nefix: hmm, and what command are you using to build it? <NieDzejkob>(also, I'm surprised you need the go compiler as input, I don't think it will be picked up during build) <nefix>NieDzejkob: I wanted to add it as a runtime dependency, but it kept breaking the whole package, so I've deleted it now <apteryx>civodul: but yeah, I think as a first step modifying the GCC build phases to unset C_INCLUDE_PATH and CPLUS_INCLUDE_PATH is the low risk/low hanging fruit <civodul>apteryx: in fact we already do that in the adjust-CPLUS_INCLUDE_PATH phase <NieDzejkob>nefix: and what command are you using to build it? <nefix>NieDzejkob: guix home reconfigure home.scm <civodul>i forgot the details of course :-), but it's ineffective here <NieDzejkob>nefix: oh, I'd recommend using 'guix build' when you're experimenting with package definitions. It prints the entire log by default <NieDzejkob>(you can also bzless the /var/log/guix/drvs path being printed, but ehh...) <nefix>NieDzejkob: it says that it's not something that we can't build <nefix>also, in which subdirectory is located the log? <nefix>because it doesn't say anything about logs :/ <nefix>NieDzejkob: guix build -f channel/nefix/packages/vim.scm <NieDzejkob>nefix: that's because the file isn't returning anything. put the variable name on the last line of the file <nefix>NieDzejkob: I see! Now it's outputing the hash! <NieDzejkob>(guix build -f is best avoided for files that are part of a module hierarchy like the one in a channel) <apteryx>civodul: perhaps we'd just need to also manipulate C_INCLUDE_PATH like we're already doing for CPLUS_INCLUDE_PATH <apteryx>if that removes the need for the latest fixes it'd mean it's sucessfull :-) <nefix>guix is really fun to learn and makes way more sense than Nix :DDD <nefix>It feels waaaay more natural, and since it's a language, you can do literally everything you want with scheme :D <lfam>Glad to hear you are enjoying it <nefix>also, sorry if I'm being annoying this days asking so much questions :( <GNUtoo>civodul: I'm not really interested in apps, but more system components <lfam>nefix: No worries! People are here to help <GNUtoo>Basically the idea is to try to find use cases that are easier to work with to make it more and more useful <GNUtoo>so right now I'm already able to compile 1 package with an Android.mk <GNUtoo>(thanks to the hard work that went into guix and android-make-stub) <GNUtoo>But the more is packaged, the closer it is to be able to build apps <nckx>nefix: Ask them all! That's why #guix exists. <GNUtoo>or even to run Android apps on GNU/Linux <GNUtoo>So the next step in my case is to build 1 useful package, because right now the software that I was packaging (libsamsung-ipc) has almost 0 dependency and has also an autotools build system along with the Android.mk <GNUtoo>And to use that for testing to justify the time spent on it <GNUtoo>(and to bring more people to contribute and use it) <nefix>ok, so I've now successfully installed vim-go, but it tries to compile and install go binaries, and when it does, it fails to one like so: https://dpaste.com/B5JLJSEVM (all the others seem to install correctly) <nckx>nefix: So âguix install ⊠vim-goâ succeeds but the paste is what you get when running/installing it in vim? (Disclaimer: I'm neither a vim user nor a Go knower.) Does installing gcc-toolchain help? <nefix>nckx: yep, exactly. Let me see if it works... <nckx>It will put a working ld into your $PATH. <nckx>That *should* be enough to get to the next error đ <nefix>well, I have to go for a bit, let's see if it succeeds after this! :D <efraim>NieDzejkob: that's not a problem with rust. I'm building the toolchain again anyway to work through some of the TODOs anyway <mbakke>uh, that log file is truncated, hm <efraim>Er, sorry, tab completion got me <NieDzejkob>efraim: Ah, nice! You might want to bump openssl at the appropriate version, then <NieDzejkob>(is updating mrustc and skipping the first ten rustc versions something we want to do?) <Noclip>Just noticed that mozilla offers a distribution indipendent linux binary tarball for firefox on their website. Can't one install firefox just that way on guix system? <nckx>Noclip: Not out of the box. <nckx>No such thing as a âdistribution-indipendentâ dynamic executable. Just one that happens to work on the most common/popular ones. <Noclip>So one also has to install dependencies? <nckx>*independent, that was not a mocking quote. <nckx>Noclip: The dependencies themselves are in Guix, but the firefox executable looks for them in a hard-coded location (/lib). You can change the search location in the firefox binary using patchelf, or change actual the location on your system using the pasted snippet, which creates /lib symlinks to the store. <nckx>I guess you can also use LD_LIBRARY_PATH but I've not tried. <Noclip>With distribution independent I only meant that it's not a .deb file or something like that. <Noclip>Many websites offer a "general linux-download" but than it's just a .deb file xD <mbakke>apteryx: excellent, thank you :-) <nckx>Noclip: Not sure what's worse: that or âDownload for Ubuntuâ. đ <nckx>Noclip: The only alien binary I've ever run was Tor Browser. It worked fine on Guix System after some tedious patchelfing. That was a few years ago. *kmicu is still not sure whether Santa Claus is cool with us patching elfs constantly. <oogel>anyone running dwarf fortress on guix? <guixy>I have a channel for all the font packages I'll ever need <guixy>But gnome character map can't find some of them. <guixy>I tried fc-cache, but that isn't working. <guixy>I can't logout and log back in because I foolishly started a long install. <nckx>Dwarves, elves, what's going on. <nckx>guixy: Do they show up in fc-list? <guixy>I'm looking for the noto fonts <guixy>fc-list | grep -i noto; echo $? returns 1 <nckx>fc-list "Noto Sans" returns much here. <nckx>Stuff like /home/nckx/.guix-profile/share/fonts/truetype/NotoSans-BlackItalic.ttf. <nckx>Do any /home/nckx/.guix-profile/share/fonts/truetype/NotoSans* exist? <guixy>They are all in a dedicated profile. <guixy>$HOME/.other_guix_profiles/fonts <nckx>I wonder if we patch (only) $HOME/.guix-profile somewhere. <guixy>I pointed fc-cache there and it found stuff <guixy>But gnome-character-map doesn't show the glyphs I want. <guixy>I had it working a couple weeks ago. Then I reconfigured. <nckx>guixy: Did you have a custom fonts.conf? <guixy>Is there an environment variable I can set to search for fonts? <nckx>I'm unaware of any environment variables and not sure they'd be a good fit but đ€· <nckx>I'm just puzzled by your claim that this used to work out of the box with a non-default user profile directory. <nckx>We need to explicitly patch fontconfig with ~/.guix-profile/share/fonts to work, so how could that. <guixy>It looks like I can configure fontconfig to look in $XDG_DATA_HOME. Then I can have my script append my profile to XDG_DATA_HOME <nckx>I'm horrified but I can't claim it won't work. *nckx sings Let It Go, goes food-hunting. Good luck. <guixy>"FONTCONFIG_FILE is used to override the default configuration file." *nckx wonders if their dodgy ZNC connection and hanging offloads to the same server are related. <nckx>nefix: If building GCC is prohibitive install gcc-toolchain@7, (or) a random older version that does have substitutes available. <guixy>I got it working. I wrote a custom config and set some environment variables. <sneek>guixy, nckx says: Try setting FONTCONFIG_FILE to $HOME/.other_guix_profiles/etc/fonts/fonts.conf. <sneek>guixy, nckx says: âŠignore that, you found it yourself đ I'm lagging again. <guixy>Can FONTCONFIG_FILE contain multiple values? If so we can have fonts set that variable. <guixy>It looks like I have so many fonts installed that font-manager exits with a segmentation fault. <nefix>nckx: it just finished building and saw the message xD. Thanks anyway. Let's see if it works now <nefix>nckx: yep! That worked! Also, I needed to do the GUIX_PROFILE thing, it's working now :D <kelsoo5>welcome. awaits the flood of new users :-) <nckx>nefix: Cool. Eventually vim-go (or maybe even go itself, if that doesn't bloat the closure too much) can pull that it itself if it makes sense. What's âthe GUIX_PROFILE thingâ? <nefix>GUIX_PROFILE="/var/guix/profiles/..." and then source the GUIX_PROFILE/etc/profile <nefix>nckx: how should I add it as a runtime dependency for vim-go? <nckx>nefix: I don't know enough about vim plugins (=nothing) to say. If this were a classic /bin/foo executable you could use wrap-script or wrap-program to add gcc(-toolchain's) /bin directory to $PATH. That's probably not an option here. <nckx>Making it a propagated-input would work *for now*, but should be temporary. <nckx>If the right place to add this is in go itself, you could wrap âŠ/link. Or patch its source to refer to /gnu/store/âŠ/bin/ld directly. Both have the same effect. <nefix>yeah, the right place would be in go itself, since the package that's trying to build it's not from vim-go but an external Go package <nefix>so, if I want to add go as a dependency for vim-go (you need go in order to use the plugin), I should add it as a propagated-input?