curl-loader-devel — curl-loader usage and development issues

req to suggest changes to fix failures

[Shalini Pv <pvs...@gm...>]

sir
I am working with mininet network simulator,
I have a nodejs webserver running on one of the hosts.
from another host when I run curl-loader
#  curl-loader -f ./conf-examples/bax.conf -v -u

I am getting this output at command line
" parse_config_file -loaded 1 batches
The configuration has been post-validated successfully.
add_secondary_ip_addrs - setting secondary IP successfully added.

Exited. For details look in the files:
bax.log
bax.txt
bax.ctx
bax.ops"

In bax.ops file I have success 0 0 Failed 56 56 Timed out 0 0
In bax.txt I have H/F 50,0,0,0,0,0,0,0
H/F/S 50,0,0,0,0,0,0,0

I am getting success as 0 and failed as number of client requests
Kindly suggest how to fix this
Thanks and Regards
Shalini

Can raw-data be POST with curl-loader?

[Hiroyuki M. <hmi...@gm...>]

Hello

Can raw-data be POST with curl-loader?

I looked for the code but couldn't find it.

When writing in curl, I want to POST the following contents.

```
curl --location --request POST '{URL}' --header '{HEADER}' --header 
'{HEADER}' --header '{HEADER}' --data-raw 'aaa'
```

Timestamp to curl-loader?

[MIGUEL A. H. G. <mig...@al...>]

Hi curl-loader experts!
It's possible to add timestamp to .log?
In my case, I ran the FTP test, but I can't add time to this .log

Regards,

distributed load test

[Joel M. <joe...@gm...>]

Hello, Is it possible to lunch a distributed test with curl-loader from
differents real PCs (which have IP's on different range... collecting the
information log on a master client)? this is because I'd like to gain
bandwidth. How to real test a server... if I only lunch it from a limited
internet bandwidth... been this the bottleneck of my test? I'm far away to
stress my server... cause, given it a second in time I'd only get as much
responses as my internet conection is able to recive.
Consider having a cluster of potent servers... with bandwidth to response
thousands of request.
Thanks in advance for your replay!

Allow double quotes on config strings

[Patricio M D. J. <pat...@th...>]

Hi there (is still anyone there or should I look for a fork?)

Last night during a test I found out that an ISS7.5 didn't like me
replacing the POST data double quotes by single quotes, so I made a little
little change for allowing double quote text between double quotes.

Please accept the patch to the mainline version.


--- parse_conf.c    2012-01-02 15:17:15.000000000 +0100
+++ parse_conf.c.patch    2016-02-09 08:51:15.105650965 +0100
@@ -584,8 +584,11 @@

         if (*(value_start + 1))
         {
-            if ((quotes_closing = strchr (value_start + 1, '"')))
+            quotes_closing = strchr (value_start + 1, '"');
+            while (quotes_closing ){
                 value_end = quotes_closing + 1;
+                quotes_closing = strchr( quotes_closing +1,'"');
+            }
         }
         else
         {




Patricio M Dorantes Jamarne

Re: how can i use random mac addresses for curl-loader tests? Current test all use a single MAC address and I need to simulate more.

[Vincent Li <vin...@gm...>]

it turned out pretty easy to use mTCP + DPDK to achieve to
randomization of source MAC, then you can send http request with
random source MAC.

patch mTCP/src/eth_out.c as below:

diff --git a/mtcp/src/eth_out.c b/mtcp/src/eth_out.c
index 7fd1097..b064e9c 100644
--- a/mtcp/src/eth_out.c
+++ b/mtcp/src/eth_out.c
@@ -181,6 +181,44 @@ FlushSendChunkBuf(mtcp_manager_t mtcp, int nif)
 }
 #endif /* E_PSIO */
 /*----------------------------------------------------------------------------*/
+
+/**
+ * Get a pseudo-random value.
+ *
+ * This function generates pseudo-random numbers using the linear
+ * congruential algorithm and 48-bit integer arithmetic, called twice
+ * to generate a 64-bit value.
+ *
+ * @return
+ *   A pseudo-random value between 0 and (1<<64)-1.
+ */
+static inline uint64_t
+rte_rand(void)
+{
+        uint64_t val;
+        val = lrand48();
+        val <<= 32;
+        val += lrand48();
+        return val;
+}
+
+
+static void
+generate_random_mac_addr(struct ethhdr *mac_addr)
+{
+        uint64_t random;
+
+        /* Set Organizationally Unique Identifier (OUI) prefix. */
+        mac_addr->h_source[0] = 0xa0;
+        mac_addr->h_source[1] = 0x36;
+        mac_addr->h_source[2] = 0x9f;
+        /* Force indication of locally assigned MAC address. */
+//        mac_addr->h_source[0] |= ETHER_LOCAL_ADMIN_ADDR;
+        /* Generate the last 3 bytes of the MAC address with a random
number. */
+        random = rte_rand();
+        memcpy(&mac_addr->h_source[3], &random, 3);
+}
+
 uint8_t *
 EthernetOutput(struct mtcp_manager *mtcp, uint16_t h_proto,
                int nif, unsigned char* dst_haddr, uint16_t iplen)
@@ -213,8 +251,9 @@ EthernetOutput(struct mtcp_manager *mtcp, uint16_t h_proto,
 #endif

        ethh = (struct ethhdr *)buf;
+       generate_random_mac_addr(ethh);
        for (i = 0; i < ETH_ALEN; i++) {
-               ethh->h_source[i] = CONFIG.eths[nif].haddr[i];
+               //ethh->h_source[i] = CONFIG.eths[nif].haddr[i];
                ethh->h_dest[i] = dst_haddr[i];
        }
        ethh->h_proto = htons(h_proto);

On Fri, Nov 13, 2015 at 4:09 PM, Vincent Li <vin...@gm...> wrote:
> Hi Malick,
>
> I am glad for you to abandon Avalanche :)
>
> the your request is unusual. I think the closest thing to achieve what
> you need is DPDK http://www.dpdk.org/   and  MoonGen
> https://github.com/emmericp/MoonGen . it appears you are doing
> http/https type of test. you could randomize MAC address and ip
> address in MoonGen, then "hardcode " http payload in tcp data section.
>
> i worked on a project to   use DPDK and MoonGen to generate ~7 million
> packet per second DNS  request to test most powerful F5 hardware
> platform, this is enterprise level of load testing using open source
> technology
>
> don't get me wrong, I used curl-loader and love it :) but for million
> connections, packet per second level of test, the bottleneck is in the
> Linux kernel tcp/ip stack that curl-loader runs on.
>
> see
>
> The Secret to 10 Million Concurrent Connections -The Kernel is the
> Problem, Not the Solution
>
>  http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
>
>
> I bought a used $300 dell poweredge R210 and i can achieve 2.5 million
> http concurrent connections.
>
> http://ickernel.blogspot.com/2015/10/25-million-tcphttp-connection-with-mtcp.html
>
>
> Vincent
>
>
> On Thu, Mar 19, 2015 at 4:20 AM,  <Mal...@sw...> wrote:
>> Hi curl-loader devs,
>> First of all, thank you for your work in creating a Smartbits Avalanche
>> “replacement” tool. I have found it very helpful and much more affordable
>> than the Smartbits.
>> I am currently trying to run some load tests with your tool (to replace our
>> aging Avalanche), however I am missing one element to make my tests a
>> success. The gateway that I am testing requires that each client has a
>> distinct MAC address, and I cannot find any way of adding this to
>> curl-loader. Any ideas or pointers that you have will be much appreciated. I
>> have looked at multiple load test tools and curl-loader is the best in the
>> FOSS space for this particular task that I have, however, I need the MAC
>> addresses to be different per request. I would really appreciate if you can
>> confirm whether this is possible, how much coding work would be needed, or
>> If anyone else has had a similar requirement. Thanks in advance.
>> Malick SY
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for
>> all
>> things parallel software development, from weekly thought leadership blogs
>> to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> curl-loader-devel mailing list
>> cur...@li...
>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>>

Re: how can i use random mac addresses for curl-loader tests? Current test all use a single MAC address and I need to simulate more.

[Vincent Li <vin...@gm...>]

Hi Malick,

I am glad for you to abandon Avalanche :)

the your request is unusual. I think the closest thing to achieve what
you need is DPDK http://www.dpdk.org/   and  MoonGen
https://github.com/emmericp/MoonGen . it appears you are doing
http/https type of test. you could randomize MAC address and ip
address in MoonGen, then "hardcode " http payload in tcp data section.

i worked on a project to   use DPDK and MoonGen to generate ~7 million
packet per second DNS  request to test most powerful F5 hardware
platform, this is enterprise level of load testing using open source
technology

don't get me wrong, I used curl-loader and love it :) but for million
connections, packet per second level of test, the bottleneck is in the
Linux kernel tcp/ip stack that curl-loader runs on.

see

The Secret to 10 Million Concurrent Connections -The Kernel is the
Problem, Not the Solution

 http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html


I bought a used $300 dell poweredge R210 and i can achieve 2.5 million
http concurrent connections.

http://ickernel.blogspot.com/2015/10/25-million-tcphttp-connection-with-mtcp.html


Vincent


On Thu, Mar 19, 2015 at 4:20 AM,  <Mal...@sw...> wrote:
> Hi curl-loader devs,
> First of all, thank you for your work in creating a Smartbits Avalanche
> “replacement” tool. I have found it very helpful and much more affordable
> than the Smartbits.
> I am currently trying to run some load tests with your tool (to replace our
> aging Avalanche), however I am missing one element to make my tests a
> success. The gateway that I am testing requires that each client has a
> distinct MAC address, and I cannot find any way of adding this to
> curl-loader. Any ideas or pointers that you have will be much appreciated. I
> have looked at multiple load test tools and curl-loader is the best in the
> FOSS space for this particular task that I have, however, I need the MAC
> addresses to be different per request. I would really appreciate if you can
> confirm whether this is possible, how much coding work would be needed, or
> If anyone else has had a similar requirement. Thanks in advance.
> Malick SY
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> curl-loader-devel mailing list
> cur...@li...
> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>

recursive download or parallel URLs

[Pieter L. <pie...@ne...>]

Hi curl-loader enthusiasts,

When a browser fetches a URL, it will analyze the content of the returned page and next fetch all embedded objects in parallel.
Can curl-loader simulate this behavior?

Since I want to use curl-loader in a test environment, I know the page to fetch upfront. That means I can construct a curl-loader config that contains the URLs of all objects, but still I would like to fetch all objects in parallel and not one after the other.
Can curl-loader do this?


Pieter Lauwers 
Network Engineer 
E-mail: pie...@ne... 
Tel: +32 3 610 8415 (direct) 

Newtec 
Laarstraat 5, B-9100 Sint-Niklaas, Belgium 
Tel: +32 3 780 65 00 (switchboard) / Fax: +32 3 780 65 49 

Newtec - *Shaping the Future of Satellite Communications*



Secure your future - Meet Newtec Dialog® <http://www.newtec.eu/product/newtec-dialog> - the platform that embraces change. With Mx-DMA™ <http://www.newtec.eu/technology/mx-dma> - Discover the WTA ‘Teleport Technology of the Year’ award winner 2015!

***mail confidentiality footer ***
 This message and any attachments thereto are confidential. They may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore is in no way liable for any errors or omissions in the content of this message, which may arise as a result of e-mail transmission. If verification is required, please request a hard copy.

Re: Configuration file settings for using OAuth2

[Tristan W. <mir...@gm...>]

Hi again,

Hopefully, this posts onto the same message. I figured out how to do it and
had to modify how I'm passing the settings:

########### GENERAL SECTION ################################

BATCH_NAME=oidc

CLIENTS_NUM_MAX=2800

CLIENTS_NUM_START=500

CLIENTS_RAMPUP_INC=5

INTERFACE=eth0

NETMASK=255.255.255.0

IP_ADDR_MIN=IP#

IP_ADDR_MAX=IP#

IP_SHARED_NUM=1

CYCLES_NUM=-1

URLS_NUM=1


########### URL SECTION ####################################

URL=https://IP#:9443/oauth2/token

URL_SHORT_NAME="oidc"

REQUEST_TYPE=POST

HEADER="Content-Type:application/x-www-form-urlencoded"

FORM_USAGE_TYPE= AS_IS

FORM_STRING =
grant_type=password&username=user&password=passwordhere&client_id=CLIENTID&client_secret=SECRET

TIMER_URL_COMPLETION=0

TIMER_AFTER_URL_SLEEP=0


This does end up working. This is based of an alternatively formatted
command in curl:

curl -k -d "grant_type=password&username=user&password=passwordhere
&client_id=CLIENTID&client_secret=SECRET" https://IP#:9443/oauth2/token &&
echo

I'd still be interested in how to get the other type of curl command to
work, but I now have a working setup at least.

Thanks again!

Tristan J. Wallace

On Wed, Oct 28, 2015 at 11:01 AM, Tristan Wallace <mir...@gm...>
wrote:

> Hi,
>
> I am trying to configure the following curl request to get it to work in
> curl-loader:
>
> curl --user CLIENTID:SECRET -k -d
> "grant_type=password&username=user&password=passwordhere"
> https://IP#:9443/oauth2/token && echo
>
> As I understand it from reading prior discussions on the list, the -k
> option is already sent. The --user portion is likely via
> WEB_AUTH_CREDENTIALS in the top section, and it's possible that the -d
> portion that passes the content type for application/x-www-form-urlencoded
> (so the -H option isn't needed for that data type) would be
> MULTIPART_FORM_DATA for the POST section.
>
> (Reference the man page for curl for -d or -data to show that is the
> content type:
>
>        -d, --data <data>
>
>               (HTTP) Sends the specified data in a POST request to the
> HTTP server, in the same way that a browser
>
>               does when a user has filled in an HTML form and presses the
> submit button. This will cause  curl  to
>
>               pass  the  data  to the server using the content-type
> application/x-www-form-urlencoded.  Compare to
>
>               -F, --form.
>
> *****
>
> As such, I have the following, but it isn't working and returns a 405
> error:
>
> ERCL 405 HTTP/1.1 405 Method Not Allowed
>
> Any help on getting the right configuration settings would be appreciated.
> I'm pasting my settings below. The CLIENTID, SECRET, user and password are
> all redacted in the example
>
> ########### GENERAL SECTION ################################
>
> BATCH_NAME=oidc
>
> CLIENTS_NUM_MAX=2800
>
> CLIENTS_NUM_START=500
>
> CLIENTS_RAMPUP_INC=5
>
> INTERFACE=eth0
>
> NETMASK=255.255.255.0
>
> IP_ADDR_MIN=IP#
>
> IP_ADDR_MAX=IP#
>
> IP_SHARED_NUM=1
>
> CYCLES_NUM=-1
>
> URLS_NUM=2
>
>
> ########### URL SECTION ####################################
>
> URL=https://IP#:9443/oauth2/token
>
> URL_SHORT_NAME="oidc"
>
> REQUEST_TYPE=GET
>
> WEB_AUTH_CREDENTIALS="CLIENTID:SECRET"
>
> TIMER_URL_COMPLETION=0
>
> TIMER_AFTER_URL_SLEEP=0
>
>
> # POST-part
>
> #
>
> URL=""
>
> URL_SHORT_NAME="Login-POST"
>
> URL_USE_CURRENT=1
>
> REQUEST_TYPE=POST
>
> MULTIPART_FORM_DATA="grant_type=password"
>
> MULTIPART_FORM_DATA="username=user"
>
> MULTIPART_FORM_DATA="password=passwordhere"
>
> TIMER_URL_COMPLETION=0
>
> TIMER_AFTER_URL_SLEEP=0
>
>
> Thank you!
>
> Tristan J. Wallace
>

Configuration file settings for using OAuth2

[Tristan W. <mir...@gm...>]

Hi,

I am trying to configure the following curl request to get it to work in
curl-loader:

curl --user CLIENTID:SECRET -k -d
"grant_type=password&username=user&password=passwordhere"
https://IP#:9443/oauth2/token && echo

As I understand it from reading prior discussions on the list, the -k
option is already sent. The --user portion is likely via
WEB_AUTH_CREDENTIALS in the top section, and it's possible that the -d
portion that passes the content type for application/x-www-form-urlencoded
(so the -H option isn't needed for that data type) would be
MULTIPART_FORM_DATA for the POST section.

(Reference the man page for curl for -d or -data to show that is the
content type:

       -d, --data <data>

              (HTTP) Sends the specified data in a POST request to the HTTP
server, in the same way that a browser

              does when a user has filled in an HTML form and presses the
submit button. This will cause  curl  to

              pass  the  data  to the server using the content-type
application/x-www-form-urlencoded.  Compare to

              -F, --form.

*****

As such, I have the following, but it isn't working and returns a 405 error:

ERCL 405 HTTP/1.1 405 Method Not Allowed

Any help on getting the right configuration settings would be appreciated.
I'm pasting my settings below. The CLIENTID, SECRET, user and password are
all redacted in the example

########### GENERAL SECTION ################################

BATCH_NAME=oidc

CLIENTS_NUM_MAX=2800

CLIENTS_NUM_START=500

CLIENTS_RAMPUP_INC=5

INTERFACE=eth0

NETMASK=255.255.255.0

IP_ADDR_MIN=IP#

IP_ADDR_MAX=IP#

IP_SHARED_NUM=1

CYCLES_NUM=-1

URLS_NUM=2


########### URL SECTION ####################################

URL=https://IP#:9443/oauth2/token

URL_SHORT_NAME="oidc"

REQUEST_TYPE=GET

WEB_AUTH_CREDENTIALS="CLIENTID:SECRET"

TIMER_URL_COMPLETION=0

TIMER_AFTER_URL_SLEEP=0


# POST-part

#

URL=""

URL_SHORT_NAME="Login-POST"

URL_USE_CURRENT=1

REQUEST_TYPE=POST

MULTIPART_FORM_DATA="grant_type=password"

MULTIPART_FORM_DATA="username=user"

MULTIPART_FORM_DATA="password=passwordhere"

TIMER_URL_COMPLETION=0

TIMER_AFTER_URL_SLEEP=0


Thank you!

Tristan J. Wallace

Re: Removing bundled libs in curl-loader

[Pavel A. <fo...@hu...>]

Hi Robert.

If in some days you will change that you may ping me. But please, off
list (or just CC).
Thank you.

On 22.09.2015 14:25, Robert Iakobashvili wrote:
> Yes, you are right.
>
> The case for CURLINFO_ERROR: to be removed.
>
> Unless the old API of libcurl, libevent and cares is broken,
> this is the only source change required.
>
> Thanks,
> Regards,
> Robert
>
>
> On Tue, Sep 22, 2015 at 1:09 PM, Pavel Alexeev <fo...@hu...> wrote:
>> Hi Robert.
>>
>> Honestly I do not understand you. If there no sources changed, how it
>> became build able without patches?
>> I have tried and got same error as was report initially:
>>
>> $ LANG=C make
>> gcc -W -Wall -Wpointer-arith -pipe -DCURL_LOADER_FD_SETSIZE=20000
>> -D_FILE_OFFSET_BITS=64  -O3 -ffast-math -finline-functions
>> -funroll-all-loops -finline-limit=1000 -mmmx -msse
>> -foptimize-sibling-calls -g -I. -I./inc -I/usr//include -c -o
>> obj/loader.o loader.c
>> loader.c: In function 'client_tracing_function':
>> loader.c:1262:10: error: 'CURLINFO_ERROR' undeclared (first use in this
>> function)
>>      case CURLINFO_ERROR:
>>           ^
>> loader.c:1262:10: note: each undeclared identifier is reported only once
>> for each function it appears in
>> Makefile:109: recipe for target 'obj/loader.o' failed
>> make: *** [obj/loader.o] Error 1
>>
>> CURLINFO_ERROR indeed introduced in your curl-trace-info-error.patch
>> patch, and that symbol does not found in system curl present in Fedora
>> for example.
>>
>> On 21.09.2015 19:59, Robert Iakobashvili wrote:
>>> Hi Pavel,
>>> I've cutted libcurl, libevent and libcares custom building:
>>> see the Makefile attached (I've not tried it, sorry)
>>> to be used instead of the one in curl-loader-0.56.
>>>
>>> My guess, you will create a patch.
>>>
>>> Thank you.
>>> Regards,
>>> Robert
>>>
>>>
>>> On Mon, Sep 21, 2015 at 7:38 PM, Robert Iakobashvili
>>> <cor...@gm...> wrote:
>>>> Hi Pavel,
>>>> From curl-loader-0.56
>>>>
>>>> Just patch the Makefile file
>>>> as described below not to build custom libcurl and libevent
>>>> and instead push there standard libraries from your distribution.
>>>>
>>>>
>>>> Regards,
>>>> Robert
>>>>
>>>>
>>>> On Mon, Sep 21, 2015 at 6:56 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>> From what tarball I could build that?
>>>>>
>>>>> On 20.09.2015 23:17, Robert Iakobashvili wrote:
>>>>>> Hi Pavel,
>>>>>>
>>>>>> In curl-loader Makefile:
>>>>>>
>>>>>> 1. comment our targets libcurl and libevent from build;
>>>>>>
>>>>>> 2. provide instead standard paths/locations of these libraries
>>>>>>     that in any case are specific for your distribution.
>>>>>>
>>>>>> Kind regards,
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> On Sun, Sep 20, 2015 at 10:47 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>> Thank you very much!
>>>>>>>
>>>>>>> But version still 0.56 for download. Could you please release new version?
>>>>>>>
>>>>>>> Or it intended to be built from source system?
>>>>>>>
>>>>>>> Should I use some switches to do not use patches, or just delete them is
>>>>>>> enough?
>>>>>>>
>>>>>>> On 04.08.2015 16:33, Robert Iakobashvili wrote:
>>>>>>>> Dear Pavel,
>>>>>>>>
>>>>>>>> This is to confirm that curl-loader will work properly without patches
>>>>>>>> for libcurl and libevent.
>>>>>>>>
>>>>>>>> The patches have their own advantages but not so important.
>>>>>>>>
>>>>>>>> I do not have any clues about fsf addresses, though.
>>>>>>>> Regards,
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>>>> Hello Robert.
>>>>>>>>> Firstly I glad receive response from you.  Thanks. I also had write
>>>>>>>>> about incorrect fsf address in files headers which leaved without answer
>>>>>>>>> (it is not stop issue, but I should be inform you [1]), and also there
>>>>>>>>> long time no new curl-loader releases... So I became fear project abandoned.
>>>>>>>>>
>>>>>>>>> What concerned libevent patch, had it been ever proposed to include for
>>>>>>>>> upstream libevent project? Is it possible to do?
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>>>>>>>>
>>>>>>>>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>>>>>>>>> Dear Pavel,
>>>>>>>>>> First, we like truly community distros like
>>>>>>>>>> Debian and Fedora.
>>>>>>>>>>
>>>>>>>>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>>>>>>>>> and all were integrated to libcurl besides this
>>>>>>>>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>>>>>>>>
>>>>>>>>>> I will look next week into this matter and what could be done,
>>>>>>>>>> but we have a good command of libcurl and error codes
>>>>>>>>>> were not a substituted from my mems.
>>>>>>>>>>
>>>>>>>>>> There's a one more essential patch and it's for libevent library.
>>>>>>>>>> This patch increases in some define maximum number of allowed
>>>>>>>>>> file descriptors to enable much higher productivity for curl-loader.
>>>>>>>>>>
>>>>>>>>>> Without this libevent patch curl-loader will function with a limit
>>>>>>>>>> of the number of connection specified in libevent as low as only 64K
>>>>>>>>>> as I remember, but it will function properly within this limitation.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Robert
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>>>>>>>>> distribution.
>>>>>>>>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>>>>>>>>> packages directory.
>>>>>>>>>>>
>>>>>>>>>>> That is strongly prohibited by our rules:
>>>>>>>>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>>>>>>>>
>>>>>>>>>>> I have tried link curl-loader with system libraries, and observe you
>>>>>>>>>>> patch that software (patches directory).
>>>>>>>>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>>>>>>>>> you prefer patch that library instead of use wide range of predefined
>>>>>>>>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>>>>>>>>
>>>>>>>>>>> So, in that point it is stop issue.
>>>>>>>>>>> Do you willing working on that issue?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>>>>>>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> curl-loader-devel mailing list
>>>>>>>>>>> cur...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel

Re: Removing bundled libs in curl-loader

[Robert I. <cor...@gm...>]

Yes, you are right.

The case for CURLINFO_ERROR: to be removed.

Unless the old API of libcurl, libevent and cares is broken,
this is the only source change required.

Thanks,
Regards,
Robert


On Tue, Sep 22, 2015 at 1:09 PM, Pavel Alexeev <fo...@hu...> wrote:
> Hi Robert.
>
> Honestly I do not understand you. If there no sources changed, how it
> became build able without patches?
> I have tried and got same error as was report initially:
>
> $ LANG=C make
> gcc -W -Wall -Wpointer-arith -pipe -DCURL_LOADER_FD_SETSIZE=20000
> -D_FILE_OFFSET_BITS=64  -O3 -ffast-math -finline-functions
> -funroll-all-loops -finline-limit=1000 -mmmx -msse
> -foptimize-sibling-calls -g -I. -I./inc -I/usr//include -c -o
> obj/loader.o loader.c
> loader.c: In function 'client_tracing_function':
> loader.c:1262:10: error: 'CURLINFO_ERROR' undeclared (first use in this
> function)
>      case CURLINFO_ERROR:
>           ^
> loader.c:1262:10: note: each undeclared identifier is reported only once
> for each function it appears in
> Makefile:109: recipe for target 'obj/loader.o' failed
> make: *** [obj/loader.o] Error 1
>
> CURLINFO_ERROR indeed introduced in your curl-trace-info-error.patch
> patch, and that symbol does not found in system curl present in Fedora
> for example.
>
> On 21.09.2015 19:59, Robert Iakobashvili wrote:
>> Hi Pavel,
>> I've cutted libcurl, libevent and libcares custom building:
>> see the Makefile attached (I've not tried it, sorry)
>> to be used instead of the one in curl-loader-0.56.
>>
>> My guess, you will create a patch.
>>
>> Thank you.
>> Regards,
>> Robert
>>
>>
>> On Mon, Sep 21, 2015 at 7:38 PM, Robert Iakobashvili
>> <cor...@gm...> wrote:
>>> Hi Pavel,
>>> From curl-loader-0.56
>>>
>>> Just patch the Makefile file
>>> as described below not to build custom libcurl and libevent
>>> and instead push there standard libraries from your distribution.
>>>
>>>
>>> Regards,
>>> Robert
>>>
>>>
>>> On Mon, Sep 21, 2015 at 6:56 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>> From what tarball I could build that?
>>>>
>>>> On 20.09.2015 23:17, Robert Iakobashvili wrote:
>>>>> Hi Pavel,
>>>>>
>>>>> In curl-loader Makefile:
>>>>>
>>>>> 1. comment our targets libcurl and libevent from build;
>>>>>
>>>>> 2. provide instead standard paths/locations of these libraries
>>>>>     that in any case are specific for your distribution.
>>>>>
>>>>> Kind regards,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Sun, Sep 20, 2015 at 10:47 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>> Thank you very much!
>>>>>>
>>>>>> But version still 0.56 for download. Could you please release new version?
>>>>>>
>>>>>> Or it intended to be built from source system?
>>>>>>
>>>>>> Should I use some switches to do not use patches, or just delete them is
>>>>>> enough?
>>>>>>
>>>>>> On 04.08.2015 16:33, Robert Iakobashvili wrote:
>>>>>>> Dear Pavel,
>>>>>>>
>>>>>>> This is to confirm that curl-loader will work properly without patches
>>>>>>> for libcurl and libevent.
>>>>>>>
>>>>>>> The patches have their own advantages but not so important.
>>>>>>>
>>>>>>> I do not have any clues about fsf addresses, though.
>>>>>>> Regards,
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>>> Hello Robert.
>>>>>>>> Firstly I glad receive response from you.  Thanks. I also had write
>>>>>>>> about incorrect fsf address in files headers which leaved without answer
>>>>>>>> (it is not stop issue, but I should be inform you [1]), and also there
>>>>>>>> long time no new curl-loader releases... So I became fear project abandoned.
>>>>>>>>
>>>>>>>> What concerned libevent patch, had it been ever proposed to include for
>>>>>>>> upstream libevent project? Is it possible to do?
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>>>>>>>
>>>>>>>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>>>>>>>> Dear Pavel,
>>>>>>>>> First, we like truly community distros like
>>>>>>>>> Debian and Fedora.
>>>>>>>>>
>>>>>>>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>>>>>>>> and all were integrated to libcurl besides this
>>>>>>>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>>>>>>>
>>>>>>>>> I will look next week into this matter and what could be done,
>>>>>>>>> but we have a good command of libcurl and error codes
>>>>>>>>> were not a substituted from my mems.
>>>>>>>>>
>>>>>>>>> There's a one more essential patch and it's for libevent library.
>>>>>>>>> This patch increases in some define maximum number of allowed
>>>>>>>>> file descriptors to enable much higher productivity for curl-loader.
>>>>>>>>>
>>>>>>>>> Without this libevent patch curl-loader will function with a limit
>>>>>>>>> of the number of connection specified in libevent as low as only 64K
>>>>>>>>> as I remember, but it will function properly within this limitation.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>>>>>>>> distribution.
>>>>>>>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>>>>>>>> packages directory.
>>>>>>>>>>
>>>>>>>>>> That is strongly prohibited by our rules:
>>>>>>>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>>>>>>>
>>>>>>>>>> I have tried link curl-loader with system libraries, and observe you
>>>>>>>>>> patch that software (patches directory).
>>>>>>>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>>>>>>>> you prefer patch that library instead of use wide range of predefined
>>>>>>>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>>>>>>>
>>>>>>>>>> So, in that point it is stop issue.
>>>>>>>>>> Do you willing working on that issue?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>>>>>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> curl-loader-devel mailing list
>>>>>>>>>> cur...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>

Re: Removing bundled libs in curl-loader

[Pavel A. <fo...@hu...>]

Hi Robert.

Honestly I do not understand you. If there no sources changed, how it
became build able without patches?
I have tried and got same error as was report initially:

$ LANG=C make
gcc -W -Wall -Wpointer-arith -pipe -DCURL_LOADER_FD_SETSIZE=20000
-D_FILE_OFFSET_BITS=64  -O3 -ffast-math -finline-functions
-funroll-all-loops -finline-limit=1000 -mmmx -msse
-foptimize-sibling-calls -g -I. -I./inc -I/usr//include -c -o
obj/loader.o loader.c
loader.c: In function 'client_tracing_function':
loader.c:1262:10: error: 'CURLINFO_ERROR' undeclared (first use in this
function)
     case CURLINFO_ERROR:
          ^
loader.c:1262:10: note: each undeclared identifier is reported only once
for each function it appears in
Makefile:109: recipe for target 'obj/loader.o' failed
make: *** [obj/loader.o] Error 1

CURLINFO_ERROR indeed introduced in your curl-trace-info-error.patch
patch, and that symbol does not found in system curl present in Fedora
for example.

On 21.09.2015 19:59, Robert Iakobashvili wrote:
> Hi Pavel,
> I've cutted libcurl, libevent and libcares custom building:
> see the Makefile attached (I've not tried it, sorry)
> to be used instead of the one in curl-loader-0.56.
>
> My guess, you will create a patch.
>
> Thank you.
> Regards,
> Robert
>
>
> On Mon, Sep 21, 2015 at 7:38 PM, Robert Iakobashvili
> <cor...@gm...> wrote:
>> Hi Pavel,
>> From curl-loader-0.56
>>
>> Just patch the Makefile file
>> as described below not to build custom libcurl and libevent
>> and instead push there standard libraries from your distribution.
>>
>>
>> Regards,
>> Robert
>>
>>
>> On Mon, Sep 21, 2015 at 6:56 PM, Pavel Alexeev <fo...@hu...> wrote:
>>> From what tarball I could build that?
>>>
>>> On 20.09.2015 23:17, Robert Iakobashvili wrote:
>>>> Hi Pavel,
>>>>
>>>> In curl-loader Makefile:
>>>>
>>>> 1. comment our targets libcurl and libevent from build;
>>>>
>>>> 2. provide instead standard paths/locations of these libraries
>>>>     that in any case are specific for your distribution.
>>>>
>>>> Kind regards,
>>>> Robert
>>>>
>>>>
>>>> On Sun, Sep 20, 2015 at 10:47 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>> Thank you very much!
>>>>>
>>>>> But version still 0.56 for download. Could you please release new version?
>>>>>
>>>>> Or it intended to be built from source system?
>>>>>
>>>>> Should I use some switches to do not use patches, or just delete them is
>>>>> enough?
>>>>>
>>>>> On 04.08.2015 16:33, Robert Iakobashvili wrote:
>>>>>> Dear Pavel,
>>>>>>
>>>>>> This is to confirm that curl-loader will work properly without patches
>>>>>> for libcurl and libevent.
>>>>>>
>>>>>> The patches have their own advantages but not so important.
>>>>>>
>>>>>> I do not have any clues about fsf addresses, though.
>>>>>> Regards,
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>> Hello Robert.
>>>>>>> Firstly I glad receive response from you.  Thanks. I also had write
>>>>>>> about incorrect fsf address in files headers which leaved without answer
>>>>>>> (it is not stop issue, but I should be inform you [1]), and also there
>>>>>>> long time no new curl-loader releases... So I became fear project abandoned.
>>>>>>>
>>>>>>> What concerned libevent patch, had it been ever proposed to include for
>>>>>>> upstream libevent project? Is it possible to do?
>>>>>>>
>>>>>>> [1]
>>>>>>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>>>>>>
>>>>>>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>>>>>>> Dear Pavel,
>>>>>>>> First, we like truly community distros like
>>>>>>>> Debian and Fedora.
>>>>>>>>
>>>>>>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>>>>>>> and all were integrated to libcurl besides this
>>>>>>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>>>>>>
>>>>>>>> I will look next week into this matter and what could be done,
>>>>>>>> but we have a good command of libcurl and error codes
>>>>>>>> were not a substituted from my mems.
>>>>>>>>
>>>>>>>> There's a one more essential patch and it's for libevent library.
>>>>>>>> This patch increases in some define maximum number of allowed
>>>>>>>> file descriptors to enable much higher productivity for curl-loader.
>>>>>>>>
>>>>>>>> Without this libevent patch curl-loader will function with a limit
>>>>>>>> of the number of connection specified in libevent as low as only 64K
>>>>>>>> as I remember, but it will function properly within this limitation.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>>>>>>> distribution.
>>>>>>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>>>>>>> packages directory.
>>>>>>>>>
>>>>>>>>> That is strongly prohibited by our rules:
>>>>>>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>>>>>>
>>>>>>>>> I have tried link curl-loader with system libraries, and observe you
>>>>>>>>> patch that software (patches directory).
>>>>>>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>>>>>>> you prefer patch that library instead of use wide range of predefined
>>>>>>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>>>>>>
>>>>>>>>> So, in that point it is stop issue.
>>>>>>>>> Do you willing working on that issue?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>>>>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> _______________________________________________
>>>>>>>>> curl-loader-devel mailing list
>>>>>>>>> cur...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel

Re: Removing bundled libs in curl-loader

[Robert I. <cor...@gm...>]

Hi Pavel,
I've cutted libcurl, libevent and libcares custom building:
see the Makefile attached (I've not tried it, sorry)
to be used instead of the one in curl-loader-0.56.

My guess, you will create a patch.

Thank you.
Regards,
Robert


On Mon, Sep 21, 2015 at 7:38 PM, Robert Iakobashvili
<cor...@gm...> wrote:
> Hi Pavel,
> From curl-loader-0.56
>
> Just patch the Makefile file
> as described below not to build custom libcurl and libevent
> and instead push there standard libraries from your distribution.
>
>
> Regards,
> Robert
>
>
> On Mon, Sep 21, 2015 at 6:56 PM, Pavel Alexeev <fo...@hu...> wrote:
>> From what tarball I could build that?
>>
>> On 20.09.2015 23:17, Robert Iakobashvili wrote:
>>> Hi Pavel,
>>>
>>> In curl-loader Makefile:
>>>
>>> 1. comment our targets libcurl and libevent from build;
>>>
>>> 2. provide instead standard paths/locations of these libraries
>>>     that in any case are specific for your distribution.
>>>
>>> Kind regards,
>>> Robert
>>>
>>>
>>> On Sun, Sep 20, 2015 at 10:47 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>> Thank you very much!
>>>>
>>>> But version still 0.56 for download. Could you please release new version?
>>>>
>>>> Or it intended to be built from source system?
>>>>
>>>> Should I use some switches to do not use patches, or just delete them is
>>>> enough?
>>>>
>>>> On 04.08.2015 16:33, Robert Iakobashvili wrote:
>>>>> Dear Pavel,
>>>>>
>>>>> This is to confirm that curl-loader will work properly without patches
>>>>> for libcurl and libevent.
>>>>>
>>>>> The patches have their own advantages but not so important.
>>>>>
>>>>> I do not have any clues about fsf addresses, though.
>>>>> Regards,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>> Hello Robert.
>>>>>> Firstly I glad receive response from you.  Thanks. I also had write
>>>>>> about incorrect fsf address in files headers which leaved without answer
>>>>>> (it is not stop issue, but I should be inform you [1]), and also there
>>>>>> long time no new curl-loader releases... So I became fear project abandoned.
>>>>>>
>>>>>> What concerned libevent patch, had it been ever proposed to include for
>>>>>> upstream libevent project? Is it possible to do?
>>>>>>
>>>>>> [1]
>>>>>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>>>>>
>>>>>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>>>>>> Dear Pavel,
>>>>>>> First, we like truly community distros like
>>>>>>> Debian and Fedora.
>>>>>>>
>>>>>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>>>>>> and all were integrated to libcurl besides this
>>>>>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>>>>>
>>>>>>> I will look next week into this matter and what could be done,
>>>>>>> but we have a good command of libcurl and error codes
>>>>>>> were not a substituted from my mems.
>>>>>>>
>>>>>>> There's a one more essential patch and it's for libevent library.
>>>>>>> This patch increases in some define maximum number of allowed
>>>>>>> file descriptors to enable much higher productivity for curl-loader.
>>>>>>>
>>>>>>> Without this libevent patch curl-loader will function with a limit
>>>>>>> of the number of connection specified in libevent as low as only 64K
>>>>>>> as I remember, but it will function properly within this limitation.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>>>>>> distribution.
>>>>>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>>>>>> packages directory.
>>>>>>>>
>>>>>>>> That is strongly prohibited by our rules:
>>>>>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>>>>>
>>>>>>>> I have tried link curl-loader with system libraries, and observe you
>>>>>>>> patch that software (patches directory).
>>>>>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>>>>>> you prefer patch that library instead of use wide range of predefined
>>>>>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>>>>>
>>>>>>>> So, in that point it is stop issue.
>>>>>>>> Do you willing working on that issue?
>>>>>>>>
>>>>>>>> --
>>>>>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>>>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> curl-loader-devel mailing list
>>>>>>>> cur...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>>

Re: Removing bundled libs in curl-loader

[Robert I. <cor...@gm...>]

Hi Pavel,
>From curl-loader-0.56

Just patch the Makefile file
as described below not to build custom libcurl and libevent
and instead push there standard libraries from your distribution.


Regards,
Robert


On Mon, Sep 21, 2015 at 6:56 PM, Pavel Alexeev <fo...@hu...> wrote:
> From what tarball I could build that?
>
> On 20.09.2015 23:17, Robert Iakobashvili wrote:
>> Hi Pavel,
>>
>> In curl-loader Makefile:
>>
>> 1. comment our targets libcurl and libevent from build;
>>
>> 2. provide instead standard paths/locations of these libraries
>>     that in any case are specific for your distribution.
>>
>> Kind regards,
>> Robert
>>
>>
>> On Sun, Sep 20, 2015 at 10:47 PM, Pavel Alexeev <fo...@hu...> wrote:
>>> Thank you very much!
>>>
>>> But version still 0.56 for download. Could you please release new version?
>>>
>>> Or it intended to be built from source system?
>>>
>>> Should I use some switches to do not use patches, or just delete them is
>>> enough?
>>>
>>> On 04.08.2015 16:33, Robert Iakobashvili wrote:
>>>> Dear Pavel,
>>>>
>>>> This is to confirm that curl-loader will work properly without patches
>>>> for libcurl and libevent.
>>>>
>>>> The patches have their own advantages but not so important.
>>>>
>>>> I do not have any clues about fsf addresses, though.
>>>> Regards,
>>>> Robert
>>>>
>>>>
>>>> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>> Hello Robert.
>>>>> Firstly I glad receive response from you.  Thanks. I also had write
>>>>> about incorrect fsf address in files headers which leaved without answer
>>>>> (it is not stop issue, but I should be inform you [1]), and also there
>>>>> long time no new curl-loader releases... So I became fear project abandoned.
>>>>>
>>>>> What concerned libevent patch, had it been ever proposed to include for
>>>>> upstream libevent project? Is it possible to do?
>>>>>
>>>>> [1]
>>>>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>>>>
>>>>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>>>>> Dear Pavel,
>>>>>> First, we like truly community distros like
>>>>>> Debian and Fedora.
>>>>>>
>>>>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>>>>> and all were integrated to libcurl besides this
>>>>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>>>>
>>>>>> I will look next week into this matter and what could be done,
>>>>>> but we have a good command of libcurl and error codes
>>>>>> were not a substituted from my mems.
>>>>>>
>>>>>> There's a one more essential patch and it's for libevent library.
>>>>>> This patch increases in some define maximum number of allowed
>>>>>> file descriptors to enable much higher productivity for curl-loader.
>>>>>>
>>>>>> Without this libevent patch curl-loader will function with a limit
>>>>>> of the number of connection specified in libevent as low as only 64K
>>>>>> as I remember, but it will function properly within this limitation.
>>>>>>
>>>>>> Regards,
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>>>>> distribution.
>>>>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>>>>> packages directory.
>>>>>>>
>>>>>>> That is strongly prohibited by our rules:
>>>>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>>>>
>>>>>>> I have tried link curl-loader with system libraries, and observe you
>>>>>>> patch that software (patches directory).
>>>>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>>>>> you prefer patch that library instead of use wide range of predefined
>>>>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>>>>
>>>>>>> So, in that point it is stop issue.
>>>>>>> Do you willing working on that issue?
>>>>>>>
>>>>>>> --
>>>>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> curl-loader-devel mailing list
>>>>>>> cur...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>

Re: Removing bundled libs in curl-loader

[Pavel A. <fo...@hu...>]

>From what tarball I could build that?

On 20.09.2015 23:17, Robert Iakobashvili wrote:
> Hi Pavel,
>
> In curl-loader Makefile:
>
> 1. comment our targets libcurl and libevent from build;
>
> 2. provide instead standard paths/locations of these libraries
>     that in any case are specific for your distribution.
>
> Kind regards,
> Robert
>
>
> On Sun, Sep 20, 2015 at 10:47 PM, Pavel Alexeev <fo...@hu...> wrote:
>> Thank you very much!
>>
>> But version still 0.56 for download. Could you please release new version?
>>
>> Or it intended to be built from source system?
>>
>> Should I use some switches to do not use patches, or just delete them is
>> enough?
>>
>> On 04.08.2015 16:33, Robert Iakobashvili wrote:
>>> Dear Pavel,
>>>
>>> This is to confirm that curl-loader will work properly without patches
>>> for libcurl and libevent.
>>>
>>> The patches have their own advantages but not so important.
>>>
>>> I do not have any clues about fsf addresses, though.
>>> Regards,
>>> Robert
>>>
>>>
>>> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>> Hello Robert.
>>>> Firstly I glad receive response from you.  Thanks. I also had write
>>>> about incorrect fsf address in files headers which leaved without answer
>>>> (it is not stop issue, but I should be inform you [1]), and also there
>>>> long time no new curl-loader releases... So I became fear project abandoned.
>>>>
>>>> What concerned libevent patch, had it been ever proposed to include for
>>>> upstream libevent project? Is it possible to do?
>>>>
>>>> [1]
>>>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>>>
>>>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>>>> Dear Pavel,
>>>>> First, we like truly community distros like
>>>>> Debian and Fedora.
>>>>>
>>>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>>>> and all were integrated to libcurl besides this
>>>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>>>
>>>>> I will look next week into this matter and what could be done,
>>>>> but we have a good command of libcurl and error codes
>>>>> were not a substituted from my mems.
>>>>>
>>>>> There's a one more essential patch and it's for libevent library.
>>>>> This patch increases in some define maximum number of allowed
>>>>> file descriptors to enable much higher productivity for curl-loader.
>>>>>
>>>>> Without this libevent patch curl-loader will function with a limit
>>>>> of the number of connection specified in libevent as low as only 64K
>>>>> as I remember, but it will function properly within this limitation.
>>>>>
>>>>> Regards,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>>> Hello.
>>>>>>
>>>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>>>> distribution.
>>>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>>>> packages directory.
>>>>>>
>>>>>> That is strongly prohibited by our rules:
>>>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>>>
>>>>>> I have tried link curl-loader with system libraries, and observe you
>>>>>> patch that software (patches directory).
>>>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>>>> you prefer patch that library instead of use wide range of predefined
>>>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>>>
>>>>>> So, in that point it is stop issue.
>>>>>> Do you willing working on that issue?
>>>>>>
>>>>>> --
>>>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> curl-loader-devel mailing list
>>>>>> cur...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel

Re: Removing bundled libs in curl-loader

[Robert I. <cor...@gm...>]

Hi Pavel,

In curl-loader Makefile:

1. comment our targets libcurl and libevent from build;

2. provide instead standard paths/locations of these libraries
    that in any case are specific for your distribution.

Kind regards,
Robert


On Sun, Sep 20, 2015 at 10:47 PM, Pavel Alexeev <fo...@hu...> wrote:
> Thank you very much!
>
> But version still 0.56 for download. Could you please release new version?
>
> Or it intended to be built from source system?
>
> Should I use some switches to do not use patches, or just delete them is
> enough?
>
> On 04.08.2015 16:33, Robert Iakobashvili wrote:
>> Dear Pavel,
>>
>> This is to confirm that curl-loader will work properly without patches
>> for libcurl and libevent.
>>
>> The patches have their own advantages but not so important.
>>
>> I do not have any clues about fsf addresses, though.
>> Regards,
>> Robert
>>
>>
>> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>>> Hello Robert.
>>> Firstly I glad receive response from you.  Thanks. I also had write
>>> about incorrect fsf address in files headers which leaved without answer
>>> (it is not stop issue, but I should be inform you [1]), and also there
>>> long time no new curl-loader releases... So I became fear project abandoned.
>>>
>>> What concerned libevent patch, had it been ever proposed to include for
>>> upstream libevent project? Is it possible to do?
>>>
>>> [1]
>>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>>
>>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>>> Dear Pavel,
>>>> First, we like truly community distros like
>>>> Debian and Fedora.
>>>>
>>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>>> and all were integrated to libcurl besides this
>>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>>
>>>> I will look next week into this matter and what could be done,
>>>> but we have a good command of libcurl and error codes
>>>> were not a substituted from my mems.
>>>>
>>>> There's a one more essential patch and it's for libevent library.
>>>> This patch increases in some define maximum number of allowed
>>>> file descriptors to enable much higher productivity for curl-loader.
>>>>
>>>> Without this libevent patch curl-loader will function with a limit
>>>> of the number of connection specified in libevent as low as only 64K
>>>> as I remember, but it will function properly within this limitation.
>>>>
>>>> Regards,
>>>> Robert
>>>>
>>>>
>>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>>> Hello.
>>>>>
>>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>>> distribution.
>>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>>> packages directory.
>>>>>
>>>>> That is strongly prohibited by our rules:
>>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>>
>>>>> I have tried link curl-loader with system libraries, and observe you
>>>>> patch that software (patches directory).
>>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>>> you prefer patch that library instead of use wide range of predefined
>>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>>
>>>>> So, in that point it is stop issue.
>>>>> Do you willing working on that issue?
>>>>>
>>>>> --
>>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> curl-loader-devel mailing list
>>>>> cur...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>

Re: Removing bundled libs in curl-loader

[Pavel A. <fo...@hu...>]

Thank you very much!

But version still 0.56 for download. Could you please release new version?

Or it intended to be built from source system?

Should I use some switches to do not use patches, or just delete them is
enough?

On 04.08.2015 16:33, Robert Iakobashvili wrote:
> Dear Pavel,
>
> This is to confirm that curl-loader will work properly without patches
> for libcurl and libevent.
>
> The patches have their own advantages but not so important.
>
> I do not have any clues about fsf addresses, though.
> Regards,
> Robert
>
>
> On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
>> Hello Robert.
>> Firstly I glad receive response from you.  Thanks. I also had write
>> about incorrect fsf address in files headers which leaved without answer
>> (it is not stop issue, but I should be inform you [1]), and also there
>> long time no new curl-loader releases... So I became fear project abandoned.
>>
>> What concerned libevent patch, had it been ever proposed to include for
>> upstream libevent project? Is it possible to do?
>>
>> [1]
>> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>>
>> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>>> Dear Pavel,
>>> First, we like truly community distros like
>>> Debian and Fedora.
>>>
>>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>>> and all were integrated to libcurl besides this
>>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>>
>>> I will look next week into this matter and what could be done,
>>> but we have a good command of libcurl and error codes
>>> were not a substituted from my mems.
>>>
>>> There's a one more essential patch and it's for libevent library.
>>> This patch increases in some define maximum number of allowed
>>> file descriptors to enable much higher productivity for curl-loader.
>>>
>>> Without this libevent patch curl-loader will function with a limit
>>> of the number of connection specified in libevent as low as only 64K
>>> as I remember, but it will function properly within this limitation.
>>>
>>> Regards,
>>> Robert
>>>
>>>
>>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>>> Hello.
>>>>
>>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>>> distribution.
>>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>>> packages directory.
>>>>
>>>> That is strongly prohibited by our rules:
>>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>>
>>>> I have tried link curl-loader with system libraries, and observe you
>>>> patch that software (patches directory).
>>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>>> you prefer patch that library instead of use wide range of predefined
>>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>>
>>>> So, in that point it is stop issue.
>>>> Do you willing working on that issue?
>>>>
>>>> --
>>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>>> with me you would use jabber: Pahan@Hubitus.info
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> curl-loader-devel mailing list
>>>> cur...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel

Re: Removing bundled libs in curl-loader

[Robert I. <cor...@gm...>]

Dear Pavel,

This is to confirm that curl-loader will work properly without patches
for libcurl and libevent.

The patches have their own advantages but not so important.

I do not have any clues about fsf addresses, though.
Regards,
Robert


On Sat, Jul 25, 2015 at 1:49 PM, Pavel Alexeev <fo...@hu...> wrote:
> Hello Robert.
> Firstly I glad receive response from you.  Thanks. I also had write
> about incorrect fsf address in files headers which leaved without answer
> (it is not stop issue, but I should be inform you [1]), and also there
> long time no new curl-loader releases... So I became fear project abandoned.
>
> What concerned libevent patch, had it been ever proposed to include for
> upstream libevent project? Is it possible to do?
>
> [1]
> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
>
> On 24.07.2015 12:43, Robert Iakobashvili wrote:
>> Dear Pavel,
>> First, we like truly community distros like
>> Debian and Fedora.
>>
>> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
>> and all were integrated to libcurl besides this
>> one that Daniel, the curl maintainer, had hesitated to incorporate.
>>
>> I will look next week into this matter and what could be done,
>> but we have a good command of libcurl and error codes
>> were not a substituted from my mems.
>>
>> There's a one more essential patch and it's for libevent library.
>> This patch increases in some define maximum number of allowed
>> file descriptors to enable much higher productivity for curl-loader.
>>
>> Without this libevent patch curl-loader will function with a limit
>> of the number of connection specified in libevent as low as only 64K
>> as I remember, but it will function properly within this limitation.
>>
>> Regards,
>> Robert
>>
>>
>> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>>> Hello.
>>>
>>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>>> distribution.
>>> Unfortunately you use bundled copies of curl, c-ares and some other in
>>> packages directory.
>>>
>>> That is strongly prohibited by our rules:
>>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>>
>>> I have tried link curl-loader with system libraries, and observe you
>>> patch that software (patches directory).
>>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>>> you prefer patch that library instead of use wide range of predefined
>>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>>
>>> So, in that point it is stop issue.
>>> Do you willing working on that issue?
>>>
>>> --
>>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>>> with me you would use jabber: Pahan@Hubitus.info
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> curl-loader-devel mailing list
>>> cur...@li...
>>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>

Re: Removing bundled libs in curl-loader

[Pavel A. <fo...@hu...>]

Hello Robert.
Firstly I glad receive response from you.  Thanks. I also had write
about incorrect fsf address in files headers which leaved without answer
(it is not stop issue, but I should be inform you [1]), and also there
long time no new curl-loader releases... So I became fear project abandoned.

What concerned libevent patch, had it been ever proposed to include for
upstream libevent project? Is it possible to do?

[1]
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address

On 24.07.2015 12:43, Robert Iakobashvili wrote:
> Dear Pavel,
> First, we like truly community distros like
> Debian and Fedora.
>
> Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
> and all were integrated to libcurl besides this
> one that Daniel, the curl maintainer, had hesitated to incorporate.
>
> I will look next week into this matter and what could be done,
> but we have a good command of libcurl and error codes
> were not a substituted from my mems.
>
> There's a one more essential patch and it's for libevent library.
> This patch increases in some define maximum number of allowed
> file descriptors to enable much higher productivity for curl-loader.
>
> Without this libevent patch curl-loader will function with a limit
> of the number of connection specified in libevent as low as only 64K
> as I remember, but it will function properly within this limitation.
>
> Regards,
> Robert
>
>
> On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
>> Hello.
>>
>> I'm Pavel. I have intension include curl-loader into Fedora Linux
>> distribution.
>> Unfortunately you use bundled copies of curl, c-ares and some other in
>> packages directory.
>>
>> That is strongly prohibited by our rules:
>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>>
>> I have tried link curl-loader with system libraries, and observe you
>> patch that software (patches directory).
>> Brief look at curl-trace-info-error.patch leave me in frustration. Why
>> you prefer patch that library instead of use wide range of predefined
>> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>>
>> So, in that point it is stop issue.
>> Do you willing working on that issue?
>>
>> --
>> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
>> with me you would use jabber: Pahan@Hubitus.info
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> curl-loader-devel mailing list
>> cur...@li...
>> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel

Re: Removing bundled libs in curl-loader

[Robert I. <cor...@gm...>]

Dear Pavel,
First, we like truly community distros like
Debian and Fedora.

Originally, we had 4-5 patches for libcurl, mainly increasing productivity,
and all were integrated to libcurl besides this
one that Daniel, the curl maintainer, had hesitated to incorporate.

I will look next week into this matter and what could be done,
but we have a good command of libcurl and error codes
were not a substituted from my mems.

There's a one more essential patch and it's for libevent library.
This patch increases in some define maximum number of allowed
file descriptors to enable much higher productivity for curl-loader.

Without this libevent patch curl-loader will function with a limit
of the number of connection specified in libevent as low as only 64K
as I remember, but it will function properly within this limitation.

Regards,
Robert


On Fri, Jul 24, 2015 at 12:16 PM, Pavel Alexeev <fo...@hu...> wrote:
> Hello.
>
> I'm Pavel. I have intension include curl-loader into Fedora Linux
> distribution.
> Unfortunately you use bundled copies of curl, c-ares and some other in
> packages directory.
>
> That is strongly prohibited by our rules:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>
> I have tried link curl-loader with system libraries, and observe you
> patch that software (patches directory).
> Brief look at curl-trace-info-error.patch leave me in frustration. Why
> you prefer patch that library instead of use wide range of predefined
> error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?
>
> So, in that point it is stop issue.
> Do you willing working on that issue?
>
> --
> With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
> with me you would use jabber: Pahan@Hubitus.info
>
> ------------------------------------------------------------------------------
> _______________________________________________
> curl-loader-devel mailing list
> cur...@li...
> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel

Removing bundled libs in curl-loader

[Pavel A. <fo...@hu...>]

Hello.

I'm Pavel. I have intension include curl-loader into Fedora Linux
distribution.
Unfortunately you use bundled copies of curl, c-ares and some other in
packages directory.

That is strongly prohibited by our rules:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

I have tried link curl-loader with system libraries, and observe you
patch that software (patches directory).
Brief look at curl-trace-info-error.patch leave me in frustration. Why
you prefer patch that library instead of use wide range of predefined
error codes http://curl.haxx.se/libcurl/c/libcurl-errors.html ?

So, in that point it is stop issue.
Do you willing working on that issue?

-- 
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me you would use jabber: Pahan@Hubitus.info

Curl-loader have old FSF address

[Pavel A. <fo...@hu...>]

Hello.

Could you please correct it?

curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/mpool.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/batch.c
curl-loader-debuginfo.x86_64: E: non-standard-dir-perm
/usr/src/debug/curl-loader-0.56/inc 775
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/batch.h
curl-loader-debuginfo.x86_64: E: non-standard-dir-perm /usr/lib/debug 775
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/loader.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/conf.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/loader.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/conf.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/timer_queue.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/mpool.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/url.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/heap.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/loader_smooth.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/client.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/timer_queue.c
curl-loader-debuginfo.x86_64: E: non-standard-dir-perm
/usr/src/debug/curl-loader-0.56/inc/curl 775
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/client.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/heap.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/screen.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/screen.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/environment.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/timer_tick.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/cl_alloc.c
curl-loader-debuginfo.x86_64: E: non-standard-dir-perm
/usr/src/debug/curl-loader-0.56/build/libevent 775
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/cl_alloc.h
curl-loader-debuginfo.x86_64: E: non-standard-dir-perm
/usr/src/debug/curl-loader-0.56/build 775
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/timer_node.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/loader_hyper.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/loader_fsm.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/statistics.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/parse_conf.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/ssl_thr_lock.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/url.c
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/ssl_thr_lock.h
curl-loader-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/curl-loader-0.56/statistics.h

from: dhirajlulla83

[dhirajlulla83 <dhi...@gm...>]

Hi


http://tipperaryhorseblankets.com/lady.php?section=y7c9tk1cq0sbhhe




dhi...@gm...


Sent from my iPhone

threads hung on read call with SMP configuration

[Mathieu <mat...@gm...>]

Hi,

When using the -t <threads_count> option, the created threads are
blocked after one cycle (the screen is not refreshed anymore, and no
more client is added).

However, entering anything on the keyboard unblock one thread, but
just for one cycle. Not using the -t option works as well.

The configuration used is the following:
- Hardware: HP server with 8cores intel CPU (not a virtual machine)
- OS: Debian Jessie
- Kernel: 3.16.0

Funnily enough, doing a strace on the main process group unblock the
situation (it seems attaching strace sends a signal to the process
that could cause this behaviour).

Nonetheless, making a strace on only one of the thread shows that it
is blocked on the read call (in screen.c), apparently ignoring the
VTIME timer.

Not sure if anyone encountered the same problem, but if so, below and
attached is a patch that fixes it (using select prior to read).

--
Mat

--- screen.c 2007-04-26 09:26:59.000000000 +0200
+++ /usr/src/curl-loader-0.56/screen.c 2015-05-31 10:44:41.712447334 +0200
@@ -82,6 +82,9 @@
   struct termios otty, ntty;
   int ch = -1;

+  struct timeval tv;
+  fd_set readset;
+
   tcgetattr(STDIN_FILENO, &otty);
   ntty = otty;

@@ -98,6 +101,10 @@
   ntty.c_cc[VMIN]  = 0;      /* non-block for input  */
   ntty.c_cc[VTIME] = 1;      /* with timer*/

+  tv.tv_sec = 0;
+  tv.tv_usec = 100000;
+
+
 #if 0
 /*
  * use this to flush the input buffer before
@@ -115,15 +122,21 @@

   if (!tcsetattr(STDIN_FILENO, FLAG, &ntty))
    {
+     FD_ZERO(&readset);
+     FD_SET(STDIN_FILENO, &readset);
+     select(STDIN_FILENO + 1, &readset, NULL, NULL, &tv);
      /* get a single character from stdin */
-     if (read (STDIN_FILENO, &ch, 1 ) == -1)
-       {
-         if (!stop_loading)
-           {
-             fprintf(stderr, "%s - read() failed with errno %d.\n",
-                     __func__, errno);
-           }
-         return -1;
+     if (FD_ISSET(fileno(stdin), &readset))
+      {
+        if (read (STDIN_FILENO, &ch, 1 ) == -1)
+          {
+            if (!stop_loading)
+              {
+                fprintf(stderr, "%s - read() failed with errno %d.\n",
+                        __func__, errno);
+              }
+            return -1;
+          }
        }

      /* restore old settings */