<bdju>can guix packages pull from master? I've got one I haven't submitted for a thing that only has one release and there were important changes after the release <bdju>I haven't yet changed my local version to pull from master so I'll have to figure that out also <leoprikler>if I understand this correctly, you want your package to point to the current latest commit <leoprikler>hence you should use the commit hash (of current master) <bdju>yes I think your thought process lines up with mine <bdju>I guess if it uses a commit hash it isn't all that different from a release so it's probably fine <bdju>I had something like the *-git packages in the AUR that keep updating in mind at first <leoprikler>Well, you can update the commit hash whenever you want to <bdju>I still have to figure out how submitting a package works also <bdju>I am just entirely unfamiliar with the process I guess. I have a local package that I've been meaning to submit and I just never looked into it much <dattashantih3>Is the compiler a library was built with encoded in the guix hash? <dattashantih3>I was wondering if there was a way to have the same libraries built with different compilers in separate profiles <dattashantih3>Anyone know how to build libraries with a variety of compilers? <jackhill>dattashantih3: I think you may have to create a different package that using a different compiler. The different common lisp packages and python2/python3 packages might be good places to look <jackhill>maybe if we ever get "parametric" packages (like gentoo use flags) it will be easier <dattashantih3>jackhill: that is unfortunate. I was looking for something similar to spack where I could easily create profiles containing libraries compiled with different compilers. <jackhill>dattashantih3: indeed that would be neat, but as far as I know that would need code that is not-yet written. I can imagine something that would programaticaly re-write packages to use a different compiler. <jackhill>Thanks for sharing spack, I wasn't familiar with it. :) Maybe their technique could be implemented with Guix <jackhill>I see that one of their use cases is HPC. There are Guix HPC people, but I'm not one of them. You may want to ask again when rekado is around or ask on help-guix@gnu.org <dattashantih3>jackhill: thanks for the info, I was hoping to use guix specifically for HPC where this is a common use case. <marusich>hello, roptat! hope you're doing well today. <pkill9>bdju: i want to make a 'url-fetch' that gets the latest git master, so it wouldn't take a hash but just get the latest one, but I don't understand how the downloaders work from looking at the code <pkill9>bdju: you can pass a commit on the command line with `guix build --with-commit=<package>=<commit>` <roptat>bdju, pkill9 or even --with-branch=master <mitescugd>question from someone who is not experienced with either scheme nor containers: isn't it better for guix environment -C to not assert container features? I could then either run with sudo (which already should have cap_sys_admin) or tweak my capabilities <mitescugd>Or better said, to not assert "unprivileged user namespaces" <mbakke>mitescugd: guix environment --container only supports unprivileged containers <mitescugd>thank you mbakke, I looked over the differences in the code to understand more what differences are there ***kdtsh[m] is now known as kdtsh
<mitescugd>privileged containers are just containers run with super-user privileges (i.e: root). afaik unprivileged containers are a source of security vulnerabilities and have them disabled by default. `guix system container` would create privileged containers, as you are only able to run them as root. docker, if the daemon is ran as non-root would basically be unprivileged containers. <brendyyn>I added sway to my os config but it doesn't appear in the gdm menu. what gives? <mbakke>brendyyn: I think wayland is not currently supported with GDM, you can try SDDM instead. <brendyyn>It appears sddm has no default service config <brendyyn>Why does (service gdm-service-type) work when added to services, but sddm requires (service sddm-service-type (sddm-configuration)) <zacts>what are the primary difficulties with getting KDE up-and-running on Guix? <OriansJ>zacts: the lack of people willing to test and document their learning or commiting patches to make the experience more enjoyable <brendyyn>I've currently got sddm running at least but am struggling to set the keyboard-layout <brendyyn>ok i got the layout working, but it seems the sddm service doesnt allow being extended like the gdm one does <pinoaffe>is there a way to add kernel parameters in the system config in guix? (so my grub boots the system with those parameters appended) <efraim>I haven't gotten enlightenment-wayland working with sddm yet <mbakke>efraim: it should be sufficient to install a session file in the same location sway adds it <efraim>mbakke: I'll have to look into that ***jonsger1 is now known as jonsger
<Aurora_iz_kosmos>Is there a standard integrated Firewall for GuixSD or is it simply mundane iptables/firewalld? <efraim>mbakke: sway has %out/share/wayland-sessions, enlightenment-wayland only has %out/share/xsessions <OriansJ>Aurora_iz_kosmos: well standard iptables works and until someone comes up with something superior it is what is generally used... *vagrantc should try sway without a display manager again... <vagrantc>i thought iptables on recent kernels was just a compatibility layer to nftables <Aurora_iz_kosmos>OriansJ: Alright, I was mostly asking in case I'd missed some relevant section about it in the manual. <Aurora_iz_kosmos>OriansJ: Do you think there's anything that would prevent firewalld from working on Guix? <efraim>I think I found a bug in the enlightenment codebase, it only installs the enlightenment-wayland.desktop file if it's built WITHOUT wayland support. I'll have to test if that makes a difference <OriansJ>Aurora_iz_kosmos: well if firewalld has a systemd dependency in behavior; there might be an issue but honestly I don't know since I don't use firewalld as secure rules can be rather simple: https://paste.debian.net/1108391/ <Aurora_iz_kosmos>OriansJ: The thing is the complexity of rules starts growing wildly the second you try to make something. <Aurora_iz_kosmos>Even something as simple as "firewall-cmd --zone=public --add-port=8080/tcp" <Aurora_iz_kosmos>On a somewhat different topic, what's the recommended way of locally caching Guix substitutes to save upstream bandwidth? <efraim>I run a guix publish server on each of my machines and put them higher than the official substitute servers <wdkrnls>could the OS installation use these publish servers if available? <wdkrnls>I'm having trouble completing substitute downloads from the official servers at times. <wdkrnls>This has so far resulted in 5 failed attempts to install guix on my desktop computer. <OriansJ>Aurora_iz_kosmos: I've been a big believer of simplicity and isolation; makes it harder to shoot myself in the face. <wdkrnls>if it was otherwise possible to build a disk image with everything I needed for a minimalist system, that might work even better. <Aurora_iz_kosmos>wdkrnls: I think that may be possible using the manual installation process, much like one can do with Arch Linux. <Aurora_iz_kosmos>wdkrnls: It would however be nice to have such an option in the friendlier GUI method <rekado>I’m looking into this “demon voice” audio problem in icecat that can be observed for some embedded videos <rekado>I tried to reproduce this with just ffplay, so I downloaded the exact same video that icecat reported as having streamed, but I could not reproduce it. <wdkrnls>Aurora_iz_kosmos: I think I will have to try out the manual installation method, then. <Aurora_iz_kosmos>rekado: Does Icecat have this problem if you attempt to play back the video when downloaded locally? <htsr>is is possible to add a custom channel for the entire system? like in a operating-system declaration <htsr>i could use the skeletons declaration so every new users will have my ~/.config/guix/channels.scm but is it the right way? <htsr>and it's only for new users... <leoprikler>htsr: as far as I know, there is no operating-system primitive for this <leoprikler>as you've pointed out, you can abuse skeletons, but may I ask why you want to do that in the first place? <htsr>I would like to use guix deploy to deploy a website. it would be nice to have it as a package so i can rollback <htsr>does guix deploy work if i specify a package in a channel unknown to the destination? will it use my local store? <leoprikler>Given that #:build-locally exists, I assume you can build the package on your machine and ship it to a Guix unaware of the channel <leoprikler>I must admit, I haven't tested it yet, though :) <htsr>the guix deploy manual page is no more? <leoprikler>however, looking at git, the last commit that referenced deploy was on 2019-09-23 <leoprikler>(give me some time to run guix pull and guix upgrade) <roptat>I think guix deploy does build locally and push the resulting os to the target <roptat>so the target doesn't have to know about the packages used on your local machine <roptat>actually, it would be an issue even with only the default channel: if you don't have the same version of guix, you would be in trouble if the target had to know about the packages you build <leoprikler>is there even a case where one would want to set #:build-locally? to #f? <roptat>#:build-locally? is related to build offloading <roptat>in fact, packages default to #:build-locally? #f <leoprikler>even if it's documented as part of machine-ssh-configuration? <roptat>which means the package can be offloaded <roptat>right, I was thinking about something else, sorry <roptat>I think guix deploy will build the derivations locally (and compute them from the locally available guix, not the remote guix), so you don't have to add your channel on the remote <pkill9>is there a way to have the remote machine build and deploy the system with `guix deploy`? <leoprikler>pkill9: setting #:build-locally? to #f will build it on remote <leoprikler>I think offloading rules will apply as normal, though <roptat>does it mean it builds the locally computed derivations on the remote, or does it use the remote guix? <leoprikler>roptat: I honestly have no idea. Going by the description, it looks like our good old friend UB :) <leoprikler>Aurora_iz_kosmos: The Guix deploy example was a forum, though, IIRC :) <Aurora_iz_kosmos>leoprikler: Oh right. That would be more the kinda thing is for. Huh, it finally got mainlined. <leoprikler>by the way, has someone managed to package Polari yet? :) <bdju>just saw the rockchip stuff in the guix update. very cool. will this mean rk3399 boards will work with guix system soon? <htsr>thanks all, I'll look a bit more at the manual <htsr>leoprikler: where's that guix deploy example? on the blog? <leoprikler>oh, I just found a nice little implementation detail <leoprikler>using a custom channel to fix seahorse, `guix package -m` will respect my channel, whereas `guix upgrade` doesn't seem to do that <htsr>i can't find anymore the guix deploy page on the online manual