=== AndreNoel [n=noel@200.175.38.38.adsl.gvt.net.br] has joined #launchpad === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === bluefoxicy [n=bluefox@c-68-33-112-13.hsd1.md.comcast.net] has joined #launchpad === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [01:27] bradb: around ? [01:27] lifeless: yeah [01:28] do you think, that if I send an email to new-bugs, cc'd to $person, malone would be sane in subscrbing $person automatically? [01:30] be^ [01:30] bradb: ^ [01:30] lifeless: I don't know that there's a correct answer to that question, but it would probably be more sane than not. [01:30] lifeless: in that case I would add a header to the first email LP sends to $person that he has been subscribed because.... [01:30] Roundup does that, I believe. [01:30] would you like a wishlist bug or a placeholder spec ? [01:31] lifeless: bug sounds good [01:31] how do you tell the bugmail to be wishlist ? [01:32] lifeless: you can't change priority via email, unfortunately [01:32] ha! [01:32] is that by design ? [01:33] lifeless: not really [01:33] want a bug on that too ? [01:36] lifeless: er, n/m, i'm on crack === bradb wonders if the email ui might be on crack though. /me checks something [01:37] lifeless: you can change importance through the email UI, but if it's working properly that should be restricted to only bugcontacts and drivers [01:38] fair enough [01:38] ... how ? [01:40] lifeless: https://help.launchpad.net/UsingMaloneEmail#head-193f41e9738ba7e7f971421b5ef98657eedad873 [01:41] thanks [01:41] np [01:41] bug 55113 is for thee [01:41] 'Malone bug 55113 in malone "ccing a person in mail to malone should subscribe them to the bugs\n\taffected." [Untriaged,Unconfirmed] http://launchpad.net/bugs/55113' [01:41] thanks [01:42] aww, rfc822 normalisation fucks over malone. [01:42] new bug coming up [01:45] bradb: also [01:45] bradb: why does it take malone so long to acknowledge my new bug filings via email ? [01:46] lifeless: AIUI, the emails are processed by a cron job every N minutes. bjornt could confirm. [01:46] I was wondering if the 'group actions when emailing' code was grouping new bug mail too [01:47] because its a new bug no-one can possibly have followed up on it immediately [01:47] so it would make sense to reply immediately IMO [01:49] that may be true. if you want to make sure bjornt sees it, feel free to file a bug. [01:49] ok [01:50] I've filed another one, on the syntax [01:50] accepting accepts: /products/malone would be really nice UI [01:50] (as well as accpeting affects /products/malone) [01:51] sfllaw: are you about? [01:51] lifeless: you mean "accepting affects: /products/malone", presumably? [01:52] yes [01:52] I also wrote a cute email to demonstrate this :) [01:52] https://launchpad.net/products/malone/+bug/55115 [01:52] Malone bug 55115 in malone "control lines in bugmail should accept : prefixes" [Untriaged,Unconfirmed] [01:52] right [01:53] \: [01:53] bluefoxicy, can you remind me tomorrow to generate the stats for you? i'm so tired tonight.. [01:53] heh, 3 of the last 5 bugs across malone reported by me :) [01:53] kiko-zzz: nods. I still say it'd be nice to have a feature to spit out various statistics through launchpad. === bradb would like to tag these bugs as "email" [01:53] kiko-zzz: I'm in no hurry ;) [01:54] 4 of the last 5 [01:54] bluefoxicy, yeah, but the devil's in the details -- how many statistics, and what sort of flexibility you want in generating them (per-month? per-week? grouped? by person? etc. it gets hairy) [01:55] kiko-zzz: flexible infra and step feature by feature :) [01:55] anyway nighters, see you another time [01:55] bluefoxicy: Yes. [01:55] I'm making supper though. [01:55] How can I help you? [01:55] (I may pop out to check the stove.) [01:57] sfllaw: oh, I was just looking for stats on how many bugs get reported per month in Ubuntu on launchpad [01:57] kiko said either you or he may be able to help me with that :) === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [02:01] (there's other interesting data that I could use too, but it's not really important) [02:02] Per month? [02:02] I don't know specifically. [02:02] Lemme look at my charts. [02:03] We seem to get about 1000 per week. [02:03] So about 3500-4000 per month. [02:04] I thought the number was increasing overtime? === lifeless waves at sfllaw [02:04] sfllaw: btw there is a distributed test manager written in python already [02:05] Huh. [02:05] Neato. [02:06] I'm not adverse to borrowing. [02:06] I'll hunt down a link [02:08] http://www.codesourcery.com/qmtest/ [02:08] I have not used it myself [02:11] Ah. CodeSourcery. [02:11] I'll ask scjody about it. [02:11] Thanks. [02:12] scjody ? [02:12] Whoops. Wrong guy. [02:12] I mean Carlos O'Donnel. [02:12] Someone I know at CodeSourcery. [02:12] ah cool [02:12] altogether now [02:13] 'its a small small world' [02:13] sfllaw: off the top of your head do you have a number for somewhere around say July 2004? I tried doing a search for all bugs (oldest first) of all statuses and importances, including duplicates, in Ubuntu; results showed around 350-400 bugs between 6912 through 7250 being in Ubuntu [02:13] perhaps the search doesn't do what I think :) [02:13] bluefoxicy: We didn't keep track of figures then. [02:13] You might be able to bribe kiko or bradb to extract them for you. [02:13] (I only looked at bugs between 7/01 and 7/30) [02:14] sfllaw: ah. Okay. I guess I'll wait for kiko to get up tomorrow then. [02:14] lifeless: verifyObject(IFoo, foo) raises a BrokenImplementationError claiming that foo doesn't provide method bar, when really it appears the problem is that the current user doesn't have the perms to access method bar. does raising an exception there seem correct to you? [02:14] Of course, back then we were using Bugzilla. [02:14] So we may have lost this data. [02:15] foo is presumably a security proxy ? [02:15] lifeless: yeah [02:15] sfllaw: well, the dates are still in the bugs; https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/6912 for example shows it affects Ubuntu and was reported on 2004-07-01 [02:15] Malone bug 6912 in linux-source-2.6.15 "kernel-source-2.4.26: Kernel panic with NFS traffic over IPsec" [Unknown,Unknown] [02:16] I'm also wondering if I really mean to be verifying the object, or instead doing verifyClass or even IFoo.providedBy. [02:16] sfllaw: but if the data is lost then I'll just have to go with what I can get. :) [02:16] and bar is part of IFoo ? [02:16] lifeless: yeah. works fine when logged in as priv'd user [02:16] bluefoxicy: Is this for some kind of research? === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [02:17] so, I'm not 100% on the underlying mechanism of the security proxy here. But - verifyObject will be probing for all attributes, and should be triggering an access denied exception when it tries to probe for bar [02:17] why are you calling verifyObject ? [02:17] sfllaw: It's not really that important, just flashing a bunch of numbers in a presentation I'm drawing up to explain an idea I had for pitti's automated-problem-reports spec [02:18] lifeless: I want some kind of verification that things are providing the right interfaces [02:18] (in tests) === bluefoxicy sticks the thing up on his server [02:19] bradb: is verifyObject called outside the test code path ? [02:19] lifeless: maybe verifyClass is more appropriate [02:19] lifeless: I'm calling it directly in a doctest. [02:19] ok [02:20] bradb: local interrupt, bb in a couple minutes [02:20] sure, np [02:21] bluefoxicy: Neato. [02:25] uh. Hmm. Server not listening. *goes across the room for a bit* === rpedro [n=rpedro@87-196-71-56.net.novis.pt] has joined #launchpad [02:35] bradb: so [02:35] verifyClass will probably fail the same way [02:35] (it will attempt to find an unboundmethod on the class, and that would allow security holes if you could get at that, then run it with the instance that is the proxy [02:36] I think your test for 'do we get the right interface back' needs to either: [02:36] - be done with a user that has access to the interface as a whole or [02:36] - be done with a more restricted interface that is safe to give to everyone [02:37] - or ask if it implements, not if it verifies [02:37] verify class seems to work [02:37] surprising [02:37] er, verifyClass [02:37] i'm not surprised, tbh [02:38] because BugNomination is not security-wrapped [02:38] but an object returned by bug.addNomination will be [02:38] sfllaw: http://bluefox.kicks-ass.org/stuff/bluefox/slides/slides/img4.html <-- that slide is where I intended the data go; of course, it's just flashing numbers around, considering we already have the drinking-from-the-firehose spec pointing out that the bug load is too high. [02:39] bradb: so testing approach wise, heres a thought [02:39] bradb: verifying that objects implement the interface is best done very close to the code - i.e. within the security proxy boundary, in content-class-level tests === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad [02:40] bradb: outside that boundary, you may not be able to access the entire interface, so just asking if it claims to implement is enough - as long as you have detailed tests at the lower layer [02:42] lifeless: right. i guess i still find it confusing that verifyObject would raise an error in this case. maybe it's not easy to say what the right behaviour should be, in that case. [02:43] though, i think not raising an error is easier to understand [02:49] well [02:49] it cant verify it [02:49] so verifyObject *should* raise an error :0 [02:51] lifeless: that it can't verify it seems like an implementation detail though [02:52] errr [02:52] I'm not sure how that matters [02:53] I guess I can see how it makes sense. === Rui [n=rmps@89.152.8.64] has joined #launchpad [02:56] when you ask verifyObject to verify something, it checks the entire interface to see that your current code can treat all the attributes named as attributes, and callables as callables [02:56] it does not matter *why* you cant use a specific bit in the right way, it only matters that you cannot. [02:58] lifeless: right [02:59] your logic makes sense === Rui [n=rmps@89.152.8.64] has left #launchpad ["Client] === bluefoxicy [n=bluefox@c-68-33-112-13.hsd1.md.comcast.net] has joined #launchpad === kiko_ [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === stub [n=stub@ppp-58.8.3.37.revip2.asianet.co.th] has joined #launchpad === rpedro [n=rpedro@87-196-71-56.net.novis.pt] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad === xenru|clone [n=Miranda@85.192.12.90] has joined #launchpad === mpt [n=mpt@203.118.156.188] has joined #launchpad === jamesh [n=james@81.16.227.227] has joined #launchpad === mpt_ [n=mpt@203.118.156.188] has joined #launchpad === Fujitsu [n=Fujitsu@c58-107-168-5.eburwd7.vic.optusnet.com.au] has joined #launchpad === Spads [n=crack@host-87-74-55-236.bulldogdsl.com] has joined #launchpad [08:54] good morning === rpedro [n=rpedro@87-196-15-9.net.novis.pt] has joined #launchpad === stub [n=stub@ppp-58.8.3.37.revip2.asianet.co.th] has joined #launchpad === BjornT [n=bjorn@195.182.78.95] has joined #launchpad === BjornT- [n=bjorn@195.182.78.95] has joined #launchpad === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === jamesh [n=james@203-59-20-109.dyn.iinet.net.au] has joined #launchpad [09:39] morning === glatzor [n=sebi@ppp-88-217-0-39.dynamic.mnet-online.de] has joined #launchpad [09:42] hi sivang [09:43] hey sabdfl [09:45] mpt_: ping === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:49] Good morning! [09:49] morning ddaa [09:49] mpool: ping [09:49] you have a review [09:49] ddaa: hello [09:49] SteveA: duh! === ddaa kicks emacs [09:50] use vim [09:50] it is betta === lbm [n=lbm@82.192.173.92] has joined #launchpad [09:50] emacs sucks vim rocks. [09:50] it's too modal for my taste [09:50] [09:50] "beeping and non-beeping modes" [09:50] :) [09:50] mpool: hihihi [09:51] hi ddaa [09:51] hey jamesh [09:51] mpool: you seem keen at nailing some kind of roadmap === sivang reverted to vim after emacs's fonts got b0rked on edgy [09:51] mpool: I may have given the impression of waffling in the past days in those discussions [09:52] actually, I was braindumping [09:52] ddaa: not at all, i think your mails have been very informative [09:52] there are two things i would like to talk with you about [09:52] - general planning [09:52] - roundtripping === ddaa thinks he rather turn down The Offspring [09:54] since the former is dependent on the latter let's start on roundtripping [09:54] here or in #bzr? [09:54] how about on skype? [09:55] any reason not to use ekiga [09:55] ? [09:55] ok, I'm popping away for the weekend === jdub [n=jdub@ppp121-112.static.internode.on.net] has joined #launchpad [09:55] lifeless: have a good weekend [09:55] tchau tchau, though I may pop in from time to time [09:55] hey dudes [09:55] lifeless: hey [09:56] any of you guys experienced this bug - [09:56] http://mail.python.org/pipermail/python-bugs-list/2005-June/029183.html [09:56] ? [09:56] lifeless: did you do this braindump about uploading/downloading souce trees for importd? [09:56] "gzip dies on gz files with many appended headers" [09:56] ddaa: i don't have ekiga on this machine [09:56] but otherwise it'd be ok [09:56] I'm hopefully starting to do some work on that today or monday, so it would be useful [09:56] hi jdub [09:57] jdub: cool [09:57] jdub: lovely bug, and no, but I relly must get my gzip tuning patch upstream [09:57] ha ha [09:57] ddaa: dang, I knew I forgot something [09:57] ddaa: its in my TODO [09:58] ddaa: but I've been busy with 0.10 all day [09:58] lifeless: I KNOW the true meaning of this sort of answer :) [09:58] ddaa: so, skype? [09:58] yeah, was connecting the headset [09:58] cool [09:58] ddaa: its agonising working with blueprint at the moment - so many page refreshes, and page load from here is about 5 seconds [09:59] lifeless: there are some similar issues with branches in lp i think - maybe not quite so bad === jamesh [n=james@203-59-20-109.dyn.iinet.net.au] has joined #launchpad === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #launchpad [10:06] ddaa: here's the first draft of my team branches article: https://chinstrap.ubuntu.com/~jamesh/team-branches.html [10:06] if you want to point out bits you think should be added/removed/changed === ddaa is on voice with mpool === imbrandon_ [n=brandon@ubuntu/member/pdpc.active.imbrandon] has joined #launchpad === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [10:22] where should I target a bug in the team expiray email notification? currently I opened it against 'launchpad', maybe this should be against FOAF ? [10:22] s/FOAF/registery [10:23] malone #55156 [10:23] Malone bug 55156 in launchpad "team expairy email should be more useful." [Untriaged,Unconfirmed] http://launchpad.net/bugs/55156 [10:48] jamesh: can you post the text to the ML so people can easily put comments in context? [10:48] or a bzr branch, or a wiki... === danilos [n=danilo@82.117.204.27] has joined #launchpad === doko_ [n=doko@dslb-088-073-098-217.pools.arcor-ip.net] has joined #launchpad === jdub [n=jdub@ppp121-112.static.internode.on.net] has left #launchpad [] [11:08] Is there a mechanism to mass-unsubscribe from bugs? [11:10] Insert beer to continue [11:11] heh [11:11] stub-o-matic [11:12] regretfully I have little option for delivery of beer === Kinnison keeps on clicking [11:31] hi! where do I change Status on support tickets? :-) [11:39] Kinnison: stub will be in London next week ... === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === ddaa notes with great satisfaction that the emacs import is now up to revision 40936 [11:52] how many revs do you think it has? [11:53] 76334 revs on MAIN [11:53] sadly, it's a roomba import ATM [11:53] meaning we'll have to start it over again on hoover before publishing it [11:54] also, as usual, there's no guarantee it's going to pass the final cross check at the end === ddaa will run the python import directly on hoover [11:57] kudos to the emacs sysadmin, it only lost the cvs connection once, on the initial changeset (most import do, cvs appears to be unable to do check-out like operation in the same connection as a rlog) [11:59] So we can no longer import SVN branches if there is no longer a corresponding sourcepackage? [12:00] stub: http://svn.python.org/projects/python/trunk [12:00] oops [12:00] stub: https://launchpad.net/products/launchpad-bazaar/+bug/46240 [12:00] Malone bug 46240 in launchpad-bazaar "posting $series/+source yields a confusing warning" [High,Confirmed] [12:01] Known problem, but merely confusing, and relatively low profile. [12:03] ta [12:47] ddaa: do those imports go much more quickly with native-bzr tech? [12:49] Yes, the diff*history cost of baz was a real killer for really large branches. [12:49] So we squashed down a really large quadratic factor on the cost of large initial imports. [12:50] But it's still short of blindingly fast [12:50] The emacs import has been running since Tuesday 07:10 [12:54] My uninformed performance guess is that most of cost lies in server round-trip. SVN import almost certainly do many more requests than they have to. CVS is probably better off. But in both cases we are still server-roundtrip bound, and we can probably do pipelining. [12:54] But since it's a guess and not a profiling result, it's virtually worthless. [12:56] Mh, actually, just since wednesday 07:10, it seems [01:28] good morning, guys [01:42] hi cprov [01:42] SteveA, pong [01:42] cprov, did you see the message from Roshan Shariff on ubuntu-devel@? [01:43] mpt_: hi, not I'm not subscribed, can you forward it to me (btw, I will subscribe myself rigth now) [01:43] cprov, well, it's mostly not interesting, but there's just one message about a possible soyuz problem [01:43] cprov, sent [01:44] mpt_: thanks === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:57] hi mpt_ === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:08] ddaa: so, if we can get a tarball of the whole svn repository, we could do the import from a local server [02:08] and much reduce the network roundtripping [02:09] That would indeed be an option. But we had a bad experience with tarballs of cvs repos in the past. The specific issue is that we were sometimes given only a partial tarball that did not include the CVS config information. [02:10] There's also the issue that tarballs may give a a transitory state of the repo. [02:10] what do you mean "transitory state"? [02:10] things like commit-in-progress [02:10] half done modifications [02:10] I don't think that would be an issue for svn [02:10] but even so, it would allow you to get the older history [02:11] and then just update for the newer stuff [02:11] it's an issue for any sort of database where you break the transaction abstraction. [02:11] the problem is not about the older stuff, it's more that we may end up with an invalid repository, or with a repository where the last commits are incorrect [02:12] so, import it ignoring commits for "the last 3 days" [02:12] ddaa: the commits in an fsfs Subversion repo should be atomic [02:12] then update the last three days against the actual live repository [02:12] they'll either be committed, or they won't be [02:12] jamesh: they might be atomic on the systema as a whole, but there still can be a race with the time it takes to generate the tarball. [02:13] I do not know the details. [02:13] But it's a problem congruent to why one should not back-up live filesystems with "cat", but use "dump" instead. [02:14] SteveA: the "import up to some point in the near past" thing is possible [02:14] but that does not alleviate my concern about overall repository consistency. [02:14] maybe it's a misplaced concern, i do not know enough about svn [02:15] there is a protocol in svn [02:15] called 'dump [02:15] oh, right [02:15] it is safe [02:15] We could use that. === lifeless removes the anal plug [02:15] gnight all [02:16] that would also likely prevent people from giving us incomplete repos === herzi_x41 [n=herzi@pD9E29F97.dip.t-dialin.net] has joined #launchpad [02:16] so, yes, importing from svn dumps would be okay [02:17] can someone please delete the monkey-bubble product from launchpad? it was not created by the maintainers and the reported bug is supposed to be an ubuntu bug. [02:17] thank you [02:17] stub: ^^ [02:21] herzi_x41: people can't file new bugs on it now. === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [02:22] herzi_x41: previously it was possible to file new bugs on products that hadn't explicitly stated that they were using Malone, but that has since been fixed [02:23] Malone's front page should be inviting volunteers to clean up those old bugs, with a link to list them all [02:23] if there are too many for us to fix by hand [02:24] jamesh: thank you === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === looksaus [n=mark@86-39-97-101.customer.fulladsl.be] has joined #launchpad [02:48] hi, I'm part of a group that is developing some code for a LocoTeam [02:48] our project is registered in Launchpad [02:49] is there a canonical way to create a mailing list for these people? [02:49] (within the Canonical/Ubuntu Foundation infrastructure, that is) [02:50] I know we can probably ask for a @lists.ubuntu.com mailing list, but is that the right way? [02:58] looksaus: yes it is. [02:58] afaik LP doesn't provide any mailinglist services [02:58] lucasvo, thx for the help [02:59] now I only have to find out where to ask for this @lists.ubuntu.com list [02:59] shouldn't be too difficult === flacoste-lunch [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:08] mpt_, good idea. where's your patch? :) [03:10] oh, did I miss stub? [03:10] or is he travelling already? [03:14] kiko: good morning! [03:14] hello francis === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [03:15] I bet you are cross with me! [03:15] kiko, it's beyond me, but I did report a bug about it several months ago :-) [03:15] mpt_, scratch my head thinking why that would be beyond you! [03:16] argh, now Malone is going to be uncooperative in returning bugs that use "malone" in the summary === flacoste-lunch wonders what 'cross with me' means? [03:17] cross ~= angry [03:18] bug 33642 [03:18] Malone bug 33642 in malone "Weed out open non-bugwatch bugs on products/distros that don't use Malone" [Medium,Unconfirmed] http://launchpad.net/bugs/33642 [03:19] Similarly bug 39960 [03:19] Malone bug 39960 in malone "Weed out obsolete uses of bug watches" [Medium,Unconfirmed] http://launchpad.net/bugs/39960 === mpt_ goes back to sleep [03:21] kiko: me angry? not at all! why should I be angry? because I haven't yet received my reviews, c'mon, it takes more than that for me to lose my cool :-) [03:21] well, I've been horribly overburdeend [03:27] kiko: yeah, i know, plus that patch is big, do you know when you think you'll find time for it? [03:28] flacoste-lunch, no promises. I have it half-done in vi for two days now :-( [03:28] kiko: did you see I did a braindump spec for tag descriptions? [03:28] SteveA, so I did, I got emailed about it today [03:28] SteveA, or.. hmm did I. whats's the spec name? [03:29] https://launchpad.net/products/malone/+spec/tag-definition === imbrandon [n=brandon@ubuntu/member/pdpc.active.imbrandon] has joined #launchpad [03:32] BjornT pointed out an issue, which is we could have different tag definitions for the same tag in a single bug, where it has more than one target [03:32] I think that indicates a problem that one or both projects need to sort out out-of-band [03:33] so we should display both definitions in that case === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [04:00] https://launchpad.canonical.com/OneZeroPageLayout [04:01] please comment, folks, at the bottom [04:01] sabdfl, "the leader has not yet arrived. please stand by" [04:01] SteveA: i don't mind tag definitions, but it does not make sense to have them balkanised [04:02] SteveA, +1 to what sabdfl just said. [04:02] hmm... is it call time? [04:02] sabdfl, well, that's what SteveA pinged me about! [04:02] so it is [04:03] I don't understand what you mean. Maybe you can explain in the phone call === ddaa hacks around a nasty test order dependency in the cscvs test suite [04:04] W6 [04:04] eh, sorry [04:06] SteveA: kiko and i are on the call === niemeyer [n=niemeyer@200-140-230-218.ctame7043.dsl.brasiltelecom.net.br] has joined #launchpad === rpedro [n=rpedro@87-196-12-26.net.novis.pt] has joined #launchpad [05:38] BjornT: was it you that add the screenshots to MaloneHighlights? [05:38] that was mpt [05:38] well [05:38] bjorn and james came up with a list of URLs [05:39] and the mail screenshot [05:39] then mpt did the actual shooting and cropping [05:39] thanks mpt_ [05:39] i have a few tweaks, will ask him to update it [05:39] a little [05:40] does anyone else think that the bugtask header would be more readable if it was: [05:40] I should have used PillarName for the reporting-by-mail screenshot [05:40] upstream evolution-exchange [05:40] upstream libsoup [05:40] kiko is the one sending it along to the python guys [05:40] ubuntu evolution-exchange [05:40] debian evolution-sxchange [05:41] SteveA, or so I am supposed to [05:41] the (postfixed) thing is harder to read [05:41] mpt_: could I ask you to tweak those screenshots a little? [05:41] depends on which bit of the target name you consider important [05:41] they are very classy - thanks for that [05:41] sure, mail me the exact changes required === mpt_ really should be asleep :-) [05:42] the package/product name or the distro name/that it is an upstream === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [05:48] mpt_: well done. night :-) [05:48] mail sent === jamesh [n=james@203-59-20-109.dyn.iinet.net.au] has joined #launchpad === bradb & # lunch === herzi_x41 [n=herzi@pD9E29F97.dip.t-dialin.net] has left #launchpad [] [06:38] WHOA [06:39] https://dogfood.ubuntu.com/distros/ubuntu/dapper.0 [06:39] kiko: ^^^ not cool [06:40] sabdfl, yeah, clunky isn't it. === lbm [n=lbm@82.192.173.92] has joined #launchpad === Mr-Petah [n=Mr-Petah@unaffiliated/mrpetah/x-000001] has joined #launchpad [07:14] wow [07:14] hi all === JanC [n=janc@lugwv/member/JanC] has joined #launchpad [07:35] kiko~ [07:35] safllowperson says to ask you to extract information from the tables [07:44] BjornT: ping === abhay [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad [07:46] hi bradb === bradb msgs === shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #launchpad === shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has left #launchpad ["Leaving"] [08:27] kiko: ping [08:29] flacoste-lunch, ahooo [08:29] what's the flavor? [08:29] didn't mean to interrupt lunch [08:29] no interruption, i'm back ;-) [08:33] if I do foo.bar = UTC_NOW, do I have to reretrive "foo" before foo.bar will return a datetime value? (instead of returning the SQL of the SQLConstant UTC_NOW) [08:39] i have one question, any people from canary islands? [08:41] bradb, not sure -- jamesh would know though [08:42] I decided to just instantiate it as a datetime object instead === Mr-Petah esta Ausente, Razon: ( Volver... no s cuando, pero volver... xD | http://mrpetah.homelinux.net ) | Desde: ( Viernes, Ahosto 4, 2006. 16:45:48 ) Xlack v2.1 === scotth [n=scotth@157.182.209.170] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] [10:49] kiko: busy? [10:50] yes [10:50] kay. [10:50] terribly today === bluefoxicy comes up with something else to do for the moment. [10:50] hello bluefoxicy [10:50] Hi winedev guy === LarstiQ giggles [10:51] I haven't seen you in a coon's age, or whatever the term is === LarstiQ nods [10:51] had some shifts in priorities [10:53] I'm trying to get a job; meanwhile I've been spitting out random ideas, tracking what's going on in Ubuntu, generally trying to do whatever to keep from being bored. [10:55] I specced out a hardened team like the one in Gentoo for Ubuntu, just to amuse myself; nobody'd ever set something like that up, it's a battlefield. Also I took interest in pitti's automated crash reporter and came up with a way to keep the massive workload of sifting through reports in check; and am looking at isolating probable security vulnerabilities using the reports. === Myk0n [n=hydrus@81.20.248.70] has joined #launchpad [10:56] that does sound like you are keeping yourself busy [10:56] well if I don't, I get bored. then I talk in #-devel a lot, and the devs get pissed at me. === LarstiQ grins === scotth [n=scotth@157.182.209.170] has left #launchpad [] [10:59] LarstiQ: currently I need to catch one of these guys when they're not busy and bribe them to get a couple statistics out of the launchpad database for me ;) But it's not a priority [11:00] bluefoxicy: you could try mailing launchpad-users? [11:04] I think users don't have the kind of access I need. I basically need bug counts per month for Ubuntu, and possibly some other stuff (It would be interesting to also graph the number of bugs closed; number of duplicates; number of confirmed bugs; and number of newly triaged bugs) [11:05] But it's not that important, since it's just to illustrate a problem that's already known. [11:05] -users is a way to communicate with the devs that is less prone to being lost than a request on irc [11:05] ah [11:05] I suppose you could also try a support ticket on launchpad === LarstiQ never used that though === bluefoxicy is starting to not like mailing lists because he's on a billion of them. [11:06] bluefoxicy: how about figuring out if the support tracker works? :) [11:08] heh sure why not. [11:08]