IRC channel logs
2018-07-14.log
back to list of logs
<pkill9>is it me or is berlin slow to download from? <nixd>Hey guys, does anyone know how to list (with guix package) or delete generations that are not per-user (as in they are directly in /var/guix/profiles)? guix package returns "guix package: error: profile '/var/guix/profiles/per-user/root/guix-profile' does not exist <nixd>". I am logged in as root <cbaines>nixd, what command are you trying to run? <nixd>cbained, guix package -l and guix package -d <cbaines>Sounds like you might not have installed any guix packages as root? If /var/guix/profiles/per-user/root/guix-profile does not exist. <nixd>cbaines, You are right, I didn't yet install packages besides when using guix system reconfigure. But I did the reconfigures as root, so why do the generations end up in /var/guix/profiles instead of /var/guix/profiles/per-user/root? guix package doesn't find them this way it seems <nixd>Am I getting something fundamentally wrong here? <cbaines>nixd, are you seeing things like system, system-*-link? <cbaines>nixd, I believe the system stuff is handled by guix system, rather than guix package <cbaines>there is just one set of system states, which is why it's not in a user specific directory <cbaines>if you want to delete previous generations of your system, I don't think there is a command to do that, but you can delete the system-...-link files <cbaines>just be careful that you don't delete the one you're using, and perhaps keep some around to roll back to <cbaines>looks like there is a guix system list-generations command <nixd>cbaines, That makes sense to me, also guix system --list-generations does return the correct generations. Alright, but I really wonder why there is no guix system command to delete generations.. <cbaines>I would guess it's just that no one has added that feature yet <nixd>Alright, thank you for your help! <brendyn>hmm arc and faba icon themes are broken again <mbakke>brendyn: I believe they were fixed late yesterday, did you run `guix pull` recently? <brendyn>I ran it and was building over night. I'll run it again and see how it goes <janneke>ACTION is doing open heart surgery on gash <roptat>what arm boards do we support? Is there a list somewhere? <janneke>snape: do you know where to find that armv7l GNU/Linux is not supported, do you know why? <janneke>ACTION would like to learn more about arm, and they apparently got an unsupported arch <OriansJ>well if I remember correctly, the primary ARM problem is based on the inconsistencies between ARM platforms (which they are fixing to a degree with device tree). <snape>janneke: I don't know enough to answer accurately. I'll let OriansJ :-) <OriansJ>There is also the fact that different ARM chips interpret certain byte sequences differently but that issue can be ignored by simply avoiding generating those sequences, do multipath optimization or just say these chips are too rare to care about. <OriansJ>There are also ARM TrustZone customizations which are explicitly hostile to Linux and those chips are not worth the time to obtain support for. <OriansJ>The big issue for linux-libre is many ARM chips require binary blobs for basic initialization (like the raspberryPI) but there are those that are reverse engineering that and hopefully that will resolved shortly <OriansJ>But that being said, the short version of why we only have a list of supported ARM systems, is because most ARM systems require binary blobs to function and GuixSD has explicitly selected to be blob-free and only support hardware that does not require binary blobs. <snape>thanks OriansJ, it's interesting <OriansJ>snape: what is really going to surprise you is that there are an entire series of ARM chips that share no instruction encodings in common with the standard ARM because they are decended from a DEC design for an ARM chip (the StrongARM series) <OriansJ>They were the heart of Intel's ARM chips up until 2000, when Intel changed direction; made XScale which had the performance properties of StrongARM but binary compatibility with standard ARM. <OriansJ>Hence why very few people want to even look at ARM prior to v7; you'd have to support multiple encodings for the exact same instruction set but had to alter your output depending on the manufactor of the chip. ARMv6 wasn't always compatable with ARMv6 and didn't share enough opcode encoding in common to work around those differences. <OriansJ>snape: the only saving grace that PowerPC, SPARC and x86 had was early monopolies that demanded compatability. MIPS however recently took a serious term for the worse; having changed encodings 3 times most recently in their bid for improving energy efficiency of embedded MIPS, which completely broke binary compatability. <snape>OriansJ: I'll read that article, thanks for sharing it <OriansJ>PowerPC however screwed up with Their vector instructions; VMX128 is not entirely compatible with VMX/Altivec, as a number of integer operations were removed to make space for the larger register file and additional application-specific operations. <OriansJ>Originally VMX had 32registers, then 128 registers and then with Power ISA v2.06, they changed VMX to have 64 registers. Each time breaking the encoding of vector instructions but keeping the opcodes the same, thus requiring multipathing just to allow vector code to work on PowerPC Chips. (I am not going to get into the crazy differences between PowerPC and Power as that is an entire field of bad choices) <OriansJ>One could say, I have a deep interest in Microprocessor design and Architecture. I guess that is why I made https://github.com/oriansj/knight-vm to have a mechanism for efficiently experimenting with various instruction set architecture changes before picking one that works optimally (While hoping others with similar interests will complain about the things in it they don't like) <janneke>ouch, so armv7l needs (or could need) binary blobs? <janneke>do we have a list of supported names, or how could i have found out we do not support armv7l? <janneke>gash: builtins: ls: Support -a,--all,-1,--one-line,-h,--help,-v,--version. <OriansJ>janneke: in ls -h is short for --human-readable not help <snape>Risc-V looks nice, I'd like Guix to support it <OriansJ>snape: (not for bootstrapping but that is a different conversation). From what I understand, the privileged ISA is available as draft version 1.10; meaning RISC-V hasn't even standarded the very thing required for an Operating system (MMU and IO space considerations) <OriansJ>snape: personally I hope they get some more experimental research done prior to the final standard, otherwise they'll have a painful transistion in the future to address their current design. <brendyn>it works but at the end it prints guix build: error: fport_write: Broken pipe <brendyn>oh wait it doesnt. guess you cant use ls like that <janneke>ACTION is going to steal find-files from guix to add a gash `find' builtin <civodul>but note that the find command is a bit of a kitchen sink <janneke>civodul: sure, the first implementation will only allow find [DIR] or something, much like ls -R <janneke>just think that would be very helpful as rescue shell command <janneke>do we have a list of desired, missing commands? <janneke>sed comes to mind, after find (will probably steal substitute* :-D) <civodul>i think the goal should be to add whatever 'configure' scripts expect <janneke>ah, yes -- i'm still working towards two somewhat different targets <janneke>Rutger has made great progress simplifying the parser and also towards compliancy, but current gash is still much more broken than last week's <janneke>so meanwhile i'm looking at exit stati, builtins and stuff <civodul>well in a sense that's a good sign ;-) <civodul>"we don't make omelettes without breaking eggs" <civodul>it might be that Gash is already good enough for typical usage in shell-mode <janneke>i'm kind of "waiting" now wrt mes/bootstrap and playing with gash in the meantime <civodul>i guess rekado, myself, and others should give wip-bootstrap a closer look now <janneke>there's no hurry with the bootstrap, i'd like to have rekado involved and don't want to disturb his vacation more than i already did <janneke>i didn't see a way to depend on a smaller section of %bootstrap-binaries <civodul>that's fine, we don't have to solve everything at once <janneke>i would like to make it so that we remove binutils/glibc/gcc (and easily remove others later) from %bootstrap-binaries and have that show in the dependency graph <janneke>so that we're very sure that we're not fooling ourselves, and have a clear set of binaries to remove, one by one <brendyn>janneke: make useful guile projects that require importing guix for some small functions, that way we can infect everyone's computer with guix! <cbaines>maybe "share guix with everyone's computer", infections don't always appeal to people <janneke>brendyn, cbaines: i'm still a little bit modest but i'd like gash to be a place where all nifty guix shell and build utils find a home <janneke>so that guix can import them just like everyone else <janneke>this shell library may also move to Guile, we'll see <brendyn>Yeah guix is project that's surely grown many useful abstractions, it'd be fantasic to move them in to modules <daviid>janneke: where is gash? i thought about snarfing find-file -> guile-lib (I wrote a few such procedures in grip, get-dirnames,get-filenames ... not good enough right now, but ...) <janneke>but as you probably read, it's *very* much in flux, the PEG grammer is being refactored <janneke>daviid: not more ambitious than Guix? <janneke>just trying to conquer the world ;-) <brendyn>when C code has execl("/bin/..." ...) embedded in it, does guix have any phase for transforming those paths? <civodul>brendyn: no, we usually do it "manually" with 'substitute*' <brendyn>Ok I've written a substite* command to fix some paths. it also requires adding a bunch of dependencies so I can get the paths. I notice there are these "config.guess" files that refer to all sorts of direct paths. Do I need to patch them too? <janneke>ACTION wonders about the overlap and underlap of shell commands: command and type <janneke>command -V <command> ~= (somewhat) type <command> <janneke>command -v <command> ~= (somewhat) type -p <command> <janneke>and if that's not enough then you also can install external command `which' <janneke>maybe let's just see what "configure" happens to need <brendyn>Should be be using gexps in package definitions at this point? <civodul>brendyn: not in master (there's a branch for that that we should merge someday) <brendyn>I'm preparing a patch that just uses the method I've learnt where I just use a let expression with many assoc-refs to define symbols for paths to the inputs I need. From what I understand gexps simplify that <nyberg>hm, guix pull ended up with info manuals in french <brendyn>I notice that Nix symlinks sbin to bin in packages but it doesn't seem we do that. Does it matter? <civodul>brendyn: dunno, i don't see what sbin -> bin symlinks would buy us <janneke>command, find, type have naive implementations that could suffice <erickomoto> file or directory ... possible causes the program is a script but its interpreter was not found` <snape>erickomoto: I don't get why "read-only" implies "non-root" <erickomoto>So, I am not very familiar with tiny core linux. I first attempted to install the binary release via root (the normal set of instructions) but every time I rebooted everything I installed was deleted. (And I ran out of memory because everything is on RAM (?)) <erickomoto>The only way for files to persist in `/` is to run another command which basically zips `/` and stores it in another partition. On every boot this zip file is expanded to root. (?) (I might be wrong) <erickomoto>But /home/user is on a partition that can be stated to be non-volatile. So I wanted to install guix there. <erickomoto>So, even though I can use root. The only place where I can get persistence (without explicitly saying zip `/`) is in the directory /home/user <snape>erickomoto: the problem if you don't use /gnu/store, is that you won't get substitutes <snape>because /gnu/store is hardcoded in binaries <erickomoto>I have used `proot` to trick guix into believing it is running in `/` <pkill9>are you running guix on foreign distro and want to move the store erickomoto? <pkill9>nope it's not, i did it when i ran guix on foreign distro <pkill9>the solution is to bind-mount the directory you put the store in, to /gnu <pkill9>i put that in an fstab so it would bind-mount it on boot <erickomoto>Ok. Thanks. I will refresh my knowledge on partitions/fstab/etc and try again. <pkill9>with command line it would be for example `mount --bind /path/to/gnu/directory /gnu` <snape>pkill9: it's weird Pjotr doesn't talk about it though <snape>yes, see the article erickomoto is talking about <erickomoto>Well the document states that root should not be necessary. After all, the title is GUIX-NO-ROOT <pkill9>yeah that's probably why, you need root to bind-mount <erickomoto>So, I think the bind-mount is achieved through proot? <pkill9>oh i dunno anything about proot, looks interesting though <pkill9>yeah, i assume you can bind-mount within the proot <erickomoto>YES! Ok, there are some command arguments missing <erickomoto>Uff.. I guess I'll make a pull request to fix this. Wuw. First contribution. <snape>and follow the official Guix tutorial :-) <erickomoto>Thanks snape. I don't know how well filetool.lst suits my needs though. Even if /gnu is persistent, I would need to run filetool.lst every time I install a new derivation. And that is what I wanted to avoid. <erickomoto>Yeah. I think you may be right... I'll give it a try! <snape>so if /gnu is persistent, everything inside (/gnu/store/...) will be too <erickomoto>I agree with that, I just don't know a lot about tinycore (and how it handles partition) to deduce that this will fix everything. I still think that / and /home are in different partitions and / is very small. So I would need to have /gnu in a different partition (or adjust the size of the / partition). Definitely an option worth exploring though. Thanks snape <snape> /gnu would be in the same place as /home <erickomoto>You may be right. I don't know much about partitions. Haha. Thanks <snape>learning one thing (Guix) is hard. Learning two (Guix + tiny core linux) is very hard. I'm not talking about learning Guix + tiny core linux + proot... <snape>so... if I were you I'd learn one thing at a time :-) <pkill9>snape: while you're here, i don't suppose you know how to compile kernel modules in guix? <snape>well, no, I saw your questions about it, but I really don't know <snape>pkill9: maybe you need a custom Linux, with another config <snape>so that it builds the modules you need <pkill9>i already compiled kernel once, ig uess i could do it again, it's just if it doesn't work i'll have to try again and it takes a while, lol <efraim>mesa fails on staging on aarch64, testing an upgrade of mesa now <snape>make-linux-libre takes a #:configuration-file argument <pkill9>sadly i need to use non-free linux driver for wifi, I want to run the linuxlibre deblobber in the future though and just make an exception for the wifi driver <snape>you could make a custom linux-package with it, and with your custom config <snape>but with Guix it's pretty easy to have a custom linux with a custom config, a custom source, etc <snape>but... compiling linux can be slow :p <pkill9>and if something goes wrong you can boot the previous kernel <pkill9>is there a URL with the raw ISO image of GuixSD? I want to create a vultr instance running GuixSD <Thra11>When ./pre-inst-env says "note: source file ... newer than compiled ... ", does that mean it will ignore the changes since it was last compiled? <efraim>new mesa compiles on staging on aarch64 <pkill9>also, how do i add that bootup graphic that appears in the guixsd iso image to my system? <janneke>do we have a `grep in scheme' lying around somewhere? <dustyweb>just as a test, would someone mind mentioning me in the channel? <efraim>ACTION wonders where my trout is when I need it <pkill9>hmm, my GuixSD installation doesn't have mkfs.fat <pkill9>someone recently was missing a mkfs.<filesystem> <janneke>ACTION added a reasonable grep to gash <pkill9>interesting, after rebooting and running the guixsd instlalation image, mkfs.fat has appeared <taylan>is the GNOME bluetooth settings panel working for others? I've got bluetooth working, but the panel still says it can't find a bluetooth dongle. <taylan>having to use bluetoothctl to pair my devices is a little... inconvenient :P <OriansJ>is there any particular reson why either curl or wget is not part of the default guix image? <janneke>OriansJ: i don't know, could be fore image size reasons, could be oversight <janneke>fwiw, i didn't have need for those, what's your use case? <pkill9>taylan: which package is bluetoothctl in? <janneke>OriansJ i'd post this script to guix-devel with the suggestion (or a patch) to add wget to the installation immage