[00:12] <luislavena> hello everybody.
[00:13] <luislavena> anyone had experience installing bzr on a shared host?
[00:13] <poolie> yes, sure
[00:14] <luislavena> poolie: dreamhost, bluehost or site5?
[00:14] <poolie> oh, huh
[00:14] <poolie> none of those
[00:14] <poolie> why not use launchpad.net?
[00:15] <luislavena> poolie: is for a private project
[00:15] <luislavena> poolie: been pushing via ftp and pulling via http, but these dumb protocols are a bit slow.
[00:15] <poolie> are you using a pack repository?
[00:16] <luislavena> yep, pack-0.92
[00:16] <luislavena> with 1.1
[00:16] <luislavena> sorry, bzr 1.1
[00:16] <luislavena> freshly created repos :)
[00:16] <beuno> luislavena, I'm not sure you can install python apps on shared hosts
[00:17] <beuno> (I'm fairly sure you can't unless it's a virtual server or the likes)
[00:19] <luislavena> beuno: thank you
[00:20] <luislavena> beuno: maybe something like this
[00:20] <luislavena> beuno: http://joshstaiger.org/archives/2007/01/bzr_on_dreamhos.html
[00:21] <beuno> luislavena, ah, seems pretty straight forward
[00:22] <luislavena> beuno: I'll need to check if the dependencies can be installed in the same way, since I've 2.4.3 available and only tested bzr with 2.5.1
[00:22] <beuno> if you're allowed to install stuff in your home, for the most part, those same steps should work
[00:22] <beuno> luislavena, bzr works fine with python 2.4X
[00:23] <luislavena> beuno: thank you for the info
[00:23] <luislavena> beuno: is there a way I can see if everything works as expected ? (selftest?)
[00:24] <beuno> luislavena, yeap, bzr selftest
[00:26] <fullermd> Uff.  Not a particularly kind thing to do...
[00:27] <Odd_Bloke> fullermd: What in particular?
[00:27] <luislavena> fullermd: yes, I know... will make the shared host a nightmare to other users.
[00:29] <fullermd> Odd_Bloke: running 'selftest' on a shared webhost?
[00:29] <poolie> because of cpu usage?
[00:29] <poolie> run it niced...
[00:29] <poolie> or run, say 'selftest command'
[00:29] <poolie> sorry, i mean 'blackbox'
[00:30] <fullermd> cpu, disk...   last time I ran it, it made my workstation crawl for about 40 minutes.
[00:30] <fullermd> Still negotiating the restraining order my hard drive filed at the time...
[00:31] <luislavena> fullermd: hehehe, no problem, the InstallationFaq contains pointers on how to check for the missing dependencies.
[00:31] <luislavena> so far, the shared host lack all of them :P
[00:31] <luislavena> I'll see if I can install them like bzr...
[00:31] <luislavena> (on $HOME)
[00:32] <Odd_Bloke> fullermd: Ah, OK, I was thinking more generally.
[00:40] <bob2> ffworked fine on dh for me
[00:44] <luislavena> bob2: how did you handle the dependencies? ElementTree, pyramiko, etc?
[00:45] <fullermd> Well, you don't need paramiko unless you're sftp'ing _out_ from there.
[00:46] <bob2> aelementree is python, as is paramiko, and what fullermd  said
[00:46] <bob2> you could probably even get bzr+http working, I think they do fastcgi
[00:50] <lifeless> revie requested: http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E
[00:54] <luislavena> bob2: how bzr+http will handle authentication?
[00:54] <bob2> poorly!
[00:56] <lifeless> bob2: uhm
[00:56] <lifeless> luislavena: it should handle it fine
[00:56] <luislavena> lifeless: thank you :)
[00:57] <luislavena> but anyway, it fails to compile the c part of bzrlib
[00:57] <luislavena> so I think this shared host is not as good as other ;-)
[00:57] <bob2> hm, I was reading the bzr+http docs yesterday, and it looked like you couldn't control what people could write to
[00:58] <lifeless> bob2: thats access control not authentication
[00:59] <lifeless> bob2: bzr+http delegates authorisation and authentication to apache and makes no direct effort at access control
[01:00] <bob2> touche
[01:00] <fullermd> Well.  Access control is a subset of authorization...
[01:00] <lifeless> fullermd: bup
[01:00] <lifeless> fullermd: bah, nup, its not
[01:01] <lifeless> fullermd: its a subset of AAA, but other than that you can have any one without the other two
[01:01] <fullermd> The third A in AAA is 'accounting', though.
[01:01] <bob2> but it's not possible to have differing read and write authorization with bzr+http yet, right?
[01:01] <lifeless> bleh, my brain has clearly faded
[01:02] <fullermd> Dirstate does that to ya   ;)
[01:02] <lifeless> bob2: depending on what granularity you want, yes or no
[01:02] <lifeless> bob2: in a single repository, we still depend on VFS access for some methods, so any access to the data base implies full data visibility
[01:03] <fullermd> I would phrase it as "bzr+http delegates authentication to Apache, and abdicates authorization to merely be contingent on authentication".
[01:03] <lifeless> bob2: but you can certainly split read and write access in a couple of ways - you can run the server with different parameters via the apache config to block writers
[01:04] <fullermd> The usual suggestion for that is "read/only bzr+http, read/write bzr+https with HTTP auth"
[01:05] <lifeless> not sure why you'd split the protocol
[01:05] <lifeless> but whatever
[01:09] <fullermd> Well, that makes the URL's almost the same on both sides.  Gives you SSL where you're sending auth info over the wire.
[01:10] <lifeless> digest auth ftw; or has that not landed yet ?
[01:10] <fullermd> Well, it would also prevent a MitM when you were pushing data.  If anybody still bothers trying to carry those out.
[01:11] <lifeless> digest supports body signing
[01:11] <lifeless> plus sign your commits kthxbye
[01:16] <lifeless> igc: I wonder if I can borrow you for http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E
[01:17] <igc> lifeless: sure. Meant to get to it yesterday.
[01:17] <igc> I'll move it to the top of my review list
[01:18] <igc> (ahead of thumper's one)
[01:18] <thumper> :(
[01:21] <luislavena> guys, there is no feed generator that can hook push and commit?
[01:22] <luislavena> branchfeed seems old and don't work.
[01:23] <lifeless> luislavena: my plugin should still work
[01:23] <luislavena> lifeless: can you point me to the branch?
[01:23] <lifeless> one sec
[01:24] <luislavena> lifeless: thank you
[01:25] <lifeless> branchfeed is what I called mine lol, I had to re-read it
[01:26] <luislavena> lifeless: the one here doesn't work:
[01:26] <luislavena> https://code.launchpad.net/~bzr/bzr-branchfeed/trunk
[01:27] <luislavena> it's supposed to generate a feed in .bzr/branch/branch.atom, but no file get generated.
[01:28] <lifeless> https://bugs.edge.launchpad.net/bzr-branchfeed/
[01:28] <lifeless> could you file a bug please
[01:29] <luislavena> lifeless: will help you if I run the plugin selftests?
[01:30] <lifeless> is the plugin installed on your client or server?
[01:30] <luislavena> client, doing everthing locally and sometimes using smart server.
[01:31] <lifeless> yah, I can't look at this right now
[01:31] <lifeless> please file a bug with as much info as you can gather
[01:31] <luislavena> lifeless: yeah, sure. thank you again :)
[01:39] <luislavena> lifeless: done :)
[01:45] <ubotu> New bug: #187479 in bzr-branchfeed "BranchFeed don't generate atom feed after commit or push" [Undecided,New] https://launchpad.net/bugs/187479
[02:07] <luislavena> guys, another silly question, but i cannot find a way to verify the signed commits
[02:08] <luislavena> there is sign-my-commits and re-sign, but no verify-signed-commits or something similar.
[02:11] <lifeless> poolie: perhaps https://code.edge.launchpad.net/~mbp/bzr/dev should be registered, its a dupe with https://code.edge.launchpad.net/~bzr/bzr/trunk
[02:11] <lifeless> luislavena: yah, someone was working on it
[02:13] <luislavena> lifeless: good to know, the check_signature and create_signatures configuration options works?
[02:14] <luislavena> (branch based and globals)
[02:15] <luislavena> ok, it seems so, just wanted to be sure :)
[02:15] <abentley> lifeless: is get_data_stream_for_search meant to have ordering restrictions?
[02:59] <lifeless> abentley: no more so than the get_data_stream api it replaced
[03:00] <abentley> They both have prefixes with lists of versions after them.
[03:00] <abentley> I'm not sure whether a prefix is allowed to be repeated.
[03:00] <abentley> The use of prefixes suggests that the designer wasn't expecting the prefix to change frequently.
[03:00] <lifeless> I don't think the current code or tests prevent that
[03:01] <lifeless> the goal was a single namespace for all data atoms
[03:01] <abentley> Since ('a')['b'], ('c')['d'] isn't all that helpful.
[03:02] <abentley> But in packs, I would expect the prefix to change at least twice per revision.
[03:02] <lifeless> why?
[03:02] <abentley> If you read from the beginning.
[03:02] <lifeless> oh right
[03:02] <lifeless> currently on sftp I do four readv's per pack
[03:03] <lifeless> each readv linear sorted
[03:03] <lifeless> (for fetching this is)
[03:04] <abentley> Cool.
[03:04] <lifeless> that seems a reasonable tradeoff in simplicity/speed - it lets us keep the read revision, read inventory, read texts etc sequence
[03:04] <abentley> Oh, I see.
[03:04] <lifeless> which means we don't copy unreferenced data, can sanity check etc
[03:05] <abentley> But revisions and sigs are fulltexts, so it wouldn't hurt to read them at the same time as inventories.
[03:05] <abentley> No additional memory cost, at least.
[03:05] <lifeless> and transactional inserts into the repository means we can just flush to disk
[03:05] <lifeless> abentley: right, it can certainly be tweaked; howver the sigs and revisions are in different indices to the inventories
[03:06] <lifeless> so if we were trying to optimise memory more we would actually be dropping index content from memory after grabbing the data for that index
[03:06] <abentley> Yes, I suppose it makes sense to do each index in turn.
[03:07] <lifeless> I haven't had any breakthough thoughts about storage/repository; I will reply to the thread though and see if we can get a good compromise; I _do not_ want to prevent improvements
[03:08] <abentley> Even though we haven't agreed on the structure for Storage, I think that we can agree that an implementation of iter_files_bytes that reads each pack only once would be a win.
[03:09] <lifeless> abentley: oh for sure
[03:09] <abentley> So I'm going to look at restructuring the knit-building code to support that.
[03:09] <lifeless> abentley: great; I hope you'll find its already half way tere
[03:09] <lifeless> *there*
[03:09] <lifeless> I split out the 'get data' stuff to a KnitAccess helper a ways back
[03:10] <abentley> Oh, I've been wondering what that thing was.
[03:10] <lifeless> so PackAccess knows how to get stuff from an arbitrary key
[03:10] <lifeless> by mapping the key which is (index, key)
[03:10] <lifeless> through the index to get an actual pack file
[03:11] <lifeless> KnitAccess maps likewise but to a single file the .knit file
[03:11] <lifeless> this gives KnitData as simply providing the logic for combining hunks etc
[03:11] <abentley> Hmm.  Somewhat different approach than I was thinking, but it could work.
[03:12] <lifeless> and KnitIndex maps into a combined index for packs, which filters out the fileid prefix
[03:12] <lifeless> so what I have been thinking about doing is
[03:12] <lifeless> adding a file id prefix to the standard knit code
[03:13] <lifeless> which the existing KnitIndex stuff would enforce as always being the file id the index is for
[03:13] <lifeless> and the pack index mapper would just stop filtering out the file id prefix
[03:14] <lifeless> thus giving the existing iter_versions etc stuff the ability to deal with many file ids at once
[03:14] <lifeless> anyhow, I'm rambling - this is what I had in my head, not the only way to do it :)
[03:14] <abentley> Well, it's interesting.
[03:15] <abentley> I basically already have the code to map a bunch of requested knit entries to their pack transport/name/offset/size.
[03:16] <abentley> So I was thinking about doing that part up front.
[03:17] <lifeless> the map code should a single index iter_entries query really :)
[03:17] <abentley> Basically via the iter_raw_items variation on get_data_stream.
[03:18] <abentley> Yeah, I like that.
[03:19] <lifeless> the thing I like about extending knit is that the combining logic does not get duplicated, or have to move
[03:20] <lifeless> so improvements there will still help anything thats roughly delta combining related
[03:24] <abentley> The downside is you can't retrieve everything in a single read.
[03:27] <lifeless> hmm? sure you can
[03:27] <lifeless> get_raw_records
[03:29] <lifeless> used by read_records_iter_raw
[03:30] <lifeless> so read_records_iter_raw is already multiple-file-id ready, as long as the _Access object it has been given is
[03:33] <abentley> By everything, I meant fetching files, revisions, inventories and signatures all at once
[03:33] <lifeless> oh right
[03:34] <abentley> You can achieve that by adding a prefix, I think.
[03:34] <lifeless> hmm, if we guarantee that the indices contain enough data
[03:37] <abentley> You then wind up with something very close it Storage.iter_raw_items.
[03:37] <lifeless> I like the idea of getting get_data_stream and insert_data_stream
[03:38] <abentley> s/it/to
[03:50] <abentley> lifeless: I think you were cut off: "I like the idea of getting get_data_stream and insert_data_stream"
[03:58] <abentley> But I'll mention that if we get the inventory first, we can do fetch and build_tree at the same time.
[03:59] <lifeless> yup
[03:59] <lifeless> fetch currently puts the inventory before all texts
[03:59] <lifeless> for locality of reference its grouped too
[03:59] <lifeless> not really cut off; just not finished
[08:51] <Aloha> whats the difference between a branch and a trunk?
[08:53] <weigon> Aloha: one starts with a b, the other with a t. That's pretty much it.
[08:53] <Aloha> weigon, whats the point of differentiating?
[08:53] <weigon> Aloha: "trunk" is svn-speak for the main-development-branch
[08:54] <Aloha> weigon, so why have more than one branch?
[08:54] <fullermd> Trunk is a branch that you call trunk.
[08:54] <weigon> Aloha: release-branches, feature-branches, merge-branches, ...
[08:54] <weigon> in bzr-world everything is a branch, everyone has it's own repository.
[08:55] <Aloha> weigon, so whats the difference between feature branch and release branch?
[08:55] <weigon> Aloha: I think the best example is taking a look how the linux kernel-development works
[08:56] <fullermd> Pretty much the difference between a water glass and a milk glass...
[08:56] <Aloha> why would my project have more than one branch? different parts of it go in different branches?
[08:57] <weigon> Aloha: no, put sometimes you have to release something to users|customers
[08:57] <weigon> and they call you 6 month later about a bug and you are already working the next big release
[08:58] <Aloha> weigon, so you can pull up the source code from that release and work on the bug?
[08:58] <weigon> ... and fix it for that release to build a new release (1.0.1), while you are still doing your main-dev in "trunk" for the 2.0 release
[08:59] <weigon> if you want to implement a new feature and want to write a Proof-of-Concept you will commit it not to trunk, but to a feature branch.
[08:59] <weigon> if it works well and matures, you merge the new feature back into trunk
[08:59] <Aloha> weigon, so your source code that you edited would be in 1.0-dev branch and your release would be in 1.0.1-release?
[09:00] <weigon> if it doesn't work out, you only have to trash your work, not the work of others that are in the main-dev branch
[09:00] <Aloha> weigon, gotcha
[09:00] <weigon> if you do it right, the main-dev branch is always in release quality
[09:01] <weigon> everything unstable is in feature branches until it is well tested and can be merged over
[09:02] <Aloha> weigon, gotcha
[09:03] <weigon> Aloha: that means proper test-cases, unit-testing, ...
[09:04] <Aloha> weigon, do you have a seperate branch for debian packages? or do you make those from release tarball?
[09:16] <weigon> Aloha: debian packages are built aside anyway.
[09:16] <Aloha> weigon, aside?
[09:17] <weigon> Aloha: scroll down on http://packages.ubuntu.com/feisty/net/hostapd
[09:17] <weigon> Source Package: hostapd, Download: [dsc] [hostapd_0.5.5.orig.tar.gz] [hostapd_0.5.5-3.1.diff.gz]
[09:18] <weigon> it is always a the original tar + a diff that includes the build-files for debian
[09:18] <Aloha> weigon, i know but the files uses to build the original tarball, does anyone keep a debian branch knowing that that branch will only be used to build packages?
[09:19] <Aloha> s/uses/used/
[10:40] <ubotu> New bug: #187593 in bzr-webserve "list index out of range" [Undecided,New] https://launchpad.net/bugs/187593
[13:14] <ricardokirkner> hi. I just installed the bzr-svn plugin (I am running fedora core 7). However, when I try to check out an svn branch, I get an error telling me that the url is not a branch. The cmd 'bzr selftest svn' failed, but I cannot make out what the problem is. Can anyone help me out here, please?
[13:15] <ricardokirkner> the error I get is '_get_location_config() takes exactly 1 argument (4 given)'
[13:40] <ricardokirkner> ok, I found out the error. I relates to bzr-svn not being able (yet) to check out from webdab
[13:40] <ricardokirkner> webdav
[15:01] <jelmer> ricardokirkner: bzr-svn supports webdav yet
[15:03] <jelmer> ?
[15:18] <awilkins> Can anyone tell me the significance of .~1~ files in my BZR trees?
[15:21] <LeoNerd> They're files left behind by 'bzr revert'
[15:21] <LeoNerd> When you 'bzr revert' it moves your locally-changed file to .~1~ in case you wanted to keep it, before overwwriting it with a clean copy
[15:21] <awilkins> Aha, thanks
[15:21]  * awilkins executes ls -r -inc *.~1~ | rm
[15:28] <dato> awilkins: there is bzr clean-tree --detritus, from the bzrtools plugin. try it with --dry-run first.
[15:56] <jelmer> info je
[15:56] <jelmer> info jelmer
[15:57] <jelmer> whoops
[15:57] <jelmer> sorry
[17:01] <alefteris> after i upgrade my launchpad branch using<EMAIL_ADDRESS>what should i do to my local working copy?
[17:01] <beuno> alefteris, upgrade it too
[17:01] <beuno> and, reconcile both
[17:01] <beuno> bzr reconcile<EMAIL_ADDRESS>[17:03] <alefteris> i was reading this http://beuno.com.ar/archives/48, it mentions that I should recogline only if there is a problem.. is reconcile a dangerous operation?
[17:03] <beuno> alefteris, oh, then I have to correct it
[17:03] <beuno> you *must* do reconcile
[17:03] <alefteris> :)
[17:03] <beuno> alefteris, no, it isn't
[17:03] <beuno> upgrade might be
[17:03] <alefteris> ok thanks
[17:04] <beuno> alefteris, I changed it a few hours ago, can you see if it's clearer now:  http://beuno.com.ar/archives/48
[17:04] <beuno> (upgrade, on the other hand, already does it's own backup before doing anything, so all operations are fairly safe)
[17:04] <synic> hey folks.  does this mean anything to any of you?
[17:04] <synic> [projects]$ bzr branch<EMAIL_ADDRESS>exaile
[17:04] <synic> bzr: ERROR: Could not install revisions:
[17:04] <synic><EMAIL_ADDRESS>[17:06] <beuno> synic, what version of bzr are you using?
[17:06] <synic> 1.0.0
[17:06] <beuno> synic, you might want to use http to branch
[17:07] <beuno> (and, is that your user in LP?)
[17:07] <synic> well, I'm trying to branch because a pull failed with the same error
[17:07] <synic> yes, that's my LP user
[17:07] <alefteris> beuno, you used to have a "check" step before the upgrade, its not actualy needed?
[17:07] <beuno> alefteris, not really, if you have knits, it isn't required
[17:08] <beuno> I also moved reconcile to _after_ upgrading
[17:08] <beuno> it's million times faster
[17:09] <beuno> synic, let me try and branch it
[17:09] <synic> yeah, I just installed bzr 1.1 and same error
[17:09] <beuno> I get 0 revisions
[17:10] <synic> uh, there are a lot more than 0 revisions
[17:10] <beuno> hmmmm
[17:11] <beuno> LP is reporting problems with the branch...
[17:11] <synic> great.
[17:11] <beuno> synic, can you do: bzr reconcile<EMAIL_ADDRESS>[17:11] <beuno> has the branch been upgraded lately?
[17:12] <synic> well, I didn't do it (I wouldn't even know how), but one of the other devs may have done something
[17:12] <beuno> synic, try and run reconcile, and I'll ask in #launchpad if anyone can help
[17:12] <synic> running it now
[17:13] <beuno> ah, you already did...
[17:13] <beuno> let's give reconcile a try first
[17:23] <synic> whew, reconciling isn't the speediest operation, heh ;-)
[17:24] <synic> beuno: ok, yeah, it's still broken.
[17:25] <beuno> synic, argh...   I suspect it's a LP problem
[17:25] <synic> bummer
[17:26] <beuno> lifeless, jam, abentley, any ideas on why https://code.launchpad.net/~exaile-devel/exaile/main  might be broken?
[17:27] <abentley> Broken how?
[17:28] <beuno> abentley, it doesn't branch
[17:28] <beuno> 0 revisions
[17:28] <beuno> and LP reports it has a problem
[17:28] <beuno> synic already ran reconcile on it
[17:28] <beuno> and still nothing
[17:28] <beuno> (nobody seems to be available in #launchpad)
[17:30] <beuno> I see there is a broken character in the last commit message
[17:31] <beuno> but I'm not sure if that can cause LP to go crazy
[17:31] <beuno> (codebrowse also breaks: http://codebrowse.launchpad.net/~exaile-devel/exaile/main/files)
[17:32] <synic> yeah, but on all the revisions, not just the last one (I don't know if that means anything)
[17:32] <beuno> synic, I think it basically mean LP can't ready from the branch either
[17:33] <synic> hrmm
[17:33] <abentley> Yeah, you can see the "branch has errors" thing on the page
[17:34] <beuno> abentley, so... how can this be solved?   push --overwrite from a healthy copy?
[17:34] <abentley> It's also in format 5, which is a bit odd.
[17:34] <abentley> Did you upgrade it?
[17:34] <abentley> or did you push from an upgraded branch?
[17:34] <beuno> synic, can you find out what the last dev did?
[17:35] <synic> I'll have to wait until he gets online
[17:35] <abentley> But I can confirm that revision-history is empty, so Bazaar is correctly interpreting that.
[17:36] <synic> I'm not real excited to hear that :)
[17:37] <beuno> synic, maybe the branch was upgraded and not reconciled
[17:37] <beuno> do you have a healthy copy locally?
[17:38] <beuno> (even if a bit out of date)
[17:38] <synic> I have one at home.  I've been trying to log in and get it, but I can't get in for some reason
[17:38]  * synic thinks of where there might be another
[17:39] <synic> ah, I have one on exaile.org, but I'm not sure how old it is.
[17:39] <beuno> synic, just so we can check what storage format you have and narrow it down to "someone upgraded recently and broke stuff"
[17:41] <synic> ok, yeah, I found it.  How do I check?
[17:41] <beuno> synic, bzr info -v | grep 'repository'
[17:42] <synic> bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n'
[17:42] <beuno> synic, ah, so it's packs. And you're using some old bzr version
[17:43] <synic> on exaile.org, yeah.  It's 0.90
[17:43] <synic> I'll upgrade, if it won't hurt anything
[17:43] <beuno> synic, I would recommend upgrading it to 1.0 (or 1.1 even)
[17:44] <synic> k, doing that now
[17:44] <beuno> you should try and get a hold on the last dev that uploaded
[17:44] <beuno> see if he can fix his locla copy
[17:44] <beuno> if not
[17:44] <beuno> find the latest healthy one you can find
[17:45] <beuno> to 'bzr reconcile;
[17:45] <beuno> s/;/'
[17:45] <beuno> and then add the changed files
[17:45] <synic> ok
[17:45] <beuno> commit
[17:45] <beuno> and move on  :D
[17:46] <beuno> make sure everyone is using bzr 1.0+, and have upgraded their local branches
[17:46] <beuno> I just blogged on how to upgrade a few days ago: http://beuno.com.ar/archives/48
[17:46] <abentley> beuno: I'm trying to get more info on this, but no luck so far
[17:48] <beuno> abentley, great, thanks!   synic can you stick around for a while and see if we can dig a bit deeper?
[17:48] <synic> yeah
[17:48] <dacresni> how do i get bzr 1.0 on ubuntu?
[17:48] <synic> might be a bit before the other dev signs on
[17:48] <synic> if he does at all
[17:48] <synic> he's in australia, I'm in utah
[17:48] <dacresni> thanks
[17:48] <beuno> dacresni, you can get the latest from: https://launchpad.net/~bzr/+archive
[17:49] <synic> bzr info -v | grep repository repository: Packs containing knits without subtree support
[17:49] <synic> that's after the upgrade.
[17:50] <dacresni> i c
[17:50] <beuno> synic, good. I would run 'bzr reconcile' on it now
[17:50] <dacresni> thanks beuno
[17:50] <beuno> dacresni, no problem!  :D
[17:51] <synic> beuno: it says "no repository present".  Ack, it's a checkout, not a branch.  Rats.
[17:52] <beuno> synic, you can use 'bzr unbind' to make it into a branch, although I'm not sure who it's parent is
[17:52] <synic> it's parent is the broken branch
[17:53] <beuno> synic, I believe unbind won't call the parent at all if it's a regular checkour
[17:53] <beuno> s/checkour/checkout
[17:53] <synic> heh, it's a --lightweight
[17:53] <beuno> aaargh
[17:53] <beuno> not your lucky day...
[17:54] <synic> no, no it isn't.
[17:54] <beuno> well, I'd find out what kind of beer abentley likes then  :p
[17:54] <abentley> You could try doing bzr reconfigure --branch, though.
[17:55] <synic> in the checkout?
[17:55] <abentley> synic: yes.
[17:55] <synic> k
[17:55] <dacresni> I like irc so much more than forums, its so much harder to search for what you wnt
[17:55] <abentley> That assumes that upstream actually has the necessary revisions.
[17:55] <dacresni> c ya
[17:56] <abentley> bzr reconfigure replaces bind, unbind and remove-tree.
[17:57] <abentley> Though I suppose you probably want reconfigure --tree.
[18:01] <dacresni> hey, back
[18:02] <dacresni> had a bit of a "problem with the package
[18:03] <dacresni> well, i just wan'ted to fix my commit signing process
[18:05] <dacresni> it responded gpg: problem with the agent - disabling agent use
[18:05] <dacresni> bzr: ERROR: Failed to gpg sign data with command "['gpg', '--clearsign']"
[18:06] <dacresni> is this a bzr issue or a gpg issue
[18:07] <dacresni> ?
[18:07] <dacresni> beuno are you still there?
[18:08] <beuno> dacresni, yes, although I haven't used gpg signing in bzr
[18:08] <beuno> have you signed any commits yet?
[18:08] <dacresni> i tried
[18:08] <dacresni> no i haven't
[18:08] <beuno> do you have your key setup with gpg?
[18:09] <dacresni> i think so
[18:09] <dacresni> i followed the instructions on the pgp site
[18:09] <dacresni> i mean gpg
[18:09] <dacresni> and those of the bzr site linked from bzrVSgit
[18:10] <dacresni> the one http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/
[18:12] <beuno> dacresni, and you've setup the email to use to sign commits?
[18:12] <dacresni> im using this localy
[18:12] <dacresni> so no
[18:15] <beuno> dacresni, does:   gpg --list-keys    print out your key?
[18:15] <dacresni> hmm
[18:15] <dacresni> yes
[18:16] <beuno> and that's the same email address you have configure in "bzr whoami"?
[18:16] <dacresni> pub something
[18:16] <dacresni> uid, my info
[18:16] <dacresni> accept for the comment
[18:16] <dacresni> o wait
[18:16] <alefteris> beuno, the upgrade prosedure at a launchpad branch sure takes a while :)
[18:16] <dacresni> ok, so i put my whole name
[18:17] <dacresni> thanks i guess ill be fixing that
[18:17] <beuno> alefteris, ah, yes, large branches + remote access are always fun to watch  :D    The upgrade is worth it though!
[18:17] <beuno> dacresni, np
[18:18] <dacresni> shouldn't it not use the comment?
[18:18] <dacresni> thats kind of silly
[18:19] <dacresni> i have 2 keys, one at home and one at work
[18:19] <beuno> dacresni, that's why you can specify your email on ~/bazaar/, so it can find the key you want
[18:20] <dacresni> i c
[18:21] <dacresni> ok, so i added the comment to my email,
[18:21] <dacresni> thats probibly going to screw up my patch emails should i use them in the future
[18:22] <dacresni> email not valid
[18:23] <dacresni> seriously, does anyone know how that works? does it really compare the entire line? or could it exempt the comment?
[18:24] <beuno> dacresni, I haven't used it really. jelmer, I believe I've seen you play around with signing commits?
[18:29] <dacresni> dang, i wonder if that came from intering the pass fraze to often
[18:30] <beuno> dacresni, sorry, everyone seems busy today
[18:30] <dacresni> 'ts ok
[18:30] <dacresni> it seems the probliem with pgp
[18:31] <dacresni> there seems to be a problem with the aigent
[18:35] <jelmer> beuno: yep, I'm signing most of my commits
[18:36] <dacresni> could you help
[18:36] <jelmer> dacresni: is there a particular reason you'd like to sign commits ? There is no way to verify signatures yet afaik
[18:36] <dacresni> well,
[18:36] <dacresni> i was trying to get my boss to use it
[18:36] <jelmer> dacresni: Should be a matter of setting "create_signatures = always"
[18:36] <dacresni> but first i need to get the security features workign
[18:36] <dacresni> o yeha
[18:37] <dacresni>  thats already there
[18:37] <dacresni> otherwise it wouldn't be asking me to  sign would it?
[18:37] <jelmer> dacresni: right, so what exactly is your question ? :-)
[18:37] <jelmer> that should be all there is to it.
[18:38] <dacresni> why isn't gpg working, sorry it seems to be a problem with the agent
[18:38] <jelmer> dacresni: Have you got gpg working outside of bzr ?
[18:38] <dacresni> just now, no
[18:38] <dacresni> i'll give you the error message
[18:39] <dacresni> gpg: problem with the agent - disabling agent use
[18:39] <dacresni> bzr: ERROR: Failed to gpg sign data with command "['gpg', '--clearsign']"
[18:39] <jelmer> dacresni: Did you create a key earlier?
[18:39] <dacresni> but first i need to find out yes
[18:39] <jelmer> dacresni: Also, there is no added security in signing revisions at this point..
[18:39] <dacresni> yes i created the key
[18:39] <dacresni> oy,
[18:40] <jelmer> Does "gpg --clearsign <somefile>" on the command-line work?
[18:40] <dacresni> same issue
[18:40] <dacresni> gpg: problem with the agent - disabling agent use
[18:40] <jelmer> the agent is optional
[18:40] <dacresni> and then proseads
[18:41] <dacresni> well, this is kind of confusiong
[18:41] <jelmer> that's just a warning, it should work fine without the agent as well
[18:41] <dacresni> sorry
[18:41] <dacresni> confusing
[18:41] <dacresni> it did work, (im finding that i've already commited something"
[18:41] <dacresni> but bzr still exits with an error
[18:41] <jelmer> it does the signature after the commit
[18:41] <dacresni> was this resolved in later version?
[18:42] <dacresni> well let me see
[18:42] <jelmer> so if the sign fails you will still have a revision, it just won't be signed
[18:42] <dacresni> well
[18:42] <dacresni> i can't find the revision comment
[18:45] <dacresni> that IS a problem
[18:46] <jelmer> dacresni: it's not in "bzr log" ?
[18:46] <dacresni> nope
[18:46] <dacresni> has anyone else experienced this problem
[18:46] <dacresni> ?
[18:46] <jelmer> dacresni: What problem specifically?
[18:46] <jelmer> not being able to sign revisions?
[18:47] <dacresni> i will disable the signing but, not being able to comment revisions
[18:47] <dacresni> thats a problem
[18:47] <jelmer> dacresni: What do you mean with "comment" revisions?
[18:47] <dacresni> let me see if disableing signing allows my comments to be saved
[18:47] <jelmer> dacresni: Not being able to specify a commit message?
[18:48] <dacresni> well,
[18:49] <dacresni> theoreticly yes but, if its not saving my comments, it snot saving my revisions
[18:49] <dacresni> i want to know if this ever happened in a more recent version
[18:50] <dacresni> im using, just now, 1.1.0 sorry
[18:50] <dacresni> i thought i was using 094 like i was an hour ago
[18:50] <jelmer> dacresni: What do you mean with comments? commit messages?
[18:50] <dacresni> "the package gave me errors in debian"
[18:50] <dacresni> yes the commit messagese
[18:51] <jelmer> dacresni: Does it ask you for a commit message or do you specify one on the command line?
[18:51] <dacresni> its been fixed after signing was disabled
[18:51] <jelmer> ok
[18:51] <dacresni> it asked for a commit message
[18:51] <dacresni> this is interesting behavior no?
[18:51] <alefteris> beuno, upgrade finished, ole :)
[18:52] <jelmer> dacresni: It simply doesn't add a revision for me if the sign step failed
[18:52] <beuno> alefteris, yay!   Now reconcile should be fairly quick
[18:52] <dacresni> thats what's happened for me
[18:53] <dacresni> i just didn't look at it like that
[18:53] <jelmer> dacresni: That's correct.
[18:55] <dacresni> so where is the branch where they are implementing the security?
[18:55] <dacresni> the revision signing?
[18:55] <jelmer> dacresni: Revision signing has been supported for a long time
[18:55] <jelmer> afaik nobody has started working on signature verification yet
[18:56] <dacresni> ps this didn't happen at home, on my mac. i dont think
[18:56] <dacresni> here im using ubuntu
[18:56] <jelmer> dacresni: what exactly didn't happen on your mac?
[18:56] <dacresni> at home, macports on a g5
[18:56] <dacresni> it worked as normal
[18:56] <dacresni> i installed macgpg
[18:56] <dacresni> then added the line to my bazaar config
[18:56] <jelmer> dacresni: It's gpg that's misconfigured on your Linux machine
[18:56] <dacresni> then i signed some local commits, and it worked
[18:56] <dacresni> probibly
[18:57] <jelmer> I'm quite sure it is
[18:57] <dacresni> i do believe the probem was with gpg
[19:01] <dacresni> this is why i straddle between mac and linux
[19:01] <dacresni> linux you have democracy issues and mac you have monarchy issues
[19:01] <dacresni> like that dtrace issue... perhaps i should use solarus
[19:02] <jelmer> dacresni: There are more userfriendly frontends for gpg on Linux
[19:02] <dacresni> but how can any work if gpg has issues
[19:03] <jelmer> They can take of configuring gpg for you
[19:03] <dacresni> so what does that/
[19:03] <dacresni> ?
[19:03] <jelmer> what do you mean? Examples of programs?
[19:03] <dacresni> yes, please
[19:07] <dacresni> first, whats this agent the error speaks of?
[19:10] <jelmer> dacresni: seahorse is one
[19:10] <jelmer> dacresni: gnupg's agent program
[19:10] <jelmer> dacresni: I don't use it but apparently you've got it configured
[19:10] <dacresni> but what is the agent in reference to gnupg
[19:11] <dacresni> and why did mine screw up
[19:11] <brink_> Am I somehow getting Bazaar from the wrong universe?   On Windows and OSX I'm at 1.1.0   On Ubuntu the most recent version from apt-get seems to be 1.0.0.candidate.1.    Is my Ubuntu installation messed up?
[19:11] <jelmer> dacresni: You may want to ask in the gnupg channel
[19:11] <jelmer> dacresni: I suspect it's something similar to ssh-agent
[19:11] <jelmer> but for gpg
[19:12] <jelmer> dacresni: Still, why are you so keen on setting up signing revisions? There's no point in doing so at this time and Bazaar may have better integration with apps like seahorse in the future.
[19:12] <dacresni> i c
[19:13] <dacresni> well, i wanted to get some kind of security so that this app is comparable to git in some other way other than workflow flexablility
[19:14] <Peng> brink_: Get it from PPA.
[19:14] <Peng> brink_: https://launchpad.net/~bzr/+archive
[19:16] <jelmer> dacresni: revision signing won't get you any security at all at this point. it may help you verifying the integrity of now signed revisions in the future
[19:16] <dacresni> well, ok
[19:16] <dacresni> the only reason why i look at this project more closely than git is because it's all done in one language
[19:16] <dacresni> instead of 5
[19:16] <jelmer> dacresni: I agree it's a useful feature though
[19:16] <dacresni> 1 being c
[19:17] <jelmer> dacresni: bzr is written in python...
[19:17] <dacresni> no i mean one of gits language being c
[19:17] <jelmer> ah, ok
[19:21] <brink_> Peng:  Thanks.  I'll give it a try.
[19:22] <Peng> Wait, so signed revisions aren't verified?
[19:22] <dacresni> yup
[19:22] <Peng> That...sucks.
[19:23] <dacresni> i would like it if it varafied the integrity of the signature before its accepted to the tree on bzr servers
[19:23] <dacresni> i guess we'll have to settle for ssh
[19:24] <dacresni> not that that's a bad thing
[19:28]  * Debolaz still has a fondness for the simplicity of git's design.
[19:29] <dacresni> hmm
[19:29] <dacresni> im curious of what that is
[19:29] <jelmer> Debolaz: in what way is git simpler than hg or bzr?
[19:29] <dacresni> i mean, simple is linus's style but how is git siimple
[19:29] <jelmer> the way the commands work?
[19:30] <dacresni> the security model itself
[19:30] <dacresni> '
[19:30] <dacresni> ?
[19:30] <Debolaz> The commands are horribly complex.
[19:30] <dacresni> exactly
[19:31] <Debolaz> But the fundamental ideas that git is based on are very simple.
[19:31] <dacresni> and those are?
[19:31] <jelmer> Debolaz: I don't see that those ideas are so different from the ones in bzr or hg though
[19:31] <dacresni> the decentralization model bzr copy
[19:31] <jelmer> dacresni: bzr is older than git...
[19:32] <Debolaz> Everything is an object in a filesystem, named after its content. Every branch is simply a file pointing to an object. When you update, you just make new objects and write the name of the head tree object to the branch file.
[19:32] <dacresni> really?
[19:32] <dacresni> i didn't know that
[19:33] <Peng> Also, the DVCS model is older than either bzr or git..
[19:33] <jelmer> Debolaz: The only thing that's different there is that bzr doesn't name a file after its contents but uses a pseudo random id
[19:33] <Debolaz> It could easily be reimplemented with a few shell scripts. Horribly inefficiently implemented, but still very simple in concept.
[19:34] <dacresni> ? git could be reimplemented in a few shell scripts?
[19:34] <jelmer> Debolaz: I still don't see what's so fundamentally different.
[19:34] <dacresni> so mw is out to lunch"?
[19:34] <jelmer> I think it's dinner, rather
[19:35] <dacresni> its only 1
[19:35] <dacresni> o wait
[19:35] <dacresni> never mind
[19:36] <Debolaz> jelmer: Well, I never made the claim that it was fundamentally different. But it is different, and it is simpler. Granted, I know very little about bzrs internal workings, but even if what you say is the only big difference in storage, then that still increases complexity by some bit.
[19:37] <rcohen> some complexity is necessary to get efficiency and features
[19:37] <rcohen> git's original storage model was horribly space inefficient
[19:38] <Debolaz> Yes it was. But very simple.
[19:38] <jelmer> Debolaz: Using ids rather than file contents to identify files doesn't impact the complexity of the storage layer all that much
[19:38] <jelmer> Debolaz: And you've still failed to mention a reason why it's simpler.
[19:38] <rcohen> simple and unusable for the primary use case
[19:39] <rcohen> i'm not sure what's so admirable about simplicity if it doesn't do what you need
[19:39] <Debolaz> jelmer: You lose the ability for renames to be detected by design for instance. You have to track this differently somehow (Possibly using hashes, but then you're back at square one again).
[19:39] <dacresni> well, this has been the argument between git and bzr before, storage format
[19:39] <Debolaz> Let me again emphasize that I'm not saying anything bad about bzr here, I barely know bzr. :)
[19:39] <jelmer> Debolaz: bzr tracks renames explicitly rather than inferring them using complex algorithms that have to determine whether one file was a rename of another.
[19:40] <rcohen> it's highly debatable whether automatically detecting file renames is a good idea
[19:40] <dacresni> it might because not could cause duplicity
[19:41] <rcohen> it can do really bad things in the worst case, and a lot of effort is put into making sure that the worst case for a merge algorithm isn't all that bad
[19:41] <jelmer> Debolaz: Right, I'm not saying git is bad or there are no reasons for picking git over bzr either. I just don't understand why you claim git is simpler...
[19:41] <fullermd> CVS is simpler yet; we should switch   :)
[19:41] <jelmer> rcohen: yeah, I agree. It's usually better if you can predict when it's not going to work
[19:42] <jelmer> fullermd: :-)
[19:43] <jelmer> rcohen: Finding the right way to track file identity is hard though
[19:43] <jelmer> rcohen: bzr uses file ids, but they only allow you to track renames, not e.g. copies
[19:43] <rcohen> i'm a big fan of doing it explicitly
[19:44] <rcohen> i don't think supporting copies is all that useful
[19:44] <rcohen> the point of doing it would be that whatever merge algorithm would be aware of it
[19:45] <rcohen> in my experience, a user would use the copy when they wanted to split a file
[19:45] <jelmer> copies can be useful when splitting files
[19:45] <fullermd> I'm a lot more interesting in splits and joins.  But copies you can kinda get for free with those mechanisms, so...
[19:45] <rcohen> which, if you then tried to merge across it, would cause horrible conflicts and ambiguity
[19:45] <Debolaz> jelmer: Because I gave the complete description of how the fundamental of git works above, and I do not think bzr or hg can be described with as few lines. git is a simple design. Possibly at the cost of efficiency, userfriendlyness (Yeah, I agree about the commands being less than idea), and other things. Bzr might be better at those things and yes, I agree those things are a higher priority for most users.
[19:46] <jelmer> Debolaz: the description you just gave above almost matches bzr and hg
[19:46] <rcohen> Debolaz: the point is that in order to be useful even git has taken on extra complexity
[19:47] <rcohen> Debolaz: by comparing git "conceptually" to the implementations of bzr and hg you're comparing apples and oranges
[19:47] <Debolaz> jelmer: I know there are significant differences from it at least for hg. Simply naming a revision by a SHA1 ID is not the same thing as actually storing the content in a file with that name. The former might be a part of something significantly more complex.
[19:47] <Debolaz> But I guess we can agree to disagree, I don't want to make this turn into a flamewar. :)
[19:48] <jelmer> Debolaz: yeah, let's do that :-)
[19:48] <fullermd> Shucks.  I was just making popcorn...
[19:48] <jelmer> rcohen: Yeah, merges would be an interesting problem for splits
[19:48] <jelmer> rcohen: but it would be awesome if we could get that working
[19:49] <rcohen> jelmer: believe me, i've thought a lot about it
[19:49] <rcohen> there be dragons
[19:49] <Debolaz> However, I would like to make a point about automatic detection, not neccesarily about renames. Whenever something isn't automatically detected, or enforced a certain way, users will screw it up. I think the most notable example of this is subversion branching.
[19:49] <jelmer> rcohen: :-)
[19:49] <jelmer> rcohen: even without proper merge support being able to represent copies would be nice though
[19:50] <jelmer> rcohen: since we get that data when we import from other version control systems
[19:50] <rcohen> jelmer: it's hard to say what should happen without merge support
[19:50] <rcohen> let's say your merge doesn't know anything about copies and the system pretends that the full history applies to both files
[19:51] <rcohen> now, you didn't really want a copy, you wanted a split
[19:51] <rcohen> so you go ahead and delete half of each file
[19:51] <rcohen> in another branch, someone modified the file
[19:51] <rcohen> then you merge that branch in
[19:52] <rcohen> suddenly, you've got a massive conflict in the file which deleted that section
[19:52] <jelmer> rcohen: ouch, yeah, that would be a problem
[19:52] <rcohen> now let's say you didn't want to split, you really wanted a copy (because you're into cutting and pasting, who knows)
[19:52] <jelmer> Debolaz: yeah, leaving out the concept of a branch really hurt Subversion
[19:53] <rcohen> someone in another branch modifies the file
[19:53] <jelmer> Debolaz: and it hurts bzr-svn now, since it has to guess what users consider a branch
[19:53] <rcohen> you merge that branch in, both files get the merge, but you only wanted the "original" to get the change
[19:54] <foom> is there a way to create a branch in an svn repository using bzr?
[19:54] <foom> i tried bzr push but it threw an error at me
[19:54] <jelmer> foom: try "bzr svn-push"
[19:54] <rcohen> one of the big problems is that there are conflicting use cases for copy
[19:54] <jelmer> foom: I haven't gotten round into implementing it in "bzr push" yet
[19:54] <foom> aha, thanks. :)
[19:55] <rcohen> i could make you even more afraid if you wanted to support a separate "split" command :)
[19:55] <dacresni> thats like telling telling a species with no eyes that something is red
[19:55] <jelmer> rcohen: I was about to suggest that :-)
[19:55] <jelmer> rcohen: Actually, we already have a split command, but it splits trees, not files
[19:56] <dacresni> thats only a little inefficient
[19:57] <rcohen> jelmer: let's take an easy case for split, the top and bottom halves of a file each go their own way
[19:57] <abentley> beuno: The error message we have is Could not install revisions<EMAIL_ADDRESS>[19:57] <rcohen> jelmer: what happens if in another branch someone adds content at the place where the file was split?
[19:58] <rcohen> jelmer: it gets worse if there are conflicts at the split point
[19:58] <abentley> beuno: I realize you've already seen something like that.
[19:59] <jelmer> rcohen: Representing that conflict in the file(s) would be the tricky bit.
[19:59] <rcohen> jelmer: it's not so much the problems with the merge algorithm and the UI
[19:59] <Debolaz> jelmer: I've had to extend git-svn for the same reason. It makes the ideological but foolish assumption that the subversion users know what they're doing. :)
[20:00] <rcohen> s/and the UI/as the UI/
[20:01] <jelmer> rcohen: Perhaps create conflicts in both files, adding a conflict in both cases and a comment?
[20:01] <jelmer> rcohen: I see your point though
[20:02] <rcohen> jelmer: also remember that was the easy case :) files can be split in other bizarre ways which may not be detected properly or are partial copies, etc etc
[20:02] <jelmer> Aaron has also explained some other issues potential issues with merges after copy earlier
[20:03] <jelmer> Even without merge, I think copy could be still be quite useful though
[20:03] <jelmer> for "bzr log" and "bzr annotate"
[20:03]  * fullermd seconds.
[20:03] <jelmer> and just for roundtripping
[20:03] <rcohen> so just an annotation in the history which says "this file was copied from that file"?
[20:04] <rcohen> but not actually used for anything
[20:04] <jelmer> rcohen: Well, only when looking at the history of a file
[20:06] <jelmer> rcohen: Do you know whether Subversion supports merges across copies?
[20:06] <rcohen> not offhand, though i doubt it
[20:06] <abentley> rcohen: A day after you expressed reservations about LCA not doing resolution against the base initially, a user found the problem with that; it doesn't emit conflicts when one side deletes a line, but the other changes it.
[20:06] <abentley> rcohen: But in my defense, knit gets that wrong too.
[20:07] <rcohen> abentley: ah, knit can be made to do that correctly :)
[20:07] <rcohen> there's a subtle difference in how cdv and bzr implement the algorithm
[20:08] <rcohen> in cdv, the annotations are on the space between the lines, which catches deletes
[20:09] <abentley> rcohen: Yeah, I know.
[20:10] <abentley> But even if you're even if you're versioning the lines, suitable historical info will let you catch that case.  I'm pretty sure weave handled it, and I believe I can extend LCA to handle it, too.
[20:10] <rcohen> yes, weave should handle it
[20:11] <rcohen> if you are going to add annotation information to the pack format in the future, that may be worth keeping in mind
[20:12] <abentley> rcohen: Do you know offhand whether annotation of the lines can be cheaply transformed into annotation of the edges?
[20:12] <rcohen> i understand that there are practical tradeoffs to be made, you obviously don't want to show the between-line versioning to users when they use the "blame" command so it would be extra info
[20:12] <rcohen> i don't think so
[20:13] <rcohen> i haven't really looked into it, it may be possible to store a small set of differences and otherwise make it automatic
[20:15] <rcohen> abentley: if you have a fast way of determining whether i change came after another, then i think only the deletes would get lost
[20:16] <abentley> Pity deletes are the reason we're interested in edge annotation :-)
[20:16] <rcohen> yeah :) but storing the standard annotation plus a little extra deletion info might work
[20:18] <abentley> Anyhow, I'm interested in edge-base merging generally because I believe it can do moves within files, and between files.
[20:19] <rcohen> there be dragons
[20:19] <rcohen> i'm currently more interested in improving the UI for conflicts
[20:20] <rcohen> there are some conflicts which are difficult for users to resolve
[20:20] <rcohen> for instance, someone deletes a big section of code, someone else makes a 1 line change to it
[20:21] <fullermd> That one bits me with some regularity   :|
[20:21] <rcohen> the poor merging user is left to stare at these 2 huge blocks of code and figure out what's different and why
[20:21] <dacresni> how does git handle it?
[20:21] <dacresni> i mean, thats what comments are for
[20:21] <dacresni> to tell why
[20:21] <dacresni> in both revision comments and inline comments to the code
[20:22] <abentley> rcohen: Oh, I certainly have bigger fish to fry than that.
[20:22] <fullermd> Comments don't help when I'm staring at 1 line of code, and 80 lines of code, where I took that one line from the 70-some that were on the other side last time, and have no idea which were added.
[20:22] <rcohen> abentley: i've come to consider UI a big fish
[20:22] <abentley> That is, I don't plan on implementing edge merging soon.
[20:23] <abentley> I agree that UI is more important.
[20:23] <abentley> You get quickly diminishing returns with merge algorithms.
[20:23] <rcohen> now, if your merge algorithm has annotation information, it should be possible to call out the 1 line which caused the conflict for the user
[20:23] <dacresni> it sounds like you can't tell when either line was added or subtracted or which
[20:24] <rcohen> abentley: absolutely agreed on diminishing returns, fun as it is to work on merge algorithms
[20:25] <rcohen> i've got another crazy idea about doing per-conflict virtual common ancestors
[20:25] <rcohen> i came up with it in the context of weaves, but it may be possible to fit it into other merge algorithms
[20:34] <brink_> Is there a way that version-info could somehow be inserted into my code automatically?
[20:34] <brink_> A revision number would be fine.
[20:41] <cliechti> i have a low power/low resources hardware where a wiki like moinmoin uses too much memory. so i thought i could use a bazar repository there, with a working copy on the server. i'd then run docutils over that copy to generate my HTMLs. so, is there an easy way to run update and a script when i push my local repo to the server.
[20:42] <cliechti> i could write a plugin, but is there a hook that is executed on the server when i do a push?
[20:45] <dato> cliechti: maybe you'd like to take a look at http://ikiwiki.info, a static wiki "compiler". it's recently gained (or is about to gain) bzr support.
[20:49] <cliechti> dato: ok, that's the direction i'm thinking of, but it seems that ikiwiki is using perl, so it is the wrong language with P for me ;-) and i'm having my nice ascii art to svg plugin in docutils :-)
[20:50] <dato> cliechti: I'm completely a python person myself, but am quite happily using ikiwiki for my personal site. ymmv.
[21:45] <beuno> abentley, did you find out anything about that broken branch (FYI, it's not really mine, I was just helping out and got curious)
[21:46] <abentley> Kinda.  I'm on a call right now.
[21:46]  * synic perks
[21:49] <beuno> abentley, no hurries
[22:36] <igc> morning
[23:04] <Rolly> Hi all. I keep getting an AttributeError: 'module' object has no attribute 'ssl' error when I try to branch any https:// url. Here's the bzr output: http://p.caboo.se/private/x2dbvkbelnrngdsscb9s1w
[23:04] <Rolly> does anyone have a clue? I have googled to no avail
[23:05] <beuno> Rolly, seems you're missing a dependency
[23:05] <Rolly> you think it's a python problem, or a bzr problem?
[23:06] <Rolly> I am clueless when it comes to python, I'm afraid
[23:06] <beuno> Rolly, neither, you're probably missing some package
[23:06] <beuno> let me check
[23:06] <Rolly> thanks :)
[23:07] <mwh> looks like your python doesn't have ssl support
[23:07] <mwh> which is a little strange
[23:07] <mwh> Rolly: what os are you on?
[23:08] <Rolly> yeah, I just saw this: http://paltman.com/2007/11/15/getting-ssl-support-in-python-251/
[23:08] <Rolly> I'm on a debian etch box
[23:08] <Rolly> w/ python2.4 installed from apt
[23:08] <mwh> maybe you need to install python-ssl or something
[23:08] <beuno> yeap, svn2bzr doesn't seem to require any special dependencies
[23:09] <mwh> _however_
[23:09] <mwh> in this case just branch from http://bazaar.launchpad.net/~niemeyer/svn2bzr/trunk
[23:11] <Rolly> cheers, I didn't think of that
[23:12] <mwh> that's what the url you were trying to access would have redirected you to
[23:14] <Rolly> installing the ssl 1.13 python package didn't work
[23:14] <Rolly> I would try to install python 2.5 from source, and use that. But I'm afraid to bork anything on this box that depends on python 2.4 :p
[23:16] <mwh> there's not usually much reason to install things from source on debian...
[23:16] <mtaylor> Rolly: install python2.5 packages?
[23:17] <Rolly> mtaylor: I did, but the system python (`which python`) remains my old 2.4
[23:18] <Rolly> mwh: probably, but I'm mystified by the package system. For example, how would I go about reconfiguring my existing python 2.4 install? I have no idea
[23:22] <Rolly> mwh: actually, http://bazaar.launchpad.net/ redirects to https://bazaar.launchpad.net/
[23:22] <Rolly> :(
[23:39] <cliechti> mwhudson: do you have something to do with lag.net (loggerhead homepage)? the last two development link at the bottom of the page do not work properly
[23:39] <mwhudson> no
[23:47] <rolly> cool, I fixed my problem with just "apt-get --reinstall install python2.4"
[23:47] <rolly> :)
[23:52] <rolly> Hmm, there's a problem with svn2bzr. I have to comment out "import bz2", because that's part of Python now. But then bzr crashes with global name 'bz2' is not defined in lines like this: self._tree_cache[str(revno)] = bz2.compress(marshal.dumps(tree, 2)).
[23:53] <mtaylor> rolly: why do you need to comment out import bz2?
[23:54] <rolly> because if I don't, I get ImportError: No module named bz2
[23:54] <mtaylor> rolly: that's because you don't have it then...
[23:54] <rolly> I think I read somewhere that bz2 is part of python
[23:54] <mtaylor> it is
[23:54] <bob2> that would be because it is NOT part of python :)
[23:54] <mtaylor> but you still need to import it
[23:54] <mtaylor> to use it
[23:54] <rolly> Ah ok
[23:54] <mtaylor> mtaylor@solace:~$ python2.4
[23:54] <mtaylor> Python 2.4.4 (#2, Jan  3 2008, 14:46:35)
[23:54] <mtaylor> [GCC 4.2.3 20071223 (prerelease) (Ubuntu 4.2.2-4ubuntu3)] on linux2
[23:54] <mtaylor> Type "help", "copyright", "credits" or "license" for more information.
[23:54] <mtaylor> >>> import bz2
[23:54] <mtaylor> >>> bz2.__file__
[23:55] <mtaylor> '/usr/lib/python2.4/lib-dynload/bz2.so'
[23:55] <mtaylor> but that file is in the python2.4 package
[23:55] <mtaylor> what python is your bzr trying to use?
[23:55] <rolly> 2.4.1
[23:55] <mtaylor> head -1 `which bzr`
[23:56] <rolly> #!/usr/local/bin/python
[23:56] <mtaylor> ah. installing python from source are we?
[23:56] <rolly> that's 2.4.1
[23:57] <mtaylor> ok, so that python install doesn't seem to have bz2
[23:57] <mtaylor> is your bzr also in /usr/local/bin - like, you build/installed it from source?
[23:57] <rolly> hmm... that is obviously not the python I just reinstalled via APT. That was 2.4.4 I'm sure
[23:57] <mtaylor> right
[23:57] <rolly> I did build bzr from source
[23:57] <mtaylor> that would be in /usr/bin/python
[23:57] <mtaylor> ok.
[23:57] <mtaylor> so that means it's also in /usr/local/bin/bzr, right?
[23:57] <rolly> correct
[23:58] <mtaylor> any particular reason for installing from source? or that's just the way you did it?
[23:58] <mtaylor> rolly: you're running debian testing, right?
[23:58] <rolly> and also correct that /usr/bin/python can import bz2
[23:58] <rolly> :|
[23:59] <rolly> mtaylor: I don't think so. How do I check?
[23:59] <mtaylor> cat /etc/debian_version
[23:59] <rolly> 4.0
[23:59] <mtaylor> apt-cache show bzr | grep Version


[23:14] <zxmpi> it's may the 4th... live long and prosper dr. who fans :-P
[23:22] <daftykins> haha
[23:48] <davef> not yet it aint


[03:20] <sbeattie> erk, what's supposed to create the /dev/disk/by-uuid paths? I just tried a (minimal vm) server install with the current candidate and on reboot, got dropped to busybox; the only path under /dev/disk/ is by-path/
[03:21] <sbeattie> going in to rescue mode and selecting the ubuntu-server task didn't fix it, either.
[04:00] <sbeattie> hggdh: have you done a test install of the latest server isos yet?
[04:04] <hggdh> sbeattie: I did presseded installs of the 0426.1 ISOs
[04:07] <hggdh> six of them, to be exact
[04:07] <sbeattie> hggdh: and they all rebooted fine? I've got a virtualbox guest that's dropping me to busybox on reboot.
[04:08] <sbeattie> after installing the 0426 iso.
[04:09] <sbeattie> basically, none of the /dev/disk/by-uuid paths are getting set up in the initramfs.
[04:09] <hggdh> sbeattie: they did reboot fine, yes, no problems *there*
[04:10] <hggdh> what I had was -- sometimes -- the kvm modules would not be leaded
[04:10] <sbeattie> hggdh: were any of them side-by-side installs?
[04:11] <hggdh> no, they were all installs in the lab, the UEC test rig. I followed 4 of them via serial console, and there were no visible problems
[04:11] <hggdh> weird. If you are seeing that, I should also
[04:13] <hggdh> sbeattie: OTOH -- if you run gnome, and you are up-to-date, please check if gnome-keyring is listing your GPG keys. Mine is not, none of them
[04:14] <hggdh> and pretty much none of the ~400 public keys I have in the keyring
[04:14] <sbeattie> I don't make use of gnome-keyring, sorry.
[04:14] <hggdh> heh. *I* do not use it, bloody evolution does
[04:14]  * sbeattie uses mutt which uses gnupg directly.
[04:15] <hggdh> yeah, I know... shoulda
[04:15] <hggdh> anyway -- g'night, sbeattie
[04:16] <sbeattie> hggdh: thanks, g'night.
[06:40] <sbeattie> bah, worked it out; virtual kernels don't include the ahci driver, which is what virtualbox needs for its sata drives.
[06:57] <ara> good morning!
[07:05] <sbeattie> morning ara!
[07:05] <ara> hey sbeattie!
[07:06] <ara> Let's start the day with some alternate testing
[08:12] <ara> sbeattie, how long (~) does it take for you an alternate installation in virtualbox?
[08:13] <sbeattie> depends; my guess would be 30-45min typically.
[08:15] <ara> thanks
[08:31] <ara> mvo, morning
[08:31] <mvo> hey ara, good morning
[08:32] <ara> mvo, do you keep reading upgrade bugs from the launchpad team?
[08:33] <mvo> ara: I'm subscribed to the page, but haven't had updates recently
[08:33] <mvo> ara: maybe it got spammed :/ is there a lot of new stuff?
[08:33] <sbeattie> there hasn't been much activity there recently, right (I'm also subscribed)
[08:33] <sbeattie> ?
[08:33] <ara> mvo, I just had some updates to previous exisitng reports
[08:34] <ara> I am subscribed to anything behind it
[08:34] <mvo> could you /msg me the links please? I have  a look then
[08:51]  * ara goes for a coffee
[09:25] <slangasek> ok folks, y'all might want to take five on the ISO testing... we've got a plymouth bug that's being ruled critical enough to respin everything
[09:26] <slangasek> (bug #570289)
[09:26] <ubot4> Launchpad bug 570289 in plymouth (Ubuntu) "mountall assertion failure breaks boot process (affects: 1) (heat: 6)" [High,Incomplete] https://launchpad.net/bugs/570289
[09:26] <sbeattie> everything? bah.
[09:26] <slangasek> yes :/
[09:26] <slangasek> sorry - the plymouth change that caused the regression only landed on Sunday
[09:29] <ara> oops
[10:22] <slangasek> publisher is running for plymouth update; getting some regression testing here around the table at the release sprint, ISO spins should be able to start again in < 30min, so first (alternate) ISOs will be available in ~1h
[10:27] <ara> slangasek, thanks for the heads-up
[10:46] <ara> good morning davmor2
[10:46] <davmor2> morning ara
[10:47] <ara> davmor2, we are respining due to bug 570289
[10:47] <ubot4> Launchpad bug 570289 in plymouth (Ubuntu) "mountall assertion failure breaks boot process (affects: 1)" [High,Fix released] https://launchpad.net/bugs/570289
[10:48] <davmor2> ara: wounder I was gonna make a start on wubi :(
[10:48] <ara> davmor2, you will need to wait a bit, I am afraid
[10:49] <davmor2> I got 2 releases going to productions probably today too so I'll just do what I can as I can but I'll hit the wubis and migration-assistant
[10:54] <ara> davmor2, thanks
[10:55] <davmor2> ara, slangasek: I might not hit the starting button on the tests so just assume they have all been ticked ;)
[11:11] <slangasek> ubuntu alternate posted
[11:16]  * ara syncs
[11:23] <slangasek> kubuntu alternate posted
[11:23] <slangasek> next up are xubuntu alternate, ubuntu-netbook
[11:42] <slangasek> ubuntu-netbook, xubuntu up
[11:42]  * ara resyncs
[11:46]  * persia considers `while true; do ubucdimage; done`
[11:49] <ara> hehe
[11:50] <slangasek> kubuntu-netbook up
[11:51] <slangasek> next: ubuntustudio, ubuntu desktop
[11:51] <slangasek> correction - ubuntustudio posted
[12:24] <slangasek> ubuntu desktop up
[12:25] <slangasek> ubuntu-server up
[12:25] <xdatap> hello
[12:26] <xdatap> ara: ping
[12:26] <ara> xdatap, hey, how is it going?
[12:26] <xdatap> ara: fine :)
[12:27] <xdatap> ara: just a clarification, it's my first release as a tester...
[12:27] <xdatap> ara: i'm receiving notification mail from tracker but then they are in rebuilding
[12:27] <ara> xdatap, like what?
[12:28] <ara> xdatap, there are some that were already posted, but others still rebuilding
[12:28] <ara> xdatap, can you give an example?
[12:28] <xdatap> ara: let me see...
[12:29] <xdatap> ara: i received mail for 20100426.2
[12:29] <davmor2> xdatap: that is because the tracker will issue a mail everytime there is an iso spun.  However if a fault is found it will be respun to fix the issue
[12:29] <ara> xdatap, yes, because a bug was found and there was a respin
[12:30] <ara> that's why
[12:30] <xdatap> but my question is, there will be another iso test before the release?
[12:30] <ara> you get the notifications, but you have to check in the tracker if it is going to be respin again
[12:30] <ara> xdatap, yes, we need to test the final isos
[12:30] <ara> so, everytime a respin is made, we need to resync our images, and test again
[12:31] <ara> xdatap, it is important to always resync the images
[12:31] <xdatap> ara: basically before to start a test during these hours we need to ask here before to start
[12:32] <xdatap> or we're expecting 20100427.1 to be tested?
[12:32] <xdatap> ...to be the final image to be tested
[12:32] <davmor2> xdatap: no you can just look at the tracker.  If it says respining just wait a bit.  But hopefully these will be the last ones
[12:33] <xdatap> i never seen "respining" in the iso track, where is this indication
[12:34] <davmor2> xdatap: basically if it has a line through it on iso.qa.ubuntu.com it means it is being respun
[12:35] <xdatap> ok! understood. Thanks everybody
[12:35] <ara> xdatap, many of them have been already posted in the tracker
[12:36] <xdatap> ara: no, I haven't understood. them who?
[12:36] <ara> xdatap, the new builds that need testing
[12:37] <ara> xdatap, if you check the tracker now, you will see that there are a lot there already, to begin with
[12:37] <xdatap> ara: perfect, thanks! :)
[12:38] <ara> xdatap, any time
[12:53] <slangasek> kubuntu desktop up
[13:13] <ara> I am going to switch to virtualbox when the two test that I am running finish, KVM is slow slow for me. I will ask kirkland why during UDS
[13:46] <davmor2> ara: present him with your laptop and don't let him leave till it flies ;)
[13:46] <davmor2> morning fader_
[13:46] <fader_> davmor2: Hey dude
[13:46] <davmor2> fader_: hows life?
[13:47] <fader_> davmor2: Can't complain, but I still do... you?
[13:48] <davmor2> fader_: about the same to be honest :D
[13:49] <slangasek> ara: can you have a look at the error on http://iso.qa.ubuntu.com/qatracker/test/4132 ?
[13:49] <slangasek> other pages load fine, but this one breaks reliably
[13:49] <slangasek> spot-checking, I only find this one page that's broken
[13:51] <ara> slangasek, which one is that?
[13:51] <slangasek> ara: Ubuntu desktop i386
[13:52] <ara> slangasek, F5? I can't reproduce
[13:52] <slangasek> ara: ah - shift-reload cleared it
[13:53] <slangasek> ara: I guess it was a cached bad page here in the office
[13:53] <slangasek> thanks for sanity-checking :)
[13:55] <persia> slangasek: When you find some spare time, could you generate some powerpc images as well?  (that said, I don't really have means to test, but I'll try to get some folks to look at them)
[13:55] <davmor2> morning cr3
[13:55]  * ara -> lunch
[13:57] <slangasek> persia: yes, will do later today after all the critical-path stuff is out of the way
[13:57] <slangasek> persia: not much urgency, since no arch-specific problems that turn up there are going to result in new uploads...
[13:57] <persia> No huge rush: just noticed it was the lagging arch of the four I mirror (for a subset of flavours)
[13:57] <persia> heh.  That sounds more like a declaration than a prediction :)
[13:59] <slangasek> yes, it is
[13:59] <slangasek> :)
[14:00] <slangasek> we're not going to derail the release process for arch-specific bugs that should've been found and fixed in RC
[14:01] <slangasek> mythbuntu up shortly
[14:01] <persia> Makes sense.  The three that affect me have already been determined to be SRUs.  I know at least some other folks are happy with the RCs.  The finals just need a sanity check (and unfortunately I failed to allow virtual testing from within Ubuntu for this cycle)
[14:07] <slangasek> mythbuntu posted
[14:12] <fader_> w00t, an excuse to watch Dr. Horrible again!
[14:12] <fader_> Er, I mean, an important image to test.
[15:23] <mdeslaur> hmmm...anyone else notice that netbook-launcher is using the short name for icons in the Favorites section?
[15:41] <ara> mdeslaur, I haven't tried netbook edition
[15:51] <jdstrand> ara: fyi, I started experimenting with using fully allocated, raw images with qemu-kvm using 'cache=writethrough'. for running one iso test at a time, it seems to make a difference
[15:51] <ara> jdstrand, thanks! I'll try that :)
[15:52] <jdstrand> :)
[15:54] <bladernr> Hey...  what do I file a bug under when the installer does not set up Windows during a dual-boot install?
[15:56] <bladernr> Grrr...  and what do I file bugs for migration-assistant under? sigh...
[15:57] <sbeattie> bladernr: ummm, for the latter, https://bugs.launchpad.net/ubuntu/+source/migration-assistant is insufficient?
[15:58] <persia> bladernr: Unless you know better, filing bugs against "ubiquity" or "debian-installer" is probably the best place to start for *all* installer bugs.
[15:58] <bladernr> hrmmm...
[15:58] <persia> use "ubiquity" if it's a liveCD, and "debian-installer" if it's not.
[15:59] <bladernr> ok... it's just me... was not including /ubuntu/+source in the URL... works now.  Head > Desk
[15:59] <persia> sbeattie: The issue with only filing aginst migration-assistant is that it may also affect other bits of the complete install, or need other bits tweaked to fix the issue (although the installer team may reassign, or if one is *sure* of the component, one may do differently)
[16:01] <sbeattie> persia: yep, you are correct. The installer team are quite good about directing bugs from ubiquity and d-i to the right component after they've tracked down what's going on.
[16:01] <persia> I've always been impressed with their handling, indeed.
[16:02] <ara> bladernr, but don't don't comment your symptoms on an already filed bug, create a new one.
[16:03] <bladernr> ara: ack. wouldn't dream of it ;-)
[16:05] <davmor2> bladernr: what is the m-a issue
[16:06] <bladernr> davmor2:  A: items in the "Shared Documents" folder are not migrated on Windows systems with multiple users
[16:07] <bladernr> B: when I have multiple users, they are all migrated to a single account on the Ubuntu install.  I had expected to see two users, not one user with everyone's data
[16:08] <davmor2> bladernr: I don't think shared is in the migration path to be honest I'll check
[16:08] <bladernr> probably not, it wasn't listed in the m-a page in Ubiquity, and that's a bit surprising...
[16:09] <bladernr> B is a much larger issue, IMHO.  a security one to some degree...
[16:09] <davmor2> I think is might be because it is then a samba share so should be easily accessible maybe don't know just guessing
[16:10] <bladernr> If I have two users, each with their own data, that data get's merged into one user in Ubuntu, who has ownership of all data...
[16:10] <davmor2> NIce that is a definate bug
[16:12] <slangasek> security> nack, the user doing the migration is already a local admin by definition
[16:12] <slangasek> it may not be desirable, but it's not a security bug
[16:13] <bladernr> slangasek:  mmmkay... you are correct.  definitely NOT desirable.
[16:13] <bladernr> but I see your point too.
[16:13] <bladernr> I'll not set it as a security issue
[16:17] <davmor2> bladernr: have a word with ev about it on u-installer
[16:26] <slangasek> there will be a slight delay in posting the Ubuntu and Kubuntu DVD images, we're slotting in a valgrind no-change rebuild to get it up-to-date on armel
[16:27] <slangasek> (they wouldn't have been done for another 2h at least, regardless)
[16:30] <bladernr> davmor2:  ^^^ thanks.  I filed a bug about the mixing of the users hoping that that behaviour will be revisited in the next cycle.
[16:43] <bladernr> I did have to fail the auto-resize test case, by the way.  Bug #570765
[16:43] <ubot4> Launchpad bug 570765 in ubiquity (Ubuntu) "[Lucid] Installer fails to configure grub for dual boot (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/570765
[16:44] <bladernr> and apparently, someone else tested after me and noted the same behaviour against a second Lucid install
[16:45] <davmor2> bladernr: check that u-installer are aware of that it might cause a respin + they might ask you for missing info etc
[16:46] <bladernr> davmor2:  will do
[16:54] <slangasek> bladernr, davmor2: escalated to the installerers
[16:54] <bladernr> slangasek:  ack... I just added logs that were requested too
[17:18] <bladernr> Has anyone had success in installing via Wubi in a virtualbox VM?
[17:19] <sbeattie> bladernr: I can try, give me a bit to set things up.
[17:21] <bladernr> sbeattie:  ok... thanks.  I'm running a 64bit VM with 64bit XP.  Wubi ran inside XP just find, but it's the reboot that I'm having trouble with.  The VM hangs regardless of what boot options I try (even combinations of disabling acpi and apic fail)
[17:28] <sbeattie> bladernr: okay; all I have is win2k/32 but I'll try a xubuntu/64bit wubi install.
[17:43] <bladernr> sbeattie:  thanks... heck even if you do a 32bit wubi install it's a data point.
[17:43] <sbeattie> bladernr: bah, the wubi installer just hung. :-(
[17:44] <bladernr> after rebooting, or during the "Inside Windows" portion?
[17:44] <bladernr> IOW, did it hang after the first reboot when you choose Ubuntu from the Win boot manager to continue the installation
[17:46] <sbeattie> during the inside windows portion.
[17:46] <sbeattie> making sure it's not an infrastructure issue on my part.
[17:50] <bladernr> ahhh.. ok.  that part went fine for me :(
[17:50] <bladernr> ok.. off to eat
[18:20] <sbeattie> bladernr: bah, keeps hanging for me.
[18:23] <bladernr> sbeattie:  ok... thanks
[19:09]  * stgraber starts working on both edubuntu
[19:10] <stgraber> slangasek: any reason edubuntu isn't on the tracker
[19:27] <sbeattie> bladernr: still around? 64bit xubuntu is failing here after rebooting to finish the install as well.
[19:28] <bladernr> sbeattie:  rhmmm... thanks.  I'm wondering if this is a problem with VMs only... in Beta 2 davmor2 was successful on bare metal
[19:28] <bladernr> sbeattie:  I'd filed a bug in that timeframe
[19:29] <sbeattie> bladernr: virtualbox up and aborts for you?
[19:30] <sbeattie> Nice, the last line in the vbox log for that guest: 00:00:20.999 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'.
[19:30] <bladernr> depends... if I muck with acpi settings or set nousb (in my case, it alway seems to hang when looking at USB devices) then yeah... otherwise, just a quiet hang with no error from VBox.
[19:30] <bladernr> BUT, I get the same GURU_MEDITATION message in the VM logs too
[19:31] <sbeattie> bladernr: ah, I'm using virtualbox-ose from the archive, so no USB for me.
[19:32] <bladernr> ??  no, I meant if I set nousb on the boot line for Ubuntu when I boot the VM (and pick Ubuntu from the Win bootloader)
[19:32] <bladernr> e.g. telling the kernel to not configure any USB controllers
[19:33] <sbeattie> ah, I see.
[19:35] <sbeattie> It's always failing (with verbose enabled) at the point right after it tells me it write-protected kernel read-only memory and then "Loading, Please Wait", and ker-boom!
[19:36] <bladernr> ahhh.. ok.  ker-boom?  does yours just hang, or do you get a stack trace?
[19:36] <sbeattie> bladernr: what bug number?
[19:37] <sbeattie> bladernr: ker-boom means virtualbox pops up a dialog that the guest has aborted.
[19:37] <bladernr> sbeattie:  bug 557448
[19:37] <ubot4> Launchpad bug 557448 in wubi "[Lucid Beta2] Wubi hangs on first reboot after installing inside windows on amd64 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/557448
[19:38] <bladernr> sbeattie:  ack... I get that about 70% of the time ;-)  YAY!
[19:38] <sbeattie> oh, I get that 100% of the time; don't get anything else.
[20:17] <stgraber> edubuntu dvd amd64 done, doing i386 now (Installed amd64 in simplified chinese and doing i386 in greek for some i18n testing)
[20:44] <slangasek> stgraber: hrm, no reason - did you post it then, I guess?
[20:55] <stgraber> slangasek: yep
[21:29] <MTecknology> I screwed up a little. I used a tool for editing run levels but it turns out that's not how upstart works. How can I make sure any scripts I have are upstart jobs instead of rc jobs?
[21:33] <charlie-tca> Wouldn't you be able to check in /etc/init.d for them? upstart scripts are usually in /etc/init instead now
[21:43] <MTecknology> charlie-tca: thanks, I didn't know where upstart jobs were heald
[21:43] <MTecknology> held*
[21:45] <charlie-tca> Well, to the best of my knowledge, they start there anyway
[21:48] <sbeattie> yes, upstart jobs are held there, unless you move them elsewhere to disable them (I have /etc/init.disabled/ on my more permanent hosts)
[21:48] <MTecknology> sbeattie: nifty idea :)
[21:49] <MTecknology> So.... if I want to completely drop sysv then I need to convert everything to an upstart job
[21:50] <MTecknology> That means 1) identify what sysv scripts I still depend on - which I can figure out with that .disabled directory idea; then 2) convert then 3) push upstream
[21:50] <MTecknology> probably in a debdiff at first with a bug report on launchpad?
[21:53] <sbeattie> MTecknology: erm, I use /etc/init.disabled for upstart jobs that I want to disable, as upstart doesn't provide any management tools for such things.
[21:53] <MTecknology> sbeattie: oh :P - I'm trying to use upstart for everything
[21:54] <MTecknology> I'm gonna run off and tackle this when I get homework done tonight..
[21:54] <sbeattie> But yes, you'd want to see what you have in /etc/init.d that's still a script; IIRC, placeholder symlinks are (typically?) put in place for sysv scripts that have already been converted to upstart.
[21:56] <sbeattie> well, you'd want to make sure it was enabled as well; /me spies an /etc/init.d/sysklogd that'sno longer relevant.
[21:57] <MTecknology> sbeattie: I don't see that at all
[21:57] <MTecknology> the sysklogd i mean
[21:58] <sbeattie> MTecknology: deritrus left behind from jaunty->karmic's conversion from sysklogd to rsyslogd; I meant on my laptop.
[21:58] <MTecknology> anyway - I'm going to run off and see my gf - I'll start converting tonnight
[21:58] <MTecknology> oh
[21:58] <sbeattie> MTecknology: have fun!
[21:58] <MTecknology> sbeattie: thanks for the info
[22:05] <MTecknology> sbeattie: I guess she's not back yet... I'll start now - I removed any symlinks in init.d; boots find - I have something at least :)
[22:13] <MTecknology> sbeattie: the more I'm reading, the harder it's seaming to actually convert them
[22:16] <sbeattie> it's... non-trivial.
[22:16] <sbeattie> or can be, depending on the initscript.
[22:17] <MTecknology> sbeattie: I was lookin at wicd and wdm
[22:21] <MTecknology> sbeattie: I guess this is why it has been a long migration
[23:03] <charlie-tca> humm, problem with the xubuntu desktop image. 'use the entire disk' partitioning results in all other grub entries not seen except that installation. It doesn't matter how many other installs are present
[23:04] <charlie-tca> Reinstalling with any other partition method allows you to see the other installations again
[23:05] <charlie-tca> I think this is critical, since it makes it appear that existing partitions with anything on them disappeared during the install
[23:05] <sbeattie> charlie-tca: I'm assuming the others are on another disk?
[23:06] <charlie-tca> negative. It doesn't matter if they are on the same disk or other disk
[23:06] <charlie-tca> Tried this twice.
[23:06] <charlie-tca> oops. I guess they are on the other disk. It is a entire disk partition
[23:06] <charlie-tca> heh
[23:07] <charlie-tca> Got a bug already?
[23:07] <sbeattie> nope
[23:09] <charlie-tca> Both drives/systems had multiple partitions in the drive used
[23:10] <charlie-tca> even better, ubuntu-bug fails too
[23:14] <sbeattie> charlie-tca: how so?
[23:14] <charlie-tca> errors as soon as I click on 'send report'
[23:15] <charlie-tca> AssertionError
[23:17]  * sbeattie starts up a xubuntu manual disk install to see if he can reproduce the ubuntu-bug error.
[23:18] <charlie-tca> not manual install; 'use entire disk' is the only partitioning that fails
[23:20] <sbeattie> charlie-tca: I got that; ubuntu-bug failing to submit bug reports is what I was trying to reproduce.
[23:21] <charlie-tca> oh
[23:21] <charlie-tca> heh
[23:21] <sbeattie> What's the assertion you see? I can't reproduce in the live environment.
[23:21] <charlie-tca> Yeah, I should report that too
[23:22] <charlie-tca> File "/usr/lib/python2.6/dist-packages/apport/REThread.py", line 46, in return_value
[23:22] <charlie-tca> assert not self._exception


[00:04] <zacarias> Hi. Is there any ready-to-install version (like a live cd or dvd) of Ubuntustudio with another DE? Like Gnome-Shell or elementary, or KDE, or...
[00:04] <zacarias> I mean Ubuntustudio 14.04
[00:09] <zacarias> Is there any ready-to-install version (like a live cd or dvd) of Ubuntustudio 14.04with another DE? Like Gnome-Shell or elementary, or KDE, or..
[00:40] <OvenWerks> zacarias: No, nothing live at this time. It is certainly possible to install the ubuntustudio metas on top of these other DEs though. This machine has sStudio installed on top of Kubuntu for example
[00:42] <OvenWerks> zacarias: The first thing is to make sure you have the DE of choice working as you like. Install the metas you want (ubuntustudio-installer can help)
[00:44] <OvenWerks> There are two more steps, Make sure the user is in the audio group and make sure that /etc/security/limits.d/audio.conf does not have a .disabled on the end of it.
[00:46] <OvenWerks> This will not change your desktop backgrounds or anything like that, just add the Studio applications for whichever workflow you install.
[01:16] <ZeroDivided> Hi, I was told to come here for Wacom tablet support in 14.04
[01:17] <ZeroDivided> Does anyone here know how to get it working in Gimp?
[01:18] <ZeroDivided> Followed these instructions, but its not working: http://meandthecomputer.blogspot.com/2010/12/gimp-how-to-enable-wacom-pen-tablet.html
[01:25] <holstein> zequence: sure
[06:52] <venkat> hi
[12:40] <ChaosColor> hi there
[12:41] <ChaosColor> I'm thinking about using ubuntu studio for video editing
[12:42] <ChaosColor> the computer that holds all the video data is ony running winows for now and I'd prefer to not dual boot it
[12:46] <ChaosColor> so I was wondering whether there were some instructions on how to persist configuration settings on usb live media
[12:46] <ChaosColor> or possibly ways of installing it to a usb disk
[12:47] <ChaosColor> the latter would probably make it easier to customize the install and add software
[12:56] <ObrienDave> unetbootin has a very easy persistence slider in the installer window. i would suggest a 16 to 32GB USB stick for Studio install
[12:58] <ObrienDave> if you're going to install all of studio. you might be able to use an 8GB if you're only going to install the video portion
[12:59] <ObrienDave> 16GB would be better
[21:07] <delt> Hello
[21:07] <delt> is it possible to use chrome's adobe flash plugin with firefox?
[21:09] <delt> currently, firefox's about:plugins shows me that vlc is handling .swf objects
[21:23] <delt> how do i choose which swf plugin to use in firefox?


[15:03] <frafu> Hi,
[15:03] <frafu> I am writing the documentation of the onscreen keyboard Onboard in mallard format (Onboard is the default onscreen keyboard in Ubuntu). The intention was to ship it with the Onboard source in the help/C subfolder, but I am unsure whether this is the best way to go, especially regarding the translation of the documentation. Could anybody please tell me what is the best way to proceed with the documentation?


[07:47] <hyperair> meh. i can't change the acceleration of my mouse. why's that?
[11:06] <petski> hey guys, yesterday I've upgraded to Karmic Beta, which resulted in a really slow desktop. Xorg takes 100 CPU, so my system is hardly usable. It seems like the issue is related to LP 399782, but not much information there. what can I do to help debugging the cause?
[11:17] <petski_> Hmm, it doesn't like me doing a strace on the xorg pid :) ..
[16:51] <Rocket2DMn> hey guys, I'm looking at bug 421221
[16:52] <Rocket2DMn> the naming in Karmic currentely is "gedit Text Editor" in the menu entry, which affects ubuntu-docs
[16:52] <Rocket2DMn> It sounds like there is still discussion upstream - are we sticking with the current name in Karmic, or do you think it will be adjusted again?
[18:04] <hyperair> is nautilus supposed to show my LVM physical volume even when all its logical volumes are mounted?
[18:04] <hyperair> seems rather annoying to me
[20:39] <chrisccoulson> hyperair - that seems to happen not just for LVM volumes
[20:39] <chrisccoulson> if i mount all mounts on a particular drive, then i end up with a useless icon for the physical drive, which does nothing
[20:40] <hyperair> oh is that so?
[20:40] <hyperair> hmm i don't get that
[20:40] <hyperair> my /dev/sda has a /dev/sda1->/boot and /dev/sda2->cryptsetup->LVM->mounted stuff
[20:40] <hyperair> but i don't get a useless /dev/sda icon
[20:42] <chrisccoulson> ah
[20:42] <chrisccoulson> it might be because my "physical drive" is part of a raid array
[20:42] <chrisccoulson> i forgot that bit ;)
[20:42] <chrisccoulson> but its basically the same issue as you
[20:47] <hyperair> hahah i see
[20:47] <hyperair> basically gdu's missing out some cases..
[20:47] <hyperair> i didn't notice this issue before though
[20:48] <hyperair> maybe it's because my previous /dev/sda2 was detected as both ext3 and luks
[20:48] <hyperair> god knows how that happened =.=
[20:49] <hyperair> i mean, fine, it was formatted as ext3 prior to me luksFormatting it
[21:23] <chrisccoulson> hyperair - in my case, dk-disks exposes one of the raw disks which make up my array
[22:53] <chrisccoulson> mclasen - have you seen this issue before (with gtk 2.18.1): bug 441905 ?
[22:54] <chrisccoulson> basically, it's no longer possible to click a button twice, without first moving the mouse cursor
[23:05] <mclasen> yes, I've seen that
[23:07] <chrisccoulson> mclasen - thanks. do you know which commit broke it (just in case i don't need to spend time bisecting it)?
[23:17] <mclasen> no, I don't. did this break between 2.18.0 and 2.18.1 ?
[23:17] <chrisccoulson> mclasen - i'm pretty sure it did. i only noticed the issue for the last couple of days, and we updated to 2.18.1 on 2/10
[23:18] <mclasen> bisecting it would be greatly appreciated
[23:18] <chrisccoulson> ok, no problem. i'll see how far i can tonight
[23:19] <chrisccoulson> s/can/can get
[23:19] <mclasen> thanks


[07:55] <lool> Daviey: Hey, what went wront with the netboot installer images?
[07:55] <lool> Daviey: Oh in qemu
[07:55] <lool> Daviey: qemu doesn't support dove nor imx51
[07:56] <lool> Daviey: We stopped doing versatile because we moved karmic to armv6 and versatile in the upstream kernel implies armv5 -- note that it can perfectly work with v6 or v7 though
[08:13] <Daviey> lool: So does that mean that it's currently note possible to virtualise arm in karmic?
[08:17] <lool> Daviey: It means that there's no prebuilt kernel to run in our qemu indeed
[08:20] <lool> Daviey: While it's an useful thing and we have a lot of people running qemu which hang around here, it's not a requirement; you could ask for such a flavour to the kernel team, I personally think it would be useful
[08:20] <lool> I didnt because I've felt I needed them to focus on the flavours supporting our hardware first
[09:20] <ogra_> Daviey, http://people.canonical.com/~ogra/arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8 might be of some help
[09:20] <ogra_> note it's quite old, but enough to get a VM up
[09:21] <ogra_> (the rootstock builder from /topic uses it to create rootfs'es and qemu images for arm)
[09:26] <Daviey> ogra_: thanks.. i'll give it a go.
[09:26] <ogra_> note there are no modules for it or anything ...
[09:26] <Daviey> ogra_: incidently, the upgrade path cannot be canculated from jaunty to karmic. :(
[09:27]  * ogra_ has no time/resources to build and patch a fresh one
[09:27] <Daviey> :(
[09:27] <ogra_> in a jaunty qemu vm you mean ?
[09:27] <Daviey> yah
[09:28] <ogra_> thats intentional, though i thought i added a proper error message
[09:28] <ogra_> do a cat /proc/cpuinfo in your vm
[09:28] <ogra_> karmic only supports v6 and v7
[09:29] <Daviey> ogra_: do-release-upgrade craps out as it tries to remove ubuntu-minimal, but that is blacklisted and marked for non-removal
[09:29] <ogra_> u-m should pop up an error message telling you that pre-v6 isnt supported
[09:30] <ogra_> oh, not sure do-release-upgrade shows the same errors u-m does
[09:30] <Daviey> ogra_: just booting now.
[09:32] <Daviey> lool: Sorry for not replying, missed your response.  I understand :)
[09:33] <Daviey> ogra_: Processor: ARM926EJ-S rev 5 (v5l) :(
[09:33] <ogra_> right
[09:33] <ogra_> my kernel fixes that
[09:33] <ogra_> it has a patch lool developed to fake a cortex-a8
[09:35] <Daviey> hmm, made qemu core dump :(
[09:37] <ogra_> you indeed need the right -M
[09:39] <ogra_> err
[09:39] <ogra_> -cpu, not -M
[09:39] <ogra_> -cpu cortex-a8
[09:39] <ogra_> and -M versatilepb
[09:40] <Daviey> yah, ogra_ you rock. :)
[09:40] <ogra_> :)
[10:03] <erikcorry> I finally got around to filing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41354
[10:03] <ubot4> gcc.gnu.org bug 41354 in c++ "g++: Inlining constructors puts wrong vtable in objects" [Normal,Unconfirmed]
[10:03] <erikcorry> clever bot
[11:58] <rabeeh> j #openplug
[13:13] <mike^> ogra, thanks to you I have omap3evm with ubuntu :)
[13:13] <ogra> :)
[13:14] <mike^> it's somewhat slow on app startup, but even 3D works :)
[13:14] <mike^> http://2.bp.blogspot.com/_dhW-lh4q-sk/Sqli478fQGI/AAAAAAAAAYo/zHk7-iRgQ1k/s1600-h/ubuntu-greeter3-small.png
[13:14] <mike^> http://4.bp.blogspot.com/_dhW-lh4q-sk/SqlivloG3fI/AAAAAAAAAYg/3-K5pHMwEa8/s1600-h/xfce2.png
[13:16] <mike^> ogra, do you know by chance is anybody working on the DSP stuff for OMAP?
[13:16] <ogra> nobody from canonical at least
[13:17] <ogra> not sure if there are any community people
[13:17] <siji> hey mike^, still am struggling with the same issue
[13:18] <siji>  checking GLES/egl.h usability... no
[13:18] <siji>  checking GLES/egl.h presence... no
[13:18] <siji>  checking for GLES/egl.h... no
[13:18] <siji>  configure: error: Unable to locate required GLES headers
[13:25] <lool> ogra: I was thinking of something: libc-vfp was dropped but wont be removed on upgrades which mean people might run an out of date libc
[13:25] <lool> ogra: Would you be interested in an update-manager snippet to drop it on upgade?
[13:25] <ogra> another u-m hack ?
[13:25] <lool> *upgrade
[13:25] <lool> Yeah that's what I had in mind
[13:25] <lool> Would check with mvo what he things though
[13:25] <ogra> sure, why not
[13:25] <lool> ogra: I'll file that now while I think of it and assign it to you then; thanks
[13:27] <ogra> gar
[13:27]  * ogra messed up his bug
[13:28] <lool> ogra: Actually thinking about it it's more of an eglibc bug, it should conflict/replace
[13:29] <ogra> yup
[13:30] <lool> ogra: there's an = dep on libc6 which is why it gets removed on upgrades
[13:30] <lool> I guess that's ok
[13:32] <ogra> god, pushing an ubiquity branch takes a century
[13:33] <lool> Yeah would need an upgrade
[13:34] <ogra> i thought its under ubuntu-core-dev but it isnt ... so i need to create a brandnew branch for merging
[13:34] <ogra> OO.o looks better this time ... didnt fail yet
[13:34] <lool> Well LP uses stacking for modern .bzr branches
[13:34] <ogra> ah
[13:34] <ogra> doesnt help me right now though :)
[13:34] <ogra> but my initramfs-tools install prob is solved
[13:35] <lool> Cool
[13:35] <lool> the unr and umr livefs breakages are awful just before A6
[13:40] <mike^> siji, native as well?
[13:40] <mike^> siji, I haven't tried to cross-compile... and apparently won't for some time
[13:40] <ogra> lool, well, i didnt have armel livefses since a few days either
[13:44] <lool> ogra: Do they build now?
[13:44] <lool> ogra: I gave back eds over the WE as I saw it was blocking but didn't look since
[13:45] <ogra> e-indicator and e-couchdb were ftbfs as well
[13:45] <ogra> but they should be fine now
[13:45] <ogra> i'll trigger a testbuild for dove and imx51
[13:57] <ogra> lool, do you know if the dove installer bits are ready so far ?
[13:57]  * ogra thinks there is still something missing, but not sure
[14:13] <tasslehoff> I'm trying to get my beagleboard to send 1680x1050 to my display (default it is 640x480). I followed the "Xorg omapfb Drivers"-section on http://elinux.org/BeagleBoardUbuntu, but afterwards X wouldn't start.
,bad luck
[14:15] <siji> :(
[14:16] <siji> have u updated the kernel
[14:16] <siji> ?
[14:18] <tasslehoff> siji: no, I have just created my own rootFS following the wiki, and started working/installing on top of that
, you have to add some patches in the kernel
[14:20] <lool> ogra: NCommander said the boot.scr doesn't get generated; probaby a simple bug
[14:20] <siji> for getting SGX Video Acceleration
[14:21] <ogra> lool, but flash-kernel and friends are ready ?
[14:22] <lool> ogra: Well it's a bug in flash-kernel-installer.postinst
[14:22] <ogra> yeah
[14:23] <ogra> i meant the rest of the changes there
[14:23] <ogra> ubiquity surely needs changes too for the bootloader parts
[14:23] <ogra> i didnt see him touching anything there yte
[14:23] <ogra> *yet
[14:23] <tasslehoff> siji: ok, I'll try to follow the wiki all the way to the bottom before asking any more :)
[14:24] <siji> yes
[14:24] <siji> it's there in the wiki
[15:06] <erikcorry> Does -mcpu=vfp get me a binary that uses floating point instructions?
[15:19] <tasslehoff> On my Beagle Board Xubuntu install update-apt-xapian-index is using almost all the cpu, and all I have set running myself is an xterm..
[15:21] <lool> erikcorry: That sounds wrong; you want fpu
[15:22] <lool> erikcorry: if you're using karmic, armv6 + vfp (v2) is the default
[15:22] <lool> So no need for any flag
[15:22] <lool> If using jaunty you want --with-float=softfp --with-fpu=vfp
[15:22] <lool> Sorry these are gcc build flags
[15:23] <lool> You want -mfloat-abi=softfp and -mfpu=vfp
[15:28] <erikcorry> Isn't the float ABI softfp by default?
[15:28] <erikcorry> Or does the mfpu option change that?
[15:30] <tasslehoff> Is the OMAP35x SDK needed to get SGX Video Acceleration on the Beagleboard?
[15:34] <lool> erikcorry: Our jaunty ABI is soft
[15:35] <lool> not softfp
[15:42] <erikcorry> What I want is a program that uses fp hardware, but is ABI compatible with the Karmic ABI.
[15:42] <erikcorry> So I think -mfpu=vfp is about right.  No change to the ABI, but use vfp inside functions.
[15:42] <erikcorry> Unless I am misunderstanding something.
[15:45] <lool> erikcorry: what's your dist?
[15:45] <lool> jaunty or karmic?
[15:45] <erikcorry> Karmic
[15:45] <lool> erikcorry: So you dont need -mfpu=vfp
[15:45] <lool> it's the default
[15:45] <erikcorry> So Karmic doesn't work on a machine with no vfp?
[15:45] <lool> No
[15:45] <erikcorry> Ah!
[15:46] <erikcorry> Good to know!
[15:46] <lool> And for jaunty you do need both
[15:46] <lool> Because one tells gcc that it may use vfp instructions in binaries but not in the ABI and actually should and the other tells which fpu instructions to use
[15:46] <erikcorry> Do Jaunty binaries run on a Karmic machine?
[15:46] <lool> Yes
[15:47] <erikcorry> Thanks
[15:49] <erikcorry> And Karmic also requires ARMv6?
[15:50] <ogra> yes
[15:52] <Daviey> Would someone be really kind, and test some packages cleanly install on armel for me?  It's a dkms package, and i want to test it also works of armel before getting it uploaded?
[15:52] <Daviey> s/of/on
[15:53] <ogra> all macines i could test on are busy for the next few hours
[15:53]  * Daviey has an n810.. but possibly not the best native arm device to test on :)
[15:53] <Daviey> ogra: oh okay, thanks.
[15:53] <ogra> especially for dkms stuff :)
[15:54] <Daviey> i've now got a qemu machine, that is almost on karmic.. but i'm not sure it's a fair test, considering how the kernel lives outside.
[15:56] <Daviey> i'm wondering if my toaster would run faster than qemu. :)
[15:57] <ogra> likely