[12:17] jelmer: whats the branch ? [12:17] https://launchpad.net/people/jelmer/+branch/samba/svn-4.0 [12:18] It has ~9000 revisions and was added on friday IIRC - launchpad doesn't seem to have problems with the wireshark branch which has 18000+ and has been added later [12:20] so I wanted to ask you [12:20] we have a discussion at the moment about 'bzr branch' and formats [12:20] I think that 'bzr branch' changing formats surprises users [12:20] and that the default behaviour should always be to preserve the control-dir format [12:21] i.e. format6 branches stay as format6, metadir stays as metadir, hg stays as hg, git stays as git [12:21] the branch looks ok to me, its mirrored correctly. [12:21] can you please file a bug on launchpad-bazaar about it ? [12:22] but svn can't really branch natively :) [12:22] lifeless: Sure [12:22] I think it indeed makes sense to keep the original format in the case of distributed systems [12:23] All the centralised systems should (imho) use the default bzr format [12:24] or perhaps, rather, all systems that can't easily build a full branch (all history locally) [12:24] s/full/heavyweight/ [12:25] What do you think should happen when making a checkout of a .hg branch? What format to use? [12:26] now *thats* a question :) [12:26] hg does not have a checkout facility itself [12:27] (heavyweight or lightewight at the moment) [12:27] so, I think it needs to convert by definition [12:27] (because commit is not natively implemented for hg - we use their pythno module to commit [12:28] hmm [12:29] So I guess the choice is between always converting foreign branches to a bzr format, or only converting them when the particular method (branch/lightweight checkout/heavyweight checkout) is not supported for the particular foreign branch format. [12:29] but in theory, we can build the same logic for hg using our implementation, and commit builder [12:30] and have a 'native commit' which would let us do the local commit, push, finalise sequence. *I guess*. I dont know their smart servers beahviour well enough to know if that would in fact honour our semantics [12:30] my concern is that conversion takes time [12:30] But what sort of .hg control dir would you create in the local dir? [12:30] a real one :) [12:30] lots of issues to figure out - how to tell .hg its bound etc etc etc [12:30] more reasons to convert on checkout [12:31] right [12:31] so there'll always be cases where conversion will be necessary ('bzr branch' on a SVN branch, etc) [12:32] right [12:32] hows your patch to the bzr-hg coming along btw ? [12:34] I haven't looked at it again yet - got distracted by some other projects [12:34] with a bit of luck, I'll resend a fixed version before the next weekend [12:34] cool [12:34] I am hoping we can reuse the inventory synthesis in bzr-git [12:36] ah, ok - I haven't looked at your git plugin yet [12:36] Have you tried it on the kernel yet? [12:36] they have very similar but not identical models [12:36] bzr vis on the kernel in git? no [12:36] I dont have a kernel tree in git format [12:37] it will be slow though - its a fork() roundtrip per revision access [12:37] that can be fixed by smarter implementation of the higher order methods like get_revision_graph to query for all the revision data and (shock, horror) cache it [12:38] There is no library or anything that can read parse gits control format? [12:38] the official interface is 'git' [12:38] as opposed to libgit. AFAICT there is no libgit even [12:39] Ouch [12:39] I wonder what the darcs folks use - apparently they have git support as well [12:39] dunno [12:39] probably they are doing 'conversion' not 'model and access' [12:40] (baz-import vs the hg/git/svn plugins) [12:40] conversion is always an easier proposition [12:40] in that you are expected to cache and stream and take a while [12:40] looks like they're actually able to use git repositories as if they were darcs branches [12:41] oh? I take it back then [12:41] they can commit to them ? [12:42] apparently - 'darcs record' is supposed to work [12:42] http://darcs.net/DarcsWiki/DarcsGit [12:45] get yourself a copy of Git (0.99 or later) and run make; this should build a libgit.a. [12:45] static library only [12:45] ahh [12:45] I guess you can always dlopen() a binary though [12:46] ;-) === jelmer wonders how well Pythons ctypes would work with binaries [12:47] holy fuck [12:47] git-core ships an entire copy of subprocess.py [12:48] probably because python 2.3 doesn't have subprocess [12:48] the right answer there is 'depend on python 2.4' ;) [12:49] theres no mention of it in the debian copyright file. :( [12:49] you're talking to a poor part-time Debian sid user who is still stuck with python2.3 [12:49] ;-) [12:49] at a minimum, the debian *package* should not ship like that === jelmer nods [12:52] https://launchpad.net/distros/ubuntu/+source/git-core/+bug/53827 [12:52] Malone bug 53827 in git-core "Please ship libgit.a" [Untriaged,Unconfirmed] [12:56] ah, guess that's probably a better idea than opening the git binary (-: [12:57] hmm.. when I get the time, I'll have a look at bzr-darcs - apparently it isn't hard to wrap haskell in python [12:58] well [12:58] I'd use pyrex and make a git.so plugin for bzr myself [12:58] no point thunking through haskell, when the darcs and bzr models are also not the same [12:59] oh, sorry, misread you [12:59] yes, bzr-darcs would be cute === mpt_ [n=mpt@203.118.156.188] has joined #launchpad [01:00] How well does pyrex work? Using SWIG really discouraged me to use binding generators unless I had to create bindings for more than 2 different languages [01:01] pyrex isn't a binding generator [01:01] have you read the readdir branch ? [01:02] ah, looking at the website made me remember. I was confusing it with some ctypes alternatives for Python [01:02] lifeless: Haven't looked at the code yet, no [01:03] lifeless: I'm keen to see it go in though.. running 'bzr status' on 5000-file branches very often now that I'm using bzr for my Samba work [01:18] Only git-core for Python2.3 in Debian.. :-/ [01:19] s/git-core/stgit/ [01:20] s/2.3/2.4/ [01:20] time to get some sleep, apparently.. 'night! === _mholthaus [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad === sevrin [n=sevrin@202.75.186.154] has joined #launchpad === mpt__ [n=mpt@203.118.156.188] has joined #launchpad === mdke_ [n=matt@unaffiliated/matt/x-000000001] has joined #launchpad === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #launchpad === Lord_Athur [n=alejandr@pc-10-33-214-201.cm.vtr.net] has joined #launchpad [06:21] hi all [06:22] how could i be sure that all my installed programs are in my language? can I do it? === mpt_ [n=mpt@203.118.156.188] has joined #launchpad [06:30] Gooooooooooooood afternoon Launchpadders! [06:32] I use kubuntu + edubuntu-desktop, but some sub-menus of the edubuntu programs are in English in the kde menu,How do I make an specification about it in order to show that the language of the menu application is the wrong one? [06:33] Lord_Athur, that seems like a bug, not a subject for a specification [06:33] ok, [06:33] so, how do i notify a bug? [06:34] It might be just that they're not translated yet [06:34] ok [06:34] What is an example of one of the programs? [06:35] I'm chilean(so my language is Spanish): [06:35] "entretenimientos educativos" :"languages":"kanagram(juego de .....". [06:35] in that example you can see a menu which is in English [06:36] ah, so "Languages" is in English but should be in Spanish [06:36] yes [06:36] and it could be difficult for young children know what to do in these situations [06:36] so, I'd like to report that bug or help or help to traslate it [06:38] ok, to start off I'd suggest reporting a bug here https://launchpad.net/distros/ubuntu/+filebug [06:39] Then someone will put the bug report into the correct package [06:39] Then if you want to, you can find the Rosetta translations for that package, and translate it yourself :-) [06:40] thanks mpt [06:49] mpt, in a part of the bug reports there are three optios for "asigned to". what may I choose? [06:49] I mean, do I put "Me"? [06:49] only assign to yourself if you'll be the one fixing the bug [06:49] generally just leave it as default [06:50] ok thanks [06:51] Thanks all, I leave now [06:51] bye === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [07:02] wtf.. launchpad still doesnt import my key :| [07:02] "HTTP Error 500: OK at http://keyserver.ubuntu.com:11371/pks/lookup?search=0x940BDA96&op=get" === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === mpt_ [n=mpt@203.118.156.188] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] 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 === mpt [n=mpt@203.118.156.188] has joined #launchpad === ChanServ [ChanServ@services.] has joined #launchpad === ChanServ [ChanServ@services.] has joined #launchpad === mdke_ is now known as mdke === ChanServ [ChanServ@services.] has joined #launchpad === ChanServ [ChanServ@services.] has joined #launchpad === mpt_ [n=mpt@203.118.156.188] has joined #launchpad === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [09:59] hey guys, where's the new push location? and has the copy from chinstrap been completed? === Spads [n=crack@217.205.109.249] has joined #launchpad === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] === mpt__ [n=mpt@203.118.156.188] has joined #launchpad === jamesh [n=james@82.109.136.100] has joined #launchpad [10:39] good morning [10:40] hi jamesh === tim-w [i=Tim@n219079028193.netvigator.com] has joined #launchpad === carlos [n=carlos@82.109.136.100] has joined #launchpad === doko_ [n=doko@dslb-088-073-088-037.pools.arcor-ip.net] has joined #launchpad === mdz [n=mdz@217.205.109.249] has joined #launchpad [10:57] morning === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [11:53] jamesh: you know what else would be good to randomise to break tests? os.listdir. [11:55] spiv: yes, it would :) === mpt_ [n=mpt@203.118.156.188] has joined #launchpad [11:56] jamesh: I just reviewed a doctest that I think is accidentally depending on ordering of os.listdir (via glob.glob), hence the thought :) [11:59] rotfl === lbm [n=lbm@0x50a1ee0c.unknown.tele.dk] has joined #launchpad === ddaa [n=ddaa@82.109.136.100] has joined #launchpad [12:04] ddaa: meeting time! === SteveA [n=steve@82.109.136.100] has joined #launchpad [12:12] spiv: hello [12:13] SteveA: Good evening. === lfittl [n=lfittl@85-125-227-78.dynamic.xdsl-line.inode.at] has joined #launchpad === spiv breathes a sign of relief after finishing the process-upload-tidy review. [12:29] Yeah, sorry about that one, I promise to keep my branches smaller going forward [12:31] Pah, I bet it wasn't as bad as the 'OMG, all of soyuz, WTF?!' branch we gave to jamesh [12:31] no more mega soyuz branches, please [12:31] :-) === Kinnison ruffles jamesh [12:31] I promise, I will never give you another mega branch === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad [12:53] reviewer meeting in 7 [01:01] reviewer meeting time [01:01] * Roll call [01:01] * Agenda [01:01] * Next meeting [01:01] * Queue status. [01:01] who art here ? [01:01] I art. [01:02] ok [01:02] me [01:02] cool [01:02] bjorn is on leave [01:02] next meeting: [01:03] 2006-07-31 at 1100 UTC. [01:03] ok? [01:03] ok [01:03] queue status [01:04] so [01:04] 2 at 5 days old [01:04] process-upload-tidy is reviewed as of nearly an hour ago. [01:04] spiv and spiv [01:04] cool [01:04] 1 at 5 [01:04] 1 at 4 [01:04] and 2 at 3 [01:04] this is all under control IMO [01:05] lots of stuff at one day [01:06] hi === SteveA reads scrollback [01:06] jamesh: is pending-reviews running ? [01:06] let me check [01:07] stale lock on the working repo === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [01:07] ah :) [01:08] also chinstrap's filesystem is mounted read only [01:08] righto [01:08] ok, any other business? any new tricks to watch out for ? [01:09] 4 [01:09] My inclination to move some tests from doctests to plain python is growing. [01:09] ok [01:10] can you write up your feelings on why? I suspect I'll agree :). [01:10] doctests actually harm readability for sufficiently complex code -- people don't ever seem to use inline comments, even when defining 20 line functions :) [01:10] lets have a discussion on the list ? [01:10] doc tests do seem to result in more test dependencies than would be nice [01:10] I'll write up my thoughts for the list. [01:11] and ok. [01:11] any other business ? [01:11] 4 [01:11] 3 [01:11] 2 [01:11] 1 [01:12] thanks for comingg === ddaa [n=ddaa@82.109.136.100] has joined #launchpad [01:12] spiv: happy to chat now about it, but didn't want to minute it :) [01:13] lifeless: Ok :) [01:14] The readability thing is funny, because that's the reverse effect to the typical doctest effect, where comments are easier to write than code. [01:14] But you almost never see a helper function in a doctest with a docstring explaining what it does or what args it should take, let alone comments inside them. [01:15] You do sometimes see big paragraphs before them that try to explain everything, and then the large code, where in plain python the comments would be one at a time, right next to the relevant line of code. [01:16] yah [01:16] Also, complex helper functions don't tend to fit neatly into a doctest narrative. [01:16] thats my biggest bugbear [01:16] narrative tests are great for showing people how to use an api [01:16] So they tend to get defined where they're needed, but are more general than that case would seem to need, because actually they're also used 100 lines further down [01:17] but beyond that I find it quickly becomes harder to grok that a tonne of focused tests [01:17] Whereas in a TestCase, you have an obvious and neat place for a helper: a method on the TestCase. [01:18] Anyway, I guess my concerns are: [01:19] * helper functions more than 3 lines long are almost always very ugly in doctests [01:20] * you get long, rambling tests with complex setup, rather than lots of focussed, specific, isolated tests (let alone *unit* tests) [01:20] yup [01:21] testing.txt is a good counter-example to my concerns. [01:21] It does lots of things, but the individual sections are independent and readable on their own, without 200 lines of context. [01:22] There are other niggles, e.g. I saw this today: [01:22] + >>> if process.returncode != 0: [01:22] + ... print stdout [01:22] + ... print stderr [01:22] + [01:22] right [01:22] Which ought to be just ">>> process.returncode\n0"... [01:23] ...but then you don't get the debugging you need. [01:23] people want unittest debugging because they are debugging things, not demonstrating the api [01:23] assertEqual(0, process.returncode, "failed, here's more info: %s" % ...) doesn't have that issue. [01:26] The doc/soyuz-*.txt tests I saw in a review today are what brought this on, if you're curious. === danilos [n=danilo@82.109.136.100] has joined #launchpad === gapz [n=gapz@84.6.180.20] has joined #launchpad [01:29] 'lo [01:32] spiv: just about any unit-as-doctest brings it on for me :) === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [01:33] morning bradb [01:34] hey jamesh === dsas [n=dean@host86-129-18-243.range86-129.btcentralplus.com] has joined #launchpad === _mholthaus [n=mholthau@johnny33.dersbach.ch] has left #launchpad ["Konversation] === marcin_ant [n=marcin@194.114.146.122] has joined #launchpad === bradb_ [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === mdz_ [n=mdz@217.205.109.249] has joined #launchpad === niemeyer [n=niemeyer@200.181.169.197] has joined #launchpad === frodon_ido [n=patrick@ip-213-49-150-10.dsl.scarlet.be] has joined #launchpad === dooglus [n=dooglus@rincevent.net] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad === jinty [n=jinty@213-156-52-99.fastres.net] has left #launchpad ["Leaving"] === danilos [n=danilo@82.109.136.100] has joined #launchpad === ddaa [n=ddaa@82.109.136.100] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === Trilla [i=Tim@n219079028193.netvigator.com] has joined #launchpad === JinTao [i=Tim@n219073008196.netvigator.com] has joined #launchpad [03:23] i'm trying to link a bug in ubuntu to a bug in debian, and i need a 'product' to go with the bug number and remote BTS - what is this 'product' it needs? [03:24] Is that the case? [03:25] Kamping_Kaiser: use the "also affects: distribution" link rather than "also affects: product" [03:25] oh ok, i'll have a shot, thanks [03:26] it says 'upstream', rahter then 'product', thats probably what caused the confusion [03:27] done, thanks jamesh [03:28] Kamping_Kaiser: I suppose it is a bit confusing since Debian is a little way upstream of ubuntu :) [03:28] :) === rpedro [n=rpedro@87-196-34-206.net.novis.pt] has joined #launchpad === JinTao is now known as tim-w === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === rpedro [n=rpedro@87-196-34-206.net.novis.pt] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad [04:30] i jsut had an oops - ID OOPS-205B211 [04:30] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/205B211 [04:30] o_0 [04:30] grrr. that was my good night rejection. [04:30] it'll wait. gl :) === bradb & # dentist (again) && lunch === kiko [n=kiko@200.181.93.60] has joined #launchpad [04:55] kiko: hi! [05:07] hey flacoste! [05:07] good to see you around [05:07] how was mallorca? [05:08] it was great [05:08] good work [05:08] just spent about 12h between airports though [05:08] got a chance to enjoy the mediterranean? [05:08] not really [05:09] kiko was a crazy cycling dude [05:09] 0wning the mountains [05:09] aha! I guess that's as good as the sea for some [05:10] well you have to understand [05:10] there was only from 6am to 8:30am to do anything but work [05:10] this is true [05:10] i am sure the sea was nice at 6:30 :-) [05:10] I have no real idea [05:10] jbailey saw the sea I hear [05:11] hey matsubara [05:11] I photographed it from a distance [05:11] it was blue [05:11] yo kiko [05:11] matsubara, nice work on the timeouts eh? [05:11] hey carlos, jordi, salgado [05:11] I was thinking [05:11] you know, now that KarmaContext has landed [05:12] it is actually possible to better track where a person did karma actions [05:12] which could in theory replace the query we do for +translations. [05:12] what do you guys think? [05:12] hey kiko [05:12] kiko: hey dude [05:13] kiko: yeah, I guess we could use it as a kind of cache for that page [05:13] carlos, we would just need to store the template the person was translating [05:13] right? [05:13] you mean, somehow store the bug/spec/whatever that the person created/changed/... ? [05:14] salgado, yes. what do you think of that? [05:14] kiko: we could get it from the context === carlos -> meeting with Steve [05:15] carlos, I don't think salgado stores the real "context" [05:15] let's talk later [05:15] he stores the "pillar" [05:15] sure. [05:15] salgado, does that sound possible,reasonable? [05:16] kiko: Indeed quite a decrease. there are some pages left to improve though. [05:16] it probably is possible, I think. but I don't see how the KarmaContext implementation helps on that front [05:16] matsubara, I'm thinking about +translations [05:16] salgado, well, in karmacontext you already give us some information related to the context, right? [05:17] yeah, the product or distribution [05:17] salgado, so, for instance, it'd be a matter of adding some extra info there. [05:17] salgado, sound.. possible? [05:17] https://launchpad.net/people/sabdfl/+translations [05:17] for instance [05:18] I'd need to store the actual pot translated. [05:18] err po-file [05:21] it should be doable, but I guess we'd need a few extra columns, each one being a foreign key to a different table, no? [05:24] salgado, I guess, yeah. kinda crummy but, well, we could do it just for translations for now. does that sound awful? [05:24] bradb, ping? [05:24] why only translations? [05:25] salgado, to stop +translations from timing out. [05:31] kiko: ok, I'm back [05:32] kiko: you are right, we only have the product or sourcepackage [05:32] kiko: but I guess that good enough to reduce the amount of time we need to calculate their contributions [05:32] carlos, so we'd need to add an extra column there, which would only be not null sometimes. what do you think? [05:32] SteveA, have an opinion? [05:32] kiko: hmm, let's try first without changing our database [05:32] carlos, how would you do that? [05:32] kiko: yes. chocolate is better than ice-cream [05:33] SteveA, I meant wrt using KarmaContext to track translations. [05:33] I haven't given it any particular thought. What's the problem it can solve or improve? [05:33] +translations timing out. see above. [05:33] kiko: use the same query we have now, but instead of joining all potemplates across all distributions/products, just join the ones that we actually know he worked on [05:34] carlos, I see. that's an interesting idea. [05:34] carlos, using an IN () subselect? [05:34] I guess, yes [05:35] kiko: I think we could try that and if it's fast enough we save some complexity in our database... [05:35] I guess. [05:35] if we do that there may be some contributions not showing up [05:35] salgado, why? [05:35] (not sure how big of a problem that is, though) [05:35] old ones you mean? [05:35] yes [05:35] salgado: we would be interested on latest contributions, say one month or so [05:35] salgado, well, we could also poison the database. :) [05:36] kiko: I don't see the connection between karma and +translate [05:36] or +translations [05:36] we'd use the karma as a cache, basically [05:36] is the idea that the context-specific karma stuff acts as a log [05:36] of the translations that you have done [05:37] and so you can rely on that log to display the translations you did === kalosaurusrex [n=aaron@dhcp59190.vcd.hp.com] has joined #launchpad [05:40] SteveA, exactly. [05:42] hey guys! does launchpad have the ability to run support reports of some sort? === Seveaz [n=seveas@ubuntu/member/seveas] has joined #launchpad [05:44] kalosaurusrex: what do you have in mind exactly? [05:44] kiko: I think it makes sense to do that. I can think of four ways to reasonably achieve it, and two that are actually worth considering. [05:44] SteveA, rock and roll [05:45] kiko: 1: add a bunch of extra columns to the karma table to link a karma record to other entities. but even then, the meaning of the link depends on the type of karma [05:45] 2: keep the karma table simple, without links. add a new "karma translations" table for the extra info. [05:45] yes, correct. [05:46] SteveA, carlos suggested 3: framing the query for translations into translations that we know the user has actually done (via karma) [05:46] salgado, does karmacontext store the source package? [05:46] yes [05:46] cool [05:51] flacoste: well it would be nice to be able to get a report on date issues is open and closed, and be able to get some stats on that. as well as if there was an option to add more fields and could get reports on those it would be useful. like operating system support reports, and some specific stuff that would be useful to me (what printer, etc.) [05:53] kalosaurusrex: that's an interesting idea, currently Launchpad doesn't have much in terms of reporting [05:54] kalosaurusrex: the date open/closed report would be possible to implement [05:54] kalosaurusrex: but the other stuff (by operating system, printer, etc.) would be more problematic since we don't track that stuff now [05:57] flacoste: I gotcha. well perhaps sometime in the future. but open/closed would be cool :) [05:58] kalosaurusrex: can you add a bug report to https://launchpad.net/products/launchpad-support-tracker about that? [06:02] SteveA: do you still plan to do some adapter refactoring this week? === flacoste had an item on his agenda to ping you about that today [06:04] flacoste: sure thanks! [06:04] flacoste: that would be next week, when I'm not sprinting [06:05] kiko: if we start using the Karma table as an person's activity log as well as for the Karmic implications of that, we should rename it Activity, and use Activity to calculate Karma. [06:05] why not? [06:05] SteveA: i thought that it was next week you were sprinting, no problem, I'll ping you again next week :-) [06:05] kiko: why not what? [06:06] rename it to activity. :) [06:07] I don't understand what you're asking [06:07] I'm agreeing with you [06:07] why not? [06:07] ;-) === SteveA goes to talk bzr with the bzr lp team [06:08] heh [06:16] flacoste: https://launchpad.net/products/launchpad-support-tracker/+bug/53913 [06:16] Malone bug 53913 in launchpad-support-tracker "[support tickets] reporting functionality" [Untriaged,Unconfirmed] [06:16] hope it makes sense. not enough coffee yet. [06:17] kalosaurusrex: thanks! [06:17] flacoste: thanks for your time as well! === LaserJock [n=mantha@ubuntu/member/laserjock] has joined #launchpad === ddaa [n=ddaa@82.109.136.100] has joined #launchpad [06:35] bradb: around? === kalosaurusrex [n=aaron@dhcp59190.vcd.hp.com] has left #launchpad [] === Lord_Athur [n=alejandr@pc-10-33-214-201.cm.vtr.net] has joined #launchpad === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === Lord_Athur [n=alejandr@pc-10-33-214-201.cm.vtr.net] has joined #launchpad [07:10] hi everyone [07:10] I've asked many times about what karma is, but [07:11] why do I have many actions in karma, but 0 as number? It doesnt make me be clear about karma :S [07:13] Lord_Athur: in launchpad karma is aged: after one year it is worth 0 [07:14] Lord_Athur: somebody did a camparison of Launchpad karma with other system: http://alligevel.blogspot.com/2006/07/karma-in-launchpad.html [07:15] :(, I've understood that karma is gaven by the actions you do in ubuntu/launchpad, am I wrong? [07:15] Lord_Athur: not, this is true, it's just that karma ages so last years action aren't worth anything anymore [07:16] Lord_Athur: you need to keep active, or your karma will drop to zero. [07:17] Lord_Athur: otherwise newcomers will be hopelessly behind, not very motivating. [07:17] I'm not sure if *all* actions give karma either, but I could be wrong [07:17] lamont, you're right [07:19] LaserJock, look at this page https://launchpad.net/people/alejandro-leonvega/+karma I've actions that are considered for karma, but no karma. [07:20] Lord_Athur: that is because you all did it today [07:20] Lord_Athur: afaik, karma is updated once per day [07:20] Lord_Athur: dude, it takes a while :-) [07:22] Hahaha, thanks all, I did some things last night in rosetta, but I don't remember in what time exactly, maybe it was this morning. [07:22] :P [07:25] thanks launchpad people, see u later === bradb gets back from 2.5 hours in a dentist's chair [07:40] eek! [07:40] bradb: you seem to still be alive? [07:40] right now, anything i say comes out "balaaahhallblllaaahhablllab" [07:41] LarstiQ: fvdo "alive" === LarstiQ always finds ircing in such situations comforting [07:41] and i'll be back tomorrow morning for more [07:41] why? [07:41] 2 more fillings [07:42] today was Tooth Reconstruction Day [07:43] kiko: pong [07:43] bradb: good luck [07:43] thanks [07:49] kiko: replied to your comments about the SF import === Lord_Athur [n=alejandr@pc-10-33-214-201.cm.vtr.net] has joined #launchpad [07:57] hi [08:07] can I change the e-mail which I use for logging in in launchpad? [08:09] Lord_Athur: yes, change the prefered email address [08:11] Lord_Athur: You should be able to login with any email address you've registered with Launchpad, preferredemail or not. [08:12] yes bradb, but can I change the e-mail address used at the moment of the registration in launchpad? === glatzor [n=sebi@ppp-82-135-76-240.dynamic.mnet-online.de] has joined #launchpad [08:15] thanks all, I solved it === jamesh [n=james@82.109.136.100] has joined #launchpad === SteveA [n=steve@82.109.136.100] has joined #launchpad === ddaa [n=ddaa@82.109.136.100] has joined #launchpad === carlos [n=carlos@82.109.136.100] has joined #launchpad === danilos [n=danilo@82.109.136.100] has joined #launchpad === Nocta [n=amy_byrd@adsl-70-142-43-190.dsl.tul2ok.sbcglobal.net] has joined #launchpad === Spads [n=crack@host-87-74-89-130.bulldogdsl.com] has joined #launchpad [08:37] lifeless: please see email addressed to you, cc launchpad list "moving from chinstrap to sodium" when you're around tomorrow. === carlos [n=carlos@82.109.136.100] has joined #launchpad === panickedthumb_wo [n=tnewman@204.119.250.19] has joined #launchpad [08:45] James Henstridge suggested I post this here [08:45] https://launchpad.net/bugs/53678 [08:45] Malone bug 53678 in launchpad "defunct account" [Untriaged,Unconfirmed] [08:46]