IRC channel logs

2014-11-11.log

back to list of logs

<nkar>is there a free software alternative to qubes? how do you keep untrusted software isolated?
<_`_>qubes is nonfree?
<nkar>it contains and recommends nonfree packages
<nkar>iiuc
<nkar>it doesn't meet the fsf free software distribution guidelines
<_`_>well all it is, is something on top of Xen.
<_`_>so if your motherboard and cpu have IOMMU support, an analogous setup is possible.
<nkar>sure, but I don't have time nor the expertise to roll my own thing
<_`_>I don't think there's another solution like qubes utilizing a hypervisor and relying on a currently niche processor/motherboard feature.
<_`_>as for isolation of untrusted software, well that's a larger discussion consisting of ideas for things you'd probably need to roll out yourself.
<nkar>well, if I only need to install some packages and configure them, it's doable.
<nkar>any concrete suggestions?
<_`_>apologies, most of my suggestions would abstract ideas (utilizing kernel user namespaces + cgroups or using a hypervisor)
<_`_>s/would/& be/
<nkar>that's unfortunate. I've expected that there's no free-software-friendly solution at the momeny.
<_`_>what software are you looking to isolate, if I may ask
<nkar>a browser, a mail reader, plus things that I download from the web, which are not included in guix.
<_`_>Capsicum for the Linux Kernel sounds like what would target your use case, but that's no where near ready, friendly, or usable.
<_`_>apologies once again
<nkar>haha, stop apologizing. it looks like I'm blaming you for the current state of things
<_`_>(●´ω`●)
<agumonkey>well, allowing substitutes changes life under vbox
<agumonkey>I still couldn't build tmux because of libevent
<agumonkey>is it me or nix uses precompiled packages by default ?
<phant0mas>good morning guix
<davexunit>good morning, guix
<civodul>Hello Guix!
<davexunit>hey civodul
*civodul considers releasing on Tue 18th
<davexunit>that works
<civodul>that leaves some time for testing etc.
<civodul>i'll have to upload a USB image soon
<davexunit>I need to figure out my segfault issue, it's still happening. I was able to download substitutes to get emacs, but when I use guix environment it segfaults.
<civodul>could you rebuild it, then try to reproduce the problem, and report a backtrace?
<civodul>oh guile-sdl segfaults on i686: http://hydra.gnu.org/build/141136
<davexunit>UGH :(
<davexunit>civodul: how would you like me to get the backtrace, via gdb?
<davexunit>I did a full rebuild, ran make clean and make clean-go and re-ran ./bootstrap.sh
<civodul>ok the full rebuild is OK
<civodul>and yes, a backtrace with gdb
<civodul>it's best to run guix-daemon in a "ulimit -c unlimited" environment, and then get the backtrace from the core
<jmd>On an up-to-date git checkout, I can no longer build:
<jmd>In unknown file:
<jmd> ?: 2 [primitive-load-path "gnu/packages/nettle" ...]
<jmd>In gnu/packages/nettle.scm:
<jmd> 59: 1 [#<procedure 2a7f660 ()>]
<jmd>In ice-9/boot-9.scm:
<jmd> 106: 0 [#<procedure 1c539c0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> out-of-range ...]
<civodul>uh
<civodul>jmd: just did a full rebuild and it went fine
<civodul>could it be that there are stale things in ~/.cache/guile, or something like that?
<jmd>Dunno. Would deleting ~/.cache/guile help?
<civodul>and is it a "make clean-go && make"?
<civodul>(the out-of-range on nettle.scm:59 suggests it's accessing the wrong field of a struct)
<civodul>deleting ~/.cache/guile can't hurt, yes
<jmd>I didn't do clean-go I will try it.
<civodul>okay
*civodul stumbled upon http://dthompson.us/reproducible-development-environments-with-gnu-guix.html
<civodul>davexunit: nice post!
<civodul>you should get subscribed to planet.gnu.org
<davexunit>civodul: thanks!
<jmd>Typo here: It accepts one on more packages
<jmd> ^^
<davexunit>civodul: how does one go about getting syndicated on planet.gnu.org?
<davexunit>there's probably some obvious page that I haven't seen
<civodul>good question
<civodul>"Please write to planet@gnu.org for blog aggregation requests or suggestions."
<civodul>davexunit: ↑
<davexunit>thanks civodul
<mark_weaver>civodul: recently, the default font sizes in GNU icecat when visiting git.savannah.gnu.org/cgit got a lot bigger, and I noticed that the X server's notion of the physical display size and DPI, as reported by xdpyinfo, does not match what the X server detects during startup (as logged in Xorg.log).
<mark_weaver>civodul: I suspect that this is due to your recent commits regarding xorg configuration, but I haven't yet investigated.
<civodul>oh
*civodul tries
<civodul>yes i see that in IceCat
<mark_weaver>on the plus side, I'm glad to report that wpa_supplicant now works properly without manually loading any kernel modules.
<davexunit>!!
<civodul>damn, i have networking issues
<davexunit>great news!
<civodul>mark_weaver: good news, indeed :-)
<civodul>i'm looking at the ath9k firmware now, because ours seems to be miscompiled
<mark_weaver>civodul: I compiled it using the exact toolchain that their build scripts downloaded, although it would certainly be vastly preferable to get it working with our own toolchain.
<mark_weaver>for the record, the fact that wpa_supplicant now works is thanks to civodul's commit d460204, which also fixed bugs #18523, #18525, and #18571.
<civodul>mark_weaver: re Xorg, xserver.conf is actually unchanged, unless you use #:resolutions or #:drivers
<mark_weaver>hmm
<mark_weaver>well, *something* changed recently. maybe I'll have to do a git bisect.
<mark_weaver>civodul: there was the syntax error in xserver.conf that you fixed. maybe the X server ignored part (or all) of xserver.conf because of that?
<mark_weaver>and there was also the "-ac" option to X that was formerly in argv[0] and now is in argv[1].
<mark_weaver>I seem to vaguely recall that the presence of xserver.conf inhibits certain auto-configuration steps.
<civodul>we should remove -ac, actually
<civodul>mark_weaver: probably the typo fixed in e30442b means that xserver.conf was that the ServerFlags section was ignored
<civodul>but the Files section was not ignored, otherwise drivers wouldn't be found at all, etc.
<mark_weaver>okay
<th3kent>so i installed guix onto my h.d.d, i have 4x primary partitions -- grub_bios, boot, swap, root -- rebooting after "guix system init ...", grub fails with "error: file '/gnu/store/.../bzImage' not found. error: you new to load the kernel first". any advice please to get my fresh gnu system going? (-8
<civodul>hey th3kent
<civodul>th3kent: it seems that GRUB is not looking for that file in the right partition
<civodul>can you try "ls /gnu/store" from the GRUB command line?
<civodul>(hit 'c' while at the GRUB menu to enter the command line)
<th3kent>issuing "ls (hd0,gpt4)/gnu/store, i see the hashed directory for linux-libre3.15.6
<civodul>ok
<civodul>so perhaps it needs to be told which partition the root is?
<civodul>i don't remember the exact commands for that
<th3kent>grub has "--root=gnuroot", gnuroot is the label of the file system.
<civodul>yes, but that's used once the kernel has booted
<civodul>the problem currently is that GRUB doesn't where to find bzImage
*civodul looks at the manual
<civodul>th3kent: does "set root=(hd0,gpt4)" help?
<th3kent>let me test that quickly ...
<th3kent>yes that helps! i get to a guile(?) prompt ...
<civodul>uh, probably because the root file system was not found, this time by the initrd, no?
<civodul>there should be a message above the Guile prompt
<th3kent>i do have an error just before entry into guile, 'failed to resolve parition label "gnuroot"'
<civodul>okay
<th3kent>s/parition/partition/
<civodul>this is 0.7, right?
<th3kent>yes it's 0.7
<civodul>could you try at the Guile prompt ",use (guix build linux-initrd)" and then: (find-partition-by-label "gnuroot")
<civodul>ISTR there was a timing issue in 0.7, i.e., it would not wait long enough to see the partition
<th3kent>testing ...
<civodul>(an aside: can "git log" follow renames?)
<th3kent>after the find... i get "$1 = #f".
<civodul>ok, so it doesn't find the partition at all
<civodul>that's an ext4 partition, right?
<th3kent>yes, ext4
<civodul>can you try: (disk-partitions)
<th3kent>$2 = ()
<civodul>bah!
<civodul>can you try ",use(rnrs io ports)" and then: (call-with-input-file "/proc/partitions" get-string-all)
<th3kent>ok ...
<civodul>also, is it a SATA disk or something? could it be that a driver is not loaded?
<th3kent>i get '$3 = "major minor #blocks name\\n\\n"' only
<civodul>ok so most likely we're missing a driver to access the disk at all
<th3kent>this is an 8+ year-old laptop, so most likely i.d.e/a.t.a (?), can't scroll back to verify from the boot messages.
<civodul>it seems to be undetected anyway
<civodul>hmm
<civodul>th3kent: could you reboot into the installation image, and run "lsmod" and similar to see which modules are in use?
<th3kent>ok ...
<civodul>i mean, modules for the disk
<civodul>sorry that it's so tedious!
<civodul>but you're contributing to improving the thing, and that's appreciated! :-)
<th3kent>i was prepared for a hacking session tonight (-:
<civodul>good :-)
<th3kent>i see "ata1.00: ATA-2: FUJISTSU MHV... UDMA/100"
<th3kent>so pata_atiixp and pata+acpi?
<th3kent>s/+/_/
<civodul>possibly
<civodul>could you edit the OS configuration and add them to the 'base-initrd' call?
<civodul>the manual has an example, IIRC
<civodul>(Alt-F2)
<th3kent>ok lemme check that out ...
<th3kent>found it, lemme hack for a while and report back ... thank you for the guidance.
<civodul>np!
<phant0mas>hey civodul did you have any look on the updated cross-libc patch?
<civodul>phant0mas: no, not yet, sorry again
<civodul>i'm working on all the little things that need to work for the new release
<phant0mas>okay okay, take your time
<civodul>gtg