<__red__>So, I see instructions for installation on qemu
<__red__>has anyone done installation on vmware by any chance?
<lfam>__red__: The installation image is a plain disk image, suitable for putting on a USB flash drive. So, it should be possible to install it anywhere that can accept this format, or that convert from it.
<lfam>Acou_Bass: That code is for a test, but it provides an example of how to write the OS declaration for an encrypted root filesystem. The shell script is used by the tests to actually do the installation
<rekado_>here the reason is that the build system tries to download things from the Internet, which won’t work at build time
<rekado_>so we add these archives as inputs via origin expressions.
<Helius>I got the point, but I do not how to do that in practice, I will wait for your comments, no rush
<rekado_>that’s okay, I might be able to fix this myself.
<rekado_>I would just amend your commit for r-shiny then.
<jmi2k_>Is there any example of system configuration divided in several files? My config.scm is slowly getting bigger and bigger...
<ng0>I think our hplip package has one more bug. I took the shortcut and extracted the ppd.gz file, and then when it came to adding the printer, neither root nor my account (groups: lp, lpadmin) weren't authenticated enough
<lfam>Others have more experience than me using Guix in a shared environment, and they'll be able to give you better advice. If nobody pipes up here on IRC, I recommend describing you use case on <email@example.com>
<quiliro>i have a few glitches i would like to tune: some characters look weird...for example ↩
<quiliro>also, claws mail will not open show some mails correctly
<quiliro>and i cannot raise or lower sound volume in xfce
<lfam>How does claws mail fail to show the mails correctly?
<quiliro>i suppose it is the ones that appear in html
<erliphant>@lfam - sorry I stepped away. Thanks for the profile switch tip. That's useful.
<quiliro>i refer to the emails which don't show up well in clawsmail
<quiliro>`guix pull` or `guix package -u` is similar to `apt-get update && apt-get upgrade`?
<lfam>quiliro: `guix pull` is similar to `apt-get update`, and `guix package -u .` is similar to `apt-get upgrade`. The biggest difference is that it must be done for each user, since Guix package management is per-user
<lfam>In `guix package -u .`, the '.' is a regex that matches all the packages in your profile
<erliphant>I'd like to provide substitutes - i.e the results of the build but some source code is "sensitive".
<lfam>erliphant: You could just make sure to have substitutes available and remove source code from the store of the substitutes server. But the idea is contrary to the spirit of the project, and also the mechanism by which Guix works. Guix is hybrid of binary and build-from-source package management systems; it offers referential transparency between building from source and downloaded a binary "substitute". That's why we call it a substitute.
<erliphant>I appreciate that it's against the spirit of the system.
<lfam>You could build offline on a private machine and then export the built packages to the public server
<lfam>We bought a new server and are racing to deploy it :)
<lfam>My point is that our Hydra package may or may not be in tip-top shape :)
<erliphant>The substitutes for hydra don't exist I believe :) cuirass sounds interesting. Will it have REST / automated configuration?
<lfam>If mthl isn't around, you'll have to read the guix-devel archives on this subject :) I don't know very much about it
<quiliro>is there a desktop.scm that could be constructed in order to have a similar configurations as Trsiquel or some other config that is ready for the user that does not have any idea about constructing their own config?
<lfam>Also the cuirass repo should offer some information
<lfam>Many people around the world don't have stable internet connections. We should try to serve those people too :)
<atw>slim is the "default" display manager (it's the one in %desktop-services) but in my opinion it has 2 problems. One, it seems unmaintained, which may be a problem going forward with wayland support or security issues. Two, it requires window managers to be installed as part of the operating system declaration, when WMs are really just a program that a users uses, not a service or anything. Are other people concerned about this?
<davexunit>atw: slim was just the easiest thing to get working back in the day.
<davexunit>I use gnome and one day we'll be able to use GDM or the login manager of our choosing
<atw>davexunit: I may be wrong about point 2, but example operating-system's include WMs in the (packages …) section. I believe this is because if you install one as an ordinary user, slim (and possibly other DMs) won't show it to you as an available WM
<marusich>wingo, do you know if elogind is supposed to detect new hardware and set ACLs for it? I've noticed that even after I compiled elogind with support for ACLs, it doesn't seem to set an ACL on a newly added device, even though switching virtual terminals triggers elogind to set the ACL as I expected it would.
<marusich>This happens when I plug my phone into my laptop - I'm already logged, and elogind doesn't seem to notice the newly added device file, even though the "uaccess" tag is set (according to "udevadm info")
<marusich>I've noticed in Ubuntu that this is not a problem: the ACL gets set (apparently) immediately when I plug in my phone. Ubuntu is using logind, I think. I'm not sure why their ACLs get set, but ours don't.