=== Varka_ is now known as Varka [04:49] @schedule now [06:14] doko: did you mean there is a current thread on dev@go-oo about modularization? [06:51] *yawn* [06:52] evening [06:53] hi [06:53] Greetings. [06:53] here [06:53] hi all [06:54] heya [06:55] howdy [06:55] guten Morgen [06:55] hiya :) [06:55] hello [06:57] hi [06:58] hi all [06:59] Good morning [07:01] Hi all; welcome to those of you visiting for 8.04.1 discussions [07:01] hardy is our rock! [07:02] As I mentioned by mail, the main thing I want to go through in this platform meeting is 8.04.1, though I have other odds and ends for afterwards [07:02] cjwatson, i just sent you another agenda item [07:03] good morning [07:03] Most of you will already know that we're assigning more resources than usual to the point release this time round, and this will consist of a virtual team of about ten people under the direction of slangasek [07:04] Steve was on well-deserved holiday yesterday after the 8.04 release, so I don't know if he's had a chance to catch up and figure out what's going on with stable yet :-) [07:04] ah, that was in fact one of my main pressing questions: slangasek is now officially part of the SRU team, so I can bother him to review my own SRU uploads? [07:05] From platform, so far, evand and about half of asac will be on the 8.04.1 team; I'm still sniffing around for one more [07:05] I've managed to process my mail with difficulty today - looks like there are one or two bugs to keep us busy for the point release [07:05] Heh, "half of asac" [07:05] from desktop, it's seb128 and me (so far) [07:05] no half people there ? [07:05] pitti: my understanding is that I'm to be officially part of the SRU team, but I'm not a member of the launchpad team yet [07:05] from the server team its me and half of kirkland [07:06] slangasek: I don't think the team comes with any extra power, it's just the bug mail I think [07:06] * cjwatson looks at https://launchpad.net/ubuntu/+milestone/ubuntu-8.04.1 - "144 bugs targeted" [07:06] hi [07:06] slangasek: but someone should add you indeed [07:06] slangasek: *clicketyclick* fixed [07:06] * calc will be putting out a new OOo, but probably not working on other stuff unless asked [07:06] cjwatson: thanks :) [07:07] Firefox 3's non-final state is one of the things I've seen in pretty much every 8.04 review so far, hence asac [07:07] (and we knew it was going to be that way, of course) [07:07] * slangasek nods [07:07] yeah, there are also massive threads about it on ubuntu-users [07:08] seems some people have problems running 2 and 3 in parallel [07:08] The target for package uploads being complete for 8.04.1 is about the first week of June, with the release itself then being early July, so plenty of time for testing and certification [07:08] ogra: nobody claimed that thats really supported ;) [07:08] Are there any major issues people would like to raise that they think ought to be hoovered up for 8.04.1? [07:09] asac, right and -users is a madhouse anyway [07:09] cjwatson: do you know whether we'll get any list of 'hardware that should work with .1' again? [07:09] cjwatson, sound support [07:09] It's not a major issue, but I need to mention the UME situation [07:09] I think all the major issues I would raise are conveniently already milestoned ;) [07:09] pulseaudio's stuttering is driving me crazy, but it might just be me [07:09] sound support is a big one that needs some attention [07:09] lool: that is on my list, I'll get to it in a moment [07:09] cjwatson: gvfs smb issues [07:09] perfect, thanks [07:10] pitti, since crimsun dropped the ball we're pretty much floating wrt sound [07:10] pitti: I'm not sure, I'll check [07:10] cjwatson: onn the server side we have a list of things we would like to see fixed or tweaked [07:10] the new kernel scheduler works for most cases, but in the cases where it doesn't it really doesn't - I think the kernel team already has that in 'fix committed' now [07:10] nobody is *really deep* into it atm [07:10] Crimsun and I are looking at putting pulseaudio through dmix at this point, and testing is giving different results for different people from what I can gather. [07:10] slangasek: Is that the commit in 2.6.25 by Ingo? [07:10] slangasek: cgroups? [07:11] TheMuso, do you know what redhat are doing wrt the pulse setup ? [07:11] zul: can you please let me know if there are any of those bugs which aren't a subset of the 8.04.1 milestoned set? [07:11] cjwatson: yes [07:11] lool: no [07:11] seb128: that's bug 207072? [07:11] slangasek: sure I can cross reference it [07:11] ogra: Using direct hardware access afaik. I plan on installing FC9 to have a closer look. [07:11] cool [07:11] one highly annoying thing is that gnome-screensaver doesn't accept your password after resuming; not sure if that's already milestoned [07:11] I need to fix my own brown paper bag regarding pam logging :P [07:12] pitti: hrm? I haven't seen this at all [07:12] Me neither [07:12] ogra: Not even sure what Fedora users do about flash and pulse, but I guess we won't really know till FC9 final is out. [07:12] pitti, i heard about keyboard issues after resume, that might be related [07:12] cjwatson: bug #209520 bug #223372 bug #207072 [07:12] I've been looking at doing some quirk and pci id updates for various X drivers, and I think we might have a few more fixes for xrandr gui from redhat and suse that could be worth pulling in [07:12] slangasek: hm, happens on both my boxes (freshly installed final), so I didn't think it was a local glitch [07:13] right, fixing the xrandr capplet would be nice too, because I'm not sure it works for lot of people right now [07:13] anyway, it's on my list to track this down [07:13] TheMuso, they go for libflashsupport [07:13] pitti: ok, please keep me informed; I would have expected a bug like that to have come to my attention by now if it were widespread, but even if it's not that sounds like a fairly important issue to try to pin down [07:14] ogra: Yeah so I guess ti comes down to how pulse/flashsupport behave for Fedora users. [07:14] slangasek: ok, I'll first get it filed, I think :) [07:14] TheMuso, but use nspluginwrapper all over the place, so it doesnt crash their browser [07:14] (people will just reload the page) [07:14] seb128: cloned (e.g. projector) should be fine for most people; dual-head layouts still needs work. Not sure we're going to get that 100% though, but could be polished better. [07:15] bryce: ok, I might just have no luck with my setup then [07:15] bryce: one of the reviews of hardy mentioned that the xrandr gui doesn't resize if you use it to scale the screen down to a size smaller than the window, making it difficult to make further changes; do you know if there's a bug about this? [07:15] I've asked TheMuso to be the third platform guy for .1, so hopefully he can spend some time smoothing out sound [07:15] yea i saw that for low resolution displays [07:15] bryce, what about single head layouts that detect a tv or external VGA ? seems the external is always on (whch forces a floating gdm of 1024x768 on a 1280x800 screen here for me) [07:16] slangasek: there is a bug yes, I've been commenting on yet yesterday, no obvious way to solve the "dialog don't fit on 800x600 issues" [07:16] seb128: well, there's a very large graphic that ought to be scalable downwards, in principle :) [07:16] slangasek: right, we actually did get it to fit in that resolution, but a button got added in at the last moment that bumped us up just enough. That was a pretty non-standard resolution (740x400 iirc) so I don't know if it's worth SRUing, but I talked about it with james. [07:16] so I make the .1 team as follows: slangasek, asac, evand, TheMuso, pitti, seb128, bdmurray, ogasawara__, pedro, kirkland, zul [07:16] I thought it was ok in 800x600, it was just x400 that didn't work. [07:16] bryce, i ave seen that on different machines now, switching the external output off via xrandr fixes it though [07:16] can we put #215755 on the .1 list, please? [07:17] I think we should re-test on 640x480 though. I *think* it should still fit ok, but if not maybe we should just shift where the button is located [07:17] When is Fedora 9 due? [07:18] james_w: might be, I use 800x600 as value we get bugs about app not fiting correctly on that usually [07:18] ArneGoetje: I've milestoned it speculatively, though it's outside the usual SRU criteria; I can see why it would be needed though [07:18] TheMuso, may 15th i think [07:18] TheMuso: iirc 13th may [07:18] cjwatson: thanks [07:18] ok ;) [07:18] or what asac says :) [07:18] 14 days apparently [07:18] whenever that is :) [07:18] Ok thanks. [07:18] ogra: the TV out interference bugs are usually easily quirkable; pass me bug ids and they should be easy to do that way [07:18] yea may 13 [07:18] lool mentioned mobile as an issue, and this was also on my list [07:18] bryce: ah, right, I can't see much reason to worry about resolutions below 640x480; but then, the GUI should therefore probably not /expose/ resolutions lower than that if it's going to break the GUI itself :) [07:19] the mobile team is going to be releasing their hardy-based product somewhat later than hardy itself; looking at late May at the moment, I understand [07:19] Yes [07:19] We need to provide security support on it, and it's currently based on hardy + ume ppa [07:19] bryce, will do ... i added "/usr/bin/xrandr --output TV --off" to a gdm Init file for now, works around it as well :) [07:19] slangasek: note that you have to confirm the choice, so people shooting themself in the foot are really asking for it there [07:19] and they have raised it as an issue that their process is very complicated at the moment, involving PPAs and other weirdness all over the show [07:20] I'd like the .1 team to consider whether parts of this can be incorporated in the updates for .1 [07:20] To be in the sweet spot of maintainability, we would be happy with having everything in hardy, but some of our changes remain ppa only at the moment [07:20] perhaps at least those packages currently in the ume ppa that are also important in the regular archive [07:20] apparently opensuse will have pulseaudio as well but isn't slated for release until mid june [07:20] I think there may be cases where a merge into the main archive just isn't appropriate yet [07:21] calc: Ok another one I need to check out, thanks., [07:21] That's true, it's certainly hard to reconcile the proposed changes with SRU requirements [07:21] The changes might be lpia specific [07:21] TheMuso: http://en.opensuse.org/Roadmap [07:21] Or might be in purely mobile packages [07:21] calc: ok thanks again. [07:22] right, I was about to say, if UME is still in the development run-up to a release, there are likely to be changes that don't really fit the SRU policy [07:22] I think these are not disruptive to the normal behavior of hardy, but they do not fit in the allowed updates scenarii [07:22] at the very least, it'd make sense to consider cases where packages are being updated anyway [07:22] if changes are lpia-specific, the major risk is from changing the package *at all*, not so much from the diff itself [07:22] and navigating the SRU requirements might be more of a hassle than using the PPA [07:22] IYSWIM [07:22] * slangasek nods [07:23] I was hoping that some easy changes would be mergeable as trivial mobile bug fixes, but it's going to be administrativa for sure [07:23] One issue with the SRU process is that it needs the reviewer to be able to test the package [07:24] lool: perhaps somebody could correlate the list of changes you have against the 8.04.1 milestone, and look for things that could slot in [07:24] But with UME, we don't have a completely virtual solution (yet) and the Xephyr solution is a pain to setup [07:24] is there wiki documentation on the setup? [07:24] at least then it could be done if need be ... [07:24] lool: but there should be at least one other person with that hw in the team? [07:24] me [07:25] Bryce, too [07:25] cjwatson: Ok; we didn't use the milestone too much yet; what needs to be done is to look one by one at the packages we carry in the ppa and see whether the changes can be merged into hardy [07:25] lool: traditionally, hw specific bugs are verified by the bug reporter/subscribers, and we collect a few of them [07:25] lool: the SRU process doesn't require the reviewer to be on the sru team or an archive admin, though? so presumably you'd have people within your own team who could do the validation [07:25] pitti: Yes [07:25] lool: right, I mean packages that are already going to be updated for .1 for other (non-mobile) reasons [07:26] Sure, we could do it within UME; I thought the sru team or archive admins had to be able to check, but UME testing is fine [07:26] TBH, that makes even more sense than ~sru-verification, since they just test a particular TEST CASE:, and not the entire package in production conditions) [07:26] cjwatson: Yup, I understood [07:26] ok, further .1 meetings [07:26] cjwatson: So should we check -proposed regularly to see whether a package is different in -updates and hardy? [07:27] it seems like it'll be valuable for the .1 team to occasionally sync up, but you're in the usual variety of timezones [07:27] one suggestion was to have shift meetings, so that at least there's some coordination even if it isn't whole-team [07:27] slangasek: but I'll leave you to carry this forward [07:28] lool: I think you guys may be too busy to poll; perhaps you can arrange some kind of notification system [07:28] Are -proposed uploads sent to some -changes list? [07:29] * ogra thinks it should be responsibility of the uploader to take care [07:29] (for notification that is) [07:29] I see them in hardy-changes I think [07:29] cjwatson: hmm, do we have any scheduling tools available internally to make this easier? :) [07:29] I guess I'll tell people to subscribe with a filter to that list so that they can see likely SRU candidates [07:29] ogra: the uploader won't necessarily know that the UME team cares about the package in question [07:30] lool, but they might have to sit in -proposed for weeks [07:30] lool: hardy-changes, yes [07:30] sladen, oh, right [07:30] lool: yes, they go to -changes normally [07:30] err s/sladen/slangasek, sorry [07:30] slangasek: not a lot, unfortunately; when I've done it I drew out a big list of timezones and people so that I could do it by eye [07:30] Ok [07:31] slangasek: I'd suggest you ask davidm too, since we have this issue with the mobile team [07:32] StevenK: thanks, I'll ask him [07:32] Where will the 8.04.1 sync meetings be announced? [07:32] I'll make sure they get on the fridge [07:33] Thanks [07:34] Just in case, it might be best to include me in the list of 8.04.1 people if that's the base for an email group or something [07:34] so on second thoughts, the other agenda item I had was just for one person, so I won't bore the whole team with it [07:34] any other business? [07:34] lool: I'm happy to do that to keep you in the loop [07:34] Thanks [07:34] thanks [07:35] cjwatson: thanks for the meeting! have a nice day [07:35] cool, g'night! [07:35] thanks [07:35] thanks [07:35] thanks everyone [07:35] Thanks folks. [07:35] thanks [07:36] thanks guys [07:36] thanks guys [07:36] thanks all [07:36] thanks (i.e., "no other business" :) [07:36] thanks [07:37] ok then, adjourned; thanks all, good luck with .1! === lamont` is now known as lamont === neversfelde|mobi is now known as kubuntu-deIRC === kubuntu-deIRC is now known as never|mobi === never|mobi is now known as neversfelde|mobi [17:13] @schedule rome [17:13] argh ubot.. === never|mobi is now known as neversfelde|mobi === guerby_ is now known as guerby === asac_ is now known as asac === Zic is now known as Zic[Pipi] === Zic[Pipi] is now known as Zic [19:57] hey heno [19:57] * ogasawara__ waves [19:58] hey all [19:58] hello! [19:58] hi === ogasawara__ is now known as ogasawara [19:59] hello [20:00] #startmeeting [20:00] meh, no bot [20:00] ok, agenda at https://wiki.ubuntu.com/QATeam/Meetings [20:01] TOPIC - Setting up virtual images of standard upstream software for upstream bug testing [20:01] I played a bit with this yesterday in vbox [20:02] basically installed Debian testing [20:02] anyone know how much debian changs Gnome and OOo? [20:02] they obviously rebrand firefox [20:03] I don't think they patch gnome a lot, you probably can take a quick look at their .diff.gz though [20:03] the idea here is to make it easy to teat whether a bug exists upstream [20:03] there's no a good way to determine that i think [20:03] that's why i prefer to use jhbuild of trunk instead [20:04] So: is offering Debian unstable images a good enough way to do this or should it be pure upstream? [20:05] latest head builds [20:05] if possible, latest gnome build definitely [20:05] I think pure upstream for OOo, firefox, and Gnome. Having a debian image would be good for a lot of bugs though. [20:06] yep it would be good for all the other software we have [20:06] I think if you asking general public to test in vm then debian unstable is probably a good call [20:06] firefox and OOo are fairly easy to install from upstream binaries I guess, what about Gnome? [20:06] ouch [20:06] heh [20:07] is a bit complicated but not a lot [20:07] and it will use a lot of space [20:07] @schedule [20:07] ok, so perhaps we can start with Debian unstable and see if we run into issues of it not being pure upstream enough [20:08] ~750 only of source code [20:08] ok [20:09] It would be great if someone could take this on, but we'll get to that on agenda item 3 [20:09] TOPIC - Creating a test-control team to lead various test efforts with similar privileges as bug-control [20:09] btw does debian have something like patches.ubuntu.com? [20:10] This would include people who can admin the test tracker, who generally edit test cases, etc. [20:11] perhaps also set priority of bugs [20:11] it would be a restricted team like bug-control [20:11] pedro_: don't know [20:12] there is the ubuntu->debian project, utnubu or something [20:12] ok will try to see what can i find out there, thanks [20:13] thoughts on test-control? do we need this? will it be useful? [20:13] heno: is there a list of initial members for the test-control team that don't already have the above mentioned privileges? [20:14] davmor2: are you in bug-control? [20:14] No bug-squad [20:14] there are the Xubuntu and Studio test people also [20:15] the test cases are just in the wiki though at the moment right? [20:15] it's also a way to encourage people to do ore structured testing [20:15] I think a defined group to manage these type of actions is a good idea. Especially as we grow. That being said, it would have to be managed so it did not become a bottleneck [20:15] Won't that require to have that test-control team as a member of bug-control ? [20:15] and learn more advanced techniques [20:15] like setting up re-flashable disk images [20:16] bdmurray: right, I'm not suggesting we limit access to editing them, just that it would be a typical task for team members [20:17] pedro_: no, they don't have patches.debian.org, but if they use a patch system patches.ubuntu.com can provide the individual patches in http://patches.ubuntu.com/by-release/extracted/debian/ which is probably quite useful for gnome [20:17] stgraber: for setting bug priority yes and I think the bug-control team requires some special knowledge that testers might not need [20:17] stgraber: why, to set importance? [20:17] heno: yep [20:17] james_w: great, thanks! [20:18] I think setting bug importance could wait a while [20:18] we can leave the right to set importance out, but it should be a restricted team [20:19] @schedule montreal [20:19] well, it has to be restricted, otherwise you are just describing our existing : "Ubuntu Testing Team" :) [20:19] (that's currently AFAIK not used at all) [20:19] the test tracker could get the info from LP in the future [20:19] stgraber: right :) [20:20] Sounds like we should define the purpose and scope a bit better before proceeding [20:20] indeed [20:20] I'll take it to the mailing list [20:21] TOPIC - Additional QA team roles [20:21] I think it is important for people to have a sense of motivation. You see now across the whole spectrum of teams. You get the base level team that anyone can join and then the elite who help the other and have more privileges [20:21] see https://wiki.ubuntu.com/QATeam/Roles for my proposal [20:21] I'm all for a restricted team showing that its members have been actively helping testing Ubuntu [20:22] the "Ubuntu Testing Team" was useless mainly because it was opened to everyone and didn't give any additional privilege. [20:23] davmor2: +1 [20:24] ok, so we are agreed on the principle, just need to settle the details :) [20:24] :) [20:24] sounds good :) [20:24] davmor2's point is really also the motivation for the QA roles [20:25] defining clear areas of responsibility that we ask people step up to [20:25] mmm we need a KDE/Kubuntu guy [20:25] * pedro_ will ask yuriy about that [20:25] heno: I think in the roles you missed asac for FF [20:25] that Roles page looks really good, will be useful to redirect people asking who to contact regarding a specific area of QA [20:26] Riddell [20:26] he tends to sit in on the testing channel anyway [20:26] When I heard role I was thinking bug forwarder, bug triager, etc... [20:26] I should link to the bug roles page - there is some overlap [20:26] Installer bug contact would also be a good thing [20:26] for debian-installer/ubiquity issues [20:27] bdmurray: should we use a different term? [20:27] Nothing great comes to mind other than "lead"? [20:27] i would love to give away the "mozilla bug role" to someone else who is more dedicated to bug work. [20:27] Well, that's not great [20:27] I'm sure asac would love someone *else* to step up as FF QA lead :) [20:27] \o/ [20:27] ... [20:28] i can provide the input and procedures, but doing the QA of my own stuff doesn't sound right [20:28] stgraber: that would be evand [20:28] davmor2: but as with asac he is the lead dev [20:28] the QA lead should be a different person [20:30] shall we decide on these one at a time and move them up to open positions/roles? [20:30] Well myself evand and xivulon (Agostino Russo) are all on pretty good terms, so I can probably take that on too. [20:31] davmor2: ok, just note that we are trying to involve new people with this, so don't take them all :) [20:31] So, in order: [20:32] Kernel bug first-response [20:32] ogasawara: please add whatever further role description is needed [20:32] sounds good to me :) I'll beef up the description more [20:32] the more detail about what it involves the better [20:33] * ogasawara nods [20:33] * Test VM maintainer [20:33] based on debian I think we decided [20:34] I can flesh that one out [20:34] what about some kind of Forum <-> QA team contact ? [20:35] what would they do? [20:36] sounds useful, but specifically [20:36] make sure people reporting bugs or test results on the forums are either redirected to the proper ressource (Launchpad) or at least forward the bug/result to the right developper or open a report himself [20:37] that sounds concrete enough [20:37] and could request testing in the forum when needed [20:37] yes, that too [20:38] stgraber: will you flesh out the description for that? [20:39] * Derivatives test coordinator (Xubuntu, Ubuntu Studio, etc.) [20:39] sure [20:39] perhaps we should hold off on the derivatives one as ISO testing season is now over [20:40] we can't post them all at once anyway [20:40] oh, about that, who's the project leader for Mythbuntu ? [20:40] And let's add FF and perhaps OOo [20:40] we don't have them on the tracker and I think it'd be a good idea to add them [20:40] asac: are getting Firefox 3.0 bugs upstream important now? and how time sensitive is it? [20:40] stgraber: superm1 [20:41] bdmurray: thanks, I'll ping him later [20:41] the installer can perhaps wait as it's out of season now :) [20:43] let's aim to have 2-3 of these posted before next week's meeting [20:43] any other topics today? [20:44] We can probably start with : test-vm, kernel bug and forum [20:44] those aren't linked to ISO testing [20:45] (not directly) [20:45] ok [20:45] 3 [20:46] 2 [20:46] 1 [20:46] #endmeeting [20:46] still no bot :) [20:46] Yeah, I'm still compelled to write that though :) [20:47] :) [20:47] yeah, 15min break before the next meeting :) [20:52] bdmurray: sorry. have to run. we can talk about that tomorrow (well tomorrow is publich holiday here, so maybe friday) [20:52] asac: okay, you know where to find me. [21:00] * ogra jumps at the stage [21:00] anyone here ? [21:01] hmm [21:01] yep [21:02] heh [21:02] so its you and me :) [21:02] Laserjock was in #ubuntu-devel 3 minutes ago [21:02] lets wait another 5 min or so [21:02] yeah, saw him, but he said he has another meeting as well [21:02] ah, right [21:04] so i''ll paste my list of proposed specs i would like to work on in intrepid, note that none of them are accepted or even put up on blueprints yet [21:04] colin has to nod off what i'm allowed to work on and we didnt have a meeting about it yet, so take that list with a grin of salt [21:05] it would be nice to have a set of community goals as well, IMO [21:05] * ogra repeats for the recently joined [21:05] * nealmcb didn't know salt could grin, but likes the idea :-) [21:05] so i''ll paste my list of proposed specs i would like to work on in intrepid, note that none of them are accepted or even put up on blueprints yet [21:05] colin has to nod off what i'm allowed to work on and we didnt have a meeting about it yet, so take that list with a grin of salt [21:06] * ogra resisted the urge to fix the typo :) [21:06] * USB Key images by default (dd'able casper images for usb keys) [21:06] * WLAN Mesh networking support out of the box [21:06] * Easy touchscreen calibration [21:06] * Initramfs profiling by default [21:06] * Lightweight kernel flavor (core kernel flavour for minimal ram usage) [21:06] * edubuntu menu completion ui [21:06] * local content filter (finish willowng parental control, ufw integration) [21:06] * ltsp sound cleanup (adapt full pulseaudio support even for capturing) [21:06] * ltsp localapps (finish the proof of concept setup from gutsy) [21:07] for edubuntu mst intresting is the menu stuff and willowng finishing i guess [21:07] *most [21:07] looks like a CMPC todolist if you remove the 2 ltsp items :) [21:07] willow and edubuntu-menus eare no cmpc items [21:08] and the others rather fall into general subnotebook and ressource reduction realm :) [21:08] i surely dont want to have another image like i have to maintain now for cmpc [21:08] they will stick on me eternally, i'd like to avoid that [21:09] LaserJock, so for the edubuntu-menu completion i thought about looking for a sceduling app as well to integrate with that [21:09] *scheduling [21:10] 22:04 < LaserJock> yeah, I'm running to my advisor meeting [21:10] 22:04 < LaserJock> I'll be back hopefully soon [21:10] ogra: ^ [21:10] well, willowng has lots of potential but misses the final bits [21:10] stgraber, yup, saw that [21:10] ok [21:11] i'D also like to look into FF addons [21:11] for content stuff [21:12] ok, from my side. My current planned changes for Intrepid are : [21:12] stgraber, oh, and the touchscreen spec is totally selfish ... i want my touchscreen to work on the new lappie ;) [21:12] * Integration of avahi with iTalc (already done in PPA) [21:12] not cmpc or edu related :) [21:12] * UI for key export/import [21:13] * Easy way to add it to the LTSP chroot (some users asked for that) [21:13] and stability fixes [21:13] what exactly ? [21:13] some users want ica to be running on the thin clients instead of the server [21:13] hmm [21:13] so it uses less bandwidth and CPU power [21:13] that will actually use more bandwith [21:13] the problem is that we'd need to add QT4, dbus and avahi [21:14]