<rekado>acrow: home container doesn’t answer the question why system container requires root.
<rekado>the code seems to indicate that it should be able to run as another user
<rekado>(it checks for (zero? uid) for parts of the work)
<acrow>rekado: guix depends on the guix-daemon to proxy most of the its rootless magic but it can't do that for root-containers, which system container are. system requires root to change, but home makes due with lesser privs to do things.
<acrow>rekado: I think you are correct but/and home is the place to do that because otherwise you leave out people using guix on foreign distros.
<civodul`>rekado: 'guix system container' needs to be able to use several UIDs
***civodul` is now known as civodul
<acrow>rekado: I think it makes sense. I also don't believe that using home container requires that you do a guix home installation. that's a separate thing.
<civodul>in theory i believe we could work around that with "subuids" (subordinate UIDs)
<vagrantc>acrow: the debian repositories are just web sites like any other ... so i'm not sure what you're actually asking about
<vagrantc>atka: got the honeycomb building several packages in parallel and drawing probably < 15W
<vagrantc>atka: although i don't have a watt meter on it specifically ... but my whole system appears to be drawing under 14-18W including a few other things
<atka>vagrantc: thanks for the update, that is great news
<vagrantc>atka: oops ... that's whole system under 118W ...
<vagrantc>atka: nevermind, it's probably still 20-30W
<vagrantc>atka: i'll try to get a more accurate reading on it sometime
<atka>vagrantc: ah, no problem, do the sfp interfaces eat much power? are they even enabled in your testing?
<vagrantc>atka: not using them ... no idea if they're enabled
<atka>vagrantc: ok, I wonder if they need blobs or not
<atka>vagrantc: any chance you can paste lscpu output sometime?
<whereiseveryone>hi, if anyone finds the time to review and merge these it would be much appreciated:
<civodul>i can't log in on kreuzberg, something about expired password
***califax_ is now known as califax
<rekado_>“guix container exec” executes also in the “user” namespace, so it’s not quite the same thing.
<rekado_>also inconvenient: the generated container script does not accept “--share” or “--expose” options, so it is necessary to build a different script for every container that wants to mount a different location.
<rekado_>so I can’t generate a container once and reuse it with different directories
<civodul>being able to use subuids instead of running as root would be a significant improvement, too
<kabouik>Has anyone tried Guix System on a GPD Pocket 3 ? I don't know much about GPD, initially the brand is mostly focused on gaming so I don't expect much from them regarding Linux support, let alone Libre (I WLAN won't work with Libre on the Pocket 3). However it seems that more and more people are using them with Linux now, especially the device line that's more focused towards IT than gaming (Micro PC, Pocket 1, 2 and 3)
<gerbil|42>Hi, I've just installed Guix from latest (https://ci.guix.gnu.org/927) and after single guix system reconfigure and one restart later I receive "unsupported manifest format" on every attempt to run either guix pull or guix system *whatever* commands, which means I'm pretty much stuck.
<atka>unmatched-paren: As of January 29th, 2020, their implementation/patches are now in kernel 5.5, and the Mesa branches in 20.0 and 19.3. The VK_INTEL_performance_query extension is designed specifically for 8th generation or newer Intel GPUs including Broadwell, Skylake, Kaby Lake and Coffee Lake.
<atka> Intel's Vulkan VK_INTEL_performance_query extension which was first published in the Khronos VulkanDocs repository as part of the 1.1.109 specification.
<acrow>antipode: Thanks. Finding a good origin is pivotal. :)
<Cairn>This thread (https://issues.guix.gnu.org/57052) has flipped into being a suggestion for changing the default value of `handle-lid-switch-external-power` to "suspend". How much consensus would be needed to get this change committed?
***yeet is now known as cedb
<apteryx>Cairn: as i mentioned in the thread, it was discussed a bit in the past; I think we have consensus to change it but it's good to check! lilyp nckx any opinion?
<Cairn>apteryx: Are you one of the people in that thread? I'm still trying to learn names
<podiki[m]>that sounds like a good change to me, fits the default I've always experienced
<podiki[m]>we should aim for "not surprising" and I think having a laptop stay on with the lid closed is "surprising"
<Cairn>I was definitely surprised by it, as well as someone else in the thread
<dominicm>when I try to do a minor version bump on a rust app and slowly realize I have to add/update like 50 packages :(
<shcv[m]>it would also be nice if it was a little clearer how to prevent suspension when using %desktop-services; I made a server once that I wanted to be able to log into graphically, but then it would go to sleep if nobody had logged in (and it wasn't clear how to fix that)
<unmatched-paren>Although it gets worse: "when I try to package a text user interface that sends json messages to a socket and realize it depends on multiple web frameworks that haven't been packaged yet"
<podiki[m]>not sure about specific importers, but generally it should know when guix has a package and not write a new definition...unfortunately for rust usually does need a new version, and sometimes see it not pick up packages that have different names
<unmatched-paren>Also, sometimes the version specs in a Cargo.toml are stricter than semver.
<podiki[m]>I've used guix import -r to import hundreds of lines of code and it "just worked", not always, but saves so much work
<unmatched-paren>So you have serde 1.0.89 or something, and the package you just imported needs 1.0.92
<podiki[m]>usually spend more time on synopsis/description/license checks than actual codeing :-P
<unmatched-paren>You also have to check every single package for stupidity like bundling of libraries in -sys crates
<dominicm>It would be nice if there was some combo refresh/import since a lot of that back-and-forth seems it could be automated, but I don't know how feasible that is because the updaters aren't specific to the build system
***Noisytoot_ is now known as Noisytoot
<trevdev>I have done something stupid(TM) and I can't see where. I can't evaluate this module in the REPL. It seems to have lost the lexical scope and can't find the binding for the funciton "list": https://paste.debian.net/1249825/
<Cairn>Hey nckx! Back on that PATH issue again. Seems like the Getting Started part of the manual isn't very clear about local packages and the PATH. It pretty says "if you're on Guix system, don't worry about it." But it *does* say to add those recommended PATH lines to your .bashrc if Guix mentions them. I think that portion needs to be written more clearly to convey that Guix System will take care of it, even if it means you need to log out first
<nckx>It is (at least on the surface) strange that it's exclusive.
<lostleonardo>Hi, noob here. I am trying to package the latest version of dwl. I have figured out how to use the --with-source flag to build/install with the new source code, but the latest version of the software also requires a new version of an input (wlroots specifically) and the new version of wlroots requires a new version of wayland... I've not followed
<lostleonardo>the chain any further than that as I'm not sure how to go about making an alternative package input available to another package build. Would anybody be able to point me towards an example of how to create multiple package alternatives, which depend one on the other?
<unmatched-paren>I guess SPEC in `git send-email SPEC` means 'everything after this ref'.
<Cairn>nckx: Sweet, thanks. I do know about some of git send-mail, since I use sourcehut. But I'm very new so I'll be sure to review everything
<jab>jpoiret: I use gnus for mailing lists...that's about it. I find it's interface difficult to use...
<jpoiret>public-inbox is pretty useful for the MLs that have such instances
<teddd>jpoiret: I would like to play around with the code of some modules in a channel. Guess I'll just git clone it and add it to my GUILE_LOAD_PATH. But somehow I have the impression it would be nie to have it at least in guix repl. I mean sometimes I just want to have the exact same environment that package definitions would have at runtime. It's a bit clumsy to have to do things manually
<shcv[m]>is "service" the best abstraction / interface to use for `guix home` configuration setup? Because a lot of configuration (e.g. setting up global git configs) are a one-time thing that I wouldn't usually think of as a "service"
<shcv[m]>and if not, what other options are there? Or should we make a new one specifically for profile construction purposes?
<teddd>shcv[m]: Services are not necesserally daemons running in the background. They are not to be confused with shephered services. For the purpose of creating config files with guix home I can recommend using home-files-service-type
<yewscion>unmatched-paren: Would that end up being something like (define pkg-symbol (origin …))? Or is there something I'm missing there? Guix seems to not know what to do with such a definition as an input.
<nckx>TBC, we don't have a nice abstraction (yet) for everything the alist was good (or OK) at. Like: the ‘problem’ with using a gexp here means you can't use package transformations to pass a different source. It will always use that exact variable. Not a huge problem, but it's there.
<nckx>I think ‘deprecated wherever it's not strictly needed, with the intention to expand the abstractions to cover all old alist use cases’ is the more accurate if verbose summary. But that implies more of a roadmap than their really is, so there's some of my own opinion in that :)