[09:06]  * persia is a bit late
[09:08] <persia> 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] <persia> Well, in the absence of anyone else, I'm cancelling the meeting.  Apologies to those seeking membership this week.
[09:22] <MaWaLe> thx persia
[09:56] <amachu> persia: Hi
[09:57] <persia> Hi.  I think it's 10:00 UTC now.  Only MaWaLe admitted to coming to the meeting, so I cancelled it.
[09:58] <amachu> yes. I got that. Ok. I need to send invitation prior and remind people
[09:58] <amachu> Well, so do we need to have the next meeting at 15.00 UTC
[09:58] <amachu> or will it clash
[09:59] <persia> It would clash.
[10:00] <amachu> fine, then Lets have it at 11.00 UTC, the time we used to meet regularly
[10:00] <amachu> what do you say?
[10:08] <persia> Well, isn't that bad over there?
[10:19] <amachu> persia: means?
[10:19] <amachu> India
[10:20] <persia> Yeah.
[10:20] <persia> Next Tuesday 11:00 is bad for me for other reasons, but my personal schedule shouldn't be the deciding factor.
[10:32] <amachu> persia: Ok. I will mail the group
[10:32] <persia> That sounds like a better plan.
[10:59] <dholbach> hi elmo
[11:00] <dholbach> I pinged sabdfl and mako also, although I'm not sure that mako is up already
[11:02] <dholbach> https://wiki.ubuntu.com/CommunityCouncilAgenda is empty afaics
[11:02] <dholbach> is here anybody with other business for the CC meeting?
[11:12] <sabdfl> hello all
[11:12] <dholbach> ah hi sabdfl! :)
[11:12] <sabdfl> sorry for the delay
[11:12] <dholbach> https://wiki.ubuntu.com/CommunityCouncilAgenda is empty and I got no AOB from the people in here
[11:13] <sabdfl> nothing from me
[11:13] <dholbach> elmo: anything from you?
[11:13] <sabdfl> do folks want an update on archivereorg?
[11:13] <james_w> that would be interesting
[11:13] <sabdfl> i think it is quite a big step from a community structure / management / leadership / organisation perspective
[11:14] <sabdfl> yes? no?
[11:15] <james_w> I agree
[11:15] <sabdfl> ok, i'll do a quick summary
[11:15] <sabdfl> the goal is to help scale our developer communit(ies), while at the same time removing unnecessary fragmentation
[11:16] <sabdfl> we hope to achieve the scaling by allowing groups of developers with specific interests to collaborate around sets of packages in ubuntu
[11:16] <sabdfl> for example, xfce folks around the set of packages that represent xfce in ubuntu, or documentation folks around the content packages
[11:17] <sabdfl> 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] <sabdfl> also, they will be evaluated and approved by the leaders of those specific communities
[11:17] <sabdfl> with some provisions for maintaining a high standard across the board
[11:18] <sabdfl> so, hopefully we have a better match of interests and permissions for more new developers
[11:18] <sabdfl> all developers that have upload to ubuntu will be considered ubuntu developers, and get a vote in the developer community
[11:18] <sabdfl> for example, in the TB elections
[11:19] <sabdfl> separately, we will unify the "generalist developer teams", currently split into -core and -motu
[11:19] <james_w> 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] <sabdfl> so, there will only be one team of generalist developers
[11:19] <sabdfl> some of current motu folks will start out in a focused team, others will start out in the new unified generalist team
[11:19] <sabdfl> we agreed to be conservative in unleashing the new force of potential fragmentation :-)
[11:20] <sabdfl> so, we will probably have 5-10 focus areas initially
[11:20] <sabdfl> gnome, kde, xfce, documentation, mozilla/xul, toolchain, java, etc
[11:20] <sabdfl> there hasn't been a decision-making conversation about that initial set
[11:20] <sabdfl> finally, there will be some portions of the archive where you will need specialised knowledge to have immediate write access
[11:21] <sabdfl> there's no final spec as to which areas they are
[11:21] <sabdfl> but they will not be concentric (i.e. we won't have a simplistic "more trusted, less trusted" approach)
[11:21] <sabdfl> kernel team gets kernel, and so on
[11:22] <sabdfl> we will try to facilitate participation in those areas by others, too
[11:22] <sabdfl> so any ubuntu developer will be able to upload to the kernel
[11:22] <sabdfl> but the upload will need to be reviewed
[11:22] <sabdfl> and there is a commitment to make sure those reviews happen timeously
[11:22] <sabdfl> that's about it
[11:22] <james_w> is that review something that could be extended across the board?
[11:23] <james_w> otherwise we need a good way of asking "can I upload this package directly?"
[11:23] <sabdfl> 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] <sabdfl> in other words, the general meme is "don't reject uploads, either send them to the builds or queue them for review"
[11:23] <james_w> thanks, that's interesting
[11:24] <sabdfl> that describes the layer of "package upload permissions", really
[11:24] <sabdfl> 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] <persia> sabdfl, This mechanism might replace some of the current sponsoring mechanisms more generally?
[11:24] <sabdfl> james_w's work around NoMoreSourcePackages
[11:25]  * dholbach hugs james_w
[11:25] <sabdfl> 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] <sabdfl> so, we will have VCS for casual or specialist or upstream participation
[11:25] <sabdfl> and a richer model for sharing the archive between collaborating teams
[11:25] <sabdfl> with a more level playing field for folks who are trusted as generalists
[11:25] <persia> 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] <james_w> 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] <sabdfl> 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] <persia> sabdfl, That makes sense.  Thank you for the clarification.
[11:26] <sabdfl> vs package reviews for someone who is not
[11:26] <james_w> and avoids clashes where you wish to upload something that is awaiting review
[11:27] <sabdfl> 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] <sabdfl> okdokey!
[11:27] <sabdfl> any other questions? or should we wrap?
[11:27] <dholbach> thanks sabdfl
[11:27] <dholbach> nothing from me
[11:27] <sabdfl> thank you dholbach :-)
[11:27] <james_w> we could always make the uploads in the queue available as branches of course
[11:28] <james_w> thank you sabdfl, interesting stuff
[11:28] <james_w> I'm sure there will be plenty more discussion on this topic
[11:29] <dholbach> OK, adjourned :)
[12:52] <CrownAmbassador> 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] <persia> CrownAmbassador, Notes are scattered, but irclogs.ubuntu.com may help.
[12:54] <CrownAmbassador> persia: thanks
[15:57] <zul> heylo
[15:58] <sommer> o//
[15:59] <kirkland> o/
[16:00] <mathiaz> good day/night server folks!
[16:01] <nijaba> \o
[16:01] <mathiaz> let's get started
[16:01] <mathiaz> #startmeeting
[16:01] <mathiaz> today's agenda:
[16:01] <mathiaz> https://wiki.ubuntu.com/ServerTeam/Meeting
[16:02] <mathiaz> last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090113
[16:02] <mathiaz> [TOPIC] Screen Profiles
[16:02] <mathiaz> kirkland: I saw your post on screen-profiles
[16:02] <kirkland> mathiaz: yessir
[16:02] <nijaba>   /o\
[16:02] <kirkland> mathiaz: i have uploaded a new copy, that changes the default escape sequence back to ctrl-a
[16:02] <mathiaz> what happened on this front last week?
[16:03] <kirkland> mathiaz: that seemed to be the overwhelming opinion on the ubuntu-server@ list
[16:03] <kirkland> mathiaz: nijaba is working on some new functionality that would allow that to be configurable
[16:03] <mathiaz> kirkland: agreed.
[16:03] <kirkland> mathiaz: basically, all of the documentation out on the internet, and in all other distributions, the escape sequence is ctrl-a
[16:03] <kirkland> mathiaz: there are some good reasons for it to be something else
[16:04] <mathiaz> kirkland: nijaba: are there other plans for screen-profiles?
[16:04] <kirkland> mathiaz: but i'm thinking it's not our place to force that change on others
[16:04] <kirkland> mathiaz: allowing for easy adjustment, however, would be a very good thing!
[16:04] <mathiaz> (beside escape sequence customization)
[16:04] <mathiaz> kirkland: agreed.
[16:04] <kirkland> mathiaz: it has also been promoted to Main
[16:04] <nijaba> 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] <kirkland> 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] <mathiaz> should it be installed by default?
[16:05] <kirkland> 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] <kirkland> mathiaz: i agree with 'feature-complete'
[16:05] <mathiaz> kirkland: if -profiles is in main, where is it seeded for now?
[16:05] <nijaba> mathiaz: after some serious testing, I would vote for it being installed by default
[16:05] <kirkland> mathiaz: it's not seeded yet
[16:05] <mathiaz> nijaba: for jaunty or jaunty+1?
[16:05] <mathiaz> kirkland: well - then it's not in main yet
[16:05] <kirkland> mathiaz: i'm going to do that later today, with the screen dependency on screen-profiles
[16:05] <kirkland> mathiaz: okay, then it's been 'approved' for main
[16:06] <kirkland> mathiaz: sorry
[16:06] <nijaba> kirkland: it is for you to seed it, core-dev ;)
[16:06] <mathiaz> kirkland: ok - dependency on screen.
[16:06] <kirkland> mathiaz: right
[16:06] <mathiaz> [ACTION] kirkland to seed screen-profiles in main as dependency of screen
[16:06] <kirkland> 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] <kirkland> mathiaz: i suspect there will be some resistance to that, but we're going to suggest it
[16:07] <kirkland> mathiaz: it's easy to configure that way, post install
[16:07] <kirkland> mathiaz: but I'm using it on all of my systems, and I'm *loving* it
[16:07] <nijaba> kirkland: let's make sure people understand HOW we are proposing this
[16:07] <mathiaz> [ACTION] kirkland to ask on ubuntu-server@ for screen by default on login
[16:07] <kirkland> nijaba: okay, what do you mean by that?
[16:07] <nijaba> kirkland: most people think it is replacing the default shel by screen
[16:07] <nijaba> kirkland: which is not what we are doing
[16:07] <kirkland> nijaba: right
[16:08] <kirkland> nijaba: it's just a one-liner, added or removed from .bashrc and .bash_profile
[16:08] <nijaba> kirkland: yes, but that changes everything, as it avoids launching screens in screen
[16:08] <mathiaz> [ACTION] nijaba to provide a way to customize the escape sequence when configuring screen profiles
[16:08] <nijaba> kirkland: when connecting to another server
[16:09] <kirkland> mathiaz: okay, so that's all from me on this item
[16:09] <nijaba> mathiaz: [ACTION] already done, now at merging stage
[16:09] <mathiaz> kirkland: ok - seems that you'd have outline the technical implementation in your email
[16:09] <kirkland> mathiaz: right
[16:09] <mathiaz> kirkland: great - thanks for the report.
[16:09] <mathiaz> let's move on.
[16:09] <mathiaz> [TOPIC] SRU for ebox
[16:09] <mathiaz> sommer: how is it going?
[16:10] <sommer> mathiaz: the questions about the patches have been answered, and foolano is working on the packages for jaunty
[16:10] <foolano> yep
[16:10] <sommer> mathiaz: so once those are uploaded, I guess we'll re-upload to proposed
[16:11] <mathiaz> foolano: where do you plan to publish your jaunty package?
[16:11] <foolano> mathiaz: they are already published, they in our  ppa
[16:12] <foolano> i have opened bugs to request sponsorship, attached diff.gz and so on
[16:12] <mathiaz> foolano: which bug number?
[16:12] <mathiaz> foolano: from https://launchpad.net/~ebox/+archive - 0.12.4?
[16:12] <foolano> let me see, they are a few...
[16:13] <foolano> i opened a bug for every package: 318697, 318710, 318717, 318729, 318730, 318810, 318813, 318814, 318817, 318822, 318825, 318827, 318829,318830
[16:13] <foolano> mathiaz: they are in ~ebox-unstable becasue they need some testing...
[16:13] <foolano> https://launchpad.net/~ebox-unstable/+archive
[16:14] <mathiaz> foolano: ok - is ebox-unstable ready for inclusion in jaunty?
[16:14] <mathiaz> bug 318697
[16:15] <foolano> mathiaz:  it's our stable version,  it's in ebox-unstable because the pacaking for jaunty hasn't been tested  a lot
[16:15] <nealmcb> bug 318710
[16:16] <mathiaz> foolano: I'm confused by the version numbers: libebox 0.12.2 and ebox 0.12.4?
[16:16] <mathiaz> foolano: is it normal that these packages don't have the same version number?
[16:16] <foolano> mathiaz: yep, let me explain it to you
[16:16] <foolano> mathiaz: we release 0.12.0 as our first stable version
[16:17] <foolano> as we do bufgfixing we increase the last number 0.12.1, 0.12.2...
[16:17] <foolano> and we release every module separated
[16:17] <mathiaz> foolano: ok - makes sense.
[16:17] <mathiaz> foolano: thanks for explaining that.
[16:18] <mathiaz> I'll look at the packages.
[16:18] <foolano> great :)
[16:18] <mathiaz> [ACTION] mathiaz to look into ebox packages for jaunty sponsoring.
[16:18] <mathiaz> once the updated packages are in jaunty, what's next for intrepid?
[16:19] <foolano> we can request a SRU for intrepid then, right?
[16:20] <sommer> can't we re-upload to proposed, and ask for sponsorship from motu-sru?
[16:21] <mathiaz> yes - I think so. Has the package been rejected from the intrepid-proposed queue?
[16:21] <mathiaz> Or the motu-sru didn't give their ACK?
[16:22] <sommer> I believe the orginal one's chuck uploaded for me have been rejected
[16:22] <mathiaz> Were any change made to the intrepid packages?
[16:23] <mathiaz> ok - we'll sort this out once the new packages have been upload to jaunty.
[16:23] <mathiaz> as this is the first step to get a SRU working properly
[16:23] <sommer> I don't think there have been yet, but I believe foolano attached a patch to one of the bugs
[16:23] <sommer> ya, should be quick to do once the jaunty packages are in
[16:24] <mathiaz> anything else on the ebox front?
[16:24] <sommer> I think that's it
[16:25] <sommer> at least from me :)
[16:25] <foolano> nothing further :)
[16:25] <mathiaz> ok - let's move on
[16:25] <mathiaz> [TOPIC] MySQL 5.1 in jaunty
[16:25] <mathiaz> so I've looked into that
[16:25] <mathiaz> and things are not fixed yet.
[16:25] <mathiaz> the deeper I look the scarier it gets.
[16:26] <sommer> heh, when you look into the abyss the abyss looks back
[16:26] <mathiaz> 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] <mathiaz> their plans is to release lenny with 5.0
[16:26] <zul> mathiaz: welcome to the party
[16:26] <mathiaz> and once lenny is released 5.1 would be uploaded to unstable
[16:27] <mathiaz> and library transition would be done at the very begining of the cycle.
[16:27] <mathiaz> The maintainer might consider having a interim period with 5.0 and 5.1 in the archive.
[16:27] <nealmcb> mathiaz: what are some of the challenges?
[16:28] <mathiaz> http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2009-January/001433.html
[16:29] <mathiaz> the biggest problem is that /etc/mysql/my.cnf are both used by 5.0 and 5.1 but they're incompatible
[16:29] <mathiaz> right now installing mysql-server-5.1 pulls in the 5.0 my.conf which doesn't work
[16:30] <nealmcb> sounds like a confusing version name
[16:30] <nealmcb> if it isn
[16:30] <nealmcb> if it isn't compatible like that
[16:30] <mathiaz> well - it's incompatible at the Debian/Ubuntu level, not upstream
[16:31] <mathiaz> we ship 5.0 my.cnf with skip-bdb (because it's deprecated in 5.1)
[16:31] <mathiaz> and the skip-bdb option is not recognized in 5.1
[16:31] <nealmcb> ahh
[16:31] <mathiaz> (which makes the server fail to start and the package fails to install)
[16:32] <mathiaz> so one of the option I've looked into is to support both 5.0 and 5.1 at the same time
[16:32] <mathiaz> since we plan to have 5.0 in main and 5.1 in universe in jaunty for now
[16:32] <mathiaz> having a structure similar to postgresql
[16:32] <mathiaz> with /etc/mysql/5.0/my.cnf and /etc/mysql/5.1/my.cnf
[16:34] <mathiaz> but that would require significant packaging work on both 5.0 and 5.1
[16:34] <ivoks> would they have uniq conf.d?
[16:34] <mathiaz> ivoks: yes. everything would move under /etc/mysql/5.X/
[16:34] <mathiaz> init scripts have to be updated.
[16:35] <mathiaz> all the scripts would be under /usr/share/mysql/5.X/
[16:35] <ivoks> with /etc/mysql/conf.d/ or /etc/mysql/5.x/conf.d?
[16:35] <mathiaz> with wrapper scripts in /usr/bin/ using the correct installed version
[16:35] <mathiaz> ivoks: /etc/mysql/5.X/conf.d
[16:35] <mathiaz> this is how the postgresql packages are setup
[16:36] <mathiaz> you can install and run 8.2 and 8.3 at the same time in hardy
[16:36] <ivoks> i know
[16:36] <mathiaz> which help in upgrading since you have access to the old version of the program
[16:36] <sommer> 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] <mathiaz> one of the question I have is if that would be usefull for MySQL?
[16:36] <mathiaz> ie having access to both 5.0 and 5.1 at the same time?
[16:37] <mathiaz> since MySQL provides support for upgrading existing databases.
[16:38] <ivoks> i think these ideas would take too much time to realize, and probably fail in the process
[16:38] <ivoks> i don't even want to think how to handle /var/lib/mysql on updates
[16:39] <mathiaz> ivoks: well in the new scheme, you'd have /var/lib/mysql/5.0/ and /var/lib/mysql/5.1/
[16:39] <ivoks> mathiaz: so, if i upgrade my 5.0 to 5.1, i'll loose all my databases?
[16:39] <mathiaz> an upgrade would dump from mysq/5.0/ into mysql/5.1/
[16:40] <ivoks> what if someone would drive both of them?
[16:40] <ivoks> i'm sure someone will try 5.1, set up databases and then realize that 5.0 was more stable :)
[16:41] <mathiaz> ivoks: hm.. seems that we should discuss this a bit more in depth.
[16:41] <mathiaz> another solution is to just remove the skip-bdb from my.cnf
[16:41] <ivoks> but... don't get me wrong, if someone thinks this is worthwile, i don't mind :)
[16:42] <mathiaz> ivoks: I understand. As I said, setting up such a infrastructure would require significant packaging work
[16:42] <ivoks> right
[16:42] <mathiaz> ivoks: and we should definetly get the opinion of the Debian maintainers
[16:42] <ivoks> let's start diuscussion on mailing list
[16:43] <mathiaz> I'll reply to the thread mentionned above
[16:43] <mathiaz> I'll also look into other solution to fix the issue in jaunty
[16:43] <ivoks> (i'll check logs, since i was late :)
[16:43] <mathiaz> [ACTION] mathiaz to ask Debian maintainer about supporting both 5.0 and 5.1 using a concept similar to postgresql
[16:44] <mathiaz> [ACTION] mathiaz to look in other ways to fix 5.1 in jaunty
[16:44] <mathiaz> ok - that's all I have from last week minutes
[16:44] <mathiaz> anything else to add wrt to last week minutes?
[16:45] <mathiaz> nope
[16:45] <mathiaz> [TOPIC] Open Discussion
[16:45] <mathiaz> anything else to add/discuss/brainstorm?
[16:45] <ivoks> umm... at uds i mentioned ACL by default
[16:46] <ivoks> i've sent patches for tar to debian matinainer
[16:46] <ivoks> and it looks like support for acl, xattrs and selinux will get accepted in upstream in new version
[16:47] <mathiaz> ivoks: do you mean turning on ACL by default on new installs?
[16:47] <mathiaz> ivoks: is this in time for jaunty?
[16:47] <ivoks> so, i would rather wait for those things to become part of upstream
[16:47] <ivoks> mathiaz: i doubt
[16:47] <ivoks> tar has 1-2 releases in a year
[16:47] <ivoks> last release was in december, iirc
[16:48] <mathiaz> ivoks: what was the answer from the Debian maintainer?
[16:48] <ivoks> he liked the idea, but he doesn't want to fork tar
[16:48] <mathiaz> ivoks: are there any other package that would be modified to support ACL by default?
[16:48] <ivoks> so he keeps it clean as from upstream
[16:49] <ivoks> mathiaz: cpio could be one of them, i didn't check it
[16:49] <ivoks> zip also
[16:50] <mathiaz> ivoks: is there a wiki page to keep track of what needs to be done?
[16:50] <ivoks> mathiaz: i'll set it up
[16:50] <mathiaz> ivoks: it seems that we'd make sure that all relevant packages have ACL support before turning it on by default
[16:50] <ivoks> mathiaz: of course
[16:51] <mathiaz> ivoks: ok. So the first step would be to identify which packages need to support ACL
[16:52] <ivoks> i'll set up wiki page with all the revelant stuff
[16:52] <mathiaz> ivoks: great. Thanks
[16:52] <mathiaz> [ACTION] ivoks to create wiki page to keep track of ACL support in packages
[16:52] <mathiaz> ok - anything else to add?
[16:52] <ivoks> and i'll start working on mail stack, now that bacula/drbd stuff are covered
[16:53] <mathiaz> is drbd working in jaunty?
[16:53] <mathiaz> ivoks: did you test it?
[16:53] <ivoks> kernel team just commited my patch
[16:53] <ivoks> once we get new kernel, i'll merge drbd 8.3.0 userspace
[16:53] <ivoks> i allready have it builded and tested
[16:54] <mathiaz> ivoks: ok. But we have to make sure that it works in jaunty too.
[16:54] <ivoks> i'm talking about jaunty :)
[16:54] <mathiaz> [ACTION] ivoks to merge drbd 8.3.0 userspace tools once the kernel has been uploaded.
[16:55] <mathiaz> ivoks: I meant the jaunty archive, not your personal jaunty environment
[16:55] <ivoks> hehe
[16:55] <mathiaz> ivoks: what's the state of bacula in jaunty?
[16:56] <ivoks> 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] <ivoks> mathiaz: with those patches, everything should be fixed in all versions
[16:56] <zul> its on my pile
[16:56] <mathiaz> ivoks: are there bugs filed for these?
[16:57] <ivoks> if anyone else is interested in sponsoring uploads?
[16:57] <ivoks> mathiaz: not really
[16:57] <mathiaz> ivoks: are you using the sponsorship queues?
[16:57] <ivoks> mathiaz: jaunty doesn't have a bug; it just doesn't work yet and probably no one tested it
[16:57] <mathiaz> ivoks: if you wanna get them fixed in hardy/intrepid you'll have to file bugs to get the SRU process going
[16:58] <ivoks> and as for intrepid and hardy; bug pops up in rare cases
[16:58] <ivoks> mathiaz: i know
[16:58] <mathiaz> ivoks: ok - we're running out of time
[16:58] <ivoks> mathiaz: don't worry about that
[16:58] <ivoks> sorry :)
[16:58] <mathiaz> ivoks: I'd suggest to file bug in LP and use the sponsorship queue.
[16:58] <mathiaz> [TOPIC] Agree on next meeting date and time
[16:58] <mathiaz> next week, same time, same place?
[16:59] <sommer> +1
[16:59] <ivoks> sure
[16:59] <ivoks> sommer: o/
[16:59] <mathiaz> oh - and a reminder - FeatureFreeze is in one month.
[16:59] <mathiaz> ok - so see you all in one week, same place, same time.
[16:59] <mathiaz> keep up the good work!
[16:59] <mathiaz> #endmeeting
[17:00] <sommer> thanks mathiaz, later on all
[17:00] <foolano> see you guys :)
[17:01] <pgraner> 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] <rtg> pgraner: it won't even be close to being done in 15 minutes. the're just getting started,
[17:03] <pgraner> rtg: they just did the VP, there should be some items in between then the Prez
[17:03] <kirkland> pgraner: is he joining the meeting or something?
[17:03] <kirkland> :-D
[17:04] <pgraner> kirkland: could open a whole new ave for Ubuntu :)
[17:04] <apw> more a mall i think
[17:04] <rtg> kirkland: did you ever get to test file name encryption?
[17:04] <kirkland> pgraner: he's too buddy-buddy with bill gates ;-)
[17:04] <apw> running late apparently...
[17:04] <kirkland> rtg: i'm hoping to finish the userspace bit today
[17:05] <kirkland> rtg: i was trying to finish that first
[17:05] <apw> he is messing it up!
[17:06] <rtg> kirkland: I think I'll include the encryption changes anyway. nothing breaks without the mount option.
[17:06] <kirkland> rtg: sounds good
[17:06] <lieb> Its a done deal.
[17:07] <rtg> he must have been nervous
[17:07] <apw> enough to fluff his lines, just like at weddings
[17:07] <lieb> yup
[17:12] <cking> the pressure starts big time when he gets into the oval office
[17:27] <pgraner> Ok folks let get started...
[17:27] <pgraner> #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] <pgraner> 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] <pgraner> [TOPIC] Security & bugfix kernels
[17:28]  * sconklin is here
[17:28] <smb_tp> Ok, Hardy point release looks good, so far.
[17:29] <pgraner> smb_tp: that goes out thurs according to schedule correct?
[17:29] <smb_tp> Intrepid seems to notice as soon as I want to get archive admins to push to -updates
[17:29] <smb_tp> pgraner, correct
[17:29] <rtg> smb_tp: what about the cifs regression?
[17:29] <smb_tp> rtg, exactly that
[17:29] <smb_tp> Turned up just this weekend
[17:30] <smb_tp> So I am looking into that one
[17:30] <rtg> smb_tp: is it a show stopper?
[17:30] <pgraner> smb_tp: what releases does it appear in?
[17:30] <smb_tp> I would think so. Quite some people use samba. It might be related only to ipv6
[17:31] <smb_tp> pgraner, Current info is after current -9 in updates
[17:31] <smb_tp> -9 still works. There have been some updates through stable
[17:32] <smb_tp> Question would be if this is only ipv6, should it hold up the update?
[17:32] <pgraner> smb_tp: anything else?
[17:33] <smb_tp> CVE kernels (daper -hardy) I got prepared and i386 run tested
[17:33] <smb_tp> Intrepid does not need security updates atm
[17:33] <pgraner> smb_tp: Thanks
[17:33] <pgraner> [TOPIC] Jaunty Status
[17:33] <pgraner> Alpha 3 Feedback: ogasawara how are we looking?
[17:34] <ogasawara> pgraner: I've been informally tracking. . . no official bugs have been reported via apport
[17:34] <pgraner> ogasawara: none?
[17:34] <ogasawara> pgraner: none.  but response via email/irc seems positive with the exception of the wakealarm being an issue for some
[17:35] <pgraner> ogasawara: yea, I saw that as well
[17:35] <ogasawara> pgraner: I have not heard of any failures thus far
[17:35] <apw> 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] <pgraner> [TOPIC] Suspend/Resume
[17:36] <ogasawara> pgraner: bah, I was thinking suspend/resume above
[17:36] <apw> from an automation point of view we have had one bug in pm-utils changes which
[17:36] <pgraner> apw: I saw we had some changes to the scripts, are we good to go now?
[17:36] <apw> has now been pushed out to -updates
[17:36] <apw> i have also added some more reporting, which is still waiting to be pushed out, but less important
[17:37] <apw> with that in place, we will have the bits in place and tested and working and in place
[17:37] <pgraner> apw: So I guess A3 was a bust then from the reporting POV
[17:37] <apw> well if they update, they will report from then, my a3 install updated and had the  fixes
[17:37] <apw> we have had a fair bit of feedback internally, mostly positive, except as leanne
[17:38] <apw> indicated the auto wakeup failures which is something broken upstream
[17:38] <apw> but manual wakes has worked so far ...
[17:38] <apw> so generally good testiing results
[17:38] <pgraner> apw: any idea when the auto wake up will be addressed?
[17:38] <apw> leann has also started tagging older bugs whcih are suspend related and i want to
[17:38] <apw> start reviewing those soon
[17:39] <apw> not had time to look yet at the cause to see if its fixed yet so no feel yet
[17:39] <pgraner> apw: ack
[17:39] <apw> ogasawara, i think you had a pointer to the underlyuing wakeup bug?
[17:40] <ogasawara> apw: yup http://bugzilla.kernel.org/show_bug.cgi?id=12013
[17:40] <apw> thanks
[17:40] <pgraner> apw: any lessons learned out of A3?
[17:41] <apw> most of my time on s/r has been fixing the bugs in the automation, not had much time to look for any results, though as there is no failures so far i think i have nothing to base an oppinion
[17:41] <apw> other than, it is better than i might have expected
[17:41] <pgraner> apw: understood, I was looking for things like if we undertake an task like this again how can we do it better?
[17:42] <apw> ahh, cirtianly we should have planned to be ready sooner so we could ahve tested the combined bits before the release
[17:42] <apw> mostly we only had the combined uploads sorted out on the day and that was too late to find and fix the errors
[17:42] <pgraner> apw: this gets into the UDS vs. Release schedule timing
[17:43] <apw> the rest of the issues are 'training' issues, things now learned should not occur again
[17:43] <sconklin> I think part of the latreness can be tracked to the late summit and the holiday break
[17:43] <pgraner> apw: not to mention this cycle had the holiday break which didn't help much
[17:43] <apw> but we were also working to the deadline of thursday, when we should have worked to monday or tuesday
[17:43] <apw> to get things in place before the last minute cut off
[17:44] <pgraner> apw: noted, we need to back the milestone back a few days not being the Alpha date
[17:44] <apw> yeah, a day or two before is better
[17:44] <pgraner> [ACTION] pgraner to revise the schedule going forward
[17:45] <pgraner> [TOPIC] Vanilla Kernel Builds
[17:45] <pgraner> apw: can we move this to someone else since your slammed? and if so recommendations?
[17:45] <apw> i think we were going to tackle these in berlin
[17:46] <rtg> pgraner: I'll take care of it.
[17:46] <apw> sure we can, i seem to rememver you an i were going to discuss this after last meeting and failed to do so
[17:46] <apw> rtg ok ... if you are going to attempt this in a PPA i have some base work that might be wort having
[17:46] <pgraner> apw, rtg: see what you guys can work out prior so during berlin we can get working
[17:46] <rtg> apw: I'm gonna build it native on zinc.
[17:46] <apw> will do
[17:47] <apw> rtg actually then my script might do what you want
[17:47] <apw> it makes a virgin tree with out build machinary in it
[17:47] <apw> building just the .debs from there would be easy
[17:47] <rtg> apw: I just have to get elmo to open a route to kernel.org
[17:48] <apw> by which i mean it puts our machinary into the virgin tree, and builds it
[17:48] <apw> if you can get that, i suspect its not a big job to get this script producing something
[17:48] <apw> it was getting it to work in a ppa that i was stuggling with
[17:48] <rtg> apw: cool. have you committed it to Jaunty (the script I mean)
[17:49] <apw> not yet.  will do that
[17:49] <pgraner> [ACTION] apw to commit vanilla kernel build script to Jaunty tree
[17:49] <rtg> on the topic of Jaunty, I'm uploading Jaunty later today, includes 2.6.28.1, drm fixes, ecryptfs filename encryption. It _is_ an ABI bump.
[17:50] <apw> is that the huge wedge of upstream updates?  or is that .2
[17:50] <rtg> .1 is pretty big
[17:50] <rtg> 94 patches
[17:50] <pgraner> rtg: reminder to email the normal parties :-)
[17:50] <smb_tp> 2.6.27.12 as well
[17:50] <Golgata> hi everybody
[17:50] <rtg> pgraner: of course
[17:51] <pgraner> [TOPIC] ARM Tree
[17:51] <pgraner> amitk, rtg: where are we?
[17:51] <rtg> the kernel at least builds now
[17:51] <Golgata> hope someone can help me. i want to create a container usable with virtualbox which i can later burn to a dvd... sb got an idea?
[17:52] <pgraner> Golgata: This is the meeting channel during an ongoing meeting, try #ubuntu-devel pls.
[17:52] <amitk> rtg: I noticed you added udeb stuff too
[17:52] <rtg> the debian installer folks should now be able to create an install disk
[17:52] <Golgata> urgs, sorry... cu ^^
[17:52] <amitk> pgraner: I am working on another pass at the configs and then enabling two OEM boards
[17:53] <pgraner> amitk: ack
[17:53] <pgraner> amitk: make sure you get with the mobile team to make sure everything is synced up. There has been alot of activity over the last few weeks.
[17:54] <pgraner> amitk: good to have you back :-D
[17:54] <pgraner> [TOPIC] LPIA tree
[17:54] <amitk> pgraner: sure. I should have more to talk about next week.
[17:54] <pgraner> sconklin: how r we doing?
[17:55]  * apw thinks sconklin is on mute
[17:55] <sconklin> I'm in the middle of rebasing our lpia tree with the latest from the netbook stuff
[17:55] <sconklin> Once that's done, I'll make sure it builds :) and make it available for testing before I bring it back into the distro tree as a branch
[17:56] <pgraner> sconklin: cool
[17:56] <amitk> sconklin: jaunty, hardy _and_ intrepid?
[17:56] <sconklin> hardy only at this point
[17:56] <cking> sconklin: and all the various branches?
[17:56] <sconklin> Once I get a feel for the scope of the divergence I'll address the others
[17:57] <sconklin> Only looking at the oem group trees so far - a lot has to be resolved before we pull it all together
[17:57] <pgraner> Ok we are about out of time so we need to move to the open discussion:
[17:57] <sconklin> This is a major topic for Berlin
[17:57] <pgraner> [TOPIC] Open Discussion
[17:57] <apw> how did the arm porter go
[17:57] <pgraner> Anyone have anything not on the agenda to discuss?
[17:58] <pgraner> apw: I never heard back from elmo, thanks for the reminder
[17:58] <pgraner> Anyone else?
[17:58] <cking> nope
[17:58] <sconklin> nope
[17:59] <pgraner> [TOPIC] Next meeting
[17:59] <pgraner> Next meeting will be same time, same channel.
[17:59] <pgraner> Thanks everyone, we will call it done
[17:59] <pgraner> #endmeeting
[17:59] <lieb> bye
[17:59] <smb_tp> cu
[17:59] <amitk> bye