<efraim1>hmm, that actually might explain why our gccgo packages don't actually work
<efraim1>I don't think its a bug per se, but if I build linux-libre on aarch64, which doesn't have a .conf file, it doesn't build any of the .ko files we need to run a VM, but aarch64 isn't listed as supported in any case
<efraim1>so I think it mostly falls under working-as-intended or at worst "won't fix"
<efraim1>i see python*-pyopenssl fails on everything except x86_64, its not just my problem :)
<efraim1>building the kernel atm, just saw lib/raid6/neon.o go by, thats a nice use of neon
<jsierles>i see this error for some builds: guix build: error: build failed: while setting up the build environment: getting attributes of path `/etc/nsswitch.conf': No such file or directory
<jsierles>am i missing something from the build environment?
<reepca>jsierles: well, nsswitch.conf is used by glibc for networking stuff. It seems important enough to have that the daemon doesn't check whether it exists or not before trying to copy it (well, more specifically, bind-mount it) into the chroot.
<reepca>in short, you're missing that file from outside of the build environment (it gets let into the build environment for fixed-output stuff like downloads)
<reepca>actually, now that you mention it being a laptop, it might hurt a bit - guile 2.2 traded pretty heavily on the speed side of the "speed vs compile time tradeoff". So make sure it's on a well-ventilated surface :-)
<jsierles>efraim: yes, but 10 parallel jobs seems to be reasonable. load is at around 50
<jsierles>but also, dont think cuirass is what we want now. we already have a distributed job queue, and hope we could reuse it. the only thing making that complicated now is having to build on a single machine, which i understand is an issue with the sqlite database.
<adfeno>quiliro: taking your .scm file as basis for what I said earlier: when we were talking about babies and "(define-public qscintilla ...)" we essentially would be copying everything that is between the line "(define-public openmolar-1" and the matching parenthesis (in openmolar-1 case, it happens to be the last one).
<quiliro>ok...so i should use the same file and include the copied text below and modify it according to your further instructions?
<joshuaBPMan_>Hello, I would like guix to swap caps and control on login. Kind of like what setxkbmap -option ctrl:swapcaps does.
<joshuaBPMan_>I could create a file, but that may not be preserved upon reconfigure...?
<joshuaBPMan_>Also I just had a crazy idea. Might it be possible to make a guix specific filesystem for /gnu ? One that acts like git and only tracks the changes of a binary files? Aka Emacs 23 and Emacs 24 are largely from the same code base. If a user had both installed, we could save some disk space by just keeping a diff of the two binary files. I'm no where near competent to do this, but it's just a thought.
<adfeno>quiliro: I was just looking for the Parabola package, I guess that the direct users of Parabola can take this information more easily (through pacman), but I, as not a Parabola user, can only get the package by doing: git clone "https://git.parabola.nu/abslibre.git" and looking for python-qscintilla-qt5
<quiliro>adfeno: there is a list of packages in packaes.parabola.gnu
<ZombieChicken>Is (mapped-devices ()) a seperate entry under (operating-system ()), or is it a part of (file-systems ())?
<adfeno>Now, I'll see where qttools should go to... I'll go to my local copy of Guix repository, and look for every place in which qttools is used, then I'll see just a few (3 perhaps) of those and see where it's used.
<adfeno>Hm... I have looked for the usage of qttools, and it's mixed between native-inputs and inputs.
<quiliro>adfeno: i never heard of native-inputs...will read it in the manual
<jsierles>i couldn't find native-inputs in the manual
<quiliro>The distinction between ‘native-inputs’ and ‘inputs’ is
<quiliro> necessary when considering cross-compilation. When
<quiliro> cross-compiling, dependencies listed in ‘inputs’ are built for
<quiliro> the _target_ architecture; conversely, dependencies listed in
<quiliro> ‘native-inputs’ are built for the architecture of the _build_
<adfeno>quiliro: From the text you just pasted: I would say that, for example: if you are building GNU Bash for ARMv7, but your current computer is a x86-64, then native-inputs will take everything that needs to be ARMv7, and inputs will take everything that needs to be x86-64.
<ZombieChicken>quiliro: I, for one, don't mind too much, though pastebin is better for things like that, or a PM if the recipient is okay with that.
<davexunit>ACTION was not upset, just wanted to mitigate flood
<quiliro>adfeno: yes....and '‘native-inputs’ is typically used to list tools needed at build
<adfeno>"pastebin" in figurative sense (the real PasteBin requires non-free software) ;)
<quiliro>davexunit: ok...sorry for the missunderstanding
<ZombieChicken>quiliro: To do something like that, you'd probably have to have your chat client detect a message greater than a certain length, or containing a newline, and have it pastebin the data, /then/ post the resulting link
<ZombieChicken>davexunit: Except you then have to use emacs to read an info page, which is kind of like using a frontend loader from a mine to dig up the flowers in the small planter in your front yard
<davexunit>when I want to look up a guile function I just press 'C-h i' to pull the manual up and press 'i' to search the index (with fuzzy matching provided by ido)
<quiliro>emacs is very useful...i should candy its look though...i think that is possible
<davexunit>ZombieChicken: I dunno, I'm already in emacs, why not read docs there, too?
<ZombieChicken>Okay, so am I mistaken in believing (mapped-device ) needs to be inside (mapped-devices (mapped-device ...))?
<adfeno>quiliro: I'm very sorry for saying this, but I have an activity that I must attend to in the comming hours, and I must leave now. At least I helped you on how to do basic packaging. :)
<davexunit>I saw an info reader web app that looked great. I wish that would get adopted for people that want everything in a web browser.
<quiliro>ZombieChicken: my emacs is lighter than my icecat
<ZombieChicken>davexunit: I'm not a fan of emacs, just fyi. The only reason I'm using it is because of gieser/slime, and even then I /need/ evil to make is usable.
<quiliro>but i dont know how to use vim so it is the same work to learn emacs as is and emacs as vim
<ZombieChicken>emacs works if you need to interact with external processes, but imo fails as far as UI is concerned. Vim fails in an entirely opposite way, which is rather painful for people needing features of both
<quiliro>will someone help me with the construction of openmolar package please?
<quiliro>adfeno was guiding me with the inclusion of dependencies
<ZombieChicken>jsierles: As far as good hardware for a guixSD system, just look for decade old hardware and that will be a decent starting point. If you want something somewhat newer, hardware like the Novena is an option, but iirc, there is no ARM port of GuixSD atm, so if you go that route you're kind of on your own.
<ZombieChicken>jsierles: What's funny is there has already been (according to Wikipedia) a trojan developed for it
<jsierles>"It is extremely unlikely that any post-2013 AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible."
<ZombieChicken>imo, if you have the time and money, look at some of the ARM-based Open Hardware laptops out there and put your money into that. It is a better long-term solution than keeping to pre2009 hardware
<ZombieChicken>jsierles: Long as you're aware of the security and privacy implications of running modern Intel hardware, there shouldn't be an issue. I'm actually trying to install GuixSD on a somewhat modern Thinkpad myself atm, which has ME on it