[12:37] BradB: is it normal?: Posted by 165 at 2004-11-07 08:48 PM [12:37] BradB: it's from a comment added to the ubuntu website [12:37] seems like it's using the id instead of the real name or nick name [12:37] there's a bug for that [12:38] i had that working; i'm not yet sure what broke it, because i haven't looked [12:38] ok, I was browsing the we and saw it, not sure if it was a know bug === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [03:39] hm, i guess a malone bug doesn't have an "absolute url". [03:42] it seems to me we need to give locations to our objects in order to, for example, provide URL's to bugs in notification emails. [03:42] as it stands, a bug container doesn't contain bugs [03:43] it just looks like it does, but there's no true container/contained relationship there. [03:46] We need an absolute URL - just hasn't been done yet. It will be particularly important if we get to doing bugtracker virtual hosting for projects (gnome.launchpad.org) [03:46] well, sure, that's exactly the problem i'm pondering [03:47] it seems to me that without locations though, bugs can't have absolute URL's [03:47] i.e. without implemented IContained [03:47] and bug containers implementing IContainer [03:47] s/implemented/implementing/ [03:48] i need this right now, for notification emails. [03:48] The Z3 mechanism is to use an adapter to IAbsoluteURL, which is how I would expect it to be implemented. It doesn't require containment (although I had all that stuff in an earlier implementation of Malone, and it worked quite well that way). [03:48] As a quick fix, it would involve writing an adapter from IBug -> IAbsoluteURL that just hardcodes the URL [03:48] yep, that doesn't work though [03:49] because of VH'ing [03:49] And this could be replaced with a non hardcoded url later [03:49] how can something that doesn't have a home have an absolute URL? [03:50] Because you give it one - you could give an object an absolute url of www.google.com?q=Malone%20Bug%206543 if you want, although that would be rather... ummm.... odd. [03:53] We would need to determine 'one true url' for objects though if they can be accessed in different contexts (launchpad.ubuntu.com/bugs/12, gnome.ubuntu.com/bugs/12, launchpad.ubuntu.com/projects/gnome/bugs/12) [03:53] Which is a UI decision [03:54] i wonder why we don't just use locations [03:55] locations? [03:55] since by not using them, our containers, well, aren't. [03:55] IContainer/IContained [03:55] oh. [03:55] It is because SteveA has been arguing about the the differences between containment and traversal [03:56] I don't see a problem with organising our stuff in a containment heirarchy though. [03:56] me neither, particularly since our naming scheme gives the impression that we have containers and objects contained in them, when we in fact don't. [03:57] (Like I said - I had it like that at one stage. I pulled it to make the code more similar to the Rosetta and Soyuz implementations. [03:57] Which is why Malone has containers and other tools have sets ;) [03:57] ah [03:57] that term would make a hell of a lot more sense [03:58] Although that implementation had problems, because it was setting __parent__ during traversal, which meant only objects traversed to had it set up properly. [03:58] setting __parent__ during /traversal/? eek. [03:59] i'd expect __parent__ gets set when an object is added to a container [03:59] I've since learnt about descriptors which are probably the correct way of doing it. [03:59] Bug.__parent__ would need to be a descriptor that calls getUtility(IBugContainer) [04:00] Or we can pull out that Utility bullshit since we don't need to switch between PostgreSQL/stub implementations any more [04:01] (Hmmm.... probably best leave that in or we have to reengineer the entire traversal mechanism for Malone) [04:04] stub: as long as we've got true containment relationships, absolute URL's seem like a SMOP [04:04] SMOP? [04:04] simple matter of programming [04:05] without that, i have no idea how we do an IAbsoluteURL adapter that works with VH'ing. [04:05] If we have true containment relationships, the programming already exists (There are already adapters from IContained -> IAbsoluteURL) [04:05] yeah, that makes sense. === BradB can't wait till Zope 3 is Googlable [04:07] I think we can go with a hardcoded IAbsoluteURL adapter for Bug right now (we aren't doing vhosting yet, although we might need to interrogate request or set an environment variable to determine the server url. [04:08] well "hardcoded", but not, because it has to be able to work when developing locally. [04:08] hardcoded at least to the point that it's $SERVER_URL + "/malone/bugs/" + bug.id [04:08] Do we have access to request as a global now? [04:09] I think we do, but can't remember how to access it... [04:09] not that i'm aware of (which isn't to say there isn't though)...i don't know if there's a utility that can give you the request. [04:09] in stock Z3, there doesn't seem to be such a thing. [04:10] then it's just r.getApplicationURL() + "/malone/bugs/" + str(bug.id) sorta thing [04:10] Jim was writing thread specific globals, which has been fed into the threading module in python 2.4 IIRC [04:10] wow [04:13] speaking of which ++apidoc++ really needs to not raise a NotFoundError on favicon.ico [04:13] ++apidoc++ needs its cool tree icons too... [04:13] oh... I hacked my local Z3 to fix that. [04:14] yeah, i remember you mentioning it somewhere, couldn't remember what it was though. [04:14] I thought it was a bug in the favicon implementation, so was hoping Steve would look into it. [04:14] There are two page templates mentioning favicon in the apidoc area - remove those bits. [04:18] ah yeah [04:19] bradb@oxygen:~/launchpad/lp/sourcecode/zope/src/zope/app/apidoc/browser$ grep -rn favico * [04:19] details_macros.pt:25: tal:attributes="href context/++resource++favicon.png" /> [04:19] menu_macros.pt:27: tal:attributes="href context/++resource++favicon.png" /> [04:24] Ahh sod. SteveA doesn't have an account on lunchfood [04:24] Can't assign him bugs ;) [04:25] heheh...he doesn't? eeek. [04:27] he does [04:28] ok - I need to go pay for my Barcelona tickets and get some groceries. Any bugs you think I should be looking at when I get back, or do you want me to look at the IAbsoluteURL stuff? [04:28] you could look at formatting bug report text and comment text if you want. [04:29]

 and s/\n/
/ are, of course, not viable options, so have fun
[04:29]  Has there been a decision on how that is actually supposed to be done?
[04:29]  oic - make it up, make it sane.
[04:29]  no idea...
[04:31]  stub: no, it's simpler than that, but much harder.
[04:32]  stub: the only thing i mean by "formatting" is to have everything look precisely as it looks now, except that user-entered line breaks should show as line breaks when rendered
[04:39]  Which sounds like newline-to-br, but you said that isn't a viable option?
[04:39]  insecure
[04:40]  it is if you htmlquote as part of the procedure (?)
[04:41]  hm?
[04:41]  def newline_to_br(txt): return htmlquote(txt).replace('\n','
'
[04:41]  )
[04:42]  ah
[04:43]  yeah, that looks good
[04:43]  ok. I'll knock that up and some sort of TAL syntax to make it not suck
[04:43]  yeah, that's what i was hoping for (tal syntax)
[04:44]  is this something that'll be fixed in z3 then?
[04:53]  It might already be there for all I know - "structure context/foo/zope:newline_to_br" or something similar. I'll ask about rolling it back to Z3 if it isn't in there already.
[04:56]  ok
=== BradB is now known as BradB|away
=== doko [doko@dsl-082-082-070-081.arcor-ip.net]  has joined #launchpad
=== ubuntulog [~warthylog@port49.ds1-van.adsl.cybercity.dk]  has joined #launchpad
=== Topic for #launchpad: lunchpad: home of the sandwich artists | fogo na bomba | "qorking along happily, with SteveA egging us on"
=== Topic (#launchpad): set by sabdfl at Tue Oct 19 11:05:38 2004
[11:16] (Kinnison/#launchpad) I guess it's good that I never quite get to the coding stage before the glaring bug stares back at me and makes itself known
=== Kinnison ponders whiteboarding this one
[11:26]  Kinnison: it's usually possible to write some of the tests before even thinking about the algorithm
[11:27]  SteveA: the issue I have is that the algorithm I end up choosing will, to an extent, dictate the data structures the function needs to be given
[11:27]  SteveA: I can't write "testbinarydomination" until I know what _dominateBinaries() will need to be passed to do its job
=== SteveA admits that he has no idea what dominating binaries involves
[11:28]  I think I've gone full-circle back to the simpler algorithm so I'm almost ready :-)
[11:28]  well, Domination is in the glossary :-)
[11:28]  SteveA: how was your holiday?
[11:35]  Kinnison: it was very good.  went to sicily and lounged around and ate well and walked up hills
[11:36]  sounds good
=== cprov [~cprov@200.158.100.251]  has joined #launchpad
=== salgado [~salgado@200-206-134-238.async.com.br]  has joined #launchpad
[12:03]  Morning cprov, salgado 
[12:04]  morning Kinnison
[12:06]  soyuz people: Given a binarypackage.id how do you decide what architecture it is for?
[12:06]  Esp. how do you decide if it is arch-specific or arch-independant?
[12:11]  Anyone?
[12:12]  Kinnison: BynaryPackage.build.processor ?
[12:12]  well, binarypackage.build.processor.processorfamily gets me most of the way there
[12:12]  but it doesn't tell me which of the binarypackage rows are arch-independant
[12:13]  Unless we create an arch-independant processor or something; but that won't sit right with the rest of the publishing stuff
[12:17]  Kinnison, another way is packagepublishing.distroarchrelease.processorfamily
[12:17]  again; doesn't help on the whole arch-specific vs. arch-independant thing
[12:17]  elmo: ping?
[12:20]  Kinnison, uhmmmm .. I think I dont know the arch-independant concept .. what you mean with it?
[12:20]  binary packages are either specific to a given architecture or are shared among all of them
[12:20]  E.g. vim is arch-specific, but vim-common is arch-independant
[12:21]  I.E. vim-common is arch: all
[12:21]  Kinnison, right.. I see 
=== debonzi thinks a bit
[12:24]  Kinnison, is it too stupid to have and processorfamily.name='all'? does it hurt any concept?
[12:25]  erm; where did that extra ping come from I wonder
[12:25]  flarp
=== Kinnison loses control of his irc client
[12:26]  please wait while I try to restore normality
[12:26]  Kinnison, :)
[12:26]  there; better
[12:26]  Kinnison: did you see anything in the CVS protocol that would let me probe for the remote servers time ?
[12:26]  debonzi: right; where do we link that in?
=== carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net]  has joined #launchpad
[12:28]  It's going to cause all sorts of amusing issues with referential integrity IMO
[12:30]  Kinnison, you mean witch page?
[12:30]  page? I'm thinking of the database itself
=== Kinnison is trying to work out how the hell lucille is going to manage arch:all packages built as part of an arch:any sourcepackage
[12:31]  Kinnison, oohhh.. sorry.. I missunderstood
[12:31]  Because currently there's no way to actually determine the architecture of a package referenced in a publishing record
[12:31]  The most I can say is "it is most likely to be "
=== Kinnison thinks he needs to sit with elmo (and probably mark) and try to hammer this our
[12:33]  s/our$/out/
=== debonzi debonzi thinks Kinnison thinks right
[12:34]  morning
[12:34]  carlos, morning
[12:34]  Morning carlos
=== salgado is now known as salgado-afk
[12:59]  Kinnison: ping
[12:59]  lifeless: pong
[12:59]  lifeless> Kinnison: did you see anything in the CVS protocol that would let me probe for the remote servers time ?
=== Kinnison does't remember. Let me check
[01:01]  Nope
[01:02]  :[
[01:10]  lifeless: Any particular reason to want it?
[01:10]  yeah, to filter commits that are in progress
[01:11]  oh blergh; yeah
=== Kinnison workraves
[02:08]  hmm, any explanation about this: /home/carlos/Work/dists/launchpad/lib/canonical/lp/sql.py:51: FutureWarning: Need to set add_missing_from=false in /etc/postgresql/postgresql.conf
[02:09]  carlos: I think this is to help finding out bad queries
[02:09]  ok
[02:10]  this way, postgres will not add missing from clauses in queries, and then the query will break. 
[02:24]  lunch time
=== morgs [~morganc@wblv-249-229.telkomadsl.co.za]  has joined #launchpad
=== debonzi is now known as debonzi|lunch
=== BradB|away is now known as BradB|brb
=== debonzi|lunch is now known as debonzi|away
=== morgs [~morganc@wblv-249-229.telkomadsl.co.za]  has left #launchpad ["Leaving"] 
=== BradB|brb is now known as BradB
[04:25]  FAILED (failures=12, errors=4)
[04:25]  anyone else getting lots of 'make check' errors?
[04:25]  80-add-comment.txt
[04:26]  the code checked in on chinstrap passes all the tests when run on chinstrap
[04:26]  bumflakes.
[04:27]  I've done a blank database schema make too
[04:27]  what does the exception look like?
[04:27]  (for one of the failing func tests)
[04:27]  Failed example:
[04:27]      print http(r"""
[04:27]      GET /malone/bugs/2/ HTTP/1.1
[04:27]      Referer: http://localhost:9000/malone/bugs/2
[04:27]      """)
[04:27]  paste.husk.org for the full tb
[04:29]  http://paste.husk.org/1956
[04:34]  Kinnison: you're running the tests with "make check" presumably?
[04:34]  yep
[04:34]  on a fresh db
[04:35]  what had you just changed?
[04:36]  I just star-merged :-)
=== Kinnison checks if launchpad is missing any of his patches
[04:37]  Kinnison: have you cd database/schema; make'd lately?
[04:37]  Like I said.. a fresh db
[04:38]  launchpad is not missing anything from me
=== BradB wonders why Mark Shuttleworth is duplicated three times there
[04:42]  Kinnison: are there any other func tests failing?
[04:43]  BradB: yes
=== Kinnison tees the output to a file for you
[04:44]  wee hee, tee!
[04:45]  my hunch is that there's something b0rked about your configuration, not yet sure what though.
[04:46]  quite possible
[04:46]  dude, try this
[04:46]  hm, well, it's a bit of a longshot, but...
[04:47]  drop your DB's first
[04:47]  the schema make does
[04:47]  yeah, actually PgTest does it in between stories too, urph
[04:49]  right
[04:49]  https://chinstrap.warthogs.hbd.com/~dsilvers/launchpad-make-check.txt
[04:49]  If you can spot the obvious problem which has eluded me; you win a prize
[04:51]  i don't know what the u/p is to access that page
[04:51]  just mail it to me: bradb@bbnet.ca
=== Kinnison sends it to whatever evolution already has for you
[04:54]  which I think is @canonical.com
[04:56]  Kinnison: have you got a connection open to launchpad_ftest atm? it's worth verifying.
[04:56]  nup
[04:56]  your db isn't getting reset properly.
[04:57]  fresh bootup
[04:58]  there's a connection open to launchpad_ftest when there shouldn't be. due to that, it fails to reset the db.
[04:58]  put an import pdb; pdb.set_trace() in lib/canonical/ftests/pgsql.py, line 72.
[04:58]  and then "n" over:
[04:58]              name = zapi.getUtility(IConnectionName).name
[04:58]              db_adapter = zapi.getUtility(IZopeDatabaseAdapter, name)
[04:58]              if db_adapter.isConnected():
[04:58]                  # we have to disconnect long enough to drop
[04:58]                  # and recreate the DB
[04:59]                  db_adapter.disconnect()
[04:59]  (which is code i added to disconnect from the db, so that statements further down can drop it)
[04:59]  and make sure it doesn't raise a ComponentLookup error the second time through onwards (the first time through it does, because the config hasn't been loaded for that func test)
[05:08]  Okay; let me finish this food and I'll do that
[05:14]  running...
[05:16]  and, if it doesn't raise a CLE, then you could step down to the place where it drops the DB and then look at what other connections are open to launchpad_ftests
[05:16]  s/ftests/ftest/
[05:16]  still waiting...
[05:21]  it didn't stop
[05:26]  eh, something sounds very b0rked about your config
[05:26]  it might be that you have another version of the code installed somewhere else, i dunno.
=== Kinnison shrugs
=== SteveA [~steve@adsl-213-190-44-43.takas.lt]  has joined #launchpad
[05:40]  SteveA: hey, welcomed back
[05:57]  hi carlos
[06:14]  Hi everybody, I apologize for not be present today ...
[06:15]  Kinnison: any new about publishing system ? do you need help ? I need :), how to get librarian interface for sourcefiles portlet in sourcepackage page ?
[06:17]  The launchpad instance should probably have a global instance of canonical.librarian.client.FileDownloadClient which has been initialised according to some global config somewhere (I don't understand zope so you'll have to get someone who does to do that bit)
[06:17]  Then you can simply call fooobject.getFileByAlias(the_file_alias)
[06:17]  where fooobject is that FileDownloadClient instance
[06:18]  the alias is the value of the column libraryfile in sourcepackagereleasefile
[06:18]  Kinnison: great !! there is something already published to play ? Any idead about how will be the behavior to download an .orig or .deb using Zope ? 
[06:19]  anything gina has imported has those files in the librarian ready
[06:19]  no idea how you would stream it through zope
[06:19]  I have a patch (uncomitted) which would allow you to get the URL out; but I haven't finished and tested it yet
[06:19]  I could bubble that to the top of my todo if you'd like
=== Kinnison might be able to get it done later tonight (about 23:00 my time) since I'm going out at 18:00 for shopping and to go to a restaurant
[06:20]  Kinnison: yes, or if you'd like help for test it, just send it to me 
[06:21]  It has some utf-8 changes in it too; so I'll have to test it well first
[06:24]  Kinnison: ok, as you want, just let me know if you need help
=== BradB never knew you could do foo = `bar` in Python
[06:29]  BradB: what do you mean ? bar = 2; foo = `bar`, then foo is '2' ...is it tricky ?
[06:32]  it's surprising
[06:33]  `` is normally for stringifying the output of a shell command, where i come from. odd that python ok's things like ``, but not (foo ? bar : baz)
=== BradB takes a copy of the ubuntu site to debug an ugly perms problem
[06:34]  SteveA: ping
[06:34]  hi brad
[06:34]  BradB: aha, it surprises me too 
[06:35]  SteveA: hey! how was your vacation?
[06:35]  thanks, it was great
[06:35]  I'm very refreshed
[06:35]  good to hear
[06:35]  SteveA: we've got a problem with placelessness now.
[06:36]  SteveA: i want to be able to provide a URL to a bug, e.g. in a notification email
[06:36]  as well, i'm sure there are lots of places we either do, or will want to provide an absolute URL for a given object (a bug, a source package release, a whatever)
[06:37]  in a placeful world, this is simple (and, AFAIK, well-supported in Z3, with an adapter from IContained to IAbsoluteURL)
[06:37]  well, kind of
[06:37]  how do I provide an absolute URL for things that don't live anywhere though?
[06:37]  it is actually a little more trickly than that
[06:38]  SteveA: point being though, if i implemented IContained, getting my absolute url in Z3 Just Works, right?
[06:39]  BradB: would it amuse you to know that having had a snack; the ftests run okay now?
[06:39]  Kinnison: computers suck
[06:39]  BradB: I blame a gremlin
[06:39]  it's trickier than that
[06:40]  consider the situation where you want an XMLRPC request on an internal ip address and port to signal the sending of email
[06:40]  but, the email will need to have the official URL used
[06:41]  one element is the domain and protocol and port to use.  another element is the path of the url to use
[06:41]  SteveA: that's trivial to work around though
[06:41]  e.g. with /etc/hosts
[06:41]  the path can be handled with a correct absolute url implementation  
[06:41]  not with /etc/hosts, I think
[06:41]  I don't think we need IContained
[06:41]  or just using the real url?
[06:42]  it seems to me we do. i have zero understanding of how to provide an absolute url that works with VH'ing for objects that have no location.
=== kiko [~kiko@200-206-134-238.async.com.br]  has joined #launchpad
=== cprov [~cprov@200.158.100.251]  has joined #launchpad
[06:43]  SteveA: what's your proposal for providing an absolute url to a placeless object?
[06:44]  the only way i can see is to make some assumptions about the $SERVER_URL, which will not obey the principal of least surprise, i think.
[06:44]  right now, I have some ideas, and some principles.  I need to consider this properly, though.  Right now, I'm up to mid-thursday's email ;-)
[06:44]  Shall we chat about this tomorrow morning (your time) ?
[06:45]  sure. i'll be around by 14:00 GMT
[06:45]  ok, great
[06:45]  SteveA: another issue of pressing concern is answering the question "when do we consider a bug 'resolved'?"
[06:46]  maybe you, mark, stub and I need to chat about that one
[06:46]  in malone, or in our own processes?
[06:46]  I guess you mean in malone
[06:47]  in malone. we've got a couple dozen bugs reported, several of which are fixed, but we have no way of signalling that currently
[06:47]  (or, at the least, if it's doable, it's entirely unclear how to mark a bug "resolved")
[06:47]  there's a resolved in the DBSchema status isn't there?
[06:48]  i don't see it in the UI, so i guess not
[06:48]  there is a "Fixed" on infestations, and a "Closed" on assignments, but that's a few levels of indirection, i.e. confusing.
[06:48]  i don't want to have to mark something infested to be able to say i fixed that bug.
[06:49]  so, something with no infestation should be considered "Fixed" by default ?
[06:50]  no. the only assumption about a bug with no reported infestation is that noone reported an infestation.
[06:50]  you've got:
[06:50]  1. a bug report, which describes something that isn't working as expected.
[06:50]  2. an assignment to zero one or more packages or products, which is simply a way of getting that bug in the face of the person who should see it (e.g. the maintainer of the source package.)
[06:51]  3. infestations, which say precisely which versions are affected by this bug, and exactly how they're affected.
[06:51]  in many real world scenarios, the bug will be so quick to fix that going to the effort of #3 won't be worth it.
[06:53]  but then, let's say you're doing a listing of bugs that are outstanding. how do you know which bugs haven't been fixed? what if all the "assignments" are "closed", but there's somehow still an infestation or two that are marked as "affected" (instead of "fixed")?
=== ddaa [~ddaa@nemesis.xlii.org]  has left #launchpad [] 
[06:56]  and, what about bogus bugs?
[06:56]  it should be easy to say "not a bug"
[06:59]  you can mark infestations as "won't fix"
[06:59]  but again, that requires two levels of indirection, if you will (e.g. assigning to a package, and then specifying an infested version of that package too)
[07:01]  the workflow really needs some thinking through (i've reported a bug for it in malone)
[07:01]  ok
[07:02]  it's a recurring problem in launchpad -- we're modeling complex things, but we have pretty simple overall actions sometimes
[07:02]  is there a meeting on wednesday? maybe we can discuss it then.
=== sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
[07:04]  Did stu arrange a time for the next meeting at the end of wednesday's one?
[07:04]  hi all
[07:05]  hiya
[07:05]  hey SteveA, have a good break?
[07:05]  hello mark
[07:05]  SteveA: no
[07:05]  hi sabdfl 
[07:05]  kiki!
[07:05]  !
[07:05]  am just catching up now
[07:05]  refueling
[07:05]  any immediate news?
[07:05]  BradB: I think this is something best disussed among you malone folks, perhaps with some input from james or kinnison
[07:05]  sabdfl: great break.  very refreshed.  still catching up on email / code.
=== kiko catches up on tons of weekend email
[07:06]  sabdfl: two pressing issues in malone: 1. how to get a URL to a bug (seems like a bit of a doozy with placeless objects), and perhaps slightly more urgent 2. answering the question "is this bug resolved?"
=== Kinnison -> out, I'll bbl
[07:12]  bradb: regarding number 2: "it depends on your perspective", it depends on the assignment to your context
[07:12]  for example, if you are upstream, then check the product assignment
[07:13]  what if an assignment is "closed", but the infestation says "affected"? what if there's an infested release of a product for which there's been no assignment of the bug to that product?
[07:16]  more specifically, several of the bugs at https://launchpad.ubuntu.com/malone/bugs shouldn't be showing, because they're already fixed. i don't know how to decide which ones to show and not show though.
[07:19]  brad and I are going to talk in detail about 1 tomorrow
[07:20]  BradB: yes, that page is just listing every bug in the system
[07:20]  i guess a "show me the bugs view" is useless without a context
[07:20]  need to show the bugs for a product or source package
[07:20]  or possible a project or distro, which are aggregates of products and packages respectively
[07:23]  yes, i think the mdz's of the world will want a god view
[07:24]  there's a third pressing issue to note too, which is the need for a combo box (it's exceedingly difficult to choose values for certain fields currently)
=== SteveA --> gym
[07:32]  sabdfl: (sticking with #2 for the moment) by "context" do you mean we turn the bug listing into a search form (e.g. to specify packages assigned to, products assigned to, etc.) with default search params set based on the current user where possible?
[07:32]  yes
[07:32]  see the bugs assigned page i've done
[07:32]  it's basically a search form
=== lulu [~lu@host217-37-231-28.in-addr.btopenworld.com]  has left #launchpad [] 
[07:35]  yeah, ok. the implementation of this gets slightly hairy (because e.g. we need all the package and product assignment and infestation search fields to i. allow us to easily choose from a huge # of options and 2. be multi-select), but i don't see any other way
[07:36]  IOW, the search criteria widgets will take up a lot of real estate
[07:46]  Do we have already an example about how to create a temporal database to do some funtional tests?
[07:46]  I mean, how to integrate it into the make fullcheck command
[07:46]  the rosetta functional tests are broken at this moment because all database changes we did
[07:47]  inherit from LaunchpadTestCase
=== debonzi|away is now known as debonzi
[07:47]  BradB: is it documented in any place?
=== carlos is not talking about page tests
=== salgado [~salgado@200-206-134-238.async.com.br]  has joined #launchpad
[07:49]  carlos: only in the docstring of the class (which is pretty pithy)
[07:50]  sorry, there's LaunchpadFunctionalTestCase too (which inherits from LaunchpadTestCase)
[07:50]  other than that, i'd just read the other functional test cases
[07:50]  ok, thanks
[07:56]  hmm
[07:56]  I'm trying to file my first bug report with malone
[07:56]  for Rosetta
[07:57]  file it against the source package rosetta
[07:57]  Which ones should be the "Source Package" and Product?
[07:57]  yeah, that was my question :-)
[07:57]  psychic i am :P
[07:57]  BradB: should I select a product?
[07:57]  nope
[07:57]  I suppose you already know that... but it's not too user friendly...
[07:58]  also, the lists should be sorted by name
[08:00]  how could I assign the bug or set its severity, priority or just change its status?
[08:00]  carlos: yep, malone isn't launchpad friendly, because it's not built for systems like launchpad, but rather for linux distributions with source packages and products.
[08:00]  carlos: and there's a bug already filed for sort order (but we need a combo box too, of course)
[08:01]  carlos: by editing the package assignment
[08:02]  ooh, we need a way to show the user that it's clicking over that field
[08:02]  I did not saw that's the way to edit it...
[08:02]  ?
[08:02]  what do you mean "that it's clicking over that field"?
[08:02]  oh, click to edit
[08:02]  yes
[08:03]  it did not thought about it
[08:03]  i did not thought about it
[08:03]  hmm, last comment about malone :-P
[08:03]  the bug report comes from your mail domain instead of canonical or ubuntu, is that normal?
[08:04]  From: 	noreply@bbnet.ca
[08:04]  Reply-To: 	noreply@bbnet.ca
[08:04]  To: 	carlos.perello@canonical.com
[08:04]  Subject: 	'Fix Rosetta functional tests' added
[08:04]  Date: 	Mon, 08 Nov 2004 18:58:40 -0000  (19:58 CET)
[08:04]  that's fixed, but not deployed
[08:04]  ok
[08:05]  if you think there are things that are weird about malone, by all means take a look and see if someone's already reported it and if not, feel free to report it.
[08:05]  ok
[08:06]  Will do, don't worry
[08:06]  cool, thanks :)
[08:06]  We use hardly the BTS from Rosetta
=== BradB is now known as BradB|lunch
=== BradB|lunch is now known as BradB
=== kiko is now known as kiko-fud
[10:43]  BradB: any chance of getting Malone notification emails to include bug numbers any time soon?
[10:45]  daf: the idea is to put the URL in there, which isn't trivial. i'll be discussing that with SteveA tomorrow morning
[10:45]  elmo: ping
[10:45]  I think having the bug number would be good enough for now
[10:46]  to get Dilys working with Malone, at least
[10:47]  ah yeah, i could indeed throw it in the subject line
[10:47]  to also be consistent with bugzilla
[10:47]  that would be groovy
[10:55]  daf: dilys is not doing her work today, I closed two bugs and did some commits and I don't remember see them in the channel
[10:57]  hmm
[10:58]  test
[11:04]  test
[11:06]  Bug 2147 resolved: We are not setting the iscomplete flag when a translation has all needed strings
[11:06]  https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2147
[11:06]  ah, found it
[11:07]  I recently made dilys use a config file, and the Bugzilla address in the config file was wrong
[11:20]  daf: :-P
=== dilys feels better
=== Kinnison sniggers dilys
[11:31]  daf: what is the earliest reasonable time you can attend a launchpad meeting?
[11:32]  well, I thought 8am was possible, but it seems I was wrong
[11:32]  foo
[11:32]  say foo
[11:32]  me foo
[11:32]  hmm
[11:35]  SteveA: I'm willing to try for 8am one more time
[11:36]  SteveA: are you thinking tomorrow or wednesday?
[11:45]  daf: what time is 8am in UTC ?
[11:46]  carlos: 12:00
[11:46]  ok
[11:50]  Kinnison: wednesday
[11:50]  SteveA: *nod* just thought I'd check and remind myself :-)
[11:51]  let's say 12:30 UTC then.  sound okay?
[11:51]  fine for me
[11:51]  yeah
[11:52]  yip; sounds good
[11:53]  ok
[11:53]  BradB: 
[11:53]  sure
[11:54]  great
=== SteveA --> bed