Hello all. When a user wants to be a relay enter Tor netw. , it sends it's router descriptor to directory authorities. Then directory authorities verifies this descriptor and if it matches some rules they decide to accept uploading it, After all these, when does a directory authority prepare it's new vote document with this new descriptor?

ilter: once an hour

Thank you Sebastian. From where did you find this information? in dir-spec?

it's the current voting interval

Now, i've realized that dir-spec says about times; @ 1858 "Lacking a latest consensus, they SHOULD default to a 30-minute Interval, a 5 minute VotingDelay, and a 5 minute DistDelay."
So can we say that new router descriptor will be included by vote documents of directory authorities in 30 minutes max. ?

no
they have a latest consensus
so they make a new one every hour.
If your timing is unlucky, you might have to wait longer than one hour

or: pootle committed revision 22001 (/translation/trunk/projects/website/nb): Commit from The Tor Translation Portal by user bleakgadfly. 65 of 65 messages translated (0 fuzzy).

Hmm .. ok. Then how long voting of all directory authorites takes?

Sebastian: how to spell couns*$##!sus properly? ;-)
and how to pronounce it? :-D
cuntcensus
? ;-)

consensus

ok
stupid joking

Sorry my net conn. dropped. Was there any answer?

i suggest you ask a dictionary for pronounciation of the word cnsensus.
consensus even

Sebastian: is it for me? ..

oh
hah
you didn't ask that question

:)

i think authorities vote at :55
then they make a new consensus within the next 5 minutes, and publish it at :00

or: arma committed revision 22002 (/website/trunk/en): add "Rewrite TorDNSEL" to our project wishlist

what about between :30 and :55 ? What is going on this time?

they don't do anything at :30
I think between :50 and :55 they synchronize the descirptors they have

Does it mean voting?

no they vote afterwards

Mar 17 18:50:01.779 [notice] Time to vote.

*synchronize the descriptors = ? voting

hah

Mar 17 18:52:31.305 [notice] Time to fetch any votes that we're missing.

:)

Mar 17 18:55:01.189 [notice] Time to compute a consensus.

I should get my private Tor network back up

Mar 17 18:57:31.721 [notice] Time to fetch any signatures that we're missing.
Mar 17 19:00:01.454 [notice] Time to publish the consensus and discard old votes
those are the five steps.

arma: Where are these useful logs? Do you collect them from one of authority?

are the typical timing for them.
ilter1: yes

ilter1: yeah, I guess I was confused about the terminology of voting.
sorry -.-

No problem Sebastian. You're telling always good for me.

tor defaults to a new consensus every 30 minutes if it doesn't know a number
our current number is 60, so it uses that.

arma: Can we access these logs from somewhere?

not really. run a tor network of your own if you want?
or look at the code

Hmm.. So how can i learn the current number? Is it written source codes?
*on source codes

ilter1: see the V3AuthVotingInterval N minutes|hours config option
(and related options)

Sebastian: you mean in torrc?

yeah
The code sets it to 1 hour by default (in contrast to what arma said, afaiui)

I couldn't find V3AuthVotingInterval parameter in torrc?

not every possible option is in the default torrc
see the manpage

sebastian: see dirvote_recalculate_timing()
in particular, the case when !consensus

right

or: [debian-tor/debian-0.2.1] 2010-02-18 16:54:26 Nick Mathewson <nickm@torproject.org>: Add changelog for latest openssl fix
or: [debian-tor/debian-0.2.1] 2010-02-24 08:36:15 Sebastian Hahn <sebastian@torproject.org>: Proper NULL checking in circuit_list_path_impl()
or: [debian-tor/debian-0.2.1] 2010-02-21 22:27:12 Roger Dingledine <arma@torproject.org>: bump to 0.2.1.24
or: [debian-tor/debian-0.2.1] 2010-02-21 22:52:52 Roger Dingledine <arma@torproject.org>: put 0.2.1.24 in release notes too
or: [debian-tor/debian-0.2.1] 2010-02-23 16:09:02 Sebastian Hahn <sebastian@torproject.org>: Proper NULL checking for hsdesc publication
or: [debian-tor/debian-0.2.1] 2010-03-02 15:40:21 Nick Mathewson <nickm@torproject.org>: Backport fix for time-goes-forward test. Fix bug 1267
or: [debian-tor/debian-0.2.1] 2010-02-18 04:55:03 Nick Mathewson <nickm@torproject.org>: Even more conservative option-setting for SSL renegotiation.
or: [debian-tor/debian-0.2.1] 2010-02-25 09:31:36 Sebastian Hahn <sebastian@torproject.org>: Properly handle non-terminated strings
or: [debian-tor/debian-0.2.1] 2010-03-04 23:37:40 Nick Mathewson <nickm@torproject.org>: Apply Roger's bug 1269 fix.
or: [debian-tor/debian-0.2.1] 2010-02-27 22:13:37 Nick Mathewson <nickm@torproject.org>: Update Tor Project copyright years
or: [debian-tor/debian-0.2.1] 2010-02-22 10:39:29 Sebastian Hahn <sebastian@torproject.org>: Zero a cipher completely before freeing it
or: [debian-tor/debian-0.2.1] 2010-02-18 12:08:57 Sebastian Hahn <sebastian@torproject.org>: Fix compile
or: [debian-tor/debian-0.2.1] 2010-02-18 16:57:47 Nick Mathewson <nickm@torproject.org>: Bump version to 0.2.1.23-dev
or: [debian-tor/debian-0.2.1] 2010-03-16 12:32:57 Peter Palfrader <peter@palfrader.org>: No longer needs patches/15_enable_renegotiation_on_098k.dpatch
or: [debian-tor/debian-0.2.1] 2010-03-15 22:08:29 Roger Dingledine <arma@torproject.org>: bump to 0.2.1.25
or: [debian-tor/debian-0.2.1] 2010-03-16 04:44:30 Roger Dingledine <arma@torproject.org>: give us a blurb; add stanza to the releasenotes
or: [debian-tor/debian-0.2.1] 2010-03-17 22:19:49 Peter Palfrader <peter@palfrader.org>: Merge branch 'debian-merge' into debian-0.2.1
or: [debian-tor/debian-0.2.1] 2010-03-17 22:21:14 Peter Palfrader <peter@palfrader.org>: Change order of recommends from privoxy | polipo to polipo | privoxy.

arma: I guess "giving it a number" might mean "out it in the source as a default" ;)

or: [debian-tor/debian-0.2.1] 2010-03-07 03:39:34 Roger Dingledine <arma@torproject.org>: clean up the 0.2.1.25 changelog
or: [debian-tor/debian-0.2.1] 2010-03-16 12:30:29 Peter Palfrader <peter@palfrader.org>: Merge commit 'tor-0.2.1.25' into debian-merge
or: [debian-tor/debian-0.2.1] 2010-03-16 12:31:55 Peter Palfrader <peter@palfrader.org>: New upstream version

someone might want to update the topic
and announce 0.2.1.25 ;)
ah, tbb isn't built

yep. i'm blocking on that for the announce
also, i plan to declare 0.2.0.x obsolete in that announce
in other news. http://metrics.torproject.org/new-users-graphs.html#burma -- what country does it say that graph is for, for you?

which probably means I should patch out the thing that starts bi**hing to users if they run a version you don't like anymore. for next time when that happens

arma: Burmese Tor users

Ok guys i got it thank you so much.

arma: the captions are somehow off, aren't they?

weasel: for some browsers they are, for some apparently not.

yes they look weird

ah
I see what happens

but it's the right graph for me

maybe you should insert linebreaks when you go from one country to the next

what's a linebreak? "<br />"?

or <p> or whatever

setting targets with <p> borders works usually

also, it's not entirely clear if the caption belongs to the image above or below

but some browsers have a cute problem:
They render the page, and take you to the anchor

(Action) resists the urge to engage in a webdev type discussion.

then they realize they need to fit all those images
then they fetch them, and expand the website
and you're in a totally wrong place
the way to fix that is give the images dimensions that reflect reality
or update your browser
(Action) suspects arma is on IE 5.0
karsten: ^^^^ you might want to implement some of these suggestions.

arma: Finally can we summarize it like this order?; a user who wants to be a relay prepares its router descriptor / it sends this new router descriptors to all authorities @any time / authorities check it @any time / if they accept it they put it in their vote documents before :50 ? / :50 time to vote / :52 time to fetch missing votes / 00: time to publish consensus / Then new OR is ready to be used.

ilter1: except not quite
once the consensus is published, it needs to be cached
and people need to start using it
that takes more time again
it will only be available to newly bootstrapping clients

Oops i forgot it. What about the others? Are they in right order?

They start making the vote document at :50
from all the descriptors they know about
when they're done, they publish to the other auths they know about.

ilter1: see section 1.4 of dir-spec.txt
you've left out some steps, and i think you misunderstand others but i'm not sure.

I've just looked it.

hah. I know have one favorite gsoc project, and one that I'd like to mentor most. yay

sebastian: which one is that?

favorite is unit testing, and I'd most like to mentor dnsel

arma: I'm trying to make it certain. As far as i read there're 2 distinct documents (vote and consensus).

I pondered learning Go so I could rewrite it in a new totally sketchy language that nobody knows

we should recruit good people to do each of those, then, rather than waiting and suggesting them to people who show up. i fear that people who show up have a higher likelihood of being flaky and clueless
ilter1: yes. plus there are signatures.

All authorities firstly making their own vote documents?

ilter1: they all make a vote. Then from all the votes, a consensus is computed.
they all compute the consensus in the same way
following the same rules
minus bugs
arma: I'll start promising stuff to people once we're in.

Sebastian: they all don't make a vote as far as i understood. They all make their own vote documents. Then there are 7 votes before preparing consensus doc. Please verify me?
*7 vote documents

every authority makes its own vote document

Yes that's what i know.

Thank you so much Sebastian, arma. Now it seems more clearly for me.

ilter: great. sorry the dir-spec is not as easy to read as it could be

or: arma committed revision 22003 (/website/trunk/en): explain why we need a rewrite

arma: maybe would/could?
erm
+This project would make use of <a
could instead of would?

are there any other reasonable alternatives, if you want to finish it in a summer?
i guess the torflow side isn't too big a part of it.
still, i think torctl is your best bet, and torflow is an easy choice once you've chosen torctl

ok
hm
yeah

if somebody wants to do it in something that's not C or python or perl, we'll have a tougher time maintaining it
and if they want to do it in C or perl, they're nuts.

being nuts isn't always bad
unless they really want perl ;P

So i changed proxy, I use polipo now, so i restarted the tor daemon several times today, but it is been painfully slow and painfully lagging. Is there a way to pinpoint why?
Will a git alpha version behave properly or is it something out of sheer luck?

sometimes tor is fast and sometimes it is slow.
i think it gets faster as more nodes follow more current versions of tor.

or: phobos committed revision 22004 (/website/trunk/include): osx ppc packages for 0.2.1.25 now available.

today is a bad tay for the tor network

how so?

funny, i've found today quite acceptable

Not good for me either,

my node wasn't up
;-)

or: n8fr8 committed revision 22005 (/projects/android/trunk/Orbot/src/org/torproject/android): fixed a few small bugs, added new network package classes for future functionality
or: n8fr8 committed revision 22006 (/projects/android/trunk/Orbot): updated changelog and resource definition files
or: n8fr8 committed revision 22007 (/projects/android/trunk/Orbot): returned AUTHORS file to its proper and rightful state

Hi. I'm searching for the 0.2.1.25 changelog. Can't find it in http://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=ReleaseNotes ; f=ChangeLog displays it as not yet released.

rudi_s_: try the maint-0.2.1 branch
rudi_s_: or grab the tarball and read the ReleaseNotes or ChangeLog files in the tarball

arma: Thanks. Just curious, why isn't Git up to date?

because we develop the 0.2.1.x releases in the maint-0.2.1 branch,
and periodically merge the maint-0.2.1 branch into master
i guess nobody has done that merge lately

arma: Ah, okay. Then maybe the link at the download page to the changelog should get updated (or point to a version from the current tarball).

yes. hm.
once upon a time we had source tree checkouts to link to
we got rid of those when we moved to git, because officially there's no such thing as "the checkout". that makes me sad.

arma: Why not just use a git checkout using the tag of the release?

why not indeed. because the nice volunteer setting up the gitweb isn't doing that. :)

https://gitweb.torproject.org//tor.git?a=blob;f=ChangeLog;hb=tor-0.2.1.25 that exists.
and the nice volunteer thought his work was done with gitweb because everyone was happy, and that he didn't need to convince we*sel that we should use non-stable debian packages

i wonder if we should change the ChangeLog url to point to hb=<version> and let wml keep updating the url.

I'm not sure what kind of checkout people want.
I think gitweb is fine