buildworld problem 9.1 stable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
hey,
i have a alix board here.
it's a new installation.
*#make buildworld*
snip
{standard input}: Assembler messages:
{standard input}:17822: Warning: end of file not at end of a line;
newline inserted
{standard input}:19715: Error: unknown pseudo-op: `.l241'
cc: Internal error: Killed: 9 (program cc1)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
*** [insn-attrtab.o] Error code 1
Stop in /usr/src/gnu/usr.bin/cc/cc_int.
*** [all] Error code 1
Stop in /usr/src/gnu/usr.bin/cc.
*** [cross-tools] Error code 1
Stop in /usr/src.
*** [_cross-tools] Error code 1
Stop in /usr/src.
*** [buildworld] Error code 1
Stop in /usr/src.
*
# gcc -v*
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]
*
#cat /etc/make.conf*
WITH_SYSTEM_CLANG=YES
WITH_PKGNG=YES
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
##Clang will return a lot of 'unused argument' warnings: they are harmless.
##Just add this to /etc/make.conf if you want to hide them:
.if ${CC:T} == clang
CFLAGS+=-Qunused-arguments
.endif
Thanks for some help.
Suri
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJQ/868AAoJEDyDkpKh+9pTILQP/2yoL8DvRPpabipDocO11kTt
2OzVwcTR+vh7AOQbsYf9c0zt4NvL66I5kW3vGAd6GHCaBozzsz3Ct4DgsuBxk1KU
EatHPVjqoVzBHuBMDD3SxR4RT/5OAXU4lOs8V7IFY3j2/hcnrow2ruUNG4UDIrSl
dlVnCMIdfPTRMkOE4XIi27XMrDyxKsbIS9QRNmj4SnCT+3/I8ipc5Z5bXN4ObWji
g33VTojL3zT9KcJw1LqI48vSa3OxqHcuUkJ5PEQFLoSSJJXAWeFUn26bRNKbn3n0
b3gaJ1QsGgdySo1FLVEyLebyxctEaGMPRjSEXkt8XvgRjUWMaO2IL9ePZjZhB3JO
pKZIRD1LrbgnVLQJ0d7Lw6r1jHU4KbyLpkSLNvoc4LlOxAXxelGBobJyhxIC7OJ6
EIFttgHmPXY9VQ4HNyDlMAqrY7AErW06KUWHsqx1TAxcsOqU3kTDsx3WIZzKR9Zz
W0W4ownLYBCfi86I7/SsBI21GR1MTn0XAYyvGJv98L/vmrlyLpetSLsGjiKw/1BM
xTXqBUsqN5fCKYDawkSd5mNhRPl3yKg8CpbP3l0x1UD5oU61bKe1Vq0/EzIMEfqc
QceuYzrH+V1XpqBMZhS9HY9TC5tW1VVkl0Kr90kArgZKmi2QCzippYOcPyWvhf1s
2JLML6k+1LOUebSSd10L
=45wV
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.1 coredump
hi, i was run ssh-keygen with output to 32g usb 3.0 flash, and got this core sorry, i was forgot. i mount that flash via fusefs-exfat-0.9.8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
svn - but smaller?
Hi, in ancient times there was cvsup. cvsup was a PITA if you wanted (or needed) to install it via ports, the only reasonable way was to use pkg_add for that if you didn't want to pollute your system with otherwise unneeded software. Then there came csup. Small, in the base. You could install FreeBSD and the first task (for me and my environment) was often to simply csup to -STABLE (or a known good version of that) and to build an up-to-date and customised system. Like tayloring make.conf and src.conf to my needs and leave out most of the stuff I don't need on my system and in the kernel. Software and drivers that aren't there can't fail and won't be a security problem. Times have been changing, we're now up to svn. svn is far more modern than cvs and there are pretty good reasons to use it. However, I either overlook something important or we are now at the point we had with cvsup in the early days: The software I need to (source-)update the system doens't come with the base and installing svn is a PITA. It pulls in a whole lot of dependencies, at the time being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the box. And in the end I have my system polluted with software and libraries I don't really need in many cases for anything else. So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? The current situaion for me is a bit annoying. From the user's or admin's point of view at least. I didn't even see an option in svn to not build the server components, which would probably already help to make things smaller? Thanx, Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: time issues and ZFS
on 22/01/2013 20:42 Adrian Chadd said the following: Hi! As I said before, the problem with non-HLT loops with event-timer in -9 and -head is that it calls the idle function inside a critical section (critical_enter and critical_exit) which blocks interrupts from occuring. The EI;HLT instruction pair on i386/amd64 atomically and correctly handles things from what I've been told. However, there's no atomic way to do this using ACPI sleeping, so there's a small window where an interrupt may come in but it isn't handled; waiting for the next interrupt to occur before it'll wake up and respond to that interrupt. I don't think that this is true of x86 hardware in general. You might have hit some limitation or a quirk or a bug or an erratum for some particular hardware. E.g. a chipset on this machine has a bit described as such: Set to 1 to skip the C state transition if there is break event when entering C state. The bit is set indeed and as far as I can tell the behavior matches the description. Most modern (non-embedded) machines seem to behave this way. Attempt to enter a deeper C state while a break event is pending still incurs some overhead, but it's not as bad as waiting for the next break event. I kept hitting my head against this when doing network testing. :( Now - specifically for timekeeping it shouldn't matter; that's to do with whether the counters are reliable or not (and heck, are even in lock-step on CPUs.) But extra latency could show up weirdly, hence why I was asking for you to try different timer configurations and idle loops. -- Andriy Gapon -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, 23 Jan 2013 15:40:50 +0100, Oliver Brandmueller o...@e-gitt.net wrote: Hi, in ancient times there was cvsup. cvsup was a PITA if you wanted (or needed) to install it via ports, the only reasonable way was to use pkg_add for that if you didn't want to pollute your system with otherwise unneeded software. Then there came csup. Small, in the base. You could install FreeBSD and the first task (for me and my environment) was often to simply csup to -STABLE (or a known good version of that) and to build an up-to-date and customised system. Like tayloring make.conf and src.conf to my needs and leave out most of the stuff I don't need on my system and in the kernel. Software and drivers that aren't there can't fail and won't be a security problem. Times have been changing, we're now up to svn. svn is far more modern than cvs and there are pretty good reasons to use it. However, I either overlook something important or we are now at the point we had with cvsup in the early days: The software I need to (source-)update the system doens't come with the base and installing svn is a PITA. It pulls in a whole lot of dependencies, at the time being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the box. And in the end I have my system polluted with software and libraries I don't really need in many cases for anything else. So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? The current situaion for me is a bit annoying. From the user's or admin's point of view at least. I didn't even see an option in svn to not build the server components, which would probably already help to make things smaller? Thanx, Oliver I've read about this initiative. http://svnweb.freebsd.org/base/user/des/svnsup/ Maybe you can help there. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
Oliver Brandmueller o...@e-gitt.net writes: snip So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? snip This type of question has been asked quite a few times recently. At this point there is no svn version of csup, however there were people working on it (or at least: there is a svnsup project). For details please search recent ports or questions mailing list archives. As far as I know there is also no alternative svn-client. I'm kind of surprised for the need of this though. Why not simply use portsnap if you are not actively developing ports? -- - Frank ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, Jan 23, 2013 at 04:12:22PM +0100, Frank Staals wrote: This type of question has been asked quite a few times recently. At this point there is no svn version of csup, however there were people working on it (or at least: there is a svnsup project). For details please search recent ports or questions mailing list archives. As far as I know there is also no alternative svn-client. Pointer to svnsup is fine; it seems I just missed to the first hint. I'm kind of surprised for the need of this though. Why not simply use portsnap if you are not actively developing ports? Well, for ports this is mostly fine, though on several places I prefer to use csup (or svn now) even for ports, since I maintain quite a set of local patches - this sometimes gives problems together with potsnap. Where this is neede, I have a shared ports tree anyway, so the whole svn setup is only needed in one machine. But my main concern is the system sources anyway. freebsd-update is not feasible for me, as described in the original post. Thank you, Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On 23 Jan 2013 15:37, Oliver Brandmueller o...@e-gitt.net wrote: On Wed, Jan 23, 2013 at 04:12:22PM +0100, Frank Staals wrote: This type of question has been asked quite a few times recently. At this point there is no svn version of csup, however there were people working on it (or at least: there is a svnsup project). For details please search recent ports or questions mailing list archives. As far as I know there is also no alternative svn-client. Pointer to svnsup is fine; it seems I just missed to the first hint. I'm kind of surprised for the need of this though. Why not simply use portsnap if you are not actively developing ports? Well, for ports this is mostly fine, though on several places I prefer to use csup (or svn now) even for ports, since I maintain quite a set of local patches - this sometimes gives problems together with potsnap. Where this is neede, I have a shared ports tree anyway, so the whole svn setup is only needed in one machine. But my main concern is the system sources anyway. freebsd-update is not feasible for me, as described in the original post. The single binaries inside the archives at [1] may help you out. I built them fairly recently, so they should be up to date (ish), and they should be fine on 9+. Just untar and use. Chris [1] http://www.bayofrum.net/svn-static/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On 1/23/2013 10:37 AM, Oliver Brandmueller wrote: But my main concern is the system sources anyway. freebsd-update is not feasible for me, as described in the original post. Actually, if you build the port minus the NEON option, its as bad in terms of dependencies. # pkg_info -r subversion-1.7.8.tbz Information for subversion-1.7.8.tbz: Depends on: Dependency: expat-2.0.1_2 Dependency: pkg-config-0.25_1 Dependency: gettext-0.18.1.1 Dependency: sqlite3-3.7.5 Dependency: gdbm-1.9.1 Dependency: db42-4.2.52_5 Dependency: libiconv-1.13.1_1 Dependency: apr-ipv6-devrandom-gdbm-db42-1.4.5.1.3.12_1 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 coredump
On Wed, Jan 23, 2013 at 1:32 PM, Alexander Nikiforenko a...@rambler-co.ru wrote: hi, i was run ssh-keygen with output to 32g usb 3.0 flash, and got this core sorry, i was forgot. i mount that flash via fusefs-exfat-0.9.8 This is on stable/9? If yes, I will send you patches to use new fuse approach in a while. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: time issues and ZFS
On 23 January 2013 06:58, Andriy Gapon a...@freebsd.org wrote: I don't think that this is true of x86 hardware in general. You might have hit some limitation or a quirk or a bug or an erratum for some particular hardware. E.g. a chipset on this machine has a bit described as such: Set to 1 to skip the C state transition if there is break event when entering C state. The bit is set indeed and as far as I can tell the behavior matches the description. Most modern (non-embedded) machines seem to behave this way. Attempt to enter a deeper C state while a break event is pending still incurs some overhead, but it's not as bad as waiting for the next break event. I'll reverify the behaviour on my netbooks when I'm back home. It may be a quirk of an older 9.x, which is fixed in -HEAD. It may be a quirk of the older generation celeron hardware - in which case, we need to tell the user somehow.. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, Jan 23, 2013 at 10:55:32AM -0500, Mike Tancsa wrote: On 1/23/2013 10:37 AM, Oliver Brandmueller wrote: But my main concern is the system sources anyway. freebsd-update is not feasible for me, as described in the original post. Actually, if you build the port minus the NEON option, its as bad in terms of dependencies. # pkg_info -r subversion-1.7.8.tbz Information for subversion-1.7.8.tbz: Depends on: Dependency: expat-2.0.1_2 Dependency: pkg-config-0.25_1 Dependency: gettext-0.18.1.1 Dependency: sqlite3-3.7.5 Dependency: gdbm-1.9.1 Dependency: db42-4.2.52_5 Dependency: libiconv-1.13.1_1 Dependency: apr-ipv6-devrandom-gdbm-db42-1.4.5.1.3.12_1 ---Mike pkg_info -r /usr/ports/packages6/All/subversion-1.7.8.tbz Information for /usr/ports/packages6/All/subversion-1.7.8.tbz: Depends on: Static linked, NEON included, run on 6+. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
One of my teammates and I were just doing a write up on this very issue, On Jan 23, 2013, at 10:55 AM, Mike Tancsa wrote: On 1/23/2013 10:37 AM, Oliver Brandmueller wrote: But my main concern is the system sources anyway. freebsd-update is not feasible for me, as described in the original post. Actually, if you build the port minus the NEON option, its as bad in terms of dependencies. THE UGLY Source for SVN: 496M (+) Source for FreeBSD 9.1: 746M (actual) (df output details below) --- THE BAD After 15+ years of FreeBSD use, I remember what a great thing cvsup was when it hit. However, SVN presents several problems for OS use (again): 1) License. Many of SVN's dependencies will never be available in the FreeBSD source. While this is totally OK for development, SVN is 3rd party software, this is unacceptable to force as 'the' respected path for OS source builds. 2) Heft: cvsup/csup was excellent for 1 thing: grabbing a REL branch. Perhaps grabbing STABLE or CURRENT. Systems administrators could QA/test new branches on massive numbers of servers quickly and efficiently. THE GOOD We've just resolved this for ourselves, and are wrapping it in a clean sh script: (I'd love to know where we can send it for input when we're done?) 40 lines of shell could get the jist of what users really need: - Download the src using fetch(1) fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/9.1-RELEASE/src.txz - Extract the tarball (to /usr/src, or wherever). tar -xf src.txz We're hacking out some simple script add-ons out right now for ourselves, to make this more CVSUP like: + flag to keep source tarball somewhere (instead of merely un-tarring it in a pipe) + flag to un-tar source to a particular directory + flag to specify OS version + flag to specify RELEASE, STABLE, CURRENT (if they exist, CURRENT may be tricky?) + define source server/mirror + source config in /etc, (or rc.conf ?), if exists -- Nice-to-have extra features (some necessary for us): + define protocol (tricky), e.g. ftp/http/https/other + after unpacking, run against mtree (possibly kept on separate server or locally) to validate sources + exit non-zero if particular conditions exist + checksum tarball (possibly against checksums kept on separate server or locally) to validate sources + exit non-zero if particular conditions exist + flags to override/change tar options ++ also nice to have, more cvsup features, (I need to read through man page again for a sanity check) -- Regarding SVN: I know the SVN change is a profound leap foreword in source management and collaboration, (I've carried many shops through CVS/SVN/GIT migrations as an SA). Developing/hacking in the FreeBSD source is already simpler, though as an outsider, (no commit bit), the transition has been expectedly rough-edged :) On Jan 23, 2013, at 10:06 AM, Ronald Klop wrote: I've read about this initiative. http://svnweb.freebsd.org/base/user/des/svnsup/ Maybe you can help there. Aside from the heft/licence issues I noted above, it's a bit late to consider this, cvsup is going away: - the *ports* CVS/csup infrastructure is going to be disabled on Feburary 28th - the *source* CVS/csup infrastructure is deprecated, but doesn't have a definite end-date On Wed, Jan 23, 2013 at 04:12:22PM +0100, Frank Staals wrote: I'm kind of surprised for the need of this though. Why not simply use portsnap if you are not actively developing ports? On Jan 23, 2013, at 10:37 AM, Oliver Brandmueller wrote: But my main concern is the system sources anyway. freebsd-update is not feasible for me, as described in the original post. For users/administrators, to merely fetch OS sources for a given branch, it goes against the grain of nearly every reason users use FreeBSD to say 'just use svn'. Additionally, it's not been fun recently to 'just use portssnap', when the actual binary ports servers have gone through the recent security incident, (as well as all the changes). I'm not meaning to be negative here, but this has slid pretty far away from the ideals that *BSD users care about. Best, .ike # uncompressed canonical sources for svn (I believe I missed some dependencies of the dependencies) du -d 1 -h 5.5M./apr-1.4.6 5.3M./sqlite-amalgamation-3071300 13M./libtool-2.4.2 79M./perl-5.16.2 4.0M./neon-0.29.6 66M./Python-2.7.1 153M./db-5.3.21 55M./subversion-1.7.8 8.6M./m4-1.4.16 3.0M./expat-2.1.0 12M./pkg-config-0.27.1 3.0M./gdbm-1.10 67M./gettext-0.18.1.1 21M./libiconv-1.14 496M. ## FreeBSD 9.1 Source $ pwd ; du -d 1 -h /usr/src 3.2M./bin 11M./cddl 316M./contrib 40M./crypto 2.0M./etc 3.7M./games 5.9M./gnu 1.1M./include 484k./kerberos5 31M./lib 2.1M./libexec 1.3M./release 32k./rescue 7.2M./sbin 3.6M./secure 39M./share 200M./sys 44M./tools 13M./usr.bin
Re: svn - but smaller?
On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy i...@blackskyresearch.net wrote: 1) License. Many of SVN's dependencies will never be available in the FreeBSD source. While this is totally OK for development, SVN is 3rd party software, this is unacceptable to force as 'the' respected path for OS source builds. Don't confuse the excessive ports default settings as dependencies. You can make a quite mean and lean svn client. I did a 100% BSD-license-compatible src/contrib/svn style proof-of-concept back when we were planning what to do. Things like gdbm and bdb are not required and are license contamination that we don't need. But that's the fault of the port, not a fundamental property of using svn. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kvm vlan virtio problem
Hi Bryan, On 23.01.2013 04:44, Bryan Venteicher wrote: Hi, - Original Message - Hi! The same warning shows up in our setup: Jan 21 23:40:46 host kernel: WARNING: at net/core/dev.c:1712 skb_gso_segment+0x1df/0x2b0() (Tainted: GW --- ) Jan 21 23:40:46 host kernel: Hardware name: System Product Name Jan 21 23:40:46 host kernel: tun: caps=(0x1b0049, 0x0) len=4452 data_len=4380 ip_summed=0 [...] KVM host: CentOS 6.3, Linux kernel 2.6.32-279.19.1.el6.x86_64 VM guest: FreeBSD 9.1, virtio-kmod-9.1-0.242658 Disabling TSO on vtnet0 stops the warnings on the KVM host. Is there any progress on this issue? Alright, I tried to recreate this on Ubuntu 12.10 without any luck. Please describe your network configuration. On my Linux host, my VLAN interface looks like: eth0.100 Link encap:Ethernet HWaddr 6c:f0:49:05:2b:6d inet6 addr: fe80::6ef0:49ff:fe05:2b6d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3119867 errors:0 dropped:0 overruns:0 frame:0 TX packets:3790183 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:166813040 (166.8 MB) TX bytes:5435432448 (5.4 GB) That is plugged into this bridge: br100 Link encap:Ethernet HWaddr 6c:f0:49:05:2b:6d inet addr:192.168.99.101 Bcast:192.168.99.255 Mask:255.255.255.0 inet6 addr: fe80::6ef0:49ff:fe05:2b6d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:876 (876.0 B) TX bytes:1420 (1.4 KB) With the tap device created by QEMU for my FreeBSD guest: vnet1 Link encap:Ethernet HWaddr fe:54:00:ec:4f:4e inet6 addr: fe80::fc54:ff:feec:4f4e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:800284 errors:0 dropped:0 overruns:0 frame:0 TX packets:3119877 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:5238099122 (5.2 GB) TX bytes:210492002 (210.4 MB) All this tied together: # brctl show br100 bridge name bridge id STP enabled interfaces br100 8000.6cf049052b6d no eth0.100 vnet1 Does this approximate your configuration? What's the output of `ethtool -k` for your VLAN, bridge, and vnet interfaces? First of all: Thanks for your efforts. We are using a different setup. Basically we are using a router VM, which means: All IP traffic for the actual VMs is routed through it. One ethernet interface of the router VM is bridged with the physical ethernet interface of the KVM host. The router VM has one or more additional interfaces for the actual VMs. This is the output of ifconfig -a from the KVM host: br0 Link encap:Ethernet HWaddr AA:50:00:1F:23:AD inet addr:88.12.100.100 Bcast:88.12.100.127 Mask:255.255.255.255 inet6 addr: fe80::aa50:ff:fe1f:23ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:338087 errors:0 dropped:0 overruns:0 frame:0 TX packets:213316 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:115518852 (110.1 MiB) TX bytes:528688448 (504.1 MiB) eth0 Link encap:Ethernet HWaddr AA:50:00:1F:23:AD inet6 addr: fe80::aa50:ff:fe1f:23ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6398703 errors:0 dropped:0 overruns:0 frame:0 TX packets:8451045 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3566218121 (3.3 GiB) TX bytes:7532154606 (7.0 GiB) Interrupt:43 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:138575 errors:0 dropped:0 overruns:0 frame:0 TX packets:138575 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:480320359 (458.0 MiB) TX bytes:480320359 (458.0 MiB) virbr0Link encap:Ethernet HWaddr 52:54:00:83:09:92 inet addr:10.30.1.1 Bcast:10.30.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:232 (232.0 b) TX bytes:3156 (3.0 KiB) virbr0-nic Link encap:Ethernet HWaddr 52:54:00:83:09:92 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX
Re: svn - but smaller?
Oliver Brandmueller o...@e-gitt.net wrote: Hi, in ancient times there was cvsup. cvsup was a PITA if you wanted (or needed) to install it via ports, the only reasonable way was to use pkg_add for that if you didn't want to pollute your system with otherwise unneeded software. Then there came csup. Small, in the base. You could install FreeBSD and the first task (for me and my environment) was often to simply csup to -STABLE (or a known good version of that) and to build an up-to-date and customised system. Like tayloring make.conf and src.conf to my needs and leave out most of the stuff I don't need on my system and in the kernel. Software and drivers that aren't there can't fail and won't be a security problem. Times have been changing, we're now up to svn. svn is far more modern than cvs and there are pretty good reasons to use it. However, I either overlook something important or we are now at the point we had with cvsup in the early days: The software I need to (source-)update the system doens't come with the base and installing svn is a PITA. It pulls in a whole lot of dependencies, at the time being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the box. And in the end I have my system polluted with software and libraries I don't really need in many cases for anything else. So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? The current situaion for me is a bit annoying. From the user's or admin's point of view at least. I didn't even see an option in svn to not build the server components, which would probably already help to make things smaller? Thanx, Oliver devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns That way the package build cluster would create a package of the static version which wouldn't pull in any runtime dependencies. Emanuel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: Oliver Brandmueller o...@e-gitt.net wrote: Hi, in ancient times there was cvsup. cvsup was a PITA if you wanted (or needed) to install it via ports, the only reasonable way was to use pkg_add for that if you didn't want to pollute your system with otherwise unneeded software. Then there came csup. Small, in the base. You could install FreeBSD and the first task (for me and my environment) was often to simply csup to -STABLE (or a known good version of that) and to build an up-to-date and customised system. Like tayloring make.conf and src.conf to my needs and leave out most of the stuff I don't need on my system and in the kernel. Software and drivers that aren't there can't fail and won't be a security problem. Times have been changing, we're now up to svn. svn is far more modern than cvs and there are pretty good reasons to use it. However, I either overlook something important or we are now at the point we had with cvsup in the early days: The software I need to (source-)update the system doens't come with the base and installing svn is a PITA. It pulls in a whole lot of dependencies, at the time being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the box. And in the end I have my system polluted with software and libraries I don't really need in many cases for anything else. So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? The current situaion for me is a bit annoying. From the user's or admin's point of view at least. I didn't even see an option in svn to not build the server components, which would probably already help to make things smaller? Thanx, Oliver On Jan 23, 2013, at 2:09 PM, Peter Wemm wrote: On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy i...@blackskyresearch.net wrote: 1) License. Many of SVN's dependencies will never be available in the FreeBSD source. While this is totally OK for development, SVN is 3rd party software, this is unacceptable to force as 'the' respected path for OS source builds. Don't confuse the excessive ports default settings as dependencies. You can make a quite mean and lean svn client. I did a 100% BSD-license-compatible src/contrib/svn style proof-of-concept back when we were planning what to do. Things like gdbm and bdb are not required and are license contamination that we don't need. But that's the fault of the port, not a fundamental property of using svn. On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns That way the package build cluster would create a package of the static version which wouldn't pull in any runtime dependencies. Emanuel Peter, this work sounds great, and sounds like it would make a great stub port itself! I'd love to see whatever you have remaining from the proof-of-concept work, to perhaps help expand it into 'devel/subversion-lite' or 'devel/subversion-static' ? I'd happily use it for development. -- However, SVN for development use is not what the point, this thread is about using, administrating, and maintaining FreeBSD systems- not about development process. And in that case, SVN is still a fairly massive toolset for the simple task of fetching REL, STABLE, or CURRENT: Source for SVN-alone:55M Source for FreeBSD 9.1: 746M That's still over 7% of the size of the entire OS. I believe it's not at all necessary to have anything except the base FreeBSD OS, to update/install FreeBSD. -- A NYC*BUG list user posted this reminder, we've been here before: Deja-vu… This reminds me of cvsup+modula-3. http://www.mavetju.org/mail/view_message.php?list=freebsd-currentid=209027 I'll keep hacking on our shell utility, and will post the PR to this thread. Best, .ike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On 23 January 2013 20:41, Isaac (.ike) Levy i...@blackskyresearch.net wrote: On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: Oliver Brandmueller o...@e-gitt.net wrote: Hi, in ancient times there was cvsup. cvsup was a PITA if you wanted (or needed) to install it via ports, the only reasonable way was to use pkg_add for that if you didn't want to pollute your system with otherwise unneeded software. Then there came csup. Small, in the base. You could install FreeBSD and the first task (for me and my environment) was often to simply csup to -STABLE (or a known good version of that) and to build an up-to-date and customised system. Like tayloring make.conf and src.conf to my needs and leave out most of the stuff I don't need on my system and in the kernel. Software and drivers that aren't there can't fail and won't be a security problem. Times have been changing, we're now up to svn. svn is far more modern than cvs and there are pretty good reasons to use it. However, I either overlook something important or we are now at the point we had with cvsup in the early days: The software I need to (source-)update the system doens't come with the base and installing svn is a PITA. It pulls in a whole lot of dependencies, at the time being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the box. And in the end I have my system polluted with software and libraries I don't really need in many cases for anything else. So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? The current situaion for me is a bit annoying. From the user's or admin's point of view at least. I didn't even see an option in svn to not build the server components, which would probably already help to make things smaller? Thanx, Oliver On Jan 23, 2013, at 2:09 PM, Peter Wemm wrote: On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy i...@blackskyresearch.net wrote: 1) License. Many of SVN's dependencies will never be available in the FreeBSD source. While this is totally OK for development, SVN is 3rd party software, this is unacceptable to force as 'the' respected path for OS source builds. Don't confuse the excessive ports default settings as dependencies. You can make a quite mean and lean svn client. I did a 100% BSD-license-compatible src/contrib/svn style proof-of-concept back when we were planning what to do. Things like gdbm and bdb are not required and are license contamination that we don't need. But that's the fault of the port, not a fundamental property of using svn. On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns That way the package build cluster would create a package of the static version which wouldn't pull in any runtime dependencies. Emanuel Peter, this work sounds great, and sounds like it would make a great stub port itself! I'd love to see whatever you have remaining from the proof-of-concept work, to perhaps help expand it into 'devel/subversion-lite' or 'devel/subversion-static' ? I'd happily use it for development. -- However, SVN for development use is not what the point, this thread is about using, administrating, and maintaining FreeBSD systems- not about development process. And in that case, SVN is still a fairly massive toolset for the simple task of fetching REL, STABLE, or CURRENT: Source for SVN-alone:55M Source for FreeBSD 9.1: 746M That's still over 7% of the size of the entire OS. I believe it's not at all necessary to have anything except the base FreeBSD OS, to update/install FreeBSD. -- A NYC*BUG list user posted this reminder, we've been here before: Deja-vu… This reminds me of cvsup+modula-3. http://www.mavetju.org/mail/view_message.php?list=freebsd-currentid=209027 I'll keep hacking on our shell utility, and will post the PR to this thread. Your shell utility appears to fetch a new tarball of the entire repo each time? That's very bandwidth-unfriendly for the Project's servers as well as yours... Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On 23 January 2013 19:17, Emanuel Haupt eha...@freebsd.org wrote: devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns Great idea; http://www.bayofrum.net/~crees/patches/svn-static.diff Lev, do you mind if I commit this? I haven't touched the subversion port, but it'll have you as maintainer :) If you prefer, I don't mind maintaining this. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
(Please keep me CC'd as I'm not subscribed to the list) Don't confuse the excessive ports default settings as dependencies. You can make a quite mean and lean svn client. I did a 100% BSD-license-compatible src/contrib/svn style proof-of-concept back when we were planning what to do. Things like gdbm and bdb are not required and are license contamination that we don't need. But that's the fault of the port, not a fundamental property of using svn. While I do understand what you're saying, the Oracle DB and GDBM actually aren't the the fault of the port, they're a result of what has been eluded to as a build cluster configuration problem or something along those lines. I brought up the dependency list mismatch in subversion.tbz on the package servers (ftp.freebsd.org) in mid November 2012; building from actual source (the port itself) did not pull in any of these dependencies: http://lists.freebsd.org/pipermail/freebsd-ports/2012-November/079589.html lev@ (port maintainer) had this to say: http://lists.freebsd.org/pipermail/freebsd-ports/2012-November/079592.html Quote: JC However, GDBM and Oracle/Sleepycat DB aren't (by default) enabled JC in 1.7.7 which is what's in ports currently: They weren't enabled for 1.7.6 too, so it is strange, that pointyhat-builded package require it. I need to investigate this. And that still seems to be the case today, as Mike Tancsa pointed out: http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071804.html What remains on ftp.freebsd.org is still the same today: $ ftp ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/ ... ftp dir subversion* 227 Entering Passive Mode (204,152,184,73,242,194). 150 Here comes the directory listing. lrwxr-xr-x1 967 10032 Oct 14 14:53 subversion-java.tbz - ../All/subversion-java-1.7.6.tbz lrwxr-xr-x1 967 10027 Oct 13 13:24 subversion.tbz - ../All/subversion-1.7.6.tbz lrwxr-xr-x1 967 10028 Oct 14 01:54 subversion16.tbz - ../All/subversion-1.6.18.tbz 226 Directory send OK. I'm left to believe lev@ hasn't had the cycles to investigate this, which is perfectly fine -- however given the importance of SVN at this point in FreeBSD's life, some other committer or whoever is responsible for the build cluster should have stepped up to the plate to figure this out, given how the *entire infrastructure* is now dependent upon this one thing. :-/ I can talk about the remaining dependencies that usually concern people (those are commonly sqlite3, expat, and apr) if required, but for now I'll stay squelched. And just as a footnote point: respectfully do not tell me this is a great opportunity to try pkgng. Please stay focused on the actual problem. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
Hello, Chris. You wrote 24 января 2013 г., 1:25:44: CR Great idea; CR http://www.bayofrum.net/~crees/patches/svn-static.diff I think, adding SERF or NEON (what is smaller) is good idea, or this build will lack http support, and it could be surprise to user, as http access method is well-know and useful in case of corporate firewalls. CR Lev, do you mind if I commit this? I haven't touched the subversion CR port, but it'll have you as maintainer :) Ok :) -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On 23 Jan 2013 21:45, Lev Serebryakov l...@freebsd.org wrote: Hello, Chris. You wrote 24 января 2013 г., 1:25:44: CR Great idea; CR http://www.bayofrum.net/~crees/patches/svn-static.diff I think, adding SERF or NEON (what is smaller) is good idea, or this build will lack http support, and it could be surprise to user, as http access method is well-know and useful in case of corporate firewalls. CR Lev, do you mind if I commit this? I haven't touched the subversion CR port, but it'll have you as maintainer :) Ok :) I'll check which makes a smaller package- thanks for the quick approval. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
(Please keep me CC'd as I'm not subscribed to the list) Great idea; http://www.bayofrum.net/~crees/patches/svn-static.diff Lev, do you mind if I commit this? I haven't touched the subversion port, but it'll have you as maintainer :) If you prefer, I don't mind maintaining this. As I understand it this patch would induce the build cluster to build subversion-static.tbz (eventually) and put it on the package servers. So what happens when one of the underlying dependencies that you've included statically (those would possibly be: Oracle/SleepyCat DB, APR, expat, sqlite3, neon, gettext, and iconv) have security holes or major bugs found/addressed in them? As I understand it -- based on history -- the packages on the FTP servers get updated whenever. My other post shows some haven't been updated in months (and yes I'm aware of the security incident). So how long would a key piece of software containing insecure statically-linked libraries be on the FTP servers? How would the port maintainer(s) even know the libraries/software which subversion is dependent upon had been updated, thus requiring a new subversion package to be pushed out to the package servers ASAP (i.e. immediately, not days, weeks, or months)? My point: ports have always been best-effort. They are advertised vehemently throughout everything FreeBSD as being third-party software and therefore infinite list of caveats. Yet now critical pieces to FreeBSD development (and now end-users too, as a result of using the security incident to push SVN) rely upon something in ports. That's quite a conundrum the Project has created for itself, an ouroboros of sorts. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees cr...@freebsd.org wrote: On 23 January 2013 19:17, Emanuel Haupt eha...@freebsd.org wrote: devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns Great idea; http://www.bayofrum.net/~crees/patches/svn-static.diff No, you completely missed the point. Its not about static linking its embedded subversion libraries. I'm complaining about things like gdbm and bdb via apr, build dependencies like both python and perl for apr, and so on. If you made a port just to turn on the static option, it is equally as fail as before. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, Jan 23, 2013 at 3:05 PM, Peter Wemm pe...@wemm.org wrote: On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees cr...@freebsd.org wrote: On 23 January 2013 19:17, Emanuel Haupt eha...@freebsd.org wrote: devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns Great idea; http://www.bayofrum.net/~crees/patches/svn-static.diff No, you completely missed the point. Its not about static linking its embedded subversion libraries. I'm complaining about things like gdbm and bdb via apr, build dependencies like both python and perl for apr, and so on. If you made a port just to turn on the static option, it is equally as fail as before. Specific example.. doing a portsnap and build of devel/subversion out of the box, you get: === The following actions will be taken if you choose to proceed: Install devel/subversion Install databases/sqlite3 Install devel/pkgconf Install devel/apr1 Install converters/libiconv Install devel/libtool Install databases/db42 Install databases/gdbm Install devel/gmake Install devel/gettext Install devel/autoconf Install devel/autoconf-wrapper Install devel/m4 Install lang/perl5.14 Install misc/help2man Install devel/p5-Locale-gettext Install devel/automake Install devel/automake-wrapper Install lang/python27 Install textproc/expat2 Install www/neon29 You can thin it down a bit by turning off a few bits.. neon-serf helps a little but not much. Trimming some runtime (vs buildtime) grandchildren like apr's gdbm/bdb modules trims some license dependencies. I'll update that list when the build is finished. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
Slawa Olhovchenkov s...@zxy.spb.ru wrote: pkg_info -r /usr/ports/packages6/All/subversion-1.7.8.tbz Information for /usr/ports/packages6/All/subversion-1.7.8.tbz: Depends on: Static linked, NEON included, run on 6+. This posting looks like an announcement of a package available for download, but it doesn't look right for a pathname on freebsd.org and Google isn't finding it (either on freebsd.org, or elsewhere). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: time issues and ZFS
On Jan 22, 2013, at 2:40 AM, Adrian Chadd adr...@freebsd.org wrote: On Jan 21, 2013, at 4:33 AM, Daniel Braniss da...@cs.huji.ac.il wrote: host: DELL PowerEdge R710, 16GB, I administer a Dell PowerEdge R710 and I've been seeing the exact same thing. It's currently running FreeBSD 9.0-STABLE #0 r236355. It has a ZFS pool which sees moderate load most of the time but can be very high at times (when certain scripts run, etc.). I hadn't previously correlated the issue with ZFS load but that is very possible. I set a cron job to restart ntpd when it dies (because the time difference exceeds the sanity check). The cron job runs every 20 minutes, but that varies greatly when the system stops counting. The time offset from ntpdate (which the script runs before restarting ntpd) varies a lot, but always in increments of 300 seconds. I've seen everything from 1200 to 23100. (Yes, that's 23 thousand seconds aka 6 hours 25 minutes that the system wasn't keeping time for.) Sysctl kern.timecounter.hardware defaults to HPET. I experimented with setting it to ACPI-fast but the issue persisted so I put it back. kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) I first installed the box with an older 9.0-STABLE and this issue was not present. I have been tracking -STABLE on it (albeit irregularly) so I'm not sure when the issue came up. Have you run tests with the machdep.idle value changed, and fiddling kern.eventtimer.periodic / kern.eventtimer.idletick ? I would love to resolve this and am able to do some experimenting. I've _usually_ been seeing the issue 2-3 times every 1-2 days, but I did just make some changes: disabling ZFS compression and deduplication on all pools updated to 9.1-STABLE from yesterday (r245821) If the issue persists I will try changing some of the sysctls above and follow up with the result. If it goes away, I'll try to remember to report that too. JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, Jan 23, 2013 at 3:16 PM, Peter Wemm pe...@wemm.org wrote: On Wed, Jan 23, 2013 at 3:05 PM, Peter Wemm pe...@wemm.org wrote: On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees cr...@freebsd.org wrote: On 23 January 2013 19:17, Emanuel Haupt eha...@freebsd.org wrote: devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns Great idea; http://www.bayofrum.net/~crees/patches/svn-static.diff No, you completely missed the point. Its not about static linking its embedded subversion libraries. I'm complaining about things like gdbm and bdb via apr, build dependencies like both python and perl for apr, and so on. If you made a port just to turn on the static option, it is equally as fail as before. Specific example.. doing a portsnap and build of devel/subversion out of the box, you get: === The following actions will be taken if you choose to proceed: Install devel/subversion Install databases/sqlite3 Install devel/pkgconf Install devel/apr1 Install converters/libiconv Install devel/libtool Install databases/db42 Install databases/gdbm Install devel/gmake Install devel/gettext Install devel/autoconf Install devel/autoconf-wrapper Install devel/m4 Install lang/perl5.14 Install misc/help2man Install devel/p5-Locale-gettext Install devel/automake Install devel/automake-wrapper Install lang/python27 Install textproc/expat2 Install www/neon29 You can thin it down a bit by turning off a few bits.. neon-serf helps a little but not much. Trimming some runtime (vs buildtime) grandchildren like apr's gdbm/bdb modules trims some license dependencies. I'll update that list when the build is finished. FWIW, this is the runtime dependency list apr-1.4.6.1.4.1_3 Apache Portability Library expat-2.0.1_2 XML 1.0 parser written in C gettext-0.18.1.1 GNU gettext package libiconv-1.14 A character set conversion library pkg-1.0.4_1New generation package manager pkgconf-0.8.9 Utility to help to configure compiler and linker flags serf-1.1.1 Serf HTTP client library sqlite3-3.7.14.1 An SQL database engine in a C library subversion-1.7.8 Version control system Doing a static link of the libsvn_* libraries into the binary doesn't help with this. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, Jan 23, 2013 at 03:20:32PM -0800, Perry Hutchison wrote: Slawa Olhovchenkov s...@zxy.spb.ru wrote: pkg_info -r /usr/ports/packages6/All/subversion-1.7.8.tbz Information for /usr/ports/packages6/All/subversion-1.7.8.tbz: Depends on: Static linked, NEON included, run on 6+. This posting looks like an announcement of a package available for download, but it doesn't look right for a pathname on freebsd.org and Google isn't finding it (either on freebsd.org, or elsewhere). I am don't have account on FreeBSD.org. http://zxy.spb.ru/subversion-1.7.8.tbz 17MB for downloading. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
Peter Wemm pe...@wemm.org wrote: On Wed, Jan 23, 2013 at 3:16 PM, Peter Wemm pe...@wemm.org wrote: On Wed, Jan 23, 2013 at 3:05 PM, Peter Wemm pe...@wemm.org wrote: On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees cr...@freebsd.org wrote: On 23 January 2013 19:17, Emanuel Haupt eha...@freebsd.org wrote: devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns Great idea; http://www.bayofrum.net/~crees/patches/svn-static.diff No, you completely missed the point. Its not about static linking its embedded subversion libraries. I'm complaining about things like gdbm and bdb via apr, build dependencies like both python and perl for apr, and so on. If you made a port just to turn on the static option, it is equally as fail as before. Specific example.. doing a portsnap and build of devel/subversion out of the box, you get: === The following actions will be taken if you choose to proceed: Install devel/subversion Install databases/sqlite3 Install devel/pkgconf Install devel/apr1 Install converters/libiconv Install devel/libtool Install databases/db42 Install databases/gdbm Install devel/gmake Install devel/gettext Install devel/autoconf Install devel/autoconf-wrapper Install devel/m4 Install lang/perl5.14 Install misc/help2man Install devel/p5-Locale-gettext Install devel/automake Install devel/automake-wrapper Install lang/python27 Install textproc/expat2 Install www/neon29 You can thin it down a bit by turning off a few bits.. neon-serf helps a little but not much. Trimming some runtime (vs buildtime) grandchildren like apr's gdbm/bdb modules trims some license dependencies. I'll update that list when the build is finished. FWIW, this is the runtime dependency list apr-1.4.6.1.4.1_3 Apache Portability Library expat-2.0.1_2 XML 1.0 parser written in C gettext-0.18.1.1 GNU gettext package libiconv-1.14 A character set conversion library pkg-1.0.4_1New generation package manager pkgconf-0.8.9 Utility to help to configure compiler and linker flags serf-1.1.1 Serf HTTP client library sqlite3-3.7.14.1 An SQL database engine in a C library subversion-1.7.8 Version control system Doing a static link of the libsvn_* libraries into the binary doesn't help with this. This is all I have in my buildjail: root@portjail:/root # uname -a FreeBSD portjail.home.critical.ch 9.1-STABLE FreeBSD 9.1-STABLE #1 r245789: Tue Jan 22 16:30:35 CET 2013 r...@alaska.home.critical.ch:/usr/obj/usr/src/sys/GENERIC amd64 root@portjail:/root # pkg_info subversion-1.7.8Version control system All this is is a package built with the default options of devel/subversion plus STATIC. I am perfectly able to use http as a chekout method: root@portjail:/root # svn checkout --depth empty http://svn.FreeBSD.org/ports/head/audio/yell ports/audio/yell Checked out revision 310914. root@portjail:/root # svn update --set-depth infinity ports/audio/yell/ Updating 'ports/audio/yell': Aports/audio/yell/distinfo Aports/audio/yell/pkg-descr Aports/audio/yell/Makefile Updated to revision 310914. root@portjail:/root # svn info ports/audio/yell/ Path: ports/audio/yell Working Copy Root Path: /root/ports/audio/yell URL: http://svn.freebsd.org/ports/head/audio/yell Repository Root: http://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 310914 Node Kind: directory Schedule: normal Last Changed Author: ehaupt Last Changed Rev: 306932 Last Changed Date: 2012-11-03 19:01:22 +0100 (Sat, 03 Nov 2012) Hence, to come back to the original post $ pkg_add -r subversion-static is the equivalent of $ pkg_add -r cvsup-without-gui Emanuel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On Wed, 23 Jan 2013 15:40:50 +0100 Oliver Brandmueller o...@e-gitt.net wrote: Hi, [skipped] So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? The current situaion for me is a bit annoying. From the user's or admin's point of view at least. I didn't even see an option in svn to not build the server components, which would probably already help to make things smaller? You may: 1/ install subversion on some host/jail 2/ do svn export ( f.e. svn://svn.freebsd.org/base/releng/9 stable_9) 3/ tar it 4/ on 'client' fetch(1)/scp/rsync tarball in that case you don't need svn on 'client', fetch and scp in base :) -- wbr, tiger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: time issues and ZFS
On Jan 22, 2013, at 2:40 AM, Adrian Chadd adr...@freebsd.org wrote: On Jan 21, 2013, at 4:33 AM, Daniel Braniss da...@cs.huji.ac.il wrote: host: DELL PowerEdge R710, 16GB, I administer a Dell PowerEdge R710 and I've been seeing the exact same =thing. It's currently running FreeBSD 9.0-STABLE #0 r236355. It has a =ZFS pool which sees moderate load most of the time but can be very high =at times (when certain scripts run, etc.). I hadn't previously =correlated the issue with ZFS load but that is very possible. I set a cron job to restart ntpd when it dies (because the time =difference exceeds the sanity check). The cron job runs every 20 =minutes, but that varies greatly when the system stops counting. The =time offset from ntpdate (which the script runs before restarting ntpd) =varies a lot, but always in increments of 300 seconds. I've seen =everything from 1200 to 23100. (Yes, that's 23 thousand seconds aka 6 =hours 25 minutes that the system wasn't keeping time for.) Sysctl kern.timecounter.hardware defaults to HPET. I experimented with =setting it to ACPI-fast but the issue persisted so I put it back. kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) HPET(950) i8254(0) =dummy(-100) I first installed the box with an older 9.0-STABLE and this issue was =not present. I have been tracking -STABLE on it (albeit irregularly) so =I'm not sure when the issue came up. Have you run tests with the machdep.idle value changed, and fiddling kern.eventtimer.periodic / kern.eventtimer.idletick ? I would love to resolve this and am able to do some experimenting. I've =_usually_ been seeing the issue 2-3 times every 1-2 days, but I did just =make some changes: disabling ZFS compression and deduplication on all pools updated to 9.1-STABLE from yesterday (r245821) If the issue persists I will try changing some of the sysctls above and =follow up with the result. If it goes away, I'll try to remember to =report that too. JN set kern.eventtimer.timer=LAPIC this solved it for me. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: svn - but smaller?
The objective is to return to a base build of FreeBSD that performs the expected task of being able to pull source, without having to acquire a port. Regardless of our individual solutions/workarounds, the task is to pull and maintain source. Is the discussion going to result in something like svn-lite that enters into the /usr/src/contrib along with the responsibilities associated with maintaining it? And then we need to take into consideration of being overwriting the base svn with a full svn package, if required by the user/admin. The issue involves policy decisions along with ongoing support load, rather than just a good technical solution; which as we've seen in earlier discussions, is sorely needed by the folks doing the development/maintenance. In the meantime, ftp isn't really workable for ongoing updates, and rsync is GPL'ed and can't be in the base system. I build svn from ports with all options off except for: ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn program. Suites me but doesn't address the underlying problem - and I don't think that the plan is to make FreeBSD dependent upon the ports system (for subversion) Regards, Dewayne. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
