<lfam>paroneayea: I'm on the east coast <lfam>I can't believe there's no Guix hackers in California! <paroneayea>surely someone is in the heart of the tech production "industry" ;) <lfam>I don't think I can go to California so soon after going to FOSDEM, because of $$$, even though I've had a Pacific Coast tour on my wishlist for years <lfam>Yeah, probably. That's a lot easier for me because I can just take a bus and stay with friends or family <civodul>so we need to recruit hackers on the West coast <davexunit>lfam: oh cool! will be nice to see you at LP <lfam>We should go to my favorite restaurant ~nearby, Underbones :) <davexunit>paroneayea: hmm pasadena... I could stay with some friends of mine out there. <davexunit>but I have heard of Redbones. love that place. <lfam>It's a delicious BBQ + beer spot in Somerville <lfam>It's in the basement of Redbones <lfam>I like basements better :) <davexunit>one of my cars still has a somerville parking pass, too ;) <paroneayea>davexunit: would you want to submit a proposal to talk? <davexunit>would need to see how my fiance feels and if my friends would be willing to host me, etc. <paroneayea>davexunit: cool, let me know after you've done some thinking :) ***Apteryx is now known as Guest4981
***orbea is now known as Guest77528
***orbea_ is now known as orbea
<vtomole> lfam: I'm still getting "can't install grub on sda" for qemu ***Guest4981 is now known as Apteryx
***Apteryx is now known as Guest44211
<Apteryx_>I've found a bug with our Python where the "user site package" appears following the "site package", which causes the behavior of "pip install --user" behavior to be slightly broken (there's no user override possibily over system installed libraries). <Apteryx_>I'm trying to understand where/how this discrepancy compared to usual Python comes to life; I know that the problem is caused by "sys.path" (PYTHONPATH) containing the "site package" locations before even running the main() of site.py. <Apteryx_>I've reviewed the patches we apply to Python3, and there doesn't seem to be anything problematic done there... <Apteryx_>By the way, how can I try python in an environment? Do I absolutely need to use "python-wrapper"? The binary doesn't seem to be in my path otherwise? <rekado>Apteryx_: the “python” package for Python 3 only comes with versioned binaries. <rekado>“python-wrapper” provides the “python” executable for Python 3. <rekado>traditionally, only the executable for Python 2.x was called “python” <Apteryx_>rekado: I try: "guix environment --pure python", then "python3" and it says "command not found". I'm puzzled; I thought I had this working earlier. <Apteryx_>I see. So I must always install "python-wrapper", and then call python3 <Apteryx_>Is there any reason to have a "python" package which doesn't install its executable? I'm sure this will puzzle many users. <Apteryx_>I guess this is how it's done in the functional model; packages with a dependency on python are to use just "python" and refer directly to the store. This keeps the PATH namespace clean. <Apteryx_>Ah! Python works as expected with pip --user when installed in my user profile. When it differs slightly is when used in an environment. <rekado>Apteryx_: Python 3 doesn’t install “python”, that’s a change performed by distributions. <rekado>we just don’t perform this change. <rekado>we stick to upstream where possible <Apteryx_>In an environment, the system site-package location is put before the user site-package in PYTHONPATH. Usually it must come after so that a user can override any system installed package. Not sure why this only manifests in environment vs regular user profile... <Apteryx_>rekado: I see! Thanks for the explanation. I'm starting to see clearly. <Apteryx_>In an environment, there this "profile" entry which gets prepended at the beginning of PYTHONPATH, which explains the different behavior: '/gnu/store/ar7k7ds90ikxv40a6lif6jv2g39l7mls-profile/lib/python3.5/site-packages'. <Apteryx_>Which piece of code would take care of creating this temporary "profile" when using a guix environment? <rekado>Apteryx_: the entry point is guix/scripts/environment.scm <Apteryx_>rekado: OK! Thanks :) This will keep me busy for a couple hours tomorrow. <roelj>How can I 'run' a derivation, as in, produce the output described with a Gexp? <roelj>I now do (run-with-store (open-connection) (gexp->derivation "hello" #~(begin ...))). <roelj>That only creates /gnu/store/...-hello.drv, right? <civodul>then you need to use 'build-derivations' <civodul>so (run-with-store s (mlet %store-monad ((drv (gexp->derivation ...))) (built-derivations (list drv)))) <jmd>Sorry. (The cat walked over the keyboard) <roelj>What's the difference between built-derivations and build-derivations? <roelj>Or, what does store-lift do? <civodul>"built-" is the monadic variant of "build-" <civodul>'build-derivations' takes a store as its first argument, 'built-' does not (it's a monadic procedure instead) <roelj>So built really is the 'already-done-the-build' of a build? <roelj>Should it return the store output path? <civodul>you need to use 'derivation->output-path' <roelj>It returns #t here, but there's no output path in the store <wingo>rekado: awesome work making docker images! <civodul>roelj: you could do (mbegin %store-monad (built-derivations (list drv)) (return (derivation->output-path drv))) <civodul>that would return the store file name <roelj>It errors on: Throw to key `srfi-34' with args `(#<condition &derivation-missing-output-error ...>) ...'. <roelj>Does that mean something is wrong with the derivation itself? <roelj>Wow, it now works. There was a problem in my Gexp. <roelj>But the output path it returns, does not actually exist in the store.. <roelj>So, how do I run the derivation? ***LnL7 is now known as LnL
<thomasd>hi guix, I somehow got the impression that "propagated-inputs" are to be avoided if possible. Is that right? <ng0>I think we should apply what works for us, regardless of upstream <ng0>Is someone interested in talking with citadel why the way they provide software is suboptimal for distributions? <ng0>they only ever keep one file around <ng0>it's one of the large bbs which evolved and is still around <ng0>citadel? maybe I meant something similar <ng0>But I think their git can be used in this case <roelj>Running: `./pre-inst-env guix environment --container guix --pure coreutils' and then ./bootstrap; ./configure; in a fresh guix git checkout results in: `configure: error: C compiler cannot create executables'. What am I missing here? <roelj>In config.log I find: ld-wrapper: error: attempt to use impure library ... <wingo>roelj: a c compiler? doesn't --pure mean that you don't have anything? <wingo>if you need to get around that issue for whatever reason you might try GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yep <roelj>wingo: Well, it's a container anyway with the tools needed to build guix. Wow, the GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yep works. Isn't it bad though? <ng0>where am I when 'unpack has finished? in the root of the build or above that? <wingo>not if you are using the c compiler to build something that isn't destined to go in the store <wingo>the purity checker is just when building things that should go to the store <roelj>wingo: Oh, right. Then this is fine. Thanks a lot! <ng0>because I know src/configure.in exists, but no matter where I move the substitute phase it is not found <roelj>ng0: You can find that out by displaying the (getcwd) in that phase. <ng0>incredible how long I am sitting on some software to trying to get it to work <ng0>although the patch says september, I am sure I started on this in july <ng0>ah, I had this problem before. Iit seems as if some line in configure.in disturbs the substitute <ng0>this is where it repeatedly fails <ng0>or how shall i understand <ng0> ?: 1 [%read-line #<input: src/configure.in 11>] <civodul>ng0: no, i haven't talked to cURL upstream re certificates <civodul>(selfishly: i think i don't use cURL or cURL-using software :-)) <ng0>I'm not sure about this build... What if I have found a bug in the substitute function or something like this? Well it would be more like a bug in this bloated software (pike), but I'm not doing anything wrong <roelj>ng0: To select for '$srcdir' you'll need to do '\\\\$srcdir' in the substitute*. <ng0>but I don't want to substitute that <roelj>Oh, nevermind my comment then :) <ng0>i'm pushing my updated package <ng0>(add-before 'build 'patch-sh <ng0>When I don't patch the /bin/sh occurences in there, the build fails because posix_to_native_sh.sh will have an /bin/sh shebang <ng0>oh, i see even more things I should replace for this weird build system <ng0>but first I want to get to the point where I can replace /bin/sh, which for whatever reason fails <ng0>I want to avoid a patch as substitute is smarter, but a patch would be effective <roelj>Is there documentation on the build protocol? I get a #<condition &nix-protocol-error ...> and I would like to look up this protocol.. <ng0>the phase before succeeds, so I am in the directory where the root Makefile is <ng0>which includes the directory src, which holds the configure.in (or even configure) I want to patch <ng0>I can push the change and someone can reproduce the error <civodul>roelj: normally there's an error message in that error condition <civodul>see 'with-error-handling' in (guix ui) on how to catch it <roelj>civodul: Thanks. In this case I didn't create the output directory in the gexp. I couldn't really find this in the error message though. <civodul>roelj: see &nix-protocol-error in (guix store): it's a struct that contains a 'message' and a 'status' field <ng0>maybe I have to catch the /bin/sh at an higher level <roelj>civodul: How would I get an input inside a gexp of a package? #$(assoc-ref inputs "samtools")? <ng0>life would be easier if we could expose /bin/sh when absolutely needed <roelj>ng0: Maybe you could add a phase after unpack to replace all instances of /bin/sh in your source code? ;) Not sure if people will appreciate that though. <roelj>ng0: The only extra input you need would be sed..? <ng0>with find in "." ? maybe.. <roelj>ng0: Or find and xargs indeed <civodul>roelj: it's simpler: just write #~(foo bar #$sam-tools) <ng0>roelj: if only they used a widely used build system <roelj>civodul: But that would just take any version of samtools, wouldn't it? I'd like it to use exactly the one specified in the inputs field of that package.. <ng0>i really think that substitute* chokes on something in the configure file <ng0>move it one phase up to the other substitutes, same problem <civodul>roelj: #$sam-tools refers to the 'sam-tools' variable that's in the scope of the gexp <ng0>I think sed is my only hope.. <civodul>roelj: it really refers to a variable, not to a package by name, so there's no ambiguity <roelj>civodul: Oh, so (let ((sam-tools (assoc-ref inputs "samtools"))) #~(foo bar #$sam-tools)) would do it..! <civodul>if 'sam-tools' is bound to a package object, that's enough <roelj>civodul: re cray_easybuild. They are really smart with the "for scientific software" thing.. <ng0>civodul: substitute* is something guile provides, and not a function which is extended by a guix part? <ng0>roelj: I could patch it to use ${CONFIGSHELL} or something which would then be replaced by the full path to …/bin/sh <civodul>ng0: 'substitute*' is defined in (guix build utils) <roelj>civodul: Their vision on "reproducible": It aims to support achieving reproducibility in science, by enabling to easily reproduce software installations that were performed previously. <ng0>something weird is going on with this build system. even patch can't find the file <rekado>civodul, roelj: wait, no Guix talk in the HPC track at all? Instead there's an Easybuild talk? Oh, man! <domenkozar>hehe I told easybuild guys 4 years ago about Nix <domenkozar>their response was "but we invested so much time already" <rekado>our partner institute uses Easybuild for similar reasons <civodul>rekado: no no, there's 1 Guix talk instead of 2 in the HPC track, not so bad ;-) <rekado>except that by the time they started I already had a lot of bioinfo tools in Guix <civodul>we're not as lucky as in previous years <roelj>How can I get the store path of a package when all I have is the package symbol? <civodul>package->derivation and derivation->output-path <civodul>but maybe that's not what you want, what are you trying to achieve? :-) <civodul>gexps substitute package references by their file name in the store <roelj>Heh, let me paste the entire thing.. <civodul>so normally you don't have to worry about that <civodul>damn, didn't we say we should have tshirts, stickers, and whatnot for FOSDEM? <roelj>civodul: I did.. but I don't think many people agreed on that <roelj>I'd like to have a simple way of doing #~(begin (system* #$samtools-bin ...)) <roelj>But getting the whole path is kinda hard.. With packages, there's the (lambda (#:key inputs ...) ...) thing that seems to do exactly what I need. <roelj>Only now, I am not defining packages <rekado>roelj: it's weird that you define samtools-bin like that <rekado>can't you just use the package definition, bind that as "samtools" and reference that inside the gexp as #$samtools? <roelj>rekado: Yes I could do that, but then #$samtools refers to the package object and not the output path in the store.. <roelj>Or am I making a mistake in that thought? <roelj>Oh, it would be nice if I specify a different samtools version in (environment ...), that I can actually use that specific version instead.. <rekado>I guess you can just bind (assoc-ref environment "samtools") to "samtools" and use that inside of the gexp <rekado>the ‘ungexp’ form is replaced by its output file name—e.g., ‘"/gnu/store/...-coreutils-8.22’. <rekado>and with some macro action I think you could hide the (assoc-ref environment ...) stuff to just bind all environment members in the scope of the gexp <roelj>rekado: That's so weird.. If I do: (string-append #$samtools "/bin/samtools"), it results in a gexp containing: #<gexp ... (string-append #<gexp-input #<package samtools#1.3.1 gnu/packages/bioinformatics.scm:4134 *hash*> "/bin/samtools") ... <roelj>rekado: I'd love to see that macro action.. ;) I'll work on that <civodul>roelj: don't use 'package-output', it's often a bad idea :-) <civodul>so yeah, just #~(system* #$(file-append samtools "/bin/foo") "blah") <roelj>Is there a build log available for something you (build-derivations ...)? <roelj>Or another way I can get the script after the gexp has been resolved to its final execution form? <civodul>roelj: print the .drv file name, open it, and then open the "-builder" file it refers to <civodul>gexps are pretty much WYSIWYG anyway ;-) <roelj>The G-Expressions are really cool..! <jmd>Always make your bugs reproducible! <civodul>rekado: may have to do with parallel builds and non-thread-safe modules :-/ <rekado>the docstring of call-with-temporary-directory says that it deletes the directory again, but this only works if the directory is empty <snape>should I add a copyright line on a commit where I only add one input? <davexunit>snape: up to you I suppose. I think such a patch could be considered "trivial" from a copyright perspective and thus need no copyright line. <snape>ok. the patch is sent already. I guess it's not worth sending a new one, that removes the line <jmi2k_>Any guidelines for formatting recipes? Or even better, a tool to do it automatically? <civodul>davexunit: i wondered the same thing when i saw that article :-) <civodul>jmi2k_: pass it through the 'indent-region' of Emacs, if it's possible for you <civodul>we should provide a --batch command line for that <jmi2k_>civodul: I prefer standalone tools, but I'll use it. At least until I find something different. <jmd>jmi2k_: pretty-print does a good job <davexunit>me: "hey that amdgpu stack isn't actually free" <davexunit>r/archlinux: "yeah well nothing is free why are you using x86 if you care about freedom?" <avoine>good question, I always wanted to read "Escape from freedom" from Erich Fromm to learn more about why one would choose to give up his freedom consciously <davexunit>ACTION peruses guix-devel for the first time in awhile <nliadm>I really wanted one of those raptor POWER8 workstations, but I don't have that kind of money to spend on a daily driver <davexunit>civodul: just learning about 'guix copy'. this is awesome! <davexunit>I think that provides everything we need to write a simple remote machine management tool <davexunit>something like 'guix deploy reconfigure 192.168.1.123 my-os-config.scm' <civodul>davexunit: yes, i think we have most of the building blocks for 'guix deploy' now :-) <civodul>guile-ssh has a 'node-eval' form for remote evaluation of sexps <civodul>we could have something on top of that that takes a gexp and builds whatever needs to be built on the remote machine <davexunit>sometimes I think that offloading the build is good, but in other cases it's not <civodul>you could write: (remote-eval #~(system* #$(file-append foo "/bin/bar"))) <davexunit>it's common to have many identical web servers for example <davexunit>where building first and shipping the built OS over the network is much more desirable <civodul>but i mean for 'guix deploy' we need (1) remote copy, (2) the ability to run code on the target (e.g., to switch symlinks) <davexunit>we need to be able to send over a script that uses sudo or whatever to get privileges to do the reconfigure <davexunit>at work we use passwordless sudo privileges to run the Chef client on remote machines <davexunit>since Chef needs root access to touch everything it needs to touch <davexunit>civodul: so would we use a gexp to make such a script, copy it to the remote, and simply have guile-ssh call (system path-to-script) ? <civodul>yeah, i do too, but perhaps it would simplify deployment <davexunit>no one wants to run an ssh server in production with root login enabled <civodul>if password-based auth is disabled, it's less bad <davexunit>that could be *a* way to do it, but not the only way. <davexunit>Chef, for example, allows you to specify which user to ssh as and has a --sudo flag <davexunit>looks like i'm not going to use guix.el anymore <davexunit>Sleep_Walker: you login via ssh as a different user <davexunit>and use sudo to elevate privileges if/when you need to <Sleep_Walker>so attacker don't know who can gain superuser privileges? <davexunit>on ssh you use only key-based auth, for sudo you use the NOPASSWD option <davexunit>having to enter a password would break automation <davexunit>I've never seen a production environment that did this <rekado>civodul: re "--batch": I just sent an email to guix-devel with a command that works for me <nliadm>I've seen that, but to be fair, the person that set it up was a moron <davexunit>it sounds okay, I guess, but I'm still skeptical that allowing a root remote login at all is a good idea, no matter the auth mechanism. <rekado>davexunit: guix.el still exists; just need to install "emacs-guix". <davexunit>I'm not okay with it being removed from guix core. <nliadm>oh, is it being removed why emacs got reinstalled when I updated? <civodul>davexunit: guix.el is still nice, it's just in a different repo, after all <civodul>in the end, it's more important for guix.el to be alive and well than to be in the main repo <adfeno>I just don't like it being on GitHub... :( <adfeno>For me, it being on GitHub, means that free/libre software activists will either have to convince GitHub to free/liberate their JS, or have to send patches and issues by email instead of through GitHub. <davexunit>I think you can use the notabug project page instead? <davexunit>but then issues/patches are divided between two sites ***psachin is now known as psachin|brb
<cbaines>Does anyone have any tips on debugging guix system container? Sometimes when my code has bugs, guix system container gives me a cryptic error (Unbound variable in the system definition), and everytime I have had this, getting past it has involved fixing something completely seperate... <civodul>cbaines: does 'guix system build' give you that same error? <civodul>IOW, is it a "host-side" or a run-time issue? <davexunit>no one really uses 'guix system container' so there's probably some usability error on our part <civodul>cbaines: is there a simple reproducer you could share? <civodul>normally "unbound variable" errors should be relatively simple to pinpoint and fix <cbaines>Unfortunately I've been lazy with this code, so its not easy to share yet ***psachin|brb is now known as psachin
<davexunit>cbaines: does it say *which* variable is unbound? <cbaines>Yep, but its the <...> thing for a record type, which I've defined using the (define-record-type* ) thing in Guix... <civodul>could it be that you moved it to a different module? <cbaines>Its code that I have not touched recently <ng0>I think i figured out how fedora fixes mozjs-38 <cbaines>I've converted the system to a module so I can load it with use-modules from a REPL, and I can see from Guile that there are some unrelated warnings elsewhere, and I bet the actual problem I'm having is to do with one of them <cbaines>I'm going to fix them, and then see if that makes the error go away <civodul>cbaines: you could also have troubles if your modules have circular references <civodul>but yeah, you should investigate from the REPL <cbaines>Is there an easy way to check for circular references, as I think I've ran in to that problem before? <davexunit>not that I know of, but they are easy to avoid. <civodul>cbaines: maybe you could hack 'module-closure' in (guix modules) to detect that <cbaines>So, I've now "fixed" the error I was having <cbaines>I think the actual problem was a completely different record type not being imported <davexunit>rekado: just tried out the Docker image stuff. works like a charm! <cbaines>If I comment out the import I added, the error comes back, but it says "Unbound variable" about a completely different record, and the line number doesn't make any sense either... <civodul>cbaines: that sounds like a circular dependency issue <civodul>circular deps are okay, except when one module refers to bindings of another module from its top-level <davexunit>I think we should move the documentation for ruby to a separate output <davexunit>the ruby 2.3.3 store item occupies 96MiB, the docs alone are 70MiB <davexunit>I checked this because I made a Docker image for Ruby to share at work and was surprised by how large the closure is. <cbaines>civodul, can removing a #:use-module entry cause a circular dependency issue? (as that does not make sense in my mind) <civodul>i'll have to start using Docker just so i can start enjoying the new stuff :-) <civodul>cbaines: no, but it could cause things to fail differently, esp. if it triggers a recompilation <davexunit>I can give people Docker images at work now and they don't even have to use guix <davexunit>"how did you make this?" well, come with me and you'll see a world of pure imagination! <ng0>ACTION silently yells at mozjs38 <ng0>come with me, down the rabbit hole :) <davexunit>I think the workflow for image generation would be nicer if 'guix environment' had a flag to just spit out the profile name <civodul>what happens if you do 'guix archive --export -f docker foo bar baz'? <davexunit>civodul: 'guix archive' needs store directories :) <davexunit>guix archive: error: argument must be a direct store path <wingo>do we have docker itself in guix yet? or something that can run docker images? <davexunit>wingo: in master you can now use 'guix archive --export -f docker' <wingo>right i understand that we can create docker images <wingo>does guix package docker now, then? <wingo>or do you test on some other machine <davexunit>hmm I can't get 'guix environment' to use only the 'out' output of a package <civodul>davexunit: "guix archive --export foo" works (although there seems to be another bug in 'export-paths' right now) <ng0>don't we have /bin/false and /bin/true in the build env? <davexunit>somehow, despite the profile generated by 'guix environment' not referencing the "doc" output of the ruby package, the generated docker image has it. <ng0>I mean unrelated to what you are talking about.. the mozjs tests for shell/os.js fail <civodul>hmm might have to do with 9a8f9f84cc1672c45c2d204d9c234c932a8cb623 <davexunit>the coreutils true and false are on $PATH, however <ng0>okay, once I get to the point where the package builds okay, I will substitute <lfam>Hi janneke! What do you think about that ncurses merge conflict? <janneke>i created a patch this morning to try out and then forgot about it <janneke>i think the patches should `just be merged' and that's what i'm trying now <lfam>We also need nckx to weigh in <lfam>Right, I worked on just merging them for a while before realizing that I don't know if pkg-config is appropriate in mingw or not <lfam>So I wasn't sure if the pkg-config stuff belonged in the mingw conditionals or not <janneke>i guess the most tricky bit is the configure-flags bit <lfam>I actually backed up my half-merged work tree because I had done so much work in it but didn't want to commit it halfway <janneke>yes...my best answer without trying is: i don't know but i like to think nothing is special about mingw...unless it is <davexunit>janneke: how goes the mingw stuff? I'm interested if I could use it to make windows binaries for some programs of mine. <davexunit>my current use-case is to make binaries for a game which will need to dynamically load libsdl2, libpng, etc. <davexunit>so I have a whole tree of dependencies that I need to provide. <janneke>davexunit: the basics have been merged into master <janneke>which means that guile-2.x plus its dependencies build <janneke>./pre-inst-env guix build --target=i686-w64-mingw32 --keep-failed guile <davexunit>I'm so ignorant here, so pardon dumb questions. <janneke>packaging hasn't been done, so i have been using a script to collect stuff, set environment paths to test it under wine <janneke>and those have bitrotted...something needs to be done there <janneke>then, i have a whole stack of wip patches to also build LilyPond with all its dependencies...but those need some cleanup <janneke>davexunit: what kind of dependencies does your package have? <davexunit>SDL2 in turn depends on things like libpng for image loading and other such libs <janneke>ah...yes i have ghostscript, pango/cairo libpng stuff in progress <janneke>so we could possibly work together there <davexunit>I'd like to be able to use Guix to make "relocatable" binary builds for a variety of platforms, including Windows. <davexunit>hell even getting something for Ubuntu would be great <davexunit>would need custom packages that produce libs that work for FHS distros <davexunit>trying to understand more of what needs to be done there <janneke>lilypond has relocatable, distribution-agnostic binaries built by GUB <davexunit>would it be possible to approximate that with guix? <janneke>it's a--now going stale--mini source based distritubution built initially for lilypond by han-wen and me <janneke>davexunit: yes, guix is so much nicer <janneke>i want to move to guix, but some work needs to be done <davexunit>basically I want to produce store items that have *no* references to other store items <davexunit>my dependency tree isn't trivially small, but it's small enough that I should be able to make it happen <janneke>sure...and i think everyone has this need, so building something on top of guix would be grand! <janneke>here's my collect-guile script that I used to test/run in wine...which i'm sure needs some resurrecting <janneke>lfam: ugh...testing my patch fails building gawk in phase check :-( <davexunit>I guess I will start with trying to make builds for ubuntu or somethiong <janneke>great, that's easier and has the same basic requirements <davexunit>I'm glad you're working on the mingw side of things <davexunit>using guix as a generic building platform is cool <janneke>I'm glad there's more hope of sharing my mingw work with guix <davexunit>hmmm how can I get ld to stop setting the damn runpaths <bavier`>davexunit: could you have ld-wrapper filter the flags out? <davexunit>ld-wrapper is adding flags, but I want to use regular ol' ld <davexunit>I even used package-with-explicit to remove ld-wrapper from %final-inputs and it still didn't work <davexunit>sneek: later tell civodul I tried removing ld-wrapper from a build using package-with-explicit-inputs but the resulting shared library still has hardcoded reference to glibc libgcc. what's up with that? <janneke>lfam: i just built ncurses-mingw...now going for guile <rekado>I added a check using “direct-store-item?”, because that’s the only thing that made sense to me. <rekado>we can extend this in the future <rekado>at the moment it’s less powerful than plain “guix archive --export” <davexunit>that's not a big deal, the real problem is that things that aren't in the profile are ending up in the docker image <rekado>maybe I misunderstand what requisites are <davexunit>I discovered that ruby docs were 70MiB, so I put them in a "doc" output <rekado>when you do “guix gc --requisites /gnu/store/…-ruby…” does this include the doc output? <davexunit>there's a reference to the doc output in the regular output <davexunit>there's a file lib/ruby/2.3.0/x86_64-linux/rbconfig.rb <davexunit>that includes all sorts of compile time stuff ***jonsger1 is now known as jonsger
<lfam>janneke: Okay thanks, I'll adapt it for the master -> core-updates merge <ng0>is someone continuing the work on the inox browser, made some progress there? <civodul>davexunit: gcc hardcodes the RUNPATH to libgcc_s and libc, see gcc.scm <davexunit>ah, thanks. I was looking there and missed it. is there a GCC that doesn't do this or maybe I'll need to build a new one? <davexunit>I'm trying to use Guix to build libs with no store references in them so I can distribute some relocatable binaries. <civodul>so yes, you'd need to have your own GCC without that trick <civodul>Pjotr has been looking into rewriting store file names in binaries, that could help too... <janneke>davexunit: we used $ORIGIN in Gub, would that trick help? <janneke>$ORIGIN is the location of the executable <bavier`>can be used for shared lib rpaths too <janneke>i was thinking...what if we used that for all libraries in guix, something like <janneke>$ORIGIN/../../../gnu/store/abc-foo-0.0/lib/ <davexunit>there's still many other places for store references <davexunit>I don't think relocatable binaries are good in general for guix <jmd>gnulib has a module which makes relocatable binaries less tricky. <civodul>we could make selected packages relocatable, but nothing generic i think <bavier`>we talked about this idea some time ago, and mark_weaver brought up some good places where it couldn't work <nliadm>is that docker export thing landed? <nliadm>because it is very relevant to my interests <nliadm>is that "guix pull" or "build from source" <rekado>our package closures aren’t necessarily as small as they could be <nliadm>okay. I didn't know if it built raw master <rekado>if you plan on updating often (which you should anyway) I recommend using a git checkout <davexunit>civodul: personally I'm not too interested in a generalized thing, but I do want to build certain shared libraries that contain no store references, as well as guile.