| jelmer | mwhudson: but it works \o/ | 00:27 |
|---|---|---|
| mwhudson | jelmer: yeah! | 00:29 |
| wgrant | You know, 2a fetch is pretty slow. | 00:51 |
| mwhudson | yes | 00:52 |
| wgrant | Well, a bit worse than that, actually. | 00:52 |
| mwhudson | heh | 00:55 |
| * mwhudson files a bug | 00:55 | |
| wgrant | About? | 00:56 |
| mwhudson | 2a fetch being slow | 00:56 |
| mwhudson | wgrant: https://bugs.edge.launchpad.net/bzr/+bug/562666 | 00:56 |
| mup | Bug #562666: 2a fetch is very cpu intensive <Bazaar:New> <https://launchpad.net/bugs/562666> | 00:56 |
| wgrant | mwhudson: I have a bzr.log for a checkout of that linux import, if you're interested... it took a little longer than I expected: 4 hours. | 00:56 |
| jelmer | mwhudson: have you profiled it? | 00:56 |
| mwhudson | jelmer: no | 00:57 |
| mwhudson | wgrant: sigh | 00:57 |
| mwhudson | wgrant: how big is the repo in the end? | 00:57 |
| wgrant | mwhudson: ~400MB, it looks like. | 00:57 |
| mwhudson | not bad | 00:57 |
| mwhudson | git is 312megs it seems | 00:57 |
| wgrant | .bzr in my shared repo is 383MB. | 00:58 |
| === Ursinha is now known as Ursinha-afk | ||
| mwhudson | wgrant: can you do repository/packs and repository/indices as well? | 00:58 |
| wgrant | I am tmepted to try a local branch, but then I might be waiting all day. | 00:58 |
| mwhudson | wgrant: it will probably take about an hour | 00:58 |
| wgrant | wgrant@magrathea:~/dev/linux/bzr$ du -sh .bzr/repository/packs | 00:58 |
| wgrant | 319M.bzr/repository/packs | 00:58 |
| wgrant | wgrant@magrathea:~/dev/linux/bzr$ du -sh .bzr/repository/indices/ | 00:58 |
| wgrant | 64M.bzr/repository/indices/ | 00:58 |
| mwhudson | wgrant: thanks | 00:58 |
| wgrant | mwhudson: Want bzr.log too? | 01:00 |
| wgrant | It was 'get_parent_map'ing until 2086s :/ | 01:00 |
| jelmer | the --lsprof output would be interesting | 01:00 |
| wgrant | THen fetched for 9000s. | 01:00 |
| jelmer | wgrant: that is a lot of time spent to figure out it had to fetch everything... | 01:01 |
| mwhudson | wgrant: did you fetch into the repo? | 01:02 |
| mwhudson | if you fetch into a new branch with no repo you can skip that part i expect | 01:02 |
| jelmer | mwhudson: it went straight to insert stream here | 01:02 |
| wgrant | mwhudson: I did, yeah. | 01:04 |
| wgrant | So I pay 2000 seconds because it retrieves the entire history map to check for anything I already have? | 01:04 |
| mwhudson | something like that | 01:04 |
| wgrant | Yay | 01:04 |
| wgrant | Still, at least in-branch operations are pretty fast. | 01:07 |
| jelmer | the smart server protocol should and could be a lot faster | 01:07 |
| jelmer | s/faster/smarter/ | 01:07 |
| wgrant | As mwhudson showed yesterday, a completely dumb fetch took it down from 70 minutes to 37 seconds. | 01:08 |
| poolie | mwhudson: hi | 01:13 |
| poolie | bzr info bzr+ssh://bazaar.launchpad.net/~gz/bzr/trivial_testskipped -Dhpps seems to hang on the server side | 01:14 |
| jelmer | wgrant: I guess it's partially a bandwidth usage/cpu usage/latency tradeoff | 01:14 |
| poolie | mwhudson: i don't suppose we can get a traceback of the production server process? | 01:16 |
| mwhudson | poolie: i expect so | 01:17 |
| mwhudson | spm: can you copy ~codehost/.bzr.log somewhere poolie and i can see it? | 01:17 |
| mwhudson | poolie: hm, it works for me | 01:17 |
| mwhudson | i guess i'm seeing the hosted area of the branch though | 01:18 |
| spm | mwhudson: sure, one sec | 01:18 |
| spm | mwhudson: poolie: chinstrip:~spm/bzr.log.save.gz | 01:20 |
| poolie | can we easily tar up a copy of the hosted disk directory for that branch? | 01:22 |
| poolie | and attach it to https://bugs.edge.launchpad.net/launchpad-code/+bug/562672 | 01:22 |
| mup | Bug #562672: info on broken? branch hangs on server side <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/562672> | 01:22 |
| mwhudson | poolie: spm can, i think | 01:26 |
| spm | mwhudson: /srv/bazaar.launchpad.net/push-branches/00/04/f5/1b/ ? | 01:29 |
| mwhudson | spm: yeah, and the mirror copy i guess | 01:33 |
| poolie | yes | 01:34 |
| spm | oki | 01:34 |
| spm | /srv/bazaar.launchpad.net/mirrors/00/04/f5/1b: No such file or directory | 01:35 |
| poolie | i think he deleted it | 01:35 |
| poolie | oh well | 01:35 |
| spm | ew. that's a 43Mb tgz. do you really want that attached to the bug? | 01:37 |
| spm | I ask as I'm not sure I'll be able to attach it without getting a timeout... | 01:37 |
| poolie | sure, why not? | 01:37 |
| poolie | erk | 01:37 |
| poolie | well, maybe put it on people.c.c. and attach the url? | 01:37 |
| spm | been down this path before | 01:37 |
| spm | sure | 01:37 |
| wgrant | mwhudson: My local branch has been going for 33 minutes, and has so far copied 99MB. | 01:39 |
| mwhudson | wgrant: speed demon | 01:39 |
| * mwhudson lunches | 01:43 | |
| spm | poolie: 15 min eta on that tarball landing on people.c.c.... 27% thru... | 01:44 |
| poolie | spm, from inside the dc? | 01:47 |
| poolie | or did you copy it down to canberra? | 01:47 |
| spm | poolie: messing around within the dc tends to be sufficently confusing; it's easier to pull locally. if it was 100Mb? yeah, I'd setlle for the hassle and do it right. | 01:49 |
| maxb | So here's a conundrum. Why would ~vcs-imports be granted launchpad.Admin on IProductSeries? | 02:03 |
| mwhudson | maxb: to be able to set the linked branch? | 02:06 |
| mwhudson | seems a bit overkill though | 02:06 |
| maxb | oh. that makes sense... in a sort of sledgehammerish way | 02:08 |
| mwhudson | sigh | 03:50 |
| mwhudson | when your changes don't seem to be taking effect: check that you're running the tests in the right branch | 03:51 |
| maxb | :-) | 03:51 |
| mwhudson | wgrant: did your clone of the kernel import complete in the end? | 04:38 |
| poolie | spm: how feasible is it for an appropriately authorized person to look at launchpad's http access logs | 05:42 |
| poolie | for the apps, not for bzr or other things | 05:42 |
| spm | poolie: easy I guess? in a technical sense. The hard part'd be the "authorised person" | 05:43 |
| poolie | who could do that? or who could ask for it to be done | 05:43 |
| spm | I have no idea.... I assume James is involved somewhere; but Francis'd be a good start. | 05:43 |
| poolie | this is re bug 537432 | 05:43 |
| mup | Bug #537432: Save Playlist button does not point to (existing) playlist file <amd64> <apport-bug> <totem (Ubuntu):New for desktop-bugs> <https://launchpad.net/bugs/537432> | 05:43 |
| wgrant | mwhudson: It did. | 05:44 |
| mwhudson | wgrant: did you see how long it took? | 05:44 |
| spm | poolie: ?? I'm not sure I follow the connection there? | 05:45 |
| wgrant | mwhudson: I ran it with --lsprof, so it doesn't really count. | 05:45 |
| wgrant | I am running it again now without it. | 05:45 |
| poolie | spm, that's cause there isn't one :) | 05:45 |
| poolie | bug 557432 is better | 05:46 |
| mup | Bug #557432: Hot Bugs algorithm works poorly for some projects, making it a bad default listing <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/557432> | 05:46 |
| poolie | just wanting to know what sort ordering people use most often | 05:46 |
| wgrant | mwhudson: But it took about 96 minutes. | 05:46 |
| wgrant | poolie: I'm guessing newest first. | 05:47 |
| spm | poolie: ahh. that'd help then. :-) | 05:47 |
| poolie | wgrant: i'm guessing most-recently-touched | 05:47 |
| poolie | but yeah | 05:47 |
| wgrant | Hm, true, or that. | 05:47 |
| wgrant | But probably not heat. | 05:47 |
| spm | poolie: ahh. i see. in that case, probably easiest if one of us runs the script directly; the logs are... um. not small. so moving the script to the logs would be a better idea. | 05:48 |
| spm | poolie: vaguely related - we did similar with loggerhead/codebrowse a while back. The additional point is that we ran a sanitizer from CERT over the logs; as well as some home grown filtering to strip other bits that were sensitive. So for future ref I guess. we could do similar. | 05:50 |
| poolie | i think in this case we'd just want the aggregate counts, so there should be nothing sensitive | 05:50 |
| spm | I agree | 05:50 |
| poolie | to write the script one would need to know the precise formats and ideally have a little sample | 05:51 |
| mwhudson | wgrant: oh | 05:51 |
| poolie | though it may just be whatever's in devel's apache config | 05:51 |
| mwhudson | wgrant: i hope you kept the output -- can you attach it to the bug? | 05:51 |
| wgrant | mwhudson: I have the lsprof output, yes. | 05:51 |
| * wgrant attaches. | 05:51 | |
| spm | given you're dealing with URL's and stock apache - the URL's can be obtained by pretty much anyone who understands what that bug report is talking about. (I don't - exactly jic you were wondering - get the gist, not the fine detail :-) ) | 05:52 |
| poolie | spm, my question was, what field of the log is the url | 05:54 |
| poolie | but i guess i can just assume 'it's the one that looks like a url' unless you're also logging referers or something :) | 05:54 |
| spm | heh; is before the referrer. ip - - date tz "type url (http ver)?" ... | 05:55 |
| spm | from memory.... | 05:55 |
| spm | generally is the 1st '"' field, sometimes the 2nd... /me goes to check. | 05:56 |
| spm | yup that looks right. I know some of our logs use an earlier '"' field. one to be wary of. | 05:58 |
| poolie | type being the http method, like GET? | 05:59 |
| poolie | and the url is absolute? | 05:59 |
| spm | 1.2.3.4 - - [13/Apr/2010:06:39:50 +0100] "GET /@@/footer-background.png HTTP/1.1" 200 404 ..... <== by way of example | 05:59 |
| spm | or: 1.2.3.4 bugs.launchpad.net - [13/Apr/2010:06:39:50 +0100] "GET /@@/edit HTTP/1.1" 200 5100 .... <== for otehr domains not specifically logged on their own | 06:00 |
| spm | url is always absolute, yes. | 06:00 |
| poolie | ah but it's only the path part, not including the hostname | 06:01 |
| poolie | ok | 06:01 |
| spm | right | 06:01 |
| * mwhudson spots awk lumbering over the horizon | 06:02 | |
| spm | i'd suggest 1 other part to look for - get a breakdown by Agent. it's not accurate, but *can* be instructive. if only to help identify noise to strip away. eg "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" | 06:02 |
| spm | mwhudson: heh; I'll just shove my logfiltering scripts at you guys and let you search'n'replace :-) | 06:03 |
| spm | mwhudson: poolie: ancient robot filter: https://pastebin.canonical.com/30558/ | 06:04 |
| spm | as in ancient script; not ancient robots. | 06:04 |
| wgrant | Can someone please land lp:~wgrant/launchpad/bug-344165-i-hate-buildd-sequencer? PQM rejected it while in testfix last night. | 06:05 |
| spm | wgrant: can you come up with a more.... descriptive branch name? :-P | 06:06 |
| poolie | spm: http://www.deviceguru.com/files/heath_he-robot.jpg | 06:06 |
| poolie | >> if ($6 !~ /bot([-./)(_s@ ]|$)| | 06:07 |
| poolie | heh | 06:07 |
| mwhudson | wow, that bug report is written in pure cprov :) | 06:07 |
| spm | poolie: I wrote that and still can't figure out what the regex means :-D | 06:08 |
| mwhudson | wgrant: so the branch passed ec2? | 06:08 |
| wgrant | mwhudson: Yes. | 06:09 |
| poolie | it's a steamroller threatening a wombat? | 06:09 |
| mwhudson | wgrant: sent to pqm | 06:10 |
| spm | okis. heading for some lunch and to let corbs run around and burn off school holidays energy. bbl. | 06:11 |
| wgrant | mwhudson: Thanks. | 06:11 |
| wgrant | spm: You're still in school holidays up there? | 06:11 |
| spm | just started end of last week | 06:11 |
| wgrant | Oh. Ours ended then. | 06:11 |
| spm | yes. well. we can't have all states on the eastern seaboard as a 1st step align on school holidays! that'd be too logical! <== come and see the cynicism on display! step right up! | 06:12 |
| mwhudson | mm | 06:13 |
| spm | anyways, me and my cynicism are bbl :-) | 06:13 |
| * mwhudson tries to remember how to turn statement logging back on in postgres... | 06:13 | |
| wgrant | mwhudson: /etc/postgresql/8.3/postgresql.conf | 06:13 |
| wgrant | log_statement='all' | 06:14 |
| mwhudson | wgrant: ta | 06:14 |
| mwhudson | hmmm | 06:18 |
| mwhudson | INSERT INTO Branch is blocking here | 06:18 |
| wgrant | Awesome. | 06:18 |
| mwhudson | stub: do you have any tips for seeing why a particular sql statement is hanging? | 06:21 |
| stub | Look at pg_stat_activity to see what else is runnin | 06:22 |
| stub | g | 06:22 |
| mwhudson | i think i found it | 06:22 |
| mwhudson | stub: all the other connections were <IDLE> | 06:23 |
| mwhudson | but i guess one of them had taken a lock | 06:23 |
| stub | If they were <IDLE>, they didn't have a lock. | 06:24 |
| stub | '<IDLE> in transaction' might | 06:24 |
| mwhudson | ah yeah, one was <IDLE> in transaction | 06:24 |
| lifeless | mwhudson: is there an LP API call where i can pass in a url and it gives me the branch-if-any ? | 07:09 |
| lifeless | mwhudson: I might have an http url, or a bzr+ssh one | 07:10 |
| lifeless | thumper: ^ wgrant: ^ | 07:20 |
| lifeless | it might be a mirrored branch too | 07:20 |
| === dpm-afk is now known as dpm | ||
| adeuring | good morning | 08:14 |
| mwhudson | lifeless: there's something like that at the python api level i think, getByURL ? | 08:36 |
| mwhudson | don't know if it's exported | 08:37 |
| lifeless | mwhudson: could you peek for me? | 08:37 |
| mwhudson | lifeless: https://edge.launchpad.net/+apidoc/devel.html <- it is exported | 08:37 |
| lifeless | mwhudson: thanks! | 08:41 |
| lifeless | whats the 'right' service root to use at the moment ? | 08:56 |
| james_w | lifeless: LPNET_SERVICE_ROOT, version='1.0' for stability or EDGE_SERVICE_ROOT, version='devel' for tracking changes I would say | 09:00 |
| lifeless | james_w: so you need to pass two parameters these days ? | 09:32 |
| lifeless | james_w: the code examples on the wiki are stale then | 09:32 |
| james_w | lifeless: you don't have to, version has a default | 09:35 |
| lifeless | ok | 09:39 |
| lifeless | what is it ? | 09:40 |
| james_w | lifeless: depends on the version of launchpadlib | 09:52 |
| james_w | 1.0 currently I believe | 09:52 |
| lifeless | mthaddon: ping | 10:17 |
| lifeless | mthaddon: spm: http://paste.ubuntu.com/414192/ - I'd like to know if thats clear enough docs on setting up LP API keys for pqm | 10:19 |
| wgrant | Interesting. | 10:30 |
| wgrant | With Python 2.5, TALES obeys SourcePackageName's __unicode__. | 10:31 |
| wgrant | With Python 2.6, we instead get '<security proxied blah blah blah>' | 10:31 |
| lifeless | is that with an exception or regular object? | 10:40 |
| lifeless | there were some changes in that area | 10:40 |
| wgrant | lifeless: Regular object. | 10:40 |
| wgrant | bigjools: Isn't the explanation in bug #562451 incorrect? | 10:40 |
| mup | Bug #562451: developer-membership-board should be able to edit ArchivePermissionSet <packagesets> <Soyuz:Triaged> <https://launchpad.net/bugs/562451> | 10:40 |
| wgrant | AFAICT, the TB can edit it because they are in ~ubuntu-drivers, which owns the primary archive, so they can do just about anything (which is pretty broken). | 10:41 |
| wgrant | The only methods restricted to launchpad.Edit on ArchivePermissionSet are packageset-related, which is also pretty broken, but not the main problem here. | 10:41 |
| bigjools | wgrant: yeah I was going to comment on that - the code is still wrong, but for other reasons | 10:43 |
| bigjools | I mean "wrong" for philosophical reasons | 10:43 |
| wgrant | AFAICT, it should all work if newPackagesetUploader and deletePackagesetUpload are moved to the <allow /> block, and the DMB added to ~ubuntu-drivers... but I really don't think most of the members of ~ubuntu-drivers should have the privs they do now... | 10:44 |
| bigjools | yes - see the team description | 10:46 |
| wgrant | In fact, their current permissions seem to somewhere between rather stupid and horrifyling dangerous. | 10:46 |
| wgrant | I am leaning towards the latter. | 10:46 |
| wgrant | Yes... but that has been there for a number of years. | 10:46 |
| wgrant | lifeless: No other ideas? | 10:54 |
| maxb | Oh gah, I'm sure I remember investigating __unicode__ vs. __str__ issues last python migration push, but I've forgotten the details :-( | 10:55 |
| wgrant | The easy fix is to alter the expression to take /name, like all but two places in the code already do. | 10:56 |
| wgrant | I am tempting to take that path. | 10:56 |
| wgrant | Er, tempted. | 10:56 |
| deryck | Morning, all. | 11:00 |
| lifeless | wgrant: ? | 11:07 |
| lifeless | wgrant: oh right, -_unicode_- | 11:07 |
| lifeless | I think using explicit accessors is clearer | 11:08 |
| lifeless | I could look at CPython if you're stuck | 11:08 |
| wgrant | Certainly. I'm just a bit suspicious that something deeper has broken that I might be about to hide. | 11:08 |
| * wgrant will trust the tests and just add /name. | 11:08 | |
| lifeless | I wonder if launchpad-code will blowup if i attach 40 MB comments to it ? | 11:23 |
| intellectronica | lifeless: don't know about launchpad-code, but in malone we block comments above reasonable size | 11:29 |
| allenap | lifeless: 50000 bytes is the limit I think, or 50000 characters. | 11:36 |
| allenap | ... in malone. | 11:37 |
| lifeless | allenap: intellectronica: So, I guess we need an attachment facility for merge proposals. | 11:41 |
| lifeless | I'll file a bug requesting that. | 11:41 |
| intellectronica | lifeless: sounds like a useful thing to have. as a short-term solution what we usually do it attach files to the bug corresponding to the MP and link to the attachment from a comment. | 11:42 |
| lifeless | intellectronica: if there is a bug ... | 11:43 |
| wgrant | lifeless: There already is one. | 11:44 |
| wgrant | lifeless: You just have to submit them by email. | 11:44 |
| lifeless | wgrant: for attachments ? | 11:44 |
| wgrant | Yes. | 11:44 |
| allenap | lifeless, intellectronica: Actually, I think the limit is on Bug.description (sane_description CHECK constraint). As far as the data model is concerned, it might be okay for comments to be bigger. | 11:44 |
| wgrant | If you attach a diff, it will even render it nicely inline. | 11:44 |
| lifeless | wgrant: oh, I've just sent a mail asking for them again then. | 11:44 |
| lifeless | wgrant: whats the # ? | 11:45 |
| intellectronica | allenap: oh, didn't realise that. that's a mis-feature, i think. | 11:45 |
| lifeless | wgrant: and what do you mean 'you just have to submit them by email' ? | 11:45 |
| wgrant | lifeless: As in it's already implemented. | 11:45 |
| wgrant | lifeless: There is no UI to add attachments, but if one is attached to an email then it will work. | 11:45 |
| allenap | intellectronica: I think there /might/ be a comment limit, but only implemented in the app. | 11:45 |
| lifeless | wgrant: I can't see them on https://edge.launchpad.net/+apidoc/devel.html#branch_merge_proposal | 11:46 |
| wgrant | lifeless: The exposed API is not even close to complete. | 11:46 |
| lifeless | wgrant: care to earn brownie points with me ? :> | 11:46 |
| * wgrant has a few too many things on his plate already. | 11:47 | |
| lifeless | wgrant: if you can bear the agony, I'm happy to learn stuff | 11:48 |
| wgrant | lifeless: Why do you want it exposed on the API? | 11:48 |
| lifeless | wgrant: so that PQM can attach failure subunit streams, which can be many MB in size | 11:48 |
| wgrant | Ahh. | 11:49 |
| wgrant | Hm, actually, only diff comments are rendered at all at the moment. Others are stored, but rendered only as HTML comments. | 11:50 |
| wgrant | And... hmmmmmmmmmmm. | 11:51 |
| maxb | Is anyone knowledgeable in bizarre vcs-imports behaviour around? After being reviewed, the initial import of https://code.edge.launchpad.net/~maxb/irssi/trunk was executed 5 times immediately consecutively before it eventually "stuck" and completed for-real | 11:54 |
| wgrant | maxb: bzr-svn and bzr-git initial imports are now done incrementally. | 11:55 |
| wgrant | 1000 revisions in each attempt. | 11:55 |
| maxb | oh... | 11:55 |
| maxb | the UI is somewhat mystic about this | 11:55 |
| wgrant | Hence the grey tick the first few times, which should have an informative tooltip. | 11:55 |
| wgrant | (insufficiently obvious, but at least present) | 11:56 |
| maxb | true (on both counts) | 11:56 |
| lifeless | mthaddon: did you see the pastebin mentioned above ? | 11:59 |
| lifeless | wgrant: and your conclusion on attachments? | 11:59 |
| * mthaddon looks | 12:00 | |
| mthaddon | lifeless: that seems fine | 12:00 |
| lifeless | wgrant: if you're interested in what I'm doing, have a look at lp:pqm - the recent commits | 12:01 |
| lifeless | mthaddon: cool | 12:01 |
| lifeless | mthaddon: I intend to ask spm to try a new pqm for bzr tomorrow (and roll it back if it won't work with the current launchpadlib) | 12:01 |
| lifeless | mthaddon: I wanted to check the docs would be clear enough | 12:01 |
| wgrant | mwhudson/thumper: Either of you still around? | 12:23 |
| james_w | lifeless: it looks to me as though exposing attachments on merge proposals would be at least one day of solid effort on it | 12:30 |
| lifeless | james_w: thanks for estimating it, thats good to know | 12:31 |
| james_w | it's possible it would be quicker, but it's all a little odd, and so isn't just a matter of writing tests and slapping exported() on it | 12:31 |
| wgrant | james_w: What do you see as being odd about it? | 12:33 |
| james_w | you call a method getAtttachments that iterates through chunks on messages and checks their mime type and then returns two lists | 12:34 |
| wgrant | You'd just need a bug-esque addAttachment (and probably linkAttachment). | 12:34 |
| wgrant | Ah, right, for reading them. | 12:34 |
| wgrant | Bugs do the same, but return only one list. | 12:34 |
| james_w | so to add an attachment you need to add a message with a single chunk | 12:34 |
| wgrant | Right, which is what Bug.addAttachment does. | 12:35 |
| lifeless | so an API approach needs only addAttachment; the web display will need that logic | 12:35 |
| wgrant | Isn't it? | 12:35 |
| wgrant | Oh, it's not. | 12:35 |
| wgrant | Odd. | 12:35 |
| wgrant | That actually uses a separate BugAttachment table. Strange strange strnge. | 12:36 |
| james_w | oh, it does attach it to a message though, so not as different as I thought | 12:37 |
| james_w | once again, yay for reinventing comments/attachments/etc. | 12:37 |
| wgrant | There's already a factory method to create the necessary message (I used it a few minutes ago), so it's probably just a matter of shuffling it around. | 12:37 |
| james_w | yeah | 12:38 |
| wgrant | And maybe strangling the next person who invents a new comment system. | 12:38 |
| james_w | oh, the description of the attachment is actually the comment that it is attached to? | 12:38 |
| james_w | interesting | 12:38 |
| wgrant | Hm? | 12:38 |
| wgrant | In which system? | 12:39 |
| james_w | bugs | 12:39 |
| james_w | IBug.addAttachement takes comment=Text() | 12:39 |
| wgrant | That's the text of the comment to be attached to, right. | 12:40 |
| james_w | ah, I'm talking nonsense, ignore me | 12:40 |
| james_w | I was confusing comment and description | 12:41 |
| wgrant | s/description/title? | 12:41 |
| wgrant | It's title in the DB, at least. | 12:41 |
| james_w | description in the API | 12:41 |
| * wgrant is confused now too. | 12:41 | |
| wgrant | Yay. | 12:41 |
| james_w | but yes, code attachments are sufficiently different that there's not a great deal you could take to implement code attachment addition | 12:42 |
| wgrant | I forgot the two systems were so different :/ | 12:42 |
| === mrevell is now known as mrevell-lunch | ||
| === matsubara-afk is now known as matsubara | ||
| deryck | gmb, is bug 546774 qa-able really? Or just passing a test run is sufficient for this? | 13:41 |
| mup | Bug #546774: BugWatchActivity.result should be NOT NULL <qa-needstesting> <story-bug-watch-error-tracking> <story-reliable-bug-syncing> <Launchpad Bugs:Fix Committed by gmb> <https://launchpad.net/bugs/546774> | 13:41 |
| gmb | deryck, Well, we can quickly QA the db patch. I'll ask a LOSA once one comes free. | 13:42 |
| gmb | deryck, But actually, there's probably no point, come to think about it | 13:42 |
| gmb | deryck, I think we can mark it qa'd | 13:43 |
| * gmb does | 13:43 | |
| deryck | gmb, yeah, that's what I wondered, if it really had any value. Thanks! | 13:43 |
| deryck | heh, we've emptied the landed/qa queue and filled it up again. | 13:45 |
| deryck | at least we're being productive | 13:45 |
| maxb | danilos: Can you provide a log of your 'make run' 'pydoc2.4' issue? FYI, the problem is that somehow the value of PYTHON_VERSION isn't being passed down from the root Makefile to the pygettextpo Makefile | 13:45 |
| danilos | maxb, sure, though after a successful make it doesn't complain anymore so I am doing it in a new branch | 13:47 |
| danilos | maxb, btw, it dies on the 'make' rather than 'make run' | 13:47 |
| danilos | maxb, and the output I have seen was totally uninteresting (though, might give you a tip: it happens in pygettextpo) | 13:47 |
| danilos | maxb, it seems it might have been stale sourcecode as well | 13:48 |
| danilos | maxb, yeah, it works just fine now | 13:50 |
| maxb | The pygettextpo sourcecode branch contains PYTHON_VERSION = 2.4 in its Makefile. This isn't a problem, because when the root makefile recurses into sourcecode, it passes its own PYTHON_VERSION as an override to the sub-make | 13:50 |
| danilos | maxb, well, that's where it was trying to execute pydoc2.4; it doesn't anymore, perhaps I need to change some timestamps so make wants to run it again | 13:51 |
| === mrevell-lunch is now known as mrevell | ||
| maxb | wfm in a completely clean environment, so I think it was just staleness hitting you | 13:53 |
| danilos | maxb, yeah, I've tried after doing 'make clean' in pygettextpo and it still works and even rebuilds docs correctly | 13:59 |
| maxb | jelmer (author), rockstar (reviewer): Regarding the cscvs "Set the 'converted-from' revision property." change landed on 2009-12-07. It appears it never got used, because sourcedeps.conf was not updated. I now have a later change to cscvs I want activated. Can you advise on the suitability of that change to go live? | 14:22 |
| jelmer | maxb: heh, whoops | 14:23 |
| jelmer | maxb: I guess any external users of cscvs would've been using it though | 14:23 |
| maxb | Do any of those exist? :-P | 14:23 |
| jelmer | maxb: There's no reason for the converted-from change *not* to go live | 14:23 |
| maxb | I'm a bit unclear on the policy for bumping revnos in sourcedeps.conf. Does it need a review, or do I just need to get someone to rubberstamp and land? | 14:24 |
| deryck | noodles775, ping | 14:28 |
| noodles775 | deryck: hi | 14:29 |
| jelmer | maxb: I *think* you just need a review given the original change has been reviewed by a launchpad reviewer already | 14:33 |
| jelmer | maxb: it's probably different for projects in sourcecode that aren't maintained by launchpad-pqm | 14:34 |
| maxb | ok, I'll put a branch up that bumps the revno to include yours and my changes, and leave it to OCR discretion whether to r or rs | 14:35 |
| * wgrant points at bug #562943, and bugs Bugs people to unbreak notifications | 14:45 | |
| deryck | wgrant, that bug is on MPs, not bugs, or I'm reading it wrong? | 14:51 |
| wgrant | deryck: The bug is Code, but it is probably Bugs' problem that there will have been no notifications about it. | 14:51 |
| wgrant | Security bugs against Launchpad go into a black hole. | 14:51 |
| wgrant | Nobody except the reporter and a list that is never read get notified. | 14:52 |
| deryck | ah, I get what you mean now. Yeah, that is likely on us. | 14:52 |
| deryck | wgrant, is there a bug about that then, about the black hole? | 14:52 |
| wgrant | deryck: It's probably not so much a bug as a config issue. | 14:53 |
| wgrant | A config issue which exists because the Launchpad notification system is pretty awful. | 14:53 |
| deryck | wgrant, right, agreed. But still would be nice to have a bug to track the issue and see if better general solution couldn't be found. | 14:53 |
| deryck | intellectronica, can you do a quick pre-imp about bug 556499 now? | 14:56 |
| mup | Bug #556499: Set user expectations for Ubuntu bugs after user reports a bug <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/556499> | 14:56 |
| intellectronica | deryck: sure. just give me a sec to get on skype again | 14:58 |
| deryck | intellectronica, great, same for me. thanks! | 14:58 |
| wgrant | abentley: Bug #562943 may interest you. | 15:00 |
| intellectronica | deryck: ready when you are | 15:00 |
| === Ursinha-afk is now known as Ursinha | ||
| Ursinha | hi gary_poster, I know you're busy now, but for you to answer later :) I've seen about 200 daily oopses like this one: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1564CEMAIL1, I wonder if it's the same problem as bug 54005 but with a slightly different symptom? | 15:08 |
| mup | Bug #54005: bugs.launchpad.ubuntu.com email ending up in Launchpad mailbox <email> <infrastructure> <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/54005> | 15:08 |
| gary_poster | Ursinha: I have no idea, unfortunately. stub, are you around and available to look at what Ursinha wrote and share a guess? | 15:13 |
| * stub has a look | 15:13 | |
| stub | I'd say the OOPS system is rooted | 15:14 |
| gary_poster | stub, uh? | 15:18 |
| stub | The OOPS is almost entirely blank. There is an email listed though, which if I examine looks like it was sent to noreply@ubuntu.com but delivered by the mail system to launchpad@mail.canonical.com | 15:18 |
| stub | Have a look at that oops | 15:18 |
| stub | Traceback: None None Traceback (most recent call last): None | 15:18 |
| stub | I guess it is a handled error that we are just dumping to an OOPS for reporting? | 15:19 |
| gary_poster | stub, I did see oops. I didn't know what to think of it either. So you think we have a security compromise on the OOPS machine? matsubara, any thoughts? | 15:19 |
| stub | I don't see a security compromise anywhere. | 15:20 |
| gary_poster | sorry, then what did you mean by "rooted" | 15:20 |
| * gary_poster looks up australian definitions :-) | 15:21 | |
| * gary_poster thinks he understands | 15:21 | |
| gary_poster | "broken" | 15:21 |
| stub | yes :) | 15:21 |
| gary_poster | :-) k | 15:21 |
| matsubara | hehe | 15:21 |
| matsubara | I think it's the same issue described in bug 54005 | 15:22 |
| stub | It looks like a wiki update email was sent to launchpad@mail.canonical.com, and our mail processor doesn't know how to handle it. | 15:22 |
| mup | Bug #54005: bugs.launchpad.ubuntu.com email ending up in Launchpad mailbox <email> <infrastructure> <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/54005> | 15:22 |
| stub | I have no idea why that email was routed to us, but as it isn't our wiki and as it isn't our email infrastructure it is just another piece of spam | 15:22 |
| gary_poster | stub, matsubara it felt lke it was something like that | 15:23 |
| gary_poster | ok | 15:23 |
| wgrant | 4 | 15:23 |
| wgrant | Argh. | 15:23 |
| gary_poster | so Ursinha, yes, I think it is similar. I'll add matsubara's and stub's comments. | 15:25 |
| gary_poster | matsubara: why would that OOPS be blank? Is the source file blank, or does this indicate a problem? | 15:25 |
| matsubara | gary_poster, that's another bug that Ursinha found. bug 230106 | 15:25 |
| mup | Bug #230106: emails interface oops reports need better error messages <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/230106> | 15:25 |
| Ursinha | yeah, that :) | 15:25 |
| Ursinha | wgrant, irssi? :) | 15:26 |
| stub | That is an old, old bug. Its a bit of an assumption to think they are the same (I have no idea if that old one is still valid - I don't even remember opening it 4 years ago!) | 15:26 |
| wgrant | Ursinha: Of course. | 15:26 |
| stub | 54005 I mean | 15:26 |
| Ursinha | stub, c'mon, I don't remember bugs I opened last month... | 15:26 |
| gary_poster | stub, ack. | 15:26 |
| gary_poster | Ursinha, matsubara: 230106: ok, cool (for some definition of cool :-) ) | 15:27 |
| Ursinha | in any case, it would be good to have bug 230106 fixed | 15:27 |
| mup | Bug #230106: emails interface oops reports need better error messages <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/230106> | 15:27 |
| Ursinha | hi deryck :) | 15:27 |
| gary_poster | heh | 15:27 |
| stub | The referenced email in the bug is gone too - garbage collected a few years ago probably :) | 15:27 |
| gary_poster | heh | 15:28 |
| * deryck sees name and "heh" and gets nervous | 15:28 | |
| Ursinha | lol | 15:28 |
| gary_poster | :-) | 15:29 |
| bigjools | stub: can you make a dump of prod for me to refresh mawson please - it should be quicker than 2 weeks to restore this time I hope? :) | 15:29 |
| Ursinha | deryck, we've been having 200 oopses with "None: none" content, how difficult would it be to fix that bug? | 15:29 |
| Ursinha | deryck, bug 230106, that is | 15:30 |
| mup | Bug #230106: emails interface oops reports need better error messages <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/230106> | 15:30 |
| deryck | Ursinha, I really have no idea what's involved, sorry. I wasn't aware of that bug until now. Does this mean we have places in the bugs app where we just raise a bare Exception? And we need something specific? | 15:31 |
| Ursinha | deryck, to be hones I don't know why is it assigned to bugs, but that bug would be to avoid oopses like https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1563CEMAIL1 to be empty as they are | 15:32 |
| Ursinha | *honest | 15:32 |
| stub | bigjools: Better if the losas do - I don't have the keys setup | 15:32 |
| stub | (this could probably be scheduled) | 15:32 |
| bigjools | stub: it's somewhat awkward on mawson but maybe | 15:33 |
| deryck | Ursinha, ah, it's to do with errors we raise when failing on bugs email, I think. | 15:33 |
| bigjools | anyway I'll ask them, cheers | 15:33 |
| stub | permission denied (public key). Yer. | 15:34 |
| * stub wonders what he broke | 15:34 | |
| deryck | Ursinha, so good and bad news -- bad, we won't fix this ASAP, but we can look at it as part of our better subscriptions/notifications story coming next month. | 15:35 |
| Ursinha | deryck, that's much better than nothing :) | 15:36 |
| Ursinha | in the meantime, gary_poster and stub, could you investigate that issue, please? | 15:38 |
| Ursinha | gary_poster, there's another oops to which I just filed a bug, bug 563055 | 15:39 |
| mup | Bug #563055: Mail parsing failing with ValueError <oops> <Launchpad Foundations:New> <https://launchpad.net/bugs/563055> | 15:39 |
| gary_poster | Ursinha: 54005: There are a lot bigger things floating around, I'm afraid. Maybe given the number of OOPSes we'll be able to get to it in a few weeks. I added the notes to the bug. | 15:40 |
| gary_poster | looking at other one | 15:40 |
| gary_poster | Ursinha: 563055: that's a spam message. low priority unless the OOPSes are high for this. Are they? | 15:43 |
| Ursinha | gary_poster, we had 36 yesterday | 15:44 |
| gary_poster | ... | 15:44 |
| Ursinha | gary_poster, but none today | 15:44 |
| Ursinha | so it's intermittent | 15:44 |
| Ursinha | (?) | 15:44 |
| gary_poster | just not sure how to treat then :-) | 15:44 |
| gary_poster | thank you | 15:44 |
| Ursinha | gary_poster, no problem, thanks for taking a look in all these issues | 15:45 |
| gary_poster | np thank you | 15:45 |
| Ursinha | also thanks deryck and stub | 15:45 |
| deryck | np | 15:46 |
| === danilos is now known as daniloff | ||
| Ursinha | gary_poster, re. bug 563055 I spoke too soon, I see 25 oopses today; not much, just correcting my previous statement | 15:54 |
| mup | Bug #563055: Mail parsing failing with ValueError <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/563055> | 15:54 |
| gary_poster | ack Ursinha thank you | 15:55 |
| barry | does anybody (maybe leonardr, flacoste, or gary_poster) know anything about bug 512832 in lazr.restfulclient? i'm getting hit by this but it's fix released, i'm assuming in lazr.rc 0.9.13. however lucid appears to have 0.9.11. do we need to push an update to lucid? | 15:56 |
| mup | Bug #512832: launchpadlib caches based on full URL <lazr.restfulclient:Fix Committed> <https://launchpad.net/bugs/512832> | 15:56 |
| gary_poster | barry: I know this keeps biting us in one way or another but AFAIK the current status is still fix released. It does look like this was fix committed on 2010-02-16, and 0.9.11 was released on 2010-02-11, so it seems pretty clear that at least something sooner is needed. | 16:00 |
| gary_poster | leonardr would need to provide more confidence. | 16:00 |
| gary_poster | s/would need/could/ | 16:01 |
| barry | gary_poster: i think you mean s/sooner/later/ ? :) | 16:01 |
| gary_poster | barry: yes, I was actually trying to say "more recent" :-) | 16:02 |
| barry | gary_poster: :) | 16:02 |
| barry | i'm happy to help push out 0.9.13 if you guys don't have time for it. i'd really like to have this fixed asap | 16:02 |
| barry | gary_poster: but i'll wait to see if leonardr responds... | 16:02 |
| gary_poster | barry: your help would be much appreciated, of course. | 16:03 |
| barry | gary_poster: cool. i'll take a look at this later today | 16:04 |
| gary_poster | thanks | 16:04 |
| leonardr | gary, are you sure it's not bug 545197? | 16:13 |
| mup | Bug #545197: Cache filenames are (still) too long for ecryptfs <lazr.restfulclient:Fix Released> <https://launchpad.net/bugs/545197> | 16:13 |
| leonardr | s/gary/barry/ | 16:13 |
| gary_poster | leonardr: that's what I meant by "it keeps biting us" | 16:13 |
| leonardr | yeah | 16:13 |
| leonardr | 0.9.13 should get rid of it for good, and if not, it makes it easy to hack the maximum file length | 16:14 |
| barry | leonardr: could be. 563065 what what a quick search found. i will at least put 0.9.13 in my ppa and give it a try | 16:14 |
| barry | i do have my home dir crypted | 16:14 |
| Ursinha | sinzui, hi, I'm trying to reproduce https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1564B963 but no luck, do you have an idea? | 16:23 |
| wgrant | leonardr: Any chance of fixing bug #401990 some time soon? It makes it pretty awful for non-Ubuntu users to use launchpadlib. | 16:32 |
| mup | Bug #401990: Depends on lazr.restful <lazr.restfulclient:New> <https://launchpad.net/bugs/401990> | 16:32 |
| === matsubara is now known as matsubara-lunch | ||
| leonardr | gary, is that something we can fix given the current state of buildout? | 16:33 |
| gary_poster | leonardr: ...I'm not sure on how buildout impacts it. If lazr.restfulclient really doesn't need lazr.restful, we ought to be able to just remove the dependency from setup.py and move on. Does it only depend on it for tests, perhaps? | 16:36 |
| leonardr | gary: yes | 16:36 |
| leonardr | it's a test dependency | 16:36 |
| leonardr | i brought this up a while ago and iirc the conclusion was 'buildout sucks, let's do it later' | 16:36 |
| wgrant | I'm sure I've seen other ZTK packages specify test deps. | 16:36 |
| leonardr | wgrant, if you can point me to an example that would help a lot | 16:37 |
| gary_poster | leonardr: I don't think buildout has anything to do with it. We could easily have buildout require lazr.restful for tests, and then remove the core dependency. However, philosophically, that means we don't have any assurance that lazr.restfulclient really works without that dependency (and even it's dependencies!). Therefore, I kind of hate that approach. | 16:37 |
| gary_poster | Perhaps there us a middle ground. | 16:38 |
| gary_poster | is | 16:38 |
| wgrant | gary_poster: Well, depending on lazr.restful brings in dozens and dozens of completely unnecessary ZTK. | 16:38 |
| gary_poster | An option I've done in the past is to define two test suites | 16:38 |
| leonardr | i was going to suggest something like that | 16:38 |
| gary_poster | One test suite verifies basic operation with only standard dependencies... | 16:38 |
| gary_poster | ok | 16:38 |
| gary_poster | yeah, I'd be fine with that | 16:39 |
| leonardr | we do have some tests in lazr.restfulclient that run against fake wsgi 'web services' | 16:39 |
| leonardr | they don't do anything, but they prove that basic lazr.restfulclient functionality works | 16:39 |
| gary_poster | I'd be much happier with that. then. | 16:39 |
| gary_poster | (sigh, s/it's dependencies/its dependencies/) | 16:40 |
| leonardr | if you're ok with me doing so, i will look into this after the first stage of performance work is done (which could be today) | 16:42 |
| gary_poster | leonardr: I'm fine with that. I added notes and comments to bug report. | 16:44 |
| leonardr | ok | 16:44 |
| jml | I have decided, strategically, that my day will be better if I have some chocolate. | 17:03 |
| gary_poster | :-) | 17:03 |
| james_w | I think sharing would be a good strategy | 17:05 |
| * gary_poster envisions willy wonka and the chocolate factory, sending chocolate over TV^D^Dthe internet | 17:06 | |
| === deryck is now known as deryck[lunch] | ||
| Ursinha | jelmer, hi, is soyuz team aware of this oops? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1564L1960 | 17:26 |
| jelmer | Ursinha: hi | 17:28 |
| jelmer | Ursinha: I can't remember seeing a bugreport about it, so I don't think we are | 17:28 |
| Ursinha | jelmer, I'm filing one :) | 17:28 |
| jelmer | Ursinha: Thanks! | 17:28 |
| === matsubara-lunch is now known as matsubara | ||
| Ursinha | jelmer, bug 563176, thanks! :) | 17:31 |
| mup | Bug #563176: OOPS accessing a distroseries binary package in a +source page <oops> <Soyuz:New> <https://launchpad.net/bugs/563176> | 17:31 |
| gary_poster | rockstar or abentley: I tried to register code mirror of an svn: scheme and got "The URI scheme "svn" is not allowed. Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp". That's new--I've imported svn: schemes many times before. :-/ Why the change? | 17:38 |
| gary_poster | zope's svn traditionally only supported the svn: and svn+ssh: schemes | 17:38 |
| rockstar | gary_poster, you don't want a mirrored branch, you want an import branch. | 17:38 |
| gary_poster | rockstar I don't see that option on, for instance, https://code.edge.launchpad.net/zope.event/+addbranch | 17:39 |
| rockstar | gary_poster, imports don't follow the same flow (stupid, I know) | 17:39 |
| gary_poster | :-) | 17:39 |
| rockstar | gary_poster, https://code.edge.launchpad.net/+code-imports/+new | 17:40 |
| gary_poster | rockstar: ah. I used mirrored branch to create https://code.edge.launchpad.net/~gary/z3c.recipe.filetemplate/svn and it worked fine | 17:41 |
| gary_poster | so something changed | 17:42 |
| rockstar | gary_poster, did you do it just now? | 17:42 |
| gary_poster | rockstar: five days ago it worked (created that branch then) | 17:42 |
| gary_poster | and just now it failed (from +addbranch) | 17:43 |
| * jml back to hacking | 17:43 | |
| rockstar | gary_poster, *shrug* no idea. I'm pretty sure it shouldn't have worked the first time. | 17:43 |
| gary_poster | huh | 17:43 |
| gary_poster | ok | 17:43 |
| gary_poster | so rockstar maybe last question then ;-) how can I tell if this is using bzr-svn or cscvs (or whatever it is)? If it is using the old juice, how do I (or other people) convert it to the new bzr-svn juice? | 17:45 |
| gary_poster | https://code.edge.launchpad.net/~vcs-imports/zope.deferredimport/trunk | 17:45 |
| rockstar | gary_poster, all new svn imports are using bzr-svn | 17:45 |
| gary_poster | rockstar: right, this was an old one, 2008. so it is cscvs. is the upgrade path to delete and recreate? | 17:46 |
| rockstar | gary_poster, and unless the cscvs import is failing, we aren't currently converting them, since it's basically just rebasing the branches (bad bad bad bad bad) | 17:46 |
| rockstar | gary_poster, if you're the only one using the branch, delete and recreate is probably fine. Is there something wrong with the branch? | 17:46 |
| gary_poster | rockstar, no, but zope folks seem to be interested in trying out more of the code-hosting bits, and in my experience the cscvs imports are much more fragile than the bzr-svn imports. For example, with my bzr-svn imports I can push svn branches to LP and do MPs and everything Just Works in a reallt nice way (except externals, of course :-/ ). I want them to have a similar experience. | 17:48 |
| rockstar | gary_poster, this is absolutely true. I agree that we should put our best foot forward. | 17:49 |
| rockstar | If there's no real fallout from it, let's do it. | 17:49 |
| gary_poster | rockstar: ack, thank you. I'll see if I can determine fallout. :-) | 17:50 |
| === gary_poster is now known as gary-lunch | ||
| === mpt_ is now known as mpt | ||
| maxb | Given that cscvs and bzr-svn will generate different revision-ids, the *only* upgrade path is move-aside and recreate. | 18:03 |
| sinzui | james_w, I jinked myself. a gentoo user reported another bug about source packages: Bug 563195 | 18:03 |
| mup | Bug #563195: distrotask: lp fails to recognize many gentoo packages in "source package name" <distrotask> <gentoo> <Launchpad itself:New> <https://launchpad.net/bugs/563195> | 18:03 |
| james_w | heh | 18:06 |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| jml | I'll fix the conflict between db-devel and stable | 18:27 |
| jml | is there any particular reason the 'combine_css' operation in the Makefile isn't specified as the CSS file it creates? | 18:40 |
| jml | hmm, I see. the 'combine-css' script uses a lazr.js method that duplicates some of make's logic. | 18:43 |
| leonardr | gary or james_w, can you give me some guidance on setting up a test dependency? i'm following http://reinout.vanrees.org/weblog/2009/12/17/managing-dependencies.html but just setting up an extras_require stanza isn't working | 18:45 |
| leonardr | can you point me to an example? | 18:45 |
| leonardr | (tests_require also doesn't work btw) | 18:49 |
| deryck | intellectronica, still around? | 18:51 |
| leonardr | ok, i think i figured it out... | 18:54 |
| === beuno-lunch is now known as beuno | ||
| === gary-lunch is now known as gary_poster | ||
| === dpm is now known as dpm-afk | ||
| jml | leonardr, what was the issue? | 19:20 |
| jml | leonardr, worth adding a note to doc/buildout.txt? | 19:20 |
| leonardr | jml: i didn't know how buildout worked | 19:20 |
| jml | leonardr, ahh ok :) | 19:20 |
| leonardr | i'm getting my test suite working and then i'll need to ask you some more questions about how buildout works | 19:20 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| leonardr | jml: ok, my question is now formulated | 19:29 |
| leonardr | well, let me look at buildout.txt first. is that in launchpad? | 19:29 |
| intellectronica | deryck: looks like i missed your ping earlier. sorry! still relevant? | 19:35 |
| jml | leonardr, yeah, it's under the root doc/ folder | 19:36 |
| jml | leonardr, it's been able to answer maybe 90% of my buildout questions | 19:36 |
| deryck | intellectronica, hey, yeah, so please look at line 71 of the green of this rev: http://bazaar.launchpad.net/~deryck/launchpad/bug-count-filters-503222/revision/10234 | 19:37 |
| * maxb chuckles at [r=jfdi] | 19:37 | |
| deryck | intellectronica, does that "<tr><td colspan="2"><br /></td></tr>" to create space bother you in this context? | 19:37 |
| intellectronica | deryck: no, i think it's a fine pragmatic solution. if you want to be really pedantic you can add a tal:comment explaining why it's there. | 19:39 |
| deryck | intellectronica, ok, I'll do that. I want a better way, but give all the tables there anyway, it seems the cleanest for the moment. | 19:39 |
| intellectronica | cool | 19:40 |
| jml | maxb: :D | 19:40 |
| jml | mwhudson, ping | 20:37 |
| mwhudson | jml: hi | 20:40 |
| jml | mwhudson, I've got a couple of branches that need review. I think you'd be the perfect reviewer. | 20:40 |
| mwhudson | jml: ok | 20:41 |
| mwhudson | jml: feel free to request a review on launchpad | 20:41 |
| jml | mwhudson, done | 20:41 |
| jml | mwhudson, one of them is slightly over 1000 lines, but that's just moving stuff around | 20:42 |
| mwhudson | jml: yeah well, only people on your side of the world care about that | 20:42 |
| jml | mwhudson, :\ | 20:43 |
| jml | mwhudson, I still haven't figured out European code review. | 20:46 |
| jelmer | there is *a* European code review standard ? :-P | 20:49 |
| jml | jelmer, yeah, those guys in Brussels think of everything | 20:51 |
| jml | g'night all | 21:13 |
| === Edwin-lunch is now known as EdwinGrubbs | ||
| === dpm-afk is now known as dpm | ||
| lifeless | notifications fail :) - http://imagebin.org/93049 | 22:22 |
| mwhudson | well, not exactly new | 22:25 |
| mwhudson | thanks for doing those approvals though | 22:25 |
| lifeless | I know | 22:25 |
| lifeless | I just laugh every time it happens - I pointed it out in dev | 22:25 |
| lifeless | and stub was 'meh, it will hardly ever happen' | 22:25 |
| lifeless | the reason I'm donig them is that tres did something annoying | 22:27 |
| lifeless | registered 50 | 22:27 |
| lifeless | and then renamed them all | 22:27 |
| lifeless | so the email links we were sent were stale | 22:27 |
| wgrant | Did stub's changes test commit changes make the test suite about an hour faster? | 22:27 |
| wgrant | I have stuff landing in less than four hours now! | 22:28 |
| wgrant | Any LOSAs around? buildd-manager is ignoring some buildds. | 22:31 |
| === matsubara is now known as matsubara-afk | ||
| wgrant | Total: 25792 tests, 25 failures, 9 errors in 204 minutes 11.495 seconds. | 22:32 |
| wgrant | Python 2.6 approaches... | 22:32 |
| mwhudson | lifeless: ah yes, that's (arguably) because we don't allow you to set the owner on the new code import page | 22:32 |
| mwhudson | (there's a bug about this, i think) | 22:32 |
| lifeless | ok nothing pendnig review | 22:33 |
| mwhudson | lifeless: thanks | 22:37 |
| lifeless | the magic of tabs | 22:38 |
| wgrant | Do we have a LOSA at the moment? | 22:38 |
| mwhudson | wgrant: mbarnett and/or Chex should be around | 22:38 |
| mbarnett | wgrant: i just returned from feasting | 22:38 |
| wgrant | mbarnett: Ah, your idle time did not raise my hopes. | 22:39 |
| wgrant | mbarnett: Can you check buildd-manager's log for any obvious strangeness? ia64, powerpc and sparc builds are not dispatching at the moment. | 22:39 |
| wgrant | Which does not make Ubuntu release managers very happy. | 22:40 |
| mbarnett | yup, taking a peek | 22:40 |
| wgrant | Thanks. | 22:40 |
| wgrant | lamont has been pinged, but appears to not be around. | 22:40 |
| mbarnett | wgrant: yeah, he has EODd. i am not seeing anything obvious in the sequencer's logs | 22:45 |
| mbarnett | wgrant: though my unfamiliarity might be a liability here :) | 22:45 |
| wgrant | mbarnett: No recent log entries mentioning artigas or sejong? | 22:46 |
| mbarnett | wgrant: 2010-04-14 19:45:17+0100 [-] Processing successful build 1691253-3345351 from builder artigas | 22:49 |
| mbarnett | wgrant: nothing recent from sejong | 22:50 |
| wgrant | mbarnett: Argh. | 22:51 |
| mbarnett | that doesn't sound happy at all! | 22:52 |
| wgrant | Indeed... some archs are rather behind, and we are dangerously close to release. | 22:52 |
| mbarnett | wgrant: do you think this warrants restarting the sequencer to see if that picks up the ignored jobs? | 22:53 |
| wgrant | Without lamont, I guess the next thing to try is, in Python, "import xmlrpclib; xmlrpclib.ServerProxy('http://artigas.buildd:8221/rpc').status()" on cesium, and see what the buildd thinks its doing. | 22:53 |
| wgrant | mbarnett: Unlikely. It's not *that* shoddy :P But we could try that if all else fails. | 22:53 |
| elmo | artgias isn't doing anything | 22:55 |
| mbarnett | wgrant: BuilderStatus.IDLE | 22:55 |
| elmo | but it is getting poked by the build manager | 22:55 |
| elmo | god I wish that thing had better logging | 22:55 |
| elmo | I mean srsly | 22:55 |
| wgrant | elmo: We improved logging a *lot* for 10.03. | 22:57 |
| wgrant | But it might still need to be flipped into DEBUG for it to tell us why it is ignoring a few of them :/ | 22:57 |
| wgrant | mbarnett: Sad. That's normal. | 22:57 |
| maxb | wgrant: Hi. Do you find attaching test logs to the wiki page is useful? I find that the layer-by-layer list of issues is what usefully displays progess and suggests action | 23:11 |
| wgrant | maxb: I was going to get to that eventually. Just got to deal with a couple of other bits and pieces first. | 23:11 |
| maxb | sure. I was thinking of tacking the tarfile nonsense next. | 23:12 |
| maxb | *tackling | 23:12 |
| wgrant | Yeah, that's the big one. | 23:12 |
| wgrant | mwhudson: Any ideas on the Mercurial failures on https://dev.launchpad.net/PythonMigrationStatus? | 23:14 |
| maxb | Fortunately it's a fairly shallow problem | 23:14 |
| wgrant | I suspect that once we fix TestMercurialImport.test_import, the rest will magically vanish too, but I haven't dealt with import slaves before so I don't know where to start | 23:14 |
| maxb | mwhudson: note that they seems to randomly oscillate between mercurial and git in different test runs | 23:14 |
| wgrant | maxb: What do you make of bugs-emailinterface.txt? It looks to me like the test is testing for broken behaviour!? | 23:15 |
| mwhudson | maxb: um, no not really | 23:15 |
| maxb | wgrant: Well, I guess the question is "why has the behaviour changed?". I've not looked into that one. | 23:16 |
| mwhudson | maxb: so it's not reliably reproducible? | 23:17 |
| maxb | mwhudson: *something* fails in that layer every time I've seen, but it varies whether it's the git tests, the hg tests, or both | 23:17 |
| wgrant | When running just the hg tests locally I've not seen them not fail. | 23:18 |
| maxb | I am really starting to hate the author of the tarfile module | 23:25 |
| james_w | it's not one of the most pleasant modules to use | 23:25 |
| james_w | I dropped it in favour of shelling out to tar eventually | 23:25 |
| maxb | It seems to break its interface every python version | 23:25 |
| mwhudson | that's what code imports do too | 23:26 |
| wgrant | Also, the author refuses to make it safe to extract things with. | 23:26 |
| lifeless | thumper: ping | 23:27 |
| lifeless | wgrant: I know the bug you're referring too; I don't think its that simple a refusal. IIRC he said roughly 'this is the same as tar itself' | 23:28 |
| lifeless | wgrant: just do filename checks in a loop; its not hard. | 23:28 |
| wgrant | lifeless: But it's not the same as tar itself. | 23:28 |
| wgrant | It has had the symlink and directory traversal vulnerabilities fixed for years. | 23:29 |
| mwhudson | maxb: ugh, i can only really suggest debugging via printf or something then | 23:34 |
| wgrant | I've added a sleep just before the failure, and it looks like hg.tdb is there, but not hg-v2.db. | 23:35 |
| wgrant | Odd. | 23:35 |
| mwhudson | oh | 23:35 |
| mwhudson | i guess you have python-tdb installed? | 23:36 |
| wgrant | Ahahah. | 23:36 |
| wgrant | And it's only for 2.6 | 23:36 |
| wgrant | So it uses tdb in preference? | 23:36 |
| mwhudson | yeah | 23:36 |
| mwhudson | though | 23:36 |
| mwhudson | i thought we mostly avoiding importing things from the system locations now? | 23:37 |
| mwhudson | maybe i'm confused | 23:37 |
| wgrant | We all know that doesn't work very effectively. | 23:37 |
| * wgrant removes python-tdb and reruns the tests. | 23:37 | |
| jelmer | tdb allows concurrent access and is a bit faster than sqlite | 23:38 |
| mwhudson | sadly bzr-hg doesn't really work :) | 23:38 |
| wgrant | Oh look, the tests pass now. | 23:38 |
| maxb | ugh ugh ugh. system-environment-dependent test -- | 23:39 |
| wgrant | jelmer: Can we tell bzr-hg to not use tdb somehow? | 23:39 |
| maxb | We could patch our sourcecode/ bzr-hg | 23:40 |
| jelmer | wgrant: not at the moment, other than patching the source | 23:40 |
| mwhudson | i think that's probably sane | 23:41 |
| mwhudson | i guess the bzr-git code is now safe from this because it works at the directory level | 23:41 |
| * mwhudson vanishes, back online in a bit (subject to cafenet working today...) | 23:41 | |
| wgrant | jelmer: Will we want to use tdb soonish? | 23:42 |
| jelmer | wgrant: we is hoping that jam finishes his pack collection refactoring soon so that we can use native bzr objects | 23:43 |
| wgrant | jelmer: Ah, OK. So I guess it is semi-reasonable to just hack the sourcecode copy temporarily until it goes away. | 23:44 |
| jelmer | 44444444444jjj~. | 23:45 |
| jelmer | wgrant: yes | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
