| Chex | sinzui: I have a output log for your script run on staging, not sure if it completed properly or not. Do you want to see the log? | 01:14 |
|---|---|---|
| wgrant | spm: Has gina been crashing for ~ a week, or is it robust enough to withstand the un-understandable packages which have turned up in the Debian archive? | 01:45 |
| mwhudson | that was a weird oopsy crashy thing | 02:18 |
| wgrant | Hm? | 02:19 |
| mwhudson | my machine more or less hung | 02:19 |
| mwhudson | only more or less though | 02:19 |
| mwhudson | i could type into bash | 02:19 |
| mwhudson | but the processes i started didn't get anywhere | 02:19 |
| wgrant | Hmm. Disk access was hanging? | 02:20 |
| lifeless | mwhudson: 'dmesg' next time | 02:20 |
| mwhudson | lifeless: that was one of the things that didn't do anythign | 02:25 |
| mwhudson | and i think it recovered actually, but i was into the reboot by then | 02:25 |
| spm | wgrant: I'm not personally aware of any failures - but have been away for a few days... | 02:40 |
| noodles775 | EdwinGrubbs: thanks for getting that QA done on staging! Just to confirm, I'm guessing you also qa'd the 'distroseries milestone timeout' there (the CRB page only has the +index page entry as qa'd). Is that right? | 02:49 |
| noodles775 | Welcome back spm :) | 02:50 |
| EdwinGrubbs | noodles775: The previous fix applied to both bugs, and I erroneously thought that new fix did also. it is not timing out on staging, but I don't know why not. | 02:50 |
| spm | noodles775: :-) | 02:53 |
| mwhudson | noodles775: _surely_ you should be asleep | 03:01 |
| wgrant | It's only 4am! | 03:02 |
| noodles775 | mwhudson: normally yes, but I'm just a little keen to see that things go smoothly ;) | 03:02 |
| mwhudson | i see | 03:02 |
| * mwhudson reminds himself to never volunteer to be RM | 03:03 | |
| spm | mwhudson: but you had all that experience with BB. You should be poifect for the role! | 03:04 |
| mwhudson | spm: itym "have enough mental scar tissue" | 03:04 |
| * spm notes that trolling when the other person can't do Punch-In-The-Nose over TCP/IP is perferable | 03:05 | |
| spm | mwhudson: same same | 03:05 |
| wgrant | Isn't the release ~6 hours away? | 03:06 |
| noodles775 | mwhudson: speaking of which, do you know where the two NEEDSTESTING remaining items on the code team testplan. | 03:06 |
| wgrant | I don't see any announcements of it anywhere. | 03:06 |
| thumper | noodles775: it seems that my fix didn't | 03:07 |
| thumper | noodles775: I need to try again to work out what the problem is | 03:08 |
| noodles775 | wgrant: yes it is, I sent the schedule to lp-dev, I'm not sure whether mrevell has an email prepared... | 03:08 |
| wgrant | mrevell won't be up before the release. | 03:09 |
| thumper | mwhudson: up for the call? | 03:09 |
| noodles775 | thumper: ok, if your certain, move it to BAD (?), and let me know if you plan to get it in a re-roll. | 03:10 |
| thumper | noodles775: not entirely certain | 03:10 |
| thumper | noodles775: I'm going to try to reproduce locally | 03:10 |
| thumper | noodles775: but apparently the revision has been rolled out and the page still oopses | 03:10 |
| thumper | noodles775: so in that sense it is bad | 03:10 |
| noodles775 | thumper: ok | 03:11 |
| thumper | noodles775: wait though | 03:12 |
| thumper | noodles775: I think it could be the staging librarian masking it | 03:12 |
| noodles775 | :) yay, ok. | 03:12 |
| thumper | spm: how do we get stuff from the production librarian to the staging librarian? | 03:12 |
| thumper | spm: what is copied across? | 03:12 |
| spm | thumper: istr it's proxied - kinda sorta handwavy. | 03:13 |
| thumper | hmm... | 03:13 |
| thumper | http://staging.launchpadlibrarian.net/30419774/mp-unicode.msg | 03:13 |
| thumper | spm: gets processing failed | 03:13 |
| thumper | spm: any ideas how or why? | 03:13 |
| spm | huh. and the real one works. looking... | 03:14 |
| mwhudson | thumper: one sec | 03:16 |
| noodles775 | Do you guys know about abentley's entry? bug 436325? | 03:16 |
| mup | Bug #436325: Diffstat generation chokes on binaries (and others) <oops> <Bazaar:Fix Released by abentley> <Bazaar 2.0:Fix Released by abentley> <Launchpad Bazaar Integration:Triaged by abentley> <https://launchpad.net/bugs/436325> | 03:16 |
| noodles775 | wgrant: mrevell will be around *for* the release, but I take from what you're saying that there's usually an announcement email sent to LP-users before the release? | 03:18 |
| * noodles775 looks through the archive | 03:19 | |
| mwhudson | thumper: ok call? | 03:19 |
| wgrant | noodles775: Normally sent to launchpad-announce, I think, so that people know that LP will be unavailable. | 03:19 |
| noodles775 | gr... I don't even know if I'll have access to send there. Thanks wgrant... checking now. | 03:19 |
| thumper | mwhudson: yep | 03:20 |
| wgrant | noodles775: They've classically been sent 24-36 hours before. | 03:22 |
| wgrant | However, I hope that lists.c.c announcement lists have a not-after-1am guard enabled. | 03:23 |
| noodles775 | wgrant: yeah - I'm not sure why it's not been sent this time, but I'll update the rm-wiki notes to put a check in there. Organising now. | 03:23 |
| wgrant | noodles775: Thanks. | 03:24 |
| wgrant | People get unhappy enough even when it is well announced. | 03:24 |
| noodles775 | :/ | 03:24 |
| spm | thumper: haha. the staging librarian is down atm; staging rollout in progress. give it another 10-20 and try try again. | 03:25 |
| thumper | mwhudson: OOPS-1404EB48 | 03:30 |
| thumper | https://lp-oops.canonical.com/oops.py/?oopsid=1325EA163 | 03:31 |
| thumper | spm: is the staging librarian up? | 03:45 |
| spm | nope. something looks nicely borked... | 03:45 |
| thumper | mwhudson: http://pastebin.ubuntu.com/309108/ | 03:46 |
| spm | thumper: alas. it is still working - the restore is gradually building eggs. perhaps abnother 45 mins wait may be appropriate :-/ | 03:48 |
| thumper | noodles775: it may be fixed | 03:49 |
| thumper | noodles775: it certainly works locally | 03:49 |
| noodles775 | great! | 03:50 |
| thumper | noodles775: I clicked on the link in staging which took me to edge, not staging | 03:50 |
| thumper | and I didn't notice | 03:50 |
| thumper | :-| | 03:50 |
| noodles775 | thumper: do you know about abentley's bug listed there too? | 03:50 |
| thumper | noodles775: yes, it is bad but not a blocker | 03:51 |
| spm | wgrant: ahh. in answer to your Q earlier about gina. I (you probably already know...) present bug 449408 | 03:55 |
| mup | Bug #449408: Need scriptactivity monitoring of "gina" <Soyuz:Triaged> <https://launchpad.net/bugs/449408> | 03:55 |
| wgrant | spm: I've seen that, yes. | 03:56 |
| wgrant | gina is a very special breed of evil. | 03:56 |
| spm | wgrant: that means a lot; hearing you say that as in. ;-) | 03:56 |
| * spm has visions of gina owning it's own plane of the netherhells | 03:57 | |
| wgrant | Heh. | 03:57 |
| wgrant | It'll need a bit of hacking soon :( | 03:58 |
| spm | by the sound of; hacking with an axe | 03:58 |
| spm | anywas. bbs. school run time. | 03:58 |
| wgrant | Just with some v3 support. | 03:58 |
| MTecknology | Is postgresql any faster than mysql? | 04:08 |
| MTecknology | random question for the channel :P | 04:08 |
| wgrant | Is that a valid question? | 04:08 |
| MTecknology | I don't have any basis for knowing | 04:08 |
| thumper | https://dev.launchpad.net/Soyuz/Specs/BuilddManagerUploadDecoupling | 04:17 |
| thumper | https://dev.launchpad.net/Soyuz/Specs/BuilddGeneralisation | 04:17 |
| noodles775 | wgrant and others: I've been chatting with flacoste and we've decided to reschedule for Thursday 5th 09.00 UTC due to the lack of announcement. | 04:27 |
| wgrant | noodles775: Probably a good idea. | 04:27 |
| noodles775 | potentially 90mins of complete offline (no read access) is too scary - and we still don't have anyone who can send to lp-announce atm. | 04:27 |
| wgrant | But... 5:30am. Ouch. | 04:27 |
| wgrant | Ooh. | 04:28 |
| wgrant | That's bad. | 04:28 |
| wgrant | No read only? | 04:28 |
| noodles775 | wgrant: nope - librarian machines are being updated. | 04:28 |
| wgrant | Ah. | 04:28 |
| wgrant | That really does need an announcement. | 04:28 |
| noodles775 | yup. | 04:28 |
| noodles775 | updating identica now... | 04:29 |
| wgrant | Thanks for working that out. | 04:29 |
| noodles775 | ... and thanks for pointing that out :) | 04:29 |
| jtv | jamesh, got time to help with a nagging problem I've been having that probably involves storm? | 04:49 |
| jamesh | jtv: sure | 04:49 |
| jtv | great, thanks. | 04:49 |
| jtv | The problem is this: we have a script that's using up too much memory. | 04:49 |
| jamesh | have you thought of buying more memory? | 04:50 |
| jtv | It shouldn't be pinning anything in memory across iterations of a particular loop. | 04:50 |
| jtv | yes, we considered that but I'm Dutch. | 04:50 |
| jtv | The only class from the Launchpad source tree that it seems to be allocating in great numbers is DBEnumVariable. | 04:50 |
| MTecknology | How hard is it to backup a launchpad server if you run everything on a single system? | 04:51 |
| jtv | jamesh: There are no other LP objects in memory that could explain having so many of those around. | 04:51 |
| jtv | MTecknology: not very, just back up the database. | 04:52 |
| MTecknology | jtv: and file system? | 04:52 |
| jtv | MTecknology: and... sleepwalking again? :) | 04:52 |
| jamesh | well, you generally get one Variable for each field of each live instance Storm object instance | 04:52 |
| wgrant | And the bzr branches, and the librarian. | 04:52 |
| MTecknology | jtv: hm? | 04:52 |
| jamesh | and a few get created during expression compilation, but they shouldn't last long | 04:52 |
| jtv | MTecknology: oh, that'd be codehosting. I wouldn't know about that part. :/ | 04:53 |
| jtv | jamesh: this is after transaction.commit() & gc.collect() | 04:53 |
| jamesh | jtv: what code in particular are we talking about? | 04:53 |
| jamesh | just so I've got some idea of what's happening | 04:54 |
| jtv | jamesh: in the LP tree, lib/lp/translations/scripts/message_sharing_migration.py | 04:54 |
| jtv | jamesh: in there, look for _mergeTranslationMessages | 04:54 |
| * jtv sneezes | 04:55 | |
| jtv | damn this cold weather | 04:55 |
| jtv | jamesh: that loop looks a lot more complex than it is | 04:56 |
| jtv | most of it is just ways to avoid pinning ORM-backed objects in memory across iterations | 04:56 |
| jtv | in essence it's "for potmsgset in potmsgsets: for tm in potmsgset.getAllTranslationMessages(False, prefetch=False): message.shareIfPossible()" | 04:57 |
| jtv | The rest is just a dance to make it store only objects' ids across iterations. | 04:58 |
| jamesh | jtv: http://paste.ubuntu.com/309149/ <- I haven't tested this code, but it should give you some idea of what objects Storm knows about | 05:01 |
| jtv | jamesh: that may not tell us much... there's >100× more of these DBEnumVariable objects floating around than there are objects in Store._alive | 05:03 |
| jtv | (In the dump I have) | 05:03 |
| jamesh | jtv: do you know what's referencing those objects? | 05:04 |
| jtv | If only I did... | 05:04 |
| jtv | This is where the storm internals start to matter, I suspect. | 05:04 |
| jamesh | gc.get_referrers() can help | 05:04 |
| jtv | Oh, I knew about get_referents but not this one | 05:04 |
| jamesh | I don't have any good sample code to play with for it | 05:05 |
| jtv | no worries, I can slot this right into our debug dumps. | 05:05 |
| jamesh | you sometimes need to use it recursively though | 05:06 |
| jamesh | the reference chain for most instance attributes is instance -> dict -> attr | 05:06 |
| jtv | The current dumping code is ready to go through 2 levels | 05:06 |
| jtv | so again no worries there | 05:06 |
| jtv | I just thought there was only get_referents and not get_referrers | 05:06 |
| jamesh | get_referrers is a fair bit more expensive | 05:07 |
| jamesh | since you essentially need to ask all the container objects whether they reference the one in question | 05:07 |
| jtv | Anyway, I have in memory: 92 POTMsgSets, 65 Languages. That's about it for the real Launchpad objects. Then, 19K DBEnumVariables, 334 CachedPropertys, 123 DBSchemaEnumCols, 99 PublicPersonChoices, 71 ContextTitles, and change. | 05:08 |
| jtv | The Language objects may get cached somewhere; I haven't bothered to look. I have no idea why the POTMsgSets would stick in memory unless Storm just likes to keep them in cache across transactions. The rest is a complete mystery. | 05:09 |
| jamesh | how many enum columns are on each of those classes? | 05:09 |
| jamesh | e.g. if POTMsgSet has 5 enum cols, then it would account for 460 DBEnumVariables | 05:10 |
| jtv | jamesh: might bools be implemented in this way? | 05:11 |
| jamesh | no | 05:11 |
| jamesh | jtv: DBEnumVariable has an _enum attribute pointing at the associated lazr enum | 05:12 |
| jtv | then judging by the interfaces, there's one enum in Language and one in POTMsgSet. | 05:12 |
| jamesh | might help to see what those variables are for | 05:12 |
| stub | https://pastebin.canonical.com/24271/ has counts for non-lp objects too. | 05:15 |
| jamesh | might be an easier way to lay the blame than get_referrers | 05:15 |
| stub | (scroll down to the last section for the meaningful results - should have trimmed the earlier sections) | 05:16 |
| jtv | jamesh: as per stub's clever suggestion we're dumping referrer info for some random samples | 05:16 |
| stub | So 108423 storm.variable.IntVariables lying around, most likely buried in tuples or dictionaries along with functions (I suspect validators) | 05:18 |
| jamesh | so, for a storm object you have a dual ObjectInfo that Storm manages behind the scenes | 05:19 |
| jamesh | inside that object there is a tuple of Variable objects representing the primary key | 05:19 |
| stub | (We are actually making a list of integer ids rather than some object that can be cast to an integer, aren't we?) | 05:19 |
| jamesh | and a mapping from from columns to variables for the other fields | 05:20 |
| jtv | stub: good question... I'm just getting [obj.id for obj in result] | 05:20 |
| jamesh | so IntVariable in a 1-tuple would be primary_vars | 05:20 |
| jamesh | Variables as values in a dict are probably other columns | 05:21 |
| jtv | stub: I pushed a new version of the branch that, for the random samples, dumps referrers instead of referents. | 05:23 |
| jtv | maybe run again with that? | 05:23 |
| stub | k | 05:24 |
| stub | Gimme a package ;) | 05:24 |
| stub | jtv: Did you tweak the filter? We don't seem to have enough launchpad database objects to account for everything so I suspect we need to turn the object filter off like I did last run | 05:26 |
| jtv | stub: package: eog | 05:26 |
| stub | Gah. What is the branch again btw? Lost my shell history. | 05:27 |
| jtv | stub: can do... it's a matter of removing the "filter" argument from the dump_mem call | 05:27 |
| jtv | lp:~jtv/launchpad/debug-mem-2 | 05:27 |
| stub | stage 1 underway (using my existing local hacks for no filter and more readable sample, not that the sample turned out to be useful) | 05:29 |
| jtv | I commented out the filter on my end as wel | 05:29 |
| jtv | l | 05:29 |
| jtv | what's the local hack for a more readable sample? | 05:30 |
| stub | jtv: https://pastebin.canonical.com/24309/ | 05:31 |
| jtv | I don't think the exception handling on get_class is needed... hasn't barfed on me yet | 05:32 |
| jtv | has it barfed on you? | 05:32 |
| stub | jtv: It did when I was trying to inspect contents of tuples - some bzrlib late loading stuff. Not needed now I suspect. | 05:34 |
| stub | I was trying to categorize the tuples but it was too noisy. | 05:35 |
| * stub goes to the fly lice sho | 05:36 | |
| jtv | stub: bong appetit | 05:36 |
| mrevell | Morning :) | 07:07 |
| wgrant | Morning mrevell -- want to announce the downtime? | 07:08 |
| mrevell | wgrant, This is me back after a couple of days holiday. Roll-out downtime looks as though it's on the status page to me. | 07:10 |
| wgrant | mrevell: So that has completely replaced launchpad-announce as the announcement mechanism? There has always been an email to launchpad-announce 24-36 hours before. | 07:13 |
| mrevell | wgrant, I'm just checking to see what's been done and what hasn't... | 07:13 |
| mrevell | wgrant, We're still waiting on definite confirmation of the roll-out time. I'll announce as soon as I have it. | 07:15 |
| wgrant | mrevell: OK, great. This one is particularly important to announce well ahead of time... | 07:16 |
| al-maisan | wgrant: http://identi.ca/launchpadstatus | 07:20 |
| wgrant | al-maisan: I know that, but most people don't. | 07:21 |
| al-maisan | wgrant: great. | 07:21 |
| wgrant | And people rightly get unhappy when LP goes down for 90 minutes without an announcement. | 07:22 |
| al-maisan | wgrant: agreed. | 07:22 |
| jtv | jamesh: one thing we keep seeing in the random samples of live objects is _break_on_local_diverged, so presumably we've got a lot of those | 07:26 |
| jamesh | that'd be the Reference() caches | 07:26 |
| jamesh | If you have a reference Foo.bar using Foo.bar_id => Bar.id, Storm caches the value of Foo.bar and sets up an event handler to break that connection when Foo.bar_id changes | 07:27 |
| jamesh | (such as happens when you commit the transaction | 07:27 |
| jtv | So what happens to those event handles when we commit? | 07:29 |
| jamesh | on commit, all alive objects are invalidated | 07:30 |
| jamesh | so non-primary vars are cleared | 07:30 |
| jtv | You've mentioned primary vars before.. what are they? | 07:30 |
| jamesh | the columns that make up the primary key | 07:30 |
| jamesh | just "id" for pretty much everything in Launchpad, IIRC | 07:31 |
| jtv | Yes | 07:31 |
| jamesh | the primary vars aren't cleared because that's what is used to tie the Python object to the database row | 07:31 |
| jtv | jamesh: that begs two questions: why is the Python object still alive? And why so many more of these than live ORM-backed objects? | 07:37 |
| wgrant | With the delay, is 3.1.10 absolutely frozen, or is there a possibility of getting in a trivial fix (in code only used by sync-source.py) to prevent crashes caused by v3 source packages breaking the autosyncer? | 07:38 |
| jamesh | jtv: well, one possibility is that you've hit a bug. | 07:39 |
| jamesh | but I don't really have enough info to say one way or the other | 07:39 |
| jtv | I also saw one dict that just mapped the string "remote" to a POTMsgSet. Would that be a Storm thing as well? | 07:41 |
| jamesh | https://bugs.edge.launchpad.net/storm/+bug/435962 was reported recently about References from primary keys. I don't suppose that would apply to your situation? | 07:41 |
| mup | Bug #435962: Reference can return a cached invalidated object if the local key is the primary key <Storm:Confirmed> <https://launchpad.net/bugs/435962> | 07:41 |
| jamesh | that'd be the cache inside the Reference, yes. | 07:41 |
| stub | jamesh, jtv: Here is the final log from the eog export: https://pastebin.canonical.com/24314/ | 07:41 |
| stub | c/export/merge-job-thingy | 07:41 |
| jtv | stub: thanks | 07:42 |
| jamesh | we really need better __repr__() on the various Storm classes | 07:42 |
| jtv | stub, jamesh: note that this dump shows referrers for the random sample, not referents | 07:43 |
| stub | Thats a lot of EventSystem instances | 07:46 |
| jtv | about one per objectinfo, so I'd guess those are the callback hooks for key changes | 07:48 |
| jtv | about as many "function" objects... are those generated on the fly for each object? | 07:48 |
| jtv | "frame" is a stack frame, meaning a local variable? | 07:50 |
| stub | I think so. If they were frames stored in tracebacks we would see object count for that. | 07:51 |
| * stub toys with the idea of disabling the cextensions implementation of EventSystem as a shot in the dark | 07:52 | |
| stub | jtv: Got another package for me to prepare, running the first two stages? | 07:53 |
| jamesh | I'd be a bit surprised if the EventSystem impl was introducing bugs | 07:54 |
| jtv | stub: file-roller | 07:54 |
| jamesh | maybe users of the API, but not the actual implementation | 07:54 |
| stub | So would I actually (everything else would be exploding too, although this is our most extreme job in the current code base as far as object loading is concerned) | 07:55 |
| jtv | do we have an easy way to find out how many objects were loaded overall? | 07:59 |
| jtv | stub: so... are you trying that idea of disabling cextensions? Shot in the dark it may be, but it hits a lot of stuff we can't see. | 08:04 |
| stub | I'm running stage 1&2 of fileroller in preparation for whatever we do next. That might be disabling EventSystem from cextensions, better logging of the events so we can see what is holding onto them, or whatever you come up with ;) | 08:06 |
| stub | At the moment, I'm reading email. | 08:06 |
| jtv | stub: I for one am way out of my depth by now | 08:07 |
| jtv | And wtf would a stack frame be referencing all this stuff? | 08:08 |
| jtv | you mentioned other ways of referencing frames... could something be holding a whole stack incarnation in memory? | 08:10 |
| jtv | like maybe a cextension forgetting to unregister something even? | 08:10 |
| jtv | jamesh: is it possible for a C extension to pin a stack frame in memory, if it forgot to drop a reference or something? | 08:21 |
| jamesh | jtv: I wouldn't think so. Not any more than a Python stack frame | 08:22 |
| jtv | I mean, could it pin a Python stack frame in memory? | 08:22 |
| jtv | So many of these objects that should live inside Storm-backed objects seem to be referenced from the stack. | 08:23 |
| jtv | stub said something interesting earlier: when I do [obj.id for obj in query_result], do I really get ints? Or is there any chance that I might be getting IntVariables or something? | 08:24 |
| stub | IIRC tracebacks and exceptions can leak stack frames if not handled correctly, but I don't think we are seeing that. | 08:25 |
| stub | obj.id should be returning an integer - it always has in the past | 08:25 |
| jamesh | jtv: well, the only Python stack frames that stick around outside of the C call stack are generators | 08:27 |
| jamesh | all the others are essentially tied to C function calls | 08:27 |
| * jtv is grepping for 'yield' | 08:33 | |
| stub | comprehensions are generators too I think | 08:34 |
| jamesh | you can have references to local variables held in cell objects too when you work with closures | 08:36 |
| jamesh | (i.e. a nested function that uses variables from its parent scope) | 08:36 |
| jtv | stub: less likely that we're keeping references to those around though | 08:37 |
| jtv | so that's what those cell objects are... not getting many of those though | 08:38 |
| stub | I saw those cell instances but have no idea what they are. | 08:38 |
| jtv | jamesh: oh, you're saying a cell can hold actual stack frames in memory, as I was suspecting the cextensions of doing? | 08:39 |
| jamesh | no | 08:40 |
| jamesh | a stack frame can hold cells that can hold locals | 08:40 |
| jamesh | (assuming you haven't been storing tracebacks and the like in local variables ...) | 08:40 |
| jtv | (we haven't) | 08:40 |
| jtv | the cells don't seem to be doing much in the scheme of things | 08:42 |
| stub | So am I correct and the current thinking is we are somehow leaking ObjectInfo instances (ObjectInfo's have a self._event==EventSystem)? | 08:42 |
| adeuring | good morning | 08:43 |
| jtv | hi adeuring | 08:43 |
| adeuring | hi jtv! | 08:43 |
| jtv | stub: that's my impression, but the frames seem to be doing it. | 08:44 |
| jtv | looking at https://pastebin.canonical.com/24314/ random sample 3, there also seems to be an EventSystem referencing an ObjectInfo. | 08:46 |
| jtv | Through a frame, so the EventSystem seems to be holding a frame in memory. | 08:46 |
| stub | None of our code will deal with ObjectInfo directly. | 08:46 |
| stub | A Store has an EventSystem, as does each ObjectInfo | 08:47 |
| jtv | oh, wait, it's a list containing a frame and an EventSystem. | 08:47 |
| jtv | So we have [frame, EventSystem], where frame holds a weak reference to an ObjectInfo. | 08:48 |
| jtv | hmm... weak ref shouldn't be the problem though | 08:48 |
| jtv | but we are seeing lots of that pattern: a list containing a frame and one other reference. | 08:49 |
| jtv | Is that something that happens in the ObjectInfo? | 08:50 |
| jtv | Or is it something that python does for generators or closures? | 08:53 |
| stub | prelim done | 09:04 |
| jtv | cool... now to figure out what to do with it | 09:04 |
| jtv | I notice that there are 5 twisted.Failure objects | 09:04 |
| jtv | wonder if those might be holding stack frames? It'd be odd for them to hold frames with Storm stuff, I guess | 09:05 |
| jtv | I have no idea how Twisted would be involved in a script like this... does storm talk to it? | 09:09 |
| thumper | bigjools: hi | 09:10 |
| bigjools | hey thumper | 09:11 |
| thumper | bigjools: is it worth us having a call? | 09:11 |
| bigjools | thumper: what do you want to talk about? | 09:11 |
| thumper | bigjools: have you looked at your email? | 09:11 |
| thumper | bigjools: I sent something about 4.5 hours ago | 09:11 |
| bigjools | I have a shitload of email! | 09:11 |
| bigjools | and kmail is a PITA, it hangs folder views when resuming >:( | 09:12 |
| bigjools | one sec | 09:12 |
| bigjools | thumper: there's no chance of this working at the end of 3.1.11 | 09:13 |
| bigjools | nor 3.1.12 | 09:13 |
| thumper | why? | 09:14 |
| bigjools | there's too much work to do, and many of the key people are sprinting in November | 09:14 |
| jtv | jamesh: we've got 5 Failure objects hanging around Twisted... any idea where those might come from and how we get rid of them? | 09:14 |
| thumper | I'm not saying we migrate soyus code away | 09:14 |
| thumper | just make it possible to run jobs in a protected environment | 09:15 |
| stub | jtv: I imagine that is just noise from all the component architecture gumph that loads up | 09:15 |
| bigjools | you need a VM for that | 09:15 |
| jtv | jamesh: or are they just unrelated failures to connect to services that this script isn't using? | 09:15 |
| thumper | bigjools: and that is how the soyuz code does it? | 09:15 |
| stub | jtv: I'm going to drop to a debugger once the object count goes about 1.5 million | 09:15 |
| bigjools | like the PPA VMs - they get totally reset after each PPA build | 09:15 |
| bigjools | yep | 09:15 |
| thumper | bigjools: what is the setup and teardown time of the vms? | 09:16 |
| jtv | stub: cool | 09:16 |
| bigjools | thumper: thankfully *very* quick, the IS guys did some great optimisation and it takes about 5 seconds IIRC | 09:16 |
| thumper | bigjools: do we have some to test with in staging? | 09:17 |
| bigjools | no, just dogfood | 09:17 |
| bigjools | we have one only | 09:17 |
| thumper | well that's going to be a problem | 09:17 |
| bigjools | yeah | 09:17 |
| thumper | we have only one vm? | 09:17 |
| bigjools | one builder | 09:18 |
| bigjools | whether it's a VM or not is irrelevant to how we talk to it | 09:18 |
| thumper | a builder can run multiple vms? | 09:18 |
| bigjools | other than resetting the machine | 09:18 |
| bigjools | the one we have is virtual I think, but yeah we can run many builder VMs on a single box IIRC | 09:19 |
| bigjools | thumper: do you want to jump on a call with me and danilos? | 09:19 |
| thumper | bigjools: both translations and code will need arbitrary jobs to run in protected environments | 09:19 |
| bigjools | I know :) | 09:20 |
| thumper | I want to work out how we are going to make this happen | 09:20 |
| thumper | my problem is it is 22:20 and my brain is fuzzy | 09:20 |
| bigjools | yeah | 09:20 |
| bigjools | I have the same problem and it's only 0920 | 09:20 |
| bigjools | so basically we already have an environment to do this - the problem is that it's built around soyuz | 09:21 |
| thumper | bigjools: what I want is a flag on the job class that says "run me in a protected env" and have the job runner just do it | 09:21 |
| bigjools | yes | 09:21 |
| bigjools | https://dev.launchpad.net/Soyuz/Specs/BuilddGeneralisation | 09:21 |
| * thumper ndos | 09:21 | |
| bigjools | and I have a plan --^ | 09:21 |
| bigjools | but there are a number of stumbling blocks - but by the end of this week I will have a big list of smaller issues to tackle to get us to the point where we can get this working for non-soyuz jobs | 09:22 |
| thumper | bigjools: mwhudson will be looking at this over 3.1.11 | 09:22 |
| bigjools | fabulous | 09:23 |
| thumper | bigjools: danilo has also offered some resources I think | 09:23 |
| bigjools | so I think the best thing he can work on is to refactor IBuilder | 09:23 |
| thumper | bigjools: and I gather that foundations may also be able to provide someone | 09:23 |
| thumper | bigjools: if you can provide some break down of the work | 09:23 |
| thumper | bigjools: we'll take a look at it | 09:23 |
| bigjools | I will | 09:23 |
| thumper | ta | 09:23 |
| bigjools | in fact I am | 09:23 |
| thumper | fantastic even | 09:24 |
| BjornT | thumper: could we have a call about this some time? i'd like to learn more about the current job system, and how you want to extend it. | 09:27 |
| thumper | BjornT: sure, but not right now :) | 09:27 |
| thumper | BjornT: abentley is going to be doing some work on it next cycle | 09:28 |
| * thumper signs off | 09:28 | |
| BjornT | thumper: yeah, i wasn't suggesting to do it now :) | 09:28 |
| * thumper smiles | 09:28 | |
| bigjools | BjornT: I suggested 2-3h after the TL call | 09:28 |
| BjornT | bigjools: ok, that's probably fine for me | 09:30 |
| noodles775 | Hey stub, would you be able to go through and update: https://dev.launchpad.net/FoundationsTestPlan/3.1.10 ? There's quite a bit of QA listed there. | 09:50 |
| jtv | stub: any luck? | 10:00 |
| stub | noodles775: I've moved one item. The other two of mine still need QA (one I'm not sure how to test, the other I don't think I have the resources to test without taking staging down for half a day) | 10:01 |
| stub | jtv: So every leaked ObjectInfo I look at is similar to this: | 10:01 |
| stub | (Pdb) random.choice([o for o in gc.get_objects() if isinstance(o, ObjectInfo)]) | 10:01 |
| stub | {<storm.references.Relation object at 0x2dfe550>: {'remote': <POTMsgSet at 0xa063c50>}, 'sequence': 1, <storm.references.Relation object at 0x2dfe850>: {'remote': <POTemplate at 0x5563c50>}, <storm.references.Relation object at 0x2dfe610>: {'remote': <Language at 0x790c190>}} | 10:01 |
| noodles775 | Thanks stub. | 10:02 |
| stub | jtv: inf.get_obj() returns None, which seems to mean it really has been lost | 10:03 |
| jtv | stub: and yet it keeps that reference to the POTMsgSet | 10:04 |
| jtv | jamesh: were the "remote" entries meant to be cleaned up as the objects fell out of cache maybe? | 10:04 |
| stub | Would the POTMsgSet be caching any back references I wonder? | 10:04 |
| jtv | stub: not that I've seen so far | 10:05 |
| jamesh | jtv: they should get cleared out when the key for the reference gets cleared | 10:05 |
| jamesh | they are meant to be strong reference | 10:05 |
| jtv | stub: and these POTMsgSets were not supposed to be in cache any more, right? | 10:07 |
| stub | Pdb) pprint(inf) | 10:08 |
| stub | {<storm.references.Relation object at 0x2dfe550>: {'remote': <POTMsgSet at 0xd2e6550>}, | 10:08 |
| stub | <storm.references.Relation object at 0x2dfe610>: {'remote': <Language at 0x790c190>}, | 10:08 |
| stub | <storm.references.Relation object at 0x2dfe850>: {'remote': <POTemplate at 0x545f810>}, | 10:08 |
| stub | 'sequence': 1} | 10:08 |
| stub | It might well still be in the cache. Why are we interested in the POTMsgSet and not in whatever is holding a reference to this ObjectInfo? | 10:09 |
| stub | Referrers are: | 10:10 |
| stub | <type 'tuple'> | 10:10 |
| stub | <type 'tuple'> | 10:10 |
| stub | <type 'builtin_function_or_method'> | 10:10 |
| stub | <type 'builtin_function_or_method'> | 10:10 |
| stub | <type 'tuple'> | 10:10 |
| stub | <type 'dict'> | 10:10 |
| stub | (one of which will include my interactive session) | 10:10 |
| jtv | So who's holding the tuples and dict? | 10:11 |
| jtv | (I'm making a wild guess that the builtin_function_or_method is the debugger) | 10:11 |
| stub | (Pdb) repr(refs[0]) | 10:20 |
| stub | "({<storm.references.Relation object at 0x2dfe550>: {'remote': <POTMsgSet at 0xd2e6550>}, 'sequence': 1, <storm.references.Relation object at 0x2dfe850>: {'remote': <POTemplate at 0x545f810>}, <storm.references.Relation object at 0x2dfe610>: {'remote': <Language at 0x790c190>}},)" | 10:20 |
| stub | (Pdb) repr(refs[1]) | 10:20 |
| stub | "({<storm.references.Relation object at 0x2dfe550>: {'remote': <POTMsgSet at 0xd2e6550>}, 'sequence': 1, <storm.references.Relation object at 0x2dfe850>: {'remote': <POTemplate at 0x545f810>}, <storm.references.Relation object at 0x2dfe610>: {'remote': <Language at 0x790c190>}},)" | 10:20 |
| stub | (Pdb) repr(refs[2]) | 10:20 |
| stub | '<built-in method _emit_object_deleted of storm.info.ObjectInfo object at 0xd9c9b60>' | 10:20 |
| stub | (Pdb) repr(refs[3]) | 10:20 |
| stub | '<built-in method get_obj of storm.info.ObjectInfo object at 0xd9c9b60>' | 10:20 |
| stub | (Pdb) repr(refs[4]) | 10:20 |
| stub | "({<storm.references.Relation object at 0x2dfe550>: {'remote': <POTMsgSet at 0xd2e6550>}, 'sequence': 1, <storm.references.Relation object at 0x2dfe850>: {'remote': <POTemplate at 0x545f810>}, <storm.references.Relation object at 0x2dfe610>: {'remote': <Language at 0x790c190>}},)" | 10:20 |
| === henninge is now known as henninge-bbl | ||
| stub | A twisty maze of tuples, all of them alike. | 10:21 |
| stub | Gah... that time of the day when my wireless connection starts dropping out :-P | 10:22 |
| stub | jtv: So for that POTMsgSet, there are 229 referrers | 10:26 |
| jtv | stub: are they (or some) TranslationMessages? | 10:27 |
| stub | All dicts, so probably lost ObjectInfos like the above | 10:28 |
| * jtv checks how many TMs we had in memory | 10:28 | |
| jtv | ah | 10:28 |
| jtv | so maybe these are event handlers waiting for _foreign_ keys to be changed? | 10:29 |
| jtv | Remarkable: we're not leaking _any_ TranslationMessages. | 10:30 |
| jtv | at this point it'd be nice to have a neat graph plotted of that maze... | 10:30 |
| stub | Unfortunately all I have is a pdb shell and a crappy connection ;) | 10:31 |
| jtv | stub: maybe this is what we need: http://mg.pov.lt/objgraph/ | 10:31 |
| stub | Could be good. You can try that locally. | 10:33 |
| jtv | It's on Launchpad, interestingly enough, but that's not showing up on google. | 10:33 |
| jtv | stub: missed your message earlier... I'll try objgraph | 10:49 |
| noodles775 | hi danilos, there's one translation bug of yours tagged as needs-testing - bug 459132, have you qa'd it, or can you pls if not? Thanks. | 10:58 |
| mup | Bug #459132: Clean up existing untranslated credits messages <qa-needstesting> <Launchpad Translations:Fix Committed by danilo> <https://launchpad.net/bugs/459132> | 10:58 |
| danilo_ | noodles775, haven't QAd it yet, won't run the script until it's QAd though, it shouldn't block the release | 10:59 |
| noodles775 | danilo_: great, thanks for the update. | 10:59 |
| noodles775 | BjornT: when you get a chance, would you be able to either QA or mark as untestable the item at https://dev.launchpad.net/LaunchpadTestPlan/3.1.10 | 11:01 |
| deryck | Morning, all. | 11:02 |
| mrevell | mthaddon, Hi | 11:08 |
| mthaddon | mrevell: howdy | 11:09 |
| BjornT | noodles775: it is OK, but i can't seem to be able to edit the wiki page | 11:21 |
| noodles775 | Thanks BjornT - I'll update it. | 11:21 |
| noodles775 | BjornT: or not - Type error - I guess the same as you. | 11:22 |
| BjornT | noodles775: yeah | 11:22 |
| === henninge-bbl is now known as henninge | ||
| === salgado-afk is now known as salgado | ||
| danilo_ | noodles775, hey, when's the actual release being rolled out? | 11:35 |
| danilo_ | noodles775, ah, seen the email, never mind :) | 11:35 |
| noodles775 | :) | 11:35 |
| jtv | jamesh, stub: http://rookery.canonical.com/~jtv/objects.png | 11:56 |
| jtv | probably a bad example because this object has legitimate business being in memory | 11:57 |
| stub | jtv: It does? I can generate a new one then ;) | 12:10 |
| jtv | stub: seems to be the same in your graph, yes... I did have to copy your trick of getting a random pick though. I think get_objects may be in-order. | 12:11 |
| jtv | stub: see latest version of my branch, it produces the objects.png at the very end | 12:12 |
| stub | Why do you think the objects should be there? | 12:12 |
| stub | I'm seeing gobs and gobs of ObjectInfo's linked to a lone POTemplate in the top left corner | 12:12 |
| stub | oh - you mean on your graph | 12:15 |
| jtv | well, same on yours: the POTemplates are supposed to be in memory because they're referenced | 12:16 |
| jtv | there should probably be a potmsgset in the graph somewhere | 12:16 |
| stub | Yes - the POTemplates are not the problem. The couple of million ObjectInfo's are. | 12:16 |
| stub | I can't see a POTMsgSet - might have been cuttoff | 12:17 |
| stub | (the graph took a few mins to generate as it is ;) ) | 12:17 |
| jtv | you could start plotting from one... mine is smaller & faster, but maybe doing it all the way at the end allows too much leakage to be cleaned up again | 12:17 |
| stub | The dubious bit to me is the 'changed' link in my graph. There is a set of 4k objects, one of which the ObjectInfo I'm inspecting (after following a few links) | 12:20 |
| jtv | actually... why should there be so many ObjectInfos attached to one POTemplate? I thought jamesh said 2 per object. | 12:20 |
| jtv | "changed" link? | 12:20 |
| * jtv really needs that 52" monitor now | 12:20 | |
| jtv | oh, I have it | 12:21 |
| stub | So these objects are registered on the 'changed' event on the POTemplate I think, and for whatever reason that isn't cleared over transaction boundaries? | 12:22 |
| jtv | or maybe they're sets of objects that storm thinks have changed? | 12:22 |
| jtv | given that committing seems to count as changing the primary key somehow... | 12:22 |
| stub | The only dictionary in EventSystem is the hooks to call. So the 'changed' is the key into the _event._hooks dictionary. | 12:23 |
| jtv | ahok | 12:23 |
| jtv | so... the event hooks aren't cleaning themselves up? | 12:25 |
| stub | Which would indicate that these objects are not unhooking themselves when they drop out of scope I guess? | 12:25 |
| jtv | stub: we can ask niemeyer on #storm | 12:27 |
| noodles775 | Hi salgado ! Could you please take a look at your remaining foundations NEEDSTESTING entries when you get a chance (and possibly others there ;))? | 12:31 |
| salgado | noodles775, I can take a look, but we don't test our own items in foundations, so I'll ask matsubara to do it | 12:32 |
| salgado | matsubara, ^. mine have instructions | 12:32 |
| noodles775 | salgado: fine - as long as they're updated I'm happy :) | 12:32 |
| noodles775 | Thanks! | 12:32 |
| matsubara | salgado, ok | 12:33 |
| === danilo_ is now known as danilos | ||
| bigjools | wgrant: you need to get r-c for your branch as well | 13:25 |
| bigjools | I think we can get it in the regular rollout | 13:26 |
| wgrant | bigjools: Ah, that would be handy. | 13:26 |
| wgrant | noodles775: Can I please have an r-c for https://code.edge.launchpad.net/~wgrant/launchpad/sync-source-v3-fix/+merge/14417? | 13:27 |
| bigjools | and ultimately I'd love it if this code was not in the LP tree | 13:27 |
| wgrant | NSS! | 13:27 |
| bigjools | *cough* | 13:27 |
| bigjools | on that note, have you looked to see if Gina will blow up with 3.0 formats? | 13:27 |
| wgrant | It will. | 13:27 |
| bigjools | fuck | 13:27 |
| wgrant | Yes. | 13:27 |
| bigjools | well-factored code FTW | 13:28 |
| wgrant | But buildds are higher on my priority list at the moment. | 13:28 |
| wgrant | However, I can't do anything on them until tomorrow morning, so gina-time now. | 13:28 |
| wgrant | It shouldn't be too difficult. | 13:29 |
| wgrant | But I wonder how spectactularly it is blowing up at the moment -- is it crashing entirely, or just failing to import some stuff? | 13:30 |
| * wgrant tries to remember how to get this thing running. | 13:32 | |
| * bigjools -> food | 13:35 | |
| stub | jtv: Was it the wordpress product or sourcepackage? | 13:41 |
| jtv | product | 13:41 |
| jtv | but part of that job is done now, I think? | 13:41 |
| stub | jtv: I never attempted wordpress | 13:41 |
| jtv | I thought you did, early on... | 13:42 |
| stub | jtv: I've commented out the gc.collect() and object count stuff. Just reporting memory usage. | 13:42 |
| stub | jtv: No - we did a smaller package first and it failed. | 13:42 |
| jtv | so did you run against the package just now, or the product? | 13:43 |
| stub | file-roller sourcepackage | 13:43 |
| stub | Of course, there is still a coredump lurking in there somewhere ;) | 13:45 |
| jtv | oh yes, that too :( | 13:50 |
| jtv | stub: so wait, you were saying that it was fixed for... file-roller I guess, but not for wordpress, right? | 13:50 |
| jtv | stub: or did you mean to say "*Now* for that wordpress run"? | 13:51 |
| stub | erm... yes. typo ;) | 13:51 |
| jtv | phew! | 13:53 |
| wgrant | bigjools: OK, great. The fix for gina is simple, and for now it will just skip the package. | 13:55 |
| === abentley1 is now known as abentley | ||
| === sidnei-away is now known as sidnei | ||
| bigjools | wgrant: awesome, thanks | 14:16 |
| sinzui | noodles775: The registry is OK to release now | 14:19 |
| noodles775 | Thanks sinzui ! | 14:20 |
| noodles775 | matsubara: how are you going with the foundations QA? | 14:21 |
| matsubara | noodles775, haven't touched that yet. it's next in my list though | 14:22 |
| noodles775 | matsubara: great. | 14:22 |
| noodles775 | matsubara: I'll do salgado's items that have instructions now. | 14:27 |
| matsubara | noodles775, I'm doing r9779 feel free to take the next one | 14:27 |
| noodles775 | matsubara: yep, taking 9817 | 14:28 |
| noodles775 | matsubara: actually, but I think I *need* you anyway - do you have access to staging's mailbox? If so, can you confirm the email as outlined there. | 14:29 |
| matsubara | noodles775, btw, I'm syncing my local mailbox to have the staging email for those login workflows, I'll let you know when I get your email :-) | 14:30 |
| noodles775 | taa | 14:30 |
| matsubara | noodles775, it'll take some time since the mailbox is huge | 14:30 |
| noodles775 | matsubara: ok, so pls just update that item too (I guess it wasn't so helpful for me to try to do some!) | 14:31 |
| matsubara | noodles775, will do. no worries :-) | 14:31 |
| Ursinha | matsubara, is it huge even with the daily cleaning? | 14:31 |
| matsubara | Ursinha, the problem is that my offlineimap cache hasn't been updated in a long time | 14:36 |
| Ursinha | matsubara, maybe you should use the regular imap now that the inbox is manageable | 14:37 |
| matsubara | Ursinha, offlineimap is still a lot faster IMO | 14:37 |
| Ursinha | matsubara, not for sporadic access, I guess | 14:37 |
| Ursinha | but it's a matter of taste :) | 14:37 |
| matsubara | Ursinha, mutt + imap sucks anyway | 14:38 |
| wgrant | Can I grab an r-c for https://code.edge.launchpad.net/~wgrant/launchpad/sync-source-v3-fix/+merge/14417? | 14:38 |
| Ursinha | noodles775, ^ | 14:38 |
| noodles775 | looking | 14:38 |
| noodles775 | Thanks wgrant - rc approved. | 14:44 |
| wgrant | noodles775: Thanks. | 14:44 |
| noodles775 | wgrant: is someone already organised to land that? | 14:45 |
| wgrant | noodles775: Not sure. bigjools ^^? | 14:46 |
| bigjools | I am OTP, would you mind landing it noodles775? | 14:46 |
| === sidnei is now known as sidnei-away | ||
| wgrant | noodles775: If you can, thanks! Happy archive admins are good. | 14:49 |
| * wgrant sleeps. | 14:49 | |
| noodles775 | wgrant, bigjools: yep, no probs. Sleep well wgrant :) | 14:49 |
| bigjools | g'night wgrant | 14:49 |
| === salgado is now known as salgado-lunch | ||
| barry | reviewers, lurkers, beuno and anybody else -> #launchpad-meeting in 5m | 14:56 |
| barry | reviewers -> #launchpad-meeting | 15:00 |
| mpt | sinzui, hi, do you have time to supply those UDS discussion estimates today? | 15:06 |
| sinzui | mpt: no. I am doing them today | 15:07 |
| sinzui | mpt: I can give scale, not time. I may be able to say the number of releases | 15:07 |
| mpt | sinzui, I'm mainly concerned with making it easy for robbiew to schedule UDS at the moment :-) Estimates for the actual implementation are interesting, but not required for that. | 15:08 |
| sinzui | Oh, time needed to discuss. I really have not idea. Maybe I will when I have this work broken into stories with technical notes. | 15:10 |
| mpt | sinzui, "not at all" is a possible valid answer for the Launchpad-related topics, if they would be better discussed outside UDS. | 15:12 |
| sinzui | noodles775: ping | 15:13 |
| noodles775 | sinzui: hi | 15:14 |
| mpt | sinzui, but if there are Registry + Soyuz people attending UDS, it would make sense to have face-to-face discussions on them since they'll be higher bandwidth than teleconferences | 15:14 |
| sinzui | noodles775: I think we need another rc https://staging.launchpad.net/bzr/+milestone/2.0.1 | 15:14 |
| sinzui | https://staging.launchpad.net/gdp/trunk/0.2 | 15:14 |
| sinzui | Bug 473738 reports issues that may relate to recent CSS changes | 15:14 |
| mup | Bug #473738: milestone page refuses to let me see the bug status (after resizing) <Launchpad Registry:New> <https://launchpad.net/bugs/473738> | 15:14 |
| * noodles775 looks | 15:15 | |
| sinzui | noodles775: The issue appears to be the "Download files for this release" table. the page lays out correctly if you remove the release | 15:16 |
| sinzui | or maybe the dual combination or .portlet .full-page-width | 15:18 |
| sinzui | noodles775: I see the issue, The DOM shows the full-page-width is nested inside another. This is a pretty simple fix. | 15:20 |
| noodles775 | sinzui: great - we've still time to land on db-devel (especially as you won't need to run the suite if it's just a css change). Let me know when it's ready. Thanks! | 15:21 |
| noodles775 | oh, although that would be a template change? still time though. | 15:21 |
| sinzui | the milestone tests are pretty robust. we do not test markup, only content. the class is not tested | 15:25 |
| noodles775 | Great. | 15:25 |
| noodles775 | matsubara: thanks for clearing the foundations QA! | 15:25 |
| matsubara | noodles775, np :-) | 15:25 |
| sinzui | noodles775: Another course is to add a CSS rule for .full-page-width .full-page-width that disables the width change. | 15:25 |
| matsubara | noodles775, about the one item in the Launchpad itself queue, I already pinged mrevell about it and basically we can't check on staging yet as it's still is one revision behind | 15:26 |
| Chex | sinzui: did you see my message on your staging script run last nite?? | 15:26 |
| noodles775 | sinzui: sounds much safer - and would actually be useful too? | 15:26 |
| sinzui | Chex: I did I would be a nice read | 15:27 |
| mrevell | matsubara, you pinged me about that? I don't see it. | 15:27 |
| noodles775 | matsubara: yep, I can do that later - it's easy. | 15:27 |
| Chex | sinzui: oki-doki, hang on | 15:27 |
| barry | abentley: what rev of lp:bzr-pipeline works with bzr 2.0.1? i just updated my plugin and it borkeded | 15:27 |
| sinzui | noodles775: it is safer, and it clearly defines our intent | 15:27 |
| matsubara | mrevell, I pinged you on another channel | 15:27 |
| noodles775 | mrevell: just the blog post update... | 15:27 |
| mrevell | noodles775, all ok with it? | 15:27 |
| abentley | barry: The lp:bzr-pipeline/stable branch works with bzr 2.0.x | 15:28 |
| noodles775 | mrevell: yep, should be, we just need to wait for staging to update before we can QA it, that's all. | 15:28 |
| barry | abentley: cool, thanks | 15:28 |
| abentley | barry: np | 15:29 |
| Chex | sinzui: chinstrap:~stasik/tmp/ | 15:29 |
| === matsubara is now known as matsubara-lunch | ||
| noodles775_ | um, is there a bug with the display of MP's? | 16:04 |
| noodles775_ | https://code.edge.launchpad.net/~matthew.revell/launchpad/whatsnew-3110/+merge/14231 | 16:04 |
| noodles775_ | The original reviewer is not displayed there, it looks like it's reviewed by jtv, but by the comment seems to be abel. | 16:05 |
| jtv | noodles775_: I updated its status only | 16:05 |
| jtv | noodles775_: after the original reviewer voted Approve. | 16:05 |
| noodles775_ | jtv: ah, *phew*, thanks. | 16:05 |
| jtv | noodles775_: sorry for the confusion, I just wanted to get it off the "reviews you should be doing RIGHT NOW, slacker!" list | 16:06 |
| noodles775_ | np... good thing to do! | 16:06 |
| jtv | Well yes and no... technically one could argue I might not have been qualified to decide whether the Approved vote was enough to approve the whole MP | 16:07 |
| noodles775_ | yes, I should be doing that when I do the rc right? | 16:07 |
| === danilo_ is now known as danilos | ||
| noodles775_ | I'm still confused why abel's not listed as a reviewer - maybe he just didn't select 'Approve' when reviewing it and I didn't notice before? | 16:08 |
| sinzui | noodles775_: I am now weeping. I can see a programming error in the product-release-finder. I am inclined to purse a CP rather than fix it for an RC. | 16:09 |
| sinzui | noodles775_: The CSS fix for the milestone page is simple, but there is something else wrong, the sidebar is in the wrong position. There must be a markup nesting error, but I cannot see it | 16:10 |
| * sinzui blows a gasket. | 16:10 | |
| bigjools | poor gasket | 16:10 |
| noodles775_ | sinzui: no stress - I think it's not really critical - it doesn't stop people from seeing the information as you can always scroll. | 16:11 |
| noodles775_ | sinzui: what do you think? | 16:11 |
| sinzui | yes that is true | 16:11 |
| sinzui | The side bar is at the bottom of the page | 16:12 |
| noodles775_ | sinzui: can the simple css fix just be landed on its own and leave the side bar issue for later? Up to you. | 16:14 |
| sinzui | absolutely | 16:14 |
| === salgado-lunch is now known as salgado | ||
| sinzui | noodles775_: FF hates this <div style="clear:both" /> changing the markup to use an open and close tag fixes the side bar. | 16:17 |
| noodles775_ | Great! | 16:18 |
| sinzui | oh there were only two cases in the whole tree | 16:18 |
| sinzui | That that cause the nesting error in the DOM, but the XML checker passed it | 16:19 |
| sinzui | It is same the reviewers meeting is over now | 16:19 |
| noodles775_ | yeah | 16:20 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| danilos | Ursinha, so, launchpad-2207-00-0.sql is a base database description from one point in time (judging how stub usually names them, that one is from 2.2 LP series from July) | 16:37 |
| Ursinha | danilos, go ahead | 16:37 |
| danilos | Ursinha, the changes you showed me in http://paste.ubuntu.com/309660/ are correct SQL-wise, but you need to make it into an incremental patch we can apply on the live database | 16:37 |
| danilos | Ursinha, that means using ALTER TABLEs and similar | 16:37 |
| danilos | Ursinha, look at examples in database/schema/patch-*.sql | 16:38 |
| Ursinha | danilos, I'm doing that, creating one with alter table, that is | 16:38 |
| Ursinha | I'd like to know if the changes were correct before doing that | 16:38 |
| Ursinha | danilos, right, after that what should I do? | 16:40 |
| danilos | Ursinha, create a patch and name it something like patch-2207-95-0.sql (use a number instead of 95 that is not used by existing patches; do update LaunchpadDatabaseRevision table with the number as well) | 16:44 |
| Ursinha | right | 16:45 |
| danilos | Ursinha, the reason why I am saying you started the wrong way is because you should be able to play with this on launchpad_dev DB, i.e. to construct relevant fields; just do "psql launchpad_dev", and issue ALTER TABLEs there, create new indexes if needed and whatnot | 16:52 |
| Ursinha | danilos, oh, I see | 16:53 |
| danilos | Ursinha, patching launchpad-*.sql is not something you'd ever want to do, at least not until you get promoted to being stub :) | 16:53 |
| Ursinha | danilos, haha sure :) | 16:53 |
| Ursinha | danilos, not my intention here :) | 16:53 |
| danilos | Ursinha, also, doing direct modifications in 'psql launchpad_dev' is much faster than re-running make schema a few times | 16:54 |
| Ursinha | danilos, indeed it is, but again, I just wanted to check with you if those changes were correct :) | 16:55 |
| Ursinha | I couldn't think of other way :) | 16:55 |
| Ursinha | danilos, sorry :P | 17:00 |
| Ursinha | danilos, this is cool exercise, btw | 17:02 |
| danilos | Ursinha, I am going back to not knowing anything about it :) | 17:02 |
| danilos | Ursinha, in a call as well now :) | 17:02 |
| Ursinha | danilos, sorry, will disturb you later then :) | 17:02 |
| === matsubara-lunch is now known as matsubara | ||
| Ursinha | matsubara, did we have any problems with summaries generator script? I see no lpnet summary for yesterday | 17:07 |
| matsubara | Ursinha, likely. if the html/txt summary is not in the oops-summaries/ directory, then it wasn't generated. can sort it ou? | 17:09 |
| Ursinha | matsubara, ok, I'll try to run that again | 17:09 |
| Ursinha | matsubara, thanks | 17:10 |
| thumper | when are we getting yui3 release code into LP? | 17:13 |
| thumper | I spent time chasing stuff last night hitting issues by reading online docs | 17:13 |
| thumper | only to find that our code didn't have it | 17:14 |
| thumper | the methods I want that is | 17:14 |
| sinzui | Chex: I think the staging reset clobbered the product-release-finder test earlier that I anticipated. Can you run the script now *if* we are not updating the staging? | 17:15 |
| Chex | sinzui: yes sure, hang on and let me check | 17:22 |
| === deryck is now known as deryck[lunch] | ||
| rockstar | thumper, I think mars is working on it (and I hope it's done in time for the sprint) | 17:27 |
| === flacoste is now known as flacoste_lunch | ||
| salgado | sidnei-away, when you get back, I'd appreciate if you could have a look at bug 474459 and see if you've got any ideas on what could've caused that | 17:57 |
| mup | Bug #474459: Text input in the picker's footer can't be focused <LAZR Javascript Library:New> <https://launchpad.net/bugs/474459> | 17:57 |
| mpt | sinzui, robbiew is doing the UDS scheduling this week, so if you think those LP bits would benefit from discussing at UDS at all, I suggest either today or tomorrow :-) | 18:04 |
| sinzui | mpt: I am struggling to get this done. I will try | 18:05 |
| mpt | thanks | 18:05 |
| Ursinha | danilos, ping me when you're available, please :) | 18:30 |
| danilos | Ursinha, ping | 18:30 |
| danilos | Ursinha, what's up? :) | 18:31 |
| Ursinha | danilos, http://paste.ubuntu.com/309797/ | 18:31 |
| Ursinha | see if this is correct, please | 18:31 |
| danilos | Ursinha, now, that looks much better | 18:33 |
| danilos | Ursinha, you don't want to use 9 as the number though, at least until stub assigns you one, since it's much more likely you are going to merge with latest db-devel and somebody would have already used that number | 18:34 |
| danilos | Ursinha, so, go with something like 99 or 92 or 97 or... | 18:34 |
| Ursinha | danilos, I see, renaming.. | 18:34 |
| danilos | Ursinha, and, the next step is to add a field description to comments.sql and you can submit that for DB review | 18:34 |
| Ursinha | danilos, ok, I'll do this right now | 18:35 |
| danilos | Ursinha, basically, the DB patch + comments.sql modification should be all you've got in this branch | 18:35 |
| Ursinha | danilos, sorry taking so long, had to figure out the problem with the oops summaries | 18:35 |
| Ursinha | danilos, right. | 18:35 |
| Ursinha | danilos, should I file an mp or just submit my branch to lp? | 18:35 |
| danilos | Ursinha, excuses, excuses... it's not like we are releasing tomorrow! | 18:36 |
| Ursinha | hehe | 18:36 |
| danilos | Ursinha, file a new bug for this branch, attach a branch to it, make an MP and ask for stub's review | 18:36 |
| Ursinha | danilos, I've filed, will do that | 18:37 |
| danilos | Ursinha, make an MP against lp:launchpad (not launchpad/devel), and once you get approval and we are good to land stuff, land it on db-devel | 18:37 |
| danilos | Ursinha, also, in general, you want to start branches like these by branching off db-devel, especially if you are going to land it like that, but it shouldn't be a problem now that you are going to land it after the rollout | 18:38 |
| Ursinha | danilos, I see that in the docs it says to name the file patch-xx-99-0.sql, so my file should be named patch-90-99-0.sql? | 18:39 |
| Ursinha | danilos, I did that already | 18:39 |
| danilos | Ursinha, excellent :) | 18:39 |
| danilos | Ursinha, no | 18:39 |
| danilos | Ursinha, xx should be 2207 in that case | 18:39 |
| Ursinha | oh *stupid* | 18:39 |
| Ursinha | sorry | 18:39 |
| Ursinha | lack of coffee here | 18:39 |
| danilos | Ursinha, 99 is the least likely number to have been reached, but anything well far off from the latest number is good :) | 18:39 |
| danilos | Ursinha, excuses, excuses, it's not like... :P | 18:40 |
| Ursinha | danilos, I won't use 99 because it's likely someone had the same idea :P | 18:40 |
| danilos | Ursinha, it doesn't matter, stub will give you a new number and then you'll bzr mv to that | 18:40 |
| danilos | Ursinha, if anyone managed to land a patch with -99, you'd better let them know :) | 18:41 |
| danilos | Ursinha, anyway, after that, the next step is to do the interface/model changes to add translation_focus to IProduct and Product, make it settable from +changetranslators | 18:43 |
| danilos | Ursinha, and finally, modify primary_translatable to point to the translation_focus if it's defined, similar to what DistroSeries.primary_translatable is doing | 18:43 |
| Ursinha | danilos, please, hold on for a moment :) | 18:43 |
| danilos | Ursinha, I ain't, I am about to split off :) take notes of above, and work on it one step at a time | 18:44 |
| danilos | Ursinha, don't be surprised if you don't finish it all by the end of the day, but do ask others about how this is done | 18:44 |
| danilos | Ursinha, this ain't anything others can't help with | 18:44 |
| Ursinha | danilos, excuses, excuses... it's not like it's EOD for you already :P | 18:44 |
| danilos | Ursinha, it's not like it is, it's well beyond it :) | 18:45 |
| Ursinha | danilos, :) | 18:45 |
| Ursinha | danilos, I took notes, will add the patch to the branch, comment and open and mp | 18:45 |
| Ursinha | hopefully will have other changes to discuss tomorrow | 18:45 |
| Ursinha | *open an mp | 18:46 |
| Ursinha | will bug everyone else to accomplish that :) | 18:46 |
| sinzui | salgado: Chex Do you know if there has been any action on bug 458835 | 18:47 |
| mup | Bug #458835: download counters are a few days old <Launchpad Registry:Triaged by salgado> <https://launchpad.net/bugs/458835> | 18:47 |
| danilos | Ursinha, of course :) thanks for the effort you are putting into it :) | 18:48 |
| sinzui | salgado: Chex: is there a job being setup? is there an RT | 18:48 |
| danilos | Ursinha, anyway, I am off | 18:48 |
| === danilos is now known as danilo-afk | ||
| Ursinha | danilo-afk, have a nice evening then :) | 18:48 |
| salgado | sinzui, yes, we now have all logs available for the script to parse but we're missing a config change to point it to the new place. the config change has landed and should be rolled out tomorrow | 18:49 |
| sinzui | salgado: rock. should I mark the bug fix committed? | 18:49 |
| salgado | sinzui, yeah, I think that's be reasonable | 18:50 |
| === deryck[lunch] is now known as deryck | ||
| sinzui | salgado: If I have just and SSO account though Ubuntu, can I log into Launchpad *now* and get a profile created automatically? | 18:58 |
| salgado | sinzui, yes | 18:58 |
| * salgado double checks | 18:58 | |
| sinzui | salgado: there is a test I can read? | 18:58 |
| * sinzui is uncertain because of so many bugs about the transition from account to person | 18:59 | |
| Ursinha | I wonder why is bzr telling me I cannot push my branch to lp due to uncommitted changes when bzr status shows nothing | 19:01 |
| salgado | sinzui, tests/test_login.py in lib/c/l/ | 19:02 |
| sinzui | thanks very much | 19:03 |
| === dpm is now known as dpm-afk | ||
| === flacoste_lunch is now known as flacoste | ||
| * thumper punches javascript in the face | 19:54 | |
| sinzui | barry: EdwinGrubbs: I just sent you an annotated summary of the the UDS software discussions about the software center. I need you estimates of the time needed to discuss each item. | 20:12 |
| barry | sinzui: k | 20:14 |
| === salgado is now known as salgado-afk | ||
| === matsubara is now known as matsubara-afk | ||
| * rockstar -> lunch/gym | 20:46 | |
| === sidnei-away is now known as sidnei | ||
| sidnei | salgado-afk: is that with yui 3.0.0? | 20:47 |
| sidnei | salgado-afk: i suspect it might be a zIndex issue, but would have to look closely | 20:48 |
| sinzui | barry: yes soyuz is going to the sprint. The mis-perception is because registry *owns* a package record, is must also know about the actual source package and the built package | 21:02 |
| thumper | beuno: ping | 21:02 |
| sinzui | barry: I'll ask bigjools about who should attend. | 21:03 |
| === lionel_ is now known as lionel | ||
| thumper | rockstar: where is the spinner icon? | 21:10 |
| rockstar | thumper, I believe /@@/spinner | 21:11 |
| * rockstar really should go eat lunch now. | 21:11 | |
| thumper | rockstar: I'd like a call with you when you have finished eating | 21:13 |
| rockstar | thumper, okay. I was also hoping to hit the gym, but maybe I'll do that later tonight. | 21:15 |
| barry | sinzui: +1 | 21:17 |
| rockstar | thumper, ready. | 21:17 |
| === EdwinGrubbs2 is now known as EdwinGrubbs | ||
| wgrant | Bug #474593 looks LOSAish. | 22:07 |
| mup | Bug #474593: Certain URLs don't redirect to SSL <Launchpad itself:Confirmed> <https://launchpad.net/bugs/474593> | 22:07 |
| mwhudson | wgrant: very odd | 22:10 |
| mwhudson | mbarnett: hi, can you look at the bug wgrant just mentioned? | 22:10 |
| wgrant | mwhudson: Rather. | 22:11 |
| beuno | thumper, hi | 22:12 |
| thumper | beuno: too late, found my answer | 22:12 |
| * mwhudson finds lib/canonical/buildd for the first time | 22:13 | |
| mwhudson | omg the horror | 22:13 |
| Chex | wgrant: mwhudson: hi, looking at that bug. | 22:13 |
| mwhudson | Chex: cool | 22:13 |
| wgrant | Chex: Thanks. | 22:13 |
| * thumper looks at the file too | 22:13 | |
| wgrant | mwhudson: RUN AWAY. | 22:13 |
| wgrant | mwhudson: NOW. | 22:13 |
| thumper | mwhudson: OMG even the directory contents looks scary | 22:14 |
| mwhudson | wgrant: sadly i'm not sure that's an option | 22:14 |
| mwhudson | if we're luckly maybe rm -rf will be | 22:14 |
| thumper | heh | 22:15 |
| wgrant | It doesn't quite run properly on Karmic, but can be made to with a bit of patching. | 22:15 |
| wgrant | But to get it to actually build, it needs a bit more. | 22:15 |
| mwhudson | some of it looks very similar to code i wrote actually... | 22:15 |
| wgrant | Just remember to ignore all of the docs in there. | 22:16 |
| mwhudson | (ProcessMonitorProtocol, to be specific) | 22:16 |
| mwhudson | wgrant: heh ok | 22:16 |
| wgrant | Some of them are a little bit correct. | 22:16 |
| wgrant | But most of them are just speculation. | 22:16 |
| mwhudson | wgrant: can i ask some basic questions about this code? | 22:17 |
| wgrant | mwhudson: Sure. | 22:17 |
| mwhudson | wgrant: aiui the buildd-manager runs from cron and basically looks through the list of builds pending and builders and assigns builds to idle builders | 22:18 |
| wgrant | mwhudson: buildd-manager is a daemon which polls everything every 5 seconds. | 22:18 |
| mwhudson | oh ok | 22:18 |
| wgrant | It's possible the old slave-scanner was a cron job, but that was before my time. | 22:19 |
| mwhudson | but the second half is correct? | 22:19 |
| wgrant | That's part of its task. | 22:19 |
| mwhudson | yeah, i think that changed recently | 22:19 |
| mwhudson | so one thing i don't really get is what "assigns builds to idle builders" means | 22:19 |
| wgrant | It also watches builders, and fucks them up if they are not doing what it things they should be. | 22:19 |
| wgrant | And takes binaries from them when they finish. | 22:19 |
| wgrant | What don't you understand about that? | 22:19 |
| mwhudson | well i think i know what happens | 22:20 |
| mwhudson | but i'm not sure | 22:20 |
| mwhudson | so there's a process on the builder that talks xml-rpc | 22:20 |
| wgrant | Right. | 22:20 |
| mwhudson | when it is given a job to do, it sets up a chroot/fires up a guest vm > | 22:20 |
| wgrant | That's the beast that lurks in lib/canonical/buildd. | 22:20 |
| mwhudson | ? | 22:20 |
| wgrant | Ah, not quite. | 22:21 |
| wgrant | The way the VM stuff works is nothing to do with lp-buildd. | 22:21 |
| mwhudson | or is it already running in the chroot/vm | 22:21 |
| wgrant | lp-buildd lives *inside* the VM. | 22:21 |
| mwhudson | aah ok | 22:21 |
| wgrant | Before dispatching a build to a virtual builder, buildd-manager will fire a reset trigger to the host over SSH. | 22:21 |
| wgrant | (this part is not public, but I know vaguely how it works) | 22:21 |
| mwhudson | so a chroot is involved even when the builder is virtualized? | 22:22 |
| wgrant | The guest, which contains the lp-buildd, then reboots with a fresh image. | 22:22 |
| wgrant | Yes. | 22:22 |
| mwhudson | ok | 22:22 |
| wgrant | To ensure a clean environment. | 22:22 |
| mwhudson | that's a good thing to learn :) | 22:22 |
| wgrant | So, buildd-manager then tells the builder to get all the files it needs. | 22:22 |
| wgrant | That is, the chroot tarball and all the source files. | 22:22 |
| mwhudson | lp-buildd is the thing that runs on the slave? | 22:23 |
| wgrant | (the builder then grabs them from the librarian directly) | 22:23 |
| wgrant | Right. | 22:23 |
| mwhudson | aka the builder | 22:23 |
| mwhudson | ok | 22:23 |
| wgrant | Once the builder has all the files cached, buildd-manager calls build(), and the builder does its stuff. | 22:23 |
| wgrant | buildd-manager will notice when a builder has finished from its status message. | 22:24 |
| mwhudson | the builder runs a subprocess something very vaguely like "chroot /srv/karmic make" ? | 22:24 |
| wgrant | The status message contains the build status (successful, failed, dependency wait, etc.), and names and hashes of all of the built files. | 22:24 |
| wgrant | Very very vaguely, but yes. | 22:24 |
| mwhudson | how does the builder find the files? | 22:25 |
| wgrant | (that's the sbuild thing you see there -- it's an ancient unmaintained fork of the standard Debian buildd tool) | 22:25 |
| mwhudson | is this where that terrible perl script (sbuild) comes in? | 22:25 |
| wgrant | Hm. Good question. | 22:25 |
| wgrant | I presume sbuild dumps them into a directory that it just lists. | 22:25 |
| * wgrant checks. | 22:25 | |
| jml | barry, you still around? | 22:25 |
| barry | jml: yep | 22:26 |
| mwhudson | oh so the subprocess is more like "chroot <chroot> sbuild" ? | 22:26 |
| wgrant | mwhudson: sbuild does the chrooting itself. | 22:26 |
| jml | barry, yay | 22:26 |
| wgrant | It runs outside it, but jumps into it to do most of the work. | 22:26 |
| jml | barry, I uploaded a patch to reproduce bug 394133 | 22:26 |
| mup | Bug #394133: Truncated links in Launchpad mailing lists automatic messages <mailing-lists> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/394133> | 22:26 |
| mwhudson | wgrant: ok | 22:26 |
| wgrant | lp-buildd actually just calls sbuild-package, which then calls sbuild. | 22:27 |
| jml | barry, but I don't know how to fix it. | 22:27 |
| barry | jml: sec.. | 22:27 |
| wgrant | mwhudson: So, the sbuild will result in one .changes file, which references the rest of the binary files. The .changes file has a known name, so canonical.buildd.debian.DebianBuildManager.gatherResults can use that to find the rest of the files. | 22:28 |
| wgrant | It then sticks them in the file cache, at which point they can be retrieved by the buildd-manager simply by knowing the SHA1. | 22:29 |
| barry | jml: do you want me to take a crack at it? | 22:29 |
| gary_poster | sinzui: I'm sorry to bother you, but I'd like your thoughts. I'm triaging and wondering what the heck to do with https://bugs.edge.launchpad.net/launchpad-foundations/+bug/70416 . It seems like a legitimate, important bug, and even importantly tied to our 6-month theme. Do you know of some already-present feature or initiative that would address the problem? If not, I think I'll bring this up on the mailing list as an im | 22:30 |
| gary_poster | consider. | 22:30 |
| mup | Bug #70416: Gnome menu names not linked to packages <Launchpad Foundations:New> <https://launchpad.net/bugs/70416> | 22:30 |
| jml | barry, yes please, or at least give me some guidance on how to fix it | 22:30 |
| jml | barry, my last comment on the bug report has a lot of details. | 22:31 |
| mwhudson | wgrant: i guess "sbuild does the chrooting" wasn't what i wanted to hear | 22:31 |
| mwhudson | wgrant: you know why i'm asking about this? | 22:31 |
| lifeless | mwhudson: is this about building source packages? | 22:31 |
| wgrant | mwhudson: BFB, I presume. | 22:31 |
| lifeless | mwhudson: if so, I have that happening in a schroot for another project, using bzr-builder | 22:32 |
| sinzui | gary_poster: I cannot comprehend what is being asked for | 22:32 |
| mwhudson | wgrant, lifeless: more about running jobs where we don't trust the code running | 22:32 |
| mwhudson | of which BFB is a particular case yes | 22:32 |
| gary_poster | sinzui: you don't know what I am asking of you, or what the bug report describes? | 22:32 |
| lifeless | mwhudson: schroot can do sessions | 22:32 |
| lifeless | its very useful | 22:32 |
| sinzui | gary_poster: Ubuntu does *not* want users to report bugs via launchpad. they should use their desktop | 22:33 |
| wgrant | It's already secure in the VM, but it's probably still good to run it in a chroot inside that. | 22:33 |
| wgrant | But for build cleanliness reasons. | 22:33 |
| gary_poster | sinzui: right, so I can close this and say "you should use apport now"? | 22:33 |
| gary_poster | that's just crash reports, so not quite the same | 22:34 |
| lifeless | mwhudson: I've sent you a mail | 22:34 |
| lifeless | with some helpers I put together | 22:34 |
| wgrant | I'm not sure there's much point using schroot, since we don't need sessions and need to grab tarballs dynamically. But lifeless' work could well be useful. | 22:34 |
| sinzui | gary_poster: Oh, yes I think it should be closed, but if you hesitate, target to launchpad bugs, because that is only launchpad app involved i this use case | 22:34 |
| gary_poster | sinzui: ok, cool. thank you. | 22:34 |
| sinzui | gary_poster: I stole 180 bugs from you a few weeks ago | 22:35 |
| sinzui | I hope you don't miss them | 22:35 |
| gary_poster | sinzui: I know and appreciate :-) | 22:35 |
| wgrant | mwhudson: I imagine it will be pretty similar to the current sbuild setup, except without a few thousand lines of Perl. | 22:35 |
| wgrant | Although... hmmm. We need to manage build-deps somehow. | 22:35 |
| wgrant | And that is messy. | 22:35 |
| wgrant | :( | 22:36 |
| lifeless | wgrant: schroot with root user permitted | 22:37 |
| lifeless | or sudo permission in the chroot for a separate user to run apt-get | 22:38 |
| lifeless | mwhudson: you'll also want to see my bugs on bzr-builder filed recently | 22:38 |
| wgrant | lifeless: Permissions are not the problem, sadly. | 22:38 |
| lifeless | while its not bzr-builddeb, I was solving/facing the same issues you're thinking about, I suspect. | 22:38 |
| lifeless | wgrant: oh? | 22:38 |
| mwhudson | lifeless: i think first it probably makes sense to focus on rosetta's needs as i think they're a bit less exciting than BDB | 22:39 |
| wgrant | lifeless: Resolving build-deps is a difficult problem. | 22:39 |
| mwhudson | BFB | 22:39 |
| mwhudson | but maybe that's just because i don't really know what they are | 22:39 |
| wgrant | Although... it's unclear at this point how bzr-bp-time dependencies will be specified. | 22:39 |
| wgrant | data and even you are a LP admin (Foo Bar) you, that field would be read-only. | 22:40 |
| lifeless | dpkg-checkbuilddeps | 22:40 |
| wgrant | Um. | 22:40 |
| wgrant | Oops | 22:40 |
| wgrant | lifeless: That checks. Does not help too much with installing. | 22:40 |
| wgrant | sbuild has its own magic to do this. | 22:40 |
| barry | jml: i added some ideas as a comment. i can try them fairly quickly on your branch... | 22:40 |
| jml | barry, cool. thanks. | 22:41 |
| lifeless | wgrant: its trivial - you run dpkg-checkbuilddeps, apt-get install the resulting list | 22:41 |
| wgrant | Hmm. | 22:41 |
| barry | jml: i don't see a linked branch. are you sure you pushed it? | 22:41 |
| jml | barry, harumph.... | 22:42 |
| lifeless | wgrant: its not as simple as apt-get install `dpkg-checkbuilddeps`, but its not much more, really. | 22:42 |
| lifeless | wgrant: you use a chroot session for efficiency | 22:42 |
| jml | barry, I pushed it, but apparently the branch linking UI failed me | 22:42 |
| barry | ;) | 22:42 |
| lifeless | and thats why I talked about permissions ;) | 22:42 |
| wgrant | Is there a spec for the Rosetta stuff? | 22:42 |
| jml | barry, lp:~jml/launchpad/ml-links-bug-394133 | 22:42 |
| mwhudson | wgrant: i have the very vague notion that the initial plan is "if you have funny bzr-lp-build time deps your build will fail" | 22:43 |
| barry | thx | 22:43 |
| mwhudson | james_w would be a better person to ask that though | 22:43 |
| wgrant | mwhudson: That seems unlikely. | 22:43 |
| wgrant | mwhudson: But would make the initial implementation much much easier. | 22:44 |
| james_w | if you have funny deps for the construction of a source package then your package is buggy | 22:46 |
| james_w | it's a requirement to specify then in Build-Depends | 22:46 |
| james_w | so installing those would work | 22:46 |
| mwhudson | ah ok | 22:46 |
| wgrant | Ah, so that's how it's working. | 22:46 |
| wgrant | I see. | 22:46 |
| * wgrant cries. | 22:46 | |
| jml | there there | 22:47 |
| wgrant | So. | 22:47 |
| thumper | rockstar: it seems that the pretty overlay doesn't have an easy way to replace the content | 22:59 |
| wgrant | The slave should be pretty simple: | 23:00 |
| wgrant | 1) Unpack chroot (with existing code) | 23:00 |
| wgrant | 2) Mount chroot (also existing) | 23:00 |
| wgrant | 3) Check out branch | 23:00 |
| wgrant | 4) pbuilder-satisfydepends (or equivalent) | 23:00 |
| wgrant | 5) bzr-buildpackage | 23:00 |
| wgrant | 6) Find changes file | 23:00 |
| wgrant | 7) Done | 23:00 |
| wgrant | Most of the code can be extracted from the existing Debian slave. | 23:01 |
| thumper | rockstar: or perhaps I'm looking in the wrong place | 23:01 |
| wgrant | Except for like three commands. | 23:01 |
| mwhudson | wgrant: the code for steps 1-2 is in perl though, right? | 23:07 |
| mwhudson | it doesn't sound too scary though really | 23:07 |
| wgrant | mwhudson: No. Those two bits are lp-buildd-specific shell scripts (mount-chroot and unpack-chroot) | 23:07 |
| mwhudson | ah ok | 23:07 |
| mwhudson | shell, way better than perl! | 23:07 |
| * mwhudson coughs | 23:07 | |
| wgrant | They're also only 80 lines in total, not 4000 | 23:08 |
| mwhudson | wgrant: i don't suppose you know this for sure, but i guess the lp-buildd inside the vm is started by an @reboot crontab entry or similar? | 23:09 |
| wgrant | mwhudson: The package has an init script. | 23:09 |
| wgrant | I don't know if that's used in production, but I presume so. | 23:09 |
| mwhudson | oh right | 23:10 |
| * wgrant disappears for a while. | 23:10 | |
| mwhudson | wgrant: thanks for the input | 23:11 |
| rockstar | thumper, yea, you may have to create it. | 23:26 |
| thumper | rockstar: working prototype lp:~thumper/launchpad/popup-diff | 23:26 |
| thumper | rockstar: very ugly right now | 23:27 |
| rockstar | thumper, javascript is pretty ugly. :) | 23:27 |
| thumper | rockstar: but it has colours, dynamic loading on demand, and only load once | 23:27 |
| thumper | rockstar: what I want is to have nice scrolling when diff appears, and limiting the visible size of the overlay | 23:27 |
| thumper | rockstar: ideas? | 23:27 |
| thumper | rockstar: although, I'll have to wait, I'm afk for a few hours | 23:29 |
| rockstar | thumper, okay. | 23:33 |
| wgrant | mwhudson: Anything else you want to know? | 23:55 |
| mwhudson | wgrant: not right now thanks | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
