***winston5mith is now known as smithwinston
***smithwinston is now known as francis7
<calher>What parts of NixOS are non-free? How hard is it to remove? I want to use a stable declarative system until Guix is ready. <calher>Then again, I break my system all the time, so maybe using Guix is not so bad. <calher>Plus, I don't want to learn a domain-specific language. <davexunit>calher: NixOS uses Linux, not Linux-libre, which includes firmware blobs, I've been told that their firefox build comes with flash built-in, but I don't know for sure, etc. <davexunit>without a policy to segregate free from non-free, I imagine that it's really difficult in practice to run NixOS without proprietary software. <calher>But OK, that's what I needed to know. Thanks for answering. <calher>I thought I could just replace Linux, or get an ugly system declaration that would let me get by until Guix is done. <davexunit>guixsd is alpha, but I use it as my main OS every day. ***francis7 is now known as winston
***winston is now known as francis7
<davexunit>has anyone ever experienced an unstable tarball from a sourceforge mirror? <davexunit>I don't understand how this could be since it should be just a static file <davexunit>ACTION gets a bit closer to having Kodi packaged <calher>davexunit: Is the packaging really done in Scheme? <fps>oops, wrong key press. never mind.. <piyo>Your keypress has been logged globally. <fps>and mankind is much richer for it <piyo>is there a hydra mirror in asia or japan region? <fps>i'm not sure that there are any mirrors at all <kmicu>“I've been told … [nixpkgs’] firefox build comes with flash built-in” that sounds like FUD ;) In general to enable anything ‘unfree’ in Nix(OS) a user must explicitly add ‘allowUnfree = true;’ in config. <alezost>kmicu: thanks for the info, you can use sneek bot to redirect it to davexunit <kmicu>alezost: thank you for a hint; channel is logged so that should suffice. Addressing the kernel issue — a user needs to explicitly enable ‘hardware.*Firmware’ options to install ‘firmwareLinuxNonfree’. Out–of–the–box you should not be able to install non–free software. If that’s not the case then please file a bug. <csed>Possible to set up wireless interfaces during installation, or do I need ethernet? <alezost>csed: I think it should be possible if linux-libre supports your wireless card <alezost>although I didn't try, so I don't really know <rekado>After days of packaging Ruby gems I'm so tired of these "clever" names and descriptions. <davexunit>does this mean that something is wrong with our ffmpeg build? <davexunit>I imagine it's probably something wrong with the kodi build, but kodi is so massive that it's hard to debug. <taylan>davexunit: maybe it just needs an ffmpeg version different from 2.8? or maybe it needs a certain patched version of ffmpeg (ugly situation, but happened me with audacity and some library whose name I forgot). <davexunit>taylan: seems that it's trying to use its own ffmpeg or somethign <davexunit>found a configure flag called --with-ffmpeg whose default value is "force", which means to forcibly use the bundled copy. <efraim>I'd take a look at ffmpeg first with that error <davexunit>I tweaked a configure flag and now the compilation is getting much farther so I think I'm okay for now <efraim>I see zlib as an input for ffmpeg, maybe xz is an optional input? <davexunit>adding xz to the build environment didn't resolve the error so something stranger is afoot, I think. <civodul>Kodi looks like an intimidating piece of software <davexunit>but I only had to package 2 new dependencies <davexunit>there's still some work to do, because I built kodi in a guix environment container <davexunit>(a *really* useful way to mess with packages that keep failing to build without having to start over each time, btw) <davexunit>there's a script that I need to identify that relies upon /bin/sh <taylan>oh wow, that's good to know. I wished for something like that many times. <taylan>starting the build from zero every time is a big pain <davexunit>I muck with things in environment containers <davexunit>and work out any additional complications that arise. <efraim>that'll help with my 6 hour gccgo5 builds <lfam>davexunit: You should make a little blog post about that. <davexunit>sweet, the kodi that I built actually plays videos <davexunit>once I have this wrapped up, I can replace Debian with GuixSD on my living room computer. :) <lfam>Nice :) The lisp-machine-television <bavier>davexunit: cool, I was hoping we'd get kodi someday <bavier>civodul: the (guix graph) module looks cool. I haven't looked at the code yet, but will soon. <wingo>is there any way to know in advance how much data a guix transaction will consume? <wingo>i am interested in on-disk and transferred size <wingo>assuming you are using substitutes <civodul>wingo: the substituter gives us that info, but the UI doesn't exploit it currently <wingo>yeah, would be nice to have some kind of global progress bar or somethign <wingo>anyway, a thought for another day, too many chainsaws in the air <davexunit>hmm, it appears that some source shebangs aren't being patched, which is why kodi's build fails. <bavier>hmmm, I thought the openmpi had fixed the scalapack build timeout problem... <efraim>I wish the Python tests ran in parallel <lfam>Oh no! I'm trying to build LibreOffice from source because I thought it might (maybe...) be faster than getting substitutes from hydra. Well, it wants to build python-2.7 and python-3.4 from scratch. I thought I had those but I guess that some dependency has changed. Groan :P <lfam>Actually, the pythons just zoomed by. We'll see how long it all takes. <mark_weaver>unless some recent update on git master triggered python rebuilds, in which case that's a problem. <lfam>civodul: I know this! I am originally from South Florida, where alligators and the pythons are locked in an eternal struggle. <lfam>Well, I'm not sure what the Python build is supposed to look like. It seemed to just unpack and copy files. I was expecting at least some C compilation. <civodul>lfam: "./pre-inst-env guix build libreoffice -n" in current master tells me that LO is available as a substitute (x86_64) <lfam>Yes, up-to-date git master. I'm building the libreoffice-5.0.3 in response to Mark's message on the ML <lfam>I decided to do --no-substitutes because I was getting ~20 kBps from hydra. <mark_weaver>lfam: oh, well, if you need to download python then you'll need to download a lot of other stuff as well. probably at least half of our packages depend on python. <mark_weaver>so, if you disable substitutes, you'll probably be compiling stuff all day. <mark_weaver>even a slow download from hydra is likely to take less time. <lfam>It's strange because I have been doing a lot of python packaging. I should have the subsitutes available locally. <efraim>same question: I thought there was supposed to be compiling while building Python stuff <mark_weaver>lfam: some security updates pushed 5 days ago caused python to be rebuilt. <efraim>I just built something and sat through 30 minutes of tests, updated dependencies and the build just copied stuff it looked like <lfam>Alright, I only started the no-substitutes build about 10 minutes ago. I will host a race between my CPU and my bandwidth to hydra ;) <mark_weaver>civodul: it may be that we should shut down the queue-runner while GC runs, if hydra is not able to serve substitutes efficiently while running GC and all the builds. <lfam>Now, I am getting an order of magnitude more downstream speed from hydra. Between 100 and 200 kBps <efraim>if there were resumable downloads from Hydra then Hydra would always be better for me <lfam>Okay, it's going very fast now. I have already downloaded boost, while I am still compiling it locally. <mark_weaver>civodul: it's a demonstration of the power of our approach that 'guix lint' can do the job robustly, dealing with the package objects directly, whereas the nix approach scraps the nix files for urls and creates a huge bash script. <lfam>ACTION agrees with mark_weaver <efraim>this is much better on my laptop than on my phone <lfam>efraim: IRC? Doesn't IRC wreak havoc on your phone's battery? <efraim>not as much as having the screen on to read IRC <efraim>plugged into my laptop I broke even <rgrau>Hi, I'm trying to compile openresty, but I hit this strange error in the proces (it's on configure, but it compiles luajit on the configure phase... yeah... ) "/home/myuser/.guix-profile/bin/ld: this linker was not configured to use sysroots" <rekado>rgrau: can you disable the build of luajit? Don't we have a package for that? <lfam>We do have a luajit package <lfam>Perhaps there is a configure option to set the path to luajit? <rgrau>yup, we have a package for that, and I guess it would be the next step. but I'd like to complete the full process of compiling it 'the normal way' <rekado>it doesn't seem normal that an application builds yet another library as part of its build process. <rekado>it would probably be better to enter a guix environment where luajit and all other dependencies are available and then build the application "the normal way". <rekado>rebuilding stuff that's already available just sets you up for confusion and unnecessary pain. <rgrau>indeed. but it's just how the openresty guys package their stuff. afaik the luajit they distribute is exactly the same as the 'standard' one but maybe in the past it wasn't like this. dunoo <lfam>rgrau: Are you building from a git checkout? It might help if you shared the build log. <lfam>Like this: `./pre-inst-env guix build --log-file openresty` <lfam>If you are not using a git tree, then you can omit `./pre-inst-env` <rgrau>I'm using the binary version. ok, will try . <davexunit>civodul: that mailing list post really does show the massive utility of 'guix lint' <civodul>that and embedded DSLs vs. external DSLs <davexunit>civodul: oh yeah, I missed the bit where "each of the nix-files is searched for pairs of fetch-url's and hash values" <davexunit>it's interesting that many people really do seem to prefer external DSLs <fps>soo, if i observe that correctly, the gnunet GSOC project was mostly about creating guile scheme bindings for gnunet service apis? <civodul>Rémi did go a bit further, but that part is not fully baked <fps>civodul: ok, interesting approach.. i'm spending some free time trying to do anything with gnunet for a start.. <davexunit>grrr why aren't these source shebangs being patched <fps>civodul: a simpleton approach to lessening load on the hydra build server (at least networt wise) would be to to use gnunet to decentralize the serving of binaries. so the ad hoc approach would be to 1] use a sks to provide a mapping from hash-package-version -> chk <fps>brb, coffee just done <efraim>updated python-py and python-pytest locally and now python-scripttest fails to build <fps>interestingly enough gnunet seems to implement its own service manager, gnunet-arm <efraim>just how set in stone are the python packages' declared version dependency? <rekado>davexunit: are the required interpreters available at patch time? <lfam>davexunit: What do the shebang lines look like? <fps>civodul: it seems he had the same thoughts... <sneek>remi`bd was here Nov 11 at 10:41 pm UTC, saying: but I imagine it’s not what you want. <fps>use sks to map to chk <fps>civodul: bookmarked for later reference. ty <davexunit>i'm used to these being patched without issue <lfam>davexunit: That's very strange. I wonder if there is something off with the encoding or line endings? <davexunit>lfam: a-ha! the patch-source-shebangs phase never ran! <davexunit>I got confused. kodi doesn't ship a pre-made configure script and makefile, so you have to bootstrap it. <davexunit>but that bootstrapping process runs some script that needs patching first <lfam>davexunit: That'll do it! <lfam>I'm watching libreoffice's interminable patch-source-shebangs. A lot of warnings about there being no interpreter for "python" found in $PATH. "python3" works fine. Not sure about "python2" yet. <lfam>Libreoffice compilation is a waterfall of compiler warnings <orbea>why exactly are there macos x and hp-ux instructions in the INSTALL file found in the guix source tarball? <bavier>orbea: because that's the standard GNU autoconf INSTALL file I believe <davexunit>bah, kodi runs configure scripts in its bootstrap scripts <davexunit>and it seems really hard to separate them enough to fit in a shebang patching phase in. <lfam>orbea: How did you try to build it? Directly from source or did you try to bootstrap using a binary installation? <davexunit>we accidentally added a non-optional dependency on guile-json <davexunit>so the configure phase doesn't complain when it's not found <davexunit>orbea: are you building from a release tarball or the git repo? <lfam>How do you get accidental dependencies with Guix? <davexunit>lfam: this is the build system we're talking about <efraim>in python programs, dependencies for tests are native inputs? <davexunit>more generally, any package that is only needed for stuff run at build-time is a native input. <davexunit>because that software needs to be built for the build machine's architecture <efraim>is it possible to build for arm from x86? guix told me no the last time I tried <calher>i know where mitzraim is but where is efraim <efraim>I'm in Israel, as for where the tribe of efraim I'd have to pull out one of the biblical maps <efraim>i'm trying to package git-annex-remote-hubic, which I didn't realize at the beginning relied on openstack pieces <efraim>I'm now pretty comfortable with reading python requirements and rebasing various trees on each other, as long as I don't have to squash commits, which I keep on messing up :) <efraim>also I get the impression version requirements in python are a lie <bavier>efraim: do you have the rest of git-annex packaged? <efraim>but the hubic remote doesn't actually rely on git annex <bavier>I have a bunch of the git-annex package's installed. I've started working on pushing them <efraim>ah, more suprise dependencies on python-keystoneclient ***user5252` is now known as user5252
<davexunit>I really don't understand why I can't send SIGINT to processes with C-c on GuixSD in many cases <davexunit>there are many times in which I want to kill a running process but it doesn't work <orbea>thanks for pointing out that commit, got me past that issue. :) <orbea>ACTION goes back to waiting for it to compile <fps>ok, can someone spell something out for me nice and slow? ok, here it goes: <fps>if root has done guix pull, while my usual user has never done that <fps>there's no .config/guix/latest in my home dir <fps>but there is in roots <fps>what package definitions will my user's account use for ad hoc installation in .guix-profile? <davexunit>on guixsd, if the user doesn't use their own guix, then they will use the one in /run/current-system <fps>davexunit: ok, because mark_weaver insisted, that a root's guix pull will only ever affect root. <fps>that might still be true though i suppose? <davexunit>each user may run their own version of the guix client. <fps>ok.. that makes sense.. but then i still don't understand one thing <fps>i did install for example the 0.8.3 image a while ago.. then installing additional packages via the system's config triggered builds instead of binary substitutes <fps>yes.. when root does guix system reconfigure root's guix version gets used.. <fps>and since guix is part of the base system, once the reconfigure is done the user will also use the new one <fps>as long as they haven't explicitly wished for their own <fps>so mark_weaver's statement about root's "guix pull" not affecting other users (directly) was indeed correct.. <fps>it does affect them indirectly though through installing new versions via reconfigure.. <fps>mark_weaver: sorry for doubting you ;)( <lfam>mark_weaver: libreoffice-5.0.3.2 is still compiling FYI <roelj>How can I power off the computer when booting GuixSD from a USB drive? <civodul>were you looking for 'shutdown' or something? <roelj>I was looking for either shutdown or init. <bavier>I can imagine no one would oppose to using "texlive-bin" for gnuplot's input rather than "texlive"? <civodul>i didn't know Gnuplot depends on TeX Live <bavier>I'll try to make sure there's no unforeseen regressions while doing that <bavier>civodul: btw, your 'guix refresh -l' rewrite is very elegant <bavier>I had actually sat down on Friday to attempt the same, but got hung up with monads and trying (perhaps too hard) to work out corner-case handling <fps>civodul: i was looking for shutdown a few times, but i always figured i would have to read dmd docs for it ;) <fps>so i resorted to rebooting and shutting off the thing in the bios screen.. <fps>civodul: and while i got you here: i tried once or twice to get the packages pages to render, but my guile-fu was too weak.. i managed to render the rest of the webpage though. <fps>i get an error on (use-modules (www)) <fps>this is on a new checkout on this new system install <fps>fps@raksha ~/guix-artwork/website$ GUILE_LOAD_PATH=. guile <fps>sadly all my duckduckgo searches for canonicalize-path went into the void.. <fps>google seems to have some ML posts though. reading <rgrau>I'm still figthing with openresty. I tried several things but nothing useful came out of them, so I'm back with more 'random' questions: <rgrau>- its 'configure' file uses #!/usr/bin/env perl as a shebang, and I cannot find which package I should have instaled to get the 'env' binary. Also, mine wouldn't be in /usr/bin, so I think there's no use in trying to just compile the program without writing the proper .scm and do the (substitute* ...) in the file itself <rgrau>- That brought me to trying to generate the .scm file, and I saw that Nix has it already packaged. so I tried 'guix import nix ~/downloaded-nixpkgs/ openresty', but the process failed because it needs nix itself. 'guix package -i nix' and retry, and now it fails with: 'error: Nix database directory /nix/var/nix/db is not writable: No such file or directory' <rgrau>ACTION is kinda clueless where to go from here <fps>did you try to configure it without a package definition? <fps>i.e. just ad hoc freely in your home? or is there an openresty package already? <civodul>fps: looks like the Guix modules are not in GUILE_LOAD_PATH <civodul>rgrau: regarding that last part, you need "export NIX_REMOTE=daemon" <civodul>probably we should do that automatically <civodul>rgrau: the 'env' binary is in coreutils, but shebang patching happens automatically in the build environment <fps>civodul: oh ok. this seems to do the trick: GUILE_LOAD_PATH=/gnu/store/r8bs9zscc3zs4iz3y5sqn8lpm3h2d0ck-guix-latest/:. guile <rgrau>aha, thanks. with NIX_REMOTE=daemon it generated the skeleton of the file. At least I have something to keep on playing . :) <fps>or is there a more canonical way to get the GUILE_LOAD_PATH for the guix modules? <rgrau>and regarding NIX_REMOTE=daemon, if automating it is too much work, just adding it in the docs would be ok IMO <Digit>i seem to have many systemd dir on my guix sd. i dont like that. some reason they're there? can be got rid? <fps>Digit: you might have store paths from previous system generations <fps>Digit: take a look in /var/guix/profiles/ iirc <fps>um, did you say systemd? <fps>Digit: where are those directories? in the store? <Digit>i suppose another question i have after this, which i havnt looked up myself yet, is how to block packages. <davexunit>and some packages come with systemd service files <davexunit>elogind is the logind service extracted out of systemd for use with guix <Digit>:/ not ever wanting gnome, or anything systemd (~i was sure i remembered civodul in a talk saying "no systemd"), is it safe to get rid? without replacement for wicd, wud i loose connection if i did remove all traces of systemd? what else would it mess up? <davexunit>you can remove elogind from %desktop-services <lfam>Digit: Besides the elogind stuff, the other files are just unit files (the systemd equivalent of init.d scripts). They won't do anything if you are using systemd. <Digit>if i'm /not/ using it, i think u mean <lfam>Digit: I wouldn't be surprised if those store items have other init systems / process supervisors unit files as well. For example, init.d, rc.d, runit... <fps>Digit: btw: how did you get the locate db up and running? <lfam>Can I hibernate during a long-running compilation? Or is that definitely going to fail? <Digit>fps, um, as far as i know i did nothing special. just sudo updatedb, n locate "just works". <lfam>civodul: I guess that means I should enjoy the waste heat of the compilation ;) <civodul>but otherwise yes, hibernation is ok in the middle of arbitrary computations <lfam>It's pretty magical that it can "snapshot" the RAM like that :) Assuming that's what it does... <fps>Digit: oh ok, i was used to distris setting up cronjobs to do that for me. but it seems to have gone out of fashion :) and i never got around to looking it up <lfam>civodul: Yes. And I don't plan to pause it by hibernating. I just wanted to know in case I needed to. <lfam>civodul: It's been going for hours now. <civodul>lfam: that's definitely possible, i occasionally do that <civodul>and you'll even get the right timings for phases in the build log <civodul>because the thing uses a monotonic time source <lfam>Oh god, the build just failed because /tmp filled up <fps>Digit: maybe it's a good exercise to try and hack up a guixsd service definition that sets up the cronjob <Digit>fps :) i like. too often i wouldnt bother dealing with crons that i should (to prevent unecessary repetitive manual tasks, and to catch things not caught from manual neglect), maybe now with a unified system config, since it'd be "right there" when configuring other things, i might get less lazy. ;) <fps>yeah, i kind of liked that declarative sytem config approach very much in nixos already. but i like guixsd even better, the user interface is so much nicer.. <fps>found a wifi usb dongle that might even work on my laptop. so a bare metal install is in sight without having to go through the trouble of trying to build the "normal" linux kernel and fiddling with loading nonfree firmware blobs <fps>and now there's even a network-manager package (though the additional hyphen made me not find it for a while ;)) <Digit>i spent last winter/spring on nixos, long overdue, having kept pushing it to the back burner od ideas for about 7 years.. was good to get a taste of what it's like before i guix'd. <fps>hehe, i jumped on nixos pretty much immediately after i heard about it ;) but that's only a couple of months ago.. <fps>i wonder though how much the "ancient" workflow in guix might hinder its progress.. mailings lists, patches per mail.. nixos really uses the (sadly nonfree) github stuff very efficiently <fps>i got packages merged like on the second day after installing it ;) <lfam>fps: I find the mailing list works pretty well. I got a simple package merged pretty quickly, too. <lfam>I have heard other people say negative things about it, though. I prefer it, really. <Digit>there are other more freedom respecting git webs. after gitorious got usurped, i started moving my stuff from gitorious (and github) to freepost's notabug.org <fps>lfam: yeah, the optimum would be to offer different workflows <lfam>It's true. At least there is the savannah cgit for browsing on the web. <fps>the choice shouldn't be exclusive but inclusibe imho <fps>the more paths you offer people to contribute, the more they will contribute :) <lfam>Are there any web-based git interfaces that can work seamlessly with a ML? <fps>Digit: oh, i didn't know about notabug.org. checking it out. <Digit>yup, to depict the extremes, wide open many targets ready to recieve beats a single heavily rule-laden narrow apperture. <Steap_>fps: the thing is, if people use github to contribute, we're not going to read their patches <fps>Steap_: yeah, i'm aware that github is not really a possible choice, but another git web interface might be. like Digit mentioned, there are more freedom respecting choices out there <Digit>the only gripe i have with notabug.org / gogs is lack of a websearch. <Steap_>fps: yeah but then, can we review patches both there and on the ml ? <Digit>erm, project search web interface... er.. whatever the correct term is. <fps>Steap_: possibly one would have to hack it up :) <lfam>You'd have to make that web submissions had their lines wrapped <fps>yeah, it's broken by design though :) <Steap_>I don't get why people would want a system that forces them to have an ccount <fps>Steap_: you have an account with mailman btw ;) <Steap_>fps: I only need an email to contribute when using email <Digit>typically mail is the one account u need already to make other website-specific accounts. <Steap_>To send patches to Firefox, I need a mozilla account on bugzilla <fps>anyways, like i said before: an inclusive choice, not exclusive <Steap_>to contribute to OpenStack I need an account on launchpad <Steap_>fps: I think people are wrong here <Steap_>and they should just learn how to properly write code :p <fps>to contribute to guixsd i need to sign up to a ML <fps>which is an account, too <Steap_>your account really is... your mail account <lfam>Especially when you consider that your password is sent to you in plain text! <lfam>It's more like an email authenticator than an account <lfam>If I am building a package from a git checkout, is it safe to change the state of the git repo once the build has started? Or will that screw things up? <lfam>I want to hack on another branch <Steap_>if you don't rerun "make" it is ok <fps>lfam: i think so, since the package definition gets evaluated before the build start, right? <lfam>fps: You're asking me? ;) That would make sense, I suppose <fps>not a guix git checkout, but just a plain git checkout <lfam>fps: I'm not sure what you mean by the distinction <fps>ok, let's say you had a guix git clone and did ./pre-inst-env guix build ....