[12:31] <dilys> Merge to devel/launchpad/: [r=jamesh]  Fix https://launchpad.net/products/malone/+bug/34105 (Strip leading and trailing whitespace before storing a bug watch's remotebug in the db) and https://launchpad.net/products/launchpad/+bug/41325 (Need to strip whitespaces from the beginning and end of people's displaynames) (r3558: Diogo Matsubara)
[12:31] <Ubugtu> Malone bug 34105 in malone "Strip leading and trailing whitespace before storing a bug watch's remotebug in the db" [Major,In progress]
[12:58] <Who_> Hello, I'm from the art team (ubuntu-art) - Mark wants us to get a poll up but no-one who is currently available/responding has administrative rights- We need to get things going as fast as possible so as to have our voting for Themes done in time for them to be packaged for Dapper. Can anyone help? - we spoke to Salgado and he said that dropping in here was our best chance... Refernces: https://lists.ubuntu.com/archives/ubuntu-art
[12:58] <Who_> /2006-May/001355.html, https://lists.ubuntu.com/archives/ubuntu-art/2006-May/001480.html
[01:03] <matsubara> Who_: AFAICT, only the team owner or a team admin are able to setup polls for the team
[01:08] <Who_> Salgado thought that it may be possible for some kind of uber admin to do it (my words, not his!)
[01:09] <Who_> From his mail to the list (not yet in the archives) "I myself can't do it, but I can explain what's going on to one of the Launchpad administrators and they'll be able to set up the poll for you. It'd
[01:09] <Who_> be good if you could join #launchpad on freenode.net so we can sort out the poll details and ask one of the global admins to create it for you."
[01:09] <Who_> so I am here obediently :)
[01:10] <matsubara> Who_: indeed it's possible for a Launchpad Admin to setup this poll. the best time to find a LP admin here, is between 12:00 UTC and 21:00 UTC
[01:10] <kiko-zzz> I can help tomorrow, Who_
[01:10] <kiko-zzz> I need to skip out tonight though "or else"
[01:11] <matsubara> Who_: salgado also works at this time, so it'll be better if you can talk directly with him
[01:12] <matsubara> I have to go too. See you guys tomorrow.
[01:13] <Who_> kiko-zzz, that would be great - can I email you more details if we haven't already sorted it out by then?
[01:13] <kiko-zzz> sure
[01:13] <kiko-zzz> gone!
[01:16] <Who_> ('thanks' seemed to escape that message)
[01:16] <lifeless> spiv: we'll still start our run at 0930
[01:21] <spiv> lifeless: ok.
[01:24] <sobersabre> hi guys.
[01:24] <sobersabre> I wonder if I can access my launchpad calendar from evolution ?
[01:24] <sobersabre> and also to post events etc. via evo.
[01:35] <spiv> lifeless: I'm copying down the branch from rocketfuel.knits now, looks about 15% done.
[01:41] <lifeless> k
[01:44] <lifeless> elmo: are you around ?
[01:44] <kiko-zzz> lifeless, he's on vacation
[01:44] <kiko-zzz> you will need to call znarl
[01:44] <lifeless> oh right.
[01:44] <lifeless> I'll rt it, its not urgent
[01:45] <kiko-zzz> ok cool
[01:45] <lifeless> its also trivial, which is why I was going to ask direct :)
[01:48] <kiko-zzz> lifeless, pqm is telling me it I'm submitting a request for a non-managed branch. any clue what I did wrong?
[01:49] <kiko-zzz> I wonder if bzr-submit needs to be updated
[01:49] <kiko-zzz> or if something else is wrong
[01:50] <lifeless> kiko-zzz: i recommend you start using the bzr pqm-submit plugin
[01:50] <lifeless> its more flexible.
[01:50] <lifeless> if pqm is telling you that, then the branch url its being given is wrong.
[01:50] <lifeless> let me check your request
[01:50] <kiko-zzz> my branch URL, right, not the RF one?
[01:50] <lifeless> this is what you sent in
[01:51] <lifeless> star-merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/kiko/launchpad/trivialities-xx/ sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/lib/canonical/launchpad/pagetests/foaf/30-mergepeople.txt
[01:51] <lifeless> it should have been
[01:51] <kiko-zzz> that's not so good.
[01:51] <lifeless> star-merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/kiko/launchpad/trivialities-xx/ sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[01:51] <kiko-zzz> I now see why
[01:51] <kiko-zzz> I am daft
[01:54] <lifeless> spiv: this is a small python fragment I call repo-adsorb
[01:55] <lifeless> from bzrlib.ui.text import TextUIFactory
[01:55] <lifeless> import bzrlib
[01:55] <lifeless> bzrlib.ui.ui_factory = TextUIFactory()
[01:55] <lifeless> import bzrlib.repository
[01:55] <lifeless> target=bzrlib.repository.Repository.open('.')
[01:55] <lifeless> source=bzrlib.repository.Repository.open('devel')
[01:55] <lifeless> target.fetch(source)
[01:55] <lifeless> followed by 'mv devel/.bzr/repository{,.old}'
[01:55] <lifeless> it will suck a branch in metaweave format into a repo
[01:56] <mpt> Yay, I have Internet again
[01:56] <lifeless> kiko-zzz: your merge request looks good. Its in the disabled queue now
[01:57] <kiko-zzz> thanks.
[01:57] <mpt> lifeless, is rocketfuel still pullable?
[01:57] <spiv> lifeless: Oh btw, I have a green Ps driving test at 11:30, so I'll have to disappear for a while around then.
[01:57] <kiko-zzz> I am now going to bed and will dream of fast merges
[01:57] <lifeless> mpt: yes, we wont touch the rocketfuel-built for another 30 minutes
[01:57] <lifeless> spiv: ok.
[01:57] <mpt> ta
[02:00] <lifeless> mpt: andrew or I will guide you through the upgrade
[02:00] <lifeless> as validation of our instructions
[02:00] <lifeless> is that ok ?
[02:04] <mpt> lifeless, sure, you want to do that now?
[02:05] <lifeless> mpt: in about 1 hour
[02:05] <mpt> ok
[02:21] <mpt> BjornT, ping
[02:22] <mpt> BjornT, unping
[02:52] <lifeless> spiv: ok, we're ready for a test merge
[02:53] <spiv> lifeless: I've got about 20MB left to download.
[02:57] <lifeless> production is currently converting
[03:01] <spiv> Finally downloaded.
[03:02] <mpt> Gooooooooooooooooooooood afternoon Launchpadders!
[03:10] <spiv> "-4 revision(s) pulled."  Heh.
[03:10] <lifeless> ;)
[03:12] <spiv> lifeless: I need to head off to the driving test now, I should be back soon.
[03:12] <lifeless> ok
[03:12] <spiv> lifeless: But I have just successfully converted a branch, following the instructions on the page.
[03:12] <mpool> good luck
[03:13] <spiv> "bzr log" and things seems to be giving sane output.
[03:13] <lifeless> cool
[03:13] <spiv> lifeless: not sure where your repo-absorb thing fits in, but we can talk about that when I get back :)
[03:13] <lifeless> ok
[03:13] <spiv> mpool: thanks
[03:13] <lifeless> I'm propogating converted production branches to chinstraph now
[03:44] <mpt> lifeless, spiv, you wanted to walk me through the migration process?
[03:45] <lifeless> yup
[03:45] <lifeless> stub: please let me know before doing anything on balleny just now
[03:45] <stub> ok
[03:46] <mpt> Will I need Internet access on my development machine for this?
[03:46] <lifeless> yes
[03:46] <mpt> ok, bbiab
[03:47] <jamesh> lifeless: to convert a repository, I suppose the best way is to create a new repo and branch into it?
[03:48] <jamesh> (having branched the knit rocketfuel branch into it first)
[03:48] <lifeless> jamesh: hi
[03:48] <lifeless> if you have a repository and need to convert it..
[03:48] <lifeless> bzr init-repo new-repo
[03:48] <lifeless> python
[03:49] <lifeless> from bzrlib.ui.text import TextUIFactory
[03:49] <lifeless> import bzrlib
[03:49] <lifeless> bzrlib.ui.ui_factory = TextUIFactory()
[03:49] <lifeless> import bzrlib.repository
[03:49] <lifeless> target=bzrlib.repository.Repository.open('new-repo')
[03:49] <lifeless> source=bzrlib.repository.Repository.open('old-repo-root')
[03:49] <lifeless> target.fetch(source)
[03:49] <lifeless> when that completes
[03:49] <lifeless> mv old-repo/.bzr/repository{,.weaves}
[03:50] <lifeless> mv new-repo/.bzr/repository old-repo/.bzr/repository
[03:50] <jamesh> shouldn't I be importing the knits branch into the repo first?
[03:50] <lifeless> and yes, pull the knit rocketfuel branch in first
[03:50] <jamesh> otherwise that's equivalent to a bzr upgrade
[03:54] <lifeless> main point is to use python to fetch the repo data
[03:54] <lifeless> rather than pulling X branches across one at a time
[03:54] <jamesh> yeah.
[03:55] <lifeless> converting a bunch of branches into a repo is essentially a 'for path in os.listdir('.'): source = Repository.open(path); target.fetch(source)' loop
[03:57] <lifeless> dell are doing 1000 dollar laptops now
[03:57] <lifeless> thats quite impressive
[03:58] <lifeless> stub: production branches are now in knit format
[03:58] <lifeless> stub: there is a diff in production/launchpad thats not committed
[03:59] <stub> mebbe just the cruft from tests?
[03:59] <lifeless> nah
[03:59] <lifeless> cd ~/production/launchpad && diff to see
[04:00] <jamesh> lifeless: so we can use the versions under .../archives/rocketfuel/ for the conversion rather than rocketfuel.knits now?
[04:00] <lifeless> not yet, the rsync is still running
[04:01] <lifeless> pqm@balleny:~/archives/rocketfuel/launchpad$ rsync -a --delete-after . chinstrap:/home/warthogs/archives/rocketfuel/launchpad
[04:01] <lifeless> when that finishes :)
[04:01] <stub> ahh yes. need to apply that change to production/1.62
[04:02] <lifeless> stub: ok. dont do it yet. will let you know when its clear
[04:02] <stub> yup
[04:03] <lifeless> ouch
[04:03] <lifeless> too much 'testing' ?
[04:03] <stub> swimmingi think
[04:03] <stub> maybe dislocated a bit - things have been clicking back occasionally
[04:04] <stub> so one handed for time being
[04:04] <stub> mebbe take it into the hospital if not getting better in a few hours
[04:05] <mpool> lifeless: gah, the downside is bizarre dell phone support
[04:06] <lifeless> www.dell.com.au/tv
[04:06] <jamesh> I think Dell is still selling $350 Pentium D 2.8GHz machines too
[04:06] <jamesh> in fairly nice tower boxes
[04:08] <jamesh> although if you want to put a replacement graphics card in, you need to modify the card with a hacksaw
[04:08] <lifeless> :)
[04:08] <jamesh> to cut an extra notch
[04:08] <lifeless> have you done this ?
[04:08] <jamesh> yeah
[04:08] <jamesh> you cut the maximum bandwidth of the card down from 16x PCIe to 8x
[04:08] <jamesh> but it works
[04:09] <lifeless> its a half-length socket ?
[04:09] <mpool> !!
[04:09] <jamesh> it is an 8x size socket which only has pins for a 4x connection (the machine is designed to be a server)
[04:10] <jamesh> there is an 8x socket, but it doesn't seem to like graphics cards
[04:11] <salgado> lifeless: around?
[04:11] <lifeless> yup
[04:12] <lifeless> I think I need new batteries :{
[04:12] <lifeless> runtime seems to be shrinking
[04:12] <lifeless> I've checked and they are only rated for 300 charge cycles !
[04:12] <lifeless> mpool: send that merge in asap please
[04:12] <salgado> lifeless: do I need to do something in order to land my shipit branch once the converion to knits is finished?
[04:12] <lifeless> salgado: send in a merge request as normal
[04:13] <lifeless> salgado: I can in fact have your branch come in first if you like
[04:13] <mpt> This is where I wish Ubuntu had labels like OS X
[04:13] <mpt> so I could color-code the branches I've converted
[04:13] <salgado> lifeless: that'd be great
[04:13] <mpool> lifeless, ok
[04:13] <jamesh> mpt: emblems
[04:13] <lifeless> salgado: will you be around if there are glitches ?
[04:13] <salgado> lifeless: at what time?
[04:13] <lifeless> (first up is most risk :))
[04:14] <lifeless> salgado: we can do it as soon as this rsync finishes
[04:14] <lifeless> shouldn't be long now
[04:14] <mpt> lifeless: I don't understand "bzr pull --overwrite into the rocketfuel-built matching branch"
[04:14] <lifeless> its between balleny and chinstrap
[04:14] <mpt> The branch matching what?
[04:14] <salgado> okay. I'm going to have a shower then, be right back
[04:14] <lifeless> mpt: this is where we need to walk you though ;)
[04:14] <lifeless> mpt: tell me what you have done so far
[04:14] <spiv> lifeless: back
[04:14] <spiv> lifeless: (and I passed)
[04:14] <lifeless> spiv: congrats!
[04:15] <lifeless> spiv: now, just sms me when you are driving
[04:15] <mpt> lifeless: I don't use a repository; all my branches are in separate directories
[04:15] <mpt> lifeless: I've rsynced rocketfuel-built
[04:15] <mpt> lifeless: I'm in the middle of "bzr upgrade --format=metaweave trivial"
[04:15] <jamesh> mpt: rocketfuel-built isn't yet in knit format
[04:15] <mpt> where trivial is the first branch I'm converting
[04:15] <lifeless> mpt: right, get those upgrade --format=metaweave done for all your branches
[04:15] <lifeless> mpt: as thats a necessary first step
[04:16] <mpt> oh
[04:16] <lifeless> each one of those will chew up about 400MB of disk
[04:16] <mpt> Why isn't it step 1, then? :-)
[04:16] <mpool> lifeless, sent
[04:16] <lifeless> mpt: because this is not as automated as the baz->bzr one, but should be easier all the same
[04:16] <lifeless> when you do upgrade --format=metaweave, there is a '.bzr.backup' directory created
[04:17] <lifeless> as long as the upgrade worked you can remove that directory, it has about 400Mb of old data in it
[04:18] <mpt> How do I tell whether it worked?
[04:18] <lifeless> it will say 'conversion complete'
[04:18] <mpt> it says "finished"
[04:18] <lifeless> and 'you can remove the .bzr.backup directory'
[04:18] <mpt> nope, doesn't say that either
[04:18] <mpt> if conversion fails, you can move this directory back to .bzr
[04:18] <mpt> if it succeeds, you can remove this directory if you wish
[04:18] <mpt> starting upgrade from format 6 to metadir
[04:18] <mpt> finished
[04:18] <jamesh> mpt: there should be a "repository" directory under the .bzr/ directory
[04:19] <lifeless> mpt: thats a successful conversion
[04:19] <mpt> yes
[04:19] <mpt> ok
[04:20] <mpt> bzr log still works
[04:23] <lifeless> garh
[04:23] <lifeless> man ext3 is SO SLOW AT RM
[04:23] <jamesh> I hear that riserfs is much quicker at losing your files
[04:25] <lifeless> its when one wants them lost its frustrating
[04:44] <salgado> lifeless: so, how's the conversion going?
[04:45] <lifeless> rsyncing still
[04:49] <lifeless> its on 1.49 oout of 1.62
[04:49] <lifeless> 1.5
[04:50] <lifeless> 1.50
[04:50] <lifeless> 1.51
[04:50] <lifeless> 11 branches to go, say 10 minutes
[04:50] <lifeless> I'm going to grab lunch
[04:51] <spiv> Me too.
[04:55] <lifeless> mpool: did that merge work for you ?
[05:04] <lifeless> 1.61, nearly there
[05:14] <lifeless> ok
[05:14] <lifeless> launchpad branch is fully converted
[05:14] <lifeless> salgado: did you have a merge request for this in the queue already ?
[05:18] <salgado> lifeless: it was in the queue
[05:18] <salgado> I can send it again right now, if you want
[05:18] <lifeless> no need, I can retrieve it from the disabled queue
[05:20] <mpt_> lifeless: Does that mean I should pull rocketfuel-built again?
[05:21] <lifeless> mpt_: not quite yet
[05:21] <lifeless> rf built is rebuilding at the moment
[05:21] <lifeless> but anyone usin the archive directly can do so
[05:21] <lifeless> stub: you can do new branches now etc
[05:23] <mpt_> "But if we try to change it to a existing upstream bugtask, our validator enters in action."
[05:23] <mpt_> Enters in action?
[05:23] <lifeless> EWTF
[05:25] <stub> ta
[05:45] <mpt_> lifeless: How long will rocketfuel-built take to rebuild?
[05:46] <lifeless> shouldn't be much longer, its in sourcecode at the moment
[06:01] <lifeless> salgado: you need to sleep. can you send another request in, and I'll shepard it through
[06:20] <lifeless> spiv: can you send in a request please
[06:20] <spiv> lifeless: Hmm, ok.
[06:21] <lifeless> just a trivial change
[06:21] <lifeless> I think I've fixed the thing that glitched salgados branch
[06:21] <mpt_> lifeless: finished?
[06:21] <lifeless> nope, same thing glitched it
[06:21] <lifeless> mpt_: so just work as normal
[06:21] <mpt_> ok
[06:39] <spiv> lifeless: still merging to the same location, right?
[06:41] <spiv> lifeless: sent
[06:42] <lifeless> yes
[06:44] <jamesh> was nice to see that the working repository for pending-reviws was about half the size when moved to knits
[06:45] <jamesh> hopefully we'll see better performance once everyone else's branches are half the size
[06:45] <lifeless> how do you merge, local disk paths or sftp ?
[06:45] <spiv> lifeless: I see no action on the pqm status page yet... I hope it won't still take four hours ;)
[06:45] <jamesh> the pending-reviews script does local disk paths
[06:46] <lifeless> spiv: building the config
[06:52] <lifeless> spiv: so, how are you going converting your branches ?
[06:52] <lifeless> spiv: fairly painless ? any ideas for the doco ?
[06:55] <spiv> lifeless: Main issue for me is disk space -- I'm very tempted to figure out how to share a repository for my branches.
[06:55] <lifeless> spiv: the python fragment I posted is the key
[06:55] <lifeless> spiv: jamesh also wrote a script
[06:55] <lifeless> which, with knits I'm happy for people to use.
[06:55] <spiv> Your python fragment assumes some weird directory structure I don't have.
[06:56] <lifeless> spiv: tell me about your structure
[06:56] <spiv> Essentially, I have a "launchpad" directory somewhere in my home directory with all my (weave) branches.
[06:56] <lifeless> so you have launchpad/foo
[06:56] <lifeless> and launchpad/bar
[06:57] <spiv> Right.
[06:57] <jamesh> spiv: http://people.ubuntu.com/~jamesh/make-bzr-repo.sh <- change FORMAT=metadir to FORMAT=knit and it will be happy
[06:57] <lifeless> do they have nested branches ?
[06:57] <lifeless> that is is there launchpad/foo/sourcecode/* ?
[06:57] <spiv> lifeless: Yes, mostly.
[06:57] <spiv> Mostly they start as copies (often hardlinked) of rocketfuel-built.
[07:00] <jamesh> spiv: the way I work now is with my branches under ~/repo/canonical/$product/$branchname where each of ~/repo/canonical/$product is a shared repository
[07:00] <lifeless> spiv: note that it is merging now
[07:00] <lifeless> I think we have fixed the performance headache
[07:00] <jamesh> spiv: I then do a "bzr checkout --lightweight" of the branch I want to work on to create a working tree (somewhere other than ~/repo
[07:01] <lifeless> spiv, jamesh we now need *good* doco to help people switch to knits themselves
[07:01] <spiv> lifeless: Down to 20 minutes for build-config + merge, yeah.
[07:01] <spiv> lifeless: I'm still curious about why it took so long before, even when merging to e.g. sqlobject, but it doesn't really matter now.
[07:01] <jamesh> lifeless: I suppose for small products I may as well just do "bzr upgrade" on my repos?
[07:02] <lifeless> yup
[07:02] <jamesh> since a full conversion is fairly cheap
[07:02] <spiv> "small" would be basically anything other than "launchpad" for us?
[07:02] <jamesh> yeah
[07:03] <spiv> The next closest in number of revisions in rocketfuel is probably sqlobject, and that's only about 50 or 60.
[07:03] <spiv> Oh, cscvs I guess.
[07:03] <spiv> But nothing else in the thousands...
[07:04] <spiv> lifeless: Note that this merge will compensate for knits by making check_merge slower ;)
[07:04] <lifeless> spiv: ahhha. bastard :)
[07:06] <lifeless> jamesh: do you think that a repo and lightweight checkout is as simple as we can get it ?
[07:07] <jamesh> lifeless: it is a little more complicated than "cp -al rocketfuel-built my-new-tree", because you need to fix up sourcecode/
[07:07] <lifeless> spiv: so to use a repository, you can just do what that script does, or use an repository with working trees where you work *within* the repository.
[07:07] <spiv> lifeless: I wish the pqm-submit plugin was packaged.
[07:07] <jamesh> lifeless: I've been playing around with doing lightweight checkouts of the sourcecode/ dirs from rocketfuel-built too
[07:08] <lifeless> yah
[07:08] <spiv> lifeless: I don't have a strong feeling for or against either of those options.
[07:08] <lifeless> spiv: bzr itself is big and you should use the version I'm converting now
[07:08] <lifeless> (sourcecode/bzr)
[07:09] <spiv> I guess this means I can't simply "cp -al" from rocketfuel-built to make a new branch + checkout anymore...
[07:09] <jamesh> lifeless: I suppose a script for setting up/updating sourcecode/ would make lightweight checkouts simple to use.  I don't know whether config-manager fits that bill or not though
[07:09] <lifeless> jamesh: thats what rocketfuel-built is done with
[07:09] <spiv> lifeless: Oh heh, I forgot about that one, I converted my bzr.dev checkout ages ago :)
[07:10] <jamesh> lifeless: but that's not a lightweight checkout
[07:10] <lifeless> jamesh: just needs a command line option to the URLMapper to make it look at local disk
[07:10] <spiv> "cp -al $rf-built/sourcecode/* sourcecode/" isn't much harder, though...
[07:10] <lifeless> jamesh: oh true. a couple of lines of python
[07:11] <lifeless> more importantly though, I think the idiom of rsyncing rf-built down and using it is nice
[07:11] <lifeless> if you do this:
[07:11] <lifeless> rsync it down
[07:11] <lifeless> hack hack hack
[07:11] <lifeless> bzr push /local-repo/branch
[07:11] <lifeless> then that push will be fast
[07:11] <lifeless> and if you have a shared repo on chinstrap
[07:11] <lifeless> bzr push sftp://chinstrap/h/w/a/user/launchpad/branch
[07:12] <lifeless> should be fast enough to
[07:12] <lifeless> it will need to pull about 2Mb of data to push, which sucks
[07:12] <spiv> lifeless: I was about to ask that -- "bzr push /local-repo/new-branch" is the obvious piece I think I was missing.
[07:13] <jamesh> lifeless: one thing I like about lightweight checkouts is that I can put the checkouts anywhere, and they use the ~/.bazaar/branches.conf settings for the repo directory
[07:13] <spiv> Is there a way to in-place convert a branch from standalone to a lightweight checkout?
[07:13] <lifeless> spiv: not so much
[07:13] <lifeless> spiv: can be written though
[07:13] <jamesh> means I only needed to configure "bzr pqm-submit" once and it works wherever my checkouts are
[07:13] <spiv> lifeless: I think I'd find that very useful at the moment.
[07:14] <lifeless> jamesh: cool. can you document that on our developer documentation today ?
[07:14] <lifeless> SteveA has allowed me to ask you to help out with the conversion, as I knew you'd been working on this workflow somewhat
[07:14] <spiv> lifeless: My upgrade procedure would then be to start a repo seeded with the converted rocketfuel, then as I want to work on existing branches I have, push them into that repo and switch them to being checkouts of that repo.
[07:14] <jamesh> lifeless: okay.  I think I included a description in an email to the list earlier but I'd be happy to add it to the wiki
[07:15] <lifeless> so we need two things today
[07:15] <lifeless> 1) conversion HOWTO for sabdfdl, mpt etc
[07:15] <lifeless> covering upgrade on chisntrap
[07:15] <spiv> Then there'd be no disruption to my existing nested working trees and finger-memory of paths :)
[07:15] <lifeless> upgrade on local machine
[07:15] <lifeless> spiv: so we can write a command using bzr to so it
[07:15] <lifeless> spiv: I was suggesting you turn ~/launchpad in to a repo - bzr init-repo ~/launchpad
[07:16] <jamesh> lifeless: I'm still using the "rsync local repo to chinstrap".  Is there a way to do that with the bzr sftp transport yet?
[07:16] <jamesh> i.e. not individual branches
[07:16] <lifeless> spiv: then upgrade each branch to metaweave - for d in *; do bzr upgrade --format=metaweave $d; done
[07:16] <lifeless> spiv: then run that python fragment to ensure you hav all the revisions from these branches - after pushing a rocketfuel-knit into the repo
[07:17] <spiv> After adjusting the paths in the python fragment...
[07:18] <lifeless> spiv: you would have ~/launchpad/branch just as you do today
[07:20] <spiv> Right.  The "." and "./devel" paths in the existing fragment confused me -- for some reason I find the "branch is here, but the repo is there, and a is parent dir of the branch" arrangement unexpected and thus disorientating until I realise what's going on.
[07:21] <lifeless> for instance, heres how I am converting the rf branches
[07:21] <lifeless> from bzrlib.ui.text import TextUIFactory
[07:21] <lifeless> import bzrlib
[07:21] <lifeless> import os
[07:21] <lifeless> bzrlib.ui.ui_factory = TextUIFactory()
[07:21] <lifeless> import bzrlib.repository
[07:21] <lifeless> target=bzrlib.repository.Repository.open('.')
[07:21] <lifeless> for branch in os.listdir('.'):
[07:21] <lifeless>   if branch == '.bzr':
[07:21] <lifeless>     continue
[07:21] <lifeless>   source=bzrlib.repository.Repository.open(branch)
[07:21] <lifeless>   target.fetch(source)
[07:21] <spiv> (on a related note, I find the fact that there are four seperate things that have formats confusing sometimes)
[07:22] <lifeless> yes
[07:22] <lifeless> its a compromise
[07:22] <lifeless> there are four concepts - the control dir, the tree, branch and repo
[07:22] <lifeless> we could have said there is one lockstep format
[07:22] <lifeless> and that all change at once
[07:22] <spiv> It provides wonderful flexibility, but I have to concentrate sometimes to keep track of what's what in test cases and the like :)
[07:22] <lifeless> yup
[07:23] <spiv> I'm not disagreeing with the design, just providing a datapoint you may find interesting.
[07:23] <jamesh> spiv: the alternative is one format identifier with (#working tree formats)*(# of repository formats)*(#branch formats) values
[07:23] <spiv> jamesh: Or to simply disallow most combinations.
[07:24] <lifeless> well
[07:24] <jamesh> spiv: with shared repos it is useful
[07:24] <lifeless> the nice thing is a plugin can install a new format of just the element it cares about
[07:24] <jamesh> spiv: the format identifiers are attached to the directories where the data is stored
[07:25] <lifeless> i.e. a faster tree format can be introduced by one plugin, and a better branch representation by another plugin
[07:25] <lifeless> this is impossible with a single identifier
[07:25] <jamesh> spiv: I can upgrade the repository to knits without having to touch the branches in the repo
[07:25] <spiv> jamesh: I agree.  I like the capabilities this design offers.  I'm just mentioning that I've sometimes been confused by it.
[07:25] <lifeless> spiv: so, what would be really good is a suggestion to retain the capabilities - which are in use - but reduce the confusion factor
[07:25] <lifeless> i.e. branch._branch_format, tree._tree_format  perhaps  ?
[07:26] <jamesh> lifeless: that implies heirarchy
[07:26] <jamesh> bah
[07:26] <jamesh> I misread what you typed
[07:26] <lifeless> :)
[07:26] <spiv> lifeless: that might help.  I think calling "bzrdir" something like "controldir" would be clearer to my brain, too.
[07:27] <lifeless> spiv: on disk, it is the '.bzr' dir :):):)
[07:28] <spiv> "bzrdir" has too many possible meanings for the casual coder -- e.g. "that's the dir with my bzr checkout" or "bzr branch"...
[07:28] <lifeless> we considered controldir
[07:28] <lifeless> but felt bzrdir was really on the money as an exact description
[07:28] <lifeless> its possible that was wrong
[07:28] <spiv> Fair enough.
[07:30] <jamesh> are readonly bound branches planned for bzr?
[07:30] <lifeless> jamesh: I'm concerned about rsync usage
[07:30] <lifeless> jamesh: because there is dataloss potential
[07:31] <lifeless> standalone branches its clear that what you copy is what you gt
[07:31] <jamesh> lifeless: sure.  That's why I was asking if there was an equivalent way to push all my branches using sftp
[07:31] <lifeless> shared repos you have to know to rsync the entire repo, and you have to never rsync from a different repo
[07:32] <spiv> Ah, crap.  The hct/sourcerer part of the check_merge is bust.
[07:32] <lifeless> ahha
[07:32] <spiv> I'll just merge the sourcecode/* bit for now.
[07:33] <lifeless> jamesh: do you work on concurrent branches ?
[07:34] <jamesh> lifeless: do you mean work on two branches on the same machine at once, or the same branch from multiple machines?
[07:34] <lifeless> the former
[07:34] <lifeless> like, why do you need 'all'
[07:35] <lifeless> if you use bzr push sftp it will push the data needed for the one branch
[07:35] <jamesh> I sometimes work on multiple branches, but mostly I'd like a single command I can use that makes sure everything is mirrored up onto chinstrap
[07:36] <lifeless> jamesh: its planned
[07:36] <spiv> lifeless: I can imagine that if I've been offline for a while, and have hacked on multiple branches, it'd be nice to have an easy way to say "mirror everything, please".
[07:36] <lifeless> jamesh: open the repo, listdir under it
[07:36] <lifeless> jamesh: for each dir, try to open a branch
[07:36] <lifeless> jamesh: if the branch opens, and the branch.repository.transport.base == repo.transport.base, then push it
[07:37] <lifeless> jamesh: if the branch opens and the repository it uses is different, then dont push it, *and stop searching down that directory structure*
[07:38] <jamesh> lifeless: okay.  I'll investigate it at some point.
[07:38] <lifeless> jamesh: take out a write lock on the remote repo at the start, and on the local repo a read lock
[07:38] <lifeless> then caching is your friend, though we may need api changes to make it really optimisable
[07:39] <lifeless> i.e. perhaps repo.fetch() should take a set of required versions (if it doesn't already - I'd need to check)
[07:46] <lifeless> merging now
[07:46] <lifeless> so thats < 7 minutes to buildconfig
[07:46] <lifeless> testing now
[07:46] <lifeless> < 2 minutes to merge
[07:47] <jamesh> how does that compare with before?
[07:48] <lifeless> before the reweaving period it was 10-15
[07:48] <lifeless> and 5-10
[07:48] <lifeless> so, much faster
[07:48] <jamesh> I suppose the push to chinstrap after a successful merge will be a lot faster too
[07:48] <lifeless> we're pulling a shitload less data from chinstrap to merge
[07:48] <lifeless> and yes
[07:52] <lifeless> spiv: so, any thoughts on doco about the convrsion ?
[07:52] <lifeless> spiv: as in, have you made any notes on the rf to knits page ?
[07:53] <spiv> I've made no notes on that page yet.
[07:53] <spiv> I'll review it and see what I can offer.
[07:54] <lifeless> I'm going through the non launchpad branches at the moment ensuring they are in knits
[07:54] <lifeless> I'll be another hour or so doing that. pqm is reenabled, and I'm restoring the queue of merges
[07:55] <spiv> lifeless: curious.
[07:56] <spiv> lifeless: the "now playing" says it's Celso's branch, but I think it's still running my merge...
[07:56] <lifeless> yes, thats because I restored the backedup queue
[07:57] <lifeless> the reporter and the merger are separate processes
[07:59] <spiv> Does that mean Celso's merge will be dropped on the floor, or just that it's next?
[07:59] <lifeless> latter
[07:59] <spiv> Cool.
[08:00] <lifeless> do you know where salgados ship branch was ?
[08:00] <lifeless> I want to put that back in the queu ...
[08:00] <spiv> I don't, no.
[08:00] <lifeless> I'll peek in his archive dir
[08:01] <lifeless> I'm just not sure if I'll get the right one ;)
[08:01] <lifeless> spiv: ok, so for doco. Can you please guide mpt through complete conversion of his branches on chinstrap and his machine
[08:01] <spiv> lifeless: Ok.
[08:02] <lifeless> spiv: and note down what was done, that should provide a good basis
[08:02] <spiv> mpt: it's time to destroy^Wconvert your branches!
[08:02] <spiv> lifeless: I'm tweaking the wiki page, too.
[08:02] <lifeless> spiv: thanks!
[08:05] <mpt_> spiv: ready?
[08:05] <spiv> mpt_: Give me another 60 seconds and I'll have updated the wiki page.
[08:05] <mpt_> ok
[08:06] <lifeless> oh meh, zope is freaking big isn't it
[08:12] <spiv> Ok, I've updated the instructions for standalone branches on RocketfuelToKnits
[08:12] <spiv> mpt_: Do you have a copy of rocketfuel in knit format?
[08:13] <mpt_> spiv: No. Will I need the copy that's in weave format any longer, or can I overwrite it?
[08:15] <spiv> mpt_: You can overwrite it.  Note that rocketfuel-built is now in knit format, so you can just rsync that as usual if that's what you usually do.
[08:15] <mpt_> spiv: On a separate issue, "you only need to do it once" suggests that the section should be "For standalone branches", with a "Then, for each branch:" line
[08:15] <lifeless> uhm about that
[08:16] <lifeless> theres is a little complication with rf-built
[08:16] <lifeless> ZOPE IS FUCKING BIG
[08:16] <spiv> lifeless: So is launchpad :P
[08:16] <lifeless> zope is worse :(
[08:16] <SteveA> hello
[08:16] <spiv> mpt_: good point, I'll change it.
[08:17] <lifeless> spiv: anyway, I suggest using built-knits for mpt
[08:17] <lifeless> SteveA: hi
[08:17] <lifeless> SteveA: launchpad is in knits, merges are going through
[08:17] <lifeless> SteveA: time to setup and merge is now < 10 minutes
[08:18] <SteveA> cool
[08:18] <SteveA> any issues?
[08:18] <spiv> lifeless: Btw, my sourcecode merge failed because of bzr.  Grr.
[08:19] <lifeless> SteveA: couple of glitches, which are corrected already
[08:20] <lifeless> SteveA: and we spiv/jamesh/I are still discussing what best practice should be
[08:20] <spiv> mpt_: So, there's a rocketfuel-built-knits directory next to the usual rocketfuel-built that lifeless suggests you use instead.
[08:23] <spiv> lifeless: btw, that wiki page lists the status of twisted as "twisted" ;)
[08:23] <lifeless> erm, yeah
 spiv: so stop the rsync from rocketfuel-built?
[08:26] <mpt> ... eh, I have to stop it anyway, since I lost the connection
[08:26] <spiv> mpt: I guess that answers that, then :)
[08:27] <mpt> meanwhile
[08:27] <mpt> spiv: Step 2 seems very strange. Why should my local copy of rocketfuel be implanted with records about local branches that might never even land?
[08:28] <spiv> It's harmless to have unreferenced revisions in a repository.  We do it so that only the new revisions in your branch need to be converted to knits, rather than the whole of history.
[08:29] <mpt> I wasn't using a repository before. Does that matter?
[08:29] <spiv> No.  And the instructions for standalone branches don't change that.
[08:29] <mpt> Hmm, I guess "local repository" means something different from .bzr/repository
[08:30] <jamesh> mpt: when you do "pull --overwrite" from one of your branches into the knit format rocketfuel-built tree, it only needs to copy the revisions that you haven't landed, which is quite quick
[08:30] <spiv> Every branch has a repository.  It might belong to just that branch and held in its .bzr directory, or it might be shared and kept somewhere else.
[08:31] <jamesh> mpt: the .bzr/repository directory just contains the history data of the branch
[08:31] <jamesh> mpt: so by overwriting the .bzr/repository directory in your branch with the version in rocketfuel-built with your changes pulled your branch is in knit format
[08:31] <mpt> So this process turns my local copy of rocketfuel's repository into a shared repository?
[08:31] <jamesh> no
[08:33] <spiv> mpt: This process sucks your revisions into a branch which already has a repository filled with launchpad knit data (so you don't have to wait hours and hours to convert it yourself), then copies that repository back into your branch.
[08:33] <mpt> ah
[08:33] <jamesh> mpt: the .bzr/repository directory for a metaweave or knit format branch stores the state of the launchpad tree at various points in the past
[08:33] <mpt> ok, so
[08:33] <jamesh> mpt: when you do "pull --overwrite" from your branch to the rocketfuel branch, it adds information about your branch to the rocketfuel-built branch's repository
[08:34] <jamesh> mpt: once it contains all the history information of your branch, you can replace the weave format repository in your branch with the knit format repository without losing any info
[08:35] <mpt> The first branch I do this to is going to end up with a repository that knows about its own revisions
[08:36] <mpt> The second branch I do this to is going to end up with a repository that knows about its own revisions, and those of the first branch
[08:36] <jamesh> yep
[08:36] <mpt> The third branch I do this to is going to end up with a repository that knows about its own revisions, and those of the first and second branches
[08:36] <mpt> and so on?
[08:36] <jamesh> but the individual changes in each branch are usually small compared to the bulk of the repository data (more than 200MB)
[08:37] <mpt> So what it lacks in scalability, it makes up for in tininess? :-)
[08:37] <spiv> mpt: Right.  But as I said before, unreferenced revisions are harmless :)
[08:37] <mpt> ok
[08:38] <jamesh> mpt: you'll probably want to switch to a shared repository at some point in the future.  At that point you essentially have one .bzr/repository directory for all your branches
[08:38] <jamesh> but for now it might be easier to just keep the branches separate
[08:38] <jamesh> attack one problem at a time
[08:38] <spiv> I think so.
[08:39] <mpt> I often work on two or three branches at once
[08:39] <mpt> e.g. merging one, fixing tests in another, running tests in a third
[08:39] <spiv> For instance, *I'm* not worrying about shared repos yet, and I think I know how they work :)
[08:40] <jamesh> mpt: you'll like shared repos.  They make merging a lot quicker if you work with multiple branches
[08:40] <mpt> Would I still be able to do that with a bzr shared repository (unlike a baz repository)?
[08:40] <jamesh> yes
[08:40] <spiv> mpt: Yes.
[08:40] <mpt> cool
[08:40] <spiv> With the added benefit that that 99% of revision data that is common to all the branches will be stored only once :)
[08:41] <jamesh> one part of the merge process is copying the revision information into your branch's repository
[08:41] <sivang> morning
[08:41] <jamesh> so if you use shared repos and are merging rocketfuel, you only need to pay that price for the first branch you merge rocketfuel into.
[08:41] <mpt> At some stage I should also figure out how to stop having a separate copy of sourcecode/ for every branch...
[08:41] <jamesh> for the subsequent branches, the revision info is already present
[08:44] <mpt> This looks like it'll take about an hour and a half
[08:45] <stub> lifeless: salgado/launchpad/shipit-for-dapper
[08:54] <carlos> morning
[08:54] <lifeless> hi carlos
[08:58] <SteveA> lifeless: how far off are the instructions for the team?
[08:58] <SteveA> sabdfl: we're converting to knits at present
[09:00] <SteveA> so, don't merge RF into any of your branches
[09:00] <SteveA> as it will take forever
[09:09] <lifeless> SteveA: quite close
[09:09] <lifeless> SteveA: spiv is validating them with mpt at the moment
[09:09] <SteveA> cool
[09:11] <lifeless> there is somthing wrong with pybaz's conversion, I'm rolling it back at the moment
[09:11] <lifeless> (only pybaz)
[09:11] <spiv> lifeless: Unfortunately, I need to head off to yoga soon, and mpt is still downloading the converted launchpad branch.
[09:13] <lifeless> ok
[09:14] <spiv> lifeless: Hmm, it's not particularly slow to pull from weaves to knits?
[09:14] <jamesh> spiv: no.
[09:14] <spiv> e.g. weave branches in pqm's queue at the moment aren't a significant problem.
[09:14] <spiv> That's what I thought (after all the conversion process does it...)
[09:14] <spiv> I'll tidy up the warnings on the wiki page, then.
[09:15] <jamesh> spiv: pending-reviews has been using a knits repository for the past few days without slowdown (it is probably a bit faster, actually)
[09:15] <spiv> jamesh: Neat.
[09:15] <lifeless> spiv: 'knits to weaves bad'
[09:15] <lifeless> 'weaves to knit fine'
[09:19] <lifeless> ok, pybaz fixed up
[09:20] <SteveA> what was wrong?
[09:20] <lifeless> corrupt weave data
[09:20] <lifeless> should have reconciled first :{
[09:21] <lifeless> so, rollback, reconcile, reconvert
[09:21] <SteveA> i see
[09:21] <SteveA> i'm a little concerned that we can have corrupt weave data in RF without it being detected for some time
[09:21] <SteveA> maybe we should cron-job integrity checks on RF or something?
[09:22] <lifeless> SteveA: it was detected by the stricter logic in knits
[09:22] <lifeless> SteveA: thats why merges failed for that period, and why I knew to correct it.
[09:22] <SteveA> cool
[09:22] <SteveA> knits are the future
[09:24] <mpt__> Everyone should learn to knit
[09:24] <carlos> :-P
[09:24] <SteveA> it takes ages to knit letters
[09:25] <mpt__> In the 1980s there was a very popular New Zealand cartoon about a woodsman called Bogor
[09:25] <mpt__> He and his pet hedgehogs were very fond of knitting
[09:25] <mpt__> and poetry
[09:26] <SteveA>  bug 44773.
[09:26] <Ubugtu> Malone bug 44773 in launchpad "Uploading a tar.gz or uncompressed tar file to https://launchpad.net/products/picard/main/+pots/picard/+upload fails" [Normal,Unconfirmed]  http://launchpad.net/bugs/44773
[09:28] <lifeless> mpt__: hows it going ?
[09:29] <mpt__> 30 minutes more for inventory.knit
[09:30] <lifeless> meep
[09:30] <spiv> I'm off to yoga now...
[09:30] <lifeless> ok
[09:30] <mpt__> Thanks for your help spiv
[09:30] <spiv> mpt__: Someone else will have to look after you.
[09:30] <lifeless> jamesh and I shall see what we can do doco wise :)
[09:31] <spiv> Ok.
[09:33] <carlos> stub: I'm getting a lot of timeouts on staging.... is that normal?
[09:33] <carlos> the server load is low
[09:34] <stub> timeout is set a lot lower on staging - check staging/launchpad.conf
[09:34] <stub> and the db is a lot slower than production
[09:37] <carlos> that's bad for testing purposes...
[09:37] <carlos> I'm fixing some Kurdish data and the guy that did the checks on staging
[09:37] <carlos> complained about the amount of timeouts he got
[09:37] <stub> it is pointing out slow pages thatneed to be fixed
[09:37] <SteveA> it's a sign we should optimise the translation stuff
[09:38] <carlos> yeah, but I guess this is another reason to use another server for data migration testing...
[09:39] <carlos> SteveA: we still have the AJAX thing that I started some time ago to reduce the overload of that page. Do we have a plan for it already?
[09:40] <stub> we can increase the timeout temporarily if needed for some reason
[09:40] <SteveA> carlos: i think we should look at it.  we should also look more closely at the code that is involved in rendering the pages that time out
[09:41] <carlos> stub: is not needed atm, the guy give me the approval anyway. Next time I know what to change, I didn't know the timeout slot was lower there
[09:41] <Yannig> Hello everybody :)
[09:41] <carlos> SteveA: I'm changing that template atm, I guess I could profile it a bit more when it lands into staging
[09:42] <carlos> Yannig: hi
[10:02] <dilys> Merge to devel/launchpad/: r=SteveA Merge in salgados shipit-for-dapper branch (r3559: Guilherme Salgado)
[10:05] <jamesh> lifeless: I put up some initial notes on using shared repos here: https://wiki.launchpad.canonical.com/WorkingWithSharedRepositories
[10:09] <lifeless> mpt: could you please read that through
[10:10] <lifeless> mpt: and tell me what questions it raises for you ?
[10:10] <lifeless> mpt: its an optional change to the way you work.
[10:11] <mpt> ok
[10:11] <lifeless> how is your rsync going ?
[10:22] <carlos> stub: could I increase the timeout preference?
[10:22] <carlos> on staging
[10:22] <carlos> only for today
[10:24] <mpt> lifeless: that looks fairly understandable
[10:25] <mpt> lifeless: (2053, 4.8% of 44827)
[10:25] <lifeless> thanks
[10:25] <lifeless> rocketfuel-built is fully knitified now
[10:30] <SteveA> cool
[10:36] <dilys> Merge to devel/launchpad/: [r=spiv,kiko]  Fix bug #44240 (build rescore input validation), bug #44227 (build rescore corner case), bug #44208 (build rescore messages layout), bug #43802 (prejoin BuildQueue for Builds)and bug #3580 (buildd celebrity). Adding cron.germinate from Kamion (r3560: Celso Providelo)
[10:36] <Ubugtu> Malone bug 44240 in soyuz "+rescore page needs input validation" [Normal,In progress]  http://launchpad.net/bugs/44240
[10:36] <Ubugtu> Malone bug 44227 in soyuz "When the buildqueue_status is None +rescore page OOPS" [Normal,In progress]  http://launchpad.net/bugs/44227
[10:36] <Ubugtu> Malone bug 44208 in soyuz "Informational message not displayed correctly in +rescore page" [Normal,In progress]  http://launchpad.net/bugs/44208
[10:36] <lifeless> hahah
[10:36] <lifeless> ubugtu and dilys talking to each other
[10:46] <lifeless> jamesh: could you review  salgado/launchpad/mirror-management2 today ? I didn't allocate it when I should have
[10:50] <BjornT> lifeless: actually you did allocate it, it was in my queue, but then salgado moved it to the 'work in progress' queue. it seems that he didn't update the status, though.
[10:50] <lifeless> ah
[10:51] <lifeless> jamesh: no matter, nothing to review
[10:52] <lifeless> that means we have only 1 outstanding review.
[10:52] <lifeless> congratulations to the review team
[10:56] <lifeless> mpt: hi. how is it going ?
[11:06] <sivang> lifeless: hehe, this is cool :)
[11:07] <lifeless> sivang: ?
[11:07] <lifeless> what is 'this'
[11:07] <sivang> lifeless: just now saw your comment about dilys and Ubugtu talking to each other, real AI :-D
[11:07] <sivang> lifeless: and evening, btw.
[11:08] <lifeless> :)
[11:09] <sivang> dilys: hi
[11:09] <carlos> sivang: she can, when daf is around ;-)
[11:09] <carlos> SteveA: btw, I didn't get any answer from daf to my email about dilys
[11:10] <mpt_> lifeless: (756, 7.3% of 44827)
[11:10] <lifeless> mpt_: garh.
[11:10] <lifeless> mpt_: ok, just let that run overnight
[11:11] <lifeless> work without merging from rocketfuel until that completes.
[11:11] <lifeless> if it stops halfway you can run it again *without* deleting your partial copy
[11:12] <mpt_> Yes, that's what I've done the three times it's stopped so far :-)
[11:12] <lifeless> if it does stop halfway, please have rsync down rocketfuel-built next time, thats fully in knit format now
[11:12] <mpt_> (resumed it rather than deleting and restarting)
[11:12] <mpt_> oh, ok
[11:12] <lifeless> (as in, rsync that down over your partial copy)
[11:12] <sivang> carlos: ah, heh
[11:12] <mpt_> yep
[11:13] <lifeless> I'm going for dinner
[11:13] <lifeless> back in a bit
[12:07] <Kamion> Does anyone understand the error on https://launchpad.net/people/kamion/+branch/debian-installer-utils/ubuntu ?
[12:07] <Kamion> "Could not install revisions<EMAIL_ADDRESS>[12:07] <Kamion> (that's the head revision on that branch)
[12:08] <Kamion> I'd like to know whether it's something wrong with my branch or something wrong with Launchpad
[12:08] <Kamion> after a quick sampling, it appears to be happening to all my branches
[12:10] <glatzor> ping carlos
[12:10] <carlos> glatzor: pong
[12:11] <glatzor> hi carlos, do you also have got a script that could revert all rosetta translations of the kde packages to suggestions?
[12:11] <Kamion> oh, except for my pcmciautils branches. The ones that are failing are all knit branches; may be a coincidence, but perhaps not
[12:11] <carlos> glatzor: I have a script that could be adapted to work that way, yes
[12:11] <carlos> in fact, is a simple SQL query
[12:12] <carlos> Kamion: ddaa is your man for launchpad
[12:12] <Kamion> not here, I see
[12:12] <carlos> Kamion: but seems like he's not around, I suggest to use bzr check
[12:13] <SteveA> Kamion: are you using knits or repositories?
[12:13] <carlos> to know if there is something wrong with your branch while you wait for David
[12:13] <Kamion> bzr check is happy
[12:13] <glatzor> I don't get any feedback on our translator list if anybody reviews and uploads each upstream translation. I don't have got the time, so we need a more "global" approach
[12:13] <Kamion> SteveA: I thought those two were orthogonal
[12:13] <SteveA> Kamion: yes.  however, the work to support these features on the SM has not been rolled out yet iirc
[12:13] <Kamion> SteveA: I'm using knits, and I have a .bzr/repository/ directory
[12:13] <Kamion> ah
[12:14] <glatzor> I will set a dead line on our list and would notify you, if it is passed or somebody volunteered doing package by package.
[12:14] <carlos> glatzor: I you want, I could write something to use upstream translations and leave the additions that are not translated upstream
[12:14] <carlos> that way you don't need to review translations that are not translated in KDE
[12:14] <glatzor> this would be terrific
[12:15] <lifeless> SteveA: pulling from a repository requires no SM changes. pulling from knits requires a specific bug to be fixed
[12:15] <SteveA> thanks lifeless
[12:15] <glatzor> carlos: I just wanted to talk with the kde guys if they had made any string changes
[12:15] <carlos> glatzor: terrific?
[12:15] <lifeless> in fact, as PQM is quiet, I'll do the bzrlib update thats been pending now
[12:16] <carlos> glatzor: well, is not that they did string changes but translated strings that we were lacking translations for
[12:16] <carlos> anyway, I'm not sure the translations are imported already... let me check....
[12:16] <SteveA> bug 41409
[12:16] <Ubugtu> Malone bug 41409 in launchpad-bazaar "initial push of a knit branch errors" [Critical,In progress]  http://launchpad.net/bugs/41409
[12:16] <SteveA> bradb: hello
[12:17] <carlos> glatzor: yes, German translations for KDE are imported now
[12:17] <glatzor> carlos: I am not very familiar with the KDE translation status. that is also why I don't like to make any decisions - but what to do if nobody else steps in.
[12:17] <carlos> glatzor: what I'm suggesting is
[12:17] <carlos> glatzor: to leave whatever upstream project has
[12:17] <carlos> and revert any change done in Rosetta
[12:18] <carlos> but without disabling translations for strings that are not translated upstream
[12:18] <SteveA> Kamion: maybe subscribe to bug 41409
[12:18] <Ubugtu> Malone bug 41409 in launchpad-bazaar "initial push of a knit branch errors" [Critical,In progress]  http://launchpad.net/bugs/41409
[12:18] <glatzor> carlos: that would be the best solution. i hope that it is not too much work for you
[12:19] <Kamion> SteveA: I just did :-)
[12:19] <SteveA> cool
[12:19] <Kamion> thanks
[12:19] <carlos> glatzor: I have already some code to do that, don't worry about it
[12:19] <carlos> glatzor: should I do this now or wait for your confirmation after talking with translators'
[12:19] <carlos> ?
[12:19] <glatzor> carlos: so I notify the other ones that you write this script and we will apply it tomorrow if nobody disagrees
[12:20] <carlos> glatzor: I can execute it on a testing server, if you could get anyone from your team that could check the changes
[12:20] <carlos> that would be really good
[12:20] <carlos> so we are sure that all things work as they should
[12:21] <glatzor> carlos: by the way do you know how i get my ubuntu email address? i was approved as an ubuntu memeber yesterday
[12:22] <carlos> glatzor: I don't know the procedure, sorry
[12:22] <carlos> Kamion, do you know it?
[12:22] <carlos> Kamion, SteveA: do we have it documented in any place? is not the first time I'm asked about that
[12:24] <Kamion> it's supposed to happen automagically
[12:24] <Kamion> afaik
[12:24] <Kamion> if it doesn't, it's an elmo thing
[12:25] <Kamion> glatzor: have you tested<EMAIL_ADDRESS>?
[12:25] <Kamion> i.e<EMAIL_ADDRESS>[12:26] <carlos> Kamion: ok
[12:26] <glatzor> Kamion: yesterday: Undelivered Mail Returned to Sender
[12:26] <glatzor> Kamion: but I could try again
[12:27] <carlos> glatzor: I guess there is a small delay between you being an ubuntu member and the alias being created
[12:27] <Kamion> glatzor: it won't be immediate, I think it's a daily cron job or something, but I've never seen the script in question so I'm not certain
 Recipient address rejected: User unknown in virtual
[12:29] <glatzor>     alias table (in reply to RCPT TO command)
[12:29] <glatzor> but it can wait
[12:31] <carlos> stub: the DELETE command is really, really slow, I already splitted it into 25 DELETE sentences, but it's still slow
[12:31] <Kamion> glatzor: if it persists, ask elmo
[12:31] <carlos> stub: do you have any suggestion to optimize it?
[12:33] <glatzor> carlos: has doku replied to you concerning the oo.o files?
[12:33] <carlos> stub: here you have what I'm executing atm: https://chinstrap.ubuntu.com/~dsilvers/paste/fileADz0FF.html
[12:33] <carlos> glatzor: no, he's out for the Debconf, so I guess I will not get any answer before next week
[12:37] <glatzor> thanks carlos, I owe you a beer :)
[12:38] <carlos> glatzor: you are welcome ;-)
[12:49] <carlos> BjornT: hi, around?
[12:49] <carlos> I'm having some problems with the new pagetest system
[12:54] <BjornT> hi carlos. what are you having problems with?
[12:54] <Yannig> Yahoooooooo!
[12:54] <Yannig> 0,25% of Ubuntu translated into Occitan! :D
[12:54] <carlos> Yannig: ;-)
[12:54] <Yannig> I may see some purple one day on the progress bar :D
[12:55] <Yannig> One day, aspell in Occitan too, when I understand how to... (but it's not that urgent :))
[12:56] <carlos> BjornT: https://chinstrap.ubuntu.com/~dsilvers/paste/file9aHd6s.html
[12:56] <carlos> BjornT: Is a problem with the Authorization
[12:57] <carlos> BjornT: with that, the first fails as it should, but the second fails too, and it shouldn't
[12:57] <carlos> BjornT: If I change the order, the request as jordi works
[12:58] <jordi> "as jordi"?
[12:58] <carlos> BjornT: this is the trace I get: https://chinstrap.ubuntu.com/~dsilvers/paste/filerxEbEZ.html
[12:58] <carlos> jordi: you are being used for testing purposes ;-)
[12:59] <jordi> yay. :)
[01:01] <BjornT> carlos: ok, it think i know why that's happening, i'll take a look at it.
[01:01] <carlos> BjornT: ok, thanks
[01:02] <BjornT> carlos: for now it should be possible to do ">>> browser = Browser()" and ">>> browser.handleErrors = False" before the second request.
[01:02] <carlos> ok
[01:02] <carlos> I guess that's only needed when the test raises an error, right?
[01:03] <BjornT> yeah
[01:03] <carlos> BjornT: I'm going to file a bug about this and add an XXX comment there, ok?
[01:03] <BjornT> that'd be good, thanks
[01:06] <carlos> BjornT: is the other patch you gave me applied now on rocketfuel?
[01:06] <BjornT> carlos: well, the bug is fixed in rf, yes.
[01:07] <carlos> ok, thanks
[01:15] <carlos> BjornT: from where should I import Browser ?
[01:15] <BjornT> carlos: zope.testbrowser
[01:17] <carlos> ok, seems like it's working now
[01:17] <carlos> BjornT: thanks
[01:17] <carlos> see you later!
[01:50] <malcc> I'm getting an error from a new-style page test I'm writing: https://chinstrap.ubuntu.com/~dsilvers/paste/fileNXhSHj.html
[01:50] <malcc> The test is here: https://chinstrap.ubuntu.com/~dsilvers/paste/file7ubW6i.html
[01:51] <malcc> It seems to be the auth causing the problem, and when running as a standalone page test, touching the front page after setting the auth before doing anything else sorts out the cookie problem in the traceback
[01:51] <malcc> But when running as part of the story, I get this cookie exception whatever I do...
[01:51] <malcc> Anyone help, or know who can?
[02:05] <BjornT> malcc: did someone help you with your pagetest error? if not, make sure you have rocketfuel revno 3357 in your branch, it should make the error go away.
[02:06] <malcc> BjornT: Thanks, I'll try that
[02:09] <SteveA> BjornT: is there a bug filed on the fascist about urlparse?
[02:11] <BjornT> SteveA: no, i'll file one now.
[02:11] <SteveA> thanks
[02:15] <Kamion> Could somebody move netcfg into the d-i project, please?
[02:18] <SteveA> lifeless: hello
[02:18] <SteveA> lifeless: one thing that is not clear to me from your email to the launchpad list is, can i continue using the rocketfuel-get script to get rocketfuel-built from chinstrap?
[02:19] <SteveA> if so, will it automatically get a knits version for me?
[02:19] <lifeless> SteveA: yes, it will
[02:19] <lifeless> and yes, you can
[02:19] <lifeless> gnight
[02:23] <Kamion> also for the d-i project: autopartkit, bterm-unifont, lvmcfg, mdcfg, usb-discover
[02:29] <Kamion> and more for the d-i project: grub-installer, lilo-installer
[02:29] <Kamion> (is this the right place to ask for these? https://launchpad.net/projects/d-i/+newproduct told me to ask here)
[02:37] <Kamion> more for the d-i project: anna, cdrom-checker, cdrom-detect, cdrom-retriever, floppy-retriever, kbd-chooser, lowmem, main-menu, net-retriever, nobootloader, partconf, udpkg
[02:46] <Kamion> alternatively, somebody could make me the registrant for all of the above products and I'll do it myself :-)
[02:48] <ddaa> good timeoftheday
[02:49] <SteveA> Kamion: send me a gpg signed email with urls to the products you want to be owner of, and i'll do it on receipt
[02:49] <Kamion> will do, thanks
[02:50] <SteveA> also, confirm what your user-id is in launchpad
[02:50] <SteveA> so i'm definitely assigning them to the right person
[02:51] <SteveA> ddaa/spiv: got an eta for making the SM understand knits?
[02:51] <lifeless> SteveA: I tried to upgrade bzr in rf, failed. I think spiv may have branches for me, so I've asked him
[02:51] <spiv> SteveA: The puller?  As soon as bzr in rf is upgraded.
[02:52] <spiv> (and rolled out, obviously)
[02:52] <SteveA> okay.  kamion was asking earlier, as he has a branch in knits he was trying to get mirrored
[02:52] <ddaa> lifeless: got a few minutes for an importd/cscvs question
[02:52] <carlos> BjornT: https://launchpad.net/products/launchpad/+bug/45226
[02:53] <Ubugtu> Malone bug 45226 in launchpad "New pagetest infrastrucrture does not recover from errors" [Normal,Unconfirmed]
[02:53] <carlos> there you have it
[02:53] <spiv> lifeless: Hmm?  I don't have any branches for making bzr tests in rocketfuel pass.
[02:53] <ddaa> SteveA: when spiv fixes are rolled out, an admin should also remove the empty branches from the supermirror
[02:54] <spiv> lifeless: it's bzrlib.tests.blackbox.test_too_much.TestCommands.test_main_version that's failing when I tried to uncripple check_merge.
[02:54] <lifeless> spiv: you said to me you had tried with bzr.dev and bzrtools merge rom aaron
[02:54] <lifeless> spiv: I get importd test failures
[02:54] <spiv> Oh, right.  Those fixes are merged.
[02:54] <lifeless> spiv: where too ?
[02:54] <spiv> Damn, either I missed some, or there are new issues...
[02:54] <lifeless> spiv: what branch were they in ?
[02:54] <spiv> Oh, hmm, maybe I only fixed launchpad and not other trees.
[02:55] <spiv> I can take a look, but just to be clear, I don't have any outstanding branches for this.
[02:55] <BjornT> thanks carlos, i'll update the bug.
[02:56] <lifeless> spiv: I merged in bzrtools and bzr dev, and ran make check_merge. it failed
[02:56] <lifeless> ddaa: ask, dont ask to ask
[02:56] <carlos> BjornT: is that related with the urlparse issue you raised on launchpad mailing list? or that one was related to the other problem we had some days ago?
[02:56] <spiv> lifeless: Ok.  I'll take a look.  Hopefully it's shallow...
[02:57] <lifeless> spiv: dont look now
[02:57] <spiv> lifeless: I'm not, just putting it on the todo list so I won't forget :)
[02:57] <lifeless> spiv: I'll make my merged trees available on chinstrap so you dont need to do conflict resolution
[02:58] <spiv> lifeless: thanks!
[02:58] <spiv> SteveA: voice call?
[02:59] <SteveA> spiv: yeah
[03:00] <SteveA> i'm running the devil's tool
[03:01] <SteveA> Kamion: received.  i'll get to it as soon as i've finished my call with spiv
[03:02] <Kamion> SteveA: thank you
[03:08] <ddaa> lifeless: importd.JobStrategy.CVSStrategy.getCVSDir does "if self._tree.repository() != self.repo():" to check if the tree needs checkout out again.
[03:08] <ddaa> That raises if the repository for the tree does not exist (e.g. Sourceforge).
[03:08] <ddaa> There's a FIXME in CVS.Repository.__init__ near the call to self.version() that raises the error that says "we should lazy initialise this".
[03:08] <ddaa> And the importd code the re-get the tree removes the existing checkout _and_ its cache.
[03:08] <ddaa> lifeless: with me so far?
[03:08] <lifeless> right
[03:08] <ddaa> Three questions:
[03:08] <ddaa> 1. should the failure be fixed by comparing textual roots in importd (instead of repos) or by fixing CVS.Repository.__init__ not to call self.version().
[03:09] <ddaa> *question mark*
[03:09] <ddaa> lifeless: next question, or are you answering that one first?
[03:11] <lifeless> ddaa: whats the failure
[03:11] <ddaa> no route to host
[03:11] <ddaa> anyway, it's wrong that this check needs to connect to the repo for the tree
[03:12] <lifeless> ddaa: is it ?
[03:12] <ddaa> sure, if the repo is changing it may likely be because the old one (stored in the tree) no longer works
[03:12] <ddaa> as it's the case with sourceforge, such cases should not require manual fixing
[03:12] <lifeless> if the repo is different, why would we not need to checkout again ?
[03:13] <ddaa> not saying that we would not need to checkout again
[03:13] <ddaa> saying that when checking whether we need to checkout again, we should not need to connect to the repo address saved in the tree
[03:13] <lifeless> anyway, the lazy init simply is saying that until the connection is needed, including the version based dispatches in repository, we shouldn't need to connect
[03:14] <ddaa> mh... except the version dispatches are in another "protocol" object now...
[03:14] <lifeless> right
[03:14] <ddaa> the Repository just does dispatch on native/subprocess
[03:15] <ddaa> So, you seem to say that we should delay creating the protocol object until it's really needed. Which leads to the second question.
[03:15] <ddaa> 2. If the fix should be done in cscvs, this significantly changes the API as a few tests expect the connection to be attempted at Repository.__init__:
[03:15] <ddaa> 2.a those that check that it raises an exception on a bad repository
[03:15] <ddaa> 2.b those that check the value of hasProtocol() to check whether the native protocol is used
[03:15] <ddaa> The 2.a could be fixed by changing the tests to check for error when calling Repository.protocol()
[03:15] <ddaa> The 2.b could be fixed by changing has protocol to try creating the protocol if _protocolAttempted is not set.
[03:15] <ddaa> Is that correct? Are there other non-obvious changes needed?
[03:16] <lifeless> sounds about right
[03:16] <lifeless> not aware of any tricks there, its one of the cleaner bits of the code base
[03:16] <ddaa> it's the "about" bit I'm worried about, I know this is an excessively tricky part of the code
[03:17] <lifeless> its 2315
[03:17] <lifeless> if you want a stronger statement than about, ask me to review it once its done
[03:17] <ddaa> sure will do
[03:17] <ddaa> you're the only one who might catch a logical mistake in that patch
[03:17] <ddaa> Then the final question
[03:18] <ddaa> 3. Should the importd re-checkout code be modified to attempt preserving the cache? That's significant because of bug 37896. If yes, how? What gotchas do you think of?
[03:18] <Ubugtu> Malone bug 37896 in launchpad-bazaar "cscvs sometimes split a CVS commit in multiple changesets" [Normal,Confirmed]  http://launchpad.net/bugs/37896
[03:21] <lifeless> ddaa: should be fine. our update is 'cvs update, cvs log, slot them in place'
[03:22] <ddaa> hu?
[03:22] <lifeless> a recheckout should be non problematic. Note that with cvs you can checkout inplace and it should work
[03:22] <ddaa> Nope, the re-checkout is "shutil.rmtree, checkout, rebuild cache"
[03:22] <ddaa> at least that's what importd does now
[03:22] <lifeless> ddaa: I'm saying we dont depend on the files on disk for the calculation of new log entries
[03:22] <lifeless> s/log entries/changesets/
[03:23] <lifeless> ddaa: sure. this is a special case. I think the general case of rmtree, checkout, rebuild is appropriate *because* we don't know that its the same content anymore
[03:23] <lifeless> but equally, one can argue that because we dont know its different, its safer to keep the same cache.
[03:23] <ddaa> then, if it's not the same content, the incremental import on the same target branch will lead to undefined results...
[03:24] <ddaa> so, you are saying, do "cvs checkout" on the existing cvsworking, that will update the files and do not touche the cscvs cache stored in the csworking/CVS dir?
[03:25] <ddaa> * that will update the files and will not touch the cscvs cache
[03:29] <lifeless> ddaa: yeah - test it by hand before spending time on it of course
[03:29] <ddaa> okay, thank you
[03:29] <lifeless> can I go to bed now ?
[03:29] <ddaa> can always move the cscvs cache to a temp name and move it back into the checkout
[03:29] <lifeless> :)
[03:30] <lifeless> consider that a race condition though
[03:30] <ddaa> ahu?
[03:30] <lifeless> possible better to checkout to a temp name and then move the final dirs around
[03:30] <lifeless> what if the checkout fails
[03:30] <ddaa> righ
[03:30] <ddaa> good point
[03:30] <lifeless> tchau
[03:31] <ddaa> good night
[03:32] <sivang> night lifeless
[03:33] <`6og> hi sivang.
[03:55] <Kamion> huh, the registrant of a product can't use +reassign on that product?
[03:55] <carlos> BjornT: hi, do you have time for a fast review?
[03:55] <carlos> Kamion: I'm not completely sure, but I think it's a bug
[03:55] <carlos> let me check
[03:55] <Kamion> ah, bug 41639
[03:55] <Ubugtu> Malone bug 41639 in launchpad "Product owner should be able to reassign ownership to another user." [Normal,Confirmed]  http://launchpad.net/bugs/41639
[03:56] <carlos> BjornT: most changes are related to pagetests, that's why I ask you to do the review
[03:56] <carlos> Kamion: there you have ;-)
[04:00] <BjornT> carlos: sure
[04:01] <carlos> BjornT: cool, thanks. It's a fix for bug #37078
[04:01] <Ubugtu> Malone bug 37078 in rosetta "+admin page for IPOTemplate is not working for Rosetta experts" [Major,In progress]  http://launchpad.net/bugs/37078
[04:01] <carlos> BjornT: https://chinstrap.ubuntu.com/~dsilvers/paste/fileCo8HAs.html
[04:01] <kiko> morning
[04:01] <carlos> kiko: morning
[04:01] <kiko> morning aces of spades
[04:12] <ddaa> knitty launchpad
[04:12] <ddaa> cool
[04:14] <LarstiQ> ddaa: surely, that isn't realised yet?
[04:14] <kiko> ddaa, did the migration succeed?
[04:14] <ddaa> LarstiQ: no, not what you mean
[04:14] <ddaa> kiko: lemme double check
[04:15] <ddaa> LarstiQ: I meant the migration of the vcs for launchpad itself to knit
[04:16] <LarstiQ> ddaa: good news too
[04:19] <kiko> ddaa, seems like the answer is yes.
[04:19] <ddaa> LarstiQ: rsync currently downloading .bzr/repository/inventory.knit from rocketfuel-built
[04:20] <spiv> kiko: Yes, it succeeded.
[04:20] <kiko> good work spiv
[04:20] <spiv> kiko: Your next rsync of rocketfuel-built will be rather large.
[04:21] <spiv> kiko: All the credit is lifeless'
[04:21] <kiko> spiv, I have a local autosynced mirror
[04:21] <ddaa> spiv: heya
[04:21] <spiv> I just helped be a guinea pig, and polished bits of the docs on the RocketfuelToKnits page.
[04:21] <spiv> ddaa: Hey.
[04:21] <ddaa> can you coordination with stub about garbage collecting the branch warehouse from spurious empty branches on the next rollout
[04:22] <ddaa> * can you coordinate
[04:22] <spiv> ddaa: I think I have a fix in hand for 44183 and maybe 41414.
[04:22] <spiv> I'll push it up and get your opinion.
[04:23] <ddaa> spiv: better to ask somebody who's more conversant in bzrlib
[04:23] <ddaa> lifeless or mpool
[04:23] <spiv> ddaa: Hmm, ok.
[04:24] <ddaa> also, I'd like to focus on fixing that #@$!+#@! importd for cvsroot changes
[04:24] <spiv> ddaa: Can you fix it for current bzrlib while you're there? ;)
[04:25] <ddaa> mh
[04:25] <ddaa> oh, right warnings...
[04:26] <ddaa> I'll try to get rid of the warning too, although it's a completely different piece of code
[04:26] <spiv> ddaa: I don't know about a warning, just that lifeless says that importd tests fail with bzrlib 0.8 instead of whatever's in rf.
[04:27] <spiv> I'll look at it soonish, don't let it bother you :)
[04:27] <ddaa> spiv: I like running around the place to give work to other people and generally try to make things work, but sabdfl wants vcs imports not too suck.
[04:28] <ddaa> So I definitely need to step out from the coordination-review sort of work and immerse myself in importd black entrails.
[04:30] <ddaa> I heard that jamesh is a bit bald because he wrote the native pserver client for cscvs when he got hired ;)
[04:31] <spiv> Heh
[04:37] <BjornT> carlos: i sent the review via email
[04:37] <carlos> BjornT: ok, thanks
[04:50] <dilys> Merge to devel/launchpad/: [trivial]  Try and make the people merging test less flaky (r3561: kiko)
[04:50] <kiko> yayzers
[04:52] <BjornT> kiko: do you think that merge increases the possibility of 30-mergepeople.txt passing?
[04:53] <kiko> BjornT, it is an attempt. Steve and I are unsure of what's wrong. care to give your merge another attempt?
[04:53] <BjornT> sure
[05:01] <kiko> wow it is indeed a long rsync
[05:06] <SteveA> kiko: 1st rsync of RF-built will take a long time
[05:06] <SteveA> it is essentially all changed
[05:06] <kiko> right
[05:07] <SteveA> spiv recommends right now to do an initial push of a branch: cp -a the branch from rf-built
[05:07] <SteveA> then push with sftp --overwrite onto it
[05:07] <SteveA> takes about 4 mins for launchpad
[05:07] <SteveA> from .au
[05:08] <SteveA> in the future, we can get good instructions for repositories on chinstrap
[05:08] <spiv> I've noted this on RocketfuelToKnits btw.
[05:08] <SteveA> and so not need to the cp -a trick
[05:08] <SteveA> spiv: what are you doing still here!
[05:09] <spiv> SteveA: bitching about users with Twisted devs...
[05:09] <carlos> SteveA: I guess https://wiki.launchpad.canonical.com/WorkingWithSharedRepositories would work for that if you only use one development machine, right?
[05:10] <SteveA> carlos: to answer your question i would need to read that wiki page.  and i'm not going to do that today.
[05:10] <carlos> oh, ok, I thought you were already aware of it
[05:10] <SteveA> i know it exists
[05:10] <SteveA> no idea what it says
[05:10] <SteveA> thanks for pointing it out anyway :-)
[05:12] <carlos> jamesh suggests using rsync to push the whole shared repository
[05:12] <carlos> but don't worry, I guess lifeless will give us more information later ;-)
[05:17] <bradb> One thing I wasn't clear about: are we supposed to avoid rspush after knits conversion?
[05:17] <bradb> rspush is taking a million years times three over here, but maybe that's normal.
[05:18] <bradb> other operations seem pretty speedy
[05:18] <spiv> bradb: rspush isn't safe with shared repositories, and sftp is almost as quick now, so it's simplest just to use sftp I think.
[05:19] <bradb> but i'll retry with sftp then
[05:19] <ddaa> it would be nice if you could avoid saying "shared repos", it confuses the heck out of everybody
[05:19] <ddaa> the user feature is "repositories"
[05:19] <spiv> ddaa: Is there a better term I should use?
[05:20] <ddaa> shared repos suggest a repo used by multiple users
[05:20] <spiv> ddaa: Hmm, how do I distinguish "repositories shared between multiple branches" and "repositories belonging to a single branch"?
[05:20] <salgado> kiko, Unshelving from default/01: "Changes shelved on 2006-05-16 14:46:45"
[05:20] <salgado> bzr: ERROR: Your shelved patch no longer applies cleanly to the working tree!
[05:20] <ddaa> it makes it a bit awkyard to refer to the "internal repository of a standalone branch", but it's the best solution I know so far
[05:20] <SteveA> http://www.imdb.com/title/tt0087995/
[05:20] <salgado> kiko, when this happens it means the patch that was shelves is lost?
[05:21] <kiko> salgado, use patch -p1
[05:21] <kiko> no
[05:21] <kiko> it means you will need to patch -p1 .shelf/...
[05:21] <spiv> ddaa: Also, the bzr wiki needs some polishing if "shared repositories" isn't a term for users...
[05:21] <kiko> salgado, and then resolve the failures manually
[05:21] <kiko> salgado, you may be able to use wiggle
[05:21] <ddaa> yes the wiki need some serious cleanup
[05:21] <bradb> most do
[05:21] <ddaa> I'm growing more and more convinced that wiki are not appropriate for maintaining documentation
[05:21] <bradb> ddaa++
[05:22] <salgado> kiko, will try. thanks!
[05:22] <ddaa> if anything, they lack a sense of continued ownership
[05:23] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug #44182: supermirror branch puller leaves empty branch when initial mirroring fails. (r3562: Andrew Bennetts)
[05:23] <Ubugtu> Malone bug 44182 in launchpad-bazaar "supermirror branch puller leaves empty branch when initial mirroring fails" [Major,In progress]  http://launchpad.net/bugs/44182
[05:24] <klichota> Hi
[05:24] <klichota> Is there anyone here taking care of Rosetta?
[05:24] <ddaa> carlos is your man
[05:24] <klichota> Thanks
[05:24] <carlos> klichota: hi
[05:24] <klichota> Hi
[05:25] <klichota> I have spotted a few broken templates
[05:25] <klichota> They have 0 messages
[05:25] <klichota> kchart, kpresenter and k3b
[05:25] <klichota> k3b.po, libk3b.po and others seem OK
[05:26] <carlos> klichota: do you have the .pot files there?
[05:26] <klichota> See https://launchpad.net/distros/ubuntu/dapper/+source/k3b/+pots/k3b/
[05:26] <klichota> No, but all .po files have 0 messages
[05:27] <carlos> klichota: yeah, that means that the .pot file has a problem
[05:27] <klichota> I have tried importing translated .po from KDE SVN, but it didn't help
[05:27] <carlos> and I guess that the problem is that the .pot file is using UTF-8 chars but the header doesn't say it
[05:27] <klichota> BTW. Are they imported automatically from KDE SVN?
[05:27] <carlos> klichota: the .pot file should be fixed first
[05:27] <carlos> no, from packages uploaded into Ubuntu
[05:28] <carlos> klichota: please, could you file a bug about this issue at https://launchpad.net/products/rosetta ?
[05:28] <klichota> So are these files from Rosetta used at all if there are translations in package?
[05:28] <klichota> OK, I will file a bug
[05:29] <carlos> klichota: I'm busy atm and that way I don't forget to take a look at it, but I guess it's a matter of fixing the .pot header
[05:29] <klichota> Should I report all templates in one bug or each separately?
[05:29] <carlos> just a single bug
[05:29] <klichota> OK, thanks
[05:29] <klichota> Bye!
[05:29] <carlos> klichota: thanks for the report
[05:38] <ddaa> knits squashes a very bad O(repository) constant
[05:39] <ddaa> it's still there I think, but much much smaller
[05:43] <kiko> hmmm. not so nice to hear that
[05:56] <havarha> how should I report a bug on with launchpad when I don't know which package contains the bug?
[05:57] <carlos> havarha: launchpad.net/products/launchpad
[05:57] <carlos> if it's a bug in launchpad itself
[05:57] <havarha> ah, no, talking about a bug in ubuntu :)
[05:57] <havarha> and the form want's me to fill in the name of the package
[05:58] <carlos> havarha: https://launchpad.net/distros/ubuntu/+filebug
[05:58] <carlos> if you select just Ubuntu distribution
[05:58] <carlos> and choose to file a bug
[05:58] <carlos> you get that page
[05:59] <havarha> yeah, I'm there, but I don't know what the name of the package is. was wondering if there was a more general bug-form, or if I should just skip that part
[05:59] <matsubara> carlos: do you think bug 45269 (the one klichota just reported) might be a dupe of bug 44808?
[05:59] <Ubugtu> Malone bug 45269 in rosetta "Some template files are broken (0 messages)" [Normal,Unconfirmed]  http://launchpad.net/bugs/45269
[05:59] <Ubugtu> Malone bug 44808 in rosetta "Some translation templates in dapper don't contain any items" [Normal,Unconfirmed]  http://launchpad.net/bugs/44808
[06:00] <bradb> havarha: That page lets you say "I don't know" when asked "In what package did you find this bug?"
[06:00] <havarha> ok, thanks
[06:00] <carlos> matsubara: yes, I think we could say is the same bug. We should fix our UI but also fix those templates
[06:01] <bradb> havarha: Out of curiousity, where did you start to try and file a bug?
[06:01] <bradb> i.e. what url
[06:01] <havarha> bradb: https://launchpad.net/malone/bugs/+package
[06:02] <bradb> ah, ok, interesting. that page is getting out of date.
[06:02] <havarha> and because I'm blind I just saw that it didn't say (Required) ;)
[06:02] <dilys> Merge to devel/launchpad/: Do not lose the standard option selected by the user when the form has errors. r=kiko (r3563: Guilherme Salgado)
[06:02] <bradb> havarha: Not your fault. That page has been neglected. It should look like our normal +filebug form.
[06:03] <havarha> ok :)
[06:17] <kiko> BjornT, rejected already?
[06:19] <BjornT> kiko: yeah, but due to conflicts. i'll convert my repository to knits and try again later after i've merge in rf.
[06:19] <kiko> BjornT, ah, shame.
[06:22] <kiko> sits, what's up?
[06:22] <sits> kiko: ah whenever I ask a question over there there's no response and after 50 bugs I think I've had enough
[06:23] <kiko> sits, what packages are you looking at?
[06:23] <sits> er
[06:23] <kiko> sits, I suspect you may have better luck in #ubuntu-motu
[06:23] <sits> all of them
[06:23] <kiko> right.
[06:23] <sits> starting with the oldest first
[06:23] <kiko> so general triage.
[06:23] <sits> yes
[06:23] <sits> I've waded through them as best I could
[06:23] <kiko> oldest first is not always the best strategy because they are often harder to triage
[06:24] <sits> but some of those are extremely tough
[06:24] <kiko> it means that it is likely somebody's already suffered
[06:24] <kiko> and failed to triage
[06:24] <sits> they are already in the right place
[06:24] <kiko> I suggest trying newest first
[06:24] <sits> often have responses
[06:24] <sits> but simply haven't been confirmed
[06:24] <sits> yes that's what I normally do
[06:24] <sits> but the MOTD in #ubuntu-bugs had a link to the oldest first so that's what I went for
[06:24] <kiko> ah
[06:24] <kiko> oldest first == hardest first :)
[06:25] <kiko> at any rate #ubuntu-motu is usually pretty active
[06:25] <sits> ok perhaps I will come back in an hour and try again with newest first
[06:25] <sits> kiko: thanks! I'd just about given up
[06:25] <kiko> yeah. if you need help give me a ping
[06:26] <sits> ok, I need to do some washing up so I'll be back in a bit
[06:26] <sits> kiko: thanks again
[06:26] <kiko> most welcome
[06:36] <jordi> mdke: pingy
[06:37] <mdke> jordi: pongy
[06:39] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug 977 (Commenting on bug should optionally subscribe you) harder, by also adding the checkbox to the status edit forms (r3564: Brad Bollenbach)
[06:39] <Ubugtu> Malone bug 977 in malone "Commenting on bug should optionally subscribe you" [Major,In progress]  http://launchpad.net/bugs/977
[06:40] <jordi> mdke: kubuntu-docs, should approve?
[06:40] <mdke> jordi: what template?
[06:41] <jordi> aboutkubuntu is the only one I see
[06:41] <mdke> jordi: there shouldn't be anything new from kubuntu-docs
[06:41] <jordi> except for this one uploaded yesterday :)
[06:42] <mdke> there is already an aboutkubuntu
[06:42] <mdke> it was approved ages ago
[06:42] <mdke> https://launchpad.net/distros/ubuntu/dapper/+source/kubuntu-docs/+translations
[06:43] <jordi> oh yes
[06:43] <jordi> maybe this one's new
[06:43] <jordi> and it's stuck for some reason
[06:43] <jordi> has the package been uploaded?
[06:44] <mdke> yeah, but no changes to the pot
[06:45] <mdke> it must be because you renamed the old one from about-kubuntu to aboutkubuntu
[06:46] <jordi> i did?
[06:46] <jordi> weird
[06:46] <jordi> I noticed about-ubuntu has a hyphen
[06:46] <jordi> what's correct?
[06:46] <jordi> without, right?
[06:47] <jordi> imported
[06:51] <carlos> kiko: dude, you will really love the new POFileTranslateView
[06:51] <carlos> it sooooo small
[06:51] <kiko> carlos, show me the money
[06:51] <carlos> s/it/it's/
[06:51] <kiko> and show me the UI too!
[06:52] <carlos> the UI should be the same as before
[06:52] <mdke> jordi: the way they were is correct (about-ubuntu, aboutkubuntu)
[06:52] <carlos> in fact the fancy navigator links are the same, we didn't lose anything
[06:52] <kiko> that we need to fixerate
[06:53] <carlos> fixerate?
[06:54] <kiko> cowabunga carlos
[06:54] <kiko> do they not say fixerate in valencia?
[06:54] <carlos> jordi: ?
[06:54] <carlos> First time I see it ;-)
[07:03] <jordi> mdke: ok, they can stay like this
[07:04] <jordi> fixerate
[07:04] <kiko-fud> fixerator
[07:04] <jordi> fixerate is cousing of fixage
[07:04] <jordi> cousin even
[07:04] <kiko-fud> fixaging
[07:11] <rpedro> hi, is there a way to get someone to correct a translation template?
[07:11] <rpedro> here --> https://launchpad.net/distros/ubuntu/dapper/+source/abiword/+pots/abiword/pt/+translate
[07:12] <rpedro> string number 4
[07:23] <carlos> kiko-fud: the navigation errors I fixed is in the POMsgSetPage branch
[07:24] <carlos> rpedro: that's a bug in abiword
[07:24] <carlos> rpedro: we cannot fix it in Rosetta directly...
[07:25] <rpedro> hmm, ok
[07:53] <jordi> heh
[07:53] <jordi> I had already requested the download of the abiword pot
[07:53] <jordi> Rosetta encountered problems exporting the files you
[07:53] <jordi> requested. The Rosetta team has been notified of this
[07:53] <jordi> problem. Please reply to this email for further assistance.
[07:53] <jordi> aha
[08:01] <kiko-fud> carlos!
[08:01] <carlos> kiko-fud!
[08:02] <carlos> jordi: .pot file export is still broken...
[08:02] <kiko> carlos, what's broken with exporting?
[08:02] <carlos> the .pot files are exported empty
[08:03] <carlos> I will add that to my 1-2h slot
[08:03] <kiko> I see. okay. sounds pretty important -- does it affect langpacks?
[08:03] <carlos> no
[08:03] <kiko> ok then
[08:03] <carlos> langpacks are not using .pot files
[08:04] <carlos> but .po files
[08:05] <jordi> so
[08:05] <jordi> my root fs was full
[08:05] <jordi> I apt-get cleaned
[08:05] <jordi> /dev/hda3             9,2G  2,4G  6,4G  27% /
[08:05] <jordi> wtf!
[08:06] <mdke> jordi: supporting the english right?
[08:06] <jordi> mdke: I'll show them my support when they are all apathic and defeated.
[08:07] <mdke> heh
[08:07] <mdke> good chat
[08:10] <carlos> jordi: are you going to see tonight's match?
[08:11] <carlos> Enough for today...
[08:11] <carlos> see you tomorrow
[08:17] <jordi> carlos: yeah
[08:25] <froud> Hi, can we ask Malone questions here?
[08:25] <aa_> I think you just did :)
[08:25] <tumbleweed> lol
[08:25] <froud> smart ass
[08:25] <aa_> sorry
[08:25] <froud> https://launchpad.net/products/ftsoftware/+bugs
[08:25] <aa_> why not though!
[08:25] <aa_> ask ask ask
[08:26] <froud> a few of us can add bugs, but we cant do zip else
[08:26] <froud> yet we are developers
[08:26] <froud> what do we need more to have ability to do more
[08:26] <bradb> froud: What "zip else" are you referring to?
[08:26] <froud> close bugs :-)
[08:26] <tumbleweed> or mark them as confirmed, etc
[08:26] <froud> assign to other developers etc
[08:27] <kiko> froud, tumbleweed: okay. so let me see here
[08:27] <kiko> currently the project is registered by paroz, correct?
[08:27] <froud> yip
[08:28] <kiko> and it uses malone officially?
[08:28] <tumbleweed> well, we don't have any other bugtracker :-)
[08:28] <bradb> froud: just to be clear, are you able to change the status, but it's just not saving? or are you not even able to select a different status?
[08:28] <froud> dunno, must it
[08:28] <sivang> froud: Sean?!
[08:28] <tumbleweed> bradb: not able to select
[08:28] <bradb> ok
[08:28] <froud> cant do anything but add bugs and view them
[08:29] <kiko> froud, what happens when you click on "ftsoftware (upstream)" in the bug UI?
[08:29] <froud> sivang: mienyanim chaver
[08:29] <tumbleweed> heh :-)
[08:29] <sivang> froud: shanim she lo raiti otcha!
[08:29] <sivang> froud: ma kore? :)
[08:30] <froud> kiko: Request fix in a product
[08:30] <sivang> froud: is all good?
[08:30] <froud> page is three fields all blanks, not much sense
[08:30] <kiko> froud, hmm? what URL are you looking at?
[08:30] <froud> https://launchpad.net/products/ftsoftware/+bug/45139/+upstreamtask
[08:30] <Ubugtu> Malone bug 45139 in ftsoftware "remove linux source install from egalax instructions" [Normal,Unconfirmed]
[08:31] <froud> I cant change the status either :-)
[08:31] <froud> perhaps we must have some rights
[08:31] <bradb> you need only be logged in
[08:31] <froud> sivang: nimasli
[08:31] <froud> bradb: we are :-)
[08:31] <kiko> froud, I meant click on the row in the table, not on the + links.
[08:32] <froud> he he
[08:32] <froud> that  looks better
[08:33] <tumbleweed> froud: nod
[08:33] <froud> tumbleweed: if it had teath it would bite :-)
[08:33] <froud> thanks kiko
[08:33] <froud> 10X
[08:34] <kiko> no problems
[08:34] <kiko> it's really invisible
[08:34] <froud> sivang: lo aya po ki nimasli et ha stooyot she kama anashim
[08:34] <froud> kiko: think the us needs to state cange options or something
[08:35] <kiko> froud, it's unfortunate UI. that's the most I can say!
[08:35] <froud> Edit Bug perhaps could link to this page
[08:35] <froud> all good fun
[08:35] <froud> later chaps
[08:36] <froud> sivang: lederber aghar kag
[08:36] <sivang> froud: sure, rock on. are you wroking on the book as well?
[08:37] <froud> I passed it to others
[08:42] <dilys> Merge to devel/launchpad/: [r=Bjorn]  Fixed bug #37078 that prevents Rosetta Experts to handle all fields of a POTemplate. It includes a lot of pagetest improvements (r3565: Carlos Perell Marn)
[08:43] <Ubugtu> Malone bug 37078 in rosetta "+admin page for IPOTemplate is not working for Rosetta experts" [Major,Fix committed]  http://launchpad.net/bugs/37078
[08:43] <kiko> rock on
[08:44] <jordi> yay
[08:48] <kiko> bradb, have you taken the time to check if BDLU is actually working well on staging?
[08:49] <bradb> kiko: no. I'd have to have db access to do so.
[08:49] <kiko> I can issue queries for you if you like.
[08:49] <kiko> I have access.
[08:50] <kiko> if you can verify it'd help me decide about the rollout tomorrow
[08:51] <bradb> kiko: ok. so right now, select count(*) from bug where date_last_update is not null; should be a very low number, like maybe not even double digits, depending on how much people are actually making changes to bugs on staging.
[08:51] <bradb> s/last_update/last_updated/
[08:51] <kiko> one sec
[08:53] <carlos> kiko, bradb: I think anyone has access to staging's database in read only mode from mawson
[08:53] <kiko> I do at least
[09:02] <kiko> bradb, I think you did migration for date_last_updated, didn't you?
[09:02] <kiko>  count
[09:02] <kiko> -------
[09:02] <kiko>  44671
[09:02] <kiko> IIRC you said you would
[09:02] <bradb> stub wrote it, actually
[09:02] <bradb> i just gave him the pseudo-logic
[09:03] <kiko> so what else can I query to verify it's working?
[09:03] <bradb> well, we could change some bugs and make sure they're getting updated
[09:05] <bradb> kiko: i just edited bug #42
[09:05] <Ubugtu> Malone bug 42 in malone "Bug description listed in task is not the correct description" [Normal,Fix released]  http://launchpad.net/bugs/42
[09:07] <bradb> kiko: also just marked #3000 a dupe
[09:07] <bradb> kiko: edited the description on #4000
[09:08] <kiko> yep
[09:08] <bradb> kiko: added an attachment to #5000
[09:08] <kiko> confirmed
[09:09] <bradb> kiko: added a branch to #6000
[09:09] <kiko> so adding the branch didn't update it.
[09:09] <kiko> launchpad_staging=> select id from bug where date_last_updated > '2006-05-17';
[09:09] <kiko>   id
[09:09] <kiko> ------
[09:09] <kiko>    42
[09:09] <kiko>  3000
[09:09] <kiko>  4000
[09:09] <kiko>  5000
[09:09] <kiko> what did you do to 7000?
[09:10] <bradb> added a comment just now
[09:10] <kiko> okay, I have 7000 in the list
[09:10] <kiko> and that's all
[09:10] <kiko> 42, 3000, 4000, 5000 and 7000.
[09:10] <kiko> can you patch up branch addition and show me the diff?
[09:10] <bradb> strange about the branch. hm.
[09:10] <bradb> sure
[09:12] <bradb> I've got adding and editing a branch tested, so my guess is that maybe it's not publishing the right events from the UI.
[09:12] <kiko> right, that's what I was thinking too
[09:12] <kiko> I think we've got some of the factoring wrong because it should all go through some centralized handling
[09:13] <kiko> and it's okay if that callsite is doing it the wrong way and can be updated, but we don't want bandaids
[09:20] <SteveA> carlos: around still?
[09:20] <carlos> SteveA: yes
[09:20] <SteveA> hi
[09:20] <SteveA> so, we're planning a rollout for tomorrow
[09:20] <carlos> hi
[09:20] <SteveA> how's that translation priotity stuff going?
[09:21] <carlos> mark asked for a merge of his branch
[09:21] <kiko> it got dropped
[09:21] <carlos> but seems like it's not done
[09:21] <carlos> I have my sql code in my own branch
[09:21] <SteveA> well, let's get it merged back
[09:22] <carlos> If you want, I can merge any change mark did and resubmit teh merge request
[09:22] <SteveA> yeah
[09:22] <SteveA> or
[09:22] <carlos> so we get my SQL sentences + marks code at the same time
[09:22] <SteveA> you can merge mark's branch in pqm, and merge your stuff
[09:22] <SteveA> as you (or i or anyone) can tell pqm to merge mark's branch
[09:22] <carlos> well, I don't have a DB patch number, I thought I was supposed to merge mark's branch
[09:23] <carlos> so I added it to mark's new db patch
[09:23] <SteveA> but i just heard it was dropped by pqm
[09:23] <kiko> carlos, that's a good way of handling it.
[09:23] <SteveA> that means that there is something to be merged by pqm
[09:23] <SteveA> so there's something i don't understand here
[09:23] <SteveA> carlos: sure, if you don't have a db patch number, then you can hijack that
[09:23] <SteveA> although, your patch could be run on production anytime i think
[09:24] <carlos> my patch is just some SQL code that can be executed at any time
[09:24] <SteveA> cool
[09:24] <carlos> but stub said sometime ago that he wants those kind of sentences included with the code changes
[09:24] <SteveA> ok, that's fine
[09:24] <SteveA> can you get the whole lot into pqm tonight?
[09:25] <carlos> yes
[09:25] <SteveA> great
[09:25] <jordi> this is pretty shocking if you ask me
[09:25] <SteveA> i'll follow up on kiko's rollout email
[09:25] <mdke> spiv: ping?
[09:26] <carlos> kiko: did you review mark's branch?
[09:26] <carlos> to know the value to set to r=
[09:26] <kiko> I did
[09:26] <kiko> I had comments
[09:26] <carlos> ok
[09:26] <kiko> did you see them?
[09:26] <carlos> hmm, I don't think so
[09:26] <carlos> kiko: did mark address it?
[09:27] <kiko> he answered at lest
[09:27] <kiko> what I don't quite understand about priorities
[09:27] <kiko> is that if anybody who owns a template can set them
[09:27] <SteveA> carlos: when you land it in RF, please reply to my email called "Re: Shipit rollout" with the revision number
[09:28] <kiko> then, well, why won't people set priorities of their own templates to 10000
[09:28] <kiko> thus creating a priority war? :)
[09:29] <SteveA> well, the launchpad admins can shit on them
[09:29] <SteveA> carlos: and...
[09:29] <carlos> kiko: well, priorities are only used with distributions, and only rosetta admins are able to edit them ;-)
[09:29] <SteveA> carlos: ROCK ON
[09:29] <kiko> carlos, I thought they were editable by template owners. are you sure?
[09:29] <carlos> SteveA: sure, I will do that (both things ;-)
[09:30] <kiko> SteveA, have you heard A Perfect Circle?
[09:30] <carlos> kiko: not sure, but the lists that uses it is only for distributions and the owners of those templates are the same, rosetta-admins
[09:31] <carlos> the product list is not using priorities or at least the patch I saw was not doing it, not sure if mark changed it later
[09:31] <kiko> carlos, is that because the buildd upload creates them with that owner hardcoded?
[09:31] <carlos> yes
[09:31] <kiko> okay.
[09:32] <carlos> I should gave full access to ubuntu maintainers
[09:32] <kiko> I guess
[09:32] <carlos> and in that case, the war could begin ;-)
[09:32] <SteveA> kiko: nope
[09:32] <kiko> SteveA, maynard's other band. not bad
[09:32] <carlos> fuck....  These guys are used to playing against English people
[09:47] <kiko> bradb, and why can't bug_branch have a hook which makes sure a notify() is called when an attribute is modified
[09:47] <bradb> to the first question, the public API for adding a BugBranch is IBug.addBranch
[09:48] <bradb> to the second one, the same could be asked for any object in the system, and is a really a Zope 3 question. what you're really asking for, i think, is to have a blackbox API to modify an object (possibly many attribs at once) and have it publish the appropriate events.
[09:48] <kiko> hmmm.
[09:49] <kiko> we could have a decorator for public constructors, then?
[09:50] <bradb> interesting idea
[09:50] <kiko> that would ensure that anything standard that needed to be done in them was don
[09:50] <kiko> e
[09:51] <bradb> that might work, yeah
[09:51] <kiko> the decorator wouldn't work for modifications though
[09:51] <kiko> we'd need a metaclass for that most likely
[09:52] <kiko> grumble
[09:52] <bradb> it might be hard to predict how it'll work without trying it though
[09:52] <kiko> does SQLObject not offer a generic "attribute modified" hook?
[09:53] <bradb> you mean "object modified"?
[09:54] <kiko> well, attribute of object modified, but yes.
[09:54] <bradb> also, re: the decorator, it's not quite that simple. there are some constructors, like .createBug, which create multiple objects.
[09:54] <kiko> do they trigger multiple notify()s?
[09:55] <bradb> no
[09:56] <bradb> but, i'm just thinking that maybe there are use cases that do
[09:56] <kiko> maybe.
[09:56] <kiko> a hook would be ideal, really
[09:57] <bradb> the challenge with modification is that you really need to set multiple attributes through an API
[09:57] <kiko> no, no
[09:57] <kiko> if you have a hook you are safe
[09:57] <kiko> you can go on modifying transparently
[09:57] <kiko> a super or metaclass makes sure your hook is called
[09:57] <bradb> how do you know when you're "done" modifying the object?
[09:57] <kiko> do you need to?
[09:58] <bradb> ISTM that you do, so that you know when to fire off the object modified event
[09:58] <kiko> I was thinking you fire off one event per modification
[09:58] <kiko> maybe you are right but I am thinking
[09:59] <bradb> that seems to granular to me. one event per transaction could be interesting...
[09:59] <kiko> yeah but then your hook needs transaction-awareness
[09:59] <kiko> not very easy to do
[09:59] <kiko> or clean
[09:59] <bradb> scary
[10:00] <bradb> in the meantime, this patch is using established patterns (e.g. like linkCVE)
[10:01] <kiko> yeah, I just don't like the pattern at all!
[10:01] <bradb> so it's either right, or correctly wrong
[10:02] <kiko> yeah, it should be right, I just dislike the pattern intensely
[10:02] <kiko> I think it is just an invitation to being permanently incomplete
[10:05] <bradb> I agree that this pattern is unpleasing. I also think it will take considerably thought to come up with a better solution (though I agree that could be time well spent.) In the meantime, can I merge this simple patch?
[10:07] <kiko> yeah, but we still have the original problem.
[10:07] <kiko> this API sucks.
[10:07] <kiko> I /hate/ that we are triggering these events from browser code
[10:07] <kiko> it is just completely broken
[10:09] <kiko> the change to doc/bug.txt is telling
[10:11] <bradb> thinking about the object modification API, things like transitionToStatus should also be considered.
[10:12] <bradb> i.e. more than just a simple foo.bar = 1; foo.baz = 2;
[10:15] <bradb> kiko: here's another crazy idea for an object modified API...
[10:15] <bradb> foo = self.context
[10:15] <bradb> ...do whatever to foo, including calling methods that set attribs, etc...
[10:15] <bradb> object_modified(foo)
[10:16] <bradb> something would have to keep a snapshot of each object created during the transaction
[10:16] <bradb> created/loaded
[10:17] <bradb> when object_modified is called, it could delta the object and publish the modified event, then flush its snapshot cache for that object
[10:18] <bradb> see what i mean?
[10:24] <carlos> ddaa: so, I cannot fill the form: https://launchpad.net/products/elisa/trunk/+source if there isn't a package in Ubuntu for it?
[10:25] <ddaa> I think you can
[10:25] <ddaa> the error message you get after posting is spurious
[10:25] <ddaa> carlos: feel free to fix that nonsense
[10:25] <carlos> oh, right, it's there....
[10:26] <carlos> wtf...
[10:27] <carlos> ddaa: anyway... could you import https://launchpad.net/products/elisa/trunk/ ?
[10:27] <ddaa> I'll give it a go.
[10:27] <carlos> ddaa: thank you
[10:28] <carlos> this Fluendo guys are developing exactly what I'm interested on....
[10:28] <ddaa> grumble annoying ssl thing
[10:28] <ddaa> should fix it one day...
[10:29] <carlos> that means it cannot be imported until you fix it?
[10:29] <ddaa> nope
[10:29] <ddaa> it just means I need to approve the ssl certificate and propagate it around
[10:30] <carlos> oh, I see
[10:33] <jordi> mdke: you are quiet, my friend.
[10:34] <mdke> jordi: *hides*
[10:35] <salgado> ddaa, does https://launchpad.net/products/bzr/+bug/45306 looks like a reasonable request?
[10:35] <Ubugtu> Malone bug 45306 in bzr "LocationConfig should look for options on parent locations when they're not found" [Normal,Unconfirmed]
[10:36] <ddaa> salgado: there's abug open about this very problem already
[10:36] <salgado> argh
[10:36] <ddaa> https://launchpad.net/products/bzr/+bug/33430
[10:36] <Ubugtu> Malone bug 33430 in bzr "Lack of cascading configs cause push to obscure directory settings" [Normal,Confirmed]
[10:37] <ddaa> your bug report has the advantage of giving a real user story
[10:38] <ddaa> I think it's better to rely on prefix matching rather than defaulting to the parent
[10:40] <salgado> you mean parent as in the one that comes up in the config file?
[10:41] <ddaa> I mean that if a config for [/foo/bar]  is not found, then it defaults to the config for [/foo]
[10:41] <ddaa> and so on, recursively
[10:41] <salgado> yeah, this is what I tried to mean when I used parent
[10:42] <salgado> as parent in the directory tree
[10:42] <ddaa> "parent" has a very specific meaning in bzr, be careful
[10:44] <Yannig>  Hello everybody :)
[10:44] <Yannig>  Can I go on with my dumb questions? :D
[10:45] <mdke> Yannig: sure, preferably in a neutral colour
[10:45] <Yannig> Ups, sorry
[10:46] <Yannig> If I go on translating after tomorrow, will the translations be included in next updates?
[10:47] <mdke> Yannig: what in particular are you translating?
[10:47] <Yannig> Everything :p
[10:47] <Yannig> (I'm beginning with Occitan translation and I'm alone for now so it's rather slow)
[10:47] <mdke> oh, cool
[10:48] <mdke> Yannig: well, the packages that don't use language packs will be starting to freeze from tomorrow, and the packages that do will have a bit more time
[10:48] <mdke> if you are concentrating on the installer, you've got another few days
[10:48] <Yannig> Yep, I'm translation debian-installer first (but it doesn't go very fast)
[10:49] <Yannig> translation => translating
[10:50] <mdke> Yannig: after dapper is released, there will be updates with new translations
[10:50] <Yannig> Great :)
[10:51] <Yannig> So I'm not working for nothing :)
[10:51] <mdke> Yannig: no, absolutely not.
[10:51] <carlos> ddaa: seems like elisa's import failed
[10:51] <ddaa> oh
[10:52] <mdke> Yannig: you know, the developer of the installer was saying yesterday that he was happy to see translations from a language that he had never heard of :)
[10:52] <ddaa> sorry, got sidetracked
[10:52] <Yannig> Just 311 955 more strings to reach 100 % translated :D
[10:52] <Yannig> mdke> :)
[10:52] <Yannig> (but I'd like to have other people on it, I'm far from being perfect in this language :()
[10:53] <ddaa> carlos: okay, the test is in progress now
[10:53] <carlos> ddaa: ok, thanks
[11:06] <dilys> Merge to devel/launchpad/: [r=kiko]  Make sure IBug.date_last_updated is updated when an IBugBranch is added or changed (r3566: Brad Bollenbach)
[11:06] <Yannig> Another dumb question :)
[11:07] <Yannig> How can I create<EMAIL_ADDRESS>so as to put it as translators contact?
[11:19] <kikoX> hey bradb
[11:19] <kikoX> have a second?
[11:19] <kikoX> I am curious about one thing in the zcml declaration for bug
[11:19] <bradb> kikoX: sure
[11:19] <kikoX>         <allow attributes="id private bugtasks subscriptions" />
[11:19] <kikoX> bradb can you explain why that is so?
[11:20] <kikoX> I mean, checkUnauthenticated already provides launchpad.View to unauth'd users. right?
[11:21] <bradb> are you asking about a specific attribute, or the allow in general?
[11:21] <kikoX> both.
[11:22] <bradb> the "allow" is there because there are some attributes that are useful to always be accessible, whether the bug is private or not, and whether or not the user is logged in
[11:23] <kikoX> well, the relevant clause in this case is "whether the bug is private or not". but okay.
[11:23] <kikoX> why are these attributes public?
[11:24] <bradb> the id should always be public, as a rule. e.g. if you want to list dupes of a bug, and one of them is private, you still want to have the ID
[11:25] <bradb> same idea with .private. you want to be able to check if a bug is private without raising a ForbiddenAttribute exception on that check
[11:25] <kikoX> kinda okay so far
[11:25] <bradb> .subscriptions, you want to be able to check if the current user is subscribed to the private bug
[11:25] <kikoX> (not so sure about private)
[11:26] <kikoX> ah, really?
[11:26] <kikoX> why is that?
[11:26] <bradb> .bugtasks, I don't recall offhand what code path was using that that made me make it public
[11:26] <bradb> kikoX: the security checker has to check if the current user is subscribed to the bug, to know if they can access it
[11:27] <kikoX> bradb: oh, so the security checker also runs within permission constraints. interesting.
[11:28] <kikoX> thanks, that makes sense.
[11:32] <lifeless> kikoX: ping
[11:32] <lifeless> BASTARDO!
[11:33] <lifeless> (I wanted to talk with kiko about the shipit rollout)
[11:35] <ddaa> duh, importd has so little test coverage it's scary
[11:36] <ddaa> lifeless: got a pair of cscvs branches up for review, including one I put in your queue
[11:36] <salgado> lifeless, he's still at the office
[11:36] <ddaa> (the stuff we talked about your yesterday evening)
[11:36] <dilys> Merge to devel/launchpad/: [trivial]  Change the heading when the user is looking at his current shipit request to make it clear that he's not making a new request (r3567: Guilherme Salgado)
[11:36] <lifeless> salgado: I have his email about the shipit rollout, but I have some questions
[11:37] <lifeless> he says its scheduled for tomorrow - is there a specific time its scheduled for ? Will I need to change my schedule to do it at some weird GMT time ? or is just 'friday' good enough ?
[11:38] <salgado> lifeless, I'd suggest you reply to his email. he's talking with cprov right now, but I'm sure he'll go back at some point and he'll read email before going home today
[11:38] <lifeless> ok
[11:38] <salgado> lifeless, the sooner it happens the better, I think
[11:39] <kiko_> hey lifeless
[11:39] <kiko_> a little birdie told me you were looking for me!
[11:43] <lifeless> kikoX: hey
[11:43] <lifeless> I'm replying to the email
[11:43] <kikoX> lifeless: when I said tomorrow I meant thursday -- so your "today"
[11:43] <lifeless> just a few questions
[11:44] <kikoX> sorry I wasn't clearer -- I seem to have been thorough in parts and overlooked others.
[11:44] <lifeless> is there a specific time you want it done ?
[11:44] <kikoX> as early as possible.
[11:44] <lifeless> like now ?
[11:44] <kikoX> do it!
[11:44] <lifeless> ok
[11:44] <kikoX> was my email helpful?
[11:44] <lifeless> I'm a little rusty on rollout procedures - stub being the rollout king
[11:44] <kikoX> (and what could have helped more, beyond specifying a target date)
[11:44] <lifeless> very helpful
[11:44] <lifeless> I liked the analysis of what is in HEAD vs known good via staging.
[11:44] <kikoX> great
[11:45] <kikoX> I test bug date last updated on staging
[11:45] <kikoX> brad and I found a small omission
[11:45] <kikoX> fix already written
[11:45] <lifeless> uhm, probably not needed in that email, but having a couple of key-contacts named to validate the rollout might be good.
[11:45] <lifeless> i.e. 'This rollout needs to be signed off by Hande before being considered complete'
[11:46] <kikoX> well
[11:46] <lifeless> now, a small check - shipit is served by the normal appsservers,its just a virtual site right ?
[11:46] <kikoX> once rolled out jane and hande will indeed need to sign off.
[11:46] <salgado> btw...
[11:47] <kikoX> but, well, we can't really avoid you having to go to sleep. at any rate I will be in early tomorrow.
[11:47] <lifeless> salgado: yes ?
[11:48] <salgado> lifeless, I just reminded that we need to coordinate some virtual hosting changes with the admins
[11:48] <salgado> nothing we need to worry, though
[11:48] <lifeless> salgado: ah. what happens if we update the codebase withouot that coordination ?
[11:48] <lifeless> does it break anything currently being used ?
[11:49] <kikoX> shipit will break.
[11:49] <kikoX> Znarl: ping?
[11:50] <lifeless> kikoX: I'm just assembling the production tree. can you phone a friend ?
[11:50] <kikoX> I can phone anyone in the world with my daisy red ryder 200 shot air rifle
[11:50] <lifeless> salgado: can you email the required changes to canonical-rt, cc'd to launchpad@ or me@kiko
[11:50] <lifeless> salgado: actually, launchpad@ or me,kiko & stub
[11:52] <kikoX> lifeless, what number?
[11:52] <lifeless> kikoX: znarl or elmo I mean
[11:52] <kikoX> oh.
[11:52] <kikoX> elmo's in mexico.
[11:52] <kikoX> I can call znarl if you like, surely
[11:53] <lifeless> please, lets me focus on the code
[11:53] <lifeless> salgado should have a rt # soon
[11:55] <kikoX> okay, will call as soon as the rt is produced
[11:56] <kikoX> lifeless: should I have znarl coordinate with you via IRC?
[11:56] <lifeless> kikoX: please
[11:56] <kikoX> I will need to skip out in a while, but.. okay. Do you have an ETA?
[11:56] <Keybuk> cprov: ping?
[11:56] <lifeless> I'll be ready in 10
[11:57] <kikoX> okay
[11:57] <kikoX> Keybuk, yo, we're reviewing. what's up?
[11:58] <Keybuk> just wondering whether the cause of the strange "source packages exist for binary packages" problem
[11:58] <Keybuk> found an interesting example
[11:59] <Keybuk> LP thinks there is a "source" for dhcp3-client (which is really a binary built by dhcp3)
[11:59] <Keybuk> but it DOES NOT think there's a "source" for dhcp-client (which is a binary built by dhcp)
[11:59] <Keybuk> now, the only interesting difference between the two is that dhcp has only been sync'd
[11:59] <Keybuk> dhcp3 has been uploaded with ubuntu variations
[12:01] <ddaa> carlos: sorry the test for elisa failed
[12:01] <kikoX> aha
[12:01] <ddaa> carlos: pysvn._pysvn.ClientError: REPORT request failed on '/elisa/svn/!svn/bc/33/trunk/elisa' '/elisa/svn/!svn/bc/33/trunk/elisa' path not found
[12:01] <carlos> what does it mean?
[12:02] <kikoX> Keybuk, so the hypothesis is that the archive publisher creates source package names when it shouldn't.
[12:02] <carlos> other than the import failed...
[12:02] <ddaa> no clue
[12:02] <kikoX> Keybuk, it is particularly interesting that the sync did not create the name.
[12:02] <kikoX> that's a good clue into the codepath.
[12:02] <Keybuk> kikoX: it may not be sync-related, but that's the first example I've found that doesn't have the extra names
[12:03] <ddaa> carlos: apparently, it tried to ls something that does not exist in the repository
[12:03] <ddaa> carlos: which might suggest a corrupt log
[12:03] <carlos> ddaa: they use external repositories links
[12:03] <carlos> not sure its technical name
[12:03] <kikoX> Keybuk, definitely interesting.
[12:04] <carlos> ddaa: they have two trees and when you checkout one of them, you get the other included
[12:04] <ddaa> carlos: that would be the culprit then, I have seen nothing in the code about such a thing
[12:04] <ddaa> ha, I see
[12:04] <ddaa> the equivalent of module configs for CVS
[12:04] <carlos> right