[00:00] <mbarnett> oh, sorry.
[00:00] <mbarnett> yeah, what he said!
[00:05] <maxb> Nooooooooooooooooooooo! Now I'm getting launchpad-bugs-owner "Your message was rejected" spam when I change code imports!
[00:05] <maxb> Pretty please, could someone kill that list :-)
[00:09] <lifeless> I think we should just remove it
[00:09] <lifeless> accept that we send too much mail
[00:09] <lifeless> and fix that
[00:09] <spm> so for example on the multiple tasks front. right now I am: eating son's birthday cake from yesterday; reading 4 irc channels watching a beta update happen on this workstation and pondering if I should read email as well; and seeing what nagios alerts I need to deal with in what order. but notice. cake 1st.
[00:09] <lifeless> someone should get consensus on that on the list
[00:10] <wgrant> lifeless: Just do it. No consensus.
[00:11] <wgrant> lifeless: If it is too spammy, make people fix the spam.
[00:11] <wgrant> Don't readd the address.
[00:11] <lifeless> wgrant: play well with others
[04:52] <ajmitch> wgrant: I've hearing from people that there are permissions issues on recipe builds (debian/control is 0700), is this known?
[04:54] <wgrant> ajmitch: Ugh, still?
[04:54] <wgrant> lamont: ^^
[04:54] <ajmitch> wgrant: yeah, latest build log for it was ~30 min ago, https://launchpadlibrarian.net/68508015/buildlog.txt.gz if it helps
[04:55] <wgrant> Fail.
[04:55] <wgrant> ajmitch: Do you have an LP link for that?
[04:56] <ajmitch> https://code.launchpad.net/~george-edison55/+recipe/jethttp-daily
[04:56] <wgrant> Thanks.
[05:01] <lamont> ajmitch: that is correct.
[05:01] <lamont> wgrant: I'll have a diff for your review shorlty
[05:02] <ajmitch> lamont: ok, thanks :)
[08:43] <AfC> Is it possible for ISPs to set up mirrors of PPAs?
[08:44] <wgrant> AfC: We don't expose rsync or anything like that.
[08:44] <wgrant> It would be nice to have a mirror over here, though :(
[08:44] <AfC> I hadn't really noticed before, but today I'm sucking down something from a PPA that's 160 MB and that's going to add up.
[08:45]  * AfC was very happy to discover that the Fedora based LiveCD was mirrored on Internode because ftp.gnome.org is mirrored there (!)
[08:45] <wgrant> Internode is generally pretty good like that.
[08:45] <wgrant> And in lots of other ways too.
[10:35] <rdale_> I have two email addresses associated with my launchpad account. i've recently subscribed to the ayatana-dev mailing list. i would like to be able to both post and receive mails from my codethink account. but it seems if i try and send from my codethink account, the mails bounce. if i send from the gmail account it works fine, but the mails go to the codethink one. does anyone know how to get launchpad to work with a specific
[10:35] <rdale_> mail address if you have more than one?
[10:36] <lifeless> rdale_: in your +editmails page you can select the one you want mails to be sent to
[10:37] <lifeless> rdale_: you can send from any of your accounts, they get whitelisted automatically
[10:37] <rdale_> ok thanks - i tried to edit my details - but i couldn't find the editmails page - i'll have another look
[10:39] <lifeless> rdale_: https://launchpad.net/people/+me/+editemails
[10:43] <rdale_> thanks - i would have never worked that out :). i've changed it now
[11:18] <popey> lifeless: recall we conversed about private bugs, and how it's annoying if a person tags a public bug as being a dupe of a private bug?
[11:19] <popey> well, it's worse if apport retracing does it
[11:20] <popey> apport retracing service tagged bug 751714 as a dupe of bug 749660 which confused the initial reporter https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/751714/comments/3
[11:22] <lifeless> popey: yes; talk to pitti ;)
[11:23] <lifeless> we may need to refine 'private' into 'hidden' and 'contains confidential data', but thats a big hammer to use
[11:32] <fta> wgrant, hey, did you have a chance to catch a losa today? ;)
[11:40] <eugenesan> HI, why deleted PPAs still appear in list? Can I "revive" or create PPA with same name?
[11:43] <bigjools> eugenesan: no, as it says when you delete them, they are gone for good
[11:44] <bigjools> you currently cannot re-use them because the code to totally wipe them has not been written yet
[11:44] <eugenesan> bigjools: And name got blacklisted?
[11:44] <bigjools> sort of - it's still there, just hidden
[11:46] <eugenesan> bigjools: Very sad, when deleting, I was sure one day I'll able to reuse the name...
[11:49] <bigjools> eugenesan: it's not that simple because if people are using the PPA, then you delete it, and then fill it with packages again, the apt client will get very confused.
[11:51] <eugenesan> bigjools: by apt client you mean apt-get and co?
[11:52] <bigjools> yes
[11:55] <eugenesan> bigjools: Can you please provide an example? I can't see how confusion may happen...
[11:55] <bigjools> eugenesan: providing the same versions of files/packages with different contents will make apt silently fail
[11:56] <bigjools> which is why Launchpad doesn't let you upload conflicting files like that
[11:56] <bigjools> PPA deletion was implemented so people could rename their accounts
[12:00] <eugenesan> bigjools: I see. But I would take that minor risk.
[12:01] <bigjools> well, don't kid yourself that the files are the same
[12:01] <eugenesan> bigjools: Also, what is the chance of PPA being removed for some time and it's lists still stored on client?
[12:02] <bigjools> eugenesan: unless someone removed the packages, a very high chance ;)
[12:06] <eugenesan> bigjools: So problematic scenario is when installed package re-uploaded to "revived" PPA not being marked for upgrade correctly? That's all?
[12:07] <bigjools> eugenesan: no, corrupted installations
[12:09] <eugenesan> bigjools: I see. Thanks for explanation.
[12:09] <bigjools> welcome
[13:01] <mok0> Hm, what's going on here? http://paste.ubuntu.com/590714/
[13:04] <mok0> I'll try to upgrade it from LP
[13:05] <mok0> That takes a good while...
[13:10] <tsimpson> mok0: usually "bzr upgrade" does the trick
[13:18] <mok0> tsimpson: thanks!
[14:38] <lfaraone> So I just uploaded to lucid-proposed, and I wanted to push up my UDD bzr tree to the nonexistant lucid-proposed bit of Launchpad. Is it expected that I'd get an error like "bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: TypeError: (\'Could not adapt\', <SuiteSourcePackage ubuntu/lucid-proposed/python-gasp>, <InterfaceClass lp.code.interfaces.branchtarget.IBranchTarget>)">')"
[14:44] <tumbleweed> lfaraone: I've never bothered pushing to -proposed UDD branches if they don't already exist. (But that doesn't answer your question, and it would be nice to be able to. Also for sponsorship purposes)
[15:09] <jcsackett> lfaraone: the zope exception is not the sort of thing we generally want LP to throw back at users if something more informative can be thrown back. i think that's probably worth filing a bug.
[15:24] <geser> does that work now? I know that you can't create branches that way (only through uploads)
[15:29] <jcsackett> geser: you're referring to lfaraone's message above?
[17:20] <geser> jcsackett: yes, it wasn't possible to use "bzr push" to create a branch in -proposed (but one could "bzr push" to one already created through a former upload) but I don't know if it's still true or if it got fixed in between
[17:35] <bjf> i'm looking at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/730972  and trying to figure out from the LP api how to tell that the "Status tracked in Natty" for the "base" task 'linux (Ubuntu)'
[17:45] <jcsackett> bjf: you can see the other bugtasks for a bug via the related bugtasks; in this instance there's a related task for natty.
[17:52] <bjf> jcsacket, if there are multiple related tasks, how do you know which one the status is tracked in? bug #600453 for example
[17:54] <bjf> jcsackett, and bug 555943 has related tasks for 'linux (Ubuntu)' but it doesn't say "Status tracking in xxx"
[18:15] <jcsackett> bjf: good point, let me do some digging.
[18:22] <jcsackett> bjf: that status, "Status tracked in..." is a result of a something in lp called a conjoined bug, which basically says that one bug is the master bug of another, so everything gets tracked in it.
[18:22] <jcsackett> conjoined statuses don't appear to be exposed on the lp api.
[18:23] <bjf> jcsackett, ok, be nice to have but knowing i can't get to it via the api is also good to know
[18:23] <bjf> jcsackett, thanks for digging into it
[18:23] <jcsackett> bjf: you're welcome. :-)
[19:29] <bjf> jcsackett, if one wanted to email a "team", is there a "team" email address or would one get the "confirmed_email_addresses_collection" for a team and use those ?
[19:34] <jcsackett> bjf: probably best to get the teamowner, and use the preferredemailaddress.
[19:35] <bjf> jcsackett, would that just go to the team owner or all members of the team? i want to spam all members of the team.
[19:36] <jcsackett> bjf: why? it's fairly bad juju to spam an entire team.
[19:36] <bjf> https://launchpad.net/~canonical-kernel-sru-team
[19:36] <bjf> jcsackett, ^
[19:37] <bjf> jcsackett, we are working on a script that monitors certain bugs, if there are problems, we want to email the members of that team that something "bad" has happened
[19:37] <bjf> jcsackett, by using an LP team, kernel folks can add / remove themselves as they seem fit
[19:37] <james_w> bjf, would subscribing them to the bugs work? That generates an email, and is easy to do.
[19:37] <bjf> jcsackett, in reality, there should be very little email sent this way
[19:38] <jcsackett> bjf: see james_w's suggestion. it also might be easier to create a list and have your script email that.
[19:39] <bjf> jcsackett, i'm not sure how a mailing list is better/different
[19:39] <jcsackett> bjf: one email, don't need to poll for all emails, and people can be part of the team (and so see team bugs &c) without necessarily getting emails they don't want.
[19:40] <bjf> jcsackett, true
[19:42] <bjf> but i'm not convinced
[19:47] <jcsackett> bjf: so, AIUI, there isn't an attribute on a team to get all emails for the team members. you would need to go through the member collection and find the preferredemail of each member.
[19:47] <bjf> jcsackett, thanks for the info
[19:48] <jcsackett> bjf: is there a reason that having the team (or teammembers) subscribe to the bugs you're interested in doesn't fill your needs? that tends to send all updates to the bugs via email.
[19:49] <bjf> jcsackett, it's not about the bugs, it's about the automated process that is looking at the bugs and deciding that it requires human intervention
[19:50] <jcsackett> i see.
[19:51] <bjf> jcsackett, https://bugs.qastaging.launchpad.net/ubuntu/+source/linux/+bug/718732
[19:51] <bjf> jcsackett, we are trying to use a bug's "series" as a way to track "workflow"
[19:52] <bjf> jcsackett, use the url i posted not what the bot picked up
[19:53] <bjf> jcsackett, each "series"/task can be assigned to individual teams/users and tracked for progress and status
[19:53] <bjf> jcsackett, a "bot" is watching the bug and helps move things along from stage to stage and looks for "problems"
[19:54] <bjf> jcsackett, it's a "creative" use of LP :-)
[19:54] <jcsackett> :-P
[20:01] <niemeyer> Yo Launchpaders
[20:01] <niemeyer> I was just wondering.. are there any plans for branch commit web-hooks?
[20:02] <niemeyer> Or perhaps "branch push"
[20:02] <niemeyer> IOW, someone pushes changes, a URL is POSTed to
[20:02] <niemeyer> ?
[20:18] <lifeless> niemeyer: I want us to support pubsubhubbub across the system
[20:18] <lifeless> niemeyer: I don't know if that would do what you want?
[20:29] <niemeyer> lifeless: Hmmm, yeah, I think that would do it!
[20:33] <Ramindu> hello
[20:33] <lifeless> niemeyer: cool; its a fair way off, because we're still catching up on our tech debt (like performance)
[20:33] <Ramindu> is there anyone here who could help me with some LP translation questions?
[20:33] <lifeless> niemeyer: but I talk about it anytome someone mentioned events or hooks to me ;)
[20:34] <lifeless> Ramindu: just ask, I'm sure someone will know
[20:35] <Ramindu> I'm trying to implement a methodology where symbolic strings, e.g. _t('SEARCH_NAME') will get replaced by the translated string based on locale
[20:35] <Ramindu> but the help for LP translations states that only English strings can be used
[20:35] <Ramindu> is there no way to use symbolic strings and still have the LP translation system recognize them?
[20:36] <lifeless> sure
[20:36] <lifeless> I'm pretty sure though, that we won't ask english speakers to translate them on english.
[20:37] <lifeless> which would mean all your other users would reasonable translations (if they can figure out what your symbols mean), but english speaking (en_UK, en_US, en_AU, en_NZ) wouldn't.
[20:37] <lifeless> what you describe was one of the original intents of gettext, but its fallen out of practice
[20:38] <Ramindu> lifeless: thanks
[20:39] <Ramindu> so what would get displayed for translators would be the symbolic string, right?
[20:39] <lifeless> yes
[20:39] <lifeless> and no instructions on what its intent is !
[20:43] <niemeyer> lifeless: Sounds good :)
[20:44] <niemeyer> lifeless: It'd be nice to be able to know when different branches are pushed, so I'm not sure it's a perfect fit.  It'd depend on what a "feed" is
[20:47] <lifeless> indeed
[20:47] <lifeless> my idea is to make every object in lp have a length-one rss/atom feed
[20:47] <Ramindu> lifeless:thanks for the help
[20:47] <lifeless> with, like the json representations, mechanical serialisation of the visible objects and sensible related links
[20:48] <lifeless> Ramindu: sorry I couldn't be more helpful
[20:48] <Ramindu> I'm wondering about asking LP to take the EN_US.pot file
[20:48] <Ramindu> and create a mapping between the created *.po files
[20:49] <Ramindu> anyway, thanks a lot for you time
[20:49] <Ramindu> bye
[20:49] <lifeless> niemeyer: that length-one feed would let you create a subscription to any individual branch, and the existing collection-scoped feeds would let you detect new branches
[20:50] <lifeless> niemeyer: and if it would be useful to folk we could also create a historical feed for the branch (e.g. containing commits, or metadata changes, $whatever)
[20:51] <niemeyer> lifeless: Cool, sounds pretty nice
[20:51] <lifeless> first though, lp needs to get 100% faster :)
[20:52] <lifeless> our 99th percentile for backend renders is now 2s
[20:52] <lifeless> need to get it to 1s
[20:52] <niemeyer> lifeless: The model used here is pretty attractive: www.pubnub.com
[20:53] <niemeyer> lifeless: Might be worth some debate before settling on pshb
[20:53] <lifeless> I *love* their page layout
[20:53] <lifeless> thats awesome
[21:03] <lifeless> niemeyer: hmm, I like the level of glue it offers straight out of the box
[21:03] <niemeyer> lifeless: Yeah, it feels very comfortable/easy to deal with
[21:03] <lifeless> niemeyer: pretty awesome too, for public content
[21:03] <lifeless> niemeyer: OTOH, it requires their proprietary service
[21:03] <niemeyer> lifeless: Well, I'm not suggesting we should use it
[21:03] <lifeless> niemeyer: and that doesn't sit well with us
[21:03] <niemeyer> lifeless: Just the model
[21:03] <lifeless> (because we have private content)
[21:04] <niemeyer> lifeless: Feels very easy to have an in-house purpose-specific service with the same interface
[21:05] <niemeyer> lifeless: And not Launchpad specific!
[21:06] <lifeless> niemeyer: possibly... probably more development though (and pshb wouldn't be lp specific either)
[21:07] <niemeyer> lifeless: Sure.. it's a pretty different beast, though
[21:08] <lifeless> niemeyer: indeed, quite different use cases
[21:08] <lifeless> I could see using both in fact
[21:08] <lifeless> in some ways I like the anonymity of messages in the pubnub system
[21:09] <lifeless> much lighterweight than needing a url, which is heavierweight
[21:09] <niemeyer> It's also more useful for building UIs on top of..  feels like a pretty good general tool to have at hand.
[21:10] <lifeless> niemeyer: how similar is it to the thing you built in ls ?
[21:10] <lifeless> (in terms of model, ease of use, flexability)
[21:12] <niemeyer> lifeless: It's a bit orthogonal.. there's a very tight relation between the web page being viewed and the server state
[21:12] <niemeyer> lifeless: Landscape's system is awesome for updating UIs
[21:12] <niemeyer> lifeless: In a secure/fast way
[21:12] <niemeyer> lifeless: Not so much as a generic pubsub
[21:38] <Ampelbein> heya, for the buildjob http://pad.lv/bld/2433780 I can't access the corresponding logfile. The build was successful locally but apparently failed on LP and I wanted to know  why.
[21:49] <maxb> Could be that something went wrong with the builder, so no log was stored, perhaps? Probably best to wait for the amd64 build to happen, and if that succeeds, get the i386 one retried
[21:53] <ScottK> wgrant or lamont: I take it something 'bad' happened to the build farm?
[22:00] <lifeless> ScottK: there was a massive problem yesterday
[22:00] <ScottK> lifeless: Sure looks like one now too https://launchpad.net/builders
[22:01] <ScottK> And a couple of multi-hour KDE on armel builds that were ~almost done are now restarted.
[22:02] <lifeless> darn
[22:05] <lamont> gar
[22:06] <ScottK> Enjoy.
[22:08] <lamont> ScottK: that apparently was compliments of one of our ISPs (by some path)
[22:08] <lamont> time to go have fun with builders
[22:09] <lifeless> oh right
[22:09] <lifeless> we had cross-DC comms issues
[22:09] <lifeless> took LP down for about 20 seconds
[22:09] <ScottK> It would be nice if that didn't cause a 12 hour build job to die and have to start over.
[22:10] <lamont> ScottK: that's the best part of my pain... it didn't cause it to die.  it just caused it to start over, and I get to go kill it
[22:10] <ScottK> Sigh.
[22:11] <ScottK> Too bad just lettting it finish wouldn't work.
[22:11] <lamont> +6
[22:14] <lamont> how conveninent... all of the non-arm non-virtual builders were basically idle
[22:29] <reviczky> hi, i have a question about ppa's, im have a package that gets some images from the web during build-time, but it appears that the ppa build doesnt provide access to the internet, is that so?
[22:30] <lamont> very much so
[22:30] <lamont> there is no internet activity from the ppa builders
[22:30] <lamont> s/activity/access/
[22:30] <reviczky> i see, so i have to patch it and download it beforehand ...
[22:31] <lamont> yeah - it has to at least be in a ppa in launchpad
[22:32] <reviczky> right, thanks for the info