mat at samba.org
Sun Oct 10 11:56:52 MDT 2010
On 10/10/2010 16:29, Michael Wood wrote:
> On 9 October 2010 08:48, Michael Wood<esiotrot at gmail.com> wrote:
>> On 8 October 2010 23:30, Matthieu Patou<mat at samba.org> wrote:
>>> On 08/10/2010 10:34, Michael Wood wrote:
>>>> I suspect Rohit used the "rsync" instructions on the Samba4 HOWTO.
>>>> When I tried that a few days ago it was broken. ./autogen.sh said it
>>>> was setting up for waf, but ./configure.developer actually ran the
>>>> autoconf version of configure.
>>> I really double checked and downloading s4 through rsync lead to a
>>> autogen.sh pointing to autogen-waf.sh.
>>> And the build is ok.
>> Yes, my point is that you did not follow the rsync instructions on the
>> HOWTO which specified to use samba.org::ftp/unpacked/samba_4_0_test/
>> and to run ./autogen.sh (not ./autogen-waf.sh.) You rsynced from
>> samba.org::ftp/unpacked/samba_4_0_waf/, so it's not surprising you got
>> different results :)
>>> I suspect that's because the previous checkout was done with the old build
>>> mode and the link was not updated.
>> Yes, I think it's something like that. Strangely, though,
>> ./autogen.sh *did* say that it was setting up for a waf build, but
>> running ./configure.developer still ran the autoconf version of
>> configure. I did not spend time on trying to figure out why that was.
> I've just tested the resurrected rsync instructions on the Samba4
> HOWTO page and updated them slightly as a result.
> Someone appears to have fixed samba.org::ftp/unpacked/samba_4_0_test/
That's tridge on friday.
> so that it works with ./autogen.sh and doesn't need ./autogen-waf.sh.
> I've left the ./autogen-waf.sh in the HOWTO, though, since it still
> works, of course, and does no harm.
In fact I decided to point to the waf autogen for people who have a
"broken" copy that still point to the "autoconf" build style
> The unpacked tree now appears to include all the git objects, instead
> of pointing to them using .git/objects/info/alternates, so I've
> removed the step that deletes that file and also the comment about
> "git fetch" downloading 160MB of git history. This is what "git
> fetch" gave me:
> $ git fetch
> remote: Counting objects: 940, done.
> remote: Compressing objects: 100% (362/362), done.
> remote: Total 487 (delta 373), reused 164 (delta 124)
> Receiving objects: 100% (487/487), 82.09 KiB | 4 KiB/s, done.
> Resolving deltas: 100% (373/373), completed with 154 local objects.
> From git://git.samba.org/samba
> 77622ac..f827fcd master -> origin/master
> ead6726..e18ef6c v3-4-test -> origin/v3-4-test
> 2ee3b08..01a15b1 v3-5-stable -> origin/v3-5-stable
> ca69f96..34aa6f4 v3-5-test -> origin/v3-5-test
> a72eba0..e8f3281 v3-6-test -> origin/v3-6-test
> * [new tag] release-3-5-6 -> release-3-5-6
> Also, there was a lock file left at .git/index.lock when I did the
> rsync (maybe the tree was being updated on the server?) so I had to
> remove it before "git pull" worked.
> Before running git fetch, git fsck --full ran without complaint.
Thanks for the investigation, did you update the howto ?
Samba Team http://samba.org
More information about the samba-technical