<reepca>huh, my mouse issues seem to have gone away after pulling, reconfiguring and rebooting. Glad it's over, I do wish I knew what caused it, though... ***nonlinear is now known as NB0X
<fusion809>Hi folks. I've been trying to set up Guix per the docs but when I try to install glibc-locales and glibc-utf8-locales Guix tells me "failed to install locale" and then suggests I install the very packages I was trying to install by the command that returned this error <roptat>"failed to install locale" is just a warning <fusion809>Yeah I know, but if it stops it from install glibc-locales it may as well be one. <roptat>what error do you have when installing glibc-locales? <fusion809>Also tried with glibc-locales instead of utf8 <jonsger>fusion809: how did you install guix? <roptat>fusion809: you missed step 4. I think <fusion809>Yes I did, I missed it because it said to look below and I didn't see where the instructions were. <roptat>indeed, I'm not sure what "as explained below" referes to... <nolash>Is guix practical to use for airgapped computer? With respect to package updates <roptat>anyway it's a required step, so please add these users and group <nolash>ng0: it will be a minimal install; console only, just for password keys signing and such. I would have to get the packages and put it on it by removable media, and then... what? <ng0>if at some point connection to a trusted computer on your network which in turn has access to the internet is allowed, then it is possible. there are other schemes, like you could work with Guix packs or export the store of the other computer in another way. <nolash>ng0: no I'd want to keep it totally offline. guix pack. Thanks I will have a look <ng0>there are some blog entries about this on the guix website, and if you search the archives of guix-devel you might find something useful for your case <roptat>fusion809: can you run "guix package -I"? <roptat>the default profile should already contain glibc-locales <fusion809>Don't think so since I'm presently running guix pull and won't it conflict with that <roptat>also, how did you start the daemon? <fusion809>Per the docs, guix-daemon --build-users-group=guixbuild <roptat>ha, that's probably where the message comes from then <roptat>you can try running GUIX_LOCPATH=... guix-daemon ... <jonsger>fusion809: on tumbleweed you could install guix by just "zypper install guix", btw <fusion809>Yep and then I wouldn't be able to follow the same instructions to set it up, at least not since I'm a bit of a beginner. But thanks for the info. <g_bor>I am dealing with a few old patches, and I have to rewrite/modify them as they no longer apply. <g_bor>How can I give proper attribution to the original author? <fusion809>Good news GNU Guix seems to be working properly now. <jonsger>fusion809: but zypper will set all up for you. you just need a "systemctl start guix-daemon" after that and then you can use guix :) <fusion809>What about when Guix tries to update itself? <fusion809>Does it also set up all the users, localese and alike? ***rekado_ is now known as rekado
<rekado>g_bor: you can add a “Co-authored-by:” line. Whose name appears there depends on how much you rewrote and who you would thus consider to be the author. <jonsger>fusion809: combinating "guix pull" and the zypper do inferfer a little. But I build a guix package on opensuse which I update once a week or so. So you dont need guix pull <fusion809>But won't guix pull be required to update other packages in a nice automated manner (instead of running guix package -i on each of them)? <jonsger>fusion809: with "zypper update guix" you update guix itself and after that "guix package --upgrade" updates the packages you installed with guix <fusion809>So no guix pull is needed after guix's zypper update? <jonsger>the main problem with openSUSE's guix is that we still use guile2.0 and not guile2.2, which would be better <fusion809>Hmm. How long have you been maintaining this package? I ask because I'm wondering if I want to hitch myself to your waggon and use ZYpp, in case you decide you don't want to maintain it anymore. I've done that with a few Gentoo packages I used to maintain in my own overlay, even though I never thought I would oneday, so of course it's hard to know whether someone is truly committed to it. <jonsger>for a year. Sleep_Walker started the package in January 2014. I'll keep maintaining it (I work for SUSE). the next thing is to update guile2.0 to guile2.2 in Tumbleweed <fusion809>Must admit I'm surprised you's would go to such trouble, especially since wouldn't adding the packages GNU Guix has access to that openSUSE doesn't and working on openSUSE's snapshotting ability be a better way of making openSUSE have more of GNU Guix's advantages? Nonetheless I; <fusion809>'m sure the community shares grattitude to yas <Sleep_Walker>fusion809: my motivation is simple - I can have separate set of packages at the same system in non-conflicting way; I was able to prepare and tune my packages on openSUSE and now I can use them on GuixSD <Sleep_Walker>sometimes it is easier to create independent package in Guix than argue with maintainer in openSUSE :D <Sleep_Walker>( jonsger: like the ones Dr. Werner Fink is taking care of :D ) <jonsger>Sleep_Walker: does rpm/zypper has something like "guix refresh PACKAGE --list-dependent"? <fusion809>Sleep_Walker: but is it easier to make your own package in your own home project in the OBS than to argue with the maintainer and make a package for GNU Guix? I find creating my own openSUSE packages easy as pi. If other people want to use them, they easily can. <Sleep_Walker>fusion809: when the package you want to alter is base one, you'd need to recompile whole distribution <Sleep_Walker>fusion809: I'm aware of benefits of OBS, quite well, I'm maintainer of several packages too :) <fusion809>OK, fair enough. But why not Nix then? Like Nix is more mature, not sure but it might have larger repositories, and frankly I find Nix, the language, easier to understand than GNU Guile, although depending on your background that may not be the case for you. <Sleep_Walker>why not? I was amazed by Guix, I like the idea, Scheme is beautiful - easy to read and demanding for writing (at least for me); I have to bend it a bit so I can use my HW but I like challenges :) <Sleep_Walker>now I am using it in both - my work environment and at home <fusion809>OK, well we're all different, that's part of what makes life interesting. So good luck to ya, and thanks for the package, even if I don't think I'll use it, I'll probably just stick to the binary install. <jonsger>Sleep_Walker: you have this czech router from the ISP? <fusion809>Nice, good ol' portability, sort of like pkgsrc and Ravenports and how cross-platform they are. <janneke>fusion809: remember that we are a GNU project, someone's "license liberal" is our "user's freedom denying" <Sleep_Walker>jonsger: and it's not ISP, it's non-profit organization which is taking care of .cz domain registrations so they use the money to make safer Internet :) <fusion809>Yep I know, but most Linux users I know are happy to compromise, if it means they get greater usability. Granted you could argue that means they should be using a proprietary OS instead, but Linux has other advantages other than the whole open-source thing. <pkill9>i like scheme/guile, the package definitions read like metadata but are code <Sleep_Walker>fusion809: well, freedom as it is seen by FSF and GNU is essential for this Linux distribution so it makes no sense to compromise it here :) <fusion809>GNU/Linux^ is the term Stallman would be insisting you use, along with many other FSF folks :P. But sure, funny thing is I just got my only PC on which I can run fairly well with open-source software alone. It's my first desktop, all my laptops have WiFi chips that needed proprietary drivers. <pkill9>and i requested it yesterday so surely cuirass would make it available as a substitute <ecbrown>pkill9: i set icecat 60 to build on my machine last night, and it failed <pkill9>ecbrown: were you building for x86-64 or i686-linux? <cbaines>I'm a bit stuck trying to reconfigure, guix says: error: you may need these modules in the initrd for /dev/nvme0n1p3: shpchp <cbaines>but on the other hand, adding it as it suggests gives: kernel module not found "shpchp" "/gnu/store/5a5fl0c4i2r257gani4aa41wb0xcqnyl-linux-libre-4.18.9/lib/modules" <ecbrown>pkill9: actually it was rust that failed. there is a discussion on the mailing list <pkill9>but still, icecat shouldn't have built in that case <pkill9>dunno why berlin saying it was built <rekado>cbaines: that module disappeared in newer kernels. <rekado>cbaines: you can either ignore it and tell Guix to not check, or you could use the LTS kernel. *janneke goes afk for a bit -- make check still fails on wip-bootstrap :-( <janneke>hmm, test-assert "gnu-build" in tests/builders.scm has me puzzled <janneke>adding anything beyond the initial ("source" ,tarball) to `input-drvs' bombs out with "string-prefix?" .. wrong type argument 2 -- but no backtrace <janneke>removing everything except ("source" ,tarball) fails at unpack, because tar is missing *g_bor fixing typo in kdenlive patch... <janneke>oh wait... (input-drvs ((source #<derivation /home/janneke/src/guix-bootstrap/test-tmp/store/qlzmg7f6jcdlmay2ymzav4nkdvlx5r2j-hello-2.8.tar.gz.drv => /home/janneke/src/guix-bootstrap/test-tmp/store/3mrwfji8b1yd5dq62ixjcc90kimkdswy-hello-2.8.tar.gz 2df1eb0>) (tar #<package tar@1.30 gnu/packages/base.scm:174 3607000>))) <janneke>the `tar' that i try to add looks different from the source: a package instead of a drv -- hmm *janneke goes to add debug printing to guix-master <janneke>aha! %bootstrap-inputs is not the %bootstrap-inputs from gnu/packages/bootstrap.scm <atw>ecbrown: were you compiling it? I had to abort the compilation of icecat 60 with a hard reboot <ecbrown>yeah, its compiling on my machine now, 16 GB and ssd. i had to kill it ia few times to do some other highrity stuff <ecbrown>hah, priority -- that's rust lagging my terminal! <atw>wow. Yeah, my recent hardware was struggling, I'll update later when there are substitutes/I'm not doing something else <terpri>part of the problem is just that so many versions of rust have to be built, in order to bootstrap from mrustc <terpri>installing rust 1.27 requires building...at least seven versions of the rust compiler <g_bor>istm that kdenlive now works. <janneke>i got builders.scm test working ... but it's terribly slow and many other failures :( :-( *janneke spams civodul and guix-devel with somewhat sad make check progress... <efraim>Does icecat require the most recent rust? <ng0>atw: wokr around it with 10 - 20 GB swap. <ng0>this is offloading and the same offloading machine is standard hardware from 10 years ago or so.. watching movies while compiling, and only getting into trouble with peak Chromium compilation times. <atw>ng0: yeah, I should set up offloading, if only to not have to deal with my laptop heating up. otoh I was a bit chilly <ng0>Webbrowsers compilations are the new heating. <atw>efraim: according to the package definition shown by guix edit on my machine, icecat depends on (@ (gnu packages rust) rust) <efraim>Right, but I mean is 1.25 good enough or does it have to be 1.27 <OriansJ>ng0: is there any way to turn off optimization passes to reduce the build requirements? <atw>but I haven't tried building icecat with 1.25 <janneke>this is so weird...tests/guix-package fails with: guix package: error: install: extraneous argument <janneke>i'm sure the computer is right, but how could the mes bootstrap trigger something like this -- where should i start looking ... :-/ *janneke goes to grab some supper <ng0>OriansJ: for firefox? or for rust? <terpri>efraim, icecat 60 needs rust 1.24.0 or later, or at least that's what it checks for during configuration <terpri>firefox nightly requires 1.28.0, but that probably won't matter for icecat anytime soon if it's based on ESR releases <ng0>this keeps growing as far as I understand building rust. So where do we go from here? I for one will look into getting a stable package which can be used for every package variant and simply use versions, not rust/latest. imagine building 12 versions of rust to get to some version of rust and then the software which depends on it. <efraim>i would hope that eventually mrustc can target a later version of rust <terpri>i'm timing rust builds with and without "-j" flags to see which is faster (i don't know what the default setting is) <terpri>also rust's check phases use "-j1" due to an i686-only bug, but it's probably not needed for most builds and certainly isn't helping build times <janneke>okay, two down, at least 8 to go: # FAIL: 9 
