<clodeindustrie>I have two questions, should I run `guix system init config.scm /mnt` with sudo? Shoud I run in particular anything with sudo when it comes to guix?
<clodeindustrie>and well actually that's 3 questions, when running that command, the process crashes when trying to build glibc-2.26.6.drv how would one go at debugging something like this? or what are people's way of dealing with crashes when building?
***terpri_ is now known as terpri
<roptat>clodeindustrie, these instructions are for guix 1.0.1, I suppose you used 1.1.0 instead?
<roptat>you probably want to enable substitutes if you didn't, as it will allow you to get packages without having to build them
<roptat>for sudo: in general you don't need to run guix with any priviledge, because it has its daemon
<roptat>but when installing or reconfiguring the system, you need to use root priviledges. You have to use sudo with "guix system init" and "guix system reconfigure"
<roptat>you could think in terms of multi-user: reconfiguring or installing a new operating system is not a task a simple user should be allowed to do, because it impacts other users as well
<roptat>whereas installing a package, or building something has no impact on other users, so it's safe to do as normal user
<leoprikler>perhaps you can tail -f the log file for the test, e.g. tests/lint.log
<marusich>leoprikler, not a bad idea. I guess I should have thought of that. I'll try it out next time
<marusich>Hmm, it seems that kinda/sorta works. There are still very long pauses (minutes).
<leoprikler>that's probably because the output is not flushed that often
<leoprikler>I had a similar problem in one of my own libraries, so explicitly flush after each line
<leoprikler>(this is semi-important, because there computation can take hours just to get to that line)
<Baerwin>Anyone here who might help me, please? I tried mounting NFS file-system under guixSD I managed to get an entry in fs-tab with the config but when I try to actually mount it with mount -a I get an error saying to use mount.nfs instead of mount -t nfs. When done manually it works. I'd like to automatically mount it however, any ideas?
<direbanana>I installed GNU guix two weeks ago. It's not on my main partition, but a secondary one to toy around with. Since the grub on my main partition somehow does not recognize the Guix partition, I boot into the grub on my Guix partition using a grub rescue stick. From that Guix grub menu, I choose the generation I want to boot.
<direbanana>This worked fine the last time I tried (two weeks ago), but today it fails at the point where I choose what to boot in the Guix grub menu. Whichever option I choose, I get
<direbanana>That is where I am stuck, as I don't understand the bits of advice my internet search has yielded. (They are mostly meant for situations that don't seem to apply to me.)
<rekado>direbanana: I’m not very familiar with grub. I hope someone else here can help.
<rain>direbanana: what file systems are involved and which device is grub installed to?
<leoprikler>a quick grep shows our grub modules reference those functions
<direbanana>rain: my main and my guix partition both use ext4, if that is what you mean. I understand a mini grub is installed on the boot sector and points to a real grub. In my case the mini grub points to the one on my main partition, which is aware of the Ubuntu installation on that main partition, but not of the Guix installation on the Guix partition. The Guix partition also has a grub of its own.
<direbanana>leoprikler: I'm afraid I don't understand your answer. I barely know what grub modules are. Do you mean that Guix has some of its own grub modules with extra functionality? I searched the Guix documentation and didn't find any mentioning of it.
<rain>direbanana: that seems rather involved o_o is installing GRUB that way even supported?
<leoprikler>I don't think it's "extra" features – I think it's a linkage problrm
<direbanana>rain: Involved is an accurate description. To boot into Guix, I have to insert the grub rescue stick and manually set the grub prefix and root to the Guix partition, then do insmod normal and normal. However I never considered it /not/ to be a possibility. Do you know a better way of setting up this dual boot?
<Bryophyllum>I'd spent quite a lot of time trying to come up with a way to *declaratively* define my aliases in the Configuration System: I had read gnu services source code in search of real-world examples, had extensively looked through the manual, but I was unsuccessful getting anywhere. Is extending Guix with a (subjectively) complicated service module the only way at the moment? Is there a subjectively easier way? I'm a signle "git com
<Bryophyllum>mit" away from deploying Guix on my production machine, but the inability to configure aliases declaratively is what holding me up. I'd prefer not to manage my user account .bashrc by hand, but, at the same time, I can't afford to put off migrating to Guix for longer to give myself more time to learn Guix.
<direbanana>leoprikler, NieDzjejkob: Ubuntu is already in my menu-entries. It appears as an option in the grub menu on the Guix partition, but gives the symbol not found error. Also I don't think I can let Guix take control of grub. The only way I know to get boot sector grub to point to the Guix partition('s grub) is by performing some commands within the Guix partition, into which I cannot boot at the moment.
<guix-vits>Bryophyllum: Do You want an declarative /etc/skel? To all new users get some predefined aliases?
<NieDzejkob>I use the approach of a dotfiles repo that also contains the guix configuration
<NieDzejkob>Bryophyllum: you could use special-files-service-type, I think
<rain>direbanana: there is a dirty workaround if you can't boot from grub. boot into Ubuntu and kexec into Guix. i used to do that from Arch. (for complicated reasons related to firmware bugs)
<leoprikler>so you're now getting to guix grub directly and it still fails?
<direbanana>leoprikler, NieDzjejkob, rain: To break the vicious cycle, I would have to boot into Guix from the grub on my Ubuntu partition. That might work, but I don't know how to get that grub to recognize the Guix installation.
<guix-vits>NieDzejkob: Hi. Do you know, by chanse, from where the default /etc/bashrc comes from?
<Bryophyllum>NieDzejkob: I don't see how this service would be useful in my case, but thanks for your input
<leoprikler>i don't think guix' grub is that different from ubuntus
<NieDzejkob>Bryophyllum: you could use it to define the contents of /etc/bashrc
<direbanana>leoprikel: no, not directly. I don't know how to get boot sector grub to point to the Guix partition without already being in the Guix partition.
<NieDzejkob>guix-vits: a quick grep suggests gnu/system.scm, line 767
<NieDzejkob>ah, looks like I used an older checkout of the repo
<guix-vits>Thanks. (i'm only came to NEWS.txt for "* Changes in 0.8.2 (since 0.8.1)" so far)
<rain>direbanana: i don't think that's how that works. the partition you install grub to shouldn't matter. but where you install it from does matter. i've had problems on Arch when i accidentally installed grub from the live system instead of chrooting into the installed one.
<rain>what you probably want is to unify the config files.
<rain>direbanana: i wouldn't say dangerous, but it takes a bit of know-how. for me it was as simple as reading the /boot/grub.cfg file from the guix partition, finding the kernel path and the kernel arguments, loading the kernel with the kexec command, loading the arguments with the same command, and running sudo systemd kexec.
<rain>direbanana: but systemd kexec is supposed to handle this pretty nicely. it properly shuts everything down.
<janneke>hmm, i cannot seem to find where to increase increase the size for the installed-extlinux-os test, i keep hitting guix system: warning: at least 1376.8 MB needed but only 1241.1 MB available in /mnt
<NieDzejkob>I'm thinking we could remove bashrc from the default etc-service and instead create a bashrc-service-type that would extend etc-service-type with a bashrc it generated
<rain>is there someone who could help me with some cross-gcc shenanigans? (maybe in PMs so as not to flood the main channel)
<rain>i'm trying to get the GCC 10 based devkitARM working but GCC 10 doesn't seem to be tested for embedded stuff.
<mbakke>in hindsight, it would have been better to reset the branch, but too late now
<janneke>mbakke: what happened, that makes that it's too late?
<Bryophyllum>niedzejkob: Now when I'm thinking of what I said, I've come to realize that it may be feasible to define the default contents of the bashrc file in /etc as a %variable that along with user changes is appended to our bashrc-service-type file-like object. I hope that what I'm saying makes sense. I've never participated in designing anything before, let alone writing a program.
<mbakke>janneke: a while back 104 commits from master were cherry-picked to core-updates by mistake (they meant to do a merge), and there have since been a few other commits to core-updates, which we would "lose" by resetting the branch now
<mbakke>they can of course be cherry-picked, but it rewrites the signatures, and resetting branches makes it difficult to audit changes
<mbakke>so I think we just have to accept the extra merge conflicts the upcoming core-updates round
<janneke>ah okay -- yeah i didn't think of signatures
<janneke>just imagined that the conflicts you're hitting now could be less (or the same with a nicer history)
<mbakke>there would be approximately zero merge conflicts if it weren't for the cherry-picks
<mbakke>FWIW 'git merge -X theirs' worked flawlessly, I'm now auditing each of the actual core-updates changes to make sure that no conflicts were resolved wrongly
<bricewge1>NieDzejkob, Bryophyllum: Having a specific service for bash system config would be easier to configure for sure.
<bricewge1>But better still will to get rid of files in /etc (if possible).
<NieDzejkob>Bryophyllum: I'm having trouble testing this at the moment, but maybe you could use (modify-services) to grab the configuration of etc-service-type and append something to the bashrc entry?
<mbakke>bah, fbd2d7c84307df00e558f722ec692247034db46e, was un-done, but I don't care enough to fix it :P
<bricewge1>NieDzejkob: We could have a procedure to be used in 'user-account-shell' fields that generate a bash that never look in /etc and instead load the config passed by that procedure.
<mbakke>NieDzejkob: i'll let nckx have his e51101ecda83c85b0ed9ca98dc7d9606f00dc0ac :P mainly to avoid future conflicts in that area
<mbakke>also, I already made the merge commit to investigate the 'git show' diff
<direbanana>rain: I tried the kexec plan. Sadly it's not working. I found the kernel image and the initramdisk in the gnu store, and within Ubuntu loaded and executed it. It simply reboots my computer.
<mbakke>that seems to be the only "bad" merge, which is OK
<mbakke>it's not visible in 'git show <merge-commit>' though, scary stuff
*mbakke should learn how to use smerge-mode instead of relying on 'git merge -X theirs'
<direbanana>That's the first thing I saw on Arch wiki. I forgot about the other way. I'll try that now.
<rain>direbanana: kexec -e didn't work for me either when i tried it. only the systemctl way.
<direbanana>Interesting. I find out I don't have "systemctl" installed. Which is strange, since I do think I am using systemd (Ubuntu 14.04).
<Bryophyllum>niedzejkob: without the extension proposed in the issue linked by bricewge1, (modify-services) won't work in our case (basically repeating what bricewge1 said since you could've overlooked their message)
<rekado>cbaines: I did “guix pull” and reconfigure; do I need to do something else to get the latest cuirass?
<cbaines>rekado, I'm unsure, is the berlin configuration fixed to a specific commit, or just a branch?
<cbaines>I think I remember someone saying it used the latest revision from master
<rekado>apteryx: yes, hardware. Madalin and I took the disks from the old server behind berlin.guix.gnu.org and put them into one of the new 2U build servers; added a new HBA card for good measure (so that we can switch back to the old server without much difficulty), connected the external storage, registered that HBA card with the storage (via Windows!), and rewired the network cables.
<rekado>I can’t say for sure that the old server’s NIC is broken (it could also be something else wrong with the chipset), but berlin.guix.gnu.org is now on a new server with new 10G NIC.
<rekado>this suggests hardware problems with the old server
<rekado>glad to see that some of you are getting higher download speeds now
<rekado>I may have to reboot the server again next week to swap HBA cables, but I think we can leave it this way
<apteryx>rekado: very nice! Thanks for sharing the story.
<apteryx>I'm also able to max my meager bandwith here at times, which is something new!
<cbaines>rekado, the other way to check if the change I have in mind has been applied is check in the cuirass database, if you look at the schema for the Outputs table (.schema Outputs), you should see an index for the derivation column.
<Bryophyllum>NieDzejkob: About that bashrc service, where do I start writing the service? Can you guide me? Let's say I cloned the git repo, authenticated my checkout, and wrote the service; how do I point Guix to my local git copy so that it uses my service (assuming it's incorporated into system.scm, where bashrc is currently generated)?
<mbakke>Bryophyllum: there is a './pre-inst-env' that you can use after configuring and building the git checkout