[00:59] <YokoZar> Are the canonical folk gonna be at an all hands meeting this week?  I'd hate for my "0-day" maverick SRU to take another 2 weeks to go through
[01:03] <persia> I don't think those are closely related.  Anyone in https://launchpad.net/~ubuntu-sru/+members can approve an SRU.
[01:04] <persia> And I don't believe the archive-admin portion requires shell access.
[01:05] <persia> How is the verification proceeding?  That's usually the biggest blocker.
[01:42] <ScottK> I can accept packages into -proposed if ubuntu-sru approves it.  Copying from -proposed to -updates needs shell access AFAIK.
[02:14] <poolie> YokoZar: if by 'this week' you mean this week now, then there's no allhands afaik
[02:15] <poolie> can i apply for a per-package-upload permission for 'bzr*' (conceptually or literally)
[02:16] <persia> poolie, Yes and Yes.
[02:17] <persia> Best to prepare an application, and get support from a few folks before you file.  There's little less embarrassing than having an application fail because everyone thought someone else was going to say something nice about you.
[02:17] <poolie> :)
[02:17] <poolie> i'm drafting it now, then i'll call in my favors
[02:18] <persia> But be aware that bzr* would be expanded at application time: changes over time would require manual action.
[02:18] <poolie> i wondered if i had to manually list all the packaged plugins
[02:18] <poolie> sure
[02:18] <persia> The person implementing it has to manually list all the packaged plugins.  If you want to make the LP API easier before you apply so that this isn't required... :)
[02:19] <poolie> 'rdepends bzr' is close to it, though not quite all of them are needed
[02:21] <persia> I hope not.  There's stuff in that list which I'd have some reservations about granting to someone based on their experience with bzr alone.
[02:21] <persia> Note that successful applications typically have a couple examples of prior uploads (to Ubuntu or Debian) for any of the packages included in the set.
[02:22] <persia> You might get away with significant upstream work in those packages, but it's unlikely that you'd be granted access to something for PPU without some demonstrable prior involvement, given the lack of social groups related to PPUs.
[02:33] <poolie> sure, that makes sense
[03:36] <YokoZar> persia: it's been verified for a while now
[03:38] <persia> Hrm.  Needs one of the SRU folk to poke it then.
[03:53] <poolie> persia, i drafted https://wiki.ubuntu.com/MartinPool/DeveloperApplication
[03:54] <poolie> i'll just see about getting some endorsements or feedback and then propose it
[06:46] <pitti> Good morning
[06:53] <ion> that.
[07:35] <pitti> cjwatson, slangasek: FYI, I updated "sru-release" to also copy to devel release if the final/-updates versions matches the devel release
[08:02] <dholbach> Good morning!
[08:22] <\sh> moin
[08:31] <geser> good morning
[08:33] <dholbach> hi geser
[09:30] <dholbach> tumbleweed, thanks for your work on the sponsoring overview
[09:31] <dholbach> tumbleweed, I added a few comments
[09:32] <tumbleweed> dholbach: np, yeah I must respond :)
[09:33] <tumbleweed> when I get to my desk...
[09:33]  * dholbach hugs tumbleweed
[09:33] <dholbach> thanks a lot tumbleweed
[09:34] <tumbleweed> :)
[10:00] <geser> Could an ubuntu-devel-announce moderator please let my minutes pass? Thanks.
[10:01] <pitti> geser: will look
[10:02] <pitti> geser: done
[10:16] <pitti> cjwatson, slangasek: I uploaded postgresql-common to hardy/lucid for bug 661061; do you have a minute for a review in the next days?
[12:07] <Laney> I think the libgpod sru needs copying to natty
[12:48] <SpamapS> heh.. is it bad when a USB HD starts sounding a lot like a 1940's typewriter?
[12:48] <ogra_ac> depends ... did you put a sheet of paper in ?
[12:50] <SpamapS> No, but I did copy a bunch of things with icons that look like sheets of paper to it!
[12:50] <ogra_ac> aha !
[12:50] <ogra_ac> dont forget to also copy some ink tape then ;)
[12:55] <SpamapS> your wisdom will save my USB HD/typewriter ogra.. thank you...
[12:55] <ogra_ac> lol
[13:28] <cjwatson> Laney: can/should it wait until the SRU is validated and it goes to -updates?  (otherwise, would prefer it to be acked by the uploader, who appears to be hyperair)
[13:30] <TLE> pitti: hallo, I'm Kenneth, I'm working with dpm on the regular language pack update specification, do you have a minute?
[13:35] <hyperair> cjwatson: i'm assuming that you mean banshee?
[13:35] <pitti> TLE: hello!
[13:36] <TLE> hey
[13:36] <TLE> do you have time for a few questions?
[13:37] <hyperair> speaking of which i need people with ipods to test libgpod in -proposed
[13:38] <cjwatson> hyperair: 12:07 <Laney> I think the libgpod sru needs copying to natty
[13:38] <pitti> TLE: just shoot
[13:38] <TLE> great
[13:39] <hyperair> cjwatson: ah. if you have an iPod could you do the test case?
[13:39] <TLE> I'm just gathering information for use during the UDS session, one thing to consider is how many update cycles we want, during first 6 months and possibly after
[13:40] <TLE> One thing that I am wondering there
[13:40] <TLE> is how much work it involves for you to push a set of newly build language pack to the proposed repository
[13:41] <TLE> the reason I'm wondering is, that if it is very easy, then maybe we can affort to offer more update cycles than the teams will in general use
[13:41] <TLE> pitti: ^^
[13:44] <dragonlord> hi there
[13:44] <dragonlord> i made recently an update to 10.10 and now gnu-smalltalk is gone breaking things
[13:44] <dragonlord> trying to reinstall gives "missing package" and "gnu-smalltalk being virtual" error
[13:45] <dragonlord> looking at http://packages.ubuntu.com/search?keywords=gnu-smalltalk I noticed gnu-smalltalk is missing "amd64" in maverick
[13:45] <dragonlord> any chance to build this package and making it available?
[13:48] <pitti> TLE: the human effort to build and upload new langpacks is very low
[13:49] <pitti> TLE: it's a significant hit on the builder machines
[13:49] <pitti> TLE: but the primary limitation here is testing
[13:49] <pitti> and we don't want to overdo those updates because we can't possibly test every string
[13:49] <pitti> but every string change can potentially be a regression
[13:50] <dragonlord> it's just a bit strange since it seems "some" packages in gnu-smalltalk are "all" and include amd64 but not the "gnu-smalltalk" package itself
[13:50] <TLE> pitti: yes ok
[13:51] <dragonlord> seems to affect only "gnu-smalltalk" package but unfortunately that's the one containing the lib to link against
[13:52] <dragonlord> what you think, how long it typically takes for an amd64 package to arrive?
[13:52] <TLE> pitti: I realize that testing is a bottleneck. What I was hoping is that we could change the way we think about the language pack updates a bit. So in stead of thinking, we do 4 language pack updates per cycle, and if only very few teams manage to test and have one released then there are to many and testing is the bottle neck
[13:53] <pitti> TLE: we can release them individually
[13:53] <pitti> TLE: in the previous couple of rounds we collected feedback for some time, and then released the languages we got feedback on
[13:54] <TLE> pitti: then in stead we could say, we give you the _opportunity_ to release a language pack so and so many times, if you don't have fixes important enough to warrant using time on testing then that is fine and we just wont release one for your language for this cycle
[13:54] <pitti> TLE: right, that's pretty much what happened
[13:55] <TLE> pitti: ok, great, but then I think the idea of this schedule should work just fine
[13:57] <TLE> pitti: but that also means that if we want to in principle give language teams the opportunity to release a langauge pack update after the first 6 months, then there are 2 ways that we could do it
[13:57] <pitti> TLE: after that we should probalby switch that aronud and only do them on request?
[13:58] <TLE> pitti: we could just include them in the schedule, and if only very few uses them, then that is ok, but we could also work towards making the late update per request
[13:58] <TLE> yes, that is an options as well
[13:58] <TLE> exactly
[13:59] <TLE> pitti: great, I just needed a little of your input, I'll add some more info to the discussion section of the specification and then we can talk more about specifics at the UDS session
[13:59] <pitti> TLE: cool, thanks!
[14:00] <TLE> pitti: thank you
[14:15] <cjwatson> hyperair: I don't
[14:15] <cjwatson> hyperair: Laney was asking me a question as an archive admin rather than as somebody who cares particularly about libgpod
[14:28] <Laney> cjwatson: I thought it was routine that uploads were copied as they went into -proposed, as a point of procedure
[14:28] <Laney> if not, don't worry
[14:31] <hyperair> Laney: ?
[14:31] <Laney> what?
[14:32] <hyperair> nevermind
[14:32] <BUGabundo> eheh you scared him off
[14:45] <ari-tczew> does armel builds working?
[14:46] <ari-tczew> I've recived a lot of mails about armel FTBFS.
[14:46] <ogra_ac> so the buildds are obviously working
[14:46] <ogra_ac> check the logs and fix them ;)
[14:47] <ari-tczew> ogra_ac: I'm not going to do this - no knowledge, no time.
[14:48]  * ogra_ac only sees very few ftbfs that are actually armel specific on http://qa.ubuntuwire.org/ftbfs/
[14:48] <ogra_ac> 5 in main so far
[14:50] <ogra_ac> 57 in universe
[14:50] <ogra_ac> but the majority fails on all arches anyway
[14:53] <kurrata> hi i made .deb package and made it so icon shows under "start menu" thingy. But it is under section other not games.  http://codepad.org/xIb475Fe .desktop file
[15:02] <cjwatson> Laney: currently, we're doing them on the way into -updates, although that procedure is new
[15:02] <Laney> ok
[15:04] <seb128> cjwatson, seems to not really make sense
[15:04] <seb128> you usually want things tested before they go to updates
[15:05] <seb128> it seems it would rather make sense to copy them before the testing period to increase the chances to catch an issue
[15:07] <Chipzz> kurrata: you want #ubuntu-app-devel (cfr topic)
[15:07] <kurrata> koey, thanks
[15:08] <cjwatson> seb128: possibly, yeah, I was just describing current state
[15:08] <cjwatson> personally I find copying from -updates is a no-brainer, copying from -proposed I sometimes have to think about
[15:08] <seb128> pitti, ^ didn't you use the pocket copy directly things?
[15:08] <seb128> cjwatson, why do you have to thing about? if the version match just pocket copy
[15:09] <pitti> seb128: I did; it's easier to do it at the time when you move stuff to -updates, though
[15:09] <pitti> (which now happens automatically, with this morning's sru-release update)
[15:09] <seb128> well we lack the testing on unstable before copy though
[15:09] <pitti> otherwise you'd have to go through all of them twice
[15:09] <seb128> sru rules used to be "get the fix in unstable before doing the sru"
[15:09] <pitti> not sure how many folks test natty at this time, though
[15:09] <cjwatson> still are, we only bend that at the start of release cycles
[15:09] <seb128> which we relaxed to "if versions match let's pocket copy when it's accepted"
[15:10] <pitti> seb128: right, but we can copy them unchanged to natty, so they won't get lost
[15:10] <cjwatson> thus I don't think it really matters because hardly anyone tests the unstable release at the start of cycles
[15:10] <seb128> ok, fair enough
[15:10] <seb128> it just seems copying before the testing period than after would be no work difference and be better
[15:11] <pitti> that said, http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html looks way smaller than I feared :)
[15:11] <pitti> seb128: I agree; it's just twice the amount of work
[15:12] <seb128> pitti, because you need to wait for the binaries to be available to copy?
[15:12] <pitti> right
[15:12] <pitti> which includes powerpc/armel
[15:13] <seb128> alright
[15:13] <pitti> and in the past couple of days that would have meant "three days"
[15:13] <cjwatson> right, and if you get that wrong by mistake it's hard to undo :-(
[15:13] <pitti> seems the builds calmed down now
[16:03] <pitti> tseliot: is nvidia 173 supposed to work on maverick?
[16:04] <tseliot> pitti: yep
[16:04] <pitti> tseliot: ok, thanks
[16:04] <tseliot> np
[16:22] <jcastro> robbiew: who is responsible for approving blueprints in "other"?
[16:23] <robbiew> jcastro: no one that I know of....though I've approved other- submitted by my team
[16:23] <robbiew> jcastro: why?
[16:23] <robbiew> what do you need?
[16:24] <jcastro> they're just piling up
[16:24] <robbiew> damn it...I nominate allison :)
[16:24] <jcastro> https://blueprints.edge.launchpad.net/sprints/uds-n/+settopics
[16:24] <jcastro> this page is getting huge
[16:24] <robbiew> rickspencer3: ^^^^^
[16:24] <jcastro> and we barely have anything scheduled because no one is approving specs
[16:24] <rickspencer3> fudge
[16:25] <jcastro> (linaro's bp's are all messed up, I'll fix them though, that one's easy)
[16:25] <jcastro> pgraner and leann are unavailable so apw's taking care of hardware, multimedia will be fine when asac returns
[16:32] <jcastro> rickspencer3: robbiew: also, summit now won't schedule things unless they're both approved and named right.
[16:32] <jcastro> this was the price for automagic colorization and scheduling without having track leads in the admin UI for hours.
[16:33] <robbiew> jcastro: by "approved" you mean the check mark by UDS-N, right?
[16:33] <jcastro> yup
[16:34] <jcastro> robbiew: here's what I'm telling people in our track "here's the naming convention, it's on YOU to name it right, if jono doesn't approve or decline in a day or so ping him."
[16:34] <jcastro> that seems to work
[16:35] <robbiew> yeah
[16:35] <jcastro> the people who schedule the sessions should be doublechecking that they hit the schedule, there's no way we can expect a track lead to check all those sessions by hand
[16:35] <robbiew> exactly
[16:35] <jcastro> and daviey and I can catch the occasional straggler
[16:35] <Daviey> !
[16:36] <jcastro> Daviey: you can still grep the orphans right?
[16:36] <Daviey> jcastro: yes
[16:37]  * ogra_ac wonders if we will have many tracks beyond "other" after all :P
[16:37] <jcastro> Daviey: if you want to cron it to mail me the broken tracks that'd be fine
[16:37] <Daviey> jcastro: I can do that
[16:38] <jcastro> Daviey: not yet please, I need to fix linaro, they've named everything different
[16:38] <Daviey> jcastro: currently only - appselection-n-thunderbird-on-ubuntu
[16:38] <Daviey> gdb-replay
[16:38] <Daviey> server-natty-lxc-production-ready
[16:38] <Daviey> ^^ nothing else is showing as trackless / orphane
[16:38] <Daviey> +d
[16:39] <jcastro> k
[17:41] <ogra_ac> mvo, the number computation for installs in sw-center seems to be slightly wrong ... do you have a bug open for that already ?
[17:41] <ogra_ac> (installing the addons fro the TI PPA talks about downloading 80GB ... thats slightly scary)
[17:42] <mvo> ogra_ac: woah, indeed - I wonder if that is a long long problem on arm or is that on i386?
[17:42] <ogra_ac> arm indeed
[17:43] <ogra_ac> updates seem to also go into the 700MB area :)
[18:15] <ebroder> Hmm...is it part of the API guarantee that /usr/share/debconf/confmodule uses fd 3 for communicating with debconf?
[19:52] <ScottK> dyfet: Would you please merge gcl.  It's blocking other builds.
[20:50] <antileet> Hi jcastro, do you have a minute?
[22:30] <apw> jcastro, hey how and who is renaming blueprints?  one of mine just got a mad prefix added ... one that doesn't even need a session ... any idea how i can fix it?
[22:31] <apw> all this renaming is causing havock with any chance of tracking whether ones team has done their 'prints given they keep moving
[22:38] <fagan> apw: there are a few people renaming them I think there was an email sent around to explain it
 if I remember right
[22:41] <apw> fagan, yep, they got renamed once and i had to find them, and now they are moving again
[22:42] <ogasawara> apw: pgraner just mentioned to me that the "other" track had too many blueprints assigned and was breaking the summit system So asked if I could move any "other-kernel-*" named blueprints to "hardware-kernel-*".
[22:42] <ogasawara> apw: but I only touched three of em:  the kernel misc blueprint, the bughandling, and stefan's stable testing
[22:42] <fagan> that would explain it
[22:43] <apw> ogasawara, heh your fault huh :) i moved the misc one to none- as it doesn't have a session
[22:43] <fagan> apw: you could find them in your blueprints list again
[22:43] <ogasawara> apw: I think I'll just stop touching the blueprints all together, I'm confused about them as it is
[22:43] <apw> fagan, yeah thats all very well in theory, but in practice most don't belong to me, they belong to one of 20 people
[22:43] <fagan> ah yeah that would be a problem
[22:43] <apw> ogasawara, its a merry nightmare for sure
[22:44] <apw> its ok if they are correctly targetted to natty, but if not they just dissappear
[22:44]  * fagan is suprised how many blueprints are actually made and never ever looked at 
[22:45] <fagan> we need some way of expiring really old blueprints too
[23:43] <sille777> Hello all
[23:44] <sille777> Just referred here from #ubuntu
[23:44] <sille777> I seem to have a bug with Chromium and Maverick
[23:46] <persia> sille777, Tell us a bit about it, and maybe we can help, or send you to a better place.
[23:47]  * fagan has a bit of experience with chromium in maverick 
[23:48] <sille777> Persia - Chromium will not start... I reinstalled and same thing...I tried to start from command line and ...
[23:48] <fagan> sille777: use pastebin.ubuntu.com please
[23:48] <persia> No, that's a bug.
[23:49] <persia> Please file a bug with `ubuntu-bug chromium-browser` and follow-up in #ubuntu-bugs.
[23:49] <fagan> ah ok
[23:49] <sille777>  Attempting to load the system libmoon  Segmentation fault (core dumped)
[23:49] <sille777> ok
[23:51] <fagan> sille777: sudo apt-get remove libmoon
[23:51] <fagan> that should get it working
[23:51] <persia> fagan, 1) that's a big hammer, and may hide an easily fixable issue, 2) this isn't a support channel.
[23:52] <fagan> yeah I know I just thought I should offer up the solution
[23:54] <persia> Yeah, but that's not a solution: it's a workaround, and perhaps not even a good one.
[23:54] <sille777> Bug has been reported
[23:55] <persia> sille777, Thanks.  Please follow-up on #ubuntu-bugs, and I'm fairly sure that folk there can help you find the root of the problem, and a solution or at least a good workaround.
[23:55] <fagan> persia: Well I had a few issues with moonlight in the repo so I used to grab it from the website instead because it was up to date
[23:55] <sille777> Bug# 663007
[23:55] <sille777> Thank you for your help persia!