[Slackbuilds-users] tangogps slackbuild doesn't work

[Donald Allen]

Now that I'm back in the slackware fold, I've done some more testing of the
changes described below and have still not seen a segfault. So it's looking
more and more like B Watson's suggestion, on which my changes are based, was
the right idea, and he deserves the thanks of those of us who enjoy using
tangogps.

/Don

On Fri, Aug 5, 2011 at 3:16 PM, Donald Allen <donaldcallen at gmail.com> wrote:

>
>
> On Sun, Jul 31, 2011 at 8:57 PM, Pedro Mendes <pedro at gepasi.org> wrote:
>
>> Too bad, I had already submitted. I think I can pull it out and will
>> wait for further information from you. We can add a patch to the
>> slackbuild, this is done in other packages when it cannot be avoided.
>>
>
> Hi --
>
> Sorry it has taken me awhile to get back. We had a family emergency that
> took me away for a couple of days.
>
> I have not tested tangogps with the changes I installed as thoroughly as I
> would have liked, but the testing I did resulted in no segfaults, which were
> pretty easy to provoke before I installed the changes below.
>
> I have reached the point where I've had enough problems with slackbuilds
> and I'm tired of the pain of slackware package management (or lack thereof)
> that I'm giving debian a try (I found that I could install it without a
> desktop environment, exactly what I wanted; I just run dwm) and I have to do
> it on the netbook for various reasons. So I no longer have slackware
> installed on that machine, so I won't be able to do further testing in a
> car. But I think it's safe to install the changes below.
>
> Here are the diffs:
>
> diff src/tile_management.c
> /home/dca/Software/tangogps-0.99.4/src/tile_management.c
> 249a250
>
> >               curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1);
> diff src/util.c /home/dca/Software/tangogps-0.99.4/src/util.c
> 111a112
> >       curl_easy_setopt(curl_handle, CURLOPT_NOSIGNAL, 1);
> 168a170
> >       curl_easy_setopt(curl_handle, CURLOPT_NOSIGNAL, 1);
>
> The left-hand files (in src/) as the originals; the right-hand files are
> the ones I modified, adding the calls to curl_easy_setopt.
>
> I hope this helps.
>
> /Don
>
>>
>> thanks
>> pedro
>>
>> On Mon, Aug 1, 2011 at 12:34 AM, Donald Allen <donaldcallen at gmail.com>
>> wrote:
>> > Pedro --
>> > I should have copied you on this, because you need to be aware of this
>> > discussion. We don't have an answer yet, but B Watson may have
>> identified
>> > the problem. I'll be sure to let you know how my testing turns out.
>> Right
>> > now, even tangogps 0.99.4 (built from source) is unreliable on slackware
>> > 13.37. Hopefully, this will fix the problem. More when I know more.
>> > /Don
>> >
>> > ---------- Forwarded message ----------
>> > From: B Watson <yalhcru at gmail.com>
>> > Date: Sun, Jul 31, 2011 at 5:39 PM
>> > Subject: Re: [Slackbuilds-users] tangogps slackbuild doesn't work
>> > To: "SlackBuilds.org Users List" <slackbuilds-users at slackbuilds.org>
>> >
>> >
>> > On 7/31/11, Donald Allen <donaldcallen at gmail.com> wrote:
>> >
>> >> If you google for 'libcurl "error 6" segfault', you get hits involving
>> all
>> >> sorts of applications that apparently use curl. Try it. This looks to
>> me
>> >> like a bug in libcurl. So unless you are feeling better, stay in bed.
>> This
>> >> appears to be someone else's problem.
>> >
>> > This sounds really similar to the issue with uget that I dealt with a
>> > while back.
>> >
>> > If it's the same issue, it can be fixed by adding
>> >
>> > curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1);
>> >
>> > somewhere in the bit of code that sets the other curl options.
>> >
>> > The issue is actually documented in the curl API docs: if curl is
>> > built with threads but without c-ares support (like the one shipped
>> > with slackware), the default DNS timeout handling (which uses signals,
>> > presumably SIGALRM) is unsafe.
>> >
>> > Adding to the confusion is that (at least in the case of uget) this
>> > didn't actually hurt anything on slackware 13.1, but it does on 13.37.
>> >
>> > I dunno if you can consider this a bug in curl or not: it's documented,
>> > but if I were a curl dev, I'd want to fix it (by having CURLOPT_NOSIGNAL
>> > default to 1 when curl is built without c-ares). Application code can
>> > set CURLOPT_NOSIGNAL, but I don't know how hard it is for a configure
>> > script or makefile to detect whether curl was built with c-ares, and I
>> > don't know what happens if you set CURLOPT_NOSIGNAL when using a libcurl
>> > with c-ares support.
>> > _______________________________________________
>> > SlackBuilds-users mailing list
>> > SlackBuilds-users at slackbuilds.org
>> > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> > FAQ - http://slackbuilds.org/faq/
>> >
>> >
>> >
>>
>>
>>
>> --
>> Pedro, o guardador de enzimas e computadores
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20110809/b0ae227c/attachment.html>