[00:27] <doctormon> AlanBell: It's good, but I have some news.
[08:01] <dholbach> good morning
[08:19] <AlanBell> morning dholbach
[08:20] <dholbach> hi AlanBell
[08:29] <AlanBell> do we know how the core design team like to collaborate?
[08:45] <doctormon> AlanBell: google docs
[08:48] <thorwil> well, i guess being in one place rather often and using white-boards could also be mentioned
[09:37] <AlanBell> sabdfl reeled off a list of irc nicks in the last CC meeting, but I don't think there has been any comment from any of them
[09:37] <AlanBell> just wondering if they would prefer mailing lists to IRC or something else?
[09:37] <AlanBell> google hangouts perhaps?
[09:38] <AlanBell> "<sabdfl> it feels weird to me that the ubuntu design team doesn't include johnlea, mika, oren, calum, christian, mpt..."
[09:39] <AlanBell> mpt is here, the rest don't appear to be on freenode
[09:41] <mainerror> sladen is here as well.
[09:54] <sladen> AlanBell: FWIW, I can only see mika on the Canonical internal IRC
[09:55] <sladen> AlanBell: I will poke people a little later
[09:57] <AlanBell> great
[10:10] <mpt> AlanBell, "oren" is oreneeshy, "calum" is ckpringle
[10:11] <mpt> AlanBell, what's the "CC"?
[10:11] <AlanBell> the community council
[10:12] <AlanBell> http://irclogs.ubuntu.com/2011/11/17/%23ubuntu-meeting.html#t17:04
[10:15] <AlanBell> hi oreneeshy & ckpringle o/
[10:15] <ckpringle> hi AlanBell
[10:15] <oreneeshy> hi AlanBell
[10:24] <mainerror> Oh hello. :)
[11:25] <mainerror> Soo, is there already an official statement on this weeks meeting date and time?
[15:32] <doctormon> mainerror: Yes, there should be in the title etc.
[20:21] <shnatsel> Hi everyone! I came here following doctormon's invitation in Ubuntu Artwork mailing list.
[20:24] <thorwil> hi shnatsel
[20:25] <shnatsel> hi thorwil
[20:25] <shnatsel> glad to meet you!
[20:25] <shnatsel> oh btw, Ubuntu Studio needs some love
[20:25] <shnatsel> Boot screen and login screen background, to be exact
[20:26] <shnatsel> the mockups, to be even more exact
[20:26] <shnatsel> I can code the plymouth myself, I already have some experience in that, e.g. http://www.youtube.com/watch?v=75_qyL7U2ME
[20:26] <mainerror> Hello shnatsel.
[20:27] <shnatsel> hello mainerror
[20:27] <shnatsel> (that thing on youtube is very old though; I've learned a lot since then)
[20:34] <shnatsel> thorwil: UbuntuStudio devs humbly hope that you'll come up with something for their boot and login screens
[20:35] <thorwil> shnatsel: oh, will not happen.
[20:36] <shnatsel> that's a pity
[20:37] <shnatsel> they seem to be in the poorest state of all official derivatives :(
[20:37] <shnatsel> I have to help them from time to time apart from my usual work for elementary project
[20:39] <thorwil> shnatsel: because i have several things on my list that are more pressing and/or interesting. tbh i don't think this derivative should exist. not as more than a collection of (meta-) packages
[20:40] <shnatsel> thorwil: they do an amazing job shipping an OOTB environment for professional sound processing
[20:40] <shnatsel> thorwil: regular Ubuntu is hardly suitable for that
[20:40] <doctormon> shnatsel: Do you have a good definition of what UBS needs?
[20:41] <shnatsel> doctormon: I think I do. You can ask ScottL in #ubuntustudio-devel for details right now if you wish.
[20:41] <doctormon> shnatsel: You should make sure you communicate with Scott how important it is to write down everythign you need in a blueprint or similar
[20:42] <shnatsel> doctormon: last time I checked they needed a boot screen mockup and a background image for login screen
[20:42] <doctormon> Think about a design breif.
[20:42] <shnatsel> doctormon: yeah, I've already converted them to blueprints
[20:42] <shnatsel> :)
[20:42] <doctormon> It's no good asking designers to boldly seek out the very busy ScottL for information in his head ;-)
[20:44] <shnatsel> doctormon: last time I checked they needed a boot screen mockup and a background for LightDM greeter. But yeah, good point.
[20:44] <shnatsel> doctormon: thanks!
[20:48] <doctormon> shnatsel: So 1 wallpaper and 1 plymouth? Do you have a link to the briefs for each of those?
[20:51] <shnatsel> doctormon: for Plymouth - https://wiki.ubuntu.com/Artwork/Documentation/Plymouth
[20:51] <shnatsel> doctormon: and examples at http://brej.org/blog/?p=238
[20:53] <shnatsel> doctormon: and LightDM is expected to look similar to GDM, but nobody really knows that yet :(
[20:54] <shnatsel> doctormon: like this: http://iloveubuntu.net/pictures_me/lightDM%200.9.2%20Oneiric.png
[21:00] <doctormon> thorwil: This is why we need a website to host designs and projects. :-)
[21:01] <thorwil> doctormon: did i miss something? i'm debugging some realtime audio software. how matching, since u-studio is the topic :}
[21:02] <doctormon> thorwil: Indeed. Although I think the branding for ubuntu studio is more important that you expressed above.
[21:13] <shnatsel> MediaGoblin, anyone>
[21:13] <shnatsel> ?
[21:15] <thorwil> shnatsel: guess who did a logo and mentioned it here? ;)
[21:15] <shnatsel> thorwil: yeah, saw that on your blog :)
[21:15] <shnatsel> thorwil: nice one btw
[21:16] <thorwil> ty
[21:16] <thorwil> gotta run, good night!
[21:21] <mmiicc> AlanBell: http://www.theregister.co.uk/2011/11/28/ubuntu_tv/
[21:21] <AlanBell> O.M.G.
[21:21] <AlanBell>  /o\
[21:21] <mainerror> hehe
[21:22] <mainerror> The internet is serious business. :D
[21:41] <shnatsel> ScottL says that he would write the exact requirements this weekend
[21:46] <mainerror> doctormon: What is the status of the design team website? Do you want to wait with it until after the meeting?
[21:47] <doctormon> mainerror: I want to wait until the meeting, consensus needs to be reached.
[21:47] <mainerror> I see.
[21:48] <doctormon> shnatsel: That sounds great, make sure he'll be specifying tone, logos and a list of don'ts.
[21:48] <mainerror> I will propose the use of Trello for the design team at the meeting. I feel this could really help.
[21:49] <doctormon> mainerror: Trello?
[21:49] <mainerror> https://trello.com/board/general/4ec98e1965baaac84a1359e9
[21:51] <mainerror> It is like a todo list but a lot better.
[21:53] <mainerror> doctormon: If you give me your email address I can invite you to the design team on Trello and you can play around with it.
[21:54] <doctormon> mainerror: Everyon should know my email<EMAIL_ADDRESS>[21:55] <mainerror> Sent. :)
[21:56] <mainerror> One day I'll get such a fancy forward email address as well. :)
[21:57] <AlanBell> the ubuntu-tv mailing list is going wild
[23:23] <doctormon> AlanBell: lol, WHAT DID YOU DO! ;-)
[23:28] <AlanBell> it is all a bit mad
[23:28] <AlanBell> however, there are lots of great ideas floating about and people are doing designs and storyboards
[23:33] <doctormon> AlanBell: That's great, using Pencil or some other method?
[23:34] <AlanBell> at least three are trying pencil, I think some others are doing other things
[23:36] <doctormon> mainerror: Trying to use Trello, it's _really_ slow. Far too slow to actually use any of the functionality.
[23:37] <doctormon> AlanBell: As you run through the ideas and methods, can you report back on your perception on whether we need a formal website or not?
[23:37] <AlanBell> will do
[23:38] <AlanBell> I can see a need for a few bits and bobs


[00:30] <jelmer> w00t, got "bzr builddeb <remote-url>" working :-)
[03:12] <alecwh> Hello! I want my bzr repository to be something that any user can just clone for the latest version possible of the software. The only problem is, I have a "config.php" file that needs to be changed after a clone, because a variable needs to be set to "$installed = 'no';". However, my local copy has it to 'yes' because that's what I use for myself. So, is there any way that bzr can just "ignore" that config.php to any changes, and just leave
[03:12] <bob2> have a seperate branch
[03:13] <bob2> although then you can only merge one way
[03:16] <alecwh> oh, so just merge branches whenever I make a change?
[03:16] <alecwh> but that will merge the config.php's (and probably have a merge conflict), because they are different, correct?
[03:20] <jelmer> alecwh: alternatively, you may just want to include a file "local-config.php" from your config.php that isn't versioned
[03:21] <jelmer> perhaps only if it exists, and set "$installed = 'yes'" if it doesn't
[03:22] <alecwh> jelmer: good idea actually... but if bzr doesn't recognize it, then it won't be uploaded with the repository.
[03:22] <jelmer> alecwh: yes, but you would be the only one who would have to have that file
[03:23] <jelmer> users who wouldn't have it would just get the default configuration
[03:23] <alecwh> oh okay. I'll try that out, thanks jelmer.
[03:23] <alecwh> =)
[03:23] <alecwh> wait - what does bzr ignore do?
[03:23] <bob2> stop bzr status complaining about files being unknown and 'bzr add .' from adding them
[03:29] <alecwh> oh, ok.
[03:30] <bob2> (you can still add them by giving their specific name)
[03:51] <nekohayo> ugh, for some reason I am still not able to rebase with bzr 1.5, getting tracebacks, can anyone help me figure out if it's me doing something wrong or if it's a bug?
[05:01] <jearl> cspam
[06:25] <alecwh> I'm trying to get bazaar to work with http://cia.vc to send my commits to IRC channels, but I'm stuck. Does anybody know how to do this?
[06:57] <bob2> you're using the bzr cia thing?
[06:59] <gour> is this "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch." common 'bzr-idiom' when for local development?
[06:59] <gour> s/when for/for
[08:38] <gour> my xdg_email is empty...anyone use Gnus with bzr?
[09:03] <vila> gour: I use bzr and I use Gnus, what is your question :)
[09:04] <bob2> I don't even have a xdg_mail
[09:05] <vila> gour: no need for a Gnus mail client, just add 'mail_client = emacsclient' in ~/.bazaar/bazaar.conf and add (server-start) to your ~/.gnus
[09:05] <vila> gour: I said ^ a few days ago, did you read it ?
[09:06] <gour> thanks
[09:06] <gour> vila: no, i missed it
[09:07] <vila> gour: hmm, yeah, re-reading logs, you left just before I posted it :) Sorry, I missed that detail :-/
[09:08] <gour> ta
[09:08] <vila> gour: what exactly means 'ta'
[09:09] <vila> I understand the 't' is for thanks but the 'a' ?
[09:10] <gour> 'alot'
[09:10] <spiv> "ta" is just a short way to say "thanks".
[09:10] <gour> :-)
[09:10] <vila> spiv: hi !
[09:11] <spiv> vila: good evening
[09:11] <vila> I'm looking at bug #230223, but I feel out of my league :-/
[09:12] <spiv> vila: sorry, I'm just passing through...
[09:12] <vila> my understanding so far is that smart server probing is not prepared to receive a 403
[09:12] <vila> spiv: ok, no worries
[09:12]  * spiv -> dinner
[11:39] <alefteris> i upgraded my local branch to rich-root-pack, then I'm trying to do the same with the launchpad.net hosted branch, but I get this: "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
[11:40] <alefteris> when i try to do bzr info at the launchpad branch i get "Standalone branch (format: unnamed)". What am I doing wrong?
[12:00] <lifeless> alefteris: for the launchpad branch you need to upgrade using sftp; that should work
[12:07] <alefteris> lifeless, thanks, I had to install paramiko as well and all went fine :)
[12:37] <jelmer> nekohayo, please file a bug report
[12:46] <lifeless> jelmer: bzr pull from bzr-svn - is it mainly slow cause of bzr ?
[12:47] <jelmer> lifeless: yes
[12:49] <jelmer> lifeless, there are some minor bits that can be improved in the fetch code of bzr-svn but it's mainly in the bzr-side of things
[12:50] <jelmer> lifeless, are you doing a pull that appears to be too slow?
[12:52] <bob2> did the bzr-gtk trunk get rebased?
[12:53] <jelmer> bob2
[12:53] <jelmer> no
[12:57] <lifeless> jelmer: I was showing ted gould from inkscape
[12:57] <lifeless> jelmer: and it was doing a revision every 30-40 seconds ot so
[12:57] <lifeless> which is rather appalling :P
[12:58] <bob2> oh, bah, ~bzr/bzr-gtk got killed 6 months ago and I didn't notice
[12:58] <jelmer> lifeless: Wow, ok. Worst I've seen is once every couple of seconds
[12:59] <jelmer> lifeless: Any idea what is being so slow?
[13:01] <jelmer> lifeless, are you trying this with a local svn repository?
[13:02] <jelmer> sourceforge can be really slow sometimes
[13:05] <jelmer> lifeless: I'm just trying it as well now, and it's taking 2 seconds to reply to each request
[13:06] <jelmer> lifeless: so, when are shallow branches going to land ? :-P
[13:18] <lifeless> jelmer: argh, 2 second latency on the server is explainable :)
[13:19] <lifeless> jelmer: could we show that in thhe ui/log file somehow ?
[13:19] <jelmer> lifeless: we are, but the progress bar is sometimes hidden for some unexplainable reason
[13:20] <jelmer> there are progress bars being displayed from inside bzr-svn
[13:20] <jelmer> s/displayed/created
[13:20] <hsn_> zr: ERROR: No such file: 'http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/indices/b072a80d0242839227870cba3a3e0f9b.rix'
[13:20] <hsn_> repo moved?
[13:22] <lifeless> hsn_: probably a push going through at the time you were reading
[13:22] <lifeless> hsn_: just try again
[13:23] <lifeless> hsn_: there is a bug open - this is something we should retry on
[13:29] <hsn_> lifeless: it works now
[13:56] <jelmer> lifeless: inkscape isn't exactly fast here either; does about one revision every two or three seconds
[13:57] <jelmer> lifeless: seriously though - what's still left for shallwo branches?
[13:58] <lifeless> jelmer: thats faster than we were seeing
[13:58] <lifeless> jelmer: well the prototype branch is there for testing; you should be able to do bzr-svn work for it now
[13:58] <lifeless> jelmer: I'm working on optimisations now - inpartcular exposing historic texts on all repositories
[14:00] <jelmer> lifeless: where's the branch?
[14:11] <lifeless> jelmer: mumbke shallow-branch or somthing
[14:11] <lifeless> http://www.google.com/search?q=bzr+shallow+branch&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
[14:11] <lifeless> its in that list :)
[14:12]  * jelmer wished he could do "lp list-branches bzr | grep shallow"
[14:17] <jelmer> lifeless: how stable is that API supposed to be, and what are the chances it's going to be in 1.6 ?
[14:17]  * jelmer doesn't want to go through similar issues as rich roots
[14:21] <lifeless> jelmer: hopefully the external API is done
[14:21] <lifeless> I would like it if you worked with me on a beta-bzr-svn branch to use it
[14:22] <lifeless> jelmer: that would be better than waiting for me to be 'done' and then findingout its missing/bad for you
[14:22] <lifeless> jelmer: just don't offer it to 'users'.
[14:28] <jelmer> lifeless: I'm happy to work on "beta" support in bzr-svn, I'm just trying to avoid participating in the process too early
[14:29] <jelmer> and having to maintain a bzr-svn branch through API changes and months of bzr releases
[14:31] <acuster> hey jelmer! Any chance you'd be willing to flesh out your answer to the last FAQ: http://samba.org/~jelmer/bzr-svn/FAQ.html ?
[14:31] <jelmer> acuster: What specifically?
[14:31] <acuster> it bit me enough that I'm being pushed towards mercurial but I suspect bzr handles svn copy better than hg
[14:32] <acuster> I did a push back to svn, possibly with an --overwrite I don't remember, and the operation deleted the whole trunk and pushed us back to where I had converted from
[14:33] <acuster> so I gather I deeply misunderstood how bzr and svn go together
[14:33] <acuster> so specifically
[14:33] <acuster> that and it are vague
[14:33] <acuster> I'd like a recepie possibly with why
[14:34] <lifeless> jelmer: I would help maintain such a branch
[14:34] <lifeless> jelmer: work goes >> when many hands
[14:34] <jelmer> acuster: I updated the FAQ
[14:34] <acuster> thanks
[14:35] <jelmer> lifeless: Thanks, that'd help
[14:35] <acuster> I'll try to get a better grip on my question when I can use 1.5 on this hardy
[14:42] <lifeless> jelmer: have you seen my status mails ?
[15:03] <jelmer> lifeless: no, I haven't - a quick search for "shallow" in my bzr mailbox doesn't list anything
[15:04] <jelmer> lifeless: also, the only "shallow" branch from you on launchpad is 11 weeks was last changed in february
[15:04] <bob2> it's on p.u.c
[15:06] <jelmer> http://people.ubuntu.com/~robertc/baz2.0/shallow-branch/ ? that's the one that hasn't hcanged since feb
[15:07] <nekohayo> jelmer: hey, it seems it stopped giving me tracebacks! http://pastebin.ca/1021882 but I get a bunch of conflicts. should bzr replay be done with -r2.. (revision 2 is identical in contents) or the revision that followed?
[15:09] <jelmer> nekohayo: the branches probably have different file ids
[15:09] <nekohayo> jelmer: well, I assume so, they were different branches... what do I do?
[15:10] <jelmer> the maptree stuff should be able to help there (it makes rebase/replay use paths rather than file ids) but that's not hooked up to the rebase ui yet (only used by svn-upgrade)
[15:11] <jelmer> so it's not really possible to use rebase/replay in this case
[15:11] <nekohayo> >_<?!
[15:12] <nekohayo> I don't exactly see what's so unusual with my case :|
[15:12] <jelmer> different file ids
[15:17] <nekohayo> jelmer: what is a fileid actually? and how could branches that were not historically connected ever have matching file ids?
[15:17] <jelmer> nekohayo: a file id is a unique string that identifies a file. It's generated when it is first added to bzr
[15:17] <jelmer> nekohayo: there's no way for historically not connected branches to have the same file ids
[15:19] <nekohayo> so there's no way to go further now? solving the conflicts wouldn't do it?
[15:20] <jelmer> nekohayo: you can use diff + patch manually to replay each commit so you end up using the file ids from the branch you're building on rather than the branch you're replaying
[15:22] <nekohayo> basically recommitting everything by hand
[15:22] <jelmer> yes
[15:22] <jelmer> I'm not aware of any bzr plugins at that can do that for you
[15:23] <jelmer> rebase/replay could do it if you hooked up the maptree stuff
[15:23] <nekohayo> how hard is that?
[15:25] <jelmer> should be a matter of adding a call to MapTree() in the function that replays a delta in rebase
[15:26] <lifeless> jelmer: yes, thats right - I've been working on 'VersionedFiles' the consolidation of knits etc
[15:26] <lifeless> jelmer: that will let me loosen the constraint on version locking in shallow-ranch, and also get good performance for checkout() over the network.
[15:27] <nekohayo> rebase.py:410:def replay_delta_workingtree(wt, oldrevid, newrevid, newparents,
[15:31] <nekohayo> jelmer: I see that there is a file bzr-rebase/site-packages/bzrlib/plugins/rebase/test_maptree.py
[15:32] <nekohayo> but I don't understand it
[15:32] <jelmer> nekohayo: you'd need the code in maptree.py
[15:34] <jelmer> and wrap the other tree specified to merge in replay_delta_workingtree() with MapTree()
[15:40] <nekohayo> x_x beyond my skillset I guess
[15:40] <nekohayo> or is there a bug/blueprint I can subscribe to for rebase to support maptree?
[15:41] <jelmer> no, though you could file one
[15:54] <Verterok> Hi
[15:54] <Verterok> nekohayo, jelmer: maybe using fastexport/fastimport to replay the commit?
[15:54] <Verterok> s/commit/commits/
[15:55] <lifeless> jelmer: so look for those mails :)
[15:56] <lifeless> vila: isn't your new POST bug a dupe?
[15:57] <vila> lifeless: I was unsure and wanted a reference to put in my merge request for #230223
[15:57] <vila> lifeless: bug #231649 is for the *test* servers
[15:58] <lifeless> vila: anyhow, do you have time to look at http vs sftp pull performance?
[15:59] <vila> ghaaa, still trying to clean up my plate, I think I shoudl decline :-/
[16:00] <vila> I really really really want to write that use-a-real-server-for-tests plugin now
[16:01] <vila> lifeless: wait a minute, what are you talking about ? http vs sftp ? Care to help me page in ?
[16:04] <lifeless> vila: couple days ago
[16:04] <lifeless> vila: kinnison was saying 'pull never utilises full bandwidth'
[16:04] <lifeless> vila: I said 'try sftp'; he did and it maxed his link out
[16:05] <lifeless> vila: he had been pulling over http
[16:09] <vila> so sftp utilizes full bandwidth but http not ? If it's with urllib, that's a regression from the time I rewrote the streaming part.
[16:12] <vila> trying.
[16:15] <vila> branch uses full bandwidth AFAICS, or not ? Seems like many pack files are involved.
[16:16] <vila> sftp doing asynchronous IO thanks to paramiko may explain a bit of difference
[16:17] <nekohayo> jelmer: think that could work?
[16:18] <jelmer> nekohayo, not familiar enough with fastexport/fastimport
[16:18] <nekohayo> Verterok: never tried them, any pointers how to go about it?
[16:19] <vila> lifeless: indeed, pull seems worst than branch for bandwith (did a test with bzr branch -r 3300 bzr.dev tests; cd test; bzr pull bzr.dev
[16:19] <jelmer> lifeless, any chance you can merge bzr.dev in your shallow branch branch?
[16:19] <Verterok> nekohayo: I'm not an expert, but played a bit with it :)
[16:20] <Verterok> nekohayo: first do an fastexport of the branch, then you can write your own  processor to filter whatever you need to
[16:21] <Verterok> and do a fastimport, using the your custom proccessor
[16:27] <lifeless> jelmer: I will, once I have all tests passing with no repository._revision_store
[16:27] <lifeless> jelmer: e.g. probably tomorrow
[16:27] <jelmer> lifeless, ok
[17:08] <vila> lifeless: bzr: ERROR: Not a branch<EMAIL_ADDRESS>???
[17:09] <bob2> are you a member of the bzr group?
[17:10] <vila> bob2: I hope so :)
[17:11] <bob2> hehe
[17:24] <lifeless> vila: ?
[17:25] <vila> lifeless: shouldn't there be a branch there ?
[17:25] <lifeless> interesting
[17:26] <lifeless> vila: no
[17:26] <lifeless> vila: its not hosted on launchpad
[17:26] <lifeless> vila: its mirrored there only
[17:26] <vila> simple, clear. Thanks lifeless :)
[18:05] <abentley> vila: We are hoping to make our sftp and bzr+ssh services behave the same.  So that branch might be available on sftp after the next launchpad release.
[18:07] <abentley> vila: I worked on that with jml.  It was rather tricky because the sftp server is twisted, and bzr+ssh is synchronous.
[18:09] <vila> abentley: thanks for the info, what I was searching for was a branch that I can access with http and sftp with the same network context cot ompare respective performances, I totally forgot that I was accessing different hosts on lp, so...
[18:09] <vila> s/cot/to/
[18:12] <abentley> vila: I think the host is the same in both cases.  The problem is really that there are two different areas on launchpad; the hosted area and the mirrored area.  http gives access only to the mirrored area (which contains copies of hosted branches).  sftp gives access only to the hosted area.
[18:12] <abentley> bzr+ssh gives access to both, preferring hosted.
[18:14] <vila> abentley: thks.
[18:15] <abentley> np
[18:22] <vila> grr, what is the difference between code.lp.net and bazaar.lp.net ? bazaar is giving me a 502 Bad Gateway after a 215s timeout where code seems to issue a redirection (triggering a bug in the nosmart+ decorator by the way) 8-(
[18:24] <beuno> vila, I think code.lp is used for the web app, and bazaar.lp is for actual branches
[18:24] <beuno> morning  :)
[18:24] <vila> beuno: hi :)
[18:49] <vila> !paste
[19:00] <lifeless> see you all tomorrow
[21:24] <MachinShin> hey guys, getting this error, what can i do to fix it? ->bzr: ERROR: Unsupported protocol for url "sftp://<censored>/trunk": Unable to import paramiko (required for sftp support): No module named paramiko"
[21:24] <mwhudson> beuno: damn loggerhead -- i bounced it
[21:24] <jelmer> MachinShin, install paramiko
[21:30] <MachinShin> thanks jelmer
[21:50] <Peng> Ok, this is weird. I'm reading Ben Finney's posts on the mailing list while watching the Star Trek TOS episode about Lt. Cmdr. Ben Finney.
[21:51] <pickscrape> Maybe they used bzr for source control when programming the LCARS system?
[22:21] <thumper> morning
[22:21] <thumper> jelmer: are you available for a few questions?
[22:21] <jelmer> thumper, hi
[22:21] <jelmer> thumper, sure
[22:22] <thumper> jelmer: There are two branches on launchpad that are causing many errors right now
[22:22] <thumper> jelmer: and both are bzr-svn branches
[22:22] <thumper> jelmer: one is yours, and one is a friends
[22:22] <thumper> jelmer: LP is failing to scan them properly as it is failing some basic integrity checks on revisions
[22:22] <thumper> jelmer: one thing we do is to check the revisions to make sure that the parentage hasn't changed
[22:23] <thumper> jelmer: but for these two branches it appears that between scans, the parents of some revisions did change
[22:23] <thumper> jelmer: I was under the impression that bzr revisions didn't change once they were created
[22:23] <jelmer> thumper, that's correct
[22:23] <thumper> s/didn't/shouldn't/ ?
[22:23] <jelmer> which branches are these?
[22:24] <thumper> https://code.launchpad.net/~jelmer/python/trunk is one
[22:24] <thumper> RevisionModifiedError: parent svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:55872 was added since last scan
[22:24] <thumper> jelmer: that is the error I am seeing
[22:25] <jelmer> to which revision was that parent added?
[22:26] <thumper> jelmer: unfortunately I don't think I have that information easily to hand
[22:26] <thumper> jelmer: what can I provide in order to help track this down?
[22:26] <jelmer> thumper: details about which revision apparently changed parents
[22:26] <thumper> ok
[22:26] <thumper> is that all?
[22:27] <jelmer> thumper: Also, is this integrity checking done across branches?
[22:27] <thumper> jelmer: yes
[22:27] <thumper> that may be the underlying problem
[22:27] <thumper> we store a copy of the revisions in the database
[22:27] <jelmer> in that case it's probably that one of the branches was created using an experimental version of bzr-svn
[22:27] <thumper> which includes parentage
[22:28] <thumper> hmm...
[22:28] <thumper> this is an interesting problem to solve then
[22:29] <jelmer> thumper: I think one of the branches just has to be thrashed
[22:29] <thumper> jelmer: is there any way to determine which branch is the one created with the experimental bzr-svn?
[22:30] <jelmer> well, recreating that branch using a stable version of bzr-svn
[22:31] <thumper> jelmer: ok, thanks
[22:41] <xif> How, and how well, does bzr support the following development process:
[22:41] <xif> The project has the following root directories: /linux, /osx, and /osx-diffs. Each time a developer commits /linux/foo.conf, the SCM applies the /osx-diffs/foo.conf.diff to it, and then commits it /osx/foo.conf.
[22:41] <xif> (commits it as the file /osx/foo.conf)
[22:43] <thumper> xif: sounds like a candidate for looms
[22:43] <thumper> xif: as long as you didn't have bidirectional diff application
[22:44] <thumper> xif: you could have /linux as the base thread
[22:44] <thumper> xif: and /osx os the next thread
[22:44] <thumper> xif: and the difference between them is effectively the /osx-diffs
[22:45] <thumper> xif: there is an export-loom command that can create branches for each thread
[22:45] <xif> thumper: very cool... I'm looking at this right now
[22:45] <thumper> xif: you would commit on /linux
[22:45] <thumper> xif: then switch up to /osx
[22:45] <thumper> xif: and merge, resolve and commit
[22:45] <thumper> at least that is how I think it would work
[22:46] <xif> yeah, it definitely looks interesting...
[22:46] <xif> I'm reading about it right now: http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/
[22:46] <xif> thumper: thanks for the recommendation :)
[22:46] <thumper> xif: np
[23:13] <Peng> Wouldn't branches work too?
[23:28] <xif> Peng: how, exactly?
[23:32] <Peng> I dunno.
[23:32] <Peng> I have very little experience with looms, but how are looms better than branches for this? Avoiding lots of merge revisions?
[23:36] <awilkins> I have a feeling I should have used looms for one of my projects after reading that page
[23:37] <awilkins> My example is patches to a set of model files (written as Java) ; one set of patches that was compatible with the old model, one that was for the new software and wasn't
[23:37] <awilkins> I was managing that as two branches ; and I was making compatible changes in one branch and merging up to the other, but it sounds like I should have made a loom and had a compatible thread and an incompatible thread
[23:38] <awilkins> It would at least have beem more conveneient
[23:38]  * awilkins is tired and his fingers are slipping
[23:40] <awilkins> I still don't think it easily addresses what to do when you are making changes and one part of them should be in a thread lower than you are on...