<Steap>if you're going to bash Docker, I might take you with me to the RH office in Brno, you'd have a lot of fun! <jonsger>For the buildfarm you only want machine which runs Libreboot + Linux-libre? or what does "usable with exclusively free software" mean <jubalh>civodul: your talk sounds pretty interesting (to a newbie like me even more:) ) <jlicht>I'm trying to build some octave/matlab modules using octave, and its internal mex compilation command (which is actually mkoctfile with some flags) cannot find the openblas library I have installed in my current guix profile. <jlicht>Is anyone familiar with octave not respecting some of the paths/symlinks set by the current guix profile? <lfam>jubalh: help-guix is a new mailing list for people to ask for help. Most discussion is on the guix-devel mailing list. The project started in 2012. <lfam>jubalh: Are you trying to install the guix package manager on another distro, or the full system guixsd? <lfam>If you want to install the package manager, follow the instructions in section 2. For the full system, section 7. And you can play with the full system on your current system with `guix system vm` <jubalh>lfam: i would like to install it on a separate pc, so the full system <lfam>The vm tool is useful for testing the initial configuration <jubalh>in the guide its stated "As of version 0.9.0, the Guix System Distribution (GuixSD) is not production-ready" <jubalh>okay, well, whats the quickest way to test guix so i can have a taste. and see what packages are available and add some of the ones i want to? <mark_weaver>jlicht: does the error (about not finding the openblas library) occur while compiling/linking the modules, or when attempting to load/run the modules? <mark_weaver>when compiling C/C++ code using the GNU toolchain, the LIBRARY_PATH variable tells the linker where to find libraries at compile/link time. As for run-time, the 'gcc-toolchain' meta-package includes the 'ld-wrapper' package, which has an 'ld' command that automatically adds options to set rpaths in the linked program, to help it find its shared libaries at run-time. <jlicht>mark_weaver: it occurs when compiling the binaries. I verified that other things are working by manually adding the -L/gnu/store/etcetclibfolder flag to the compilation command <mark_weaver>I can think of a couple of possible problems: (1) maybe LIBRARY_PATH is not set properly in the environment where you ran 'mex'. (2) maybe your 'ld' is from 'binutils' instead of from 'ld-wrapper' or 'gcc-toolchain'. (3) maybe 'mex' doesn't use the 'ld' in your PATH, and directly uses the one from 'binutils' or does its own thing. <jlicht>(3) would mean I need to fix the script manually, I assume? <mark_weaver>jlicht: well, if it's (3) then we should fix our package <mark_weaver>jlicht: are you using GuixSD or Guix on top of another distro? <jlicht>I'm currently using Guix on top of a 14.04 ubuntu base <jlicht>How would I go about ruling out (2)? <jlicht>lrwxrwxrwx 38 root guixbuild 70 jan 1 1970 /home/jelle/.guix-profile/bin/ld -> /gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/bin/ld <jubalh>i will first look the existing fosdem talks and then try myself at installing guix tomorrow :) <mark_weaver>jlicht: okay, that looks good. what is the value of LIBRARY_PATH? <jlicht>I'm not totally sure how to evaluate that. Mex is called as an internal octave command, which seems to be translated to a call to the mkoctfile binary. Is it correct to assume this happens in my current profile? <mark_weaver>jlicht: if 'mex' is an internal octave command, then I guess the environment where octave is run is the relevant one. <mark_weaver>do you run octave from the command line or via something else (e.g. a desktop environment launcher)? <mark_weaver>actually, I think I don't have time to diagnose this with you, and probably people who actually use octave with Guix would be able to investigate more efficiently. Can you email bug-guix@gnu.org about it? <mark_weaver>make sure to mention that you're running Guix on top of ubuntu <jlicht>mark_weaver: I *think* I might have found the issue: it seems that the openblas library (0.2.15) builds into an openblas.so file (and some other stuff), whereas other distributions and software depending on this library expects a blas.so file. <mark_weaver>jlicht: ah, okay. well, if you could email bug-guix@gnu.org about it that would be helpful <jlicht>mark_weaver: I'll look into that tomorrow, but thanks for your help! <jubalh>It would be interesting to know whether you people run guix in guixsd or in another distro? <jubalh>maybe it would be good to start with the latter and later transition when its more complete? <jubalh>"On hosts using the systemd init system, drop ~root/.guix-profile/lib/systemd/system/guix-daemon.service in /etc/systemd/system. " instead of doing the line above (running the daemon by hand)? <jubalh>hmm i am running a binary distribution but used funtoo before that. maybe guix is just perfect to what i need in many cases. one case is that i am not happy with the compilation defaults of some packages i use, and guix would be a nice way to gain control over it without getting trouble with the systems package manager (i suppose) <jubalh>i suppose if i use guix on a foreign distro i just need to have as the first entry for PATH /home/user/.guix-profile/bin/ <mark_weaver>jubalh: I've been running GuixSD for over a year on my primary machine <mark_weaver>jubalh: the manual is in the main git repository, together with guix itself <gibal>greetings folks! life treating you all well i hope? <gibal>i was thinking about trying guix - but i dont know any scheme or even lisp. i understand it is in beta, in your seasoned opinions do you think there is enough documentation on the net for me to learn as i go? ***exio4 is now known as y
***y is now known as hacker
***hacker is now known as init
***init is now known as exio4
<rekado>gibal: there's a pretty comprehensive manual included with Guix. I suggest reading/skimming the manual first. <rekado>mark_weaver: thanks for merging the gtk-path-patch branch! <gibal>thank you, think im going to give it a try today, i usually use slackware - great thing about it not being update for ages is any problems ive ran into someone else has already asked about it and had the question answered! guess a manual is the same thing but all in one place <jubalh>Can somebody tell me how I can contribute to the git repo? I am used to GitHub and it's pull requests. how does it work on savannah? <rekado>jubalh: we send patches to guix-devel@gnu.org <rekado>you commit to your local clone and the use, for example, "git format-patch -1" to turn the last (1) commit to a patch that can be sent via email. <rekado>you do not need an account on savannah to contribute. <rekado>we will review patches sent to guix-devel@gnu.org with subject "[PATCH] ..." and eventually apply them to the repo on savannah. <jubalh>rekado: do i need to register to the ML or can I just sent the patch and people will include my email in the reply? <jubalh>rekado: I created a patch, should I attach it to a mail or make it the body? <alezost>jubalh: no need to subscribe to ML. But a note about keeping you CC-ed will be good <alezost>jubalh: you can attach or use "git send-email" whatever you prefer <rekado>jubalh: you can also inline the patch if you want. <jubalh>mail is sent, I attached it because I was not sure where to write the content of the mail if i include the path in the body (above or below the actual patch?) <rekado>jubalh: I haven't yet received it. Maybe it's stuck in moderation. <civodul>the 1st message sent to the list takes a little longer <jubalh>ah sorry, only read civodul's message now <civodul>jubalh: yeah for your first message, you have to be a little bit patient :-) <jubalh>Okay, thanks for letting me know. Patience is still something I work on hehe <jubalh>Whats the reason the first message takes longer? <roelj>civodul: Have you seen my patch for the build status icons? My request for enabling CORS for hydra has been resolved now. <efraim>jubalh: probably something about limiting spam <civodul>roelj: not yet, will check later today <civodul>good that you managed to get this far! <efraim>looks like libtasn1 4.7 no longer tries to rebuild libtasn1.info, so we can drop texinfo as a native input <civodul>maybe double-check the timestamps in the tarball and build with --rounds=2 <efraim>configure looked for a timestamp iirc <efraim>configure: autobuild timestamp... 20160105T134819Z <civodul>Spack very good support to describe package variants on the command line <civodul>but the paper fails to discuss reproducibility issues and all that <civodul>and what they write about Nix is incorrect <jubalh>looking forward to afte work. will try to install guix on my system today :) <jubalh>and if all goes will install guixsd on a seperate laptop tomorrow <jubalh>Sleep_Walker: why am I'm not surprised to see you here ;) <rekado>civodul: do you mean "users cannot easily navigate or query the installed software"? <rekado>I'm not too impressed with the command line syntax for package variants. @%-+=^ is a bit too much for me. <civodul>rekado: yes, that sentence for instance <civodul>i think the syntax is okay, and definitely convenient <rekado>why are compilers treated differently from other inputs? "%" for compilers and "^" for other packages. <civodul>i want to offer similar facilities on the command line <civodul>rekado: heh, because they're out of the scope of Spack :-) <civodul>some of the dependencies are taken for granted <rekado>I like "@" for specifying versions. And overriding inputs is certainly convenient. <civodul>but it's interesting because by leaving so many degrees of freedom, their "distro" provides very few guarantees <rekado>Recently I've been wishing for a little script that prepares a container with packages from the store linked to "expected" locations that would allow the user to run pre-built software for other distributions. <rekado>(maybe this already works with "guix environment" and an explicit list of packages) <civodul>"pre-built" as in "proprietary"? :-) <rekado>at my FSFE group there's someone who would like to try GuixSD, but they are currently using Debian. <rekado>it would so convenient if one could just spawn a faux-Debian container and run Debian software. <rekado>rather than using Guix as a package manager on top of Debian. <civodul>adding a --fhs flag to 'guix environment' wouldn't be difficult <civodul>but i think it would take more than this to be able to "run Debian" or some subset thereof <rekado>yes, optional FHS support, that's what I mean. <rekado>this annoying compiler problem that I fought with over the past days ... well, I'd probably have gotten more things done had I been able to run the Debian binary from launchpad. <rekado>(right now I'm cheating: I'm using the prebuilt firmware from the deb and use my cross-compiler for changes; surprisingly, this works.) <mog>an fhs debian container would be cool feature <mog>but would retard adoption of porting some things i think <efraim>a deb/rpm->store installer sounds like an interesting project, but a better option would be a pkg-src or aur importer <civodul>rekado: your cross-compiler still produces invalid binaries? <bavier>the guix website has something similar with our "liberating, dependable, and hackable" but each of those points could certainly be expanded <rekado>civodul: this cross-compiler problem is difficult for me to understand. The binaries look perfectly fine to me. <rekado>but the board doesn't like them and misbehaves when I use mine. <rekado>the difference between the pre-compiled binary in the .deb archive and the one I built with the cross-compiler (made from the same SVN revision) is not very big either. <rekado>I'm planning to look at the disassembled elf files and compare them. <rekado>maybe there's something obvious that can be fixed with a flag. <rekado>the compiler is, however, good enough to build "patches", i.e. generated C source files that are then linked with the firmware. <rekado>but I suspect it's an issue with the board's firmware rather than the compiler I built. <rekado>Today I updated a terrible piece of software at work and I even wished they provided a Docker image rather than this mess: bundled JDK, Mono for F#, Scala, Python, Perl, libgcc, libfortran, tons of Python packages such as scipy, Tomcat, ... and more. <rekado>I've never seen anything so bold. <rekado>I like that they call this "open source software". It might as well be a binary blog. Oh, wait: it *is* a binary blob. <efraim>more like an open source code dump <bavier>*but it's a special snowflake, so don't touch it <civodul>rekado: re the cross-compiler, i would skim the set of patches of the GCC that people use <civodul>i did that when cross-building the firmware for my wifi dongle <civodul>fortunately, the patches were easily located <efraim>I made the mistake just now of rebasing my core-updates branch on origin/core-updates before testing my gnutls update :) <efraim>civodul is trying to kill my netbook, changing gnu-build-system out from under me <civodul>but then i thought we'd better fix it before it bites <efraim>i've been building some of the inexpensive x apps, like xeyes, to test that nothing breaks <efraim>now's a great time to do it though, hydra didn't seem to have too much built up yet <jlicht>Is there anything special I need to do to build guix from git? When doing guix environment guix, and then the boostrap->configure->make, I get help2man errors. <jlicht>isn't guix environment <whatever> supposed to be able to build <whatever>, in general? <bavier>jlicht: from git, you'll want to `guix environment -e "(@@ (gnu packages package-managers) guix-devel)"` <mark_weaver>jlicht: also, make sure to pass --localstatedir=/var to ./configure <bavier>otherwise the environment doesn't include the devel-only dependencies <mark_weaver>but yeah, the problem is that help2man was added as a dependency fairly recently, and the 'guix' package in the version of guix you're running is older than that. <jlicht>bavier: That makes quite some sense. Thanks :) <mark_weaver>bavier: hmm, actually, won't 'guix-devel' get used automatically when one types "guix environment guix", since guix-devel has the name "guix" and a newer version number? <mark_weaver>the problem might rather be that the version of guix jlicht is using to run "guix environment guix" is too old, and predates when help2man was added as a dependency. <mark_weaver>anyway, I think those help2man errors can be ignored for now <mark_weaver>and after guix is built from git, you can use the version of guix from git to run "./pre-inst-env guix environment guix" and then help2man should be included in the inputs. <jlicht>mark_weaver: I'm updating the guix in my profile right now, as it complained about guix-devel being an unbound variable. <mark_weaver>alternatively, run "guix pull" to get the latest updates before running "guix environment guix" <mark_weaver>I guess you're using Guix 0.9.0 and haven't run "guix pull". <jlicht>mark_weaver: exactly what I'm doing right now ;-). <jlicht>incidentally, is there any way in which to throttle the compilation that follows the guix pull command? My laptop seems to be nearing core-meltdown temperatures <mark_weaver>That's a problem on some (but not all) Libreboot X60 machines, and I've dealt with it by disabling one of the cpus by "echo 0 > /sys/devices/system/cpu/cpu1/online <mark_weaver>most guix build commands also accept a --cores=1 option, but I don't know off hand if "guix pull" accepts that <mark_weaver>but in general, if you need to resort to such workarounds to avoid overheating, then your system is either improperly designed or has a hardware problem. <mark_weaver>some of the X60 variants have an inadequate cooling system, and apparently (I guess) rely on some hack in the proprietary BIOS to throttle the CPU in software, behind the kernel's back. <mark_weaver>Libreboot X200 machines have no such problems, btw. they work very well in my experience. <lfam>I'm trying to apply a bunch of patches to w3m. Some of then have a prefix of -p1 and other -p0. Is there a way to specify (patch-flags) multiple times? <mark_weaver>lfam: no, sorry. the patches will need to be modified to all use the same -pN flag <lfam>Hmm, I don't like this path. We are going to end up doing our own amount of non-trivial development trying to keep on top of all the important patches. I'm hoping that the old w3m authors declare the project abandoned so we can just use the Debian fork. <rekado>sneek: later tell civodul I'm using the exact same SVN revision and branch of GCC as the binary declares to have used. But I'll again compare the tarball with the SVN checkout to see if there's anything else that needs patching. ***jubalh is now known as Guest65701
<lfam>Guest65701: Almost! Make the title start with "doc:" and end with a period, as in commit daa8922abc. Usually, you also name the manual section where the changes are made, but since this is just correcting typos throughout the manual, I don't think that's necessary. <lfam>So, just change the title. Listing all the occasions is not necessary here, in my opinion. <Guest65701>lfam: oh my problem was that i looked at commit db5a94445f3b21b307c73ea72ed495bda891ef28 <lfam>In that commit, the changes to the docs are just describing the changes in the `guix package` code. They are not the focus of the changes so they don't get top billing <Guest65701>Now I'll start with writing my first system description <Guest65701>I hope I'll manage without knowing Guile/Scheme/Lisp <lfam>The basics are pretty accessible ***Guest65701 is now known as jubalh
<codemac>hey - I think I've figured out the libgcc_s bug on go, finally. <codemac>It's how we package glibc vs gcc, nixos has run into similar issues, and it's because of their global work arounds that their go package works <codemac>Will write something up for bug-guix and the conversation can happen there, just excited to finally find something actionable on this hellish package <codemac>Yeah, I don't know what the *answer* is lol, but others much smarter than me will hopefully have an idea. stracing builds in guix was a royal pain though <civodul>taylan: finally replied: go for it! :-) <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, rekado says: I'm using the exact same SVN revision and branch of GCC as the binary declares to have used. But I'll again compare the tarball with the SVN checkout to see if there's anything else that needs patching. <rekado>no difference between the GCC sources; but the binutils sources probably do differ. <rekado>I wonder if it wouldn't be best for me to use the tarball of source tarballs for this toolchain, rather than fetching from SVN and git directly. <civodul>for Xtensa, the patch i needed was a Binutils one