=== kiko-afk is now known as kiko === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [12:47] BradB: The existing vocabulary tests should show you what is needed. [12:49] Urgh - which I can't find any more. I could have sworn there were some there :-( [12:52] And the work I did splitting up the Launchpad harness into standalone setUp and tearDown methods never landed. [12:52] It'll be worth deploying a new dogfood once I land this bug-id-in-subject-line-on-add patch [12:52] BradB: Yup === BradB waits while make check runs [12:54] harness.LaunchpadFunctionalTestCase is supposed to setup the database and all the Z3 infrastructure for functional tests (although Carlos was going to land a patch last night I think because I forgot to actually call the superclasses setup/teardown). [12:55] stub: I know. The problem is, this isn't a functional test. [12:55] A functional test is like "add a bug". [12:56] I wanna test one teeny little thing, that just happens to grab some data from the outside world. [12:57] Yup. I moved the pgsql.py harness into ftests because SteveA seemed to be saying it was a functional test because it hit the database, but I think you are right and it should stay in the Unit test area. [12:58] stub: SteveA, daf and I had this argume^Wdiscussion in London. :P [12:58] I think pureist thinging says you need a stub implementation of the database, but in our environment SQLObject are just another provided datatype that we should be treating like dictionaries. [12:59] stub: My major concern there is that stub implementations are a Real World Nightmare to work with. [12:59] The rely on knowing the *implementation* of the code your testing, which is masochistic. [01:00] Hey - I think I personally caused the stub implemenations in soyuz and rosetta to be dropped because I never bothered with it in Malone and it worked dammit ;) [01:00] heh [01:01] I built the world's most solid credit card payment processing on the same philosophy (i.e. test stubs usually suck) [01:01] s/processing/processing system/ # okay, there might be one or two better [01:03] daf: I'm now just waiting on tla as I land the bug id fix. Can we expect dilys's malone notifications to be working tomorrow? === BradB tells tla to fogo na bomba === stub wonders if he should attempt upgrading to Hoary [01:16] stub: what's the status of airport cards being supported in linux? [01:16] i want to install ubuntu on my other powerbook (the 15" 867 MHz), and see if it'll run faster than this 1.5 GHz one. [01:16] I have no idea. I'm not on a mac any more so haven't been following. [01:28] Merge to rocketfuel@canonical.com/launchpad--devel--0: add bug id to subject line in bug add emails. cleanup bug add machinery and remove some dead chickens. (patch-764) [01:31] stub: anytime you want to rollout a new dogfood, go ahead. [01:35] Oohh..... from z3-users [01:35] No, but in order for them to work well, the have to be ILocations; you can put a proxy around the values before returning them using zope.app.location.locate(object, parent, name). [01:36] Might be possible to hack that into our publisher method and make everything that is traversable to locatable [01:43] that's what i was saying though :) [01:43] we need locations [01:44] the way it is now is screwed up. bugcontainers contain bugs, but bugs don't know that they're in bugcontainers. [01:49] Mmm.... it might be trivial to switch it on though - I suspect it involves changing a single method. I might give it a try ;) [01:59] BradB: I spoke too soon last night about the bug watches. Our internal bugzilla is setup so you need to be logged in before you can see a bug. I suspect we need to extend the BugTracker table to contain a username and password, and refactor the checkwatches.py script to goto that tracker types login form, login, and maintain the auth information when it then checks the bugs on that external tracker. Which is annoying because we proba [02:00] Hmm... maybe I could just hardcode auth information in there for our internal one... [02:01] watches in general will need to support the possibility that logging in to the remote system could be required [02:03] is the intent for dogfooding that we'll be watching dogfood bugs that were already reported in bugzilla? (i.e. before i got jdub to make that impossible) [02:03] ...until they're migrated in a week or two. === BradB is now known as BradB|afk [02:20] Merge to thelove@canonical.com/bazaar--devo--1.0: Making test-dir-regexps.sh posixly correct (patch-64) [02:58] stub: so will there be a new dogfood by the time Canada wakes up tomorrow? [03:01] BradB|afk: yup [03:01] sweet [03:02] It is pretty trivial for me to rollout now and difficult to screw up. [03:02] cool === BradB|afk is now known as BradB|away [04:44] SteveA: ping [06:18] BradB|away: sure, as long as I have some sample emails to work with [09:26] daf: At this stage, I think we just want to report the subject line of emails that have an errors-to: set to bounces@canonical.com - that should be future proof while we tweak the templates. === ddaa [~ddaa@deep-thought.xlii.org] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === Kinnison [~dsilvers@host81-153-126-219.range81-153.btcentralplus.com] has joined #launchpad [10:12] Morning === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:18] lulu! === Kinnison dances [10:18] morning :o) === doko [doko@dsl-082-082-210-084.arcor-ip.net] has joined #launchpad === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [01:00] Morning sabdfl [01:01] hiya === cprov [~cprov@200.158.100.251] has joined #launchpad [01:11] stub: how did that popup page selector work out? [01:11] hiya BradB|away [01:12] sabdfl: Partially done. I think it will be running by the end of tomorrow. [01:13] Itegrates happily as a standard widget, and the popup is working. I just have to have the popup contain content and the javascript to push the value back to the form. === debonzi [~debonzi@200.158.100.251] has joined #launchpad === debonzi [~debonzi@200.158.100.251] has joined #launchpad [03:28] Kinnison: what's been the focus since you got archives published? [03:29] sabdfl: "The focus" ? [03:29] sabdfl: gina-wise, the dogfood server and hoary [03:29] sabdfl: lucille-wise, getting a pile of unit-tests done for all the publishing stuff and then the domination and unpublishing stuff [03:30] ok [03:30] sabdfl: I have been prioritising dogfood over lucille recently; although that has receeded into nearly no time now [03:31] So apart from periodic dogfood related sidelines; I'm back to lucille full-time [03:31] do you think the spanish inquistion will need to roast your tosies to get derivative distros working before christmas? [03:31] ok [03:31] my toesies?! eep! === Kinnison doesn't want his toes roasted; that's fer sure [03:32] Hopefully wednesday next week will leave me pretty much clear to get single-distro working nicely [03:32] Derivative distros needs all the policy stuff assuming we're not faking it [03:32] right [03:32] Hopefully we'll get a chance to discuss some of that next week [03:32] yes [03:32] Cool [03:32] we'll start as simple as possible [03:32] germinate-style [03:32] Do you want me to try and come up with an agenda for wednesday? [03:33] just a list of packages to be included [03:33] good idea to have an agenda === BradB|away is now known as BradB [03:36] morning [03:37] brad. [03:37] mornin' bradb [03:37] nice cleanup work in malone btw on the bug add forms etc [03:38] thanks [03:39] dilys integration should be a real possibility today. i'm sure we'll end up reformatting the notification emails at some point, but they provide everything dilys needs now. [03:41] awesome [03:44] i think we should make the product / package selection compulsory for new bugs [03:44] ok [03:44] given the Packaging table which links product and package, we should be able to make it quick [03:46] what do you mean "make it quick"? make it quick to figure out if the selected a package or product? [03:47] s,the,they, [03:49] spiv: can I disable globally the stderr proxy twistd puts in place? [03:49] ddaa: hmm [03:50] I suspect it's what causes the gdb stuff to segfaults [03:51] I successfully got the gdb macros to run on a dummy python script. [03:51] BradB: selecting a package should immediately preselect the relevant product [03:52] ddaa: there's no option in twistd to do it... [03:52] ddaa: it's a hack, but the simplest way would be to edit the startLoggingWithObserver function in twisted/python/log.py [03:53] Changing the default value of setStdout should be sufficient. [03:53] sabdfl: ah. IOW, /both/ are required. [03:53] spiv: well, then when is it done? I am happy if I can just add a bit of client code to restore sys.stderr out of sys.__stderr__ at some point. [03:53] (that flag affects sterr too) [03:53] ddaa: Well, it's done before running the tap/tac. [03:54] So I suspect you could sort it out in buildbot's master.cfg thing. [03:54] i'm not sure we can require both, since we can't be certain that the product entry has been created [03:54] also, the bug might not exist upstream [03:54] spiv: I'm interested in doing that in the slave. [03:54] for example, if it's purely a packaging bug [03:54] then it only exists in the package, not upstream [03:56] sabdfl: is it worth auto-selecting the product then? i would have thought it'd be common that the bug reporter would have no idea if the bug exists upstream. [03:57] ddaa: I suppose you could do it with something that does "reactor.addSystemEventTrigger('before', 'startup', setattr, sys, 'stderr', sys.__stderr__)" [03:57] sabdfl: stub was saying that maybe there was a specific reason that we don't want the product selection widget on the bug add form too. i think he was saying that it would confuse users (i.e. it's probably enough for us to leave it to the package maintainer to decide if a product assignment is warranted.) [03:58] ddaa: Personally, I'd just edit log.py ;) === ddaa looks at spiv with blank stare [03:58] hmm... good idea [03:58] ddaa: I don't know the slave code well enough to know where a good spot to put that call would be, hence my slightly vague advice. === ddaa follows spiv advice [03:59] sabdfl: ok, i'll remove it today. [03:59] i think it would also be possible to add a bug directly to a product, which creates the bug, and a bug-product-assignment [03:59] remember, we want to be able to use malone for pure-upstream projects too [03:59] sabdfl: that's technically how we should be assigning bugs to malone. [04:00] yes [04:00] maybe two add forms? i'm not sure... [04:00] go to the product, then "file bug" [04:00] i'll have a stab at that [04:00] now [04:00] ok [04:01] owwwie! unittests hurt my fingers [04:01] what are the semantics of page test creation now? [04:04] spiv: your suggestion does not seem to work terribly well... [04:05] sabdfl: each dir in pagetests is a "story" [04:05] sabdfl: for each "story", a fresh db is created. [04:05] ./makepagetest {xx,nn} some cool test [04:05] xx if it's stand-alone, nn if it depends on the previous test. [04:06] Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix zopeless bug for Carlos (patch-765) [04:06] that puts the test in pagetests/, then you move it to the appropriate story and elide all the crap not related to what you're testing. [04:06] right [04:07] ddaa: Hmm :/ [04:08] sabdfl: i /think/ that it's appropriate for each app to be a story. i started that malone dir, because standalone was starting to get a bit overwhelming. we might want to gradually make standalone/ go away (and the tests therein be moved to malone/ soyuz/ rosetta/ and launchpad/) === debonzi [~debonzi@200.158.100.251] has joined #launchpad [04:19] so creation is unchanged, just move them to a story afterwards? === debonzi [~debonzi@200.158.100.251] has joined #launchpad [04:25] progress... I added the sys.stdout/stderr restauration hack at some essentially random place, and now it segfauts just a bit later [04:27] mh... well, no... actually, just at the same place :-( [04:33] hehe... that was the "print local variables" that screwed at some point :-) === debonzi is now known as debonzi|lunxh === debonzi|lunxh is now known as debonzi|lunch [04:42] Here it goes. [04:42] sabdfl: correct (sorry, wasn't paying attention to this window for a while) [04:43] Hehe! Not even needing gdb actually... [04:44] I got a familiar "interrupted system call" from within cscvs [04:44] at a point where I used to have an occasional hanf [04:49] BradB: any reason why the page test creation is not recording a POST? [04:50] sabdfl: that should work fine...you're posting on port 9000? [04:51] thought i did [04:51] just tried again and it seems to have got it [04:51] ok === debonzi|lunch is now known as debonzi [05:20] BradB: i think we need a datecreated on the bugassignment tables [05:20] so we can see a list of the bugs assigned to a product, in order of assignment [05:20] or a list of the x latest bugs assigned [05:20] mind if i go ahead and create that? [05:21] we don't yet have that? yes, please feel free to create them. :) [05:22] sabdfl: while you're at it...do we want to add a "note" to assignments and infestations? mdz mentioned something about wanting this. [05:22] ok [05:22] could be tricky to display though [05:23] we could elide it as necessary "blah blah blah..." [05:54] can I sort() a list descending? [05:55] foo.sort(lambda a, b: cmp(b, a)) [05:56] wow, that's immediately obvious, innit [05:56] thanks :-) [05:56] no prob :) [05:59] "foo.sort(); foo.reverse()" works well as well :) [06:00] slower though [06:01] BradB: Actually, no. [06:02] oh, because it's all done in C? [06:02] BradB: The cost of doing n log n python function calls tends to strongly outweigh the cost of reversing the list in C :) [06:02] indeed, indeed. [06:06] looks like 2.4 will make this operation even faster with reverse iteration [06:10] Yeah. And also with supporting a keyfunc to sort. [06:11] So you could do "foo.sort(keyfunc=operator.neg)" [06:12] Too many ways to do it ;) [06:12] heh === BradB is now known as BradB|lunch [07:43] night all :o) === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] === BradB|lunch is now known as BradB [08:18] daf: ping [08:42] BradB: pong [08:49] daf: do you have enough info now to get dilys going with malone? [08:50] I'm working on it as we speak [08:50] awesome [08:52] daf: will we be able to also see who submitted a bug? (i just realized that there's no way to see who made a *change* currently, be at least we know who submitted a bug.) [08:52] s/be at/but at/ [08:53] if you want to :) [08:53] actually, I don't see that information in the report [08:54] Submitted By: [08:54] daf: yes, it's useful to know who submitted that. then we can jump into conversation with that person on IRC, knowing who just submitted it. [08:55] ah, in the headers [08:55] actually, it's currently Owner:, but I made a little fix so that when the next version is rolled out it'll be Submitted By: [08:55] no, in the add mail itself [08:55] oh, *right* [08:55] :) [08:55] cool [09:02] where's Malone, by the way? [09:02] https://launchpad.ubuntu.com/malone [09:02] a bug is at https://launchpad.ubuntu.com/malone/bugs/$bugnumber [09:03] ta [09:05] and what's my password? :) [09:07] i dunno, you tell me :) [09:07] it's whatever it is in ubuntulinux.org [09:07] it's just a dump from production. [09:08] ah === daf tries to remember if he has an accoutn [09:09] yep, you do === daf wonders what the password is [09:14] there's a forgotten password link, that hopefully works correctly on dogfood. you could give it a shot and see what happens. [09:14] where is it? [09:15] https://launchpad.ubuntu.com/ubuntulinux/forgottenpassword [09:15] you see it from going here: https://launchpad.ubuntu.com/ [09:16] ahh [09:16] "Your account details have not been found." :-/ [09:18] daf: you were using the wrong email address. it's dafydd.harries@canonical.com. you've got mail. [09:20] heh [09:20] I also have an account at daf@muse.19inch.net, apparently [09:20] yes [09:20] the forgotten password thing works [09:20] woo [09:20] but it has an incorrect link in the email [09:21] can you file a bug for that and assign it to debonzi? [09:21] well, the link is http://www.ubuntulinux.org/forgottenpassword/... [09:21] and it should be https://launchpad.ubuntu.com/... [09:22] does the code have some way of knowing the correct prefix? [09:22] it should have a way. perhaps it wasn't implemented. [09:23] did you confirm that it's actually correctly resetting the p/w and allowing you to login to dogfood/ [09:25] yes [09:25] also, it redirected me to http://canonical.com after I'd reset my password :) [09:26] heh [09:26] that's something debonzi and steve worked on, so the bug should probably be assigned to debonzi === debonzi [~debonzi@200-158-107-151.dsl.telesp.net.br] has joined #launchpad [09:27] debonzi! [09:27] daf has a bug for you [09:27] in forgottenpassword [09:27] I'll file it in a second [09:27] thanks [09:28] BradB, daf.. right.. just do it :) [09:28] heh [09:32] grrrr [09:32] summaries [09:32] daf, Im going for dinner and Ill take I look on it latter.. see you all [09:32] debonzi: sure [09:32] :) [09:35] New Malone bug #39: forgottenpassword email has incorrect link [09:35] https://launchpad.ubuntu.com/malone/bugs/39 [09:35] (submitted by Dafydd Harries) [09:35] ;P [09:36] :) [09:36] well, I guess I could parse "Owner: ..." for now [09:42] how's this: [09:42] New Malone bug #39: "forgottenpassword email has incorrect link", submitted by Dafydd Harries [09:42] https://launchpad.ubuntu.com/malone/bugs/39 [09:43] ? [09:44] sure. if other #launchpad'ers don't like it, they'll let us know :) [09:45] true :) [10:11] hi all [10:11] dilys! [10:11] nie [10:12] c === SteveA [~steve@adsl-213-190-44-43.takas.lt] has joined #launchpad [10:12] good work daf [10:12] & bradb [10:14] thanks [10:14] sabdfl: thanks [10:15] I have cookie login working nicely in my tree. I need to do something about pagetests before I merge though, otherwise we'll end up with a bit of a mess. [10:15] what kind of mess? [10:15] hopefully you can't merge a mess ;-) [10:16] exactly :) [10:16] BradB: I think you can close #33 now [10:17] I could make it merge, by cleaning up the current mess with a hack. but there would be difficulties when creating new pagetests. [10:17] SteveA: because of expirations? [10:18] SteveA: doesn't the basicauth still work? [10:18] SteveA: the layers work a *treat* [10:18] BradB: no, because of authentication. although basic auth still works, when you create new pagetests, there will be cookie headers that need eliding. [10:18] sabdfl: cool [10:19] SteveA: we elide a lot of stuff anyway. i don't see the problem. [10:19] there's a limitation in the session/cookie api [10:19] you can't see if there is a current session without making a current session [10:20] BradB: I really like that you can create a pagetest, and immediately run it again. it would be a shame to lose that. Then again, it might encourage more elision ;-) [10:20] SteveA: we've already agreed (sabdfl and I, and I think others) that we elide a ton of stuff. we've never been able to record-and-run anyway. [10:21] e.g. you have to elide AuthorizationError's, dates, Content-Length, etc. anyway === sabdfl wonders if it's worth climbing on the "elide everything but one specific page feature" soapbox again === sabdfl decides everyone's heard that message already :-) [10:22] what's the tal foo to give you assignee/browsername OR "No assignee" ? [10:22] in implementing this stuff, I've found a number of bugs I need to file on zope3 [10:22] | [10:23] SteveA: cool [10:23] tal:content="context/whatever | default" [10:23] default being? [10:23]

The default

[10:23] or, [10:23] ah [10:23]

This is always removed

[10:24] nice [10:24] SteveA: I'm looking forward to the bug of not ignoring elisions in diffs output to be fixed, because it's a major pain to do a lot of eliding until that's fixed. Also the broken elisions needs to be fixed. [10:24] you can actually string a load of "|"s together [10:24] first one that works matches? [10:24] yes [10:24] BradB: noted :-) [10:24] Zope3 keeps its own copy of the relevant libs, so we can change them there [10:24] easier than changing them in the python libs [10:25] although, we might be able to get such bugs fixed in python before 2.4 final [10:26] is it possible to use the same addform with different contexts, and do some different post-processing? [10:26] for example [10:26] i want to "add a bug to a product" [10:26] actually, all I want to do is add the bug [10:27] sabdfl: make a new schema for that. [10:27] i think you can: [10:27] then after adding it, i want to add the productassignment [10:27] 1. create a base schema common to both add forms (bug + package and bug + product) [10:28] 2. inherit and create a schema for bug + package. [10:28] base schema should just be IBug [10:28] 3. do the same for bug + product. [10:28] factory should just be Bug [10:28] sabdfl: no, it's a schema for rendering a form to add a package. [10:28] you can use the full IBug schema, then restrict the elements using... [10:29] fields [10:29] sabdfl: schemas are, among other things, there to help zope render forms for you. IBug doesn't include product or package. [10:29] i don't want product or package [10:29] oh, ok [10:29] the use case is: [10:29] navigate to the product or package in doap or soyuz [10:29] then click on "file a new bug for this product/package" [10:29] now all i need is fields from the bug [10:29] create the bug [10:30] *then* create the product/package bugassignment [10:30] you just need to configure two addforms then, i think. one hanging off product, one off package. [10:30] what we've got now is hanging off BugContainer. [10:30] er, but hrm, that might not work. [10:31] btw, i've created a Title field [10:31] and it automatically gets a nice widget [10:31] no need for the displayWidth stuff [10:32] i thought the displayWidth stuff was a feature :) [10:32] Title and Summary [10:32] not all titles will want to be the same width. [10:32] it's a feature i didn't know about so I subclassed TextLine :-) [10:32] it was fun [10:32] we just needed a top-level browser:widget, rather than only a subdirective. [10:32] but anyway, hm [10:32] the idea is that we can have consistent validation rules for a Name, a Title, a Summary (ShortDesc) etc [10:33] right [10:33] i'm just learning here [10:35] i too would have to play around a bit to figure out the best way to do what you're wanting to do with products/packages + filing bugs. maybe SteveA has a more immediate solution. [10:39] i think it's under control [10:39] well... there are two ways I can think [10:39] will let you know what i come up with [10:39] cool [10:45] sabdfl: got a moment to discuss how to provide a useful bug listing, that more clearly shows the user what stuff they need to fix? (or to get someone else to fix :) i think i have an idea. [10:45] ok fire away [10:45] sabdfl: ok, so here's the thing: [10:46] we need one screen in malone where i can go to find out what bugs i need to fix. [10:46] in malone, bugs are assigned to packages or products and infest specific versions of products and packages (to which they may or may not be assigned) [10:47] assignments talk about work needing to be done. infestations just describe the way in which a bug affects a particular version of a thing. [10:47] yes [10:47] so, for our main bug listing ("Outstanding Bugs" or something) we can totally ignore infestations. [10:47] yes [10:47] we need to show that somewhere, but on a different screen [10:47] though we do need to think a little about the connection between infestation and assignment [10:48] sabdfl: there isn't always one. [10:48] yes [10:48] sabdfl: for products and packages that have infestations, we can provide some kind of link or whatever, but that's the easy part. [10:48] right [10:49] so, we show the Outstanding Bugs table with all the columns, including a "package" column, and a "product" column, one of which will be populated in each row. [10:49] and by "all the columns" i mean things like severity, priority, assignee, etc, of course. [10:49] so it's really "outstanding bug assignments" [10:49] mm...kind of. i thought "outstanding bugs" made it more clear, but... [10:50] assignments is a bit of jargon we may not want to include in the title of that page. [10:50] this is one area where i've been tempted by postgres inheritance [10:50] yes [10:50] sabdfl: a guy i used to work with in quebec city is the guy who implemented inheritance in sqlobject. :) [10:51] but anyway, does that seem about right? [10:52] (there's still some issues though, but i think they come down to validation really, rather than altering the fundamental view i have in mind of how this interface should present info) [10:52] yes it does [10:52] hold on a sec [10:52] ... [10:52] ok [10:52] just checked my implementation of the assignment report [10:53] i was trying to focus on the bug itself [10:53] but i can see the point of including the assignment info [10:53] the issues i'm referring to are, e.g. what if there's an infestation saying "affected", but the bug isn't assigned to the corresponding package? things like that. i think we can work that out though, because an infestation is, afterall, not a statement of work. [10:54] that's what i was saying above [10:54] we are going to have to polish off quite a lot of that stuff [10:54] figuring out usability [10:54] yes [10:54] people will take time to understand the model [10:54] yes [10:55] they will assume that saying "this version has the bug" is the same as saying "please fix it!" [10:55] yes, they may indeed [10:55] so the "add an infestation" should default to adding an assignment too, say, with a checkbox, that can be removed [10:56] perhaps if you set "victimised" as the infestation then the assignment is by default not created [10:56] these are polish items [10:56] yes, i was just about to mention that... [10:56] i'll focus on coming up with a better listing first off, in any case. [10:56] do you want me to revamp the bugs assigned report? [10:56] sabdfl: i think it'll be folded into the Outstanding Bugs page. [10:57] e.g. one field on which you can search will be assignee [10:57] and, by default, it may show all the bugs you've been assigned. or not, but either way, another screen won't be needed, i don't think, once this works right. [10:58] nor will the screen i created, for the bugs submitted by [10:58] i would expect that too to be a field i can search on [10:58] where is the outstanding bugs page? [10:59] It's what the "Bugs" page is now becoming. [10:59] er, hm, it shouldn't be called "Outstanding Bugs", I guess [10:59] that's just what the default params will retrieve === debonzi [~debonzi@200-158-107-151.dsl.telesp.net.br] has joined #launchpad [11:03] sabdfl: random though: yeah, a checkbox on an infestation like "[] notify the maintainer of this package" should make the user's life much easier. it would then create the assignment, if needed. [11:03] s/though/thought/ [11:03] yes [11:03] daf, did you file the bug for me? [11:04] sabdfl: i'll proceed with modifying the listing then first, to bring it inline with what we've just discussed. [11:04] debonzi: yeah [11:04] ok [11:04]