IRC channel logs

2022-02-10.log

back to list of logs

<Kolev>This 'guix home reconfigure' is taking FOREVER.
<Kolev>All just to install Kodi.
<rekado>what does it do?
<rekado>is it compiling anything?
<Kolev>rekado: I'm not sure. It might be building Telegram Desktop, yes.
<Kolev>rekado: Does "building ... drv" mean actual building, as in compiling source?
<ulfvonbelow>What's the Proper Way to simply ensure a directory exists on the root file system in my system configuration? I happen to need a directory that's guaranteed to be empty for something (so something like /empty).
<ulfvonbelow>should I extend the activation service?
<rekado>Kolev: depends on the derivation
<rekado>a “drv” file contains what’s called a “derivation”
<rekado>it’s a low level representation of “work” to be performed by the guix-daemon
<rekado>this can something very simple (like creating a profile union directory) or something very complex (like compiling a package).
<rekado>so “All” is not necessary “just to install Kodi” but to do a whole lot of other work
<rekado>in cases like this the question to ask is: “why does it need to do that?” and not “why is Guix not faster?”
<Kolev>rekado: I know it's doing all this work, but it makes me wonder if all the work is worth it.
<Kolev>rekado: Sorry about the frustration.
<sneek>Welcome back rekado_!!
<vagrantc>sneek, you're so welcoming.
<rekado_>sneek: botsnack!
<sneek>:)
<rekado_>Kolev: I totally understand the frustration. Perhaps it would be less frustrating if Guix had a way to tell us why it’s doing something unexpected.
<Ribby>Anyone know about (free) firmware. It appears that I need this after installing the driver.
<atomizedalex>I installed proprietary iwlwifi drivers for my wifi card
<atomizedalex>But I'm not a wiz with this. I followed the instructions from Daviwil systemcrafters page to install Guix with the Linux kernel rather than the libre kernel, so that it would work with iwlwifi
<AwesomeAdam54321>Ribby: What hardware do you use?
<Kolev>Sigh. Telegram Desktop keeps failing to build.
<apteryx>atomizedalex: hello! this channel is reserved to discuss free software; if you are having issues with proprietary software (which is not part of Guix), please seek guidance/assistance in that software space.
<atomizedalex>No I'm not having issues. I was responding to Ribby, pointing him to a resource that I used.
<atomizedalex>Is that not allowed?
<atomizedalex>Apteryx: are you a mod?
<vagrantc>shouldn't metter who's a moderator, those are the community expectations in this channel
<atomizedalex>Very good and I take that seriously, so I want to know if I've overstepped the limits, as well as who is interpreting that.
<vagrantc>it is admittedly a bit awkward at times
<atomizedalex>I'm not a developer. I am a PhD in Political Philosophy.
<vagrantc>i'm not sure who the moderators are, but it's common for anyone to step up for gentle reminders, which is what i'd guess this was :)
<vagrantc>ribby was also asking about free firmware, which kind of need to know for what device in order to help
<vagrantc>well, i guess free was parenthetical :)
<vagrantc>free/libre firmware totally on topic, at least inasmuch as using it on guix
<atomizedalex>There are universal rules, and then rules are applied to concrete instances. This involves interpretation, which varies according to the interpreter. I was asking if what I said did infringe on the limits, and according to whose interpretation. Where is the rule posted?
<atomizedalex>The systemcrafters guy has contributed to Guix. Mentioning him seemed natural.
***califax- is now known as califax
<vagrantc>hmmm... tring to find some documentation
<vagrantc>hrm. drawing blanks on the specific guidelines for communications on #guix channels ... guix does follow the GNU FSDG https://www.gnu.org/distros/free-system-distribution-guidelines.html ... but even that doesn't bring up some of the things that specifically mention not referencing non-free works
<vagrantc>though i've definitely read some of that at some point
<vagrantc>the FSDG is referenced from https://guix.gnu.org
<vagrantc>might be covered here: https://guix.gnu.org/en/videos/2020/asking-for-help/
<vagrantc>though a video is a poor reference
<AwesomeAdam54321>vagrantc: I remember that /topic of this channel stated that proprietary software was off-topic
<atomizedalex>I had tracked down that document as you were looking. I think that you were right in interpreting what I said as outside of the limits based on the "License Rules" section, "Information for practical use."
<atomizedalex>It would be helpful to have this stated more clearly upfront.
<vagrantc>agreed
<vagrantc>also, it took me a while to find the code of conduct, which doesn't actually address the free software norms: https://git.savannah.gnu.org/cgit/guix.git/tree/CODE-OF-CONDUCT
<vagrantc>probably worth bringing up on the list at some point
<vagrantc>gotta head out for now, but thanks for pointing out something that is either undocumented or at the very least, not trivial to find! :)
<atomizedalex>I agree with the aims of the FSF, in general terms, although my academic background leads me to see its approach as a bit Quaker--creating an island of purity with little influence on the political lifeblood of society. That of course means that there is an organizational difference and I might be more at home in a more catholic (universal) community with room for sin.
<vagrantc>or even a bug report to bug-guix@gnu.org
<atomizedalex>Cheers for the polite conversation.
<vagrantc>yeah, you'll find people in guix who don't even agree with all the decisions, but are willing to work with this great community because of other strengths :)
*vagrantc waves
<vagrantc>you don't have to believe or agree 100%, just be willing to understand the boundaries :)
<oriansj>atomizedalex: one does not shift a political discussion by compromising core values.
<oriansj>and to argue that the FSF's puritan beliefs had little influence on the political lifeblood of society misses a great deal of the political reality of modern software.
<oriansj>but I will grant that guix might not hit the global use numbers of Redhat or Ubuntu or Android; but Nix and Guix are going to chance distros forever. In fact in some ways they already have.
<atomizedalex>I take your point and I appreciate programmatic points. I also appreciate the work of the FSF and the Guix developers (otherwise I would not have stumbled in here).
<MisterMentat>Is gfortran-toolchain supposed to *not* export libgfortran? And if so, what package can I get from Guix to get it?
<MisterMentat>After some digging, I found a gfortran installation in /gnu/store that has the libgfortran.so files but they don't seem to be exported from gfortran-toolchain. Is there some way to fix this? I'm new to Guix. (I do know scheme though.)
<apteryx>atomizedalex: hello! sorry, I was away for a bit and missed your replies. I think this policy comes from the GNU FSDG yes; and the commitment of GNU Guix to free software in general.
<apteryx>to be clear, steering someone toward instructions to install nonfree software is what went against it
*apteryx vanishes into sleep
<atomicalex>Yes, I understand; it is a central aim to make an operating system without proprietary black boxes. I share the committment, but mentioned nonfree blobs because I incline to jesuitical casuistry (which I won't do again here).
<civodul>Hello Guix!
<roptat>hi guix!
<jonsger>how would one write `(mesa_path (string-append (assoc-ref inputs "mesa") "/lib"))` in gexp way?
<gnoo>maybe you want: `(mesa_path ,(string-append ...))
<gnoo>or just (list 'mesa_path (string-append ...))
<civodul>jonsger: #~(mesa-path #$(file-append (this-package-input "mesa") "/lib") ...)
<civodul>assuming that's within a package
<efraim>apteryx: yeah, I got webrtc-audio-processing building on all architectures, so that enabled a bunch of builds
<mbakke>jonsger: (dirname (search-input-directory inputs "lib/libGL.so"))
<jonsger>mbakke: but then I need to find an arbitrary file in the inputs "lib/" folder
<jonsger>if that file gets however removed in an update it will no longer work...
<jonsger>in that case I just wanna have: /gnu/store/xxx-mesa-x/lib
<mbakke>jonsger: I don't think libGL.so will ever disappear from Mesa :)
<mbakke>errh, I meant search-input-file above
<jpoiret>is GUIX_UNINSTALLED set if and only if we're running guix from a git checkout?
<jpoiret>i'll just use ((@ (guix describe) current-channels)) == () instead
<jonsger> https://paste.opensuse.org/view/raw/78637735 thats what I have to convert from sexp to gexp new way. Wasn't successful yet and the feedback loop is > 0,5h :(
<vldn>sneek: botsnack :*
<sneek>:)
<rekado_>jpoiret: it’s only set by pre-inst-env
<rekado_>jonsger: which part exactly is giving you trouble?
<rekado_>the snippet you posted would work even in the context of a gexp
<rekado_>do you want to use this-package-input and the like?
<jonsger>rekado_: I tried to use the new style in (inputs) and (native-inputs), then it complains about that stuff in '("pulseaudio" "mesa"), not being a string or returning #f
<jonsger>need to recompile and see the backtrace...
<rekado_>jonsger: don’t recompile
<rekado_>you can shorten the loop by adding a build phase to the very beginning
<rekado_>even before 'unpack if you want
<rekado_>you don’t need to wrap anything yet; if it’s just about accessing the inputs then that should work just fine in a phase before 'unpack
<jonsger> https://paste.opensuse.org/view/raw/48181005
<vldn>civodul: are there manpages for the guile-sqlite3 module?
<vldn>or some examples somewhere?
<civodul>vldn: i'm afraid there's no manual
<civodul>you can find examples in Guix though
<civodul>like (guix store database)
***ft_ is now known as ft
***darosior3 is now known as darosior
<vldn>civodul: ah ty!
<mbakke>would it make sense to expose native-inputs to builders even when not cross-compiling?
<mbakke>then tricks like f97fe92b570b01ed1b03abd4f3ec89bf20ebc9db could be performed on the build side
<gnoo>hello, looks like the pandoc package doesn't have pandoc manpage
<gnoo>man pandoc -> No manual entry for pandoc
<civodul>mbakke: like passing #:native-inputs to build phases while leaving #:inputs unchanged, right?
<civodul>it's conceptually kinda confusing maybe
<mbakke>civodul: indeed, #:inputs would behave the same as now, but builders can access #:native-inputs if they want.
<mbakke>it could fix https://issues.guix.gnu.org/25235 for good, and get rid of some (or native-inputs inputs) hacks :)
<mbakke>not sure if native-inputs is any less confusing today
<civodul>yeah, maybe you're right
<civodul>i guess we should give it a try and see if there are corner cases or unintended consequences
<civodul>it's true that those (or native-inputs inputs) bits aren't pretty :-)
<vldn>mhh what for is the nix-daemon still used in guix? just for generating the hashstring+drvfile and navigating/creating the build processes? i mean the database api in guix store database is quite nice @ civodul, shouldn't be so hard to write a daemon replacement with guile-fibers or am i wrong?
<vldn>maybe someone knows in which specific place/file the nix-daemon is called from our guile scripts?
<sughosha>Hi, I have few questions regarding the Guix package manager. I would appreciate anyone for the help.
<sughosha>1. Is there a way to list system-wide installed applications? `guix package --list-installed` lists only profile's packages.
<sughosha>2. Is it possible to list files of an installed application?
<sughosha>Thank you.
<vldn>guix package --list-installed --profile=/run/current-system/profile @sughosha for your guix system config.scm installed packages
<sughosha>vldn Thank you! It worked! 😃️
<Rodon>hi i am interested in installing guix on debian 11.. what is minimum size after guix -pull ? i want to start with minimum..
<vldn>and you can look at the dependency graph for your second question sughosha
<vldn>look here: https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph.html
<vldn>guix graph PACKAGE | dot -Tpdf > dag.pdf something like this
<vldn>or with xdot installed: guix graph PACKAGE | xdot -
<sughosha>vldn I will try them. Thank you.
<civodul>vldn: you're right, but the devil is in the details :-)
<civodul>there's a branch with a preliminary daemon rewrite in Scheme
<vldn>ah sughosha maybe try guix size instead
<civodul>and the goal is to do that, but the project is currently dormant
<vldn>then you don't need extra tools :)
<vldn>guix size PACKAGE
<vldn>yeah already saw that and wanted to contribute or write a new one but had a hard time finding the right files to know what the nix-daemon is used for
<vldn>so just this two use cases? Hash+drv into Sqlite and Buildjob management?
<sughosha>vldn `guix size PACKAGE` shows the dependencies list. I wanted to list the files of the package. Anyway thank you.
<vldn>then you have to cd inside your package like /gnu/store/nwi7az05ikkvnfbbkda62s4156z6rs68-wine-7.0 and make a good old "ls" :)
<vldn>maybe there is some nicer way but don't know
<vldn>but don't manipulate files there
<sughosha>vldn Yes, but it's bit difficult to get the store link, currently I am using `find` command but it is slow.
<vldn>/gnu/store should be untouchable
<vldn>guix size is comparable slow too but shows the right path
<sughosha>Hm. Yes.
<gnoo>sughosha: readlink -f "$(type -p <package name>)"
<vldn>ah nice
<vldn>should make that as an alias :D
<sughosha>gnoo That command outputs nothing.
<gnoo>not the package name but the binary name
<vldn>works for me
<sughosha>gnoo Yes you are right. Thanks! I don't know how it functions but it worked :)
<sughosha>I will alias it right now.
<vldn>and it would be a nice addition to the guix cli or am i wrong?
<gnoo>cdpack() { local path; path=$(readlink -f "$(type -p $1)"); echo "$path"; cd -- "${path%\/*}/../"; }
<gnoo>a better function, cds to the path, should probably check for errors there
<sughosha>vldn It would be nice to add it to guix. Some package managers like `apk` and `pacman` provide options to list the installed files. It would be really good addition to guix.
<gnoo>sughosha: yeah, that's an option i really miss. void has an interesting solution to it, they have a git folder listing all the outputs of a package and provide a script that searches that folder
<gnoo>so you just do xlocate /bin/emacs and it'll give you all the packages that have /bin/emacs in it's output
<vldn>two more guix cli arguments, get the /gnu/store/path and one to list the files in it, maybe with an additional flag
<sughosha>vldn Yes, these two options would come handy.
<mbakke>sughosha: you can do 'find $(guix build package)' to list the contents
<gnoo>still, you don't know which package provides a certain binary
<sughosha>mbakke I was thinking that `guix build` would build a package, but it just shows the path! Cool.
<gnoo>it builds the package if it's not already built but prints the path if it is built
<sughosha>Yes, as gnoo said, querying which package owns the binary would be very useful.
<sughosha>Ok.
<sughosha>Actually, I am trying to build `geary`. It shows `messaging-menu` as missing dependency, but I don't know which package provides `message-menu`.
<gnoo>if it uses pkg-config, that should tell the general name of package. maybe messaging-menu is a package in itself that's not on guix yet?
<sughosha>gnoo Just now I noticed that `/gnu/packages/gnome.scm` doesn't include `pkg-config`.
<sughosha>I think no one issued a bug for this (or at least I couldn't to find one in issues.guix.gnu.org)
<sughosha>I think I should file a bug report.
<gnoo>probably because it's a virtual package i.e. it itself doesn't have anything
<gnoo>try 'guix edit gnome' and see that it is just a big list of propagated-inputs
<zimoun>Giving a look at the GHC new bootstrap by rekado_, I notice that gcc-toochain@4.8.5 does not build.
<sughosha>hm. I need more experience to understand them better. I just started using Guix this week but learnt so much from the manual and this community!
<sughosha>I think the best way to understand Guix is to learn Guile or Scheme and then read the default .scm files.
<rekado_>zimoun: yeah, GCC 4.7 also doesn’t build
<rekado_>jonsger: can you show me the complete package definition please?
<rekado_>I need to know where you’re using gexps and what the full expression looks like (what parts are quoted and how)
***dgcampea-2 is now known as dgcampea
***daviid`` is now known as daviid
<attila_lendvai>how is the release-monitoring-url property used? is it something that i can run locally? or is there a regular report published somewhere?
<attila_lendvai>i have a channel, and i'd be happy to get notifications at new upstream releases...
<AwesomeAdam54321>attila_lendvai: Is 'guix refresh' what you're looking for?
<attila_lendvai>AwesomeAdam54321, but doesn't `guix refresh` work even for packages without such a property? by guessing it?
<rekado_>attila_lendvai: it doesn’t guess. There are defined updaters.
<rekado_>e.g. in (guix import cran) see %cran-updater and %bioconductor-updater
<civodul>release-monitoring-url is for those packages that get updated by the "generic-html" updater
<roptat>you could check that the packages in your channel have an updater, and then set up a cron job to run guix refresh regularly
<roptat>you'd get notified by email of the result
<apteryx>civodul: there's actually some caching going on for nginx; see the %extra-content variable in hydra/nginx/berlin.scm
<apteryx>efraim: well done!
<civodul>apteryx: oh indeed! there's a cache for nars, but not for narinfos (which is important, so that "guix publish" can have its LRU policy)
<civodul>i guess it can't hurt
<apteryx>I cleared it yesterday; so now it's testing our fresh new copy of substitutes under /var/cache.
<apteryx>(or rather, rebuilding its cache from the new /var/cache/guix/publish nars)
<char[m]>what package is dlopen a part of?
<jpoiret>the c function?
*roptat is running guix refresh -t opam again...
<char[m]>just the one I can use at command line
<roptat>looks like we have enough OCaml packages that I need to run it regularly
<jpoiret>char[m]: does that even exist?
<roptat>if you already have it you can try "ls /gnu/store/*/bin/dlopen"
<char[m]>jpoiret: maybe I am looking for the c function then ...
<roptat>never heard of it before
<jpoiret>the c function should be provided by ld.so, so I think it should be ok to use in any program compiled with gcc
<roptat>the c function comes from the libc I think
<jpoiret>right, it's in libc, standardized by POSIX
<jpoiret>it's in dlfcn.h if you need it in C
<roptat>why do you think you need it?
<char[m]>roptat: for cffi to find shared libraries
<roptat>I see
<roptat>then I think it's more likely you're looking for the C function
<char[m]>thanks, I think glibc worked for me.
<rekado_>roptat: I do the same for R packages regularly
<rekado_>lots of work!
<rekado_>maybe we should automate this some more
<roptat>that's a bit difficult for ocaml, because the source is usually not correct
<roptat>I mean, it's usually a github tarball
<roptat>so I often change that manually to a git checkout
<roptat>I'd appreciate any effort in that direction though
<rekado_>perhaps we can use the github API to retrieve the corresponding git commit
<roptat>I'd have to guess the github URL :p
<roptat>although, it's usually the package's home-page
<roptat>oh but it's part of the source URI anyway, I'm stupid
<roptat>mh, coq isn't going to be fun to update
***Noisytoot_ is now known as Noisytoot
<katco>hey guix friends! i'm trying to get a libvirt service to listen on a tcp socket. the docs for `listen-tcp?` say "You must set listen for this to have any effect.", but i can't find a `listen` parameter, nor a way to start libvirtd with `--listen`. any ideas?
<civodul>katco: hello! i think it's actually 'listen-addr', no?
<civodul>the doc is misleading
<katco>civodul: hm, no i don't think so? that just tells it what address to listen on, but there is a `--listen` flag that enables listening at all
<katco>i.e. https://libvirt.org/remote.html " Note: it is also necessary to start the server in listening mode by running it with --listen or adding a LIBVIRTD_ARGS="--listen" line to /etc/sysconfig/libvirtd."
<jpoiret>mhmmm, i need some help on the guix bootstrapping process
<jpoiret>in build-aux/build-self.scm, we explicitely don't select (guix channels), but it is still somehow ends up inside the build environment of the derivation
<jpoiret>i say that because i added some code to (guix channels) that requires (guix git), in turn requiring (git object) which isn't available at this stage
<civodul>katco: oh, so could it be that we're just lacking that option?
<civodul>i've never used this service, so i'm just trying to guess :-)
<katco>civodul: i looks that way, but i wanted to check before i submit a bug!
<katco>in the meantime i'm wondering if i could work around it by passing a script into the service for its `libvirt` package
<civodul>i don't see an easy way to do that :-/
<civodul>jpoiret: weird, you'd have to find out where that (guix channels) come from; you can add pk calls in there :-)
<katco>hm, yeah, maybe this won't work. you can pass in the libvirt package to use, but there's more than the shepherd service's forkexec using that.
<katco>i'll submit a bug
<jpoiret>civodul: alright, it's definitely my fault (added a ref to (guix channels) in (gnu packages package-management))
<jpoiret>it still seems weird that guix/channels.scm is included in the source though
<mbakke>Clang crashes while building the new version of ungoogled-chromium and dumps a neat reproducer; but it does not crash when running the reproducer interactively in 'guix shell'
<jpoiret>setting %load-hook helped a bunch hehe
***daviid` is now known as daviid
<civodul>jpoiret: %load-verbosely is "nice", too
<civodul>mbakke: it's great that it emits a reproducer, though; good intent
<jpoiret>quick question, why do we take care to use source-module-closure when right at the beginning of the build script, we basically do (set! %load-path (cons source %load-path))?
<civodul>these are two different things: with-imported-modules ensures that in the derivation's environment we have all the Guix modules from the host Guix
<civodul>and then setting %load-path allows us to make sure we load the right modules
<civodul>hmm that's poorly said
<civodul>sorry
<jpoiret>more pragmatically: won't the (use-modules (guix self)) try to load the self from source rather than from the imported modules?
<jpoiret>i think i've pinpointed the issue: compiled-guix tries to pass a daemon to whole-package, which it gets from (gnu packages package-management), hence why that file ends up being loaded
<jpoiret>although setting %load-hook shows that _a lot_ of (gnu packages ...) modules are being loaded
<efraim>civodul: I looked at (guix cpu) again for aarch64, not all the values from /proc/cpuinfo are being read it seems
<whound>Can anyone give tips on making Sonic-Pi package def ?
<efraim>civodul: I think I found it, stopping the loop at flags on x86_64 works, stopping at Features on aarch64 doesn't work since CPU implementer is after it
<efraim>I got it looping over all of /proc/cpuinfo, now I have the CPU implementer and CPU part, time to get the actual sorting down!
<leinad>Hi Guix! Today, I have noticed the following message just before gdm shows the login screen: localhost elogind[364]: elogind is already running as PID 354
<leinad>Is this expected behaviour? Seems like elogind is started twice.
<acrow>If anyone wants to harvest, what I think, is the low hanging fruit of bug#53908, I am openly lurking here.
<lilyp>"all-jar" sounds suspiciously like "we're bundling all our dependencies into this thing"
<jpoiret>leinad: what architecture are you running on? is your computer using a SSD or HDD?
<acrow>For batik, yes.
<leinad>jpoiret: A 256GB NVMe SSD on x86_64
<acrow>I could find no existing package that included everything that was required.
<jpoiret>hmmm, weird
<jpoiret>it's a known issue, but I thought it would cause actual errors
<jpoiret>can you check that all services are properly started with `sudo herd status`?
<acrow>Batik is, after all, a toolkit for other things. I hope the all-jar may be used by others.
<leinad>jpoiret: All services are properly started, except for term-auto, this one is stopped.
<jpoiret>yes, that's normal
<jpoiret>well, if everything works fine, let's just ignore that
<leinad>Yeah, it works fine :) I just have the impression it steals a second or two of my boot time
<leinad>and was wondering whether I can do something about it.
<jpoiret>we start elogind manually rather than on-demand through dbus, and maybe there's a race between elogind registering to dbus and someone else asking for elogind on the dbus, leading to dbus trying to start it (again)
<leinad>ahaaa! that makes sense
<jpoiret>although we haven't yet been able to see which program is the culprit
<acrow>leinad: I was able to avoid that message by putting elogind-service and the ssdm login manager together with xfce in my system configuration. The problems went away albeit because I had the flexibility to just make some different choices. Still, maybe there is a clue in there.
<leinad>I see... so maybe it's gdm itself which causes the race
<jpoiret>most of the shepherd services that rely on elogind should wait until it's fully started (written its pid file), and that happens after elogind registers on DBus
<acrow>leinad: that is kinda what I concluded but wasn't able to troubleshoot.
<acrow>jpoiret: I think those timing issues are difficult to resolve for all systems.
<jpoiret>ehmmmmmmmmm
<jpoiret>big oops
<jpoiret>looks like gdm-shepherd-service just doesn't have elogind as a requirement
<jpoiret>i'll send a patch asap
<leinad>aha :-)
<acrow>What if gdm triggers the dbus startup of a elogind that is already in the middle of startup?
<leinad>jpoiret: perfect! thank you very much
<jpoiret>acrow: that's exactly what happens
<jpoiret>we can wait for elogind to be fully ready by simply having the shepherd service depend on elogind being started
<jpoiret>which is (weirdly) not the case
<lilyp>I don't think shepherd is smart enough to enforce itself upon dbus yet (which is the main difference from systemd)
<leinad>lilyp: What does that mean wrt. this issue?
<jpoiret>leinad: just opened https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53926 :)
<leinad>cool... I could apply the patch and test it with my system
<acrow>jpoiret: nice.
<jpoiret>sddm does in fact require elogind, so that's why it worked better :p
<jpoiret>well, if you know how to do that, go ahead!
<jpoiret>for some reason, I don't see that on my own system (maybe it's slower, who knows)
<acrow>jpoiret: I doubt that slower system claim. :)
<jpoiret>it's a mere i5 from 5 years ago
<acrow>jpoiret: sounds like it has some character.
<vivien>guix shell pkg-config glib --container -- pkg-config --exists glib-2.0 && echo ok
<vivien>guix shell pkg-config vips --container -- pkg-config --exists glib-2.0 && echo ok
<vivien>Why does the first command prints ok and not the second one?
<vivien>Sorry
<vivien>guix shell pkg-config vips --container -- pkg-config --exists vips && echo ok
<acrow>vivien: I am guessing it is because the instatiation of vips doesn't include glib-2.0.
<acrow>s/instatiation/instantiation/ I hope.
<ryanprior[m]>I'm having trouble with direnv installed via Guix on a foreign distro (my elementary OS laptop): when I try to run direnv it fails with an error like libc.so.6 - version not found
<vivien>Thank you acrow, it seems that I have a lot of libs to find!
<ryanprior[m]>But if I run `guix shell -C direnv bash coreutils` and then run direnv, it works fine. So it seems like direnv is picking up something incompatible from the base OS instead of from my profile?
<acrow>vivien: I got the same outcomes you did. Using guix size you can see that vips does reference glib-2. pkg-config may not dwelve deeply enough in a guixy world, no?
<lilyp>ryanprior[m]: `which direnv` normally?
<ryanprior[m]>lilyp: `readlink $(which direnv)` reports the same store path inside & outside the container
<ryanprior[m]>However, `ldd $(which direnv)` reports slightly differently inside vs outside.
<acrow>vivien: vips certainly appears to reference many libraries.
<civodul>pukkamustard: i had completely overlooked v2 at https://issues.guix.gnu.org/52555#8, and that looks pretty exciting!
<vivien>I’m hunting them down
<ryanprior[m]> https://gist.github.com/ryanprior/c2a12584d48ef35f11a99da469f7cb36
<lilyp>is that guix' ldd or foreign ldd?
<ryanprior[m]>Inside the container it's Guix's ldd, outside the container it's foreign ldd
<ryanprior[m]>If I explicitly use Guix's ldd outside the container, it gives me the same behavior as I get inside
<ryanprior[m]>So I'm not sure what to make of all that
<lilyp>/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f01e149d000) WTF is the linker doing here?
<ryanprior[m]>what indeed!
<lilyp>it already has an absolute path, so ???
<vivien>TFW a trivial package requires a huge package like pyvips for its tests, you package it, only to realize that the developer took it as an example of package that should NOT be present
<Kolev>Using Kodi as a DLNA server because I can't figure out minidlna on Guix. On Ubuntu, it's easy.
<leinad>jpoiret: I applied the patch, had no problems building guix. I am reconfiguring my system tomorrow and will report on #53926. Thanks, folks :)
*Kolev runs `guix pull` to warm his hands
<jonsger>rekado_: it's a non-FDSG compliant package, so I obviously can not share the whole package definition...
<tanner40>Guix System newbie here - I see in my `/var/guix/profiles/per-user/me/` directory several symlinks with the prefix `current-guix-` and several symlinks with the prefix `guix-profile-`. What is the difference between these two types of profiles?
<jackhill>tanner40: hi, welcome to Guix! the current-guix- ones are what gets updated when you do a `guix pull` to get new package definities and guix code. The other one is for software you've installed with Guix e.g. with `guix install`.
<acrow>lilyp: I see how eternal vigilance is the price of liberty. Guix facilitates virtually limitless manipulation of the build process.
<tanner40>jackhill thanks! so does that mean guix itself runs in an environment defined by a current-guix- profile, and that all other software runs in an environment defined by a guix-profile- ?
<jackhill>tanner40: yep, I'd say that's accurate
<acrow>lilyp: The batik-all-jar was derived entirely from the Apache batik source package. I modified the build so tha the default guix ant build system target, 'jars', would yield the provided ant build target, 'all-jar'.
<jackhill>tanner40: and naturally there are facier things for managing even more environemtns is needed. Chapters 4 and 5 in the cookbook https://guix.gnu.org/en/cookbook/en/html_node/Advanced-package-management.html 😀
<vivien>My python package sanity-check phase fails with: validating 'pyvista' /gnu/store/fk2k9iivcyyr90rc3nfvf93j5j78hysf-python-pyvista-0.33.2/lib/python3.9/site-packages
<vivien>...checking requirements: ERROR: pyvista==0.33.2 DistributionNotFound(Requirement.parse('vtk'), {'pyvista'})
<vivien>What does that mean?
<civodul>vivien: i think it means that your package needs pyvista at run time and that it cannot be found
<civodul>or not the right version
<vivien>My package is pyvista 0.33.2
<Kolev>Is there a way to tell Guix to not compile stuff?
<civodul>vivien: ah, then it must be vtk that's missing :-)
*civodul performs fuzzy matching on error messages
<vivien>civodul, I don’t understand, I have vtk as a propagated input and it should be sufficient
<civodul>yeah, dunno
<civodul>Kolev: in what sense? it compiles only when it can't find pre-built binaries (substitutes)
<vivien>civodul, what is DistributionNotFound and Requirement.parse? Is it guix-specific?
<vivien>I guess it comes from a file named "sanity-check.py" but I can’t find it
<vivien>OK I found it
<vivien>OK the problem might be that vtk doesn’t install a distribution file
<civodul>ah
<civodul>a poll (to be taken with a grain of salt) on "guix pull" news: https://toot.aquilenet.fr/@civodul/107769064690480004