<mbakke>Probie: Docker is not packaged yet. You can create Docker images, though :-) <Probie>mbakke: Unfortunately I need to run existing Docker images :'( <mbakke>Probie: Sounds like a good learning opportunity ;-) <mbakke>I don't know if anyone has tried packaging it, but it should be possible with go-build-system. <pkill9>what does this mean? "GUID Partition Table Header signature is wrong: 0 != 5452415020494645" <freestorm_>hey guys. i installed the guix qemu vm image. now im presented with a login but for the life of me i cant find the default password <lfam>sneek: later tell freestorm_: The password is blank <efraim>jonsger: I just put it there 10 minutes ago! <efraim>Its 32 bit PowerPC, should be big endian <efraim>I even managed to burn a CD to convert my G4 to Debian <efraim>I figured I knew it better than Gentoo <civodul>snape: can you take a look at merging Tatiana's work when you have time, or do you want me to chime in? <jonsger>powerpc64le is more tricky, because glibc@2.27 requires gcc >= 6.2 for float128 support :( <efraim>Same results as the last time I burned a CD, first one turned into a coaster <efraim>jonsger: you should be able to define a different gcc for creating the bootstrap binaries and then work on changing bootstrap.scm to work for you after <efraim>I think Nix uses busybox in their bootstrap <jonsger>efraim: glibc/linux uses the gcc version coming from gnu-build-system? <efraim>jonsger: I'm not at my computer ATM but it should <efraim>jonsger: I'm not sure about PPC64el support in gcc-5.5.0 but I can make and host bootstrap binaries if it helps <jonsger>efraim: gcc-5.5 has ppc64le support, but not "enought" for building glibc-2.27 for it... <efraim>If its just glibc we can work around that with a native input of a later gcc <efraim>Debian does a lot of cross building so I'm not sure how they built theirs <efraim>I think I read in #gentoo-powerpc they're still using glibc 2.25 <jonsger>efraim: glibc@2.25 depends on glibc@2.27 :( <efraim>Only in guix, you could make a glibc/ppc64el-linux like we have for Hurd and use that <ng0>Intel Corporation Ethernet Connection (2) I219-LM (rev 31), an Intel PRO/1000 should work with linux-libre right? <_cat_>I found a slight usability issue with GuixSD... <_cat_>so you press alt+F2 to get at the documentation <_cat_>and on most DEs you also press alt+F2 to run programs <_cat_>and so if you're using it in a virtual machine <_cat_>these conflict and you can end up with weird issues <_cat_>e.g. using it in virtualbox on Linux Mint, I find that it acts like I kept holding down alt+F2 <_cat_>so I can't ever exit the documentation because it just reopens <_cat_>for those who find the logs via google: use "info guix" and then go to the "GNU Distribution" section, instead of using the alt+F2 hotkey <_cat_>and to the developers: it'd be wise to change it to something else like control+backslash or something <ng0>it is on tty 2, which can be reached via ctrl + alt + f2… how would you do it different? <roptat>it this situation, ctrl+alt+f2 may open the host's tty2 <ng0>I'm procrastinating over an mdadm setup <ng0>of course it should not matter when I just pick the raw disks and not partition numbers, but idk right now if we have some strange assumptions here. I hope not. <roptat>I don't see "save_env" in my grub.cfg <roptat>so I have an arm board that's not listed in gnu/bootloader/u-boot.scm <roptat>how do I know if it requires some binary blob, and if it doesn't, how do I port guixsd to it? <ng0>do you have/find specs for the board anywhere? <ng0>that would be my first step <snape>(and look at the code that adds other boards) <ng0>read into them and see which hardware is mentioned <ng0>so stupid question, been too long :) when I pick raw disks for software raid, I have to stick with the size of the disks for when I need to change one of them, right <snape>ng0: it depends of the read technology <ng0>I meant to mention: raid-1 <ng0>and furthermore, this should be no blocker in our mapped-devices support, right? <ng0>I think I am bound to same size exchange anyway… so raw should be okay. and for our mapped-devices I think it has no opinion on /dev/sdX1 or /dev/sdX? <snape>ng0: mapped-devices source is a list of partitions, so /dev/sdX1 I guess <snape>although you could have partitions that look like /dev/sdX, but it's rare <ng0>I think I had this once on a coreboot system… hm <efraim>roptat: I check the uboot source, buried down in the .c file for the board is a readme for how to build uboot for that board <roptat>efraim: I've found what I need, I think. How do I test it? <roptat>ha I've been unsubscribed from php-announce... so I missed a few updates <snape>g_bor: I'm reading the web-interface email history and doing the review. I hope to be done tonight <snape>and then I may do... the gitolite service review :-) <efraim>roptat: after building I sometimes try a spare SD card and flash it manually over a vendor/community image for the board <roptat>efraim: I meant, how do I install guixsd? <roptat>does it work if I flash an iso on the SD? <roptat>(built with the uboot for my board of course) <roptat>I thought the arm machines in the build farm ran guixsd <mbakke>roptat: I think all of them use a foreign distro, actually. <efraim>Sorry, random construction vehicles showed up outside <efraim>For armhf it should be easier, vagrantc's gotten aarch64 working with some manual tweaking I think <mbakke>roptat: Which board do you have? <efraim>From the city, I think they're building a sidewalk <vagrantc>most of the armhf/aarch64 systems i've just installed Debian, done the binary installation of guix, and then "guix system init ..." <roptat>I'm not sure it's working though <vagrantc>cubietruck should work fine ... mainline linux and u-boot work well (at least for headless) <vagrantc>oh, looks like the cubietruck u-boot target isn't enabled in guix <roptat>so guix system init from a foreign distro... I'll try that <vagrantc>it's probably getting close to the point of being able to generate installer images like for x86/x86_64 for aarch64 and armhf <ng0>syncing 2x4 TB raid really takes a long time. <OriansJ>ng0: really depends on the transfer rate (100MB/s => 11.54 Hours but 20GB/s => 3.4 Minutes) <ng0>inside the machine I mean, first sync <OriansJ>ng0: so I am guessing SATA, spinning discs and probably less than 32MB Buffer averaging 50-70MB/second <OriansJ>So looking at 23+ish hours; assuming no induced loads <OriansJ>*points to basic math equation for how to calculate average bandwidth* <snape>OriansJ: I think you need the /me IRC command :-) <ng0>if I could copy specs of the server I would, but I can't so I shan't :) <OriansJ>ACTION wonders if snape noticed that... <OriansJ>ng0: So either those disks are far from full or you got the specs wrong. <ng0>relatively new, not full. but it's still 10 hours iirc <OriansJ>I am guessing it is probably the first case (less you are converting it into a stripped raid instead of a mirrored raid) <davidl>so Im able to tab out guix system, but running guix system init config.scm /mnt says "guix: system: command not found". <ng0>in my evergrowing list of things to send as patches: would the texinfo output of the python2/3 documentation be acceptable? it is quiet useful as reference <ng0>I've been using it for a while now <ng0>it's still in my ports-wip, as the python2 variant would need to be renamed iirc <ng0>my question earlier today…: Intel Corporation Ethernet Connection (2) I219-LM (rev 31), an Intel PRO/1000 should work with linux-libre right? ... since my minimal rescue image (Debian based) is working I'd guess that this works with linux-libre? I'm not really keeping up with -libre these days. <ng0>seems like this is e1000e driver <ng0>brain knot… is our grub capable to load the grub partitition from mdma devices (raid-1, initialized on the raw devices)? <ng0>instead of (target "/dev/sda"), is (target "/dev/md0p1") acceptable? <mbakke>ng0: The bootloader must be installed to a "real" partition, e.g. non-RAID. <ng0>hm.. in addition to just trying, I could simply generate and start the system in qemu <mbakke>And yes, e1000e should be fully supported. <ng0>expect more stupid questions like this (wrt mdadm), as this is part of a cross-project work where I need to mess around with GuixSD. <demotri>It seams like jars are indeterministic. Directory entries are not ordered. <ng0>so it goes format disks, create matching partitions, create raid, … magic … wizards hat … /dev/sda for boot partition. so since mdadm is the only thing I need to read up on - when /dev/sda is damaged, the grub part with a raid-1 should by then exists on both disks after the raid is created, correct? <mbakke>ng0: It would be best to write the bootloader to both disks, but I don't know how to do that. <ng0>I knew I'm touching less documented terain :) <ng0>this is just the beginning, it should lead to encryted RAIDs and all… ;) <ng0>but since md0p1 will "contain" /dev/sda1 and /dev/sdb1 this should only be necessary because of something to do with grub and device names <ng0>I got something to read into <ng0>mbakke: why do you think it's necessary? <ng0>"Afterwards we must make sure that the GRUB2 bootloader is installed on both hard drives, /dev/sda and /dev/sdb" … ah, well. <soundtoxin>How do I open the guile info page in emacs? I can only find out how to open info from the top level, and I don't see guile in the list. <ng0>I think it could be easy to extend the grub part to install to two or more disks ***soundtoxin is now known as tune
<snape>(Or C-h i instead of M-x info) <snape>once you press 'm', you type "Guile Reference" <snape>then you can go back to the top level by pressing 'd' <snape>if you rename the buffer, you can have different info buffers opened at the same time <snape>and... if you don't see Guile in the list, you need to install it (guix package -i guile) I guess <vagrantc>ng0: grub is at least partially installed before the first partition, so wouldn't be in the raid... unless you're raiding whole devices <ng0>which is why I think we should extend the target in bootloader devices for grub to a list, and install to each of the mentioned devices. at least that's my current off-to-bed opinion <rk4_>randomish question: do main 4ish guix devs [3 names pop to mind] have day jobs? do they involve guix? just curious where you folks get the time! <rk4_>i'm guessing, there's a few people whose names come up all the time, like rekado and ludo <rk4_>your name i've seen a lot, too, ng0 <ng0>let's say I started with guix when I had lots of time, which lead to too much contributions during '15 - '17.. then I started computer science studies. my new freelancer contract involves work on GuixSD. <ng0>but I also started with it because I saw the ideal fit for custom system creation, which is why my I'm currently a little less visible, trying to sync up and experimenting there :)