[06:55] morning all [07:03] hei jam [07:03] morning LarstiQ [10:19] hey vila === yofel_ is now known as yofel [11:06] vila: did you see the "jubany package importer stopped" email from stephanie? [11:08] jam: james_w and maxb know more about that, AIUI they both deployed stuff there that is leading to the actual problems [11:08] * vila lunch bbl [11:26] ah [11:26] seen [11:27] I can prod at that, but ultimately it seems to be fallout from the stormification [11:27] I suppose we could roll back the use of storm.... but that might irk james_w a bit [11:27] ( jam / vila bing ^ ) [11:28] maxb: right, I think the big thing is working with james_w to either polish storm use, or nuke it [11:28] I have nothing to do with the introduction of the problem, so from my perspective, james_w fixes soon, or we nuke [11:39] hmm, this went out a bit ambiguously, I didn't mean to throw stones (I rarely do ;), I meant I wasn't aware of the details but james_w and maxb were. So +1 on what jam and mabx said ;) [11:46] I know nothing about storm myself, so it looks like james_w might have turned himself into a bit of a SPOF by introducing it :-/ [13:18] Hi, using bzr in win7 and cant do a commit - bzr is treating all filenames as case sensitive - i think i can fix it if i delete a couple of files but i can only get an add option and no delete - any help available? [13:21] avalon_: what is commit complaining about? [13:23] LarstiQ: it says it cant open the files - there is no reason for that - all that happened was 2 files were renamed withl lower case from mixed [13:23] avalon_: does `bzr status` show them as missing, and then the renamed files as unknowns? [13:24] LarstiQ: yes [13:24] avalon_: I'm looking for an option to deal nicer with case-insensitive filesystems, but one thing you could do is `bzr mv --auto` to make it try and infer the move [13:25] LarstiQ: don't understand but i'll try - thanks for the help [13:26] avalon_: `bzr mv --auto` tries to automatically guess renames [13:26] ah.. [13:41] Any one available to provide advice about smart server jails? Specifically about how to have plugins make calls outside of the jail. [13:46] LarstiQ: hey, did you see my recent email about bzr package maintenance? [15:30] Hey all, want to do my brother a favor by participating in this survey? It's about the motivation of open source programmers and takes about 7 minutes: https://uleidenss.eu.qualtrics.com/SE/?SID=SV_8jgmLHsvuymV36s === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === r0bby is now known as robbyoconnor === thomi_ is now known as thomi [21:55] Is there a way to take advantage of a local svnsync read-only mirror for purposes of populating bzr-svn's metadata cache?? [22:21] nDuff: if it has the same repo guid [22:21] nDuff: then it will populate the same metadata cache [22:42] ...hmm. Is "bzr shelve" expected to work against a SvnWorkingTree (bzr 2.4.1, bzr-svn 1.1.0)? [22:45] I'm getting a crash in lp-propose because for some reason bzr can't talk to gnome-keyring. Any idea how I fix that without rebooting? The bug is https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/728548 which is marked as a duplicate of #534326 , which is marked as fix-released, but it's still at large in precie [22:45] Ubuntu bug 534326 in Bazaar GTK+ Frontends "duplicate for #728548 bzr: ERROR: gnomekeyring.IOError:" [Medium,Fix released] [23:07] thomi: hi [23:07] thomi: that's not the bzr-gtk bug [23:07] nDuff: you probably want a newer version of bzr-svn for that [23:07] thomi: it's a bug in python-keyring, which launchpadlib uses [23:07] jelmer: yeah, it looks like the 'duplicate bug' thing on lp is incorrect? [23:08] thomi: it's actually bug 885732 [23:08] Launchpad bug 885732 in python-keyring (Ubuntu) "breaks application when Gtk3 is also used" [Undecided,Confirmed] https://launchpad.net/bugs/885732 [23:08] I've fixed the dupe [23:09] cheers [23:18] ...so, "svn info $URL" shows the same UUID for both the original repo and my svnsync mirror, but when I try to run "bzr info" against the original after populating the cache against the mirror, bzr-svn goes back and starts a refetch. [23:19] there's only one directory in ~/.cache/bazaar/svn/, so it's not reading the UUIDs as different... [23:19] ...perhaps does it not bother populating the cache for local repos? [23:20] nDuff: it doesn't populate the cache for local repositories [23:20] ahh! [23:20] is there a way to force contrary behavior? [23:20] IIRC you can set "use-cache = True" for the relevant repository in ~/.bazaar/subversion.conf [23:21] that did it; thanks!