***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? ***tschwing_ is now known as tschwinge
***boegel|quassel is now known as boegel
***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>the errors occur in matplotlib: cursors.MOVE : Gdk.Cursor.new(Gdk.CursorType.FLEUR), <rekado>TypeError: constructor returned NULL <rekado>does this mean that I need to set GI_TYPELIB_PATH? <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. <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>'display' happens not to be a display, but that's fine, keep going <civodul>same spirit as JavaScript regarding "error handling" <xd1le>toothbrush0: sweet. thanks so much for ghc 7.10.2 <xd1le>oh and *all* those patches too. :D <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.... <xd1le>toothbrush0: hmm i went away sorry.. i don't really know anything haskell <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>it should be -I/gnu/store/..-sdl-image../include/SDL <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 <toothbrush0>hm, okay, thanks though! i think i'm getting warmer with the -I flag, but we'll see. <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>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 <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. <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/guix-environment.sh' 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 <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>also, we're at Haskell Platform 7.10.2-a completeness! :D <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. <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>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 <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>it might also be useful to spruce up the hackage-importer <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. <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 <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. <toothbrush0>i just haven't yet investigated how it works, so i was motivated by laziness to just continue with hackage <nebg>hello everyone... has guix already a stable version ? <bavier>I've heard of it, but am not familiar with its differences <bavier>well, its introductory description sounds like it might be a better place to get distro packages <civodul>nebg: the latest release is labeled as "alpha" <civodul>nebg: however, the package manager itself is rather "beta++", i'd say <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 <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>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
<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. <civodul>davexunit: i wasn't sure either, but i can say that 'guix graph libreoffice' runs in 0m0.639s :-) <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 <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. <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>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. <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>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". <bavier>toothbrush0: it may fail if the fixup A patch contains parts of the B patch <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>i have a million patches, then after the fact separately commit minor fixups, but then have to redo them by hand using rebase edit <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. <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>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 <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 <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>davexunit: actually it works if i use $(guix build guile)/bin/guile <civodul>(maybe i shouldn't have ~/soft/bin in the first place ;-)) <civodul>mark_weaver: ah, good to see you in person! ;-) <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>the add-to-store for the "bash" file produces a zero-sized store item <mark_weaver>civodul: ext4 fileystems are prone to leaving zero-length files after a crash <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>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>(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 <davexunit>I use 'touch' in gnu/build/linux-container.scm to create files /dev to bind-mount onto <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 <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>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>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 <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>we're mounting $PWD, which includes $STORE <civodul>so in effect yes, we're mounting the thing on top of itself <davexunit>yeah, because the store happens to be in our container <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 $? <davexunit>sneek: later tell civodul thanks for helping me get to the bottom of the container issue! <iElectric>who wrote blogs.rdoproject.org/7843/guix-tox-a-functional-version-of-tox <davexunit>iElectric: that would be our very own Steap. <iElectric>Steap: just wanted to let you know I'm packaging openstack in Nix, if you might be interested <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. <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>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>not that we can't do that, it's just plain stupid <davexunit>yeah, no one really gets the whole DAG thing. <davexunit>which leads me to create bootstrapping versions of such packages <davexunit>in the case of rspec, I disabled the test suite. <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>but it's hard to argue against "but you can just bootstrap" <iElectric>davexunit: have good is ruby support in guix? <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>in guix, we wrap up everything into this 'guix import' tool and every now and then someone adds a new importer <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. <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?" <francis7>mark_weaver, I can ship you a C201 if you want? <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) <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>I'd definitely buy one to help with that <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>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>on the other hand, its EC runs free software, which is not the case for any other RYF laptop <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>does the gpu only require a blob for acceleration/3d? <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) <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. <mark_weaver>one of Paul K's early posts on the libreboot-dev ML has some links for more info on that. <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 <mark_weaver>I just recently added a wandboard quad to the build farm, so now I know the process <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>I'm hosting them at present. hosting them somewhere else will require making proper cases for them. <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. <davexunit>3d printers are rather expensive unless you use someone else's. <davexunit>for my project, I've been considering going artisinal and making it out of wood using my parent's table saw and stuff. <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>for a sturdy piece, you need some kind of machine that I do not have. <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>there might even already be some designs around. probably are. <davexunit>mark_weaver: where would you print it? the FSF? somewhere else? <mark_weaver>but there are also hacker spaces around the boston area, e.g. artisans asylum <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. <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>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>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 :) <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. <davexunit>cehteh: I was once recommended forstner bits for this. what do you think? <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 <davexunit>for polycarbonate, I used spade bits without issue. <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 <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>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 ;) <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 <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>I want to get better with electronics and building physical objects. <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>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) 
