=== psynaptic is now known as psynaptic|away [00:25] hi all [00:25] hey poolie. [00:30] hi there [00:31] i'm working a bit today on a plan to bring bzr-colo into core [00:34] 'morning spiv, poolie [00:34] 'evening maxb, mgz [00:34] * jelmer wonders what part of the day fullermd is in [00:34] jelmer, have you filed a bug against launchpad yet to enable projects to remove certain states from the drop down box yet? :) [00:35] mgz: I think it'd be closed as "Won't Fix" :) [00:36] hi jelmer [00:36] mgz: certain bug states? [00:36] which ones do you want to remove? [00:37] * fullermd doesn't know himself anymore :| [00:37] poolie: I'm winding jelmer up a little, he's forgotten bzr doesn't use 'Triaged' a few times. :) [00:43] okay, now I need sleep. [00:51] ah [00:51] in that particular case i think we'd be better off removing triaged altogether [00:53] On the other hand, the distinction between confirmed and triaged is rather vital if a project wants to separate user confirmations and "has had developer attention" [01:00] how can bzr have a conflict with a file that doesn't exist? [01:04] if you delete a file, and the branch you merge from changes it, that sounds like a conflict to me [01:06] that's right === Ursinha is now known as Ursinha-afk [04:43] If I have 2 commits in my local bzr branch and the parent has new commits, what happens if I do a 'bzr up'? [04:44] The 2 local commits become a pending merge. [04:44] Which you then need to commit. [04:48] hi spiv [04:48] spiv, have you used bzr-colo yet? [04:50] spiv: thanks. [04:51] why 'bzr up' always report I am up-to-date when in fact there are 9 new commits from parent? [04:56] leo2007, if it's a separate branch you may need to pull or merge them. [04:59] poolie: no, I haven't [05:01] poolie: pull says conflicts. But merge will not place my local revs on top of the remote parents, right? [05:01] leo2007, are these separate branches, or is your local branch a checkout of trunk? [05:02] spiv, how do you manage your branches? [05:02] just separate trees within a shared repo? [05:02] poolie: a checkout. [05:04] leo2007, what does 'bzr info' show? [05:05] poolie: http://paste.pocoo.org/show/lGSnxK33ZSi6vAKxlWmq [05:05] when you say '9 new commits from parent' where do you see that? by separately running 'bzr log' on the parent? [05:06] poolie: from 'bzr missing' [05:06] leo2007, this looks like just a regular standalone branch then [05:06] you're trying to bring the latest stuff from trunk into your branch, and then continue with development of your branch? [05:07] yeah, and my branch has two commits. [05:07] two extra* [05:08] ok, so you should probably just merge trunk [05:08] your own revisions will still be visible in history, but they won't be on top of it [05:08] poolie: yes, exactly that layout [05:08] if you want to rewrite history so it looks like they were done after what is now on trunk, use bzr-rewrite [05:09] poolie: I also need to push my commits to trunk at some time later. [05:10] ok [05:10] but not right now? [05:24] poolie: no, not right now. [05:25] I basically want to pull from upstream compile and submit my commits. [05:25] I am familiar with git but not bzr. [05:25] spiv, when you get a chance could you install it and have a play [05:26] leo2007, ok, the typical bzr thing would just be to merge from trunk, resolve any conflicts, compile and test, then send up your changes [05:26] would that mean my branch having different history than upstream? [05:27] well, your branch is going to show you did some work, then you merged trunk and resolved conflicts [05:27] which is accuarte [05:27] when trunk merges from you, all the history will be accurate [05:28] Is it possible to push an individual commit to upstream? In my case, I have two new commits locally, one is more mature and the other is waiting for confirmation before submitting. [05:30] when you say 'push' do you mean actual bzr push direct into trunk? [05:30] do you have access to write to trunk? [05:30] or just to submit for someone else to review? [05:31] poolie: I have write access. [05:34] spiv: hi, re bug 739144 - making it critical is fine; please don't set to confirmed though - if you've triaged it, set it to triaged. [05:34] Launchpad bug 739144 in Launchpad itself "Code review comment via email truncated, most content lost!" [Critical,Triaged] https://launchpad.net/bugs/739144 [05:36] leo2007, perhaps the cleanest/easiest thing is to make a new branch off trunk to integrate your work [05:37] do a 'bzr merge -r whatever' from your branch into that [05:37] then push that back up [05:38] poolie: is it possible to export a commit to a file which I can then put back in easily? something like git format-patch and am? [05:39] I am thinking since I have only two commits for now. I could save them to a file and drop them in my local branch. Sync my branch and put them back. [05:39] 'bzr send -o FILE' [05:39] that would appear solve all my questions. [05:40] or perhaps 'bzr shelve' is a better idea [05:40] or, if you have only two, just uncommit, shelve, pull, then unshelve [05:45] poolie: bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/Users/Shared/sources/EmacsBZR/trunk/". [05:46] lifeless: ah, ok. Thanks for the correction. [05:49] leo2007, ok, in that case you will need to make a new checkout of trunk trunk, merge your work, then commit [05:50] spiv: you may not have read https://dev.launchpad.net/BugTriage in a while - its been refreshed [05:52] lifeless: I haven't read it in detail, no, although I did skim it to check that I wasn't being too outrageous in choosing Critical [05:53] lifeless: I just didn't think at all about Confirmed vs. Triaged because I'm totally out of the habit of ever considering Triaged :) [05:53] :) [05:53] jelmer of course is having the opposite problem these days :) [05:55] poolie: I changed branch.conf and go ahead with uncommit. [05:55] just curious, what change did you make? [05:56] poolie: append_revisions_only = False [05:56] lifeless, how about you, did you ever use bzr-colo [05:56] oh, for the real emacs trunk? [05:56] that might make other people unhappy [05:56] poolie: my branch [06:06] poolie: could you recommend some good docs for using bzr? [06:06] well, mostly the current version under doc.bazaar.canonical.com [06:06] i know emacs also have some special conventions that i think are on their wiki [06:07] i would also really recommend using bzr-colo with bzr [06:07] from [06:07] http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html [06:11] spiv: :( [06:11] ok, i'll take a look after reading http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html [06:11] poolie: thanks for your help. [06:11] spiv: Processing that same email locally works fine.; [06:13] wgrant: whee [06:14] spiv: So I wonder if an MTA ate it... or something. [06:15] I guess we should check that jam's copy is intact. [06:16] wgrant: yeah, that's a good idea [06:16] If it's intact, we might need to go through MTA logs and find where the size drops... [06:17] poolie: no, I have used looms, and pipelines, and for non-distro work I just use a lightweight checkout of branches in a shared treeless repo [06:19] ok [06:19] you might like to try this as an alternative to the latter [06:20] i would appreciate your feedback if you do so [06:20] it will be a bit tricky right now - my lp dev environment is down to 200MB free :( (and my host os 2GB free :( :( ) [06:20] I need to get a larger SSD [06:21] I've been looking at getting a larger desktop box in fact - but the price for ones with 48GB of memory is ridiculous ;) [06:21] hm, it shouldn't use any more space than what you do now [06:22] poolie: Is colo fairly usable these days? [06:22] it might take more than 200MB to convert into it [06:22] i think it's really good [06:22] I haven't tried it since the week it was announced. [06:22] i'm just drafting a mail proposing we should bless it as the standard way to use bzr [06:22] and ship it by default etc [06:22] poolie: ping [06:22] IIRC the main problem I had with it was shelf. [06:22] it gives people a less manual way to set up the single-tree multiple brancehs thing [06:22] hi stylesen [06:23] poolie: Hi poolie, would like to have a private chat with you! [06:23] poolie: yeah, converting is what I was thinking might be an issue [06:23] sure, see pm [06:23] lifeless, i think the default conversion does copy all your histoyr [06:23] this could be optimized of course [06:25] for the common case of turning a repo + branches into a colo workspace, just moving the directories ought to be enough [06:25] lifeless, i just bought a 750GB magnetic disk to go into my laptop base [06:25] to store (my own) photos [06:26] lifeless, it's kind of ironic that you just converted me to the convenience of not having separate laptops/desktop machines :) [06:27] poolie: nice! [06:27] poolie: thats in an expansion bay, or the main unit? [06:28] in the sata bay of the ultrabase [06:28] the base does work pretty well for using it as a desktop replacement [06:30] ah, nice. [06:31] poolie: I'm finding my biggest limit is RAM [06:31] the disk is a bit annoying, but I can juggle tolerably (though 128GB is quite constraining) [06:31] but I can barely use all 4 cores with 8GB [06:32] i probably will ssh into my desktop box again if i'm doing something on lp and don't anticipate travelling soon [06:32] it seems like i touch dkim infrequently enough that every time i do, i spend 30 mins trying to get all the dependencies going again :/ [06:32] poolie: so if I do get a new desktop, I'll setup testr to run tests on the desktop from my laptop [06:32] lifeless: Are new ThinkPad motherboards still limited to 8GB? :/ [06:33] probably set that up locally too so that I edit in a local vim session, and the lp-dev VM runs the tests [06:33] wgrant: the W something or other can do (IIRC) 12 [06:33] wgrant: need 4GB for a lp test run end to end last time I tried to put a figure on it [06:34] wgrant: (4GB in a VM) [06:34] wgrant: so to parallelise robustly-before-we-fix-the-test-suite, I'm thinking we want 4GB*cores. [06:34] lifeless: It's a lot less if you run i386. [06:34] wgrant: but then I'd be running i386. [06:35] In the VM :) [06:35] How do I grab a remote branch into an existing colo workspace? [06:35] I [06:36] I'd expect 'make a branch, pull --overwrite' [06:36] 'bzr branch lp:launchpad colo:devel' seems to work. [06:37] or bzr colo-fetch lp:launchpad [06:37] colo-fetch says it creates a new workspace. [06:37] sorry, i misread [06:38] yes, i think your command is correct then [06:38] Thanks. [06:46] :( [06:47] I wish bzr switch had an option to shelve changes into the branch or something. [06:47] wgrant, that was just requested [06:47] it shouldn't be too hard to add [06:47] poolie: Except that shelves are in the WT, right? [06:48] wgrant: right [06:48] :( [06:48] Hmm. [06:49] I guess it's useful to have them visible in all, but it would be nice if I could tell where each shelf came from. [06:49] Since I use shelve a *lot*. [06:49] wgrant: hmm! [06:50] (and I just about never give a message... perhaps I should) [06:50] wgrant: bzr-colo could perhaps auto-fill the --message option of 'bzr shelve' with the branch nick? [06:50] Right. [06:50] That would help. [06:51] wgrant, well, what i meant is that it seems like it would be a small code change to put them in the branch dir [06:52] giving better identities would be good [06:52] i'd like if they showed a diff stat or a snippet of the change more easily [07:19] hi all ! === r0bby is now known as robbyoconnor [07:34] hi vila [07:36] poolie: hey ! [07:40] hi vila [07:40] vila, did you try bzr-colo yet? [07:41] s//at all? [07:41] not at all [07:42] I still favor using a different working tree for each branch and looms for more involved feature dev [07:43] I also use bound branches for specific needs (so multiple working trees but on different hosts) [07:48] ok [07:48] rfc sent [07:55] vila, like multiple machines all on the same network, bound to branches on one of them? [07:55] for fixing failures inside vms, or something? [07:56] well, the branches are called my/setup and my/admin and they centralize/share all tweaks/setups I do on all my hosts [07:56] that includes VMs [07:59] but I still haven't a good story for fixing failures in VMs, partly because I keep encountering corruptions due to hard crashes and partly because I don't want to put valid auth tokens in VMs [07:59] (thought I cheat a bit with the later ;) [08:00] I work around corruptions by using mounted file systems for most of the VMs [08:00] I'd prefer a bzr-based workflow but each time I need it, I'm already in bugfix mode and procrastinate [08:01] s/proca*/punt/ [08:01] urg, one more random kill of a VM as a write this :( === hunger_ is now known as hunger [08:02] hmm, death may be more appropriate in fact, *2* VMs died (out of 3 running) and only the 3rd one should have shut down... [08:03] wow [08:03] died in the vm infrastructure, or in the guest os? [08:03] the vm just vanished [08:03] n ologs, no core, no nothing [08:04] this is with virtualbox? [08:04] most annoying "babune" bug for months, no idea how to progress, last attempt was configuring core dumps but none ever appeared [08:05] yup, and vbox is my first suspect, I keep hoping that the next version will address the issue :-/ [08:05] maybe some of these things could run under kvm, vmware desktop, or something else? [08:05] I chatted in #vbox several times but no one has any idea about what is going on nor how to collect useful infos to help debug it [08:07] and since most of the time it happens during my sleep it's very hard to even caracterize it (hence my kill/death remark above) [08:32] gah [08:32] This is the most annoying thing. [08:52] vila: Really, it's your own fault for sleeping :p [08:53] aaaaaaah, of course ! [09:19] hi vila, [09:19] would you like a quick chat [09:21] sure === jelmer changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer | 2.3.1 is officially out, 2.4b1 has been frozen [10:14] how to show what's in a commit? [10:14] leo2007: do you mean the tree contents, the changes in that commit, the commit message / committer information? [10:15] the diff, the message, etc [10:15] leo2007: bzr log -p -rREV [10:17] thanks. === psynaptic|away is now known as psynaptic === psynaptic is now known as psynaptic|scran === psynaptic|scran is now known as psynaptic [12:05] jam1: LP appears to have mangled an email I sent to it: https://launchpad.net/bugs/739144. You were CC'd, did you receive it intact? [12:05] Ubuntu bug 739144 in Launchpad itself "Code review comment via email truncated, most content lost!" [Critical,Triaged] [12:06] jam1: probably best to reply on the bug, it's zzz time here :) [12:06] spiv: I got the email in-tact [12:06] and broken from lp === jam1 is now known as jam [12:08] jam: I'm not sure if I feel relieved to hear that or not! [12:08] spiv: sleep well. But yes, you sent the email correctly to me, LP messed something up [12:08] or LP's mailhost did :) [12:54] hi [12:54] I get an error when trying bzr update : [12:54] bzr: ERROR: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 85: ordinal not in range(128) === Ursinha-afk is now known as Ursinha [12:56] hi guys. In our current team workflow, we occasionally have a 'merge session' where we merge in all changes prior to a release. After that, I get the team to `bzr pull` from the master branch, so we're all now working from the same code [12:56] is that last bit sensible? [12:57] it seems to work OK, as all team members then get everyone elses changes in their own branches [12:57] Sp4rKy: See if there is a traceback in ~/.bzr.log, and pastebin it [12:59] CaMason: that seems perfectly sensible [13:01] maxb: http://paste.dunnewind.net/show/eVa29Aq8XkZ8ySIA0Xrt/ [13:03] Sp4rKy: set you LANG/LC_ALL env vars to something sensible. [13:03] *your [13:20] Sp4rKy: to expand slightly on mgz's answer - you're trying to check out code with non-ascii file names. To do this, you need to be configured to use a locale which uses a character encoding which can represent them, so that Bazaar knows how to write the filenames to disk [13:21] Nowadays, everyone ought to be using a utf8 locale, really [13:21] maxb: in fact I am using utf-8 locale [13:21] but for some strange reason puppet (I manage the bzr repo with it) reset it ;) [13:22] so nothing bzr-related I think [13:22] line 56 of your pastebin says you are not [13:26] I am :) [13:26] but puppet reset it [13:31] is there any benchmarks comparing bzr 2.1+ to mercurial and git? [13:32] I've only seem really old ones and people told me bzr improved a lot in the 2.x line [13:36] santagada: I haven't seen any recent benchmarks [13:51] jelmer: care to finish your review of https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994 [13:51] ? [13:51] Error: Launchpad bug 2 not found [13:52] jam: Sure [14:25] what's the easiest way to output all files that have changed between revisions? Sometimes we get a customer that needs a 'patch', and we want to send only the PHP files that have changed [14:26] CaMason: "bzr status -r X..Y" ? [14:27] we might be talking a few hundred files :) Any way to `bzr cat` based on the revisions? [14:27] if not, I could set up a script [14:27] CaMason: so you want the complete contents of all files that changed recently (that end in .php)? [14:27] between specified revisions, yes [14:28] CaMason: "bzr status --short" is quite scriptable [14:28] my 'cut' experience is limited [14:28] but [14:28] ah, hadn't seen that :D [14:28] bzr status --short -r X..Y | grep ".*\.php" [14:29] gets you a sart [14:29] start [14:29] I would use sed to get just the filenames, but that's because I don't know cut [14:31] no sweat, that output is great, I'll get that scripted [14:31] thanks [14:33] bzr st --short -r last:4 | cut -c 5- [14:35] CaMason: still need 'grep .php' [14:35] but yeah [14:36] bzr st --short -r last:4 | cut -c 5- | grep '.php' | xargs -n1 bzr cat -r -1 [14:36] ah that's no bother, I actually want all files. I just said 'php' so people didn't worry about a build script :P [14:37] CaMason: though you could probably just pass the list to tar so that it will include only those files in a tarball [14:41] `bzr st --short -r last:4 | cut -c 5- | xargs zip ../patch.zip` worked great [14:41] its for windows clients unfortunately :) [14:47] jelmer, vila: ping about https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994 [14:47] Error: Launchpad bug 2 not found [14:49] ubot5: where do you find a bug 2 ? [14:49] * mgz eyes ubot5 suspiciously [14:49] Error: Launchpad bug 2 could not be found [14:50] mgz: ;) [14:50] mgz: it *really* likes bug 2 [14:50] Error: Launchpad bug 2 could not be found [14:51] mgz: currently reviewing https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130 [14:51] Ubuntu bug 54130 in Ubuntu "no sound of any sort 6.10 knot 1" [Undecided,Invalid] [14:51] why do you return the Error class rather than just raising it? [14:51] okay, someone just borked poor ubotu5. [14:51] gee, unplug that bot ! [14:52] mgz: at least it didn't mention "that bug" again [14:52] jam: I don't really like helpers appearing in the stack, and to raise I need to return object from the cdef anyway [14:52] mgz: well,there are other ways, and you don't have to explicitly list object (it is the default if you say nothing) [14:53] so it's either helper than raises or returns None, or returns exception instances [14:53] cdef foo() returns None [14:53] same as regular python [14:53] jam: oh, and pong https://code.launchpad.net/~vila/udd/735477-kill-harder/+merge/53837 ;) [14:53] Ubuntu bug 735477 in Ubuntu Distributed Development "some imports survive a kill -SIGTERM leading to massive log output and no kill" [High,In progress] [14:54] I picked the way that gave me a shorter path in the common case, and one less level of stack when something goes wrong. but I'm open to all suggestions of this kind, made various stylistic judgement calls. [14:54] vila: you didn't respond to my comment on that proposal [14:55] I don't usually like hard-coded constants in the middle of code, can you bring it to a module/class level constant? [14:55] jam: it wasn't related to the proposal but to another script :) [14:55] otherwise seems good to me [14:55] vila: though isn't that script broken by any grace period that isn't 0? [14:55] since it only waits 1 second before starting the next process === psynaptic is now known as psynaptic|away [14:57] jam: no, as explained in the cover letter (updated before asking for re-review) during the grace period no kills are issued but the mass_import script doesn't wait either [14:57] vila: I saw the update, but probably missed the details in the 5-pages-of-text [14:58] the discussion then went about how long it takes for the mass_import to stop [14:58] vila: so only ImportDriver is using the new kill_with_escalation, and mass-import is doing? [14:59] 61 lines == 5 pages ? a page = 12 lines ? [14:59] anyway, it isn't very clear how your first comment how it ties in with the last comment. since you seem to say it should switch, but then say it doesn't [14:59] jam: sorry I don't understand your question [14:59] or maybe just doesn't fast enough? [15:00] vila: I'll try to start at the top [15:00] "For the first case, we don't really care about what is currently [15:00] going on since this denotes a bug" [15:00] that sounds exactly like the case we care about [15:00] s/the case/a case/ [15:01] except we can't any data from a process that doesn't respond to SIGTERM (as shown with nexuiz-data) [15:01] vila: certainly [15:01] and we *currently* generate log files 1GB/day with attempts to kill it [15:01] I think martin and my point is that under load, 2s is actually pretty short for something to even generate a backtrace [15:02] I'm happy to have the SIGTERM end up with SIGKILl [15:02] well, not *currently* because it's seen as failing but still [15:02] after a reasonable time [15:02] 10s seems good to me [15:02] a bit long for "die now please" [15:02] but good for most situations [15:02] jam: which is what the proposal implements hence asking for a re-review [15:02] vila: which is the part I've certainly approved already [15:03] meh, there are currently 2 NeedsFixing vote and no Approve [15:03] vila: reload [15:04] mgz: why is "delta_data" a "void **" rather than a "delta_index **" ? [15:04] (in the pyrex header) [15:05] it was a straight change from returning void* to taking void**, but it could be unsigned char** instead given the actual value [15:05] mgz: and in the docs, I would say "when DELTA_OK "fresh" contains a struct ..." [15:05] was it some cython being to clever with strings workaround thing? [15:05] rather than "outparam" which isn't defined [15:06] mgz: the actual value is a delta_index pointer [15:06] at least from what I'm reading in delta.h [15:06] possibly the header is misleading? [15:06] unsigned char *out; [15:06] ... [15:06] https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130 [15:06] *delta_data = out; [15:06] Ubuntu bug 54130 in Ubuntu "no sound of any sort 6.10 knot 1" [Undecided,Invalid] [15:07] line 285 [15:07] you added a new parameter, it should be called "fresh" not "delta_data", or whatever you want to do with it [15:07] create_delta and create_delta_index have different signatures. [15:08] mgz: ah, just misreading it [15:09] 282 in diff-delta.c is 197 in delta.h [15:10] adding to the function descriptions in the header might help things, the similar names are confusing to start with. [15:11] mgz: overall approve, just needs a news entry [15:11] something about getting better error messages when things fail [15:11] is probably enough [15:13] I'll do that and take another pass at the comments. [15:15] which news heading should it be under? :) [15:15] mgz: probably either internals or bugfixes [15:17] I'm just having a closer look at your tar export branch now, the push fixed the broken tests clearly. === mnepton is now known as mneptok === Ursinha is now known as Ursinha-lunch === psynaptic|away is now known as psynaptic === deryck is now known as deryck[lunch] === Ursinha-lunch is now known as Ursinha [17:15] jelmer: what do you mean in bug #739481 ? Repository has too many methods - iter_reverse_revision_history " ... "in favor of Repository.iter_reverse_revision_history" ? [17:15] Launchpad bug 739481 in Bazaar "deprecate Repostory.iter_reverse_revision_history" [Low,Confirmed] https://launchpad.net/bugs/739481 [17:16] Obviously, he means there's madness in its methods ;) [17:31] hi [17:32] suppose my shared repository is offline, can I commits locally and then when I can reach my serve again move all changes to the shared repository? === deryck[lunch] is now known as deryck [17:37] gypsymauro: Yes, but a little advice on terminology - a "shared repository" in bzr terms usually refers to a location on disk created with "bzr init-repo" which exists to share one copy of history between multiple branches within it. [17:37] Whereas I assume you are talking about a remote server hosting branches. [17:39] maxb: no I'm talking about a shared repository in bzr terms :) [17:39] How can a directory on disk be offline? === beuno is now known as beuno-lunch [17:55] vila, is anyone running the bzr benchmarks that ian was running? [17:56] or jam ^^ === psynaptic is now known as psynaptic|break [18:34] g'morning poolie === beuno-lunch is now known as beuno [18:42] sidnei: I think you will have to run them [18:42] :D [18:42] santagada, yeah, why not [18:43] santagada, you could too :) [18:44] sidnei: if you can get the scripts used, I can try [18:44] santagada, yay! [18:51] jelmer, would you know anything about ian's benchmark scripts? [18:55] if it is a simple shell or python we could run it on my mac on windows and osx, you could do it on ubuntu [18:55] sidnei: I think it's on Launchpad as lp:bzr-usertest [18:57] jelmer: yep it is in there but the docs http://people.canonical.com/~ianc/plugins/usertest/doc/ are 404 [18:59] santagada: I think the docs are probably in the branch too [19:00] yeah, looks like it [19:00] santagada, see http://bazaar.launchpad.net/~bzr/bzr-usertest/trunk/view/head:/scripts/script_network.py for example [19:03] jelmer, Hey. [19:03] jelmer, I got that information you requested: https://pastebin.canonical.com/44973/ [19:03] jelmer, It... looks like a bigger issue at hand. And the fact that someone else also reported this is rather concerning. [19:05] cody-somerville: who did? [19:05] cody-somerville: that all looks reasonable [19:06] jelmer, Why is the group owner of somethings users and not jagosta? [19:07] jelmer, LP #661678 [19:07] Launchpad bug 661678 in bzr (Ubuntu) "bzr whoami: unable to copy ownership from '$HOME/.bazaar' to '$HOME/.bazaar/bazaar.conf'" [Undecided,Invalid] https://launchpad.net/bugs/661678 [19:08] cody-somerville: I don't know, but that shouldn't really be an issue [19:09] cody-somerville: or maybe that breaks the ownership copying [19:10] cody-somerville: what groups is he in ? is he in both jagosta and users? === psynaptic|break is now known as psynaptic|away [19:12] jelmer, weird... no. users but not jagosta [19:14] That would explain why bzr is errorring out - as it probably can't set the group for that file [19:14] * jelmer reopens the bug [19:17] I think this might be a regression in Ubuntu. [19:20] cody-somerville: yeah, looks like it === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [20:39]