<mark_weaver>sneek: later tell civodul: regarding the bash fixes: alas, there is now an official 26th patch for bash-4.3, and it includes another "eol_ungetc_lookahead = 0;" that we didn't include, and for some reason they didn't include the parser-oob patch or anything like it.
<mark_weaver>sneek: later tell civodul: okay, I ended up pushing another branch 'bash-cve-bis' with a modified version of your patch from 'bash-cve-next'. this includes the upstream bash 4.3.27 plus the parser-oob patch. I've deleted the other bash-related jobsets from hydra and added a new one to build the 'bash-cve-bis' branch.
<sneek>civodul, mark_weaver says: regarding the bash fixes: alas, there is now an official 26th patch for bash-4.3, and it includes another "eol_ungetc_lookahead = 0;" that we didn't include, and for some reason they didn't include the parser-oob patch or anything like it.
<sneek>civodul, mark_weaver says: also, I don't know about the version number 4.3.27, since it doesn't include all of the fixes of the real 4.3.26, and we don't know what .27 is going to be.
<sneek>civodul, mark_weaver says: so, I'm thinking that maybe we should _not_ merge the branch, and instead redo it differently and rebuild again.
<sneek>civodul, mark_weaver says: and now there's an official bash-4.3.27 patch, and it still doesn't include parser-oob. instead it has a variant of the variables-affix patch.
<sneek>civodul, mark_weaver says: I guess patch 27 makes the parser-oob patch much less important. I would advise scrapping bash-cve-next and just using the upstream bash-4.3.27 as-is.
<sneek>civodul, alezost says: Hey, initially I suggested something for "configure.ac" to take care about the users who don't have Emacs installed, but you said there's no need. And now you are adding "HAVE_EMACS" there. I feel aggrieved :-(
<sneek>civodul, alezost says: Joking :-) Would it be OK if I'll push a couple of small fixes and not interesting internal changes to Emacs UI without mailing to guix-devel?
<sneek>civodul, mark_weaver says: okay, I ended up pushing another branch 'bash-cve-bis' with a modified version of your patch from 'bash-cve-next'. this includes the upstream bash 4.3.27 plus the parser-oob patch. I've deleted the other bash-related jobsets from hydra and added a new one to build the 'bash-cve-bis' branch.
<alezost>civodul: re HAVE_EMACS, actually I knew that it would fail without Emacs since the very beginning and that's why I was surprised that you found it acceptable (apparently it was miss-understanding); but never mind, I'm glad it's fixed now
<DusXMT>Elzair: I'd say the simplest thing to do (the only thing I've done so far myself) is packaging, but it depends on the package. Packages with a built system comformant to the GNU coding standard are primitively easy to package, but it can get tricky still
<DusXMT>bavier:yup, just running the built, installed package. It also wanted a dbus session, and once I created it (mkdir and something else), it worked but segfaults when I try to save or open any spreadsheets
<davexunit>ruby gems are infuriating, going to give up for the day soon and go back to importer fixes.
<cmhobbs>watching the february fosdem guix talk, i just learned that guix can do per-user installations. that's really rad
<a_e>Yes. I think that is one of its major features!
<davexunit>civodul: potential issue with the test suite. The module (guix snix) no longer exists in my source tree, but since I installed guix to my system, the module is still in guile's load path when tests are run.
<davexunit>so, I don't see the test failure that I'm expecting.
<a_e>I think that from time to time, it is good to rm -rf $PREFIX/share/guile.\\
<davexunit>I'd like to alter the test env to make sure this can't happen.
<davexunit>civodul: yeah, I couldn't find anyway to prevent those unwanted results.
<mark_weaver>right. I was thinking that if guix was installed in the same prefix as guile, then it would necessary to go further and remove things from %load-path and %load-compiled-path, but that you'd have to somehow include guile's own modules while excluding the older guix installed modules.
<mark_weaver>I don't remember off-hand if the guix installed modules end up in the same place as guile's own modules.
<cmhobbs>alright, i'm gone for real. waiting on hello (binary) to install on this machine. it worked (building from source) under xubuntu. i'll report back later once it installs here and then dive into the guix source
<isd>Hey all -- I've got a recipe I'm working on, and am trying to build it (for the first time). I running guix on top of an existing system, and haven't previously built any packages, so it seems to be pulling in everything. It seems to be trying to build everything in /run/user/$UID, which is mounted as a tempfs. That directory seems to be managed by systemd somehow. Unsurprisingly, it's running out of space when building gcc.
<davexunit>alezost: heh, someone's already submitted your elisp package to MELPA.
<alezost>davexunit: My variant of using is strange I think: I modified "emacs/guix-helper.scm" a bit to make 'updates-dir' point to the git repo instead of "~/.config/guix/latest". I did so with "scripts/guix" as well.
<alezost>davexunit: ouch, people are really fast now :-)
<a_e>Hm, I just did not find the header files: KApplication resides inside a subdirectory KDE, and all it does is this:
<a_e>I tried g++ directly, but I do not know which -l to pass; I get an "undefined reference to symbol '_ZN7QString11shared_nullE'
<a_e>libQtCore.so.4: error adding symbols: DSO missing from command line
<mark_weaver>maybe we should add some common utilities for fixing things in cmakefiles.
<mark_weaver>e.g. to replace those search paths with directories from the inputs.
<a_e>Nix needs to have solved the problem. I am just trying to compile the KDE Hello world by hand, but the same problems must appear in each and every kde program.
<a_e>mark_weaver: This would only work if we added libx11 as an input to cmake; plus a lot of other x.org libraries, as they are checked for in the remainder of the cmake file. libx11 is just the beginning.
<mark_weaver>a_e: I think you misunderstood my suggestion. I don't mean to modify the cmake package, but rather to add a (guix build cmake) module with some helpers used in recipes. I recently added (guix build emacs) to support convenient editing of emacs variable defaults, for example.
<a_e>mark_weaver: Okay. Indeed one could set a lot of environment variables.
<RISCi_ATOM>mark_weaver: Ya, when I get this set up I'll make my own install image ;)
<mark_weaver>civodul: hmm, is wildebeest running a very old guix?
<mark_weaver>one issue I ran into when setting up the MIPS build slave is that, by default, ssh sets PATH to some hardcoded value that was causing a different 'guix' to be used than the one I intended.
<mark_weaver>I had installed 'guix' using Guix, so it was in ~/.guix-profile/bin, and I set the PATH in the .bashrc or .bash_profile (don't remember which), but that wasn't sufficient. it was using some ancient guix that I installed long before in /usr/local/bin
<civodul>mark_weaver: i think it's actually a related but different issue