Timestamps are in GMT/BST.
[0:08] * n00b99999 (n=robert@) has joined #freenet
[0:24] * NEOatNHNG (n=neo@) Quit ("Leaving.")
[0:24] * NEOatNHNG1 (n=neo@) has joined #freenet
[0:28] * molat (n=molat@) Quit ("Quitte")
[0:41] * ahuxley (n=ahuxley@) has joined #freenet
[0:57] * christefano (n=christef@) Quit ()
[1:02] * toad_ (n=toad@) Quit (Remote closed the connection)
[1:12] * NEOatNHNG1 (n=neo@) Quit ("Leaving.")
[1:12] * NEOatNHNG (n=neo@) has joined #freenet
[1:17] * n00b99999_ (n=robert@) has joined #freenet
[1:18] * n00b99999 (n=robert@) Quit (Read error: 104 (Connection reset by peer))
[1:21] * n00b99999_ (n=robert@) Quit (Remote closed the connection)
[1:23] * dexterity is now known as Cookie`
[1:27] * NEOatNHNG (n=neo@) Quit (Read error: 54 (Connection reset by peer))
[1:27] * NEOatNHNG1 (n=neo@) has joined #freenet
[1:39] * christefano (n=christef@) has joined #freenet
[1:39] * infinity0 (n=infinity@) has joined #freenet
[1:41] * batosai (n=batosai@) Quit (Read error: 113 (No route to host))
[1:49] * christefano (n=christef@) Quit ()
[1:51] * NEOatNHNG (n=neo@) has joined #freenet
[2:05] * nine9nevermind (n=ninety9@) has joined #freenet
[2:10] * NEOatNHNG1 (n=neo@) Quit (Read error: 110 (Connection timed out))
[2:15] * Zarggg (n=z@) Quit ()
[2:18] * gasi_ (n=gasi@) has joined #freenet
[2:24] * darkmo0d (i=darkmo0d@) has joined #freenet
[2:30] * n0ob (n=travis@) has joined #freenet
[2:32] * gasi__ (n=gasi@) Quit (Read error: 110 (Connection timed out))
[2:50] * TheBishop_ (n=TheBisho@) Quit ("Verlassend")
[2:59] * nine9nevermind (n=ninety9@) Quit ("Ex-Chat")
[3:18] * dbkr (n=nnnnndbk@) Quit ("Getting off stoned server - dircproxy 1.2.0")
[3:18] * caytchen (n=caytchen@) Quit (Read error: 104 (Connection reset by peer))
[3:19] * dbkr (n=nnnnnndb@) has joined #freenet
[3:19] * caytchen (n=caytchen@) has joined #freenet
[3:22] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror3.freenetproject.org/ : it has been disabled
[3:25] * dbkr (n=nnnnnndb@) Quit ("Getting off stoned server - dircproxy 1.2.0")
[3:25] * dbkr (n=nnnnnnnd@) has joined #freenet
[3:37] <FreenetLogBot> The monitoring script has detected that http://mirror3.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[3:41] * caytchen (n=caytchen@) Quit (Read error: 104 (Connection reset by peer))
[3:56] * darkmo0d (i=darkmo0d@) Quit (Remote closed the connection)
[3:57] * darkmo0d (i=darkmo0d@) has joined #freenet
[4:37] * nine9nevermind (n=ninety9@) has joined #freenet
[4:40] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror2.freenetproject.org/ : it has been disabled
[4:42] * sanity sets mode +v nine9nevermind
[4:55] <FreenetLogBot> The monitoring script has detected that http://mirror2.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[5:21] * Nande (n=KVIrc@) Quit ("byes, tengan la bondad de ser felices. ;)")
[5:28] * mrdmx (i=mrdmx@) Quit ("long live the darknet!")
[5:31] * Krhis (n=Krhis@) Quit (Remote closed the connection)
[5:38] * Luke771 (n=luke@) has joined #freenet
[5:50] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror3.freenetproject.org/ : it has been disabled
[5:56] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror2.freenetproject.org/ : it has been disabled
[6:01] * localhost (n=Chris@) Quit (Read error: 104 (Connection reset by peer))
[6:02] * localhost (n=Chris@) has joined #freenet
[6:05] <FreenetLogBot> The monitoring script has detected that http://mirror3.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[6:11] <FreenetLogBot> The monitoring script has detected that http://mirror2.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[6:27] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror2.freenetproject.org/ : it has been disabled
[6:42] <FreenetLogBot> The monitoring script has detected that http://mirror2.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[6:42] * localhost (n=Chris@) Quit (Read error: 104 (Connection reset by peer))
[6:42] * localhost (n=Chris@) has joined #freenet
[6:57] <Luke771> are <meta= > tags stripped when uploading a site to freenet?
[7:00] * n0ob (n=travis@) Quit ("Now onto something more interesting")
[7:21] * Luke771 (n=luke@) Quit (Read error: 104 (Connection reset by peer))
[7:21] * Luke771 (n=luke@) has joined #freenet
[7:23] * dbkr- (n=nnnnnnnn@) has joined #freenet
[7:32] * infinity0 (n=infinity@) Quit (Read error: 104 (Connection reset by peer))
[7:40] * dbkr (n=nnnnnnnd@) Quit (Read error: 110 (Connection timed out))
[7:41] * dbkr- is now known as dbkr
[7:47] * Krhis (n=Krhis@) has joined #freenet
[8:29] * Cookie` (i=dexterit@) Quit (Nick collision from services.)
[8:29] * Cookie` (i=dexterit@) has joined #freenet
[8:29] * Cookie` (i=dexterit@) Quit (Nick collision from services.)
[8:34] * Cookie`_ (i=dexterit@) has joined #freenet
[8:54] * SweetHeartDoll (n=bhf_ira@) has joined #freenet
[8:54] * SweetHeartDoll (n=bhf_ira@) has left #freenet
[8:55] * batosai (n=batosai@) has joined #freenet
[9:04] * Anarhist (n=volodya@) has joined #freenet
[10:17] * nine9nevermind (n=ninety9@) Quit ("Ex-Chat")
[10:25] * steel8 (n=steel8@) has joined #freenet
[10:25] * steel8 (n=steel8@) Quit (Remote closed the connection)
[10:42] * sbc (n=ca@) has joined #freenet
[10:48] * toad_ (n=toad@) has joined #freenet
[10:48] * ChanServ sets mode +o toad_
[10:53] * don42martin (n=don@) has joined #freenet
[11:02] * NEOatNHNG (n=neo@) Quit ("Leaving.")
[11:02] * NEOatNHNG (n=neo@) has joined #freenet
[11:04] * MUK (n=RU@) has joined #freenet
[11:05] <MUK> hello?
[11:05] <toad_> hmmmm?
[11:05] <MUK> I'm trying to make this freenet thing work but I'm quite lost really
[11:07] <Luke771> ok, what's the problem?
[11:07] <MUK> I'm on Vista and the fms files don't work, is there any fix for that?
[11:07] <Luke771> hmm... there must be
[11:08] <Luke771> what fms files don't work? what you did and what happened?
[11:09] <MUK> I've downloaded fms-win32bin-0.3.14 and, let me check...
[11:09] <MUK> Microsoft.VC80.CRT also
[11:09] <Luke771> o k...
[11:09] <MUK> they both tell me "program too big to fit in memory"
[11:09] <Luke771> jeesus
[11:10] <toad_> that seems unlikely :(
[11:10] <Luke771> how much memory you got?
[11:10] <MUK> 3gb
[11:10] <Luke771> well of course it must be an error
[11:10] * NEOatNHNG1 (n=neo@) has joined #freenet
[11:10] <Luke771> and even if you had 2 or 1 gb, those files only take a couple of mb
[11:11] <MUK> dunno
[11:11] <Luke771> wait a minute I have a windows expert on another channel
[11:11] <Luke771> I mean I hope he's around
[11:11] <MUK> will try to redownload them again just in case
[11:12] <Luke771> well, ok
[11:15] <Luke771> MUK: re-enable pagefile, says my windows expert
[11:15] <MUK> ok now it works, sorry i'm quite a newsbie with all this
[11:15] <Luke771> oh. ok
[11:15] <MUK> well cya :)
[11:15] <Luke771> anyhow if you get that memory error again, the solution is usually to re-enable pagefile
[11:15] <MUK> ok thanks
[11:16] <MUK> later
[11:16] * MUK (n=RU@) has left #freenet
[11:16] * batosai (n=batosai@) Quit ("KVIrc 3.4.0 Virgo http://www.kvirc.net/")
[11:16] * Nande (n=KVIrc@) has joined #freenet
[11:16] * Luke771 wonders what a newsbie is
[11:17] <saces> Luke771: the answer is: try it ;)
[11:17] <FreenetLogBot> r21466 (1154) was built successfully on emu, mirrors are updating
[11:17] * NEOatNHNG2 (n=neo@) has joined #freenet
[11:19] <Luke771> saces: try what? a newsbie?
[11:23] <saces> or your question yesterday.
[11:23] * NEOatNHNG (n=neo@) Quit (Read error: 110 (Connection timed out))
[11:23] <saces> load plugin from freenet key
[11:26] <FreenetLogBot> r21467 (1154) was built successfully on emu, mirrors are updating
[11:31] * NEOatNHNG1 (n=neo@) Quit (Read error: 110 (Connection timed out))
[11:47] <FreenetLogBot> r21468 (1154) was built successfully on emu, mirrors are updating
[11:56] <nextgens> saces> hi
[11:57] <nextgens> saces> I suggest you go futher and create the file if it doesn't exist :)
[11:57] <nextgens> hmm
[11:57] <nextgens> in fact you do create it
[11:57] <nextgens> okay
[11:58] <nextgens> cool
[12:14] <nextgens> saces> I suggest you get rid of the System.out.println and convert them to log messages
[12:15] <nextgens> it didn't make sense in Sha1Test but it does in the node's code
[12:26] <toad_> Luke771: hehe
[12:26] <toad_> saces: hey
[12:26] <toad_> saces: are you intending to provide update over freenet for plugins? imnsho we need some revocation mechanism if you do that
[12:27] <toad_> have a look at the updating code for freenet itself in node.updater ...
[12:29] <saces> toad_: some sort of plugin descriptor is required: revocation, dependicies, alternative locations...
[12:30] <toad_> right
[12:30] <toad_> well if you're going to do dependancies then that'd be great
[12:30] <toad_> should the descriptor itself be updatable?
[12:32] <dbkr> if it included dependencies, then yes
[12:33] <dbkr> *includes
[12:34] <saces> http://wiki.freenetproject.org/FreenetPlugins
[12:35] <nextgens> imho saces should work on a branch too :)
[12:36] <toad_> seems reasonable .. i can't really contribute to this debate since i haven't read the code yet though
[12:36] <nextgens> we definitly don't want the plugin code to be broken because the installer depends on it
[12:37] * nextgens is currently investingating more about dscms
[12:37] <toad_> nextgens: w.r.t. my branch, i think the client layer was always a bit of a nightmare, and i'm doing as much in debugging and fixing various problems and rearchitecting as i am in making it more complex
[12:37] <nextgens> not because we need them but because their implementation are really faster on most operations
[12:38] <nextgens> toad_> sure but it would have deserved to be done on the trunk and then backported to the branch imho
[12:38] <nextgens> things like ChainedBuckets could be used easily on trunk
[12:38] <toad_> yeah, well, it wasn't my original intention to Sort Out The Client Layer, originally I just wanted to persist it
[12:38] <nextgens> and they aren't right now because no one backports it
[12:39] <nextgens> and when you'll have to take the final decision whether to switch to the new code or not the choice won't be fair as you won't be comparing the same thing
[12:39] <toad_> well i may backport some stuff when i reach it
[12:39] <nextgens> ok :)
[12:39] <toad_> but i won't be able to test the backported version
[12:40] * nextgens has just experienced yetAnotherSVNBreakage on a non-freenet related project
[12:40] <toad_> resulting from...?
[12:40] <nextgens> I'm fed up with it
[12:40] <nextgens> a bug; a symptoms are similar to what we experienced
[12:41] <nextgens> svn log and svn blame do take an awful lot of time
[12:41] <nextgens> even though emu is iddling most of the time
[12:41] <nextgens> so I'm reading up on both mercurial and git
[12:42] <nextgens> apparently Bombe and sdiz are git addicted
[12:42] <nextgens> I am not (because I find that it's not a DSCM but a "distributed filesystem")
[12:43] <nextgens> ie: it has way to many features we won't ever need
[12:43] <toad_> yay, 31 subsegments...
[12:43] <nextgens> to be fair:
[12:44] <nextgens> both have all the features we need except sparse checkouts
[12:44] <nextgens> (but Mc2` is working on that for hg)
[12:44] <toad_> probably all of them have retry count 1 too...
[12:44] <toad_> (/me just fixed a big memory bug)
[12:44] <nextgens> does it affect trunk as well?
[12:44] <nextgens> both have non-existent ide integration
[12:45] <toad_> no sadly
[12:45] <nextgens> well, hg is a bit better than git on that side; tortoiseHG and netbeans do have decent clients
[12:45] <nextgens> whereas git doesn't have any
[12:45] <nextgens> nor a good integration to windows
[12:47] <nextgens> and according to my scm-internals-knowledgeable friend hg scales up better when the number of files to deal with increases
[12:49] <saces> eclibse have also a hg plugin
[12:50] * caytchen (n=caytchen@) has joined #freenet
[12:51] <nextgens> a git one too
[12:51] <nextgens> but both of them suck
[12:52] <toad_> more than the SVN plugin does?
[12:52] * infinity0 (n=infinity@) has joined #freenet
[12:52] <toad_> actually the SVN plugin is quite acceptable...
[12:52] <nextgens> toad_> how do we want to handle it; shall we have a vote about it or shall I just rule and deploy one of them?
[12:52] * infinity0 (n=infinity@) Quit (Read error: 104 (Connection reset by peer))
[12:53] <nextgens> toad_> except that it randomly corrupts the svn repository ;)
[12:53] <toad_> nextgens: you think it's useful for performance reasons?
[12:53] <toad_> nextgens: it does?
[12:53] <toad_> nextgens: afaik that sort of thing wouldn't be possible with a DSCM, no?
[12:53] <nextgens> as I told you; I've just experienced it once again!
[12:53] <nextgens> it shouldn't be possible with a dscm
[12:53] <toad_> I thought you said you were looking at tools because of performance issues?
[12:53] <sdiz> nextgens: .... git allow me "stage" commit and reorder them before pushing ....
[12:53] <nextgens> and yeah I do think that it would help performance wise
[12:54] <nextgens> and same goes for space efficiency
[12:54] <toad_> imho performance isn't a big problem atm ... offline commit, staggered commits, easier anonymous development, and above all better merging, all would be significant gains
[12:54] <toad_> space efficiency? you mean on emu?
[12:54] <nextgens> here I have 6 checkouts of the code; that's a waste of space
[12:55] <toad_> right, but compared to a DSCM where you have the full history locally...?
[12:55] <nextgens> including on emu yeah
[12:55] <nextgens> toad_> the build script has one checkout per 'target'
[12:55] <toad_> which is like a gigabyte, isn't it?
[12:55] <nextgens> which isn't optimized
[12:55] <toad_> i mean the full history?
[12:55] <nextgens> let me see
[12:55] <nextgens> I don't think so
[12:56] <toad_> how big?
[12:56] <nextgens> the full history is likely to be way smaller
[12:56] <nextgens> because most of our changes were "copy and branches"
[12:56] <toad_> well how big is it on emu right now?
[12:56] <nextgens> it's less than a gigabyte
[12:56] <toad_> how much less? :)
[12:56] <nextgens> ~svn-build is 800M
[12:56] <toad_> most of that is object files no?
[12:57] <nextgens> nah we clean up everything
[12:57] <nextgens> and store the jars in a different location
[12:57] <toad_> eeeek
[12:57] <toad_> 800M of source? how is that possible?
[12:57] <nextgens> well, that's source + svn-files
[12:57] <nextgens> we have several checkouts of the same thing
[12:58] <toad_> even so, the svn files are just a second copy of the same source
[12:58] <toad_> and the source isn't that big
[12:58] <nextgens> plugins for instance are in 4 different locations
[12:58] <nextgens> okay plugins aren't the right example
[12:58] <nextgens> let's take legacy stuffs
[12:58] <nextgens> we have 4 checkouts
[12:58] <nextgens> 6 actually
[12:58] <toad_> imho changing to a DSCM is a major policy decision ... at the very least you have to convince me (generally I'm in favour, but I'm not sure about timing), and you have to convince Ian
[12:58] <nextgens> one per tag + one per branch + the auto-build one
[12:59] <nextgens> at this stage I'm only experimenting
[12:59] <nextgens> timing is convinient for me :p
[12:59] <nextgens> at the moment I'm on vacation; I have some time I could spare working on emu
[13:00] <toad_> well that is something to take into account definitely
[13:00] <toad_> but we should talk to ian before doing anything irreversible
[13:00] <nextgens> sure
[13:01] <toad_> it will take a certain amount of effort on the part of devs, will that slow things down and cause us trouble in the short term?
[13:01] <nextgens> most of us are used to dscms
[13:01] <nextgens> saces wrote the hg plugin thingy; bombe and sdiz are used to git
[13:01] <nextgens> I will have to get used to one of them...
[13:02] <nextgens> you might be the only one who doesn't have to use them yet :)
[13:03] * sbc (n=ca@) Quit ("Ex-Chat")
[13:03] <nextgens> so no, I don't think that it will slow things down enough for it to be noticed
[13:03] <toad_> okay
[13:03] <nextgens> it will introduce downtime that's for sure
[13:03] <nextgens> but nothing we can't deal with
[13:03] <toad_> well then doing it in the near future makes sense, but we still need a go-ahead from ian
[13:03] <nextgens> my biggest worry is integration to mantis & co
[13:04] * toad_ thinks that too much integration with mantis & co is a recipe for security disasters
[13:04] <toad_> and difficult to partition configurations
[13:04] <toad_> mind you, i can certainly see a benefit
[13:04] <nextgens> it depends on how it's done
[13:04] <nextgens> with a dscm everyone owns the full copy of the tree :)
[13:05] <nextgens> and we could make signatures mandatory
[13:05] <nextgens> so from a security PoV it's probably better than keeping the repository in a presumably safe place and assume that the guys in charge of keeping it safe know what they are doing
[13:06] <toad_> i agree that it's more secure
[13:06] <toad_> that's one big thing in favour of it
[13:06] <toad_> i assume we'd have a Main Tree on emu which core devs could merge stuff to?
[13:07] <nextgens> yeah
[13:07] <nextgens> builds would be done on emu just like now
[13:07] <toad_> cool
[13:07] <nextgens> and the recommended behaviour will be to merge stuffs early
[13:08] <toad_> would all devs have access to emu?
[13:08] <nextgens> like if we weren't using a dscm :p
[13:08] <nextgens> it might be a good idea not to grant everyone access
[13:08] <nextgens> that would be a good way of ensuring that commits are reviewed
[13:09] <toad_> yeah, that's what i was thinking ... e.g. saces' stuff is good, but should really go on a branch for now
[13:09] <toad_> how would review of stuff that IS committed to emu work?
[13:10] <toad_> would we still have the cvs list? or is it unnecessary?
[13:10] * NEOatNHNG2 (n=neo@) Quit ("Leaving.")
[13:10] <nextgens> imho @cvs should reflect what has been commited to the "to be built" trunk
[13:10] * NEOatNHNG (n=neo@) has joined #freenet
[13:10] <nextgens> whether we want to deliver emails related to it is a policy decision more than anything else
[13:10] <toad_> with the crypto features, we can be 100% confident that our commit has been accepted by emu as-is?
[13:11] <toad_> or that a clever attacker has created a separate repo just to spoof us with?
[13:11] <nextgens> with crypto we can ensure that it hasn't been tempered with
[13:11] <nextgens> but we still have to establish a trust-chain
[13:11] <nextgens> ie: that you are who you claim to be
[13:11] <toad_> so we'd have two layers of review - pre-merge review of non-privelidged devs' branches, and of those requested explicitly, and post-merge review of stuff that goes in from other core devs?
[13:12] <nextgens> we could even have a per-dev branch/repository
[13:12] <nextgens> hosted on emu
[13:12] <toad_> what would the point be?
[13:12] <nextgens> that's how the kernel guys do it
[13:12] <toad_> what's the benefit?
[13:12] <nextgens> the point is that anyone could pull any dev's change from a central place
[13:13] <nextgens> it's handy in case the dev in question can't easily export his tree
[13:13] <nextgens> (because he is behind a nat or has limited bandwidth, ...)
[13:13] <toad_> right
[13:13] <toad_> yeah, that makes sense
[13:14] <nextgens> anyway
[13:14] <toad_> but we'd retain the ability to merge from "external" repo's
[13:14] <nextgens> the main question was: hg or git?
[13:14] <toad_> is review-and-commit an atomic operation? i suppose you choose a revision, review to that point, then merge to that point?
[13:15] <toad_> nextgens: do you have a preference? i understand git is reasonably friendly nowadays... mercurial always was...?
[13:15] <toad_> there are big projects using both?
[13:15] <nextgens> imho hg is better in terms of ide integration
[13:15] <toad_> well that's a big plus
[13:15] <nextgens> but that's the status right now
[13:16] <nextgens> it could evolve
[13:16] <nextgens> toad_> netbean's code is hosted on a mercurial repository
[13:16] <toad_> sure... hg is likely to be maintained into the future?
[13:16] <nextgens> meaning that their ide-integration is native and rocks
[13:16] <toad_> well yeah but only for netbeans
[13:16] <toad_> some of us use eclipse :)
[13:17] <toad_> did you say git has issues with windows?
[13:17] <nextgens> saces told me about a plugin earlier on
[13:17] <nextgens> yeah it does have issues
[13:17] <toad_> we don't want to increase the barriers to entry for windows-based devs ...
[13:17] <nextgens> we don't have any :p
[13:17] <nextgens> why should we worry about them ? :)
[13:17] <toad_> java is the cobol of the 90s ... lots of commercial devs use java, even in the naughties
[13:18] <toad_> apart from that... windows devs are just useful
[13:18] <toad_> we can get them to work on the installer ;)
[13:18] <nextgens> hehe
[13:18] <nextgens> something else we might want to consider:
[13:18] <toad_> imho we need to chain an NSIS-based launcher capable of downloading the jvm automatically to the installer on windows
[13:18] <toad_> hmm?
[13:18] <nextgens> people have worked on integrating both hg and git to freenet
[13:19] <toad_> the linux kernel community is as paranoid as we are, this is a plus
[13:19] <nextgens> and it appears that integrating git is easier out of the box
[13:19] <toad_> are there working git tools though? i thought we had working hg tools only?
[13:19] <nextgens> Bombe has been working on git
[13:19] <toad_> ahhhh
[13:19] <nextgens> and iirc it works
[13:19] <toad_> so we have both
[13:19] <toad_> cool
[13:19] <toad_> i believe both work at the moment
[13:20] <nextgens> maybe I should consider implementing the ticket he filled in the other day
[13:20] <toad_> but neither has been tested with a realistic sized project
[13:20] <toad_> we really should try
[13:20] <toad_> i mean we should attempt to insert the repo
[13:20] <toad_> it's less than the size of an ISO, it *might* just work :)
[13:20] <toad_> my worry is the authors are crying out for people to use them and test them ... and nobody is ... they will lose interest if nobody does
[13:20] <sdiz> both of the integration attempt to insert the *full history*, always
[13:21] <toad_> sdiz: iirc one of them inserts diffs most times and a full history every X revisions?
[13:21] <nextgens> both have it configurable
[13:21] <toad_> imho that's the optimal strategy for freenet
[13:22] <nextgens> anyway
[13:22] * nextgens tries to digg the thread about git out of the ml archives
[13:22] <nextgens> http://archives.freenetproject.org/message/20080629.223103.fbca01eb.en.html
[13:23] <toad_> so either of them will work equally well on freenet ... well, maybe git is better because we know bombe ... but i don't think there's much in it :)
[13:24] <toad_> git has poor support for windows, and poor IDE integration for java, correct?
[13:24] <toad_> so my inclination is to go with Mercurial, unless Bombe can contradict these claims?
[13:24] <toad_> given that in terms of other features/issues they are very similar - ease of use, security, performance ?
[13:25] <sdiz> git is slower on windows, but it works well
[13:26] <nextgens> toad_> we know saces too and he has been there longer than me :)
[13:27] <nextgens> git is slower if you don't GC it often
[13:27] <toad_> nextgens: the SVN plugin managed to corrupt the repository on emu?
[13:27] <nextgens> I would say that git is slower in any case... especially when it has to deal with many files
[13:27] <toad_> nextgens: if SVN is that insecure against a malicious dev, then we really shouldn't stay with it
[13:27] <toad_> the plugin wasn't running on emu?
[13:27] <nextgens> but git has more features (we don't necessarily need) than HG
[13:28] <sdiz> nextgens: git do gc automatically in recent builds
[13:28] <sdiz> whenever needed
[13:28] <nextgens> okay, I didn't know that :)
[13:28] <toad_> nextgens: can you confirm w.r.t. data corruption?
[13:29] <toad_> nextgens: is it fixed in SVN 1.5?
[13:29] <nextgens> toad_> we have limited the number of people who can access the tree so the problem is solved
[13:29] <nextgens> toad_> dunno
[13:29] <toad_> I disagree
[13:29] <nextgens> we can't reliably reproduce the problem
[13:29] <nextgens> hence it can't easily be fixed
[13:29] <nextgens> it must be timing-related
[13:29] <toad_> hmmm
[13:30] <nextgens> somehow
[13:30] <toad_> well it does suggest that svn is rather too fragile
[13:30] <nextgens> it has been around longer than any of git/mercurial
[13:30] <nextgens> so I wouldn't bet on that :)
[13:30] <toad_> true
[13:30] <toad_> yeah i suppose
[13:31] <toad_> you don't think it would be possible for a dev with SVN access to rewrite history etc without triggering a commit mail?
[13:31] <nextgens> I'll publish an officially converted read-only repository
[13:31] <toad_> git or hg?
[13:31] <nextgens> toad_> nah that's definitly not possible for a normal dev
[13:32] <nextgens> probably for hg first :p
[13:32] <toad_> okay
[13:32] <toad_> when you've published them, try to insert them using the freenet-hg / freenet-git tools, see if you can crash your node :)
[13:32] <nextgens> it's never that bad: when we experienced the problem it did f*ck the repository up but svn detected it
[13:32] <toad_> ok
[13:32] <nextgens> it was an effective DoS but that's all
[13:33] <nextgens> and we did have logs and could have removed access to the offender (which was you iirc ;) )
[13:33] <toad_> when you've got the read-only repo's done, i assume you're going to post a manifesto on the devl list?
[13:33] <nextgens> yeah, probably
[13:34] <toad_> okay, that's sane
[13:36] <nextgens> http://lwn.net/Articles/151624/
[13:36] <toad_> Hg is used by mozilla now isn't it?
[13:37] <nextgens> yes
[13:38] <sdiz> that "news" was written in 2005
[13:39] <toad_> so it's even better now :)
[13:40] <toad_> [14:39:55] Ian Clarke: do these things have mature Eclipse plugins?
[13:40] <toad_> e.g. eclipse's git plugin definitely isn't mature
[13:40] <toad_> [14:40:07] ? egit definitely isn't mature - there isn't even a binary
[13:40] <nextgens> ask saces about hg
[13:40] <toad_> okay so we take a hit on efficiency there
[13:41] <toad_> nextgens: hmmm?
[13:41] <nextgens> he told me that there was a hg plugin for eclipse
[13:41] <toad_> http://www.vectrace.com/mercurialeclipse/
[13:41] <saces> the mercurialeclipse plugin is realesed 1.xx
[13:41] <nextgens> tortoiseHG is definitly usable on the windows world
[13:42] <nextgens> and that doesn't involve setting up cygwin or whatever
[13:42] <nextgens> toad_> sanity> what about talking here instead of on skype? :)
[13:43] <sanity> i've tried the mercurial eclipse plugin, i wasn't impressed
[13:43] <toad_> http://goldenhammers.com/merclipse/
[13:43] <toad_> here's a different mercurial eclipse plugin
[13:43] <sanity> in fact, I just tried mercurial two days ago, I switched back to svn almost immediately as I couldn't get it to work properly
[13:43] <toad_> may not be mature
[13:44] <toad_> nextgens: so why do we want a DSCM again?
[13:44] <toad_> performance isn't a big issue atm imho
[13:44] <toad_> trustability is a huge issue for me, but i bet ian disagrees
[13:44] <nextgens> I see three important points:
[13:44] <toad_> offline commit, freenet contributors etc, are arguably minor ... better merge we get *in part* in SVN 1.5
[13:44] <nextgens> - security and trustability
[13:45] <nextgens> - performances (svn log and svn blame are *real* slow)
[13:45] <sanity> nextgens: why is it more secure and trustable?
[13:45] <toad_> sanity: for the same reason git is
[13:45] <nextgens> - and offline/anonymous contribution (we have people working on that right now)
[13:45] <sanity> toad_: why is git more secure and trustable?
[13:45] <toad_> sanity: every dev has a full copy of the repo, and it's structured in such a way that any tampering would be instantly detected
[13:46] <nextgens> it can even be signed cryptographically
[13:46] <nextgens> whereas on svn's model you trust what the server says
[13:46] <toad_> another point is that imho a more branch-and-merge oriented workflow would probably be helpful for a lot of stuff - we have two big branches atm, and we have saces' recent plugin work which ought to be on a branch
[13:46] <nextgens> checksums are used but that's to verify integrity
[13:47] * Luke771 (n=luke@) Quit ("Leaving")
[13:47] <sanity> i don't know, I've seen a few projects try to switch over to dcvs, and all they got for their effort was a *lot* of time wasted, a big learning curve, and a bunch of much less mature tools
[13:47] <toad_> sanity: you mean like Linux and Mozilla ?
[13:47] <toad_> sanity: granted those are big projects with different requirements...
[13:47] <toad_> i.e. they really need the performance of a DSCM
[13:47] <sanity> toad_: linux was written by the guys that wrote git, so they didn't have a learning curve. also, their mode of operation is very different
[13:48] <sanity> beb
[13:48] <sanity> brb
[13:48] <toad_> sanity: is that true of mozilla?
[13:48] <toad_> imho we are very vulnerable, a lot of that is due to the auto-update system, but switching to a DSCM would help significantly
[13:49] <sdiz> how does it help the auto-update system?
[13:49] <nextgens> last time we concluded the debate by "dscms are great but we won't make the switch now"
[13:49] <nextgens> sdiz> we could distribute sources
[13:49] <toad_> it doesn't in itself, but long-term, we have signed commits and integrity checking in the DSCM, and we have nodes update from the DSCM over Freenet
[13:50] <toad_> after some stabilisation period during which trusted people can dispute the release and everyone can debate it
[13:51] <sanity> toad_: i don't know about mozilla, i'm referring to Revver
[13:51] <toad_> imho for a workable system that wasn't completely busted by a central compromise, we would end up effectively building a DSCM ... and it's better to *use* an existing DSCM
[13:51] <toad_> sanity: what timescale?
[13:51] <sanity> there is just so much hype and fanboyism around dcvs, its hard to get an honest perspective
[13:51] <toad_> sanity: DSCMs have advanced significantly in the last few years
[13:51] <sanity> toad: a year ago
[13:51] <toad_> well what was the problem?
[13:52] * toad_ has had many favourable perspectives (mostly on git) from many OSS devs at the GSoC
[13:52] <toad_> GSoC conference
[13:52] * darkmo0d (i=darkmo0d@) Quit (Client Quit)
[13:54] <toad_> sanity: any opinions on offline/staggered/anonymous contributions and branch/merge workflow?
[13:59] * toad_ supposes we will have this debate (again) on the devl list after nextgens has implemented the read-only mirrors and announced them
[14:00] <saces> its like a discussion about relegion ;)
[14:01] <toad_> :|
[14:01] <toad_> saces: or filesystems!
[14:02] <nextgens> mirrors are easy to create
[14:02] <nextgens> maintaining them is hard
[14:02] <toad_> i thought there was a tool?
[14:02] <nextgens> keeping them in sync with svn I mean
[14:02] <toad_> that polled an SVN repo and pushed to a git one?
[14:02] <sanity> toad_: if the eclipse tools are mature, i don't mind trying it
[14:03] <sanity> but we should try it for a week, and keep the svn infrastructure around in case it turns out to be a PITA
[14:03] <toad_> sanity: hmmm, how do we reversibly try it without wasting a lot of time?
[14:03] <toad_> nextgens: is that feasible?
[14:03] <sanity> toad_: i believe those dcvs can talk to svn
[14:04] <nextgens> yeah it's feasible
[14:04] <nextgens> but I would prefer not to have to keep both (hg and git) around
[14:04] <toad_> sanity: some can, but we need a git/hg repository to really try it out
[14:04] <sanity> no, we should choose one of hg and git
[14:04] <sanity> or bzr
[14:04] <toad_> agreed, there's no point trying both out
[14:04] <sdiz> git-svn allow bi-directional syncronization between svn and git.
[14:04] <sanity> it shouldn't be that hard to figure out which one is best
[14:04] <toad_> that would be more time than we should spend
[14:05] <sanity> i hear that git is lower level, mercurial is easier to use
[14:05] <toad_> it certainly used to be, i dunno if that is true now
[14:05] <toad_> sdiz: any comments?
[14:05] <sdiz> sanity: it was true in ~2006
[14:05] <nextgens> sanity> no way we go for bzr :)
[14:06] <sdiz> lots of higher level tools are build recently
[14:06] <toad_> nextgens: why?
[14:06] <nextgens> because it's slow
[14:06] <toad_> ok
[14:06] <toad_> nextgens: how often do you use svn blame?
[14:06] <nextgens> a lot recently
[14:06] <toad_> and/or svn log
[14:06] <toad_> because of problems with backporting?
[14:06] <nextgens> yeah
[14:06] <toad_> ok, that's good enough
[14:06] <nextgens> and because I bugfix reported bug
[14:07] <nextgens> sdiz> imho git is lower level than hg
[14:07] <sdiz> git blame is slower then hg ... but it's faster then svn
[14:07] <nextgens> because it doesn't aim to be a dscm it aims to be a distributed file system
[14:07] <toad_> http://goldenhammers.com/merclipse/
[14:07] <nextgens> which is very different
[14:08] <toad_> ian said the other eclipse-mercurial plugin is rubbish, what about this one? it's pre-1.0 so might not be fully mature?
[14:08] <toad_> it won't corrupt your repository, unlike the SVN one ... :)
[14:08] <sdiz> nextgens: hmmm.... i love git because it's easier to integrate with shell scripts.... there are no easy way to do that with hg without using pyhton.. and i hate python..
[14:08] <toad_> well it might have such bugs, but at least it's unlikely to corrupt emu's repo...
[14:08] <sanity> toad_: i wouldn't say its rubbish, but i had trouble getting it to work
[14:08] <sanity> toad_: then again, i'm extremely impatient
[14:09] <toad_> well... it's more mature
[14:09] <toad_> i had some issues getting the svn plugin to work ... it had packaging issues iirc
[14:09] <toad_> it should just install and play now though
[14:10] <toad_> recommended pre-requisites: "a merge tool, like p4merge"
[14:10] <toad_> hmmm
[14:10] <toad_> well obviously we won't be using p4merge...
[14:10] * toad_ supposes there are free alternatives
[14:12] <nextgens> meld?
[14:12] <toad_> the other one is likely more mature
[14:12] <toad_> since it's older
[14:13] <nextgens> both git and hg started around the same date
[14:14] <toad_> Trac has mercurial integration... but we don't want to use Trac...
[14:15] <toad_> anyway i'm not convinced that stuff is vital
[14:15] <nextgens> I guess we can integrate both with mantis
[14:15] <nextgens> if we don't go for the full integration (which we don't have atm)
[14:15] <toad_> just a matter of a few shell scripts? ok
[14:15] <toad_> what would the impact be on current pending work?
[14:16] <toad_> apart from having to commit anything we have locally, install the plugins, and re-checkout, there wouldn't be any major disruption?
[14:16] <nextgens> there wouldn't be any impact as I plan to keep the svn tree up
[14:16] <toad_> in parallel? so automatic merging back to the svn tree?
[14:16] <toad_> or would you set it to be read-only?
[14:16] <nextgens> heh it would be read-only trees
[14:17] <toad_> okay
[14:17] <toad_> read-only SVN makes sense
[14:17] <nextgens> it's just a matter of publishing one official tree for a dscm
[14:17] <toad_> read-only DSCM trees then?
[14:17] <toad_> don't we lose a lot of benefits if we do it that way?
[14:18] <nextgens> (that saves hours of conversion for people willing to use it.. and allows them to speek with meaningfull revision identifiers)
[14:18] <nextgens> that's a temporary solution
[14:18] <toad_> well ian said try it for a week
[14:18] <nextgens> of course long term we will want to get rid of svn
[14:19] <toad_> if for that week it's easier to just commit to SVN then everyone will just commit to SVN
[14:19] <nextgens> really, it shouldn't impact on anyone's work except mine :)
[14:19] <toad_> don't we want there to be an official hg tree which me and you at least can write to?
[14:19] <nextgens> the only question is "git or hg" ?
[14:19] <nextgens> no, not at this stage
[14:20] <sanity> the official hg tree should be on emu
[14:20] <sanity> surely
[14:20] <toad_> sanity: of course
[14:20] <toad_> sanity: that's the plan
[14:20] <sanity> really we will be using the dcvs like a centralized vs
[14:20] <nextgens> agreed, we won't be using it for it's decentralized features at the beginning
[14:21] <toad_> nextgens: i fail to see the benefit of having a read-only DSCM ... well, it would be useful for people working on anonymous patches etc ... but not useful enough, since how would we apply such diffs? we'd commit them to SVN!
[14:21] <nextgens> *its
[14:21] <toad_> okay, this is a good point .... most projects that moved over started off by using it purely as a centralised system
[14:21] <sanity> i'd see the main benefit of a dcvs for us as making merging easier
[14:21] <toad_> and started using the decentralised stuff later on
[14:21] <nextgens> sanity> I'm willing to switch for two reasons: 1) svn randomly corrupts the repository and that pisses me off 2) performance sucks
[14:21] <sanity> well, 1) is a serious problem
[14:22] <toad_> 1) *might* be fixed by svn 1.5
[14:22] <sanity> but that surprises me, svn is pretty mature, very surprising that it would corrupt repos
[14:22] <toad_> it might be fixed by a more recent subversion plugin ... but if so, then it's evil
[14:22] <toad_> because it means the repository is still vulnerable
[14:22] <nextgens> we experienced the problem twice in the past and I've just experienced it on a non freenet repository
[14:23] <sanity> nextgens: hmm, ok, well, that is a good reason to switch
[14:23] <sanity> but i've been using svn for years in a variety of contexts and i've never seen that
[14:23] <toad_> different store type perhaps?
[14:23] <nextgens> it might be an APR bug (apache's libraries)
[14:24] <toad_> nextgens: afaics Mercurial has more mature eclipse etc plugins
[14:24] <sdiz> toad_: which svn backend is emu using? bdb or fsfs ?
[14:24] <sdiz> fsfs is more stable..
[14:24] <nextgens> fsf
[14:24] <nextgens> fsf
[14:24] <nextgens> fsfs
[14:25] <toad_> so IMHO we should go with mercurial
[14:25] <nextgens> toad_> right, mercurial has a better ide integration... and git is easier to integrate with shell scripts
[14:25] <nextgens> ok
[14:25] <toad_> it has the same cryptographic security as git, and i don't think there's much difference in terms of performance by now???
[14:25] <toad_> and it's used by huge projects just like git is
[14:25] <toad_> namely mozilla
[14:26] <nextgens> hg is faster
[14:26] <toad_> cool
[14:26] <nextgens> or said to be faster at least
[14:26] <sdiz> hg blame is faster .... git branching / switching branch is faster
[14:26] <nextgens> sdiz> as far as I know hg stat is way faster too
[14:27] <nextgens> and I do use it a *lot* :)
[14:27] <sdiz> hmmm.. no idea. i never use hg on any project large enough to feel the different...
[14:28] <toad_> okay so the next step?
[14:29] <toad_> nextgens is going to make a read-only mercurial repo, which mirrors changes to the svn repo?
[14:31] <toad_> NetBeans and OpenJDK also use Mercurial
[14:35] <toad_> in other news, persistent downloads on the db4o branch really do seem to be working, without causing major memory issues ... but i'll need to run it overnight to be sure
[14:41] * Johan^mlg (n=bllarf@) has joined #freenet
[14:52] * TheBishop_ (n=TheBisho@) has joined #freenet
[15:10] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror2.freenetproject.org/ : it has been disabled
[15:19] * sbc (n=ca@) has joined #freenet
[15:25] <FreenetLogBot> The monitoring script has detected that http://mirror2.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[15:33] * don42martin (n=don@) has left #freenet
[15:48] * FrinkC (n=FrinkC@) has joined #freenet
[15:57] <sdiz> cherry-picking commit in mercurial seems to be more difficult...
[15:58] <sdiz> transplant extension allow that, but it generate false conflict when you merge the branch ..
[16:00] * ahuxley (n=ahuxley@) Quit ()
[16:06] * apterium (n=apterium@) Quit (Remote closed the connection)
[16:07] * apterium (n=apterium@) has joined #freenet
[16:09] * apterium (n=apterium@) Quit (Remote closed the connection)
[16:16] * apterium (n=apterium@) has joined #freenet
[16:20] * Krhis (n=Krhis@) Quit (Read error: 110 (Connection timed out))
[16:41] <toad_> sdiz: hmmm
[16:41] <toad_> nextgens: thoughts?
[16:46] <nextgens> rehi
[16:46] <nextgens> hmm
[16:47] <nextgens> do we use cherry-picking?
[16:47] <nextgens> I don't :)
[16:47] <toad_> I dunno
[16:47] <nextgens> http://hg.freenetproject.org/
[16:47] <nextgens> that's a raw convert
[16:47] <toad_> surely cherry picking is ~= backporting ?
[16:47] <nextgens> if we decide to keep it I'll do a better one
[16:47] <nextgens> nah
[16:48] <nextgens> cherry picking is "trying every revision" in order to identify where a bug has been introduced
[16:48] <toad_> if we can't commit to it what's the point of having it?
[16:48] * Luke771 (n=luke@) has joined #freenet
[16:48] <toad_> nextgens: no, that's bisection
[16:48] * Shak- (n=shak@) has joined #freenet
[16:48] * nextgens is lost with the terminology
[16:49] <toad_> bisection is like a binary search
[16:49] <toad_> to identify which commit broke some specific feature
[16:49] <nextgens> toad_> the point is that we can exchange and talk about the same revision numbers
[16:49] <toad_> cherry picking is merging some commits but not others
[16:49] <toad_> hence backporting from branches
[16:51] <Shak-> im having some trouble installing freenet.. the error the shell script spat out was: An SSL exception has occured:java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
[16:51] <nextgens> svn-data@emu:/tmp/testing2/freenet$ du -hs .
[16:51] <nextgens> 224M
[16:51] <nextgens> that's way smaller than svn's
[16:51] <toad_> woah
[16:51] <toad_> cool
[16:51] <toad_> and very much feasible to insert to freenet
[16:52] <toad_> Shak-: openjdk?
[16:52] <Shak-> toad_: yep
[16:53] <toad_> Shak-: get the sun JRE
[16:53] <toad_> 1sec
[16:53] <Shak-> so shall I uninstall openjdk first?
[16:53] <nextgens> toad_> I need to take the jabber server down to reclaim some memory; any objection?
[16:54] <toad_> no
[16:54] <nextgens> Shak-> didn't the error message tell you how to fix it?
[16:54] <toad_> Shak-: there's a command to select which java to use
[16:54] <toad_> it's something like java-update-alternatives
[16:54] <toad_> otherwise just install the sun JRE and then purge the openjdk one
[16:54] <Shak-> ok
[16:55] <nextgens> toad_> it's in the FAQ
[16:55] <toad_> then double check with java -version
[16:56] <toad_> nextgens: where?
[16:56] <toad_> nextgens: on the website or on the wiki?
[16:56] <nextgens> http://wiki.freenetproject.org/FrequentlyAskedQuestions
[16:56] <nextgens> fourth question starting from the botom
[16:56] <toad_> Q: The installer told me that I am using a buggy JVM, what can I do?
[16:56] <toad_> ahhh
[16:56] <nextgens> +t
[16:57] <toad_> but the installer didn't tell him the java is buggy
[16:57] <toad_> Shak-: did it?
[16:57] <nextgens> afaic it did tell him
[16:57] <nextgens> I bet he has seen the template you don't like and wrote about on @devl
[16:58] <Shak-> yep it did
[16:58] <toad_> yeah, we should change it
[16:58] <nextgens> it tells what the problem is and there is an entry about it on the faq
[16:58] <nextgens> what else do you want it to do?
[16:59] <nextgens> I mean, sure we could open the browser up to the page
[16:59] <toad_> does it say there is an faq item?
[16:59] <nextgens> or even worst: change their default jvm without asking them
[16:59] <nextgens> but is that really what we want to do?
[16:59] <nextgens> dunno
[16:59] <toad_> [22:42] <Luke771> hm? update.sh is not finding the file, it ran 10 attempts and exited with 'No mirror is available at the moment, please try again later'. Should I try with a newer update.sh from the website?
[16:59] <nextgens> but even if it doesn't their next move should be to go and read the faq
[17:00] <toad_> nextgens: any ideas?
[17:00] <nextgens> where did he find about the irc channel?
[17:00] <toad_> nextgens: how would they even find the wiki-faq?
[17:00] <nextgens> googling like everyone else :p
[17:00] <toad_> nextgens: they'd probably find the main faq first and then give up
[17:01] <toad_> nextgens: it sucks to have 3 FAQs
[17:01] <nextgens> agreed
[17:01] <nextgens> we should merge them
[17:01] <Luke771> toad_: I didnt need to do that. After a few minutes I could update with the update.sh I had. Probably the problem was cause by me trying to update too early straight after a release
[17:01] <toad_> Luke771: ah ok
[17:03] <nextgens> but that goes along with the refactoring of the doc & website
[17:04] * sbc (n=ca@) Quit ("Ex-Chat")
[17:04] <nextgens> and no; I won't do it.
[17:05] <nextgens> and I'm not planning on changing the wording in the installer either
[17:05] <nextgens> it's self-explicit enough
[17:06] <nextgens> asking them to change their system's default jvm is a *bad* workaround
[17:06] * toad_ is fine with that, i'll do it when i get around to it
[17:07] <nextgens> how far are you from reaching current trunk on your review process?
[17:07] * toad_ will be working on that soon
[17:07] <toad_> certainly won't reach trunk today
[17:07] * toad_ has on his todo list: Add an FAQ item about ubuntu 8.04 / openjdk.
[17:07] <toad_> what should it say? what is the typical symptom?
[17:08] <nextgens> get them to moan on ubuntu's bug tracker
[17:08] <toad_> :)
[17:08] <toad_> what's the symptom exactly? the installer won't run?
[17:08] <nextgens> so that the new upstream wichi is already in hardy-proposed will be pushed and deployed
[17:08] <nextgens> yeah the installer won't run because an exception is thrown for no reason when we import the keystore
[17:09] <toad_> it won't run at all? it starts and shows an error? at what point exactly?
[17:09] <nextgens> when it downloads files
[17:09] <toad_> ok
[17:09] <toad_> what is that stage called in the installer? Processes?
[17:12] <nextgens> yes
[17:13] <nextgens> there is already an error message displayed all you have to do is to change it
[17:13] <nextgens> of course it's not only triggered by that bug (using gij will trigger the same error but because of a different bug)
[17:13] <nextgens> and you've to change it in both the graphical and the non-graphical installers
[17:15] * Luke771 (n=luke@) Quit ("Leaving")
[17:23] * Shak- (n=shak@) Quit ()
[17:43] <toad_> what is the correct update-java-alternatives line for ubuntu to enable sun jre 5 as the default?
[17:43] <toad_> somebody quoted it somewhere recently but it's not in any of the irc logs..
[17:44] * greycat (i=rfc1413@) has joined #freenet
[17:46] <nextgens> if you think that users know what openjdk or even a jvm is you're dreaming
[17:46] <nextgens> I doubt that the faq entry helps
[17:46] <FreenetLogBot> Website is up to date with r21485
[17:47] <toad_> nextgens: most users know what ubuntu is
[17:47] <toad_> nextgens: because most of them use it
[17:47] <toad_> most users affected by this bug
[17:49] <FreenetLogBot> Website is up to date with r21487
[17:49] <nextgens> on ubuntu they need to sudo
[17:53] <toad_> they will probably have a menu item for a root terminal
[17:53] * toad_ alters it to "open a root terminal"
[17:58] <FreenetLogBot> Website is up to date with r21488
[18:08] * nico_32 (n=user@) has joined #freenet
[18:10] <kork> # An unexpected error has been detected by Java Runtime Environment:
[18:10] <kork> #
[18:10] <kork> # java.lang.OutOfMemoryError: requested 2048000 bytes for GrET in /BUILD_AREA/jdk6_02/hotspot/src/share/vm/utilities/growableArray.cpp. Out of swap space?
[18:10] <kork> woo
[18:10] <kork> at least it dies gracefully
[18:10] <kork> Successfully closed all datastores.
[18:30] <kork> awesome: a paypal pyramid scheme on freenet \o/
[18:30] <kork> I'm gonna be like soo rich
[18:41] <Cooo> :)
[18:43] * caytchen (n=caytchen@) Quit (Read error: 104 (Connection reset by peer))
[18:56] * christefano (n=christef@) has joined #freenet
[19:29] * mrdmx (i=mrdmx@) has joined #freenet
[19:30] <mrdmx> hey toad when are you going to fix or remove the ssl code
[19:39] * Mathiasdm (n=Mathias@) has joined #freenet
[19:42] * phrosty (n=phrosty@) Quit ("He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever.")
[19:49] <nextgens> mrdmx> which code are you talking about?
[19:51] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror3.freenetproject.org/ : it has been disabled
[19:51] <nextgens> mrdmx> we are about to introduce more in next stable build
[19:52] <mrdmx> more?
[19:55] <nextgens> yes, the opposite of removing it; adding more
[19:55] <mrdmx> heh
[19:56] <mrdmx> Your configuration changes were applied with the following exceptions:
[19:56] <mrdmx> ssl Enable SSL support before use ssl with Fproxy
[19:56] <mrdmx> thats the sort of errors i get
[19:58] <nextgens> ah
[19:58] <nextgens> use stunnel :p
[19:58] <mrdmx> oh
[19:59] <mrdmx> perhaps you should remove the config options then
[20:00] <Cooo> mrdmx: You enabled SSL for FProxy only, right?
[20:01] <mrdmx> no
[20:01] <mrdmx> its broken im certain
[20:02] <Cooo> Yeah. I see now.
[20:02] <nextgens> send a patch.
[20:02] * saces (n=saces@) Quit (Read error: 110 (Connection timed out))
[20:02] <nextgens> toad_> did you do "postmap /etc/postfix/virtual" on emu ?
[20:02] * saces (n=saces@) has joined #freenet
[20:02] * ChanServ sets mode +o saces
[20:05] <FreenetLogBot> The monitoring script has detected that http://mirror3.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[20:06] <nextgens> bbiab
[20:07] <Cooo> mrdmx: did you restart the node after enabling SSL under SSL in config
[20:07] <mrdmx> yes
[20:07] <mrdmx> nevermind that
[20:08] <Cooo> ok.
[20:09] <Cooo> well. trying to enable SSL under SSL here gives me an NotImplementedYetException so there might be something wrong
[20:11] * phrosty (i=phrosty@) has joined #freenet
[20:15] * molat (n=molat@) has joined #freenet
[20:25] * mrdmx (i=mrdmx@) Quit ("long live the darknet!")
[20:34] * FrinkC (n=FrinkC@) Quit ("Bye")
[20:44] * Johan^mlg (n=bllarf@) Quit ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[20:48] * Mathiasdm (n=Mathias@) Quit ("Invisible Internet Project: http://www.i2p2.de")
[20:55] * molat (n=molat@) Quit ("Quitte")
[21:08] * greycat (i=rfc1413@) Quit ("This time the bullet cold rocked ya / A yellow ribbon instead of a swastika")
[21:25] * nico_32 (n=user@) Quit (No route to host)
[21:36] <toad_> <nextgens> toad_> did you do "postmap /etc/postfix/virtual" on emu ?
[21:37] <toad_> nextgens: no, how was i supposed to know about that? :)
[21:37] <toad_> nextgens: aliases is easier, why not just use aliases?
[21:44] * [Nande] (n=KVIrc@) has joined #freenet
[21:45] * Zarggg (n=z@) has joined #freenet
[21:47] * Nande (n=KVIrc@) Quit (Read error: 60 (Operation timed out))
[22:00] * amphibian (n=toad@) has joined #freenet
[22:16] * toad_ (n=toad@) Quit (Read error: 110 (Connection timed out))
[22:16] * amphibian is now known as toad_
[22:27] <nextgens> toad_> because what we need are virtual maps not aliases
[22:28] <toad_> nextgens: what's the difference?
[22:28] <nextgens> aliases are for all domains, virtual maps aren't
[22:28] <nextgens> and anyway, in both cases you need to tell postfix that you did change the file
[22:29] <nextgens> with aliases you use postalias with virtual maps postmap :)
[22:29] <toad_> newaliases, yeah
[22:29] <toad_> any chance of a comment somewhere though?
[22:30] <nextgens> you can put one :)
[22:34] * caytchen (n=caytchen@) has joined #freenet
[22:34] <nextgens> toad_> I've problems understanding how UoM is supposed to work
[22:34] <nextgens> maybe you can help
[22:34] <nextgens> to sum up:
[22:35] <nextgens> when peers connect or discover a new available version they do broadcast an UOMAnnounce
[22:35] <nextgens> those announces are kept by the receiving peers
[22:35] <nextgens> in case it makes sense to upgrade we do upgrade sending an UOMRequest
[22:35] <nextgens> what I don't understand is why we send it to more than one peer
[22:36] <toad_> because one peer might be incredibly slow?
[22:36] <toad_> or otherwise fail?
[22:36] <nextgens> is that intended to attempt to fetch it from multiple peers?
[22:36] <nextgens> in parallel
[22:36] <nextgens> well, we could wait for it to fail, can't we?
[22:37] <nextgens> the code is incredibly racy
[22:37] <nextgens> because what happens is that usually one transfert finishes before the other one
[22:37] <toad_> so?
[22:37] <toad_> why is that a problem?
[22:37] <nextgens> that gets saved somewhere...
[22:37] <nextgens> we don't cancel the other one
[22:37] <nextgens> when it finishes it overrites the update file ...
[22:38] <nextgens> we might be restarting/whatever when that happens
[22:38] <toad_> why would it overwrite it? if we don't need it surely we dump it?
[22:38] <nextgens> atm we don't :)
[22:38] <toad_> iirc we check in NodeUpdater, don't we?
[22:38] <toad_> not NodeUpdater
[22:38] <toad_> hmmm somewhere else :|
[22:38] <toad_> well we should check
[22:38] <nextgens> we don't :)
[22:38] <nextgens> moreover we periodically re-fetch the jar
[22:38] <toad_> imho we should keep the fetch from 2 at once logic
[22:39] <nextgens> okay
[22:39] <nextgens> and cancel the other one when the first finishes
[22:39] <nextgens> right ?
[22:39] <nextgens> or let it finish but discard what was returned?
[22:39] <toad_> because we don't want it to take an age to deploy a vital security fix... it could be *very* slow without timing out, and if we put in a shorter arbitrary timeout, that will fail on slow links
[22:39] <toad_> nextgens: either way is fine
[22:40] <toad_> re-fetching the jar also isn't an issue. we don't re-fetch if there are already 2 fetches running, or if we have the jar already, afaik
[22:40] <nextgens> it's an issue
[22:41] <nextgens> because we fetch over and over the same file
[22:41] <toad_> so what?
[22:41] <nextgens> it's wasting a *lot* of bandwidth
[22:41] <toad_> if we fetch it successfully then we don't re-fetch it
[22:41] <toad_> so what's the problem?
[22:41] <nextgens> that's broken
[22:41] <nextgens> atm we fetch over and over
[22:41] <toad_> have you checked the call trace?
[22:41] <nextgens> not yet
[22:41] <toad_> we must check somewhere
[22:42] <toad_> right-click-call-hierarchy .. that's so much work... :)
[22:42] <toad_> anyway if we're not checking, then clearly there is a problem
[22:43] <nextgens> ok
[22:44] <toad_> maybe we aren't ... hmmm ... fix it :)
[22:44] * Dieppe (n=clement@) Quit (Read error: 60 (Operation timed out))
[22:45] * toad_ worries that it's almost impossible to write leak-free code for db4o because of its lack of garbage collection
[22:45] <toad_> e.g. if you persist a HashMap, unless there's a translator involved at some point, if you clear the hashmap, the HashMap$Entry's are still going to be in the database file
[22:46] * toad_ supposes the answer is to use a translator, or a db4o-compatible object, but then i need to find some info on how to do that
[22:46] <toad_> it's not covered in any of the basic documentation
[22:47] <toad_> well it's not covered in the tutorial pdf anyway
[22:52] <FreenetLogBot> r21495 (1154) was built successfully on emu, mirrors are updating
[22:55] <FreenetLogBot> r21496 (1154) was built successfully on emu, mirrors are updating
[23:07] <nextgens> let's test the new UoM code
[23:07] <FreenetLogBot> r21497 (1154) was built successfully on emu, mirrors are updating
[23:07] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror3.freenetproject.org/ : it has been disabled
[23:19] <FreenetLogBot> r21498 (1154) was built successfully on emu, mirrors are updating
[23:19] <FreenetLogBot> r21499 (1154) was built successfully on emu, mirrors are updating
[23:22] <FreenetLogBot> The monitoring script has detected that http://mirror3.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
[23:33] * toad_ (n=toad@) Quit (Remote closed the connection)
[23:40] <FreenetLogBot> The monitoring script has detected a network glitch on http://mirror2.freenetproject.org/ : it has been disabled
[23:51] * n0ob (n=travis@) has joined #freenet
[23:55] * danny__ (n=danny@) has joined #freenet
[23:55] * danny__ (n=danny@) Quit (Client Quit)
[23:58] <FreenetLogBot> The monitoring script has detected that http://mirror2.freenetproject.org/ is eligible to be back on the main mirror rotation list. Welcome Back!
Irc logs of #freenet : 2008 2007 2006 2005
These logs were automatically created by FreenetLogBot on chat.freenode.net using the Java IRC LogBot.