[00:04]  * jelmer yells at libapr
[00:21] <poolie> hi all
[00:52] <spiv> Good morning.
[00:53] <lifeless> hi guys
[02:08] <poolie> hi there spiv
[02:57] <mwhudson> jelmer: hey, do you want to make launchpad work with bzr 2.2? :-)
[02:58] <poolie> mwhudson, what's broken?
[02:59] <mwhudson> i can't remember
[02:59] <mwhudson> the usual sort of boring things i think
[03:00] <poolie> failing tests in integration?
[03:00] <mwhudson> yeah
[03:01]  * mwhudson is trying to dig up a buildbot log, the openid process is a little slow over 3g
[03:02] <mwhudson> hm, the compile is failing currently, but that looks like an image problem
[03:02] <mwhudson> src/zope/interface/_zope_interface_coptimizations.c:15:20: error: Python.h: No such file or directory
[03:02] <mwhudson> (that's not even the build of bzr)
[03:05] <mwhudson> hee hee, making bzr whoami mandatory seems to have broken some tests
[03:05] <mwhudson> poolie: failing tests from a couple of weeks back: https://lpbuildbot.canonical.com/builders/bzr/builds/200/steps/shell_8/logs/summary
[03:06] <mwhudson> i guess we have some bzr-using tests that don't inherit from bzrlib's testcase, maybe
[03:06] <poolie> wow
[03:06] <poolie> probably
[03:06] <poolie> look at all that crap :)
[03:07] <poolie> what are the dns failures about?
[03:09] <mwhudson> not sure
[03:10] <mwhudson> _probably_ the image is old and needs stuff adding to /etc/hosts
[05:22] <parthm> i was looking at bug #488519 what would be a way to handle this. abort the operation telling the user to change the name? any suggestions?
[05:22] <ubot5> Launchpad bug 488519 in Bazaar "[master] UnicodeDecodeError in osutils.walkdirs with non-ascii filenames (affected: 12, heat: 26)" [High,Confirmed] https://launchpad.net/bugs/488519
[05:28] <poolie> oh hi parthm
[05:28] <poolie> dude you're fixing all our bugs! :-}
[05:29] <poolie> i think in the first place it would be good to at least just print the name of the problem file
[05:29] <poolie> what actually should happen
[05:29] <parthm> poolie: i am just having fun ;-) ... also bugs with stack trace are easier to fix.
[05:29] <poolie> 1- in most cases, the filename is valid but the filename encoding is not set properly
[05:30] <poolie> eg on unix filenames are normally going to be utf-8 but in this case we seem to be detecting it as ascii
[05:30] <poolie> so that could be about better detection or better defaults or perhaps (last resort) having a configuration for it
[05:30] <poolie> 2- in some cases the user really may have a file that does not fit with the encoding of their tree
[05:30] <poolie> and then i guess we should...
[05:31] <poolie> i wonder
[05:31] <poolie> i think ideally we would just tolerate it if it was an ignored file
[05:32] <parthm> poolie: i saw another ticket by you saying we need a config option for bazaar.conf. maybe that should be fixed first?
[05:33] <parthm> poolie: bug #538925
[05:33] <ubot5> Launchpad bug 538925 in Bazaar "want configuration option for filesystem encoding (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/538925
[05:34] <poolie> i would do #1 then bug 538925 then #2
[05:34] <ubot5> Launchpad bug 538925 in Bazaar "want configuration option for filesystem encoding (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/538925
[05:36] <parthm> poolie: makes sense. ... i will look into the detection logic and try to understand it better. thanks for your inputs.
[05:44] <GungaDin> How come bzr tells me it's added file.OTHER during a merge?
[05:47] <poolie> GungaDin, ah, because you didn't totally resolve a conflict
[05:47] <poolie> this shouldn't be allowed; there's a bug vila's working on
[05:47] <GungaDin> shouldn't it have added just file and not file.OTHER?
[05:48] <GungaDin> after bzr resolve --all it's disappeared and file is just under 'unknown'
[06:16] <vila> GungaDin: Urgh, 'bzr resolve --all' is a huge hammer that should almost never be used
[06:18] <vila> If a file.OTHER is versioned after a merge, it's generally because there was a 'file' present in the working tree and in the other branch leading to a conflict on this path and you should resolve this conflict manually (by keeping one file, the other or a mix of the two)
[06:19] <vila> GungaDin: 'bzr resolve --all' "solves" the conflicts by just deleting them, it's really the last resort when nothing else make sense
[06:19]  * vila not really there yet, will be back in ~40mins
[06:28] <vila> poolie: spurious failure at http://lbabune.ladeuil.net:24842/job/selftest-jaunty/90/testReport/junit/bzrlib.tests.test_progress/TestTextProgressView/test_render_progress_nested/
[06:29] <vila> poolie: not reproducible, so probably a time dependent issue, just mentioning it as it's the first time I see it fail
[06:30] <poolie> that is odd that it would be timing depednt
[06:30] <poolie> however some of those tests are old and could bear to be refactored and thereby more isolated
[07:09] <lifeless> hmm, didn't get nearly enough done today
[07:09] <lifeless> tomorrow!
=== radoe_ is now known as radoe
[07:12] <mlh> there is always tomorrow
[07:13] <vila> poolie: why not ? progress rendering is controlled with a time threshold no ?
[07:13] <vila> hi all !
[07:13]  * vila fully there now albeit may need to reboot soon :)
[07:14] <poolie> vila, i guess it is
[07:14] <poolie> obviously in rendering tests it should not be
[07:15] <vila> poolie: not a big deal, the subsequent run worked anyway
[07:29] <poolie> vila i'm going offline for a bit in the name of concentration
[07:30] <vila> poolie: np, I'm going to reboot in the name of valuable upgrades :)
[07:32] <fullermd> Well, I'm eating in the name of getting fatter.
[07:32] <vila> :)
[07:32] <vila> cu later all
[08:15] <vila> bug #586341 is assigned to bazaar (Ubuntu), what is the trick get it assigned to bzr ? I can't set the importance right now
[08:15] <ubot5> Bug 586341 on http://launchpad.net/bugs/586341 is private
[08:15] <vila> argh
[08:16] <vila> for once the private status is valid :-/
[08:16] <vila> some confidential stuff exposed in the comments :-/
[08:22] <spiv> vila: Click "Also affects project"?
[08:23] <vila> spiv: that will create an additional line, I want to do that as a last resort only :-/ But thanks
[08:23] <spiv> vila: why as a last resort?
[08:23] <vila> I think the current affectation is bogus
[08:23] <spiv> Well, it affects the version in Ubuntu...
[08:24] <spiv> Anyway, the LP bug tracker doesn't currently allow directly reassigning from a distro package to a project.  Using the "also affects" options is as close as it gets.
[08:24] <vila> Ha, ok
[08:25] <vila> spiv: hehe, I can't copy/paste right now, but just try what you're proposing :)
[08:27] <spiv> First, let me fix it to be assigned to bzr (Ubuntu) rather than bazaar (Ubuntu)...
[08:27] <poolie> vila you can't delete 'affects' lines (aka tasks)
[08:27] <poolie> which is a bug
[08:27] <poolie> so just leave it there or mark it invalid
[08:29] <vila> poolie: I can't use 'Also affects project' either, I run into a 'too many matches' when searching for 'bzr' as  a project
[08:29] <spiv> vila: worked for me
[08:30] <spiv> vila: although as noted I fixed it to point to the right package first
[08:30] <spiv> Which means it automatically defaulted to the right project.
[08:30] <vila> spiv: cool, thanks
[08:30] <spiv> The "there's no upstream link for this package" and "this package has no versions published in Maverick" was a bit of clue that something was up :)
[08:31] <poolie> sorry, that sucks
[08:31] <poolie> there's a bug for that too
[08:31] <vila> poolie: well, spiv is right, I suck too :)
[08:32] <spiv> vila: heh, I didn't mean to say that :)
[08:32] <vila> :)
[08:33] <poolie> vila or you can use hydrazine bugclient and say 'bug 1234123' 'affects bzr' :-)
[08:33] <ubot5> Error: Could not parse data returned by Launchpad: 1234123 (https://launchpad.net/bugs/1234123)
[08:34] <vila> poolie: wow, cool, well, the demo effect didn't please ubot5 but I trust you :)
[08:35] <vila> ubot5: don't worry, that wasn't a real bug
[08:35] <ubot5> Error: I am only a bot, please don't think I'm intelligent :)
[08:35] <vila> ubot5: that's why I explain
[08:35] <ubot5> Error: I am only a bot, please don't think I'm intelligent :)
[08:35] <poolie> poor thing
[09:02] <lifeless> vila: you might like to file a bug saying you can't do that reassignment you wanted to
[09:10] <poolie> there is one laready
[13:12] <vila> jelmer: ping
[13:32] <spiv> in 27
=== nlisgo_ is now known as nlisgo
[13:57] <vila> spiv: try 28 too
[13:58] <spiv> :P
[14:39] <nitian> i am getting "different rich-root support" and " is not compatible " when i am rying to merge my branch .
[14:39] <nitian> how can i fix this?
[16:02] <Jemsquash> Does anyone know if there is jira integration for bazaar?
[16:37] <verterok> Jemsquash: Hi, there is a experimental plugin (for jira 3.x)
[16:38] <verterok> Jemsquash: and I have a inprogress branch to make it work with the new jira SDK (and probably jira 4)
[16:39] <Jemsquash> I think I just found it, is this the correct place to get it? https://code.launchpad.net/~verterok/bzr-eclipse/trunk
[16:39] <servilio> hi! I am getting an bzrlib.errors.NoSuchRevision exception in bzr when doing a rebase; is this normal or something I should file a bug for?
[16:39] <verterok> Jemsquash: http://launchpad.net/bzr-jira isn't a full integration, just a small experiment based on the svn integration
[16:40] <Jemsquash> just paste the wrong one - doh
[16:40] <verterok> Jemsquash: but it depends on the old jira sdk :(
[16:40] <Jemsquash> ah we just upgraded to the latest Jira yesterday - sods law :(
[16:42] <maxb> servilio: You should file a bug (against the bzr-rewrite project). If at all possible, provide links to the branches you were trying to rebase
[16:42] <RDV_Linux> I am looking for some help. I cannot push changes to my branch. I was working in March of this year.  Here is a step by step from starting at a bzr update to make sure I was working from what was in LP. http://paste.ubuntu.com/444107/
[16:42] <RDV_Linux> Any help would be appreciated. This is for Mythbuntu.
[16:45] <servilio> maxb: what if the branches are not publicly accessible ATM?
[16:45] <servilio> maxb: I mean, what would you recommend in that case?
[16:46] <maxb> Did bzr write a .crash file and give you its path when it died?
[16:46] <servilio> maxb: yes, it did :)
[16:48] <maxb> Check it doesn't contain anything private (I doubt it will), and attach it to the bug. Describe as much as possible about the rebase operation you were doing
[16:48] <servilio> maxb: ok, thanks!
[16:50] <maxb> The NoSuchRevision presumably mentioned a specific revision-id - try to find out what that revision-id was
[16:50] <servilio> maxb: I notice in the traceback that though the exception ocurred while using a command from the bzr-rewrite module, it happened in bzrlib/repofmt/groupcompress_repo.py, should I file the bug in bzr instead of bzr-rewrite?
[16:51] <maxb> Were there bzr-rewrite frames in the traceback?
[16:51] <servilio> maxb: there is indeed a missing revision, I had to revert a commit in the parent branch and add a couple of other things
[16:51] <maxb> If so, it's more likely a rewrite issue
[16:51] <servilio> maxb: yes, there is; also, thinking about it, it was while doing a rebase and fails, so it should be there
[16:52] <servilio> maxb: again, thanks!
=== IslandUsurper is now known as IslandUsurperAFK
=== IslandUsurperAFK is now known as IslandUsurper
=== deryck is now known as deryck[lunch]
[18:37] <lfaraone> lifeless: you said that bug 556968 was fixed in bzr-git, do you know which commit that was?
[18:37] <ubot5> Launchpad bug 556968 in Bazaar Git Plugin "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository (needs upstream cherrypick/backport) (affected: 3, heat: 18)" [Critical,Confirmed] https://launchpad.net/bugs/556968
[18:39] <lfaraone> jelmer: see above.
[18:39] <jelmer> lfaraone: hi
[18:39] <jelmer> lfaraone: it's fixed in the latest release
[18:39] <jelmer> 0.5.1 IIRC
[18:40] <lfaraone> jelmer: okay. I'm looking for what I should SRU to Lucid.
[18:41] <jelmer> lfaraone: you'd have to SRU both dulwich and bzr-git
[18:41] <jelmer> I think dulwich 0.5.0 and bzr-git 0.5.0 would be sufficient as well
[18:41] <jelmer> alternatively you can cherry-pick the fix, which is trivial
[18:42] <lfaraone> jelmer: ideally, we want to make the smallest change possible.
[18:42] <jelmer> lfaraone: I have to make sure I get my groceries before the shops close, but if you're still here in 2 hours I can get you a patch for just this issue.
[18:42] <lfaraone> jelmer: sure, thanks.
=== khmarbaise_ is now known as khmarbaise
=== deryck[lunch] is now known as deryck
[19:39] <servilio> what is the recommended way of changing the parent of a branch? is editing the branch.conf ok?
[19:42] <beuno> servilio, bzr pull --remember?
[19:57] <servilio> beuno: I was wondering if there would another way other than editing branch.conf or using --remember
[19:57] <servilio> beuno: thanks!
[21:48] <james_w> abentley: hi, was it lp-submit that has pipeline integration?
[21:48] <abentley> james_w, lp-submit and lp-propose both have pipeline integration.
[21:48] <james_w> I'm having trouble getting it to do what I want
[21:49] <james_w> aren't they the same thing?
[21:50] <abentley> james_w, lp-submit was the official name of the version in bzr-pipeline, and an alias for lp-propose when it moved to bzr proper.
[21:51] <james_w> abentley: ok. Is there a certain way to add ~/.bazaar/locations.conf entries to get a nice mapping to LP branches?
[21:51] <james_w> appendpath has .bzr/pipes/ showing up in the LP urls
[21:52] <abentley> james_w, there's nothing that will make locations.conf give a nice public location for that kind of layout.
[21:52] <james_w> abentley: you have your branches at the same level as the checkout?
[21:53] <abentley> james_w, no, but I have my branches at the same level as each other, whether or not they're part of a pipeline.
[21:54] <abentley> james_w, I have my checkouts in ~abentley/launchpad, and my branches in ~abentley/launchpad/branches
[23:31]  * mtaylor bitches about bzr storing the expansion of shortcuts rather than the shortcut itself
[23:31] <mtaylor> bitch bitch bitch
[23:35] <lifeless> huh?