[00:03] <maxb> why do we even *have* time-based rescoring?
[00:03] <maxb> It seems a rather pointless concept given the queues are mostly FIFO anyway
[00:04] <cody-somerville> maxb, they're not FIFO at all
[00:05] <wgrant> The order seems to be based on (score, id)
[00:05] <wgrant> So apart from score, they are FIFO.
[00:05] <wgrant> And most builds have the same score.
[00:05] <maxb> ok, that was an oversimplification. But the increments added by the time-based rescorer are smaller than most of the other score-determining factors
[00:06] <wgrant> (except for a few which differ slightly on the distro builders, and private PPAs will get a 10000 point bonus)
[00:06] <cody-somerville> I don't think anyone disagrees that scoring needs work
[00:06] <bigjools> right, the small increments don't make enough of a difference to change the order
[00:09] <cody-somerville> it also stops making a difference after 4 hours of waiting
[00:10] <wgrant> The entire build dispatch algorithm needs to be redone. Trying to fix scores is unlikely to do anything.
[00:15]  * mwhudson lunches (and is setting up a new modem so will be mostly offline)
[00:21] <thumper> mwhudson: ping
[00:41] <wgrant> Hmm, interesting.
[00:41] <wgrant> I cannot access +index of some projects. I suspect this is because the development focus branch is private.
[00:42] <thumper> ??
[00:42] <thumper> arse
[00:42] <thumper> wgrant: can you please give me an example?
[00:42] <thumper> wgrant: and file a bug?
[00:42] <thumper> wgrant: I'll fix asap
[00:42] <wgrant> thumper: eg. https://launchpad.net/landscape. I don't have an OOPS code.
[00:42] <wgrant> I will file a bug.
[00:42] <wgrant> thumper: Registry or Code?
[00:42] <thumper> code
[00:45] <wgrant> thumper: Bug #484533
[00:45] <mup> Bug #484533: Cannot access index for project with private development focus branch <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/484533>
[00:45] <thumper> wgrant: thanks
[01:24] <mwhudson> well that was exciting
[01:24] <mwhudson> plug in new modem, doesn't work, plug in old modem, doesn't work
[01:24] <thumper> mwhudson: what's that?
[01:24] <mwhudson> phone isp tech support
[01:24] <thumper> :(
[01:25] <mwhudson> "it seems your account was suspended because of reports of spam last week"
[01:25] <mwhudson> !!!!
[01:25] <wgrant> Ouch.
[01:26] <thumper> mwhudson: so now you have in the new modem?
[01:26] <mwhudson> thumper: no, still the old
[01:27] <mwhudson> and indeed, using 32 gigs of traffic in the first 18 days of the month is a bit unusual
[01:27] <thumper> oh
[01:27]  * thumper stabs windmill
[01:27] <thumper> my windmill tests are failing to use the api!!!
[01:29] <thumper> oh FFS
[01:30]  * thumper frowns
[01:31]  * thumper frowns more
[01:31] <thumper> AppServerLayer not tearing down
[01:31] <thumper> stabby stabby
[01:31]  * ajmitch steps away from the knives
[01:32] <mwhudson> after all that
[01:32] <mwhudson> lunch, finally
[01:42] <thumper> ✁☹
[01:43] <wgrant> thumper: Windmill still killing you(ll)?
[01:43] <thumper> yes
[01:43] <thumper> works locally, but not in windmill
[01:52] <bac> jml: yes, i've seen those import violations today since going to 2.5
[03:39] <thumper> recipe would live at https://launchpad.net/ubuntu/karmic/+source/some-package/+recipe/recipe-name
[03:45] <Ursinha> hey stub, when you return, can we chat a bit?
[03:46] <stub> I'm here
[03:47] <lifeless> thumper: no team/person in there ?
[03:48] <thumper> lifeless: not in the url
[03:48] <thumper> lifeless: but on the object, yes
[03:49] <thumper> lifeless: do you think it is really needed?
[03:49] <lifeless> I don't know
[03:49] <mwhudson> hooray
[03:50] <stub> Ursinha: ^^
[03:51] <Ursinha> hi stub
[03:52] <Ursinha> stub, what should I do after you approve my db-patch and give me a patch number?
[03:53] <stub> If I and jml have both approved it, you need to land it on lp:~launchpad-pqm/launchpad/db-devel (with the correct patch number if you haven't changed that on your branch yet).
[03:53] <Ursinha> stub, but should I change from pending folder or just rename it?
[03:53] <stub> Ursinha: ^^
[03:53] <Ursinha> (and  change the line inside of the patch to contain the correct number)
[03:53] <stub> Oh - it needs to be in database/schema.
[03:54] <stub> Most people keep them in there - pending tends to only be used by me.
[03:54] <Ursinha> stub, anything else?
[03:54] <stub> Nup. If the tests pass its fine.
[03:56] <wgrant> stub: If I want to get some production data trivially fixed, how do I go about it?
[03:56] <Ursinha> stub, I did what you said, and I'm getting this: https://pastebin.canonical.com/24833/
[03:56] <wgrant> Get the query approved by the appropriate team and you?
[03:56] <Ursinha> stub, what am I doing wrong?
[03:58] <stub> wgrant: Sounds good. If it is really trivial I can just do it.
[03:59] <stub> Ursinha: The last statement of the DB patch should be "INSERT INTO LaunchpadDatabaseRevision VALUES (2207, 10, 0);".
[03:59] <Ursinha> stub, I've changed that
[04:00] <stub> Ursinha: Please pastebin the db patch
[04:00] <wgrant> stub: There are some thousands of old sourcepackagereleases with a null dsc_format. None of these have been created since 2006. Until now, only the '1.0' format has been accepted, so all the old SPRs should have their dsc_format set to that.
[04:01] <Ursinha> stub, it's in the other computer, a minute
[04:01] <stub> wgrant: I recall that. Sounds fine to me but this one I'd want soyuz team to agree too, just in case there is some need to differentiate records made before the code that added that field landed.
[04:02] <stub> Which is a stretch, but better safe than fired.
[04:02] <wgrant> stub: Indeed. bigjools seemed happy with it last week, but I will get more concrete approval this evening.
[04:02] <wgrant> Thanks.
[04:03] <stub> We also need a bug opened to set the column NOT NULL and targetted to this cycle.
[04:03] <wgrant> Shall I prepare and get landed a DB patch for that?
[04:04] <ursula> stub, http://paste.ubuntu.com/321244/
[04:04] <stub> wgrant: If you want, or I can just append it to my pending db stuff branch.
[04:04] <wgrant> stub: That would be handy. Filing a bug now.
[04:07] <wgrant> stub: bug #484602
[04:07] <mup> Bug #484602: SourcePackageRelease.dsc_format should be NOT NULL <Soyuz:New> <https://launchpad.net/bugs/484602>
[04:07] <wgrant> stub: I cannot target or anything.
[04:08] <stub> I've got it
[04:25]  * mwhudson afk for a few minutes
[05:36] <mwhudson> is there a word for "tree that you could plausibly try to run debuild in" ?
[05:36] <mwhudson> i.e. source tree, debian/ dir etc
[05:36] <lifeless> source tree
[05:36] <lifeless> no, you don't run it in the debian dir, rather in the top dir
[05:36] <lifeless> you could coin a word
[05:36] <lifeless> debianized source tree
[05:37] <lifeless> is probably what folk would understand
[05:37] <mwhudson> "debianized source tree" works
[05:37] <wgrant> '[unpacked] source package' is my usual term.
[05:37] <wgrant> But I like 'debianized source tree'
[05:37] <mwhudson>  Results 1 - 10 of about 11,800 for "debianized source tree".
[05:37] <spm> debianised perhaps?
[05:37] <lifeless> spm: sadly no, I'm not making this up :)
[05:37] <lifeless> spm: or I would have used an s
[05:37] <mwhudson> spm: "debian" CERTAINLY did not arrive in the english language via french
[05:38] <lifeless> mwhudson: but did deborah and ian ?
[05:38] <spm> I knew I should have put the evil/ironic smiley in.... ;-)
[05:38] <mwhudson> lifeless: deborah doesn't sound like it does it?
[05:38] <mwhudson> ian i guess might have done
[05:41] <mwhudson> hah, debian policy says debianised
[05:41] <spm> *snort*
[05:41]  * spm is reminded of the wikipedia rules on UK vs USA spelling :-D
[05:44] <spiv> mwhudson: well, if it's *policy* then you have no choice...
[05:44] <mwhudson> i think i shall alternate between the two in this mail and see how well that troll works
[05:44] <spiv> mwhudson: pick a middle ground: "debianiced"
[05:45] <mwhudson> spiv: that's a strange middle you're standing on
[05:45] <spiv> mwhudson: it's the sort of middle that makes no-one happy!
[05:45] <mwhudson> debianated
[05:46] <mwhudson> debianorized
[05:46] <spiv> debianificated
[05:46] <mwhudson> endebianned
[05:47] <spm> mwhudson: bigendebianned ???
[05:48] <mwhudson> spm: that's clearly much too silly
[05:48] <spm> sorry
[05:48] <spm> will aim for a more moderate level of silliness next time
[05:49] <spm> 0xdebianised ??
[05:49] <mwhudson> spiv, lifeless: are you guys on launchpad-dev?
[05:50] <spiv> You mean this channel?
[05:50] <lifeless> mwhudson: are you human?
[05:50] <mwhudson> spiv: no, the mailing list?
[05:50] <lifeless> I think I am
[05:50] <spiv> Probably.  I certainly get lots of mail about Launchpad...
[05:50] <lifeless> is there something we should have seen and replied to?
[05:51] <mwhudson> lifeless: the mail i'm about to send
[05:51] <lifeless> my advice is that if you want $foo to see mail, CC them always.
[05:51] <lifeless> on-a-list doesn't guarantee 'pay attention'
[05:52] <mwhudson> yeah, i was thinking that
[05:56] <spm> jtv: heyo! can I draw your attention to https://answers.edge.launchpad.net/rosetta/+question/89602 pls. Is this (1) a sane request and (2) If Y, how? :-)
[05:56] <jtv> spm: looking...
[05:56] <spm> ta
[05:57] <jtv> It sounds like there was some mistake... pt and pt_BR are different enough that we treat them as separate languages.
[05:58] <jtv> It's pretty exceptional for us to do that; the differences between country variants of Spanish can be pretty huge but people manage to keep those translations unified.  From that I infer that it really couldn't be done for pt and pt_BR.
[05:59] <jtv> spm: I'll follow up.  I've had a fair amount of interaction with these people.
[05:59] <spm> jtv: ta
[06:01] <spm> jtv: fwiw, from ex-brazilians I've worked with in previous jobs (vs the wonderful Brazilians I work with now! ;-) ) They speak in quite ... derrogatory terms of pt vs pt_BR :-)
[06:01] <mwhudson> my limited understanding was that they're basically different languages
[06:02] <jtv> spm: to make sure I follow... they hate pt, right, not the distinction of pt vs pt_BR?
[06:02] <spm> the descriptive analogy I got was pt to pt_BR is like 12th century english to modern english.
[06:02] <spm> jtv: exactly.
[06:03] <jtv> They may have gotten pt translations imported as pt_BR by accident, or vice versa.
[06:16] <mwhudson> spiv, lifeless: mail sent fwiw
[06:17] <spiv> mwhudson: ta, will take a look
[06:26] <wgrant> mwhudson: Does anybody have any idea at all how private branches are going to be done?
[06:26] <mwhudson> wgrant: you don't mean private branches there do you?
[06:26] <mwhudson> wgrant: but i don't think so, no
[06:27] <wgrant> mwhudson: I mean BFB from private branches.
[06:27] <mwhudson> wgrant: ah
[06:27] <mwhudson> wgrant: then no
[06:27] <mwhudson> i guess it'
[06:28] <wgrant> The only possibility that is obvious to me is to have them served over internal HTTPS, and have buildd-manager grant and revoke credentials.
[06:28] <mwhudson> s worth thinking about a bit so we don't paint ourselves into a corner, but right now BFB at all is looking hard enough to be starting with
[06:28] <mwhudson> oh at that level
[06:28] <mwhudson> yes, something like that
[06:28] <mwhudson> doesn't really have to be https though does it?
[06:29] <wgrant> Probably not, as the buildd network seems rather secure. But it still seems like a Good Idea, and that's how it's done with P3As.
[06:29] <wgrant> What other problems are there with private BFB?
[06:29] <mwhudson> i guess there must be some inspiration to be found in the restricted librarian
[06:30] <wgrant> mwhudson: The restricted librarian is not useful here.
[06:30] <mwhudson> wgrant: well, P3Asa at least then
[06:30] <wgrant> Right.
[06:31] <mwhudson> wgrant: well, i'm imagining stuff like preventing people building a private branch into a public pps
[06:31] <mwhudson> ppa even
[06:31] <mwhudson> anyway it's late and i need to get away from the computer
[06:31] <wgrant> It would be nice to design this properly from the start, so there isn't a crazy situation like there is with P3As, where file retrieval is completely different from public PPAs.
[06:31] <wgrant> Indeed.
[06:33] <mwhudson> wgrant: feel free to reply to my mail
[06:33] <mwhudson> i don't know how P3As work, i guess i should find out
[06:35] <wgrant> mwhudson: They are accessed from the archive with static buildd credentials over HTTPS. The master gives the slave a set of URLs with credentials embedded.
[06:37] <mwhudson> wgrant: oh, for when a package build-deps on things in the P3A?
[06:37] <wgrant> mwhudson: That's separate.
[06:38] <mwhudson> wgrant: then i'm not sure what you'
[06:38] <mwhudson> re talking about, but as my brain has turned to runny cheese and dribbled out of my ears, perhaps that's ok
[06:38] <wgrant> mwhudson: For public archives, the slave is given a list of SHA1s and it is up to it to grab them from the librarian.
[06:38] <wgrant> For private archives, the slave is given a list of HTTPS ppa.launchpad.net URLs with embedded credentials.
[06:39] <wgrant> (this is for retrieving the source package, not deps)
[06:39] <wgrant> But anyway, late.
[06:40] <mwhudson> oh that
[06:40] <mwhudson> accessing librarian files by sha1 seemed a little bonkers to me tbh
[06:43] <wgrant> It's ancient Soyuz stuff. It is expected to be bonkers.
[07:13] <spm> maxb: ref https://answers.edge.launchpad.net/launchpad/+question/89097 you didn't actually click on the proffered link did you? :-) And seeing as I'm about to remove that response, did you want me to tidy yours away as well?
[08:13] <adeuring> good morning
[09:50] <henninge> bin/test is segfaulting for me
[09:50] <henninge> I did make clean ; make build but it did not help ...
[09:52] <henninge> make run works fine btw
[10:11] <allenap> henninge: Can you paste the full error?
[10:11] <allenap> Morning adeuring :)
[10:11] <adeuring> hi allenap!
[10:12] <henninge> allenap: on the command line it is just "segmentation fault"
[10:12] <henninge> allenap: I am currently tracing into it
[10:13] <henninge> allenap: it happens on "from canonical.testing.layers import *" in testgin/__init__.py
[10:14] <henninge> "from canonical.launchpad.ftests import ANONYMOUS, login, logout, is_logged_in" in layers.py
[10:14] <allenap> henninge: Oh, not nice. Have you tried a "bzr clean-tree --ignored --force" for each directory in sourcecode/ ?
[10:14] <henninge> tracing deeper ...
[10:14] <thumper> make cleaner?
[10:14] <thumper> heh
[10:14] <thumper> sorry
[10:14] <allenap> henninge: And then a rebuild?
[10:14] <henninge> allenap: no, let me try that
[10:15] <allenap> thumper: :)
[10:16] <henninge> allenap: looking into sourcode I found an invalid symlink for lsprof
[10:17] <allenap> henninge: Mmm, link-external-sourcecode should remove dead symlinks in sourcecode/
[10:18] <wgrant> Why do dead symlinks matter?
[10:18] <wgrant> update-sourcecode will remove obsolete sourcecode branches?
[10:18] <wgrant> s/?/./
[10:19] <henninge> wgrant: what's "update-sourcecode"? Is that run by rocketfuel-get?
[10:19] <wgrant> henninge: Yes.
[10:19] <wgrant> henninge: It grabs new sourcecode branches (in lp-sourcedeps), updates existing ones, and removes old ones.
[10:19] <henninge> I did run it recently but I'll try and run it again
[10:28] <henninge> wgrant, allenap: unchanged :(
[10:29] <henninge> "make build" includes this line:
[10:29] <henninge> lib/twisted/web/http.py:40: RuntimeWarning: Python C API version mismatch for module _c_urlarg: This Python has API version 1013, module _c_urlarg has version 1012.
[10:31] <allenap> henninge: bac had a similar problem yesterday. IIRC, he did:
[10:32] <allenap> henninge: . ~/.rocketfuel.env
[10:32] <allenap> henninge: cd $LP_SOURCEDEPS_PATH/twisted
[10:32] <allenap> henninge: bzr clean-tree --ignored --force
[10:32] <allenap> henninge: make PYTHON=python2.5
[10:33] <allenap> henninge: The Twisted Makefile has python2.4 hardcoded :(
[10:33] <henninge> ah, I see
[10:33] <henninge> allenap: let me try that
[10:34] <gmb> I come to learn things.
[10:34] <allenap> henninge: Oops, that should be: . ~/.rocketfuel-env.sh
[10:35] <henninge> allenap: ;) saw that
[10:35] <allenap> Cool.
[10:37] <henninge> allenap: after that a "make build" again?
[10:38] <allenap> henninge: I don't think it should be necessary, but it'll do no harm I guess.
[10:39] <henninge> allenap: you are my hero today!
[10:39] <henninge> :-D
[10:39] <henninge> now the import facist is complaining ...
[10:40] <henninge> oh, that is after the test
[10:40] <allenap> henninge: Woohoo \o/ :)
[10:40] <henninge> allenap: thank you
[10:41] <allenap> henninge: You're welcome.
[10:41] <allenap> gmb: Any luck?
[10:41] <gmb> We'll know in a second...
[10:42] <gmb> allenap: Wewt, etc. Thanks.
[10:43] <allenap> gmb: Cool. I'll email the list with this too.
[11:23] <maxb> spm: (Re: https://answers.edge.launchpad.net/launchpad/+question/89097) Um, proffered link? I don't remember there being a link. Yes, it would make sense to tidy away my response since the thing I was responding to isn't there any more.
[12:17] <thumper> mwhudson: you shouldn't be replying to email at 40m past midnight
[12:17] <thumper> mwhudson: it sets a bad precident
[12:17] <thumper> :)
[14:14] <sinzui> bac: does bug 483607 need updating
[14:14] <mup> Bug #483607: The person profile page still shows the image and link to set somone's location <Launchpad Registry:In Progress by bac> <https://launchpad.net/bugs/483607>
[14:15] <bac> sinzui: done
[14:16] <sinzui> sweet. The page looks much better without a empty map section
[14:30] <sinzui> bac: EdwinGrubbs: stand-up in 2 minutes
[15:06] <jml> where do the doctest utilities live?
[15:07] <jml> canonical/launchpad/testing/pages.py
[15:09] <jml> gmb, hello
[15:09] <gmb> jml: Hi
[15:10] <jml> gmb, I came across a XXX comment of yours that says we won't need canonical.launchpad.testing.systemdocs.ordered_dict_as_string once we've switched to Python 2.5 because dict ordering is guaranteed when __str__() is called
[15:10] <gmb> jml: Right.
[15:10] <gmb> I assume that I research that before inserting the XXX...
[15:10] <jml> gmb, I'm trying to find a citation before I kill it.
[15:10] <gmb> Thought you might be.
[15:10] <gmb> :)
[15:11] <jml> gmb, heh
[15:11] <jml> http://www.python.org/doc/2.5.4/lib/typesmapping.html doesn't say much about it.
[15:11] <gmb> jml: I'm sure I looked it up, but I can't remember where I got the information from.
[15:11] <gmb> I should have cited it in the XXX, sorry.
[15:11] <jml> gmb, np.
[15:12] <jml> I'll ask on #twisted
[15:21] <jml> man
[15:21] <jml> thing that sucks about doctests
[15:21] <jml> we have a proliferation of dict-printing helpers
[15:21] <jml> all of which are subtly different.
[15:26] <jml> http://www.python.org/doc/2.5.4/lib/doctest-warnings.html
[15:36] <mars> jml, makes you wonder if we should just define a sensible __str__() on the objects we want to print, or maybe even start using pprint inside __str__()?
[15:36] <mars> unless you are talking about printing true dictionary objects
[15:37] <jml> mars, actually it makes me wonder why people continue to think doctests are a good idea
[15:37] <mars> I though of that too, I just didn't say it :)
[15:37] <jml> mars, we should have useful __repr__() methods for more of our objects definitely
[15:37] <jml> mars, in this particular context, I'm printing a thing of type dict though.
[15:38] <mars> ah, so no way around that then.
[15:39] <mars> just realized something.  BDD and cucumber lead to the same proliferation, but instead of dict output formatters, they lead to a proliferation of natural language interpreters.
[15:39] <mars> either way, you have a bunch of helpers to translate to and from plain text
[15:39] <mars> might just be necessary for the medium
[15:39] <jml> meh
[15:40] <jml> I still prefer building a DSL in the programming language
[15:40] <jml> I am bigoted against executable natural language.
[16:02] <bigjools> james_w: are package recipes tied to a distro or are they more generic?
[16:37] <sinzui> bac: are you available for our weekly call?
[16:43] <[reed]> gmb: huh, I had never heard of doctest before
[16:43] <[reed]> neat
[16:43] <[reed]> I don't get to do much python coding in my current job
[16:44] <gmb> [reed]: Yeah, we use them a lot. It's a nice way of keeping strong documentation, but it's not always terribly useful. We still love good old-fashioned unit tests for a lot of things.
[16:44] <[reed]> hehe
[16:44] <[reed]> yeah
[16:44] <gmb> So, things with lots of iterations and lots of nuanced behaviour == unittests
[16:44] <[reed]> as much as it is a pain to write tests, they can be so useful :)
[16:44] <gmb> [reed]: Before I can land this, you need to have sent in your contributor agreement form. Have you done that?
[16:45] <[reed]> gmb: no, I didn't know there was one. If you can point me to where it is, I can probably get that done in the next hour or two, depending on what form I have to send it in.
[16:46] <bac> sinzui: i am now.
[16:46] <gmb> [reed]: https://dev.launchpad.net/ContributorAgreement
[16:46] <gmb> [reed]: Just ping me when you're done.
[16:46] <[reed]> literally, that was my first lp bzr branch ever ;)
[16:47] <sinzui> bac: calling
[16:47] <[reed]> ah, it's just a simple e-mail
[16:48] <[reed]> ok, it's a bit scary that in less than 30 min. after I post that bzr branch, the google alert for my name goes off and informs me of it
[16:51] <gmb> [reed]: If you don't contribute anything else in six months you get an email that says "we know where you live," too.
[16:51] <[reed]> lol
[16:53] <[reed]> gmb: ok, read the agreement and sent the e-mail... I cc'd you, as per the instructions.
[16:53] <gmb> [reed]: Brilliant, thanks. I'm working on the tests now. Should be able to land it tonight, or tomorrow at the latest.
[16:54] <[reed]> cool
[16:59] <sinzui> bac: https://edge.launchpad.net/launchpad-registry/3.1
[17:01] <al-maisan> beuno: just letting you know: jml is on level 3
[17:02] <gary_poster> maxb, From following the instructions I was given, I believe you should be able to upload to the PPA.  Let me know how it works.
[17:07] <beuno> al-maisan, thanks
[17:09] <salgado> mars, what revno of lazr-js are you using in your yui3-final-upgrade branch?
[17:09] <mars> salgado, 153
[17:10] <mars> salgado, but that can be updated as needed.  Downgrading is a bit tricker.
[17:12] <salgado> mars, ok, just wanted to check we'd be using tip
[17:16] <salgado> mars, btw, all that I'm going to integrate is the combo loader -- flacoste's css minifier will come together as a bonus?
[17:17] <mars> salgado, yes, I believe it was merged during the sprint.
[17:17] <salgado> yeah, it was
[17:19] <salgado> mars, do you have an idea how that's going to be integrated into LP?  if not, I guess flacoste has
[17:20] <mars> salgado, I have no idea how.
[17:21] <salgado> flacoste, I'm going to work on integrating the combo loader into LP, and I assume you've got an idea how that should be done, so was hoping to have a pre-impl call with you. ;)
[17:23] <maxb> gary_poster: Nothing to upload right now, but the Launchpad web ui claims I can upload. :-)
[17:24] <gary_poster> maxb: awesome :-)
[17:24] <maxb> I guess I could start populating it for Lucid :-)
[17:25] <maxb> But actually many of the packages are obsolete now we don't need python 2.4 support
[17:25] <maxb> I should make a list and propose deleting them at some point
[17:27] <mars> salgado, presumably the combo loader will be a stand-alone process like the librarian.  It will also need access to all of our static files, and I don't know how that part would be linked into the system.
[17:29] <maxb> Is it just me or has someone broken the page layout on https://dev.launchpad.net/ ?
[17:30] <maxb> oh, it's just that it wraps amazingly poorly if your browser window isn't wide enough
[17:32] <maxb> hm, has someone changed something about the way drop-down select boxes get handled on edge?
[17:32] <maxb> I'm seeing a major performance regression with drop-downs taking several seconds to display
[17:32] <mars> maxb, which page?
[17:32] <maxb> ppa pages
[17:33] <salgado> mars, yeah, that sounds reasonable
[17:33] <mars> maxb, you are right.  I wonder why that is.
[17:34] <maxb> gary_poster: Also, I appear to have upload rights but not delete-package rights, oddly
[17:35] <maxb> mars: Hmm. I see the problem on the ppa root page, and on /+copy-packages, but *not* on /+packages, oddly
[17:36] <mars> maxb, it may be the JavaScript blocking the main browser thread :(
[17:36] <maxb> ETOOMUCHJAVASCRIPT :-(
[17:36] <mars> I can't reproduce it.  It is only on initial page load
[17:36] <mars> maxb, not too much, just doing the wrong thing at the wrong time.
[17:36] <maxb> oh dear. heisenbugs are not fun. It seems to be consistently affecting me
[17:38] <mars> maxb, the other explanation is something not downloading fast enough.  On my page load, I see a long, long blocking on laucnhpad.js and the arrowBlank images.
[17:38] <maxb> surely that shouldn't be an issue after navigating around a few launchpad pages?
[17:39] <mars> if it is cached properly, then no, it should not be an issue.
[17:42] <mars> maxb, since this is a good reproducible case, would you mind filing a bug about it?  And please note the exact page(s) you are visiting, and the browser you are using.
[17:42] <mars> maxb, I'd like to work on front-end performance at some point, and this would be a good point to cut my teeth on :)
[17:49] <maxb> Hmm, it seems to only occur on PPAs with a non-trivial number of packages
[17:50] <mars> I had it happen on a PPA with two packages.  But only the first time.
[18:13] <flacoste> salgado: suer, let's have a call
[18:14] <salgado> flacoste, I'm ready
[18:33] <al-maisan> hello salgado, do you have a minute? I'd like to ask your advice re. a branch I am currently working on.
[18:34] <salgado> hi al-maisan.  what's up?
[18:35] <al-maisan> I need to expose a method on the LP API and that new method would use a class that's currently in the browser layer (ProxiedLibraryFileAlias)
[18:36] <al-maisan> the new method will be part of a model class
[18:36] <al-maisan> so, not quite sure what the best approach is
[18:37] <al-maisan> salgado: using browser-layer code in a model class is obviously less than ideal
[18:37] <salgado> indeed
[18:39] <salgado> al-maisan, do you really need to expose ProxiedLibraryFileAlias or do you just want people to have access to files in the restricted librarian?
[18:39] <al-maisan> salgado: to be more concrete, sourceFileUrls() (http://pastebin.ubuntu.com/321744/) will need to use ProxiedLibraryFileAlias
[18:40] <salgado> oh, I didn't understand it at first
[18:40] <al-maisan> salgado: we can't throw librarian URLs back since these may be *restricted* librarian URLs in case of private PPAs
[18:41] <salgado> I thought you wanted to expose ProxiedLibraryFileAlias, but you just want to expose a method that happens to use ProxiedLibraryFileAlias
[18:41] <al-maisan> salgado: right!
[18:43] <al-maisan> salgado: bigjools just pointed me to an example where we already use ProxiedLibraryFileAlias in the model layer
[18:44] <salgado> oh, and ProxiedLibraryFileAlias.http_url calls get_current_browser_request()
[18:44] <al-maisan> but if there's a better way of doing it I am open to it
[18:46] <al-maisan> the changes_file_url() property in lp/soyuz/model/publishing.py is using it already and it does not seem to be a problem
[18:46] <salgado> al-maisan, it will be if someone uses that property in a script, for example
[18:49] <gary_poster> maxb, I asked bigjools about you not having delete permission and he said it was expected/desired behavior.  Only PPA owners can delete.
[18:50] <maxb> quirky that I can use copy-packages but not delete-packages
[18:50] <maxb> doesn't really matter, I guess
[18:50] <maxb> I guess copy-packages is 'sort of' an upload. If you squint a bit
[18:51] <al-maisan> salgado: can we continue later? It's lunch time here..
[18:52] <salgado> al-maisan, so, basically we're making model code depend on the current browser request because we can only expose things from the model in the webservice?
[18:52] <salgado> al-maisan, and I was thinking you were working late!
[18:52] <al-maisan> salgado: UDS :)
[18:52] <salgado> al-maisan, sure thing, go enjoy some tex-mex food. ;)
[18:54] <al-maisan> salgado: "we can only expose things from the model in the webservice" .. is this a fixed rule?
[18:54] <al-maisan> .. or do you know of examples where non-model code was exposed via the LP API?
[18:55] <salgado> al-maisan, no, I think that's just a limitation of our existing webservice
[18:56] <al-maisan> salgado: hmm .. I'll try using ProxiedLibraryFileAlias in the method that is to be exposed (although it's less than ideal) and see how it goes..
[18:56] <al-maisan> definitely lunch time now
[18:56] <salgado> al-maisan, it will work fine until somebody comes along and try to use that method in a script
[18:56] <al-maisan> right
[18:57] <al-maisan> I see
[18:57] <al-maisan> salgado: thanks for taking a look!
[18:57] <al-maisan> ttyl
[19:01] <maxb> Woo, just got my "you have been added to launchpad-committers"
[19:02] <maxb> Though with none of the ~launchpad admins around, I guess it's not going to be actually have branches for a while yet
[19:04]  * maxb reassigns some branches
[19:45] <mars> salgado, around?
[19:45] <salgado> mars, yep
[19:46] <mars> salgado, in Francis' reply to me on lp-dev, the thread about "Redesigning lazr.restful", he said that you know about common cases for update pages via AJAX?
[19:47] <mars> salgado, if so, I was wondering if you could reply to the thread with one of those cases, for the benefit of myself and other readers?
[19:47] <salgado> mars, the one I know about is the one he mentioned
[19:47] <salgado> Adding a team member inline
[19:48] <mars> ok
[19:48] <mars> so how does that involve updating multiple parts of the page?
[19:48] <salgado> mars, would you like to know what needs to be updated in that case?  or other cases where this would be needed?
[19:48] <mars> salgado, both
[19:49] <salgado> mars, if the new member is a person, we add it to the 'Recent members' section and update the count of active members
[19:49] <salgado> if it's a team, we update the count of invited members
[19:50] <salgado> but if the new member was a proposed/inactive member, then we need to update two lists and two counts
[19:50] <mars> oh?
[19:50] <salgado> moving the member from the 'pending members' section to the 'recent members' one
[19:51] <mars> just thinking, that leads to a problem.  Using francis' scheme, how do you know when to ask for one, two, or many fragments in return?
[19:51] <mars> salgado, anyway, please go on
[19:51] <salgado> mars, all of this is in one portlet
[19:51] <mars> ah
[19:53] <salgado> I think it's quite unlikely that an inline action would require changes to more than one fragment/portlet
[19:55] <mars> salgado, thank you, I'll reply to the thread
[19:58] <salgado> mars, np
[20:03] <jelmer> bigjools: yeah, it works now - thanks
[20:04] <mwhudson> james_w: hi, you there?
[20:06] <mwhudson> james_w: it seems like the official source package branches for indicator-applet are not in 2a format
[20:06] <mwhudson> james_w: do you want to fix that or shall i?
[20:17]  * thumper is fetching kickass strong coffee
[20:20] <mwhudson> hm
[20:20] <mars> abentley, ping
[20:20] <mwhudson> did kiko make all the importd slaves fall over with those kernel imports?
[20:20] <abentley> mars: on a call
[20:20] <mars> k
[20:39] <abentley> mars: pong
[20:40] <mars> abentley, could you please explain to me how the +fragment URL scheme that you were using works?
[20:42] <abentley> mars: Sure, let me refresh myself.
[20:43] <abentley> mars: I manually construct the relative URL of the comment fragment, using the comment ID.
[20:44] <abentley> mars: Then I use Y.io to retrieve the fragment, and invoke a callback with the response text.
[20:44] <mars> abentley, so Y.io("/+bug/1234/+comments/1"), or something?
[20:44] <mup> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <Launchpad Foundations:Fix Released by debonzi> <https://launchpad.net/bugs/1234>
[20:45] <mars> ugh
[20:45] <thumper> abentley, mars: just an FYI
[20:45] <thumper> I started doing this with showing the merge proposal details on the branch page
[20:45] <thumper> y.io worked fine
[20:45] <abentley> mars: No, I was doing it only with code review comments.  So it was comments/1
[20:45] <thumper> but when I needed to do so on the bugs page
[20:45] <thumper> it blew up
[20:45] <mars> abentley, ah, but same idea
[20:45] <thumper> so I had to use the api to get the formatted code
[20:46] <abentley> mars: And then appending +fragment on the end, so "comments/1/+fragment"
[20:46] <mars> ah
[20:46] <abentley> thumper: Did you try constructing an absolute URL?
[20:46] <thumper> getting the fragments rendered all at once through the api is necessary
[20:46] <thumper> abentley: didn't work
[20:47] <thumper> abentley: there may be other reasons why
[20:47] <thumper> but I couldn't find them
[20:47] <abentley> thumper: I'm surprised, because I thought that limitation only applied to AJAX.
[20:47] <thumper> abentley: it is ajax
[20:47] <thumper> doesn't Y.io use xmlhttprequest?
[20:48] <abentley> thumper: But it returns text, not xml.
[20:48]  * thumper shrugs
[20:48]  * mwhudson blinks
[20:49] <abentley> mwhudson: You know the same-origin policy for ajax, right?
[20:50] <mwhudson> well vaguely
[20:50] <mwhudson> abentley: i think the part that confuses me is what you mean by "ajax"
[20:50] <abentley> mwhudson: I mean making asynchronous requests for XML using javascript.
[20:51]  * sinzui saw that remark coming
[20:51] <mwhudson> abentley: but that's not what ajax means in practice these days, is it?
[20:51] <mwhudson> as ~noone actually does the xml bit
[20:52] <mars> mwhudson, that may be true, we just never talk about it :)
[20:52] <abentley> mwhudson: Okay, I rephrase my comment to "I'm surprised, because I thought that limitation only applied when AJAX actually does XML".
[20:52] <sinzui> AJAJ The greek hero of jam
[20:53] <mwhudson> abentley: ah, i don't think that's true
[20:53] <mwhudson> maybe i'm wrong!
[20:56] <abentley> mwhudson: Apparently with json, it's popular to use an IFRAME hack to circumvent the same-origin policy.
[20:57] <abentley> mwhudson: Though according to http://www.json.org/fatfree.html this only gives access to subdomains.
[20:57] <mars> thumper, fwiw, same-orgin policy isn't a problem for the JavaScript API.  The whole webservice is exposed via every subdomain's /api URL.
[20:57]  * mwhudson sticks his fingers in his hears and hides under his desk
[20:58] <mwhudson> mars: that's why he had to change his code to actually use the api :-p
[20:58] <mwhudson> (at least, that was my understanding)
[20:58] <mars> yep :)
[20:59] <sinzui> abentley that is true about the iframe, and YUI allows you to shoot yourself in the foot
[20:59] <mars> sinzui, how?
[20:59] <sinzui> abentley: I believe there is another reason though to use an iframe, I think it was file uploads
[20:59] <thumper> mars: yes, that is how I got it working
[21:00] <abentley> mars: Anyhow, I think the idea of allowing us to get the views, and get them all at once, makes a lot of sense.
[21:01]  * thumper is starting to wake up 3 hours after getting up
[21:01] <thumper> abentley: +1
[21:01] <sinzui> mars: I think any site that circumvents the security in my browser and risks handling my data should also have its pages re-written in javascript to say security-holes are here to play, come steal user user's data today
[21:02] <mars> heh
[21:02] <ajmitch> how poetic
[21:02] <mars> well, there was that nifty page that stole your gmail contact list...
[21:04] <thumper> flacoste: ping
[21:04] <flacoste> hi thumper
[21:04] <flacoste> call?
[21:04] <thumper> yeah
[21:15] <mars> Wow, cherrypicks take a long time to run.
[21:15] <mwhudson> yes
[21:17] <abentley> mwhudson: call?
[21:17] <mwhudson> abentley: skype ok?
[21:17] <abentley> mwhudson: sure.
[21:17] <mwhudson> then yes
[21:18] <abentley> mwhudson: https://pastebin.canonical.com/24854/
[21:20] <mwhudson> abentley: http://twistedmatrix.com/pipermail/twisted-python/2009-April/019482.html
[21:26] <mwhudson> abentley: https://launchpad.net/ampoule
[21:44] <mwhudson> yay skype
[21:45] <abentley> mwhudson: Yeah, it's getting to bug me more and more.
[21:46] <mwhudson> abentley: i'll try to get my new router going
[21:46] <abentley> mwhudson: thanks.
[21:46] <mwhudson> and then we can sip for great justice or something
[21:54] <mars> is the layout of the subscribers portlet on edge broken for everyone, or just me?
[21:55] <mars> to pick an arbitrary bug, #234567
[21:55] <mup> Bug #234567: Gnome toolbars unresponsive after update and no toolbars on reboot. <toolbar> <gnome-panel (Ubuntu):Invalid by desktop-bugs> <https://launchpad.net/bugs/234567>
[21:55] <wgrant> mars: Yes.
[21:55] <wgrant> mars: It was fairly broken last week.
[21:55] <wgrant> mars: But this week it transitioned to really broken.
[21:55] <mars> wgrant, last week!
[21:55] <wgrant> A bug was filed last night.
[21:58] <mars> wgrant, thanks.  #484848 :)
[21:58] <mup> Bug #484848: Subscriber icons in the subscribers portlet appear on a separate line from the subscribers' names <bug-page> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/484848>
[22:01] <mwhudson> cool bug number
[22:01] <wgrant> Too close to 500000 :(
[22:13] <mwhudson> https://code.edge.launchpad.net/~vcs-imports/linux/trunk is running really fricking slowly
[22:24] <jml> tee hee
[22:24] <jml> mwhudson, hi
[22:25] <mwhudson> jml: hello
[22:25]  * jml waves to the rest of the launchpadders
[22:26]  * jelmer waves
[22:26]  * mwhudson starts working through the stack of replies to his mail of last night
[22:26] <jml> so... when are we doing bzr-svn?
[22:27] <mwhudson> jml: after i've replied to these mails i guess
[22:27] <jml> woop woop!
[22:27] <mwhudson> jml: or you or jelmer could bang on https://code.edge.launchpad.net/~mwhudson/launchpad/bzr-svn-imports a bit
[22:27] <mars> flacoste, cool, thanks for the reply
[22:28] <mwhudson> where do the packages that get built by the current soyuz system get signed?
[22:29]  * jml looks
[22:29] <wgrant> mwhudson: The sources are signed on the dev's machines.
[22:29] <jml> orrible ack :)
[22:29] <wgrant> s/'s/s'/
[22:29] <mwhudson> wgrant: sorry
[22:29] <mwhudson> wgrant: s/packages/binaries/
[22:29] <wgrant> Oops, didn't read the 'built by'
[22:29] <wgrant> mwhudson: They're not actually signed themselves.
[22:30] <mwhudson> well they are by the time they get into the archive?
[22:30] <wgrant> mwhudson: They're stuck in the repository, and the repository's Release file (containing lots of hashes) is signed.
[22:30] <mwhudson> oh
[22:30] <mwhudson> ok
[22:30] <mwhudson> this happens during publication then?
[22:31] <wgrant> Yes.
[22:31] <mwhudson> are the source packages that are uploaded for a ppa published before they are built?
[22:32] <wgrant> For PPAs, not necessarily.
[22:32] <wgrant> For P3As, yes.
[22:32] <wgrant> (because P3A builds need to get the source files from the published archive)
[22:32] <mwhudson> ok
[22:33] <mwhudson> i think the mist is beginning to lift
[22:33] <mwhudson> (or close in, or something)
[22:33] <wgrant> Now, sources don't actually have to be signed. But as bigjools says, you probably should if you can.
[22:33] <mwhudson> wgrant: is the 'not necessarily' for PPAs because publication and building are essentially independent?
[22:34] <mwhudson> man, i'm amazed the soyuz guys got P3As to work
[22:34] <mwhudson> much respect due there
[22:34] <wgrant> mwhudson: Well, they worked, but I was able to penetrate them simply three times, so it's a restricted value of work.
[22:35] <wgrant> mwhudson: The source signature is only used to verify that the uploader is who they say they are.
[22:35] <wgrant> mwhudson: Once archiveuploader finishes with it, it is no longer important.
[22:36] <wgrant> (and archiveuploader already accepts unsigned source packages from trusted sources)
[22:39] <wgrant> What could perhaps work is getting the builddmaster to sign them once it gets them from the slaves, but that's a bit ew.
[22:55] <thumper> rockstar: ping
[22:55] <rockstar> thumper, hi.
[23:00] <spm> mars: hi; "<maxb> spm: (Re: https://answers.edge.launchpad.net/launchpad/+question/89097) Um, proffered link?" it looked like a sig; but was to.. um.... an male enlargement assistant site. To put things delicately.
[23:07] <maxb> huh. I don't remember seeing a link there. Are the spammers getting clever enough to stick their links in legitimate-ish responses now !?
[23:07] <mars> spm, ?
[23:08] <spm> mars: gah. sorry. tab completion fail. 1001 apologies.
[23:08] <mars> ok.  I didn't see the link-spam anyway?  I hate spam.
[23:08] <maxb> spm removed a question comment to which I'd responded. Apparently there was a dodgy link there. I'm confused because I interpreted it as a genuine user, and wrote a response to it, without noticing.
[23:09] <spm> maxb: well... one of them at least. the responses they we're making were *vaguely* on topic; just ... odd. but the link was a no-no. and some of the responses they had were pure spam.
[23:09] <wgrant> sinzui: Why Jaunty->Lucid rather than Karmic->Lucid?
[23:09] <james_w> mwhudson: I have a list somewhere of the packages that aren't in 2a
[23:09] <james_w> I haven't done the work to upgrade them all yet, do you have a way to do it easily?
[23:09] <maxb> spm: huh. there was only one response from that user at the time I wrote my response.
[23:09] <sinzui>  wgrant It is a typo
[23:09] <mwhudson> james_w: well there is a script now
[23:09] <thumper> rockstar: it doesn't look link yui 3.0 is in devel
[23:09] <spm> maxb: (mars) they hit about half a dozen different answers across the place
[23:09] <thumper> mars: are you landing it?
[23:09] <mwhudson> i don't know if we have an easy way of letting it rip at a bunch of branches
[23:09] <sinzui> wgrant: And my script definitely knows not to do exactly that
[23:09] <rockstar> thumper, it's in db-devel
[23:10] <wgrant> sinzui: great.
[23:10] <james_w> mwhudson: for loop?
[23:10] <sinzui> in fact. I think I need to get my confidence up and ask a LOSA to run it on staging.
[23:10] <mwhudson> james_w: i guess :-)
[23:10] <spm> sinzui: I do recognise I'm scary to ask. just saying. ;-)
[23:11] <mars> thumper, waiting for the CP on db-devel, fixing up any gross errors (I've found one so far), then merging back into devel.
[23:11] <mwhudson> i don't know if we have an easy way of scheduling even one branch to be upgraded i guess
[23:11] <mwhudson> rockstar: ^^ ?
[23:11] <mars> thumper, maybe early next week.  But you can build on top of the branch now!
[23:12] <sinzui> spm: The sample data is small, My script certainly works. as wgrant hinted. The order I fix the packing link is very important.
[23:12]  * sinzui fixes bug title
[23:12] <wgrant> sinzui: I don't see why you single out Feisty there.
[23:12] <james_w> mwhudson: I don't think trying to do this over conference wifi would be wise
[23:12] <james_w> mwhudson: I could pass the list to you?
[23:12] <mwhudson> james_w: that would be great
[23:13] <mwhudson> i can always do it from devpad if the new sexiness proves uncooperative
[23:13] <spm> mwhudson: james_w: coming in this half way thru - I gather this may be appropriate to run on crowberry itself? or?
[23:13] <sinzui> wgrant: the original bug mentioned that, and that is the point we added the initialisation.. My script runs from hoary to lucid
[23:13] <wgrant> sinzui: Ah, I see.
[23:14] <rockstar> mwhudson, I don't think so.
[23:14] <mwhudson> spm: maybe yes, don't think it matters too much
[23:14] <mwhudson> spm: you can't do it at the fs level because of the ever joyful stacking
[23:15] <rockstar> mwhudson, so, what we have REALLY needs to be tested.
[23:15] <spm> mwhudson: sweet....
[23:15] <mwhudson> rockstar: well i guess we can test it
[23:16] <mwhudson> rockstar: the way of scheduling a job now is "INSERT INTO BranchUpgradeJob ...." ?
[23:16] <james_w> mwhudson: http://paste.ubuntu.com/321956/
[23:16] <james_w> that's the packages
[23:16] <james_w> inferring the branches from that is left as an exercise for the reader
[23:16] <mwhudson> james_w: btw
[23:16] <mwhudson> james_w: what should i do when i find a source package has no branches?
[23:16]  * mwhudson feels a query of doom coming on
[23:17] <rockstar> mwhudson, yes, but that's not even all that tested.
[23:17] <mwhudson> rockstar: ok
[23:17] <james_w> mwhudson: the branch URLs are predictable fwiw
[23:17] <mwhudson> rockstar: so maybe i won't try to upgrade all of these branches as the first test :-)
[23:17] <rockstar> mwhudson, I have UI, but didn't think it wise to land while I was sprinting/at UDS/week 3
[23:17] <rockstar> mwhudson, please for the love of Thor no.
[23:17] <james_w> mwhudson: for packages with no branches, file a bug against "udd" project please
[23:17] <mwhudson> james_w: one per package?
[23:18] <mwhudson> rockstar: >:)
[23:18] <sinzui> spm: I have this script that walks the history of Ubuntu's series and copies the packaging links restore the data we have been losing with each series we create. I want to run this test on stagings database to verify it runs, and to examine the quality of data that it makes. https://pastebin.canonical.com/24860/
[23:18] <mwhudson> i guess a test on staging is a good idea in any case
[23:18] <rockstar> mwhudson, yeah, probably.
[23:18] <james_w> mwhudson: a bunch per package
[23:19] <spm> sinzui: sure. one sec.
[23:19] <rockstar> mwhudson, Also, the upgrade won't actually upgrade to 2a just yet.  I didn't realize that until week 4 of last cycle.
[23:19] <james_w> ~ubuntu-branches/ubuntu/<distroseries>/<sourcepackagename>/<suite>
[23:19] <rockstar> We never updated the format map when we moved to 2.0
[23:19] <mwhudson> rockstar: groan
[23:20] <mwhudson> james_w: sorry, i'm being dense, was that aimed at me?
[23:20] <rockstar> mwhudson, yes, but I think we can actually get rid of the mapping now, since a call to upgrade should upgrade properly to 2a
[23:20] <james_w> mwhudson: yeah, however, I'm out of battery and so can't expand, sorry :-)
[23:20] <mwhudson> james_w: the query to find all the official branches for a particular source package is not very hard
[23:20] <rockstar> i.e. I shouldn't have to make some format first...
[23:20] <james_w> mwhudson: that's probably the better way for you to do it then
[23:20] <maxb> james_w: Do we still file bugs for native packages without branches? Or is that a general problem still?
[23:21] <mwhudson> james_w: the "of doom" part was thinking about requesting upgrades of all of them :)
[23:21] <james_w> maxb: file a bug please
[23:21] <james_w> back in a few when I can escape from this corner of the session with no electricity
[23:22] <spm> sinzui: quick Q; is this expected to be quick; or slow? do you want it run with any special options or just go for it?
[23:22] <mwhudson> james_w: https://code.edge.launchpad.net/ubuntu/lucid/+source/bzr-fastimport
[23:23] <sinzui> spm: I honestly do not know. I think it could complete in a few minutes because we are looking with 1000s of objects.
[23:23] <spm> sinzui: oki; suck and see time.
[23:24] <sinzui> spm: when it is done. We will know exactly how may objects we are playing with
[23:26] <spm> sinzui: I do love Dev's who wildly overestimate how long their code takes to run. ;-) https://pastebin.canonical.com/24861/
[23:27] <sinzui> spm: It better to please than to disappoint. I schedule milestones the same way
[23:27] <spm> hahahaha
[23:28] <sinzui> those numbers do look like the pages. I'll look at lucid on staging and see if it makes sense. I suspect I have just create 1200 links to packages that are in PPAs, not main
[23:30] <wgrant> There are some links to PPA packages, but not that many.
[23:31] <sinzui> ugh. It copied squeak.  That project is proprietary and should be deactivated
[23:44] <sinzui> These links look correct. I see some wrong one, but they are wrong because the version changed late in Karmic, so karmic and lucid both need need fixing
[23:48] <jelmer> bigjools: Hi
[23:49] <jelmer> bigjools: Do you perhaps have a free moment to look at a zope issue?
[23:49] <bigjools> jelmer: possibly, I am sorting out a production problem, I can try and find you later
[23:51] <jelmer> bigjools: thanks - we're in presidente