IRC channel logs


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?
<jlicht>katco: sorry, it is not ;)
<katco>jlicht: no worries at all. i just wanted to make sure i was not meant to respond :)
<paroneayea>oh shit
<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>I'll take care of those updates
<paroneayea>mark_weaver: thank you :)
<mark_weaver>paroneayea: I pushed the 4.1.30 update, but afaict, it doesn't include a fix for this
<mark_weaver>linux-libre-4.4.17 isn't there yet
<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>even on an unsecured connection!
<mark_weaver>agreed :)
<paroneayea>mark_weaver: I might look at backporting that patch tomorrow, but I doubt I'll have time :(
<mark_weaver>I'll keep an eye out for kernel updates
<paroneayea>ok, going to go back to reading.
<mark_weaver>okay, enjoy!
<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>it sounds like you should start by rolling back
<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>so one can know what is going wrong
<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>bah, edit fail
<mark_weaver>I hope to soon find the time to review it and get it merged.
<janneke>np, thanks!
<janneke>ACTION finally picks-up the lilypond-guile-2.0 mingw stack
<mark_weaver>does lilypond work with guile-2.0 now?
<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
<mark_weaver>janneke: that would be very useful!
<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
<sneek>Got it.
<janneke>sneek: botsnack
<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?
<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
<mark_weaver>I'd prefer to avoid this library
<ng0>i'll look into the other socks' i found.
<mark_weaver>what's wrong with the usual socks library?
<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.
<mark_weaver>what about torsocks?
<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
<mark_weaver>ng0: would 'torsocks' work for this?
<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>I don't recall another case along these lines
<ng0>i don't know
<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
<ng0>*socks support
<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
<mark_weaver>according to <>, "it seems as though tsocks is obsolete and torsocks is its replacement", and I've gotten that impression elsewhere also, although I don't remember where else I saw that.
<ng0>ah, right
<mark_weaver>what problem are you trying to solve?
<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
<mark_weaver> also indicates that torsocks is better than tsocks, fwiw.
<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>ghc-socks would certainly not work for ircii.
<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>ghc-socks would certainly not work for ircii.
<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 :)
<mark_weaver>thanks for your contributions
<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.
<mark_weaver>heh :)
<mark_weaver>sounds like a good plan!
<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 ( 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.
<efraim>sortmerna won't find zlib on arm or mips
<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"
<rekado>catern: I mean ‘binaries’ :)
<catern>oh :)
<rekado>language is hard.
<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: yuck.
<rekado>ng0: that’s the old format.
<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>catern: yes.
<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.
<ng0>ERROR: download failed "" 404 "Not Found"
<catern>are you concerned about space consumption to provide substitutes for all the source tarballs?
<ng0>for the new format
<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"))
<ng0>^ yep
<rekado>catern: in that case you’d only need archived tarballs. (And lots of time.)
<rekado>ng0: yup, that’s it.
<rekado>ACTION goes afk for a while
<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>read only.
<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>to an extent anyway
<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.
<jlicht>hello guix!
<phant0mas>hey janneke nice job, I will check it out when I have time :-/
<phant0mas>mark_weaver: ok, take your 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?
<jlicht>phant0mas: *
<bavier>jlicht: not usually where I'm from.
<jlicht>and *people.
<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
<davexunit>for LWN subscribers, we've got a big feature this week
<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"?
<davexunit>rekado: we as in Guix! :)
<rekado>oh, interesting
<davexunit>a very nice summary of the 0.11 release
<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> this
<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>*not commited
<ng0>services are hard.
<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
<ng0>i have to change it
<myglc2>... Yo Guix!
<myglc2>Hello jlicht!
<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?
<janneke>phant0mas: thanks!
<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
<myglc2>jlicht: oh well then :-0
<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?
<myglc2>* file that requires *
<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>It might just look horrible ;P
<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>hydra will be down for a few minutes
<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>that would be great news
<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 ;-)
<mark_weaver>the new server is still a work-in-progress
<myglc2>mark_weaver: do you know if they got the RAID drives working?
<mark_weaver>yes, they did
<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?
<jamesrichardson>Is there a java jre package for guix?
<jamesrichardson>oh I found icedtea.
<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.
<mark_weaver>hydra is back up now...
<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.
<mark_weaver>regarding the emacs/gtk+ daemon, see:
<mark_weaver>*daemon issue
<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? ;-)
<myglc2>getting -> got
<mark_weaver>hmm? I'm not sure I follow.
<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.
<mark_weaver>yay :)
<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 ;-)
<myglc2>jlicht: invoke for what?
<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>oh, that's even better@
<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
<paroneayea>jlicht: ha
<jlicht>paroneayea: ?
<paroneayea>jlicht: the before-after joke
<bavier>efraim: obs probably shouldn't be #include'ing xmmintrin on non-x86
<efraim>bavier: agreed
<efraim>however, our armhf clang does have xmmintrin.h
<jlicht>sneek: later tell lfam: thanks for reacting so quickly to the jq fix :)
<davexunit>ACTION reads about the $ORIGIN variable for rpaths
<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
<bavier>davexunit: right
<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>but I need a bunch of libraries...
<davexunit>sdl2, a bunch of image and audio libraries, bleh.
<bavier>that'd be cool
<bavier>you could use ld-wrapper to rewrite rpath flags
<davexunit>I need to learn to use that
<davexunit>but that seems like what I want
<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
<davexunit>mark_weaver: yeah, that's true.
<mark_weaver>explicitly specified inputs should take precedence over the implicit ones, iiuc
<mark_weaver>this is certainly relied upon in several places
<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?
<mark_weaver>I'm not sure off hand
<davexunit>jlicht: yes
<davexunit>bavier: I need to make package variants anyway
<davexunit>for every library that I want to include in my bundle
<davexunit>which is over a dozen currently
<davexunit>sdl2, sdl2_image, sdl2_ttf, sdl2_mixer and all of libraries they link against.
<davexunit>libpng, libjpeg, libvorbis, truetype, etc.
<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
<davexunit>which is easy enough.
<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>not sure how it would work
<davexunit>my head is spinning just trying to figure out my little problem :)
<bavier>heh, yeah
<bavier>I'll think about it some more
<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>I don't know how we could do that automatically
<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.
<mark_weaver>because the shared libraries can't be found
<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>I might be onto something...
<davexunit>set GUIX_LD_WRAPPER_DISABLE_RPATH after the configure phase
<davexunit>and skip runpath validation
<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>it seems that it does
<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>which is luckily not much
<davexunit>figuring out C libraries will solve most of the problem
<davexunit>having a static guile helps too
<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>so I need to try to rebase it if possible
<mark_weaver>that will likely be a bit of work
<davexunit>yes which is why I'm seeking alternate solutions :)
<davexunit>enough hacking on this for one day
<davexunit>thanks for the help everyone
<bavier>davexunit: good luck
<Petter>Good talk Dave!