***fkz is now known as Guest1473
<OriansJ>I wonder how many people have ever written a text editor in assembly? It was strangely easier than I though it would be... <OriansJ>A fully functional text editor in 468 lines of commented assembly :D <OriansJ>A grand total of 229 Instructions which compiles down to 916 bytes for the whole binary <calcal>joshuaBPMan_, ok just checking. looks like i'm going to reinstall debian because i broke it again because i was really enticed by a program and installed it and then my system broke. <joshuaBPMan_>calcal: Are you running guix on debian? Or are you dual booting? <calcal>joshuaBPMan_, neither. Linux panicked and I need a Xanax. <calcal>joshuaBPMan_, and I'm looking for a distro that doesn't suck, but they all do. <calcal>I really want Ubuntu, but it's nonfree. <calcal>I just want to stop having to jump through hoops. <OriansJ>calcal: What are your primary goals in selecting a distro? What absolutely must be there and what doesn't matter [Broad strokes please] <calcal>I want to be able to install any GNU/Linux program from anywhere I want without having to compile anything or worry about dependencies being out of date. <calcal>(compiling is a problem because it usually involves chasing dependencies and knowing where files go on the system) <calcal>But some things (I can't recall what) won't work because the libraries in Trisquel repos are way out of date. Some nodejs app or something, I forgot what it was. <OriansJ>calcal: unfortunately that isn't reasonable. No operating systems could satisfy that criteria. But if you are willing to relax it a bit, Arch might be what you are looking for. <joshuaBPMan_>though I'm using it right now, and it's pretty good so far. <calcal>OriansJ, Windows and OS X let you install/run any program without a problem. <calcal>I only have one computer, and it irks me that I can't try something or use it permanently because it's incompatible with my system unless I do a lot of tedious annoying work. <OriansJ>calcal: wrong, I can list several thousand programs that CAN NOT RUN on either of those. <joshuaBPMan_>neither one attempts to package software for you. Like every GNU/Linux distro <joshuaBPMan_>OriansJ: just out of curiosity, what won't run on Windows or OS X? <OriansJ>calcal: being limited to a single computer isn't a problem, because virtual machines can be utilized. Install virtualbox, qemu or even VMware if that is your preference. <calcal>See? I use a lot of weird apps. I like to know I can use them if I ever need them. I hate making a commitment to a system and then finding out later "oh shit, I can't use that program because I'd have to build so many dependencies from source first" <calcal>OriansJ, >virtual machines on libreboot x200 <joshuaBPMan_> I'm under the impression that libreboot makes vm run substantially slower. <calcal>joshuaBPMan_, every time i reboot my system, i have to disable some kernel modules before running a vm or plan to KERNEL PANIC <OriansJ>joshuaBPMan_: They provide a rom for qemu if I remember correctly <calcal>joshuaBPMan_, debian stable on the previous stable release of libreboot on an x200 <joshuaBPMan_>OriansJ: does it work well? I'm not complaining. I love the libreboot project. If it supported my laptop, I'd get it. <calcal>joshuaBPMan_, libreboot is also hacky and gross. you have to fiddle with grub to get shit to boot <calcal>i heard that changed in the latest release, but havent tried it because updating firmware is a bitch <calcal>ok, i guess i'm going to make a list of programs i always use and need and just HOPE that i can do everything i want to do with those programs for a whole year <OriansJ>calcal: what if better programs exist for doing the tasks you wish to do? <OriansJ>calcal: there is no need to think of the system in static terms, instead realize there are always things that can be improved and the software ecosystem is rather fluid. <calcal>OriansJ, considering that possibility leads me down a dark path of cluttering my system with half-configured programs and breaking it. <calcal>OriansJ, because I try to get 'the best' program that I REALLY want and then I end up not knowing enough to configure it and then I get stuck and then it just sits there cluttering the system <calcal>OriansJ, i don't want anything to change because change=>breakage <OriansJ>calcal: assuming you use debian stable and install programs via apt-get; you are not going to break the system <calcal>OriansJ, but not everything is in debian stable repos <calcal>Well, no. Configuring I2P is hard, and I was bound to make mistakes. <OriansJ>calcal: did you contact the I2P irc channel asking for help? Since they are much more familiar with that program. <calcal>OriansJ, no, because i didnt know exactly what i did. all i have is screenshots. <calcal>and i was having kernel panics before i2p <calcal>and i had a kernel panic even when i did not start i2p <calcal>so idk if it was i2p, idk what it was. i just... dont ***know! <OriansJ>calcal: if you were to just install vanilla Debian on your laptop, would you still experience kernel panics? <OriansJ>calcal: Have you run memtest or CPU burn-in to determine if the problem isn't the software but rather aging hardware dying <calcal>OriansJ, how was i supposed to know about that stuff? <OriansJ>calcal: well think of this as a wonderful chance to learn <calcal>and then the next thing will pop up in three to six months and i'll have to reinstall again because i was ignorant again and i broke it again <OriansJ>Run memtest over night, it should have ZERO errors <OriansJ>Then run CPU burn-in over night, it should have ZERO errors <calcal>OriansJ, does that even boot on libreboot? do i have to figure out on my own which grub commands to type to even get this thing to run? hsnatheosnu <OriansJ>calcal: if your grub has a seabios payload it will boot any CD <calcal>OriansJ, i read somewhere that it was bad to use it <OriansJ>calcal: You are still new on the road to Fully free software, the goal isn't to be perfect but to be better than you were yesterday. <calcal>i dont think it was a freedom thing <OriansJ>calcal: do you have high security requirements? <calcal>OriansJ, my life would be ruined if unauthorized people got to my disk <calcal>If I were to get the ultimate boot CD, I would have to (1) figure out how to put it on my multiboot and give it a working grub entry OR (2) get rid of the multiboot and have no live system to use when i have no system on disk <calcal>making grub entries is hard. not having a working system to go back to is really hard. <OriansJ>calcal: My recommendation is to first get seabios, so that you never have to worry about booting CD/DVDs again then use exclusively Tails and encrypted partitions for everything. <calcal>OriansJ, oh, those things! I stopped using them because I would burn random distros to them and never use them again, and it wasted CDs. <calcal>OriansJ, I use USB now, but it means I can only have one at a time because I only have one USB. <OriansJ>calcal: You know about USB hubs right? <calcal>OriansJ, but i mean i only have one flash drive <OriansJ>calcal: your x200 has a working CD drive right? <calcal>OriansJ, there is no slot for it <OriansJ>calcal: I strongly recommend you find a local linux users group and go to the meetings. As the assistance you require appears to be more than should take place in a IRC conversation. <muck>finally ! all lua-lgi tests succeed ... we may have a proper awesome version soon :) <muck>turns out $LG_LIBRARY_PATH is not set, neither in the builder sandbox nor within guix environment .. instead its called $LIBRARY_PATH .. im not sure whats the meaning of this and if i should patch the lgi makefile within the guix package accordingly or if that issue is better fixed elsewhere <ng0_>in case anyone tries to review some of the packages I might've send in hosted on *.psyced.org and wonders why it does not succeed downloading, there's currently an outage which is being investigated. <sneek>Welcome back ng0_, you have 3 messages. <sneek>ng0_, lfam says: Regarding gparted: I think the package is ready for roelj to push, if he wants to. There are a couple of very minor problems but they should not block packaging. <sneek>ng0_, lfam says: "Our primary goal is to un-fork the Tor Browser." <ng0_>o.o sneek, you already played me those... maybe ircii lacks the feature sneek needed. <ng0>rekado_: did you work on python2-pyqt4? <ng0>else I would try to come up with another version, I want to attempt another temporary package for pybitmessage because everthing sucks, but being able to temporary use it sucks less... writing the setup.py takes time when you don't know the project. <ng0>correction, the psyced.org files are available. <davexunit>I attempted to correct some common misunderstandings <cmhobbs>davexunit: why do you continue to lurk hn? <joolean>@mark_weaver: Hey Mark! Sorry again about those build failures. What do the Cool Kids do these days for cross-arch compatibility testing? I don’t have access to Hydra and I’m having a hard time finding a CI service that offers a 32-bit build environment. Should I just run a VM locally? <ng0>how would I escape ${DESTDIR} in substitute? <ng0>well nvm, i think i can solve this differently :) <rekado_>normally we don't need to touch DESTDIR <ng0>yeah but PyBitmessage Makefile is bad. <rekado_>one for the regex, the other for Guile strings. <ng0>okay, I think when I fix the Makefile upstream it is easier than improving my setup.py ... now I just need to figure out why pyqt4 is not found <ng0>native searchpaths or whatever i guess <ng0>why does it work for calibre though.. <muck>mh .. is there a way to use a local extracted (and modified) copy as sources for a build ? i.e. something like (source (origin (method local) [...] ? I've got a package tests successfully within a guix-environment, but same tests do a segfault when using guix build <muck>i'd like to debug those tests within the context of guix build so i want to use the modified sources without having to upload them somewhere <bavier>muck: you could define another package with a modified origin that includes one or more patches to apply <muck>right so no quick&dirty source uri=~/testme .. <alezost>muck: you can do it like this: (source (local-file "/path/to/local/source.tar.gz")) <alezost>or if it's a directory: (source (local-file "/path/to/local/source-dir" #:recursive? #t)) <alezost>note that 'local-file' is from (guix gexp) module <retroj>i'm trying to apply the ola patch from Rene Saavedra on the guix-devel mailing list, and i get this error: <retroj>$ git apply --stat ~/0001-gnu-Add-ola.patch <retroj>fatal: new file gnu/packages/ola.scm depends on old contents <retroj>anybody know what this means? the patch should create this new file. the new file is diffed against /dev/null as usual <muck>is there a way to make (patches (search-patches [...])) consider my local patches in GUIX_PACKAGE_PATH ? <efraim>I have (patches (search-patches "onionshare-fix-install-paths.patch")))) in one of my files in GUIX_PACKAGE_PATH, with onionshare-fix... in the root directory of GUIX_PACKAGE_PATH <jmd>I want to move my .guix-profile directory to a different location. How can I do that safely? <rekado_>the directory itself is located in the store. <jmd>So I don't actually need it at all? <rekado_>jmd: yes, you could do without, but I think Guix will create it the next time you install something. <rekado_>unless you add “-p /path/to/the/profile/in/localstatedir” <muck>heh interesting ... i put it into the root directory before just to test it, but i left another copy in a GUIX_PACKAGE_PATH patches subfolder which lead to pretty weird behaviour efraim thx <efraim>you could also have a patches subfolder, and then make it (patches (search-patches "patches/...patch")) <muck>yea .. just thought it belongs to module/patches you know, same as vanilla store .. but who needs consistency :p <jmd>rekado_: You're right. It keeps putting the link back again. <retroj>how can i force guix build to build a package even if it's already in the store? <jmd>Is there no way I can tell it to use a different location? <retroj>davexunit: i want to see the output of the ./configure phase <davexunit>but you could also just edit the recipe to make it trivially different <rekado_>jmd: you can use the “-p” option to tell it to use a different directory. <rekado_>e.g. “guix package -p ~/system/stuff/.guix-profile -i guile“ <alezost>muck: you can also just use (patches (list "/full/path/to/your.patch")) <jmd>But then it wont set my environment will it? <rekado_>jmd: you can set the environment with ‘source ~/system/stuff/.guix-profile/etc/profile’ <jmd>rekado_: No such file or directory <alezost>jmd: it's supposed to be the profile you want to use instead ~/.guix-profile <muck>alezost, alright cool .. though, i wanna keep my buildfiles in line with the others so that i can potentially easily submit patches :) <rekado_>jmd: for “guix package -p ~/system/stuff/.guix-profile -i guile” to work you need “mkdir -p ~/system/stuff” first. The final link is created automatically, though. <jmd>rekado_: Is there anyway I can change the default, so that I don't always have to do -p ? <alezost>jmd: no, write some shell wrapper that will add -p option <jmd>Actually I think by default it should go in $XDG_RUNTIME_DIR <muck>i probably don't have the best workflow for this yet since im such a noob .. i simply fork guix somewhere and point GUIX_PACKAGE_PATH to it and then run guix build mypackage when testing <muck>at least for this particular package (awesome 3.5.9) <retroj>in the patch-shebang phase of a build process, i get lines like this: foo.py: warning: no binary for interpreter `python' found in $PATH <retroj>how should i change the recipe so that python can be found? <bavier>retroj: yes, unless it's also needed at runtime, in which case in 'inputs' <retroj>i had it in inputs when i received those warnings <retroj>i'm not entirely sure whether it's needed at runtime.. it may be for certain features of this program <bavier>retroj: you could try using the python-wrapper package instead <bavier>the python package has no "python" interpreter, only "python3" <ng0>because PyBitmessage Makefile still sucks, I need to call part of the build-system-python in the build-system-gnu in a phase... how do I manage this if at all possible? I need it for wrapping correctly <bavier>ng0: you could (assoc-ref (@ (guix build python-build-system) %standard-phases) 'phase) or something similar <bavier>you'd need to make sure your #:modules argument is appropriate <ng0>interesting. can you give an example or is there one like this in source already? I need some more context before I can apply this correctly <bavier>ng0: I don't know of any package off the top of my head which does this <rekado_>ng0: the “node” package does something similar. <rekado_>grep for “(assoc-ref %standard-phases” <lfam>rekado_: I'm glad you have sent the prosody patch series :) This means I can finally delete my WIP-prosody branch and stop banging my head against the wall <lfam>rekado_: The changelogs are a little confusing. I think the commit title should describe the name of the package that is added. <ng0>bavier: gnome-tweak-tool <ng0>at least now qt-4 gts pulled in <ng0>lets see if this works <ng0>could be a different error about pyqt4 still not being there: <ng0>2016-08-22 20:02:31,736 - CRITICAL - <type 'exceptions.NameError'>: name 'sys' is not defined <lfam>I don't know if we have a policy or not. It just took me a while to figure out what names to pass to `guix lint` <rekado_>is anyone here interested in giving a lightening talk about Guix/Guile at the FSFE summit? <lfam>Where "a while" is about 90 seconds <rekado_>naming these things confused me, because upstream names are “luasocket”, “luaexpat”, “luasec”, etc but our package names start with “lua5.1-” … <lfam>Yeah... I don't know what the best solution is. We don't have much Lua software yet, so I think this is fine. Maybe we'll revisit it if we end up needing, for example, a lua-5.2 version of luasec <lfam>Speaking of which, I find it weird that Prosody depends on this old version of Lua. Does the Lua project still support 5.1? <lfam>Well, that's something for the Prosody project to think about. Of course we should package Prosody as-is <rekado_>lfam: I actually think I should rename the packages to have a “lua5.1-” prefix as well. <rekado_>we do the same for “python2-” packages. <lfam>rekado_: Right, that makes sense <lfam>rekado_: Speaking of Guix talks, I would *love* a talk about using GuixSD for a music workstation. I think a lot of computer musicians live in terror that their "instrument" will break due to updates and things like that <jmd>What is the correct way to set my domainname ? <retroj>when i add certain inputs to the package i'm building, i get a "match error" like: guix/packages.scm:833:12: Throw to key `match-error' with args `("match" "not matching pattern" ())' <retroj>inputs that have produced this error include ("libftdi" ,libftdi) and ("libmicrohttpd" ,libmicrohttpd) <retroj>any thoughts on what this error means? <rekado_>retroj: could you show us the complete package expression? <retroj>i also received this error when i added ("python-numpy" ,python-numpy) to native-inputs. it and python-protobuf are used for a certain build option (--enable-rdm-tests, which is commented out in the code i shared above) <retroj>(that was produced with libftdi in the inputs) <retroj>i receive the same error when i try to build another package that uses libftdi (avrdude) <lfam>retroj: Your ola package definition has unbalanced parentheses. (arguments) is never closed <lfam>I'm not sure if there are other problems <retroj>lfam: i don't see the mismatched parens.. <ng0>this can't be a pythonpath problem now... the wrapper wrapped my python2-pyqt-4 into the path.. <ng0>maybe it really is a pyqt4 problem <lfam>retroj: Line 68 should end with 3 parentheses, in order to close (arguments) <lfam>retroj: I recommend using some form of "paredit" to do this for you automatically. Many popular editors have paredit plugins <lfam>It's not fine, because it doesn't work :) <lfam>In that file, line 68 has 2 parens at the end, right? <ng0>what are qt .sip files? <retroj>lfam: is #; syntax not treated as commenting a sexp? <lfam>retroj: No, Scheme does not use # in that way <lfam>As a new Schemer, I believe that is called a "key". Corrections welcome :) <lfam>Yes, #; would make a comment, but the package definition uses #: <lfam>Or, perhaps #; would make a comment. ; alone does make a comment <retroj>; makes a line comment, but in some schemes, #; makes a sexp comment. i didn't check whether guile did, but it didn't complain <retroj>anyway, i can just use a line comment there instead and put the close paren on the next line. the error persists <retroj>and i still get the same error with avrdude, which also uses libftdi <lfam>retroj: I don't understand line 66. What are you trying to do there? <lfam>Are you trying to pass some flags to the configure script? <lfam>If so, the following should work: #:configure-flags (list "--enable-rdm-tests" "CXXFLAGS=-ftrack-macro-expansion=0") <ng0>lfam: it seems like my email server is stuck somehow... or at least I suppose so. I added the mirror for font-un because I feel like there should be a safe way to get the file. but if it's unnecessary because the noted hash is enough, than this new patch is not necessary <lfam>So, you don't mean to comment out the configure flags? <retroj>lfam: i commented about "--enable-rdm-tests" because it has some other problems that i'm working on. apparently only the CXXFLAGS=... is needed for the memory issue <lfam>retroj: Okay, I think the effect of your #; is to comment out the rest of the line, which comments out the closing paren of the configure-flags list <retroj>lfam: oddly, #; worked as expected on my computer, but to be safe, i changed it to a line comment. <lfam>retroj: I'm building the ola package from that patch, with no modifications. It seems to have worked fine. <retroj>lfam: with the ola.scm that i posted above? <lfam>So, sorry for the noise. My comments were totally off the mark <retroj>okay.. that's interesting. the match error that i'm receiving is somehow unique to my setup. <lfam>Perhaps there are other modifications in your tree? <lfam>The Vim paredit plugin does not handle the #; correctly <lfam>This plugin mis-handles lots of things. But it's better than nothing <retroj>i built guix in a git clone with the boostrap procedure. maybe i need to do a clean build? <ng0>it just needed python2-sip <ng0>ACTION prepares cleaner patches <davexunit>lfam: guile -c "(display '(foo bar #;(baz)))(newline)" <lfam>davexunit: Fascinating. Another great thing about s-expressions! <lfam>Wow, long list of questions from Bjorn on help-guix. I'll try to give some answers, but I don't know them all <retroj>i did a git clean of my guix checkout, rebuilt guix, and now i think ola is building properly <lfam>retroj: Hm, sometimes there are ABI incompatibilities in my tree, and I resort to `make clean-go` or even `make clean` <lfam>`git clean` could help too I guess <ng0>semi-functional.. but at least I get to the interface, can receive message, and can open them :) <ng0>something with ssl, probably easy to fix. <ng0>no it was just my wm <ng0>all good. tomorrow you'll get patches for pybitmessage. there are also a couple more where I did reply fixed versions in the last days 