IRC channel logs


back to list of logs

<paroneayea>lfam: hey, how far from california are you? :)
<lfam>paroneayea: Really far!
<paroneayea>lfam: ah!
<lfam>paroneayea: I'm on the east coast
<paroneayea>civodul and I were thinking who might be a good fit to present at
<lfam>I can't believe there's no Guix hackers in California!
<paroneayea>yeah, Guix has a lot of hackers
<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
<paroneayea>lfam: same
<paroneayea>lfam: will you be at LP this year?
<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
<civodul>ACTION -> zZz
<civodul>later, gentlefolks!
<davexunit>lfam: oh cool! will be nice to see you at LP
<davexunit>(it's the one software conference I attend)
<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>lfam: I've never heard of Underbones
<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
<davexunit>oh we're talking about the same place :)
<lfam>I like basements better :)
<davexunit>the basement is awesome
<davexunit>I'd love to go to redbones.
<lfam>It's a date!
<davexunit>one of my cars still has a somerville parking pass, too ;)
<davexunit>good until may
<lfam>Ha, perfect
<paroneayea>davexunit: would you want to submit a proposal to talk?
<paroneayea>you'd be a perfect presenter for it!
<davexunit>paroneayea: I'll consider it.
<davexunit>would need to see how my fiance feels and if my friends would be willing to host me, etc.
<davexunit>I've never been to California
<paroneayea>davexunit: cool, let me know after you've done some thinking :)
<davexunit>will do
***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 Hartmut sometimes around here?
***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
<Apteryx_>Why this is so... I have no clue yet.
<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.
<Apteryx_>as in, python3 or python3.5 ?
<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_>And avoids unexpected coupling.
<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.
<Apteryx_>Good night/day!
<Apteryx_>ACTION zzz
<civodul>Hello Guix!
<wingo>happy new year, guix :)
<civodul>hey wingo :-)
<civodul>this will be the year of 1.0!
<civodul>and Guile 2.2 i'm sure!
<roelj>How can I 'run' a derivation, as in, produce the output described with a Gexp?
<civodul>roelj: at the REPL you can do:
<civodul>,use (guix)
<roelj>I now do (run-with-store (open-connection) (gexp->derivation "hello" #~(begin ...))).
<civodul>(gexp->derivation "foo" #~(x y z))
<civodul>right, that's correct
<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?
<civodul>subtle no? :-)
<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?
<civodul>that name was probably a mistake
<roelj>I see
<roelj>Should it return the store output path?
<roelj>'built-derivations' that is
<civodul>it returns a Boolean
<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!
<roelj>civodul: Here's what I do:
<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>Or actually, with the Gexp?
<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>I now do this:
<roelj>So, how do I run the derivation?
***LnL7 is now known as LnL
<roelj>Here's you gexp:
<thomasd>hi guix, I somehow got the impression that "propagated-inputs" are to be avoided if possible. Is that right?
<ng0>civodul: wrt have you asked cURL upstream in the past?
<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>too many branches
<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/ 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>I'll try that
<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 disturbs the substitute
<ng0>line 11 contains:
<ng0>case "$srcdir" in
<ng0>this is where it repeatedly fails
<ng0>or how shall i understand
<ng0>In unknown file:
<ng0> ?: 1 [%read-line #<input: src/ 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>Okay :)
<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>or dirctly:
<ng0>my problem is with
<ng0>(add-before 'build 'patch-sh
<ng0>When I don't patch the /bin/sh occurences in there, the build fails because 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>I've added an (with-directory-excursion "src and the error is similar to what I had before:
<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 (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
<ng0>done in
<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)
<civodul>roelj: seem the workflow talk didn't get in:,_big_data_and_data_science/ :-/
<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..
<roelj>civodul: No it didn't :(
<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
<civodul>bavier, rekado, roelj:
<roelj>civodul: Oh, so (let ((sam-tools (assoc-ref inputs "samtools"))) #~(foo bar #$sam-tools)) would do it..!
<civodul>no no, no assoc-ref, nothing :-)
<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>roelj: their paper at mentions Guix (the paper is called "Reproducible ... with EasyBuild", and the paragraph about Guix says that Guix provides "true isolation" :-))
<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 ;-)
<civodul>domenkozar: fun :-)
<rekado>except that by the time they started I already had a lot of bioinfo tools in Guix
<rekado>civodul: oh, right, I missed it
<civodul>we're not as lucky as in previous years
<civodul>surely there's a conspiracy
<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?
<Sleep_Walker>ACTION would like Guix hoodie
<roelj>civodul: I did.. but I don't think many people agreed on that
<roelj>Here's what I am trying to do:
<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>that's okay
<rekado>I guess you can just bind (assoc-ref environment "samtools") to "samtools" and use that inside of the gexp
<rekado>the manual says:
<rekado>the ‘ungexp’ form is replaced by its output file name—e.g., ‘"/gnu/store/...-coreutils-8.22’.
<rekado>so you'll actually get the path
<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>Ah great
<roelj>The G-Expressions are really cool..!
<rekado>I see a lot of these: guile: warning: weak hash table corruption (
<rekado>(when running "make")
<rekado>cannot reproduce it
<jmd>Always make your bugs reproducible!
<civodul>nooo, not that one
<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
<davexunit>can we get guixsd on a watch?
<snape>should I add a copyright line on a commit where I only add one input?
<snape>I mean, a package 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
<davexunit>yeah it's fine
<jmi2k_>Any guidelines for formatting recipes? Or even better, a tool to do it automatically?
<civodul>rekado: good point
<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?"
<davexunit>why is this type of argument so common?
<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>so you can reconfigure remote machines
<davexunit>something like 'guix deploy reconfigure my-os-config.scm'
<civodul>davexunit: yes, i think we have most of the building blocks for 'guix deploy' now :-)
<civodul>there are more things we could do
<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>civodul: so basically offloading?
<civodul>yes, but more fine grain
<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>that have few resources
<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)
<civodul>yes, agreed
<davexunit>ah okay
<davexunit>yes, we need that
<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>we could also SSH log in as root
<civodul>davexunit: something like that, yes
<davexunit>I turn off root login on all machines
<davexunit>and give the root user no password
<civodul>yeah, i do too, but perhaps it would simplify deployment
<davexunit>it would be too risky I think
<civodul>yeah it's not ideal
<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>that's a bummer, it was nice.
<davexunit>oh well, the CLI will do just fine.
<Sleep_Walker>disabling root login? and replace it with sudo or how?
<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?
<Sleep_Walker>and sudo asks about your password?
<davexunit>no password
<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
<Sleep_Walker>not my cup of tea, but interesting
<davexunit>then what is your cup of tea?
<Sleep_Walker>having root login available and using key-based auth
<davexunit>that's not best practice
<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.
<davexunit>so I'm not going to use it anymore.
<nliadm>oh, is it being removed why emacs got reinstalled when I updated?
<davexunit>no I don't think so.
<davexunit>I hope the code will return some day.
<civodul>rekado: awesome!
<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
<davexunit>I guess.
<adfeno>I just don't like it being on GitHub... :(
<davexunit>I think it's the wrong move.
<davexunit>so I will boycott.
<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
<davexunit>not great.
<davexunit>oh well.
<davexunit>it is better that the code still exists.
***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?
<cbaines>Yes it does
<davexunit>no one really uses 'guix system container' so there's probably some usability error on our part
<davexunit>nvm then
<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.
<davexunit>another old proprietary game has been freed
<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
<civodul>this is admittedly annoying
<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 think this will help Guix adoption
<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>oh you can put package names there?
<davexunit>I will try once ruby finishes building!
<davexunit>store dir size down to 26MiB! awesome
<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'
<davexunit>and pass in a store item(s)
<wingo>right i understand that we can create docker images
<wingo>but how to test them?
<davexunit>wingo: docker load < the-output.tar
<wingo>does guix package docker now, then?
<wingo>or do you test on some other machine
<davexunit>we still don't have a docker package
<davexunit>I'm using docker on ubuntu
<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>ng0: /bin/true and /bin/false do not exist
<davexunit>there is no /bin
<civodul>bah, i'll look at it later
<ng0>ok :)
<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
<janneke>hey lfam!
<lfam>Hi janneke! What do you think about that ncurses merge conflict?
<janneke>i'm looking into it now
<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> 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
<davexunit>janneke: as windows binaries?
<janneke>yes, run
<janneke>./pre-inst-env guix build --target=i686-w64-mingw32 --keep-failed guile
<davexunit>will try this :)
<davexunit>possible to run with wine easily?
<davexunit>I'm so ignorant here, so pardon dumb questions.
<janneke>yes and no...
<janneke>packaging hasn't been done, so i have been using a script to collect stuff, set environment paths to test it under wine
<davexunit>ah I see
<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>janneke: OpenGL and SDL2 are the big ones
<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>davexunit: we built GUB for that...
<davexunit>what is that?
<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>no runpath in binaries, for example.
<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 :-(
<janneke>changing ncurses is not funny
<davexunit>janneke: thanks for sharing
<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>can move onto mingw from there
<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>I thought ld-wrapper put the flags in!
<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 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”
<rekado>improvements welcome!
<davexunit>rekado: ah I see.
<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
<davexunit>that doc output is not in the profile
<davexunit>but it is in the docker image
<davexunit>I don't have any leads on why this happens
<rekado>when you do “guix gc --requisites /gnu/store/…-ruby…” does this include the doc output?
<davexunit>hmmm, yes. the bug is elsewhere, then.
<davexunit>your code is fine!
<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
<davexunit>gonna delete that
<rekado>that’s like perl
<bavier`>and ghc packages too, iirc
<davexunit>this went unnoticed for so long
***jonsger1 is now known as jonsger
<davexunit>oh damn it
<davexunit>ruby loads rbconfig at runtime
<davexunit>so I can't simply delete the file
<davexunit>I'll need to cleverly edit it
<janneke>lfam: i have pushed a `manually merged' commit to
<lfam>janneke: Okay thanks, I'll adapt it for the master -> core-updates merge
<janneke>lfam: thanks!
<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>ooh, relocatable binaries, tricky!
<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?
<davexunit>what is that env var?
<janneke>no, it's a ld directive, like so
<janneke>gcc -Wl,-rpath,'$ORIGIN/../lib'
<janneke>$ORIGIN is the location of the executable
<davexunit>yeah maybe!
<bavier`>can be used for shared lib rpaths too
<davexunit>I'm not sure how it would work though
<davexunit>I was just gonna set LD_LIBRARY_PATH
<janneke>i was thinking...what if we used that for all libraries in guix, something like
<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
<rekado>nliadm: it is in master now
<rekado>it might be a little crude
<nliadm>is that "guix pull" or "build from source"
<rekado>our package closures aren’t necessarily as small as they could be
<rekado>either way is fine
<rekado>guix pull builds from source.
<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.