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


Channel log from 26 March 2012   (all times are UTC)

02:07adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.170.194, Ping timeout: 250 seconds)
02:25tessier has left IRC (tessier!~treed@216.105.40.125, Changing host)
02:25tessier has joined IRC (tessier!~treed@kernel-panic/copilotco)
03:29alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
04:34alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:29bauerski has joined IRC (bauerski!~witekb@frodo.psp.opole.pl)
05:51Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
06:21siahos has left IRC (siahos!968c0b30@gateway/web/freenode/ip.150.140.11.48, Quit: Page closed)
06:50dobber has joined IRC (dobber!~dobber@213.169.45.222)
06:53Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Ping timeout: 272 seconds)
07:22Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com)
07:39monteslu__ has joined IRC (monteslu__!~monteslu@ip68-109-174-213.ph.ph.cox.net)
07:43monteslu_ has left IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 272 seconds)
08:21alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
09:00StevePerry has joined IRC (StevePerry!~StevePerr@CPE-124-178-180-118.lns4.pie.bigpond.net.au)
09:03
<StevePerry>
hey guys
09:03
any chance anyone can help me with my sanity with ltsp/rdesktop + centos 6.2 >.>
09:05
i cant connect to anything with rdesktop through pxe, im out of ideas as to why.."black screen with cursor only"
09:06
all hosts can ping each other and such.
09:06
SCREEN_07=rdesktop
09:07
any suggestions on where/what to check ?
09:11
<Hyperbyte>
StevePerry, is your chroot also Centos 6.2?
09:12
<StevePerry>
Scientific Linux 6.1 i think
09:12
i could be wrong >.>
09:12
<Hyperbyte>
cat /opt/ltsp/i386/etc/issue
09:13
'i386' could be something else
09:13
<StevePerry>
Scientific Linux 6.1
09:17monteslu__ is now known as monteslu
09:18
<Hyperbyte>
StevePerry, what happens if you do a regular install of Scientific Linux 6.1, and then use rdesktop from that to connect to your server?
09:18
(perhaps SL 6.1 has a live CD you can try with?)
09:18Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com)
09:18
<StevePerry>
ill give it a go and find out
09:18ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
09:21bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
09:45
<Hyperbyte>
My god... I just found out about the upcoming HTC One S
09:45* Hyperbyte drools
09:46
<StevePerry>
im waiting on samsung galaxy s3
09:46
>.>
09:46
one day...
09:47
hey i just ran scientific linux 6.1 livecd, and rdesktop connected to my servers fine
09:47
>.<
09:47
was kinda hoping it didnt
09:48
any ideas on what to try/look for from here ?
09:48
ive got nothin
09:58xsl has joined IRC (xsl!~silence@unaffiliated/xsl)
10:04xsl has left IRC (xsl!~silence@unaffiliated/xsl, Quit: Connection reset by fear)
10:11alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.12.47)
10:12alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Ping timeout: 245 seconds)
10:13
<Hyperbyte>
StevePerry, hmm... me neither (someone else might though)
10:13
Can you pastebin your lts.conf?
10:25
<StevePerry>
yeah
10:25
anything else i should put up ?
10:41toscalix has joined IRC (toscalix!~toscalix@62.87.117.194)
11:10StevePerry has left IRC (StevePerry!~StevePerr@CPE-124-178-180-118.lns4.pie.bigpond.net.au, )
11:13risca has left IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net, Quit: Lämnar)
11:14adrianorg_ has joined IRC (adrianorg_!~adrianorg@177.18.170.194)
11:39toscalix has left IRC (toscalix!~toscalix@62.87.117.194, Ping timeout: 246 seconds)
12:07bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 265 seconds)
12:12artista-frustrad has joined IRC (artista-frustrad!~fernando@200.247.43.2)
12:42
<alkisg>
ogra_: "unless you really need to force the lower depth ..." ==> isn't halfing the bandwidth a good enough reason?
12:42
<ogra_>
i think you will see a lot of banding on cheap LCDs with that
12:44
<alkisg>
I haven't noticed that... actually, when I have 2 VMs booted on the same screen, one with 16bpp and one with 32bpp, I have a hard time to tell which one's which
12:45
<ogra_>
then you have good panels ;)
12:45
<alkisg>
And from 76 mbps to 38 mbps, even if one can put his eyes close enough to the screen to tell the difference, I think he'll still appreciate more his video not lagging
12:45
Or his xterm scrolling better, etc etc
12:57
<ogra_>
well, up to you guys, its not that i (want to) have anything to say wrt dev decisions ;)
12:58* ogra_ will likely do some development next release, but only for new architecture support
13:03
<alkisg>
ogra_: you do know that we always appreciate your wisdom. :) I don't think anyone has actually seen real world problems with 16 bpp though (except with nv on TNT2, but now we've switched to nouveau)
13:07mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
13:15alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
13:15alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:16
<Hyperbyte>
alkisg++
13:18* alkisg also committed a DNS_SERVER=auto option... getting ready for ltsp-server-php... ;)
13:19
<Hyperbyte>
ltsp-server-php?
13:21* Hyperbyte shakes alkisg up and down
13:21
<Hyperbyte>
If you're doing something with PHP I need to know about it!
13:21
<alkisg>
!learn ltsp-server-pnp as An alternative to ltsp-server-standlone, this package uses dnsmasq in proxyDHCP mode, doesn't mind if an external dhcp server is around (e.g. a router), ships a default lts.conf that focuses on speed, etc etc
13:21
<ltsp>
alkisg: The operation succeeded.
13:21
<Hyperbyte>
....
13:21
<alkisg>
More when it's ready :D
13:21
<Hyperbyte>
What does this have to do with PHP?
13:21
Oh
13:21
PNP
13:21
<alkisg>
pnp == plug and play
13:22* Hyperbyte smacks alkisg
13:22
<Hyperbyte>
Yeah
13:22
<alkisg>
And put bigger glasses :P
13:22
<Hyperbyte>
Then actually -write- PNP please!
13:22
<alkisg>
Oooouch
13:22
<Hyperbyte>
15:18 ≡ alkisg/#ltsp also committed a DNS_SERVER=auto option... getting ready for ltsp-server-php... ;)
13:22* alkisg slaps himself
13:22* Hyperbyte smacks alkisg again!
13:22
<Hyperbyte>
:-D
13:22
<alkisg>
Hey I got today's dose, no more please, I'll get bruises :P
13:23
<Hyperbyte>
I'll make sure to not leave any. :P
13:23
<JesseC>
so wait, ltsp-server-pnp comes with the dnsmasq setup for dhcp proxying?
13:23
<Hyperbyte>
!ltsp-server-pnp | echo JesseC
13:23
<ltsp>
JesseC ltsp-server-pnp: An alternative to ltsp-server-standlone, this package uses dnsmasq in proxyDHCP mode, doesn't mind if an external dhcp server is around (e.g. a router), ships a default lts.conf that focuses on speed, etc etc
13:23
<Hyperbyte>
:P
13:23
<alkisg>
JesseC: that's the idea, although it's not ready yet, the first alpha will be out in a week or so
13:23
<JesseC>
Yeah I read that, was confirming that I read it correctly. =(
13:24
<Hyperbyte>
I'm just being silly. ;-)
13:24
<alkisg>
I'll put it in a PPA for 12.04, and if many people want it, we can ship it with ubuntu for 14.04
13:24
<JesseC>
dnsmasq was pretty easy to setup though, ~10 minutes
13:24
<alkisg>
That focuses on people that don't know how to do "sudo gedit /etc/dnsmasq.d/*"
13:25
Just install ltsp-server-pnp from synaptic, done, no need to install dnsmasq or configure it or create an lts.conf etc
13:25
<JesseC>
I think you told me to ready the guide at least 5 times and that's how I learned to do it. haha
13:25
read even..
13:25
<alkisg>
It'll also have nice pxe menus
13:26
http://alkisg.mysch.gr/steki/index.php?action=dlattach;topic=2828.0;attach=1672;image
13:26
Ah and it'll support using vbox to manage your chroots
13:26
No ltsp-build-client or ltsp-update-image anymore
13:26
<JesseC>
speaking of all this fancy new stuff
13:26bauerski has left IRC (bauerski!~witekb@frodo.psp.opole.pl, Quit: Leaving.)
13:26
<elias_a>
alkisg: Really? That's something!
13:27
<alkisg>
elias_a: many people are switching to fat clients, and chroots aren't really handy for managing fat disks
13:27
<elias_a>
alkisg: I understand.
13:27
<JesseC>
So we will be able to boot into the image using vbox
13:27
<elias_a>
I think it is a very good thing.
13:27
<JesseC>
and modify the image directly, gui and all?
13:28
<alkisg>
Yes
13:28
<elias_a>
Wow!
13:28
<JesseC>
=DDD
13:28
<alkisg>
Although an "ltsp-publish-image" is still required, that'll be handled by a GUI
13:28
(advanced users can directly export the vbox image, but not regular users)
13:28
<elias_a>
Is this channel logged publicly?
13:28
<alkisg>
!logs
13:28
<ltsp>
alkisg: logs: http://irclogs.ltsp.org/
13:29
<elias_a>
Just wanted to know because I want to quote todays discussion to a mailing list.
13:29
<alkisg>
elias_a: note that those are _my_ plans, not upstream ltsp's plans
13:30
But if many people start using ltsp-server-pnp, I guess it'll eventually end up in distros too, not just in a PPA
13:30
<elias_a>
alkisg: σας ευχαριστώ!
13:31
Message understood :)
13:31
<alkisg>
ole hyvä :)
13:31
<Hyperbyte>
You guys are messing up my terminal. :'(
13:31
<elias_a>
Kiitos!
13:31
<alkisg>
Hyperbyte: get a utf-8 capable terminal :D
13:31
<elias_a>
Hyperbyte: UTF-8 rules!
13:31
<Hyperbyte>
Noobs. :(
13:32
<elias_a>
ooo - one more channel to start UTF-8 wars on.... :)
13:32
<Hyperbyte>
Actually my IRC client isn't UTF-8 capable I think.
13:32
<elias_a>
Hyperbyte: What are u using?
13:33
<Hyperbyte>
Something so ancient it's pathetic.
13:34
BitchX-1.1-final+ by panasync - Linux 2.6.34.9-69.fc13.x86_64
13:35
<andygraybeal_>
zentyal has released a ltsp integrated module!!
13:36
<elias_a>
Hyperbyte: Oh that's a little aged, I agree...
13:36
<Hyperbyte>
elias_a, nostalgia. :-)
13:37
<elias_a>
I have to say I just love running irssi+screen in a shell...
13:37
Hyperbyte: It'll soon have vintage value... :)
13:37
<Hyperbyte>
I do the same thing, but with BitchX. :-)
13:49Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave)
13:50
<||cw>
Hyperbyte: for a minute there I thought you were going to say pirch
13:51
back in the day I wrote a little tray-app that listed for pirch dde commands and use ms's text to speach engine to read IRC to me
13:53
s/listed/listened/
13:59
<Hyperbyte>
=)
13:59
That'd be pretty easy to do with BitchX, if I weren't running it in a virtual screen terminal. :-)
14:05dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174)
14:11artista-frustrad has left IRC (artista-frustrad!~fernando@200.247.43.2, Read error: No route to host)
14:26artista_frustrad has joined IRC (artista_frustrad!~fernando@200.247.43.2)
14:26alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
14:26khildin has joined IRC (khildin!~khildin@ip-80-236-227-194.dsl.scarlet.be)
14:30
<||cw>
yeah, it wasn't hard then either, but I was "green" and it was my first forte into DDE, which is an odd little beast
14:30
<Hyperbyte>
:)
14:51staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-207.oregonstate.edu)
14:52bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9)
14:56bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
14:58Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Ping timeout: 240 seconds)
15:06leio has left IRC (leio!~leio@gentoo/developer/leio, Quit: No Ping reply in 180 seconds.)
15:06leio has joined IRC (leio!~leio@gentoo/developer/leio)
15:07toscalix has joined IRC (toscalix!~toscalix@235.184.219.87.dynamic.jazztel.es)
15:17vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
15:30risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca)
15:36Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
15:39dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection)
15:59Mava has left IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi, Read error: Connection reset by peer)
15:59Mava has joined IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi)
16:00bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 245 seconds)
16:02risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 246 seconds)
16:30Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Remote host closed the connection)
16:31toscalix has left IRC (toscalix!~toscalix@235.184.219.87.dynamic.jazztel.es, Ping timeout: 276 seconds)
16:35alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:36
<alkisg>
vagrantc: heya there, so in short, do you agree or not for X_COLOR_DEPTH=auto by default?
16:36
<vagrantc>
alkisg: dunno.
16:37rthomson has joined IRC (rthomson!~rthomson@mars.pet.ubc.ca)
16:37
<vagrantc>
i got a fair number of complaints about defaulting to 16-bit, actually, so was actually happy to let X.org do it's thing.
16:39
the more LTSP mucks with, the more we diverge from L
16:39
TSP5
16:39
but if the performance is really better for the common use-cases...
16:39
<alkisg>
What kind of complains though?
16:40
It's been a really long time since I've seen a client not supporting 16bpp...
16:40
(nv with TNT2, now nouveau has no problems with it)
16:40toscalix has joined IRC (toscalix!~toscalix@62.87.104.103)
16:40
<vagrantc>
people complaining about "why isn't this higher color depth? it looks awful."
16:41
<alkisg>
It does?!
16:41
Maybe they're talking about the ltsp logo which had 256 colors?
16:41
*ldm theme
16:41
<vagrantc>
i am relaying the complains that caused me to switch...
16:41
<alkisg>
OK, any other ones? Because I don't buy that one.. :D
16:42
<vagrantc>
that was it... definitely numerous complaints, though
16:42
<alkisg>
Mhm...
16:43
<vagrantc>
X_COLOR_DEPTH=auto suggests to me to leave X.org do it's thing, though.
16:43
<alkisg>
X_COLOR_DEPTH=unset, really
16:43
"By default, X_COLOR_DEPTH varies; it depends on ..."
16:43
"You can set a specific bpp to force it..."
16:44
<vagrantc>
well, if we default to X_COLOR_DEPTH=auto, how do you "unset" it?
16:44risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca)
16:44
<alkisg>
X_COLOR_DEPTH=""
16:44
<vagrantc>
that works in lts.conf?
16:44
<alkisg>
Yes, if you have backside code to handle it
16:44
<vagrantc>
seems... messy.
16:44
<alkisg>
if ${X_COLOR_DEPTH-not set} ...
16:45
<vagrantc>
i don't like having to add code like that for all of our variables.
16:45
<alkisg>
Why for all of them?
16:45
We only need "smart" defaults for a few of them
16:46
<vagrantc>
if one variables supports special behavior when unset, then it seems like it should be consiistant with all variables.
16:46
<alkisg>
When to have nbd swap, when to force LTSP_FATCLIENT=False...
16:46
The special behavior is only for the special variables though, that have a "smart" default
16:46* vagrantc rejects special variables
16:47
<alkisg>
OK, do you like the idea of an explicitly defined X_COLOR_DEPTH="smart" though?
16:47
<vagrantc>
i prefer to have a feature be on, or off. and if there's some autodetection needed, you should be able to turn it on or off.
16:47
<alkisg>
Ah. Then we could have an X_SMART_COLOR_DEPTH? :P
16:47
<vagrantc>
maybe.
16:47
<alkisg>
Which defaluts to true?
16:48
OK, let me think of better names there...
16:48
<vagrantc>
i am of mixed mind about the whole idea.
16:48
<alkisg>
lts.conf aside, do you like the concept of automatic detection?
16:48* vagrantc re-reads the proposal
16:48
<alkisg>
Because for LTSP 6, I really want to implement a proper configuration system...
16:48risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 248 seconds)
16:49
<alkisg>
*not proper, just another, i'm not suggesting that this one is not proper, it's just too mixed up now
16:49* alkisg hopes people here realize that non-english speakers don't always select appropriate words :)
16:51* vagrantc is forgiving and admiring of people who speak multiple languages
16:52
<vagrantc>
alkisg: so the proposal with LOCAL_APPS_MENU is a little odd ... if they're using local apps without the menu ...
16:52
<alkisg>
We do support TIMESERVER=auto, XSERVER=auto, LIVE_UDEVD=auto, X_MOUSE_PROTOCOL=auto, and I just put support for DNS_SERVER=auto
16:52
But if a better name like X_COLOR_DEPTH=smart would make more sense, sure
16:53
vagrantc: it is indeed odd, and Ben in the mailing list prefered X_COLOR_DEPTH=16 even with localapps enabled,
16:53
<vagrantc>
well, X_COLOR_DEPTH=auto ... i just feel like we *switched* to X.org autodetection
16:53
<alkisg>
but I was trying to prevent complains from people that use a lot of localapps
16:54
<vagrantc>
but definitely, a lot of FOO=auto seems to make it consistant
16:54
X_COLOR_DEPTH=auto in thin clients at least, seems to force 16 bit, rather than do autodetection.
16:55
<alkisg>
Supposedly, if one has configured a local web browser and flash, he might prefer the xorg default color depth. But I believe in that case we would have configured the menu. Also, personally I wouldn't mind having 16bpp even in that case, to make xterm and all the window movements etc faster.
16:56
<vagrantc>
i guess it's just a matter of what you're autodetecting
16:56
<alkisg>
Btw in my original proposal, I don't want to use "auto", it'll just be the default behavior
16:57
<vagrantc>
we're trying to detect use-cases where we would want to override the default X.org autodetection.
16:57
<alkisg>
And if one wants to get back to the old one, he'd have to use the weird X_COLOR_DEPTH="" syntax, but I wonder how many people would actually want to do that
16:57
<vagrantc>
alkisg: which doesn't leave a way to disable LTSP from mucking with it?
16:57
<alkisg>
So there's no "auto" involved
16:58* vagrantc doesn't like unset behaving differently from set to an empty value.
16:58
<alkisg>
Why not? If I set DNS_SERVER="", I get a different DNS server than if not setting it
16:58
<vagrantc>
i think unset and empty should be treated the same.
16:58
<alkisg>
(where we get it from dhcp)
16:58
Ah, no, currently not
16:58
<vagrantc>
*should* be.
16:58
<alkisg>
I *should* get a ... &
16:58
^
16:59
Erm, let me rephrase: what would you expect with DNS_SERVER="" vs unset?
16:59
<vagrantc>
i'd expect them to behave the same.
16:59
<alkisg>
So how can I override the dhcp provided values?
16:59
And force dns=none?
17:01
Second proposal.. how about the default X_COLOR_DEPTH to be what I said, and having X_COLOR_DEPTH="auto" would allow falling back to the default xorg detection?
17:02
<vagrantc>
alkisg: that would fit my concerns better.
17:03
setting DNS_SERVER=none might make sense.
17:04
<alkisg>
Does that also apply for X_COLOR_DEPTH=none? :-/
17:04
I don't know, but DNS_SERVER="", X_COLOR_DEPTH="" sound better to me, but no problem, I just want a way to apply that smart color depth thing
17:04
<vagrantc>
doesn't seem to make as much senese to me.
17:04
also, DNS_SERVER=auto would make sense to use the values provided from DHCP
17:05
<alkisg>
I think all those questions could go away if we supported an "unset" syntax in lts.conf
17:05
But anyway, for now, are you ok with that last proposal?
17:06
Default X_COLOR_DEPTH="unnamed smart logic", and X_COLOR_DEPTH="auto" just doesn't use -depth in X
17:07
And forcing X_COLOR_DEPTH="" again uses the smart logic
17:07risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca)
17:07
<vagrantc>
unset or "" should be equivalent, X_COLOR_DEPTH=auto LTSP doesn't do anything (i.e. default to X.org autodetection)?
17:08
<alkisg>
Yes
17:08
<vagrantc>
seems fine to me.
17:08
<alkisg>
Either that, or: we define a new name, e.g. X_COLOR_DEPTH=smart, which applies the new behavior only if set, without changing the default existing behavior
17:08
<vagrantc>
so the "" or unset cases use 16-bit on thin-clients, and are treated as if "auto" was set in other cases.
17:09
<alkisg>
Yes, and the only thing left is if you want that LOCAL_APPS_MENU addition or not
17:09
*exception
17:10
<vagrantc>
i wouldn't do any special handling of local apps ... they can set lts.conf if they want ?
17:10
<alkisg>
Sure
17:11
<vagrantc>
fatclients, it's obviously better to use X.org defaults, but with localapps it seems more case-by-case.
17:11
<alkisg>
OK, I'll push that, and commit to answer the first round of complains in the mailing list. If there are many people insisting, I'll say I'm sorry and revert to auto. :)
17:12
I'll also allow for defining X_COLOR_DEPTH="smart", in case that ever happens, so that people can be sure that will still work if explicitly defined
17:12
<vagrantc>
alkisg: i think the big pool of complaints came from debian-edu, although i've not been watching debian-edu much lately.
17:12
<alkisg>
Meh. Thin clients with tuxpaint in 32bpp?!!!
17:13
<vagrantc>
?
17:13
<alkisg>
All the edu apps we use here are very slow with 32bpp
17:13
I really wonder why one would want 32bpp for thin clients in an educational environment
17:13Meesterarend has joined IRC (Meesterarend!~meesterar@41.29.123.149)
17:13
<alkisg>
I was more worried about people that only have a couple of clients and don't mind the double bandwidth
17:15risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 260 seconds)
17:17
<alkisg>
Btw, I'm preparing "ltsp-server-pnp", that's why I'm pushing for those changes now, to get them in precise. I'll put some beta-quality code for pxemenus, automatic dnsmasq configuration etc, and we can strip the ones we want for upstream packages when we have enough feedback.
17:19komunista has joined IRC (komunista!~slavko@adsl-195-168-247-102.dynamic.nextra.sk)
17:24Meesterarend has left IRC (Meesterarend!~meesterar@41.29.123.149)
17:26
<alkisg>
Btw #2, thanks :)
17:42
<highvoltage>
hey Άλκης
17:52
<alkisg>
:)
17:53
vagrantc: on second thought... I'm pushing X_SMART_DEPTH=True by deafult, and people can change it to False if they want
17:53
highvoltage: would you be interested in creating a pxelinux theme for ltsp?
17:57
<vagrantc>
alkisg: seems reasonable too.
17:57
alkisg: that way we're not repurposing an existing argument, and it's easy to turn on/off
17:57
<alkisg>
There was some complexity in the code about X_COLOR_DEPTH in configure-x and in an altlinux initscript
17:58
So I thought I'd opt for the easiest implementation :D
17:58
<vagrantc>
altlinux hasn't committed code in years...
17:58
and configure-x should probably get removed... ?
17:59
alkisg: X_SMART_COLOR_DEPTH ?
17:59
<alkisg>
Sure
17:59
<vagrantc>
hmm...
17:59* vagrantc thinks more
17:59
<highvoltage>
alkisg: I saw your messages regarding that over the weekend. I'd like to but I'd first like to get my current to-do list down a bit (which hasn't been going great the last few weeks due to playing too much minecraft), but yes, I'd like to
18:00
<alkisg>
highvoltage: cool, yeah no hurries at all, it'll be in a PPA for starters
18:00
So there are no deadlines whatsoever, thanks
18:04
<highvoltage>
k
18:07
<alkisg>
Which one sounds better? XRANDR_COMMAND_0, XRANDR_CMD_0 or even plain XRANDR_0 ?
18:07
https://bugs.launchpad.net/ltsp/+bug/942608
18:11toscalix has left IRC (toscalix!~toscalix@62.87.104.103, Ping timeout: 260 seconds)
18:17
<vagrantc>
alkisg: i think i like XRANDR_COMMAND_NN or XRANDR_NN
18:17risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca)
18:17
<vagrantc>
little more preference for XRANDR_COMMAND
18:17
<alkisg>
vagrantc: ok, XRANDR_COMMAND_N it is :)
18:17
<vagrantc>
alkisg: 0-9 ?
18:18
<alkisg>
vagrantc: yes, the other xrandr variables are the same too, 0-9
18:18
I can also allow XRANDR_COMMAND_*, it makes no difference in the code complexity, if you prefer...
18:18
env | sed -n '/^XRANDR_COMMAND_[0-9]=/s///p' | while read command; do
18:18
# Remove possible "xrandr" in front of the command
18:18
command=${command#xrandr}
18:18
xrandr $command
18:18
done
18:19
<vagrantc>
which, is actually executing arbitrary commands
18:19
<alkisg>
Nope
18:19
<vagrantc>
ah, right.
18:20
<alkisg>
It allows for arbitrary xrandr arguments, but not running other commands
18:20
<vagrantc>
drop support for the old variables? or shoe-horn them into the current setup?
18:20* vagrantc wonders why it was done the way it is now.
18:20
<alkisg>
Dunno... I was planning to just add that
18:20
But I'd never use the other variables anyway
18:20
Except for XRANDR_MODE_0, that is
18:21
I think I'll leave the big XRANDR cleanup for the future, when we start using the new xorg equivalent snippets
18:21
E.g. PreferredMode instead of setting it with xrandr,
18:21
<vagrantc>
it probably started with XRANDR_MODE_0, which was from X_MODE_0 ... and then just evolved from there on a per-feature basis
18:21
<alkisg>
because that would start X at the desired resolution, instead of changing it later on and causing flicker
18:22
(man xorg.conf)
18:22
Position, LeftOf, and other fancy xrandr-supported options there
18:25artista_frustrad has left IRC (artista_frustrad!~fernando@200.247.43.2, Remote host closed the connection)
18:25adrianorg__ has joined IRC (adrianorg__!~adrianorg@177.18.170.194)
18:29adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.170.194, Ping timeout: 245 seconds)
18:29
<vagrantc>
alkisg: so you've changed your mind after mailing the ltsp list regarding X_COLOR_DEPTH? :)
18:30
<alkisg>
Yup I have to send another annoying email :)
18:31artista_frustrad has joined IRC (artista_frustrad!~fernando@200.247.43.2)
18:32
<vagrantc>
alkisg: why'd you put the color depth change in screen-session.d rather than ltsp_config.d ?
18:32
<alkisg>
vagrantc: we need to make a discussion about that, but I don't want to have a lot of ltsp_config.d variables overhead (storing, restoring etc) for variables that are only used in a single place
18:33
<vagrantc>
so instead we autodetect it every time it runs?
18:33
<alkisg>
Yes, if it can be autodetected with a single if, there's no point in saving/restoring it, too much overhead there
18:34
Let's postpone that discussion for when we redesign/clean up our configuration system
18:34ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
18:34Mava has left IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi, Read error: Connection reset by peer)
18:35Mava has joined IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi)
18:35ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
18:38
<vagrantc>
alkisg: but it was something that could be detected with a two-part if?
18:39
<alkisg>
vagrantc: ? if boolean_is_true "${X_SMART_COLOR_DEPTH:-True}" && ! boolean_is_true "${LTSP_FATCLIENT}"; then
18:39
That doesn't use any external commands at all.. set_lts_var writes a file, much more expensive...
18:39
<vagrantc>
alkisg: i don't see why that couldn't go in ltsp_config.d ...
18:39
ah.
18:40
<alkisg>
OK, let's discuss that a bit
18:40
ltsp_config.d now tries to handle everything
18:40
Even parts that some clients won't need
18:40
E.g. if a client uses SCREEN_07=shell, it doesn't care about X
18:40
So why not have the code run when it's actually needed?
18:41
<vagrantc>
the logic before was ltsp_config handled setting all configuration variables, and then the rest of the stuff just responded to teh configguration
18:41
<alkisg>
Actually ltsp_config now doesn't even use set_lts_var for all variables,
18:42
<vagrantc>
whee.
18:42
<alkisg>
and also half of the logic isn't in ltsp_config at all
18:42
It really needs a cleanup
18:43
<vagrantc>
what sets variables that's outside of ltsp_config (other than your recent commit) ?
18:43
definitely needs a good cleanup, yes.
18:45
<alkisg>
I also want to propose the rule that "variables in CAPS are exported in the environment, local script variables should use lowercase"
18:45
Now, one can't tell if X_ARGS is an lts.conf variable or an internal variable
18:46
So will configure-x.sh (which is executed) see it or not?
18:46
<vagrantc>
alkisg: i like the CAPS/lowercase distinctions
18:46
<alkisg>
X_RAMPERC=${X_RAMPERC:-100} => e.g. should that go in ltsp_config too?
18:47Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com)
18:47
<alkisg>
XCONF=/var/run/ltsp-xorg.conf.. the code is full of parts that set variables in caps
18:48
XSERVER=fbdev
18:48
Why would ltsp_config.d do an expensive `uname -m` call if X isn't going to run at all?
18:49
<vagrantc>
guess there's some logic to that.
18:49* vagrantc felt like the last BTS was a frenzy of code changes, rather than solid code review
18:49
<alkisg>
We should have a "get_lts_var XSERVER" at that point, and if it was cached, we'd avoid the uname -m the second time
18:50
Yeah it'd be better if we targetted more specific goals at BTS's
18:51
<vagrantc>
you talking about client/screen-session.d/XS20-xserver-ppc-r128-hack ?
18:51
<alkisg>
Yes
18:51
But there are many similar code samples all over trunk
18:52
<vagrantc>
wonder if that should go away? http://bugs.debian.org/587900
18:52
sure.
18:52
<alkisg>
So, new logic: defined points where we save and retrieve the configuration, similar to the -cluster ones
18:52
E.g. ldm loads them on init, before login etc
18:53
So XSERVER would be properly set at that case. If not, then that script would set it to fbdev.
18:53
Then the configuration would be saved, so it'd be there on next checks, avoiding the second uname
18:54
<vagrantc>
alkisg: so, when you upload a package, does launchpad not automatically register the bug as "Fix Released" or whatever?
18:54
<alkisg>
I don't have an overall design yet of course, just a general idea, it needs some more thinking
18:55
vagrantc: there's a bzr commit -fixes, I think that if I use it, it'll do it,
18:55
but it does close them on package uploads
18:55
Should we start using bzr commit -fixes?
18:55
<vagrantc>
alkisg: so you haven't been manually closing all those epoptes bugs? they always seem to come several days after a release actually gets uploaded... ?
18:56
alkisg: i'd rather not have to use the launchpad plugins to bzr.
18:56
<alkisg>
I think that there's some bug there, they're closed when syncing from debian, but not when directly uploading an ubuntu-specific version
18:57
So for the latest epoptes ubuntu upload I did have to close them manually :(
18:57
I haven't verified that "sync vs ubunt upload" bug though
19:00
<vagrantc>
highvoltage: i keep forgetting to look at ltsp-cluster*
19:00
<alkisg>
vagrantc: since LTSP bugs are reported on launchpad, I don't think it'd be bad to use -fixes for them either...
19:01* vagrantc will not use features that require bzr login
19:01
<alkisg>
Ah, it requires login? OK :)
19:03
<highvoltage>
vagrantc: we got ltsp-cluster-agent and ltsp-cluster-agent-weblive into ubuntu (by upload instead of sync), so there's no immediate rush, but it would be nice to get them into debian before freeze (do you happen to know when that is?)
19:03
<vagrantc>
dunno.
19:03
highvoltage: freeze is in june.
19:04
alkisg: looks like it might just record metadata in the commit, which would be fine.
19:04
although having to remember one more thing to commit...
19:04
<alkisg>
It's still optional, one can close the bugs manually if he doesn't remember it
19:04* vagrantc wonders if you can retroactively add --fixes for previously committed stuff
19:05
<highvoltage>
vagrantc: /win last
19:05
(oops)
19:05
<vagrantc>
highvoltage: might want to comment on the ITP's that they're in ubuntu
19:06
especially if the packaging is the same.
19:19
<highvoltage>
vagrantc: ok
19:26risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 248 seconds)
19:39monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net)
19:43monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 272 seconds)
19:52alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
19:53risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca)
20:01jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net)
20:03Lns has left IRC (Lns!~Lns@pdpc/supporter/professional/lns, Quit: Leaving)
20:07
<jvin>
If I turn off ltsp dhcp on eth1, and connect eth1 to the same switch eth0 is on (that has a router with dhcp), will clients attached on that same switch find ltsp ok (maybe need to reissue ltsp 'ssh-keys'/etc again)?
20:09
<Hyperbyte>
jvin, LTSP can work with any dhcp server, as long as it has the correct options set.
20:10
An LTSP client needs to know where to find kernel image to boot, and which server is the LTSP server.
20:10
If these are correctly passed by the dhcp server, then LTSP clients will boot properly.
20:10
!dhcp
20:10
<ltsp>
Hyperbyte: dhcp: http://wiki.ltsp.org/twiki/bin/view/Ltsp/DHCP
20:10
<Hyperbyte>
Actually scratch that.
20:11
If you can't set those options on the dhcp server, you can use proxy dhcp
20:11
!proxy-dhcp
20:11
<ltsp>
Hyperbyte: proxy-dhcp: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
20:19
<jvin>
Hyperbyte, the top level dhcp server is a standard ISP business/residential router so I'll have to use the proxy part. Thanks for the help! Off to experiment...
20:26khildin has left IRC (khildin!~khildin@ip-80-236-227-194.dsl.scarlet.be, Quit: I'm gone, bye bye)
20:43pari has joined IRC (pari!~priyank-u@122.177.237.225)
20:44
<pari>
Hi I am not able to boot my client, I am a newbie kindly help
20:45
I have followed steps in https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
20:45
but I am stuck since I am trying to boot using dnsmasq
20:46Parker955_Away is now known as Parker955
20:48
<pari>
Please give some links for my guidance
20:48
<vagrantc>
what have you done to configure dnsmasq?
20:50
<pari>
I just installed it and it was running fine
20:50
<vagrantc>
you're running ubuntu, i presume?
20:50
<pari>
yes
20:51
<vagrantc>
there should be an example dnsmasq file in /usr/share/doc/ltsp-server/examples/
20:52
<pari>
yes
20:52
its there
20:52
<vagrantc>
and you'll either need to drop a file in /etc/dnsmasq.d/ or edit /etc/dnsmasq.conf
20:52
<pari>
ok.. and how to configure it?
20:54
<vagrantc>
while it suppose dnsmasq, it's not really supported by default ... why not just use tftpd-hpa and isc-dhcp-server?
20:54
those should work out of the box ... otherwise, you'll have to experiment with the dnsmasq configuration options.
20:55
<pari>
can you help?
20:55
<vagrantc>
i'm trying...
20:55
if you just install tftpd-hpa and isc-dhcp-server it should "just work"
20:55
<pari>
ok let me try tftpd-hpa
20:56bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
20:56
<vagrantc>
pari: what part of the install is not working for you?
20:56
<pari>
both are installed
20:57
<vagrantc>
does this give you any output: pgrep -l -f 'tftpd|dhcpd'
20:58
<pari>
1213 /usr/sbin/in.tftpd --listen --user tftp --address 0.0.0.0:69 --secure /var/lib/tftpboot
20:59
can you take remote desktop for 5 min.. and let me know what mistakes I am making.? thanks
20:59
<vagrantc>
no
20:59
<pari>
ok
20:59
<vagrantc>
so dhcpd isn't running?
21:00
you have two network cards on the server, one for internet access, and one for the thin client network?
21:00
<pari>
no.. actually I am connected to a router and I am trying to boot client on VM
21:00
this is working OK sudo invoke-rc.d dnsmasq restart
21:00
<vagrantc>
ok, so your router is doing DHCP?
21:00
<pari>
yes
21:01
thats y i installed dnsmasq
21:01
<vagrantc>
so either your router needs to be configured to give the right boot arguments, or you need to use proxydhcp
21:01
!proxydhcp
21:01
<ltsp>
vagrantc: I do not know about 'proxydhcp', but I do know about these similar topics: 'proxy-dhcp'
21:01
<vagrantc>
!proxy-dhcp
21:01
<ltsp>
vagrantc: proxy-dhcp: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
21:02
<pari>
I followed that particular page only
21:02
I have already done all the things on that page
21:02
I have changed dhcp-range=192.168.1.2,proxy
21:03
when I start my VM error is coming fatal: could not read from the boot medium
21:04
I have already changed in Network tab value of Attached to: to Bridged Adapter
21:05
<vagrantc>
that's more likely an issue of your virtual machine configuration
21:05
is the bridge attached to your physical interface?
21:05
<pari>
that I am not sure of.. how to check?
21:06
<vagrantc>
what virtual machine software are you using?
21:06
<pari>
oracle VM
21:06
<vagrantc>
don't know anything about it
21:06
<pari>
ok...
21:07
<vagrantc>
sudo brctl show
21:07
if it's using standard linux bridging
21:08
<pari>
command not found
21:08
<vagrantc>
then it's probably doing it's own weird thing
21:09
<pari>
okk... is there any particular ubuntu distro which require min configuration while setting LTSP?
21:10
<vagrantc>
ubuntu's probably one of the simplest, but you've got some unusual networking requirements...
21:10
<pari>
ok.. so what according to you would be simplest approach to building ltsp system?
21:11
<vagrantc>
might be simpler to set up a virtual server as well as a virtual machine in order to learn the process... presuminng your VM environment can easily set up it's own virtual network for the thin clients
21:11Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Remote host closed the connection)
21:11
<pari>
okk
21:11
<vagrantc>
the simplest setup is a computer with two network cards, one facing the internet/local network, and one dedicated for the thin client network.
21:12
<pari>
okk...
21:12
thanks for your effort...
21:12
<vagrantc>
and then a separate thin client.
21:12
<pari>
ok
21:12Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
21:12
<vagrantc>
installing from the ubuntu alternate CD in that environment shoulld set up a fully functional LTSP.
21:13
<pari>
ubuntu alternate CD?
21:13
<vagrantc>
to start messing with unusual networking environments, you really need a solid grasp of DHCP, tftp, NBD/NFS, etc.
21:13
<pari>
okk yes
21:13
<vagrantc>
pari: the installer mentioned in the URL you pointed me to.
21:13
<pari>
thanks
21:14Parker955 is now known as Parker955_Away
21:14pari has left IRC (pari!~priyank-u@122.177.237.225, Quit: Leaving)
21:15* vagrantc wanders off to be useless
21:16Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave)
21:19bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9, Quit: Leaving.)
21:24artista_frustrad has left IRC (artista_frustrad!~fernando@200.247.43.2, Quit: Leaving)
21:39mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving)
21:53Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Ping timeout: 246 seconds)
21:53FatBastard has joined IRC (FatBastard!~Gary@ip-80-238-8-128.bskyb.com)
21:57Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
22:00FatBastard has left IRC (FatBastard!~Gary@ip-80-238-8-128.bskyb.com, Ping timeout: 276 seconds)
22:03Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
22:05alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.12.47, Quit: Хана X'ам !!!)
22:07Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com)
22:11komunista has left IRC (komunista!~slavko@adsl-195-168-247-102.dynamic.nextra.sk, Quit: Leaving.)
22:16bara has joined IRC (bara!~bara@zebar.de)
22:24bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 260 seconds)
22:27risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Quit: Lämnar)
22:28dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...)
22:34Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Ping timeout: 252 seconds)
23:12irule has joined IRC (irule!~irule@189.199.30.249)
23:16irule has left IRC (irule!~irule@189.199.30.249, Read error: Connection reset by peer)
23:20irule has joined IRC (irule!~irule@189.199.30.249)
23:28irule has left IRC (irule!~irule@189.199.30.249, Ping timeout: 260 seconds)
23:33irule has joined IRC (irule!~irule@189.199.30.249)
23:34* vagrantc just realized the problem with having all dirs in one directory for plugins
23:34
<vagrantc>
there's no way for add-ons to override the defaults.
23:35
i.e. if i wanted to override the plugin, i wouldn't be able to do so cleanly in an add-on package.
23:35vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving)
23:59irule has left IRC (irule!~irule@189.199.30.249, Ping timeout: 276 seconds)