<bovid-19>jpoiret: thank you! I thought it would be in (al utils) or one of the other custom modules, too, but grepping through the repository didn't find it.
<jlicht>lumberjack123: No, not now nor in the near future; cleanly building Electron itself is already challening (but possible); the web of JS dependencies around that makes it kind of a non-starter to meet the bar for inclusion in Guix
<lumberjack123>jlicht: Yes I just used yarn for my first time and it downloaded over 800MiB of modules!! I am flabbergasted...
<lumberjack123>But I do not see why JS code is a big deal, as long as V8 binary in Node.js is safely/reproducably compiled with g++
<lumberjack123>OKay what is so special about Nix that it can compile/package Electron app but Guix cannot?
<singpolyma>lumberjack123: less focus on builds from super pure sources, likely
<pinoaffe>lumberjack123: probably that they're less strict about licensing and building everything from source
<pinoaffe>you can do the same using guix, but those kinds of packages probably won't be accepted as "official" guix packages, whereas they might be accepted in the case of nix
<lumberjack123>As for license the app in question is GNU GPLv3 and Node.js is MIT license and V8 is 3-clause BSD, also SQLite is public domain... I do not know what the license all of the modules yarn downloaded were, is this the issue?
<bovid-19>Nix includes packages that just download official binaries. For guix, you'd have to have source packages for each item in the dependency tree.
<lumberjack123>bovid-19: Ohhh hmm so in nix they do not compile V8 from source or something for Electron apps or what else do they not compile?
<lumberjack123>I don't see why the dependencies for Electron apps cannot be built from source on Guix as long as license of modules is libre
<singpolyma>lumberjack123: they can be. It's just a lot of work and no one has
<singpolyma>The chromium source tree is a bit insane, but obviously there is a way to build it right, just not a one day kind of task
<jlicht>I think it's mostly the npm packages here that are problematic; it's no fun trying to build it all from sources, so Nix throws their hands up and just downloads the 'binaries' from the npm registry
<sneek>civodul, nckx says: No objections from me! Happy hurding.
<sneek>civodul, apteryx says: OK for me too; as long as you don't need to reconfigure berlin itself, it should be fine
<civodul>apteryx, nckx: i deployed the build nodes, but unfortunately their childhurd service still fails to start
<civodul>either it's a timing issue or the new "childhurd" service wasn't reloaded
<chaos1>Hi I'm trying to debug something with the openjfx package defined in guix/gnu/packages/java.scm, but I am not sure what are the right steps to do so.
<chaos1>The source code lives in mercurial under teh 8u202-ga tag, and is used to build the java-openjfx-build, java-openjfx-base, java-openjfx-graphics and java-openjfx-media packages
<chaos1>I would like to change a single line in the source code and rebuild the packages; so what I have done is to clone the openjfx project from the mercurial server to my localhost, and export the source code into a local directory, so that the source code is available on my pc
<chaos1>I then modified the source line i was interested in the local source code copy
<chaos1>Then, i switched into a guix environment with `guix environment guix --pure`, and rebuild the package with `./pre-inst-env guix build java-openjfx-graphics --email@example.com=<path-to-the-modified-source-code>`
<chaos1>this has created the new version of the package as expected
<chaos1>though (as perhaps is expected) this package is not available from my normal guix profile, i.e. `guix search java-openjfx-graphics` will not list it
<chaos1>How do I make a local dev build accessible to my normal guix environment?
<raghavgururajan>chaos1: If you have a self-built binary, you can add the path of that binary to $PATH environment vairable; and start the program from terminal. It cannot be managed with guix as it isn't part of guix distribution.
<raghavgururajan>chaos1: Oh wait! You modified a package in the distribution and built it. Okay. Instead of `guix search`, do `./pre-inst-env guix search`.
<chaos1>I see thanks, both suggestions make sense, let me try them out
<raghavgururajan>You could also do, `./pre-inst-env guix environment --pure --ad-hoc package-name -- program-name`
<chaos1>thanks, my use case is so simple that the first suggestion did the trick (explicitly specifying the path tot he new package)
<chaos1>I have another question, this is independent of the above, no code was modified or new packages are created here
<chaos1>When I install the above libraries with a normal `guix install java-openjfx-graphics` say, the jar is installed as expected at ~/.guix-profile/share/java/java-openfx-graphics.jar as a symlink pointing to the corresponding /gnu/store path, but it is not available in the class path
<chaos1>e.g. I was expecting that the library can be found with javac say when I import it in the source file
<chaos1>but this is not the case, I have to explicitly mention the above path in the classpath
<chaos1>Is this expected behaviour? I would have expected that any java library I install with guix should be made available in the classpath
<dansa>Hi. I'm looking forward to buy a new computer for installing the GNU Guix. Is there a website somewhere that I can sort of just buy a computer that is fully supported by GNU Guix? (Or must I somehow build it myself or build a particular configuration for a company that builds and sells computers to sell me one?)
<dansa>In other words, I'm trying to play the role of the total-beginner who doesn't want to discover that a certain piece of hardware isn't supported. I'm looking for off-the-shelf, plug-n-play stuff.
<dansa>I'm already aware of catalogs of supported hardware, but this still leaves me with the job of either buying all parts and assembling it or building a shopping a card in some vendor. I'd love a one-click-buy to solve this problem. And it does like we all would have the interest in perhaps building a website that sort of keeps such information up to date.
<pinoaffe>dansa: are you in the market for a laptop or a desktop?
<unmatched-paren>my 'typical consumer laptop' still has evil bios, but it otherwise is completely free
<pinoaffe>On a consumer laptop, afaik the only things that typically may cause issues are the wireless connectivity cards (anything from wifi, nfc, bluetooth, etc) and the graphics card
<pinoaffe>I personally use a lenovo t470, the wifi card it comes with OOTB is not supported in guix but I was able to buy a compatible wifi card with fully open source drivers that is supported in guix
<ternary>I need some help packaging squeekboard. It builds with meson, but meson calls cargo to build the rust portion of it. My original plan was to use the meson build system and insert the cargo configure phase, but now I've realized that the cargo dependencies are provided through the cargo-inputs argument, which meson obviously doesn't use, and now I don't know what to do
<f1refly>otherwise i'd just say it's probably a random hardware failure or something
<f1refly>the first time there was suddenly whitenoise playing for a split second, indicating that either the hardware is going bonkers or something overrode pulseaudios buffer
<f1refly>(from my understanding of how this could've happened)
<tooblu>trying to install a subset of glibc-locales, the new instructions provide an example bit of code for Canadian utf8 locales. I think I can adapt that for my purposes. What do I do with that bit of code after I've edited it? I tried putting it in a file, glibc-my-utf8-locales.scm, and running "guix package
<tooblu>--install-from-file=glibc-my-utf8-locales.scm", but that failed with: "guix package: error: cannot install non-package object: #<unspecified>"
<kaelyn>@tooblu the error is because that example defines a variable containing the package, and "--install-from-file" expects the file to return a package object. The simple fix is to add "my-glibc-locales" (without quotes) on a new line at the bottom of glibc-my-utf8-locales.scm
<kaelyn>(to explain better: the return value of the last top-level expression to be evaluated in the file is used as the package. "(define some-var ...)" does not return anything, while just "some-var" returns the value of "some-var")
<tooblu>Kaelyn, thank you! That seems to have worked. I appreciate the reasons for removing glibc-utf8-locales, but the new instructions for not having to install the entire glibc-locales, which seem to be targeted at people like me, not-a-package-developer-just-want-to-install-guix-and-some-packages, seem to assume the new-to-guix person installing Guix
<jlicht>finally found out why Guix System was so terribly slow on my new laptop; turns out there is a bug in my proprietary bios. Who'd thunk it? Either way, running thermald with --adaptive seems to get my CPU to clock a bit faster than 400MHz, which it was normally stuck at
<nckx>jlicht: I got a similar bug free with (and only with) Coreboot, so it's not all libre unicorns & rainbows. Alas.
<nckx>Machine clocks down to 1.2 GHz after a random uptime, and nothing but a reboot will fix it.
<jlicht>I'm just happy the solution is not 'buy new laptop' :)
<atka>when installing guix to luks + btrfs are there any btrfs subvolumes that need to be present to boot? on other distros I usually just have a root "/" and home "/home" subvolume and don't mount the toplevel except for maintenance. is it required or recommended to have a "gnu" subvolume as well?
<nckx>I'll try the same command (though I'm not hopeful — Linux report's the CPU's unrestricted, it just refuses to live).
<jlicht>`thermald --no-daemon --adaptive' as root did the trick for me
<jlicht>unmatched-paren; not having used kakoune (nor having a working pc), why would you not want there to be one directory to autoload *.kak files from? AFAIK, this is what will happen in a profile or environment
<unmatched-paren>jlicht: if you support multiple directories, you'd be able to install kak plugins on both the system and user profiles, right?
<unmatched-paren>it's unlikely that someone would want that, but it'd still be a bug if it doesn't support that
<unmatched-paren>i know it's probably silly to ask this in a channel dominated by emacs users, but is there a good terminal (non-emacs) email client in guix? i tried packaging aerc but failed because golang
<Ribby>Just an opinion, I think that guix should have mfs.vfat, mkfs.exfat, fsck, parted, mklabel msdos, mklabel gpt, and mkpart. It might not be a customer retention strategy, but the ability to make OS copies/backups can be a selling point bonus. I am not sure if there's a 64 bit requirement, but it shouldn't be the case.
<unmatched-paren>does qubes run a distro for each application, then? i've never really looked into it
<Aurora_v_kosmose>Fedora includes more of them by default. So you might have to switch the sys-net to a fedora template just in order to download the drivers package to install in a Debian template you'd then use for the sys-net qube.
<Aurora_v_kosmose>unmatched-paren: Not necessarily. You can use it that way but typically due to resource constraints you separate qubes by security domain.
<Aurora_v_kosmose>So you'd have say... Emacs and Firefox in your work qube, and Emacs from another qube also running.