<lfam>The thing being counted by the progress bar would probably not reflect the time remaining very well. I guess you could count the number of derivations that remain to built. But it couldn't guess how long it would take to build each one
<davidl>could it perhaps make a gross estimate by making a system call checking the processor and also by the size of the software?
<lfam>Perhaps :) I wonder if anyone has tried this sort of thing before?
<lfam>Personally I'd rather work to get a faster build farm :)
<davidl>Faster build farm is probably a better priority. Im pretty far down the list of persons to ask for priorities xD
<lfam>It's just that you might not wonder how long reconfiguring will last if you can just download substitutes for everything
<lfam>If you lack fast internet, or don't want to use substitutes, that's another story
<lfam>I don't mean to discourage you from working on a progress bar, by the way. If you are motivated, you should try it :)
<davidl>I think it would be fun to try but I don't know any scheme dialect. It would be fun to learn Racket but Im not fast enough with my school-work to find extra time for it.
<efraim>sneek: later tell civodul libxslt, libxcb and xcb-proto all currently rely on python-minimal-wrapper, I'm trying them out with python2-minimal, and I also changed xorg to python2-minimal, so that should fix the python3 dependency of python2
<sneek>civodul, efraim says: libxslt, libxcb and xcb-proto all currently rely on python-minimal-wrapper, I'm trying them out with python2-minimal, and I also changed xorg to python2-minimal, so that should fix the python3 dependency of python2
<civodul>efraim: it's a build-time dependency, so does it really matter?
<adfeno>I'm unable to send patches to guix-devel. My email client is configured to use SMTP with TLS, and it seems that it only fails sending if the recipient is guix-devel (I have tested with other email addresses, not mine, and not from same service I use).
<civodul>adfeno: it would be surprising if lists.gnu.org were improperly set up
<civodul>there are hundreds of mailing lists on it :-)
<ng0>I succeded with building palemoon yesterday. Now I just need to clean up bundled software, fix the config (for example, do not use the default start page) and then it's ready to be distributed :)
<ng0>I'm building it again right now because I had to correct one path, but if you are curious, you can checkout my browser/palemoon branch from https://pagure.io/guix-dev.git .. just note that the start page it connects to is unfortunate and needs cookies etc.
<ng0>and the browser might include feature we don't want, I need to fine tune that as well
<ng0>(i hope I removed the phases which were just named in cursing at the build system)
<ng0>also the objdir is currently hardcoded, so I need info on how this will be called on other architectures..
<ng0>(objdir (string-append "obj-x86_64-" "unknown-" "linux-gnu")) it is for x86_64
<civodul>so basically, you should mimic 'fold-packages', which is the entry point
<roelj>I have stolen the implementation of fold-packages, and adapted it to my record type. (very hard ;))
<civodul>roughly it (1) determines the file names of the relevant modules, (2) converts them to module names, (3) calls 'resolve-interface' on these module names to load the modules, (4) traverses the list of exported bindings, (5) selects only those that match 'package?'
<Apteryx>Another question: what is the preferred location to add locales? My system config or my user profile? Or does it not matter.
<mekeor>Apteryx: i'm not sure, but i'd guess, if your computer is used by people speaking different languages, everyone should use the user profile. otherwise, system-wide? – my guess.
<Apteryx>mekeor: Thats seems reasonable. I was wondering if it would make any difference for the software, I guess not, the same way a package doesn't care if it's installed system-wide or in your user profile, it works the same.
<ng0>I'm back. and I hit runpath issues. is there an example of how to add an .so to a runpath of another .so ?
<dadinn>just a question, been looking at the ways to run Guix, and the "System Installation" download, even though it says USB install AFAIU is a qemu raw image to boot from, not really an iso image to write on a USB drive, and install Guix (like eg. Debian installer)
<lfam>mekeor: Yeah... hopefully we have substitutes soon :)
<mekeor>is there a way to make 'guix package -m' or 'guix system reconfigure' either (1) show all packages to be installed, marked as 'to-be-build locally' or 'there is a substitute', and then ask if that's fine for me; or (2) just install the last system completely available as substitutes?
<lfam>mekeor: (1) In practice, --dry-run will you what will be substituted and what will be built from source. It doesn't take grafting into account, but grafting is an order of magnitude faster than building in most cases, and you should never disable it except when debugging.
<lfam>I mean to say, "--dry-run will tell you what..."
<lfam>There *was* a bug that made grafts slow in some cases, but it's fixed on the master branch.
<lfam>Fixed in 0aeed5e310504a9ef2cf6a2b2a7e76086eb8c2fc and the preceding commit
<mekeor>alright, i'll check out --dry-run, thanks lfam :)
<lfam>Right, in my limited knowledge, it's a use case that Guix doesn't really meet right now, since Guix is a build-from-source system that transparently substitutes binaries when they are available. But my understanding of the implementation is still weak, so I don't know how easy or hard it would be to do what was asked there.
<lfam>mekeor: I'm curious, did you do `guix pull` and now find yourself wondering how you can go back?
<mekeor>lfam: yes, i did `guix pull` and then i did 'guix package -m' (as user) and 'guix system reconfigure' (as root) and i didn't like that i didn't know how long it would gonna take
<lfam>`guix pull` is one tool that I think suffers because many of us have an alternative to that particular flavor of dog food. We keep a Guix Git repo that we build and use, and that gives us way more flexibility than the one-way `guix pull`.
<lfam>Working from the Git repo lets us use arbitrary commits, and test changes at will.
<lfam>It's not great for everyone that's unfamiliar with Git :/
<ng0>rekado_: I know again why I did it like this. the configure flags get transported on to other subdirectories/moz.build files, and let the configure phase fail once it enters "js/src" (which happens probably because no java,javac,javah,jar,jarsigner is found
<ng0>or maybe not.. but to not carry these build flags on and on would be good. haven't pushed an updated yet
<ng0>ah, because out of source does not work in this case
<ng0>the thread got so long that I stopped paying attention
<lfam>I was thinking a "small" improvement would be to enable it to accept arbitrary commits to pull from. That would at least allow a basic roll-back funtion, assuming the user could determine which commit they wanted.
<rekado_>rofi is like ido and stumpwm is a bit like emacs
<lfam>The snapshot generator is actually really fast! I requested a snapshot of a very early commit, and Savannah started to send it immediately
<rekado_>ng0: in that case please generate the file from scratch with “display”, not by substitition. And please comment why it’s needed :)
<ng0>even when it says windows, this is also valid for gnu systems because build system from hell something is broken or whatever. I will try to mess around some more and see if I can stick with #:configure-flags, otherwise I'll switch back
<ng0>I've used substtitute because there is a file you can copy
<OrangeShark>mekeor: the file has to evaluate to a package. So you can either remove the define-public or just add emacs-athena to the end
<lfam>Off-topic but Obama just commuted Chelsea Manning's sentence. She'll be free in May 2017 :)
<OrangeShark>mekeor: if you want to be able to `guix package -i emacs-athena`, you can put the file as gnu/packages/emacs-attena.scm where the gnu directory would be in your GUIX_PACKAGE_PATH environment variable
<mekeor>OrangeShark: how do i make my package visible in my manifest? i put the define-public back in into emacs-athena.scm. i defined $GUIX_PACKAGE_PATH. i moved emacs-athena.scm to $GUIX_PACKAGE_PATH/gnu/packages/. i inserted (use-modules ... (gnu packages emacs-athena)) into my manifest.scm. still, 'guix package -m manifest.scm' results in emacs-athena being unbound...