*****

ssri · 2010-06-30 18:57:50

Xyne wrote:

@ssri
This isn't a reflector issue. Pacman 3.4.0 introduced the $arch variable and it is now used in the official mirrorlist.
It seems that you haven't merged /etc/pacman.conf.pacnew into /etc/pacman.conf.
You should always pay attention to the output of an upgrade operation as it issues warnings about configuration file changes that require manual intervention. You may want to run the following commands to locate all *.pacnew and *.pacsave files on your system.
updatedb
locate "*.pac*"

doh! thanks! I believe I upgrade a slew of packages that day and must have missed that message.

Cookie · 2010-08-05 10:23:01

Xyne wrote:

Filtering by region might make sense in some cases but generally I don't think it would make much difference. It's possible to get good speeds from geographically distant servers and I would expect the latency to be negligible for most operations.
If there really is a demand for this I can ask Pierre to include country codes in Reflector's custom status page and add a filter. I might even try writing some code to ping servers to estimate network distance, just to see if I can.

I would love to see region filtering, most of the time when I update mirrorlist with reflector, it returns servers that are other end of the world, syncing with them takes ages so I manually edit them out. Would be neat to get the latest and fastest mirrors that is in my geographical area which is Europe.

Xyne · 2010-08-05 18:11:04

I've sent an email to Pierre about parameterizing the interface to enable the inclusion of available geographic data. I'll post an update once I get a reply.

Xyne · 2010-08-06 16:58:50

Ok, Reflector now supports filtering by country using the "--country" and "-c" options. Use "--country %own%" to automatically detect your own. You can also pass the "--country" option multiple times to create a list, e.g.

reflector -c Canada -c "United States" -c Mexico

for North America.

Install the latest version of perl-xyne-arch from my site to try it. I will push it to [community] after a little more testing.

SanskritFritz · 2010-08-06 17:04:13

Wow, thank you!

Cookie · 2010-08-07 09:26:37

Xyne wrote:

Ok, Reflector now supports filtering by country using the "--country" and "-c" options. Use "--country %own%" to automatically detect your own. You can also pass the "--country" option multiple times to create a list, e.g.
reflector -c Canada -c "United States" -c Mexico
for North America.
Install the latest version of perl-xyne-arch from my site to try it. I will push it to [community] after a little more testing.

Thank you soooo much!

Edit: just tried it. it works perfectly

Last edited by Cookie (2010-08-07 09:53:42)

havresylt · 2010-08-08 11:25:33

Hi, I really like this utility. However, what I found a bit weird is that it does _not_ sort the mirrors by default. Of course there is the '-l N' option, but if I want to get a list of all the mirrors sorted, I manually have to choose the right value for N. If I choose it to large I get errors. In my opinion, '-l' without the N should do what I want.

I tried fixing this, but it seems like Xyne::Common::OptionHandler lacks support for options with optional arguments. I wonder if one could just make a new property 'optional' parallel with all the others. I.e. an option could be either float, int, bool, etc. AND either optional or not. Now of course non-optional doesn't really make sense for 'switch'...

Of course, the easy fix for this would be to just have negative N's give the full list.

The way I use this now is sort of the opposite of how you're supposed to use it. I first fetch the N fastest servers with rankmirrors, and then sort them according to uptodateness with reflector:

# get the fastest servers                                                                                                                                                                                           
rankmirrors -n $num_to_rank $CANDIDATES_FILE > $fastest

# get index of uptodateness -- here is where I want to be able to omit the hard coded number!
reflector -l 128 > $by_uptodate

# sort fastest by uptodateness                                                                                                                                                                                      
grep '^[^#]' $by_uptodate |
while read l
do
    grep "^$l" $fastest
done > $DEST_FILE

In my opinion, it is more important to have a recent mirror rather than the very fastest (usually I take the 20 fastest which are all very fast). Consider adding functionality for doing things in this order also.

Btw, your website has lots of cool stuff!

anonymous_user · 2010-08-08 17:30:00

havresylt wrote:

In my opinion, it is more important to have a recent mirror rather than the very fastest

So then why don't you use just use reflector to get some recent mirrors, and use reflector's -r flag to rank them according to speed.

havresylt · 2010-08-11 05:50:54

anonymous_user wrote:

havresylt wrote:
In my opinion, it is more important to have a recent mirror rather than the very fastest
So then why don't you use just use reflector to get some recent mirrors, and use reflector's -r flag to rank them according to speed.

Yes, I could do that and it would give me similar results, but it would not give me the _same_ result. They do _not_ commute. I don't know which one is smarter, but with the possibility to do both, people could decide for themselves.

Xyne · 2010-08-13 23:31:23

havresylt wrote:

Hi, I really like this utility. However, what I found a bit weird is that it does _not_ sort the mirrors by default. Of course there is the '-l N' option, but if I want to get a list of all the mirrors sorted, I manually have to choose the right value for N. If I choose it to large I get errors. In my opinion, '-l' without the N should do what I want.

The list is already in descending order by last update, so unless I've misunderstood you, you should simply omit the "-l" flag as that will give you the full "sorted" mirrorlist.

havresylt wrote:

I tried fixing this, but it seems like Xyne::Common::OptionHandler lacks support for options with optional arguments. I wonder if one could just make a new property 'optional' parallel with all the others. I.e. an option could be either float, int, bool, etc. AND either optional or not. Now of course non-optional doesn't really make sense for 'switch'...

Catching options with optional arguments is difficult when you have to take non-option arguments into account. You can use the "str" option type with an empty string, but there are few cases in which you would actually want an option with an optional argument. Normally you can or should structure the options differently.

havresylt wrote:

In my opinion, it is more important to have a recent mirror rather than the very fastest (usually I take the 20 fastest which are all very fast). Consider adding functionality for doing things in this order also.

I agree, but I don't think it makes that much of a difference. Consider the following cases:

* using pacman:
You only use 1 mirror at a time and a fast up-to-date mirror very rarely fails, so you will only use the first mirror in the list most of the time. You definitely don't need more than 5 and the 5 most recent servers are almost always within 1 hour of each other. Ranking them by speed will thus give you the fastest of the most recent mirrors. I don't think it really matters if the fastest is an hour or 2 behind the most recent. The only way the fastest would be way behind is if you filter a large number but, as mentioned above, there is no reason to do that with pacman.

* using powerpill/bauerbill
Parallel and segmented downloads reduce the significance of the speed of each individual server, whereas the importance of each server being in sync is increased. Filtering first by speed wouldn't be useful most of the time.

Also, filtering first by the latest number of mirrors reduces the load and runtime of rankmirrors. Passing it 100 plus mirrors to filter by speed first is very slow.

That stated, I would be more inclined to add an option to invert the order if I didn't rely on rankmirrors for the speed filter. I already think that portion of the code is ugly (by my own Perl standards, which doesn't say much), and adding support to invert the order would be even kludgier. Nag me hard enough though and I will probably add such an option.

havresylt wrote:

Btw, your website has lots of cool stuff!

Thanks

havresylt · 2010-08-18 20:25:38

Xyne wrote:

That stated, I would be more inclined to add an option to invert the order if I didn't rely on rankmirrors for the speed filter. I already think that portion of the code is ugly (by my own Perl standards, which doesn't say much), and adding support to invert the order would be even kludgier. Nag me hard enough though and I will probably add such an option.

Actually, I think you have convinced me to do it the other way. So I don't really have any interest in it anymore.

Last edited by havresylt (2010-08-18 20:27:27)

Arch Linux

#51 2010-06-30 18:57:50

Re: *****

#52 2010-08-05 10:23:01

Re: *****

#53 2010-08-05 18:11:04

Re: *****

#54 2010-08-06 16:58:50

Re: *****

#55 2010-08-06 17:04:13

Re: *****

#56 2010-08-07 09:26:37

Re: *****

#57 2010-08-08 11:25:33

Re: *****

#58 2010-08-08 17:30:00

Re: *****

#59 2010-08-11 05:50:54

Re: *****

#60 2010-08-13 23:31:23

Re: *****

#61 2010-08-18 20:25:38

Re: *****

Board footer