| === doko_ [n=doko@dslb-088-073-076-102.pools.arcor-ip.net] has joined #launchpad | ||
| ryanakca | how do you remove a remote bug watch thingy? ex: https://launchpad.net/products/amarok/+bug/64573 is watching the same remote bug twice | 12:25 |
|---|---|---|
| Ubugtu | Malone bug 64573 in amarok "Amarok crashes on iPod connection" [Unknown,Unknown] | 12:25 |
| === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad | ||
| mpt | Goooooooooooooooooooood morning Launchpadders! | 12:31 |
| === AlinuxOS [n=alinux@d83-190-23-235.cust.tele2.it] has joined #launchpad | ||
| === AlinuxOS [n=alinux@d83-190-23-235.cust.tele2.it] has joined #launchpad | ||
| === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad | ||
| === jml [n=jml@ppp105-240.lns1.hba1.internode.on.net] has joined #launchpad | ||
| jamesh | mpt: I did a bit of work on the new FormLayout stuff | 03:28 |
| jamesh | mpt: a few screenshots are here: https://devpad.canonical.com/~jamesh/images/ | 03:29 |
| jamesh | the positioning of the textarea on formlayout-productseries-edit.png one looks a bit weird to me | 03:30 |
| jamesh | but maybe left aligning all the labels would fix that | 03:31 |
| jamesh | also, I am not sure where the "required" markers should go with this layout | 03:31 |
| === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad | ||
| mpt | jamesh, that looks very cool | 04:04 |
| mpt | well done! | 04:04 |
| mpt | You're right about the textarea | 04:05 |
| mpt | but I don't think there's any better solution | 04:05 |
| mpt | The usual solution should be to make the textarea either the first or the last field in the form. | 04:06 |
| mpt | So all the aligned elements are together, and all the textareas are together. | 04:06 |
| jamesh | The alignment of formlayout-new-distro-task.png also comes out a bit weird since the fields are laid out in two groups | 04:09 |
| jamesh | not sure how much of a problem that is though | 04:09 |
| jamesh | what do you think about placement of the "(required)" text though? | 04:09 |
| mpt | I think it should be removed, in favor of "Foo (optional):" labels for optional fields | 04:12 |
| mpt | see bug 39142 | 04:13 |
| Ubugtu | Malone bug 39142 in launchpad "Checkboxes should not be flagged as 'required'" [Medium,Confirmed] http://launchpad.net/bugs/39142 | 04:13 |
| jamesh | alright. Same question then: where do you think the "(optional)" labels should be placed? | 04:14 |
| mpt | "Foo (optional):" | 04:15 |
| === AstralJava [n=jaska@cm-083-102-068-117.lohjanpuhelin.fi] has left #launchpad [] | ||
| === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad | ||
| === stub [n=stub@ppp-58.8.1.171.revip2.asianet.co.th] has joined #launchpad | ||
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| Ubugtu | New bug: #66344 in blueprint "Dependency chart becomes unreadable with >12 dependencies" [Undecided,Unconfirmed] http://launchpad.net/bugs/66344 | 05:05 |
| Ubugtu | New bug: #66345 in blueprint "alt="" in dependency charts makes them poorly accessible" [Undecided,Unconfirmed] http://launchpad.net/bugs/66345 | 05:21 |
| === stub [n=stub@ppp-58.8.1.219.revip2.asianet.co.th] has joined #launchpad | ||
| === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad | ||
| stub | I think I'm going to do a full rollout - r4153 | 07:54 |
| stub | (as long as malcc or cprov agrees - soyuz is running with local patches) | 07:54 |
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad | ||
| SteveA | morning | 08:29 |
| stub | Morning | 08:30 |
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad | ||
| stub | SteveA: Where are the navigation menus generated from now? I need to change the URLs they all point too | 08:43 |
| === stub finds LaunchpadRootFacet | ||
| SteveA | which navigation menus? | 08:57 |
| SteveA | there are several | 08:57 |
| SteveA | ah, okay | 08:57 |
| SteveA | you'll need to also grep for absolute URLs starting with the paths you're changing | 08:57 |
| stub | There seem way to many places to change :-( | 08:58 |
| stub | $ grep -R /malone/ . | wc -l | 09:01 |
| stub | 131 | 09:01 |
| SteveA | redirects should handle it if you miss any | 09:01 |
| SteveA | particularly if the redirects have logging | 09:02 |
| === mholthaus__ [n=mholthau@140.245.76.83.cust.bluewin.ch] has joined #launchpad | ||
| stub | There won't be a redirect for /malone, because that is a perfectly valid URL to the malone product under the new system | 09:04 |
| stub | So LaunchpadRootFacet handles the top level menu, bug URLs in the navigation and actions portlets in /+bugs still point to /malone/ | 09:07 |
| stub | And I don't know what generates that popup menu at the top of the page either | 09:08 |
| lifeless | stub: have you just done an update ? | 09:10 |
| stub | of what? | 09:10 |
| lifeless | never mind | 09:11 |
| lifeless | (got a weirdness in malone) | 09:11 |
| mpt | stub, are you going to break URLs of the form https://launchpad.net/bugs/nnn? | 09:16 |
| SteveA | I think we should blacklist "bugs" to keep that working | 09:18 |
| stub | mpt: yup | 09:18 |
| mpt | SteveA, agreed | 09:19 |
| stub | The amazing mutating spec | 09:19 |
| mpt | There was a spec??? | 09:19 |
| stub | Yup | 09:19 |
| stub | Although it didn't have URL changes at all on it originally ;) | 09:19 |
| mpt | That's something wrong with the spec process, perhaps | 09:20 |
| stub | Ok. So no tacking on UI changes to non UI specs after the non-UI spec has been implemented | 09:20 |
| mpt | Specs *should* mutate, otherwise for someone starting as a Launchpadder in five years, there will be no useful information outside of the code | 09:22 |
| mpt | unless that's an ok thing | 09:23 |
| stub | Nah - specs should be obsoleted, possibly by other specs being implemented (IMO) | 09:24 |
| mpt | Well, specs can (a) describe how a feature should behave, or (b) describe how something should be changed | 09:24 |
| mpt | Currently we have (b), so our specifications are glorified bug reports | 09:25 |
| stub | Specs describe work to be done (except for specs flags as informational), and are not documentation that needs to be maintained. | 09:25 |
| mpt | But without (a), it's harder to do QA, or to decide whether something is a bug. | 09:25 |
| lifeless | the best specs I've seen describe a state to reach | 09:27 |
| lifeless | *and* | 09:27 |
| lifeless | how to reach it | 09:27 |
| stub | You are talking about a Launchpadder in 5 years time. Unless the specs are treated as documentation and maintained in lockstep with code, QA using the spec is just silly. And specs should not be documentation, they should be a description of a task that was discussed, approved and implemented at a particular point in time. | 09:27 |
| mpt | I see only assertions in that paragraph :-) | 09:28 |
| stub | Specs should not be mutated, as then they stop being specs and become moving targets. You have no idea what is implemented, what will be implemented, what might be implemented, what was implemented. | 09:30 |
| stub | If you have one spec, you might have an answer to one of those. Or a very confusing spec that attempts to address two or more. | 09:31 |
| mpt | I don't think any of those particularly matter. What matters is whether there's a difference between what the spec says and what the code does. | 09:31 |
| mpt | Because that can be regarded as a bug in one or the other. | 09:31 |
| mpt | Otherwise you can't tell whether the divergence was because of design decisions made since the spec was approved, or because the developer was sloppy. | 09:32 |
| stub | We need a different term then. In most usage, a spec represents an agreed chunk of work generally in the context of someone implementing a spec. Changes to specs during implementation involve negotiation. And changes post signoff are irrelevant as the chunk of work is done. | 09:33 |
| mpt | So, I'm not a wizened software engineer, but I'm thinking of functional specifications | 09:34 |
| mpt | Are you thinking of a different kind? | 09:34 |
| stub | Same I think. But I don't see how a spec being implemented today can possibly be relevant in 5 years unless no work was done on that feature over that time. | 09:34 |
| stub | Once a spec is implemented, its only use is historical information and possibly finger pointing. | 09:35 |
| stub | If the feature needs to change, write a new spec. | 09:35 |
| mpt | Okay, that's great | 09:39 |
| mpt | because it greatly reduces the rationale for having a separate bug tracker and feature tracker :-) | 09:40 |
| === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad | ||
| stub | Use case would be a bounty on implementing a particular spec. The spec at the time the bounty was accepted is what counts, with changes a possibility through negotiation. And changes after signoff just represent destruction of historical record. | 09:44 |
| === stub wanders off to sort out flights | ||
| === Spads [n=spacehob@217.205.109.249] has joined #launchpad | ||
| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad | ||
| === slgeorge [n=steve@217.205.109.249] has joined #launchpad | ||
| === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad | ||
| === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad | ||
| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has left #launchpad [] | ||
| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad | ||
| SteveA | mpt: ping | 11:07 |
| mpt | SteveA, pong | 11:07 |
| SteveA | skype call? | 11:08 |
| mpt | sure | 11:08 |
| mpt | Well, I could hear you... | 11:10 |
| Ubugtu | New bug: #66367 in launchpad "Number of translations to do" [Undecided,Unconfirmed] http://launchpad.net/bugs/66367 | 11:10 |
| mpt | that's a dupe | 11:11 |
| SteveA | i could not hear you | 11:11 |
| SteveA | lets try echo test, both of us | 11:11 |
| mpt | works fine for me | 11:12 |
| SteveA | try again pleae | 11:12 |
| SteveA | I'm having intermittent issues hearing voices | 11:13 |
| mpt | ok | 11:13 |
| SteveA | poo | 11:13 |
| SteveA | silence | 11:13 |
| mpt | ? | 11:14 |
| jamesh | do you have your microphone muted? | 11:15 |
| mpt | If I did, the echo test wouldn't work... | 11:15 |
| SteveA | no, it's a bluetooth issue I think | 11:15 |
| mpt | complete silence from you now | 11:16 |
| SteveA | I'll adjust alsa setting | 11:16 |
| SteveA | don't just hang up! | 11:16 |
| mpt | Shall I sing? | 11:16 |
| SteveA | no | 11:16 |
| SteveA | hmm | 11:18 |
| === mpt thinks pqm.launchpad.net should have less aggressive caching | ||
| SteveA | also spracht | 11:18 |
| jamesh | mpt: I don't think it has any caching | 11:20 |
| jamesh | mpt: the output of the test suite would be buffered, so the web front end wouldn't see each new line as it is generated | 11:24 |
| jamesh | stdio only uses the line buffered mode (flush on new line) when outputting to the terminal | 11:25 |
| mpt | It doesnt't send any Expires header, or anything else | 11:26 |
| mpt | http://www.ircache.net/cgi-bin/cacheability.py?query=http%3A%2F%2Fpqm.launchpad.net%2F | 11:26 |
| jamesh | ... so it isn't using caching | 11:26 |
| jamesh | that URL site says that it will be considered stale | 11:28 |
| jamesh | how can you less agressively cache the result than not caching it at all? | 11:28 |
| === danilos [n=danilo@ip-115-195.sn1.eutelia.it] has joined #launchpad | ||
| mpt | Maybe Epiphany is looser with caching | 11:34 |
| === stub [n=stub@ppp-58.8.1.219.revip2.asianet.co.th] has joined #launchpad | ||
| stub | danilos: Do you remember what I was supposed to be runnng against the production database today? I can't find the details in my IRC log and Carlos never emailed me (assuming it was actually Carlos who asked). | 12:12 |
| danilos | stub: copy-translations | 12:13 |
| stub | dapper -> edgy? | 12:13 |
| danilos | stub: let me check the proper syntax, I think it's "copy-translations-from-parent.py dapper edgy" | 12:13 |
| danilos | stub: that's right | 12:13 |
| stub | ok - that's all I need. I'll wait until malcc or cprov get online to see if I can combine the downtime with a rollout. | 12:14 |
| === stub hopes Carlos wasn't just guessing when he said half an hour | ||
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad | ||
| lifeless | lp review teem meeting in 41 minutes | 12:19 |
| === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad | ||
| mpt | A 6.8 MB PQM failure message? That has to be some kind of record | 12:27 |
| spiv | mpt: lucky you! | 12:28 |
| mpt | I must have caused every single pagetest to fail voluminously | 12:28 |
| stub | jamesh: Are you aware of any limits to the size of a regexp? | 12:31 |
| jamesh | stub: not off hand | 12:31 |
| stub | I'm wondering how safe it is to use a single |'d regexp when the list grows to be a few hundred items long | 12:32 |
| jamesh | stub: I can't see it being worse than maintaining all those regexps separately | 12:32 |
| stub | I'll probably leave it the way it is though, as it will allow the UI to report the id of the regexp matched if we want | 12:34 |
| stub | (yagni?) | 12:34 |
| jamesh | stub: fair enough. If that feature is really needed, it can also be done with named groups | 12:35 |
| spiv | stub: If you used named groups (like Moin's markup parser), you could have one regexp but still report an id. | 12:35 |
| jamesh | stub: but if you'd prefer to go with multiple regexps for now, go for it. | 12:35 |
| === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad | ||
| jamesh | (just make sure they don't get recompiled every run) | 12:35 |
| stub | spiv: As in r'(?P<1>exp_1)|(?P<2>exp_2)|...|(?P<n>exp_n)' ? | 12:38 |
| stub | Means people can't use (?i) syntax but that might be good | 12:40 |
| spiv | >>> re.compile(r'(?P<a>a+)|(?P<b>b+)|(?P<c>c+)').match('aaaaa').groupdict() | 12:40 |
| spiv | {'a': 'aaaaa', 'c': None, 'b': None} | 12:40 |
| SteveA | stub: ask gustavo | 12:44 |
| SteveA | he maintains regex libs in python | 12:44 |
| === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad | ||
| SteveA | lifeless: review meeting? | 01:01 |
| stub | Tests show only 100 named groups | 01:04 |
| SteveA | python library tests? | 01:04 |
| SteveA | named groups, so that you can say which pattern a particular name falls foul of | 01:05 |
| stub | Me playing with a command line tests. | 01:05 |
| stub | Non named groups have a similar limit | 01:05 |
| SteveA | oh, a limit in python? | 01:05 |
| SteveA | I was confused by your use of the word "Tests" | 01:06 |
| SteveA | lifeless: ping | 01:07 |
| lifeless | review meeting | 01:07 |
| lifeless | sorry, had a phone call from mum right at the start | 01:07 |
| lifeless | getting organised give me 5 | 01:08 |
| SteveA | ok | 01:10 |
| === slgeorge [n=steve@217.205.109.249] has left #launchpad ["Leaving"] | ||
| lifeless | ok | 01:12 |
| lifeless | == Agenda == | 01:13 |
| lifeless | * Roll call | 01:13 |
| lifeless | * Queue status. | 01:13 |
| lifeless | who art here ? | 01:13 |
| BjornT | me | 01:13 |
| spiv | me | 01:13 |
| SteveA | me | 01:13 |
| jamesh | me | 01:13 |
| lifeless | queue status... | 01:14 |
| SteveA | actually... grammar nazi... | 01:14 |
| SteveA | I | 01:14 |
| lifeless | :) | 01:14 |
| lifeless | 11 items in the queue | 01:15 |
| lifeless | longest is the tt-workflow mega branhc | 01:15 |
| lifeless | BjornT: how is that co,ing ? | 01:15 |
| BjornT | lifeless: i think i can finish it tomorrow. but it's taking some time since it's big, and i've also done other reviews in parallel, since it don't want it to block my queue completely. | 01:16 |
| lifeless | BjornT: I've been trying not to allocate anything to you | 01:16 |
| SteveA | tt-workflow? | 01:16 |
| lifeless | BjornT: how many hours so far reviewing it ? | 01:16 |
| SteveA | I can't quite place this | 01:16 |
| SteveA | who is the author? | 01:17 |
| === malcc [n=malcolm@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| spiv | tt == "ticket tracker", I believe. | 01:17 |
| lifeless | https://launchpad.canonical.com/SupportTrackerWorkflowSpec | 01:17 |
| lifeless | flacoste | 01:17 |
| lifeless | see https://launchpad.canonical.com/PendingReviews for details | 01:17 |
| SteveA | ok, thanks. does francis know that large branches are not welcome in the future, and that he can get support from the review team in working out how to make landings in smaller units? | 01:18 |
| BjornT | lifeless: i haven't checked yet, but i'd say it's almost two full working days. in short, several smaller patches would have been much faster to review. | 01:18 |
| lifeless | SteveA: I think we need to do a general announcement about this | 01:18 |
| SteveA | it's difficult to reverse-engineer a suitable staged landing plan from the whole blob | 01:18 |
| lifeless | SteveA: as I mentioned on the phone to you | 01:18 |
| SteveA | lifeless: I announced it last week in the meeting, btw | 01:18 |
| BjornT | SteveA: i will at least inform him about it in my review. | 01:18 |
| lifeless | SteveA: thank you | 01:19 |
| SteveA | but I think this will take several announcements | 01:19 |
| SteveA | it was met with general support iirc | 01:19 |
| SteveA | or, my ego is being overactive again | 01:19 |
| lifeless | ok, so jamesh - you have two branches over the 2 day goal period - whats up there ? | 01:19 |
| Keybuk | sabdfl: ping | 01:19 |
| lifeless | (4 and 7 respectively) | 01:19 |
| Keybuk | I still get "Not allowed here" for https://launchpad.net/sprints/uds-mtv/+settopics | 01:19 |
| jamesh | lifeless: just posted a review of matsubara's one. Will get on to Bjorn's one | 01:19 |
| SteveA | we may need to go to a policy of rejecting large landings unless they've been agreed with a reviewer in advance, sometime over the coming weeks | 01:20 |
| lifeless | SteveA: :) I was proposing something like this to you, and you suggested we wait and talk in allhands | 01:20 |
| lifeless | SteveA: so lets wait, and talk in allhands about it | 01:20 |
| lifeless | everything else is within our target review period of 2 days | 01:21 |
| lifeless | though there are a number of branches - BjornT spiv SteveA are the reviewers - that need to be done tomorrow at latest. | 01:22 |
| === mdz [n=mdz@217.205.109.249] has joined #launchpad | ||
| lifeless | jamesh: you were bringing up white space cleanups at the lp meeting last week. How did that go ? | 01:22 |
| spiv | I'm not sure that flacoste's 3402 line diff will be reviewed be reviewed tomorrow. | 01:22 |
| jamesh | lifeless: I forgot to add it to the agenda. Will do so for this meeting | 01:22 |
| BjornT | lifeless: i plan to spend all of today and tomorrow reviewing, hopefully i'll finish all my reviews then. | 01:23 |
| === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad | ||
| SteveA | lifeless: I have some review time today | 01:23 |
| lifeless | SteveA: you already have jamesh/launchpad/death-to-tabindex allocated to you | 01:24 |
| lifeless | SteveA: if you have time to do flacostes flacoste/launchpad/tt-views instead, you and spiv can swap :) | 01:24 |
| lifeless | (death to tabindex is 1K lines, largely mechanical | 01:24 |
| lifeless | tt-views is 3.4K lines, and not so mechanical, but seemed probably ok when spiv and I glanced at it | 01:25 |
| BjornT | SteveA: if you have time for some more reviews, you could take salgado's shipit branch from my queue. i think it's fairly small, but i won't get by reviewing it today. | 01:25 |
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| lifeless | loo | 01:25 |
| lifeless | lol, its pile on stevea day | 01:25 |
| SteveA | stick them in my queue, and we'll see what I can do today | 01:26 |
| lifeless | SteveA: fyi salgado is too busy with 1.0 to review at the moment, so there is some extra pressure on the review team; and the lp coding team has grown recently too | 01:26 |
| SteveA | after that, I want no more reviews this week | 01:26 |
| lifeless | SteveA: ok | 01:26 |
| SteveA | as I have UI 1.0 stuff to do | 01:26 |
| spiv | SteveA: thanks | 01:26 |
| lifeless | jamesh: can you trigger a reviews run please | 01:27 |
| lifeless | ok, any other business? | 01:27 |
| jamesh | lifeless: finished | 01:28 |
| lifeless | wicked | 01:28 |
| lifeless | SteveA: your reviews are ready | 01:28 |
| lifeless | https://devpad.canonical.com/~jamesh/pending-reviews/ | 01:28 |
| lifeless | SteveA: the biggest ones first please! | 01:28 |
| lifeless | any other business 5 | 01:29 |
| lifeless | any other business 4 | 01:29 |
| lifeless | any other business 3 | 01:29 |
| lifeless | any other business 2 | 01:29 |
| lifeless | any other business 1 | 01:29 |
| lifeless | thanks for attending! | 01:29 |
| SteveA | thanks lifeless | 01:30 |
| ctrlsoft | jamesh: hi | 01:30 |
| === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| ctrlsoft | jamesh: Is there any easy way to import bugs from trac into lp? | 01:30 |
| ctrlsoft | (not just remote watch, but really migrate) | 01:32 |
| jamesh | ctrlsoft: not at present. We have an importer from the XML dump effbot's SourceForge tools generate, but that is not really that user friendly to generate | 01:32 |
| jamesh | getting a better interchange format is a todo | 01:32 |
| lifeless | poolie: btw, dotted decimal has landed | 01:32 |
| === raraavis [n=emurphy@194.18.118.70.cfl.res.rr.com] has joined #launchpad | ||
| ctrlsoft | jamesh: ok, thanks | 01:34 |
| poolie | lifeless: sweet | 01:35 |
| jamesh | ctrlsoft: we have an XML export format for a product's bugs, so it would be useful to be able to import something in a similar format | 01:35 |
| jamesh | but that code isn't yet ready. | 01:35 |
| ctrlsoft | jamesh: Any spec/bug about it? | 01:36 |
| jamesh | ctrlsoft: no | 01:37 |
| jamesh | ctrlsoft: I've already written importers for Ubuntu Bugzilla and SourceForge, so I'd really like to have a sane XML format I could tell people to give me | 01:39 |
| === jinty [n=jinty@127.Red-83-50-221.dynamicIP.rima-tde.net] has joined #launchpad | ||
| ctrlsoft | jamesh: Yeah, that makes sense. I'm happy to write a generator for trac once there's a format | 01:39 |
| === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| === niemeyer [n=niemeyer@200.138.50.152] has joined #launchpad | ||
| === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad | ||
| lifeless | gnight all | 02:36 |
| stub | cprov: I would like to roll out r4153 either tonight or (preferably) tomorrow morning my time. | 02:48 |
| stub | cprov: That will add db patches 67-21, 22, 23, 24 and 26 | 02:50 |
| stub | cprov: I don't think any of those affect soyuz but thought I should confirm | 02:53 |
| === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad | ||
| === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has joined #launchpad | ||
| Ubugtu | New bug: #66408 in malone "URL of bugs does not understand rejected bugtask status" [Undecided,Unconfirmed] http://launchpad.net/bugs/66408 | 03:10 |
| cprov | stub: yes, looks ok, but we need 4155 cherrypick | 03:18 |
| cprov | stub: or we can do it ourself only in drescher | 03:19 |
| stub | cprov: So you don't need those local patches listed on the wiki page? | 03:19 |
| malcc | stub: Let me check, I think they were mostly turning something off then back on again and things which are in rf, I'll confirm in a moment | 03:20 |
| malcc | stub: Yes, confirmed. Two local fixes undo each other, the third is r4136. | 03:23 |
| cprov | stub: the db patches should be fine too | 03:25 |
| stub | cprov: I will roll out 4155 tomorrow everywhere, including drescer then. | 03:26 |
| cprov | stub: perfect, thank you | 03:26 |
| === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad | ||
| === zwnj [n=zwnj@213.207.218.157] has joined #launchpad | ||
| salgado | SteveA, do you have some time to review my latest shipit changes today, so that I can ask stub to include them in tomorrow's roll out? | 04:26 |
| stub | Shouldn't we sit on the changes a few days before pushing out brand new code, or is it really urgent? | 04:26 |
| salgado | stub, it is /really/ urgent, and it's quite low risk --just changes the front page | 04:28 |
| stub | ok | 04:29 |
| === PSUSI [i=hidden-u@iriserv.iradimed.com] has joined #launchpad | ||
| PSUSI | how would one go about getting spam removed from bugs on launchpad? | 04:37 |
| seb128 | is there a way to mail all the member of a team on launchpad? | 04:40 |
| === _thumper_ [n=tim@tpsoft.gotadsl.co.uk] has joined #launchpad | ||
| === gjc [n=gjc@eremita.di.uminho.pt] has joined #launchpad | ||
| gjc | hmm.. lucky me, no nick registration needed here :) | 04:43 |
| === _thumper_ [n=tim@tpsoft.gotadsl.co.uk] has joined #launchpad | ||
| === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad | ||
| PSUSI | anyone know what to do when someone starts spamming bugs on launchpad? can it be cleaned up and the offending email unsubscribed? | 04:58 |
| salgado | PSUSI, although there's no automated way to do so, we can sort it out for you. what's the bug that's beeing spammed? | 05:02 |
| PSUSI | I have a list of about 10 bugs that some silly person is also subscribed to and he seems to have recently installed a very broken email blocking probram that has ignored the Errors-to: header and replied with a confirm request to each bug | 05:03 |
| PSUSI | so now this silly confirm request is posted to all of these bugs... standby for list | 05:04 |
| jamesh | distributed spam blocking: get the rest of the world to filter your email | 05:04 |
| PSUSI | 35934, 38649, 64174, 44370, 64585, 28925, 45768, 30284 | 05:05 |
| PSUSI | hehehe | 05:05 |
| Ubugtu | New bug: #66422 in malone "How to deal with spam" [Undecided,Unconfirmed] http://launchpad.net/bugs/66422 | 05:05 |
| PSUSI | I just wish the retarded developers of these things would at least respect the damn Errors-to: header | 05:06 |
| PSUSI | I also found a half a dozen of these confirm requests in my mailbox this morning as a result of a few posts to a public mailing list | 05:06 |
| jamesh | It is an argument for requiring that replies maintain some token in the subject line (e.g. the bug number) | 05:06 |
| PSUSI | the list sets Errors-to: specifically to be able to deal with ( read: unsubscribe ) email addresses that are undeliverable instead of bothering subscribers with that | 05:07 |
| PSUSI | I think just setting the From: filed to an undeliverable address would fix it actually | 05:08 |
| PSUSI | normal mail clients will use the Reply-to: anyhow | 05:08 |
| ddaa | some do | 05:08 |
| ddaa | it's an ongoing flamewar topic | 05:09 |
| === PSUSI flames on then | ||
| salgado | seb128, no, we don't have a way to do that yet. (bug 44545) | 05:09 |
| Ubugtu | Malone bug 44545 in launchpad "FOAF Request: make all Teams into email-aliases/mailing-lists" [Medium,Unconfirmed] http://launchpad.net/bugs/44545 | 05:09 |
| PSUSI | non broken mail clients will respect it ;) | 05:09 |
| seb128 | gjc: ^^ | 05:09 |
| seb128 | salgado: thank you | 05:09 |
| PSUSI | jamesh: so you are manually cleaning the spam from the bugs and unsubscribing the guy? | 05:10 |
| PSUSI | err, salgado even | 05:10 |
| gjc | seb128, salgado: thanks | 05:11 |
| salgado | seb128, gjc, np. | 05:12 |
| salgado | PSUSI, I can't do that myself, but I just noticed that he's only subscribed to bug 28925 | 05:14 |
| Ubugtu | Malone bug 28925 in xserver-xorg-driver-ati "X fails to start in dapper flight3 & 4 with ati X600, onward all the way through dapper 6.06 LTS" [Unknown,Unknown] http://launchpad.net/bugs/28925 | 05:14 |
| salgado | the problem is that he's notified every time a bug is marked as a duplicate of that one, and that one has lots of dupes | 05:15 |
| PSUSI | salgado: do you know who can? and if he isn't subscribed then why did he get notifications from the bug? | 05:15 |
| PSUSI | ahhhh | 05:15 |
| PSUSI | yes | 05:15 |
| salgado | actually, he's subscribed to 47083 which is a dupe of 28925 | 05:16 |
| salgado | oh, he reported that one. :/ | 05:16 |
| salgado | stub, is there anything we can do to avoid glen-stewart's spam killer to spam bug 47083 and the dupes of 28925? | 05:20 |
| Ubugtu | Malone bug 47083 in xserver-xorg-video-ati "installer CD fails to start X on Radeon X800 GTO" [Medium,Unconfirmed] http://launchpad.net/bugs/47083 | 05:20 |
| elmo | salgado: how about a rubber duck deactivates his email, would that work? | 05:22 |
| stub | eh? | 05:24 |
| salgado | elmo, that may cause OOPSes because we assume that somebody who reported a bug has a preferred email | 05:25 |
| elmo | salgado: sweet | 05:26 |
| salgado | stub, on 47083 we can see an automated reply from the reporter's spam killer asking for a confirmation of the message. a similar message is sent every time a bug is marked as a dupe of 47083 or 28925. | 05:28 |
| stub | Bg 47083 | 05:28 |
| stub | Bug 47083 | 05:28 |
| Ubugtu | Malone bug 47083 in xserver-xorg-video-ati "installer CD fails to start X on Radeon X800 GTO" [Medium,Unconfirmed] http://launchpad.net/bugs/47083 | 05:28 |
| stub | I'll unsubscribe glen-stewart for a start | 05:29 |
| stub | I wonder if elmo's suggestion would blow anything up? It should work, but unlikely to be tested. | 05:30 |
| stub | Hmm... should, because they would become an invalid user. | 05:31 |
| salgado | I think it'd blow if the guy was the only person subscribed to that bug | 05:31 |
| salgado | might blow in other cases too | 05:31 |
| stub | Not much we can do anyway - it isn't as if Launchpad will ever be able to communicate with them. | 05:33 |
| === lbm [n=lbm@82.192.173.92] has joined #launchpad | ||
| === mdz [n=mdz@87-194-36-33.bethere.co.uk] has joined #launchpad | ||
| salgado | stub, btw, I think we had enough testing of the mirror prober on staging. there's no need to keep it running there | 05:45 |
| stub | ok | 05:45 |
| === daq4th [n=darkness@netstation-005.cafe.zSeries.org] has joined #launchpad | ||
| === carlos [n=carlos@146.Red-80-36-81.staticIP.rima-tde.net] has joined #launchpad | ||
| carlos | hi | 06:40 |
| === kiko_ [n=kiko@200.103.112.11] has joined #launchpad | ||
| === kiko_ is now known as kiko-fud | ||
| kiko-fud | bonjour mes amies | 06:43 |
| kiko-fud | err amis | 06:43 |
| kiko-fud | how's it going? | 06:43 |
| SteveA | hello world | 06:45 |
| SteveA | salgado-lunch: still need that review done? | 06:45 |
| kiko-fud | sabdfl, around? | 06:50 |
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| kiko-fud | hey cprov-lunch | 07:08 |
| salgado-lunch | SteveA, yeah, I do | 07:08 |
| cprov-lunch | kiko-fud: hey | 07:08 |
| kiko-fud | how's it going cprov-lunch | 07:13 |
| kiko-fud | just saw your update to n-m-a-f | 07:13 |
| cprov-lunch | kiko-fud: yes, very good so far, updating specs & plans, testing new i-f-p (w/o translations) in mawson. | 07:14 |
| kiko-fud | cprov-lunch, the funny part is that mdz doesn't think that changing the RFC address would be a big deal | 07:15 |
| kiko-fud | cprov-lunch, and malcc? | 07:15 |
| malcc | Changing my rfc address probably wouldn't be a big deal either | 07:16 |
| cprov-lunch | kiko-fud: well, it's precisely what is in the DSC, it will only change if we modify the SPR | 07:16 |
| kiko-fud | malcc, so you arrived in one piece? | 07:17 |
| kiko-fud | cprov-lunch, no, mdz was saying that it wouldn't be strictly necessary to store that exact line | 07:17 |
| kiko-fud | as long as we never regenerated old indices files, I guess | 07:17 |
| malcc | kiko-fud: Yup, the journey was suspiciously smooth. I think the universe must have a nightmare in store for me on the way home | 07:17 |
| kiko-fud | malcc, you firm believer in karma? | 07:18 |
| cprov-lunch | kiko-fud: yes, I understood, but better keep it constant, following the DSC, not the Person.displayname, IMHO. | 07:18 |
| kiko-fud | cprov-lunch, yeah, I'm okay too | 07:19 |
| === Spads [n=spacehob@host-84-9-50-48.bulldogdsl.com] has joined #launchpad | ||
| SteveA | salgado: I'm reviewing your shipit branch now | 07:56 |
| === Spads [n=spacehob@host-84-9-50-48.bulldogdsl.com] has joined #launchpad | ||
| ddaa | SteveA: my hands are falling off, and I'll be going for dinner soon | 08:05 |
| ddaa | I'll reply to poolie about the debian svn issue tomorrow | 08:05 |
| ddaa | some clarifications seem to be needed | 08:05 |
| malcc | Hmm, looks like the date created patch went into rocketfuel without the matching sampledata changes, anyone regenerating sampledata at the moment gets a bonus 1000 lines for their patch | 08:08 |
| === mdz [n=mdz@87-194-36-33.bethere.co.uk] has joined #launchpad | ||
| malcc | Any objection if I do nothing but make newsampledata in a branch and trivial it? | 08:08 |
| kiko-fud | malcc, no objection, d it. | 08:09 |
| === ryanakca_ [n=ryan@unaffiliated/ryanakca] has joined #launchpad | ||
| SteveA | salgado: reviewed. well done. | 08:11 |
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| === |telenieko| is now known as telenieko | ||
| sivang | hi all | 09:22 |
| sivang | is there a way to list package karms joined by maintainers, over a specific team? (ubuntu-dev) | 09:22 |
| === lamont has a question for the launchpad gang | ||
| lamont | currently there are 3 or so releases worth of build logs in people.u.c/~lamont/buildLogs - does it make sense to import those into launchpad to go with the binaries that are there? | 09:57 |
| kiko-fud | lamont, good question, check with cprov if it's doable | 10:28 |
| lamont | kiko-fud: you will, or I should? | 10:30 |
| === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad | ||
| kiko-fud | lamont, if you can, that'd be best | 10:30 |
| lamont | cprov: how about it? ^^^ | 10:30 |
| lamont | :-) | 10:30 |
| malcc | So this is build logs which would have been imported by gina, if gina imported build logs, right? | 10:31 |
| kiko-fud | yes. | 10:31 |
| === kiko-fud gone | ||
| cprov | lamont: what buildlogs ? security ? | 10:31 |
| lamont | people.ubuntu.com/~lamont/buildLogs - all of warty-breezy build logs | 10:31 |
| lamont | no security logs | 10:32 |
| lamont | just thinking it might be good to prune the size of that tree on p.u.c | 10:32 |
| lamont | esp since someone went there today looking for an edgy build log, and had to be redirected to launchpad... | 10:32 |
| cprov | lamont: well, not sure if they are useful since they were not done using our buildfarm. really, dunno. | 10:33 |
| salgado | SteveA, around? | 10:34 |
| lamont | cprov: neither were the binaries... :) | 10:34 |
| cprov | lamont: it's feasible and you want them we can do it. if it was your question. | 10:34 |
| lamont | cprov: the real question was (1) does it make sense to do it, and (2) if so, how feasable? | 10:34 |
| cprov | lamont: yes ;) legacy | 10:35 |
| lamont | exactly | 10:35 |
| cprov | lamont: it only make sense if you use it | 10:35 |
| lamont | well, not personally, but sometimes it's useful to compare the build log with the one that's not working for a security update or some such | 10:36 |
| cprov | lamont: it's feasible, it's just a matter of finding the correspondent build record, upload the log to librarian and update its buildlog field | 10:36 |
| lamont | so it really gets back to a dev-team question of "do we want them". got it. | 10:36 |
| lamont | cprov: I'll ask dev-team et al, and get back with you | 10:36 |
| cprov | lamont: good, thank you for pointing that, I appreciate it. | 10:37 |
| lamont | np | 10:38 |
| SteveA | salgado: hi | 10:46 |
| salgado | hi SteveA. about the XXX I droped from some config files on my shipit-for-edgy branch... I'd like to keep them since I'm going to remove the variable I added soon | 10:47 |
| salgado | do you think it'd be okay to not add that variable on the production config files and leave the XXX in them? | 10:48 |
| === jkakar [n=jkakar@204.174.36.228] has joined #launchpad | ||
| SteveA | salgado: I'd say leave the XXX, add the variable, but add a further line of comment above the variable saying | 10:56 |
| SteveA | # XXX: the following config item is temporary, so the XXX above applies in the long term. | 10:56 |
| salgado | fair enough | 10:59 |
| salgado | SteveA, do you know if it's possible to check the status used by the redirect using testbrowser or if I have to use an old-style test? | 11:06 |
| salgado | BjornT, maybe you know ^^? | 11:06 |
| SteveA | I think you can't easily check from a regular "real" browser | 11:11 |
| SteveA | so it may not be so easy from testbrowser | 11:11 |
| SteveA | looking at the testbrowser code, doesn't look like there's an easy way | 11:14 |
| SteveA | so, write an old-style test for it | 11:14 |
| BjornT | salgado: i think you can do it by setting browser.handleError = True (or maybe False). but i'm not sure. | 11:14 |
| salgado | yeah, I couldn't find anything either | 11:14 |
| === salgado tries | ||
| === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad | ||
| sabdfl | kiko: briefly now - 'sup? | 11:33 |
| === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has left #launchpad [] | ||
| === mdz [n=mdz@george.kkhotels.co.uk] has joined #launchpad | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!