Hello Martin,

Are you saying that Bacula is wrong assuming that echo works like defined in the Unix/Linux man pages?
If that is the case, what are you suggesting?  To men MAKEFILEECHO doesn't mean much.

Best regards,
Kern

On 04/03/2014 03:51 PM, Martin Simmons wrote:
> This problem with ECHO affects the main bacula makefiles as well.  The
> definition of ECHO comes from libtool.m4, but it will not work in makefiles
> because of the backslash.
>
> I think the makefiles should stop using ECHO, or at least Make.common.in
> should do something like:
>
> ECHO = @MAKEFILEECHO@
>
> where configure can define MAKEFILEECHO correctly.
>
> __Martin
>
>
>
>>>>>> On Wed, 2 Apr 2014 19:19:16 -0400, Dan Langille said:
>>
>> I had local changes for this echo problem.  I just did a 'git stash' on my checkout so I could try 7.0.2
>>
>> It fails.
>>
>> I notice that the 5.x code using:
>>
>> @$(ECHO) "# DO NOT DELETE: nice dependency list follows" >> Makefile
>>
>> It works.
>>
>> This makes me think: has configure changed?
>>
>> So I went looking at another regression testing jail.  I found this:
>>
>> $ diff configure configure.orig
>> 6056c6056
>> <   ECHO='echo'
>> ---
>>>   ECHO='printf %s\n'
>>
>> I have a local patch.  That's why it works here.  I'm sure if we search the archives, I reported this same problem back when I first set up my first round of regression testing.
>>
>> Look what I have in my regression test script:
>>
>> # patch the printf / echo problem
>> cd bacula
>> patch -N < ${CONFIG_DIR_SRC}/patch-bacula-printf
>> cd - 
>>
>> Here is the patch itself:
>>
>> $ cat patch-bacula-printf
>> --- bacula/configure.orig
>> +++ bacula/configure
>> @@ -6045,7 +6045,7 @@ if test "X`( print -r -- -n ) 2>/dev/null`" = X-n && \
>>     test "X`print -r -- $ECHO 2>/dev/null`" = "X$ECHO"; then
>>    ECHO='print -r --'
>>  elif test "X`printf %s $ECHO 2>/dev/null`" = "X$ECHO"; then
>> -  ECHO='printf %s\n'
>> +  ECHO='echo'
>>  else
>>    # Use this function as a fallback that always works.
>>    func_fallback_echo ()
>>
>>
>> And this is the patch I just created for bacula7:
>>
>> $ cat patch-bacula7-printf
>> --- configure~    2014-04-02 21:55:27.000000000 +0000
>> +++ configure    2014-04-02 23:12:21.022646230 +0000
>> @@ -5977,7 +5977,7 @@
>>     test "X`print -r -- $ECHO 2>/dev/null`" = "X$ECHO"; then
>>    ECHO='print -r --'
>>  elif test "X`printf %s $ECHO 2>/dev/null`" = "X$ECHO"; then
>> -  ECHO='printf %s\n'
>> +  ECHO='echo'
>>  else
>>    # Use this function as a fallback that always works.
>>    func_fallback_echo ()
>>
>>
>> That local patch allows the regression testing to proceed unhindered on FreeBSD (9.2 in this particular case).  It's running now.
>>
>> On Apr 1, 2014, at 9:27 PM, Dan Langille <d...@langille.org> wrote:
>>
>>> In addition to my previous post, this just in: http://regress.bacula.org/viewTest.php?onlyfailed&buildid=24144
>>>
>>> Only disk:tls-test failed this time.
>>>
>>> On Mar 31, 2014, at 11:16 AM, Kern Sibbald <k...@sibbald.com> wrote:
>>>
>>>> Hello Dan,
>>>>
>>>> Can you try applying the attached patch to release 7.0.0 and see if it
>>>> fixes the problem with the tls-test?  I am not 100% convinced that it
>>>> will, but at least the code is much tighter now and will not store any
>>>> address if it is not either IPv4 or IPv6 and if IPv6 is not configured
>>>> and it resolves an IPv6 address, it will not be used.
>>>>
>>>> Best regards,
>>>> Kern
>>>>
>>>> On 03/31/2014 03:44 PM, Dan Langille wrote:
>>>>> On 2014-03-31 09:01 AM, Dan Langille wrote:
>>>>>> On 2014-03-31 07:36 AM, Kern Sibbald wrote:

$ grep 28 /etc/services  | head
gss-xlicen    128/tcp       #GSS X License Verification
gss-xlicen    128/udp       #GSS X License Verification
http-mgmt    280/tcp
http-mgmt    280/udp
personal-link    281/tcp
personal-link    281/udp
cableport-ax    282/tcp       #cable port a/x
cableport-ax    282/udp       #cable port a/x
rescap        283/tcp
rescap        283/udp
>>>>> Ouch.  That's port numbers, not protocols.
>>>>>
>>>>> The protocols are defined in /usr/include/sys/socket.h and the URL I
>>>>> posted below should help.
>>>>>
This test runs perfectly here, and
we have made some significant networking changes. This protocol should
be the sa_family member and should normally be AF_INET for IPv4.
However, now Bacula handles IPv6 much better than previous versions,
and apparently there is a problem or difference with the FreeBSD IP
definitions. For IPv6 this value should be AF_INET6. Those are the
only two values that Bacula understands.
FYI, there is no IPv6 on the regression testing machine in question.

Note for Linux: AF_INET == 2 AF_INET6 = 10, so 28 is something
different and doesn't even exist on Linux.
Guess what, you're right.  See:

https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html

#define    AF_INET6 28


Best regards,
Kern
>>>>>>>
On 03/31/2014 04:04 AM, Dan Langille wrote:
>>>>>>>> On Mar 30, 2014, at 4:44 PM, Dan Langille <d...@langille.org> wrote:
>>>>>>>>
>>>>>>>>> I tried some regression tests for Bacula 7 tonight. I found what I
think may be a configure issue.
>>>>>>>>
>>>>>>>> The test finished, two errors:
>>>>>>>>
>>>>>>>> http://regress.bacula.org/buildSummary.php?buildid=24125 [1]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
------------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Bacula-devel mailing list
>>>>>>>> Bacula-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/bacula-devel [2]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Links:
>>>>>> ------
>>>>>> [1] http://regress.bacula.org/buildSummary.php?buildid=24125
>>>>>> [2] https://lists.sourceforge.net/lists/listinfo/bacula-devel
>>>>>> [3] http://www.enigmail.net/
>>>>
>>>> <ipv6_check.patch>------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Bacula-devel mailing list
>>>> Bacula-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bacula-devel
>>>
>>> --
>>> Dan Langille - http://langille.org
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bacula-devel mailing list
>>> Bacula-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bacula-devel
>>
>> --
>> Dan Langille - http://langille.org
>>
>>
>



------------------------------------------------------------------------------
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to