***samis is now known as CompanionCube
<OriansJ>nckx: well the 2 opcodes that I found where run from superuser space and are now listed as official errata for the i3 chips in question. Based on the encoding, I wonder if it was a RISC core debug instruction that isn't supposed to be passed unmodified to the core. <mbakke>jlicht: Have you had any luck with later nodejs versions? The current is failing for me on 'core-updates' due to libuv being too new. ***tg` is now known as tg
<j3kyl_>gitlab have been receiving a lot of neat features that now I can say I dont miss github ***rekado_ is now known as rekado
<ngz>Hello. Where do you insert lines like "export SSL CERT DIR=..." when using Guix on top of another distro? I used to have them in ".profile" but, for some reason, I can no longer start Gnome (GDM is fine though). I have to rename ".profile" to ".profile.bak" so I can start it, but obviously, I don't have any configuration loaded. <mange>I load mine in .profile, and I used to be able to log in with GNOME (I no longer use GNOME, but I assume it still works). <mange>What specific things are you trying to add to .profile? Can you put them in a paste? <ngz>I only export environment variables and source $HOME/.guix-profile/etc/profile <ngz>I can try to paste it, but it's not going to be easy since I'm on a terminal right now (no Gnome) <mange>I have found that sometimes exporting particular variables can cause problems for programs, like GNOME. I've had particular problems with XDG_DATA_DIRS. <mange>I make sure to put something like this before I source my profile: <mange>if [ -z "$XDG_DATA_DIRS" ]; then export XDG_DATA_DIRS="/usr/local/share/:/usr/share/" fi <mange>That just sets it to the default value that programs are meant to use if it's not set. That way if my Guix profile tries to add to it the base will still be the default. <ngz>I don't export XDG_DATA_DIRS in my .profile but $HOME/.guix-profile/etc/profile might. Let me check. <ngz>For some reason it defines XDG_DATA_DIRS. <mange>Okay then, maybe my fix will work for you, too! <ngz>so if I use your trick, i.e. insert the conditional before sourcing $HOME/.guix-profile/etc/profile in .profile, it could work? <mange>I don't want to promise too much, but I remember that fixing issues that I was having with my desktop. <mange>If it does, it might be worth opening a bug about it and adding it to the manual. <ngz>ok, I added your test as a single line at the very top of ".profile". Let's see what it does. <ngz>mange: No luck. It goes past GDM but displays as when you don't have any window manager defined: a terminal in the upper left of the screen and nothing else. <mange>Ah, bummer. You didn't happen to accidentally select the "Default Xsession" option in GDM, did you? :P <mange>If it's not that, then I don't have any other solid ideas for what it could be. ***slyfox_ is now known as slyfox
***jonsger1 is now known as jonsger
<jonsger>guix package --show is faster then zypper info :) <civodul>package descriptions are also l10n'd in RPM/zypper, right? <civodul>mbakke: thanks for removing the GCC ICE workarounds! <jonsger>civodul: will guile-gcrypt became a dependency for guix? <civodul>you're welcome to make a package for openSuSE :-) <jonsger>civodul: the COPYING file is missing in EXTRA_DIST in the Makefile.am, so I can't get installed. I think we should add it there :) *dustyweb shoots a hodgepodge of thoughts on security stuff off to guix-devel <dustyweb>jonsger: that could be useful... though I seem to remember that ppc64's instruction set is a bit hairier than RISC-V because it's aiming for ease of porting some x86 things... do I remember right? <dustyweb>still, useful for the libre hardware design stuff <jonsger>I guess that riscv has a "cleaner" instruction set, as ppc64 has already some history :P <rekado>dustyweb: what are your thoughts on SELinux? <jonsger>rekado: what do you think about apparmor compared to selinux? <rekado>jonsger: I only really know SELinux, and even there “know” is a bit of a strong word. <rekado>searching around I see that apparmor labels the file path, whereas SELinux labels the inode. <rekado>I think the arguments for/against SELinux/Apparmor that rely on how easy/difficult these things are to set up don’t really apply in a system like Guix, where I assume it to be easier to compose and abstract over policies. <dustyweb>rekado: iirc from what I've read of SELinux, it's the wrong approach <dustyweb>yes, for those who don't know, Shill is a shell using Capsicum capabilities <dustyweb>RBAC has more fine grained ACL but it's still taking a "perimeter security" approach <dustyweb>E in a Walnut has something to say about that <dustyweb>> With tools like access control lists and firewalls, we engage in "perimeter defense", which is more correctly described as "eggshell defense". It is like an eggshell for the following reason: while an eggshell may seem pretty tough when you tap on it, if you can get a single pinhole anywhere in the surface, you can suck out the entire yoke. <dustyweb>the right approach instead is to go full principle of least authority: only hand the capabilities necessary for an operation to happen to the program in question <rain1>what do you think about openbsd pledge and unveil dustyweb? <rekado>(I totally misunderstood the term “eggshell defense”, because eggshells are a really good defense against slugs in a garden) <rekado>dustyweb: principle of least authority is best. Is that what capsicum provides? <dustyweb>rekado: yes, it provides a capability mechanism <dustyweb>it's similar to what the Hurd uses with Mach Ports <rain1>pledge lets a program drop the ability to use certain syscalls, unveil jails a program to only be able to access a certain set of paths <rain1>i have been impressed with it <dustyweb>rain1: I mean, sounds better than nothing, but it doesn't sound very composable <dustyweb>it still sounds like a system with a central set of permissions <dustyweb>the nice things about capabilities is they're like passing around arguments to functions <rain1>what i like about it is that, while it is not a full blown ocap system with fine granularity, it is something they were able to roll out in practice very quickly <dustyweb>rain1: yes, it's helpful to be able to roll those things out <dustyweb>though I think it can create a sense of complacency the way SELinux does <rain1>it may ease the transition to a much more solid capability based design <dustyweb>I think openbsd's capsicum support is more important <rekado>so, with capsicum the tools need to be modified to make use of it, right? <efraim>That like pledge it's far easier to implement on new tools than to retrofit <rain1>pledge was invented then added to all the demons in openbsd <rain1>in doing this they noticed minor design flaws in some of the demons that had to be improved to be able to apply pledge *jonsger hast still no idea how to use the guix selinux file <dustyweb>one nice feature of the Hurd is that you could compose a Hurd on top of Hurd that had less authority to run things... like containerization but better implemented ;) <dustyweb>IMO in some ways that's a better path for retrofitting on top of the existing POSIX tools we have <dustyweb>though I *do* think probably all gnu tooling should be updated for capsicum support... if only capsicum can arrive in Linux <civodul>jonsger: COPYING is automatically added to the tarball if you run "make dist"; it doesn't have to be explicitly listed in EXTRA_DIST <rain1>I would be worried about the potential technical debt, one may end up having to maintain the cap branch <ng0>efraim: I had a discussion with someone about pledge-like support in Linux <ng0>I have to remember the name and details <ng0>but basically there was a repo which implemented it for what we have in Linux <ng0>or they wanted to pick it up again <ng0>the trouble with pledge is that it is in the kernel <efraim>I feel like most of the time we just drop things in a container and call it a day <ng0>I played around with a pledge(2) implementation using seccomp, but never really <ng0>finished it. The main problem is that seccomp is inherited on execve(2), while <ng0>pledge(2) is not. This means every program that uses the exec promise can't be <ng0>restricted using seccomp. Another problem is that pledge(2) internally whitelists <ng0>some paths based on the given promises like `/etc/resolv.conf`, with seccomp alone <ng0>its not possible to filter seccomp by paths, because the bpf programm can't look at <ng0>the memory of pointers, filtering by other arguments like flags for open works tho. <ng0>there's a repository.. will look into that now <ng0>no new commits on master though <ng0>fwiw, Theo publicly offered to help systems who want to adopt pledge, but knowing it can be difficult for Linux. *ng0 catches up with rest of the log <rain1>ahh it would be so cool to have a cap based OS from the start, and programs working with s-expressions for interchange instead of "universal plaintext" <rekado>I wish I could spend more time contributing to the Hurd. It’s a fun system and it’s early enough to do lispy things at a lower level. <jonsger>civodul: I could already use it, because its in the tarball. RPM was more intelligent then I tought :P <civodul>rekado: here's a plan: once Guix 1.0 is out (i.e., soon), we all go hacking on the Hurd *civodul attempts to initiate an IRC join <civodul>rekado: i just noticed we got contributions from the MDC, nice! <rekado>yes, I’m training my new colleague. *jonsger tries to let opensuse make the step to guile2.2 <civodul>mbakke: hey! how's everything going with glibc 2.28? <mbakke>civodul: Unfortunately I don't have any more than the patches I sent; I've been busy higher up the chain :/ <apteryx>do we have other themes than gnome-standard-themes and MATE themes in Guix? <apteryx>I'm trying to match my host theme with Guix themes for proper integration, but the Linux Mint here doesn't play well with Adwaita unfortunately. <apteryx>roptat: arc-theme worked a treat to unify Linux Mint 18 with Guix :) <civodul>mbakke: no problem! would you like help on specific issues? <mbakke>civodul: Pretty much all gnulib consumers need patching...so yes please :-) <ecbrown>52KiB download from mirror.hydra.... *groan* ***elky is now known as Guest25195
*ecbrown wonders whether guix plays well with squid <nckx>ecbrown: Do you get similar speeds from Berlin? <nckx>s/Berlin/berlin/, for once. *vagrantc wonders if qtwebkit is still borked <vagrantc>my last attempts ran out of disk space, and then i freed up a bunch more disk space, and it ran out of ram ... added some swap, still ran out of ram <nckx>vagrantc: It still fails on my build box, but that doesn't keep logs... <vagrantc>8GB of ram ought to be enough for anyone! :) <vagrantc>oh yeah, i also tried building it with only 1 core, which helped a lot ... but still ran out of ram in the end <ecbrown>nckx: not sure if berlin would be faster -- unfortunately it was a system init with custom kernel and i didn't want to interrupt it. i always have good luck with https://hydra.gnu.org though i wonder if i'm being naughty by not using mirror. <lfam>ecbrown: Please use mirror.hydra.gnu.org <lfam>Is there a problem with the mirror? <lfam>Sorry that I'm jumping in to the conversation having missed the earlier parts <lfam>And it was faster to connect directly to hydra.gnu.org for the same file <lfam>In general, hydra.gnu.org can only support a single-digit number of users at one time, so please try to use its mirror and berlin.guixsd.org. <lfam>In my experience, berlin.guixsd.org is fast and has substitutes available very quickly, so it could help you <ecbrown>i'm still trying to figure out strategies for making sure that i'm not having to compile e.g. webkit and qt on my machines... is berlin faster than the official server at having up to date binaries and what not? <lfam>Yes, in my experience substitutes are available surprisingly quickly from berlin.guixsd.org <efraim>I have some notes for when I try to port guix to powerpc 32 bit, I'll see if I can dig up something later to work with the OOM linking problem <lfam>I don't know off the top of my head if berlin.guixsd.org is part of the default set of substitute-urls. <efraim>Only on aarch64 in the install script IIRC <ecbrown>i'm trying to figure out if i should just have a fat tank compile machine on amazon <nckx>Is there a hardware porn post for berlin. somewhere? It does seem blazingly fast. Or I was too used to hydra.