| kiko | hmmm | 12:14 |
|---|---|---|
| malcc | kiko: The traceback doesn't say, but I'm sure I can find where it leads to drq.addSource, if that's useful | 12:14 |
| kiko | 2029. | 12:14 |
| kiko | queue_root = self.distrorelease.createQueueEntry(self.policy.pocket, | 12:14 |
| kiko | self.changes_basename, self.changes["filecontents"] ) | 12:14 |
| kiko | # Next, if we're sourceful, add a source to the queue | 12:14 |
| kiko | if self.sourceful: | 12:14 |
| kiko | queue_root.addSource(self.policy.sourcepackagerelease) | 12:14 |
| malcc | kiko: Yes, that looks like the one | 12:14 |
| malcc | kiko: I'm sure nascentupload and the zcml are right, the question is, why is zopeless layer working to give me permissive security on my machine, but not on pqm? | 12:15 |
| kiko | malcc, what's the test? | 12:15 |
| === lbm [n=lbm@82.192.173.92] has joined #launchpad | ||
| malcc | kiko: https://devpad.canonical.com/~andrew/paste/filei63hW3.html | 12:16 |
| kiko | but malcc... | 12:17 |
| kiko | do you know which test is failing? | 12:18 |
| malcc | kiko: Yes, testUploadToFrozenDistro | 12:18 |
| malcc | kiko: It's failing where it first compares the email results - the first upload is rejected, instead of going to NEW | 12:18 |
| malcc | kiko: Funny enough, the other test is passing. Hmm... | 12:18 |
| kiko | and it's run exactly before this one? | 12:19 |
| malcc | kiko: Hmm, no it isn't, it isn't running the other one | 12:19 |
| kiko | at all? | 12:20 |
| malcc | kiko: Sorry cancel that, getting tired | 12:20 |
| malcc | kiko: It runs the other one just before this one and it works fine | 12:20 |
| malcc | kiko: Runs them in the same order locally | 12:20 |
| cprov | malcc: I can help you tomorrow morning, will wake up 9 UTC | 12:22 |
| kiko | weird weird weird. | 12:23 |
| === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad | ||
| malcc | Hmm. Good job we had this think about it, I've just realised my fix is wrong anyway | 12:27 |
| malcc | Ah, no it isn't. I persuaded myself it would stop publishing frozen distros, but actually the code right now would refuse to publish release on a frozen distro, and that's wrong too | 12:29 |
| malcc | My change would start publishing them. But I'm not going to force it through until I've had another think in the morning | 12:29 |
| malcc | Ok, night all | 12:29 |
| === Burgwork [n=corey@ubuntu/member/burgundavia] has joined #launchpad | ||
| === niemeyer [n=niemeyer@201.23.168.11] has joined #launchpad | ||
| mpt | cprov-afk, ping | 12:33 |
| mpt | darn, ten minutes too late | 12:33 |
| cprov-afk | mpt: not really ;),pong | 12:42 |
| mpt | cprov-afk, I was wondering yesterday if any of the Soyuz pages on the Canonical wiki are useful any more | 12:42 |
| cprov-afk | mpt: they are not, maybe only SoyuzCatchUp | 12:43 |
| === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad | ||
| malcc | Ok, actually, I was talking nonsense, it all came clear, the fix is exactly right | 12:43 |
| kiko | malcc, what the hell | 12:44 |
| Nafallo | malcc: go to sleep then? :-) | 12:44 |
| mpt | cprov-afk, ok, I'll move that one and delete the rest | 12:45 |
| malcc | kiko: I mean, you see those last few lines before I logged out, where I'd convinced myself maybe my status fix wasn't right? Well I was talking nonsense, the status fix is exactly right | 12:45 |
| malcc | kiko: I still don't have a clue about the pqm issue though | 12:45 |
| kiko | heh | 12:45 |
| kiko | sleep over it | 12:45 |
| malcc | Yeah | 12:46 |
| kiko | tomorrow morning there are wizards available to help | 12:46 |
| kiko | anyway, zzzing here as well | 12:46 |
| malcc | Nafallo: Yes, good idea :) | 12:47 |
| malcc | Night again all | 12:47 |
| Nafallo | malcc: night :-) | 12:47 |
| === Nafallo starts the timer :-P | ||
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] | ||
| === danilo_ [n=danilo@cable-89-216-150-8.dynamic.sbb.co.yu] has joined #launchpad | ||
| mpt | Gooooooooooooooooooooood afternoon Launchpadders! | 02:31 |
| === AlinuxOS [n=alinux@d83-176-121-107.cust.tele2.it] has joined #launchpad | ||
| === lamont [i=lamont@nat/hp/x-e347698875221e4a] has joined #launchpad | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad | ||
| === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad | ||
| Ubugtu | New bug: #60169 in launchpad-bazaar "Product's +branches page contains misleading link to www.bazaar-vcs.org" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60169 | 04:10 |
| === stub [n=stub@ppp-58.8.6.29.revip2.asianet.co.th] has joined #launchpad | ||
| jamesh | I wonder if it would be a good idea to randomly perturb the db sequences after building the database for the tests | 04:29 |
| jamesh | to remove the possibility of relying on the exact value of new sequence numbers | 04:30 |
| === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad | ||
| Keybuk | random Q ... it's not possible for a spec to exist for multiple products? | 04:39 |
| Keybuk | or should I say pillars? | 04:39 |
| jamesh | Keybuk: no. | 04:39 |
| Ubugtu | New bug: #60172 in launchpad "Launchpad shouldn't auto-link "sftp://" by itself" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60172 | 05:40 |
| Ubugtu | New bug: #60173 in blueprint "Attendance list of a sprint should be private, or attendance should be markable as private" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60173 | 05:45 |
| stub | jamesh: We already use a script to reset all the sequences to the correct values, it would be trivial to add a random number to them. | 06:54 |
| stub | Has this been a problem? | 06:54 |
| jamesh | stub: I ran into a few extra test failures when landing a branch that added to the sample data -- if the sequences didn't have a fixed starting value this would have been less of a problem | 06:56 |
| jamesh | might not be worth the hassle though | 06:57 |
| stub | It involves adding a --random argument to database/schema/reset_sequences.py and a random parameter to canonical.database.postgresql.resetSequences - pretty trivial. | 06:58 |
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| === frodon_ido [n=patrick@ip-213-49-147-165.dsl.scarlet.be] has joined #launchpad | ||
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| === lfittl [n=lfittl@193.170.41.114] has joined #launchpad | ||
| === mpt [n=mpt@203-167-187-118.dsl.clear.net.nz] has joined #launchpad | ||
| mpt | jamesh, is there any way of exporting your calendar as an .ics or anything like that? | 08:25 |
| jamesh | mpt: yeah. add "/+icalendar" to the end | 08:27 |
| jamesh | e.g. https://launchpad.net/people/mpt/+calendar/+icalendar | 08:27 |
| mpt | jamesh, awesome, thanks | 08:27 |
| === Spads [n=spacehob@host-87-74-19-213.bulldogdsl.com] has joined #launchpad | ||
| === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad | ||
| === carlos [n=carlos@138.Red-81-39-35.dynamicIP.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 08:34 |
| SteveA | morning | 09:01 |
| === Burgundavia_ [n=corey@ubuntu/member/burgundavia] has joined #launchpad | ||
| === glatzor [n=sebi@ppp-82-135-82-91.dynamic.mnet-online.de] has joined #launchpad | ||
| SteveA | mpt: hi | 09:15 |
| mpt | hi SteveA, cooking dinner right now, back in an hour or so | 09:17 |
| SteveA | mpt: ok | 09:20 |
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| jordi | morning guys | 09:37 |
| === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad | ||
| === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad | ||
| === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad | ||
| === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad | ||
| malcc | Any testing gurus in the house? | 10:16 |
| === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad | ||
| malcc | I have a test (https://devpad.canonical.com/~andrew/paste/filei63hW3.html) which passes fine on my machine, but when run on PQM fails with a permissions error | 10:16 |
| malcc | Which is a surprise, as the zopeless layer ought to let me do whatever I like, and indeed this seems to work on my local machine just fine | 10:16 |
| === Spads_ [n=spacehob@host-87-74-83-75.bulldogdsl.com] has joined #launchpad | ||
| BjornT | malcc: could you put up the full error log (i.e. pqm's failure message) somewhere? | 10:23 |
| BjornT | malcc: also, it'd be worth doing exactly what pqm does. take a fresh RF branch, merge in your branch and run the tests. just to rule out any strange merge behaviour. | 10:31 |
| malcc | BjornT: Thanks, I'll try that. pqm log extract here: https://devpad.canonical.com/~andrew/paste/fileyhMbAZ.html. Let me know if you really did mean the whole thing | 10:32 |
| SteveA | jamesh: hi | 10:44 |
| jamesh | SteveA: hi | 10:45 |
| SteveA | stub, jamesh: I'd like to do a quick infrastructure irc meeting | 10:45 |
| SteveA | when's a good time? | 10:45 |
| jamesh | I'd prefer a time before 8pm (midday UTC) | 10:48 |
| jamesh | earlier if it is on a Friday | 10:48 |
| SteveA | oh, I meant today | 10:48 |
| SteveA | just a quick informal catchup | 10:48 |
| jamesh | okay. Any time then :) | 10:48 |
| SteveA | ok, let's see what stub says | 10:49 |
| BjornT | malcc: i think i do need the whole pqm log. | 10:51 |
| malcc | BjornT: https://devpad.canonical.com/~andrew/paste/files7NCdF.html | 10:53 |
| SteveA | jamesh: meanwhile, do you have time for a pre-implementation review call? | 10:53 |
| jamesh | SteveA: okay | 10:54 |
| SteveA | try sip? | 10:54 |
| jamesh | sure | 10:54 |
| === jamesh fires up ekiga | ||
| SteveA | i'll call you | 10:55 |
| === civija [i=msabljic@193.198.206.5] has joined #launchpad | ||
| === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad | ||
| civija | hy guys! | 10:57 |
| civija | can you tell how to change my prefered e-mail address in launchpad? | 10:58 |
| carlos | civija: hi | 10:59 |
| civija | hi carlos | 10:59 |
| carlos | civija: Go to: https://launchpad.net/people/carlos/+editemails (change carlos with your launchpad name) | 10:59 |
| carlos | and select the one you want as the Contact Address | 10:59 |
| mpt | SteveA, back | 11:01 |
| civija | carlos: tnx! i've changed it | 11:02 |
| carlos | civija: you are welcome | 11:02 |
| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad | ||
| malcc | BjornT: Merging changes into a fresh branch from rocketfuel, the test still passes locally | 11:04 |
| BjornT | malcc: did you run just a subset of the tests, or 'make check_merge'? | 11:05 |
| malcc | BjornT: Just a subset. make check_merge tends to be non-terminating on my hardware | 11:05 |
| malcc | BjornT: I'll give it a go though | 11:06 |
| Ubugtu | New bug: #60190 in soyuz "Misleading email when uploads are UNAPPROVED" [Medium,Confirmed] http://launchpad.net/bugs/60190 | 11:11 |
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| seb128 | is it possible to edit a comment on launchpad? | 11:16 |
| mpt | seb128, no | 11:16 |
| seb128 | ok | 11:16 |
| === Spads [n=spacehob@217.205.109.249] has joined #launchpad | ||
| seb128 | I got a mail from an user saying he's getting spam since his email is listed by one comment on launchpad | 11:17 |
| seb128 | I was wondering if there was a way to drop it | 11:17 |
| BjornT | malcc: it's hard to say exactly what's wrong. what you could do is to insert a self.assertEquals(getSecurityPolicy(), PermissiveSecurityPolicy) in the failing test and send it off to pqm again. | 11:20 |
| malcc | BjornT: Thanks, I'll give that a try | 11:20 |
| BjornT | at least that will tell you whether something's wrong with the test setup | 11:24 |
| SteveA | mpt: hi | 11:27 |
| === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad | ||
| mpt | How do I return a custom HTTP code (e.g. 404) for a particular Launchpad page? | 11:35 |
| Ubugtu | New bug: #60195 in malone "May need to obfuscate email addresses in bug comments" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60195 | 11:35 |
| BjornT | mpt: in the view class: self.request.response.setStatus(404) | 11:38 |
| mpt | thanks BjornT | 11:38 |
| === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #launchpad | ||
| SteveA | mpt: why do you want to return a 404? | 12:15 |
| mpt | SteveA, 410 Gone for the calendar, so we don't get bazillions of "Sorry" pages showing up in Google | 12:15 |
| jamesh | or "402 Payment Required" | 12:15 |
| mpt | Launchpad 3.0, jamesh, Launchpad 3.0 | 12:15 |
| jamesh | it'd make a good april fools day joke for shipit ... | 12:16 |
| === mpt looks for other uses of self.request.response so that he won't have to ask another annoying question | ||
| SteveA | mpt: is it that you want to do a special 404 page? | 12:20 |
| SteveA | we have a particular way of doing that | 12:20 |
| mpt | oh, I can do it just in __init__ | 12:20 |
| SteveA | mpt: please have a call with jamesh about how to do this efficiently | 12:20 |
| SteveA | don't do anything in __init__ | 12:20 |
| mpt | that's what error.py does | 12:21 |
| jamesh | mpt: is the plan to make the calendar pages inaccessible or just not linked to? | 12:21 |
| SteveA | then it is wron | 12:21 |
| SteveA | g | 12:21 |
| mpt | Should I report a bug, or is that a one-line fix? :-) | 12:21 |
| SteveA | mpt: that depends. | 12:21 |
| mpt | jamesh, the latter. I have changed the template to include an explanation plus a download link. | 12:21 |
| SteveA | but please talk through what you want to do with james | 12:21 |
| SteveA | maybe by voice | 12:22 |
| SteveA | otherwise, you may take an inappropriate approach, and so it will have to be re-done after a code review | 12:22 |
| jamesh | mpt: so what page would the "Gone" response be for? | 12:22 |
| mpt | jamesh, any calendar page | 12:23 |
| mpt | calendar-view-*.pt, calendar-subscribe.pt, calendar-event-*.pt | 12:23 |
| jamesh | mpt: okay. I don't think Mark bothered with that for the bounty tracker pages. | 12:24 |
| mpt | jamesh, he did that several weeks ago, and Launchpad's bountry tracker currently features two bounties registered four days ago, so I don't think that's a particularly good example. | 12:25 |
| SteveA | mpt: I think this can be done in two stages | 12:25 |
| SteveA | 1. remove links to calendar | 12:25 |
| mpt | (Maybe I should hide the bounty tracker more thoroughly in this branch too?) | 12:25 |
| SteveA | 2. remove pages | 12:25 |
| SteveA | it's important to land 1 | 12:25 |
| SteveA | 2. is less important | 12:26 |
| SteveA | I don't really care if two or three users are a little confused | 12:26 |
| SteveA | I do care if 20 or 60 users are | 12:26 |
| SteveA | I'd like to see removing the calendaring have a simple low risk landing first | 12:26 |
| SteveA | that can get into the next rollout | 12:27 |
| mpt | I get the impression that many more people use the calendar than used the bounty tracker | 12:27 |
| mpt | no statistics to back that up, though | 12:27 |
| SteveA | so, they can still use it if they know the URL | 12:27 |
| SteveA | that's not a big deal | 12:27 |
| SteveA | it's okay for it to stay there, hidden, and we're not supporting it | 12:27 |
| SteveA | i'd rather your time was spent improving areas of launchpad we care about | 12:27 |
| SteveA | not areas of launchpad we currently don't care about | 12:28 |
| SteveA | in other words | 12:28 |
| SteveA | Don't polish the lack of a calendar! | 12:28 |
| SteveA | we can apply polish after all the 1.0 UI stuff is done | 12:28 |
| jamesh | If we don't want Google indexing certain parts of the site, a robots.txt file might be more appropriate | 12:29 |
| mpt | ok | 12:31 |
| SteveA | mpt: also, please do use the facility of pre-implementation calls to discuss implementation plans with a reviewer | 12:33 |
| SteveA | I like that you work on the python code in launchpad | 12:33 |
| SteveA | certain areas of the code are tricky in terms of infrastructure | 12:33 |
| SteveA | so I want you to seek guidance when you work in those areas | 12:33 |
| === xenru [n=Miranda@85.192.12.67] has joined #launchpad | ||
| Ubugtu | New bug: #60211 in launchpad "webapp/error.py uses self.request.response.setStatus() in __init__ and that's bad" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60211 | 12:40 |
| SteveA | thanks mpt. I commented on the bug. | 12:43 |
| carlos | stub: hi, around? | 12:44 |
| stub | carlos: yes | 12:45 |
| === SteveA --> lunch | ||
| carlos | stub: is there any way to know more or less at what time the language pack DB mirror is ready to use? | 12:45 |
| carlos | I would like to adjust the timing with the export scripts | 12:45 |
| mpt | jamesh, meanwhile, would you have time to review some pagetest changes? | 12:46 |
| jamesh | mpt: sure. | 12:46 |
| stub | It seems to be consistently finishing rebuilding at 4:15, so 4:45 or later is a safe bet. | 12:46 |
| mpt | jamesh, https://devpad.canonical.com/~jamesh/pending-reviews/mpt/launchpad/2006-09-compatibility/full-diff | 12:46 |
| carlos | stub: London time? | 12:46 |
| stub | carlos: I can create a file after the rebuild if you want stating that the rebuild is complete | 12:46 |
| jamesh | mpt: you have a conflict | 12:46 |
| stub | carlos: yes - london time | 12:46 |
| mpt | jamesh, I was just going to say, it contains one six-line conflict, for which I'll be using the MERGE-SOURCE | 12:47 |
| carlos | stub: as you wish, but I will not use it yet (I don't have too much time to expend on this) I have the logs anyway to detect any problem there... | 12:47 |
| carlos | stub: I will start at 5:00 | 12:47 |
| carlos | stub: thanks | 12:47 |
| jamesh | mpt: well, you should integrate the change from TREE (products/firefox/milestones => products/firefox/trunk) | 12:47 |
| mpt | oh. of course. | 12:48 |
| stub | carlos: it can be rebuilt earlier if you need, but then it will be using the previous days backup. | 12:48 |
| jamesh | mpt: as a general comment, your page test modifications make things harder to debug in the failure case | 12:49 |
| carlos | stub: no, that's good enough, thanks | 12:49 |
| jamesh | mpt: before, we'd get a diff of the contents vs. what was expected. After the change it'll be a simple True vs. False | 12:50 |
| mpt | jamesh, the problem is that the expected items are present in a particular order on mainline, and in a different order on 1.0 | 12:51 |
| mpt | I suppose the other option is to print browser.contents twice, and pick out one thing each time | 12:52 |
| mpt | (or three times, or however many) | 12:52 |
| jamesh | mpt: the alternative is to use BeautifulSoup to extract a portion of the page and check that -- we really need a helper for some common cases here ... | 12:53 |
| mpt | jamesh, that wouldn't really help in this case, because the markup is very different too | 12:53 |
| jamesh | no common element IDs or classes? | 12:53 |
| mpt | no | 12:53 |
| jamesh | we'd still be eliding content | 12:54 |
| mpt | We have very few IDs, and the classes are all different | 12:54 |
| mpt | I suppose I could add IDs, but putting IDs in a page just for test purposes seems odd | 12:54 |
| jamesh | probably not for a simple change like this. | 12:55 |
| mpt | not odd, or not appropriate? :-) | 12:56 |
| jamesh | well | 12:57 |
| lifeless | adding ids for testing is often appropriate | 12:57 |
| lifeless | I think jameshs point was about the size of the effort/reward ratio here | 12:58 |
| jamesh | what I mean is that (1) it would be good to have some helpers available for things like this, (2) I am not expecting you to write those helpers for this change and (3) it isn't worth holding up your merge til those helpers are available | 12:58 |
| jamesh | mpt: your branch looks okay to merge r=jamesh. The tests you've converted were not the most informative to start with, so it probably doesn't affect debugability much | 01:02 |
| mpt | thanks jamesh | 01:02 |
| malcc | BjornT: I added your suggested assert to both tests in that class. Both passed locally, both failed on PQM with AssertionError: <class 'canonical.launchpad.webapp.authorization.LaunchpadSecurityPolicy'> != <class 'zope.security.simplepolicies.PermissiveSecurityPolicy'> | 01:02 |
| malcc | BjornT: I'm still not able to run make check_merge locally, so this may be a one test vs. entire suite problem, rather than different machines, arches or whatever | 01:03 |
| lifeless | malcc: why cant you run check_merge locally ? | 01:05 |
| malcc | lifeless: Swap death. I think I need to order some more RAM | 01:05 |
| malcc | At least it looks like swap death, things stop, much processor time is in wait state | 01:06 |
| lifeless | vmstat will tell you | 01:06 |
| BjornT | malcc: ok. i suggest sending an email about this to the list, CC stub. my guess is that the layers are setUp:ed and tearDown:ed incorrectly, but i'm not sure. could be something else as well. the pqm log didn't give me any clue. | 01:08 |
| === mpt cries as his girlfriend utterly fails to figure out how to confirm a bug in Launchpad | ||
| lifeless | 'your girlfriend sucks dude' | 01:12 |
| mpt | Enough with the double entendres | 01:13 |
| malcc | Does *anybody* find the magic controls hidden behind what looks like a link to the product, without being told? | 01:14 |
| mpt | malcc, probably 2 or 3 percent do | 01:14 |
| mpt | (wild-ass guess) | 01:14 |
| jamesh | more people guessed when we had the expander arrow | 01:17 |
| jamesh | lifeless: I think I've got the dl.openafs.org product-release-finder bug fixed, btw | 01:19 |
| lifeless | jamesh: fantastic | 01:19 |
| jamesh | this time it'll work for sure. | 01:19 |
| lifeless | hhahaha | 01:20 |
| lifeless | but I hope you are right | 01:20 |
| jamesh | the change should also greatly reduce how much of a site it walks looking for releases | 01:20 |
| === civija [i=msabljic@193.198.206.5] has left #launchpad [] | ||
| mpt | canonical.testing.layers.LayerInvariantError: Component architecture should not be available | 01:30 |
| === malcc -> Lunch | ||
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| BjornT | mpt: probably bug 55041 | 01:33 |
| mpt | BjornT, so it is | 01:35 |
| mpt | so I'll run all tests overnight instead | 01:37 |
| BjornT | mpt: another solution is to try to be a bit more specific which tests you want to run | 01:42 |
| BjornT | for example, instead of running: python test.py -f --test=shipit | 01:43 |
| BjornT | you could divide it into to test runs: python test.py -f --test='pagetests.*shipit.*' | 01:43 |
| BjornT | and: python test.py -f --test='doc/.*shipit.*' | 01:44 |
| BjornT | and possible a few more like that if there are tests in other places you want to run. | 01:44 |
| === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| === aa_ [n=ali@pida/aa] has joined #launchpad | ||
| aa_ | hi, are we allowed to delete stuff like branches? | 01:54 |
| aa_ | (oops we are not in a meeting are we?) | 01:54 |
| mpt | aa_, that isn't implemented yet, sorry | 01:57 |
| aa_ | mpt: fair enough | 01:57 |
| aa_ | bzr is crushing my testicles :) | 01:58 |
| mpt | aa_, subscribe to bug 34540 if you want to be notified of any progress | 01:58 |
| Ubugtu | Malone bug 34540 in launchpad-bazaar "cannot delete a branch" [High,Confirmed] http://launchpad.net/bugs/34540 | 01:58 |
| aa_ | mpt: ok, thanks | 01:59 |
| ddaa | aa_: however you can rename branches, so you can reuse the object for something else instead of registering new branches. | 01:59 |
| ddaa | that's a workaround, but it's better that it used to be | 01:59 |
| ddaa | aa_: also, I'd be interested in why you want to delete a branch. There are some other bugfixes in the plans that might fix the root cause of your problem. | 02:00 |
| aa_ | ddaa: I want to move back to svn | 02:01 |
| aa_ | a sorry state I know | 02:01 |
| ddaa | sounds a weird thing to want to do, but you must have compelling reasons | 02:01 |
| aa_ | well, no one ever seems to be able to get my source code | 02:01 |
| ddaa | aa_: I think the best match for what you want to do is to set the branch status to "ABANDONED" and explains where the code is now hosted in the whiteboard of the branch. | 02:02 |
| aa_ | sounds good | 02:03 |
| aa_ | well, I used to host an http mirror of the branch myself, before the branch backup thing was working | 02:03 |
| aa_ | but I think launchpad does that now | 02:03 |
| ddaa | yeah, mirroring of external branches was one of the initial features of the bzr support in launchpad | 02:04 |
| === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad | ||
| === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| cprov | salgado: ping | 02:27 |
| salgado | cprov, pong | 02:27 |
| aa_ | well, thanks for the advice everyone, launchpad looks better every day, keep it up :) | 02:28 |
| cprov | salgado: did you check the last diff of my small-fixes (-backports fix) ? | 02:28 |
| === aa_ [n=ali@pida/aa] has left #launchpad [] | ||
| === carlos -> lunch | ||
| salgado | cprov, not yet | 02:30 |
| salgado | I'll check today | 02:30 |
| cprov | salgado: fair enough, it's blocking some guys to fix stuff in dapper, thank you | 02:31 |
| lifeless | SteveA: I was going to drop by for the meeting, but I've been up for 15 hours, body is telling me it needs sleep now | 02:34 |
| lifeless | SteveA: sorry | 02:34 |
| === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad | ||
| Ubugtu | New bug: #59573 in ubiquity "The installer crashed" [Untriaged,Needs info] http://launchpad.net/bugs/59573 | 02:40 |
| salgado | jamesh, around? | 02:43 |
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| === niemeyer [n=niemeyer@201.23.160.13] has joined #launchpad | ||
| === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad | ||
| salgado | stub, around? | 03:12 |
| stub | salgado: Can I get a 2 minute review of https://devpad.canonical.com/~andrew/paste/fileOV33Nk.html ? | 03:12 |
| stub | :-) | 03:12 |
| salgado | heh | 03:12 |
| salgado | hmmm. firefox is failing to load that | 03:13 |
| stub | works for me... | 03:14 |
| salgado | I restarted and now it works | 03:14 |
| salgado | stub, do you know if that keyring trust analyzer was ever run in production? | 03:15 |
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| stub | salgado: No, it never was. It got blocked on creating the initial trusted set of keyrings IIRC. | 03:17 |
| salgado | stub, have you tried writing an old-style pagetest with no Referer line, to see if we get the referer set to None in the session? | 03:23 |
| === Spads [n=spacehob@host-87-74-19-213.bulldogdsl.com] has joined #launchpad | ||
| stub | No, but I think the current tests are good enough. They will still detect breakage, and the comment explains why the test is slightly screwed. | 03:26 |
| salgado | stub, I guess it's not possible to have a non-ASCII referrer, right? | 03:31 |
| stub | I stuck 'replace' in there just incase | 03:31 |
| salgado | I'm concerned that any unexpected problems on this code will prevent new users from using launchpad completely | 03:31 |
| === bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad | ||
| stub | That should stop the decode call ever raising an exception (?) | 03:32 |
| salgado | should it? can you add with a test with a non-ASCII referrer just to make sure? | 03:33 |
| salgado | s/with// | 03:33 |
| spiv | salgado: yes, it should; that's what that docs for {str,unicode}.{encode,decode} say (see sections 2.3.6.1 and 4.9.1 of the python library reference). | 03:37 |
| stub | I'll add a test demonstrating crazy encoded referrer headers anyway. | 03:39 |
| SteveA | lifeless: meeting? | 03:39 |
| SteveA | lifeless: maybe you were confused about the day of the week? | 03:40 |
| spiv | SteveA: see comment from him on this channel a little over an hour ago | 03:40 |
| === bradb_ [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad | ||
| spiv | He's gone to sleep | 03:40 |
| SteveA | spiv: I read the comment addressed to me | 03:40 |
| spiv | Oh, right. | 03:40 |
| SteveA | I wasn't expecting a meeting today anyway | 03:40 |
| spiv | I misunderstood what you meant by "meeting?" | 03:40 |
| SteveA | ah, right | 03:41 |
| SteveA | as in "what meeting?" | 03:41 |
| spiv | That's clear now :) | 03:41 |
| === bradb_ [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad | ||
| === bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad | ||
| SteveA | spiv: hi | 04:14 |
| SteveA | spiv: still around? | 04:14 |
| spiv | SteveA: yeah, but not for much longer... | 04:15 |
| Ubugtu | New bug: #60235 in launchpad "Disabling mirrors when they fail a single probe is not fair" [High,Confirmed] http://launchpad.net/bugs/60235 | 04:15 |
| === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad | ||
| SteveA | spiv: you'll be working with lifeless tomorrow? | 04:15 |
| spiv | Yep | 04:15 |
| spiv | After I get the stitches removed from the back of my head... | 04:16 |
| SteveA | spiv: would you ask him to give an estimate of when he'll be able to do the bzr code update in RF that ddaa asked for? | 04:16 |
| spiv | Ok. | 04:16 |
| SteveA | thanks | 04:16 |
| ddaa | SteveA: thanks | 04:16 |
| === spiv puts a big tomboy note in the middle of the relevant workspace to make sure I don't forget | ||
| SteveA | thanks! | 04:18 |
| === Spads [n=spacehob@host-87-74-19-213.bulldogdsl.com] has joined #launchpad | ||
| === lfittl [n=lfittl@193.170.41.114] has joined #launchpad | ||
| === lbm [n=lbm@82.192.173.92] has joined #launchpad | ||
| kiko-zzz | morning | 04:33 |
| kiko | hello hello | 04:33 |
| SteveA | hello america | 04:34 |
| SteveA | hello south america | 04:34 |
| kiko | how's it going? | 04:35 |
| SteveA | yeah, top | 04:36 |
| === xenru|clone [n=Miranda@85.192.13.219] has joined #launchpad | ||
| === bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad | ||
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| matsubara | https://launchpad.net/products/launchpad/+bug/60211 is forbidden for me but it was initally reported as a public bug. | 04:48 |
| matsubara | did mpt remove everyone from the subscribers list? | 04:49 |
| kiko | matsubara, let me check | 04:51 |
| === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad | ||
| kiko | hey malcc, cprov-afk | 04:55 |
| malcc | Hey kiko | 04:55 |
| kiko | how's the surf? | 04:55 |
| === mvo [n=egon@p54A6572B.dip.t-dialin.net] has joined #launchpad | ||
| malcc | Not sure, I'm a long way from any useful surfing locations here | 04:56 |
| malcc | On a separate note, soyuz development is going quite well :) | 04:57 |
| kiko | as usual! | 04:57 |
| malcc | My branch still isn't merged though... | 04:57 |
| kiko | did you find out what was up yesterday? | 04:57 |
| malcc | Bjorn made a suggestion, which showed beyond doubt that I'm not getting the same security manager when running all tests on PQM | 04:57 |
| kiko | SteveA, can you help malcc? this is really blocking us | 04:58 |
| malcc | And I've sent an email out to the launchpad list with my failure | 04:58 |
| kiko | you are a * | 04:58 |
| malcc | An asterisk? :) | 04:58 |
| kiko | that too | 04:59 |
| malcc | Or did you mean a ? | 05:00 |
| kiko | I am against unicode | 05:00 |
| kiko | matsubara, did you see this SMTPRecipientsRefused oops today? really neat | 05:01 |
| matsubara | kiko: glanced over | 05:01 |
| kiko | matsubara, validation error? | 05:01 |
| siretart | that imported branch looks strange: https://launchpad.net/people/vcs-imports/+branch/xine-lib/head - the latest 16 revisions date from 2001, but then there come commits from yesterday | 05:02 |
| siretart | how comes? | 05:02 |
| SteveA | kiko, malcc: what's up? the test failure you posted to the list? | 05:03 |
| matsubara | kiko: looks like | 05:03 |
| kiko | SteveA, yeah. pretty serious for us | 05:03 |
| SteveA | I don't know what the answer could be. It's really a stub issue. | 05:04 |
| === kiko cries | ||
| SteveA | malcc: have you merged from RF recently? | 05:05 |
| SteveA | and also check you've updated all your subtrees | 05:05 |
| SteveA | like zope, in particular | 05:05 |
| malcc | SteveA: Yup, and Bjorn also suggested taking a fresh rf and merging from my branch. And yes, I've got the latest other bits :) | 05:05 |
| === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad | ||
| Nafallo | siretart: looks like a ddaa question ;-) | 05:06 |
| malcc | I suspect I'd be able to reproduce the issue locally if I had enough RAM to run all the tests | 05:06 |
| === ddaa looks | ||
| ddaa | siretart: yes it does look weird, yes it's expected behaviour, yes it's because CVS sucks | 05:08 |
| SteveA | malcc: you shouldn't need to run all the tests | 05:08 |
| SteveA | malcc: because they run in a separate process | 05:08 |
| SteveA | malcc: running all the launchpad tests should be enough. try python test.py canonical | 05:08 |
| malcc | SteveA: Willdo | 05:09 |
| ddaa | siretart: those "Filler changeset" commits are here to emulate the CVS notion of "default branch" which affects the result of checking out HEAD but is orthogonal to normal history. | 05:09 |
| siretart | ddaa: will those 'filler changesets' always be the latest revisions? | 05:10 |
| ddaa | siretart: no, when further commits are made to other files, the filler changesets will stay where they are in history | 05:10 |
| siretart | ah, so the import just finished today? | 05:10 |
| kiko | matsubara, yeah, a validation issue. interesting one. it will require some manual intervention once fixed.. do you think that's really a valid email address? | 05:11 |
| ddaa | siretart: yes, it completed very recently after a fixed on one-letter bug. | 05:11 |
| siretart | lucky :) | 05:11 |
| siretart | thanks for all ddaa! :) | 05:11 |
| salgado | kiko, why manual intervention? that email is not registered in launchpad | 05:12 |
| ddaa | It is my duty to please my users ;) | 05:12 |
| kiko | salgado, yeah, I now understand the traceback. just a token. | 05:12 |
| matsubara | kiko: This domain cannot be registered because it contravenes the Nominet UK | 05:13 |
| matsubara | naming rules. The reason is: | 05:13 |
| matsubara | third-level domains may neither start nor end with a hyphen. | 05:13 |
| kiko | matsubara, :) | 05:13 |
| kiko | it was a typo btw. | 05:13 |
| kiko | malcc, do other ftests depend on the PermissiveSecurityPolicy, I wonder? | 05:14 |
| malcc | kiko: When Jamesh suggested I use the LaunchpadZopelessLayer to avoid the need for login etc., he didn't sound like he was describing anything experimental | 05:17 |
| malcc | kiko: A few other tests use that layer, but it's hard to say immediately whether they rely on the security aspects of it | 05:17 |
| BjornT | kiko: all tests in the ZoplessLayer should use PermissiveSecurityPolicy since that's what scripts use. | 05:18 |
| === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has left #launchpad [] | ||
| ddaa | SteveA: kiko: any of you want to rs=him the removal of utilities/{library-cut-tails.py,library-relink.py,arch} from launchpad? | 05:54 |
| kiko | does nobody use them? | 05:54 |
| ddaa | kiko: dude... they are user helpers for arch/baz | 05:54 |
| ddaa | if somebody on the team still use them, he has way bigger problems! | 05:55 |
| kiko | I have no idea what they are for | 05:55 |
| kiko | go ahead and nuke them then | 05:55 |
| ddaa | kiko: okay, rs=kiko then | 05:55 |
| ddaa | same applies to utilities/rocketsync | 05:56 |
| ddaa | utilities/rocketmeld | 05:57 |
| ddaa | utilities/refuel | 05:57 |
| ddaa | utilities/launch | 05:57 |
| ddaa | crazy that stuff that depends on the launchpad code being hosted on baz has stayed around that long | 05:58 |
| === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad | ||
| kiko | well, it's just the matter that few people use bzr rm | 06:01 |
| ddaa | I'm way happy to do it. It's just going to large a diff to be [trivial] | 06:03 |
| matsubara | kiko: what about bug 60211? Could you subscribe LP-devel to it? | 06:04 |
| kiko | done. | 06:05 |
| matsubara | kiko: thanks | 06:05 |
| malcc | SteveA: Success, in that test.py -vv canonical has reproduced the problem locally | 06:40 |
| === merriam [n=merriam@84-12-185-157.dyn.gotadsl.co.uk] has joined #launchpad | ||
| SteveA | malcc: great | 06:44 |
| SteveA | malcc: depending how late you're working tonight, you might be best off doing something different, and working with stu tomorrow morning | 06:46 |
| malcc | SteveA: Yes, I'm not spending any significant time on this now, until an expert can shed some light for me | 06:46 |
| === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad | ||
| === seb128 [n=seb128@ANancy-151-1-73-182.w81-49.abo.wanadoo.fr] has joined #launchpad | ||
| === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad | ||
| Ubugtu | New bug: #60257 in rosetta "sylpheed-claws-gtk2 translation template" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60257 | 07:58 |
| kiko | carlos, do you think OOPS-255D527 is caused by a race condition? | 07:59 |
| Ubugtu | https://chinstrap.ubuntu.com/~jamesh/oops.cgi/255D527 | 07:59 |
| salgado | mpt, I guess you're not around, right? | 08:00 |
| carlos | kiko: well, that's the NameNotAvailable error but with the right exception | 08:01 |
| kiko | carlos, but... why is it still happening? | 08:02 |
| carlos | and at this point... I would appreciate that someone else take a look to that code | 08:02 |
| kiko | :) | 08:02 |
| carlos | becuase I think I'm handling the only corner case that would cause such exception | 08:02 |
| carlos | I was not able to reproduce it in our development tree | 08:03 |
| carlos | so yes, It smells like a race condition | 08:03 |
| carlos | at least is the only explanation I can think on atm | 08:03 |
| kiko | it's a race condition but I'm not yet sure where. carlos could you look at the query log to see if anything weird is happening? | 08:03 |
| carlos | sure | 08:03 |
| carlos | kiko: hmm, wait, seems like it's not exactly the same error... but another path quite similar that could be fixed in the same way.... | 08:07 |
| carlos | kiko: forget that, I was looking at an old tree.... | 08:09 |
| kiko | bradb, before landing any more code, please reply to my email and let's plan for fixing up targeting. | 08:09 |
| bradb | kiko: I'm replying to it now. | 08:09 |
| kiko | okay. | 08:09 |
| carlos | kiko: ok, confirmed, now that I checked it with latest code, seems like it's the same pattern I fixed last week | 08:16 |
| carlos | kiko: I fixed POFile's POMsgSet creation, this time is POTemplate's POTMsgSet creation | 08:17 |
| kiko | ah! | 08:17 |
| carlos | kiko: same kind of fix should be enough to 'kill' it | 08:17 |
| carlos | I will do it myself, don't worry | 08:18 |
| kiko | wonderful, thanks carlos. | 08:18 |
| carlos | but I'm still not able to reproduce it in our local system | 08:18 |
| kiko | not even with reloads? | 08:19 |
| carlos | I can test that path better (I wrote tests), but what I saw on staging and on production is not exactly what the test is designed to 'force' | 08:19 |
| carlos | the test assumes that someone submitted a form after we modified the imported .pot file | 08:19 |
| kiko | I thought that the problem was a submit, stop, submit, but perhaps it's not form-dependent. | 08:19 |
| carlos | but I got that error on staging without a new .pot import which would be a cache issue.. | 08:19 |
| kiko | so load the form, submit, and then submit again the same form. | 08:19 |
| carlos | kiko: that's not possible unless some cache issues are involved | 08:20 |
| carlos | the code is quite simple, we check whether the entry exists if it doesn't exists, we try to create it | 08:20 |
| carlos | there is just once corner case that doesn't follow that rule, the new .pot file being imported between the form load and its submission | 08:21 |
| carlos | and that's what I fix, that corner case, but I'm sure is not the issue we get | 08:22 |
| carlos | kiko: perhaps it's also related with something you told me some time ago about using IPOTemplate.__getitem__ and IPOFile.__getitem__ | 08:22 |
| carlos | I'm moving to use proper methods instead of those special ones. If the __getitem__ usage introduces some unexpected behaviour that I'm not aware of... | 08:23 |
| kiko | I wish I could remember that! :) | 08:23 |
| carlos | kiko: well, you asked me to stop using __getitem__, __len__ and others | 08:23 |
| carlos | and use explicit methods instead | 08:24 |
| kiko | well, because they are confusing, not because they are flawed.. | 08:24 |
| carlos | you raised that issue while working on the SQLObject Snapshots | 08:24 |
| carlos | kiko: I'm not saying they are flawed, just that perhaps they have a behaviour I'm not expecting in this concrete situation... | 08:24 |
| carlos | anyway, the code is much more clear if we stop using __getitem__ | 08:25 |
| kiko | right :) | 08:25 |
| === ddaa puts another arch-removing patch up for review | ||
| carlos | in this concrete situation, so it's not a bit deal | 08:25 |
| carlos | s/bit/big/ | 08:25 |
| carlos | kiko: I will fix that one and ask for another cherrypick | 08:26 |
| carlos | kiko: thanks for noting me it | 08:26 |
| kiko | carlos, it's only happened once, I think, but if you think it's worth it, sure. | 08:26 |
| kiko | no problemo! | 08:26 |
| carlos | well, it's part of the previous fix | 08:26 |
| carlos | or bug | 08:26 |
| carlos | as you wish to call it :-P | 08:26 |
| bradb | kiko: Can I land the tinytext fix having just added a style="font-size: 100%" to the span? | 08:56 |
| kiko | that sounds like a hack.. is that the right way to fix that? | 08:56 |
| bradb | Well, it's using the class="discreet lesser" thing, like you used for the "This description was updated..." text below the desc, but 85% is too small for this specific tag. | 08:57 |
| kiko | bradb, the approve/decline link have the right size. | 08:57 |
| bradb | hm, 100% for the rest of the text, bug 85% for approve/decline looks pretty ugly | 08:58 |
| Ubugtu | Malone bug 85 in rosetta "We need a way to publish translators' email address" [Medium,Fix released] http://launchpad.net/bugs/85 | 08:58 |
| bradb | blah blah | 08:58 |
| kiko | right, that's why I'm saying there's something else wrong. | 08:59 |
| bradb | kiko: why not have it all just 100%? | 08:59 |
| kiko | bradb, I have no clue what needs to be done as long as it looks good. | 09:01 |
| bradb | you said it was too small and unreadable! | 09:01 |
| === bradb makes it 100% then :P | ||
| bradb | it will be not small and more readable then. it looks fine, imho | 09:01 |
| kiko | it was too small an unreadable | 09:04 |
| kiko | do you want a screenshot? | 09:04 |
| bradb | it looked okay to me, but i imagine it could get nano at high res | 09:05 |
| kiko | the letters deformed, it was impossible to actually see what was written | 09:06 |
| === LeeJunFan_ [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| === merriam [n=merriam@84-12-84-123.dyn.gotadsl.co.uk] has joined #launchpad | ||
| === xenru [n=Miranda@85.192.13.234] has joined #launchpad | ||
| === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #launchpad | ||
| === lbm [n=lbm@82.192.173.92] has joined #launchpad | ||
| === glatzor [n=sebi@ppp-82-135-82-91.dynamic.mnet-online.de] has joined #launchpad | ||
| Ubugtu | New bug: #60280 in soyuz ""source" added to Architectures: in Release file" [High,Confirmed] http://launchpad.net/bugs/60280 | 10:00 |
| kiko | ah. so that was the bug. | 10:01 |
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad | ||
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| === AlinuxOS [n=alinux@d81-211-234-247.cust.tele2.it] has joined #launchpad | ||
| kiko | matsubara, did you report a bug about the tag advanced search crasher? | 10:51 |
| matsubara | yes | 10:51 |
| matsubara | kiko: ^ | 10:51 |
| kiko | which bug is that may I ask | 10:51 |
| matsubara | kiko: bugs 59972 59975 | 10:52 |
| Ubugtu | Malone bug 59972 in malone "Tag search field needs better validation for non-alphanumeric characters" [High,Confirmed] http://launchpad.net/bugs/59972 | 10:52 |
| matsubara | bug 59975 I think it's the same issue explained by jamesh in his email with subject: LaunchpadFormView.validate() gotcha | 10:54 |
| Ubugtu | Malone bug 59975 in malone "Edit bug tag form needs to cope with invalid values in tag field." [High,Confirmed] http://launchpad.net/bugs/59975 | 10:54 |
| kiko | matsubara, ah, so underscores are known to break it. | 10:58 |
| lifeless | morning | 10:58 |
| lifeless | SteveA: I thought it was thursday | 10:58 |
| matsubara | kiko: I didn't test all non-alphanumeric chars but some like: @;,#$ break it | 10:59 |
| kiko | underscores too. | 10:59 |
| kiko | okay thanks! | 10:59 |
| kiko | matsubara, do you figure what's this cmp() recursion crasher? | 11:00 |
| matsubara | kiko: not yet. | 11:02 |
| kiko | it appears that a bug is somehow finding itself in its list of dupes, doesn't it? | 11:02 |
| === j-a-meinel [n=j-a-mein@adsl-67-37-234-251.dsl.chcgil.ameritech.net] has joined #launchpad | ||
| bradb | Is there a way to invalidate a cachedproperty? | 11:05 |
| bradb | foo.bar.invalidate() or something weird like that. | 11:05 |
| j-a-meinel | ping, anyone know why a newly pushed Launchpad branch (pushed to sftp://bazaar.launchpad.net) wouldn't show up in the rest of the listings? 'bzr log sftp://' works | 11:06 |
| bradb | kiko: do you want to discuss siamese bugtasks? | 11:07 |
| kiko | bradb, no, there is no way to invalidate it automatically. you can however specify how the property is cached and then clear it manually. | 11:09 |
| bradb | ok | 11:09 |
| kiko | do a grep for @cachedproperty( to see what I mean | 11:10 |
| bradb | well, basically, there are three ways i can think of doing siamese bugtasks: 1. through create/change event handlers, 2. a setStuff API 3. a .siamese_twin cachedproperty | 11:10 |
| bradb | 1. has issues we've already seen before, like the current possible inconsistencies that can happen with bug privacy | 11:11 |
| bradb | 2. is a friggin' huge change | 11:11 |
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| kiko | well | 11:12 |
| bradb | 3. is perhaps the least intensive, with a cacheproperty that gets cleared when a currentrelease task is created | 11:12 |
| kiko | cachedproperty aren't cached in the DB, bradb. | 11:12 |
| matsubara | kiko: exactly. https://devpad.canonical.com/~andrew/paste/fileCE0Dnx.html | 11:13 |
| kiko | matsubara, so.. a dupe cycle? | 11:13 |
| matsubara | kiko: looks like | 11:13 |
| kiko | how did that happen? a race? | 11:13 |
| kiko | or something else I wonder.. | 11:14 |
| matsubara | kiko: I think so. perhaps people were triaging at the same time. | 11:14 |
| bradb | kiko: I didn't think they were cached in the DB. What issue are you getting at? | 11:14 |
| kiko | matsubara, can you reproduce? | 11:14 |
| kiko | bradb, I didn't get your cachedproperty suggestion, then. | 11:15 |
| bradb | kiko: Well, here's the strawman, because there are some things I will figure out only when I start writing the code: | 11:15 |
| matsubara | kiko: no | 11:17 |
| bradb | 1. add a siamese_twin cachedproperty to bugtasks. 2. this returns the current release task, or None. 3. it's invalidated when a current release task is created (because we don't want the cached prop to keep returning None, we want it to start returning the current DR task at that point), 4. we modify BugTask._SO_setValue to check for a siamese_twin, and call its _SO_setValue too, if applicable. | 11:17 |
| bradb | the cached prop is to, hopefully, minimize how much we hit the DB in checking if there's a siamese twin | 11:18 |
| kiko | bradb, that sounds like too much magic. | 11:19 |
| bradb | kiko: the point of this solution is to not require modifying existing callsites. | 11:19 |
| kiko | I think option 2. is the right option, and I have said that many times now | 11:19 |
| kiko | modifying the callsites is necessary -- just needs to be acknowledged. | 11:20 |
| kiko | the callsites are broken anyway | 11:20 |
| bradb | urgh. that will be a truly huge change. :/ | 11:20 |
| kiko | they should not really be modifying the bug directly | 11:20 |
| kiko | we knew this already when we embarked on this project... | 11:20 |
| kiko | at any rate | 11:20 |
| bradb | and inconsistent with all our other object APIs | 11:20 |
| bradb | AFAIK | 11:20 |
| kiko | I suggest you have a call with steve | 11:20 |
| kiko | to talk to him and see what he thinks | 11:21 |
| kiko | I don't think that's an important consistency | 11:21 |
| kiko | and there are other objects which are not modified directly (the queue objects, for instance) | 11:21 |
| kiko | but have the call with steve and he may have a great idea | 11:21 |
| kiko | he often does | 11:21 |
| bradb | indeed | 11:21 |
| bradb | SteveA: around? :) | 11:22 |
| === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad | ||
| === panickedtest [n=travis@cdm-75-109-115-91.asbnva.dhcp.suddenlink.net] has joined #launchpad | ||
| === panickedtest is now known as panickedthumb | ||
| === j-a-meinel [n=j-a-mein@adsl-67-37-234-251.dsl.chcgil.ameritech.net] has left #launchpad [] | ||
| bradb | https://launchpad.net/distros | 11:36 |
| bradb | "Soyuz" is the part of Launchpad that keeps track of the applications published in different distributions. It allows you to track, for example, the bugs in a distribution. | 11:36 |
| bradb | that makes it sound like Soyuz is Malone :) | 11:36 |
| kiko | gross | 11:51 |
| Nafallo | bradb: and it isn't? ;-) | 11:54 |
| bradb | heh | 11:55 |
| bradb | kiko: so the issue about allowing you to nominate for a target that already has a task... | 11:56 |
| bradb | kiko: it's because IBug.isNominatedFor assumes everything must have a nomination /before/ a task is created. | 11:57 |
| bradb | so for older bugs that don't have noms, it looks like all the releases can be nominated, to this method | 11:57 |
| bradb | so, i can think of a couple options | 11:58 |
| bradb | 1. data migration, to create approved noms for all existing DR tasks | 11:58 |
| bradb | 2. make the code deal with this pre-nomination data, instead | 11:58 |
| bradb | #2 seems like a safer option, IMHO | 12:00 |
| bradb | particularly if we're thinking of growing different perms systems for release management, noms vs. no-noms, etc. | 12:01 |
| mdz | mpt: what should Ubuntu print on the screen for the few seconds before the graphical progress display comes up? | 12:07 |
| mdz | mpt: it currently says "Booting the operating system now" and I want to get rid of the jargon | 12:07 |
| kiko | bradb, I don't quite understand why you assume that everything must have a nomination. what about bugs that had no nomination process, but were opened automatically? seems like you're assuming too much.. | 12:08 |
| bradb | kiko: the bug /is/ that assumes everything has a nomination! | 12:09 |
| bradb | so, i'm not saying it's a good thing that it assumes that | 12:10 |
| kiko | ah. :) | 12:10 |
| kiko | it's just that you said "pre-nomination data" | 12:10 |
| bradb | so, it sounds like we agree on #2 | 12:10 |
| kiko | whereas there is data which is post-"nomination the feature" that will still trigger this, right? | 12:10 |
| bradb | kiko: well, the code creates a nom and auto-approves it if the person has the privs to do that | 12:11 |
| kiko | bradb, what about new bugs filed? | 12:12 |
| bradb | kiko: a new bug isn't related to a release (explicitly), so there are no noms created at that point. | 12:12 |
| kiko | ah, right. | 12:13 |
| kiko | I guess ISWYM. | 12:13 |
| kiko | well... | 12:13 |
| kiko | if you are going to do #2.. then | 12:13 |
| kiko | does it still make sense to create the nom and auto-approve it? | 12:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!