On Tue, Sep 14, 2010 at 7:13 PM, Fess <email@example.com> wrote:
> On 04:00 Sun 12 Sep , David C. Rankin wrote:
> > On 09/09/2010 07:40 AM, Fess wrote:
> >> Page "Local mirros" was removed from wiki by this reason:
> >> -----
> >> It is generally frowned upon to create a local mirror due the bandwidth
> that is required.
> >> There is not a good reason to create a local mirror, since one of the
> alternatives below will likely meet your needs.
> >> -----
> >> I think it's very useful ability, and why this page was removed... i
> don't know. It's silly.
> >> If anyone else think it must be return - maybe we should do it?
> >> P.S.
> >> A lot of guys agreed with me this morning, so i think many people want
> this article back.
> > I looked into an Arch local 'mirror/repo' when I started using Arch,
> > similar to what I used to maintain for my SuSE installs. (the local
> > mirror page was a mess and wrong then as well) However, since Arch will
> > check for the presence of packages in /var/cache/pacman/pkg
> > before/(instead of) re-downloading the packages, for local network boxes,
> > it was just easier to use rsync to grab the packages from whatever box
> > did the most recent update and transfer then to the nextbox you need to
> > update (same architecture only).
> > The only caveat is you need a way to manage duplicate (old packages) in
> > /var/cache/pacman/pkg so I came up with a script that does that.
> > So instead of worrying about a 'local mirror', just:
> > (1) rsync -uav updatedbox:/var/cache/pacman/pkg nextbox:/var/cache/pacman
> > (2) grab the following 2 scripts:
> > (the wrapper script that calls the main script [twice - see why below])
> > http://www.3111skyline.com/dl/Archlinux/scripts/fduparch.sh
> > (the main duplicate identification and removal script)
> > http://www.3111skyline.com/dl/Archlinux/scripts/fduppkg
> > Put them both in /usr/local/bin (or link them there), edit fduparch.sh
> > and change the directories you want the duplicates from
> > /var/cache/pacman/pkg moved to (default is /home/backup/pkg-old and for
> > the second pass to /home/backup/pkg-older). Then after updating one box,
> > just call fduparch.sh (the wrapper script) as root and the duplicates in
> > /var/cache/pacman/pkg are moved as follows:
> > Pass 1:
> > /var/cache/pacman/pkg => /home/backup/pkg-old
> > Pass 2:
> > /home/backup/pkg-old => /home/backup/pkg-older
> > Which leaves you with the current set of packages in:
> > /var/cache/pacman/pkg
> > The last used packages before update in:
> > /home/backup/pkg-old
> > And finally all older packages in:
> > /home/backup/pkg-older
> > which can be deleted or archived. (of course you can delete the packages
> > in /home/backup/pkg-old if you like as well)
> > NOTE: the duplicate removal script uses the file ctime and/or mtime to
> > determine which is the newer package, so when copying machine to machine
> > with rsync, make sure you preserve the file attributes. (rsync's -a
> > option works fine).
> > Once you set this up, maintaining a local set of packages is a breeze,
> > (1) pacman -Syu as normal on one box (works the same for new installs
> > (2) fduparch.sh (as root to remove the older versions of new packages)
> > (3) rsync -uav updatedbox:/var/cache/pacman/pkg nextbox:/var/cache/pacman
> > (only for boxes of the same architecture of course)
> > (4) pacman -Syu on the box you rsync'ed the packages to (nextbox)
> > (5) call fduparch.sh on the box you just updated (nextbox), and so on,
> and so on...
> > As long as your boxes have reasonably similar packages installed, this
> > eliminates 90+% of re-downloading, takes no additional bandwidth because
> > you have to download the updated packages once anyway, and is simple
> > enough for me to manage so you guy will have no problems with it
> > And if you wanted to get even more creative, you could simply write a
> > script on your main box that you update to automate the entire process
> > for all your local boxes using nothing more than rsync and ssh calls of
> > run the updates and dup removal scripts. (I haven't been that creative
> > yet) Just remember to separate your boxes into groups/classes by
> > architecture (i686 & x86_64)
> > Cheers.
> > --
> > David C. Rankin, J.D.,P.E.
> > Rankin Law Firm, PLLC
> > 510 Ochiltree Street
> > Nacogdoches, Texas 75961
> > Telephone: (936) 715-9333
> > Facsimile: (936) 715-9339
> > www.rankinlawfirm.com
> err.. what?
> Don't you think, that mirrorsync in crontab is MUCH more easier way to get
> new packages, huh?
> I'm using local mirror for 3 years and i have no idea why i shoulnd't use
> it know.
> If you have local mirror, you won't worry about 3-4 another GB's. You just
> download some less porn. Less porn -> more profit.
made my day
Kirill E. Churin
Jabber: firstname.lastname@example.org, ICQ: 8163230, Skype on demand.
In a world *without walls* or fences, *who needs windows and gates?*
Tue Sep 14 16:30:03 2010
Delivery-date: Tue, 14 Sep 2010 15:30:57 +0300
Received: from bastion02.fedoraproject.org ([220.127.116.11]:48544 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
for email@example.com; Tue, 14 Sep 2010 15:30:56 +0300
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [192.168.1.21])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id 5FD23110DE9;
Tue, 14 Sep 2010 13:21:40 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id AD66D32679E;
Tue, 14 Sep 2010 13:21:39 +0000 (UTC)
Received: from smtp-mm3.fedoraproject.org (smtp-mm3.fedoraproject.org
by lists.fedoraproject.org (Postfix) with ESMTP id 5B2ED326795
Tue, 14 Sep 2010 13:21:37 +0000 (UTC)
Received: from mail-wy0-f173.google.com (mail-wy0-f173.google.com
by smtp-mm3.fedoraproject.org (Postfix) with ESMTP id D8A3237CC3
Tue, 14 Sep 2010 13:21:36 +0000 (UTC)
Received: by wyb39 with SMTP id 39so7077925wyb.32
Tue, 14 Sep 2010 06:21:34 -0700 (PDT)
Received: by 10.216.93.10 with SMTP id k10mr3940118wef.38.1284470493977; Tue,
14 Sep 2010 06:21:33 -0700 (PDT)
Received: by 10.216.135.220 with HTTP; Tue, 14 Sep 2010 06:21:33 -0700 (PDT)
Date: Tue, 14 Sep 2010 08:21:33 -0500
Message-ID: <AANLkTim1_NFSOtXo9yQ+vaKG_AEaHZ6hdXfjJ9+QS+Bu@mai l.gmail.com>
Subject: Re: ogre3d lagging behind more than half a year
From: =?ISO-2022-JP?B?Q29uYW4gS3VkbyAoGyRCJUshPCVrISYlNCVzJVEbKEIp? =
To: Development discussions related to Fedora <firstname.lastname@example.org>
Reply-To: Development discussions related to Fedora
List-Id: Development discussions related to Fedora
Content-Type: multipart/mixed; boundary="===============0124823647901196966=="
Content-Type: multipart/alternative; boundary=0016e6d99cb7849f6504903817f9
Content-Type: text/plain; charset=ISO-8859-1
I don't think it would have been too late for Fedora 14. It isn't a core
package that needs to be available in a spin, afaik...
On Tue, Sep 14, 2010 at 4:43 AM, Rudolf Kastl <email@example.com> wrote:
> ogre3d, one of the most important 3d engines we have in fedora is
> already lagging behind over half a year in rawhide:
> would be nice to see it finally updated atleast in rawhide so it can
> go atleast in f15... which means we are only 1 year behind by then.
> kind regards,
> Rudolf Kastl
> devel mailing list
Content-Type: text/html; charset=ISO-8859-1
I don't think it would have been too late for Fedora 14. It isn't a=
core package that needs to be available in a spin, afaik...<br><br><div cl=
ass=3D"gmail_quote">On Tue, Sep 14, 2010 at 4:43 AM, Rudolf Kastl <span dir=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">heyyas,<br>
ogre3d, one of the most important 3d engines we have in fedora is<br>
already lagging behind over half a year in rawhide:<br>
<a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D576286" target=3D"=
would be nice to see it finally updated atleast in rawhide so it can<br>
go atleast in f15... which means we are only 1 year behind by then.<br>
devel mailing list<br>
<a href=3D"mailto:firstname.lastname@example.org">deve email@example.com.=
<a href=3D"https://admin.fedoraproject.org/mailman/listinfo/devel" target=
Content-Type: text/plain; charset="us-ascii"
devel mailing list