Enabling PAM support or not only..
Hi, Last week was quite challenging and frustraiting, culminated by sleepless nights in the weekend. Among other things at least two serivces was broken, which are cups-service-type and swaylock with screen-locker-service-type. Both issues are not easy troubleshootable due to nature of PAM. cups-service-type: core-updates merging commit 3bacd3c76a added linux-pam to cups package. Resulting in https://issues.guix.gnu.org/issue/63198. While switching cups-service-type's default package from cups to cups-minimal solves authentication issue, it however broke ipptool printer finder tool. When PAM support is compiled in, it does not work without proper PAM entry. While workaround could be as simple as: --8<---cut here---start->8--- +(simple-service + 'cups-pam-service + pam-root-service-type + (list (unix-pam-service "cups" #:allow-empty-passwords? #f))) --8<---cut here---end--->8--- Total solution could be: https://issues.guix.gnu.org/issue/63198#4 swaylock with screen-locker-service-type: commit 146bae3979 added linux-pam to swaylock package. Resulting in https://issues.guix.gnu.org/issue/63357#2. While workaround could be as simple as: --8<---cut here---start->8--- -(service screen-locker-service-type - (screen-locker-configuration - "swaylock" (file-append swaylock "/bin/swaylock") #f) +(simple-service + 'cups-pam-service + pam-root-service-type + (list (unix-pam-service "cups" #:allow-empty-passwords? #f))) --8<---cut here---end--->8--- Detailed explanation with total solution is provided in https://issues.guix.gnu.org/issue/63652. The following coming afterwards to my mind: GUIX at first is package manager, so there are a lot of them, but of two types: - BOUND - ones referenced from (gnu system) (gnu services) - FREE-STANDING - ones not referenced Then for BOUND packages, changing their behavior requires more careful handling and probably such change is always news worthy. And for FREE-STANDING packages, changing their behavior is totaly up to maintainers of packages and their users, not much could be done here. Having said that, we could go further with something like: guix package --list-available-bound[=...] This would be different from things likes "installed" or illustrated on the graph of running system. The point here is to know the packages that are referenced/used by GUIX it self, not only as package manager. When that available, careful handling and news worthines could be automated probably. muradm signature.asc Description: PGP signature
Re: usage of basu as requirement for sd-bus
Maxime Devos writes: [[PGP Signed Part:Undecided]] On 30-08-2022 09:59, muradm wrote: Hello, basu is sd-bus library extracted from systemd. Currently, there are two packages depending on it, which are mako and grimshot. In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56859, I suggest switching xdg-desktop-portal-wlr to basu. In very same issue, Maxime asks to discuss switching _all_ dependents of elogind to basu. [1] Some elogind dependents, like wireplumber, as per code depends on sd-login.h also in module-logind.c. While I have wireplumber-without-elogind locally, I don't propose switching it basu, because someone may want module-logind.c to work. [2] Currently there are 1461 packages depend on elogind. First, all of them should be analyzed if they do use sd-bus only, those can be switched to basu. Then those using more than sd-bus should be analyzed if elogind is missing would their functionality be hurt. If these problems are like [1], then IIUC these problems would manifest as build errors. Checking for build errors is relatively simple by pushing to a separate branch first, evaluating it on ci.guix.gnu.org and checking for new build failures. Not necessarily, simple ifdef or alike will silently drop anticipiated functionality. Software will build without errors but functionality expected by users might be missing. Because of [1] and [2], I find it not feasible/not possible to blindly switch _all_ dependents from elogind to basu. Do I miss anything else here? IIUC, everything using basu also works fine with elogind (*), so the 'status quo' of still using elogind (for old and new) seems harmless to me (except for size -- basu is smaller). I don't find the "everything using basu also works fine with elogind" statement/assumption/guess correct, as per contents of elogind and basu. See above comment for ifdef thingy. As far as I know, the benefit of 'basu' is using less storage (**). If most dependents are switched from elogind to basu, then this benefit can be fulfilled. But if we just do a mix of elogind and basu, then we have both elogind and basu in the store, _increasing_ the storage footprint instead of lowering, which is the opposite of the goal of lowering storage usage. As such, assuming that lowering the storage footprint was your reason for switching to basu, I think we should either try switching _all_ packages to basu or keep using elogind and add elogind instead of basu to new dependents. My intention is not to have something that is not used. Roughly, if elogind is not used, why should I have it on my system. Basically, elogind provides: elogind, loginctl, busctl, libelogind (sd-bus, sd-login ...) ... basu provides: busctl, libbasu If basu is enought for package it should dependen on basu IMHO. So my reason is not directly-storage-only, but dependency which impacts storage in some or another way. Btw, how much storage are we talking about when having some packages depend on elogind and some on basu? Is it user storage or build server/substitute storage concern? Greetings, Maxime (*) This is an unverified guess. If disproved, my reasoning becomes a lot weaker. (**) This is just a guess about what your goal was, maybe you had a different reason in mind. E.g., basu seems to be more active than elogind. [2. OpenPGP public key --- application/pgp-keys; OpenPGP_0x49E3EE22191725EE.asc]... [[End of PGP Signed Part]] Thanks in advance, muradm signature.asc Description: PGP signature
Re: Idea: Function composition to declare operating-system
Hi, I had similar problem popping up periodically. So here are my 10 cents.. Théo Maxime Tyburn writes: Hi guix! [...] --BEGIN USE_CASE For example to add jackd to my system I need to add the "realtime" group, add some users to this group and add a pam-limits-service. If I want to remove this functionality from my system using the declarative approach I have to look down my config file for places where I added these things. Usually I partially solve this problem by putting comments to signal the purpose of each code block in the system declaration. But wouldn’t it be better if I just had a function `add-jackd` that takes an operating-system instance and returns the os with the extra functionalities ? --END USE_CASE To clarify, do you ask that in the end of the day, some where in (gnu services ...) there should be exported `add-jackd` function? If so, I beleive that this will increase cross dependency between things, thus decreasing flexibility. Imagine `add-jackd` maintainer should always keep track on what is being added into guix, that potentially may cause conflict with jackd and/or require adjustments in `add-jackd` function implementation. Also, IMHO, implementation of `add-jackd` would be very much opinionated. So that was the purpose of the experimentation. It didn’t turn out to be too complicated to implement. At least for my use case, I just needed to add two helper functions to extend users and services fields. The rest is handled directly by record inheritance and by accessing the fields of the input operating-system. The final declaration looks like this: ((apply compose (reverse os-functions)) minimal-os) [...] (define* (extend-operating-system-services os services #:key (drop '()) (keep '())) (append (filter (lambda (service) (not (member (service-type-name (service-kind service)) (filter (lambda (s) (not (member s keep))) (append drop %fixed-system-service-types) (operating-system-services os)) services)) I suppose this could be useful to have it in guix toolbox, although I would prefer to have (required '(account activate ...)) or (required %fixed-system-service-types) optional argument, instead of refering to global constant %fixed-system-service-types, which might not satisfy everyone requirements. and also force keeping or dropping of some services if needed. The list of services that gets duplicated seems to be this one: (define %fixed-system-service-types '(account activate boot cleanup etc file-systems firmware fstab guix host-name linux-bare-metal linux-builder pam profile root-file-system session-environment setuid-program shepherd-root system user-processes)) I generated the list by just checking which services get duplicated, so I am not very sure about it. There surely is a better way to get it. Anyway I can now define a function adding desktop functionalities: (define (x-os os) (operating-system (inherit os) (services (extend-operating-system-services os (list ;; slim display manager (service slim-service-type (slim-configuration (display ":0") (vt "vt7") (theme %default-slim-theme) (theme-name %default-slim-theme-name) (xorg-configuration (xorg-configuration (keyboard-layout (operating-system-keyboard-layout os))) #:drop '(gdm))) (packages (cons* ;; window managers i3-wm python-py3status emacs-nc-exwm-xdg (operating-system-packages os) Of course there is room for some macros to make this more elegant, but this is the rough idea. In a way it feels like treating the operating-system like a service you can extend. Maybe it would even make sense to implement this as a service ? Not sure about that. It seems it would also be reasonable to have something like an operating-system-configuration record and a way to compose some before putting them into an operating-system record (it seems to be the approach rde `features` are based on). But I felt too lazy to copy all the fields from the operating-system record definition. There might be a way to get all the fields programatically and define a record/configuration though. Anyway, what do you think about this functionality? Have you already experimented with similar things? Did I reinvent the wheel? Is there a better approach? Did you try using (modify-services ...)? Basically, you can achieve similar goal within services list only with it. Anyway that was a very fun hacking session :) Happy Hacking! Th
usage of basu as requirement for sd-bus
Hello, basu is sd-bus library extracted from systemd. Currently, there are two packages depending on it, which are mako and grimshot. In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56859, I suggest switching xdg-desktop-portal-wlr to basu. In very same issue, Maxime asks to discuss switching _all_ dependents of elogind to basu. [1] Some elogind dependents, like wireplumber, as per code depends on sd-login.h also in module-logind.c. While I have wireplumber-without-elogind locally, I don't propose switching it basu, because someone may want module-logind.c to work. [2] Currently there are 1461 packages depend on elogind. First, all of them should be analyzed if they do use sd-bus only, those can be switched to basu. Then those using more than sd-bus should be analyzed if elogind is missing would their functionality be hurt. Because of [1] and [2], I find it not feasible/not possible to blindly switch _all_ dependents from elogind to basu. Do I miss anything else here? Thanks in advance, muradm signature.asc Description: PGP signature
Re: image derivation for deploy
Hi, I'm also using Guix on few of my Linodes. In my backlog I have an item which says: - implement Linode API in guile So basically I would prefer seeing such integration via Linode API directly from Guile, instead of using linode-cli. muradm Csepp writes: Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: Hi Csepp, On Sun, Aug 14, 2022 at 3:44 PM Csepp wrote: I'm working on a Guile module that should help with deploying to Linode If someone wants to take a look I can upload it somewhere. Thank you for that work! I use Guix on Linode as well as another provider and would be happy to take a look. Kind regards Felix Lechner This is the current version from my config repo: https://paste.sr.ht/~raingloom/56775fa4dd042739297e3c3c9eb63ad81b127de6 I'll move it to a branch on my Guix repo today. signature.asc Description: PGP signature
Re: Why is greetd greeter user in so many groups?
Hi, Here you are: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56971 I added explanations and proposed solution there as well. Thanks in advance, muradm Ludovic Courtès writes: Hi, muradm skribis: This change broke greetd on my side as I am using it with gtkgreet. Could you open an issue so we keep track of this? While greetd is running as root, specific greeter started by it is not. This many groups was required to: - make it able starting graphical greeters with user greeter - access to seatd's socket file That sounds surprising to me. If other distros don’t do that, there must be something we’re missing? Anyway, let’s see how to move forward. Thanks, Ludo’. signature.asc Description: PGP signature
Re: Why is greetd greeter user in so many groups?
Hello, This change broke greetd on my side as I am using it with gtkgreet. While greetd is running as root, specific greeter started by it is not. This many groups was required to: - make it able starting graphical greeters with user greeter - access to seatd's socket file I admit that, initially it was not clear what is needed, and how. But now it is ok, I suggest to make groups configurable for both greetd (56699) and seatd (56690). This way is most flexible as how user prefers to use them. Could your please have a look at these? Once we done, I would like to submit at least gtkgreet as well. Thanks in advance, muradm Lars-Dominik Braun writes: Hi, Sounds good, thanks for the fix! d921516f50a946e92f9d5dc6d3bd49aca9788ac2 services: greetd: Remove unnecessary user groups. Cheers, Lars signature.asc Description: PGP signature
Re: How to Write Empty File in Build Phase?
May be something like this? (e-mail adhoc typing, may require
fixing)
(define-public python-verspec
(package
(name "python-verspec")
(version "0.1.0")
(source
(origin
(method url-fetch)
(uri (pypi-uri "verspec" version))
(sha256
(base32
"07n06wv85fm4vl1ird2mja0823js3x322wgs9gdnq1djjyk4ql64"))
(modules '((guix build utils)))
(snippet
'(with-directory-excursion "test"
(with-output-to-file "__init__.py"
(newline))
(build-system python-build-system)
(native-inputs
`(("python-coverage" ,python-coverage)
("python-flake8" ,python-flake8)
("python-mypy" ,python-mypy)
("python-pretend" ,python-pretend)
("python-pytest" ,python-pytest)))
(home-page
"https://github.com/jimporter/verspec;)
(synopsis "Flexible version handling")
(description "Flexible version handling")
(license '(license:asl2.0 license:bsd-2
You can use (snippet of (origin, that allows pre phases actions on
source before
any build steps/phases. (with-directory-excursion will basically
"cd" to "test"
directory, (with-output-to-file will open file named
"__init__.py", (newline)
will write empty line to just opened file.
Antwane Mason writes:
Hello,
I am currently working to resolve a build issue of
python-verspec with the ultimate goal of submitting a package
for this
package, onlykey-cli, and all other dependencies required for
onlykey-cli. Onlykey is a hardware password manager, second
factor authenticator, and private key storage manager. A working
solution to the build problem is to include an empty
__init__.py file in the test folder of the source code. How do I
write this file during a build phase?
Here is the package definition for reference.
---
(define-public python-verspec
(package
(name "python-verspec")
(version "0.1.0")
(source
(origin
(method url-fetch)
(uri (pypi-uri "verspec" version))
(sha256
(base32
"07n06wv85fm4vl1ird2mja0823js3x322wgs9gdnq1djjyk4ql64"
(build-system python-build-system)
(native-inputs
`(("python-coverage" ,python-coverage)
("python-flake8" ,python-flake8)
("python-mypy" ,python-mypy)
("python-pretend" ,python-pretend)
("python-pytest" ,python-pytest)))
(home-page
"https://github.com/jimporter/verspec;)
(synopsis "Flexible version handling")
(description "Flexible version handling")
(license '(license:asl2.0 license:bsd-2
---
Regards,
Antwane
