Re: Svnsup architecture
Disclaimer: I am trying to go inside the technicalities of the SVN protocol. I am not sure whether this sub-thread should belong to this list or to another; I am open to suggestions on this topic. On Fri, Jan 25, 2013 at 07:40:45PM -0600, John Mehr wrote: > On Fri, 25 Jan 2013 13:42:19 +0100 Arrigo Marchiori wrote: > > On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy > > > > 1- svnsup-distill: takes a revision from svn and creates > > a text file (called a delta) that represents it. It seems to be > > almost complete. > > > To answer one of John Mehr's problems: MD5 sums are calculated by > > svnsup-distill and included in the deltas. The client only needs > > to check them against the local files. > > Hello, > > I've been looking for a way to get the details of a > complete revision in one step, but I haven't had any luck > yet. This would solve the one aspect I'm most worried > about: with 5+ files and 5500+ directories in my local > copy of /usr/src, I'd hate to have my code end up > inadvertently causing a denial of service on the > repositories with a flood of tiny requests... After investigating more in depth the SVN protocol, if I understood correctly, your problem cannot be solved. Or, at least, the server is not supposed to help us. The SVN client, in fact, seems to save a copy of the whole working copy inside the .svn directory. Whether a file was changed or not, it is an information that the _client_ knows, before it contacts the server. A "svn update" command sends to the server the start and end revisions (the latter in the svn-update message, the first in the set-path message). Merging the information from the server (delta's) with the working copy is the client's job. To summarize, any svn-like downloader should at least know: 1- the current revision of the working copy; 2- the checksums of all the files in the repository, at the current revision. The "official" SVN client does more than point 2: it stores the whole content of each file; this allows the "svn diff" and "svn revert" commands to work off-line. Best regards, -- rigo http://rigo.altervista.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: Svnsup architecture
On Sun, 27 Jan 2013 13:49:08 +0100 Arrigo Marchiori wrote: > Disclaimer: I am trying to go inside the technicalities >of the SVN > protocol. I am not sure whether this sub-thread should >belong to this > list or to another; I am open to suggestions on this >topic. > > On Fri, Jan 25, 2013 at 07:40:45PM -0600, John Mehr >wrote: > >> On Fri, 25 Jan 2013 13:42:19 +0100 Arrigo Marchiori >> wrote: >> > On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy >> > >> > 1- svnsup-distill: takes a revision from svn and >>creates >> > a text file (called a delta) that represents it. It >>seems to be >> > almost complete. >> >> > To answer one of John Mehr's problems: MD5 sums are >>calculated by >> > svnsup-distill and included in the deltas. The client >>only needs >> > to check them against the local files. >> >> Hello, >> >> I've been looking for a way to get the details of a >> complete revision in one step, but I haven't had any >>luck >> yet. This would solve the one aspect I'm most worried >> about: with 5+ files and 5500+ directories in my >>local >> copy of /usr/src, I'd hate to have my code end up >> inadvertently causing a denial of service on the >> repositories with a flood of tiny requests... > > After investigating more in depth the SVN protocol, if I >understood > correctly, your problem cannot be solved. Or, at least, >the server is > not supposed to help us. > > The SVN client, in fact, seems to save a copy of the >whole working > copy inside the .svn directory. > > Whether a file was changed or not, it is an information >that the > _client_ knows, before it contacts the server. > > A "svn update" command sends to the server the start and >end > revisions (the latter in the svn-update message, the >first in the > set-path message). Merging the information from the >server (delta's) > with the working copy is the client's job. > > To summarize, any svn-like downloader should at least >know: > 1- the current revision of the working copy; > 2- the checksums of all the files in the repository, at >the current >revision. > > The "official" SVN client does more than point 2: it >stores the whole > content of each file; this allows the "svn diff" and >"svn revert" > commands to work off-line. > > Best regards, > -- > rigo > > http://rigo.altervista.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" > Hello, Thanks for looking into this. I was experimenting yesterday with the commands to checkout a revision and still wasn't getting the checksums. I also noticed when I ran a svn pg svn:mime-types -R There was a get-file log entry for each file so my concerns may not be an issue in the end. Thanks again. ___ 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: libstdc++, libsupc++, delete operators and valgrind
On Sun, Jan 20, 2013 at 02:19:55PM +0200, Mikolaj Golub wrote:
> Hi,
>
> Some time ago I noticed that valgrind started to complain about
> "Mismatched free() / delete / delete []" for valid new/delete
> combinations.
>
> For example, the following test program
>
> int main()
> {
> char* buf = new char[10];
> delete [] buf;
>
> return 0;
> }
>
> produced a warning:
>
> ==38718== Mismatched free() / delete / delete []
> ==38718==at 0x100416E: free (vg_replace_malloc.c:473)
> ==38718==by 0x4007BE: main (test.cpp:5)
> ==38718== Address 0x2400040 is 0 bytes inside a block of size 10 alloc'd
> ==38718==at 0x10047D7: operator new[](unsigned long)
> (vg_replace_malloc.c:382)
> ==38718==by 0x40079D: main (test.cpp:4)
>
> For some time I hoped that "someone" would fix the problem but seeing
> that after several upgrades it was still there I decided it is time to
> do some investigations.
>
> Running the valgrind with "--trace-redir=yes -v" showed that valgrind
> activates redirections for new/delete symbols in libstdc++:
>
> --6729-- Reading syms from /usr/lib/libstdc++.so.6 (0x1209000)
> ...
> --6729---- ACTIVE --
> ...
> --6729-- 0x01260770 (operator new[](unsig) R-> (1001.0) 0x010041b0
> operator new[](unsigned long, std::nothrow_t const&)
> --6729-- 0x01260780 (operator new(unsigne) R-> (1001.0) 0x01004270
> operator new(unsigned long, std::nothrow_t const&)
> --6729-- 0x012608a0 (operator delete[](vo) R-> (1005.0) 0x01003e40
> operator delete[](void*, std::nothrow_t const&)
> --6729-- 0x012608b0 (operator delete(void) R-> (1005.0) 0x01003fa0
> operator delete(void*, std::nothrow_t const&)
> --6729-- 0x012dea90 (operator new[](unsig) R-> (1003.0) 0x01004770
> operator new[](unsigned long)
> --6729-- 0x012deab0 (operator new(unsigne) R-> (1003.0) 0x01004860
> operator new(unsigned long)
> --6729-- 0x012deca0 (operator delete[](vo) R-> (1005.0) 0x01003ef0
> operator delete[](void*)
> --6729-- 0x012e2b80 (operator delete(void) R-> (1005.0) 0x01004050
> operator delete(void*)
>
> But "delete" redirection is not triggered, while "new" is:
>
> --6729-- REDIR: 0x12dea90 (operator new[](unsigned long)) redirected to
> 0x1004770 (operator new[](unsigned long))
> --6729-- REDIR: 0x19dd9a0 (free) redirected to 0x1004100 (free)
> ==6729== Mismatched free() / delete / delete []
> ==6729==at 0x100416E: free (vg_replace_malloc.c:473)
> ==6729==by 0x400715: main (test.cpp:5)
> ==6729== Address 0x1ed7040 is 0 bytes inside a block of size 10 alloc'd
> ==6729==at 0x10047D7: operator new[](unsigned long)
> (vg_replace_malloc.c:382)
> ==6729==by 0x400701: main (test.cpp:4)
>
> A little research revealed that in this case the delete operator from
> libsupc++ is called and valgrind does not provide redirections for the
> symbols in libsupc++.
>
> When I added the redirections for libsupc++ to valgrind's
> vg_replace_malloc.c:
>
> #define VG_Z_LIBSUPCXX_SONAME libsupcZpZpZa // libsupc++*
>
> FREE(VG_Z_LIBSUPCXX_SONAME, _ZdlPv,__builtin_delete );
> FREE(VG_Z_LIBSUPCXX_SONAME, _ZdlPvRKSt9nothrow_t, __builtin_delete );
> FREE(VG_Z_LIBSUPCXX_SONAME, _ZdaPv, __builtin_vec_delete );
> FREE(VG_Z_LIBSUPCXX_SONAME, _ZdaPvRKSt9nothrow_t, __builtin_vec_delete );
>
> the issue was fixed:
>
> --99254-- Reading syms from /usr/lib/libstdc++.so.6
> ...
> --99254---- ACTIVE --
> ...
> --99254-- 0x012627c0 (operator new[](unsig) R-> (1001.0) 0x01004ce0
> operator new[](unsigned long, std::nothrow_t const&)
> --99254-- 0x012627d0 (operator new(unsigne) R-> (1001.0) 0x01004860
> operator new(unsigned long, std::nothrow_t const&)
> --99254-- 0x012628d0 (operator delete[](vo) R-> (1005.0) 0x01005b00
> operator delete[](void*, std::nothrow_t const&)
> --99254-- 0x012628e0 (operator delete(void) R-> (1005.0) 0x01005500
> operator delete(void*, std::nothrow_t const&)
> --99254-- 0x012c27e0 (operator new[](unsig) R-> (1003.0) 0x01004a80
> operator new[](unsigned long)
> --99254-- 0x012c2800 (operator new(unsigne) R-> (1003.0) 0x01004430
> operator new(unsigned long)
> --99254-- 0x012c29a0 (operator delete[](vo) R-> (1005.0) 0x01005800
> operator delete[](void*)
> --99254-- 0x012c3e40 (operator delete(void) R-> (1005.0) 0x01005200
> operator delete(void*)
> ...
> --99254-- Reading syms from /usr/lib/libsupc++.so.1
> ...
> --99254---- ACTIVE --
> ...
> --99254-- 0x01cae1f0 (operator delete[](vo) R-> (1005.0) 0x01005a00
> operator delete[](void*, std::nothrow_t const&)
> --99254-- 0x01cae200 (operator delete[](vo) R-> (1005.0) 0x01005700
> operator delete[](void*)
> --99254-- 0x01cae210 (operator delete(void) R-> (1005.0) 0x01005400
> operator delete(void*, std::nothrow_t const&)
> --99254-- 0x01cb73d0 (operator delete(void) R-> (1005.0) 0x01005100
> operator delete(void*)
> ...
> --99254-- REDIR
Re: bge numbering
On Fri, 25 Jan 2013 09:46:10 +0100, Daniel Braniss wrote: Hi, this server, a Dell R720 has 4 bge on board, Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 bge0: APE FW version: NCSI v1.1.7.0 bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E miibus0: on bge0 ... I have connected the ethernet to port labeled 0, but it appears as bge2, how can this be corrected? thanks, danny See /etc/defaults/rc.conf: #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. or 'ifconfig name'. 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: bge numbering
> On Fri, 25 Jan 2013 09:46:10 +0100, Daniel Braniss > wrote: > > > Hi, > > this server, a Dell R720 has 4 bge on board, > > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 > > bge0: APE FW version: NCSI v1.1.7.0 > > bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E > > miibus0: on bge0 > > ... > > > > I have connected the ethernet to port labeled 0, but it appears > > as bge2, how can this be corrected? > > > > thanks, > > danny > > > > See /etc/defaults/rc.conf: > #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. > > or 'ifconfig name'. > > Ronald. too late, I have first to do a ifconfig_bge?=SYNCDHCP oh well, lets move on. thanks, 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: time issues and ZFS
On 26 January 2013 02:15, Andriy Gapon wrote: > on 23/01/2013 18:20 Adrian Chadd said the following: >> 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.. > > This is not software related at all. It's the hardware feature (or its > absence). > I wonder if your celerons report PBE feature. What am I looking for? And personally, requiring (much) more recent hardware to get sane/correct (btu inefficient) behaviour out of the timekeeping framework is a little .. suboptimal. :) 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: time issues and ZFS
on 27/01/2013 19:27 Adrian Chadd said the following: > On 26 January 2013 02:15, Andriy Gapon wrote: >> on 23/01/2013 18:20 Adrian Chadd said the following: >>> 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.. >> >> This is not software related at all. It's the hardware feature (or its >> absence). >> I wonder if your celerons report PBE feature. > > What am I looking for? PBE in dmesg > And personally, requiring (much) more recent hardware to get > sane/correct (btu inefficient) behaviour out of the timekeeping > framework is a little .. suboptimal. :) Well, I never knew about this issue before but I always assumed that the reasonable behavior was the behavior. And I never encountered any evidence to the contrary. -- 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"
mergemaster -p / installkernel problem
# mergemaster -p *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot *** Beginning comparison *** Comparison complete *** /var/tmp/temproot is empty, deleting # make installkernel ERROR: Required auditdistd user is missing, see /usr/src/UPDATING. *** [installcheck_UGID] Error code 1 Stop in /usr/src. *** [installkernel] Error code 1 Stop in /usr/src. Why doesn't mergemaster find the updated master.password file? # grep FreeBSD /etc/master.passwd # $FreeBSD: stable/9/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $ # grep FreeBSD /usr/src/etc/master.passwd # $FreeBSD: stable/9/etc/master.passwd 243947 2012-12-06 11:52:31Z rwatson $ ___ 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 9:40 AM, Oliver Brandmueller wrote: > Hi, > > in ancient times there was cvsup. ... > Then there came csup. ... > Times have been changing, we're now up to svn. ... > alternative small svn client I'm trying to consolidate notes on this topic, here: https://wiki.freebsd.org/UsersFetchingSource (Aiming to condense some clarity for as many parts of the situation as I can). Please feel to make edits (esp. if you are a committer who knows something I don't!), or email me with corrections and I'll put them in! 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"
named fails two weeks ago unexpectedly
Hi I was used FreeBSD 9.1 Release since December 2012, I usually use "portsnap fetch && update" and "portmaster-a" to keep my system updated. Two weeks ago unexpectedly "named" not worked. this is my case: "Problem: root@server:/etc # /etc/rc.d/named start /etc/rc.d/named: ERROR: get_pidfile_from_conf: /etc/namedb/named.conf does not exist (named) Checking: root@server:/etc # ls -l /var/named/etc/namedb total 40 drwxr-xr-x 2 bind wheel 512 Dec 4 04:32 dynamic drwxr-xr-x 2 root wheel 512 Dec 4 04:34 master -rw-r--r-- 1 bind wheel 15150 Jan 17 15:57 named.conf -rw-r--r-- 1 bind wheel 3135 Dec 4 04:34 named.root -rw--- 1 bind wheel 97 Dec 22 03:49 rndc.key drwxr-xr-x 2 bind wheel 512 Dec 4 04:32 slave drwxr-xr-x 2 bind wheel 512 Jan 27 13:25 working root@server:/root # cat /etc/defaults/rc.conf | grep named # named. It may be possible to run named in a sandbox, man security for named_enable="NO" # Run named, the DNS server (or NO). named_program="/usr/sbin/named" # Path to named, if you want a different one. named_conf="/etc/namedb/named.conf" # Path to the configuration file #named_flags="" # Use this for flags OTHER than -u and -c named_uid="bind" # User to run named as named_chrootdir="/var/named" # Chroot directory (or "" not to auto-chroot it) named_chroot_autoupdate="YES" # Automatically install/update chrooted # components of named. See /etc/rc.d/named. named_symlink_enable="YES" # Symlink the chrooted pid file named_wait="NO" # Wait for working name service before exiting named_wait_host="localhost" # Hostname to check if named_wait is enabled named_auto_forward="NO" # Set up forwarders from /etc/resolv.conf named_auto_forward_only="NO" # Do "forward only" instead of "forward first" root@server:/root # cat /etc/rc.conf | grep named named_enable="YES" Cause: FreeBSD 9.1 was running OK, but "named" failed for no apparent reason My Solution: root@server:/etc # ln -s /var/named/etc/namedb /etc/namedb root@server:/etc # /etc/rc.d/named start Starting named." I do not know what happened with "named" that it fails two weeks ago, any ideas ? William Moreno ___ 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: mergemaster -p / installkernel problem
On Sun, Jan 27, 2013 at 11:18 AM, Michiel Boland wrote: > # mergemaster -p > > *** Creating the temporary root environment in /var/tmp/temproot > *** /var/tmp/temproot ready for use > *** Creating and populating directory structure in /var/tmp/temproot > > > > *** Beginning comparison > > > *** Comparison complete > > *** /var/tmp/temproot is empty, deleting > > # make installkernel > ERROR: Required auditdistd user is missing, see /usr/src/UPDATING. > *** [installcheck_UGID] Error code 1 > > Stop in /usr/src. > *** [installkernel] Error code 1 > > Stop in /usr/src. > > > > Why doesn't mergemaster find the updated master.password file? > > # grep FreeBSD /etc/master.passwd > # $FreeBSD: stable/9/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $ > # grep FreeBSD /usr/src/etc/master.passwd > # $FreeBSD: stable/9/etc/master.passwd 243947 2012-12-06 11:52:31Z rwatson $ If you 'grep auditdistd /usr/src/etc/master.passwd', does is it there? I have the same version and auditdistd is there, and mergemaster -p did catch it. You don't by any chance have a mergemaster.rc in /etc or .mergemasterrc in $HOME? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: svn - but smaller?
Hi Peter, On Jan 24, 2013, at 6:13 AM, Peter Jeremy wrote: > On 2013-Jan-23 15:40:50 +0100, Oliver Brandmueller 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 Thank you for adding the ctm bits in the page, I'm deeply intrigued by possibly solving this problem with bits *already* in base?!! https://wiki.freebsd.org/action/diff/UsersFetchingSource?action=diff&rev1=6&rev2=7 However, even after reading the handbook page, I just don't quite understand how to use it on a modern system. (The handbook page isn't too helpful, nor is the man page- perhaps I'm looking at it backwards) Could you help clarify: - does CTM go away with the CVS servers? - do CTM-compatable patch/delta files exist on project repos? - what is the cleanest path to using CTM? (e.g. is the patch you mention required) -- Say I have a bare 9.1 install, no ports, haven't downloaded any base/src or ports yet. How do I go about using ctm(1) to fetch REL or STABLE to /usr/src, command by command? 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 01/27/2013 09:24 PM, Isaac (.ike) Levy wrote: > Hi Peter, > > On Jan 24, 2013, at 6:13 AM, Peter Jeremy wrote: > >> On 2013-Jan-23 15:40:50 +0100, Oliver Brandmueller 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 > > Thank you for adding the ctm bits in the page, I'm deeply intrigued by > possibly solving this problem with bits *already* in base?!! > > https://wiki.freebsd.org/action/diff/UsersFetchingSource?action=diff&rev1=6&rev2=7 > > However, even after reading the handbook page, I just don't quite understand > how to use it on a modern system. (The handbook page isn't too helpful, nor > is the man page- perhaps I'm looking at it backwards) Could you help clarify: > > - does CTM go away with the CVS servers? > - do CTM-compatable patch/delta files exist on project repos? > - what is the cleanest path to using CTM? (e.g. is the patch you mention > required) > > -- > Say I have a bare 9.1 install, no ports, haven't downloaded any base/src or > ports yet. > How do I go about using ctm(1) to fetch REL or STABLE to /usr/src, command by > command? First, you don't need any patches to get started. Suppose you want to keep up with 9.x-stable. Then you look at the ftp site ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-9/, look at the latest xEmpty file, and fetch it. Then create an empty directory /usr/src, and then do cd /usr/src && ctm the-xEmpty-file-you-downloaded. No need to decompress the file first. Then fetch from the same web site all the files whose number is greater than the xEmpty file you downloaded and do cd /usr/src && ctm the-rest-of-the-files* Now in /usr/src, you will have a reasonably up to date version of 9.x-stable. You can keep it up to date by getting more files, either from the ftp site, or by email, and doing again cd /usr/src && ctm the-rest-of-the-files* It will automatically ignore the files already applied. Similar instructions for all the other stable/currents and ports. Main thing to remember - start with an empty directory. Also making local changes is not permitted. If ctm tries to modify a file whose md5 checksum has changed, it will quit with an error message. (But it won't leave your system in an unusable state - if you put that file back to its original state, then ctm will work again.) Now, if you want something not offered by ctm (e.g. 8.2-release), then you need to use svn. You can get svn via ctm. But you (1) need to apply the patch, (2) install the svn port, and (3) install the xz port if your FreeBSD is really old. ___ 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 Sun, 27 Jan 2013 16:03:35 -0500 "Isaac (.ike) Levy" wrote: On Jan 25, 2013, at 8:27 PM, John Mehr wrote: On Fri, 25 Jan 2013 10:27:23 +0100 Oliver Brandmueller wrote: Also I'd like to mention John Mehr, who's work on a "lightweight, dependency-free, BSD licensed program to pull source using the svn protocol" (couldn't say it better, so I use his words :-)). Hope this will make it into ports soon and in the long run even to base! Thank you for the kind words. If all goes well (I'm still wearing my "Crown of Naive Optimism") I should have something ready for show-and-tell in the next week or so and I'll be submitting it as a new port soon after that. John, Pullin' for you man! If you make progress, please give a shout and I'll note it in this page: https://wiki.freebsd.org/UsersFetchingSource Best, .ike Hello, I think I've got all of the protocol issues sorted out as good as they'll probably get. I can't get the exact file permissions from the get-file requests -- it only lets me know which ones are executable. Setting executables to 0755 and non-executables to 0644 would work for all files in my copy of /usr/src except for /usr/src/usr.bin/lex/mkskel.sh (0744) and /usr/src/usr.sbin/pkg_install/tkpkg (0754). Since they're both executable for root, unless there's an issue, we could probably let it slide and assign them 0755 permissions. All I have left at this point is to add support for command line configuration options, add comments, tidy everything up, get it to conform to the "man style" guidelines and test it against a remote repository. ___ 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 Sun, Jan 27, 2013 at 09:27:11PM -0600, John Mehr wrote: > All I have left at this point is to add support for > command line configuration options, add comments, tidy > everything up, get it to conform to the "man style" > guidelines and test it against a remote repository. > If you have code available to the public, I am sure many would be happy to test. If you do not have a public repository available, email me off-list, and I will help. Glen pgp53LZmAftyT.pgp Description: PGP signature
Re: svn - but smaller?
On 2013-Jan-27 21:54:44 -0600, Stephen Montgomery-Smith wrote: >On 01/27/2013 09:24 PM, Isaac (.ike) Levy wrote: >> Thank you for adding the ctm bits in the page, I'm deeply intrigued by >> possibly solving this problem with bits *already* in base?!! >Suppose you want to keep up with 9.x-stable. Then you look at the ftp >site ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-9/, look at the latest >xEmpty file, and fetch it. Then create an empty directory /usr/src, and >then do >cd /usr/src && ctm the-xEmpty-file-you-downloaded. >No need to decompress the file first. >Then fetch from the same web site all the files whose number is greater >than the xEmpty file you downloaded and do >cd /usr/src && ctm the-rest-of-the-files* I tracked the CVS repo for at least 10 years using a perl script I wrote. It checks the local .ctm_status and then fetches successive deltas until the fetch fails. A second script ran ctm on the downloaded deltas to update my local CVS repo. If there's sufficient interest, I could make the scripts available. At $ex-work, I had an email subscription and had a script setup to run the emails through gpg and feed them into gpg. Unfortunately, I can't distribute that script. >Now, if you want something not offered by ctm (e.g. 8.2-release), then >you need to use svn. Or freebsd-update. The biggest downside of CTM ishat you can't pick arbitrary deltas - you can only fetch the head of pre-configured branches. The only way to get an older tree is to not apply deltas (ZFS snapshots are the best work-around here). -- Peter Jeremy pgpbZzqAVCO6F.pgp Description: PGP signature
Re: mergemaster -p / installkernel problem
On 01/28/2013 02:10, Kevin Oberman wrote: You don't by any chance have a mergemaster.rc in /etc or .mergemasterrc in $HOME? Duh... I'll go stand in the corner for the next 37 years. Cheers Michiel ___ 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"
