<scottviteri>Hello! I am trying to set up my configuration so that I can run X11 and i3. I don't need most of the things in desktop services, and in my configuration I only set the xorg keyboard layout and incluse %base-services. I run X using "DIR=/run/current-system/profile" and "$DIR/bin/xinit -- $DIR/bin/Xorg :0 vt1 -keeptty -configdir $DIR/share/X11/xorg.conf.d -modulepath $DIR/lib/xorg/modules", and an .xinitrc just with "exec i3". .config/i3
<scottviteri>is empty. I am able to run this xinit command from non-root user's login shell, but I am then confronted with a frozen i3 landing screen.
<scottviteri>I have also tried giving up and explicitly including gdm-service-type in services, to no avail. I have also tried using the whole %desktop-services but this also fails. I would appreciate any possible help here!
<joshuaBPMan>scottviteri: Can you put your config.scm online where we can see it?
<apteryx>rekado_: yep, I found out :-) it's a neat feature. Thanks!
<PotentialUser-69>apteryx: Hey, my question is how many settings do I have to change on the remote machine? I am trying to deploy a file from my local to remote but I keep getting a status 1 error exit and not sure where to go from here.
<PotentialUser-69>error: remote command '/run/setuid-programs/sudo -n -- guix repl -t machine' failed with status 1
<apteryx>perhaps the problem is that the ssh is running as non-root, and the non-root user can't use 'sudo' non-interactively?
<apteryx>there's a sudoers example in the manual under info '(guix) Invoking guix deploy', if you are using a non-root user for SSH
<apteryx>you have to do that config on the remote machine (the one being deployed to). It gives allows sudo to run without a password (non-interactive).
<rekado>mothacehe: but this doesn’t sound like a terrible mistake
<mothacehe>I restored to a personal backup from 14/09 which means that we lost a few evaluations. Having multiple screen sessions to multiple sqlite database is really dangerous, I should have been more more careful.
<jlicht>answer to my own question; adding --network _also_ makes the container part of the same network space (e.g. port 8181 in my container == port 8181 on my host machine)
<nckx>civodul: Oh, I see you changed the pastebin back to Debian's. This is tedious. We should find a less fragile one... Any arguments against paste.gnome.org? Tor'd just fine here. Default TTL might be a bit low.
<civodul>nckx: i don't have any opinion, someone just said paste.debian.net was back so i put it back there
<civodul>(it still doesn't work for me, not sure why)
<jlicht>I'm running guix system container with openssh-service-type, and the ssh key provided in `authorized-keys' isn't getting me in. The permissions for "/" (???) are wrong in the container, according to /var/log/debug: https://paste.gnome.org/pxz9u9gzm
<civodul>jlicht: can you enter the container (with nsenter or "guix container exec") and check the permissions on / ?
<jlicht>civodul: I'll need some time to wrap my head around this. How do you find out the pid to use for guix container exec? Right now, it's a guessing game with ps aux 'till I see the correct hostname ;-)
<nckx>raghavgururajan: Could you either fix the bot (preferred; the fix looks trivial: retain the first <title> element, not the last) or disable it so we're not wasting $someone's resources by running a blocked bot? Thanks!
<roptat>cbaines, I'm still having some troubles with my git setup: whenever I push a commit, new objects are created in the repo with access 600 instead of 640, so the anonymous access doesn't work (and refs/head/master also gets set to 600, so all you can do is clone an empty repo)
<guix-vits>+1XP: `sudo herd restart syslogd` <-- also restarts dbus and elogind (and therefore, sway).
<roptat>is there anything you do in gitolite to ensure everything has read access for the group?
<civodul>fun fact: i have a newish external monitor that causes kernel crashes sometimes after it's gone to sleep
<bdju>Can someone please enable debug symbols for the dino and quaternion packages? I'm having some issues in both and it's looking like I can't get good enough info to the devs for debugging at this rate.
<PotentialUser-16>I have Guix Deploy working. I am confused that the deploy doesn't replace the exisiting config file and that a reconfigure on the remote system will remove any deployment packags installed. Am I missing a step?
<jlicht>PotentialUser-16: What do you mean with 'existing config file'?
<PotentialUser-16>On my remote machine, I have a config.scm that exists from a basic default install. I then do the deploy and it installs some packages for me. Those packages do not show up for me when using guix package -I and I don't see the config.scm modified in place to add them.
<PotentialUser-16>I was expecting that if I push an operating-system through deploy, it would overwrote any existing config.scm
<PotentialUser-16>roptat: I will look into that. If I am going to use guix deploy to manage minion machines, I want the files being pushed to stay on the machines and not be removed if I run a reconfigure, such as unattended-upgrades
<nckx>mfg: Aren't you missing another , before the call?
<bdju>str1ngs: you mean like a whole second line? I want both help-mode and info-mode in there
<nckx>mfg: I recommend writing (list "-DBUILD... instead of `("-DBUILD... for this reason. More readable.
<str1ngs>bdju: right it does not take a list. so you would have to call it for each mode you want emacs to be the initially mode for.
<str1ngs>bdju: evil-buffer-regexps does take a list but it's a regex based on the buffer name.
<str1ngs>bdju: also this is way I switched from evil bindings to pure emacs bindings. because there were many cases like this I had to manually account for all the time. so I can appreciate the frustration :)
<bdju>str1ngs: I tried that as a secondary line and it doesn't seem to be working. I see this in the messages buffer now if I press n or p while in info-mode: user-error: "initial-state": pattern not found
<bdju>maybe info-mode was the wrong thing to write
<bdju>oh wait. it's assuming I'm hitting n as in "next search result"
<bdju>so it's just not doing anything and it's taking an evil-mode bind. I just overthought it
<guixer>Hi there. I've used a single profile with a dedicated manifest with all packages that I liked to use on my system. I converted the single profile into several profiles. I successfully sourced all profiles within my .profile. Only problem I can see is that gtk-themes do not work properly. I see the default theme in gtk apps and not the papirus dark,
<guixer>which I configure with xsettingsd. Also icons do not seem to be available in nm-applet. I think it must be linked to some gtk-cache problem, but I don't know how to solve this.
<guixer>gtk-update-icon-cache: Failed to open file /home/guixer/.guix-profile/share/icons/.icon-theme.cache : Read-only file system
<mfg>nckx: so i should use (list "" ... ,(string-append ..))?
<jlicht>guixer: I have no experience with your gtk issues, but when splitting stuff up in several profiles, be sure to include the packages that actually have the 'native-search-paths' field installed in _that specific profile_
<mfg>so i guess i should reread quoting in guile :D
<apteryx>guixer: it's probably the XDG_DATA_DIRS environment variable that's missing
<apteryx>it's set by default from your /etc/profile, but it only take into account the system profile and the user profile.
<nckx>mfg: That should work if I'm counting quotes correctly 🙂
<zimoun>civodul: Hi! I am playing with #43578 and rewritting the inputs. I hit some cases where it is not doing what I expect (but expected by ’package-mapping’ & co.). The offending ones modify the field ’argument’ (e.g., emacs-magit using emacs-no-x). Do you think something is doable for such cases?
<mfg>nckx: why does the icecat build take 4 (more) days o.O?
<bdju>str1ngs: thank you, it was 'Info-mode with the capital I. Works now!
<vagrantc>how do we find out who the moderators of this channel are? yesterday someone dropped some inappropriate links thinly disguised as referencing a CVE ...
<mihi>janneke, mothacehe, My intention was just be able to download it in 5 minutes vs. in 1 hour. I don't care if you serve it as .img.[gx]z, or as qcow, or even if you make your webserver send it transparently encoded as "Contnent-Encoding: gzip". For my workflow the next step is to throw it at vboxmanage to convert to VDI anyway.
<zimoun>civodul: done on guix-devel. Even if it is trivial. :-)
<nckx>mfg <IceCat>: Because I'm building without substitutes on an old, underclocked laptop & dependencies keep failing non-deterministically. So many test ‘failures’ due to authors pulling random numbers out of random holes to serve as pointless timeouts.
<nckx>guixer: I missed your message, but the thing you asked for has been done.
<nckx>50 shades of fun. Mind you, IceCat itself might've taken 4 days to build on this machine regardless, but this certainly isn't helping matters.
<mfg>nckx: yes i can imagine tha tit takes reeeaaally long, i mean compiling llvm takes forever, and icecat depends on rust and therefore also on llvm ?! i had to upgrade my RAM to not run out of memory with 24 build threads... and it still takes ~30 minutes or so
<nckx>mfg: ‘Everything‘ [graphical] depends on LLVM through Mesa, but indeed, it seems that so does Rust (not rustc). Rust's ‘problem’ for the self-builders is that we build something like 20 Rust versions in serial. No way around that though. Not complaining.
<rekado>mesa only needs LLVM for drivers; I wonder if we could modularize Mesa a bit.
<rekado>“grep llvm -r” shows me lib/libOSMesa.so.8.0.0, lib/dri/nouveau_drv_video.so, lib/dri/iris_dri.so, lib/libXvMCnouveau.so, lib/libxatracker.so.2.5.0, lib/libvulkan_radeon.so, and lib/vdpau/libvdpau_nouveau.so.1.0.0.
<nckx>Well, the entire design of things like Guix is antithetical to how libGL was supposed to be used.
<rekado>not sure if these are *all* drivers, but perhaps something can be done about this.
<nckx>It's supposed to be an OS API like the kernel. Not that that works in practice, I'm sure.
<BlackMug>if malicious package downloaded by guix package manager, what kind of damages can be done to the host (since its installed under user privileges)?
<apteryx>if you run such malicious program as your user, your $HOME is at risk. If you run it as root... it can do anything.
<nckx>As much as the user who eventually runs them, which can be root in the worst case. Same as other distributions. Guix packages aren't sandboxed or (really) installed as a regular user: regular users simply talk to a daemon that performs builds in a relatively restricted & sandboxed environment, but still runs as root.
<vagrantc>BlackMug: main thing is it isn't installed setuid/setgid ... but otherwise it can do anything the user can do
<celestialparalla>> if malicious package downloaded by guix package manager, what kind of damages can be done to the host (since its installed under user privileges)?
<celestialparalla>iirc, no damage can be done by the actual building/downloading alone of a package, since it's all sandboxed and is meant to withstand malicious users on the system as well. obviously, if you run the programs *in* the package, then they can do whatever under the user account you ran them under
<vagrantc>(and there are a lot of userspace exploits to escalate privledges)
<bdju>is anything done to the Xonotic build that would break the stats tracking?
<nckx>In this, Guix is very much like more traditional distributions.
<vagrantc>it's *slightly* safer building arbitrary code due to the containerized build environment, but not much safer, i would guess, since the containers aren't designed to be security hardened
<BlackMug>oh i see, then packages coming from Guix needs as well sandboxing like apparmor or selinux or so
<vagrantc>you can use containers to add some degree of added security, but there are so many holes in the implementation...
<celestialparalla>BlackMug: the dependency headache is something all package managers intend to solve; what makes guix special is its transactional package management (so halfway-completed upgrades can't break your system), reproducible builds (so different people build the same pakage the same way), and some things like the ability to fully describe a system with a scheme file and to have different profiles.
<BlackMug>vagrantc damn, and what your future road map for guix on gnu-hurd same no security in mind implementation?
<nckx>civodul: Right, they are a ‘building block’, or at least made of ‘building blocks’, that can help you achieve it.
<civodul>vagrantc: i'm not sure we can quantify the holes or that number would be decreasing, no? :-)
<nckx>It's the ‘helps strengthen the immune system’ of security but fine.
<BlackMug>celestialparalla yes i know these interesting features, but something need to be done if the package itself hacked after installation or its malicious from the source of installation.
<nckx>BlackMug: Guix is a package manager, you're looking for something (much) more.
<vagrantc>civodul: i would guess both increasing and decreasing, but that's purely speculative.
<apteryx>BlackMug: unlike other platforms, the packages allowed in Guix must be free software, and are all manually curated and reviewed or at least pushed by trusted committers whose commits are authenticated with their GPG key; that's a good security benefit in itself.
<celestialparalla>BlackMug: no package manager that i've ever heard of tries to accomplish that, and i do not believe it is possible. package managers just put the files on your system. the closest guarantee that you get from any package manager is, like apteryx said, that whoever made the repos for your package manager looked over the packages, and that what you're installing is the same thing they vetted.
<BlackMug>nckx yes im talking actually about guix the distro more than the package manager
<vagrantc>and guix has a known (and possibly reproducible) set of bootstrap seeds which very few distributions can claim
<vagrantc>most distros probably don't even know what binaries were used to bootstrap the distribution
<celestialparalla>vagrantc: probably whatever the first person who invented the distribution was running before they invented it lol
<vagrantc>so in that sense, guix's auditability is way better than most, for the potential security implications
<vagrantc>and the bootstrappability of guix has been improved with each of the last several releases, and will likely continue to improve
<BlackMug>celestialparalla i see, but other distros currently offering sandboxes to the packages either through Mandatory access control or Namespace this is not in guixsd yet and i dont know if something invented for hurd when guixsd 2.0 gonna come out
<celestialparalla>yeah. guix excels on that front. and auditability + only vetted, libre packages in the main repo [or as guix calls it, channel] is pretty good security--but it doesn't secure you against manually putting in a malicious package definition or repo/channel, which is what i thought BlackMug was referring to.
<vagrantc>i vaguely recall there was some selinux support ... but that sort of security policy requires per-package maintenance
<vagrantc>and each and every instance ... which is cumbersome with the guix model, since you can't set permissions on /usr/bin/FOO, you have to set permissions on /gnu/store/12345678...abcdefg/usr/bin/FOO
<vagrantc>so the policy has to change with each build of the software
<celestialparalla>BlackMug: as a workaround for the time being, if a particular package worries you, you can try using "guix system vm" or "guix system container" to quickly spin up a VM or container containing it, instead of installing it on your main system; or you can install it only into the profile of a separate user who is unprivileged and does not have permission to do the damage you are worried about. both of these should
<celestialparalla>protect you, if you know in advance which package is likely to be troublesome
<drakonis>civodul: does guix provide content addressed storage anywhere other than guix deploy?
<celestialparalla>i imagine it'd be possible to make guix itself set up the policies, but that would probably require a bit of mucking around.
<nckx>‘Mandatory access control or Namespace’ - again, one of these is a security feature, one is not (at least on Linux). Maybe the Hurd is better in that regard. Guix supports containers pretty well, AFAIK, but containers != sandboxes.
<drakonis>its the only place i've seen it refereced in the manual and source
<drakonis>nckx: container tooling is reasonably mixed right now
<civodul>drakonis: what do you mean by "provide content addressed storage"?
<civodul>what can't we change /proc/sys/kernel/perf_event_paranoid any longer?
<str1ngs>I'm surprised I would have thought IPFS's markle tree hash would be a good candidate for say nix or guix CAS
<nckx>msavoritias[m]1: They would be welcomed as long as the benefit outweighs the technical/maintenance/performance/complexity/... costs (don't be intimidated: that's not a terribly hard bar to clear). The Guix daemon has an SELinux policy file, it's just under-maintained, and probably too fragile as-is. As far as I'm aware there is no such thing for the entire package collection or operating system yet.
<nckx>BlackMug: Nobody & everyone 🙂 There are no official package or subsystem maintainers. Only people with commit access and an open patch tracker. In practice, some packages are maintained almost entirely by a single person, and it's a good idea to run your own patches by them, but they don't own the package.
<drakonis>there's a fairly significant amount of impressive PRs lined up
<nckx>BlackMug: Of course not. That is a bizarre conclusion to derive from my words, and a pointlessly combative method of discussion. I'm going to read about Nix instead. Others can address any further confusion you may have.
<jonsger>bavier[m]1: I saw that you have some stuff for anbox. Very interesting...
<civodul>anyway, i'm critical, but i think it's definitely interesting development to follow
*nckx forwards 2 ‘no longer using Guix, please close‘ bug mails, feels a bit down, remembers all of their own exes, has fond memories of basically all of them (even Gentoo, that crazy bastard), happy again.
<nckx>civodul: FWIW I greatly appreciate your positive criticality 🙂
<jonsger>I didn't noticed that we have no fpc (Free pascal), so I can finally package ultrastardeluxe :P