Bug#895333: double-conversion: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: double-conversion Version: 2.0.1-4 Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for the riscv64 architecture. With the "quick and dirty" patch attached it builds and passes the test suite, but ideally it should also test which of the ISA extensions (including which of the FP extensions, Float, Double, Quad) actually fullfil the property that needs support. (In "riscv64" we are using "G+C"="IMAFD+C" as baseline, so with the Float and Double extensions). The package is orphaned and under the umbrella of Science Team, so if anybody feels adventurous, please go and team-fix or NMU :) Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> --- a/src/utils.h +++ b/src/utils.h @@ -58,6 +58,7 @@ defined(__hppa__) || defined(__ia64__) || \ defined(__mips__) || \ defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) || \ +defined(__riscv) || \ defined(__sparc__) || defined(__sparc) || defined(__s390__) || \ defined(__SH4__) || defined(__alpha__) || \ defined(_MIPS_ARCH_MIPS32R2) || \ -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#892219: gmp: Please update symbols file for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: gmp Version: 2:6.1.2+dfsg-2 Severity: wishlist Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need changes in this package to bootstrap the riscv64 architecture, in particular we need an updated symbols file. I am attaching a patch that allowed me to compile the package. It would be great if you could include these changes and release a new version for unstable. If we can do something to speed-up this process, please let me/us know. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> --- ../libgmp10.symbols.orig2018-03-06 15:44:17.633015980 + +++ debian/libgmp10.symbols 2018-03-06 15:44:22.576939680 + @@ -215,7 +215,7 @@ (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1 __gmpn_add_n_sub_n@Base 2:5.1.1 (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1 - (arch=!hppa !mips !mipsel !m68k !nios2 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_add_nc@Base 0 + (arch=!hppa !mips !mipsel !m68k !nios2 !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_add_nc@Base 0 (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1 @@ -224,9 +224,9 @@ (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1 (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0 - (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0 + (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !riscv64 !sparc !sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0 (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh2_n@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh2_n@Base 0 (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1 (arch=any-amd64)__gmpn_addlsh_n@Base 0 __gmpn_addmul_1@Base 0 @@ -394,7 +394,7 @@ __gmpn_hgcd_reduce_itch@Base 2:5.1.1 __gmpn_hgcd_step@Base 2:5.1.1 __gmpn_invert@Base 0 - (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0 + (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !riscv64 !sparc !sparc64 !sh3 !sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0 __gmpn_invertappr@Base 0 __gmpn_ior_n@Base 0 __gmpn_iorn_n@Base 0 @@ -507,7 +507,7 @@ (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_mul_1c@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_mul_1c@Base 0 (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1 @@ -571,13 +571,13 @@ __gmpn_redc_n@Base 0 __gmpn_remove@Base 0 __gmpn_rootrem@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsblsh1_n@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsblsh2_n@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !ia64 !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsblsh_n@Base 0 - (arch=!alpha !arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsh1add_n@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !ia64 !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsh1add_nc@Base 0 - (arch=!alpha !arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsh1sub_n@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !ia64 !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsh1sub_nc@Base 0 + (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !riscv64 !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsblsh1_n@Base 0 + (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !p
Bug#881435: vtk6: Please move the build-depends on ftgl-dev to libftgl-dev
Source: vtk6 Version: 6.3.0+dfsg1-10 Severity: wishlist Control: block 878529 by -1 Hello, In order to be possible to drop the transitional package ftgl-dev, the packages depending on it have to migrate first. Please move the build-depends on ftgl-dev to libftgl-dev. Additionally, as per #750186, it seems that the build-dependency it's not even needed because the system-provided ftgl is not used, so maybe it can be dropped entirely. Cheers. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#851895: gmp: Please update symbols for sh3
Control: tags -1 + pending Hi, 2017-01-19 17:53 John Paul Adrian Glaubitz: Source: gmp Version: 2:6.1.2+dfsg-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi! We're currently adding sh3 as a new architecture to rebootstrap which allows to cross-bootstrap Debian for architectures. sh3 is an older architecture which is currently being redesigned as an open source CPU with the name J-Core. While cross-bootstrapping, the build stopped because the symbols for gmp need to be updated for sh3. This can be trivially achieved by globally replacing "!sh4" with "!sh3 !sh4" in libgmp10.symbols: $ sed -i 's/!sh4/!sh3 !sh4/g' debian/libgmp10.symbols I uploaded an NMU including this fix to delayed/10, please tell me if you want me to cancel it or, otherwise, you are OK and we can make it happen earlier. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog --- gmp-6.1.2+dfsg/debian/changelog 2016-12-21 06:39:47.0 +0100 +++ gmp-6.1.2+dfsg/debian/changelog 2017-09-29 02:22:49.0 +0200 @@ -1,3 +1,12 @@ +gmp (2:6.1.2+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Update symbols for nios2, thanks Helmut Grohne (Closes: #814671) + * Update symbols for tilegx, thanks Helmut Grohne (Closes: #850010) + * Update symbols for sh3, thanks Adrian Glaubitz (Closes: #851895) + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Fri, 29 Sep 2017 02:22:49 +0200 + gmp (2:6.1.2+dfsg-1) unstable; urgency=medium * New upstream. diff -Nru gmp-6.1.2+dfsg/debian/libgmp10.symbols gmp-6.1.2+dfsg/debian/libgmp10.symbols --- gmp-6.1.2+dfsg/debian/libgmp10.symbols 2015-11-17 12:07:24.0 +0100 +++ gmp-6.1.2+dfsg/debian/libgmp10.symbols 2017-09-29 01:58:27.0 +0200 @@ -215,7 +215,7 @@ (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1 __gmpn_add_n_sub_n@Base 2:5.1.1 (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1 - (arch=!hppa !mips !mipsel !m68k !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_add_nc@Base 0 + (arch=!hppa !mips !mipsel !m68k !nios2 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_add_nc@Base 0 (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1 @@ -224,9 +224,9 @@ (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1 (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0 - (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4)__gmpn_addlsh1_n@Base 0 + (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0 (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !s390x !sh4 !sparc !sparc64)__gmpn_addlsh2_n@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh2_n@Base 0 (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1 (arch=any-amd64)__gmpn_addlsh_n@Base 0 __gmpn_addmul_1@Base 0 @@ -394,7 +394,7 @@ __gmpn_hgcd_reduce_itch@Base 2:5.1.1 __gmpn_hgcd_step@Base 2:5.1.1 __gmpn_invert@Base 0 - (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4 !any-i386)__gmpn_invert_limb@Base 0 + (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0 __gmpn_invertappr@Base 0 __gmpn_ior_n@Base 0 __gmpn_iorn_n@Base 0 @@ -507,7 +507,7 @@ (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_mul_1c@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_mul_1c@Base 0 (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1 @@ -548,7 +548,7 @@ __gmpn_pow_1@Base 0 __gmpn_powlo@Base 0 __gmpn_powm@Base 0 - (arch=!m68k !ppc64 !ppc64el)__gmpn_preinv_divrem_1@Base 0 + (arch=!m68k !ppc64 !ppc64el !tilegx)__gmpn_preinv_divrem_1@Base 0 (arch=any-i386)__gmpn_preinv_divrem_1_atom_sse2@Base 2:5.1.1 (arch=any-i386)__gmpn_preinv_divrem_1_init@Base 2:5.1.1 (arch=any-i386)__gmpn_preinv_divrem_1_k7_mmx@Base 2:5.1.1 @@ -571,13 +571,13 @@ __gmpn_redc_n@Base 0 __gmpn_remove@Base 0 __gmpn_rootrem@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !sh4 !sparc !sparc64 !any-i386)__gmpn
Bug#814671: libgmp10: please update symbols for nios2
Control: tags -1 + pending 2016-02-13 21:56 Helmut Grohne: Source: gmp Version: 2:6.0.0+dfsg-6 Tags: patch User: helm...@debian.org Usertags: rebootstrap Dear gmp maintainer, gmp fails to build from source on nios2 (which is a new architecture from a Debian point of view). dpkg-gensymbols fails missing a lot of symbols. This is kinda expected for a new port. As it happens, nios2 behaves exactly the same as mips (and a few other architectures) from a gmp symbols point of view. Thus sed -i 's/!mips /!nios2 &/' debian/libgmp10.symbols can be used to make the gmp build succeed on nios2. Can you apply this fix? I uploaded an NMU including this fix to delayed/10, please tell me if you want me to cancel it or, otherwise, you are OK and we can make it happen earlier. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog --- gmp-6.1.2+dfsg/debian/changelog 2016-12-21 06:39:47.0 +0100 +++ gmp-6.1.2+dfsg/debian/changelog 2017-09-29 02:22:49.0 +0200 @@ -1,3 +1,12 @@ +gmp (2:6.1.2+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Update symbols for nios2, thanks Helmut Grohne (Closes: #814671) + * Update symbols for tilegx, thanks Helmut Grohne (Closes: #850010) + * Update symbols for sh3, thanks Adrian Glaubitz (Closes: #851895) + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Fri, 29 Sep 2017 02:22:49 +0200 + gmp (2:6.1.2+dfsg-1) unstable; urgency=medium * New upstream. diff -Nru gmp-6.1.2+dfsg/debian/libgmp10.symbols gmp-6.1.2+dfsg/debian/libgmp10.symbols --- gmp-6.1.2+dfsg/debian/libgmp10.symbols 2015-11-17 12:07:24.0 +0100 +++ gmp-6.1.2+dfsg/debian/libgmp10.symbols 2017-09-29 01:58:27.0 +0200 @@ -215,7 +215,7 @@ (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1 __gmpn_add_n_sub_n@Base 2:5.1.1 (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1 - (arch=!hppa !mips !mipsel !m68k !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_add_nc@Base 0 + (arch=!hppa !mips !mipsel !m68k !nios2 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_add_nc@Base 0 (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1 @@ -224,9 +224,9 @@ (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1 (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0 - (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4)__gmpn_addlsh1_n@Base 0 + (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0 (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !s390x !sh4 !sparc !sparc64)__gmpn_addlsh2_n@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh2_n@Base 0 (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1 (arch=any-amd64)__gmpn_addlsh_n@Base 0 __gmpn_addmul_1@Base 0 @@ -394,7 +394,7 @@ __gmpn_hgcd_reduce_itch@Base 2:5.1.1 __gmpn_hgcd_step@Base 2:5.1.1 __gmpn_invert@Base 0 - (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4 !any-i386)__gmpn_invert_limb@Base 0 + (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0 __gmpn_invertappr@Base 0 __gmpn_ior_n@Base 0 __gmpn_iorn_n@Base 0 @@ -507,7 +507,7 @@ (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_mul_1c@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_mul_1c@Base 0 (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1 @@ -548,7 +548,7 @@ __gmpn_pow_1@Base 0 __gmpn_powlo@Base 0 __gmpn_powm@Base 0 - (arch=!m68k !ppc64 !ppc64el)__gmpn_preinv_divrem_1@Base 0 + (arch=!m68k !ppc64 !ppc64el !tilegx)__gmpn_preinv_divrem_1@Base 0 (arch=any-i386)__gmpn_preinv_divrem_1_atom_sse2@Base 2:5.1.1 (arch=any-i386)__gmpn_preinv_divrem_1_init@Base 2:5.1.1 (arch=any-i386)__gmpn_preinv_divrem_1_k7_mmx@Base 2:5.1.1 @@ -571,13 +571,13 @@ __gmpn_redc_n@Base 0 __gmpn_remove@Base 0 __gmpn_rootrem@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !sh4 !sparc !sparc64 !any-i386)__gmpn_rsblsh1_n@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64
Bug#850010: libgmp10: please update symbols for tilegx
Control: tags -1 + pending Hi, 2017-01-03 07:28 Helmut Grohne: Package: libgmp10 Version: 2:6.1.2+dfsg-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Dear gmp maintainer, gmp fails to build from source on tilegx (which is a new architecture from a Debian point of view). dpkg-gensymbols fails missing a lot of symbols. This is kinda expected for a new port. As it happens, tilegx behaves exactly the same as m68k (and a few other architectures) from a gmp symbols point of view. Thus sed -i '/^ /s/!m68k /!tilegx &/' debian/libgmp10.symbols can be used to make the gmp build succeed on tilegx. Can you apply this fix? I uploaded an NMU including this fix to delayed/10, please tell me if you want me to cancel it or, otherwise, you are OK and we can make it happen earlier. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog --- gmp-6.1.2+dfsg/debian/changelog 2016-12-21 06:39:47.0 +0100 +++ gmp-6.1.2+dfsg/debian/changelog 2017-09-29 02:22:49.0 +0200 @@ -1,3 +1,12 @@ +gmp (2:6.1.2+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Update symbols for nios2, thanks Helmut Grohne (Closes: #814671) + * Update symbols for tilegx, thanks Helmut Grohne (Closes: #850010) + * Update symbols for sh3, thanks Adrian Glaubitz (Closes: #851895) + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Fri, 29 Sep 2017 02:22:49 +0200 + gmp (2:6.1.2+dfsg-1) unstable; urgency=medium * New upstream. diff -Nru gmp-6.1.2+dfsg/debian/libgmp10.symbols gmp-6.1.2+dfsg/debian/libgmp10.symbols --- gmp-6.1.2+dfsg/debian/libgmp10.symbols 2015-11-17 12:07:24.0 +0100 +++ gmp-6.1.2+dfsg/debian/libgmp10.symbols 2017-09-29 01:58:27.0 +0200 @@ -215,7 +215,7 @@ (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1 __gmpn_add_n_sub_n@Base 2:5.1.1 (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1 - (arch=!hppa !mips !mipsel !m68k !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_add_nc@Base 0 + (arch=!hppa !mips !mipsel !m68k !nios2 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_add_nc@Base 0 (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1 @@ -224,9 +224,9 @@ (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1 (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0 - (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4)__gmpn_addlsh1_n@Base 0 + (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0 (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !s390x !sh4 !sparc !sparc64)__gmpn_addlsh2_n@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh2_n@Base 0 (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1 (arch=any-amd64)__gmpn_addlsh_n@Base 0 __gmpn_addmul_1@Base 0 @@ -394,7 +394,7 @@ __gmpn_hgcd_reduce_itch@Base 2:5.1.1 __gmpn_hgcd_step@Base 2:5.1.1 __gmpn_invert@Base 0 - (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4 !any-i386)__gmpn_invert_limb@Base 0 + (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 !sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0 __gmpn_invertappr@Base 0 __gmpn_ior_n@Base 0 __gmpn_iorn_n@Base 0 @@ -507,7 +507,7 @@ (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1 - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_mul_1c@Base 0 + (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_mul_1c@Base 0 (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1 (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1 @@ -548,7 +548,7 @@ __gmpn_pow_1@Base 0 __gmpn_powlo@Base 0 __gmpn_powm@Base 0 - (arch=!m68k !ppc64 !ppc64el)__gmpn_preinv_divrem_1@Base 0 + (arch=!m68k !ppc64 !ppc64el !tilegx)__gmpn_preinv_divrem_1@Base 0 (arch=any-i386)__gmpn_preinv_divrem_1_atom_sse2@Base 2:5.1.1 (arch=any-i386)__gmpn_preinv_divrem_1_init@Base 2:5.1.1 (arch=any-i386)__gmpn_preinv_divrem_1_k7_mmx@Base 2:5.1.1 @@ -571,13 +571,13 @@ __gmpn_redc_n@Base 0 __gmpn_remove@Base 0 __gmpn_rootrem@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !powerpc !powerpcspe !sh4 !sparc !sparc64 !any-i386)__gmpn_rsblsh1_n@Base 0 - (arch=!alpha !arm64 !armel !armhf !hppa !mips
Bug#862256: libgmp3-dev is not Multi-Arch compatible
Hi, 2017-05-10 12:32 Francois Gouget: Package: libgmp3-dev Version: 2:6.1.2+dfsg-1 Severity: normal Dear Maintainer, There are still some packages that Depend and Build-Depend on libgmp3-dev. Unfortunately libgmp3-dev is not multiarch-aware which makes things harder than needed. The packages depending on libgmp3-dev should definitely be updated to depend on libgmp-dev but given that all libgmp3-dev does is pull libgmp-dev which is compatible with multiarch, it should be trivial to make libgmp3-dev multiarch-compatible too. To the maintainers: are you OK with an NMU for this? To François: would you please be able to provide a patch? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#849696: libogre-1.9.0v5: Ogre games abort on startup with “basic_string::_M_construct null not valid” / freeimage API issues
Hi,
2016-12-30 02:33 James Cowgill:
Control: severity -1 grave
Hi,
This is RC because nothing using ogre will start anymore.
On 29/12/16 21:52, Thibaut Girka wrote:
Package: libogre-1.9.0v5
Version: 1.9.0+dfsg1-7+b2
Severity: important
Any Ogre game/application (for instance, funguloids, available in Debian)
crashes with the following output:
Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
SceneManagerFactory for type 'DefaultSceneManager' registered.
Registering ResourceManager for type Material
Registering ResourceManager for type Mesh
Registering ResourceManager for type Skeleton
MovableObjectFactory for type 'ParticleSystem' registered.
ArchiveFactory for archive type FileSystem registered.
ArchiveFactory for archive type Zip registered.
ArchiveFactory for archive type EmbeddedZip registered.
DDS codec registering
FreeImage version: 3.17.0
This program uses FreeImage, a free, open source image library supporting all
common bitmap formats. See http://freeimage.sourceforge.net for details
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Abandon
This started happening since upgrading libfreeimage3, so this might be a bug in
it rather than in Ogre itself, but I haven't investigated any further yet.
This appears to be a regression in the Debian patch applied in
libfreeimage3 3.17.0+ds1-4.
Ogre contains this (OgreMain/src/OgreFreeImageCodec.cpp:98):
for (int i = 0; i < FreeImage_GetFIFCount(); ++i)
{
// Skip DDS codec since FreeImage does not have the option
// to keep DXT data compressed, we'll use our own codec
if ((FREE_IMAGE_FORMAT)i == FIF_DDS)
continue;
String exts(FreeImage_GetFIFExtensionList((FREE_IMAGE_FORMAT)i));
[loop body continues]
[String is typedefed to std::string]
This code assumes that FreeImage_GetFIFExtensionList will never return
NULL for values of i between 0 and FreeImage_GetFIFCount(). However in
the most recent Debian version of freeimage,
FreeImage_GetFIFExtensionList(27 / FIF_FAXG3) does return NULL.
It is unclear to me who is wrong here. The documentation does not
suggest anything about when FreeImage_GetFIFExtensionList can fail,
although the examples always check FreeImage_FIFSupportsReading before
calling it. Can any freeimage maintainer suggest the best way to fix this?
Thanks for the analysis.
The comment on the patch seems to add some light as to the cause of this
breakage:
https://anonscm.debian.org/cgit/debian-science/packages/freeimage.git/commit/?id=a67fe8c111d0de919b7a6710d4dd5efe05fbf380
++//allows adding a NULL node in order to not mess up plugin
++//numbering when some are disabled. Otherwise there will be a
++//discrepancy between FREE_IMAGE_FORMAT enumerator values and the
++//actual format.
++m_plugin_map[(const int)m_plugin_map.size()] = 0;
If freeimage plans to ship with this change and not revert it somehow,
the OGRE plugin for freeimage needs to check for the possibility of
having null nodes in this structure.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#723010: libgmp-dev: please reinstate lib64gmp-dev on ppc64
Hi, 2016-04-16 13:09 GMT+01:00 Bill Allombert <bill.allomb...@math.u-bordeaux.fr>: > unarchive 723010 > reopen 723010 > quit > On Sat, Mar 12, 2016 at 01:10:44PM +, Manuel A. Fernandez Montecelo wrote: > dd >> Version: 2:6.0.0+dfsg-4 >> Hi, > > Please always CC the submitter when closing a bug, thanks! Sorry, I thought that with the email sent by -done it was enough to get you notified -- that's what most people do it in the packages that I have close contact with. >> (bug triaging on the fly while looking at other things, sorry if not >> welcome...) >> >> 2013-09-15 12:19 Bill Allombert: >> >Package: libgmp-dev >> >Version: 2:5.1.2+dfsg-2 >> >Severity: wishlist >> > >> >Hello Steve, >> > >> >Please reinstate lib64gmp-dev on powerpc until ppc64 is an official Debian >> >distribution. And maybe the same for sparc/sparc64. Otherwise, there will >> >be >> >no ppc 64bit libgmp-dev for jessie since unofficial ports only carry sid. >> >> If not before, I think that this was fixed in version 2:6.0.0+dfsg-4 >> long ago. > > Hello Manuel, > > I cannot find this package in the archive: > %rmadison lib64gmp-dev > lib64gmp-dev | 2:5.0.5+dfsg-2 | oldstable | powerpc > so I assume this bug was not fixed. > Which is too bad beacuse the unofficial ppc64 port is not reliable > currently, which is especially important when using multiarch. (the following it's an explanation of my reasoning why I closed it, I don't have any stakes in this). I thought that the issue was "solved" in a way because 2:6.0.0+dfsg-4 doesn't provide any package named lib64gmp-dev or lib32gmp-dev (removed in 2:5.1.2+dfsg-3), neither for this architecture nor for any others, and because libgmp-dev has been built successfully in recent versions of the package for ppc64. At the time you submitted another bug #714998 against the package because "You can easily check on <http://packages.debian.org/sid/libgmp-dev> that there is no libgmp-dev packages for ppc64". There was, but due to a bug in the code generating the website, it didn't appear there (according to comments in that report). Since libgmp-dev in ppc64 is it's been working for years, I expected that the problem was indeed solved for you, and that you would be able to use ppc64's libgmp-dev for the speed gains, and that this bug just laid forgotten in the BTS. Sorry for all the mess. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#766748: gazebo: Please depend on ogre-1.9, 1.8 is obsolete and will be removed soon
Package: gazebo Version: 3.0.0+dfsg-1 Severity: normal Hi, This package was added recently to the archive, but depends on 1.8 (which is unsupported for more than a year) rather than 1.9, which has been in Debian unstable for a long time. I don't know if upstream fully supports 1.9 yet, but when it does, please switch. Cheers. -- Manuel -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
