<lfam>Man... I've been building webkit all day <adfeno>But, it still displays the warning <adfeno>My faulty memmory again.... Sorry for being so dumb. <bavier>adfeno: the message might be coming from guix-daemon <adfeno>With my limited Bash/sh knowledge, I think I must imsert all the needed exports inside "my_home/.profile" <adfeno>Because if I open other shell, these lose their meaning. <adfeno>(By the way: I decided to use the export commands inside .bashrc instead, so I assume it works now, since I do "echo $GUIX_LOCPATH" and it does display the path) <adfeno>But I'm still receiving that warning message. <adfeno>And yes, I have tried reopenning a terminal and also restarting guix-daemon. <adfeno>Perhaps it's because ${LANG} is "pt_BR.UTF-8"? <adfeno>I'm reading the archives of a similar discussion in guix-devel <adfeno>Now, instead of one message, it displays two. Anyways, I'll just igonre this. ***Digitteknohippie is now known as Digit
<baconicsynergy>for my first time instantiating my config, do i run guix system init or guix system reconfigure? <baconicsynergy>i cant wait until i can run the Hurd kernel with GuixSD :))))))) <baconicsynergy>um, it give me a 410 "gone" error when attempting to retrieve Babel <baconicsynergy>Maybe all this guix hype will finally motivate porting ext4, usb, and sound to the hurd <efraim>I don't know if there are any stickers right now, I've settled for now with a gnu head on my laptop <alezost>baconicsynergy: I think it compiles stuff, right? <rekado>I waited long enough for my ipython update patches to be obsolete. <rekado>I packaged 4.x but now 5.0 was released. <sneek>ng0, efraim says: I think qtdeclarative has qtquick and qml <ng0>yes, i know. thanks though :) <rekado>ng0: I thought it would be about org-babel in Emacs... :) <rekado>I just mentioned org mode's babel feature to my colleagues who are excited about the upcoming notebooks feature in RStudio. <ng0>i did not use much of orgmode so far.. but enough to know that another project I am in has its website in org <rekado>I put off learning org mode for a long time. <rekado>took me a long time to understand why I want it <rekado>now I'm using it wherever I can. <rekado>looks a bit ugly by default, though <rekado>now I'm writing my Emacs configuration in literate style in a single org-mode file. It's great. <ng0>i think it couldbe useful for websites.. though I started looking at guile for that, but orgmode is different <rekado>for websites I use davexunit's haunt. <rekado>it comes with support for different format readers and handles annoying stuff like RSS. <ng0>I came to like a push to publish thing I wrote before I temporarily retired what I used <ng0>some minimalistic cms with markdown and dhtml <rekado>the "shogun" package is broken since the upgrade from Octave 3.8 to 4. <rekado>it's odd because it complains about an undefined "do_octave_atexit", but this procedure has not disappeared in Octave 4. <ng0>ashort update on gnunet-svn: I pinned to a version I was told is usable (before the refactoring started), but I'll only sent the patches once I have a functional system service for it, which at the moment requires debugging and learning through my git-daemon-service <ng0>I wished these 2 or 1 tests out of hundreds would not break, if enabled check/tests it hangs at the last check of tests round, 2 tests before that are skipped. <ng0>as noted in the gnunet-fs integration thread, 0.10.2 of gnunet is "around the corner" so it will be release after this summer, with no specific date set - refactoring requires some rewrites <rekado>ng0: can't you disable these two tests? <ng0>I'll take a look into that later <rekado>I for one am waiting for the next release. <rekado>before getting into gnunet again. <ng0>ideally I can finish the service before the release <ng0>there are bits and pieces of shepherd i need to understand <rekado>is this a "pure" shepherd service? <rekado>guix itself has a concept of services, which is unrelated. <ng0>I know I could ask more questions, but I'm not exactly stuck, i just need to understand. <ng0>a guix system service <rekado>personally, I find the name overlap unfortunate <ng0>i would not know at this moment how much pure and guix service differ <ng0>for gnunet it would be easier to write a guix system service, as it is config file based. git is not. and while I almost have it, I'll need to add back some values and try again. <ng0>gnunet has more priority I'd say, but git is something which is smaller. <ng0>what I definitely not understand and have not looked at so far is service expanding <ng0>whydo some services export 'name'-service-type in addition to 'name'-service ? just because not everything is included in -service? <ng0>most systems put the git user into /var/git for a home (for plain git, with access via git+ssh for the pubkeys). I have selected this directory as well, and will also use /var/gnunet for gnunet (the default iirc). is there anything against using /var/ for this? I assume it's okay <ng0>I'd like to have a guix gnunet service first, but also expandable/refactoring to a generic shepherd service later. I assume at the moment guixsd is the only system using shepherd. <ng0>generic service files can be included in gnunet upstream, specific ones not (and for guix it makes no sense to be included somewhere else when I aim for master tree) <rekado>the service-type stuff is used so that a user can modify the service easily <rekado>by matching for a particular service type you can then take its configuration and modify it. <rekado>a Guix service is not necessarily a shepherd service. <rekado>we use Guix services for creating files in /etc or to set the keymap. <rekado>the service framework is very comprehensive and can be used for many neat things. <rekado>if all you want is to have the equivalent of a systemd service (e.g. starting some daemon) then you need little more than a simple shepherd service definition. <rekado>if that's what you want I suggest playing around with user-level shepherd. <ng0>the (lirc lirc) in the lirc service refers to the user or package name? I renamed my service definitions from git-daemon-* to git-* once, but I'd like to prepend git services with git- in the future <rekado>you can install shepherd into your profile, edit ~/.config/shepherd/init.scm and then start it as a user. <rekado>I'll upload my service definitions to my server some day. <ng0>for gnunet i need and want more than a simple service. for git is just taking some arguments and creating the user+group <ng0>git daemon --base-path --port etc <ng0>does the init.scm of shepherd hold cases/examples the gnu/services/ files don't have? <ng0>when in (define-record-type) I have among other lines: (git-daemon git-daemon-configuration-git (default git)) which i understand is for the output/package, (git git) in define git-daemon-service is wrong. would (git-daemon git) be accurate, or even (git-daemon git-daemon)? the rest I do understand as it is set and used before, but this I do not understand so far.. for every service there is a (name name) in <ng0>the end. name or output? of service or package? <rekado>ng0: could you give an example of a service like that? <ng0>at the bottom of its file <ng0>(service lirc-service-type (lirc-configuration (lirc lirc) etc <ng0>does it just reference what's in record-type? <rekado>it initialises the field "lirc" with the value "lirc" <rekado>the value comes from the caller of the lirc-service procedure <rekado>this is used to create a lirc-configuration value. <ng0>i think i understand it a bit more <rekado>at the top of the file a new record is defined <ng0>i have to test and fail to get morespecific questions for the git-daemon i write <rekado>this record has type "<lirc-configuration>" <rekado>think of it as an object with fields <rekado>these fields have labels and accessor procedures <retroj>did my message about ola come through? <ng0>where (lirc lirc-configuration-lirc (default lirc)) is about the package lirc as the comment says <rekado>correct, there's a field "lirc" with accessor procedure "lirc-configuration-lirc" and a default value of "lirc", which is the package value. ***marxistvegan is now known as marxistvegan_
<rekado>"lirc-service" produces a new service object of lirc-service-type with a certain configuration object. ***marxistvegan_ is now known as marxistvegan
<rekado>(lirc lirc) means: set field "lirc" to whatever value is bound to the variable called "lirc" <rekado>a user can call (lirc-service #:lirc my-own-lirc) to use a different package <ng0>and "port" is in the guile vocabulary (or guix vocab.) so I have to use port-number unless I overwrite "port" which i should not do. correct? <rekado>"port" is generally used as a communication facility in Guile. <rekado>you could have a variable named port <ng0>ah, okay. from understanding and reading it makes more sense to name it port-number in this case. <davexunit>in the context of networking, it's understood that a port is a number <rekado>yeah, you won't break anything by naming a field "port" <ng0>I have an additional question I have a bit trouble constructing the question. I need some moments <ng0>git daemon takes the argument --port=number (at least from what I remember with most systems, if it doesn't I'll find out soon enough). I let conf be a string-append where also "--port="(number->string port) is included. as the default is a number, 9418, I should not need this however I think I have seen a service where it number->string was used for this. I have yet to successfully run a VM when the service is <ng0>ready, but there should be no need for number->string <ng0>bitlbee does that, but it also writes this to a file, so it's different from what I do *I guess* <ng0>woo :) I'm getting different errors now. once which are easier to fix. <ng0>mostly about forgotten fields <rekado>string-append works on strings, so you need to convert a number to a string <ng0>i have it almost working, but I think there are some last problems. the variable git-daemon does not get initialized, I'll compare to bitlbee again to see if I can solve it on my own, else I'll send an email with a patch ***marxistvegan is now known as marxistvegan_
<bavier>is substitute* an acceptable way to remove a line from a source file? <bavier>i.e. (substitute* "foo" ((".*bar.*") ""))? <bavier>in my case it's just much nicer than a patch <ng0>git-daemon ends up being unbound. <ng0>the convention so far seems to be to name services $name-service <rekado>bavier: please do this in a snippet <ng0>woops.what's the service for syslog named now? <bavier>but it seems more appropriate to do it as a build phase, since its for reproducibility only <ng0>guix system: error: service 'git' requires 'syslog', which is undefined <ng0>so i guess the source file of the service has to use-module where syslog is? <rekado>bavier: oh, I thought this is about removing non-free stuff. <rekado>must have mixed this up with a previous message of yours <ng0>but it already has base ... hm <rekado>I'm adding "lapack-with-lapacke", because a) I need lapacke and b) lapacke would add 20MB to the lapack package. <ng0>that's what tor uses <bavier>rekado: I think davem already enable lapacke in our lapack package <rekado>I don't see it. Is this in core-updates? <rekado>to build lapacke we need to add "-DLAPACKE=ON" to the configure flags. And I don't see that in our lapack package. <rekado>grep on the core-updates commit log also doesn't show anything. <bavier>maybe it hasn't gotten pushed yet <rekado>I'll submit my patch and reference Dave's patch <davexunit>it never got pushed because it needs to be made into a separate output <davexunit>and that was more work then I felt like doing at the time <rekado>yeah, I think using a separate output is nicer than either of these options <davexunit>especially since I'm not very familiar with lapack <bavier>would it be useful for `guix build --check` to warn about the presence of build directory strings in the output? <bavier>it rebuilds a package and checks that the output it the same as what's currently in the store <davexunit>ah, sounds like maybe adding that additional check would be odd, then. <davexunit>or maybe --check can be expanded to do output directory linting <davexunit>or maybe 'guix lint' can be expanded to build the derivation and lint the output directory <bavier>yeah, 'guix lint' might be a better place for such a thing <davexunit>currently 'guix lint' only looks at the source, but I don't see any reason why it must *only* do that. <bavier>I wonder why cmake-build-system doesn't pass -DBUILD_SHARED_LIBS:BOOL=YES by default... <bavier>rekado: speaking of lapack, it would be nice to link it against openblas, rather than its own netlib library <davexunit>bavier: probably just oversight re: BUILD_SHARED_LIBS <bavier>I've noticed several packages that set it themselves. <bavier>I'll try making it default and see what happens <Gamayun>sneek: later tell alezost the kernel panic seems to have been an issue with partitions. Redid partition tables and filesystem, and it appears all sorted now. :)