IRC channel logs


back to list of logs

<lfam>Man... I've been building webkit all day
<adfeno>lfam: I did so...
<adfeno>But, it still displays the warning
<adfeno>I guess I know what's wrong...
<adfeno>My faulty memmory again.... Sorry for being so dumb.
<adfeno>Got it now.
<bavier>adfeno: the message might be coming from guix-daemon
<adfeno>Hm... Perhaps...
<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>Hm... That's unnexpected...
<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>I have an idea...
<adfeno>We have progress. :D
<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>the manual in tty2 is different from the online manual
<baconicsynergy>ITS WORKINGGGGG
<baconicsynergy>i cant wait until i can run the Hurd kernel with GuixSD :)))))))
<baconicsynergy>my geek levels are dangerously high right now
<baconicsynergy>um, it give me a 410 "gone" error when attempting to retrieve Babel
<efraim>add --fallback to your command
<baconicsynergy>after 'init'?
<baconicsynergy>all seema nominal
<baconicsynergy>Maybe all this guix hype will finally motivate porting ext4, usb, and sound to the hurd
<baconicsynergy>damn i shoulda dumped stdout to a log
<baconicsynergy>i seeing several nonlethal errora
<efraim>collisions are ok
<baconicsynergy>oh ok
<efraim>as is missing locale
<baconicsynergy>really? thats interesting
<baconicsynergy>is there a place i could buy a guixsd sticker for my laptop? :3
<efraim>I don't know if there are any stickers right now, I've settled for now with a gnu head on my laptop
<baconicsynergy>damn this install is taking a long time
<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.
<ng0> fascinating emacs note i found about amazon
<sneek>ng0, you have 1 message.
<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>we have "modify-services"
<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.
<ng0>ah, okay
<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>at first
<ng0>git daemon --base-path --port etc
<ng0>does the init.scm of shepherd hold cases/examples the gnu/services/ files don't have?
<rekado>no, I think it's pretty empty
<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>for example lirc
<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?
<ng0>ah, now i get it :)
<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>"port" is a perfectly fine variable name
<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
<rekado>ng0: take your time :)
<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>logical :) thanks
<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?
<retroj>bavier: yes
<bavier>i.e. (substitute* "foo" ((".*bar.*") ""))?
<bavier>in my case it's just much nicer than a patch
<retroj>bavier: yes
<bavier>thanks for the affirmation :)
<ng0>git-daemon ends up being unbound.
<ng0>the convention so far seems to be to name services $name-service
<ng0>so I'll rename it
<rekado>bavier: please do this in a snippet
<bavier>rekado: I could do that
<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?
<davexunit>bavier: sounds useful to me.
<davexunit>what does --check do currently?
<davexunit>I have never used it
<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>as a 'expensive check'
<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. :)
<paroneayea>hiya #guix!
<bavier>hey there paroneayea