/srv/irclogs.ubuntu.com/2009/01/27/#ubuntu-meeting.txt

=== _neversfelde is now known as neversfelde
robbmunsonbe back in just a few minutes, gotta restart kde02:05
=== 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
elkbuntuhmm.. must be the not-now week09:44
=== 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
cjwatsonKeybuk: around?15:01
cjwatsonKeybuk: clan says Matt and Mark won't be15:01
Keybukyup15:02
Keybukbadly timed typing break15:02
cjwatsonI don't see a whole lot of business, though15:03
cjwatsonpatent policy from mdz, presumably in abeyance until next week15:03
KeybukI think we have to do your swearing in :)15:03
cjwatsonyou can approve my subscription to technical-board@ if you like ;-)15:04
cjwatsonI swear to faithfully preserve, protect, and defend the code of conduct ... oh wait, that's the community council15:05
Keybukok, ML subscription approved15:05
Keybukwelcome aboard15:05
cjwatsonta muchly15:06
Keybukdholbach: are there any outstanding nominations we should consider?15:07
dholbachKeybuk: which were the last ones that you processed?15:07
dholbachKeybuk: I'll check the archives, hang on15:07
cjwatsondid we process the request for selective upload for Stefan Bader?15:07
cjwatsons/we/you/15:08
dholbachKeybuk: Dustin was the last one15:08
Keybukdholbach: Dustin Kirkland, Stephan Graber (LTSP)15:08
dholbachah yes, Stephane too15:08
Keybukcjwatson: we did, that was approved15:08
dholbachthen it's all resolved now15:08
cjwatsonI'm curious as to which applications are in the MC pipeline15:09
Keybuk * Open Applications: Nick Ellery (UUC), Jonathan Thomas (MOTU),15:09
KeybukMichael Casadevall (core-dev), Alessio Treglia (MOTU)15:09
dholbachthey'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
dholbachsome are lacking votes, some are lacking input from sponsors15:09
Keybuk*nods* the new process looked good15:10
dholbachthanks for the flowers15:10
dholbach:)15:10
KeybukI don't see anything from the other outstanding issues that is ready for discussion yet15:10
Keybukok, any business from anyone today?15:11
cjwatsonhas the calendar stuff from last meeting been resolved?15:12
cjwatsonit seems that we just need to invite the appropriate magic address15:12
cjwatsonI can do that now, if folks would like15:12
Keybukmatt recorded an action to follow up with the news team, but I don't know whether that has been done15:12
james_whttps://wiki.ubuntu.com/Fridge/Calendar15:12
Keybukthe technical board meeting still doesn't appear there15:13
cjwatsonlet me try15:13
james_wthey are now using google calendar, and the drupal calendar is abandoned15:13
cjwatsonthere it is15:13
cjwatsonthat should be the whole series added now15:14
cjwatsonand indeed http://fridge.ubuntu.com/calendar is now correct15:14
Keybukheh, did we both do that ?15:14
cjwatsonmaybe :)15:14
Keybukwell, it seems that google figured it out anyway ;)15:14
Keybukthat should be paired with the event our calendars, right?  so if we move it, it'll move on the fridge15:15
cjwatsonI *think* so15:16
cjwatsonDaniel asked if we could look at the per-package uploader proposal15:17
cjwatsonhttps://lists.ubuntu.com/mailman/private/technical-board/2009-January/002892.html15:17
Keybukgood idea15:18
dholbachpersia, soren, nixternal: around?15:18
Keybukhttp://pastebin.com/m2ea34e9115:19
Keybuk^ public viewable copy15:19
dholbachthanks Keybuk15:19
sorendholbach: hm?15:19
cjwatsonmy main concern, on a quick reading, is that ditching the expectation of social integration with the larger team altogether seems to invite problems15:19
cjwatsonI agree that per-package uploaders don't need to be quite so plugged into the development community as generalist developers15:20
dholbachsoren: talking about "per package upload" requirements15:20
Keybukcjwatson: 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 community15:20
Keybukalso that the MOTU team, as it currently stands, seems most effective at supporting its own members and potential members15:20
cjwatsonbut 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 cohesion15:20
Keybukand I'm not sure how per-package uploaders would get support for problems they encounter15:20
dholbachis there specific portion of the text that you'd like to be changed or something else to be added?15:21
cjwatsonI'm offering hopefully-constructive criticism rather than a patch :-)15:21
Keybuk  1) There is no expectation that the applicant meets the requirements15:22
Keybuk  of Ubuntu Membership, so the prior demonstration of significant and15:22
Keybuk  sustained contribution to Ubuntu is waived.15:22
Keybukas I understand it, we are explicitly talking about granting ubuntu membership rights to such uploaders15:22
dholbachcjwatson: 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
cjwatsonI'd sort of like the proposal to incorporate the notion that the candidate should be working with other Ubuntu developers rather than against them15:22
Keybuktherefore it seems alien to me that the requirements would be waived15:22
nixternalyo yo15:23
Keybukcjwatson: indeed, this goes on to specifically say that per-package uploaders need not be expected to work on the team or be integrated with it15:23
cjwatsonI 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 integration15:23
nixternaldholbach: what's up?15:23
cjwatsonthis 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 it15:24
dholbachI'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
Keybukotoh, where this has worked so far has been in the kernel team15:24
Keybukwhere there's explicitly an expectation that they do work with that team15:24
Keybukand 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 sponsorship15:25
cjwatsonI would be happier if the proposal said "There is a reduced expectation that the applicant is socially integrated ..." rather than "no expectation"15:25
dholbachStill 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
Keybukcjwatson: I'm not sure I'd even be happy with a reduced expectation15:25
Keybuksomebody who can upload to Ubuntu should see themselves as a fully socially integrated member of the Ubuntu Developer team15:25
KeybukI would rather the distinction was simply viewed as a technical one15:26
cjwatsondholbach: 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 happening15:26
cjwatsonor, at least, criteria that suggest that that's OK15:26
Keybuka per-package uploader is somebody with a specific skill set that uploads a package they are familar with15:26
cjwatson(obviously it's not put that way right now, I'm elaborating)15:26
Keybuka MOTU member is somebody who's skill set is wide and varied15:26
dholbachcjwatson: I definitely agree with what you're saying and will work with the MC to make it clearer in the proposal15:26
persiaI'm happy with the idea of requiring all developers to be members: that proposal was written some time ago.15:27
cjwatsonKeybuk: yeah, that matches my expectation more closely, I must say: narrow skills, broad openness to integration15:27
cjwatsondholbach: I certainly agree that the technical expectations are very different; no argument there15:27
dholbachKeybuk: 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 tell15:28
cjwatsonthe "does not grant sole-maintainership" bit in Emmet's proposal is good15:28
Keybukdholbach: those are the cases that worry me most15:28
Keybukbecause I forsee those people being so attached to their package that, if they are not also socially integrated with Ubuntu, will lead to difficulties15:28
Keybukthey might revert patches other Ubuntu developers make to their package15:29
Keybukthey might fail to participate in transitions or large-scale work that affects their package15:29
cody-somervilleThe barrier to MOTU is not overly high. Why even allow per-package uploader rights to not-motu?15:29
cody-somerville*non-motu15:29
Keybuk(and I would claim that this already happens)15:29
dholbachcody-somerville: because it's very hard to judge in cases like the one I described above15:29
cjwatsoncody-somerville: because, at the moment, the MOTU barrier involves demonstrating an ability and interest in general contributions15:29
persiaI'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:29
Keybukcody-somerville: MOTU has general upload access to the entire universe component, and as such, applicants are expected to be technically diverse in their skills15:30
cjwatsoncody-somerville: (and this is expected to evolve with archive-reorganisation)15:30
cjwatsonpersia: and I think that's OK, it's clearly not their interest15:30
KeybukI guess what'd I expect from per-package uploaders is somebody who meets all the social requirements of MOTU15:30
cody-somervilleThat doesn't seem to be the case. I see a lot of applicants get approved base on a sub-set of interest.15:30
persiaRight.15:30
Keybukand has made a sustained contribution15:30
cjwatsonpersia: as long as they don't block it15:30
Keybukbut only in a small subset of area15:30
cjwatsoncody-somerville: it has been a practical problem in a number of specific cases15:30
cjwatsoncody-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 MOTU15:31
KeybukMatthew East is a good example here, he has had a single package sponsored for a long time now, and is well integrated into Ubuntu15:31
dholbachKeybuk: 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
Keybukhe would seem to be an obvious choice, even though he is not a MOTU member15:31
Keybukdholbach: I think we go back to "why can't they be members of MOTU" ?15:31
cjwatsondholbach: the warning bell for me is when they start off by saying that Ubuntu's doing it all wrong :-)15:31
cjwatson(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:31
dholbachcjwatson: I'll make a note to check archives and Google for instances of them saying that before sending in my +1 :-)15:32
persiaKeybuk, 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
cjwatsonperhaps we could say "generalist developer" ;-)15:32
persiaThat might be even better, as it looks towards archive reorganisation.15:32
Keybukok, let me a little more specific15:32
dholbachKeybuk: being MOTU would not help mdke15:33
cjwatsondholbach: 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 reports15:33
cjwatsonmdke would pass that with flying colours15:33
dholbachcjwatson: sounds good15:33
KeybukIf 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:33
cjwatsonwell, because many packages aren't in any team smaller than "Ubuntu developers"15:34
dholbachKeybuk: 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
persiaKeybuk, What if there exists no such specialised team, and they are the only one who wants to work on that specific package?15:34
Keybukdholbach: let me pick up on a point there already15:34
Keybukyou suggest that they should already have been touching that package in Ubuntu15:35
Keybukassumedly through sponsorship15:35
KeybukI agree wholeheartedly15:35
dholbach*nod*15:35
Keybukthat they are liasing with users, upstreams and other distro maintainers suggests that they are using Launchpad and the Ubuntu Mailing lists already15:35
Keybukthe only difference to my mind:15:36
Keybuk- if they have contributed to a wide variety of different packages, they are suitable for a generalist team membership15:36
Keybuk- if their contribution has been to a narrow set of packages (or even just one), they are suitable for per-package upload rights15:36
Keybukall other requirements should be the same15:36
persiaI think there's three categories.15:37
persiaThere's generalist developers15:37
KeybukGeneralist UBUNTU Developers15:37
KeybukUbuntu developers who are generalists15:37
persiaThere's specialist developers in a given interest area (e.g. Xubuntu, Games, etc.)15:37
KeybukSpecialist UBUNTU Developers ;)15:37
persiaAnd there's people who want to work on *one* package.15:37
persiaYes, s//Ubuntu/ in all lines above.15:38
KeybukI see the one package as a very narrow interest area15:38
dholbachthat 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
cody-somervilleKeybuk, SUPER Specialist UBUNTU Developer?15:38
cody-somerville;]15:38
dholbachplease don't get caught up into nomenclature again :-)15:38
Keybukdholbach: does MOTU not already have this problem?15:38
persiaKeybuk, Is it worth creating the infrastructure of a layer for one person for one package?15:38
Keybukwhat 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:38
cjwatsonI don't think you should infer technical infrastructure (layers) from social structure (interest areas)15:39
dholbachKeybuk: 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
cjwatson(and no, it isn't worth it)15:39
Keybukdholbach: I think it's easier to judge someone's skills as a generalist15:39
Keybukbut not much more15:39
persiacjwatson, 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
dholbachKeybuk: I still think we should make that clear in the expectations we set15:39
Keybukquestions I might ask a prospective per-package uploader:15:40
Keybuk1. there's a new upstream version available; what's changed? why is it not packaged?15:40
cjwatsonpersia: 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 gain15:40
Keybuk2. you're not a bug contact for this package, why not?  (and -200 points)15:40
Keybuk3. there's several bugs that haven't yet been triaged in Launchpad, have you looked at these?15:40
Keybuk4. what are your thoughts on the open High priority bug #nnnn ?15:40
cjwatsonpersia: 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 other15:41
cjwatsonat least as far as the access controls go15:41
Keybuk5. package foo is quite similar, and uploads have been made by Ubuntu developer X - have you talked to them?15:41
cjwatson(now, obviously that's a bit down the line in terms of actual LP implementation, but)15:41
persiacjwatson, Agreed.  Similarly, I think we want slightly different requirements for per-package uploaders and uploaders to a layer.15:41
cjwatsonpersia: absolutely15:41
dholbachKeybuk: I'm very happy with the questions you ask and I'll make sure I'll massage that into the proposal.15:41
Keybukwhere a layer is aligned with a team, I'm actually less nervous because that developer is clearly joining an existing team15:42
persiaAnd presumably, is welcomed by the existing members of the team, who can provide support, mentoring, guidance, etc.15:42
Keybukit's the lone developer that worries me15:42
Keybukassumedly on a crusade to champion the cause of the innocent, the helpless, the powerless, in a world of...no, wait15:43
persiaThat's different :)15:43
cjwatsonlet's put it as "likely to require additional assistance", shall we? :)15:43
dholbachKeybuk, 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
persiacjwatson, Well, maybe.  Again, the handy example is Matthew East.15:43
dholbachI'll be moving the existing proposal back to the drawing-board. :-)15:44
dholbachThanks a bunch for your input15:44
cjwatsonpersia: well, he's a likely-to-pass candidate, not a dubious candidate, surely15:44
Keybukof 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 package15:45
Keybukthe other seems to be to be a developer who just wants to upload his package, and has not demonstrated a contribution to Ubuntu thus far15:45
Keybuk(avoiding names since it's unfair if they're not here)15:45
KeybukI think that the policy, as worded, does not encapsulate that difference - and in some ways seems to deliberately try and get rid of it15:46
persiaIf we add the requirement of Ubuntu Membership, as previously discussed, it makes the line much easier to draw.15:46
persiaThe 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:47
KeybukI think I would agree with that15:48
Keybukpersia: will you take the action to redraft the proposal and resubmit it to the TB?15:49
persiaKeybuk, Sure.  Am I just changing the Membership, or is there more? (I'll review the meeting log for details if the latter)15:49
cjwatsonI think it's a bit more than that; review the log15:50
persiaOK.  I saw a few things, and wanted to check :)15:50
cjwatsonI can give a brief update on the state of play with archive reorg15:51
Keybuklet's hold the issue of the candidates in abeyance until we agree on the policy15:51
Keybukcjwatson: please do15:51
Keybukwe have ~9 minutes15:51
cjwatsonI've introduced the notion of restricted layers into the spec15:51
cjwatsonI've added sections on how the ogre model will work, and on some anticipated community factors15:52
cjwatsonI've changed the proposed permissioning around to encapsulate what I believe to be current consensus15:52
cjwatsonthe permissioning has one rather curious feature15:52
cjwatsonit has a "core" layer, which remains necessary for the ogre model and for partial mirrors15:53
cjwatsonbut the permissions on the "core" layer are simply "Ubuntu [generalist] developers", the same as for all packages in no layers15:53
cjwatsonI think this is actually OK, and explain why I think that in the spec, but it does look a bit curious :)15:53
Keybukoh?15:54
cjwatsonI've explicitly introduced the term "general developers" (should probably change that to generalist)15:54
cjwatson"(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:54
Keybuksounds fair15:55
KeybukI'll re-read the spec ;)15:55
cjwatsonmy 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 archive15:55
cjwatsonI 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 like15:56
persiaOne 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
cjwatsonthis will both afford us the opportunity to test the tool changes, and let us work on the layer migration itself15:56
cjwatsonpersia: noted, will adjust15:56
cjwatsonthough 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:57
cjwatsonhaving an example layerised archive will let people play about and answer quite a few questions, I think15:58
cjwatsonthat will have to come with some basic tools to sync up with the current archive overrides15:58
persiaAlso, 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-dev15:58
cjwatsonI suspect that the resolution there is to call the merged one "Ubuntu Generalist Developer" or something15:59
cjwatsonbut I've been holding off on that because, frankly, it sounds clunky :-/15:59
persiaThat seems sensible.15:59
cjwatsonI don't have a better suggestion at the moment15:59
cjwatsonanyway, that's all from me for the moment - there'll be a call with the Soyuz team next week15:59
Keybukok, we're about to run into the server team meeting ...15:59
Keybukdo we have any other business?15:59
cjwatson(once Mark is back from gallivanting)16:00
cjwatsonnothing from me16:00
Keybukok, adjourned then16:01
Keybukthanks all16:01
nijabao/16:01
nealmcb\o16:01
Koon\o/16:01
* mathiaz waves16:01
mathiazLet's get the Ubuntu Server Team started16:02
mathiaz#startmeeting16:02
MootBotMeeting started at 10:02. The chair is mathiaz.16:02
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]16:02
mathiazToday's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting16:02
=== dendrobates- is now known as dendrobates
zulhi ho neighborarinos16:02
soreno/16:02
sommerhey all16:02
mathiazwhat a busy agenda! let's get moving16:02
mathiazLast week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/2009012016:03
mathiaz[TOPIC] SRU for ebox16:03
MootBotNew Topic:  SRU for ebox16:03
mathiazso I've uploaded ebox 0.12 to the new jaunty archive16:03
mathiazsommer: that means the SRU process for intrepid can move on.16:03
sommermathiaz: great, thanks16:04
mathiazsommer: do you have the three bug numbers?16:04
sommerone sec16:04
mathiazsommer: https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/27348616:05
ubottuLaunchpad bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,New]16:05
mathiazsommer: ok - I don't find the others16:06
sommerbug 25536816:06
ubottuLaunchpad bug 255368 in ebox "ebox: Depends: libapache-authcookie-perl but it is not installable " [Undecided,Fix released] https://launchpad.net/bugs/25536816:06
sommerand the dbug gconf one16:07
mathiazsommer: is there a bug number for the latter?16:07
sommermathiaz: bug 31460616:08
ubottuLaunchpad bug 314606 in ebox "ebox and libebox don't support Intrepid gconf version" [Undecided,Fix released] https://launchpad.net/bugs/31460616:08
sommerthat's them :)16:08
mathiazsommer: ok - I've just mark bug 273484 fix released16:08
ubottuLaunchpad bug 273484 in ubuntu "monitors wont go to sleep " [Medium,Incomplete] https://launchpad.net/bugs/27348416:08
mathiazsommer: https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/27348616:08
ubottuLaunchpad bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,Fix released]16:08
mathiazsommer: all the three bugs are fixed in jaunty and the intrepid SRU can move along.16:09
sommermathiaz: I'll get with foolano and whip up some new debdiffs16:09
mathiazsommer: the next step is to get the debdiff for the sru prepared, ACKed by the sru team and then sponsored to intrepid-proposed16:10
mathiaz[ACTION] sommer to prepare new debdiff for the ebox intrepid SRU16:10
MootBotACTION received:  sommer to prepare new debdiff for the ebox intrepid SRU16:10
mathiaz[TOPIC] ACL by default16:10
MootBotNew Topic:  ACL by default16:10
mathiazivoks: ^^ did you create a wiki page?16:11
ivoksmathiaz: nope :/16:11
ivoksmathiaz: probably tomorrow16:11
mathiazivoks: anything else to report on this topic?16:11
ivoksno16:11
mathiaz[ACTION] ivoks to create wiki page to keep track of ACL support in packages16:11
MootBotACTION received:  ivoks to create wiki page to keep track of ACL support in packages16:11
mathiaz[TOPIC] DRBD in jaunty16:11
MootBotNew Topic:  DRBD in jaunty16:11
ivoksdrbd is uploaded16:11
mathiazivoks: ^^ ? is dbd working in jaunty?16:11
ivoksyes16:11
mathiaz*drbd*16:11
mathiazivoks: what kind of test did you conduct?16:12
ivoksmathiaz: two vritualized machines16:12
ivoksi'll do upgrade tests too during this week16:12
mathiazivoks: could you write down some test instructions?16:12
ivokssure16:12
mathiazivoks: so that they can be put in a wiki page and other can also help out in testing16:13
ivoksof course... but in two-three days16:13
mathiazivoks: I'd suggest to create a subpage under https://wiki.ubuntu.com/Testing/Cases/16:14
ivoksok16:14
mathiaz[ACTION] ivoks to write a wiki page for conducting DRBD testing under https://wiki.ubuntu.com/Testing/Cases/16:14
MootBotACTION received:  ivoks to write a wiki page for conducting DRBD testing under https://wiki.ubuntu.com/Testing/Cases/16:14
mathiaz[TOPIC] Screen profiles16:15
MootBotNew Topic:  Screen profiles16:15
mathiazkirkland: what's the state of screen and screen-profiles now?16:15
kirklandmathiaz: screen-profiles is in main16:15
kirklandmathiaz: screen recommends screen-profiles16:15
nijabaand it kicks asses16:16
kirklandnijaba: yes, multiple asses :-)16:16
sommerheeeh16:16
kirklandmathiaz: so here's my question for the Ubuntu Server team .....16:16
* mathiaz plays the drums16:16
kirklandmathiaz: what could/should we do with the default /etc/screenrc ?16:16
cjwatsonconffiles and alternatives are unlikely to be friends; I recommend not using alternatives (as suggested in the agenda)16:16
ivoksi'm for vanilla /etc/screenrc16:16
kirklandcjwatson: okay, so not update-alternatives .....16:17
ivoksjust because most of the people expect that16:17
mathiazkirkland: how many different screen profiles are there now?16:17
nijabaivoks: a lot of people expect linux desktop to be command line only, if we go that direction...16:18
kirklandivoks: 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 Server16:18
kirklandmathiaz: for Ubuntu, 3 basically....  the plain vanilla one, ubuntu-light, and ubuntu-dark16:18
ivoksnijaba: that's correct, but i was thinking more about people who do know how to use cli and screen16:18
kirklandmathiaz: we also have profiles for debian, etc, but those are not installed on ubuntu16:18
kirklandivoks: they won't be using screen then16:19
nijabaivoks: run a test, and ask how many admin DO know about screen, you'll be surprised16:19
kirklandcjwatson: do you have any other suggestion, if not alternatives?16:19
cjwatsonI haven't looked into it at all; I was just raising a warning flag rather than purporting to have an alternative :)16:19
kirklandcjwatson: thanks16:20
mathiazkirkland: what are you trying to accomplish actually?16:20
cjwatsonalthough I would say, why is this a root-only thing?16:20
mathiazkirkland: IIUC you're asking what we should put in /etc/screenrc16:20
kirklandcjwatson: its not at all a root-only thing16:20
cjwatsonalternatives and other solutions that involve moving things around in /etc are root-only16:20
mathiazkirkland: and we have 3 choices16:20
kirklandcjwatson: any user can have this profile, if they run 'select-screen-profile'16:20
cjwatsonif you aren't focusing on root-only, you should be thinking about options that users can easily set16:20
nijabakirkland: what about it being installed by default with ubuntu-standard?  it is quite easy to put back to default16:20
cjwatsonah, well, who cares about what's in /etc then16:20
ivokshere's an idea...16:21
ivoksdefault screen prompts text, that nobody reads16:21
kirklandcjwatson: b/c that's what you get if you don't (know to) run 'select-screen-profile'16:21
ivoksis it possible to put a list of profiles there?16:21
ivoksthat would be selectable? :)16:22
ivoksjust an idea...16:22
nijabaivoks: in "select-screen-profiles" ?  that's alreay the case16:22
kirklandivoks: 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
nijabaand once screen is launched, you can change it using the screen profile helper16:22
ivokskirkland: no... you would run select-screen-profile16:22
mathiazkirkland: how does the sensible-editor selection work?16:22
ivokskirkland: and, on first run, let people choose16:22
kirklandivoks: i like that, choose on first run16:23
ivokskirkland: people that want plain screen, wouldn't notice anything16:23
ivokskirkland: they would just hit enter16:23
kirklandmathiaz: that's sort of how select-editor works16:23
ivokskirkland: people who run it for the first time, they would be 'wow, look at that...'16:23
kirklandmathiaz: ivoks: cool, i think that's a plan16:23
Koonmelikes ivoks plan16:23
mathiazkirkland: seems like we could try a similar workflow for screen profiles selection16:24
cjwatsonsounds appropriate16:24
mathiazkirkland: do you have an idea on how to do that?16:24
ivoksright, just as select-editor16:24
kirklandmathiaz: cheers.  thank you brilliant community16:24
Koonespecially as usual screen users are trained to ignore that screen anyway16:24
mathiazkirkland: are you planning to work on that?16:24
kirklandmathiaz: 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 screen16:25
kirklandmathiaz: i'll have it done by the end of today ;-)16:25
nijaba\o/16:25
ivoksnice16:25
mathiaz[ACTION] kirkland to implement screen-profiles selection tool16:25
nealmcbkirkland: 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/ServerGUI16:25
MootBotACTION received:  kirkland to implement screen-profiles selection tool16:25
ivoksgood job kirkland16:25
kirklandnealmcb: correct16:26
nealmcbwill do :)16:26
mathiazlet's move on16:26
mathiaz[TOPIC] EtcUnderRevisionControl status16:26
MootBotNew Topic:  EtcUnderRevisionControl status16:26
mathiazKoon: ^^ what's going on there?16:26
KoonJust a quick update on that project, which you may have heard (with the epic delay) at UDS16:26
ivoksi'm sorry, but i have to leave... bbl16:27
KoonThe design is finalized, it's heavily relying on etckeeper16:27
Kooneverything should be implemented directly into etckeeper16:27
KoonThe idea is to improve etckeeper and its bzr plugin to be a little more user-friendly16:28
mathiazKoon: is there anything to test?16:28
Koonmathiaz: not yet. I created a project and a team on launchpad16:28
Kooninterested people are welcomed to join, I already have Jelmer Vernooij (author of current bzr etckeeper featured) in16:29
mathiazKoon: is the spec up-to-date wrt to the implementation plan?16:29
Koonthe spec is up to date, ready to be accepted16:29
mathiazKoon: what are the names of the team and project in LP?16:29
jdstrandKoon: what's the project name in LP?16:29
Koonproject: etckeeper16:29
Koonteam: etckeeper16:30
jdstrandgee, I could have guessed that...16:30
Koonit's manually synced with the GIT tree16:30
Koonat upstream16:30
Koonand we have Ubuntu branches in there16:30
mathiazKoon: so you're waiting for the Spec to approved?16:30
Koonmathiaz: yes.16:30
KoonJoey Hess (upstream) has been quite open to intergating more advanced features16:31
Koonso they should find their way back into core16:31
mathiazKoon: great. You should ping dendrobates about aproving the spec16:31
Koonhe is pinged already16:32
jdstrandKoon: I haven't followed the spec closely since UDS. will this require changes to bzr as well?16:32
Koonjdstrand: it /could/ use a few more hooks16:32
dendrobatesKoon: he already did.16:32
dendrobateser mathiaz16:32
=== dholbach_ is now known as dholbach
Koonjdstrand: especially to catch all permissions-upsdating corner cases16:33
jdstrandKoon: not that it should be a factor in your devel work, but I was curious how easy it would be to backport to hardy16:33
jdstrandKoon: IIRC, the hooks cannot be done via bzr plugins-- is that accurate?16:34
mathiazdendrobates: are you planning to review the blueprint soon?16:34
dendrobatesmathiaz: yes.16:34
Koonjdstrand: hooks usually are in bzr core, and plugins use them16:34
* jdstrand nods16:34
Koonbut you could theorically add a hook by plugin, it just doesn't make much sense in the common scenario16:35
mathiaz[ACTION] dendrobates to review the etc-under-revision-control blueprint16:35
MootBotACTION received:  dendrobates to review the etc-under-revision-control blueprint16:35
mathiazok - let's move on.16:35
mathiaz[TOPIC] Server Team Bug Days16:35
MootBotNew Topic:  Server Team Bug Days16:35
mathiazzul: what's your idea?16:35
zulyeah 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 involved16:36
mathiazright. We had one bug day organized by the bug team16:37
mathiazthat was about 1 3/4 years ago16:37
zulwell we should have another one organized soonish16:37
mathiazso I'd suggest to ask the Bug team about it16:37
mathiazthey'd be more than happy to help out and we'd reach much more people16:38
mathiazthan just organizing a Server Bug day in the server team.16:38
mathiazbdmurray: what should we do to get a Server Team Bug day organized?16:38
zulwell thats what I was thinking as well we need someone to approach them16:38
dendrobatesmathiaz zul: I am arranging a discussion between all of us at the sprint.16:40
zulthats it from me :)16:40
zuldendrobates: nifty16:40
mathiazdendrobates: ok. We'll talk about this topic next week then.16:40
mathiazlet's move on16:40
mathiaz[TOPIC] ncrypted private/home with filename encryption available16:41
MootBotNew Topic:  ncrypted private/home with filename encryption available16:41
kirkland\o/16:41
mathiazkirkland: what did you do?16:41
kirklandi uploaded a new ecryptfs-utils-69 package that enables filename encryption, if your kernel supports it16:41
kirklandrtg on the kernel team backported ecryptfs filename encryption from 2.6.29 to 2.6.2816:41
kirklandand i completed the userspace bits this weekend to make this work with encrypted home and encrypted private16:42
mathiazkirkland: awesome.16:42
kirklandso, 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 dir16:42
kirklandand transparently decrypted for your in Private16:42
kirklandsame goes for encrypted home16:42
mathiazkirkland: so upgrade are automatically handled?16:43
kirklandmathiaz: dammit with the hard questions!16:43
kirklandmathiaz: :-)16:43
kirklandi still have some work to do on "live migration"16:43
kirklandwith some help from jdstrand, we came up with a theoretical design to solve this16:43
mathiazkirkland: ok - so you get filename encryption on new installs only.16:43
mathiazkirkland: for now16:44
kirklandi'm flying to Germany tomorrow;  i hope to hack that live migration script then16:44
kirklandmathiaz: right16:44
kirklandmathiaz: if you wanted to take advantage of this, you should backup your cleartext data elsewhere16:44
mathiazkirkland: ok - do you have specific instructions for testing this?16:44
kirklandmathiaz: then do a new ecryptfs-setup-private (fresh, empty dir)16:44
kirklandmathiaz: and then rsync your data back in16:44
kirklandmathiaz: i will blog about it this week16:45
cjwatsonnote that the desktop CD's still busted, this is server/alternate install CD only still16:45
mathiazkirkland: great.16:45
kirklandcjwatson <- is right16:45
kirklandbut i think we  (evand, cjwatson) mostly know whats wrong there16:45
mathiaz[ACTION] kirkland to make a call for testing filename encryption16:46
MootBotACTION received:  kirkland to make a call for testing filename encryption16:46
kirklandcjwatson: i have set ecryptfs-setup-private to automatically use filename encryption, if possible16:46
kirklandcjwatson: so no further changes in that respect should be required from you dudes16:46
mathiazexcellent news kirkland !16:47
mathiazkirkland: is there anything else to add on this topic?16:47
mathiazkirkland: once the installer has support for this is there anything else left to be done for jaunty?16:48
kirklandmathiaz: encrypted swap16:48
kirklandmathiaz: i *strongly* believe that any user using encrypted home or encrypted private should really be using encrypted swap16:49
mathiazkirkland: ok - that's a different (but related) topic16:49
mathiazkirkland: for encrypted directories I meant16:49
kirklandmathiaz: in such cases, all of the encrypted data lives as cleartext in memory16:49
kirklandmathiaz: should that memory get swapped to disk, it's swapped to disk in the clear, unless swap too is encrypted16:49
mathiazkirkland: is this something targeted for jaunty?16:49
kirklandmathiaz: in the very worst case, i plan on adding a script to ecryptfs-utils that would attempt to setup your system for encrypted swap16:50
kirklandmathiaz: to be run at the user's discretion after installation16:50
kirklandi'm guessing that this item probably won't make the installer at this point16:50
mathiazkirkland: ok. seems like a good first step.16:50
kirklandi hope to talk to the foundations team about this next week16:50
mathiazkirkland: FYI FeatureFreeze is in 3 weeks16:51
kirklandmathiaz: and the live migration scripts16:51
kirklandmathiaz: right16:51
* kirkland is looking forward to FF :-)16:51
* kirkland <--- late nights16:51
mathiazok - let's move on.16:51
mathiaz[TOPIC] Open Discussion16:52
MootBotNew Topic:  Open Discussion16:52
nealmcbI updated https://help.ubuntu.com/community/ServerGUI to note the latest info on screen and screen-profiles.  feel free to jump in16:52
sommerI 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
sorensommer: Noone's been working on it, AFAIK.16:52
nealmcb!screen16:53
ubottuscreen is a terminal multiplexer. See http://www.kuro5hin.org/story/2004/3/9/16838/14935 and http://en.wikipedia.org/wiki/GNU_Screen16:53
nealmcbI'll update that factoid also - input welcome16:53
sommersoren: okay, I just was wondering for documentation reasons16:53
mathiaznealmcb: great - thanks.16:53
mathiaz[ACTION] nealmcb to update the screen factoids16:53
MootBotACTION received:  nealmcb to update the screen factoids16:53
mathiazanything else?16:55
jdstrandI might mention that ufw now has debconf/preseeding support16:55
cjwatsonkirkland: I think you'll be lucky to get encrypted swap by default16:55
kirklandcjwatson: not "by default"  ... i've abandoned that16:56
cjwatsonsommer: I saw that there had been a requirement mentioned for it, but nobody wrote up the UDS session *at all*16:56
kirklandcjwatson: but "when encrypted home is selected", would be ideal16:56
cjwatsoni.e. there's a server-installer-partitioning spec that doesn't even have a wiki link set16:56
cjwatsonkirkland: I doubt that's feasible for jaunty. Sorry16:56
kirklandcjwatson: right16:56
sommercjwatson: ah, well maybe for jaunty+116:56
cjwatsondoes 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:56
cjwatsonI understood that it had got demoted in priority, which is why I haven't been making too much noise about it16:57
kirklandcjwatson: 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 security16:57
cjwatsonkirkland: it's already on the foundations agenda for next week16:58
nealmcbI 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
sommercjwatson: from my UDS notes and memory, it was only mentioned during the server raid discussion, as sort of a sidebar16:59
kirklandcjwatson: awesome, i'll be there with bells on :-)16:59
sommercjwatson: err the lvm discussion16:59
mathiazok - let's move on16:59
mathiaz[TOPIC] Agree on next meeting date and time16:59
=== smarter_ is now known as smarter
MootBotNew Topic:  Agree on next meeting date and time16:59
mathiazsame place, same time, next week?17:00
kirklandk17:00
sommerworks for me :)17:00
cjwatsonsommer: 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 tools17:00
dendrobatescjwatson: I think it was not actually help to allow for even more cloud discussions/17:00
dendrobatescjwatson: I'll review what I have, though.17:00
mathiazok - see you all next week17:01
mathiazsame time same place here.17:01
mathiaz#endmeeting17:01
MootBotMeeting finished at 11:01.17:01
pgranerHello Everyone.... Time for the Kernel Team Weekly Meeting... yay!17:01
Koon\o/17:01
* apw is here17:01
* cking too17:01
pgraner#startmeeting17:01
MootBotMeeting started at 11:01. The chair is pgraner.17:01
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]17:01
* smb_tp as well17:02
nealmcbHey - what about next week?  Maybe at the same time?17:02
* nealmcb oops17:02
* rtg is messing with encrypted file names.17:02
pgraner[LINK] https://wiki.ubuntu.com/KernelTeam/Meeting17:02
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting17:02
pgranerThat is the agenda17:02
pgraner[TOPIC] Security & bugfix kernels17:03
MootBotNew Topic:  Security & bugfix kernels17:03
smb_tpOk17:03
pgranersmb_tp: whats new in your world?17:03
smb_tpSecurity is waiting just for the upload for dapper to intrepid17:03
smb_tpintrepid is a special upload as it is identical to the last proposed and hopefully very soon -updates kernel17:04
smb_tp(just a little test away)17:04
pgranerwhy so "special"?17:04
smb_tpIt diff only on the changelog17:04
rtgI didn't understand why pitti required a special upload17:04
smb_tprtg, not pitty kees17:05
BenCSo the -security kernel is just the same as the -proposed kernel?17:05
smb_tpHe wanted to have the CVE visible17:05
rtgI think we need to talk about this stuff next week17:05
smb_tpBenC, correct17:05
smb_tprtg, Agreed :)17:05
BenCsmb_tp: so did the cve get uploaded to -proposed before it was sent to -security?17:05
smb_tpBut with the current queue of intrepid I did not want to argue17:05
smb_tpBenC, The CVE's (on the current list) just were included in previous uploads already17:06
BenCsmb_tp: Ah, makes more sense then17:06
pgraner[ACTION] smb_tp to hold sidebar as sprint on this latest upload case17:06
MootBotACTION received:  smb_tp to hold sidebar as sprint on this latest upload case17:06
pgraners/as/at/17:06
smb_tpOk17:07
smb_tpSo, currently backing a bigger intrepid next-proposed17:07
pgranersmb_tp: how are the upstream stable updates looking. I see there are a ton of them17:07
smb_tpWe got two -stable updates there17:07
pgraner:-)17:07
smb_tpYeah, a few look important and scary, so I like to have them tested well17:08
smb_tpScary in the sense that the muck around in mm17:08
ckingthat's unpleasant17:08
pgraneryea I saw that17:08
rtgthey're pretty straightforward17:08
smb_tpAnd four of those patches are changing the AI17:08
smb_tperr ABI17:09
pgranersmb_tp: any other things we should know about?17:09
smb_tpLemme thin17:10
smb_tpHardy will have to be reloaded after security17:10
smb_tpThe request is to include there some vmware patches as well17:10
smb_tpSince they are bumping ABI I am abit reluctant there17:11
* pgraner nods17:11
smb_tpProbably queueing them until there is another reason17:11
* rtg is in favour of ABI bumps between major updates17:11
smb_tpWe might do. The point release is done by now17:12
pgranersmb_tp: anything else?17:12
rtgwhich is why I'd like to see an ABI bump17:13
smb_tpcking, Is doing some test with them. So if he finds them useful it might be more reason17:13
smb_tpNo, thats all I can think of17:13
ckingsmb_tp, they did not address the issue17:13
rtgfrankly, the vmware patches alone are enough reason.17:13
smb_tprtg, We beer it out next week17:13
pgranerGreat... moving on to everyones favorite topic....17:13
pgraner[TOPIC] Jaunty Status17:13
MootBotNew Topic:  Jaunty Status17:14
pgranerWe have alpha 4 next thurs...17:14
pgranerand a few actions according to the calendar17:14
pgraner* Finalize the compiled in modules and online docs17:15
pgraner* Finalize the removal of lrm and creation of DKMS pkgs17:15
rtgI think the list of built in modules is stable17:15
rtgwrt LRM: probably ain't gonna happen for Jaunty17:16
pgraner* Document what we turned on from the /staging directory publicly17:16
pgraner* Reduce grub timeout17:16
rtgstaging: rt2860/287017:16
BenCgrub timeout done17:16
ckingreduce grub timeout even further?17:16
ckingah17:17
pgranercking: no that was the overall task needed to be complete17:17
pgranercking: I know it was hurting you the other day...17:17
rtgI uploaded 2.6.28.2 -stable Sunday, it just got NEWed an hour ago.17:17
rtgapw has submitted patches for vanilla kernel build, still reviewing17:18
pgranerrtg: wrt to LRM then we need to move it off to Jaunty+1, what was the reason?17:18
rtgbecause of wl mostly. it is still required by default in some cases.17:19
pgranerrtg: ok17:19
pgranerrtg: on staging... those are the only drivers we enabled out of all the crap?17:20
rtgso far.17:20
BenCrtg: wlan-ng/prism wasn't enabled?17:20
BenCI thought we switched out everything that was duped in ubuntu/17:20
rtgI've not had any requests17:20
rtgI also need to check for dupes.17:20
pgraner[ACTION] rtg to check for /staging /ubuntu dupes...17:21
MootBotACTION received:  rtg to check for /staging /ubuntu dupes...17:21
BenCdebian/config/i386/config:CONFIG_PRISM2_USB=m17:21
BenCrtg: wlan-ng is enabled17:21
BenCin staging17:21
rtgBenC: but thats still under the ubuntu directory17:21
BenCrtg: ew...then we have ambiguous config options enabled17:22
rtgit only looks taht way, but in truth it won't compile unless you DTRT17:23
apwwe'll get both i assume17:23
BenCrtg: the one in staging is getting build...not the one in ubuntu17:23
BenC /lib/modules/2.6.28-5-generic/kernel/drivers/staging/wlan-ng/prism2_usb.ko17:23
rtghmm, thats unexpected,.17:23
apwwould we not get both17:23
apwBenC, do you have the ubuntu one?17:23
rtgeven if we get both, the driver in staging is the one that gets loaded first. but, we need to weed out the dups17:24
BenCapw: nope, just the staging one is in -517:24
pgranerapw: how are we looking for this round of suspend/resume?17:25
apwthe final bit for apport has been merged and uploaded17:25
apwwe have gotten a couple of reports back, so it is working (the automation)17:25
pgranerapw: were they usefull?17:26
apwone was a battery run flat the others seem real17:26
pgraners/usefull/useful/17:26
apwthe only confusion is the users always seem confused and put17:26
apw"i don't know why this poped up, so i have no idea what occured"17:26
apwwhere they might have told us something useful17:26
ogasawaraapw: yah, I've seen a few like that17:27
apwthat may be because its is saying crash in the output17:27
sconklinthat'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 user17:27
apwi also don'tknow why it asks for the description17:28
apwas they really have no information at that point to put in the one liner17:28
apwand appport knows its a suspend error17:28
sconklinapport thinks it's a kerneloops17:28
sconklinThat was the most reasonable error type to report it under17:28
pgranersconklin: apport need some schooling17:28
apwyeah but even for a kernel opps, popping up a box saying "summary of your bug"17:29
sconklinYes, I'll talk with pitti about it again17:29
apwwhen the user has no clue whats in the report, isn't helpful17:29
pgranerogasawara: When is the next/updated call for testing going out?17:29
pgranerapw: do we need any docs changes on the wiki for the changes that were made since A3?17:30
ogasawarapgraner: I can send it whenever we're ready, but I'd just assumed around Alpha417:30
apwpgraner, not sure there is anything specific to that, but more review is needed overall17:30
liebsconklin, add me to the conversation w/ Martin17:31
pgranerogasawara: fine by me :-)17:31
sconklinlieb: ok17:31
pgranerlieb: how crashdump/kernel oops going?17:31
liebhave a patchset for new kerneloops17:31
liebcrashdump next17:31
liebI'll send it around after meeting17:32
pgranerlieb: will it be in a4 or a5?17:32
liebtesting today, packaging this week17:32
pgranerlieb: so I take it A4...17:33
liebhow long the pipeliine after that I don' tknow17:33
apwi note kerneloops is not installed by default, are we planning on making it a default install17:33
amitkapw: mdz has agreed to it in principle17:34
liebMartin sent me something about nominations and inclusion meetings...17:34
pgranerapw: we need to talk to the foundations guys on that, lieb I'd ping robbiew and see what he says17:34
amitkwe just need to check if it still runs as root or drops privilegs17:34
liebok17:34
pgranerBenC: how did we make out with the removal of the ACPI suspend bits...?17:35
BenCpgraner: acpi support is making use of dbus-pm and dbus-hal by default17:35
liebamitk, k-oops keeps root. it reopens /dev/dmesg each time17:36
BenCpgraner: so it's mostly unused, unless the user switches it manually in the config file17:36
apwlieb, what does it use /dev/dmesg for?17:36
apwsomething that running dmesg cannot do?17:37
liebtries that first, then /var/log/messages17:37
pgranerBenC: the task was to get rid of all but the one method of suspend...17:37
amitklieb: that might be an objection to installing it by default.17:37
BenCpgraner: and it in affect is17:37
BenCpgraner: dbus-pm is the default...dbus-hal is the fallback17:37
BenCthey are essentially the same method17:38
pgranerBenC: 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
pgranerBenC: are the scripts gone?17:38
BenCpgraner: No, I can easily remove it though...I must have misunderstood the reasoning behind it17:39
pgranerBenC: ok, we are trying to present one unified way to suspend and keep the confusion down to a min17:40
BenCpgraner: understood17:40
pgraner[ACTION] BenC to remove /etc/acpi/*.sh scripts17:40
MootBotACTION received:  BenC to remove /etc/acpi/*.sh scripts17:40
pgraner[TOPIC] Vanilla Kernel Builds17:40
MootBotNew Topic:  Vanilla Kernel Builds17:40
pgranerrtg, apw: sup with $TOPIC?17:40
rtgapw has presented some patches, still reviewing17:41
rtgI think we'll work it out next week17:41
pgranerrtg: I raised the priority on the RT ticket for the git stuff17:41
pgranerrtg: let me know if it stalls out and I'll escalate17:41
apwyeah we have some scripts which seem to make workable kernels.  so we need to get the environment to run them sorted out17:41
rtgthanks, it'll be required to fully implement vanilla builds17:41
pgranerrtg: s/escalate/beg/g17:42
rtgpgraner: I'm sure the key folks that I need will be in Berlin17:42
pgranerrtg: ack on that17:42
pgranerrtg: what do estimate as a ETA for this?17:43
rtgsometime after A417:43
pgranerrtg: thanks17:43
pgraner[TOPIC] ARM17:43
MootBotNew Topic:  ARM17:43
pgraneramitk: anything to report? Welcome back from holiday :-D17:43
amitkthanks17:44
rtgwhere are the ARM porter machines?17:44
amitkI am finishing up changes to our build system to allows us to cross compile arm on our intel boxes17:45
amitksomething like: debuild -b -eARCH=armel -eCROSS_MPILE=arm-linux-17:45
pgranerrtg: I have the RT # and its still not complete17:45
amitkthis should speed up kernel build testing quite a bit17:45
rtgamitk: that would be outstanding.17:45
rtgis there a cross compile tools package17:46
rtg?17:46
* apw cheers for that idea17:46
cking..and where is all this documented?17:46
amitkno. But I'll post instructions on how to get a tar ball and set up an environment17:46
rtgwfm17:46
apwtarball yeeks17:47
amitkperhaps we can nudge doko to provide a cross-compile toolchain in berlin over beer17:47
apwyeah i'd contribute a beer to the pot for that one17:47
rtghey, I can live with tarballs. ANYTHING to speed up the builds.17:47
amitkbesides this I am working through the OEM boards and patches17:47
pgraneramitk: thanks...17:48
amitkover...17:48
pgraner[TOPIC] LPIA17:48
MootBotNew Topic:  LPIA17:48
ograany news on the linux-omap merge ?17:48
* pgraner pauses17:48
pgraneramitk: ^^^^^^^^^^^^^17:48
amitkogra: still working with the maintainer to get a set of base patches17:48
ograwe'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 help17:49
* amitk agrees17:49
ograadditionally we have a lot of n8x0 users17:49
amitkbut merging the tree in its current state will cause a heavy maintenance burden17:49
ograthough thats not as pressing since the boot setup requires some tinkering anyway17:50
ograyeah, indeed i dont want to push you into something like that :)17:50
amitkunfortunately I can't give a date. Only promise that it will happen :)17:50
ograthe 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
pgraner[TOPIC] LPIA17:51
MootBotNew Topic:  LPIA17:51
ograbut thanks for the info so far17:51
pgranersconklin: how is that hairball?17:51
rtgaack, phpht17:52
sconklinI have a handle on the differences between the netbook tree and ours - but17:52
pgraneralways a "but"17:52
sconklinJust discovered that there is a separate branch in the netbook tree with some commits that are needed, so I'm looking at that17:52
ckingit's quite a hairball17:53
sconklinand then next week we can discuss how to manage this moving forward17:53
looli'd like to know about the hardy patches17:53
loolNot the one from the netbook tree, the ones in the hardy official tree17:53
loolLiving as lpia specific patches17:53
loolIt seems these are missing for proper support of some lpia devices both in intrepid and jaunty17:54
sconklincan you provide some examples?17:54
rtghow about moving thios to the mailing list?17:54
sconklincool17:54
looldebian/binary-custom.d/{lpia,lpiacompat}/patchset in ubuntu/ubuntu-hardy.git17:54
pgranerrtg: ack on that... we are running down on time17:55
loolI am not in a position to sort them out myself17:55
pgraner[TOPIC] Open Discussion17:55
MootBotNew Topic:  Open Discussion17:55
loolSo who's sending the hardy patches to the ML?17:56
pgranerAnyone need to raise anything quickly as we only have 4 min left17:56
apwlool i think we want you to remind us of where these patches are on the mailing list17:56
apwnothing here17:56
amitklool: add them to the pending issues thread17:56
loolHmm ok; albeit sconklin cking yourself and pgraner were in copy17:57
loolamitk: it's in there...17:57
loolSince the beginning17:57
amitklool: ok.. i thought you had more examples17:57
ograpoint 3)17:57
loolWell I have more specific examples such as the SSD in the jax1017:57
ograin the list17:57
loolWhich I filed as a bug back in the intrepid cycle17:57
loolAs a result we have half the storage on the jax10 when running intrepid17:57
apwperhaps we need to get some tags on the bugs so we can find them all17:58
apwkernel-lpia or summat17:58
loolI 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/reviewed17:59
loolAnd possibly merged17:59
pgranerlool: lets take this offline and get it sorted... we are about out of time.17:59
pgranerThere will not be a meeting next week due to the sprint in Berlin!17:59
pgranerWe will pick up the following week 9 Feb18:00
ograwe'll all bug you all the time in preson :P18:00
ogra*person18:00
pgranerThanks everyone18:00
pgraner#endmeeting18:00
MootBotMeeting finished at 12:00.18:00
loologra: I'd prefer resolving at least some issues before the sprint18:00
amitkbye18:00
ogralool, for lpia you mean ?18:00
loologra: For whatever isn't low priority18:00
=== calc_ is now known as calc
=== nhandler_ is now known as nhandler

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!