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


Channel log from 23 April 2008   (all times are UTC)

00:01MacIver has quit IRC
00:08
<johnny>
i don't mean run autogen.sh in the tarball..
00:08
then again..
00:08
maybe i'm just too used to getting software out of version control :)
00:08MacIver has joined #ltsp
00:09
<johnny>
vagrantc, wanna humor me and take a look at my packaging for ldm?
00:10
http://git.overlays.gentoo.org/gitweb/?p=proj/ltsp.git;a=blob;f=x11-misc/ldm/ldm-9999.ebuild;h=5d271d59ada9e648eb35f077035f42a5ab48896a;hb=HEAD
00:12
<vagrantc>
johnny: after i get this upload done, gladly. :)
00:12
<johnny>
see.. i'm not in the complicated phase of actually distributing this thing yet
00:12
i can just laughat you for now :)
00:13
altho we never have to do uploads
00:13
at least not the way you do it
00:13
packaging in debian was alot more complicated
00:13
my first deb package EVER was ldm btw :)
00:13
for my ubuntu deployment
00:16
<vagrantc>
debian packaging has been accused of being overly complicated, indeed.
00:17
<generic>
helo ltspbot
00:17
any one works on ltsp clusters
00:17
?
00:17
<vagrantc>
although, when i say upload, about 70-90% of that just means testing it in virtualbox with several of the different possible modes
00:19
<johnny>
vagrantc, can you tell warren how to add a thing for fedora @ltspbot
00:20
so i can paste it to people when he is not here
00:28
<vagrantc>
johnny: "add a thing" ?
00:28
johnny: like ... learn FOO as BAR BAZ BAT syntax?
00:29
<johnny>
i guess
00:29
<vagrantc>
and then you say !FOO and it tells you all about FOO ?
00:30
<johnny>
!debian
00:30
<ltspbot>
johnny: "debian" is is a GNU/Linux based operating system that makes an excellent LTSP server. You can find it at http://www.debian.org. for information about LTSP on debian see http://wiki.debian.org/LTSP
00:30
<johnny>
yes :)
00:30
yes.. we should make warren write something for that
00:30
i will too when i get something i want to tell people about
00:31
of which i am pretty close
00:31
<vagrantc>
sure.
00:33
<generic>
ltspbot
00:33
?
00:33
what abt ltsp clusters
00:34
<vagrantc>
generic: what do you want to know?
00:34
<generic>
well i have 2 ltsp servers
00:34asac_ has joined #ltsp
00:34
<generic>
i want if my 1 server goes down users can login from other
00:35
also my all home dir should me replicated
00:35
and when both are up should load balance each other
00:35
?
00:35
any good howto?
00:35
<vagrantc>
requires a fair amount of manual configuration...
00:35
<generic>
sure but i need good howto
00:35
<vagrantc>
not aware of any documentation
00:36
<generic>
then
00:36
you did it or not?
00:36
<vagrantc>
no, i haven't done it.
00:37
<generic>
any guidence?
00:37
<vagrantc>
but i'm aware of some of the things necessary to do so... it's a good deal of work.
00:45asac has quit IRC
00:45asac_ is now known as asac
00:48
<dberkholz>
johnny: the ebuild looks fairly normal. what's the reason for the double testing of PV = 9999 near the top?
00:49
<johnny>
you mean this?
00:49
[[ ${PV} == 9999.* ]] && EBZR_REVISION="${PV/9999./}"
00:50
uhmm.. copied from another ebuild, what it should do, is allow you to pull a specific revision by nameing your ebuild package-9999.revno
00:51
its just a nice hack until -vcs suffixes come into play
00:52
<dberkholz>
johnny: the way i would do that would be to pass EBZR_REVISION into emerge from the environment
00:52
<johnny>
i was just going by convention i found in a bunch of ebuilds
00:53
i' not married to it
00:54
i think the only ebuild that needs more work is ltsp-server
00:54
it does work, you justhave to handle a few things manually afterwords
00:54
like /var/lib/tftpboot
00:54
and setting up your tftp server
00:54
other than that, just testing the ltsp-build-client again..
00:55
i added a few more bits for openrc, testing them out before commiting
00:55
your RCS_WHITELIST stuff needed editing
00:55
and i need to remember to rm net.eth0
00:55
so i added that into the quickstart profile
00:56
commiting that soon hopefully
00:56
been doing real work stuff last few days
00:56
damn openfire :(
00:56
it's all openfire's fault
00:56
tried and tried and tried to get http binding to work
00:57
so.. went back to ejabberd, now all is well
00:58
<dberkholz>
johnny: EAPI=1 should be the first noncomment line in an ebuild, because it tells portage how to read the rest of it
00:58
<johnny>
ok.. i'll make a note of it
00:58
it works?
00:58
i ran repoman over it before iirc
00:59
<dberkholz>
repoman might not check that yet
00:59
what's this supposed to do: 73 insinto /etc/xinetd.d/*
00:59
<johnny>
uhmm? how is that not self explanatory?
00:59
<dberkholz>
insinto, not doins
01:00
<johnny>
look below
01:00
<dberkholz>
what am i supposed to be seeing?
01:00
http://git.overlays.gentoo.org/gitweb/?p=proj/ltsp.git;a=blob;f=net-misc/ltsp-server/ltsp-server-9999.ebuild;h=9fad662af4169c9a6a17b1c5e557fabde0d44b4d;hb=HEAD to make sure you're seeing what i am
01:02
<generic>
vagrant ?
01:02
what are those
01:03
<johnny>
oh you're right.. i broke it
01:03
somehow that line got deleted
01:04
<dberkholz>
johnny: i think there's an xinetd use flag around for installing that stuff
01:05
<johnny>
use flag?
01:05
gonna have to point me to what yo're talking about
01:05
<dberkholz>
johnny: yeah. if use xinetd; then install xinetd files; fi
01:06
<johnny>
they aren't optional
01:06
<dberkholz>
there's some service only accessible with xinetd?
01:06
<johnny>
ldminfod
01:06
nbdroot
01:06
d
01:06
nbdswapd
01:06
we don't necessarily need those other two
01:06
but we do need ldminfod
01:07
ubuntu/debian use openbsd-inetd
01:07
that package doesn't exist in gentoo
01:07
<dberkholz>
mm. anyone explored the difference of making them standalone?
01:07
<johnny>
not sure
01:07
ask them :)
01:07
but atm, it is non optional
01:08deavid has joined #ltsp
01:09
<dberkholz>
the startup costs could be high if they get called often
01:09
<johnny>
ldminfo gets called when ldm starts up
01:09
so.. on login
01:10
nbdrootd and swapd, i think they get called once per boot, but i haven't really checked yet
01:12
it's a small problem tho..
01:12
the real problem is with applications :
01:13mccann has quit IRC
01:18mikkel has joined #ltsp
01:18
<vagrantc>
ldm 2.0.3 tagged, push(ing), tested, and uploaded to debian.
01:20
johnny: that URL is the entirety of your packaging?
01:21
<daduke>
vagrantc: bringing back directx w/ local USB?
01:21
<dberkholz>
cut off the url to proj/ltsp.git if you want to see the other packages besides ldm
01:21
<johnny>
for ldm yes :)
01:21
<vagrantc>
daduke: no, that was with the ltspfs upload two days ago. :)
01:21
<johnny>
the ltsp-server or client is more interesting
01:21
<dberkholz>
johnny: oh, for ldm i was thinking we probably want to hack client/server options into the autotools
01:21
<daduke>
vagrantc: even better. thanks.
01:22
<dberkholz>
johnny: er, ltspfs
01:22* dberkholz smokes less crack
01:22
<vagrantc>
daduke: i have etch backports ready for ltspfs and ltsp, and ldm should be on the way shortly.
01:22
<johnny>
dberkholz, only if it will go upstream..
01:22
otherwise you can do it
01:22
<daduke>
vagrantc: splendid
01:22
<dberkholz>
johnny: sounded fine with sbalneav when i talked to him about it a while ago
01:23
as long as the defaults don't change
01:23
<johnny>
cool
01:23
well.. go ahead with that.. :)
01:26
ok.. ltsp-server ebuild fixed
01:26
i'm in constant break fix mode here
01:26
adjust my quickstart config, test it
01:26
adjust again, test again
01:26
i'm making it actually care about --arch now
01:27
then i'll rename the profile to ltsp.qs
01:27subir has joined #ltsp
01:27
<johnny>
so the same profile will work with amd64 or x86
01:28
and will easy to add support for ppc too.. theoretically..
01:29
ok dudes.. i think i'm gonna head to bed, i'll get this arch stuff working sometime tomorrow and commit it
01:29
and do one more smoketest with the updated whitelist
01:30
then we'll have something that will only require manual setup of /var/lib/tftp
01:31
except editing the xinetd files to enable the services, and point tftp and dhcp to ltsp server
01:31
i'll try to find somebody with a spare machine to test for me
01:31
2GB ram isn't enough for me
01:32
and i haven't figured out how to adjust 2.6.24's scheduler to actually perform decently underload
01:32
pehraps you can help me with that tomorrow
01:32
<dberkholz>
johnny: you might want to try .25
01:32
johnny: referring to cpu or io?
01:32
<johnny>
i'm guessing i/o
01:32
but i'm no expert
01:32
<dberkholz>
change your io scheduler to cfq if it isn't already
01:32
<johnny>
it is
01:32indradg has quit IRC
01:33
<johnny>
been, since i ck stopped doing his patches
01:33
and 2.6.23.. was ok enough
01:33
but 2.6.24.. BADNESS
01:33
it's bad in hardy betas too!
01:33
update-manager takes FOREVER
01:33
and that's just doing binary packages
01:34
i can't web browse at the same time on that machine
01:34
i'm going to upgrade to 2.6.25 when vbox drivers are available
01:34
it is a registered bug
01:35
should occur in the next release hopefully
01:35
since fedora is already using 2.6.25
01:35
for some version or another
01:36
if it doesn't.. i'll stop using virtualbox and find something else ...
01:36
but i can afford to wait a bit longer atm
01:36
anyways.. it's 2am
01:36
err 2:30
01:36
i'm going to try to go bed early tonight
01:36
check you guys tomorrow
01:37plamengr has joined #ltsp
02:16
<vagrantc>
klausade, daduke: etch backports for ltsp, ltspfs and ldm updated.
02:19bobby_C has joined #ltsp
02:21plamengr has quit IRC
02:34
<daduke>
vagrantc: cool. gracias.
02:40
<vagrantc>
the ldm backport is actually newer than what's in sid, at least for a few more minutes
02:41vagrantc has quit IRC
02:41generic has quit IRC
02:41exodos has joined #ltsp
02:42generic has joined #ltsp
02:53toscalix has joined #ltsp
03:08ogra has quit IRC
03:09ogra has joined #ltsp
03:17exodos has quit IRC
03:19toscalix has quit IRC
03:23nantes_geek has joined #ltsp
03:23captain_1agnus has joined #ltsp
03:25
<nantes_geek>
have anyone pulseaudio running inside a ltsp 4.2 ?
03:27viking-ice has quit IRC
03:36captain_magnus has quit IRC
05:14toscalix has joined #ltsp
05:21hersonls has quit IRC
05:27generic has quit IRC
05:58toscalix has quit IRC
05:58captain_1agnus has quit IRC
05:59captain_magnus has joined #ltsp
06:06jammcq has joined #ltsp
06:08viking-ice has joined #ltsp
06:15hersonls has joined #ltsp
06:18TelnetManta has quit IRC
06:18
<jammcq>
hersonls: hey
06:19
<hersonls>
jammcq: hey
06:19
jammcq: you like fisl9.0?
06:20
<jammcq>
yes, I enjoyed it very much
06:20
i'm still traveling towards home
06:20
left POA yesterday
06:22
<hersonls>
)
06:22
:)
06:23
i like very much, if my first forum
06:24
is *
06:24
<jammcq>
that was my 6th forum
06:26
<hersonls>
good
06:26
:)
06:27
i work in ltsp for slackware, but slackusers no help
06:27
I am sad with them
06:28
<jammcq>
hmm
06:30
<hersonls>
But I never quit, I'm Brazilian
06:30
:D
06:32daya has joined #ltsp
06:40subir has quit IRC
06:48ogra has quit IRC
06:53jammcq has quit IRC
06:56ogra has joined #ltsp
06:59mhterres has joined #ltsp
07:02deavid has quit IRC
07:08Guaraldo has joined #ltsp
07:16TelnetManta has joined #ltsp
07:24daya has quit IRC
07:34slidesinger has joined #ltsp
07:36pscheie has joined #ltsp
07:37daya has joined #ltsp
07:52daya has quit IRC
07:54Q-FUNK has joined #ltsp
08:01Pascal_2 has quit IRC
08:07K_O-Gnom has joined #ltsp
08:14
<Q-FUNK>
nantes_geek: cou cou, me revoila!
08:15
<nantes_geek>
re Q-FUNK
08:15
<Q-FUNK>
:)
08:15
nantes_geek: so, any news?
08:16
<nantes_geek>
i'm back to ltsp 4.2 and i try a ltsp5 with mandriva 2006 (because of the Xorg version )
08:17
the bug is going to be fixe into the mandriva cooker ... so i'have just to wait
08:17
<Q-FUNK>
ah ok
08:21Bengoa has joined #ltsp
08:21
<Q-FUNK>
ogra: about that libDDC issue: when in June is 8.04.1 supposed to release?
08:21
<ogra>
no idea, really
08:22
https://wiki.ubuntu.com/HardyReleaseSchedule
08:22
July 3rd
08:26K_O-Gnom has quit IRC
08:29
<Q-FUNK>
ah, so july it is.
08:30K_O-Gnom has joined #ltsp
08:30
<Q-FUNK>
I suppose thta if Jordan releases his 2.9 driver in early june, we might have enough time to test this before the release?
08:33mccann has joined #ltsp
08:34
<warren>
Q-FUNK: so... bad news. Using the 12V @ 2A power supply, it is failing to boot the kernel immediately with "crc error" maybe 75% of the time. Sometimes it manages to get into memtest86+ where it shows intermittent errors at seemingly random memory addresses.
08:34
<ogra>
i'm not sure there will be any new upstream version for X in hardy at all
08:35
<warren>
Q-FUNK: the memory errors are never at the same location, but they are consistently 08000000, which is really strange.
08:35
<ogra>
it falls under the normal SRU rpocess ... that doesnt cover new upstream
08:35
*process
08:35
<Q-FUNK>
warren: so PSU issue, it seems. I know that the same 9v PSU we use are also sold as power for guitar pedals, though IIRC with reverse polarity.
08:36
ogra: right, so the only thing that could remotely be acceptable would be a 2.8.1 with only the libDDC added?
08:36
<ogra>
well, either that or a properly tested patch to 2.8.0
08:39
<Q-FUNK>
we cannot just patch. we need to regenerate all the autoconf stuff.
08:40
and just because of that, we'd end up with a diff that is bigger than the upstream tarball, which doesn't make sense.
08:40
just for the refreshed config.sub
08:40
<ogra>
well, policy ...
08:40
convince bryce to break it and there you go
08:40
but i doubt he will do that
08:40
especially for an LTS
08:41
<Q-FUNK>
the correct approach would be for you to reply to jordan and explain why a whole new major upstream would not be acceptable for hardy.1, but a small point release with just libDDC and a refreshed autotool might.
08:41
<ogra>
why me ?
08:41
thas bryces job
08:41
i'm not involved in X deveopment or maintenance
08:41
<Q-FUNK>
I cannot do it. it has to come from someone else who is concerned by this bug and who can explain the policy to him.
08:42
<ogra>
and i would get rude answeing him
08:42
he has a pretty elite attitude here
08:43
"because of the shitty distros we have to roll releases"
08:44
its just arrogant to ignore that the distros are the delivery path for your software to the users
08:44vagrantc has joined #ltsp
08:45
<ogra>
(reading his comment the first time i was really upset ... i'm not the right person to answer there)
08:46
<Q-FUNK>
ok
08:50* warren hunts for another PSU...
08:51Gadi has joined #ltsp
08:53* warren found 9V 150mA
08:54
<warren>
I can't even find a suitable power supply online anywhere
08:57
<ogra>
if you would have flipped polarity i would imagine te device to blow up
08:59
<warren>
I didn't flip polarity
09:00
<Q-FUNK>
well, there is a big zener diode there, but... it still wouldn't be a good diea
09:00
<warren>
I tried a 16V @ 4.5A after talking to co-workers. They suggested that the higher A doesn't matter because that's maximum load, and the website says 9-16V.
09:00
Then I tried 12V @ 2A because it seemed closer.
09:01
both now are exhibiting huge memory corruption
09:01
I guess the segfaults I was seeing since the first time I booted it were memory corruption as well.
09:02
<daduke>
warren: sorry to intrude, but what's your problem here exactly? I have a bit of a background in physics and EE..
09:02
<warren>
http://www.artecgroup.com/thincan/models.html
09:02
<Q-FUNK>
psu substitition, according to P = E * I
09:02
<warren>
I got a DBE61
09:02
website says 9-16V @ 1.5A
09:03Arauto has joined #ltsp
09:03
<warren>
I could only find a 16V @ 4.5 and 12V @ 2A
09:03
<Q-FUNK>
we normally use 9v 1.5a
09:04
<ogra>
my dbe60 says 9V/1.5A
09:04
<daduke>
warren: and you tried with anything from 12..16V, getting mem errors.
09:04
<ogra>
16 and 12 seem qute high
09:04
<Q-FUNK>
12v 1a would be an ok substitute
09:04
the general idea is, the higher the voltage, the lower the current needed
09:04
<warren>
"needed"
09:05
but doens't that current rated simply mean maximum?
09:05
(I might have got bad advice.)
09:05
<daduke>
not necessarily - the 9..16 V range suggests that there's a step-down converter on board that regulates input to probably 5V.
09:06
depending on the circuitry, 'excess' voltage might just be converted to heat.
09:06
<warren>
Hmm, the Linksys PSU is 12V @ 1A. I have an extra linksys somewhere here... I have to hunt for it.
09:06
P (voltage?) = E (???) * (current in units of amps?)
09:07
<ogra>
didnt they send you a power supply with that thing ?
09:07
<warren>
no
09:07
<ogra>
gah
09:08
<warren>
found my other linksys PSU
09:08
12V @ 1A
09:09
running now
09:09
I hope I didn't cause permanent damage with the other PSU's
09:10
doing memtest86+ now
09:11Blinny has joined #ltsp
09:12
<daduke>
vagrantc: good morning. who's the author of ldm? are you?
09:13
<ogra>
daduke, inital ldm (python and C version) were written by me, sbalneav took over about a year ago and rewrote the C thing i had
09:14
since then it lives from patches mostly and doesnt really have a dedictaed maintainer but the ltsp-upstream team
09:15
<daduke>
ogra: ok thanks. you're not aware of any DPMS efforts to turn off screens by any chance? I'm currently trying to figure out how to do that...
09:15
<warren>
sigh. still memory errors.
09:15
Q-FUNK: are you sure this unit was error free when you sent it?
09:15
Q-FUNK: or do you think I destroyed it..
09:15
<ogra>
daduke, xorg prob, i think vagrant added the possibility for X commandline options that can get handed over from the screen script
09:16
in a recent merge
09:16
<daduke>
ogra: oh, I have to look into that then!
09:16mikkel has quit IRC
09:17
<ogra>
i just heard though that the X dev team planned a completely new DPMS handling deeply integrated with *-power-manager for their next release
09:18
<daduke>
ogra: we have the absurd situation that our thin clients need < 10 W, but their screens use > 50 W. I'd like to get rid of that during night/weekend
09:19
<ogra>
well, a five line addition to configure-x.sh would suffice i think
09:20
or even doing it with X_OPTION_0
09:20
through lts.conf
09:20
<daduke>
ogra: that's what I'm trying to figure out atm. I've already enhanced configure-x.sh for font paths and screen rotation. Unfortunately it seems that certain hardware does not support DPMS. vbetool might be needed in these cases
09:21
<ogra>
really ?
09:21
did you try with X_OPTION_[00-12] ?
09:22
<daduke>
ogra: http://www.shallowsky.com/linux/x-screen-blanking.html, near the bottom. Our hardware/X driver might be affected
09:23
<Q-FUNK>
warren: worked just fine when I tested it
09:23
<ogra>
daduke, ah
09:23
<warren>
Q-FUNK: at first it was working, except random processes were segfaulting, I thought it was software bugs at first.
09:24
<ogra>
daduke, should work from rc.local even i dont think vbetool needs a running screen, it writes to the basic
09:24
<Q-FUNK>
warren: so which one is failing now? the A model?
09:24
<ogra>
s/basic/basic bios/
09:24
<warren>
Q-FUNK: the PXE boot one
09:25
Q-FUNK: I only used the 12V @ 2A PSU on the other one for a few seconds (long enough to find out that it doesn't like memtest86+ file format)
09:28
<daduke>
ogra: and X_OPTION_* is for X command line options or xorg.conf options?
09:28
<ogra>
xorg.conf
09:29
wnt help if you are forced to write to the vesa bios
09:29
<vagrantc>
daduke: for commandline options, use X_ARGS in lts.conf
09:30
<ogra>
vagrantc, in etch ?
09:30
thats pretty new, no ?
09:30
<daduke>
ogra: I'm gonna try w/o vbetool first. With X_OPTION, how to I tell which section to put it in?
09:30
<vagrantc>
ogra: just backported everything, and i think daduke is using backports
09:30
<daduke>
ogra: I got the latest backports, about 6 hours old.
09:31
vagrantc: USB sticks and directx is working fine again btw
09:31
<vagrantc>
ogra: got non-bzr versions for everything in unstable now :)
09:31
<ogra>
daduke, it will put it into the Device section
09:31
vagrantc, non-bzr ?
09:31
<vagrantc>
ogra: ! ~bzrDATESTRING
09:32
<ogra>
ah, yay
09:32
<vagrantc>
much easier on the eyes
09:32
ogra: how's your release going?
09:32
<daduke>
ogra: I'm not sure that's gonna work then. In my xorg.conf I have it in "Monitor" and "Screen"
09:45
<warren>
EE's in fedora are saying "Regardless, if you managed to toast it, they have a sadly inferior voltage regulator in there."
09:46
<ogra>
vagrantc, looking ok, i havent heard of bad showstoppers yet
09:46
vagrantc, and there is always 8.04.1 :)
09:46* ogra just got this intresting question: "apt mirror provision rpm to RHEL5 machines"
09:47
<ogra>
*can apt mirror
09:47
<vagrantc>
heh
09:47
<ogra>
well, RH has apt, no ?
09:48
<warren>
apt for rpm works fairly well
09:48
unless you're doing multilib
09:48
<ogra>
then apt-mirror might work as well, who knows :)
09:48
<warren>
yum has its own intelligent mirror selection
09:49
<ogra>
but that guy seems to use an ubuntu infrastucture and has just one RH machine it seems
09:49
<warren>
it would be trivial to build and installe createrepo on ubuntu
09:50
it is just a python script
09:50
<ogra>
sonds like a lacking area ... lets resign and found a company that provides inter distro tool development *G*
09:50
<vagrantc>
ogra: i'm still a little confused about what to do next regarding limiting the architectures on debian ... i can't really find any good documentation about dropping support for architectures...
09:50
<ogra>
adding [arch] to the Source line didnt help ?
09:51
<vagrantc>
ogra: it's not a valid thing to put in there.
09:51
<ogra>
i never had probs with that on Soyuz
09:51
<vagrantc>
that would seem like a nice and simple way to restrict architectures, but it's just not supported for some reason.
09:51
oh, really?
09:51
<ogra>
i usually just specify it in the Architecture line
09:51
but then we only have 6 arches here
09:52mhterres has quit IRC
09:52
<vagrantc>
well, if it is valid, it's not documented.
09:52
<ogra>
it doesnt attempt to build on arches that arent listed
09:52mhterres has joined #ltsp
09:52
<vagrantc>
ogra: in the source or the package section?
09:52
maybe the debian buildd's are just stupid.
09:53hersonls has quit IRC
09:53
<ogra>
5.6.8 Architecture
09:53
Depending on context and the control file used, the Architecture field can include the following sets of values:
09:53
*
09:53
A unique single word identifying a Debian machine architecture, see Architecture specification strings, Section 11.1.
09:53
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
09:53
<vagrantc>
yes, but then when it describes where you can put it ...
09:54
<ogra>
If a program needs to specify an architecture specification string in some place, it should select one of the strings provided by dpkg-architecture -L. The strings are in the format os-arch, though the OS part is sometimes elided, as when the OS is Linux.[69]
09:54
Architecture: i386 amd64 powerpc
09:55
<vagrantc>
the magic trick i want to do is have all the server-side stuff available for all architectures, while the client-side stuff only for a limited set of architectures.
09:55
<ogra>
that should work according to te doc
09:55
<warren>
Q-FUNK: some of my people are suggesting that it is dangerous to suggest 9-16V on your website because too many power supplies will spike over 16V
09:55
<ogra>
vagrantc, then mae ltsp-server/-standalone all ad the -client bits arch specific
09:55
*and
09:56
<vagrantc>
ogra: yeah, i've been thinking of doing that.
09:56
<Q-FUNK>
warren: this regulator can handle more. just that up to 16 is the safe range.
09:56
<vagrantc>
ogra: it's in section 5.2 of debian-policy where it doesn't mention the architecture in anything but the binary package paragraphs...
09:57
<ogra>
right
09:57
why should they mention it in source
09:57
<vagrantc>
for the buildd's
09:57
<ogra>
source is the same on all arches
09:57
build attempts should be according to the biary packages defined
09:58
*be done
09:58
if your arch isnt in the binary list, dont build it
09:58
<vagrantc>
otavio: if you have a moment, i'd like a little more input on limiting the architectures for ltsp ... i tried it, but all the buildd's are still trying to build the package ... is that expected?
09:58
<ogra>
thas definately work
09:59
gor your control file for paste ?
09:59
got
09:59
*thats definately wrong even
10:00
<otavio>
vagrantc: where's the control to me take a look?
10:01* vagrantc tries to paste it
10:02
<warren>
Q-FUNK: I put the unit in the freezer for a few minutes, then run memtest86+ again. 15 minutes with no errors now.
10:02
<Q-FUNK>
freezer?!
10:02
<warren>
bad idea? =)
10:03
<ltsppbot>
"vagrantc" pasted "debian/control for ltsp 5.1.3-1" (68 lines) at http://pastebot.ltsp.org/514
10:03
<vagrantc>
otavio, ogra: ^^
10:04
<ogra>
ltsp-client is wrong
10:04
<warren>
Q-FUNK: the outside is slightly above room temperature now, 16 minutes with no errors
10:04
<ogra>
vagrantc, it needs the same line as ltsp-client-core
10:04
<vagrantc>
ogra: well, that still shouldn't trigger the buildd's
10:04
<ogra>
for ltsp-client ? sure
10:05
it wont trigger then for -core only
10:05
<vagrantc>
ogra: buildd's don't build arch: all packages.
10:05
<ogra>
huh ?
10:05
indeed they do
10:05
<vagrantc>
not debian buildd's
10:05
<ogra>
on one buildd at least
10:06
<vagrantc>
ogra: but yes, i'll probably drop arch: all from ltsp-client*
10:06
<otavio>
vagrantc: it depends if they're or not available
10:06bobby_C has quit IRC
10:06
<otavio>
vagrantc: other... is "package [arch]" not "package[arch]"
10:07
<vagrantc>
otavio: i don't understand ...
10:07
<warren>
Q-FUNK: one memory error after 20 minutes =(
10:07
<vagrantc>
otavio: oh, you mean for the syslinux [i386 amd64] ?
10:08
otavio: vs. mkelfimage[i386] ?
10:08
<Q-FUNK>
warren: after 20 minutes running memtest+?
10:08
<warren>
Q-FUNK: yes
10:08
Q-FUNK: just a single bit on one memory location
10:08slidesinger has quit IRC
10:08
<warren>
there goes another one
10:08
<otavio>
vagrantc: yes
10:08
<Q-FUNK>
hmm. not good.
10:08
<otavio>
vagrantc: you need to request package removal from other architectures.
10:08
<warren>
Q-FUNK: strangely all error bits are 08000000
10:09
<Q-FUNK>
?!
10:09
<warren>
Q-FUNK: whatever it should have been plus 08000000
10:09
<vagrantc>
otavio: and then make ltsp-client: Architecture: amd64 i386 powerpc (instead of all) ... and then i'll be able to have the server-side stuff on all arches, and the client-side stuff only on amd64 i386 powerpc ?
10:10
otavio: do you know if there's much documentation about requesting package removals? i haven't found much.
10:11Faithful has quit IRC
10:11
<otavio>
vagrantc: i think it works. Do that
10:12
vagrantc: I can try to find it for you but the best is to talk at #debian-devel and ask for guidance.
10:12
<vagrantc>
otavio: so i request removal of ltsp-client* from all architectures except amd64 i386 and powerpc ?
10:12
<otavio>
vagrantc: people are willing to help most of time
10:12
vagrantc: yes
10:12* vagrantc is scared of #debian-devel
10:12
<ogra>
heh
10:12
<vagrantc>
it's one of those channels that has infinite scrolling
10:12
<Q-FUNK>
#debian-devil ?
10:12
<ogra>
come over to #ubuntu-devel, its warm and fuzzy
10:13
<vagrantc>
it's mostly just the volume of information
10:13
<Q-FUNK>
warren: is that the address reported by memtest+ or some value?
10:13
<ogra>
hm, #ubuntu has only 1300 ppl today
10:13
thas not much a day before release
10:14
<Q-FUNK>
warren: knowning exactly which info line in the memtest+ resulted reportted this could help us track it
10:14* ogra goes to check #ubuntu-release-party
10:14
<ogra>
pfft only 130 users yet
10:14
<warren>
Q-FUNK: it looks like random memory locations, but consistently the memory is corrupted by + 08000000
10:14
<johnny>
i'm sure lots of people give up on #ubuntu
10:14
i know i do
10:14
or did
10:15
<warren>
http://fakejonobacon.blogspot.com/ "I love the community. I am the Community Manager for Ubuntu, which is like Debian without the morals."
10:15
<ogra>
johnny, i still do support from time to time o a bored sunday there
10:15
oooooh
10:15
<Q-FUNK>
warren: as far as our guys can tell, the only thing that could cause this would be a bad solder on one of the chips' data line
10:16
<ogra>
the bind/unbind feature of blockdevices in the kernel is COOL !
10:16deavid has joined #ltsp
10:16mccann has quit IRC
10:16
<warren>
Q-FUNK: I love inconsistent consistent failures.
10:17* ogra hugs whoever that added (gregkh likely)
10:17
<warren>
ogra: what exactly does that do?
10:17
<Q-FUNK>
warren: that's the interesting part. constant offset
10:17
<ogra>
warren, it behaves like unplugging/plugging a disk
10:18
warren, i had massive probs with getting the classmate installer re-read the partitions properly after fdisk
10:18
<warren>
Q-FUNK: it began happening on this thincan only after ~20 minutes or so when it heated back up
10:18
Q-FUNK: 12V @ 1A power supply
10:18
<ogra>
warren, http://paste.ubuntu.com/7858/ that solves it easily :)
10:19
<warren>
ogra: The way fdisk behaves is poor, that's why we left it behind in Fedora
10:19
ogra: the alternatives have nice API's to drive with other interfaces anyway
10:19
<ogra>
well, i didnt want to reinvent the whell for a scripted installer
10:19
*wheel
10:19
i could have taken parted but that seemed overkill
10:19
<warren>
we've abandoned fdisk maybe 3-4 years ago
10:20
what are you using fdisk for?
10:20
<ogra>
i have a fixed partition tabe and no user interaction ... just cat'ing a here document to fdisk is sufficient
10:20
it was just not re reading the new table
10:22
warren, its an installer for the classmate PC, pretty much everything hardcoded (same HW everywhere, wipe out install)
10:23
<warren>
sfdisk has a really nice way of doing that
10:23artista-frustrad has quit IRC
10:23
<vagrantc>
ogra: sfdisk is nice
10:23
<ogra>
likely, but i wont change the partitioning part a day before release :)
10:23
<warren>
ogra: http://togami.com/~warren/guides/remoteraidcrazies/ look at how I use sfdisk here.
10:24
<daduke>
ogra: patching the DPMS stuff into xorg.conf via configure-x.sh did the trick. thanks for your help
10:25alekibango has joined #ltsp
10:25staffencasa has joined #ltsp
10:25
<warren>
Q-FUNK: I'm trying to hack mkelfImage now to get it to wrap memtest86+ so I can run it on the other thincan
10:26
(mkelfImage is the right tool?)
10:26
<Q-FUNK>
yes
10:27
well, you just need to use mkelfimage to consider memtest86+ as a kernel that needs to be processed into an elf image
10:34artista_frustrad has joined #ltsp
10:36
<warren>
yeah, it doesn't recognize the memtest86+ as a kernel
10:36
memtest86+ is based on a linux 1.0-ish kernel
10:38
<ogra>
daduke, trun it into a patch (with lts.conf option) ;)
10:39
<warren>
Q-FUNK: if I ship the PXE unit back to you, will there be customs/duty problems?
10:39mikkel has joined #ltsp
10:39
<Q-FUNK>
not if you mark it as an RMA in the declaration
10:40
as long as it's clear that it's being returned for repairs, it should be ok
10:40
<johnny>
Q-FUNK, send me some :)
10:40
lol
10:40
<Q-FUNK>
johnny: ? :)
10:40
<warren>
at least the coreboot + etherboot unit was the important one for me to get working
10:40
<johnny>
oh.. i'm just using desktops atm
10:40
<warren>
this is my only coreboot + etherboot unit
10:40
<daduke>
ogra: yeah, why not. but it's a rather ugly - I s/Section Monitor/Section Monitor\n\tOption "DPMS"/ the generated xorg.conf. I'm not sure that's ready for prime time...
10:40
<Q-FUNK>
warren: yes, as long as bad american line voltage doesn't zap it! :-P
10:41
ogra: btw, whatever happened to sbalneav?
10:41
<daduke>
ogra: it's the same way we use to include mathematica fonts and "Rotate" "CCW"
10:41
<ogra>
Q-FUNK, busy i guess
10:41
<johnny>
so i'm just begging :)
10:42
<warren>
johnny: do you have limited access to grumpy X and kernel deveopers?
10:42
=)
10:42
<johnny>
who doesn't? :)
10:42
<warren>
I ride the bus with them. They can't ignore me on the bus ride.
10:43
<johnny>
kick their asses
10:43
<ogra>
lock them in your closet and breed more :)
10:43
<johnny>
i think spawn is a better word for those types
10:43
jk :)
10:43
<ogra>
that *must* work if you keep them in there long enough
10:43
<laga>
fork()
10:44
<johnny>
the ratio of male to female kernel developers is heavily weighed on the male side..
10:46
<ogra>
johnny, they reproduce through binary osmosis ...
10:46
no wimen needed
10:46
<Q-FUNK>
ogra: I would have been curious to hear from him, Gadi and you about how the bios upgrade went on the units with the old bios
10:46
<johnny>
aha...
10:46
<Q-FUNK>
ogra: does it work on humans too?
10:47Blinny has quit IRC
10:47
<ogra>
binary osmisis ?
10:48
<Q-FUNK>
yeah
10:48
<ogra>
i have no idea what that is so it might ... :)
10:48
...who knows ...
10:48
:)
10:49
wow the term actually exists just the other way round
10:49
Reverse Osmosis of Binary Organic Solute Mixtures in the Presence of Strong Solute-Membrane Affinity
10:49
now thats a sexy heading isnt it ?
10:49
<johnny>
it's getting hot in here
10:49
<ogra>
i which my job would foce me to invent such creative headings for my docs :)
10:49
<Q-FUNK>
so take off...
10:49
<johnny>
please.. keep all your clothes on..
10:50
Q-FUNK, where are you?
10:50
<Q-FUNK>
up north. Eesti
10:51
<johnny>
huh?
10:51
<Q-FUNK>
erm.. tnhat thesis title doesn't compute. we need to break the strong membrane before organic mixes can occur.
10:51
http://www.welcometoestonia.com/
10:51
<johnny>
oh...
10:51
duh
10:51
i wouldn't call that much more north
10:51
more like waaay east :)
10:52
i shoulda known that
10:53
<Q-FUNK>
north and east :)
10:53
<johnny>
much more east than north
10:54* johnny fights css
10:54
<Q-FUNK>
we're higher than alaska, IIRC
10:55
<ogra>
jamaika is higher :P
10:55* johnny feels welcome in estonia
10:57
<Q-FUNK>
airee, mon
10:58
ogra: well, with all the happy pills circulating in this country and the illegitimate kids that result, I feel safe in stating that Jah is with is in Tallinn :)
10:58
<johnny>
Q-FUNK, try not to take your cultural cues from this side of the world :)
10:58
<daduke>
Baltic Tiger, roar!
10:59
<ogra>
heh
10:59* daduke is reading wikipedia... flat tax?
10:59
<Q-FUNK>
yup. flat tax.
11:00
the most brlilliant invention ever.
11:00
<ogra>
you mean like ... nothing ?
11:00
<Q-FUNK>
no complicated calculation to figure out how much you'll owe the taxman, even if your salary varies.
11:00
<ogra>
zero ?
11:00
<daduke>
they're discussing it in parts of .ch too...
11:00
<Q-FUNK>
no, as in fixed percentage.
11:00
<ogra>
or a fixed value
11:01
ah
11:01
cool
11:01
<Q-FUNK>
currently 21%
11:01
they're dropping one percent per year. they intend on stopping in 2010, when it will stabilize at 18%.
11:01
<daduke>
internet access for free??? come on..
11:02
<wwx>
so? normal there
11:02
<Q-FUNK>
daduke: yup. free wifi pretty much everywhere, including gas stations
11:02* daduke considers changing his travel plans..
11:02
<ogra>
daduke, its EU :) you can live there if you want
11:03
<wwx>
in libraries there are public access internet ... just computers, which can be used by everyone
11:03
<Q-FUNK>
it always puzzles people, why in gas stations, but the explanation is simple: truckers need to access their bank account and government services while on the road too.
11:03
<daduke>
ogra: I know. but no Euro yet?
11:03
<ogra>
i thought they recently switched ?
11:03
Q-FUNK, ?
11:03
didnt you
11:03
<johnny>
so, who wants to find a reason to pay me to come to estonia..
11:03
<Q-FUNK>
accession to the euro is subject to separate criteria
11:04
ogra: slovenia did. lithuanian almost qualified too.
11:04
<ogra>
oh, i thought estonia was in the chunk with poland and romania
11:04
<wwx>
:)
11:04
<ogra>
so i thought lithuania was too
11:04
<Q-FUNK>
9 9 9
11:05
only one of the 2004 countries managed to control their inflation enough to qualify: slovenia. lithuania missed the mark by only 0.1%. others had either too much inflation or not fully recovered from their soviet chaos.
11:06
<daduke>
1.3M ppl? cute, even .ch's gotten more..
11:07
<Q-FUNK>
curent discussions for transition to the euro place the baltic countries and czekia as the next ones, for 2010, IIRC
11:08
ah, hungary too
11:08
<ogra>
well, thats not to far
11:08
<Q-FUNK>
the main two criteria are strong economy with low inflation
11:09
still, I love this place so much that I'm wrapping things up in fucking finland before the end of this month and bringing the rest of my stuff here.
11:11
grmbl. seems I shot myself in the foot by insisting that Hardy should ship with geode 2.8.0 instead of amd 2.7.7.7
11:12vagrantc has quit IRC
11:12
<Q-FUNK>
ogra: I know that vorlon will kill me, but is there any way that we can revert that AND use my 2.7.7.8 with the libDDC patch instead?
11:12
or how do you propose that we solve this?
11:14
wwx: thank goodness, they don't have to place livonia on the map :-P
11:18weiss__ has joined #ltsp
11:19
<weiss__>
hi
11:19
anyone familiar with DiskOnChip technology?
11:19
<Q-FUNK>
a bit
11:20
<weiss__>
im trying to grasp how the whole thing works...i understand it installs a bios extension
11:20
<Q-FUNK>
we have that in one of our legacy products
11:20
<weiss__>
and that its supposed to emulate a harddrive
11:20
im wondering if the emulation is done by patching the bios, or at the driver level
11:20
i've seen that Linux and other OSes have drivers for it, but on the other hand
11:20
according to documentation, DOS supports it natively
11:20
so im confused
11:20
<Q-FUNK>
driver level
11:20
IIRC
11:21
<weiss__>
IIRC?
11:21
<Q-FUNK>
weiss__: what's the hardware?
11:21
<weiss__>
Q-FUNK, Single Board Computer (x86), altho im trying to get a general understanding
11:22
<Q-FUNK>
some Geode variant?
11:22mccann has joined #ltsp
11:22
<ogra>
the classmate PC i got here uses such devices, they appear like a normal (USB) disk to the kernel here
11:22
<weiss__>
Q-FUNK, no some embedded product
11:22
<Q-FUNK>
namely, which one?
11:23
<weiss__>
Q-FUNK, something propietary used in an assembly line
11:23Skarmeth has joined #ltsp
11:23
<Q-FUNK>
weiss__: so what prompted you to ask LTSP people about this, then?
11:24
<weiss__>
Q-FUNK, I couldn't find anyone who knows anything about it ;)
11:24
<warren>
Q-FUNK: what is the best address to ship it back to?
11:25
<weiss__>
okay, driver then...
11:26
<wwx>
weiss__, you can try to find something on sandisk website, sandisk acquired m-systems couple of years ago and year ago or so some doc-s was there
11:26
<weiss__>
i've read that it has a 8k window in memory, that must be where the 'flash pointer' is pointing at...how would you switch to another flash address? I/O ports?
11:26
<Q-FUNK>
wwx: oh, they did?
11:26* weiss__ attempts to rtfm
11:26
<Q-FUNK>
that would explain the crappy quality of sandisk USB sticks :)
11:27
<weiss__>
heh
11:31
<wwx>
Q-FUNK, yes. and this attitude sucks... nothing was left aside press release, no docs anymore :-(
11:31
http://www.sandisk.com/Corporate/PressRoom/PressReleases/PressRelease.aspx?ID=3494
11:32
<Q-FUNK>
wwx: so they bought the technology and then it disappeared?
11:32
<wwx>
diskonchip tech is considered obsolete, yes
11:32
<Q-FUNK>
that too
11:33Q-FUNK has quit IRC
11:34
<wwx>
weiss__, you can google for some tools, which can handle those DoC-s... they have special tools for this (under DOS mostly)
11:36
<weiss__>
wwx, yes i've seen them
11:36
<wwx>
but generally DoC is flash with little internal cpu + firmware. for outside world this looks like ordinary disk, you can even partition it with fdisk and such
11:36
<weiss__>
wwx, no, as you guys said, to the outer world *who has a driver* it looks like a regular disk
11:36
quite different
11:37
im wondering if its interface is documented enough so you could patch Bochs to emulate it
11:38nantes_geek has quit IRC
11:38
<wwx>
afaik DoC doesn't require any drivers, only when internal repartitioning required (bad block map and such). Under DOS those worked without drivers
11:38
<weiss__>
oh
11:38
so why does linux needs a driver?
11:39
i've seen articles that explains how to boot linux from DiskOnChip, if it emulates a disk, why is that worth mentioning?
11:39
<wwx>
but i don't know very much, i've seen one industrial system with DoC... and since Dos works entirely on BIOS calls (int 13), then maybe bios contains some special stuff
11:39vagrantc has joined #ltsp
11:45
<wwx>
ehh...
11:45
The DiskOnChip has built-in firmware that is visible in the CPU
11:45
address range, reserved for BIOS expansions. Being executed by the
11:45
BIOS, the DiskOnChip firmware installs itself at INT 13h (BIOS disk
11:45
services), thus providing full read/write emulation of a hard disk.
11:46
<ogra>
right
11:46
so you should just see a HDD
11:46
(SDD to be precise :) )
11:46
<wwx>
yes... but only under such os, which lives on int 13
11:47
<weiss__>
ah, i see
11:48
wwx, thanks ;)
12:01makghosh has joined #ltsp
12:08deavid has quit IRC
12:11Q-FUNK has joined #ltsp
12:12viking-ice has quit IRC
12:13
<Q-FUNK>
daduke: see, I'm now sitting in one of Tallinn's many designer bar/cocktail lounge/restaurants. wifi comes as a byproduct of sitting here.
12:19
<ogra>
they serve designers in your bars ? *shudder*
12:20BGomes has joined #ltsp
12:20
<Q-FUNK>
hehe
12:21
well, many places here won prizes for their design
12:21
pretty cool interior design
12:21hersonls has joined #ltsp
12:22
<laga>
who gave out the prizes? designer bars/cocktail lounges/restaurants? ;)
12:22
<Q-FUNK>
some were rpized by some british design magazines
12:22
e.g. Wallpaper*
12:26deavid has joined #ltsp
12:36Q-FUNK has quit IRC
12:36Q-FUNK has joined #ltsp
12:48deavid has quit IRC
12:59
<lns>
Q-FUNK, so are you installing ltsp in these award winning bars? =)
13:00
<Q-FUNK>
lns: what for? everyone has laptops here
13:01
<lns>
Q-FUNK, maybe for those who don't have laptops? hmmm... like at the corner of the bar where normally you'd have a little tabletop videogame or something
13:01
<Q-FUNK>
they don't have those here
13:01
they have snooker tables and mabe one videopoker
13:01
<lns>
there ya go
13:01
tabletop ltsp ;)
13:02
with LAN-based frozen-bubble (if that worked well in ltsp)
13:02
<wwx>
ltsp is a bit... overengineered. but this is only my humble opinion
13:02
<lns>
wwx, ?
13:03
<wwx>
local apps for example
13:03
<lns>
wwx, do you mean local apps shouldn't be a part of ltsp?
13:03
i'm not following
13:04
<wwx>
yes. generally those terminals are low end computers with low memory and weak cpu
13:04
<laga>
i guess LTSP isn't needed if you only have one client ;)
13:04
<vagrantc>
wwx: less and less the case with each passing day.
13:05
wwx: even slow computers are getting to be remarkably fast.
13:05
<lns>
wwx, i think the good thing about local apps is that it's there if you WANT it...of course not required
13:05
yet very useful for things like firefox (maybe that'll change w/ff3)
13:05
<vagrantc>
local apps isn't in ltsp5 at all, really. it's all manual configuration.
13:06
<lns>
vagrantc, the truth comes out! =p
13:06
do-it-yourself-ware ;)
13:06
<wwx>
lns, agreed. but i don't think any old pc or terminal can run firefox at usable speed
13:07
as i said, this is only my humble (and nothing more) opinion
13:07
<lns>
wwx, i'm sure there are installations out there that use higher-end terminals than you're thinking
13:07
<loather-work>
my terminals have a 250MHz CPU and 128M RAM.
13:07
<wwx>
lns, of course it is
13:07
<loather-work>
Firefox would eat it alive and be begging for more.
13:07
<vagrantc>
it's not uncommon to have lots of "old" 1GHz, 256MB ram machines in some places.
13:08
<johnny>
that's my machines
13:08
for the most part
13:08
<Gadi>
sounds like over-engineered for some, under-engineered for others :)
13:08
<lns>
Gadi, ;)
13:08
<wwx>
Gadi, :-) yes
13:08
<vagrantc>
basically, ltsp is just a framework for a wide variety of needs.
13:09
<Gadi>
wwx - it would prolly be more 'over-engineered' if ur low-end clients didnt work out of the box
13:09
but, they do
13:09
:)
13:09
<wwx>
second thing i don't like very much is ltspfs need for some specific display manager. don't know how this now, but year ago it need something ltsp specific
13:10
<vagrantc>
and was totally insecure
13:10
now it's slightly secure :)
13:10
<wwx>
yes, maybe
13:11
<Gadi>
personally, I dont like the fact that it isnt tunneled - something I intend to correct before hackfest Portland :)
13:12
<lns>
since we're all bullsh*tting here lemme ask a quick q (IANAP) - why the need for LDM ? Why isn't GDM suitable for ltsp, or at least working on GDM to make it more LTSP featureful ?
13:12* Gadi intends to bring LTSP into a unified client/server architecture kicking and screaming
13:12
<Gadi>
:)
13:12
<loather-work>
integrate it with NX
13:12
<Gadi>
pheh! NX
13:12
<vagrantc>
lns: GDM just doesn't have hooks to do anything it wasn't designed for.
13:12BGomes has quit IRC
13:13
<wwx>
yep, ldm was it called. i don't remember even name :-)
13:13
<vagrantc>
lns: there's been talk about adding the features to *DM, but for now we need something that works.
13:13
<lns>
vagrantc, gotcha
13:13
<loather-work>
GDM is really only useful for local machine logins. The fact it has XDMCP support at all seems like an afterthought.
13:13
<lns>
hopefully it'd be easy to port those features
13:14
<vagrantc>
lns: this is one of those classic cases where sometimes it's easy enough to just re-implement the wheel when you need some particular feature ... not ideal in the long run, but you need to figure out what you actually want before trying to nudge a larger project in your direction.
13:14
<lns>
loather-work, i disagree - I use VNC tunnelled over SSH for my clients, it seems plenty nice for remote - even gives you a little 'disconnect' option in the lower-left when you're remotely connected
13:14
vagrantc, that makes sense, as long as it's easy to port the work to the larger project when you're comfortable with it
13:16
loather-work, meaning gdm/vnc/ssh
13:16
<vagrantc>
lns: well, it's probably a huge task to add these features... so it's not really even a matter of portability. it's just going to be a lot of work.
13:17
<lns>
vagrantc, is it that the two projects are coded so differently that makes it a lot of work?
13:17
as in, non-modular, type thing?
13:18makghosh has quit IRC
13:18makghosh has joined #ltsp
13:19
<vagrantc>
lns: without having looked at the code for GDM, i would wager a guess to say that LDM is just a much smaller, simpler project. so i don't think there's anything specific about LDM that will make it hard to port the features to GDM ... it's just that it will be a lot of work to add those features to GDM weather LDM even ever existed. LDM is almost irrelevent at that point.
13:19
what LDM is useful for, is giving a playground to figure out what we actually want.
13:19
the code doesn't really matter.
13:20
well, it matters in that it works right now :)
13:21
<lns>
=)
13:21
I like it a lot, it 'just works' for me so.. =) was just curious
13:21
<loather-work>
i rather like the idea of LDM
13:22
<lns>
just the couple little things that i'm pretty sure are fixed now, like the whole 3-password-attempt thing
13:22
<wwx>
wondering how ldm looks from end user side view
13:22
<loather-work>
the python one was slow and overall pretty miserable, but from what i hear the C one is much, much better
13:22
<vagrantc>
now it just fails if the first password is wrong.
13:22
<lns>
vagrantc, awesome
13:22
<vagrantc>
wwx: many users don't even know it's not GDM ...
13:23
<lns>
vagrantc, most users don't know what a 'display manager' even is ;)
13:23
<loather-work>
my users don't even know what GDM is, and truthfully don't even care.
13:23
<lns>
but yeah
13:23
<wwx>
i used kdm since
13:23
<loather-work>
all they care about is if it gets them from point A to point B, which it does (well, I might add)
13:24
<Q-FUNK>
I use s&m instead
13:24
<lns>
Q-FUNK, is that a new package for Hardy? =p
13:24
<Q-FUNK>
oh, a very hard package indeed
13:25
<lns>
gross
13:25
=p
13:25
<wwx>
ldm based on python?
13:26
<loather-work>
the old one was
13:26
it's C now.
13:38makghosh is now known as makghosh|afk
13:49
<johnny>
so, what will it take to get my changes merged into upstream ?
13:50
gentoo changes that is
13:50
it's not 100% done, but it's close enough for a dedicated tester to work with now
13:51weiss__ has quit IRC
13:51
<johnny>
my time is going to bit a bit lesser in the coming weeks
13:51
as i'm trying to find a job
13:51
that is more regular than this contracting i'm doing
13:58staffencasa_ has joined #ltsp
14:01
<vagrantc>
johnny: publish bzr branches somewhere and ask for them to be merged
14:02
johnny: dberkholz should be able to merge them if you'd rather have internal peer review, and dberkholz might also be able to give you commit access.
14:02mikkel has quit IRC
14:15staffencasa has quit IRC
14:18slidesinger has joined #ltsp
14:23mhterres has quit IRC
14:23mhterres has joined #ltsp
14:32
<laga>
ogra: for example, i'd like to write a proper /etc/resolv.conf.
14:32
it's very easy to do that inside the initramfs because i can still access the ipconfig output
14:32
<ogra>
thats tricky since there are so many apps mucking about with it
14:32
you have the ipconfig data later as well
14:33
<laga>
ogra: hardy has a new "resolvconf" tool, i think
14:33
<ogra>
no
14:33
hardy uses NM
14:33
<laga>
ogra: yes, but i also need to know which device is the correct one.
14:33
<ogra>
it knows that from hal
14:33
<laga>
ogra: we're not gonna use NM on a diskless client i hope?!
14:34
<ogra>
not on a thin cliet, no
14:34
<laga>
good :)
14:34
<ogra>
but with a full desktop installed you might
14:34
<laga>
ogra: there is a utility called "resolvconf" which will manage /etc/resolv.conf
14:34
<ogra>
and there are plenty of attempts going on for fat clients atm
14:34
laga, and i wont add any universe stuff
14:35
at least not as a default dep
14:35
<laga>
resolvconf is in universe?
14:35
let's see
14:35
<ogra>
resolvconf is the suck
14:35
<laga>
i assumed it was some kind of default. it's so braindead i had to disable it
14:35aragua has joined #ltsp
14:35
<laga>
agreed, but it showed up on my kubuntu box
14:35Pascal_1 has joined #ltsp
14:35
<ogra>
its in universe since 2 years or so
14:35toscalix has joined #ltsp
14:35
<laga>
ok. then i'll be quiet.
14:36
ogra: re fat clients: is there any point in having NM there?
14:36
<ogra>
not sure
14:36
<laga>
i've disabled NM on mythbuntu clients
14:36
<ogra>
i would do that too
14:36
<johnny>
next networkmanager will be configurable at the system level
14:36
should be pretty awesome
14:36
<ogra>
but if someone has i.e. a wired and wlan card he migh want it
14:37
johnny, its pretty cool we had a 0.7 version in ubuntu for a while
14:37
<laga>
ogra: i guess you can build a hal rule during initramfs which will ignore the network device used to bring up the system
14:37
<ogra>
yeah
14:37
<johnny>
it's still being worked on..
14:38
<ogra>
right, thats why we ship 0.6 in ubuntu
14:38
<laga>
ogra: should be very easy to do. but again, it's in initramfs and you probably dont like it :)
14:38
<ogra>
sadly
14:38aragua has quit IRC
14:38hersonl1 has joined #ltsp
14:38
<ogra>
laga, whats the prob letting the usual etc/init.d/networking stuff care ?
14:38hersonl1 has quit IRC
14:39
<laga>
ogra: what do you mean?
14:39
<ogra>
make sure it uses dhclient and let it do its stuff on its own instead of hardcoding a file from initramfs
14:40
<laga>
ah.
14:40
<ogra>
i.e. properly integrate instead of "hack around the prob"
14:40
<laga>
ogra: i'm assuming we do not ever want anything to touch the device used to bring up the system (let's say 'eth0').
14:41Q-FUNK has quit IRC
14:41
<laga>
do you suggest to add an entry to /etc/network/interfaces for eth0 to prevent NM from touching it?
14:41
<ogra>
something like that
14:42
<laga>
sounds sensible.
14:42
i wish there was support for a conf.d dir for interfaces
14:43
conf.d >> silly sed/grep magic.
14:43
<ogra>
there is if-up.d and if-down.d
14:43
<laga>
ogra: yes, but you can't define interfaces in there directories
14:43
<vagrantc>
laga: netconf will happen... someday
14:43
<ogra>
vagrantc, i doubt ubuntu will see that (probably on -server though)
14:44
by te time that will happen, we will be 100% NM
14:44
<vagrantc>
ogra: well, you'll see it ... it'll just probably hang out in universe
14:44
ogra: is there a NM console/text interface ?
14:44
<ogra>
and i case N works on a system level it will be another hal rule to do what you want in the end
14:45
*NM
14:45
<laga>
ogra: what about my code to use different file systems for the copy-up branch in unionfs? the default is still tmpfs
14:45
<ogra>
vagrantc, CK yes, NM not yet
14:45
<johnny>
vagrantc, there will be :)
14:45
<ogra>
laga, patches accepted :)
14:45
<johnny>
as .7 becomes finalized
14:45
<ogra>
laga, take a deep look at casper for that
14:46
it has all such special caes covered
14:47
<laga>
ogra: i need to move out some functionality out first. i guess they don't support wake on lan or $HOSTNAMEOVERRIDE ;)
14:47jammcq has joined #ltsp
14:47* vagrantc waves to jammcq
14:47
<jammcq>
boa tarde all
14:47
<ogra>
hey jammcq
14:47
<laga>
hey jammcq
14:47
<jammcq>
hey guys
14:48
ogra: hey, next year, FISL-10.0 will be in June, instead of April, so you won't have the release schedule conflict
14:48
<Bengoa>
boa tarde :-D
14:48hersonls has quit IRC
14:48
<ogra>
jammcq, yay
14:48
<jammcq>
so we should have a hackfest, brazilian style
14:48
<ogra>
jammcq, i bet i would have been allowed to go if i wanted even this time ... but i had to much on my plate
14:48
<jammcq>
there's talk of wanting a LTSP workshop also
14:48
<vagrantc>
jammcq: like, while doing capoera?
14:48
<ogra>
edubuntu keeps me less busy now
14:48sepski has joined #ltsp
14:48
<laga>
ogra: i'll get myself an upstream checkout and play a bit with it
14:49
<ogra>
laga, great :)
14:49
<jammcq>
capoera ?
14:49
<ogra>
vagrantc, rather caipirinha
14:49
<vagrantc>
jammcq: that dance/martial art
14:49
jammcq: very brazillian
14:49
<jammcq>
hmm, cool.
14:49
<ogra>
and then churrasca
14:49
<laga>
i think i remember that from tekken. ;)
14:49
<jammcq>
Bengoa: is that what they do at ctg-35 ?
14:49* vagrantc would hold out on the currasca
14:50
<ogra>
all good brazilian things start wizh c
14:50Pascal_1 has quit IRC
14:50
<ogra>
vagrantc, soy churrasca for you then :)
14:50
<Bengoa>
no, what they does at ctg-35 is a gaucho dancing
14:50
<jammcq>
ah
14:51
<vagrantc>
yeah, that's a good deal different :)
14:51
<Bengoa>
capoeira is baiano things
14:52
<vagrantc>
and then there's brazillian jiu-jutsu...
14:52
i've gotta go back to brazil someday.
14:52
<jammcq>
vagrantc: june, 2009
14:52
<Bengoa>
yes, fisl10
14:52
or fislX
14:52
<ogra>
finally a good date
14:52
<jammcq>
fisl-dec
14:52
<Bengoa>
oh, a new variant
14:53
<ogra>
i bet i can get some more ubuntu people to attent on such a date
14:54
wow, #ubuntu-release-party nearly hits the 200 ppl mark already
14:54
<jammcq>
ogra: is tomorrow the day?
14:55
<ogra>
yup
14:55
<jammcq>
awesome
14:55
<ogra>
looks all good so far
15:04Pascal_1 has joined #ltsp
15:07elisboa has quit IRC
15:10Pascal_1 has quit IRC
15:11Q-FUNK has joined #ltsp
15:14gonzaloaf_work has joined #ltsp
15:15gonzaloaf_work has joined #ltsp
15:26indradg has joined #ltsp
15:29
<johnny>
dberkholz, my script is broken now
15:29
coreutils & mktemp
15:29
so.. while we wait for a new beta to roll
15:30
can you think about merging my codez?
15:30
<dberkholz>
johnny: sure. i've just been waiting on you to tell me stuff is ready for me to test
15:30
johnny: should your repo work for me now?
15:31
<johnny>
i just said it won't work :)
15:31
cuz of coreutils/mkstemp
15:32TelnetManta has quit IRC
15:37Egyptian[Home] has quit IRC
15:44toscalix has quit IRC
15:46vagrantc has quit IRC
15:56Guaraldo has left #ltsp
15:56Arauto has quit IRC
16:01mhterres has quit IRC
16:08Guaraldo has joined #ltsp
16:24K_O-Gnom has quit IRC
16:26Skarmeth has quit IRC
16:36cliebow has joined #ltsp
16:41Bengoa has quit IRC
16:49johnny_ has joined #ltsp
16:50sepski has quit IRC
16:50Guaraldo has left #ltsp
16:55
<cliebow>
8.04 tomorrow?
16:56
<ogra>
looks like
16:57
<laga>
ogra: ltsp-build-client --copy-sourceslist - is that going to use the sources.list for debootstrap?
16:57
<ogra>
no, afterwards
16:57
at apt configuring stage
16:57
<laga>
ah.
16:58
<ogra>
debootstrap doesnt use a sources.lis at all iirc
16:58
*sources.list
16:58
<laga>
yup
16:58
<ogra>
and doesnt create one either
17:05
<laga>
ogra: is it possible to use a ubuntu alt disk to generate the squashfs after install? i assume you need to bind mount /cdrom inside the chroot
17:08slidesinger has quit IRC
17:11
<ogra>
the suqshfs is generated from an installed system
17:11
<laga>
ogra: sure. but can you use the debs to create the chroot?
17:11
<ogra>
indeed
17:12
sudo mount /cdrom && sdo ltsp-build-client --mirror file:///cdrom
17:12
s/sdo/sudo/
17:12
<laga>
and that'll also show up in /opt/ltsp/i386/etc/apt/sources.list?
17:15
i guess i have to bind mount /cdrom to /opt/ltsp/i386/cdrom
17:17
<ogra>
if yu use --copy-sourceslist it wont
17:17
no, you dont have to bind mount anything
17:19elisboa has joined #ltsp
17:20
<laga>
oh.
17:20
i'm in love then
17:50Gadi has left #ltsp
18:00johnny_ has quit IRC
18:15otavio has quit IRC
18:18otavio has joined #ltsp
18:26BGomes has joined #ltsp
18:27Q-FUNK has quit IRC
18:28BGomes has quit IRC
18:28BGomes_ has joined #ltsp
18:29makghosh|afk has quit IRC
18:31BGomes has joined #ltsp
18:31BGomes has quit IRC
18:32makghosh|afk has joined #ltsp
18:35BGomes has joined #ltsp
18:40elisboa has quit IRC
18:42TelnetManta has joined #ltsp
18:50staffencasa_ has quit IRC
18:59petre has joined #ltsp
19:04elisboa has joined #ltsp
19:19PMantis has joined #ltsp
19:19
<PMantis>
Hi guys
19:39vagrantc has joined #ltsp
19:41BGomes has quit IRC
19:43jammcq has quit IRC
19:43rrittenhouse has joined #ltsp
19:44cpunches has quit IRC
19:45
<rrittenhouse>
Is there any way when using the rom-o-matic images to specify a specific dhcp server so the clients can boot from it. The problem is, is that we have two dhcp servers on the same segment (one for ltsp and the main windows dhcp)
19:49
<shogunx>
hey guys... what the deal with the squashfs image built by gutsy's ltsp-build-client? is that the filesystem the term gets?
20:13lns has quit IRC
20:14elisboa has quit IRC
20:19cliebow has quit IRC
20:34otavio has quit IRC
20:51makghosh|afk has quit IRC
21:03rrittenhouse has quit IRC
21:09
<warren>
yuck
21:09
hmm
21:09
vagrantc: If you use mkelfimage you MUST embed your BOOTPROMPT_OPTS within the image, it can't be given by the server like PXE?
21:10
This seems like terrible lose.
21:11
If this is so, then I can't rely on the "tools never edit the boot options"
21:11
or..
21:11
decouple non-PXE from PXE options
21:11
which is confusing
21:19
<vagrantc>
warren: you *might* be able to supply some of those options through dhcp
21:20
warren: but overall, yes. the options need to be specified in BOOTPROMPT_OPTS
21:20
warren: that's why i do it all client-side rather than server-side.
21:23
<warren>
vagrantc: what cases are impossible if you do it all server-side instead of client side?
21:23
<vagrantc>
warren: makes cross-architecture very difficult.
21:24
which, i guess isn't a huge issue
21:24
<warren>
more difficult yes
21:24
but we can solve individiual issues there
21:25
cross-compiled binaries
21:25
or binaries that can put payload of another arch in the wrapper
21:25
<vagrantc>
warren: the server has to know about how the particular version of softwares in the client chroot, rather than the client-chroot maintaining itself.
21:25
<warren>
ok, a bit exhausted now
21:26
you have time to talk in depth about this tomorrow?
21:26
<vagrantc>
i wish i could articulate better why i feel client-side is better... it *feels* like it has some positive advantages.
21:27
i should have time here and there during the day ... probably busy in the evenings.
21:28elisboa has joined #ltsp
21:32mccann_ has joined #ltsp
21:38BGomes has joined #ltsp
21:39mccann has quit IRC
21:40
<BGomes>
.
21:58petre has quit IRC
22:12spectra has quit IRC
22:23alekibango has quit IRC
22:43cpunches has joined #ltsp
23:24cpunches has quit IRC
23:27indradg has quit IRC
23:29mccann_ has quit IRC