[00:14]  * mgrandi waits for jelmer
[00:26] <jelmer> mgrandi: I'm here
[00:27] <mgrandi> yay!
[00:33] <mgrandi> i have to leave fairly soon so i was wondering if you had any input so i could file a bug report or something
[00:34] <jelmer> mgrandi: perhaps just file a bug report ? I don't have anything yet
[00:34] <jelmer> mgrandi: did reverting to an older verison help?
[00:37] <mgrandi> 0.6.5 of bzr-git says unsupported url
[00:37] <mgrandi> bzr: ERROR: Unsupported protocol for url "git@github.com:mgrandi/PythonScripts.git,branch=master"
[00:39] <jelmer> try git+ssh://git@github.com/mgrandi/PythonScripts.git
[00:39] <jelmer> what about 0.6.7 ?
[00:40] <mgrandi> 0.6.7 still had the problem
[00:40] <mgrandi> with the locking
[00:40] <jelmer> hmm, perhaps the bug is related to bzr itself in that case, 0.6.7 is already a pretty long time ago at this point
[00:40] <mgrandi> 0.6.5 has the same lock problem
[00:41] <mgrandi> and yeah, whatever version i was using before, was working fine, it just stopped working today when it seemed that bzr did a repack
[00:41] <mgrandi> before it pushed to github
[00:41] <jelmer> hmm, hang on
[00:42] <jelmer> did you perhaps add tags recently for the first time in a while?
[00:42] <mgrandi> no, i dont think i have any tags
[00:42] <mgrandi> unless the git repo has them or something
[00:43] <mgrandi> (i dont see them if i do a qlog)
[00:43] <jelmer> I don't see any on github either
[00:45] <jelmer> mgrandi: is your local branch bound?
[00:45] <mgrandi> yeah, its bound to my ftp server (bazaar)
[00:46] <jelmer> I suspect that's related
[00:46]  * jelmer digs a bit deeper
[00:53] <jelmer> mgrandi: is it a lightweight checkout?
[00:53] <mgrandi> it is not
[00:54] <jelmer> mgrandi: managed to reproduce it
[00:54] <jelmer> mgrandi: any chance you can file a bug?
[00:54] <mgrandi> yay! and what should i report it against, bzr-git or bzr
[00:54] <jelmer> mgrandi: bzr-git I think
[00:54] <jelmer> not entirely sure yet
[00:54] <mgrandi> i'll report it against bzr-git for now
[00:59] <mgrandi> jelmer: reported here: https://bugs.launchpad.net/bzr-git/+bug/949557
[00:59] <ubot5`> Ubuntu bug 949557 in Bazaar Git Plugin ""Unable to obtain lock" error when using bzr dpush" [Undecided,New]
[01:01] <mgrandi> however, i must go get food and go to the gym, you can contact me through the bug report if you need more information =)
[01:01] <mgrandi> later~
[01:11] <jelmer> ... and fixed
[01:11] <jelmer> g'night all
[01:11] <poolie> night jelmer
[05:00] <mgrandi> jelmer: i saw that you fixed the bug we were talking about earlier and i tried it and it works =) thanks
[08:13] <vila> hi all !
[08:56] <mgz> morning all!
[08:57] <vila> mgz: ;)
[08:57] <mgz> and how are you this morning vila?
[08:57] <poolie> hi all
[08:57] <poolie> not really here
[08:58] <vila> fine thanks, I slept far before 4:00 in the morning unlike yesterday ;)
[08:58] <vila> mgz: and thanks for the windows installers, I'll release 2.5.0 officially later today
[09:39] <apw> in ubuntu, i am all of a suddent 1) seeing an onscreen progress window for command line pushes, and 2) finding it gets stuck on the screen forever.  is the first expected and the second known?
[09:40] <vila> apw: never heard about that, you mean some gtk/kde progress window right ?
[09:41] <apw> yeah some gtk type little cylon wizzer
[09:42] <vila> apw: 'bzr plugins -v' paste ? This may be caused by some plugin... in which case 'BZR_DISABLE_PLUGINS=gtk:qbzr' will confirm... but that's really a wild guess
[09:43] <apw> https://bugs.launchpad.net/bzr/+bug/949798
[09:43] <ubot5`> Ubuntu bug 949798 in Bazaar "bzr-notify leaves a rogue status throbber on screen after bzr push completes" [Undecided,New]
[09:43] <vila> apw: in any case, it's not from bzr itself AFAICT but worth being investigated
[09:43] <vila> apw: not a notification dialog right ?
[09:43] <vila> meh, notification thing :)
[09:44] <apw> http://paste.ubuntu.com/874298/
[09:44] <apw> vila, the box literally has a 1in wide cylon style progress 'indicator' which zips back and forth like a mad thing
[09:45] <apw> when i find out how to kill it ... i shall take great pleasure in doing so
[09:45]  * vila blinks
[09:45] <apw> vila, i think its coming in as a side effect of having bzr-gtk installed, that has always had expected side effects like giving you notification bubbles for command line pushes; also really annoying
[09:46] <mgz> that's kinda funny
[09:46] <vila> hmm, I had trouble *getting* notifications (which I like ;) but there should be a trick to disable them
[09:47] <vila> but I only get notifications messages for a few seconds, never any progress stuff
[09:47] <apw> vila, its 'brand new' as in i think i got it in the last day or two max
[09:50] <vila> hmm, can't reproduce while pushing a branch new branch on lp :-/
[09:50] <vila> apw: where did you push ?
[09:51] <apw> vila, to launchpad
[09:51] <apw> vila, do you have bzr-gtk installed?  pretty sure that is required to trigger the fun
[09:52] <vila> yup, running from trunk though
[09:52] <apw> hmmm ... only appears to be triggered when you have something to push too, when it says 'no new reviews or tags to push' it doesn't appear
[09:59] <vila> apw: as a workaround, try killing bzr-notify
[09:59] <vila> apw: (I'm still in the dark as I can't reproduce :-/)
[10:06] <apw> vila, will do
[10:12] <vivekimsit1> hii
[10:13] <vivekimsit1> I have a diff file which contains diff of more than one files who can I use that diff file to apply a patch ..?
[10:14] <vila> vivekimsit1: if no renames are involved then 'patch' is the command you're searching for I guess
[10:37] <vila> jelmer: ping, is one of the foreign plugins adding a '/changes' to the end of an url for probing purposes ?
[10:38] <jelmer> vila: no, that seems more like a loggerhead artefact
[10:40] <vila> k, thnks
[10:41] <jelmer> (what are you tracking down?)
[10:42] <vila> a weird redirect issue in bug #924727
[10:42] <ubot5`> Launchpad bug 924220 in Bazaar "duplicate for #924727 ssl.ca_certs should be supported in authentication.conf" [Medium,Confirmed] https://launchpad.net/bugs/924220
[10:43] <vila> rhaaa, not the duplicate (which is ~abusive)
[11:06] <vila> jelmer: did you read about apw issues earlier (~1 hour ago) ? Can https://code.launchpad.net/~sinzui/bzr-gtk/ui-factory/+merge/94866  be related ?
[11:08] <jelmer> vila: if you mean bug 949798, I don't see how that could be related
[11:08] <ubot5`> Launchpad bug 949798 in Bazaar GTK+ Frontends "bzr-notify leaves a rogue status throbber on screen after bzr push completes" [High,Confirmed] https://launchpad.net/bugs/949798
[11:10] <vila> jelmer: I don't see *how* for now, but may be a progress window wasn't displayed before and now is
[11:10] <vila> (under circumstances I can't reproduce though :-//)
[11:11] <apw> vila, i've never seen these progress frobbers until just the last day or two maybe
[11:12] <vila> apw: but (except for bzr-notify), you're not using any g* command right ?
[11:12] <jelmer> ah, bzr-notify uses open_display, which sets the ui factory
[11:12] <jelmer> that makes sense
[11:12] <jelmer> I'll ask Curtis about this
[11:12] <apw> vila, right i see them when i bzr push from the command line directly
[11:13] <mgz> I can belive curtis fixing bugs made some previously broken misfeature accidentally work
[11:14] <vila> jelmer: yeah, something like that, so my guess (uneducated and therefore guaranteed to be at least half bogus) is that some progress is triggered and never closed. But for bzr-notify, it should just *never* display a progress
[11:14]  * vila nods @ mgz
[11:15] <jelmer> vila: right, so I think this is a regression from the ui-factory branch
[11:15] <jelmer> as I think you suggested :)
[11:15] <vila> yeah
[11:16] <vila> not a regression per se, I agree with mgz
[11:16] <jelmer> vila: it is a regression, the Gtk UI factory didn't use to display anything if there was no active window registered
[11:16] <vila> probably making some old broken code works better and as such reveals an older bug
[11:16] <vila> kk
[11:16] <vila> the mistery (to me) is still that I can't reproduce
[11:17] <jelmer> vila: are you running bzr-notify from bzr-gtk trunk?
[11:17] <vila> yes
[11:17] <jelmer> vila: not just bzr-gtk, but bzr-notify too?
[11:17] <jelmer> and did you log out and back in again after updating bzr-gtk?
[11:17] <vila> yes, I have a ~/bin/bzr-notify pointing to the trunk version
[11:17] <vila> no :)
[11:18] <vila> I'm trying to get rid of my backlog mail before releasing to avoid missing some known issue
[11:19] <vila> which is how I discovered curtis work (which I welcome ;)
[12:53] <jelmer> vila: btw, it seems like quilt is generating different contents for .pc/ in newer versions
[12:53]  * jelmer thinks that might be a good excuse to move to not shipping .pc/ in udd branches
[12:54] <vila> jelmer: I have little experience there but when did it start ?
[12:55] <jelmer> vila: I think one of the quilt packages in Debian sid
[12:57] <vila> jelmer: as in: last week, last month ?
[12:57] <jelmer> vila: no idea
[12:57] <jelmer> vila: this came up in #ubuntu-devel yesterday
[13:08] <jelmer> vila: it shows up in precise
[13:08] <jelmer> if you pop all quilt patches and push them, you end up with a bunch of .timestamp files in .pc that weren't there previously
[13:09] <vila> :-/
[13:44] <jelmer> vila: I think we should get bzr-builddeb to a point where bzr can deal with quilt patches transparently (like looms) and then change the default in UDD to not apply patches by default.
[13:47] <vila> jelmer: i..e. apply patches in the wt only, sounds nice. I'm unclear about how far we are from that (I thought we were already there ;)
[13:48] <jelmer> vila: we can automatically apply patches on checkout/update and make sure they aren't applied on commit
[13:48] <jelmer> vila: if we do that, we still see the changes in 'bzr diff' and 'bzr status'
[13:50] <vila> right, forgot that, lack of practice :-/
[13:51] <vila> I need a break, bbl
[14:26] <abentley> mgz: Could youl please review https://code.launchpad.net/~abentley/bzr/config-cache-bugs/+merge/96227 ?
[14:26] <ubot5`> Ubuntu bug 81798 in democracyplayer (Ubuntu) "duplicate for #96227 [apport] democracyplayer crashed with TypeError in __new__()" [High,Fix released]
[14:27] <abentley> ubot: don't be silly
[14:28] <mgz> abently, sure, I had a look at that
[14:28] <mgz> tests look good, only thing I wasn't sure on was where they should live
[14:29] <abentley> mgz: thanks.
[14:30] <mgz> and generally I'd write expected failure tests as...
[14:30] <mgz> for instance, if I know that f() currently returns 1, but it should return 2
[14:31] <mgz> self.expectedFailure("...", self.assertNotEquals, 1, f())
[14:31] <mgz> self.assertEqual(2, f())
[14:31] <mgz> so the diff for the fix is just deleting the expectedFailure line
[14:32] <mgz> but that's mostly useful in more complex cases than this
[14:34] <smoser> jelmer, are you expectin to get bug 923688 into ubuntu soon ?
[14:34] <ubot5`> Launchpad bug 923688 in bzr-builddeb (Ubuntu) "bzr crashed with AttributeError in tree_unapply_patches(): 'DirStateRevisionTree' object has no attribute 'last_revision'" [High,Triaged] https://launchpad.net/bugs/923688
[14:34] <smoser> i've hit it several times when trying to merge things.
[14:38] <mgz> smoser: 2.8.3 is tagged and in unstable, so it presumably just needs to filter through into precise
[14:39] <smoser> mgz, well., at this point in cycle *someone* would have to ask for a sync, right?
[14:39] <smoser> what does "in unstable" mean ?
[14:40] <smoser> duh.
[14:40] <smoser> sorry.
[14:40] <smoser> i looked at pts record for bzr (not bzr-builddeb) and saw no 2.8.3 there.
[14:44] <mgz> smoser: syncing now.
[14:44]  * mgz claims credit for jamespage's work
[14:44] <smoser> thats always good
[14:44] <smoser> i make it a habit
[14:46] <mgz> :)
[14:46] <abentley> mgz: Okay, I can change the expectedFailures to calculate the result in a separate statement.
[14:49] <mgz> abentley: do you have feelings about where the tests should be? I thought in config, but looking at the existing tests in both places your current pick seems more appropriate
[14:50] <abentley> mgz: I think making them branch-related makes sense because they are related to the per-branch caching.
[14:50] <jelmer> smoser: I'll request a sync
[14:52] <mgz> jelmer: doing it now
[14:55] <abentley> mgz: updated.
[14:56] <jelmer> mgz: not sure I follow?
[14:56] <jelmer> mgz: (it's already been synced)
[15:08] <abentley> mgz: I've made the changes you requested.  Anything else?
[15:11] <mgz> ah. er... link to lp bug in comment?
[15:11]  * mgz approves
[15:13] <abentley> mgz: Comment in the code or on the merge proposal?
[15:14] <mgz> both would be good.
[15:15] <abentley> mgz: sure thing.
[15:18] <Noldorin> hey folks
[15:18] <Noldorin> jelmer, wgz
[15:18] <jelmer> hi Noldorin
[15:19] <Noldorin> how's things going?
[15:19] <jelmer> alright, how are you?
[15:19] <Noldorin> okay thanks
[15:20] <Noldorin> jelmer, some good news re: windows support. i rememebr this applying t oa certain bzr bug which i forget...
[15:20] <Noldorin> "import" as well as all python filesystem functions now correctly resolve junctions on windows
[15:20] <Noldorin> i.e. directory symlinks
[15:20] <jelmer> Noldorin: ah, neat
[15:20] <Noldorin> next release of py2.7 i believe
[15:21] <Noldorin> i submitted this bug some time ago, and they've been working on it :-)
[15:21] <jelmer> yeah, I remember you mentioning that
[15:21] <Noldorin> jelmer, forget which bzr bug(s) it applied to, but at least you know now
[15:22] <mgz> ...next release of 2.7? really? there is no symlink support in 2.7
[15:22] <Noldorin> mgz, sure there is. python has supported windows symlinks on files and (very dodgily) on directories for a while now
[15:23] <Noldorin> but it will finally be fixed, most importantly for "import" in the next revision
[15:23] <Noldorin> 2.7.x
[15:23] <Noldorin> http://bugs.python.org/issue6727
[15:28] <mgz> so, that's not actually symlink support, that only landed on py3k
[15:28] <mgz> it does work around a bug in the msvc runtime though, which is like what you ran into
[15:28] <mgz> I'm not sure it's the same issue without comparing them though
[15:29] <mgz> I think your problem related to rename? this is in stat related.
[15:35] <Noldorin> mgz, nah it says 2.7
[15:35] <Noldorin> which onee you looking at? :-P
[15:35] <Noldorin> i get the notifications
[15:35] <Noldorin> have for ages
[15:36] <LarstiQ> Noldorin: nice detective work on that bug
[15:36] <Noldorin> cheers
[15:37] <mgz> Noldorin: I'm looking at the 2.7 source, and it's not there :)
[15:37] <Noldorin> mgz, then take it up with the dev. Jason Coombes i htink
[15:37] <Noldorin> he explicitly said he's making it for the next 2.7 release
[15:37] <Noldorin> ha
[15:38] <abentley> vila: it would be nice if "configure" was an alias for "config".
[15:38] <mgz> that fix is in 2.7
[15:38] <mgz> but it concerns a particular issue with stat and junctions, not the symlink plumbing
[15:39] <Noldorin> yes that's what i mean :-P
[15:39] <Noldorin> didn't say anything about plumbing heh
[15:39] <mgz> and it doesn't change any of the functions on the path you had problems with
[15:41] <Noldorin> hmm?
[15:41] <Noldorin> i was talking about imports
[15:41] <Noldorin> i think you're thinking about a different bug i had
[15:42] <mgz> Noldorin: ah, perhaps
[15:43] <Noldorin> yeah i've had lots of problems with symlinks :-)
[15:43] <Noldorin> one of which you were involved in
[15:43] <Noldorin> the winapi and its interop with python can be very dodgy sometimes
[15:43] <Noldorin> due to various winapi "features"
[15:43] <Noldorin> heh
[17:41] <mgrandi> hu
[17:41] <mgrandi> hi*
[17:43] <mgrandi> is launchpad broken? i keep getting urls like https://bugs.launchpad.net/~markgrandi/null
[17:43] <mgrandi> and then when i go back i get the 404 error pge
[17:46] <mgz> sounds like bug 897277
[17:46] <ubot5`> Launchpad bug 897277 in Launchpad itself "Going to +bugs results in incorrect URL location" [Low,Triaged] https://launchpad.net/bugs/897277
[17:46] <mgrandi> hmm
[17:46] <mgz> in general, disabiling javascript means launchpad works properly,
[17:47] <mgrandi> yeah im using opera too
[17:47] <mgz> (though don't let anyone hear me say that)
[17:47] <mgz> and #launchpad is the right place to complain
[17:48] <mgrandi> and yeah, it works in chrome, so it might be an opera problem
[17:49] <mgz> well, it's a launchpad javascript bug
[17:50] <mgz> tell #launchpad about it
[17:50] <mgrandi> actually it seems like a opera bug
[17:51] <mgrandi> http://my.opera.com/community/forums/topic.dml?id=1303132
[17:51] <mgz> o, actually there are more details now
[17:51] <mgz> that's nice.
[17:51] <mgrandi> if you look there, it seems the html5 history thing
[17:51] <mgrandi> launchpad uses some js library, and it says that one method can return null as the url
[17:51] <mgrandi> which opera doesn't ignore
[17:53] <mgrandi> so its either a yui bug or an opera bug, probably both, so yeah
[17:53] <mgrandi> it works fine if you just don't hit the back button ever =P
[17:55] <mgrandi> anyway mgz, since we were working on https://bugs.launchpad.net/bzr/+bug/864217, do you think thats related to the problem someone posted ot the mailing list about getting OOM while branching?
[17:55] <ubot5`> Ubuntu bug 864217 in Bazaar "MemoryError when repacking repository with large numbers of revisions " [Medium,Confirmed]
[18:18] <jelmer> mgrandi: I wouldn't be surprised if that's related
[18:18] <mgrandi> i still need to work with mgz or someone to trace that out, since debugging stuff on windows is...hard
[18:18] <mgrandi> i have not tried it on linux or mac but yeah.
[18:22] <mgrandi> but thx for the fast turnaround on that bug jelmer, turns out that it actually already pushed to github (when it was getting hung up on the lock), but at least it now exits cleanly!
[18:27] <jelmer> mgrandi: yeah, it was failing while pulling changes back into the master branch
[18:28] <mgrandi> ah
[18:28] <mgrandi> i noticed it was a one line change, so yay
[18:37] <jelmer> mgrandi: well, a one line code change and 10 lines of test :)
[18:37] <wgz> sorry mgrandi, hit the wrong button leaving in a hurry for the bus
[18:38] <mgrandi> nah tis fine
[18:38] <wgz> didn't seem to be directly the same thing, as it was an OOM during fetching, not on repacking
[18:39] <wgz> but no doubt some of the same things that are sitting in memory are the same
[18:39] <wgz> we should have another go at tracing your one some evening
[18:42] <SRay> Hi, I'm part of a project and I'd like to use Bazaar in connection with a decentralized server. Now we can't exchange IPs manually everytime and that's where DHT come into play. However it appears nobody wrote such an implementation as of yet. Am I mistaken? Is this possible or am I missing some aspect?
[18:43] <mgrandi> wgz, yeah, this weekend might be good, our timezones are weird so you are on at weird times for me
[18:44] <LarstiQ> mgrandi: what timezone are you in?
[18:45] <mgrandi> usa/arizona/phoenix
[18:46] <LarstiQ> ah, UTC-7. That explains things :)
[18:47] <mgrandi> utc - 7 without dst
[18:47] <mgrandi> arizona is special :>
[18:47] <LarstiQ> :)
[18:49] <mgrandi> its sunny 300+ days a year
[18:49] <mgrandi> we don't need to save daylight haha
[18:51] <mgrandi> i take it most of you guys are on the other side of the earth!
[18:51] <SRay> Depending on what you regard as the other side :P
[18:51] <SRay> If it's Europe for you then yes :D
[18:52] <mgrandi> rather, on the other side of the ocean
[18:53] <SRay> ^^
[18:54] <SRay> It really sucks in terms of communication that there's such a big difference in time.
[18:57] <fullermd> I figure if I can't drive there, it's the other side of the world  ;p
[18:57] <SRay> :P
[18:58] <fullermd> 'course, you never know.  Some smartass might build a bridge across the Bering Strait and screw up my whole worldview...
[18:58] <SRay> I like bridges :D
[18:59] <mgrandi> might be able to drive there, isn't there a bridge between alaska and russia? you can see your house from there after all
[18:59] <mgrandi> (ha ha)
[18:59] <SRay> hehe
[19:00] <LarstiQ> mgrandi: Finland for me, so across an ocean yes :P
[19:01] <SRay> Germany here ^^
[19:02] <mgrandi> and now i'm on the phone with india-adobe trying to resolve key issues. *waits*
[19:02] <SRay> XDDDDDDDDDDDDD
[19:02] <fullermd> Well, that's sure to fail.  But then, the time probably doesn't matter much either way on that one   :p
[19:02] <mgrandi> "my name is jeff, how may i help you" your name is not jeff don't lie to me
[19:03] <SRay> ^^
[19:05] <SRay> hm still got a question: Anyone knows an "easy" way to use Bazaar decentralized? Somehow you or Bazaar gotta know the IP of the project member(s) to pull and commit, but how if there's no tracker nor central repository?
[19:05] <jelmer> SRay: not that I'm aware of
[19:05] <jelmer> SRay: I think this isn't really a bzr-specific problem
[19:06] <mgrandi> shouldn't you have a server that hosts the repository?
[19:06] <wgz> having one well-known place to coordinate from is useful
[19:06] <mgrandi> and then people branch from that and then merge to it, etc
[19:06] <wgz> you can still work in a decentralised fashion without everyone being able to access everyone else's machines
[19:06] <jelmer> sray: you'd probably want just some sort of flexible host lookup mechanism
[19:07] <SRay> jelmer: right but in connection with Bazaar since I want the version control XD
[19:07] <fullermd> If only there were some sort of system to be like a directory, to turn human-readable names into IP addresses...   :p
[19:07] <wgz> mgrandi: lets try this weekend, my evening is your morning :)
[19:07] <mgrandi> have a server on your local network
[19:07] <SRay> mgrandi: true, but someone's gotta pay it :S
[19:08] <mgrandi> its not hard to have a computer just hooked up to the network and have your router forward a host name to it or something
[19:08] <mgrandi> hell i have a computer from 1998 with a 1tb drive in it =P
[19:08] <jelmer> SRay: right, but if you have a host name lookup mechanism in place (like mns) then bzr will work work just fine
[19:09] <SRay> mgrand: yup I could do that, but that sneaky thing consumes energy non-stop :P
[19:10] <SRay> jelmer: sounds interesting, do you have a link?
[19:10] <SRay> *mgrandi:
[19:11] <SRay> mgrandi: appart from costing money, just think about the environment :P
[19:11] <jelmer> SRay: https://en.wikipedia.org/wiki/Multicast_DNS
[19:11] <fullermd> Environment, pah.  What'd the environment ever do for me?
[19:11] <mgrandi> yeah, although a computer that is just a hard drive would not use that much power.
[19:11] <SRay> jelmer: thx I'll take a look.
[19:11] <mgrandi> video cards are what take most of the power in a computer =P
[19:13] <mgrandi> and not to mention modern hard drives shut them self off if not used after a while, or the OS does that
[19:13] <SRay> mgrandi: yeah my parents still don't wanna pay that xD. (I'm still a student and with all the hours I have to stay at university there isn't really enough time to work q_q. And they don't wanna substract it from my pocket money neither :S)
[19:13] <fullermd> Yes, that's why they wear out in 3 months from spinning up and down all the time   :p
[19:13] <SRay> ^^
[19:14] <mgrandi> fullermd: the amount of 'head turn offs' are something in like the low millions
[19:14] <fullermd> Couple hundred thousand.  And those wear out REAL quick when it spins down and up twice a minute.
[19:14] <mgrandi> that a hard drive is rated for, and most of the time they still work after that so, thats like 5+ years,
[19:15] <SRay> mgrandi: I'd be curious to know how much your server consumes though. Maybe if it was cheap enough I could finally convince them unless the look up service doesn't work out.
[19:15] <mgrandi> well yeah, the OS shouldn't be spinning it down twice a minute though
[19:15] <mgrandi> (ubuntu was doing that, which caused a big snafu)
[19:15] <fullermd> That's not the OS spinning it down; that's the drive spinning itself down.
[19:15] <mgrandi> i do need to get a wattage/hour meter, its probably not that efficient since its so old but yeah
[19:15] <fullermd> Anyway, that's not going to save meaningful power unless you can spin it down for, like, 12 hours at a block.
[19:16] <mgrandi> then i'm confused on what controls the hard drive, the hd itself or the OS :o
[19:16] <fullermd> An idle spinnign drive doesn't burn much more'n a watt or two.  That's like 1 kWh a month.
[19:20] <mgrandi> true
[19:33] <LarstiQ> SRay: you might be able to pool up on a vps
[19:34] <LarstiQ> SRay: or use `bzr send` to do the exchaning via email
[19:35] <LarstiQ> SRay: or use a service like dyndns to provide the name -> ip mapping
[19:37] <SRay> LarstiQ: Thx for the hint checking it out too. The mDNS sounds like it's meant for local handshake only. the bzr send would mean though that it has to be made manually everytime isn't it? as for dyndns: I thought about that aswell, but it would mean that everyone has to set up his router to automatically send the IP to DynDNS unless....there would be an application which could do it aswell (at startup e.g.)
[19:38] <mgrandi> dyndns usually has a program that runs on the computer
[19:38] <mgrandi> that updates the ip
[19:38] <mgrandi> so if one person's computer has the repo, then you just use whatever.dyndns.org/bzr/branch/whatever/trunk
[19:41] <LarstiQ> SRay: what has to be made manually with send?
[19:42] <SRay> LarstiQ: Open the email?
[19:42] <SRay> or not?
[19:43] <LarstiQ> SRay: well, I would suggest inspecting the bundle before applying it to your local branch
[19:43] <LarstiQ> SRay: but you can completely automate it
[19:43] <SRay> Yup I'd like that.
[19:44] <SRay> Make it similar to Dropbox (with an additional program of course or also just scripts)
[19:44] <SRay> (I'll probably need a program e.g. made in Java with listeners and stuff)
[19:45] <LarstiQ> if you have dropbox then a simple python-inotify script might do the job
[19:45] <SRay> unless there are already programs which automate all the tasks with bzr
[19:46] <SRay> uh, i have no clue about python, but java should do the job aswell isn't it?
[19:50] <mgrandi> what are you trying to do again?
[19:51] <SRay> setting up a distributed repository for a game project
[19:52] <mgrandi> i dont really thing you need to automate anything
[19:52] <mgrandi> you just need to somehow connect to a computer that has the repo, somehow
[19:52] <mgrandi> i think you are making it harder then it should be
[19:53] <SRay> might be, but quite some ppl on the project might not be that tech savy (I've been working together with ppl on a Mod which uses SVN) and that often causes problems.
[19:54] <mgrandi> all you need is one computer that is local or something that acts as the repository and then you can just use that
[19:54] <mgrandi> whether its using dyndns or an ip or what, you can even turn it off when you all leave or something
[19:54] <SRay> ah the project is with ppl over the internet.
[19:55] <SRay> and we have no fix working times.
[19:55] <mgrandi> well, why not use something like launchpad?
[19:55] <SRay> cause launchpad requires the projects to be open-source
[19:55] <SRay> q_q
[19:55] <SRay> or we'd have to pay
[19:55] <mgrandi> does no one have a ftp
[19:56] <SRay> i think same goes with git or sourceforge
[19:56] <mgrandi> server?
[19:56] <SRay> nope
[19:56] <mgrandi> its like 5 dollars a month =P
[19:56] <SRay> i know XD
[19:56] <mgrandi> you gotta pay something =P
[19:57] <SRay> well if only our PCs would be used to upload and download it should work.
[19:57] <SRay> it should work like peer to peer
[19:57] <SRay> see RetroShare
[19:57] <SRay> or Bittorrent
[19:58] <mgrandi> not really...
[19:58] <mgrandi> the repo is always changing, uploading it using any sharing site or whatever isn't going to work :>
[19:58] <SRay> yeah that's the problem
[19:59] <SRay> with Bittorrent
[19:59] <SRay> however not with RetroShare
[19:59] <mgrandi> you would be reuploading stuff every time something changed in the database
[19:59] <mgrandi> that is going to be a pain in the butt.
[19:59] <mgrandi> repo*
[19:59] <mgrandi> seriously, someone can afford a cheap ftp server, 5 dollars a month is nothing
[19:59] <mgrandi> save yourself the pain =)
[20:00] <SRay> i wonder how much space would the FTP server provide for 5 $ a month?
[20:01] <mgrandi> mine says "infinite"
[20:01] <mgrandi> but its obviously limited, within reason.
[20:01] <SRay> D:
[20:01] <bob2> win115
[20:01] <mgrandi> i highly doubt any thing you upload there will make them yell at you
[20:01] <mgrandi> unless you run a huge website like reddit/github that probably goes through a gb/tb a day
[20:02] <SRay> well no. it would be only for our game project. hmm which is your provider if I may ask?
[20:02] <SRay> FTP server provider
[20:05] <mgrandi> bluehost
[20:06] <mgrandi> however, they charged me for all 3 years at once
[20:06] <mgrandi> which was 300 dollars, but still 5 dollars a month
[20:06] <mgrandi> you might be able to do a smaller number of months but yeah
[20:08] <mgrandi> i feel this would be an issue with any version control system, you just have to have a common place to hold the repository and whatnot, even if its decentralized, and espeically if it is centralized (svn, etc)
[20:09] <SRay> it'd be an option if someone would pay for it. (my parent's surely won't and my project member (only one active so far but other on demand as soon as we finally finished the concept and storyline) probably couldn't afford it neither). it's not even sure we gonna be able to sell this game :S. huh? how comes  300 $ for 3 years where they say 5$ per month? 5$ per month would result in 180$ for 3 years D:
[20:12] <mgrandi> i just checked my billing history
[20:12] <mgrandi> $250.20 for web hosting (3 years), the domain name and domain name privacy
[20:13] <SRay> you're sure it wasn't 5$ per month the first year only?
[20:14] <LarstiQ> SRay: you can also take a look at say, http://www.comparevps.com/
[20:14] <mgrandi> 3 years is 36 months, 3 * 6 (which i think is what it was, 6 dollars not 5) is 216
[20:14] <mgrandi> plus the domain which was like 10 dollars and stuff, 350 sounds right
[20:14] <mgrandi> 250*
[20:14] <mgrandi> hell, if you are that hurting for space i'll let you use mine haha
[20:17] <mgrandi> i'll just give you a folder and some accounts or whatever
[20:18] <SRay> like this it sounds right! hehe cool this would be so great! if we make any money with the game we could refund you afterwards :D. but are you sure this doesn't violate the polycies?
[20:19] <SRay> *policies
[20:20] <SRay> the lowest price for a VPS seems to be 3,95$ a month according to comparevpns
[20:20] <SRay> *vps
[20:53] <SRay> Ok ppl. Thanks a lot for you input! I'll see which option we'll take.
[23:31] <poolie> hi all
[23:47] <wgz> hey poolie
[23:52] <jelmer> hi poolie, wgz
[23:54] <wgz> jelmer: can I do anything to help on the gsoc front tomorrow?