=== Varka_ is now known as Varka [05:19] @schedule Santiago [05:38] Schedule for America/Santiago: 12 Mar 17:00: Server Team | 14 Mar 16:00: MOTU | 14 Mar 17:00: REVU Coordination | 19 Mar 17:00: Server Team | 26 Mar 17:00: Server Team === cjwatson_ is now known as cjwatson [06:57] hi [06:57] yawn [06:57] hello [06:57] Greetings. [06:57] * ogra feels like sh*t [06:57] * asac waves (in time) [06:58] heya [06:58] we are out of coffee! argh [06:58] lol [06:58] * cjwatson attempts to survive on juice alone [06:58] * ArneGoetje waves [06:58] hard thing [06:58] cjwatson: I've always found a morning walk gets me woken up. :) [06:58] bit late :) [06:58] Yeah I know, but nevertheless, its the suggestino that counts. [06:58] suggestino [06:58] ugh [06:58] ta :) [06:58] suggestion [06:59] el suggestino ? [06:59] so just waiting for doko [06:59] he was in distro ... [06:59] evand: early enough for you? :) [06:59] ogra: yeah slip of the fingers.... twice. [06:59] doko: ping [07:00] TheMuso, sounds like some kind of southamerican pimp :) [07:00] good morning [07:00] ogra: I know. [07:00] :) [07:00] calc: pff, a cakewalk [07:00] aha, welcome [07:00] right, I only have two activity reports this week; I hope that the rest are stuck in a mail queue (I think my mail reception doesn't work so well overnight for some reason) [07:01] * cjwatson blinks and realises he clearly can't count [07:01] * TheMuso saw a lot on the ml./ [07:01] I just submitted mine a few minutes ago... sorry for that [07:01] * ogra just sent his ... with wrong date first place ... [07:01] cjwatson: more coffee? [07:01] ah, I counted ogra twice and made it nine without bothering to check all the names :) sorry Steve [07:01] :-) [07:02] ok, somebody else will have to say if there are agenda items in activity reports [07:02] yeah, we're easy to mix up :P [07:02] 2 in my one [07:03] so I wanted to talk first about scim, since there has been a lot of user confusion about scim accidentally being enabled for them, and I want to make sure we have a clear plan to ensure this is fixed for beta [07:03] cjwatson: it is fixed already [07:03] at the moment it looks like live CDs and fresh installs don't have it switched on, but that users sometimes get it enabled on upgrade [07:03] ArneGoetje: somebody reported breakage on upgrade just yesterday [07:03] i don't know if i forcefully uninstalled it, but its not enabled for me anymore. it was rather annoying a week ago. [07:04] * scim enabled by default for non-CJK locales: This has been resolved [07:04] with the latest scim and scim-bridge updates. On a current Live CD the [07:04] old behaviour, where scim is by default disabled for non-CJK locales can [07:04] be observed. Upgrading from Gutsy to Hardy should work fine also, [07:04] however I haven't tested it yet. For users who followed the Hardy [07:04] development manual interaction is required though. Calling [07:04] Language-selector, unchecking the checkbox and doing a re-login should [07:04] be sufficient. [07:04] i had to go back to gutsy for my vmware session for other reason so i didn't see if it got fixed for my issue [07:04] ArneGoetje: ah, is that a change since yesterday? [07:04] but it hasn't seemed to have affect my two hardy systems [07:04] cjwatson: no, I updated the packages a few days ago. [07:05] ArneGoetje: there have been reports since then; the evidence suggests that upgrades are still broken [07:05] somebody just yesterday reported upgrading from alpha-6 to current and having scim enabled [07:05] i didnt have any trace of scim on yesterdays classmate image === _czessi is now known as Czessi [07:06] cjwatson: for users who follow Hardy for a longer period, manual interaction is required to fix this. Language-selector -> uncek the checkbox -> re-login should fix it. [07:06] well, presumably neither I nor the other bug reporter followed the "calling language-selector" step? [07:06] i mean of it getting in my way ... its installed indeed [07:06] OTOH, where *is* language-selector? I don't seem to have it on my system [07:06] cjwatson: Live CD from Mar 9 had it fixed already [07:06] ArneGoetje: OK, I'll be happy if gutsy->hardy (and ideally also dapper->hardy) are tested for this before beta [07:06] ArneGoetje: could you organise that? [07:07] slangasek: System -> Administration -> Language Support [07:07] slangasek: we should add Arne's comment above to the release notes [07:07] cjwatson: ack [07:07] cjwatson: will do. [07:07] ArneGoetje: is there any way to sanely spot the breakage and revert it without also overwriting user customisations? [07:08] three's been a lot of noise on #ubuntu-devel, #distro, #canonical, well just about everywhere about it [07:08] Scott has been taking a lot of heat for it too [07:08] (since everyone assumes it's a desktop thing) [07:08] cjwatson: not really... see my comments in bug #199030 [07:08] override the alternative on upgrade only if it's set to the expected value and we're upgrading from the problematic version? [07:09] cjwatson: short explanation: [07:10] cjwatson: some time in the past the function to enable/disable scim in language-selector broke and the link in /etc/X11/xinit/xinout.d/ for all_ALL was set by default. [07:11] cjwatson: as we cannot detect which user enabled it on purpose and who didn't, we cannot fix it by script, can we? [07:12] you could ask [07:12] by "set by default", you mean "update-alternatives was misused from a maintainer script"? [07:12] or something else? [07:12] like the directory conversion tool does [07:12] its ugly but helps [07:12] slangasek: I'm not sure what caused it actually.. I just remember that I couldn't uncheck the checkbox anymore... [07:12] I'm not convinced that all these users had ever seen the language-selector UI [07:13] I hadn't :) [07:13] it feels much more like an update-alternatives accident to me [07:13] cjwatson: as I said, I'm not sure what caused the breakage... [07:13] it affected my vmware image when i hadn't done anything with it, of course it wasn't a local fresh install (got it off the site) [07:13] that means we need to be extra-careful about testing it [07:13] it was a image that was upgraded from gutsy [07:13] if you aren't sure what caused it, it doesn't seem that you can say that it happened during hardy development [07:14] and we should probably put some effort into tracking down what *did* cause it [07:14] report is that alpha-6 -> current reproduces it, so perhaps we should start there [07:14] the bug was triggered recently with the seeding of im-switch. when im-switch is not installed on the system, scim can't be started at all. that's why it hadn't surfaced earlier. [07:14] indeed [07:15] but it's a very serious problem when it does show up, so it is our responsibility to understand it as much as we can [07:15] * debian/scim.postinst: disable u-a calls for all_ALL; remove the [07:15] scim-bridge entries again... they should go into the scim-bridge package. [07:15] while I'm happy with "hardy users have to do some magic to recover" if that's necessary, it would be better for that not to be required [07:16] ArneGoetje: that's from the most recent changelog on scim; what was the u-a call being disabled? [07:16] slangasek: that was the fix, yes [07:16] also, was the removal of those alternatives from postinst accompanied by a prerm change to remove existing alternatives on upgrade? [07:16] ArneGoetje: "what" was the u-a call being disabled? :) [07:17] hmm, apparently those alternatives are unconditionally removed on upgrade [07:18] slangasek: it's the one that's commented out in scim.postinst at the moment [07:18] #ua_inst all_ALL scim 0 [07:18] #ua_inst all_ALL scim-immodule 0 [07:18] slangasek: before it was set to scim-bridge, as well as additiinal entries to scim and scim-immodule, but with lower priority. that was amistake [07:18] ok, those are just removals of calls to ua_inst(), which currently DTRT [07:18] oh, no, I'm wrong [07:18] so it's not the culprit for the manual u-a [07:18] ArneGoetje: we have some empirical evidence that update-alternatives has ended up in manual mode for the xinput-all_ALL alternative [07:18] in the buggy cases [07:19] this class of problem is traditionally an absolute bastard to track down, but usually worth it [07:19] (and sometimes is a bug in update-alternatives, which is one of the least reliable programs in the dpkg toolchain) [07:19] cjwatson: they will also be removed in prerm [07:20] worst case, as ogra suggests, a debconf question on upgrade might be the least ugly solution [07:20] hrm, I don't remember if u-a --remove DT"R"T if called for an alternative in manual mode that's pointed at the entry you're removing [07:21] so the alternative was reported to be wrong in the alpha-6 liveCD? [07:21] if ($mode eq "manual" and $state ne "expected" and (map { $hits += $apath eq $_ } @versions) and $hits and $linkname eq $apath) { [07:21] &pr(_g("Removing manually selected alternative - switching to auto mode")); [07:21] should be traceable in that case [07:21] $mode = "auto"; [07:21] } [07:21] it's supposed to, at least [07:21] I'm not sure if it was desktop or alternate, the report wasn't detailed enough [07:22] cjwatson: well, that means that every package upgrade resets the value... [07:22] since they're all being unregistered in prerm and reregistered in postinst [07:22] hah, yes, apparently [07:22] this is one of the broken modes of update-alternatives use [07:22] yep [07:22] (which is UNDOCUMENTED, gah policy rant) [07:23] so I'll dig into the livefs and see if I can confirm the broken alternative there [07:24] Launchpad bug 199030 in scim "Can't close SCIM" [High,Fix released] https://launchpad.net/bugs/199030 [07:24] fixing bugs in update-alternatives for hardy+1 would be nice ... [07:24] * cjwatson would just like to say http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71621 [07:24] Debian bug 71621 in debian-policy "No policy on calling update-alternatives (was Re: update-alternatives)" [Wishlist,Fixed] [07:24] (which Manoj closed out of hand) [07:25] heh [07:25] you could reopen it now that Russ is a policy maintainer :-) [07:25] I think I might [07:26] slangasek: could you continue to work with Arne to try to nail this down? [07:26] yes [07:27] great, thanks [07:27] * Beta status [07:27] I know we aren't quite frozen yet - anything interesting to report? [07:27] Wubi installs onto FAT32 partitions are currently a non-event. [07:27] I wonder if those should just plain be blacklisted [07:28] "doctor, it hurts when I do this" [07:28] beta is the milestone where aaaaaall the bugs have landed that weren't critical for the alphas [07:28] Spent time with Agostino today debugging a few things, but still an issue somewhere, where abouts I'm not sure yet. [07:28] * ogra is heavily disappointed by ram usage of the i810 driver on the classmate ... [07:28] so there's some triaging to be done, but more importantly there's plenty of bugfixing we should be doing too :) [07:28] cjwatson: Sounds sane to me, since NTFs allows for much larger files, and we can now write to it anyways. [07:29] i tried the intel driver by accident, it takes over 30M less reserved ram :( [07:29] (.oO wubi to umsdos...) [07:29] slangasek: Yes, installing onto FAT32 bails out on first attempted boot from the loop mounted FS. [07:30] TheMuso: oh, sorry, I thought I was making a umsdos joke [07:30] that is rather a lot of bugs [07:30] ugh no umsdos die die die [07:30] ZipSlack will make a comeback someday ;) [07:31] yay [07:31] umsdos on fat16... really good way to eat up all clusters [07:31] bug 193842 looks complex, and better sooner than later if it's going to land [07:31] Launchpad bug 193842 in acpi-support "Please sponsor cherrypicked fixes for acpi-support into Hardy" [Medium,Triaged] https://launchpad.net/bugs/193842 [07:33] are we sure these scripts are executed at all with the new power management structure ? [07:33] * ogra knows modules he lists in /etc/default/acpi-support are definately not unloaded anymore [07:33] well, I know things aren't firing that I'm expecting to on my Thinkpad [07:34] but I'm not sure whether that's a kernel issue [07:34] all i know is that with hardy the PM structure changed a lot leaving everything to hal, having mjg59 taking a look at that bug would be a good thing imho [07:34] btw are systems supposed to make noise now on sleep/wake? [07:34] it wouldn't hurt, but since he's formally left the project we cannot rely on him to do it [07:34] i noticed my laptop started doing that a while back [07:35] had a lot of problems with the lcd brightness not coming up again after sleeping [07:35] but current kernel works [07:35] calc, it does that on lid open/close as well ... gpm doesnt have a fine grained scheme for it and just makes noise for everything or nothing [07:35] ogra: ah [07:35] calc: there's a g-p-m change, if you look under preferences there's "Use sound to notify in event of an error"... it seems to believe that everything is an error [07:35] acpi-support has ~18 bugs with patches attached: http://daniel.holba.ch/really-fix-it [07:36] i had disabled it in the past because i didnf fid it suitable without being able to tag events for noise specifically [07:36] ok, we could probably keep on looking at ACPI bugs all day, but I gathered there were a few other agenda items [07:36] slangasek: yea it always claims my system doesn't suspend properly but it seems to afaict [07:36] who else do we have that's versed in the current power management structure then? [07:36] pitti? [07:36] slangasek, ted does the frontend and matthew the acpi and parts of the kernel stuff [07:36] pitti is usually a good start for matters of hardware-from-userspace [07:37] it suddenly got awfully quiet - is this thing still on? *pff pff* [07:37] for hardcore kernel things amit is also a good resource [07:37] and as ogra says Ted has been taking on gnome-power-manager maintenance [07:37] bryce: there's been pretty steady conversation for the last 30+ minutes [07:38] weird, irc was being hangy. seems better now [07:38] g-p-m has 14 bugs open on http:/daniel.holba.ch/really-fix-it - if we can't review them, maybe we should forward them upstream and see what hughsie says [07:39] could somebody volunteer to review and sponsor that acpi-support change, please? [07:39] I suspect that, if it's any good, Daniel Hahler may end up as the de facto acpi-support maintainer ;-) [07:39] I've already followed up to an acpi-support sponsor request, because some of the proposed changes affect my hardware [07:39] I can follow through [07:40] much appreciated [07:41] ArneGoetje: you said you had some other agenda items? [07:41] * There is a crash report for scim-bridge which has lots of duplicates [07:41] by now. However, I cannot reliably reproduce it. People claim [07:41] scim-bridge crashes on startup. However, on a recent Live CD and also on [07:41] my local system, there is no crash. [07:41] When installing the Live CD from 3 days ago, after reboot, I activated [07:41] scim support in Language-Selector and did a reboot. After then I opened [07:41] a terminal and toggeled scim repeatedly by pressing crtl+space multiple [07:41] times. The crash happened once and never again. Also inputting complex [07:41] scripts with scim worked. So, as I cannot reliably reproduce this crash, [07:41] I'm asking for help. [07:42] no apport retracer data on it [07:42] ? [07:42] slangasek: the bug has apport data attached. [07:42] bug #? [07:43] bug #199592 [07:44] * slangasek whimpers [07:44] that looks like conflicting libstdc++ versions to me [07:45] So, basically my question is, why it happens only in some situations, and whether it really is a scim-bridge bug or libscim, which is in the scim package, or somewhere else... [07:45] I noticed there were some linstdc++ updates in the past days... [07:46] I'm thinking of the class of crash that's caused by having two different libstdc++ sonames loaded in memory at the same time [07:46] * ArneGoetje has no idea about that [07:46] it classically affects XIM because XIM is one of the few things that's dynamically loaded by a large range of apps, *and* is written in C++ [07:46] this is the actual scim-bridge process though, not a random client [07:47] but even the fglrx driver now uses libstdc++.so.6 [07:47] right; I don't know for sure that's the same problem here, but it's the first thing I think of when I see unreproducible crashes in a C++ deconstructor [07:47] could of course be a poorly-written destructor [07:47] true [07:48] hmm, when was scim-bridge built the last time? [07:48] 6 days ago [07:48] ok [07:49] scim::Module::unload is not exactly trivial ... [07:49] calls a bunch of other stuff, does dlclose, etc. [07:50] but the crash doesn't always seem to be there, either [07:50] it might be worth running scim-bridge under valgrind [07:51] doko_: could you help Arne out with this? [07:51] cjwatson: trying, but probably not before Tuesday [07:52] ok, if the other problems with scim being started by default get fixed, then it will only affect CJK users (for whom presumably it isn't a regression) [07:52] for CJK users it's expected behaviour [07:53] a crash is not expected behaviour [07:53] without loss of generality [07:53] I mean scim being started by default :P [07:53] right, but I didn't :-) [07:53] got it [07:53] I meant that the crash has presumably been around for a while [07:54] I'll un-private that bug and stick it on the hardy list [07:54] thanks [07:54] any other business? [07:54] two quick questions: [07:54] Yes, a quick one re minutes. [07:54] asac: go [07:54] NetworkManager: does anyone experience issues since 0.6.6? i am especially interested in ipw2X00, madwifi and broadcom things. [07:55] broadcom seems OK for me so far [07:55] cjwatson: some things ... [07:55] * ogra is very happy with it on his laptop and on the classmate [07:55] * TheMuso hasn't used his ipw2100 for a fair while, but will try with the latest daily. [07:55] (laptop == broadcom as well) [07:55] TheMuso: please do [07:55] i dropped a bunch of driver tweaks [07:55] do we want to have bash-completion installed on the desktop? [07:55] and its hard to judge from bugs if that is just after-upgrade-"noise" [07:55] 2nd. did anyone retrieve my activity report last week? [07:55] * ArneGoetje has ipw2200... will try tonight... (no wireless here right now) [07:56] some users think so, but others disagree. if it's installed, it is enabled by default [07:56] doko_, is it big ? does it do any harm sitting on the disk ? [07:56] 3010 Mar 05 Alexander Sack ( 74) [ACTIVITY] Feb 27 - Mar 04 (asac) [07:56] 3069 L Mar 12 Alexander Sack ( 59) [ACTIVITY] Mar 05 - Mar 11 [07:56] no harm on the list [07:56] ArneGoetje: highly appreciated. i have reports about it being broken [07:56] asac: wfm, ipw3945 (know it's not exactly your target group) [07:56] wasn't it installed by default before (as part of bash)? [07:56] asac: orz [07:56] 120k [07:56] doko_: I never wanted it enabled by default in the first place, but considered that I'd lost that battle [07:56] * TheMuso wondered where his useful completion went. [07:56] s/his/the/ [07:56] cjwatson: ok thanks. i still didn't get that. just want to be sure because it contained some valuable content about mozilla translations imo [07:57] I can live with not having it by default. [07:57] doko_, pfft [07:57] slangasek: yes, but I got tired, never getting any replies from upstream [07:57] thats nothing [07:57] ok if you could try all the chipsets you have around i would be happy to receive feedback [07:57] imho we should have it ... its comfortable [07:57] asac: Will keep you posted. [07:57] TheMuso: go [07:57] the only thing that ever concerned me about bash-completion was shell startup time [07:57] in the case we still want it, I'd like to seed it for desktop, so that people can uninstall it on the server [07:58] asac: not sure if this is expected but it seems nm still drops connection on upgrades [07:58] mainly affecting people like us who start lots of shells [07:58] Ok. re minutes, this is the 4th week I've done it. While I don't mind doing them, I wonder if people would be up for doing 4 weekly stints of minutes, and then moving onto someone else? [07:58] calc: thats expected. i will fix that for final (e.g. don't restart at all) [07:58] asac: ok [07:58] ok, but the lots of you can then remove or disable it [07:58] cjwatson, well, give that the terminal we use already grabs 20-25M and is slow anyway, who cares ... [07:58] *given [07:58] not restarting is the official advice from upstream :( [07:58] ogra: might be the terminal *you* use :-P [07:59] cjwatson, i use the one *we* install by default :) [07:59] any disagreement to seed bash-completion again? [07:59] the one our users use :) [07:59] doko_: remove/disable> indeed, I do, but still [07:59] doko_: bash-completion is a Recommends at present, so it looks like it can be removed already [07:59] we can keep it in universe as well [08:00] in fact, I appear not to have it installed, presumably by accident [08:00] ogra: (yeah, this is my one deviation from that rule which I normally do apply to myself) [08:00] next thing: shorewall - do we want to have this in main? [08:01] I have no objection to bash-completion either being seeded or unseeded; if it is seeded, it should be as a recommends (" * (bash-completion)") [08:01] i use xterm on the classmate i must admit :) [08:01] hang on, let's serialise these agenda items [08:01] doko_, i thought that was gone after th discussion a month ago [08:01] 07:58 Ok. re minutes, this is the 4th week I've done it. While I don't mind doing them, I wonder if people would be up for doing 4 weekly stints of minutes, and then moving onto someone else? [08:02] I have no objection to rotating the secretary job if there are other volunteers [08:03] TheMuso: BTW, as a small tweak, it would be good to have an explicit Actions section at the end with any specific follow-on tasks that have been agreed; I find that useful when it comes to the next meeting [08:03] cjwatson: Ok thanks for feedback. [08:03] would anyone else like to do this after Luke, with the knowledge that it's for a bounded time? [08:04] Ok, I'm quite happy to keep doing them for the time being. [08:04] I volunteer, but not for the next two weeks [08:05] I can take May [08:05] thanks, I'm sure even a rotation of three will help; sort it out among yourselves :-) [08:05] doko_: so, shorewall [08:05] as contrasted with ufw, presumably [08:06] ok, I'll re-add it to the seeds, with a comment [08:06] ... (I didn't think that was a decision) [08:06] oops [08:06] shorewall was in main up to gutsy, so I certainly have no objection to it being added back [08:07] once the bashims were fixed it looks rather stable [08:07] you removed it, I see [08:07] - remove shorewall from server-ship (ufw is in main) [08:07] it's not the killer firewall, but ufw isn't today either; and shorewall gives users functionality that ufw doesn't [08:07] yes, but it's still referenced in Kubuntu hardy [08:07] my gut feeling is that ufw is rather new and relatively untried compared to shorewall, and, while ufw may well turn out to be the future once it's well-integrated, a lot of people will still want to use shorewall for good reasons [08:08] so I think we should ship it [08:08] * ArneGoetje is happily using shorewall on all my machines, including laptop :) [08:08] technically it should be a server team decision, mind you [08:09] I'll bring it to their attention [08:10] next: any actions about duplicates/unnecessary files on the CDs? [08:10] but I think it's fine to go for status quo (i.e. ship shorewall, as in gutsy) until they explicitly say otherwise [08:10] which would correspond to "use ufw in all cases, damn your eyes" [08:11] can we carry on discussing duplicates/unnecessary files on the list? [08:11] or perhaps on ubuntu-devel@, since it's currently distro-team@ [08:11] just conscious that we're over time [08:11] fine with me, sending then to u-d [08:11] i have another quick one about seeds: the crash reporter of mozilla upstream builds doesn't work in default installs, because we don't ship ca-certificates. any arguments against shipping them? [08:11] (or make curl depend on ca-certificates) [08:12] I'm sure we used to ship ca-certificates? [08:12] didnt we ship the before ? [08:12] i think so ... i guess one rdepends got removed from cd [08:12] no objection to shipping them provided that its (crazy) debconf question doesn't get asked by default [08:12] unfortunately I suspect it does get asked by default on upgrades, worth checking its priority [08:12] yes. afaik you don't get asked about that [08:13] hmm ... really? i never saw any question. but maybe thats because the packages wasn't updated for a while [08:13] i can check that [08:13] thanks [08:13] I'm just going on vague memory, I'm afraid [08:13] ca-certificates was in dapper/desktop [08:14] dependency of libcurl3 [08:14] apparently it fell out in gutsy [08:14] hmmm ... libcurl3-gnutls has a recommends on it now [08:15] might have to duplicate that recommendation in the seeds, then, until such time as we do recommends-by-default [08:15] yep [08:15] thanks [08:15] which I think fell out of hardy because the ball was in too many people's courts [08:15] ok, 15 minutes over time, so let's adjourn [08:15] thanks all [08:15] Thanks. [08:15] thanks all [08:15] thanks [08:15] thanks [08:15] Minutes will be out tomorrow. [08:16] * asac hugs TheMuso [08:16] thanks [08:16] great [08:16] Launchpad bug 199592 in scim-bridge "scim-bridge crashed with SIGSEGV in scim::Module::unload()" [Medium,In progress] https://launchpad.net/bugs/199592 [08:16] thanks [08:18] thanks [08:18] goodnight :) [08:19] sleep well, USians [08:19] * bryce zzz's [08:19] (early meeting tomorrow) [08:21] heh, thanks === doko_ is now known as doko === \sh_away is now known as \sh === ogra_cmpc_ is now known as ogra_cmpc [12:04] hello ... who's here for the education meeting ? [12:04] * stgraber waves [12:04] hi stgraber :) [12:05] * ogra_cmpc waves ... very tired [12:06] only us three ? [12:06] well apart from the passive lurkers ... looks like it [12:07] let's whip through a tech status then ... [12:07] well, i somewhat lost track with edubuntu the last days, was sitting in a cave and finishing the autobuilder and writing the new installer [12:07] * Hobbsee waves [12:08] on my for fixes i have the edubuntu-addon metatdata ... there is still the xfce entry in there which doesnt do anything anymore [12:09] and te edubuntu entry needs a proper short descritipon ... [12:09] ahhh .. [12:09] * RichEd spots the delayed wave from Hobbsee all the way from oz [12:10] RichEd: :) [12:10] there is still some gfxboot work i didnt manage yet (adding LTSP to the modes menu and somehow find a way to prevent teh addon cd from looking like a install cd if you boot it) ... i was pondering to ask cjwatson for help here [12:10] gfxboot is a beast and takes more time than i want to understand it atm [12:11] s/want/have/ [12:11] beyond that the cds should be pretty much in shape [12:11] s/cds/cd/ [12:11] :D [12:12] you will have seen me throwing around classmate images ... so classmate is also starting to look pretty well ... better and better every day [12:14] for ltsp i plan a final upload for tonight or tommorw, there are a bunch of bugs with fixes i want to include before we freeze to deep .... [12:14] well, thats about it from the tech side [12:14] i'd like to note that artwork freeze is tomorrow [12:14] gimme a sec ... getting power [12:14] which means we'll likely not have anything new in hardy [12:15] and there are a bunch of edubuntu-doc bugs that need a helping hand (not sure if laserjock went over them already) [12:15] is that an absolute art final, or is there a sneak it in route i've heard mentioned :) [12:16] the artwork thing is quite bad btw .... [12:16] no official one [12:16] we have an LTS this time [12:16] okay ... and what time tomorrow is the freeze ? [12:16] and that means the doc teams will want to have a fixed UI state for their screenshots etc [12:16] there is no time [12:17] so is the end of the day US time acceptable ? [12:17] slangasek is our release manager ... he will call out the freeze at will [12:17] i'll hav a word with him ... see how flexible he could be ... [12:17] not sure what time he prefers, but he sits in US westcoast ... [12:18]