IRC channel logs


back to list of logs

***Gama is now known as Gamayun
<bavier1>I have a local package, and if I do `./pre-inst-env guix size foo`, I get "guix size: error: no available substitute information for '...'"
<bavier1>I would have assumed 'guix size' would look in the current store too?
<efraim>have you built it yet?
<civodul>Hello Guix!
***tschwing_ is now known as tschwinge
***boegel|quassel is now known as boegel
<toothbrush0>Hi Guix!
***Xe is now known as XE
***XE is now known as Xe
<rekado>I have a package for the Python module statsmodels and most of its many tests pass, but those involving plotting via matplotlib fail.
<rekado>it's 13 out of 3157 tests.
<rekado>the errors occur in matplotlib: cursors.MOVE :,
<rekado>TypeError: constructor returned NULL
<rekado>does this mean that I need to set GI_TYPELIB_PATH?
<rekado>(for the tests)
<rekado>if so, what value should it hold?
<rekado>matplotlib says users should do "export GI_TYPELIB_PATH=~/.guix-profile/lib/girepository-1.0", but when the tests for statsmodels are run there is no profile I could conveniently use.
<rekado>or should I just disable all plotting tests...?
<civodul>rekado: is GI_TYPELIB_PATH associated with a package via a search-path?
<civodul>if so, you could add that package to the inputs
<civodul>for the sake of having GI_TYPELIB_PATH appropriately set
<rekado>the gobject-introspection package has GI_TYPELIB_PATH listed among the search paths.
<rekado>it is propagated by matplotlib, and matplotlib is an input to statsmodels.
<rekado>upon closer inspection it seems that matplotlib fails to open a display with the GTK3 backend during testing.
<rekado>in the end these displays are all to be closed again, but since opening them failed closing fails as well.
<rekado>I think it may be unrelated to GI_TYPELIB_PATH after all.
<civodul>could it be ?
<effa>rekado: given that the error is about Gdk, I would try '/gnu/store/...gdk-pixbuf-2.31.1/lib/girepository-1.0'.
<effa>You may also have to add more entries, such as 'atk', ... as mentioned in the matplotlib package source.
<rekado>the check phase starts with a couple of lines like this:
<rekado>(.nosetests-real:196): Gdk-CRITICAL **: gdk_cursor_new_for_display: assertion 'GDK_IS_DISPLAY (display)' failed
<civodul>i've always loved these warnings
<civodul>'display' happens not to be a display, but that's fine, keep going
<civodul>same spirit as JavaScript regarding "error handling"
<civodul>happy people, no stress :-)
<effa>rekado: it sounds like it's trying to access the X system. Here a possible hint:
<rekado>effa: thanks, I'll try that.
<xd1le>toothbrush0: sweet. thanks so much for ghc 7.10.2
<xd1le>oh and *all* those patches too. :D
<toothbrush0>xd1le: haha, no problem :)
<toothbrush0>i've got a few more, so we'll have the complete Haskell Platform :)
<toothbrush0>just looking for an app to test Haskell's GLUT bindings with -- know of any, xd1le ?
<toothbrush0>hm, when trying to build a package, it complains that SDL_image.h does not exist, even after adding the package sdl-image to inputs....
<toothbrush0>how can i debug this?
<xd1le>toothbrush0: hmm i went away sorry.. i don't really know anything haskell
<xd1le>that uses glut..
<toothbrush0>argh, this is rather frustrating: there's a package which depends on sdl-image, which builds fine outside of Guix, but when i try to package it using Guix, it fails on configure, saying that SDL_image.h does not exist
<toothbrush0>anyone know where i can start to figure out what the problem is?
<remi`bd>toothbrush0: how are you compiling this specific packages that depends on SDL_image ?
<toothbrush0>it's using the Haskell build system, but the configure step fails
<toothbrush0>i think i've found something, but i'm not sure, i'll explain
<toothbrush0>on my host os (Arch) it works when i install sdl and sdl_image, which both place their files in /usr/include/SDL
<toothbrush0>but in Guix of course the files are spread out in the store
<toothbrush0>but the configure stage pkg-config comes up with SDL_LIBS=-L/gnu/store/p5ksjfcs8pa87hnpfliqhlpz7dvgxvpp-sdl-1.2.15/lib -lSDL_image
<toothbrush0>which cannot work, since SDL_image is in another gnu store location
<toothbrush0>so perhaps it's an issue with the Guix sdl-image package?
<remi`bd>the include files can be found using your guix profile
<toothbrush0>this is actually what i should've pasted: SDL_CFLAGS=-I/gnu/store/p5ksjfcs8pa87hnpfliqhlpz7dvgxvpp-sdl-1.2.15/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
<toothbrush0>that's not right?
<toothbrush0>it should be -I/gnu/store/..-sdl-image../include/SDL
<remi`bd>maybe ~/.guix-profile/include/SDL
<remi`bd>(or something like that)
<toothbrush0>um, but surely .guix-profile doesn't exist when guix-builder is compiling your package?
<remi`bd>oh, I thought you were compiling using Haskell’s build system
<toothbrush0>well, yes, inside a guix package, it's specified to use 'haskell-build-system
<remi`bd>oh, okay, can’t help you
<remi`bd>*I can’t
<toothbrush0>hm, okay, thanks though! i think i'm getting warmer with the -I flag, but we'll see.
<remi`bd>good luck!
<toothbrush0>thank you :)
<toothbrush0>Why isn't the following snippet reasonable?
<toothbrush0> (arguments
<toothbrush0> `(#:configure-flags
<toothbrush0> (let* ((sdl-image (assoc-ref %inputs "sdl-image"))
<toothbrush0> (sdl-image-lib (string-append gmp "/lib"))
<toothbrush0> (sdl-image-include (string-append gmp "/include")))
<toothbrush0> ((string-append "--extra-include-dirs=" sdl-image-include)
<toothbrush0> (string-append "--extra-lib-dirs=" sdl-image-lib)))
<toothbrush0>nvm, it's %build-inputs
<civodul> <- the bundling article that davexunit referred to recently
<civodul>a bit depressing, indeed
<toothbrush0>how can i get the current build directory in a package? i have a tar.gz which contains a "cbits/macro.h" file which is not being picked up at build time
<davexunit>civodul: poking at the container tests again. I'm becoming more convinced that there is something wrong in general with the bootstrap guile in the test environment.
<davexunit>now, even if I remove the test that uses 'guix environment --container --bootstrap', the suite still fails with an 'exec format error'
<civodul>toothbrush0: "guix build foo --keep-failed"?
<civodul>davexunit: can you "rm -rf test-tmp" and try again?
<civodul>it could be that the test store was corrupt or something
<davexunit>civodul: trying
<toothbrush0>civodul: sure, but that's not really giving me anything understandable.
<toothbrush0>it's just that a weird config script doesn't believe that whatever.h exists
<toothbrush0>it's definitely in the right spot, when i inspect --keep-failed's directory
<civodul>toothbrush0: check that script's log file, the CPATH value in the 'environment-variables' file, etc.
<civodul>that might give clues
<davexunit>civodul: that fixed the failures I was seeing, but I still had the usual failure for the container test. :/
<davexunit>civodul: I pushed the latest and greatest version of wip-container
<davexunit>if you have time, you could try running 'make check TEST=tests/' and see what happens.
<rekado>effa: setting the backend to 'Agg' worked. Thank you!
<toothbrush0>civodul: solved! \\:)/ the error message was wrong, but i finally discovered how to bump up the verbosity
<toothbrush0>thanks for the inspiration though :P
<civodul>davexunit: ok, i'll give it a try
<civodul>toothbrush0: heh :-)
<davexunit>civodul: sorry for the long delays, this test is killing me.
<davexunit>everything I check looks right, yet I'm missing something.
<davexunit>something which will probably look obvious in retrospect
<civodul>i'm not sure if we'll call it "obvious" though
<civodul>we won't forget about the hours spent on it ;-)
<toothbrush0>phew! I've added a small fun platform game proving that Haskell and SDL works now :)
<toothbrush0>i'm going to stop packaging now :P
<toothbrush0>also, we're at Haskell Platform 7.10.2-a completeness! :D
<civodul>woow, congrats toothbrush0!
<civodul>quite an achievement
<toothbrush0>civodul: i'll be taking a holiday now :P
<toothbrush0>it was mostly dumb grunt work though
<toothbrush0>only a few packages were difficul
<effa>rekado: yw! :-)
<bavier>toothbrush0: thanks again for all the work. I did start looking through your patches, but didn't get a chance to make much progress yet.
<toothbrush0>bavier: no problem.
<davexunit>looks like we'll soon enough be able to compete with Nix for the love of Haskellites.
<toothbrush0>I've modified the patch subjects for the older ones, they're consistently in the "correct format" now
<toothbrush0>yeah but there's still a looming headache when the new haskell platform comes out
<toothbrush0>i'm thinking how to solve that, i'll send a mail soon
<toothbrush0>s/solve/prepare for/
<toothbrush0>because Cabal is a nightmare
<toothbrush0>all those package version dependencies are *so* fragile
<bavier>hopefully the fabled generalized-refresh can help a bit
<toothbrush0>i'm thinking of making a metapackage HaskellPlatform-$ver which points to all the right core package versions, but i'm not sure how best to handle that
<toothbrush0>then, packages can depend on a known-working HP version
<toothbrush0>i'm not sure if it'll help
<davexunit>that could work.
<davexunit>I don't really know, though, since I know nothing about Haskell.
<toothbrush0>yeah, except when a new program shows up with dependencies on library dependencies which are in different HP versions
<davexunit>but taking advantages of Guix's programmability sounds like a good route.
<bavier>toothbrush0: the 'gcc-toolchain' package is similar
<toothbrush0>i'll check it out for inspiration
<toothbrush0>it might also be useful to spruce up the hackage-importer
<toothbrush0>it works, usually, but sometimes explodes
<toothbrush0>but i knwo that cabal is a notoriously sloppy/flexible grammar
<bavier>I've noticed a few instances where cabal files with empty fields will kill the hackage-importer
<civodul>toothbrush0: if it's "explodes" as in "crashes", please send the details to bug-guix
<davexunit>toothbrush0: yeah, would be good to jot down cases where the importer fails
<rekado>we could just agree not to upgrade Haskell packages that belong to the HP. When a later version of an individual package is needed we could create a variant.
<toothbrush0>hm, i should've kept a list
<davexunit>the importers are very important for lowing the barrier to entry.
<bavier>speaking of haskell, has anyone else looked at my haskell-build-system patches?
<davexunit>rekado: we'll have to encode that somehow, so it's easy to know what packages are a part of that.
<toothbrush0>rekado: yeah, i thought of that idea indeed, but i'm worried a patch will be accepted "by accident", since we can't expect everyone to keep a taboo-list in mind of which are core libraries
<toothbrush0>davexunit: exactly
<davexunit>bavier: ping the relevant threads
<civodul>we could add (properties '(#:haskell-platform? #t)) to those packages?
<toothbrush0>and i guess we'll just have to hope that before submitting patches, people will make an effort to build all dependent packages. because that's really the risk we're guarding against: non forward-compatibility in dependency tree roots.
<toothbrush0>bavier: we should actually, probably, use Stackage as a source, instead of Hackage.
<bavier>toothbrush0: oh?
<toothbrush0>i just haven't yet investigated how it works, so i was motivated by laziness to just continue with hackage
<toothbrush0>Are you familiar with it? <>
<nebg>hello everyone... has guix already a stable version ?
<bavier>I've heard of it, but am not familiar with its differences
<toothbrush0>right, same here :)
<bavier>well, its introductory description sounds like it might be a better place to get distro packages
<toothbrush0>exactly my thoughts
<civodul>nebg: the latest release is labeled as "alpha"
<civodul>nebg: however, the package manager itself is rather "beta++", i'd say
<iyzsong>yeah, I read a thread about the difficult of haskell packageing from NixOS.
<civodul>iyzsong: yes, i enjoyed it
<civodul>basically they have a fancy highly-customizable system
<efraim>new texlive update! time to run `guix gc`
<civodul>and now they find out that it's too hard to understand
<rekado>efraim: oh, not again...
<efraim>it seems to be monthly now
<bavier>iyzsong: thanks for the link, I hadn't read it
<efraim>i think we also have a sqlite and curl upgrade pending ;)
<rekado>all those packages that use texlive for building documentation --- do we have a way to determine what features of texlive they use?
<rekado>I'm tired of downloading 3+GB to rebuild scipy.
<rekado>I wish for a texlive-minimal package.
<civodul>rekado: they should use texlive-minimal
<civodul>Andreas says it's doable
<toothbrush0>ask and you will receive? :P
<iyzsong>so many packages :-)
<civodul>efraim: re "monthly", check the output of "guix graph texlive" and you'll see why it frequently changes :-)
<ArneBab>it would be great if guix --help could include descriptions of what the commands do.
<ArneBab>as now-and-then tester I always forget how to do common tasks
<ArneBab>guix pull or guix download or guix refresh?
<iyzsong>I want to update mesa and some GNOME in weekend at the 'dbus-update' branch. I already broken some packages there :-(
***wgreenho` is now known as wgreenhouse
<efraim>wow, texlive.pdf actually looks worse than ffmpeg
<mark_weaver>ACTION would like to see our texlive broken up into many individual packages, as I heard was recently done for Nix.
<efraim>time ./pre-inst-env guix graph libreoffice | dot -Tpdf >~/libreoffice.pdf => real 5m48.052s
***wgreenhouse is now known as wgg
***wgg is now known as wgreenhouse
<toothbrush0>mark_weaver: +1
<civodul>efraim: that's the time spent in dot
<civodul>mark_weaver: i'm not completely sure; it's clear we need a texlive-minimal, but the 1000s of tiny packages may prove to be inconvenient
<civodul>or we'd need higher-level meta-packages, maybe
<toothbrush0>i forget, but i seem to recall that debian had a reasonably useful granularity
<davexunit>civodul: really? I would have expected the pipe to delimit the time command from the dot command.
<toothbrush0>like, in categories
<davexunit>something like that might be better.
<davexunit>than thousands of tiny packages.
<civodul>davexunit: i wasn't sure either, but i can say that 'guix graph libreoffice' runs in 0m0.639s :-)
<davexunit>civodul: fair enough! :)
<civodul>in no time it gives a whole lot of work to dot ;-)
<efraim>ok, time without dot was 3.14 seconds
<civodul>that's an order of magnitude more than on my laptop
<efraim>i'm running an e-350
<civodul>what's that?
<efraim>one of the early amd apus
<civodul>like from what year?
<iyzsong>a build of debian (and archlinux) source package can produce multiple packages, they have different meta data (name, description, depends). and I think the ability to having different meta data for different outputs useful for us too.
<civodul>so not that early :-)
<efraim>i picked up my laptop feb 2012, so mid 2011
<civodul>my laptop has an Intel i5, from ~2012
<efraim>from what I understand, it's only slightly more powerful than the arm chromebooks
<efraim>mine is around the celeron/pentium line from then
<iyzsong>I have a an good old thinkpad with intel T4300.
<rekado>my most powerful CPU is a Phenom II. (But since it isn't portable I mostly use the Thinkpad X200S.)
<toothbrush0>efraim: i agree with you, but i cannot find the syntax now
<toothbrush0>i've been grepping gnu/packages/*.scm, looking at the online manual, etc, even searched the ML
<toothbrush0>oh i just found it, it seems, @uref{} !
<toothbrush0>the least intuitive tag ever :P
<toothbrush0>i was grepping for "url"
<toothbrush0>So when i'm using Magit, i like to use rebase to reorder patches, but really frequently, it doesn't manage to apply a small "fixup" patch right after the patch that introduces a given term. Anyone have tips for these situations? I usually resort to dropping the fixup patch, and manually editing the original patch, which sucks.
<davexunit>just resolve conflicts and move on?
<toothbrush0>the conflict is usually about 80% the size of the original file
<toothbrush0>much more work than aborting, then editing the original patch :(
<toothbrush0>davexunit: i suspect it's when many terms have been added before the affected spot in the file; diff gets confused about line numbers. i think. i.e., too little context.
<davexunit>yes, if you are continually adding packages one after another
<davexunit>you will inevitably have trouble reordering them.
<toothbrush0>indeed, that's the situation
<toothbrush0>well, i'm not reordering the packages, but their fixups
<toothbrush0>say i've got commits adding package A, B, C, then a commit "fixup A".
<toothbrush0>it doesn't manage to reorder fixup A before B
<toothbrush0>oh well
<toothbrush0>it's not that much to do manually.
<bavier>toothbrush0: it may fail if the fixup A patch contains parts of the B patch
<toothbrush0>that shouldn't be the case
<toothbrush0>i mean, these are really tiny amendments, like typos.
<iyzsong>I often want to do the same thing, to just change that commit (or patch). does darcs work this way?
<rekado>I never have problems with fixup commits except for the case that bavier mentioned.
<rekado>you could also mark the broken commit for editing in an interactive rebase.
<toothbrush0>rekado: that's been my fallback
<toothbrush0>but it's ugly
<toothbrush0>i have a million patches, then after the fact separately commit minor fixups, but then have to redo them by hand using rebase edit
<toothbrush0>oh well
<toothbrush0>done now :P
<toothbrush0>is it possible to `guix lint` a given module?
<mark_weaver>fwiw, I've had good experience using magit interactive rebase to reorder fixup commits back to an earlier commit and merge them together. rarely have I had problems.
<rekado>It certainly does work for me. I use fixup in interactive rebase all the time.
<mark_weaver>e.g. on the wip-loongson2f branch
<toothbrush0>mark_weaver: that's precisely what's breaking for me, but probably the file has too many additions to let diff find the right context
<davexunit>yeah, I rarely encounter problems as well.
<davexunit>but there are certain unavoidable conflicts that may happen
<davexunit>since patches ultimately depend on the previous state of the system.
<toothbrush0>it's a pity git isn't aware of scheme syntax. that'd solve the problem in my case :P
<toothbrush0>bavier: i think your native-search-paths patches for GHC look rather useful, but i don't think i'm qualified to comment on their correctness.
<bavier>toothbrush0: ok, thanks for your vote
<toothbrush0>Why is running `guix lint` so incredibly slow, actually? It doesn't look like it's doing anything super-complex.
<taylan>ACTION also uses interactive rebase, fixup, reword, edit, etc. very often
<bavier>toothbrush0: some of the checks are more expensive than others
<davexunit>some even make http requests
<davexunit>I think
<bavier>yes, the "source" checker
<bavier>the "derivation" checker is also more expensive
<civodul>also the 'gnu-description' checker downloads a list of package descriptions from CVSweb
<civodul>so it's best to run 'guix lint a b c d'
<civodul>rather than 'guix lint a; guix lint b; ...'
<civodul>(now we should probably keep that in ~/.cache...)
<civodul>davexunit: i've reproduce the guix env --container test failure here
<civodul>i still have my segv with mount name spaces tho
<davexunit>civodul: urgh.
<civodul>and that's puzzling: it occurs when calling the FFI'd 'mount' procedure
<davexunit>I have no idea why it's happening. I've tried with 2 different computers.
<civodul>called from mount-file-system, called from run-container
<civodul>yeah dunno
<civodul>davexunit: actually it works if i use $(guix build guile)/bin/guile
<civodul>it fails with my ~/soft/bin/guile
<civodul>maybe i should ignore the problem
<civodul>(maybe i shouldn't have ~/soft/bin in the first place ;-))
<mark_weaver>fyi, for purposes of putting a name to a face, and for future authentication purposes, I'm the one with the red shirt in the lower left of this photograph at FSF30:
<mark_weaver>(FSF staff emeriti)
<mark_weaver>(linked from here:
<civodul>mark_weaver: ah, good to see you in person! ;-)
<mark_weaver>I hope to travel to europe eventually
<civodul>that'd be nice
<daviid>mark_weaver: yeah, cool to put a face on a name! tx
<civodul>davexunit: ooooh, the bash in the shebang of 'guile' has size 0
<davexunit>civodul: I didn't realize that was a bash script.
<civodul>yes the bootstrap Guile is a bash script
<davexunit>okay, so we're missing a bash to evaluate it
<civodul>now that's interesting
<civodul>the add-to-store for the "bash" file produces a zero-sized store item
<davexunit>civodul: oh boy.
<mark_weaver>civodul: ext4 fileystems are prone to leaving zero-length files after a crash
<davexunit>this bug goes deeper than I expected.
<mark_weaver>not sure if that's what happened here though
<mark_weaver>(for files that were written not long before the crash)
<davexunit>mark_weaver: unlikely that is the cause, since civodul and I can both reproduce this.
<mark_weaver>nevermind then :)
<davexunit>but a helpful thing to know, anyway!
<mark_weaver>recently, someone here on channel (karhunguixi?) ran into that issue, where a 'module-import-compiled' store item had zero length, and had to be manually removed in order to get things working again.
<mark_weaver>in that case, it was because he was trying to use "guix system vm" on a Libreboot X200, which doesn't support KVM
<mark_weaver>(because of bugs in the CPU related to KVM that are fixed in a microcode update)
<mark_weaver>so the system crashes when attempting to use KVM.
<mark_weaver>(I suppose there might be some X200 machines with non-buggy CPUs)
<civodul>davexunit: there are two issues: (1) mount-file-systems makes r/w bind-mounts, which is Bad, and (2) the 'touch' procedure there turns that 'bash' file into an empty file
<civodul>this corrupts the test store since it's a r/w bind-mount
<civodul>why is there 'touch' anyway?
<civodul>aah i see
<francis7>mark_weaver, ARM has no microcode
<francis7>it's all circuits
<francis7>which is a nice benefit
<davexunit>civodul: where specifically?
<davexunit>I use 'touch' in gnu/build/linux-container.scm to create files /dev to bind-mount onto
<civodul>yes, sorry for the confusion
<davexunit>files in /dev*
<francis7>mark_weaver, btw, what's the current status of GuixSD on ARM (rk3288 SoC)?
<mark_weaver>francis7: no progress so far, and I haven't yet ordered a C201.
<mark_weaver>I was hoping to find one nearby in a store, but maybe it's unrealistic.
<mark_weaver>another issue is that we really need GRUB, and it appears that GRUB only supports u-boot-based ARM systems currently.
<davexunit>civodul: I don't see where 'touch' could be used to mess up bash
<davexunit>I see it used only on /dev nodes
<mark_weaver>civodul: btw, the current main blocker on GuixSD on Loongson is that I've had trouble getting qemu to work on MIPS, at least with a kernel built for loongson.
<civodul>davexunit: it's also used in mount-file-system (singular)
<mark_weaver>QEMU fails its test suite on MIPS, so I had to disable it's test suite to even get started, but then it didn't work anyway.
<davexunit>civodul: a-ha
<davexunit>the point of that was to support mounting files, not just directories
<mark_weaver>it's possible that I need to come up with a different kernel config for MIPS meant specifically for running with qemu, but I'm not sure.
<davexunit>civodul: but I see that here, we're mounting something on top of itself?
<davexunit>and thus the touch clobbers it.
<davexunit>we should be smarter and check if file-exists? first.
<mark_weaver>I'm pondering the thought of just manually running "guix system init" to build a USB installer.
<civodul>davexunit: yes, adding file-exists? solves the problem
<civodul>but i don't fully understand
<mark_weaver>ACTION goes afk
<davexunit>civodul: the problem I ran into was that if the thing you were bind-mounting was a file, then you couldn't mount it where a directory node was.
<civodul>i see!
<civodul>we're mounting $PWD, which includes $STORE
<civodul>so in effect yes, we're mounting the thing on top of itself
<civodul>ok, problem solved? :-)
<davexunit>yeah, because the store happens to be in our container
<davexunit>I'll nuke test-tmp and retry.
<civodul>yeah, it needs to be removed first, because it's probably corrupt
<civodul>i did "./test-env guix gc -d test-tmp/fault-file" before testing
<civodul>and then: /test-env strace -f -o ,,s guix environment --bootstrap --container --ad-hoc guile-bootstrap -- guile -c '(exit 42)' ; echo $?
<civodul>ACTION needs to go
<davexunit>yes, the test passes!
<davexunit>sneek: later tell civodul thanks for helping me get to the bottom of the container issue!
<sneek>Will do.
<iElectric>who wrote
<davexunit>iElectric: that would be our very own Steap.
<mark_weaver>iElectric: iirc, it was Steap
<mark_weaver>heh :)
<iElectric>Steap: hey!
<iElectric>Steap: just wanted to let you know I'm packaging openstack in Nix, if you might be interested
<iElectric>and cool stuff with guix-tox
<iElectric>also talked to Robert Collins, which reflects the state of mind in Python packaging:
<iElectric>"use all possible dependency hell problems, because we can"
<davexunit>iElectric: oh hey! I know you. I like what you've written about Nix.
<iElectric>davexunit: hey! thanks
<davexunit>iElectric: there are so many circular dependencies in lesser package systems, especially when you take into account things they call "development dependencies"
<davexunit>I did a lot of work on RubyGems, and it's crazy there.
<iElectric>all dynamic languages
<iElectric>and in open stack
<iElectric>they have lots of circular dependencies
<iElectric>and pbr would depend on 10 packages for testing that all depend on pbr
<davexunit>I tried to package rspec, but rspec's "development dependencies" depended on rspec.
<iElectric>but because pip works in different staes (downloads all packages first, builds them, install thems)
<iElectric>they think all build systems work this way
<iElectric>not that we can't do that, it's just plain stupid
<iElectric>davexunit: yeah same here
<davexunit>yeah, no one really gets the whole DAG thing.
<iElectric>yes ^^
<davexunit>which leads me to create bootstrapping versions of such packages
<davexunit>in the case of rspec, I disabled the test suite.
<iElectric>and then of course, we need bootstrapping
<iElectric>to every problem we create there is a more complicated solution
<davexunit>I had a brief twitter conversation with the rspec maintainer who didn't understand my issue
<davexunit>granted 140 character tweets aren't a great conversation medium
<iElectric>true that
<iElectric>but it's hard to argue against "but you can just bootstrap"
<iElectric>davexunit: have good is ruby support in guix?
<iElectric>how good*
<davexunit>iElectric: the build system works well, we have ~60 gems at the moment, and an importing tool.
<iElectric>davexunit: are gems automatically generated?
<davexunit>so, low on packages, but the foundation is there to make it easy for people.
<davexunit>iElectric: we use a tool called 'guix import gem' that generates a Scheme snippet that the packager can start with
<davexunit>so it's auto-generated in that sense, but it's maintained separate from that.
<davexunit>the importer can't do everything right
<davexunit>but it's helpful
<iElectric>right, just like we have python2nix
<davexunit>yeah, and there's even bundix or something
<davexunit>in guix, we wrap up everything into this 'guix import' tool and every now and then someone adds a new importer
<iElectric>that's so neat.
<davexunit>yeah it's good stuff. I want to write an npm importer next... god help me.
<davexunit>and get a working node build system, but that's the hardest build system I've yet tried to make work.
<iElectric>do look at
<iElectric>and how it needs to be overlycomplex
<davexunit>iElectric: thanks!
<davexunit>I saw this some time ago and then forgot about it :)
<davexunit>the first step to solving any problem in guix is asking "what did nix do?"
<iElectric>yeah we have to start doing the same
<francis7>mark_weaver, I can ship you a C201 if you want?
<francis7>I'll buy 2
<francis7>and ship you one
<francis7>if you can't easily find them
<francis7>I don't care about being paid for it
<francis7>I'll be getting one for myself soon anyway
<francis7>(I want to actually use one for travelling. lighter, smaller, longer battery life - also free EC and lack of microcode is a plus)
<davexunit>wow these c201s are pretty cheap machines.
<mark_weaver>francis7: that would be very helpful!!
<mark_weaver>my funds are quite limited, and I've been on the fence about whether to get one, but if one is donated that eliminates that issue entirely.
<keverets>GuixSD on a C201?
<keverets>I'd definitely buy one to help with that
<bavier>I was thinking the same
<davexunit>francis7: do you believe that the c201 (plus libreboot and all that) could meet the RYF standards?
<davexunit>it would make for a very affordable fully free laptop.
<mark_weaver>if someone sends me a
<mark_weaver>C201, I'd be glad to work on it, or I can help someone else work on it. either way is fine.
<mark_weaver>I don't see how it could achieve RYF certification, however.
<mark_weaver>because of the wifi and gpu requiring blobs
<davexunit>I didn't know about that.
<davexunit>first I'm hearing of this machine.
<mark_weaver>on the other hand, its EC runs free software, which is not the case for any other RYF laptop
<mark_weaver>s/other //
<davexunit>I'm guessing the wireless chip is soldered onto the board so we can't do the usual trick of replacing it with an atheros chip.
<keverets>though usb wifi dongle is possible
<keverets>disable the onboard chip
<keverets>does the gpu only require a blob for acceleration/3d?
<keverets>or to work at all?
<davexunit>wonder if the gpu can be liberated.
<mark_weaver>the gpu blob is only needed for acceleration. without a blob, it still works, unaccelerated.
<davexunit>the usual deal. makes running say, GNOME, not a real option unfortunately.
<davexunit>if this laptop grows popular in the free software community, I hope that the gpu can be freed by some smart hacker.
<keverets>still works for my use case, though (simple window manager)
<davexunit>it can still do enough to be useful
<mark_weaver>someone was working on liberating it, but apparently he was treated badly by some people, and unsupported, and he became very unhappy and is now witholding his work.
<davexunit>well that's a shame to hear.
<keverets>ah, I recall reading that story
<mark_weaver>one of Paul K's early posts on the libreboot-dev ML has some links for more info on that.
<mark_weaver>(a couple of months ago, iirc)
<mark_weaver>*early posts about the C201
<davexunit>mark_weaver: do you think the c201 could be used as a build slave if we coupled it with an external storage device?
<mark_weaver>davexunit: the wandboard quad is better, because it has SATA
<davexunit>mark_weaver: same price range?
<mark_weaver>I just recently added a wandboard quad to the build farm, so now I know the process
<davexunit>nvm, then!
<davexunit>mark_weaver: could you use another? ;)
<davexunit>these things are so cheap.
<mark_weaver>davexunit: sure, it would be very helpful to add another to the build farm!
<davexunit>mark_weaver: are these arm boards colocated at the FSF or somewhere else?
<mark_weaver>at present, we are quite behind in our armhf builds
<mark_weaver>I'm hosting them at present. hosting them somewhere else will require making proper cases for them.
<davexunit>ah, I see.
<davexunit>I want to know how to make custom cases without breaking the bank.
<davexunit>I have an electronics project of my own that needs a home.
<davexunit>it's been living in a shoe box for over a year.
<mark_weaver>3d printer?
<davexunit>3d printers are rather expensive unless you use someone else's.
<mark_weaver>the FSF has 3d printeres
<davexunit>for my project, I've been considering going artisinal and making it out of wood using my parent's table saw and stuff.
<mark_weaver>sure, that works too!
<davexunit>yeah, but they worked really unreliably when I saw them used.
<davexunit>I tried to make a case from polycarbonate, but cutting it is the big issue.
<davexunit>same with acrylic.
<davexunit>for a sturdy piece, you need some kind of machine that I do not have.
<davexunit>nor have space for in a small condo.
<davexunit>basically, I wish I was handy enough to produce cases for the machines you have.
<mark_weaver>I have the skills and access to the needed equipment, but lack time
<mark_weaver>for now, it's easier just to put them half-assedly on a high book shelf :-)
<davexunit>mark_weaver: if you had the time, how would you build them?
<mark_weaver>I like the 3d printer approach, because the time spent on the 3d model could be amortized over many cases.
<mark_weaver>and shared with others, etc
<mark_weaver>there might even already be some designs around. probably are.
<davexunit>mark_weaver: where would you print it? the FSF? somewhere else?
<mark_weaver>the FSF
<mark_weaver>but there are also hacker spaces around the boston area, e.g. artisans asylum
<davexunit>been meaning to go there and see what's up
<mark_weaver>you could also cut acrylic with the laser cutter at "danger awesome" in central square.
<davexunit>I get anxiety about going to these places because I don't really know what I'm doing.
<keverets>in Toronto the library provides access to 3D printing, as well as a copy shop downtown for more urgent jobs
<keverets>would hope that idea will become more prevalent as time goes on
<mark_weaver>davexunit: fyi, you can cut metal on a table saw, with a suitable blade.
<mark_weaver>although the results would be very rough and need to be cleaned up with a grinder.
<davexunit>I could do that in my parent's garage. not sure if I want to work with metal or not.
<mark_weaver>in lieu of a real grinder, you could make due with a small grinding wheel on something like a dremel
<davexunit>acrylic or polycarbonate is appealing, but hard to cut and drill.
<davexunit>acrylic is prone to cracking, so I once tried polycarbonate as something that is tougher
<davexunit>but I had no machine to cut the sheet into sections, so I used a scoring knife, but the results were terrible.
<davexunit>which probably isn't surprising to you.
<mark_weaver>the cracking might be less of an issue if you use a blade with many more teeth (closer together), and/or by sandwiching the plastic between two pieces of wood.
<mark_weaver>(and cutting the whole sandwich)
<mark_weaver>I don't actually have experience working with acrylic
<davexunit>I'm worried cracking it while cutting the sections, and also worried about cracking it while drilling.
<davexunit>to make the various ports for things
<davexunit>for my project, many 24mm and 30mm holes are required.
<mark_weaver>oh, yeah, if you want to use acrylic for the side panel with port holes, you'd better go with a laser cutter.
<davexunit>I was able to drill polycarbonate easily enough, but I couldn't make straight, even cuts for the large sections
<cehteh>you dont need fine teeth for plastics, but they must be sharp and you need to cut slowly enough not to melt it (or use some cooling fluid)
<cehteh>and drilling needs different cutting and tip angles than normal steel drills have, much steeper
<mark_weaver>cehteh: thanks! you seem to know what you're talking about :)
<cehteh> .. these work fine too
<mark_weaver>iyzsong: fyi, librsvg and libsoup are broken on dbus-update
<cehteh>yeah i do a lot wood and plastics working, build my own kitchen and some quadcopters and so on
<mark_weaver>I'm going to cancel the rest of the builds on that branch for now.
<mark_weaver>cehteh: nice!
<davexunit>cehteh: I was once recommended forstner bits for this. what do you think?
<cehteh> there you see the geometry for a plastics drill
<davexunit>(trouble is, I can't get my hands on bits of the right size)
<mark_weaver>my dad is a highly skilled wood-worker and amateur machinist, so I've picked up a few things from him, but I don't know much about working with plastics.
<cehteh>davexunit: with cooling and when its very sharp, maybe
<cehteh>but you need a drill stand
<mark_weaver>but I can tell that cehteh is knowledgeable :)
<davexunit>for polycarbonate, I used spade bits without issue.
<cehteh>works too
<davexunit>24mm and 30mm are the ideal sizes, but I can't seem to find bits for them.
<cehteh>anything which cuts with good shavings and no much friction does
<cehteh>how thick?
<davexunit>well, I don't really know what thickness is best. the piece I tried was too thin.
<davexunit>this is for an arcade stick controller that you could put on your lap or a table, if it helps
<cehteh>the 'stufenbohrer' i shown above works well with reasonable thin material
<davexunit>(running free firmware, of course)
<mark_weaver>ACTION goes afk
<davexunit>random example from the internet:
<davexunit>my stick has the same number of buttons, a joystick, and the same exact usb port.
<cehteh>forstner bits dont work well in thin material and you need some skill for them, good people can easily make big freehand holes in wood, but if it tears out or you tilt it accidentally it gets very hot
<davexunit>I know this is off-topic from guix... sorry about that.
<cehteh>hehe you may come over to ##woodworking . .not exactly the place for that but we talk there sometimes about such stuff too
<davexunit>I don't want to derail another IRC channel ;)
<davexunit>especially one where I'm not a regular
<cehteh>anyway .. i feel good that i can at least help the people workin on guix :) ... i havnt had the time to use and work with it unfortunally
<cehteh>i think i should buy a cheap laptop drive and install guixsd on real hardware
<davexunit>it's nice to have a working guixsd system.
<davexunit>it's been very realiable for me.
<davexunit>despite missing conveniences like GNOME.
<cehteh>i tried it on kvm some time ago which gave me some trouble
<cehteh>i expect many issues are fixed by now, and i dont need gnome
<cehteh>i just didnt had the time to try again
<davexunit>not enough time in the day
<davexunit>I want to get better with electronics and building physical objects.
<davexunit>I'm only good with software.
<davexunit>I learned to solder so I could assemble my arcade stick. since I'm good at programming it was easy to hack the firmware sources to do what I wanted. but I've completely failed trying to build an enclosure.
<cehteh>haha thats what i am doing currently :D
<cehteh>building small gadgets with atmel chips, watchdog for server etc
***francis7 is now known as francis7-awol
<francis7-awol><davexunit> francis7: do you believe that the c201 (plus libreboot and all that) could meet the RYF standards?
<francis7-awol>* no video accel (needs blobs, can do software rendering without blobs)
<francis7-awol>* broadcom wifi soldered in, needs blobs (can use dongle)
<francis7-awol>* no endorsed distros available yet
<francis7-awol>colud be RYF, with a lot of work. I'm not focussing on that at the moment. My priority now is adding every other rk3288 laptop to libreboot from coreboot (there are many, mostly in google's branch of coreboot, which need upstreaming in coreboot)
<francis7-awol>or afaik