[01:00] <kklimonda> hey, can you guys take a look at bug 662100 ?
[01:05] <poolie> i'll look
[01:06] <poolie> kklimonda, there's nothing obvious to me
[01:07] <poolie> kklimonda,  it would be nice if it explained what made it decide there was nothing suitable
[01:09] <kklimonda> poolie: I don't think I got any mail from LP about it but I remember deleting quite a lot of them at some point..
[01:09] <poolie> seems unlikely but could it be that you're trying to build for some nonexisitant platform or architecture?
[01:11] <kklimonda> no, the same recipe has succesfully built for few weeks
[01:12] <james_w> kklimonda, what happens when you try and request a manual build?
[01:12] <kklimonda> I get an error: "An identical build is already pending for ubuntu maverick"
[01:12] <wgrant> The issue is that the BuildQueue records are missing.
[01:13] <mwhudson> that this one https://code.edge.launchpad.net/~kklimonda/+recipe/transmission-daily/+build/4050 still seems to be uploading is a bit strange too
[01:13] <wgrant> I tried to work it out last week, but it really needs to be investigated by somebody who has log access.
[01:13] <wgrant> mwhudson: Known bug. Failed uploads aren't recorded.
[01:13] <wgrant> The fix landed overnight.
[01:13] <mwhudson> ah ok
[01:13] <mwhudson> ahh, a forgotten commit?
[01:14] <wgrant> Yep.
[10:41] <fta> dput over sftp is broken today
[10:42] <bigjools> fta: can you be more specific?
[10:43] <fta> it just sits there doing nothing, then the server closes the connection
[10:43] <bigjools> which machine are you connecting to?
[10:44] <fta> the one you asked me to use
[10:44] <fta> hold on
[10:44] <fta> ppa.launchpad.net
[10:45] <bigjools> it looks sick
[10:45] <bigjools> gimme a few minutes
[10:45] <fta> germanium.canonical.com:ssh (ESTABLISHED)
[10:48] <Daviey> Hi!  Is anyone able to tell me why (for example) https://blueprints.edge.launchpad.net/linaro-pm-wg/+spec/hardware-linaro-n-meta-pm-tools isn't showing on https://edge.launchpad.net/sprints/uds-n/+temp-meeting-export
[10:48] <fta> either it's doing nothing at all, or it's really slow and times out
[10:52] <wgrant> Daviey: It's Approved.
[10:52] <wgrant> Daviey: Only New, Discussion and Draft blueprints appear to be included in that export.
[10:55] <Daviey> wgrant: urg
[10:55] <Daviey> apw: Do you have power to bounce into new to test?
[10:55] <Daviey> or one of the other states?
[10:55]  * apw goes have a look
[10:59] <Daviey> grepping the export url, seems to confirm wgrant is correct
[10:59] <Daviey> grep for "meeting status"
[11:00] <apw> Daviey, asked for that one to be changed, also testing with one of mine which appears to be missing too and is Approved
[11:00] <apw> wgrant, how live is that report?  i changed the state on mine but its not yet appeared
[11:01] <Daviey> apw: Have you bounced that out of approved?
[11:01] <apw> yep, but its not yet appeared
[11:01] <wgrant> apw: It's there for me.
[11:02] <wgrant>     <meeting status="DISCUSSION"
[11:02] <wgrant>              name="hardware-linaro-n-meta-pm-tools"
[11:03] <apw> wgrant, yeah and they arn't for me, so i assume a cache is getting in my way
[11:03] <Daviey> yeah, same here.
[11:04] <Daviey> ah, just showed!
[11:04] <apw> yep, we are getting a cached copy
[11:04] <Daviey> apw: running an import now
[11:05] <apw> thanks ... wgrant ... the rules are somewhat hard to hit these days :)
[11:05] <wgrant> Hm, I can't see any caching.
[11:06] <wgrant> Although it could be cached if you're not logged in.
[11:06] <Daviey> http://pb.daviey.com/bWAa/raw/
[11:06] <Daviey> well.. curl isn't going to be logged in :)
[11:06] <wgrant> Ah, not logged in.
[11:07] <Daviey> it's hit and miss :)
[11:07] <apw> we have some front end short lived caches i think to reduce load
[11:08] <wgrant> Right. Unauthenticated requests are cached.
[11:08] <Daviey> apw: OK, i'll let you know when that one imported
[11:10] <apw> Daviey, wgrant thanks both for your help with this
[11:10] <Daviey> apw: No problem, i would still have been scratching my head if it wasn't for wgrant :)
[11:10] <Daviey> apw: btw, that one is now scheduled
[11:12] <apw> Daviey, most excellent
[11:20] <Daviey> apw: not in launchpad.. lets go -> :)
[11:22] <Mez> Who do I speak to about problems with a buildd?
[11:22] <Mez> Cannot build any of the architectures requested: any
[11:22] <persia> Which buildd?  Which build ID?
[11:22] <wgrant> Mez: Where'd that message appear?
[11:22] <persia> (this is usually as good a place as any)
[11:22] <wgrant> That sounds like it would appear in an upload rejection, not a build log.
[11:23] <Mez> wgrant: yeah, it's an upload rejection
[11:23] <wgrant> Uploading to something ancient, like intrepid?
[11:23] <Mez> So, yeah, dak / whatever
[11:23] <Mez> yes, uploading to intrepid
[11:23] <wgrant> intrepid is obsolete.
[11:23] <wgrant> Has been for six months.
[11:23] <persia> That's an odd error, really.
[11:23] <wgrant> It is.
[11:23] <wgrant> But so is uploading to Intrepid :)
[11:23] <persia> Well, yes.
[11:24] <Mez> wgrant: I know it's obsolete ... but then - I have to build stuff.... cause some ****** setup a couple of intrepid servers that we can't update
[11:24] <wgrant> Mez: You probably want to incinerate those servers or something...
[11:24] <wgrant> Given the whole lack of security updates thing.
[11:25] <Mez> Unfortunately, I can't
[11:33] <persia> Mez, So, you *can* create an sbuild instance against old-releases, and use that to build stuff locally.
[11:34] <bigjools> fta: I tried to upload something and it worked, the only problem was that the session didn't disconnect properly
[11:34] <bigjools> we're looking into it
[11:35] <fta> bigjools, on my side, there's a select() waiting forever for something to come up from the tcp socket.
[11:35] <bigjools> yeah, same here I think
[11:35] <fta> bigjools, the host is 91.189.90.217 = germanium.canonical.com
[11:35] <bigjools> yup
[11:52] <Tigeli> koit
[11:52] <Tigeli> hups :D
[12:44] <maxb> wgrant: Hi - the superseding-across-series bug - poolie got an email from mrevell and forwarded it to me asking us to reupload unspecified packages to the bzr ppa to restore them. Would we be able to see evidence in the web UI of damaged packages?
[12:49] <wgrant> maxb: You can identify them through the web UI, but you basically have to check them all.
[12:49] <wgrant> Unless someone has run a query to list them.
[12:50] <maxb> So, if it does not say "Superseded" or "Removed from disk", it should all be good? Because so far I've not been able to find any damaged ones - hence the hesitation whether I'm doing it right
[12:51] <wgrant> maxb: The problematic publications will be Superseded.
[12:51] <wgrant> Superseded by a build that is not published in that series.
[12:53] <maxb> I can't seem to find any. Oh well, perhaps mrevell was just being over-cautious
[13:15] <bigjools> maxb: he was emailing based on a list I gave him.  It's possible that someone re-uploaded a package since it was borked but before the email went out.
[13:46] <napster> How to delete a project of mine?
[14:15] <bilalakhtar> Is there some problem with the official archive builders? My build is continuously getting tried and re-tried all by itself every 5 mins without any log!
[14:17] <bilalakhtar> A few moments ago, a build was 4 seconds away, then it automatically went in the 'building' state and now, in just a few more seconds, its back at 'needs building'
[14:19]  * bilalakhtar now has to go , sorry
[14:41] <MTecknology> My package went from building.. "started 2 min ago" to "start in 2 min"
[14:45] <kai> MTecknology: x86 and x86_64 builds?
[14:45] <MTecknology> kai: x86
[14:45] <kai> not building both?
[14:46] <MTecknology> kai: the x86_64 builds seem to have finished in the blink of an eye
[14:46] <maxb> MTecknology: The builder it was building on could have been taken out of service, or, a bug could have terminated the build
[14:46] <MTecknology> oh
[14:47] <MTecknology> That would make sense then
[14:47] <bigjools> fta: FYI: Bug 663222
[14:48] <MTecknology> I just saw it happen and I was kinda like, hey man, what the heck man; it the it's like; calm down man, we build soon man
[14:49] <bigjools> MTecknology: package name please?
[14:49] <MTecknology> bigjools: nginx
[14:49] <bigjools> and PPA or Ubuntu?
[14:49] <MTecknology> ppa
[14:49] <kai> MTecknology: canonical hired the guy who also built the windows progress dialog ;)
[14:49] <MTecknology> https://edge.launchpad.net/~nginx/+archive/stable/+build/2009518
[14:49] <MTecknology> kai: LOL!
[14:50] <MTecknology> That'll probably be the most awesome thing I read all week
[14:52]  * kai bows
[14:53] <bigjools> I would laugh as I also did at that xkcd cartoon but then I know how hard it is to get right :/
[14:53] <kai> bigjools: I was about to cite http://xkcd.com/612/ for the idea, yeah
[14:54] <bigjools> best xkcs evar
[14:54] <bigjools> xkcd, even
[14:54] <kai> my favourite is http://xkcd.com/303/
[14:54] <bigjools> 2nd best :)
[15:06] <MTecknology> bigjools: can you tell me if the build is breaking?
[15:07] <MTecknology> or if it's just having extremely poor luck..
[15:07] <bigjools> I am looking into it
[15:39] <MTecknology> bigjools: it's building yet again....
[15:39] <MTecknology> bigjools: time to see how it goes
[15:39] <bigjools> MTecknology: I know
[15:39] <bigjools> something is broken with that build
[15:39] <bigjools> I don't know what
[15:39] <bigjools> can you upload another to get it superseded?
[15:39] <MTecknology> ya, but I'll need to fix it first, won't i?
[15:40] <bigjools> MTecknology: well it would be good to see if it's repeatable
[15:40] <bigjools> I can see it getting dispatched to 2 builders at the same time which indicates a problem in our code
[15:40] <MTecknology> bigjools: 2 ppa's
[15:41] <bigjools> ah
[15:41] <MTecknology> development and stable
[15:41] <bigjools> didn't look that closely, ok
[15:41] <bigjools> assumption being the mother of all f....
[15:41] <MTecknology> :P
[15:42] <bigjools> MTecknology: there is something odd though
[15:42] <bigjools> it's an i386 build running on an amd64 builder :/
[15:42] <MTecknology> bigjools: I'm ready upload the new one - maybe wait until this one pukes?
[15:42] <MTecknology> ?
[15:43] <bigjools> ah no - the build page is talking crap
[15:43] <MTecknology> lol
[15:44] <MTecknology> it built this time..
[15:44] <bigjools> yeah
[15:44] <bigjools> but
[15:46] <bigjools> sigh - the builder description says "amd64" yet it's an i386 builder
[15:47] <bigjools> let me know if you see it happening again
[15:47] <MTecknology> bigjools: there's two amd64 builds still waiting
[15:47] <MTecknology> any chance that's part of it?
[15:47] <MTecknology> or.. probably not
[15:47] <bigjools> I doubt it
[15:48] <bigjools> I restarted the manager process and everything started working again
[15:48] <bigjools> there's a subtle bug in there somewhere :(
[15:49] <MTecknology> thanks for looking at it :)
[16:15] <mterry> PPAs on staging.launchpad.net are completely separate data-wise from ones on production, right?  Like, I can add and remove packages and it wouldn't affect production (like one would normally expect with staging server, but just never heard anyone talk about PPAs specifically)
[16:18] <fta> jtv, hi, i want to simplify the encoding of my strings (they come from xml so there are extra encodings and tags that are not needed (wanted) in gettext format). if i change them now, how long will the old strings stay available to translators in launchpad?
[16:35] <shadeslayer> mterry: id think so
[16:36] <shadeslayer> mterry: from what i know, staging.lp.net is overwritten by lp.net every few hours
[16:36] <mterry> shadeslayer, yah.  Just didn't know if that extended to PPAs.  No reason it wouldn't, I guess.  Just seems like a lot of data to duplicate
[16:37] <shadeslayer> probably ..... im not sure either
[16:39] <mterry> I'll test  :)
[17:14] <mterry> It looks to be the case for PPAs that you can create them or whatever and they don't show up in production.  But now I'm trying to dput to a staging URL (ppa.staging.launchpad.net), but it doesn't exist?
[17:21] <cody-somerville> mterry, the soyuz infrastructure is not duplicated for staging
[17:21] <cody-somerville> mterry, if you want to test something with soyuz you need to use dogfood
[17:22] <mterry> cody-somerville, hey Cody!  :)  dogfood?
[17:22] <cody-somerville> dogfood.launchpad.net
[17:22] <mterry> cody-somerville, can you explain dogfood vs staging?
[17:23] <mterry> (or link me to one)
[17:23] <cody-somerville> mterry, dogfood is the soyuz team's test instance
[17:25] <mterry> cody-somerville, but it has same semantics as staging, where data is overwritten once a day or so, etc.?  /me is curious why they don't just use staging
[17:27] <cody-somerville> I imagine because if they're testing a new buildd-manager they don't want their code and data to be automatically overwritten :P
[17:28] <mterry> cody-somerville, oh, so you're thinking it has a different resync schedule
[17:28] <cody-somerville> mterry, it only 'resyncs' if the Soyuz guys want it to
[17:29] <mterry> cody-somerville, OK.  Thanks!
[19:08] <mterry> I'm interested in launchpadlib help.  Say I have a project.releases_collection_link (or really any of the 'link' attributes in the API).  It appears to just be an object ID.  So I loaded it up using launchpad.load, but it gave me an Entry that is not iterable (nor does it have a self_id...).  How do I access API links?
[19:10] <mterry> Hrm, only the releases_collection_link fails like this.  owner_link works.  May just be a bug...  I'll file one
[19:13] <cody-somerville> mterry, if you're using launchpadlib, you would just access the releases_collection attribute on the project object
[19:14] <mterry> cody-somerville, what the heck?!  That works but is not documented in the API
[19:14] <mterry> cody-somerville, is that a common pattern for '_link' attributes?
[19:15] <mterry> cody-somerville, well thank you!  That saves me time
[19:26] <cody-somerville> mterry, Its a feature of launchpadlib, yea.
[19:48] <sobczyk> hi, how fast my package will appear after uploading to ppa?
[20:24] <Gameboyman99> Hey if I file a bug(https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/660837) how long does it usually take ppl to get to it?
[20:25] <Gameboyman99> 'Cuz it's bees there about 2 wks. or so
[20:26] <Gameboyman99> *been
[20:42]  * mwhudson stares at https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntutheproject-launchpad-n-launchpad-bazaar-introduction, tries to work out why he's getting mail about it
[20:42] <mwhudson> oh, i'm drafter
[21:57] <geser> does somebody know what happened to the "upload logs"? e.g. https://edge.launchpad.net/ubuntu/+source/icecc/0.9.6-1/+build/2000412 has none
[21:57] <geser> I remember being able to see the upload log for FAILEDTOUPLOAD
[22:10] <wgrant> geser: There are around 200 builds across Launchpad which are in that state. There was a bug which wasn't storing them.
[22:10] <wgrant> But all new upload failures should have a log.
[22:12] <geser> wgrant: so this bug should be already fixed?
[22:12] <wgrant> geser: Yes.
[22:13] <wgrant> Retry it, and it will either succeed or have an upload log.
[22:14] <geser> let's see what happens in around 15 min
[22:17] <geser> nice, the FTBFS script hit the small window when two package versions are published at the same time (before the old one gets marked as superseded) :)
[22:29] <geser> wgrant: like it was to expect, it was only a transient error and the package build now
[22:29] <wgrant> geser: Then it'd be particularly nice if we had an upload log for that previous failure :/
[22:30] <geser> wgrant: did that get fixed after 2010-10-16? as this build was from three days ago
[22:30] <wgrant> geser: Yes, it was fixed just a couple of days ago.
[22:32] <geser> now I just need to get the patch for the DEPWAIT regexes reviewed so we hopefully have soon proper DEPWAIT again