[12:42] <ddaa> yay, got the new svn changeset expression logic to actually do something useful
[12:42] <ddaa> namely, single file additions...
[12:43] <ddaa> lifeless: it's funny how code refactoring and TDD sometimes leads you to absurdly overcomplicated intermediate states
[12:44] <ddaa> When you have all the old logic in place, and the skeletal new logic hooked into the old code for some trivial case.
[03:30] <Ubugtu> New bug: #63668 in launchpad "No explanation for "Auto Tested"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63668
[03:53] <jamesh> lifeless: any chance of getting the bzr-0.11 branches merged for launchpad, cscvs and bzr?
[04:09] <mpt> Gooooooooooooooood afternoon Launchpadders!
[04:22] <mpt> jamesh, ping
[04:22] <jamesh> mpt: pong
[04:24] <mpt> jamesh, did you revert the description of bug 63106, or was that a glitch in the matrix?
[04:24] <Ubugtu> Malone bug 63106 in launchpad "https://launchpad.net/products/+new ignores "Programming Language"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63106
[04:24] <jamesh> mpt: I reverted it because it was misleading
[04:25] <mpt> Misleading?
[04:25] <jamesh> mpt: the bug is about the form ignoring the "programming language" field (so it doesn't get set on the resulting product)
[04:26] <mpt> right
[04:26] <mpt> So there are two ways to fix that
[04:26] <mpt> (1) make the form pay attention
[04:26] <mpt> (2) remove the field
[04:26] <jamesh> when I say that the code used to create the product doesn't use the programming language field, I mean that the field input is not used in the createProduct() call (so is ignored)
[04:27] <jamesh> your addition was about the programming language attribute on products not being used for anything once the product has been created
[04:27] <mpt> and which is appropriate depends on what it would be used for
[04:28] <mpt> Do you think (1) or (2) is most likely? Or something else?
[04:29] <jamesh> (1) is what the rest of the initial comment was about -- the field is included on the product edit form, and does cause the product to get updated there.
[04:29] <mpt> oh, I see
[04:29] <mpt> So it does work somewhere, just not in the add form
[04:29] <jamesh> it just looks like data loss at the moment, since everything else I enter on the +newproduct form appears as I typed it on the +edit form
[04:30] <mpt> ok
[04:30] <mpt> "it doesn't look like the programming language field is used at all" was a bit vague
[04:30] <mpt> but, sorry for misinterpreting it.
[04:30] <jamesh> no problem.
[04:31] <jamesh> it is easier to record these sorts of conversations in bug comments rather than description edits though :)
[04:34] <mpt> perhaps
[04:35] <mpt> though I think it will be useful for bug report descriptions to acquire sentences of the form "This is not about X, because Y."
[04:35] <jamesh> yep.  That is good in addition to a conversation.
[04:47] <jamesh> mpt: btw, I put up a branch to collapse all the registered SourceForge.net trackers into a single entry, which should simplify things a bit
[04:58] <mpt> That's excellent
[06:59] <lifeless> jamesh: yeah, should be able to ;)
[07:09] <jamesh> lifeless: thanks.  I guess we can do bzr-0.11 now rather than 0.11rc2
[07:53] <stub> lifeless: What would be involved in setting up a launchpad branch that merges changes to launchpad/devel automatically that a) Don't contain new files in the form database/schema/patch-*.sql and b) Don't cause conflicts ?
[07:54] <stub> and c) Passes the test suite
[07:59] <lifeless> stub: write a make target that does it then its easy to hook into pqm
[07:59] <lifeless> and having hooked it into pqm, we can do a cron job to do it
[08:00] <stub> lifeless: But how do I write a make target that detects if files are newly added or not. Use bzr status | grep | wc ?
[08:00] <lifeless> the target can use bzr status / bzr inventory/bzr diff / bzr status database etc to check file status
[08:00] <stub> cool
[08:00] <lifeless> i.e. bzr status database/schema should -> empty output in this scenario
[08:00] <stub> Does pqm automatically reject a merge with conflicts?
[08:00] <lifeless> we're not worried about abuse, we're worried about honest mistakes
[08:00] <lifeless> and yes, pqm says fuckoff to conflict containing requests
[08:01] <stub> ok.
[08:01] <SteveA> morning
[08:02] <lifeless> stub: so whats the branch for ? (bbs)
[08:02] <stub> morning
[08:02] <stub> lifeless: edge.launchpad.net - (almost) HEAD code running against the production database
[08:05] <stub> Ideally, I would want to cherry pick each launchpad/devel commit onto that branch if the above conditions are met.
[08:06] <stub> So if patches A, B, and C land, and B has a database change, then A and C are the only ones merged to launchpad/edge assuming the tests still pass for each of them.
[08:06] <stub> But the current plan just says stop updating edge.launchpad.net as soon as someone lands a new database patch.
[08:08] <stub> After every production rollout, we would need to sync up the launchpad/edge branch with reality though, reverting it to launchpad/production/x.xx and reapplying any outstanding patches or something like that if we did the cherry pick approach.
[08:29] <carlos_> morning
[08:38] <lifeless> stub: yup, no problems with all of thata
[09:25] <jordi> hey
[09:26] <jamesh> stub: could you have a quick look over the SQL in https://devpad.canonical.com/~jamesh/pending-reviews/jamesh/launchpad/bug-61590/full-diff ?
[09:26] <stub> db patch review, or after comments or something?
[09:27] <jamesh> stub: it isn't a db patch due to it not changing any schema, but BjornT suggested you might want to look at it
[09:27] <jamesh> it is a bit of SQL to consolidate all the SourceForge type bugtrackers into a single one
[09:28] <BjornT> stub: it's mostly because i remember you complaining about a sql script that wasn't reviewed some time ago. thought it wouldn't hurt to ask you to take a quick look at it.
[09:28] <stub> jamesh: looks fine. Make sure running that script is noted on LaunchpadProductionStatus when it lands
[09:28] <jamesh> stub: thanks.  I'll make sure to add it.
[09:30] <lifeless> ok, pqm going down
[09:30] <Ubug2> New bug: #63699 in rosetta "translation templates in focus-sis don't contain any items" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63699
[09:31] <jamesh> lifeless: with the bzr update, I don't think we need the bzrlib/plugins/bzrtools symlink anymore
[09:31] <lifeless> jamesh: so whats are the branches I need ?
[09:32] <jamesh> lifeless: jamesh/launchpad/bzr-0.11-support and jamesh/cscvs/bzr-0.11-support and a merge from bzr
[09:32] <jordi> SteveA: nope, wasn't around anymore.
[09:36] <lifeless> _thumper_: you are pqm enabled
[09:41] <_thumper_> lifeless: cheers
[09:47] <sivang> morning
[09:51] <Ubug2> New bug: #63344 in language-pack-pl "[update-manager]  wrong translation crashes application" [Medium,Needs info]  http://launchpad.net/bugs/63344
[09:52] <jamesh> I wonder why ubugtu occasionally sends notifications like this to this channel?
[10:15] <jordi> jamesh: maybe "rosetta related"?
[10:16] <jordi> but they shouldn't be here
[10:28] <SteveA> jamesh: ping
[10:29] <jamesh> SteveA: pong
[10:31] <jordi> carlos: can you add the kyrgyz team to Ubuntu translators?
[10:32] <carlos> sure
[10:33] <carlos> jordi: done
[10:34] <SteveA> jamesh: is your wiki page on using repositories up to date wrt how you use repositories with developing launchpad?
[10:34] <jordi> carlos: great
[10:37] <jamesh> SteveA: mostly.  These days I've been using checkouts for the branches under sourcecode/
[10:37] <jamesh> with a script to create them or update them
[10:38] <SteveA> jamesh: would you take _thumper_ through how to do an effective setup for working with launchpad branches?
[10:38] <jamesh> also the branch of bzr-pqm it says to use is wrong (since we're using new bzr now)
[10:38] <jamesh> okay
[10:39] <jamesh> _thumper_: where are you up to so far?
[10:39] <_thumper_> I am exploding a tarball from SteveA
[10:39] <_thumper_> which is rocketfuel-built from yesterday
[10:39] <SteveA> jamesh: I talked with martin about getting the bzr-pqm packaged for us
[10:39] <SteveA> we should be using packages
[10:40] <jamesh> _thumper_: okay.  Do you have your devpad account yet?
[10:41] <_thumper_> yep
[10:42] <_thumper_> the tarball contains rocketfuel-built/launchpad with a lot of files
[10:43] <jamesh> _thumper_: first thing first, do you have bzr-0.11 and bzr-pqm installed?
[10:44] <_thumper_> I have bzr 0.10.0
[10:44] <_thumper_> I don't know about bzr-pqm
[10:44] <jamesh> that's good enough
[10:45] <_thumper_> is bzr-pqm packaged?
[10:45] <jamesh> not at the moment
[10:45] <_thumper_> should I grab bzrtools?
[10:46] <jamesh> you can grab it with the following command: mkdir -f ~/.bazaar/plugins && bzr branch http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel ~/.bazaar/plugins/bzr-pqm
[10:46] <jamesh> _thumper_: yeah.  Install the bzrtools package
[10:47] <jamesh> The above command will install a plugin locally that gives you a "bzr pqm-submit" command
[10:48] <_thumper_> ok
[10:48] <_thumper_> did the branch
[10:49] <_thumper_> would be easier if I was running irc on my laptop :)
[10:49] <jamesh> you can ensure that it worked by running "bzr pqm-submit --help"
[10:49] <jamesh> which should print a short usage message
[10:49] <_thumper_> yep, got that
[10:49] <jamesh> if you'd prefer to switch over to your laptop, I can wait
[10:49] <_thumper_> depends, is there going to be more copy and paste?
[10:50] <_thumper_> it is handy working with two screens
[10:50] <jamesh> a bit.  Some bits from this page: https://launchpad.canonical.com/WorkingWithSharedRepositories
[10:50] <_thumper_> I have that up on the laptop
[10:51] <jamesh> okay.  Lets get on to setting up the local repo.  You should follow the commands listed in the "Creating The Repositories" section
[10:51] <jamesh> although you'll probably only need to create a repo for launchpad at the moment
[10:52] <_thumper_> yep, done that
[10:52] <jamesh> have you branched rocketfuel into that repo?
[10:52] <_thumper_> no
[10:52] <_thumper_> I have a tarball from SteveA that I have exploded locally
[10:52] <_thumper_> what do I need to marry the two?
[10:53] <jamesh> _thumper_: okay.  I have the rocketfuel-built/launchpad directory unpacked locally as ~/src/rocketfuel-built
[10:53] <jamesh> so if you do the following command, it will install the main launchpad history into your repo:
[10:53] <jamesh> cd ~/repo/canonical/launchpad
[10:53] <jamesh> bzr branch ~/src/rocketfuel-built rocketfuel
[10:54] <jamesh> that will take a while, but will make things quicker later on
[10:54] <_thumper_> I'll move mine to the same location as yours
[10:54] <_thumper_> to avoid confusion later
[10:55] <jamesh> we'll also want to set up a similar repo on devpad.canonical.com
[10:55] <jamesh> this will reduce the amount of stuff that needs to get pushed on the initial rsync
[10:56] <_thumper_> ok, the branch command is running
[10:57] <_thumper_> ok, I'm in devpad too
[10:57] <jamesh> _thumper_: on devpad, you'll be putting your branches under /home/warthogs/archives/$USER
[10:57] <jamesh> _thumper_: so after ssh'ing in, run the following commands:
[10:58] <jamesh> cd /home/warthogs/archives
[10:58] <jamesh> mkdir tim
[10:58] <jamesh> cd tim
[10:58] <jamesh> bzr init-repo launchpad
[10:58] <jamesh> cd launchpad
[10:58] <_thumper_> done so far
[10:58] <jamesh> bzr branch ../../rocketfuel/launchpad/devel rocketfuel
[10:59] <_thumper_> jamesh: fetch pahse 0/4
[10:59] <_thumper_> s/ah/ha/
[11:00] <_thumper_> I take it this takes a while :)
[11:00] <jamesh> yep.  There are a lot of history to copy
[11:00] <jamesh> s/are/is/
[11:01] <_thumper_> all done, both locally and devpad
[11:01] <jamesh> okay.
[11:01] <jamesh> what are you going to be working on first?
[11:01] <_thumper_> no idea
[11:01] <_thumper_> probably find out at 10UTC
[11:02] <jamesh> _thumper_: at various times, you'll probably want to make trivial changes that don't need to go through review
[11:02] <_thumper_> jamesh: right
[11:02] <jamesh> _thumper_: keeping a branch around for these sort of changes can be useful, so we'll set that up
[11:02] <_thumper_> jamesh: ok
[11:03] <jamesh> _thumper_: so locally, we'll create the branch:
[11:03] <jamesh> cd ~/repo/canonical/launchpad
[11:03] <jamesh> bzr branch ~/src/rocketfuel-built trivial
[11:03] <jamesh> this command should be very quick because all the history needed by the branch is present in the repo already
[11:03] <_thumper_> yep
[11:03] <_thumper_> it was
[11:04] <jamesh> we'll create a working tree for this branch under ~/src/lp
[11:04] <jamesh> mkdir -p ~/src/lp
[11:04] <jamesh> cd ~/src/lp
[11:04] <_thumper_> what's the point of that?
[11:05] <jamesh> bzr checkout --lightweight ~/repo/canonical/launchpad/trivial
[11:05] <jamesh> _thumper_: if you look in ~/repo/canonical/launchpad/trivial, you'll notice that there are no source files for you to edit: only a .bzr directory containing revision control info
[11:06] <jamesh> _thumper_: in contrast, the lightweight checkout only contains source files with a pointer to the branch in your repo
[11:06] <_thumper_> jamesh: ah, I see
[11:06] <jamesh> if you've committed all your changes on a branch, you can delete the checkout to save disk space without losing the branch
[11:07] <_thumper_> ok
[11:07] <jamesh> (the branch taking up around 300k rather than a few hundred megabytes)
[11:07] <_thumper_> ~/src/lp/trivial now has 42M of stuff
[11:07] <LarstiQ> that's due to the real data being in the repository storage though.
[11:08] <LarstiQ> but at least you only pay that price once
[11:08] <jamesh> okay.  Next you'll need to set up the branches under sourcecode/
[11:08] <_thumper_> ok
[11:08] <jamesh> I'll grab the script I use to create/update them
[11:10] <jamesh> _thumper_: https://devpad.canonical.com/~andrew/paste/fileeNDO29.html <- you'll want to change my email address to yours
[11:10] <jamesh> put it in ~/bin, or somewhere else on the path
[11:11] <_thumper_> jamesh: what do you call it?
[11:11] <jamesh> _thumper_: I called it setup-lp-sourcecode-dir
[11:13] <jamesh> If you run it while in ~/src/lp/trivial, it will fill out the branches under sourcecode/ with checkouts of the rocketfuel-built directories
[11:13] <lifeless> jamesh: you dont use config-manager ?
[11:13] <jamesh> it will also add a small bit of ZCML to make sure you don't spam other people when testing things
[11:14] <jamesh> lifeless: no.  I've just been doing things by hand.
[11:14] <_thumper_> jamesh: running now
[11:15] <jamesh> _thumper_: next thing: have your set up postgres according to https://launchpad.canonical.com/DatabaseSetup ?
[11:15] <_thumper_> not yet
[11:17] <_thumper_> database setup next?
[11:17] <jamesh> _thumper_: those instructions are pretty easy to follow.  A few notes: setting log_statement='all' will generate a lot of log data so you may not want to turn that on, and you should definitely set fsync=off since it'll decrease the time tests take to run
[11:18] <jamesh> _thumper_: for step (9), $your_launchpad_checkout will be ~/src/lp/trivial
[11:20] <_thumper_> jamesh: I'll run through that now
[11:21] <jamesh> There is also a bit of local apache setup to do, but it isn't on the wiki.  I'll find the details for that
[11:25] <_thumper_> does the launchpad-database-setup script currently do the right thing?
[11:27] <jamesh> no idea
[11:28] <_thumper_> damn, almost worked
[11:29] <jamesh> morning ddaa
[11:29] <ddaa> that much for hacking till midnight yesterday
[11:30] <ddaa> SteveA: spiv: jamesh: _thumper_: meeting in 30 mins
[11:30] <SteveA> ok
[11:30] <_thumper_> ok
[11:30] <cprov> good morning
[11:36] <jamesh> _thumper_: how are you going so far?
[11:43] <_thumper_> jamesh: just getting rid of 4 computers
[11:43] <_thumper_> the patch in the script for postgresql.conf hit a problem
[11:43] <_thumper_> so edited manually
[11:44] <jamesh> I just followed the instructions on the wiki page when setting up my new laptop earlier this year
[11:45] <_thumper_> might have been easier
[11:45] <_thumper_> now it won't start
[11:50] <jamesh> check the syslog or /var/log/postgresql/postgresql-8.1-main.log
[11:50] <carlos> danilos: ping
[11:50] <danilos> carlos: pong
[11:50] <_thumper_> it is the certs that it can't find
[11:50] <_thumper_> the script makes sym links but not described on the wiki
[11:50] <_thumper_> so deleting symlinks
[11:55] <_thumper_> I don't seem to have /etc/postgresql-common/postgresql.crt and .pem
[11:57] <jamesh> _thumper_: I didn't have to do anything with certs when setting up the db
[11:58] <_thumper_> jamesh: damn, now to find out why mine complains
[11:59] <stub> Do you have postgresql-contrib installed?
[11:59] <_thumper_> nope
[11:59] <_thumper_> but I do have postgresql-contrib-8.1
[12:00] <stub> Setting ssl=false in the postgresql.conf file should fix it, but not having the postgresql.crt indicates a slightly different environment to us.. hmm...
[12:01] <jamesh> I'd have thought it'd get created when installing the package
[12:02] <stub> _thumper_: Do you have openssl installed? 
[12:02] <_thumper_> must have, can ssh
[12:02] <stub> Is there an openssl command line tool?
[12:03] <_thumper_> yep
[12:03] <stub> ie. what the postgresql package installer would have used to generate that certificate
[12:03] <stub> pitti might know more
[12:03] <stub> Or just set ssl=false and not worry about the cert
[12:04] <_thumper_> I'll try that to get things going
[12:05] <_thumper_> stub: ssl=false got it started
[12:07] <jamesh> _thumper_: next you will need to set up apache so that you can access http://launchpad.dev locally for testing
[12:07] <_thumper_> jamesh: still need to create user and run schema script
[12:07] <jamesh> _thumper_: https://lists.ubuntu.com/mailman/private/launchpad/2006-June/009808.html contains most of the instructions, but use "features.launchpad.dev" where it says "blueprint.launchpad.dev"
[12:08] <sivang> jamesh: there's also Kinnison's hack which releives you from having to use apache
[12:09] <sivang> (in order to do the virtual hosts dance)
[12:31] <lifeless> pqm is back
[01:03] <ddaa> jamesh: duh!
[01:03] <ddaa> bad fix in cscvs
[01:03] <ddaa> the test case really means it
[01:03] <ddaa> the  branch nick must not be set by cscvs
[01:03] <ddaa> because it has nothing meaningful to set it to
[01:07] <ddaa> if a branch nick is _required_, it should be something like "Launchpad import"
[01:08] <jamesh> ddaa: Looks like it started getting set when I switched it over to WorkingTree.commit()
[01:08] <ddaa> jamesh: was that part of the bzr-0.11 compatibility work?
[01:09] <jamesh> I made the change during that work, but it looks like it wasn't necessary
[01:10] <jamesh> and the WorkingTree.commit() in 0.11 does less than the version in older bzr, so using the Commit() object directly should be less bad
[01:10] <ddaa> I'd be glad if you could fix it soon, so I would not have to pay attention when rolling out importd next time
[01:11] <jamesh> done
[01:15] <jamesh> it is pushed
[01:17] <ddaa> Looked at it, it's fine.
[01:17] <ddaa> lifeless: land at your leisure :)
[01:18] <ddaa> jamesh: thanks a lot
[01:23] <lifeless> jamesh: don't use WorkingTree.commit for cscvs
[01:23] <jamesh> lifeless: it isn't anymore.
[01:23] <lifeless> jamesh: its the wrong policy layer
[01:23] <jamesh> (in my branch)
[01:41] <ddaa> what is staging status, when will it get the latest code to run?
[01:43] <carlos> ddaa: I think you should ask bradb
[01:57] <stub> ddaa: Staging is still running bradb's branch. If that is a problem we need to work out what to do with brad
[02:06] <ddaa> stub: no problem, I just made a cherrypick request
[02:08] <ddaa> I trust that jamesh got it right, anyway it's difficult to get that feature wrong with the implementation strategy he used, and as long as the code matches the commit message
[02:08] <ddaa> stub: if you could make that cherrypick soon, that would make some bzr folks quite happy
[02:08] <stub> ok
[02:08] <stub> timing was good - I'm currently waiting on pqm so I can test the current batch.
[02:09] <ddaa> that's great, it will be possible to do "bzr get https://launchpad.net/bzr/trunk bzr.dev" and have it just work!
[02:10] <ddaa> maybe, even bzr get https://launchpad.net/bzr, actually
[02:11] <ddaa> will make communication around bzr branches in launchpad much easier
[02:29] <AlinuxOS> hello launchpadders ;)
[02:30] <AlinuxOS> I would like to ask, is it possible to visualise more then 10 strings on rosetta ? maybe 50 or more ? Can I setup that ?
[02:38] <AlinuxOS> salgado, hi
[02:39] <AlinuxOS>  is it possible to visualise more then 10 strings on rosetta ? maybe 50 or more ? Can I setup that ?(maybe you know...)
[02:41] <salgado> hi AlinuxOS.  what's the page where you're seeing them?
[02:41] <AlinuxOS> https://launchpad.net/distros/ubuntu/edgy/+source/debian-installer/+pots/debian-installer/ka/+translate
[02:41] <AlinuxOS> for example debian-installer
[02:42] <AlinuxOS> increase from 10 to 50 for example...
[02:42] <AlinuxOS> salgado, maybe it's not implemented yet.
[02:45] <salgado> AlinuxOS, that should be possible; I just need to find out how
[02:45] <salgado> here we go... just add an "?batch=50" at the end of the URL. (e.g https://launchpad.net/distros/ubuntu/edgy/+source/debian-installer/+pots/debian-installer/ka/+translate?batch=50)
[02:45] <AlinuxOS> salgado, ok... (it's just some users request....)
[02:45] <AlinuxOS> salgado, mmm
[02:47] <AlinuxOS> salgado, and to have that everytime ? :)
[02:48] <AlinuxOS> I understand you but...translators are poor mortals :) (me too)
[02:48] <AlinuxOS> It's quite tricky...
[02:48] <salgado> it's not yet possible to have this without hacking the URL
[02:48] <AlinuxOS> salgado, ok :)
[02:49] <AlinuxOS> I hope it's will implemented with a common button ;)
[02:49] <AlinuxOS> Thank You!
[02:58] <salgado> spiv, around?
[03:05] <braverock> ddaa: (or anyone else) can you help debug an import failure on registering a sourceforge cvs repository with bazaar?
[03:05] <braverock> https://launchpad.net/products/xrms/trunk
[03:06] <braverock> Import status: Test Failed doesn't give any useful feedback to help me fix the problem
[03:07] <braverock> https://launchpad.net/products/bzr-register/+ticket/1936
[03:08] <ddaa> braverock: look at https://help.launchpad.net/VcsImportRequests
[03:08] <ddaa> I have written down the status of xrms
[03:09] <ddaa> it looks like the default branch setting of of xrms/include/adobd/pear/readme.Auth.txt confuses our import tool
[03:09] <ddaa> maybe other files have the same problem
[03:09] <kiko> matsubara, did we cherry-pick request bug 59975?
[03:09] <Ubugtu> Malone bug 59975 in malone "Edit bug tag form needs to cope with invalid values in tag field." [High,Fix committed]  http://launchpad.net/bugs/59975
[03:09] <ddaa> braverock: I do not think that bug is going to have any attention soon, we are focusing of svn support now
[03:10] <braverock> ok, well did I do something wrong, or is this a bazaar bug?
[03:10] <matsubara> kiko: nope, it's not on the list.
[03:10] <braverock> I believe that the repository root is correct
[03:11] <ddaa> neither
[03:11] <kiko> matsubara, why don t we?
[03:11] <ddaa> it's a bug in cscvs
[03:11] <ddaa> the tool we use to magically create changesets out of CVS repository, and apply them
[03:12] <braverock> ok.  can I change anything on the " the default branch setting of of xrms/include/adobd/pear/readme.Auth.txt" to unconfuse your tool?
[03:12] <ddaa> braverock: if you have write access to the cvs repo, you could fix it so no file in has a default branch set
[03:12] <braverock> and could you consider maybe adding a link to the full import report to the "import Failed" error?
[03:12] <ddaa> we do plan to do that
[03:13] <ddaa> the wiki page is a stopgap measure
[03:13] <ddaa> I maintain manually.
[03:13] <matsubara> kiko: just added to the list
[03:13] <braverock> I don't think we've set branches on anything, but I'll check
[03:14] <kiko> matsubara, +++
[03:15] <braverock> someone else registered xrms in launchpad, and then abandoned it.  I picked it up, and hoped to get it in, because broader exposure on ubuntu would be good for xrms (even though xrms is already a very popular project)
[03:15] <ddaa> braverock: when you do "cvs -d :pserver:anonymous@xrms.cvs.sourceforge.net:/cvsroot/xrms/ rlog xrms/include/adodb/pear/readme.Auth.txt you should see a "branch" line in the heading (before individual revisions), it's that setting that is causing us trouble
[03:15] <ddaa> I do not know cvs very much, so I cannot help you much more, though.
[03:16] <braverock> unfortunately, this is an Attic file
[03:16] <ddaa> ?
[03:16] <braverock> so it's already been deleted from the repository
[03:16] <braverock> perhaps you could ignore all Attic files
[03:16] <ddaa> what makes you say it's an attic file?
[03:17] <braverock> xrms/include/adodb/pear/Attic/readme.Auth.txt
[03:17] <braverock> from your error
[03:17] <ddaa> the error message reads Attic because cscvs tries to look up file there if there are not found at the expected location
[03:17] <braverock> oh...
[03:17] <ddaa> it's not an attic file, it's present when you do a checkout
[03:17] <lifeless> ddaa: cvs import creates a default branch
[03:17] <lifeless> fwiw
[03:18] <ddaa> lifeless: look at the error
[03:18] <ddaa> I looks like the default branch was reset after the initial import
[03:18] <braverock> yes, adodb is a database abstraction library, and was probably created using cvs import
[03:18] <ddaa> though I'm not too sure about it
[03:18] <lifeless> ddaa: uel to the error ?
[03:19] <ddaa> https://macquarie.warthogs.hbd.com/roomba/status/xrms-trunk/events/6/log
[03:19] <ddaa> look at https://help.launchpad.net/VcsImportRequests for some diagnostic info
[03:20] <ddaa> braverock: lifeless is the guy who wrote the default branch support code. I leave you in his capable hands
[03:20] <braverock> thanks
[03:21] <braverock> lifeless: I'd be happy to remove the default branch tag there too, if you've got an idea on the cvs command to do that with
[03:22] <lifeless> ddaa: Attic should not be in the request line
[03:23] <ddaa> lifeless: it does fix some imports
[03:23] <lifeless> ddaa: for this specific one
[03:23] <ddaa> right, but it's a fallback
[03:23] <ddaa> first it try in the normal location, then if it does not find the file, it looks into the attic
[03:23] <lifeless> so heres the glitch: there is no revision 1.1.1.2
[03:23] <lifeless> the branch 1.1.1 is fine
[03:24] <ddaa> and if the attic lookup fail, the error bubble up
[03:24] <ddaa> so it's entirely an error reporting issue, not a logic issue
[03:24] <lifeless> ddaa: sure. but look closer : rlog of xrms/include/adodb/pear/readme.Auth.txt
[03:24] <lifeless> there is /no/ 1.1.1.2
[03:24] <ddaa> lifeless: I looked
[03:24] <ddaa> I know the revision is not there
[03:25] <ddaa> but I have no clue why cscvs tries to make a filler cs 1.1->1.1.1.2
[03:25] <lifeless> is that what its trying to do ?
[03:25] <lifeless> whats in changeset MAIN.4167
[03:25] <ddaa> yes, It's explained in https://help.launchpad.net/VcsImportRequests
[03:26] <ddaa> MAIN.4167 is a filler cs 1.1->1.1.1.2
[03:27] <lifeless> your sentence that begins 'in other words' on the help. page appears to be pure speculation.
[03:27] <ddaa> yes it is
[03:27] <ddaa> "it might be"
[03:27] <lifeless> so fillers appear when the branch changes
[03:28] <lifeless> I'd do a search in the file revision table for that file, all revisions, see what cscvs is thinking happened to it
[03:28] <ddaa> that's more than I know about cscvs
[03:28] <ddaa> but thanks for the advice
[03:29] <ddaa> you suggest it might be a problem in the log parser and checking the catalog contents would help narrowing the cause of the problem?
[03:33] <lifeless> something is inventing the .2
[03:33] <lifeless> if its in the catalog then the catalog generator can be checked
[03:33] <lifeless> if its not in the catalog then the application-of-changesets can be checked
[03:33] <lifeless> it will narrow it down
[03:34] <lifeless> As its a very small rlog I'd make a test case from it
[03:34] <lifeless> later
[03:34] <ddaa> thank you
[03:43] <braverock> I've recorded the relevant parts of this conversation on the bug report https://launchpad.net/products/bzr-register/+ticket/1936
[03:44] <braverock> and for the record, I'll note that there are far more projects still using cvs (especially large established ones like xrms) than using svn
[03:44] <braverock> so I hope you can spend a little more time on it to get this resolved.  I'll do anything I can on this end to assist
[03:45] <braverock> thanks for spending the time.
[03:45] <Digital-Pioneer> Hello, all. I just registered with Launchpad, so I figured I'd swing by here and see what's happening. :)
[03:47] <kiko> hey Digital-Pioneer 
[03:47] <kiko> it's a busy tuesday
[03:47] <kiko> as all tuesdays appear to be
[03:47] <Digital-Pioneer> LOL
[03:48] <Digital-Pioneer> Yes... Sever contrast to the activity on #uira (I'm assuming you mean channel population)
[03:48] <Digital-Pioneer> *Severe
[03:50] <kiko> what's #uira?
[03:50] <Digital-Pioneer> Channel for UIRA. ;)
[03:50] <Digital-Pioneer> UIRA: UIRA Isn't a Recursive Acronym.
[03:50] <Digital-Pioneer> Stupid name, but I use it. We're working on a OSS flash IDE.
[03:50] <ddaa> braverock: we are aware of that, but the fraction of cvs using projects is decreasing over time and the svn import code does not work nearly as well as the cvs import code. It's quite rare for a new CVS impont to fail (failure later when people do history-destroying surgery on the repo is another matter...)
[03:51] <Digital-Pioneer> kiko: It used to be FFL.
[03:51] <ddaa> braverock: if you look at the VcsImportRequests page, you'll see that almost all failures recorded there are on SVN.
[03:51] <Digital-Pioneer> But some problems arose, so now it's UIRA. :)
[03:52] <ddaa> braverock: I'm not dismissing the importance of CVS, I'm just explaining why the priorities are what they are
[03:53] <braverock> ddaa: yes, i see that.  I'll happily change anything I can, but it would be nice to get this resolved, as xrms is one of the top few hundred projects on sourceforge, so getting it in launchpad/bazaar would be a nice additional boost
[03:53] <braverock> i understand, I run a big project too ;)
[03:54] <ddaa> braverock: you know how to make your case :)
[03:54] <ddaa> once we have the python import done to satisfaction, I'll try to fix you
[03:54] <braverock> thanks
[03:55] <braverock> I'll leave you alone for a week or so ;)  I really do appreciate the time so far
[03:57] <Digital_Pioneer> Finally. :)
[04:15] <kiko> thanks stub, I appreciate that.
[04:21] <salgado> kiko, my person-creation-rationale branch is blocked because of some unused authserver API. I mailed spiv asking him if it'd be okay to remove that API and he said yes. I added a branch which does that to his queue on friday but apparently he didn't have the time to review. can you review it for me? (it's the kind of diff you like to review: 7 files changed, 12 insertions(+), 462 deletions(-))
[04:21] <salgado> https://devpad.canonical.com/~jamesh/pending-reviews/salgado/launchpad/trivialities/full-diff
[04:21] <SteveA> salgado: I ca review it
[04:22] <SteveA> kiko: I'll take this one
[04:22] <salgado> SteveA, cool, thanks a lot. :)
[04:22] <kiko> thanks SteveA!
[04:24] <SteveA> salgado: r=me
[04:25] <salgado> thanks SteveA!
[04:39] <_thumper_> SteveA: ping
[04:41] <ddaa> _thumper_: how's it going?
[04:41] <_thumper_> ddaa: good
[04:41] <_thumper_> ddaa: db all set up (I think)
[04:41] <_thumper_> code branch set up
[04:42] <_thumper_> now I just need the magic invokation to start it all
[04:42] <ddaa> got the virtualhosting setup?
[04:42] <_thumper_> ah, nope
[04:42] <_thumper_> jamesh mentioned that just before going to sleep
[04:42] <_thumper_> ozzies, what are they like?
[04:43] <jamesh> _thumper_: did you see the mailing list archive page I pasted the link to?
[04:43] <ddaa> I have set it up with apache here, but some people have setups that do not involve using several hundred thousand lines of C
[04:43] <SteveA> _thumper_: hi
[04:44] <_thumper_> hmm.. launchpad private archives
[04:44] <_thumper_> SteveA: just working on the virtual hosting
[04:44] <SteveA> ok, any problems?
[04:44] <jamesh> _thumper_: you log in using your email address plus the password you chose when joining the list
[04:44] <ddaa> once you have that set up, go to your launchpad tree, then "make schema" (if not already done) and "make run"
[04:44] <_thumper_> ok
[04:45] <_thumper_> I'm in... 
[04:45] <ddaa> finally, you should have your toy launchpad at http://launchpad.dev/
[04:45] <jamesh> _thumper_: so remember to write "features.launchpad.dev" wherever it says to write "blueprint.launchpad.dev"
[04:45] <_thumper_> ok
[04:45] <_thumper_> why the change?
[04:46] <ddaa> brand consolidation
[04:46] <jamesh> because we moved the content that appeared at blueprint.launchpad.net to features.launchpad.net
[04:46] <_thumper_> :)
[04:47] <jamesh> _thumper_: you'll be happy to know a lot of this stuff you've been doing is one-off
[04:47] <_thumper_> I did a lot of apache config hacking in my last job
[04:47] <_thumper_> so not phased by that
[04:48] <ddaa> well, if we needed to do it every week, there would at least be up-to-date documentation :) I think that goes without saying
[04:48] <ddaa> just consider it's part of an initiation ritual :)
[04:49] <_thumper_> at least I don't have to run through a tunnel of you guys armed with paddles :)
[04:49] <jamesh> ddaa: I noticed that the viewvc import says "test failed".  I guess it is suffering from the same directory move issue other svn imports have been?
[04:49] <ddaa> naw, paddles are for wuss
[04:49] <ddaa> we use klingon painsticks here
[04:49] <ddaa> jamesh: bingo
[04:50] <ddaa> if somebody wants to do the bazaar meeting minutes for me, I'd be glad to be back at fixing it!
[04:51] <jamesh> looks like the fake .bzr dir patch has been cherry picked into production
[04:53] <kiko> jamesh, surprisingly so!
[04:53] <kiko> jamesh, could you blog about it I wonder?
[04:54] <ddaa> kiko: this email is definitely scary
[04:54] <kiko> ddaa, waaah
[04:54] <ddaa> I need to read it more carefully, but apparently the guy claims to be amnesic and to be the victim of some kind of con job.
[04:55] <kiko> what does it have to do with ubuntu?
[04:55] <ddaa> it does not make a lot of sense though, it might be just a nutcase
[04:55] <ddaa> I'll try to make sense of it and send you a reply.
[04:56] <kiko> heh. okay.
[05:03] <_thumper_> ddaa: apache config done, runlaunchpad.py fails with no command line params
[05:03] <ddaa> _thumper_: make run
[05:04] <ddaa> "make run" that is
[05:04] <_thumper_> ddaa: thanks, it is doing something now
[05:04] <_thumper_> w00t
[05:05] <jamesh> so you have a local Launchpad instance up and running?
[05:05] <_thumper_> ddaa: got it going
[05:05] <_thumper_> yep
[05:06] <matsubara> carlos: ping
[05:06] <carlos> matsubara: pong
[05:07] <matsubara> hi carlos, could you take a look at: https://launchpad.net/products/rosetta/+bug/63236 ? Is there any reason for that page at all? Can I change it to a BrowserNotification instead?
[05:07] <Ubugtu> Malone bug 63236 in rosetta "Change the +export page message to a BrowserNotification message." [Low,Unconfirmed]  
[05:07] <matsubara> s/to a/to use a/
[05:08] <carlos> hmm
[05:08] <carlos> I thought I already answered it...
[05:08] <carlos> matsubara: the answer is yes, you can
[05:09] <matsubara> okie, thanks carlos 
[05:09] <carlos> you are welcome
[05:09] <ddaa> _thumper_: congrats
[05:10] <kiko> salgado, I love incremental diffs
[05:11] <salgado> kiko, so do I... did you know they can be generated with interdiff? :p
[05:12] <kiko> salgado, or bzr -r X..
[05:13] <salgado> only if you've committed
[05:13] <kiko> i've learned to commit
[05:14] <salgado> btw, now it's time to commit because the pending-reviews page is telling me I have a conflict with rocketfuel
[05:14] <kiko> heh heh
[05:18] <salgado> do you want the interdiff? (even for this pretty small diff)
[05:18] <flacoste> salgado: what happens to emails sent by a script run in a test subprocess?
[05:18] <kiko> salgado, not really
[05:19] <salgado> flacoste, they should be stored in stub.test_emails, I think.  IIRC I do check that in some places
[05:20] <flacoste> salgado: really!?! how does execute_zcml_for_scripts knows it is running inside a test harness and should run the particular ftest.zcml file?
[05:21] <salgado> maybe it uses the testrunner config?
[05:21] <salgado> let me see if I can find an example
[05:23] <ddaa> kiko: sent mail
[05:23] <kiko> ddaa, thanks a mil
[05:23] <ddaa> I believe this guy is _actually_ brain-damaged and delusional
[05:24] <ddaa> and he is probably being abused too
[05:24] <ddaa> we should make sure we do not have any support contract or other for-pay service
[05:25] <ddaa> then ignore him
[05:25] <kiko> ddaa, I'll forward it on. :)
[05:28] <ddaa> kiko-fud: there is actually a low probability that somebody is abusing him and posturing as Canonical
[05:29] <ddaa> but we won't be able to find out unless we get to talk with somebody more articulate
[05:30] <salgado> flacoste, hmmm. looks like I was wrong. we don't seem to have any tests that check stub.test_emails after running a script as a subprocess
[05:30] <flacoste> salgado: i think they are just dropped
[05:31] <flacoste> salgado: because execute_zcml_for_scripts loads script.zcml and in there the email stuff is configured outside the tree ("../*-email.zcml")
[05:33] <salgado> maybe you need to include package-includes/mail-configure-testing.zcml
[05:33] <salgado> in script.zcml, that is
[05:34] <flacoste> hmm, maybe. anyway, I don't need that, I was just wondering what would happen with the notifications messages
[05:34] <flacoste> salgado: thanks for your help!
[05:34] <salgado> flacoste, you're welcome. :)
[06:17] <salgado> malcc, around?
[06:40] <salgado> cprov, help! (got another nascentupload failure)
[06:41] <cprov> salgado: where ?
[06:41] <cprov> salgado: hope in test env, not in production ;)
[06:42] <salgado> cprov, yeah, locally. it's in test_uploadprocessor
[06:42] <salgado> cprov, https://devpad.canonical.com/~andrew/paste/fileZOUWDC.html
[06:43] <salgado> cprov, and https://devpad.canonical.com/~andrew/paste/fileA6oyfF.html contains my changes to nascentupload.py
[06:43] <cprov> salgado: well it was aborted earlier than expected, changes_maintainer isn't filled
[06:44] <cprov> salgado: does person = getUtility(IPersonSet).ensurePerson raises something ?
[06:44] <cprov> salgado: I think we already discussed it, no ?
[06:44] <salgado> cprov, no, it's self.distrorelease.displayname that is raising something other than UploadError
[06:44] <salgado> (I think)
[06:45] <salgado> cprov, yeah, we discussed it but at that time I was missing the except UploadError
[06:45] <cprov> salgado: yes, could be
[06:45] <salgado> it looks like now I'm missing an "except BrokenUploadPolicy:"
[06:45] <cprov> salgado: let me check the code
[06:46] <salgado> at least that is the exception being raised by self.distrorelease
[06:46] <salgado> ah, great. that exception only exists for testing purposes and is defined in test_uploadprocessor.py
[06:47] <cprov> salgado: yes, it's for testing the exception handler
[06:48] <salgado> oh no, it does a raise Exception("Exception raised by BrokenUploadPolicy for testing.")
[06:49] <cprov> salgado: anyway, in order to make that code pass (actually send the email) you need to call verify_changes before this time.
[06:51] <carlos> see you!!!
[06:51] <carlos> danilos: do you need anything from me before leaving?
[06:51] <danilos> carlos: no, I am fine, I'll be working for another half an hour or so
[06:51] <danilos> carlos: thanks
[06:52] <salgado> cprov, why does BrokenUploadPolicy raises an Exception? can't it be an UploadError?
[06:52] <carlos> danilos: ok
[06:52] <cprov> salgado: no, check uploadprocessor, there is a bare exception which is what we are trying to test
[06:57] <salgado> cprov, it looks like unless I add a bare except (or an except Exception:) to parse_address, we'll keep having problems on this code forever
[06:58] <cprov> salgado: I have this feeling too, something looks wrong with that multi exception handler in uploadprocessor.
[06:58] <salgado> it shouldn't be a problem since the self.distrorelease is not /really/ required there and will be issued in many other places that are crucial to the processing of the upload
[06:59] <cprov> salgado: well, try it.
[07:03] <salgado> yeah, it works as expected
[07:09] <cprov> salgado: what exception are you getting ?
[07:10] <salgado> cprov, I'm getting an Exception, which is raised by BrokenUploadPolicy.setDistroReleaseAndPocket()
[07:11] <cprov> salgado: uhm, test is wrong, decided to raise a test exception where we already expect UploadError
[07:11] <salgado> eh?
[07:12] <salgado> you said it had to raise an Exception
[07:13] <cprov> salgado: I was wrong, we do not expect any exceptions other than UploadError, to happen via that path, it looks like a simple test convenience for me
[07:14] <salgado> cprov, okay. then I can change the test to raise UploadError?
[07:14] <cprov> salgado: of course, the purpose of the test is to verify if we handle a unexpected exception, but it's imporssible to happen in this path
[07:17] <cprov> salgado: no, the right thing to do would be find another path where a Exception could occur and use it, instead of the current one, which already transform the NotFound in UploadError and deal with the remaning data. But as you can see, it's not your problem, it's something that is getting worst and worst as more as we try to workaround it.
[07:18] <salgado> http://article.gmane.org/gmane.comp.python.devel/84113
[07:18] <kiko-fud> salgado, yeah
[07:23] <salgado> cprov, so, for now, changing BrokenUploadPolicy to raise UploadError() is okay?
[07:25] <cprov> salgado: it will produce different result, test will fail.
[07:27] <salgado> cprov, so, what should I do, then?
[07:28] <kiko> salgado, change it and fix the test?
[07:28] <salgado> that is done already
[07:28] <salgado> but by cprov's last message I assumed this wasn't acceptable
[07:30] <cprov> salgado: well, you want the distrorelease to create a person, but last malcc's fix assume person is created and able to recieve email to handle unexpected exceptions
[07:34] <cprov> salgado: by invoking self.distrorelease.displayname you cause an *unexpected exception* too earlier for the current implementation.
[07:35] <salgado> unexpected exception or an UploadError?
[07:38] <cprov> salgado: the BrokenPolicy emits a Exception.
[07:39] <cprov> salgado: which is caught as an unexpected expection in uploadprocessor (this is utterly confusing)
[07:39] <salgado> now it emits an UploadError, as you said it'd be okay to do
[07:40] <Burgwork> https://launchpad.net/distros/ubuntu/dapper/+source/desktop-multiplier/2.2-3-0ubuntu1
[07:40] <Burgwork> how do I get from that page to the main product page?
[07:40] <cprov> salgado: but it's not, you will break the test.
[07:42] <salgado> cprov, you mean, it won't give the expected output or it won't exercise the code path that it's expected to?
[07:42] <cprov> Burgwork: there is no way, file a bug and/or use this instead: https://launchpad.net/distros/ubuntu/+source/desktop-multiplier/2.2-3-0ubuntu1
[07:43] <Burgwork> cprov, so the UI currently doesn't support those kinds of linkage?
[07:43] <Burgwork> https://launchpad.net/people/support-userful <-- and how do I create this team?
[07:43] <cprov> salgado: if it gives the same result it's only for luck, because UploadError is caught and treated in different way than a Exception
[07:44] <salgado> cprov, no, it doesn't give the same output, but that I can fix easily. (already done that even)
[07:45] <cprov> Burgwork: it does support it, we are just trying to organize the pages better, fewer pages easier info in fewer steps.
[07:45] <Burgwork> yes
[07:45] <Burgwork> ok
[07:46] <cprov> salgado: the test became pointless if you do so. I would preffer to disable it instead of the modification.
[07:47] <Burgwork> cprov, can I get you to merge two teams?
[07:47] <salgado> Burgwork, that's not possible
[07:47] <Burgwork> oh, joy
[07:47] <cprov> Burgwork: see if the page I pointed you has all the info you need, if not, please file a bug in soyuz we will address it soon
[07:50] <Burgwork> ok, I want to shoot LP right now
[07:51] <Burgwork> cprov, https://launchpad.net/products/soyuz/+bug/63808
[07:51] <Ubugtu> Malone bug 63808 in soyuz "/distros/$distro/+source/blah page links badly" [Undecided,Unconfirmed]  
[07:51] <cprov> salgado: can't you create a person w/o the distrorelease name for while ? 
[07:51] <Burgwork> salgado, then can I get a team deleted?
[07:52] <cprov> Burgwork: thanks
[07:53] <Burgwork> cprov, general feedback: what LP really sucks at right now is showing the relationship between the same product in different places
[07:53] <Burgwork> which ironically, is supposed to be its strong point
[07:54] <salgado> Burgwork, no, that's not possible either. :/
[07:54] <salgado> cprov, that would defeat the whole purpose of PersonCreationRationale
[07:56] <Burgwork> salgado, let me tell you what I want and then you can tell me if it is possible. https://launchpad.net/people/support-userful <-- I need to create this team, which is autogenerated, with myself as the admin
[07:56] <Burgwork> and then I need https://launchpad.net/people/userful-support to go away
[07:57] <salgado> Burgwork, so, the first issue is that https://launchpad.net/people/support-userful was created as a person and thus it won't be possible to turn it into a team without manual DB hacking
[07:57] <Burgwork> oh bloody hell
[07:58] <salgado> Burgwork, the email address associated with that person should be something like support@userful.tld
[07:58] <Burgwork> it is
[07:58] <salgado> Burgwork, do you have access to that email address?
[07:58] <Burgwork> salgado, I don't directly, but I can
[07:59] <cprov> salgado: uhm, knowing it was motivated by an upload (dbschema), it is a text field, we have timestamp and we only deal with ubuntu should suffice, IMO. The bigest problem is that we don't have distrorelease info at the time we create person and it will require huge changes in NU workflow, but is your call.
[08:00] <Ubugtu> New bug: #63808 in soyuz "/distros/$distro/+source/blah page links badly" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63808
[08:02] <salgado> Burgwork, then one option would be to merge the support-userful account into yours, then delete the support@userful email that will be assigned to you and register that email as the email address of https://launchpad.net/people/userful-support
[08:02] <salgado> this way future uploads mentioning the support@userful.tld domain will be assigned to that team
[08:02] <salgado> s/domain/email address/
[08:03] <Burgwork> sounds good
[08:03] <salgado> but the existing upload will be assigned to you
[08:04] <salgado> actually, you'll be listed as the maintainer of desktop-multiplier
[08:05] <salgado> cprov, okay, I think that hardcoding "Ubuntu" for now will do the job
[08:06] <cprov> salgado: nice, big xxx and we can improve it when fixing NU workflow
[08:06] <Burgwork> salgado, I still want support@userful.com to be the maintiner
[08:07] <Burgwork> is there a bug out there for "auto created people should be able to be turned into teams"?
[08:07] <Burgwork> because this is not the last time you are going to be dealing with thtis, I am sure
[08:07] <salgado> Burgwork, no, I don't think there's a bug for that
[08:07] <Burgwork> what shoudl I file it against?
[08:08] <salgado> Burgwork, it may be trivial to implement it.  file it against launchpad
[08:09] <salgado> Burgwork, actually, if you're not in a hurry it may be a better idea to wait until I fix the bug
[08:09] <Burgwork> not really
[08:10] <Burgwork> https://launchpad.net/products/launchpad/+bug/63812
[08:10] <Ubugtu> Malone bug 63812 in launchpad "Autocreated people should be trivially turned into teams" [Undecided,Unconfirmed]  
[08:11] <Burgwork> salgado, is there a bug for "people <--> teams should be trivial"?
[08:12] <matsubara-lunch> bug 36966
[08:12] <Ubugtu> Malone bug 36966 in launchpad "Convert person to team" [Medium,Confirmed]  http://launchpad.net/bugs/36966
[08:12] <Burgwork> ah
[08:13] <matsubara-lunch> Burgwork: I think yours is a dupe of 36966
[08:16] <Ubugtu> New bug: #63812 in launchpad "Autocreated people should be trivially turned into teams" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63812
[08:16] <salgado> yeah, it looks like a bug indeed
[08:17] <salgado> s/bug/dupe
[08:17] <salgado> but I don't like the title
[08:18] <salgado> I'm not sure we actually want to turn persons into teams.  on the other hand, an auto-created person is only called a person because we don't know if we should have created a person or a team
[08:38] <salgado> kiko, any chance of some review love today? ;)
[08:38] <kiko> salgado, sure. 
[08:49] <SteveA> dude
[08:49] <SteveA> I have room for more love in my life
[08:49] <SteveA> particularly tonight
[08:50] <SteveA> what do you want reviewed?
[08:58] <salgado> SteveA, it's salgado/launchpad/mirror-management-tweaks, which kiko already reviewed. it's just a review of the last changes I've done that is missing
[09:00] <guibis> Hi i have a problem to log in launchpad ...
[09:00] <kiko> guibis, what's up?
[09:02] <guibis> I try to log in order to report a bug about edgy, and i give my right mailaddress my right password, and after i come back to the page where i were like a none registred ...
[09:02] <kiko> guibis, you need to already be logged in to file a bug.
[09:06] <guibis> I know but evenif i am on this page https://launchpad.net/, i can't log in .
[09:07] <BjornT> guibis: do you have cookies enabled?
[09:09] <guibis> sorry to disturb you, i am a big shit ! now i can give my bug about black screen just after the x .... thks !
[09:09] <kiko> sure
[09:11] <bradb> guibis: Don't worry, it's our fault that the page doesn't remind you to see if you have cookies enabled.
[09:11] <kiko> or detect it
[09:12] <bradb> yeah
[09:12] <guibis> yes, but a simple problem like that, i would be aware about it !
[09:12] <bradb> bug 30679
[09:12] <Ubugtu> Malone bug 30679 in launchpad "Login requires cookies, but does not say so" [Medium,Confirmed]  http://launchpad.net/bugs/30679
[09:16] <guibis> ok i add a comment on it.
[09:18] <guibis> done
[09:18] <SteveA> salgado: so, I'm confused.  What exactly should I review?
[09:20] <salgado> SteveA, well, I guess it's better to leave it for kiko, since he already reviewed the branch. (that's what I tried to say in my last message)
[09:21] <SteveA> salgado: ok
[10:05] <matthewrevell> kiko: ping
[10:05] <kiko> matthewrevell, pong
[10:06] <matthewrevell> Hi :) I'm just summarising the Launchpad news for The Fridge.
[10:06] <kiko> cool
[10:06] <matthewrevell> A URL seems to be broken.
[10:06] <matthewrevell> https://launchpad.net/distros/ubuntu/+releasemirrors
[10:06] <matthewrevell> Gives OOPS-276C490
[10:06] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/276C490
[10:08] <matthewrevell> Apologies, I've just seen your post in launchpad-users
[10:08] <elmo> matthewrevell: that should be +cdmirrors
[10:08] <matthewrevell> elmo: Thanks.
[10:08] <elmo> JOOI, where did you get releasemirrors from?
[10:20] <kiko> crack
[10:20] <kiko> I sent it
[10:31] <mhb> hello
[10:47] <flacoste> anybody wants to do a quick review of my 8600 lines branch? (jjust oking)
[10:47] <flacoste> (just joking, that is)
[11:29] <mpt> Gooooooooooooooooooooooood morning Launchpadders!
[11:48] <salgado> kiko, I know you're going to read it anyway, but my last email to launchpad@ (subject Re: Direct Person Creation) could do with some input from you.
[11:49] <kiko> yeah, I know.
[11:50] <salgado> I'm reminding you because I just sent another one
[11:50] <kiko> I know.
[11:51] <ddaa> Ah, I get to delete the first big chunks of old cscvs code replaced by the new svn changeset logic :)
[11:59] <AlinuxOS> To get 50 strings per page I do: https://launchpad.net/distros/ubuntu/edgy/+source/debian-installer/+pots/debian-installer/ka/+translate?batch=50
[11:59] <AlinuxOS> but after some string translation I get this message:
[11:59] <AlinuxOS> Sorry, something just went wrong in Launchpad. Weve recorded what happened, and well fix it as soon as possible. Apologies for the inconvenience. 
[11:59] <AlinuxOS> If this is blocking your work, let us know on the launchpad-users mailing list (requires subscription). Include the error ID OOPS-276A553 in your message.
[11:59] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/276A553
[11:59] <AlinuxOS> What's wrong ?
[12:03] <ddaa> apparently, the URL query part confused launchpad
[12:03] <ddaa> and it tried to lookup a language by the name 'ru?batch=50'
[12:04] <ddaa> hu
[12:04] <ddaa> ha
[12:04] <ddaa> apparently it redirected you to:
[12:04] <salgado> AlinuxOS, basically, when you already have an "?" in the URL, you should add an "&batch=50" at the end, instead of the "?batch=50"
[12:04] <ddaa> http://launchpad.net/distros/ubuntu/edgy/+source/debian-installer/+pots/debian-installer/ka/+translate?start=970&alt=ru?batch=50
[12:05] <salgado> AlinuxOS, but this is not supported, so you may experience other similar problems
[12:05] <ddaa> and of course, it crashed trying to parse that
[12:06] <ddaa> I think that should be considered a bug, but as salgado points it, hacking the batch size is unsupported, so it would be a low priority bug
[12:07] <ddaa> In the meantime, it's a case of "don't do that".
[12:11] <jordi> hey
[12:11] <jordi> My friend josep had 3 launchpad identities, and has merged them using the "josep" launchpad id
[12:12] <jordi> but when trying to change his wikiname, lp says that "josep" is already owned by some other user.
[12:12] <jordi> which is also him
[12:12] <jordi> hm, nm, I think he solved it