[05:19] <mruiz> @schedule Santiago
[05:38] <ubotu> 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
[06:57] <calc> hi
[06:57] <ogra> yawn
[06:57] <evand> hello
[06:57] <TheMuso> Greetings.
[06:57]  * ogra feels like sh*t
[06:57]  * asac waves (in time)
[06:58] <bryce> heya
[06:58] <cjwatson> we are out of coffee! argh
[06:58] <asac> lol
[06:58]  * cjwatson attempts to survive on juice alone
[06:58]  * ArneGoetje waves
[06:58] <ogra> hard thing
[06:58] <TheMuso> cjwatson: I've always found a morning walk gets me woken up. :)
[06:58] <cjwatson> bit late :)
[06:58] <TheMuso> Yeah I know, but nevertheless, its the suggestino that counts.
[06:58] <TheMuso> suggestino
[06:58] <TheMuso> ugh
[06:58] <cjwatson> ta :)
[06:58] <TheMuso> suggestion
[06:59] <ogra> el suggestino ?
[06:59] <cjwatson> so just waiting for doko
[06:59] <ogra> he was in distro ...
[06:59] <calc> evand: early enough for you? :)
[06:59] <TheMuso> ogra: yeah slip of the fingers.... twice.
[06:59] <cjwatson> doko: ping
[07:00] <ogra> TheMuso, sounds like some kind of southamerican pimp :)
[07:00] <doko> good morning
[07:00] <TheMuso> ogra: I know.
[07:00] <TheMuso> :)
[07:00] <evand> calc: pff, a cakewalk
[07:00] <cjwatson> aha, welcome
[07:00] <cjwatson> 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] <ArneGoetje> I just submitted mine a few minutes ago... sorry for that
[07:01]  * ogra just sent his ... with wrong date first place ...
[07:01] <calc> cjwatson: more coffee?
[07:01] <cjwatson> ah, I counted ogra twice and made it nine without bothering to check all the names :) sorry Steve
[07:01] <slangasek> :-)
[07:02] <cjwatson> ok, somebody else will have to say if there are agenda items in activity reports
[07:02] <ogra> yeah, we're easy to mix up :P
[07:02] <ArneGoetje> 2 in my one
[07:03] <cjwatson> 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] <ArneGoetje> cjwatson: it is fixed already
[07:03] <cjwatson> 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] <cjwatson> ArneGoetje: somebody reported breakage on upgrade just yesterday
[07:03] <asac> 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] <ArneGoetje>  * scim enabled by default for non-CJK locales: This has been resolved
[07:04] <ArneGoetje> with the latest scim and scim-bridge updates. On a current Live CD the
[07:04] <ArneGoetje> old behaviour, where scim is by default disabled for non-CJK locales can
[07:04] <ArneGoetje> be observed. Upgrading from Gutsy to Hardy should work fine also,
[07:04] <ArneGoetje> however I haven't tested it yet. For users who followed the Hardy
[07:04] <ArneGoetje> development manual interaction is required though. Calling
[07:04] <ArneGoetje> Language-selector, unchecking the checkbox and doing a re-login should
[07:04] <ArneGoetje> be sufficient.
[07:04] <calc> 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] <cjwatson> ArneGoetje: ah, is that a change since yesterday?
[07:04] <calc> but it hasn't seemed to have affect my two hardy systems
[07:04] <ArneGoetje> cjwatson: no, I updated the packages a few days ago.
[07:05] <cjwatson> ArneGoetje: there have been reports since then; the evidence suggests that upgrades are still broken
[07:05] <cjwatson> somebody just yesterday reported upgrading from alpha-6 to current and having scim enabled
[07:05] <ogra> i didnt have any trace of scim on yesterdays classmate image
[07:06] <ArneGoetje> 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] <slangasek> well, presumably neither I nor the other bug reporter followed the "calling language-selector" step?
[07:06] <ogra> i mean of it getting in my way ... its installed indeed
[07:06] <slangasek> OTOH, where *is* language-selector? I don't seem to have it on my system
[07:06] <ArneGoetje> cjwatson: Live CD from Mar 9 had it fixed already
[07:06] <cjwatson> ArneGoetje: OK, I'll be happy if gutsy->hardy (and ideally also dapper->hardy) are tested for this before beta
[07:06] <cjwatson> ArneGoetje: could you organise that?
[07:07] <ArneGoetje> slangasek: System -> Administration -> Language Support
[07:07] <cjwatson> slangasek: we should add Arne's comment above to the release notes
[07:07] <slangasek> cjwatson: ack
[07:07] <ArneGoetje> cjwatson: will do.
[07:07] <cjwatson> ArneGoetje: is there any way to sanely spot the breakage and revert it without also overwriting user customisations?
[07:08] <cjwatson> three's been a lot of noise on #ubuntu-devel, #distro, #canonical, well just about everywhere about it
[07:08] <cjwatson> Scott has been taking a lot of heat for it too
[07:08] <cjwatson> (since everyone assumes it's a desktop thing)
[07:08] <ArneGoetje> cjwatson: not really... see my comments in bug #199030
[07:08] <slangasek> override the alternative on upgrade only if it's set to the expected value and we're upgrading from the problematic version?
[07:09] <ArneGoetje> cjwatson: short explanation:
[07:10] <ArneGoetje> 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] <ArneGoetje> 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] <ogra> you could ask
[07:12] <slangasek> by "set by default", you mean "update-alternatives was misused from a maintainer script"?
[07:12] <slangasek> or something else?
[07:12] <ogra> like the directory conversion tool does
[07:12] <ogra> its ugly but helps
[07:12] <ArneGoetje> slangasek: I'm not sure what caused it actually.. I just remember that I couldn't uncheck the checkbox anymore...
[07:12] <cjwatson> I'm not convinced that all these users had ever seen the language-selector UI
[07:13] <slangasek> I hadn't :)
[07:13] <cjwatson> it feels much more like an update-alternatives accident to me
[07:13] <ArneGoetje> cjwatson: as I said, I'm not sure what caused the breakage...
[07:13] <calc> 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] <cjwatson> that means we need to be extra-careful about testing it
[07:13] <calc> it was a image that was upgraded from gutsy
[07:13] <cjwatson> if you aren't sure what caused it, it doesn't seem that you can say that it happened during hardy development
[07:14] <cjwatson> and we should probably put some effort into tracking down what *did* cause it
[07:14] <cjwatson> report is that alpha-6 -> current reproduces it, so perhaps we should start there
[07:14] <ArneGoetje> 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] <cjwatson> indeed
[07:15] <cjwatson> 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] <slangasek>   * debian/scim.postinst: disable u-a calls for all_ALL; remove the
[07:15] <slangasek>     scim-bridge entries again... they should go into the scim-bridge package.
[07:15] <cjwatson> 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] <slangasek> ArneGoetje: that's from the most recent changelog on scim; what was the u-a call being disabled?
[07:16] <ArneGoetje> slangasek: that was the fix, yes
[07:16] <cjwatson> also, was the removal of those alternatives from postinst accompanied by a prerm change to remove existing alternatives on upgrade?
[07:16] <slangasek> ArneGoetje: "what" was the u-a call being disabled? :)
[07:17] <cjwatson> hmm, apparently those alternatives are unconditionally removed on upgrade
[07:18] <cjwatson> slangasek: it's the one that's commented out in scim.postinst at the moment
[07:18] <cjwatson>         #ua_inst all_ALL scim  0
[07:18] <cjwatson>         #ua_inst all_ALL scim-immodule 0
[07:18] <ArneGoetje> 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] <slangasek> ok, those are just removals of calls to ua_inst(), which currently DTRT
[07:18] <cjwatson> oh, no, I'm wrong
[07:18] <slangasek> so it's not the culprit for the manual u-a
[07:18] <cjwatson> ArneGoetje: we have some empirical evidence that update-alternatives has ended up in manual mode for the xinput-all_ALL alternative
[07:18] <cjwatson> in the buggy cases
[07:19] <cjwatson> this class of problem is traditionally an absolute bastard to track down, but usually worth it
[07:19] <cjwatson> (and sometimes is a bug in update-alternatives, which is one of the least reliable programs in the dpkg toolchain)
[07:19] <ArneGoetje> cjwatson: they will also be removed in prerm
[07:20] <cjwatson> worst case, as ogra suggests, a debconf question on upgrade might be the least ugly solution
[07:20] <slangasek> 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] <slangasek> so the alternative was reported to be wrong in the alpha-6 liveCD?
[07:21] <cjwatson>     if ($mode eq "manual" and $state ne "expected" and (map { $hits += $apath eq $_ } @versions) and $hits and $linkname eq $apath) {
[07:21] <cjwatson>         &pr(_g("Removing manually selected alternative - switching to auto mode"));
[07:21] <slangasek> should be traceable in that case
[07:21] <cjwatson>         $mode = "auto";
[07:21] <cjwatson>     }
[07:21] <cjwatson> it's supposed to, at least
[07:21] <cjwatson> I'm not sure if it was desktop or alternate, the report wasn't detailed enough
[07:22] <slangasek> cjwatson: well, that means that every package upgrade resets the value...
[07:22] <slangasek> since they're all being unregistered in prerm and reregistered in postinst
[07:22] <cjwatson> hah, yes, apparently
[07:22] <cjwatson> this is one of the broken modes of update-alternatives use
[07:22] <slangasek> yep
[07:22] <cjwatson> (which is UNDOCUMENTED, gah policy rant)
[07:23] <slangasek> so I'll dig into the livefs and see if I can confirm the broken alternative there
[07:24] <ubotu> Launchpad bug 199030 in scim "Can't close SCIM" [High,Fix released] https://launchpad.net/bugs/199030
[07:24] <doko_> 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] <ubotu> Debian bug 71621 in debian-policy "No policy on calling update-alternatives (was Re: update-alternatives)" [Wishlist,Fixed]
[07:24] <cjwatson> (which Manoj closed out of hand)
[07:25] <slangasek> heh
[07:25] <slangasek> you could reopen it now that Russ is a policy maintainer :-)
[07:25] <cjwatson> I think I might
[07:26] <cjwatson> slangasek: could you continue to work with Arne to try to nail this down?
[07:26] <slangasek> yes
[07:27] <cjwatson> great, thanks
[07:27] <cjwatson>  * Beta status
[07:27] <cjwatson> I know we aren't quite frozen yet - anything interesting to report?
[07:27] <TheMuso> Wubi installs onto FAT32 partitions are currently a non-event.
[07:27] <cjwatson> I wonder if those should just plain be blacklisted
[07:28] <cjwatson> "doctor, it hurts when I do this"
[07:28] <slangasek> beta is the milestone where aaaaaall the bugs have landed that weren't critical for the alphas
[07:28] <TheMuso> 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] <slangasek> so there's some triaging to be done, but more importantly there's plenty of bugfixing we should be doing too :)
[07:28] <TheMuso> cjwatson: Sounds sane to me, since NTFs allows for much larger files, and we can now write to it anyways.
[07:29] <ogra> i tried the intel driver by accident, it takes over 30M less reserved ram :(
[07:29] <slangasek> (.oO wubi to umsdos...)
[07:29] <TheMuso> slangasek: Yes, installing onto FAT32 bails out on first attempted boot from the loop mounted FS.
[07:30] <slangasek> TheMuso: oh, sorry, I thought I was making a umsdos joke
[07:30] <cjwatson> that is rather a lot of bugs
[07:30] <calc> ugh no umsdos die die die
[07:30] <evand> ZipSlack will make a comeback someday ;)
[07:31] <ogra> yay
[07:31] <calc> umsdos on fat16... really good way to eat up all clusters
[07:31] <cjwatson> bug 193842 looks complex, and better sooner than later if it's going to land
[07:31] <ubotu> Launchpad bug 193842 in acpi-support "Please sponsor cherrypicked fixes for acpi-support into Hardy" [Medium,Triaged] https://launchpad.net/bugs/193842
[07:33] <ogra> 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] <slangasek> well, I know things aren't firing that I'm expecting to on my Thinkpad
[07:34] <slangasek> but I'm not sure whether that's a kernel issue
[07:34] <ogra> 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] <calc> btw are systems supposed to make noise now on sleep/wake?
[07:34] <cjwatson> it wouldn't hurt, but since he's formally left the project we cannot rely on him to do it
[07:34] <calc> i noticed my laptop started doing that a while back
[07:35] <doko_> had a lot of problems with the lcd brightness not coming up again after sleeping
[07:35] <doko_> but current kernel works
[07:35] <ogra> 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] <calc> ogra: ah
[07:35] <slangasek> 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] <dholbach> acpi-support has ~18 bugs with patches attached: http://daniel.holba.ch/really-fix-it
[07:36] <ogra> i had disabled it in the past because i didnf fid it suitable without being able to tag events for noise specifically
[07:36] <cjwatson> ok, we could probably keep on looking at ACPI bugs all day, but I gathered there were a few other agenda items
[07:36] <calc> slangasek: yea it always claims my system doesn't suspend properly but it seems to afaict
[07:36] <slangasek> who else do we have that's versed in the current power management structure then?
[07:36] <slangasek> pitti?
[07:36] <ogra> slangasek, ted does the frontend and matthew the acpi and parts of the kernel stuff
[07:36] <cjwatson> pitti is usually a good start for matters of hardware-from-userspace
[07:37] <bryce> it suddenly got awfully quiet - is this thing still on?  *pff pff*
[07:37] <ogra> for hardcore kernel things amit is also a good resource
[07:37] <cjwatson> and as ogra says Ted has been taking on gnome-power-manager maintenance
[07:37] <cjwatson> bryce: there's been pretty steady conversation for the last 30+ minutes
[07:38] <bryce> weird, irc was being hangy.  seems better now
[07:38] <dholbach> 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] <cjwatson> could somebody volunteer to review and sponsor that acpi-support change, please?
[07:39] <cjwatson> I suspect that, if it's any good, Daniel Hahler may end up as the de facto acpi-support maintainer ;-)
[07:39] <slangasek> I've already followed up to an acpi-support sponsor request, because some of the proposed changes affect my hardware
[07:39] <slangasek> I can follow through
[07:40] <cjwatson> much appreciated
[07:41] <cjwatson> ArneGoetje: you said you had some other agenda items?
[07:41] <ArneGoetje>  * There is a crash report for scim-bridge which has lots of duplicates
[07:41] <ArneGoetje> by now. However, I cannot reliably reproduce it. People claim
[07:41] <ArneGoetje> scim-bridge crashes on startup. However, on a recent Live CD and also on
[07:41] <ArneGoetje> my local system, there is no crash.
[07:41] <ArneGoetje> When installing the Live CD from 3 days ago, after reboot, I activated
[07:41] <ArneGoetje> scim support in Language-Selector and did a reboot. After then I opened
[07:41] <ArneGoetje> a terminal and toggeled scim repeatedly by pressing crtl+space multiple
[07:41] <ArneGoetje> times. The crash happened once and never again. Also inputting complex
[07:41] <ArneGoetje> scripts with scim worked. So, as I cannot reliably reproduce this crash,
[07:41] <ArneGoetje> I'm asking for help.
[07:42] <slangasek> no apport retracer data on it
[07:42] <slangasek> ?
[07:42] <ArneGoetje> slangasek: the bug has apport data attached.
[07:42] <slangasek> bug #?
[07:43] <ArneGoetje> bug #199592
[07:44]  * slangasek whimpers
[07:44] <slangasek> that looks like conflicting libstdc++ versions to me
[07:45] <ArneGoetje> 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] <ArneGoetje> I noticed there were some linstdc++ updates in the past days...
[07:46] <slangasek> 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] <slangasek> 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] <cjwatson> this is the actual scim-bridge process though, not a random client
[07:47] <doko_> but even the fglrx driver now uses libstdc++.so.6
[07:47] <slangasek> 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] <cjwatson> could of course be a poorly-written destructor
[07:47] <slangasek> true
[07:48] <doko_> hmm, when was scim-bridge built the last time?
[07:48] <slangasek> 6 days ago
[07:48] <doko_> ok
[07:49] <cjwatson> scim::Module::unload is not exactly trivial ...
[07:49] <cjwatson> calls a bunch of other stuff, does dlclose, etc.
[07:50] <cjwatson> but the crash doesn't always seem to be there, either
[07:50] <cjwatson> it might be worth running scim-bridge under valgrind
[07:51] <cjwatson> doko_: could you help Arne out with this?
[07:51] <doko_> cjwatson: trying, but probably not before Tuesday
[07:52] <cjwatson> 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] <ArneGoetje> for CJK users it's expected behaviour
[07:53] <cjwatson> a crash is not expected behaviour
[07:53] <cjwatson> without loss of generality
[07:53] <ArneGoetje> I mean scim being started by default :P
[07:53] <cjwatson> right, but I didn't :-)
[07:53] <ArneGoetje> got it
[07:53] <cjwatson> I meant that the crash has presumably been around for a while
[07:54] <cjwatson> I'll un-private that bug and stick it on the hardy list
[07:54] <ArneGoetje> thanks
[07:54] <cjwatson> any other business?
[07:54] <asac> two quick questions:
[07:54] <TheMuso> Yes, a quick one re minutes.
[07:54] <TheMuso> asac: go
[07:54] <asac> NetworkManager: does anyone experience issues since 0.6.6? i am especially interested in ipw2X00, madwifi and broadcom things.
[07:55] <cjwatson> broadcom seems OK for me so far
[07:55] <doko_> 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] <ogra> (laptop == broadcom as well)
[07:55] <asac> TheMuso: please do
[07:55] <asac> i dropped a bunch of driver tweaks
[07:55] <doko_> do we want to have bash-completion installed on the desktop?
[07:55] <asac> and its hard to judge from bugs if that is just after-upgrade-"noise"
[07:55] <asac> 2nd. did anyone retrieve my activity report last week?
[07:55]  * ArneGoetje has ipw2200... will try tonight... (no wireless here right now)
[07:56] <doko_> some users think so, but others disagree. if it's installed, it is enabled by default
[07:56] <ogra> doko_, is it big ? does it do any harm sitting on the disk ?
[07:56] <cjwatson> 3010     Mar 05 Alexander Sack  (  74) [ACTIVITY] Feb 27 - Mar 04 (asac)
[07:56] <cjwatson> 3069   L Mar 12 Alexander Sack  (  59) [ACTIVITY] Mar 05 - Mar 11
[07:56] <doko_> no harm on the list
[07:56] <asac> ArneGoetje: highly appreciated. i have reports about it being broken
[07:56] <Hobbsee> asac: wfm, ipw3945 (know it's not exactly your target group)
[07:56] <slangasek> wasn't it installed by default before (as part of bash)?
[07:56] <ArneGoetje> asac: orz
[07:56] <doko_> 120k
[07:56] <cjwatson> 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] <TheMuso> s/his/the/
[07:56] <asac> 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] <TheMuso> I can live with not having it by default.
[07:57] <ogra> doko_, pfft
[07:57] <doko_> slangasek: yes, but I got tired, never getting any replies from upstream
[07:57] <ogra> thats nothing
[07:57] <asac> ok if you could try all the chipsets you have around i would be happy to receive feedback
[07:57] <ogra> imho we should have it ... its comfortable
[07:57] <TheMuso> asac: Will keep you posted.
[07:57] <asac> TheMuso: go
[07:57] <cjwatson> the only thing that ever concerned me about bash-completion was shell startup time
[07:57] <doko_> 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] <calc> asac: not sure if this is expected but it seems nm still drops connection on upgrades
[07:58] <cjwatson> mainly affecting people like us who start lots of shells
[07:58] <TheMuso> 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] <asac> calc: thats expected. i will fix that for final (e.g. don't restart at all)
[07:58] <calc> asac: ok
[07:58] <doko_> ok, but the lots of you can then remove or disable it
[07:58] <ogra> cjwatson, well, give that the terminal we use already grabs 20-25M and is slow anyway, who cares ...
[07:58] <ogra> *given
[07:58] <asac> not restarting is the official advice from upstream :(
[07:58] <cjwatson> ogra: might be the terminal *you* use :-P
[07:59] <ogra> cjwatson, i use the one *we* install by default :)
[07:59] <doko_> any disagreement to seed bash-completion again?
[07:59] <ogra> the one our users use :)
[07:59] <cjwatson> doko_: remove/disable> indeed, I do, but still
[07:59] <cjwatson> doko_: bash-completion is a Recommends at present, so it looks like it can be removed already
[07:59] <doko_> we can keep it in universe as well
[08:00] <cjwatson> in fact, I appear not to have it installed, presumably by accident
[08:00] <cjwatson> ogra: (yeah, this is my one deviation from that rule which I normally do apply to myself)
[08:00] <doko_> next thing: shorewall - do we want to have this in main?
[08:01] <cjwatson> 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] <ogra> i use xterm on the classmate i must admit :)
[08:01] <cjwatson> hang on, let's serialise these agenda items
[08:01] <ogra> doko_, i thought that was gone after th discussion a month ago
[08:01] <cjwatson> 07:58 <TheMuso> 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] <cjwatson> I have no objection to rotating the secretary job if there are other volunteers
[08:03] <cjwatson> 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] <TheMuso> cjwatson: Ok thanks for feedback.
[08:03] <cjwatson> would anyone else like to do this after Luke, with the knowledge that it's for a bounded time?
[08:04] <TheMuso> Ok, I'm quite happy to keep doing them for the time being.
[08:04] <doko_> I volunteer, but not for the next two weeks
[08:05] <bryce> I can take May
[08:05] <cjwatson> thanks, I'm sure even a rotation of three will help; sort it out among yourselves :-)
[08:05] <cjwatson> doko_: so, shorewall
[08:05] <cjwatson> as contrasted with ufw, presumably
[08:06] <doko_> ok, I'll re-add it to the seeds, with a comment
[08:06] <cjwatson> ... (I didn't think that was a decision)
[08:06] <doko_> oops
[08:06] <cjwatson> shorewall was in main up to gutsy, so I certainly have no objection to it being added back
[08:07] <doko_> once the bashims were fixed it looks rather stable
[08:07] <cjwatson> you removed it, I see
[08:07] <cjwatson>   - remove shorewall from server-ship (ufw is in main)
[08:07] <slangasek> it's not the killer firewall, but ufw isn't today either; and shorewall gives users functionality that ufw doesn't
[08:07] <doko_> yes, but it's still referenced in Kubuntu hardy
[08:07] <cjwatson> 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] <cjwatson> so I think we should ship it
[08:08]  * ArneGoetje is happily using shorewall on all my machines, including laptop :)
[08:08] <cjwatson> technically it should be a server team decision, mind you
[08:09] <doko_> I'll bring it to their attention
[08:10] <doko_> next: any actions about duplicates/unnecessary files on the CDs?
[08:10] <cjwatson> 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] <cjwatson> which would correspond to "use ufw in all cases, damn your eyes"
[08:11] <cjwatson> can we carry on discussing duplicates/unnecessary files on the list?
[08:11] <cjwatson> or perhaps on ubuntu-devel@, since it's currently distro-team@
[08:11] <cjwatson> just conscious that we're over time
[08:11] <doko_> fine with me, sending then to u-d
[08:11] <asac> 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] <asac> (or make curl depend on ca-certificates)
[08:12] <cjwatson> I'm sure we used to ship ca-certificates?
[08:12] <ogra> didnt we ship the before ?
[08:12] <asac> i think so ... i guess one rdepends got removed from cd
[08:12] <cjwatson> no objection to shipping them provided that its (crazy) debconf question doesn't get asked by default
[08:12] <cjwatson> unfortunately I suspect it does get asked by default on upgrades, worth checking its priority
[08:12] <asac> yes. afaik you don't get asked about that
[08:13] <asac> hmm ... really? i never saw any question. but maybe thats because the packages wasn't updated for a while
[08:13] <asac> i can check that
[08:13] <asac> thanks
[08:13] <cjwatson> I'm just going on vague memory, I'm afraid
[08:13] <cjwatson> ca-certificates was in dapper/desktop
[08:14] <cjwatson> dependency of libcurl3
[08:14] <cjwatson> apparently it fell out in gutsy
[08:14] <asac> hmmm ... libcurl3-gnutls has a recommends on it now
[08:15] <cjwatson> might have to duplicate that recommendation in the seeds, then, until such time as we do recommends-by-default
[08:15] <asac> yep
[08:15] <asac> thanks
[08:15] <cjwatson> which I think fell out of hardy because the ball was in too many people's courts
[08:15] <cjwatson> ok, 15 minutes over time, so let's adjourn
[08:15] <cjwatson> thanks all
[08:15] <TheMuso> Thanks.
[08:15] <asac> thanks all
[08:15] <slangasek> thanks
[08:15] <ogra> thanks
[08:15] <TheMuso> Minutes will be out tomorrow.
[08:16]  * asac hugs TheMuso 
[08:16] <bryce> thanks
[08:16] <cjwatson> great
[08:16] <ubotu> 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] <ArneGoetje> thanks
[08:18] <evand> thanks
[08:18] <calc> goodnight :)
[08:19] <cjwatson> sleep well, USians
[08:19]  * bryce zzz's
[08:19] <bryce> (early meeting tomorrow)
[08:21] <evand> heh, thanks
[12:04] <RichEd> hello ... who's here for the education meeting ?
[12:04]  * stgraber waves
[12:04] <RichEd> hi stgraber :)
[12:05]  * ogra_cmpc waves ... very tired
[12:06] <ogra_cmpc> only us three ?
[12:06] <RichEd> well apart from the passive lurkers ... looks like it
[12:07] <RichEd> let's whip through a tech status then ...
[12:07] <ogra_cmpc> 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] <ogra_cmpc> 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] <ogra_cmpc> and te edubuntu entry needs a proper short descritipon ...
[12:09] <RichEd> ahhh ..
[12:09]  * RichEd spots the delayed wave from Hobbsee all the way from oz
[12:10] <Hobbsee> RichEd: :)
[12:10] <ogra_cmpc> 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] <ogra_cmpc> gfxboot is a beast and takes more time than i want to understand it atm
[12:11] <ogra_cmpc> s/want/have/
[12:11] <ogra_cmpc> beyond that the cds should be pretty much in shape
[12:11] <ogra_cmpc> s/cds/cd/
[12:11] <ogra_cmpc> :D
[12:12] <ogra_cmpc> 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] <ogra_cmpc> 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] <ogra_cmpc> well, thats about it from the tech side
[12:14] <ogra_cmpc> i'd like to note that artwork freeze is tomorrow
[12:14] <RichEd> gimme a sec ... getting power
[12:14] <ogra_cmpc> which means we'll likely not have anything new in hardy
[12:15] <ogra_cmpc> and there are a bunch of edubuntu-doc bugs that need a helping hand (not sure if laserjock went over them already)
[12:15] <RichEd> is that an absolute art final, or is there a sneak it in route i've heard mentioned :)
[12:16] <ogra_cmpc> the artwork thing is quite bad btw ....
[12:16] <ogra_cmpc> no official one
[12:16] <ogra_cmpc> we have an LTS this time
[12:16] <RichEd> okay  ... and what time tomorrow is the freeze ?
[12:16] <ogra_cmpc> and that means the doc teams will want to have a fixed UI state for their screenshots etc
[12:16] <ogra_cmpc> there is no time
[12:17] <RichEd> so is the end of the day US time acceptable ?
[12:17] <ogra_cmpc> slangasek is our release manager ... he will call out the freeze at will
[12:17] <RichEd> i'll hav a word with him ... see how flexible he could be ...
[12:17] <ogra_cmpc> not sure what time he prefers, but he sits in US westcoast ...
[12:18] <ogra_cmpc> so rather late tomorrow i guess
[12:18] <ogra_cmpc> (i also think he"s more concerned about teh beta freeze than about artwork :) they are the same date this time)
[12:19] <RichEd> great ... even if we polish one of the alternates from the last round ... a different desktop for LTS would be good
[12:19] <ogra_cmpc> well, i dont see anything i'd like to ship in the alternates
[12:19]  * RichEd will drive that, and kep ogra_cmpc informed
[12:19] <ogra_cmpc> else i would have added one already during the dev cycle
[12:19] <ogra_cmpc> thanks :)
[12:19] <RichEd> let me touch sides with ideas tomorrow
[12:20] <RichEd> a couple of classmate questions for you, but i'll grab you later for that ... they are intel device specific
[12:20] <ogra_cmpc> ok
[12:20] <RichEd> stgraber: can you give me an update on iTalc ... with comments from ogra_cmpc about the odds of inclusion ?
[12:21] <ogra_cmpc> its in sinc4e we4eks
[12:21] <ogra_cmpc> oops
[12:21] <ogra_cmpc> its in since weeks
[12:21] <RichEd> 4sure
[12:21] <RichEd> :)
[12:21] <RichEd> excellemt
[12:21] <ogra_cmpc> i reported that three weeks ago or so in the meeting :)
[12:21] <stgraber> ogra_cmpc: is it on the add-on CD ?
[12:21] <ogra_cmpc> the client is even installed in the default classmate install now
[12:21] <RichEd> my head has been bent a bit of late ... may need reminders at times :)
[12:21] <RichEd> w00t re classmate :)
[12:22] <ogra_cmpc> stgraber, just in main yet, i havent done the last seed shuffle dance yet
[12:22]  * RichEd hands an ubuntu noddy badge to stgraber and ogra 
[12:22] <stgraber> btw, I pinged upstream a bit earlier and he'll see what he can do to give us a patch for the MMX and bug fixes
[12:23] <ogra_cmpc> do we have a bug with the patch already ? or only the mail you sent me ?
[12:23] <RichEd> stgraber: is upstream positive about our use of it and inclusion ?
[12:24] <stgraber> yes and he's helped me quite a lot for it
[12:24] <stgraber> ogra_cmpc: only the mail
[12:24] <RichEd> great ... cc me in the next mail to him, and i will extend our thanks
[12:24] <RichEd> please :)
[12:24] <ogra_cmpc> ok, we need a bug for pitti/slangasek then
[12:25] <stgraber> RichEd: sure
[12:25] <stgraber> ogra_cmpc: ok, I'll open one with the same info has I emailed you
[12:26] <ogra_cmpc> thanks a lot
[12:26] <RichEd> okay stgraber / ogra_cmpc / Hobbsee ... any other urgent issues ?
[12:27]  * RichEd does not have anything else to raise today ... need to get work done for meetings and freeze tomorrow
[12:27] <ogra_cmpc> same here
[12:27] <Hobbsee> RichEd: if you've got edubuntu-specific stuff to freeze, which doesn't affect the rest, you should be OK
[12:27] <stgraber> nothing from me
[12:27] <ogra_cmpc> and i had a 8am meeting already
[12:27] <RichEd> ogra_cmpc: can i grab you at the top of the hour for 15 / 20 mins ?
[12:27] <ogra_cmpc> (after 3h of sleep ...)
[12:27] <ogra_cmpc> sure
[12:28] <RichEd> anti-theft and other fiddly bits ... need an update
[12:28] <ogra_cmpc> lets see how much i can squeeze out of my brain still :)
[12:28]  * ogra_cmpc is curious about the fiddly bits 
[12:28] <RichEd> ogra_cmpc: if we add our two brains together, we may have at least half a decent one to chat with some sense
[12:29] <ogra_cmpc> heh
[12:29] <RichEd> the proprietary drive issues ... them fiddly bits
[12:29] <RichEd> *driver
[12:29] <ogra_cmpc> there are proprietary drivers ?
[12:29] <RichEd> sonic etc.
[12:29]  * ogra_cmpc wasnt aware and didnt plan anything ... 
[12:30] <RichEd> me repeats the call for issues ... and raises the gavel in anticipation
[12:30]  * RichEd looks around 
[12:30]  * RichEd counts to 10
[12:30] <RichEd> going once ...
[12:30] <RichEd> twice ...
[12:31] <RichEd> and that's a BONG and thanks ...
[12:31] <ogra_cmpc> thanks
[12:31] <RichEd> will be in the channel if needed
[13:19] <cjwatson> ogra_cmpc_: oh, you want LTSP on Edubuntu's modes menu?
[13:20] <ogra_cmpc_> cjwatson, in alternates modes menu
[13:20] <ogra_cmpc_> there is no edubuntu cd with ltsp anymore :)
[13:20] <cjwatson> err, right
[13:20] <cjwatson> ok, that should be easy
[13:20] <ogra_cmpc_> how freeze critical is that ?
[13:21] <cjwatson> it doesn't require a package upload, but we should still do it sooner rather than later
[13:21] <ogra_cmpc_> i would prefer to do it myself but i'm kneedeep in classmate stuff and wouldnt like to hibernate the enthusiasm
[13:21] <cjwatson> why don't I do it now and mail you the diff so that you can grok it
[13:21] <cjwatson> and then you get to do the next similar change :)
[13:21] <ogra_cmpc_> that would be great
[13:21] <ogra_cmpc_> thanks :)
[13:22] <ogra_cmpc_> another thing i thought about is the edubuntu cd ... cant we just drop the bootloader completely during build ?
[13:22] <cjwatson> we could, true
[13:22] <ogra_cmpc_> so the BIOS cares and we dont need to make up special artwork, translations etc
[13:22] <cjwatson> it would be a bit unhelpful but possibly better than a bootloader that doesn't work
[13:23] <ogra_cmpc_> right
[13:23] <ogra_cmpc_> and making it pretty is a bit more work imho ...
[13:28] <cjwatson> ogra_cmpc_: ok, both done
[13:29] <ogra_cmpc_> thanks, that takes some pressure away
[13:40] <nand> #ubuntu-testing
[13:40] <nand> :}
[16:00] <pedro_> hello hello
[16:00]  * Iulian waves
[16:00] <ogasawara> hi
[16:00] <pedro_> hey Iulian, hello ogasawara
[16:00] <liw_> heippa
[16:00] <pedro_> hola liw_
[16:01] <nand> bonjour!
[16:01] <bdmurray> howdy
[16:01] <pedro_> salut
[16:01] <heno> hello!
[16:02] <Iulian> Hiya
[16:02]  * stgraber waves
[16:02] <heno> My system just died a minute ago, had to reboot :(
[16:03] <heno> I'll need to investigate that after the meeting
[16:03] <heno> bdmurray, ogasawara: here?
[16:03] <bdmurray> ype
[16:03] <ogasawara> heno: yup
[16:03] <heno> ok
[16:04] <heno> #startmeeting
[16:04] <MootBot> Meeting started at 16:04. The chair is heno.
[16:04] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:04] <heno> not many agenda items today: https://wiki.ubuntu.com/QATeam/Meetings
[16:05] <heno> [TOPIC] Beta testing preparations
[16:05] <MootBot> New Topic:  Beta testing preparations
[16:05] <heno> davmor2 and I met on Saturday to talk about Beta+ testing
[16:06] <heno> I've drawn up a proposed schedule here https://wiki.ubuntu.com/Testing/ISO/Schedule
[16:07] <heno> according to which testing starts tomorrow
[16:08] <heno> I'll write the distro team about contributing and blog as well
[16:08] <heno> I'll be asking for help mostly toward the end --  ISO validation testing - March 18-19
[16:09] <heno> ok, next
[16:09] <heno> [TOPIC] Testing wiki pages refreshed - please review
[16:09] <MootBot> New Topic:  Testing wiki pages refreshed - please review
[16:10] <heno> that's mostly done. We still need to update some test cases
[16:10] <heno> I'll post to the QA list regarding new features that we should cover
[16:11] <bdmurray> I've been looking at the pages a bit this morning
[16:11] <liw_> the update is done, or the review is done?
[16:11] <heno> update
[16:11] <liw_> so it's still good to review, check
[16:12] <heno> I've been looking at http://www.ubuntu.com/testing for ideas for new test cases.
[16:12] <heno> But further suggestions are welcome
[16:12] <bdmurray> Does the FixValidation page overlap a lot with FixesToVerify?
[16:13] <heno> bdmurray: not really
[16:13] <heno> FixValidation is supposed to be bugs fixed since the milestone freeze
[16:14] <heno> so in the past 2-3 days at that point
[16:14] <bdmurray> okay
[16:14] <heno> making sure that code we _just_ touched didn't break anything
[16:15] <heno> both are useful to test from in that period though
[16:15] <heno> bdmurray: thanks, I should clarify that on the page
[16:16] <heno> so, please look the pages over for sanity and readability
[16:16] <heno> that should cover that topic
[16:17] <heno> bdmurray: how has your yesterday page been working?
[16:17] <bdmurray> It has been interesting to me at least.
[16:17] <heno> also an interesting page is http://daniel.holba.ch/really-fix-it/
[16:17] <ogasawara> I was going through the really-fix-it kernel bugs yesterday
[16:18] <heno> bdmurray: perhaps you can get the progress meter from there
[16:18] <bdmurray> heno: that's an interesting idea
[16:18] <heno> I looked at the abiword bugs and it seems they will all stay on the list
[16:19] <heno> they are fixed upstream in v. 2.6 which I don't think we'll get until intrepid
[16:20] <pedro_> right, bumping to 2.6 wouldn't be nice at this stage...
[16:20] <heno> There should perhaps be a way of marking such bugs as 'have-looked-at-not-for-hardy' <- dholbach
[16:23] <heno> any other topics today?
[16:23] <bdmurray> heno: Have you been looking at Hardy nominations at all?
[16:23] <heno> bdmurray: no I haven't
[16:24] <bdmurray> Maybe we should review those again.
[16:24] <heno> bdmurray: do you have the URL handy?
[16:24] <dholbach> heno: not very easy to do
[16:25] <heno> https://edge.launchpad.net/ubuntu/hardy/+nominations
[16:25] <bdmurray> heno: https://bugs.launchpad.net/ubuntu/hardy/+nominations
[16:25] <bdmurray> ;)
[16:26] <heno> dholbach: with a tag perhaps and mark it on the list with an * ?
[16:26] <dholbach> or milestone it as 'later'?
[16:26] <heno> that'll work
[16:26] <dholbach> ok, I'll document that on the page and filter them out
[16:27] <heno> so the nomination list is long again :)
[16:27] <bdmurray> Couldn't we get an Ibex milestone setup rather than using Later?
[16:27] <heno> dholbach: cool!
[16:27] <bdmurray> Because they would just need to move from later to Ibex
[16:27] <liw_> Ibex?
[16:28] <bdmurray> liw_: Intrepid?
[16:28] <stgraber> intrepid
[16:28] <liw_> ah, right
[16:28] <heno> so how do we triage the nominated bugs at this stage? Milestone the serious looking ones?
[16:28] <bdmurray> and the In Progress ones. ;)
[16:29] <heno> that would bring it onto the lists the developers and release managers look at
[16:29] <heno> my guess is there is already a fair bit of overlap
[16:30] <heno> ok, let's all have a look at the list and reduce it a bit for the next meeting
[16:30] <heno> then we'll have a better idea of what it contains
[16:31] <heno> bdmurray: thanks for bringing that up
[16:31] <bdmurray> Sounds good.  Who should we speak to about adding an Intrepid milestone?
[16:32] <heno> bdmurray: any LP admin I think, so kiko or mdz for example
[16:32] <heno> bdmurray: will you take that?
[16:32] <heno> I'll make a start on nominations today
[16:32] <bdmurray> heno: okay, I'm pretty sure we have the power I'm not certain on the procedure
[16:33] <bdmurray> anyway I'll look into it
[16:33] <heno> likely not documented on the LP wiki
[16:33] <heno> thanks
[16:33] <heno> anything else?
[16:35] <heno> ok, thanks everyone!
[16:35] <heno> #endmeeting
[16:35] <MootBot> Meeting finished at 16:35.
[16:36]  * heno goes digging in logs to find out why his computer crashed earlier
[16:36] <liw_> heno, just in case it's memory, you may want to run memtest86+ from the grub menu, for at least 12 hours, preferably 24
[16:37] <heno> liw_: that is a good candidate, yes
[19:00] <keescook> @now utc
[19:00] <ubotu> Current time in Etc/UTC: March 12 2008, 19:00:22 - Next meeting: Server Team in 1 hour 59 minutes
[19:00] <keescook> #startmeeting
[19:00] <MootBot> Meeting started at 19:00. The chair is keescook.
[19:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:00] <keescook> [topic] introductions
[19:00] <MootBot> New Topic:  introductions
[19:00]  * propagandist waves
[19:00] <keescook> okay, are people here for the security team meeting?  :)  hi propagandist
[19:01] <keescook> [link] https://wiki.ubuntu.com/SecurityTeam/Meeting
[19:01] <MootBot> LINK received:  https://wiki.ubuntu.com/SecurityTeam/Meeting
[19:01] <keescook> there is the agenda for today's meeting
[19:01] <emgent> @schedule rome
[19:01] <ubotu> Schedule for Europe/Rome: 12 Mar 22:00: Server Team | 14 Mar 21:00: MOTU | 14 Mar 22:00: REVU Coordination | 19 Mar 22:00: Server Team | 26 Mar 22:00: Server Team
[19:01] <emgent> hi keescook
[19:02] <keescook> heya emgent
[19:02] <keescook> looks like joejaxx isn't here, but I'd like to still cover the TODO list/Roadmap
[19:02] <emgent> jdstrand, :)
[19:02] <keescook> is anyone from motu-swat here to do membership stuff for that team?
[19:03]  * jdstrand got confused with the recent change to EDT
[19:03] <keescook> well, and I tried to trick every one by moving it an hour in UTC too.  :P
[19:04] <jdstrand> very sneaky indeed
[19:05] <keescook> Fujitsu: are you here?  (ScottK, Nafallo, and sistypot aren't -- the other motu-swat admins)
[19:05] <keescook> okay, well, I'll mark the motu-swat agenda item as postponed for now.
[19:06] <keescook> alright, moving forward...
[19:06] <keescook> [topic] CVE review
[19:06] <MootBot> New Topic:  CVE review
[19:06] <keescook> the only item I have here is to call attention to the -proposed version of mysql that jdstrand prepared.
[19:07] <jdstrand> hey I was going to do that
[19:07] <keescook> have at it.  :)
[19:07] <keescook> [link] https://lists.ubuntu.com/archives/ubuntu-devel/2008-March/025173.html
[19:07] <MootBot> LINK received:  https://lists.ubuntu.com/archives/ubuntu-devel/2008-March/025173.html
[19:07] <jdstrand> the bug is #201009
[19:07] <jdstrand> bug #201009
[19:07] <ubotu> Launchpad bug 201009 in mysql-dfsg-5.0 "[mysql-dfsg-5.0] fix for several open vulnerabilities in -proposed" [High,Fix committed] https://launchpad.net/bugs/201009
[19:08] <jdstrand> we need testing of the -proposed packages with feedback put in that bug
[19:08] <keescook> anyone running mysql that can give it a go?
[19:08] <jdstrand> the summary is that there were several CVEs that are fixed, but two of them, CVE-2007-6303 and CVE-2007-2692 were fairly intrusive
[19:08] <ubotu> MySQL 5.0.x before 5.0.51a, 5.1.x before 5.1.23, and 6.0.x before 6.0.4 does not update the DEFINER value of a view when the view is altered, which allows remote authenticated users to gain privileges via a sequence of statements including a CREATE SQL SECURITY DEFINER VIEW statement and an ALTER VIEW statement. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6303)
[19:08] <ubotu> The mysql_change_db function in MySQL 5.0.x before 5.0.40 and 5.1.x before 5.1.18 does not restore THD::db_access privileges when returning from SQL SECURITY INVOKER stored routines, which allows remote authenticated users to gain privileges. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2692)
[19:09] <jdstrand> you go ubotu
[19:09] <jdstrand> anyhoo, the packages have gone through quite a bit of testing already and are in good shape as far as I can tell, but it be nice to get more testing
[19:10] <jdstrand> dapper - feisty primarily
[19:10] <sdh> oops, hi
[19:10] <jdstrand> gutsy is close enough to upstream that it wasn't affected be these
[19:10] <jdstrand> that came out weird
[19:11] <jdstrand> gutsy isn't affected by those
[19:11] <jdstrand> heh
[19:11] <jdstrand> ok, that was wrong
[19:11] <keescook> heh :)
[19:12] <jdstrand> gutsy is affected by 6303, but is close enough to the current upstream that its patch wasn't intrusive
[19:12]  * jdstrand tried to be too brief in his summary
[19:12] <keescook> cool.  so, anyone listening, please enable -proposed and give some feedback.  :)
[19:12] <keescook> any other CVE issues people want to bring up?
[19:13] <keescook> [topic] Contributing to ubuntu-cve-tracker
[19:13] <MootBot> New Topic:  Contributing to ubuntu-cve-tracker
[19:14] <keescook> okay, so, the Ubuntu CVE tracker is used to ... track CVEs
[19:14] <keescook> [link] https://launchpad.net/ubuntu-cve-tracker
[19:14] <MootBot> LINK received:  https://launchpad.net/ubuntu-cve-tracker
[19:15] <keescook> we're all doing lots of CVE updates, and I'd like to have more people from motu-swat reviewing the open CVEs
[19:15] <keescook> Fujitsu did a few great passes at it, but it still needs more work
[19:15] <keescook> the process is fairly well documented in the README
[19:15] <keescook> [link] http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/files
[19:15] <MootBot> LINK received:  http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/files
[19:15] <jdstrand> in addition to getting it up to date, ubuntu-cve-tracker is the main method we use to coordinate wok on the CVEs
[19:16] <keescook> before the next meeting, I'll make sure we have a published "open CVE" list so it's easier for people to see the work
[19:16] <keescook> [action] keescook to get HTML publication finalized
[19:16] <MootBot> ACTION received:  keescook to get HTML publication finalized
[19:16] <jdstrand> it is important that if we are preparing updates that we check ubuntu-cve-tracker to see if the CVE is assigned to someone, so there isn't duplicate work
[19:17] <jdstrand> (this happened recently)
[19:17] <keescook> emgent: have you had a chance to check out a branch of this?
[19:17] <jdstrand> if it's assigned to someone, then ping that person to see what's going on
[19:17] <emgent> yep
[19:17] <emgent> i use this for working
[19:18] <keescook> emgent: cool.  if you have any changes, please push up a branch and we can merge in your updates
[19:18] <emgent> ok i will do.
[19:18] <jdstrand> seems that is the best way to go
[19:18] <keescook> okay... moving on
[19:18] <keescook> [topic] To-Do List (Expanding our Roadmap)
[19:18] <MootBot> New Topic:  To-Do List (Expanding our Roadmap)
[19:19] <keescook> [link] https://wiki.ubuntu.com/SecurityTeam/Roadmap
[19:19] <MootBot> LINK received:  https://wiki.ubuntu.com/SecurityTeam/Roadmap
[19:19] <jdstrand> motu-swat people check out their branch, keep it up to date with master, and keescook and I will pull in the changes
[19:19] <jdstrand> lp has a way to request a merge that makes it very convenient
[19:19] <keescook> I'd like to see more things listed on the ST roadmap :)
[19:19] <jdstrand> Fujitsu did that the other day and it worked great
[19:20] <keescook> if people have ideas about stuff they want to work on, please add it to the roadmap.
[19:20] <jdstrand> yikes, I didn't think we were done with u-c-t yet
[19:20] <keescook> I'd love to get all the non-exec stack bugs closed, too.
[19:20] <keescook> jdstrand: np, it was kind of a short topic -- not a big group today
[19:21] <keescook> [action] keescook to add non-exec stack bug list to roadmap
[19:21] <MootBot> ACTION received:  keescook to add non-exec stack bug list to roadmap
[19:21] <emgent> :)
[19:21] <keescook> anyone have anything else they want to see on the TODO list?
[19:22] <emgent> not now, for me
[19:22] <jdstrand> though it overlaps with the server team
[19:22] <jdstrand> I think apparmor profiles would be great
[19:22] <keescook> one idea I had was to add a "wishlist" section to the roadmap, and point anyone there that had ideas they wanted to see implemented.
[19:22] <keescook> ooh, yeah
[19:23] <gaten> what about something like a bastille script for ubuntu??
[19:23] <keescook> I don't mind having TODO items duplicated between teams -- more chance people will work on it :)
[19:23] <jdstrand> while I haven't tried it, wouldn't Debian's bastille work fine on ubuntu?
[19:24] <keescook> I'd also like to add "build FAQ" to the TODO list
[19:24] <gaten> +1 for the wishlist
[19:24] <jdstrand> I like the wishlist idea too
[19:24] <emgent> +1 too
[19:25] <gaten> jdstrand: quite possible. sounds like a TODO
[19:25] <mathiaz> keescook: one of the problem with a whishlist section in the Roadmap is that it can become a long landry list
[19:25] <keescook> mathiaz: true.  I figure if it gets that way, we can move it to another page.
[19:25] <mathiaz> keescook: That's why the server Team has a IdeaPool page that is separate from the Roadmpa
[19:25] <gaten> jdstrand: but i would like to see a hardened default config
[19:26] <mathiaz> keescook: the desktop team has a vision wiki page for long term and todo for short trem
[19:26] <keescook> gaten: "hardened" means so many things.  what parts did you have in mind?
[19:26] <mathiaz> keescook: and people tend to start discussing things under the wishlist point
[19:27] <keescook> mathiaz: I'm all for generating discussion.  any significantly large discussion can be turned into a Blueprint.  :)
[19:27] <gaten> keescook: the basics first. umask, ulimit, read access to logs etc
[19:28] <gaten> and i would like to see a firewall thats enabled and has some actual rules on by default.
[19:28] <sdh> agreed on firewall
[19:29] <keescook> gaten: some of that already exists -- it's be great to document a checklist.  Can you write a wiki page for that, and link to it in the Wishlist section?
[19:29] <jdstrand> gaten: not sure if you are referring to ufw there, but after an install, a simple 'sudo ufw enable' and you've got a good host-based firewall
[19:29] <keescook> (I've added Wishlist and FAQ to the Roadmap now)
[19:29] <gaten> keescook: sure. when will this whislist be available?
[19:29] <gaten> ahh, nvm
[19:30] <keescook> also, I'd like to see the "KnowledgeBase" link to something useful.
[19:30] <gaten> jdstrand: ahh, wasn;t aware it shipped w/ rules available. but it should still be part of the setup, like 'Do you want to enable the firewall on startup'
[19:30] <keescook> I figure lists of links to other information could be handy there (oss-security link, CVE tracker link, you name it)
[19:31] <gaten> another item I have brought up on the list-server but have done nothing about: chrooted packages (ie apt-get install LAMP-chroot)
[19:32] <jdstrand> gaten: that is a hard problem and very site-specific
[19:32] <jdstrand> however, the 'M' in LAMP is now in apparmor enforcing mode
[19:32] <keescook> :)
[19:33] <jdstrand> gaten: I have been thinking about how to deal with 'A'
[19:33] <gaten> jdstrand: what about using bind-chroot as a stepping stone? and another thing, does chroot become moot if apparmor/selinux are implimented?
[19:33] <jdstrand> gaten: re> chroot moor -- basically yes
[19:33] <keescook> gaten: depends ... I'd say that might be true if kvm/xen are used too
[19:33] <jdstrand> gaten: you get a lot of pain for little gain
[19:33] <keescook> some people use chroots to split up service configs.  *shrug*
[19:33] <gaten> well apache is the easiest to chroot of em all, and there are so many scripts out there for it. also you've got mod-chroot if you wanna take the easy way out, still don't think its as secure though
[19:34] <jdstrand> gaten: and it isn't apache that is the problem, it is wirtual hosting and added packages
[19:34] <jdstrand> virtual even
[19:34] <gaten> yes, and updating. ive played that game before
[19:34] <jdstrand> me too
[19:34] <jdstrand> which is why apparmor and selinux can help quite a bit here
[19:35] <gaten> which is why i have wet dreams of apt-get update lam-chroot ;)
[19:35] <keescook> hehe
[19:35] <emgent> hahha
[19:35] <keescook> okay, move on?
[19:35] <gaten> ok, so hold off on that for now then
[19:35] <jdstrand> however, more thought needs to be done on the packaging of the added software and dealing with virtual hosts in a sane way that is easy to profile
[19:35] <keescook> we're skipping MOTU-SWAT membership since we lack any motu-swat admins
[19:35] <jdstrand> gaten: it is absolutely an idea though, feel free to add it :)
[19:35] <keescook> [topic] SELinux progress
[19:36] <MootBot> New Topic:  SELinux progress
[19:36] <keescook> propagandist: all yours
[19:36] <propagandist> hey everyone
[19:36] <propagandist> A new bug fix release of SETools was released today which includes transitional packages (and should resolve the major complaint with the last FFE request).
[19:36] <keescook> excellent
[19:36] <keescook> oh, ubotu just left
[19:36] <propagandist> An official release of SELinux was done last week as well.
[19:37] <keescook> for the logs, setools FFe is bug 198391
[19:37] <propagandist> I'll be integrating these into the packages and reposting to REVU.
[19:37] <keescook> propagandist: ah! that's good news.  I'm glad to see that SELinux release.
[19:37] <propagandist> for SETools that means updating the ffe as well
[19:37] <propagandist> for the rest of them do I need to do an FFE?
[19:37] <propagandist> keescook: ;o}
[19:37] <keescook> propagandist: is it a new upstream version?  if so, yes.
[19:38] <keescook> what do we gain by updating SELinux?
[19:38] <keescook> [link] https://launchpad.net/bugs/198391
[19:38] <MootBot> LINK received:  https://launchpad.net/bugs/198391
[19:38] <jdstrand> is this 3.3.4 or a more major update?
[19:39] <propagandist> not too much I would think
[19:39] <propagandist> its 3.3.4
[19:39] <jdstrand> as this FFE isn't accepted yet, could it just be updated?
[19:39] <propagandist> the upstream selinux ones would only have the advantage of using an official release (but they are basically the same as what we have now)
[19:40] <keescook> propagandist: if the changelog is small, I'm for it, just to be on a "known" release version.
[19:40] <propagandist> jdstrand: yes for setools, i will update the ffe
[19:40] <keescook> [link] http://www.nsa.gov/selinux/code/download-trunk.cfm
[19:40] <MootBot> LINK received:  http://www.nsa.gov/selinux/code/download-trunk.cfm
[19:40] <keescook> I see it's at 2.0.59
[19:41] <propagandist> yup and we are curretly on 2.0.55
[19:41] <keescook> propagandist: so, beyond those things, how is SELinux on Hardy for you guys?  Has it tested out well?
[19:42] <propagandist> keescook: it looks good to me, there is still a mislabeled cups file i need to fix, and some upgrade problems with sepolgen, but in general it looks good
[19:43] <propagandist> keescook: of course I will be fixing those -^
[19:43] <keescook> propagandist: okay -- beta freeze starts tomorrow IIRC, so I'd recommend focusing on bug fixes first, then FFe later -- the FFes might not get through :)
[19:43] <propagandist> keescook: kk
[19:43] <propagandist> anyone else  had a chance to poke at it?
[19:44] <keescook> I booted it once found myself in unconfined X11 session, but it all appears to be running.
[19:44] <keescook> I haven't tried the relabeling since the fsck/usplash integration work was finished.
[19:44] <keescook> I think it'll just look like a regular fsck
[19:45] <keescook> ajmitch, siretart: you guys here?  have you played with SELinux in Hardy yet?
[19:46] <keescook> propagandist: did you reproduce the unconfined X session, or do I just have a weird install?
[19:46] <propagandist> keescook: I haven't been able to reproduce it :(
[19:47] <keescook> heh, okay.  I'll give it another shot now that I've got kvm running sanely.
[19:47] <keescook> alright, shall we move on?
[19:47] <propagandist> keescook: but maybe i'm misunderstanding because you should be unconfined_t
[19:47] <keescook> oh, that's what I was seeing
[19:47] <propagandist> ah
[19:47] <propagandist> ;o} well all is good then
[19:47] <mathiaz> propagandist: keescook you may wanna ask on ubuntu-hardened for more selinux testing on hardy
[19:47] <keescook> I'm still an SENewb :)
[19:48] <propagandist> ;o}
[19:48] <propagandist> mathiaz: will do
[19:48] <keescook> mathiaz: good idea
[19:48] <mathiaz> and add ubuntu-server@lists.ubuntu.com in the game also
[19:48] <keescook> [action] propagandist to bring up SELinux testing on u-hardened and u-server lists
[19:48] <MootBot> ACTION received:  propagandist to bring up SELinux testing on u-hardened and u-server lists
[19:49] <propagandist> kk, i'm all out of status
[19:50] <keescook> okay...  Selinux gui utils is skipping (joejaxx is gone)
[19:50] <keescook> er, skipped
[19:50] <keescook> [topic] Hardening Wrapper testing
[19:50] <MootBot> New Topic:  Hardening Wrapper testing
[19:50] <keescook> so, I recompiled all of "main" will the wrappers enabled.
[19:51] <keescook> I tried full, no-pie, and no-hardening.
[19:51] <keescook> overall, the results were good
[19:51] <keescook> [link] http://people.ubuntu.com/~kees/hardening/
[19:51] <MootBot> LINK received:  http://people.ubuntu.com/~kees/hardening/
[19:51] <keescook> I have all the build logs saved
[19:51] <keescook> but I threw out the .debs since I didn't have space for it
[19:52] <keescook> if people are interested in going through the "ok-nohardening.txt" file to figure out what's failing, and opening bugs for it, that would rock
[19:52] <keescook> (same goes for ok-nopie.txt, but those are likely a bit trickier)
[19:52] <jdstrand> keescook: did you get a chance to try the rebuild with the i386 personality?
[19:53] <keescook> jdstrand: oh!  no, I didn't.
[19:53] <keescook> I will start one up over the weekend.
[19:53] <gaten> keescook: do we have a priority for certain packages in nohardening?
[19:53] <keescook> I'm also considering generating a PPA that is exclusively hardened builds.

[19:54] <keescook> gaten: no real priority -- my goal is to have those two text files be 0 length by the end of intrepid.  :)
[19:54] <keescook> but I know it's going to be a lot of work.
[19:54] <gaten> heh, roger that
[19:54] <keescook> I want to run the PPA idea past the soyuz folks so I don't get poked in the eye :)
[19:55] <siretart> keescook: re selinux in hardy: yes, at my departmend we had a course (a week fulltime) were two students played with selinux in hardy
[19:56] <keescook> a concern brought up on the Debian devel mailing list is one of performance.  All the measurements I've done show less than 1% loss for PIE
[19:56] <keescook> siretart: the new stuff that tresys has worked on?
[19:56] <siretart> exactly. I instructed them to use the ubuntu-hardened PPA
[19:56] <keescook> PIE> I am not a statistician.  :)
[19:56] <keescook> siretart: cool!
[19:57] <propagandist> siretart: !!
[19:57] <siretart> the objective was writing 2 policy modules: one for mt-daapd and one for boxbackup
[19:57] <propagandist> siretart: awsome :o} how did it go?
[19:57] <siretart> propagandist: the __sns__ guy was one of the two students, you remember? ;)
[19:57] <siretart> both were successfully
[19:57] <siretart> some tools behaved a bit strange compared to fedora
[19:58] <propagandist> oh? which ones?
[19:59] <siretart> IIRC adding new selinux users, and listing selinux users. it looked like ubuntu had a different version of the tools or something
[20:00] <siretart> I have to admit that I don't remember exactly
[20:00] <propagandist> ah i see
[20:00] <jdstrand> siretart: how long ago was this?
[20:00] <siretart> 18.2.2008-22.2.2008
[20:00] <siretart> was that course
[20:02] <keescook> emgent had to leave early due to stuff out of his control, so he asked that his topics be postponed
[20:03] <jdstrand> well, seems the selinux reprise is over
[20:03] <siretart> anyways, I had a rather good impression of selinux in ubuntu
[20:03] <keescook> \o/
[20:03] <propagandist> siretart: thanks for the feedback :o} its great to hear that it worked for them
[20:03] <jdstrand> keescook: has there been any more discussion of enabling hardening-wrapper on specific packages
[20:03] <jdstrand> ?
[20:03] <siretart> what was most surprising is that the "new" unconfined module in ubuntu was behaving very differently than most documentation out there
[20:04] <jdstrand> keescook: ie what I added to the Roadmap?
[20:04] <jdstrand> I admit I haven't done anything with it
[20:04] <siretart> e.g. we didn't manage to get the gpg module work in ubuntu at all
[20:04] <keescook> jdstrand: there hasn't been -- I've been waiting to get feedback from doko about the hardened builds.
[20:04]  * jdstrand nods
[20:04] <keescook> for us to build stuff with hardening enabled vi Build-Deps (not the buildds) we'd need to promote hardening-wrapper to main, etc
[20:05] <siretart> I think what's needed here most is more documentation/explanation how the unconfined module is supposed to work in ubuntu.
[20:06] <keescook> jdstrand: so, at least we could provide PPAs for hardened builds too.
[20:07] <jdstrand> keescook: that would be a good alternative.  I'm just really excited about hardening wrapper and thinking about how this is an LTS release
[20:07] <NthDegree> yes indeed siretart
[20:07] <propagandist> siretart: kk, i'll look at adding it to the wiki, if you can send me more information on the problems you had getting gpg working that will help
[20:07] <keescook> jdstrand: yeah, I wish it could have happened earlier, but this is how it worked out.  :(
[20:07] <doko> keescook: yeah ...
[20:08] <keescook> doko: oh! hey there.  :)
[20:09] <NthDegree> just to satisfy my curiosity:  how is unconfined going to handle mprotect ideally?
[20:10] <doko> keescook: just found me doing uploads for reports assigned to some k...c...
[20:11] <keescook> doko: oh?
[20:11] <siretart> propagandist: well, afaiu, the gpg module is not supposed to run from the unconfined role, and a role transition was neccessary to do that. I think a small howto or example module or something how to enable the gpg module for 'normal' users would be a great example!
[20:11] <propagandist> NthDegree: Can you clarify?
[20:11] <NthDegree> propagandist: preventing execstack, execmem, execmod etc.
[20:12] <NthDegree> Fedora prevents that in normal "unconfined".. will Ubuntu have it the reverse way?
[20:12] <NthDegree> as in tagging apps gradually that can safely be restricted, and leaving the rest truly unrestricted
[20:15] <keescook> say, let's move the selinux discussion to #ubuntu-hardened, and I can close up this meeting.  :)
[20:15] <keescook> we've got no more topics
[20:15] <propagandist> kk :o}
[20:15] <keescook> [topic] schedule
[20:15] <MootBot> New Topic:  schedule
[20:15] <keescook> next meeting in two weeks, same time?
[20:15] <jdstrand> good with me
[20:16]  * jdstrand will be sure to remember his timezone next time
[20:16] <keescook> heh
[20:16] <keescook> okay, thanks very much everyone!  great work all around.  :)
[20:16] <keescook> #endmeeting
[20:16] <MootBot> Meeting finished at 20:16.
[20:17] <jdstrand> thanks keescook!
[20:17] <gaten> thanks all
[20:17] <keescook> :)
[20:22]  * faulkes- whistles innocently
[20:26] <zul> @schedule montreal
[20:26] <ubotu> Schedule for America/Montreal: 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
[20:45] <txwikinger> @schedule
[20:45] <ubotu> Schedule for Etc/UTC: 12 Mar 21:00: Server Team | 14 Mar 20:00: MOTU | 14 Mar 21:00: REVU Coordination | 19 Mar 21:00: Server Team | 26 Mar 21:00: Server Team
[20:58]  * mathiaz gets ready for the server team meeting...
[20:58] <ivoks> hi
[20:59] <sommer> o//
[20:59] <jdstrand> hi!
[20:59] <owh> hiya
[21:00] <soren> Hi, guys.
[21:00]  * nealmcb waves
[21:00]  * nijaba waves
[21:01] <nealmcb> sommer: I just made some changes to https://help.ubuntu.com/community/ServerGUI
[21:01] <owh> nijaba: Updated the launch text a few moments ago.
[21:01] <mathiaz> Let's get started for this week meeting
[21:01] <mathiaz> #startmeeting
[21:01] <MootBot> Meeting started at 21:01. The chair is mathiaz.
[21:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:01] <sommer> nealmcb: cool
[21:01] <dendrobates> o/
[21:01] <mathiaz> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[21:02] <mathiaz> [TOPIC] Review ACTION points from previous meeting.
[21:02] <MootBot> New Topic:  Review ACTION points from previous meeting.
[21:02] <mathiaz> https://wiki.ubuntu.com/MeetingLogs/Server/20080305
[21:03] <mathiaz> So I've sent an email about the ServerTestingTeam
[21:03] <mathiaz> And I've noticed that some new pages were created in the wiki
[21:03] <mathiaz> Again - anyone that has some server hardware available is welcome to test drive hardy.
[21:04] <mathiaz> [TOPIC] Server survey
[21:04] <MootBot> New Topic:  Server survey
[21:04] <mathiaz> The reportingpage has been updated
[21:04] <mathiaz> https://wiki.ubuntu.com/ServerTeam/ReportingPage
[21:04]  * soren blushes as he realises he hasn't sent anything for that page :(
[21:05] <mathiaz> nijaba: any news on the hosting front ?
[21:05] <owh> soren: You could have updated it and blamed it on "caching" :)
[21:05] <nijaba> we are waiting for an audit from kees
[21:05] <nijaba> it should be done soon
[21:06] <soren> owh: Encouraging dishonesty? Tsk, tsk :)
[21:06] <mathiaz> [TOPIC] iSCSI support
[21:06] <MootBot> New Topic:  iSCSI support
[21:06] <soren> I talked to Rick.
[21:06] <mathiaz> soren: did you have a change to talk with steve about root fs support ?
[21:06] <soren> We decided we wanted to do it.
[21:06]  * keescook ran out of time last friday.
[21:07] <soren> I e-mailed slangasek asking if it was ok. I haven't heard back.
[21:07] <nijaba> \o/
[21:07] <faulkes-> evening
[21:07] <soren> This was Friday, I believe. I should poke him some more.
[21:07] <mathiaz> soren: that would be post-beta work I guess
[21:08] <mathiaz> [ACTION] soren to talk with slangasek about iSCSI support for root fs.
[21:08] <MootBot> ACTION received:  soren to talk with slangasek about iSCSI support for root fs.
[21:09] <mathiaz> [TOPIC] Bacula status
[21:09] <MootBot> New Topic:  Bacula status
[21:09] <ivoks> hi
[21:09] <mathiaz> ivoks: what's the state of your work on that ?
[21:09] <ivoks> it needs one day of work
[21:10] <ivoks> tomorrow it will be ready for inspection
[21:10] <mathiaz> ivoks: great
[21:11] <mathiaz> who can do the inspection ?
[21:11] <ivoks> if someone want to see debdiff, http://www.grad.hr/~ivoks/bacula.diff
[21:11] <nijaba> beta freeze starts tomorrow
[21:11] <sommer> so is bacula going to make it into main?
[21:11] <mathiaz> probably not before beta
[21:11] <ivoks> ok, then it will be finished in couple of hours
[21:11] <nijaba> we have yet to file a mir, though...
[21:11] <sommer> for hardy release?
[21:12] <ivoks> debdiff is already over 1000 lines
[21:12]  * zul cries
[21:12] <sommer> either way I was just wondering if we should add a section to the docs or not?
[21:12] <ivoks> zul: it's not that bad :)
[21:13] <mathiaz> considering that we're changing a lot of the packaging, we should ask for FFexception
[21:13] <mathiaz> or should it be considered as just bug fixes ?
[21:14] <nijaba> these are mainly bug fixes to match requirements, IIRC
[21:14] <ivoks> there are also new features
[21:14] <ivoks> like new catalog_backup script
[21:15] <mathiaz> isn't that a fix for the security issues raised ?
[21:15] <ivoks> it is
[21:15] <ivoks> anyway... i'll finish it in couple of hours
[21:16] <nijaba> so it is a bug fix ;)
[21:16] <mathiaz> anyway - since the diff seems large, it may worth asking for a FFe to the motu-release team
[21:16] <mathiaz> zul: can you review the bacula diff ?
[21:16] <zul> mathiaz: sure..
[21:16] <mathiaz> zul: and figure out whether a FFe is needed or not
[21:17] <zul> I can do it tomorrow
[21:17] <mathiaz> [ACTION] ivoks to post an updated debdiff for bacula
[21:17] <MootBot> ACTION received:  ivoks to post an updated debdiff for bacula
[21:17] <mathiaz> [ACTION] zul to review the bacula debdiff
[21:17] <MootBot> ACTION received:  zul to review the bacula debdiff
[21:17] <mathiaz> [TOPIC] mysql testing
[21:17] <MootBot> New Topic:  mysql testing
[21:17] <mathiaz> jdstrand: what did you do to mysql ?
[21:18] <ivoks> zul: i'll be online, so contact me if you have questions
[21:18] <jdstrand> I have been preparing a security update for mysql
[21:18] <zul> ivoks: sure thanks
[21:18] <jdstrand> there are several issues that are addressed
[21:18] <jdstrand> 2 required a rather substantial patch
[21:19] <jdstrand> all of this is documented in bug #201009
[21:19] <ubotu> Launchpad bug 201009 in mysql-dfsg-5.0 "[mysql-dfsg-5.0] fix for several open vulnerabilities in -proposed" [High,Fix committed] https://launchpad.net/bugs/201009
[21:19] <jdstrand> the short summary is that CVE-2007-6303 and CVE-2007-2692 required quite a bit of work to fix dapper - feisty
[21:19] <ubotu> MySQL 5.0.x before 5.0.51a, 5.1.x before 5.1.23, and 6.0.x before 6.0.4 does not update the DEFINER value of a view when the view is altered, which allows remote authenticated users to gain privileges via a sequence of statements including a CREATE SQL SECURITY DEFINER VIEW statement and an ALTER VIEW statement. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6303)
[21:19] <ubotu> The mysql_change_db function in MySQL 5.0.x before 5.0.40 and 5.1.x before 5.1.18 does not restore THD::db_access privileges when returning from SQL SECURITY INVOKER stored routines, which allows remote authenticated users to gain privileges. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2692)
[21:19] <jdstrand> as such, I have uploaded the packages to -proposed for wider testing
[21:20] <jdstrand> they have received a good bit of testing already, and they look good here
[21:20] <jdstrand> I'd really appreciate it if people could test these packages and report 'works here' in that bug report, so I can push the update out next week
[21:21] <mathiaz> jdstrand: great
[21:21] <nijaba> jdstrand: there is a version for dapper?
[21:22] <jdstrand> because gutsy is so close to upstream, its patches weren't significant
[21:22] <mathiaz> jdstrand: You've already sent a couple emails on different mailing lists
[21:22] <mathiaz> jdstrand: could you post something to the forums ?
[21:22] <jdstrand> really looking for dapper (and edgy and feisty if possible)
[21:22] <mathiaz> jdstrand: or ask faulkes- about it ?
[21:22] <jdstrand> nijaba: 5.0.22
[21:22] <jdstrand> is faulkes- around?
[21:22] <mathiaz> jdstrand: I think there is developer forum that is targeted at that
[21:22] <jdstrand> mathiaz: but to answer your question-- sure
[21:23] <mathiaz> jdstrand: altought I'm not sure if the people reading the developer forums would be able to test your updates
[21:23] <jdstrand> nijaba: oh heh, I read your question to quickly-- yes dapper has updates and I'd really like testing there
[21:24] <jdstrand> mathiaz: couldn't hurt
[21:24] <nijaba> ok, I'll test it on my prod server
[21:24] <mathiaz> jdstrand: could you coordinate with faulkes- about requesting feedback in the forums ?
[21:24] <nijaba> and blame you if it blows up ;)
[21:24] <jdstrand> nijaba: yes, you would be within your rights on that
[21:25] <mathiaz> [ACTION] jdstrand to coordinate with faulkes- about mysql testing in the forums
[21:25] <MootBot> ACTION received:  jdstrand to coordinate with faulkes- about mysql testing in the forums
[21:25]  * jdstrand won't mention testing updtes on a production server, as he really wants as much testing as possible
[21:25] <jdstrand> ;)
[21:26] <mathiaz> [TOPIC] LSB compliant init script
[21:26] <MootBot> New Topic:  LSB compliant init script
[21:26] <mathiaz> kirkland: owh: you've started to look into that
[21:26] <mathiaz> what is the outcome ?
[21:26] <owh> We started creating some code to get output.
[21:26] <kirkland> mathiaz: we have a list of all packages in Main, and Universe that install something in /etc/init.d
[21:26] <owh> We've created an initial list of the hardy .iso: https://wiki.ubuntu.com/OnnoBenschop/ubuntu-server/init.d-status
[21:27] <owh> Next step is testing what they output :)
[21:27] <ScottK2> Is this really a project we ought to be starting a day before beta freeze?
[21:27] <mathiaz> LSB compliant means a lot of things - what are you trying to fix first ?
[21:28] <mathiaz> I think trying to get the status action for the daemons makes sense
[21:28] <kirkland> mathiaz: a "status" action by init scripts is one of the things required for LSB
[21:28] <kirkland> mathiaz: in most cases, it's a trivial patch
[21:28] <mathiaz> having a fully compliant init script may require too much work though
[21:28] <owh> We start small and work our way up.
[21:29] <mathiaz> kirkland: well - there is also the headers for startup sequence
[21:29] <kirkland> mathiaz: for services (and mainly those in ubuntu-server), i think it's important enough to have in Hardy, and minor enough code changes
[21:29] <owh> We started with the packages installed by tasksel on the ubuntu-server install.
[21:29] <ScottK2> Personally I think adding features to inits is adding features and should be done at the appropriate point in the development cycle for feature development.
[21:29] <kirkland> mathiaz: full compliance is beyond the scope I'm suggesting
[21:29] <owh> It's a fair point ScottK2
[21:30] <mathiaz> ScottK2: right. OTOH not having a status action for init script is really annoying
[21:30] <owh> And I figure if we're serious with ebox, it will need to know if stuff is working - no?
[21:31] <mathiaz> so trying to add a status action for packages that are on the ubuntu-server iso seems to be a good compromise
[21:31] <kirkland> mathiaz: i agree with that
[21:31] <owh> All of them, or only the ones that are installed by a tasksel server selection?
[21:31] <ScottK2> It's not nearly annoying as having a broken init script on release day.
[21:32] <mathiaz> ScottK2: I'd say that testing an init script is easy.
[21:32] <ScottK2> mathiaz: I think if you want to pursue this you should ask ubuntu-release for an FFe.
[21:32] <owh> There's only 7 that don't have a status that are installed by a tasksel *server selection
[21:32] <mathiaz> ScottK2: aggreed.
[21:32] <mathiaz> ScottK2: I was about to suggest that we should talk to ubuntu-release about this.
[21:32] <ScottK2> It all depends on the init.
[21:32] <kirkland> ScottK2: the risk is having an init script with a broken 'status' action on release day
[21:32] <ScottK2> kirkland: We have lots on unimplemented features.
[21:32] <kirkland> we should not be affecting the start/stop/(other) actions
[21:33] <mathiaz> kirkland: could you update the Roadmap with a clear scope on what we aim at ?
[21:33] <ScottK2> kirkland: Agree with should not.
[21:33] <owh> There are only 4 that have a status option so far.
[21:33] <nealmcb> I'd suggest taking it one package as a time - if the patch is trivial and fixes the "non-lsb-compliant" bug, then it is worthwhile given the 5 year lifespan of hardy.  but I know it is also risky
[21:33] <mathiaz> kirkland: and also list the packages targeted for hardy ?
[21:33] <kirkland> mathiaz: will do
[21:33] <mathiaz> kirkland: once the list is there, we can ask ubuntu-release to have a look at it and get a FFe for it.
[21:34] <kirkland> nealmcb: I agree with your LTS comment, plus the fact that this is "catch-up" for many key services on ubuntu-server
[21:34] <mathiaz> kirkland: however we won't have this ready by beta.
[21:35] <nealmcb> at any rate, thanks for gathering the data, folks....
[21:35] <mathiaz> kirkland: the archive freeze is tomorrow - and these are patches that are not show-stoppers for the beta release
[21:35] <owh> That gives us 24 hours :)
[21:36] <kirkland> owh: with 2/7 done
[21:36] <zul> uh...no it gives you less than that
[21:36] <mathiaz> [ACTION] kirkland to update the Roadmap outlining the scope of the work - just add status action
[21:36] <MootBot> ACTION received:  kirkland to update the Roadmap outlining the scope of the work - just add status action
[21:36]  * nealmcb would love to have status-getting documentation that doesn't have to say "except on hardy" for a long time
[21:36] <owh> Seriously, the packages on the CD, there are really not that many if we limit ourselves to tasksel only stuff.
[21:36] <mathiaz> [ACTION] kirkland to ask ubuntu-release for a FFe for each of the packages.
[21:36] <MootBot> ACTION received:  kirkland to ask ubuntu-release for a FFe for each of the packages.
[21:38] <mathiaz> [TOPIC] libdb4.x transition
[21:38] <MootBot> New Topic:  libdb4.x transition
[21:38] <mathiaz> there has been some work done on this.
[21:39] <mathiaz> mruiz has been working on a couple of them - and contacted some upstream about the transition. Some of the upstream added a check in the configure script for a specific version of libdb.
[21:39] <mathiaz> zul: is the Roadmap updated wrt to the package you've uploaded ?
[21:39] <zul> mathiaz: afaik yes
[21:40] <zul> yes it is...mruiz is doing the rest of them
[21:40] <mathiaz> ScottK2: is there any packages for libdb4.4 and libdb4.5 ?
[21:41] <ScottK2> mathiaz: There are, but I haven't had time to look
[21:41] <mathiaz> ScottK2: ok - so may be we should concentrate on libdb4.3
[21:41] <ScottK2> Yes.
[21:42] <mathiaz> ScottK2: and then jump to libdb4.4 and 4.5
[21:42] <ScottK2> Yes
[21:42] <ScottK2> lidbd4.2 will be sticking around, so no point worrying about that one right now.
[21:42] <mathiaz> [TOPIC] Server Guide documentation
[21:42] <MootBot> New Topic:  Server Guide documentation
[21:42] <mathiaz> ScottK2: yeah - related to openldap
[21:42] <ScottK2> Exactly
[21:42] <mathiaz> sommer: so how is the string freeze going ?
[21:43] <sommer> getting there
[21:43] <sommer> added an ebox section if people would like to review
[21:43] <mathiaz> sommer: do you have section that needs focus for review ?
[21:43] <sommer> probably the virt section... working with nijaba and soren on it
[21:44] <sommer> I should have an update for it this evening... the current version isn't quite accurate
[21:44] <mathiaz> sommer: ok - I'll look into also as I'm still setting up my new vm environement.
[21:45] <sommer> mathiaz: cool, the more the marrier
[21:45] <mathiaz> keescook and jdstrand have also migrated to kvm IIRC
[21:45] <jdstrand> yep
[21:45] <jdstrand> loving it
[21:45] <nealmcb> :-)
[21:45] <jdstrand> much less resource intensive than vmware
[21:45] <sommer> other than that just working through the rest of the sections and updating minor adjustments for hardy
[21:46] <nijaba> at least sommer does it in real condition: remotely
[21:46] <sommer> heh... attempts to :-)
[21:46] <mathiaz> sommer: could you update the Roadmap with a list of the section you'd ask for review ?
[21:46] <dendrobates> sommer:  I should get the likewise-open man pages by tomorrow.
[21:46] <soren> I had 10 vm's running at the same time a few days ago. Worked fine.
[21:46] <mathiaz> sommer: so that we can point people to it and focus our efforts on that.
[21:46] <sommer> mathiaz: sure
[21:47] <mathiaz> [TOPIC] sommer to update the roadmap section with a list of section of the server guide that need reviews.
[21:47] <MootBot> New Topic:  sommer to update the roadmap section with a list of section of the server guide that need reviews.
[21:47] <sommer> dendrobates: that's cool, I noticed the ffe bug.
[21:47] <mathiaz> nealmcb: could you update the factoids by adding a servergui entry ?
[21:47] <nealmcb> I sent mail a little while ago
[21:48] <mathiaz> !servergui
[21:48] <ubotu> Sorry, I don't know anything about servergui - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[21:48] <nealmcb> mail to the server team...
[21:48] <nealmcb> if folks like what I wrote, and the servergui changes, I'll talk to the ops
[21:48] <faulkes-> I now have hardware and a requirement for virtuals, so I'll be doing kvm stuff very soon
[21:49] <nealmcb>  https://help.ubuntu.com/community/ServerGUI
[21:49] <nealmcb> (that's mostly sommer's work of course - just a few edits by me)
[21:49] <mathiaz> nealmcb: I think it looks good
[21:49] <jdstrand> I should mention that while I have been loving kvm
[21:49] <mathiaz> nealmcb: and should be added
[21:50] <jdstrand> and have moved all my vmware machines to it
[21:50] <nealmcb> will do
[21:50] <mathiaz> nealmcb: I can't seem to find your email to the server team about the servergui entry
[21:50] <jdstrand> there is some adjustments that need to be made on pre-hardy vms
[21:50] <nealmcb> just half an hour ago
[21:50] <mathiaz> [ACTION] nealmcb to add an entry for the servergui factoid
[21:50] <MootBot> ACTION received:  nealmcb to add an entry for the servergui factoid
[21:50] <jdstrand> I will update the wiki accordingly (probably tomorrow)
[21:51] <jdstrand> additionally, there is s script available to help migrate
[21:51] <mathiaz> nealmcb: ah ok - I haven't checked my email
[21:51] <jdstrand> vmware images to kvm:
[21:51] <jdstrand> http://people.ubuntu.com/~soren/vmware2libvirt
[21:51] <MootBot> LINK received:  http://people.ubuntu.com/~soren/vmware2libvirt
[21:51]  * owh hugs jdstrand
[21:51]  * owh thanks soren for the code.
[21:52] <nealmcb> I did change one part of the recommend apt-get commands...
[21:52] <mathiaz> [TOPIC] LTS upgrades
[21:52] <MootBot> New Topic:  LTS upgrades
[21:52] <mathiaz> so what are our current efforts in that area ?
[21:53] <soren> owh: Oh, it's jdstrand's doing. All of it.
[21:53] <soren> owh: I just stole it and threw it on people.ubuntu.com :)
[21:53] <owh> ROTFL
[21:54] <mathiaz> so I guess we're doing really good on LTS upgrade testing if noone has anything to report
[21:55] <jdstrand> mathiaz: I would not assume that
[21:55] <jdstrand> :)
[21:55] <jdstrand> mathiaz: I was until a moment ago silent because I haven't done it
[21:55] <ScottK2> I can unequivicably (or however that's spelled) say that I have not encountered any errors in LTS to LTS upgrade testing.
[21:55]  * jdstrand could say the same
[21:56] <mathiaz> well - my question then is: what was LTS-to-LTS-upgrade-tested ?
[21:56]  * sommer needs to make time for testing LTS on LTS action
[21:56] <nealmcb> ScottK2: but what fractions of the upgrades have been successful?  Any singularities encountered?
[21:56] <nealmcb> :-)
[21:56] <mathiaz> ScottK2: I guess you've tested postfix and mail daemon
[21:57] <ScottK2> Actually I haven't directly, but I've tested direct upgrades of Postfix to modern versions on Dapper with no trouble for backports
[21:58] <mathiaz> well - we still need to focus on LTS-to-LTS upgrades
[21:58] <mathiaz> especially now that we're about to release beta
[21:58] <mathiaz> [TOPIC] Any Other Business
[21:58] <MootBot> New Topic:  Any Other Business
[21:59] <mathiaz> anyone wants to add something ?
[21:59] <mathiaz> soren: could you update the ReportingPage with a virtualization section ?
[21:59] <ScottK2> mathiaz: Any chance now for tasksel changes?
[21:59] <owh> And a migration guide :)
[21:59] <mathiaz> dendrobates: same thing for likewise-open ?
[22:00] <mathiaz> ScottK2: you mean the dovecot+postfix integration ?
[22:00] <ScottK2> mathiaz: Yes.
[22:00] <soren> mathiaz: Will do.
[22:01] <ScottK2> I wanted to see about integrating amavisd-new since we finally got it in Main
[22:01] <mathiaz> ScottK2: I think that ivoks updated the patch for the new version of tasksel
[22:01] <mathiaz> ScottK2: now it needs a FFe and then a core-dev can upload it
[22:01] <soren> "unequivocably", I think, by the way.
[22:02]  * kirkland quivs with soren
[22:02] <ScottK2> soren: That looks right
[22:02] <ScottK2> mathiaz: Do you have a bug number?  If there's a patch, I'll look into FFe.
[22:03] <mathiaz> ScottK2: https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/164837
[22:03] <ubotu> Launchpad bug 164837 in dovecot "Dovecot SASL for postfix" [Low,In progress]
[22:03]  * ScottK2 looks
[22:03] <mathiaz> [TOPIC] Agree on next meeting date and time.
[22:03] <MootBot> New Topic:  Agree on next meeting date and time.
[22:03] <mathiaz> Same time, same place, next week ?
[22:04] <nealmcb> yes - utc-wise :-)
[22:04] <mathiaz> well - 21:00 UTC
[22:04] <nxvl> meeting is already over?
[22:05] <mathiaz> the time hasn't changed - only the some part of the world decided to move forward in time
[22:05] <ivoks> mathiaz: yes, i've updated it
[22:05] <ivoks> ScottK2: no, i didn't put amavis in it; and i'm not big fan of doing amavis filtering by default
[22:06] <ivoks> ScottK2: i think we should leave that to people who know what it is for
[22:06] <ivoks> otherwise, we'll have angry users complaining that their ubuntu mail server kills mail
[22:07] <ScottK2> ivoks: Fair enough
[22:07] <ScottK2> It's certain not something we should shove in at the last minute if there's no consensus.
[22:07] <ivoks> ScottK2: amavis bounces mail with exe attachments by default, so... i don't know...
[22:07] <mathiaz> Ok - so next meeting: next week, same time same place
[22:07] <ScottK2> We'd need to come up with a do no harm config
[22:08] <mathiaz> Thanks all for attending ! :)
[22:08] <ivoks> ScottK2: yeah... i'm still in a quest for ideal amavis config :)
[22:08] <mathiaz> #endmeeting
[22:08] <MootBot> Meeting finished at 22:08.
[22:08] <ivoks> ScottK2: and, it would love to see mailzu integrated with amavis
[22:08] <sommer> thanks mathiaz, later all
[22:09] <nijaba> thanks all