[00:00] beuno: OOI why Postgres over MySQL? [00:02] Odd_Bloke, because that's what I've been working for the past 6 years :) [00:02] I'm not saying that should be *the* backend [00:02] it's just easier for me to start with that, implement it, and then jump to pg [00:02] beuno: My question was the other way around. :p [00:02] Or, why is Postgres the end goal? Won't MySQL be good enough? [00:03] Odd_Bloke, ah, sorry, was expecting a MySQL bashing :p [00:03] yes, MySQL should be good enough, but I suspect PG will be prefered from people coming from LP [00:08] has anyone here installed turbogears on leopard? [00:08] beuno: Ah, yeah, that hadn't occurred to me. [00:08] without wanting to maim someone (possibly themselves) [00:22] Odd_Bloke: Yeah, familiarity with PG, and I understand that PG is a more correct SQL implemplementation. [00:24] abentley, any idea why I would get this while voting? http://paste.ubuntu.com/13751/ [00:25] Your account doesn't have any submitter associated with it, I would imagine. [00:25] If you used the create_account script, that shouldn't have happened. [00:26] I did [00:26] I'll clean the DB and try it again [00:27] It looks as though the submitter list is optional, but you should have at least one. [00:27] abentley: Well, there's certainly an argument that being a correct SQL implementation isn't necessarily a good thing. :p [00:27] * Odd_Bloke had Hugh Darwen teach his Intro to Databases course, and has disliked SQL since. :D [00:44] beuno: How do you want this sqlite file? Email? [00:45] abentley, email is fine, yes [00:45] abentley: Might be worth putting it somewhere several people can get, if it could aid development... [00:46] Odd_Bloke: Okay. [00:46] hrm, I'm making some progress with moving over the data, although I'm not sure how I'm going to automate some steps [00:47] I've got *most* tables in mysql with data [00:47] beuno: What approach are you taking? [00:47] abentley, exporting the SQL db, replacing known differences between sqlite and mysql queries, and dumping into the mysqldb [00:48] beuno: Are you prepared to deal with binary data that way? [00:49] abentley, AFAIK, binary data should be dumped and imported correctly, but I'll get back to you when I actually test it :) [00:49] that would be mainly for patch_text, right? [00:49] beuno: There are some UTF16 files in there. [00:49] IIRC. [00:51] abentley, I'm going to aim at getting all the tables created and data fully imported into them, and then start to check consistency [00:51] that's where the bzr db will come in handy :) [00:54] I'm going to head home now to get something to eat, but I'll be back in a while, I'm curious to see how far I can get without running into substantial blocker [01:20] beuno: http://code.aaronbentley.com/bundlebuggy/devdata.sqlite.nopasswords [01:23] abentley, great, thanks! I'll use that as soon as I get mysql to create all the tables correctly (already home) === abadger1991 is now known as abadger1999 [01:47] how does bzr treat symlinks by default? [01:47] i made a change to a symlink file and i noticed that bzr commit didn't list the file as changed [01:49] if the symlink and destination are versioned by bzr, it should work (and does for me) [01:58] abentley, I haven't tried with the bzr db, but with small adaptations to the table structure, and replacing a few characters from the sqlite dump, data seems to get imported correctly into mysql. I'm leaving for a few hours, and hopefully I'll be back to test it against the bzr db [01:58] (I imported the blobs from sqlite, and they seem to get imported correctly) [01:59] Well, that sounds promising. [02:31] morning === mw is now known as mw|oug === mw|oug is now known as mw|out [02:47] poolie: Thanks for your emails re file categories. I've emailed the list with my latest thoughts so I'd be keen for you to consider them when times permits. [02:55] poolie: here [03:08] beuno: I've updated the docs. [03:21] * igc lunch [05:44] * igc pick up kids [05:44] ZOMG netsplit. [06:57] hello lifeless [06:57] lifeless: could you look at balleny again if you get a chance or ask a sysadmin to do so, it's still ridiculously slow [06:59] poolie: will nag === You're now known as ubuntulog [08:23] liw: how is the rsync?\ [08:23] lifeless, the big pack file has about 43 more hours to go, and then there's another 227 thousand more files [08:24] are you copying the working trees? [08:24] nope [08:24] strange [08:25] let the big file finish [08:25] then stop the rsync, and do 'for branch in branches; bzr zap-tree $branch' [08:26] ack [08:26] "zap-tree"? [08:26] something like [08:26] remove-tree, zapt-ree, I dunno [08:27] remove-tree. [08:27] zap-tree would be a useful alias. "remove-tree" is long. [09:13] * igc dinner [09:15] * gour wonders why igc always has dinner so early...we hardly took a breakfast here [09:21] timezones ftw [09:22] timezones? i thought there is no life out of the europe [09:23] * gour is joking a bit...holiday is here today ;) [09:48] .THIS .OTHER .BASE - is there a doc describing them anywhere? [09:50] mtaylor: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#resolving-conflicts [09:50] mtaylor: "bzr help conflicts" === pmezard_ is now known as pmezard [09:51] Hmm, test_35_wait_lock_changing has bitten me twice today. [10:10] <[reed]> How does bzr compare to this? http://quotes.burntelectrons.org/3715 [10:13] [reed]: ideally, you don't rebase, but merge instead [10:14] but if you really must, there is a plugin, so you can do just 'bzr rebase' [10:14] or just pull [10:14] LarstiQ: I guess the situation is that you have a committed change and you want to pull [10:14] at least that's what I understood from the hg sequence of commands [10:14] luks: that explains the need for rebase, the 'cvs up -A' is a bit misleading though [10:15] er, I meant ;'and you want to push' [10:16] <[reed]> yeah [10:16] <[reed]> k, thanks [11:14] [reed]: ouch, that quote hurts my eyes [11:19] <[reed]> lifeless: hehe [12:08] lifeless: fail. :/ dapper chroot is <1s on my laptop [13:17] elmo: garh [13:43] should bzr build-depend on the pyrex stuff? [13:44] nm [13:45] no === mw|out_ is now known as mw [14:19] abentley: ping === mw is now known as mw|bbiab [14:27] hello people [14:30] http://pastebin.ubuntu.com/13848/ [14:30] some idea? [14:31] launchpad /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown] [14:34] Think that's fixed in newer bzr. 1.5 should have it. [14:34] bug 217701 [14:35] Launchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix released] https://launchpad.net/bugs/217701 [14:37] fullermd: uhm [14:38] i think no [14:38] http://pastebin.ubuntu.com/13849/ [14:38] i have newest bzr [14:38] No, you have 1.3.1. [14:38] 1.5 has the fix. [14:38] uhm just a moment [14:38] uhm true [14:38] Coffee. Blame it on lack of coffee :) [14:39] :) [14:40] lifeless: "fixed" [14:40] best non-solution ever [14:41] jml: pong [14:43] abentley: I've got a patch to the stacked branch stuff that only really makes sense to apply to your branch. [14:43] abentley: it make BzrDir.clone() also clone stacked_on information. [14:44] jml: Wouldn't it also make sense to apply to Robert's branch? [14:45] abentley: logically yes. I haven't tried applying it though. [14:47] thumper and I haven't discussed what he wants me to do vis-a-vis an integration branch, but I'm happy to look it over. [14:49] abentley: http://pastebin.ubuntu.com/13853/ [14:49] abentley: lifeless paired with me to do that, fwiw. [14:54] So I guess the main concern I have is whether "push" uses clone or sprout. === mw|bbiab is now known as mw [15:47] elmo: new kernel? [15:50] * lamont idly wonders why the ppa archive for bzr doesn't bother with a bzr_1.5.0.orig.tar.gz [15:50] admittedly, bzr_1.5.0-$mumble.tar.gz is only 3.5MB, but still... [15:51] Is the PPA archive suitable for debian users, or is it Ubuntu only? [15:51] installing ubuntu debs on debian and vice versa is an action that is fraught with peril. [15:52] OTOH, bzr_1.5-1 is in sid [15:52] What's sid? [15:52] debian unstable [15:52] and I rather expect that someone has tossed it at backports.debian.or [15:52] g [15:53] * pickscrape is a debian distro noob. Long time gentoo user. [15:53] lifeless: yea, that 'fixed' it - it's still reproducable on tungsten, which is edgy (2.6.17.4) [15:53] welcome to the fold [15:57] * lamont rotfl at the bzr packaging using quilt. [16:03] nfw [16:03] hi there! [16:03] hi Psy|ecimTech [16:03] Just a quick question :P [16:05] I'm playing a bit using the smart server, but seems that when I kill the process, the 4155 port remains open. [16:05] So, next time I fire up the server, I get this error: error: (98, 'Address already in use') [16:06] Oh, now its ready, seems that it takes time to close up the port on ubuntu [16:07] Looks like the smart server may not be setting the SO_REUSEADDR option; I'll check. [16:08] Yep, seems that you must wait for a timeout to reuse the port [16:09] Indeed the SO_REUSEADDR socket option isn't being set. [16:10] Wait, I'm not looking at the latest code. [16:12] BTW, whe are playing a bit versioning thru smart server on windows <-> ubuntu 64. [16:13] If you're running a smart server on Ubuntu, why not use bzr+ssh instead? [16:14] (I'm waiting on a checkout of bzr trunk so I can see if the smart server sets SO_REUSEADDR in the latest revision.) [16:15] Oh, we're just starting, and just avoid any problem on windows side... [16:19] Looks like the smart server sets the SO_REUSEADDR option in bzr trunk. Anyone know when this was done? [16:20] Psy|ecimTech: What version of bzr are you running on the Ubuntu machine? [16:21] Wait a minute, the Ubuntu guy is just comming in [16:21] there! [16:22] The SO_REUSEADDR fix was done on 2008-04-21. [16:23] Gus_Tronador: -> MattCampbell: Psy|ecimTech: What version of bzr are you running on the Ubuntu machine? [16:23] Gus_Tronador: -> MattCampbell: The SO_REUSEADDR fix was done on 2008-04-21. [16:23] So it should be in 1.5. [16:23] Seems to be 1.3.1 [16:24] Could it be a RC? [16:24] An update to 1.5 should fix the problem. [16:24] 1.5 came out a few days ago. [16:25] BTW, I'm a bzr newbie too, so maybe what I'm saying is obvious to everyone else here. [16:26] No, thats great, but seems that ubuntu's repo is still not updated to the latest [16:27] * MattCampbell looks on packages.ubuntu.com [16:27] you can use https://launchpad.net/~bzr/+archive [16:28] ahhh great! [16:47] Hello! ... I'm using BZR in ubuntu 8.04 Hardy Heron and I have an issue with "bzr server" ... When I run it from console and I stop it with "ctrl+c" socket remains open or address-port 0.0.0.0:4155 remains binded to socket [16:47] so ... I wish I could unbind it to restart server. Could someone please help me? [16:48] (when I try to re-run "bzr server" I get : "bzr: ERROR: Cannot bind address "0.0.0.0:4155": Address already in use." ) [16:50] heh [16:51] Gus_Tronador: someone just mentioned this problem half an hour ago :) [16:51] Gus_Tronador: it should work after a couple minutes. [16:52] Gus_Tronador: oh, and it seems to be fixed in bzr 1.5, according to conversation that just happened [16:54] radix: I think it wasn't fixed in 1.5 because I'm using that version :( ... address-port remains binded for a couple of minutes [16:54] radix: and after those minutes I can restart server. [16:55] Gus_Tronador: you're using the final version of 1.5? [16:55] maybe it's not in a release yet [16:57] WFM on Ubuntu with bzr.dev. [16:57] (I dunno if I have 1.5 installed.) [16:58] Well. [16:58] Yeah, WFM in 1.5 too. [17:03] hi [17:05] in our ssh configuration we had a limitation that people can only run "/usr/bin/svnserve -t" [17:06] what command is needed to allow them to use bzr smart server? [17:06] bzr server [some args] [17:06] Er, 'serve'. [17:07] "serve" ? [17:07] it starts the bzr server [17:07] i am talking about bzr+ssh:// [17:07] Same thing. [17:07] It uses serve --inet [various others... --allow-writes at least, --directory=/ maybe? Not sure] [17:08] Yeah, --directory / is among them. [17:08] so i just edit .ssh/authorized_keys [17:08] i need some help (in order to provide bzr completion for fish shell) how is bzr help formatted, i.e. in string "-v, --verbose Display more information." [17:08] and add "bzr serve --directory=/ --allow-writes" there [17:09] ...space is used between short & long option, but what about long option and description? [17:09] ignas: Don't forget --inet. [17:15] gour: have you seen "bzr shell-complete"? [17:16] james_w: no, i'm figuring out where and how are helo topics generated [17:18] james_w: shell-complete misses descriptions [17:19] james_w: see http://rafb.net/p/7k94LV34.html - this is the fish (shell) function which generates tab completion for several (D)VCSs, bzr is missing :-( [17:19] hg is covered with case '*' === beuno_ is now known as beuno [17:54] getting a weird error doing a bzr status on a branch on an NFS mount: [17:54] /usr/lib/python2.5/site-packages/bzrlib/dirstate.py:237: DeprecationWarning: struct integer overflow masking is deprecated [17:54] , st.st_dev, st.st_ino & 0xFFFFFFFF, st.st_mode))[:-1] [18:11] Can I cherry-pick changes to commit? === abadger1991 is now known as abadger1999 [18:44] Laney: iirc the record plugin can do that [18:44] demod: I found bzr shelve, looks to do what I want [18:45] Laney: kk [18:45] hm, it was the interactive-plugin anyway... ,) [19:01] lifeless: ping, loom breaks the bzr test suite (6 test failing related to push), should I file a bug ? [19:09] vila: sure [19:11] lifeless: damn, I was hoping you would have say: "Holly cow! I'll fix that right *now*" ;-) [19:18] vila: I'm fixing 'why does gdm not list latin as a language even though I clicked on latin int he various gui thingys' === mw is now known as mw|food [19:28] lifeless: gee [19:32] abentley, ok, after a few hours of cursing, I've got the SQL to create the tables in MySQL, and, a problem while importing the bzr DB, due to single quotes in BLOBs [19:33] Yeah, that's the kind of thing I ran into with that approach. [19:33] I'll have to look into other ways of exporting data from sqlite, but I've got a reproducible list of changes to the sqlite dump that make it "mysql-importable" [19:33] vila: https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/234101 [19:33] Launchpad bug 234101 in gdm "Support latin locale" [Undecided,New] [19:35] abentley, I'm going to get some work done, and try a different approach [19:37] I went though a lot of pain moving our trac installation from SQLite to Postgres because of string quoting issues [19:38] Shortly after I muddled through it myself, they released an offical migration script [19:38] Could be of use to you if you want to have a look at the code: http://trac-hacks.org/wiki/SqliteToPgScript [19:39] pickscrape: Yeah, I saw that. Unfortunately, it seemed very Trac-specific. [19:40] I'll see if I can dig out what I did. [19:42] vila: and https://bugs.edge.launchpad.net/ubuntu/+source/langpack-locales/+bug/234105 [19:42] Launchpad bug 234105 in langpack-locales "Support latin locale" [Undecided,New] [19:50] Bad pickscrape. I can't have version controlled it. Shame: there was all sorts of clever shellery involved. :( [19:55] lifeless: regarding bug #234105 are you sure latins had telephone ??? [19:55] Launchpad bug 234105 in langpack-locales "Support latin locale" [Undecided,New] https://launchpad.net/bugs/234105 [19:56] vila: see my comment re accuracy :) [19:56] I saw it :) [19:58] lifeless: regarding loom, is there a reason for record to not be part of commit ? [19:59] I'm still unclear on when I should record... [20:00] jelmer, statik: ping [20:00] jam: hi [20:01] jam: hi! any chance you can host this week? I'm not able to punch a hole in the router for gobby here === J-Unit is now known as jdong [20:02] jelmer: are you available on skype? [20:02] vila: yes, they are orthogonal operations, commit and record are definitely different [20:02] statik: I'll give it a shot [20:02] vila: you should record before you push [20:03] jam: yep, let me see if I can find a headset of some sort [20:03] the use case I have which seems broken is: bzr merge --uncommitted [20:03] jam: my skype name is jvernooij [20:05] lifeless: I use that when hacking on one "slow" machine and running the tests on a faster one [20:05] jam: one sec [20:05] jelmer: np [20:06] well, more precisely I do: bzr revert --no-backup; bzr pull; bzr merge --uncommitted (on the faster machine) [20:07] jam: whats 'notification' as opposed to the thing I wrote for bzr-gtk ? [20:07] lifeless: ask statik [20:08] statik: ^ [20:09] lifeless: it just pops a notify_send bubble when a push or pull completes [20:10] notify-send even [20:10] statik: thats what the bzr-gtk commit-notify does [20:10] lifeless: cool [20:10] statik: I am smelling wheel reinvention :) [20:10] lifeless: i will have to check out commit-notify [20:11] the other one doesn't require me to do anything, I must need to do something to turn on commit-notify [20:11] jelmer: are you ready yet? [20:13] statik: you just run it, or set it on in the bzr-gtk prefs (though they seem somewhat borked at the moment) [20:13] statik: jelmer knows all about it, ask while you are on the phone [20:13] statik: it listens on dbus and can tell you about commits from other machines on your network if lan-notify is also running [20:14] lifeless: from what statik said, it also notifies you when a push/pull finishes [20:14] so you can start it, and switch your focus [20:14] and it will pop up when it is done [20:14] jam: almost - couldn't find a headset but I'm just going to use an external mike [20:14] jelmer: np [20:15] jam: commit-notify hooks on set_rh [20:15] lifeless: which doesn't trigger anymore :) [20:16] jam: Ok, I'm ready [20:16] jam: so modulo the obvious trivial update, which belongs in bzr-dbus, it sounds identical [20:16] lifeless: sounds similar to me, too [20:16] jam: (except commit-notify is devcoupled, yada yada yada [20:16] I don't use either [20:17] lifeless: sounds very cool, i should switch :) [20:23] elmo: https://pqm.bazaar-vcs.org/ errors now? [20:34] any LP bzr people about? I'm wondering what happened to the gchemutils vcsimport [20:35] as a related question, can cvsps import only a part of the history? [20:40] where a found documentation for loggerhead? === mw|food is now known as mw === mwhudson_ is now known as mwhudson [20:58] night all [21:05] hey guys - what's the reasoning behind having bzr branch not set a default push location ? [21:05] or rather, having bzr push not default to using the parent location? [21:08] 90% of the times i've branched in bzr i've not pushed back to the parent [21:09] (not a reason, just what i've found as a user) [21:11] that's odd, it's the oposite with me, 90% of the times I push back to parent [21:12] but I guess that's the beauty of DVCS [21:13] 90% of the time I never push anywhere :) [21:13] hehe [21:14] alright, you win, we should remove push by default and make it a plugin [21:14] * fullermd nods. [21:14] More secure that way. [21:14] Really, we should do the same with 'commit'. It's far too dangerous a tool to allow people to use willy-nilly. [21:15] yeah, and that should improve performance quite a bit [21:16] so I'm guessing we don't have a default push location then because, well, because that would waste resources on fullermd's machine setting it [21:17] yes, that sounds like a solid answer [21:17] good [21:17] as long as there is a reason [21:18] if IIRC, this was discussed at some point, and some good reasons given for it, finding the thread will be impossible [21:18] I figured [21:19] I'm _guessing_ it has something to do with there not really being a "default" usage pattern for this [21:19] * CardinalFang doesn't figure there are /good/ reasons, just reasons. [21:19] it sounds like something lifeless would know, but he's changed timezone [21:19] * mtaylor punches timezones in the face [21:20] Well, I would guess there are 2 factors. [21:20] lifeless: I'd like to talk about looms. [21:20] One is that having the parent loc and push loc being the same is definitely a non-starter; there are vhastly many cases where that would be useless. [21:20] And the other is that the more you increase the number of "X uses the Y location, except if that's not set, then it defaults to Z" cases, the more confusing everything gets. [21:20] Different is fine. Defaults, though? [21:21] (some might say we're already too far in that pit) [21:21] mtaylor, http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/37064/match=default+push+location [21:22] I could never understand how to navigate through gmane, but that's the thread [21:23] beuno: great. that's a good summation I think [21:23] CardinalFang: see above link [21:47] beuno: click on the "subject" link: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/37041/focus=37064 [21:48] jam, aaaaaaaah, yes, thank you :) [22:37] morning [22:50] mornin' mwhudson [22:50] Folks: I just installed bzr 1.4 (via the Mac OS installer) and I get a bzrlib problem. Anyone familiar with this? [22:51] bzr: WARNING: bzrlib version doesn't match the bzr program. [22:51] This may indicate an installation problem. [22:51] bzrlib from ['/Library/Python/2.5/site-packages/bzrlib'] is version (1, 4, 0, 'final', 0) [22:51] tolstoy: i did that yesterday, worked fine [22:51] Did you install over the top of the bzr 1.3 installation? [22:51] Might that be an issue? [22:51] no, it was a clean install [22:52] it indeed might be the issue [22:52] Hm. I wonder if there are any uninstall instructions. [22:52] tolstoy: what does `which bzr` say? [22:52] /usr/bin/bzr [22:52] it sounds like you're getting the right bzrlib but possibly the wrong bzr script [22:52] tolstoy: is there a /usr/local/bin/bzr as well? [22:53] Yep. That's the issue. [22:53] the /usr/bin/bzr has a _script_version_ of 1 3 0 (or something like that). [22:53] I guess I can just delete it, but.... eek. ;) [22:53] Well, that's why it does the version checking ;) [22:54] Yep. Well, thanks for the help! [22:55] I've re-arranged my path to prefer /usr/local/bin, at least for now. [22:59] i would /guess/ that this was really a bug in the old installer [22:59] it shouldn't really have been putting files in /usr/bin, that's naughty === fullermd_ is now known as fullermd === J-Unit is now known as j-dizzle === j-dizzle is now known as j-diddy