IRC Logs for #crux-devel Thursday, 2014-05-08

prologic^^^ we need to try to get these resolved somehow for crux 3.100:49
prologicI currently have no solution to either gith now00:49
prologicbridge-utils and go00:49
prologicUpdate to go build failure:
prologicsolve the go building error02:36
prologictwo issues02:36
prologic#! lo wans’t up (crux 3.1 caught me by surprise again)02:36
prologic#1 rather02:37
prologicdidn’t notice that lo is no longer in /etc/rc.d/net02:37
prologic#2 you _must_ have IPv6 multicast enable din your kernel (not enabled by default) for the failing go test to pass (d'uh)02:37
prologicI’ll make a note of this in the README02:37
jaegerwhen the discussion came up about splitting lo and ethwhatever I tried to think of a reason to have a lo script vs. just setting it up automatically or something. I couldn't think of a situation where you wouldn't want lo but if anyone knows a good reason not to have it, let me know02:38
prologicwell I don’t think it matters a whole lot02:48
prologicjust caught me by surprise is all :)02:48
prologicfunny that Eterhnet works just fine otherwise without Lo02:48
prologicjust you have no access to the loopback (
prologicI can’t think of a situation where you wouldn’t want Lo up at all02:48
prologicbut it just mean a) we should document this and b) you will now have SERVICES=(lo net sshd crond) as a minium in your /etc/rc.conf02:49
jueprologic: here are the incomplete release notes for 3.1 ->
jueprologic: as always help is welcome09:12
jueyour point b) is fixed now, thx for the hint09:13
prologicahh nps09:31
prologicI'll have a read after dinner :)09:31
prologicbbs :)09:31
teK__jaeger: if you dont want lo, just disable it in a separate script / rc.local.. +1 for auto-lo-setup.10:25
teK__prologic: I will take care of bridgeutils once I installed the rc110:25
juewhat's the problem to have lo in rc.conf?10:31
teK__that's polemic10:32
teK__(to ask)10:32
jueno, I'm serious10:32
teK__it's done in 99.9999% of cases10:32
teK__just like mounting things rw in /etc/rc10:32
juewell, that's true for cron too10:33
teK__or anything else10:33
teK__there is almost ero gain in running that as a 'service' while everybody has to have that 'redundant' entry in SERVICES10:33
jueIMO it's more transparent to have it there and keeps our rc minimal10:34
teK__that's a point and still the question boils down to: how many user will want to remove lo vom SERVICES10:36
jueprobably nobody, but you know that's not my point ;)10:38
teK__yeah, SCREW users :D10:39
teK__always complaining and not understanding things10:40
teK__so let's just put the lo-setu into rc.multi right before starting the services *g*10:41
teK__keeps a) rc.conf more slim b) rc clean10:41
teK__oh and the file count in /etc is reduced by one!10:42
jueteK__: sorry, I'm still not convinced :)10:42
teK__here's my last try: I will, angrily, shake my fist at you every time I spot lo in /etc/rc.conf10:43
jueteK__: ok, that's fine for me10:44
frinnstwhats wrong with /etc/rc.d/lo ?10:45
frinnstmuch cleaner imo10:45
frinnstits just another interface after all10:45
frinnstsilly tek10:45
teK__you could put every logicla step from rc into /etc/rc.d/, too10:45
jueteK__: btw, new tig ships with prebuild man-pages, just add 'install-doc-man' to 'make install'10:46
frinnstwhat if you build a kernel without network?10:46
teK__oh, good catch, thx10:46
frinnstfor some reason10:46
teK__yeah, we're the 99.9999.10:46
frinnstor if you want to disable lo for some reason ?10:46
teK__there is a reason to do that?10:47
teK__I found that interesting10:47
juethe lo thing is definitely a thing the user can/will configure, why hide it in a system script?10:47
frinnsti guess, if you dont plan to connect it to a network :)10:47
teK__I think I did not configure it once and things (X?) stopped working10:47
teK__but I'm not sure about this10:48
frinnstdoesnt x just use unix sockets?10:48
teK__will configure? I *seriously* doubt thatand that's my whole point10:48
teK__I dont remeber exactly it's been a long time ago10:48
frinnstanyways, lo is not that different from eth0 or whatever. granted most users will probably never touch it10:49
frinnstbut the same can be said for stuff like crond10:49
teK__not that different is a vast understatement10:50
teK__it has, in MORE than the mentioned 99.9999% of cases as address10:50
jueI dunno remember why, but I've used the start/stop feature for lo more than once10:50
teK__so it is _VERY_ different from the configuration standpoint10:50
frinnstbut it is still just another network interface10:50
teK__that would be interesting. It always bugged me to be in net at all (which his resolved now)10:50
*** prologic_ has joined #crux-devel10:51
*** Lukc__ has joined #crux-devel10:51
frinnstare there other distros that configure lo automagically?10:51
frinnstiirc debian and rhel has config-files for it that you can change stuff10:51
jueteK__: have you seen my tig message whithin all the lo crap10:52
teK__jue yes!10:52
jueok, fine :)10:52
teK__12:46 < teK__> oh, good catch, thx10:52
juehehe, thx10:53
frinnstim off to lunch!
teK__having angry lunch right now10:53
*** Romster has quit IRC10:55
*** prologic has quit IRC10:55
*** Lukc has quit IRC10:55
*** Romster has joined #crux-devel10:56
*** Amnesia has quit IRC12:04
*** Amnesia has joined #crux-devel12:18
jaegerteK__: I'm not against it, was just trying to think of a situation where it wouldn't be wanted12:36
*** Amnesia has quit IRC13:33
*** Amnesia has joined #crux-devel13:33
teK__and I will need to save this one:15:07
teK__15:20 <@frinnst> + makes me sound like a retard15:07
teK__just as a reference :>15:07
teK__oh a sarcastic retard, how innovative16:23
teK__it would be awesome to have a working kernel config for {qemu,vmware,vbox} (driver-whise) on our ISO16:27
jaegerWe do now, as far as I know16:27
jaegerThough if you find something's missing let me know16:27
teK__the provided config works on these ootb?16:29
jaegerIt should, yes16:30
teK__will try, thx16:30
jaegerChecking for CONFIG_BLK_DEV_SD... OK16:31
jaegerChecking for CONFIG_HYPERV_STORAGE... OK16:31
jaegerChecking for CONFIG_SCSI_VIRTIO... OK16:31
jaegerChecking for CONFIG_VMWARE_PVSCSI... OK16:31
jaegerI see what you did there16:34
*** jaeger has quit IRC16:38
*** jaeger has joined #crux-devel16:41
*** crash_ has joined #crux-devel17:55
jaegerteK__: just noticed that qemu only uses one core on the host even if I specify -smp 2 or similar. Is that by design?19:03
teK__I cannot confirm that19:16
teK__% grep -c processor /proc/cpuinfo19:17
teK__command line host:19:18
teK__/usr/bin/qemu-system-x86_64 -enable-kvm -drive file=/vm/,if=virtio -m 4096 -smp 4...19:18
jaegerMy VM sees 2 CPUs (-smp 2) but on the host only one is used at a time19:18
jaegernot a problem, just odd19:18
teK__on the host? Hm, gotta try19:21
teK__21258 root      20   0 8810416 3.085g   3436 S 800.0 20.1   3722:11 /usr/bin/qemu-system-x86_64 -enable-kvm -d+19:22
teK__800.0% usage19:22
teK__hmm :)19:22
jaegerwhat's your full qemu command line?19:25
teK__nothing special, I think:19:27
teK__/usr/bin/qemu-system-x86_64 -enable-kvm -drive file=/vm/,if=virtio -m 4096 -smp 4 -name sop -vga qxl -spice port=4900,addr=,password=S3CR3T! -net nic,vlan=5,macaddr=00:50:56:00:2F:27,model=virtio -net tap,vlan=5,ifname=tap1,script=no -net nic,vlan=6,macaddr=00:50:56:00:13:37,model=virtio -net tap,vlan=6,ifname=tap3,script=no -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,ch19:28
jaegerwhat does -enable-kvm do?19:31
teK__make use of the kernel acceleration19:32
jaegerI wonder if that's required for the smp... I'll try it19:32
teK__which is rather desirable :P19:32
jaegerI haven't used qemu very much so that's a guess19:32
jaegerI do have that enabled in the kernel, just didn't think to check if I needed to tell qemu it was available :D19:32
jaegerIt's been compiling a kernel for like 2 hours19:33
teK__I was surprised, too, when I was told I had to say enable-kvm19:35
teK__the serverop VM is actually hosted by a CRUX instance :))19:35
teK__works like a charm19:35
jaegerThe few times I've used qemu I've felt it's horribly slow, maybe that would help :)19:35
jaegercool, I wondered about that19:35
teK__it will19:35
teK__trust me19:35
jaegerFor what do you use the virtual serial port?19:36
teK__my co-admin added that19:41
teK__it could be for libvirt (dunno if it uses the socket or the chardev)19:41
teK__it may be for a simple plain and old serial console, too19:50
teK__it's not necessary by my dear fellow likes long command lines :D19:50
jaegerhehe, ok19:51
jaegerteK__: yeah, it's using all 4 of my laptop's cores now... -enable-kvm was the trick19:57
jaegerIt's a completely different VM that way, heh19:58
jaegerI was wondering to myself, "how does anyone use qemu for production virtualization?!"19:58
jaegernow I know the answer is "they set it up properly"19:58
teK__still it's kinda stupid it does not do autodection19:59
teK__but we ship a config file20:00
teK__I wonder if I can specify that in there20:00
teK__oh no that's for something else.20:03
jaegerit took 7m22s to build the 3.1-rc1 defconfig with make -j4 instead of over 2 hours and not finished :)20:04
jaegerhrmm... looks like I need to add VIRTIO_BLK to the defconfig, VIRTIO_SCSI isn't quite enough20:30
*** crash_ has quit IRC20:45
jaegerI wonder if there's a way to use tmux as the console for a few qemu VMs21:01
jaegermaybe using -curses, I'll try that for grins21:06
prologicteK__, I found no patch or newer version for it21:08
prologicwe will likely have to try to patch it ourselves21:08
prologicor wait for gentoo or arch folk to do so :)21:08
jaegerthat does work :D slick21:23
jaegerRomster: do you know what causes xscreensaver to be installed setuid root? Is it the root password option? Just curious because it always bitches in the log that it's running as root, even though it switches effective UID without any trouble and locking works fine22:18

Generated by 2.11.0 by Marius Gedminas - find it at!