<terpri_>(someone correct me if i'm wrong, it's been a while since i've worked with debbugs) <terpri_>(i've added it to my guix todo list, but it's already rather long; i still have lvm patches from 2018(!) to send in) <apteryx>haha, the guile test failure was caused by my tiny change <terpri_>apteryx, better than the alternative :) <Bryophyllum>terpri_: I appreciate your enthusiasm to help, but I think I'll pass on this one. More than anything, I eagerly await LVM support for boot devices on Guix ^^ <mbakke>I wonder if there is a clever trick to describe a pre-release such that (version>=? "2.6.pre" "2.6") would evaluate to #f (so guix realizes the proper version is an upgrade) <mbakke>I considered "2.5.99" but it feels wrong :P <ngz>mbakke: Isn't 2.6.pre exactly like 2.5-whatever on a specific commit? ***kmicu_ is now known as kmicu
<mbakke>ngz: yes, quite, I frequently just use the raw 'git describe' version in these situations, but in this case it's '2.5.0.07-7062-ga542a87a89' which is somewhat misleading <ngz>mbakke: I don't get why (git-version "2.5" revision commit) would be misleading. <mbakke>hmm, we'll need a 'cpp-for-target' to complement 'cc-for-target' eventually <mbakke>ngz: because it really is not anything close to 2.5 at this point, and users should not be lead to believe that :-) <terpri_>Bryophyllum, i'm typing from guix system booted from an lvm disk ;) so hopefully it'll be supported soon <mbakke>oh, the version comparison logic is taken from glibc <mbakke>I was about to hack (guix utils) to make "2.6.a" be considered a lower version than "2.6.0" :P <terpri_>Bryophyllum, i'll ping you when lvm is ready, the internal part is 95% done, installer support may take longer (i've never used the installer) <vagrantc>terpri_: i wouldn't wait till you have the installer working to push lvm support! :) <terpri_>who knew there were so many lvm fans ;) <mbakke>ngz: lol, it works against "2.6.0", but not "2.6" :P <vagrantc>and ffmpeg also used by something in diffoscope's huge dependency tree... <mbakke>vagrantc: I think the rust dependency in ffmpeg is optional? so you can probably just remove it <vagrantc>mbakke: it seems like ffmpeg is maybe even inappropriate for wlroots <vagrantc>unless there's some features it enables... <NieDzejkob>argh, mrustc-built rustc is crashing with SIGFPE on i686 <NieDzejkob>the instruction at fault is a fild qword ptr [esp], where the qword at esp is 1 <mbakke>vagrantc: does 'guix size wlroots | grep ffmpeg' return anything? <mbakke>NieDzejkob: you'll probably have better luck in #mrustc <vagrantc>mbakke: but i did remove it from native-inputs ... <mbakke>vagrantc: I checked on x86_64 and no references are kept, at least <mbakke>vagrantc: so we should both remove it from native-inputs, and remove the rust dependency from ffmpeg :-) <mbakke>I guess you'll want a browser and video player on that aarch64 system <ngz>mbakke: version 2.5.∞ <mbakke>ngz: lol, I like it! is that symbol in the ASCII table? I suspect utf8 is supported in versions, but maybe not external tooling <vagrantc>mbakke: netsurf is nice and fast ... but lacks something <vagrantc>mbakke: you also suspected some of the other native-inputs weren't correct? <mbakke>vagrantc: indeed, libcap and libpng can probably go too <terpri_>Bryophyllum, ah, very interesting. quite close to my solution, except i'm trying to avoid manual vgscan/vgmknodes calls as i think there's a daemon that handles that on other distros (could be wrong, it's been a while since i dug through the lvm source) <mbakke>vagrantc: webkitgtk, qtwebengine and ungoogled-chromium should work on aarch64, but unfortunately no icecat yet <vagrantc>mbakke: libcap and libpng are in guix size wlroots... <ngz>mbakke: not it is not in ASCII table. There, it degrades (gracefully?) into 2.5.oo ! ;) <vagrantc>doing a quick test using --with-input ... <mbakke>vagrantc: but probably because they are in the closure of other packages, and not used directly by wlroots <nckx>raghavgururajan: 88% and ticking. 🤞 <vagrantc>mbakke: they're build-depends for the Debian wlroots packages... don't have as high hopes there <mbakke>ngz: I'll just go with '2.6.dev' for now, despite guix being unable to recognize the eventual 2.6.0 upgrade... too late for bikeshedding! :P <vagrantc>reading the rationale for removing libpcap probably removes my favorite feature of sway ... being able to start it from a terminal with no display manager <vagrantc>or maybe the (e)logind support will still work <mbakke>vagrantc: I don't think it's used in Guix? is it possible to set capabilities on store items? that sounds like a serious vulnerability <mbakke>'unable to set CAP_SETFCAP effective capability: Operation not permitted' in the build container, phew <pkill9>they're removing that ability? damn <mbakke>aw, I'm not able to use setcap in a 'guix environment --container -u root' either :P <vagrantc>pkill9: i think it's removing a legacy way to do that ... i think it still supports the elogind method *vagrantc will find out in a moment <nckx>raghavgururajan: /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh: glib-compile-resources: command not found <nckx>You probably need a ("glib:bin" ,glib "bin") native-input. <vagrantc>ok, with libcap and libpng removed ... sway still seems to be working ... <NieDzejkob>rekado: is it me, or did cuirass-web die on berlin again? *vagrantc will follow-up with the ffmpeg and wlroots issues later... <terpri_>aha, the lvm metadata daemon needs a config file tweak to work. getting closer... <hendursaga>Can someone point to a good Guix config repo that involves setting up web servers? <clodeindustrie>hey, Should I be able to find the X11 config files in /etc/X11/... or is it somewhere else? <NieDzejkob>clodeindustrie: I don't have a /etc/X11 on my machine <wdkrnls>Would anyone be interested in packaging Zim Desktop Wiki for Guix? I wanted to package it so I could point my significant other to something remotely like OneNote but which is Free Software. I saw it wasn't packaged and originally hoped maybe it was going to be dead easy to package (which sadly are the only ones I know how to do). <wdkrnls>error: option --single-version-externally-managed not recognized <wdkrnls>command "python" "-c" "import setuptools, tokenize;__file__='setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\\r\\n', '\\n');f.close();exec(compile(code, __file__, 'exec'))" "install" "--prefix=/gnu/store/2qgk0p0pmdd4gb3ikwyg7f00qc3wwdyh-python-zim-0.73.1" "--single-version-externally-managed" "--root=/" failed with status 1 <wdkrnls>Some earlier warnings popped up after 'starting phase `install': <wdkrnls>running "python setup.py" with command "install" and parameters ("--prefix=/gnu/store/2qgk0p0pmdd4gb3ikwyg7f00qc3wwdyh-python-zim-0.73.1" "--single-version-externally-managed" "--root=/") <wdkrnls>Environment variable $HOME does not point to an existing folder: /homeless-shelter <wdkrnls>Unable to init server: Could not connect: Connection refused <wdkrnls>XDG_RUNTIME_DIR is not set, using /tmp/guix-build-python-zim-0.73.1.drv-0/zim-homeless-shelter as a fallback <wdkrnls>usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] <NieDzejkob>wdkrnls: try setting #:use-setuptools? #f in the arguments <wdkrnls>cool! that plus #:tests #f got it through the build. <wdkrnls>I did that because it spit out at me: <wdkrnls>command "python" "./setup.py" "test" failed with status 1 <NieDzejkob>so, looks like the non-x64 rustc bootstrap is not as simple as I thought, I'll wait for mrustc being able to compile 1.39 <terpri_>NieDzejkob, what's not simple about it? (curious because i want to use rust on power9) <terpri_>NieDzejkob, just the incredibly long build times, or something worse? <NieDzejkob>ouch, power9? That's not even a target normal rustc supports <NieDzejkob>right now, the issue is that mrustc on i686 makes binaries that overflow the FPU stack <NieDzejkob>the github issue for this mentions that newer versions have had many improvements and maybe the issue is gone <NieDzejkob>(wait, maybe it is supported. is power9 and powerpc the same thing?) <terpri_>powerpc is an old standard used for powermacs etc, power9 is the current version of the cpu architecture (same cpu family) <terpri_>firefox runs on talos boxen, so rust must be supported somehow...or they're using a truly ancient version of ff :) <terpri_>dunno, my talos blackbird is in pieces atm <raghavgururajan>sneek, later tell nckx: On my end, wpewebkit fails with "c++: internal compiler error: Terminated (program cc1plus)". <NieDzejkob>that's still a better state than any of my power machines ;) <raghavgururajan>Anyone else have any idea about this error "c++: internal compiler error: Terminated (program cc1plus)" ? <terpri_>ppc64le is what uname calls the cpu fwiw (except for those few brave souls running their power workstations in big-endian mode :)) <terpri_>raghavgururajan, any oom killer activity in dmesg? i've seen it before but don't remember the root cause <mroh>raghavgururajan: webkits need tons of ram to compile... so, "internal error" could be an oom, maybe <raghavgururajan>sneek, later tell nckx: When you get a chance, could you rebuild wpewebkit with glib:bin and gobject-introspection as native inputs? Thanks! <terpri__>til users with the CAP_SYSLOG capability can run dmesg w/o sudo <terpri__>maybe i'll try that, i've always found the sudo requirement annoying since they added it <bdju>oh yeah, needing sudo for dmesg and a few other commands like reboot is pretty annoying. I think my arch machines don't need sudo for that, but debian and guix system do <bdju>also kinda hate that guix system lacks "poweroff" and I have to do "sudo shutdown" instead <terpri__>raghavgururajan, that doesn't look great <terpri__>("Core temperature above threshold, cpu clock throttled (total events = 54118035)" and the like repeated dozens of times for those who didn't click through) <terpri__>raghavgururajan, do you have adequate cpu cooling, or is this on a laptop or something? <mroh>raghavgururajan: how much swap do you have? i dont think 8GB ram is enough to compile any webkit with -j2 <Gooberpatrol66>I can't manage to edit any services that I've tried. I keep getting "guix system: error: duplicate entry for /etc" ***terpri__ is now known as terpri
<lispmacs>does somebody have some kind of script that produces those thousands of rust packages, or are they created manually? <lispmacs>homepage gemini://gem.limpet.net/agate/ :) <bdju>one of these may help answer <bdju>I think there are tools to assist in making packages for certain langs that have a lot of packages, though I'm not a packager myself <bdju>oh yes that looks like the right thing <malaclyps>I'm fascinated by how guix wants me to install the same (large) set of package (including ghc, and mesa, and cups) on all of my machines (which roughly have the same manifest) whenever I try to upgrade any package. Is this because of urgent security updates, or something? Here's an example: https://paste.debian.net/1153022/ <malaclyps>This surprised me, because I assumed package installs just installed any necessary dependencies <janneke>malaclyps: that looks less than great; i believe your assumption is correct; it may be that your assumption about what "necessary depedencies" could be are not how guix currently defines them <janneke>iow: i think it's unfortunate that less pulls gtk and ghc <janneke>i would love to see some dependencies cut there <mange>janneke: Does it? It only has gnu-build-system and ncurses for its inputs. Do they really pull in GTK and GHC? <malaclyps>i don't think it's less pulling these things in, because any package i try to install does the same thing <malaclyps>right -- I picked less because I figured it had a very small dependency chart <janneke>malaclyps: right, what if you add --no-grafts? <mange>I can't explain what you're seeing, malaclyps, but I agree with your intuition that it seems wrong. Guix shouldn't automatically upgrade the software in your profile when you install other packages. As far as I'm aware it doesn't. <malaclyps>i mean, these are not crazy dependencies for my profile as a whole -- I have pandoc installed, which often pulls in ghc, for instance <janneke>ah, right. then the question becomes rather: why does installing less /upgrade/ your profile's pandoc <malaclyps>janneke, I mean, it's a clue to what might be going on <janneke>indeed, that's what i meant to say -- it's helpful information <nckx>raghavgururajan: OK, building. You should keep an eye on your CPU temperature the next time you build webkit/it's under heavy load (i.e. you get these throttling messages in ‘sudo dmesg --follow’). You can use ‘sensors’ (after running ‘sensors-detect’) from the lm-sensors package, or (I guess) whatever graphical applet your desktop provides. <sneek>Welcome back nckx, you have 2 messages! <sneek>nckx, raghavgururajan says: On my end, wpewebkit fails with "c++: internal compiler error: Terminated (program cc1plus)". <sneek>nckx, raghavgururajan says: When you get a chance, could you rebuild wpewebkit with glib:bin and gobject-introspection as native inputs? Thanks! <nckx>I dreamt about a Malaclypse tonight; weird. <NieDzejkob>Gooberpatrol66: you might beed to use (modify-services) for that <NieDzejkob>something like (modify-services (alsa-service-type config => (alsa-configuration (inherit config) (pulseaudio? #f))) ...) IIRC <asdkfadslfjasd>guix pull: error: Git error: cannot locate remote-tracking branch 'origin/keyring' <asdkfadslfjasd>I fork and then modify the guix, and then the recent update has such a problem, how should I fix it? <civodul>your fork doesn't have material to allow "guix pull" to authenticate it <civodul>in particular, it lacks a "keyring" branch <civodul>if you want, you can pass --disable-authentication, understanding the implications <asdkfadslfjasd>It seems that to solve this problem forever requires me to understand the new guix. <nckx>malaclyps: We were exposed in the countryside with a menacing hurricane approaching fast. Luckily we were accompanied by Malaclypse, a might dragon, and planned to ride upon their back to safety. It took us a few attempts to realise this would not be an option because Malaclypse was the size of a large house-cat, because dream logic. <nckx>NieDzejkob: You mean 32-bit ARM machine, right? <asdkfadslfjasd>Where should I get this branch? It looks like github.com/guix-mirror/guix does not have it. <nckx>asdkfadslfjasd: Why not? (You're right, it seems to be missing from the mirror; that's not great.) <NieDzejkob>nckx: either would be helpful, although my understanding is that a 64-bit one can run 32-bit binaries too <asdkfadslfjasd>Although I like Guix so much, because of the ISP's QOS, I need to enable --disable-authentication to make it work until I understand the source code of the new feature. <asdkfadslfjasd>nckx, Due to regional issues, the ISP here seems unfriendly to Guix's IP. <nckx>That's a quick & dirty ‘mirror’ of keyring & master branches. <nckx>In quotes because I don't know how to set up a proper mirror using GH. <cbaines>I've found a confusing derivation... I thought one could build a derivation if for all the specified inputs, the indicated outputs were available in the local store <cbaines>I think that's the case with the derivation I've got, but Guix claims it'll have to build ~80 other derivations as well, which I don't understand... <cbaines>What else do you need in your store to build a derivation, apart from the derivation itself, and all the required outputs for the specified inputs? <NieDzejkob>maybe it remembered that these paths come from a substitute and it wants to rebuild them because of --no-substitues? <nckx>Or (previously directly substituted) grafts…? <NieDzejkob>but why would the paths exist then? grafts get different hashes, no? <cbaines>There shouldn't be anything to do with grafts for this derivation <cbaines>I've tried saying it can fetch substitutes, but just not from where one is available: guix build --dry-run --substitute-urls=https://data.guix.gnu.org /gnu/store/mafs37vw7k65ah071p8f080c9y1y3l7n-bbmap-35.82.drv <cbaines>But I get the same result, Guix says it needs to build lots of things for some reason <cbaines>NieDzejkob, how confident are you that Guix remembers that outputs came from substitutes, and ignores them if you tell it to build without substitutes? <cbaines>That seems impossible to me, as the guix-daemon would have to remove the store item from the store, before it could replace it with something it built locallyt <nckx>raghavgururajan: How much RAMs does your X200 have? <civodul>would be nice to have it regularly updated since it seems to be expected <civodul>cbaines: data.guix.gnu.org provides substitutes only for .drv files, right? <civodul>in that case, you should also add ci.guix.gnu.org to your substitutes <cbaines>If you're referring to the above command, I was just testing whether the behaviour was consistent between providing --no-substitutes, or a substitute server without any relevant substitutes <cbaines>The problem I'm trying to solve is why I can't understand why Guix thinks it can't build the derivation I've asked it to, and thinks it needs to build other things first. <nckx>No need for the ‘temp’ hack now. *nckx torn between asking mbakke nicely to share the creds for the ‘guix’ GH account vs. not endorsing that mirror in any way by doing so. Thoughts? <mbakke>nckx: currently that mirror is on my own user account. I've been meaning to migrate to a dedicated account since forever. <mbakke>the mirror script also run on a server I control, we could perhaps migrate it to berlin? <mbakke>I set up the mirror because I heard some countries are unable to access savannah, but GitHub cannot be blocked because it is so widely used <nckx>That was exactly asdkfadslfjasd's problem. Also one of few legitimate reason to support it (vs. putting one on berlin, another plan once had) IMO. <nckx>So there's no way to configure GitHub to ‘mirror this’ without an external script? Schade. <nckx>I must be thinking of GitLab. <mbakke>nckx: I asked GitHub about migrating to their built-in mirror system, but they could only update it once a day, which was not good enough IMO. <mbakke>I'll ask GitHub again soonish, perhaps things have changed in the last two years <nckx>raghavgururajan: So you really want 16 GiB of RAM to compile wpewebkit (and probably every other 💩Kit derivative), *and* swap (your OS needs to hide somewhere while WebKit takes over your machine!). I managed to build it 8 GiB RAM + 16 GiB swap + zstd zswap, but I can't recommend it. It's all one final linker process so --cores=1 won't help. It failed, by the way: http://tobias.gr/y5sziqc7w3q4fbfqb2qphns84az0zw-wpewebkit-2.28.2.drv.bz2 <mbakke>so ebtables is deprecated, and nftables still can't do NAT on bridges, great <mbakke>proxy ARP to the rescue, I guess *mbakke works on single-machine Ganeti cluster setup/blog post <nckx>raghavgururajan: It failed with the (.bz2) log file I pasted above. Missing symbols <NieDzejkob>cbaines: did you figure out what the deal with that derivation was? <cbaines>I'm not sure if it's something odd about that derivation, or something else <cbaines>But I'm definatly not understanding what's going on :( <nckx>raghavgururajan: I'll start a build without woff2… <nckx>Even with "-DUSE_WOFF=OFF"? <nckx>Could NOT find WOFF2Dec: Found unsuitable version "", but required is at least "1.0.2" (found WOFF2DEC_INCLUDE_DIRS-NOTFOUND) <nckx>raghavgururajan: I meant USE_WOFF2… <nckx>See Source/WebCore/CMakeLists.txt. *nckx fixy typo try again. <nckx>raghavgururajan: Thanks for the mirror. Does it use your personal account/password? Would it be possible to share access amongst Guix maintainer(s)? <raghavgururajan>nckx: Oh yeah, it is mentioned there. But shouldn't there be a line `option "USE_WOFF2"`? <raghavgururajan>nckx: I have created them under organisation. I can add you all as owners, provided you have account at git.disroot.org. <nckx>Golly. I created a disroot account once, now I need to remember what it was… <raghavgururajan>At this moment, git.disroot.org is not integrated into Disroot's LDAP account management (user.disroot.org). It will be soon. For now, dediacted accounts can be created on git.disroot.org. It is recommended to use same username as used in user.disroot.org, so that account migration/linking can be done in future. <nckx>raghavgururajan: OK, I fiddled out my password and created a git. account. User name is nckx. ***davidpgil1 is now known as davidpgil
<bricewge>Is there a generic way to apply a patch serie to a package? <lfam>bricewge: Maybe not generic but check what happens for Bash <bricewge>lfam: readline.scm does have something similar <bricewge>It would be nice to have a helper doing a similar thing <raghavgururajan>bricewge, I would clone package's repo, apply all the required patches, format-patch to generate single patch and apply it to package's definition. <bricewge>raghavgururajan: Yeah, better go the quick way, I'll do this! <nckx>raghavgururajan: Thanks! <nixfreak>does anyone know how to add libgcc I already installed gcc-toolchain , <mbakke>bricewge: the 'ungoogled-chromium' source derivation applies patches from a debian/patches/series file (with some filtering). Not very generic, but not too complicated either. <NieDzejkob>nixfreak: This is the kind of thing you'll need to include in /lib with special-files-service-type <NieDzejkob>Guix is not really intended for downloading random binaries off the internet, so you'll need to customize your operating-system a bit to make it work <nixfreak>ok so this is what I did (service special-files-service-type `(("/lib" ,(file-append gcc "/lib")))) <nixfreak>ok so this is what I did (service special-files-service-type `(("/lib" ,(file-append glibc "/lib")))) <nixfreak>I don't have /lib but I have ~/.guix-profile/lib ***sneek_ is now known as sneek
<nixfreak>ok running it right now , just take for ever to build linux kernel <nixfreak>ok running it right now , just take forever to build linux kernel <NieDzejkob>thankfully that's cached, so it's not necessary to wait for that with every reconfigure, but only when a new version is shipped <NieDzejkob>pinoaffe: Since all users can read the password from the store, what's the point? <NieDzejkob>I'm not too familiar with mpd, sorry if I'm missing something <nerthus>does anyone here use Guix with Void? <nixfreak>whats wrong with this (use-modules (gnu packages gcc) (nongnu packages linux) (nongnu system initrd)) <nixfreak>it worked just fine with everything but packages gcc ? <lfam>NieDzejkob: Remote users would not be able to read the password. It's usually accessed over the network <lfam>Usually mpd runs on a server connected to the sound system, and clients connect to control what is playing <NieDzejkob>nixfreak: Are you sure you didn't remove any other imports? <NieDzejkob>(use-modules (gnu)) imports gnu.scm, (use-modules (gnu packages gcc)) imports gnu/packages/gcc.scm <nixfreak>ok , i'm remote now with my kid of hockey I will jump on later , appreciate the help ***jonsger1 is now known as jonsger
<pinoaffe>NieDzejkob: mpd is a usually accessed over the network, this patch makes it so you don't give everyone with network access mpd control (but yeah, anyone on the same machine could gleam credentials from the store) <pinoaffe>I'm still waiting / hoping for a good, generic way to handle credentials in guix, but for now this'll have to do :) <NieDzejkob>pinoaffe: on Guix Days, a conclusion was reached that it'd be best to let the user point to a file outside of the store that will store the secrets <NieDzejkob>not all services support this cleanly, we could have a campaign of upstreamable patches to fix this <NieDzejkob>another usecase that benefits from this is a public dotfiles repo, so it's not too esoteric <NieDzejkob>I'm mostly looking for a maintainer that could smoketest and push that patch <jgarteeeeeeeeee>Just wanted to announce that libremiami.org is hosting a Guix Virtual Watch Party at 16:00 EST. If you'd like to watch some guix videos with us and chat come join us! Here is the playlist we'll choose from: 1. Towards reproducible Jupyter notebooks2. Introduction to G-Expressions3. How Containers and Kubernetes re-defined the GNU/Linux Operating <jgarteeeeeeeeee>System A Greybeard's Worst Nightmare4. Practical, verifiable software freedom with GuixSD5. Building a whole distro on top of a minimalistic language The story of GNU Guix6. Guix: Unifying provisioning, deployment, and package management in the age of containers7. Hacking on Guile, Guix, Sway/Wayland status bars, talking to myself about 90s <atw>NieDzejkob: I use emacs, I gave the linked patch a quick test <pinoaffe>NieDzejkob: letting the user point to a file outside of the store the secrets would mean the service would need to be changed so that the config file is regenerated every time the service is started, that doesn't seem very clean <NieDzejkob>pinoaffe: or an include directive could be added to mpd's config system <atw>I'm not a committer, just want to help get Joseph's work merged :) <nckx>jgarteeeeeeeeee: I'll be driving, but I love it! Thank you 🙂 Will there be a recording? <atw>jgarteeeeeeeeee: jit.si tells me "It looks like you're using a browser we don't support." Is there something I can do to trick jit.si into loading the application? <raghavgururajan>atw: Are you using Icecat? Unfortunately, it doesn't work on Icecat. But works on ungoogled-chromium. <nckx>jgarteeeeeeeeee: Only if it's not too much trouble. I'd certainly watch a recording. <jgarteeeeeeeeee>atw: I'm going to record the guix watch. I'll upload the recording to #libremiami:matrix.org <atw>thanks all :) and thanks for putting this together jgarteeeeeeeeee <raghavgururajan>jgarteeeeeeeeee, atw: In IceCat, media.peerconnection.enabled is already set to true. But doesn't work for some reason. It definitely works on ungoogled-chromium. `guix package --install ungoogled-chromium` <atw>hehe yeah I also checked media.peerconnection.enabled and found the same *nckx thinks they've joined #libremiami (utter Matrix noob) <jgarteeeeeeeeee>raghavgururajan: Last time I installed ungoogled-chromium it failed to run but maybe I should try again <bonz060>Hi. I've just installed GHC and cabal-install from GUIX, but any time I try to use cabal .e.g. `cabal install -n`, I keep getting: `Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times)`. How do I fix this? Anyone have any idea? <bonz060>Found the problem. Turns out that the version of cabal_install packaged in guix is really old :(. What is packaged is v2.4.0.0 but the latest upstream version is 3.2.0.0 :( <bonz060>NieDzejkob: That's what I want to try out. I'll tell you in a few <nixfreak>Ok does anyone know good scheme checker for parens ? I'm using vim , but if there is an online one I'll use that also <NieDzejkob>not a checker, but rather a mode that doesn't let you fsck em up in the first place <nixfreak> ok so if nvim (neovim) is in /share/nvim/ but everything in there is root , do I need to copy that out into ~/.nvim instead , I'm trying to copy vim.plug into /share/nvim/runtime/autoload and its read only? <nixfreak>this is way different then a regular nvim install <NieDzejkob>there's no "share" directory in / on my install, wdym? <NieDzejkob>~/.guix-profile/share (or /usr/share on normal distros) is for distro-managed things (plugins, etc), and ~/.nvim is for things you install yourself <bonz060>NieDzejkob: I've updated things but that doesn't seem to fix anything :( <NieDzejkob>I've read about the problem before but can't figure out where <nixfreak>place plugins in ~/.config/nvim/plugged and ~/.config/nvim/autoplugged ***ChanServ sets mode: +o nckx
***ChanServ sets mode: -o nckx
<bonz060>NieDzejkob: I've given up on cabal. It seems to hacky. I'll use stack. Is there a guix package for it though? <nixfreak>I think its correct , now I have to wait for kernel to get phased again ***ChanServ sets mode: +o nckx