IRC channel logs


back to list of logs

<Kabouik>This turns out to be harded than I hoped. i3status-rust needs rust-inotify-10, but when I change the version in the cargo-inputs to rust-inotify-0.10, then guix build says I might have omitted a use-modules.
<Kabouik>Tried to updae rust-inotify to 0.10 (although I don't think it is necessary because I think guix would fetch the dependencies from cates for building i3status-rust, I tried anyway), but upgrading rust-inotify to 0.10 fails with a similar error.
***jesopo is now known as jess
<AwesomeAdam54321>Does anyone know what the appropriate regex is for '$(MAKE) $(AM_MAKEFLAGS) install-am' in substitute*?
<AwesomeAdam54321>s/in/to use in
<Kabouik>nckx: re power_supply not refreshing its values except at reboots: I installed `upower` and I can now see my battery level change dynamically with i3status-rust. power_supply/BAT0/uevent gets refreshed now.
<jpoiret>Kabouik: Guix doesn't fetch the dependencies using cargo
<jpoiret>that's the thing
<jpoiret>otherwise Guix wouldn't have control over the dependencies
<civodul>Hello Guix!
<cbaines>hey civodul :)
<civodul>hi cbaines, how's everything?
<civodul>i noticed a pretty cool thing while reviewing patches: sometimes i get substitutes from bordeaux.guix!
<civodul>which i guess is a side effect of building the branches automatically
<Kabouik>jpoiret: Ok, then trying to update rust-inotify first was not a bad idea in the end. But I still got this error stating that I might have forgotten a use-modules, despite reusing all the use-modules of the previous version (taken from guix edit rust-inotify). I don't have the Guix machine at end right now to investigate more.
<jpoiret>Kabouik: what's the error exactly?
<cbaines>civodul, things are going well, busy but good
<cbaines>civodul, and yeah, funnily enough I noticed that too. Went to build a package after I'd applied a patch, and I just got the substitute...
<efraim>civodul: thanks for pushing the racket update. I realized last night I had forgotten that part
<cbaines>but yes, I've been submitting builds for patch series to the bordeaux build coordinator, and I need to get around to updating guix-devel on the progress made
<efraim>cbaines: I'm loving the updated branches for newer versions of patches. Made it easier to take the racket patches and rebase them on master while checking them out
<cbaines>efraim, that's good to hear :)
<sneek>wb antipode
<Luk6655>let's say I need to use virtualenv with guix shell(because guix import doesn't support indexes different than pypi site), is there something special I need to do to make it work? (my existing venvs don't work, perhaps due to difference in python version 3.8~3.9)
<efraim>abcdw: I like your ignoring .go files in the .dir-locals.el, finally figured out how to do that in vim :)
<Obikawa>Hi. I have a question about packaging: Are `inputs` accessible in the store during run-time?
<cbaines>Obikawa, not necessarily, but any store item that is referenced by the package output will be available
<cbaines>so, usually for a package, the built outputs will reference a subset of the inputs that were available at build time
<efraim>jgart[m]: The one liner to ignore '.go' files in file completion in vim when you have a scheme file open is (for .vimrc) 'autocmd FileType scheme setlocal wildignore+=*.go'
***jetomit_ is now known as jetomit
<Obikawa>cbaines What does "referenced by the package output" mean? I looked at the documentation, and (package (outputs ...)) does not appear to be the matching combination.
<Obikawa>I am still very dumb when it comes to Guix.
<cbaines>Obikawa, references as in they mention the store item. Take this example of the references for the output of the hello package
<cbaines>other than itself, the output references two other store items
<abcdw>efraim: Cool! How it looks in vim land?
<cbaines>you can use grep to see which specific files in the hello store item contain those references
<cbaines>Obikawa, this makes some sense, since you can't use something that you don't maintain a reference to
<Obikawa>cbaines I am sorry - I do not think this is what I want. I am trying to make `gnupg` available at runtime for `trezor-gpg`. I was told `propagated-inputs` are to be avoided, but nothing else seems to give the correct result. Is it even possible to "propagate" an input without adding to the user's profile?
<cbaines>Obikawa, could you point to where in the trezor-gpg code that it tries to use gpg/gnupg?
<Obikawa>cbaines From the Python backtrace: File "/gnu/store/9bbnkjs4n1b92kz286vrfm49cwarkgdk-python-trezor-agent-0.14.4/lib/python3.9/site-packages/libagent/gpg/", line 194, in get_gnupg_components
<Obikawa>    args = [util.which('gpgconf'), '--list-components']
<cbaines>Obikawa, ok, so you could at build time replace util.which('gpgconf') with the absolute path to the gpgconf binary, but I'm not sure if that's the best approach here
<cbaines>since this is trying to connect to some other process, I'd perhaps make gnupg a propagate-input
<cbaines>given a user is probably only wants one gpg-agent processing running, I think the propagated inputs approach may be more appropriate here
<efraim>abcdw: was afk. I set it globally for all scheme files and then unset it for "guix files" (which is currently just guix.scm). basically the line I mentioned to jgart but I put it in ~/.vim/after/ftplugin/scheme.vim
<Obikawa>cbaines, I spent three days trying to modify the Python script, and the backtrace never showed an absolute path to GPG. I am confident that Trezor Agent calls a GPG process at runtime. However, I am unable to prove that `propagated-inputs` is the ONLY way to solve the error. Should I just press in the Guix Issue
<Obikawa>for acceptance of the `propagated-inputs` way?
<ulfvonbelow>https connections to my server (uses letsencrypt cert) work with icecat, but not with curl or wget. Any idea what might be causing that?
<abrenon>hi guix
<cbaines>Obikawa, so, rekado is suggesting some inbetween approach where the gnupg available at build time is used as a fallback if gnupg isn't available in the users environment. That sounds OK to me.
<efraim>Obikawa: would it work to wrapp the python script with gpg?
<cbaines>wrapping should be able to achieve the same result as well, providing you add the gnupg package output to the end of the PATH rather than the start
<cbaines>that'll also be less fragile than patching the .py files
<ulfvonbelow>curiously enough, the prosody https server seems to work just fine, even though it uses the same certificate
<efraim>/gnu/store/dlxi64dq6z5bf0fmazmm6ccvqr0fk3hj-python-trezor-agent-0.14.4-checkout/libagent/gpg/ calls to gpgconf
<pkill9>ulfvonbelow: is $SSL_CERT_DIR and $SSL_CERT_FILE set?
<Obikawa>cbaines, I have built `trezor-agent` many times with `gnupg` in `inputs` and it was never picked up. efraim: I started working on the wrapping idea, but I am too dumb to execute it.
<pkill9>also $CURL_CA_BUNDLE
<efraim>does this ring any bells? cmd = get_gnupg_binary(neopg_binary=env.get('NEOPG_BINARY'))
<ulfvonbelow>pkill9: SSL_CERT_DIR = /run/current-system/profile/etc/ssl/certs, SSL_CERT_FILE = SSL_CERT_FILE=/run/current-system/profile/etc/ssl/certs/ca-certificates.crt, CURL_CA_BUNDLE = /run/current-system/profile/etc/ssl/certs/ca-certificates.crt
<ulfvonbelow>system has nss-certs in os packages
<Obikawa>efraim I am under impression that it is some GPG fork.
<efraim>ok, so probably not relevant
<ulfvonbelow>my first thought was that I would need to install le-certs, but that doesn't explain why it does work with the prosody http file upload https server, which uses the same certificate
<efraim>it looks like /gnu/store/dlxi64dq6z5bf0fmazmm6ccvqr0fk3hj-python-trezor-agent-0.14.4-checkout/libagent/gpg/ in function get_gnupg_binary returns neogp_binary or the string 'gpg'
<ulfvonbelow>wget says "ERROR: The certificate of ‘<my-domain>’ doesn't have a known issuer."
<abcdw>efraim: Oh, I missed your reply to jgart, now I see, looks simple :)
<efraim>abcdw: once you see it it's obvious, took me a while to figure out what to search for :)
<Obikawa>efraim: In theory, should this line have worked? `(substitute* "./libagent/gpg/" (("'gpg'") (string-concatenate (list "'" (which "gpg") "'"))))` In practice it did not, but I am likely to have misunderstood something.
<efraim>Obikawa: there's a bunch of other calls to other binaries in the gnupg package, I'll write an email to bug 57345 suggesting about wrapping the files in trezor-agent
<civodul>cbaines: that substitutes are available when testing patches is really convenient
<abcdw>efraim: To be fair, I found completion-ignored-extensions by accident, but liked how it works and keep it :)
<civodul>cbaines: it's perfect integration, one doesn't even need to go and check a web dashboard
<Numerobis>Hi again #guix. First, let me mention that my issue yesterday was solved by using "guix system delete-generations". I thought "guix gc" was already doing this, but this is not the case. I have another question today: it seems that the versions of biblatex and biber on guix are incompatible. Is there any solution to this issue?
<cbaines>civodul, haha, that's true, of course I've been working on a web page that summarises the testing for a issue, but yes, if you know what has changed, you can check this through substitutes
<sneek>muradm: wb!!
<rekado>Numerobis: “guix gc” only removes items from /gnu/store that cannot be reached from any root, e.g. a profile generation.
<rekado>you do need to remove old generations if you want to release the item they refer to.
<efraim>cuirass keeps trying to build rust for aarch64. We might need to give one machine lots of swap and manually start the rust build
<ulfvonbelow>hmmm, adding le-certs seems to work for curl, and unsetting all the certificate environment variables makes 'wget --debug ...' still claim it's loading 444 certificates.
<antipode>ulfvonbelow: Not all programs support SSL_CERT_DIR / SSL_CERT_FILE, some hardcode /etc/ssl/certs. Maybe wget is one of those?
<ulfvonbelow>hmm, in that case I'd have to reconfigure the system
<ulfvonbelow>been putting it off for a bit, so it'll take awhile
<ulfvonbelow>sounds plausible, though
<Kabouik>Is there something blocking this? As far as I understand there are no alternatives to wayvnc for Guix and Wayland ad the moment
<Obikawa>Thank you efraim. I have implanted your code and now am rebuilding the system configuration. In one hour I will know the effect.
<cbaines>Obikawa, I'd recommend just building the package and checking the output
<cbaines>Obikawa, how is the package involved in your system configuration?
<Obikawa>cbaines, I do not know how to build the package itsellf. I want to use Trezor Agent as my crypto identity source.
<cbaines>Obikawa, probably something like ./pre-inst-env guix build trezor-agent
<Obikawa>cbaines does that command create files in $PWD?
<cbaines>Obikawa, probably not, although .go files may be created if you don't run make
<cbaines>Obikawa, what you're looking for is the trezor-agent package output, which will be in the /gnu/store
<ulfvonbelow>still doesn't explain why curl works on the prosody https server but not the nginx one... only difference I can spot is that the nginx request is using TLS 1.2, while the prosody one is using TLS 1.3
<pkill9>has anybody used SELinux on Guix System?
<efraim>I just realized vifm bundles lua-5.4. Will have to see about unbundling that
<civodul>pkill9: i doubt it! then again, is it a good idea? :-)
<mrvdb>i'm running emacs-next but I'd want it with a configure flag changed (--with-toolkit=lucid) What is the recommended way to do that? Create a derivation of the package emacs-next?
<rekado>mrvdb: yes, define a package variant that overrides the configure flags.
***wielaard is now known as mjw
***PrinceMyshkin09 is now known as PrinceMyshkin0
***MonsoonSecrecy_ is now known as MonsoonSecrecy
***rheaplex_ is now known as rheaplex
***abcdw_ is now known as abcdw
<mrvdb>rekado: ok, thx
***m5zs7k_ is now known as m5zs7k
<Luk6655>Does anyoen know what is guix's equivalent to ldconfig -p ?
<Luk6655>(to show available shared libraries)
<muradm>guix shell gcc-toolchain -- ldconfig -v works, but i don't think there will be reasonable -p output
<Luk6655>I found I can get what I need with checking the LIBRARY_PATH variable
<Luk6655>but I was very surprised to find guix shell doesn't touch this variable
<Luk6655>for example if I run "guix shell python mesa" it doesn't add mesa libs to LIBRARY_PATH, it leaves it unchanged
<Luk6655>if I specify "guix shell python mesa --container" or --pure, it blanks LIBRARY_PATH, but mesa shared libs are stil not acessible
<muradm>Luk6655: first try file $(readlink $(which ls)) and pay attention to "interpreter" value
<Luk6655>in the guix shell ?
<muradm>in any prompt i suppose should work
<muradm>$ file $(readlink $(which ls))
<Luk6655>ok, it shows a path to coreutils in /gnu/store
<muradm>and then also have a look at 'guix shell gcc-toolchain -- ldd $(readlink $(which ls))'
<Luk6655>it seems to use the same locations
<Luk6655>sorry, I don't get it, does this mean guix shell is capable of adding shared libs to temporary environments it creates or not?
<muradm>Luk6655: you normally should avoid LIBRARY_PATH usage. i suppose you want to launch some application which requires mesa, if it is opensource, you'd better repackage it for guix
<muradm>then whatever tool is used for building, cmake, meson whatever, will find proper locations of libs etc.
<Luk6655>I'm trying to load a python module that requires a particular .so file from mesa, it is far too much work to be repackaging it for guix
<muradm>Luk6655: try packaging that python module for guix and then use it
<muradm>it will make your life easier
<Luk6655>I can;t be packaging everything I need for guix....
<Luk6655>I weould be doing nothing but packaging for guix for next 10 years...
<Luk6655>is this the only way?
<muradm>are you using guix as package manager, or guix including os?
<Luk6655>I expected guix shell to simply make shared libs available in some way to whatever runs within it, but now it seems everything must be guix aware to run in it? is this true?
<Luk6655>I use guix as os
<Luk6655>also I wanted to take advantage of guix ability to create temporary semi/isolated environments
<muradm>there are two ways, one way is to get used for packaging which is easy enough, other way is to spend hours mangling with LD_LIBRARY_PATH and then fail again if you executable compiled not on guix with interpreter set to somthing like /lib/
<Luk6655>I guess guix is not for me
<muradm>which python module requires mesa?
<efraim>/gnu/store/dl192sx56kqcxan1i1qas03nkhj6bpqa-webkitgtk-2.36.7/lib/ ELF 64-bit LSB shared object, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), dynamically linked, not stripped
<Luk6655>it is not mesa
<Luk6655>mesa is a placeholder
<muradm>Luk6655: guix package --list-available=webkit
<Luk6655>sorry, I'm not sure what is the signifficance of webkit, or the list of packages related to it
<Luk6655>However, one thing I don't get is how people that use guix on top another os deal with this
<Luk6655>do they just use guix shell with packages that are themselves (and all their dependencies) packaged for guix?
<muradm>Luk6655: it is not clear what you are trying to achieve
<Luk6655>ok, let me clarify, I have a python module (actually a pretty big collection of them) that all rely on a shared library that is packaged for guix
<Luk6655>I have the shared library installed at OS level and it works
<Luk6655>perhaps I could install it with guix install mylibrary and it would work
<Luk6655>but this defeats a purpose of having separate development environments
<Luk6655>I hoped to be able to use guix shell to create a temporary environment that contains python, and my library
<muradm>this colletion of python modules are not available already in guix?
<Luk6655>then I could run my module, unfortunately my module can't load the shared library
<Luk6655>onn other distros this particular requirement is fulfilled by conda (which I'm not a huge fan of)
<muradm>Luk6655: what does it mean "i have a shared library installed at OS level"?
<Luk6655>It means I have it specified as package in my OS config
<Luk6655>my OS profile is also a root profile
<muradm>guix shell pkg-config wlroots -- pkg-config --libs wlroots
<muradm>try running this
<muradm>may be it will make clear for you
<Luk6655>what does --libs do?
<muradm>Luk6655: you know what pkg-config does in general?
<Luk6655>yes, it provides location of libraries for compilation
<Luk6655>I need it for runtime rather than compilation/linking
<Luk6655>for example: guix shell --search-paths pkg-config wlroots -- pkg-config --libs wlroots
<Luk6655>export PATH="/gnu/store/pd3rqvkyi7bs9j54ba8ky9yx6rlmfh8q-profile/bin:/gnu/store/pd3rqvkyi7bs9j54ba8ky9yx6rlmfh8q-profile/sbin${PATH:+:}$PATH"
<Luk6655>export PKG_CONFIG_PATH="/gnu/store/pd3rqvkyi7bs9j54ba8ky9yx6rlmfh8q-profile/lib/pkgconfig:/gnu/store/pd3rqvkyi7bs9j54ba8ky9yx6rlmfh8q-profile/share/pkgconfig${PKG_CONFIG_PATH:+:}$PKG_CONFIG_PATH"
<Luk6655>it shows this first path that ends in sbin,(in my guix shell python mylibrary) if I look in there there is a lib folder that contains mylibrary
<Luk6655>but my guix-unaware module doesn't know how to find it there
<muradm>should not be aware of anothing global in general, don't think of it like a standard distro that puts all eggs into one bin
<Luk6655>I assume this folder is not global but created for this environment
<muradm>in stead, every application built with guix knows their exact dependencies
<Luk6655>so I just would like to clarify this: guix shell doesn't provide any facility for non-guix executables to find guix shared libs
<Luk6655>is this tru?
<Luk6655>I mean for runtime use, rather than for building
<muradm>above I mentioned that executable compiled outside of guix, will not run at all out of the box, due to "interpreter" thing
<muradm>regardles if you provide libraries on sight or not
<Luk6655>well, I'm not really running an executable in a traditional sensne, I use guix's python, guix's library, just a module compiled elsewhere that expects to find that library on some path
<muradm>Luk6655: i suppose better to say that, guix makes runtime environment to build application, and then run it
<muradm>this will be hard, you will be advised to build that module depending on binary for guix
<muradm>which will be much more easier
<muradm>which module is that?
<Luk6655>it is not just this module, or this library, I have tens of dev environments, for example buildroots that all depend on stuff compiled elsewhere
<Luk6655>if I can't get one simple module to load a shared lib without having to recompile it, it is very unfortunate, because I wqas hoping I can use guix as OS, take good parts, and still run other software compiled elsewhere in temporary separate environments. It appears that's impossible without conda,docker or VM..
<Luk6655>I think I'll try few other things to see if I can make it work
<muradm>Luk6655: here is how sample python module depending on some library looks
<muradm>normally if you want to make development on guix you will want to port your projection in some or another way
<muradm>and running "software compiled elsewhere" you may be right, it is not very guix'y thing
<Luk6655>perhaps if guix import worked with other indexes than pypi main site
<Luk6655>anyway, thanks for your help, I have to pop out
<muradm>good luck
<pkill9>i got icecat running with bublewrap woop, just needed to add /proc
<Luk6655>btw, is this limitation to run only stuff built for guix a feature of guix os? So if one uses guix on top of another os it doesn't exist, right?
<muradm>Luk6655: i suppose having guix running on other distro will allow you using two types of environments distro's and guix's, but i'm not sure how they are interoperating, i was always on guix
<Luk6655>I wonder how does guix's interpreter locate shared libs
<Luk6655>I suppose they are probably all located relative to the executable and those relative paths are hardcoded
<Luk6655>well, not really, because the example with ls mentioned before shows glibc is not in the same store lation as for example ls
<antipode>Luks6655: Binaries in Guix find their shared libraries the same way as in other ELF-based systems -- the interpreter isn't really modified except for not looking in /usr/lib and such.
<muradm>Luk6655: try not thinking about runtime much. guix is package manager, so most things happen on packaging stage. for instance "guix refresh -l mesa" will show and list dependents of mesa package, currently it is 1892 packages. so if you advance version of mesa, all packages have to rebuild with new mesa version.
<antipode>I.e., based on RUNPATH and RPATH (part of the ELF binary) and LD_LIBRARY_PATH and LD_PRELOAD (environment variables)
***Noisytoot_ is now known as Noisytoot
<antipode>The absolute file name of the directories of the dependencies .so is the RUNPATH (or RPATH, I always forget which one is used in Guix).
<Luk6655>antipode: interesting, if both can be used as you say (the interpreter is not patched) I can probably work with that
<Luk6655>muradm: I have to think of runtime, because I have lots of stuff that needs to run that I can't just leave and not use
<Luk6655>In time I might port it to guix
<antipode>I mean, it's patched a little, but it's not replaced by something else entirely.
<Luk6655>antipode: I mean if I set LD_LIBRARY_PATH to some folder, will it attempt to load a shared library from it?
<Luk6655>assuming that's the only location it's at?
<antipode>I think so, yes?
<Luk6655>that would solve my problem
<antipode>Didn't always work for me though, once I had to set or something like that (somehow LD_LIBRARY_PATH didn't work)
<Luk6655>as guix shell seems to create a folder with those libs I specify on guix shell some-package-containing-shared-libs and it exports it on PATH I can have a script that adds it to LD_LIBRARY_PATH and hopefully my python module will "just work"
<Luk6655>I forgot what LD_PRELOAD does
<Luk6655>I suspect it... preloads...
<Luk6655>muradm: I have a multiple boot system, I could just boot into another distro to use whatever doesn't work in guix.
<Luk6655>but then I would probably use it less and less, while there are some features in guix I think are very valuable
<muradm>Luk6655: switching to guix will require mindset/workflow update definetely
<pkill9>how do programs like icecat find out if they already have a running instance?
<pkill9>I'm trying to sandbox programs so I can run multiple instances side by side
<rekado>pkill9: is it enough to unshare the pid namespace?
<pkill9>apparently not
<pkill9>unless I've done it wrong
<pkill9>I also put a tmpfs in /run incase it was using dbus
<muradm>pkill9: you need to instances of icecat?
<muradm>pkill9: --new-instance?
<pkill9>oh interesting, that works, thanks, but I want to make it work via sandboxes so I can do it for all applications
<muradm>pkill9: normally i run all my browsers with "--private-window --new-instance" or similar, qutebrowser has -T flag also which creates temporary "profile" every time
<muradm>for icecat/firefox probably you may create profile for every application uusing --ProfileManager
<muradm>and then start them "icecat -P twitter --new-instance" assuming that you have created profile named "twitter"
<muradm>then theoretically, if using "icecat -P twitter --new-instance" and "icecat -P amazon --new-instance" you are kinda isolating between twitter and amazon
<muradm>but of course better isolation would be with container or VM
<muradm>and as far as i remember, you won't be able to start multiple --new-instance for same profile
<civodul>jpoiret: hi! am i right that hibernation isn't possible when swapping to a file that's on the root file system?
<civodul>(i'd like to have hibernation but i'd rather not type a passphrase once more :-))
<pkill9>wow I think I've figured it out, it's actually communicating via xorg server, or in my case xwayland
<pkill9>when I set MOZ_ENABLE_WAYLAND it doesn't open in the same instance
<pkill9>apparently the --no-remote option has some history dating back to Netscape
<pkill9>mystery solved
<pkill9>i think sandboxing would go great with guix as guix is all about keeping environments pure
<pkill9>this xkcd never ages
<pkill9>it only gets more and more relevant with time
<muradm>pkill9: +1
<jpoiret>civodul: iirc, you can't hibernate to a file or to encrypted file systems
<jpoiret>basically, we don't try to unlock anything before trying to resume
<Luk6655>wow, I'm pleased to report all it took to get my module working was to run python with LD_LIBRARY_PATH=$(echo $PATH | grep -Po '/gnu/store/[^\/]+')/lib
<civodul>jpoiret: by "we", you mean on the Guix side?
<civodul>or is there a fundamental limitation in Linux?
<jpoiret>on the guix side
<jpoiret>in gnu/build/linux-boot.scm
<jpoiret>it could totally be done
<civodul>ah but see
<civodul>doesn't that solve what you mention?
<jpoiret>tobias mentions what I'm also worried about here
<jpoiret>resuming is very dangerous if not handled correctly, you could lose a lot of data
<jpoiret>if you mistakenly mount a drive that was in use prior to hibernation, you *are* going to lose data
<jpoiret>see the docstring of resume-if-hibernated
<Luk6655>is there some way to specify in the manifest file for guix shell to run a script following environment setup?
<jpoiret>it's a recurring feature request though, you're not alone in asking for this :)
<rekado>Luk6655: setting LD_LIBRARY_PATH to such a large range of directories is probably not a good idea.
<Luk6655>perhaps it will at some time, I guess one can specify a command on guix shell command line
<Luk6655>rekado, it is set to **one** directory
<Luk6655>the one guix shell sets up
<rekado>oh, I see
<rekado>you can access the profile directory inside of guix shell with $GUIX_ENVIRONMENT
<Luk6655>I didn't know, that might be even better
<Luk6655>yes, it is the very same folder
***reyman_aw is now known as reyman
***reyman is now known as reyman_aw
<Luk6655>it appears there is something wrong with pip3's cache when used with guix shell python
<Luk6655>it tends to download stuff multiple times when installing to different venvs, normally despite venv pip uses a single cache folder in ~/.cache/pip
<Luk6655>stuff seems to be put in that folder, but rather than reuse it, pip downloads again
<Luk6655>is this by deign? pip3 cache info results in: ERROR: pip cache commands can not function since cache is disabled.
<Luk6655>well, it seems the cache dir is disabled by default in pretty much all python packages, I wonder what the reason for this might be? Still it can be re-enabled in user config.
<cbaines>Luk6655, typically you'd want to avoid using pip when using Guix, given you're loosing out if you're trying to mix and match package managers
<cbaines>but I'm not aware of why this pip caching wouldn't work, that's more of a python/pip question though
<nckx>civodul`: Linux can resume from ‘files’ in the sense that it can resume from arbitrary offsets within a block device. Normally this offset is that of a swap partition, but sure, somebody realised that if you were very careful to create an unfragmented(!) multi-GiB file and passed its offset to the kernel instead, that's equivalent. It works but it's fragile, and it requires more work (FIBMAP) from user space that we still don't do.
<nckx>This whole discussion has made me reconsider just moving to uswsusp already. I'd started, then stopped (because IMO uswsusp is sucky), but I should probably just bite the bullet.
<Luk6655>cbaines: yes, that's for sure, nevertheless sometimes one has to. It seems it was a concious decision to disable the cache as the specific setting is present in multiple python packages (python, python-xyz etc)
<nckx>At least get it far enough that I can benchmark both, and decide whether I'd ever use the user-space implementation myself. I hibernate *a lot*.
<Luk6655>so I wonder why? I can easily enable it, but maybe there is some problem I don;t know about
<cbaines>Luk6655, using pip in package definitions is completely different to what you're doing, right?
<vagrantc>Luk6655: does it only use ~/.cache/pip ... or does it also try to use a cache from /gnu/store/... which cannot work?
<cbaines>when building packages with pip, the caching isn't helpful, as it's all going to be thrown away at the end of the build
<nckx>jpoiret: I did something even more fun this week, which was resume from the same image twice. I'm pretty sure my ex-root file system passed the FIPS entropy test after that… :-/
<Luk6655>we're talking about two different things...
<Luk6655>I'm talking about using pip as a user to download and install python modules, there is no mention of using pip to build guix packages. I wasn't aware it can do such a thing? I know guix can import from pypi, but using pip to build on guix? Well,l that's interesting, but I meant packages that install **python** (pip comes as a module with python)
<Luk6655>those packages that deploy python, all seem to have an option to add it to pip's global config file to disable cache
<Luk6655>the cache lives in ~/.cache/pip
<Luk6655>and is a per user thing
<cbaines>Luk6655, where are you seeing the caching behaviour being disabled?
<Luk6655>just a sec
<cbaines>it seems to be enabled for me
<Luk6655>hmm, perhaps I interpreted it mistakenly
<Luk6655>I grepped for --no-cache-dir, but those files I now looked at in more detail appear to indeed use pip to build packages
<Luk6655>not build pip otself
<Luk6655>then I wonder why my global config had cache disabled
<cbaines>right, and that pip behaviour when packages are being built should be separate
<Luk6655>yes, agreed
<cbaines>where does this global config file live?
<Luk6655>I can only guess that maybe when this switch is used it sets it in global config?
<Luk6655>I'm not sure, let me check
<Luk6655>the per user config is in ~/.config/pip/pip.conf
<Luk6655>I'm not sure if there is any system wide config file, it might just refer to this as global
<cbaines>I'd perhaps just fix it this time, and then investigate further if the problem crops up again
<Luk6655>yes, that's what I'll do
<cbaines>I guess it's still technically possible that this is somehow Guix related, but I think it's highly unlikely
<Luk6655_>BTW did anyone get vscode working on guix os?
<podiki[m]>hi guix; working on my first service and it should create an account and then chown files/dirs with that account
<podiki[m]>however, seems like the activation function doesn't find the there something I should do that makes sure the account is created first? (I do extend account-service-type)
<podiki[m]>whoops, typo I think, nevermind
<johnjaye>question about the qcow image on the site. to run it should i use qemu-system-x86_64 -hda barebones.qcow2
<johnjaye>i did get the grub menu but i believe it goes to an error console. i may have to switch the virtual terminal in qemu manually, not sure
<Luk6655>I can answer my own question from earlier in case anyone else is interested. VSCode indeed runs on guix, but in de-microsoft'ed version called vscodium as a flatpak app. So it is not a guix package yet(probably due to it needing yarn for build time dependency resolution), but one can get it if required.
<rekado>Luk6655: indeed, the problem with VSCode is the vast amount of JavaScript that cannot be built from source with our methods.
<podiki[m]>same for electron apps like element
<podiki[m]>can I run something with system* as a specified user?
<Luk6655>I didn't know they generate js, interesting
<Luk6655>or do they compile js so it doesn't have to be interpreted on the fly>
<antipode>lilyp, civodul: I've sent my v3 documentation patch
<podiki[m]>or how to run something (in a service activation gexp) as a certain user?
***mark__ is now known as mjw
<podiki[m]>woohoo think I have a peroxide (protonmail bride) service working :)
<Luk6655>is there some file that can be backed up that contains packages installed with "guix install something" by a normal user? Just in case one wants to recreate their $HOME app-wise?
<podiki[m]>guix package --export-manifest
<podiki[m]>(and read about manifests in the manual and cookbook to see how you can recreate a whole system)
<pkill9>why can't guix build the vast amounts of javascript?
<podiki[m]>this is usually referenced:
<pkill9>so basically a combination of sheer number of dependencies,.and bundling various versions of other js packages multiple times within many js packages it seems
<pkill9>iirc it is also due to npm using binaries instead of sources, and circular dependencies
***Dynom_ is now known as Guest3074
<pkill9>using binaries for some packages atleast
<Reza[m]1>Hi, is it possible for a user (not in the wheel group) to check the shepherd services status?
<vivien>pkill9, and also someone who worked on the issue told me that there are a lot of nonfree software that gets bundled together with free software
<vivien>on npm
<Andronikos>PCSX2 (PS2 emulator) has the option to use bundled or system packages. If I create a package which option should I use?
<kajiya_>hey everyone - is this a good place to ask questions about chrony or is there a more appropriate channel?
<yewscion>Andronikos: IME the most canonical way seems to be system packages, as using bundled packages often means they aren't built from source. If it's possible to build and package each subpackage separately, then it might be okay. Otherwise, my $0.02 is go with system packages.
<podiki[m]>what's the difference between sudo -u someuser somecommand and in a service definition using make-forkexec-constructor with :user and :group? the first works for me, the second doesn't, I feel like it is a working directory or access issue
<podiki[m]>(each runs, but the first works in finding accounts which must be in some file I think)
<rekado>pkill9: ultimately it’s also a matter of mismatched cultures.
<rekado>what’s the point of adding literally thousands of JavaScript packages with descriptions and synopses, in numerous variants, where the source code is a fraction of the size of the Guix package definition…?
<rekado>and who will maintain this…? ain’t nobody got time for that.
<rekado>in practice this is what it looks like:
<rekado>that’s the few javascript dependencies of just one average package
<pkill9>i was thinking that yeh
<singpolyma>what could cause libpthread installed with guix to point at system libc?
<singpolyma> => /lib/x86_64-linux-gnu/ (0x00007f3802c0a000)
<rekado>the most obvious culprit would be LD_LIBRARY_PATH
<rekado>does the libpthread you installed contain references to the glibc from Guix?
<efraim>looks like r-rmarkdown builds without pandoc, but does actually need it
<pkill9>most of those appear to be the same basic structure though
<pkill9>i.e. disable tests, delete configure and build phases, use the synopsis as description
<rekado>just because that’s what the importer spat out
<rekado>none of this would be fit to add to Guix
<pkill9>maybe in a separate channel
<rekado>this *is* a separate channel ;)
<pkill9>so ther eis an npm importer and it does work?
<rekado>there are a few
<rekado>in previous discussions I cast my vote to merge one of them
<rekado>but the understanding is that whatever it *produces* would not be added to Guix
<pkill9>i agree
<pkill9>has anyone managed to build electron from source?
<pkill9>that's the final beast to tame
<pkill9>in js world
<podiki[m]>I imagine that will be very beastly, since it is an embedded chrome browser isn't it?
<podiki[m]>I figured out my service problem, it just needed to be restarted (to reload cache I think)
<Andronikos>yewscion: Thanks.
<podiki[m]>so....peroxide package and service I think all works now! will want some help to polish the ~45 go packages and the service definition though...
<Andronikos>Does somethimg like nvm and pyenv even make sense on Guix?
<klm>If I wanted to add Microsoft's memory allocator mimalloc, where should that package definition go? I only found talloc (which lives in samba) and jemalloc (which has its own jemalloc.scm) - neither quite fit for mimalloc.
<singpolyma>I thought I had got past it, but no. Just trying to `guix shell ruby -- bundle` in my ruby project on a foreign distro, getting: and similar
<singpolyma>something is looking at the system libc instead of the guix one
<podiki[m]>might need --pure ? or do a --check to see if some env variable is interfering somehow?
<rekado>Andronikos: the question has different answers and none of them can claim to be the only correct answer.
<rekado>singpolyma: I second podiki[m]’s suggestions. “guix shell --check” will tell you if there’s something obviously wrong about how environment variables are set; using “--pure” is a good idea to clear potentially bad env vars.
<rekado>I’ll add “guix shell --container” to the mix to hide the system’s glibc
<podiki[m]>yes, good idea on container when in a foreign distro especially
<ulfvonbelow>is python-scipy failing to build for anyone else?
<ulfvonbelow>the test_maxiter_worsening test is failing on my system
<ulfvonbelow>IIRC there were floating point issues with some tests on my cpu (amd kaveri) in the past with other packages
***justache- is now known as justache
<florhizome[m]>Andronikos yewscion i think other Distributions even do that and even go the step of devendoring
<florhizome[m]>automating devendoring is one thing that would help a lot with packaging I think
<rekado>it fails on i686-linux but builds fine on x86_64
<cyber-chris[m]>Is this in 1.3 or somewhere in development?
<cyber-chris[m]> * Anyone know if this patch is in 1.3 or somewhere in development:
<ulfvonbelow>so I've got a local clone of guix that I pull from, and I'd like to figure out how to make channel authentication work well with my local changes. The difficulty is that I often have to rebase, and I'm not sure how to shove all the upstream commits "in between" the (local-only, of course) commit that adds my gpg key to .guix-authorizations and the rest of the local commits