| === jamalta-afk is now known as jamalta | ||
| mwhudson | thumper: woo, new code import mail with actual information in it \o/ | 01:04 |
|---|---|---|
| jelmer | mwhudson: it looks like bzr-git will switch to a new caching format as of the next version | 01:12 |
| mwhudson | jelmer: does that mean we'll need to do something to update the old caches? | 01:12 |
| jelmer | mwhudson: better performant, but I guess it'll also mean there's some changes that have to happen in lp-code to cope with new filenames, etc | 01:12 |
| mwhudson | or will regenerating them work? | 01:13 |
| mwhudson | yeah, guess so | 01:13 |
| mwhudson | should be easy though | 01:13 |
| mwhudson | jelmer: is the new format going to be pack based? | 01:13 |
| jelmer | regenerating them should work, if it doesn't that's a bug in bzr-git :-) | 01:13 |
| jelmer | mwhudson: not pack based, but based on bzr indexes (there's no content so no need for packs) | 01:13 |
| mwhudson | ah, ok | 01:14 |
| mwhudson | will it be a single file still? | 01:14 |
| jelmer | no, it's a directory with multiple files | 01:15 |
| jelmer | though if you wanted to you could trigger a repack so it ends up being just a single file (and a format indicator) in that directory | 01:15 |
| mwhudson | mmf, that sounds boring | 01:16 |
| mwhudson | probably tarring it up is easier | 01:16 |
| mwhudson | jelmer: will it be .bzr/repository/git-cache or something like that? | 01:17 |
| jelmer | mwhudson: yeah, .bzr/repository/git | 01:17 |
| jelmer | mwhudson: of course, Bazaar should really have hooks for fetch that allow us to copy this data along with the branch.. | 01:17 |
| mwhudson | jelmer: have you seen how AMAZINGLY SLOW the kernel import is going? https://code.edge.launchpad.net/~kiko/linux/2.6.31 | 01:18 |
| jelmer | mwhudson: yeah | 01:18 |
| lifeless | jelmer: yes, we should. | 01:18 |
| jelmer | lifeless: is this the moment where you suggest I submit a patch ? ;-) | 01:18 |
| lifeless | jelmer: I wouldn't insult your intelligence that way :) | 01:19 |
| lifeless | actually this is not trivial to do well | 01:19 |
| lifeless | and doing it badly will make push and pull suck arse for everyone | 01:19 |
| jelmer | mwhudson: it'll be a bit faster with the new cache | 01:19 |
| mwhudson | jelmer: i *think* we have tests that will fail when bzr-git changes here | 01:19 |
| jelmer | mwhudson: also, there's some Google folks working on improving the performance of Dulwich, that'll help a bit | 01:20 |
| mwhudson | jelmer: it will also be a bit faster when we get that new machine online... | 01:20 |
| mwhudson | jelmer: heh, interesting | 01:20 |
| jelmer | lifeless: what are you thinking might make it problematic ? Figuring out what revisions to fetch? | 01:21 |
| mwhudson | do you know why it's so slow for the kernel? | 01:21 |
| mwhudson | just because it's a big tree? | 01:21 |
| lifeless | jelmer: not triggering VFS on every pull | 01:21 |
| lifeless | jelmer: and integrating with streaming | 01:21 |
| lifeless | how much to fetch and so on is also interesting | 01:22 |
| lifeless | but I was figuring plugins will need their own protocol for negotiating that shit | 01:22 |
| jelmer | lifeless: yeah - how hard is it to add custom commands to the smart server protocol? | 01:22 |
| jelmer | hopefully using the bzr btree indexes will also make it a bit easier to just fetch those keys that we need - it'd be trickier than tdb | 01:23 |
| wgrant | mwhudson: It seemed to go from 3-5 hours per run to > 12 a couple of days ago. | 01:24 |
| jelmer | wgrant: it depends on the machine | 01:24 |
| jelmer | galapagos in particular is very slow | 01:24 |
| mwhudson | wgrant: galapagos seems particularly slow | 01:24 |
| mwhudson | i think elmo said one of the machines was one of canonical's very first machines :) | 01:25 |
| lifeless | jelmer: custom commands are easy; making it all hook in well not so much - we don't want plugin-count extra round trips either | 01:25 |
| wgrant | mwhudson: Ah, yeah, but neumayer isn't fast either by the look of things. | 01:25 |
| wgrant | Yeah, galapagos is from the original naming scheme, so it makes sense that it's old... | 01:25 |
| mwhudson | oh right, yeah | 01:26 |
| jelmer | lifeless: so even a single extra roundtrip if there's no data would be a problem? I guess in that case we really need something like what's specified in the 'branch baggage' spec to make it perform well | 01:26 |
| mwhudson | neumayer and russkaya are both antartic bases | 01:26 |
| wgrant | Yep. | 01:26 |
| mwhudson | there's a new machine ready and waiting apparently | 01:26 |
| lifeless | jelmer: something-mumble-mumble | 01:27 |
| wgrant | Penguins, Antarctic bases, elements, fruits... is that it? | 01:27 |
| lifeless | jelmer: imagine 10 plugins doing this | 01:27 |
| mwhudson | waiting for our sysadmin to recover from dental surgery :/ | 01:27 |
| wgrant | mwhudson: Yeah :( | 01:27 |
| lifeless | jelmer: if that was a rtt per just to probe, we'd spend 3 more seconds on an empty pull | 01:27 |
| lifeless | for me <-> London | 01:27 |
| mwhudson | wgrant: yeah, still on friut afaik | 01:27 |
| mwhudson | jelmer: in other news | 01:28 |
| mwhudson | jelmer: bzr-hg's tests are appalling | 01:28 |
| jelmer | mwhudson: don't say I didn't warn you :-P | 01:29 |
| mwhudson | this is true | 01:29 |
| jelmer | mwhudson, thumper: oh, btw, is it possible to upgrade lp:django ? www.isgitbetterthanx.com uses it to show that bzr is slow, and since it uses 0.92 it's indeed very slow | 01:36 |
| mwhudson | jelmer: with a losa to help, yes :/ | 01:37 |
| mwhudson | jelmer: ask a question? | 01:38 |
| jelmer | against launchpad-code and assign to losas? | 01:38 |
| mwhudson | yeah | 01:38 |
| mwhudson | i'll post some more details | 01:38 |
| lifeless | huh | 01:39 |
| lifeless | can't a branch expert upgrade it on the web ui? | 01:39 |
| mwhudson | not for an import branch, no | 01:39 |
| EdwinGrubbs | wgrant, jelmer: Can you look at this proposal if you have time? https://dev.launchpad.net/Registry/InvolvementPortletRefactor | 01:39 |
| wgrant | EdwinGrubbs: Looking. | 01:40 |
| EdwinGrubbs | sorry, I have to leave now | 01:41 |
| jelmer | EdwinGrubbs: Sure, I'll have a look (might be tomorrow morning CET though) | 01:42 |
| mwhudson | grar | 01:42 |
| mwhudson | calling mercurial.commands.commit() in a test is asking me to choose an editor | 01:42 |
| jelmer | mwhudson: I think you can specify a custom ui object to prevent that | 01:43 |
| jelmer | mwhudson: we have one that wraps a bzr ui factory | 01:43 |
| mwhudson | yeah, seems likely | 01:44 |
| mwhudson | oh right | 01:44 |
| mwhudson | woo, i think my tests are ok now | 01:48 |
| mwhudson | now why doesn't stop_revision to InterBranch.fetch() work... | 01:48 |
| thumper | and now to attempt to focus on work... | 02:01 |
| mwhudson | jelmer: still there? | 02:04 |
| jelmer | mwhudson: yeah | 02:04 |
| mwhudson | jelmer: i'm not sure where to do the limit of importing in bzr-hg | 02:04 |
| mwhudson | it doesn't seem to produce a nice toposorted list of the hg revisions to import anywhere | 02:05 |
| mwhudson | unless a mercurial.changegroup.chunkiter() iterates in toposorted order? | 02:05 |
| jelmer | yeah, that's guaranteed to be toposorted | 02:06 |
| jelmer | although it would be nice to not fetch those revisions in the first place | 02:06 |
| thumper | jelmer: any movement on the bzr-hg bug that is causing 80% of them to fail? | 02:07 |
| mwhudson | jelmer: is that going to be possible? | 02:07 |
| mwhudson | given a head, you'll have to walk back to null to find which ones to import first, won't you? | 02:07 |
| poolie | thumper: is a 'revision feed' a feed of all revisions for a particular project | 02:09 |
| mwhudson | poolie: or person | 02:10 |
| thumper | or team | 02:10 |
| thumper | or project group | 02:10 |
| thumper | poolie: but yes | 02:10 |
| lifeless | not quite | 02:11 |
| thumper | ok | 02:11 |
| thumper | latest revisions | 02:11 |
| lifeless | there is a feed of new braches | 02:11 |
| thumper | in the last 30 days | 02:11 |
| lifeless | and per branch a feed of revisions | 02:12 |
| lifeless | I filed a bug asking for project feeds the day they went into beta | 02:12 |
| thumper | lifeless: and a revision feed for a project for over a year | 02:12 |
| thumper | lifeless: and I did it | 02:12 |
| jelmer | mwhudson: I think that might be possible by doing the right thing in findmissing() | 02:12 |
| lifeless | thumper: ah! For some reason I thought it hadn't been done. | 02:12 |
| lifeless | thumper: sorry! | 02:12 |
| thumper | lifeless: it has been so long I've forgotten when I did it | 02:12 |
| jelmer | thumper: not yet, I need to spend some quality time with a particular branch that's failing to figure out what's going wrong | 02:12 |
| jelmer | thumper: and preferably write some tests that demonstrate the problem, that bit is probably the hardest | 02:13 |
| thumper | jelmer: ok | 02:24 |
| * mwhudson is completely confused | 02:29 | |
| mwhudson | making a method which is called in one place which doesn't look at the return value return something causes tests to fail | 02:30 |
| mwhudson | ooh | 02:31 |
| * mwhudson slaps himself | 02:31 | |
| mwhudson | jelmer: findmissing() is fairly opaque to me :/ | 02:36 |
| * mwhudson stares at it some more | 02:36 | |
| thumper | mwhudson: what are you doing? | 02:37 |
| mwhudson | thumper: incremental imports for bzr-hg | 02:38 |
| thumper | ah | 02:38 |
| * thumper is still doing code review comment emails... | 02:45 | |
| jtv | wgrant: bob seems to think it's building for me | 02:46 |
| wgrant | jtv: I saw your bug reports that implied that, yeah. | 02:48 |
| wgrant | Is it actually working? | 02:48 |
| jtv | no | 02:48 |
| wgrant | :( | 02:48 |
| wgrant | What does the slave think it's doing? | 02:48 |
| jtv | that's what I wanted to ask you: is there anything more to look at slave-side than the launchpad-buildd.log? | 02:49 |
| wgrant | jtv: No. That's all there is. | 02:50 |
| jtv | and I just zapped that for my next attempt :) | 02:50 |
| wgrant | But it should give you lots of information. | 02:50 |
| jtv | I can go through the setup pretty quickly now though | 02:51 |
| jtv | There wasn't much in it last time | 02:51 |
| wgrant | Why are you reinstalling each time? | 02:51 |
| jtv | Am I? | 02:53 |
| jtv | I mean, I'm reinstalling every time I reinstall, obviously, but... | 02:54 |
| wgrant | Why do you have to go through the setup again? | 02:56 |
| * NCommander wonders if anyone can explain why we keep copyright file contents in the database and not in librarian | 02:58 | |
| wgrant | NCommander: I asked that myself. | 02:58 |
| NCommander | wgrant: was there an answer? | 02:58 |
| wgrant | NCommander: No. | 02:58 |
| jtv | wgrant: various reasons. So far I haven't had to re-do the slave setup at all. | 02:59 |
| jtv | I have had to reboot a few times though. | 02:59 |
| jtv | wgrant: in many cases I had changes I _could_ just patch through without re-doing anything, but didn't want to because I'm trying to write up something reproducible. It's easy to mess that up without knowing it. | 03:01 |
| mwhudson | i don't like the mercurial code very much :/ | 03:01 |
| wgrant | jtv: Ah, right. | 03:02 |
| jtv | wgrant: for example, between henning's work and mine we had a case where for him "dpkg -i <package> ; apt-get -f install" worked, and for me the other way around worked, because the --force-depends was missing from the dpkg command line. | 03:03 |
| jtv | We'd like one order that works for everyone, but differences in our setup hid the problem in different ways | 03:03 |
| wgrant | The dpkg, apt-get order should always work. | 03:04 |
| wgrant | If it doesn't, give me examples because I don't believe you :P | 03:04 |
| jtv | Note the bit where I said --force-depends was missing... | 03:06 |
| jtv | if you do dpkg -i first, well, launchpad-buildd won't install because the dependencies aren't there | 03:06 |
| jtv | if you do apt-get -f first, I don't think there's necessarily anything there that'll make it install all dependencies | 03:07 |
| jtv | for the package you have yet to install | 03:07 |
| jtv | ...or maybe other stuff was broken in my case, which is the sort of thing you get when you don't re-do from scratch from time to time, which was my original point :-) | 03:08 |
| wgrant | dpkg -i should keep the package installed but unconfigured. | 03:08 |
| wgrant | Then apt-get -f install will satisfy the dependencies and finish installation. | 03:08 |
| jtv | dpkg -i leaves it unconfigured? | 03:09 |
| wgrant | If the dependencies are not satisfied, yeah. | 03:09 |
| jtv | Anyway, when you do dpkg -i first, it refuses service because the dependencies aren't there, doesn't it? | 03:09 |
| jtv | The --force-depends forces it to break things, and then the apt-get -f can fix the deliberate breakage | 03:09 |
| wgrant | It probably looks like it refuses, but it actually lets it go half way. | 03:10 |
| jtv | ah, like so | 03:11 |
| jtv | wgrant: meanwhile, it seems as if my job has stopped cold somewhere below the radar :( | 03:21 |
| jtv | The buildd-manager log says it's dispatching. The slave log says nothing. | 03:21 |
| jtv | Maybe the previous instance of the slave, which I killed a little late, grabbed it. | 03:21 |
| wgrant | jtv: Is buildd-manager repeatedly dispatching it? | 03:22 |
| jtv | no, just once | 03:22 |
| wgrant | And can you see buildd-manager currently polling in the slave log? | 03:22 |
| jtv | The launchpad-buildd log on the slave ended with "daemon ready." | 03:24 |
| jtv | So I think it went to the wrong buildd instance... I'm retrying. | 03:24 |
| jtv | wgrant: marking Bob as not-OK is not stopping its ongoing job this time... | 03:43 |
| jtv | Does changing the OK setting POST to the slave on xmlrpc? | 03:44 |
| wgrant | jtv: Only buildd-manager can talk XML-RPC to the slave. | 03:44 |
| wgrant | Marking it not-OK will stop scanning. | 03:44 |
| wgrant | It will not touch the slave, but it should deassign the job in the UI. | 03:44 |
| wgrant | And when you mark the builder OK again, buildd-manager should declare the builder lost (since it's building an unassigned job), and abort the builder. | 03:45 |
| wgrant | The lost builder detection may not work in this case, however. | 03:45 |
| jtv | That sounds plausible | 03:46 |
| jtv | what would break it? | 03:46 |
| wgrant | It being crap. | 03:46 |
| * wgrant finds the bug. | 03:46 | |
| jtv | wgrant: ahhhh, _that_ explains _everything_! :-) | 03:46 |
| wgrant | Bug #463041 | 03:47 |
| mup | Bug #463041: Lost builder detection is insufficiently aggressive <buildd-manager> <Soyuz:Triaged> <https://launchpad.net/bugs/463041> | 03:47 |
| wgrant | Is there a way to make a @stepthrough consume multiple segments? | 03:47 |
| wgrant | I want a @stepthrough method to take multiple arguments, without having to create intermediate objects. | 03:48 |
| * thumper stabs his tests | 03:48 | |
| mwhudson | wgrant: i think you need to write your own navigation (?) to do that | 03:50 |
| mwhudson | there's something more general than @stepthrough, anyway | 03:51 |
| wgrant | The closest thing I can think of is that BranchNamespace thingy. | 03:51 |
| mwhudson | yeah | 03:52 |
| * jtv has to be off for a bit | 03:53 | |
| mwhudson | lp.registry.browser.person.BranchTraversalMixin | 03:53 |
| wgrant | mwhudson: Ah, thanks. | 03:54 |
| thumper | gah | 03:56 |
| thumper | grrr | 03:56 |
| thumper | testing jobs is a PITA | 03:56 |
| wgrant | It seems sort of evil, but it might work. | 03:56 |
| jtv | amen to that | 03:59 |
| * mwhudson EODs | 04:22 | |
| * thumper waves at mwhudson | 04:23 | |
| * thumper sprinkes some removeSecurityProxy around | 04:28 | |
| mwhudson | heh heh | 04:30 |
| poolie | thumper: did robert ask you yesterday what happens if you set a bmp to state 'queued'? | 04:43 |
| poolie | does the world end? does the ui cope? | 04:43 |
| thumper | poolie: he did | 04:43 |
| thumper | poolie: I suggested that he shouldn't | 04:43 |
| thumper | poolie: weird shit may happen | 04:44 |
| thumper | it might work | 04:44 |
| thumper | it might not | 04:44 |
| lifeless | poolie: thumper also said that staging would probably be a good enough indication | 04:44 |
| thumper | it should | 04:44 |
| lifeless | of what weird shit would happen | 04:44 |
| thumper | it'll either work or not | 04:44 |
| thumper | staging should be able to tell you | 04:44 |
| * persia wonders of !ohmy is supposed to apply in launchpad channels | 04:46 | |
| wgrant | It is often violated here, but it seems unproblematic. | 04:48 |
| lifeless | !ohmy? | 04:49 |
| wgrant | !ohmy | 04:49 |
| wgrant | No bot :( | 04:49 |
| lifeless | so | 04:54 |
| lifeless | what doth it mean? | 04:55 |
| wgrant | 15:55:19 <ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. | 04:55 |
| lifeless | ah | 04:55 |
| thumper | persia: NZ has a slightly more relaxed attitude to swearing | 04:56 |
| thumper | persia: there are several prime time adds that use "bugger" and "bloody idiot" | 04:57 |
| thumper | sorry if I offended anyone | 04:57 |
| persia | thumper: I'm sure. I don't claim that ohmy applies here, just asking. Mostly because of e.g. http://irclogs.ubuntu.com/2010/03/11/#launchpad-dev.txt | 04:57 |
| thumper | 'twas not my intention | 04:57 |
| * persia certainly isn't offended, but is so used to typing !ohmy in other channels, that the message had to be erased before the query | 04:58 | |
| thumper | which bit? | 04:58 |
| lifeless | persia: I don't see the thing that triggered you to say that | 05:00 |
| poolie | lifeless: i think you meant to say "wtf does that mean?" :) | 05:00 |
| poolie | the s-word | 05:00 |
| * thumper EODs | 05:00 | |
| thumper | later people | 05:00 |
| poolie | cheerio | 05:00 |
| poolie | thump em and thump em again | 05:01 |
| lifeless | oh, wow. | 05:01 |
| persia | heh | 05:01 |
| poolie | persia: i think we share that attitude but i don't think tim's expression trips it | 05:04 |
| poolie | this may just show i need sensitivity training | 05:04 |
| wgrant | In some channels it does. | 05:04 |
| lifeless | as colloquial for 'things' 'my shit', 'weird shit' etc are pretty ingrained. 'your shit' would be an aggressive use and would trip my bad-censor | 05:05 |
| lifeless | I blame the US for popular culture and tv shots. | 05:05 |
| lifeless | s/shots/shows/ | 05:05 |
| persia | poolie: Personally speaking, I'm open to lots of expressions. That said, I've seen long-winded arguments about usage of terms, and self-admitted 8-year-old people in some development channels. | 05:05 |
| * persia agrees with lifeless | 05:05 | |
| === jamalta is now known as jamalta-afk | ||
| lifeless | ok, EODing | 05:07 |
| poolie | bye | 05:09 |
| NCommander | where can I get a log of the local keyserver? I'm getting a 500 when I try to create a soyuz user | 06:03 |
| * persia has a sense that the query is dropping into the nebulous dark span that lies between NZ and EU timezones | 06:06 | |
| NCommander | nm, got it by killed twistd and restating everything | 06:08 |
| * wgrant appears. | 06:58 | |
| wgrant | NCommander: It all ended up working? | 06:58 |
| NCommander | wgrant: when applied a heavy enough wrench, although the soyuz script didn't add my GPG key to the ppa-user, and I'm getting issues with rejection based on "Can not build for architecture: any" | 06:59 |
| wgrant | NCommander: You specified the right email address? | 07:01 |
| wgrant | The "Cannot build for architecture" thing normally means that your DASes either aren't enabled for virtualisation, or do not have chroots. | 07:01 |
| NCommander | wgrant: yes, and the key posted to the internal keyserver | 07:02 |
| NCommander | wgrant: it might have gotten confused though, I have my keys on a GPG smartcard | 07:02 |
| wgrant | Hmm. | 07:02 |
| NCommander | which makes gpg --list-keys look a bit different | 07:02 |
| wgrant | Ah. | 07:02 |
| NCommander | wgrant: second BTW, for pygpgme, there's a patch in the archive that fixes it | 07:02 |
| wgrant | jtv: Did you have any more luck with the slave? | 07:03 |
| wgrant | NCommander: We don't use the archive version :( | 07:03 |
| jtv | wgrant: no... | 07:03 |
| NCommander | wgrant: right, but that patch can just be applied to the version in the tree | 07:03 |
| wgrant | jtv: You didn't try, or it didn't work? | 07:03 |
| NCommander | wgrant: I would do it, but I know diddly about pushing to launchpad-pqm or doing a review on an external component | 07:03 |
| jtv | wgrant: I didn't try, and waiting didn't help either :) | 07:04 |
| jtv | (helping out with something urgent here) | 07:05 |
| wgrant | Ah. | 07:05 |
| NCommander | wgrant: can you help me get ready to push my first changes to LP? I have a database change that needs to be made, and I'm kinda confused on how I edit the schema | 07:05 |
| wgrant | NCommander: Sure. What's the change? | 07:05 |
| NCommander | wgrant: first pat of implemented raw source changelogs | 07:06 |
| NCommander | wgrant: the part I wrote causes new packages to have the changelog stripped out and put in the database | 07:06 |
| NCommander | on upload | 07:06 |
| wgrant | NCommander: ie. new column SPR.changelog -> LFA.id? | 07:06 |
| NCommander | wgrant: no. just SPR.changelog | 07:07 |
| NCommander | per bigjools and sadbfl's comments | 07:07 |
| wgrant | But changelogs get unsmall. | 07:07 |
| persia | THey don't "get" unsmall, they are by default. Still : https://bugs.edge.launchpad.net/soyuz/+bug/139028/comments/1 | 07:09 |
| mup | Bug #139028: SPR.changelog should be renamed to 'changelog_entry' <soyuz-core> <trivial> <Soyuz:Fix Released by julian-edwards> <https://launchpad.net/bugs/139028> | 07:09 |
| wgrant | Hmm. | 07:11 |
| wgrant | Has the DBA been consulted? | 07:11 |
| lifeless | pep8 names are preferred | 07:12 |
| lifeless | if thats your concern | 07:12 |
| wgrant | lifeless: I'm more wondering about the storing large strings in the DB thing. | 07:13 |
| NCommander | wgrant: well, worse case, I rewrite a bit of code, and some comments :-) | 07:13 |
| wgrant | stub: Do you have an opinion on this? | 07:13 |
| NCommander | wgrant: while we wait, maybe you can explain how do I integrate a schema change? I've already gotten the bit htat I need db-devel | 07:26 |
| wgrant | NCommander: Ah, right. I tried to find the wiki page, but then U1 ate my bandwidth. | 07:28 |
| wgrant | I've killed it, so maybe it will work better this time. | 07:28 |
| wgrant | I believe that https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess is the latest. | 07:29 |
| NCommander | wgrant: cool, so now I need to learn how to interact better with bzr | 07:31 |
| * NCommander reads on bzr loom | 07:32 | |
| wgrant | NCommander: I prefer pipeline these days. | 07:33 |
| NCommander | wgrant: pipeline? | 07:33 |
| * NCommander admits he perfers git when dealing with non-trivial archives | 07:33 | |
| wgrant | NCommander: https://launchpad.net/bzr-pipeline | 07:33 |
| wgrant | NCommander: Why? | 07:33 |
| NCommander | wgrant: git rebase is my best friend with dealing with local trees before submisison | 07:35 |
| wgrant | NCommander: Ew. | 07:36 |
| wgrant | History destruction is revolting. | 07:36 |
| wgrant | (but bzr can rebase too) | 07:36 |
| NCommander | wgrant: having all of ones changes ontop of the history is very handy | 07:36 |
| NCommander | But we digress | 07:36 |
| * NCommander decides not to bother with looms or pipeline with this change | 07:37 | |
| adeuring | good morning | 08:21 |
| * thumper prefers pipelines too | 08:25 | |
| stub | Whoops. | 08:26 |
| lifeless | thumper: different use cases | 08:29 |
| lifeless | thumper: hey, how is your bzr using project going | 08:29 |
| thumper | lifeless: slowly | 08:29 |
| thumper | lifeless: how to I create a preview tree for a particular revision? | 08:29 |
| thumper | lifeless: I want to commit to it | 08:29 |
| thumper | lifeless: and either pull or merge into the main branch | 08:30 |
| stub | wgrant, NCommander: (from 1 hour 15 mins ago) It depends :-) changelogs are not that big. If we want to search on them, they certainly can go in the database. If we don't, we are juggling the convenience of stuffing them in the database vs. sticking them in the librarian. I want to keep binary blobs out of the database, so if the text is in an unknown encoding it should definitely get stuffed in the Librarian. | 08:31 |
| lifeless | thumper: a preview tree is the result of a merge done into a revision tree AIUI | 08:32 |
| lifeless | thumper: so I'd look at the pipeline pump code | 08:32 |
| thumper | lifeless: ok | 08:32 |
| thumper | lifeless: a revision tree is tree based on a revision? | 08:32 |
| lifeless | you can commit from the transform I believe | 08:32 |
| thumper | lifeless: can you commit to a revision tree? | 08:33 |
| lifeless | thumper: a revision tree - b.basis_tree(), or b.repository.revision_tree(arbitrary_revid) | 08:33 |
| lifeless | thumper: no | 08:33 |
| lifeless | revision trees are immutable | 08:33 |
| lifeless | 'MutableTree.commit()' commits a new tree to a branch. | 08:33 |
| NCommander | stub: we already have copyright in the database and the encoding is guessed (although I realize that kinda is hit or miss). sabdfl made a comment that we should stuff it in the DB already as well | 08:33 |
| lifeless | thumper: give my phone a ring; just going for a walk and voice will sort this quicker | 08:33 |
| NCommander | stub: plus I want to retroactively add all the past changelogs, which is going to be about 5 GiB when done | 08:33 |
| stub | NCommander: What do we do with them once they are stuffed in the database? Are we going to display them inline in the web UI or similar? | 08:34 |
| NCommander | stub: ideally | 08:35 |
| stub | If we are guessing encoding, is there a use case for keeping an unadulterated copy in the Librarian (eg. are they GPG signed) | 08:35 |
| NCommander | stub: the file ripped out of the source package, the original can always be retrieved there | 08:35 |
| NCommander | stub: right now, the code just exists to put them in the database. I need to talk to bigjools and persia on how we want to change +changelogs and the SRP page specifically. | 08:35 |
| stub | Yup. Also, do we want to store the entire changelog (a potential DOS perhaps), or truncate it to some sane limit. | 08:36 |
| wgrant | We pretty much need the whole thing. | 08:36 |
| * NCommander thinks wgrant can explain better than I can | 08:37 | |
| wgrant | Since we need to be able to produce an Ubuntu->Debian changelog delta. | 08:37 |
| stub | Basic procedure for altering the schema is to create a database/schema/patch-2207-99-0.sql file containing a sequence of CREATE TABLE, ALTER TABLE etc. DDL commands. The first line and last line are dead chickens you can steal from one of the other patches. When requesting a review, request 'db' reviews from me (stub) and bjorn (bjornt). | 08:38 |
| stub | So if I upload a sourcepackage to my PPA that when uncompressed contains a 60GB changelog.... ? | 08:38 |
| wgrant | Right, we're screwed. | 08:39 |
| thumper | lifeless: sorry, called away | 08:39 |
| thumper | lifeless: I'll talk to you tomorrow about it | 08:39 |
| stub | I suspect we do want some limit. Just pick an arbitrary number we won't hit except in case of a) major screwup or b) attack. | 08:39 |
| jtv | wgrant: meanwhile, on my simulated buildd, I've deleted the job that was in the way but my own is just not getting picked up. :( Still sits there w status 0 | 08:39 |
| NCommander | er | 08:39 |
| * NCommander coughs | 08:39 | |
| wgrant | jtv: What does the query do? | 08:39 |
| jtv | wgrant: the candidate selection query? | 08:40 |
| noodles775 | jtv: put a break point in the candidate selection and follow it through. | 08:40 |
| jtv | Last time I tried that, it worked. Maybe it's failing for some new reason. | 08:40 |
| noodles775 | Aha. | 08:41 |
| stub | NCommander: Of course, the 2GB limit on a text column is the arbitrary limit if you don't set one, so it probably doesn't matter. | 08:41 |
| NCommander | stub: ugh :-/. | 08:41 |
| noodles775 | jtv: related to bug 536797 | 08:42 |
| mup | Bug #536797: Builder pages break for job without build <wellington> <Soyuz:New> <https://launchpad.net/bugs/536797> | 08:42 |
| jtv | noodles775: no, it's before it gets to that | 08:42 |
| noodles775 | jtv: I think it's straight forward to ensure that the builder index works for your jobs, but the harder part is how we present the history. | 08:42 |
| NCommander | stub: thats really nasty :-/ | 08:42 |
| noodles775 | jtv: (no, I have a question about it ;)). | 08:42 |
| jtv | ah :) | 08:43 |
| jtv | (al-maisan, what's supposed to happen right after this query? SELECT SUM(BuildQueue.estimated_duration) FROM Archive, Build, buildpackagejob, BuildQueue, DistroArchSeries, Processor WHERE buildpackagejob.job = BuildQueue.job AND buildpackagejob.build = Build.id AND Build.distroarchseries = DistroArchSeries.id AND Build.archive = Archive.id AND DistroArchSeries.processorfamily = Processor.family AND Build.buildstate = 0 AND Archive.ena | 08:43 |
| jtv | ) | 08:43 |
| noodles775 | jtv: Currently the builder histor relies on the builds (as they are the only permanent record that something happened on the builder), but I'm guessing we'll need to modify it to instead rely on BuildFarmJob records, and not delete those immediately. Let me know what you think (you too wgrant) and I'll update the bug. | 08:44 |
| jtv | noodles775: I think I see what you mean. Yes, getting this right is going to be an interesting question; it also came up in the sprint. My immediate worry was getting it not oopsing though. :-) | 08:44 |
| al-maisan | jtv: where's that query from? | 08:44 |
| wgrant | noodles775: I think we'll have to present each Job, with adapters for each type. | 08:44 |
| jtv | al-maisan: the buildd manager | 08:44 |
| jtv | I agree with wgrant | 08:44 |
| wgrant | noodles775: Hmm, I guess TTBJs don't actually have a builder once the BuildQueue dies, do they? | 08:44 |
| jtv | (I have it not oopsing for now) | 08:44 |
| noodles775 | wgrant: nope, we'd need to defer the deletion of those, perhaps truncating the history to 1000 BuildFarmJobs or something. | 08:45 |
| wgrant | I think we have too many tables. | 08:45 |
| noodles775 | +1 | 08:46 |
| wgrant | noodles775: Why truncate them? | 08:46 |
| noodles775 | wgrant: at the moment we delete the BFJ, Job, QueueItem etc. once the (soyuz) build completes. | 08:46 |
| wgrant | noodles775: I think just the BuildQueue is deleted. | 08:46 |
| wgrant | The other three (Build, BPJ, Job) should survive. | 08:46 |
| wgrant | I hope. | 08:46 |
| * wgrant checks. | 08:47 | |
| noodles775 | Yes, the Build is permanent of course, but I'd thought the others were deleted, but haven't checked. Doing so now too. | 08:47 |
| jtv | wgrant: there's some propagation of deletions in the python though | 08:48 |
| wgrant | noodles775: BuildBase appears to kill the buildqueue. | 08:48 |
| wgrant | But not the others. | 08:48 |
| lifeless | thumper: de nada | 08:48 |
| wgrant | Oh. | 08:48 |
| wgrant | But the BuildQueue kills the rest. | 08:48 |
| wgrant | Damn. | 08:49 |
| noodles775 | Yep. | 08:49 |
| wgrant | I think we should just keep them all. | 08:49 |
| al-maisan | FWIW: we also discussed briefly *not* deleting the BuildQueue records upon job completion and putting in place a purge mechanism that deletes them after some configurable period of time (e.g. a month) | 08:49 |
| wgrant | We are going to have at least three five rows in other tables from each build for eternity anyway. | 08:49 |
| wgrant | So three extra very tiny rows for each really shouldn't make much difference... | 08:50 |
| NCommander | stub: so no issue with changelog in database aside from a sanity check on size? | 08:50 |
| wgrant | Er, s/three // in that first sentence. | 08:50 |
| wgrant | al-maisan: IIRC we argued this during the sprint, and nobody brought up a compelling reason to purge them. | 08:51 |
| al-maisan | wgrant: data volume? | 08:51 |
| wgrant | al-maisan: It's trivial compared to the other stuff we store for each build. | 08:52 |
| noodles775 | jtv: so you've got a branch that ensures the builder-index doesn't oops for jobs without builds? | 08:52 |
| wgrant | (the build, build log, changes file, upload entries...) | 08:52 |
| jtv | noodles775: yes | 08:52 |
| jtv | not pretty, but... | 08:53 |
| wgrant | jtv: Does it just not link them if they have no build attribute? | 08:53 |
| stub | NCommander: Should be fine. (Assuming this is SourcepackageRelease) We probably want to split out the bulk data from SourcepackageRelease such as copyright, dsc_* etc. into a seperate table as it is getting pretty fat. Fine in theory, but because we use an ORM we generally load all columns even when we don't need them. | 08:53 |
| wgrant | al-maisan: Plus, if we keep some of the others than we can trim Build. | 08:54 |
| al-maisan | wgrant: I am inclined to agree .. however: we currently operate on a BuildQueue table with a very *small* number of rows and if that were to change we may see some performance issues | 08:54 |
| NCommander | stub: ugh :-/. So maybe make a sourcepackagerelease_metadata in the nearish future? | 08:54 |
| jtv | wgrant: close. It names the job type and says there's no build for it; and it shows the log regardless of who you are. | 08:54 |
| stub | NCommander: Yes, but with a name that doesn't suck :) | 08:54 |
| bigjools | morning guys | 08:54 |
| NCommander | stub: I'm from the platform team, we have a bad history of sucky names. (i.e., bundles, petals, leafs, etc. :-)) | 08:54 |
| wgrant | Morning bigjools. | 08:54 |
| noodles775 | Morning bigjools | 08:55 |
| al-maisan | Good morning bigjools | 08:55 |
| wgrant | NCommander: Heh, I remember that discussion. | 08:55 |
| stub | NCommander: It might not be a problem in reality - it depends if we have pages that load a large number of SourcePackageRelease records | 08:55 |
| NCommander | stub: suggestions welcome | 08:55 |
| NCommander | stub: no, its usually just loaded one at a time except for +copy-packages (I think) | 08:55 |
| stub | SourcePackageReleaseData sucks less in my opinion | 08:55 |
| wgrant | NCommander: It's a lot more than that, sadly. | 08:55 |
| wgrant | NCommander: Anything that displays a version number is loading an SPR to get it. | 08:56 |
| NCommander | wgrant: ugh. Maybe I'll make mychangeset grow so we only need one or two hits against db-devel | 08:56 |
| NCommander | wgrant: ow. | 08:56 |
| stub | But that can be future anyway - mention it in the review request and open a bug if you can be bothered. | 08:56 |
| lifeless | hey | 08:56 |
| * NCommander remember he could make the database timeout by access the archive copy-package page | 08:56 | |
| lifeless | is there a 'create a project' API script yet ? | 08:56 |
| NCommander | Doing the near-equivelent ofSELECT * FROM SourcereleasePackages didn't make the database happy :-) | 08:56 |
| wgrant | bigjools: Do you have an opinion on preserving the buildqueue, job and specificjob for completed builds? | 08:57 |
| bigjools | NCommander: that happens because it does a lot of checks | 08:57 |
| bigjools | wgrant: strongly against preserving | 08:57 |
| wgrant | :( | 08:58 |
| wgrant | kfogel: Hm, that single "Merging db-stable" is interesting. | 09:00 |
| wgrant | Not sure why that is. | 09:00 |
| bigjools | wgrant: why has this come up? | 09:03 |
| wgrant | bigjools: There was a little bit of a discussion about how to present a generalised history. | 09:04 |
| mrevell | Morning | 09:05 |
| bigjools | those table rows are cruft once the job is done. We should find a better way of keeping history. | 09:06 |
| bigjools | and I really, really like having a single table that contains all the waiting jobs | 09:06 |
| wgrant | bigjools: OK, so maybe BuildQueue could be purged. But the Job seems useful. | 09:07 |
| wgrant | (in the current model, all record of a translations job is destroyed once the build completes) | 09:08 |
| bigjools | doesn't it have build records? | 09:08 |
| wgrant | I don't believe so. | 09:09 |
| wgrant | jtv: ^^? | 09:09 |
| * jtv reads | 09:09 | |
| jtv | nope | 09:10 |
| jtv | No builds. | 09:10 |
| bigjools | it should do! | 09:10 |
| jtv | Would they be the same kind of build records? Do build records need to go into buildfarm? | 09:10 |
| * jtv wonders if we should have a buildfarm team | 09:10 | |
| bigjools | please no more teams :) | 09:11 |
| bigjools | so noodles775 and I discussed last night that we would rename Build -> BinaryBuild and then a new Build table would have common fields from all build types | 09:11 |
| wgrant | kfogel: Ah! They were merged in db-devel r8326, which is the rev before the one c-c.py listed as being the first merge. | 09:12 |
| lifeless | wgrant: pop quiz, connecting lplib to staging | 09:12 |
| bigjools | having persistent data hanging around in a set of tables that represent a queue is crack IMO | 09:12 |
| jtv | bigjools: and those will stay around "forever"? | 09:12 |
| bigjools | jtv: yes | 09:12 |
| noodles775 | bigjools: but that's only really suitable for SPRecipeBuilds and BinaryBuilds... not for the TranslationTemplatesBuildJob tyep. | 09:13 |
| noodles775 | I thought. | 09:13 |
| wgrant | lifeless: Launchpadlib.login_anonymously('your app', 'staging') | 09:13 |
| wgrant | bigjools: Does Job represent a queue? | 09:13 |
| * noodles775 reads the back-scroll. | 09:13 | |
| bigjools | noodles775: if that's the case then we should take a look | 09:13 |
| lifeless | wgrant: is there a constant like EDGE_SERVICE_ROOT ? | 09:13 |
| bigjools | wgrant: no, but buildqueue does :) | 09:13 |
| wgrant | bigjools: right. | 09:13 |
| jtv | well, all 1:1 anyway in the cases we care about... | 09:14 |
| wgrant | lifeless: I think they're deprecated by the simple strings. But yes, STAGING_SERVICE_ROOT should exist. | 09:14 |
| jtv | bigjools, noodles775: anyway the new Build could be just an id to hold things together and still be useful. | 09:15 |
| bigjools | jtv: id, builder are the 2 main things | 09:15 |
| noodles775 | OK, so if there was a build for TranslationTemplatesBuildJob's then that would enable us to generalise for all three build farm job types. | 09:15 |
| lifeless | wgrant: is there any convention for environment variables to control this? | 09:15 |
| jtv | bigjools: I'm sure there's stuff like dates that would otherwise perish with the more transient job/buildqueue rows | 09:15 |
| noodles775 | But I think we need to think through this carefully. | 09:15 |
| bigjools | yes very carefully | 09:16 |
| jtv | why? hack the thing up & roll it out I say! | 09:16 |
| lifeless | wgrant: like LAUNCHPAD_API=staging | 09:16 |
| jtv | phone | 09:16 |
| noodles775 | lol | 09:16 |
| wgrant | lifeless: Not sure. | 09:16 |
| * lifeless makes one up | 09:16 | |
| === jtv is now known as jtv-otp | ||
| bigjools | jtv: date is also another good one :) | 09:16 |
| * noodles775 updates the relevant bugs trying to summarise. | 09:16 | |
| wgrant | noodles775, bigjools: Why Build rather than Job? | 09:16 |
| jtv-otp | wgrant: lets us denormalize to our little hearts' content | 09:17 |
| jtv-otp | s | 09:17 |
| wgrant | All build farm jobs might not always be Builds. | 09:17 |
| al-maisan | the actual build duration is another piece of data for the generic `Build` table | 09:17 |
| bigjools | build farm jobs might not always be Jobs | 09:17 |
| bigjools | no wait :) | 09:17 |
| bigjools | Jobs might not always be build farm jobs, is what I meant to say | 09:17 |
| wgrant | And indeed they are not. True. | 09:18 |
| wgrant | So.. we need BuildFarmJob? | 09:18 |
| bigjools | or... Build :) | 09:18 |
| bigjools | which is the same thing | 09:18 |
| bigjools | but it could be called BuildFarmJob | 09:18 |
| wgrant | I thought you were averse to the idea of calling something Build ever again. | 09:18 |
| bigjools | I'm not precious about it | 09:18 |
| wgrant | I think we need a good list of all the columns on all the tables, and what we need to keep. | 09:19 |
| wgrant | Is there such a thing around? | 09:19 |
| bigjools | I don't even remember what I did yesterday so if I said that then great :) | 09:19 |
| bigjools | such a thing is the db schema. no? | 09:20 |
| wgrant | The second point is a subjectively processed version of the DB schema. | 09:20 |
| bigjools | if we could factor stuff out, that'd be great | 09:20 |
| bigjools | yeah it needs analysis | 09:20 |
| lifeless | wgrant: thanks | 09:21 |
| noodles785 | Not that I know of, I'll try to create something like http://people.canonical.com/~michaeln/bfb/sourcepackagerecipe.png for the build/queue related tables today, if it's helpful. | 09:22 |
| === noodles785 is now known as noodles775 | ||
| bigjools | noodles775: if it's easy, yes please | 09:23 |
| lifeless | now thats fairly cool | 09:23 |
| lifeless | oauth tokens for edge work on staging | 09:24 |
| bigjools | noodles775, wgrant, jtv-otp: Job on its own is too generic for a build farm job. I'd even be happy to ditch our use of Job and migrate to BuildFarmJob completely. | 09:25 |
| wgrant | bigjools: Yeah, quite possibly. | 09:25 |
| lifeless | call it task | 09:25 |
| lifeless | that way you can really confuse people | 09:25 |
| bigjools | I've never been really happy with using Job | 09:26 |
| jtv-otp | bigjools: that whole subsystem needs a cleanup... not sure I'd enjoy yet more duplication | 09:26 |
| bigjools | I felt press-ganged into using it | 09:26 |
| wgrant | It never seemed like a really good idea to use it. | 09:26 |
| wgrant | We do not use much of it. | 09:27 |
| bigjools | I continually fail to see the duplication between Job and build farm jobs | 09:27 |
| bigjools | someone wanted the buildd manager to become more like a job runner | 09:27 |
| bigjools | it's not going to happen | 09:27 |
| === jtv-otp is now known as jtv | ||
| jtv | bigjools, wgrant: I'm not sure the Job runner uses most of what you see in the schema there either. | 09:40 |
| jtv | My impression is, Job failed to become all it was planned to be, with failover mechanisms that never materialized. Okay, I'm not trying to force anyone to stick with Job, but it'd be nice to have something that everyone could use and be happier for it. Message queue plus log table maybe? | 09:49 |
| jtv | bigjools: unrelated note... what happens to a build slave when its chroot falls out of date? | 09:50 |
| jtv | Would it be noticed at all? Would jobs still be dispatched to it? | 09:51 |
| * persia has seen the results of such dispatches | 09:53 | |
| persia | Dunno if it still can happen | 09:53 |
| jtv | wgrant, could this be related to my buildd stuckage? lib/canonical/twistedsupport/processmonitor.py:254: twisted.internet.error.PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. | 09:57 |
| jtv | persia: what did those results look like? I'm talking about my local system, so weeeird things can happen :) | 09:58 |
| persia | jtv: Generally FTBFS because the build-deps couldn't be installed. | 10:03 |
| jtv | persia: hmm... so sounds like it wouldn't affect me. | 10:04 |
| persia | jtv: chroot-out-of-date shouldn't do anything particularly odd, other than make the build take longer. | 10:05 |
| jtv | persia: because of the apt-get update? I'm skipping those in this case, re-using the same slave in the same state, so I guess for my case even that wouldn't apply. | 10:06 |
| bigjools | jtv: sorry was otp | 10:06 |
| jtv | it happens | 10:06 |
| jtv | to all of us with hones | 10:06 |
| persia | jtv: There's two bits. The update, and the build-dep install. But yeah, if neither of those breaks because of old-chroot, you shouldn't care. | 10:06 |
| jtv | phones | 10:06 |
| bigjools | jtv: the job runner is being improved all the time, but I see it as orthogonal to the build farm | 10:06 |
| bigjools | jtv: as for chroots, what do you mean by out of date? | 10:07 |
| jtv | persia: ok, thanks; that means I'd better look in other directions for the explanation of my troubles. Thanks! | 10:07 |
| jtv | bigjools: I've got a test setup as per https://dev.launchpad.net/Translations/BuildTemplatesOnLocalBuildFarm (which I'm writing), but this time around my jobs fail to dispatch. | 10:07 |
| jtv | When I restarted everything just now, I got a timeout from an attempt to talk to the Librarian though. | 10:08 |
| jtv | Maybe it's just the order in which I did things. | 10:08 |
| bigjools | jtv: quite possibly | 10:08 |
| bigjools | jtv: the builder does an apt-get dist-upgrade as part of setting up the chroot, BTW | 10:09 |
| jtv | bigjools: as a prelude to dispatch, I guess? | 10:09 |
| bigjools | yes | 10:10 |
| jtv | Or in the actual slave-side FSM? | 10:10 |
| bigjools | well the slave does it as part of kicking off the build | 10:10 |
| jtv | ok, so that's not working I guess until I get my dispatch working | 10:10 |
| bigjools | the chroot comes from the librarian so I guess not :) | 10:11 |
| jtv | I'll try registering my chroot earlier on in the process | 10:13 |
| jtv | okay, my librarian is down. that'll do it. | 10:14 |
| wgrant | jtv: The chroot stuff is all done as part of the build process. | 10:14 |
| wgrant | As long as you've run ensurepresent with that SHA1 before, the librarian doesn't matter. | 10:15 |
| wgrant | (as long as you're not calling ensurepresent again -- are you dispatching manually now, or with buildd-manager?) | 10:15 |
| jtv | buildd-manager | 10:15 |
| lifeless | wgrant: you might like merge_sorted in bzrlib.tsort | 10:15 |
| jtv | wgrant: I'm using manage-chroot; where would ensurepresent be called from? | 10:15 |
| wgrant | jtv: ensurepresent is a buildd XML-RPC. It's called from buildd-manager. | 10:16 |
| wgrant | lifeless: For what? | 10:17 |
| jtv | wgrant: so would that fail right there if the chroot on the slave were out of date _and_ the librarian is down? | 10:17 |
| lifeless | determining the revision thats shallowest | 10:17 |
| lifeless | and/or which ones should show up in a log-like situation | 10:17 |
| wgrant | jtv: "out of date" meaning you've uploaded a new one with manage-chroot.py? | 10:18 |
| wgrant | lifeless: Hmm. Possibly, yes | 10:18 |
| jtv | wgrant: I wouldn't swear to it never having happened since I created this slave image | 10:18 |
| jtv | So I could just create a new slave image, but it takes a while | 10:18 |
| wgrant | Or start the librarian. | 10:19 |
| jtv | Fixing the librarian seems like a better idea. | 10:19 |
| jtv | Exactly. :-) | 10:19 |
| jtv | I've started poppy... what else? | 10:19 |
| jtv | start_librarian? | 10:20 |
| wgrant | make run | 10:20 |
| wgrant | Or that. | 10:20 |
| wgrant | poppy isn't important for you. | 10:21 |
| wgrant | Unless you're uploading source packages with dput. | 10:21 |
| jtv | No, no package uploads for this | 10:21 |
| jtv | I tried make run_codehosting | 10:21 |
| jtv | ...which should have started the librarian. ook. | 10:25 |
| * jtv looks for pidfiles | 10:25 | |
| lifeless | wgrant: how do you say 'me' in LP apis ? | 10:37 |
| wgrant | lifeless: lp.me | 10:38 |
| lifeless | so team.owner = self.launchpad.me? | 10:39 |
| wgrant | lifeless: Yes. | 10:39 |
| * lifeless tries | 10:39 | |
| lifeless | hmm, its not .owner | 10:40 |
| wgrant | Ah, yeah, team_owner | 10:41 |
| lifeless | odd | 10:42 |
| lifeless | oh well | 10:42 |
| lifeless | IPerson claims owner, in the apidoc | 10:42 |
| lifeless | and team claims to extend person | 10:42 |
| wgrant | team has team_owner_link. | 10:42 |
| wgrant | Where do you see IPerson's owner on +apidoc? | 10:43 |
| lifeless | person ... owner 'Link to a person' | 10:44 |
| lifeless | oh, method declaration | 10:44 |
| * lifeless whines about apidoc again | 10:44 | |
| lifeless | I don't think I've seen a more confusing api documentation layout, ever. | 10:44 |
| lifeless | wgrant: any idea what 'team_owner_link: Constraint not satisfied.' actually means? | 10:46 |
| wgrant | lifeless: You're probably trying to unset it on a team, set it on a person, or set it to a Private Membership Team. | 10:47 |
| lifeless | ah, no | 10:48 |
| lifeless | I was trying to something I was sure worked, but apparently not. | 10:48 |
| lifeless | which is to set it's owner to itself. | 10:48 |
| wgrant | What was it? | 10:48 |
| wgrant | Ah. | 10:48 |
| wgrant | No. | 10:48 |
| lifeless | Which means you can't have a trivial anarchy. | 10:48 |
| wgrant | Correct. | 10:48 |
| wgrant | There has to be someone at the root. | 10:48 |
| lifeless | can you do A->B->A ? | 10:49 |
| wgrant | Memberships can't work like that, so ownerships probably can't. But you could try. | 10:49 |
| lifeless | meh, its ok | 10:49 |
| lifeless | I just want to automate all the manual 'good practice' stuff I do on new projects. | 10:49 |
| lifeless | if I was imagining that I did something, thats ok :) | 10:50 |
| deryck | Morning, all. | 11:00 |
| lifeless | how do you say 'project uses launchpad for bug tracking' via API's ? | 11:05 |
| lifeless | likewise 'code is published in bzr branches' etc | 11:09 |
| wgrant | How do I identify a binarypackagerelease's archtag? | 11:09 |
| wgrant | Do I have to go through the build's DAS? | 11:09 |
| deryck | lifeless, you want to set this via the API or just get at the info? | 11:17 |
| lifeless | set it | 11:17 |
| deryck | lifeless, there is official_malone on product, distribution, etc. but it's not exported in the API. | 11:20 |
| lifeless | deryck: exactly :) | 11:20 |
| deryck | :-) | 11:21 |
| lifeless | deryck: in case you're wondering, I hit my DRY threshold for making projects on launchpad. | 11:24 |
| lifeless | I already copy n paste 90% of the docs and settings do that. | 11:24 |
| lifeless | s/do/doing/ | 11:24 |
| deryck | ah, ok. | 11:25 |
| lifeless | while I can think of interesting things to do by reading these settings | 11:26 |
| lifeless | I really do want to set them | 11:26 |
| lifeless | do we have staging codehosting? | 11:27 |
| wgrant | lifeless: Yes. | 11:27 |
| wgrant | lifeless: The branch content isn't copied from prod, but you can push branches up. | 11:27 |
| lifeless | bah | 11:27 |
| lifeless | lp: doesn't seem to support it yet | 11:27 |
| wgrant | lifeless: lp://staging/~blah/blah/blah | 11:28 |
| lifeless | oh, handled in the xmlrpc server side? | 11:28 |
| wgrant | That is all magic to me. | 11:28 |
| wgrant | I haven't bothered to look. | 11:28 |
| wgrant | bigjools: What should the BPRDC URL? The easiest appears to be something like +binaryhits/foo_1.0_i386.deb/2010-03-11/AU | 11:29 |
| lifeless | wgrant: you know far too much about our systems :) | 11:30 |
| lifeless | \o/ | 11:31 |
| lifeless | check out staging.launchpad.net/duh9 | 11:31 |
| wgrant | lifeless: Maybe. | 11:33 |
| lifeless | hmm, maintainer isn't set yet | 11:34 |
| wgrant | That was set up automatically? | 11:34 |
| lifeless | yes | 11:34 |
| lifeless | http://pastebin.org/109632 | 11:35 |
| lifeless | is there a better url than self_link ? | 11:35 |
| wgrant | lifeless: web_link, but that doesn't exist yet. | 11:36 |
| lifeless | is there a bug for that yet ? | 11:36 |
| wgrant | Bug #316694 | 11:37 |
| mup | Bug #316694: Add web_link property to resources <launchpadlib :Triaged> <https://launchpad.net/bugs/316694> | 11:37 |
| lifeless | ok, duh11 has the right maintainer | 11:38 |
| * lifeless commits and proposes for merge | 11:38 | |
| lifeless | wgrant: lp:~lifeless/lptools/lp-project/ if you are interested. | 11:41 |
| * lifeless now uses it to make his project | 11:43 | |
| lifeless | deryck: you might be interested in that script too | 11:44 |
| * deryck looks | 11:44 | |
| lifeless | did we end up turning on auto-list-approval? | 11:49 |
| lifeless | (the answer is yes) | 11:52 |
| bigjools | wgrant: +binaryhits/foo/1.0/20100311/AU would be nicer | 11:55 |
| lifeless | deryck: what do you think ? | 11:56 |
| wgrant | bigjools: Yes, that's sort of what I have now, but the arch is a bit awkward. | 11:57 |
| wgrant | bigjools: Should I just use the archtag of the build DAS? That will be a bit odd for arch-indep? | 11:58 |
| bigjools | hmmm | 11:59 |
| bigjools | it has precedent though | 11:59 |
| wgrant | Where? | 12:00 |
| deryck | lifeless, its nice, definitely. I'll use it myself. :-) | 12:00 |
| === matsubara-afk is now known as matsubara | ||
| lifeless | deryck: :) high complement - thanks | 12:05 |
| didrocks | mars: if you are interested to track the bug we discussed yesterday: bug #537298 | 12:06 |
| mup | Bug #537298: Launchpad make firefox rendering pages very slow with lucid version <Launchpad itself:New> <https://launchpad.net/bugs/537298> | 12:06 |
| === Ursinha-lunch is now known as Ursinha | ||
| bigjools | wgrant: sorry, phone again. Meh, I thought it was used for DASSP[R] but those are linked to publications of course | 12:30 |
| wgrant | bigjools: Yes :( | 12:30 |
| bigjools | wgrant: I can't see any great harm just using the arch-indep though? | 12:31 |
| wgrant | bigjools: ie. i386 instead? | 12:31 |
| bigjools | yes | 12:31 |
| wgrant | I think it is probably ambiguous, although it shouldn't be a problem in practice. | 12:32 |
| wgrant | (think foo_1.0_i386.deb, then foo_1.0_all.deb appears in another upload. | 12:32 |
| * jtv got his job to dispatch again, but has no clue why it fails | 12:34 | |
| wgrant | jtv: What does the slave log say this time? | 12:34 |
| jtv | wgrant: it gets stuck... I snipped copies at the bottom of the wiki page: https://dev.launchpad.net/Translations/BuildTemplatesOnLocalBuildFarm | 12:35 |
| jtv | On the bright side, the librarian was working and it looks as if the slave tried to get the tarball | 12:35 |
| wgrant | jtv: Does the fetch complete? | 12:35 |
| jtv | I don't know. | 12:35 |
| wgrant | sha1sum /home/buildd/filecache-default/f1f10b8402ed686aaf0307676c76f07b45af2a09 | 12:36 |
| jtv | f1f10b8402ed686aaf0307676c76f07b45af2a09 /home/buildd/filecache-default/f1f10b8402ed686aaf0307676c76f07b45af2a09 | 12:36 |
| jtv | (hey, we're a remote terminal session) | 12:36 |
| jtv | $ | 12:36 |
| wgrant | So it worked. | 12:37 |
| jtv | ...yup, that's the sha of my tarball. | 12:37 |
| wgrant | jtv: Can you flip buildd-manager into debug mode? | 12:37 |
| wgrant | I'm not sure if it's any more useful now, but it's worth a try. | 12:38 |
| lifeless | gnight | 12:38 |
| wgrant | Night lifeless. | 12:38 |
| jtv | g'night lifeless | 12:38 |
| jtv | wgrant: how do I do that? | 12:38 |
| wgrant | jtv: s/logging.INFO/logging.DEBUG/ in lib/lp/buildmaster/manager.py, IIRC. | 12:39 |
| jtv | ah | 12:39 |
| * jtv edits | 12:39 | |
| jtv | now that would be a nice thing for the config... | 12:39 |
| jtv | and now I guess I restart the daemon to make it take effect? | 12:40 |
| wgrant | Yes. | 12:41 |
| jtv | seems to be running again, and talking to bob | 12:43 |
| jtv | 010-03-11 19:42:52+0700 [-] Dispatching: <bob:http://localhost:8221/> | 12:43 |
| jtv | 2010-03-11 19:42:52+0700 [-] <bob:http://localhost:8221/> -> ensurepresent((u'f1f10b8402ed686aaf0307676c76f07b45af2a09', 'http://launchpad.dev:58080/93/chroot-ubuntu-lucid-i386.tar.bz2', '', '')) | 12:43 |
| jtv | 2010-03-11 19:42:52+0700 [QueryWithTimeoutProtocol,client] <bob:http://localhost:8221/> response for "ensurepresent": [True, 'Cache'] | 12:43 |
| jtv | And the slave got another Twisted/XMLRPClib post | 12:44 |
| jtv | but now once again everything seems to sit still | 12:44 |
| jtv | Bob is listed as doing "Job of type TranslationTemplatesBuildJob with no associated Build." Which is what I taught it to say. | 12:45 |
| jtv | My job has status 3, so that explains why there's no progress; but why no more scanning? | 12:48 |
| wgrant | What is status 3? | 12:48 |
| jtv | failure iirc | 12:49 |
| jtv | yup | 12:50 |
| jtv | it had that before I restarted the buildd, so why did it re-dispatch? | 12:50 |
| jtv | maybe the best thing is to delete the job, restart the daemons, and retry | 12:50 |
| wgrant | It does what it wants. | 12:50 |
| wgrant | Probably, yeah. | 12:50 |
| jtv | I can confidently confirm that debug output has been enabled... | 12:52 |
| jtv | it's trying to add a bunch of distroarchseries every 5 seconds | 12:53 |
| jtv | loudly | 12:53 |
| jtv | well, here goes nothing! | 12:53 |
| jtv | ensurepresent | 12:54 |
| jtv | xmlrpclib post on slave | 12:55 |
| jtv | silence | 12:55 |
| wgrant | jtv: Yeah, the DAS-driven approach is pretty stupid. | 12:55 |
| jtv | job is marked as started. | 12:55 |
| jtv | damage assessment strike? | 12:55 |
| wgrant | DistroArchSeries. | 12:56 |
| jtv | oh, that would work too | 12:56 |
| wgrant | Fortunately I trialled a branch to remove it, and it worked. | 12:56 |
| wgrant | So... what's the final POST? | 12:56 |
| jtv | 2010-03-11 12:54:33+0000 [HTTPChannel,104,127.0.0.1] 127.0.0.1 - - [11/Mar/2010:12:54:32 +0000] "POST /rpc HTTP/1.0" 200 212 "-" "Twisted/XMLRPClib" | 12:56 |
| jtv | is what the slave says | 12:56 |
| wgrant | Well, how useful. | 12:56 |
| wgrant | What if you call status() on it manually? | 12:56 |
| stub | DistroSeries.getQueueItems tries and fails to return rows in a particular order. This is failing under PG 8.4. Should I just work around the bug by fixing the test? The method is flagged as depricated. | 12:57 |
| jtv | wgrant: what, "make harness," retrieve the slave, and invoke it on that? | 12:57 |
| wgrant | jtv: import xmlrpclib; xmlrpclib.ServerProxy('http://localhost:8221/rpc').status() | 12:58 |
| jtv | ah like that... IDLE | 12:58 |
| wgrant | Hm. | 12:59 |
| wgrant | And it's marked OK in the UI? | 12:59 |
| jtv | but the job still has status 1 | 12:59 |
| jtv | I think that's the part where Build came in... :/ | 12:59 |
| wgrant | jtv: Is the slave code reasonably similar to what's in trunk now? | 13:00 |
| jtv | wgrant: no, I merged henninge's branch; see the top of the page under "patches" | 13:01 |
| wgrant | jtv: I don't see a henning branch there | 13:01 |
| === henninge_ is now known as henninge | ||
| henninge | wgrant: it's henningE ;-) | 13:02 |
| henninge | Although my name *is* Henning | 13:02 |
| jtv | wgrant: hang on, I'll add that right away | 13:02 |
| wgrant | henninge: Right, I just didn't want to ping you unnecessarily. | 13:03 |
| henninge | wgrant: thanks ;-) | 13:03 |
| * henninge has an alarm on henning, too | 13:03 | |
| wgrant | :( | 13:03 |
| * henninge lunches | 13:03 | |
| jtv | wgrant: lp:~launchpad/bug-509557-invoke-pottery | 13:05 |
| wgrant | jtv: s@~@~henninge/@? | 13:05 |
| jtv | wgrant: yes | 13:05 |
| * wgrant looks. | 13:05 | |
| wgrant | jtv: I'd be trying to work out what the XML-RPC call was. | 13:08 |
| wgrant | But I should also be sleeping. | 13:08 |
| jtv | wgrant: both of those make sense | 13:09 |
| jtv | I guess I could just try the state machine. | 13:09 |
| jtv | oh! the slave just showed some activity again | 13:09 |
| wgrant | So it was just hanging for a while? | 13:09 |
| wgrant | Maybe you're not using the state machine properly. | 13:09 |
| jtv | this is with henning's branch that just re-uses the debian builder | 13:10 |
| wgrant | Hm, OK. | 13:10 |
| === mrevell is now known as mrevell-lunch | ||
| wgrant | Anyway, ping me when you're giving up for the day if you can't get it working, and I'll have a poke around myself in a few hours. | 13:10 |
| === salgado is now known as salgado-afk | ||
| jtv | wgrant: I'm being kicked out of here right now, in fact | 13:11 |
| jtv | wgrant: but you mentioned sleep. :) | 13:12 |
| wgrant | Yeah, I should. Uni is forcing me to sleep at reasonable hours for now. | 13:12 |
| wgrant | Night | 13:12 |
| jtv | good night! | 13:13 |
| jtv | damn those fascists | 13:13 |
| NCommander | When building a test case, how do I properly catch something raised so the test passes? | 13:29 |
| * NCommander kills his laptop | 13:40 | |
| allenap | NCommander: Have a look at TestCase.assertRaises() | 13:41 |
| NCommander | allenap: thanks, although I don't seem to be having much luck with it | 13:46 |
| allenap | NCommander: How are you invoking it? | 13:47 |
| NCommander | allenap: the wrong way it seems :-) | 13:47 |
| NCommander | self.FailUnlessRaises(UploadError, self.findCopyright, self.dsc_file, self.tmpdir, mock_logger_quiet) | 13:47 |
| NCommander | (the raise error comes up in a function that findCopyright calls, but changing the arguments to that also fails) | 13:48 |
| allenap | NCommander: Can you paste against LP (I assume this is LP) so I can replicate? | 13:49 |
| allenap | s/paste/paste a diff/ | 13:49 |
| NCommander | allenap: its a set of changes with a database mod, not a small set :-/ | 13:49 |
| === mrevell-lunch is now known as mrevell | ||
| allenap | NCommander: I'm kinda here to help, so it's fine :) If you'd rather plug away at it, I don't mind either :) | 13:52 |
| NCommander | allenap: let me post to launchpad | 13:53 |
| NCommander | allenap: its based off db-devel versus devel, but given my internet connection ATM, this will take awhile | 13:56 |
| NCommander | allenap: lp:~mcasadevall/launchpad/raw_source_changelog | 13:57 |
| NCommander | I think I pushed everything properly w.r.t. to database changes | 13:57 |
| allenap | NCommander: Okay, I'm getting that now. | 13:58 |
| === jamalta-afk is now known as jamalta | ||
| allenap | NCommander: Okay, I have a fix for you I think. | 14:11 |
| NCommander | allenap: I assume you know this, but you can run the test code that breaks with ./bin/test -t lp.archiveuploader.tests.test_dscfile | 14:13 |
| NCommander | :-) | 14:13 |
| allenap | NCommander: The new function findFile() that you've added raises UploadError, whereas errors are yielded elsewhere. | 14:13 |
| allenap | NCommander: I can get the test to pass with http://paste.ubuntu.com/393289/, but I think the callers of findFile need to change. | 14:14 |
| === Chex_ is now known as Chex | ||
| NCommander | allenap: well, I refactored the code this way so I don't have to duplicate code between findChangelog/findCopyright | 14:15 |
| allenap | NCommander: Yes. The way errors are handled - by yielding them - is interesting but a bit weird, so the refactoring in your branch doesn't quite work. I've nearly got a suggestion for you... | 14:17 |
| allenap | NCommander: http://paste.ubuntu.com/393291/ | 14:19 |
| allenap | NCommander: Callers of findFile() must catch UploadError and yield it to their callers. | 14:20 |
| NCommander | allenap: that's ugly, but :-/ | 14:21 |
| allenap | NCommander: Yes it is :) | 14:22 |
| NCommander | allenap: I'm kinda concerned that won't make it through a review :-/ | 14:22 |
| NCommander | allenap: *sigh* NameError: global name 'errors' is not defined | 14:25 |
| NCommander | allenap: (on a second note, how can I land a change for one of the sourcedeps; I have a fix that gets LP going again on lucid) | 14:25 |
| NCommander | allenap: wait, that a fail to save error :-) | 14:26 |
| allenap | NCommander: It's been a while since I did that... First, get an LP dev to add your sourcedep to lp:~launchpad/lp-source-dependencies/trunk, then propose merging an LP branch to update versions.cfg. | 14:27 |
| allenap | NCommander: In findFile(), why do you do os.path.exists()? Does globbing not demonstrate that the name exists? | 14:30 |
| NCommander | allenap: that may just be a case of code being copied; I refactored old code into findFile, I didn't write it | 14:30 |
| allenap | NCommander: Ah, okay, it might be safest to leave it then. | 14:31 |
| bigjools | allenap, NCommander: errors are yielded instead of raised so that we can collect as many as possible to return to the uploader | 14:32 |
| allenap | bigjools: Yeah, the problem NCommander's facing is that it's difficult for helper functions to raise errors; the caller must add boilerplate to catch the error and yield it. It works, it's just ugly. | 14:33 |
| NCommander | bigjools: ah, that explains it | 14:33 |
| bigjools | allenap: what's the context here | 14:34 |
| bigjools | ? | 14:34 |
| NCommander | bigjools: I just refactored findChangelog to call a new findFiles | 14:35 |
| NCommander | which is also called by findCopyright :-) | 14:35 |
| NCommander | as I didn't want to duplicate code logic | 14:35 |
| bigjools | where is findChangelog? | 14:36 |
| allenap | NCommander: Here's another approach: http://paste.ubuntu.com/393298/ | 14:36 |
| NCommander | bigjools: in code not yet merged ;-) | 14:36 |
| bigjools | ah :) | 14:36 |
| NCommander | allenap: I need to add another sanity check to findFile to prevent a possible DOS, so I like the former approach. Thanks for your help | 14:37 |
| allenap | NCommander: Okay, you're welcome :) | 14:38 |
| NCommander | bigjools: this is the code that implement raw_source_changelog in soyuz (I'm not sure I grok zope UI yet, but at least the mind numbling part is in) | 14:38 |
| bigjools | NCommander: ah interesting | 14:39 |
| * bigjools will need to review that ;) | 14:39 | |
| NCommander | bigjools: branch up on LP already | 14:39 |
| NCommander | lp:~mcasadevall/launchpad/raw_source_changelog | 14:39 |
| bigjools | NCommander: so are you fixing changesfile.py? | 14:39 |
| NCommander | bigjools: not yet. That requires a proper changelog parser unfortunately | 14:40 |
| bigjools | aye | 14:40 |
| bigjools | NCommander: so you're just storing the raw changelog? | 14:40 |
| NCommander | bigjools: ATM, yes. We ran it by stub this morning | 14:41 |
| * bigjools looks at the branch instead of postulating | 14:41 | |
| * NCommander hears bigjools screaming for some reason | 14:43 | |
| bigjools | NCommander: be careful with those yield error texts | 14:43 |
| bigjools | they are copied verbatim into emails | 14:43 |
| bigjools | so "Failed to copy changelog file" isn't that useful | 14:43 |
| NCommander | bigjools: that came from Failed to copy copyright file :-) | 14:43 |
| bigjools | that sucks too :) | 14:44 |
| bigjools | open(fullpath).read().strip() should probably be broken down into different stages and a separate error for each | 14:44 |
| NCommander | ugh | 14:46 |
| * NCommander is getting the feeling that since I'm now the most recent to touch this file, I get to fix and make it publish | 14:47 | |
| bigjools | NCommander: if we didn't do drive-by fixes they'd never get done :/ | 14:47 |
| bigjools | so we like to encourage it :) | 14:47 |
| NCommander | bigjools: this doesn't seem like the right way to maintain critical infrastructure ... | 14:48 |
| bigjools | why's that? | 14:48 |
| persia | Shhhh ! | 14:48 |
| * NCommander wonders who persia is shhhhing | 14:48 | |
| bigjools | it seems a great way to me, but perhaps we're thinking about different things | 14:49 |
| bigjools | NCommander: anyway your change looks great from what I can see so far | 14:51 |
| NCommander | bigjools: I'm probably going to run into issues when it gets to the point of bending the UI to my will | 14:52 |
| bigjools | NCommander: yeah probably, but we can help you! Get this one done first though. | 14:52 |
| NCommander | bigjools: I also have no clue how to write the migration tool when we get there | 14:54 |
| bigjools | NCommander: yeah that will be tough | 14:54 |
| NCommander | bigjools: there's code in dak that can be recycled :-) | 14:55 |
| bigjools | we need something to parse the changelogs and poke the database | 14:55 |
| bigjools | it will be an interesting script | 14:55 |
| * NCommander rewrote a good chunk of dak pre-Canonical days, including support to generate dists/* from the database | 14:55 | |
| bigjools | I don't think it's too hard though | 14:55 |
| bigjools | tough but not impossible :) | 14:56 |
| NCommander | bigjools: its more just going one by one through sourcereleasepackage, finding its files, downloading the package from librarian, sucking out a changelog, and updating the database | 14:56 |
| NCommander | Its going to be bloody time consuming | 14:56 |
| bigjools | well we only need to scan published sources | 14:56 |
| NCommander | bigjools: we don't want everything? | 14:57 |
| bigjools | NCommander: what's the point? | 14:57 |
| bigjools | if there's a good reason it's fine of course | 14:57 |
| NCommander | ^- persia - please provide a point if there is one | 14:58 |
| bigjools | :) | 14:58 |
| * persia reads backscroll | 14:59 | |
| * bigjools going otp | 14:59 | |
| persia | Hrm. I think I have to defer to mvo on that. | 15:00 |
| persia | The point would depend on where/how the comparisons are happening for the update-manager display. | 15:00 |
| persia | If it's happening between two pulls from the server, we need everything. If it's happening between the server and the client, we only need urrently published stuff. | 15:01 |
| persia | c | 15:01 |
| deryck | adeuring, , is bug 505999 really a dupe? It was marked fixed so I assume you passed the bug number to the commit message? | 15:01 |
| mup | Bug #505999: Unsubscribe OOPS <oops> <qa-needstesting> <Launchpad Bugs:Fix Committed by adeuring> <https://launchpad.net/bugs/505999> | 15:01 |
| adeuring | deryck: yes, this really looks like a dupe. | 15:02 |
| adeuring | the OOPS data is quite similar | 15:02 |
| deryck | adeuring, ok, thanks. | 15:02 |
| deryck | adeuring, did you QA the doNotSnapshot-related OOPS bugs? | 15:04 |
| adeuring | deryck: yes, I tried for example to (un)subscripbe from bug one | 15:04 |
| deryck | adeuring, can you update all the related bugs to change to the qa-ok tag then? | 15:05 |
| adeuring | deryck: sure | 15:05 |
| deryck | thanks! | 15:05 |
| deryck | adeuring, sorry, many questions about this. :-) Bug #518254 was fixed, too? | 15:06 |
| adeuring | deryck: probably.... but I need to check this | 15:08 |
| deryck | adeuring, ok, just claim it and mark it fixed if so. if not, ping me to follow up about it. | 15:08 |
| adeuring | ok | 15:08 |
| === matsubara is now known as matsubara-lunch | ||
| leonardr | flacoste, i'm having trouble iterating over a shell glob in the launchpad makefile. can you take a look? | 15:24 |
| leonardr | http://pastebin.ubuntu.com/393326/ | 15:24 |
| leonardr | that same code works in a shell script | 15:24 |
| mcasadevall | allenap: I have no luck with exceptions :-/ | 15:25 |
| allenap | mcasadevall: Hehe :) Can I help? | 15:25 |
| mcasadevall | errors = findFile(self.tmpdir, self.changelog_file, mock_logger_quiet) self.failUnlessRaises(UploadError, list, errors) | 15:26 |
| mcasadevall | allenap: I'm trying to trigger an upload error in findFiles that I added for files being too big | 15:26 |
| === mcasadevall is now known as NCommander | ||
| allenap | mcasadevall: Sorry, I have to go out for a minute; I'll be back in <10m. | 15:26 |
| NCommander | np | 15:26 |
| leonardr | flacoste: i changed $(WADL_FILE_GLOB) to $(wildcard WADL_FILE_GLOB), but that's expanding to the empty string for some reason | 15:38 |
| jelmer | leonardr: you'd want $(wildcard $(WADL_FILE_GLOB)) probably? | 15:39 |
| leonardr | jelmer: madness! | 15:39 |
| persia | No, just make | 15:39 |
| leonardr | jelmer, thanks, that works | 15:39 |
| allenap | NCommander: Do you have a diff of your latest changes? | 15:49 |
| NCommander | allenap: see PM | 15:53 |
| === matsubara-lunch is now known as matsubara | ||
| NCommander | bigjools: so, I think I'm at the point where I need to run the local test suite to make sure this all is working sanely | 16:12 |
| NCommander | bigjools: how do I do that? :-) | 16:12 |
| bigjools | NCommander: best thing is to type: | 16:12 |
| bigjools | bin/test -cvv -m soyuz -m archiveuploader -m archivepublisher | 16:12 |
| bigjools | and go get coffee for 30m | 16:12 |
| * NCommander lets it run | 16:13 | |
| bigjools | oh -m buildmaster too | 16:13 |
| NCommander | Test-module import failures: Module: lp.soyuz.browser.tests.test_archive_admin_view | 16:13 |
| NCommander | uh oh | 16:13 |
| NCommander | What did I break | 16:13 |
| bigjools | happens here too | 16:13 |
| bigjools | don't worry | 16:13 |
| bigjools | jelmer was going to look into that | 16:14 |
| jelmer | I'll be mailing the list about it before EOD | 16:14 |
| NCommander | bigjools: w.r.t. to findFile(), allenap is concerned thats not going to pass review. If thats the case, I rather rewrite it now. Care to weigh in? (or any other soyuz person) | 16:16 |
| bigjools | what is the concern, exactly? | 16:17 |
| NCommander | bigjools: it kinda handles errors funny | 16:17 |
| NCommander | bigjools: it uses raise to raise an error, then catches them one level up and yeilds them so I don't have a lot of code duplication across changelog and copyright file findings stuff | 16:17 |
| bigjools | NCommander: I can't think of a better way of doing it | 16:18 |
| allenap | NCommander: I don't see the exception catching code in the branch...? | 16:19 |
| allenap | NCommander: If you catch UploadError in findCopyright() and findChangelog() and yield it then it's fine. The test we just worked on would not work though, and would need to be changed; that's why I assumed you weren't doing that. | 16:22 |
| NCommander | allenap: | 16:23 |
| NCommander | try: copyright_file = findFile(source_dir, 'debian/copyright', logger); except UploadError, error: yield error | 16:23 |
| NCommander | hrm | 16:23 |
| NCommander | that came out a bit flatter than I expected | 16:23 |
| NCommander | unless I'm misunderstanding the code patch you wrote | 16:23 |
| allenap | NCommander: I only got "try:" then "hrm" there; maybe you hit some flood protection. | 16:24 |
| NCommander | oh | 16:25 |
| NCommander | http://paste.ubuntu.com/393377/ | 16:25 |
| === deryck is now known as deryck[lunch] | ||
| allenap | NCommander: Cool :) | 16:34 |
| leonardr | gary: i'm going to create a .pt file for the apidoc index file. should that go into lib/canonical/launchpad/templates? | 16:37 |
| gary_poster | leonardr: mm. I'd be tempted to put it closer to the machinery that you are building. It is a not a template that the application should use itself, except in this rare case, yes? | 16:39 |
| leonardr | gary: right | 16:39 |
| leonardr | should it go in utilities or utilities/templates? | 16:39 |
| gary_poster | leonardr: in favor of ./lib/canonical/launchpad/utilities | 16:40 |
| leonardr | ok, cool | 16:40 |
| leonardr | but, that's not really anywhere near create-lp-wadl.py, which is in /utilities | 16:41 |
| gary_poster | leonardr: oh | 16:41 |
| gary_poster | leonardr: I thought it would be over there. | 16:42 |
| leonardr | gary: i think it's in /utilities because it's only called by the makefile? | 16:42 |
| gary_poster | leonardr: right. since this template needs to run within lp, it should be in the lp tree. if there's not an obvious place for it, but it in the standard template location you mentioned first | 16:43 |
| gary_poster | s/but/put/ | 16:43 |
| leonardr | ok | 16:43 |
| NCommander | zeca failed to start in the test suite :-/ | 17:14 |
| bigjools | NCommander: yeah it's very problematic sometimes | 17:29 |
| NCommander | bigjools: so five tests failed, I'm looking over the failures now. Is the full log automatically saved somewhere? | 17:31 |
| bigjools | NCommander: no :/ | 17:32 |
| NCommander | ugh | 17:32 |
| * NCommander accidently cleared his screen | 17:32 | |
| bigjools | NCommander: it sounds spurious to me | 17:32 |
| NCommander | now I need to wait an hour for the other failures to repop up | 17:32 |
| bigjools | do you remember the test names?> | 17:32 |
| * bigjools keeps meaning to make bin/test and make check write a log | 17:32 | |
| === deryck[lunch] is now known as deryck | ||
| NCommander | bigjools: nops :-/ | 17:33 |
| NCommander | I have one as a doc test, although I'm unsure how to rerun it individually | 17:33 |
| NCommander | lib/lp/soyuz/tests/../doc/distroseriesqueue-translations.txt | 17:33 |
| === gary_poster is now known as gary-lunch | ||
| * kfogel is away: switching consoles for a bit, back soon | 18:19 | |
| === Ursinha is now known as Ursinha-lunch | ||
| === leonardr is now known as leonardr-lunch | ||
| === salgado-afk is now known as salgado | ||
| === leonardr-lunch is now known as leonardr | ||
| kfogel | wgrant: I was thinking, now that the community-contributions.py script is counting Canonical devs (who aren't on the launchpad team) too, maybe it no longer makes sense to have these hardcode start revs in the file? | 19:03 |
| NCommander | Stupid question but are there any know broken tests in soyuz, I have a test thats failing that doesn't seem be related to my changes, and it fails in devel and in my branch | 19:11 |
| === gary-lunch is now known as gary_poster | ||
| thumper | morning | 19:42 |
| thumper | NCommander: which tests are breaking for you? | 19:43 |
| NCommander | thumper: FTPconfig | 19:43 |
| NCommander | test_generateConfig (lp.archivepublisher.tests.test_ftparchive.TestFTPArchive) | 19:43 |
| thumper | NCommander: I'll check mine on devel | 19:44 |
| NCommander | thumper: it fails consistantly on my branch, and on stock devel | 19:44 |
| NCommander | thumper: I'd also like to start the review process for my changeset into db-devel | 19:44 |
| thumper | NCommander: propose your branch for merging | 19:48 |
| thumper | NCommander: that's all you have to do to start the process | 19:48 |
| thumper | TestFTPArchive tests pass for me locally with up to date devel | 19:48 |
| NCommander | thumper: are you onlucid? | 19:49 |
| thumper | NCommander: no, karmic still | 19:49 |
| * NCommander is suspecting he's having some unique failures because of it | 19:49 | |
| NCommander | thumper: thats probably why | 19:49 |
| NCommander | thumper: who should I put down for reviewer | 19:52 |
| thumper | NCommander: just leave it as launchpad | 19:52 |
| thumper | NCommander: it should have that already | 19:52 |
| thumper | NCommander: although are you wanting to land on devel or db-devel? | 19:53 |
| NCommander | thumper: I'm just reading on the wiki about who to set for reviewer and cover letter | 19:53 |
| NCommander | thumper: db-devel | 19:53 |
| thumper | NCommander: ok, lp:launchpad is the right branch then | 19:53 |
| NCommander | thumper: I'm running make lint as recommended by the cover page instructiosn, and I'm getting a bunch of can't import messages | 20:18 |
| NCommander | 29: [F0401] Unable to import 'zope.component' | 20:18 |
| thumper | NCommander: have you linked the external sourcecode in your branch? | 20:18 |
| NCommander | thumper: yes | 20:19 |
| thumper | hmm... | 20:19 |
| * thumper confesses to not running make lint in a while | 20:19 | |
| * NCommander has run make run and make schema without issues | 20:19 | |
| thumper | NCommander: I'd say ignore those errors/warnings | 20:19 |
| wgrant | NCommander: generateConfig is the only test broken on lucid. | 20:22 |
| wgrant | kfogel: Hm, possibly. | 20:23 |
| NCommander | wgrant: make lint seems broke too :-/ | 20:23 |
| wgrant | NCommander: What does it do? | 20:23 |
| NCommander | wgrant: runs pylint, the submission directions say your supposed to run it and attach the output to any merge cover letter | 20:24 |
| wgrant | NCommander: I mean, why is it broken? | 20:24 |
| wgrant | It works for me. | 20:24 |
| NCommander | wgrant: 17: [F0401] Unable to import 'zope.schema' | 20:25 |
| NCommander | wgrant: and other such messages | 20:25 |
| wgrant | That's normal. | 20:25 |
| wgrant | Ignore external missing imports like that; they're in eggs. | 20:25 |
| wgrant | Internal imports should work fine, though. | 20:25 |
| NCommander | merge proposed | 20:26 |
| wgrant | kfogel: I suspect we'll probably need to extend the lists, then, but let's just see what happens. | 20:26 |
| * wgrant runs. | 20:26 | |
| === fjlacoste is now known as flacoste | ||
| NCommander | thumper: so I take it now I just wait? | 20:30 |
| thumper | NCommander: yep or go into #lauchpad-reviews and bug the on call reviewer | 20:30 |
| NCommander | thumper: don't DB changes need some special reviewing as well? | 20:31 |
| wgrant | Request 'db' reviews from stub and BjornT. | 20:32 |
| NCommander | wgrant: before or after the technical review? | 20:34 |
| wgrant | NCommander: I don't believe it matters. | 20:34 |
| thumper | NCommander: same time | 20:36 |
| lifeless | jml: morning | 20:44 |
| jml | lifeless, hi | 20:46 |
| lifeless | I'd love it if I could understand the progress-to-hard issue. I feel like I just don't get the crux of it | 20:49 |
| lifeless | s/to/too/ | 20:49 |
| jml | I don't want to write a thing that displays a progress bar while dumping subunit output | 20:50 |
| kfogel | jml: for changes to the community-contributions script (by wgrant) it's okay if I just review and land them, right? | 20:50 |
| jml | kfogel, yes. | 20:50 |
| lifeless | jml: ok. So you're saying that it is possible, but you don't want to do it. I was saying that its pointless (you can get the bar from subunit in real time anyway). | 20:52 |
| jml | lifeless, it's also pointless | 20:52 |
| lifeless | jml: ok, so I think we're agreed at this level. The reason I suggested saying pointless in the docstring, was so that other people examining it won't think you're discarding an important feature. | 20:53 |
| jml | lifeless, ok. | 20:53 |
| jml | # subunit output is designed for computers, so displaying a progress bar | 20:54 |
| jml | # isn't helpful. | 20:54 |
| jml | also, we're on the wrong channel :) | 20:54 |
| lifeless | jml: well, its a launchpad patch. | 20:55 |
| lifeless | jml: so I think this is the right channel :) | 20:55 |
| jelmer | You should crosspost. | 20:55 |
| lifeless | hah. Now perhaps finally thats a reason to install bip | 20:56 |
| jml | lifeless, uhh, no, it's a patch to zope.testing. | 20:57 |
| lifeless | oh, my bad | 20:57 |
| lifeless | I thought it was going to go into the lp tree for some reason. | 20:57 |
| lifeless | jml: should I join #zope? I think we're essentially done on the review, right? | 20:59 |
| kfogel | wgrant: one teeny little thing left for the community-contributions-fixes branch: | 20:59 |
| wgrant | kfogel: Sure. | 21:00 |
| kfogel | wgrant: the line "lr.merge_depth < ec.seen_revs[lr.rev.revision_id][0].merge_depth):" and the one below it go longer than 78 columns. https://dev.launchpad.net/PythonStyleGuide#Whitespace%20and%20Wrapping | 21:00 |
| jml | lifeless, I think we're done, yeah | 21:00 |
| jml | lifeless, #zope3-dev is the appropriate channel AIUI. Also, you're CCd on the email to the zope mailing list. | 21:00 |
| wgrant | kfogel: Really? Argh. | 21:00 |
| * wgrant fixes. | 21:00 | |
| kfogel | wgrant: if you fix up, then we have a clean set of commits by you. | 21:00 |
| kfogel | wgrant: (I could fix it, but I hate to taint the history with my shameful name...) | 21:01 |
| lifeless | jml: sweet. | 21:01 |
| wgrant | Heh. | 21:01 |
| wgrant | kfogel: Pushing. | 21:02 |
| kfogel | wgrant: thanks. I will land. | 21:02 |
| wgrant | kfogel: Thanks. | 21:02 |
| jml | now all I need to do is trick gary_poster or barry or another person w/ commit privs to land it for me :) | 21:03 |
| lifeless | jml: I'm a little nervous about the embedded protocol, because I kindof expect the chunked stuff to change - martin is working on a patch to use a ascii coding rather than 8bit | 21:03 |
| lifeless | when I say working on, I mean he wants it and I keep saying patches accepted. | 21:03 |
| lifeless | I think barry makes a good victim^Wassistance | 21:05 |
| === matsubara is now known as matsubara-afk | ||
| wgrant | kfogel: The current version of /Draft was generated from r1 of both branches, with an extended name map. | 21:23 |
| kfogel | wgrant: oh, you filled in the name map with those earlier devs? you rock again | 21:24 |
| * kfogel visits | 21:24 | |
| kfogel | wgrant: looks good to me | 21:25 |
| kfogel | wgrant: are all your changes pushed to the lp branch now? | 21:25 |
| wgrant | kfogel: No, I haven't committed these yet. | 21:25 |
| wgrant | Should I remove the start_revno support? | 21:25 |
| kfogel | wgrant: I think it's kind of pointless now. Do you concur? | 21:26 |
| wgrant | Indeed. If we end up needing it, we have a VCS... | 21:26 |
| * wgrant removes. | 21:26 | |
| wgrant | kfogel: r10469 pushing. | 21:32 |
| kfogel | wgrant: thank you | 21:32 |
| wgrant | np | 21:32 |
| lifeless | sidnei: you are da man | 21:33 |
| lifeless | bah echannel | 21:33 |
| kfogel | wgrant: got your changes, looking now; expect to land today. | 22:27 |
| wgrant | kfogel: Great. | 22:28 |
| lifeless | oh jml - https://code.edge.launchpad.net/~lifeless/lptools/lp-project/+merge/21124 - may interest you; I'm going to do a further variation for bzr plugins. | 22:29 |
| * kfogel is away: machine fan cleanup; back later | 22:29 | |
| === salgado is now known as salgado-afk | ||
| === jamalta is now known as jamalta-afk | ||
| wgrant | Hum. | 23:19 |
| wgrant | I have twisted.web.xmlrpc.Proxy.callRemote hanging when one of its arguments is a dict containing a None value. | 23:20 |
| shen-long | ok ... wow ... | 23:50 |
| shen-long | trying to https://dev.launchpad.net/Running/RemoteAccess | 23:50 |
| shen-long | getting a 503 error | 23:50 |
| shen-long | followed directions to a T, not using two ip's though, just one public | 23:51 |
| shen-long | this is on a fresh ubuntu 9.10 | 23:51 |
| shen-long | ImportError: No module named _pythonpath in apache error log is the only thing I can see | 23:56 |
| shen-long | from scripts/branch-rewrite.py | 23:57 |
| shen-long | everything else loops fine | 23:57 |
| shen-long | wrong version of python | 23:58 |
| shen-long | thanks for talking me through it #launchpad-dev ;p | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
