[00:00] <jdong> can someone tell me what bzr-rebase does exactly, or smack me and tell me to just get the plugin and play with it?
[00:00] <jdong> it sound intriguing but I guess I don't completely understand what it's doing from the wiki's description
[00:00] <lifeless> its a tool for discarding history
[00:00] <lifeless> and making it hard to merge with people
[00:01] <jdong> ok tell me about why not to use it after telling me what it does :)
[00:01] <beuno> or making it linear, not having nested commits
[00:01] <lifeless> but can be used to make the 'revision graph' look 'clean', and some projects consider this more important than good merging and collaboration.
[00:01] <lifeless> jdong: what it does is transcribe the content of commits to a new revision graph
[00:01] <lifeless> beuno: you don't need rebase to do that
[00:01] <jdong> lifeless: so it essentially extracts the patch associated with each commit in a child branch and linearly commits it to the parent branch?
[00:02] <beuno> lifeless, you don
[00:02] <beuno> er,  you don't?
[00:02] <lifeless> beuno: merge; bzr revert --forget-merges; bzr commit
[00:02] <lifeless> jdong: no, bzr is not patch based.
[00:02] <beuno> lifeless, ah, right, but that's on a per-commit basis
[00:03] <beuno> though it's interesting to know, I've needed that a few times
[00:03] <jdong> lifeless: the operation that it rebase does is similar to a merge in end result, but not in history, correct?
[00:03] <lifeless> beuno: concurrency is endemic to collaboration; trying to hide it is a lie.
[00:03] <jdong> wow I can't type coherently today
[00:04] <lifeless> jdong: no, because it _discards history_
[00:04] <jdong> lifeless: in what way?
[00:04] <jdong> (ok I think I should just play with bzr-rebase to find out for myself)
[00:04] <lifeless> jdong: anyone following the branch that has been rebased can no longer follow it; they have to start over
[00:04] <jdong> lifeless: oh.... ouch.
[00:04] <lifeless> jdong: the revision graph is what gives you the ability to do merges at all
[00:04] <beuno> lifeless, assuming that you always have non-conflicting merges, it shouldn't actually loose any useful history, no?
[00:05] <beuno> aaaaaaaah, interesting...
[00:05] <lifeless> beuno: it always loses history
[00:05] <beuno> _not_ what I need then  :D
[00:05] <lifeless> beuno: if you are a leaf node in the contributor graph, then the impact of this loss is minor or even trivial.
[00:05] <beuno> it should be stressed that i's more of a cosmetic thing
[00:06] <lifeless> beuno: if you are not a leaf node in the contributor graph, then every node following you has pointers to revisions that your branch no longer refers to
[00:06] <lifeless> beuno: imagine if linus rebased the linux mainline to insert a new commit a few days ago, which he'd done on a 'private mainline' or something
[00:07] <jdong> eep, what does a KeyError on a pack during commit mean?
[00:07] <jdong> bzr: ERROR: exceptions.KeyError: 'sftp://linerva/%7E/docs/.bzr/repository/upload/zq5x7hmwfonjtr1jgpd9.pack'
[00:07] <lifeless> beuno: so - if you want to encourage a strict hub and spoke merge graph, rebase may fit the leaf nodes only
[00:07] <lifeless> beuno: but if there are no leaf nodes, noone can use rebase without impact
[00:08] <beuno> lifeless, I see. I understand why you're so pesimistic about it now  :D
[00:08] <lifeless> jdong: no idea; what bzr version? try it again ?
[00:09] <jdong> 1.0 locally, 1.1.0rc was used a bit remotely, seems to happen consistently with this commit (9 pngs)
[00:09] <lifeless> file a bug
[00:09] <lifeless> get the backtrace from ~/.bzr.log
[00:10] <jdong> will do
[00:10] <ubotu> New bug: #191402 in bzr "bzr resolve fails on files with certain strings" [Undecided,New] https://launchpad.net/bugs/191402
[00:21] <ubotu> New bug: #191409 in bzr "commit on bound branch yields KeyError" [Undecided,New] https://launchpad.net/bugs/191409
[00:24] <jdong> lifeless: ^^ filed. Let me know if any more information would be helpful
[00:28] <jdong> lifeless: odd, looked like bzr+ssh:// worked fine (remote smartserver is 1.1.0~rc)
[00:42] <mtaylor> anyway to find out in which revision a file was removed?
[00:43] <mtaylor> or to get a log of a file not currently in a working tree?
[00:44] <jdong> mtaylor: probably not best way, but bzr log -v shows all the add/modify/deletes associated with each commit....
[00:44] <jdong> mtaylor: so you can pipe that to less and search through it for a filename
[00:44] <jdong> the first catch should be the deleted revision
[00:45] <rolly> there are two grep plugins, aren't there? Maybe one of those can help
[00:46] <mtaylor> cool. that worked
[00:47] <mtaylor> so now if I want to revert the deleted file to that rev... ?
[00:47] <mtaylor> I actually want to restore that file and another, and then revert two other files to the state they were in that rev
[00:47] <beuno> mtaylor, you can:  bzr cat dir/file -r revno
[00:47] <mtaylor> hm
[00:47] <beuno> cat it to a file
[00:47] <mtaylor> yeah
[00:47] <beuno> and there you have it
[00:48] <beuno> bzr cat dir/file -r revno > new_file
[00:48] <mtaylor> well hot-damn, look at that
[00:48] <lifeless> mtaylor: please file a bug
[00:48] <mtaylor> lifeless: against what?
[00:48] <jdong> mtaylor: probably against log deleted_file_name not working
[00:49] <lifeless> mtaylor: using revert to reinstate a deleted file to an old version
[00:49] <mtaylor> ah. ok
[00:49] <lifeless> mtaylor: because you want to restore the file id too
[00:49] <jdong> lifeless: shouldn't there be a way to log old_file_name too?
[00:49] <lifeless> mtaylor: I think there is one for deleted-way-back file names not working. we need a syntax for saying 'this file in that revision'
[00:49] <jdong> that doesn't involve a long grep
[00:50] <lifeless> mtaylor: also, for your case, to restore the file name I suggest you do:
[00:50] <lifeless> bzr merge -r 0..before:DELETEDIN ./path/to/filename
[00:50] <lifeless> mtaylor: rather than playing games with cat
[00:52] <mtaylor> lifeless: can I give that a list of filenames?
[00:52] <lifeless> mtaylor: no, not yet. there is a bug about that ;)
[00:52] <lifeless> mtaylor: OTOH you can give it a directory :)
[00:52] <lifeless> if a directory was deleted
[00:53] <mtaylor> well, I actually do want to cherry pick file from the dir...
[00:53] <mtaylor> but that's why bash has for!
[00:53] <jdong> for file in.....
[00:54] <lifeless> beuno: jdong: for reference, 'revert' is an alias for a special form of merge. So problems with revert can usually be addressed by using merge in a clever way.
[00:54] <lifeless> this matters because you get better results with log afterwards.
[00:54] <lifeless> and with merge
[00:54] <jdong> lifeless: thanks. I should put this channel in my autojoin. I've learned more here the past 20 minutes than my entire day :)
[00:56] <beuno> lifeless, but won't you have to manage conflicts for a file you actually want to overwrite with a previous version?
[00:56] <lifeless> beuno: rarely
[00:57] <lifeless> beuno: anyhow, note that this is the exception, normally just revert will DTRT
[00:57] <beuno> lifeless, interesting. Thanks for the tip
[01:04] <jdong> lifeless: interesting, it seems like the problem is pushing over sftp onto an OpenAFS filesystem causes all kinds of blowups that I didn't notice before
[01:04] <jdong> bzr: ERROR: Generic path error: 'x5mcow4qnooegj14jua7.fetch': Failure: unable to rename to '../packs/e99efc4177e3d29106b0219514f8c3c4.pack')
[01:04] <jdong> that's a new one
[01:05] <jdong> lifeless: is there any way to get paramiko or whatever the SFTP backend is to give more debugging info?
[01:16] <poolie> jdong, there may not be a debug option, but there is a debug setting in paramiko
[01:16] <poolie> i'm just not sure how it's exposed
[01:16] <poolie> it may be an environment variable
[01:17] <poolie> separately, the failure i have at the moment is bzrlib.tests.blackbox.test_bundle_info.TestBundleInfo.test_bundle_info
[02:11] <poolie> i'm planning to fix bug 189771 by keeping a record of plugins that failed to load,
[02:11] <ubotu> Launchpad bug 189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/189771
[02:11] <poolie> and having the test suite fail if that list is nonempty
[02:15] <spiv> poolie: that sounds good to me
[02:15] <poolie> i think the other dirstate thing is now merged
[02:15] <poolie> god and pqm willing
[02:26] <lifeless> poolie: I don't know that the launchpad plugin fails to load
[02:27] <lifeless> poolie: it may be that the tests for it fail to load, but that that is a soft error.
[02:27] <poolie> true
[02:27] <lifeless> poolie: if its the plugin failing to load, perhaps a test that all present plugins load  ?
[02:28] <lifeless> (said test disabled by --no-plugins of course)
[02:28] <poolie> ok actually it does load
[02:29] <lifeless> if its the tests for it failing to load; then I think failing to load a test containing module should be a hard error not a soft error
[02:29] <lifeless> I've always thought this :)
[02:29] <lifeless> as in - don't run any tests, just stop cold
[02:33] <poolie> right
[02:33] <poolie> and it'd be a simple way to fix it
[02:33] <poolie> if you don't like it, you can always use --no-plugins
[03:16] <lifeless> poolie: can you land the 1.3 NEWS sections etc asap
[03:16] <lifeless> poolie: its a blocker for doing merges to mainline, unless you're going to fixup NEWS for us :)
[03:17] <lifeless> hmm, well not 1.3, but at least the markers for what is 1.2
[03:17] <poolie> lifeless, sure
[03:17] <lifeless> (this is why its in the release process docs)
[03:18] <poolie> i have not got up to that part of the process yet
[03:19] <lifeless> ah
[03:19] <lifeless> so technically I can land something in mainline still. _cool_
[03:19] <lifeless> :>
[03:26] <poolie> lifeless, i'm submitting that patch now
[03:26] <poolie> the static declarations in symbol_versioning are a bit ugly
[03:26] <poolie> remember to check you merges to NEWS go into the right place
[03:26] <lifeless> which patch?
[03:26] <poolie> to call it 1.3dev
[03:26] <lifeless> oh the release stuff
[03:26] <lifeless> yes
[03:27] <lifeless> I'll hold off this merge then
[03:27] <lifeless> I suspect your release process is somewhat difference in internal nature than mine
[03:30] <lifeless> thumper: so why did you add test_lp_registration when there is test_register already ?
[03:31] <thumper> lifeless: test_register was testing the register branch command
[03:31] <lifeless> and the rpc
[03:31] <thumper> lifeless: whereas test_lp_registration was testing the launchpad xmlprc bits
[03:31] <poolie> lifeless, also your change to use edge seems to break the tests, now that they're running, but probably in a straightforward way
[03:32] <lifeless> poolie: well, when my change landed all the tests passed :)
[03:32] <lifeless> thumper: for instance, test_register has test_mock_server_registration, testing the service directly
[03:33] <thumper> lifeless: I was pairing with abentley to do this
[03:33] <thumper> lifeless: and he suggested it and it seemed reasonable at the time
[03:33] <lifeless> thats fine, I am worried that we either have duplication, or confusion.
[03:33] <lifeless> if there is no duplication then its at best confusing to me
[03:33] <poolie> i think i will merge the files and dedupe
[03:33] <lifeless> because test_register is just blackbox tests
[03:34] <lifeless> thanks poolie
[03:34] <thumper> the tests in test_lp_registration are very simple and explicit, I don't think there is any duplication
[03:34] <lifeless> is *not*
[03:34] <thumper> I don't have a strong opinion one way or the other
[03:34] <thumper> the tests could be moved if that would help unconfuse you
[03:35] <lifeless> poolie has already said he will
[03:35] <abentley> poolie: But using --no-plugins means I can't use gselftest to run my tests...
[03:35] <poolie> ! i didn't know of gselftest
[03:35] <lifeless> abentley:
[03:36] <lifeless> abentley: tests that fail to load are still broken; I _really_ want hard errors on all such things
[03:36] <lifeless> abentley: I don't really care if its expressed as a failing test ('all test scripts loaded'), or as an earlier error ('failed to create test suite')
[03:36] <abentley> lifeless: I think I agree.
[03:37] <abentley> There are some plugins I don't run because their test suites don't pass.
[03:37] <poolie> abentley, so you mean you want it shown as a failure, but other tests should run?
[03:38] <abentley> poolie: I think that would be fine.
[03:39] <lifeless> I think its unneeded complexity though
[03:39] <poolie> note that this is only when the plugin's tests can't even be imported
[03:39] <lifeless> as failing to run any tests is much easier to signal
[03:39] <poolie> hopefully that's rare
[03:40] <abentley> I think mainly I was saying that --no-plugins is not a panacea.
[03:41] <abentley> But the plugin should be fixed, and I have a low tolerence for broken plugins.
[03:41] <abentley> I have a very big ~/.bazaar/plugins/inactive directory
[03:48] <poolie> lifeless, re indenting of news, you want the asterisks in column 5?
[03:50] <lifeless> poolie: yes
[04:00]  * igc bbl
[04:05] <poolie> lifeless, spiv: patch for 189771 sent, would appreciate if someone could look at it
[04:05] <poolie> i'm going out for a bit
[04:05] <ubotu> New bug: #191449 in bzr-gtk "tests should skip if there's no $DISPLAY" [Undecided,New] https://launchpad.net/bugs/191449
[04:43] <lifeless> bleh what a day of little-tasks
[04:46] <lifeless> time for some coding
[04:53] <i386> lifeless: im getting another me here at work
[04:53] <i386> so they can do those sorts of things :)
[04:53] <lifeless> didn't they break the mold?
[04:55] <i386> haha
[04:55] <i386> urgh
[04:55] <i386> large PNG is large
[05:09] <mwhudson> hee: AttributeError: '_PreviewTree' object has no attribute 'get_symlink_target'
[05:10] <mwhudson> i guess we didn't think that code was complete
[05:19] <abentley> mwhudson: nopes.
[05:50] <ubotu> New bug: #191466 in bzr "bzr update on missing file does nothing. svn update brings back file." [Undecided,New] https://launchpad.net/bugs/191466
[06:35] <poolie> lifeless, what do you mean "5 spaces rather than 2"?
[07:35] <lifeless> rather than 4
[07:36] <lifeless> from
[07:36] <lifeless>     here
[07:36] <lifeless> from
[07:36] <lifeless>      here
[07:36] <lifeless> thats what the diff shows
[07:36] <poolie> thought so
[07:36] <poolie> did you have an objection to vila's patch other than the trace thing?
[07:37] <lifeless> vila? or alexander?
[07:43] <poolie> vila
[07:43] <poolie> regarding setup.py
[07:44]  * igc dinner
[08:45] <lifeless> poolie: oh right the test cleanup one?
[08:45] <lifeless> poolie: note vs info ?
[08:50] <poolie> yes
[08:52] <lifeless> poolie: I hadn't seen his follow up
[08:52] <lifeless> iz fine
[08:53] <poolie> i have a tarball
[09:15] <poolie> night all
[09:32] <rolly> yay, rc1
[10:51] <johnny> if i do a cvsps-import, what exactly do i have ? layoutwise?
[11:09] <cropalat> hi, i need some help with bzr. Any body???
[11:10] <garyvdm> There are lots of people here. Go ahead an ask.
[11:10] <cropalat> since yesterday, i try to use "bzr branch http://bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta", and the transmission stop as you can see with this part of tcpdump output.
[11:11] <cropalat> 08:04:52.496764 IP <IP_ADDRESS>.www ><PHONE_NUMBER>7.user.veloxzone.com.br.35472: P 2615850:2616810(960) ack 6326 win 8416 <nop,nop,timestamp<PHONE_NUMBER> 39394400>
[11:11] <cropalat> 08:04:52.496852 IP<PHONE_NUMBER>7.user.veloxzone.com.br.35472 > <IP_ADDRESS>.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394531<PHONE_NUMBER>,nop,nop,sack 2 {2598570:2616810}{2561450:2592810}>
[11:11] <cropalat> 08:04:52.510477 IP <IP_ADDRESS>.www ><PHONE_NUMBER>7.user.veloxzone.com.br.35472: . 2616810:2618250(1440) ack 6326 win 8416 <nop,nop,timestamp<PHONE_NUMBER> 39394400>
[11:11] <cropalat> 08:04:52.510582 IP<PHONE_NUMBER>7.user.veloxzone.com.br.35472 > <IP_ADDRESS>.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394535<PHONE_NUMBER>,nop,nop,sack 2 {2598570:2618250}{2561450:2592810}>
[11:11] <cropalat> 08:04:52.524143 IP <IP_ADDRESS>.www ><PHONE_NUMBER>7.user.veloxzone.com.br.35472: . 2618250:2619690(1440) ack 6326 win 8416 <nop,nop,timestamp<PHONE_NUMBER> 39394403>
[11:11] <cropalat> 08:04:52.524272 IP<PHONE_NUMBER>7.user.veloxzone.com.br.35472 > <IP_ADDRESS>.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394538<PHONE_NUMBER>,nop,nop,sack 2 {2598570:2619690}{2561450:2592810}>
[11:11] <cropalat> 08:04:52.537799 IP <IP_ADDRESS>.www ><PHONE_NUMBER>7.user.veloxzone.com.br.35472: . 2619690:2621130(1440) ack 6326 win 8416 <nop,nop,timestamp<PHONE_NUMBER> 39394403>
[11:11] <cropalat> 08:04:52.537903 IP<PHONE_NUMBER>7.user.veloxzone.com.br.35472 > <IP_ADDRESS>.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394541<PHONE_NUMBER>,nop,nop,sack 2 {2598570:2621130}{2561450:2592810}>
[11:11] <cropalat> 08:04:52.551418 IP <IP_ADDRESS>.www ><PHONE_NUMBER>7.user.veloxzone.com.br.35472: . 2621130:2622570(1440) ack 6326 win 8416 <nop,nop,timestamp<PHONE_NUMBER> 39394406>
[11:11] <cropalat> 08:04:52.551511 IP<PHONE_NUMBER>7.user.veloxzone.com.br.35472 > <IP_ADDRESS>.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394545<PHONE_NUMBER>,nop,nop,sack 2 {2598570:2622570}{2561450:2592810}>
[11:11] <cropalat> 08:04:52.565075 IP <IP_ADDRESS>.www ><PHONE_NUMBER>7.user.veloxzone.com.br.35472: . 2622570:2624010(1440) ack 6326 win 8416 <nop,nop,timestamp<PHONE_NUMBER> 39394410>
[11:11] <cropalat> 08:04:52.565177 IP<PHONE_NUMBER>7.user.veloxzone.com.br.35472 > <IP_ADDRESS>.www: . ack 2558570 win 3530 <nop,nop,
[11:11] <garyvdm> Please use http://pastebin.org/
[11:11] <beuno> please :D
[11:12] <cropalat> my screnn show this "| [=                                                         ] Transferring 0/4"
[11:12] <cropalat> sorry
[11:12] <beuno> cropalat, does bzr output an error?
[11:12] <cropalat> beuno, no
[11:12] <cropalat> but it get out with timeout
[11:12] <beuno> cropalat, doesn't seem bzr-related than
[11:13] <beuno> what version of bzr are you using?
[11:13] <cropalat> Bazaar (bzr) 1.0.0
[11:14] <beuno> cropalat, seems good enough. It's probably related to some problem with your ISP
[11:14] <beuno> you can try updating to the latest bzr if you want to try _something_ on your end
[11:14] <beuno> 1.1 es the latest release
[11:14] <cropalat> i will get the traffic to see. Thanks
[11:15] <cropalat> my distro are working with 1.0
[11:15] <beuno> cropalat, what distro would that be?
[11:15] <cropalat> Ubuntu 7.10
[11:16] <beuno> cropalat, you can get the lastest from: https://launchpad.net/~bzr/+archive
[11:16] <beuno> either add the ppa to your sources.list, or just plain download and install the deb
[11:16] <cropalat> beuno, what is new in this version?
[11:17] <beuno> cropalat, nothing significant enough that would fix your timeout, but it won't hurt  :D
[11:19] <cropalat> beuno, thanks
[11:20] <beuno> cropalat, np
[11:23] <cropalat> beuno, where the bzr put the temp files?
[11:24] <garyvdm> cropalat: yourbranch/.bzr/
[11:26] <cropalat> garyvdm, any specia name?
[11:27] <garyvdm> cropalat - sorry - I don't understand
[11:27] <garyvdm> What are you looking for>
[11:27] <garyvdm> *?
[11:29] <cropalat> garyvdm, how can i identify where the bzr are storing the download data at this time?
[11:29] <garyvdm> yourbranch/.bzr
[11:29] <garyvdm> where yourbranch is the dir you are creating the branch in
[11:32] <cropalat> ok
[11:33] <garyvdm> If you bzr branch mybranch and it stop half way you can cd mybranch then bzr pull and it will carry on from where it stopped
[12:05] <mikeX> hello, this is somewhat OT, but is it possible for your patiencediff to output only the *characters* that differ, not the whole line?
[12:06] <luks> you can split the input on characters, not lines
[12:06] <luks> but then it will be very slow, obviously
[12:06] <mikeX> how would that work?
[12:06] <luks> list("foobar") -> ['f', 'o', ...]
[12:06] <mikeX> well actually i don't wont characters, just the subsets that differ
[12:07] <mikeX> hello world vs hell0_world, in such a case 0_
[12:08] <lifeless> mikeX: yes the algorithm can do this
[12:08] <lifeless> mikeX: and our internal code too
[12:08] <mikeX> can you point me to the files that require modification for changing the output then?
[12:08] <lifeless> mikeX: but its much more expensive (if each line was 80 characters, and it was a linear cost, 80 times slower, but its > linear, upto quadratic worst case)
[12:09] <lifeless> mikeX: what you could do is something slightly different, and on the differing lines run the more expensive algorithm
[12:09] <lifeless> bzrlib.diff has the bulk of the diff high level logic
[12:10] <mikeX> thanks a lot
[12:10] <lifeless> gnight
[12:10] <lifeless> oh also
[12:11] <lifeless> check out bzrlib.tests - there is a thing in there -assertEqualDiff that does a character level diff output
[12:12] <luks> mikeX: PatienceSequenceMatcher(None, "hello world", "hell0_world").get_opcodes()
[12:18] <mikeX> that's greak, thanks luk
[12:18] <mikeX> s
[13:46] <jdong> is there a bzr plugin yet that can act like a "branch aggregrator"
[13:46] <jdong> i.e. check X different branch locations for new commits
[13:51] <awilkins> jdong: Even if there was, would there be any difference between that and a shell script?
[13:51] <jdong> awilkins: well other than from a UI perspective, no.
[13:52] <jdong> that would be a final fallback if there weren't a plugin AND I wasn't willing to write one :)
[13:52] <awilkins> Sort of like a branch manager GUI?
[13:52] <awilkins> Keeps track of all your branches and such?
[13:53] <jdong> kind of like let's say "foobar" has a large developer community, with 20+ branches
[13:54] <jdong> right now, if I want to check for new commits from one of the developers, I'd have to keep track of 20 branch URLs by hand
[13:54] <jdong> or edit aliases by hand in a text editor... both of which are kind of annoying
[13:54] <jdong> I'd love to be able to do like "cd foobar; bzr check-related-branches"
[13:55] <jdong> and get a quick summary of type "Branch $foo has $n new revisions"
[14:40] <ignas> hi
[14:40] <ignas> if i have 5 branches and want to put them into a shared repository that i have just created using "bzr init-repo" what would be the command to use?
[14:41] <LeoNerd> Just push them there
[14:41] <luks> bzr branch
[14:41] <ignas> i want to pull 1 branch as a trunk, and put other 4 in branches/
[14:41] <luks> oh, or push
[14:41] <ignas> LeoNerd: thanks
[14:41] <mikeX> hmm, PatienceSequenceMatcher seems to yield very bad results for unicode strings
[14:45] <ignas> hmm I get bzr: ERROR: No WorkingTree exists for "file:///home/ignas/src/schooltool.devtools/.bzr/checkout/" if I try bzr mkdir branches in the central repository
[14:46] <fullermd> You just want to use mkdir for branches/...
[14:46] <ignas> oh
[14:55] <ubotu> New bug: #191569 in bzr "Cannot set "whoami" at a repository level" [Undecided,New] https://launchpad.net/bugs/191569
[15:00] <ubotu> New bug: #191572 in bzr "KeyError when pulling from svn repo." [Undecided,New] https://launchpad.net/bugs/191572
[15:10] <ubotu> New bug: #191576 in bzr "TypeError when using `bzr branch` on an svn repository" [Undecided,New] https://launchpad.net/bugs/191576
[15:23] <dato> abentley: hi. do you think `shelf show` could use colors like `shelve` itself does, and maybe gain a --no-color switch?
[15:24] <abentley> dato: I don't remember what shelf show does.
[15:24] <dato> display the contents of a patch from the shelf
[15:25] <dato> basically `cat $topofshelf`
[15:25] <abentley> Yeah, I think that's reasonable.
[15:26] <dato> would you like a bug? I'm afraid time doesn't allow me to offer anything else =)
[15:27] <abentley> dato: Launchpad actually provides for feature requests as "blueprints".
[15:28]  * dato guesses he has the "wishlist bug" concept very hard wired in his brain
[15:29]  * abentley doesn't like it when people say his software has bugs just because it doesn't have a feature they want :-)
[15:30] <abentley> I actually prefer the Trac approach of "Issues" being "Bugs", "Enhancements" and "Tasks".
[15:32] <schierbeck> fuck
[15:32] <schierbeck> had a network outage, now the bzr-gtk trunk is locked, and break-lock ain't working
[15:32] <abadger1999> Any packagers of bzr & company for Ubuntu/Debian/etc around?
[15:32] <dato> abadger1999: yes
[15:33] <abadger1999> Do you guys do anything out of the ordinary to manage the large number of bzr plugins?
[15:34] <abentley> schierbeck: Pastebin us a traceback, and I can take a look.
[15:34] <dato> abadger1999: yes: most of them are not packaged
[15:34] <dato> personally I wanted to create a big package with a selection of the most useful ones
[15:34] <dato> but several core people disliked the idea
[15:34] <abadger1999> dato: Yeah, that would make my day as well :-)
[15:35] <dato> and I'm afraid I'm not going to spend my time in creating 10 or 12 different packages for such tiny stuff
[15:35] <abentley> dato: Isn't that what I do? ;-)
[15:35] <schierbeck> abentley: well, the only thing i get which resembles an error is "Disconnecting: Received extended_data after EOF on channel 0."
[15:35] <schierbeck> right after using break-lock on the remote branch
[15:35] <dato> abentley: hehe
[15:36] <abadger1999> abentley: That's why bzrtools is packaged for Fedora but bzr-{dbus,avahi,bisect} is not :-)
[15:37] <abentley> schierbeck: That resembles a bug we had with old versions of Paramiko.
[15:37] <abentley> But it was a harmless message
[15:37] <schierbeck> maybe, but the locks are not released
[15:37] <schierbeck> actually, it just resets the lock time
[15:38] <abentley> schierbeck: Okay, so you probably have a couple of "bzr serve" processes running on the server.
[15:38] <abadger1999> If there was an effort to get things into a single upstream product (like bzrtools) and make releases as part of that product then there'd be more uptake of the individual utilities.
[15:38] <abentley> You should be able to run break-lock several times.
[15:39] <schierbeck> abentley: yeah, it seems like it
[15:39] <schierbeck> i'll try
[15:39]  * abadger1999 resigns himself to asking for more bzr related packagers on the fedora lists
[15:39] <abentley> Each time you break-lock, a bzr process should stop.
[15:39] <schierbeck> abentley: that worked! thanks!
[15:40] <abentley> schierbeck: No problem.
[15:42] <dato> abadger1999: and what do the packagers say? they'll do more packages?
[15:42] <schierbeck> i've drunk an unhealthy amount of coffee today...
[15:42] <abadger1999> dato: I'm guessing I'll get a bunch of people telling me to use git :-/
[15:42] <dato> abadger1999: heh
[15:43] <abadger1999> dato: I don't think the overlap between packagers and bzr users is very high in Fedora ATM.
[15:43] <dato> abadger1999: there are a lot of git fanboys in debian as well
[15:43] <abentley> abadger1999: Could you post something to the list?  If the authors are amenable, I'd be happy to incorporate more stuff into bzrtools.
[15:43] <dato> damn, abentley was faster about the list bit
[15:43] <abadger1999> abentley: I sure can.
[15:43] <dato> :)
[15:44] <abentley> And that's not exclusive with shipping the plugins separately.
[15:44] <abadger1999> Anything to help me scale more effectively :-)
[15:45] <ignas> how do I do a push without being in the branch, like bzr push /path/to/some-repo sftp://place-for-push ?
[15:45] <abadger1999> abentley: Oh?  Meaning you'd help manage releases as separate tarballs from the bzrtools tree?
[15:46] <abentley> abadger1999: Meaning that bzr-dbus can be provided as a standalone plugin and as part of bzrtools.
[15:46] <abadger1999> abentley: okay.  that would be awesome for packagers.
[15:47]  * dato bbl
[15:47] <abentley> I suppose the converse also applies, if people think bzrtools is getting too big.
[16:02]  * awilkins sulks because there is no dbus on Windows
[16:02] <LeoNerd> There were rumours of a port
[16:03] <awilkins> Cursory searching reveals one
[16:03] <awilkins> I mean, it wouldn't be hard, windows is thick with IPC methods it could wrap
[16:03] <awilkins> Only wanted to see if commit-notifier worked
[16:04] <awilkins> It puts an icon in the toolbar then dies :-)
[16:09]  * Debolaz has a dbus-daemon.exe running on his Windows XP box.
[16:09] <Debolaz> At least according to task manager. :)
[16:35] <orospakr> Hey, can I get bzr diff to do colour diffs with paging like git can do?
[16:35] <awilkins> Right, I've switched from svk to bzr for my working-at-home needs from the SVN repo
[16:36] <orospakr> awilkins, do you have issues where bzr eats all available ram (due to a bug in libsvn) when doing a big svn checkout?
[16:36] <awilkins> orospakr: Yes, I have that problem, esp on my big repo
[16:37] <orospakr> awilkins, it's been ongoing for years.
[16:37] <awilkins> orospakr: Alas, it's now failing on something else, having successully converted about 7900 / 9000 revisions
[16:37] <orospakr> recently I finally saw some activity on the svn bug tracker about this issue.
[16:37] <orospakr> harsh.
[16:38] <awilkins> You can at least resume it after it MemoryErrors you
[16:38] <awilkins> But now it's the same KeyError on a pack each time
[16:38] <awilkins> It's in the upload folder which makes no sense to me because it's PULLING not pushing
[16:38] <awilkins> Go figure.
[16:38] <awilkins> There's a bug in for it
[16:39] <awilkins> #191572
[16:42] <awilkins> I think increasingly SVN is going to end up as the nice, safe, steady backend for roving teams of developers using wild and crazy new VCS tools
[16:43] <awilkins> Despite all the effort they put in for v 1.5
[16:44] <awilkins> And when TortoiseBzr or TortoiseGit are done, SVN will really start to die.
[16:45] <awilkins> Tortoise<DVCS> ought to be possible - just use the common idiom and a plugin backend
[16:46] <awilkins> Should cover bzr, mtn, hg, git ; there aren't too many radical differences there.
[16:51] <awilkins> cd ..
[16:51] <awilkins> oops
[17:10] <abentley> orospakr: "bzrtools" provides cdiff.  You can also use diff --using colordiff.  The pager side is generally done using |less -R.
[18:56] <zurgutt> folks, help me understand something: apparently i can commit just one subdir of branch by "bzr commit dir" but how to update just some file/subdir? "bzr update dir" updates whole branch.
[18:57] <kiko> for general reading and comments: http://news.launchpad.net/general/the-great-source-code-supermarket
[18:57] <kiko> zurgutt, I'm not sure that's actually possible
[18:57] <zurgutt> bzr help update says "bzr update [DIR]"
[18:58] <fullermd> That should probably say "bzr update [BRANCH]" instead...
[18:59] <zurgutt> what would [BRANCH] mean in this case ?
[18:59] <fullermd> "bzr update foo" instead of "cd foo ; bzr update"
[18:59] <dato> kiko: 'three or more of the words: "foo"' <-- the foo stuff is screaming for commas, otherwise you try to read it as a sentence and choke
[19:00] <kiko> that's kind of the point ;)
[19:00] <zurgutt> ah.. but no way to update one file?
[19:01] <fullermd> No, that's not a sensible operation.  Files aren't versioned, whole branches are.
[19:01] <dato> kiko: well, suit yourself. IMHO it sucks, but it's not my problem. :-)
[19:01] <zurgutt> in respect to this, how does committing just one file make sense?
[19:02] <fullermd> You can create constructs like "a branch at rev6, with this file at rev3", but what you'll end up with is a branch at rev6 with one altered file; that it happens to have the same content as the file did at rev3 is periphal and of no interest to bzr.
[19:02] <fullermd> In that you're implicitly creating a branch state that only partly corresponds to what's on disk.
[19:06] <zurgutt> should be ok to update (well, get) one file to working tree from central repo without updating local status.. someone used to svn is asking for it, i myself am not familiar with svn
[19:08] <fullermd> Well, "central" is kinda question-begging.
[19:08] <fullermd> You can use 'revert' to throw a file's contents to some arbitrary rev.
[19:20] <ubotu> New bug: #191651 in bzr "bazaar.conf::editor line quoting is not preserved correctly" [Undecided,New] https://launchpad.net/bugs/191651
[19:33] <n[ate]vw> what's the best way to send another coder a repo over, say, email? just tarring the project folder up can leave "dangling pointers" to other branches on my machine
[19:33] <fullermd> Does that matter?
[19:34] <n[ate]vw> it doesn't hurt, I suppose. It's not like "merge" would have a better reference given that mode of transportation
[19:35] <n[ate]vw> so that's not a bad way to do do a lo-fi share without involving an HTTP server or opening ports for ssh?
[19:36] <fullermd> I s'pose you could just push it to /tmp somewhere and tar that up.  Then it wouldn't have those cosmetic issues.
[19:36] <dato> right
[19:36] <dato> push /tmp/foo
[19:36] <dato> remove-tree /tmp/foo if you'd like
[19:36] <fullermd> That would also take care of issues you might have with it being in a repo, too.
[19:39] <n[ate]vw> ok, that makes sense. the push would let bzr know it's a distinct branch, which is basically what I was wanting. and the remove-tree would help the other guy get familiar with basic usage :-)
[19:40] <luks> hm, would be nice to have an option to do this from bzr export
[19:42] <n[ate]vw> yeah, I'd looked into export, but it didn't seem to be quite what I was looking for (a complete branch, but able to go wherever a .tgz can)
[19:42] <abentley> n[ate]vw: bzr send is a good choice for sending a branch to someone.
[19:43] <n[ate]vw> abentley: that's not just for patches?
[19:43] <luks> that would involve creating an empty target branch, no?
[19:43] <abentley> n[ate]vw: It preserves all data except tags.
[19:43] <fullermd> I thought bundles were a wildly inefficient means of bulk rev moving...
[19:43] <abentley> luks: yes, it would
[19:44] <abentley> fullermd: They are actually more efficient, because they use MPdiff and don't have any fulltexts.
[19:44] <abentley> And they use bzip.
[19:45] <fullermd> Interesting.
[19:46] <abentley> The previous bundle format was much more inefficient, in terms of both storage and speed.
[19:47] <dato> n[ate]vw: there is --no-patch, in case you want that if you use send
[19:47] <dato> (that'd be the equivalent of the remove-tree above :)
[19:49] <fullermd> D'oh, you moved bzrtools to launchpad...
[19:49] <abentley> Something wrong with that?
[19:50] <fullermd> Not as such, really.  Just the URL's for the download files are unfriendly.
[19:50] <fullermd> Are you planning to keep using the 'stable' release series?
[19:50] <fullermd> (i.e., for 1.3.0 and 1.4.0 and such)
[19:50] <abentley> Yes, that's the plan.
[19:51] <n[ate]vw> dato: so I would "bzr send --no-repo -o ../sendable_repo", and then the other developer would need to create an empty branch and "bzr merge sendable_repo"?
[19:51] <fullermd> 'k.  I think I can get away with using the 1.x.y version for that bit of the path too, and not have to update the base URL for every upgrade then...
[19:51]  * fullermd is trying to get a head start on port updates for the next release while he waits for a phone call.
[19:52] <abentley> I can't really keep hosting stuff on panoramicfeedback.com now that I don't work there.
[19:52] <fullermd> Some places are funny like that.
[19:52] <dato> n[ate]vw: sorry, gotta run, but : `bzr send --no-patch -o ../sendable ../empty-branch` <-- *you* create the empty branch
[19:52] <dato> leaving now, but I leave you in good company ;)
[19:53] <n[ate]vw> thanks, I'll keep experimenting!
[19:56] <fullermd> Hm.  I guess I should add LP as a backup source for bzr too, as long as I'm here...  means I need to get creative on that anyway.  Blah.
[19:58] <fullermd> Heck with it, I'll just change it by hand for every release series.
[20:00] <n[ate]vw> can someone explain what the function of the PUBLIC_BRANCH argument is on bzr send?
[20:00] <fullermd> It's the location of a public mirror of your branch (assuming one exists)
[20:00] <n[ate]vw> how can I "unremember" it? I was playing with it, and now I can't play *without* it
[20:01] <fullermd> You can edit the branch.conf manually.  Don't think there's a UI for it.
[20:03] <appcine> Hi! I've been using svn for a project about a year. Is it possible to preserve revision history somehow when switching to bzr? I'm not likely to revert as the system is quite stable, but it's fun to check out oooold stuff to see what you had back then :)
[20:05] <n[ate]vw> fullermd: ok. so by setting it, it would cause the branch to push changes to submit_branch?
[20:05] <n[ate]vw> hmm, but that role seems to be fulfilled by push_location already
[20:05] <fullermd> No, it's not used for push.
[20:06] <fullermd> I'm not sure if it's used for anything except send.  Maybe some of the PQM stuff?
[20:06] <abentley> appcine: Check out bzr-svn.  It provides lossless import from svn and export to svn.
[20:06] <appcine> abentley: Ah, sweet
[20:07] <n[ate]vw> fullermd: so I guess I'm confused as to what happen's when I specify dato's ../empty-branch
[20:07] <abentley> fullermd: Yes, it's used by PQM-submit also.
[20:08] <abentley> I can't think of anything else that uses it offhand.
[20:08] <fullermd> n[ate]vw: 'send' can include the revisions inline, or it can refer to an external branch ("Get these revs from there").  The public loc is used for the latter.
[20:09] <fullermd> (it may be used in the former too, if the person trying to do the merge needs other revs you didn't include)
[20:09] <n[ate]vw> ok, so if I specify a public branch, the ../sendable file won't actually include the history?
[20:09] <fullermd> No, you need --no-bundle to cause that.
[20:10] <abentley> But if you specify --no-bundle, then a public branch is required.
[20:11] <n[ate]vw> ok
[20:12] <abentley> The important thing to note is that dato's commandline specifies only one branch: the empty one
[20:12] <n[ate]vw> I guess I don't see why you would specify a "public_branch" on your local machine when sending to another developer
[20:14] <abentley> What you are sending is a requst to pull or merge your changes.  If you have a public mirror, there's no need to include a bundle, and that's what public_branch is for.
[20:15] <n[ate]vw> ok, so the public_branch usually goes with --no-bundle, so that you can send some changes to somebody who already has a branch or can grab one from the public repo
[20:15] <abentley> Yes.
[20:17] <n[ate]vw> cool. then for a one-off "here's my code, and also please play around with bazaar",  it looks as though my options are:  A) push+remove-tree+tar on my side, untar+co for the receiver, or B) send on my side, init+pull on the receiver
[20:17] <n[ate]vw> in this case, A seems preferable given that I'm a little more familiar with bazaar than the other developer
[20:19] <johnny> so, what exactly do i get when i run cvsps-import on a repo
[20:19] <johnny> is it a repository already?
[20:45] <lifeless> johnny: 'bzr info' :)
[20:53] <johnny> lifeless, it says repository branch: .
[20:53] <johnny> in each area
[20:55] <lifeless> sounds like each has been converted separately, which is what I would have expected if you didn't create a repository yourself
[20:55] <lifeless> you can create a repository and bzr branch them into it all at once via bzr multi-pull (from bzrtools)
[20:55] <johnny> i only have 1 branch
[20:55] <johnny> HEAD
[20:56] <lifeless> no tags?
[20:56] <fullermd> Eh?  If it says "repository branch", it's in a repo...
[20:57] <lifeless> fullermd: but a path of . ?
[20:57] <lifeless> johnny: perhaps I'm confused
[20:57] <lifeless> fullermd: unless 'repository branch' means 'the shared bit is on'
[20:59] <fullermd> I didn't say it's a great UI   :p
[20:59] <fullermd> You're in the root of the branch, so it gives the branch path as '.'
[21:00] <johnny> it doesn't matter where i am
[21:00] <fullermd> The line after it gives the location of the repo.  If it were a standalone branch, it would say "branch root: .", not "repository branch: ."
[21:01] <johnny> i have one tag called start
[21:01] <fullermd> But anyway, cvsps always puts its stuff in a shared repo.
[21:02] <johnny> i just want to shorten the path i think
[21:03] <lifeless> fullermd: oh god thats just confusing
[21:03] <lifeless> fullermd: surely it should say branch root always; and only sometimes show the repository root
[21:03] <fullermd> Well, it could be a checkout, in which case it'll say "repository checkout root: ."   :)
[21:04] <fullermd> Of course, if you move into a subdir, it calls the branch root (by whatever name) by its full path, instead of relative to $CWD like it does with '.'...
[21:04] <abentley> The fact that it says "repository branch" not "standalone branch" means that it's in a shared repo.
[21:05] <johnny> any where in here ~/projects/redemmas/infoshopkeeper/branches/HEAD
[21:05] <fullermd> Or if you info $DIR from elsewhere, it always uses a path relative to ., unless that path would include a '..'...
[21:05] <johnny> it says repository branch: .
[21:05] <johnny> under infoshopkeeper thatis
[21:06] <fullermd> johnny: I don't think cvsps-import creates working trees in the repo, so there's nowhere you could go inside any of the branches BUT the root.
[21:06] <lifeless> abentley: I think it is confusing to have something that is always the same datum labelled differently
[21:06] <lifeless> abentley: if I understand what the output is doing correctly that is
[21:07] <johnny> aha.. ok
[21:07] <johnny> so, i think i'd like to reformat per the recommendations in the user guide
[21:07] <lifeless> if they are all under the same repository
[21:08] <lifeless> just mv the directories to where you want them (still under the repository)
[21:08] <fullermd> I never directly touch the repos/branches cvsps-import creates.  I branch them elsewhere and rearrange stuff there.
[21:08] <fullermd> (that leaves them pristine for future incremental conversions, for one thing)
[21:09] <johnny> good recommendation
[21:09] <abentley> lifeless: Well, you've got a point.  When I worked on "info", it was mostly to make it handle more cases show more paths.  I didn't want to make too many changes at once.
[21:09] <abentley> ...handle more cases AND show more LOCATIONS...
[21:11] <johnny> now i just need to make loggerhead work
[21:24] <RainCT> Hi
[21:24] <lifeless> hi
[21:24] <james_w> hi
[21:24] <RainCT> is it possible to force a merge with uncommited changes?
[21:24] <lifeless> yes
[21:24] <lifeless> --force
[21:24] <lifeless> but its usually a bad idea; why do you want to?
[21:27] <RainCT> lifeless: because I have some changes that are not intended for commiting (local changes to get the code working on my machine)
[21:28] <lifeless> RainCT: merging with them present will result in you committing them
[21:28] <lifeless> RainCT: its definitely not what you want to do.
[21:28] <lifeless> RainCT: bzr shelve --all
[21:28] <lifeless> RainCT: then merge
[21:28] <lifeless> RainCT: commit
[21:28] <lifeless> RainCT: bzr unshelve --all
[21:29] <lifeless> RainCT: (but have you considered having a branch where the changes to make it work are committed)
[21:31] <RainCT> it's database password, path locations and such stuff..
[21:31] <RainCT> lifeless: thanks
[21:31] <james_w> lifeless: won't that be a problem if the changes you merge affect the same area that your local changes do?
[21:32] <james_w> (as I recall shelve currently only does two way, and doesn't handle diffs that don't apply).
[21:32] <lifeless> james_w: shelve --force
[21:32] <lifeless> james_w: its less of a problem than a commingled tree with stuff you don't want to commit and a merge you need to commit
[21:32] <mwhudson> james_w: it's not worse than having conflicts in your tree where some changes are from the merge and some from your uncommitted changes is it?
[21:33] <james_w> no, it's not worse at all.
[21:33] <lifeless> RainCT: sounds like that stuff should not be altering versioned files; I'd consider making a branch that adds an include facility or some such, then you can have an ignored file with that local stuff
[21:33] <james_w> It's just not the perfect solution in all cases.
[21:34] <lifeless> RainCT: or you could still have a branch called 'machineX' that you commit them too, but never ever merge from it.
[21:34] <lifeless> james_w: for the given scenario --force is never the right thing
[21:35] <RainCT> it doesn't commit: http://paste.ubuntu.com/4565/plain/ (had an error like that some days ago too)
[21:35] <lifeless> james_w: (merge --force) I mean
[21:35] <james_w> it would be great to have a shelve that could do 3 way merges to avoid all of this.
[21:39] <lifeless> bb crashing on the resubmit tab :(
[21:40] <james_w> RainCT: I think that is the name of one of the directories in the path that is causing the problem.
[21:40] <james_w> I can't find the bug report at the moment.
[21:40] <lifeless> abentley: the containing dir?
[21:40] <lifeless> meh
[21:40] <lifeless> james_w: ^ the containing dir?
[21:40] <lifeless> RainCT: have you committed in other projects under programació ?
[21:41] <RainCT> lifeless: yes, all my branches are there and they work fine
[21:41] <james_w> lifeless: yeah, Programació
[21:41] <james_w> RainCT: do you have versioned symlinks in the other branches?
[21:41] <lifeless> RainCT: please try the commit with BZR_PDB=1 (BZR_PDB=1 bzr commit ....)
[21:41] <lifeless> RainCT: when it stops you'll be in a python debugger
[21:42] <lifeless> RainCT: and able to example the path it fails on
[21:42] <RainCT> james_w: Programació is a symlink to another hard disk
[21:42] <RainCT> beside that there is no other symlink I think
[21:43] <james_w> ah, but if it is that then it would be odd to only fail in this branch.
[21:43] <RainCT> lifeless: ok I'm there, what now
[21:43] <james_w> RainCT: p abspath
[21:43] <RainCT> ?
[21:43] <RainCT> u'/media/sdb2/rainct/Programaci\xf3/Python/revu/bin'
[21:43] <lifeless> ok thats wrong
[21:43] <lifeless> :)
[21:44] <lifeless> whats os.getfilesystemencoding()
[21:44] <abentley> lifeless: bb restarted.
[21:44] <lifeless> thanks
[21:45] <james_w> RainCT: also "p path" please.
[21:45] <RainCT> lifeless: in an interactive python console?
[21:45] <RainCT> u'bin'
[21:45] <lifeless> RainCT: where you are right now :)
[21:46] <james_w> RainCT: and "p self.basedir" please.
[21:46] <lifeless> jam: ping
[21:46] <RainCT> lifeless: *** AttributeError: 'module' object has no attribute 'getfilesystemencoding' (and the some with python -c "import os; print os.getfilesystemencoding()")
[21:47] <RainCT> u'/media/sdb2/rainct/Programaci\xf3/Python/revu'
[21:47] <james_w> it's sys.getfilesystemencoding() I think.
[21:47] <lifeless> print bzrlib.osutils._fs_enc
[21:47] <dato> yes
[21:47] <RainCT> james_w: 'UTF-8'
[21:47] <RainCT> lifeless: UTF-8
[21:49] <luks> os.readlink doesn't seem to like unicode strings
[21:49] <lifeless> >>> '/media/sdb2/rainct/Programaci\xf3/Python/revu'.decode('utf8')
[21:49] <lifeless> Traceback (most recent call last):
[21:50] <luks> lifeless: u'/media/sdb2/rainct/Programaci\xf3/Python/revu/bin' already is unicode
[21:50] <lifeless> and giving it the u and encoding to utf8 fails too
[21:50] <lifeless> luks: yes I know
[21:50] <lifeless> luks: I am probing for what particular mis-interpretation has occured
[21:50] <luks> if I make a file 'á' on utf-8 filesystem, os.readlink(u'á') fails, but os.stat(u'á') works
[21:50] <lifeless> luks: which thanks to the entire lack of structure (its all bytes, HAI), is mainly trial and error
[21:52] <lifeless> oh foo, misread the output.
[21:52] <lifeless> ok, so its valid unicide
[21:52] <luks> yeah
[21:52] <james_w> so abspath = os.path.pathjoin(posixpath.realpath(safe_unicode(basedir)) , u'bin')
[21:52] <lifeless> right, we need a readlink wrapper
[21:52] <luks> but it's encoding it in ascii, not the FS encoding
[21:52] <lifeless> a) file a bug on python
[21:53] <lifeless> b) wrap readlink and do the fs_encoding ourselves
[21:53] <lifeless> RainCT: please file a bug on bzr
[21:53] <lifeless> RainCT: to work around this, cd to where the symlink points first
[21:53] <lifeless> RainCT: or if the symlink is in the tree you are committing; you'll have to patch bzr
[21:54] <luks> hm, from http://svn.python.org/projects/python/trunk/Modules/posixmodule.c it looks like it should be using the FS encoding
[21:55] <luks> but maybe it's a recent bugfix
[21:55] <awilkins_away> Hmm, shame you can't have bug dependencies in launchpad
[21:55] <lifeless> awilkins: we can't depend on python being fixed anyway
[21:57] <awilkins> No, but it would be nice to unpick the fix if it is ?
[21:57] <RainCT> ok, thanks :)
[21:57] <lifeless> awilkins: its a C module; we're not going to monkey patch with a new build of that at runtime :)
[21:57] <mwhudson> pff, ctypes!
[21:58]  * mwhudson hides
[21:58] <james_w> http://svn.python.org/view?rev=52415&view=rev
[21:58] <lifeless> mwhudson: I know where you live
[21:58]  * RainCT renamed /media/sdb2/rainct/Programació to something without special chars (but the symlink still has them) and now it works
[21:58] <lifeless> RainCT: what python version are you using ?
[21:59] <RainCT> 2.5.1-5ubuntu5
[21:59]  * RainCT is away for a while
[22:00] <lifeless> RainCT: please file a bug on ubuntu's python then; this is a regression from the look of it
[22:01] <awilkins> Looks like you need a test case for this anyway
[22:01] <lifeless> oh yeah, we have to change bzr
[22:01] <lifeless> someone has this in the field :(
[22:03] <james_w> lifeless: that fix isn't in 2.5
[22:04] <james_w> it wasn't also fixed in the 2.5 branch as far as I can see.
[22:04] <lifeless> james_w: its from 2006 !
[22:05] <james_w> yeah, but 2 months after the 2.5 branch was created.
[22:06] <lifeless> ekk
[22:06] <lifeless> anyhow, all moot; we support 2.4
[22:18] <schierbeck> you guys know of a generic patching library for python? i just need to be able to apply a patch
[22:19] <lifeless> schierbeck: application is really trivial, the main issue is actually parsing
[22:20] <lifeless> schierbeck: if you mean patches created by 'diff -u' I *think* there is a parser in bzrtools.
[22:20] <RainCT> lifeless: so, what should I report?
[22:20] <lifeless> RainCT: the error and original backtrace
[22:20] <schierbeck> lifeless: okay
[22:21] <lifeless> RainCT: for bzr itself. For python, that os.readlink in 2.5 barfs on unicode paths.
[22:21] <schierbeck> just checking to see if there's anything obvious, i'm not that well-versed in python libraries
[22:21] <schierbeck> and searching for "patch library" yields quite a bit of noise...
[22:21] <lifeless> RainCT: and point at the fix in svn :) - this should be an ubuntu bug, because we can cherry pick that fix from svn
[22:21] <lifeless> schierbeck: yeah I can imagine
[22:24] <foom> surely it should be filed against upstream python so they backport it into the 2.5 branch...
[22:26] <lifeless> foom: well they presumably already know that 2.5 doesn't have it, they committed it solely to trunk after all
[22:27] <foom> lifeless: if they know 2.5 doesn't have it, and explicitly didn't backport it, I (as a python software developer) would be very unhappy to see it appear only in ubuntu python 2.5
[22:27] <lifeless> foom: why?
[22:28] <foom> going against the explicit stable release policy decision of upstream for no particularly good reason.
[22:29] <lifeless> distros are more than a build engine
[22:29] <foom> it's not like anyone writing software could ever depend upon that fix existing, seeing as how no other python 2.5 will have it.
[22:29] <foom> so it provides no value
[22:29] <lifeless> I would be very unhappy if ubuntu didn't carry patches in advance of huge numbers of upstreams
[22:29] <foom> in advance is one thing, in opposition to is another
[22:29] <lifeless> -> #ubuntu-policy or something
[22:30] <igc> morning
[22:30] <lifeless> I've got some code to write, sorry.
[22:30] <foom> me too.
[22:30] <RainCT> bug 191694 reported
[22:30] <ubotu> Launchpad bug 191694 in bzr "bzr crashes commiting a branch from a directory with special characters" [Undecided,New] https://launchpad.net/bugs/191694
[22:30] <foom> my only point was: it should be filed against upstream python to make sure they're aware. didn't want to get into an argument. :P
[22:30] <lifeless> foom: my point was file it against ubuntu where the bug was observed; doko will do something sane from there.
[22:30] <RainCT> (the title is not very good but I couldn't think of anything better..)
[22:31] <lifeless> RainCT: thanks
[22:31] <foom> lifeless: great. we can agree to that point. :)
[22:32] <luks> ouch, some tests are failing is readlink returns unicode strings
[22:34] <RainCT> lifeless: np
[22:35]  * RainCT thinks that it would be better if some of you reported the bug in python as he isn't really understanding what's going on :P
[22:35] <luks> using %r in diff output is probably not a good idea, anyway
[22:35] <RainCT> well, good night
[22:35] <lifeless> night
[22:36] <ubotu> New bug: #191694 in bzr "bzr crashes commiting a branch from a directory with special characters" [Undecided,New] https://launchpad.net/bugs/191694
[22:39] <abentley> schierbeck: Actually, the patch parsing / applying code lifeless was referring to is in Bazaar: bzrlib/patches.py
[22:55] <schierbeck> abentley: thanks!
[23:04] <hipertracker> Is there any Baazar plugin for Eclipse, Netbeans6 or TextMate?
[23:05] <igc> poollie, jam, spiv: call?
[23:06] <mwhudson> hipertracker: there's at least something for eclipse
[23:07] <jam> igc: I don't want to talk to you, I just want to listen to the pretty music
[23:07] <igc> it's prettier today than normal for some reason :-)
[23:07] <igc> it's even bearable
[23:07] <jam> igc: I'll just enter the leader code, and we'll get done with it
[23:51] <pickscrape> Hi, does anyone know of a quick way to publish a fresh branch to a remote host?
[23:51] <LeoNerd> bzr push ?
[23:52] <pickscrape> The working copy is 384M, and the .bzr direcotry of my shared repo (containing just this branch) is 228M.
[23:52] <pickscrape> It's taking *ages*.
[23:53] <pickscrape> Well, it's taken about 40 minutes so far and the remote shared repo has reached 63M in size. Does that sound about right?
[23:53] <pickscrape> I'm using bzr+ssh. I'm just wondering if there's a way to speed it up. For example, tarring it up and using scp would be much quicker, but I doubt that it would put things in the right place.
[23:54] <LeoNerd> It should do
[23:55] <pickscrape> Even taking into account the shared repository?
[23:55] <LeoNerd> Oh.. hrm.. possibly not
[23:56] <LeoNerd> bzr push it locally to another local dir, then tar/scp that
[23:57] <pickscrape> Yeah, I'm thinking it's probably quicker to scp the raw WC to the server, and import and then branch locally to kick things off.
[23:57] <pickscrape> Thanks for the idea :)
[23:57] <pickscrape> My other question is, is it possible to do something like bzr branch <remote_url> <remote_url> to create a new branch remotely?
[23:57] <mwhudson> hard to beat tar.bz2 + scp for the initial transfer


[10:58] <BUGabundo> bons dias
[11:41] <artir> buenos días
[11:42] <BUGabundo> hola artir
[11:42]  * BUGabundo better stop it, before ppl think im spanish!
[20:41] <BUGabundo> hi everyone
[22:23] <BUGabundo> what is this I hear of U1 and FF sync ??


[06:26] <RAOF> Oh, I am going to be _so_ annoyed if it turns out that gcc on ppc64el optimises out our faulting reads :blobcat_angry:
[06:59] <Saviq> That was my suspicion, too - and why I tried `-O2`
[07:00] <Saviq> Also tried a debug build, didn't help
[07:09] <Saviq> RAOF (he/they): 👆
[08:43] <RAOF> Yeah, I think actually I wasn't rebuilding mir_unit_tests (even though it was rebuilding the test file I was editing?!)
[09:10] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq drafted [pull request #2796](https://github.com/MirServer/mir/pull/2796): debug
[09:15] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq closed [issue #2773](https://github.com/MirServer/mir/issues/2773): BadBufferTest.client_lies_about_buffer_size dies on PowerPC
[09:16] -GitHub[m]:#mir-server- **[MirServer/wlcs]** Saviq marked [pull request #259](https://github.com/MirServer/wlcs/pull/259): Release 1.5.0 as ready for review
[09:19] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq merged [pull request #2786](https://github.com/MirServer/mir/pull/2786): Better concatenation for pkg-config values, better use of GNUInstallDirs variables
[09:49] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq opened [pull request #2797](https://github.com/MirServer/mir/pull/2797): spread: alpine is at 3.17 now
[09:55] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [pull request #2798](https://github.com/MirServer/mir/pull/2798): Automate reloading display configuration... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/659f90951d84704ba815a2082b988c03f20a01b7>)
[09:56] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [pull request #2798](https://github.com/MirServer/mir/pull/2798): Automate reloading display configuration
[10:08] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [issue #2799](https://github.com/MirServer/mir/issues/2799): Occasional abort when exiting... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/1d6538ba55a225c6eee6dee710c7cc9731ada73f>)
[10:21] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq closed [pull request #2796](https://github.com/MirServer/mir/pull/2796): debug
[10:24] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq closed [pull request #2640](https://github.com/MirServer/mir/pull/2640): Only call extension filter once per app per extension
[11:13] -GitHub[m]:#mir-server- **[MirServer/mir]** OPNA2608 opened [issue #2800](https://github.com/MirServer/mir/issues/2800): Building docs fails when trying to not remove doc/html/cppguide: Is a directory... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a3d2a1aa3fbb08a12ef43458037d856bd5dc13f5>)
[11:14] <alan_g[m]> Saviq anything more we want in wlcs 1.5?
[11:15] <Saviq> alan_g no, I think we're good
[11:17] <alan_g[m]> OK, tagged
[11:52] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq reopened [pull request #2796](https://github.com/MirServer/mir/pull/2796): debug
[11:58] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2795](https://github.com/MirServer/mir/pull/2795): Document that extension filter callbacks are called multiple times
[12:48] -GitHub[m]:#mir-server- **[MirServer/wlcs]** AlanGriffiths published [v1.5.0: Release 1.5.0](https://github.com/MirServer/wlcs/releases/tag/v1.5.0)
[12:58] -GitHub[m]:#mir-server- **[MirServer/wlcs]** bors[bot] merged [pull request #259](https://github.com/MirServer/wlcs/pull/259): Release 1.5.0
[15:04] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2797](https://github.com/MirServer/mir/pull/2797): spread: alpine is at 3.17 now
[15:44] -GitHub[m]:#mir-server- **[MirServer/mir]** OPNA2608 opened [issue #2801](https://github.com/MirServer/mir/issues/2801): Some failing tests in Nixpkgs... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/1cf9a6a62ae8e35b4a8df986f9277bee8689cd3d>)
[16:14] -GitHub[m]:#mir-server- **[MirServer/mir]** graysonguarino assigned graysonguarino to [issue #2792](https://github.com/MirServer/mir/issues/2792): [23.04] swaybg requires a newer version of wl-output than we support
[16:15] -GitHub[m]:#mir-server- **[MirServer/mir]** OPNA2608 edited [issue #2801](https://github.com/MirServer/mir/issues/2801): Some failing tests in Nixpkgs
[16:29] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq assigned Saviq to [issue #2788](https://github.com/MirServer/mir/issues/2788): UdevWrapperDeathTest.DereferencingEndReturnsInvalidObject getting stuck in CI
[16:31] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq closed [pull request #2793](https://github.com/MirServer/mir/pull/2793): test new build-snap action
[16:35] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq assigned  to [pull request #2798](https://github.com/MirServer/mir/pull/2798): Automate reloading display configuration
[17:00] -GitHub[m]:#mir-server- **[MirServer/wlcs]** wmww opened [pull request #265](https://github.com/MirServer/wlcs/pull/265): XDG shell & layer shell: drop experimental from optional
[17:04] -GitHub[m]:#mir-server- **[MirServer/wlcs]** wmww edited [pull request #265](https://github.com/MirServer/wlcs/pull/265): Change remaining std::experimental::optionals to std::optional
[17:05] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww unassigned wmww from [issue #2792](https://github.com/MirServer/mir/issues/2792): [23.04] swaybg requires a newer version of wl-output than we support
[17:34] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths closed [pull request #2756](https://github.com/MirServer/mir/pull/2756): Spike dynamic display configuration
[17:38] -GitHub[m]:#mir-server- **[MirServer/wlcs]** bors[bot] merged [pull request #265](https://github.com/MirServer/wlcs/pull/265): Change remaining std::experimental::optionals to std::optional
[17:52] <Saviq> Good weekend all o/
[18:02] <alan_g[m]> Good weekend all o/
[20:00] -GitHub[m]:#mir-server- **[MirServer/mir]** musicinmybrain opened [pull request #2802](https://github.com/MirServer/mir/pull/2802): Add missing #include statements... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/17a17acf7c32dcbc8dded1ac0701788dda5d571f>)
[20:01] -GitHub[m]:#mir-server- **[MirServer/mir]** musicinmybrain pushed something to [pull request #2802](https://github.com/MirServer/mir/pull/2802): Add missing #include statements
[20:01] -GitHub[m]:#mir-server- **[MirServer/mir]** musicinmybrain edited [pull request #2802](https://github.com/MirServer/mir/pull/2802): Add missing #include statements
[22:03] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2802](https://github.com/MirServer/mir/pull/2802): Add missing #include statements


[01:52] <teward> do private PPAs work with add-apt-repository?
[01:54] <wgrant> teward: Unfortunately not. add-apt-repository has no way to authenticate.
[02:01] <teward> wgrant: that's what i thought
[02:02] <teward> (following up to an #ubuntu question >.<)


[12:09] <cjwatson> wgrant: Is it intentional that AccessArtifact has FKs for bug and specification, but not branch?
[12:10] <cjwatson> wgrant: Just tracking down the IntegrityError I found when QAing https://bugs.launchpad.net/launchpad/+bug/1456583, and wondering why Branch.destroySelf apparently doesn't need to clean up its AAs
[12:10] <mup> Bug #1456583: Can't delete Git repositories <feature> <git> <qa-needstesting> <Launchpad itself:Fix Committed by cjwatson> <https://launchpad.net/bugs/1456583>
[12:12] <cjwatson> I wonder if there are leftover AA rows for now-nonexistent branches as a result.
[12:20] <wgrant>     bug integer REFERENCES bug,
[12:20] <wgrant>     branch integer, -- FK to be added later.
[12:22] <wgrant> Something must have been checking for branch FKs.
[12:24] <wgrant> APGF.grantee is the only other one from that patch that wasn't fixed later.
[12:36] <wgrant> Oh, no
[12:36] <wgrant> APGF.grantee is deliberately not FKed, I think, because it shouldn't be touched by person merge.
[12:36] <wgrant> It's purely maintained by triggers.
[13:10] <cjwatson> So do I need something like getUtility(IAccessArtifactSource).delete([self]) ?
[13:11] <cjwatson> One of these days I will properly understand the access model :)


[06:52] <alkisg> stgraber: I've started doing some ltsp packaging changes: http://bazaar.launchpad.net/~alkisg/+junk/ltsp/changes
[06:54] <alkisg> I left the nbd-server configuration change for later on, because I'd like to talk again about what part is packaging and what is dynamically generated by ltsp-update-image


[02:23] <BUGabundo> $ sudo echo snoozzz | /proc/cpuinfo
[13:04] <facundobatista> Hi all
[13:08] <jblount> facundobatista: Good morning to you!
[13:08] <facundobatista> jblount, :)
[13:20] <statik> hello world
[14:52] <urbanape> happy wednesday
[14:52] <popey> It is!
[14:54] <urbanape> so, following up on #387772
[14:55] <urbanape> the initial bug report said he couldn't access his "Shared with Me" files. Unless he deleted them locally and that synced upstream, he should still be able to get to them, yeah?
[14:58] <dobey> urbanape: even then, if he didn't have write access granted to those files, they should just get re-downloaded i think (unless there's a bug where they don't), and would certainly see them in the web ui
[14:59] <urbanape> I'll follow up with him in email and get some more info
[15:01] <jblount> MEETING BEGINS
[15:02] <jblount> Hi, everyone who is here for the ubuntu one developer standup, please say 'me'. The format for this  meeting is to paste 3 lines: TODO, DONE, and BLOCKED. Then say the person that should go next - we can  try going in 'me' order.
[15:02] <jblount> me
[15:02] <urbanape> me
[15:03] <jblount> dobey, statik, CardinalFang, rodrigo_: ping
[15:03] <rodrigo_> jblount: pong
[15:03] <rodrigo_> me
[15:03] <CardinalFang> me
[15:04] <jblount> Better to get started, and let folks jump in when they get a chance...
[15:04] <jblount> DONE: Landed the file storage stats branch (and helped fix a rollout related bug with mthaddon)
[15:04] <dobey> sorry
[15:04] <jblount> TODO: Pair on /files/new with urbanape, small branch with a few minorish text and css fixes, asking about about making squid rollout proof
[15:04] <dobey> me
[15:04] <jblount> BLOCKED: Nope.
[15:04]  * jblount passes to urbanape
[15:04] <urbanape> DONE: Face duty, blueprint, specs, and skeletal firefox extension for ubuntuone-firefox-bookmark-sync, handoff-meeting with jblount and pfibiger on /files/new UI.
[15:04] <urbanape> TODO: Flesh out FF extension, get blueprint into review state, pair with jblount on /files/new UI
[15:04] <urbanape> BLOCK: Nada
[15:04] <urbanape> rodrigo_: your turn
[15:05] <rodrigo_> done: added missing blueprints for couchdb-in-the-desktop stuff, some evo-couchdb fixes and working on packaging them
[15:05] <rodrigo_> todo: face duty this afternoon (swapped with aquarius), more packaging in my PPA
[15:05] <rodrigo_> blocked: none
[15:05] <rodrigo_> CardinalFang: yours
[15:05] <CardinalFang> First is statik's message, since he's not here.
[15:05] <statik-puppet> DONE: python-testtools passed REVU and has been uploaded. lots of phone calls, a couple of branch reviews, design review for firefox plugin with urbanape.
[15:05] <statik-puppet> TODO: lots of phone calls and scrambling for Karmic Feature Definition Freeze today. Screensharing design review, work on OOPs with pfibiger, look at glib-couchdb with rodrigo.
[15:05] <CardinalFang> BLOCKED: None
[15:05] <CardinalFang> DONE: reviewed branches.  more work on mail queueing -- just need tests now, and to figure out config file for zope.sendmail .
[15:05] <CardinalFang> TODO: get tests to run, damnit.
[15:05] <CardinalFang> BLOCKED: None.
[15:05] <CardinalFang> dobey, you!
[15:06] <dobey> DONE: Lots of client build system hacking (almost done)
[15:06] <dobey> TODO: Finish build system and package changes, move share creation via web api code to syncdaemon, split ubuntuone-client packaging, backport python-oauth
[15:06] <dobey> BLCK: None.
[15:06] <dobey> nobody else?
[15:06] <jblount> dobey: I think that's it.
[15:06] <jblount> END OF MEETING
[15:07] <rodrigo_> so statik is not around?
[15:07] <dobey> statik is in a call
[15:10] <rodrigo_> ok
[15:16] <jblount> Hmm. pidgin is back to hardlocking my system. I wonder why it hates me.
[15:16]  * jblount hugs empathy
[15:17] <urbanape> rodrigo_: you're face just for the afternoon?
[15:18] <rodrigo_> urbanape: yeah, aquarius swapped it this morning with me
[15:18] <rodrigo_> he is sprinting, so really needed someone to take it over
[15:18] <rodrigo_> so we are just swapping half day :)
[15:18] <urbanape> k, I cc'd my notes (sparse as they were) to the discussion list
[15:19] <rodrigo_> urbanape: yeah, reading them now
[15:21] <rodrigo_> ok, now #2 task: change the topic, who can do it?
[15:24] <jblount> rodrigo_: rmcbride can, but I think we decided it wasn't a huge deal.
[15:25] <rodrigo_> ah ok
[15:25] <rodrigo_> it's nice, if there are difficult questions, I can just pretend to not read them :)
[15:27] <jblount> rodrigo_: ;)
[15:28] <dobey> rodrigo_: i would like to point out that everyone can see you now :)
[15:28] <rodrigo_> ugh! :D
[15:29] <dobey> you have been logged :P
[15:33] <rodrigo_> damn!
[16:03] <rodrigo_> hmm, we use GNOME's proxy settings in the u1-client programs, right?
[16:03] <dobey> no
[16:03] <rodrigo_> well, I guess we don't
[16:03] <rodrigo_> right, ok
[17:07]  * jblount goes looking for food
[17:11] <rodrigo_> so, yeah, too quiet today in here. It was a joke what I said before, you can ask questions  :)
[17:18] <dobey> heh
[17:25] <rodrigo_> ok, keep your questions for later then, I'll be back :)
[17:28] <JayMP> How popular is the beta testing - is there a long queue for invitations, anyone knows?
[17:31] <jblount> JayMP: We do have a pretty large queue, I don't think we've published a specific numbe.
[17:32] <JayMP> OK, it is a great idea. I use Dropbox for work and using several machines it is very useful! Can't wait for an "indigenous" Ubuntu solution..
[17:32] <jblount> JayMP: :)
[17:37] <dobey> let's just say our queue is very large :)
[17:51] <dobey> rodrigo_: hey. you shouldn't set the bugs to confirmed unless you've reproduced them. generally bugs that are unassigned should stay in the "New" state
[19:03]  * statik code reviews https://code.edge.launchpad.net/~dobey/ubuntuone-client/nautilus-no-python/+merge/7565 and is excited about seeing source tarballs up soon
[19:05] <statik> i wish launchpad required you to set the commit message when you proposed a branch for merging
[19:09] <urbanape> pfibiger: you aboot?
[19:10] <dobey> i think he's a person, not a boot
[19:11] <urbanape> Having never met him, I can neither confirm nor deny
[19:12] <urbanape> The voice I spoke with yesterday could easily have been computer generated
[19:12] <urbanape> we're poking around in the new files ui.
[19:14] <statik> hey dobey, i'm having failures in https://code.edge.launchpad.net/~dobey/ubuntuone-client/nautilus-no-python/+merge/7565 I just wrote the details in the merge proposal. configure is unhappy with my versions of libsoup2.4-dev and nautilus-extension-dev
[19:14] <statik> are you specifying certain versions of those libs, or do they get generated from somewhere else? I'm wondering if I've got a karmic system that has some updates but is missing others
[19:15] <dobey> statik: i think that's a bug in gnome 2.27 stuff, and thus karmic :)
[19:15] <statik> also, is libsoup for parsing html/json? if so, is it still needed as a dep?
[19:16] <dobey> statik: there shouldn't be any @FOO@ text in any pkg-config files in an installed system. that should have been replaced at build time by whatever package (presumably nautilus or one of its deps)
[19:16] <dobey> libsoup is for HTTP
[19:17] <dobey> i can probably remove it, when i move the create share code over to syncdaemon, that is currently disabled in the C version of the extension
[19:17] <statik> cool
[19:17] <statik> that makes sense
[19:17] <dobey> but there is some starter code that still depends on it
[19:18] <dobey> i'll make another quick branch to remove libsoup, after i get this in :)
[19:18] <statik> great. i'm trying to update my packages now to see if I can get it to build
[19:25] <pfibiger> urbanape: i am. what's up?
[19:27] <urbanape> heya, jblount and I are just poking around the new files UI stuff. As we stumble through, we'll probably poke you with some questions
[19:33] <statik> great, now inkscape is segfaulting during the build
[19:34] <dobey> statik: i'm going to poke on karmic as well
[19:34] <statik> dobey, after updating my packages again (i had updated last night) i was able to get through configure. trying the rest of it now
[19:34] <dobey> statik: ok, cool
[19:36] <statik> dobey, crazy question: when this new package is installed, will it remove the old .pyc file from the nautilus python extension directory?
[19:36] <statik> for people who had older versions of the package installed?
[19:36] <statik> i've been wondering whether something like that was the cause of use getting those bug reports about stuff crashing in code that we had deleted long ago
[19:37] <dobey> statik: i think the debian python magic will do that when the old package gets removed, before the new one gets installed
[19:37] <dobey> statik: ie, the pyc don't get left around now when you just uninstall, do they?
[19:38] <statik> i hopes not
[19:38] <dobey> statik: though i don't know if it necessarily works the same with upgrades... hrmm, let me see
[19:39] <dobey> i'll see what happens as soon as soon as my karmic install finishes upgrading
[19:41] <statik> dobey, thanks! say, do you get lots of warnings about mismatched quotes at line 209 in ../canonical/ubuntuone/storage/syncdaemon/fsm/fsm_parser.py (and many other files) when running make check?
[19:42] <dobey> yes
[19:42] <statik> beautiful
[19:42] <statik> i'm happy with this branch
[19:43] <dobey> it's from intltool-update, because perl doens't handle """ """ in python very well
[19:43] <dobey> there's a long standing bug on it
[19:43] <statik> dobey, should I wait to mark it as approved until kenvandine reviews it?
[19:43] <dobey> i don't know if he has time to review it
[19:44] <kenvandine> dobey, i can in like 5 minutes :)
[19:44] <kenvandine> or 10
[19:44] <kenvandine> :)
[19:44] <dobey> ok
[19:45] <statik> kenvandine, you'll love this branch, it spits out tarballs so stuff can be packaged for foresight :)
[19:45] <kenvandine> woot
[19:45] <statik> dobey, is there a similar branch for ubuntuone-storage-protocol?
[19:47] <dobey> statik: no, we're not porting anything to C in there (yet anyway) :)
[19:48] <dobey> i already fixed storage-protocol by adding the MANIFEST.in, so we can make tarballs with setup.py sdist there
[19:49] <statik> dobey, that makes perfect sense. you know, i really should have remembered that considering that I was examining the tarballs coming from setup.py sdist in ubuntuone-storage-protocol yesterday
[19:49] <dobey> heh
[19:49] <dobey> it's been a busy 2.5 days :)
[19:51] <BUGabundo> boas noites
[19:54] <kenvandine> dobey, sorry... few more minutes :/
[19:56] <rmcbride> statik: dobey: once the 0.90.2 tarballs are in place I will change the package build scripts for the PPAs to use diff.tar.gz magic etc, now that I understand the process.
[19:57] <dobey> cool
[19:57] <statik> rmcbride, cool. I think the package also needs to be uploaded to REVU, dunno whether you or dobey want to do that
[19:58] <statik> then once it's accepted we'll have to figure out how to ask for new uploads
[19:58] <dobey> i was going to upload some 0.90.2 release packages to revu
[19:58] <statik> perfect
[19:58] <rmcbride> statik: we'll want to put the tarballs up for REVU (dobey should probably do this) and if we do new uploads we'll do the diff.tar.gz stuff
[19:58] <dobey> i think the process is roughly the same for new uploads
[19:58] <rmcbride> statik: basically 0.90.2 will be the "orig.tar.gz" for that workflow
[19:59] <dobey> well new uploads into karmic we will roll new tarballs for
[19:59] <statik> rmcbride: whenever we build new source tarballs we'll need new orig.tar.gz though, yes?
[19:59] <statik> right
[19:59] <rmcbride> statik: right
[20:00] <rmcbride> dobey: yea the new tarballs would be generated similarly to how I did the upload for python-configglue, workflow wise.
[20:02] <dobey> ah, i don't know what you did there :)
[20:04] <rmcbride> dobey: I've got a handle on it. Once I figure out how to explain it I'll have a doc up somewhere. The fact that you added the bits for generating the source tarball makes the whole thing much easier to keep consistent
[20:04] <dobey> right
[20:05] <rmcbride> dobey: basically we're thinking along the same lines and my technical language ciruits are a bit fuzzed today so it probably sounds like I'm talking gibberish(er tahn usual) :)
[20:05] <dobey> it still needs some fixes (because as a rule, 'make distcheck' should not fail, but am using some hacks at the moment to integrate with distutils, which break that)
[20:05] <dobey> speaking of gibberish
[20:06]  * dobey goes to pop in Brazil for some entertainment while working
[20:06] <rmcbride> Yea caught that in the review submission.
[20:09] <dobey> hi there, i want to talk to you about ducts
[20:11] <kenvandine> dobey, ok... ready
[20:11]  * kenvandine looks
[20:13] <kenvandine> dobey, that's a big diff :)
[20:13]  * kenvandine is reviewing
[20:14] <dobey> yes, yes it is
[20:18] <dobey> hrmm, i wonder what new stuff Ian Holm is in
[20:18] <statik> kenvandine, if you ignore the deletes its a lot easier to digest
[20:18] <BUGabundo> dobey: so what do you have against gwibber?
[20:19] <dobey> BUGabundo: i don't have anything against gwibber
[20:20] <BUGabundo> oh
[20:20] <dobey> outside of it being yet another app where i have to enter all the same information i entered in some other app
[20:20] <BUGabundo> ahah
[20:20] <dobey> and the ui doesn't really fit my ideal workflow
[20:20] <dobey> but that first one will be fixed in due time
[20:20] <dobey> with new ducts
[20:21] <BUGabundo> yeah
[20:21] <BUGabundo> I know
[20:21] <BUGabundo> I've been following the devel since the beginning
[20:26] <dobey> katherine helmond hasn't been in anything recently either
[20:31] <urbanape> dobey: he was Bilbo
[20:31] <urbanape> Polonius
[20:31] <dobey> i know he was bilbo
[20:32] <dobey> but that was in 2003 :)
[20:32] <urbanape> well, you were talking about Brazil.
[20:32] <urbanape> it's newer than that
[20:32] <dobey> well, i'm watching brazil now
[20:32] <lamalex> the movie?
[20:32] <dobey> yes
[20:32] <lamalex> lve that movie
[20:32] <dobey> indeed
[20:33] <lamalex> tax time is non-stop brazil references in my apt
[20:33] <dobey> ah crap
[20:33] <dobey> hrmm
[20:33] <dobey> statik: make check passed for you?
[20:34] <statik> dobey, it bombed on not finding ubuntuone-storage-protocol because my system is currently a pile of unassembled branches
[20:35] <statik> dobey, i was happy with the contents of the tarball i got from make dist though
[20:35] <dobey> statik: haha, well, it bombed on me because i made a mistake :)
[20:35] <dobey> but i'll fix that and push real quick
[20:35] <statik> bad reviewer
[20:36] <statik> alright, just pushed my first mercurial changeset to bitbucket, fixing up the licensing for the spawning wsgi server
[20:36] <statik> maybe tomorrow i can figure out git and help rodrigo with glib-couchdb
[20:37] <dobey> i'm an upstream gnome maintainer, and i still haven't figured out git
[20:40] <urbanape> pfibiger: did you do the initial migration for the new files UI? I'm stumped on how individual record rows decide how to render their individual columns. Just based on the columnsDef?
[20:42] <kenvandine> dobey, git is really making my head hurt
[20:42] <urbanape> kenvandine: anything in particular?
[20:42] <dobey> kenvandine: indeed. notice how i've moved stuff off gnome.org, and how i haven't made any 2.27.x releases of gnome-icon-theme or evolution-webcal yet :)
[20:42] <statik> CardinalFang, btw ^ I just sent donovan the licensing patch for spawning, so as soon as he uploads a tarball with those changes to pypi I will be able to get a package up onto REVU, which will make it much easier for us to use spawning to run the web servers.
[20:43] <dobey> i hope the answers are on live.gnome.org, but i haven't had time to search for crap on there either
[20:43] <kenvandine> urbanape, just a pain to use compared to mercurial and bzr
[20:43] <pfibiger> urbanape: yeah, based on fileColumnDefs
[20:43] <kenvandine> urbanape, basically it is a bit harder to remember how to do stuff
[20:43] <CardinalFang> statik: Roger.  I pushed it back onto my queue.  Someone triaged it as "later".
[20:43] <kenvandine> hg and bzr are just very intuitive... and git seems like it is designed by people that hate me :)
[20:44] <urbanape> pfibiger: so, how does the checkbox column get disassociated with the label in the columnDefs?
[20:44] <kenvandine> dobey, did you see my comment on the merge request?
[20:44] <statik> CardinalFang, oh right. that was the big ol' script removing all the bugs from beta2 when we switched to more granular milestones. it should probably go into w09 or the next one
[20:45] <dobey> kenvandine: meh. ok :)
[20:47] <urbanape> kenvandine: I guess I was just getting used to it when I left Slate, but yeah, it seemed to capriciously rename defacto standard commands to be intentionally obtuse.
[20:47] <urbanape> although I don't have bitkeeper experience, maybe it was designed to mimic it?
[20:47] <statik> nah, git was designed to not look like bitkeeper. bk was actually pretty nice to use
[20:48] <dobey> git was designed (or rather, not designed so much) to not be like anything else
[20:48] <urbanape> it succeeded
[20:49] <kenvandine> yeah
[20:49] <dobey> git is like a perfect example of -ESUCCESS
[21:01] <kenvandine> dobey, ImportError: No module named protocol.oauth
[21:01] <kenvandine> in make check
[21:02] <dobey> kenvandine: ls -ld canonical/ubuntuone/storage/protocol ?
[21:02] <kenvandine> notta
[21:10] <dobey> kenvandine: added some updates per your comments, went ahead and removed the libsoup dep, and fixed that :)
[21:10] <kenvandine> rodrigo_, btw, your specs look good to me
[21:10] <kenvandine> dobey, ok
[21:12] <kenvandine> ln: creating symbolic link `canonical/ubuntuone/storage/protocol': File exists
[21:12] <kenvandine> dobey, ^^
[21:12] <kenvandine> perhaps that is something make clean should remove?
[21:12] <dobey> make clean does remove it
[21:13] <kenvandine> i get that on make check
[21:13] <kenvandine> rm -f canonical/ubuntuone/storage/protocol
[21:13] <kenvandine> indeed
[21:13] <dobey> and the rule to create it has an if to check that it doesn't exist
[21:13] <kenvandine> hmmm
[21:13] <dobey> if [ ! -e canonical/ubuntuone/storage/protocol ]; ...
[21:13] <kenvandine> blowing up here
[21:14] <dobey> weird
[21:14] <dobey> do you have conflicts or something?
[21:15] <kenvandine> nope
[21:17] <dobey> i just ran make check twice and it works fine
[21:17] <dobey> hrmm
[21:19] <kenvandine> :/
[21:20] <kenvandine> make by itself fails too
[21:20] <kenvandine> same error
[21:23] <dobey> does that file actually exist?
[21:26] <kenvandine> yes
[21:26] <kenvandine> it is getting linked
[21:26] <kenvandine> no idea where though
[21:27] <dobey> if you remove it, and run make twice, does it still fail?
[21:27] <kenvandine> yes
[21:27] <kenvandine> make clean removes it too
[21:28] <dobey> and it still fails?
[21:29] <dobey> your filesystem is weird!
[21:31] <kenvandine> dobey, yup :)
[21:31] <kenvandine> i have to run though... kids swim meet
[21:31] <kenvandine> will look more when i get back
[21:32] <kenvandine> oh... it fails on make check... if i remove it and run make
[21:32] <kenvandine> it works
[21:32] <kenvandine> running make a second time fails
[21:32] <dobey> ok
[21:32] <kenvandine> that if statement isn't working :)
[21:32] <dobey> weird
[21:32]  * kenvandine runs
[21:32] <dobey> your filesystem is lying :)
[21:33] <dobey> you must be using xfs or something weird
[21:56] <dobey> sigh
[22:07] <amackera> hello all, is there any documentation or developer examples for the ubuntu one API, or will that appear closer to production release?
[22:11] <dobey> there are some examples in ubuntuone-storage-protocol, and there is the main client itself
[22:13] <rodrigo_> dobey: from https://wiki.canonical.com/UbuntuOne/BugTriage, I understood confirmed is not only for bugs I can replicate
[22:13] <rodrigo_> kenvandine: cool, have you approved them?
[22:15] <dobey> rodrigo_: "can confirm the bug" means "you see it too" and not "this makes sense that it would be a bug"
[22:15] <dobey> rodrigo_: perhaps that could use a little clarification though
[22:15] <rodrigo_> dobey: yeah, because triaged is not a good default value
[22:16] <rodrigo_> dobey: if we have to keep then as 'New', we should have that on the wiki page
[22:18] <dobey> default value? "new" is the default
[22:18] <amackera> dobey: thanks!