<lfam>I think there is something messed up with the aarch64 support on the build farm
<rekado>nefix: no, unless you use a fancy expression with “guix system build -e”
<rekado>you could use the same file, load it, and then select the variable of interest
<lfam>It would be nice if the Cuirass web interface could serve the log files in a way that browsers could open, rather than requiring a download and manual decompression
<rekado>nefix: if the file “mytest.scm” contains two variable definitions “os” (bound to an operating-system expression) and “foo” (bound to a package expression), then “guix system build -e '(begin (load "mytest.scm") os)'” will build the system and “guix build -e '(begin (load "mytest.scm") foo)'” will build the package.
<rekado>lfam: I think it’s just a matter of sending along the correct mime type header
<nij>I installed guix system using the graphical interface, and chose exwm as my default window manager. What if I wanted to change it to stumpwm? Should I alter `/etc/config.scm` and `guix system reconfigure [that-file]`?
<nefix>hello! Can someone give me a hand wit G-expressions? I have a variable defined and I want to set the content of the variable inside a file I'm creating with a G-expression: (define test '(1 2 3)) (define test2 (scheme-file "test2" #~(<????>))). How can I make that '<???>' is actually `'(1 2 3)`? Thanks!
<apteryx>rekado_: the problem with composing texlive-unions and other texlive inputs is that TEXMF is sets to a single value. I'm testing whether this limitation can be lifted
<nikita`>htgoebel1: but pax is part of what gnu tar and libarchive/bsdtar can operate on? there's a couple of implementations which provide a single binary for it. i don't know anymore what except gtar can work on it, we have our own implementation
<nikita`>i might be confusing it with something else for gnu tar though.
<htgoebel1>nikita: Yes, pax covers quite some archive formats. It is just a wrapper to "a compromise in the chronic controversy over which of tar or cpio is best"
<htgoebel1>nikita: What I'm seeking is the command line tool.
<htgoebel1>Anyhow: I'm working around this - patching the respective file instead of packaging pax.
<htgoebel1>There are several implementations: MirBSD and Heiliroom. Both need special treatment for building.
<nikita`>yes, my point was unless you are on *BSD (and maybe Solaris?) there is no binary for this
<nij>Hmm resolved automatically.. perhaps savannah hanged a bit @@
***matijja``` is now known as matijja
<desmes>Sup' Guixers. How do you inspect your current live environment? E.g. your current services or packages, after doing "guix system reconfigure" and restarting? I normally open a Guile REPL (on an Emacs buffer with Geiser) And eval (use-modules (gnu)) (use-service-modules desktop ...) and then eval, e.g. %desktop-services to find out the default ones (their print representation at least). But I have no means of knowing my current services,
<desmes>for example. Can I inspect my system using a Guile REPL?
<mdevos>desmes: ‘herd status’ as root should give a list of services
<sneek>mdevos, moesasji says: I don't understand what you are trying to do in your patch as the keymap that is needed in an initrd is not the same as the xkb layout you find in xkeyboard-config. It would need to be converted like is done for the console layout in keyboard.scm
<desmes>mdevos: I see, so the use of Guile in the definition doesn't really mean that you can use a Guile REPL during runtime a la Emacs to inspect and interact with the system. We still rely on shell tools for that.
<mdevos>desmes: the herd daemon has a REPL. I haven't used it yet, though
<desmes>mdevos: But does it interact with Guile objects? That's what I meant
<mdevos>sneek: later tell moesasji: sorry, I don't understand what your trying to say. Doesn't the last sentence address the issue in the first sentence? I hope you can make it work, though! But I won't be working on that patch anymore.
<PurpleSym>rekado_: I’m upgrading jupyterlab right now. Since everything is an extension to jupyter-server now it would be nice to merge all etc/jupyter_server_config.d/ directories, so nbclassic (i.e. providing /tree) is autoloaded when installed.
<mdevos>civodul: I don't know how to properly fix the package definition. Apparently it requires macro's from gnulib. I don't see a gnulib package anywhere anywhere in guix, and I know many package bundle a part of gnulib. Doesn't this count as vendoring? (Exception: gnulib is unbundled in lbzip2)
<efraim>I think because it's designed to be used that way. I don't have a good reason though
<ngz>Hello. I want to check if Emacs packages need to be updated, using "guix refresh". How to do it in a single command? I assume I could create a manifest file containing all Emacs packages in Guix, but is there something more automated?
<Gooberpatrol66>What's the easiest way to see the default .config file for linux-libre?
<ArneBab_>Is anyone else interested in improving KDE-support?
<lfam>Gooberpatrol66: I would look it up in the Guix source code
<lfam>Assuming that's what you mean: The default .config for Guix's kernel
<lfam>ArneBab_: I would like to see it happen, but I probably won't be able to work on it, if that's what you're asking. I've found that I tend to prefer KDE programs for "desktop" stuff
<ArneBab_>lfam: I won’t be able to do much, but maybe I’ll be able to package one or the other, so getting a group of people together who all have almost no time might allow us to get it done anyway :-)
<rekado_>civodul: I’d like to have a version of Guix that supports the GUIX_EXTENSIONS_PATH machinery for use with the GWL development environment or the GWL website service on ci.guix.gnu.oqrg
***nij is now known as Guest74108
<lfam>Is it expected that a bunch of R software depends on libressl?
<rekado_>a long time ago I picked libressl when I had the choice between libressl and openssl
<rekado_>I don’t know if that was a good idea then, nor do I know if it’s a good idea now
<mroh>hehe, "Building the following 2493 packages would ensure 6502 dependent packages are rebuilt:" could be the result of `guix refresh -l cmos`
<lfam>Back then, the choices were basically equal. Now openssl has improved significantly, and libressl will fall behind due to licensing incompatibility. We should probably keep libressl for the packages that come from openbsd
<lfam>We should also begin removing openssl-1.0, which is no longer supported upsteram
<apteryx>civodul: any idea how to mock a file in our unit tests? Or do we use a real, temporary file instead? (not best practice but...)
<apteryx>I'm trying to write a test for (guix build utils)'s substitute
<aecepoglu[m]>Question: A package I want to share has support for a number of things and ideally the user should decide which of these things they want (an editor plugin whose support for different programming languages get compiled in. Enabling all the languages would make it massive in size)
<apteryx>aecepoglu[m]: if it cannot be achieved via plugins that can be installed individually, it's a best judgement thing; trying to maximize the available features without exagerating the size
<apteryx>if some of the features are desirable by some but would incur a very large size, multiple packages can be made, inheriting from the base version.
<lfam>Ultimately, the decision will be made by whoever writes the patch
<aecepoglu[m]>I'll enable support for no languages then, and require that the users patch in the list of languages
<lfam>Does that mean the program won't be useful after it is installed?
<aecepoglu[m]>not so much about being able to change it later but rarely two different programmers use the same set of programming languages.
<apteryx>aecepoglu[m]: another typical thing done is to reduce the size of the closure of a package, some tools can be left for the users to install if they can be picked up from the PATH or environment automatically.
<lfam>Is there a way to make Guile show me the full package definition of a package that inherits from another?
<civodul>apteryx: for a substitute* test, i'd create a temporary file
<civodul>lfam: yes, just type the package name at the REPL
<lfam>I'm going to write a patch that "removes" openssl-1.0. Really, we have to keep it in order to bootstrap rust, so I want to disconnect it from from the openssl package and move it to the rust module
<civodul>we could keep it in tls.scm but mark it as hidden, no?
<apteryx>For my earlier example: (with-store store (build-derivations store (list (lower-object $15)))) -> Throw to key `match-error' with args `("match" "no matching pattern" #<procedure 7faa3a63bd80 at guix/gexp.scm:248:2 (state)>)'.