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

Request log from specific day:

Channel log from 18 September 2010 (all times are UTC)

00:01	MorningSon has quit IRC
00:22	johnny has joined #ltsp
00:59	poff has joined #ltsp
01:31	poff has quit IRC
01:32	poff has joined #ltsp
02:02	alkisg has joined #ltsp
02:04	poff has quit IRC
02:04	poff has joined #ltsp
02:18	poff has quit IRC
03:49	alkisg has quit IRC
03:50	alkisg has joined #ltsp
03:53	alkisg has quit IRC
04:01	alkisg has joined #ltsp
04:04	cyberorg has joined #ltsp
05:16	Kicer86 has joined #ltsp
06:06	artista_frustrad has joined #ltsp
06:56	alkisg has quit IRC
07:11	pmatulis has joined #ltsp
07:51	alkisg has joined #ltsp
07:58	Kicer86 has quit IRC
08:26	ogra_cmpc has quit IRC
08:30	ogra_cmpc has joined #ltsp
08:39	markit has joined #ltsp
08:41	<markit> hi, a clarification please
08:41	if I setup, for instance, the power saving features/params when I'm logged in a thin client
08:41	am I acting against server setup or thin client one?
08:41	<alkisg> The programs are running on the server, so any changes that you do are server settings
08:42	...with the exception of any X-related settings, because the X server is running on the client
08:42	MorningSon has joined #ltsp
08:43	<markit> alkisg: mmm so makes not sense try to prevent thin client to turn off screen after some minutes of inactivity using the KDE settings, right?
08:43	how on earth can be done then?
08:43	<alkisg> X can turn the screen off
08:43	And X runs locally
08:43	<markit> so I should hack xorg.conf?
08:43	<alkisg> If KDE asks X to turn the screen off, then sure, it makes sense
08:44	No, I'm saying that it might just work, depending on the tools used
08:44	bbl
08:44	<markit> the confusion arises about settings that are user-related, while OMHO should be "hardware related"
08:44	alkisg has quit IRC
08:46	<markit> anyone in this channel that can tell me how he solves this issue? even in gnome, should be the same
09:25	MorningSon has quit IRC
09:32	MorningSon has joined #ltsp
09:35	F-GT has quit IRC
09:43	jhutchins_lt has joined #ltsp
09:45	alkisg has joined #ltsp
10:11	F-GT has joined #ltsp
12:18	z0r0 has quit IRC
12:26	mistik1 has quit IRC
12:28	mistik1 has joined #ltsp
12:36	artista_frustrad has quit IRC
13:44	mistik1 has quit IRC
13:44	mistik1 has joined #ltsp
13:56	<klausade> markit: one moment. I have a ltsp-client that is always on, displaying the nagios status of all our servers. There we had the same problem with the screen going into black.
13:58	markit: here it is, it's a four line long script that we run when the user logs in (we use kde). The content of .kde/Autostart/noblank.sh is:
13:58	#!/bin/sh
13:58	xset -dpms
13:58	xset s off
13:58	xset s noblank
15:38	jhutchins_lt has quit IRC
15:41	GodFather has joined #ltsp
16:10	alkisg has quit IRC
16:10	alkisg has joined #ltsp
16:20	<markit> klausade: back: thanks a lot
16:20	so I'd only to put in each user's home
16:21	<klausade> markit: you also have other places where you can put it, like in /usr/share/autostart/ i guess-
16:21	<markit> klausade: I'm too ignorant about the insight of kde, unfortunatly
16:22	I'll ask around and google a little. Thanks a lot
16:22	<klausade> gnome and others have pretty much the same possibilities to autorun stuff.
16:23	<johnny> i think i put that in the ltsp scripts directory somewhere
16:23	there was an equivalent for gnome that didn't involve editing the global gconf
16:23	<markit> johnny: is this documented in ltsp doc? Seems pretty important in school setups
16:24	<johnny> why is it important for schoo lsetups?
16:24	what's wrong with blanking?
16:24	<markit> expecially when used with italc or (in the future) alkisg script
16:24	<johnny> i always blank mine
16:24	italc isn't affected by blanking
16:24	<markit> and the screen of the teacher is sent to all children
16:24	<alkisg> My script isn't affected too
16:24	<markit> ah, did not know
16:24	nice to know after a day of struggle :(
16:24	<johnny> you mean because the students are just watching and not doing stuff so the timeout is too long?
16:24	<alkisg> It calls xset etc to disable the screensaver
16:24	<johnny> err too short
16:25	<markit> johnny: exactly
16:25	<johnny> markit, apps like totem (the movie player in gnome) use the inhibit dbus call
16:25	so. blame your apps :)
16:25	apps can tell dbus to tell the x server to not blank
16:26	vs just blanking globally
16:26	i blank mine in my cafe setup
16:26	people just wiggle the mouse and their in
16:26	<markit> johnny: never faced the issue. Yesterday while testing noticed that the ltsp client screens went blank, and thought would have been a big problem if they have the teacher's screen displayed
16:26	<johnny> markit, well those apps should inhibit the screensaver themselves
16:26	<markit> also because becomes blank after very few minutes, probably 10
16:26	<johnny> not all do
16:26	but they can
16:26	<markit> good to know, thanks
16:26	<johnny> i'm sure there are reasons why an app might not..
16:27	like if i'm running compile in a terminal.. my screen will blank
16:27	i could tell it not too condtionally
16:27	via dbus send with the right stuff
16:27	artista_frustrad has joined #ltsp
16:27	* alkisg likes the screens going blank after 10 minutes... lets the students focus on the real board when it's used
16:27	<johnny> yes.. that too alkisg :0
16:27	it also saves power
16:28	<markit> alkisg: I've not yet had a look at your app, but the file dgross sent me is a sort of xml
16:28	<johnny> markit, this is a relatively recent development (5 years) before that there was no semi unified framework for apps to tell the system when and when not to inhibit
16:28	<markit> so seems your app have strings "external" to the source code
16:28	and should be easy to localize... or should be based upon a totally different mechanism to be "right"?
16:29	<alkisg> markit: you open the glade file with the glade-3 program
16:29	It's a UI editor
16:29	Something like the delphi form designer...
16:31	<johnny> hah.. i'm turning into a unix graybeard :(
16:31	<markit> alkisg: do you have the url of your program handy? and any instruction about how to "install"?
16:31	<alkisg> You mean the ppa?
16:31	sudo add-apt-repository ppa:ts.sch.gr
16:31	sudo apt-get update
16:31	sudo apt-get install sch-scripts
16:32	That's all, then you create the fat/thin chroot from the menus
16:32	artista_frustrad has quit IRC
16:32	<alkisg> Clients are automatically detected, no need for config files etc
16:33	But ... greek only, depends on dnsmasq, adds greek locale to the chroot etc, not suitable as is. That's why I'm proposing to wait 2 years until the i18n version.
16:33	<markit> I've already thin client chroot created... will it overwrite it? do I have to remove it first? when/how "inject" dgross translated file?
16:33	(I'm using dnsmasq fortunatly)
16:33	<alkisg> I think dgroos installed sch-client on the chroot manually
16:34	..and, ask him about the "injection process", or see the #edubuntu logs, we had some hours there trying to set it up for international use...
16:34	* alkisg wouldn't want to go through it again until it's properly i18n :)
16:34	<markit> is it split among a "server" part for visualization, and a chroot one that provides the connection to the server part?
16:34	<alkisg> Yes
16:35	The chroot part is a simple script that only takes 1 MB RAM
16:35	<markit> for each client?
16:35	<alkisg> On each client
16:36	<markit> fabolous low footprint
16:36	<alkisg> The server network backend is based on twisted, it doesn't add much overhead per client
16:36	<markit> how can I grab the "sources" so I can install manually?
16:36	<alkisg> You don't need the sources, use the ppa
16:36	Just don't use the chroot generation wizard
16:37	Use your existing chroot..
16:37	<markit> I see, thanks!
16:37	<alkisg> Here are the sources (which you won't need): http://bazaar.launchpad.net/~sch-devs/sch-scripts/trunk/
16:38	<markit> svn? git? mercurial?
16:38	<alkisg> bazaar = bzr :)
16:39	<markit> ah, don't know about bazaar... to be sincere, I can barely use git and nothing more
16:39	<alkisg> bzr pull lp:sch-scripts
16:39	<johnny> stupid bzr :(
16:39	canoncial bad :(
16:39	they should have used hg
16:39	:(
16:39	<markit> hg?
16:39	<johnny> mercurial
16:39	it's what mozilla uses
16:39	among other big projects
16:39	<alkisg> Why not git?
16:39	<johnny> bzr's only main user is launchpad
16:39	<markit> aren't many moving to git?
16:40	<johnny> well lots of canonical stuff is python.. so an importable version control system is useful
16:40	as a library
16:40	certainly many valid complaints of git for it's UI
16:40	and versioning
16:40	bzr tries to hide teh hashes
16:44	<markit> btw, my clients are underpower for "fat clients", do you think that run some app like "local app" is a good idea or is higly risky of messing everything?
16:44	like firefox, that seem to eath ram and cpu like a dog
16:44	<alkisg> How much ram?
16:44	<markit> (maybe removing flash plugin will help a lot)
16:45	some 256MB, most 512MB
16:45	well not most.. half and half
16:45	kde4 should run decently with 512MB, though
16:46	<alkisg> I'd (automatically) use thin for the 256 ones, and fat for the 512 ones
16:46	<markit> (my test show that 384 is the bare minimum)
16:46	alkisg: you told me, do you have to provide a "table", a config file that says how much ram each client (mac address) has?
16:47	<alkisg> No, the current code does it automatically based on the client ram
16:47	<markit> stunning
16:47	<alkisg> So you wouldn't need any config files
16:47	Just a fat chroot
16:48	<markit> are the home still in the host system, or in the fat chroot?
16:48	<alkisg> Host
16:48	<markit> and users have to be created in the host system or in fat chroot?
16:49	<alkisg> Host, it's ltsp as you know it...
16:49	<markit> fabolous... so the ONLY problem is keep in sync installed programs / versions and global kde config among host (used by the teacher and thin clients) and fat chroot
16:49	<alkisg> You just have to maintain 2 images (server+chroot) instead of 1 (server)
16:50	<markit> well, in any case is far simple than single installations for sure!
16:51	alkisg: last question... your "script of wonders" is going to be included in -buntu (and hope debian) distro, once i18l?
16:51	<alkisg> No idea
16:51	I'll try to push it in debian sometime in the far future, not sure if I'll be able to do it..
16:52	<markit> seems so good that I would ask canonical at least if can do the work asap, instead of wait 2 years
16:52	<alkisg> I don't think canonical wants to spend money on developing a classroom administration app
16:53	<markit> do you think that an ruby programmer + (debian + kde lover) like me could easely help the i18n?
16:54	<alkisg> Nope, pygtk knowledge would be required as the infrastructure isn't there
16:54	<markit> I see
16:55	<johnny> well.. there is ruby gtk..
16:55	<markit> also ruby qt
16:55	<alkisg> ...but that would require a complete rewrite :)
16:55	<markit> but I would love have alkisg work fine and be i18l
16:56	* alkisg too
16:56	<markit> instead of "reinvent the wheel" before have at least one project workig
16:56	the final goal would be have the "core" and 2 interfaces, gtk and qt
16:56	<johnny> is the problem making the app il8n or the translations and stuff themselves?
16:56	<markit> instead than 2 different projects
16:57	<johnny> if the 2nd.. then you can use launchpad's translation service
16:57	<alkisg> I'd love to see a web site where local school admins can upload their lists of packages + configuration tasks, and that future classroom administration tool just asking the teacher which region he's in, and doing everything automatically for him...
16:57	<johnny> ifthe first, wrapping the cals is easy
16:57	alkisg, can't you already do that?
16:57	conary :)
16:57	err sorry.. foresight linux
16:57	<alkisg> We have code that installs specific packages in the chroot, greek apps for primary, secondary etc education
16:57	<johnny> but i woud be suprised if that didn't already exist
16:58	<alkisg> That's not easy to internationalize
16:58	<johnny> greek apps?
16:58	what is a greek app?
16:58	<alkisg> An infrastructure would need to be developed for school admins to configure their own setups, so that teachers can automatically use them
16:58	johnny: http://ts.sch.gr/repo/images/education-menu.png
16:58	Dozens of greek-only edu apps
16:59	<markit> and windows - wine converted, right?
16:59	so proprietary software :(
16:59	<alkisg> Flash, windows etc, yes
16:59	<markit> don't you feel gulty for that? lol
17:00	<alkisg> Nope, I just did the packaging, I didn't write the software requirements :)
17:01	<markit> alkisg: you are injecting proprietary software to the childrens of your country
17:01	<alkisg> Nope
17:01	I'm just making the same software that they use on windows, available on linux
17:01	Otherwise they wouldn't use linux
17:01	<markit> (btw, is only "small talk" with you, nothing serious)
17:02	<alkisg> There are cases (few, fortunately) where the student book uses/teaches a specific app, if that app isn't available on linux, they won't use it
17:02	<markit> alkisg: because there are not native sw that are as good as those ones, or because teacher are lazy and want to find the programs they are used to?
17:03	I ask because I'm starting to face the same problem
17:03	<alkisg> Because the ministry paid for those programs, and wrote books that teach them
17:03	So the teacher can't really select which software to use
17:04	<markit> "oh, I use program XXX, does it run here too?" me: "well, you can use YYY", teacher "oh, can't I use XXX? works so well, and.. 100 weak reasons"...
17:04	<alkisg> We're trying to persuade the ministry to develop floss software from now on, but we can't change what's already been done
17:04	<markit> alkisg: ok, anyway is a good news
17:05	I've the feeling that here in italy is the book printer that selects software to include in the book
17:05	<alkisg> markit: e.g. do you know of any floss program that teaches the orthodox religion?
17:05	Or the greek geography?
17:05	Etc etc
17:06	The ministry developed some apps, we just need to use those
17:06	<markit> I see
17:06	btw, they could provide as FOSS, but windows only, that would be a pity also
17:06	<alkisg> (it's usually one app for each book, and the books are distributed by the government, the teacher can't select which book to teach)
17:07	<markit> while gtk and qt let you create one that works in windows AND gnu/linux
17:07	<alkisg> If they were foss, at least we could try to make them run native on linux
17:07	<markit> but probably developers only use Visual Studio .NET these days
17:07	<alkisg> E.g. there are a lot of flash apps that could run native, but they're not foss
17:08	<markit> wondering if there are people here from different EU countries that can tell me about their situations
17:08	I'm very curoius about this subject
17:09	btw, ltsp server you usually deploy, is simple sata or raid10 with fast controller and write back cache?
17:10	because if it has to server 16-20 pc, I/O could be a severe bottleneck
17:10	but usually I've read about ram and cpu requirements (and gbit nick for the server)
17:11	<alkisg> The network is the most significant part, imho
17:11	We have small classrooms of up to 12 PCs, so we're just using simple PCs as servers
17:11	4GB RAM, a simple sata disk, core 2 duo or similar, and a switch with at least 1 gigabit port
17:12	* alkisg wants to try bonding on gigabit pci-e network cards though...
17:12	<stgraber> if you can, store the files on SAN exported as NFS (with a few tweaked I can get a good 250MB/s from it) and then have dual-gigabit from that to a switch with your servers, then the HDD in the server doesn't really matter (that's for centralized deployment)
17:13	<markit> oh, I've a 8GB ram, 4core xeon 32something, and I've the fear will be too slow! that's why I'm thinking about fat clients
17:13	<stgraber> alkisg: I had to start using bonding for all my appservs and file servers at the office, the disk controlers were just too fast for gigabit ;)
17:13	markit: for how many clients ?
17:13	<markit> oh, someone else alive in addition to me, alkisg and johnny! hi stgraber
17:13	16 clients
17:14	<stgraber> 16 clients on that kind of hardware won't be an issue
17:14	in some cases I run 50 clients on similar hardware (though firefox is running as localapp)
17:14	<markit> FF is what I feart will put everything in it's kneew
17:15	fear
17:15	<stgraber> yep, one single firefox+flash can take half of what you have ;) so that's why you want it as localapp
17:15	<alkisg> stgraber: is there any advantage in using SAN + bonding instead of some embedded RAID, for single server setups?
17:16	<markit> I've simulated startup and logged all 16 clients. KDE at first log creates it's directory structure in home dir and try to "migrate don't know what". I saw 4core at 100% for some minutes and was very scared
17:16	<stgraber> yes, kde is an issue ;)
17:16	last kde we deployed was kde3 with 8.04 then we switched all our customers to gnome
17:17	<markit> alkisg: btw, from my experience with proxmox, forget about "on board sata raid", and if you but a sas/sata RAID board, use with BBU (battery backup) and enable write through, otherwise will be VERY slow
17:17	<stgraber> gnome scales quite well once you do a few config changes, currently the server I'm running with the most thin clients runs something like 100-150 concurent gnome sessions
17:17	and it's just a dual-quadcore-i7 (appears as 16 cores) with 24GB of RAM
17:18	* alkisg didn't have any disk bottlenecks so far, as the server caches most of the needed data in RAM for my small setups...
17:18	<markit> stgraber: more or less, what kind of "gnome changes"? maybe I can get some tip for kde also
17:19	<stgraber> alkisg: depends on the controler, if you buy some actual decent controler like HP's P4xx serie, you should be good. Just forget about these cheap kind-of-RAID controlers you get on some computers.
17:19	<alkisg> Right, I've heard enough problems to know to avoid that :)
17:19	<stgraber> markit: patched glib and libc (at least for a while) to avoid having them read /proc/mounts (syncronous kernel call ...) every-time a thin client logs in
17:20	markit: at some point we'd have 100 process trying to access /proc/mounts at the same time, making the load go at something like 120 from time to time
17:20	we patched glib+libc to have them read /etc/mtab instead
17:21	that way we can filter it (as we mount most shares with "mount -n") and as it's an actual file, it gets cached and can be access asyncronously
17:23	<markit> so not gnome specific...
17:26	stgraber: are your's school installato of of what kind?
17:26	s/of of/or of
17:26	* markit is becoming too tired, not enough sleep does not forgive
17:27	<alkisg> markit: not all ltsp installations are schools :)
17:27	<markit> alkisg: that's why I'm asking
17:27	I dubt is for office
17:27	since GNU/linux seems not to be able to gain "professional" usage attention
17:30	<alkisg> http://www.revolutionlinux.com/
17:30	They do deploy for offices to, afaik
17:31	<markit> well, you have people to migrate to OOo, abandon Outlook, have accounting programs for gnu/linux, etc
17:31	not an easy task
17:32	technically is ok, but...
17:32	like you that have to package wine apps
17:32	the "old chains" are very strong
17:32	<stgraber> sorry, just got back.
17:32	markit: I'm the main developer of ltsp-cluster at Revolution Linux
17:33	markit: we have 10 or so mass deployments of LTSP in schools as well as usage in public administation and companies
17:33	<markit> stgraber: oh! incredible people you find in irc, lol
17:33	stgraber: what country?
17:33	* alkisg adds "and the current ubuntu ltsp maintainer" :)
17:33	<stgraber> markit: Canada
17:33	alkisg: yeah, that too ;)
17:33	<markit> lol, nothing more?
17:33	:)
17:33	<stgraber> a few more things but not too many LTSP-related ;)
17:33	<alkisg> He's also running for president, but he keeps it a secret :D
17:34	<stgraber> alkisg: shhh ;)
17:34	alkisg: btw, are you coming to BTS ?
17:34	<alkisg> stgraber: unfortunately no :(
17:34	It didn't work out....
17:35	<stgraber> doh ... would have been great meeting you there
17:35	<alkisg> Yeah, I was looking forward to meeting you all in person... :-/
17:35	* alkisg hopes for a EU bts some time in the future :)
17:35	<markit> stgraber: I see you have some eeepc pictures... had problems to make them boot properly
17:36	I've the feeling that Gbit pxe firmware does not work good with ltsp
17:36	<stgraber> alkisg: sadly there aren't many of us in Europe (anymore ;))
17:36	<markit> (like did not worked with some fujitsu pc I'm using, had to install 1.0 and not 1.0.1 gPXE that makes nic work at 100mbs)
17:37	<alkisg> markit: try the current git, 1.0.1 has some known problems. If that doesn't work, ask in #etherboot
17:38	<markit> alkisg: is there something I can ask and about you don't know the answer? :)
17:39	<alkisg> "what's the meaning of life"?
17:39	...oh no I know that, "42"...
17:39	:P
17:39	<markit> alkisg: I'm scared to ask, since I suspect you know the answer...
17:39	lol
17:39	<alkisg> (from the hitchiker's guide to the galaxy... nice book)
17:39	<markit> I know :)
17:40	btw also "on board pxe" fails
17:40	so I think could be a "ltsp side" problem, not pxe one
17:41	and works with 1.0 because has not e1000 driver
17:41	so probably runs the nic at slower speed in some compatibility mode
17:41	just my guess
17:42	<alkisg> LTSP isn't related to the pxe code, it just uses the tools
17:42	So if there's a bug, it's either in the nic rom, in dnsmasq, or in tftpd
17:43	<markit> alkisg: sure, I use "ltsp" in the wrong way
17:43	I always mean "server side"
17:44	I understand why johnny was upset yesterday, just I don't realize it
17:44	<alkisg> A wireshark dump would reveal the problem...
17:44	<markit> when I write
17:44	I've tried
17:44	seems that the packets flow, but very slow
17:44	I don't see retransmission or whatever
17:44	just a slow flow of packets
17:44	<alkisg> Which part is slow? The server or the client?
17:44	<markit> maybe I could try again
17:45	I've tcpdumped the server side
17:45	<alkisg> E.g. when the server receives a dhcp request, it should answer in a few msec
17:45	<markit> dhcp is very fast
17:45	the slow part is at
17:45	"loading vmlinuz..."
17:45	that takes, i.e. 4 minutes
17:45	<alkisg> That's tftp + pxe stack on the nic
17:46	<markit> then the stage "initrd.img..." takes another 4-5 minutes
17:46	<alkisg> Again, a dump + a bug report against the tftp server will get you on your way
17:46	<markit> and after 10min you are in gdm, you login and you are fast as hell (very fast)
17:46	<alkisg> If it proves to be a problem on your nic, then you should contact the laptop manufacturer :)
18:06	Anyone knows if udevadm is there on debian initramfs?
18:07	<markit> I'm on debian sid, if is something you can tell me how to check, I'll be happy to help
18:11	<alkisg> mkdir /tmp/initramfs && cd /tmp/initramfs && gunzip -c /initrd.img \| cpio -i -d -H newc --no-absolute-filenames && find . -name udevadm
18:15	moldy_ is now known as moldy
18:31	jhutchins_lt has joined #ltsp
18:32	vagrantc has joined #ltsp
18:37	<alkisg> vagrantc: hi, is udevadm there on the debian ltsp initramfs? I think we need a `test -b /dev/nbd0 \|\| udevadm settle` before running nbd-client...
18:44	* vagrantc looks
18:46	<alkisg> mkdir /tmp/initramfs && cd /tmp/initramfs && gunzip -c /initrd.img \| cpio -i -d -H newc --no-absolute-filenames && find . -name udevadm
18:46	<vagrantc> lsinitramfs
18:47	jhutchins_lt has quit IRC
18:47	<vagrantc> alkisg: i see sbin/udevadm
18:47	at least on squeeze
18:47	<alkisg> Thanks, that's fine
18:48	I'll tell some people to test that fix on their systems that experience the nbd problem on monday...
18:57	dgroos has joined #ltsp
19:02	<markit> alkisg: sorry, was away and missed your request
19:02	I've seen vagrantc catch it thoug, fortunatly
19:08	alkisg has quit IRC
19:10	jhutchins_lt has joined #ltsp
19:13	artista_frustrad has joined #ltsp
19:16	F-GT has quit IRC
19:18	artista_frustrad has quit IRC
19:27	jhutchins_lt has quit IRC
19:28	F-GT has joined #ltsp
19:38	F-GT has quit IRC
19:42	rjune has quit IRC
19:52	ogra_cmpc has quit IRC
19:55	rjune has joined #ltsp
20:04	ogra_cmpc has joined #ltsp
20:05	markit has quit IRC
20:06	F-GT has joined #ltsp
20:12	dgroos has quit IRC
20:26	markit has joined #ltsp
20:44	<highvoltage> can anyone else access the BTS 2010 wiki page fine?
20:45	chromium tells me that the page refers to itself in a loop and then stops the page
21:02	ogra has quit IRC
21:04	ogra has joined #ltsp
21:13	markit has quit IRC
21:35	jconlon has joined #ltsp
21:39	<jconlon> I am struggling to get an HP t5135 to work. It has a via chipset but hen I try to use XSERVER= via or openchrome it freezes. Only works with vesa but slow tho.
21:41	<pmatulis> re local app (say firefox), why does one need to specify SEARCH_DNS parameter in lts.conf? why isn't normal dhcp provisioning (domain-name-servers) sufficient?
21:42	leio has quit IRC
21:45	leio has joined #ltsp
21:46	<vagrantc> pmatulis: because it wasn't fixed until very recently.
21:46	<pmatulis> vagrantc: ah, a bug
21:47	vagrantc: do you know which version of LTSP has the fix? or which release of ubuntu will have it?
21:48	<vagrantc> pmatulis: should be fixed in debian 5.2.4-2
21:48	pmatulis: added a patchc from bzr.
21:52	<pmatulis> vagrantc: darn, ubuntu 10.10 will have 5.2.4-0
21:53	<vagrantc> pmatulis: should be able to get it patched to support it
21:54	stgraber: you should apply the patch i have for debian to support dhcp's dns server configuration
21:54	stgraber: er, the patch i have in debian's ltsp...
21:54	<pmatulis> vagrantc: yeah. now i wonder why it took so long to fix said bug. seems SEARCH_DNS has been around a long time
21:56	<vagrantc> i think, up until recently, most LTSP installs didn't need DNS
21:58	<pmatulis> vagrantc: ah right. local apps are recent
22:16	jconlon has quit IRC
22:45	mistik1_ has joined #ltsp
22:47	mistik1 has quit IRC
22:47	mistik1_ is now known as mistik1
22:52	pmatulis has quit IRC
22:54	artista_frustrad has joined #ltsp
22:59	artista_frustrad has quit IRC
23:58	vagrantc has quit IRC