| === cinerama_ is now known as cinerama | ||
| jtv | morning folks | 03:33 |
|---|---|---|
| lifeless | hahhahahahahaahahahahahahahahaha | 03:50 |
| lifeless | ha | 03:50 |
| lifeless | wgrant: yo, soyuz question | 03:54 |
| lifeless | https://lp-oops.canonical.com/oops.py/?oopsid=1904K1614 | 03:54 |
| lifeless | queries 10 and 12 | 03:54 |
| wgrant | lifeless: What about them? | 03:57 |
| lifeless | why does the file size count not have the status enum check | 03:57 |
| wgrant | lifeless: It uses dateremoved instead. | 03:58 |
| wgrant | Which is similar, but not quite the same. | 03:58 |
| wgrant | dateremoved lags a bit. | 03:58 |
| wgrant | But it represents the actual size on disk. | 03:58 |
| lifeless | uhm | 03:58 |
| lifeless | would it be incorrect to put the status enum in ? | 03:58 |
| wgrant | It depends on your definition of correctness. | 03:58 |
| wgrant | It would make it no longer reflect the archive disk usage. | 03:59 |
| wgrant | lifeless: Erm, 6to4 doesn't do that. | 04:00 |
| wgrant | Maybe you mean NAT64. | 04:00 |
| wgrant | Which is in no way widely supported. | 04:00 |
| wgrant | And then you probably need DNS64 too. | 04:01 |
| wgrant | Pure IPv6 is not a very friendly environment at the moment. | 04:01 |
| lifeless | ah | 04:01 |
| lifeless | there used to be a 6 -> 4 thingy | 04:01 |
| wgrant | Still, World IPv6 Day soon. | 04:01 |
| lifeless | 6-7 years ago | 04:01 |
| wgrant | Yeah. | 04:01 |
| wgrant | That was deprecated. | 04:01 |
| wgrant | And replaced by NAT64. | 04:02 |
| wgrant | But neither has ever been widely supported. | 04:02 |
| wgrant | Doable, but not common. | 04:02 |
| lifeless | I feel for the guy | 04:02 |
| lifeless | but its totally not a bug in lp's code | 04:02 |
| StevenK | I just love how The Plan for IPv6 is "Oh, everyone will move. At some point." | 04:02 |
| wgrant | StevenK: What more plan can there be? | 04:02 |
| wgrant | People have to stop being hideously lazy. | 04:02 |
| wgrant | And just do it. | 04:02 |
| spiv | I just like to imagine IPv6 causing DNS servers the world over to scream “AAAA!” | 04:02 |
| wgrant | It's not that hard. | 04:02 |
| StevenK | spiv: Boo. Hiss. | 04:03 |
| StevenK | wgrant: No, it just costs time and lots of money. | 04:03 |
| wgrant | StevenK: And they've had more than a decade to do it. | 04:04 |
| StevenK | And telecommunication companies prefer to *recieve* lots of money and spend very little. | 04:04 |
| lifeless | wgrant: thats -barely- 2 equipment refreshes of core switch gear | 04:04 |
| wgrant | lifeless: Sure. But most companies are not even thinking about it yet. | 04:04 |
| lifeless | wgrant: and its not been /stable/ for all that long | 04:05 |
| lifeless | anyhow | 04:05 |
| lifeless | archive:+repository-size | 04:05 |
| lifeless | not ip6 | 04:05 |
| lifeless | kgo | 04:05 |
| wgrant | At least aarnet's tunnel broker is reasonable. | 04:06 |
| wgrant | lifeless: What about it? | 04:06 |
| lifeless | wgrant: thats the oops I'm looking at | 04:08 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/739070 | 04:08 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 04:08 |
| lifeless | 9+ seconds to query file sizes | 04:08 |
| wgrant | Yes. | 04:08 |
| wgrant | lifeless: Would the status filter improve it significantly? | 04:09 |
| lifeless | I'm not 100% sure | 04:09 |
| lifeless | exploring the space atm | 04:09 |
| lifeless | is it 2 for binaries as well? | 04:09 |
| === Ursinha is now known as Ursinha-afk | ||
| wgrant | Yes. | 04:10 |
| wgrant | PackagePublishingStatus is universal. | 04:10 |
| wgrant | ~/launchpad/lp-branches/bfj-different-urls$ bzr push | 04:10 |
| wgrant | Using saved push location: lp:~wgrant/launchpad/bfj-different-urls | 04:10 |
| wgrant | bzr: ERROR: Server sent an unexpected error: ('error', '<ProtocolError for xmlrpc.lp.internal:8097/codehosting: 502 Bad Gateway>') | 04:10 |
| wgrant | I don't think that's meant to happen. | 04:10 |
| lifeless | wgrant: would 2+3 be equivalent ? | 04:10 |
| wgrant | lifeless: No. | 04:10 |
| wgrant | lifeless: What's 3? Superseded? | 04:11 |
| wgrant | (it's working this time) | 04:11 |
| lifeless | wgrant: yes | 04:11 |
| lifeless | 4 is deleted | 04:11 |
| lifeless | 1 is pending | 04:12 |
| wgrant | 5 Obsolete. | 04:12 |
| wgrant | Right. | 04:12 |
| wgrant | I never remember the 3/4 order. | 04:12 |
| wgrant | So, 3/4/5 are all potentially removed. | 04:12 |
| wgrant | In the beginning there was Pending/Published/PendingRemoval/Removed. | 04:12 |
| lifeless | anyhow | 04:12 |
| wgrant | Then ArchiveRemovalRedesign happend, and the removedness was moved into dateremoved instead. | 04:12 |
| lifeless | with (2) its a 50ms query hot | 04:12 |
| wgrant | With status indicating the reason for removal. | 04:12 |
| wgrant | Hmm. | 04:12 |
| wgrant | With dateremoved how is it hot? | 04:13 |
| lifeless | 73ms | 04:13 |
| lifeless | :P | 04:13 |
| lifeless | look at the plan | 04:22 |
| lifeless | "securebinarypackagepublishinghistory__archive__status__idx" btree (archive, status) | 04:22 |
| lifeless | is the index it is using | 04:22 |
| lifeless | so it reads every row ever in that archive | 04:23 |
| lifeless | wgrant: ^ | 04:26 |
| lifeless | wgrant: ping | 04:28 |
| lifeless | create index bpph__dateremoved__for__size__idx on binarypackagepublishinghistory using btree (dateremoved) WHERE dateremoved IS NULL; | 04:28 |
| lifeless | can you create that on dogfood | 04:28 |
| lifeless | and get me an explain analyze for the query in https://bugs.launchpad.net/launchpad/+bug/739070/comments/1 ? | 04:28 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 04:28 |
| wgrant | lifeless: Ah, didn't see the plans in the bug. | 04:31 |
| wgrant | Let's see. | 04:31 |
| wgrant | lifeless: The index is building. | 04:33 |
| lifeless | I suspect we'll want (archive) where dateremoved is null | 04:34 |
| lifeless | or | 04:34 |
| lifeless | we should make dateremoved go away | 04:35 |
| lifeless | either folding it into the status enums | 04:35 |
| lifeless | or dropping the librarian reference or whatever | 04:35 |
| wgrant | lifeless: -> Index Scan using temp_bpph_archive_dateremoved_idx on binarypackagepublishinghistory (cost=0.00..1112.40 rows=391 width=4) (actual time=56.562..107.930 rows=915 loops=1) | 04:43 |
| wgrant | Index Cond: ((archive = 14516) AND (dateremoved IS NULL)) | 04:43 |
| StevenK | So the bpph scan is cheap with an index | 04:43 |
| wgrant | 34ms hot. | 04:44 |
| jtv | Is that dateremoved check a status check in disguise? | 04:44 |
| wgrant | 10s cold, but DF. | 04:44 |
| wgrant | jtv: Yes. | 04:44 |
| StevenK | lifeless: There is a stay of execution for [bs]pph, we'd need to think very carefully about it. | 04:44 |
| lifeless | StevenK: We don't need to remove it | 04:44 |
| lifeless | StevenK: but we do need to model it. Modelling it as a separate field may be worse than not. | 04:45 |
| lifeless | wgrant: the query was 10s cold ? did you get the full explain analyze? | 04:45 |
| StevenK | We could add another DBItem to PackagePublishingStatus -- PURGED or so | 04:46 |
| wgrant | lifeless: I had it, but then I made the mistake of pressing PgUp, which DF does not enjoy at all. | 04:46 |
| wgrant | StevenK: Doesn't quite work. | 04:46 |
| wgrant | StevenK: PPS has three separate end states. | 04:46 |
| wgrant | (whether this is sane or not is in question) | 04:46 |
| wgrant | lifeless: But cold data from DF is entirely useless. | 04:47 |
| wgrant | lifeless: The numbers, at least. | 04:47 |
| wgrant | The plan is OK. | 04:47 |
| lifeless | wgrant: can I see? | 04:47 |
| lifeless | wgrant: cold data still tells me where time is going, and thats useful. | 04:47 |
| lifeless | wgrant: so I dispute entirely useless | 04:47 |
| lifeless | wgrant: oh, I see, lost. | 04:47 |
| lifeless | kk | 04:47 |
| wgrant | Yeah. | 04:47 |
| wgrant | Get one from qastaging, I guess. | 04:48 |
| lifeless | select count(*) from branchrevision; then try again ? | 04:48 |
| wgrant | It doesn't tell you where the time goes, really. | 04:48 |
| wgrant | It tells you that DF has like 4MB of RAM. | 04:48 |
| StevenK | 4MB. 'lol' | 04:48 |
| lifeless | 640k surely | 04:48 |
| === Ursinha-afk is now known as Ursinha | ||
| lifeless | ugh, timeline only works if you run upstream builds of chromium? wtf | 04:52 |
| wgrant | lifeless: Hm? | 04:53 |
| wgrant | Works for me. | 04:53 |
| lifeless | "Pfffttt, Speed Tracer is not working. | 04:53 |
| lifeless | Please double check a couple of things: | 04:53 |
| lifeless | You must start Chrome with the flag: --enable-extension-timeline-api | 04:53 |
| lifeless | You must be running the Chrome Dev channel. | 04:53 |
| lifeless | For more details, see our getting started docs." | 04:53 |
| wgrant | Oh. Not an upstream build. | 04:53 |
| lifeless | I have enable-extension-timeline-api in CHROMIUM_FLAGS in /etc/chromium-browser/default | 04:53 |
| wgrant | Just not a stable build. | 04:53 |
| lifeless | webdevs are stable users too | 04:54 |
| StevenK | And error message that includes "Pfffttt," Kwality | 04:54 |
| wgrant | eg. ppa:chromium-daily/beta or so. | 04:54 |
| lifeless | I question the sanity of this | 04:54 |
| wgrant | lifeless: *That* makes you question the sanity of Chromium?" | 04:54 |
| StevenK | I have yet to see any *compelling* reason to switch to Chromium, TBH. | 04:54 |
| wgrant | StevenK: I use Chromium. | 04:54 |
| wgrant | It's not bad. | 04:55 |
| StevenK | However, I question Google's motives. | 04:55 |
| wgrant | Firefox 4 is OK, except not with fglrx. | 04:55 |
| lifeless | wgrant: so can has plan? | 04:55 |
| wgrant | lifeless: The hot one? | 04:55 |
| lifeless | the cold one after querying branchrevision a lot | 04:56 |
| wgrant | It's been running that select for 8 minutes, still hot as ever. | 04:56 |
| lifeless | argh hhaa | 04:56 |
| lifeless | ok | 04:56 |
| wgrant | Yes. | 04:56 |
| lifeless | hot will be fine | 04:56 |
| wgrant | http://paste.ubuntu.com/602605/ | 04:56 |
| micahg | funny, 3.6 was broke with nvidia, 4.0 is broke with fglrx | 04:57 |
| wgrant | Our test suite is slow. | 04:57 |
| lifeless | wgrant: https://bugs.launchpad.net/launchpad/+bug/739070/comments/4 | 05:00 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 05:00 |
| wgrant | lifeless: 19ms | 05:01 |
| lifeless | this is 1/2 the estimated cost | 05:01 |
| lifeless | which is daft but there you go | 05:01 |
| wgrant | http://paste.ubuntu.com/602606/ | 05:01 |
| lifeless | why are we bringing back the rows ? | 05:02 |
| wgrant | Which rows? | 05:03 |
| lifeless | these rows | 05:03 |
| lifeless | why aren't we summing | 05:03 |
| wgrant | NFI | 05:03 |
| wgrant | But it's only a single column. | 05:03 |
| wgrant | So it's not that bad. | 05:03 |
| wgrant | (yes, it should be fixed) | 05:03 |
| wgrant | Oh. This query is not a single column. | 05:03 |
| wgrant | Ahh, this is query 11, not query 10. | 05:04 |
| lifeless | wgrant: https://bugs.launchpad.net/launchpad/+bug/739070/comments/5 | 05:06 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 05:06 |
| lifeless | wgrant: actually I'm in https://lp-oops.canonical.com/oops.py/?oopsid=1948BB197 | 05:06 |
| lifeless | query 21 | 05:07 |
| lifeless | 8929msSQL-launchpad-main-master | 05:07 |
| lifeless | SELECT DISTINCT LibraryFileContent ... | 05:07 |
| wgrant | lifeless: Still 19ms. | 05:07 |
| lifeless | spm: can you run https://bugs.launchpad.net/launchpad/+bug/739070/comments/5 on the readonlymode replica - *one* run, I need the explain analyze (looking for cold cache effects) | 05:08 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 05:08 |
| spm | oki | 05:08 |
| lifeless | why does packagefile exist? | 05:23 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/739070/comments/6 | 05:24 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 05:24 |
| lifeless | wgrant: ^ | 05:25 |
| lifeless | StevenK: ^ | 05:25 |
| wgrant | lifeless: packagefile? You mean BinaryPackageFile? | 05:25 |
| lifeless | yes | 05:25 |
| StevenK | There are two | 05:25 |
| lifeless | and I assume sourcepackagefile | 05:25 |
| wgrant | SourcePackageReleaseFile is essential. | 05:26 |
| StevenK | It's SourcePackageReleaseFile | 05:26 |
| StevenK | (Usually called SPRF) | 05:26 |
| wgrant | BinaryPackageFile is for potential expansion to multi-file binaries. | 05:26 |
| wgrant | (yes, seriously, one has Release and one does not) | 05:26 |
| lifeless | ok | 05:26 |
| lifeless | I can see the expansion factor | 05:26 |
| lifeless | but | 05:26 |
| lifeless | if we makde bpph be an owner of LFC (wrapping the LFA fields in it, and glued into the gc process) we'd save 2.2 seconds of overhead. | 05:27 |
| wgrant | aaaaaaaaaaaaaaa | 05:28 |
| wgrant | aaaaaaaaaaaaaaaaaa | 05:28 |
| wgrant | So, an SPR can have any number of SPRFs. | 05:28 |
| wgrant | And there are often lots of BPPHs for a BPR. | 05:28 |
| lifeless | sure | 05:28 |
| lifeless | but the whole point of LFA is to reference-count-own LFC | 05:28 |
| lifeless | ignore SPRF for now, I see why the 1:M is needed | 05:29 |
| lifeless | we could roll up some stuff there too, but separate problem. | 05:29 |
| wgrant | No point solving BPPH without SPPH. | 05:29 |
| lifeless | wgrant: 3:1 bpph -> spph rows | 05:29 |
| lifeless | or more | 05:29 |
| wgrant | A constant factor of three is not very compelling. | 05:30 |
| lifeless | wgrant: solving a problem is solving a problem | 05:30 |
| lifeless | so the question is, can we solve | 05:30 |
| lifeless | or | 05:30 |
| lifeless | do we need to precalculate | 05:30 |
| * StevenK murders gina.txt | 05:43 | |
| lifeless | stub: hi | 05:52 |
| jtv | Speaking of stub, where did his wonderful "prejoin" decorator go? | 05:54 |
| lifeless | jtv: deleted | 05:54 |
| jtv | in favour of what? | 05:54 |
| lifeless | DecoratedResultSet | 05:54 |
| lifeless | stub: is 2.8 seconds 'about right' for reading in 1000 cold rows from libraryfilecontent? | 05:55 |
| jtv | With cold rows, how would you know? | 05:56 |
| stub | yo | 05:56 |
| lifeless | jtv: https://bugs.launchpad.net/launchpad/+bug/739070/comments/11 | 05:56 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 05:56 |
| lifeless | jtv: science :> | 05:56 |
| stub | lifeless: I don't think is very good | 05:56 |
| jtv | It's still considerably less than you'd expect from a full seek per row. | 05:57 |
| lifeless | stub: https://bugs.launchpad.net/launchpad/+bug/739070/comments/6 | 05:57 |
| _mup_ | Bug #739070: Archive:+repository-size timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 05:57 |
| jtv | lifeless: no I don't mean how do you know it's 2.8 seconds for 1000 rows, but how would you know whether it's "about right." | 05:57 |
| lifeless | jtv: we're seeing 2.5ms per row, thats plausible with many redundant spindles | 05:57 |
| lifeless | jtv: I would ask someone familiar with our db's guts :> | 05:58 |
| jtv | Regardless, it's all a question of access patterns isn't it? It could probably be 5x worse, it could probably be 500x better. | 05:59 |
| lifeless | jtv: not really | 05:59 |
| lifeless | jtv: if this is slower than we'd anticipate given our hardware and prior experience, then we can go digging for issues like table/index bloat, contention whatever | 06:00 |
| lifeless | jtv: if this is approx as fast as we'd expect on an average day, then we're wasting time if we do that and we should instead look at how to either avoid it being cold or avoid accessing the rows | 06:00 |
| StevenK | wgrant: Want to hear something awesome? | 06:00 |
| StevenK | wgrant: gina.txt has been running for 20 *minutes* locally. | 06:01 |
| stub | So that is 695 index lookups and row lookups, so pulling a minimum of 1400 blocks off the disk random access | 06:01 |
| jtv | lifeless: what I'm trying to say is that cold random reads have so many unknowns that this sample size seems inadequate. | 06:01 |
| wgrant | StevenK: It normally only takes 60 seconds. I think you have a bug. | 06:01 |
| StevenK | wgrant: Or I've broken it into pieces. | 06:01 |
| StevenK | And since it's a doctest, I have to printf-debug | 06:02 |
| lifeless | StevenK: how do you go from 695 -> 1400 blocks ? | 06:02 |
| lifeless | bah | 06:02 |
| lifeless | stub: ^ | 06:02 |
| lifeless | stub: heuristic of 2:1 (index + table) ? | 06:02 |
| jtv | (It would be pretty nice if postgres could at least profile distribution of I/O latencies) | 06:02 |
| lifeless | jtv: that would be awesome | 06:03 |
| lifeless | jtv: I agree that there are many unknowns | 06:03 |
| stub | Read a bucket in the index == pull one block from disk. Read that row from disk == pull one block from disk. | 06:03 |
| jtv | (The stupid thing is, we've been thinking of I/O costs in terms of FS cache misses, which is impossible to predict and may soon be an outdated concept anyway. If we could just look at it from an empirical standpoint, we might win something.) | 06:04 |
| lifeless | its about 150 bytes per row min, so what 25 per page | 06:04 |
| lifeless | on a 14M row set we're very likely to get one page per row | 06:04 |
| stub | So 700*2 == 1400, == the minimum if we somehow magically only load up wanted information from the index | 06:04 |
| lifeless | stub: kk, thats cool, i have the same basic model | 06:05 |
| lifeless | stub: was just checking | 06:05 |
| stub | Ok. I was assuming the size of the table would make it unlikely to get multiple rows in a page. | 06:05 |
| lifeless | yeah, an assumption I agree with | 06:05 |
| lifeless | the BPPH table is very spread over time | 06:05 |
| lifeless | jtv: thats not my model of IO costs | 06:05 |
| jtv | Not "we" personally; I mean the world. | 06:06 |
| stub | The index should be much more tightly packed too. | 06:06 |
| lifeless | jtv: ah; so I don't think the world thinks of IO that way per se ;) - see for instance the scale free algorithms work | 06:06 |
| lifeless | jtv: which models IO as tiers of progressively bigger and slower cache | 06:06 |
| jtv | Well okay, the database world. | 06:07 |
| jtv | And that model is still wrong, is my point. | 06:07 |
| stub | lifeless: Oh... and the toast lookups for the md5 and sha1 hashes which are stored as text, so potentially another 4 lookups | 06:07 |
| lifeless | jtv: they seem to have /very/ good results doing this - noting that they start with the CPU L1 cache and work out | 06:07 |
| lifeless | stub: even if we're not looking at the columns (as my rephrased cheaper-estimate query doesn't) | 06:08 |
| jtv | Yes, but that's cache-oblivious algorithms isn't it? I'm talking database. | 06:08 |
| lifeless | jtv: it is, but database will get those algorithms eventually I suspect | 06:08 |
| stub | lifeless: I think that will avoid loading the data from the toast tables, yes. | 06:08 |
| lifeless | that or mlock() the entire table | 06:08 |
| jtv | (And I'm not talking cache-oblivious database either: we can worry about that once that world finally catches on to space-filling curves) | 06:08 |
| lifeless | jtv: I think its percona that have a space-filling curve index | 06:09 |
| jtv | lifeless: There have long been cache-oblivious algorithms for databases. I worked on a cache-oblivious join algorithm 2 jobs ago. | 06:09 |
| lifeless | jtv: very similar to bzr's index /packing logic in fact | 06:09 |
| lifeless | jtv: \o/ | 06:09 |
| lifeless | stub: so what I'm trying to assess, is there some way to get this down to < 2 seconds reliably (we have to do a parallel query for the source package data) | 06:11 |
| jtv | But when it comes to buffer management and individual query optimization, my point is is we can't afford to keep thinking "what if this misses in FS cache and the seek is long" because it just gets too complex: SSD, on-disk cache, bad blocks, network latency. | 06:11 |
| lifeless | stub: or should we be maintaining the archive size as a cache | 06:11 |
| lifeless | stub: its currently 9 seconds with the original query, 6.6 seconds in my rephrased one | 06:12 |
| jtv | StevenK, wgrant: should the "synchronize the simple updates" button on +localpackagediffs update blacklisted differences as well? | 06:13 |
| lifeless | stub: and we're seeing ~ 7 of these a day where its stuttering (presumably on IO) | 06:13 |
| wgrant | jtv: No. | 06:13 |
| stub | lifeless: So your theory is this query will often be cold due to access patterns so the lfc lookups will sometimes be too slow? I'm trying to think if we have other pages accessing more than a few dozen lfc rows. | 06:14 |
| stub | More of the ones I can think of are dealing with bulk packaging data and are slow too | 06:15 |
| lifeless | stub: bug attachments show their size in the comment, for some bizarre reason | 06:15 |
| lifeless | very busy bug pages could access hundreds; *but* we will paginate those eventually | 06:15 |
| lifeless | so not relevant here | 06:15 |
| wgrant | lifeless: That's also the only non-packaging one I can think of. | 06:15 |
| stub | lifeless: Bug attachments are fine as it would be rare for a page to have more than a dozen attachments. | 06:16 |
| wgrant | Some have hundreds. | 06:16 |
| jtv | wgrant: I'll take your word for it. | 06:16 |
| lifeless | stub: its rare, but I can link you to the bugs :> | 06:16 |
| wgrant | jtv: That is sort of the point of blacklisting. | 06:16 |
| lifeless | stub: I don't think its *often* cold, but I think its cold *often enough* | 06:16 |
| lifeless | specifically I don't think we do this query on this dataset anywhere else except *perhaps* on package upload (for quota checking) | 06:17 |
| jtv | wgrant: well, unless maybe we have automated syncing and then users start blacklisting dsds they feel will behave correctly without human attention. | 06:17 |
| wgrant | jtv: Then we've redefined the term. | 06:17 |
| jtv | wgrant: so it sort of requires a conscious decision that blacklisting means "I don't want this change" and not "I don't want to see this change." | 06:17 |
| stub | yeah. so caching the archive size is fine for this query. I'm wondering if there is something more generic we can do to solve slowness in similar pages. The packaging tables always seem to be an issue - large, and the users want complex reports. | 06:17 |
| wgrant | jtv: At the moment the Ubuntu sync blacklist blacklists the sync. | 06:17 |
| lifeless | stub: so in this particular case; there is a missing index that would drop the rows examined by 6000 in the packaging table | 06:18 |
| lifeless | stub: I don't know if its worth adding | 06:18 |
| lifeless | I don't think it will solve the problem | 06:18 |
| StevenK | jtv: It effectively means "I don't care" | 06:18 |
| jtv | wgrant: fine by me; the "I'll take your word for it" still stands but in light of yesterday's conversation I thought I'd at least ask. :) | 06:18 |
| wgrant | Heh. | 06:19 |
| wgrant | StevenK: ^^ | 06:19 |
| jtv | StevenK: that seems to contradict wgrant's take. | 06:19 |
| wgrant | Do you agree? | 06:19 |
| wgrant | Oh, he's here. | 06:19 |
| jtv | Alas, yes. | 06:19 |
| jtv | <wink> | 06:19 |
| wgrant | StevenK: You mean "I don't care what the parent thinks"? | 06:19 |
| lifeless | stub: ok, I'll update this bug to say 'needs cached figures' | 06:19 |
| StevenK | More correctly: "I don't care about this difference" | 06:19 |
| jtv | wgrant is showing his age | 06:20 |
| jtv | "I don't care what my parents think" | 06:20 |
| StevenK | "I'll hack on Launchpad even if my father thinks that Web 2.0 is wrong! I'll show them!" | 06:21 |
| jtv | StevenK: humans may not think they care, but it'd be nice to have a clear notion of whether they have a right to be disappointed if the blacklisted difference stops the package from updating. | 06:21 |
| StevenK | jtv: Yes, a blacklisted difference stops a sync | 06:21 |
| jtv | Of course the button I'm building will sort of eliminate an excuse for blacklisting packages that should be updated. | 06:21 |
| * jtv updates his tests. | 06:21 | |
| StevenK | Keep in mind there are two blacklist states | 06:22 |
| stub | lifeless: So that query is broken anyway, because the distinct on is lacking an order by so it isn't doing what the author thought it is doing | 06:22 |
| lifeless | stub: my one ? | 06:23 |
| stub | the one in the bug comment you linked me to | 06:23 |
| lifeless | stub: my rephrased one is the one with the subselect | 06:23 |
| lifeless | stub: it doesn't need the order by | 06:23 |
| StevenK | Ran 1 tests with 1 failures and 0 errors in 35 minutes 35.459 seconds. | 06:23 |
| lifeless | stub: look at the plan: it orders to do the distinct and unique automatically | 06:23 |
| StevenK | WHEEE! | 06:23 |
| stub | lifeless: That is fine if you happen to get the plan you are expecting. | 06:24 |
| jtv | StevenK: not too worried about the two blacklist states; I'm whitelisting, not blacklisting statuses. Are we confused yet? :) | 06:25 |
| stub | lifeless: So we really need the order by, esp if we want this to survive future PG upgrades. | 06:25 |
| stub | (and with luck, it will be a noop with the expected plan) | 06:26 |
| lifeless | stub: I'd like to learn more about this | 06:26 |
| lifeless | stub: which docs should I read? | 06:26 |
| StevenK | jtv: Don't make me kick you. | 06:26 |
| stub | lifeless: This is documented in the DISTINCT ON section of the SELECT page in the SQL Reference guide for PostgreSQL | 06:27 |
| stub | Sorry - 'DISTINCT clause' section | 06:27 |
| stub | file:///usr/share/doc/postgresql-doc-8.4/html/sql-select.html | 06:27 |
| lifeless | stub: so, I read that | 06:30 |
| lifeless | stub: and it doesn't conflict with what I've done | 06:30 |
| lifeless | stub: because - 'Note that the "first row" of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first' | 06:30 |
| lifeless | thats fine, we're selecting identical rows, so whichever row comes first is ok | 06:31 |
| lifeless | stub: anyhow, I can add a sort in | 06:31 |
| lifeless | stub: but we don't use that crafted query /anyway/ because I was seeing if we could make it fast without caching etc | 06:32 |
| stub | lifeless: nm. You are correct I think. | 06:32 |
| stub | I wonder if it changed, or if I'm thinking of a similar statement? I'm sure there was one that if you neglected the ORDER BY you can get duplicate results | 06:33 |
| stub | lifeless: So in this case you can use the SQL standard "SELECT DISTINCT libraryfile, filesize" rather than SELECT DISTINCT ON (libraryfile) filesize, but the cost saving is statistically insignificant. | 06:36 |
| lifeless | stub: interesting; we don't need libraryfile at all anyhow, just the summed sizes | 06:37 |
| stub | lifeless: Should we be using rabbitmq instead of triggers to maintain BugSummary btw? | 06:37 |
| lifeless | stub: it would remove all the races | 06:38 |
| lifeless | stub: I have a branch for rabbitmq but ec2 threw it out | 06:38 |
| lifeless | stub: I don't know why yet and haven't gotten back to it | 06:38 |
| stub | (now that I think the DB patch is done, and just waiting on tests to confirm this hypothesis :) ) | 06:38 |
| lifeless | :> | 06:39 |
| lifeless | stub: thanks! | 06:39 |
| lifeless | I've written up my theory in https://bugs.launchpad.net/launchpad/+bug/739070 | 06:39 |
| _mup_ | Bug #739070: Archive:+repository-size timeout retrieving many hundreds of package sizes <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739070 > | 06:39 |
| lifeless | just the top of the bug summary | 06:39 |
| stub | lifeless: I needed to change the structure a bit - we might be race free now with the simpler triggers that I thought were needed to catch some potential modifications | 06:41 |
| lifeless | bug_fti || 76% || 612 MB of 798 MB | 06:41 |
| StevenK | wgrant: I fixed gina! | 06:42 |
| lifeless | stub: that would be cool, but the case of 'person subscribes and the bug is made public' - how will that be race free? | 06:42 |
| wgrant | StevenK: Oh? | 06:42 |
| StevenK | wgrant: Well, the test now takes 65 seconds, rather than 2135. | 06:42 |
| wgrant | That's more normal. | 06:42 |
| wgrant | What did you break? | 06:42 |
| StevenK | wgrant: gina needed access to DSP | 06:43 |
| wgrant | Ah. | 06:43 |
| StevenK | Since she creates DSDJs | 06:43 |
| wgrant | Yes. | 06:43 |
| wgrant | Anyone want to review https://code.launchpad.net/~wgrant/launchpad/bfj-different-urls/+merge/59730? Fairly long, but mostly just sed applied to test. | 06:43 |
| wgrant | +s | 06:43 |
| jtv | wgrant: I'll take it | 06:44 |
| lifeless | stub: have we got enough bloat-changing data to point at (or exclude) bug heat yet ? | 06:45 |
| lifeless | stub: or equally, backups | 06:45 |
| stub | lifeless: yer... I think the race is still there. | 06:46 |
| lifeless | stub: I thought of a way to make it detect races | 06:46 |
| stub | lifeless: No, I haven't got the data to confirm the cause. | 06:46 |
| lifeless | stub: but you'll either cry or aim a nuke at me. | 06:46 |
| lifeless | stub: and I don't want to cause either event. | 06:47 |
| stub | We can serialise it by using an advisory lock. | 06:47 |
| lifeless | stub: the way would be in any transaction affecting a bug, update a row in a common table, to for serialization detection | 06:47 |
| lifeless | a lock sounds better :> | 06:49 |
| stub | And advisory lock will do the same thing, and be explicit and faster. yes. | 06:49 |
| StevenK | bzr di can't handle multiple revspecs? :-) | 07:10 |
| StevenK | :-( rather | 07:10 |
| lifeless | StevenK: -r x..y | 07:11 |
| StevenK | lifeless: I'd like to skip one in the middle | 07:12 |
| lifeless | you may want difftastic | 07:12 |
| LPCIBot | Project windmill-devel build #2: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-devel/2/ | 07:13 |
| StevenK | lifeless: Google doesn't show anything relevant for that? | 07:13 |
| lifeless | aarons plugin for lp merge proposals to show incremental diffs | 07:14 |
| wgrant | difftacular? | 07:14 |
| StevenK | Perhaps I'll just use filterdiff | 07:14 |
| lifeless | whata the rev you want to skip? a merge? | 07:15 |
| StevenK | Yes | 07:15 |
| lifeless | interdiff / difftcular is what yo uneed then | 07:15 |
| StevenK | I can generate the two diffs, interdiff shows the diff between them, how does that help? | 07:17 |
| StevenK | Oooh, I see. combinediff | 07:19 |
| jtv | wgrant: done | 07:19 |
| lifeless | bbiab | 07:35 |
| jtv | wgrant: in case I didn't get through earlier, your review is done. | 08:25 |
| jtv | Anyone care for a simple, short cleanup review? https://code.launchpad.net/~jtv/launchpad/db-pre-747546/+merge/59737 | 08:25 |
| StevenK | Bah, I was about to answer him, too | 08:28 |
| StevenK | jtv: r=me | 08:29 |
| jtv | thanks | 08:29 |
| lifeless | jml: hi | 08:29 |
| lifeless | jml: sorry I was afk; was fooding | 08:30 |
| jtv | StevenK: and fwiw you're absolutely right about moving it. One battle at time though. | 08:30 |
| StevenK | jtv: Sure, which is why I just approved it | 08:31 |
| jtv | We're in loud agreement. | 08:31 |
| StevenK | jtv: You probably could have targetted devel, too | 08:31 |
| jtv | Yes, but I already have these changes in another branch and I want to had them off at the diff. | 08:32 |
| StevenK | jtv: Just saying, is all | 08:33 |
| jtv | That is understood. | 08:33 |
| wgrant | jtv: Thanks. It changes the URLs used by the API, but not the API itself. | 08:44 |
| jtv | Very well. | 08:44 |
| adeuring | good morning | 08:46 |
| rvba | wgrant: Hi! I modified the call sites of Archive.syncSource like you suggested ... you might want to have a look since the modification is kind of sensitive (https://code.launchpad.net/~rvb/launchpad/change-perm-sync/+merge/59341). | 08:54 |
| wgrant | rvba: I think CannotCopy exceptions are exposed in the UI, so you probably want to check that their values will be sensible. | 08:58 |
| rvba | wgrant: good point. | 08:59 |
| wgrant | Otherwise that looks great. | 08:59 |
| bigjools | morning all | 08:59 |
| wgrant | Morning bigjools. | 08:59 |
| rvba | bigjools: Morning! | 08:59 |
| bigjools | what's broken? :) | 08:59 |
| wgrant | You survived your vacation without PSN? | 08:59 |
| bigjools | yeah, I got a copy of Portal 2 :) | 09:00 |
| wgrant | Ah, 'tis an excellent game. | 09:00 |
| bigjools | I like Valve stuff anyway | 09:00 |
| wgrant | although dissapointingly short. | 09:00 |
| * bigjools sees size of inbox | 09:06 | |
| StevenK | bigjools: And you run screaming? | 09:07 |
| StevenK | A GLaDOS reference somewhere in Soyuz would be apt. | 09:07 |
| bigjools | I am gently rocking backwards and forwards while hugging a small furry toy | 09:07 |
| bigjools | StevenK: ha | 09:08 |
| mrevell | Good morning! | 09:09 |
| lifeless | jml: ready when you are | 09:11 |
| jtv | hi mrevell | 09:13 |
| === almaisan-away is now known as al-maisan | ||
| jml | lifeless: hi | 09:49 |
| lifeless | hi | 09:49 |
| jml | lifeless: sorry, I got distracted by my RSS feeds. | 09:49 |
| lifeless | skype/voip either is good | 09:49 |
| jml | lifeless: ok. what's your voip number? | 09:49 |
| lifeless | jml: thats ok, its only getting vs is late :) | 09:49 |
| lifeless | jml: actually, skype is better because I don't need a headset ;) | 09:49 |
| lifeless | ekigas echo detection is still poor | 09:50 |
| jml | lifeless: ok. skype. | 09:50 |
| StevenK | allenap: http://pastebin.ubuntu.com/602641/ ; thanks! | 09:53 |
| allenap | StevenK: Cheers. | 09:54 |
| henninge | wgrant: Hi! | 10:26 |
| === gmb changed the topic of #launchpad-dev to: PQM in RC mode | https://dev.launchpad.net/ | On call reviewer: gmb | https://code.launchpad.net/launchpad-project/+activereviews | ||
| wgrant | henninge: Hi. | 10:53 |
| henninge | wgrant: Do you happen to know if bug 776160 is a duplicate? | 10:54 |
| _mup_ | Bug #776160: mail headers inconsistent between FAILEDTOUPLOAD and FAILEDTOBUILD <Launchpad itself:Triaged> < https://launchpad.net/bugs/776160 > | 10:54 |
| wgrant | henninge: I don't think it is. | 10:54 |
| henninge | wgrant: thanks | 10:54 |
| === al-maisan is now known as almaisan-away | ||
| henninge | I have a problem writing a view test for bug 644872. | 10:57 |
| _mup_ | Bug #644872: UnicodeEncodeError in search_text field <faqs> <lp-answers> <oops> <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/644872 > | 10:57 |
| henninge | I can trigger it in the UI by searching "português" here: https://answers.launchpad.net/ubuntu/ | 10:58 |
| bigjools | wgrant, rvba: regarding the sync package permission change, did you think about how it'll fit in when we start doing it asynchronously? | 10:59 |
| wgrant | bigjools: Do we have a plan for that yet? | 10:59 |
| rvba | bigjools: I'm afraid not. But how is this particular change (the permission change) related to that exactly? | 11:00 |
| bigjools | wgrant: sorta. The job is done but not used. allenap is working on changing the job schema so we can query across archive/series and display something to the user to show pending jobs. Then we'll switch over the syncing first, maybe PPA copies in the future. | 11:00 |
| bigjools | rvba: the check will happen in the job, not the UI. | 11:00 |
| bigjools | it would be nice if it happened in the UI but I think it'll bust the query time | 11:01 |
| wgrant | bigjools: This seems like it's only useful for mass copies. | 11:01 |
| rvba | the permission check is now done in the copyChecker along with the various other checks | 11:01 |
| bigjools | wgrant: correct. We might decide an arbitrary number of packages, over which we use the job rather than synchronously. The next step is to design the UI. | 11:02 |
| wgrant | bigjools: Great. | 11:02 |
| wgrant | bigjools: As long as you're not trying to do async for normal copies. | 11:02 |
| wgrant | When immediate feedback is helpful. | 11:02 |
| bigjools | wgrant: define "normal" | 11:02 |
| bigjools | not trying to do async for *anything* yet :) | 11:03 |
| wgrant | bigjools: PPA copies, mostly. | 11:03 |
| wgrant | Not let's-sync-20%-of-the-archive. | 11:03 |
| bigjools | not initially but I have PPAs in mind | 11:03 |
| bigjools | since some PPA copying times out still | 11:03 |
| wgrant | It's very fixable. | 11:04 |
| wgrant | Most of the time in most cases is now spent in the UI. | 11:04 |
| wgrant | Determining the list of sources. | 11:04 |
| bigjools | ok | 11:04 |
| wgrant | But there are some very expensive build queries when there is a potential source conflict in the destination (which is rare) | 11:04 |
| wgrant | And delayed copy creation is slow :( | 11:05 |
| bigjools | wgrant: what do you think is a good number? 50? 100? (total source+binaries) | 11:07 |
| wgrant | bigjools: NFI | 11:07 |
| wgrant | We may need science. | 11:07 |
| * bigjools licks finger and holds to the wind | 11:08 | |
| wgrant | henninge: Wishlist doesn't exist. We are using Low instead. | 11:11 |
| wgrant | (just hope Rob doesn't notice you doing that ;)) | 11:11 |
| henninge | wgrant: thanks ;) | 11:12 |
| henninge | wgrant: I'll fix the documentation | 11:12 |
| wgrant | I thought it already was fixed :( | 11:12 |
| henninge | We map these buckets into: | 11:13 |
| henninge | critical : generally empty, bugs that need to jump the queue go here. | 11:13 |
| henninge | high: bugs that are likely to get attention within 6 months | 11:13 |
| henninge | low [or perhaps wishlist]: All other bugs. | 11:13 |
| henninge | that sounds old | 11:13 |
| henninge | is the critical definition current? | 11:14 |
| wgrant | Yes. | 11:15 |
| wgrant | But ZOP means it's not empty. | 11:15 |
| wgrant | Yet. | 11:15 |
| henninge | Ah, I see. | 11:15 |
| wgrant | We have 5 years of debt to repay. | 11:15 |
| henninge | ok, doc changed. | 11:16 |
| henninge | low: All other bugs. | 11:16 |
| henninge | We don't use wishlist. | 11:16 |
| wgrant | Thanks. | 11:16 |
| bigjools | rvba: regarding the permission changes to syncing, I am concerned that users with zero permissions can cause a load on the job runner | 11:19 |
| bigjools | and in the webapp for direct syncs, for that matter | 11:19 |
| rvba | bigjools: good point, but is there a "small" permission that can be checked before doing the sync? | 11:20 |
| bigjools | rvba: I'm trying to work that out now :) Ideally, we need a "has any permission at all?" check | 11:21 |
| wgrant | If it's too expensive to check all permissions at the time of the request, you could just check for any ArchivePermission on the Archive. | 11:21 |
| bigjools | right | 11:21 |
| bigjools | in fact the upload processor does this somewhere | 11:21 |
| * bigjools digs | 11:21 | |
| wgrant | If you use the upload processor as a model for anything I will cry. | 11:21 |
| * bigjools slaps wgrant | 11:21 | |
| wgrant | But yes. | 11:21 |
| wgrant | It's struct_component on checkUpload. | 11:22 |
| wgrant | s/struct/strict/ | 11:22 |
| wgrant | But it's not quite right. | 11:22 |
| wgrant | Oh, no, there's that other thing too. | 11:22 |
| wgrant | Argh this is such a mess. | 11:22 |
| bigjools | yes | 11:22 |
| bigjools | blame Ubuntu policies | 11:22 |
| wgrant | Yeah, see Archive.verifyUpload | 11:23 |
| wgrant | if not self.getComponentsForUploader(person): | 11:23 |
| wgrant | But it's buggy because it only considers components. | 11:23 |
| bigjools | le sigh | 11:23 |
| wgrant | A bug exists for that, I believe. | 11:23 |
| wgrant | But the any-permission-at-all check is pretty simple to query for. | 11:24 |
| bigjools | yep, we can just join TP to AP | 11:24 |
| wgrant | Exactly. | 11:24 |
| wgrant | Really cheap. | 11:24 |
| bigjools | rvba, ok? | 11:24 |
| rvba | bigjools: sounds ok. Just tell me what TP and AP are | 11:24 |
| rvba | ArchivePerm | 11:25 |
| wgrant | TeamParticipation | 11:25 |
| wgrant | It is a flattened version of TeamMembership. | 11:25 |
| rvba | ok | 11:25 |
| wgrant | So it contains indirect memberships too. | 11:25 |
| bigjools | make life so much easier when querying | 11:25 |
| wgrant | And faster. | 11:25 |
| wgrant | And less recursive. | 11:25 |
| wgrant | And less reliable... | 11:25 |
| bigjools | so if someone has any AP at all, show the button | 11:25 |
| bigjools | otherwise, nada | 11:25 |
| rvba | all right. I'm on it. | 11:26 |
| rvba | wgrant: why "less reliable"? | 11:26 |
| wgrant | There are occasional bugs in its maintenance. | 11:26 |
| wgrant | So it gets inconsistent with TM. | 11:27 |
| rvba | I suppose it gets periodically whipped out and recalculated then. | 11:27 |
| LPCIBot | Project windmill-db-devel build #230: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-db-devel/230/ | 11:28 |
| jtv | allenap: are you all caught up? | 11:45 |
| allenap | jtv: In what? :) | 11:46 |
| jtv | allenap: ah | 11:46 |
| allenap | jtv: I assume you want to talk about the sync button? | 11:46 |
| jtv | Yes! | 11:46 |
| allenap | jtv: IRC, Mumble, Skype? | 11:46 |
| jtv | I've been asked to make a change to the indexes initialization code, which means dropping my ongoing work on the sync button. | 11:46 |
| jtv | IRC would be convenient for me right now (headset is charging). | 11:47 |
| allenap | jtv: Okay. | 11:47 |
| jtv | Now, the code I have should be in a pretty nice shape. | 11:47 |
| jtv | I'm trying to make useful notes. | 11:48 |
| jtv | And Steve said you'd been working on something called... SyncPackageJob? | 11:48 |
| allenap | jtv: SyncPackageJob has been reincarnated as PackageCopyJob, but yes. | 11:49 |
| allenap | Instead of calling IArchive.syncSource() it calls do_copy() directly, and so can copy multiple packages in a single job. | 11:49 |
| henninge | Can anybody give me a clue why this test http://paste.ubuntu.com/602716/ produces this output http://paste.ubuntu.com/602717/ ? | 11:50 |
| jtv | allenap: ahhh so copying and syncing really are more or less the same thing? | 11:50 |
| henninge | For some reason, "search_text" is an "object", not a string. | 11:50 |
| allenap | jtv: Yeah, so it seems :) syncSource() and syncSources() both end up calling do_copy(). | 11:51 |
| jtv | henninge: no idea; looks like it might be one of those uses of object() as a way of creating a guaranteed-unique value in cases where None already has a meaning. | 11:53 |
| jtv | allenap: Thanks. I'll update my comments so at least that is correct. | 11:53 |
| henninge | jtv: thanks for looking at it ;) | 11:55 |
| jtv | allenap: another point is that the button's working title is Upgrade Packages. There may well be a better name for that. I'm told cjwatson would probably know. | 11:56 |
| henninge | adeuring: Moin! Do you have an idea ^^ (My question with the two pastebins) | 11:56 |
| allenap | jtv: Cool. | 11:56 |
| * adeuring is looking | 11:57 | |
| cjwatson | the main thing to be careful of is to draw a distinction between pulling in new versions of unmodified packages from the upstream distribution, which can be done verbatim, and pulling in new versions of packages that have been modified downstream, which requires human attention (and is, I hope, outside the scope of this button) | 11:58 |
| jtv | cjwatson: thanks. That is correct: the harder case is outside the scope of this button. | 11:58 |
| jtv | The big question right now is what should be on the button. | 11:58 |
| cjwatson | in Ubuntu jargon we call those "sync" and "merge" respectively | 11:58 |
| bigjools | its label? | 11:58 |
| jtv | bigjools: yes | 11:59 |
| bigjools | "sync all unchanged" ? | 11:59 |
| jtv | Well they are unchanged, but in the parent. | 11:59 |
| bigjools | or sommat | 11:59 |
| adeuring | henninge: after looking at an "advanced search" page, I'd suggest: s/search_text/searchtext/ | 11:59 |
| henninge | hm | 11:59 |
| bigjools | cjwatson: do you differentiate in nomemclature between a single sync and the mass-sync? | 12:00 |
| bigjools | nomenclature, even | 12:00 |
| henninge | adeuring: I'll try but this is the equivalent in the UI: | 12:00 |
| henninge | https://answers.launchpad.net/ubuntu/+questions?field.search_text=portugu%C3%AAs&field.actions.search=Search&field.status=OPEN | 12:00 |
| jtv | bigjools, cjwatson: I'd also like to be very clear in the distinction between the "interesting" cases and this simple case. | 12:01 |
| cjwatson | bigjools: no | 12:01 |
| bigjools | ok | 12:01 |
| henninge | adeuring: does not help but interestingly gives the same error. | 12:01 |
| jtv | Just repeating the word "sync" all over the place and making the button labels very long doesn't quite do it for me. | 12:01 |
| adeuring | henninge: weird... | 12:01 |
| henninge | adeuring: it's like it does not see the parameter. | 12:01 |
| bigjools | cjwatson: when someone wants a brand new package, presumably its uploaded rather than synced? | 12:01 |
| lifeless | henninge: thanks | 12:01 |
| jtv | henninge: then it may just mean that the data dict is uninitialized and there's a get(foo, object()) | 12:01 |
| cjwatson | bigjools: that's generally synced too | 12:01 |
| bigjools | interesting | 12:02 |
| cjwatson | bigjools: well, if it was in Debian and we can just reuse that, anyway | 12:02 |
| cjwatson | bigjools: if they do it from scratch for Ubuntu, that's an upload | 12:02 |
| bigjools | well, sync-source is rather esoteric | 12:02 |
| adeuring | henninge: have a look at https://bugs.launchpad.net/launchpad/+bugs?advanced=1 . There is this tag: <input class="textType" id="field.searchtext" ... | 12:02 |
| cjwatson | not especially, it's rather simple-minded | 12:02 |
| bigjools | cjwatson: right, ta | 12:02 |
| cjwatson | in our terminology, "sync" is any case where we copy a package verbatim from another archive | 12:02 |
| jtv | Packages that are in the parent but not the derived series are another thing I'd very much like to stay away from, naming-wise. | 12:02 |
| bigjools | yeah, makes sense | 12:02 |
| cjwatson | (source-only) | 12:03 |
| henninge | adeuring: I am quite sure it's "search_text" in this case. | 12:03 |
| cjwatson | I'm not wedded to that terminology, but if you do use the word "sync" then it should match those semantics, IMO | 12:03 |
| bigjools | yup, that's been my assumption all along | 12:04 |
| bigjools | we're not touching mergers | 12:04 |
| bigjools | merges | 12:04 |
| adeuring | henninge: argh... your bug is about questions, not bugs, right? | 12:04 |
| * adeuring was looking in the wrong place... | 12:04 | |
| henninge | adeuring: it is. Sorry. | 12:04 |
| jtv | bigjools, cjwatson: would "upgrade" be a good word to use then, for the case where it's merely an upgrade that's being pulled in? | 12:04 |
| wgrant | The same button will also probably sync new packages. So I doubt it. | 12:05 |
| cjwatson | personally, "upgrade" sounds like something users do | 12:05 |
| cjwatson | and yeah, I'm not sure I see any value in a UI distinction between install/upgrade in the button name | 12:05 |
| bigjools | cjwatson: oh one more thing, we're going to auto-create indexes in new series as part of the first publisher run. I think you'll still be able to do compare-archive even without disabling the publisher since the release pocket won't change and the new series is frozen | 12:06 |
| wgrant | I think we should reuse the terminology from everywhere else in LP: just say copy. | 12:06 |
| cjwatson | bigjools: doesn't the first publisher run already create indexes? unless you're talking about some indexes I'm not aware of | 12:06 |
| cjwatson | I think I agree with wgrant | 12:07 |
| cjwatson | it's a source-only copy | 12:07 |
| bigjools | cjwatson: the "careful" mode I mean | 12:07 |
| jtv | The button as specified doesn't copy new packages. | 12:07 |
| wgrant | cjwatson: initialisation will automatically create the indices. | 12:07 |
| wgrant | cjwatson: No need for a manual run any more. | 12:07 |
| cjwatson | oh, right | 12:07 |
| cjwatson | sure, whatever :) | 12:07 |
| bigjools | heh | 12:07 |
| wgrant | Click button in the web UI, it will do the rest. | 12:07 |
| bigjools | cjwatson: is compare-archive really necessary anyway? | 12:07 |
| wgrant | No manual i-f-p or p-d or blah. | 12:07 |
| cjwatson | bigjools: it's just paranoia | 12:07 |
| bigjools | figured | 12:07 |
| cjwatson | and it doesn't cost you guys anything | 12:08 |
| cjwatson | but yeah, less manual work => good | 12:08 |
| bigjools | yeah I didn't think there'd be any complaints :) | 12:08 |
| bigjools | we need to do it for derivations, or they will need someone to ssh in to somewhere | 12:09 |
| cjwatson | jtv: hm, well, sync-source can only go away once we have some other way to copy new packages | 12:09 |
| cjwatson | so that sounds like a spec weakness | 12:09 |
| bigjools | there is a way, it's in the spec | 12:09 |
| wgrant | I wasn't aware it wasn't going to copy everything :( | 12:09 |
| wgrant | bigjools: Also, how are we going to push copies through the queue? | 12:09 |
| bigjools | we're not | 12:09 |
| wgrant | Erm. | 12:10 |
| wgrant | Erm. | 12:10 |
| bigjools | well, it doesn't do that right now | 12:10 |
| wgrant | Clearly. | 12:10 |
| wgrant | But it needs to. | 12:10 |
| bigjools | out of scope | 12:10 |
| cjwatson | so right now, syncs get away with going through a specialised queue (ignoring unapproved etc.) because only archive admins can run it | 12:10 |
| === almaisan-away is now known as al-maisan | ||
| bigjools | right | 12:11 |
| cjwatson | once it's opened up to everybody, not going through the queue means that any developer can break our release management around milestones and we can't stop them | 12:11 |
| cjwatson | so if it's out of scope, it needs to be turned off :-) | 12:11 |
| bigjools | heh | 12:11 |
| wgrant | That is my point, yeah. | 12:11 |
| wgrant | We can't allow syncSource into a primary archive unless it goes through the que. | 12:11 |
| wgrant | +ue | 12:11 |
| bigjools | the other option is to restrict copying to archvie admins until we add queueing | 12:11 |
| wgrant | Since it would allow anyone to copy into -updates, for example. | 12:11 |
| wgrant | == bad | 12:11 |
| * cjwatson nods | 12:14 | |
| bigjools | cjwatson: so, you'd be happy with all syncs going through the normal queue process that uploads do? (including auto-acceptance etc) | 12:16 |
| adeuring | henninge: trying to reproduce your problem, I got at first another error: SyntaxError: Non-ASCII character '\xc3' in file ... After s/ê/\x2345, and after adding "with_person_logged_in", create_initialized_view worked for me. | 12:16 |
| henninge | adeuring: thanks, I'll check that after lunch. | 12:17 |
| cjwatson | bigjools: totally | 12:17 |
| === henninge is now known as henninge-lunch | ||
| cjwatson | bigjools: er, modulo mail announcements | 12:17 |
| bigjools | cjwatson: great, I always wondered why sync-source never did that anyway | 12:18 |
| cjwatson | manually requested syncs need announcements on the -changes list; mass autosyncs need to not flood the -changes list | 12:18 |
| bigjools | but as you say, it needs shell anyway | 12:18 |
| wgrant | Yeah. I think mass syncs will have to be AA-driven with a no-mail flag. | 12:18 |
| bigjools | AA? | 12:18 |
| bigjools | oh nm | 12:18 |
| cjwatson | bigjools: I think it's because if you put it through the queue then there's no way to suppress announcements | 12:18 |
| cjwatson | IIRC | 12:18 |
| bigjools | there's always a way :) | 12:18 |
| cjwatson | wgrant: doesn't really help derivatives ... | 12:18 |
| wgrant | Also because the hack wasn't dirty enough, they needed a bit more dirt. | 12:19 |
| wgrant | cjwatson: I mean in the UI. | 12:19 |
| cjwatson | bigjools: well, I mean when we set it up | 12:19 |
| cjwatson | wgrant: ok | 12:19 |
| wgrant | cjwatson: We don't want normal people to copy things in without announcement, do we? | 12:19 |
| cjwatson | oh, actually, there was a BIG reason they went through a separate hacked queue | 12:19 |
| cjwatson | syncs aren't GPG-signed | 12:19 |
| cjwatson | wgrant: no, indeed | 12:20 |
| bigjools | we can handle that now | 12:21 |
| wgrant | bigjools: Oh? | 12:21 |
| StevenK | Perhaps we just implement NSS :-) | 12:21 |
| cjwatson | at the time, though, that's the basic reason why Daniel set it up with a different queue | 12:21 |
| wgrant | StevenK: That's what this is... | 12:21 |
| bigjools | I can't remember *why* but there's code that handles lack of signer | 12:22 |
| wgrant | bigjools: Right, and that's what the backdoor policies use. :( | 12:22 |
| bigjools | not those | 12:22 |
| wgrant | Huh? | 12:22 |
| wgrant | What else accepts uploads with no signer? :/ | 12:22 |
| bigjools | there is actual code that doesn't fall over blindly accessing the signature | 12:22 |
| StevenK | buildd? | 12:22 |
| wgrant | Oh. | 12:22 |
| StevenK | I guess. | 12:22 |
| bigjools | like I said, I can't remember why it's there | 12:23 |
| wgrant | buildd doesn't go anywhere near sigs. | 12:23 |
| StevenK | But it does do uploads. | 12:23 |
| wgrant | Oh, you mean -C buildd? | 12:23 |
| bigjools | cjwatson: which queue? | 12:23 |
| wgrant | -C sync, I presume. | 12:24 |
| wgrant | That is SyncUploadPolicy. | 12:24 |
| cjwatson | yes. | 12:24 |
| cjwatson | ~lp_queue/sync-queue/ for those with cocoplum access. | 12:24 |
| cjwatson | the processing command is LPCONFIG=ftpmaster /srv/launchpad.net/codelines/current/scripts/process-upload.py -d ubuntu -C sync $DRYRUN $NOMAILS -v . | 12:25 |
| StevenK | cjwatson: Of LP devs, that's ... me | 12:25 |
| bigjools | how do the packages get to the local FS? | 12:25 |
| wgrant | sync-source with evil... | 12:26 |
| StevenK | They are grabbed from ftp.uk.debian.org and/or the librarian | 12:26 |
| bigjools | ahhhh | 12:26 |
| wgrant | More evil, that is. | 12:26 |
| bigjools | right, I forgot that sync-source doesn't actually do any uploading does it? | 12:26 |
| cjwatson | no, it creates the files in good order to be copied into a queue | 12:26 |
| bigjools | which queue? | 12:27 |
| cjwatson | see above! | 12:27 |
| bigjools | I mean, LP queue. I presume they just hit accepted? | 12:27 |
| wgrant | They go through whatever SyncUploadPolicy puts them into. Which is normally DONE> | 12:28 |
| bigjools | auto-accepted then | 12:28 |
| bigjools | ok I'll dig later | 12:28 |
| wgrant | Indeed. | 12:28 |
| wgrant | AbstractUploadPolicy.autoApprove returns True. | 12:29 |
| wgrant | The FROZEN handling is in InsecureUploadPolicy. Odd. | 12:29 |
| bigjools | this makes things a little more complicated than I'd anticipated | 12:29 |
| cjwatson | right now yes - but as I say they'd need to be treated slightly more like uploads once this is open to all developers. | 12:29 |
| wgrant | That seems like the sort of thing that really should be elsewhere. | 12:29 |
| cjwatson | the real distinctions we actually need are insecurity and announcements. | 12:29 |
| cjwatson | (AFAICR.) | 12:29 |
| wgrant | Insecurity? | 12:29 |
| wgrant | Oh. | 12:29 |
| wgrant | Right. | 12:29 |
| wgrant | Yes. | 12:29 |
| cjwatson | (no signed .changes) | 12:29 |
| wgrant | Announcements are going to be amusing. | 12:30 |
| bigjools | for NSS that won't be an issue since there's no changes file | 12:30 |
| wgrant | Since we don't have changes files at all for Debian uploads. | 12:30 |
| wgrant | We'll have to parse the changelogs. | 12:30 |
| bigjools | yeah, *that*'s the issue :) | 12:30 |
| cjwatson | sync-source does that already. just move the code around. | 12:30 |
| wgrant | sync-source must burn. | 12:30 |
| wgrant | BURN. | 12:30 |
| cjwatson | but that code is the very bit you need. burning it out of pique is a tad silly. :) | 12:30 |
| wgrant | python-debian makes it easy these days. | 12:30 |
| cjwatson | sure - reuse the business logic though | 12:31 |
| wgrant | Don't need sync-source's regexps. | 12:31 |
| wgrant | It does things like this: | 12:31 |
| wgrant | if previous_version is None: | 12:31 |
| wgrant | previous_version = "9999:9999" | 12:31 |
| wgrant | I'm reluctant to reuse logic that has been near that. | 12:32 |
| bigjools | /o\ | 12:32 |
| cjwatson | I thought I proposed a patch at one point to fix that. | 12:32 |
| wgrant | There was a fix at one point for < 0 versions. | 12:33 |
| wgrant | But I don't recall anything about this bit. | 12:33 |
| cjwatson | sigh, trapped in a local branch | 12:33 |
| cjwatson | http://paste.ubuntu.com/602728/ | 12:33 |
| wgrant | Well, that was easy. | 12:33 |
| cjwatson | (since < 0 versions don't work right now) | 12:33 |
| wgrant | Yeah. | 12:33 |
| wgrant | cjwatson: Can we get away with not attaching a fake changes file -- just compiling the usual email contents? | 12:35 |
| cjwatson | probably | 12:35 |
| wgrant | I don't know of anything that parses the changes files. | 12:35 |
| cjwatson | oh, hm | 12:35 |
| cjwatson | I do | 12:35 |
| wgrant | Can it use the API instead? :) | 12:35 |
| cjwatson | it does | 12:35 |
| cjwatson | we have an API-based thing that we use for compiling point release notes | 12:35 |
| wgrant | Oh, right. | 12:35 |
| cjwatson | it grabs .changes files using the API | 12:35 |
| wgrant | HMm. | 12:35 |
| bigjools | so when we have this in the UI, one button "mass sync" will not send announcements, the other one "sync" will. I assume that's good enough. | 12:35 |
| wgrant | That's slightly upsetting. | 12:35 |
| wgrant | cjwatson: Can I see that code somewhere? | 12:36 |
| cjwatson | http://paste.ubuntu.com/602729/ is the most recent version of it I have to hand | 12:36 |
| wgrant | Hopefully it doesn't want too much. | 12:36 |
| wgrant | Ah, so it just wants bugs? | 12:36 |
| cjwatson | right now I think so, though I think in general having access to the equivalent of changes['changes'] would be good. | 12:37 |
| wgrant | Yeah. Hmm. That's difficult. | 12:37 |
| wgrant | Since the definition of that is a little hazy. | 12:38 |
| cjwatson | it's tricky in cases where the sync skips over several versions | 12:38 |
| wgrant | Right. | 12:38 |
| wgrant | We need to determine the old version. | 12:38 |
| wgrant | Whatever that means... | 12:38 |
| cjwatson | publishing history? | 12:38 |
| wgrant | Sure, we have the data, but we have to work out how to interpret it. And then how to store the changelog entries. | 12:39 |
| wgrant | Unless we just provide a method on SPPH which finds the last published version and grabs the library files and works it out. | 12:40 |
| wgrant | Not quick, but meh. | 12:40 |
| wgrant | Since we don't really have anywhere to store it. | 12:40 |
| cjwatson | bigjools: announcements> yes, sounds good enough | 12:41 |
| cjwatson | (whether it meets your UI guidelines is another matter, but it meets our requirements) | 12:41 |
| wgrant | Come now, you've been around Launchpad for long enough to know how strict and excellent our UI guidelines are.... | 12:41 |
| bigjools | cjwatson: I'll work that out later but it was to clarify the difference for me, which you did | 12:41 |
| cjwatson | it's certainly better than archive admins having to remember which ones need a special flag passed | 12:42 |
| wgrant | Or forgetting to flush normal sync queues before someone does a no-mail run... | 12:42 |
| cjwatson | yeah, though the person who does such a run is supposed to check | 12:43 |
| cjwatson | but it's a bit error-prone | 12:43 |
| StevenK | allenap: O hai -- has my diff made you blind yet? :-/ | 12:55 |
| bigjools | wgrant: I think the queue stuff will be easy-ish. We can refactor the nascentupload checks so they can be re-used. If the package is not auto-accepted, we make the appropriate PU, otherwise copy as we do now. Does that sound sane? | 12:55 |
| wgrant | bigjools: We also need to log the copies. | 12:55 |
| bigjools | log? | 12:56 |
| wgrant | Who did them, and where from. | 12:56 |
| wgrant | At the moment we have no idea. | 12:56 |
| bigjools | joy | 12:56 |
| === henninge-lunch is now known as henninge | ||
| wgrant | I had considered just adding a creator to [SB]PPH. I still think that might be reasonable. | 12:56 |
| wgrant | But it sounds relevant to the queue stuff. | 12:56 |
| bigjools | well we're not losing anything by not doing it if it's not already done, so it's not critical | 12:56 |
| wgrant | cjwatson: Do you want to know who copied things? I presume so. | 12:57 |
| wgrant | It would seem mildly insane to not. | 12:57 |
| cjwatson | wgrant: at the moment we record who requested the sync by pretending they're the uploader | 13:01 |
| wgrant | Right, I know that, but we can't do that any more. | 13:02 |
| cjwatson | that kind of loses information a bit and it would be better to have that in a separate slot | 13:02 |
| wgrant | Yeah. | 13:02 |
| cjwatson | yes, definitely do want to know, for audit trail | 13:02 |
| wgrant | But in the current copy model there is no record (besides appserver logs) | 13:02 |
| wgrant | Right. | 13:02 |
| wgrant | bigjools: ^^ | 13:02 |
| bigjools | well, they are effectively the uploader | 13:02 |
| cjwatson | and it should go out in mail announcements of manual syncs too | 13:02 |
| bigjools | ok | 13:02 |
| cjwatson | bigjools: in the past, Debian people have justifiably got upset at what looks like an Ubuntu person taking credit for their work | 13:02 |
| wgrant | cjwatson: But we also have them getting upset about the opposite :/ | 13:03 |
| cjwatson | so we should have both names | 13:03 |
| wgrant | "I didn't upload that" | 13:03 |
| bigjools | cjwatson: don't they see the different users involved? uploader vs maintainer vs creator? | 13:03 |
| wgrant | uploader/creator are one field in LP. | 13:03 |
| cjwatson | bigjools: by overwriting uploader, we lose one of those | 13:03 |
| wgrant | signer is different, but that's not used for syncs. | 13:03 |
| bigjools | not exactly | 13:03 |
| cjwatson | and signer may be the sponsor in Debian anyway, not the person who actually did the work | 13:04 |
| cjwatson | wgrant: I'm much happier to defend the case where we give too much credit | 13:04 |
| bigjools | sourcepackagerelease.creator | 13:04 |
| wgrant | bigjools: That's Changed-By, right? | 13:04 |
| bigjools | I thought it was the dsc signer? can't remember! | 13:04 |
| cjwatson | as for recording the Ubuntu side of it: we do need to do that because it's used as part of people's applications for Ubuntu upload rights | 13:04 |
| wgrant | No. | 13:04 |
| wgrant | bigjools: SPR.dscsigningkey | 13:05 |
| wgrant | Huh. | 13:05 |
| bigjools | I would like to maintain uploaded-by as-is | 13:05 |
| wgrant | Why dscsigningkey and not changesigningkey? :/ | 13:05 |
| wgrant | That's pretty bad. | 13:05 |
| wgrant | bigjools: As-is? What do you mean? | 13:05 |
| bigjools | if something's getting overwritten that's a separate bug | 13:05 |
| wgrant | bigjools: We have no control over that. gina sets it. | 13:05 |
| bigjools | I'm talking about syncs | 13:06 |
| wgrant | Syncs will stop existing. | 13:06 |
| bigjools | gina should not set uploader | 13:06 |
| wgrant | Hm? | 13:06 |
| wgrant | What do you mean by uploader? | 13:06 |
| bigjools | of course they won't, we're syncing here | 13:06 |
| wgrant | We normally use SPR.creator as uploader. | 13:07 |
| bigjools | instead of sync-source | 13:07 |
| wgrant | And that is Changed-By. | 13:07 |
| bigjools | that's crack | 13:07 |
| wgrant | bigjools: Why? | 13:07 |
| wgrant | And even so, we can't use anything on SPR to record the requestor. | 13:07 |
| bigjools | the uploader is whoever signed the changes file | 13:07 |
| bigjools | or in this case, did the sync | 13:07 |
| wgrant | bigjools: Right, that's (mostly) dscsigningkey. | 13:07 |
| cjwatson | um, ish | 13:07 |
| bigjools | not really | 13:07 |
| wgrant | At present it's all we have. | 13:08 |
| bigjools | right, and it needs cleaning | 13:08 |
| wgrant | Where do you propose to store the sync requester? | 13:08 |
| wgrant | It can't be on SPR> | 13:08 |
| bigjools | dunno | 13:08 |
| bigjools | not got that far yet :) | 13:08 |
| wgrant | I am initially inclined to store the uploader/requestor in some generic version of PackageUpload, which works for copies too and goes through the queue. | 13:09 |
| bigjools | mebbe | 13:09 |
| bigjools | why can't it be on spr? | 13:10 |
| bigjools | ah I see | 13:10 |
| wgrant | What happens if I sync it to two places? | 13:10 |
| bigjools | yeah | 13:10 |
| bigjools | so, maybe on spph | 13:10 |
| bigjools | not sure about creating PUs all the time | 13:11 |
| wgrant | We need to think and see if we can unify this and PackageUpload and all the checks in archiveuploader that duplicate packagecopier. | 13:11 |
| bigjools | yes | 13:11 |
| wgrant | Since it's currently stupid. | 13:11 |
| bigjools | yes | 13:11 |
| wgrant | Really duplicated and really stupid. | 13:11 |
| bigjools | yes | 13:11 |
| bigjools | one step at a time | 13:11 |
| allenap | StevenK: I was talking about other things this morning, sync buttons, PackageCopyJob, etc, so I haven't got to the diff yet, but I'm clear now. | 13:11 |
| wgrant | Right, but some of these steps are DD-critical, so it is probably a good idea to go some way to at least identifying that they exist :) | 13:12 |
| bigjools | wgrant: do you have a list/idea of which checks are duped in packagecopier and archiveuploader? | 13:15 |
| wgrant | bigjools: Not really... but everything in packagecopier is either buggily duplicated or buggily omitted from archiveuploader. | 13:16 |
| wgrant | It is *entirely* checks that archiveuploader needs too. | 13:17 |
| bigjools | sorta, but yeah | 13:17 |
| wgrant | I don't really know how we can unify them. | 13:18 |
| bigjools | archiveuploader deals with one at a time | 13:18 |
| wgrant | Unless we make the internal copy logic take a set of SPRs and BPRs and their overrides. | 13:18 |
| bigjools | I don't either, we'll just have to look at it and work it out | 13:18 |
| wgrant | And then the copier can extract those from the source archive, and archiveuploader can use the ones it's just created. | 13:18 |
| wgrant | The post-refactor underlying logic mostly does that, anyway. | 13:19 |
| wgrant | It just needs to be dragged up a bit further. | 13:19 |
| bigjools | it needs a coding sprint | 13:19 |
| wgrant | Yes | 13:19 |
| wgrant | the copying stuff is not going to get fixed without that, I don't think :/ | 13:19 |
| wgrant | It needs thought and experimentation and throwing at people. | 13:20 |
| * bigjools eats | 13:23 | |
| henninge | adeuring: thanks, that helped! I also had use a different layer. | 13:33 |
| adeuring | henninge: out of curiosity: Do you know what type this object was you got for the string "português"? | 13:34 |
| henninge | adeuring: "object" ... | 13:35 |
| henninge | generic | 13:35 |
| henninge | nothing | 13:35 |
| === al-maisan is now known as almaisan-away | ||
| adeuring | indeed | 13:35 |
| henninge | ... | 13:35 |
| henninge | adeuring: I also found it that it was using the widgets from zope.app.dav not zope.add.form. | 13:35 |
| henninge | s/add/app/ | 13:36 |
| adeuring | intereting | 13:36 |
| henninge | I don't know if the wrong layer influenced that but I could imagine that. | 13:36 |
| jcsackett | clear | 13:44 |
| jtv | gmb: free to review a simple peephole cleanup branch? https://code.launchpad.net/~jtv/launchpad/pre-747546/+merge/59771 | 13:45 |
| gmb | jtv: Sure. | 13:46 |
| jtv | thanks | 13:46 |
| jtv | allenap: my branch for the upgrade button is here as a WIP... https://code.launchpad.net/~jtv/launchpad/bug-747546/+merge/59765 | 13:49 |
| allenap | Cool, thanks jtv. | 13:49 |
| jtv | A lot of that diff is actually just cleanup, which is currently being reviewed as a separate branch to lighten the diff. | 13:49 |
| gmb | jtv: r=me | 13:49 |
| jtv | thanks! | 13:49 |
| jtv | allenap, correction: the cleanup branch _has been_ reviewed. :) | 13:50 |
| jtv | It's set as a prerequisite for the main branch. | 13:50 |
| jtv | (So actually I'm not even sure why its changes show up in the diff) | 13:51 |
| allenap | jtv: Mmm, suspicious :) | 13:52 |
| henninge | Hi deryck! ;) | 14:00 |
| deryck | Hi hi | 14:00 |
| deryck | henninge, stand up? | 14:01 |
| henninge | deryck: I need a minute alone with my laptop ... :( | 14:02 |
| deryck | henninge, tmi | 14:02 |
| deryck | henninge, join us when you finish :) | 14:02 |
| henninge | sure | 14:02 |
| jtv | allenap: the big remaining issue with my branch is that the few people who actually know soyuz stuff get into long, incomprehensible discussions when you ask "what label do you want on the button?" :-) | 14:10 |
| allenap | jtv: lol! | 14:11 |
| jtv | I'm serious! | 14:12 |
| deryck | gmb, ping | 14:17 |
| gmb | deryck: Hi | 14:17 |
| === almaisan-away is now known as al-maisan | ||
| sinzui | deryck: This page has directions to enable the backlight buttons on you computer: https://help.ubuntu.com/community/MacBook5-1/Natty | 14:35 |
| deryck | sinzui, oh happy day! | 14:35 |
| deryck | sinzui, it worked for you? | 14:35 |
| sinzui | yes | 14:35 |
| deryck | lovely. I shall disappear shortly as I relog. ;) :) | 14:37 |
| sinzui | I did the same :) | 14:37 |
| deryck | oh happy not-overly-bright-or-overly-dim day! | 14:40 |
| deryck | sinzui, many thanks for the pointer! | 14:40 |
| bigjools | heh | 14:40 |
| * deryck turns the brightness up and down repeatedly, just 'cause he can | 14:40 | |
| sinzui | deryck: I believe every feature of older macbooks are now working working without hacks | 14:41 |
| deryck | sinzui, yup, that was my last issue. | 14:42 |
| sinzui | Now I need to avoid buying a new computer for a few years | 14:42 |
| jcsackett | sinzui: in a few years you won't be able to install any software on a macbook anyway, so you'll have to buy a different computer *anyway*. | 14:43 |
| jcsackett | sooner or later usb ports will be deemed as too messy for the unibody. :-P | 14:43 |
| sinzui | jcsackett: I doubt that. I do not use the macos except as a way to buy music from time to time. I buy from U1 and amazon UK too because my indie tastes are poorly represented in all music shops | 14:44 |
| StevenK | jcsackett: But then how will fanbois hook up their iPhones and iPods! | 14:45 |
| StevenK | jcsackett: I mean, oh noes! | 14:45 |
| jcsackett | sinzui: ah, so your next computer may be a thinkpad or something? | 14:46 |
| * jcsackett is considering his next upgrade | 14:46 | |
| jcsackett | StevenK: ipods will be updated via a proprietary protocol that is basically tarted up bluetooth. they will call it iSync, and it will return "childlike wonder" to wireless devices. | 14:47 |
| * jcsackett stops his cynical futurism. | 14:47 | |
| StevenK | Where did I put that hangman's noose ... | 14:48 |
| jcsackett | ? | 14:48 |
| StevenK | jcsackett: iSync as a 'feature' makes me want to inflict harm | 14:48 |
| * jcsackett laughs. | 14:48 | |
| jcsackett | i joke, but apple did just by the iCloud domain. | 14:48 |
| jcsackett | s/by/buy/ | 14:49 |
| sinzui | StevenK: hmm, I think that tarted up protocol will be based on what the hacker community created to enable mounting the pnhone over the net. | 14:49 |
| StevenK | allenap: Thank you for the review. No fair not +1'ing my shell output. | 14:49 |
| allenap | StevenK: Okay, okay, +1 on shell dump. | 14:49 |
| StevenK | That sounds like Apple. What Free Software project can we take, bend to our will and never release as source? | 14:49 |
| StevenK | allenap: :-) | 14:49 |
| allenap | StevenK: The whole diff was actually repeated twice. It was a nice surprise to find that I was done once I was only half way through. | 14:51 |
| StevenK | allenap: Oh, drat. Sorry about that. In which case, there is *one* change between the two diffs, can you find it? :-D | 14:52 |
| allenap | StevenK: Yeah, there was a change to a docstring iirc. | 14:52 |
| StevenK | Right | 14:53 |
| StevenK | allenap: Nicely done. At least you didn't mention the fix in the review mail :-) | 14:54 |
| === Ursinha-afk is now known as Ursinha | ||
| adeuring | gmb: could you please review this mp: https://code.launchpad.net/~adeuring/launchpad/bug-768443/+merge/59782 ? | 15:10 |
| deryck | mrevell, ping | 15:14 |
| mrevell | Hey there deryck. How are things in Alabama? | 15:15 |
| henninge | gmb: Hi! Are you free for a review? | 15:15 |
| henninge | https://code.launchpad.net/~henninge/launchpad/devel-644872-unicode-error-in-search-text/+merge/59783 | 15:15 |
| deryck | mrevell, getting better here. still lots of damage to clean up, though. | 15:15 |
| gmb | adeuring: Sure. | 15:16 |
| adeuring | thanks! | 15:16 |
| gmb | henninge: I'll take yours afte adeuring's | 15:16 |
| henninge | gmb: thank you ;) | 15:16 |
| gmb | adeuring: r=me | 15:22 |
| adeuring | gmb: coool, thanks! | 15:22 |
| gmb | henninge: r=me | 15:27 |
| henninge | gmb: thank you ;) | 15:27 |
| rvba | gmb: Hi! Could you please review this MP: https://code.launchpad.net/~rvb/launchpad/sync-to-updates/+merge/59653 ? | 15:29 |
| gmb | rvba: Sure | 15:29 |
| rvba | thanks. | 15:29 |
| gmb | rvba: Approved. | 15:33 |
| rvba | gmb: thanks a lot. | 15:33 |
| gmb | np | 15:33 |
| === al-maisan is now known as almaisan-away | ||
| jcsackett | abentley: can i beg your assistance on some yui/test stuff? | 15:48 |
| abentley | jcsackett: Sure. | 15:48 |
| jcsackett | cool. so, i am trying to just get a stubbed out suite with two tests that fail. right now i have http://bazaar.launchpad.net/~jcsackett/launchpad/spam-button-ui/view/head:/lib/lp/answers/javascript/tests/test_question_spam.html | 15:49 |
| jcsackett | and it's js file is http://bazaar.launchpad.net/~jcsackett/launchpad/spam-button-ui/view/head:/lib/lp/answers/javascript/tests/test_question_spam.js | 15:49 |
| jcsackett | the js file being tested is stubbed out here: http://bazaar.launchpad.net/~jcsackett/launchpad/spam-button-ui/view/head:/lib/lp/answers/javascript/question_spam.js | 15:49 |
| jcsackett | i am pretty sure i have failed in setting something up, as when i open up the html i expect to be told of two failures (for the Assert.isTrue(false)) stuff, but i get nothing. | 15:50 |
| abentley | jcsackett: For me, that's usually failure to include a JS file, or perhaps a wrong path. | 15:50 |
| LPCIBot | Project db-devel build #512: FAILURE in 5 hr 39 min: https://lpci.wedontsleep.org/job/db-devel/512/ | 15:51 |
| jcsackett | abentley: i thought that, but i've double checked the paths and they all look correct. | 15:51 |
| jcsackett | abentley: in the html harness, i link in test_question_spam.js and ../question_spam.js; as the test_*js file is in the same dir as html and the other file is one above, that should be right, shouldn't it? | 15:52 |
| abentley | Yes, that does look right. | 15:52 |
| abentley | jcsackett: Your paths to yui etc don't look like mine at all. | 15:54 |
| abentley | jcsackett: e.g. I have ../../../../canonical/launchpad/icing/yui/yui/yui.js | 15:54 |
| jcsackett | abentley: ah, that could be. i didn't double check those b/c i copied them out of the wiki page. | 15:55 |
| abentley | jcsackett: I know the wiki was wrong, but I thought we'd fixed it. | 15:55 |
| abentley | jcsackett: Anyhow, try copying them out of lp/translations/javascript/tests/test_sourcepackage_sharing_details.html | 15:55 |
| jcsackett | abentley: okay, thanks. | 15:56 |
| timrc | Is 404 to an empty PPA really the correct response? When you create a PPA, it should exist at the URL, even if it's empty IMO. Maybe I'm about to split blasphemy but wouldn't a 204 No Content be an improvement? | 16:04 |
| bigjools | indexes are deliberately not published to save space/inodes | 16:04 |
| jcsackett | abentley: i have updated the paths, still nothing. :-/ | 16:05 |
| jcsackett | abentley: do you have any knowledge regarding hooking in namespace stuff? perhaps i've screwed up in getting the stub of a js module hooked in... | 16:05 |
| timrc | bigjools, but changing the HTTP code to a 204 would distinguish is from a "you mistyped the URL" error | 16:05 |
| abentley | jcsackett: sorry, OTP | 16:05 |
| bigjools | timrc: how do we know it wasn't a mistype? | 16:05 |
| bigjools | it's just a plain Apache server | 16:06 |
| === matsubara is now known as matsubara-lunch | ||
| timrc | bigjools, launchpad should be smart enough to know that the ppa was created, but is empty and then return a code better reflecting that.. based on launchpad's implementation 404 is probably technically correct, but it's not intuitively correct IMO | 16:10 |
| bigjools | timrc: fair enough. I think it's quite a lot of work to do for a small gain though. | 16:10 |
| timrc | perhaps :) | 16:11 |
| bigjools | patches welcome :D | 16:12 |
| abentley | jcsackett: I did have to hook up a namespace for the work I did, but I just followed an example I found. | 16:20 |
| abentley | jcsackett: Are you using firebug or similar? That sort of problem will usually generate error messages. | 16:21 |
| jcsackett | abentley: no, firebug isn't catching anything either, which is weird. | 16:21 |
| jcsackett | abentley: does our test stuff work with firefox4? | 16:21 |
| abentley | jcsackett: there were some firefox4 compatibility issues. deryck, could you remind us what those were? | 16:22 |
| * deryck looks at scrollback | 16:23 | |
| abentley | deryck: with javascript testing in general? | 16:23 |
| deryck | abentley, jcsackett -- ah. so yui test has no ff 4 issues. windmill has issues with the magic comment bugs that only become enabled when you type text into them. | 16:24 |
| deryck | abentley, jcsackett -- and then getting a profile windmill can use with ff 4 is a bit tricky | 16:25 |
| deryck | but running yui test in the browser should work fine | 16:25 |
| abentley | deryck: thanks. | 16:25 |
| jcsackett | ok, so that eliminates that as a source of the problem. thanks, deryck. | 16:25 |
| deryck | np! | 16:25 |
| jcsackett | ok. i have managed to get an error. yuitest is not loaded. except that i can see the .use('test') bit. hm. | 16:33 |
| jcsackett | success! also, i cannot read. | 16:44 |
| abentley | jcsackett: yay! | 16:47 |
| jcsackett | abentley: so, i was doing use('yuitest'), not use('test). | 16:48 |
| abentley | jcsackett: doh! | 16:48 |
| jcsackett | when i went to doublecheck, i was actually looking at your file opened as an example, not mine, and saw 'test'. :-P | 16:49 |
| jcsackett | thus, i cannot read. :-) | 16:49 |
| jcsackett | thanks for the help, abentley. :-) | 16:49 |
| abentley | jcsackett: you're welcome. | 16:49 |
| benji | jml: do you have a minute to chime in on bug 772763? in particular the importance of "low" | 16:50 |
| _mup_ | Bug #772763: Unmuting a bug's notifications should restore your previous direct subscription <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/772763 > | 16:50 |
| jml | benji: not until tomorrow afternoon. sorry. | 16:50 |
| benji | jml: no worries; I'll ping you again then | 16:51 |
| jml | benji: I'm already late for an appointment, and am flying out to Budapest tomorrow morning. will make sure that bug doesn't slip through the cracks. | 16:51 |
| jml | benji: ta | 16:51 |
| * jml gone | 16:51 | |
| === Ursinha is now known as Ursinha-afk | ||
| === matsubara-lunch is now known as matsubara | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === gmb changed the topic of #launchpad-dev to: PQM in RC mode | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| JonOomph | Greetings! I am having a LaunchPad PPA issue and I'm not sure who to direct it to. I have many builds that are marked as 'Needs building', and they have been stuck in the queue for about 12 hours now. Any thoughts? | 17:46 |
| bigjools | JonOomph: there is currently a very large backlog of builds, the queue is very long | 17:47 |
| bigjools | see https://launchpad.net/builders | 17:47 |
| bigjools | we're currently missing a number of builders as they are temporarily used during the Ubuntu release | 17:48 |
| JonOomph | Ahhh, that makes perfect sense | 17:49 |
| bdmurray | bac: what's the right way to give you feedback regarding better bug notifications? | 17:50 |
| JonOomph | Having a few days of delay in the PPA build system makes releasing a new version of OpenShot a bit tricky, but I'm patient and can wait. =) | 17:51 |
| === Ursinha-lunch is now known as Ursinha | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| sinzui | jcsackett: do you have time to mumble? | 19:50 |
| jcsackett | sinzui: sure, just one moment. | 19:50 |
| benji | sinzui: will you have some time this afternoon to do a small UI review for me? (https://code.edge.launchpad.net/~benji/launchpad/click-to-close-boxes/+merge/59818) | 20:10 |
| sinzui | benji: I can starting it now | 20:10 |
| benji | sinzui: I am thanking you now. | 20:11 |
| jelmer | rockstar: hi | 20:41 |
| lifeless | moin | 20:41 |
| jelmer | g'day lifeless | 20:42 |
| rockstar | jelmer, hello sir | 20:43 |
| jelmer | rockstar: What's the policy on landing changes in lp:tarmac? | 20:44 |
| jelmer | rockstar: related, is it intentional that lp:tarmac is owned by an open team? | 20:48 |
| jelmer | argh, it isn't.. nevermind | 20:49 |
| abentley | deryck: there's no OCR. Could you please review https://code.launchpad.net/~abentley/launchpad/allow-noop-claims/+merge/59795 ? | 21:31 |
| deryck | abentley: sure. | 21:31 |
| abentley | deryck: thanks. | 21:31 |
| benji | sinzui: Thanks for the review. Do you want the "Hide \2715" bit in parenthesis to distringuish it from the text of the message? | 21:32 |
| sinzui | No, that would introduce difference. We want to be the same | 21:32 |
| benji | (I'm also investigating using the sprite.) | 21:32 |
| benji | k | 21:32 |
| deryck | abentley: r=me | 21:34 |
| abentley | deryck: thanks. | 21:34 |
| lifeless | benji: hi | 21:42 |
| lifeless | merge proposals don't do attachments | 21:42 |
| benji | lifeless: I know that now. :) | 21:42 |
| lifeless | benji: where else could one see these screenshots? | 21:42 |
| lifeless | ah, I see, nvm | 21:42 |
| benji | I edited the MP to point to... | 21:43 |
| benji | right | 21:43 |
| lifeless | so, UI question (perhaps curtis has asked this) | 21:43 |
| lifeless | we have a X icon in the top right of other things that are closable | 21:43 |
| abentley | lifeless: they do too! | 21:44 |
| lifeless | abentley: oh ? | 21:44 |
| abentley | lifeless: attach a patch and we'll even colourize it! | 21:44 |
| lifeless | abentley: supporting attachments is a superset of supporting attachments-that-are-patches | 21:45 |
| benji | lifeless: right; in the review he suggested emulating the "Hide X" target on the new private bug ribbon | 21:45 |
| lifeless | benji: ok cool; I can butt out | 21:45 |
| lifeless | benji: separately, I declined the team-join for lp to alpha testers | 21:45 |
| abentley | lifeless: you didn't say "launchpad doesn't support attachments of particular kinds" | 21:46 |
| lifeless | I think a feature flag is better and easier to clean up | 21:46 |
| benji | abentley: my problem with that MP was that I submitted it after forgetting the attachments and it took less time to find the edit link then to figure out how to add attachments after the fact | 21:46 |
| lifeless | abentley: you're splitting hairs I think; theres a very large set of more refined meanings I could have meant | 21:46 |
| lifeless | abentley: mps don't support attachments *like bugs support attachments* | 21:47 |
| benji | lifeless: i.e., just change the flag to predicate on team:launchpad instead of team:malone-alpha? if so, that sounds good to me. | 21:47 |
| lifeless | benji: yeah, or add a row | 21:47 |
| lifeless | benji: depending on whether you anticipate having non-lp folk participate in the alpha stage | 21:47 |
| benji | sounds good; I'll get that done tomorrow | 21:47 |
| lifeless | I would expect something like adding launchpad-beta-users as a rule when it comes out of alpha | 21:47 |
| abentley | lifeless: It looked to me like you were saying "merge proposals don't allow attachments" as an absolute. | 21:48 |
| benji | lifeless: I wasn't aware of launchpad-beta-users, sounds like the ticket | 21:48 |
| lifeless | hmm, spelling error, one sec | 21:49 |
| lifeless | benji: https://help.launchpad.net/GetInvolved/BetaTesting | 21:50 |
| lifeless | launchpad-beta-testers | 21:50 |
| lifeless | is the team | 21:50 |
| lifeless | 2K early adopters | 21:50 |
| benji | cool | 21:51 |
| === flacoste changed the topic of #launchpad-dev to: Merge to devel are open again | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| benji | sinzui: hmm, the privacy ribbon's hide affordance is underlined on hover and changes the mouse cursor. I'll match that behavior. | 21:56 |
| lifeless | benji: oh, btw - you have 'edge' in your browser bookmarks :> | 22:11 |
| benji | heh, so I do; fixed now | 22:19 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | hmm | 22:27 |
| lifeless | we have lots of css warnings in the ff4 console | 22:27 |
| === salgado is now known as salgado-afk | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| sinzui | lifeless: pocket-list also complains about CSS. There is no to that is aware of supported and proprietary rules to provide a competent report of broken css. | 23:02 |
| sinzui | s/pocket-list/pocket-lint | 23:02 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | sinzui: hi | 23:25 |
| sinzui | hi lifeless | 23:25 |
| lifeless | sinzui: I'm thinking of closing https://bugs.launchpad.net/launchpad/+bug/741092 | 23:25 |
| _mup_ | Bug #741092: Archive:+subscriptions times out with many subscribers <qa-ok> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741092 > | 23:25 |
| lifeless | because it seems ok now | 23:25 |
| lifeless | IMBW, what do you think? | 23:25 |
| sinzui | I honestly do not know. When was the last time we saw an issue | 23:27 |
| lifeless | I looked back a few days, couldn't see one | 23:27 |
| lifeless | it may be very sporadic though | 23:28 |
| sinzui | I favour closing it, though I also like being able to say this issue has not been see in 30 days | 23:29 |
| lifeless | better matching in oops-tools would be nice | 23:31 |
| === Ursinha-afk is now known as Ursinha | ||
| lifeless | Any follow on issue will not need the sql optimisation | 23:31 |
| sinzui | lifeless: actually, I still wonder if qastaging was a bad env to test one. | 23:31 |
| lifeless | so I think I'll close it | 23:31 |
| sinzui | +1 I believe there are some performance issues that can only be experienced in production | 23:32 |
| lifeless | losa ping | 23:48 |
| lifeless | can you please change a feature flag on qastaging: | 23:48 |
| lifeless | malone.bugmessage_owner default 0 on | 23:48 |
| sinzui | wgrant: I cannot attend the meeting in 15 minutes. I can we talk later? I want to understand the effort needed to address bug bug/747558 | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!