Re: antlr3 on slow machines
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
Reply to: