Re: svn - but smaller?
Hello, Peter. You wrote 24 января 2013 г., 3:05:16: PW Its not about static linking its embedded subversion libraries. I'm This port will link statically EVERYTHING, what gets you PACKAGE without dependencies. PW complaining about things like gdbm and bdb via apr, build dependencies bdb abd gdbm is optional. PW like both python and perl for apr, and so on. -- // 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?
Sergey V. Dyatko sergey.dya...@gmail.com wrote: 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 :) If you go through all of that why not just install the damn svn from ports? I think you don't understand the reason why people are asking for this. I personally experienced the need not long ago. I had stable/9 branch and wanted to downgrade to 9.0. The entire process went well until I rebooted the system, to see tons of errors in pretty much everything that was compiled from ports. Instead recompiling them from scratch I just decided to go ahead and upgrade to 9.1 which was not officially released yet. And of course I could not perform svn sw because svn was broken too. And since svn has tons of dependencies it took me nearly an hour to recompile them (portupgrade and Ruby were broken too). -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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: panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated
On Jan 24, 2013, at 0:48, Ask Bjørn Hansen a...@develooper.com wrote: Hi everyone, I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few days ago. Booting the new image on a pcEngines Alix board it panics with a kmem_map too small error when mounting the disk. Any ideas what I'm doing wrong? In case it's useful, below is the full boot sequence. Ask PC Engines ALIX.2 v0.99h 640 KB Base Memory 130048 KB Extended Memory 01F0 Master 848A SanDisk SDCFJ-256 Phys C/H/S 980/16/32 Log C/H/S 248/32/63 1 FreeBSD 2 FreeBSD F6 PXE Boot: 2 /boot/config: -h FreeBSD/x86 boot Default: 0:ad(0,a)/boot/loader boot: Consoles: serial port BIOS drive C: is disk0 BIOS 640kB/130048kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (root@fbsdvm, Wed Jan 23 14:28:25 PST 2013) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x928f64 data=0x68a6c+0x89cb0 syms=[0x4+0x8d9e0+0x4+0xcc4ec] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #0: Wed Jan 23 14:51:17 PST 2013 root@fbsdvm:/usr/obj/nanobsd.grundwall/usr/src/sys/GRUNDCLOCK i386 CPU: Geode(TM) Integrated Processor by AMD PCS (431.65-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x5a2 Family = 0x5 Model = 0xa Stepping = 2 Features=0x88a93dFPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX AMD Features=0xc040MMX+,3DNow!+,3DNow! real memory = 134217728 (128 MB) avail memory = 116412416 (111 MB) pnpbios: Bad PnP BIOS data checksum K6-family MTRR support enabled (2 registers) cryptosoft0: software crypto on motherboard pcib0 pcibus 0 on motherboard pci0: PCI bus on pcib0 Geode LX: PC Engines ALIX.2 v0.99h tinyBIOS V1.4a (C)1997-2007 glxsb0: AMD Geode LX Security Block (AES-128-CBC, RNG) mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 vr0: VIA VT6105M Rhine III 10/100BaseTX port 0x1000-0x10ff mem 0xe000-0xe0ff irq 10 at device 9.0 on pci0 vr0: Quirks: 0x2 vr0: Revision: 0x96 miibus0: MII bus on vr0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr0: Ethernet address: 00:0d:b9:12:99:ec vr1: VIA VT6105M Rhine III 10/100BaseTX port 0x1400-0x14ff mem 0xe004-0xe00400ff irq 11 at device 10.0 on pci0 vr1: Quirks: 0x2 vr1: Revision: 0x96 miibus1: MII bus on vr1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr1: Ethernet address: 00:0d:b9:12:99:ed vr2: VIA VT6105M Rhine III 10/100BaseTX port 0x1800-0x18ff mem 0xe008-0xe00800ff irq 15 at device 11.0 on pci0 vr2: Quirks: 0x2 vr2: Revision: 0x96 miibus2: MII bus on vr2 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr2: Ethernet address: 00:0d:b9:12:99:ee isab0: PCI-ISA bridge port 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD CS5536 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 ohci0: OHCI (generic) USB controller mem 0xefffe000-0xefffefff irq 12 at device 15.4 on pci0 usbus0 on ohci0 ehci0: AMD CS5536 (Geode) USB 2.0 controller mem 0xefffd000-0xefffdfff irq 12 at device 15.5 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 cpu0 on motherboard orm0: ISA Option ROM at iomem 0xe-0xea7ff pnpid ORM on isa0 uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2f8-0x2ff irq 3 on isa0 atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer at port 0x40 on isa0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 ctl: CAM Target Layer loaded Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to accept, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: AMD at usbus0 uhub0: AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: AMD at usbus1 uhub1: AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: SanDisk SDCFJ-256
Re: svn - but smaller?
On Thu, Jan 24, 2013 at 06:34:33PM +1100, Dewayne wrote:
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.
Regarding your svn-lite theory of having that added to src/contrib/,
let me introduce you to Subversion's actual dependencies, and I'll
explain why these would have to remain enabled (for a base system
Subversion) as well:
* SQLite3 (used for bits/pieces in .svn/ directories)
-- License: http://www.sqlite.org/copyright.html
-- Not in the base system
* APR (used for HTTP fetching (not necessarily HTTPS))
-- License: http://www.apache.org/licenses/LICENSE-2.0.html
-- Not in the base system
* Expat 2.x (XML parsing/generation library
-- License: http://en.wikipedia.org/wiki/MIT_License
-- Not in the base system
* Neon or Serf (used for HTTPS fetching)
-- Neon license: http://www.gnu.org/copyleft/lgpl.html
-- Serf license: http://www.apache.org/licenses/LICENSE-2.0
-- Neither are in the base system
-- Serf supposedly has some kind of wonky/weird bugs on FreeBSD; I
remember reading about these on the mailing lists or in PRs, combined
with some statement about how newer Subversion uses Serf exclusively?
* gettext and libintl (used for character set support)
-- gettext license: GPL (not sure what version)
-- libintl license: LGPL (not sure what version)
-- Neither are in the base system
* libiconv (used for character set conversion)
-- License: LGPL (not sure what version)
-- Not in the base system
Why would all of these third-party bits be required? Keep reading.
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)
Though your OPTIONS recommendations work for you, they do not work for
everyone. Some people sit behind firewalls where HTTP or HTTPS are the
only viable means (native SVN or SVN+SSH will not work for them). Thus,
any kind of base system svn-lite would need to offer all of these
out-of-the-box, hence the above dependency list becoming mandatory.
src.conf WITHOUT_x knobs could turn some of these off, but they'd still
have to become part of src/contrib/.
FreeBSD for many years has been trying to remove non-BSD-compatible
software from the base system. I can't find the statement but the move
towards LLVM/Clang is partially driven by this, as well as the push to
move from GNU grep to bsdgrep.
Now, review the above dependencies and ask yourself the likelihood of
all of those being brought into src/ any where. I imagine given its
large dependency count on software that has non-BSD-compatible
licenses, that statement likely proves true. I believe there was also a
statement made in passing on the mailing lists not too long ago
mentioning that Subversion would never be brought into the base system
for that reason. I would love (LOVE!) to find out there are plans to
move it into the base system, but I can't see how given the above.
As for your last line:
FreeBSD is already dependent upon Subversion. This has been the case
for quite some time, but has only recently (as an indirect result of the
security incident) become forced upon users/administrators of FreeBSD.
The entire project is presently managed/maintained under Subversion.
The Handbook now documents that if you want to pull down src/ you need
to install Subversion. If you want to pull down ports/ you can use
portsnap and waste lots of /var space, hoping that the portsnap mirrors
are up to date, and a bunch of other hullabaloo... or you could just use
Subversion and be done with it.
There is no more cvsup. There is no more csup. There is no more cvs.
There is only Subversion (there is only Zuul...). I do not want to
talk about the whole security incident situation because it's another
topic that makes me quite volatile.
Also, just as a footnote point to readers: please do not bring up
svnsup. Until it's stated by some official FreeBSD person that
{committers} are actively working on this and bringing it into the
panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated
Hi everyone, I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few days ago. Booting the new image on a pcEngines Alix board it panics with a kmem_map too small error when mounting the disk. Any ideas what I'm doing wrong? Ask Trying to mount root from ufs:/dev/ada0s2a [ro]... panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated cpuid = 0 KDB: stack backtrace: #0 0xc089b0ff at kdb_backtrace+0x4f #1 0xc08678af at panic+0x16f #2 0xc0b0848a at kmem_malloc+0x28a #3 0xc0afbc87 at page_alloc+0x27 #4 0xc0afe320 at uma_large_malloc+0x50 #5 0xc085142c at malloc+0x8c #6 0xc07cedc0 at g_read_data+0x50 #7 0xc07d45f8 at g_label_ufs_taste_common+0x98 #8 0xc07d485b at g_label_ufs_id_taste+0x1b #9 0xc07d35ec at g_label_taste+0x3ec #10 0xc07d075f at g_new_provider_event+0x5f #11 0xc07ce205 at g_run_events+0x265 #12 0xc07cf6e9 at g_event_procbody+0x69 #13 0xc08366f6 at fork_exit+0x96 #14 0xc0b59e64 at fork_trampoline+0x8 Uptime: 13s Automatic reboot in 15 seconds - press a key on the console to abort ___ 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 Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy Chadwick' wrote: Regarding your svn-lite theory of having that added to src/contrib/, let me introduce you to Subversion's actual dependencies, and I'll explain why these would have to remain enabled (for a base system Subversion) as well: * gettext and libintl (used for character set support) Not need. ___ 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: panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated
--On January 24, 2013 0:49:35 -0800 Ask Bjørn Hansen a...@develooper.com wrote: On Jan 24, 2013, at 0:48, Ask Bjørn Hansen a...@develooper.com wrote: Hi everyone, I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few days ago. Booting the new image on a pcEngines Alix board it panics with a kmem_map too small error when mounting the disk. Any ideas what I'm doing wrong? In case it's useful, below is the full boot sequence. Ask PC Engines ALIX.2 v0.99h 640 KB Base Memory 130048 KB Extended Memory 01F0 Master 848A SanDisk SDCFJ-256 Phys C/H/S 980/16/32 Log C/H/S 248/32/63 1 FreeBSD 2 FreeBSD F6 PXE Boot: 2 /boot/config: -h FreeBSD/x86 boot Default: 0:ad(0,a)/boot/loader boot: Consoles: serial port BIOS drive C: is disk0 BIOS 640kB/130048kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (root@fbsdvm, Wed Jan 23 14:28:25 PST 2013) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x928f64 data=0x68a6c+0x89cb0 syms=[0x4+0x8d9e0+0x4+0xcc4ec] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #0: Wed Jan 23 14:51:17 PST 2013 root@fbsdvm:/usr/obj/nanobsd.grundwall/usr/src/sys/GRUNDCLOCK i386 CPU: Geode(TM) Integrated Processor by AMD PCS (431.65-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x5a2 Family = 0x5 Model = 0xa Stepping = 2 Features=0x88a93dFPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX AMD Features=0xc040MMX+,3DNow!+,3DNow! real memory = 134217728 (128 MB) avail memory = 116412416 (111 MB) pnpbios: Bad PnP BIOS data checksum K6-family MTRR support enabled (2 registers) cryptosoft0: software crypto on motherboard pcib0 pcibus 0 on motherboard pci0: PCI bus on pcib0 Geode LX: PC Engines ALIX.2 v0.99h tinyBIOS V1.4a (C)1997-2007 glxsb0: AMD Geode LX Security Block (AES-128-CBC, RNG) mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 vr0: VIA VT6105M Rhine III 10/100BaseTX port 0x1000-0x10ff mem 0xe000-0xe0ff irq 10 at device 9.0 on pci0 vr0: Quirks: 0x2 vr0: Revision: 0x96 miibus0: MII bus on vr0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr0: Ethernet address: 00:0d:b9:12:99:ec vr1: VIA VT6105M Rhine III 10/100BaseTX port 0x1400-0x14ff mem 0xe004-0xe00400ff irq 11 at device 10.0 on pci0 vr1: Quirks: 0x2 vr1: Revision: 0x96 miibus1: MII bus on vr1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr1: Ethernet address: 00:0d:b9:12:99:ed vr2: VIA VT6105M Rhine III 10/100BaseTX port 0x1800-0x18ff mem 0xe008-0xe00800ff irq 15 at device 11.0 on pci0 vr2: Quirks: 0x2 vr2: Revision: 0x96 miibus2: MII bus on vr2 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr2: Ethernet address: 00:0d:b9:12:99:ee isab0: PCI-ISA bridge port 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD CS5536 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 ohci0: OHCI (generic) USB controller mem 0xefffe000-0xefffefff irq 12 at device 15.4 on pci0 usbus0 on ohci0 ehci0: AMD CS5536 (Geode) USB 2.0 controller mem 0xefffd000-0xefffdfff irq 12 at device 15.5 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 cpu0 on motherboard orm0: ISA Option ROM at iomem 0xe-0xea7ff pnpid ORM on isa0 uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2f8-0x2ff irq 3 on isa0 atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer at port 0x40 on isa0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 ctl: CAM Target Layer loaded Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to accept, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: AMD at usbus0 uhub0: AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: AMD at usbus1 uhub1: AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0:
Re: svn - but smaller?
Hello, 'Jeremy. You wrote 24 января 2013 г., 12:57:17: JC to install Subversion. If you want to pull down ports/ you can use JC portsnap and waste lots of /var space, hoping that the portsnap mirrors JC are up to date, and a bunch of other hullabaloo... In case of csup, you relies that the cvs mirrors are up to date. And what about /var space... svn spends much more space in /usr/ports itself (.svn directory) than portsnap does (now my /var/db/portsnap directory is 95MiB, and .svn for ports will be comparable with size of ports itself!). I personally (maintainer of subversion port!) prefer csup over all other methods for non-developers systems too, and I'll be happy to see svnup when (if?) it will be created... -- // 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?
Quoth 'Jeremy Chadwick' j...@koitsu.org: Regarding your svn-lite theory of having that added to src/contrib/, let me introduce you to Subversion's actual dependencies, and I'll explain why these would have to remain enabled (for a base system Subversion) as well: * SQLite3 (used for bits/pieces in .svn/ directories) -- License: http://www.sqlite.org/copyright.html -- Not in the base system It is in HEAD, because the new Heimdal needs it. (The library is currently called libheimsqlite, and is built under kerberos5/lib, but both of those could be changed if necessary.) * APR (used for HTTP fetching (not necessarily HTTPS)) -- License: http://www.apache.org/licenses/LICENSE-2.0.html -- Not in the base system * Expat 2.x (XML parsing/generation library -- License: http://en.wikipedia.org/wiki/MIT_License -- Not in the base system So these could potentially be brought in? I'm not sure if the Apache license is considered sufficiently BSDish? * Neon or Serf (used for HTTPS fetching) This could be considered optional, for a base-system svn, as long as the repository is available over HTTP. If necessary the binary could be renamed to bsdsvn so as not to conflict with a full-featured svn installed from ports. (Of course, HTTPS would be *nice*.) * gettext and libintl (used for character set support) -- gettext license: GPL (not sure what version) -- libintl license: LGPL (not sure what version) -- Neither are in the base system Don't know about these, but I'd be surprised if it wasn't possible to build svn without them. That means losing i18n, but I'm fairly sure csup didn't have i18n either. * libiconv (used for character set conversion) -- License: LGPL (not sure what version) -- Not in the base system There is a BSD-licensed libiconv in HEAD, though it currently isn't built by default. So, it looks to me as though it would be possible, in principle, to bring svn into the base. I'm not at all sure I think that would be a good idea (in particular, bringing in both APR and Expat just to download a few files seems excessive), but it could perhaps be provided as a make.conf option for those who are concerned. (Personally I would not willingly use svn again for any reason, so I'm keeping my source up-to-date using the github mirror. I wonder whether a BSD-licensed checkout-only git client would be easier to write than svnsup? I'm certain the wire protocol is more efficient.) Ben ___ 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?
Am Thu, 24 Jan 2013 00:57:17 -0800 schrieb 'Jeremy Chadwick' j...@koitsu.org: Though your OPTIONS recommendations work for you, they do not work for everyone. Some people sit behind firewalls where HTTP or HTTPS are the only viable means (native SVN or SVN+SSH will not work for them). But then, cvsup/csup didn't work either, right? So, what did those people do in the days of cvsup? As for the whole dependency/license nightmare - there is some truth[1] in that and I'm sure, the people in charge are aware of it. I was always under the assumption that the switch to svn was more of a temporary stopgap solution where the benefits (progress of the FreeBSD project) out-weighted the deficiencies. The migration to a better system is supposed to be easier from svn than cvs... [1] I have the need to have mod_dav_svn in my subversion-package (because a customer needs it and I only want to maintain one pkgng-repo). Thus, every time svn is installed, apache gets pulled in, too. Awesome. ___ 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?
At 9AM + on 24/01/13 you (Ben Morrow) wrote: Quoth 'Jeremy Chadwick' j...@koitsu.org: Regarding your svn-lite theory of having that added to src/contrib/, let me introduce you to Subversion's actual dependencies, and I'll explain why these would have to remain enabled (for a base system Subversion) as well: snip * APR (used for HTTP fetching (not necessarily HTTPS)) -- License: http://www.apache.org/licenses/LICENSE-2.0.html -- Not in the base system * Expat 2.x (XML parsing/generation library -- License: http://en.wikipedia.org/wiki/MIT_License -- Not in the base system Correction: expat is in base already, as libbsdxml (rather confusingly built under lib/libexpat). So AFAICS the only remaining piece is APR (and svn itself), and I suspect that if only the bits required for a svn client were brought in (assuming the licence is deemed acceptable) that would be a lot smaller than a full APR build. (Again, this would need to be built as libbsdapr to avoid conflicts with real APR from ports.) Ben ___ 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 2013-Jan-23 15:40:50 +0100, Oliver Brandmueller o...@e-gitt.net wrote: 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. There was also ctm(1). ctm is small, BSD-licensed and has been part of FreeBSD forever (almost). Thanks to stephen@, ctm deltas for various src trees, as well as the entire SVN repo are still available. c[v]sup can do things than aren't possible with ctm but I would expect that most people who currently use c[v]sup could readily migrate to using ctm. See http://www.freebsd.org/doc/handbook/ctm.html for details. Note that mirroring the actual SVN repo via ctm requires some patches. There is a README and patches in ftp://ftp.freebsd.org/pub/FreeBSD/CTM/svn-cur/ -- Peter Jeremy pgpTfeB8Ea6dH.pgp Description: PGP signature
Re: svn - but smaller?
On Thu, 24 Jan 2013 18:34:33 +1100 Dewayne dewayne.gerag...@heuristicsystems.com.au wrote: 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 Hello all, I'm working on writing a lightweight, dependency-free, BSD licensed program to pull source using the svn protocol (not using the aforementioned svnsup code). I've only got a few more pieces of the puzzle to sort out and some code cleanup and it should be ready for testing. As someone who has never contributed code, what's the best way to submit this code for consideration? Do I just slap a BSD license on it and post it to the list? Do I first create a port for it? Also, does anyone know who I should contact regarding permission to test my code against the repository at svn.freebsd.org? Thanks. ___ 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 24/01/2013 11:30, John Mehr wrote: I'm working on writing a lightweight, dependency-free, BSD licensed program to pull source using the svn protocol (not using the aforementioned svnsup code). I've only got a few more pieces of the puzzle to sort out and some code cleanup and it should be ready for testing. Ooooh... shiny! Thank you very much indeed for working on this. It's an area where a solution is very much in demand. As someone who has never contributed code, what's the best way to submit this code for consideration? Do I just slap a BSD license on it and post it to the list? Do I first create a port for it? Also, does anyone know who I should contact regarding permission to test my code against the repository at svn.freebsd.org? Thanks. Ummm... both of the above. If you submit it as a port, it will get into the ports a lot quicker than it would get into src, plus it will be available to all FreeBSD users to test straight away. Once it does go into src, it will take a number of release cycles before it can be considered generally available. Given a good track record in ports, you'll find it easier to persuade people to import it into src. For testing against svn.freebsd.org -- this is pull only? So you only need read permissions on svn.freebsd.org? That's fine: the SVN repository is open to public access and you can just use it without asking permission. Although I'd use one of the mirror sites listed in the handbook rather than svn.freebsd.org directly. Note: for read-only access you can use svn:// http:// and https:// type URLs. If you want to test, say, svn+ssh:// then you'll need to find a committer to help you out. However, as the only reason to have svn+ssh:// access is to be able to commit, it's probably out of scope for your case. Cheers, Matthew ___ 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.01.2013 15:40, Oliver Brandmueller wrote: 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 is not a well publicized fact, but I understand that the base utility freebsd-update(8) through it's freebsd-update.conf(5) is able to pull the base sources (/usr/src/) only instead of also updating your binaries. less /etc/freebsd-update.conf # Components of the base system which should be kept updated. Components src world kernel The above setting is the default, but you may easily leave out everything but src. (Caveat: I have not tried it myself yet.) It also have some optional settings for preserving local changes to the source instead of blowing them away (default). This will allow you to use the sources for a custom build and install yourself. Also for ports we have the portsnap(8) utility, also in base. So it is perfectly possible to get sources for everything using just the tools in base. No csup or svnup is required. Best regards, Gyrd ^_^ ___ 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?
For testing against svn.freebsd.org -- this is pull only? So you only need read permissions on svn.freebsd.org? That's fine: the SVN repository is open to public access and you can just use it without asking permission. Although I'd use one of the mirror sites listed in the handbook rather than svn.freebsd.org directly. Correct. I just want to give the folks that administer the servers a heads-up that there's going to be a lot more entries in their log files coming from me -- unless it's an undocumented feature of the svn protocol, md5 signatures for files are not included in directory requests and I need to issue a get-file command for each and every file to get their md5 signatures in order to determine which local files need an update. :( ___ 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?
Hi, all, Am 24.01.2013 um 15:20 schrieb Gyrd Thane Lange gyrd...@thanelange.no: It is not a well publicized fact, but I understand that the base utility freebsd-update(8) through it's freebsd-update.conf(5) is able to pull the base sources (/usr/src/) only instead of also updating your binaries. less /etc/freebsd-update.conf # Components of the base system which should be kept updated. Components src world kernel The above setting is the default, but you may easily leave out everything but src. (Caveat: I have not tried it myself yet.) It also have some optional settings for preserving local changes to the source instead of blowing them away (default). This will allow you to use the sources for a custom build and install yourself. I tried that and found that at least /usr/src/UPDATING was not touched by freebsd-update. See e4e97bb3-4535-4e9f-ad78-e16a94f75...@punkt.de on this list. Any hints welcome - must have been doing someting wrong. Thanks Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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 24 Jan 2013 14:33, John Mehr j...@visi.com wrote: For testing against svn.freebsd.org -- this is pull only? So you only need read permissions on svn.freebsd.org? That's fine: the SVN repository is open to public access and you can just use it without asking permission. Although I'd use one of the mirror sites listed in the handbook rather than svn.freebsd.org directly. Correct. I just want to give the folks that administer the servers a heads-up that there's going to be a lot more entries in their log files coming from me -- unless it's an undocumented feature of the svn protocol, md5 signatures for files are not included in directory requests and I need to issue a get-file command for each and every file to get their md5 signatures in order to determine which local files need an update. :( It'd probably be faster for you to use svnsync to get a local mirror of the repo. 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 Jan 2013 21:55, Jeremy Chadwick j...@koitsu.org wrote: (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? The package would be updated on the next build, since a dependency changed. 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). That's why, so for normal use it's irrelevant. So how long would a key piece of software containing insecure statically-linked libraries be on the FTP servers? No longer than any other package. 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. This is not intended as general use for everyone, it's intended as a shortcut when building a new machine or anything else. I'll put a big warning in pkg message :) 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
9.1-stable crashes while copying data from a NFS mounted directory
Hi!
I'm using 9.1 stable svn revision 245605 and I get the panic below if I execute
the following commands (as single user):
# swapon -a
# dumpon /dev/ada0s3b
# mount -u /
# ifconfig age0 inet 192.168.2.2 mtu 6144 up
# mount -t nfs -o rsize=32768 data:/multimedia /mnt
# cp /mnt/Movies/test/a.m2ts /tmp
then the system panics almost immediately. I'll attach the stack trace.
Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe that's
the cause for the panic, because the bcopy (see
stack frame #15) fails.
Any clues?
Ciao,
Christian.
#0 doadump (textdump=0)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265
265 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265
#1 0x802a8ba0 in db_dump (dummy=value optimized out,
dummy2=value optimized out, dummy3=value optimized out,
dummy4=value optimized out)
at /spare/tmp/src-stable9/sys/ddb/db_command.c:538
#2 0x802a84ce in db_command (last_cmdp=0x808bc5c0,
cmd_table=value optimized out, dopager=1)
at /spare/tmp/src-stable9/sys/ddb/db_command.c:449
#3 0x802a8720 in db_command_loop ()
at /spare/tmp/src-stable9/sys/ddb/db_command.c:502
#4 0x802aa859 in db_trap (type=value optimized out,
code=value optimized out)
at /spare/tmp/src-stable9/sys/ddb/db_main.c:231
#5 0x803c4918 in kdb_trap (type=3, code=0, tf=0xff81b2da8a80)
at /spare/tmp/src-stable9/sys/kern/subr_kdb.c:649
#6 0x805a02cf in trap (frame=0xff81b2da8a80)
at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:579
#7 0x8058992f in calltrap ()
at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228
#8 0x803c43cb in kdb_enter (why=0x806145f3 panic,
msg=0x80 Address 0x80 out of bounds) at cpufunc.h:63
#9 0x8038f407 in panic (fmt=value optimized out)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:627
#10 0x80568049 in vm_fault_hold (map=0xfe000200,
vaddr=18446743530148802560, fault_type=2 '\002', fault_flags=0,
m_hold=0x0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:285
#11 0x80568753 in vm_fault (map=0xfe000200,
vaddr=18446743530148802560, fault_type=value optimized out,
fault_flags=0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:229
#12 0x805a00c7 in trap_pfault (frame=0xff81b2da9170, usermode=0)
at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:771
#13 0x805a051e in trap (frame=0xff81b2da9170)
at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:463
#14 0x8058992f in calltrap ()
at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228
#15 0x8059d7b5 in bcopy ()
at /spare/tmp/src-stable9/sys/amd64/amd64/support.S:134
#16 0x81c5963b in nfsm_mbufuio (nd=0xff81b2da9320,
uiop=value optimized out, siz=32768)
at
/spare/tmp/src-stable9/sys/modules/nfscommon/../../fs/nfs/nfs_commonsubs.c:212
#17 0x81c19571 in nfsrpc_read (vp=0xfe0005ca2000,
uiop=0xff81b2da95a0, cred=value optimized out,
p=0xfe0005f28000, nap=0xff81b2da9480,
attrflagp=0xff81b2da954c, stuff=0x0)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clrpcops.c:1343
#18 0x81c3aff0 in ncl_readrpc (vp=0xfe0005ca2000,
uiop=0xff81b2da95a0, cred=value optimized out)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clvnops.c:1366
#19 0x81c2fed3 in ncl_doio (vp=0xfe0005ca2000,
bp=0xff816fabca20, cr=0xfe0002d59e00, td=0xfe0005f28000,
called_from_strategy=0)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:1605
#20 0x81c32aaf in ncl_bioread (vp=0xfe0005ca2000,
uio=0xff81b2da9ad0, ioflag=value optimized out,
cred=0xfe0002d59e00)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:541
#21 0x804379c3 in vn_read (fp=0xfe0005f3e960,
uio=0xff81b2da9ad0, active_cred=value optimized out,
flags=value optimized out, td=value optimized out) at vnode_if.h:384
#22 0x80434d40 in vn_io_fault (fp=0xfe0005f3e960,
uio=0xff81b2da9ad0, active_cred=0xfe0002d59e00, flags=0,
td=0xfe0005f28000) at /spare/tmp/src-stable9/sys/kern/vfs_vnops.c:903
#23 0x803d7bd1 in dofileread (td=0xfe0005f28000, fd=3,
fp=0xfe0005f3e960, auio=0xff81b2da9ad0,
offset=value optimized out, flags=0) at file.h:287
#24 0x803d7f7c in kern_readv (td=0xfe0005f28000, fd=3,
auio=0xff81b2da9ad0)
at /spare/tmp/src-stable9/sys/kern/sys_generic.c:250
#25 0x803d8074 in sys_read (td=value optimized out,
uap=value optimized out)
at /spare/tmp/src-stable9/sys/kern/sys_generic.c:166
#26 0x8059f4f0 in amd64_syscall (td=0xfe0005f28000, traced=0)
at subr_syscall.c:135
#27 0x80589c17 in
Re: svn - but smaller?
On 24.01.2013 15:46, Patrick M. Hausen wrote: Hi, all, Am 24.01.2013 um 15:20 schrieb Gyrd Thane Lange gyrd...@thanelange.no: It is not a well publicized fact, but I understand that the base utility freebsd-update(8) through it's freebsd-update.conf(5) is able to pull the base sources (/usr/src/) only instead of also updating your binaries. less /etc/freebsd-update.conf # Components of the base system which should be kept updated. Components src world kernel The above setting is the default, but you may easily leave out everything but src. (Caveat: I have not tried it myself yet.) It also have some optional settings for preserving local changes to the source instead of blowing them away (default). This will allow you to use the sources for a custom build and install yourself. I tried that and found that at least /usr/src/UPDATING was not touched by freebsd-update. See e4e97bb3-4535-4e9f-ad78-e16a94f75...@punkt.de on this list. Any hints welcome - must have been doing someting wrong. I just tried (src only), from an 8.2 system: # freebsd-update -r 8.3-RELEASE upgrade # freebsd-update install This gave me the same experience as you. The latest entry in UPDATING is 20120411: 8.3-RELEASE (The good news is that it actually updated it from 8.2 to 8.3, so it did not ignore it completely.) But all other files under the /usr/src/ hierarchy is properly updated. For instance: # egrep '^(REVISION|BRANCH)' /usr/src/sys/conf/newvers.sh REVISION=8.3 BRANCH=RELEASE-p5 This gives me some confidence that I've got the important bits from -p5, even though UPDATING remains at unpatched level. I guess there is some bug or misconfiguration on the server side of freebsd-update that ignores some files. I have no idea. ;-) In short, I think you used the correct commands, and that it is reasonable to expect the /usr/src/UPDATING file to be updated. Regards, Gyrd ^_^ Thanks Patrick ___ 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: panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated
On Jan 24, 2013, at 1:16, Göran Löwkrantz goran.lowkra...@ismobile.com wrote: Search for cam clt kmem in the lists. I had to add kern.cam.ctl.disable=1 on a Soekris box with 9.1. Thanks Göran; that did indeed fix it. Michael Moll sent me the same solution off-list and a link to http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-td5771583.html I changed my kernel to not include that driver now and all is well, even on my 64MB Soekris 4501 board. :-) Thank you again! Ask ___ 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: RFC: Suggesting ZFS best practices in FreeBSD
#1. Map the physical drive slots to how they show up in FBSD so if a disk is removed and the machine is rebooted all the disks after that removed one do not have an 'off by one error'. i.e. if you have ada0-ada14 and remove ada8 then reboot - normally FBSD skips that missing ada8 drive and the next drive (that used to be ada9) is now called ada8 and so on... How do you do that? If I'm in that situation, I think I could find the bad drive, or at least the good ones, with diskinfo and the drive serial number. One suggestion I saw somewhere was to use disk serial numbers for label values. The term FreeBSD uses for this is called wiring down or wired down, and is documented in CAM(4). It's come up repeatedly over the years but for whatever reason people overlook it or can't find it. Here's how you do it for Intel AHCI (and probably others like AMD), taken directly from my /boot/loader.conf -- # Wire down device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at=ahcich0 hint.scbus.1.at=ahcich1 hint.scbus.2.at=ahcich2 hint.scbus.3.at=ahcich3 hint.scbus.4.at=ahcich4 hint.scbus.5.at=ahcich5 hint.ada.0.at=scbus0 hint.ada.1.at=scbus1 hint.ada.2.at=scbus2 hint.ada.3.at=scbus3 hint.ada.4.at=scbus4 hint.ada.5.at=scbus5 IMPORTANT: The device names/busses/etc. are going to vary depending on each person's setup, controller, etc.. Proof of this is in a post from Randy Bush, where I helped him off-list with this task and he figured out the remaining bits by himself for his hptrr(4) controller: http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014522.html You can use labels if you want, but I prefer to just have statically assigned device names regardless of a bay being populated by a disk or not. That's my preference. Other people like labels and that's fine -- I just can't stand the utter mess that is labelling on FreeBSD, sans GPT labels. And finally, touching /boot/device.hints is wrong. Do not do this. Ever. This file is actually managed by either mergemaster or installkernel/installworld (I forget which). Use /boot/loader.conf for any hint overrides/adjustments. Leave /boot/device.hints alone. -- | 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?
Hi On 24.01.2013 18:10, Gyrd Thane Lange wrote: On 24.01.2013 15:46, Patrick M. Hausen wrote: This gives me some confidence that I've got the important bits from -p5, even though UPDATING remains at unpatched level. I guess there is some bug or misconfiguration on the server side of freebsd-update that ignores some files. I have no idea. ;-) In short, I think you used the correct commands, and that it is reasonable to expect the /usr/src/UPDATING file to be updated. I had a search through the PR database, and came across this: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/147430 freebsd-update(8) not updating /usr/src/UPDATING I appears to be a long outstanding issue (from june 2010). Not really critical, but certainly confusing. Gyrd ^_^ Regards, Gyrd ^_^ Thanks Patrick ___ 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-stable crashes while copying data from a NFS mounted directory
On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote:
Hi!
I'm using 9.1 stable svn revision 245605 and I get the panic below if I
execute the following commands (as single user):
# swapon -a
# dumpon /dev/ada0s3b
# mount -u /
# ifconfig age0 inet 192.168.2.2 mtu 6144 up
# mount -t nfs -o rsize=32768 data:/multimedia /mnt
# cp /mnt/Movies/test/a.m2ts /tmp
then the system panics almost immediately. I'll attach the stack trace.
Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe
that's the cause for the panic, because the bcopy (see
stack frame #15) fails.
Any clues?
I tried a similar operation with the nfs mount of rsize=32768 and mtu
6144, but the machine runs HEAD and em instead of age. I was unable to
reproduce the panic on the copy of the 5GB file from nfs mount.
Show the output of p *(struct uio *)0xff81b2da95a0 in kgdb.
Ciao,
Christian.
#0 doadump (textdump=0)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265
265 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265
#1 0x802a8ba0 in db_dump (dummy=value optimized out,
dummy2=value optimized out, dummy3=value optimized out,
dummy4=value optimized out)
at /spare/tmp/src-stable9/sys/ddb/db_command.c:538
#2 0x802a84ce in db_command (last_cmdp=0x808bc5c0,
cmd_table=value optimized out, dopager=1)
at /spare/tmp/src-stable9/sys/ddb/db_command.c:449
#3 0x802a8720 in db_command_loop ()
at /spare/tmp/src-stable9/sys/ddb/db_command.c:502
#4 0x802aa859 in db_trap (type=value optimized out,
code=value optimized out)
at /spare/tmp/src-stable9/sys/ddb/db_main.c:231
#5 0x803c4918 in kdb_trap (type=3, code=0, tf=0xff81b2da8a80)
at /spare/tmp/src-stable9/sys/kern/subr_kdb.c:649
#6 0x805a02cf in trap (frame=0xff81b2da8a80)
at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:579
#7 0x8058992f in calltrap ()
at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228
#8 0x803c43cb in kdb_enter (why=0x806145f3 panic,
msg=0x80 Address 0x80 out of bounds) at cpufunc.h:63
#9 0x8038f407 in panic (fmt=value optimized out)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:627
#10 0x80568049 in vm_fault_hold (map=0xfe000200,
vaddr=18446743530148802560, fault_type=2 '\002', fault_flags=0,
m_hold=0x0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:285
#11 0x80568753 in vm_fault (map=0xfe000200,
vaddr=18446743530148802560, fault_type=value optimized out,
fault_flags=0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:229
#12 0x805a00c7 in trap_pfault (frame=0xff81b2da9170, usermode=0)
at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:771
#13 0x805a051e in trap (frame=0xff81b2da9170)
at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:463
#14 0x8058992f in calltrap ()
at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228
#15 0x8059d7b5 in bcopy ()
at /spare/tmp/src-stable9/sys/amd64/amd64/support.S:134
#16 0x81c5963b in nfsm_mbufuio (nd=0xff81b2da9320,
uiop=value optimized out, siz=32768)
at
/spare/tmp/src-stable9/sys/modules/nfscommon/../../fs/nfs/nfs_commonsubs.c:212
#17 0x81c19571 in nfsrpc_read (vp=0xfe0005ca2000,
uiop=0xff81b2da95a0, cred=value optimized out,
p=0xfe0005f28000, nap=0xff81b2da9480,
attrflagp=0xff81b2da954c, stuff=0x0)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clrpcops.c:1343
#18 0x81c3aff0 in ncl_readrpc (vp=0xfe0005ca2000,
uiop=0xff81b2da95a0, cred=value optimized out)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clvnops.c:1366
#19 0x81c2fed3 in ncl_doio (vp=0xfe0005ca2000,
bp=0xff816fabca20, cr=0xfe0002d59e00, td=0xfe0005f28000,
called_from_strategy=0)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:1605
#20 0x81c32aaf in ncl_bioread (vp=0xfe0005ca2000,
uio=0xff81b2da9ad0, ioflag=value optimized out,
cred=0xfe0002d59e00)
at
/spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:541
#21 0x804379c3 in vn_read (fp=0xfe0005f3e960,
uio=0xff81b2da9ad0, active_cred=value optimized out,
flags=value optimized out, td=value optimized out) at vnode_if.h:384
#22 0x80434d40 in vn_io_fault (fp=0xfe0005f3e960,
uio=0xff81b2da9ad0, active_cred=0xfe0002d59e00, flags=0,
td=0xfe0005f28000) at /spare/tmp/src-stable9/sys/kern/vfs_vnops.c:903
#23 0x803d7bd1 in dofileread (td=0xfe0005f28000, fd=3,
fp=0xfe0005f3e960, auio=0xff81b2da9ad0,
offset=value optimized out, flags=0)
Re: 9.1-stable crashes while copying data from a NFS mounted directory
On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: Hi! I'm using 9.1 stable svn revision 245605 and I get the panic below if I execute the following commands (as single user): # swapon -a # dumpon /dev/ada0s3b # mount -u / # ifconfig age0 inet 192.168.2.2 mtu 6144 up # mount -t nfs -o rsize=32768 data:/multimedia /mnt # cp /mnt/Movies/test/a.m2ts /tmp then the system panics almost immediately. I'll attach the stack trace. Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe that's the cause for the panic, because the bcopy (see stack frame #15) fails. Any clues? I tried a similar operation with the nfs mount of rsize=32768 and mtu 6144, but the machine runs HEAD and em instead of age. I was unable to reproduce the panic on the copy of the 5GB file from nfs mount. Show the output of p *(struct uio *)0xff81b2da95a0 in kgdb. And the output of p *(struct buf *)0xff816fabca20. pgp7FpCXEXXAM.pgp Description: PGP signature
Re: 9.1-stable crashes while copying data from a NFS mounted directory
On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote:
On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote:
On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote:
Hi!
I'm using 9.1 stable svn revision 245605 and I get the panic below if I
execute the following commands (as single user):
# swapon -a
# dumpon /dev/ada0s3b
# mount -u /
# ifconfig age0 inet 192.168.2.2 mtu 6144 up
# mount -t nfs -o rsize=32768 data:/multimedia /mnt
# cp /mnt/Movies/test/a.m2ts /tmp
then the system panics almost immediately. I'll attach the stack trace.
Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe
that's the cause for the panic, because the bcopy (see stack frame
#15) fails.
Any clues?
I tried a similar operation with the nfs mount of rsize=32768 and mtu
6144, but the machine runs HEAD and em instead of age. I was unable to
reproduce the panic on the copy of the 5GB file from nfs mount.
Show the output of p *(struct uio *)0xff81b2da95a0 in kgdb.
(kgdb) p *(struct uio *)0xff81b2da95a0
$1 = {uio_iov = 0xff81b2da95d0, uio_iovcnt = 1, uio_offset = 5964,
uio_resid = 26804,
uio_segflg = UIO_SYSSPACE, uio_rw = UIO_READ, uio_td = 0xfe0005f28000}
And the output of p *(struct buf *)0xff816fabca20.
(kgdb) p *(struct buf *)0xff816fabca20
$2 = {b_bufobj = 0xfe0005ca2120, b_bcount = 32768, b_caller1 = 0x0,
b_data = 0xff8171418000 ø\017, b_error = 0, b_iocmd = 1 '\001',
b_ioflags = 0 '\0', b_iooffset = 0, b_resid = 0, b_iodone = 0, b_blkno = 0,
b_offset = 0, b_bobufs = {tqe_next = 0x0, tqe_prev = 0xfe0005ca2140},
b_left = 0x0,
b_right = 0x0, b_vflags = 0, b_freelist = {tqe_next = 0x0,
tqe_prev = 0x80926900}, b_qindex = 0, b_flags = 536870912,
b_xflags = 2 '\002', b_lock = {lock_object = {lo_name = 0x8061d778
bufwait,
lo_flags = 91422720, lo_data = 0, lo_witness = 0x0},
lk_lock = 18446741874786074624, lk_exslpfail = 0, lk_timo = 0, lk_pri =
96},
b_bufsize = 32768, b_runningbufspace = 0, b_kvabase = 0xff8171418000
ø\017,
b_kvasize = 32768, b_lblkno = 0, b_vp = 0xfe0005ca2000, b_dirtyoff = 0,
b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr =
0xff8171418000,
b_pager = {pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first = 0x0,
tqh_last = 0x0}, cluster_entry = {tqe_next = 0x0, tqe_prev = 0x0}},
b_pages = {
0xfe01f1786708, 0xfe01f1785880, 0xfe01f17858f8,
0xfe01f1785970,
0xfe01f17859e8, 0xfe01f1785a60, 0xfe01f1785ad8,
0xfe01f1785b50,
0x0 repeats 24 times}, b_npages = 8, b_dep = {lh_first = 0x0},
b_fsprivate1 = 0x0,
b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0}
___
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-stable crashes while copying data from a NFS mounted directory
On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: Hi! I'm using 9.1 stable svn revision 245605 and I get the panic below if I execute the following commands (as single user): # swapon -a # dumpon /dev/ada0s3b # mount -u / # ifconfig age0 inet 192.168.2.2 mtu 6144 up # mount -t nfs -o rsize=32768 data:/multimedia /mnt # cp /mnt/Movies/test/a.m2ts /tmp then the system panics almost immediately. I'll attach the stack trace. Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe that's the cause for the panic, because the bcopy (see stack frame #15) fails. Any clues? I tried a similar operation with the nfs mount of rsize=32768 and mtu 6144, but the machine runs HEAD and em instead of age. I was unable to reproduce the panic on the copy of the 5GB file from nfs mount. Hmmm, I did a quick test. If I do not change the MTU, so just configuring age0 with # ifconfig age0 inet 192.168.2.2 up then I can copy all files from the mounted directory without any problems, too. So it's probably age0 related? Ciao, Christian. ___ 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-stable crashes while copying data from a NFS mounted directory
On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote:
On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote:
On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote:
On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote:
Hi!
I'm using 9.1 stable svn revision 245605 and I get the panic below if I
execute the following commands (as single user):
# swapon -a
# dumpon /dev/ada0s3b
# mount -u /
# ifconfig age0 inet 192.168.2.2 mtu 6144 up
# mount -t nfs -o rsize=32768 data:/multimedia /mnt
# cp /mnt/Movies/test/a.m2ts /tmp
then the system panics almost immediately. I'll attach the stack trace.
Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe
that's the cause for the panic, because the bcopy (see stack frame
#15) fails.
Any clues?
I tried a similar operation with the nfs mount of rsize=32768 and mtu
6144, but the machine runs HEAD and em instead of age. I was unable to
reproduce the panic on the copy of the 5GB file from nfs mount.
Hmmm, I did a quick test. If I do not change the MTU, so just configuring
age0
with
# ifconfig age0 inet 192.168.2.2 up
then I can copy all files from the mounted directory without any problems,
too. So it's probably age0 related?
From your backtrace and the buffer printout, I see somewhat strange thing.
The buffer data address is 0xff8171418000, while kernel faulted
at the attempt to write at 0xff8171413000, which is is lower then
the buffer data pointer, at the attempt to bcopy to the buffer.
The other data suggests that there were no overflow of the data from the
server response. So it might be that mbuf_len(mp) returned negative number ?
I am not sure is it possible at all.
Try this debugging patch, please. You need to add INVARIANTS etc to the
kernel config.
diff --git a/sys/fs/nfs/nfs_commonsubs.c b/sys/fs/nfs/nfs_commonsubs.c
index efc0786..9a6bda5 100644
--- a/sys/fs/nfs/nfs_commonsubs.c
+++ b/sys/fs/nfs/nfs_commonsubs.c
@@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio *uiop,
int siz)
}
mbufcp = NFSMTOD(mp, caddr_t);
len = mbuf_len(mp);
+ KASSERT(len 0, (len %d, len));
}
xfer = (left len) ? len : left;
#ifdef notdef
@@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio *uiop,
int siz)
uiop-uio_resid -= xfer;
}
if (uiop-uio_iov-iov_len = siz) {
+ KASSERT(uiop-uio_iovcnt 1, (uio_iovcnt %d,
+ uiop-uio_iovcnt));
uiop-uio_iovcnt--;
uiop-uio_iov++;
} else {
I thought that server have returned too long response, but it seems to
be not the case from your data. Still, I think the patch below might be
due.
diff --git a/sys/fs/nfsclient/nfs_clrpcops.c b/sys/fs/nfsclient/nfs_clrpcops.c
index be0476a..a89b907 100644
--- a/sys/fs/nfsclient/nfs_clrpcops.c
+++ b/sys/fs/nfsclient/nfs_clrpcops.c
@@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio *uiop, struct ucred
*cred,
NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED);
eof = fxdr_unsigned(int, *tl);
}
- NFSM_STRSIZ(retlen, rsize);
+ NFSM_STRSIZ(retlen, len);
error = nfsm_mbufuio(nd, uiop, retlen);
if (error)
goto nfsmout;
pgpIbrH5zjxPK.pgp
Description: PGP signature
Re: 9.1-stable crashes while copying data from a NFS mounted directory
On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote:
On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote:
On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote:
On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote:
On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote:
Hi!
I'm using 9.1 stable svn revision 245605 and I get the panic below
if I execute the following commands (as single user):
# swapon -a
# dumpon /dev/ada0s3b
# mount -u /
# ifconfig age0 inet 192.168.2.2 mtu 6144 up
# mount -t nfs -o rsize=32768 data:/multimedia /mnt
# cp /mnt/Movies/test/a.m2ts /tmp
then the system panics almost immediately. I'll attach the stack
trace.
Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network,
maybe that's the cause for the panic, because the bcopy (see stack
frame #15) fails.
Any clues?
I tried a similar operation with the nfs mount of rsize=32768 and mtu
6144, but the machine runs HEAD and em instead of age. I was unable
to reproduce the panic on the copy of the 5GB file from nfs mount.
Hmmm, I did a quick test. If I do not change the MTU, so just configuring
age0 with
# ifconfig age0 inet 192.168.2.2 up
then I can copy all files from the mounted directory without any
problems, too. So it's probably age0 related?
From your backtrace and the buffer printout, I see somewhat strange thing.
The buffer data address is 0xff8171418000, while kernel faulted
at the attempt to write at 0xff8171413000, which is is lower then
the buffer data pointer, at the attempt to bcopy to the buffer.
The other data suggests that there were no overflow of the data from the
server response. So it might be that mbuf_len(mp) returned negative number
? I am not sure is it possible at all.
Try this debugging patch, please. You need to add INVARIANTS etc to the
kernel config.
diff --git a/sys/fs/nfs/nfs_commonsubs.c b/sys/fs/nfs/nfs_commonsubs.c
index efc0786..9a6bda5 100644
--- a/sys/fs/nfs/nfs_commonsubs.c
+++ b/sys/fs/nfs/nfs_commonsubs.c
@@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio
*uiop, int siz) }
mbufcp = NFSMTOD(mp, caddr_t);
len = mbuf_len(mp);
+ KASSERT(len 0, (len %d, len));
}
xfer = (left len) ? len : left;
#ifdef notdef
@@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio
*uiop, int siz) uiop-uio_resid -= xfer;
}
if (uiop-uio_iov-iov_len = siz) {
+ KASSERT(uiop-uio_iovcnt 1, (uio_iovcnt %d,
+ uiop-uio_iovcnt));
uiop-uio_iovcnt--;
uiop-uio_iov++;
} else {
I thought that server have returned too long response, but it seems to
be not the case from your data. Still, I think the patch below might be
due.
diff --git a/sys/fs/nfsclient/nfs_clrpcops.c
b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 100644
--- a/sys/fs/nfsclient/nfs_clrpcops.c
+++ b/sys/fs/nfsclient/nfs_clrpcops.c
@@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio *uiop, struct
ucred *cred, NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED);
eof = fxdr_unsigned(int, *tl);
}
- NFSM_STRSIZ(retlen, rsize);
+ NFSM_STRSIZ(retlen, len);
error = nfsm_mbufuio(nd, uiop, retlen);
if (error)
goto nfsmout;
I applied your patches and now I get a
panic: len -4
cpuid = 1
KDB: enter: panic
Dumping 377 out of 6116 MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..94%
#0 doadump (textdump=0)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265
265 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0)
at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265
#1 0x802a7490 in db_dump (dummy=value optimized out,
dummy2=value optimized out, dummy3=value optimized out,
dummy4=value optimized out)
at /spare/tmp/src-stable9/sys/ddb/db_command.c:538
#2 0x802a6a7e in db_command (last_cmdp=0x808ca140,
cmd_table=value optimized out, dopager=1)
at /spare/tmp/src-stable9/sys/ddb/db_command.c:449
#3 0x802a6cd0 in db_command_loop ()
at /spare/tmp/src-stable9/sys/ddb/db_command.c:502
#4 0x802a8e29 in db_trap (type=value optimized out,
code=value optimized out)
at /spare/tmp/src-stable9/sys/ddb/db_main.c:231
#5 0x803bf548 in kdb_trap (type=3, code=0, tf=0xff81b2ba1080)
at /spare/tmp/src-stable9/sys/kern/subr_kdb.c:649
#6 0x80594c28 in trap (frame=0xff81b2ba1080)
at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:579
#7 0x8057e06f in
Re: svn - but smaller?
On 25/01/2013 03:13, Chris Rees wrote: On 24 Jan 2013 14:33, John Mehr j...@visi.com wrote: Correct. I just want to give the folks that administer the servers a heads-up that there's going to be a lot more entries in their log files coming from me -- unless it's an undocumented feature of the svn protocol, md5 signatures for files are not included in directory requests and I need to issue a get-file command for each and every file to get their md5 signatures in order to determine which local files need an update. :( It'd probably be faster for you to use svnsync to get a local mirror of the repo. and if you're going to set up a local mirror, save yourself a couple of days' sync time. Instead of synchronizing from scratch, start with the most recent seed file (repository archive) available on your nearest FTP mirror. ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ Clues for building a mirror can be found here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html#AEN1201 ...but if you're only using it for testing - and it doesn't need to be up to date - then you don't need to worry about setting up svnsync and updating your local mirror. Simply unbundling an archive of a repository from a seed file and serving it via svnserve (and/or apache) is all you need to do. -- John Marshall signature.asc Description: OpenPGP digital signature
Re: svn - but smaller?
On Thu, 24 Jan 2013 00:06:47 -0800 Derek Kulinski tak...@takeda.tk wrote: Sergey V. Dyatko sergey.dya...@gmail.com wrote: 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 :) If you go through all of that why not just install the damn svn from ports? I have svn installed on all my boxes (for src and configs) ;-) I think you don't understand the reason why people are asking for this. I personally experienced the need not long ago. I had stable/9 branch and wanted to downgrade to 9.0. The entire process went well until I rebooted the system, to see tons of errors in pretty much everything that was compiled from ports. Instead recompiling them from scratch I just decided to go ahead and upgrade to 9.1 which was not officially released yet. how in this case you would have helped availability lite-svn-client on base ? And of course I could not perform svn sw because svn was broken too. r232944 | lev | 2009-04-29 15:11:17 +0300 ... (3) Add STATIC option to build only static binaries [2] ... And since svn has tons of dependencies it took me nearly an hour to recompile them (portupgrade and Ruby were broken too). that's why I don't use portupgrade for a long time;-) use portmaster WTF -- 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: svn - but smaller?
On Fri, 25 Jan 2013 09:09:58 +0300, Sergey V. Dyatko wrote: On Thu, 24 Jan 2013 00:06:47 -0800 Derek Kulinski tak...@takeda.tk wrote: Sergey V. Dyatko sergey.dya...@gmail.com wrote: 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 :) If you go through all of that why not just install the damn svn from ports? I have svn installed on all my boxes (for src and configs) ;-) I think you don't understand the reason why people are asking for this. I personally experienced the need not long ago. I had stable/9 branch and wanted to downgrade to 9.0. The entire process went well until I rebooted the system, to see tons of errors in pretty much everything that was compiled from ports. Instead recompiling them from scratch I just decided to go ahead and upgrade to 9.1 which was not officially released yet. how in this case you would have helped availability lite-svn-client on base ? And of course I could not perform svn sw because svn was broken too. r232944 | lev | 2009-04-29 15:11:17 +0300 ... (3) Add STATIC option to build only static binaries [2] ... And since svn has tons of dependencies it took me nearly an hour to recompile them (portupgrade and Ruby were broken too). that's why I don't use portupgrade for a long time;-) use portmaster WTF Portupgrade works fine for me. What's the problem with it? ___ 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 Fri, 25 Jan 2013 07:27:58 + (UTC) Walter Hurry walterhu...@gmail.com wrote: On Fri, 25 Jan 2013 09:09:58 +0300, Sergey V. Dyatko wrote: On Thu, 24 Jan 2013 00:06:47 -0800 Derek Kulinski tak...@takeda.tk wrote: Sergey V. Dyatko sergey.dya...@gmail.com wrote: 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 :) If you go through all of that why not just install the damn svn from ports? I have svn installed on all my boxes (for src and configs) ;-) I think you don't understand the reason why people are asking for this. I personally experienced the need not long ago. I had stable/9 branch and wanted to downgrade to 9.0. The entire process went well until I rebooted the system, to see tons of errors in pretty much everything that was compiled from ports. Instead recompiling them from scratch I just decided to go ahead and upgrade to 9.1 which was not officially released yet. how in this case you would have helped availability lite-svn-client on base ? And of course I could not perform svn sw because svn was broken too. r232944 | lev | 2009-04-29 15:11:17 +0300 ... (3) Add STATIC option to build only static binaries [2] ... And since svn has tons of dependencies it took me nearly an hour to recompile them (portupgrade and Ruby were broken too). that's why I don't use portupgrade for a long time;-) use portmaster WTF Portupgrade works fine for me. What's the problem with it? 1) portupgrade and Ruby were broken too from original email (yep, long time ago I faced with this too) 2) heavy depts(ruby) 3) don't know how it is now, but before it was supported weakly (large thread in ports@ (?) year or two ago, IIRC) -- 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
