=== _neversfelde is now known as neversfelde [00:58] when is the next ubuntuforums council meeting? [06:51] morning [06:52] hiya huats [06:54] hey dholbach [06:56] @schedule rome [06:57] emgent, The bot doesn't know the schedule since the transition to the new calendar. If you (or anyone) can make SupyBot understand Google Calendar and recurring events, it can be reenabled. [06:58] \o [06:58] morning scottK [06:58] hello ScottK [06:59] ola [07:00] hello everybody! :) [07:00] soren: around? [07:00] o/ [07:00] yoohoo [07:00] didrocks, huats, Laney: alive and doing well as well? :) [07:01] dholbach: alive, for sure, at least ;) [07:01] * jono high-fives everyone :) [07:01] didrocks: nervous? ;-) [07:01] alive yeah.... and sleeping an bit :) [07:01] we have an action-packed agenda: https://wiki.ubuntu.com/MOTU/Council/Meeting [07:01] dholbach: no, it's ok. Just surprised to see huats wake up so early :p [07:01] let's first chat a bit with Didier Roche [07:01] :-) [07:01] https://wiki.ubuntu.com/DidierRoche/MOTUApplication [07:02] didrocks: you said that you worked on the bzr-desktop documentation - how did that work out generally? [07:03] is it an easy, intuitive process? something that could be done by default? [07:03] dholbach: there were an original and deprecated documentation for bzr-desktop team. As I am found of Vcs, I wanted to try to put some packages in bzr [07:03] so, asking for some tips to james_w, I try to make it easier to use in the process [07:03] and rewrote the documentation [07:04] I think now it's quite easy to use. Putting a package in bzr is quite easy nowadays [07:04] and then, updating a package in bzr is just fantastic :) [07:04] I think that, as usual, the first step is the harder one [07:04] but then, it's a gain of time, when you have to diff between two revision, and so on… [07:05] right [07:05] all the desktop packages just store the packaging in bzr, right? [07:05] erm... some of the desktop packages :) [07:05] we are putting them one by one :) [07:05] using bzr merge mode [07:05] and not everyone [07:05] right, but you don't store the actual source there, right? [07:05] yes, the merge mode is used to only store debian/ folder [07:06] could some of the DesktopTeam/Bzr docs go into DistributedDevelopment? [07:06] I think, yeah, there is some updates to do accordingly to branch destination, but I think I can handle that easily [07:07] super [07:07] I have to discuss with james_w about synchronisation [07:07] ah... talking about documentation: did you document the dh_install --list-missing pbuidler hook? :-) [07:07] because ATM, packages in ~desktop-team aren't synchronised if someone do not use bzr [07:07] dholbach: it's on my schedule [07:07] I want to better document hook [07:07] didrocks: great, it's going to be handy for lots of others as well [07:08] dholbach: it's written in the ~desktop documentation one [07:08] didrocks: where's that? [07:08] but also, I want to change some little things in the proposed hook [07:08] dholbach: https://wiki.ubuntu.com/DesktopTeam/Bzr [07:08] (in updating a package) [07:08] but, for instance, there is a hook that install/remove/install/purge… [07:09] it's using depkg -i *.deb [07:09] dpkg [07:09] but when you use pbuilder, the external runtime dependency aren't install [07:09] I was thinking of changing it for dpkg -i *.deb || apt-get install -f [07:09] to avoid crashing on unresolved dependency [07:10] didrocks: you could take a look at the check-symbols script, I think kees added some functionality there to do something similar [07:10] dholbach: ok, I will, I just have used this script once and I have to review huats' work on it :) [07:11] Is it OK if I jump in with a question? I need to get to bed. [07:11] ScottK, Yes. [07:11] ScottK: fire away [07:11] didrocks: I see you used to use KDE. Have you tried KDE4 yet? (this isn't my actual question) [07:11] ScottK: hehe. I was sure it was KDE related :) [07:12] ScottK: I saw KDE 4.2 in FOSDEM and I was really impressed [07:12] In the Kubuntu team we are also using bzr to store the debian dir. The basic is https://wiki.kubuntu.org/Kubuntu/Ninjas/ReleasePackaging [07:12] especially with the "activities" dimension [07:12] I will have a look at the Ninjas' documentation [07:12] I was wondering if given your interest in bzr and desktop team you might be interested in working with us a bit and see how the two work flows compare. [07:13] See what we can learn from each other ... [07:13] so, yes, KDE 4.2 is a great step forward. I really want to see 4.4 when activities will be bind to worspakces [07:13] * ScottK didn't pick the names ... [07:13] ScottK: for sure [07:13] ScottK: I will have a look and see how we can bind our workflows [07:13] vorian: ^^^ Be sure to grab this one the next release. [07:14] that sounds like a good idea [07:14] I don't know that it makes sense to 'bind' them, but see what we can learn from each other. [07:14] * ScottK sits down. [07:14] thanks scottK [07:14] didrocks, One of your endorsements mentions small mistakes in upload candidates. What strategies do you expect to use to avoid these in the future? [07:15] persia: my mistakes were mostly in my first uploads (something like september?) [07:15] I was more typos and stuff like that [07:15] (I remember a LP:# ...) [07:15] persia: I think having commit rights is well different [07:15] and this kind of responsibality will make you check things 3 or 4 times :) [07:16] and as I said "when I don't know, I ask" [07:16] Fair enough. [07:16] didrocks: You mention the server team a bit in your application. How have you found working with the server team? Is there anything we could do to improve? [07:16] seb128 and dholbach are used that I bothered them with question [07:17] soren: I must say that I worked less recently with the desktop team. desktop team is time consuming :) [07:17] but well, I really want to get involved in both team [07:17] I find there very kind people and I think it's easy to get involved [07:17] I hope that, for instance, integration of upstrart, writing event script can make people join the team [07:17] upstart* [07:18] for improvement, well [07:18] I think more call for volonteer in special project can be a great help in that [07:18] Really? That's interesting. [07:19] as I get involved with removal of "multiuser" in init scripts :) [07:19] I think we often tend to aim wide to reach more people, but perhaps we should be more specific and just ask more often? [07:20] yeah, because people are some times, a little bit afraid, I reckon [07:20] that reminds me of james_w saying "if people scratch their own itches, maybe we need more itching powder" :) [07:20] Heh :) [07:20] knowing that "I can help on that" is easier for them to start [07:20] dholbach: that's true :) [07:20] didrocks: one thing I was really interested to read was your experience with Africedu - was it an experience you'd recommend to somebody else? would you do it again? what was the most challenging thing for you? [07:20] Africedu was really a great experience [07:21] I think I can share the video (30 minutes) of all the project [07:21] I would recommend to everyone who has a lot of time (one year project) [07:21] didrocks: I'd be very very very interested to see it [07:21] the non governemntal organization still exists [07:21] dholbach: Don't get any ideas. We need you here :) [07:21] it has 10 years now [07:22] every one, with a new team a new African country [07:22] so, it's really a human adventure [07:22] within the team (working together…) [07:22] that sounds absolutely fantastic [07:22] and in communication, working with people with different way of living, culture… [07:22] sharing knowledge, etc. [07:23] the most challening part is as usual [07:23] money! [07:23] it's was quite hard to raise enough founds [07:23] to ship computers there [07:23] the most easy part is to find computers :) [07:23] Ok, let's chat about that some other time again - maybe you should write a long blog post about what you did there :-) [07:23] soren, persia: any more questions? [07:24] Also, you mention an interest in a content control mechanism. Last month, it was mentioned that Ubuntu ME and ichthux both claim to have one on their websites. Is your solution similar to the ones used there, or independent? [07:24] dholbach: for sure, it's quite old now, but why not, posting with the video :) [07:24] No, I'm good :) [07:24] persia: my solution is independant.; I search a lot time for such controls [07:24] but there aren't at all user friendly to me [07:25] you can find the result of my research at https://edge.launchpad.net/gchildcare [07:25] (if you want, I can give you more direct pointers) [07:25] but they are not integrated in the desktop environment [07:25] I really want to follow some KISS rules [07:25] Do you have any plans to coordinate with others to build a content control model that can be shared by all interested flavours? [07:26] I have already a guy with another team who joined me [07:26] and a OOo developper who wants to develop a plugin on it [07:26] (so, I have still to develop the plugin mecanism ;)) [07:26] OK. I'm good. [07:26] Votes [07:26] +1 [07:27] +1! [07:27] +1 [07:27] congratulations didrocks! [07:27] dholbach: thanks \o/ [07:27] :-) [07:27] * persia wonders if we oughtn't use MootBot [07:27] congratulations my friend ! [07:27] congrats didrocks!! :) [07:28] persia: maybe next time? :) [07:28] thanks huats , it will be your turn soon :) [07:28] * didrocks hugs jono [07:28] didrocks: let's see... [07:28] next up: https://wiki.ubuntu.com/ChristopheSauthier/MOTUApplication [07:28] dholbach, Sounds like a plan. [07:28] hey everyone [07:29] huats: you've been quite involved in the Desktop team as well - what was your experience like? what do you think should be easier? [07:29] I think my experience was great :) [07:29] the guy are really great [07:29] seb128 is always present by instance [07:30] may be it might be interesting to continue the work that was started by norsetto to know the states of the various packages [07:30] I think that right now the centralised model we are using in the distribution of work is not optimal [07:30] what could be improved there? have a link to the page? [07:31] and a webpage listing the various states would be better [07:31] http://norsetto.890m.com/desktop_packages.php [07:31] persia: gracias [07:31] thanks persia [07:31] I think integrating that and most of all, using it might be a more efficient way [07:32] to distribute the work [07:32] I have talked a bit with seb about that [07:32] huats, You mention you dislike the merging process, and raise this tracker in discussion of the Desktop Team experience. How would you adjust or improve the workflow if you were responsible for a new definition? [07:32] clearly it was a question of lack of time if it hasn't been done so far [07:32] do you have examples of what should be changed on there to make the Desktop team more efficient? [07:33] persia: I will start with your question (sorry dholbach) [07:33] huats: take your time [07:33] persia: I said it was one of the thing I like the least [07:33] since there was something to fond :) [07:33] found [07:33] as I said [07:34] I haven't done tons merges [07:34] and that is probably the reason [07:35] persia: I really think that may be using bzr (or svn in the debian collaboration) might be a solution [07:35] to ease the process [07:35] besides [07:35] huats, How so? Do you mean the manual merge effort, or the tracking of necessary variance? You mention working upstream to avoid needing to merge (which is nice), but there are cases where we cannot do that. [07:36] I do think that the workflow is great as it is, and I don't see how we can simplify it [07:37] persia: one of the advantage of using a VCS might be the revision grouping of modifications [07:37] in the same revision you will likely to find things that are related [07:37] so you can sort them more easily, and keep the one you need [07:38] the manual merge effort still have to be here... [07:38] and of course there are cases where the upstream collaboration is not possible... [07:39] persia: did I answer your question and can deal with dholbach one ? [07:40] Sure. [07:40] dholbach: so improvments... [07:40] so far we are working mainly on a centralized way, where people go to the channel and ask seb : what can I do... [07:41] he is the only one who is keeping records of the stuffs that are needed to do [07:41] it might be better to use a common place to store that [07:41] there used to be a wiki page [07:41] but it was not very useful... [07:42] since you have to deal with colors and stuffs like that [07:42] having the same kind of page that persia pointed out in the url [07:42] might be better [07:42] so you're saying that it's not clear enough to newcomers what needs doing and what needs special attention? [07:43] you can annotate it, saying that you wokr on that (to avoid dupplicate work) [07:43] exactly [07:43] and you have the various versions available... [07:43] sounds like a good topic for ubuntu-desktop@, what do you think? :) [07:43] well it helps for the beginners AND for people who are daily working on it [07:44] absolutly [07:44] :) [07:44] there was a thread already [07:44] (in september if I remember well) [07:45] but it was too close of the intrepid release I think... [07:45] that might be [07:45] (and you need some time to be able to set an infrastucture) [07:45] even if in that case, it is almost done [07:45] (apparently vuntz is using the same kind of stuffs in the opensuse team) [07:46] huats: can you give us a quick update from the MOTU Mentoring Reception? [07:46] dholbach: sure :) [07:46] we have currently something like 20 mentee in the junior program [07:46] and 2-3 in the senior one [07:47] we are a bit short on mentors available everywhere except in europe (the location is important because we try to match mentee/mentors in the same timezone) [07:47] currently the main problem is that people sometime drop the mentoring program after a few days... [07:48] We have noticed that if your mentee is still here after 2 weeks you have good chances to keep him [07:49] I am thinking of asking every mentee to have like a bugpage, where he put the things he did... [07:49] (using the example of the great didrocks) [07:49] sounds like that would help to keep track of what the mentees are doing [07:49] (I told myself, "hum… it reminds me something"… ;)) [07:49] so that it will be easier for us (the mentoring team) to notice people who are not doing stufs lately.... [07:50] and so we can contact him quite fastly enough... [07:50] dholbach: exactly [07:50] currently I am sending an email to every mentors (something like every2 monthes) [07:50] and I am dealing with the answers... [07:50] huats: who's helping out in the mentoring reception at the moment? is it just you? [07:51] dholbach: were a 3 in the reception team [07:51] porthose and nxvl [07:51] but they are currently quite busy [07:51] so for some monthes I a bit alone... but they promised me they will be back ;) [07:51] and I trust them :) [07:51] ok :) [07:52] a question that was bound to come up: Mr 4k: how do we get those 4000 people in Paris to help out in Ubuntu development? [07:52] :-) [07:52] LOL [07:52] by doing more and more stuffs in France :) [07:52] I think it should be a requirement of his approval [07:52] at least 50% become MOTU in a year :) [07:52] jono: thanks :) [07:52] I might need some help in the mentoring reception then :) [07:53] dholbach: I think bugs jams are a very good start [07:53] huats: so you're going to do the "developers developers developers" dance in Paris next time? [07:53] we are doing one in paris for the global one [07:53] (didrocks chairing it) [07:54] and I am doing one in Toulouse too [07:54] (http://blog.didrocks.fr/index.php/post/What-to-do-after-Fosdem-Bug-jam! for more information) [07:54] yeah, if we are doing it with didrocks :) [07:54] didrocks, huats: promise? :) [07:54] ok... I'm all set :-) [07:55] soren, persia: any more questions? [07:55] you are of course invite to take pictures ;) [07:55] or to participate [07:55] :) [07:55] Nope, I'm good :) [07:55] huats: I'm sorry, I don't know how to translate "developer" into French :) [07:55] the same word [07:55] dholbach: développeur (2 p) :) [07:55] developpeur [07:56] that's easy enough then :) [07:58] soren, Anything? [07:58] Nope, I'm good :) [07:58] persia: anything else from you? [07:58] What dholbach said :) [08:01] Nothing else from me. [08:01] OK [08:01] Votes [08:01] +1 [08:01] +1 from me [08:02] soren: Señor Hansen? :) [08:03] +1 from me too! [08:03] congratulations huats! [08:03] :-) [08:03] * didrocks hugs huats [08:03] * pochu cheers huats :) [08:03] congrats my friend :) [08:03] thanks guys ! [08:03] congrats huats! :) [08:03] * soren had an angry baby that needed a bit of attention.. Sorry. [08:03] * huats hugs didrocks dholbach pochu persia soren [08:03] soren: I thought you wanted to keep the suspense high :) [08:03] Laney: around? [08:04] dholbach: I'm sure of that, soren likes this ^^ [08:04] soren, drama queen...making huats wait :) [08:04] ;) [08:04] jono: Yeah, I'm like that. :) [08:04] hehe [08:04] soren: I knew it [08:04] Laney...a man named after my very first guitar amplifier [08:04] no surprises there [08:04] that has to be a reason for approval [08:04] * jono chuckles [08:04] I hope Laney is not having second thoughts [08:05] jono: :) [08:05] quoting from https://wiki.ubuntu.com/IainLane/MOTUApplication - section Areas of Improvement: "Iain is unfortunately not very good at applying for MOTU when he should, often waiting some months too long. " [08:06] dholbach: that's quite a good quotation which can be verified :) [08:06] I guess he hasn't practiced very much :) [08:07] I am sorry, I really have to go to work now (more than one hour of transportation, Paris \o/) [08:07] Well, perhaps this is the practice run :) [08:07] so you later guys and thanks again ;) [08:07] see* [08:08] persia, soren: should we wait a few minutes for Laney to show up or organise an impromptu meeting or ask to show up in the next meeting? [08:08] or is there a different option you see? [08:09] I'm for waiting up to 7 minutes, and then asking for attendance at the next meeting. [08:09] I'm with persia. [08:09] alrighty [08:09] Unless the time is bad for Laney, though. [08:09] AFAIK he lives in the UK. [08:09] Well, that's the asking part. If it's not good, we can expect him to respond, or reschedule. [08:10] Ok, so 1700 UTC should be good for him, I suspect. [08:11] he was here at the begnning of the meeting [08:12] huats: I don't think he replied here [08:12] He was? [08:12] Not in my backscroll, but perhaps not set Away. [08:12] dholbach: oh [08:13] may be I mixed it indeed... [08:13] last thing he said yesterday in #ubuntu-motu: [23:11 UTC] * Laney cuddles Debian :) [08:14] :) [08:17] persia: do you think you can send Laney a mail about it? [08:17] Sure. [08:17] I'd take the action points of processing the applications of huats and didrocks :) [08:18] Next meeting: Feb 26th, 17:00 UTC. [08:18] Any other business? [08:19] Going once [08:19] twice [08:19] Thanks everybody. Adjourned. [08:21] dholbach: I have to go [08:21] (going to work) [08:21] huats: have a great day [08:21] thanks everyone [08:21] dholbach: I am sure it will :) === mvo__ is now known as mvo [09:44] oh CRAP! [09:52] o/ [09:52] We're back for an impromptu meeting of the MOTU Council because of mis-scheduling... or something. [09:52] :$ [09:52] persia: want to drive MootBot? [09:53] there is an irc council meeting in a few minutes [09:53] boredandblogging: takes ~an hour? [09:54] I mean... does your meeting roughly take an hour? [09:54] #ubuntu-mc-meeting? [09:54] dholbach: an hour should be fine [09:54] soren, Not logged. [09:54] soren: we could do it afterwards? [09:54] * persia won't be available in an hour [09:54] persia: Point. [09:55] geser, soren, Laney: would you guys be there? [09:55] I'm here all day [09:55] Yes. [09:55] besides 1-2pm [09:55] * dholbach would be there too [09:55] dholbach: that would also give me an hour for a crash review of Laney application [09:55] excellent [09:55] * Laney sets numerous alarms [09:55] let's recovene in an hour then [09:55] !schedule [09:55] Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases [09:55] erm [09:56] * Laney cannot remember the command [09:56] Laney, It's disabled for now. [09:56] right [09:56] thanks boredandblogging [09:56] Laney, Essentially, Supybot needs a plugin to parse Google Calendar feeds. [10:04] elky, jussi01, Pici, Pricey: ping [10:04] o hai [10:04] o/ [10:04] hello! [10:05] where is nal? [10:05] not here unless he has to be, i'd guess [10:06] pong [10:07] should we give nalioth a couple of minutes? [10:08] he appears to be detached, judging by his /away [10:08] Pici: said he is busy, no? [10:08] we also have a quorum here, and a queue waiting behind us [10:09] true [10:09] well lets et it hppening [10:09] someone got a link to an agenda? [10:09] https://wiki.ubuntu.com/IrcTeam/IrcCouncil/MeetingAgenda [10:10] ok [10:10] then let me start [10:10] i realize me being on the council is a bit odd [10:10] been around the community for a couple of years [10:11] spend quite a bit of time on irc [10:11] while I haven't done any ops work [10:11] think I've been involved in lots of different aspects [10:11] and hope that I can be of some help [10:11] particularly in helping the Irc Team communicate better with the rest of the community [10:12] even though Irc so important [10:13] it seems, at least to me, that its hard for the rest of the community [10:13] to know whats is going on with it [10:13] just want to help smooth all that part out :-) [10:13] thats all I got [10:14] anything more on that or shall we move on? [10:15] I got nothing to add. elky Pricey?? [10:15] except, welcome ;) [10:15] jussi01: thanks [10:15] no, i'm distracted in several directions at the moment. dont expect immediate answers. [10:16] ok, lets move on, if Pricey wants say something then he can in a min. [10:16] not sure its a dicussion point [10:17] then IRC contributors team? [10:19] Currently we have the ubuntu-irc team, for 'reccomended operators'. [10:19] (I don't think it is technically needed any more for ubottu bt access) [10:19] The CC asked we start thinking about a process for approving Ubuntu membership. [10:20] define 'contributor' in terms of IRC. and what scope this involves in terms of what channels [10:20] yeah... [10:21] This isn't like the forums, we can't easily see other people's activities unless we were personally in that channel and have logs. [10:22] should it not then be limited to publically logged chans? [10:22] jussi01: i've heard the user with the nick "asiudj" has been great, can you go review logs for him on planet.ubuntu.com and come back to us with a report? [10:22] jussi01, depends. do you want to trawl #ubuntu logs anyway? [10:23] hrm [10:24] ask them to provide some evidence from logs in irclogs.u.c? [10:24] bah, i was reading planet, yeah meant irclogs. [10:25] boredandblogging, the problem with doing that is that you'll guaranteed get the good stuff, and not the bad stuff like them telling someone to stfu or rm.... [10:25] boredandblogging: that could be very selective and overwhelming. I want about 3 months contribution I think, and reviewing 60+ days of logs to see what he's done in this other random channel? [10:27] elky: is that the problem with any evidence that a candidate would submit? [10:27] boredandblogging, forums are far more searchable than mbs of irc logs. [10:27] true [10:28] the original memberhsip teams didn't mind that what the candidate produced would be selective, regional ones still don't [10:28] so i htink we can ignore that [10:29] but they base a lot of "is this person a good contributor to ubuntu's irc community" on cheers from the ircc for example [10:29] and we wouldn't have cheered for that unless we had 1st hand experience with the person over a long time.... an operator [10:31] yeah. i'm not sure there's a list of checkboxes you can draw up for that either [10:31] it'd be a list of 1. and 100% interpretive [10:31] we have just cheered if we felt they deserved it [10:32] exactly [10:32] jussi01, Pici, boredandblogging any input? [10:33] Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | Check out the scheduled meetings at http://fridge.ubuntu.com/calendar [10:33] bah === Pricey changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | Check out the scheduled meetings at http://fridge.ubuntu.com/calendar [10:34] not sure how to do it without some logs [10:34] operators that operate in the main ubuntu channels are going to be the easiest people to talk abot [10:34] *about [10:35] would people to able to nominate themselves? [10:36] well we haven't got any kind of process written down yet, but i assume so as everyone else does it that way [10:36] i kind of hope not. we'd have every second banned person applying. [10:36] and that's not going to make it fun, i see what you're getting at [10:36] especially the ones who actually tell us they're going to get us sacked and take down the channels [10:36] those are the most fun of all. [10:39] * elky prods the screen. [10:39] like RMBs, why not ask for testimonials from operators when users nominate themselves? [10:39] See if I had my way, we would probably only really be dealing with main ubuntu operators, maybe a very small number of people who would probably have turned down +o etc. That's probably not good enough. [10:41] What kinds of people do we envisage coming to us for membership? [10:41] boredandblogging, the problem with this is a textbook Catch-22. Anyone who wants to be an op is clearly insane and should not be. Anyone who doesn't want to be is clearly sane and shoud. [10:42] the ones of us who are -- are the gulliable few from the second category [10:44] are we setting the bar too high? this team is to recognize their good work [10:44] not giving them the keys to anything [10:45] Is there a demand for this process? Can you think of more then 5 people you would suggest come to membership for this? [10:45] Pricey, well, if you want my honest, battleworn and slightly cynical opinion: the people who are least qualified to. the genuine ones are not actually going to ask. [10:48] Pricey, currently no. I dont even know who the active helpers are at this present time. === thekorn__ is now known as thekorn [10:50] we're running out of time too [10:50] Sorry guys, had a very important phone call [10:50] boredandblogging, Pricey, Pici, jussi01 [10:50] i think we need to think about this point some more. can we move on to the last so we can hand over to the patient motus? [10:51] 1 sec [10:51] I honestly can see some demand for mebership through IRC contribution, BUT! it seems to me, people hwo actually contribute on IRC also contribute other places, so should be handled buy the regional board [10:52] Unless they are someone from #ubuntu-ops? In which case, they might just contribute there? [10:53] in which case we've probably already assimilated them. all ops should be members first, imho. [10:53] but, this needs to be thought about some more, and we're out of time. [10:53] yes, but still why should we deal with it? they go to the regional board, with us in tow, and the regional bord makes the decision - we just cheer/give evidence [10:54] boredandblogging, you have another item waiting. were you invisaging that taking any more than 5 minutes? [10:55] no, its just grunt work stuff... [10:55] thinking we should post logs, summaries, do the team reports, etc, et [10:55] that sounds like volunteering then. [10:55] I see no real reason to make 'yet anothe member approval place' [10:55] i can kick off the reporting [10:55] unless someone else wants to do it [10:56] boredandblogging, we already post logs... or more to the point canonical does on our behalf. [10:56] secondly, summaries of what? [10:56] 'hi, we banned joe, billy and mary bob today. [10:56] any decisions, highlights of these meetings [10:57] bullet pointsont he wiki? [10:57] Pricey: yeah [10:57] i think the rest of ubuntu would like these reports summarised in the monthly team reports too [10:57] yes, the monthly team reports [10:57] Pricey, saying what exactly though? [10:58] there's absolutely no way i could summarise a month of my op stuff [10:58] no, just summarizing the council meeting [11:00] is that it for today? [11:00] uh ok then. i dont actually see anything reportworthy from this meeting though. [11:00] bullet points are OK :) [11:01] thats it for me [11:01] hi dholbach [11:01] hiya jussi01 [11:01] someone want to set up the next meeting? [11:02] boredandblogging, want is probably the wrong word to use. [11:02] hah, we can do it later [11:02] good. because now that this is over, i can have friday drinks. [11:02] elky: have fun [11:02] same day, same time next month? :P [11:03] Ok, then, meeting over. MOYU's all yours :) [11:03] gracias! [11:03] MOTU's ;) [11:03] jussi01, dunno at this point. friday evenings are not the stable type for organising things. [11:03] thanks everyone [11:03] Laney, geser, soren, persia(?)? :) [11:04] howdy [11:05] I hope everybody else is busy sponsoring and reviewing [11:05] * dholbach is not going to accept any other excuses :) [11:05] Morning. [11:05] * persia really isn't here, despite what the client may claim. [11:05] persia: ok [11:06] soren, geser: around? well prepared? :) [11:06] Yes. [11:07] yes, I'm ready for a second try :) [11:07] #startmeeting [11:07] Meeting started at 05:07. The chair is dholbach. [11:07] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [11:07] [TOPIC] https://wiki.ubuntu.com/IainLane/MOTUApplication [11:07] New Topic: https://wiki.ubuntu.com/IainLane/MOTUApplication [11:07] hiya Laney :) [11:07] hello [11:07] apologies for the false start [11:08] no worries, I think we as the MC want to show that we're flexible after ... some public display of procrastination with other applications :) [11:08] heh [11:08] Laney: so you're interested in getting stuff upstream earlier and in a more streamlined way - do you have any ideas on how we could do that? is there anything missing today? [11:08] Well [11:09] I don't think there's really anything wrong with our processes [11:09] just that they don't really emphasise the importance of getting stuff back to our upstreams as much as they should (IMO) [11:09] is it a matter of education and documentation, you think? [11:09] pretty much [11:10] Asking for bug links before sposoring patches, for example [11:10] volunteering for a UDW session next time? :) [11:10] I'd be happy to do that! [11:10] excellent :) [11:10] do you make use of the submittodebian tool? [11:10] yeah, that's how I submit bugs back [11:10] nice [11:11] it seems to work well [11:11] except I wish it would know how to ignore maintainer field changes [11:11] sounds like a feature request :) [11:11] you mention agda in your application, what is it? [11:11] yeah, I started working on it [11:11] ah yes [11:11] great [11:11] this is a dependently typed programming language which I'm using in my PhD [11:12] (DTP is a language where types can depend on values - a simple example is you can have a type of vectors of a certain length) [11:12] ah I see [11:12] having better types in your programs gives more assurances that what you're writing is correct [11:12] Have you found somebody else with an interest in it already to start getting it in Debian/Ubuntu? [11:13] I talked to sistpoty a while ago and he said he'd be happy to look at it too [11:13] ok [11:13] In your application you say: "I also support the mighty Nottingham Forest, currently battling their way to safety in the Championship after a shaky couple of months in the relegation zone." - what does that mean exactly? :) [11:13] but I discovered that we're missing some dependencies [11:13] hah! [11:14] This is the football team in my city [11:14] http://en.wikipedia.org/wiki/Nottingham_Forest [11:14] LINK received: http://en.wikipedia.org/wiki/Nottingham_Forest [11:14] ahhh, it was a bit misleading - I was expecting some tree hugging activity going on there ;-) [11:14] sadly nothing so noble [11:15] geser, soren: do you have questions too? [11:15] yes :) [11:15] * Laney hides [11:16] geser: You go first. [11:17] Laney: I read that your are interested in haskell packages and also done a ghc transition already. I've helped with haskell transitions in the past and it was a hell to get the build order right. What's your impression from the haskell transition? [11:17] geser: Yes. Basically I just built all of the packages and then drew a graph of which ones had unsatisfiable build-deps [11:17] debian-haskell are talking about how to get past this [11:18] I think a current idea is to use provides in a clever way [11:18] so the haskell packages are in a usable state currently in jaunty again? [11:19] Until the next GHC upload breaks everything, yes [11:19] but we probably won't get another one this cycle [11:19] and things should be better for 6.10 [11:19] so maybe we only have to do this pain once more... [11:19] Does every ghc upload break things? [11:20] They don't guarantee ABI stability [11:20] so potentially [11:20] I mean... Even one without any changes in it? Is it that strict? [11:20] Or just ones that actually change internal data structures? [11:20] the problem this time was slightly different though [11:20] Or whatever. [11:20] the maintainer +dfsged the upstream version [11:20] and therefore a lot of the dependent packages had to be rebuilt [11:21] Laney: and a last question: what's your impression/expierence with working with Debian in general? [11:21] but in general, every upstream release (not each Debian one) will break ABI [11:21] geser: Mixed to be honest [11:21] why? [11:22] I love working with packaging teams in Debian, because you get a lot of people with specialist knowledge all working together on a focused set of packages [11:22] but I've found some maintianers unwilling to work with me on things [11:22] some people prefer to do everything themselves [11:23] soren: your turn [11:23] and separately, I always feel guilty asking individuals for sponsorship [11:23] so the Ubuntu sponsoring models is better? [11:23] I'm good, actually. My question was already answered. [11:24] geser: I prefer it because sponsors can take from it when they choose [11:24] instead of being pinged [11:25] geser, soren: all set? [11:25] Yes! [11:25] a lot of Debian teams have more DDs than contributors, so there's a lot of blocking on a single personw [11:25] yes, you can take over now again [11:25] which doesn't feel fair to me [11:25] [VOTE] Should Iain Lane become a MOTU? [11:25] Please vote on: Should Iain Lane become a MOTU?. [11:25] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [11:25] E.g. /msg MootBot +1 #ubuntu-meeting [11:25] +1! [11:25] +1 [11:25] +1 [11:25] +1 received from dholbach. 1 for, 0 against. 0 have abstained. Count is now 1 [11:25] +1 received from geser. 2 for, 0 against. 0 have abstained. Count is now 2 [11:25] +1 [11:25] +1 received from soren. 3 for, 0 against. 0 have abstained. Count is now 3 [11:25] #endvote [11:26] err [11:26] ... whatever [11:26] [AGREED] Iain Lane to become MOTU [11:26] AGREED received: Iain Lane to become MOTU [11:26] it's [ENDVOTE] [11:26] ;) [11:26] [ENDVOTE] [11:26] Final result is 3 for, 0 against. 0 abstained. Total: 3 [11:26] thanks Laney :) [11:26] \o/ [11:26] \m/ [11:26] nice one chaps [11:26] [TOPIC] Any other business? [11:26] New Topic: Any other business? [11:26] nothing from me [11:27] Nor me. [11:27] nope [11:27] #endmeeting [11:27] Meeting finished at 05:27. [11:27] thanks a bunch everybody! [11:27] congratulations Laney :) [11:27] thanks a bunch [11:27] * dholbach will do the honours [11:27] Laney: shall I directly add you to ubuntu-universe-sponsors? :) [11:28] yes please [11:28] thanks === Rafik_ is now known as Rafik === thunderstruck is now known as gnomefreak [15:01] morning [15:01] hi [15:01] o/ [15:01] * lool waves [15:01] o/ [15:02] Yo [15:02] hello [15:02] hiya [15:03] don't we have the release team meeting now? [15:04] yes [15:04] still doing a head count [15:04] mdz and rickspencer send their regrets [15:04] * rtg is here [15:04] lool: will davidm be joining us also? [15:04] slangasek: No, he gave me his apologies [15:04] ok [15:04] He had a conflicting meeting [15:04] slangasek: rtg will be the kernel rep this week [15:05] Riddell, sbeattie: ping? [15:05] hey [15:05] morning [15:05] hi [15:05] #startmeeting [15:05] Meeting started at 09:05. The chair is slangasek. [15:05] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:05] and we're off :) [15:06] [TOPIC] Outstanding actions [15:06] New Topic: Outstanding actions [15:06] I sent out a list of these after the last meeting; I'll skip the ones that I know are resolved [15:07] (or that are going to be covered later) [15:07] robbiew: is dbarth on the google calendar invite list for this meeting? [15:07] I forgot to include him on the agenda mail :( [15:07] slangasek: yes [15:07] ok [15:07] but unavailable today, I guess [15:08] slangasek: I invited him, didn't see him right now [15:08] pgraner: hmm, looks like we have a carry-over item to discuss milestones in the kernel team [15:08] robbiew: I didn't seem him in the google calendar event [15:08] hmm [15:08] * lool added him now [15:08] thnx...strange [15:08] pgraner: and we didn't get a chance to talk about the "kernel to userspace" communique during the sprint - at the end of the meeting, can we schedule some time to talk about these two items? [15:08] I added him, but perhaps it didn't update for all meetings [15:08] slangasek: we can talk later this afternoon if you want... [15:09] lool: did you chase up bug #299847? [15:09] Launchpad bug 299847 in libipc-sharelite-perl "armel build failure (without ignoring testsuite results)" [High,Triaged] https://launchpad.net/bugs/299847 [15:09] slangasek: I delegated to ogra [15:09] ogra: ^ [15:09] yeah [15:09] slangasek: I'm in calls for two hours right after this meeting.... [15:09] And asked that he sends his findings on the bug [15:09] pgraner: ok - at the end of the meeting, let's figure out a time that works? [15:09] seems the porter boxes and buildds have issues all other armel devices dont show [15:09] slangasek: ack [15:10] ogra: but on the upside at least it reproduces on the porter box, eh? [15:10] i'm just testbuilding on qemu, it builds fine on all my arm devices here [15:10] yes [15:10] lool, ogra: where does that leave us, then? with a critical bug that needs fixed on the buildd/porter boxes, or a standing disabled testsuite for release? [15:10] slangasek: We'll continue investigating to understand severity of the issue, the fact that it only happens on one kernel / hardware seems to imply it might not be critical for the other platforms [15:10] porter shows the same behavior as the buildds [15:10] lool: right; do we have to worry about misbuilds? [15:11] Hard to say what might be using the same interface; I don't this particular package or other perl packages in the stack are in danger though [15:11] * ogra waits for the qemu build to get to the make test stage just this very moment [15:11] I just fear we discover this causes a class of syscalls to misbehave [15:11] Hopefully not creating broken binaries [15:12] ok [15:12] slangasek: So we'll continue debugging, nothing to report here apart slow progress in the research [15:13] qemu is fine too btw [15:13] alright. Given the size of the "makes a class of syscalls misbehave" unknown, we probably need a final assessment of this well before beta - what are the chances we'll know what's going on two weeks from now at the next meeting? [15:13] (i wouldnt have expected differently) [15:14] ogra: Do you think you can finish investigation, perhaps with help from kernel or foundation folks? [15:14] yeah, kernel and IS i think [15:14] i have no clue what they are running on these machines [15:14] The kernel is older than the ubuntu jaunty armel ones, so this might be a cause [15:15] right [15:15] ogra: ping amitk if you need kernel assistance [15:15] (the buildd hardware is not supported by our jaunty kernels) [15:15] ok, moving on [15:15] * slangasek to ask armel/versatile/d-i to be added to ISO tracker [15:15] pgraner, yep, i'll also need someone from IS to assist [15:15] slangasek: Could you also add NSLU2 and N2100 images? [15:15] I thought I did the asking, but I don't find it in my logs and it's not done; so I'll follow up on this today :/ [15:15] lool: we're building all of those images currently? [15:15] slangasek: Also, make sure to reference the netboot images [15:15] slangasek, versatile and nslu2 are netboot only [15:16] slangasek: We do, as inherited from Debian [15:16] not sure about n2100 [15:16] slangasek: NSLU2 is one of the board we have available in the mobile team and we're trying to enable [15:16] ok, so what we need is 'netboot arm' added to the tracker [15:16] * lool, davidm to provide MID test case documentation for the ISO tracker [15:16] lool: was this done? [15:16] slangasek: I delegated to persia [15:16] slangasek, a link to a howto on the wiki and to the dir that holds the netboot image would suffice [15:16] persia: ^ [15:17] I know he was blocking on the move of testcases to testscases.qa.u.c [15:17] hmm, ok [15:17] * persia is currently drafting, and expects to have something on the wiki soon. Integration with testcases.qa.ubuntu.com will take longer due to issues with multiple flavour support for that site. [15:18] persia: Will you be done on Monday, before A5 testing begins? [15:18] Riddell: I see bug #289907 is fixed, kudos [15:18] Should be done in a couple hours. [15:18] Launchpad bug 289907 in qt4-x11 "Event handler drops some events when rate of incoming events is high" [Undecided,Fix released] https://launchpad.net/bugs/289907 [15:18] and that's it for outstanding actions - everything else was taken care of [15:18] Is Alpha 5 next week? https://wiki.ubuntu.com/JauntyReleaseSchedule says the week after. [15:19] alpha 5 on the 26th [15:19] Sorry, it's in two weeks, I'm confused with FF [15:19] would have had the answer more quickly if gnome-panel's calendar wasn't broken for me right now ;) [15:19] ok, team reports [15:19] [TOPIC] QA team [15:19] New Topic: QA team [15:20] The QA team is still looking for new features to test on an upcoming testing day [15:20] Please add them to https://wiki.ubuntu.com/Testing/UbuntuTestingDay/Features [15:20] Daily smoke testing continues apace: https://wiki.ubuntu.com/Testing/DailySmoke [15:20] slangasek: use evolution directly ;-) [15:20] We're ramping up a new person for hardware testing (fader), but he's still figuring out our infrastructure, so we don't have anything to report on that front. [15:20] seb128: I have enough apps left open without adding evo :( [15:20] Also in QA, I'm working on getting the hardware certification tests running on a regular basis across all the hardware I have access to [15:21] But I am currently blocking on access to some systems and on some work by cr3 and schwuk [15:21] Hopefully next week I'll be able to say at least a little something useful :) [15:21] :) [15:21] that's all for us for this week. [15:21] ok, cheers [15:22] skipping over Desktop for the moment, at pitti's request [15:22] I'm ready [15:22] oh [15:22] but as you wish [15:22] [TOPIC] Desktop team [15:22] New Topic: Desktop team [15:22] https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [15:22] well then :) [15:22] is our detailled report [15:22] summary, we are still struggling with a couple of Xish bugs, but by and large the largest blocker is getting the Dx work into jaunty [15:23] do you have code drops scheduled for that? [15:23] we are asking daily, but we won't get them until next Monday or Tuesday [15:23] so far we only have a few internal testers [15:24] * slangasek nods [15:24] is there a need for a wider call for testing? [15:24] we'll send one out as soon as it lands [15:24] or should the focus be on getting the code landed in jaunty? [15:24] ack [15:24] oh, internal testin? [15:24] I meant public [15:25] it should land in jaunty proper ASAP [15:25] pitti: the status for bug #320632 says "debugging going on" - who's driving this? based on conversations had with the kernel team during the sprint, I wonder if the remaining issue isn't a kernel regression [15:25] Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632 [15:25] however, on the bright side, all the necessary bugs are filed now [15:26] a plus :) [15:26] bugs> for the packages we need to fix for notifications [15:26] 320632> I'll talk to bryce [15:26] also, is there any other potentially-disruptive spec work we should expect to see landing between now and alpha-5? [15:27] the language selector shoudl get a better UI [15:27] rtg: do you have any insight into bug #320632? Could the issue with side-scroll not working be related to that kernel regression, and is that synaptics reset issue now fixed in the kernel? [15:27] but it doesn't change functionality, so it's only intrusive in terms of UIF [15:27] Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632 [15:27] slangasek: I have no idea [15:28] who would know? apw? [15:28] WRT bugs for notificatios related changes. I've seen bugs filed on Universe packages for this. [15:28] I don't think MOTU is in a position to maintain a bunch of diff for this and the changes should just be in Main. [15:29] * ScottK had thought that was the plan. [15:29] [ACTION] slangasek to follow up with kernel team (apw) on the question of bug #320632 being a kernel bug [15:29] ACTION received: slangasek to follow up with kernel team (apw) on the question of bug #320632 being a kernel bug [15:29] ScottK: still good for having them, to attach upstream bug refs and patches to them [15:29] Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632 [15:29] pitti: I think the Ubuntu tasks should be wontfix though. [15:30] ScottK: for all of them? I don't see why interested people shouldn't do/take them if they want [15:30] that sounds like a discussion we should take to #ubuntu-devel after? [15:30] OK [15:30] pitti: anything else from your team? [15:30] not right now [15:30] hopefully we'll have some better news next week [15:30] [ACTION] ScottK, pitti, slangasek to follow up on question of DX patches for universe [15:30] ACTION received: ScottK, pitti, slangasek to follow up on question of DX patches for universe [15:31] slangasek: the only synaptics patch that I'm aware of is the reset issue (which allows synaptics touchpads to be correctly identified) [15:31] pitti: "we're not breaking the release" is pretty good news as it stands, thanks ;) [15:32] rtg: right - I think the upshot of that bug is that the synaptics X driver now thinks all touchpads support scroll methods that they don't [15:32] rtg: anyway, I've taken an action to discuss this further after the meeting [15:32] slangasek: hmm, I'll sic Andy on it since he did the bug work. [15:32] [TOPIC] Mobile team [15:32] New Topic: Mobile team [15:32] Our jaunty roadmap is more or less tracked at . [15:32] Since last meeting we dropped/postponed endangered specs and we discussed blockers at the sprint, either with foundations or kernel people; in particular toolchain changes (to enable FPU notably) are out of the picture for jaunty (303232). However we expect to work on random libs to add VFP (FPU-enabled) flavours to t [15:33] hem ASAP; the list is discussed in 303232. [15:33] We assigned actions on other teams such as kernel actions to identified individuals where applicable (e.g. armel config fixes, or missing syscalls on armel). [15:33] We'd like to link to netboot images as part of the alpha 5 release announcement even if these aren't self-contained; we will be testing them against the archive around alpha time. [15:33] We're looking at some potential last minute work on the kernel to add a new flavour, but it remains uncertain that this will land in time for FF. [15:33] Finally, we will try to integrate the Poulsbo driver in jaunty as we receive it; first and biggest code drop is expected in the next 10 days. [15:33] [LINK] https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [15:33] LINK received: https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [15:33] [LINK] https://wiki.ubuntu.com/MobileTeam/Roadmap [15:33] LINK received: https://wiki.ubuntu.com/MobileTeam/Roadmap [15:33] (That's about all the release worthy stuff which I've got) [15:34] Basically the vfp lib stuff is in flux right now, and the biggest other items are out of our control [15:35] lool: does the state of bug #303232 need to be updated to reflect your comments? If we're not making toolchain changes, gcc-4.3 seems like the wrong package for the bug to be against? [15:35] Launchpad bug 303232 in gcc-4.3 "armel gcc default optimisations" [High,Confirmed] https://launchpad.net/bugs/303232 [15:35] slangasek: Yes; I'll update the bug when I have a list of bugs for library changes as I don't want to let the submitter think we're dropping the ball on the topic [15:35] ok [15:35] (Got an early list of libs earlier today only) [15:36] you'll open tasks on each of the libs that are going to be changed? (You said 'list of bugs') [15:36] No, I think I'll open new bugs, one for each lib, due to prior bad experience with a bug with a long list of tasks [15:36] Perhaps I'll link them to this bug, or another meta bug [15:37] lool: bug #319729 wasn't on your report webpage, but was in the agenda - anything to say about the status there? Is the course of action clear for resolving it? [15:37] Launchpad bug 319729 in linux "ARM architecture lacks support for pselect() and ppoll()" [High,Triaged] https://launchpad.net/bugs/319729 [15:37] I'm happy to follow the best recommended practice here; I just have had poor experience with things like transition bugs or libv4l enablement and the like [15:37] [ACTION] slangasek, cjwatson, lool to discuss inclusion of ARM netboot images in the alpha-5 release announcement [15:37] ACTION received: slangasek, cjwatson, lool to discuss inclusion of ARM netboot images in the alpha-5 release announcement [15:38] slangasek: Thanks for pointing it out, I will ad it to our "roadmap"; it's in the hands of the kernel team to bring this problem up to upstream now [15:39] ok; I see amitk is assigned to it [15:39] when we expect him to have an answer back from upstream? [15:39] (added to our "roadmap") [15:39] s/when we/when do we/ [15:39] slangasek: I don't know; I asked for this during the sprint and reminded by email recently [15:39] 2 days ago [15:40] I tried subscribing to the upstream list since a month myself, but my subscription is pending moderation [15:40] frankly, I doubt if he's had time to pursue it. [15:40] (tried via email and via web) [15:40] pgraner: Could you make sure amitk has enough time for this, or assign somebody else? [15:40] lool: put another way: what's an appropriate deadline by which this needs to be done, in order to keep ARM on track? [15:40] they probably only accept snailmail subscriptions :) [15:41] slangasek: That's a good question, neither do we know how much ubuntu breaks without this support; I'm told udev will deadlock randomly due to races [15:41] slangasek, to be honest nobody has seen the bug that can introduce yet [15:41] lool: we are going to have to let a contract to get that done, I'm in process now of working thru it. However I've been on travel for weeks [15:41] slangasek: So anytime our release team is happy for us to add the syscalls to the kernel, and before release I guess? [15:41] hmm, right [15:41] pgraner: Sure, thanks [15:42] lool: so it's clear that the solution will be to get the syscalls added? [15:42] as long as that much is clear, we have some time to get the implementation sorted [15:43] slangasek: I was told by NCommander that this didn't seem to be overly complex -- but he underlined that he isn't enough into kernel stuff to judge -- so that would be the preferred solution, yes [15:43] I don't know whether any other exist; AFAIK, newer udev just relies on that unconditionally [15:43] ok [15:43] slangasek, lool: do we have a bug that *demonstrates* this behavior [15:44] we would need to ask Keybuk to provide a testcase [15:44] pgraner: No; I think Keybuk might have more information as he pointed out this syscalls as required for future upstart [15:44] he brought it up [15:44] ISTR he mentionned upstart / init hanging without them [15:44] *these [15:44] and udev [15:44] it's a race, so a deterministic reproducer will be tough ... [15:44] lool: If we do this it will be expensive and I find it hard to believe if its that big of an issue it has not been fixed upstream yet [15:44] I don't think he saw udev hanging [15:44] pselect() ? it's part of POSIX! [15:44] Keybuk, glibc provides an emulation of it if the kernel doesn't [15:44] it's not been done upstream because Russell King simply doesn't implement anything he doesn't need [15:45] NCommander: the emulation doesn't fix the race [15:45] * NCommander is now backish for five minutes. [15:45] pgraner: New udev only came out recently; perhaps it's fixed in 2.6.29 and we don't have it? I don't know [15:45] NCommander: the emulation suffers the exact race condition the syscall was designed to avoid [15:45] Keybuk: Is the definitely needed for Jaunty? If not we can work it for 9.10 [15:45] Keybuk, no, I know, I'm just saying why glibc has it even though our kernel doesn't :-) [15:45] pgraner: if the syscall is not implemented in the kernel, you will have random hangs in any program that uses pselect() or ppoll() [15:45] Keybuk: We plan to ship products based on jaunty/arm and tell people to install it; is it a serious issue which will prevent the use of jaunty? [15:45] lool: I believe it is a critical issue [15:46] THanks [15:46] Keybuk: can you quantify the probability of such hangs? [15:46] slangasek: no, it's a race condition [15:46] I can describe it [15:46] you have a main loop [15:47] a small test program that loops a zillion times around pselect would probably be vaguely helpful [15:47] your main loop, like just about every other, is a loop around a select() or poll() call that sleeps until there is activity [15:47] you want that woken up by a particular signal [15:47] but you don't want those signals otherwise being delivered to your process [15:47] Keybuk: maybe this would be better left for after the meeting then, we've already overrun the mobile team's slot [15:47] so you set a signal mask to include that signal [15:47] and before you select() [15:47] restore the original signal mask [15:47] select() with the original signal mask (so the signal can be caught) [15:47] then restore the previous signal mask again after [15:48] Keybuk: #ubuntu-devel or elsewhere, please [15:48] the race is that the signal can be delivered between the calls to sigprocmask() and select() [15:48] slangasek: Any other question on the list of things I dumped? [15:48] if that happens, you will stay in sleep even though the signal has been delivered [15:48] lool: nope, thank you [15:48] [TOPIC] Kernel team [15:48] New Topic: Kernel team [15:49] need wireless-crda promoted to main (which pitti has promised to do) [15:49] rtg: bug #308387 is a one-liner control file change that's been lingering for a bit; who can take care of getting this fix into the next kernel upload? [15:49] Launchpad bug 308387 in linux "[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev" [Undecided,Fix committed] https://launchpad.net/bugs/308387 [15:49] slangasek: I think its done [15:50] "Added libdrm-dev as a 'Replaces' to linux-libc-dev" in 2.6.28-8.21 changelog. [15:51] rtg: ah, you closed it an hour ago, ok :) [15:51] wireless-crda> I don't have a bug number on my watch list for that, is there an open bug that should be escalatd? [15:51] slangasek: yeah, I've been slogging through several [15:51] there is an MIR [15:52] bug #325801 [15:52] yes [15:52] what does not having wireless-crda block us on? [15:52] Launchpad bug 325801 in ubuntu "Main inclusion request: wireless-crda" [Undecided,In progress] https://launchpad.net/bugs/325801 [15:52] slangasek: wireless-crda was just added to Ubuntu a couple of days ago [15:52] saw it a couple of hours ago, will get to that asap [15:52] The kernel won't install because wirel;ess-crda is a dependency [15:52] MIR has been set in progress some hours ago [15:53] By Kees IIRC [15:53] lool: but not approved, right? [15:53] (yet) [15:53] in progress is approved AFAIK; albeit I had some comments against it [15:53] targeted to jaunty now [15:53] Status: New => In Progress [15:54] rtg: er. why is it a depends instead of a recommends, which is what was suggested in the bug log? [15:54] because its a requirement for CRDA. why wouldn't it be a depends? [15:54] definitely an alpha-5 issue if the kernel can't be installed, though ;) [15:54] depends sounds too strong, there are certainly pleny of systems without any wifi at all? [15:54] when I was asked about this, I said Recomments [15:55] Recommends [15:55] for pitti's reason [15:55] Yes, I wasn't personally sure whether this should be pulled by some higher level meta package or the kernel itself; I don't mind where but I want it to be optional in some use cases as well [15:55] I'll defer to you guys. I just think it really needs to be installed. [15:55] rtg: recommends just means that people can uninstall it, it'd still be installed by default [15:55] rtg: recommends -> installed by default, but users who don't have wifi can uninstall it for a slimmer system [15:55] we have no kernels that do not also have wireless. [15:55] There was the question of upgrades; hopefully people don't turn off recommends [15:56] lool: users who do that are shooting themselves in the foot generally [15:56] slangasek: CRDA is really small. [15:56] I actually wondered why this isn't simply part of udev [15:57] 'cause its not part of the udev upstream [15:57] "why this isn't simply part of udev upstream" [15:57] right; anyway, Recommends vs. Depends doesn't need to be hashed out here and now [15:57] disparate developers I guess [15:57] maybe that's something that needs to be talked about [15:58] rtg: do you know if there's progress on bug #261318? [15:58] Launchpad bug 261318 in linux "Regression: new Toshiba Laptop Support (tlsup) driver breaks Toshiba hotkeys; input device does not support 'kbd' input handler" [High,Fix released] https://launchpad.net/bugs/261318 [15:58] ... right, 'fix released', guess so [15:58] (bah, developer race conditions) [15:58] I was looking at that. I thought we revereted to tochiba_acpi (which should fix the probnlem) [15:59] toshiba_acpi, even [15:59] sounds right [16:00] the last bug I had on the list is #88746 [16:00] IIRC I targeted this to jaunty because someone had already accepted a nomination for hardy [16:00] bug 88746 [16:00] but I don't know that anyone is working on it currently? [16:00] Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/88746/+text) [16:00] (or if it's even actionable, honestly) [16:01] oh, that one. there are 472 comments. [16:01] yes [16:01] I've never been able to get a handle on it. [16:01] what would help us get a handle on it? [16:02] do we need to get users to give us PCI IDs for their USB controllers, and get them to confirm that the devices work at USB2.0 speeds under !Linux? [16:02] danged if I know. get a platform that exhibits the problem? [16:02] looks like upstream has declined the bug report as invlaid [16:03] uh, nevermind. I misread that [16:04] is there someone on the kernel team who could take care of distilling this bug? or should we ask the QA team for help? [16:04] lets put it this way, I have no plans to address this bug before release. [16:05] well, it's also been marked as an SRU candidate for hardy; so if we're not going to handle the bug we should follow through on documenting this in the bug state === Nicke_ is now known as Nicke [16:06] sure [16:06] [ACTION] slangasek to follow up on bug #88746 [16:06] ACTION received: slangasek to follow up on bug #88746 [16:06] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/88746/+text) [16:07] rtg: anything else we should discuss before moving on? [16:07] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/88746/+text) [16:07] CRDA was the big item for me. [16:07] ok [16:07] [TOPIC] Foundations team [16:07] New Topic: Foundations team [16:07] cjwatson: [16:07] robbiew: you too, though I guess I saw cjwatson preparing the report :) [16:08] I'll defer to cjwatson, as I would just be a "parrot" for cjwatson's report.. [16:08] hah [16:09] ok, bugs first [16:09] 325690: (udev breaks cryptsetup initramfs hook) - fix committed [16:09] 323602: (kernel upgrade fails when casper is installed(?)) - this is probably bug 292159, which I've discussed with Evan and we'll get fixed after FF [16:09] Launchpad bug 292159 in linux "MASTER update-initramfs is disabled since running on a live CD but it is running from a flash drive. " [Undecided,New] https://launchpad.net/bugs/292159 [16:09] 322482: (update-manager fails over remote GDM) - almost certainly not really an update-manager problem, as Steve points out, but it's true that there are lots of things that can go wrong in this scenario and a warning does seem called for; we'll get this fixed after FF, just need to figure out the best detection method [16:09] 313218: (IPv6 causes slow Internet access) - still on my plate for as soon as I get feature work out of the way; there's been good progress upstream for at least a workaround [16:09] 303515: (passwd gives wrong return code on failure) - this one's Steve's, likely to make progress upstream within the next few weeks [16:09] 311228: (extra translations not installed for the default language) - fix committed [16:09] 44194: (wpasupplicant interfaces don't start right with separate /usr partition) - I meant to discuss this at the sprint but didn't have time. One possible fix would be for all necessary binaries and libraries to be outside /usr, and to use somewhere like /var/run in case the root filesystem is not writable yet. [16:09] 309215: (python-numpy vs. pygtk package split) - still an open question [16:09] 325257: (migration-assistant incompatible with encrypted home directories) - per security team comments on lack of encrypted swap, we're going to have to disable encrypted home on the desktop CD, so this is moot for jaunty but we'll look at it anyway [16:10] regarding feature freeze, major things yet to land are a couple more installer changes (including manual package selection for server installs and some more timezone map changes in ubiquity), python2.6, update-manager/computer-janitor merge, hwclock and console changes for boot performance [16:10] (ack on 44194, that was my thought as well) [16:10] I NEWed python2.6 source earlier and should be able to NEW the binaries before leaving for the day [16:11] (I'll be offline all weekend) [16:11] robbiew: any other relevant feature bits I'm missing? [16:11] no...not that I'm aware of [16:12] hmm, python2.6 failing on lpia not a good sign [16:13] anyway, yeah - my general feeling from our last foundations meeting was that it's a bit of a sprint to the finish, but that most people are fairly well on track [16:13] sounds good, thanks [16:13] [TOPIC] Server team [16:13] New Topic: Server team [16:13] dendrobates: hi-yo [16:14] slangasek: nothing big from us. [16:15] dendrobates: I gave you two bugs in the agenda so you didn't feel left out :) is jdstrand owning bug #305264? we discussed at the sprint that the openldap behavior should be changed so it's consistent when built with gnutls vs. openssl [16:15] Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [Undecided,Invalid] https://launchpad.net/bugs/305264 [16:15] I'll toss in that clamav 0.95 is expected in ~ 1 month another set of "let's break all the libclamav rdepends" changes. They promise though that this is the one true last redesign. [16:16] or if not jdstrand, is there someone else on your team who can drive it? (mathiaz?) I'm happy to make sure the Debian openldap packages follow suit, but I don't have time right now to figure out what needs patching [16:16] dendrobates is on a call, so he may need to follow up via email [16:16] ScottK: heh [16:16] robbiew: ah, thanks [16:17] ScottK: and 0.95 is intended for jaunty? [16:17] has his head in the clouds ;) [16:17] slangasek: mathiaz should handle anything ldap related. [16:17] [ACTION] slangasek to follow up with mathiaz on bug #305264 [16:17] ACTION received: slangasek to follow up with mathiaz on bug #305264 [16:17] Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [Undecided,Invalid] https://launchpad.net/bugs/305264 [16:17] slangasek: I'd say so if we can unbreak the rdepends in a reasonable time. [16:17] I've talked with Debian and upstream about a svn snapshot in experimental soonish so we can start working. [16:18] ok, great [16:18] dendrobates: thanks [16:18] [TOPIC] MOTU [16:18] New Topic: MOTU [16:18] ScottK: still you, then :) [16:18] Yeah. [16:18] We got a volunteer for our 5th person, so it seems we'll be fully manned. [16:19] excellent [16:19] My biggest concern right now is Lenny releasing 5 days before feature freeze, what will get uploaded and what that does to the sponsorhip quueu [16:19] for some better spelling of queue [16:19] hmm [16:19] you can always say no to merges :) [16:20] We also have a charter we're working with other MOTUs to clarify what it is we are supposed to be doing. [16:20] It's sort of grown organically up to now. [16:20] right; based on my experience with Debian post-release uploads, saying no might be a good idea anyway :) [16:20] heh. [16:20] perhaps a mail to -motu@ would not go amiss? [16:20] That's it for MOTU I think. [16:20] james_w: For the post-release question? [16:20] I think Mark Hymers' mail to d-d-a is apposite [16:21] We'll deal with it one way or another. [16:21] "We'll drop an email to d-d-a again once this happens and then go and hide somewhere while everyone uploads a new version of every package to sid simultaneously :-)" [16:21] * slangasek grins [16:21] ScottK: to explain that there will be an explosion of things in MoM, and we probably don't want them all [16:21] Ah. [16:21] Makes sense. [16:22] james_w: I have to drop offline shortly after this meeting, would you draft something? [16:22] * lool suggests we sponsor beer to Debian to make sure everybody is drunk for long after the release [16:22] * ScottK suspects lool is wearing his Debian hat when he suggests that. [16:22] ScottK: I'll draft it and let you take a look [16:22] [ACTION] james_w to draft an email to -motu about handling of post-lenny-release MoM explosion [16:22] ACTION received: james_w to draft an email to -motu about handling of post-lenny-release MoM explosion [16:22] ScottK: argh! [16:22] That's it for MOTU. [16:23] lool: I'm not sure why you think that would reduce upload frequency, as opposed to upload quality ;) [16:23] ScottK: thanks :) [16:23] haha [16:23] [TOPIC] General feature update [16:23] New Topic: General feature update [16:23] james_w: You can mail me, as I'll be getting mail. [16:23] (AKA: AOB?) [16:24] thanks slangasek [16:24] It looks like we now have functional kernels/libdrm on all the ports archs. [16:24] goodgood [16:24] I think all the other features I'm aware of being in the pipe have been covered, so... [16:25] I've been working on getting the rebuild sequence right for KDE. [16:25] On hppa I will be blocked by Bug #311952 [16:25] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/311952/+text) [16:25] I'd appreciate it if someone could talk to the LP people about that one. [16:26] (since the bot isn't helping, it's a PAS problem that makes it so kdebidings gets skipped on hppa) [16:26] ah, hmm [16:26] cjwatson: I think we also need to talk through management of P-a-s for Ubuntu now that Debian has moved to git [16:27] pkern sent a mail to u-devel, I don't think there was any followup there [16:27] For intrepid, we have KDE 4.1.4 in -proposed and it is just lacking verificaton of https://bugs.launchpad.net/ubuntu/+source/kdeutils/+bug/318866 [16:27] Ubuntu bug 318866 in kdeutils "printer-applet does not display when new printers get configured" [Undecided,Fix committed] [16:27] Unfortunately haven't found someone with a USB printer to test it. [16:27] I was wondering if sru-verification could take that one on so we can get the set pushed to -updates. [16:28] slangasek: yes, we'll need to grab infinity for that [16:28] slangasek: assuming that we can't just continue to pull it [16:28] * ScottK sits down. [16:29] sbeattie: can you help with that KDE SRU verification ScottK mentions above? [16:29] ScottK|slangasek: yeah, I can take a poke at that one. [16:29] thanks [16:29] sbeattie: Thanks. [16:30] pitti: Once that one is verified, I think we can push 4.1.4 (all package bugs tagged kde4.1.4.) [16:30] \o/ [16:30] and I'll summarily truncate "Hardware testing, ISO size" since I think everything's been said which needs to at this point [16:31] slangasek: IIRC we wanted to SRU the gnutls bug. I can take it [16:31] dendrobates: ^ [16:31] so I think were done here - thanks, all [16:31] #endmeeting [16:31] Meeting finished at 10:31. [16:31] thanks all === dholbach_ is now known as dholbach === asac_ is now known as asac === smarter_ is now known as smarter === MikeB is now known as Technoviking