User1: 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
User2: I don't think those are closely related.  Anyone in https://launchpad.net/~ubuntu-sru/+members can approve an SRU.
User2: And I don't believe the archive-admin portion requires shell access.
User2: How is the verification proceeding?  That's usually the biggest blocker.
User3: I can accept packages into -proposed if ubuntu-sru approves it.  Copying from -proposed to -updates needs shell access AFAIK.
User4: User1 if by 'this week' you mean this week now, then there's no allhands afaik
User4: can i apply for a per-package-upload permission for 'bzr*' (conceptually or literally)
User2: poolie, Yes and Yes.
User2: 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.
User4: :)
User4: i'm drafting it now, then i'll call in my favors
User2: But be aware that bzr* would be expanded at application time: changes over time would require manual action.
User4: i wondered if i had to manually list all the packaged plugins
User4: sure
User2: 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... :)
User4: 'rdepends bzr' is close to it, though not quite all of them are needed
User2: 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.
User2: 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.
User2: 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.
User4: sure, that makes sense
User1: User2 it's been verified for a while now
User2: Hrm.  Needs one of the SRU folk to poke it then.
User4: persia, i drafted https://wiki.ubuntu.com/MartinPool/DeveloperApplication
User4: i'll just see about getting some endorsements or feedback and then propose it
User5: Good morning
User6: that.
User5: cjwatson, slangasek: FYI, I updated "sru-release" to also copy to devel release if the final/-updates versions matches the devel release
User7: Good morning!
User8: good morning
User7: hi geser
User7: tumbleweed, thanks for your work on the sponsoring overview
User7: tumbleweed, I added a few comments
User9: User7 np, yeah I must respond :)
User9: when I get to my desk...
 * dholbach hugs tumbleweed
User7: thanks a lot tumbleweed
User9: :)
User8: Could an ubuntu-devel-announce moderator please let my minutes pass? Thanks.
User5: User8 will look
User5: User8 done
User5: cjwatson, slangasek: I uploaded postgresql-common to hardy/lucid for bug 661061; do you have a minute for a review in the next days?
User10: Launchpad bug 661061 in postgresql-common (Ubuntu Hardy) "pg_createcluster silently deletes existing cluster" [High,Fix committed] https://launchpad.net/bugs/661061
User11: I think the libgpod sru needs copying to natty
User12: heh.. is it bad when a USB HD starts sounding a lot like a 1940's typewriter?
User13: depends ... did you put a sheet of paper in ?
User12: No, but I did copy a bunch of things with icons that look like sheets of paper to it!
User13: aha !
User13: dont forget to also copy some ink tape then ;)
User12: your wisdom will save my USB HD/typewriter ogra.. thank you...
User13: lol
User14: User11 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)
User15: User5 hallo, I'm Kenneth, I'm working with dpm on the regular language pack update specification, do you have a minute?
User16: User14 i'm assuming that you mean banshee?
User5: User15 hello!
User15: hey
User15: do you have time for a few questions?
User16: speaking of which i need people with ipods to test libgpod in -proposed
User14: User16 12:07 <Laney> I think the libgpod sru needs copying to natty
User5: User15 just shoot
User15: great
User16: User14 ah. if you have an iPod could you do the test case?
User15: 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
User15: One thing that I am wondering there
User15: is how much work it involves for you to push a set of newly build language pack to the proposed repository
User15: 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
User15: User5 ^^
User17: hi there
User17: i made recently an update to 10.10 and now gnu-smalltalk is gone breaking things
User17: trying to reinstall gives "missing package" and "gnu-smalltalk being virtual" error
User17: looking at http://packages.ubuntu.com/search?keywords=gnu-smalltalk I noticed gnu-smalltalk is missing "amd64" in maverick
User17: any chance to build this package and making it available?
User5: User15 the human effort to build and upload new langpacks is very low
User5: User15 it's a significant hit on the builder machines
User5: User15 but the primary limitation here is testing
User5: and we don't want to overdo those updates because we can't possibly test every string
User5: but every string change can potentially be a regression
User17: 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
User15: User5 yes ok
User17: seems to affect only "gnu-smalltalk" package but unfortunately that's the one containing the lib to link against
User17: what you think, how long it typically takes for an amd64 package to arrive?
User15: User5 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
User5: User15 we can release them individually
User5: User15 in the previous couple of rounds we collected feedback for some time, and then released the languages we got feedback on
User15: User5 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
User5: User15 right, that's pretty much what happened
User15: User5 ok, great, but then I think the idea of this schedule should work just fine
User15: User5 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
User5: User15 after that we should probalby switch that aronud and only do them on request?
User15: User5 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
User15: yes, that is an options as well
User15: exactly
User15: User5 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
User5: User15 cool, thanks!
User15: User5 thank you
User14: User16 I don't
User14: User16 Laney was asking me a question as an archive admin rather than as somebody who cares particularly about libgpod
User11: User14 I thought it was routine that uploads were copied as they went into -proposed, as a point of procedure
User11: if not, don't worry
User16: User11 ?
User11: what?
User16: nevermind
User18: eheh you scared him off
User13: so the buildds are obviously working
User13: check the logs and fix them ;)
User13: 5 in main so far
User13: 57 in universe
User13: but the majority fails on all arches anyway
User19: 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
User14: User11 currently, we're doing them on the way into -updates, although that procedure is new
User11: ok
User20: cjwatson, seems to not really make sense
User20: you usually want things tested before they go to updates
User20: it seems it would rather make sense to copy them before the testing period to increase the chances to catch an issue
User21: User19 you want #ubuntu-app-devel (cfr topic)
User19: koey, thanks
User14: User20 possibly, yeah, I was just describing current state
User14: personally I find copying from -updates is a no-brainer, copying from -proposed I sometimes have to think about
User20: pitti, ^ didn't you use the pocket copy directly things?
User20: cjwatson, why do you have to thing about? if the version match just pocket copy
User5: User20 I did; it's easier to do it at the time when you move stuff to -updates, though
User5: (which now happens automatically, with this morning's sru-release update)
User20: well we lack the testing on unstable before copy though
User5: otherwise you'd have to go through all of them twice
User20: sru rules used to be "get the fix in unstable before doing the sru"
User5: not sure how many folks test natty at this time, though
User14: still are, we only bend that at the start of release cycles
User20: which we relaxed to "if versions match let's pocket copy when it's accepted"
User5: User20 right, but we can copy them unchanged to natty, so they won't get lost
User14: thus I don't think it really matters because hardly anyone tests the unstable release at the start of cycles
User20: ok, fair enough
User20: it just seems copying before the testing period than after would be no work difference and be better
User5: that said, http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html looks way smaller than I feared :)
User5: User20 I agree; it's just twice the amount of work
User20: pitti, because you need to wait for the binaries to be available to copy?
User5: right
User5: which includes powerpc/armel
User20: alright
User5: and in the past couple of days that would have meant "three days"
User14: right, and if you get that wrong by mistake it's hard to undo :-(
User5: seems the builds calmed down now
User5: User22 is nvidia 173 supposed to work on maverick?
User22: User5 yep
User5: User22 ok, thanks
User22: np
User23: User24 who is responsible for approving blueprints in "other"?
User24: User23 no one that I know of....though I've approved other- submitted by my team
User24: User23 why?
User24: what do you need?
User23: they're just piling up
User24: damn it...I nominate allison :)
User23: https://blueprints.edge.launchpad.net/sprints/uds-n/+settopics
User23: this page is getting huge
User24: User25 ^^^^^
User23: and we barely have anything scheduled because no one is approving specs
User25: fudge
User23: (linaro's bp's are all messed up, I'll fix them though, that one's easy)
User23: pgraner and leann are unavailable so apw's taking care of hardware, multimedia will be fine when asac returns
User23: User25 User24 also, summit now won't schedule things unless they're both approved and named right.
User23: this was the price for automagic colorization and scheduling without having track leads in the admin UI for hours.
User24: User23 by "approved" you mean the check mark by UDS-N, right?
User23: yup
User23: User24 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."
User23: that seems to work
User24: yeah
User23: 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
User24: exactly
User23: and daviey and I can catch the occasional straggler
User26: !
User23: User26 you can still grep the orphans right?
User26: User23 yes
 * ogra_ac wonders if we will have many tracks beyond "other" after all :P
User23: User26 if you want to cron it to mail me the broken tracks that'd be fine
User26: User23 I can do that
User23: User26 not yet please, I need to fix linaro, they've named everything different
User26: User23 currently only - appselection-n-thunderbird-on-ubuntu
User26: gdb-replay
User26: server-natty-lxc-production-ready
User26: ^^ nothing else is showing as trackless / orphane
User26: +d
User23: k
User13: mvo, the number computation for installs in sw-center seems to be slightly wrong ... do you have a bug open for that already ?
User13: (installing the addons fro the TI PPA talks about downloading 80GB ... thats slightly scary)
User27: User13 woah, indeed - I wonder if that is a long long problem on arm or is that on i386?
User13: arm indeed
User13: updates seem to also go into the 700MB area :)
User28: Hmm...is it part of the API guarantee that /usr/share/debconf/confmodule uses fd 3 for communicating with debconf?
User3: dyfet: Would you please merge gcl.  It's blocking other builds.
User29: Hi jcastro, do you have a minute?
User30: 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?
User30: all this renaming is causing havock with any chance of tracking whether ones team has done their 'prints given they keep moving
User31: User30 there are a few people renaming them I think there was an email sent around to explain it
User31: <track>-<team>-<uds>-<title> if I remember right
User30: fagan, yep, they got renamed once and i had to find them, and now they are moving again
User32: User30 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-*".
User32: User30 but I only touched three of em:  the kernel misc blueprint, the bughandling, and stefan's stable testing
User31: that would explain it
User30: ogasawara, heh your fault huh :) i moved the misc one to none- as it doesn't have a session
User31: User30 you could find them in your blueprints list again
User32: User30 I think I'll just stop touching the blueprints all together, I'm confused about them as it is
User30: fagan, yeah thats all very well in theory, but in practice most don't belong to me, they belong to one of 20 people
User31: ah yeah that would be a problem
User30: ogasawara, its a merry nightmare for sure
User30: its ok if they are correctly targetted to natty, but if not they just dissappear
 * fagan is suprised how many blueprints are actually made and never ever looked at
User31: we need some way of expiring really old blueprints too
User33: Hello all
User33: Just referred here from #ubuntu
User33: I seem to have a bug with Chromium and Maverick
User2: sille777, Tell us a bit about it, and maybe we can help, or send you to a better place.
 * fagan has a bit of experience with chromium in maverick
User33: Persia - Chromium will not start... I reinstalled and same thing...I tried to start from command line and ...
User31: User33 use pastebin.ubuntu.com please
User2: No, that's a bug.
User2: Please file a bug with `ubuntu-bug chromium-browser` and follow-up in #ubuntu-bugs.
User31: ah ok
User33: Attempting to load the system libmoon  Segmentation fault (core dumped)
User33: ok
User31: User33 sudo apt-get remove libmoon
User31: that should get it working
User2: fagan, 1) that's a big hammer, and may hide an easily fixable issue, 2) this isn't a support channel.
User31: yeah I know I just thought I should offer up the solution
User2: Yeah, but that's not a solutUser6 it's a workaround, and perhaps not even a good one.
User33: Bug has been reported
User2: 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.
User31: User2 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
User33: Bug# 663007
User33: Thank you for your help persia!
ubuntu-devel
Ubuntu IRC