IRC channel logs


back to list of logs

<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
<sneek>Will do.
<civodul>Hello Guix!
<roptat>hi guix!
<janneke>hi civodul!
<janneke>hi roptat!
<civodul>hey hey!
<efraim>hydra seems to be paused
<jonsger>efraim: thats for powerpc (big endian) or?
<snape>Cuirass' web interface, with multiple inputs:
<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: excellent!
<civodul>snape: can you take a look at merging Tatiana's work when you have time, or do you want me to chime in?
<civodul>efraim: fun :-)
<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
<snape>civodul: I can do it :-)
<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
<brendyn>Possibly an xbacklight replacement?
<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
<efraim>Debian shows support for it
<jonsger>efraim: gcc-5.5 has ppc64le support, but not "enought" for building glibc-2.27 for it...
<efraim>I see
<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>do we make use of for our grub installation?
<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 think we do
<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>same size or bigger I think
<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
<g_bor[m]>snape: Thanks, that's nice.
<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?
<dustyweb>hi #guix friends
<roptat>does it work if I flash an iso on the SD?
<roptat>(built with the uboot for my board of course)
<efraim>roptat: oh, that's much harder
<roptat>I thought the arm machines in the build farm ran guixsd
<roptat>how is it done?
<mbakke>roptat: I think all of them use a foreign distro, actually.
<efraim>Sorry, random construction vehicles showed up outside
<mbakke>efraim: Random? :)
<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?
<mbakke>Perhaps vagrantc has some tips
<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>that's a cubieboard
<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
<vagrantc>easy to add, though
<roptat>so guix system init from a foreign distro... I'll try that
<roptat>thank you :)
<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
<ng0>no, it's faster
<ng0>already at 90%
<OriansJ>ng0: in 9 minutes? ummm
<ng0>many hours
<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".
<snape>ACTION does :-)
<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
<wigust>ng0: wow, it will be useful
<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.
<mbakke>ng0: Sounds good! :)
<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
<ng0>here's an example for nixos, although a bit far off from what I want
***soundtoxin is now known as tune
<snape>tune: M-x info, then 'm'
<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
<tune>snape: thanks!
<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 :)