<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
<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?
<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.
<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)
<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>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