Re: antlr3 on slow machines

[Bálint Réczey <balint@balintreczey.hu>]

Hi,

2015-02-24 14:27 GMT+01:00 Thorsten Glaser <tg@mirbsd.de>:
> Emmanuel Bourg dixit:
>
>>This issue only affects non arch all packages depending on antlr, I
>>don't think there are many of them and fixing the issue with an extra
>>command line parameter is trivial.
>
> Hmm.
>
> udd=> SELECT source, version, architecture FROM sources WHERE release='sid' AND build_depends LIKE '%antlr3%';
>         source         |    version    | architecture
> -----------------------+---------------+--------------
>  sqljet                | 1.1.10-1      | all
>  openjfx               | 8u20-b26-3    | any all
>  netbeans              | 7.0.1+dfsg1-5 | all
>  logol                 | 1.7.0-2       | any all
>  logol                 | 1.6.9-3       | any all
>  libnb-platform18-java | 7.4+dfsg1-2   | all
>  herold                | 6.1.0-1       | all
>  forked-daapd          | 22.0-2        | any
>  forked-daapd          | 22.0-1        | any
>  eclipselink           | 2.5.1-2       | all
>  belle-sip             | 1.3.0-1.1     | any
> (11 rows)
>
> Unsure if the query is really “enough” (IMHO B-D should be
> split off into their own table so we can do exact package
> name matches), but if it is, and if the “architecture”
> column is what I think it is, we have:
>
> • openjfx
> • logol
> • forked-daapd
> • belle-sip
>
> That’s indeed not much for the respective maintainers to fix.
>
> Debian-Multimedia, can you do that for your packages, so we
> see whether the fix indeed works?

A bigger context from the email:
2015-02-24 13:44 GMT+01:00 Emmanuel Bourg <ebourg@apache.org>:
> Le 24/02/2015 13:23, Thorsten Glaser a écrit :
>
>> Bálint Réczey dixit:
>>
>>> Not that I am lazy but I think instead of patching every package using
>>> antlr antlr itself should be patched to use higher default timeouts on
>>> slow platforms.
>>
>> can we please get some sort of feedback on this?
>> Revisiting because the next forked-daapd build failed.
>
> This issue only affects non arch all packages depending on antlr, I
> don't think there are many of them and fixing the issue with an extra
> command line parameter is trivial.
>
> I have no strong opinion on this, I tend to prefer sticking to the
> default upstream settings, but if you think patching antlr is better
> feel free to go ahead.
>
> Emmanuel Bourg
>
I would still fix antlr instead and Emmanuel seems to be OK with that.
Why would reverse dependencies diverge from upstream when the slow
program is antlr?

Cheers,
Balint