<civodul>sneek: later tell davexunit i'd just add cgroupfs to %base-file-systems <bavier`>I was pleasantly surprised to find out that my netbook's wifi works out-of-the-box with GuixSD <bavier`>I had actually been using a wifi dongle with it for a while, just assuming the internal wouldn't work <bavier`>then I went to pack things up today and realized I had forgotten to plug it in but had been happily browsing the internet still <bavier`>on the other hand, netbook's do not make great build machines :( <zacts>so perhaps this can help me until I get FDE working fully on GuixSD <zacts>I can use GuixSD on my primary laptop <zacts>and I think I can bootstrap FDE with another distro this way for now <mdln>bavier: Which netbook? I used an Acer C720 chromebook as my only computer for nearly two years and was pretty satisfied. <zacts>(and I can share Debian 8.0 packages for my missing needed packages not in Guix that I need for school) <zacts>until I port the missing packages to Guix eventually <mdln>bavier: noice, almost pulled the trigger on one of those <Mikko->I had one of those, very good hardware support <mdln>zacts: I was considering doing the same with Arch, but I finished backing up my system today so I'm going to switch over to GuixSD direct <zacts>mdln: yeah, well my idea is rougly the following: <bavier`>I suppose it's been fine until this particular code. C++ application, and gcc has to swap to disk a lot <zacts>1) Setup FDE using Debian 8 as the core with bedrock linux 2) install GuixSD into bedrock 3) boot into FDE debian 8 4) configure GuixSD for FDE, while booted in debian 5) command bedrock to reboot into a GuixSD core. <zacts>I'll then be in a GuixSD FDE <zacts>then since GuixSD will be on my primary laptop, I'll be more able to conveniently look into contributing to Guix <mdln>bavier`: I know what you mean. I found out I can do nearly everything in a normal day on a Raspi 2 <bavier`>zacts: looking forward to the contributions ;) <bavier`>zacts: what software is it that you're missing for school? <mdln>zacts: I was going to do the same, but decided that I would be more motivated to contribute packages if I didn't have another package manager to rely on <zacts>bavier`: um.. I can't remember off-hand, but I'll check. I'm actually about to reboot and install GuixSD / Debian 8 via bedrock in a few min <zacts>haskell-platform I think is one <zacts>but I want the full platform <bavier`>zacts: I see. Yes, ghc is there, but we don't have nearly as many haskell libs as haskell-platform <bavier`>I've been trying to package git-annex <bavier`>I have about 80-90 haskell packages for that <zacts>the inital commit though for bup on my home folder took like 8 hours to do for me <zacts>but after that each commit is pretty fast, due to data deduplication <zacts>bup doesn't store everything as a blob though <zacts>so you don't have duplicated space for the binaries <zacts>but I like better than rsync in some ways, as it can track content and file / directory movements <bavier`>I'm having issues with keeping track of files accross systems, so I thought git-annex would be nice to try <bavier`>our haskell support in general needs some work <bavier`>well, I maybe shouldn't say that too soon. <bavier`>the haskell packages I've done so far have gone fairly smoothly; I just got hung up on the "doctest" package, that tries to do tricky stuff for its tests <zacts>I just wonder if haskell-platform has any non-free packages <zacts>I wonder how parabola and trisquel do it <mdln>Anyone currently working on Blender or Docker? Also iirc it is possible to install multiple sub-systems that are (fully?) isolated with Guix, is this the case? <bavier`>mdln: I don't know of anyone working on packaging blender at the moment <bavier`>regarding "multiple sub-systems", are you thinking of profiles? <bavier`>profiles allow a user to install isolated sets of packages that can then be used independently <mdln>Yes you were correct, thank you! <mdln>Ah, this years GSoC mentions that David Thompson wants to work on adding containers as an installation targer for Guix! <bavier`>mdln: he's made some great progress so far <mark_weaver>zacts: there's probably more work needed to support full disk encryption in GuixSD. <ewemoa>mark_weaver: to contribute a package, is it required to provide an email address? <iyzsong>civodul: 'guix edit' (especially when '~/.config/guix/latest' is the git checkout) and 'guix size' is awesome! <civodul>'guix size' had been on my to-do list for a long time <iyzsong>yes, when playing with it, I just find that there have a 'linux-libre-headers' with 'bootstrap-binaries-0' in it's closure. <iyzsong>for example, 'guix size cups'. and it's used by qt, icedtea7, etc. is this a optimize chance? <civodul>yes, as i wrote the linux-libre-headers -> bootstrap-binaries dep is fixed in core-updates <civodul>with 'guix size' it'll be easier to notice this kind of things, hopefully <sneek>davexunit, you have 1 message. <sneek>davexunit, civodul says: i'd just add cgroupfs to %base-file-systems <nully>i dropped from too many irc chans when we upgraded the fencepost machines <nully>thank you for your welcome back machines <nully>i need to get with MW on hydra <nully>x.x >.> so we can get that rolling <nully>the last problem we ran into was coreboot having issues unpacking the kernel <nully>it just hangs on that step.. we'll have to see if we cant get more debugging out of it <nully>i was tempted to try a non-guix packaged kernel to just make sure its nothing guix specific <davexunit>the latest guix snapshot fails to build on my machine <efraim>could that be why guix package -u had me building packages? <civodul>davexunit: mark_weaver updated the Guix snapshot yesterday <civodul>could you check the log of the previous attempt, to see which test was failing? <davexunit>I should bump up the scrollback size for the futuer <civodul>well, try ls -lrt /var/log/guix/drvs/*/*guix-0.8.3*.drv :-) <civodul>ah sorry, must be: ls -lrt /var/log/guix/drvs/*/*guix-0.8.3*.drv.bz2 <davexunit>I ran: find /var/log/guix/drvs -name "*guix-0.8.3*" <anthk_>I have a question. how can I execute a binary outside the guix store? <anthk_>jackdaniel, that's when I compile, I mean if I download a compiled binary <davexunit>downloading a binary is just an optimization <anthk_>davexunit, I mean something out of GUIX <davexunit>I don't understand. just run the binary as you normally would on any other GNU/Linux system. <DusXMT>Unless the binary is using RPATH, or hard-coded paths in dlopen () calls, it should "just work" <jackdaniel>check binary with ldd, maybe something will show <mark_weaver>anthk_: you mean a binary that was compiled by someone on a non-Guix system, precompiled for you? <mark_weaver>a lot of things can go wrong when trying to run a binary that was compiled for a typical GNU/Linux system that follows the FHS. <mark_weaver>one thing that can go wrong is that the program can't find the shared libraries its looking for. <mark_weaver>in that case, you can set LD_LIBRARY_PATH to something like $HOME/.guix-profile/lib:/run/current-system/profile/lib before running the program. <mark_weaver>(but don't set that in your whole environment; only for that program) <mark_weaver>it might also look for other things in standard locations on the filesystem. you can use strace to help find out what's going wrong. <mark_weaver>nully: hi. I tried to boot a stock Debian kernel on that machine as well. I think there's something really wrong with it. <rekado>mdln, zacts: moving from Fedora to GuixSD on my main machine (and one dedicated to audio work) gave me a lot of motivation to package things and fix issues. <nully>mark_weaver: hvae you recompiled coreboot? <nully>mark_weaver: i dont mind donig that, if that's the step we're at <mark_weaver>but yeah, I need to get going on that again. The last few weeks I've had a somewhat nasty cold which won't go away and I'm reluctant to spread it around. <nully>rather the entire office for that matter <mark_weaver>I really suspect there's a hardware problem on that machine. <mark_weaver>it's 11 years old anyway. I feel like it's been a waste of my time to spend so much time on it. <nully>it boots up fine with the non-free bios though <nully>yeah there is that huge stack too <nully>of stuff we're getting rid of <fr33domlover>davexunit, a binary also saves a lot of power, compiling just once :) <mark_weaver>fchmmr ended up buying both of those KFSN4-DRE boards that I suggested the FSF buy. he got the ones with 8GB and 4GB RAM for $130 and $100, respectively. <nully>oooh i didnt know you were going that route <mark_weaver>he has them now, and plans to add libreboot support for them <nully>mark_weaver: if that is the case, can i pull that 1.5T drive? or do you need that? <nully>the one in the hydra you are not going to use <nully>if i find a 1.5G drive.... i will find u <mark_weaver>there are two 2TB drives in that machine that civodul and I bought new. please leave those. <nully>mark_weaver: do they need to be tested still? i have a volunteer doing disk testing <nully>if you want i can pull them and have him run them though the standard test and put them back <mark_weaver>my hope is that after libreboot officially supports the KFSN4-DRE, that the FSF will be willing to buy at least one. <mark_weaver>nully: sure, if you want to test them that would be swell. <nully>yeah i'll hvae the volunteer do it <mark_weaver>nully: we tried booting that machine with the factory BIOS and that also hung during boot. <anthk_>mark_weaver, it says "no such file or directory" <anthk_>my locale is in Spanish, and LANG=C ./binary does not work <nully>mark_weaver: i will mark it as bad and put it in the recycle bin <mark_weaver>anthk_: you can use strace to find out what it's trying to access, but I don't want to spend a lot of time helping you run proprietary software, sorry. <mark_weaver>nully: make sure to save the RAM from that bad machine though. <anthk_>mark_weaver, is open source, actually <mark_weaver>anthk_: if running binaries compiled elsewhere for generic GNU/Linux systems is important to you, then GNU Guix is probably not the best choice for you, honestly. ***hopses is now known as hospes
*paron_remote still unpacking into his new place <civodul>changing houses requires a lot of energy <paron_remote>also first time we've had roommates in a long time. Lots of "whose pans are we keeping in the kitchen and which ones go into storage?" type things <rekado>ftgl's pkg-config file contains this line: "Requires.private: freetype2" <rekado>does this mean freetype2 should be propagated? <rekado>I needed to add freetype2 to the inputs of another package in order to use ftgl. <bavier`>rekado: yes, Requires is enough to merit propagation ***tschwing_ is now known as tschwinge
<rekado>bavier`: thanks for the confirmation, patch sent to the ML. ***hopses is now known as hospes
<bavier`>are there tools for guile/scheme to test code-coverage? <amz3>bavier`: what do you use to do unit tests? <amz3>oops I though it was guile <mark_weaver>bavier: the test suite used to test guile itself has some support for code coverage, but I don't know anything about it and there might be unresolved issues with it. wingo or civodul might know more. ***hopses is now known as hospes
***hopses is now known as hospes
***hopses is now known as hospes
***hopses is now known as hospes
<rekado>wishlist: I'd like to have a tool to render a dependency graph for any given package. <rekado>I'm curious to see how qsynth depends on postgresql, mysql, and ruby. <davexunit>civodul has made diagrams with graphviz for stuff like this <mark_weaver>rekado: it's quite easy to produce the input format needed by 'dot' from graphviz. <mark_weaver>so it's just a matter of writing a tool that creates the graph, and culling it down to something simple enough to comprehend. <mark_weaver>in the meantime, it's not as nice, but on the build page of hydra you can view the build dependencies and runtime dependencies. <mark_weaver>unfortunately it is a graph turned into a tree structure, so in general there are vast numbers of repeated portions. <mark_weaver>I'm glad you're here. I'm struggling to find the right place to set the guile load path for hydra-evaluator. <mark_weaver>my current hack is to set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH before running hydra-evaluator. <civodul>i fiddled with /usr/local/bin/guile so that it would not completely override the load path <mark_weaver>yeah, the most recent evaluations were actually using the packages from the version of guix installed in the 'hydra' user profile on hydra. <mark_weaver>I changed /usr/local/bin/guile to just be a symlink to the guile in hydra's profile. <mark_weaver>but I confess I'm a bit lost in this maze of hydra code. <mark_weaver>with just a symlink, the evaluations fail because of failure to load (guix config) <mark_weaver>maybe hydra-eval-guile-jobs is the right place to set it, dunno. <civodul>why is Guix installed in the profile BTW? <mark_weaver>civodul: no, hydra didn't even have a .guix-profile symlink before. <mark_weaver>well, we need to protect it from the GC somehow, and it would be good to have an easy way to update it, but if you have a better idea, I'll all ears :) <mark_weaver>using the standards guix package from guix seems to work well. <mark_weaver>the problem is just with the evaluator, using guile directly. ***DusXMT_ is now known as DusXMT
<civodul>so what was the reason again for having Guix in the profile? <mark_weaver>I don't really understand the theory behind how it apparently needs to have the system-wide installed guix in the load path to do an evaluation, but on the other hand it should be using the guix from the git checkout also. <civodul>i dunno, was it just to protect it from GC? <mark_weaver>civodul: yes, and also to have an easy way to update it. there are several symlinks that need to point to it, and if those symlinks point into the store directly they'll all need to be updatd. <mark_weaver>also, the guile load path apparently needs to have guix modules in the load path, at least to load the (guix config) module. <mark_weaver>for now, I disabled evaluations of master and core-updates, and created a new hidden jobset for testing. <civodul>until now, hydra-eval-guile-jobs would use the Guix modules from /usr/local/share <mark_weaver>right, because the 'guile' that was there before had that path hardcoded in its binary. <mark_weaver>but now we're using guile from guix, which has its private directory in the store hardcoded instead. but that doesn't include (guix config) <mark_weaver>so what I'm trying now is setting GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH to /usr/local/share/guile/site/2.0 <mark_weaver>where /usr/local/share/guile is a symlink to ~hydra/.guix-profile/share/guile <mark_weaver>and that profile has both 'guile' and 'guix' packages installed. <mark_weaver>how do you think we should help it find (guix config) ? <civodul>why not just set GUILE_LOAD_PATH=$HOME/.guix-profile/share/guile/site/2.0? <mark_weaver>I just thought that since /usr/local/share/guile had guix modules before, it should still have them just in case anything else needs them. <civodul>yeah, we won't remove them from there <davexunit>civodul: when trying to mount a cgroup file system: ERROR: In procedure scm_to_pointer: Wrong type argument in position 1 (expecting POINTER_P): "cpuset" <davexunit>"cpuset" is what I set the 'options' field to for one of the cgroup mount points <davexunit>and the 'mount' implementation calls string->pointer on 'options' <civodul>davexunit: that's with needed-for-boot? = #t right? <civodul>davexunit: the problem is that there are two 'mount' implementations, one in (guix build syscalls), and one in guile-linux-syscalls.patch for the static-link case (initrd) <civodul>anyway, the one in guile-linux-syscalls.patch expects a pointer, not a string (which is silly) <davexunit>I've gotta run, but I suppose I'll add that to my list of things to do <davexunit>I'm working towards 'guix environment --container' ;) <civodul>sneek: later tell davexunit thumbs up for 'guix environment --container'! <amz3>rekado: I am working on graph library, I mean I have it now, if you want I can build the dot output <amz3>dot output of the dependency graph <civodul>Graphviz won't work except for trivial graphs <civodul>you need something à la d3.js for the dependency graphs <civodul>i mean it needs to be interactive and to scale well <amz3>I was not thinking about the full dependency graph, only the dependency graph of a package <amz3>why not do it in d3 or something <civodul>well, it can be made smaller by looking at packages instead of derivations <amz3>hopefully sigmajs can handle the size of the graph, last resort is gephi that will. Gephi is desktop app though