[12:07] night all [12:19] sabdfl: hi, back for a bit, if you're still around. [12:20] got it working [12:20] created a ProductFileBugView [12:20] sweet...what'd you do? [12:20] which as a createAndAdd method [12:21] which pulls out the form data and creates the bug, then creates the BugAssignment [12:21] can't commit it yet because it needs the datecreated field approved by stub [12:21] have emailed him, so it will likely be committed tomorrow [12:21] i think i could generalise this and have the same view class used for package as well as product bugs [12:22] we've already got a view that does that. [12:22] also, it's important that the person who added it is subscribed, which the existing factory already does. [12:22] (BugFactory) [12:23] it's a content factory actually [12:23] and it works for both packages and products, whichever is provided. [12:25] createAndAdd is just a method in the base AddView that ends up calling the factory [12:31] ok, gotta really be away now, catch ya later === BradB|afk is now known as BradB|away === ddaa [~ddaa@deep-thought.xlii.org] has left #launchpad [] === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [02:25] Merge to rocketfuel@canonical.com/launchpad--devel--0: datecreated on ProductBugAssignment and SourcePackageBugAssignment for Mark (patch-766) [02:53] Merge to rocketfuel@canonical.com/launchpad--devel--0: Bounty comments (patch-767) [04:52] elmo: is there an easy way with GPG to print a summary of a key I have in a file? [04:52] elmo: (without importing it) [04:55] gpg --keyring foo.gpg --list-keys [04:56] > gpg --no-default-keyring --keyring key.gpg --list-keys [04:56] gpg: keyring `/home/daf/.gnupg/key.gpg' created [04:56] bob2: tried that already :) [04:56] hrm, I did something like that to see the buildbot keys [04:59] hmm: [04:59] > gpg --no-default-keyring --keyring ./key.gpg --list-keys [04:59] gpg: [don't know] : invalid packet (ctb=2d) [04:59] gpg: keydb_search_first failed: invalid packet [05:01] maybe 'cause the file is ascii-armoured or something === mdz_ [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad === mdz_ is now known as mdz [09:09] New Malone bug #40: "Batching module needs refactoring", submitted by Stuart Bishop [09:09] https://launchpad.ubuntu.com/malone/bugs/40 [09:14] lifeless: ping? [09:16] stub: do you think we can set test_on_merge to run the page tests first, and if they work, then to go on and run the functional tests? [09:16] i'm trying to get my 30 second test runs back :-) [09:17] Buy a faster laptop? ;) [09:17] There is no reason we can't do it like that. [09:18] I personally just run test.py directly ('python test.py test_pages' should do what you want) [09:20] can we make it a separate makefile target? [09:20] make pagetests? [09:21] Sure [09:25] My 'we' do you mean 'me', or you just looking for feedback? [09:28] good point, i'll do it, what i know about Makefiles approximates zero though :-) [09:30] Just remember that Makefiles require real tabs. I'm happy to put it in if you want - it is two lines [09:32] got it, thanks! [09:32] really wasn't that hard :-) [09:33] but the real tab thing would have stumped me if vim hadn't Just Worked. [09:33] So simple even management can do it ;) [09:34] har [09:34] "baz - the revision control system so simple even your boss could use it" [09:44] Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix archivelocation instantiation bug. (patch-768) [10:18] Merge to rocketfuel@canonical.com/launchpad--devel--0: bounty cleanup, add bugs directly to products, show bugs for a product (patch-769) [10:24] Merge to rocketfuel@canonical.com/buildbot--devel--0: Fix taxi up. (patch-66) [10:38] Anyone got any tips for updating previously working page tests to cope with changes? That diff output is monstrous. [10:51] stub: that's why i've been banging the "elide everything except one tiny feature per page" drum [10:52] It is the elisions that are causing me grief in this case - the diff output doesn't know how to handle them so the entire output is different. Makes finding the bits that need changing a problem :-( [10:52] Need a more intelligent diff [10:56] Ohh... I think I can fix it. [11:20] stub: yeah, we need to make pagetest diffs understand and ... [11:20] Can '...' appear anywhere, or just on a blank line? [11:21] it should be able to appear anywhere [11:21] for example, to demonstrate that a particular header exists, but you don't care about the value [11:25] is there any good way to know the len() of a resultset? [11:25] or even just whether or not it actually contains a result? [11:27] spiv: around? [11:33] does len() on it work? If not, I think it has a count() method or something like that === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad === doko [doko@dsl-082-082-210-039.arcor-ip.net] has joined #launchpad [11:35] Kinnison: morning [11:35] hi doko [11:40] sabdfl: Good morning === Kinnison recommends not falling asleep on your mobile phone [11:40] it makes hearing the alarm a might difficult :-( [11:41] wondered what had happened to you :-) === Kinnison can only apologise and get-on :-) [11:41] at least you should have enough rest to smack the domination bits into order :-) [11:41] Well; it's certainly time to write more unit-tests === Kinnison skims ubuntu-users while his machines come up to speed; sync rocketfuel etc [11:45] bummer. can't access count from the page template [11:45] SteveA: any other suggestions? [11:45] hi sabdfl [11:45] hiya doko [11:45] doko: see my mails? [11:46] yes, thanks, will answer tonight. one mail yes, any more mails? [11:47] hmm... thought there was one yesterday, one today [11:48] SteveA: can i tal:define something as false, then, iterate of the resultset, and during the iteration, redefine that as true? [11:48] how do i tal:define something as false? [11:50] or true for that matter? [11:52] you can tal define things to any python value using tal:define="foo python:False" [11:52] but, that sounds like a case of programming in a page template [11:52] maybe this logic can be moved to the view's class? [11:53] tal:define="foo nothing" [11:54] tal:define="foo string:whatever" for true, or tal:define="foo string:" for false as well [11:54] sabdfl: it is a bug in sqlos. sqlos things that ISelectResults has a __len__, but it does not. it has a count() [11:56] to work around, add this in some zcml file somewhere: [11:56] [11:56] [11:56] [11:56] add a comment saying "XXX: working around bug in sqlos. remove when fixed upstream." and a suitable name and date :-) === debonzi [~debonzi@200-158-107-151.dsl.telesp.net.br] has joined #launchpad === debonzi is now known as debonzi|exam [12:39] python question: [12:39] from foo import bar as wibble [12:39] is that correct? [12:40] if that's what you want [12:40] I think it is [12:40] it is syntactically correct [12:40] cool [12:40] from canonical.sourcerer.deb.version import Version as DebianVersion [12:40] is what I want to say [12:41] to get 'DebianVersion' as canonical.sourcerer.deb.version.Version [12:41] yes. c.s.d.v.Version will be bound as DebianVersion in the module's namespace [12:41] coolie [12:43] For implementing a compare function for [] .sort() what does one use as the equivalent of the perl <=> operator? [12:44] don't implement a compare function [12:44] it is slow, and hard to read [12:44] use the schwarzian transform idiom instead [12:44] explain... [12:44] ok [12:46] >>> foo = ['a4', 'b2', 'c6', 'd1'] [12:46] >>> L = [(item[1] , item) for item in foo] [12:46] >>> L.sort() [12:46] >>> foo = [obj for sortkey, obj in L] [12:46] >>> foo [12:46] ['d1', 'b2', 'a4', 'c6'] [12:46] >>> [12:46] In this case, I wanted to sort the contents of `foo` by the second character [12:46] that's where `item[1] ` comes from in the second line of code [12:47] Hmm [12:47] Merge to rocketfuel@canonical.com/launchpad--devel--0: popup work (patch-770) [12:47] this is usually much clearer than using a comparison function, and vastly faster to execute === Kinnison tries to write the equivalent [12:48] templist = [ DebianVersion(foo) for foo in outpkgs[k] ] [12:48] templist.sort() [12:48] outpkgs[k] = [ str(foo) for foo in templist ] [12:48] bah [12:49] SteveA: that kind of thing? === stub likes his comparison functions ;) [12:49] hang on [12:49] Kinnison: in the first part of the transform, you want to get a list of tuples (sortkey, original) [12:49] sorting tuples only considers the first element? [12:50] then you sort the list of tuples [12:50] sorting a list of tuples onsiders the first element before the second [12:50] then the operation is unuseful [12:50] the original objects are incomparable [12:50] you don't need all this in python 2.4, by the way [12:51] what's the python2.4 syntax? [12:51] I think that since the common-case is for the list to contain two or three elements; I'll put up with the slowness of a sort function [12:51] Kinnison: should still work, if the sort keys are all unique [12:52] >>> L = [(4, 1j), (2, 4j)] [12:52] >>> L.sort() [12:52] >>> L [12:52] [(2, 4j), (4, 1j)] [12:52] >>> 4j < 1j [12:52] Traceback (most recent call last): [12:52] File "", line 1, in ? [12:52] TypeError: cannot compare complex numbers using <, <=, >, >= [12:52] >>> === Kinnison cannot be certain they'll be unique [12:52] Kinnison: okay. Please write it as a function with docstring, and not a lambda === Kinnison already was [12:52] (most of the examples use lambda) [12:52] I don't understand lambda so I don't use it [12:53] Kinnison: well said [12:53] cmp(o1,o2) does the right thing wrt. o1.__comp__(o2) yes? [12:53] s/comp/cmp/ [12:54] sort() will take a 'key' keyword argument [12:54] you mean __cmp__ [12:54] implementing __cmp__ is invariably an arse [12:55] implementing __eq__ and __ne__ and __le__ __and __ge__ is simpler [12:55] It's not my type I'm comparing [12:55] (or, whatever subset of those you need) [12:55] oh, ok [12:55] I'm using the sourceror debian-version tools [12:55] then, yeah, cmp(x, y) [12:55] def compare_packages(p1,p2): [12:55] """Compare packages p1 and p2 by their version; using Debian rules""" [12:55] v1 = DebianVersion(p1.version) [12:55] v2 = DebianVersion(p2.version) [12:55] return cmp(v1,v2) [12:55] __cmp__ was a mistake in python [12:55] is what I just wrote then [12:56] looks good. the python style guide recommends a space after commas. [12:56] right [12:56] Is there an equiv of 'static' to mark a single def as being non-exported? [12:57] what do you mean "non exported" ? [12:57] you can import anything from anywhere [12:57] oh okay [12:57] the python convention is to start something with an _ [12:57] gotcha [12:57] to say it is "private" === Kinnison does that then [12:58] sabdfl: http://www.sourcekeg.co.uk/www.python.org/peps/pep-0290.html#simplifying-custom-sorts [12:59] or even, http://www.python.org/peps/pep-0290.html#simplifying-custom-sorts [12:59] which is the same, but from the canonical source [01:04] SteveA: nice, thanks [01:28] Anyone have any rules about what a valid version number is? I'm thinking same rules as the productname. [01:28] version numbers are very well defined in debian-policy [01:28] assuming that's what you're after [01:28] yup. [01:29] canonical.sourceror.deb.version.Version is an implementation of debian versions [01:29] you can look there for regexps etc [01:29] excellent [01:30] sourcerer even [01:31] upstream is the upstream package's version number (the 2.4beta2 of python-2.4beta2) ? [01:31] yep [01:31] epoch:upstream-debian [01:31] where 'debian' is not permitted to contain hyphens IIRC [01:31] and epoch must be numeric [01:32] (or absent) [01:32] Bad Scott - embedding utf8 characters in source code :-( [01:33] is that bad? [01:34] It assumes everyone on the team has editors set to the correct encoding or autodetecting editors. [01:34] so long as they leave the utf-8 chars alone it'll be fine ;-) [01:34] testDomination (canonical.lucille.tests.test_domination.TestDominator) ... ok === Kinnison bounces [01:35] Now to move on to the tool to move superceded packages to death row [01:36] yay! [01:37] Kinnison: i have a doubt about my decision to remove the superceded / removed items from the Publishing tables [01:37] based on malone [01:37] sabdfl: Oh? [01:37] it's a bit hazy, hear me out === Kinnison is listening [01:38] a use case question is "is there a packagerelease that was uploaded to distrorelease x that fixes a given bug"? [01:38] now, we have bugpackageinfestation, so we can say "that packagerelease fixed this bug" [01:39] but if that packagerelease has been superceded we don't necessarily know if it was ever uploaded to distrorelease c [01:39] x === Kinnison nods [01:39] that's a compelling use-case for something === Kinnison ponders for a moment [01:39] Okay; we add one more PackagePublishingStatus [01:39] we add 'REMOVED' which is chronologically after PENDINGREMOVAL [01:40] don't do it yet [01:40] We never delete from PackagePublishing or SourcePackagePublishing [01:40] would that solve things? [01:40] i think it's worth thinking through the consequences [01:40] The primary consequence is that the publishing tables *will* become massive [01:41] we are working our way through malone, and this interaction between assignments "fix it in this package" and infestation "it's fixed in that package release" is a big grey area [01:41] yes, i don't know that we *have* to bloat the Publishing tables to achieve the goal [01:41] there may be a more elegant way [01:42] Okay; another idea just popped into my head [01:42] we have a 'Morgue' table which contains records which passed out of publishing [01:42] We only stash the sourcepackagereleases there [01:42] so the Morgue just says this sourcepackagerelease was in this distrorelease [01:42] and possibly a datetime it was removed [01:43] How does that sound? [01:43] we have to really understand the rest of the problem before i try to solve this bit === Kinnison nods [01:44] an extra REMOVED status is one solution [01:44] I think the Morgue table is preferable [01:44] ok [01:44] We should try to keep the publishing tables as small as possible [01:44] agreed [01:44] don't implement the Morgue just yet [01:44] I won't === Kinnison has plenty to be getting on with [01:45] will you want the solution decided before wednesday; or can we put it on the agenda for then? [01:46] not even by then === Kinnison isn't quite sure what you mean [01:53] we won't need to decide this on wednesday, maybe during es-conf [01:53] Ok okay :-) [01:53] lucille is modular enough that whatever decision we make will be simple to do in her [01:53] super [01:53] zzzuuuuupppa === Kinnison writes more Fake... classes for testing lucille's config gatherer [02:00] SteveA: Are we running Zope3X or trunk? [02:15] Wah! [02:16] sabdfl: Source packages don't have unique names, so we have no unique human readable id to represent them :-( [02:18] stub: i know, it's a pain, but in the real world multiple distros all have the same name for totally different packages [02:20] sabdfl: Can I get away with making UNIQUE(SourcePackage.sourcepackagename, SourcePackage.distro) ? [02:20] stub: alas not [02:20] because the source package in a given distro can change [02:21] for example, in warty (ubuntu) the sourcepackage foo might be different to the sourcepackage in hoary [02:21] They are different sourcepackages though - 'hoary foo' and 'warty foo' [02:22] Oh - that is distrorelease [02:23] Well - if this is the case, there is no way for a user to select a sourcepackage. [02:24] The only way of identifying a particular sourcepackage unambiguously is by its numeric database key. === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad [02:28] stub: we're running a zopex3 trunk from several weeks ago [02:28] sabdfl: I suspect a sourcepackage should be linked to a distrorelease instead of a distribution. Then we can add the require unique constraint and identify a sourcepackage using the combination of its distrorelease.name and sourcepackagename.name and users won't have to guess [02:29] SteveA: Ta. [02:29] stub: for the next update, I'd like us to move to using a .deb, although I need to check whether anyone is still using macosX or something that it won't work with. [02:29] basically, the .deb that will be in hoary [02:30] SteveA: As long as it doesn't delay fixes we make to upstream getting back to our codebase. [02:31] I think at the moment we are encouraged to work around Z3 problem rather than fixing them. It would be good if it is easier to sync upstream with our dev version. [02:32] stub: yeah, we'll be able to generate a new .deb easily [02:32] I've been talking to matthias about it. he's produced some .debs that I need to look at [02:44] stub: afraid not [02:45] because the source package can change during the production of a distrorelease [02:45] when we start a new release, for example, we might just be using the debian package [02:45] then we modify it [02:45] and what we get is a new sourcepackage [02:46] and if the modified one fails to build on an architecture, then we will have TWO different sourcepackages in the same distrorelease at the same time [02:46] one with binary packages in one architecture, and a second in the others [02:46] If we have two sourcepackages in the same distribution with the same name, it is useless because nothing can tell them apart except for a rather meaningless integer id. [02:48] Or at least useless as far as users cannot choose one. This is a show stopper for Malone's sourcepackagebug assignment, as you could end up with a choice between assigning a bug to 'Ubuntu firefox', 'Ubuntu firefox' or 'Ubuntu firefox' and no way to decide between them. [02:53] well, exactly === debonzi|exam is now known as debonzi|lunch [02:57] what's the purpose behind "foo = property(foo)"? [02:59] Makes a function call look like an attribute [03:00] ok [03:00] is it a Python thing? [03:00] yes [03:00] property(getter_func, setter_func, deleter_func, docstring) [03:01] ok [03:01] thanks [03:01] sabdfl: So we have to drop sourcepackagebugassignment then? [03:01] you can have any of those _funcs as None to say "this isn't possible" [03:01] *cough* what? [03:01] stub? [03:01] It is impossible for a user to select a sourcepackage unambiguously. [03:01] so, a read-only property is foo = property(get_foo). write-only is foo = property(None, set_foo) [03:02] stub: right. one solution is to assign the bug to the tuple of (sourcepackagename, distro) [03:02] in other words "fix this damn bug in the package called foo in ubuntu" [03:03] But that isn't unique either. We might have 100 rows in Sourcepackage with that name and distro [03:03] not likely [03:03] bugs would just show up against all of them [03:04] So we would have to create a number of sourcepackagebugassignments instead of one, to match the number of matching rows in sourcepackage ? [03:05] no [03:05] just one assignment [03:05] If we want to represent 'package named blah in ubuntu' we could do it by making the sourcepackagebugassignment link to sourcepackagename and distro [03:05] yes [03:05] "assign to the tuple..." [03:06] but im not quite ready for that yet [03:06] just assign to the *current package called foo" [03:06] which we can do [03:06] there is a big grey area between "assignment" and "infestation" [03:06] which we need to sort out [03:06] it will take a while, mainly using it and figuring out what works [03:07] So we need to somehow determine the 'current' sourcepackages and only present them. [03:07] the soyuz guys have done a lot of work on this [03:07] figuring out which source package to display by default [03:07] ok. I'll chat to them next week. [03:09] stub: where are you running into this? [03:10] in the popup selector? [03:11] Yes - the select a sourcepackage widget. The current one is broken too - we just didn't have suitable sampledata to demonstrate it. [03:14] Merge to rocketfuel@canonical.com/launchpad--devel--0: popup search facility (patch-771) [03:17] SteveA: is there any way to turn a value into a dbschema ENUM object? [03:18] for example, given 40, I want the dbschema.BugSeverity item which has 40 as its vlaue [03:18] stub: we should first answer the questions on how we want it to behave [03:18] with regard to derivative distros [03:19] say someone has a derivative of ubuntu [03:19] kubuntu [03:19] or gnoppix [03:19] and they file a bug on the apache package in there, which is unchanged [03:19] it's basically the ubuntu apache package [03:19] should that bug show up for us, the ubuntu team? or for the gnoppix team? [03:20] if we have a clear answer to that we can implement it easily === debonzi|lunch is now known as debonzi [03:22] My gut feeling is that even though the apache package is unchanged in the derivative, bugs are still specific to that package/distro combination. For example, the bug might be that the unchanged apache just doesn't work under gnoppix === BradB|away is now known as BradB [03:26] sabdfl: BugSeverity.items[40] [03:28] stub: well, my gut feel is that we should at least *record* where the bug report came from [03:28] so that we have the option to filter one way or another [03:28] but more than that, i'm ot certain of [03:28] i want to get malone working in the "single distro" sense before es-conf [03:28] es-conf will largely be about the derivative management process [03:29] for soyuz, lucille, malone, etc [03:32] We still have the 'multiple identical rows in sourcepackage' issue. If we can guarentee that the sourcepackage.sourcepackagename is unique among all the 'current' sourcepackages (however we determine that), then the interface will cope for the time being. [03:33] i dont think this is so bad, actually stub [03:34] we need a slick interface where the dev can say "this isn't a bug in THIS sourcepackage, it's in THAT sourcepackage" [03:34] a reassignment [03:34] these packages are usually tightly related [03:34] the maintainer will know exactly what they are === debonzi [~debonzi@200-158-107-171.dsl.telesp.net.br] has joined #launchpad [03:36] Mmm.... I still suspect that (sourcepackage.sourcepackagename, sourcepackage.distro) should be unique, as I thought sourcepackagerelease was suppose to capture snapshots. [03:41] tat's a lot closer, but i think it's still possible for there to be a completely different source package in the same distro with the same name [03:41] SteveA: is there an existing python class for parsing a configuration file from a string in memory or should I use ConfigParser and StringIO ? [03:44] sabdfl: We need a real use case for that. I suspect that it shouldn't be allowed to happen. The only case I can see at the moment for that would be if different people were maintaining the warty release of a package and the hoary release of a package. [03:44] SteveA: this is for stop-gap config until we normalise it into database columns [03:45] stub: es-conf :-) [03:45] for the moment, display them all, and display maintainer and distro [03:45] should be enough to distinguish them [03:46] hi sabdfl, are you up to date with soyuz status? How does it look like? [03:46] debonzi: haven't had a look in a while [03:46] is it running on mawson with current data from hoary, via gina? [03:46] ok. Can I enforce that? UNIQUE(maintainer, distro, sourcepackagename)? Or should we just trust none of the ubuntu package maintainers will break the interface? [03:46] sabdfl, should be [03:46] Kinnison: ConfigParser and StringIO sounds pretty reasonable [03:47] debonzi: i'll take a look [03:47] SteveA: okies [03:47] SteveA: at least I already know how to use that pair :-) [03:48] sabdfl, right.. we know still a lot to do but we whould like to have some feed back [03:49] breaks the existing popup implementation though, because I don't have a unique human readable key to put in the textbox :-( [03:50] stub: did you write the sessioning stuff for zope3? [03:50] SteveA: yes [03:50] stub: was it discussed at all to have a way of asking if there is a session, without actually starting one? [03:51] right now, even looking to see if there is a session causes one to be created, and the cookie sent to the browser [03:52] is there a use case for not having that behavior? [03:54] well, using sessions for auth, and not wanting the overhead for the anonymous [03:54] There is a method to do it in the implementation (getRequestId), but it isn't exposed in the interface [03:54] right [03:54] I noticed that [04:01] also, the RAMSessionDataStorage thing is rather b0rked [04:02] it doesn't seem to be tied into transactions at all [04:02] so, it gives somewhat random results when used [04:02] I assume this for the auth system, which is storing credentials in the session, so it can say 'there is no client id so I must be anonymous' [04:02] at least, that's what I think was going on [04:02] yes [04:02] Really? The MappingStorage should be handling that. [04:03] yeah, I thought it would do, but it didn't seem to [04:03] I'll look into it later. I've set things up to use the main zodb for launchpad [04:04] If you get different results between the ZODB and the RAM storage there is a bug, since they should work identically. [04:06] sabdfl: did you see my comments about BugFactory? [04:06] BradB: no, where? [04:06] i was about a minute too late yesterday :) [04:07] sabdfl: basically, we need to ensure that all bugs are created with BugFactory [04:07] e.g. when a bug is created from a product [04:07] because BugFactory Does The Right Thing (e.g. adds the submitter as a Cc) [04:07] oh, ok [04:08] it handles both package and product adds [04:08] the submitter should become the owner and that's a special kind of cc anyway [04:08] we need to make owners, and assignment maintainers, visible [04:08] sabdfl: we're not special-casing that though anymore (if the owner *really* wants, they can unsubscribe) [04:09] hmm... seems to me that "owner" is a pretty fricken' special case :-) [04:09] stub: I think it is something to do with the ram storage not paying proper attention to transactions [04:10] or rather, the ram storage in the sessions code [04:10] it isn't a problem with ram storage per se [04:10] sabdfl: in any case, BugFactory should be used, for whatever given rules we have as a bug gets created (rather than maintaining two or three forks of bug creation code) [04:11] ok [04:11] i'll take a look, couldyou file a bug on me please? [04:12] i haven't yet seen your code so i can't be specific, but i guess i can file a bug that says "BugFactory should be used for creating bugs" [04:18] SteveA: If it isn't tying into the transaction system correctly, then it needs someone more familiar with the ZODB guts than me to look at it. Maybe there is a dead chicken to sacrifice to register the connection with the transaction system that has to be done for each request. [04:18] New Malone bug #41: "BugFactory should be used to create bugs", submitted by Brad Bollenbach [04:18]