IRC channel logs

2016-09-29.log

back to list of logs

<ng0>so whonix got split into many separate packages for others to use and port.. maybe someone can make use of their torbrowser related packages to form some kind of intermediate torbrowser wrapper for us.
***lostcoff` is now known as lostcoffee
***fps_ is now known as fps
***[0xAA] is now known as Zer0Pings
***malthe_ is now known as malthe
<sapientech1>hi all, im getting a build error during the install phase: http://paste.lisp.org/+70L0/1
<sapientech1>says that i don't have permission, so wondering whether this is due to some autoconf mistake, or whether i messed up my guix
***jluttine_ is now known as jlutine
***jlutine is now known as jluttine
<civodul>heh ho
<civodul>hello!
<paroneayea>hi hi civodul
<Petter>Greetings!
<paroneayea>hi Petter
<paroneayea>Petter: whenever I see your name I think of the sfxr author, DrPetter :)
<Petter>Hello paroneayea!
<Petter>Heh, I'm not familiar with this person. *looking it up*
<paroneayea>who also wrote a nice "theory of sound" post that I think davexunit and rekado would like http://www.drpetter.se/article_sound.html
<Petter>paroneayea: Do you have some guidelines as to pronounce your nick?
<paroneayea>Petter: pair-oh-nye-ah
<paroneayea>or
<paroneayea>take "paranoia", and reverse the two center vowel sounds
<Petter>Thanks! :)
<Petter>I've always stumbled working my way through your nick.
<paroneayea>yeah it's an accident of history that I use this name on freenode... :)
<paroneayea>ACTION doesn't want to talk about it ;)
<Petter>Hehe.
<Petter>I'll remember the pronunciation by removing the e's, paronaya.
<paroneayea>:)
***kelsoo1 is now known as kelsoo
<roelj>Ugh. I included #:use-modules (guix build utils) and yet the package building fails with `ERROR: Unbound variable: mkdir-p'. What could I be missing here?
<roelj>#:use-module*
<OrangeShark>roelj: you are using mkdir-p in the package, right?
<roelj>OrangeShark: Yes
<OrangeShark>and #:use-module is declared on the top of the file?
<roelj>In a (arguments `(#:builder' block
<OrangeShark>or in the package?
<roelj>Oh.. no the package recipe.. sorry
<OrangeShark>ya, it should be in the package recipe
<roelj>Hmm, I see some packages do (arguments `(#:modules (guix build utils) \\n #:builder (begin (use-modules guix build utils)))).. Specifically the module I need.. Why would this be?
<roelj>If I do the same as those packages, it works
<OrangeShark>it could be that #:modules is newer
<roelj>Weird..
<roelj>Thanks OrangeShark. You lead me to a solution :)
<roelj>Even though I don't know exactly why it works
<civodul>hey roelj
<roelj>hi civodul!
<civodul>the #:modules things of trivial-build-system specifies which modules are to be imported in the build environment (chroot)
<roelj>Oh..! It uses Guile inside the build environment
<roelj>I think I understand
<civodul>yeah
<roelj>Woah.. the trivial build system is something I had been looking for, for a long time without realizing it
<roelj>And.. another question.. If I use (sha256 (base32 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")) then it continues building, even though the source does not have that hash!
<roelj>Is this a bug or a feature? :)
<civodul>i can't believe it!
<civodul>can you come up with a complete example?
<roelj>Ehm, of course.. I have to either open up something I've been developing offline, or come up with something new..
<roelj>I could send the package recipe that isn't buildable for you..
<roelj>right away, if that helps
<roelj> http://paste.lisp.org/+70LI
<roelj>Now let me see if I can easily publicize the source..
<roelj>Oh, actually..
<roelj>This feature is a bit different than I thought
<roelj>If you do this:
<roelj>1. Download a source tarball: guix download mirror://gnu/hello/hello-2.10.tar.gz
<roelj>2. Edit the recipe to use the local URI ((uri "file:///gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz"))
<roelj>3. guix build -K hello
<roelj>It'll build
<roelj>but is it because it's a local file that it skips the hash?
<rekado>We need more regular updates to Haskell packages.
<rekado>I just upgraded all of them because I wanted to add a new package that doesn't play nice with the rest.
<rekado>I think the hackage updater has a bug.
<civodul>rekado: funny :-)
<civodul>the substitution code is generic though, so it may be a bug in 'edit-expression'
<civodul>roelj: yes, it skips the hash in this case
<roelj>civodul: So the world is all fine and makes sense again :) Thanks
<roelj>How can I substitute* literal ( and )?
<roelj>Escaping them with a backslash doesn't seem to be allowed
<davexunit>\\\\(
<roelj>davexunit: Thanks!
<davexunit>you need to escape the backslash
<davexunit>since backslash is the escape character for strings in guile
<roelj>So the string to search for is interpreted by guile?
<davexunit>roelj: guile's strings, like any other language's strings, have a syntax that you need to follow.
<davexunit>a string is delimited by double quotes
<davexunit>but what if you want a string that contained a double quote? well you need to escape it.
<rekado>gah, haskell/hackage is awful
<davexunit>and guile's escape character is the backslash
<rekado>I cannot upgrade all packages because some important packages like zlib have strict bounds for dependencies
<rekado>and now quickcheck depends on a package that ultimately depends on quickcheck...
<davexunit>in your case, you want to write a regexp as a guile string. regexps have their own syntax and escapes, so you have two layers of escapes to deal with.
<rekado>all these people who depend on pandoc really should reconsider
<roelj>davexunit: Right. Thanks for the explanation
<rekado>pandoc stands on wobbly feet
<bavier>rekado: I think the quickcheck circle is maybe not new
<bavier>idk, the hackage testing frameworks seem to make circles a lot
<bavier>rekado: and I think we have a history of patching version bounds
<davexunit>rekado: thanks for that PSA. there's a lot of software that seems awesome until you learn about the dependency tree...
<davexunit>bavier: a lot of testing frameworks seem to have circles. rspec and cucumber, Ruby testing frameworks, also have cycles.
<bavier>it seems like a nice idea: "hey, we'll just use each other's test framework to run our own tests"
<davexunit>the cycles are allowed to happen because the standard packaging tools for these languages aren't source-based
<davexunit>so there's a disconnect between software needed at runtime and software needed to build
<bavier>ah, right
<davexunit>so cycles can happen all over the place and no one will ever notice or care.
<davexunit>and when we come along and say "you have dependency cycles" they'll scoff.
<davexunit>"but those are *development* dependencies" they'll say
<davexunit>"*you* don't need those"
<bavier>yeah, definitely not the same empowerment angle we're going for
<davexunit>it's hard to present the problem in a way that makes people think that it's not just a technical deficiency on our end.
<bavier>do we have examples of cases where we haven't been able to "easily" break the cycle?
<bavier>s/the/a/
<davexunit>bavier: for our rspec package, I just disabled the test suite.
<davexunit>which broke the cycle.
<bavier>sure, and we've used bootstrap packages for a number of the ghc packages
<davexunit>if we wanted to use an rspec that ran unit tests, we'd make this package "rspec0" or something and use it to bootstrap the true rspec package's dep graph
<davexunit>it's the only way I know of to break these cycles
<thomasd>w.r.t. development dependencies & cycles, I must admit I never thought about the issue until now...
<thomasd>and I can imagine this holds for many people. If you are not building a complete sysem from source, I suppose it's easy to miss this problem. (How does e.g. Gentoo deal with this?)
<davexunit>awareness of the issue needs to be raised, but thus far being seem to dismiss it as a problem altogether.
<thomasd>Probably not trivial to fix, once your project's cyclic toolchain is in place :)
<efraim>If I do start to work on the python-updates branch I was going to look at python-mock and some of the other early circles in our python chain
<Drakonis>I seem to be having trouble getting the usb install to boot
<Drakonis>It stops at usb core and doesnt proceed
<Drakonis>Nor is there efi support, is there?
<efraim>No efi support yet
<lfam>Speaking of wobbly feet, don't look too closely at certbot. There are, IIRC, two cycle in its dependency graph. And there are some unmaintained packages in there, too.
<lfam>Hm, it looks the unmaintained packages have some people paying attention to them now. That's good
<rekado>do we really need to propagate inputs for haskell packages?
<rekado>I'm confused about this because I see a lot of Haskell packages with only regular inputs
<rekado>does GHC embed full paths in binaries it creates?
<rekado>when I run ldd on the libs of the ghc-cereal package, for example, they contain links to other Haskell packages' libraries (such as "libHSbytestring").
<rekado>maybe propagation really isn't necessary (anymore)?
***[0xAA] is now known as Zer0Pings
<efraim>Who was it that had those 100+ Haskell patches about a year ago? They might know
<Drakonis>Is there any way to build my own guixsd image?
<rekado>efraim: about a year ago I added pandoc, but that was only about 35 patches.
<rekado>propagation is really bad.
<rekado>our ghc-network package only works by accident.
<rekado>it doesn’t actually declare the dependencies it needs itself.
<rekado>now that I’m updating stuff it breaks.
<rekado>another problem is that since ghc-network wasn’t updated I’m getting a substitute from hydra that pulls an older version of ghc-bytestring.
<rekado>this is a mess.
<brendyn>Drakonis: Yep, if you get the git repo, I think you can build a GuixSD with gnu/system/install.scm . https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html#Invoking-guix-system
<Drakonis>Hm, so i still would need a existing guix install?
<Drakonis>Because the guixsd usb install doesnt fully boot on my system
<brendyn>Drakonis: Yeah, You'll want to start with the binary install method, which is not so compicated
<brendyn>Oh, any idea why?
<Drakonis>Is there any recommended hardware release date range for libre linux?
<brendyn>I'm not sure if any such recommendation exists. I was under the impressions it's just linux minus proprietary stuff
<Drakonis>Maybe that i have a uefi setup booting on bios?
<Drakonis>Maybe i'll try another libre distro
<brendyn>I found this on the mailing list. Says it isn't supported yet https://lists.gnu.org/archive/html/guix-devel/2014-12/msg00318.html
<brendyn>Sure, Guix is still Alpha quality. Try Parabola?
<Drakonis>Eh
<Drakonis>It works very well for alpha
<brendyn>;)
<brendyn>Drakonis: I'm just running Guix on Parabola, I haven't installed GuixSD yet.
<Drakonis>I'm aware of that possibility
<Drakonis>But guixsd has all the nicer toys
<Drakonis>And parabola is just libre arch :v
<Drakonis>I'll test later to see if the libre kernel is the source of my troubles
<lfam>Drakonis: I saw you were interested in building a GuixSD image. See the commands `guix system vm`, `guix system vm-image`, and `guix system disk-image` for different varieties of that
<lfam>You'll need Guix installed and a GuixSD operating system configuration file
<lfam>There are examples in the manual
<lfam>You don't need to use the example at gnu/system/install.scm. That is merely what we use to create the GuixSD installer
<Drakonis>Hm, exciting
<Drakonis>I want to use it to generate a install image and modify it, as i cannot get it to work here
<Drakonis>So i might as well make a modified image that does
<lfam>Ah, the installer doesn't boot for you?
<Drakonis>Yes
<lfam>Well, in that case gnu/system/install.scm is actually relevant for you
<Drakonis>Fails at usb core
<Drakonis>Good
<Drakonis>Time to tweak it until it works
<lfam>It would be helpful to get a more detailed report about the failure at bug-guix@gnu.org
<Drakonis>I'll give it a shot
<Drakonis>I take it that logging doesnt work
<lfam>What do you mean?
<Drakonis>While booting
<lfam>I don't know... it would certainly be helpful
<lfam>Even a photo of the screen could be better than nothing
<lfam>I have to go. Good luck!
<ZombieChicken>Would it be better to ask technical questions about GuixSD on help-guix or guix-dev?
<myglc2>Hello Guix!
<rekado>ZombieChicken: either is fine but I have a slight preference for help-guix (unless you are preparing to write a patch).
<myglc2>Anyone out there using the guix 'r' package, aka 'R' language?
<myglc2>R package installation from CRAN fails and produces 'Peer certificate cannot be authenticated with given CA certificates' warning
<bavier>myglc2: do you have nss-certs package installed?
<myglc2>bavier: Thanks. It is installed in the system profile showing 'Outputs: '(This package is obsolete)'.
<myglc2>bavier: I installed nss-certs in user profile where r is installed... install.packages() still failing :-(
<bavier>hmmm
<bavier>I wonder if there's an environment variable you need to set to point R to the certs
<bavier>idk much about R
<myglc2>bavier: You are probably right. I used R 24x7 5 years including on my Debian servers but this is the first time on GuixSD.
<rekado>myglc2: I’m using the R package.
<rekado>but I can’t test to see which env var it needs.
<rekado>myglc2: note that if you want to use “install.packages” on a foreign distro you also need to ensure that GCC and gfortran (and more) are available from Guix.
<rekado>ACTION goes offline for a while
<myglc2>rekado: Thanks
<sharlatan>hi
<bavier>hello sharlatan
<sharlatan>Plaing with Guix configuration, have "warning: failed to install locale: Invalid argument
<sharlatan>"
<bavier>sharlatan: on guixsd?
<bavier>the warning is usually harmless if not annoying
<sharlatan> bavier: Nope, on my Fedora 23W, also trying to bind it to Emacs. Reading documentation now how to do it.
<bavier>sharlatan: there's documentation regarding locales as well