IRC channel logs
2016-08-11.log
back to list of logs
<balduin>lfam: thanks, but this does not really answer my question. MariaDB and MySQL are database server packages. Where is the client or connector? <balduin>in other distributions there is a package mysql-client and mysql-cli etc. <lfam>I don't know. Maybe it's the client and server end up in the same package <katco>i'm getting this most of the time, how do i troubleshoot? "guix refresh: error: connect: Network is unreachable" <jlicht>Is it possible, that setting -O3 -> -O0 in CFLAGS makes a bug dissappear? <katco>jlicht: i am assuming this is not in response to my question? <katco>jlicht: no worries at all. i just wanted to make sure i was not meant to respond :) <mark_weaver>paroneayea: thanks. I see there are new kernels 4.1.30 and 4.4.17. I wonder if they address this issue. <mark_weaver>paroneayea: I pushed the 4.1.30 update, but afaict, it doesn't include a fix for this <mark_weaver>although I must say, you shouldn't be expecting unencrypted TCP sessions to be secure anyway, so this doesn't strike me as critical. <mark_weaver>obviously I want to fix it as soon as possible, but speaking for myself, I'm not too worried about it. <mark_weaver>we already know that the NSA routinely hijacks TCP connections, and this fix won't change that. <mark_weaver>(things like remote execution vulnerabilities are what tend to send me into a panic :) <paroneayea>mark_weaver: I don't expect unencrypted TCP sessions to be secure, but I don't really want people who aren't even in the middle to be able to MiTM me :) <paroneayea>mark_weaver: I might look at backporting that patch tomorrow, but I doubt I'll have time :( <mark_weaver>balduin: the server and clients for mysql and mariadb end up in the same package on guix, afaik. <mark_weaver>in almost all cases in guix, everything that's built from a single source tarball or git checkout is a single package. sometimes that package has multiple outputs though. <habs>Hi all -- Sorry for length, but I seem to have majorly messed up my system to the point where all binaries will not run. It started with just X being not able to start with some libc error, so I upgraded glibc 2.22 to 2.23, and since then I get the error "segfault at 0 ip" when I try to execute any non-bash-builtin binaries from my user account (root seems to work ok though). I'd rather fix whatever's happening <habs>now than roll back and be stuck on an old glibc, but I'm at a loss for either considering I can't even start the guix binary from my user account. What should I do to debug / fix this? <habs>To clarify, this is GuixSD x86_64 on an X200, relatively up to date. I can't think of anything specifically I could have done recently to cause this <mark_weaver>habs: what guix operation did you perform just before things became broken? or did the system first become unusable after rebooting? <mark_weaver>and then run "guix gc --verify=contents" to check for corruption of store items <ooxi>davexunit thanks for the paste! <ooxi>wow that's already changed for violetland <ooxi>I'll play around and surly will release a guix package :) <phant0mas>hey mark_weaver, I sent an updated patch to the list about the daemon about the CHROOT_ENABLED macro <phant0mas>I broke the macro into smaller ones as you suggested <phant0mas>the defined(CLONES_NEWNS) doesn't need to be included in CHROOT_ENABLED <phant0mas>because in non linux systems, it uses fork() <phant0mas>and I also prefer to define pivot_root() only if defined(SYS_pivot_root) does not fail <phant0mas>btw I have written a wrapper inside the daemon which replaces mount() and umount2() calls with nixMount() and nixUmount2() <phant0mas>and uses my libhurdutil library on the Hurd in order to offer mount() and MS_BIND <phant0mas>the only problem I still have is how to handle pivot_root on Hurd <janneke>hey phant0mas, finally rebased mingw patch set on master now ready to apply! <mark_weaver>phant0mas: excellent, thanks! I'll review it soon, but not now. <mark_weaver>janneke: thanks for working on it. I consider this mingw work to be very important. <mark_weaver>I'm sorry I haven't paid it the attention it deserves until now, but I hope to soon find the time intend to review it and get it merged soon. <mark_weaver>I hope to soon find the time to review it and get it merged. <janneke>ACTION finally picks-up the lilypond-guile-2.0 mingw stack <janneke>mark_weaver: some thingks work, there are problems <janneke>with guix i hope to remove any build/configuration issues that people may have that stand in the way of fixing lilypond-guile-2 <janneke>yes, esp. if you need a patched guile-2.0, want to try guile-2.2, and want to run lilypond which uses guile-1.8...and want to work together on that... <janneke>guix should be able to make that much easier <janneke>sneek: later tell civodul: with latest mcron, last night rottlog rotated /var/log/messages for me <efraim>you use mcron with 'crontab -e' or with some shepherd services? <ng0>news on the git-service: it's almost functional. *almost* as i need to debug the respawning on startup <janneke>efraim: i'm using it as a shepherd service <janneke>and a patch for rottlog, not 100% sure if all of that patch is needed <ng0>searching for a smaller socks library or any socks library/client which isn't haskell bsaed, i found dante. however the license is strange. debian includes Dante, so i assume it is okay for us? can someone look at the here included LICENSE file? http://www.inet.no/dante/files/dante-1.4.1.tar.gz <ng0>Developed by Inferno Nettverk A/S, Dante is released under a BSD/CMU-type license and comes with complete source code. quote from the website <ng0>maybe they changed the license, the fsf dir says gpl <rekado>bavier: I heard of qupzilla only from the EOMA68 demo video. Too bad it depends on this mess :( <rekado>(and that abucodonosor person is really unfriendly.) <mark_weaver>ng0: I checked one of the source files in dante, and found a BSD-style advertising clause, which is rather onerous: "All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by Inferno Nettverk A/S, Norway." <ng0>onerous? what does that mean? <mark_weaver>it may qualify as free software, but we should probably avoid it if possible. <ng0>okay. the last line of the license made me ask.. as they want changes to be contributed back and licensed to them <ng0>i'll look into the other socks' i found. <ng0>which usual? searching for socks only gave me "ghc-socks" in guix and one other <ng0>and i want to avoid haskell <mark_weaver>I definitely want to avoid ghc as a dependency on anything, since it doesn't support armhf or mips64el, and it also requires ghc which cannot be built from source code without first downloading a ghc binary. <ng0>this socks lib i need, optimal case socks4 + 5, is for building socks support into ircii <ng0>there are hundreds of socks libs out there, so i keep searching <ng0>can torsocks address more than just tor? I never used it for anything else <ng0>there's sockchains or what's it called, but i'm not sure what it does, used it 6 months ago <ng0>but that's just for linking socks and other proxies in a chain, no lib <mark_weaver>can ircii really work with so many different socks libraries? do these libraries all have the same API? <mark_weaver>debian's ircii doesn't seem to be linked with any socks library <ng0>currently it's built without any socks support <ng0>i don't know when socks was implemented, but i can ask someone who was involved in ircii in the 90s <mark_weaver>torsocks apparently doesn't need to be linked to programs that use it. it apparently uses LD_PRELOAD to hook in. <ng0>i found 2 socks libs i want to package, also small <mark_weaver>torsocks seems to be what the tor project recommends, which I take as a good sign. they tend to perform security audits of the software they recommend <mark_weaver>and I don't see any indication that it's specific to tor, despite the name. <ng0>there's tsocks and shadowsocks-libev <ng0>i'll take a look at how ircii is configured for socks <ng0>ircii needs to be linked to socks. otherwise it will look in its own dir for socks lib, at least from the README <ng0>i'll give it a try with torsocks, see if it gets me anywhere <mark_weaver>why does ircii need to be linked to socks? torsocks is supposed to be able to transparently SOCKSify programs. have you tried this? <ng0>read the README of ircii. <ng0>i don't know. maybe i'll just leave it for now <ng0>i don't torify irc clients as there's hardly any tor irc server left.. for psyc i repair the native psyc client and currently use a telnet client which has no problems to be torified. <ng0>i just thought if there's a socks option it would be good to build it <ng0>i'll give it a try with `torsocks irc`, although my current torsocks is a prerelease version which is broken. <mark_weaver>ng0: btw, I checked the source code of ircii, and it seems to want a specific socks library, namely the one provided by the "libsocks4" debian package. dante has a different library name, and would not be accepted by ircii afaict. <mark_weaver>this is not a case where you can just shop around for another socks library and have it work with ircii. <mark_weaver>(and there are very few cases like that, in practice) <mark_weaver>ng0: btw, I checked the source code of ircii, and it seems to want a specific socks library, namely the one provided by the "libsocks4" debian package. dante has a different library name, and would not be accepted by ircii afaict. <ng0>yes, .onion names get resolved with `torsocks irc` <mark_weaver>this is not a case where you can just shop around for another socks library and have it work with ircii. <ng0>so no need to build socks in <mark_weaver>(and there are very few cases like that, in practice) <ng0>i thought socks libs are all equal, at least ones written in C like shadowsocks-libev <ng0>works for me, so i won't fix this. <ng0>i should remove the todo note from ircii next time i make a change in irc.scm <ng0>thanks for looking into it :) <ng0>i think i'm just distracting myself from writing services.. i have many packages to port from gentoo to guix on my list, but services are what i need to learn. <ng0>my plan is to retire most of what I maintain in gentoo, and make my work to just maintain the 6 applications which are not in portage. <habs>mark_weaver: Thanks for the help. guix system list-generations seems to show only one generation, though guix package --roll-back said that I was on gen 3. Even if I rolled back to 1 that way, every binary not in /run/setuid-programs still segfaults for me. I ran guix gc --verify=contents and it did show three hashes modified, but they were only for dosbox and sdl so don't think they were causing the problem <mark_weaver>habs: "guix package --roll-back" rolls back the current user's profile, which is distinct from the system-wide profiles listed by "guix system list-generations" <ng0>we can not include software which states on its website that it is public domain, it has to be in the source code or a license file, correct? I wanted to include this (http://c9x.me/irc/) and messaged the developer about it <mark_weaver>yes, the source tarball itself must clearly state the license of the code within. <ng0>okay, I'll have to wait on their reply then <mark_weaver>the copyright notice and copying permission notice really belongs in the source files themselves. <mark_weaver>but if the README clearly states that all of the code within is under a given license, that should be sufficient. <ng0>the source has no copyright at the moment, i pointed this out to them <ng0>*no coyprigfht statement <mark_weaver>right, and the default in many (most?) jurisdictions is that we have no rights at all to copy. <catern>hey, how well does guix run when it doesn't have access to the open internet? say, when it is inside a corporate firewall and can only access the web through a proxy? how well can access to a local substitutes mirror replace access to the open internet? <ng0>it should honor proxy settings as far as i read the mailing list <catern>what I mean is more - I should be able to put everything guix would normally download from the internet, onto a substitutes server, and then use guix normally, right? <catern>without guix accessing the internet? <catern>(the internet is a scary place, you see...) <rekado>catern: proxying should work, but anticipating any web access can be difficult. <ng0>how are pypi-uris to be constructed? (pypi-uri "stem" version) would work out? <ng0>the importer gave a different one <catern>rekado: oh? how is it difficult? <catern>the only reason guix would access the internet is to download source or substitutes, right? <rekado>catern: you would not only need to have tarballs cached but also substitution artifacts <catern>and source can be provided as substitutes? <catern>ACTION googles "substitution artifacts" <catern>sure, isn't caching binaries the normal thing to do with substitutes? <rekado>ng0: I think (pypi-uri "stem" version) should be fine. What did the importer spit out? <rekado>catern: hydra does this after building out these many variants. <rekado>but there can be a lot of substitutes. <ng0>well without the md5= <rekado>ng0: or rather the old new format :) <catern>rekado: just to be clear - we're just talking about source code and built binaries here, right? <rekado>ng0: I thought someone had already updated the importer to use ‘pypi-uri’ again. Guess I was wrong. <catern>that doesn't seem like it would be too much - and there's part of a proof of concept in the hydra substitute server... <rekado>ng0: we should be using the shorter expression. <catern>are you concerned about space consumption to provide substitutes for all the source tarballs? <rekado>catern: I’d be concerned with keeping things in sync. <rekado>catern: there’s a different set of substitutes needed for a different version of the Guix repo. <rekado>(of course there’s some overlap) <rekado>catern: do you plan on having a single shared store and a single daemon? <ng0>ah.. that's because it looks for targz <ng0>when it has to be tar bz2 <catern>that's a fair point, so you'd need the union of old and new versions' substitutes every time you upgrade <rekado>ng0: I seem to remember that you can pass a file ending to pypi-uri to override the default. <rekado>ng0: there should be at least one instance somewhere in the repo. <rekado>catern: another way is to let your servers build out everything from source and populate a central store. <rekado>catern: then the store is the cache. <ng0> (uri (pypi-uri "pytz" version ".tar.bz2")) <rekado>catern: in that case you’d only need archived tarballs. (And lots of time.) <catern>rekado: and serve that store over nfs or something you mean? <rekado>catern: that’s what I’m doing here at work. The store sits on an NFS share and the single daemon on a management server handles writes. <rekado>all workstations and servers mount the store like any other shared drive. <rekado>users manipulate their profiles through a wrapper that talks to the daemon via SSH <catern>rekado: hmm, that might be an option or might not be <catern>but, if my servers build everything out from source and populate a single store, wouldn't it be fine then to just guix publish the resulting store? <rekado>catern: that would work, too, actually. <rekado>but then you need to be sure that everybody uses the same version of Guix. <rekado>otherwise they would request binaries that your server cannot provide. <rekado>and then they would end up building things from source. <catern>(and be unable to actually fetch the source) <rekado>(and without Internet access that's difficult.) <catern>but I can control what version of guix is being used, yeah <catern>and before doing an update, I'll update the servers first <catern>so they can build everything out <rekado>yes, this might work. I do something similar. <rekado>people here can have their own version of Guix (I think it's only two users here, and one of them is me), but most use the centrally managed version. <rekado>after each upgrade I fill the cache/store by "guix build"-ing common packages. <phant0mas>hey janneke nice job, I will check it out when I have time :-/ <phant0mas>damn my internet provider, the network was out since 2pm <bavier>I've been without internet at my home for 3 weeks now, due to incompetent provider <jlicht>is that normal where you guys live, bavier, phant0mas? <bavier>jlicht: not usually where I'm from. <bavier>in this case its an issue of the ISP rolling out fiber access and not having enough technicians to do timely "installations" <phant0mas>jlicht: no it's not usual here either, it's just that it's high tourist season, malfunctions happen and not enough tenchnicians to fix everything on time <ng0>hi, is someone reviewing my st to terminals.scm move and all the patches afterwards related to suckless? <rekado>davexunit: "we" means "LWN subscribers"? <rekado>ng0: I remember seeing emails that were critical of getting rid of the suckless module. I don't know what the latest status is here. <rekado>I think one point that was raised was that there is no good home for "dmenu", one of the last remaining residents of the suckless module. <ng0>there was someone who wanted copyrights to be included, i sent a nameless subject patch to address that <ng0>as copyorghts have been ignored in past moves too <ng0>afaik i moved dmenu to wm.scm <bavier>yeah, we should be more careful about copyrights in package moves <ng0>equal behavior in the past made me assume that a separate patch is okay, but for future patches, we should adjust documentation + be more careful <ng0>As long as this is not patched, I'll do the update for st to 0.7 <ng0>wa swreleased this hour <ng0>at least i stopped the respawing error <rekado>ng0: indeed, understanding services (and keeping the concept of the service graph separate from mere shepherd services) took me quite some time <ng0>st update is sent out <ng0>notmuch update is cool.. scrolling long searches is much faster now <ng0>in the emacs interface i mean <ng0>damn. i did the st update patch before the official release email was out <myglc2>So... when I installed perl guix told me I might need export PERL5LIB="blahblahblah" Does that mean I need to put it in my bash profile? <rekado>myglc2: you could just run "source /path/to/profile/etc/profile" and do that in ~/.bash_profile <rekado>the etc/profile file will always contain (almost) all variables you need to use the software in a profile <myglc2>rekado: Thanks. So is this advice provided to say what one needs to do to immedately use the package, but will typically not be needed after a restart? <jlicht>although automatically sourcing /path/to/profile/etc/profile sometimes breaks my (ubuntu-installed) X session when I have a certain GTK variable defintion in the profile <myglc2>jlicht: thanks, good to know, but isn't that probably a bug? <jlicht>myglc2: hmm could be. I thought it was just a logical result of my frankenstein ubuntu14.04 based system + guix <jlicht>thank $DEITY for `guix package --roll-back` ;) <myglc2>I want to write a make file and requires perl which I don't normally use. Is there a slick way to have Guix load up perl just for the purposes of my makefile? <jlicht>`guix environment --ad-hoc perl -- make`? <jlicht>basically, have guix install perl in an environment that doesn't influence anything outside it, and invoke make <myglc2>jlicht: Is there a way to put that inside the makefile? <jlicht>you could prefix the perl part in your makefile with the guix environment invocation. <jlicht>so instead of a line saying `your-perl-related-command`, have it be `guix environment --ad-hoc perl -- your-perl-related-command` <myglc2>Cool. Done this way do you think the PERL5LIB="blahblahblah" I asked about earlier need to be on that line too? <myglc2>jlict: Many thanks, I'll try it and see. <mark_weaver>(it will return with more RAM for better performance) <myglc2>jlicht: oops, sorry & expecting a makefile to be outside the box. <ng0>the new server is done? <jlicht>myglc2: what do you mean with 'makefile to be outside the box'? <mark_weaver>no, it's the same server, but with double the disk space and 1G more RAM. <myglc2>jlicht: bad typing... I meant to say expecting a makefile to be good looking might be outside the box ;-) <myglc2>mark_weaver: do you know if they got the RAID drives working? <myglc2>mark_weaver: cool, I am still trying to get my servers RAIDed w/Guix. Do you know if I could get a copy of the config somehow? <myglc2>Hi Guix... I'm back... just rediscovered how emacs server crashes when emacsclient disconnects <mark_weaver>myglc2: due to limitations in gtk+, emacs based on gtk+ cannot survive disconnecting from an X display. if it's important to avoid that, try 'emacs-no-x-toolkit'. this is the main motivation behind that package. <mark_weaver>or maybe it's that it cannot survive the X server going away. I've forgotten the details. <mark_weaver>myglc2: regarding the OS config: I'm not directly involved with installation of the machine, and the people who've been working on it (mainly Andreas) are on vacation afaik. <myglc2>mark_weaver: I didn't mean to imply it's a Guix problem, thanks for the no toolkit tip, I'll try it. <myglc2>mark_weaver: Thanks, I will ask Andreas for the config when he is back. <myglc2>mark_weaver: I know it is a long standing GTK problem. R doesn't handle X connection loss either. Could this be trickle-down from when the DEC/IBM geeks that invented X Window at MIT in 1978 on DECstations and IBM servers getting client and server backwards? ;-) <mark_weaver>ACTION has a feeling there's a joke involved, but he's sometimes a bit humor-impaired <myglc2>mark_weaver: yep, I'm just saying many of X's issue result from the early decision to make the display+mouse+keyboard be the server <mark_weaver>I'm not sure how it would work the other way, but maybe I haven't thought about it enough :) <myglc2>Well VNC is an example. & wouldn't the whole problem with xauth spoofing go away if the display is a client? <mark_weaver>VNC is an unusual case. how would it work for things like web browsers and terminal programs? <mark_weaver>how would the display know how and when to connect to programs? <mark_weaver>and what would be the process, from the user's perspective, for starting up a new graphical program? <myglc2>mark_weaver: Well using a desktop machine as the window manager for multiple web browsers seems to work pretty well. <myglc2>mark_weaver: Ok I tried 'emacs-no-x-toolkit' and it fixes the problem, YEAH! And so painless using GuixSD ;-) <myglc2>mark_weaver: ... And it isn't missing icons and spewing messages like the gtk+ version either. <jlicht>myglc2: which command did you invoke <myglc2>mark_weaver: Thanks again. I tested it in a VM, but now I got to restart the emacs mothership so bye bye Guix ;-) <jlicht>myglc2: did you just install the emacs-no-x-toolkit package into your profile? <mark_weaver>"guix package -r emacs -i emacs-no-x-toolkit" would be one way to do it <myglc2>jlicht: Well, Its a bit complicated. I just got vm-images working on the headless server I use, so I spun up a VM and installed it there with 'guix package -i emacs-no-x-toolkit' to test it. Then I did 'guix package -i emacs-no-x-toolkit' and restarted emacs. <myglc2>I actually also have emacs installed in the system config, so the gtk version is still installed system wide. <myglc2>mark_weaver: Hmm I lied. I actually edited g1.scm did 'guix package -m g1.scm' <mark_weaver>specifying your profile manifest as a .scm is the superior approach, IMO. <myglc2>mark_weaver: I easily lose track of where I am so I like the manifest. <myglc2>I am just starting to appreciate all the cool 'M-x Guix-installed-packages' features which make an adhoc approach pretty inviting too. <jlicht>I like that guix, very much like emacs, offers easy ad-hoc ways of making use of the features you want. <jlicht>With the same drawback as well that you once you start, there is no turning back ;) <myglc2>jlicht: The primary issue with emacs is getting the first drink from the fire hose. Guix/SD is much the same. <myglc2>OK now back to my guix environment perl in a make file ;-) <jlicht>yeah, the 'where do I even start' feeling you get when start researching. <myglc2>jlicht: I installed Nix and Guix in January & I have spent ~ 50% of my time studying/using Guix/GuixSD since. Kind of mind bending. <jlicht>myglc2: maybe there should be disclaimer on the guix website. Or one of those 'Before - After' ads. <efraim>it looks like obs can't be built for armhf, armhf's gcc:lib doesn't have lib/gcc/arm-unknown-linux-gnueabihf/4.9.3/include/xmmintrin.h <bavier>efraim: obs probably shouldn't be #include'ing xmmintrin on non-x86 <efraim>however, our armhf clang does have xmmintrin.h <jlicht>sneek: later tell lfam: thanks for reacting so quickly to the jq fix :) <davexunit>looks like I can take advantage of this to make relocatable binaries with guix <janneke>davexunit: that's what GUB does for relocatable lilypond binaries; not sure how to use this with guix though <bavier>$ORIGIN/../../../.. pointing to $storedir e.g.? <davexunit>bavier: pointing to a directory relative to the executable <davexunit>my plan is to build all of the shared libraries I need such that they don't hardcode store references <davexunit>so I can use guix as the wonderful build system that it is, but produce a relocatable binary tarball of my software <davexunit>sdl2, a bunch of image and audio libraries, bleh. <bavier>you could use ld-wrapper to rewrite rpath flags <davexunit>so if I could make a variant of the gnu build system that uses my special ld-wrapper, I think I could get something to work. <mark_weaver>davexunit: it would probably be sufficient to just add your ld-wrapper as a native-input <mark_weaver>explicitly specified inputs should take precedence over the implicit ones, iiuc <davexunit>in fact, I might not need ld-wrapper, regular ld might do just fine. <davexunit>such that the libraries don't have any runpath, and I can use a wrapper script to set LD_LIBRARY_PATH or whatever <mark_weaver>LD_LIBRARY_PATH might take precedence over rpaths, so you might not need to avoid ld-wrapper <bavier>some packages specify their own -Wl,-rpath flags <jlicht>davexunit: is the end-game here to build binaries using guix, but have them be usable outside of guix? <davexunit>bavier: I need to make package variants anyway <davexunit>for every library that I want to include in my bundle <davexunit>sdl2, sdl2_image, sdl2_ttf, sdl2_mixer and all of libraries they link against. <bavier>sure, but with a modified ld-wrapper you might not need to specialize any packages, and it has the command-line parsing and library path handling machinery already <davexunit>bavier: I have to specialize them all to at least use the new ld-wrapper <bavier>yeah, that can be done with a package-with-python2-esque function <davexunit>the validate-runpath phase might get in my way <davexunit>but again, a function can strip that phase out. <bavier>hmmm, come to think of it, using $ORIGIN might be useful as the default <bavier>we could serve substitutes regardless of the choice of storedir <bavier>maybe not completely, I guess there are other less-flexible places where the storedir is embedded <davexunit>normally the hardcoded store dirs are a very good thing. <bavier>davexunit: I'm thinking of just the "/gnu/store" part <davexunit>my head is spinning just trying to figure out my little problem :) <davexunit>hmm, adding binutils as a native input causes the configure script to crash <mark_weaver>one complication to using $ORIGIN is that you need to know, when linking a program, where it will be installed, or at least how many "../" components are needed to get back to /gnu/sstore from its installation directory <davexunit>configure: error: cannot run C compiled programs. <mark_weaver>also, even if we could solve that problem, that would only solve the issue of where to find shared libraries. it would not help to locate other files <mark_weaver>so I don't see a complete solution around this to enable a relocatable /gnu/store <mark_weaver>davexunit: that's because without the rpaths added by ld-wrapper, ./configure cannot run the test program. <davexunit>maybe I can use GUIX_LD_WRAPPER_DISABLE_RPATH <mark_weaver>it's not everything you would hope for, but one option would be to build with a longer storedir, and then provide a convenient way for users to graft that storedir into any desired storedir with length <= the one you compiled in. (redundant slashes can be used for shorter ones) <mark_weaver>this has the benefit that it can handle all cases uniformly <mark_weaver>anything nicer will require special handling for different pieces of software, e.g. patching them to consult environment variables to find what they need, etc. <mark_weaver>a really ugly hack would be to use LD_PRELOAD to wrap filesystem-related functions in libc to recognize storedir at the beginning of filenames and do the needed substitution at run-time. <mark_weaver>and you could compile for a storedir that would be highly unlikely to be found in the wild. <mark_weaver>I don't see any magic bullet here. the practice of looking for things in hardcoded paths is quite widely ingrained in the POSIX world. <davexunit>set GUIX_LD_WRAPPER_DISABLE_RPATH after the configure phase <mark_weaver>davexunit: have you checked if LD_LIBRARY_PATH overrides rpaths? if so, disabling rpaths is pointless <davexunit>mark_weaver: no, I haven't. that's a good point. <davexunit>haven't tested, but a quick search makes it seem that way <davexunit>so really I just need to bundle all of the libs I already have and set LD_LIBRARY_PATH <mark_weaver>now that just leaves all the *other* hardcoded paths :) <davexunit>figuring out C libraries will solve most of the problem <mark_weaver>every executable contains a hardcoded path to the dynamic linker <davexunit>hopefully that won't be toooo bad to deal with. <davexunit>I need to figure out how to fix the locale issues with my static guile 2.1 first <davexunit>when I run it in an isolated container it segfaults after saying that it couldn't convert a narrow string <davexunit>because it has no access to it's precious hardcoded libc <davexunit>I guess that's what ludo's utf8 patch handled, but it doesn't apply to 2.1. <davexunit>yes which is why I'm seeking alternate solutions :)