***Cal[m] is now known as CharlieBrown
<reepca>Are there any reasons for the daemon to run as root besides access to /gnu/store and using chroot? <reepca>and is there any particular reason for /gnu/store and its contents to be owned by root instead of, say, a guix-daemon user? <reepca>If I understand what I've been reading about user namespaces correctly, it looks like it might be possible to get an isolated build environment without needing root <rekado_><rekado> yes, with user namespaces it probably would not be necessary to use <rekado_><rekado> but user namespaces are not yet available on all systems. [05:47] <rekado_><rekado> CentOS 7, for example, disables them by default. <rekado_><rekado> you can only enable them by passing a kernel argument at boot. <sneek>civodul, you have 1 message. <sneek>civodul, efraim1 says: are the gccgo packages created by custom-gcc stripped at the end? <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) <jsierles>i'm building in an alpine docker container <fr33domlover>I have guix installed on top of Trisquel and I want to update guix itself to the latest version, I get an error about some github token idk <reepca>fr33domlover: would this be using "guix pull" or "guix package -u"? <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>building all guix packages now: load average: 734.49, 473.26, 220.74 <civodul>jsierles: woow, how many cores/hyperthreads? <jsierles>looks like libunistring-0.9.7 build just hangs forever <jsierles>in general though, using gnu parallel with max 10 jobs seems to be a decent poor mans CI <civodul>jsierles: probably the 'test-lock' test program no? <jsierles>i saw this particular one hang a few times on test-lock <jsierles>libsoup is failing with "unexpected status 6 Unacceptable TLS certificate". <civodul>BTW, note that --max-jobs is per client <civodul>so if you spawn N 'guix build --max-jobs=M', you have up to N*M jobs running <efraim>Was that 'guix package -A | cut -f1 | sort -u | shuf | xargs ./pre-inst-env guix build' <efraim>Also known as 'I wont spend the time to set up cuirass' like me? <efraim>wouldn't you be limited by the number of guix-builder users? <civodul>the number of guix-builder users is not a problem if you have just one client with --max-jobs <= number of build users <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. <janneke>i want to enter an environment described in a manifest file, how do i do that? <adfeno>civodul: Thank you very much for fixing bug#27582. ;) <adfeno>I just tested it, and at least the package download --- as was the subject of the bug --- works well. :D <adfeno>(The bug was the one about the GNU Artanis web server). <davexunit>the --load flag only handles a single file, but I think --manifest flag, mirroring that of `guix package`, would work nicely. <adfeno>Now we just need to start working on the bundled and customized guile-json that's inside artanis. <davexunit>janneke: getting myself re-acquainted with the code, there are some complications. <davexunit>how does this -m flag compose with the other args? <davexunit>what should `guix environment -m foo.scm coreutils` do? <davexunit>I suppose it should be the union of the manifest and coreutils <davexunit>does the command line parser handle multiple instances of an arg? <janneke>davexunit: hmm, suppose those considerations are part of the reason there is no -m flag yet <davexunit>like, could I do `guix environment -m foo.scm -m bar.scm` ? <janneke>davexunit: usual guile getopt allows that, but you'll have filter options to get a list of them all <janneke>ACTION thinks getopt should have something like a #:multiple flag for that but hey <jsierles>it looks like '504 timeout' from a substitute server doesn't trigger a fallback build. <davexunit>I think I can make the manifest thing work with a little bit of hacking. <bavier`>davexunit: with srfi-37 args-fold you should be able to collect as many instances of an option as you'd like <efraim>With the chances of output collisions it should probably only add the Union of the two manifests <davexunit>I would expect it to union everything passed <bavier`>nice to see mikegerwitz advocating for guixsd on HN <paroneayea>./pre-inst-env guix environment --ad-hoc openmolar <paroneayea>./pre-inst-env guix environment --ad-hoc openmolar -- openmolar <paroneayea>or you could install it in your profile and run it <quiliro>paroneayea: executed the last command you told me <quiliro>ImportError: cannot import name 'Qsci' <paroneayea>hm, it's missing a python dependency, apparently <paroneayea>quiliro: looks like it needs something added to its propagated inputs <paroneayea>all I did was search for the package name and find what references to it I could find <paroneayea>sneek: later tell quiliro add it to propagated-inputs since it's a python dependency <ijp-web>Hey, is there a guide to setting up guix-daemon on linux distributions that use SELinux? <ijp-web>well, other than cycling: try systemctl start guix-daemon, read error, apply recommended fix <sneek>quiliro, you have 1 message. <sneek>quiliro, paroneayea says: add it to propagated-inputs since it's a python dependency <quiliro>paroneayea: i dont have an entry with propagated-inputs <quiliro>guix package -A qscintilla shows no output <quiliro> ImportError: cannot import name 'Qsci' <quiliro>so paroneayea said i should include it in propageted-inputs <quiliro>but when i run guix package -A qsci or <adfeno>quiliro: openmolar is a package that you are making? <adfeno>Hm... I see.... so we essentially have to make a baby called qscintilla... ;) <adfeno>And tell your openmolar package to use the other one (qscintilla) as propagated-input. <quiliro>will these dependencies go ad infinitum? <quiliro>adfeno: so....what should i help with? <adfeno>quiliro: Like so: (define-public qscintilla ...) (define-public openmolar ... (propagated-inputs `(("qscintilla" ,qscintilla))) ...) <quiliro>adfeno: before openmolar...where should that go? <adfeno>quiliro: I generaly put things in the same .scm file, but only if I'm using it for myself. <quiliro>adfeno: i have no idea how to replace the dots.....i want to make it for guix and myself too <adfeno>quiliro: Hm... Could you share with us the file that you are using to install openmolar. <adfeno>I mean... It probably came from some .scm file (it's a text file). <quiliro>adfeno....yes...it is one made by rekado_ and modified by me with help of paroneayea <paroneayea>quiliro: not ad infinitum, eventually you'll get it all :) <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? <adfeno>quiliro: yes, in a way such that the new copy will tell Guix everything about qscintilla. We can take the related Parabola-or-Hyperbola packages for qscintila as an example. <quiliro>adfeno: oh...where can i find those in parabola? <adfeno>I'll walkthrough there too and help out, let me check... <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 <quiliro>adfeno: great....what will you do with that? <adfeno>From that page, I can see that python-qscintilla-qt's propagated-inputs must have: qttools python-qscintilla-qt-common (we'll probably make that too) python-pyqt. <quiliro>adfeno: ok...i start understanding how to package! <adfeno>Actually, python-pyqt is in inputs, like what was done in openmolar <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: Don't worry, I sometimes do that too, although we both do this for small texts. <quiliro>‘native-inputs’ is typically used to list tools needed at build time, but not at run time <adfeno>I have seen people doing this with larger texts, and these do cause trouble. :) <quiliro>i did yesterday....and some people were very upset <quiliro>it was an accident because i am still learning how to copy and paste in emacs <quiliro>but i am getting better...perhaps you people will be tolerant until i dont mess up <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 <adfeno>quiliro: Oh... I see what you mean now. :) <quiliro>ZombieChicken: i do use pastebin...it would be great to paste in chat and make it automatically pastebin! <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 <adfeno>quiliro: Info pages saving the world. :) <davexunit>quiliro: sorry for making you feel bad about it. <adfeno>One thing I like about info pages is that they don't depend on internet connection to be read. :) <quiliro>davexunit: thank you for your concern <quiliro>adfeno: i would love all guix would be like that <ZombieChicken>The problem with info pages is the readers for them are vastly inferior to webpages <quiliro>i am currently in a municipal office for the wifi link <davexunit>I look up things much faster than in a web page <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. <adfeno>quiliro: Note: "evil" is an Emacs package. :) <quiliro>adfeno...please leave me with homework (tips) <davexunit>ZombieChicken: well then I guess what the world needs is a vim info reader <quiliro>evil is for making emacs similar to vi, right? <davexunit>I hear spacemacs is good to have things that way out-of-the-box <davexunit>plus all sorts of other changes to make it more vim-like <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 <bavier`>i.e. letting users create containers without needing to carry around huge disk images <jsierles>i work on a mac and use the atom editor. how bad is that on a scale 1 to 10 <slyfox>the /gnu/store directory is quite big though <quiliro>jsierles: i use a mac ....but have no OSX <jsierles>i am probably evil for doing iOS dev as well <quiliro>jsierles: no....apple is...they just use you <ZombieChicken>quiliro: from my understanding, most major corps just use f/oss work without giving anything back, so I don't think there is a huge difference there <jsierles>probably should get a guixsd machine. what's a good laptop for it? <quiliro>but with the software there is a huge difference...user is under their control or not <quiliro>that is another step....i hope to make it with my next machine <quiliro>even though it would be with lower specs <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. <quiliro>ZombieChicken: less than a decade..i use a 2009 macbook air <ZombieChicken>8 years old. Close enough, and still ancient in computer terms <jsierles>OK. why do you have to use decade old hardware? <ZombieChicken>You could use something a bit newer with an AMD CPU, but then you'll have to look into the "feature" set of the CPU to see if it includes their ME-equivilent <quiliro>how many people would buy an equivalent of an i7 laptop with all hardware and software libre for $1000? <ZombieChicken>jsierles: Long story short, it's a hardware-level backdoor on a parallel computer on your system that you have literally zero control of and it setup entirely as a black box <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>Then Intel "fixed" it, but didn't change it to a sane design <ZombieChicken>jsierles: Yeah, and pre-2013 hardware needs a looking at to see if it includes the spying feature, I mean out-of-band management engine <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 <quiliro>they are closing the municipal offices <ZombieChicken>Does anyone here use mapped-devices? I'm getting some weird nonsensical errors here that /seem/ to point to my (mapped-devices ...) entry in my sysconfig file <ZombieChicken>sadly, this is on another system, so I don't have exact backtraces <bavier`>ZombieChicken, jsierles: there's some good work/progress underway atm for guixsd on aarch64 <ZombieChicken>bavier`: If that is ARM 64-bit, then I question it's value. IIRC, there aren't too many 64-bit ARM cores out there atm <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 <davexunit>and left a comment with a link to the blog post I wrote about containers in guix <jsierles>ZombieChicken: ok. so it can work, even if libreboot doesn't support it? <jsierles>ZombieChicken: just wondering if 'support' means 'it wont work' or 'we won't support it' <ZombieChicken>If you are refering to libreboot, there is a list of supported motherboards on the site. It's use on anything else whatsoever is likely to cause problems <ZombieChicken>GuixSD doesn't really care about what BIOS you are using, if any (I think GuixSD and Grub support UEFI now, but I'm not 100% sure) <oriansj>however should your budget be limited and your board be not supported, coreboot is partial step up <davexunit>for awhile I wanted to make sure the next motherboard I bought had libreboot support, but it is just too impractical of a requirement right now <ZombieChicken>davexunit: Honestly? Novena's "solution" seems like the best option; it's BIOS/firmware is on a MicroSD card, and I'm fairly sure it's BSD/GPLed or something