<lfam>vagrantc: Guix System can mount LVM things now, but I don't think they can be created declaratively yet
<mekeor[m]>lfam: one heavy reason for package installation to take so long is that extracting archives takes so long because creating files in a file system takes so long, compared to mounting an image
<lfam>vagrantc: I think that you can. What I mean is that you have to create the logical volumes, the volume groups, register the physical volumes, etc, on your own. Imperatively. But then you can use them in config.scm
<jorts>mekeor[m]: I don't doubt that, but video is too inefficient to consider.
<lfam>You can't create new logical volumes or configure LVM from config.scm yet. *If I understand correctly*
<mekeor[m]>the other link is a quick intro into distri which beats apt and similar package managers by an order of magnitude in package installation time
<lfam>mekeor[m]: One of the main Guix developers watched that talk and has been landing some improvements based on it, actually
<lfam>There is still room for improvment, obviously. Guix is probably the slowest package manager
<mekeor[m]>yes i stumbled upon the talk because its linked in the guix blog
<lfam>Something I'd really like is to speed up or somehow memoize the compute-guix-derivation step of `guix pull`
<lfam>mekeor[m]: Ah, great :) That person is called 'civodul' here, btw. In case you didn't know
<mekeor[m]>jorts: ah right. – but maybe the speed advantage would remain if you'd only have one file to decompress – namely the image – and not dozens of files (which you'd have to create each on the file system)
<jorts>mekeor[m]: Guix deduplicates identical files. It saves quite a bit of space, but is also slow (it's most of the ‘unpacking time’, I'm sure). You can disable it to use significantly more space to save some time installing packages.
<mekeor[m]>jorts: okay, i didn't know about the idea before i saw it implemented in distri
<jorts>But you only create them once, vs. decompressing them every time... who knows? I don't. The only answer is in hard data ☺
<jorts>Feel free to start an issue thread, and hopefully find fellow volunteers to implement a PoC to demonstrate clear wins.
<jorts>I don't find any issues about it either. I'm a bit surprised.
<jorts>Maybe guix-devel@, which might be better for discussion anyway.
<raingloom><grumble>goddammit i'm trying to package rust-parinfer and the specific bindgen version it indirectly depends on isn't one of the ~10 packaged ones so i tried patching the dependency to use a packaged one and now it won't accept it, even though the version string matches. cargo-build-system feels like a sick joke.</grumble>
<pkill9>i think that may be what I was thinking of
<vagrantc>gah. forgot to set up a serial console ...
<phireh>I managed to get the bluetooth working on Guix but it's only working on mono (A2DP sink is unavailable). The solutions posted online involve editing /etc/bluetooth... but it's a read-only filesystem in Guix x.x, has anyone had this problem before?
<pkill9>typically you want to run the bluetooth daemon and ppoint to a editable config, and once you got it working add that config to the service
<pkill9>as in, run it as a user while getting it working
<pkill9>not sure if the bluetooth service lets you give it a raw config
<pkill9>maybe it already has configuration ooptions for it
<pkill9>in which case often you got to translate web solutions to guix config
<phireh>I just did a big fat copypaste of the bluetooth section
<lle-bout>phireh: can you also paste the full error message on reconfigure?
<phireh>guix system: error: bluetooth-configuration: source expression failed to match any pattern
<lle-bout>phireh: probably there you could be missing some use-modules, try to take inspiration from the use-modules at the top of the desktop.scm file and copy some over, there I am thinking you'll need at least (gnu services) and (guix gexp)
<marusich>Trying to build some things on POWER9, and noting what fails. I think the next goal for that port on master should be to get guix-build-coordinator working, so we can more easily gauge the health of the port.
<marusich>But I have no experience with using guix-build-coordinator, so it's an adventure.
<rekado>the first thing is to declare types that this policy depends on
<rekado>things like init_t (for processes started by the init system, for example)
<rekado>these exist on Fedora, but they are not declared on a Guix System.
<rekado>the next section shows how to declare types.
<rekado>next we declare type transitions, to say that processes in domain init_t (processes started by the init system) may transition to guix_daemon_exec_t, so that the rules we specify for that type apply to that process.
<rekado>and then we declare what permissions come with all these types.
<rekado>at the very end we declare what files should get what label.
<rekado>all of the rules for files and processes are defined in terms of labels on files
<rekado>the hard part is designing the policy; implementing it is pretty straight-forward.
<rekado>once the base policy is in place (defining common types) you can define per-application policies.
<rekado>the filecon directive uses regular expressions to label files, and since the application directories all have unique prefixes in Guix, it would make sense to generate the policy in a separate service (using G-expressions to get the absolute directory names).
<balance>Hello! Can anyone help with issue with command "./gradlew build" a error occurs "Execution failed for task ':assets:compileJava'. Cannot find System Java Compiler. Ensure that you have installed a JDK (not just JRE) and configured your JAVA_HOME system variable to point to the according directory"? Have installed openjdk. Have exported JAVA_HOME=/home/user/.guix-profile/bin/
<rekahsoft>roptat: Well, just tested again and you are definitely right. Thank you for clearing up my confusion :)
<leoprikler>balance: openjdk has a jdk output for the jdk :P
<balance>leoprikler: ok, thank you for answer, and what it means?
<roptat>balance, you need to install openjdk:jdk insteadd of openjdk
<roptat>(confusingly openjdk provides "java" to run java programs, while openjdk:jdk provides the jdk, to build java software)
<raghavgururajan>HELP! Ruby dependencies of ruby-asciidoctor are failing in core-updates. Could anyone help us by fixing them?
<g_bor[m]>raghavgururajan: Hello, do you know why they fail?
<raghavgururajan>g_bor[m]: Not sure, bunch of ruby stuff fails. I am unable to look into it more, as I am working on fixing other stuff. :)
<raghavgururajan>Btw, `./pre-inst-env guix build ruby-asciidoctor --dry-run` should give all its ruby dependencies that are not building.
<balance>roptat: your advice helped, but another issue occurs. Trying to build bisq on guix. "Failure: Build failed with an exception. * What went wrong: Execution failed for task ':proto:generateProto'. > java.io.IOException: Cannot run program "/home/user/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protoc/3.10.0/e7ba2967f692c3bd2bd417f6a305bcb6a8c6a357/protoc-3.10.0-linux-x86_64.exe" : error=2, No such file or directory
<apteryx>Hello Guix! I'm trying to 'guix deploy' a machine, and it failes because of a channel downgrade error; are channels used when guix deploying? Is there a workaround?
<roptat>balance, yeah, kinda expected: gradle downloads arbitrary binaries that expect to be run on a system that has all its dependencies, but they can't find them on Guix System
<roptat>I don't really have a good solution, probably you can fix this by running in an FHS container (a guix container where you mount at least /lib to contain the libraries, so these binaries can run)
<roptat>the "no such file or directory" is confusing: I'm sure the file exists, but it wants to be run by /lib/ld-linux.so or similar, that doesn't exist on Guix System
<balance>roptat: yes file exists, but even when i try to start it manually console shows "no such file or directory"
<apteryx>ah, the machine-ssh-configure has this: machine-ssh-configuration-allow-downgrades?
<leoprikler>balance: "file does not exist" can also mean, that it links against some library, that it can't find
<roptat>I had recipes for a big chunk of gradle in 2017
<roptat>but it stalled because of scala and kotlin
<nefix>Good afternoon! I've almost finished packaging `email@example.com`! There's only a missing piece: there are 3 build options that are `sysconfigdir`, `localstatedir` and `runstatedir`, which are mappped to `/etc` `/var` and `/run` by default. The thing is that they make the install phase (using `meson-build-system`) fail since they try to write to those directories during install. `firstname.lastname@example.org` solves this
<nefix>by sending flags to the `make install` but now `email@example.com` uses`meson` & `ninja`. Can I pass flags to the `ninja install` command? I've tried replacing the `'install` phase, but it doesn't seem to pick up the `-D` flag prefix. Any ideas? Thanks! :D
<lfam>Did you create that file? Or was it created for you? Did you look to see if it's a regular file, or a symlink to something else?
<Vongazi>i installed guix manually as described in the info page, So i copied this file from /etc/configurations/lightweight-desktop.scm in the live cd to /mnt/etc/config.scm and edited it, And no it is not a symlink
<Vongazi>i can edit it if change the permissions, I'm asking because some programs do this intentionally like sudo, /etc/sudoers is not writable by any user and if you want to edit it, the proper way is to run visudo, i thought maybe config.scm is doing something like this.
<apteryx>would someone know if h.264 hardware acceleration is possible with the Intel 4500MHD GPU that the X200 boasts?
<cbaines>Vongazi, I don't believe /etc/config.scm has any special significance, so I'd just change the permissions to suit you
<raingloom>Noisytoot: that's a can of worms i'm not opening right now :D
<raingloom>let's just say i tried to love Emacs but it didn't love me back. Kakoune is my new sweetheart for now.
<Noisytoot>raingloom, You can use evil-mode if you prefer vi keybindings
<raingloom>of course Kakoune also sucks in its own ways, but they are much more manageable ways, at least for me personally.
<Frosku>Sorry, last question. The contributing guideline says that it needs to be 'in the guix source tree' before running ./pre-inst-env -- do I just run the command in the same dir as the file or does it need to be somewhere special?
<raingloom>Frosku: you should cd to the guix repo that you pulled.