Bug#837354: proj: FTBFS on kfreebsd

[Bas Couwenberg]

On September 17, 2016 9:10:56 AM GMT+02:00, Mattia Rizzolo <mattia at debian.org> wrote:
>On Sun, Sep 11, 2016 at 11:08:03AM +0200, Sebastiaan Couwenberg wrote:
>> On 09/11/2016 12:32 AM, Andreas Beckmann wrote:
>> > Or is it possible to just not build libproj-java on kfreebsd*?
>> > Removing proj from kfreebsd* would affect a lot of packages:
>> 
>> libproj-java doesn't have reverse dependencies are a very low popcon,
>so
>> dropping the package is an option. Now is not the time to do that
>though.
>
>Why not?  Would you like/need a patch for it?

Because we've just had a proj transition for which the last rdep only migrated to testing today.

I don't need a patch, thanks for the offer though.

>> Since kfreebsd-* isn't a release architecture any more, this kind of
>> breakage is expected. hurd-i386 and x32 have similar issue for
>example.
>[whereas both hurd-i386 and x32 built just fine...]

I was not talking about the proj package on Hurd and x32, but gdal, another essential GIS package. The numpy FTBFS on x32 is preventing lots of rdeps to build on that architecture for example.

>> Because maintainers don't care enough about the ports essential GIS
>> packages cannot be built. And apparently the porters don't care
>enough
>> either to assist the maintainers to get the packages fixed on those
>> architectures.
>
>The difference between kfreebsd/hurd and i.e. x32 is that they live on
>ftp-master.  Being on ftp-master means they get to be under the radar
>of
>several QA people, and are tracked during transitions in the transition
>trackers, and hinder decrufting of old libraries.
>
>
>Could you please explain why it wouldn't be possible for you to make
>libproj-java building only on 'linux-any hurd-any'?

I never said that it's not possible, just that now was not the right time for this change. I don't like packaging differences between architectures, so I'm currently doubting whether to drop the Java package entirely or complicate matters by only removing it from the problematic architectures or to simply not bother since kfreebsd is not a release architecture. I've so far leaned towards the latter, but I'm willing to reconsider if more people want to fix proj on kfreebsd.

Kinds Regards,

Bas