Discussion:
Mageia3, beta4 torrent
(too old to reply)
Ar
2013-04-02 08:54:04 UTC
Permalink
Has anyone managed to download the file to enable the torrent to be used
for the latest beta? The ISOs seem to be at the local mirrors, but
nobody has a torrent file. I prefer not to hammer someone's server for
the entire 4GB.
Bit Twister
2013-04-02 11:21:38 UTC
Permalink
Post by Ar
Has anyone managed to download the file to enable the torrent to be used
for the latest beta? The ISOs seem to be at the local mirrors, but
nobody has a torrent file. I prefer not to hammer someone's server for
the entire 4GB.
1. Would you care to indicate which torrent you are trying, from what mirror.

2. You do know the beta4 live iso have not been released yet. :(

Mageia-3-beta4-x86_64-DVD.iso downloaded from mirror is working pretty good.
unruh
2013-04-02 15:40:20 UTC
Permalink
Post by Bit Twister
Post by Ar
Has anyone managed to download the file to enable the torrent to be used
for the latest beta? The ISOs seem to be at the local mirrors, but
nobody has a torrent file. I prefer not to hammer someone's server for
the entire 4GB.
1. Would you care to indicate which torrent you are trying, from what mirror.
His complaint is that he can find NO torrent. Not that he is trying one,
and it is failing.
Post by Bit Twister
2. You do know the beta4 live iso have not been released yet. :(
Mageia-3-beta4-x86_64-DVD.iso downloaded from mirror is working pretty good.
I think he is asking whether there is a torrent for
Mageia-3-beta4-x86_64-DVD.iso so he does not have to download it from
one mirror, overloading the mirror, and having a very long download
because of that overload.
Ar
2013-04-02 18:19:42 UTC
Permalink
Post by unruh
Post by Bit Twister
1. Would you care to indicate which torrent you are trying, from what mirror.
His complaint is that he can find NO torrent. Not that he is trying one,
and it is failing.
Correct.

This is being looked into.
Post by unruh
Post by Bit Twister
2. You do know the beta4 live iso have not been released yet. :(
Mageia-3-beta4-x86_64-DVD.iso downloaded from mirror is working pretty good.
I think he is asking whether there is a torrent for
Mageia-3-beta4-x86_64-DVD.iso so he does not have to download it from
one mirror, overloading the mirror, and having a very long download
because of that overload.
I am not bothered at the speed as such, it downloads when it downloads.
I would of course like to not eat into the Mageia's or specific mirror's
bandwidth, which using torrents means it's spread around.
David W. Hodgins
2013-04-02 18:27:06 UTC
Permalink
Post by Ar
I am not bothered at the speed as such, it downloads when it downloads.
I would of course like to not eat into the Mageia's or specific mirror's
bandwidth, which using torrents means it's spread around.
You'd enjoy being on the qa team, where we all download all of the iso
images (15GB), from one server. :-)

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Ar
2013-04-02 19:08:49 UTC
Permalink
Post by David W. Hodgins
Post by Ar
I am not bothered at the speed as such, it downloads when it downloads.
I would of course like to not eat into the Mageia's or specific mirror's
bandwidth, which using torrents means it's spread around.
You'd enjoy being on the qa team,
If I had a better grip and more knowledge of Linux I would submit to the
torture. As it is, I just report bugs I find in "normal" usage.
Post by David W. Hodgins
where we all download all of the iso images (15GB), from one server. :-)
Sounds like fun, should grind a server very slowly.
David W. Hodgins
2013-04-02 21:55:18 UTC
Permalink
Post by Ar
Post by unruh
Post by Bit Twister
1. Would you care to indicate which torrent you are trying, from what mirror.
His complaint is that he can find NO torrent. Not that he is trying one,
and it is failing.
Correct.
The torrent files are going out to the mirrors now.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Bit Twister
2013-04-03 01:16:47 UTC
Permalink
Post by David W. Hodgins
The torrent files are going out to the mirrors now.
Having seen the occasional incorrect sum and/or missing torrent file,
you would think they would have a script to automagically create them
and push them when they release an iso out to the production/public mirror.
David W. Hodgins
2013-04-03 01:47:13 UTC
Permalink
Post by Bit Twister
Post by David W. Hodgins
The torrent files are going out to the mirrors now.
Having seen the occasional incorrect sum and/or missing torrent file,
you would think they would have a script to automagically create them
and push them when they release an iso out to the production/public mirror.
I think there is, but the person who normally does that
is the same person who produces the live iso images,
and he's been pretty sick lately.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Bit Twister
2013-04-03 02:02:56 UTC
Permalink
Post by David W. Hodgins
Post by Bit Twister
Post by David W. Hodgins
The torrent files are going out to the mirrors now.
Having seen the occasional incorrect sum and/or missing torrent file,
you would think they would have a script to automagically create them
and push them when they release an iso out to the production/public mirror.
I think there is, but the person who normally does that
is the same person who produces the live iso images,
and he's been pretty sick lately.
Ah, ha, alternate/backup bio unit did not follow iso to production migration
checklist. :(

I still think migration script's job should check for all required
items before doing the move. Any missing items aborts the move.
After the move, verify moved items are valid.
David W. Hodgins
2013-04-05 06:41:22 UTC
Permalink
Post by Bit Twister
Ah, ha, alternate/backup bio unit did not follow iso to production migration
checklist. :(
In this case, it's actually three separate functions. Anne produces the
classical installer iso images. Thomas produces the live iso images.
Thomas produces the torrent files for both, once they've passed qa approval.

As Thomas was ill, and just as he returned, a critical bug was found in how
the live iso images are built was found.
https://bugs.mageia.org/show_bug.cgi?id=9326
production of the live iso images has been delayed.

As the classical iso images had passed the qa requirements for a beta, the
decision was made to go ahead and release them. That was done before
Thomas returned to being available, so the production of the torrent files
didn't happen, until after his return.

Now that bug 9326 has been figured out, the live iso images have been
delayed again, in order to have the latest kde updates included. (The
push of the new kde packages shouldn't have started till all of beta4
had been released, but that's a minor problem, for another discussion).

As a volunteer community developed distribution, we do have some critical
people, where no-one else is ready to take over there function, if they are
not available.

If the person becomes permanently unavailable, we'll have to get someone else
to volunteer to take over their functions, keeping in mind that it will take
them some time to get up to speed.

That's why releases will be made available when they are ready, not necessarily
on some date decided 9 months or more in advance.

Currently, live iso images are expected to start qa testing within the next
24 hours.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Bit Twister
2013-04-05 11:44:21 UTC
Permalink
Post by David W. Hodgins
Post by Bit Twister
Ah, ha, alternate/backup bio unit did not follow iso to production migration
checklist. :(
In this case, it's actually three separate functions. Anne produces the
classical installer iso images. Thomas produces the live iso images.
Thomas produces the torrent files for both, once they've passed qa approval.
As a volunteer community developed distribution, we do have some critical
people, where no-one else is ready to take over there function, if they are
not available.
Oh, I understand completely. My suggestion, is at a given activity/milestone
the/a generation/migration script should generate required items and
maybe run some audits. If unable to automate the process, then a
procedural document have to be made available.

Example: generate_iso Mageia-3-beta4-dual-CD, which parse the name,
generate it, check size, generate sums and torrents. Just a rough example:

_rtn_code=0
_exe=$0
_app=$(basename $_exe)
_rpt_fn=/var/tmp/$_app.rpt
_iso_fn=$1

/bin/rm -f $_rpt_fn

if [[ "$_iso_fn" == *Live* ]] ; then
_iso_type="Live"
else
_iso_type="normal"
fi

Bunch of iso generation magic happens here based on arguments.

#***************
#* audit iso
#***************

for _iso in /some/dir/*.iso
set -- $(IFS='.' ; echo $_iso)
_fn=$(basename $1)
set -- $(IFS='-' ; echo $_fn)
shift $(($# - 2))
_iso_media=$2
_arch=$1

case $_iso_media in
CD) _max_size=nnn ;;
DVD) _max_size=nnn ;;
*) echo Unknown media type: $_iso_media >> $_rpt_fn
_rtn_code=1
;;
esac

_iso_size=$(stat --format=%s $_iso)
if [ $_iso_size -gt $_max_size ] ; then
$_bytes=$(echo $_iso_size - $_max_size | bc)
echo "Error $_iso is $_bytes too big for $_iso_media" >> $_rpt_fn
_rtn_code=1
fi

_t_fn=/some/dir/torrent/$_fn.torrent
if [ ! -e $_t_fn ] ; then
echo " $_t_fn does not exists" >> $_rpt_fn
_rtn_code=1
fi

done

if [ $_rtn_code -ne 0 ] ; then
mail -s "$_exe Failure with $_iso_fn" $USER,$_DEPT_HEADS < $_rpt_fn
fi
exit $_rtn_code



When happy with iso. run migration script which moves iso, sums, torrents
onto public mirror, runs public audit, and removes what was migrated.
Post by David W. Hodgins
Now that bug 9326 has been figured out, the live iso images have been
delayed again, in order to have the latest kde updates included.
That is kinda nice, I know the dual had ~100 updates on my install the
day of public release. Live users will have much less updates.
unruh
2013-04-05 16:41:14 UTC
Permalink
Post by Bit Twister
Post by David W. Hodgins
Post by Bit Twister
Ah, ha, alternate/backup bio unit did not follow iso to production migration
checklist. :(
In this case, it's actually three separate functions. Anne produces the
classical installer iso images. Thomas produces the live iso images.
Thomas produces the torrent files for both, once they've passed qa approval.
As a volunteer community developed distribution, we do have some critical
people, where no-one else is ready to take over there function, if they are
not available.
Oh, I understand completely. My suggestion, is at a given activity/milestone
the/a generation/migration script should generate required items and
maybe run some audits. If unable to automate the process, then a
procedural document have to be made available.
The problem is that a) those scripts have to be debugged, and b) almost
always, a new distro will mean that the scripts have to be updated. At
least that is what I find for most of the scripts I genereate to
automate the updating of the installation of each new distro. (eg
cheking that tex is installed, bringing over the password/shadow
password database, tweaking /etc/inittab and msec to remove the absurd
ACD reboot behaviour, etc. Except that each new release breaks something
new, and changes how it broke the old stuff.
Post by Bit Twister
Example: generate_iso Mageia-3-beta4-dual-CD, which parse the name,
_rtn_code=0
_exe=$0
_app=$(basename $_exe)
_rpt_fn=/var/tmp/$_app.rpt
_iso_fn=$1
/bin/rm -f $_rpt_fn
if [[ "$_iso_fn" == *Live* ]] ; then
_iso_type="Live"
else
_iso_type="normal"
fi
Bunch of iso generation magic happens here based on arguments.
#***************
#* audit iso
#***************
for _iso in /some/dir/*.iso
set -- $(IFS='.' ; echo $_iso)
_fn=$(basename $1)
set -- $(IFS='-' ; echo $_fn)
shift $(($# - 2))
_iso_media=$2
_arch=$1
case $_iso_media in
CD) _max_size=nnn ;;
DVD) _max_size=nnn ;;
*) echo Unknown media type: $_iso_media >> $_rpt_fn
_rtn_code=1
;;
esac
_iso_size=$(stat --format=%s $_iso)
if [ $_iso_size -gt $_max_size ] ; then
$_bytes=$(echo $_iso_size - $_max_size | bc)
echo "Error $_iso is $_bytes too big for $_iso_media" >> $_rpt_fn
_rtn_code=1
fi
_t_fn=/some/dir/torrent/$_fn.torrent
if [ ! -e $_t_fn ] ; then
echo " $_t_fn does not exists" >> $_rpt_fn
_rtn_code=1
fi
done
if [ $_rtn_code -ne 0 ] ; then
mail -s "$_exe Failure with $_iso_fn" $USER,$_DEPT_HEADS < $_rpt_fn
fi
exit $_rtn_code
When happy with iso. run migration script which moves iso, sums, torrents
onto public mirror, runs public audit, and removes what was migrated.
Post by David W. Hodgins
Now that bug 9326 has been figured out, the live iso images have been
delayed again, in order to have the latest kde updates included.
That is kinda nice, I know the dual had ~100 updates on my install the
day of public release. Live users will have much less updates.
Bit Twister
2013-04-05 18:07:07 UTC
Permalink
Post by unruh
The problem is that a) those scripts have to be debugged, and b) almost
always, a new distro will mean that the scripts have to be updated.
I understand where you are coming from, but in this case, whatever
magical process generates the iso doesn't matter.

What matters is the migration of the product across boundaries.
Theoretically, iso tech runs the generate_iso script in his/her
account. Once happy, runs migrate_iso -testing, then migrate_iso -QA.
On release day, someone runs migrate_iso -release.
The script run the checks on the items needed by the next
boundary/milestone/phase.
Post by unruh
At
least that is what I find for most of the scripts I genereate to
automate the updating of the installation of each new distro.
Boy, I hear that. Seems like RC is where I get all the surprises
despite regressing testing alpha, beta 1,2,3, now 4.
Post by unruh
(eg cheking that tex is installed,
Yep, I built a x_urpmi function. Anytime a package I use goes missing
I just add it to install_addons. x_urpmi checks to see if installed
and if not, install the package.
Post by unruh
bringing over the password/shadow password database,
I automated that by moving all user UID/GID to > 1499. Backup
script automagically extracts those and my install_changes appends
them back to passwd/shadow/group files.
Post by unruh
tweaking /etc/inittab and msec to remove the absurd
ACD reboot behaviour, etc.
Yup, I add if cron lock file exists, don't run, to a few of those myself.
My burn_iso touches the lock file and deletes it after burn just to make
sure burner fifo is always 90% full.
Post by unruh
Except that each new release breaks something
new, and changes how it broke the old stuff.
I hear that. I have a disable_server and enable_servers script.
Wrote a system_ctl function script to detect if I should run systemctl or
chkconfig to en/disable stop/start some daemon based on distribution
release.

Something like my "new_boot_logs" script has to decide if release is
using journalct or rsyslog to know what/how to empty the log files.


As for install scripts:
$ ls install_* | wc -l
33

Then there are my
$ ls *_changes | wc -l
52
scripts which change configuration file settings.
unruh
2013-04-05 20:59:57 UTC
Permalink
Post by Bit Twister
Post by unruh
bringing over the password/shadow password database,
I automated that by moving all user UID/GID to > 1499. Backup
script automagically extracts those and my install_changes appends
them back to passwd/shadow/group files.
This is an example. It used to be that all system IDs were less than
uid=100. They they upped that to 200, then to 500, then to 1000. I have
a system that has been runnning for almost 30 years, constantly
migrating (Apollo OS->SunOS->Linux(Mandrake->Mandriva->Mageia) and many
users have stayed the same, and many of the scripts were written 20
years ago. But what do I do when they arbitrarily decided to change the
minimum for user uids? Spend time changing all of the users uids? (and
breaking a bunch of stuff in the process)? And every 3 years or so when
they decide that 500 uids are not enough for system stuff? (of course
they onely ever use about 20 of those uids, but need to reserver 500.
And then always stuff some into the maximum.)
Bit Twister
2013-04-05 21:39:02 UTC
Permalink
Post by unruh
Post by Bit Twister
Post by unruh
bringing over the password/shadow password database,
I automated that by moving all user UID/GID to > 1499. Backup
script automagically extracts those and my install_changes appends
them back to passwd/shadow/group files.
This is an example. It used to be that all system IDs were less than
uid=100. They they upped that to 200, then to 500, then to 1000. I have
a system that has been runnning for almost 30 years, constantly
migrating (Apollo OS->SunOS->Linux(Mandrake->Mandriva->Mageia) and many
users have stayed the same, and many of the scripts were written 20
years ago. But what do I do when they arbitrarily decided to change the
minimum for user uids? Spend time changing all of the users uids? (and
breaking a bunch of stuff in the process)? And every 3 years or so when
they decide that 500 uids are not enough for system stuff? (of course
they onely ever use about 20 of those uids, but need to reserver 500.
And then always stuff some into the maximum.)
Yeah, I know, checking the vendor installed files:
$ wc -l < /etc/passwd_vinstall
38

$ wc -l < /etc/group_vinstall
63

But when I went to modify pulseaudio to run as a system wide audio server,
groupadd --force --system pulse
adduser --system --gid pulse --home-dir /var/run/pulse pulse
usermod -a -G audio pulse
groupadd --force --system pulse-access

I wound up with
$ grep pulse: /etc/group
pulse:x:411:

89 slots left is not much room for growth, using the "standard
assignment" method, even though there were only 63 GIDs used prior to
my changes. :(

I would have thought it would be fairly easy to write a script to just
add 1000 to user's UID/GID above 499, chown -R their home
directories, and use find to fix files in other directories.

If scripts have UID/GID for users, then that would be somewhat more of
a challenge.
Bit Twister
2013-04-06 03:32:30 UTC
Permalink
Post by Bit Twister
I wound up with
$ grep pulse: /etc/group
89 slots left is not much room for growth, using the "standard
assignment" method, even though there were only 63 GIDs used prior to
my changes. :(
Sorry.

After looking at a sorted view of groups and passwd, I see that the
--system argument causes groupadd and adduser to look backwards from
GID_MIN/UID_MIN values, in /etc/login.defs, for the first unused GID/UID.
unruh
2013-04-06 04:10:52 UTC
Permalink
Post by Bit Twister
Post by unruh
Post by Bit Twister
Post by unruh
bringing over the password/shadow password database,
I automated that by moving all user UID/GID to > 1499. Backup
script automagically extracts those and my install_changes appends
them back to passwd/shadow/group files.
This is an example. It used to be that all system IDs were less than
uid=100. They they upped that to 200, then to 500, then to 1000. I have
a system that has been runnning for almost 30 years, constantly
migrating (Apollo OS->SunOS->Linux(Mandrake->Mandriva->Mageia) and many
users have stayed the same, and many of the scripts were written 20
years ago. But what do I do when they arbitrarily decided to change the
minimum for user uids? Spend time changing all of the users uids? (and
breaking a bunch of stuff in the process)? And every 3 years or so when
they decide that 500 uids are not enough for system stuff? (of course
they onely ever use about 20 of those uids, but need to reserver 500.
And then always stuff some into the maximum.)
$ wc -l < /etc/passwd_vinstall
38
$ wc -l < /etc/group_vinstall
63
But when I went to modify pulseaudio to run as a system wide audio server,
groupadd --force --system pulse
adduser --system --gid pulse --home-dir /var/run/pulse pulse
usermod -a -G audio pulse
groupadd --force --system pulse-access
I wound up with
$ grep pulse: /etc/group
89 slots left is not much room for growth, using the "standard
assignment" method, even though there were only 63 GIDs used prior to
my changes. :(
They are lazy. They count down-- ie they start to add them from 499 down
if they are things like pulse, Then others count up and others demand a
certain number.
Post by Bit Twister
I would have thought it would be fairly easy to write a script to just
add 1000 to user's UID/GID above 499, chown -R their home
directories, and use find to fix files in other directories.
If scripts have UID/GID for users, then that would be somewhat more of
a challenge.
Jim Beard
2013-04-02 12:46:41 UTC
Permalink
Post by Ar
Has anyone managed to download the file to enable the torrent to
be used for the latest beta? The ISOs seem to be at the local
mirrors, but nobody has a torrent file. I prefer not to hammer
someone's server for the entire 4GB.
Downloading torrents actually takes more bandwidth, total.
Spreading it around just rearranges who carries the load.

If you wish to minimize the burden, do the download when it is
after midnight both where you are and where you are downloading
from. The load on servers drops dramatically immediately after
the witching hour, regardless of location in the world.

Cheers!

jim b.
--
UNIX is not user unfriendly; it merely
expects users to be computer-friendly.
unruh
2013-04-02 15:44:10 UTC
Permalink
Post by Jim Beard
Post by Ar
Has anyone managed to download the file to enable the torrent to
be used for the latest beta? The ISOs seem to be at the local
mirrors, but nobody has a torrent file. I prefer not to hammer
someone's server for the entire 4GB.
Downloading torrents actually takes more bandwidth, total.
Spreading it around just rearranges who carries the load.
Yes.
Post by Jim Beard
If you wish to minimize the burden, do the download when it is
He wishes to both minimize the burden on any single mirror, AND increase
the speed of his download.
Post by Jim Beard
after midnight both where you are and where you are downloading
from. The load on servers drops dramatically immediately after
the witching hour, regardless of location in the world.
Unfortunately, since downloading can occur from anywhere in the world,
and since it is always noon, not midnight, somewhere, this is less
useful than it seems. Similarly, with torrents it is always midnight
somewhere, and if your torrent finds that server, your download goes
quickly. Of course it could get stuck with someone who has a 300bps
modem.
Post by Jim Beard
Cheers!
jim b.
Jim Beard
2013-04-03 01:18:35 UTC
Permalink
Post by unruh
Post by Jim Beard
If you wish to minimize the burden, do the download when it is
He wishes to both minimize the burden on any single mirror, AND increase
the speed of his download.
Post by Jim Beard
after midnight both where you are and where you are downloading
from. The load on servers drops dramatically immediately after
the witching hour, regardless of location in the world.
Unfortunately, since downloading can occur from anywhere in the world,
and since it is always noon, not midnight, somewhere, this is less
useful than it seems. Similarly, with torrents it is always midnight
somewhere, and if your torrent finds that server, your download goes
quickly. Of course it could get stuck with someone who has a 300bps
modem.
Downloaders can be anywhere in the world, in any time zone, but
the statistics show that overwhelmingly when it goes past
midnight where a server is located, that server's load will drop
dramatically.

This is not because it has to, nor there are no other
possibilities, but absent very deliberate load-sharing to counter
customary effects, when it goes past midnight where the server is
located load drops and stays down until 5 or 6 a.m. there.
Resumption of load is more diffuse, as different people in
different places tend to arrive at work and start working at
slightly different times.

To minimize the load at the sending end and receiving end (the
OP's ISP is presumably operating a local server that delivers the
bytes to the OP's machine), pick a time when it is between
midnight and roughly 5 am at both ends.

Theory says the load can be anything anywhere. Reality says that
load drops when the witching hour arrives.

Cheers!

jim b.
--
UNIX is not user unfriendly; it merely
expects users to be computer-friendly.
Bit Twister
2013-04-03 01:28:57 UTC
Permalink
, pick a time when it is between midnight and roughly 5 am at both ends.
Theory says the load can be anything anywhere. Reality says that
load drops when the witching hour arrives.
But in Cauldron's case, Mageia's mirror setup document suggest Tier 1
mirrors should rsync every 2 hours with Mageia's mirror.
I have noticed I tend to get a more complete update if I wait about 20
minutes after the hour.

It also does not hurt to look at http://pkgsubmit.mageia.org/ before
doing the update just to see I should wait to get "all" the KDE or
kernel packages.
Ar
2013-04-03 07:07:44 UTC
Permalink
To minimize the load at the sending end and receiving end (the OP's ISP
is presumably operating a local server that delivers the bytes to the
OP's machine), pick a time when it is between midnight and roughly 5 am
at both ends.
No proxies or transparent proxies at my ISP. :) I would not want an ISP
that caches stuff, you'd never know if your copy of a page / file is an
up to date version.
David W. Hodgins
2013-04-02 17:45:44 UTC
Permalink
Post by Ar
Has anyone managed to download the file to enable the torrent to be used
for the latest beta? The ISOs seem to be at the local mirrors, but
nobody has a torrent file. I prefer not to hammer someone's server for
the entire 4GB.
My guess is that the torrent file creation was forgotten when the
decision was made to push the classic installer iso images without
waiting for the live iso images.

I'll try to get it sorted out. Thanks for the notice.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Jim Whitby
2013-04-02 23:38:12 UTC
Permalink
Post by Ar
Has anyone managed to download the file to enable the torrent to be used
for the latest beta? The ISOs seem to be at the local mirrors, but
nobody has a torrent file. I prefer not to hammer someone's server for
the entire 4GB.
torrent files are available now.
Ar
2013-04-03 07:09:01 UTC
Permalink
Post by Jim Whitby
Post by Ar
Has anyone managed to download the file to enable the torrent to be used
for the latest beta? The ISOs seem to be at the local mirrors, but
nobody has a torrent file. I prefer not to hammer someone's server for
the entire 4GB.
torrent files are available now.
Thank you for letting us know.
Doug Laidlaw
2013-04-03 13:28:14 UTC
Permalink
Post by Ar
Post by Jim Whitby
Post by Ar
Has anyone managed to download the file to enable the torrent to be used
for the latest beta? The ISOs seem to be at the local mirrors, but
nobody has a torrent file. I prefer not to hammer someone's server for
the entire 4GB.
torrent files are available now.
Thank you for letting us know.
I have been watching French mirrors, Terasaur and LinuxTracker without
seeing anything, but I will keep a lookout. I downloaded the full DVD and
its md5sum. Australia and Taiwan might as well be at the Pole.

Doug.
Jim Whitby
2013-04-03 22:09:37 UTC
Permalink
On Thu, 04 Apr 2013 00:28:14 +1100, Doug Laidlaw wrote:

<snip>
Post by Doug Laidlaw
I have been watching French mirrors, Terasaur and LinuxTracker without
seeing anything, but I will keep a lookout. I downloaded the full DVD
and its md5sum. Australia and Taiwan might as well be at the Pole.
Doug.
I found mine here:

http://mageia.r0b0t.fr/linux/Mageia/iso/cauldron/torrents/
Continue reading on narkive:
Search results for 'Mageia3, beta4 torrent' (Questions and Answers)
4
replies
What's the best linux right now?
started 2013-04-06 12:42:24 UTC
computer networking
Loading...