IRC channel logs


back to list of logs

***gcrl2 is now known as gcrl
***gcrl is now known as pyfgcrl
<paroneayea> shit
<paroneayea>"Fedora opens up to bundling"
<xentrac>keverets: sloccount I think
<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
<xd1le>problems with npm)
<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>Hello Guix!
<xentrac>hello civodul!
<xd1le>xentrac: okay thanks!
<civodul>'guix refresh' can refresh more, yay!
<davexunit>wow, improved 'guix refresh'!
<davexunit>once again, I *almost* have 'guix environment --container' done
<davexunit>one test down, one to go.
<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:
<civodul>efraim: oops, my bad
<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>and it didn't use to happen.
<davexunit>used to*
<davexunit>ACTION packaged awscli to download some stuff from amazon s3 at work, which lead me to package 7 new python libraries
<civodul>heh, good
<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...
<davexunit>libgcrypt was probably not a gc root
<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
<davexunit>so you deleted everything in the store?
<davexunit>so that no 'guix' program works?
<davexunit>do you not have non-root profiles?
<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.
<davexunit>okay, so you have libgcrypt
<davexunit>so re-run configure
<lfam>I did that, and ran make, and they succeeded. But `make check` is NOT happy
<davexunit>rm -rf test-tmp
<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.
<davexunit>the store files are read only
<davexunit>test-tmp has a store
<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?
<davexunit>I do not do that.
<davexunit>I treat my dev environments as ephemeral
<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
<davexunit>yeah a new output would be great
<davexunit>let's keep slimming these beasts down
<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>nice infrastructure
<bavier>one thing I worry about re refresh is packages whose inputs change from one release to the next
<davexunit>that will be difficult to automate
<bavier>many of the importers have information about package inputs
<bavier>but yeah, it might be tough to automate those updates
<civodul>bavier: yes, that's still a problem
<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>Cabal is the worst though, AIUI
<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>*CPAN updater
<bavier>amongst all the other Guix things on my TODO, but shiny new thing :)
<civodul>hopefully it'll help a bit :-)
<civodul>ACTION will be off-line Thursday -> Sunday
<davexunit>civodul: take it easy!
<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.
<civodul>real-life use cases are hard ;-)
<civodul>holidays will be nice, i expect
<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
<davexunit>weird stuff.
<civodul>bah, don't talk to me about scons
<bavier>davexunit: I think scons sets up a weird environment before it runs anything
<civodul>an empty environment, specifically
<bavier>I tried packaging some code that used scons once, then gave up.
<davexunit>great news!
<civodul>you have to write a few lines of Python to tell it to honor the environment variables
<civodul>this is terrible
<davexunit>I'll add that to these scons scripts
<civodul>i've been treated with scons at work :-/
<civodul>(treated to scons?)
<paroneayea>treated to scones!
<civodul>heheh :-)
<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"
<paroneayea>ACTION hacking furiously
<civodul>ahah, that's rather good news i guess!
<bavier>paroneayea: good to hear
<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 Haskell projects.
<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)."
<rekado>moar docker!
<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.
<karhunguixi>at the prompt that is
<civodul>rekado: heh, interesting
<civodul>karhunguixi: seems to work fine for me
<karhunguixi>ok, thanks. Then i've done something weird.
<civodul>dunno what this could be
<davexunit>got scons to work!
<karhunguixi>oh, i've made a bad line in .inputrc
<civodul>davexunit: \\o/
<davexunit>bam! 'guix environment --container' building some "real world" stuff
<civodul>the real world stuffed in a container!
<davexunit>no disk images needed!
<civodul>no Foobarfile!
<davexunit>well, just a 'guix.scm' file ;)
<davexunit>with the project's package description
<civodul>it's the future!
<davexunit>yeah, we need to rename to Guixfile
<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
<yrns>Making sure, thanks.