IRC channel logs

2016-03-31.log

back to list of logs

***Basstard1 is now known as Basstard`
<rain1> http://paste.lisp.org/display/311882
<rain1>I wanted to add a phase after 'install that would cd into a subdir bindings/python and do make install
<rain1>this didn't work though, says no such directory (and I tried doing it after build but no change)
<rain1>any tips on the correct way to do this?
<Jookia>ca
<mark_weaver>rain1: as you wrote it, your new phase comes after the 'build' phase, not after the 'install' phase.
<rain1>I'm trying splitting capstone and capstone-python into separate packages now
<mark_weaver>also, 'source' is going to be the filename of the source tarball (or directory for things like git checkouts), which seems like the wrong thing here.
<rain1>I've got a different error now where it's trying to copy files to python-2.7.10/lib/python2.7/site-packages/capstone
<rain1>I wonder if that's a common thing with python packages
<rain1>it fails with Permission denied though
<mark_weaver>if you want to install things into the build output directory (e.g. /gnu/store/... that will contain the result of the build) then it should be "#:key outputs" instead of "#:key source", and use (assoc-ref outputs "out") to get the file name of the "out" output
<mark_weaver>the source will be read-only in any case, so yeah
<mark_weaver>see above
<mark_weaver>oh, I see
<mark_weaver>sorry, I was bit confused. you want to run "make install" a second time from a different directory?
<rain1>well i did but it seems like splitting into two avoids that problem, like this:
<rain1> http://paste.lisp.org/display/311883
<mark_weaver>I think this is what you want: (with-directory-excursion "bindings/python" (zero? (system* "make" "install")))
<rain1>this isa tough one i might give up on this
<mark_weaver>I don't see how that can work. how will it know where to install it?
<rain1>looking at the installer script setup.py there is no clear way to make it put things in an output
<mark_weaver>anyway, it's probably better to make a separate "python" output
<mark_weaver>note that the 'capstone' package uses the 'cmake-build-system', so I guess that build system knows how to tell cmake where to install things
<mark_weaver>it's probably better to make a separate "python" output if you really want to keep these separate
<mark_weaver>although I'm not sure it's worth it
<rain1>oh there is a dest dir variable! DESTDIR so I can use that assoc-ref thing you said
<mark_weaver>DESTDIR is usually not the right hting
<mark_weaver>PREFIX is usually the right hting
<mark_weaver>*thing
<mark_weaver>and if it's a variable in the Makefile, it's usually best to add something like (string-append "PREFIX=" %output) to #:make-flags
<rain1>thanks! trying that now
<mark_weaver>the problem with DESTDIR is that the code is usually compiled to expect that installed files will be in PREFIX when the code is run
<mark_weaver>DESTDIR is used when it will be temporarily installed somewhere else, but later moved to PREFIX before the code is actually run.
<mark_weaver>e.g. when building a Debian package that will later be installed into PREFIX by dpkg
<mark_weaver>btw, the standard 'build', 'check', and 'install' phases will pass the make-flags to 'make'. if you add your own phase that runs 'make' directly, you'll need to arrange to pass the make flags as well..
<mark_weaver>see the 'build' procedure in guix/build/gnu-build-system.scm to see the default 'build' phase procedure, and emulate it if needed.
<mark_weaver>ACTION goes afk for a bit
<rain1>thanks a lot
<ng0>ACTION sent 2 or 3 updated patches to the list on the gnunet thread.
<ng0>goodnight
<rain1> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/lsh.scm#n106
<rain1>What about removing xauth from lsh?
<rain1>this would reduce its dependency tree a lot and in light of the recent openssh vuln, could be considered to harden it
***necronian_ is now known as necronian
<str1ngs>I need to autoreconf guix but its not finding my guile.m4 error: possibly undefined macro: GUILE_MODULE_AVAILABLE
<str1ngs>m4 and guile are not installed in regular location
<str1ngs>nvm I was using the wrong automake :(
<janneke> xb
<janneke>morning guilers!
<str1ngs>morning :)
<janneke>str1ngs: did you fix your problem?
<str1ngs>I did
<janneke>good :)
<str1ngs>build is way to loud :(
<str1ngs>tar xfv ?
<str1ngs>I dont think we need to see every file that is decompressed :(
<janneke>str1ngs: there is --quiet
<str1ngs>hmm I looked!
<str1ngs>thanks.
<str1ngs>hmm is it possible for the client to not block?
<str1ngs>basically hand off to the daemon? atleast for building?
<civodul>Hello Guix!
<str1ngs>hello!
<janneke>Hi civodul!
<rekado_>Hi!
<rekado_>added some "format" expressions to my procedure extending pam-root-service-type and I see that it's called multiple times on the very same pam services.
<rekado_>also, when I check for the pam-service-name and only modify '("login" "su" "slim"), then the "su" pam-service is never actually modified.
<rekado_>same for the "sudo" pam-service
<rekado_>maybe that's related to execution order.
<rekado_>the pam-services that cannot be modified are all created with "unix-pam-service"
<civodul>oh?
<civodul>could you post a reduced example?
<civodul>sorry that this is proving so cumbersome!
<civodul>rekado_: BTW, please give your opinion about the disks for the ARM machine on guix-sysadmin :-)
<str1ngs>anyone good with guile backtraces?
<str1ngs> https://gist.github.com/mrosset/d415e488f39fb2536ac6728f30995d28
<str1ngs>note this is on a s390x
<str1ngs>ahh found it :)
<str1ngs>ice-9/eval.scm:386:9: Throw to key `match-error' with args `("match" "no matching pattern" "s390x")'.
<civodul>str1ngs: the (guix build syscalls) module has an architecture-dependent bit that needs to be adjusted
<civodul>BTW, did you see https://www.gnu.org/software/guix/manual/html_node/Porting.html ?
<str1ngs>I have
<str1ngs>I'm trying to find the bit now for s390x
<str1ngs>this part is not on the porting page haha
<str1ngs>civodul: is this bit a guix constant? or linux?
<civodul>see the comment at syscalls.scm:317 :-)
<civodul>the syscall number is a Linux constant
<str1ngs>what I thought I'll check the x86_64 reference and go from there
<str1ngs> For some architectures, the order of the arguments for the system
<str1ngs> call differs from that shown above. On the score, microblaze, ARM,
<str1ngs> ARM 64, PA-RISC, arc, Power PC, xtensa, and MIPS architectures, the
<str1ngs> order of the fourth and fifth arguments is reversed. On the cris and
<str1ngs> s390 architectures, the order of the first and second arguments is
<str1ngs> reversed.
<str1ngs>sorry spam :(
<civodul>look for __NR_clone in <asm/unistd.h>
<str1ngs>this looks good. so basically its syscall-id 6?
<str1ngs>should I be concerned about the variadic order you think?
<str1ngs>err 120
<str1ngs>same as i686 since it was copied. makes sense
<civodul>"make check TESTS=tests/syscalls.scm" will tell you if you got it right ;-)
<Jookia>So Microsoft are implementing the Linux ABI in Windows 10, I wonder if this would be useful for Guix devel environments
<str1ngs>it would be
<str1ngs>is basically a linux sub system
<Jookia>They use to have a POSIX one but trashed it a while ago
<str1ngs>civodul: thanks
<str1ngs>help2man install dependency is new to 0.10.0 ?
<str1ngs>not good server is on fire! FAIL: tests/syscalls.scm
<efraim_>i've been looking at the python2-tempest-lib failures, python-tempest-lib has warnings that its depreciated, and to switch tempest_lib to tempest.lib
<efraim_>tempest-lib is at 1.0.0, tempest is at 10.0.0, both from openstack
<rekado_>civodul: oh, I knew I forgot something. I've been meaning to reply as soon as I saw the email but never got around to it.
<rekado_>these months are just so packed with work I hardly get to do anything.
<rekado_>civodul: re pam: I'll try to post something to the ML tonight.
<rekado_>Jookia: I wonder if this is another embrace-extend attempt on the part of Microsoft.
<civodul>it's a way to gather more developer mindshare, like Apple with OS X
<civodul>many "open source" developers use OS X nowadays...
<rekado_>OSX is also oddly popular here at work among scientists.
<rekado_>trying to solve their issues takes up lots of my time.
<Jookia>Since Steve Ballmer left, Microsoft loves "Linux" and "open source" now, and they're building programmer cred by being on github and releasing C# stuff
<Jookia>Containers are the cool thing so they add a Linux ABI to run containers
<jmarciano>it is just a trap for those who are not aware of what Microsoft is doing
<Jookia>I'm pleased to see they had to keep GNU and couldn't make their own userspace
<rekado_>"look, I can do all your funny linuks/development stuff and also play games! What's not to like?!"
<Jookia>The Nix devs are curious as to how this would help them
<rekado_>I had hoped that Windows would simply disappear over time, not mutate into this and stick around.
<ng0>there's still hope.. some doctor I know switched from osx to gnu linux, not to windows. those who are curious will try what's out there :)
<Jookia>I wonder what canonical is playing at this time
<ng0>(sadly it was canonical. but you have to start somewhere)
<jmarciano>Canonical, instead of supporting free software is supporting that kind of nonsense with Microsoft
<jmarciano>I guess they repackaged cygwin
<Jookia>jmarciano: this is better than cygwin, it's a subsystem
<jmarciano>sure
<jmarciano>only not for free software users
<ng0>the website of ubuntu really grew into corporate entity over the years..
<janneke>it also proves bad for #guix ontopicness :-(
<ng0>oh, right
<jmarciano>yes
<ng0>but nobody is on topic at the moment
<Jookia>Could we run Guix on Windows with this?
<Jookia>s/Could/Should/
<rekado_>Jookia: possibly. But who here would be willing to use Windows 10 to test it?
<ng0>i could theoretically test it.
<ng0>if i would want it.
<Jookia>If you need nonfree software to test it it doesn't sound like a good idea :(
<Jookia>I easily see this being turned in to a 'run your CI on Windows to do both Linux and Windows tests using Linux tools'
<rekado_>yeah, that's what I was thinking too.
<Jookia>Which would kill the current attempt to do that with Wine
<rekado_>"I only need Windows now!"
<Jookia>Much like we can write programs using both the Windows and Linux API, I think that's going to be the case on Windows too
<ng0>i hope the harddrive with my gentoo survives long enough to do a last backup.. values and noise of the harddrive are singing Pigeon John's "The Bomb" ..
<ng0>hm. someone here talked about online.net when I was looking for a new ISP for another server. Are there any bad experiences? I would add them to the closer selection of ISPs
<ng0>only downside I see in comparison is that I would have to pay with my visa card, all other IPSs allow paypal or even *coin.
<ng0>which package is the "who" command part of?
<Jookia>coreutils
<ng0>oh, thanks
<ng0>i have so many collisions in my profile, i should clean up
<ng0>Jookia: well that "who" should work like the who on other systems, yet I get no output when there's only me on the system.
<ng0>*myself
<ng0>hm. to those of you who are living in france, is online.net just very popular or is there just a slow reorder of servers? dedibox xc 2016 has no available units and I don't feel like calling international phonenumbers for just checking out when/if restock is happening.
<ng0>ah, nvm the laste questions, I just follow their social media outputs and wait for a mention on restock
<civodul>"The match function in pcre_exec.c in PCRE before 8.37 mishandles the /(?:((abcd))|(((?:(?:(?:(?:abc|(?:abcdef))))b)abcdefghi)abc)|((*ACCEPT)))/ pattern"
<civodul>(recent PRCE vulnerabilities)
<taylan>if I were a regexp engine I'd mishandle that too
<Jookia>fantastic
<civodul> http://lwn.net/Articles/681662/
<civodul>and http://lwn.net/Articles/681816/ :-)
<iyzsong>cool!
<Digit>"We are collaborating and experimenting with the Guix community" :) :)
<civodul>that's the least paroneayea could say ;-)
<civodul>davexunit, paroneayea: do you know when your LP talk will be available at https://media.libreplanet.org/u/libreplanet/tag/lp2016/ ?
<davexunit>civodul: I've been told that the video is ready to be uploaded.
<civodul>awesome!
<davexunit>which was very surprising!
<davexunit>so we might see it as soon as today
<davexunit>they uploaded 4 videos yesterday
<civodul>woohoo!
<davexunit>looks like they haven't tagged them all correctly yet, though, so I'm watching this URL instead https://media.libreplanet.org/videos
<davexunit>which has all the uploads, even ones that they probably meant to delete ;)
<Digit>ACTION loved the guixy presence at lp2016, and has been watching his own wget'd streams of the event
<wingo>grr, i forgot how to gdb guile from git in guixsd
<davexunit>Digit: what is the above quote from?
<wingo>maybe that's a good reason to figure out the load path thing...
<efraim>Bad news, my laptop started smelling like it was burning so my wife turned it off
<Jookia>thats only bad news if it wasn't burning
<rain1>what were you cooking with it?
<civodul>wingo: you mean that: https://www.gnu.org/software/guix/manual/html_node/Installing-Debugging-Files.html#Installing-Debugging-Files ?
<civodul>or the gdb plugin?
<Digit>davexunit: http://mediagoblin.org/news/mediagoblin-0.9.0-three-goblineers.html the link within one of civodul's two links there
<efraim>The fan has been really loud for a week or two
<wingo>civodul: the gdb plugin
<davexunit>Digit: ah okay!
<wingo>meta/gdb-uninstalled-guile does not work
<efraim>Looking at almost a month on the replacement fan from china
<civodul>wingo: i have things like: set auto-load safe-path ~/src/guile/libguile:~/soft/lib:~/.guix-profile/lib:~/.guix-profile/lib/debug:/gnu/store
<civodul>more than needed i guess
<civodul>(in ~/.gdbinit)
<wingo>heh
<wingo>my problem is the opposite
<efraim>I do have a donated pentium4 I'm going to try guixsd on, and some other not-dead-yet laptops
<wingo>the gdb plugin doesn't load
<wingo>preventing me from debugging anything
<wingo>i.e. meta/uninstalled-env gdb bails before getting to the prompt
<civodul>oh, because of incompatible .go files?
<wingo>yep
<civodul>ah
<wingo>could be that thigns like GUILE_SYSTEM_EXTENSION_PATH or the like also conflict
<civodul>we don't set that one in Guix
<wingo>but the first error i get is for .go files
<wingo>yeah, i think the relevant fact about guix is that it actually includes the guile plugin
<civodul>in the meantime you could add "unset GUILE_LOAD_COMPILED_PATH" in meta/gdb-uninstalled-guile
<wingo>so the problem is not guix-specific
<civodul>ok
<wingo>civodul: heh, how would that help, i need to debug guile from git :)
<wingo>guile 2.2
<wingo>anyway, just grumbling :P
<rain1>I have /gnu/store/n20i0s96p29vkl07vlvxli5xql3m3hgi-linux-libre-4.5
<civodul>wingo: it should help because then, neither guile-2.0-in-gdb nor guile-2.2-in-the-inferior are going to stumble upon incompatible .go files, no?
<rain1>btw the debian-reproducible kernel is not reproducible - I am trying to learn to set up debian dev environment to hopefully help that
<wingo>civodul: but guile 2.0 in gdb would load its .scm files from guile 2.2 from git
<wingo>due to GUILE_LOAD_PATH
<wingo>which would be bogus
<civodul>ah right
<civodul>bummer
<civodul>we should talk with the Guile maintainers
<wingo>hehe ;-)
<civodul>:-)
<alirio>civodul, about freefont-ttf comment removed: icecat has .zip binaries too, but i think in both cases the binaries are not useful for guix
<wingo>i think i have to start gdb then do follow-fork on bash meta/guile
<civodul>might work
<alirio>civodul, python-2 has a eol determined
<wingo>yep, "set follow-fork-mode child; file bash; run meta/guile" <- works
<civodul>alirio: well, if no other GNU package uses .zip files for source, then what about making it (the removal of .zip from the regexp) a separate patch?
<civodul>alirio: "eol determined"?
<alirio>2020, https://www.python.org/dev/peps/pep-0373/
<rain1>I wonder what hash lfam got?
<civodul>alirio: ok, and why do you mention it? :-)
<alirio>civodul: you asked about changing the default python of fontforge at https://lists.gnu.org/archive/html/guix-devel/2016-03/msg01369.html
<janneke>how do i add an option to ncurses' configure, only for target=i686-w64-mingw32
<janneke>without the world wanting to rebuild?
<civodul>alirio: i know; so are you suggesting that Fontforge should be using Python 3 because Python 2 will reach end of life in 2020?
<civodul>please be explicit ;-)
<alirio>yes, i think python 3 should be the default
<civodul>but just for that reason?
<civodul>we have tons of Python 2 packages already
<alirio>yes, it is the default python atm
<rain1>did anyone else try compiling linux?
<civodul>surely we'll remove them by 2020, but for now, i wouldn't worry
<civodul>(i'm no python expert though)
<ng0>3 years left
<ng0>eh
<ng0>4
<ng0>plenty of time and development :)
<civodul>alirio: the other question is my message was: why wouldn't fontforge-with-python3 work?
<alirio>say i want to write a _new_ fontforge script, i should write it with python 3
<civodul>sure
<cm2>hi - quick question about .so and generations
<cm2>if i have different generations of teh same software linking to different .so
<alirio>civodul, this i will add as a inline comment: python 3 support commits aren't yet released in 20120503
<cm2>are the .so stored in which one?
<cm2>and the ld path changed accordingly?
<cm2>s/which one/each one/
<civodul>alirio: but we build fontforge against python 3 already, right? does that mean that python support is actually missing?
<alirio>python 3 support is missing from freefont
<civodul>oh, i think i understand now
<civodul>:-)
<civodul>so the patch you sent is fine, but the comment should say (roughly) that freefont uses a Python 2 script for Fontforge, so we have to use a Python 2-enabled Fontforge
<civodul>sounds good?
<civodul>sorry, i hadn't understood the whole equation
<alirio>"python 3 support commits aren't yet released in 20120503, so freefont needs python 2 support in fontforge"
<civodul>sounds good!
<civodul>damn, this hydra mirror works great, congrats ;-)
<civodul>ACTION just installed LO in a glimpse
<davexunit>which mirror?
<civodul>mirror.hydra.gnu.org
<davexunit>is this a new mirror or the existing one?
<civodul>it's still the same one :-)
<davexunit>oh cool
<civodul>dunno it seems to be working well these days
<davexunit>glad it's zippy
<civodul>so i thought it was appropriate to self-congratulate
<davexunit>:)
<ng0>so i am now waiting for new servers to arrive to order, i hope to provide a large enough guix cache (around 300GB maybe) and also experiment with dht+pex distribution and gnunet based mirror, also gets onion service like most of the things I run.
<civodul>FWIW the cache takes currently less than 20G at mirror.hydra.gnu.org, which is supposedly what everbody uses now
<davexunit>nice!
<ng0>i'm looking at some way to provide a long lived back catalogue, cleaning out older packages once it hits a certain size. maybe i don't think about a cache?
<ng0>so like $now + xy weeks before
<davexunit>civodul: it seems wrong to me that 'herd restart foo' will stop foo and its dependents, but then only restart foo.
<civodul>agreed
<civodul>it's annoyed me occasionally
<davexunit>so you'd accept a patch? :)
<civodul>of course!
<davexunit>ACTION adds to TODO list
<civodul>you can always file a bug in the meantime, so it doesn't get lost
<davexunit>wasn't sure if it was as-designed for a reason I didn't yet understand
<davexunit>does shepherd use bug-guix or its own bug tracker?
<civodul>i don't think there's a good reason for this behavior
<civodul>bug-guix
<davexunit>k
<civodul>it should restart the dependents that were already started before
<civodul>(as opposed to all the dependents)
<davexunit>civodul: yes
<alirio>civodul: i think you misread something in https://lists.gnu.org/archive/html/guix-devel/2016-03/msg01337.html; mame isn't in free distros, parabola has a package to remove all emulators
<civodul>fine, but that doesn't change the conclusion
<civodul>see also the discussion on gnu-linux-libre
<davexunit>MAME in particular isn't in free distros because until earlier this month it *wasn't* freely licensed.
<davexunit>or rather, it couldn't have been included in a free distro even without considering the topic of emulators.
<civodul>ok, that was very good reason
<davexunit>but now it is free software. they went through a great deal of effort to relicense all code that had a noncommercial license.
<davexunit>we should probably audit the next release they make to ensure that there is nothing else that could cause a license issue.
<rain1>maybe someone should bug them to make a 'make install' target
<davexunit>that would definitely be nice ;)
<alirio>davexunit: yeah, i'm warning because i think guix would be the first distro to include it and so do the audit; guix don't need to wait for a upstream release first
<rain1>it's just a one liner, but it would make the guix package shorter
<civodul>so extra care must be taken when auditing this package's license, indeed
<davexunit>I think any problems we find would likely be mistakes, and not intentional.
<davexunit>the project has an explicit intent to be fully free moving forward.
<civodul>ok
<ng0>does the build system also remove .gitignore in addition to .git/ with git checkouts?
<davexunit>ng0: because they are non-deterministic. I don't think it removes .gitignore
<davexunit>but the contents of .git depends upon when the repository was cloned, thus nondeterministic.
<ng0>i think of packaging https://github.com/bittorrent/bootstrap-dht , x11 license. maybe it's useful for someone.
<mattlea>Hi all, I've just managed to install guix on my TP, nice job!
<mattlea>However, it seems as though, /bin/bash doesn't exist so none of my setup scripts seem to work
<ng0>you can use /bin/sh
<mattlea>I just wondered whether my scripts should be more portable (i.e. not assume that bash is located at /bin/bash) or if this could be a guix problem
<mattlea>ng0: My scripts rely on some bash extensions, I'm afraid.
<davexunit>mattlea: /bin/sh is the only thing in /bin, and there is no /usr
<davexunit>shebangs are often not portable
<davexunit>since Guix doesn't conform to the FHS, scripts written with the assumption of being run on FHS systems will not run.
<mattlea>davexunit: so my best option would be to recode the shebang in my scripts for use on Guix?
<alirio>mattlea: you can make a wrapper
***vasile_ is now known as vasile
<mattlea>alirio: Would you be able to elaborate? Sorry.
<davexunit>mattlea: in my projects, I use autoconf to determine the absolute paths to binaries so that they always work
<davexunit>the Guix source also uses this method to determine where binaries are at configure time
<alirio>mattlea: something like "#!/bin/sh bash myscript", with a newline, this way bash will be taken from $PATH
<ng0>I am misformating things.. one level of parens too much in the substitute* section? https://ptpb.pw/R0kN
<rekado_>ng0: don't use string-append for the pattern
<rekado_>you can break strings and escape the linebreak
<rekado_>ng0: also, this substitution looks a little big
<ng0>hm, so I could use the old (350 characters on one line) substitute line, but break it somehow?
<rekado_>couldn't you just replace "/opt/psyced"?
<ng0>yeah I just need to insert one thing
<ng0>no
<rekado_>oh, in that case you could just anchor the expression on "exec ", no?
<ng0>i need this exec ${CONFIG_SHELL} ./configure-do
<ng0>it's just the beginning to run into more issues later :)
<rekado_>your build phase is wrong
<ng0>how would that work, anchoring an expression? any examples i could look for?
<rekado_>you have the lambda inside of the let.
<taylan>ng0: remove the ` and ,. they are unnecessary since substitute* is a macro...
<taylan>and after evaluating the string-append parts, it becomes: (substitute* <file> ((<string1>) (<string2>))). this doesn't look right; the correct format is (substitute* <file> ((<string1> <replacement1>) (<string2> <replacement2>) ...))
<taylan>er, no, I'm wrong
<taylan>ACTION didn't package stuff for way too long
<ng0>hm.. I would prefer if there was some kind of "inser n just between a and c" instead of substitute.
<ng0>rekado_: thanks. i try to fix that later
<taylan>the correct format is (substitute* <file> ((<regexp1> <match_group> ...) <replacement1>) ((<regexp2> <match_group> ...) <replacement2>) ...)
<taylan>ng0: so remove the parens around your second string
<ng0>okay
<rain1>"Parabola has unprivileged package management thanks to Guix"
<taylan>ng0: and refraining from using string-append as rekado_ said should make it marginally more readable
<ng0>hm
<taylan>rain1: heh. sadly it means duplicating all the base packages across Parabola and Guix.
<ng0>i'll look for some occurence of escaping line breaks
<taylan>ng0: "foo\\<newline>bar"
<taylan>the <newline> should be literally a newline i.e. line break
<taylan>so the backslash is the last thing on a line. this will cause the lines to be joined together.
<ng0>ah
<ng0>i thought i had to escape the backslash. okay, thanks
<ng0>so this way I can just use the old substitute
<taylan>note that if you indent the second (or third, fourth...) line, the spaces that make up the indentation will be part of the string
<taylan>this might not matter if the string is not for humans to later look at in output
<ng0>it shouldn't be
<taylan>but if it's important not to have superfluous spaces in the string, you'd have to keep the following lines unindented
<taylan>(the r7rs-wip branch of guile has an option to enable "hungry newline escaping" that makes the backslash eat any spaces after the line break as well. I hope this will become standard practice one day.)
<ng0>i guess that would work too. i don't know if I would introduce errors, i have to fix some more parts of the two packages later, like how to disable psyced -u which reconfigures and updates through git
<paroneayea>civodul: re: "that's the least paroneayea could say"; Deb wrote the post, not me! :)
<paroneayea>though I did send her an outline
<paroneayea>but yes
<paroneayea>I was happy to mention Guix in the post; after all we do have a guix-env.scm now :)
<paroneayea>I hope to get 0.9.0 in Guix proper.
<ng0>cool
<davexunit>ACTION sees that 5 libreplanet videos were uploaded today
<davexunit>ACTION hopes for the Guix one to be uploaded, too
<ng0>how would I fix the build phase? just remove the (lambda _) part and/or alter the first lambda? simply removing the 2nd did not work
<taylan>ng0: put an additional closing paren on the (let* ((out ... line, and remove one from the end of the lambda
<taylan>(and then re-indent the code :)
<taylan>let takes a "table" of variable bindings so to say. (let ((<var1> <val1>) (<var2> <val2>) ...) <body of code>)
<civodul>paroneayea: even better :-)
<ng0>ah :)
<bavier>alirio: I like your font build patch
<bavier>I was just doing some work like that last night
<bavier>I was wondering about the python scripting support in our fontforge, but didn't get to that point yet
<janneke>i'd like to make a small modification to ncurses, only for one cross target
<janneke>something like: http://paste.lisp.org/display/311963
<janneke>i cannot seem to make any change without triggering a full rebuild
<civodul>janneke: Bash depends on ncurses, and everything depends on Bash
<alirio>bavier: so you had issues with it?
<davexunit>janneke: define a new variable with your customized ncurses
<davexunit>that way you can test without changing the entire dependency graph
<janneke>civodul: i understand that...so what i would like is *only* make that mod for the i686-w64-mingw32 target
<davexunit>janneke: you've changed the build script, though.
<davexunit>you can't know until build time what platform you're building for
<bavier>alirio: I was working on adding the fantasque-sans-mono font, and wanted to build it from source
<janneke>yes, so my question is: do we have a provision to make a platform-specific change only?
<bavier>it requires the python scripting support in fontforge, but I have yet only had time to package some other dependencies
<rain1>I sent an email about MAME to the gnu-linux-libre thread
<janneke>davexunit: if i choose another name, then i must choose other names for all packages that depend on that new name, for that platform?
<rain1>ACTION amazed this is even contraversial at all
<davexunit>janneke: my suggestion was just for testing things out.
<ng0>oh great. now "$*" in the substitute* is breaking the regexp. can i just \\$\\* for that?
<davexunit>once it's ready to be incorporated, we could include it in core-updates or something
<janneke>ok; yes that works, I already tried it
<davexunit>core-updates is where we put patches that rebuild the world
<davexunit>we build it periodically, fix things that are broken, and then merge when things are mostly good
<janneke>so what i "think" that i want, is simply not possible?
<ng0>maybe. i am not sure if it's the $*
<davexunit>you cannot alter a build script without changing the hash of everything that depends on it.
<davexunit>you could try to graft the new ncurses if you want to avoid rebuilding everything.
<ng0> https://ptpb.pw/h8ue
<ng0>is the build output
<janneke>yes, but in effect my change has no "effect", we cannot somehow compute the hash after some evaluation?
<davexunit>janneke: no.
<davexunit>the build script is part of the hash.
<alirio>bavier: it seems validate-generate's inline python is python 3 compatible, but fantasque-sans lacks a makefile...
<ng0>while I'm at it, should I configure psyclpc and psyced to not be under the /opt/ dir?
<bavier>alirio: this one? https://github.com/belluzj/fantasque-sans/blob/master/Makefile
<bavier>alirio: I have the ttfautohint, sfnt2woff, and ttf2eot packaged
<alirio>bavier: i expected it to be in Sources...
<ng0>no, \\* is wrong. can i escape that somehow?
<alirio>bavier: eot seems useless to guix, fontforge does hinting and woff generation...
<bavier>alirio: sure. I was trying to not get too involved.
<alirio>bavier: i wonder if we shouldn't have a font-build-system with freefont tools and just grab *.sfd from other fonts
<bavier>alirio: I'm not too familiar with fonts development. Would something like that be generic enough?
<alirio>i would say to look at tools/generate/{TrueType,OpenType,WOFF} from freefont tarball, it seems generic
<ng0>is a statement of myself saying that a project (2 packages I am working on) will no longer release tarballs and that git is the only supported way enough or do I have to include the short statment of one of the developers in the file?
<alirio>ng0: a link would be better
<ng0>there's no link
<ng0>just a chatlog
<alirio>some channels are logged...
<alirio>if not, it's better to include the statement
<ng0>it's not irc. if someone wants to, you can join psyced.org/@welcome and do a +hist until you see lynX saying it.
<alirio>ng0: there's a easy way to do it? like "run this command"
<ng0>yes, excatly, what I just wrote. but if that's not enough I can ask to get it included on the website if you necessarily need proof.
<alirio>documentation in official website is better in any case
<ng0>the command would be: point your webbrowser, irc client, telnet client, xmpp client or whatever to psyced.org , enter #welcome (you will automatically in most cases), do a +hist (for example +hist 300 to see the last 300 lines) and search for the mentioning of the lines.
<alirio>ng0: this doesn't seem easy, confront: this is the last commit in my git, execute 'git log|grep "Thu Mar 24 15:39:45 2016 +0100" -A 2'
<ng0>?
<alirio>you just execute 'git log|grep "Thu Mar 24 15:39:45 2016 +0100" -A 2' and you see my reference
<alirio>one manual step
<ng0>www.psyced.org describes how to join, help.pages.de gives input about +hist command. I don't see how this is any more difficult. Anyway, I asked to get it included on the website
<ng0>you can also compare the contribution to the git repos vs how "often" tarballs were released. the one done in 2016 is probably the last
<alirio>ng0: it would be the same if you could do something like that: 'icecat www.psyced.org -exec "+hist 253"'
<ng0>ah, forget it. I just wait for it to be included, meanwhile package it based on git anyhow.
<ng0>i don't see a point in discussing about the easiest way to proof statements
<ng0>okay, one last:
<ng0>could you open www.psyced.org/files/ and read the first paragraph? is that enough already, or does it have to be clarified? older files (2012 and later) were recently deleted.
<alirio>ng0: i think including a comment like "this project will no longer release tarballs" is better than what is in http://www.psyced.org/files/
<ng0>i can try to communicate that with them, but the nature of how this package will work, will most likely require git anyhow to include bugfixes as psyced -u will most likely not work under guix.
<alirio>ng0: if it's too much effort, it's ok to not make a reference
<alirio>just explain the situation
<ng0>okay
<ng0>could I escape $* somehow at the end of a substitute? I'm looking at all substitutes we have, but this seems to be a first
<alirio>escapes are \\\\
<ng0>which did not work
<alirio>you can just use . that matches any character
<alirio>maybe you missed a escape for each character "\\\\$\\\\*"
<efraim>that part you are taking out or the string you're putting in?
<efraim>for the part you're putting in you might need an extra \\
<efraim>9th gnu mirror finally had the new gnupg@2.0.30
<ng0>i did \\\\$\\\\*
<ng0>$* is unaltered, needs to be in both parts
<ng0>torproject recommends to call what used to be hidden service now "onion service" for new services. shouldn't we reflect this in the service?
<ng0> https://blog.torproject.org/category/tags/onion-services
<alirio>ng0: sure, would you write a patch?
<ng0>should hidden-service remain available? otherwise it would break peoples setups if someone uses it already
<alirio>this is stability policy, better ask civodul; but i think it's ok in 0.* to do things like that
<alirio>s/do/break/
<efraim>can we have hidden service be an alias of onion service?
<ng0>can services also be inherited?
<ng0>I just started reading the services, as I think it's more useful to work on those
<efraim>it's all scheme, so I'd assume so
<ng0>i need to read some more before I do changes.
<alirio>efraim: this can make _new_ configurations use it; can we make mark a service as deprecated?
<ng0>as long as we have no post-install notes thing, i guess we can't.
<efraim>we should be able to make it spit out a warning (to log?) that it's being depreciated
<efraim>then again, if its working well I don't always read the logs
<ng0>although i am not 100% sure about onion service.. I read it in a recent news at torproject, but trac and all still have many occurences of hidden service
<ng0>there's this presentation:
<ng0>i mean talk: https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think
<alirio>ng0: i followed the argument about it, actually it was "location-hidden services" because you can use without showing the ip of the server (ip leaks location), but now that facebook uses it they are planning to optimize it _without_ privacy, so it not _just_ to hide location and "onion services" are better
<davexunit>release announcement on lwn http://lwn.net/Articles/681662/
<alirio>ng0: btw, other use is having a server behind dynamic ip
<ng0>i know
<ng0>or simply provide a quick authenticated git daemon
<alirio>that is a server behind dynamic ip, no?
<ng0>sometimes, sometimes not
<ng0>in most cases yes
<davexunit>hmm, GNOME's built-in screencasting doesn't work
<davexunit>the log complains about vp9enc
<lfam>GNOME doesn't work at all on my 12 year old i686 "beater" laptop :(
<lfam>I suppose it's a lot to ask ;)
<lfam>I sent a revised Erlang patch to guix-devel for review
<efraim>nvidia gforce 8400 GS, was that a good graphics card way back when, and I assume it's old enough that its supported by the libre nvidia graphics
<lfam>efraim: Do you know the status of our webkitgtk-2.4.10 package? There's a security advisory for versions before 2.10.5: http://webkitgtk.org/security/WSA-2016-0003.html
<lfam>I mailed guix-devel with the same question
<efraim>i think we just updated the 2.4 branch
<efraim>first version bump in forever
<lfam>I see that. None of the CVE IDs in this advisory are mentioned in our changelog.
<efraim>:(
<lfam>It looks like the only thing that depends on 2.4 is shotwell
<keverets>efraim: the 8400gs was a bit weak for its day (mainly intended for media centres, etc). Getting full use of nvidia cards without nvidia provided proprietary drivers was always problematic
<keverets>don't know how the state of libre nvidia drivers has progressed for that card, though
<efraim>keverets: thanks. it's probably better than whatever built-in graphics the chip has
<efraim>its a dual-core pentium 4, upgraded to 1GiB of ram!
<lfam>It looks like shotwell is "very lightly maintained"
<lfam> https://bugzilla.gnome.org/show_bug.cgi?id=751709
<lfam>"I don't think there's much we can do tbh. I don't forsee the release team stepping up to do shortwell maintenance"
<lfam>Does GNOME have a replacement for shotwell?
<alirio>gnome-photos
<str1ngs>I know ./gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz are downloaded. but how are they produced?
<lfam>We should ask upstream for advice. Especially since they have been making noise about webkitgtk+ security updates, I think we owe it to them to follow up on these questions
<lfam>str1ngs: What do you mean by "produced"?
<str1ngs>also how are the static "assuming they are static" tar mkdir xz bash produced?
<str1ngs>How is that tarball created.
<lfam>str1ngs: How were the bootstrap binaries produced?
<str1ngs>yes
<str1ngs>is that included in build bootstrap ?
<lfam>Here's what I know ;) https://www.gnu.org/software/guix/manual/guix.html#Bootstrapping
<lfam>An elaboration would make for an interesting blog post
<str1ngs>I'm not sure that included these intial depends
<davexunit>pretty cool to see milkytracker packaged in guix. I should learn how to use it for when I make games.
<lfam>I'm interested in GuixSD configurations that turn a computer into a musical instrument appliance. Like, turn it on and it gives you what seems to be an instrument rather than a general purpose computer.
<str1ngs>lfam: see the top four objects in the graph? I think those are manual produced
<lfam>davexunit: We could share these and then have a fundraiser show
<str1ngs>then put in /gnu/packages/bootstrap/x86_64-linux/ at guix build time
<lfam>I thought those top 4 objects were built from the lower parts of the graph
<rain1>it would be nice if they were reproducible, then you could use them to rebuild them and verify you got the same :)
<str1ngs>no there in the guix source tree. they get downloaded
<str1ngs>I need to make the guile package for x390x
<str1ngs>why I'm asking
<rain1>maybe you could use guix on one computer to build them for another/
<lfam>Sorry, I don't know the answer. You could ask one of the core developers or search guix-devel
<str1ngs>no thats not the issue
<lfam>I'm interested in this topic too
<rain1>guix build --system=SYSTEM attempt to build for SYSTEM--e.g., "i686-linux"
<ng0>a startup melody for a guix-theme for gnome composed on milkytracker in guixsd :)
<str1ngs>I'll make the tarball by hand but I was thinking there was a better way
<lfam>ng0: Yes :)
<davexunit>lfam: that's a fun idea
<lfam>Yeah, why not? :)
<alirio>ng0: and a kernel option to disable :P
<lfam>Even if no money is raised, it would be a good time
<ng0>yes :)
<ng0>i just discovered schneierfacts.com , this is better than chuck norris facts
<efraim>does %base-packages include a terminal?
<str1ngs>emacs how do you paste say register 4?
<str1ngs>C-x r i 4 right?
<davexunit>does anyone know how to "retarget" a patch at a different source tree?
<davexunit>there's an application that includes a bundled version of a library that has been patched
<davexunit>I have been able to isolate the patch I want
<ijp>str1ngs: pretty sure registers can only be named for latin characters
<davexunit>but the patch doesn't apply to the upstream source because the patch I have has the files a few directories deep.
<rain1>davexunit, maybe you can get it to apply by choosing -p0 or -p1, -p2 commands for the depth
<str1ngs>davexunit: with -P I think
<ijp>hmm, apparently not
<str1ngs>sorry -p
<str1ngs>personally I like to use git patches when I can if you are making the patch anyways.
<str1ngs>going to #emacs hope I live :( !
<davexunit>I need to ultimately recreate a patch file that will work on its own
<str1ngs>use git IMO
<str1ngs>add the source to git. then make your changes then you can use git diff
<rain1>if you get it to apply then you can keep a copy of the unpatched dir, and diff -ruN them
<anthk_>guix for mainframes :O ?
<davexunit>upon further investigation, I think it might be best to abandon this approach. the library in question has actually been pretty heavily modified.
<davexunit>to the point that we should just use that
<davexunit>because it's a fork, really.
<vasile>Is there a manual for Guix that is less like documentation and more like instructions for actually accomplishing things with guix?
<davexunit>vasile: the manual does this.
<vasile>davexunit: I think I'm looking for something a little more like a tutorial
<rain1>are there specific things you want to know how to do?
<davexunit>the manual explains things like how to install guix in the first place, how to install packages, etc. it could use a more tutorial-like section.
<vasile>davexunit: rain1: Yes. Say I made a bash script. How do I make a guix package out of it and install it. I see an programming API, and I'm happy to write some scheme, but for the life of me, I can't figure out where to put the resulting scheme file or how to feed it to guix. Some walkthroughs and examples would be really useful.
<vasile>rain1: Or, say I find a pypi package I want to install via guix. It's not really clear how I get it into the system, even after having read the manual section that talks about pypi build system.
<rain1>I mean i just put my bash scripts in ~/bin/
<rain1>but you can also do it via guix package manager, I could try to write a tutorial on it if you would like to test it
<davexunit>vasile: I don't have time to walk you though things, but the contributing section will tell you how to set up an environment for hacking on guix
<vasile>rain1: Yes, the point is that's an example of the simplest form of package I can imagine
<davexunit> http://www.gnu.org/software/guix/manual/html_node/Contributing.html#Contributing
<vasile>rain1: I don't actually want to package bash scripts.
<rain1>oh right :)
<davexunit>vasile: it's probably not as simple actually because it doesn't use a well-defined build system
<davexunit>importing something from pypi would be more likely to work without having to know much Scheme
<vasile>davexunit: Is there a step-by-step for pypi import?
<vasile>davexunit: I didn't see one in the manual.
<davexunit>vasile: you're not going find step-by-step guides for things so specific
<davexunit>but here's the 'guix import' documentation http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.html#Invoking-guix-import
<vasile>davexunit: So, let's say I run the import and get a package definition. (Yay for easy definition!) What do I do with that definition? I think I'm asking something really basic that just isn't clear from the docs or that I missed.
<davexunit>vasile: clone the guix git repo and add the package definition
<davexunit>note that 'guix import' doesn't necessarily output things that are guaranteed to build, as it is impossible.
<davexunit>it's job is to write as much code as it can for you.
<davexunit>its*
<vasile>davexunit: OK. I'm going to try this as a test run and see what happens. Thank you.
<davexunit>altnrnatively, you can maintain a tree of your own package expressions and use the GUIX_PACKAGE_PATH environment variable to point at them http://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#Package-Modules
***Basstard1 is now known as Basstard`
<davexunit>package modules are just Guile modules, with publicly exported variables that hold a reference to Guix package objects.
<davexunit>vasile: good luck! there's usually someone around to help if you get stuck, and maybe you could give us some suggestions for what a tutorial could look like.
<vasile>davexunit: Thanks! I'll think on it a bit more for contributing back some doc text
<davexunit>I'm too familiar with Guix at this point to know what a good beginner's guide would look like.
<efraim>i noticed the install image doesn't have wget or curl
<davexunit>a-ha, I think we might need to add gst-plugins-good as an input to gnome-shell
<rain1>it does have: guix dowload
<rain1>download*
<davexunit>that has the vpx stuff
<davexunit>then I should be able to record screencasts
<davexunit>efraim: we should probably add wget
<rain1>davexunit, I've packaged simple screen recorder
<rain1>it's pretty good to record video and I think it can stream to stuff like twitch too
<davexunit>rain1: I packaged OBS which can also stream
<davexunit>but I also want gnome's built-in screencast feature to work
<davexunit>it's nice for quick stuff.
<davexunit>press a keystroke, record a quick video, press the keystroke again to stop.
<civodul>someone should record a 5mn video demoing Guix
<rekado_>*someone* :)
<civodul>yeah, that person :-)
<str1ngs>I should take notes for porting. must more work then what the manuals says :)
<str1ngs>much*
<alirio>civodul: no font builds are deterministic without https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00968.html
<civodul>alirio: ah right, thanks for the reminder