[00:00] which is the case with ltsp-client-setup [00:00] ok, but you still gotta do the work [00:00] that's the problem [00:00] Lns: well for LTSP, we didn't do it for Intrepid either so ... :) [00:01] when you gotta support 3-4 releases while also trying to get a new release out [00:01] it can get really hard to prioritize [00:01] LaserJock: Yeah, it sounds a bit crazy, doesn't it? [00:01] Lns: it's clearly a manpower issue, I did some good job for Jaunty (I believe) but I could still use some people doing the SRU work because I just don't have a minute for that :) [00:02] stgraber: Here's the million dollar question [00:02] What can a non-programmer do to help LTS releases become more stable? [00:02] report and test [00:02] besides filing SRU requests and twiddling his thumbs? [00:02] right, teast early [00:02] LaserJock: I do both... [00:02] *before* release [00:03] report bugs and test fixes. I can easily find people to do these two but I need someone to actually do the fix :) [00:03] Lns: awesome [00:03] ogra: +1 [00:03] heck yeah [00:03] that's we've *never* gotten people to do much [00:03] how can one test a pre-release without a complete test environment with the same users, etc? [00:03] for now, I'm mainly focusing on providing a stable LTSP in the next release so hopefully we won't need SRU for Jaunty :) [00:04] stgraber: I fear you are too optimistic for your own good ;) [00:04] Lns: I have a backport of current LTSP in my PPA [00:04] Lns: so you can run it on Intrepid (sorry, no Hardy :)) [00:04] not downplaying anything you do whatsoever.. it just never works that way (for me anyway) :) [00:04] and have some people using it and reporting bugs [00:04] well, i personally think that ltsp5 is nearly in the state of going into maintenance mode ... which means devs can focus on polish and cleanup, all features are there [00:05] ogra: but with the underlying software constantly changing...there will always be issues that come up [00:05] within the next one or two releases you should only have to adjust to distro specific changes that show up in a new release [00:05] by underlying i mean OS [00:05] right [00:05] but the past of ltsp was always focused on feature development [00:06] the rest was held together by duct tape [00:06] there's a whole lotta duct tape around here ;-) [00:06] nobody had the time to look at replacing the interim solutions with better ones [00:06] running Jaunty's LTSP in production helped a lot for the bugfix part :) [00:06] now ltsp itself is at the feature completeness state [00:07] ogra: !!! you can't say that, i have so many ideas! =) [00:07] so the interim solutions can actually be improved [00:07] Lns, send patches then :) [00:07] *before* release :P [00:07] ogra: =p~ [00:07] hmm, my LTSP todolist is quite small actually but that's the by-Thursday one so ... :) (feature freeze) [00:07] shellscripts arent *that* hard [00:08] that's the thing, we gotta do stuff *before* release [00:08] Lns: by thursday actually if that's a new feature :) [00:08] well i don't see any feasable way to test pre-release releases in the same environment that needs to be stable 24x7... [00:08] and i know, stable != lts [00:09] but to me, it is because the app software/etc doesn't change [00:09] Lns: that's precisely why we have problems [00:09] we need to figure out how to test this stuff [00:09] LaserJock: I hate to say it but it seems to me that the release priorities are just ...off. [00:10] ?? [00:10] Lns: how so? [00:10] well [00:10] Lns: why not ask the launchpad developers? they run edge and staging alongside the stable production. [00:10] just look at my example...i run LTS because I can't handle daily updates, updates breaking apps/functionality, etc [00:11] all three (edgy, staging, stable production) access the same db [00:11] I run it because it's been run over with a fine toothed comb by hundreds of people over a longer period of time [00:11] s/edgy/edge/ [00:11] Lns: Hardy was getting much more updates than Intrepid [00:12] I've done the non-LTS route before. I can't go that route again because i just trade old bugs for new ones. [00:12] sure [00:12] it's a catch 22. [00:12] yep [00:12] well, it also had the hint o not pgrade production systems before 8.04.1 [00:12] *to [00:12] that's why you gotta make sure to test before implementing [00:12] ogra: and i don't try to do that either, at least for the next one. Hardy was the first LTS i stood tall on. [00:12] I don't run regular Intrepid (-updates + -security) but running it with -proposed I only get one or two update a week in average and it's probably a lot less if you don't have -proposed [00:12] *especially* because theer was the hope to get bugs and testing from people running the actual 8.04 [00:13] since we dont get neough testing before release [00:13] it all boils down to comunity participation in QA during the development releases [00:13] only if you have that you can do quality releases [00:14] ubuntu turned definately from a participant distro into a consume distro over the releases ... and thats the prob here [00:14] not the release policy [00:14] *consumer [00:15] ogra: I agree...but the biggest roadblock for people in my situation is that I don't have the resources to have a fully featured test lab for this stuff, and i simply can't run my clients' servers on stuff for testing and reporting purposes. Students need to learn, and they need a system with as few bugs as possible to do this effectively. [00:16] it's not LTSP, or Ubuntu, it's just stability. [00:17] so the question is, how can we get pre-release testing going better [00:17] I wish I could, truly. /me looks at his Ubuntu hoodie he's wearing right now - but I have to run my business so my clients dont dump me. [00:17] LaserJock: good q [00:17] It's probably because I'm both upstream+packager but I tend to prefer my users running a recent version that I know I can fix and publish the fix than running an old "stable" version where the users will just get stuck with that annoying bug for weeks/months before it gets fixed [00:18] I have an answer, but canonical doesn't like it for some reason [00:18] which is strange, because it involves me giving them $$$ [00:18] and probably tons of others [00:19] you want to pay for a test lab? [00:19] I would be MORE than willing to pay for LTS support, if it promised quick SRUs (at least as quick as bugfixes in devel releases) and it wasn't on a per-server basis. More like a per-SRU basis.. [00:20] LaserJock: yeah, and pay two hundred kids to beat the crap out of it every day ;) [00:20] well, then rather pay fifty fultime devs and donate their worktime to the project ;) [00:20] instead of 200 kids [00:21] (you will run into less legal probs with that as well *g*) [00:21] I guess one fulltime would probably be enough for the SRU part :) [00:21] ogra: exactly. [00:21] I thought about registering just one site as my "supported" site so i could get affordable lts support, but i don't want to cheat. [00:21] I just want to pay canonical to fix bugs in hardy for me and my clients, no matter how many clients I have. [00:21] for the same price, since it's still just one bug. [00:22] Lns: well, it's not exactly easy [00:22] I understand [00:22] for instance, there isn't anybody currently to do so [00:22] but money helps, right? at least for the cherry picking, non-fun things. [00:23] and last time i heard, canonical wanted money. ;) [00:23] I don't know actually [00:23] Mark's got ~ $1bil. [00:23] I'm sure Canonical wants money, but I'm not sure that's the blocker [00:24] what could be then? Lots of coders want paying jobs [00:24] and paying jobs require them to do things that might not be so much fun, but they get a paycheck. [00:24] so.... [00:26] what better development cycle would it be to have the people at the top be true OSS programmers, who do things the way they do now, and then employ people to fix their mistakes when they don't have time to? [00:26] (payed by people like me, who get paid from companies/schools to deploy and service the networks the OSS runs on) [00:27] generally I think the paid people just keep things kinda going [00:27] community management, etc. [00:28] LaserJock: the currently paid people at canonical you mean? [00:28] I mean we don't have any paid people [00:29] so the things that paid people can do are largely management and gap-filling [00:30] LaserJock: why? Why can't canonical employ people for SRU work in LTS releases which they get paid big $$ for ? [00:30] who is dong the interviews ? [00:30] ogra: management? [00:30] am i thinking of canonical wrong? [00:31] the only competent people that can judge if soeone is qualified are the persons working 16h/day already [00:31] ogra: intriguing, and you're right [00:31] how bout a community-based hiring process [00:31] voting, karma, etc. [00:32] but we don't really have anybody [00:32] if your applicants come from the community that helps indeed [00:32] but if we're building community in the first place [00:32] ogra: exactly. [00:32] do we have anyone doing LTSP work and willing to do it fulltime that's currently unemployed ? :) [00:32] we can more or less solve the problem [00:32] but we're at a growth rate where the community starts to get drained [00:33] right, and that will always be the case [00:33] as it is with any company [00:33] or project [00:33] or anything in life really...you do what you can do until you can't, then you get others' help [00:33] where are these others ß [00:33] ? [00:33] and it gets bigger, and more people start using ubuntu, therefore more work is to be done for the people using it [00:34] right [00:34] thats what i meant by "consumer distro" [00:34] ogra: the "others" are people that want to be paid canonical employees [00:34] yeah, it really has changed [00:34] the amount of users largely outweights the amount of developers [00:34] and the amount of users still grows [00:34] hopefully that will always be the case :) [00:35] Lns, which others [00:35] we do want more users, right? [00:35] the amount of users grows but the number of devs isn't [00:35] send me some resumes for good ARM people [00:35] ogra: i can post a craigslist ad right now that would do the trick [00:35] and i'll have some extra time for ltsp [00:36] or monster.com, or careerbuilder.com....or whatever else [00:36] me currently does the work for three planned positions that are not filled [00:36] ogra: argh, still haven't found some goods embeded developers ? [00:36] and yes, we're doing plenty of interviews every week [00:36] "WANTED: Experienced open-source developer wanted for ARM architecture work on Ubuntu operating system." [00:36] stgraber, two more already, but still two to go [00:37] and Edubuntu still lacks somebody [00:37] which would make SRUs a lot easier, IMO [00:37] Lns, right and you get 100 rplies of which 90 are windows admins that had a 1 week linux training in their last NT4 admin job [00:38] ogra: grep the resumes. :) [00:38] wow, hail! [00:38] Lns: http://webapps.ubuntu.com/employment/ is usually well-known among people with Ubuntu experiences and looking for a job [00:39] Lns, grepping insnt enough ... you have to read them ... [00:39] any idea how much worktime you burn reading 100 resumes 5 ages each ? [00:39] *pages [00:39] its a painfully slow process to find the best guys [00:40] ogra: how about this: require very strict guidelines for the resume. Require ODF format. Require them to state which projects they've worked on, with code/patch examples, etc. [00:40] Less resumes, better quality. [00:40] well, you need to difne clearly the problem we're trying to solve [00:41] and you miss the one super talented guy who is just bad in writing resumes :P [00:41] we can talk Human Resources for a while [00:41] ogra: =p there's always a risk! [00:41] but I think that's a side issue [00:41] right, it is [00:41] the issue is SRUs and in general growing dev community [00:41] but hiring good people is a slow process thats what i wanted to point out :) [00:42] LaserJock: isn't it safe to say that SRUs are "less fun" to provide than simply fixing the dev code? [00:42] yeah [00:42] ok [00:42] more paperwork [00:42] but some people dig it [00:42] fixing the dev code is always easier [00:42] so, the current developers want to fix dev code, which means we have less devs for SRUs [00:42] the prob is that the probem isnt known while the code is dev code [00:43] Lns: I don't think it's an interest problem [00:43] so we're back to "test *before* release" [00:43] I can upload a new release of ltsp/ldm/ltspfs/italc/... in a few seconds but it takes weeks and paperwork for a SRU, which one do I choose ? :) [00:43] LaserJock: hrm [00:43] stgraber: hrrrmmm [00:43] * Lns churns [00:43] it's time-consuming work and it involved a fair amount of coordination [00:44] and we're supposed to fix things in dev releases first [00:44] right [00:44] what we need is more hands [00:44] but that's bad news for service companies like mine [00:44] it's bad news for everybody [00:46] we almost need a spin-off company that handles only SRUs for slower moving LTS releases [00:46] why? [00:46] because it could provide the resources necessary to handle SRUs? [00:46] LaserJock what we need is more hands [00:46] right [00:47] we need more hands, period [00:47] rihgt [00:47] you're not likely to hire people just to do SRUs [00:47] but we need more hands for SRUs specifically in this conversation [00:47] why not? [00:47] I would [00:47] because it's not exactly exciting work [00:47] neither is janitorial services [00:47] but people need to survive, and you need money to survive [00:48] (unfortunately) [00:48] no, but you don't have the janitor teaching your important classes [00:48] sure, but they keep the bathrooms clean, so people don't get sick [00:48] just as important [00:48] SRUs are one of the most difficult dev tasks [00:48] unfortunately the same people will get an interresting job from someone else then (involving development, not SRU ...) [00:48] blargh [00:48] you need developers for SRU and developers don't like doing SRUs because they like to actually develop the software :) [00:49] bottom line though, we need more people [00:49] you guys are too pessimistic for me :) [00:49] nah ;-) [00:49] hehe [00:49] I just think we need to think a bit simpler here [00:49] we need hands [00:49] stgraber: developers will do what they don't like because they get paid. They won't get paid for fun dev work, because that doesn't pay. [00:49] that will fix a lot of things [00:50] Lns: well, I'm being paid for fun dev work :) [00:50] stgraber: good for you, you're a lucky one apparently :) [00:50] as long as the community is still the focus, and the community is what decides on important issues (stability of SRUs, fixes, everything), i don't see what would be a downfall of employing SRU specific coders. [00:51] there's a business model that screams out for this already, i'm just one small company that would make use of it. [00:51] you need *people* [00:51] SRU will take care of itself [00:52] you want the people who put the code in the dev release to put it in -updates [00:52] LaserJock: why? [00:52] why not have those people focus on -dev work, and employ people to fix bugs, and simply look over them to make sure they're good? [00:52] because the person who changes the code initially is the best to propogate them [00:53] we're still keeping the power with the people who need it. [00:53] LaserJock: that's a mindset that keeps any project from truly evolving. [00:53] no offense at all intended of course. [00:53] heh [00:53] non taken [00:53] but I've been at this a little while [00:53] case in point though: my dad was an appliance repairman. [00:54] he didn't want to trust any of his business to anyone, because he was the mastermind. [00:54] so he never hired anyone. [00:54] you have multiple people touching the same code you easily end up with things falling through the cracks and long delays [00:54] He did the books, the labor, the relations. [00:54] And he was so burnt out that things started slipping through the cracks, and nothing was 'ideal'. [00:54] sure [00:55] but I think that's a good case for teamwork [00:55] sure [00:55] not necessarily multiple people touching the same code [00:55] what's the diff? [00:55] because, for a given change, the same person should drive that change [00:55] however multiple people can be working in parallel [00:56] so what's with "give me a patch and I'll implement it" speak of so many OSS project maintainers? [00:56] that's what I'm talking about [00:56] but I'm saying "implement" = "implement wherever it needs to go" [00:57] I'm looking at a bug fix as a discrete object [00:57] if you fix it somewhere, fix it *everywhere* [00:57] sure, of course. [00:57] it's portable, more dynamic and easily modified. [00:58] so how about the devs fixing the bugs in -devel, passing the patches to the SRU people and say "make it work in LTS." After that, review the SRU patches and give it the go ahead. [00:58] the devs will always know what's going on, but the hard/crappy work is handed to someone else. [00:58] or ... have the dev people do SRUs where appropriate :-) [00:59] LaserJock: as you said, we don't have enough to do that. [00:59] and it's not as fun. [00:59] ok, but that's not gonna change [00:59] sure it can [00:59] as you get people you get SRUs [00:59] * Lns has to leave in a couple min [00:59] LaserJock: what's the harm in people that specialize in SRUs though? [01:00] there already are, right? [01:00] no [01:00] wouldn't that be a good thing(tm) ? [01:00] not in my opinion [01:00] they'd be experts in backporting/cherry picking. [01:01] backporting/cherry picking also means knowing the software you're working on [01:01] they're still managed by the devs..but they do the heavy lifting [01:01] otherwise you'll just break things [01:01] stgraber: ^^^ [01:01] yep [01:01] its just enlistment of extra help. [01:01] then let's enlist help *period* [01:02] that will fix more than just the SRU issue [01:02] LaserJock: remember, dev work is more fun than SRU work. they'll always go away to do something more fun for free. [01:02] no [01:02] that's not right [01:02] people will do what needs to get done [01:02] how so? those are your words :) [01:03] SRUs aren't fun, but that doesn't mean people don't do them [01:03] LaserJock: right, but "needs" is relative to who you're talking to. [01:03] that's why you have management [01:03] I "need" SRUs for hardy. but you "need" to fix devel bugs first. [01:03] no [01:04] I'm looking at all needs trying to get things done as best we can with the resources we can [01:05] LaserJock: if we don't think our resources will expand, we'll never get anywhere [01:05] we have to focus on getting more people involved [01:05] I think they will [01:05] right [01:05] ok [01:05] I totally agree we need to get more people involved [01:05] I just think focusing on SRUs is the wrong way to get more [01:05] because it's sucky work [01:05] i know :) [01:06] but look at it from my perspective [01:06] I need that sucky work to get done [01:06] sure [01:06] like...way faster than -devel patches [01:06] so does Edubuntu [01:06] right [01:06] so we need people involved that will do the SRUs [01:06] and i know what you said [01:07] right [01:07] you're representing a particular need [01:07] maybe it's an issue with what someone considers their "job title" or equiv for this [01:07] one I'm painfully aware of [01:08] we have to have some people focus on certain tasks, with oversight from the collective [01:08] otherwise everyone is doing everything, and it's not productive [01:08] the problem is, we don't even have people on the dev release [01:08] too many cooks in the kitchen [01:08] it's stgraber and myself [01:08] stgraber doesn't have time for SRUs really [01:08] i don't doubt that one bit [01:08] and I don't have much [01:08] I'm astonished at the things you all get done currently, it's amazing [01:09] i could never handle something like that [01:09] so if we could get more people that would either 1) find some SRU types or 2) free stgraber and myself to do SRUs [01:10] either way, more people helps solve the problem [01:10] sbalneav was wanting to give a hand at that but he's likely even more busy than I'm :) [01:10] LaserJock: IMHO we need specific focus and direction for us all [01:11] well [01:11] obviously everyone has a preference on what they'd like to work on [01:11] so let the experts do the expert work in their field, whether it's development, security, SRUs, etc. [01:11] exactly [01:11] but we don't *have* any experts :-) [01:12] again, $$$ helps prime :) [01:12] not sure [01:12] maybe we won't need $$$ later on if the community grows organically [01:12] but i bet it would help grow the community initially anyway [01:12] maybe canonical is just an interim company that helps evolve ubuntu [01:13] it's just gonna take quite a bit to get something like that going [01:13] i dunno, maybe i'll think about subcontracting/hiring some people interested in doing what i need done specifically [01:13] when i have the resources myself...given i am a 2 man company [01:14] LaserJock: you gotta start somewhere [01:14] anyway, i need to go home :) [01:15] thank you all for the input.. my gears are turning, and i hope to contribute more to the big picture soon [01:15] that will benefit us all [01:16] cheers! [01:18] LaserJock: btw, I remember you poking me last week asking me when I'd have time to talk ? Do you still have something to discuss ? :) [01:19] stgraber: just seeing what's up with LTSP [01:20] I'm currently doing some testing trying to get rid of ipconfig and using a real dhcp client instead (udhcpc) but that'll need a MIR and may be a bit hard to get before FF ... [01:20] though the initramfs scripts will run fine even if udhcpc isn't installed, using it only if installed in the chroot. So it'd rock if I can get it in for Jaunty but won't be a big issue if I can't. [01:21] other than that, it's mainly improving ltsp-cluster, bug fixing and preparing a few new upstream to be uploaded before FF [01:21] I actually almost finished the first deployment of Intrepid-based ltsp-cluster using Jaunty's LTSP, so far no problem so Jaunty's LTSP is as far as I'm concerned production ready :) [03:12] hi, all [03:12] hi nothingman [03:14] what's new? [03:46] nothingman: not much [03:55] I've been trying to set up a vbox pxe client to test with on the fly [03:55] it hangs on tftp though [15:53] I'm trying to figure out how to change education programs to work in Spanish. Any hints? [16:25] morgs: ping [17:16] anybody around? [17:16] I need some naming help [17:27] hi all [17:27] hi jelkner [17:28] i noticed some postings on the mailing list awhile back, and was wondering if this is the place to come to talk about getting scratch working on ubuntu [17:28] LaserJock: hi man! [17:29] scratch is truly one of the coolest pieces of educational software i've ever seen [17:29] this is the second year i have experimented with it with my students [17:29] cool [17:30] it is a constructivists dream tool [17:30] students don't want to stop using it [17:30] (even when class is supposed to be over!) [17:30] well, basically we need to do 2 things. 1) get Squeak updated/maintained and 2) package scratch up [17:31] there is already some effort on the scratch side [17:32] if edubuntu-devel was part of the discussion of that effort then it may help [17:33] i hope so [17:33] i just wanted to lend my voice to the chorus singing about how important this is [17:33] sure, yeah [17:33] we'd love to see scratch get in [17:34] and we'd love it even more if we could get it in a free component (Universe/Main) [17:34] from what i understand there has been progress in that direction [17:35] http://info.scratch.mit.edu/Linux_installer [17:35] i'm running scratch now from the debian/ubuntu package on the scratch site [17:35] the problem is we don't have a free Squeak [17:36] the problem is with multimedia things [17:36] sounds don't work [17:36] nor does image morphing [17:39] LaserJock: do you know any other folks on our end following up on this? [17:40] is there any way i could help? [17:40] i'm not in a position to contribute to the code [17:40] we have too many other python based projects going on [17:40] jelkner: well, finding somebody in the squeak/scratch community who would like to at least help maintain it would be awesome [17:41] I can help guide and sponsor work [17:41] but I can't maintain the whole thing myself [17:41] did you see the link? [17:41] they seem to be doing that already [17:41] i just wanted to make sure all the right communication is taking place [17:41] jelkner: but not *in* ubuntu [17:41] exactly, and it's not [17:42] so what would the process be to help fix that? [17:42] I need to have people email edubuntu-devel [17:42] I currently can't be on everybodies mailing list pushing them along :-) [17:42] so i should start with that? [17:42] of course [17:43] i'll email edubuntu-devel and let them know how important i think this is [17:43] if you could encourage people who are interested in Squeak/Scratch in Ubuntu to start some conversations on edubuntu-devel I'd be glad to do what I can to help that along [17:43] the issue is less knowing that it's important [17:43] but rather getting people who know what they're doing plugged into the process [17:43] ahh [17:44] i don't know how to do that [17:44] i could send the email if you think it would help [17:44] jelkner: if you can find the people in Scratch doing the Debian/Ubuntu installer and see if they'd talk to edubuntu-devel [17:44] I think that'd be a significant help [17:44] ok, i'll approach it from that direction then [17:44] so far I've gotten quite a few people who want to see it in [17:44] thanks [17:45] I just haven't heard from anybody actually wanting to take on the work [17:45] typical story unfortunately :-( [17:45] yep [17:45] especially with things like this [17:45] we are just educators who know how great a tool it is [17:45] but if we can plug in a Squeak/Scratch dev into the Ubuntu dev community then it'd be a big wiin [17:45] but we don't have the where with all to do the work on it [17:46] so i'll look into that [17:46] thanks again [17:46] awesome [17:46] no, thank *you* [17:46] this is the sort of thing the educators can help with [17:46] got it [17:46] * jelkner goes off to poke around the Scratch community... [18:35] Lns: morning [18:35] LaserJock: morning! =) [18:57] LaserJock: so what are you exciting projects currently? [18:57] trying to stay afloat at the moment :-) [18:57] ok, so I talked with some people about abiword [18:58] and email got sent to the Debian maintainer about splitting out the lib, etc. [18:58] jelkner dropped by to ask about getting Scratch in Ubuntu, he's gonna talk with them to try to find some Squeak/Scratch maintainers [18:59] I really really need to finalize the name for the Universe app bundles though [18:59] what are the candidates? [19:00] I liked edubuntu-extras-* [19:00] but nubae didn't [19:00] we can do just edubuntu-* [19:00] edubuntu-*-universe [19:01] these are for "extra" packaged apps such as abiword? what's in there? [19:01] it's going to be relatively high-demand, useful edu apps that are in Universe [19:02] abiword wouldn't be one since it's in Main [19:02] right [19:02] childsplay perhaps [19:02] did you guys decide against simply edu-? [19:02] don't wanna open a can of worms at the moment, just curious :) [19:03] well, the Main ones are ubuntu-edu-* [19:05] argh phone [19:16] back [19:16] cool..i was for ubuntu-edu-* [19:16] :) [19:19] LaserJock: so what's wrong with ubuntu-edu-extras-*? [19:19] it's rather long [19:19] but consistent! =) [19:19] well, if I was going for consistency I'd got edubuntu-* ;-) [19:20] hmm... [19:20] * Lns has always been a fan of consistency [19:29] Lns: any suggestions? [19:31] LaserJock: personally i don't see anything wrong with ubuntu-edu-extras-* [19:31] k [19:31] there's plenty of packages with longer names [19:31] edubuntu-edu-extras-preschool doesn't seem toolong? [19:31] and at least they'd be easy to group together and understand [19:32] nope [19:32] i think it's a very good description actually [19:32] and you can apt-cache search it very easily along with the other package names [19:32] oh wait [19:32] you mean ubuntu-edu-extras-preschool ? [19:32] not edubuntu-edu [19:33] (that's a bit redundant ;) ) [19:33] yes, sorry [19:33] muscle habit [19:33] then yeah [19:33] haha [19:33] $ apt-cache search ubuntu-edu [19:33] will bring up everything we would want :) [19:51] hello alkisg [19:52] Hey Lns, what's the good word? :) [19:52] (I learned that from you :P) [19:53] alkisg: =p [19:53] the good word is ...."ltsp". [19:53] And also "edu" [19:53] Heh... any java speedups? [19:54] alkisg: nope, but I just triaged the LP bug w/freedesktop bug [19:54] like...2 seconds ago [19:54] Erm.. this one? https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/277069 [19:54] Ubuntu bug 277069 in libxcb "Java slow on remote X" [Unknown,Confirmed] [19:55] yep [19:55] * Lns hopes he was supposed to do that [19:56] Sometimes I get messed up in what tasks to perform on a bug so people can collab better [19:56] Hmm... ok, on to the next bug: solving the firefox right-click delay :) [19:57] alkisg: haven't heard of that yet [19:57] url me ? [19:59] I don't know where I saw it (bug report or mailing list), but it's a known bug, and there was some talking recently about it [19:59] Let me check... [19:59] well there SHOULD be a bug report on it if it's known.... ;) [20:00] Here are some links: http://www.mail-archive.com/ltsp-discuss@lists.sourceforge.net/msg35841.html [20:00] https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9/+bug/305531 [20:00] Ubuntu bug 305531 in xulrunner-1.9 "Context menu and drop down list are slow to appear" [Medium,Triaged] [20:02] alkisg: interesting, i dont' have that issue at all [20:03] I'm on FF3.0.6 [20:03] Lns, ahm, I think it's an intrepid issue? [20:03] I don't remember having it in hardy... [20:03] ahh, ok [20:04] ii xulrunner-1.9 1.9.0.6+nobinonly-0ubuntu0.8.04.1 + ii xulrunner-1.9-gnome-support 1.9.0.6+nobinonly-0ubuntu0.8.04.1 [20:04] Lns, you're on hardy now? Try ssh -X and then firefox... [20:04] alkisg: yes [20:04] OK, ssh -Y localhost [20:04] from a tc? [20:04] Then run firefox, right click and see if it takes more than a second [20:04] No, from the server / your PC [20:04] It's not ltsp related [20:05] Or just run firefox from a TC [20:05] i'm on a thin client.. i can't do that :( i'd have to vnc into the server [20:05] oh [20:05] well i do that all the time [20:05] Ah, so no delay then [20:05] and i odn't have the issue..takes MAYBE 0.25sec to bring up a right-click context menu [20:06] and they say LTS doesn't mean more stable. ha! =p (just kidding just kidding) [20:06] well, I'd prefer localapps to stability any time :P [20:07] alkisg: how much ram do your tcs have to run localapps (and which apps) ? [20:07] i'm wondering if localapps will even work for me, most of my TCs in the field are like, 128mb or so [20:07] One lab has 64 Mb, the other 128 Mb... (yup, I was just kidding about the localapps... :D) [20:07] Well, I have htop as a local app :D [20:09] lol [20:09] well that's a good localapp! [20:10] * alkisg would like to be able to run a video player as a local app... :( [20:15] that would be nice...and tsclient, as that would reduce roundtrips for display on a windows termserver too (from ubuntu desktop) [20:18] why tsclient and not rdesktop? [20:19] alkisg: well either one [20:19] rdesktop is what tsclient uses [20:19] I have the feeling that rdesktop would be lighter [20:20] it is i think [20:21] damn it, how do you get a thread view on SF lists... [20:21] ah got it [20:23] hi, all [20:24] hey nothingman [21:39] any moodle users around? [21:44] yeah where's nubae been? [21:45] not sure [21:56] !seen nubae [21:56] I have no seen command [21:56] !last nubae [21:56] Sorry, I don't know anything about last nubae [21:56] bah [21:57] !help [21:57] Hi! I'm #edubuntu's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots [22:48] hi how can i make a usb boot stick in handy? [22:59] hello, what programs are offered to assit child in learning reading and spelling? === sa7a is now known as sara2-away