IRC channel logs

2015-10-10.log

back to list of logs

<goglosh>Hi
<goglosh>Idk if it's my pc but
<goglosh>I can't install any os now, every one throws weird errors, and every os I'd installed bfore
<goglosh>anyway, for guixsd it says that a substitute file is corrupted
<goglosh>guix-0.8.3
<goglosh>Though that did 't happen 3 days ago
<goglosh>tried passing --no-substitutes to guix system init, but some other stupid error showed
<mark_weaver>goglosh: sounds like hardware problems. maybe bad RAM.
<mark_weaver>I would run a memory tester
<goglosh>Yeah that's what I thought
<goglosh>I'l, look that up
<goglosh>is that themusual memtest kernelmthat comes in instalk disks?
<goglosh>install*
<mark_weaver>yeah, some OS installers and rescue disks include "memtest86" in the grub menu
<mark_weaver>in general, when reporting problems, it's useful to tell us what the error messages are. descriptions like "weird errors" or "stupid error" doesn't help much.
<goglosh>Sorry, yeah. But I did tell you, it says something a corrupted file
<goglosh>I'lk be more specific from now on though
<mark_weaver>network errors can sometimes cause reports of corrupted data when downloading substitutes, so that doesn't necessarily indicate a problem with your system.
<mark_weaver>but if you can be more specific about the errors that occurred when you tried to install other OSes (which ones?) and when you tried to run "guix system init", that would also be helpful.
<goglosh>Well, I got that problem with that specific file about 5 times
<goglosh>ubuntu installed correctly but the install wouldn't boot
<goglosh>uh...
<mark_weaver>well, all of these reports are too vague for me to do much with. but actually I need to go afk very soon anyway.
<goglosh>Yes, sorry
<goglosh>I'd be more specific but I've been getting really frustrated to think properly
<mark_weaver>but if you can show us the error that "guix system init" printed, along with the OS config file that you passed to it, then someone here can probably help
<mark_weaver>okay, in that case maybe it's best to take a break
<mark_weaver>if you want to try again later, there are lots of helpful people on this channel, if given enough information.
<mark_weaver>ACTION goes afk
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 2 messages.
<sneek>civodul, nalaginrut says: Do you think this is a bug we need to care? https://lists.gnu.org/archive/html/bug-guix/2014-12/msg00055.html
<sneek>civodul, nalaginrut says: And someone encountered similar problem in Artanis, but I think this is the bug in client/browser https://github.com/NalaGinrut/artanis/issues/44
<iyzsong>civodul: hi! which icons dont work? I have xfce and emacs in system profile, and all seem ok for me, but I guess something can go wrong if 'hicolor-icon-theme' not there.
<civodul>hey, iyzsong
<civodul>iyzsong: i noticed that for wicd-client
<civodul>which is in my global profile
<civodul>ACTION rewrites "Defining Services", hopes to merge the whole thing today :-)
<davexunit>oh wow!
<davexunit>awesome!
<davexunit>ACTION needs to rebase wip-container and finish up testing
<iyzsong>cool!
<davexunit>(getting distracted by adding Skribe support Haunt, though)
<civodul>haha :-)
<davexunit>3-day weekend here so I imagine I can get both done before it's back to the ol' grind.
<civodul>heh
<paroneayea>hi everyone
<paroneayea>civodul: oooh
<paroneayea>awesome
<paroneayea>and davexunit, also awesome!
<paroneayea>I'm working on w3c things this weekend but I am excitedly rooting for guix things this week :)
<paroneayea>maybe I can figure out more on the python hacking front in the process though :)
<civodul>heheh :-)
<iyzsong>civodul: get it when I don't have 'hicolor-icon-theme' installed in any profile. and this is a common issue for all gtk apps, I think we can either propagate or wrap XDG_DATA_DIRS over hicolor (and adwaita for gtk3 app).
<iyzsong>run 'wicd-client' with `XDG_DATA_DIRS=$hicolor-icon-theme/share:$XDG_DATA_DIRS' should work. the wrap logic is still in glib-or-gtk-build-system, but wicd use python-build-system.
<iyzsong>ACTION AFK to sleep..
<civodul>iyzsong: oh right, i guess we should add a the right phase(s) for wicd
<davexunit>argh these guix-environment tests
<davexunit>guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
<davexunit>works outside of test environment
<davexunit>fails inside test environment
<davexunit>execve throws ENOEXEC with the bootstrap guile
<davexunit>I thought maybe the issue was the daemon since I had that locale issue before
<davexunit>so I rebuilt it
<davexunit>and the test still fails.
<davexunit>the exec man page says that ENOEXEC happens when the "header of a file isn't recognized"
<civodul>davexunit: isn't it because of a hard-coded "/bin/sh" somewhere?
<davexunit>it's not using /bin/sh though.
<davexunit>it's trying to directly run the bootstrap guile binary
<civodul>ah ok
<civodul>the binary is on a bind-mount inside the container, right?
<civodul>could it be that this mount point lacks execution capability?
<davexunit>I did a stat on the file from within the container and it's #o555
<davexunit>and I couldn't see a reason why the bind-mount would behave differently inside a test environment
<civodul>i was referring to the MS_NOEXEC mount flag
<civodul>it if's bind-mounted with MS_NOEXEC, then failure
<davexunit>that flag isn't used.
<davexunit>here's the relevant file system spec
<davexunit>("/home/dave/Code/guix/test-tmp/store/w8fsskwxr793yq6w3368x5k1p07syi3h-guile-bootstrap-2.0" device "/home/dave/Code/guix/test-tmp/store/w8fsskwxr793yq6w3368x5k1p07syi3h-guile-bootstrap-2.0" "none" (bind-mount read-only) #f #f)
<civodul>yeah that looks good
<davexunit>yeah so I'm confused as to what the problem could be.
<civodul>i would look at the "strace -f" output of the whole thing
<civodul>to see exactly how things are mounted, etc.
<davexunit>civodul: I've been grovelling through it
<civodul>could you post it?
<civodul>i could look at it tomorrow
<davexunit>okay let me generate it again
<davexunit>civodul: I'll send an email with the log attached
<civodul>great, thanks!
<civodul>ttyl
***mood_ is now known as mood
<Steap>Hm
<Steap>I'm getting ;;; ERROR: missing interface for module (gnutls)
<Steap>even though gnutls is installed
<Steap>and I have GUILE_LOAD_PATH=/home/cyril/.guix-profile/share/guile/site/2.0
<Steap>and GUILE_LOAD_COMPILED_PATH=/home/cyril/.guix-profile/share/guile/site/2.0
<mthl>Steap: In which context does this error happen?
<Steap>mthl: when using guix build with a package that downloads a tarball using https
<Steap>;;; Failed to autoload make-session in (gnutls):
<Steap>;;; ERROR: missing interface for module (gnutls)
<Steap>ERROR: In procedure module-lookup: Unbound variable: make-session
<Steap>hum
<Steap>I can do "scheme@(guile-user)> (use-modules ((gnutls)))" though
<mark_weaver>Steap: does the URI as written in the 'origin' field start with "https:" ?
***yves_del_harlow| is now known as yves_del_harlow
<mark_weaver>if not, then the 'gnutls' module will not be included in the inputs available to the download process.
<mark_weaver>this is a problem if you provide an 'http:' URL that redirects to 'https:'
<Steap>oh
<Steap>I see
<Steap>so, if it starts with "https", it's ok
<Steap>I was using a function in the URI field
<Steap>that evaluates to "https://..."
<mark_weaver>can you show me the code?
<Steap>mark_weaver: https://paste.debian.net/315290/ here is the commit that adds this function :)
***orly_owl_ is now known as orly_owl
<mark_weaver>Steap: so far, none of the mirrors we use are https URLs. the check in 'url-fetch' that sets the 'need-gnutls?' variable sees "mirror:" instead of "https:"
<Steap>mark_weaver: yeah :/
<mark_weaver>I'm not familiar with this code. it's probably more efficient to ask civodul how best to generalize it.
<mark_weaver>I suggest bringing this up on the ML