***gcrl2 is now known as gcrl
***gcrl is now known as pyfgcrl
<xentrac>davexunit: yes, npm has some things that have software-freedom problems, and in that sense they are not comparable to Debian <xentrac>also I think things like GNU units, Emacs, and LuaJIT are more worthwhile per line of code than yet another HTML template engine ;) <xd1le>xentrac: could you perhaps give a few examples? (about the software freedom <xentrac>I would be surprised if davexunit were wrong about them, but I have to admit I very rarely look at the "source code" I download with npm <xentrac>20:44 < davexunit> xentrac: npm only sort-of hosts free software, though. they host a lot of minified stuff, which is not source code. <xentrac>20:44 < davexunit> and they, like rubygems, make no effort to give users the source code that was used to build that binary. <xentrac>20:45 < davexunit> so I question that they have more free software than Debian. <xentrac>20:45 < davexunit> also, node packages are notorious for being tiny, and thus there are tons of them, so counting the number of packages is a poor measure for the amount of free software available. <xentrac>but I also think that npm has a huge amount of free software, outweighing Debian by sloccount, last I heard <xentrac>and some of it is actually free software whose legal status is merely slightly hazy because the authors haven't bothered to clarify it because they're hackers, not lawyers, and it sucks that we have to become lawyers in order to share information safely <civodul>'guix refresh' can refresh more, yay! <davexunit>once again, I *almost* have 'guix environment --container' done <Steap>davexunit: yeah, guix refresh is nice <Steap>though I wonder whether we could merge "guix import" and "guix refresh" <Steap>"guix refresh" mostly being some kind of "guix import --update" <davexunit>Steap: well, they serve different roles I think. <davexunit>we can add the ability to refresh software for which there is no importer. <davexunit>for example, there's some heuristics we could apply to scrape an HTTP/FTP server directory listing for version strings that are greater than what a given package has. <efraim>civodul: can't help too much atm because its kid bath time, but i just tried guix package -u and while checking for an update for gnunet got an error: https://pastee.org/7uawp <davexunit>for some reason I can't C-c in screen to kill programs <davexunit>my screenrc is minimal and doesn't do anything funky to clobber it <civodul>efraim: should be fixed now, thanks for the heads-up! <civodul>davexunit: weird, it works for me (on GuixSD) <civodul>~/.screenrc only has "defscrollback 5000" here <davexunit>I'm not sure what's up, but I've encountered this on two machines now. :/ <davexunit>ACTION packaged awscli to download some stuff from amazon s3 at work, which lead me to package 7 new python libraries <lfam>Uh oh, I seem to have lost the libgcrypt binaries <lfam>Would that have something to do with how I accidentally ran `guix package -d` as root? <lfam>Following by a garbage collection... <lfam>It certainly wasn't once I deleted all the profiles :( <lfam>But all I should need to do is re-bootstrap from the binary installation, yes? <lfam>Oh no, `make check` failed big time <lfam>No. I have still have all the non-root profiles. But I did delete the root profiles by accident and then garbage collected on purpose (needed to reclaim disk space after finally getting the bash patches to work) <davexunit>but none of those profiles have guix in them? <lfam>I can use guix. I was able to install libgrcypt and guile. <lfam>But when I try to work from my local source tree it fails. <lfam>I did that, and ran make, and they succeeded. But `make check` is NOT happy <lfam>That results in permission denied even though I own the directory tree... <lfam>I guess it's safe to chmod -R if I'm about to delete it. <lfam>Yes, I saw that. It's interesting. I never looked in there before <lfam>Okay. Should I register a gcroot as root for libgcrypt, guile, etc? <lfam>Fair enough. I'm still learning how all the parts fit together, so to speak. <lfam>The line between the dev environment and the system environment is still not totally clear to me, obviously. <efraim>qt-5.5.0 is 311Mb, 129Mb of which is examples. time to delete that as part of the build process? <bavier>efraim: could the examples be moved to another output? <efraim>shouldn't be too hard, been compiling upgrades for the past 1.5 hours though so i'll put it on my to-do list <efraim>my real problem is the two translation files from qtkeychain. they REALLY want to go in qt-5.5.0/translation <efraim>easiest would be to just delete them, but there has to be another way <civodul>efraim: i did improvements in that vein for qt-4 <civodul>you might might want to look at them <civodul>another issue with Qt is the weird default layout, which is fixed for qt-4 <efraim>civodul: thanks, i'll take a look at those <bavier>civodul: I like the new (guix upstream) <bavier>one thing I worry about re refresh is packages whose inputs change from one release to the next <bavier>many of the importers have information about package inputs <bavier>but yeah, it might be tough to automate those updates <civodul>for things like Cabal, the Nixpkgs people just regenerate the whole list of packages every time <civodul>but that means that (1) packages have to work perfectly without manual intervention, and (2) you give up on things like providing reasonable descriptions/license info, etc. <civodul>so i don't know what the best solution is <civodul>probably for PyPi, CRAN, etc., dependencies vary rarely enough <bavier>I might try my hand at a CPAN importer, and see how much trouble our perl packages give. <bavier>amongst all the other Guix things on my TODO, but shiny new thing :) <civodul>ACTION will be off-line Thursday -> Sunday <davexunit>I'll hopefully have the container stuff wrapped up. made some headway today, but running into an issue with a real life use-case at work that I want to investigate. <davexunit>a scons build script insists that permission is denied to some file when running g++ <davexunit>but then I run the same command and it works <bavier>davexunit: I think scons sets up a weird environment before it runs anything <bavier>I tried packaging some code that used scons once, then gave up. <civodul>you have to write a few lines of Python to tell it to honor the environment variables <civodul>i've been treated with scons at work :-/ <paroneayea>sorry I've been inactive btw all, despite the promises I'd be helping around now. Things have gotten do-or-die in the federation group at the w3c <paroneayea>the good news is I think we're moving towards "do" <civodul>ahah, that's rather good news i guess! <rekado>received an email announcing "stack"build <rekado>"stack is a cross-platform tool supporting Linux, Windows, and OS X, designed for reproducible builds. It manages the configuration and installation of the compiler and packages needed by your project, and then builds, tests, and benchmarks your code." <rekado>"For those of you trying to get your coworkers to use Haskell, one of the most important features of Stack is reproducible build plans. This should significantly reduce the incidence of frustration, where a coworker cannot build your successful build. For even more reproducibility, Stack ships with the ability to build inside a Docker container (and, for that matter, to generate runtime Docker images for robust deployment)." <karhunguixi>hm, quick question, are you guys able to type ^ in terminal and/or console? When i do the cursor skips one word towards the beginning. <civodul>karhunguixi: seems to work fine for me <davexunit>bam! 'guix environment --container' building some "real world" stuff <civodul>the real world stuffed in a container! <yrns>Do I ever need to "guix pull" if I'm running from git? <davexunit>I just symlink ~/.config/guix/latest to the root of my git checkout