Bug#893188: mapnik: add mips* back to arch list

[James Cowgill]

Hi,

On 18/03/18 09:37, YunQiang Su wrote:
> On Sun, Mar 18, 2018 at 5:05 PM, Sebastiaan Couwenberg
>  wrote:
>> On 03/18/2018 09:23 AM, YunQiang Su wrote:
>>> On Sat, Mar 17, 2018 at 5:41 PM, Sebastiaan Couwenberg wrote:
 Why do you want mapnik back on mips*?

 I don't expect any actual users of the mapnik family of packages on
 mips*, so despite improvements to the architecture in Debian I don't
 think it's worth the effort.

How much extra effort is required here?

>>> At least Loongson may need it, as Loongson is working on providing
>>> high-end PC/Server in China, and some department of government and
>>> some companies will need it.
>>> At least please provide mips64el and mips64r6el, both of them are
>>> targeting for high-end machines.
>>
>> If they "may" need it, I strongly prefer those users who will actually
>> use mapnik on mips* to request it. So far it's still hypothetical.
> 
> In deed, a Loongson guy told me that their customers are using mapnik.
> He didn't tell me the customers of course.
> 
> @Anibal, @Douglas,
>I guess we should also ask for any our customers are using it.
> 
> @Sebastiaan, I know it is a quite hard work to maintain so many packages,
> and before the response from MIPS is some slow, I am very sorry of that.
> Anyway, we can have a quicker response in future.
> 
>> I'm inclined to close this as wontfix until actual users of mapnik
>> request it on mips64el.

Debian policy lists the two valid reasons for restricting the
architecture list (5.6.8):
- A package is not portable to that arch.
- A package would not be useful on that arch.

I argue that none of these reasons apply here and therefore the packages
should be Architecture: any (or possibly linux-any, but I haven't
checked non-linux arches). This would also assist ia64 which I notice is
not in the architecture list. Also note that none of these reasons
require actual users. Do you think there are users of mapnik on every
architecture you currently have in the architecture list? Can you
provide the requests from users of these architectures to enable mapnik?

If you are concerned about mips (or any architecture) blocking testing
migration then the two correct options are:
- Asking the porters for help.
- Requesting removal of your package on that architecture.

Sometimes the porters have a lot of other work to do or are unavailable.
Sorry if this has happened to you.

The advantage of requesting removal over restricting the arch list is
that the package automatically becomes available again if it gets fixed
(eg by upstream) and the package is continually built and tested each
upload so people can see what is broken. Not restricting the
architecture list avoids porters having to poke maintainers when a new
architecture is bootstrapped.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#791482: mapnik: ftbfs, please upgrade your compiler to at least g++ 4.7

[James Cowgill]

Control: severity -1 important
Control: retitle -1 mapnik: incorrectly handles CPPFLAGS

On Sun, 5 Jul 2015 17:04:05 +0200 Holger Levsen hol...@layer-acht.org wrote:
 Source: mapnik
 Version: 3.0.0~rc3+ds-2
 Severity: serious
 x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org
 User: reproducible-bui...@lists.alioth.debian.org
 Usertags: ftbfs
 
 Dear Maintainer,
 
 mapnik fails to build from source in sid, as can be seen at 
 https://reproducible.debian.net/rbuild/unstable/amd64/mapnik_3.0.0~rc3+ds-2.rbuild.log
 
 Quoting that log:
 
 Welcome to Mapnik...
 
 Configuring build environment...
 Configuring on Linux in *release mode*...
 Checking for freetype-config... yes
 Checking for xml2-config... yes
 Checking for dlfcn.h support ... no
 Checking if compiler (c++) supports -std=c++11 flag... (cached) no
 C++ compiler does not support C++11 standard (-std=c++11), which is 
 required. Please upgrade your compiler to at least g++ 4.7 (ideally 4.8)
 debian/rules:28: recipe for target 'debian/stamps/configure-python' failed
 make[1]: *** [debian/stamps/configure-python] Error 1
 make[1]: Leaving directory '/tmp/buildd/mapnik-3.0.0~rc3+ds'
 debian/rules:58: recipe for target 'build' failed

I couldn't reproduce this in a clean unstable chroot.

However I could reproduce the build failure from the rbuild by running
scons manually with the arguments from it. It appears that mapnik
incorrectly handles the CPPFLAGS variable - the addition of -Wdate-time
in the reproducible builds caused the build failure.

Running scons gives this in config.log:
c++ -o .sconf_temp/conftest_3.o -c -std=c++11 -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -g0 -D-Wdate-time -D_FORTIFY_SOURCE=2 -g0 
-DSHAPE_MEMORY_MAPPED_FILE -Iinclude -I/usr/include -I/usr/include/freetype2 
-I/usr/include/libxml2 .sconf_temp/conftest_3.cpp
command-line:0:1: error: macro names must be identifiers

The '-D-Wdate-time' comes from adding CPPFLAGS to the CUSTOM_DEFINES
variable in debian/rules. SCons prefixes everything in this variable
with -D so it is not suitable for CPPFLAGS. I suggest you append
CPPFLAGS to both CUSTOM_CFLAGS and CUSTOM_CXXFLAGS instead.

Thanks,
James

signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#734153: libhdf4-alt-dev doesn't work on mips*

[James Cowgill]

Control: tags -1 patch

Hi,

On Sat, 04 Jan 2014 11:26:48 + Alastair McKinstry mckins...@debian.org 
wrote:
 Building ncl with libhdf4-alt-dev, it FTBFS on mips and mipsel due to:
 
 cc -ansi  -fPIC -g -O2 -Wformat -Werror=format-security
 -I../../../.././include -I/usr/include/freetype2 -I/usr/include/gdal  
 -I/usr/include/hdf-eos5 -I/usr/include/hdf   -DBuildRasterHDF -DLINUX 
 -DBuildRasterHPPCL -DBuildRasterNrif -DBuildRasterSun  
 -DBuildRasterXWD  -DBuildRasterAVS -DBuildRasterSGI 
 -DBuildRasterAbekas  -DBuildRasterBinary -DBuildRasterYUV   
 -DNGTMPDIR='tmp' -Dmips -DIBM -DSYSV -D_POSIX_SOURCE -D_XOPEN_SOURCE 
 -DByteSwapped -DNeedFuncProto  -D_FORTIFY_SOURCE=2  -c -o hdf.o hdf.c
 In file included from /usr/include/hdf/hdf.h:20:0,
  from hdf.c:54:
 /usr/include/hdf/hdfi.h:1886:1: error: unknown type name 'No'
  No machine type has been defined.  Your Makefile needs to have someing like

This is caused by compiling with -ansi which suppresses the non-ansi
MIPSEB and MIPSEL defines hdfi.h uses. This can be fixed by using
__MIPSEB__ and __MIPSEL__ instead, and I've attached a patch which does
this.

Note this fix is unrelated to any of the mips64el stuff which is also
going on at the minute.

Thanks,
James

diff -ur a/debian/patches/hdfi.h b/debian/patches/hdfi.h
--- a/debian/patches/hdfi.h	2015-03-01 16:04:15.0 +
+++ b/debian/patches/hdfi.h	2015-03-13 15:33:42.559914610 +
@@ -293,7 +291,7 @@
 +
 +#endif /* Linux/s390 */
 +
-+#if defined (__linux__)  (defined (MIPSEB) || defined(MIPSEL))
++#if defined (__linux__)  (defined (__MIPSEB__) || defined(__MIPSEL__))
 +
 +#ifdef GOT_MACHINE
 +If you get an error on this line more than one machine type has been defined.
@@ -307,9 +305,9 @@
 +#include unistd.h
 +#include ctype.h  /* for character macros */
 +
-+#if defined (MIPSEB)
++#if defined (__MIPSEB__)
 +#define DF_MT DFMT_MIPSEB
-+#elif defined(MIPSEL)
++#elif defined(__MIPSEL__)
 +#define DF_MT		  DFMT_MIPSEL
 +#endif
 +


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#779624: libhdf4: FTBFS on mips64el (again) - lots of segfaults in testsuite

[James Cowgill]

Source: libhdf4
Version: 4.2.10-3.1
Severity: important
Tags: patch
X-Debbugs-CC: s...@debian.org

Hi,

The previous upload wasn't enough it seems (sorry). Although libhdf4
built OK, the testsuite segfaults quite a lot.

Full log:
http://mipsdebian.imgtec.com/debian/logs/libh/libhdf4/libhdf4_4.2.10-3.1_mips64el-20150302-1113.build.gz

The attached patch fixes the testsuite for me this time. The header
which defines 'struct xdr_ops' has no mention of these special IRIX
fields so when they're inserted later in 'xdrposix_ops' they cause all
the other fields to be misplaced and the incorrect functions get called.

Thanks,
James

--- a/HDF4/mfhdf/libsrc/xdrposix.c
+++ b/HDF4/mfhdf/libsrc/xdrposix.c
@@ -283,12 +283,6 @@ static void xdrposix_destroy();
 static struct xdr_ops   xdrposix_ops = {
 xdrposix_getlong,   /* deserialize a 32-bit int */
 xdrposix_putlong,   /* serialize a 32-bit int */
-#if (_MIPS_SZLONG == 64)
-/* IRIX64 has 64 bits long and 32 bits int. */
-/* It defines two extra entries for get/put int. */
-xdrposix_getint,   /* deserialize a 32-bit int */
-xdrposix_putint,   /* serialize a 32-bit int */
-#endif
 xdrposix_getbytes,  /* deserialize counted bytes */
 xdrposix_putbytes,  /* serialize counted bytes */
 xdrposix_getpos,/* get offset in the stream */
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#772980: Bug #772980: libhdf4: FTBFS on mips64el - Assertion `sizeof(hdf_pint_t)==sizeof(void *)' failed.

[James Cowgill]

Control: tags -1 patch

On Fri, 12 Dec 2014 17:40:06 + James Cowgill james...@cowgill.org.uk 
wrote:
 Hi,
 
 libhdf4 FTBFS on mips64el because it chooses the size of hdf_pint_t
 incorrectly. This results in a lot of warnings and causes this assertion
 to fail near the end of the log:

So I had a look at fixing this and it seems that there was already
another bug (#753493) on this issue and you tried to fix it in this
commit:

https://anonscm.debian.org/cgit/pkg-grass/hdf4.git/commit/?id=683f409c2e11b4cd3f20f62bc01ba02f839656bc

Unfortunately, you changed the typedefs for ARM instead of MIPS so the
bug wasn't fixed. Thankfully since int and long are the same on 32-bit
ARM, it had no effect there and nothing broke.

I've attached a patch to the hdfi.h patch which has the correct line
numbers against 4.2.10-3.

Thanks,
James
--- a/debian/patches/hdfi.h	2014-10-21 14:20:19.0 +0100
+++ b/debian/patches/hdfi.h	2015-02-27 23:48:18.397275292 +
@@ -324,14 +324,14 @@
 +typedef unsigned char uint8;
 +typedef short int int16;
 +typedef unsigned short int uint16;
-+typedef long int  int32;
-+typedef unsigned long int uint32;
++typedef int   int32;
++typedef unsigned int  uint32;
 +typedef int   intn;
 +typedef unsigned int  uintn;
 +typedef float float32;
 +typedef doublefloat64;
 +typedef long  intf; /* size of INTEGERs in Fortran compiler */
-+typedef int   hdf_pint_t;   /* an integer the same size as a pointer */
++typedef long  hdf_pint_t;   /* an integer the same size as a pointer */
 +#define FNAME_POST_UNDERSCORE
 +#define _fcdtocp(desc) (desc)
 +
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#772980: libhdf4: FTBFS on mips64el - Assertion `sizeof(hdf_pint_t)==sizeof(void *)' failed.

[James Cowgill]

Source: libhdf4
Version: 4.2.10-3
Severity: important

Hi,

libhdf4 FTBFS on mips64el because it chooses the size of hdf_pint_t
incorrectly. This results in a lot of warnings and causes this assertion
to fail near the end of the log:

 lt-ncgen: atom.c:103: HAinit_group: Assertion 
 `sizeof(hdf_pint_t)==sizeof(void *)' failed.

You can find the full log here:
http://mips64el.debian.net/debian/buildlog/libh/libhdf4_4.2.10-3/libhdf4_4.2.10-3_mips64el-20141112-0459.build

Thanks,
James

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel