[00:00] <poolie> mkanat: i messaged you
[00:41] <_habnabit> dash, okay, so I'm trying to figure out how to tell bzr about the svn merges that were done in the past. Do you know what svn prop it's supposed to be looking at?
[00:41] <dash> _habnabit: svn:mergeinfo i think.
[00:42] <_habnabit> I have `svn:mergeinfo` set, and it contains accurate infofmation.
[00:42] <_habnabit> Well.
[00:42] <_habnabit> Let me double-check the latter bit.
[00:43] <_habnabit> Does svn:mergeinfo describe merges *into* the branch it's set on?
[00:43] <dash> I forget.
[00:43] <dash> I haven't done merges without bzr-svn
[00:43] <_habnabit> Lucky. :(
[00:43] <_habnabit> I should've done that from the beginning.
[00:43] <_habnabit> This is a mess.
[00:54] <maxb> _habnabit: Your problem is a tricky one. bzr-svn does not directly support it
[00:55] <_habnabit> Ah, balls.
[00:55] <_habnabit> What is bzr-svn looking for?
[00:55] <maxb> Whilst bzr-svn will write svn:mergeinfo for svn to consume, it won't read it
[00:55] <maxb> bzr-svn looks for its own properties, or (I think) svk's style of merge metadata
[00:56] <dash> oh snap, svk.
[00:56]  * _habnabit grumbles.
[00:56] <_habnabit> I'm sure someone's done this before.
[00:56] <maxb> I believe the reason for doing so is that it was deemed overly complex to extract which elements of svn:mergeinfo relate to whole-tree merges, vs individual file ones.
[00:56] <maxb> I'm not sure I agree with that
[00:56] <_habnabit> Ah.
[00:57] <maxb> Especially since having started to work with svn:mergeinfo at my work, we've settled on avoiding subtree mergeinfo whereever possible
[00:58] <maxb> I have explored how to deceive bzr-svn into reading merges a little, but I never really got the procedure working for real
[00:59] <_habnabit> Lordy this is just a horrible mess. If I'd been using bzr-svn from the beginning, or we were using svn 1.5, this would be so much easier.
[00:59] <maxb> I think I'd probably attempt to investigate what form svk merge properties take
[00:59] <maxb> I don't think 1.5 would help
[00:59] <_habnabit> 1.5 has merge tracking.
[00:59] <_habnabit> I just need some way of doing merges that isn't svnmerge.
[00:59] <_habnabit> bzr-svn worked well in the past.
[01:00] <_habnabit> (For other projects.)
[01:00] <maxb> 1.5 has merge tracking, but not in a way which integrates with bzr-svn
[01:00] <_habnabit> Right.
[01:01] <_habnabit> I'm just using bzr as an svn client right now.
[01:01] <mkanat> mwhudson or thumper: Is there anything special I should know about doing a new stable release of loggerhead?
[01:01] <maxb> Ah. I have never tried that. I usually branch from svn into a native bzr branch and work there
[01:01] <_habnabit> Yeah, unfortunately that's not possible.
[01:02] <mwhudson> mkanat: not that i know of
[01:02] <mkanat> mwhudson: Okay, cool.
[01:02] <_habnabit> Basically my work is horrible, horrible, horrible, and I'm cleaning up my predecessors' messes.
[01:02] <_habnabit> Somehow, someone broke svnmerge.
[01:04] <_habnabit> I'm looking at using svk now.
[01:05] <maxb> I strongly advise against using svk
[01:05] <maxb> But svk's metadata might be a way to dupe bzr-svn into seeing merges
[01:05] <mkanat> I think svk is a dead project, from what I've heard.
[01:05] <maxb> Very dead
[01:06] <_habnabit> Right, that's what I'm hoping.
[01:06] <maxb> https://launchpad.net/~bzr-beta-ppa/+archive/ppa/+packages?field.name_filter=bzr-pqm&field.status_filter=published&field.series_filter= I wonder if anyone has any thoughts on these weird bzr-pqm build failures?
[01:11] <maxb> oh, it's not that deep, it's just launchpadlib versions
[01:22] <lifeless> maxb: did you see my reply?
[01:23] <maxb> About testtools? Yes. So I guess I should update my MP for 0.9.7, unless 0.9.8 is going to happen ASAP
[01:25] <lifeless> your mp ?
[01:25] <lifeless> maxb: if its a packaging one, I would say don't bother
[01:25] <maxb> ok
[01:25] <lifeless> I generally do the merge-upstream dance as part of cutting upstream releases.
[01:43] <mkanat> Hey, I think I need to be given permissions to commit to the loggerhead-team repositories.
[01:43] <mkanat> [mkanat@es-compy 1.18]$ bzr push lp:loggerhead/1.18 --use-existing-dir
[01:43] <mkanat> bzr: ERROR: Permission denied: "+branch/loggerhead/1.18/"
[01:43] <mkanat> poolie, or thumper?
[01:43] <mkanat> Or perhaps jam.
[01:44] <poolie> hi mkanat
[01:44] <poolie> maybe you're not in the right team?
[01:45] <mkanat> poolie: I'm in loggerhead-team. Maybe I need to be in another team?
[01:45] <poolie> hm, i'm not sure
[01:45] <spiv> That branch appears to be owned by loggerhead-team.
[01:46] <spiv> And created by mkanat!
[01:46] <mkanat> Indeed.
[01:46]  * thumper looks
[01:46] <spiv> So I think this is one for thumper...
[01:46] <mkanat> Maybe I have to push to the full URL?
[01:46] <mkanat> Or at least, the ~loggerhead-team URL.
[01:47] <thumper> mkanat: you "shouldn't" have to
[01:47] <mkanat> Now it's just hanging, so I'm guessing it might be working.
[01:49] <poolie> hm :)
[01:49] <poolie> and now?
[01:50] <mkanat> Yeah, just hanging.
[01:51] <mkanat> No matter which URL I use.
[01:51] <poolie> try running with -Dhpss and look in the log
[01:53] <mkanat> Okay.
[01:54] <spiv> mkanat: hmm...
[01:55] <spiv> mkanat: If it's hanging, then I think it's a known bug, I'll dig up the number
[01:55] <mkanat> Stops at:
[01:55] <mkanat> 7.541  hpss call:   'BzrDir.open_branchV3', '+branch/loggerhead/1.18/'
[01:55] <mkanat> 7.541               (to bzr+ssh://bazaar.launchpad.net/%2Bbranch/loggerhead/1.18
[01:55] <mkanat> And then starts doing:
[01:55] <mkanat> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
[01:55] <spiv> mkanat: https://bugs.launchpad.net/launchpad-code/+bug/668176
[01:55] <mkanat> spiv: Yep, sounds like my issue.
[01:57] <mkanat> spiv: So I'm taking it that that fix hasn't been rolled out yet?
[01:57] <spiv> So far I think the launchpad-code team are planning to wait for bzr 2.2.2 to be released before deploying the fix.
[01:57] <mkanat> spiv: Okay...so nobody can push new branches until that happens?
[01:57] <spiv> No, it only affects some slightly odd situations.
[01:58] <spiv> Like ones where you need to use --use-existing-dir, I think?
[01:58] <mkanat> Okay. So I'll delete the branch and try again.
[01:59] <spiv> Perhaps a side-effect of your earlier permission denied problem is creating that sort of situation?
[01:59] <mkanat> spiv: Yeah, that sounds very possible.
[01:59] <mkanat> Okay, that worked. :-)
[01:59] <mkanat> Thanks spiv. :-)
[01:59] <mkanat> I still got the __subclasscheck__ warning, but it pushed.
[01:59] <spiv> What caused that permission denied anyway?
[02:00] <mkanat> spiv: I don't know--poolie, did you change something?
[02:00] <spiv> mkanat: huh, interesting.
[02:00] <mkanat> spiv: Oh, wait, maybe it wasn't related to that push, because I'm still getting the messages from somewhere in my console.
[02:00] <spiv> mkanat: oh, the old ssh connection may still be alive.  You may as well kill it.
[02:00] <mkanat> Yeah, I just did that.
[02:00] <mkanat> I'm surprised it didn't get some signal when bzr died.
[02:01] <spiv> There's a reason why it doesn't, but I forget what it is.
[02:02] <mkanat> Okay.
[02:02] <mkanat> Maybe because it's part of a critical section or something?
[02:03] <spiv> No, I think it's just some vexing aspect of how child processes and python interact, or something like that.
[02:03] <mkanat> Ah, I recall something about that, yeah.
[02:04] <poolie> mkanat: i sent a amil with the list of items from our conversation; you can reply if you want to add more
[02:04] <mkanat> poolie: Okay, cool.
[02:25] <poolie> mkanat: hi, thanks
[02:27] <poolie> for the reply
[02:27] <mkanat> poolie: Yeah, no problem. :-)
[02:27] <mkanat> Okay, this may sound silly, but I've never had to do this...is there a way to cherrypick a single revision from a branch and merge it?
[02:28] <poolie> not in a single command
[02:28] <poolie> though it would be good to add that
[02:28] <poolie> but basically just 'bzr merge -c REV_SPEC BRANCH && bzr commit'
[02:28] <mkanat> Yeah, basically, jelmer added an info.py file to trunk on loggerhead, and we should add that to the branch, too.
[02:28] <mkanat> poolie: But that doesn't keep the revision metadata.
[02:29] <mkanat> poolie: So it looks like they're separate revisions when you go to merge again, later.
[02:33] <mkanat> poolie: But that's the only way?
[02:33] <poolie> i'm afraid so; tracking them is not implemented yet
[02:33] <mkanat> poolie: Okay. :-(
[02:33] <mkanat> (We have this problem in a big way in the Bugzilla Project, too.)
[02:50] <_habnabit> Is there a way to automatically resolve conflicts? I was trying to use resolve --action=take-other, but it doesn't seem to do anything.
[02:50] <_habnabit> This is with bzr 2.3b4.
[02:51] <_habnabit> It doesn't remove the conflicted status, and it doesn't change the contents of the file.
[02:51] <poolie> _habnabit: hm, that seems like a bug then
[02:51] <poolie> that is what it's supposed to do
[02:51] <poolie> you may need to give the file name?
[02:51] <_habnabit> I did.
[02:52] <_habnabit> 0 exit code, no output at all even with -v.
[02:53] <poolie> please file a bug tagged 'conflicts'?
[02:54] <_habnabit> Oh, another thing that seems odd.
[02:54] <_habnabit> bzrlib is complaining that its version is wrong, when both bzr and bzrlib are 2.3dev4.
[02:54] <_habnabit> It says '... is version (2, 3, 0, 'dev', 4)'
[02:55] <_habnabit> Aaaand 'bzr version' says 'Bazaar (bzr) 2.3.0dev4'
[02:55] <spiv> _habnabit: I wonder if https://code.edge.launchpad.net/~vila/bzr/638451-malformed/+merge/40567 addresses your conflict problem?
[02:55] <_habnabit> Oh, never mind, that latter issue is me running the wrong bzr binary.
[02:56] <_habnabit> Looking at that ticket, though.
[03:00] <_habnabit> spiv, no, but it does something completely different!
[03:00] <_habnabit> Now I get an InvalidEntryName exception.
[03:03] <spiv> _habnabit: huh.  Sounds like useful feedback to add to that merge proposal, at least :)
[03:04] <_habnabit> I just think it's odd that it's taken this long to add!
[03:04] <spiv> take-other etc are fairly new.
[03:04] <_habnabit> Yes that's what I think is odd.
[03:05] <spiv> Well, it just automates something you can do manually.  It mainly cuts out some tedium.
[03:14] <poolie> hi spiv
[03:43] <_habnabit> Is there a way to see which revisions would be merged by bzr merge, without doing the merge?
[03:44] <fullermd> 'missing' will tell you which revs each side has that the other doesn't, so you can tell from that.
[03:44] <_habnabit> Oh, great.
[03:44] <_habnabit> This reminds me of another thing. Is there a way to mark revisions as 'plz to not merge ever'
[03:51] <mkanat> poolie: Okay, release pretty much done. Is there anywhere else I should announce it besides the bazaar list and on Launchpad itself?
[03:52] <mkanat> s/itself//
[03:52] <dash> _habnabit: Sort of
[03:52] <jam> _habnabit: bzr merge; bzr revert .; bzr commit -m "merging without adding the changes"
[03:52] <dash> yeah that.
[03:52] <_habnabit> Aha okay.
[03:52] <jam> the '.' in revert is significant
[03:52] <jam> it says revert the content, but leave the merge as pending
[03:52] <fullermd> That still _merges_ it, so it's in the history.  But the changes it made aren't in the current (and presumably future) revs.
[03:53] <_habnabit> Great, that should do exactly what I want.
[03:53] <fullermd> So if you don't want to merge it because it contains code you just don't want to use, that's OK.
[03:53] <fullermd> But if you don't want to merge because it has stuff you don't want to be available (IP reasons, giant files, etc), it doesn't work so well.
[03:53] <fullermd> It also means that if you ever merge that branch back into the branch those changes were on, they'll disappear there too.  So if you ping-pong between the branches much, it gets ugly.
[03:54] <_habnabit> I'm using bzr-svn, and it doesn't recognize any merges as having happened.
[03:54] <_habnabit> So this *should* make it think that the merges happened, I think.
[04:02] <poolie> mkanat: you could tweet about it?
[04:02] <mkanat> poolie: Sure, will do now.
[04:02] <poolie> cool
[04:02] <poolie> i'm really  glad we got this rolling again :)
[04:03] <mkanat> poolie: Yeah, me too!
[04:03] <mkanat> poolie: Okay, tweeted.
[04:09] <poolie> abentley: congrats!
[04:09] <abentley> poolie: :-)
[04:10] <abentley> poolie: are you aware of any tools that automate releasing bzr plugins via Launchpad?
[04:12] <poolie> i'm not
[04:13] <abentley> poolie: It seems like we should have written something like that by now.  What do you think of "The Kraken" as a name?
[04:14] <poolie> sure
[04:14] <poolie> there are some scripts in bzr/tools
[04:15] <poolie> and i think something slightly related in hydrazine, to do uploads
[04:16] <abentley> You mean hydrazine uploading the tarballs?
[04:24] <mkanat> abentley: How does pipeline relate to loom?
[04:25] <abentley> mkanat: pipeline is what I wrote when I found looms frustrating to use.
[04:25] <mkanat> abentley: Cool. I've found them frustrating as well, sometimes.
[04:27] <abentley> mkanat: They don't introduce any new concepts like threads.  A pipeline is just an ordered list of branches.
[04:28] <mkanat> abentley: Okay. Are they colocated?
[04:28] <abentley> mkanat: They don't overload the meaning of push, either.  Instead there's a new sync-pipeline command.
[04:28] <abentley> mkanat: No, they're just sibling branches by default.
[04:29] <mkanat> abentley: Okay. I suppose I could just try it out instead of asking you. :-)
[04:30] <abentley>  mkanat: They could be combined with colocated stuff, but I haven't done that yet.
[04:30] <mkanat> abentley: Okay.
[04:31] <mkanat> I found a few things particularly confusing or difficult about looms. Like trying to remember which directory I had which loom set in, for one.
[04:31] <mkanat> And then that they would permanently loomify your branch.
[04:31] <mkanat> And then certain weird and unexpected things about moving up or down threads.
[04:32] <abentley> mkanat: Right.  With pipelines, the format is always a standard Bazaar format.
[04:32] <mkanat> Coo..
[04:32] <mkanat> *Cool.
[04:33] <abentley> mkanat: You can switch between pipes with the normal bzr switch command, or with "switch-pipe" which will auto-shelve your uncommitted changes.
[04:33] <mkanat> Sweet.
[04:34] <abentley> mkanat: The weird up-thread behaviour is a separate "pump" command in bzr-pipeline.
[05:49] <jtv> I guess my repo is broken; see bug 673439.  Could anyone help me get back on my feet again?
[05:49] <jtv> Thank you ubot
[05:49] <lifeless> abentley: switch in looms doesn't do up-thread either, fwiw
[05:52] <jtv> spiv: last time you fixed me up IIRC… would you mind doing it again?  :)  Can I just remove the broken file?
[05:53] <jtv> Got matching cix, iix, rix, six, and tix files all empty.
[05:59] <jtv> lifeless: I hear you're pretty good with bzr… if I have a tuple of empty cix, iix, rix, six, and tix files in my repo, can I just delete them or something along those lines?
[05:59] <jtv> (imagine a smiley after that first sentence)
[06:13] <lifeless> uhm
[06:13] <lifeless> so that means you had a system crash without the content getting flushed
[06:13] <lifeless> the canonical answer is restore from backup
[06:14] <spiv> jtv: hi
[06:14] <lifeless> you may be able to rollback a single transaction if there is a .old pack-names file
[06:14] <jtv> hi spiv
[06:14] <lifeless> jtv: however I'm being called to the kitchen... and I'm not working today so I have no excuse :)
[06:14] <glyph> https://bugs.launchpad.net/bzr/+bug/673884
[06:15] <spiv> lifeless's advice is (of course) good.  If there isn't an old pack-names file you may be able to recover by cutting the broken pack out of pack-names.
[06:15] <jtv> lifeless: backup, you say?  Physically out of reach for the foreseeable future.  :-(
[06:15] <spiv> glyph: https://code.edge.launchpad.net/~maxb/bzr/2.2-close-ssh-subprocess-socket/+merge/40493
[06:16] <abentley> lifeless: true, but AIUI mkanat finds up-thread vs down-thread confusing, and pipelines doesn't have that kind of quasi-similar command.
[06:16] <glyph> spiv: is that a fix for it?
[06:16] <spiv> glyph: oh, dpush, not dput :)
[06:16] <glyph> gah what's dput
[06:16] <mkanat> abentley: I don't know if I find that confusing, actually.
[06:16] <spiv> glyph: a debian package archive thing, forget I mentioned it!
[06:16] <dash> not a bzr command. :)
[06:16] <mkanat> abentley: up-thread and down-thread as concepts are fine, it's that sometimes I want to switch between looms without all the merge craziness.
[06:16]  * spiv looks more closely
[06:17] <glyph> spiv: It's a pretty obvious bug, sorry for the somewhat obtuse description.
[06:17] <mkanat> abentley: Or I want to switch all the way down in one command.
[06:17] <abentley>  mkanat: so, you can always do both those things.
[06:17] <spiv> glyph: yeah, that looks like a reasonable bug to me.
[06:17] <mkanat> abentley: Also, when I push some of the lower threads into the repository but not the upper ones, the combine-thread functionality is annoying, often.
[06:17] <glyph> spiv: As bzr bugs are wont to do, it showed up immediately in the middle of trying to demonstrate to a co-worker why bzr is great :(
[06:17] <abentley> mkanat: you do down-thread [THREAD]
[06:18] <abentley> mkanat: even if the thread you want to switch to is higher.
[06:18] <spiv> glyph: and probably fairly easy to make better in many cases (and maybe even not too hard to make good in tricky cases, like e.g. local system crash/power drop during dpush).
[06:18] <spiv> glyph: s/bzr/all software/ ;)
[06:19] <glyph> spiv: yeah.  thanks :)
[06:19] <glyph> spiv: I am planning to use dpush increasingly heavily, so it'd be great if it worked right :)
[06:19] <glyph> In the meanwhile, is there any sensible way to do a cherry-pick which preserves log messages?
[06:23] <spiv> glyph: use rebase to do the cherrypick, maybe?  :/
[06:23]  * spiv hmms
[06:23] <glyph> spiv: is that a thing you can do?
[06:23] <glyph> spiv: That was actually my first thought.
[06:25] <spiv> glyph: another option would be to write a plugin to add a log format that output the commit message (and only the commit message), and then you could do "bzr merge -c NNN && bzr log --format=msg-only > commit.msg && bzr ci -F commit.msg"
[06:25] <lifeless> mkanat: in a loom you can use 'switch'
[06:25] <spiv> glyph: (or abuse the existing xmloutput plugin or something like that for the same purpose)
[06:25] <lifeless> mkanat: to avoid all that
[06:25] <mkanat> lifeless: Ah, okay.
[06:26] <lifeless> switch thread-name
[06:26] <lifeless> mkanat: could you file bugs though where things are unclear
[06:27] <lifeless> mkanat: including what it is about combine-thread thats annoying
[06:27] <mkanat> lifeless: Yeah, if I can quite figure out what I don't like, I will.
[06:27] <glyph> spiv: while that would be useful, I was hoping not to write that shell for-loop for every revision :)
[06:27] <lifeless> mkanat: even if you don't have that figured out
[06:27] <lifeless> mkanat: bug reports are about symptoms, not answers.
[06:27] <spiv> glyph: *nod*
[06:29] <spiv> glyph: rebase may be the right tool here, but it's just not something I've used much at all so I don't know the limitations and nitty gritty details of using it for stuff like this.
[06:29] <spiv> lifeless: I know you aren't here
[06:30] <spiv> lifeless: but you may be interested to know that doing working on making branch etc fetch all the tags as well as the tip is pushing me towards other improvements that have the side-effect of chipping off a few hpss round trips.
[06:34] <glyph> spiv: thanks for the classification
[06:48] <A117> bazaar explorer failed to run on XP
[06:49] <A117> any help plz?
[06:50] <spiv> A117: please file a bug at <https://bugs.launchpad.net/bzr>.  Hopefully someone that knows more than me about bzr-explorer and/or XP will be able to help you here too.
[06:51] <spiv> A117: also, give a bit more detail about your problem... in what way did it fail?  What were you trying to do when it failed?  What installer did you use?
[06:59] <A117> instaler for windows. error message is bzr
[06:59] <A117> CreateProcess failed; code 2
[06:59] <lifeless> spiv: thats great
[07:00] <lifeless> spiv: there's stuff in loom that badly needs your love in the same way
[07:00] <lifeless> spiv: using the same multi head improvements
[07:01] <lifeless> spiv: I had the idea of having a get_refs() call to find out what heads to fetch
[07:02] <spiv> lifeless: yeah, it'd be nice to give loom some love... I should make some time.
[07:02] <lifeless> spiv: I hear udd would cover it
[07:02] <lifeless> :)
[07:02] <spiv> :)
[07:18] <GaryvdM> Morning all.
[07:18] <GaryvdM> Bla- Just missed A117
[07:37] <peitschie> (a very late hiya GaryvdM :)  )
[08:13] <stefanlsd> hihi
[08:14] <GaryvdM> Hi stefanlsd
[08:16] <stefanlsd> Anyone familiar with bzr merge-package and what happens with the debian/changelog. seems like its ignored?
[08:21] <maxb> stefanlsd: Ignored? No, but it is processed with a custom merge tool that understands the format of debian/changelog entries and sometimes does things rather differently to what you might expect if you were expecting a textual merge
[08:23] <stefanlsd> maxb: aah ok. yeah, i actually see it was more intellegent than i expected. thanks
[13:57] <figure002> hello! I'd like to use parts of the text in http://doc.bazaar.canonical.com/bzr.2.1/developers/HACKING.html for my own Sphinx documentation, is this allowed?
[13:59] <james_w> figure002, it should be, but I can't remember what license it is under
[14:00] <figure002> ok, and if it is allowed, can someone tell me how to give the credit?
[15:13] <vila> figure002: in what context do you want to re-use it ? (Keeping in mind that GPL is more about distribution than use)
[15:23] <figure002> vila: i'm developing a python app for analyzing biological data for a small biological company. i'd like to use parts of that documentation for the Developer Guide of my application.
[15:24] <vila> figure002: so you intend to distribute the result ? Undr which license ?
[15:25] <vila> figure002: We're talking about distributing your developer guide here
[15:25] <figure002> vila: the app is GPL3, so i would use the same licence for its documentation
[15:26] <vila> ha, if it's GPL I see no objections on principle, now the differences between v2 and v3 are... way beyond my legal knowledge :)
[15:26] <vila> you could try to get in touch with poolie (see https://launchpad.net/~mbp), but I think it's ok
[15:26] <figure002> vila: haha, also, i mailed Canonical a few minutes ago about this
[15:27] <vila> figure002: even better
[15:27] <vila> figure002: nice of you to do that anyway :)
[15:27] <figure002> vila: so according to you, that documentation is licensed under GPL also?
[15:27] <figure002> vila: :)
[15:29] <vila> figure002: honestly, I don't remember. There have been discussions about which license should be used but I don't remember the specifics, I'm 75% sure it is GPLv2 though
[15:29] <figure002> vila: ok
[17:00] <vila> figure002: see bug #433734
[17:01] <vila> argh urgh too late he left :(
[17:10] <vila> mgz: ping, I'm finally reviewing lp:~gz/bzr/cleanup_testcases_by_collection_613247 again
[17:10] <vila> mgz: far cleaner than I remember overall !
[17:11] <vila> mgz: running it locally with --parallel=fork I have a *huge* number of uncollected test cases (still running)
[17:12] <vila> mgz: it's also running on babune as http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/98/aggregatedTestReport/ so you'll get a bunch to eat ;)
[17:12] <vila> mgz: more than 11000 uncollected, surely this is a shallow thing, any subset I could try to focus ?
[17:13] <vila> mgz: right, it looks like *all* tests are uncollected
[17:14] <vila> bah, and the babune run seems to be exhibiting yet another subunit stream leak :(
[17:15] <vila> mgz: I'll abort the babune runs, forget about them
[17:16] <vila> mgz: ha right, the local run finished, 7 failures, all in bzrlib.tests.test_selftest.TestUncollectedWarnings
[17:17] <vila> mgz: re-running without --parallel seems to exhibit the same behaviour :-/
[17:18] <vila> only slower :)
[17:18] <vila> mgz: ./bzr selftest -s  bzrlib.tests.test_selftest.TestUncollectedWarnings => 7 failures
[17:19] <vila> ok, so I'm definitely speaking alone tonight, I'm going to copy that to the mp instead :)
[17:28] <GaryvdM> vila: some of us are listening :-) Unfortunately I can't add much to the discussion.
[17:32]  * fullermd isn't listening, if that helps   :)
[17:35] <vila> :-D
[19:19] <lifeless> mgz: shiny new in testtools ;)
[19:51] <vila> lifeless: s/propogate/propagate/ no ? (at least 4 occurrences), raises_value_error is cute, make_error is brilliant and deserves a comment, hehe game of the day: make test_KeyboardInterrupt_matched fail :D
[19:52] <lifeless> vila: interesting... python 2.4 I bet ?
[19:52] <vila> lifeless: no no it succeeds, no problem but *how* can you make it fail ?
[19:54] <lifeless> if you revert a few commits, and put the test back in, it will fail
[19:54] <vila> if you type ctrl-C at the right time too ;)
[19:54] <lifeless> no
[19:54] <lifeless> there are two cases
[19:55] <lifeless> either you trigger k-i within the block its expected
[19:55] <lifeless> in which case (sadly) it will be ignored
[19:55] <lifeless> or you trigger it outside it, in which case it will propagate :)
[19:55] <lifeless> and the test run will abort
[19:56] <vila> ah right, silly me, if you catch *my* k-i you will won't trigger yours, but one is still happening, rats, too bad ;)
[19:56] <vila> s/will//
[19:59] <vila> lifeless: I wish our stable ppa was used in the pqm chroot so we can rely on updating pqm when updating our stable ppa (which should be fine since it's our best validated bzr version after all), that would ensures a broad and correct deployment of testtools...
[20:00] <lifeless> why don't you do that then ?
[20:00] <lifeless> or something analogous
[20:00] <vila> what more can I do than adding my last comment on rt 41340 ?
[20:01] <vila> lifeless: you mean by using a private testtools updated by the makefile ?
[20:01] <lifeless> no
[20:01] <vila> then what ?
[20:02] <lifeless> have a ppa with the stuff in it that gets used.
[20:02] <lifeless> e.g. the CAT ppa, perhaps.
[20:02] <vila> CAT ? url ?
[20:03] <lifeless> I don't have it offhand
[20:03] <lifeless> is the sysadmins ppa
[20:04] <vila> meh, why would I have more control an this than on pqm which currently is == 0 ?
[20:04] <vila> s/an/on/
[20:05] <lifeless> You could have its contents auto deployed to pqm
[20:05] <lifeless> or a dedicated ppa
[20:05] <lifeless> I dunno, I'm offering suggestions.
[20:05] <lifeless> I think you'll find they deploy testtools from the CAT ppa anyhow
[20:05] <vila> but why isn't our stable ppa valid for that ?
[20:05] <vila> ha, that's interesting then
[20:06] <lifeless> vila: I don't know - have you discussed this with tom ?
[20:06] <vila> hmm, at least using our private one could serve as a temporary workaround
[20:07] <vila> lifeless: no, I'm asking for feedback but Chex told me the losas are in a degraded mode these days
[20:07] <lifeless> this week for sure
[20:07] <lifeless> hol-i-days
[20:08] <vila> geez, yeah, Valentine told me today was one here... and that was why she was a t home (ooooooops :)
[23:44] <poolie> hi jam, spiv
[23:46] <spiv> Hi poolie
[23:50] <poolie> i'm going out to give blood in a bit, will be back later
[23:51] <poolie> then i'm going to see about finishing my outstanding branches and graphing packages built from branches
[23:56] <spiv> I'm going to keep working on fetching all tags as well as tip when doing e.g. 'bzr branch'.  There's an incremental step towards that, fixing sprout to open & lock branches/repos once, that I have passing tests but want to polish.
[23:56] <poolie> k
[23:56] <poolie> i liked seeing the hpss ratchet go down
[23:56] <poolie> and locking just once would be very nice
[23:56] <poolie> ok, biab
[23:56] <spiv> I also need to figure out what to do with <https://code.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406>, perhaps just landing on trunk and not 2.2 is the way forward for that.
[23:57] <spiv> Yeah, the fix to sprout knocks one of the hpss ratchets down by another two calls :)


[17:16] <AnhVoMSFT> rharper - regarding your comment on this PR https://github.com/canonical/cloud-init/pull/880#discussion_r617733841 - those netdev mounts are in /etc/fstab, they should have their own .mounts unit and don't really rely on the mount -a command within init phase to get mounted
[17:16] <AnhVoMSFT> the mount -a is really only introduced recently (about a year) to deal with the case where cloud-init re-partition the ephemeral disk (upon discovering that new ephemeral disk was added when vm was started/stopped) and /etc/fstab was changed
[18:54] <rharper> AnhVoMSFT: are you suggesting they are in /etc/fstab prior to boot?
[18:55] <rharper> AnhVoMSFT: the mount -a is needed for any new mount that cloud-init adds due to the mounts: user-data;  on Azure you supply a default mounts data; but users are perfectly capable of providing their own as well (or instead of); in which case, systemd's fstab generator has not *yet* seen those entries in fstab that cloud-init writes in cc_mount.py;  hence the need for a mount -a
[19:13] <AnhVoMSFT>  rharper: the issue are mostly relevant for reboot. So yes, the mounts are in /etc/fstab prior to boot
[19:13] <AnhVoMSFT> the mount -a during reboot will try to mount those netdev mounts which will cause boot hang, since it's too early for netdev mounts
[19:32] <rharper> yes, I certainly see the -O no_netdev in the mount -a being useful, but I thought we checked fstab for entries added only ... we wouldn't call mount -a unless we have new mounts not in fstab ?
[19:34] <rharper> AnhVoMSFT: ^
[20:24] <tkonto> Hi all. not very familiar with cloud-init just following a hint from friend. I have a gold image of RHEL7 on which I need to change IP address, Hostname, and multipath.conf prior to cloning it 18 times. There is no cloud or Virtualization provider involved here. Just a machine and the disk image. Alter the image, deploy the new OS
[20:24] <tkonto> Could cloud-init be useful on that? For the IPaddr/Hostname for sure.. what about multipath.conf?
[20:32] <rharper> tkonto: hey, cloud-init doesn't have a config modules for multipath.conf built-in;  however, it has some primitives you could use; though it wouldn't help you get your rootfs together;
[20:33] <rharper> tkonto: but if you're templating an image that doesn't need to change at runtime, you might look at packer;  cloud-init is typically used at runtime to inject config during boot;
[20:36] <rharper> tkonto: if you still end up using cloud-init; and if you can do boot time modifications to multipath.conf (for not rootfs disks I would guess) then , you can use cloud-init's write_files to send a specific file, or runcmd if you have a shell program you want to use to modify the config.


[04:38] <ddaa> lifeless: okay, knits upgrade started
[04:38] <ddaa> I reduced the max number of job per slave to 3, to avoid running out of memory
[04:39] <ddaa> also hacked a better bzr BatchProgress so long conversions will not time out
[12:22] <sabdfl> good work ddaa
[12:22] <sabdfl> so, what's up with staging? where's the log?
[01:51] <lifeless> sabdfl: I think its a code skew issue of some sort
[01:51] <lifeless> possible the new zope
[01:52] <lifeless> I'm digging
[01:52] <lifeless> db looks completely fine to me
[01:58] <mhb> hello
[02:00] <mhb> I hope this is the right place to ask ... I would like to know when we finally be able to translate Edgy Eft into local languages
[02:00] <mhb> I asked at the ML ubuntu-translators, but sadly, nobody replied
[02:05] <lifeless> sabdfl: making progress, it is db.
[02:05] <lifeless> something has borked the permissions on the karma cache
[02:06] <mhb> or can you recommend me another IRC channel or mail address where I can get a reply, please?
[02:12] <lifeless> mhb: hi
[02:12] <lifeless> the folk who know are usually here
[02:12] <lifeless> but its middle of the weekend
[02:13] <lifeless> I would not expect a reply until moday
[02:13] <mhb> lifeless: oh well
[02:14] <lifeless> you can try #rosetta, #ubuntu-devel, or the launchpad-users mailing list
[02:14] <lifeless> mailing lists are usually the best place
[02:14] <lifeless> and the ubuntu-translators list is definately the right place
[02:14] <mhb> nobody replied for more then a week or so
[02:14] <lifeless> how long has your message been unanswered on that list ?
[02:14] <mhb> than
[02:14] <lifeless> I suggest mailing again
[02:14] <lifeless> sorry I cant offer better than that
[02:15] <lifeless> pitti *may* know, or carlos, but neither are around just this minute
[02:15] <mhb> lifeless: if you meet someone who's responsible for Rosetta, tell him to check the ubuntu-translators list mor often :o)
[02:18] <mhb> lifeless: well I guess mailing the same question to the same ML won't help a lot
[02:18] <lifeless> seriously, it may well help
[02:18] <lifeless> sometimes things get dropped
[02:18] <mhb> I'll check the archive
[02:19] <mhb> Thu Jul 27 17:58:39 BST 2006
[02:20] <mhb> a *lot* more than a week :o) the question is here, btw: https://lists.ubuntu.com/archives/ubuntu-translators/2006-July/000743.html
[02:23] <kiko-afk> mhb, I know that edgy translations will be open RSN
[02:23] <kiko-afk> carlos has been working on updating the database to allow for it
[02:27] <mhb> kiko-afk: thanks
[02:28] <mhb> kiko-afk: I can't believe that, though ... the first time I asked this question was about a month ago, at 10th of July
[02:29] <mhb> kiko-afk: 15:39 < carlos> mhb: after that I will test it and try to move it into production... I guess we could say one week or so
[02:29] <kiko-afk> mhb, so I was unaware of this issue myself back then
[02:29] <kiko-afk> mhb, but I became aware of it last week
[02:29] <kiko-afk> I think that this has been very poorly communicated, but I do think it is on-track (i.e. it will not be delayed forever)
[02:29] <kiko-afk> mhb, I'll have carlos update me and then /I'll/ post to ubuntu-translators.
[02:30] <mhb> ok, thank you
[02:30] <mhb> I'm sorry, but it disappoints me when someone says "a week" and nothing happens for more than a month
[02:31] <kiko> mhb, well, I agree that the communication has been bad, but I think they ran into more problems than expected (as usual with complex software). you should still have been updated though.
[02:34] <mhb> kiko: it's more painful for me because some of the Czech translators asked me about it and I (as one of the Administrators on that team) promised them to ask someone in charge of that
[02:35] <kiko> mhb, IKWYM. I think you can tell them that:
[02:35] <kiko> a) the changes to the DB were more complicated and took longer than expected.
[02:35] <mhb> kiko: so when nothing happened even though I told them otherwise, the blame goes to Ubuntu as a whole and myself
[02:35] <kiko> b) there will be changes done while Launchpad is offline next tuesday that relate to this, and it shouldn't take long from then
[02:36] <kiko> c) regardless, I'll post to ubuntu-translators to update you guys on how things are going
[02:36] <kiko> d) don't loose faith, it's tough at spots but we are really working hard to make this the best translation tool. ever.
[02:36] <kiko> mhb, just hang in there until monday
[02:38] <mhb> kiko: tell me, will there be a search for a specific word/sentence through all of Rosetta ?
[02:39] <mhb> kiko: that's what practically *every* person I showed Rosetta to asked about
[02:39] <kiko> mhb, it's one of the earliest planned features, so yes, it will happen. we discussed it in cape town in february 2005! I know it's a top requested feature
[02:39] <kiko> the problem with it is that that when we did experiment with that search it brought the servers to a halt ;)
[02:40] <kiko> so we've been considering ways of making it faster -- we're talking matching through millions of strings. lots of data.
[02:40] <kiko> let  me check on one thing.
[02:42] <mhb> kiko: IMVHO the first thing that comes to my mind with all these delays and features is the fact that Rosetta is closed-source application
[02:43] <kiko> hey
[02:43] <kiko> if you have volunteers that are interested in getting their hands dirty we have arranged code access in the past.
[02:43] <kiko> however, it's not easy work -- so don't expect the search feature, for instance, to be change 50 lines and hooray! :)
[02:43] <mhb> kiko: I know volunteers that refuse to work on it UNTIL it gets open-source
[02:43] <kiko> (if it was it would already have been done)
[02:44] <kiko> heh
[02:44] <mhb> kiko: like me, for instance
[02:44] <kiko> well, we've all got our opinions.
[02:44] <kiko> but
[02:44] <kiko> I should make it clear that this product is /really/ being worked on /for you/. there is no agenda other than building the best collaboration tool for open source
[02:45] <kiko> there are a number of reasons it's not free software yet. but it will be when the time comes
[02:46] <mhb> kiko: maybe we could define a "closed approach" - that's an approach when you can't answer the question directly and precisely
[02:47] <kiko> I don't understand what you mean.
[02:48] <mhb> kiko: an "open approach" is when the distribution says that it will 99% come out at 6.10 and I can trust it.
[02:48] <kiko> come out?
[02:48] <kiko> oh, the date.
[02:48] <mhb> get released
[02:48] <kiko> and a closed approach?
[02:50] <mhb> kiko: the "closed approach" uses words like "ASAP" and "when the time comes" ... and furthermore they avoid the direct answer why so
[02:50] <mhb> kiko: take Vista, for instance - nobody except the core devs know *exactly* why it got delayed
[02:50] <kiko> sorry, are you implying that I am avoiding direct questions?
[02:51] <mhb> kiko: I feel some of your/Canonical's answers are more "closed" than I'd like them to be
[02:52] <kiko> look, I can't tell you exactly why this has been delayed because I don't know myself, but I /can/ ask and then post you a summary with a good estimate of when it will happen. don't ask a developer when a feature will be ready because he will always get it wrong. ask me.
[02:53] <kiko> the difference to an open source project is yes, you can't see what the commits contain, and that open source projects don't really make date commitments for features.
[02:53] <kiko> but you do see what every individual commit was about
[02:54] <kiko> and we do make date commitments, which makes us prone to slipping from time to time.
[02:54] <mhb> kiko: IMHO with every slip you lose a bit of the community support
[02:55] <kiko> mhb, yeah, you're right.
[02:58] <kiko> we just need to do better.
[02:59] <mhb> kiko: Rosetta slipped 3 times for me - lack of the most wanted feature for quite some time, closed-source and now the delays
[03:00] <mhb> kiko: a lot of people leave our team because they feel they don't have anything to do
[03:01] <kiko> mhb, that's interesting. is Dapper fully translated into czech?
[03:01] <mhb> kiko: nope
[03:01] <kiko> hmmm. I don't understand what you mean then.
[03:01] <mhb> kiko: you keep adding new features into Dapper?
[03:02] <kiko> the strings you add to dapper will be inherited by edgy, and by future releases
[03:02] <mhb> kiko: nope, and we do not keep adding translations into the Dapper applications - and if we do, we do it in upstream
[03:03] <kiko> and dapper will be around for a long time, so getting dapper language packs better and better will definitely promote better translation of software in general to czech.
[03:04] <mhb> kiko: you might know why we do *not* recommend to translate any GNOME/KDE/other non-ubuntu-specific tool in the Dapper rosetta page
[03:04] <mhb> because it's a waste of time - when you translate it in upstream, you help GNOME/KDE itself, not just one release of one distribution
[03:05] <kiko> that's not very true. upstream can pull automatically newer translations from Launchpad, and definitely everybody benefits with more strings translated than with less strings translated.
[03:05] <kiko> you seem to be making an odd point
[03:05] <kiko> you say your team has nothing to do
[03:06] <kiko> and yet you are unwilling to suggest to them to translate strings in dapper, the majority of which are going to be the same strings as in edgy.
[03:06] <mhb> kiko: do you know any larger project that uploads translations from Launchpad?
[03:06] <kiko> and which we make freely available to any upstream.
[03:06] <mhb> kiko: maybe I'm wrong, but  both KDE and GNOME doesn't
[03:07] <mhb> kiko: they use their own translations, we can modify them in Rosetta, but they won't get back to them
[03:07] <kiko> I know that individual projects definitely do, and that KDE and GNOME don't do it as policy because such policy would be controversial at best
[03:08] <kiko> so yeah, we should better relate to upstream. many of them don't even know they can download the translations.
[03:08] <kiko> (but even individual translators can, merging them with the current translations and then committing)
[03:10] <mhb> kiko: I talked to both the main KDE and GNOME coordinator for the Czech language. They refuse to upload anything if we don't send the files to them by hand in the way they want it
[03:11] <kiko> that's interesting. and what is "the way they want it"?
[03:12] <mhb> kiko: for example,  send the *exact* .po file that is in CVS/SVN with the new translations to them via email
[03:12] <kiko> mhb, but it's easy to do so. download the rosetta version, and run the merge commands with the current version.
[03:13] <mhb> kiko: is it possible to download .po files directly, not through the slow librarian app?
[03:13] <kiko> we also do the upstream imports for a reason: our intention is to track CVS/SVN translations and offer pre-merged translations for them.
[03:14] <mhb> kiko: and don't you think translators want actually to translate, don't they expect the tools to do the administrative work for them?
[03:14] <kiko> heh. yeah, users do expect Rosetta to do everything for them. and we're trying
[03:14] <kiko> mhb, the librarian is not particularly slow -- it's just a fileserver. however, what you want is something like /products/ubuntu/+source/evolution/+pots/evo/download-latest
[03:14] <kiko> which automatically redirects you to the latest copy of the translations output by rosetta
[03:15] <kiko> mhb, let me stop chatting now and summarize what your concerns were so that we can give you an acceptable answer by monday. otherwise I will invest all my saturday into chatting but not fixing the things that are annoying you.
[03:15] <mhb> kiko: OK
[03:16] <kiko> man my wrist hurts today
[03:17] <mhb> sorry for that .o)
[03:18] <kiko> nothing to be sorry about, if the tool is annoying then you should indeed complain, and I should indeed do something about it
[03:20] <mhb> so: we would like to know a date, possibly the exact date when we can start translating edgy. I think if you want to be a friend with the translators in the future, notify them in the ubuntu-translators about almost everything - new features in Rosetta etc.
[03:21] <mhb> everything that is related to them, of course
[03:21] <kiko> mhb, okay, I'll add the weekly rosetta update excerpt and send it to them.
[03:21] <kiko> so you'll receive one this tuesday. and please comment on them if they are unclear or poor, I'll make sure to clarify
[03:22] <mhb> okay
[03:22] <kiko> mhb, is there anywhere else I should post these updates?
[03:22] <kiko> they have a highlights section
[03:23] <kiko> and then a detailed list of the individual commits and what they did
[03:24] <mhb> kiko: I don't know if someone else needs that
[03:24] <kiko> yeah, I don't know either. it's hard to decide when you're being annoying
[03:25] <mhb> kiko: please, tell me - who do you get feedback for Rosetta from?
[03:26] <kiko> mhb, carlos, danilo and SteveA are the people directly responsible, though I do work on Rosetta as well when I have time
[03:26] <mhb> kiko: I mean more of a user feedback
[03:26] <kiko> oh
[03:27] <kiko> to be honest, I mainly get feedback through bugs. we're not very good at keeping an eye on the many lists out there. we're trying this month to start keeping better track
[03:27] <mhb> kiko: where and how many people should shout "we want this feature" so that someone responsible will realize this?
[03:27] <mhb> :o)
[03:28] <kiko> mhb, filing bugs is useful, and you can forward them directly to me<EMAIL_ADDRESS>if you think they didn't get proper traction
[03:28] <mhb> kiko: OK
[03:29] <kiko> and /do/ forward them
[03:29] <kiko> because they will get traction
[03:30] <mhb> so I should file a bug about "Rosetta should be more upstream-developer-friendly" ?
[03:30] <mhb> especially KDE and GNOME
[03:30] <kiko> I think there are generic bugs like that. the best bugs are those that request very specific features that aid in that
[03:30] <kiko> I think there is even a bug to offer a permanent download link
[03:32] <mhb> off-topic: there are more issues than just the hard communication
[03:32] <kiko> heh. indeed. most of the issues are related to writing code! :)
[03:32] <mhb> for example KDE and GNOME have sometimes a different translation of a specific term
[03:33] <kiko> yes, right
[03:33] <kiko> the right way to handle that
[03:33] <kiko> is to have an order of precedence for translations
[03:33] <kiko> and to allow people to easily review the translations being inherited from other projects
[03:34] <kiko> so for instance KDE translations would prefer to inherit from other KDE products/packages first
[03:34] <kiko> we also need to offer translation overheads
[03:34] <kiko> so that people when translating KDE have easy access to a glossary of the words translated the way KDE does
[03:34] <kiko> it would be nice to even have highlights
[03:35] <mhb> sure, but first, the search feature, please :o)
[03:35] <mhb> we can't even track bugs without it
[03:35] <kiko> yes, I know it's the #1 feature requested.
[03:35] <kiko> mhb, just to be sure, it's searching a string in any language, right?
[03:35] <mhb> I have to grep the .po files on my computer to find out in what package is the mistake
[03:35] <kiko> english and czech in your case?
[03:36] <mhb> yes
[03:36] <kiko> would it make sense to search through /other/ languages in your case, or just those two?
[03:37] <mhb> kiko: well, it would be helpful for some people ... for example Slovak is very similar to our language, everyone in the Czech Rep. can understand Slovak, so someone would like to check if a word is translated in Slovak and if so, how
[03:38] <kiko> I see
[03:38] <kiko> mhb, but would it be acceptable for the UI to say
[03:38] <kiko> Search for: [                             ]  in [ Czech   | v]
[03:38] <kiko> ?
[03:39] <mhb> it would be for me
[03:39] <kiko> all right
[03:39] <mhb> can I ask you one more question, please?
[03:39] <kiko> sure!
[03:40] <mhb> the Czech translation team does have a little dictionary of terms which are *strongly* recommended to translate as the dictionary suggests
[03:41] <mhb> we use wiki to achieve that
[03:41] <kiko> right
[03:41] <kiko> is it a single wikipage?
[03:41] <mhb> yes, just like that - word and translation etc
[03:41] <kiko> so
[03:41] <kiko> very easy strawman proposal:
[03:41] <kiko> wikilink for language guide
[03:41] <kiko> and display that prominently when translating
[03:42] <mhb> for example that
[03:42] <kiko> other less easy strawman proposal: fetch information from that page and display it (but where?)
[03:42] <mhb> I thought more of a large scale
[03:42] <kiko> a real tool, yeah. there's a spec on that called TranslationGlossaries I think
[03:42] <mhb> make a similar dictionary that can communicate with Rosetta
[03:42] <kiko> and offer it as an overhead
[03:42] <mhb> I'll take a look, thanks
[03:43] <kiko> the cool way to do that
[03:43] <kiko> would be to do it using ajax
[03:43] <kiko> with a floating div containing information on the words you typed into the box
[03:43] <kiko> so let's say I typed
[03:44] <kiko> "o livro est na mesa" in portuguese
[03:44] <kiko> I'd get a little overhead saying things like "mesa: avoid use in translations related to fish".
[03:44] <kiko> and "livro: KDE prefers the term revista"
[03:44] <kiko> etc
[03:44] <mhb> yeah
[03:45] <mhb> I wanted to code that in AJAX myself
[03:45] <kiko> you know that the largest problem with rosetta
[03:45] <kiko> is actually the @#!!@@ large dataset
[03:45] <mhb> kiko: I can undestand
[03:45] <kiko> which causes us to scramble for performance even for simple suggestion lookup!
[03:46] <kiko> I spent like god knows how many hours looking at the SQL generated
[03:46] <kiko> ugh
[03:46] <kiko> danil[o] ut is currently working on improving that
[03:46] <kiko> made some progress last week
[03:47] <mhb> kiko: as I said, I wanted to do this tool, but I have other projects, so I couldn't lead the development ... and without the Launchpad account information it is also not so useful
[03:47] <kiko> well
[03:47] <mhb> kiko: and I don't want to do any community work that is non-free
[03:47] <kiko> you could develop a prototype
[03:47] <kiko> that could be useful generally
[03:47] <kiko> client-side only
[03:48] <kiko> and license it to us separately
[03:48] <kiko> while still releasing it under your free software license of choice
[03:48] <kiko> LGPL it
[03:48] <kiko> we'd be happy to improve and give back improvements.
[03:49] <kiko> I did so for the javascript sorting code we use a few months ago
[03:49] <mhb> kiko: yeah, but nobody can promise me that, which saddens me
[03:49] <kiko> well
[03:49] <kiko> if it's LGPLed, being client-side, we do have to redistribute modifications
[03:50] <kiko> and we would if we said we would anyway.
[03:50] <mhb> when the time comes, I know .o)
[03:50] <mhb> no, sorry bout that
[03:50] <kiko> no, I meant immediately
[03:51] <kiko> if your code is LGPLed and we use it
[03:51] <kiko> because it is client-side
[03:51] <kiko> we need to release modifications to it
[03:51] <kiko> immediately
[03:51] <kiko> not "when the time comes"
[03:51] <mhb> ok
[03:51] <kiko> that only holds for client-side code
[03:51] <kiko> but.. it's still binding
[03:52] <mhb> by client-side you mean the code without the database access, or what?
[03:52] <kiko> correct
[03:52] <kiko> using an API to do the query to the remote server
[03:52] <kiko> (and if we implement the server-side you can use that API everywhere, not only in rosetta JS)
[03:52] <mhb> kiko: I think I could do it, but I have a lot of other things going, so it would be ready for edgy+1 translations, I guess
[03:53] <kiko> wow that would be most excellent
[03:53] <sabdfl> hey kiko
[03:53] <kiko> hello sabdfl
[03:53] <kiko> what's cooking up north?
[03:53] <sabdfl> in case you're wondering, the crashes come from a db issue, not the code, though it's too soon to tell if the code itself has issues
[03:53] <sabdfl> the staging db update lost all db premissions
[03:53] <sabdfl> so lifeless rest the db to the production one, i think
[03:53] <kiko> me, wonder? ;)
[03:54] <sabdfl> which does not include the additional columns needed with the new code
[03:54] <sabdfl> kiko, i will take that pie if there's a single new oops, if i give the go-ahead after testing tomorrow, hmmmk?
[03:55] <kiko> well, I still don't see why we are in a hurry to put this into production -- the points I made still stand
[03:55] <sabdfl> the code keeps track of who started specs and when
[03:55] <sabdfl> the distro sprint is in a week
[03:56] <sabdfl> if we land it this week, we get much better data for edgy
[03:56] <kiko> I see
[03:56] <kiko> you hadn't said that
[03:56] <kiko> when does it start?
[03:56] <sabdfl> i just thought of it this morning
[03:56] <sabdfl> i think in a week
[03:56] <kiko> let me check
[03:56] <kiko> if it does indeed start on the same week as the soyuz sprint then I think it's a good idea
[03:57] <kiko> otherwise it should wait
[03:58] <kiko> sabdfl, it starts on the 21st, so I agree.
[03:59] <mhb> kiko: could you send me some more info/documentation about the line between client-side and server-side in a mail, please? I want to know the rough structure first.
[03:59] <kiko> mhb, sure. are you aware of how ajax works?
[04:00] <kiko> it basically needs a way to contact the server
[04:00] <kiko> it uses an XMLHttpRequest object to pull the data
[04:00] <mhb> kiko: don't hesitate with the details, if there is something I don't know, I'll look it up
[04:00] <kiko> okay, cool.
[04:01] <kiko> mhb, what's your email address?
[04:01] <mhb> kiko<EMAIL_ADDRESS>[04:01] <kiko> my pleasure
[04:04] <mhb> kiko: I would also be happy if you keep me informed when something related happens, like some other developer starts implementing that or so.
[04:04] <kiko> mhb, will do. the upcoming features section of the report usually tells about the new stuff being worked on
[04:05] <mhb> thank you
[04:06] <mhb> for the lengthy talk. I won't tire your hands anymore :o)
[04:06] <kiko> heh. thanks to you
[04:08] <mhb> I hope you don't forget about the translators next week :o)
[04:08] <mhb> bye all
[04:08] <kiko> I never forget. laters!
[04:24] <Mez> any LP admin: ping
[04:24] <kiko> Mez, yo
[04:24] <kiko> what's cookin
[04:30] <Mez> kiko: problems with bazaar... it's fscked up an upload- and i cant delete them
[04:30] <kiko> Mez, isn't it the case that you can ssh into the supermirror and delete it manually?
[04:30] <Mez> kiko: no permissions apparently
[04:36] <Mez> kiko : it gives me permission denied- so I need an admin to do it for me
[04:40] <kiko> mmmm
[04:40] <kiko> I can't do anything on the SM. I think it needs to be lifeless
[04:41] <Mez> :'(
[04:41] <Mez> lifeless: ping
[04:41] <Mez> hmm - I believe I remember lifeless from ubz :P
[04:47] <LarstiQ> kiko: also, rm -rfing a directory seems to be problematic over sftp
[04:48] <Mez> LarstiQ, indeed ... but thats an sftp bug
[05:06] <Shart> hi
[05:07] <Shart> i want to request ubuntu cd, but i have a problem
[05:07] <kiko> hello Shart
[05:07] <kiko> what's the problem?
[05:08] <Shart> there is phone number required
[05:08] <kiko> right
[05:08] <Shart> are you really want to call me?
[05:08] <kiko> that's required because you may be contacted if your package is held up in customs.
[05:08] <kiko> it's required by the shipping company.
[05:09] <kiko> canonical will not call you, no
[05:09] <Shart> i don't think it's cheap to call to Belarus
[05:09] <kiko> but a customs agent or the shipping agency on your side of the world may. it only happens in rare occasions.
[05:09] <kiko> it will be a call from somebody local
[05:09] <kiko> not from us
[05:09] <kiko> and it very rarely happens
[05:10] <Shart> ok
[05:10] <Shart> tanks
[05:10] <Shart> thanks* :)
[05:11] <Shart> is it really free of charge?
[05:11] <kiko> you're most welcome
[05:11] <kiko> yes, it is.
[05:12] <Shart> ok
[05:12] <Shart> we don't have so money as you do
[05:13] <Shart> )
[05:13] <kiko> I don't have any money
[05:13] <kiko> and I don't know what you are talking about!
[05:13] <Shart> ok, sorry
[05:13] <Shart> bye
[05:15] <kiko-fud> aw
[10:18] <mdke> does anyone know whether, if I assign a bug to someone, and comment, they get that bug email, even if they weren't subscribed to the bug before that?
[10:18] <mdke> I mean, if I assign the bug and comment at the same time
[10:30] <LarstiQ> good question
[10:39] <BjornT> mdke: yes, the one you assign to the bug will get the comment.
[10:59] <mdke> BjornT: good, thanks. The absence of the good ol' bugzilla "Mail sent to X, Y, Z" made me worry
[11:13] <teolemon> hi


[08:45] <rogpeppe1> uiteam: any else failing to connect to canonical irc?
[08:46] <frankban> rogpeppe1: no, I am there
[08:46] <frankban> rogpeppe1: (and morning)
[08:46] <rogpeppe1> frankban: hiya
[08:47] <rogpeppe1> frankban: hmm, maybe it's the VPN connection that's failing
[08:47] <rogpeppe1> frankban: i'll try leaving that