[00:00] ok [00:00] sort_order is only for iteration [00:00] and comparison [00:00] inside the enum code itself [00:00] used primarily for ordering the enum values inside drop down lists et al [00:00] nothing to do with the db queries [00:01] or the db_value [00:01] right [00:01] so I think the thing to do then is to change from mid 30's for the INCOMPLETE_WITH_RESPONSE and INCOMPLETE_WITHOUT_RESPONSE [00:02] and insert them adjacent to the existing INCOMPLETE value [00:02] ah... sure [00:15] thumper: is the default sort order numeric ? [00:16] * thumper tries to recall [00:16] * thumper looks at the code [00:17] lifeless: the enum item has a sortkey value that is numeric [00:17] the sort_order is used to recreate the sortkey values [00:17] so if its absent its numeric [00:17] cool [00:23] hmm [00:27] hi [00:29] lifeless: i have a test which calls DocTestMatches. It fails if "matchee" is unicode but passes if I encode to utf-8 as in: self.assertThat(markups[1].encode('utf-8'), DocTestMatches(expected_item_1, self.doctest_opts)) [00:29] lifeless: the error is [00:29] File "/var/launchpad/tmp/eggs/testtools-0.9.10-py2.6.egg/testtools/matchers.py", line 169, in _with_nl [00:29] result = str(actual) [00:29] UnicodeEncodeError: 'ascii' codec can't encode character u'\u2026' in position 2121: ordinal not in range(128) [00:30] lifeless: should DocTestMatches be fixed? is it broken? ie should str(actual) be replaced with actual.encode('utf-8')? [00:31] lifeless: this is an existing test that broke when a change to made to what was rendered on a page. it was not previously being passed a unicode string [00:31] wallyworld: I don't remember if its a doctest limitation or a shallow bug in testtools [00:32] it seems reasonable to me that we'd support self.assertThat(u'fo', DocTestMatches(u'bar')) [00:32] lifeless: ok. for now i can amend the test with the .encode() and file a testtools bug or look up and existing one and include a XXX in the test? [00:34] certainly file a test tools bug [00:34] will do [00:35] encoding to utf8 is a tolerable workaround, though it will break if someone runs the lp test suite on a cp* or shift-jis system [but it wouldn't be the only thing to break that] [00:35] unless there's another workaround i can use? [00:35] you could fix the bug :) [00:37] lifeless: sure. but i want to get my branch landed without the blockage caused by having to land a testtools update [00:37] or i guess i could do them together [00:38] In terms of fixing it, I think something like: [00:38] if type(foo) is unicode: [00:38] ... [00:38] else: [00:38] foo = str(foo) [00:38] ... [00:38] [that is, special case handling of foo] [00:38] it won't be entirely correct unless you also handle both sides being conditionally unicode [00:39] yes [00:39] i wish my unicode foo was better [00:40] Its not you, its python. [00:40] Python, and all of the people who refuse to use UTF-8. [00:40] wallyworld: I think we need to disable the YUI tests :( [00:40] wgrant: i saw another failure :-( [00:41] Yeah. [00:41] well it was worth a try [00:41] Definitely. [00:41] it was a useful test. [00:42] we need to look at perhaps another harness to run them besides windmill [00:45] wallyworld: YUITestLayer? [00:45] wgrant: i think so [00:50] WTF [00:50] Unity just went insane. [00:50] ‽just ? [00:50] It all worked fine, except that any window that you clicked on disappeared. [00:50] Then reappeared when I clicked again. [00:51] KDE is rock solid :-P [00:52] but you loose 30K pixels. Thats got to hurt. [00:52] wallyworld: That's irrelevant. So is Gnome, XFCE etc. [00:53] huwshimi: i was just stirring [01:08] https://code.launchpad.net/~wgrant/launchpad/disable-yuitestlayer/+merge/58058 [01:09] Bug #763604 sounds like a browser bug... [01:09] <_mup_> Bug #763604: Cannot remove attachment when reporting new bug < https://launchpad.net/bugs/763604 > [01:09] Isn' [01:10] t most of the point of that widget to not be manipulatable except by the user? [01:12] lifeless: https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/764086 is a slightly interesting example of your task unification thing [01:12] <_mup_> Bug #764086: dchroot.conf parser uses deprecated key "location" < https://launchpad.net/bugs/764086 > [01:13] like many bugs it's already fixed in natty but we really want to say, to start with, 'please fix it in lucid-updates' [01:13] and there are two ambiguous ways to do it: nominate for lucid, or target the main task to lucid-updates [01:23] indeed [01:23] so this is something I think a clueful user would reasonably file directly on lucid [01:28] i agree it is something they would want to file directly on lucid [01:29] can you do that in lp today? [01:30] No. [01:35] a script could nominate for release and target milestone to lucid-updates, but you can't do it on the web [01:35] i guess [01:41] interestingly [01:41] apport tags bugs as [01:41] natty [01:41] etc [01:41] the nomination stuff is intended to stop incorrect bugtasks [01:42] more precisely [01:42] on a frozen series [01:42] developers opt in to having tasks [01:42] and non-priviliged folk can suggest where a task should be using nominations [01:42] there is an unresolved tension between 'bug exists' and 'task to work on the bug' [01:43] what's the semantic difference between nominating for lucid, and targeting to lucid-updates? [01:43] theres a few [01:44] firstly you can't target to lucid-updates, that isn't a series. [01:44] you can target to lucid, if you have access [01:44] nominating to lucid would write a proposal that it should be targeted against lucid [01:44] there is a milestone called 'lucid-updates' and you can target it [01:44] ah [01:44] so 'target' and milestone are different again [01:45] the milestone ui says 'target to milestone' :) [01:45] right [01:45] 'bug tasks' have a 'target' field [01:45] which is the IBugTarget that the bug is for [01:45] bah [01:45] bugtask is for [01:45] so, in your proposed change [01:45] which can be a product/productseries/distro/distrosourcepackagename/distroseries/distroseriessourcepackagename [01:46] the default bugtask target would be the current development series, natty [01:46] what i find really annoying, is that it is impossible to remove a bugtask from a bug [01:46] and then it would be obviously silly to have a natty series milestone called lucid-updates [01:46] dobey: yes, we're going to do something about that. [01:46] you can only change the project/package [01:46] cool [01:47] dobey: one proposed thing is to hide 'Invalid' status tasks, unless *all* the tasks are invalid. [01:47] dobey: what do you think of that? [01:47] ! [01:47] seems like that would make it hard to undo some changes [01:47] poolie_: it might; its a discussion point at the moment [01:47] lifeless: it's not so much the web ui that bugs me, so much that i continue to get unneccesary e-mail [01:48] dobey: there is a separate bug I filed about that :) [01:49] poolie_: so the common case is one task per bug [01:49] i would really like to be able to remove a bugtask; but shouldn't be able to if there's only one task on a bug [01:49] poolie_: in that case, the task would just show as invalid [01:49] poolie_: not show up by default in searches (thats the current behaviour anyway) [01:49] poolie_: in there are two tasks, and one is invalid and one is (say) wontfix. [01:50] yeah, i can imagine [01:50] the case i was thinking of is, suppose it's affecting 'bzr (Ubuntu)' and 'bzr' [01:50] and a cosmic-ray commenter changes 'bzr' to invalid [01:50] i suppose you would just click 'also affects project' again [01:50] you would fix this by saying 'also affects' [01:50] yup [01:50] would that resurrect the existing task? [01:51] something equivalent to [01:51] i would like the dates to remain accurate [01:51] such as they are [01:51] rather than actually deleting it [01:51] open question is whether the dates etc /should/ be preserved or not [01:51] mm [01:51] note that this question applies whether we reuse invalid to hide, or have a new 'deleted' status. [01:51] anyhow, i can see how it would be a tidy implementation [01:51] right [01:51] but only allow driver/owner/maintainer/whatever to remove tasks, and not arbitrary users [01:52] right, the job of arbitrary users is to _add_ more task lines :) [01:52] the only time that this question doesn't apply is if we actually delete things - which presupposes that we've concluded the dates not mattering, and that the error rate on deletes would be low enough to not need an undo facility. [01:52] a la http://pad.lv/410407 [01:53] hm [01:53] i think of .status as being something like a member variable of the task [01:54] it's pretty much presented that way in the ui and api [01:54] whereas deleting a task, such that you'll need to create a new one later, is more like a method [01:55] thats a display issue [01:55] we could: [01:55] (agurably a display issue) [01:55] we could: [01:55] - show a button to delete [01:55] - hide invalid except when there is only one task [01:58] i think it would be weird if, over the api [01:58] bt.status=invalid;bt.lp_save(); bt.status=confirmed [01:58] did not work [01:59] I agree [01:59] I see no reason it wouldn't [01:59] what is weird is that bt.lp_delete(); bt.status=confirmed;bt.lp_save() would work. [01:59] if we chose to expose it as a semantic delete. [01:59] why not just delete it? [02:00] destructive delete is harder to undo [02:00] and users make lots of mistakes [02:02] both true [02:03] that combined with a 300GB database is a pretty powerful trifecta [02:04] wgrant: https://launchpad.net/ubuntu/+bugtarget-portlet-tags-content (Distribution:+bugtarget-portlet-tags-content) [02:04] OOPS-1933A810, OOPS-1933J816 [02:04] bah [02:04] if delete was restricted to privileged users though, would they really make that many mistakes? [02:04] fail font in chromium, I read that as JB for a second [02:04] dobey: Hahahah [02:04] dobey: privilege correlates to experience not accuracy ;) [02:05] could preserve the history before the delete. [02:05] thats what this proposal does. [02:05] lifeless: heck, i'd be happy if it was only available via API even. :) [02:05] well, marking the object 'deleted' or whatever is a classic way to all it to be undone [02:05] i guess you could start by even just hiding invalid tasks from the bug page, or not sending mail about them [02:06] in fact the second case is interesting [02:06] bug is marked invalid, then a person replies to say 'no it really is valid' [02:06] hm, or they change the existing task to point at the project with the invalid task [02:06] Past proposals have suggested that invalid tasks get bugmail when no tasks are valid. [02:07] and otherwise it's the job of whoever is getting the bugmail to make decisions about it? [02:09] problem is, i don't want the bugmail :) [02:10] poolie_: Right. [02:10] poolie_: Just like if the task was retargetted. [02:10] Retargeted meaning having its target changed, not being targeted to a series, or targeted to a milestone. [02:11] lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1933A108 [02:11] lifeless: lazr.restful's exception handling is buggy in other ways too :( [02:11] dobey: yes, me too [02:12] dobey: long list of things to fix [02:12] wgrant: thank you so -very very very- much for getting even this much [02:12] lifeless: Erm, the fix isn't landed yet, but yeah. [02:13] wgrant: though that looks pretty ok [02:13] lifeless: This isn't a timeout, so the data is fine. [02:13] oh of course [02:13] mea culpa [02:13] lifeless: But the traceback is obliterated by lazr.restful explicitly reraising the exception object. [02:13] yes [02:13] (in 2.7 this would work fine) [02:13] Er, 3.x. [02:13] Not backported to 2.7, is it... [02:13] works fine in 2.x if include the backtrace [02:14] 3 arg raise [02:14] its just poor python [02:15] Yeah. [02:17] GRAH [02:17] whoever thought a bug couldn't have 1000 actions [02:17] * lifeless puts on the positive face [02:17] Actions as in BugActivity? [02:17] ROM BugActivity [02:17] WHERE BugActivity.bug = 659052 [02:17] ORDER BY BugActivity.id LIMIT 1001 [02:17] thats whats triggering the shortlimit [02:18] what. [02:18] At least there was shortlist() there to warn. [02:18] I think it is [02:18] lets check [02:20] yup [02:45] hi wgrant [02:45] Hi jtv. [02:46] Had a chance to look at the updated publish-ftpmaster script? [02:46] Not enough. [02:46] Which, on a sidenote, I found may actually have been slower than it needed to be all this time. [02:46] Oh? [02:46] I tried not to work during the holidays, honest. [02:47] You see, it tries to update these two directories from each other using hardlinks. [02:47] Far as I can tell, it does that by passing rsync the -H option. [02:47] Which says "try to figure out whether there are any hardlinks within the source, and recreate those in the destination." [02:47] Whereas what I think is really wanted is --link-dest. [02:48] Hmmm, -H makes sense, but I'm not sure --link-dest is what we want. [02:48] -H is there to not undo fdupes. [02:48] It's possible that --link-dest would be faster than what we have now, bit it really depends. [02:49] Oh, so there are "meaningful" hardlinks in the publishing directory? [02:49] s/bit/but/ [02:49] (Besides faster, it'd also be much more space-efficient of course) [02:49] Saving about a megabyte, I believe, yes. [02:49] Right. [02:49] There's only a megabyte in the dists directories? [02:50] No, I mean the current hardlinking done by dsync link-dupes saves about a megabyte. [02:51] Oh [02:51] But are the hardlinks significant? Or are they still just a space-saving measure? [02:51] Not significant AFAIK. [02:51] Total space saved by merging 28.1kb. 577 files affected. [02:51] Oooh yeah. [02:52] I guess it saves inodes and a trivial amount of space. [02:57] wgrant: it sounds pretty insignificant compared to what we could save on not duplicating the dists directory itself. [02:58] jtv: Indeed. [02:58] Although the rsync only takes 23 seconds. [02:59] In that case, why do we go to all the trouble of re-using that directory? [02:59] Copying the whole thing would take much longer. [02:59] Hard-linking maybe not so much. [03:00] Exactly. [03:00] It'd even save the time of reading files. [03:01] Yeah. But we have to hope that nobody uses O_APPEND :) [03:01] I guess [03:01] Except [03:01] no [03:02] All the risks are from re-using the directory. [03:02] Hmm [03:02] No... [03:03] It depends on when, I guess. [03:03] Changing a hardlinked file and then rolling back the publication would cause trouble. [03:03] If they're hard-linked and someone writes a file without first unlinking it, your archive is borked. [03:03] So the risk is that publish-distro or one of the publish-distro plugin scripts might modify a file. [03:03] s/might/probably do/ [03:04] In lots of places. [03:04] Oh [03:04] Well never mind that then. [03:04] Just about nothing explicitly unlinks first... [03:04] pop quiz [03:05] nvm [03:05] we already expose it ;0 [03:05] jtv: Release file generation, for example. [03:05] f = open(os.path.join( [03:05] self._config.distsroot, suite, "Release"), "w") [03:05] Bye. [03:05] Well never mind that then. [03:06] actually [03:06] here is a question [03:06] should we still expose an unqualified 'incomplete' [03:06] Yes. [03:07] where ? [03:07] Needed for backwards compatibility. [03:07] And stuff does use it. [03:07] (good luck with that) [03:08] wgrant: outside of migration support [03:08] where do you you think we should expose it? [03:08] I personally think that s/New/Unconfirmed/ and merge "Incomplete with response [03:08] " into that. [03:08] There's very little useful distinction. [03:09] wgrant: while I'm pro that thats a larger discussion to do [03:09] what I'm doing is materialising an inferred status [03:09] We're going to need to break API clients at least once. [03:09] so that we can aggregate it sensible. [03:09] Let's do it only once. [03:10] separate problem [03:10] I'm hoping not to break anything at all [03:10] Ah. [03:10] OK. [03:10] I'm talking about UI [03:10] like [03:11] show 'incomplete' but set to incomplete-without-response [03:11] thats a place I think showing incomplete is useful [03:11] but [03:11] a bug that is incomplete [03:11] cannot be asked for more input without toggling to new and back to incomplete. [03:11] this is nuts [03:12] so if we show the bug status as incomplete-with-reponse and show incomplete in the list [03:12] I guess. I am fairly strongly against making any UI changes without fixing it properly, though. [03:12] folk can trivially set it back to incomplete-without-response [by choosing incomplete] [03:12] Since this is just going to be awkward. [03:12] one option is to not change the ui at all [03:13] That would be my preference. [03:13] Your proposal is less awkward than the status quo, but the change is probably more awkward. [03:14] is getInitialValuesFromSearchParams dead code ? [03:14] please-say-yes-please-say-yes-please-say-yes [03:15] It seems to be... but that's very odd. [03:15] \o/ [03:18] I'd kind of like to expose the actual status [03:18] why do you say a change would be awkwards [03:20] I wonder how many folk set 'incomplete' and *then* make a comment using ajax saying 'please tell us more' [03:20] thus defeating the incomplete-without-response entirely. [03:28] lifeless: Change to a bad solution is awkward, even if the solution is better than what we have now. [03:28] Particularly since we're planning to change this again in the next 12 months. [03:36] why is it awkward though? [03:36] We have a status field that doesn't show the status. [03:38] thats what we have now [03:38] It has the same idea of 'status' as most of the rest of the UI. [03:40] the bug search form shows two incomplete statuses [03:40] the drop down widget to change a bug status shows one [03:41] The with/without reponse statuses only show up on the search form. [03:41] and the bug portlet exposes that there are two in yet another way by doing incomplete(can expire) but searching for a variant again [03:41] On the advanced search form, even. [03:41] bug expiry discusses this in the various bits of help [03:42] so I don't know that I accept your assertion about most of the ui pretending their is one such status [03:42] s/their/there/ [03:44] Mmm. [03:44] Well, it's a terrible mess at the moment. [03:45] agreed. [03:46] I want to understand what is awkward about reducing the amount of inconsistent UI here - by accepting that we have two incompletes and starting to propogate them. [03:46] we can do a totally hidden thing, I'm sure. [03:46] Aaaa [03:46] aaaaaaaaaaaaaaaaa [03:47] ECAT ? [03:47] process-accepted is crap. [03:47] It goes through all pending uploads. [03:47] processing them. [03:47] logging errors if they fail. [03:47] That sort of thing. [03:47] But it doesn't do any transaction stuff. [03:47] \o/ [03:47] So a failed upload gets the partial state left uncommitted, so it gets committed at the end. [03:48] (and library files created in early uploads aren't accessible to later ones) [03:50] This is the sort of thing that you *really really* want to be transactional :/ [04:01] headdesk [04:01] Bug.permits_expiration === poolie__ is now known as poolie [04:35] Hmmmmmm. [04:35] Our Referer parsing sucks. [04:36] OOPS-1934A83 [04:41] Grar. [04:41] Web browsers suck. [04:41] Backslashes are not legal URI characters, please don't send them. [04:45] * wgrant stabs Chromium in the eye. [04:45] And Firefox. [04:45] Stop autocorrecting my backslashes to slashes. [04:46] wgrant: which browser ? [04:47] lifeless: Chromium and Firefox appear to both happily send backslashes in URLs. [04:48] Despite RFC2396 excluding them. [04:48] Why don't people follow specs :( [04:48] And why does Chromium insist on treating URLs as non-opaque entities to be autocorrected unoverridably? [04:52] Huh. [04:53] Firefox encodes it correctly if it's in the path, but not if it's in the query string. [04:54] Yeah, that's pretty clearly illegal. [04:54] Gah. [04:57] Can we please delete the Web and start over? [05:00] oh yay [05:01] unwise turns up exactly twice in 2396 [05:01] lifeless: It's only documenting the rationale for the exclusions. [05:01] yeah [05:02] but its really strange to use a BNF rule to do that [05:02] It is. [05:02] and then not reference that elsewhere [05:03] Oh hmm. [05:03] query = *uric [05:03] uric = reserved | unreserved | escaped [05:03] reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | [05:03] "$" | "," [05:03] unreserved = alphanum | mark [05:03] mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | [05:03] "(" | ")" [05:03] Yes. [05:04] so yues [05:04] clearly FUBAR [05:04] In this case the URL actually comes from apport, not generated from a form. [05:04] However, it still sends bad stuff if you type it in the address bar :/ [05:05] user input cannot be trusted. [05:05] Thats like rule 1 of programming, right ? [05:05] which reminds me [05:05] need to talk to pitti about apport + privacy. [05:05] but now, grocery shopping [05:07]