IRC channel logs


back to list of logs

<civodul>Hello Guix!
<Sleep_Walker>hm, I'm afraid I was correct
<Sleep_Walker>it first tries to mount filesystems and then run udev
<Sleep_Walker>I need to mount base filesystems
<Sleep_Walker>then start udev
<Sleep_Walker>and then mount other mounts
<civodul>right, udev is started after switch-root
<civodul>is it a problem?
<Sleep_Walker>I need to mount filesystems after starting udev
<civodul>including root?
<Sleep_Walker>no, root is mounted already from initrd
<civodul>ah sorry, i see
<Sleep_Walker>I'm mounting some additional mounts, /home is among them
<civodul>file-system-service has a #:requirements parameter that you could use to have them depend on udev
<civodul>but there's some chicken-and-egg issue i'm afraid
<civodul>well dunno, you should try :-)
<Sleep_Walker>I'm afraid that I need to split file-system-service for base (%base-file-systems) and rest
<Sleep_Walker>so there is root-file-system-service, base-file-system-service, file-system-service
<Sleep_Walker>and file-system-service will depend on udev
<civodul>i don't think it needs to be split, there's already a #:requirements parameter for that
<civodul>but what i wonder is whether file system services can just depend on udev
<Sleep_Walker>if I won't split it, it can't
<Sleep_Walker>I'll give a try and see
<Sleep_Walker>whether #:requirements will help
<Sleep_Walker>I'm so close! :)
<civodul>good! :-)
<Sleep_Walker>so, I won't use filesystem structure, but service part of configurtion, right?
<civodul>well, do whatever seems appropriate
<civodul>what do you mean?
<Sleep_Walker>file-system doesn't seem to support #:requirements
<Sleep_Walker>it's implemented on services level
<Sleep_Walker>so I need to define file-system-service instance in services section of system configuration instead
<civodul>file-system-service, not file-system
<civodul>see (gnu services base)
<Sleep_Walker>yes, that's is what I mean
<civodul>for a start, you could just change other-file-system-services to always pass #:requirements `(udev ,@requirements)
<Sleep_Walker>I made it into:
<Sleep_Walker>- #:requirements (requirements fs)
<Sleep_Walker>+ #:requirements (cons eudev (requirements fs))
<civodul>should be (cons 'udev (requirements fs))
<civodul>the dmd service is called udev, not eudev
<toothbrush0>hey all, is it normal that is slower than treacle in winter? or is that to do with the core update merge? (it might also be PEBKAC though..)
<sturai>Hello, I am new to this topic and of course I am an amateur to programming. I would like to know if there is some website where I can see the Guix running as an OS
<iyzsong>sturai: Hi, I'm running Guix (or GuixSD, the distro name) as an OS. By website, you mean image, video or product server?
<Tsutsukakushi>i think he might mean just a webpage that's being hosted on GSD
<civodul>toothbrush0: "slower than treacle in winter"? :-)
<civodul>toothbrush0: but yeah, i'm afraid it's "normal" :-/
<civodul>i logged in and load is relatively low, everything seems normal
<civodul>so presumably it's the other VMs on that machine that are slowing it down...
<toothbrush0>civodul: ah, it's an idiom -- treacle is a sort of syrup
<toothbrush0>so it's a thing that is slow. and in winter it's cold, so it's slower :p
<toothbrush0>i was getting like 0-5Kb/s :/ it stalled every time i tried to install a package
<civodul>sounds like a Canadian expression
<civodul>nully: any idea what makes so slow today?
<civodul>nully: to me it really sounds like the problem currently is with other VMs on that machine
<civodul>today is Gateway Time-out day
<civodul>it takes a great deal of code to implement it
<civodul>but here it is:
<iyzsong>civodul: I have build 'mariadb' both on master and core-updates, both missing ''.
<iyzsong>But without '-DBUILD_CONFIG=mysql_release', it was ok (linked with IIRC..
<civodul>iyzsong: can you give the full details, like which binary, what does ldd say, objdump -x |grep PATH, etc.
<civodul>could you paste the build log then?
<civodul>they might be using --disable-new-dtags or something
<iyzsong>the build failed when it try to run './gen_lex_hash', reported "error while loading shared libraries: ..."
<iyzsong>I run ldd and patchelf to check, all executables built has linked with and a not found item for it does has a RUNPATH to gcc-lib.
<civodul>iyzsong: could you paste the build log, or at least the part where gen_lex_hash is linked?
<iyzsong>sure. ./sql/CMakeFiles/gen_lex_hash.dir/link.txt =>
<iyzsong>I have the failed build saved ;-)
<iyzsong>and 2.3M build log:
<civodul>ooh -static-libgcc
<civodul>(what's the point?)
<civodul>iyzsong: could you email with this command and the resulting issue?
<iyzsong>civodul: sure.
<bavier>debugging this hydra package is a bit of a pain. It takes "forever" to calculate the derivation.
<civodul>it's an opportunity for optimization :-)
<bavier>I have an inkling that it's all the propagated inputs
<civodul>could be
<civodul>so i think we can merge core-updates now?
<mark_weaver>bah, an unexpected pass causes "make check" to fail? :-/
*mark_weaver tries again to fix the test-async-cancel test failures....
<mark_weaver>civodul: I just merged 'master' into 'core-updates', and there are a bit over 100 builds per platform in the queue
<mark_weaver>including things like emacs
<mark_weaver>and icecat
<civodul>oh emacs too?
<mark_weaver>I'm actually surprised how many rebuilds happened. not sure which package it was that caused this.
<civodul>ok will wait a bit longer :-)
<mark_weaver>anyway, I think we should wait for those things to build
<civodul>well it's ok to not have 100% built, but emacs is a good indication that we should wait more
<mark_weaver>and icecat too
<mark_weaver>icecat takes a long time to build, and most everyone wants it
<mark_weaver>blah, it's a pain to disable a single test without running automake again
<civodul>yeah but it's still worth doing it
<mark_weaver>I was so pleased to find the XFAIL_TESTS make variable, but that only works if the test *always* fails.
<civodul>you're looking at a random failure?
<mark_weaver>yeah, the test-async-cancel test in gnome-vfs sporadically fails, and not just for us. it's a known problem, but that module is deprecated and the problem will apparently never be fixed upstream.
<mark_weaver>for months, I've been manually restarting those builds until the test passes, but I've had enough of that
<civodul>i see :-)
<mark_weaver>during 'make install', there are a large number of these warnings in gnome-vfs:
<mark_weaver>WARNING: failed to install schema `/schemas/system/http_proxy/port', locale `eo': Unable to store a value at key '/schemas/system/http_proxy/port', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /gnu/store/3j7099a1yabpmpk8kpc5i9k235k34abp-gconf-3.2.6/etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two
<mark_weaver>gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove
<mark_weaver>~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage
<mark_weaver>locations such as ~/.gconf
<civodul>it seems to be something inherently imperative no?
<mark_weaver>I haven't yet taken the time to try to understand it, but it's a lot of output
<mark_weaver>civodul: did you see that qemu failed on x86_64 in core-updates?
<mark_weaver>oh, it was a transient failure, nevermind.
<mark_weaver>I had restarted it and forgot
<bavier>yay first hydra package build! \\o/
<mark_weaver>bavier: oooh! :)
<davexunit>bavier: whoa!
<civodul>bavier: congrats!
<bavier>now to try testing it installed to see if it actually works...
***fchmmr is now known as everyone
***everyone is now known as fchmmr
<bavier>it might be useful for wrap-program to take a non-list in the '= case
<bavier>e.g. (wrap-program file `("VAR" '= "foo"))
<civodul>i don't like the "typing fuzziness" though
<civodul>when something can be either a list or a string, for instance
<bavier>there's that, yes
<mark_weaver>maybe we should support another symbol, e.g. ':= that takes a string
<mark_weaver>well, I don't know what to call it...
<mark_weaver>civodul: I will mention though that substitute* takes either a list or string :)
<mark_weaver>but I agree it's best to avoid it
<_`_>was there a torrent for the usb install images?
<bavier>_`_: yes, the link is in the ML archives
<bavier>I don't believe it made its way to
<_`_>bavier: thank you very much
<civodul>mark_weaver: i was hoping nobody would mention it :-)
<civodul>re bittorrent, i think i got stuck in "waiting" state
<mark_weaver>heh :)
<rekado>our racket package doesn't quite work. I just started the REPL and evaluated (require plot) and got an error.
<rekado>ffi-lib: couldn't open "" ( cannot open shared object file: No such file or directory)
<davexunit>rekado: looks like glib needs to be propagated :(
<civodul>that rings a bell
*davexunit hates propagated inputs
<civodul>it's just that the source needs to absolute file names
<civodul>(propagating wouldn't help here)
<davexunit>I see
<rekado>BTW: I wrote something:
<civodul>oh yes, i have a git stash about racket
<rekado>still need to add pwetty pictures.
<civodul>rekado: nice!
<rekado>comments to my handle @ are welcome.
<davexunit>rekado: this is great!
<davexunit>I haven't finished reading, but so far you've done a great job enumerating the problems with traditional package managers that guix solves
<civodul>rekado: very well written
<civodul>it's nice to have a very clear general intro
<civodul>and then an actual "experience report"
<civodul>maybe you should email guix-devel about it
<civodul>someone should submit it to HN
<davexunit>I will
<zacts>davexunit: what is this?
<zacts>that you guys are posting to HN?
<davexunit>feel free to upvote, everyone :)
<davexunit>zacts: rekado just wrote this fantastic blog post about guix
<zacts>oh cool!
<davexunit>help me get this to the HN front page
<zacts>davexunit: must I be a HN member, or contributor to upvote?
<davexunit>zacts: yes
<zacts>ok, let me do this
<davexunit>you need like 500 karma or something, though
<zacts>oh I would have 0 karma
<zacts>how do you build karma?
<davexunit>or maybe that's not true...
*zacts is totally confused now
<davexunit>you need some amount of karma to do *something* but I'm not sure what
<davexunit>zacts: sign up and see if you can upvote
<zacts>I'll check it out
<civodul>hmm but i'm able to upvote
<davexunit>civodul: yeah, I think I'm mistaken.
<davexunit>it might be X karma to submit links or something
<civodul>i see
<davexunit>I can't remember now, but there was something that I unlocked after being around the community long enough
<zacts>davexunit: it let me upvote it
<zacts>well, I think it did
<zacts>is it the triangle next to the topic?
<zacts>that's what I pressed
<davexunit>the up triangle :)
<zacts>ah ok, cool. it worked then
<davexunit>with a few more upvotes we'd probably get to the front page
<civodul>mark_weaver: emacs is still missing on i686 (it's on x86_64, and icecat is on both)
<civodul>could you merge when it's built?
<civodul>TIA :-)
*civodul goes afk
<mark_weaver>civodul: I'll merge when the popular packages are built on intel platforms...