[10:08] <acheronUK> is there an issue with the ppa publisher? seems to be taking extra long the last day or 2?
[11:42] <cjwatson> acheronUK: There was a large uncoordinated test rebuild performed in a PPA rather than using the usual dedicated arrangements for such things, and the system has been having some trouble keeping up as a result.
[11:50] <acheronUK> cjwatson: that would do it if the effects linger. thanks
[16:23] <CarlFK> not sure who's problem this is... I'll go log an issue if someone will tell me where:
[16:24] <CarlFK> https://paste.ubuntu.com/24738955/  click "Download as text"  https://paste.ubuntu.com/24738955/plain/
[16:24] <CarlFK> "Plain form not available for deep linking."
[16:27] <cjwatson> It has nothing to do with Launchpad.  #canonical-sysadmin or<EMAIL_ADDRESS>[16:32] <CarlFK> thanks - I remember someone in IRC explaining why I needed to log in. and this is irc.. soo... ;)
[16:44] <bdmurray> cjwatson: I just reported bug 1695031 regarding a timeout I'm seeing regularly. I may have mentioned the same timeout yesterday.
[17:04] <cjwatson> ack, thanks
[17:16] <sergio-br2> hi
[17:16] <sergio-br2> how can I specify a commit in the git recipe?
[17:16] <sergio-br2> I want to use a specific commit to build a package
[17:17] <sergio-br2> hey cjwatson
[17:20] <cjwatson> doesn't the documentation cover that?
[17:21] <cjwatson> https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Specifying_revisions
[17:22] <sergio-br2> for bzr you use revno:1234 for example, for git I'm not sure what to do
[17:22] <cjwatson> "For git, a revision specifier may be anything that you could pass to git rev-parse in a clone of the given repository."
[17:22] <cjwatson> no need for a revno: prefix or anything
[17:23] <sergio-br2> that's greek for me
[17:23] <cjwatson> man gitrevisions
[17:24] <cjwatson> you can just put a SHA-1 there for instance
[17:24] <sergio-br2> something like
[17:25] <sergio-br2> lp:~libretro/libretro/+git/RetroArch master f14473f
[17:25] <sergio-br2> or the full hash?
[17:25] <cjwatson> drop the "master" there.  you either mean master (which means the tip of the master branch) or you mean a specific commit, not both
[17:25] <sergio-br2> humm
[17:26] <cjwatson> you can truncate the hash if you like
[17:26] <rbasak> Repeatedly getting OOPS-5b689b57381685b4549dbc5f55d66212 for a few minutes trying to file a bug against ubuntu pygit2. Known issue?
[17:26] <rbasak> IllegalTarget: Package pygit2 not published in Ubuntu
[17:26] <cjwatson> it's an ungraceful failure mode, but it's true.  you mean python-pygit2 I think
[17:26] <rbasak> Thanks
[17:27] <cjwatson> I think if you use the JS picker it will present you with the source package name as an option if you search for the binary package name
[17:28] <rbasak> Filed now, thank you.
[17:28] <cjwatson> (this is a slight regression as a result of the work done in http://blog.launchpad.net/beta/beta-test-new-package-picker)
[17:28] <rbasak> Would you like a bug on the ungracefulness?
[17:28] <cjwatson> I think there's one already, but let me check
[17:28] <rbasak> BTW, you might be interested in the bug too - pygit2 giving bad results, resulting in a corrupted import for us: bug 1695049
[17:29] <rbasak> nacc will try to follow up upstream next week.
[17:29] <rbasak> (we're working around for now)
[17:30] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/1635118
[17:30] <rbasak> Thanks
[17:32] <cjwatson> I think we normally diff by full commit IDs, but would have to check
[17:40] <sergio-br2> it worked cjwatson, thanks
[17:40] <cjwatson> good
[20:38] <nacc> cjwatson: is LP: #1669712 showing the nominations for series where it has already been opened a bug? If i click on approve/decline and approve it, I get an oops (OOPS-c4f79485d4d8b208eff2688148cdca15)
[21:24] <cjwatson> nacc: that's certainly a bug-worthy head-scratcher
[21:24] <nacc> cjwatson: ok, will file -- against launchpad itself, i assume?
[21:31] <cjwatson> yeah
[21:34] <nacc> cjwatson: done, LP: #1695097
[21:37] <cjwatson> ta


[11:01] <amanulla> hii every one
[11:01] <persia> Hello amanulla
[11:01] <amanulla> hello
[11:02] <amanulla> i want to install and run java on ubuntu
[11:02] <amanulla> but im new to ubuntu
[11:02] <amanulla> how can i?
[11:04] <amanulla> HELLO ARE YOU THERE BUSY
[11:08] <persia> Just busy and distracted.  Sorry.
[11:08] <persia> Which version of Ubuntu do you have installed?
[11:08] <amanulla> 8.04
[11:08] <persia> What do you want to do with Ubuntu?
[11:08] <amanulla> run java
[11:08] <persia> What do you want to do with Java.
[11:08] <amanulla> html
[11:09] <persia> So, run tomcat or something?
[11:09] <amanulla> yes
[11:09] <amanulla> im running tomcat on xp
[11:09] <persia> OK. Does apt-get install tomcat5.5 work for you?
[11:10] <amanulla> but i dont know how to find any
[11:10] <amanulla> netbeans,eclipse.........
[11:10] <amanulla> any ides
[11:10] <amanulla> here
[11:10] <amanulla> i just tried with this
[11:10] <amanulla> sudo apt-get install ecclipse
[11:10] <amanulla> in terminal
[11:10] <amanulla> but no use
[11:10] <amanulla> ok i will try now
[11:11] <amanulla> some error
[11:11] <amanulla> E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
[11:11] <persia> apt-get install netbeans should work.  If it doesn't, I'll be personally annoyed.
[11:11] <persia> Oh, something is broken in your apt-cache.  Run the suggested command.
[11:11] <amanulla> oh same error
[11:12] <amanulla> what can i do
[11:12] <persia> What error do you get from dpkg --configure -a ?
[11:13] <amanulla> E: Could not open lock file /var/lib/dpkg/lock - open (13 Permission denied)
[11:13] <amanulla> E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
[11:13] <persia> OK.  sudo dpkg --configure -a
[11:14] <amanulla> i got some screen
[11:14] <amanulla> http://paste.ubuntu.com/53405/
[11:14] <amanulla> like above
[11:14] <persia> OK.  Answer the question.
[11:15] <amanulla> which one to select
[11:15] <amanulla>  install the package maintainer's version                      │
[11:15] <amanulla>   │           keep the local version currently installed                    │
[11:15] <amanulla>   │           show the differences between the versions                     │
[11:15] <amanulla>   │           show a side-by-side difference between the versions           │
[11:15] <amanulla>   │           start a new shell to examine the situation
[11:15] <persia> Dunno.  I usually install the package maintainer's version, but if you made changes, you might want one of the other choices.
[11:29] <amanulla> thank u im now installing tomcat
[11:30] <amanulla> but i dont know how to open it afetr installation can u
[11:32] <persia> No idea.  I know *lots* of work went into tomcat recently, but I haven't used it since 2001, so anything I might be able to remember is surely out of date.
[11:32] <persia> There should be some documentation in /usr/share/doc/tomcat5.5/ which might help.
[11:32] <amanulla> ok thank you
[11:33] <amanulla> for spending your time to help me
[11:33] <amanulla> have a nice day
[11:33] <amanulla> take care bye
[11:33] <persia> You too.
[13:23] <cfm> Hi, installing Java on 8.04 LTS Server.  Picked openjdk-6-jre-headless, but it wants to install all kind of extras including X11 and GTK.
[13:23] <cfm> Any way to avoid all this?
[13:32] <cfm> Ah, found sun-java5-jre package, which looks a lot nicer!  Any reason this package wasn't suggested by the system when I ran "java"?
[14:12] <persia> cfm: The recommendation is for openjdk because we can fix bugs.  the sun binary blob has some bugs that cannot be fixed.  With luck, you won't hit them.
[14:13] <persia> For Intrepid we've spent a lot of time trying to make -headless more -headless, but may not have succeeded entirely.  For 8.04, it's unfortunately bloated.  Sorry about that.
[14:19] <persia> slytherin: I didn't give back jhope (or whatever).  Just build-depending on sun-java5-jdk isn't enough, because the build-dependency on ant pulls in headless openjdk.  You'll need to find some way to advise the build which JDK to use.
[14:20] <slytherin> persia: Got it. Will do over weekend.
[14:21] <persia> slytherin: Great.  Poke me when you get it, and I'll try it, as I definitely have some time to focus on Java this weekend.
[14:23]  * robilad apologizes for missing the last meeting, on the road since yesterday until tomorrow
[14:24] <persia> robilad: No worries.  This close to release, there's not much we can do other than maybe get some plans together for jaunty, and publish some specs for discussion/approval.
[14:24] <persia> Unless you have some RC issue you want to raise?
[14:25] <robilad> nope
[14:26] <robilad> I'm loving intrepid so far ;)
[14:26] <persia> It's a bit of an improvement on the Java front :)
[14:27] <persia> For the next meeting, I think we should try to get some specs together for the server stuff.
[14:27] <persia> I know Koon pretty much finished the maven spec, and is seeking an approver.
[14:27] <persia> Is there anything else we want to do other then get more stuff free, and maven?  Surely something glassfish related.
[14:36] <robilad> good question - i think the next important bit would be the osgi support (felix)
[14:36] <persia> Right.  We'll need a bit of a roadmap to give to developers at UDS (in December), including a list of targets, and some specs to get completed.
[14:37] <persia> We'll want to have those drafted in the next 6 weeks or so, so if there's nothing RC outstanding for you, that's probably the best target.
[14:59] <robilad> ok, thanks
[15:01] <cfm> persia: Ah, that makes sense, thanks!  I'm going with sun for now purely because of those dependencies.
[15:02] <persia> cfm: Makes sense.  Depending on your use, you may be happy with the intrepid upgrade in another month or so.


[15:31] <Prf_Jakob> Just checking, none of you guys who have help me/VMware in the past are in the London office?
[15:39] <mlankhorst> no
[15:49] <Prf_Jakob> shame, no beer for you :) well some other time
[18:30] <gQuigs> I'm trying to figure out if this is a packaging bug or not in xorg-edgers.. I'm on 14.04 w/ edgers and a geforce 750 ti
[18:30] <gQuigs> I can't get BOINC to detect CUDA
[18:30] <gQuigs> It detected perfectly fine when I installed the nvidia drivers manaully
[19:20] <gQuigs> well... reported as: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1320990  still not sure how to figure out where it's breaking.. happy to debug more


[01:43] <jose> jcastro: what? wiki? what's going on with it? can I help?
[07:21] <dholbach> good morning
[07:40] <dpm> morning all
[07:45] <dholbach> salut davidcalle, hey dpm
[07:46] <davidcalle> dholbach, hey hey :)
[07:48] <davidcalle> dholbach, staging deploy update: we still need an external intervention to do it, to upload the project tarball to http://archive.admin.canonical.com/other/devportal/, then it's picked up by juju from this location.
[07:48] <dpm> hey dholbach
[07:50] <davidcalle> dholbach, on the bright side, the new tarball is being uploaded there right now, and as soon as it's in I should be able to trigger a deploy that's not outdated or broken
[07:51] <dholbach> NICE!
[07:51] <dholbach> once it's deployed on staging that could serve as a blueprint for a production deployment or will that be more complicated?
[07:56] <davidcalle> dholbach, I honestly don't know, but from what I've gathered from the spec, it should be the same but on a prod environment
[07:57] <davidcalle> dholbach, when Mike or Caio is back, I'll talk to them about updathing the spec to have it pull the tarball directly from launchpad, so we could skip the step I just went through
[07:57] <dholbach> davidcalle, I guess they'll just need a recent db dump and we'll have some downtime, but that should be it, right?
[07:58]  * dholbach might be a bit overly optimistic :-)
[07:58] <davidcalle> dholbach, I forgot about the pesky db, that's right, there must be another step for prod :-)
[07:59] <davidcalle> dholbach, let's have all the cms content on launchpad, now that we have tools to pull it into pages :D
[08:00] <davidcalle> (I actually would love that, to some extent)
[08:02] <dholbach> same here :)
[08:03] <dholbach> let's iron out the bugs along the way and then see what we can do :)
[08:27] <czajkowski> aloha
[11:17]  * dholbach relocates to the office, brb
[15:16] <jose> dpm: ping
[15:32] <dpm> hola jose
[15:32] <jose> dpm: hey, llegaste a revisar el correo que envié?
[15:34] <dpm> jose, no aun no, lo siento. Te lo miro ahora
[15:34] <jose> genial
[15:39] <dpm> jose, let me check with Michelle first to see if there is the option to return to the fund, she appears to be out atm. I'll come back to you by tomorrow, as IIRC both you and I will be off on Monday :)
[15:40] <jose> yep!
[17:20] <dholbach> all right my friends - have a great rest of your day - see you tomorrowQ
[17:20] <dholbach> all right my friends - have a great rest of your day - see you tomorrow!


[01:12] <cprofitt> AlanBell: are you around?
[06:59] <AlanBell> o/
[12:32] <mhall119> daker: try naming the function get_urls, instead of urls
[12:46] <daker> mhall119, oh i see
[12:46] <daker> i'll try it
[13:04] <daker> mhall119, it does not work http://pastebin.com/Ar7LBhdN
[13:06] <mhall119> okay,  I'll have to read the Admin documentation then
[13:10] <mhall119> why are you making 2 calls to super.get_urls?
[13:12] <mhall119> also, I don't think you need to specify the urls property, it looks like the ModelAdmin already has that
[13:12] <mhall119> but that shouldn't cause problems either
[13:13] <mhall119> oh wait a second
[13:13] <mhall119> I think I see the problem
[13:14] <mhall119> you're passing self.list_pages as the view function
[13:14] <mhall119> but Django is going to treat it as a regular function, not an instance method
[13:19] <mhall119> daker: you just want to over-write the list view?
[13:19] <daker> mhall119, yes
[13:20] <mhall119> then just have your model implement changelist_view
[13:20] <mhall119> in that call super.changelist_view
[13:20] <mhall119> then you shouldn't have to mess with urls at all
[13:21] <daker> i see i'll try
[13:23] <daker> mhall119, if i add a __call__ func it works http://pastebin.com/F8eJAYnF
[13:32] <daker> Woo got it http://pastebin.com/1LmjFpmG
[13:58] <mhall119> well, yeah I guess that would work too
[13:59] <daker> ツ
[13:59] <daker> thanks for your time
[14:12] <locodir-user> hello
[15:20] <nigelb> Hey folks :)
[15:23] <mhall119> morning
[15:26] <nigelb> mhall119: Now I understand why I didn't get what you meant last night --> sleep deprivation
[15:31] <daker> mhall119, do you know any working threaded comment system in django ?
[15:52] <mhall119> nigelb: yeah, sleep deprivation makes coding...interesting
[15:52] <mhall119> it also makes for amusing comments
[15:52] <mhall119> daker: I don't know about threaded, but there's a default django comments system isn't there?
[15:55] <nigelb> mhall119: ;)
[16:39] <TrickyJ> Good morning friends :)
[19:49] <Ronnie> about bug https://bugs.launchpad.net/loco-directory/+bug/686268 is this about the comments added to agenda items>
[19:50] <ubot4> Launchpad bug 686268 in loco-directory "Add the ability to add agenda items (affects: 1) (heat: 5)" [Wishlist,In progress]
[19:52] <Ronnie> daker, cjohnston, mhall119: ^
[19:52] <Ronnie> its not clear what need to be fixed in order to commit this bug
[19:53] <daker> AFAIK the backend is already implemented
[19:54] <mhall119> Ronnie: right now there is no interface for adding agenda items
[19:54] <mhall119> that's what the bug is for
[19:55] <Ronnie> mhall119: agenda != meeting/event ?
[19:55] <mhall119> there is (ugly) code for displaying them
[19:55] <mhall119> Ronnie: a meeting has multiple agenda items
[19:55] <Ronnie> aha
[19:56] <mhall119> agenda items can be nested too, so each meeting has a tree of agenda items
[21:03] <AlanBell> o/ Daviey


[00:21]  * infinity feeds the poor, lonely buildds.
[00:33] <infinity> cjwatson: Argh.
[00:34] <infinity> cjwatson: Did you overzealously remove linux from -proposed?
[00:35] <infinity> cjwatson: Yup, you sure did. :/
[00:35] <infinity> wgrant: So, silly copying tricks.  Is there a clever way to get https://launchpad.net/ubuntu/+source/linux/3.5.0-17.27/+publishinghistory undeleted?
[00:36] <infinity> wgrant: With bonus points for having it back before the builds complete? ;)
[00:36] <wgrant> infinity: If the source is deleted, then yeah
[00:36] <infinity> wgrant: It is.
[00:36] <wgrant> Use copy-package's version argument
[00:36] <wgrant> The API doesn't require the package to not be deleted
[00:37] <wgrant> It's possible that your copy-package script does, but you can just hack that check out if it whinges
[00:37] <wgrant> copy-package -b -e 3.5.0-17.27 --to-suite=quantal-proposed linux
[00:37] <wgrant> I think
[00:38] <infinity> I had a -s quantal-proposed in mine too..
[00:38]  * infinity knocks that out.
[00:38] <wgrant> That's probably just used to find the origin version
[00:39] <wgrant> So it should be irrelevant when -e is specified
[00:39] <wgrant> But checking
[00:41]  * infinity comments some bits out.
[00:41] <wgrant> Ah, so find_latest_published_source requires -s and that the package be currently published
[00:42] <infinity> Oh, hrm.  Yeah.
[00:42] <wgrant> I'd just eliminate that and use options.version directly in copy_packages
[00:42] <wgrant> Remove the find_latest_published_source call
[00:42] <infinity> And more to the point, I can't just comment those bits out, cause it's used for versions too.
[00:42] <wgrant>                     source_name=package, version=source.source_package_version,
[00:42] <wgrant> version=options.version
[00:42] <wgrant> done
[00:42] <infinity> Yeah, just did that. :P
[00:43] <infinity> Alright, that may or may not have just done... Something.
[00:44] <wgrant> infinity, ScottK: BTW, the copier diff bug that broke both your binary revival attempts was fixed yesterday, will be on production next week
[00:44] <wgrant> infinity: You copied it twice
[00:44] <wgrant> infinity: It's in Unapproved now
[00:44] <infinity> Twice?  Go me.
[00:44] <infinity> wgrant: The billion dollar question is what this will do to the builds.
[00:45] <wgrant> infinity: If you copied with -b, nothing
[00:45] <wgrant> They should continue and then be accepted fine
[00:45] <wgrant> No new ones will be created
[00:45] <infinity> wgrant: Sure, and the two that already failed due to being for superseded source?
[00:45] <infinity> wgrant: Need SQL intervention to kick them back to needs-build? :/
[00:46] <wgrant> 2012-10-05 00:45:18 INFO    Job:
[00:46] <wgrant> <PlainPackageCopyJob to copy package linux from ubuntu/primary to ubuntu/primary, PROPOSED pocket, in ubuntu quantal, including binaries>
[00:46] <wgrant> raised CannotCopy:
[00:46] <wgrant> linux 3.5.0-17.27 in quantal (source has no binaries to be copied)
[00:46] <wgrant> It was copied before there were any binaries at all?
[00:46] <infinity> Just builds, no binaries.
[00:46] <infinity> It was deleted before any builds completed.
[00:46] <infinity> https://launchpad.net/ubuntu/+source/linux/3.5.0-17.27
[00:46] <wgrant> Ah, OK
[00:46] <wgrant> Trying to load, LP not being forgiving
[00:46] <wgrant> But copy without -b
[00:47] <wgrant> Since there are no binaries in either suite, a source-only copy will work fine
[00:47] <wgrant> But you are correct that the amd64/i386 builds will need manual recovery
[00:47] <infinity> Bugger.
[00:47] <wgrant> For added fun, we have no ops
[00:47] <infinity> We have GSAs.
[00:48] <wgrant> We do
[00:48] <infinity> If you know the magic required.
[00:48] <wgrant> And I guess we have bigjools to approve
[00:48] <wgrant> But we have no webops or lifeless
[00:48] <wgrant> So, copy without -b
[00:48] <wgrant> To get the soruce back and salvage the other three builds
[00:48] <infinity> I haven't surgerised that table in years.
[00:48] <wgrant> It's a really easy query. I'll just set them to failed, then retry.
[00:48] <infinity> Check.
[00:48] <infinity> New copy accepted.
[00:49] <wgrant> No need to mess with the buildqueue etc.
[00:49] <wgrant> linux 3.5.0-17.27 in quantal (same version already building in the destination archive for Quantal)
[00:49] <wgrant> blaaargh
[00:49] <wgrant> Yeah, this isn't going to work :/
[00:49] <wgrant> If there was a single binary in the initial copy it would have been fine.
[00:49] <infinity> Oh, bah.
[00:49] <wgrant> But since it was copied with nothing, we're stuck
[00:50] <infinity> Hrm.  What if I just copy it to release?  Will that suffer the same issue?
[00:50] <infinity> It's not an ABI change, there's no real reason it needs to be in proposed.
[00:50] <wgrant> Copy what to release?
[00:50] <infinity> The source.
[00:50] <wgrant> Oh, it's not already there?
[00:50] <infinity> Or will it still have a sad about it being currently building?
[00:50] <infinity> No, it's in proposed.
[00:50] <infinity> Well, it WAS in proposed, and that's where I was copying it to.
[00:51] <wgrant> I assumed it was deleted from proposed because it was copied to release
[00:51] <wgrant> But I see now it's entirely gone.
[00:51] <wgrant> The release copy will fail the same way
[00:51] <infinity> No, it was deleted from proposed because the previous version was moved to release, and Colin wasn't paying attention. :P
[00:51] <wgrant> Heh
[00:51] <infinity> So, if all the builds were to spontaenously fail, would that help us any?
[00:52] <infinity> Or is "building in destination" not actually what it says?
[00:53] <wgrant> A source-only copy will work if the builds are all failed
[00:53] <infinity> That, I can do.
[00:53] <wgrant> So if you want to kill those three, you can copy it back into proposed source-only, retry the builds, and then we can fix the x86 stuff
[00:53] <wgrant> They need to actually be failed, though, not just not building.
[00:54] <infinity> wgrant: They'll be failed shortly.  If DarrenS loves me.
[00:57] <wgrant> Although it's not directly relevant here, builds will complete and upload successfully as long as the source is published somewhere in the archive. The suite doesn't necessarily need to match
[00:57] <wgrant> And you can then use the binary revival trick (once the bugfix is deployed) to copy them into the right pocket.
[00:58] <infinity> wgrant: And that would be more interesting if I could have rescued the source in the first place. ;)
[00:58] <wgrant> Yeah
[00:59] <infinity> wgrant: Oh, and it's going to have to be SQL surgery on i386, amd64, and powerpc.  The latter finished while we were talking.
[01:00] <wgrant> Yeah, so I saw
[01:00] <infinity> And armel and armhf now dead.
[01:00] <infinity> Well, armhf is in the death throes...
[01:00] <wgrant> armhf still seems alive
[01:00]  * infinity waits.
[01:00] <wgrant> Yeah
[01:00] <wgrant> Once it's failed properly, retry the source-only copy
[01:01]  * wgrant prepares SQL
[01:01] <infinity> There.
[01:02] <wgrant> BuildStatus.SUPERSEDED should possibly be retriable nowadays, since it is possible to unsupersede things
[01:02] <wgrant> But it's historically been our go-to status for making builds unretriable.
[01:03]  * infinity accepts and crosses his fingers.
[01:04] <wgrant> 2012-10-05 01:03:17 INFO    Ran 1 PlainPackageCopyJob jobs.
[01:04] <wgrant> It worked.
[01:05] <infinity> It did indeed.  And beat the publisher by a matter of seconds.
[01:05]  * infinity fires up the ARM builds again.
[01:08] <infinity> wgrant: Right, all looks snazzy.  Whenever you can make the SQL mojo go, that'd be nice.  You have a couple of hours of slack time, thanks to those builds being wildly faster than armhf. :P
[01:08] <wgrant> Heh
[02:26] <infinity> ^-- lolwut?
[02:27] <infinity> Oh, that's the amd64 build, queuebot's confused.
[03:18] <ScottK> wgrant: Thanks.  Both for the quick turn around and the update.
[03:59] <micahg> Bug #1057518 has UI changes, could someone tell me if a UIFe is needed?
[03:59] <ubot2> Launchpad bug 1057518 in onboard "debian.tar.gz supplied: New upstream release 0.98.1 available" [Undecided,New] https://launchpad.net/bugs/1057518
[04:17] <micahg> is 'Added NVIDIA driver detection' to checkbox called a feature?
[04:18]  * micahg rings the bell on the counter to see if anyone is around :)
[04:18] <RAOF> That sounds like a feature to me, but I'm not exactly on the release team.
[04:20] <micahg> right, which is why I'm asking :)
[04:28] <ScottK> micahg: Yes and yes.
[04:28] <micahg> ScottK: thanks for the confirmation :)
[04:33] <infinity> It's a feature for sure, but depending on the size of the code, and how obviously unbroken it seems, it may be FFeable.
[04:36] <micahg> looks FFeable, just wasn't sure if that qualified as a feature for checkbox
[04:37] <infinity> Pretty much any new code that isn't directly fixing a bug that could only be fixed by refactoring a bit is a "feature", to be fair.
[04:37] <infinity> That was a convoluted sentence.
[04:37] <micahg> fair enough :)
[04:45] <ScottK> infinity: I'm working on some no change rebuilds so we can get the binaries that got missed when Riddell prematurely copied from proposed (you can see the first one ^^^).  I'd appreciate if you could push them through.
[04:46] <infinity> ScottK: I'm working on wandering away from my computer and killing brain cells with gin, but I'll poke at things randomly when I come back.
[04:46] <ScottK> Thanks, but you know what gin is made from, right?
[04:46] <infinity> ScottK: Love.
[04:46] <ScottK> Juniper berries.
[04:47] <infinity> ScottK: And love.
[04:47] <ScottK> And do you know what juniper berries are?
[04:47] <ScottK> They are poisonous.
[04:47] <ScottK> Just saying.
[04:47] <infinity> So are tomatoes, in large enough quantity, doesn't stop people from eating 'em.
[04:49] <ScottK> Shortly after one of my brothers graduated from high school he got sick enough from gin that for years afterwards all you had to do way say the word and he would turn pale.
[04:49] <ScottK> ;-)
[04:56] <micahg> scottk: did you want to review kaffeine in precise-proposed? (when you're done with your no change rebuilds)?
[04:57] <ScottK> Depends on if I run out of steam or not.
[05:16] <micahg> hrm, i'm guessing I need a UIFe to upload Bug #621204  as well
[05:16] <ubot2> Launchpad bug 621204 in im-switch "Typo in error string" [Undecided,In progress] https://launchpad.net/bugs/621204
[05:29] <ScottK> micahg: Done.
[05:30] <ScottK> BTW, that's it for the KDE rebuilds for missing binaries.  Maybe if the gin gets infinity, Riddell will tend to them once he wakes up.
[05:39] <micahg> scottk: thanks
[06:39] <cjwatson> infinity: argh sorry
[06:42] <cjwatson> infinity: we really should make pending-sru's recommendation be to remove by version
[07:48] <apw> cjwatson, infinity, linux-signed above is the packaging half of the signing changes; if you would review w
[07:48] <apw> (so much for waiting till it appeared)
[07:52] <infinity> cjwatson: Did you want to review the linux/amd64 in unapproved, since you have a vague idea of WTF should be in the tarball? ;)
[07:53] <cjwatson> I suppose I'd better
[07:53] <cjwatson> " Archive admins should review the corresponding source upload for correctness prior to approving these uploads"
[07:53] <cjwatson> BRB in a week
[07:54] <infinity> I reviewed the source and it seemed vaguely sane...
[07:54] <infinity> But, I'm not as well-versed in how this is all meant to work.
[07:55]  * apw notes there is at least the correct extra binary in the upload
[07:55] <apw> (in the linux/amd64 binary)
[08:15] <Laney> cjwatson: -e default> yes please. I don't think I've wanted the prefix/substring/whatever behaviour yet.
[08:16] <infinity> I use it for langpacks.
[08:16] <infinity> But that's a perfectly reasonable sort of use-case for pattern-matching being an argument, not the inverse.
[08:16] <Laney> Yep.
[08:29] <cjwatson> linux/amd64 accepted now.  Distracted by an argument, sorry.
[08:29] <cjwatson> Wait, why didn't that work
[08:30] <cjwatson> Sigh.  Accepted by id, can't be bothered to debug why by name didn't work
[09:04] <Riddell> ScottK: I'm confused, https://launchpad.net/ubuntu/+source/kde-baseapps/4:4.9.2-0ubuntu4 exists but is not on https://launchpad.net/ubuntu/+source/kde-baseapps
[09:04] <Riddell> oh wait, it just appeared
[09:04] <Riddell> good I guess that's sorted, thanks much for doing that
[09:09] <cjwatson> What happened with those KDE builds?  Were they copied in advance of pending-sru saying that all the builds were done?
[09:10] <cjwatson> (And could somebody have a look through my 30 no-change rebuilds in the queue?)
[09:10] <Riddell> cjwatson: yes I copied them early which apparantly confuses launchpad
[09:11] <Laney> doing
[09:11] <Laney> I added a --names-only to queue locally so that I can loop over queuediff
[09:11] <cjwatson> Riddell: Yeah, please don't do that, that's why we have pending-sru list the build states
[09:12] <Riddell> cjwatson: where is pending-sru?
[09:12] <cjwatson> http://people.canonical.com/~ubuntu-archive/pending-sru.html
[09:12] <cjwatson> section near the bottom for quantal
[09:21] <Laney> does queuediff cache the fact that there's no diff available?
[09:22] <cjwatson> I think it tends to run into proxy trouble a good bit
[11:10] <ScottK> Found one more KDE package needs rebuilding.
[11:11] <ScottK> Riddell: kdepim-runtime should appear forthwith.
[11:46] <ScottK> Found another one.
[11:46] <ScottK> smokekde should be along in a moment.
[11:50] <Laney> What's the barrier for desktop interface freeze?
[11:50] <Laney> https://wiki.ubuntu.com/DesktopInfrastructureFreeze "no further fixes"
[11:50] <cjwatson> s/interface/infrastructure/
[11:50] <Laney> yeah
[11:50] <cjwatson> IMO anything that doesn't affect the users of that infrastructure shouldn't count: e.g. FTBFS fixes
[11:51] <cjwatson> I mean I would see that as an obvious case for an exception
[11:51] <Laney> so I have a fix for a crash in a library which occurs on non-default setups
[11:51] <Laney> can I upload that, for example?
[11:51] <ScottK> Where did that come from?
[11:51] <Laney> the fix?
[11:51] <ScottK> The freeze
[11:52] <Laney> oh, I'm not really sure about it
[11:52] <cjwatson> I lose track.
[11:52] <ScottK> That doesn't even make sense.
[11:52] <cjwatson> Laney: I would upload it for review if I were you.
[11:53] <Laney> I feel like I should understand it so that I can review stuff too
[11:53] <ScottK> I've no idea what the bounds of desktop infrastructure are either.
[11:53] <ScottK> Laney: Don't worry, you're not the only one.
[11:54] <cjwatson> It feels like "hey can we not have lots of unity churn after here"
[11:54] <cjwatson> But it's not well-phrased.
[11:55] <ScottK> We already have a freeze that's supposed to cover that.
[11:55] <ScottK> Feature freeze.
[12:32] <phillw> cjwatson: have you had any feed back from kernel / X-org team re: PPC?
[12:43] <cjwatson> phillw: No; you'll need to chase them if you want an answer, as I absolutely don't have time
[12:45] <phillw> cjwatson: Thanks, I'll go in to full nagging mode :) If that fails, would you allow the change? (It would be, as you state, a 'bodge job' instead of a fix)
[12:51] <cjwatson> phillw: No, I want an ack from one of those teams one way or the other telling me what to do
[12:51] <cjwatson> I'm not going to take responsibility for changing those boot parameters without that, given that I don't really understand them
[12:52] <cjwatson> So I want at least *one* of our relevant developers to look it over and tell me what they think, even if they don't fix the underlying bug(s)
[12:53] <cjwatson> Without that I'm afraid I'm going to leave it as it is, on the basis that currently I'm hearing from people who are broken by the current setting, but for all I know some different group of people might be broken by the change
[12:53] <phillw> cjwatson: and we both know that one will blame the other...
[12:53] <cjwatson> (And obviously I wouldn't hear from the latter until after changing things)
[12:56] <phillw> cjwatson: shame they were not on the 24 hour marathon. Would have been a really good time to bash heads together.
[12:57] <cjwatson> What, when people are low on sleep?  Doesn't seem like a good time to me ...
[12:57] <phillw> cjwatson: I got in early :)
[12:57] <cjwatson> I don't want a coerced or thoughtless answer; I want an actual one
[12:59] <phillw> cjwatson: so do I... So, why do -kernel and -xorg keep kicking the critical bugs into the 'long grass'?
[12:59] <phillw> cjwatson:
[13:00] <phillw> cjwatson: A3 worked, these bugs are 100% regression issues.
[13:00] <cjwatson> I expect they're upstream regressions that have not been reported coherently to the right people
[13:01] <cjwatson> Please stop asking me - I don't know
[13:01] <cjwatson> Talk to them
[13:04] <phillw> cjwatson: I do apologise, I do get frustrated at times. May I repeat that you are "one of the good guys" for trying to keep a PPC release going. I do not say 'thank-you' often enough. You really are a star.
[13:05]  * smartboyhw nods in agreement:P
[13:06] <cjwatson> I'm not fishing for compliments or anything - it's just that the best way I can help is to encourage you to talk to the people who actually have useful knowledge
[13:29]  * ogra_ shudders seeing Laney approved bug 999771
[13:29] <ubot2> Launchpad bug 999771 in myunity "myunity depends upon DISTRIB_RELEASE being the second entry in /etc/lsb-release" [Undecided,Won't fix] https://launchpad.net/bugs/999771
[13:30] <Laney> k
[13:31] <ogra_> they should have used lsb_release -r
[13:33] <micahg> that would require a runtime dependency on lsb-release
[13:33] <Laney> indeed
[13:33] <ogra_> sure
[13:33] <Laney> the fix in there is miles better than it was
[13:33] <cjwatson> Hmm, this tickles a memory somewhere
[13:33] <Laney> cjwatson: your name is indeed invoked in the bug :-)
[13:33] <micahg> (which is in minimal, so shouldn't matter too much), but running the command is usually slower though
[13:33] <cjwatson> I have a distinct feeling I remember a bug related to assuming /etc/lsb-release was shell
[13:33] <ogra_> but its a tool to manage unity ... which surely pulls in some python already
[13:34] <cjwatson> Laney: an older memory :)
[13:34] <Laney> heh
[13:34] <ogra_> so adding lsb-release as a dep shouldnt add much
[13:34] <micahg> chromium used it for a while (don't remember if it still does or not)
[13:34] <micahg> ogra_: the problem is lsb_release is slow
[13:34] <ogra_> oh, come on ...
[13:35] <cjwatson> I'm going to have to grep my upload mailboxes :-/
[13:35] <smartboyhw> skaet, er release meeting today?
[13:35] <ogra_> its a one time check in a gui tool
[13:35] <Laney> it's hardly a terrible fix
[13:35] <Laney> people coming out of the woodwork immediately after the upload rather than the weeks when the patches were available ...
[13:35] <micahg> ogra_: it should really be generated at build time IMHO
[13:35] <cjwatson> Laney: the one worry I have is that my memory is that this may be crashy on some flavours
[13:35] <ogra_> micahg, ++
[13:35] <cjwatson> I'm trying to find the history to see if it's this I'm thinking of or something else
[13:37] <doko> Laney, use /etc/os-release ... the format is defined
[13:37] <ogra_> doko, but only available in quantal
[13:37] <cjwatson> bug 214861
[13:37] <ubot2> Launchpad bug 214861 in localechooser "expects to be able to source /etc/lsb-release" [High,Fix released] https://launchpad.net/bugs/214861
[13:37] <cjwatson> Laney: ^-
[13:38] <doko> well, I'll see to backport this then to precise
[13:38] <Laney> aha
[13:38] <cjwatson> Laney: localechooser has some battle-tested shell code for this
[13:38] <cjwatson> which matches the python implementation afaik
[13:38] <Laney> perhaps you want to inform marga
[13:38] <cjwatson> yeah
[13:42] <cjwatson> Laney: Done.  Sorry for being late, but associative memory over four years takes a while to respond sometimes
[13:45] <Laney> cjwatson: Ta. It's an interesting data structure that has such a fast membership operation, but much slower lookup performance
[13:47] <cjwatson> Laney: That's a hash :-)
[13:48] <cjwatson> In the crypto sense - you can check whether you have the ciphertext, but getting back from that to the plaintext is hard ...
[13:52] <Laney> Also here the membership test is probablistic, and the hashes get harder to crack over time :P
[14:16] <skaet> smartboyhw - yes there is a release meeting today
[14:16] <smartboyhw> skaet, thanks
[14:23] <doko> skaet, for a gcc-4.7 update, which should go to -updates ... can I upload to -proposed? or just prepare and build in the ubuntu-toolchain-r ppa?
[14:24] <cjwatson> If you upload to -proposed at the moment, there's a decent chance somebody running on autopilot will copy it to release
[14:24] <skaet> doko,  please do it in the ppa,
[14:24] <doko> ok
[14:35] <tumbleweed> not that I tend to be particularly active at release meetings, but advance notice: I almost certainly can't make it
[16:24] <skaet> hmm....   do we want to reject the nvidia-graphics-drivers-tegra3 in unapproved queue,  until the source version in the new queue is processed?
[16:25] <ogra_> skaet, ?
[16:25] <ogra_> one is tegra, the other is tegra3
[16:25] <ogra_> tegra3 is completely new
[16:25] <ogra_> -tegra is just a package update for the tegra2 drivers
[16:25] <skaet> ogra_  Thanks!   ok,  missed that "3", and thought somethin weird was going on since the versions looked the same.
[16:26] <ogra_> yeah, i was pondering to name them -cardhu and -ventana (teh work names for the tegras) ... but then tegra2 would have had so much extra paperwork (new source etc)
[16:27] <skaet> ogra_ what's the bug associated the tegra3 ones?   would like to read the backstory.
[16:27] <ogra_> i wanted to save us from that ... though i agree the naming isnt great :)
[16:27] <ogra_> skaet, identical code, same bug
[16:27] <ogra_> i would have filesd a tegra3 task, but thats only possible once a source package is in the archive
[16:27] <ogra_> *filed
[16:28] <skaet> fair enough.   Thanks for the background
[16:28] <ogra_> skaet, the libas have now a SONAME field (never had that before) but that doesnt have the correct contant
[16:28] <ogra_> sigh, my typing degrades every day
[16:29]  * skaet just sees that a flood of langpacks has hit the unapproved queue.... :P
[16:29] <ogra_> skaet, if you run ldconfig on them, the broken info lands in ld.so.cache
[16:30] <ogra_> if an app looks for libEGL.so.1 ld only knows about libEGL.so
[16:30] <ogra_> so the app cant run
[16:33] <skaet> Laney,  would you mind taking a look at the libunity that seems to be in the unapproved queue?
[16:36]  * skaet takes her turn letting through some rebuilds
[16:37] <roadmr> micahg: sorry to pester you, we FFed bug 1060211 if you want to have a look,  depending on what happens with that I'll resubmit the merge for checkbox 0.14.8
[16:37] <ubot2> Launchpad bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix committed] https://launchpad.net/bugs/1060211
[16:38] <ogra_> thanks !
[16:41] <apw> infinity, cjwatson, i have updated linux-signed to add the postinst/postrm and linux-image binary dependancies
[16:49] <micahg> roadmr: IANA release team member
[16:49]  * micahg can sponsor once approved
[16:50] <roadmr> micahg: oh ok! thanks anyway!
[17:13]  * skaet starts wading through RIddell's langpack changes...
[17:14]  * iulian is reviewing the other ones.
[17:15] <iulian> Well, not all of them. :)
[17:15] <smoser> hi. can i get an approval on a cloud-init upload ?
[17:15] <cjwatson> Upload it first then we'll review it
[17:15] <smoser> https://launchpad.net/ubuntu/quantal/+source/cloud-init/0.7.0-0ubuntu2
[17:15] <cjwatson> Or is it that one in the queue?
[17:15] <smoser> should be in queue
[17:16] <smoser> yes.
[17:17] <cjwatson> smoser: accepted
[17:17] <skaet> cjwatson, can you take the linux signed one too?
[17:18] <cjwatson> Yep, looking
[17:18] <skaet> ta
[17:18] <skaet> hmm... is queuebot acting up again?
[17:18]  * skaet accepted a couple and not seeing them.
[17:19] <infinity> Ugh.
[17:19] <cjwatson> Which?
[17:19] <infinity> ScottK: There seems to be an explosion of KDE-related things that want to come back to main.
[17:20] <cjwatson> infinity: Ugh, what.  language packs maybe?
[17:20] <cjwatson> No ...
[17:20] <micahg> langpacks in main are part of it
[17:20] <cjwatson> Well, maybe
[17:20] <cjwatson> What the heck is the root cause of all that
[17:20] <micahg> according to http://people.canonical.com/~ubuntu-archive/component-mismatches.svg :)
[17:20] <infinity> langpacks and kde4libs->kate.
[17:21] <skaet> they were labeled universe
[17:21] <cjwatson> This is the tool that does the labelling
[17:21] <infinity> So, the langpack bit is simple to fix.  Let's go see what changed to make the other bit happen.
[17:22] <skaet> ok,  will leave them for infinity to sort.
[17:22] <smoser> thank you.
[17:22] <cjwatson> Hm, yes, language-pack-kde-zh-* might be the cause of the lot
[17:22] <cjwatson> ubuntu.quantal/usb-live: * /^language-pack-[^-]+-zh-han/
[17:22] <cjwatson> That plus (presumably) a new dependency?
[17:23] <infinity> You'd think...
[17:23]  * skaet shakes her head at the kate package name, and see the potential for confusion.
[17:24] <cjwatson> Yeah, that would account for it
[17:24] <cjwatson> Fix that seed and I think everything else should follow
[17:24] <skaet> ok
[17:24] <infinity> Yeah, I'm not seeing the kde4libs->kate thing.
[17:25] <infinity> The fancy svg might be lying.
[17:25] <cjwatson> The rest is all the effect of Extra-Includes, I believe
[17:25] <cjwatson> Pull in enough stuff and the auto-"include -dbg" stuff kicks in and drags in half the world
[17:25] <cjwatson> Also, stuff.
[17:25] <infinity> Have you already mangled the seed, or shall I?
[17:26] <cjwatson> No, go ahead.  I'm too woozy for regexps.
[17:26] <infinity> I've so far failed to wake up this morning.
[17:26] <infinity> I'm out of bed only to prove I'm not dead. ;)
[17:26] <infinity> But, let's regex away.
[17:29]  * infinity wonders why that regex is there at all...
[17:29] <cjwatson> Probably made sense once.
[17:32] <infinity> I suspect that replacing the zh-han regex with /^language-pack-gnome-zh-han/ will fix it all up nicely.
[17:33]  * infinity will do a quick before-and-after germinate for both Ubuntu and Kubuntu and check.
[17:33] <cjwatson> Agreed.
[17:35] <iulian> gilir: Have you uploaded pcmanfm as well? I can only see libfm in the queue.
[17:36] <iulian> gilir: Nevermind, saw it.
[17:47] <bdmurray> could somebody have a look at approving my update-manager uploads to p and o proposed?
[17:50] <infinity> bdmurray: Sure, I'll trade you those for my eglibc upload to precise.
[17:51] <infinity> bdmurray: (Which is a combination of the 10.1 that was previously accepted and then superseded by the security update, the 10.2 security update, and then two small patches from the recent quantal)
[17:51] <kenvandine> the latest upload for aptdaemon ftbfs because of failing tests, i tried building the latest built version and it now ftbfs as well
[17:52] <kenvandine> anyone have suggestions for someone that might be around that has messed with aptdaemon in the past?
[17:52] <bdmurray> infinity: the changelog entry for update-manager is longer than the change - I'm not sure this a good deal
[17:52] <kenvandine> or... if we can turn off those tests until mvo can look at it on monday, so we get some better testing of webapps over the weekend?
[17:53] <kenvandine> the tests fail for the current published version of aptdaemon anyway, so that isn't a regression
[17:53] <kenvandine> but i would really like to be able to get more testing for webapps
[17:54] <infinity> bdmurray: It's probably a bum rap for you, but someone needs to accept that eglibc, and I'm pretty sure it's not allowed to be me (even if I've verified a few times that the diff is sane). :P
[17:54] <kenvandine> skaet, ^^
[17:56] <cjwatson> kenvandine: I'll have a look either tonight or tomorrow if nobody else does
[17:56] <cjwatson> Please don't disable tests
[17:56] <kenvandine> ok
[17:56] <kenvandine> i didn't want to... just couldn't find anyone to look at it that knew their way around
[17:57] <kenvandine> cjwatson, thanks!
[17:57] <kenvandine> the more testing we can get for webapps, the better :)
[17:57] <infinity> bdmurray: Uhm, your precise-proposed update imported quantal sources.
[17:58] <infinity> bdmurray: I'm thinking that was unintentional, given the changelog.
[18:02] <bdmurray> infinity: yes, I'm not sure how that happened
[18:02] <infinity> bdmurray: oneiric looks good, though.
[18:05] <infinity> bdmurray: Given the tininess of the diff, I'd probably not mess with pre-upload magic at all, and just apply it directly to the source package, but whatever workflow helps you sleep better...
[18:09] <bdmurray> It looks like something in utils/demotions.py - I'll try and sort it out
[18:13] <skaet> thanks kenvandine, cjwatson
[18:27] <slangasek> cjwatson: ^^ new shim with changed path for second stage, as requested
[18:53] <bdmurray> infinity: ^
[18:54] <slangasek> self-accepting shim (time-sensitive, can't break anything yet because we're still putting it in place)
[18:55] <Daviey> shimmy it in!
[18:57] <kenvandine> Daviey, :-D
[19:04] <skaet> slangasek, well, I'd trust your review over mine on the subject, at any rate. :P
[19:17] <slangasek> infinity, bdmurray: does eglibc still need looking at?
[19:17] <infinity> slangasek: Looks like bdmurray got to it for me.
[19:17] <infinity> slangasek: You're free. :)
[19:17] <slangasek> ah ok
[19:17] <infinity> (Free to keep hating secure boot...)
[19:17] <slangasek> sorry, was a bit tied up this morning :P
[19:22]  * skaet --> dr. appt.  back on later.
[19:28] <slangasek> Daviey: mm, why does http://people.canonical.com/~ubuntu-archive/component-mismatches.txt show maas having a dependency on a package not in main?
[19:28] <slangasek> (ipmitool)
[19:32] <Daviey> slangasek: because that is the intention of the report, it shows packages that depend or recommend on universe packages.. And candidates for demotion.. but i know you know that?
[19:33] <slangasek> Daviey: I'm trying to figure out why we're two weeks before release and there's a package in main with a dependency on a package that's never been in main, and I find no MIR for it
[19:33] <Laney> slangasek: https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1040682
[19:33] <ubot2> Launchpad bug 1040682 in ipmitool "[MIR] ipmitool" [High,Invalid]
[19:34] <slangasek> ah, I didn't check 'invalid'
[19:34] <Daviey> slangasek: it's being replaced with freeipmi on next upload, covered by MIR 1052056
[19:34] <Daviey> bug 1052056
[19:34] <ubot2> Launchpad bug 1052056 in freeipmi "[FFe] [MIR] freeipmi" [Undecided,In progress] https://launchpad.net/bugs/1052056
[19:34] <slangasek> ok
[19:35] <Daviey> slangasek: The debdiff for jdstrand's requirements is here, http://paste.ubuntu.com/1262079/ pending one more addition.. which is in progress
[19:35] <Daviey> (this was discussed in the release meeting, just a few hours ago)
[19:35] <slangasek> alright
[21:04] <ScottK> No more KDE stuff on http://people.canonical.com/~ubuntu-archive/testing/quantal_outdate_all.txt
[21:04] <ScottK> Riddell: I think the copying misfire is all cleaned up now.
[21:07] <Riddell> oh great, many many thanks
[21:26] <cjwatson> I already reviewed the minitube diff when granting its FFe, so accepted.
[21:58] <jdstrand> skaet: hmmm, final freeze is next tuesday? that is rough on the US...