[00:02] <mwhudson> james_w: https://code.launchpad.net/~james-w/launchpad/export-specification-bug-links/+merge/42426 has conflicts
[01:30] <LPCIBot> Yippie, build fixed!
[01:30] <LPCIBot> Project devel build (267): FIXED in 3 hr 9 min: https://hudson.wedontsleep.org/job/devel/267/
[01:30] <LPCIBot> Launchpad Patch Queue Manager: [r=deryck][ui=none][bug=514190, 672576] Update lazr-js to 1.5DEV-r191.
[01:38] <james_w> mwhudson, so it does, thanks
[04:08] <lifeless> [04:08] <lifeless>     Hard / Soft  Page ID
[04:08] <lifeless>      387 / 6695  Archive:+index
[04:08] <lifeless>      155 /  482  BugTask:+index
[04:08] <lifeless>      126 /  226  Question:+index
[04:08] <lifeless>       49 /  104  RootObject:+login
[04:08] <lifeless>       39 /  247  Distribution:+bugs
[04:08] <lifeless>       37 /   50  DistributionSourcePackage:+index
[04:08] <lifeless>       33 /  283  POFile:+translate
[04:08] <lifeless>       27 /   39  Distribution:+questions
[04:08] <lifeless>       26 /  126  BranchSet:CollectionResource:#branches
[04:08] <lifeless>       26 /    0  https://api.launchpad.net
[04:08] <lifeless> wgrant: its spiking...
[05:47] <poolie> lifeless: did you ever see
[05:47] <poolie> /usr/lib/python2.6/atexit.py:24: DeprecationWarning: Attempt to tearDown inactive fixture.
[05:47] <poolie>   func(*targs, **kargs)
[05:47] <poolie> at the end of an lp testn
[05:47] <StevenK> I keep seeing that with ec2 land and such like
[05:48] <poolie> or LayerIsolationError: Test left new live threads: [<_Timer(Thread-1, stopped 140604130006800)>]
[05:51] <lifeless> basically
[05:52] <lifeless> zope.testing sucks
[05:52] <lifeless> layers and reinvoking processes sucks
[05:52] <lifeless> and rather than have unclean code in the core, I'm building out a stack of clean
[05:52] <lifeless> the downside is some things will warn
[05:53] <poolie> as long as it's not my fault :)
[05:53] <lifeless> probably isn't
[06:06] <lifeless> thumper: was baxters keynote good ?
[06:06] <spiv> lifeless: heh, trying to decide whether you'll go to SyPy tonight? :)
[06:06] <lifeless> spiv: exactly!
[06:07] <lifeless> spiv: having yak shaved the day on a modem issue + chatting with poolie.
[06:10] <lifeless> meh, its hot, long walk isn't what I need.
[06:10] <lifeless> not with a 4:40am - nzdst - start time.
[06:11] <spiv> lifeless: I feel sleepy just thinking about that!
[06:12] <lifeless> yah
[08:06] <thumper> lifeless: yes
[08:53] <adeuring> good morning
[08:58] <mrevell> Morgen
[08:58] <adeuring> moin mrevell
[08:58] <mrevell> :)
[08:59] <bigjools> helleau
[11:17] <salgado> can somebody running Maverick run a 'grep shared_buffers /etc/postgresql/8.4/*/postgresql.conf' for me?
[11:17] <wgrant> salgado: shared_buffers = 28MB			# min 128kB
[11:18] <salgado> wgrant, thanks.  care to also grep max_connections and tell me what you have in /proc/sys/kernel/shmmax ?
[11:18] <wgrant> salgado: shmmax is 33554432
[11:19] <wgrant> max_connections is 100
[11:21] <salgado> if I have exactly that, postgres fails to start but tells me I have max_connections==103 rather than 100
[11:21] <salgado> wtf!?
[11:22] <wgrant> Hah.
[11:22] <wgrant> Hmm.
[11:23] <wgrant> I recall that it reserves connections for superusers.
[11:23] <wgrant> salgado: Where are you getting the 103?
[11:24] <salgado> wgrant, the error message:
[11:24] <salgado> [2010-12-02 09:22:38 BRST] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently 33562624 bytes), reduce PostgreSQL's shared_buffers parameter (currently 3584) and/or its max_connections parameter (currently 103).
[11:25] <salgado> and it's lying about shared_buffers; it's currently at 28M
[11:25] <wgrant> salgado: #superuser_reserved_connections = 3	# (change requires restart)
[11:25] <wgrant> Looks relevant.
[11:25] <wgrant> But the docs say that should be included within max_connections.
[11:26] <StevenK> 28MiB in bytes is 29360128, which is smaller than 33562624 ... Silly Postgres
[11:31] <salgado> wgrant, changing that doesn't have any effect; postgres still fails and reports 103 max_connections
[11:32] <salgado> however, changing max_connections causes it to start just fine
[11:32] <salgado> reducing it from 100 to 99 is enough
[11:32] <wgrant> Odd.
[11:32] <salgado> indeed
[11:32] <wgrant> Which arch?
[11:33] <salgado> x86_64
[11:33] <wgrant> I'm plain i386 here.
[11:34]  * salgado creates a fresh new cluster to see what it's going to look like
[11:36] <salgado> by default it comes with 24MB for shared_buffers, so it starts up just fine
[11:36] <salgado> but then if I change that to 28MB it fails
[11:37] <salgado> and when it fails it reports the same 103 max_connections
[12:06] <wgrant> bigjools: Do we have a rebuild in our immediate future?
[12:07] <deryck> Morning, all.
[12:10] <bigjools> wgrant: as soon as jelmer lands his fix for not leaving uploads in limbo, yes
[12:10] <wgrant> bigjools: Yay.
[12:11]  * jelmer waves to wgrant
[12:12] <wgrant> Morning jelmer.
[12:29] <bigjools> wgrant: something is odd with domination
[12:33] <wgrant> bigjools: Slow?
[12:33] <wgrant> For those two tortoisehg PPAs?
[12:33] <bigjools> wgrant: some PPA's publications don't seem to get scheduleddeletiondate set
[12:33] <bigjools> so they appear in the getPendingPublicationPPAs every time
[12:34] <wgrant> I haven't been near the condemnation stuff in a while.
[12:34] <wgrant> Let's see..
[12:35] <wgrant> bigjools: Do you have a specific example?
[12:35] <bigjools> yeah
[12:36] <bigjools> a few, hang on
[12:36] <wgrant> The code looks reasonably sane.
[12:36] <bigjools> mirabilos/ppa is one
[12:36] <wgrant> Which pub?
[12:37] <bigjools> working it out, I mention it because it appears in the list of PPAs being processed every time
[12:37] <bigjools> and it's not seen any activity for ages
[12:37] <wgrant> Hmm. We need to ban animated GIFs.
[12:41] <wgrant> bigjools: Do you have any idea what's going on with those two tortoisehg PPAs which take >70s to publish?
[12:42] <bigjools> wgrant: no not yet, I suspect it's related to this issue
[12:42] <wgrant> They only have ~850 source pubs in total...
[12:42] <wgrant> It could be, but it seems too small.
[12:42] <wgrant> Let's see.
[12:43] <wgrant> bigjools: Are you sure that mirabilos doesn't just have some orphaned binaries?
[12:43] <bigjools> also the ubuntu langpack PPA is taking 20 minutes
[12:43] <wgrant> Indices, or something else?
[12:44] <bigjools> will look later
[12:45] <wgrant> The tortoisehg sources seem to all be condemned
[12:47] <bigjools> wgrant: https://dogfood.launchpad.net/~mirabilos/+archive/ppa/+sourcepub/761302/+listing-archive-extra
[12:47] <bigjools> http://pastebin.ubuntu.com/538967/
[12:48] <bigjools> created and deleted without getting published
[12:48] <wgrant> Probably has orphaned binaries.
[12:48] <wgrant> There is a bit of a race there.
[12:48] <wgrant> We need something like NBS.
[12:50] <wgrant> Yep. Binaries still published.
[12:52] <bigjools> why are they still published?
[12:53] <wgrant> It was deleted after the build uploaded, but before process-accepted ran.
[12:53] <wgrant> So the upload was accepted, but the publications weren't there when the deletion happened.
[12:53] <wgrant> So, in other words, custom uploads fuck the world over again :)
[12:53] <bigjools> awesome
[12:53] <bigjools> custom?
[12:54] <wgrant> Custom uploads are the only reason that the upload doesn't create the publishing records.
[12:54] <wgrant> Like it already does for sources.
[12:56] <bigjools> ah right
[12:56] <bigjools> I wonder if we can do it
[12:57] <wgrant> We do need to fix custom copies at some point, and it is the same fix...
[12:58] <bigjools> ok so for ubuntu-langpack, we've got 2 seconds doing nothing but publishing empty Sources/Packages
[12:58] <bigjools> so that will be the same for all PPAs
[12:58] <bigjools> what a waste
[12:59] <wgrant> All pending PPAs.
[12:59] <bigjools> domination is 2.5 minutes
[13:00] <wgrant> on langpack?
[13:00] <bigjools> yes
[13:00] <wgrant> domination, or judgmenet?
[13:00] <bigjools> both
[13:00] <bigjools> superseding processing is the long bit
[13:00] <wgrant> Hmmm.
[13:01] <wgrant> A lot of that is probably the stupid cache invalidation.
[13:01] <bigjools> http://pastebin.ubuntu.com/538970/
[13:01] <bigjools> ummm
[13:01] <bigjools> wtf
[13:02] <bigjools> oh ignore that
[13:02] <wgrant> It just tried to start again?
[13:02] <bigjools> anyway Packages for non-existent arches take too long
[13:02] <bigjools> yeah it tries to start every 5 mins
[13:02] <bigjools> and given that we're taking 35-40m....
[13:02] <wgrant> Non-existent arches?
[13:03] <bigjools> yes, powerpc....????
[13:03] <wgrant> I think we need to move to using ArchiveArch even for non-virt PPAs.
[13:03] <bigjools> which it then generates for each component
[13:04] <bigjools> which is probably why the whole thing is like treacle
[13:04] <wgrant> Restricting that to main is trivial now.
[13:04] <wgrant> + tests
[13:04] <bigjools> that would be a *great* start
[13:04] <wgrant> I made sure to factor that out sanely in my last publisher refactor.
[13:08] <bigjools> jeez, 4 minutes on writing all those empty files!
[13:08] <wgrant> Are they really empty?
[13:08] <wgrant> langpacks are arch-all.
[13:09] <bigjools> ah maybe
[13:09] <bigjools> I assume too much
[13:09] <bigjools> release files, 4 seconds
[13:10] <wgrant> For a single PPA?
[13:10] <bigjools> yes
[13:10] <wgrant> Ouch.
[13:10] <bigjools> components ....
[13:10] <wgrant> True.
[13:10] <bigjools> if we remove non-main we'lll get a huge win
[13:11] <bigjools> I am going to fix this today
[13:11] <wgrant> Archive.getComponentsForSeries
[13:11] <wgrant> Not sure about tests.
[13:11] <bigjools> wgrant: I'll send you a log snippet if you want to examine it more?
[13:11] <bigjools> for a single run, with -v
[13:12] <wgrant> bigjools: I'm about to head off to bed, but I'd be glad to look tomorrow.
[13:12] <bigjools> wgrant: yeah no rush, just thought you'd be interested :)
[13:21] <bigjools> wgrant: so I reckon we should disallow package deletions where there's a build in progress
[13:22] <wgrant> bigjools: This situation can also arise in the normal NBS case, when a source no longer builds a binary.
[13:23] <bigjools> wgrant: I suspect we have a bug for that
[13:23] <bigjools> anyway, errands and food
[15:02] <james_w> benji, hi, could you give me some advice on the webservice?
[15:03] <james_w> benji, we want to export the "bugs" attribute that IBugLinkTarget contributes to Specification. Currently ISpecification isn't related to IBugLinkTarget, Specification just implements(IBugLinkTarget).
[15:04] <james_w> benji, exporting IBugLinkTarget and its bugs attribute and adding it to the webservice interfaces isn't enough, but if I then have ISpecification subclass IBugLinkTarget everything works. Is this the right thing to do, or should I use a different approach to achieve this?
[15:04] <james_w> benji, https://code.launchpad.net/~james-w/launchpad/export-specification-bug-links/+merge/42426 for more context
[15:06] <benji> james_w: taking a look at the MP
[15:06] <james_w> thanks
[15:12] <benji> james_w: a digression: are you aware that the diff in that MP has conflict markers in it?
[15:13] <james_w> benji, yup, just fixed them
[16:06] <benji> james_w: I haven't forgotten about you.  Sill looking.
[16:07] <james_w> thanks
[16:22] <bigjools> jml, leonardr: only series are derived, not distros, in the model we're doing
[16:22] <bigjools> this implies a distro of course
[16:24] <leonardr> bigjools: does that mean that Natty is derived (from Ubuntu or from Maverick?), but Linaro is not? will that change anytime soon?
[16:26] <bigjools> leonardr: Linaro distros would be dervied from a series in Ubuntu.  Ubuntu is dervied from Debian unstable.
[16:26] <bigjools> leonardr: once a distro is derived it cannot be derived again, but you can keep syncing packages
[16:27] <bigjools> we'll track in each Ubuntu series which Debian series we sync from (it can change during LTS releases)
[16:33] <leonardr> bigjools: so, if you were to search for a bug in "ubuntu or its derivatives", you'd be searching across a lot of distribution *releases*, not distributions
[16:33] <bigjools> leonardr: well bugs are different in that regard because they are not targeted to distroseries
[16:34] <bigjools> I think for the case of bugs you can say Ubuntu or its derivatives but I've not really thought about it
[16:35] <bigjools> (and mean the whole distro, I mean)
[16:36] <leonardr> a bug can be targeted to a distro source package, and that's associated with a distribution
[16:36] <leonardr> not a distro series
[16:43] <benji> james_w: I've resorted to building your branch; Do I assume correctly that test_representation_contains_bug_links fails with an attribute error?
[16:44] <james_w> benji, my branch works for me, I'm just not sure that it's the right approach. You get the attribute error?
[16:51] <bigjools> leonardr: I think you'll be ok, I just wanted to ward off any incorrect assumptions in case it causes issues in the future after we finish the derived distro feature
[16:56] <benji> james_w: nope, no error.  It sounds like all classes that implement ISpecification also implement IBugLinkTarget, if so, then your approach is fine.  If not, you should decompose IBugLinkTarget into two interfaces, one that ISpecification implementations can provide and one with the rest of the bits and IBugTarget would inherit from both of those but otherwise be empty
[17:03] <james_w> benji, ok, thanks
[17:51] <sinzui> allenap, ping
[17:59] <cody-somerville> bigjools, Would it make sense to post something in topic/identica about publishing slow down? There seems to be a lot of questions about it.
[17:59] <bigjools> cody-somerville: it's been slow for weeks
[18:00] <cody-somerville> bigjools, No disagreement here about that! :P
[18:00] <bigjools> cody-somerville: :)  I thought it was just the high load - it is, but it's other problems too.
[18:00]  * cody-somerville nods.
[18:00] <bigjools> anyway, I gotta dash
[18:00] <cody-somerville> bigjools, Cool. FYI, expect a trivial branch from me soon.
[18:01] <bigjools> cody-somerville: great!  I'll check later.
[20:21] <sinzui> lifeless, I want to replace the launchpad.Append rules in lp.answers with launchpad.AnswerContact. The use of "Append" is ambiguous and when an object like a distros/project can have many ".Append" rules that conflict. I think .AnswerContact is clear, like Driver and BugSupervisor permissions
[20:24] <deryck> leonardr or benji, hi.  Could one of you look at bug 680339 to see if you can offer insight in what might be happening?
[20:24] <_mup_> Bug #680339: 'Entry' object has no attribute 'markAsDuplicate' <api> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/680339>
[20:25] <benji> deryck: sure
[20:25] <deryck> thanks benji!
[20:29] <deryck> thumper, hey. you want to do a call today?
[20:34] <leonardr> deryck: the thing you 'should' be doing is setting duplicate_of, but 1.0 should be allowing the old behavior for backwards compatibility
[20:36] <leonardr> one possibility is that the wrong wadl is generated for 1.0
[20:36] <leonardr> if the trunk wadl is presented as the wadl for 1.0, then launchpadlib will think there is no such thing as markAsDuplicate
[20:37] <deryck> leonardr, what do you mean "old behavior?"  I'm not following what as changed, though I see what you mean about should be using duplicate_of based on the interface declarations now.
[20:37] <lifeless> sinzui: did you have a tab complete fail there?
[20:38] <leonardr> deryck: in later versions of the web service, methods like markAsDuplicate are no longer exposed as such
[20:38] <sinzui> lifeless, maybe
[20:38] <leonardr> instead, you set duplicate_of the way you would set any other value, and it calls markAsDuplicate behind the scenes
[20:38] <allenap> sinzui: pong
[20:38] <leonardr> the old behavior is that a mutator_for method also shows up as a named operation
[20:39] <deryck> leonardr, got you.  and this was a web service change, nothing that we on the bugs team changed?
[20:39] <leonardr> deryck: right, it is a totally general change affecting every mutator_for method
[20:40] <sinzui> allenap, as I said in reply, our version of simplejson is too old. so I cannot HTML encode
[20:40] <leonardr> i suspect you are getting the 'devel' version of the wadl when you should be getting the '1.0' version--that would tie it in to benji's recent hcnage
[20:41] <deryck> leonardr, ok.  I recall all this for the transitionToStatus, etc., but didn't make the connection here for markAsDuplicate.
[20:41] <allenap> sinzui: Ah, fair enough. It doesn't seem to be causing us bother so far so I'm not really worried.
[20:41] <benji> leonardr: I don't quite follow, will you explain that some more?
[20:42] <allenap> sinzui: Although I think I'll file a bug about it anyway.
[20:42] <lifeless> sinzui: I don't have an opinion about lp.appent/lp.answercontact until jan 4th
[20:43] <sinzui> lifeless, we have a regression. Ubuntu answer contacts cannot manage FAQs because the permission was changed from something removed to a permission that quietly conflicts with Ubuntu's rules for adding series
[20:44] <lifeless> sinzui: ok
[20:45] <thumper> deryck: hi, I'm on leave today :)
[20:45] <thumper> deryck: in fact I'm not working a Friday until Jan :)
[20:45] <deryck> well ok then.  enjoy the leave, thumper :-)  We'll chat in Jan then ;)
[20:45] <thumper> deryck: so perhaps we could arrange a call earlier next week?/
[20:45] <lifeless> sinzui: do you need anything from me
[20:45] <sinzui> no. thanks lifeless
[20:46] <deryck> thumper, sure, let's try to find a time when next week is here.
[20:46] <thumper> deryck: ok
[20:46] <deryck> probably easier now that our times overlap a bit more.
[20:46] <thumper> deryck: yeah, it will be
[20:49] <leonardr> deryck: can you look in your .launchpadlib/api.whatever.launchpad.net/cache/*1.0*wadl and see if the base of the wadl:resources tag really says "1.0"? a
[20:49] <leonardr> (you can make it easier to find the file by removing /cache and running your script again
[20:49] <deryck> leonardr, I can.  this was poolie who reported the bug though.
[20:53] <lifeless> leonardr: the online api doesn't show markAsDuplicate in 1.0
[20:54] <leonardr> lifeless: since the apidoc is generated from the wadl, that means it's not in the wadl
[20:55] <leonardr> there are a couple places where that could go wrong but i would look at the change benji made recently
[20:55] <leonardr> since the other place i can think of involves a change nobody would reasonably make
[21:08] <maxb> *blink* wtf
[21:08] <maxb> I just typoed a PPA Upload and got an email whose subject referred to a totally random other PPA
[21:10] <lifeless> maxb: \o/
[21:12]  * maxb searches bugs for "ppa" and starts reading the resultant list to check for similar
[21:48] <maxb> bug 684450 filed. ftr
[21:48] <_mup_> Bug #684450: Totally unrelated PPA referenced in subject of upload rejection email <Soyuz:New> <https://launchpad.net/bugs/684450>
[23:09] <gary_poster_> sinzui: I added some notes from our conversation yesterday at the bottom of https://dev.launchpad.net/LEP/OpenIdRoadmap .  Your review, additions, and corrections would be appreciated.
[23:09] <gary_poster_> See everybody Monday!
[23:09] <sinzui> okay
[23:45] <mwhudson> maxb: fun bug, it seems
[23:45] <maxb> it's a bit mad, isn't it :-)
[23:45] <maxb> (and scary)
[23:45] <mwhudson> maxb: i just commented
[23:48] <wgrant> maxb: If we have a PPAish upload path that doesn't map to a PPA, we deliberately pick the first PPA we can find. Probably to get PPA-specific error messages.
[23:48]  * wgrant checks the code.
[23:50] <wgrant>             # XXX cprov 20071212: using the first available PPA is not exactly
[23:50] <wgrant>             # fine because it can confuse the code that sends rejection
[23:51] <wgrant> Yay.
[23:51] <wgrant>             # messages if it relies only on archive.purpose (which should be
[23:51] <wgrant>             # enough).