IRC channel logs


back to list of logs

***fkz is now known as Guest1473
<calcal>Does Guix have Mumble yet?
<joshuaBPMan_>just a sec. I'll check
<davexunit>I tried and never completed something
<joshuaBPMan_>looks like a no.
<davexunit>it was rather difficult IIRC
<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>For those who are following stage0:
<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]
<joshuaBPMan_>You could try out
<joshuaBPMan_>it's based on ubuntu
<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>or breaking system
<calcal>(compiling is a problem because it usually involves chasing dependencies and knowing where files go on the system)
<joshuaBPMan_>trisquel is a pretty good JUST FREAKIN' work distro.
<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_>Well GuixSD is still a bit alpha/beta quality.
<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.
<joshuaBPMan_>And if you want the free'd version of Arch, try out
<joshuaBPMan_>But Windows and OS X are crap spyware.
<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?
<calcal>joshuaBPMan_, Lilypond
<joshuaBPMan_>really? hmmm. didn't know that.
<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_>does libreboot support virtual machines well?
<OriansJ>calcal: Not a problem
<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
<joshuaBPMan_>not by design of course.
<OriansJ>joshuaBPMan_: They provide a rom for qemu if I remember correctly
<joshuaBPMan_>calcal: What system are you running?
<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.
<joshuaBPMan_>calcal: ok.
<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>OriansJ, i2p, for example
<calcal>and it made linux panic
<OriansJ>calcal: So you added deb jessie main to your sources.list and used apt-get and it caused a kernel panic?
<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?
<calcal>OriansJ, i dont know
<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?
<calcal>OriansJ, but n
<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>calcal: Download this
<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
<OriansJ>calcal: Then use Tails
<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, what's a CD/DVD?
<OriansJ>calcal: they look kinda like this:
<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, i have one
<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 * 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: I thought you might be interested in this statement from a Mozilla developer: <>
<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 takes time when you don't know the project.
<ng0>correction, the files are available.
<davexunit>nixos thread on HN with some guix discussion
<davexunit>I attempted to correct some common misunderstandings
<cmhobbs>davexunit: why do you continue to lurk hn?
<cmhobbs>that place stresses me out
<ng0>news on hackernews: how is this newsworthy while it explains nothing new.
<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 :)
<ng0>ah, two \\\\
<rekado_>normally we don't need to touch DESTDIR
<ng0>thanks :)
<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 ... 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 ..
<muck>ohwell :)
<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
<muck>nice, thx :)
<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
<retroj>i manually resolved it
<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
<efraim>muck: ^
<jmd>I want to move my .guix-profile directory to a different location. How can I do that safely?
<rekado_>jmd: .guix-profile is just a link.
<rekado_>the directory itself is located in the store.
<jmd>So I don't actually need it at all?
<jmd>(the one in $HOME)
<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?
<davexunit>retroj: why do you want to do that?
<retroj>davexunit: i want to see the output of the ./configure phase
<davexunit>a build log should be saved
<davexunit>but you could also just edit the recipe to make it trivially different
<davexunit>and it will rebuild
<retroj>where would the log be?
<efraim>guix build foo --log-file
<retroj>thank you
<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
<alezost>I don't use ~/.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: warning: no binary for interpreter `python' found in $PATH
<retroj>how should i change the recipe so that python can be found?
<retroj>python in native-inputs?
<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
<retroj>ah, thanks
<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”
<rekado_>that’s similar enough
<ng0>okay. thanks
<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
<rekado_>lfam: heh :)
<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>i'm not sure...
<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
<ng0>afk for a while
<rekado_>lfam: yeah, I’ll change that.
<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?
<rekado_>lfam: I see.
<lfam>Where "a while" is about 90 seconds
<lfam>Longer than usual :)
<lfam>Not a big deal
<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> <> states "There will be no futher releases of Lua 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>here is the complete error:
<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
<retroj>lfam: looks fine to me
<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 :)
<davexunit>#;(this is a comment)
<davexunit>hmm no
<lfam>Yes, #; would make a comment, but the package definition uses #:
<lfam>Or, perhaps #; would make a comment. ; alone does make a comment
<davexunit>';' alone is a comment
<davexunit>everything after the ';' is ignored
<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
<retroj>yes. ola fails to build on low-memory systems due to a thing called macro expansion tracking.
<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
<retroj>*commented out
<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>Hm, I'm no expert
<retroj>asking in #guile
<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>pybitmessage works
<ng0>it just needed python2-sip
<ng0>ACTION prepares cleaner patches
<davexunit>lfam: guile -c "(display '(foo bar #;(baz)))(newline)"
<davexunit>prints "(foo bar)"
<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
<retroj>that must be what happened
<retroj>git clean -d -x
<retroj>(backed up my ola.scm first!)
<ng0>semi-functional.. but at least I get to the interface, can receive message, and can open them :)
<ng0>sending killed it
<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