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

Channel log from 25 August 2012 (all times are UTC)

00:11	Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
00:14	humph has joined IRC (humph!7a6aa9a8@gateway/web/freenode/ip.122.106.169.168)
00:44	andygraybeal has joined IRC (andygraybeal!~andy.gray@obsidian.casanueva.com)
00:55	ry has left IRC (ry!~ry@static-71-183-64-28.nycmny.fios.verizon.net, Ping timeout: 272 seconds)
01:05	ry has joined IRC (ry!~ry@static-71-183-64-28.nycmny.fios.verizon.net)
01:20	staffencasa__ has left IRC (staffencasa__!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
01:22	dgeary2 has joined IRC (dgeary2!~david@114.72.238.37)
01:30	jocarter has left IRC (jocarter!~highvolta@ubuntu/member/highvoltage, Ping timeout: 260 seconds)
01:30	dgeary2_ has joined IRC (dgeary2_!~david@42.241.75.146)
01:33	dgeary2 has left IRC (dgeary2!~david@114.72.238.37, Ping timeout: 260 seconds)
01:38	dgeary2_ is now known as dgeary2
01:46	Parker955_Away is now known as Parker955
02:25	Parker955 is now known as Parker955_Away
03:20	jocarter has joined IRC (jocarter!~highvolta@ubuntu/member/highvoltage)
03:56	sha has joined IRC (sha!~sha@e177165066.adsl.alicedsl.de)
03:56	adrianorg has left IRC (adrianorg!~adrianorg@201.22.230.206, Ping timeout: 276 seconds)
03:57	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:59	sha_ has left IRC (sha_!~sha@e177119115.adsl.alicedsl.de, Ping timeout: 245 seconds)
04:32	<darthanubis> https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
04:33	The end of that page does not even read like english
04:33	is ok since nbd-server is started using this inetd line:
04:33	everything after that line?
04:35	<alkisg> darthanubis: did you get your kernel/initramfs to load?
04:37	That wiki paragraph is completely outdated, don't bother yourself with it. The "is ok since nbd-server is started using this inetd line: " is part of the sentence that starts a few lines above, " So, the error ... is ok since..."
04:40	<darthanubis> alkisg,I was able to actually get the client to log in to desktop, about 4hrs ago
04:40	Can't seem to repeat it since
04:41	<alkisg> So now where does booting stop?
04:41	<darthanubis> I reinstalled the isc-dhcp-server
04:41	before that I was stuck
04:41	<alkisg> Ah, and you now have a dhcp server conflict, so it only works a few times, ok
04:42	It'll also cause problems to other, non-ltsp clients in your network
04:42	<darthanubis> now it just hangs at trying to load pxelinux.cfg/default
04:42	<alkisg> You need to focus on fixing your dhcp server. If you cannot do that, you need dnsmasq in proxydhcp mode, not isc-dhcp-server.
04:43	<darthanubis> will I need two nic for dnsmasq?
04:43	<alkisg> No
04:43	<darthanubis> ok
04:43	removing isc-d-s
04:43	<alkisg> But don't go there just yet. Fix your main dhcp server
04:43	<darthanubis> well the main dhcp-serveris passing along the boot to the ltsp-dhcp server
04:44	<alkisg> !ipxe
04:44	<ltsp> alkisg: ipxe: iPXE is the successor to the etherboot/gPXE project, and can be used to netboot clients that don't have a NIC ROM with a PXE stack. To add it to grub, see !grub-ipxe. To add it to the Windows boot loader, see !win32-loader. To download floppy, CD or USB images, visit http://ipxe.org or install the ipxe package.
04:44	<darthanubis> When I removed the ltsp-dhcp server the pxelinux file was never found
04:44	<alkisg> Yeah, because your dhcp server is misconfigured
04:44	<darthanubis> hmph:(
04:44	<alkisg> So the ltsp dhcp server was trying to send the correct info, but it had collisions with the real one
04:44	That'll never work right
04:44	Can you boot a client with an ipxe cd or usb stick?
04:45	ipxe has a nice menu which reports the boot info
04:45	so it'll convince you that your dhcp server is still wrongly configured
04:46	I.e. something like this: http://ipxe.org/_media/screenshots/config_ui.png?w=360&h=200
04:46	<darthanubis> just got the iso
04:47	<alkisg> ...or this: http://wiki.jpoetry.net/_media/files:gpxe-003.png
04:48	So, once you boot with ipxe, you'll see a message saying "press ctrl+b to enter command line"
04:49	Do press ctrl+b, and on the command line, write those 2 commands:
04:49	dhcp net0
04:49	config
04:49	You'll get a configuration dialog that shows you the info passed by your dhcp server (assuming that you stopped + uninstalled isc-dhcp-server)
04:49	There, you need to verify the following:
04:49	next-server == the ltsp server ip
04:50	filename = /ltsp/i386/pxelinux.0
04:50	root-path = /opt/ltsp/i386
04:51	<darthanubis> holy crap, it booted into the thin client asap
04:51	I did not even have a chance to press anything
04:51	wow
04:51	now I'm really confused
04:52	<alkisg> ipxe has a bit better boot code than most roms
04:52	Did you remove isc-dhcp already?
04:52	<darthanubis> nope
04:52	<alkisg> So it preferred the info from your ltsp server instead of your real dhcp server
04:53	<darthanubis> did not touch a thing, you told me to wait and do this first
04:53	<alkisg> That's not what you want, it'll give you problems
04:53	<muppis> Strange. Not really ltsp related, but happened to fat client. Could boot and access to lan, but not to internet.
04:53	<alkisg> muppis: gateway?
04:53	darthanubis: sudo service isc-dhcp-server stop; sudo apt-get purge --auto-remove isc-dhcp-server
04:53	Then reboot the client with ipxe
04:54	<muppis> alkisg, almost. Booted over wlan bridge and client-end wlan was stuck. Other end is a gateway.
04:54	<darthanubis> ok
04:56	<muppis> Using Buffalo WBMR-HP-G300 as gw, wlan, dnsmasq, adsl, firewall, ...
04:58	<darthanubis> alkisg,ok it shows everything but filename, thereis not "root path" category
04:59	<alkisg> OK, do fix the filename
04:59	Clients won't boot without it
05:00	<darthanubis> here is where it gets hairy here....the gateway has the field "File path in next server"
05:01	not filename
05:01	<alkisg> Do you have a link to online documentation about the system you're using? E.g. a picture with the confguration? Search with google images..
05:01	<darthanubis> ok, in the ipxe utility there is a root path cat. I just had to scroll down
05:01	yes
05:02	one sec
05:02	http://doc.zentyal.org/en/dhcp.html
05:02	To make it more confusing, there are two locations for passing next server
05:03	on the first tab there and the advanced tab
05:03	The advanced tab actually has a thin client section. The next release of Zentyal actually will have ltsp intergrated
05:04	The RC is currently too buggy for me
05:04	<alkisg> I don't see a next-server option on the first tab
05:04	Put the info in the thin client section
05:04	next-server, and filename. Don't bother with next-server filename.
05:04	<darthanubis> Scroll down to the advanced section
05:05	so use path and not filename
05:05	?
05:05	<alkisg> http://doc.zentyal.org/en/_images/dhcp_advanced.png
05:05	Use next -server and filename
05:05	Don't use path
05:06	Remember to restart the dhcp service on the zentyal server
05:07	(unless it does that automatically upon saving the settings)
05:07	<darthanubis> That is amazing. That is not what my screen looks like. I don't have the option for none as a next server, nor do I have filename option.??!!
05:07	one sec, thats strange
05:07	<alkisg> Btw, until you manage to get ipxe to receive the correct info, it's a zentyal problem, so if you don't manage to do it, ask in their irc channel; we don't know about zentyal here
05:08	<darthanubis> I understand
05:08	<alkisg> darthanubis: you don't want none as your next server. You want the ltsp server ip as the next-server.
05:09	<darthanubis> I know, just don't know why it appears I'm missing options
05:12	<alkisg> Hmm not many people around in #zentyal... also, I think if you weren't using zentyal, you'd have solved your problem days ago :)
05:13	You just need to modify 2 dhcp options, it would be much easier to do them in a text file than this...
05:13	<darthanubis> interesting, changing the path in zentyal changes the filename in ipxe
05:14	I had it working today
05:14	and yesterday on ClearOS
05:14	just passed it through
05:14	but I did not remove the isc server
05:14	I can see havign two dhcp servers is bad though
05:15	<alkisg> OK, sorry, it looks like you prefer experiments rather than following advice.. I'll head on to my work, hope you solve the issue.
05:15	<darthanubis> don't know where that came from. I was just sharing my experience
05:16	<alkisg> (08:14:27 πμ) darthanubis: but I did not remove the isc server
05:16	<darthanubis> I'm not experimenting
05:16	<alkisg> Ah you mean yesterday?
05:16	<darthanubis> I did not, I did not know what I was doing
05:16	yeah
05:16	<alkisg> OK, sorry then, misunderstood
05:16	<darthanubis> that was before I got straightened out
05:16	<alkisg> Just to be clear, now there's no dhcp service on your ltsp server, right?
05:16	<darthanubis> right
05:16	<alkisg> Because it would make troubleshooting really really complex
05:17	On your ltsp server: sudo netstat -nap \| grep :67
05:17	==> should be empty
05:18	<darthanubis> it is
05:18	<alkisg> Cool, ok, go on with configuring zentyal until you see the correct results in the ipxe config screen
05:18	When you do, the client should be able to boot
05:19	You don't need to reboot the client each time that you want to check the results; just write dhcp net0 and config again
05:19	<darthanubis> ok
05:20	well I have the correct entries, filename is correct, but I can't set path. It finds the file, and just says loading like the original rhin client
05:21	oooh, there it goes
05:21	it booted
05:21	it's like hit or miss
05:22	<alkisg> root-path isn't used on ubuntu, so it's ok. But, a few rare clients do need it even if it's unused, so if you have a specific client that doesn't boot, try to fix it, else, ignore it
05:22	So now try to boot without ipxe, and also other clients etc
05:22	<darthanubis> trying now
05:27	<alkisg> darthanubis: wait, after getting the correct entries, you still have hit or miss problems?
05:27	<darthanubis> Thank you for the intro to ipxe. It is booting into the client everytime
05:27	My original client, just hanging there
05:27	no problems with ipxe
05:27	boots everytime
05:27	<alkisg> OK, so, here are 2 possible problems:
05:28	<darthanubis> ok
05:28	<alkisg> 1) root-path. Try to fix that first
05:28	2) boot filename is a bit tricky:
05:28	The dhcp protocol has 2 places where it can be set
05:28	Inside the dhcp structure, on in an extended set of options
05:28	ipxe supports both, as do most recent clients
05:28	But some clients only like the boot filename inside the dhcp structure
05:29	So, all dhcp servers have a configuration option for that
05:29	In dnsmasq, the configuration is called "dhcp-no-override"
05:29	I don't know where zentyal exposes that option
05:29	<darthanubis> hmm
05:32	<alkisg> Try the root-path first.
05:32	<darthanubis> ok
05:36	alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
05:37	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 276 seconds)
05:38	<darthanubis> alkisg1,while looking into making those changes, the slow client finally booted
05:38	alkisg1 is now known as alkisg
05:38	<alkisg> How slow? How many seconds to the login screen?
05:39	<darthanubis> That had to be 10mintures
05:40	<alkisg> How much client RAM?
05:40	<darthanubis> hmm
05:41	2Gs
05:41	The client is not slow
05:42	I think I have to find a way to either fix those issues you brought to my attention, or try different clients
05:42	At least ipxe lets me know I'm not crazy
05:42	<alkisg> Does it boot fast with ipxe?
05:42	<darthanubis> yup
05:42	almost instantly
05:43	<alkisg> And when it boots slowly without ipxe, do you see the ubuntu logo screen for 10 minutes, or it's still in the pxe stage for the first 10 minutes?
05:44	<darthanubis> pxe stage for 10mins
05:44	<alkisg> OK still a dhcp configuration problem then
05:44	Did you fix root-path?
05:45	<darthanubis> can't see how at the moment. There is no option, and path actually means filename in this goofy zentyal on my machine
05:45	alomst makes me want to reinstall my dhcp module
05:46	<alkisg> If you can't fix zentyal, or ditch it, there's another method called proxydhcp that can help, but it'll take you a few minutes to remove the boot filename from zentyal and to configure dnsmasq in proxydhcp mode on your ltsp server
05:46	<cyberorg> alkisg, http://software.opensuse.org/package/epoptes
05:47	<alkisg> cyberorg: cool!!! /me writes a news item at epoptes.org about it...
05:47	cyberorg: how close is opensuse with fedora? Would that mean that getting it to fedora now would be easier?
05:48	<cyberorg> alkisg, on build service we can build packages for fedora, mandriva, debian, ubuntu, centos, rhel, and few more
05:48	<alkisg> Very nice
05:48	<cyberorg> if anyone from other distro is interested ping me :)
05:49	packages are built on the target distro VM so they are 100% native packages
05:50	<alkisg> cyberorg: any objections to mentioning your real name in the epoptes news?
05:51	Or, if you have a link in opensuse.org about you...
05:51	Hmm I could link there, if you don't mind: http://en.opensuse.org/User:Cyberorg
05:52	<cyberorg> http://en.opensuse.org/User:Cyberorg no problem with real name, its there in IRC handle as well
05:57	alkisg, btw did you know the screenshot http://software.opensuse.org/package/* comes from debian?
05:58	<alkisg> cyberorg: nope, but I was the one that uploaded it there ;)
05:58	It's nice to have distros cooperate on things like that... and I really hope in the future they settle on the same packaging methods
05:59	<Hyperbyte> alkisg, fat chance.
05:59	<alkisg> Hyperbyte: well, when in the future linux users start shifting to android, companies behind distros will realize they can't afford not to cooperate anymore
05:59	<Hyperbyte> cyberorg, couldn't KIWI-LTSP work on Fedora?
06:00	<cyberorg> yes, open build service ;) upload source .spec/deb files and it does building for different archs and distros without packager having to worry about details :)
06:00	Hyperbyte, yes
06:00	<Hyperbyte> cyberorg, how difficult is it, to get it working?
06:00	<cyberorg> alexqwesa, is working on way to build ltsp image on unsupported distros using chroot/vm
06:01	Hyperbyte, this difficult at the moment http://old-en.opensuse.org/LTSP/Other_Distros
06:03	<darthanubis> alkisg,brb, I'm going to try to boot my laptop from the server
06:03	<alkisg> http://www.epoptes.org/news :)
06:03	ok
06:03	<Hyperbyte> cyberorg, you should really start developing this stuff in the main LTSP branch more. I'd love to get a good version of LTSP packaged with Fedora/RHEL/CentOS by default
06:03	darthanubis has left IRC (darthanubis!~darthanub@cpe-71-79-187-73.neo.res.rr.com, Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet)
06:05	sutula has left IRC (sutula!sutula@nat/hp/x-syxnkkdinmkcefun, Quit: Terminated with extreme prejudice - dircproxy 1.0.5)
06:05	<cyberorg> Hyperbyte, you can see here what we do, its not related to upstream http://kiwi-ltsp.svn.sourceforge.net/viewvc/kiwi-ltsp/trunk/
06:05	http://kiwi-ltsp.svn.sourceforge.net/viewvc/kiwi-ltsp/trunk/kiwi-ltsp/ltsp/
06:06	sutula has joined IRC (sutula!sutula@nat/hp/x-oialajncvrtmdxal)
06:08	<Hyperbyte> cyberorg, what I mean is that most of those things could just be included in LTSP by default
06:09	darthanubis has joined IRC (darthanubis!~darthanub@cpe-71-79-187-73.neo.res.rr.com)
06:09	<Hyperbyte> And set so that they only come into play once a client image is built or updated on OpenSUSE. But some things might be useful for all distros, like the GUI.
06:10	<cyberorg> Hyperbyte, no, as the kiwi-ltsp script is what you'd call an ugly hack :) it modifies other daemons config files
06:10	<Hyperbyte> Anyway... that's how I feel about it. :P
06:10	<cyberorg> it is like old ltsp admin script
06:10	<alkisg> ltsp-config does the same too, because we can't do that on package postinst
06:11	Debian policy says it's ok to provide tools that modify other daemon config files, as long as you don't do it as part of your installation scripts
06:11	...and leave it up to the administrator to do it when he wants
06:11	<darthanubis> alkisg,yeah, it was unacceptably slow
06:11	<alkisg> ltsp-config also supports function overlaying, e.g. knipwim had put support for gentoo there
06:12	<cyberorg> may be some day when all the cross distro bits are complete we can see how to get it upstream
06:12	<darthanubis> I will there was a file I could edit besides the gateway for now. Otherwise, I'm going to have to rebuild the gateway:(
06:12	<cyberorg> alexqwesa has been adding stuff to make it distro independent, so hopefully ... :)
06:13	<Hyperbyte> cyberorg, this would rock. :)
06:13	<alkisg> Debian has live-build, we could use that in LTSP in the same sense that opensuse/ltsp uses kiwi
06:13	We could build chroots with it, use its initramfs and services hooks etc
06:14	But I don't think it's a good idea, those tools are too distro-specific to rely upon them
06:14	I think LTSP deserves its own ltsp-config, init-ltsp.d etc systems
06:14	<cyberorg> kiwi already has support for rhel, so fedora/centos/clones should be easy to get working
06:15	as always it needs someone from that distro to pick it up :)
06:15	<Hyperbyte> cyberorg, well at least it'll become an easier task. Last time Warren had lots of work to get LTSP working with current CentOS.
06:16	Last time Warren was in here he was talking about training his replacement at RedHat though
06:17	<cyberorg> Hyperbyte, that is what i didn't understand, there has been nothing we needed changed in ltsp upstream to get it working on suse right from the beginning, long before fedora
06:17	<Hyperbyte> I think if it becomes easier to integrate LTSP, more people would be interested.
06:18	cyberorg, Warren had problems with modern Fedora kernels not supporting i386 hardware, so he had to make it build Fedora 11 chroot, he also had problems with sound and local devices I think...
06:18	<cyberorg> it would be lot easier if everyone used same initrd system
06:18	may be dracut one day
06:19	<Hyperbyte> (which he fixed, but naturally Warren does all his work seperate from upstream as well)
06:19	<knipwim> cyberorg: i'm trying to get dracut working on gentoo
06:20	<cyberorg> knipwim, people were/are probably working to get it on opensuse http://blog.crozat.net/2012/07/my-hackweek8-project-dracut.html
06:20	knipwim, so you should be able to achieve a lot in a week as well :)
06:20	<knipwim> check, well, there is a package
06:21	in it actually works for nfs ltsp boots (untill 0.14)
06:22	i really want it for nbd ltsp booting on gentoo
06:22	<cyberorg> knipwim, what do you use for overlay on nfs, got it finally working with unionfs-fuse now
06:23	<knipwim> cyberorg: with the ltsp distro overlaying system it has become much easier to integrate it with your own distro
06:23	<warren> Hyperbyte: not at redhat, some volunteer
06:23	<knipwim> cyberorg: bind mounts still
06:23	<warren> Fedora/RHEL lacks any type of overlay mount
06:24	<knipwim> but i heard overlayfs might be in the kernel (3.7)
06:24	<cyberorg> knipwim, https://bugzilla.novell.com/show_bug.cgi?id=776505 thats how unionfs would work
06:24	<warren> Hyperbyte: I do all my work separate from upstream?
06:24	<cyberorg> with unionfs-fuse we don't have to worry about kernel supporting it
06:24	<warren> cyberorg: oh, is that stable now?
06:24	Hyperbyte: I pushed everything to upstream LTSP, but I haven't had time to work on it for a year now.
06:24	<cyberorg> warren, i have been testing it for some time, looks quite good
06:25	<warren> cyberorg: ok, I'll consider using unionfs-fuse
06:25	<knipwim> cyberorg: me too
06:25	<cyberorg> probably the same will work with nbd/aoeroot
06:27	check what the command is called on your distro, it is unionfs on suse, unionfs-fuse somewhere else
06:27	<knipwim> yeah, gentoo has a unionfs-fuse package, so that looks promising
06:28	<cyberorg> havent tested with rw cow, it would be interesting if it worked :)
06:28	<knipwim> working on my nbd boot error with dracut
06:28	basically i get a Negotiation: ..size= 4229768MBError: Exported device is too big for
06:28	me. Get 64-bit machine :-(
06:29	on an image of less than 1Gb
06:29	if you guys have any clues
06:30	<cyberorg> knipwim, first try nbd-client serverip /dev/nbd0 working on normal pc
06:30	*port
06:30	<knipwim> that works
06:30	also port-based works
06:31	<cyberorg> do you get shell in initrd?
06:31	<knipwim> and a name-based one using nbd-client
06:31	yes
06:31	<cyberorg> manually doing nbd-client works?
06:32	<alkisg> (09:28:05 πμ) cyberorg: havent tested with rw cow, it would be interesting if it worked :) => I tried with a rw nbd-server export, worked fine!
06:32	So no need for overlayfs etc there
06:32	<knipwim> cyberorg: i'll try
06:32	<cyberorg> alkisg, i mean ro image/nfs with rw cow per client
06:34	knipwim, may be nbd-client version in initrd is bugged, which one are you using busybox/normal nbd-client? busybox does not like -persist
06:36	<alkisg> cyberorg: nfs is sent uncompressed over the network, even if the underlying fs is compressed (e.g. btrfs). With fat clients becoming more widespread as client hardware matures and as DEs require 3d acceleration etc, I'd rather invest in compressed btrfs chroots than in nfs...
06:36	A compressed btrfs chroot can be easily maintained with ltsp-chroot, without any need for ltsp-update-image etc
06:36	And `nbd-server -c` exports it as cow, with the writes going in a separate temp file on the server
06:36	<cyberorg> alkisg, yes, that is the future
06:38	<knipwim> cyberorg: i guess... i'm using busybox-1.20.1 and nbd-client-2.9.22
06:38	don't know what the -persist is about
06:39	<cyberorg> knipwim, in initrd shell try with normal nbd-client serverip... and then busybox nbd-client serverip...
06:39	<alkisg> knipwim: I'm getting that error when (a) there's no matching [ltsp_i386] or [/opt/ltsp/i386] header in the nbd-server .conf files, or (b) when I try to export a directory instead of a file
06:39	knipwim: so I'd try to strace nbd-server...
06:39	To see what file it tries to access
06:40	<cyberorg> 2.9.22 is very old
06:40	<alkisg> Afaik -persist is broken on the kernel module side... don't know if it was fixed very recently
06:41	<cyberorg> 2.9.20 works with xinted, anything later use standalone, try 3.2
06:42	alkisg, busybox nbd-client does not recognize that option
06:42	<alkisg> cyberorg: which one? -c? That's for nbd-server, not the client
06:42	The client doensn't know that the rw root is actually cow on the server
06:42	<cyberorg> -persist
06:42	<alkisg> Ah. Well, it doesn't really work anyway
06:43	<cyberorg> alkisg, you can point to http://download.opensuse.org/repositories/server:/ltsp/openSUSE_12.2/src/ if other rpm based distro wants starting point
06:43	<alkisg> Cool, ty
06:44	<cyberorg> src.rpm for epoptes is there
06:44	now i can finally retire italc
06:46	<alkisg> cyberorg: epoptes-client is normally launched from if-up.d,
06:47	the sysvinit service is only there for old ltsp chroots that deleted the network service, at least in debian/ubuntu
06:47	<cyberorg> alkisg, i've put /etc/init.d/epoptes-client
06:47	<alkisg> So you might want to replace epoptes-client.init with something like this: http://bazaar.launchpad.net/~epoptes/epoptes/trunk/view/head:/debian/epoptes-client.if-up
06:47	As /etc/init.d/epoptes-client won't work for standalone workstations
06:47	It only works in old LTSP chroots, not even in new ones
06:47	tuv0k has joined IRC (tuv0k!~darthanub@cpe-71-79-187-73.neo.res.rr.com)
06:47	<alkisg> It'll be removed in the future, once people stop using LTSP < 5.3
06:48	<cyberorg> why doesn't it work? all it does it run /usr/sbin/epoptes-client
06:48	<alkisg> See the checks it does:
06:48	test -f /etc/ltsp_chroot \|\| exit 0
06:48	grep -qs "init=/sbin/init-ltsp" /proc/cmdline && exit 0
06:48	E.g ./etc/ltsp_chroot isn't there on recent ltsp versions
06:49	<cyberorg> ah, we can remove those check then it will work?
06:49	<alkisg> Yes, but it's better to launch it from if-up, so that you ensure there's a network connection established
06:50	darthanubis has left IRC (darthanubis!~darthanub@cpe-71-79-187-73.neo.res.rr.com, Ping timeout: 256 seconds)
06:50	tuv0k is now known as darthanubis
06:50	<alkisg> From if-up you also get a small "reconnection" feature, as now it lacks support for client reconnects
06:50	<cyberorg> Required-Start: $network should take care of that?
06:51	<alkisg> Ubuntu doesn't respect the headers there due to upstart, if systemd does respect them it would take care of the networking part, but not of the reconnection part
06:52	But anyway if networking is not yet ready, epoptes-client waits until it is, so it's not a big problem, you just lose some reconnection ability
06:53	<cyberorg> why would it lose connection?
06:53	<alkisg> Suppose a student in a standalone workstation pulls out the network plug
06:54	When he plugs the cable again, if you're using if-up.d, then epoptes-client will reconnect, otherwise not
06:54	<cyberorg> can't something like that be scripted in epoptes-client? ping the gateway at interval and reconnect when it becomes available again
06:55	<alkisg> Yes, but it would require an external loop, i.e. a second shell process, and we wanted to save RAM for thin clients, as if you pull the network plug in ltsp you're screwed anyway
06:55	So we postponed the reconnections feature until the client is rewritten in C
06:56	<cyberorg> we don't have ifup.d
06:56	<alkisg> OK, but I think you do have a framework for running processes triggered by networking events... let me google..
06:56	<cyberorg> sorry we do, if-up.d
06:57	<warren> btw
06:57	did you folks adapt to the new nbd-server with an official port number?
06:57	<alkisg> Yup
06:57	We even removed most of the old port based code
06:58	It's all name-based exports now
06:58	Even swap
06:58	<warren> is that in LTSP upstream?
06:58	<alkisg> Yes
06:58	<warren> ok
06:58	i'll have to see if it is compatible here
06:58	I think that happened after RHEL6 though
06:58	the nbd-server part
06:58	<cyberorg> warren, you'd probably need nbd > 3.0
07:00	<alkisg> In Debian name-based exports were implemented in 2.9.18, no idea about other distros...
07:00	<knipwim> alkisg: i can't make heads or tails from the strace: http://dpaste.com/791314/
07:01	<cyberorg> alkisg, includedir didn't work at least on 2.9.20 we had in 12.1
07:01	<knipwim> s/or/nor/ :)
07:03	warren: fyi, we described some packaging info in the wiki: http://wiki.ltsp.org/wiki/Packaging
07:03	<alkisg> knipwim: the problem might be earlier, try strace -e trace=file
07:04	<knipwim> warren: and also the config file inclusion logic: http://wiki.ltsp.org/wiki/Commands#Design
07:04	<alkisg> It should access /opt/ltsp/images/i386.img at some point, if it doesn't, it's a configuration (might also mean bug in the code) error...
07:05	<knipwim> using nbd-3.2 now on the server and client
07:07	<alkisg> knipwim: strace from working setup: http://paste.debian.net/185517/
07:08	<knipwim> where the 2505 is nbd-server?
07:08	<alkisg> Just the pid name of the service
07:08	connect(5, {sa_family=AF_FILE, sun_path="/dev/log"}, 110) = -1 EPROTOTYPE (Protocol wrong type for socket) ==> I wonder if it chokes there
07:08	Do you have /dev/log ?
07:10	srw-rw-rw- 1 root root 0 Aug 25 06:53 /dev/log
07:10	<knipwim> i got it on the server
07:10	not on the client
07:11	<alkisg> OK.. did you try nbd-server -d ?
07:11	"-d Do not fork. Useful for debugging."
07:15	Also verify that it actually does read your configuration files, like e.g. in http://paste.debian.net/185519/
07:22	<cyberorg> alkisg, are these related to epoptes or general gnome thing? http://paste.opensuse.org/12545375
07:22	<alkisg> I think general gnome, we'll have to ask phantomas, he's the gtk expert
07:22	I get a few of those here in any gtk app
07:28	komunista has joined IRC (komunista!~slavko@adsl-195-168-234-168.dynamic.nextra.sk)
07:35	<knipwim> alkisg: okay, i got a "Can't open authorization file (null) (Bad address)."
07:35	probably #authfile = /etc/ltsp/nbd-server.allow
07:36	<alkisg> I think that shouldn't matter
07:36	Don't create one, you'll hit another bug there
07:36	<knipwim> but it connects from the dracut shell now
07:38	weird, but now from the boot process
07:39	no errors either on the server side, except negotiation failed
07:40	<alkisg> That's name-based, right? What's the client command line?
07:42	<knipwim> nbd-client 192.168.0.1 -N ltsp /dev/nbd0
07:42	but i'll doublecheck the command dracut is actually using
07:49	ricotz has joined IRC (ricotz!~rico@p5B2AD8E5.dip.t-dialin.net)
07:49	ricotz has joined IRC (ricotz!~rico@unaffiliated/ricotz)
07:53	<knipwim> alkisg: yeah, the exact same line
07:53	<alkisg> knipwim: and your config file?
07:54	<knipwim> [generic]
07:54	[ltsp]
07:54	exportname = /opt/ltsp/images/i686-dev.img
07:54	readonly = true
07:57	alkisg: i'm thinking the problem is in dracut somehow, because the cmd works in the dracut shell, but not in the actual boot process
07:57	<alkisg> Ah if it works in the shell then yeah that makes sense
08:04	darthanubis has left IRC (darthanubis!~darthanub@cpe-71-79-187-73.neo.res.rr.com, Ping timeout: 244 seconds)
08:04	<knipwim> alkisg: thx for the debugging help btw
08:04	<cyberorg> alkisg, epoptes needs a popup that says "add yourself to epoptes group, log out and back in to access it"
08:04	<knipwim> i hope to get gentoo ltsp in the 21st century soon :)
08:05	<alkisg> cyberorg: nah it needs to use newgrp if the user already added himself to the epoptes group...
08:05	<cyberorg> right now clicking the .desktop icon does not do anything that makes user think that something is broken
08:05	<alkisg> So that no logout is needed
08:05	(or a dialog if he isn't in the epoptes group, but I think we already have that)
08:05	<cyberorg> launching from terminal works with newgrp
08:05	<alkisg> Right, we need to add that into epoptes itself
08:07	khildin has joined IRC (khildin!~khildin@ip-80-236-228-129.dsl.scarlet.be)
08:35	<cyberorg> alkisg, what happens if there are multiple epoptes servers in a network, which server does epoptes-client -c fetches?
08:35	epoptes-client -c serverip would be more safer?
08:35	<alkisg> cyberorg: `epoptes-client -c` uses the dns name "server" by default, so it's up to your dns to handle that
08:36	<cyberorg> ah ok
08:36	<alkisg> It does support passing an ip
08:36	There's also a configuration file in debian, at /etc/default/epoptes-client
08:36	#SERVER=xxx
08:36	If one uncomments the SERVER variable, it overrides the default "server" name...
08:37	<cyberorg> k
08:37	<alkisg> http://bazaar.launchpad.net/~epoptes/epoptes/trunk/view/head:/debian/epoptes-client.default
08:45	<knipwim> alkisg: jeej! it's connecting!
08:45	<alkisg> Whoah, what changed?
08:45	<knipwim> not booting though
08:46	apparently the dracut boot process executed nbd-client 192.168.0.1 '-N ltsp' /dev/nbd0
08:46	removing the quotes fixed it
08:46	you wouldn't need quotes with port-based nbd mounts either right?
08:47	<alkisg> Ah, damn ps not showing the quotes, need cat /proc/pid/cmdline to check...
08:47	Nope
09:06	qwebirc72558 has joined IRC (qwebirc72558!3b1c4959@gateway/web/freenode/ip.59.28.73.89)
09:07	qwebirc72558 has left IRC (qwebirc72558!3b1c4959@gateway/web/freenode/ip.59.28.73.89, Client Quit)
09:17	dgeary2 has left IRC (dgeary2!~david@42.241.75.146, Quit: ĝis la)
09:24	ricotz has left IRC (ricotz!~rico@unaffiliated/ricotz, Remote host closed the connection)
09:30	darthanubis has joined IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com)
09:40	darthanubis has left IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com, Ping timeout: 245 seconds)
09:40	darthanubis has joined IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com)
09:47	<cyberorg> alkisg, https://build.opensuse.org/package/binaries?package=epoptes&project=Education&repository=Fedora_16
09:48	<alkisg> Cooool! :)
09:48	<cyberorg> not published, but that is how easy it is to build packages, see if someone on fedora can test it
09:49	we call it python-Twisted, they call it python-twisted, that was the only change required
09:53	ricotz has joined IRC (ricotz!~rico@p5B2AD8E5.dip.t-dialin.net)
09:53	ricotz has joined IRC (ricotz!~rico@unaffiliated/ricotz)
09:56	<cyberorg> alkisg, https://build.opensuse.org/package/rdiff?opackage=epoptes&oproject=server%3Altsp&package=epoptes&project=Education&rev=4
09:56	that shows the diff
10:00	<alkisg> Hehe, that's nice, I'll try to find some fedora user to test it
10:27	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:09	andygraybeal has left IRC (andygraybeal!~andy.gray@obsidian.casanueva.com, Quit: Ex-Chat)
11:23	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
11:52	tuv0k has joined IRC (tuv0k!~darthanub@cpe-66-61-37-133.neo.res.rr.com)
11:55	darthanubis has left IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com, Ping timeout: 265 seconds)
11:55	tuv0k is now known as darthanubis
11:59	Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
12:06	telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection)
12:08	telex has joined IRC (telex!~telex@freeshell.de)
12:12	komunista has left IRC (komunista!~slavko@adsl-195-168-234-168.dynamic.nextra.sk, Ping timeout: 272 seconds)
12:27	komunista has joined IRC (komunista!~slavko@adsl-195-098-013-109.dynamic.nextra.sk)
12:30	adrianorg has joined IRC (adrianorg!~adrianorg@201.22.230.206)
12:41	tuv0k has joined IRC (tuv0k!~darthanub@cpe-66-61-37-133.neo.res.rr.com)
12:43	darthanubis has left IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com, Ping timeout: 264 seconds)
12:43	tuv0k is now known as darthanubis
12:47	Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 246 seconds)
13:01	darthanubis has left IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com, Ping timeout: 276 seconds)
13:01	Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
13:10	<cyberorg> alkisg, client side shouldn't require python-gtk just for message popup at LDM, cant you use the same toolkit that ldm is using?
13:10	<alkisg> cyberorg: I think we're also using it to get screenshots... ldm is also using gtk, but it's not written in python
13:11	Right, for screenshots and for screen locking
13:12	cyberorg: the python-gtk2 package is less than 1 mb though, it shouldn't cause any problems...
13:12	<cyberorg> locking needed at ldm?
13:13	yes, was just trying to see if we can do without :)
13:13	<alkisg> No, but we can't have different package dependencies, depending on whether it's installed in an ltsp chroot or not
13:13	<cyberorg> right
13:13	<alkisg> We could have an epoptes-ltsp-client package just for that, but I don't think it's worth it
13:14	<cyberorg> no, anyway compressed python-gtk wouldn't amount to much
13:16	i had added python-twisted, which was 25M more, removed it as it is not required in the client
13:19	<alkisg> The debian/control file lists the required dependencies, at least for debian/ubuntu
13:28	<cyberorg> alkisg, also instead of librsvg, you can use png image? thats what ldm uses for logo, i know only few kb(250) more :)
13:29	btw how big is ubuntu image?
13:30	<alkisg> libsvg is for reading /usr/share/epoptes-client/lock.svg
13:31	bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
13:31	<alkisg> That's 8.6 kb, while rendering it as a png would make it larger
13:31	(and it would be resolution dependend, etc etc)
13:32	<cyberorg> librsvg-2-2-2.36.1-2.1.2.i586 220.1 KiB (853.1 KiB unpacked
13:33	i meant the ltsp image how big is it?
13:34	<alkisg> I think the compressed thin nbd image is 250 mb nowadays
13:34	Uncompressed it would be around 700-800 mb
13:37	<cyberorg> 168M before epoptes and all its deps
13:44	<Hyperbyte> Heey, cool - United Kingdom joined the LTSP world map. :-)
13:45	I really love peeking around the world map viewing stories. :)
13:45	http://www.ltsp.org/stories/viewstory/?story_id=21&secret=47f077
14:03	<alkisg> cyberorg: do you include /boot/vmlinuz, /boot/initrd to the compressed image?
14:04	<cyberorg> alkisg, no, we strip lot of other files as well
14:04	<alkisg> Gotcha... the `ltsp-update-image --cleanup` upstream tool can exclude items as well, but we don't have /boot/* on its list
14:05	Anyways, our images here are > 1 Gb, so a few more wouldn't matter much :)
14:05	(fats)
14:06	<cyberorg> alexqwesa came up with this idea, we strip unneeded files put them in image-unneeded, when user runs kiwi-ltsp --chroot, those files are copied back in the image and stripped again when coming out of chroot
14:06	that allows us to remove packagement stack as well
14:07	<alkisg> cyberorg: wait, I thought 168mb was the compressed clicfs size, that's for uncompressed (nfs) chroot?
14:07	<cyberorg> no, compressed
14:07	<alkisg> Wouldn't it be easier then to just exclude them in the compression stage?
14:07	<cyberorg> yes thats what we do
14:08	<alkisg> So why do you need to copy them around when someone runs kiwi-ltsp --chroot?
14:09	<cyberorg> because uncompressed tree is stripped before compress
14:09	<alkisg> Ah, the mkclicfs tool doesn't support excludes?
14:09	<cyberorg> if compression stage is not run then the files are still there
14:09	<alkisg> (however it's called...)
14:10	Do you mean that you can run kiwi-ltsp --chroot into a compressed image?
14:11	<cyberorg> yes it is mkclicfs, no there is no exclude
14:11	<alkisg> Gotcha, ltsp-update-image uses a temp cow file system for that case, you might want to use that instead
14:12	<cyberorg> but this way even the nfsroot gets the same tree as compressed, and when user wants to modify anything all the stripped files are available
14:13	<alkisg> E.g. to delete security-related data before the compression step, a cow file system is generated over the chroot, and commands are executed, packages purged, files deleted etc
14:13	<cyberorg> 546M /srv/kiwi-ltsp-nfs-openSUSE_12_2_prebuilt_unstable
14:13	178M /srv/kiwi-ltsp/openSUSE_12_2_prebuilt_unstable.img
14:13	so epoptes added 7M
14:14	<alkisg> How much did italc add when you were using it?
14:14	Btw, it's possible to operate epoptes without installing it to the chroot at all
14:14	<cyberorg> we didn't add italc in the image, client also ran on the server
14:14	<alkisg> You just lose the ability to control clients before login
14:15	(like italc if you don't install it to the chroot)
14:15	<cyberorg> yeah, but it is nice to get control right from ldm
14:22	<alexqwesa> cyberorg: then we run kiwi-ltsp --chroot it's already made "cp -a $LTSNFSPATH-unneeded/* $LTSNFSPATH/" and removed this file after user exit from chroot
14:23	<cyberorg> alexqwesa, yes, thats what i was explaining
14:24	<alkisg> alexqwesa: but couldn't that step be completely avoided, if you only removed the files in the compression step?
14:25	Then kiwi-ltsp --chroot wouldn't need to copy files around, they could just be excluded from the compressed image (without even really deleting/moving them on the disk)
14:25	<cyberorg> alkisg, yes that would require mkclicfs support exclude?
14:25	<alkisg> Nope
14:26	Just a cow image before compressino
14:26	See the ltsp-update-image code, it already has support for that
14:26	E.g. /opt/ltsp/i386 + a tmpfs get cow-mounted in /tmp/some-temp-dir, and the files are deleted there, and mkclicfs operates there,
14:27	<alexqwesa> alkisg: but chroot also used as NFSROOT isn't it good idea cut unneeded files from NFSROOT ?
14:27	<alkisg> and since it's a cow system, the rm commands don't actually delete anything, it doesn't affect the actual disk at all
14:27	alexqwesa: why? NFS doesn't have any overheads based on the disk size
14:27	<alexqwesa> alkisg: ok
14:27	<cyberorg> yeah would probably be faster than actual mvs
14:28	<alexqwesa> then i will change it
14:28	<alkisg> It's basically instant, rm's just use a whitelist in ram
14:28	*whiteout list
14:28	<cyberorg> alexqwesa, we can use unionfs
14:29	we dont have aufs or overlayfs
14:29	<alkisg> So... it would be very easy to add unionfs to ltsp-update-image though. And clicfs support. Dunno if that would make it easier than kiwi-ltsp for you guys, in the long term
14:31	Steps like those would make even documentation easier, e.g. "to configure dhcp, run: ltsp-config dhcp", in the central ltsp wiki, instead of having to document it specifically per distro
14:32	<cyberorg> alexqwesa, may be add those to ltsp-update-image functions, we can source it where required?
14:34	alkisg, yes we provide things like ltsp-build-client, ltsp-update-sshkeys etc which basically runs kiwi-ltsp -whatever switch
14:35	<alkisg> E.g.: http://paste.ubuntu.com/1166360/ => we can make ltsp-config our central tool for configuring the parts of the server that we need, with distro overridable functions where necessary
14:36	I guess what I mean is that some parts of kiwi-ltsp may be moved upstream, it might be more easy for everyone + more maintainable this way
14:38	<alexqwesa> cyberorg: ??
14:38	ltsp-update-image functions ?
14:39	khildin has left IRC (khildin!~khildin@ip-80-236-228-129.dsl.scarlet.be, Quit: I'm gone, bye bye)
14:40	<cyberorg> alexqwesa, ltsp-update-image in ltsp-trunk, i see we can't source it as it is not function library
14:41	alkisg, for moving stuff to upstream scripts it would be best if all the functions were separate from the scripts
14:41	<knipwim> cyberorg: but a hypothetical /server/SUSE_LINUX/share/ltsp/ltsp-update-image-functions is
14:42	if you create that to overwrite specific functions in the generic ltsp-update-image, it overwrites them
14:43	<cyberorg> knipwim, functions shouldn't be in the script is what i mean, makes life easier, we don't have to hunt for functions in different places
14:45	<knipwim> what do you mean with hunt for functions, isn't that a normal consequence of having a lot of functions on different layers of abstraction?
14:45	<cyberorg> kiwi-ltsp-functions.sh is function library, kiwi-ltsp sources it and other function libs, so we can have ltsp-functions-XYZ which can be overridden by DISTRO/ltsp-functions-XYZ
14:46	<knipwim> so you have all functions in one file? and one for each distro
14:46	<cyberorg> knipwim, i can't just source ltsp-update-image as it is as it is just to use relevant function, as functions are called from within that script
14:47	<alkisg> cyberorg: it goes like this: a script has some generic functions that no distro would need to override, and a set of overridable functions that some distros might need to override
14:47	If so, those distros write files with specific names, and they're automatically sources
14:47	*sourced
14:47	<cyberorg> knipwim, yes that way it is easier to figure out how other distros approach the same problem, cow mount for update for example by upstream and us doing mv
14:48	<alkisg> These functions are under the "# Distro overridable functions" comment on each tool
14:48	This scheme makes it very easy to see the differences between distros
14:48	E.g. it allowed ubuntu to have a minimal diff from debian. It had a very large diff for no real reason.
14:50	It also allows the generic implementation to show a reasonable message "your distro does not support this function, contact the maintainers" on e.g. updated ltsp versions where the maintainer forgot to see some new function
14:50	<cyberorg> see ltsp-common-functions, ltsp-client-functions, something on the similar lines for the server
14:50	<alkisg> Finally, having functions instead of sourceable files with no functions in them, allows for common main code
14:50	<cyberorg> and ltsp-init-common
14:51	<alkisg> Those are for all tools, they're still valid; the scheme I described above are for tool-specific functions, which aren't worth to be separated in extra files unless the tool is very large (e.g. > some hundred lines)
14:52	<knipwim> cyberorg: the design part here describes an example execution for ltsp-chroot: http://wiki.ltsp.org/wiki/Commands#Design
14:52	what files are sourced, when and why
14:52	<alkisg> E.g. ltsp-chroot => only has 1 overridable function, it's not worth to separate it to another file
14:54	<cyberorg> but why multile separate tools for each command and not something like ltsp-config --chroot?
14:54	F-GT has left IRC (F-GT!~phantom@ppp121-44-77-36.lns20.syd6.internode.on.net, Ping timeout: 244 seconds)
14:55	<alkisg> "ltsp-config" means "configure something, some part of the server /etc scripts"
14:55	"ltsp-chroot" means "enter a chroot"
14:55	<muppis> cyberorg, that's the spirit of *nixes.
14:55	<alkisg> Splitting tasks into smaller tasks makes it easier for people to remember each command, to go through its man page, etc
14:55	<cyberorg> everything is done by single command kiwi-ltsp on opensuse, although, we can just have ltsp --config, ltsp --chroot, ltsp --whatever
14:56	that just personal preference :)
14:56	<alkisg> Well, it's like using `bash ls`, `bash pwd`, `bash whoami`...
14:56	<cyberorg> alkisg, no, figuring out which command does what is confusing, having to remember many commands is too
14:56	<alkisg> cyberorg: would you prefer for ls and pwd and whoami to be in the same man page?
14:57	<cyberorg> yeah, or busybox xyz :)
14:57	<alkisg> I wouldn't be able to easily navigate through a man page of 10.000 lines...
14:57	<cyberorg> alkisg, no, but at least everything to do with ltsp in one place
14:57	<alkisg> But everything that relates to shell, isn't
14:57	Everything that relates to accounts, (passwd, useradd...) isn't
14:58	<knipwim> cyberorg: ltsp <tab><tab> ?
14:58	<alkisg> It's the spirit of unix, as knipwim said, we don't have `user change passwd`, `user add new` ...
14:58	<cyberorg> we have yast <tab> <tab> that does everything as well :)
14:58	alkisg, i know, just personal preference, other people might find other ways simpler
14:59	<alkisg> But anyway that's just a way to invoke the commands, I don't think that you're suggesting that the command themselves should be merged...
14:59	I mean, it would be enough to have an '/usr/bin/ltsp' launcher, and all the other commands in /usr/share/ltsp* to implement what you're saying
15:00	ltsp --config would launch ltsp-config, ltsp --chroot would launch ltsp-chroot, etc
15:00	<cyberorg> alkisg, no, something like puting functions in /usr/share/ltsp/common-functions/* and distros can override /usr/share/ltsp/vendor-functions then the scripts in /usr/bin/ltsp* can use those
15:01	<alkisg> cyberorg: you're mentioning two things
15:01	One is internal function organization
15:01	The other is how the tools are launched
15:01	First, about the first one:
15:01	It's easier to have the functions inside the tool, as long as it's small, and only the distro-specific functions in separate places
15:02	We had functions in ltsp-init-common which noone knew if distros were using them or not
15:02	<cyberorg> alkisg, we can have how the tools launch same on all distro as well, don't care for single tool, but that would be easy to do once functions are organized
15:02	<alkisg> The launching is not related to how functions are organized
15:02	<cyberorg> alkisg, we used only those always
15:03	<alkisg> With that organization the common code is common, and the distro specific code is separated
15:03	OK let's have an example
15:03	Suppose we put all the ltsp-chroot functions in ltsp-common-functions
15:04	9 of them are distro-agnostic
15:04	1 is distro specific
15:04	* muppis goes pick some popcorn..
15:04	<alkisg> You're the opensuse maintainer. Would you like to have to go through all the functions and search for distro-specific code, or would you prefer for the 1 function to be cleanly separated, so that you know what you need to check if it runs on your distro or not?
15:04	And, you wouldn't even know which tool used those, then
15:05	You'd have to go through all the tools to see what the coder meant there
15:05	<cyberorg> then distro dev puts /usr/share/ltsp/vendor-function/modified-function
15:05	<alkisg> But how would you know which functions you needed to modify?
15:05	Or, which tool uses which functions?
15:05	If only 1 tool uses 1 function, why would it be in "common"?
15:05	It's not good modular programming if you dump everything there...
15:06	Next step. I want to modify 1 "common" function.
15:06	<knipwim> on first glance perhaps complex, but on the long run very maintainable by various distro maintainers
15:06	<alkisg> In the implementation you describe, I'd have to go through all the distro implementations to check if they overrided it, so as to not break things
15:07	While in this implementation, we know it's inside the tool and not distro specific, so no maintainer overrode it
15:09	<cyberorg> well common functions should have if $distro;then wherever possible
15:09	<alkisg> There shouldn't be any need at all for if distro
15:11	<cyberorg> the way current tools are written they wont work anywhere without modifications, so if the modification is needed developer can send in patch to a function with if $distro to get it working
15:11	<alkisg> "main" code uses functions (==define an API), distros override the functions they need and mark them as distro-specific, and we don't have to use "if distro" anywhere
15:11	markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)
15:12	<cyberorg> so have a library of API/functions in one place is what is needed
15:12	it can be broken up in multiple files and sourced by tools requiring them
15:12	<markit> hi ppl :) I'm going to re-install a ltsp server (and then try to copy accounts etc.). Was installed as 64 bit, you suggest 32 + pae. Is there a significant performance regression I should be aware of?
15:12	<cyberorg> same as we have /usr/bin/ for binaries and /usr/lib for functions used by /bins
15:12	<markit> (I know I will save a lot of internet band when updating the system and chroot)
15:13	<alkisg> `grep -rw detect_vendor .` and `grep -rw VENDOR .` return only a handful of not-yet-updated functions, that require 'if distro'
15:13	<markit> ehm, you = alkisg :)
15:13	<alkisg> markit: the ubuntu kernel team still suggests 32 bit as the default
15:14	So I'm inclined to say "no" there :)
15:14	<markit> I've seen, but this is a 12GB ram quad core, not average PC ;P
15:14	<knipwim> cyberorg: are you looking for an API as documentation, all functions on one page, or all functions in one file?
15:14	<markit> I've been told that for instance nfs servers or whatever have a very lower latencies as 64 bit, but can't confirm the source
15:15	<alkisg> markit: I think in general there's no noticable difference, unless you're running math/simulation etc apps
15:15	32bit use smaller pointers so they're even faster in many cases
15:15	<cyberorg> knipwim, all the functions in one place /usr/share/ltsp/ and tools in /usr/bin/ makes life simple, but as i said, that is just a personal choice, we have functions in /usr/share/kiwi-ltsp/* and tools in /usr/bin/
15:15	<alkisg> And save a lot of ram
15:16	markit: they're even implementing a x32 api to have 32-bit pointers in 64bit mode, imagine how important that is then
15:16	(implementing in the kernel, in gcc etc, it's a big work)
15:16	<markit> alkisg: ok, I'm convinced, thanks a lot ;P
15:17	<alkisg> cyberorg: the main idea here is that we want to have a method to mark distro specific functions vs distro agnostic code
15:17	It doesn't matter much if we put them in separate files or not
15:17	<knipwim> for long term maintanance perspective
15:18	making it simpler at first glance was not a design criterium
15:19	<cyberorg> knipwim, :) i have been glancing it for many many years now, i still don't get it
15:19	<alkisg> So, each coder can do anything he likes in distro-agnostic code (as long as he keeps it distro-agnostic), and distro maintainers only need to look at distro-specific functions, they don't even have to look at all the ltsp code
15:19	<knipwim> hehe
15:21	<alkisg> Check a specific example, ltsp-chroot: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/view/head:/server/ltsp-chroot
15:21	# distro specific functions ==> 1 function
15:21	Debian: 3 lines: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/view/head:/server/Debian/share/ltsp/ltsp-chroot-functions
15:21	Gentoo: 10 lines or so: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/view/head:/server/Gentoo/share/ltsp/ltsp-chroot-functions
15:22	So, a new distro maintainer knows that he only need to change that 1 function for that tool
15:23	<knipwim> in practice a distro maintainer won't even have to look at all common function files
15:25	<alkisg> Another example. Suppose I want to change the API of a distro-specific function. I'd go through all the distro-specific files and do my best to have it running, but the important thing is that you, as a distro maintainer, will see that your distro dir contents were modified by me, so you'd need to check if they still run
15:26	The 'separate dir per distro' allows for that; with `if $distro` it's very difficult to understand if you distro code was modified
15:31	<cyberorg> alkisg, there wont be much difference if functions were removed from scripts executing them
15:32	* alkisg didn't get that
15:32	<alkisg> Are you're talking about moving the ltsp-chroot functions inside ltsp-common-functions?
15:32	<knipwim> alkisg: each function could have a function library
15:32	cyberorg: right?
15:33	<cyberorg> alkisg, no, it could be ltsp-chroot-functions
15:33	<alkisg> The idea now is "each function which is only used by 1 tool, is local to that tool. Each function that is used by more tools, goes in ltsp-common-functions"
15:34	<cyberorg> alkisg, so ltsp-chroot tool can have ltsp-chroot-functions
15:34	<alkisg> cyberorg: and the distro-specific ltsp-chroot functions, where would they go?
15:34	<knipwim> alkisg: if the functions were separate, they can be used by other tools, for instance kiwi-ltsp --chroot
15:34	<cyberorg> easy to add compatibility tools,
15:35	<alkisg> cyberorg: now, in an Ubuntu ltsp installation, I only have common and ubuntu-specific code. I don't have gentoo, opensuse etc code anywhere
15:35	That's because the packagers only ship the ltsp-chroot-functions that match my distro
15:36	(let's not mention ltsp-build-client now, it's another story :D)
15:36	<knipwim> alkisg: they would then only ship the ltsp-chroot tool, the ltsp-chroot-functions and ltsp-chroot-vendor-functions for their distro
15:36	<alkisg> knipwim: right, but we don't want to have the "vendor" in the name
15:36	We want to leave that for the packager
15:37	So that we just source what the packager put there, without IFs
15:37	<knipwim> alkisg: and cyberorg wouldn't ship the ltsp-chroot tool, he uses kiwi-ltsp sourcing the ltsp-chroot-functions
15:37	alkisg: for example sake
15:37	<alkisg> So, I don't mind if we do this: ltsp-chroot (without functions), ltsp-chroot-common-functions, ltsp-chroot-distro-functions
15:37	(or whatever other names)
15:37	But no -vendor anywhere
15:37	<knipwim> :)
15:37	never again
15:38	<cyberorg> knipwim, don't care for other tool, we can ship ltsp-chroot, hold on a sec
15:38	<alkisg> cyberorg: is that what you're proposing?
15:38	<knipwim> i guess not :)
15:39	<cyberorg> we can have ltsp-chroot sourcing ltsp-chroot-function if it works otherwise we can source /usr/share/ltsp/vendor/ltsp-chroot-function
15:39	vendor/ltsp-chroot-function will have functions that need modifications from ltsp-chroot-function, it could be 1 or many
15:40	*will only have...
15:40	<alkisg> cyberorg: we're saying the same thing, we're just using different names
15:40	I'm deliberatly omitting the vendor anywhere in the file/dir names, and leave that up to the packager
15:40	<cyberorg> heh :)
15:40	<alkisg> So that we don't need IFs in the code
15:41	I don't think that has any downsides, does it?
15:41	vendor would be in the upstream tree, but not in the shipped packages
15:41	(as is the case now, except for ltsp-build-client)
15:43	(ltsp-build-client is different (1) because it was too big to fix it at the moment me and knipwim worked on this, and (2) because it might be possible to generate a cross-distro chroot in some cases, so we might actually want the different vendor dirs there)
15:45	quiliro has joined IRC (quiliro!~quiliro@186.4.149.245)
15:51	<cyberorg> http://susepaste.org/78892064, so now most tools are there on suse doing similar things
15:53	no functions in those scripts, much cleaner
15:54	so probably ? and X can be removed from http://wiki.ltsp.org/wiki/Commands#Design :)
15:55	nbdswap is supported
15:55	remoteapps is installed in the chroot, never test it though
15:56	looking at scripts i am sure it works
15:56	<knipwim> cyberorg: all the ? and X's /
15:57	check
15:57	<cyberorg> knipwim, wiki page :)
15:58	heading home, 'night :)
16:01	<knipwim> cyberorg: changed
16:10	Bootless has joined IRC (Bootless!~AnDyLap@p57A2550A.dip.t-dialin.net)
16:11	Bootless has left IRC (Bootless!~AnDyLap@p57A2550A.dip.t-dialin.net)
16:13	komunista has left IRC (komunista!~slavko@adsl-195-098-013-109.dynamic.nextra.sk, Ping timeout: 276 seconds)
16:18	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
16:19	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:39	Parker955_Away is now known as Parker955
17:15	Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 264 seconds)
17:19	<knipwim> alkisg: what's the difference between rm-session-services and rm-system-services?
17:23	<alkisg> knipwim: system == /etc/init, session = /etc/xdg/autostart, basically for fat clients
17:24	E.g. there's no point in having gockey-gtk running inside the thin client session to tell the user to install modem drivers for the client...
17:25	*fat
17:26	<knipwim> check, the diff between them is clear
17:26	Parker955 is now known as Parker955_Away
17:29	dgroos has joined IRC (dgroos!~dgroos@mail.troop187.org)
17:30	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
17:58	Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
18:13	jocarter has left IRC (jocarter!~highvolta@ubuntu/member/highvoltage, Remote host closed the connection)
18:25	shogunx_ has left IRC (shogunx_!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Ping timeout: 268 seconds)
18:28	jocarter has joined IRC (jocarter!~highvolta@ubuntu/member/highvoltage)
18:28	jocarter has joined IRC (jocarter!~highvolta@ubuntu/member/highvoltage)
18:29	shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
18:29	bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 252 seconds)
18:38	darthanubis has joined IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com)
18:46	phillw has joined IRC (phillw!~phillw@sii/piglet)
18:48	<phillw> ping... anyone about for a comment on http://pastebin.com/Qi2J5m5W
18:48	i have no idea really to file the bug.
18:59	markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, )
19:07	shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Read error: No route to host)
19:09	shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
19:27	<muppis> phillw, for those poweroff's, have you looked for bios update for machines? Or setting from bios? It's a acpi communication error which causes that. You can also try (no thin in hand right noe, can't by self) to (re)install acpid to running system (so no need to alter chroot or image) via root shell if it helps.
19:27	Can't test by self.. Have been dropping word whole evening.
19:27	<phillw> muppis: I'm just a poor QA guy, stuck in the middle.
19:28	<muppis> Sucks ;)
19:28	<phillw> As the OP has taken the time to report, maybe it is an ltsp bug?
19:29	I can chase it if confirmed
19:30	<muppis> Can be, if it happens only in specific but popular hardware.
19:30	<phillw> ltsp == kernel bug
19:32	1st time I've had a complaint about ltsp server for lubuntu (I'm the QA co-ordintor for that team)
19:33	<muppis> And shutdown from desktop, I'll say it's a bug.
19:34	<phillw> muppis: what should he report it agaionst?
19:34	against
19:36	I'm just a bug hearder who gets asked as to what best to report against instead of multiple and invalid bugs.
19:38	<muppis> I don't really know. All what I know about there is a similar bug in Gnome shipped with 10.04 and there's a patch in Greek school's PPA which make it work. Maybe looking that up can help.
19:39	<phillw> muppis: can you find the bug number
19:40	<muppis> I'll try. I'm using my phone right now. :)
19:40	<phillw> edubuntu is a project that i really do care about
19:41	muppis: please do not, one of the ltsp guys will go dig it out.
19:42	<muppis> Ok.
19:49	It was quick: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/491940
19:50	vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
19:50	vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
19:51	<phillw> thanks, I'll see what I can do.
19:51	<muppis> Good luck.
19:52	<phillw> as lubuntu is also used on lstp, I do owe a debt
20:06	muppis: if you have an email addy, i will ensure that you are cc'd.
20:13	muppis: I'm most likely in trouble again :P I have asked that the bug be resolved, quickly.
20:23	<Hyperbyte> Can I just make a brief statement here?
20:23	Quite offtopic, but I need to say it
20:23	Today is the most sucking of this year so far.
20:24	Boy do I hate today. Glad that in another one hour and 37 minutes this day is officially history.
20:24	<knipwim> you had your yearly bbq in the rain?
20:24	harddisks die?
20:24	<Hyperbyte> First radio deejay colleague phones me that his mother is dieing, if I can stand-in for his show - sure I can, so I go to the studio horribly early in the rain
20:24	And I fall down with my electric scooter... those things weight 150 kilos, so quite a bit of damage.
20:25	(there was some oil on the road)
20:25	Still a bit shaken up from the accident I do the radio show, so of course it goes anything but smoothly
20:25	<knipwim> dude, are you allright?
20:26	like in one piece and all
20:26	<Hyperbyte> Somewhere in the afternoon I get a phonecall that another colleague has had a brain infarct and is in hospital in coma
20:27	And tonight I went and visited the colleague who's mother is dieing, and he's pretty down about it all, things aren't going well for him, she won't make the night probably/hopefully.
20:27	Today is officially the worst day of the year. It must be.
20:27	<knipwim> hope so
20:27	<Hyperbyte> I'm okay, by the way - foot hurts, knee hurts (had to break my fall)
20:28	I didn't go fast, it was in a corner... going 10km/h at most... but falling hurts nonetheless, and scooter damage will set me back a few hundred.
20:28	<knipwim> well, at least you're alive
20:28	<Hyperbyte> Anyway
20:28	Heh, yeah, there's that. :P
20:29	Oh and I saw cyberorg and alkisg collaborating about integrating some things from OpenSUSE upstream, I really like that. :)
20:29	So there's that as well.
20:29	But other than being alive and the aforementioned, today sucked. :)
20:31	* vagrantc got thrown around plenty, so can't complain
20:31	<Hyperbyte> How so? :)
20:33	<vagrantc> aikido :)
20:35	<Hyperbyte> Yeah, but then you choose for it. :P
20:35	I didn't choose to fall. :P
20:36	darthanubis has left IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com, Ping timeout: 252 seconds)
20:36	<vagrantc> hence my non-complaining :)
20:37	Hyperbyte: sounds like a mess though. glad you'll be getting through it soonish
20:38	<Hyperbyte> Yeah, it'll be fine tomorrow
20:38	Just today sucked. :)
20:41	darthanubis has joined IRC (darthanubis!~darthanub@cpe-66-61-37-133.neo.res.rr.com)
20:45	dgroos has left IRC (dgroos!~dgroos@mail.troop187.org, Quit: dgroos)
21:09	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
21:12	<alkisg> phillw: about the power down button being instant or needing 5 secs, that's a bios setting, it's unrelated to the OS that you use
21:12	The other "not shutting down" problems are kernel/acpi related, to verify it just boot a client from a cd or usb stick, and then report the bugs to those projects
21:13	For upstream acpi/kernel bugs the suggested method is to try booting with a vanilla kernel (not modified by Ubuntu), and to file the bug upstream then, not in launchpad
21:15	<phillw> alkisg: if you can try head the bug better, I'd appreciate it.
21:16	It has been bounced on me, I really do need you guys to help out.
21:16	<alkisg> https://wiki.ubuntu.com/Bugs/Upstream/kernel
21:16	It's not at all related to LTSP, so if you need more help, try #ubuntu, #ubuntu-kernel etc
21:16	Do verify with a cd or usb booted OS that it's not related to ltsp, of course
21:17	(and you can even verify with a different distro that it's not ubuntu related either)
21:22	<phillw> alkisg: I will ask within QA, but everyone likes to move bugs.
21:23	<alkisg> QA of what?
21:23	lubuntu?
21:23	<phillw> QA of ubuntu
21:24	<alkisg> OK, first try booting e.g. a fedora live cd on those machines and shutting them down with it. That should cover some of the questions about which packages are related :) (e.g. if indeed they won't shut down, ltsp and ubuntu are unrelated, it's an upstream issue)
21:24	<phillw> alkisg: lubuntu QA is a part of main QA. As this issue involves Edubuntu, it is a 'general' QA issue.
21:25	alkisg: we are running ubntu system, not fedora / red hat / CentOs
21:25	<alkisg> Yes, but in order to fix the issue, you need to locate the package that contains the code that breaks it
21:26	That's why ubuntu requests that kernel issues are tested without the ubuntu kernel
21:26	So by testing with another distro, you verify that the problem isn't in ltsp, and isn't in one of the ubuntu-specific kernel patches
21:27	<phillw> alkisg: you are far beyond my limited knowledge, please ask on the bug report?
21:27	bengoa has joined IRC (bengoa!~bengoa@alberto.propus.com.br)
21:27	<alkisg> Is there a bug report filed against the poweroff issue?
21:28	bengoa has left IRC (bengoa!~bengoa@alberto.propus.com.br, Client Quit)
21:30	<phillw> alkisg: yes, there is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1041625
21:30	<alkisg> ...ubiquity?!!
21:31	<phillw> alkisg: as it failed to install, it was the palce.
21:31	I have come here to chase up https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/491940
21:32	<alkisg> phillw: err is #1041625 related at all with the acpi/kernel issues that we were talking about?
21:32	<phillw> alkisg: but it does appear that whilst a fix was proposed that it was actually done?
21:33	<alkisg> phillw: you're confusing me very much
21:33	I replied to some kernel/acpi issues that you mentioned
21:33	Then you gave me a link to an ubiquity bug which seems totally unrelated to what we were saying,
21:33	cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Read error: Connection timed out)
21:33	<alkisg> and then a link to a bug report I filed some years ago
21:33	Which one of those 3 cases do you want to talk about?
21:34	<phillw> alkisg: there is little point asking me, i do not run LTSP, I simply asked that you guys get in touch with people who do.?
21:34	<alkisg> That we get in touch with people that run ltsp? We do run ltsp...
21:34	Who should we get in touch with?
21:35	<phillw> the bug reporter is always a good idea?
21:35	<alkisg> I'm the bug reporter for that last bug you mentioned
21:35	Should I contact myself?
21:35	* vagrantc joins alkisg in confusion
21:35	cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
21:36	<phillw> alkisg: you registered https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/491940
21:36	?
21:36	<alkisg> Yup, so?
21:36	<phillw> alkisg: did you also register https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1041625]
21:36	?
21:37	<alkisg> No, that's completely unrelated to ltsp and to whatever we were talking about
21:37	So, what is it that you're asking of us? I really can't understand
21:38	Is it possible that you noted down the wrong bug number?
21:38	<phillw> alkisg: I'm about bug numbered out... let me go grab it
21:40	alkisg: http://pastebin.com/Qi2J5m5W is this yours?
21:40	<alkisg> No, I thought that was yours, I saw it on the ltsp mailing list a while back
21:40	<phillw> nope, it from the OP
21:41	<alkisg> Is there a launchpad bug report with it?
21:41	<phillw> we have been chasing it.
21:41	<alkisg> What is "OP"?
21:41	qwebirc12839 has joined IRC (qwebirc12839!c4d74bb3@gateway/web/freenode/ip.196.215.75.179)
21:42	<qwebirc12839> hello
21:42	<phillw> alkisg: OP == The orginal questoner
21:42	<alkisg> Where is his question?
21:44	<qwebirc12839> im hoping someone can tell me if it is possible to use ltsp on a server with only one NIC, and if possible a point in the right direction
21:44	<phillw> alkisg: I do believe he does explain as to where the bug up quite clearly at http://pastebin.com/Qi2J5m5W
21:45	<alkisg> phillw: so, you saw that question in pastebin, and came here to help John Hupp with that question?
21:45	Where will you answer him? In pastebin?
21:45	There's no launchpad bug report filed for this?
21:45	<phillw> alkisg: nope, he has not had a full answer, just that there was an old bug never resolved.
21:46	<alkisg> So you know him personally, and he never filed a bug report?
21:46	And to answer him, we'll have to send the answer through you?
21:47	<phillw> He asked as to what to file the bug report to?
21:47	<qwebirc12839> are my my messages visible?
21:47	<alkisg> qwebirc12839: yes, they are
21:47	<qwebirc12839> sorry ive been having all sorts of problems so i wasnt sure
21:47	<alkisg> phillw: tell him to file the bug report in launchpad, so that people can properly answer him and direct him to the correct package (i.e. the kernel)
21:48	<Hyperbyte> qwebirc12839, if you want to use internet on your network, you need a router. If your LTSP has two NICs, it can be a router. If it doesn't, you can use an external router to get to internet.
21:48	<phillw> alkisg: quite simply? does he report to https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/491940 or raise a new one?
21:48	<Hyperbyte> *LTSP server
21:48	Basically an LTSP server uses only NIC to communicate with the clients. The second NIC would be used for routing internet.
21:48	<alkisg> phillw: he should create 3-4 bug reports, one for each of the problems he mentions
21:49	phillw: one of them, that he's unable to shutdown ltsp from within gnome-session, is the one I filed (#491940), so he can just comment there
21:49	<phillw> and, more importantly, as a tester -- to which app does he rais the bug against?
21:49	<alkisg> For the other 3-4 ones he should file new bugs under the kernel etc
21:49	no shutdown => kernel
21:49	<phillw> this seems to be on going problem that is not being answered?
21:49	<alkisg> no "it's safe to power off your computer" => ubuntu, not sure where that would fit
21:50	no "instant poweroff" => his computer manufacturer, so that he sends him the bios manual
21:51	<phillw> alkisg: so I simply tell him " tough luck, Ubuntu does not work"
21:51	<qwebirc12839> thank you Hyperbyte i do have a router and im wondering how to configure the dhcp on it to send pxe to my server
21:51	<alkisg> phillw: it doesn't work when you try to get feedback from a pastebin, yeah :)
21:52	You need to file bug reports to get feedback
21:52	Also, the BIOS is inside the computer ROM, it's unrelated to Ubuntu
21:52	He just needs to press del to enter setup and do a configuration change
21:52	If you want to blame ubuntu for that... whatever
21:53	<phillw> alkisg: the reason I came on here was to ask to which to raise a bug to.... Guess what... I'm still waiting for a deffinitive answer.
21:54	<vagrantc> phillw: maybe try #ubuntu ?
21:55	<phillw> vagrantc: as it is an ltsp system, I was advised to ask here.
21:55	<vagrantc> while we try to help people out in general, we do kind of focus on ltsp issues in #ltsp
21:55	ah, i see.
21:56	<alkisg> phillw: I did tell you the answer, 2 new bugs, one comment in an existing bug
21:56	<phillw> vagrantc: have a read of http://pastebin.com/Qi2J5m5W
21:56	<alkisg> I don't know what else you're looking for
21:56	* vagrantc might
21:57	<phillw> alkisg: so, what do I tell the original questioner?
21:57	<alkisg> Copy/paste our chat, I believe he'll understand
21:58	<phillw> there are no answers to his bug report in our chat.
21:58	<alkisg> Are you sure?
21:58	I believe I answered all of them
21:58	Anyway, never mind, I'll send him the answer myself
21:58	<phillw> th eoriginal questioner wishes his systems to work. Do you have that?
21:58	<alkisg> To the ltsp mailing list where he posted the problem
22:00	<phillw> I cc'd it there, so yeah... please do hive him the answer to his problem.
22:00	I will say a good night
22:00	phillw has left IRC (phillw!~phillw@sii/piglet)
22:02	<vagrantc> maybe the answer doesn't exist?
22:02	what a strange interaction...
22:03	please provide an answer to the fact that the sun is going to expand and engulf the earth.
22:04	<Hyperbyte> 42!
22:04	<alkisg> Hehe
22:04	I really wonder what his part in this was
22:04	He surely wasn't involved in Ubuntu QA, he didn't know anything about bug triaging etc
22:06	ricotz has left IRC (ricotz!~rico@unaffiliated/ricotz, Quit: Ex-Chat)
22:07	<alkisg> Hehe... https://wiki.ubuntu.com/phillw
22:20	* vagrantc wonders if an anti-testimonial section would be appropriate
22:31	<alkisg> What I didn't understand is why phillw didn't want to say where he has heard John Hupp's questions... Trying to sell support? Or trying to prove to his friend that he can help him by himself?
22:32	Anyways, it looks like he tries to give back to the community, so... :)
22:33	<vagrantc> though sometimes takes time from the community in doing so :(
22:34	<alkisg> qwebirc12839: is your router configurable? Can you specify the boot filename, root-path and next-server there?
22:51	'night guys
22:51	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
22:58	qwebirc12839 has left IRC (qwebirc12839!c4d74bb3@gateway/web/freenode/ip.196.215.75.179, Ping timeout: 245 seconds)
23:43	quiliro has left IRC (quiliro!~quiliro@186.4.149.245, Quit: Leaving.)
23:45	F-GT has joined IRC (F-GT!~phantom@ppp121-44-77-36.lns20.syd6.internode.on.net)
23:52	qwebirc1202 has joined IRC (qwebirc1202!c4d74bb3@gateway/web/freenode/ip.196.215.75.179)
23:52	<qwebirc1202> hello again
23:53	ive managed to configure and get ltsp up and running and got a client logged in, but the client has no icons or launchers