| lifeless | wgrant: are you looking at the same url ? if so, sure | 00:01 |
|---|---|---|
| lifeless | spm: is OOPS-1698EA2488 mirrored yet ? | 00:02 |
| lifeless | or something wrong with lp-oops ? | 00:02 |
| lifeless | wgrant: 4.18 seconds, hitting it again. | 00:03 |
| lifeless | wgrant: so it -can- be fast; we may have caused disk io | 00:03 |
| mwhudson | working on blueprints presents interesting challenges | 01:17 |
| mwhudson | like not trying to fix absolutely everything | 01:17 |
| wgrant | Delete delete delete. | 01:18 |
| mwhudson | i mean really | 01:40 |
| wgrant | Hm? | 01:42 |
| mwhudson | oh sorry just venting | 02:00 |
| mwhudson | and some silly code | 02:00 |
| thumper | mwhudson: I feel your pain | 02:13 |
| thumper | been there | 02:13 |
| lifeless | mwhudson: have you looked at the query counts for blueprints | 02:23 |
| mwhudson | lifeless: no, but given the naivety of the code i've just been looking at, i imagine they might be crazy | 02:52 |
| mwhudson | thumper: you around ? | 02:59 |
| thumper | kinda | 02:59 |
| mwhudson | thumper: can i call you at some point? | 03:03 |
| mwhudson | no massive hurry | 03:03 |
| thumper | sure, I'll ping you | 03:03 |
| mwhudson | cool | 03:03 |
| mwhudson | i think i'm going to end up with another preparatory branch | 03:04 |
| mwhudson | first was: move code i want to change | 03:04 |
| mwhudson | second looks like being: de-stupid code i want to change | 03:04 |
| mwhudson | OMG | 03:06 |
| mwhudson | ls lib/lp/blueprints/stories/blueprints | 03:06 |
| mwhudson | sequential page tests! | 03:06 |
| lifeless | mwhudson: almost certainly | 03:08 |
| gary_poster | eek: I haven't used make lint in a while, and I just ran it on a branch. it seemed to have linted just about every file in the tree. That wasn't particularly useful. ./bin/lint.sh doesn't seem to point to any glaring mistake I made either :-/ | 03:09 |
| mwhudson | gary_poster: if there are no changed files (bzr st) it should do a diff against the parent (bzr info) i think? | 03:10 |
| lifeless | gary_poster: did you have any uncommitted files ? | 03:10 |
| lifeless | if not - what mwhudson said | 03:10 |
| gary_poster | no uncommitted files | 03:10 |
| lifeless | gary_poster: while you're here | 03:10 |
| lifeless | gary_poster: did you see the thread on lp dev about scripts and participations ? | 03:11 |
| mwhudson | gary_poster: bzr st -r parent: ? | 03:11 |
| gary_poster | bzr: ERROR: Requested revision: u'parent:' does not exist in branch: BzrBranch7('file:///home/gary/launchpad/lp-branches/devel/') | 03:11 |
| mwhudson | heh, that just blew up for me | 03:11 |
| lifeless | if you didn't, mwhudson and I would appreciate your thoughts | 03:11 |
| gary_poster | parent branch: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ | 03:11 |
| lifeless | mwhudson: :parent I think | 03:11 |
| mwhudson | lifeless: oh right, that's what blew up | 03:12 |
| gary_poster | crashed for me | 03:12 |
| mwhudson | i just said the wrong thing to gary | 03:12 |
| gary_poster | lifeless: I saw it fly by but did not look closely; will look | 03:12 |
| mwhudson | "ReadOnlyError: A write attempt was made in a read only transaction on LockableFiles" | 03:12 |
| gary_poster | yeah, same here | 03:12 |
| lifeless | mwhudson: personally, I'd do 'bzr st -r ancestor:..' | 03:12 |
| lifeless | where ... is (for me) ../devel | 03:13 |
| mwhudson | lifeless: ah yeah, probably better | 03:13 |
| gary_poster | bzr st -r ancestor:../devel/ gives me the kind of list I expected make lint to use | 03:14 |
| === Ursinha-afk is now known as Ursinha | ||
| * gary_poster will try make lint again for amusement sake | 03:14 | |
| gary_poster | eek, no | 03:15 |
| * gary_poster googles "bzr set parent branch" | 03:16 | |
| mwhudson | gary_poster: maybe you should just fix all the lint in the tree! | 03:18 |
| gary_poster | thanks a lot mwhudson :-) | 03:18 |
| gary_poster | OK, so I think this is the problem: | 03:19 |
| gary_poster | parent branch: bzr+ssh://bazaar.launchpad.net/~mars/launchpad/lsprof-on-demand/ | 03:19 |
| gary_poster | I want it to be my local devel (or a remote devel, whatever) | 03:19 |
| mwhudson | ah yes | 03:19 |
| mwhudson | i think bzr pull --remember will set parent | 03:20 |
| gary_poster | I tried bzr merge --remember ../devel/ | 03:20 |
| mwhudson | although of course bzr pull won't actually work | 03:20 |
| mwhudson | gary_poster: vim .bzr/branch/branch.conf is probably as easy as anything :/ | 03:20 |
| gary_poster | ok :-/ if it works that would be good though :-) | 03:21 |
| mwhudson | i don't know if the --remember config setting happens before or after the 'pull' part | 03:23 |
| gary_poster | all fixed, thank you | 03:23 |
| mwhudson | aararargh | 03:25 |
| mwhudson | if (ISpecification.providedBy(self.context) and | 03:25 |
| mwhudson | specurl == getattr(self.context, 'specurl')): | 03:25 |
| mwhudson | # The specurl wasn't changed | 03:25 |
| mwhudson | return | 03:25 |
| mwhudson | why getattr there? | 03:26 |
| gary_poster | lifeless: I have to go, but you were talking about the email thread from this week titled "performance tuesday - transparency," right? | 03:37 |
| mwhudson | gary_poster: yes | 03:58 |
| gary_poster | ok, will read and reply tomorry | 03:58 |
| thumper | mwhudson: it is just there to make you tear your hair out | 04:20 |
| thumper | mwhudson: shall I get a coffee before our call? | 04:20 |
| mwhudson | thumper: a cunning plan | 04:20 |
| mwhudson | thumper: yeah, i've become distracted by the craptitude of this code, i need to remember what i wanted to talk to you about :-) | 04:21 |
| thumper | :) | 04:21 |
| mwhudson | i want to cry | 04:24 |
| * spm hands mwhudson a box of kleenex | 04:25 | |
| spm | synmpathy from a losa only goes so far..... | 04:26 |
| wgrant | How long is it since Blueprint was maintained? 3ish years? | 04:28 |
| ajmitch | possibly because it drives people mad? | 04:38 |
| mwhudson | it's a bit of a chicken and egg problem there | 04:40 |
| mwhudson | i'm making a small corner of it better at least | 04:40 |
| jtv | wgrant—hi! Say, how is BuildFarmJob coupled to a Job or BuildQueue? Is there any chance that the state of a BuildFarmJob fell out of sync with that of the Job? | 04:41 |
| jtv | We've got a bunch of TranslationTemplateBuildJobs that were starved out of the build farm as far as we can tell, but now the build farm is mostly idle again and those jobs aren't being picked up. | 04:42 |
| wgrant | jtv: Yes, there are a few ways they can become inconsistent. | 04:42 |
| wgrant | Although less for translations jobs. | 04:42 |
| wgrant | let's see... | 04:42 |
| wgrant | jtv: The i386 virt queue is still 500 items and 11 hours deep. | 04:43 |
| wgrant | That's not what I'd call idle. | 04:43 |
| jtv | ah | 04:43 |
| jtv | so many i386 builders idle… all nonvirtual? | 04:43 |
| wgrant | Yes. | 04:43 |
| jtv | oic | 04:43 |
| wgrant | There used to be just three, but as of yesterday there are five. | 04:44 |
| wgrant | I'm not sure where all the virt builders have been for the last week. | 04:44 |
| jtv | so that ought to help a little | 04:44 |
| wgrant | How? | 04:44 |
| wgrant | Translations jobs build on virt builders. | 04:44 |
| wgrant | So the extra non-virt ones just slow down buildd-manager for you :) | 04:44 |
| jtv | Oh, the extra ones are non-virtual. I misunderstood that. | 04:45 |
| wgrant | There are normally 15 or so i386 virt builders. | 04:46 |
| wgrant | Now there are 6. | 04:46 |
| jtv | that'd explain a few things… | 04:46 |
| jtv | wgrant: I don't see anything that would associate a BuildFarmJob with a Job or BuildQueue. How does it connect to things? | 04:47 |
| wgrant | jtv: Ha ha ha. | 04:48 |
| wgrant | jtv: Well. | 04:48 |
| wgrant | jtv: http://people.ubuntu.com/~wgrant/launchpad/buildfarm/current-build-model.png | 04:48 |
| wgrant | That's how it roughly is at the moment. | 04:49 |
| wgrant | Except that it's been partially converted to http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png | 04:49 |
| wgrant | But the link tables (BuildPackageJob, SourcePackageRecipeBuildJob) are still in place. | 04:49 |
| jtv | (That's a relief, because I didn't see any BuildFarmJob at all in the former) | 04:49 |
| jtv | (I still say the arrows look the wrong way around to me) | 04:50 |
| wgrant | The parts of the new model that have so far been adopted are the merging and splitting of BinaryPackageBuild and SourcePackageRecipeBuild into BuildFarmJob, PackageBuild, BinaryPackageBuild, and SourcePackageRecipeBuild. | 04:51 |
| wgrant | Yes, shutup :P | 04:51 |
| wgrant | Everything else hangs on the translations jobs being ported to sit on top of BFJ. | 04:51 |
| wgrant | BuildPackageJob and other link tables need to remain in place until we have you off the old infrastructure. | 04:51 |
| * jtv is disappointed to see that shaking his head doesn't clear the cobwebs | 04:53 | |
| wgrant | Hmm? | 04:54 |
| jtv | It's just dizzying. | 04:54 |
| jtv | Being somewhere inbetween these two schemata. | 04:55 |
| wgrant | Yes :( | 04:55 |
| jtv | With the arrows—sorry, but it's really not helping!—all pointing the other way. | 04:55 |
| jtv | wgrant: also, I _still_ don't see how the translation template build jobs are linked to buildfarmjobs. | 04:59 |
| wgrant | jtv: Even in the second diagram? | 04:59 |
| wgrant | A TranslationsTemplateBuild has a BuildFarmJob and a Branch. | 04:59 |
| jtv | wgrant: I mean in the current schema—there being no TranslationTemplatesBuild table. | 04:59 |
| wgrant | Ah. | 04:59 |
| wgrant | In the current model, they're not linked to a BuildFarmJob. | 05:00 |
| jtv | The link to BuildFarmJob has to remain memory-only, which ISTM is getting more and more tenuous. | 05:00 |
| wgrant | There's just a TranslationTemplatesBuildJob (BranchJob) linked to a Job linked to a BuildQueue. | 05:01 |
| wgrant | You're different from the others, since you don't have a permanent object. | 05:01 |
| jtv | So does the absence of a buildfarmjob currently matter? | 05:04 |
| wgrant | Only in that it prevents us from radically simplifying the mess. | 05:05 |
| jtv | So it's not likely that we've got jobs stuck forever just because of this, but all the more urgent that we update our part of the schema. | 05:07 |
| wgrant | Right. | 05:07 |
| wgrant | I don't think you have stuck jobs. | 05:07 |
| wgrant | I think they're just at the end of the queue. | 05:07 |
| jtv | Almost certainly, if it's true that the farm is currently swamped by PPA jobs coming in mostly at a score of 2505. Until the cherrypick that spm deployed for us just now, our jobs went in at 1000. | 05:09 |
| wgrant | jtv: You can see at https://launchpad.net/builders that the queue is large. | 05:10 |
| jtv | wgrant: quite | 05:11 |
| jtv | It's just hard to get an impression of more subtle aspects such as "what's the queue like for the group of builders that can handle our jobs?" | 05:11 |
| jtv | Whoops, did my local launchpad repository just break? | 05:26 |
| jtv | Can't pull any of the LP branches now. | 05:26 |
| jtv | No such file or directory: u'/home/jtv/canonical/lp-branches/.bzr/repository/indices/f16f01b514931e8ff2433001ed359d47.rix' | 05:26 |
| jtv | lifeless: what do I do about a broken repo? | 05:27 |
| thumper | bzr check? | 05:27 |
| * jtv tries | 05:28 | |
| jtv | That's busily checking away | 05:28 |
| mwhudson | argl | 05:28 |
| jtv | mwhudson: try argv—it's called a vector, not a list for some reason | 05:28 |
| jtv | ECONTEXT | 05:28 |
| mwhudson | oh, ./bin/ec2 is slightly broken | 05:30 |
| jtv | argh | 05:32 |
| thumper | really? | 05:33 |
| thumper | hmm | 05:33 |
| thumper | I still use utilities/ec2 :) | 05:33 |
| mwhudson | well | 05:34 |
| mwhudson | that's just a symlink | 05:34 |
| mwhudson | it only matters if you have "debug_flags = hpss" in your config, i think | 05:34 |
| mwhudson | https://bugs.edge.launchpad.net/launchpad-foundations/+bug/624434 | 05:34 |
| _mup_ | Bug #624434: ec2 needs to initialize bzrlib <Launchpad Foundations:New> <https://launchpad.net/bugs/624434> | 05:34 |
| mwhudson | about 50% of the time needed to fix this bug is waiting for "make build" :( | 05:35 |
| wgrant | mwhudson: make compile isn't enough? | 05:37 |
| thumper | :) | 05:37 |
| wgrant | It skips the WADL and related crap. | 05:37 |
| wgrant | So it doesn't take five minutes. | 05:37 |
| mwhudson | yeah, that probably would have been ok here | 05:37 |
| thumper | the WADL generation is being moved out of make build | 05:37 |
| thumper | and WADL will be checked into the tree | 05:38 |
| thumper | see gary for details :) | 05:38 |
| mwhudson | that'd be nice | 05:39 |
| wgrant | Um, what happens if it changes? | 05:41 |
| lifeless | jtv: depends on the breakage | 05:45 |
| lifeless | jtv: #bzr is a good place to ask | 05:45 |
| jtv | lifeless: thanks. "bzr check" has been recommended to me, and I'm running that now. | 05:46 |
| mwhudson | jtv: do you have other files called /home/jtv/canonical/lp-branches/.bzr/repository/indices/f16f01b514931e8ff2433001ed359d47.* ? | 05:47 |
| mwhudson | or well /home/jtv/canonical/lp-branches/.bzr/repository/*/f16f01b514931e8ff2433001ed359d47.* | 05:47 |
| jtv | obsolete_packs/f16f01b514931e8ff2433001ed359d47.cix | 05:48 |
| jtv | obsolete_packs/f16f01b514931e8ff2433001ed359d47.iix | 05:48 |
| jtv | obsolete_packs/f16f01b514931e8ff2433001ed359d47.pack | 05:48 |
| jtv | obsolete_packs/f16f01b514931e8ff2433001ed359d47.rix | 05:48 |
| jtv | obsolete_packs/f16f01b514931e8ff2433001ed359d47.six | 05:48 |
| jtv | obsolete_packs/f16f01b514931e8ff2433001ed359d47.tix | 05:48 |
| jtv | that's it | 05:48 |
| mwhudson | mmm | 05:48 |
| mwhudson | looks like pack-names didn't get updated properly? | 05:48 |
| jtv | does it? | 05:49 |
| mwhudson | maybe | 05:49 |
| * jtv is devoid of clue | 05:49 | |
| mwhudson | lifeless would know more than me | 05:49 |
| mwhudson | jtv: bzr stores all data in packs, named after some checksum of the contents | 05:49 |
| mwhudson | jtv: the pack-names file lists which pack files are curreent | 05:50 |
| mwhudson | jtv: repacking coalesces pack files, so removes some | 05:50 |
| mwhudson | so one way you could get in this situation is if packs were combined, the old ones moved to obsolete_packs and then the update of pack-names file didn't succeed for some reason | 05:51 |
| mwhudson | but i don't know the order things happen in off the top of my head | 05:51 |
| mwhudson | in fact i would guess the pack-names update would be done _before_ obsoleting the packs | 05:51 |
| jtv | I think this happened while I was pulling several branches at the same time. Maybe a race condition? | 05:51 |
| jtv | let me also try if my fs is still writeable; it corrupts itself sometimes | 05:52 |
| jtv | yup, still writable | 05:52 |
| lifeless | a missing index | 05:54 |
| lifeless | means your fs failed to complete a write | 05:54 |
| jtv | so a previous instance of fs corruption is the most likely cause… odd though that it started failing in the middle of a bunch of pulls though. | 05:56 |
| lifeless | we only do IO as required | 05:59 |
| lifeless | so we don't check that every index is there every time | 05:59 |
| lifeless | so, a pack-name update that wasn't flushed looks plausible | 06:00 |
| lifeless | you could see if there is a tmp file with a newer date | 06:00 |
| lifeless | and if so, (in a copy of the repo, of course) | 06:00 |
| lifeless | try putting it in place | 06:00 |
| jtv | lifeless: where would I find that? And shouldn't I wait for "bzr check" to complete first? | 06:04 |
| lifeless | check doesn't handle this sort of problem | 06:10 |
| lifeless | .bzr/repository | 06:10 |
| lifeless | and - seriously - hop into #bzr | 06:10 |
| lifeless | grab - probably spiv right now | 06:11 |
| * mwhudson eods | 06:27 | |
| === almaisan-away is now known as al-maisan | ||
| wgrant | jtv: Looks like your build score changes worked. | 08:39 |
| jtv | wgrant: are we building one? | 08:39 |
| wgrant | jtv: Yeah. | 08:39 |
| wgrant | https://edge.launchpad.net/builders/rhenium | 08:39 |
| jtv | yup, see it! | 08:39 |
| jtv | Thanks for the heads up | 08:40 |
| wgrant | However, the i386 queue is looking pretty sad. | 08:41 |
| wgrant | I wonder if lamont rolled out the new lp-buildd this morning. | 08:41 |
| wgrant | Then we can easily reassign some amd64 builders to i386... | 08:42 |
| adeuring | good morning | 08:43 |
| jtv | hi adeuring | 08:45 |
| adeuring | hi jtv! | 08:45 |
| noodles775 | allenap: will you be landing your alternative property cache branch soon? It looks great (tests will be much nicer to read :) ). | 09:00 |
| noodles775 | actually, just saw that there is canonical.cachedproperty.is_cached too. | 09:06 |
| mrevell | Hello | 09:15 |
| wgrant | bigjools: Yes, db-devel merges into devel have really bad revnos :( | 09:33 |
| jtv | mrevell: just dumping a branch on you may have been a little rough yesterday… would you prefer a series of HTML snapshots? Won't show the full interaction, but will show the different forms the message can take. | 10:48 |
| mrevell | jtv, No a branch is fine, I'm just in the middle of transcribing a particularly difficult to understand interview. I'll have that finished this morning and will get to the translations help this afternoon, thanks. | 10:50 |
| danilos | mrevell, particularly hard-to-understand? I don't remember talking to you! | 10:50 |
| mrevell | danilos, heh | 10:50 |
| jtv | mrevell: thanks—looking forward to it! | 10:50 |
| jtv | (ignore the danilo) | 10:50 |
| danilos | mrevell, who deals with commercial emails on feedback@lp? | 10:50 |
| mrevell | danilos, me | 10:53 |
| danilos | mrevell, there's one from 17th that I haven't seen a response to | 10:54 |
| danilos | mrevell, and another one 5 days ago | 10:54 |
| mrevell | Anything that old will definitely have been dealt with. | 10:56 |
| noodles775 | wgrant: Thankyou for removing BuildBase :) | 10:59 |
| jtv | Q: do we have anything that actually runs the tests in lib/canonical/launchpad/windmill/jstests/launchpad_ajax.js ? | 11:00 |
| wgrant | noodles775: Still need to move the last couple of things from the interface file. | 11:00 |
| wgrant | noodles775: I'll move BuildStatus to BuildFarmJob, but I'm not sure where to put BUILDD_MANAGER_LOG_NAME. | 11:00 |
| noodles775 | wgrant: I'm assuming BuildStatus should go to lp.buildmaster.enums? | 11:01 |
| wgrant | noodles775: I guess it could. | 11:01 |
| wgrant | if anybody other than Code is doing that now, which it seems is the case now. | 11:01 |
| noodles775 | Yep. | 11:01 |
| wgrant | bigjools: Where should lp.buildmaster.interfaces.buildbase.BUILDD_MANAGER_LOG_NAME go? | 11:02 |
| wgrant | I think it should probably not be BUILDD_MANAGER_*, since that's an implementation detail. | 11:02 |
| bigjools | wgrant: ummm, I wonder if it's worth making lp.buildmaster.constants | 11:13 |
| bigjools | or it could go in enums | 11:14 |
| noodles775 | Why does it even exist? It's used in two places and represents a logging config name... | 11:16 |
| wgrant | slave-scanner is still hardcoded in several places. | 11:17 |
| wgrant | It should be used more widely, or we should pass loggers around more aggressively. | 11:17 |
| jelmer | wgrant, my branch makes us do that | 11:17 |
| wgrant | Or we could just resolve to hardcode it more heavily. | 11:17 |
| wgrant | jelmer: Ah! | 11:17 |
| jelmer | (pass loggers around more aggressively) | 11:17 |
| wgrant | Excellent. | 11:17 |
| wgrant | jelmer: Is BUILDD_MANAGER_LOG_NAME still used anywhere? | 11:18 |
| wgrant | jelmer: Is this your Popen removal branch? | 11:19 |
| jelmer | wgrant: yeah | 11:19 |
| * noodles775 would prefer to see the module names used with getLogger (ie. getLogger('lp.buildmaster.manager') and the logging configs updated to do the right thing - where possible) | 11:19 | |
| jelmer | wgrant: IIRC BUILDD_MANAGER_LOG_NAME is still used once or twice. | 11:19 |
| wgrant | noodles775: But I don't think that's entirely correct, since it's not necessarily buildd-manager that's calling things. | 11:19 |
| wgrant | noodles775: Although it will be the only caller, once we remove SlaveScanner. | 11:20 |
| wgrant | jelmer: :( | 11:20 |
| jelmer | wgrant, I'm sure we can fix that afterwards.. | 11:20 |
| wgrant | Yeah. | 11:21 |
| noodles775 | wgrant: I thought the reason for using the module name as a standard for getLogger was to indicate the context of the log message, not the call-site? | 11:22 |
| wgrant | noodles775: Ah, I just took your lp.buildmaster.manager example in the context of the calls I was thinking of, which are not in fact in buildd-manager itself. | 11:23 |
| wgrant | Never mind me. | 11:23 |
| jml | +1 for passing loggers around | 11:32 |
| noodles775 | jml: is that from experience, or is there an good article you'd recommend? From reading about pythons logging configuration options, I'd assumed part of their intention was to remove the need to pass loggers around? | 11:34 |
| jml | noodles775, experience | 11:34 |
| jml | noodles775, every time I think mutable global state is a good idea and actually try it, it turns out to be a bad idea | 11:35 |
| bigjools | last I heard, flacoste was not so keen on passing loggers around | 11:36 |
| wgrant | danilos: I question the fix suggestion in bug #522800. From what was it derived? | 11:38 |
| _mup_ | Bug #522800: Broken link in PPA package details page (404) <ppa> <QGIS:Invalid> <Soyuz:Triaged> <https://launchpad.net/bugs/522800> | 11:38 |
| jml | passing them around is easy to read, easy to write, easy to change and doesn't reduce functionality | 11:38 |
| wgrant | The problem is a bit less serious than that fix suggests. | 11:38 |
| bigjools | wgrant: I forgot what you said about it | 11:39 |
| jml | it also makes it _really_ obvious what needs a logger and what doesn't | 11:39 |
| wgrant | bigjools: The query returns the oldest LFA with the given name. | 11:39 |
| wgrant | bigjools: It should filter out expired ones. | 11:39 |
| bigjools | ah right | 11:39 |
| bigjools | would you mind updating the bug? I think you said you were going to do that :) | 11:40 |
| wgrant | There are unexpired ones there. I can see them through the librarian's search interface. | 11:40 |
| wgrant | Heh, possibly. Uni has been keeping me busy. | 11:40 |
| * wgrant updates the bug. | 11:40 | |
| bigjools | Uni didn't keep me busy | 11:40 |
| bigjools | well - not academically :) | 11:40 |
| wgrant | Heh. | 11:41 |
| wgrant | The team project is actually taking up time. The first subject to actually do so :( | 11:41 |
| danilos | wgrant, the fix suggestion came from bigjools, but I see you already resolved that :) | 11:42 |
| bigjools | I'll tell you a story about one of mine next time we meet up | 11:42 |
| wgrant | Heh. | 11:42 |
| bigjools | danilos: yeah I was wrong in my assumption :() | 11:42 |
| wgrant | See, this project has classically been done over a year. | 11:42 |
| wgrant | This is the first time they've crushed it into a semester. | 11:42 |
| danilos | wgrant, can you update the description or should I (while I have the bug open)? | 11:42 |
| wgrant | I'm not sure they've really thought it through. | 11:42 |
| wgrant | danilos: I'm doing it. | 11:43 |
| danilos | wgrant, cool, thanks | 11:43 |
| bigjools | geez, LP's test suite even brings my four-core to its knees. | 11:43 |
| jml | is it using more than one core? | 11:43 |
| noodles775 | jml: but to add a logging statement to a method that previously didn't log anything, you've got to update the method signature and (possibly) all call-sites, and potentially the signatures of the callsites which may not yet have the logger themselves? I'm not clear why you think it's good that the decision to log something in a method changes the method. | 11:43 |
| wgrant | bigjools: Need more SSD! | 11:43 |
| bigjools | jml: yes, but not in the way you think | 11:44 |
| bigjools | disk access is the killer | 11:44 |
| noodles775 | jml: but that scenario might just indicate badly-factored code anyway. | 11:44 |
| bigjools | and memory hogging | 11:44 |
| jml | noodles775, for the case where "log" is little more than a print statement, that's a fair point | 11:44 |
| bigjools | wgrant: I think I can soon start heating my office from the machines in here | 11:44 |
| jml | noodles775, but so often with Launchpad, logging is srs bsns | 11:44 |
| wgrant | bigjools: Have you acquired a new one to replace your previous quad-core? | 11:45 |
| jml | I dunno. I'm also going through a phase of making interfaces with methods that correspond to events I care about, and using that for logging. | 11:45 |
| bigjools | wgrant: nope I'm still happy with this one | 11:46 |
| bigjools | unless you count the pseudo 4-core in the i5 :) | 11:46 |
| StevenK | That's not a real quad-core | 11:46 |
| bigjools | jml: personally I agree with noodles775 here, changing method signatures to accommodate logging objects sounds quite evil | 11:47 |
| jml | indeed, "pseudo" could imply little else. | 11:47 |
| bigjools | yeah I was about to say ... | 11:47 |
| StevenK | Oh, bleh | 11:47 |
| * StevenK goes back to terrorizing dogfood | 11:47 | |
| * bigjools likes to call it a fork-whore in honour of the Two Ronnies | 11:47 | |
| StevenK | bigjools: The only thing I know from Two Ronnies is "and that's good night from 'im" :-( | 11:48 |
| jml | bigjools, I've more frequently encountered evil where I've had to mix code that each does it's own logging and neither bits of code have given me permission to touch their logging | 11:48 |
| jml | because it's acquired from a global rather than passed in. | 11:49 |
| jml | or refactoring a chunk of code that has log statements all over the place | 11:49 |
| jml | in any case, more often I pass logging objects into constructors | 11:49 |
| noodles775 | ah, that would help :) | 11:50 |
| bigjools | StevenK: http://www.youtube.com/watch?v=qu9MptWyCB8 | 11:50 |
| noodles775 | jml: but I wonder if the evil you've encountered is related to logging not being configured correctly in the first place? (/s/correctly/optimally) Not sure. | 11:52 |
| jml | noodles775, maybe. I can't recall enough detail. | 11:53 |
| jml | noodles775, things not being right in the first place is certainly a strong theme in the soundtrack of my programming career :) | 11:53 |
| noodles775 | jml: but being right in the end I'm sure too :) | 11:54 |
| jml | noodles775, software is never finished, it just runs out of funding | 11:54 |
| danilos | Ursinha, hi (when you are around), does this bug activity look like a problem with qa-tagging scripts? https://bugs.edge.launchpad.net/rosetta/+bug/618987 | 12:01 |
| _mup_ | Bug #618987: gc.get_objects() interacts badly with bzrlib lazy imports <qa-untestable> <tech-debt> <Launchpad Translations:In Progress by thumper> <https://launchpad.net/bugs/618987> | 12:01 |
| deryck | Morning, all. | 12:05 |
| jml | morning | 12:05 |
| === al-maisan is now known as almaisan-away | ||
| === matsubara-afk is now known as matsubara | ||
| === henninge_ is now known as henninge | ||
| allenap | noodles775: I tried to land it yesterday but there were some test failures. I'm away until Tuesday and I probably won't have enough time to fix it before then, sorry. I'll migrate any code that lands before then though. | 14:27 |
| noodles775 | allenap: np. Enjoy your break! | 14:27 |
| allenap | noodles775: Cheers :) | 14:29 |
| leonardr | salgado, i'm looking into the oauth token scope thing we talked about yesterday, but i'm remembering other problems with it. for instance, a web service client with a scoped oauth token can't get the service root | 14:33 |
| leonardr | because the service root is not in scope | 14:33 |
| leonardr | an oauth token is also scoped to a person, but the person will be out of scope | 14:33 |
| salgado | leonardr, when things are out of scope the client should have read access still, no? | 14:34 |
| leonardr | salgado: we'll find out. i don't know if i actually tested this | 14:34 |
| leonardr | so it could still work | 14:34 |
| salgado | maybe that's not how it works today, but I think that's how it should work | 14:34 |
| leonardr | that makes sense | 14:36 |
| leonardr | wgrant, we have a solution to the timeout problem i last talked with you about on july 20th | 14:43 |
| leonardr | i'm delegating to benji the responsibility for updating the script you're running on optusnet.com.au | 14:44 |
| leonardr | basically, you need to upgrade to the latest versions of launchpadlib and lazr.restfulclient | 14:44 |
| leonardr | you need to make your script use edge (until the changes are deployed in the next launchpad release) | 14:45 |
| leonardr | and if you were using the ._wadl_resource.total_size hack to get the length of a collection, you need to change that code to use len() | 14:45 |
| leonardr | gary -^ delegating to benji | 14:47 |
| gary_poster | ack thanks | 14:48 |
| leonardr | salgado, i see how the oauth context could be a specific project or distribution or whatever, but not how it could be a particular _class_ of object. do you have any ideas? | 14:53 |
| salgado | leonardr, indeed, the scope is a db object and not a python class. you could scope it to the person, but I guess that wouldn't help you in this case? | 14:56 |
| leonardr | scoping it to the person would be a good start | 14:56 |
| leonardr | or maybe not... since the person's oauth tokens are probably not considered to be in scope | 14:59 |
| === almaisan-away is now known as al-maisan | ||
| leonardr | i'll give it a try | 14:59 |
| deryck | wow, comment fonts are huge on my system now. | 14:59 |
| deryck | Feel like I'm reading a large print old-folks book. | 15:00 |
| benji | deryck: I just noticed the same thing; I like big text but that is taking it a bit far :) | 15:00 |
| deryck | benji, indeed :-) | 15:01 |
| deryck | It's falling back to monospace for me and at 116% | 15:01 |
| deryck | perhaps the percentage worked for whatever font we used to request. | 15:01 |
| benji | I'm not aware of a way to have different sizes for different type faces... but I'm no CSS expert either. | 15:03 |
| deryck | I don't seem to have a mono version of the ubuntu font either. | 15:06 |
| deryck | jml, hi. See my good-god-that's-a-huge font comments above. ^^ | 15:08 |
| deryck | jml, should I file a bug on launchpad-web? | 15:08 |
| jml | deryck, huh what, yes. | 15:08 |
| deryck | heh | 15:08 |
| jml | deryck, there's no Ubuntu monospace yet. | 15:08 |
| jml | soon, I'm told. | 15:08 |
| deryck | ok, I didn't think so. | 15:09 |
| deryck | jml, should we just scale back the percentage on the monospace then, since we know we're only using that currently? | 15:09 |
| jml | deryck, sorry, otp, that sounds reasonable | 15:11 |
| deryck | jml, np. Sorry to interrupt. I'll work up a branch now and see how it looks. | 15:11 |
| jml | deryck, np | 15:11 |
| jml | deryck, a bug with screenshots would help the reviewer. | 15:11 |
| deryck | jml, ack | 15:12 |
| jml | deryck, beuno, fwiw, they don't look huge to me. | 15:26 |
| jml | oh, 'comment fonts' | 15:27 |
| beuno | jml, right | 15:27 |
| beuno | and merge proposal diffs | 15:27 |
| jml | no, same as ever. | 15:27 |
| deryck | beuno, they do look huge to you? | 15:27 |
| beuno | deryck, yes, huge | 15:27 |
| beuno | I'll take a screenshot | 15:27 |
| deryck | beuno, yeah, they look huge to me, and benji confirmed. But just making sure. | 15:28 |
| deryck | jml, they don't look huge to you? | 15:28 |
| deryck | I've add my own screenshot at bug 624666 | 15:28 |
| _mup_ | Bug #624666: Monospace fonts too large after adding Ubuntu font to font-family declaration <launchpad-web:Triaged by deryck> <https://launchpad.net/bugs/624666> | 15:28 |
| benji | do my fonts look big in this? | 15:28 |
| deryck | benji, I just meant you said comment fonts looked large to you too. | 15:28 |
| benji | that was a (failed) joke, a la "does my butt look big in this" | 15:29 |
| deryck | I assumed this happened with the font change, bzr blame says sinzui changed the 116% rule for comments. | 15:29 |
| deryck | benji, :-) Ah. | 15:29 |
| sinzui | I landed the branch | 15:30 |
| deryck | ah | 15:30 |
| jml | benji, I chuckled. | 15:30 |
| benji | at least I'm not a total failure | 15:30 |
| adeuring | gary_poster: could you help me get a clue why the tests in lines 155, 165 from this diff https://pastebin.canonical.com/36336/ are failing? And why the test in line 145 is _not_ failing (it should, because I commented out lines 59,60)? Or: How should I set up test for ProxiedLFA.(http|api)_url for webservice requests? | 15:30 |
| deryck | I just thought benji's fonts looked fine | 15:30 |
| benji | deryck: that's what you always say | 15:31 |
| deryck | sinzui, you have no objections then to me changing the 116% to get a sane look | 15:31 |
| deryck | heh | 15:31 |
| sinzui | go ahead | 15:31 |
| gary_poster | adeuring: looking | 15:31 |
| sinzui | deryck, I do not see a size change in the diff | 15:32 |
| beuno | deryck, jml, FWIW: http://ubuntuone.com/p/Dwt/ | 15:32 |
| beuno | sinzui, ^ | 15:33 |
| adeuring | gary_poster: https://pastebin.canonical.com/36340 has the test failures | 15:33 |
| sinzui | deryck, the 116% has been there a long time. I think the font is just different | 15:33 |
| gary_poster | ack | 15:33 |
| adeuring | so, the host name is wrong, and 'api/devel' is missing in the URL | 15:33 |
| deryck | sinzui, ok, that's what I thought. But the rule used to just be "monospace" if the diff is to be believed. Since there's no ubuntu monospace, we should still be using that. | 15:34 |
| deryck | but at any rate, a percentage change will not harm us, I think. Until we have the real font. | 15:34 |
| deryck | 116% seems too large to me anyway. | 15:35 |
| jml | beuno, it's kind of meaningless without a "before" screenshot. | 15:36 |
| beuno | jml, really? the huge-ass difference isn't meaningful? | 15:36 |
| deryck | jml, the fonts don't look large to you? | 15:36 |
| sinzui | deryck, You could have the real font, or the beta font, or you could choose to keep Monospace (system font--either dejavu or Bitstream depending on the ago) | 15:36 |
| beuno | I'll take a screenshot of production | 15:36 |
| leonardr | salgado, i've shelved the scope thing for now. i think it might work, if we hack the 'container' code (about which i know nothing) or hack the code that uses the container code so that the service root and top-level collections are always considered to be in scope | 15:36 |
| beuno | I think jml is doing drugs again | 15:37 |
| leonardr | i have another problem, which i hope you or benji can help with | 15:37 |
| jml | deryck, beuno: they look obviously configured differently to what I have. | 15:37 |
| deryck | jml, do you have the ubuntu mono font? | 15:37 |
| deryck | installed, I mean | 15:37 |
| beuno | jml, but look at the difference in size between the diff and everything else | 15:37 |
| leonardr | i thought i had traversal set up correctly, and indeed i can access /~salgado/+oauth_access_tokens/token-name with GET | 15:37 |
| beuno | I do not have the ubuntu font, tw | 15:37 |
| jml | deryck, no. | 15:37 |
| deryck | jml, ok. Can you use an inspector and see that the rules for the fonts are for you? | 15:38 |
| leonardr | but when i PATCH that same URL, i get a 404. it looks like launchpad is trying to find token-name directly under ~salgado and ignoring the +step_into that tells it (should tell it?) to look up an access token | 15:38 |
| leonardr | does this problem seem familiar? | 15:38 |
| jml | deryck, I use Courier for monospace in my browser, for example | 15:38 |
| deryck | ah | 15:38 |
| jml | beuno, irrelevant. that stuff is totally browser configurable. | 15:38 |
| sinzui | deryck, I switched the Ubuntu fonts the day of the announcement, and I set a custom CSS in my browsers so that I always saw the fonts...bold was very ugly for a few weeks | 15:38 |
| beuno | jml, so what are you saying? | 15:39 |
| deryck | So I would think the size rule should be sane for the default, and if people are configuring fonts in the browser, they can adjust accordingly there. | 15:39 |
| jml | beuno, that to file a useful bug about font changes being bad, you need to have before & after screenshots | 15:39 |
| deryck | would jml, sinzui, beuno agree? ^^ | 15:39 |
| beuno | jml, deryck, sinzui, here's a screenshot of production: http://ubuntuone.com/p/Dx1/ | 15:39 |
| gary_poster | adeuring: here's one thing. setUpApiInteraction correctly sets up the request, *but not the publication* or the virtual host bits. So that *might* be important for your test. However, my suspicion is that your test is actually showing a real problem either wat. If it is a web interaction *or*an api interaction, api url should be stable, I would think, yes? | 15:39 |
| beuno | deryck, sure, I have not changed any default | 15:40 |
| adeuring | gary_poster: yes | 15:40 |
| beuno | jml, there, before and after. Go nuts. | 15:40 |
| jml | deryck, agreed. | 15:40 |
| adeuring | gary_poster: I mean, the URLs should be the same | 15:40 |
| jml | beuno, Already gone. | 15:40 |
| gary_poster | adeuring: right. So whether or not setUpApiInteraction is sufficient seems irrelevant | 15:40 |
| adeuring | gary_poster: erm, probably ;) | 15:41 |
| deryck | beuno, can you attach those as before/after shots on Bug #624666? | 15:41 |
| _mup_ | Bug #624666: Monospace fonts too large after adding Ubuntu font to font-family declaration <launchpad-web:Triaged by deryck> <https://launchpad.net/bugs/624666> | 15:41 |
| beuno | deryck, sure | 15:41 |
| gary_poster | aseuring, how you calculate api_url is relevant, of course. I'm not sure what a proper way of doing that would be. What are you trying? | 15:41 |
| deryck | thansk! | 15:41 |
| deryck | "s" took over for both gary_poster and I there. | 15:42 |
| adeuring | gary_poster: Basically, I copied the approach for http_url which enforces non-api URLs | 15:42 |
| gary_poster | lol, true deryck | 15:42 |
| Ursinha | StevenK, hi, can I mark bug 449408 as qa-ok? | 15:43 |
| _mup_ | Bug #449408: Need scriptactivity monitoring of "gina" <boobytrap> <canonical-losa-lp> <gina> <qa-needstesting> <Soyuz:Fix Committed by stevenk> <https://launchpad.net/bugs/449408> | 15:43 |
| gary_poster | adeuring: Unless you really want me to look at that code, I'm going to run away, since we appear to have agreed that the test itself is not (exactly) at fault. ;-) I'm late for a call. Do you want me to ping you later? | 15:43 |
| adeuring | gerthat would be great | 15:44 |
| gary_poster | ok cool | 15:44 |
| bigjools | Ursinha: he's in bed but he did already QA it | 15:44 |
| Ursinha | ah, cool | 15:44 |
| Ursinha | thanks bigjools | 15:44 |
| beuno | sinzui, the only difference I see is in the font-family (font-family:"UbuntuBeta Mono","Ubuntu Mono",monospace;) | 15:44 |
| beuno | production doesn't have the first 2 | 15:44 |
| sinzui | beuno, yes. I think the font has different metrics than dejavu/vera | 15:45 |
| bigjools | Ursinha: the qa bot is removing ok/untestable tags which is really annoying :( | 15:46 |
| Ursinha | bigjools, it removes the tags if you place them before it being available to qa... | 15:48 |
| bigjools | Ursinha: that's bogus, we might have already tested it on dogfood | 15:49 |
| Ursinha | bigjools, if you commit a fix with incremental or no-qa tag, it won't replace untestable tags | 15:49 |
| bigjools | ah | 15:49 |
| Ursinha | bigjools, I recall having this discussion with you two months ago :) | 15:49 |
| bigjools | yes | 15:49 |
| rockstar | Ursinha, maybe your bot can check for the tags that it shouldn't be replacing. | 15:50 |
| rockstar | I think adding more noise to the commit message is sub-optimal. | 15:50 |
| Ursinha | rockstar, I think suboptimal is leaving things untested behind :) | 15:50 |
| Ursinha | rockstar, point is script should replace. if you have something qa-ok, and you land another branch related to the same bug, you need to qa that | 15:51 |
| Ursinha | so script replaces | 15:51 |
| rockstar | Ursinha, it should add, not replace, methinks. | 15:51 |
| Ursinha | if that doesn't need qa or is a partial fix, there are two clauses to express that | 15:51 |
| Ursinha | rockstar, two qa tags in a bug is confusing | 15:52 |
| Ursinha | specially considering the new mergeworkflow lifeless planned | 15:52 |
| rockstar | Ursinha, I don't think it's all that confusing. As long as it shows up in the qa-untestable list, it's served its purpose, right? | 15:53 |
| gary_poster | rockstar, we're talking about scripts that have to parse these tags and interpret them according to agreed-upon rules. | 15:53 |
| Ursinha | what gary_poster said | 15:54 |
| gary_poster | Certainly we can change those scripts, but then we need to agree on the rules again. | 15:54 |
| jml | when I get back from hols, I'm going to start trying to get down some requirements from you guys re QA | 15:55 |
| jml | (OEM, Platform & others want something built-in to LP) | 15:56 |
| gary_poster | And arguably this is an example of an impedance mismatch between using tags, a rather imprecise tool by intent, to control QA, which is supposed to be much more precise and controllable. | 15:56 |
| leonardr | salgado, fun fact: my lp_save() on the oauth token seems to have *dissociated it from the user*, which is why i'm getting that 404 | 15:56 |
| gary_poster | Yeah, that would potentially address the impedance mismatch, jml. | 15:56 |
| jml | *nod* | 15:56 |
| jml | there's also an issue building tools that work with an informally managed staging environment (i.e. dogfood) | 15:58 |
| gary_poster | yeah. a one-size-fits-all qa feature, or even a one-size-fits-many, will be tough. Our roll-our-own-locally qa integration has its advantages. | 16:02 |
| deryck | jml or abentley, I'm playing local dev server with MPs. How do I generate the diff locally? | 16:05 |
| jml | deryck, no idea, sorry. | 16:05 |
| deryck | np, thanks anyway. | 16:05 |
| leonardr | salgado: ARGH. the access token was disappearing because i was setting its expiration date to a date in the past | 16:06 |
| salgado | leonardr, heh. but does it work when you set a date in the future? | 16:10 |
| salgado | I mean, can you change it? | 16:10 |
| leonardr | finding that out now | 16:10 |
| leonardr | we need to change lazr.restful (or possibly the client) to understand what happens when setting a field value causes the object to disappear | 16:10 |
| leonardr | salgado: yes, i can change the expiration date to a date in the future. (however, i have given up hope for the time being of making GRANT_PERMISSIONS anything more than an all-powerful access level, so it's not too surprising) | 16:13 |
| deryck | This YUI cssfont stuff is confusing to me. | 16:15 |
| deryck | sinzui, there are places where our rules to use the ubuntu font work, but others where yui's rules have precedence. I don't understand why. | 16:16 |
| sinzui | really. I think all font-family's were changed | 16:17 |
| deryck | sinzui, YUI has the arial,helvetica, blahblahblah line that wins out for some items. | 16:17 |
| sinzui | deryck, But at what level? I think our rules supersede them | 16:18 |
| sinzui | deryck, can you show me a page that is using YUI's font rules? | 16:19 |
| deryck | sinzui, I would have thought so, too. That's why I'm confused. | 16:19 |
| deryck | sure, digging for link | 16:19 |
| sinzui | I have never seen arial in any launchpad page that I inspect. I do that a lot. I recall we had a nasty bug hunt in YUI to ensure it's widget rules (like the calendar) never surfaced | 16:20 |
| sinzui | oh, rockstar updated our YUI rules last month. I wonder if our older version was directly hacked. | 16:20 |
| rockstar | sinzui, what YUI rules? I haven't landed the newest YUI yet (I need to squeeze more into lazr-js first) | 16:21 |
| deryck | ok, so I think I got the problem wrong. | 16:21 |
| sinzui | rockstar, good to know | 16:21 |
| deryck | it's not that the YUI rule has precedence. It's that *no* rule applies. See comments on any MP, for example. What font is that? | 16:22 |
| deryck | sinzui, ^^ | 16:22 |
| rockstar | sinzui, I'll send an announcement when I do it. | 16:22 |
| * sinzui looks with inspector | 16:22 | |
| deryck | rockstar, hi. How do I generate diffs in a local dev server for MPs? | 16:23 |
| rockstar | deryck, there's a script called create_merge_proposals I think. | 16:25 |
| deryck | rockstar, cool, thanks. Was searching for scripts with "diff" in the name :-) | 16:25 |
| sinzui | deryck, you may be looking too close to the text. merges... | 16:25 |
| sinzui | deryck, pre defines monospace in YUI, but I see our rule is ignored | 16:26 |
| rockstar | deryck, LPCONFIG=development bin/py cronscripts/merge-proposal-jobs.py | 16:26 |
| * sinzui looks at source | 16:27 | |
| deryck | sinzui, what I'm trying to work out is why this patch fixes comments having the large font for bugs and leaves MP comments unchanged? http://pastebin.ubuntu.com/484011/ And playing with the inspector, if I delete all font rules on MPs the font is unchanged. | 16:27 |
| jcsackett | can someone help me understand an odd comment/if statement in the validate method of lp.bugs.browser.bugtask.BugTaskEditView? | 16:28 |
| jcsackett | method is here, with comment asking for clarification: https://pastebin.canonical.com/36347/ | 16:28 |
| deryck | jcsackett, I can likely help. looking.... | 16:28 |
| jcsackett | thanks, deryck. | 16:29 |
| sinzui | deryck, since our pre matched YUI's pre, we did not define a font rule. Ours does not match, so we want to define one now | 16:29 |
| sinzui | deryck, you must put the ubuntu fonts back | 16:30 |
| sinzui | the UX team have a hammer and they hit everyone who disobeyed them last year when they defined font rules | 16:31 |
| deryck | sinzui, right. I want the Ubuntu fonts. :-) I'm trying to understand why changing the rule has the affect it does. | 16:31 |
| deryck | the patch is not what I'm proposing as a fix. Merely as a reference to get to a real fix. | 16:32 |
| sinzui | deryck, we need to add fonts to "pre, code, samp, tt, .console {" | 16:32 |
| sinzui | and I think we want to change the font-size from 116%; to 108% or 100% | 16:33 |
| deryck | sinzui, ok, that makes sense. And this is going to change the look of bugs and MP comments. And we don't currently use the monospace font there, so I assume make it the same Ubuntu choice in html, body? | 16:34 |
| deryck | i.e. UbuntuBeta, Ubuntu, 'Bitstream Vera Sans', 'DejaVu Sans', Tahoma, sans-serif | 16:34 |
| sinzui | ?? | 16:35 |
| deryck | sinzui, what I mean is comments don't currently use a monospace font, right? on lpnet. | 16:36 |
| sinzui | deryck, I think you are saying that we did not set font-family because YUI was providing what we wanted "Monospace". | 16:36 |
| deryck | no, sorry | 16:36 |
| sinzui | deryck, I think we are changing scope here, but you will close a lot of bugs if all comments were made monospace | 16:36 |
| sinzui | UbuntuBeta Monospace, Ubuntu Monospace, Monospace | 16:37 |
| deryck | yeah, I'm not sure if I want to go that route yet, only because there doesn't seem to be agreement about that. | 16:37 |
| deryck | but I could just JFDI | 16:37 |
| deryck | ;) | 16:37 |
| === salgado is now known as salgado-lunch | ||
| deryck | jcsackett, sorry for delay. Doing too much at once here. So old_product and new_product reference just products. "pillar" is a wrapper method that gets at the target regardless of being a product or a distribution. | 16:38 |
| sinzui | deryck, lets get the font size right, and define the the expected monospace fonts on "pre, code, samp, tt, .console" | 16:38 |
| jcsackett | deryck: okay, so in that instance, though we're working with products predominantly, the target isn't necessarily old_ or new_ product? | 16:39 |
| deryck | sinzui, agreed. Working that up now, testing locally to see fall out. | 16:39 |
| deryck | jcsackett, I read the comment below the if check to suggest the check against pillar there is to make sure we don't somehow have a distro task. | 16:40 |
| jcsackett | deryck: okay, thanks. | 16:40 |
| deryck | I'm not sure how we would, but evidently it happened once :-) | 16:40 |
| jml | deryck, the 'if old_product is None' is surely about not being a distro task | 16:46 |
| jml | s/not// | 16:46 |
| jml | scratch that correction. | 16:46 |
| deryck | jml, right. If old_product == None this would be a distro. | 16:48 |
| deryck | re-thinking the question about doing new_product.official_malone | 16:48 |
| jml | I guess you can't change the bugtask of a product that doesn't use Launchpad because the remote tracker won't detect it? | 16:49 |
| jml | or something? | 16:49 |
| deryck | jml, right. You create a watch if it doesn't use malone. But the question jcsackett has is why not new_product.official_malone. | 16:53 |
| deryck | jcsackett, I'm rethinking this. | 16:53 |
| jml | deryck, why not instead or why not in addition to | 16:53 |
| deryck | sorry, why not right it as new_product.official_malone instead. Why do we need to check on the pillar, rather than the new_product. | 16:54 |
| jcsackett | deryck, that was sort of my confusion. | 16:55 |
| deryck | jcsackett, jml -- so doing it on the pillar prevents having to spell it (new_product is not None and new_product.official_malone) | 16:55 |
| deryck | maybe, that's it? I'm not entirely sure. Were it me, I would change it and run bugtask tests and see what fails. | 16:56 |
| jml | lemme check again | 16:56 |
| jml | deryck, has the new_product been set on the bugtask at the time of the if statement? | 16:57 |
| deryck | I'm jumping on a standup now, so an as exercise in "hey remember when we ..." I'll ask if anyone knows :-) | 16:57 |
| jcsackett | deryck: sounds good. :-) | 16:57 |
| deryck | jml, this is a validate method. So you could submit the form without supplying new_product and it would be None. | 16:57 |
| jml | deryck, that's what I mean, bugtask.pillar will be old_product (or a distro), not new_product | 16:57 |
| deryck | right | 16:58 |
| deryck | so it really seems wrong | 16:58 |
| jml | deryck, unless there's a reason for preventing changing bugtasks that are on products that don't use malone officially | 16:58 |
| deryck | ah | 16:58 |
| deryck | yes | 16:58 |
| deryck | so we don't want to move a bugwatch off | 16:58 |
| deryck | or move a task that is for a watch | 16:59 |
| * deryck is on call now | 17:00 | |
| jml | not actually on topic, but I'm reminded of how much look-before-you-leap sucks | 17:04 |
| jml | mrevell, wb | 17:08 |
| mrevell | thanks jml ... power cut ... country living, etc | 17:09 |
| mrevell | bac, every 15 mins, I believe | 17:09 |
| === beuno is now known as beuno-lunch | ||
| cody-somerville | when did the text for bug change history get so big? | 17:33 |
| maxb | losa ping: The branch on which lp:~launchpad-pqm/bzr-builder/trunk is stacked has been renamed, and the bzr-level stacking pointer is now wrong. | 17:35 |
| maxb | Please could you download this script: http://j.maxb.eu/~maxb/bzr-set-stacked-url.py - and run bzr-set-stacked-url.py lp:~launchpad-pqm/bzr-builder/trunk lp:bzr-builder | 17:35 |
| === Ursinha is now known as Ursinha-lunch | ||
| Chex | maxb: let me take a look at that for you | 17:36 |
| maxb | thanks | 17:36 |
| === deryck is now known as deryck[lunch] | ||
| jml | :( | 17:44 |
| jml | cody-somerville, today. | 17:47 |
| === benji is now known as benji-lunch | ||
| Chex | maxb: get a failure when I try to run it: https://pastebin.canonical.com/36352/ | 17:49 |
| maxb | Chex: I can't see pastebin.canonical.com | 17:50 |
| Chex | maxb: sorry about that. | 17:50 |
| Chex | http://pastebin.ubuntu.com/484045/ try that | 17:52 |
| Chex | maxb: ^ | 17:52 |
| maxb | oh, I see. First run 'bzr launchpad-login your-lp-id' so bzr knows how to connect via bzr+ssh | 17:53 |
| jml | abentley, a bunch of changes on the recipe LEP | 17:54 |
| mthaddon | maxb: erm, is there really no better way of doing this? | 17:55 |
| mthaddon | maxb: I'm not very happy about download a random script off the internet and having an admin run it | 17:55 |
| maxb | Well, you could hack the .bzr/branch.conf directly if you like | 17:56 |
| maxb | er, .bzr/branch/branch.conf | 17:56 |
| mthaddon | maxb: there's no way to do this in the web UI? | 17:56 |
| maxb | no | 17:56 |
| mthaddon | maxb: if not, it seems to me like there should be a bug report about it rather than trying to work around it | 17:57 |
| mthaddon | (or at the very least, a bug report and trying to work around it) | 17:57 |
| maxb | The fundamental problem is that when a branch changes name, Launchpad doesn't update the bzr-level metadata in stacked branches to say so. | 17:58 |
| maxb | I believe someone mentioned they were actually working on fixing that next cycle | 17:58 |
| mthaddon | sounds very much like the basis of a bug report to me | 17:58 |
| mthaddon | :) | 17:58 |
| maxb | I'm assuming that if someone's already decided to work on it next cycle, there's already a bug filed | 17:59 |
| mthaddon | maybe, but we really should have asked you for that info before going ahead and doing it :) | 17:59 |
| maxb | bug 377519 | 18:00 |
| _mup_ | Bug #377519: Stacked on location breaks if the stacked upon branch is renamed <branch-stacking> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/377519> | 18:00 |
| maxb | mthaddon/Chex: It doesn't seem to have changed yet, did you want me to describe fixing it by editing files rather than using the script? | 18:08 |
| === beuno-lunch is now known as beuno | ||
| === salgado-lunch is now known as salgado | ||
| === matsubara is now known as matsubara-lunch | ||
| jml | I'm off. Have a great time folks. | 18:14 |
| === Ursinha-lunch is now known as Ursinha | ||
| maxb | mthaddon? Chex ? | 18:22 |
| Chex | maxb: hi there | 18:24 |
| Chex | maxb: yes it may make more sense for you to describe the files we need to look at | 18:25 |
| maxb | OK then, please edit the file lp:~launchpad-pqm/bzr-builder/trunk/.bzr/branch/branch.conf (either directly or over sftp) such that the stacked_on_location line now reads: stacked_on_location = /~bzr-builder-devs/bzr-builder/trunk | 18:27 |
| === benji-lunch is now known as benji | ||
| === al-maisan is now known as almaisan-away | ||
| === deryck[lunch] is now known as deryck | ||
| Chex | maxb: sorry, looking around now | 18:55 |
| adeuring | gary_poster: ping | 18:57 |
| gary_poster | adeuring: didn't forget, call day | 18:57 |
| adeuring | gary_poster: ah, ok | 18:58 |
| maxb | Chex: Hi, I'm semi-afk for ~15 minutes, then ircing from a phone only for the rest of the evening. I will read anything you say here, but my responses might be delayed/limited | 19:05 |
| Chex | maxb: thats fine, we have a process/script to handle this issue, apparently | 19:08 |
| Chex | running it now, just slow going | 19:08 |
| === almaisan-away is now known as al-maisan | ||
| Chex | maxb: all set, should be fixed now. in the future, remind us admins of this equest by asking for the 'LP process to Fixing Broken branches' | 19:21 |
| Chex | request, that is | 19:21 |
| maxb | thanks Chex, with any luck lo will get fixed properly soonish to not create this issue | 19:22 |
| maxb | s/lo/lp/ | 19:23 |
| Chex | maxb: agreed. your welcome | 19:23 |
| === matsubara-lunch is now known as matsubara | ||
| === al-maisan is now known as almaisan-away | ||
| lifeless | morning | 19:41 |
| lifeless | Ursinha: I think ther emay be room to permit not-replacing, but it will need careful thought about race conditions | 19:42 |
| Ursinha | lifeless, I agree with that | 19:42 |
| lifeless | mthaddon: if you're around, I would love to touch base, however briefly, on the staging-with-prod-schema progess. | 19:44 |
| lifeless | and I ashamed to say, its entirely a 'are we there yet' question. | 19:44 |
| Ursinha | lifeless, I have to reply your bug comment about tags | 19:44 |
| lifeless | gary_poster: so, private librarian | 19:44 |
| lifeless | gary_poster: have you seen the wildcard-dns proposal ? | 19:45 |
| gary_poster | on calls today lifeless--but it doesn't ring a bell unless it was the branch stub was looking at with you a few weeks ago | 19:47 |
| lifeless | yeah that one | 19:47 |
| lifeless | I'm thinking of picking it up | 19:47 |
| lifeless | librarian is consistently very high up there | 19:47 |
| gary_poster | ah, yes. It looked like a great idea to me | 19:47 |
| lifeless | ok cool | 19:47 |
| gary_poster | lifeless, btw, have been concerned lately thinking about edge/production on same machines/processes: it gives us arguably a bit less safety in trying out big infrastructure changes--say, trying a broad change to the template implementation. Now, if edge service degrades significantly, there is an escape hatch. edge will no longer be an easy way to do that. | 19:54 |
| gary_poster | I don't think this is a necessarily huge deal, but I do suspect that it will drive us into some new patterns. One is for us to be able to easily upgrade a single load balanced machine with certain code changes and evaluate its performance. If that's relatively easy and lightweight for devs and LOSAs, that might work. | 19:54 |
| gary_poster | And it might be a better story than what we have now, for the end users. | 19:54 |
| lifeless | from what I know of the deployment process, that should be straight forward | 19:55 |
| lifeless | we'd qa the the change so we're happy with performance on staging | 19:55 |
| lifeless | which btw, implies we want a load test harness | 19:55 |
| lifeless | then, when we're happy, we can rollout the icing, and some N appservers, and monitor them, | 19:55 |
| lifeless | gary_poster: I think it will be a better story than we have today, once we get the db schema changes more agile | 19:57 |
| lifeless | in the interim I think it should be no worse. | 19:57 |
| gary_poster | sounds reasonable. load test harness: ack and agreed. | 19:58 |
| lifeless | I understand that SSO was tested with such a thing; I don't know if its scalable in terms of request pattern complexity to LP | 19:58 |
| lifeless | it might be nice to just take a days worth of logs | 19:59 |
| lifeless | or a week | 19:59 |
| lifeless | and toss the exact same pattern at a staging env; with something special to handle POSTs | 19:59 |
| gary_poster | yeah; POSTs/webservice is the trick, I think | 20:01 |
| lifeless | one thing we could do is ask for volunteers; use a featureflag to enable it and capture their posts | 20:01 |
| lifeless | would only work if we had a point-in-time recovery for the to-be-tested environment rather than 'current data' recoveryt | 20:02 |
| lifeless | anyhow, EFUTUREWORK | 20:02 |
| gary_poster | lifeless: exactly what I was going to say about point-in-time and POSTs, agreed. and yes EFUTUREWORK. | 20:22 |
| lifeless | gary_poster: great minds | 20:22 |
| gary_poster | ;-) | 20:22 |
| gary_poster | adeuring: if you are still around I have about about 12 min | 20:22 |
| adeuring | gary_poster: great! | 20:23 |
| gary_poster | where should I look? | 20:23 |
| adeuring | gary_poster: https://pastebin.canonical.com/36336/ and https://pastebin.canonical.com/36336/ | 20:23 |
| gary_poster | right thanks | 20:23 |
| adeuring | https://pastebin.canonical.com/36340/ | 20:23 |
| gary_poster | ok... | 20:24 |
| adeuring | gary_poster: I also tried setupInteraction() but only got even more weird results | 20:24 |
| gary_poster | heh | 20:24 |
| gary_poster | adeuring: ok, I think I see your strategy now. You want getURL to come up with the right URL on the basis of the request passed in. I am afraid it needs to be more sophisticated...or canonical_url needs to be more sophisticated :-/ . Lemme go look at that implementation again. | 20:26 |
| adeuring | gary_poster: ok | 20:26 |
| gary_poster | adeuring: I think you need to explicitly pass in the right rootsite to canonical_url. Seeing if I can learn more... | 20:30 |
| adeuring | gary_poster: that's what I tried, via setupinteraction() -- seems that I messed thatup ;) | 20:31 |
| deryck | bryceh, Just fyi.... without reviewing too closely, I think your model/db changes are on track. | 20:41 |
| bdmurray | I'm having issues running make build on devel No local packages or download links found for zc.buildout==1.5.0 | 20:42 |
| bdmurray | and Link to http://pypi.python.org/simple/zc.buildout/ ***BLOCKED*** by --allow-hosts | 20:42 |
| bdmurray | How can I sort this out? | 20:42 |
| deryck | I thought we had out own zc.buildout. You shouldn't have to hit pypi. | 20:44 |
| bryceh | deryck, ok | 20:44 |
| deryck | bdmurray, the first "no package" error I've seen before, and fixed by various combinations of updating source deps, make clean, make. | 20:45 |
| gary_poster | bdmurray: make sure your download-cache is up-to-date | 20:45 |
| gary_poster | ``cd download-cache && bzr up`` in the common case | 20:46 |
| gary_poster | leonardr: I am trying to look at an issue for adeuring. He is trying to generate API urls for objects. AFAICT, canonical_url doesn't have sufficient smarts for this--in particular, it does not insert a webservice version into urls. It also has no way of guessing what version of the webservice should be used if you are not already coming in on a webservice request. | 21:00 |
| gary_poster | Do you know if there is a pattern for this already? http_url in lib/canonical/launchpad/browser/librarian.py returns the current request's url, AIUI, right adeuring? He would like to generate a url for a librarian file proxy even if the current request is not a webservice request, right adeuring? adeuring, do you want a specific policy as to what version should be returned, or would you want a function to retu | 21:00 |
| gary_poster | versions, or...? | 21:00 |
| gary_poster | sorry, he would like to generate a *webservice* url for a librarian file proxy... | 21:01 |
| lifeless | does that really make sense ? | 21:01 |
| lifeless | I mean, isn't the proxy an implementation detail; we havce the LFA separately | 21:01 |
| gary_poster | only if there's a use case :-) | 21:01 |
| adeuring | gary_poster: well, the code works fine when you access launchpad.dev via launchpadlib. My main issue is the test... | 21:02 |
| lifeless | and the LFA can and should be on the API; but the proxy itself, really that should just be the launchpadlibrarian.net URL | 21:02 |
| leonardr | gary: you can convert a website request into a webservice request, and i think when you do you can specify a version (or it will use the latest version) | 21:02 |
| lifeless | we *do not want* to serve librarian contenxt via the API | 21:02 |
| lifeless | adeuring: ^ | 21:02 |
| lifeless | adeuring: what is your use case | 21:02 |
| gary_poster | leonardr: ah, that makes sense, thanks | 21:03 |
| adeuring | lifeless: the usecase is access to ProxiedLFAs via launchpadlib. The is a bug about it, just a second... | 21:03 |
| gary_poster | lifeless, adeuring, I'm getting out of the way :-) I was just trying to help | 21:03 |
| lifeless | gary_poster: you're not in the way at all :) | 21:03 |
| adeuring | lifeless: bug 620458 | 21:03 |
| _mup_ | Bug #620458: cannot access attachments of private bugs any more <httplib2:Unknown> <Launchpad Bugs:Triaged by adeuring> <https://launchpad.net/bugs/620458> | 21:03 |
| lifeless | gary_poster: I'm just leaping on the meta issue | 21:03 |
| gary_poster | heh, but I want to consider myself in the way so I can go do other things ;-) | 21:04 |
| lifeless | gary_poster: fair enough ;) | 21:04 |
| leonardr | gary: specifically, you can cast a request to IWebServiceClientRequest--but i don't know what is the launchpad adapter | 21:04 |
| adeuring | leonardr: the adapter works fine -- testing this is a problem for me... | 21:05 |
| lifeless | adeuring: ok, I see | 21:05 |
| lifeless | uhm | 21:05 |
| lifeless | I'd really rather just finish fixing the private librarian to emit correct public urls | 21:05 |
| lifeless | adeuring: I can almost guarantee that this API will hard timeout a huge amount | 21:05 |
| lifeless | the apport retracer runs in the DC | 21:05 |
| adeuring | lifeless: sure... | 21:05 |
| lifeless | can we not just give it the restricted librarian URL for now ? | 21:05 |
| adeuring | lifeless: hrm.... what about other people who ant to acces private librarian files via launchpadlib? | 21:06 |
| adeuring | s/ant/want/ | 21:06 |
| gary_poster | sinzui: ping | 21:07 |
| lifeless | adeuring: what about them ? :) | 21:07 |
| lifeless | adeuring: if they are in the DC, its easy. | 21:07 |
| sinzui | hi gary_poster | 21:08 |
| lifeless | adeuring: if they are not, then we'll *increase* the chance of timeouts and simply not be serving them well | 21:08 |
| lifeless | adeuring: we'll also, because the librarian client has bugs, run a real risk of DOSing the entire appserver cluster. | 21:08 |
| gary_poster | hi sinzui! the linter doesn't like a line in schema-lazr.conf because it is too long | 21:08 |
| gary_poster | is this alright? | 21:08 |
| gary_poster | -cookie_domains: demo.launchpad.net, staging.launchpad.net, launchpad.net, launchpad.dev | 21:08 |
| gary_poster | +cookie_domains: demo.launchpad.net, | 21:08 |
| gary_poster | + staging.launchpad.net, | 21:08 |
| gary_poster | + launchpad.net, | 21:08 |
| gary_poster | + launchpad.dev | 21:08 |
| gary_poster | things still work | 21:08 |
| gary_poster | tests pass and such | 21:09 |
| gary_poster | but you are keeper of those keys | 21:09 |
| lifeless | adeuring: I have a branch that is about 40% done, which will expose the restricted librarian publically | 21:09 |
| lifeless | adeuring: using an access token. | 21:09 |
| lifeless | adeuring: when that is done, the API can be used to get an access token for such a file. | 21:09 |
| lifeless | adeuring: the basic mechanism will be: | 21:10 |
| lifeless | - LFA can hand out a token on request | 21:10 |
| adeuring | lifeless: I remebr you idea | 21:10 |
| sinzui | gary_poster, yes that works because indentation implies continuation, *and* the callsite is splitting on whitespace | 21:10 |
| lifeless | - the token goes into a short lived store | 21:10 |
| lifeless | - the user gets https://contenthash.restricted.launchpadlibrarian.net/name?token=XXX | 21:10 |
| lifeless | adeuring: cool | 21:10 |
| sinzui | gary_poster, that fix is okay, but I would not assume that always works. I think we should tell lint to not check for long lines in conf files | 21:11 |
| gary_poster | sinzui: ok. Should I not make that change then, do you think? I have one other question for you: a mini review of a CSS change. let me put a pastebin up one sec | 21:11 |
| sinzui | gary_poster, I can make the pocket-lint change. | 21:12 |
| adeuring | lifeless: so, you think we should for now simply return the restricted librarian URL in the property api_url in this diff: https://pastebin.canonical.com/36336/ ? | 21:12 |
| sinzui | I can review the CSS | 21:12 |
| adeuring | (SORRY, ITS A BIT LATE FOR ME) | 21:12 |
| gary_poster | sinzui: ok thank you, I will revrt the line changes to the conf file then. Here's the CSS. http://pastebin.ubuntu.com/484149/ | 21:12 |
| * adeuring cant turn off caps lokćk,,. | 21:12 | |
| gary_poster | (it is a bit late for you, after all :-) ) | 21:13 |
| gary_poster | sinzui: this is CSS for developer-only profiling bits | 21:13 |
| gary_poster | by biggest question is where it should go in the file, though of course you may have other concerns | 21:13 |
| sinzui | gary_poster, is profiling_info used by more than one page? | 21:13 |
| gary_poster | sinzui: potentially by every page in LP | 21:14 |
| gary_poster | it will be used when someone puts a ++profile++ in the URL | 21:14 |
| lifeless | adeuring: I think that that would work. I am really very concerned (maybe I shouldn't be) about the risk of very long requests on the appserver farm | 21:14 |
| lifeless | adeuring: alternatively | 21:15 |
| lifeless | adeuring: you could flip the bit back to how it was before your change, to let apport work ? | 21:15 |
| adeuring | lifeless: erm, then we would have againa public attachment in prvate bugs, right? | 21:16 |
| lifeless | adeuring: yes, but we tolerated that for 5 years or so | 21:16 |
| sinzui | gary_poster, hide_reveal_profiling implies it is a link because it is underlined but it is red. we use blue or green else where | 21:16 |
| gary_poster | sinzui, ok fair enough. (this is developer-only, but consistency is nice) | 21:17 |
| adeuring | lifeless: yes, but frankly, i would feel quite uncomoftable when we "opened" the attachments again | 21:17 |
| adeuring | let's try the restritced librarian URL | 21:17 |
| sinzui | gary_poster, yes, the point of pointing something in the global css is consistency :) | 21:18 |
| gary_poster | :-) true | 21:18 |
| sinzui | gary r=me with the colour change. Thank you very much for structuring the rules so clearly | 21:18 |
| gary_poster | thank you sinzui! | 21:18 |
| lifeless | adeuring: it will need an RT ticket to open firewall access, but that should be quite trivial | 21:25 |
| adeuring | lifeless: OK; let's discuss this tomorrow (or in the evening your time) -- it's too late for me now ;) | 21:25 |
| thumper | aah... nice coffee smoothing the pain of morning | 21:45 |
| cr3 | thumper: I noticed I was getting older when it started taking more coffees to smooth the pain | 21:46 |
| thumper | cr3: :) | 21:47 |
| mwhudson | morning | 21:53 |
| mwhudson | i don't think that's "older" i think that's just "too used to coffee" | 21:53 |
| mwhudson | go without for a month and it starts to have more of an effect again :-) | 21:53 |
| thumper | mwhudson: back on the coffee again? | 21:58 |
| mwhudson | thumper: somewhat | 21:58 |
| mwhudson | trying not to have more than 2 cups of coffee a day | 21:58 |
| thumper | I'm trying to limit myself to around 6 shots a day | 21:58 |
| thumper | normally taken 2 at a time | 21:59 |
| thumper | home espresso machines are good | 21:59 |
| * lifeless is detoxing | 22:00 | |
| lifeless | been *so tired* for the last two days | 22:00 |
| lifeless | thumper: good, evil, its a fine line | 22:00 |
| lifeless | thumper: you want a catch up? | 22:00 |
| mwhudson | oh man, the week where i first stopped drinking coffee about a year ago was horrid | 22:01 |
| thumper | lifeless: yes, I'll ping you later | 22:01 |
| mwhudson | lifeless: i'm not sure you should be hacking canonical.launchpad.webapp under these circumstances :-) | 22:02 |
| lifeless | mwhudson: indeed | 22:07 |
| === matsubara is now known as matsubara-afk | ||
| wgrant | added: lib/lp/archiveuploader/tests/test_securityuploads.py.THIS | 22:54 |
| wgrant | (from devel r11453) | 22:54 |
| wgrant | That seems like a mistake. | 22:54 |
| jelmer | wgrant: yep | 22:59 |
| jelmer | wgrant: also, hi :-) | 22:59 |
| mwhudson | whoops | 23:00 |
| wgrant | jelmer: Morning. | 23:00 |
| jelmer | thumper: I'd be interested in having a pre-implementation call about code import bug linking sometime. | 23:02 |
| jelmer | wgrant: Thanks for removing buildbase btw. It conflicted quite heavily with my builddmaster async branch, but it's great to finally see it gone. | 23:03 |
| wallyworld | morning | 23:04 |
| jelmer | hi wallyworld | 23:04 |
| jelmer | wallyworld: Welcome :-) | 23:04 |
| wallyworld | thanks :-) | 23:04 |
| thumper | hi | 23:07 |
| wallyworld | thumper: g'day | 23:07 |
| mwhudson | hi wallyworld | 23:08 |
| wallyworld | g'day mw | 23:09 |
| wgrant | Hi wallyworld. | 23:09 |
| thumper | wallyworld: see... already more interaction than yesterday | 23:09 |
| wallyworld | hi william | 23:10 |
| wallyworld | thumper: yes, indeed | 23:10 |
| wgrant | :( Distribution.getDevelopmentSeries doesn't return FROZEN series. | 23:10 |
| wgrant | So my scripts are broken :( | 23:10 |
| thumper | wgrant: really? | 23:10 |
| thumper | wgrant: I thought it would | 23:10 |
| wgrant | So did I. | 23:10 |
| lifeless | . | 23:32 |
| wgrant | Really? | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
