<quiliro>ok...but you will learn more if you repair
<quiliro>adom`: even if it does not work, finding the structure of things is a great learning experience
***card.freenode.net sets mode: +o Sigyn
***grubles is now known as Guest48292
***jamesrichardson is now known as Guest91833
***Guest64341 is now known as nalkri
<jgibbons[m]>I have two drives in my computer. I want to use one as my root and one as my /home. ext4 doesn't like links between separate drives. Will this cause trouble with my profile ($HOME/.guix_profile or something like that)? If so is there a known workaround?
<erudition1>I've never heard of that issue with ext4, and I don't know the answer, but I do know that btrfs is supported and works well, with a lot more useful features
<erudition1>Less of a workaround, more like making the problem irrelevant heh
<nckx>When running any Guix command that builds anything, Guix will connect to all remote nodes and should print something about their ‘normalised load’ (which is the remote load divided by that machine's parallel-builds). If it's over 2 the machine will not be used. Are all your machines highly loaded?
<alloy>I've got a normalized load of 0.08, doesn't seem to overloaded :D
<efraim>sneek: later tell ng0 libgit2-sys can almost link to libz which can link to libc, but libgit2-sys doesn't like that libz isn't linked to the vendored libc source it's using, so that's where I'm stuck for now
<efraim>I also just learned that as part of cargo's 'cargo build' command it creates a Cargo.lock file, so we can get rid of the 'update-cargo-lock phase from the cargo-build-system and move the deletion of Cargo.lock to another phase
***Guest48292 is now known as grubles
<civodul>efraim: oh, you should ping Ivan, Robert, and all on the list
<nixo_>rekado_: hi, thanks for the guix-artwork merge! Do you know how frequently the website is generated (i.e., when the packages.json will be available)?
<nixo_>hi civodul! Thanks, then maybe something is not working (or am I checking the wrong url)? I'd expect after 9c6f714305460e99c681d9b7f368e13bfe49fdd9 was merged to see this page: https://guix.gnu.org/packages.json
<chrislck>further noob questions: guix install allegro --> long compile; guix remove allegro; guix gc; guix install allegro --> quick. does this mean allegro compiled to my cpu is now cached on ci.guix.gnu.org?
<efraim>it means that there wasn't a substitute available on ci.guix.gnu.org so you built it locally. when you removed it and re-installed it, it was already cached in your /gnu/store directory.
<efraim>all the packages on ci.guix.gnu.org are built on the build farm behind ci.guix.gnu.org
<chrislck>so it means /gnu/store will grow steadily with time, unchecked
<efraim>until you run 'guix gc', to remove the unreferenced packages
<chrislck>well see my post above; guix gc should remove the built allegro shouldn't it?
<efraim>I normally use 'guix gc -F 50G' to remove packages until I have about 50GB of space available on my drive
<efraim>the above allegro is likely still referenced by a previous profile generation so it won't be removed yet
<minall>What are the steps to package kde? any idead?
<nly>i suppose there would be several sub packages, some core ones, and some peripheral ones
<nly>there might have been some previous work on kde which might help
<nixo_>civodul: I'm on a clean checkout of guix-artwork 9c6f714, guix --version = f5111 (slightly newer than yours). But still guix build -f .guix.scm does not work. Did on 2 different machines (other has guix version 3251c628f754). Is it "cd guix-artwork/website; guix build -f .guix.scm" ? I don't get why our results differ
<civodul>nixo_: that's because ".guix.scm" refers to the 'guix' package, and presumably yours uses guile-json@1 whereas mine uses guile-json@3
<xavierm02>Hey. So by removing the texlive-union from the propagated inputs of the lyx package, everything seems to work fine (i.e. if you don't have texlive / texlive-bin lyx runs but when you try to export to pdf there's an error, and if you have them everything works)
<xavierm02>The problem is: I don't know why this texlive-union was ever added...
<nixo_>civodul: ok I can confirm that my guix package --show=guix is at version c902458863, the commit before the move to json3 (2eb0628a42)
<civodul>xavierm02: hi! texlive is probably required by lyx, but the problem might be that it shouldn't be propagated, no?
<xavierm02>civodul: Well to edit files, you don't need it. I'd think of texlive as "recommended" for lyx, but I don't think there's "recommended" in guix
<xavierm02>civodul: Also, the reason I want to remove the texlive-union is that if it's here, LyX uses it, so that even if you install the full texlive, it'll only find stuff from the texlive-union
<civodul>is it on Guix System or on another distro?
<nckx>I got that a few times on a few systems, removing that directory and running ‘guix pull’ again fixed it.
***dongcarl_ is now known as dongcarl
<nckx>You'll have to ’readlink -m $(which guix)’ before that to print the full path of the guix you'll have to run.
<adom`>Hi! I'm installing on a foreign distro. Thanks nckx. I'll try that!
<rekado_>xavierm02: I think I added it back then. That was part of the move from the monolithic texlive package to the much smaller texlive-union. I remember that TeX Live was required at build time. Perhaps propagation is wrong here.
<rekado_>I’m still working on a fix for our modular TeX Live (found another problem with our font maps)
<rekado_>I’ll create a new branch for the fixes soon.
<rekado_>there’s just one more odd problem now that the font maps are fixed (it doesn’t find any Latex files any more…)
<adom`>It seems like there's something wrong with the permissons for guix? Is there something I can do to check that directly? Or change it? Or a stage in the installation process I should take a closer look at?
<nckx>adom`: No explanation of *what* it was trying to mkdir? :-/
<adom`>Oh sorry. It has this first: Migrating profile generations to '/var/guix/profiles/per-user/adom'... Nothing else though.
<nckx>adom`: /var/guix/profiles/per-user/adom should be owned by adom:adom.
<jlicht>annoying thing is that you have to do it for all guix profiles (so in your case both root and adom)
<adom`>Even if it's the root version of guix pull? I'm worried that it won't work for adom after this.
<jlicht>I have never had good experiences with having a separate root profile when using guix, so I can't help you there
<adom`>Cool cool. I'll check out the link after this finishes. Thanks :)
<adom`>Man. IRC is really so amazing. I need to find some channels where I can be helpful.
<nckx>adom`: I'm not a fan of running ‘sudo guix pull’ either (because in 99% of cases it doesn't do what people thought it was for), but if it gets you a working Guix now I'd say that's a win & we can fix the permissions later.
<nly>i don't think i've run 'sudo guix pull' in months, i just use the user profile
<nly>'sudo -E guix something' when you need permission, only reconfigure needs that in my usage
<nckx>nly: I've never run it, period. Why did you? Just curious what its use cases are.
<nckx>adom`: Ah, at least that gives us a clue! Seems like something (maybe ‘sudo guix’) created your user's ~/.cache/guix as root. Since it's a cache, you can just ‘sudo rm -rf $HOME/.cache/guix’ and try again.
<nckx>It should at the very least print a different new & exciting error message, or you might even get lucky.
<adom`>I may have messed things up. After using that guix variable once, it doesn't seem like I have access to it anymore.
<adom`>I'm getting the same "something is happening" thing as before. Just a laggy terminal so far
<adom`>I'm embarrassed. I probably should have said earlier that I've installed and uninstalled guix a few times today and yesterday trying to get this to work. I followed the directions on the Arch wiki and I thought I was removing every trace. But I guess there was stuff in the cache.
<adom`>Wow, it really seems to be working. Incredible.
<nckx>If it does, run a plain ‘guix pull’ (no $) just to make sure all new paths are properly set up.
<adom`>What's the appropriate thank you in situations like this? Donate to guix? Some charity you like? I really feel like I could have struggled with this for days and maybe would have just given up. I read so many email threads and irc logs and didn't see anything about the cache.
<adom`>Just sent $10. Thank you so much for your help. And patience. And everyone else too.
<dwdv>Hello everyone! Say, except for non-free firmware /wireless, what else would I be missing when switching over to guixsd from fedora? ffmpeg and such seems to by included.
<dwdv>Also, is guix supporting something similar to freebsb's port flavours, where a pkg has different build options (e.g. no perl support in urxvt), so multiple binaries are build, not just the main one?
<dwdv>Are vim and vim-full the exception or does this happen more often?
<nckx>dwdv: Missing: hard to tell, Guix has just over 10k packages but it's still easy to find that one killer app that we're missing.
<nckx>dwdv: Flavours: Some packages have a -full or more often a -minimal variant, but those tend to be added in an ad-hoc manner when someone needs them (e.g. emacs-no-x), not systematically.
<nckx>I'm sure we have far less of those than FreeBSD.
<jlicht>dwdv: if you know some guile, you can rewrite parts of the dependency graph of a package programmatically, (which is usually how we support python2 variations of python packages, if you are interested in an example), but this is by no means as 'easy' as using ports.
***psachin is now known as psachin|away
<minall>I need to make a reconfigure of my GuixSystem installation, but I can only do it from the live-USB
<quiliro>if the efi partition was not mounted, on boot GS will not boot...what must i do if i have this problem?
***len1 is now known as lenn
<minall>How should I do it? I mounted my installation on /mnt, and then my boot device on /mnt/boot, does chroot /mnt and -guix system reconfigure- works?
<quiliro>i am helping minall...my problem is minall's problem
<dwdv>nckx, jlicht: thanks for the info, will make sure to read the packaging tutorial. Regarding missing packages: not so much about the obscure ones that you use once a leap year, more about hardware acceleration support and stuff that's impacting the desktop experience.
<dwdv>Guess I'll just give it a spin, thanks again.
<bandali>hi guix, does anyone have a guix channel for using org master?
<rschifflin>hey channel, i just received a pinebook so i can finally build myself a guixbox =)
<rschifflin>whats cool is that amazon even provides arm-based ec2 instances now so i can build an installation image in a reasonable amount of time
<rschifflin>i have hit a problem though- apparently the linux-libre kernel that gets compiled when specifying `pinebook-installation-os` is erroring out trying to make some arm-neon intrinsic with some type alias collision. Here's the actual log output: https://pastebin.com/drKPqBAa
<rschifflin>anyone have any experience building guix for arm? would it be straightforward to modify my installation file to set `CONFIG_KERNEL_MODE_NEON` to `n` as a bandaid to build without the conflicting files
<ngz>Maybe the best way to move forward is to start writing such examples, even if they are inaccurate or plain wrong, in a wiki fashion, and improve them later.
<ngz>I mean, it is simpler for a knowledgeable person to fix an existing template than to write everything right from scratch.
<bandali>ngz, i’m curious to hear about your setup as an org dev. do you redefine emacs-org in a separate channel to fetch from latest master? or perhaps simly clone into a folder and add it to your load-path?