IRC channel logs


back to list of logs

<nefix>good night! can I build a (operating-system) derivation with `guix build`?
<rekado>nefix: close! “guix system build”
<nefix>rekado: hmmmm, so I can't have a file with both a (operating-system) and a (package) defined and build both?
<nefix>(even if the package is not used by the (operating-system) derivation
<lfam>I retried a build on Cuirass and it failed in 1 second:
<lfam>The logfile reads "while setting up the build environment: executing `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such file or directory"
<cbaines>the guix-daemon can cache failures, and I believe that may be how it's configured on berlin
<lfam>I think it's s real failure in this case, right? Or has it cached the result of not being able to find guile?
<cbaines>so maybe the guix-daemon has the failure cached, so Cuirass "built" it, but the daemon was able to just give back the cached failure
<lfam>There are no results for `guix gc --list-failures | grep qtbase`
<lfam>There are currently 18216 cached failures
<cbaines>probably not what I said then
<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
<rekado>not sure where it’s missing though: do we need a rule in nginx or is Cuirass not doing the right thing
<cbaines>Cuirass does set content types for JSON/HTML
<cbaines>It looks like Cuirass might instruct NGinx to serve the log from guix publish though, so maybe it's guix publish that needs to set the header (or NGinx)
<jonsger>hey lfam, what is the way to get a change in the linux.conf? would be nice to uncomment CONFIG_RTW88=m :)
<nefix>rekado: oh, okay. Thank you!
<lfam>I'll take a look jonsger, thanks!
<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]`?
<nij>I have added the first block of code as shown in the doc: , reconfigured, and rebooted. But after logging in via GUIX's login interface, exwm is auto-launched, and I cannot start stumpwm from there.
<drakonis>is there a list of available services?
<drakonis>i can't tell if there's any being added now
<drakonis>its entirely confusing that the kde packages get updated on a daily basis, but there's no documentation on how to use it
<dftxbs3e>is there a freedom problem on gutenprint? (cups module for epson, canon, etc..)
<dftxbs3e>it's in Debian but not Parabola or GNU Guix
<dftxbs3e>but it's in Trisquel:
***daviid is now known as Guest14816
***Guest14816 is now known as daviid
<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
<apteryx>nope, it didn't help.
<raghavgururajan>If I add `#:use-module (gnu packages lxqt)` to gnu/packages/telephony.scm, any of the packages in that module fails to start building.
<apteryx>probably a module circular dependency?
<apteryx>does attempting to compile slowly eats at your RAM until your terminate it?
<apteryx>raghavgururajan: ^
<raghavgururajan>apteryx: Seems like it.
<abcdw>Morning guix!
<mothacehe>hey guix!
<sneek>Welcome back mothacehe, you have 1 message!
<sneek>mothacehe, mbakke says: any idea why staging evaluations hang?
<abcdw>mothacehe: o/
<htgoebel1>Good morning guix!
<htgoebel1>I can not find pax - POSIX File System Archiver
<htgoebel1>Is this part of another package or simply not packaged yet?
<htgoebel1>Hui, according to <>:"pax is required to be present in all conformant systems by Linux Standard Base since version 3.0 (released on July 6, 2005),"
<htgoebel1>So I' assume I just missed it in guix?!
<efraim>plus we also don't conform to LSB
<efraim>doesn't it just have a dependency on every compression/decompression program out there? or was that something else
<efraim>I'd check libarchive first
***sneek_ is now known as sneek
<htgoebel1>efraim: Sure we don't confirm to LSB, anyhow the program seems to be POSIX standard
<htgoebel1>It seems to not depend an other libraries
<htgoebel1>I'll give packaging a try
<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
<nikita`>you can use gnu tar etc
<htgoebel1>Since for my current needs "xargs tar" suffices, I'm not going to package pax (yet).
<htgoebel1>nikita: I have a package which uses pax to create some test data - this is why I was seeking for it.
<htgoebel1>The package maintainer seems to work on OSX = BSD, thus using pax
<rekado_>apteryx: what’s the use case for more than one texlive-union in a package?
<nij>Good morning!
<nij>I ran `guix pull` just now and got a Git error.. what's going on?
<nij>Updating channel 'guix' from Git repository at ''... \n guix pull: error: Git error: unexpected http status code: 502
<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>Welcome back mdevos, you have 1 message!
<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.
*mdevos afk
<PurpleSym>Can a Guix package somehow define a profile hook?
*mdevos back to keyboard (forgot something)
<rekado_>PurpleSym: no.
<mdevos>desmes: I can't find the REPL, but perhaps try sudo herd eval root '(display "test")'
*mdevos afk
<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.
<desmes>mdevos: Ok, thanks!
<PurpleSym>Actually, maybe I can just set JUPYTER_CONFIG_DIR…
<rekado_>PurpleSym: perhaps you can use a native-search-path on the main package?
<PurpleSym>Yeah, that seems to work.
<mdevos>‘guix build emacsy-minimal’ seems to fail due to a missing ‘autoconf’ input. Can someone verify?
<mdevos> agrees, I'll write a patch later
<civodul>mdevos: ah, i removed the autoconf input from "emacsy" because it wasn't needed there, but i must have overlooked emacsy-minimal
<civodul>speaking of Emacs, has anyone used OBS with EXWM?
<Noisytoot>Why are some builds completed on 1 Jan 1970?
<civodul>among the available windows, it doesn't list Emacs itself
<civodul>my understanding is that the window list has to do with the xcomposite interface
<civodul>Noisytoot: i suspect it's a bug and they should instead be marked as not-started, but you'd need to provide specific examples
<Noisytoot>civodul: For example:
<civodul>hmm perhaps it was built behind Cuirass' back
<Noisytoot>Installing confusion-mdl (using Guix) fails
<Noisytoot>The log:
<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>we normally leave gnulib bundled
<mdevos>efraim: any particular reason?
<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?
<efraim>'guix refresh --list-updaters' lists elpa
<efraim>I suppose you could do something like 'guix package -A ^emacs- | cut -f1 | xargs guix refresh'
<civodul>ngz: "guix refresh -t elpa"?
<civodul>oh it crashes on emacs-exwm-no-x-toolkit
<civodul>left as an excercise to the user :-)
<efraim>I normally end up with a list for sed to skip
<efraim>'guix package -A ^emacs- | cut -f1 | sed -e '/emacs-exwm-no-x-toolkit/d' -e '/emacs-some-other-package/d' | xargs guix refresh'
<ngz>civodul: IIUC this assumes all emacs packages use elpa updater, which is not true.
<ngz>efraim: OK, thanks, my sh-fu is weak.
<nefix>everything is slowly starting to click inside my head, from Scheme to Guix itself, I'm really happy :DDD
<nefix>soon I'll feel confident enough to maybe contribute!
<apteryx>rekado_: I think I've found a way to generally compose multiple texlive trees
<apteryx>(including those generated by texlive-union)
<apteryx>nefix: yay :-)
<civodul>apteryx: oh! that'd be great
<civodul>mdevos: re gnulib, it's a "source library" so it's a bit different from "normal" libraries, and it's next to impossible to just remove it because it meshes with the build system
<rekado_>the “guix” package now has a native-search-path specification for GUIX_EXTENSIONS_PATH, but the profile that “guix pull” generates does not set GUIX_EXTENSIONS_PATH. Is this expected?
<rekado_>civodul: is it okay if I updated the “guix” package with “make update-guix-package”?
<civodul>rekado_: the profile that 'guix pull' generates does not use packages, so no search paths in there
<civodul>rekado_: sure, but may i ask why? :-) (the native-search-paths change probably doesn't require it)
<lfam>It seems like #45654 (Building guile on x86_64 for aarch64 fails because of a missing guile) is affecting the CI
<lfam>We seem to have the same errors there:
<nij>I have $desktop-services enabled, but would like to get rid of the (and only the) graphical login manager. What should I do?
<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 :-)
<lfam>Heh :
<ArneBab_>many of the libraries are already there
<ArneBab_>and I also prefer KDE for desktop
<lfam>We have so many parts, but bringing them together into like a kde-desktop-service will probably be a large amount of work
<mroh>Gooberpatrol66: try `cat /var/guix/profiles/system/kernel/.config`
<lfam>At least, GNOME was like that
<ArneBab_>lfam: do you have an idea about the next steps that would be needed to get there?
<lfam>Not really ArneBab_, I don't know anything about how KDE is supposed to work as a full system
<ArneBab_>as a full system there’s kinit4(5?) that launches programs, then kwin as window manager. And plasma desktop for the equivalent of gnome shell.
<lfam>I'd guess there is a really simplified guide to "starting KDE" somewhere, that makes a lot of assumptions about filesystem layout and how services work, and then we would adapt it to Guix
<lfam>Did you ever see the presentation about GNOME on Guix? It showed a graph of the services and told the story of how it was achieved
<lfam>It could be a useful diversion from "real work" :)
<ArneBab_>I didn’t see it yet, no
<ArneBab_>do you have a link?
<lfam>I'll look
<lfam>I always find it difficult to find old talks
<lfam>It's the one with a plate of spaghetti in the slides ;)
<ArneBab_>yes — it’s become a sad situation with finding stuff again online
<ArneBab_>but that was fast :-)
<lfam>The google search into our PDF made it possible
<lfam>I searched for "gnome guix fosdem"
<ArneBab_>that’s somehow not how this should work …
<lfam>And then looked for spaghetti
<lfam>And yet...
<lfam>You might talk to Hartmut about it. They have done most of the work adding KDE components to Guix
<ArneBab_>lfam: what’s the nick for Hartmut?
<lfam>I believe it's htgoebel, but you might have more luck over email
<drakonis>lfam: the nixos module might help there
<drakonis>it has a cocktail of changes to enable it to function with nix's environment
<Gooberpatrol66>mroh: thanks
<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]>yes sir :)
<lfam>It's not a problem if a package is large
<lfam>We shouldn't add packages that don't work at all "out of the box"
<aecepoglu[m]>but we are talking stupid large. The compilation will take forever too
<lfam>How large? 100 GB? 1 GB?
<lfam>You could choose to add support for the most common use cases
<lfam>It's a matter of judgement
<aecepoglu[m]>It doesn't belong in guix then
<aecepoglu[m]>I'll share the scheme file with the developer for in case they want to put it in their repo
<lfam>Why not? I encourage you to add the package so that people can use it
<aecepoglu[m]>But do I add support for JavaScript by default and not Haskell? I can't make that choice
<lfam>Sure you can :) It's not set in stone. If someone requests a change, we can change it
<lfam>I assure you, we all make choices like this, and change our minds later :)
*lfam reboots to install new kernel
<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>Thanks civodul
<civodul>whether or not it inherits from another one, it's just a normal package
<lfam>Not sure I understand, but it shows me this, for example, "$1 = #<package openssl@1.0.2u gnu/packages/tls.scm:461 7ff7b86125a0>"
<civodul>ah yes, but then you can call procedures to access specific fields
<civodul>like (package-inputs $1)
<civodul>that will print the inputs of the value recorded as $1
<civodul>or: (package-inputs openssl) in this case
<lfam>I see
<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?
<lfam>Yes, we could
<lfam>I think we should make it as obscure as possible, though. Otherwise people will want to use it
<lfam>There are some packages that will probably never support later versions
<civodul>i'd say make it hidden, possibly add a prominent comment, and just make sure nothing but the old Rust depends on it internally
<apteryx>how come substitute* on a ISO-8859-1 encoded file throws an exception in the build environment, but not in my user profile? It is because of the locales present?
<apteryx>civodul: OK! Thanks.
<civodul>you should set the %default-port-encoding fluid
<civodul>there are examples around
<civodul>(the default is UTF-8)
<apteryx>but my system is UTF-8 as well, no (en_US.utf8) ? And it doesn't throw the exception. I'm trying to reproduce outside of the build env.
<apteryx>it does something wrong as well though, which is saves the resulting file as UTF-8, which introduces garbage, but it doesn't throw.
<civodul>ah yes, because there's also %default-port-conversion-strategy
<civodul>(also a fluid)
<civodul>you want to set it to 'error
<apteryx>ah, indeed! (fluid-set! %default-port-conversion-strategy 'error)
<apteryx>thanks for checking :-)
<apteryx>That's good, I prefer the failure mode than silent corruption.
<mdevos>There's a post on ‘Bootstrappable builds’ on idk if Guix is mentioned (I don't have a subscriptions), but if you do, you may want to take a look
<civodul>oh indeed
<civodul>janneke: ↑
<civodul>dunno if you were planning to wait a bit before announcing it loudly :-)
<apteryx>How do I manually "compile" an origin record?
<cbaines>guix build -S I think
<apteryx>currently I have:
<apteryx>cbaines: I meant using the Guix API.
<cbaines>origin->derivation then?
<civodul>yes or lower-object
<janneke>civodul: amazing, and a very thoughtfully/thourough articl; wow
<civodul>janneke: yep, i hope it can help raise awareness
<janneke>civodul: what we need most, is raising awareness
<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)>)'.
<apteryx>where $15 is my origin record object
<apteryx>if I swap lower-object to origin->derivation, I then get: Invalid keyword: #vu8(45 40 199 248 52 204 169 [..])
<civodul>apteryx: lower-object and origin->derivation are monadic procedures
<civodul>so you need to "run out of the monad" :-)
<janneke>had i planned it, i would have added *finish fosdem talk* to that mail
<civodul>heh :-)
<civodul>for sure you have something to announce in your talk
<civodul>just one slide: "We did it."
<janneke>yup, i have a slide with that title
<apteryx>civodul: oh, thanks.
<apteryx>And how do I run out of the monad? (with-store store (run-with-store store (origin->derivation $15))) or ,run-in-store (origin->derivation $15) both return an invalid keyword error
<apteryx>there's an mlet based example in search-bootstrap-binary (guix tests) I think.
<apteryx>this naive adaption of it still gives me that #vu8 invalid keyword error:
<civodul>,run-in-store (origin->derivation (package-source (@@ (gnu packages base) coreutils)))
<civodul>works for me!
<civodul>'test2' looks good to me at first sight
<rekado_>I have a TODO comment in the GWL code that says I should use (computed-file "the-thing" build-exp) instead of (run-with-store %store (gexp->derivation "the-thing" build-exp)
<rekado_>the code there is seriously messy
<rekado_>that definition is too long, too nested, too complicated
<civodul>in general one shouldn't need to use the monadic procedures nowadays
<civodul>exceptions are: in a gexp compiler, or in obscure low-level stuff
*janneke -> zZzz
<civodul>same here, night!
<nij>Hello! I'm trying to make xmonad work in Guix System.
<nij>In my config (xmonad.hs), I `import XMonad`.
<nij>And I ran `xmonad --recompile`.
<nij>But it complains that such module isn't presented.
<nij>I have `guix install xmonad` though! It must have gone into guix directories, so `ghc` cannot see it.
<nij>(I got ghc by `guix install ghc` as well. What should I do?)