Re: Sorry state of the rsync based CVS,replication
On Sun, 2010-11-14 at 12:13 +0100, Simon L. B. Nielsen wrote:
> There is nothing which prevents mirror sites from providing access to
> the CVS repo via rsync, even if they get it via CVSup...
I went ahead with adding this to ftp2.freebsd.org:
% rsync ftp2.freebsd.org::FreeBSD-CVS/
drwxr-xr-x 512 2010/08/02 13:35:40 .
drwxr-xr-x 512 2010/08/02 22:09:36 gnats
drwxr-xr-x 512 2010/08/03 02:34:06 mail
drwxr-xr-x 512 2010/08/02 21:50:04 ncvs
drwxr-xr-x 512 2010/08/03 00:51:26 www
%
--
Ken Smith
- From there to here, from here to | kensm...@buffalo.edu
there, funny things are everywhere. |
- Theodor Geisel |
signature.asc
Description: This is a digitally signed message part
Re: Sorry state of the rsync based CVS,replication
On Wed, 2010-10-27 at 14:45 +0200, Patrick Bihan-Faou wrote: > We use FreeBSD extensively and keep a local mirror of the CVS > repository. Up until recently things where working properly with the > various servers listed in > http://www.freebsd.org/doc/handbook/mirrors-rsync.html, but sometime > during the summer ftp13.freebsd.org did not respond anymore and since > then rsync replication is broken. > > The main issue (besides the removal of ftp13.freebsd.org) is that most > rsync sources refuse to replicate the content of the .Attic directories > in the CVS tree. This means that performing a check-out on ports using a > tag usually won't work as some files will not be there anymore. > > Here are the typical logs I get using most rsync servers: > > rsync: opendir > "/3/freebsd-core/development/FreeBSD-CVS/ports/chinese/pcmanx/files/Attic" > (in vol) failed: Permission denied (13) > > At this moment the only rsync server that provides an adequate > replication of the CVS repository is ftp2.tw.FreeBSD.org. As others have reported this was caused by the permissions on the Attic directories not including world read permission. For sites where it was working it's actually an indication they're not following "best practices" for a mirror site. It's typically a bad idea to have the thing that allows access to the content of the mirror site running with the same credentials as what keeps the mirror site up to date. We don't use the 'feature' that allow for (pre-staging content that the world shouldn't have access to for a period of time, allowing the mirror sites to get fully populated before the release date) but I know of other projects that do. The ftp-master machines don't have that in place because they're not public and they need to allow the blessed mirrors access to everything (for the purposes of pre-staging, if we were actually using that feature...). The development/ section of the FTP site is something I hadn't looked at before so it took me a little time to find what populates it and investigate a little. I *think* the issue with the Attic directories not including world-read permissions was either an issue with a badly formed chmod(1) done a long time ago or an issue with the mechanism that populates that portion of the FTP site missing a umask setting in the script that does it some time back in history (it's there now). Not all of the Attic directories had the wrong permissions, it seemed to stop some time in 2007. I adjusted the permissions on ftp-master so hopefully this issue is fixed. However ... > We are moving to svn and svnsync for the freebsd source tree (and I am > happy with this), but the ports do not seem to be available using SVN > (or not in a documented way). > > Can something be done to restore RSYNC mirroring of the CVS tree to a > working state ? The FTP site desperately needs to go on a diet so we're poking around to see if there is some stuff that can be dropped. This section of the site is a candidate for being removed. As you say the ports are not available in SVN but I'm curious why you use the content from the FTP site instead of just using a CVSUP mirror. Is there some benefit to it? We would sort of like to stop providing this as part of the FTP site if there really isn't any benefit to it over using the cvsup mirror infrastructure which won't be going away any time soon. Thanks. -- Ken Smith - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | signature.asc Description: This is a digitally signed message part
Re: freebsd-update(8) under sparc64? Why is it not available?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/24/10 6:38 PM, Marius Strobl wrote: > On Wed, Mar 24, 2010 at 02:57:09AM -0500, Mark Linimon wrote: >> You're the first one to ask in a while. Since our userbase is small, >> and developer time is limited, we've never set it up. >> > > The last time this topic came up IMO there was quite some > interest in getting this running but the showstopper was that > cperciva@ said that a requirement for any platform supported > by freebsd-update(8) would be that the build server is able > to run buildworld in 1 hour at most (unfortunately I currently > just can't find that email). My 4x1.5GHz V440 I originally > intended for this purpose unfortunately still takes 72 minutes > last time I checked. I suspect a 8x1.2GHz V880 would be able > to meet this requirement but I simply can't afford the housing > for such a beast. I have none that are faster than 900MHz processors, and the one with the most processors in it is 6x750MHz. > Ken, did the V880s at your university become available as > intended some time ago? At the moment there are two - one being used by portmgr@ for package builds which is the 6x750MHz machine. The other I do the monthly snapshots and release builds on, it's 4x900MHz. This was its performance on the world built of 7.3-RELEASE: >>> World build started on Sat Mar 20 23:34:54 EDT 2010 >>> World build completed on Sun Mar 21 00:50:58 EDT 2010 - -- Ken Smith - - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkurSrkACgkQ/G14VSmup/aDPACeM4Whnkrn2UfQys/22Y4qTCOa 7soAnAnjusO81m0q/9fvMBDTYR9LjUgj =l35W -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Install from a USB Pen
On Sat, 2009-07-18 at 11:41 +0800, Fbsd1 wrote: > Took 3 times longer to download the 8.0-BETA1-i386-memstick.img that to > download the 8.0-BETA1-i386-disc1.iso. I suggest you look into another > method of creating the memstick.img so it downloads faster. dd does no > compression of the data. You're comparing apples to oranges here to some extent. disc1 isn't compressed either. The reason the memstick is larger is that it contains more stuff than disc1. That extra stuff is usually referred to as "livefs" and having that allows the memstick to be used in "Fixit" mode - you can boot off the memstick and enter into sysinstall's "Fixit" menu item which in turn you can use to get to a usable shell that has all the normal FreeBSD base system utilities available. That functionality can be useful for recovering a machine from mistakes. The CDROM media has a separate livefs. We needed to separate them out because of size issues on the CDROM media - the contents of disc1 plus the contents needed from the livefs disc to make it work in Fixit mode are too big for our target CDROM media size (700Mb). The DVD media contains both so DVDs can be used for this 'Fixit' mode as well. If you're going to use download time as any sort of evaluation of the memstick's merit you need to compare the speed of downloading it versus the speed of downloading both disc1 and livefs. Though I'm not quite sure why that's any measure of the memstick's merit. I think I've settled on the memstick images containing what was provided with BETA2, which will be the installation bits from disc1, the livefs bits, and just the packages that make up the documentation. Put a slightly different way it's the contents of the DVD minus all packages except for the documentation packages. That's my best guess on the trade-off of size versus functionality that would benefit the most end-users. > Using a 8gb memstick as the target to install 8.0 on took 2 times longer > than disc1 cd installing to same 8gb memstick. This shouldn't come as too big a surprise, for *typical* machines things slow down a bit if you're using the same I/O subsystem for both reads and writes. I'm guessing your CD isn't USB. Even if it is, you're again comparing apples to oranges to a large degree here. If a speed comparison is important to you here then compare the speed of installing from the memstick we provide versus one you create with your script from disc1. I'd be surprised if installing from the one you created using your script was faster than the memstick we provide. > Here is a script i have used in the past to convert the disc1.iso to > bootable memstick. Maybe its better to add this script to the place > where 8.0-BETA1-i386-disc1.iso is located in place of the memstick.img. > That way the 3 times larger memstick.img is not needed any more. Per above the 3 times larger memstick.img we're providing has more functionality than what you would get by running your script. For some people your script also causes something of a chicken-and-egg issue. It may not be particularly convenient to run your script if you don't already have FreeBSD installed on a machine. I don't see the harm in us providing one pre-built memstick image for peoples' convenience. -- Ken Smith - From there to here, from here to | kensm...@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: Upgrading 7.1-PRERELEASE
On Thu, 2008-10-23 at 22:30 -0700, Jeremy Chadwick wrote: > I sincerely do not know where "BETA2" (not "BETA-2") comes from. It's > not defined anywhere in src/sys/conf/newvers.sh in CVS: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh > > To me, this means someone is hand-hacking the file before making ISO > releases. The problem with this is there's no way to correlate what CVS > tag said string is based on; I have to assume it's RELENG_7. > > CC'ing Ken, who can probably explain where "BETA2" comes from, since I > believe he's the one who makes the builds. Release builds are done using whats in /usr/src/release. One of the things you can set on the command line when you run make(1) there is the BUILDNAME variable, for example "BUILDNAME=7.1-BETA2" in this case. The result of doing that is to change src/sys/conf/newvers.sh inside the build environment (which is among other things a checked out source tree) before doing the build. We use BUILDNAME for the Monthly Snapshots as well, that's why src/sys/conf/newvers.sh doesn't need to be altered just for those builds. > > I really wish we'd name our not-yet-RELEASE-or-STABLE ISO releases as > FreeBSD x.y-PRERELEASE-MMDD, which would make more sense to users. > What to have in src/sys/conf/newvers.sh before we do the branch for the release (typically the BETA builds, we usually do the branch for the release at the point we shift over to Release Candidates (RCs)) is unfortunately something we can't win with no matter what we do. The truth is that branches like RELENG_7 are development branches. We try very hard to never break things (well, badly anyway... :-) in those branches once they're considered to be a "stable branch". But from time to time things do get broken there. If we were a corporation RELENG_7 type branches wouldn't be available to the public - they would be a "tool" for the staff programmers to work in. Its the RELENG_7_0 type branches that would be considered suitable for our customers. But we're not a corporation, and we don't want to keep stuff "private". The downside to that however is people who are sort-of involved in the FreeBSD community but aren't truly active participants see RELENG_7 called "stable" and figure its OK to run their systems on that. We tell them not to, or at least to be sure to read mailing lists like freebsd-stable@ if they're going to do that, but lots of people don't follow that advice. And someone in that situation *really* freaks out if they update a system and winds up with a system that calls itself something too strange. It was a lot worse the last couple times we tried calling a "stable branch" something that had the word BETA in it, and we've more or less settled on PRERELEASE with no other fiddling as a way to suggest "something is going on" but not freak out that set of people too much... We do bump src/sys/conf/newvers.sh in the release branches once they get created (so it will become 7.1-RC1 at the point we create RELENG_7_1). But for the BETAs the best you can do to be a bit more descriptive of when you had done a source-based update is just note the date you did the update. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: make release error for customed x86 platform
[ cc line trimmed a bit... ] On Sun, 2007-08-12 at 08:55 +0800, Put PostgreSQL to Work for Your Business. wrote: > Dear all > > I am building a custom FreeBSD for internal use for the various > platforms we used (x86 platform). I am encountering a issue write > failed, filesystem is full when creating the boot.floppy on touch > release.5, > > can someone take a look to see what's the reason? following is the screen > dump, > > sorry for any interruptions, thanks in advance. > > Tony > > [ Snip ] > + mount /dev/md0c /mnt > + [ -d /R/stage/image.boot ] > + set -e > + cd /R/stage/image.boot > + find+ cpio . -dump -print /mnt > > > /mnt: write failed, filesystem is full > cpio: write error: No space left on device > + umount /mnt > + mdconfig -d -u md0 > *** Error code 1 > > Stop in /usr/src/release. > *** Error code 1 > > Stop in /usr/src/release. > + umount /dev > *** Error code 1 > > Stop in /usr/src/release. I just built the August Monthly Snapshots for amd64 and i386 with no boot floppy issues so I'm guessing whatever it is you're customizing is having some sort of an impact on the boot floppy. Do you actually use the floppies at all? If not I'd suggest you just add "NO_FLOPPIES=" to the command line when you do the release build so it doesn't even bother trying to create the floppies. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: cvsup8.freebsd.org not updating (Re: RELENG_6 cvsup returns 6.0-RC1)
On Fri, 2005-11-11 at 18:33 -0500, Kris Kennaway wrote: > On Sat, Nov 12, 2005 at 12:30:32AM +0100, Erik Trulsson wrote: > > On Fri, Nov 11, 2005 at 06:07:13PM -0500, Kris Kennaway wrote: > > > On Fri, Nov 11, 2005 at 02:54:11PM -0800, Frank Jahnke wrote: > > > > > I just ran a cvsup with a tag of RELENG_6 and rebuilt world/kernel. > > > > > After installing kernel/world and subsequent reboot, I expected to see > > > > > a kernel labeled: > > > > > > > > > >FreeBSD 6.0-STABLE > > > > > > > > > > but am instead seeing: > > > > > > > > > >FreeBSD 6.0-RC1 > > > > > > > > > > I double-checked my supfile and my tag is indeed RELENG_6. > > > > > > > > Set your tag to RELENG_6_0 and all will be well. > > > > > > No, that's the release branch. RELENG_6 indeed should work as he > > > expects. Is anyone else able to confirm that this cvsup server is > > > handing out old files? > > > > Yes, I just tried the cvsup server he said he was using > > (cvsup8.us.freebsd.org) and does indeed hand out old files, as if it hasn't > > been updated in quite a while. > > > > To the OP: Use another cvsup server. The one you have been using seem to > > have problems. > > Thanks for confirming, I'm forwarding this to hubs@ > > Kris FYI: - cvsup8.freebsd.org and cvsup8.us.freebsd.org are not the same machine... :-) - cvsup8.us.freebsd.org was having problems with their upstream host. They're now sync-ing from cvsup-master instead. I still need to contact their upstream host to see what the problem with them is... And as part of a different thread... cvsup10 had a drive blow. We're still working on that. cvsup10 is temporarily pointing to a different machine. And just to add to the fun cvsup12 also lost something-or-other and is down for a couple days. It also has been temporarily pointed to a different machine. Whee... -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: Maximum uptime 497 days?
On Mon, Jun 28, 2004 at 05:19:10PM +0400, Maxim Konovalov wrote: > On Mon, 28 Jun 2004, 12:39+0900, Rob wrote: > > By accident I happen to come across this remarkable limit of > > uptime registration for FreeBSD systems. After 497 days, the > > timer jumps to zero again. > > > > 497 days is less than a 1.5 years ! > > > > Has this been fixed in newer versions of FreeBSD (stable and/or > > current) ? Or is there a hardware limitation (CPU?) that does > > not allow this? > > > > Just wondering. > > $ uptime > 5:18ÐÐ up 498 days, 6:13, 5 users, load averages: 0.07, 0.03, 0.06 > $ uname -r > 4.4-RELEASE % uptime 7:25AM up 932 days, 3:48, 1 user, load averages: 0.47, 0.30, 0.23 % uname -r 4.4-STABLE % That said, I'd love to know what limit it was you (original poster) saw. Maybe something has crept in between 4.4 and now? -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
