=== _neversfelde is now known as neversfelde [09:06] * persia is a bit late [09:08] amachu ? elkbuntu ? TheMuso ? lifeless ? zakame ? Belutz ? [09:11] * persia confirms it's 9:11 UTC on 20th January, against https://wiki.ubuntu.com/Membership/RegionalBoards/AsiaOceania [09:21] Well, in the absence of anyone else, I'm cancelling the meeting. Apologies to those seeking membership this week. [09:22] thx persia [09:56] persia: Hi [09:57] Hi. I think it's 10:00 UTC now. Only MaWaLe admitted to coming to the meeting, so I cancelled it. [09:58] yes. I got that. Ok. I need to send invitation prior and remind people [09:58] Well, so do we need to have the next meeting at 15.00 UTC [09:58] or will it clash [09:59] It would clash. [10:00] fine, then Lets have it at 11.00 UTC, the time we used to meet regularly [10:00] what do you say? [10:08] Well, isn't that bad over there? [10:19] persia: means? [10:19] India [10:20] Yeah. [10:20] Next Tuesday 11:00 is bad for me for other reasons, but my personal schedule shouldn't be the deciding factor. [10:32] persia: Ok. I will mail the group [10:32] That sounds like a better plan. [10:59] hi elmo [11:00] I pinged sabdfl and mako also, although I'm not sure that mako is up already [11:02] https://wiki.ubuntu.com/CommunityCouncilAgenda is empty afaics [11:02] is here anybody with other business for the CC meeting? [11:12] hello all [11:12] ah hi sabdfl! :) [11:12] sorry for the delay [11:12] https://wiki.ubuntu.com/CommunityCouncilAgenda is empty and I got no AOB from the people in here [11:13] nothing from me [11:13] elmo: anything from you? [11:13] do folks want an update on archivereorg? [11:13] that would be interesting [11:13] i think it is quite a big step from a community structure / management / leadership / organisation perspective [11:14] yes? no? [11:15] I agree [11:15] ok, i'll do a quick summary [11:15] the goal is to help scale our developer communit(ies), while at the same time removing unnecessary fragmentation [11:16] we hope to achieve the scaling by allowing groups of developers with specific interests to collaborate around sets of packages in ubuntu [11:16] for example, xfce folks around the set of packages that represent xfce in ubuntu, or documentation folks around the content packages [11:17] access to those groups should be easier for new developers, because they will need to demonstrate a rigorous understanding of a subset of ubuntu, rather than the whole [11:17] also, they will be evaluated and approved by the leaders of those specific communities [11:17] with some provisions for maintaining a high standard across the board [11:18] so, hopefully we have a better match of interests and permissions for more new developers [11:18] all developers that have upload to ubuntu will be considered ubuntu developers, and get a vote in the developer community [11:18] for example, in the TB elections [11:19] separately, we will unify the "generalist developer teams", currently split into -core and -motu [11:19] do you anticipate that we will have an explosion of councils, or that the existing MOTU Council will evaluate applications taking input from those leaders? [11:19] so, there will only be one team of generalist developers [11:19] some of current motu folks will start out in a focused team, others will start out in the new unified generalist team [11:19] we agreed to be conservative in unleashing the new force of potential fragmentation :-) [11:20] so, we will probably have 5-10 focus areas initially [11:20] gnome, kde, xfce, documentation, mozilla/xul, toolchain, java, etc [11:20] there hasn't been a decision-making conversation about that initial set [11:20] finally, there will be some portions of the archive where you will need specialised knowledge to have immediate write access [11:21] there's no final spec as to which areas they are [11:21] but they will not be concentric (i.e. we won't have a simplistic "more trusted, less trusted" approach) [11:21] kernel team gets kernel, and so on [11:22] we will try to facilitate participation in those areas by others, too [11:22] so any ubuntu developer will be able to upload to the kernel [11:22] but the upload will need to be reviewed [11:22] and there is a commitment to make sure those reviews happen timeously [11:22] that's about it [11:22] is that review something that could be extended across the board? [11:23] otherwise we need a good way of asking "can I upload this package directly?" [11:23] james_w: well, if someone from the xfce team uploads something that's defined as being part of gnome, or not part of anything, it would get queued for review, yes [11:23] in other words, the general meme is "don't reject uploads, either send them to the builds or queue them for review" [11:23] thanks, that's interesting [11:24] that describes the layer of "package upload permissions", really [11:24] i think w e will see a second layer emerging around access control to the branches that people use for package version control [11:24] sabdfl, This mechanism might replace some of the current sponsoring mechanisms more generally? [11:24] james_w's work around NoMoreSourcePackages [11:25] * dholbach hugs james_w [11:25] persia: yes. if you have someone who is an expert in a field, and is doing good work with that set of packages, it should be possible to empower them to upload those packages directly [11:25] so, we will have VCS for casual or specialist or upstream participation [11:25] and a richer model for sharing the archive between collaborating teams [11:25] with a more level playing field for folks who are trusted as generalists [11:25] I meant rather for those that weren't. Currently, we use subscription to special sponsoring teams, but the queued upload solution seems like a better model for those who do not (yet) have upload to a given package. [11:26] I think encouraging non-trivial uploads to be submitted as merge proposals would be sensible, as that is a better interface for review than pulling a package out of the unapproved queue [11:26] persia: at this stage, i'd prefer there to be a difference between the queue for review of packages uploaded by people who are already ubuntu developers SOMEWHERE (i.e. -studio or -xubuntu) [11:26] sabdfl, That makes sense. Thank you for the clarification. [11:26] vs package reviews for someone who is not [11:26] and avoids clashes where you wish to upload something that is awaiting review [11:27] james_w: yes, i don't think our current queue system is up to it, that's where we'll need to do some work [11:27] okdokey! [11:27] any other questions? or should we wrap? [11:27] thanks sabdfl [11:27] nothing from me [11:27] thank you dholbach :-) [11:27] we could always make the uploads in the queue available as branches of course [11:28] thank you sabdfl, interesting stuff [11:28] I'm sure there will be plenty more discussion on this topic [11:29] OK, adjourned :) [12:52] Hi all. Can anyone tell me where I can find the notes for previous meetings and classes? I had it but lost it! [12:53] CrownAmbassador, Notes are scattered, but irclogs.ubuntu.com may help. [12:54] persia: thanks === davmor2 is now known as davmor2-lunch === davmor2-lunch is now known as davmor2 === asac_ is now known as asac [15:57] heylo [15:58] o// [15:59] o/ [16:00] good day/night server folks! [16:01] \o [16:01] let's get started [16:01] #startmeeting [16:01] today's agenda: [16:01] https://wiki.ubuntu.com/ServerTeam/Meeting [16:02] last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090113 [16:02] [TOPIC] Screen Profiles [16:02] kirkland: I saw your post on screen-profiles [16:02] mathiaz: yessir [16:02] /o\ [16:02] mathiaz: i have uploaded a new copy, that changes the default escape sequence back to ctrl-a [16:02] what happened on this front last week? [16:03] mathiaz: that seemed to be the overwhelming opinion on the ubuntu-server@ list [16:03] mathiaz: nijaba is working on some new functionality that would allow that to be configurable [16:03] kirkland: agreed. [16:03] mathiaz: basically, all of the documentation out on the internet, and in all other distributions, the escape sequence is ctrl-a [16:03] mathiaz: there are some good reasons for it to be something else [16:04] kirkland: nijaba: are there other plans for screen-profiles? [16:04] mathiaz: but i'm thinking it's not our place to force that change on others [16:04] mathiaz: allowing for easy adjustment, however, would be a very good thing! [16:04] (beside escape sequence customization) [16:04] kirkland: agreed. [16:04] mathiaz: it has also been promoted to Main [16:04] mathiaz: we are going to have a chat later today with kirkland so that he can merge my changes, but AFAIK, we should be feature complete [16:04] mathiaz: the next thing i'd like to do is make the 'screen' package depend on it, to get screen-profiles on the server cd [16:05] should it be installed by default? [16:05] mathiaz: also, i'd like to make a minor modification to the screen package, to install the ubuntu profile created in screen-profiles to our default /etc/screenrc [16:05] mathiaz: i agree with 'feature-complete' [16:05] kirkland: if -profiles is in main, where is it seeded for now? [16:05] mathiaz: after some serious testing, I would vote for it being installed by default [16:05] mathiaz: it's not seeded yet [16:05] nijaba: for jaunty or jaunty+1? [16:05] kirkland: well - then it's not in main yet [16:05] mathiaz: i'm going to do that later today, with the screen dependency on screen-profiles [16:05] mathiaz: okay, then it's been 'approved' for main [16:06] mathiaz: sorry [16:06] kirkland: it is for you to seed it, core-dev ;) [16:06] kirkland: ok - dependency on screen. [16:06] mathiaz: right [16:06] [ACTION] kirkland to seed screen-profiles in main as dependency of screen [16:06] mathiaz: once that's done, i'm going to start another thread on ubuntu-server@, about whether or not we should launch screen on login [16:07] mathiaz: i suspect there will be some resistance to that, but we're going to suggest it [16:07] mathiaz: it's easy to configure that way, post install [16:07] mathiaz: but I'm using it on all of my systems, and I'm *loving* it [16:07] kirkland: let's make sure people understand HOW we are proposing this [16:07] [ACTION] kirkland to ask on ubuntu-server@ for screen by default on login [16:07] nijaba: okay, what do you mean by that? [16:07] kirkland: most people think it is replacing the default shel by screen [16:07] kirkland: which is not what we are doing [16:07] nijaba: right [16:08] nijaba: it's just a one-liner, added or removed from .bashrc and .bash_profile [16:08] kirkland: yes, but that changes everything, as it avoids launching screens in screen [16:08] [ACTION] nijaba to provide a way to customize the escape sequence when configuring screen profiles [16:08] kirkland: when connecting to another server [16:09] mathiaz: okay, so that's all from me on this item [16:09] mathiaz: [ACTION] already done, now at merging stage [16:09] kirkland: ok - seems that you'd have outline the technical implementation in your email [16:09] mathiaz: right [16:09] kirkland: great - thanks for the report. [16:09] let's move on. [16:09] [TOPIC] SRU for ebox [16:09] sommer: how is it going? [16:10] mathiaz: the questions about the patches have been answered, and foolano is working on the packages for jaunty [16:10] yep [16:10] mathiaz: so once those are uploaded, I guess we'll re-upload to proposed [16:11] foolano: where do you plan to publish your jaunty package? [16:11] mathiaz: they are already published, they in our ppa [16:12] i have opened bugs to request sponsorship, attached diff.gz and so on [16:12] foolano: which bug number? [16:12] foolano: from https://launchpad.net/~ebox/+archive - 0.12.4? [16:12] let me see, they are a few... [16:13] i opened a bug for every package: 318697, 318710, 318717, 318729, 318730, 318810, 318813, 318814, 318817, 318822, 318825, 318827, 318829,318830 [16:13] mathiaz: they are in ~ebox-unstable becasue they need some testing... [16:13] https://launchpad.net/~ebox-unstable/+archive [16:14] foolano: ok - is ebox-unstable ready for inclusion in jaunty? [16:14] bug 318697 [16:14] Launchpad bug 318697 in libebox "Please upgrade libebox to 0.12.2" [Undecided,Confirmed] https://launchpad.net/bugs/318697 [16:15] mathiaz: it's our stable version, it's in ebox-unstable because the pacaking for jaunty hasn't been tested a lot [16:15] bug 318710 [16:15] Launchpad bug 318710 in ebox "Please upgrade ebox to 0.12.4" [Undecided,Confirmed] https://launchpad.net/bugs/318710 [16:16] foolano: I'm confused by the version numbers: libebox 0.12.2 and ebox 0.12.4? [16:16] foolano: is it normal that these packages don't have the same version number? [16:16] mathiaz: yep, let me explain it to you [16:16] mathiaz: we release 0.12.0 as our first stable version [16:17] as we do bufgfixing we increase the last number 0.12.1, 0.12.2... [16:17] and we release every module separated [16:17] foolano: ok - makes sense. [16:17] foolano: thanks for explaining that. [16:18] I'll look at the packages. [16:18] great :) [16:18] [ACTION] mathiaz to look into ebox packages for jaunty sponsoring. [16:18] once the updated packages are in jaunty, what's next for intrepid? [16:19] we can request a SRU for intrepid then, right? [16:20] can't we re-upload to proposed, and ask for sponsorship from motu-sru? [16:21] yes - I think so. Has the package been rejected from the intrepid-proposed queue? [16:21] Or the motu-sru didn't give their ACK? [16:22] I believe the orginal one's chuck uploaded for me have been rejected [16:22] Were any change made to the intrepid packages? [16:23] ok - we'll sort this out once the new packages have been upload to jaunty. [16:23] as this is the first step to get a SRU working properly [16:23] I don't think there have been yet, but I believe foolano attached a patch to one of the bugs [16:23] ya, should be quick to do once the jaunty packages are in [16:24] anything else on the ebox front? [16:24] I think that's it [16:25] at least from me :) [16:25] nothing further :) [16:25] ok - let's move on [16:25] [TOPIC] MySQL 5.1 in jaunty [16:25] so I've looked into that [16:25] and things are not fixed yet. [16:25] the deeper I look the scarier it gets. [16:26] heh, when you look into the abyss the abyss looks back [16:26] I've emailed the Debian mysql maintainers and they don't have plans (for now) to support both 5.0 and 5.1 in archive [16:26] their plans is to release lenny with 5.0 [16:26] mathiaz: welcome to the party [16:26] and once lenny is released 5.1 would be uploaded to unstable [16:27] and library transition would be done at the very begining of the cycle. [16:27] The maintainer might consider having a interim period with 5.0 and 5.1 in the archive. [16:27] mathiaz: what are some of the challenges? [16:28] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2009-January/001433.html [16:29] the biggest problem is that /etc/mysql/my.cnf are both used by 5.0 and 5.1 but they're incompatible [16:29] right now installing mysql-server-5.1 pulls in the 5.0 my.conf which doesn't work [16:30] sounds like a confusing version name [16:30] if it isn [16:30] if it isn't compatible like that [16:30] well - it's incompatible at the Debian/Ubuntu level, not upstream [16:31] we ship 5.0 my.cnf with skip-bdb (because it's deprecated in 5.1) [16:31] and the skip-bdb option is not recognized in 5.1 [16:31] ahh [16:31] (which makes the server fail to start and the package fails to install) [16:32] so one of the option I've looked into is to support both 5.0 and 5.1 at the same time [16:32] since we plan to have 5.0 in main and 5.1 in universe in jaunty for now [16:32] having a structure similar to postgresql [16:32] with /etc/mysql/5.0/my.cnf and /etc/mysql/5.1/my.cnf [16:34] but that would require significant packaging work on both 5.0 and 5.1 [16:34] would they have uniq conf.d? [16:34] ivoks: yes. everything would move under /etc/mysql/5.X/ [16:34] init scripts have to be updated. [16:35] all the scripts would be under /usr/share/mysql/5.X/ [16:35] with /etc/mysql/conf.d/ or /etc/mysql/5.x/conf.d? [16:35] with wrapper scripts in /usr/bin/ using the correct installed version [16:35] ivoks: /etc/mysql/5.X/conf.d [16:35] this is how the postgresql packages are setup [16:36] you can install and run 8.2 and 8.3 at the same time in hardy [16:36] i know [16:36] which help in upgrading since you have access to the old version of the program [16:36] is it against debian policy to say have /etc/mysql/my.5.0.cnf and /etc/mysql/my.5.1.cnf and symlink one or the other to /etc/mysql/my.cnf? [16:36] one of the question I have is if that would be usefull for MySQL? [16:36] ie having access to both 5.0 and 5.1 at the same time? [16:37] since MySQL provides support for upgrading existing databases. [16:38] i think these ideas would take too much time to realize, and probably fail in the process [16:38] i don't even want to think how to handle /var/lib/mysql on updates [16:39] ivoks: well in the new scheme, you'd have /var/lib/mysql/5.0/ and /var/lib/mysql/5.1/ [16:39] mathiaz: so, if i upgrade my 5.0 to 5.1, i'll loose all my databases? [16:39] an upgrade would dump from mysq/5.0/ into mysql/5.1/ [16:40] what if someone would drive both of them? [16:40] i'm sure someone will try 5.1, set up databases and then realize that 5.0 was more stable :) [16:41] ivoks: hm.. seems that we should discuss this a bit more in depth. [16:41] another solution is to just remove the skip-bdb from my.cnf [16:41] but... don't get me wrong, if someone thinks this is worthwile, i don't mind :) [16:42] ivoks: I understand. As I said, setting up such a infrastructure would require significant packaging work [16:42] right [16:42] ivoks: and we should definetly get the opinion of the Debian maintainers [16:42] let's start diuscussion on mailing list [16:43] I'll reply to the thread mentionned above [16:43] I'll also look into other solution to fix the issue in jaunty [16:43] (i'll check logs, since i was late :) [16:43] [ACTION] mathiaz to ask Debian maintainer about supporting both 5.0 and 5.1 using a concept similar to postgresql [16:44] [ACTION] mathiaz to look in other ways to fix 5.1 in jaunty [16:44] ok - that's all I have from last week minutes [16:44] anything else to add wrt to last week minutes? [16:45] nope [16:45] [TOPIC] Open Discussion [16:45] anything else to add/discuss/brainstorm? [16:45] umm... at uds i mentioned ACL by default [16:46] i've sent patches for tar to debian matinainer [16:46] and it looks like support for acl, xattrs and selinux will get accepted in upstream in new version [16:47] ivoks: do you mean turning on ACL by default on new installs? [16:47] ivoks: is this in time for jaunty? [16:47] so, i would rather wait for those things to become part of upstream [16:47] mathiaz: i doubt [16:47] tar has 1-2 releases in a year [16:47] last release was in december, iirc [16:48] ivoks: what was the answer from the Debian maintainer? [16:48] he liked the idea, but he doesn't want to fork tar [16:48] ivoks: are there any other package that would be modified to support ACL by default? [16:48] so he keeps it clean as from upstream [16:49] mathiaz: cpio could be one of them, i didn't check it [16:49] zip also [16:50] ivoks: is there a wiki page to keep track of what needs to be done? [16:50] mathiaz: i'll set it up [16:50] ivoks: it seems that we'd make sure that all relevant packages have ACL support before turning it on by default [16:50] mathiaz: of course [16:51] ivoks: ok. So the first step would be to identify which packages need to support ACL [16:52] i'll set up wiki page with all the revelant stuff [16:52] ivoks: great. Thanks [16:52] [ACTION] ivoks to create wiki page to keep track of ACL support in packages [16:52] ok - anything else to add? [16:52] and i'll start working on mail stack, now that bacula/drbd stuff are covered [16:53] is drbd working in jaunty? [16:53] ivoks: did you test it? [16:53] kernel team just commited my patch [16:53] once we get new kernel, i'll merge drbd 8.3.0 userspace [16:53] i allready have it builded and tested [16:54] ivoks: ok. But we have to make sure that it works in jaunty too. [16:54] i'm talking about jaunty :) [16:54] [ACTION] ivoks to merge drbd 8.3.0 userspace tools once the kernel has been uploaded. [16:55] ivoks: I meant the jaunty archive, not your personal jaunty environment [16:55] hehe [16:55] ivoks: what's the state of bacula in jaunty? [16:56] mathiaz: mostly working, i've sent patches for hardy/intrepid/jaunty to zul [16:56] * nijaba needs to run. see you later all [16:56] mathiaz: with those patches, everything should be fixed in all versions [16:56] its on my pile [16:56] ivoks: are there bugs filed for these? [16:57] if anyone else is interested in sponsoring uploads? [16:57] mathiaz: not really [16:57] ivoks: are you using the sponsorship queues? [16:57] mathiaz: jaunty doesn't have a bug; it just doesn't work yet and probably no one tested it [16:57] ivoks: if you wanna get them fixed in hardy/intrepid you'll have to file bugs to get the SRU process going [16:58] and as for intrepid and hardy; bug pops up in rare cases [16:58] mathiaz: i know [16:58] ivoks: ok - we're running out of time [16:58] mathiaz: don't worry about that [16:58] sorry :) [16:58] ivoks: I'd suggest to file bug in LP and use the sponsorship queue. [16:58] [TOPIC] Agree on next meeting date and time [16:58] next week, same time, same place? [16:59] +1 [16:59] sure [16:59] sommer: o/ [16:59] oh - and a reminder - FeatureFreeze is in one month. [16:59] ok - so see you all in one week, same place, same time. [16:59] keep up the good work! [16:59] #endmeeting [17:00] thanks mathiaz, later on all [17:00] see you guys :) [17:01] Hello All... its time for the weekly Kernel Team Meeting. I would like to start the meeting at 15 past the hour. I have had a few requests to hold off until after the integration of the US President. That should be complete by then. We will run a condensed meeting. [17:02] * smb_tp acks [17:02] * apw is here [17:02] * cking acks [17:02] pgraner: it won't even be close to being done in 15 minutes. the're just getting started, [17:03] rtg: they just did the VP, there should be some items in between then the Prez [17:03] pgraner: is he joining the meeting or something? [17:03] :-D [17:04] kirkland: could open a whole new ave for Ubuntu :) [17:04] more a mall i think [17:04] kirkland: did you ever get to test file name encryption? [17:04] pgraner: he's too buddy-buddy with bill gates ;-) [17:04] running late apparently... [17:04] rtg: i'm hoping to finish the userspace bit today [17:05] rtg: i was trying to finish that first [17:05] he is messing it up! [17:06] kirkland: I think I'll include the encryption changes anyway. nothing breaks without the mount option. [17:06] rtg: sounds good [17:06] Its a done deal. [17:07] he must have been nervous [17:07] enough to fluff his lines, just like at weddings [17:07] yup [17:12] the pressure starts big time when he gets into the oval office [17:27] Ok folks let get started... [17:27] #startmeeting [17:27] * apw is here [17:27] * smb_tp here [17:27] * cking is here too [17:27] * pgraner wonders where the bot its [17:28] * rtg dries his eyes :) [17:28] Ok the agenda is here: https://wiki.ubuntu.com/KernelTeam/Meeting [17:28] * jpds gets someone on it. [17:28] * amitk is here [17:28] [TOPIC] Security & bugfix kernels [17:28] * sconklin is here [17:28] Ok, Hardy point release looks good, so far. [17:29] smb_tp: that goes out thurs according to schedule correct? [17:29] Intrepid seems to notice as soon as I want to get archive admins to push to -updates [17:29] pgraner, correct [17:29] smb_tp: what about the cifs regression? [17:29] rtg, exactly that [17:29] Turned up just this weekend [17:30] So I am looking into that one [17:30] smb_tp: is it a show stopper? [17:30] smb_tp: what releases does it appear in? [17:30] I would think so. Quite some people use samba. It might be related only to ipv6 [17:31] pgraner, Current info is after current -9 in updates [17:31] -9 still works. There have been some updates through stable [17:32] Question would be if this is only ipv6, should it hold up the update? [17:32] smb_tp: anything else? [17:33] CVE kernels (daper -hardy) I got prepared and i386 run tested [17:33] Intrepid does not need security updates atm [17:33] smb_tp: Thanks [17:33] [TOPIC] Jaunty Status [17:33] Alpha 3 Feedback: ogasawara how are we looking? [17:34] pgraner: I've been informally tracking. . . no official bugs have been reported via apport [17:34] ogasawara: none? [17:34] pgraner: none. but response via email/irc seems positive with the exception of the wakealarm being an issue for some [17:35] ogasawara: yea, I saw that as well [17:35] pgraner: I have not heard of any failures thus far [17:35] if we are talking suspend bugs? they would only be reported correctly if the system was updated, a bug in the pm-utils changes [17:35] [TOPIC] Suspend/Resume [17:36] pgraner: bah, I was thinking suspend/resume above [17:36] from an automation point of view we have had one bug in pm-utils changes which [17:36] apw: I saw we had some changes to the scripts, are we good to go now? [17:36] has now been pushed out to -updates [17:36] i have also added some more reporting, which is still waiting to be pushed out, but less important [17:37] with that in place, we will have the bits in place and tested and working and in place [17:37] apw: So I guess A3 was a bust then from the reporting POV [17:37] well if they update, they will report from then, my a3 install updated and had the fixes [17:37] we have had a fair bit of feedback internally, mostly positive, except as leanne [17:38] indicated the auto wakeup failures which is something broken upstream [17:38] but manual wakes has worked so far ... [17:38] so generally good testiing results [17:38] apw: any idea when the auto wake up will be addressed? [17:38] leann has also started tagging older bugs whcih are suspend related and i want to [17:38] start reviewing those soon [17:39] not had time to look yet at the cause to see if its fixed yet so no feel yet [17:39] apw: ack [17:39]