IRC chat logs for #ltsp on irc.libera.chat (webchat)

Channel log from 1 June 2012 (all times are UTC)

00:28	vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
00:34	Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 265 seconds)
00:34	Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
01:50	risca has left IRC (risca!~risca@81-233-43-131-no18.tbcn.telia.com, Quit: Lämnar)
02:06	Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 252 seconds)
02:18	Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
02:22	Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
02:44	Parker955 is now known as Parker955_Away
02:57	andygraybeal has left IRC (andygraybeal!~andy@h190.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds)
03:11	F-GT has joined IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net)
03:31	Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
03:45	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:48	vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
03:48	vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
03:51	* vagrantc waves
03:53	<vagrantc> alkisg: i'm not so sure about the modprobe overlayfs/aufs changes ... but i think i have a workable alternative
03:53	<alkisg> Hi vagrantc
03:53	Why not so sure?
03:53	We're the ones needing them, we're the ones that should be loading them
03:54	...since I removed the force_load part to save RAM
03:54	<vagrantc> alkisg: they might not necessarily be modules
03:54	<alkisg> Then how would force_load work?
03:55	<vagrantc> alkisg: it works by not failing if the modules don't exist :P
03:55	<alkisg> modprobe asdf fails if the module doesn't exist too
03:55	sha has joined IRC (sha!~sha@e177119119.adsl.alicedsl.de)
03:55	<vagrantc> alkisg: also, what if the module is already loaded? does modprobe return true then?
03:55	<alkisg> Yes
03:56	adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.171.174, Ping timeout: 244 seconds)
03:56	<vagrantc> alkisg: yes, but previously we were just checking which filesystems were available, and asking for the modules to be loaded
03:56	<alkisg> That's true now too, we just do it with modprobe instead of force_load,
03:56	and what we gain is that we only load one of them instead of both of them
03:56	(and none for local boots)
03:56	<vagrantc> alkisg: but if the module load doesn't succeed, then none of the mount options will be set.
03:57	<alkisg> That's why the "panic" below
03:57	Before, we didn't even panic, and the user just saw a missing disk later on
03:57	<vagrantc> sure, that's good
03:58	* vagrantc experiments
03:58	sha_ has left IRC (sha_!~sha@e177172223.adsl.alicedsl.de, Ping timeout: 245 seconds)
03:59	<vagrantc> alkisg: i'll play around with it, and see if i can't resolve my concerns :)
04:00	<alkisg> vagrantc: so what you're saying is "what if someone has compiled overlayfs in their kernel instead of using it as a module?"
04:00	<vagrantc> alkisg: that's the first glance ... and also just didn't realize that modprobe returned true if the module's already loaded.
04:01	alkisg: it seems like if the filesystem support is present, why can't we go with that? i mean we can modprobe also.
04:02	<alkisg> vagrantc: in ltsp-update-image I have code that does that, maybe you prefer that one instead
04:03	I didn't think that someone could have compiled overlayfs or aufs in their kernels when I wrote the initramfs part
04:03	<vagrantc> alkisg: checks for which filesystem is supported, tries to modprobe, checks if it's supported, tries the fallback module, check if supported?
04:03	<alkisg> Right
04:05	vagrantc: so if someone has overlayfs compiled in the kernel, modprobe will fail or succeed?
04:05	* vagrantc looks at the clock
04:05	<alkisg> Because if it succeeds, which would be the ideal result, then we have no problem
04:05	<vagrantc> alkisg: i would guess it would fail
04:06	alkisg: modprobing for a module that isn't a module should fail
04:06	<alkisg> I haven't ever even compiled a kernel, so I wouldn't know, but it depends on if they're doing kernel feature detetion this way or with some other way
04:07	...some other way == cat /proc/filesystems... hmm, ok
04:10	* vagrantc looks for a module to test
04:13	* alkisg starts his day with highvoltage's https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/981049 ... "LTSP needs a non-intrusive method to set a default session" ...would that be "LDM_DEFAULT_SESSION" ?
04:15	<alkisg> Normally that's exactly what the "default" Xsession is supposed to do, but I couldn't find an easy way to configure it system-wide on the server. Each DM keeps the default Xsession in a different file :(
04:17	<vagrantc> alkisg: well ... initial testing shows that modprobe module_name_of_compiled_in_feature returns 0 ...
04:17	* vagrantc is surprised yet again
04:17	<alkisg> :)
04:18	It appears that there's code around that checks for features with modprobe/lsmod
04:18	So they decided to make things easier for cases such as ours
04:18	<vagrantc> i mean, it's useful that it behaves that wayy
04:18	it's just not very intuitive
04:19	alkisg: so your code is great! :P
04:19	yet again
04:19	<alkisg> Haha
04:19	...not knowing 2 facts is the same as knowing them both. :P
04:19	<vagrantc> heh
04:20	<alkisg> Well it does have one disadvantage over the code in ltsp-update-image:
04:20	It doesn't check if aufs was already loaded
04:21	<vagrantc> yeah, it has a hard-coded preference for overlayfs
04:21	although so did the old code
04:21	actually the old code could've been dependent on what order they showed up in /proc/filesystems ...
04:21	so if you have both, you might end up with unpredictible results
04:22	alkisg: could use a loop and make it a variable as to what order to probe in
04:23	<alkisg> The code in ltsp-update-image is fine, if the user wants e.g. aufs, he can just modprobe it before
04:23	No need for a variable, it's a clean way to select your preference
04:23	<vagrantc> alkisg: how would we do that in the initramfs? they blacklist one or the other module?
04:24	<alkisg> No, put it in a force_load directive in hooks
04:24	force_load aufs
04:25	<vagrantc> alkisg: do you think debian/patches/getltscfg-makefile-flags is feasible to upstream?
04:25	* alkisg checks...
04:25	<vagrantc> i'm not sure how it would work outside of a debian build environment, so i just patched it for debian.
04:25	i.e. building getltscfg manually
04:27	<alkisg> I'm not too familiar with makefiles, I used to program C in visual studio :( But the change is that you also pass CPPFLAGS?
04:27	...where would that hurt?
04:27	<vagrantc> alkisg: well, also removing LDFLAGS=
04:28	<alkisg> Why do they empty LDFLAGS in the first place?
04:28	<vagrantc> dunno.
04:28	this is a jammcq question, probably.
04:28	alkisg: i was thinking we might want to autofooify it which would be more likely to behave properly ... so this was just a quick patch to get the hardening flags respected
04:29	alkisg: i think LDM_DEFAULT_SESSION is a reasonable feature request
04:29	* vagrantc waves to highvoltage
04:30	<alkisg> vagrantc: well normally I wouldn't want it to be an LTSP option but a server option
04:30	I don't think I want a different default session locally on the server, or with NX, etc
04:30	Or from XDMCP...
04:31	<vagrantc> well, every display manager seems to do it differently again ... there was some attempt at getting them all to support .dmrc, but they did it incompatibly, and now some have moved away from it
04:31	<alkisg> Meh
04:31	<vagrantc> x-session-manager worked on debian for a long, long time ...
04:32	but that seems to not work as well now that folks are trying to use .desktop files.
04:32	* vagrantc seconds alkisg's Meh
04:33	<alkisg> Btw I think we currently have problems if the .dmrc specified session doesn't exist, so we do need some changes in that code path anyway
04:33	<vagrantc> hence, why i think LDM_DEFAULT_SESSION is a reasonable request ... if everyone else is crazy, we may as well not try to herd cats.
04:33	* alkisg checks
04:35	<alkisg> ...although I'm not sure if we should silently select "default" in this case, or if stopping with a dialog error is indeed the correct way to handle it
04:36	(unrelated idea) ltsp-config dnsmasq --edit ?
04:37	<vagrantc> alkisg: what would it do?
04:37	<alkisg> It would open the related configuration file in $EDITOR
04:37	...so that we don't have to tell people "open lts.conf, it might be there or there or there"
04:37	...just ltsp-config lts.conf --edit
04:38	<vagrantc> and then could create it if not present...
04:38	or at least prompt to do so?
04:39	* vagrantc updates ltsp-client-core on the server
04:39	<vagrantc> let's see if it becomes unbootable :)
04:40	alkisg: sounds really useful ... although i don't know about a cross-distro way to support if $EDITOR isn't set.
04:40	debian has sensible-editor
04:41	<alkisg> I'm sure a distro-overridable function can help there
04:41	<vagrantc> but i'd hate to drop someone into vi or emacs if they didn't know either.
04:43	staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 244 seconds)
04:49	F-GT has left IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net, Remote host closed the connection)
04:50	F-GT has joined IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net)
04:52	dgeary2 has joined IRC (dgeary2!~david@c114-77-214-254.rivrw3.nsw.optusnet.com.au)
04:55	<vagrantc> I can see why, but for a while, SCREEN_DEFAULT=01 was a nice hack to not switch to other tty so that you could scroll back and see errors in the boot process ... but somewhere along the way we "fixed" that so it refuses to use SCREEN_DEFAULT=01 if SCREEN_01= isn't set
04:56	wonder if we need a "null" screen script.
05:00	we should default to IPAPPEND=2
05:02	<alkisg> True
05:02	About the default screen.... X does chvt by itself, if you mean that
05:02	<vagrantc> i'm 99.9% sure it's harmless at worst, and when you need it, it's so good.
05:03	alkisg: no, not X
05:03	alkisg: gadi wrote code where it doesn't even start the screen script until the tty becomes active a while back
05:03	just to handle X doing it's own chvt.
05:05	alkisg: ok, i've tested NFS, NBD with ext2 image, and soon squashfs image ... then it will be ... ltsp-update-image --cleanup /
05:05	* vagrantc thinks if cleanup should generally always be run that there should be an option to disable it at least with the "/" mode.
05:05	<alkisg> # Start the default screen and make it the active tty
05:05	openvt -f -c "${SCREEN_DEFAULT#0}" -s -- /usr/share/ltsp/screen_session "$SCREEN_DEFAULT"
05:06	<vagrantc> alkisg: yup, that's the code.
05:06	alkisg: so something's checking SCREEN_DEFAULT for a sane value, i haven't looked too deep into it yet.
05:06	<alkisg> ...so you're saying that SCREEN_DEFAULT=x and SCREEN_x is not defined, then what, it should switch to that vt?
05:06	*if
05:06	<vagrantc> alkisg: yup.
05:07	alkisg: that's how it behaved, and it was actually useful.
05:07	<alkisg> I don't think that's correct
05:07	SCREEN_DEFAULT=none, ok
05:07	But not SCREEN_DEFAULT=4 without anything in vt4
05:07	<vagrantc> alkisg: ok, so i want LDM to come up on tty7, i want a shell on tty8, and i don't want to to switch screens
05:08	alkisg: so just skip that code if SCREEN_DEFAULT=none ?
05:08	<alkisg> X will switch screens when started
05:08	<vagrantc> but our screen script doesn't start X until the tty is active
05:08	<alkisg> I don't think so
05:08	Ah right
05:08	OK
05:08	<vagrantc> i know so :P
05:09	that's how gadi's code had any possibility of working
05:09	it runs in a while loop
05:09	<alkisg> So... yeah just don't openvt -s when SCREEN_DEFAULT=none
05:09	<vagrantc> that sounds reasonable.
05:10	hmmmm... i got "ltsp0" as a generated hostname ...
05:10	with NBD squashfs
05:10	* vagrantc didn't notice NFS or NBD ext2
05:13	* vagrantc dreads writing the changelog entry for this one
05:14	<alkisg> ...or we could just remove the SCREEN_DEFAULT verification part I added... # Verify that SCREEN_DEFAULT points to an existing SCREEN_XX
05:15	<vagrantc> alkisg: actually, you might want to see what's on a tty that's not the default, so yeah...
05:15	alkisg: it could still warn about it, or something.
05:15	alkisg: as it's a pretty unusual use-case.
05:16	<alkisg> (08:15:07 πμ) vagrantc: alkisg: actually, you might want to see what's on a tty that's not the default, so yeah... ==> we don't have code anywhere to switch to "random" vts, we can only _not_ switch to a vt
05:16	I.e. no chvt calls anywhere
05:16	<vagrantc> alkisg: i guess maybe when i set SCREEN_DEFAULT=01 that's essentially what it did ... not switch to anything.
05:17	<alkisg> I removed them, they were very confusing and sometimes even wrong
05:17	<vagrantc> in which case none would be more explicit.
05:17	<alkisg> openvt -f -c "${SCREEN_DEFAULT#0}" -s -- /usr/share/ltsp/screen_session "$SCREEN_DEFAULT"
05:17	==> you were switching to vt1 and running screen_session there
05:18	...which of course didn't find the correct SCREEN_01 and did nothing etc etc
05:20	vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 252 seconds)
05:22	<vagrantc> alkisg: hrm.
05:22	<alkisg> ?
05:23	<vagrantc> alkisg: so ... i'm getting the hostname "ltsp0" and i just noticed a "couldn't state /tmp/net-*.conf" scroll by
05:24	<alkisg> ...and yet you have a booted system... weird
05:24	<vagrantc> alkisg: ok... looks like it's now /run/net-*.conf
05:24	<alkisg> vagrantc: break=bottom, check ... ah
05:24	...so they keep it even after the switch to the real system?
05:25	* vagrantc looks
05:26	<vagrantc> wheee.
05:26	shouldn't be too hard to fix, but might need to fix nbd-client's initramfs-tools hooks too
05:28	alkisg: it does appear to persist afterwards
05:28	alkisg: so /run/net-eth0.conf is there...
05:28	<alkisg> Got it...
05:29	<vagrantc> shouldn't be too hard to support both in init-bottom/ltsp
05:29	<alkisg> We could make a symlink to /tmp to help nbd-client
05:29	From top/udhcpc
05:29	<vagrantc> alkisg: looks like nbd-client just uses the initramfs-tools function
05:29	<alkisg> ...only until it's fixed upstream
05:29	Ah right
05:29	<vagrantc> so that's good
05:29	relying on unpromised features :)
05:30	* alkisg should check if configure_networking now properly handles IPAPPEND 3...
05:30	<alkisg> ...so then we could remove that part of the code in top/udhcp
05:30	<vagrantc> looks like IPAPPEND 3 is no longer documented
05:31	<alkisg> ip=xxx isn't documented?
05:31	<vagrantc> there's IPAPPEND 1, 2 and 4
05:31	<alkisg> Woah
05:31	Ah, and combinations
05:31	That was the case before too
05:31	<vagrantc> in /usr/share/doc/syslinux/syslinux.txt.gz
05:31	<alkisg> It's just bits to toggle and combine
05:31	00008421
05:32	<vagrantc> never really had a good understanding of how that sort of thing worked :)
05:32	<alkisg> You just add the numbers you're interested in, so if you want 1 and 2, you add them and put ipappend=3
05:33	<vagrantc> 2 seems harmless enough that it should just be default ... 1 is fairly safe, but there are some cases where it doesn't pan out?
05:34	<alkisg> 1 prevents a dhcp request, so no dns server, no lease (for the ones using dhcp) etc, it's not for everyone
05:34	*using udhcp
05:36	<vagrantc> ok, it's a one-line fix to add support for /run/net-*.conf
05:37	just need to also source /run/net-*.conf from init-ltsp.d/02-initramfs-env
05:37	we could optionally also copy /run/net-*.conf to /var/cache/ltsp/ but that seems more or less unecessary?
05:38	<alkisg> We also need to save it from top/udhcp,
05:38	and yes copy it to /var/cache/ltsp
05:39	<vagrantc> alkisg: well, if /run/net-*.conf exists, we'll source it. if it doesn't, we won't.
05:39	<alkisg> *init-premount/udhcp
05:39	<vagrantc> in case other things use it?
05:40	<alkisg> Now udhcp handles ipappend=3 this way
05:40	(ip=xxx, static ips in the cmdline)
05:40	If we don't create that file, then we let configure_networking handle static ips
05:41	And, for /var/cache/ltsp, we read it in ltsp_config
05:41	<vagrantc> alkisg: so we should copy /run/net-*.conf to /var/cache/ltsp/ ?
05:42	<alkisg> Yes
05:42	<vagrantc> alkisg: or should we just use /run/net-*.conf if it exists?
05:42	<alkisg> We should copy it because we read it from ltsp_config
05:43	<vagrantc> alkisg: i don't see where it's read from there.
05:43	<alkisg> You said it above, ./client/share/ltsp/init-ltsp.d/02-initramfs-env
05:44	Ah wait
05:44	* vagrantc nods
05:44	<alkisg> I'm talking about the initramfs /run/net*
05:44	i.e. we should copy that
05:44	Are you talking about the real /run/net*?
05:44	<vagrantc> alkisg: i don't see a difference ... they are the same.
05:45	<alkisg> OK bottom line is we need that info in ltsp_config
05:45	So if it's in /tmp, we need to copy it
05:45	<vagrantc> why not:
05:45	-for netfile in /var/cache/ltsp/net-*.conf ; do
05:45	+for netfile in /var/cache/ltsp/net-.conf /run/net-.conf ; do
05:45	<alkisg> If it'
05:45	If it's in /run, we either need to copy it in /var/cache/ltsp, or just source it from there
05:45	* vagrantc sees the latter working
05:46	<alkisg> Sounds find
05:46	fine
05:46	<vagrantc> what i don't see is how init-premount is going to know which file to write
05:46	i guess it could write both ...
05:47	<alkisg> Or make a symlink
05:47	(put it in /run since that's the new correct place, and a symlink in /tmp)
05:48	<vagrantc> ah, that's simple enough
05:48	unless /run doesn't exist ... or we just blindly create it?
05:49	<alkisg> We could just blindly create it, I don't see how it could do harm
05:50	<vagrantc> ok ... ltsp-update-image --cleanup / ... still getting segfaults :(
05:51	alkisg: also, at least at one time, userdel had no consistant behavior across distros
05:51	<alkisg> At least it's in a file where it's overridable
05:51	So if other distros need to override it, they can
05:51	<vagrantc> fair enough :)
05:52	<alkisg> Does add-apt-repository ppa:xxx work in debian?
05:52	<vagrantc> no
05:54	ok, mksquashfsing
05:56	alkisg: we shoudn't generate rsa1 keys ... long since deprecated
05:56	<alkisg> vagrantc: ssh-keygen -A
05:56	...not our bug :)
05:57	<vagrantc> heh
05:57	* vagrantc wonders how the packages handle it
05:57	<vagrantc> probably iterates through each supported type
05:58	<alkisg> The sshd postinst does that ^ yeah
05:59	<vagrantc> ah, it checks the configuration file if it has the key listed ...
05:59	mealstrom has left IRC (mealstrom!~mealstrom@46.63.71.254, Quit: Leaving.)
06:00	<vagrantc> and the default ssh doesn't have rsa1 keys listed
06:01	sshd_config
06:01	<alkisg> vagrantc: is it a security issue, or just a policy issue?
06:02	Because policy-wise, I'd leave it up to ssh-keygen, it's their decision what they want to deprecate anyway
06:02	<vagrantc> it's just cruft in the image
06:02	i.e. it's generating and shipping a key that won't possibly work
06:03	<alkisg> It's not worth the code overhead though to go around it
06:03	(for our purposes)
06:03	Even if it's just 2 more lines
06:03	<vagrantc> as long as the key names are appropriate, yeah, probably not.
06:04	* vagrantc watches mksquashfs progress bar ... 80% ...
06:04	<alkisg> I think that nice + ionice part makes it much slower than it was :(
06:07	<vagrantc> hrm ...
06:07	no kernels.
06:08	no kernels in the image either
06:09	maybe aufs doesn't support the bind-mounted sub-mounts?
06:11	this just got more complicated.
06:14	* alkisg started testing on debian and then went on to edit the epoptes installation page instead :P
06:15	<vagrantc> oh, i also didn't test with ldm installed.
06:16	i guess i should create a simpler install or something
06:16	<alkisg> I'm testing right now
06:17	ltsp-server-standalone: depends on nbd-server (>= 1:2.9.25-2) but it's not installable
06:17	vagrantc: ^ ?
06:18	<vagrantc> so, with the segfaulty "userdel \|\| true" and still the missing kernels problem ... it still does work :)
06:18	alkisg: still probably only in unstable?
06:19	nbd had build failures on one of the obscure arches that only recently got resolved
06:19	<alkisg> Hrm I wonder what would be faster, to copy it to my ppa or to search yet again how to do apt pinning... :D
06:19	<vagrantc> apt-pinning is each
06:19	easy
06:20	<alkisg> I think I have it in my other debian installation, /me checks...
06:20	<vagrantc> Package: *
06:20	Pin: release n=sid
06:20	Pin-Priority: 120
06:20	in /etc/apt/preferences.d/sid.pref
06:20	and then apt-get -t sid install nbd-server
06:21	and then once nbd-server migrates to testing (hopefully in 4 days), it should prefer the testing version again
06:23	alkisg: how bad do you think it would be to patch with "userdel \|\| true" ?
06:23	it seems to actually remove the user...
06:24	<alkisg> vagrantc: ltsp-cleanup runs in the client so we don't have set -e there
06:24	So the \|\| true isn't really needed
06:24	<vagrantc> i guess could do "userdel $foo \|\| check_if_user_is_really_gone $foo"
06:25	alkisg: ltsp-update-image fails to continue if the cleanup stuff fails to run.
06:25	<alkisg> It shouldn't fail though, unless I'm setting set -e manually, let me check..
06:25	<vagrantc> no, but if the last command run was a failure
06:26	which is the 52-remove-groups stuff
06:27	<alkisg> True
06:27	Let me check if it works here...
06:29	<vagrantc> could put in a 99-truth-the-whole-truth-and-nothing-but-the-truth
06:29	<alkisg> Nah a proper fix would be the best :)
06:30	<vagrantc> oh yes, of course. i keep forgetting :)
06:30	* vagrantc rebuilds with actual LDM support this time
06:31	<vagrantc> alkisg: oh, so ... i have to manually create /etc/ltsp/update-kernels.conf with the NBD values for this to work on Debian ... sigh
06:31	since i need to do that in 2 ltsp-build-client plugins, and also need to do that here ... seems like i should have a common way for them to do that.
06:32	<alkisg> ...the following packages will be removed: sysvinit :(
06:32	I probably shouldn't have tried the PPA version :D
06:33	...now to see why it tries to install upstart...
06:34	<vagrantc> hrm?
06:34	i guess i should push my builds somewhere people can test them.
06:35	<alkisg> ...some of the python* stuff probably depends on upstart
06:35	<vagrantc> which ppa are you messing with?
06:35	<alkisg> Mine, where I built ltsp in order for not having to set up a dev env in debian
06:36	mealstrom has joined IRC (mealstrom!~mealstrom@46.63.71.254)
06:37	<mealstrom> hi is it possible to blacklist some module like nouveau from lts.conf or some script without updating image ?
06:38	<alkisg> From pxelinux.cfg/default, google for "kernel parameters"
06:38	<mealstrom> oh, tnx. you ve saved my day
06:40	<vagrantc> alkisg: so it defaulted to running as a thin client
06:40	<alkisg> vagrantc: how much client ram?
06:40	<vagrantc> alkisg: ah, 256
06:40	<alkisg> fat_ram_threhold=300
06:41	* vagrantc bumps it to 1G
06:42	<vagrantc> alkisg: why 300 ? it's less than 512MB, but more than 256MB?
06:43	<alkisg> vagrantc: for cases with e.g. 384 ram (256+128). But now with the increased ram requirements, that should probably be increased as well
06:44	(256 was too low for fat when I wrote that number, and 512 was OK, but 512 - internal videoram was ok too)
06:44	E.g. 512 - 64 mb videoram - a couple of mb reserved by bios, etc etc
06:45	Currently I think we should change the threshold to 600
06:45	ltsp-client-core: depends: upstart-job
06:45	...dunno way, checking...
06:46	It was probably put there by dh_installinit, can't think of anything else
06:46	<vagrantc> probably detected that there was an upstart job available and added the dependency
06:47	<alkisg> vagrantc: but why didn't it do that for you?
06:47	We're using the same debian/rules, right?
06:47	cp $(CURDIR)/client/Ubuntu/initscripts/ltsp-core.upstart $(CURDIR)/debian/ltsp-client-core.upstart
06:47	I think that dh_installinit also checks the distro it runs in
06:48	<vagrantc> far as i know
06:48	* alkisg installs ltsp-client-core with dpkg -i... ;)
06:48	<vagrantc> or the debhelper scripts are patched in ubuntu to behave differently
06:49	hrm. ldm is failing..
06:49	well, got some more testing in ... i feel like we can have something releaseable tomorrow
06:50	<alkisg> vagrantc: can you upload your .debs somewhere?
06:50	Are they i386?
06:50	<vagrantc> alkisg: yeah, i386
06:50	<alkisg> Or at least ltsp-client-core.deb
06:50	<vagrantc> will do
06:51	<mealstrom> pxelinux.cfg/default .... APPEND ..blabla... blacklist=nouveau
06:56	<vagrantc> alkisg: sources.list entry: deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
06:56	<alkisg> vagrantc: thanks!
06:57	<vagrantc> i've been running that server for a while, barely use it for anything ...
07:06	<Hyperbyte> Good morning!
07:06	<alkisg> Hi Hyperbyte
07:07	mealstrom has left IRC (mealstrom!~mealstrom@46.63.71.254, Quit: Leaving.)
07:09	biomorph_ has joined IRC (biomorph_!~m@host-78-145-54-15.as13285.net)
07:09	biomorph has joined IRC (biomorph!~m@host-78-145-54-15.as13285.net)
07:09	<alkisg> OK let's see, time for ltsp-update-image -c /
07:13	vagrantc: it's running mksquashfs, no warnings etc about the users
07:14	The "FATAL: Module overlayfs not found." warning is a bit scary though, even if it's not harmful, maybe we should put 2>/dev/null there
07:17	<vagrantc> alkisg: probably
07:17	<alkisg> vagrantc: lsof /etc/passwd ?
07:18	<vagrantc> alkisg: hm?
07:18	<alkisg> Are you using some kind of live /etc/ monitoring daemon?
07:18	<vagrantc> not that i know of
07:18	<alkisg> So lsof /etc/passwd is empty?
07:18	<vagrantc> i use etckeeper, which checks /etc/ into git on package install/removal/cron.daily
07:18	yeah
07:19	<alkisg> ....I wonder why it segfaults for you then... ah, maybe your passwd is malformed? try pwck
07:19	<vagrantc> alkisg: so the sub-mounts need to be configured in aufs
07:20	<alkisg> Ouch, I'll leave that part for you, it'll be too hard for me to get a testing environment for that
07:20	So overlayfs isn't available for debian?
07:20	<vagrantc> not that i'm aware of
07:20	you can add aufs layers afterwards, yes?
07:21	<alkisg> No idea at all
07:22	bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
07:26	<alkisg> vagrantc: so do pwck and grpck show any problems in your system?
07:27	<vagrantc> alkisg: a few system users without homedirs
07:27	alkisg: well, with missing homedirs
07:28	alkisg: and it exits 2
07:29	<alkisg> I wonder if you tried `userdel vagrantc` on your real system, when another user was logged in, if it would segfault then too
07:29	For me, if a user is logged it, it just displays an error, no segfaults
07:36	<vagrantc> ok, with only ltsp-client-core and ldm installed, it failed to log in...
07:36	but with ltsp-client installed, it logged in (and of course, GNOME3 failed .... ugh)
07:37	mealstrom has joined IRC (mealstrom!~mealstrom@46.63.71.254)
07:38	<mealstrom> how to fix this? im using nvidia-173 on 12.04 and Xorg.7.log says This video driver ABI is not supported . Use the -ignoreABI option to ovveride this check. How can i add this option to Xorg ?
07:46	<vagrantc> alkisg: well, i'll put more into this tomorrow morning
07:47	vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
07:47	bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 246 seconds)
07:51	biomorph_ has left IRC (biomorph_!~m@host-78-145-54-15.as13285.net, Quit: Ex-Chat)
07:51	biomorph has left IRC (biomorph!~m@host-78-145-54-15.as13285.net, Quit: Ex-Chat)
07:54	<mealstrom> any ideas?
07:55	cant start thin client with nvidia-173 GF5200 at ubuntu 12.04
07:59	<jimjimovich> why does compiz work perfectly on nearly all ltsp clients with 10.04 but not work anywhere with 12.04?
08:02	<alkisg> ...because of unity?
08:03	<jimjimovich> I'm not sure. It just seems weird. It worked so well even on old hardware in 10.04. Now even in "classic" gnome, all 3D fails.
08:09	<alkisg> 3D over the network worked on old hardware? Maybe you're talking about something else?
08:13	<jimjimovich> no, i'm talking about Compiz 3D desktop effects. It worked perfectly, even on old intel integrated graphics cards. It ran on the client and caused no extra network traffic.
08:14	Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
08:14	<jimjimovich> every client (a big mix of hardware) in our 10.04 system has compiz desktop effects working by default with no problems
08:18	Da-Geek has joined IRC (Da-Geek!Da-Geek@nat/redhat/x-ihjpoqngoyjwksec)
08:21	<alkisg> Ah, I thought the problem was related to LTSP. Yeah if you run it locally and the driver supports 3D then there's no network involved.
08:24	<jimjimovich> Sorry for not being clear. This is an LTSP setup. I just have a standard 10.04 LTSP thin client setup. All Compiz 3D effects "just work" out of the box. I assume that Compiz is running on the client as it produces no extra network traffic and is quite responsive. I don't understand what changed to make 3D not work in 12.04.
08:26	<alkisg> No, compiz isn't installed in typical Ubuntu chroots
08:27	<jimjimovich> so it's running through the network? I didn't do anything special to try to make it work. It just worked with 10.04 and has worked well for 2 years.
08:28	<alkisg> It's probably running in software emulation mode
08:28	...which isn't good enough for unity
08:30	<jimjimovich> you're running ltsp-pnp, right?
08:31	<alkisg> Yeah?
08:31	<jimjimovich> how does that work with 32-bit kernel on a server with lots of ram?
08:31	<alkisg> More than 64gb?
08:31	<jimjimovich> no
08:32	<alkisg> Then it shouldn't be a problem
08:32	<jimjimovich> the standard i386 desktop image will see 16GB?
08:32	<alkisg> Sure
08:32	<jimjimovich> interesting. is that something new?
08:32	<alkisg> No, it's been that way for years
08:32	It's called "pae"
08:33	<jimjimovich> weird. i just installed 11.10 on a notebook with 8GB and it only saw 3.x GB.
08:34	these instructions you sent me for ltsp-pnp look very interesting and promising
08:34	<alkisg> How did you install it? With the desktop CD?
08:34	<jimjimovich> on the notebook, yes
08:34	<alkisg> Or e.g. with the alternate?
08:34	<jimjimovich> desktop CD
08:34	<alkisg> The desktop CD is supposed to select the -pae kernel automatically on systems with >= 4 gb ram afaik
08:35	Don't know why it didn't do that for you, but you can just install the -pae kernel with 1 command
08:35	<jimjimovich> this is good to know!
08:45	alkisg: in your ltsp-pnp setup (from the wiki), the clients are getting a standard DHCP response from a regular router and not a special response like "filename "/ltsp/i386/pxelinux.0"" ... am I understanding that correctly?
08:45	<alkisg> Yes
08:47	<jimjimovich> I'm curious, does Compiz and/or Unity 3D work on supported clients that boot via fat client mode?
08:47	<alkisg> Fat clients are like standalone clients booting from a usb disk
08:48	So yeah
08:49	<jimjimovich> yeah, I understand. I was just wondering because while searching the last few days, I've seen people reporting that even in fat client mode, Unity 3D fails to work correctly.
08:49	your setup really does seem optimal for many situations
08:49	<alkisg> Unity 3d fails to work correctly in many non-ltsp related cases, I don't think fat clients have anything to do with it not working
08:49	<jimjimovich> do you generally bother to assign IPs to clients via DHCP or just let the DHCP server handle that?
08:50	<alkisg> For others, I tell them to let the dhcp server (==router). For my school, I assign static ips from pxelinux.cfg/01-mac-address.
08:52	<jimjimovich> alkisg: does Epoptes work to connect to these fat clients?
08:52	<alkisg> Sure
08:52	<jimjimovich> this seems to good to be true :)
08:53	<alkisg> It's just software, you know you'll find a few bugs to annoy you :)
08:55	<jimjimovich> I need to give this a try. ltsp-pnp seems even simpler than standard ubuntu ltsp.
08:55	thanks for your work on it
08:55	<alkisg> That's the idea, to allow teachers to maintain ltsp without console
08:56	You're welcome
09:02	jimjimovich has left IRC (jimjimovich!~jim@77.239.224.238, Quit: Leaving.)
09:06	dobber has joined IRC (dobber!~dobber@213.169.45.222)
09:18	scribs has joined IRC (scribs!2e1007f1@gateway/web/freenode/ip.46.16.7.241)
09:20	<scribs> Running ubuntu 10.04 LTSP in a school across 64 machines. Two types of clients... 32 x new viglen PCs (hope to run as fat clients soon); 32 x 7 year old Dell machnes. I've set up a ubutn 12.04 LTSP test server which boots the new clients fine but the old ones get stuck on the splash screen. Pressing escape yields a blank black screen. What are my next debug steps or anyone have any suggestions please?
09:37	I should add that both types of clients have worked seemlessly under 10.04 for over 18 months - both types of clients as thin clients with local apps.
09:45	<mealstrom> does anyone have working 12.04 with nvidia-173 ? i cant get it working. it argues on ABI
09:47	ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
09:47	ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
09:55	<alkisg> scribs: how much ram on the old machines?
10:00	<scribs> 512mb
10:01	I've set FAT_RAM-THRESHOLD=1000 to try to force it to thin client mode in case that was the problem. Using a fat client image though, so it's bulky?
10:01	<alkisg> !quiet-splash \| echo scribs:
10:01	<ltsp`> scribs: quiet-splash: to disable the splash screen in Ubuntu, in order to see any boot error messages, run `sudo gedit /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default` and remove quiet splash .
10:02	<scribs> I did that... black screen (the same when I press escape). Will try again though.
10:03	<alkisg> scribs: also remove the force-plymouth bit
10:03	<scribs> Will try. Away for 20 mins... taking assembly!
10:04	adrianorg_ has joined IRC (adrianorg_!~adrianorg@177.18.171.174)
10:22	Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
10:32	<scribs> With 'quiet splash' and plymouth:force deleted, I now get a blank screen with no info at all.
10:33	(same as pressing escape)
10:37	Pressing alt an 'f' keys, I see the following errors:
10:37	<alkisg> And what's the last message you see before the blank screen?
10:37	Ah, ok, what?
10:37	<scribs> plymouthd: ply-terminal.c:630: pl.... Assertion `terminal! ... failed
10:38	error: unexpectedly disconnecged from boot status daemon
10:38	Begin: loading essential drivers .. done
10:38	Begin: Running /scripts/inintpremount ... dhcp request for eth 0
10:38	taht's it
10:38	hangs there
10:39	<alkisg> I think that you're editing the wrong file then
10:39	You shouldn't have plymouth messages with quiet splash afaik...
10:39	*without
10:39	<scribs> for removing quiet splash?
10:39	<alkisg> Yes
10:40	quiet splash and forceplymouth
10:40	<scribs> sudo nano /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
10:40	<alkisg> Put your /etc/ltsp/dhcpd.conf to pastebin
10:40	<scribs> ...
10:40	append ro initrd=initrd.img root=/dev/nbd0 init=/sbin/init-ltsp vt.handoff=7 nbdroot=:ltsp_i386
10:40	<alkisg> And your pxelinux.cfg/default too
10:41	Right
10:41	Ah
10:41	<scribs> ok... keep in mind that the other clients boot, this seems workstation type specific
10:41	<alkisg> So on the clients, do you get a busybox?
10:41	(shell)?
10:41	<scribs> no... nothing
10:41	will check again
10:42	machine still hanging - no busybox
10:43	<alkisg> OK in pxelinux.cfg/default put "break=bottom" in the place where "quiet splash" was
10:43	and reboot the client and see if you get a shell
10:45	<scribs> no quotes, right?
10:45	<alkisg> No quotes
10:48	<scribs> No change. Last messga eis Begin: Running /scripts/init.premount etc
10:48	. . . dhcp reuqest eth0
10:49	<alkisg> OK now on the same file, _under_ the append line, put a new line with this:
10:49	ipappend 3
10:49	Hmm
10:49	But you're saying that the other clients boot
10:49	OK try this then: break=premount
10:49	* ogra_ would change the break to break=premount to debug the mount process
10:49	<ogra_> heh, snap
10:49	* alkisg said it first :P
10:49	<scribs> They do. I'll boot one now to check nothing's change
10:49	<ogra_> :)
10:51	<scribs> Other clients going to busy box now, presumably because of the break?
10:52	<alkisg> And those clients don't break even with break=premount?!
10:53	<scribs> Trying that now... editing the file
10:58	Yes, old clients now break to busybox
11:07	mealstrom has left IRC (mealstrom!~mealstrom@46.63.71.254, Ping timeout: 244 seconds)
11:11	<alkisg> scribs: at that point, run ipconfig eth0
11:12	<scribs> New info...! Adding ipappend 3 seems to have fixed it. I removed the break and left the ipappend 3 in... works. What does that do?
11:13	<highvoltage> gooooooooooooood morning!
11:16	<scribs> Will leaving ipappend 3 in potentially break anything else? Any 'down sides'?
11:21	bieb has joined IRC (bieb!~hbieber@173.226.16.130)
11:28	Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Remote host closed the connection)
11:30	Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
11:41	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
11:44	Parker955_Away is now known as Parker955
11:51	vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
11:57	Parker955 is now known as Parker955_Away
12:16	alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 260 seconds)
12:27	<scribs> The new test server appears to be working (with ipappend 3). Thanks very much for your help. Much appreciated. We'll be using ltsp on ubuntu 12.04 in our school soon.
12:35	alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
12:51	sideffect has left IRC (sideffect!sideffect@gateway/shell/bshellz.net/x-lemgslyxeizjksks, Ping timeout: 244 seconds)
12:54	bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9)
13:03	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:06	Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
13:17	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
13:21	lefteris_nik has joined IRC (lefteris_nik!~lefteris@vlan11-dhcp247.cti.gr)
13:23	risca has joined IRC (risca!~risca@81-233-43-131-no18.tbcn.telia.com)
13:28	dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174)
13:31	mealstrom has joined IRC (mealstrom!~mealstrom@46.63.71.254)
13:32	Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Read error: Operation timed out)
13:46	Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
13:57	dgeary2 has left IRC (dgeary2!~david@c114-77-214-254.rivrw3.nsw.optusnet.com.au, Ping timeout: 256 seconds)
13:57	Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Remote host closed the connection)
13:59	Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Read error: Operation timed out)
14:00	Da-Geek has left IRC (Da-Geek!Da-Geek@nat/redhat/x-ihjpoqngoyjwksec, Quit: Leaving)
14:13	Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
14:17	lefteris_nik has left IRC (lefteris_nik!~lefteris@vlan11-dhcp247.cti.gr, Quit: Ex-Chat)
14:22	dgeary2 has joined IRC (dgeary2!~david@c114-77-214-254.rivrw3.nsw.optusnet.com.au)
14:26	bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
14:43	scribs has left IRC (scribs!2e1007f1@gateway/web/freenode/ip.46.16.7.241, Quit: Page closed)
15:13	darkpixel_ has joined IRC (darkpixel_!~darkpixel@curetheitch/staff/darkpixel)
15:13	alkisg has joined IRC (alkisg!~alkisg@ppp089210132173.dsl.hol.gr)
15:13	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
15:16	[GuS] has joined IRC ([GuS]!~gustavo@186.18.222.3)
15:16	[GuS] has joined IRC ([GuS]!~gustavo@unaffiliated/gus/x-663402)
15:20	dgeary2 has left IRC (dgeary2!~david@c114-77-214-254.rivrw3.nsw.optusnet.com.au, Ping timeout: 260 seconds)
15:23	mealstrom has left IRC (mealstrom!~mealstrom@46.63.71.254, Quit: Leaving.)
15:27	Parker955_Away is now known as Parker955
15:34	staffencasa has joined IRC (staffencasa!~staffenca@128.193.8.220)
15:45	dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection)
15:48	<bieb> I know this is not an LTSP issue.. just hoping someone may have seen this issue already.. I have a print issue.. I am using Crossover office to provide MS Office to students (required from higher-ups).. office works fine.. but when I try to print from ms-office (word, excel and powerpoint) it prints a blank page, then an error page... Error: undefinedresult Offending Command: awidthshow STACK: 0 0 32 0 0. Printing uses wineps. but printing from Libre works
16:02	vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
16:02	vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
16:10	<\|\|cw> bieb: sounds like a wineps issue
16:11	<bieb> \|\|cw: thanks.. I had already asked in other channels.. thats why I said I was hoping someone here might have seen the issue..
16:12	<\|\|cw> I try not to use wine if at all possible, there's always something that doens't seem to work quote right
16:13	<bieb> \|\|cw: some of the channels are really quiet today.. everyone taking off on friday
16:13	\|\|cw: crossover uses parts of wine..
16:13	<\|\|cw> I know
16:14	I've used it to, it's mostly just a heavily tweaked wine
16:14	a lot of wine's code came from crossover and transgaming
16:14	<bieb> \|\|cw: but I have to have MS office available for students so I am kinda stuck with it
16:21	<vagrantc> alkisg: re debian/rules clean target, i think i just need to switch: - [ ! -f client/getltscfg/Makefile ] \|\| $(MAKE) -C client/getltscfg clean
16:21	+ [ -f client/getltscfg/Makefile ] && $(MAKE) -C client/getltscfg clean
16:21	<alkisg> vagrantc: I think I tried that and it failed, but do try it (not for getltscfg, for localapps and nbd-proxy)
16:21	getltscfg works fine in all cases
16:22	<vagrantc> alkisg: oh, it's the same issue either way.
16:22	alkisg: i.e. leaving the test empty
16:22	pwd
16:22	ls
16:23	* vagrantc stares at toes
16:23	<vagrantc> ending the test on a failure
16:23	<alkisg> :D
16:23	I haven't tried a \|\| true at its end
16:23	<vagrantc> yeah, that might be worth trying
16:25	<alkisg> But it is working if I check "missing" instead of "Makefile"
16:26	I think the problem is that at some point, missing has been cleared, but the makefile is still there, but of course it won't work
16:26	<vagrantc> that's a clear bug, then.
16:28	<alkisg> While if I run autogen.sh manually at first, it doesn't hit the problem
16:31	<vagrantc> that's because it creates all the appropriate files, and dh_autoreconf doesn't register them as something it created
16:34	dptech has joined IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net)
16:34	dptech has left IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net, Client Quit)
16:36	<vagrantc> alkisg: did those packages i pushed work out for you?
16:49	alkisg: debuild -b -tc ?
16:55	<alkisg> vagrantc: I didn't try booting, but they worked just fine until ltsp-update-image -c /
16:55	NFS boot options, though
16:56	vagrantc: yes, debuild -b -tc reproduces the problem
16:57	<vagrantc> alkisg: yeah, the NFS boot options thing is kind of annoying ... i kind of miss ltsp-update-image setting the options now.
16:57	dunno where to put it ... ltsp-config nbd-boot-options ?
16:58	<alkisg> I think ltsp-client should ship an /etc/ltsp/update-kernels.conf file
16:58	It would make it easier for people to edit it, and it would provide both nbd and nfs options
16:58	But I'm not sure if that task is for now, or for later on along with the pxemenus
16:58	<bieb> \|\|cw: do you think I should be checking wine for that print issue? or crossover?
16:59	<alkisg> vagrantc: when update-kernels.conf is shipped, then ltsp-config can read it and decide the command line in a distro-agnostic way
16:59	<vagrantc> alkisg: shipping a file would still require actually setting the options manually, though.
17:00	alkisg: ah, you're talking about an update-kernels.conf with different syntax.
17:00	<alkisg> Yes, it should list all supported boot methods in that file
17:01	<vagrantc> it sure is weird to see ltsp-client and ltsp-server on the same server :)
17:01	<alkisg> It could also be in /usr/share/ltsp, but then the user won't see an example that he can edit
17:01	Haha
17:01	True, but it's working out fine here
17:01	<vagrantc> working about 90% great here :)
17:02	<alkisg> About the userdel problem, I'm inclined to believe it's specific to your system
17:02	Maybe it would even segfault if you ran it without aufs
17:02	<vagrantc> i guess i could build a fresh system.
17:03	<alkisg> A userdel wrapper that runs strace might help
17:03	...although it might not be worth the trouble
17:04	* vagrantc forgot how useful ltsp-build-client --debug was
17:04	<highvoltage> heya vagrantc
17:04	<vagrantc> just seeing exactly which plugin and in which phase something fails is mighty handy
17:04	* vagrantc waves to highvoltage
17:05	<alkisg> I'd prefer this to be implemented inside run_parts
17:05	<vagrantc> alkisg: the debug?
17:05	<alkisg> Yeah
17:05	<vagrantc> i'm not attached to where it's implemented
17:05	<highvoltage> vagrantc: I saw your wave from last night too, were you looking for me?
17:06	<vagrantc> highvoltage: i mentioned something shortly before that that i thought had something to do with you ... dunno what it was now
17:06	* highvoltage scrolls up
17:07	<highvoltage> 01:53 < vagrantc> alkisg: i think LDM_DEFAULT_SESSION is a reasonable feature request
17:07	01:53 * vagrantc waves to highvoltage
17:07	ah right, LDM_DEFAULT_SESSION
17:07	<vagrantc> highvoltage: but now that i have your attention ... looking like ltsp-cluster* might have to wait till wheezy+1 ?
17:07	<highvoltage> I think I filed a buf for that
17:07	<vagrantc> highvoltage: yes, that's what started the conversation
17:08	<highvoltage> vagrantc: ok, I don't think anyone will particularly cry :)
17:08	<vagrantc> highvoltage: if we get it together in the next week or so, there's some hope
17:09	<highvoltage> vagrantc: ok
17:10	SmallR2002 has left IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net, Ping timeout: 246 seconds)
17:10	<alkisg> highvoltage: I can push a fix for LDM_DEFAULT_SESSION, got any time to test it?
17:12	<vagrantc> i should probably also update ldm sometime soon ... although that looks to be smallish changes.
17:13	<highvoltage> alkisg: I could test it on monday if that's ok?
17:13	<vagrantc> alkisg: i could maybe test LDM_DEFAULT_SESSION today if you've got a patch
17:13	<alkisg> OK, I'll push it and you can test then. Do you guys prefer the whole line there, like LDM_SESSION, or just the desktop file name, like in .dmrc ?
17:13	<vagrantc> maybe some time sunday/mmonday too
17:14	that whole mess...
17:14	i think it should probably behave consistantly with LDM_SESSION
17:14	<alkisg> Unless we name it differently
17:15	<vagrantc> didn't someone put code in there to support both full commandlines and .desktop filenames?
17:15	or that's the translation between LDM_SESSION -> .dmrc
17:16	<alkisg> Yup I committed that ^ one
17:16	I suspect that most people will start using LDM_DEFAULT_SESSION instead of LDM_SESSION, so it might be a good chance to name it differently and make it match what people see in their .dmrc and in their /usr/share/xsessions
17:16	Dunno, whatever you people prefer.
17:17	<vagrantc> LDM_DEFAULT_DESKTOP and maybe a corresponding LDM_DESKTOP
17:17	?
17:17	<highvoltage> alkisg: oh cool (regarding .dmrc)
17:22	<vagrantc> alkisg: regarding debian packaging ... pushed the lts.conf example ... working on the debuild -b -tc issue ... anything else outstanding?
17:23	<alkisg> vagrantc: the localapps .desktop files issue, I'm not sure if we're packaging them in the right package (server or client)
17:25	<vagrantc> alkisg: it's currently in ltsp-server ... for thin-clients it makes sense, given that the desktop files will be on the server itself.
17:25	alkisg: we could ship the example desktop files in both.
17:26	<alkisg> vagrantc: I think they're meant to be installed on the client and to have them appear on the menu with LTSP_LOCALAPPS_ITEMS etc
17:27	So the sysadmin would be required to only add two lines in lts.conf to activate them
17:27	(instead of moving them to the server's /usr/share/applications etc)
17:28	<vagrantc> so we should install them in the client's /usr/share/applications/ ?
17:28	<alkisg> Btw, we could use the endsession script from epoptes to make them work in all environments
17:28	I think so, let me check the ubuntu packaging...
17:28	<vagrantc> yes, working in all environments would be good (although recent versions of LXDE support it natively)
17:28	<alkisg> (although they shouldn't appear on fat clients, dunno how to do that)
17:29	ltsp-client-core.install:client/localapps/doc/examples/*.desktop usr/share/applications/
17:31	And their icon is gnome-specific... nah, leave them as examples on the server
17:31	<vagrantc> heh
17:31	what about adding them to /usr/share/applications at boot time through init-ltsp.d somehow?
17:32	<alkisg> Ah right that's what I proposed to stgraber when we talked about it
17:32	<vagrantc> is there a way to detect their relevence?
17:32	<alkisg> Sure
17:32	...but doing it all correctly, with the icon and the endsession and the fat/thin detection would take time, I'd postpone it for now :D
17:33	So... leave them as ltsp-client-core examples?
17:33	shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Ping timeout: 240 seconds)
17:33	<alkisg> ...whatever as long as they don't show up in the menus :)
17:34	<vagrantc> the easiest thing to do about this is leave it as it is, and we can change it later when we know what we want :)
17:34	<alkisg> ok
17:35	<vagrantc> so, i think the "debuild -b -tc" is a policy violation that we need to solve the riight way ... ugh.
17:37	<alkisg> !gnome-fallback
17:37	<ltsp`> alkisg: gnome-fallback: To select gnome-fallback as your default session, put this line in your lts.conf: LDM_SESSION="gnome-session --session=gnome-fallback"
17:37	<alkisg> ...so, if the user sets LDM_DEFAULT_SESSION="gnome-session --session=gnome-fallback", and he hasn't installed the gnome-session-fallback package, we can't really do anything but fail
17:38	So I don't think it's worth it to try to check if $LDM_DEFAULT_SESSION has a valid value
17:38	<vagrantc> debian ships a "gnome-session-fallback" script.
17:39	<alkisg> I mean, we have no generic method to check if the session the user provided in lts.conf is valid
17:39	<vagrantc> right
17:40	<alkisg> So there's really not much to do to implement it... +++ rc.d/X50-dmrc-processing 2012-06-01 17:39:34 +0000
17:40	@@ -42,6 +42,8 @@ if [ -n "$dmrc_exec" ]; then LDM_SESSION="$dmrc_exec" fi
17:40	+ elif [ -n "$LDM_DEFAULT_SESSION" ]; then
17:40	+ LDM_SESSION="$LDM_DEFAULT_SESSION"
17:44	...so, here's an advantage of the .dmrc method, we can indeed check if the filename is valid
17:44	So we can e.g. set LDM_DEFAULT_DESKTOP=gnome-fallback, and that would only take effect if gnome-session-fallback is installed and the user has nothing in his .dmrc
17:53	risca has left IRC (risca!~risca@81-233-43-131-no18.tbcn.telia.com, Quit: Lämnar)
17:57	<vagrantc> alkisg: so, the problem is that the Makefile is generated and depends on missing and install-sh and depcomp and so on being installed, but dh_autoreconf purges them... simply not running make clean isn't ok... i'm kinda stumped on this.
18:00	* alkisg doesn't have enough experience to help there, but he's ok with checking if 'missing' exists until a proper solution is found
18:00	<vagrantc> alkisg: i migh be using dh-autoreconf wrong by having it call autogen.sh
18:00	shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
18:03	Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
18:09	bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 252 seconds)
18:11	komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
18:13	<alkisg> vagrantc, highvoltage: untested: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/revision/1435
18:14	I believe LDM_DEFAULT_DESKTOP is the best thing to use from all of them
18:14	as it allows to check for the desktop file existence
18:17	Btw, I wonder if LDM_SESSION is really mandatory, does ldm override whatever the user selects from the menu with it?
18:18	If not, there's no reason to provide all those "DEFAULT" variants of them...
18:19	<vagrantc> alkisg: i am fairly certain it overrides whatever the user selects.
18:19	at least, it used to...
18:19	<alkisg> Hmm ok then I should handle LDM_DEFAULT_DESKTOP differently
18:19	Errr LDM_DESKTOP
18:19	<vagrantc> i think it's appropriate to have a way to force the session
18:20	<alkisg> I.e. now LDM_DESKTOP takes precedence from the user's .dmrc, but he's allowed to select a different session from the menu (when LDM_SESSION is unset)
18:25	OK, pushed
18:26	Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
18:27	Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
18:29	shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Quit: leaving)
18:37	<alkisg> vagrantc: you also said that you want us to default to IPAPPEND=2, right?
18:38	<vagrantc> alkisg: seems like a good idea, yes.
18:41	<alkisg> vagrantc: ok, pushed
18:42	vagrantc: any objections on committing https://bugs.launchpad.net/ltsp/+bug/975128 ?
18:42	I.e. make LOCAL_APPS_EXTRAMOUNTS work even if the target dir is nonempty
18:44	<vagrantc> alkisg: seems reasonable.
18:48	<alkisg> Pushed, those were all the quick ones in my TODO list: http://pad.ubuntu-uk.org/ltsp
18:50	<vagrantc> alkisg: [v] is done?
18:53	* vagrantc wonders about LP#976344 ... it should get cleaned up
18:53	<vagrantc> oh, the symlinks.
18:54	looks like the symlinks are even backwards
18:56	<alkisg> vagrantc: we remove nbi images from the tftp dir in ltsp-update-kernels, but not from $chroot/boot in update-kernels
18:57	<vagrantc> oh
18:58	<alkisg> So we should probably check when we're called as part of postrm, get the removed kernel version, and delete that .nbi
18:59	If that's not possible, maybe we could loop through the .nbi images every time update-kernels is called
18:59	Parker955 is now known as Parker955_Away
19:00	<vagrantc> the first should work
19:00	<alkisg> Btw I wonder why "else
19:00	echo "ServerName ${LDM_SERVER}" > /etc/cups/client.conf" ===> is a good thing
19:00	<vagrantc> alkisg: as opposed to?
19:00	<alkisg> Not doing anything
19:01	Cups then detects all printers on the local network, not just the server ones
19:01	So currently fat clients can't print to their own printers unless CUPS_SERVER=localhost is set
19:01	<vagrantc> doesn't that allow you to relay through the cups server, rather than talk to the printers directly?
19:02	i.e. for printers on a different network without routing
19:02	or is that just the discovery server?
19:02	<alkisg> The client sees any printers published by the server anyway
19:02	<vagrantc> dunno then
19:02	<alkisg> So if you add some printer from another network to your server and check [x] publish printers, it will show up on the client
19:03	...I suppose that is there for localapps, right?
19:03	I think I want to try to remove the "else", and see if we get any complains
19:03	There's already a bug report for this
19:03	https://bugs.launchpad.net/ltsp/+bug/948372
19:04	It's not exactly the same issue, but it's related
19:05	Also it seems a bit silly to create the /etc/cups dir first and _then_ check for its existence to decide if cups is installed
19:06	<vagrantc> heh
19:06	probably part of how the code evolved
19:06	<alkisg> ...and finally I wonder why that is done in X01-localapps instead of init-ltsp.d
19:06	This way cups has to discover the printers on each login
19:08	<vagrantc> it would make some sense if it was part of the login process
19:08	i.e. you select a different LDM_SERVER
19:08	Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Read error: Operation timed out)
19:09	<alkisg> Hmmm if that LDM_SERVER isn't reachable with cups' avahi, maybe
19:11	<vagrantc> oh, pulseaudio-esound-compat vs. pulseaduio
19:11	komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.)
19:12	<alkisg> In a school they had 2 labs served by a single server. Users could login in any of those labs, and they wanted to be able to print to their nearest printer (in the lab they logged in). Couldn't solve that from the client side, I had to make a login script on the server to modify the user's ~/.cups/lpoptions
19:13	<vagrantc> should probabbly move server/share/ltsp/plugins/ltsp-build-client/Debian/010-pulseaudio-tweaks to an init-ltsp.d plugin, or at least mostly so
19:14	or explore weather it's still needed
19:18	alkisg: i'm tempted to drop support for esound and nas
19:18	at least from the debian dependency chains, if not upstream.
19:19	Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
19:21	<alkisg> vagrantc: I'm fine with both, never heard anyone using them 4 years here
19:22	komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
19:23	<vagrantc> there is some code change required to drop pulseaudio-esound-compat, looks like.
19:24	Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
19:25	<vagrantc> and there is some ugly code to support old pulseaudio versions that we could probably drop
19:30	<alkisg> vagrantc: why depend on cryptsetup instead of e.g. suggesting or recommending it? It adds some stuff to the initramfs...
19:32	<vagrantc> alkisg: because it is a feature that i believe is part of the core feature set
19:33	and swap over the network without encryption is insane.
19:33	<alkisg> More insane than LDM_DIRECTX?
19:34	<vagrantc> i think they're both crazy :P
19:34	<alkisg> I don't mind about disk usage, but I'd like to be able to get rid of features that need RAM and that I don't use... isn't "recommends" good enough for it?
19:34	I mean, it doesn't even work out of the box, it needs some lts.conf options, right?
19:34	<vagrantc> works out of the box for me
19:35	alkisg: i'd have to see how recommends is supported with upgrades
19:35	* alkisg fires up a thin client to check if nbd swap is encrypted by default...
19:36	<vagrantc> it is, admittedly, imperfect encryption, in that it never gets seeded with random data
19:37	and even if you did seed it with random data, that would go over the network...
19:37	<alkisg> Doesn't linux use the hwclock as random source?
19:38	<vagrantc> that's a separate issue
19:39	you're talking about a source of entropy, and i'm talking about someone being able to observe over the network the entirety of the encrypted stream
19:40	without seeding the file with random data first, it signficantly reduces the difficulty of breaking the encryption ... and there's no way to securely seed it with random data.
19:41	but at least it's better than LDM_DIRECTX :P
19:41	<alkisg> ...why would linux read swap partition sectors without writing them first?
19:41	I.e. any random data in it would never be read, right?
19:44	<vagrantc> sure, but someone with access to the file could break the encryption and get data out of the swap file, like passwords.
19:45	if the file contains completely random data, they don't know where the encrypted data is.
19:45	bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9)
19:45	<vagrantc> if it only contains encrypted data, they can more easily look for patters.
19:45	patterns.
19:45	because they know which data is potentially meaningful
19:46	i guess the way to handle it correctly is to have the server create the file with random data, but then sparse is useless.
19:47	and then the client runs mkswap on the encrypted volume.
19:47	<alkisg> If someone writes to the disk I'm sure he can at least crash the client :)
19:47	<vagrantc> sure
19:48	but reading is another issue
19:48	<alkisg> If someone reads all the network traffic, he could see what sectors the client writes anyway
19:48	<vagrantc> not worried about someone injecting data into the swapfile (though that would be a differentt issue)
19:48	<alkisg> So he'd know which parts of the file were written to
19:48	<vagrantc> as i said, it's not complete.
19:49	<alkisg> I wonder if ssh could be put in the initramfs so that all traffic is encrypted, and the e.g. nbd images and swap images are mounted with sshfs for those that need that extra security
19:49	<vagrantc> skip NBD entirely?
19:49	<alkisg> Yeah
19:50	<vagrantc> probably doable ... no idea if sshfs is reliable enough
19:50	<alkisg> It'd access them as plain files, so I don't see why it would have problems with them
19:50	<vagrantc> thhat would go along with my idea to implement a copy image to ram idea ... same kind of things needed.
19:51	well, some of the same things...
19:51	i did have issues with sshfs from the initramfs last time i tried
19:51	but that was several years ago no
19:51	now
19:52	alkisg: so, to drop the esound-compat stuff, i'm not sure if we need to modify the pulseaudio start call
19:52	alkisg: thhere's a line in there that enables the compat module.
19:53	<alkisg> Maybe it tries to load the module but doesn't fail if it doesn't exist...
19:54	<vagrantc> that's what i'm wondering ... or if there's a way to detect it on boot ... if the file is present, enable it kind oof thing
19:55	bieb has left IRC (bieb!~hbieber@173.226.16.130)
19:55	<alkisg> We can put an init-ltsp.d break and remove the pulseaudio-esound package and see if pulseaudio still works without it
19:56	* vagrantc has admittedly not tested sound support in quite some time
19:57	* vagrantc tests
19:57	<vagrantc> it fails
19:59	seems like it has a versioned path, so non-trivial to check for it
20:00	pulseaudio --dump-modules
20:01	seems to work ...
20:01	* vagrantc checks older versions
20:05	<vagrantc> works with squeeze versions, too.
20:07	Parker955_Away is now known as Parker955
20:09	<vagrantc> so, i could hack together some compatibility where if pulseaudio-esound-compat is installed, enable it ... but it also seems like a lot of work for ... what?
20:10	how many clients are out there that don't support alsa+pulseaudio but do support esound?
20:10	or i just leave it in.
20:14	<alkisg> vagrantc: meh, remove it and if someone ever files a bug report we can put it back :P
20:14	Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
20:15	<alkisg> You could make a debian/patches/patch for it, but I don't think it's worth it
20:15	<knipwim> alkisg: is the test -f "$chroot/usr/share/initramfs-tools/scripts/local-top/nbd" in ltsp-update-image needed?
20:15	it seems debian specific
20:16	<vagrantc> alkisg: ah, i've got the code, it's not too hrad.
20:16	hrad.
20:16	hard.
20:17	<alkisg> knipwim: I don't know who put the check there, I think we can leave it up to the sysadmin to verify that nbd is installed on the chroot, or check for /sbin/nbd-client...
20:17	Apparently typing "hard" is hrader :P
20:18	<vagrantc> it does involve a call to pulseaudio --dump-modules \| awk
20:18	<knipwim> or else make distro specific checks for the supported initrd tools
20:18	<vagrantc> though i just got rid of a pulseaudio --version check
20:18	* alkisg has never heard of anyone using esound so he thinks all those are too much
20:19	<stgraber> esound was useful back when gnome was using esd as sound server
20:19	but that was years ago and has been deprectated now
20:19	so no real reason to support it
20:20	<vagrantc> dropped, committed, pushed.
20:20	<alkisg> nice, nice, nice
20:20	<stgraber> do we still have artsd support? if so, it probably should also go away
20:20	<knipwim> alkisg: isn't nbd-client installed in /usr/sbin/nbd-client in ubuntu?
20:21	<alkisg> knipwim: no, it's in /sbin
20:21	<vagrantc> older versions may have installed in /usr/*bin
20:21	<alkisg> I guess people might need it to mount /usr with nbd
20:22	<knipwim> indeed
20:22	filing a gentoo bug :)
20:23	<alkisg> knipwim: I think the new trend is to move everything in /usr/
20:23	People say that the /sbin vs /usr/sbin separation was done because Richie had a small disk and was bored to repartition his new one
20:24	http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
20:26	knipwim: I think you can completely remove that check
20:29	<Hyperbyte> alkisg, Fedora's done that already actually... the whole OS in /usr
20:30	<alkisg> Some decades back I had a 40 MB hard disk and I wished that C:\Program files was read only so that I could put it in a CD
20:30	...little did I suspect that I'd have something similar 20+ years later :P
20:31	<knipwim> okay, removing it
20:31	alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
20:33	alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
20:42	khildin has joined IRC (khildin!~khildin@ip-80-236-227-228.dsl.scarlet.be)
20:44	<knipwim> alkisg: i'd like to make the service() function in ltsp-config distro specific
20:44	keeping the /usr/sbin/service "$@" as default
20:45	dgeary2 has joined IRC (dgeary2!~david@c114-77-214-254.rivrw3.nsw.optusnet.com.au)
20:45	<knipwim> and moving the invoke-rc.d "$@" to Debian ltsp-config-functions
20:46	gentoo uses rc-service "$@"
20:47	Parker955 is now known as Parker955_Away
20:48	bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
20:49	<alkisg> knipwim: by all means, I thought about that when I made the function but didn't have time to look at how other distros do it
20:49	dgeary2 has left IRC (dgeary2!~david@c114-77-214-254.rivrw3.nsw.optusnet.com.au, Ping timeout: 248 seconds)
20:50	<alkisg> In debian, invoke-rc.d is preferred because it respects the policy
20:51	knipwim: it's also possible to not define a "service" function
20:51	But only let distros that need to override it do so
20:51	(in that case they'll override the external utility called service)
20:53	<vagrantc> oops, i guess i accidentally committed my test changelog entries :(
20:53	<alkisg> ...and this is where bzr push --overwrite comes handy :P
20:53	bzr uncommit; bzr push --overwrite
20:54	and for those that pulled already, bzr uncommit; bzr pull
20:54	* alkisg does that all the time in epoptes-trunk
20:54	<vagrantc> i know :P
20:54	<alkisg> Hehe
20:54	<vagrantc> i'd rather just fix the commit and move forward
20:54	that's anti-social DVCS behavior :P
20:54	<alkisg> Aren't coders anti-social anyway? :D
21:09	bb all
21:09	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:18	alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
21:19	alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
21:20	<vagrantc> doh. should install the udev sound script as an init-ltsp.d hook
21:27	alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 252 seconds)
21:31	mgariepy_ has left IRC (mgariepy_!mgariepy@nat/revolutionlinux/x-mjcvomkdfqhcvhja, Ping timeout: 260 seconds)
21:57	alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
22:05	alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 252 seconds)
22:09	dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...)
22:11	komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.)
22:16	alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
22:30	darkpixel_ has left IRC (darkpixel_!~darkpixel@curetheitch/staff/darkpixel, Quit: Leaving.)
22:40	Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
22:59	bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 248 seconds)