<antiatom>All of schematics of which chips are used and how they connect to each other is completely open for peer review and commentary. Feedback is welcome! <antiatom>I think Guix would make a perfect fit for such a operating system agnostic handheld computer <ellis>So, I must have messed up the partition table for GuidSD. It won't install GRUB because there's no boot partition? <mark_weaver>antiatom: The Neo Freerunner (GTA02) used a wireless chip that did not require loading a blob to function, so your claim that "the Neo900 gets us closer than anything" is false. <mark_weaver>please do not spam this channel promoting a device that requires loading non-free blobs to function. <mark_weaver>also, your claim "This blob never touches the main CPU" is false. The main CPU needs to load the blob into the WLAN device. <mark_weaver>"There is no alternative on the market that can offer this, or even projects in the planning stages that are trying to offer this." is also false. The GTA02 had the same unusual feature of preventing the baseband processor from being able to control the user's CPU, but did not require loading a blob to use the wifi. ***davi_ is now known as Guest74801
<lfam>I saw mark_weaver mentioned the failing coreutils-8.24 armhf build yesterday. That fails on armhf for me too. Same test (tests/tail-2/assert.sh) <civodul>i'm trying to understand what's going on <lfam>uname -a: Linux hostname 4.1.0-2-amd64 #1 SMP Debian 4.1.6-1 (2015-08-23) x86_64 GNU/Linux <amz3>I need to update a package, The documentation says to run `guix refresh --list-dependent package` but what I am supposed to look for in the output of that command? <civodul>lfam: 'tail --follow=name foo' should notice when 'foo' is removed and write 'No such file or directory' once it's removed <civodul>so the test does that, and waits for 7 seconds to see if that message appears <civodul>it fails because the message doesn't appear <civodul>internally, 'tail' uses inotify to monitor the file <civodul>amz3: that command tells you how many packages depend on the one you are modifying <phant0mas>good morning, tests/tail-2/assert.sh failed on my x86_64 as well <phant0mas>btw I rebased wip-hurd on core-updates, seems to work on crossbuilding from x86_64, trying it out natively <civodul>phant0mas: i can't reproduce the tail-2/assert.sh failure on x86_64 <civodul>i've been running it in a loop for some time <phant0mas>it happened to me only once, the second time it succeded <phant0mas>it happened on the rebased core-updated/wip-hurd <phant0mas>failed on the rebased branch, sending log to ml <antiatom>AFAIK mark_weaver, the WLAN chip in the GTA02 is the Accton 3236AQ which uses the Atheros AR6001GZ chipset. This chipset is FullMAC and implements a large part of the 802.11 stack in a non-libre, non-replaceable firmware blob stored on the ROM of the chip itself. If you use the ar6000 or ar6k driver with your GTA02, it may be GPLed but a lot of the complex code implementing Wi-Fi is non-libre but stored on-chip <antiatom>Contrast this to the AR9170 chipset also from Atheros. This chipset has no ROM to store firmware, so you can load LIBRE firmware to the WLAN chipset's RAM so it can function. <antiatom>Non-libre code burned onto the ROM of the WLAN chip does not make the problem of spying and the ethics of user liberties somehow magically disappear. <antiatom>At least with the Neo900, because the firmware blob is not burned into WLAN chip ROM, there is a possibility to replace the firmware easily once someone reverse engineers it. <antiatom>Also, Neo900 does not require WLAN to function. You can use a USB to ethernet adaptor if you want. <phant0mas>civodul: first time failed, second succeeded <benben9621>Hi everyone ! I'm here looking for an advice : I'm starting a new year in my university and I have to choose which distribution to put on my computer. I was considering using GuixSD but I don't know if it's stable enough since it's still at alpha stage, I would not really appreciate loosing all of my courses just before the exams actually :/ <benben9621>I have to say it's a math/info year I'm starting (License 1) so it may have some more needs than just LibreOffice but it may not be as much advanced as an Info Master for example... <antiatom>benben9621: If you need stability, better to install another distro like Parabola GNU/Linux-libre and then install Guix on top of that. <antiatom>You can always install GuixSD in a virtual machine using something like QEMU <benben9621>Okay, sounds like a good option, always wanted to give a try to parabola anyway :) <benben9621>Actually, I installed it on a bigger laptop than the one I'll be using to take my courses because I wanted to try it as a not-emulated-distro and I'm quite satisfied for the moment :) <benben9621>That's why I was considering using GuixSD actually ^_^ <civodul>phant0mas: what if you run "cd tests; while make check TESTS=tail-2/assert.sh ; do : ; done" in a failed build tree? <iyzsong>civodul: yes, we should add hooks to generate gschemas.compiled and loaders.cache, it's useful for dconf-editor, etc. but I don't think we should remove the wrapper for those 2 thing. <iyzsong>otherwise, the application won't launched from store unless it's installed, and may have some binary compatiable issue with gestings schemas. <civodul>then we need to find a way to silence the collisions <iyzsong>civodul: sure. the 'icon-theme.cache' can be remove safely, it's for 'core-updates' right? <iyzsong>I have remove the 'generate-icon-cache' phase in my glib-or-gtk-build-system locally. but still some packages build the cache (eg: dconf). how about split the 'gtk-update-icon-cache' out from gtk+, and then let me fixes the broke ones.. <civodul>iyzsong: yes, rather for core-updates <civodul>so applications run from the store (not in a profile) won't get icons or what? <iyzsong>icons don't need the cache to work AFAIK <civodul>mark_weaver: re tail-2/assert.h, it seems that somehow tail's stderr isn't redirected as it should, hence the failure <civodul>wait, maybe it's just me messing up, nvm <civodul>but its public key is not public yet <davexunit>civodul: thanks for feedback on 'guix environment --container' <bavier>I'd like to push the xmonad patch now <civodul>davexunit: i feel sorry to ask you for more because i'd really like us to start using it! :-) <iyzsong>ah, that's not fair. I better check it in my morning when most of you fall sleep :-) <civodul>i think we cover pretty much all the time zones :-) <bavier>it doesn't yet work with reconfiguration, but I think it would be nicer just to have it available <civodul>bavier: sounds good; i think i lost track of that patch <civodul>or thought that we were waiting for the other person to chime in <iyzsong>not 'check', but to broke then fix some gtk+ packages 'core-updates'. <civodul>bavier: if you're confident though, it's OK <davexunit>civodul: nah, it's fine. I knew that things were incomplete. <davexunit>ACTION waits on hydra to reconfigure his machine with a working elogind <bavier>civodul: yeah, with the current state of the patch xmonad works well if you're satisfied with the default configuration ;) <bavier>I was kinda hoping some others would look at it <bavier>I found out GHC_PACKAGE_PATH doesn't work how I had thought <civodul>bavier: i'd say push it & notify them, so they'll have an incentive to improve it ;-) <mark_weaver><antiatom> benben9621: If you need stability, better to install another distro like Parabola GNU/Linux-libre and then install Guix on top of that. <mark_weaver>antiatom: that's not good advice. for stability, by which I take to mean reducing the risk that you system will become broken, GuixSD is actually far more stable than Parabola. <mark_weaver>Trisquel is surely a good thing to recommend for people who want stability. <davexunit>Arch, and thus Parabola, are unstable by design. <mark_weaver>GuixSD is very stable. The problem with GuixSD is not stability, but rather the limited selection of packages and some missing features. <mark_weaver>and I see that antiatom is going to continue to recommend hardware that requires non-free blobs on this channel :-( <davexunit>ACTION attempts to test a geiser bug fix via guix ***davi_ is now known as Guest93821
<ellis>I'm having trouble installing guixsd. I don't know what partitions are required, but GRUB failed to be installed because I don't have a GPT partition? <ellis>Do I need to create an MBR partition? <davexunit>maybe someone else who knows more about GRUB and such will chime in. <ellis>I set up 3 partitions. root(ext4), home(ext4), and swap. But guix said it coulnd't install GRUB. <mark_weaver>ellis: if you use the GPT partition method, then you must include a EFI boot partition. <davexunit>ellis: could you post your config file? if someone who can help sees this, they will want that. <mark_weaver>I don't remember the details, but UEFI systems require a special partition where the bootloader(s) are stored. GRUB tries to install something on that partition when the GPT partition map is present on the disk. <iyzsong>I think our GRUB don't support UEFI yet. <ellis>My BIOS hase a setting for UEFI/Both/LegacyOnly. I had it set to legacy only. I'll read the documentation and give it another go. <mark_weaver>iyzsong: as I recall, wingo successfully installed GuixSD with a GPT partition map, and it worked for him. <mark_weaver>ellis: the link that iyzsong cited describes how to create the special boot partition. I suspect that if you create that partition, you'll be able to successfully install grub with GPT. alternatively, you could use MBR instead. <iyzsong>mark_weaver: yes, GPT is supported. but UEFI require a file 'grubx64.efi' (our grub desn't have this) install into the EFI partinion. <ellis>I've got to create the partion first right? I mean it's not intrinsically part of the disk, correct? <iyzsong>ellis: yes, you have to create it manually (using gdisk, select '0xEF02', and 1M should be enough) <ellis>alright. Thanks very much. I'll give it another go. <civodul>i have a GPT too, but UEFI is another story, i think <mark_weaver>if it's true that our GRUB doesn't support UEFI, I wonder why not. <mark_weaver>the lack of grubx64.efi in our build output is not conclusive evidence. On the YeeLoong, I need 'grub.elf' which is loaded from PMON. That file is dynamically generated by 'grub-mkimage', which is run by 'grub-install'. <iyzsong>and Grub haven't made a stable release after 2.00 (3 year ago). <ellis>So, I deleted my swap partition created a new swap and an EFI partition. <mark_weaver>iyzsong: on the 'wip-loongson2f' branch, I updated our GRUB to recent git. I needed that to get it working on the YeeLoong. <ellis>That didn't work, so I deleted the EFI partition and created a BIOS boot partition. This time GUIXSD installed without error. But it doensn't boot... <ellis>it didn't. I had to put the usb stick back in to boot <iyzsong>ellis: can you use 'chainloader' from the usb's grub to your harddisk's grub? <iyzsong>ellis: at the Grub menu, pause 'e' to the grub command line. then write (something like) 'set root=(hd0)' (enter) 'chainloader +1' (enter) 'boot' (enter). <ellis>should hd0 be in parens or is that a template? <iyzsong>you way mant to press 'TAB' to ensure your harddisk is 'hd0'. <iyzsong>ellis: ah, sorry, not 'e' (it's for edit, then you need to delete exist entry) but press 'c' to enter the Grub command line. <ellis>hey that worked. it was hd1 not hd0 <ellis>now, I don't recall setting a password. What's my password? <iyzsong>ellis: root have no passwd default. I think you need to reconfigure your system, and see it can boot or not. <davexunit>Guix is so nice. just built a custom geiser to verify that jao's bug fix worked for me. <ellis>so, if the usb grub can chainload to my system grub, how do i make it so I don't need to chainlaod? <ellis>Much fun. Trying to get my grub to boot without chainloading <lfam>civodul: I realized I told you the wrong kernel yesterday re: armhf build failure of coreutils-8.24 <lfam>civodul: it's actually Linux hostname 3.4.106-cubieboard2 #6 SMP PREEMPT Fri Apr 17 19:44:23 CEST 2015 armv7l GNU/Linux <lfam>That's a weird device-specific kernel and may not be useful for troubleshooting. <paroneayea>I might give a talk on guix at the end of the month <civodul>lfam: ok, i just reported my findings on the list <civodul>not 100% sure i got it right, we'll see ***davi_ is now known as Guest8828
<paroneayea>would be nice to have access to hamts and stuff in guile <amz3>mark_weaver: did you package libusb-compat-0.1 ? <amz3>I mean do you have it on the side, because I create a package for it, to be able to run libreboot flashrom <amz3>if it's not the case, the correct name of the package should be libusb-compat-0.1, isn't it? <mark_weaver>amz3: I don't remember, but I'd like to update our flashrom to a newer version, such that we can use it instead of Libreboot's hacked up flashrom. <mark_weaver>the last time I tried, I had some difficulties, however. <amz3>there is a flashrom in guix? <mark_weaver>yes, and I used it regularly to flash Libreboot to my Thinkpad X60. <mark_weaver>as I recall, upstream flashrom requires some old libraries, and I had to patch it up to get it to build against the new ones we have in guix. I had some difficulties making a similar patch for a newer flashrom release. <mark_weaver>it's possible that I didn't try using libusb-compat-0.1. I don't remember, and right now I don't have time to investigate. <mark_weaver>however, I'll say this: the 'flashrom' that comes with libreboot is hacked up to only support a few flash chips: the ones in Libreboot-supported machines, and is done in such a way so that you don't need to tell it which kind of chip you want to flash. <amz3>np. libusb-compat-0.1 is part of LFS so I guess it's a good candidate for package, anyway I will send my patch so it doesn't get lost <mark_weaver>so, using the upstream flashrom requires adding some extra command-line options that aren't documented in the libreboot docs. <mark_weaver>amz3: for now, you could just use the pre-compiled 'flashrom' executable that is libreboot provides. <mark_weaver>at some point, I'd like to add a guix package to build the libreboot images and utilities from source. <mark_weaver>but lately I've been trying to get our MIPS and ARMHF ports in better shape <amz3>I already did flash my laptop using libreboot provided tools, I did not know they provided pre-compiled flashrom executable, so I compiled it myself <mark_weaver>amz3: did you add a guix package for libusb-compat-0.1 ? if so, it would be great to get it in guix. it might simplify getting a newer 'flashrom' into guix. <amz3>I'm setting up the dev environment <paroneayea>I'm thinking of getting a minifree laptop shortly, since morgan's laptop is dying <paroneayea>maybe I should since getting one is still currently easy <mark_weaver>paroneayea: I've been very pleased with the Libreboot X200 :) <paroneayea>kind of a bad time for me to do it financially since my contracting work is running out, but if her computer dies I'm not going to have a choice anyway <paroneayea>mark_weaver: glad to hear it's working well for you! <francis7>paroneayea, cool. Are you going to FSF30? <francis7>I'll probably deliver the laptop via UPS though <francis7>Although, I did deliver a laptop to someone in person at libreplanet <mark_weaver>paroneayea: francis7 is also the principal Libreboot developer :) <paroneayea>francis7: you deserve huge praises for your work then! <paroneayea>I'm not sure what's happening at fsf30 yet, I just plan to be there :) <civodul>sounds like FSF30 is going to be a pleasant event :-) <civodul>mthl: looks like you forget to push the patch for the web site's package page <mthl>I've just push it tonight :) <mthl>But yes I forgot about it until today. <antiatom>True that Parabola was not the best to recommend, however... <antiatom>mark_weaver: It is impossible to recommend to anyone who wants a handheld computer with a GSM radio + WLAN chip *anything* that does not require blobs. <antiatom>There are no SDIO WLAN cards that run a fully libre stack, and the only practical way to handle GSM radios is to isolate them in hardware like Neo900 does. <antiatom>People want GSM/UMTS/LTE on mobile, and they want those same computers to have WLAN. They expect that. If there is any current "smartfone" owner now who is looking for something that even BEGINS to respect the user's freedom, the only options are Openmoko and decendents (including Neo900) <mark_weaver>antiatom: the GTA02 runs without blobs, and can even run OsmocomBB for free software in the baseband.