 Hey Folks I've been talking with Ovidiu Florin-Bogdan, and we're planning  to open the Kubuntu Kafe for a 20.04 Release Party.
 Here is a very basic Show Planning / Note page
 https://phabricator.kde.org/w/kubuntu/kubuntu_kafe/shownotes/20.04_release_party/
 So more the Kafe to the general Kubuntu YouTube account?
 @Sick_Rimmit
[21:13] <valorie> oh how fun, @Sick_Rimmit
[21:13] <valorie> it will be good to see your faces again
 Yes, I hope it will be an opportunity to celebrate and have a good time.
 We're going to keep it informal, and just see how it rolls


[08:54] <evaluate> Hello.
[08:54] <evaluate> If a new release of a program is made, that only includes bugfixes, does it have any chance of making it in for oneiric?
[09:55] <alkisg> I have a package which installs a program that runs on user logon. So when a user installs the package, he needs to logoff/logon for my invisible (no gui) user-session-based "service" to run from /etc/xdg/autostart.
[09:55] <alkisg> Does the packaging policy allow me to run it from postinst as the SUDO_USER, if I detect that that env var exists, and X is running?
[10:22] <tumbleweed> alkisg: I don't think that would be desireable
[10:45] <alkisg> Thank you tumbleweed, I'll put a note for the users to the docs that they need manually start it or logoff+logon
[13:01] <bdrung> tumbleweed: housten, we've had a problem: https://launchpadlibrarian.net/82843129/buildlog.txt.gz
[13:02] <nigelb> *Houston ;)
[13:06] <tumbleweed> bdrung: yeah, noticed that
[13:13] <bdrung> tumbleweed: the typo or the build failure? ;)
[13:20] <tumbleweed> bdrung: the build failure, hadn't got as far as the typo
[13:23] <bdrung> tumbleweed: any idea how to solve this build failure?
[13:26] <tumbleweed> not immediately obvious, and I can't look right now
[14:12] <tumbleweed> bdrung: ah, that was easy. The new binary packages are in NEW
[14:14] <bdrung> :)
[14:30] <ari-tczew> wgrant: could you upgrade this page http://qa.ubuntuwire.org/multidistrotools/all.html to precise?
[14:32] <CarlFK> http://packages.ubuntu.com/search?suite=default&section=all&arch=any&searchon=names&keywords=sphinx2-bin
[14:32] <CarlFK> sphinx2-bin isn't in Oneiric. what' the process for getting it in?  (I am assuming I can port the natty version forward)
[14:54] <tumbleweed> CarlFK: https://launchpad.net/ubuntu/+source/sphinx2/+publishinghistory
[14:57] <CarlFK> tumbleweed: thanks.  how do I find out why Status=deleted ?
[14:57] <tumbleweed> click on the arrow and you can see :)
[14:58] <CarlFK> low popcon ?
[14:59] <CarlFK> any idea where I can see Debian bug #624817 (no the lp bug that it links to)
[14:59] <CarlFK> thank you happy robot
[14:59] <tumbleweed> thanks ubottu
[15:01] <CarlFK> grumble.  but thanks.
[15:01] <tumbleweed> CarlFK: you can take over maintainance of it in debian
[15:04] <CarlFK> joy
[18:45] <c_korn> hello, the compilation of pragha fails because of "libtool: link: cannot find the library `/usr/lib/libcurl.la' or unhandled argument `/usr/lib/libcurl.la'" as I see it is in the /usr/lib/x86_64-linux-gnu/ directory on oneiric. how can I fix this?
[18:49] <sladen> c_korn: could you file it in the bug tracker so that it doesn't get lost?
[18:50] <c_korn> uhm, of course. against which package?
[18:50] <c_korn> so the problem is on the Ubuntu side?
[18:50] <sladen> c_korn: but most likely you're probably missing   sudo apt-get install libcurl-dev
[18:50] <sladen> c_korn: there isn't enough information to tell you what/where/how/who the issue is
[18:51] <sladen> c_korn: I don't even eg. know what software you're trying to compile
[18:51] <c_korn> I have libcurl4-openssl-dev installed
[18:51] <tumbleweed> err, no it sounds like it's bearking because curl was multiarched
[18:51] <c_korn> the music player "pragha" http://code.google.com/p/dissonance/
[18:52] <c_korn> (pragha is not in the Ubuntu repositories)
[18:52] <tumbleweed> c_korn: it may be being directed to libcurl.la by another .la file, see if you can see where that came from
[18:53] <c_korn> uff, should I look for some symbolic link now?
[18:53] <tumbleweed> no, other la files probably
[18:55] <c_korn> find /usr/lib -name *.la ?
[18:55]  * tumbleweed tries to build it
[18:55] <jtaylor> it should not need to know the path at all
[18:56] <c_korn> those are my build depends http://pastebin.com/MP5WAdLS
[18:57] <c_korn> I built the libclastfm0-dev library before. but it should be optional.
[18:58] <jtaylor> autsch
[18:58] <jtaylor> it uses LDFLAGS for libraries
[18:58] <jtaylor> that will bite you with as-needed
[19:01] <tumbleweed> erm c_korn, it built for me (make all)
[19:03] <tumbleweed> (i was building 0.99)
[19:03] <c_korn> hum, maybe it is related to my libclastfm library then
[19:03] <tumbleweed> also, I was on amd64
[19:04] <tumbleweed> yeah it might only need curl for lastfm
[19:05] <c_korn> hm, yeah. it also compiles here without my libclastfm library
[19:13] <c_korn> ok, I have rebuilt clastfm and now also pragha compiles with lastfm support. thanks.
[19:33] <c_korn> well, I think this lintian error explains my problems. http://pastebin.com/DJAMXs7H
[19:36] <tumbleweed> :)
[19:45] <c_korn> hm, shouldn't gensymbols automatically been run with compat 8 ?
[19:48] <tumbleweed> before that, even
[19:53] <c_korn> hum, but I had to generate the symbols for myself
[19:53] <tumbleweed> well, the initial symbols list has to be created by hand. After that it'll be verified at build time
[19:54] <c_korn> ah, ok
[19:54] <c_korn> so I delete one line and see what happens ;)
[19:54] <tumbleweed> remember, it'll differ between architectures
[19:54] <tumbleweed> (err, s/will/may/, e.g. if C++)
[19:55] <c_korn> ok, works ;) dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
[19:55] <c_korn> yeah, I already got into that situation once
[19:55] <c_korn> luckily there is the lib.symbols.arch naming rule of the file.
[20:04] <c_korn> what happened to xulrunner in oneiric?
[20:05] <jtaylor> firefox-dev replaces at least parts of it I think
[20:05] <chrisccoulson> we got rid of it
[20:06] <chrisccoulson> firefox-dev exists purely to provide npapi headers. please don't build anything else against it
[20:10] <c_korn> hum, but there is no xulrunner executable any longer?
[20:14] <c_korn> there is the application http://getbuzzbird.com/bb/ which I started with "xulrunner ./application.ini". how should I do that now?
[20:20] <chrisccoulson> c_korn, you can't. we don't support that anymore
[20:20] <chrisccoulson> you could always grab the upstream xulrunner binary though
[20:21] <c_korn> hum, ok
[21:37] <jbicha> what's the easy/correct way to backport from precise to oneiric-proposed?
[21:38] <tumbleweed> easiest is to just upload to oneiric-proposed, and copy-up to precise
[21:38] <jbicha> ok, what if I already uploaded to precise? since the SRU page said bugs should be fixed in the current development release first
[21:38] <tumbleweed> yeah that's not strictly necessary in the first week or so
[21:39] <tumbleweed> I'd just do exactly the same upload, with an SRUish version, to oneiric-propesed
[21:39] <arand> jbicha: There is a good wiki page on SRU:ing, you've read?
[21:41] <jbicha> arand: yes, but I don't always read every word...
[21:41] <jbicha> I'll need to do a -0ubuntu1.1 then?
[21:42] <tumbleweed> jbicha: what package?
[21:43] <jbicha> totem 3.0.1-0ubuntu8
[21:44] <tumbleweed> jbicha: totem already has an upload in -proposed waiting for verification
[21:45] <jbicha> tumbleweed: right, this upload improves the -proposed fix and fixes a second bug while I'm at it
[21:45] <jbicha> basically, how do I fix this? and how do I do this correctly next time?
[21:46] <tumbleweed> ok, I'd have said use 3.0.1-0ubuntu5.1 if 3.0.1-0ubuntu7 wasn't already there. Because of 3.0.1-0ubuntu7 you'll have to use 3.0.1-0ubuntu7.1 (which is a little misleading, in that it looks like the first SRU)
[21:47] <tumbleweed> you just note on the bug that you're about to replace the proposed versoin with another one, so don't verify it yet
[21:47] <jbicha> so 7.1 or 8.1 then?
[21:48] <tumbleweed> jbicha: it needs to be lower than the version in later releases, so 7.1
[21:48] <jbicha> I was thinking I'd just sync from precise but it looks like that doesn't really work the same way syncing from Debian does
[21:48] <jbicha> ok, and how does copying up work?
[21:50] <tumbleweed> jbicha: if oneiric and precise currently have the same versions, you can upload to -proposed, and ask for the upload to be copied to precise when it's accepted. (as if you'd uploaded it before precise opened) But this should only be done in the first week or so


[00:00] <lifeless> ah yes, we're not doing the original merge sort anymore
[00:00] <lifeless> well we're doing the same order but different numbers?
[00:00] <jam> lifeless: right, same ordering
[00:00] <jam> new root nodes would post-increment the branch counter
[00:00] <jam> while new intermediate nodes would pre-increment it
[00:01] <jam> so there are 2 "0.8.1" revisions right now
[00:01] <lifeless> I read the patch :)
[00:01] <jam> lifeless: We also should have a fix for ghosts
[00:01] <jam> For the immediate work, I'm replicating bzr.dev
[00:01] <jam> and pre-filtering ghosts
[00:02] <igc> poolie: awake now
[00:02] <lifeless> by fix you mean: a ghost should reserve a revno for itself' ?
[00:02] <jam> lifeless: right
[00:02] <jam> At least, that is my idea
[00:02] <jam> I could implement it either way
[00:02] <lifeless> I think thats wrong - because there is an unknown quantity of revnos to reserve
[00:03] <lifeless> one is no more or less correct than 0 or 50000
[00:03] <lifeless> and as it is a ghost we have no information to show about it in log etc
[00:03] <lifeless> actually, by wrong I mean no more correct than our current behaviour.
[00:04] <Odd_Bloke> jam: Well, yes, but that's not the sort of job I can get a mortgage with. ;)
[00:04] <jam> lifeless: I sort of understand your point, but there is also: http://rafb.net/p/hfnZd187.html
[00:04] <jam> Assume 'C' is a ghost in both cases
[00:04] <jam> In the latter, a spot is reserved for 'd'
[00:04] <lifeless> D is not a ghost right?
[00:04] <jam> lifeless: correct
[00:04] <lifeless> what revno does D get today
[00:05] <jam> 0.1.1
[00:05] <jam> today
[00:05] <lifeless> and you are saying it should get 0.1.2
[00:05] <lifeless> ?
[00:05] <jam> lifeless: yes
[00:05] <jam> C would be 0.1.1 in both cases
[00:05] <lifeless> but what if theere is F, a parent of C in both cases
[00:05] <jam> lifeless: obviously we can't go into nodes that we haven't seen at all
[00:06] <jam> parents of ghosts
[00:06] <poolie> good morning igc :)
[00:06] <jam> I *can* mimic current behavior
[00:06] <jam> it just turns out to be *more* work
[00:06] <lifeless> I don't see what paste as an argument for or against; one graph isn't a subset, theres no reason for numbers to be stable
[00:06] <jam> And I'm hesitant to write tests that require it
[00:06] <jam> morning igc
[00:06] <poolie> it's desirable they be stable across releases
[00:07] <igc> hi jam, lifeless
[00:07] <lifeless> poolie: we've violated that so hard that integer is seeking a restraining order on bzr
[00:07] <jam> poolie: well, they are already going to change as of today :)
[00:07] <jam> though not dramatically
[00:07] <lifeless> jam: I'm all for doing less work; but I'd justify it on that basis not on correct, as correct is ... vague here
[00:07] <jam> just removing a bug for it
[00:09] <jam> lifeless: sure, I suppose I'm a bit concerned about knock-on effects
[00:09] <jam> right now, because we prune ghosts
[00:09] <jam> the next layers don't worry about whether 'get_revision()' could fail
[00:09] <lifeless> I'd expect log to fail
[00:09] <lifeless> etc
[00:10] <jam> though, I have gotten the feeling we've been trying to push ghost handling further up the stack
[00:10] <lifeless> jam: we want to stop hiding bugs
[00:10] <lifeless> for instance a ghost on the mainline should be supportable
[00:10] <jam> So 'bzr log' could just show that there is a known revision_id, even if it doesn't know the info
[00:11] <jam> poolie: the one "savior" here, is that it is only changing the "0.X" numbers
[00:12] <jam> the rest of the numbers are stable either way
[00:12] <jam> 0.X.Y, I guess
[00:13] <jam> I guess I'll stick with the current scheme, going via the "principle of minimal change"
[00:13] <jam> I might just comment out those tests
[00:14] <lifeless> erm
[00:14] <lifeless> delete
[00:15] <lifeless> or fix
[00:15] <lifeless> please
[00:17] <jam> anyway, enjoy your day
[00:19] <lifeless> you too
[00:19] <lifeless> I'm wowing tomorrow FWIW
[00:24] <lifeless> jam: do we nest branches as deeply as the original merge_sorted did ?
[00:43] <lifeless> oh wow WT.remove is crufty
[01:18]  * igc bbl
[01:56] <rocky> jelmer: you use trac-bzr much?
[02:07] <lifeless> jam: ping; an ack on my reply-to-the-annotate-patch would be nice
[02:21] <laszlok> lifeless: ping
[02:22] <lifeless> laszlok: hi
[02:23] <laszlok> re the jokosher email, what does remixing mean?
[02:23] <lifeless> changing things around
[02:24] <lifeless> if you're happy with the branches and tags you have today, then you don't need to change stuff - just convert systems
[02:24]  * jdong resists temptation to turn "remixing" into a Barack Obama energy plan jab....
[02:25] <laszlok> basically branch refactoring
[02:25] <lifeless> yup. its much more complex to do that; but I got the impression from your mail that you had something other than a direct switch in mind
[02:27] <laszlok> not particularly, i think as long as all out svn branches come out as separate bzr trees it should be okay
[02:27]  * laszlok checks the stale branches in the svn repo
[02:27] <lifeless> yes, they should
[02:28] <laszlok> so the svn import will automatically split them up into different repos
[02:28] <lifeless> if you install bzr-svn and just run bzr svn-import SVN_REPO_ROOT /tmp/svn-conversion
[02:28] <laszlok> different repos with the same parent
[02:28] <lifeless> we'll know soon enough
[02:28] <lifeless> svn-import can be run incrementally so you could do this somewhere more persistent than /tmp too :)
[02:29] <laszlok> launchpad it currently mirroring the svn trunk, is there a special way to import it, or is it just a simple push?
[02:29] <lifeless> this will supercede the launchpad mirror
[02:30] <lifeless> we'll end up with a bunch of branches - you can push some or all of them to launchpad, owned by you, or by a jokosher team if you have one
[02:30] <lifeless> and we'd turn off the launchpad mirror of svn trunk
[02:46] <emgent> beuno: ping
[02:53] <laszlok> lifeless: i did the svn-import with the repositiory root, but all the branches and tags directories are now in the bzr branch :/
[02:53] <lifeless> laszlok: really? It should create many branches in a shared repository
[02:54] <laszlok> how do i get a list of branches in the shared repo
[02:55] <emgent> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[02:55] <emgent> some idea?
[02:55] <emgent> i'm on intrepid.
[02:55] <emgent> ssh-add dont work.
[02:55] <lifeless> laszlok: 'bzr branches'
[02:55] <lifeless> (or just ls :))
[02:55] <laszlok> yeah there are none
[02:55] <lifeless> laszlok: how big is the output directory?
[02:55] <lifeless> and whats the jokosher svn url
[02:56] <laszlok> 26MB, and when i do a branch of the shared branch the files appear
[02:56] <laszlok> do the branches/ and tags/ dirs have to be at the top level?
[02:57] <lifeless> laszlok: I'll defer to jelmer: on that;
[02:57] <laszlok> cause in jokosher we have modules with separate branches and tags folders
[02:57] <lifeless> whats the svn repo url ?
[02:57] <laszlok> maybe that confused it
[02:57] <laszlok> http://svn.jokosher.python-hosting.com
[02:59] <lifeless> I was fairly sure that this is a common layout bzr-svn understands
[02:59] <lifeless> oh except -art and -extra are different
[02:59] <laszlok> right because they don't release
[03:00] <laszlok> stupid historical reasons
[03:00] <lifeless> so you want four projects essentially?
[03:00] <laszlok> if we can just get JonoEdit converted, that will be enough
[03:01] <laszlok> gst-chanplit is in gstreamer-cvs now, and the other two are just files. ie no history needs to be saved
[03:01] <lifeless> ok
[03:02] <laszlok> laszlo@sescento:~/Software/svn/bzr-jokosher-convert$ bzr st
[03:02] <laszlok> bzr: ERROR: No WorkingTree exists for "file:///home/laszlo/Software/svn/bzr-jokosher-convert/.bzr/checkout/".
[03:03] <laszlok> if i branch from bzr-jokosher-convert, then i have a proper working directory
[03:03] <laszlok> strange
[03:06] <lifeless> laszlok: the converter doesn't create working trees because you can end with with gb's of data that way
[03:06] <lifeless> laszlok: imagine a svn repo with several thousand branches/tags
[03:06] <lifeless> maybe all of them are shared history
[03:07] <laszlok> okay, but doesn't svn do the same thing when you checkout the entire repo?
[03:09] <lifeless> svn will create working trees because all the svn commands to get data locally are working tree centric
[03:13] <lifeless> so svn checkout some-root will indeed give huge downloads and huge disk usage
[03:13] <lifeless> this isn't really a feature
[03:26] <laszlok> okay its getting late. thanks for you help lifeless, i will try to see why it isn't splitting the branches tomorrow
[03:27] <lifeless> laszlok: gnight
[03:35] <ToyKeeper> If I merge in an unrelated branch and it adds a file with the same name as a previously ignored/unversioned file, is there a way to make bzr not treat it as a conflict?
[03:35] <ToyKeeper> Or, at least, not report a conflict if the files are identical?
[03:39] <spiv> ToyKeeper: Well, you can just do "bzr resolve FILE" manually after the merge.
[03:39] <ToyKeeper> Yeah, I do.  It just seems odd to conflict when the files are identical.
[03:40] <ToyKeeper> ... just running some experiments for keeping $HOME in bzr.
[03:40] <spiv> I know what you mean.  bzr is being conservative and so assumes they have different identities in that situation, regardless of content.
[03:42] <ToyKeeper> I think I'll probably stick with my current svn-based home repo, but it's interesting to find ways to do similar things in bzr.
[03:42] <spiv> It would probably be fairly easy to write a plugin to add a "resolve-harder" command that would notice that situation and auto resolve them for you.
[03:43] <ToyKeeper> I'm using externals and partial checkouts and symlinks extensively in svn, so the approach is rather different with bzr.
[03:43] <jelmer> laszlok, bzr-svn should be able to deal with branches/tags at non-top-level
[03:44] <spiv> Maybe bzr should deal better with that case natively, although "unversioned file with same contents as added-by-merge file" does sound like a fairly rare case.
[03:45] <ToyKeeper> spiv: Yeah, pretty uncommon.  I had never encountered it until I tried to do something funky.  :)
[03:46] <spiv> It's also a bit confusing I think how bzr can have conflicts involving unversioned files; I've seen that surprise people (mainly in the context of the 'bzr up causes weird merge-conflicts-conflicts' bug)
[03:46] <lifeless> laszlok: it worked for me:
[03:46] <lifeless> $ bzr branches repo
[03:46] <lifeless> JonoEdit/branches/0.1
[03:46] <lifeless> JonoEdit/branches/0.2
[03:46] <lifeless> JonoEdit/branches/0.9
[03:46] <lifeless> JonoEdit/branches/Elleo-SoC
[03:46] <lifeless> JonoEdit/trunk
[03:46] <ToyKeeper> It's not very well-suited to tracking $HOME.  I love bzr for most purposes, but it's not as good as svn at being a versioned filesystem with different views on every checkout.
[03:46] <lifeless> gst-chansplit/trunk
[03:47] <laszlok> lifeless: what command did you use for conversion?
[03:48] <lifeless> bzr $ cd /tmp/
[03:48] <lifeless> $ mkdir jokosher
[03:48] <lifeless> $ cd jokosher/
[03:48] <lifeless>  bzr svn-import http://svn.jokosher.python-hosting.com repo
[03:52] <ToyKeeper> Hmm, this still isn't fixed.
[03:52] <ToyKeeper> w3m -dump http://www.jokosher.org/ | grep -i viagra | wc -l
[03:52] <ToyKeeper> 18
[03:56] <lifeless> oh yay hackage lol
[03:56] <laszlok> lifeless: before it was copying x/1500 revisions, now its doing x/1391. So its not copying the entire repo
[03:56] <laszlok> i guess it working now
[03:57] <lifeless> laszlok: you might want to edit that homepage
[03:57] <lifeless> laszlok: to remove the advertising spam :P
[03:57] <laszlok> ToyKeeper: yeah we know but jono is too lazy to do anything about it
[03:57] <lifeless> oh, only jono can edit ?
[03:57] <laszlok> yeah its on his host
[03:57] <lifeless> hah!
[03:57] <laszlok> i dont think hes upgraded his wordpress in a while either
[03:58] <lifeless> mailed him a nag
[04:03] <laszlok> just reading the chan topic, was there a bitkeeper->bazaar converter before, or was it special for mysql?
[04:04] <lifeless> there were some tools that could poke at bitkeeer
[04:22] <Stumbles> i'm storing some php files in a bazaar branch and publishing it via my http on my website. Was surprised to see that you could use "bzr branch" to get the php files without them being executed. How does that work? If I try to get the php file, say with wget, it gives me the output of the php script.
[04:24] <spiv> bzr branches are stored in special files in .bzr/ directories, rather than just as the original files.
[04:24] <Stumbles> oooooh right, confusing the working-copy/repository issue
[04:24] <Stumbles> thanks spiv
[04:25] <spiv> Right.
[04:25] <Stumbles> just got a bit of a fright that I might have been overlooking something that allowed people to download all my .php database config files ;)
[05:02] <beuno> emgent, pong
[05:10] <laszlok> lifeless: i think i found the problem; there was a branching-scheme = single-JonoEdit in the ~/.bazaar/subversion.conf from a previous checkout
[05:11] <lifeless> laszlok: that would do it
[05:14] <emgent> beuno: i saw your bzr-upload
[05:14] <emgent> seems very good plugin :)
[05:14] <emgent> are you packaging it ?
[05:14] <beuno> emgent, thanks :)   jelmer has packaged it
[05:14] <beuno> he's looking for a sponsor to get it into Debian
[05:15] <emgent> oh nice!
[05:16] <emgent> I was thinking but now is ok :)
[05:16] <emgent> s/but/to package it but/
[05:16] <beuno> emgent, cool, thanks anyway.  There may be other bzr plugins in need of packaging
[05:20] <beuno> emgent, seems I found a sponsor, and it's being built now!
[05:20] <beuno> (talk about coincidence)
[05:21] <emgent> nice :)
[05:21] <beuno> emgent, if you could request the sync into intrepid once it's uploaded, that would be great
[05:21] <emgent> uhm.. but debian NEW package need FTP master work :)
[05:22] <emgent> beuno: sure will do when i see it in debian :)
[05:22] <beuno> emgent, yeah, and it's debconf now, so it will take a while
[05:22] <emgent> s/see/will see/
[05:22] <emgent> true :)
[05:22] <emgent> ~1 month
[05:22] <emgent> hhehehe
[05:22]  * beuno crosses fingers
[05:22] <emgent> Debian FTP Masters are very slow :)
[05:23] <beuno> yeah, and even more so if they're full of bear on a beach in winter
[05:23] <emgent> heheh true :)
[05:45] <mxpxpod> can bazaar do partial branches?
[05:46] <beuno> mxpxpod, partial as in history or as in files?
[05:46] <mxpxpod> as in files
[05:46] <mxpxpod> like, if I just want to grab one directory out of a branch
[05:47] <beuno> you can't currently do that, no
[05:47] <mxpxpod> is support for it coming?
[05:47] <lifeless> mxpxpod: yes
[05:47] <mxpxpod> lifeless: is there a blueprint for it?
[05:48] <beuno> Verterok, ping
[05:48] <Verterok> beuno: pong
[05:48] <beuno> Verterok, hi!  Just saw you released xmlouput 0.5. Cool!   Just one thing, did you maybe link it incorrectly on the wiki?
[05:49] <Verterok> beuno: let me check
[05:49] <Verterok> beuno: yeap, copy & paste madness :P, thanks for pointing it ;)
[05:50] <beuno> Verterok, :)    I wasn't sure which part was mixed up
[05:51] <Verterok> beuno: fixed now
[05:51] <beuno> Verterok, thanks
[05:52] <Verterok> beuno: actually, thank you :)
[05:52] <mxpxpod> lifeless: because I'm not seeing anything on it
[05:55] <lifeless> mxpxpod: the concept is called 'views' and Ian Clatworthy has been doing most towards it
[05:55]  * beuno heads to bed. Have to go pick up someone at the airport in 5 hours  :/
[05:55] <mxpxpod> lifeless: ok, thanks
[05:56] <lifeless> night beuno
[05:56] <beuno> g'night lifeless!
[05:56] <beuno> have a good weekend
[05:57] <lifeless> you too
[05:57] <beuno> Verterok, we should meet up soon and get the automatic testing on it's way  ;)
[05:58] <Verterok> beuno: indeed
[05:59] <Verterok> beuno: there are big chances that I'll be offline during saturday, maybe I can start hacking a proof of concept :)
[06:00] <lifeless> auto testing?
[06:00] <beuno> lifeless, we're planning to setup a server which auto-updates and runs the full test suite against all the plugins
[06:00] <beuno> get reports
[06:01] <lifeless> beuno: thats a good idea
[06:01] <beuno> and maybe send them to the list, if people don't get annoyed by them
[06:01] <lifeless> beuno: can I suggest separately running the set that my patch bundles?
[06:01] <lifeless> (Preferrably by doing the bundling action and seeing what works)
[06:01] <beuno> lifeless, so, full test suite, and then just the plugin's?
[06:02] <beuno> we want to catch plugins that break bzr, and plugins that bzr breaks
[06:02] <lifeless> the full test will include the bundled plugins
[06:02] <lifeless> beuno: you saw the patch I'm referring to right?
[06:02] <beuno> lifeless, nope, not that I recall
[06:02] <Verterok> lifeless: that  sounds like a good start point, and from there start adding extra plugins :)
[06:03] <lifeless> pls wait for BB
[06:03] <lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1217210104.21600.106.camel%40lifeless-64%3E
[06:03] <lifeless> that patch
[06:03] <lifeless> ubottu: please be learning about bb, kthxshutup
[06:03] <lifeless> ubottu: hey, I told you to shutup alread
[06:04] <beuno> lifeless, ah, I understand. The more "official" plugins
[06:04] <beuno> or the ones that will be bundled, so we need to pay more attention to
[06:04] <lifeless> beuno: well specifically - *what the tarball will have and how it will install*
[06:05] <lifeless> which is different from taking the list, installing from the plugins own installer
[06:07] <beuno> lifeless, ok, sounds like a good idea. From the looks of it, they just get copied, instead of being installed.
[06:07] <lifeless> they get copied into the tarball; and then the bzr installer copies them out again yes
[06:07] <lifeless> thats the open bug in the patch discussion in fact :)
[06:08] <lifeless> now, if someone wanted to fix that ... that would rock :)
[06:08] <beuno> Verterok, we'll ping-pong over the weekend then, and see where we get, and when you're free
[06:08] <beuno> lifeless, the bug being the individual setup's don't get run?
[06:08] <lifeless> yes
[06:08] <lifeless> most plugins won't give a rats
[06:08] <lifeless> but some will
[06:08] <lifeless> so we need to figure out how to do that gracefully
[06:09] <beuno> ok, we'll see what comes out of it  :)
[06:09] <beuno> I'm really off now
[06:09] <beuno> night!
[06:09] <Verterok> beuno: tomorrow I'll be at home..
[06:10] <Verterok> beuno: g'night
[06:18] <lifeless> beuno: btw
[06:18] <lifeless> beuno: I've just done partial tree exports
[06:30] <marianom> hi everyone, good night (at least here)
[06:30] <marianom> a little question if you don't mind
[06:31] <marianom> I was committing a change to LP, interrupted it by mistake and now I get a lock: http://paste.ubuntu.com/35401/
[06:31] <marianom> I don't know how to break it. can anyone suggest a way out?
[06:32] <lifeless> marianom: bzr should have broken the lock when you hit ctrl-C, unless you were physically interrupted?
[06:32] <lifeless> anyhow, bzr break-lock URL
[06:32] <marianom> lifeless: I was the cause of the error, however I did a break lock but get the unsupported error
[06:33] <marianom> I used the same info I got from the error message to perform the action
[06:33] <lifeless> marianom: oh the error is borked there is a bug
[06:33] <lifeless> pass the url to your branch
[06:33] <marianom> upps
[06:33] <marianom> ok
[06:33] <marianom> https://code.edge.launchpad.net/easyark/trunk
[06:37] <lifeless> all sorted
[06:37] <lifeless> ?
[06:37] <spiv> marianom: bzr+ssh://bazaar.launchpad.net/~easyark/easyark/trunk
[06:38] <spiv> (Or just lp:easyark should work too)
[06:42] <marianom> sorry I didn't get it. Can I try to commit again or should I do something with the command you paste?
[06:44] <spiv> marianom: once you've broken the lock you can commit again, yes.
[06:45] <spiv> marianom: is that clear, or are you still stuck?
[06:45] <marianom> in a minute I tell you spiv
[06:45] <marianom> I did $ bzr break-lock bzr+ssh://bazaar.launchpad.net/~easyark/easyark/trunk
[06:45] <marianom> but I get permission denied
[06:46] <spiv> Oh, you need<EMAIL_ADDRESS>rather than just bazaar.launchpad.net I guess.
[06:46] <marianom> ok let's see
[06:46] <spiv> (I tend to forget that because I've set up my ~/.ssh/config so that I don't need that bit)
[06:47] <spiv> Basically, you just need to use the same branch URL you used to do "bzr co" in the first place.
[06:48] <marianom> ok, the lock is gone, committing now
[06:50] <marianom> it worked. thanks spiv, lifeless for your support
[06:51] <spiv> marianom: great!  Glad we could help.
[07:26] <markh> I've got what seems to be a late regression on windows just before the branch 1.6 was made.  Should I submit it with 1.6 as the target, or still use -dev and note it should also be merged to 1.6, or something else?
[07:28] <spiv> markh: either, probably.  I think BB won't pick it up if you don't target it to bzr.dev, though.
[07:29] <spiv> Typically we use subject lines like "[MERGE][1.6] Fix frobnicator..."
[07:29] <markh> spiv: ok thanks, I'll target .dev and make a note about 1.6
[07:29] <markh> ah - then it implicitly targets both?
[07:29] <spiv> Nah, we do that just for human benefit :)
[07:29] <markh> ie, use that subject line, but attach a bundle targetting .dev?
[07:30] <spiv> (Targetting .dev in the merge directive makes sense because usually bugs in release branches need to be fixed in .dev as well...)
[07:30] <markh> BB then ignores the [1.6], but its a clue for humands :)
[07:30] <markh> yeah
[07:30] <spiv> Happily this doesn't happen often enough that we've really needed smarter tools :)
[07:30]  * markh must have means humanoids
[07:30] <spiv> Or human hands smooshed together.
[07:30] <markh> yeah - I'm saying the tool can ignore the [1.6], but the humanoids can instead.
[07:31] <markh> :)
[07:31] <markh> lifeless caused the regression :)  os.listdir doesn't return errno.ENOTDIR on windows :(
[07:31] <spiv> D'oh.
[07:40] <lifeless> markh: yay!
[07:41] <markh> :)
[08:08] <lifeless> later everyone
[09:16] <jonnydee> Hello lifeless, how are you doing? I did what you suggested yesterday and, indeed, a "bzr pack" on my repository which is located on the network share failed. I've attached it to the Bug report.
[09:28] <jonnydee> hi, just a question: is it ok to change the title of a bug report when the problem has been narrowed down? I've done this right now, but now I wonder if this is appreciated or not.. Could someone give me an advice, please?
[09:29] <spiv> jonnydee: yes, definitely
[09:29] <jonnydee> ok, thanks a lot :)
[09:30] <spiv> Thanks for gardening bugs! :)
[09:33] <awilkins> markh: That's not the only lifeless-related not-a-directory error on windows ; I found one too
[09:34] <awilkins> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C489ACEB7.1010503%40gmail.com%3E
[09:36] <jonnydee> Oh, no problem. I like being able to contribute at least somehow to the wonderful Bazaar community :)
[09:46] <lopio> hi
[09:49] <lopio> a simple question about CRLF: someone said a new feature about CRLF management will be introduced in bzr 1.6; have you got some more  details ? thank you
[09:54] <awilkins> lopio: AFAIK line endings support is not going in because versioned properties are not going in either.
[09:55] <awilkins> lopio: I personally find it less necessary with each passing year ; the only code editor I use that cares is the VB6 IDE, and I never edit that source on Linux anyway.
[09:56] <awilkins> lopio: Do you have something badly behaved that messes with your line endings?
[09:56] <lopio> my problem is that now we develop both under xp and hp-ux using cvs
[09:57] <awilkins> And CVS is the thing messing with the line endings?
[09:58] <lopio> when you checout file under xp a LF is added automatically and when you commit is removed; nothingg is done under HP and everything is right
[09:59] <awilkins> lopio: Are your code editors line-ending aware?
[09:59] <awilkins> (on XP)
[10:00] <lopio> this is possible cause there is such a behaviour when you want to bypass this mechanism for example for binary file (cvs add -kb)  )
[10:00] <awilkins> What are you using? (the windows notepad is about the only editor I know of that isn't ending aware now)
[10:02] <awilkins> lopio: Can your windows folk not move over to using *nix line endings?
[10:02] <lopio> for example if you open a .ksh file file with worpad this file is reformatted
[10:04] <lopio> on the other side .bat file must contains CRLF on XP
[10:06] <lopio> To manage your repository with cvs you have to : 1) add ascii file with cvs add 2) add binary files with cvs add -kb
[10:06] <awilkins> lopio: It sounds like your biggest problem is that Wordpad is rude enough to change line endings without asking you.
[10:07] <lopio> the xp cvs client add or remove LF when co and ci ascii file. nothing else
[10:07] <awilkins> Yes, I understand the feature, I've tutored people on the SVN equivalent.
[10:08] <awilkins> Although I find the SVN behaviour to be better (only do line endings when explicitly told to, not by default)
[10:08] <lopio> I'm not the only developer so i don't know which editors could be used -)))
[10:09] <luks> I don't like that the SVN approach is not user configurable
[10:09] <awilkins> Using Wordpad for code is madness, I tell you, Madness!!!!!   ;-)
[10:09] <luks> if a file has svn:native, I can't use LF on windows even if I want to
[10:12] <awilkins> lopio: At any rate ; I've not seen line ending support being discussed in here or on the list, so I doubt it's going into 1.6 (unless it says so in NEWS, which it doesn't).
[10:12] <awilkins> 1.6 is basically a wrap now in terms of features.
[10:13] <lopio> someone said this cvs / svn mechanism could corrupt files and this is why could not be implemeted in bzr. On the other side i think this could be a blocking problem in a multiplatform environment.
[10:13] <lopio> checkeol plugin is an attempt to solve it
[10:13] <awilkins> The CVS flavour certainly can corrupt files if you forget to mark them as binary ; I've seen cases where this is so
[10:14] <lopio> yes but it's a mistake not a corruption
[10:16] <awilkins> Tell that to Visio when it can't load the file. "Oh, it's just a mistake.....
[10:16] <awilkins> And you can't un-do it because there are a mixture of CRLF and LF sequences in there
[10:17] <awilkins> That's why I like the SVN approach of treating everything as binary by default better
[10:19] <lopio> i agree
[10:20] <lopio> what about this answer in launchpad :
[10:20] <lopio> question "CRLF management will be possible ?"
[10:20] <lopio> vila answer "There is a work in progress regarding eol handling and keywords expansion that may find its way into bzr 1.6, search the <email address hidden> mailing list for 'content filter' to stay tuned."
[10:22] <awilkins> My personal position is that line-ending munging is a feature that scratches an itch which should have gone away a long time ago ;
[10:22] <awilkins> http://search.gmane.org/?query=content+filter&group=gmane.comp.version-control.bazaar-ng.general
[10:24] <awilkins> There's a patch for it in the bundle buggy waiting approval
[10:26] <lopio> awilkins thank you very much for your advice
[10:26] <lopio> bye
[10:39] <awilkins> hello again :-)
[10:39] <awilkins> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4880CF60.2080805%40canonical.com%3E
[10:40] <awilkins> The patch is there, if you want to test it out I'm sure Ian will appreciate any user reports
[10:44] <lopio> hello
[10:44] <lopio> -)
[10:45] <lopio> thank you a lot for your link
[10:45] <awilkins> You're welcome
[10:46] <lopio> excuse me for my bad english and for my too simple question:
[10:48] <lopio> what should i do? install bzr-eol?
[10:49] <awilkins> lopio: For bzr-eol to work, you also need to be running a version of Bazaar with the content filtering feature in it
[10:49] <awilkins> Which is not in the main line but is provided by the patch linked to
[10:50] <awilkins> Or you can pull the branch linked to in the comment
[10:51] <lopio> this patch is developed in a branch (as bzr-eol plugin) , right ?
[10:51] <awilkins> The plugin is separate to the content-filtering branch
[10:53] <awilkins> So you need to grab the content-filtering branch (or merge the patch to bzr.dev) to run the plugin
[11:08] <lopio> Last question -) : after  dowloading this branch  how can i use the new bzr ? via absoluth path? thank you
[11:09] <lopio> excuse me there is an install -(
[11:09] <awilkins> lopio: You could build and install it (a slightly tall order on Windows), but it's probably enough to put the bzrlib on your PYTHONPATH
[11:09] <awilkins> (and remove the old one, of course)
[11:10] <awilkins> Well, might not have to remove the old one if the new one is first on the path.
[11:10] <lopio> now i'm under gentoo and i see 1.6b4 -)
[11:11] <awilkins> I suspect you've just installed it then :-)
[11:11] <lopio> in the afternoon i'll download and try  the bzr-eol
[11:12] <lopio> see you later !!! my wife is calling me -)
[11:12] <awilkins> lopio: Just cd ~/.bazaar/plugins ; bzr branch lp:bzr-eol eol
[11:12] <lopio> thanks
[11:12] <awilkins> Wices eh :-)
[11:12] <awilkins> *wives
[11:12] <lopio> cd ~/.bazaar
[11:32] <Cilyan> Hello everyone !
[11:32] <Cilyan> I have a little question
[11:33] <Cilyan> I use bazaar to control versions of a current work, only for personal use (a sort of advanced backup)
[11:34] <Cilyan> The directory tree is Laas/Rapport, Laas/Simulations Laas/Automatique ...
[11:34] <Cilyan> And at the beginning, I only wanted revisions for my report, so I runned bzr init in Laas/Rapport
[11:35] <Cilyan> But I'd like now to use bazaar in the root directory, but if possible I'd like to keep the commits I have done in Rapport. Is it possible ?
[11:36] <Cilyan> In other words, is it possible to move the root of a bzr vc ?
[11:44] <jonnydee> Cilyan: You could "bzr mv Laas/Rapport Laas/Laas/Rapport"
[11:44] <awilkins> "Laas" isn't versioned
[11:45] <jonnydee> Yes, but what could actually do is to put The versioned Rapport directory under a versioned Laas Directory
[11:46] <jonnydee> So you will have a directurey structure like Laas/Lass/Rapport
[11:46] <awilkins> Yes, he can just move his "Rapport/*" to "Rapport/Rapport/"
[11:46] <awilkins> Then rename "Rapport" to "Laas", and move all the old "Laas" stuff to new "Laas"
[11:46] <Cilyan> So, I have to first init a branch in Laas ?
[11:46] <awilkins> THen add it
[11:46] <awilkins> Cilyan: No
[11:46] <jonnydee> awilkins: that's exactly what I meant
[11:47] <awilkins> Cilyan: Make a new Rapport folder inside Rapport, move the stuff into it, then copy the other folders from "Laas" into your working tree and add them
[11:47] <jonnydee> right :)
[11:47] <Cilyan> Oh, yes, ok :)
[11:47] <Cilyan> brilliant
[11:47] <Cilyan> I try at once
[11:47] <awilkins> You're not moving the root of the tree, your're moving the the stuff in the tree into a lower folder
[11:48] <jonnydee> exactly
[11:50] <jonnydee> This could be maybe an idea for a new plugin. A plugin which simulates extending version control to some parent directory...
[11:50] <Cilyan> I should I proceed if the files are in the root dir ?
[11:51] <jelmer> beuno, thanks for helping bzr-upload again, also to mlt!
[11:51] <Cilyan> oops, forget that ^^'
[11:51] <beuno> jelmer, :)   I made sure lintian didn't complain this time
[11:52] <awilkins> Could someone with BB privs review http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C489ACEB7.1010503%40gmail.com%3E
[11:53] <awilkins> I know it's boring but the regression it reverses breaks tests on Windows.
[11:54] <awilkins> lifeless: You approve it. You submitted the code that broke it, you fix it :-)
[11:54] <Odd_Bloke> awilkins: People will get to it in time. :)
[11:55] <awilkins> Odd_Bloke: It should really be in 1.6 as well as dev, IMHO
[11:58] <Cilyan> Will the files moved keep this directory tree if I need to revert to a previous revision ?
[11:59] <awilkins> Cilyan: No
[12:00] <Cilyan> So they will extract like they where before move
[12:00] <Cilyan> Allright, no matter
[12:05] <Odd_Bloke> awilkins: Make a note on the list to that effect.
[12:18] <Odd_Bloke> Right, I'm off.  See everyone in a week and a bit.
[12:33] <Cilyan> Thanks everyone, it works like a charm !
[12:33] <Cilyan> Bye
[12:51] <lifeless> we will be getting line ending support
[13:23] <manishtech> can anyone help me out a little with bzr checkout?
[13:24] <jonnydee>  I'm relatively new to bzr, but maybe I can...?
[13:24] <manishtech> jonnydee: actually am from svn background, so I am finding it a bit difficult to checkout any code to my machine
[13:25] <jonnydee> My background is svn, too
[13:25] <jonnydee> So what is your question
[13:25] <jonnydee> ?
[13:25] <manishtech> jonnydee: am finding bzr a bit complicated at beginning, i need to checkout tangocms branch on my computer
[13:26] <manishtech> most of the bzr commands are giving error
[13:26] <jonnydee> just do "bzr co URL-TO_BRANCH"
[13:26] <jonnydee> do you have to connect to a svn-repo?
[13:26] <manishtech> jonnydee: i didnt get you... svn-repo?
[13:27] <manishtech> thanks trying bzr co
[13:27] <manishtech> i heard there was something called branch in bzr i tried itbutin vain
[13:27] <jonnydee> I mean do you want to check out a project from a subversion repository via bzr?
[13:27] <manishtech> no..  i need to checkout code from launchpad itself
[13:28] <manishtech> jonnydee: Tangocms is the project which I wanted
[13:28] <jonnydee> well, there is a command "bzr branch", but if you use "bzr checkout" it does feel like a subversion checkout
[13:28] <jonnydee> ok, then you should not do a checkout but you will want to branch
[13:29] <jonnydee> bzr branch URL-TO-PROJECT
[13:29] <jonnydee> just a moment
[13:29] <manishtech> jonnydee: this is the page which I get for TangoCMS https://launchpad.net/tangocms
[13:30] <manishtech> jonnydee: I tried " bzr branch https://launchpad.net/tangocms "
[13:30] <manishtech> this is the error which i got bzr: ERROR: Not a branch: "https://launchpad.net/tangocms/"
[13:30] <chadmiller> manishtech: See that "code" section?
[13:30] <jonnydee> try "bzr branch https://code.launchpad.net/~vcs-imports/tangocms/trunk-imported"
[13:30] <chadmiller> That url is not the branch location.
[13:31] <manishtech> chadmiller and jonnydee: thanks... trying
[13:31] <jonnydee> the one I mentioned should be the right one
[13:31] <chadmiller> Instead, find the actual branch location on the web page.
[13:31] <chadmiller> jonnydee's is likely right.  Also, projects at launchpad have a shortcut.
[13:32] <jonnydee> lp:xxxx -- I know....
[13:32] <jonnydee> or do talk about something different?
[13:32] <chadmiller> You got it, j,  lp:~vcs-imports/tangocms/trunk-imported
[13:33] <jonnydee> AFAIK for using lp:project you should have a ssh-key configured
[13:33] <manishtech> chadmiller: means the syntax should be bzr branch lp:~vcs-imports/tangocms/trunk-imported ?
[13:33] <radix> jonnydee: nope
[13:33] <chadmiller> manishtech: One additional change.  The last part of the branch URL is not very useful, often.  Rename it by specifying a different name at the last parameter.
[13:33] <chadmiller> "bzr branch lp:~vcs-imports/tangocms/trunk-imported tangocms-trunk"
[13:33] <manishtech> jonnydee: ssh key is configured
[13:33] <jonnydee> ok... I seee
[13:34] <manishtech> trying.... checking
[13:34] <manishtech> thanks all.... its working
[13:34] <chadmiller> manishtech: Are you comfortable with the distributed nature of this stuff?
[13:35] <manishtech> chadmiller: worked on svn... not much, but have idea..
[13:36] <chadmiller> You're getting an exact copy of what's on the far end.  The only criteria we don't call your new branch the official trunk are social.  They're the same except in human behavior.
[13:38] <jam> Just to note, if someone associates a branch with the development focus of a project "bzr co https://launchpad.net/tangocms" would actually work
[13:38] <jam> (it does for 'bzr' for example)
[13:38] <jam> Though I would recommend "bzr co lp:tangocms" at that point, because it is shorter :)
[13:38] <jonnydee> jam: so this has to be done on the launchpad site directly
[13:38] <jonnydee> ?
[13:39] <manishtech> jam: how are co and branch different... its a silly question
[13:39] <jonnydee> co more behaves like svn
[13:39] <jonnydee> with one exception:
[13:39] <jam> jonnydee: Registering a "focus of development" does, indeed, need to be done on LP
[13:39] <jonnydee> you build up remote history and local history
[13:39] <jam> manishtech: I can give you the detailed or the overview
[13:40] <jonnydee> so when you "bzr unbind" you still have access to the complete history contents
[13:40] <jam> jonnydee: I would also mention that if he is branching over http: he can't commit to a checkout
[13:40] <manishtech> thanks jonnydee ... Its on 3/5
[13:40] <chadmiller> manishtech: in "checkout", you don't get a full copy of the history.  You rely on your machine to be able to reach launchpad to make major changes.
[13:40] <jam> well, under *normal* circumstances
[13:40] <manishtech> chadmiller: means I should always use branch?
[13:40] <jam> chadmiller: not true, only if you checkout --lightweight
[13:41] <jam> It will connect to launchpad at commit time, yes, but all stuff like "bzr log/diff/status/etc" are only local
[13:41] <chadmiller> manishtech: Theoretically, "checkout" could be faster than "branch", so that could be a reason to use it.  I think there's little difference at present.
[13:42] <chadmiller> jam: Ah, thanks.
[13:42] <manishtech> chadmiller: I was trying this, but got stuck up with the URL's http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
[13:42] <jonnydee> manishtech: by using a branch all commits go locally. when you want to synchronize with remote repository you do a "bzr push"
[13:43] <manishtech> jonnydee: means "bzr push" is equal to "svn commit" ?
[13:43] <jonnydee> commits to a checkout go directly to remote repository, too. (unless you use --commit-local)
[13:44] <manishtech> jonnydee: one ques, if i checkout a branch and then made a commit on it and got one branch by using "bzr branch" and then made a commit, what's the difference?
[13:44] <jonnydee> when you work on a branch you can do commits. they will go into your local repository. only when you do "bzr push" will all your local commits be transfered to the remote repository
[13:44] <jam> jonnydee: don't confuse him with too much detail just yet :)
[13:45] <jonnydee> when you do commit on a checkout it will go immediately into the remote repository
[13:46] <jonnydee> jam: you are right -- it's confusing. but it's also the first thing I tried to understand before I started using bzr
[13:46] <manishtech> jam: ahem, thanks for the care... but i dont think everyone can make a commit to remote repository? we need to be authenticated... is it just by ssh key?
[13:46] <jam> manishtech: so, first lets find out what *you* want to do
[13:46] <jam> Are you working on the project?
[13:46] <jam> Are you just an interested fan
[13:47] <jam> or one of the main devs?
[13:47] <manishtech> jam: i am an interested person.. who wants to work on tangocms project..
[13:47] <manishtech> am not a main dev.... hope i can be one day
[13:47] <jam> manishtech: ok, as you are unlikely to be given priviledge to commit directly to their branch
[13:47] <jam> you want to use "bzr branch" to create a local copy that you can modify
[13:48] <jam> If you are used to svn, think of it as something like doing
[13:48] <jam> svn branch their/trunk their/branches/myworkspace; svn co their/branches/myworkspace
[13:48] <jam> except the final repository is on *your* machine, separate from theirs
[13:48] <jam> manishtech: with me so far?
[13:49] <manishtech> jam: didnt get what you meant "with me so far"
[13:49] <jam> manishtech: Do you understand what I have said to this point
[13:49] <jam> well written, since I didn't speak :)
[13:49] <manishtech> jam: looks like I missed out something
[13:50] <jam> manishtech: ok, I'll try a different tack
[13:50] <manishtech> jam: i have used code.google.com , there are seperate authorized people on each proj who can commit, so how to find out who can commit to remote branch?
[13:50] <jam> With SVN, you normally do "svn co URL", right?
[13:50] <jam> At which point you have files you can modify locally
[13:50] <manishtech> jam: yeah
[13:50] <jam> and when you commit, it sends your changes back to URL
[13:50] <manishtech> yes... that way, and if am authorized to commit on the repo
[13:51] <jam> manishtech: Bazaar allows you to work it 2 forms
[13:51] <jam> With 'bzr checkout', when you commit, it sends your changes to the remote URL
[13:51] <jam> and yes, you wouldn't be able to without authorization
[13:51] <jam> (it *also* usually creates a copy locally, so you have access to it when you are not online)
[13:52] <jam> manishtech: Bazaar *also* lets you work a different way
[13:52] <manishtech> yes, that's the svn way
[13:52] <jam> which is with "bzr branch URL" it copies the repository from remote to local
[13:52] <jam> so when you commit, it only stores the changes locally
[13:52] <jam> And as you aren't accessing the other people's server, there is no way they can give authorization or not
[13:53] <jam> It is, indeed, by design
[13:53] <jam> However, when it comes time to share your changes, either they need read access to your changes, or you need write access to push your changes to somewhere they can see.
[13:53] <jam> Launchpad can facilitate this
[13:53] <jam> because it lets anyone host their own branch in their own location
[13:53] <jam> (and access control is done via ssh-keys and group permissions)
[13:54] <manishtech> means i can create a branch on launchpad itself...
[13:55] <manishtech> thanks everybody... now i need to work on it... Got the basics, hope now I can learn additionally in due course...
[13:56] <jam> manishtech: I would recommend the tutorials if you haven't tried them yet
[13:56] <jonnydee> mansihtech: yes, you can host your own branch on launchpad
[13:57] <manishtech> jam: i was trying the tutorials when I got stuck... I always feel that the first step is bit tough if it has to be tough, furthur one can manage
[13:57] <jonnydee> so the developers of Tangocms can have a look at your branch and merge your changes into their official branch
[13:59] <manishtech> jonnydee: its just a start, i will to read the whole code and see what is to be done... thanks a lot
[13:59] <jonnydee> you are welcome :) -- have fun!!!
[13:59] <manishtech> jonnydee: thanks
[13:59] <manishtech> jam: thanks
[13:59] <jam> manishtech: well, I'm glad you came here to ask, and if you *talk* to the tangocms guys, you might recommend associating a branch with their development focus
[14:00] <jam> Then they get "bzr branch lp:tangocms" for everyone to enjoy :)
[14:01] <manishtech> jam: i have seen people having problems but still dont use irc to solve it.. they feel it a bit geeky.. dunno why.. people here ae some helpful :)
[14:01] <manishtech> *so helpful
[14:01] <manishtech> sorry for the typo :P
[14:02] <jonnydee> manishtech: this is what I experienced, too.
[14:03] <jonnydee> This is really a nice community here
[14:03] <manishtech> jonnydee: this is my fist entry in #bzr , will be quite active in future... :)
[14:04] <jonnydee> that'*s excatly the reason why I am here. I would like to give some help back!!!
[14:04] <awilkins> I think it intrinsically comes from the mentality that creates a DVCS ; DVCS is inclusive (anyone can branch and commit), not exclusive (central control). That said, the guys in the subversion channel are also great :-)
[14:05] <awilkins> I remember Ben Collins-Sussman himself uploading a patched build of svn to my SFTP server to examine a partocular issue.
[14:06] <jonnydee> awilkins: so Ben should use Bazaar to develop svn ;P
[14:06] <awilkins> Can't really see it happening, that would be like Bazaar migrating to git :-)
[14:07] <jonnydee> yes, I agree
[14:07] <jonnydee>  :)
[14:26] <Necoro> "Please install git to use the live bzr branch" ^^ ... ok - perhaps if used as a naive excuse to avoid bootstrapping issues ^^
[14:42] <awilkins> Maybe someone will make a "Bazaar" porcelain for git - that would depend on it :-)   (Gitaar?)
[14:44] <jonnydee> Gitaar..."sounds" funny :)
[14:48] <Necoro> btw: if I want to have something to control a document repository - what should I use?
[14:48] <rocky> jelmer: you using bzr+trac ok?
[14:48] <LeoNerd> awilkins: Bonus points if you can get some mentions of "strings" in there
[14:48] <Necoro> with "document repository" I mean a repository of documents (scientific papers or letters), where the documents themselves never or rarely change
[14:49] <Necoro> but might be large ;)
[14:49] <Necoro> is bzr designed to be used there? - or is it just overkill (esp. because I double sizes)
[14:51] <jam> awilkins: well, there is bzr-git, which should eventually be able to treat a git repo as "just another bzr branch" like we have for bzr-svn
[14:52] <jam> I think ATM, it can do "bzr log" on a git repo
[14:53] <awilkins> jam: Does that use the git plumbing? It sounds like it really should just be a "porcelain"
[14:54] <jam> awilkins: Last I checked, it just did "git foo" and then interpreted the results
[14:54] <jam> so "git cat --tree", etc
[14:54] <jam> It is a bzr plugin, though, not a mod to git
[14:55] <awilkins> Yeah, but git is just a bunch of shell scripts ; so a bunch of Python scripts is not such a stretch
[14:55] <awilkins> (plus the nasty C bits of course)
[14:55] <jam> awilkins: IIRC, there were actually some python and perl and XX bits in git
[14:56] <awilkins> What is XX
[14:56] <jam> And the C bits are pretty much focused on being an app and not a lib
[14:56] <jam> awilkins: "etc"
[14:56] <awilkins> Ah
[14:56] <jam> Just saying that it is *mostly* shell porcelain, and then a lot of other stuff
[14:56] <jam> not sure how much
[14:58] <jam> so yeah, you could build something on top of git that looks like bzr, but it makes more sense IMO, to build something under bzr that interfaces with git repos
[15:03] <pickscrape> How would bzr handle me making a lightweight checkout of a checkout?
[15:03] <pickscrape> Specifically, what would happen on commit?
[15:07] <awilkins> pickscrape: It commits to the co but doesn't update the tree, and the revision is not propagated to the bound branch
[15:07] <pickscrape> Would be really smart if it went all the way up the chain :)
[15:07] <pickscrape> The tree I'm not surprised about though
[15:07] <jonnydee> but what would happen in turn of merge conflicts...?
[15:07] <awilkins> Might be difficult though ; you might not have access to the bound branch of the co
[15:08] <jonnydee> (I mean somewhere up the chain)
[15:08] <pickscrape> Indeed
[15:08] <pickscrape> I'm really trying to work around a limitation in my text editor really, which follows my 'active' branch symlink and opens the actual file
[15:09] <pickscrape> Which makes moving the symlink not do what I want it to do.
[15:17] <jonnydee> lifeless: what do you think? will solving bug https://bugs.launchpad.net/bzr/+bug/255656 be of high importance? I mean is it likely that it will be focused on in one of the next releases? I'm askinf because if not I have to figure out another feasible solution than hosting the repo on a network share...
[15:17] <jam> pickscrape: try it, I believe it *does* propagate the changes
[15:18] <jam> you only get 1 level of bound to work, but it should at least manage that
[15:18] <pickscrape> jam: ooh, I will then :)
[15:18] <Snaggen_> I'm thinking of setting up a BundleBuggy with a PQM in the same way as bzr.dev has it. As I understand you send the patch to BundleBuggy and when it is approved it is submitted to PQM that performs all the tests and then perform the merge. But how do you get BB to send to PQM?
[15:18] <jam> Snaggen_: not quite right
[15:18] <jam> We have BB monitor the mailing list
[15:19] <jam> we don't send things to it directly
[15:19] <Snaggen_> jam, yes, my bad
[15:19] <jam> And we send directly to the PQM, it isn't sent from BB
[15:19] <jam> (bzr-pqm is the plugin we use)
[15:19] <jam> to add 'bzr pqm-submit -m "pqm commit message"'
[15:19] <Snaggen_> jam, so BB monitors the list. then when a patch is approved what does it do?
[15:20] <jam> BB doesn't do much but *track* patches
[15:20] <jam> humans submit them to PQM
[15:20] <jam> and BB also tracks the branch
[15:20] <jam> so it can see when a patch lands
[15:20] <jam> at least, for Merge Directives, plain patches need manual intervention.
[15:21] <Snaggen_> So when a patch is approved you manually submit it to PQM?
[15:21] <jam> Snaggen_: yes
[15:21] <jam> We've wanted to have a "Submit to PQM" button on BB
[15:21] <jam> just hasn't happened
[15:21] <jam> it might be more likely after some of the PQM updates land from Odd_Bloke
[15:21] <jam> to make it friendlier, etc.
[15:21] <Snaggen_> jam, would it be interesting att all to have a "auto send approved patches to PQM" feature?
[15:22] <Snaggen_> jam, or is a button prefered?
[15:22] <jam> I'm a bit leary of auto-send
[15:22] <jam> leery
[15:22] <jam> Just because sometimes something gets approved, but should really wait a day or two
[15:22] <jam> in case there are objections
[15:22] <Snaggen_> jam, ok...
[15:22] <jam> lots of people have votes, I trust some in certain areas more than others
[15:23] <jam> so... I think having that feature would be neat
[15:23] <jam> I don't know that we would turn it on for bzr
[15:24] <Snaggen_> jam, I see... I'm looking in to use BB and PQM for code review and regression testing... if we get to a point where it is interesting enough (which I hope to get to quite soon) we might spend an hour or two to do some adaptions... but we'll see
[15:27] <jam>  Snaggen_: sure
[15:27] <jam> I would just mention Odd_Bloke has a lot of nice updates for PQM pending review
[15:28] <jam> So you may end up with something nice in a week or two.
[15:28] <Snaggen_> jam, does he have a branch with his work in lp?
[15:29] <jam> Snaggen_: AIUI he has several branches, just a sec
[15:29] <jam> Snaggen_: http://bundlebuggy.aaronbentley.com/project/pqm/request
[15:30] <Snaggen_> jam, and that is PQM... auto-submit would be done in BB I guess... using the bzr-pqm plugin?
[15:30] <jam> Snaggen_: well, I would expect that once PQM could support an XML-RPC request, then BB would use that to submit merges.
[15:30] <jam> Further, I think PQM needs to support merge directives directly
[15:30] <Snaggen_> jam, or would you prefer XML-RPC request.
[15:31] <jam> Right now, you have to have a public branch for it to merge
[15:31] <jam> Both of which Odd_Bloke worked on (Daniel Watkins)
[15:31] <Snaggen_> jam, Ok... if I go down that road I'll lock at the XML-RPC stuff
[15:31] <jam> The current issue is that lifeless is the maintainer of PQM, and he's a bit overworked right now to review the changes
[15:31] <jam> It *will* happen, just not sure when
[15:32] <Snaggen_> jam, I'll go straight to the source then and look att Odd_Blokes RPC branch then
[16:20] <pickscrape> Is there any difference between bzr checkout and bzr checkout --lightweight if the two branches are both in the same shared repository?
[16:21] <dato> I don't think so
[16:21] <dato> (though I believe you'd save a ridicously small amount of bytes :P)
[16:22] <pickscrape> I'm wondering if one or the other might trigger a slightly more optimal code path for example over the other one.
[16:24] <pickscrape> Is there a way to bzr branch and have it not create a working tree explicitly?
[16:29] <jonnydee> pickscrape: if you branched into a shared repo which had been configured not to contain a working tree... but this is not what you intend -- I guess....
[16:34] <pickscrape> No, this use case is that I have a shared repo that I want to contains a mixture of branches with and without trees.
[16:34] <jonnydee> but you can configure a tree-less branch into a tree-containging one
[16:35] <jonnydee> I think it's to be done with "bzr reconfigure"
[16:35] <pickscrape> Yes, but a --no-tree option would be a lot simpler :) Especially if you want the repo to default to creating a tree.
[16:36] <jonnydee> yes, of cource, I agree
[17:28] <jelmer> jam, bzr-git can fetch data from git repos as well
[17:29] <jam> jelmer: does it get things like "last modified" for directories correct? That was always a hard part for me and formats that don't track directories explicitly
[17:30] <jam> like, renaming the last file out of a directory deletes it
[17:30] <jam> etc
[17:31] <jelmer> jam, I'm not sure
[17:31] <jelmer> jam, I implemented the .texts and revisiontree interfaces
[17:31] <jelmer> and fetch suddenly worked out of the box
[17:31] <jelmer> it was kinda scary, really
[17:33] <jam> sure, but getting the Inventory object correct is the really tricky part
[18:24] <Odd-rationale> Hello. I'm using 5-a-day. I have run "5-a-day --add-team <team>". It create the appropriate ~/.5-a-day-<LPID>/team file. But for some reason, i cannot get it uploaded to my bzr branch. The data file pushes fine, however. So is there a way I can force it? Thanks!
[18:25] <Odd-rationale> BTW, this is for the GBJ :P
[19:31] <jonnydee> hello, I would like to play around a bit and try to write a plugin for bzr. Can anyone suggest me a powerful python IDE (except emacs)?
[19:32] <jonnydee> I mean debugging support etc
[19:35] <jam> jonnydee: I personally like Vim a lot :)
[19:35] <jam> But as for real IDEs
[19:35] <jam> I would go with http://www.wingware.com/
[19:35] <jam> It's vim text-editing mode wasn't very good last I used it, but I've heard its gotten better.
[19:35] <jonnydee> vim...I merely thought of something like a real ide....
[19:35] <pickscrape> There's a free one called Eric
[19:36] <jam> I understand the idea of a nice ide, but since 90% of my time is editing text
[19:36] <jam> I find a nice *text* editor is the most important
[19:36] <jam> A good test suite + pdb is usually enough for the debugging side
[19:36] <jam> Again, an IDE would probably help there
[19:36] <pickscrape> jam: I agree. Editors seem to really lack in what I consider to be basic editing features.
[19:36] <jam> but it would have to play nicely with our test environ
[19:37] <pickscrape> Gah, I mean IDEs lack :)
[19:37] <jam> pickscrape: There was supposed to be an IDE, that was able to combine your preferred components
[19:37] <jam> so it would embed vim for editting
[19:37] <jonnydee> has anyone tried PyDev for Eclipse?
[19:37] <jam> and various other tools
[19:37] <jam> jonnydee: I've tried some Eclipse, but again "Vim" mode sucked
[19:37] <jam> and might have been better if I paid for it
[19:38] <jam> but their teaser didn't even work
[19:38] <jam> which didn't inspire me to buy the product :)
[19:38] <jam> The other problem with Eclipse is that it wanted to configure 1 project per location
[19:38] <jonnydee> ok I see... well I don't want to spend money, either
[19:38] <jam> which means it doesn't like feature branches very well
[19:38] <jam> Eclipse had nice syntax highlighting
[19:38] <jam> and *could* have been good
[19:39] <jonnydee> jam: that's a good point
[19:39] <jam> But it did seem to have a strong java bent
[19:39] <jam> jonnydee: I've since switched to having a small number of working trees that I 'bzr switch' between branches
[19:39] <jam> so Eclipse might like that more
[19:39] <jam> but it really wants you to create Eclipse projects
[19:39] <pickscrape> I struggled to get decent visible whitespace for Eclipse.
[19:40] <jam> Oh, and Eclipse wanted to use absolute paths
[19:40] <jam> so you couldn't create a project, and just copy it around :(
[19:40] <jam> My Eclipse-fu might be weak, though, as I don't see how people would stand for abspaths all the time
[19:40] <jonnydee> jam: yes, I know this problem from Java. Absolute paths suck....
[19:40] <jam> it doesn't even work between *developers*
[19:41] <jam> I might try it again sometime, but in the short term... it didn't work so well
[19:41] <pickscrape> My current preference is jedit, though I am always on the lookout for something better.
[19:41] <jonnydee> ok, I'm a bit surprised now, because I thought there exists a good IDE. But it seems like one is better of with simple tools
[19:42] <pickscrape> jonnydee: you might want to have a look at Eric. It's not bad
[19:42] <jonnydee> ok, I'll have a look at Eric. I think for my first experiments it should be good enough
[19:42] <jonnydee> does it support debugging?
[19:43] <jam> pickscrape: this one? http://die-offenbachs.de/eric/
[19:43] <jam> I used to use Scintilla as my text editor for a while
[19:43] <jam> It was pretty nice
[19:43] <pickscrape> Yes, that's the one. I've not really used it in anger though
[19:43] <jam> just not *as* good as Vim
[19:43] <jam> Nothing compares to "." :)
[19:44] <pickscrape> I use vim for quick editing from the command line.
[19:44] <jam> jonnydee: http://die-offenbachs.de/eric/images/eric4-screen-03.png
[19:44] <jam> Integrated unittest running
[19:44] <jam> jonnydee: debugger in action: http://die-offenbachs.de/eric/images/eric4-screen-02.png
[19:44] <jonnydee> ok, so thank you very much for your comments and your help. :)
[19:45] <jonnydee> ok, cool. Eric seems to be the tool I've been looking for... the screenshots look nice :)
[19:45] <jonnydee> very very nice ... :D
[19:47] <jonnydee> btw Eric seems to be also in the ubuntu package repository.... I'm installing it right now...
[19:48] <jam> it does look shiny, just need to know if it *works* right :)
[19:49] <pickscrape> From my experimentation, the editor wasn't up to jedit's level, but it wasn't terrible.
[19:50] <jonnydee> well, I can give you some report when I tried it...
[19:50] <pickscrape> I've heard a lot of good things about 'scribes'
[19:56] <jonnydee> There is a Flash demo of scribes: http://scribes.sourceforge.net/demo.htm (but it seems to me like this tool is something for people experienced in programming using python...so I think Eric is a better choice--for me, at least)
[20:01] <pickscrape> Yes, scribes is an editor rather than an IDE. This conversation just reminded me to try it. :)
[20:02] <jonnydee> well, I think it could be a good choice for you, because you know the language and the APIs already (I guess ;) )
[20:02] <jam> well, I can get it to run a couple individual tests
[20:02] <jam> but I can't get it to actually run the whole bzr test suite
[20:02] <jonnydee> So you can just write down your code and et good support by scribes
[20:53] <cgrindsXO> Is it possible to pull part of a branch? For example my root is c:/stuff. It contains lots of, well, stuff. I'd like to go to an unrelated dir and do a pull like so: "bzr pull c:\stuff\fan\fansh" but that doesn't work
[20:55] <Necoro> cgrindsXO: perhaps you should have used a shared repository instead of one large branch ;)
[20:56] <cgrindsXO> right - I think I started using bzr before shared repos existed. The original reason I went with one large branch is it made it easier to backup one thing instead of all my projects individually
[20:56] <Necoro> cgrindsXO: bzr help split
[20:57] <cgrindsXO> Necoro: thxs I'll go read
[21:01] <cgrindsXO> C:\stuff>bzr split fan
[21:01] <cgrindsXO> bzr: ERROR: No WorkingTree exists for "file:///C:/stuff/fan/.bzr/checkout/".
[21:06] <Necoro> cgrindsXO: perhaps you need to update the repository formate to something known subtrees first
[21:06] <Necoro> but this is only a guess
[21:06] <Necoro> testing it on a branch of mine, it worked
[21:07] <cgrindsXO> yeah I tried upgrade and it said
[21:07] <cgrindsXO> C:\stuff>bzr upgrade .
[21:07] <cgrindsXO> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[21:08] <Necoro> cgrindsXO: try: bzr upgrade --rich-root-pack
[21:10] <cgrindsXO> Necoro: sigh apparently not my day. bzr: ERROR: Revision {('chris@g.org-20080731173055-6pzgw3yoz1rha0um',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x02010C30>".
[21:10] <Necoro> oh
[21:10] <Necoro> hmm ... some bzr-dev here to help?
[21:11] <jelmer> cgrindsXO, while upgrading to rich-root-pack?
[21:12] <cgrindsXO> yes
[21:20] <jelmer> cgrindsXO, please file a bug
[21:20] <cgrindsXO> jelmer: ok will do
[21:29] <cgrindsXO> jelmer: https://bugs.launchpad.net/bzr/+bug/256199
[21:29] <jelmer> cgrindsXO, thanks
[21:30] <jelmer> hopefully one of the australians can have a look on monday
[22:24] <lifeless> jam: will you be wowing?
[22:24] <pickscrape> World of Warcraft?
[22:24] <lifeless> pickscrape: yah
[22:25] <pickscrape> Ah. You've said that a couple of times and wondered what it meant :)
[22:25] <Kinnison> lifeless: which realm?
[22:27] <lifeless> caelsytraz
[22:28] <lamalex> Is there a way to see when the last time a file was edited was?
[22:29] <lamalex> rather, the revision number of the last edit
[22:29] <pickscrape> bzr log -l 1 <filename> ?
[22:30] <lifeless> lamalex: annotate probably is best today
[22:30] <lamalex> i actually just found log
[22:30] <lamalex> pretty much exactly what i needed
[22:30] <lifeless> lamalex: worth filing a bug I think, noone has asked for that, but I think ls would be a good place to have that be visible
[22:30] <lamalex> sorry for not rtfm'ing first
[22:31] <lamalex> no, log was basically it
[22:33] <lamalex> thanks
[22:38] <Kinnison> lifeless: presumably not a european realm :-)
[22:38] <lifeless> Kinnison: nope sorry :)
[22:38]  * Kinnison grins
[22:39]  * Kinnison has to admit that he never would have pegged you as a WoWer :-)
[22:40] <lifeless> Kinnison: well its not on my laptop
[22:40] <lifeless> so you'll only catch me wowing from home
[22:40] <lifeless> right now I'm farming mats for my priests epic flying machine
[22:42] <Kinnison> Heh, I need to be bothered to farm for mats so I can waste 'em skilling up to make an epic flying machine
[22:42] <pickscrape> Sounds like quite a responsibility.
[22:42] <Kinnison> heh
[22:43]  * Kinnison loves the bizarre language which goes with WoWing
[22:44] <LaniSwe> Hi! I'm trying to setup Bazaar with a central repository on my server. I'm using the "Centralized workflow" tutorial: http://bazaar-vcs.org/Tutorials/CentralizedWorkflow. Unfortunately I'm stuck on 2.3: "Setting up a remote Repository". The tutorial there tells me to run the command: "bzr init-repo --no-trees sftp://centralhost/srv/bzr/", but it does not explain how I should configure the server?
[22:44] <lifeless> Kinnison: #ubuntu-wow is more topical :)
[22:44] <LaniSwe> If I just execute that command I get an error that tells me that the directory does not exist. If I create that directory with "sudo" and then run the command again I get an access denied message.
[22:45] <LaniSwe> So I don't know if I'm on the right track here. As I don't what to create a user account for every user that needs to access the repository.
[22:46] <LaniSwe> I just want to grant public ssh keys, is that possible?
[22:49] <LaniSwe> Anyone here that have used Bazaar over ssh?
[22:49] <pickscrape> We use bzr+ssh
[22:50] <LaniSwe> pickscrape: Yes I've seen that command, but how do you setup the ssh public keys in a central repository on the server?
[22:51] <pickscrape> ssh public keys is purely an ssh thing: if the user can ssh to the server via their key, they can do the same with bzr too
[22:52] <LaniSwe> But I don't want to create a separate user account for every Bazaar user. In git you can create a specific 'git' user on the server and then just add in a file what public keys that should have access to the repository, is there no such thing in Bazaar?
[22:52] <pickscrape> We just use one 'bzr' user
[22:53] <pickscrape> We had to add something to ~/.ssh/config for every user though to get ssh to use the 'bzr' user when connecting to that server
[22:54] <LaniSwe> Ah, ok. But then it will always use the bzr user as default for that server? That's not ideal either, as the server is also used for other things.
[22:55] <lifeless> LaniSwe: so we took the approach that folk wouldn't want us implementing security sensitive code like user management unless absolutely needed
[22:55] <lifeless> LaniSwe: there are several options to avoid system users:
[22:55] <pickscrape> Yeah. I think you are supposed to be able to do it using ~/.bazaar/authentication.conf, but I couldn't get it to work.
[22:55] <lifeless>  - http with either webdav or bzr+http; in this scenario apache does the authentication
[22:56] <lifeless>  - a custom sftp server port which doesn't use system users (e.g. twisted has one of these); I believe some-assembly-required for this option
[22:56] <lifeless>  - doing something like pickscrape describes
[22:56] <lifeless> I'd say that http is the simplest and most robust
[22:57] <pickscrape> lifeless: does the bzr+http method allow per-branch authentication?
[22:58] <LaniSwe> Ah ok, in this case http is acceptable but in future scenarios it might not be. Then encryption might be needed. The .bazaar/authentication.conf sounds ideal, to bad you couldn't get it to work pickscrape.
[22:59] <lifeless> LaniSwe: we support ssl
[22:59] <LaniSwe> Ah ok :)
[22:59] <LaniSwe> Just another thing for me to learn how to setup then ;)
[23:00] <lifeless> its pretty easy, lots of apache howtos
[23:00] <LaniSwe> I've just started to like ssh and how simple it is to use and setup :)
[23:00] <LaniSwe> ok
[23:00] <lifeless> I love ssh
[23:01] <LaniSwe> Well I would go that far ;) but it's really nice :)
[23:02] <pickscrape> lifeless: what are the connection setup overhead differences between http and ssh like?
[23:02] <LaniSwe> lifeless: Are you aware of an option for specifying the bazaar user in the ~/.bazaar/authentication.conf file that pickscrape talked about?
[23:02] <lifeless> pickscrape: should be minimal
[23:03] <lifeless> LaniSwe: authentication.conf is just a credentials cache AFAIK
[23:03] <LaniSwe> ok
[23:03] <pickscrape> I couldn't get it to force the ssh user
[23:05] <lifeless> pickscrape: you can set ssh users by ~/.ssh/config
[23:05] <LaniSwe> pickscrape: But when I think about it, how would that work? Wouldn't that make all checkins etc come from the bazaar user?
[23:05] <pickscrape> Yes, that's what we did. However, that means always connecting to the server in question via that user
[23:05] <lifeless> LaniSwe: no it wouldn't
[23:06] <lifeless> LaniSwe: checkings are really just a form of push; the data is generated on the client
[23:06] <LaniSwe> lifeless: ok, so the "bzr whoami" will be used then?
[23:06] <lifeless> yes
[23:06] <LaniSwe> ok :)
[23:07] <LaniSwe> But if pickscrape couldn't get it to work I don't think that I will either :/
[23:08] <pickscrape> We got the ~/.ssh/config method to work fine.
[23:09] <pickscrape> It's just not *quite* as convenient as being able to define it in a bzr-specific place.
[23:10] <LaniSwe> I guess that I could make a separate dns entry like bzr.myserver.com, and then if just myserver.com points to the same ip shouldn't matter? I should then be able to specify a default user for just bzr.myserver.com in the .ssh/config?
[23:17] <pickscrape> LaniSwe: Yes, that appears to work as you're expecting. The matching is done on the hostname, not the IP address.
[23:19] <LaniSwe> pickscrape: Ok thank you very much for your help and pointing me in the right direction!
[23:19] <pickscrape> pleasure :)
[23:19] <LaniSwe> You to lifeless!
[23:20] <LaniSwe> pickscrape: You don't happen to have a good reference for the config file? ;) Or is it in the man page maybe? ;)
[23:20] <lifeless> LaniSwe: my pleasure
[23:20] <lifeless> man ssh_config
[23:20] <LaniSwe> ok!
[23:21] <pickscrape> At the end add: Host <hostname> (newline) User <username>
[23:22] <LaniSwe> Ok!
[23:24] <LaniSwe> I'm going to try this out tomorrow. Time for bed now as it is 12:23 am over here now. Thank you for being so helpful and have a nice day/night ;)
[23:24] <lifeless> sleep well
[23:25] <mvo> what does the error: http://paste.ubuntu.com/35690/ mean?
[23:27] <lifeless> I so want to say "bzr never prints error: http://paste.ubuntu.com..."
[23:27] <mvo> heh :)
[23:28] <lifeless> also its a bug indicating a deeper problem
[23:28] <lifeless> that is, its a symptom
[23:28] <mvo> I guess in this case using a pastebin was not really needed
[23:28] <lifeless> latest bzr's should show the real error
[23:28] <mvo> that is bzr 1.5
[23:28] <dato> oh
[23:28] <dato> he left
[23:28] <lifeless> dato: you know him ?
[23:29] <dato> no
[23:29] <dato> but I would've told him he doesn't need a DNS entry
[23:29] <dato> Hostname blablabla
[23:29] <dato>   Username foo
[23:29] <dato>   Host <IP_ADDRESS>
[23:29] <lifeless> oh right :P
[23:29] <mvo> lifeless: do I need a more recent bzr? is there a workaround (like using sftp instead of bzr+ssh etc?
[23:29] <lifeless> or even host foo.ar
[23:29] <dato> yep
[23:29] <lifeless> mvo: well what were you doing
[23:30] <dato> s/told him/told them/
[23:30] <mvo> lifeless: I did a bzr commit on a branch that is bound to bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/apt/ubuntu/
[23:31] <lifeless> mvo: so, not sure tbh
[23:31] <lifeless> check ~/.bzr.log
[23:31] <lifeless> may be more details there
[23:35] <mvo> lifeless: some info in http://paste.ubuntu.com/35692/
[23:35] <lifeless> statik: ping
[23:36] <lifeless> mvo: probably the autopack race we have a bug open on
[23:37] <mvo> aha, bzr pack seems to have helped indeed
[23:37] <mvo> thanks
[23:37] <lifeless> np
[23:38] <jelmer> lifeless, still there?
[23:39] <lifeless> yahuh
[23:39] <jelmer> lifeless, when is the a directory supposed to be touched in bzr?
[23:39] <jelmer> I mean, when is it's 'revision' property updated?
[23:39] <lifeless> same as for a file
[23:39] <lifeless> metadata-change or heads-of-revision-property-greater-than-one
[23:40] <jelmer> what is considered metadata though?
[23:40] <jelmer> are children metadata?
[23:40] <lifeless> no
[23:40] <lifeless> see repository.py - commit builder
[23:41] <lifeless> I can phrase it differently - anything that changes the xml line in todays formats
[23:41] <jelmer> lifeless, thanks
[23:41] <lifeless> will count as a 'change'
[23:41] <lifeless> + do a change anyway if the heads() count is > 1 [this records a merge at the file level]
[23:43] <jelmer> lifeless: not sure I follow
[23:43] <jelmer> lifeless, If the heads count is > 1 doesn't it use the revid of one of the parent revids if the text was unchanged?
[23:44] <lifeless> never
[23:44] <lifeless> this is not the revision graph
[23:44] <lifeless> this is the per-file graph
[23:44] <lifeless> for the heads count to be greater than 1, we must be a) committing a merge, and b) both branches must have made changes to this file
[23:45] <lifeless> concurrent changes that is
[23:45] <jelmer> lifeless, ahh, of course
[23:46] <lifeless> if one side changes you get no-change against that side,and a heads count of one, so you keep the old revision
[23:46] <lifeless> if both sides change to the same text
[23:46] <lifeless> you get no-change against both sides, but 2 heads, so you record a merge
[23:47] <lifeless> the intent
[23:48] <lifeless> is that if you follow the per file graph you will find every actual change made to the file, and you won't see a change just because someone merged a branch that had changed it
[23:49] <lifeless> thus the graph has to bifurcate where changes were made concurrently even if no change was made at the bifurcation point
[23:49] <lifeless> please do check the code
[23:49] <lifeless> but does that made sense?
[23:55] <lifeless> jelmer: ^
[23:56] <jelmer> lifeless, yep, it does
[23:56] <jelmer> lifeless, thanks
[23:56] <lifeless> cool


[14:54] <pikapika> Does ubuntu plan to go wayland in future? Will x11 still be available to install if it does?
[15:12] <pikapika> Hi remline
[15:31] <blue_penquin> pikapika:  Yes x11 will be available only the default session is changing to wayland and for people with NVIDIA hardware that will still remain as the default session.
[15:32] <pikapika> blue_penquin, thats alarming
[15:32] <pikapika> Which release?
[15:33] <blue_penquin> What's alarming? It's going to change in upcoming 21.04.
[15:36] <pikapika> blue_penquin, imposition of half baked replacements for years old software
[15:38] <blue_penquin> It's not half-baked.
[15:39] <blue_penquin> And you can continue to use X11 if you wish I don't see what's the issue.
[15:39] <pikapika> The writings on the wall. I fear X will be slowly abandoned.
[15:46] <Maik> pikapika: probably in the future. After 12 years of development Wayland is still not ready yet, also not all desktop environments have been made comaptible with it
[15:47] <Maik> Ubuntu is the only one that will ship Wayland by default, the other official flavours will still use Xorg
[15:49] <blue_penquin> pikapika: It'll, hopfully sooner the better. Right now wayland is missing a lot of customisation and quirks that people used to to with various x* cli tools some of them have working alternatives; some of them won't have.
[15:49] <blue_penquin> This is Due to A)not being developed, for example xmodmap B)delegated to the compositor which doesn't have a setting for example controlling scroll speed - gcc will provide that in the future. C) Wayland protocol doesn't allow for security reasons
[15:51] <pikapika> Maik, is Debian's policy regarding wayland known?
[15:51] <blue_penquin> And for your applications browser support wayland; FF is better in this regard; all GNOME apps support it; Qt supports it, electron 12 or greater does but it is right now a bit buggy and you can always use xwayland.
[15:53] <blue_penquin> pikapika: Debian defaulted to it earlier https://wiki.debian.org/Wayland#Supported_environments
[15:54] <pikapika> Thats alarming
[15:56] <blue_penquin> Wayland experience on GNOME is better than KDE in my opinion although KDE is making good progress every week. And the other three major ones won't have wayland support anytime soon.
[15:58] <Maik> Fedora uses Wayland by default for a long time, the more distro's use it the more reports users file the better development gets.
[15:58] <pikapika> Gnome has already gone down a dark path
[15:58] <pikapika> I worry more about XFCE falling
[15:59] <pikapika> Maik, the question is less one that of sufficient users reporting bugs, more that of their attitude regarding user reports
[15:59] <pikapika> Do they brazenly shut down the users or do they actually listen to them?
[16:00] <Maik> since it has nothing to do with a support question regarding Ubuntu 21.04, i guess this discussion would fit better in #ubuntu-discuss
[16:09] <pikapika> Ok, sorry
[16:13] <Maik> np