<pmikkelsen>While working on a build system for meson, I am experimenting with some different ways to keep the RPATH or RUNPATH after install, since meson by default deletes this. I have tried making a package called something like meson-for-build, where i patch out the part of meson that deletes the rpath of binaries. Would this be a good way to do stuff?
<efraim>i built monero, with 4GB ram, 4GB swap and 6 cores I ran out of memory, it took about 6 hours with --cores=2 but I didn't have memory issues
<efraim>would it be different if we packaged the last bundled lib and build it shared?
<pmikkelsen>sort of, I am not very good at reading python code ;) What I have right now just deletes the lines of code that triggers the deletion, but it is not enough, as the runpath from the build time is not always what we want
<civodul>efraim: on aarch64? it worked on my x86_64 laptop, with 16G of RAM though
<pmikkelsen>for example, if the lib and executable of a project is in the same source dir, the bin will have '$ORIGIN/:/other/paths...' in its runpath, while it should really have '$ORIGIN/../lib:....'
<civodul>i guess you'd need to install a bunch of gnome-* packages in your profile
<brendyn>well i have gnome installed with gnome-desktop-service, so i can launch that from the display manager
<jlicht>brendyn: if you figure this out, I would very much be interested in your system config file, as well as any other steps you had to undertake to make it all work
<brendyn>sure. i've had a lot of trouble with simple things on guixsd. guixsd does not seem to use .xinitrc so i am not sure how to run commands on login for my user, and set the keyboard layout for the login manager
<jlicht>brendyn: I recall people using exwm via .xsession
<elpogo>is there a talk(video) on guix that focuses on design decisions of the guix implementation and not on what functional package management is? every video i'm finding on youtube seems to assume that the audience needs to be educated about functional package management
<elpogo>i just want to quickly understand what the .drv files in /gnu/store are, etc
<davexunit>elpogo: I don't think so. there are papers on that subject, though.
<davexunit>most talks are given to an audience that doesn't know what guix is in an effort to raise awareness of the project
<elpogo>you must all be a bunch of academics (nothing against that). for some reason i can't get myself to read papers
<davexunit>thanks civodul, had forgotten about that section :)
<elpogo>civodul: last question. with gentoo, i could use the ebuild command to break down the various steps of the build process (fetching, extraction, patching, building, packaging and installing). is there a command to similarly to build a package step by step?
<elpogo>no real use case other than to understand how guix works.
<elpogo>i figured understanding the building blocks (like ebuild is to emerge) would help
<davexunit>most build systems have the notion of "phases", but the build daemon has no idea about those.
<elpogo>so if a build fails, and you want to hack/debug in an attempt to fix it, you have to start from scratch every time? there's no way to 'pause' after extraction of source and run the build command by hand?
<davexunit>I think learning about derivations in general will help
<davexunit>in the case of failure there is the --keep-failed flag
<elpogo>i'm running guix on a debian stretch machine on google cloud. my only goal is to understand it and determine if it makes sense to contribute to this project. no real need for it. my crappy laptop is best running debian since i can get binary packages
<sneek>efraim, ng0 says: many thanks for merging the Mate patches!
<davexunit>people sometimes compare us to gentoo but we really are quite different
<elpogo>i don't have the time to maintain a gentoo distribution anymore. as of now i'm using debian testing, but if i get comfortable with guix my goal is to switch to debian stable + guix for latest packages
<elpogo>do the prebuilt packages(mainly libc) have a minimum kernel version?
<elpogo>and if so, how often does that minimum kernel version get bumped up?
<civodul>elpogo: these days we're following what glibc decides, and for 2.26 that'll be 3.2
<elpogo>they probably don't nuke the old libc from hydra either. the people who haven't guix pulled can still get the old libc+dependent packages from hydra
<bavier>elpogo: we usually protect important "snapshots" from garbage collection on the build farms
<bavier>elpogo: and nginx will retain packages in its cache too
<elpogo>is there a 'lightweight' version of guix challenge where if you trust the person providing you the binary then you only check that the inputs are identical without actually doing the compilation?
<elpogo>that way you know that if you ever need to debug that binary, you have the identical inputs necessary to create that binary
<davexunit>elpogo: the inputs would have to be identical
<elpogo>bavier: if curl-7.54.0 is used an input for building something else, which files are considered as part of the input? just the files actually used (say /gnu/store/...curl-7.54.0/lib/libcurl.so) or is every file within /gnu/store/...curl-7.54.0/ considered as part of the input?
<bavier>elpogo: if a package declares curl as an input, all files under that curl's store directory is visible to the package during its build
<bavier>elpogo: for hash calculations, its the contents of curl's derivation that is used
<elpogo>do you get these kinds of questions in this channel often? or do most people just read the manual and so know this stuff? if anyone is thinking of doing a guix talk, please consider doing one on the implementation details!
<catonano>jlicht: though, I'm not sure it's a good idea. Now it's buildind coreutils. God nows how much stuuff it will have to build. Wouldn't just merge this patch of yours in core-updates and let the mules do the work ?
<marusich>Does anyone know offhand how to create file associations in GuixSD using GNOME? Does "the usual" way of doing it in GNOME work? (I'm unfamiliar with that method but can look it up) Or is it something special for GuixSD?
<marusich>I'd like to double click a PDF and have it open using Evince, but I'm unsure of how to make that happen in GuixSD.
<marusich>e.g. from the GNOME "Files" file browser.
<marusich>cbaines, that setting in GNOME did not work for me (there is no option for PDF files or documents in general), but what did work was to right click on a PDF file (in Nautilus), go to "Properties", select the "Open With" tab, and then select "Document Viewer" (evince) from the list of "Recommended Applications". It "magically" showed up there, presumably because I've installed Evince.
<marusich>I have no idea how Nautilus stores the information that it uses to remember what program it should use to open which file types, but I'm happy, so that's good. :)
<cbaines>marusich, ah, yeah, I don't see anything about documents/pdf's in the settings either