<emyles>Hi, on Arch Linux, just upgrading glibc to 2.23 and locale-gen <emyles>does: en_GB.UTF-8...cannot create temporary file: /run/current-system/locale/2.22/locale-archive.YWtNZZ: No such file or directory <paroneayea>not a lot of things being pulled down via substitutes right now it seems... <lfam>Gah, I built a bunch of packages against the grafted libarchive yesterday, and then I rebuilt after rebasing on master before pushing, but now libarchive fails to build. The sparse_basic test fails. <lfam>mark_weaver: Okay, that's good. I wonder what is going on for me?! <lfam>Yes, but it just happened 4 times in a row. <lfam>After pushing, I did `guix pull` and then `guix package -u .` But, I ran out space so I had to stop and `guix gc`. `guix gc --verify` succeeds. <mark_weaver>well, I confess that on my mips machine, I actually cherry-picked your libarchive patch on top of my rather old private branch <lfam>I'm going to try building without today's commits <mark_weaver>and on my i686, I'm also running a bit of a strange private branch with gnome-updates and some of my unsubmitted patches <mark_weaver>so I haven't actually tried building it on pristine master <lfam>Huh, I can build it on another x86_64 machine. Waiting on the third... <lfam>I decided to transfer the libarchive closure from a machine that could build it to this one <z0d>git.savannah is down? <wingo>ACTION wonders what guix + bubblewrap would look like <wingo>it's a setuid helper that runs a subprocess in a container with new namespaces <wingo>i wonder if we could deliver applications to foreign distros and run them via bubblewrap <roelj>Do you think we could run guix-daemon in unprivileged user mode with bubblewrap? <alezost>z0d: at least something is happening with savannah: I can't commit to git.sv.gnu.org :-( <jlicht>Am I missing some kind of service announcement, or are the git.savannah.gnu.org/guix repos not working? <alezost>jlicht: not working for me too; I don't think there are any announcement of this kind <jlicht>Is there any semi-official mirror? <jlicht>jfc: Maybe this ties into the git clone troubles for that same domain? <jfc>jlicht: I don't know about those... but I'm somewhat concerned that I'm stuck getting the master snapshot via http .... <rekado>I'm still having git fetch problems after IT re-opened the ports here, though I'm not sure if this really fixed it. <jlicht>maybe it would make sense to have a default setting that refuses to download guix sources over http? <wingo>roelj: i don't think so because the daemon needs to chroot <jfc>jlicht: but then how are you going to download them since https isn't working (as I mentioned above) <wingo>i am more interested in how to run guix programs on foreign distros as a normal user <wingo>user namespaces is one option <wingo>bubblewrap is a suid helper that uses mount namespaces <jfc>jlicht: seems that savannah needs to update their https <wingo>rekado: requiring the user to have an installed suid helper is the other one was thinking of <jfc>jlicht: I expect this would happen in the next 3 years... /s <ng0>If at some point I were to work on getting features of hardened gentoo, like grsec, selinux, rsbac,IMA/EVM, etc, into guix - knowing that this will mean a long time testing and debugging because it's the complete base of guix - are some of those technologies not necessary with guixsd? <ng0>leaving aside licenses for a moment, just a mere "what if" <rekado>selinux is hard to get right with Guix, I think. <rekado>I have packaged some of the tools already. <rekado>you'd need to tag all files in the store and make sure they have the right types. <rekado>then develop a policy from scratch that would work in spite of having files installed to /gnu/store/hash-* <ng0>I have only minimal, but growing knowledge of selinux and grsec. wouldn't that be doable in advance and provide certain policies devliered with guix? <rekado>this means that pretty much all of the default rules would not work. <rekado>as far as I remember SELinux rules apply to file path patterns. <ng0>GRsec was a bit different, right? <ng0>I'd like to look into that once I've debugged gnunet-gtk for gentoo. <rekado>and you'd have to modify all files by labelling them. <rekado>SELinux isn't bad, but it would be a lot of work to get it right. <rekado>I also wonder how we would handle policies. <rekado>we probably shouldn't install rules for each package. <rekado>so we'd have packages named *-selinux providing rules <rekado>and a service that acts on these rules to label files <rekado>but relabling a system on boot wouldn't be feasible <rekado>and we cannot store pre-labelled files in the store <ng0>maybe that's what we can consider for roadmap for $muchlater and have a group or some individuals working on it, for policies etc. I'll have to get more familiar with grsec etc and when I have guixsd back, I would like to test this over an undefined timespan <rekado>we could also try this on just a single package: the browser. <rekado>then figure out the details as we go. <ng0>which one of the browsers? <ng0>I also wonder about this, because of hardened toolchain features you can build with firefox and other applicaitons in general <rekado>I'm not sure I understand this sentence <rekado>in the easiest case a user would label only their own files. System files would not be labelled at all. <ng0>hardened gcc, and also musl or uclibc are part project:hardened in gentoo. selinux isn't my only focus. <rekado>then we'd have a rule that permits tasks with a certain label to access files with a particular label, and refuse access on all other files. <rekado>I don't know much about hardening, but I have some experience with SELinux. <rekado>if someone wants to bring SELinux to GuixSD I'd be happy to help with the effort. <ng0>rekado: I'd like to come back to this conversation when I have more time :) It looks like there's definitely potential for adding functionalities. <rekado>ng0: yeah, currently I'm also out of time for exploratory stuff like this :-) <ng0>I'm doing exploratory stuff with gnunet-gtk debuuging :/ did it break due to libgcrypt-1.7? was it some other part on this system? I'm setting up many VMs now to look for differences in build <ng0>if I finish the ebuild before july, it only took me 3-5 months for the whole packaging process, when I started in july 2015 <ng0>oh, grammar broke in that sentence. <roelj>Are there any GTK2 themes I can propagate with a GTK2 package, so it looks a bit more decent? <davexunit>someone won't use guix because they can't clone over https? <davexunit>why the hell would a gnu project host on notabug.org? just doesn't make any sense. <ng0>did I miss something? <davexunit>one of those users that just complains even though we acknowledge and work on addressing the issues <ng0>older than 2 weeks, hard to find without grep in Maildir. possibly not worth the effort. <ng0>explanation: I get >=250-400 emails average in 2 weeks and I gave up sorting. I wanted to look into the thread, but I'll just use the debuggs/patches website <rekado>roelj: I would advise against propagating GTK themes. <rekado>unless you mean propagate as in propaganda. <rekado>bah, I still get "Timeout, server git.sv.gnu.org not responding." :( <roelj>So, it's a GTK2 program (Dia), and it seems to run without a GTK theme. <rekado>do you mean that it doesn't *use* the theme you have configured for all other GTK applications? <roelj>Well, that's the problem.. I don't have any theme configured, other than what Fedora does by default. <roelj>I guessed the GUIX_GTK3_* variables won't work on GTK2 things. <roelj>Can I just expect that it will run with a theme when someone installs it? <ng0>the joy of halfway modern computers: watching star trek while 2 virtual machines compile the world and your base system also compiles world updates <rekado>I think you can configure GTK2 stuff with a gtk2rc (?) file. <roelj>Right. So it's up to the user to do that? <roelj>No, I'm trying to package it ;) <rekado>Well, I have a Fedora workstation here at work, so I could try that. <roelj>Shall I paste the package definition somewhere? <rekado>not sure if it will work for me as I haven't updated the git checkout in a while (and I cannot do it right now for some reason), but I can give it a try <davexunit>I think we may need to identify and revert some commits on master <davexunit>I seem to be compiling nearly everything from source whilst trying to do a system update <davexunit>which leads me to suspect that a commit was pushed that should've been for core-updates instead <rekado>oops, I think I have a broken Guix since "guix gc" again... <roelj>Broken how? I thought "guix gc" only removes the dead stuff :) <rekado>which includes things I forgot to register after "guix environment guix". <rekado>;;; ERROR: missing interface for module (gnutls) <rekado>or it could be my recent Fedora upgrade :-/ <roelj>Oh, on Fedora, you can install gnutls-guile, which should fix that error. <davexunit>rekado: we'll fix this in the future. we'll make the profiles that 'guix environment' generates into gc roots <roelj>(And then it uses Fedora's gnutls guile module) <davexunit>at least for now you only have to manually register a single profile <rekado>davexunit: yeah, it's no problem. <rekado>I only forget about this too often... <davexunit>I'm trying to think about what a good UI for this would be. <davexunit>it probably shouldn't register a gc root by default, because that makes the throwaway environment use-case more difficult, and most of the time that's what I want to make. <davexunit>then of course transactional upgrades and rollbacks would be the next step ;) <rekado>is anyone here using slurm from Guix? <rekado>I'm trying it right now (for the very first time) and it looks like slurmctld looks for /etc/slurm.conf in the store. <rekado>ah, never mind, need to set SLURM_CONF. <rekado>it's a scheduler or process manager. <rekado>hmm, our slurm package isn't quite working. <rekado>localstatedir defaults to the store, but munge tries to create socket files there at runtime. <bavier>rekado: I'm glad you're testing it <foobarry>rekado: you know we chatted last week about someone who had module wrappers for guix? was that someone called pjotor? <roelj>join #genenetwork if you want to reach Pjotr. <roelj>I keep getting the following error when evaluating a (define-module ...) that uses guix modules: <roelj>guix/download.scm:211:2: In procedure module-lookup: Unbound variable: plain-file <roelj>plain-file is exported by (guix gexp). <rekado>does anyone know how to get bluetooth to work? <rekado>I installed bluez and started btmon as root. <rekado>"rfkill list" shows me the local bluetooth device, but "hcitool dev" does not. <davexunit>I have never used a bluetooth anything so I'm afraid I'll be of no help. <rekado>I have a bluetooth card in this laptop. Don't see any deblobbed messages, so I assume it works with linux-libre <kyamashita>So the Tor Browser Bundle looks like it could be runnable on Guix with some ELF patching. <ng0>oh? my plan was to just wait for 6.0.5 release and use the more recent firefox esr they use to build on, like we do now for a while for gentoo <davexunit>kyamashita: that would lead me to believe that it's not reproducible <rekado>ah, needed to run "sudo hciconfig hci0 up" first to enable the internal bluetooth device. <kyamashita>davexunit: True. But I never said reproducible. ;-) <davexunit>kyamashita: well if you want to run that on your own, go for it. ;) <ng0>ebuilds orient around what torproject does for building, so it's inofficial. <davexunit>"secure" is in scare quotes because freedom is sacrficed in the process. <ng0>that'sbehind great firewall of cloudflare, but i'll work around that. <ng0>oh. it loaded anyway <ng0>ah, the moxie story... -.- <kyamashita>davexunit: I would never! It was a theoretical realization. Patching each of the libraries and constantly searching through the store doesn't sound like fun. <kyamashita>ng0: Indeed. I was hearing about this on GNU Social. <ng0>we were discussing this for the last 2 days in psyced. <ng0>also, if you are interested in fixing up torbrowser, do it. from what I've looked at it's doable without any license issues, I had no time for further checking. if you want to, you can get the code from gpo.zuyana.org or what the searchengine was, or look at http://c.n0.is and get the youbroketheinternet-overlay, check www-client/torbrowser/ directory for an orientation on how this can work. it pulls patches <ng0>for versions from a gentoo devs userspace, so those would have to be adjusted. <davexunit>isn't it not possible to compile the tor browser from source and have a usable result? <ng0>i don't know, i have always done it this way <ng0>gentoo, we have not written a torbrowser-bin so far <ng0>I can try in some days in one of the VMs if torbrowser can build just from source of torbrowser <davexunit>my understanding, without having ever used it, was that if the hash of the binary changed at all the application wouldn't work. <davexunit>or would do something that would negate its benefits. <ng0>torbrowser is just firefox-esr of some version + torbrowser addons + torbrowser source adjustments <ng0>of course there's more, but they track firefox esr <ng0>pull in firefox esr, patch the sources according to the distro you are on, apply torbrowser repository, build <ng0>from memory at least. <kyamashita>ng0: ebuilds look like they do something close to that. <ng0>of course there's stuff like EAPIs and eclasses, but that should be easy to get with guix, maybe even shorter than the ebuild <kyamashita>ng0: Yeah. I'm not familiar with emake and its friends. I never got too in depth with Portage. <ng0>if you feel like you can make most of it, but need help with translating EAPI and eclasses or understandin them, I can help you <kyamashita>ng0: I'll see what I can do this weekend assuming I'm not busy. :) <ng0>I don't get all of it to the core of the functions, but I know my way around EAPI4,5 and 6 and some eclasses I'd say <lumidragon>Hi everyone, is there a license option for when packages have no license? or do u just use '#f'? <ng0>what's the packages name? <lumidragon>I check the repo for for one I'm packaking now didn't see one. And the name is envstore <davexunit>lumidragon: in order to submit a package upstream to us, there needs to be a valid free software license applied to the source code. <ng0>lumidragon: do you have an url to a website and/or sourcecode? <lumidragon>oh kk which license variable does that corrspond to? <ng0>maybe grep for license in the whole repo <jlicht>what use is the 'environment-variables' file that is created after failing building a guix package /w --keep-failed? <ng0>idk, i don't store licenses in my head. use the fsf / gnu.org page :) <ng0>or the license file in guix.git <kyamashita>ng0: non-copyleft is a generic license type in guix/licenses.scm that allows you to point to a URL of the specific license. <ng0>oh, derf. derf is someone from around the region where I live I think, chaosdorf düsseldorf :) <lumidragon>kyamashita: I should add a license for the wtfpl then? <ng0>lumidragon: if it is copyleft <ng0>or compatible or whatever <lumidragon>oh kk, guess I'll have to research that. thanks. <efraim>wikipedia helps with figuring out if a license is copyleft or not <kyamashita>lumidragon: You can! There is another package that uses it. <kyamashita>lumidragon: Non-copyleft does not necessarily mean nonfree. <kyamashita>lumidragon: It's part of the r-dt package in gnu/packages/statistics.scm. <ng0>cd $your-git-checkout-of-guix/gnu/packages/ ; grep "wtfpl" * <lumidragon>I grep for and didn't find anything. Only realized I had a typo sry. <ng0>Ijustthought you did not know about grep or awk <lumidragon>oh kk cool, emacs projectile has a pakage or mode for it. goes nicely with helm :D <lumidragon>oh while I'm on emacs, where should the emacs packages installed by guix go? <ng0>weird. you can get the hacker magazine phrack in gentoo by emerging it <ng0>found it while searching for ack <lumidragon>is the emacs packaging a sore point? or the location doesn't really matters as long as it's under the emacs directory? <ng0>sorry for writing so much, I'm just watching star trek while waiting for systems to be usable <ng0>gentoo VMs. need to debug something <lumidragon>yikes, I remember those days. Loved gentoo, but some packages take forever to build from source -_- <lumidragon>oh another question, since no takes on the emacs thing. <ng0>bloatware takes long to prepare everywhere. everything else is max 30 minutes, average here for me is maybe 10 minutes maximum. <bavier>lumidragon: what do you mean "emacs packaging"? <ng0>I'm not happy with setting up the VMs, now that I know guixsd, but it is mainly gentoo packaging it is for. <lumidragon>when developing packages do I need to run the guix-daemon under ./pre-inst-env ? <lumidragon>bavier: I was asking if emacs packages should go un site-lisp or site-lisp/guixd.d <bavier>lumidragon: the guix-daemon doesn't need pre-inst-env in most cases <bavier>I think guixd.d is the preferred, but alezost would know more <lumidragon>kk thanks something I get an error when the package link is https. so was wondering. <ng0>this is also halfway guix related, as the new, on hold, gnunet-gtk package might be adjusted after I have results on what I am currently doing :) <ng0>also I learned about some more optional dependencies, so gnunet-svn will be adjusted. <lumidragon>intersting, would have figured you do that with NixOS. <ng0>I don't know NixOS enough to use it but I know Gentoo enough and package for it so that's the natural choice. <lumidragon>I started looking at go (for packagin), but my gosh 0_0. Why didn't they use gnu build tools. :(. <lumidragon>with a couple sed the build runs okay, but when u get to the test it's a nighmare. <ng0>eg I don't know if I can test some package / entire system to compile with musl, uclibc and its hardened variants (I only know them in gentoo hardened existing) in NixOS. <lumidragon>oh quick question can nix package manager be installed along side guix on guixsd? <bavier>I think its possible, but I've never done it personally <bavier>IIRC there's at least one other here who has such a setup <lumidragon>was wondering about cause two tools I use docker and peco are both built in golang. <bavier>lumidragon: have you read up on the golang efforts on the ML? <lumidragon>I only recently join the list like 3-4 days ago. <bavier>lumidragon: the archives are searchable <ng0>you can get archives on the gnu.org mailman site for it, or gmane.org <lumidragon>oh right forgot most mailing list do that thinks. <alezost>lumidragon: Our Emacs searches for packages both in "site-lisp" dir and in "site-lisp/guix.d/<package>" subdirs. None is preferred. The former is where GNU Build System usually puts elisp files, and the latter is where our emacs-build-system puts them; both are fine. <alezost>I personally hate "guix.d" name; I think we should get rid of it and just use "site-lisp/<package>" <mthl`>alezost: I don't like it either. However After seeing what is done in Debian testing currently I guess It might be interesting to not put everything directly in site-lisp <mthl`>Debian is using "elpa-src" subdirectory for "elpa-XXX" packages <mthl`>and then the emacs package installed via apt appeared in M-x list-packages <alezost>mthl`: I agree!! No one seems to see my point, I don't suggest to put all *.el files in "site-lisp", but in "site-lisp/<package>" instead of the current "site-lisp/guix.d/<package>" ***kelsoo1 is now known as kelsoo
<alezost>then I don't understand, what's the problem with "site-lisp/<package>/*.el"? <jlicht>alezost: Is there actually a technical issue with this as well, or are we really discussing the aesthetics of the extra 'guix.d'? <mthl`>There is no problem for me, I was just pointing that maybe the extra directory could provide a useful feature if we were doing it the way debian does it <mthl`>I don't know if it is feasible <alezost>jlicht: there is no technical issue. AFAIU both "site-lisp/<package>" "site-lisp/guix.d/<package>" can be used equally, so I just don't like an extra "guix.d" level <alezost>also I don't care what debian does :-) <alezost>mthl`: sorry, I don't understand what convenience and "useful feature" you mean <mthl`>packages installed via apt appears as read-only in list-package so they you can share dependencies between GNU Elpa/Melpa and Debian packages. <alezost>oh, you mean appearing in "M-x list-packages"! I don't see the point since these packages can't be upgraded/removed as they are installed globally <mthl`>the point is that you might want to install unstable version from MELPA and you can share the dependency with the packages installed globally <alezost>mthl`: btw I don't think Debian does anything special, there is `package-directory-list' variable, so IIUC they just put the packages there, so they appear in the package list <mthl`>Anyway it is quite new in Debian <alezost>I guess if we rename "guix.d" to "elpa", the packages will also appear in the package list <mthl`>in debian the directory is name elpa-src <alezost>is it added to `package-directory-list' variable? <jlicht>does anyone see any use for a '--with-patch[es]=' package transformation option? <alezost>jlicht: I don't have a need in it, but you can propose it on guix-devel, perhaps it will be useful for someone <mthl`>They put '/usr/share/emacs/VERSION/site-lisp/elpa' in `package-directory-list' <mthl`>and this directory contains the subdirectory for Emacs packages which then contains symlinks to the files in "/usr/share/emacs/site-lisp/elpa-src/PACKAGE/..." <alezost>I think it's one of the default element of package-directory-list <mthl`>s/subdirectory/subdirectories <alezost>ah, I see, thanks for the explanation! <mthl`>... agree with you than the name "guix.d" is confusing <jlicht>heh, TIL that `#:parallel-build? #f` could have saved me quite some headaches XD <bavier>jlicht: yes, those issues are sometimes difficult to diagnose <jlicht>is there some way in which to somehow apply `#parallel-build #f` only to a subset of make targets? <bavier>jlicht: you'd need a custom build phase for that <jlicht>that is probably more of a hassle than it might potentially be worth then ;-) <bavier>jlicht: or patch the makefile ;) <jlicht>bavier: for my specific situation, it could potentially shave some 2 mintues off a build that takes about 31 minutes in total ;-) <joshuaBPman>hello. So I did a completely stupid thing just now. I had installed guix with a seperate / and /home partitions. Well I downsized my /home partition w/o downsizing the filesystem. I've already ran mkfs.ext4 on my /home partiton again. So there's no way to salvage it. do I need to completely re-install guix? Or can I run reconfigure and be ok? <cbaines>joshuaBPman, what is the current state of your system? e.g. does it still boot? can you login as root? <joshuaBPman>cbaines: I cannot log in a my normal user. I am currently logged in as root. (running gnome as root with a terminal open). <cbaines>If you are trying to use reconfigure to repopulate the lost files, it might work, and I see no harm in trying <joshuaBPman>well. I ran `sudo guix system reconfigure` and rebooted. and it didn't work. But I supposed that only reconfigured stuff for root. hmmm. I might just have to reinstall. <cbaines>joshuaBPman, I don't think reinstalling is necessary yet <cbaines>does your users home directory exist <cbaines>Ok, I guess that is not sufficient to allow logging in as them? <joshuaBPman>My normal user home directory does not have a .guix-store dir. <cbaines>The shadow package contains useradd, that might be able to help <cbaines>I'm just looking at the documentation at the moment <cbaines>Another option that might work, would be to delete the user (using userdel), and then run reconfigure <cbaines>If the account does not exist, and the home directory does not exist, then reconfigure might work? <joshuaBPman>well after installing shadow, I still could not run useradd. So I'll try deleting /home/joshua and then rerunning `sudo guix system reconfigure /etc/config.scm' <joshuaBPman>yeah. It didn't create the /home/joshua. I'm just going to reinstall. Won't be too hard. I'll remember to run guix pull before running guix system init <jsgrant>Does GuixSD support UEFI now? I'm thinking of jumping back into it all, sooner than later. <jsgrant>Don't see anything explicity specifying this on cursory inspection; I'll go NixOS for now knowing it works, and maybe retrograde in that direction later. <joshuaBPman>so I am re-installing guix. I just ran guix pull (before guix system init) and guix pull failed. It said no cod efor module (gnu packages asciidoc). so I guess I'll install an outdated version of guix. And then later update. <mthl`>(gnu packages asciidoc) has recently be moved to (gnu packages documentation)