[00:37] <cody-somerville> Running make results in the following error:
[00:37] <cody-somerville> Error: Couldn't find a distribution for 'lazr.restful==0.9.17'.
[00:37] <cody-somerville> any clues?
[00:38] <mwhudson> cody-somerville: bzr update download-cache maybe?
[00:38] <cody-somerville> I was just going to try that
[00:39] <cody-somerville> mwhudson, thanks. That seems to have fixed it.
[00:40] <mwhudson> rocketfuel-get will do that for you
[00:40] <mwhudson> (but i don't use that)
[00:40] <cody-somerville> I don't use it either
[00:41] <mwhudson> i'm sure some people do :)
[00:46] <maxb> Has anyone floated the idea of making "Policy:  You must be a team member to subscribe to the team mailing list. " configurable in the past?
[00:48] <thumper> cody-somerville: I have a simple bash script I use for updating stuff
[00:48] <thumper> cody-somerville: involves cd and bzr pull :)
[00:49] <maxb> ditto :-)
[00:49] <maxb> rocketfuel-* is mostly too magic for my liking
[00:52] <thumper> maxb: my thoughts exactly
[00:52] <thumper> I prefer a simpler magic
[00:52] <cody-somerville> I want to interact with an object in launchpad via python shell. Whats the easiest way to go about that?
[00:53] <mwhudson> cody-somerville: launchpadlib isn't too bad for interactive use
[00:54]  * thumper agrees with mwhudson
[00:54] <cody-somerville> this function isn't exposed via the API
[00:54] <mwhudson> cody-somerville: submit a patch :-)
[00:55] <cody-somerville> nor should it be exposed <g>
[00:55] <cody-somerville> or maybe it could be
[00:57] <maxb> getting launchpadlib going in a python shell is harder than it needs to be
[00:57] <maxb> unless there are helpers that I'm unaware of
[00:58] <maxb> bug 425856. I solicit comments :-)
[00:58] <mup> Bug #425856: non-team members cannot subscribe to launchpad/team mailing list <Launchpad itself:New> <https://launchpad.net/bugs/425856>
[00:58] <mwhudson> maxb: getting going is a bit of a pita yes
[00:58] <cody-somerville> mwhudson, thumper: basically, I want to cal an SQL helper method to see what the result is
[00:58] <mwhudson> cody-somerville: the correct interface for that is "a losa" i think?
[00:58] <mwhudson> if you can run an irc client in you python terminal, that might work :)
[00:59] <mwhudson> cody-somerville: or do you mean locally?
[00:59] <spm> SELECT CAN HAZ CHEEZEBURGER FROM GREASYS
[00:59] <cody-somerville> :)
[00:59] <cody-somerville> mwhudson, locally
[00:59] <wgrant> cody-somerville: 'make harness'
[00:59] <mwhudson> yes, make harness
[00:59] <cody-somerville> can I do that when launchpad is running?
[01:00] <mwhudson> yep
[01:03] <cody-somerville> thanks
[01:03] <cody-somerville> Now, whats the easiest way to get the object for a particular bug filed against a source package in a distribution?
[01:04] <thumper> cody-somerville: using its number
[01:04] <cody-somerville> Is there some zope magic I invoke against the interface or some helper function?
[01:05]  * thumper looks
[01:05] <thumper> getUtility(IBugSet).get(number)
[01:07] <cody-somerville> thanks
[01:07] <cody-somerville> I suppose I should refer to the doctests
[01:07] <cody-somerville> lots of good examples there
[01:08] <mwhudson> well
[01:08] <mwhudson> lots of examples, at least
[01:10]  * ajmitch saw some lovely doctests in thumper's talk :)
[01:10] <thumper> I didn't read the doctests for that
[01:10] <thumper> I went to lib/lp/bugs/interfaces/bug.py
[01:10] <ajmitch> oh it was in the testing discussion, wasn't it?
[01:10] <thumper> heh
[01:11] <ajmitch> you showed off branch.txt
[01:11] <jml> :(
[01:12] <thumper> jml: it was an example of a bad doctest
[01:12] <jml> good good :)
[01:12] <ajmitch> jml: don't worry, he didn't say it was all crap
[01:13] <mwhudson> branch.txt is very largely crap
[01:13] <ajmitch> thumper: where can I read about the factory stuff you mentioned earlier?
[01:13] <thumper> ajmitch: look at any tests in the lp.code area
[01:13] <thumper> ajmitch: or look in lp.testing.factory
[01:13] <thumper> ajmitch: we tend to use TestCaseWithFactory from lp.testing
[01:13] <ajmitch> ok, thanks
[01:14] <thumper> ajmitch: if you are using a doctest, there is a factory glob object
[01:14] <jml> factories are cool
[01:14] <jml> but
[01:14] <jml> ours is really slow
[01:14] <jml> and it ought to have tests of its own
[01:15] <ajmitch> lp.testing.factory does look rather large to wade through
[01:20] <jml> thumper, you know what would be great
[01:20] <thumper> jml: unlimited cosmic power?
[01:20] <jml> thumper, being able to see all the trunk branches I have commit access to
[01:27] <jml> thumper, what do you think?
[01:27] <thumper> jml: useful for some people
[01:28] <thumper> jml: what is your main use case?
[01:28] <jml> thumper, I want to find my projects.
[01:28] <jml> thumper, I have quite a few of them now.
[01:28] <thumper> jml: I'd much rather have a way to personally associate myself with a project
[01:28] <thumper> jml: that is of more interest to more people
[01:29] <jml> thumper, I don't get it. You want to enter even more data?
[01:29] <thumper> yes
[01:29] <thumper> if
[01:29] <thumper> I can have a page that just shows me about projects I care about
[01:29] <thumper> kinda like a "follow" this project
[01:30] <jml> hmm
[01:30] <jml> I think I'd still want to be able to see the projects I have commit rights to
[01:31] <cody-somerville> wgrant, where is the configuration for lucile kept at?
[01:31] <wgrant> cody-somerville: Which bit?
[01:32] <cody-somerville> publisher
[01:32] <wgrant> Some in the DB, some in configs/development/launchpad-lazr.conf, some in configs/schema-lazr.conf
[01:33] <wgrant> And the occasional bit hardcoded.
[01:33] <wgrant> https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally is my documentation on setting the whole thing up.
[01:34] <thumper> jml: where would you put the link?
[01:34] <jml> thumper, why not make it part of the personal code page
[01:35] <thumper> could do...
[01:35] <thumper> patches accepted
[01:35] <ajmitch> jml: I suppose that you could have write access to quite a few projects indirectly through teams?
[01:35] <jml> ajmitch, yes.
[01:35] <jml> thumper, I'm actually still waiting on a chance to get my other patches landed.
[01:38] <jml> thumper, can you please review upload-permission-joy?
[01:43] <jml> how do I expose a function over the API that takes a list of URLs as a parameter?
[01:45] <thumper> rockstar: how do I assert that an xpath doesn't exist in a windmill test?
[01:51] <Ursinha> hey wgrant :)
[01:51] <wgrant> Hi Ursinha.
[01:55] <Ursinha> my lp setup still wants to use the 0.9.9 version of lazr.restfulclient when I have the 0.9.10 inside the download-cache folder
[01:55] <Ursinha> what do I have to do to lp use the newest?
[01:55] <wgrant> Merge from devel.
[01:56] <wgrant> (or alter versions.cfg manually)
[01:58] <Ursinha> thanks wgrant :) I'd like to know which file defined that
[01:58] <wgrant> You might also have to run bin/buildout again, I guess.
[01:58] <jml> yay
[01:59] <MTecknology> Where's the bestest best best place to get help on LP API; right here?
[02:03] <thumper> MTecknology: yep
[02:04] <MTecknology> thumper: How do I get my hands on it so I can use it? I feel like I'm about to dive into a sea of sharks with this but my company wants two of us to learn all we can about it
[02:05] <thumper> MTecknology: to what end?
[02:06] <MTecknology> One reason is because we want to modify some core tools we use to utilize the openid+login process of Launchpad so the use of LP is entirely transparent to the user. We're also looking into our own server to host the LP server
[02:07] <MTecknology> If we can get that, then we're looking into using it for a support ticket system and other things
[02:08] <thumper> MTecknology: the project is launchpadlib, and I believe it has good docs
[02:08] <jml> next question
[02:09] <jml> how can I expose a method that returns a dict?
[02:09] <jml> mapping URLs to IBranch
[02:09] <wgrant> jml: Give up, I'm afraid :(
[02:09] <jml> wgrant, that sucks.
[02:09] <wgrant> It does.
[02:09] <jml> wgrant, I guess a list will work ok in this context though.
[02:10] <wgrant> You can return a dict, but launchpadlib will just see it as a dict of URLs to URLs.
[02:12] <MTecknology> thumper: thanks. I was trying to figure out how we could do everything that's being planned and it hit me that Launchpad can handle every piece of that
[02:13] <wgrant> MTecknology: I don't see what the LP API has to do with this.
[02:13] <thumper> jml: I think leonard is working on exposing a dict over ReST
[02:13] <jml> thumper, that's good.
[02:14]  * thumper throws hands in the air
[02:14] <thumper> how can XPath have "and" and "or" but not "not"?
[02:15] <MTecknology> wgrant: I don't really understand what the api is; but I was told to get it so we can see if it will help us
[02:17] <jml> MTecknology, https://help.launchpad.net/API
[02:18] <jml> kfogel, hi
[02:19] <kfogel> jml: hey
[02:20] <jml> kfogel, how's things?
[02:21] <kfogel> jml: well, I discovered halfway through the day that today was a U.S. holiday, that was interesting :-).  How's the sprint going?
[02:21] <jml> kfogel, good.
[02:21] <jml> kfogel, less coding than I had hoped, but probably the better for it.
[02:22] <kfogel> jml: ah, too bad, but that's what happens when you know too much
[02:23] <poolie> hello
[02:23] <poolie> nice reply there kfogel
[02:24] <poolie> it's thanksgiving isn't it?
[02:25] <kfogel> poolie: thanks.  I was wondering if it was too harsh; glad you didn't find it so.  It's not Thanksgiving yet, btw, but it is Veterans Day in the US.
[02:25] <thumper> poolie: veterans day
[02:25] <poolie> oh right
[02:25] <thumper> thanksgiving is in two weeks
[02:26] <poolie> armistice day is observed here but not a holiday
[02:26]  * kfogel is glad the whole world knows US holidays, and wonders if it has something to do with all our missiles
[02:27] <Ursinha> lol
[02:27] <Ursinha> jml, do you know which commit message ec2 script considers when using the land command?
[02:27] <jml> Ursinha, the one on the merge proposal page
[02:27] <thumper> kfogel: no, just approved rockstar's holidays, that's all
[02:27] <jml> Ursinha, you can provide one as an option to ec2 land
[02:28] <kfogel> thumper: heh
[02:28] <thumper> Ursinha: but don't add all the [xx] rubbish to that commit message :)
[02:28] <Ursinha> thumper, oops, why?
[02:28] <thumper> Ursinha: because the land commands adds them
[02:28] <thumper> Ursinha: based on who reviews/approves, bugs et al.
[02:28] <Ursinha> thumper, makes sense
[02:29] <jml> Ursinha, --dry-run ftw
[02:29] <Ursinha> jml, :)
[02:29] <maxb> Speaking of the [xx] rubbish, is there a reference to what it all means anywhere?
[02:29] <jml> maxb, if it's not on the dev wiki, then probably not.
[02:29] <jml> maxb, the source code for ec2 land might actually have pointers to docs :)
[02:30] <maxb> not that I've been able to find
[02:30] <wgrant> The only one that was unobvious to me was rs.
[02:30] <jml> maxb, in that case, I won't be able to help you find docs, since I looked for docs when I wrote land :)
[02:31] <maxb> Well, yeah, I think I've figured most of them out by example by now. But [!log] still mystifies me (seen in some sourcecode branch I forget which)
[02:32] <jml> maxb, don't include it in the news announcement for the release.
[02:32] <jml> maxb, we used to use it to make preparing announcements easier. We don't any more.
[02:43] <kfogel> poolie: nice response -- I didn't mean to guilt-trip you, though! :-)
[02:43] <poolie> not at all
[02:43] <jml> I am feeling unhappy
[02:43] <jml> and it is because of software
[02:43] <jml> again
[02:44] <jml> If I return a list of branches over the API, but some of those branches are None, then the 'None' objects don't appear in the list.
[02:48] <jml> AFAICT, this means that helper methods like IBranchSet.getByUrls are impossible
[02:53] <thumper> jml: and there isn't a map?
[02:53] <jml> thumper, there isn't.
[02:55] <jml> I'm going to have to think of a different example for my UDS session.
[02:56] <kfogel> jml: is there no way to match up the returned branches to the URL(s) originally requested?
[02:56] <jml> kfogel, not easily.
[02:56] <jml> kfogel, there are multiple attributes on branch that the URL might be matched on.
[02:57] <kfogel> jml: oh
[02:57] <jml> and some that aren't even attributes
[02:59] <jml> although matching against the returned bzr_identity, then matching against the returned branch.url and then falling back to matching the returned unique_name against the requested URL path would _probably_ get you most of the way there
[03:00] <jml> https://bugs.edge.launchpad.net/lazr.restful/+bug/481090
[03:00] <mup> Bug #481090: Cannot define a method that returns a dict <lazr.restful:New> <https://launchpad.net/bugs/481090>
[03:20]  * thumper ndos
[03:23] <PingJocky> good evening
[03:37] <thumper> afternoon :)
[03:54] <MTecknology> Can the LP API allow users to manage teams/users if the person using the API has that permission?
[03:54] <MTecknology> I know the API is used to pull info, not if it can pushing or altering
[03:56] <MTecknology> nevermind - I guess if I pay attention the first page kinda says I can do that
[03:59] <maxb> and the api documentation says exactly what can be done
[04:00] <MTecknology> maxb: I'm still looking aroudn for that. I don't refer to documentation much so reading through it is hard work for mew
[04:03] <maxb> https://launchpad.net/+apidoc/
[04:20] <MTecknology> maxb: :D
[04:21] <MTecknology> thanks
[06:26] <jml> hey, people here know stuff
[06:26] <jml> I'm trying to prepare a USB stick for UDS that I can use to accelerate people having a Launchpad development environment
[06:27] <jml> my plan is to set up a minimal chroot, run rocketfuel-setup, make sure everything works, and then whack it all in a tarball
[06:27] <jml> does that sound sane?
[06:27] <wgrant> Awesome idea.
[06:29] <wgrant> As long as you rerun rocketfuel-setup at the other end, that does sound sane.
[06:29] <jml> well, I'm also not 100% clear on what people on the other end will need to do to get the chroot.
[06:30] <wgrant> Oh, you're going to copy the entire chroot? Hmm.
[06:30] <jml> that was my original plan
[06:30] <wgrant> That'll run into postgres port conflicts and other mess if they already have postgres installed.
[06:30] <jml> oh yeah
[06:30] <wgrant> Better to make rocketfuel-setup make less of a mess, so you don't really need a chroot.
[06:31] <jml> wgrant, I'm not going to have time to do that before UDS :)
[06:31] <wgrant> Plus even if you do have a chroot, you still need to modify /etc/hosts outside the chroot.
[06:31] <jml> so maybe just having the repo on a USB stick
[06:31] <wgrant> + sourcecode
[06:32] <jml> right.
[06:32] <jml> and make sure that rf-setup can be run in such a way as to respect the existing file
[06:32] <jml> s
[06:32] <wgrant> Get a clean ~/launchpad, remove devel from it, but keep a copy of rocketfuel-setup in there.
[06:32] <wgrant> It will already.
[06:33] <wgrant> If you extract the tarball into ~/launchpad as it expects, it will Just Work Very Quickly.
[06:42] <thumper> jml: what about a vm on a stick?
[06:43] <jml> thumper, the problem is then people need to know how to get a vm set up
[06:44] <jml> thumper, it's all about taking the smallest amount of time as possible so I can get on with the rest of the session.
[06:44] <thumper> jml: people need to know how to get a chroot set up too
[06:44] <thumper> jml: just a thought
[06:44] <jml> thumper, well yeah, that's why I'm not doing it :)
[06:45] <wgrant> If you're expecting quite a few people to set it up, it might be a good idea to remove some of the crap from rf-setup this week.
[06:45] <wgrant> eg. the SSH config stuff is no longer necessary.
[06:46] <jml> wgrant, maybe
[06:46] <jml> wgrant, are there bugs filed about all of this?
[06:47] <wgrant> jml: Bug #419028
[06:47] <mup> Bug #419028: Don't edit SSH config in rocketfuel-setup <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419028>
[06:48] <jml> wgrant, know of anything else that ought to be removed / cleaned up that doesn't require much thinking?
[06:49] <wgrant> jml: I really feel that it's unnecessary to install rocketfuel-* in $PATH, but that's a slightly more destructive change.
[06:49] <jml> I agree on both counts.
[06:49] <wgrant> OTOH, it won't affect any existing installations.
[06:55] <wgrant> Apart from that, rf-setup isn't too bad.
[06:55] <wgrant> launchpad-database-setup, OTOH...
[07:06] <jml> wgrant, http://bazaar.launchpad.net/~jml/launchpad/rf-setup-cleanup/revision/9863
[07:07] <wgrant> jml: Great.
[07:07] <wgrant> That probably makes it noninteractive, too.
[07:07] <wgrant> Hm, not quite.
[07:07] <wgrant> But close enough.
[07:14]  * mwhudson_ reviewatrons
[07:17] <wgrant> Is there no link back from Loggerhead to the branch in LP?
[07:18] <wgrant> mwhudson_: Nice review comment, but your diff highlighter sucks.
[07:18] <mwhudson_> wgrant: there is a link in the top left
[07:18] <mwhudson_> wgrant: "watches pelcome" or something
[07:18] <wgrant> Ah, so there is.
[07:20] <wgrant> Oh, right, it assumes it's a header.
[08:33] <adeuring> good morning
[09:10] <mrevell> Morning
[09:15] <wgrant> bigjools: I don't see what your SourcePackageFormatSet methods do.
[09:15] <bigjools> wgrant: ok I'll explain in a moment
[09:30]  * thumper has many branches waiting for review
[09:30]  * thumper has fixed two oopses today
[09:30] <thumper> my work here is done
[09:30]  * thumper goes to wash disher
[09:31] <thumper> s/disher/dishes/
[09:31] <thumper> it's late
[09:42] <bigjools> wgrant: ok let's chat
[09:42] <bigjools> so, SourcePackageFormatSet would be a utility
[09:43] <bigjools> which is security wrapped
[09:43] <bigjools> we don't generally use __init__ methods in model classes
[09:43] <bigjools> the utility has the job of creating new instances
[09:43] <bigjools> so that it returns security-wrapped objects
[09:45] <pgquiles> I followed https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally to add builders but now I want to remove them. I've tried with "remove" instead of "add" ( scripts/ftpmaster-tools/manage-chroot.py -s lucid -a i386 remove -f chroot-ubuntu-lucid-i386.tar.bz2 ) but it does nothing. What am I doing wrong?
[09:46] <pgquiles> (sorry for repeating the question, noone answered yesterday and I haven't found a solution yet)
[09:48] <bigjools> pgquiles: that command deals with chroots, not builders
[09:48] <wgrant> bigjools: Right, yes. So it would be add(distroseries, format), and then there would be something like get(distroseries, format)?
[09:49] <wgrant> pgquiles: What did you expect it to do?
[09:49] <bigjools> wgrant: yep, pretty much, although not get(), getBySeriesAndFormat()
[09:49] <bigjools> wgrant: get() is normally used for getting by ID
[09:49] <wgrant> bigjools: Right. Thanks.
[09:49] <wgrant> bigjools: Now, what did you mean about the XXX?
[09:49] <wgrant> bigjools: There were some words omitted.
[09:50] <bigjools> wgrant: I read it back and it made sense to me, so maybe it's just my twisted English :)  Basically, I would say don't worry about it and remove the XXX
[09:50] <pgquiles> wgrant: I want to remove a builder from launchpad.dev/builders, and I want to remove a chroot because I did manage-chroot.py -s karmic -a i386 add -f chroot-ubuntu-lucid-i386.tar.bz2 (I told LP to add a Lucid chroot for a Karmic series, my bad)
[09:51] <bigjools> pgquiles: mark it as manual and it disappears
[09:51] <wgrant> bigjools: "I'm trying to think if it would be bad to reject the upload if we detect orphan files, and I can't think of one." <- one what? reason to reject, I presume.
[09:51] <bigjools> wgrant: yes
[09:51] <bigjools> wgrant: my twisted English, sorry
[09:51] <wgrant> pgquiles: You actually want to mark the build as inactive, or something like that.
[09:51] <wgrant> Not manual -- that will still show up.
[09:52] <wgrant> pgquiles: You're sure that manage-chroot.py remove does nothing?
[09:52] <wgrant> bigjools: Thanks. Fixing now.
[09:52] <wgrant> I've never had cause to remove a chroot myself.
[09:52] <pgquiles> wgrant: I don't know if it does anything but builders are still there
[09:52] <pgquiles> even worse: when I try to add a new chroot, it adds it but it does not show in LP :-/
[09:52] <wgrant> pgquiles: Chroots are not shown in LP.
[09:53] <pgquiles> wgrant: the launchpad.dev/builders/bob/+edit I mean
[09:53] <wgrant> pgquiles: That has nothing to do with any chroot.
[09:53] <pgquiles> ¿?
[09:54] <wgrant> pgquiles: A builder is it a builder. Its builds will use chroots, but it isn't directly related to them.
[09:54] <pgquiles> according to https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally you have to add a chroot, then mark Bob the Builder as OK
[09:55] <wgrant> Those steps are not related beyond both being prerequisites for a working build system.
[09:55] <bigjools> ah yes mark it as inactive to remove it from /builders
[09:56] <pgquiles> I don't understand anything :-( After I added a chroot, it was shown in the builders list and I could mark it OK and it worked fine
[09:56] <wgrant> The existing builder is shown in the builders list.
[09:56] <wgrant> Not the chroot.
[09:56] <pgquiles> what I want to do is remove a chroot (tried with 'remove' but it does nothing) and add a new chroot for jaunty (but after the 'remove' for lucid, it no longer works)
[09:57] <pgquiles> bigjools: it will not show the builder in /builders but it's still in LP, you can re-enable it again
[09:57] <pgquiles> wgrant: do you mean the builder is there but with no chroot?
[09:57] <bigjools> pgquiles: that's correct
[09:57] <pgquiles> ok, so, how do I completely remove a builder?
[09:59] <pgquiles> as in "this builder no longer has a chroot associated, I don't want it to be shown, even as inactive"
[10:01] <wgrant> Builders are not associated with chroots.
[10:01] <wgrant> You cannot completely remove a builder without removing lots of other sample data.
[10:02] <pgquiles> mmm so I add chroots to launchpad
[10:02] <pgquiles> and then I add builders
[10:02] <pgquiles> and builders will know what chroot to pick when a package needs to be built
[10:02] <pgquiles> is that it?
[10:02] <wgrant> Yes.
[10:03] <pgquiles> great :-) so builders are smarter than what I thought (and definitely smarter than I :-) )
[10:04] <pgquiles> then, to fix my bad "manage-chroot.py -s karmic -a i386 remove -f chroot-ubuntu-lucid-i386.tar.bz2", can I just run "manage-chroot.py -s lucid -a i386 remove -f chroot-ubuntu-lucid-i386.tar.bz2" and that's it?
[10:11] <wgrant> bigjools: SourcePackageFormatSet, or should it be SourcePackageFormatSelectionSet?
[10:12] <bigjools> wgrant: the latter
[10:12] <bigjools> bit of a mouthful :/
[10:12] <wgrant> There's worse.
[10:18] <pgquiles> one more question: virtualized builders. Are there any docs on how to set up one? (I can't find anything)
[10:18] <bigjools> no, there are no docs
[10:20] <pgquiles> and I guess it's not exactly easy, is it?
[10:20] <bigjools> depends on how much you know about virtualisation
[10:23] <pgquiles> I know virtualization but I've never set up Xen (which is what LP uses IIRC). Can it use something else (VMware, VBox, qemu, KVM) ?
[10:24] <bigjools> you can use what you like, it's nothing to do with LP
[10:24] <pgquiles> great
[10:24] <bigjools> exactly what are you setting up LP for?
[10:24] <pgquiles> for internal use at work
[10:25] <pgquiles> we are developing our own distribution for military use, based on kubuntu + packages for our software and backports from lucid, debian unstable and some stuff I've packaged and it's not available from debian or ubuntu
[10:26] <pgquiles> I think I'm the first one who requested to buy Launchpad for on site use but it was not available at the time (2+ years ago)
[10:27] <pgquiles> given that it's military use and our software is closed source, hosted LP commercial is not an option
[10:30] <maxb> I wonder how long it will be before enough people start wanting to rebrand launchpad that we actually end up with launchpad hosting projects/branches for a rebranding effort of itself
[10:32] <bigjools> I find someone internally using an open-source LP to host closed-source stuff extremely distasteful
[10:33] <pgquiles> bigjools: does Canonical sell a LP appliance, training, whatever? I've tried to BUY that but I was told (by Mark himself) Canonical does not sell that still
[10:33] <pgquiles> and I cannot upload military stuff to somewhere else, no matter how much security you promise
[10:34] <maxb> bigjools: why?
[10:41] <maxb> The way I see it, using Launchpad in that way takes nothing away from the Launchpad project, and might be the source of bug reports, fixes, and an interested contributor
[11:10] <pgquiles> I've fixed a missing quote in HowToUseSoyuzLocally and added the explanation on the non-association between builders and chroots, which was not obvious from reading the page
[11:11] <wgrant> It was a hasty conversion last week from a Tomboy note; I'm not surprised I missed a quote.
[11:11] <wgrant> Was the attachment change this morning just s/serieses/series/?
[11:12] <pgquiles> wgrant: yes, that was it -  maxb told me what was failing
[11:16] <pgquiles> HowToUseSoyuzLocally says I should add an external dependency on "deb http://archive.ubuntu.com/ubuntu %(series) main restricted universe multiverse" to the PPA but when I try to do that from "add dependencies" in the PPA, LP fails. Is that the right place? Is that the line I should enter in the "Add PPA dependency" text entry?
[11:16] <maxb> "# We use Hoary as the root, as Breezy and Grumpy are broken." ....... Grumpy? :-)
[11:16] <wgrant> Grumpy Groundhog
[11:16] <wgrant> The long-fabled bleeding edge daily builds Ubuntu.
[11:16] <wgrant> Which somehow made it into the sample data.
[11:24] <pgquiles> mmm one little trick in /etc/hosts and now archive.launchpad.dev goes to archive.ubuntu.com... and it's building!
[11:25] <wgrant> pgquiles: If you followed my instructions, you shouldn't need to do that.
[11:27] <pgquiles> wgrant: I followed your instructions but I don't know how to add the external dependency on archive.ubuntu.com, adding it in the "Add PPA dependencies" page in LP does not work (Zope error) :-?
[11:27] <wgrant> pgquiles: See the field at the bottom of the PPA's +admin page.
[11:28] <bigjools> wgrant: heh, so that's why you said it was handy
[11:28] <pgquiles> wgrant: ah! that was it
[11:28] <pgquiles> wgrant: I thought I should add it to the "Edit PPA dependencies" page
[11:28] <pgquiles> thanks!
[11:29] <wgrant> bigjools: Yeah, it's particularly convenient for testing primary archive stuff.
[11:29] <wgrant> bigjools: If I'm just dealing with PPAs, I just change archivepublisher.base_url to a local mirror.
[11:29] <bigjools> yeah
[11:31] <pgquiles> added to the wiki
[11:31] <wgrant> pgquiles: Note that that same thing is mentioned two steps earlier.
[11:32] <pgquiles> oops, right
[11:35] <wgrant> pgquiles: That looks better.
[11:56] <pgquiles> wgrant: sorry if this is a stupid question but, the section about "dealing with the primary archive", does it refer to a local mirror of archive.ubuntu.com (i. e. archive.launchpad.dev) ? the steps listed there, are they for adding PPA-built packages to archive.launchpad.dev?
[11:57] <wgrant> pgquiles: The primary archive is archive.launchpad.dev. But it's nothing about copying in PPA packages.
[12:00] <pgquiles> so those steps are for building the packages and adding them to archive.launchpad.dev *instead* of a PPA, is that it?
[12:00] <wgrant> Yes.
[12:01] <pgquiles> perfect, thank you
[12:01] <pgquiles> now looking into setting up virtualized builders!
[12:06] <wgrant> bigjools: Want an intermediate diff?
[12:06] <bigjools> wgrant: yes please
[12:06] <pgquiles> wgrant: btw, /var/tmp/zeca is not created in the by rocketfuel_setup/start_soyuz.sh/whatever
[12:07] <wgrant> pgquiles: Ah, yes, forgot about that.
[12:32] <wgrant> bigjools: What do you think about running "UPDATE sourcepackagerelease SET dsc_format='1.0' WHERE dsc_format IS NULL"? No new broken SPRs have been created since 2006, so it should be a safe one-off fix.
[13:54] <bigjools> wgrant: yes, sounds sane
[14:45] <matsubara> Chex, gary_poster, rockstar, bigjools, danilos, citrus, allenap: LP production meeting in 15 min @ #launchpad-meeting
[14:47] <gary_poster> danilos: do we have team lead call in 15, as Google lists?
[14:51] <danilos> gary_poster, no, as per email yesterday
[14:51] <danilos> matsubara, thanks
[14:51] <gary_poster> danilos: oh, must have missed it in the email swamp.  Looking...
[14:56] <gary_poster> found, and thanks
[16:45] <sinzui> salgado:  ping
[16:45] <salgado> hi sinzui
[16:46] <sinzui> salgado:  I am working on bug 471770. There is a conflict between AdminMergeBaseView.doMerge() which sets the dup email address to NEW and PersonSert._mergeMailingListSubscriptions which moves the subscription (with a NEW email) to the new acount
[16:46] <mup> Bug #471770: mailing list subscription email address are in NEW status <oops> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/471770>
[16:47] <sinzui> salgado: I think I should change PersonSert._mergeMailingListSubscriptions to remove all the subscriptions and send an email to the user that he has to re-validate his address *and* resubscribe...
[16:49] <sinzui> salgado: but maybe I should change the subscriptions to the preferred email address, or ensure that the the affect email addresses are VALIDATED
[16:55] <pgquiles> wgrant: ping
[17:14] <salgado> sinzui, I think I'd rather remove the subscriptions and send out emails for the user to re-validate the address and subscribe
[17:15] <sinzui> salgado: thank you. That is what I will do.
[17:58] <mrevell> night all
[18:29] <Ursinha> gmb, ping
[20:28] <thumper> any one around who can review?
[20:28]  * thumper needs some reviewers
[21:38] <wgrant> pgquiles: Hi.
[22:07] <pgquiles> wgrant: hey. I was wondering why the instructions to use Soyuz locally tell you to download a pre-built bootstrap (with all the steps and guessings that involves) instead of telling how to build a bootstrap of your own with debootstrap
[22:07] <pgquiles> in the meanwhile, I've added how to use debootstrap to the wiki
[22:07] <pgquiles> is there anything special in the bootstraps from launchpadlibrarian.net ?
[22:11] <wgrant> pgquiles: The production chroots have various modifications (see /root/bootstrap), and it's so much quicker and easier.
[22:11] <wgrant> Plus it is better at convincing me that my full stack changes will work in production.
[22:36] <pgquiles> wgrant: mmm I see. So, how are the chroots from launchpadlibrarian.net generated? debootstrap + manual steps?
[22:45] <wgrant> pgquiles: I presume debootstrap + copy in that bootstrap script + run that bootstrap script.
[22:45] <wgrant> But I don't exactly know.
[22:47] <pgquiles> wgrant: should I ask in the mailing list?
[22:48] <wgrant> pgquiles: Launchpad developers will not know. It's not really a Launchpad question.
[22:48] <pgquiles> oh
[22:48] <pgquiles> who can I ask?
[23:11] <maxb> pgquiles: lamont. I'd be interested in the answer.
[23:12] <pgquiles> maxb: is he/she on IRC usually (meaning: tomorrow) ? or should I ask by e-mail?
[23:13] <maxb> He's certainly sometimes on IRC. LP says he's America/Denver TZ. But for a complex question, email might be best
[23:13] <pgquiles> perfect, thanks
[23:14] <rockstar> maxb, I think he's EOD'd already.
[23:15] <pgquiles> maxb: he's on #debian-devel at OFTC
[23:15] <pgquiles> EOD?
[23:15] <rockstar> End of day.
[23:15] <pgquiles> oh
[23:15] <maxb> pgquiles: and also on a variety of #ubuntu-* on freenode
[23:15] <pgquiles> I was thinking Esoteric Order of Dragon
[23:15] <pgquiles> :-)
[23:17] <pgquiles> off to bed, it's late here
[23:17] <pgquiles> thank you all, see you tomorrow!