=== _neversfelde is now known as neversfelde [02:05] be back in just a few minutes, gotta restart kde === ScottK3 is now known as ScottK-desktop === Pricey is now known as Guest75242 === Hobbsee` is now known as Hobbsee === davroman1ak is now known as davromaniak === pricechild is now known as Pricey [09:44] hmm.. must be the not-now week === asac_ is now known as asac === ALAYA_ is now known as ALAYA === davmor2 is now known as davmor2-lunch === lamont` is now known as lamont === davmor2-lunch is now known as davmor2 [15:01] Keybuk: around? [15:01] Keybuk: clan says Matt and Mark won't be [15:02] yup [15:02] badly timed typing break [15:03] I don't see a whole lot of business, though [15:03] patent policy from mdz, presumably in abeyance until next week [15:03] I think we have to do your swearing in :) [15:04] you can approve my subscription to technical-board@ if you like ;-) [15:05] I swear to faithfully preserve, protect, and defend the code of conduct ... oh wait, that's the community council [15:05] ok, ML subscription approved [15:05] welcome aboard [15:06] ta muchly [15:07] dholbach: are there any outstanding nominations we should consider? [15:07] Keybuk: which were the last ones that you processed? [15:07] Keybuk: I'll check the archives, hang on [15:07] did we process the request for selective upload for Stefan Bader? [15:08] s/we/you/ [15:08] Keybuk: Dustin was the last one [15:08] dholbach: Dustin Kirkland, Stephan Graber (LTSP) [15:08] ah yes, Stephane too [15:08] cjwatson: we did, that was approved [15:08] then it's all resolved now [15:09] I'm curious as to which applications are in the MC pipeline [15:09] * Open Applications: Nick Ellery (UUC), Jonathan Thomas (MOTU), [15:09] Michael Casadevall (core-dev), Alessio Treglia (MOTU) [15:09] they're all in process still and we plan to have them resolved soon (before we hold our meetings and move to the new process) [15:09] some are lacking votes, some are lacking input from sponsors [15:10] *nods* the new process looked good [15:10] thanks for the flowers [15:10] :) [15:10] I don't see anything from the other outstanding issues that is ready for discussion yet [15:11] ok, any business from anyone today? [15:12] has the calendar stuff from last meeting been resolved? [15:12] it seems that we just need to invite the appropriate magic address [15:12] I can do that now, if folks would like [15:12] matt recorded an action to follow up with the news team, but I don't know whether that has been done [15:12] https://wiki.ubuntu.com/Fridge/Calendar [15:13] the technical board meeting still doesn't appear there [15:13] let me try [15:13] they are now using google calendar, and the drupal calendar is abandoned [15:13] there it is [15:14] that should be the whole series added now [15:14] and indeed http://fridge.ubuntu.com/calendar is now correct [15:14] heh, did we both do that ? [15:14] maybe :) [15:14] well, it seems that google figured it out anyway ;) [15:15] that should be paired with the event our calendars, right? so if we move it, it'll move on the fridge [15:16] I *think* so [15:17] Daniel asked if we could look at the per-package uploader proposal [15:17] https://lists.ubuntu.com/mailman/private/technical-board/2009-January/002892.html [15:18] good idea [15:18] persia, soren, nixternal: around? [15:19] http://pastebin.com/m2ea34e91 [15:19] ^ public viewable copy [15:19] thanks Keybuk [15:19] dholbach: hm? [15:19] my main concern, on a quick reading, is that ditching the expectation of social integration with the larger team altogether seems to invite problems [15:20] I agree that per-package uploaders don't need to be quite so plugged into the development community as generalist developers [15:20] soren: talking about "per package upload" requirements [15:20] cjwatson: this has been my general concern as well; I still feel it's important that per-package uploaders still consider themselves to be Ubuntu Developers and participate in the wider community [15:20] also that the MOTU team, as it currently stands, seems most effective at supporting its own members and potential members [15:20] but we have talked recently about single-package-only uploaders having TB voting rights and generally being considered Ubuntu developers, which seems to point towards some degree of social cohesion [15:20] and I'm not sure how per-package uploaders would get support for problems they encounter [15:21] is there specific portion of the text that you'd like to be changed or something else to be added? [15:21] I'm offering hopefully-constructive criticism rather than a patch :-) [15:22] 1) There is no expectation that the applicant meets the requirements [15:22] of Ubuntu Membership, so the prior demonstration of significant and [15:22] sustained contribution to Ubuntu is waived. [15:22] as I understand it, we are explicitly talking about granting ubuntu membership rights to such uploaders [15:22] cjwatson: OK, I'm not asking you to write it, but what do you feel is the specific expectation that you'd have in that regard :-) [15:22] I'd sort of like the proposal to incorporate the notion that the candidate should be working with other Ubuntu developers rather than against them [15:22] therefore it seems alien to me that the requirements would be waived [15:23] yo yo [15:23] cjwatson: indeed, this goes on to specifically say that per-package uploaders need not be expected to work on the team or be integrated with it [15:23] I have a concern that we might be approving developers who have an entirely different mindset about how the system should work, and might proceed to make their package conform to their view of the world, without regard for wider integration [15:23] dholbach: what's up? [15:24] this kind of thing, indeed, *has* been a problem, and the fact that we expect developers to work as part of a team is very important in mitigating it [15:24] I'm all for per-package uploaders working with the community and understanding that there's no "lock". And that they demonstrate that they have worked with others beforehand. [15:24] otoh, where this has worked so far has been in the kernel team [15:24] where there's explicitly an expectation that they do work with that team [15:25] and they are being granted upload rights *because* they work closely with that team, and to avoid them having to rely on their team-mates for sponsorship [15:25] I would be happier if the proposal said "There is a reduced expectation that the applicant is socially integrated ..." rather than "no expectation" [15:25] Still they might have worked with a smaller set of sponsors and the expectations on a technical level are different from what we expect from applicants now. [15:25] cjwatson: I'm not sure I'd even be happy with a reduced expectation [15:25] somebody who can upload to Ubuntu should see themselves as a fully socially integrated member of the Ubuntu Developer team [15:26] I would rather the distinction was simply viewed as a technical one [15:26] dholbach: sure, they don't have to work with everyone on the planet, but I don't agree that we should be laying out criteria that allow for a per-package developer to work in their own little corner and disregard what else is happening [15:26] or, at least, criteria that suggest that that's OK [15:26] a per-package uploader is somebody with a specific skill set that uploads a package they are familar with [15:26] (obviously it's not put that way right now, I'm elaborating) [15:26] a MOTU member is somebody who's skill set is wide and varied [15:26] cjwatson: I definitely agree with what you're saying and will work with the MC to make it clearer in the proposal [15:27] I'm happy with the idea of requiring all developers to be members: that proposal was written some time ago. [15:27] Keybuk: yeah, that matches my expectation more closely, I must say: narrow skills, broad openness to integration [15:27] dholbach: I certainly agree that the technical expectations are very different; no argument there [15:28] Keybuk: what interests me most is cases where people really just care about one or two package, have worked with one or two sponsors (through the process, understanding our processes and stuff), but have merely added a patch or two or packaged new upstream version, but on the other hand demonstrated that tey deeply care about the package and have an excellent bug story and an excellent upstream story to tell [15:28] the "does not grant sole-maintainership" bit in Emmet's proposal is good [15:28] dholbach: those are the cases that worry me most [15:28] because I forsee those people being so attached to their package that, if they are not also socially integrated with Ubuntu, will lead to difficulties [15:29] they might revert patches other Ubuntu developers make to their package [15:29] they might fail to participate in transitions or large-scale work that affects their package [15:29] The barrier to MOTU is not overly high. Why even allow per-package uploader rights to not-motu? [15:29] *non-motu [15:29] (and I would claim that this already happens) [15:29] cody-somerville: because it's very hard to judge in cases like the one I described above [15:29] cody-somerville: because, at the moment, the MOTU barrier involves demonstrating an ability and interest in general contributions [15:29] I'd rather expect single-package-uploaders to fail to participate in transitions or other large-scale work, just from lack of notification, if nothing else. [15:30] cody-somerville: MOTU has general upload access to the entire universe component, and as such, applicants are expected to be technically diverse in their skills [15:30] cody-somerville: (and this is expected to evolve with archive-reorganisation) [15:30] persia: and I think that's OK, it's clearly not their interest [15:30] I guess what'd I expect from per-package uploaders is somebody who meets all the social requirements of MOTU [15:30] That doesn't seem to be the case. I see a lot of applicants get approved base on a sub-set of interest. [15:30] Right. [15:30] and has made a sustained contribution [15:30] persia: as long as they don't block it [15:30] but only in a small subset of area [15:30] cody-somerville: it has been a practical problem in a number of specific cases [15:31] cody-somerville: cf. the kernel developers who are only interested in hacking on the kernel and so don't build up the packaging experience needed for MOTU [15:31] Matthew East is a good example here, he has had a single package sponsored for a long time now, and is well integrated into Ubuntu [15:31] Keybuk: you said that these cases worried you the most - what would ease your fears there, what kind of story would you like to see first? [15:31] he would seem to be an obvious choice, even though he is not a MOTU member [15:31] dholbach: I think we go back to "why can't they be members of MOTU" ? [15:31] dholbach: the warning bell for me is when they start off by saying that Ubuntu's doing it all wrong :-) [15:31] (which can be OK, obviously there are some things we *are* doing wrong, but it can also be a sign of somebody with a very fixed agenda) [15:32] cjwatson: I'll make a note to check archives and Google for instances of them saying that before sending in my +1 :-) [15:32] Keybuk, Could I ask you to please not use the phrase "MOTU Member"? It's somewhat confusing, and has been misused by others. Would just "MOTU" work for your meaning? [15:32] perhaps we could say "generalist developer" ;-) [15:32] That might be even better, as it looks towards archive reorganisation. [15:32] ok, let me a little more specific [15:33] Keybuk: being MOTU would not help mdke [15:33] dholbach: I think personally I'd like to see examples of them working with other Ubuntu developers to at least some extent, even if that's just constructive engagement with their bug reports [15:33] mdke would pass that with flying colours [15:33] cjwatson: sounds good [15:33] If somebody wishes upload rights to a package, why would we not simply require that they join the development team that maintains that component and provides upload rights as part of the team permissions? [15:34] well, because many packages aren't in any team smaller than "Ubuntu developers" [15:34] Keybuk: how do you judge that if they just touched one package (and did it well), but their main contribution was liaising with users, upstreams and other distro maintainers? [15:34] Keybuk, What if there exists no such specialised team, and they are the only one who wants to work on that specific package? [15:34] dholbach: let me pick up on a point there already [15:35] you suggest that they should already have been touching that package in Ubuntu [15:35] assumedly through sponsorship [15:35] I agree wholeheartedly [15:35] *nod* [15:35] that they are liasing with users, upstreams and other distro maintainers suggests that they are using Launchpad and the Ubuntu Mailing lists already [15:36] the only difference to my mind: [15:36] - if they have contributed to a wide variety of different packages, they are suitable for a generalist team membership [15:36] - if their contribution has been to a narrow set of packages (or even just one), they are suitable for per-package upload rights [15:36] all other requirements should be the same [15:37] I think there's three categories. [15:37] There's generalist developers [15:37] Generalist UBUNTU Developers [15:37] Ubuntu developers who are generalists [15:37] There's specialist developers in a given interest area (e.g. Xubuntu, Games, etc.) [15:37] Specialist UBUNTU Developers ;) [15:37] And there's people who want to work on *one* package. [15:38] Yes, s//Ubuntu/ in all lines above. [15:38] I see the one package as a very narrow interest area [15:38] that sounds good, the only trouble is: if the "packaging skills demonstrated" merely consist of "just" packaging a new upstream release or "just" adding an upstream patch, the requirements ARE different :) [15:38] Keybuk, SUPER Specialist UBUNTU Developer? [15:38] ;] [15:38] please don't get caught up into nomenclature again :-) [15:38] dholbach: does MOTU not already have this problem? [15:38] Keybuk, Is it worth creating the infrastructure of a layer for one person for one package? [15:38] what if a prospective applicant has had a very large number of sponsored uploads, all of which have been just packaging a new upstream release or just adding a new upstream patch? [15:39] I don't think you should infer technical infrastructure (layers) from social structure (interest areas) [15:39] Keybuk: it's a lot easier to judge when somebody demonstrated their abilities on a variety of packages and did "packaging changes that were necessary" [15:39] (and no, it isn't worth it) [15:39] dholbach: I think it's easier to judge someone's skills as a generalist [15:39] but not much more [15:39] cjwatson, Well, fair, but I'm thinking in terms of implementation. I'd rather that those with a narrow interest (in an entire layer) have a slightly different process than those with interest only in a specific package. [15:39] Keybuk: I still think we should make that clear in the expectations we set [15:40] questions I might ask a prospective per-package uploader: [15:40] 1. there's a new upstream version available; what's changed? why is it not packaged? [15:40] persia: I don't see a reason to create a separate layer for individual packages, and it would result in more work for archive admins for little gain [15:40] 2. you're not a bug contact for this package, why not? (and -200 points) [15:40] 3. there's several bugs that haven't yet been triaged in Launchpad, have you looked at these? [15:40] 4. what are your thoughts on the open High priority bug #nnnn ? [15:41] persia: as Mark said on the phone a week or two ago, packages and package sets (a.k.a. layers) should be like people and teams - you can use either in place of the other [15:41] at least as far as the access controls go [15:41] 5. package foo is quite similar, and uploads have been made by Ubuntu developer X - have you talked to them? [15:41] (now, obviously that's a bit down the line in terms of actual LP implementation, but) [15:41] cjwatson, Agreed. Similarly, I think we want slightly different requirements for per-package uploaders and uploaders to a layer. [15:41] persia: absolutely [15:41] Keybuk: I'm very happy with the questions you ask and I'll make sure I'll massage that into the proposal. [15:42] where a layer is aligned with a team, I'm actually less nervous because that developer is clearly joining an existing team [15:42] And presumably, is welcomed by the existing members of the team, who can provide support, mentoring, guidance, etc. [15:42] it's the lone developer that worries me [15:43] assumedly on a crusade to champion the cause of the innocent, the helpless, the powerless, in a world of...no, wait [15:43] That's different :) [15:43] let's put it as "likely to require additional assistance", shall we? :) [15:43] Keybuk, cjwatson: before we move the topic to Archive Reorg, is there anything else you would like to see covered in a new proposal that was not raised yet? :) [15:43] cjwatson, Well, maybe. Again, the handy example is Matthew East. [15:44] I'll be moving the existing proposal back to the drawing-board. :-) [15:44] Thanks a bunch for your input [15:44] persia: well, he's a likely-to-pass candidate, not a dubious candidate, surely [15:45] of the existing three candidates for specific upload rights, two seem to me to demonstrate that they consider themselves Ubuntu developers with a specialist interest in a package [15:45] the other seems to be to be a developer who just wants to upload his package, and has not demonstrated a contribution to Ubuntu thus far [15:45] (avoiding names since it's unfair if they're not here) [15:46] I think that the policy, as worded, does not encapsulate that difference - and in some ways seems to deliberately try and get rid of it [15:46] If we add the requirement of Ubuntu Membership, as previously discussed, it makes the line much easier to draw. [15:47] The current proposal specifically doesn't require this, but that's simple to change, and provides protection in the sense that we select from those who already identify with Ubuntu. [15:48] I think I would agree with that [15:49] persia: will you take the action to redraft the proposal and resubmit it to the TB? [15:49] Keybuk, Sure. Am I just changing the Membership, or is there more? (I'll review the meeting log for details if the latter) [15:50] I think it's a bit more than that; review the log [15:50] OK. I saw a few things, and wanted to check :) [15:51] I can give a brief update on the state of play with archive reorg [15:51] let's hold the issue of the candidates in abeyance until we agree on the policy [15:51] cjwatson: please do [15:51] we have ~9 minutes [15:51] I've introduced the notion of restricted layers into the spec [15:52] I've added sections on how the ogre model will work, and on some anticipated community factors [15:52] I've changed the proposed permissioning around to encapsulate what I believe to be current consensus [15:52] the permissioning has one rather curious feature [15:53] it has a "core" layer, which remains necessary for the ogre model and for partial mirrors [15:53] but the permissions on the "core" layer are simply "Ubuntu [generalist] developers", the same as for all packages in no layers [15:53] I think this is actually OK, and explain why I think that in the spec, but it does look a bit curious :) [15:54] oh? [15:54] I've explicitly introduced the term "general developers" (should probably change that to generalist) [15:54] "(It looks a little odd to have this require the same level of access as the "core" layer, but the different layers are required in order to preserve things like ogre model and the ability to produce working partial mirrors, and in practice this models the "broad and shallow" type of developer quite well.)" [15:55] sounds fair [15:55] I'll re-read the spec ;) [15:55] my next steps are: to prepare a rough set of requirements for the Soyuz team (including a transition plan of sorts); and to start work on an example layerised archive [15:56] I want to have something on people.ubuntu.com that you can point experimental versions of apt and friends at in order to see what the new world order would look like [15:56] One note is that members of MOTU belong to the ~motu team, rather than ~ubuntu-dev. ~ubuntu-dev contains both ~ubuntu-core-dev and ~motu. [15:56] this will both afford us the opportunity to test the tool changes, and let us work on the layer migration itself [15:56] persia: noted, will adjust [15:57] though of course ubuntu-dev is appropriate at some places in that spec where we're really talking about the union (e.g. "ability to upload to current universe" -> ubuntu-dev) [15:58] having an example layerised archive will let people play about and answer quite a few questions, I think [15:58] that will have to come with some basic tools to sync up with the current archive overrides [15:58] Also, as a suggestion for the conflict between "Ubuntu Developer" being the term for merged core-dev and MOTU vs. "Ubuntu Developer" being the term for all Ubuntu Developers in the new model, it may be best to merge the current teams separately, and then add any new developer teams to ~ubuntu-dev [15:59] I suspect that the resolution there is to call the merged one "Ubuntu Generalist Developer" or something [15:59] but I've been holding off on that because, frankly, it sounds clunky :-/ [15:59] That seems sensible. [15:59] I don't have a better suggestion at the moment [15:59] anyway, that's all from me for the moment - there'll be a call with the Soyuz team next week [15:59] ok, we're about to run into the server team meeting ... [15:59] do we have any other business? [16:00] (once Mark is back from gallivanting) [16:00] nothing from me [16:01] ok, adjourned then [16:01] thanks all [16:01] o/ [16:01] \o [16:01] \o/ [16:01] * mathiaz waves [16:02] Let's get the Ubuntu Server Team started [16:02] #startmeeting [16:02] Meeting started at 10:02. The chair is mathiaz. [16:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:02] Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting === dendrobates- is now known as dendrobates [16:02] hi ho neighborarinos [16:02] o/ [16:02] hey all [16:02] what a busy agenda! let's get moving [16:03] Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090120 [16:03] [TOPIC] SRU for ebox [16:03] New Topic: SRU for ebox [16:03] so I've uploaded ebox 0.12 to the new jaunty archive [16:03] sommer: that means the SRU process for intrepid can move on. [16:04] mathiaz: great, thanks [16:04] sommer: do you have the three bug numbers? [16:04] one sec [16:05] sommer: https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/273486 [16:05] Launchpad bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,New] [16:06] sommer: ok - I don't find the others [16:06] bug 255368 [16:06] Launchpad bug 255368 in ebox "ebox: Depends: libapache-authcookie-perl but it is not installable " [Undecided,Fix released] https://launchpad.net/bugs/255368 [16:07] and the dbug gconf one [16:07] sommer: is there a bug number for the latter? [16:08] mathiaz: bug 314606 [16:08] Launchpad bug 314606 in ebox "ebox and libebox don't support Intrepid gconf version" [Undecided,Fix released] https://launchpad.net/bugs/314606 [16:08] that's them :) [16:08] sommer: ok - I've just mark bug 273484 fix released [16:08] Launchpad bug 273484 in ubuntu "monitors wont go to sleep " [Medium,Incomplete] https://launchpad.net/bugs/273484 [16:08] sommer: https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/273486 [16:08] Launchpad bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,Fix released] [16:09] sommer: all the three bugs are fixed in jaunty and the intrepid SRU can move along. [16:09] mathiaz: I'll get with foolano and whip up some new debdiffs [16:10] sommer: the next step is to get the debdiff for the sru prepared, ACKed by the sru team and then sponsored to intrepid-proposed [16:10] [ACTION] sommer to prepare new debdiff for the ebox intrepid SRU [16:10] ACTION received: sommer to prepare new debdiff for the ebox intrepid SRU [16:10] [TOPIC] ACL by default [16:10] New Topic: ACL by default [16:11] ivoks: ^^ did you create a wiki page? [16:11] mathiaz: nope :/ [16:11] mathiaz: probably tomorrow [16:11] ivoks: anything else to report on this topic? [16:11] no [16:11] [ACTION] ivoks to create wiki page to keep track of ACL support in packages [16:11] ACTION received: ivoks to create wiki page to keep track of ACL support in packages [16:11] [TOPIC] DRBD in jaunty [16:11] New Topic: DRBD in jaunty [16:11] drbd is uploaded [16:11] ivoks: ^^ ? is dbd working in jaunty? [16:11] yes [16:11] *drbd* [16:12] ivoks: what kind of test did you conduct? [16:12] mathiaz: two vritualized machines [16:12] i'll do upgrade tests too during this week [16:12] ivoks: could you write down some test instructions? [16:12] sure [16:13] ivoks: so that they can be put in a wiki page and other can also help out in testing [16:13] of course... but in two-three days [16:14] ivoks: I'd suggest to create a subpage under https://wiki.ubuntu.com/Testing/Cases/ [16:14] ok [16:14] [ACTION] ivoks to write a wiki page for conducting DRBD testing under https://wiki.ubuntu.com/Testing/Cases/ [16:14] ACTION received: ivoks to write a wiki page for conducting DRBD testing under https://wiki.ubuntu.com/Testing/Cases/ [16:15] [TOPIC] Screen profiles [16:15] New Topic: Screen profiles [16:15] kirkland: what's the state of screen and screen-profiles now? [16:15] mathiaz: screen-profiles is in main [16:15] mathiaz: screen recommends screen-profiles [16:16] and it kicks asses [16:16] nijaba: yes, multiple asses :-) [16:16] heeeh [16:16] mathiaz: so here's my question for the Ubuntu Server team ..... [16:16] * mathiaz plays the drums [16:16] mathiaz: what could/should we do with the default /etc/screenrc ? [16:16] conffiles and alternatives are unlikely to be friends; I recommend not using alternatives (as suggested in the agenda) [16:16] i'm for vanilla /etc/screenrc [16:17] cjwatson: okay, so not update-alternatives ..... [16:17] just because most of the people expect that [16:17] kirkland: how many different screen profiles are there now? [16:18] ivoks: a lot of people expect linux desktop to be command line only, if we go that direction... [16:18] ivoks: i agree that that's been the traditional screen profile, but i think we've created something cool, and very Ubuntu-unique ... could be a nice advantage of using the Ubuntu Server [16:18] mathiaz: for Ubuntu, 3 basically.... the plain vanilla one, ubuntu-light, and ubuntu-dark [16:18] nijaba: that's correct, but i was thinking more about people who do know how to use cli and screen [16:18] mathiaz: we also have profiles for debian, etc, but those are not installed on ubuntu [16:19] ivoks: they won't be using screen then [16:19] ivoks: run a test, and ask how many admin DO know about screen, you'll be surprised [16:19] cjwatson: do you have any other suggestion, if not alternatives? [16:19] I haven't looked into it at all; I was just raising a warning flag rather than purporting to have an alternative :) [16:20] cjwatson: thanks [16:20] kirkland: what are you trying to accomplish actually? [16:20] although I would say, why is this a root-only thing? [16:20] kirkland: IIUC you're asking what we should put in /etc/screenrc [16:20] cjwatson: its not at all a root-only thing [16:20] alternatives and other solutions that involve moving things around in /etc are root-only [16:20] kirkland: and we have 3 choices [16:20] cjwatson: any user can have this profile, if they run 'select-screen-profile' [16:20] if you aren't focusing on root-only, you should be thinking about options that users can easily set [16:20] kirkland: what about it being installed by default with ubuntu-standard? it is quite easy to put back to default [16:20] ah, well, who cares about what's in /etc then [16:21] here's an idea... [16:21] default screen prompts text, that nobody reads [16:21] cjwatson: b/c that's what you get if you don't (know to) run 'select-screen-profile' [16:21] is it possible to put a list of profiles there? [16:22] that would be selectable? :) [16:22] just an idea... [16:22] ivoks: in "select-screen-profiles" ? that's alreay the case [16:22] ivoks: ah that's an idea, perhaps .... on that screen we could say "run 'select-screen-profile' if you'd like some advanced features, etc." [16:22] and once screen is launched, you can change it using the screen profile helper [16:22] kirkland: no... you would run select-screen-profile [16:22] kirkland: how does the sensible-editor selection work? [16:22] kirkland: and, on first run, let people choose [16:23] ivoks: i like that, choose on first run [16:23] kirkland: people that want plain screen, wouldn't notice anything [16:23] kirkland: they would just hit enter [16:23] mathiaz: that's sort of how select-editor works [16:23] kirkland: people who run it for the first time, they would be 'wow, look at that...' [16:23] mathiaz: ivoks: cool, i think that's a plan [16:23] melikes ivoks plan [16:24] kirkland: seems like we could try a similar workflow for screen profiles selection [16:24] sounds appropriate [16:24] kirkland: do you have an idea on how to do that? [16:24] right, just as select-editor [16:24] mathiaz: cheers. thank you brilliant community [16:24] especially as usual screen users are trained to ignore that screen anyway [16:24] kirkland: are you planning to work on that? [16:25] mathiaz: i think /usr/bin/screen becomes a wrapper script to see if you've selected a profile; if so, just launch screen. if not, run select-screen-profile, then launch screen [16:25] mathiaz: i'll have it done by the end of today ;-) [16:25] \o/ [16:25] nice [16:25] [ACTION] kirkland to implement screen-profiles selection tool [16:25] kirkland: the "home page" for this is listed as https://launchpad.net/screen-profiles on launchpad - is that right? I want to know where to point people from https://help.ubuntu.com/community/ServerGUI [16:25] ACTION received: kirkland to implement screen-profiles selection tool [16:25] good job kirkland [16:26] nealmcb: correct [16:26] will do :) [16:26] let's move on [16:26] [TOPIC] EtcUnderRevisionControl status [16:26] New Topic: EtcUnderRevisionControl status [16:26] Koon: ^^ what's going on there? [16:26] Just a quick update on that project, which you may have heard (with the epic delay) at UDS [16:27] i'm sorry, but i have to leave... bbl [16:27] The design is finalized, it's heavily relying on etckeeper [16:27] everything should be implemented directly into etckeeper [16:28] The idea is to improve etckeeper and its bzr plugin to be a little more user-friendly [16:28] Koon: is there anything to test? [16:28] mathiaz: not yet. I created a project and a team on launchpad [16:29] interested people are welcomed to join, I already have Jelmer Vernooij (author of current bzr etckeeper featured) in [16:29] Koon: is the spec up-to-date wrt to the implementation plan? [16:29] the spec is up to date, ready to be accepted [16:29] Koon: what are the names of the team and project in LP? [16:29] Koon: what's the project name in LP? [16:29] project: etckeeper [16:30] team: etckeeper [16:30] gee, I could have guessed that... [16:30] it's manually synced with the GIT tree [16:30] at upstream [16:30] and we have Ubuntu branches in there [16:30] Koon: so you're waiting for the Spec to approved? [16:30] mathiaz: yes. [16:31] Joey Hess (upstream) has been quite open to intergating more advanced features [16:31] so they should find their way back into core [16:31] Koon: great. You should ping dendrobates about aproving the spec [16:32] he is pinged already [16:32] Koon: I haven't followed the spec closely since UDS. will this require changes to bzr as well? [16:32] jdstrand: it /could/ use a few more hooks [16:32] Koon: he already did. [16:32] er mathiaz === dholbach_ is now known as dholbach [16:33] jdstrand: especially to catch all permissions-upsdating corner cases [16:33] Koon: not that it should be a factor in your devel work, but I was curious how easy it would be to backport to hardy [16:34] Koon: IIRC, the hooks cannot be done via bzr plugins-- is that accurate? [16:34] dendrobates: are you planning to review the blueprint soon? [16:34] mathiaz: yes. [16:34] jdstrand: hooks usually are in bzr core, and plugins use them [16:34] * jdstrand nods [16:35] but you could theorically add a hook by plugin, it just doesn't make much sense in the common scenario [16:35] [ACTION] dendrobates to review the etc-under-revision-control blueprint [16:35] ACTION received: dendrobates to review the etc-under-revision-control blueprint [16:35] ok - let's move on. [16:35] [TOPIC] Server Team Bug Days [16:35] New Topic: Server Team Bug Days [16:35] zul: what's your idea? [16:36] yeah so I was thinking that other teams have similar things where they hang out on the bugs channel and get people to help fixing bugs, i believe its a good way to get people involved [16:37] right. We had one bug day organized by the bug team [16:37] that was about 1 3/4 years ago [16:37] well we should have another one organized soonish [16:37] so I'd suggest to ask the Bug team about it [16:38] they'd be more than happy to help out and we'd reach much more people [16:38] than just organizing a Server Bug day in the server team. [16:38] bdmurray: what should we do to get a Server Team Bug day organized? [16:38] well thats what I was thinking as well we need someone to approach them [16:40] mathiaz zul: I am arranging a discussion between all of us at the sprint. [16:40] thats it from me :) [16:40] dendrobates: nifty [16:40] dendrobates: ok. We'll talk about this topic next week then. [16:40] let's move on [16:41] [TOPIC] ncrypted private/home with filename encryption available [16:41] New Topic: ncrypted private/home with filename encryption available [16:41] \o/ [16:41] kirkland: what did you do? [16:41] i uploaded a new ecryptfs-utils-69 package that enables filename encryption, if your kernel supports it [16:41] rtg on the kernel team backported ecryptfs filename encryption from 2.6.29 to 2.6.28 [16:42] and i completed the userspace bits this weekend to make this work with encrypted home and encrypted private [16:42] kirkland: awesome. [16:42] so, if you were to use ecryptfs-setup-private on an up-to-date jaunty system, you would see that your filenames are now encrypted as well, in your underlying .Private dir [16:42] and transparently decrypted for your in Private [16:42] same goes for encrypted home [16:43] kirkland: so upgrade are automatically handled? [16:43] mathiaz: dammit with the hard questions! [16:43] mathiaz: :-) [16:43] i still have some work to do on "live migration" [16:43] with some help from jdstrand, we came up with a theoretical design to solve this [16:43] kirkland: ok - so you get filename encryption on new installs only. [16:44] kirkland: for now [16:44] i'm flying to Germany tomorrow; i hope to hack that live migration script then [16:44] mathiaz: right [16:44] mathiaz: if you wanted to take advantage of this, you should backup your cleartext data elsewhere [16:44] kirkland: ok - do you have specific instructions for testing this? [16:44] mathiaz: then do a new ecryptfs-setup-private (fresh, empty dir) [16:44] mathiaz: and then rsync your data back in [16:45] mathiaz: i will blog about it this week [16:45] note that the desktop CD's still busted, this is server/alternate install CD only still [16:45] kirkland: great. [16:45] cjwatson <- is right [16:45] but i think we (evand, cjwatson) mostly know whats wrong there [16:46] [ACTION] kirkland to make a call for testing filename encryption [16:46] ACTION received: kirkland to make a call for testing filename encryption [16:46] cjwatson: i have set ecryptfs-setup-private to automatically use filename encryption, if possible [16:46] cjwatson: so no further changes in that respect should be required from you dudes [16:47] excellent news kirkland ! [16:47] kirkland: is there anything else to add on this topic? [16:48] kirkland: once the installer has support for this is there anything else left to be done for jaunty? [16:48] mathiaz: encrypted swap [16:49] mathiaz: i *strongly* believe that any user using encrypted home or encrypted private should really be using encrypted swap [16:49] kirkland: ok - that's a different (but related) topic [16:49] kirkland: for encrypted directories I meant [16:49] mathiaz: in such cases, all of the encrypted data lives as cleartext in memory [16:49] mathiaz: should that memory get swapped to disk, it's swapped to disk in the clear, unless swap too is encrypted [16:49] kirkland: is this something targeted for jaunty? [16:50] mathiaz: in the very worst case, i plan on adding a script to ecryptfs-utils that would attempt to setup your system for encrypted swap [16:50] mathiaz: to be run at the user's discretion after installation [16:50] i'm guessing that this item probably won't make the installer at this point [16:50] kirkland: ok. seems like a good first step. [16:50] i hope to talk to the foundations team about this next week [16:51] kirkland: FYI FeatureFreeze is in 3 weeks [16:51] mathiaz: and the live migration scripts [16:51] mathiaz: right [16:51] * kirkland is looking forward to FF :-) [16:51] * kirkland <--- late nights [16:51] ok - let's move on. [16:52] [TOPIC] Open Discussion [16:52] New Topic: Open Discussion [16:52] I updated https://help.ubuntu.com/community/ServerGUI to note the latest info on screen and screen-profiles. feel free to jump in [16:52] I have a quick question about the installer. are we going to be using lvm by default, there was some talk about it at UDS? [16:52] sommer: Noone's been working on it, AFAIK. [16:53] !screen [16:53] screen is a terminal multiplexer. See http://www.kuro5hin.org/story/2004/3/9/16838/14935 and http://en.wikipedia.org/wiki/GNU_Screen [16:53] I'll update that factoid also - input welcome [16:53] soren: okay, I just was wondering for documentation reasons [16:53] nealmcb: great - thanks. [16:53] [ACTION] nealmcb to update the screen factoids [16:53] ACTION received: nealmcb to update the screen factoids [16:55] anything else? [16:55] I might mention that ufw now has debconf/preseeding support [16:55] kirkland: I think you'll be lucky to get encrypted swap by default [16:56] cjwatson: not "by default" ... i've abandoned that [16:56] sommer: I saw that there had been a requirement mentioned for it, but nobody wrote up the UDS session *at all* [16:56] cjwatson: but "when encrypted home is selected", would be ideal [16:56] i.e. there's a server-installer-partitioning spec that doesn't even have a wiki link set [16:56] kirkland: I doubt that's feasible for jaunty. Sorry [16:56] cjwatson: right [16:56] cjwatson: ah, well maybe for jaunty+1 [16:56] does anyone care enough to watch the UDS videos corresponding to server-installer-partitioning and write it up so that I have some clue what the design is supposed to be? [16:57] I understood that it had got demoted in priority, which is why I haven't been making too much noise about it [16:57] cjwatson: let's discuss contingency plans next week. i'm thinking now about an ecryptfs-utils provided script that would do the magic for you, in some constrained cases. and then document/warn that it needs to be run, for more security [16:58] kirkland: it's already on the foundations agenda for next week [16:59] I think the encrypted swap session was at noon on the 11th: http://videos.ubuntu.com/uds/jaunty/Server/2008-12-11/morning-post-break/ [16:59] cjwatson: from my UDS notes and memory, it was only mentioned during the server raid discussion, as sort of a sidebar [16:59] cjwatson: awesome, i'll be there with bells on :-) [16:59] cjwatson: err the lvm discussion [16:59] ok - let's move on [16:59] [TOPIC] Agree on next meeting date and time === smarter_ is now known as smarter [16:59] New Topic: Agree on next meeting date and time [17:00] same place, same time, next week? [17:00] k [17:00] works for me :) [17:00] sommer: ok, that doesn't make it very easy to have a clue on what to implement, given that there are known problems with the post-installation tools [17:00] cjwatson: I think it was not actually help to allow for even more cloud discussions/ [17:00] cjwatson: I'll review what I have, though. [17:01] ok - see you all next week [17:01] same time same place here. [17:01] #endmeeting [17:01] Meeting finished at 11:01. [17:01] Hello Everyone.... Time for the Kernel Team Weekly Meeting... yay! [17:01] \o/ [17:01] * apw is here [17:01] * cking too [17:01] #startmeeting [17:01] Meeting started at 11:01. The chair is pgraner. [17:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:02] * smb_tp as well [17:02] Hey - what about next week? Maybe at the same time? [17:02] * nealmcb oops [17:02] * rtg is messing with encrypted file names. [17:02] [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting [17:02] LINK received: https://wiki.ubuntu.com/KernelTeam/Meeting [17:02] That is the agenda [17:03] [TOPIC] Security & bugfix kernels [17:03] New Topic: Security & bugfix kernels [17:03] Ok [17:03] smb_tp: whats new in your world? [17:03] Security is waiting just for the upload for dapper to intrepid [17:04] intrepid is a special upload as it is identical to the last proposed and hopefully very soon -updates kernel [17:04] (just a little test away) [17:04] why so "special"? [17:04] It diff only on the changelog [17:04] I didn't understand why pitti required a special upload [17:05] rtg, not pitty kees [17:05] So the -security kernel is just the same as the -proposed kernel? [17:05] He wanted to have the CVE visible [17:05] I think we need to talk about this stuff next week [17:05] BenC, correct [17:05] rtg, Agreed :) [17:05] smb_tp: so did the cve get uploaded to -proposed before it was sent to -security? [17:05] But with the current queue of intrepid I did not want to argue [17:06] BenC, The CVE's (on the current list) just were included in previous uploads already [17:06] smb_tp: Ah, makes more sense then [17:06] [ACTION] smb_tp to hold sidebar as sprint on this latest upload case [17:06] ACTION received: smb_tp to hold sidebar as sprint on this latest upload case [17:06] s/as/at/ [17:07] Ok [17:07] So, currently backing a bigger intrepid next-proposed [17:07] smb_tp: how are the upstream stable updates looking. I see there are a ton of them [17:07] We got two -stable updates there [17:07] :-) [17:08] Yeah, a few look important and scary, so I like to have them tested well [17:08] Scary in the sense that the muck around in mm [17:08] that's unpleasant [17:08] yea I saw that [17:08] they're pretty straightforward [17:08] And four of those patches are changing the AI [17:09] err ABI [17:09] smb_tp: any other things we should know about? [17:10] Lemme thin [17:10] Hardy will have to be reloaded after security [17:10] The request is to include there some vmware patches as well [17:11] Since they are bumping ABI I am abit reluctant there [17:11] * pgraner nods [17:11] Probably queueing them until there is another reason [17:11] * rtg is in favour of ABI bumps between major updates [17:12] We might do. The point release is done by now [17:12] smb_tp: anything else? [17:13] which is why I'd like to see an ABI bump [17:13] cking, Is doing some test with them. So if he finds them useful it might be more reason [17:13] No, thats all I can think of [17:13] smb_tp, they did not address the issue [17:13] frankly, the vmware patches alone are enough reason. [17:13] rtg, We beer it out next week [17:13] Great... moving on to everyones favorite topic.... [17:13] [TOPIC] Jaunty Status [17:14] New Topic: Jaunty Status [17:14] We have alpha 4 next thurs... [17:14] and a few actions according to the calendar [17:15] * Finalize the compiled in modules and online docs [17:15] * Finalize the removal of lrm and creation of DKMS pkgs [17:15] I think the list of built in modules is stable [17:16] wrt LRM: probably ain't gonna happen for Jaunty [17:16] * Document what we turned on from the /staging directory publicly [17:16] * Reduce grub timeout [17:16] staging: rt2860/2870 [17:16] grub timeout done [17:16] reduce grub timeout even further? [17:17] ah [17:17] cking: no that was the overall task needed to be complete [17:17] cking: I know it was hurting you the other day... [17:17] I uploaded 2.6.28.2 -stable Sunday, it just got NEWed an hour ago. [17:18] apw has submitted patches for vanilla kernel build, still reviewing [17:18] rtg: wrt to LRM then we need to move it off to Jaunty+1, what was the reason? [17:19] because of wl mostly. it is still required by default in some cases. [17:19] rtg: ok [17:20] rtg: on staging... those are the only drivers we enabled out of all the crap? [17:20] so far. [17:20] rtg: wlan-ng/prism wasn't enabled? [17:20] I thought we switched out everything that was duped in ubuntu/ [17:20] I've not had any requests [17:20] I also need to check for dupes. [17:21] [ACTION] rtg to check for /staging /ubuntu dupes... [17:21] ACTION received: rtg to check for /staging /ubuntu dupes... [17:21] debian/config/i386/config:CONFIG_PRISM2_USB=m [17:21] rtg: wlan-ng is enabled [17:21] in staging [17:21] BenC: but thats still under the ubuntu directory [17:22] rtg: ew...then we have ambiguous config options enabled [17:23] it only looks taht way, but in truth it won't compile unless you DTRT [17:23] we'll get both i assume [17:23] rtg: the one in staging is getting build...not the one in ubuntu [17:23] /lib/modules/2.6.28-5-generic/kernel/drivers/staging/wlan-ng/prism2_usb.ko [17:23] hmm, thats unexpected,. [17:23] would we not get both [17:23] BenC, do you have the ubuntu one? [17:24] even if we get both, the driver in staging is the one that gets loaded first. but, we need to weed out the dups [17:24] apw: nope, just the staging one is in -5 [17:25] apw: how are we looking for this round of suspend/resume? [17:25] the final bit for apport has been merged and uploaded [17:25] we have gotten a couple of reports back, so it is working (the automation) [17:26] apw: were they usefull? [17:26] one was a battery run flat the others seem real [17:26] s/usefull/useful/ [17:26] the only confusion is the users always seem confused and put [17:26] "i don't know why this poped up, so i have no idea what occured" [17:26] where they might have told us something useful [17:27] apw: yah, I've seen a few like that [17:27] that may be because its is saying crash in the output [17:27] that's good information - pitti and I discussed adding a new class of apport report for these, which would let us customize the presentation to the user [17:28] i also don'tknow why it asks for the description [17:28] as they really have no information at that point to put in the one liner [17:28] and appport knows its a suspend error [17:28] apport thinks it's a kerneloops [17:28] That was the most reasonable error type to report it under [17:28] sconklin: apport need some schooling [17:29] yeah but even for a kernel opps, popping up a box saying "summary of your bug" [17:29] Yes, I'll talk with pitti about it again [17:29] when the user has no clue whats in the report, isn't helpful [17:29] ogasawara: When is the next/updated call for testing going out? [17:30] apw: do we need any docs changes on the wiki for the changes that were made since A3? [17:30] pgraner: I can send it whenever we're ready, but I'd just assumed around Alpha4 [17:30] pgraner, not sure there is anything specific to that, but more review is needed overall [17:31] sconklin, add me to the conversation w/ Martin [17:31] ogasawara: fine by me :-) [17:31] lieb: ok [17:31] lieb: how crashdump/kernel oops going? [17:31] have a patchset for new kerneloops [17:31] crashdump next [17:32] I'll send it around after meeting [17:32] lieb: will it be in a4 or a5? [17:32] testing today, packaging this week [17:33] lieb: so I take it A4... [17:33] how long the pipeliine after that I don' tknow [17:33] i note kerneloops is not installed by default, are we planning on making it a default install [17:34] apw: mdz has agreed to it in principle [17:34] Martin sent me something about nominations and inclusion meetings... [17:34] apw: we need to talk to the foundations guys on that, lieb I'd ping robbiew and see what he says [17:34] we just need to check if it still runs as root or drops privilegs [17:34] ok [17:35] BenC: how did we make out with the removal of the ACPI suspend bits...? [17:35] pgraner: acpi support is making use of dbus-pm and dbus-hal by default [17:36] amitk, k-oops keeps root. it reopens /dev/dmesg each time [17:36] pgraner: so it's mostly unused, unless the user switches it manually in the config file [17:36] lieb, what does it use /dev/dmesg for? [17:37] something that running dmesg cannot do? [17:37] tries that first, then /var/log/messages [17:37] BenC: the task was to get rid of all but the one method of suspend... [17:37] lieb: that might be an objection to installing it by default. [17:37] pgraner: and it in affect is [17:37] pgraner: dbus-pm is the default...dbus-hal is the fallback [17:38] they are essentially the same method [17:38] BenC: the problem in the past was users were reading on the web to use acpi supsend and would turn it on or use the /etc/acpi/*.sh scripts, and complicate the bug reports... [17:38] BenC: are the scripts gone? [17:39] pgraner: No, I can easily remove it though...I must have misunderstood the reasoning behind it [17:40] BenC: ok, we are trying to present one unified way to suspend and keep the confusion down to a min [17:40] pgraner: understood [17:40] [ACTION] BenC to remove /etc/acpi/*.sh scripts [17:40] ACTION received: BenC to remove /etc/acpi/*.sh scripts [17:40] [TOPIC] Vanilla Kernel Builds [17:40] New Topic: Vanilla Kernel Builds [17:40] rtg, apw: sup with $TOPIC? [17:41] apw has presented some patches, still reviewing [17:41] I think we'll work it out next week [17:41] rtg: I raised the priority on the RT ticket for the git stuff [17:41] rtg: let me know if it stalls out and I'll escalate [17:41] yeah we have some scripts which seem to make workable kernels. so we need to get the environment to run them sorted out [17:41] thanks, it'll be required to fully implement vanilla builds [17:42] rtg: s/escalate/beg/g [17:42] pgraner: I'm sure the key folks that I need will be in Berlin [17:42] rtg: ack on that [17:43] rtg: what do estimate as a ETA for this? [17:43] sometime after A4 [17:43] rtg: thanks [17:43] [TOPIC] ARM [17:43] New Topic: ARM [17:43] amitk: anything to report? Welcome back from holiday :-D [17:44] thanks [17:44] where are the ARM porter machines? [17:45] I am finishing up changes to our build system to allows us to cross compile arm on our intel boxes [17:45] something like: debuild -b -eARCH=armel -eCROSS_MPILE=arm-linux- [17:45] rtg: I have the RT # and its still not complete [17:45] this should speed up kernel build testing quite a bit [17:45] amitk: that would be outstanding. [17:46] is there a cross compile tools package [17:46] ? [17:46] * apw cheers for that idea [17:46] ..and where is all this documented? [17:46] no. But I'll post instructions on how to get a tar ball and set up an environment [17:46] wfm [17:47] tarball yeeks [17:47] perhaps we can nudge doko to provide a cross-compile toolchain in berlin over beer [17:47] yeah i'd contribute a beer to the pot for that one [17:47] hey, I can live with tarballs. ANYTHING to speed up the builds. [17:47] besides this I am working through the OEM boards and patches [17:48] amitk: thanks... [17:48] over... [17:48] [TOPIC] LPIA [17:48] New Topic: LPIA [17:48] any news on the linux-omap merge ? [17:48] * pgraner pauses [17:48] amitk: ^^^^^^^^^^^^^ [17:48] ogra: still working with the maintainer to get a set of base patches [17:49] we'd like to somehow involve the community ... most of them have beagle boards, so having omap packages (at least for that) would gain us a lot user help [17:49] * amitk agrees [17:49] additionally we have a lot of n8x0 users [17:49] but merging the tree in its current state will cause a heavy maintenance burden [17:50] though thats not as pressing since the boot setup requires some tinkering anyway [17:50] yeah, indeed i dont want to push you into something like that :) [17:50] unfortunately I can't give a date. Only promise that it will happen :) [17:51] the current HW we support in the kernel doesnt really gain us much is the prob ... nobody will run ubuntu-desktop on his nslu2 :) [17:51] [TOPIC] LPIA [17:51] New Topic: LPIA [17:51] but thanks for the info so far [17:51] sconklin: how is that hairball? [17:52] aack, phpht [17:52] I have a handle on the differences between the netbook tree and ours - but [17:52] always a "but" [17:52] Just discovered that there is a separate branch in the netbook tree with some commits that are needed, so I'm looking at that [17:53] it's quite a hairball [17:53] and then next week we can discuss how to manage this moving forward [17:53] i'd like to know about the hardy patches [17:53] Not the one from the netbook tree, the ones in the hardy official tree [17:53] Living as lpia specific patches [17:54] It seems these are missing for proper support of some lpia devices both in intrepid and jaunty [17:54] can you provide some examples? [17:54] how about moving thios to the mailing list? [17:54] cool [17:54] debian/binary-custom.d/{lpia,lpiacompat}/patchset in ubuntu/ubuntu-hardy.git [17:55] rtg: ack on that... we are running down on time [17:55] I am not in a position to sort them out myself [17:55] [TOPIC] Open Discussion [17:55] New Topic: Open Discussion [17:56] So who's sending the hardy patches to the ML? [17:56] Anyone need to raise anything quickly as we only have 4 min left [17:56] lool i think we want you to remind us of where these patches are on the mailing list [17:56] nothing here [17:56] lool: add them to the pending issues thread [17:57] Hmm ok; albeit sconklin cking yourself and pgraner were in copy [17:57] amitk: it's in there... [17:57] Since the beginning [17:57] lool: ok.. i thought you had more examples [17:57] point 3) [17:57] Well I have more specific examples such as the SSD in the jax10 [17:57] in the list [17:57] Which I filed as a bug back in the intrepid cycle [17:57] As a result we have half the storage on the jax10 when running intrepid [17:58] perhaps we need to get some tags on the bugs so we can find them all [17:58] kernel-lpia or summat [17:59] I filed only one bug about these patches, but I discovered that the bug was a result of the patches being dropped and that's why I wanted them screened/reviewed [17:59] And possibly merged [17:59] lool: lets take this offline and get it sorted... we are about out of time. [17:59] There will not be a meeting next week due to the sprint in Berlin! [18:00] We will pick up the following week 9 Feb [18:00] we'll all bug you all the time in preson :P [18:00] *person [18:00] Thanks everyone [18:00] #endmeeting [18:00] Meeting finished at 12:00. [18:00] ogra: I'd prefer resolving at least some issues before the sprint [18:00] bye [18:00] lool, for lpia you mean ? [18:00] ogra: For whatever isn't low priority === calc_ is now known as calc === nhandler_ is now known as nhandler