Changed-By: James Clarke
Description:
libgmp-dev - Multiprecision arithmetic library developers tools
libgmp10 - Multiprecision arithmetic library
libgmp10-doc - Multiprecision arithmetic library example code
libgmp3-dev - Multiprecision arithmetic library developers tools
libgmpxx4ldbl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 05 Feb 2018 12:29:49 +
Source: mpi-defaults
Binary: mpi-default-dev mpi-default-bin
Architecture: source
Version: 1.10
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team
Changed-By: James Clarke
On 10 Dec 2017, at 23:06, John Paul Adrian Glaubitz
wrote:
> On 12/11/2017 12:04 AM, James Clarke wrote:
>> Yeah, I noticed this back when I was uploading to experimental a few months
>> ago. I suspect it's an issue with qemu-user's atomics support on sh4, which
> On 10 Dec 2017, at 22:09, Aaron M. Ucko wrote:
>
> Source: polyml
> Version: 5.7.1-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> User: debian-sup...@lists.debian.org
> Usertags: sh4
>
> Builds of polyml 5.7.x for sh4
[Cc'ing David Matthews, upstream maintainer]
On 2 Nov 2017, at 10:27, Alan Modra wrote:
> On Sat, 28 Oct 2017 10:51:01 -0400 John David Anglin
> wrote:
>> Source: polyml
>> Version: 5.7
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> Build fails here:
>>
>> Making STRUCT_CONVERSIONALS
>> Cr
On 16 Oct 2017, at 11:08, Andreas Tille wrote:
> On Sun, Oct 15, 2017 at 08:21:46PM +0100, Rebecca N. Palmer wrote:
>>> raise nose.SkipTest("known failure of test_stata on non-little endian")
>>> E NameError: name 'nose' is not defined
>>
>> You need an 'import nose' first, if the test does
Source: h5py
Version: 2.7.0-1
Tags: upstream patch
Forwarded: https://github.com/h5py/h5py/pull/904
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Hi,
Currently h5py FTBFS on sparc64 (and has done for as long as sparc64 has
been building packages
Source: openblas
Version: 0.2.19-3
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Hi,
The upstream code supports 64-bit SPARC; please apply the attached
debdiff to enable the build.
Regards,
James
diff -Nru openblas-0.2.19/debian/cont
Source: reprozip
Version: 1.0.9-2
Tags: upstream patch
Hi,
Currently reprozip FTBFS in Ubuntu[1], which has switched to python3.6.
The failure is in the test suite:
> ==
> ERROR: test_combine (test_reprozip.TestCombine)
> ---
Source: reprozip
Version: 1.0.9-2
Severity: wishlist
Hi,
You disabled every architecture except amd64 and i386 as a result of
#862351, but upstream actually supports x32 too (I just successfully
built it in an x32 chroot). Please could you add x32 back to the list of
architectures?
Regards,
James
cessary, but is even more mind-boggling.
Regards,
James
Description: Fix FTBFS on non-Linux since stdin is not a constant
Author: James Clarke
Last-Update: 2017-03-07
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/mc_compact/readcgraph_l.h
+++ b/src/mc_compact
the
> binaries.
> If you are in doubt, don't hesitate to ask me or to the debian-mentors list :)
>
> $ dcut -k 92978A6E195E4921825F7FF0F34F09744E9F5DD9 ftp-master dm --uid "James
> Clarke" --allow polyml
> Uploading commands file to ftp.upload.debian.or
Added in
http://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=bb8f943a3b54332b65cf4a64644e9e8b57bdbdcf.
James
> On 12 Mar 2016, at 19:11, James Clarke wrote:
>
> Hi,
> It's in the debian-keyring git repo, but February's release was never
> uploaded t
in debian-keyring just
> ping me
> https://wiki.debian.org/DebianMaintainer
>
> cheers,
>
> G.
>
>
>
>
>
> Il Sabato 12 Marzo 2016 18:48, James Clarke ha scritto:
> Hi Gianfranco,
> I’m ready to release polyml 5.6-3, with the following changes:
>
warning on the
Hurd)
- source-date-epoch.diff: Use SOURCE_DATE_EPOCH instead of current time if
it is defined
- x32.diff: Add support for x32
-- James Clarke Sat, 12 Mar 2016 17:17:35 +
I don’t believe I yet have permission to upload polyml; could you please either
grant
> (I almost blindly trusted the upstream changes, I have no knowledge about the
> patches)
>
> cheers,
>
> Gianfranco
>
>
>
>
> Il Lunedì 1 Febbraio 2016 1:08, James Clarke ha scritto:
> Hi Gianfranco,
> I’ve backported some of upstream’s fixes (i
>
>
>
>
>
> Il Martedì 26 Gennaio 2016 10:12, James Clarke ha scritto:
> Hi Gianfranco,
> I have uploaded 5.6-1 to mentors; could you please review it?
>
> Thanks,
> James
>
>
>> On 25 Jan 2016, at 21:08, James Clarke wrote:
>>
>> O
Hi Gianfranco,
I have uploaded 5.6-1 to mentors; could you please review it?
Thanks,
James
> On 25 Jan 2016, at 21:08, James Clarke wrote:
>
> Ok, hopefully my s390x build will finish soon and I can then upload 5.6-1 to
> mentors including S/390 support (and thus, barring any
I think I'll trust your dsc file, but unfortunately I need to prior
> have one to test and double check/report back in case of issues.
>
> So if you have a dsc, please share, I think it will be fine!
>
> Cheers,
> G.
>
> Sent from Yahoo Mail on Android
>
> On Mo
iner, I trust your opinion after sponsoring 4
> times already the package!
>
> Cheers,
>
> Gianfranco
>
> Sent from Yahoo Mail on Android
>
> On Mon, 25 Jan, 2016 at 20:55, James Clarke
> wrote:
> Hi Gianfranco,
>
>
> >> I think it’s implemented i
Hi Gianfranco,
>> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are.
>> Should I get in touch with debian-arm?
>
> probably yes, even if I don't care there are much armel porters there...
>
> You might end up in asking ftpmaster to remove the armel binary.
Ok, I think I’
Hi,
>> Besides FE_UPWARD having a different value (given that it’s
>> platform-specific), armel calculates 1.0 / 3.0 as 0.15,
>> which is wrong for FE_UPWARD (but correct for FE_NEAREST), and I imagine
>> there are similar issues for the other rounding modes (other than
>> FE_NE
Hi Gianfranco,
>> That’s my guess. The test suite wasn’t run before I took over (I feared I
>> had stopped it running when I changed debian/rules to modern debhelper)
>> either, so who knows how long it’s been there.
>
> I don't find running testsuites there
> https://buildd.debian.org/status/l
Hi Gianfranco,
>> I quickly looked at the test
>> setRoundingMode(TO_POSINF);
>> check(getRoundingMode() = TO_POSINF);
>> val pos = 1.0/3.0;
>> check(pos * 3.0 > 1.0);
>> val neg = ~1.0/3.0;
>> check(neg * 3.0 > ~1.0);
>>
>>
>> well, I'm not sure the test is correct, I mean, you might have the e
> Hi,
>
>> Meant to say: I have one, though it’s running raspbian; would that mess with
>> things?
> not sure, I'm pretty sure the bug has always been there, just hidden because
> of a missing
> testsuite run…
That’s my guess. The test suite wasn’t run before I took over (I feared I had
stoppe
> On 25 Jan 2016, at 08:03, James Clarke wrote:
>
> Hi Gianfranco,
>
>>> Is there any way in which I could get access to an armel porter box to try
>>> and work out what’s causing the failure?
>>
>> as a normal contributor not, as a DM yes, after
Hi Gianfranco,
>> Is there any way in which I could get access to an armel porter box to try
>> and work out what’s causing the failure?
>
> as a normal contributor not, as a DM yes, after you requested the access, as
> a DD yes.
That was my guess.
> that said, I'm happy to test patches if yo
Hi Gianfranco,
>> I am aware s390x is failing. I have been trying to port it, and it no longer
>> segfaults (thanks to the pexport-endian.diff patch from upstream), but one
>> part of the >build step (the compiler bootstrapping itself) exits with code
>> 1, without printing anything. That’s on
Hi Gianfranco,
Is there any way in which I could get access to an armel porter box to try and
work out what’s causing the failure?
Thanks,
James
> On 24 Jan 2016, at 20:26, James Clarke wrote:
>
> I am aware s390x is failing. I have been trying to port it, and it no longer
&g
intainer, you are doing a good job here,
> you might even have direct upload privileges one day for this package :)
>
> Cheers,
>
> G.
> ----
> Dom 24/1/16, James Clarke ha scritto:
>
> Oggetto: Re: polyml 5.5.2-4
> A: "
chim for your work!"
>
> and then upload :)
>
> anyway, thanks to you both for your work, and James, keep up the nice work!
> (as you did in the last three uploads)
>
> cheers,
>
> Gianfranco
>
>
>
>
>
> Il Domenica 24 Gennaio 2016 20:38, James Clark
> thanks for your contribution to Debian!
>
> cheers,
>
> Gianfranco
>
>
>
>
>
> Il Domenica 24 Gennaio 2016 14:54, James Clarke ha
> scritto:
> Hi Gianfranco,
>
>> 1) you took over the package maintenance, can I see a post where the current
>>
Hi Gianfranco,
> 1) you took over the package maintenance, can I see a post where the current
> uploaders acked the change?
Please see the entirety of this thread in debian-science:
https://lists.debian.org/debian-science/2016/01/msg00035.html
> 2) a patch against testsuite not mentioned in ch
Hi Gianfranco (and Debian Science),
I have been working with upstream to port Poly/ML to additional architectures,
and have backported these changes. I have uploaded 5.5.2-4 to mentors; could
you please check it and then upload it?
Thanks,
James
signature.asc
Description: Message signed with
Great, thank you once again!
James
> On 22 Oct 2015, at 16:25, Gianfranco Costamagna
> wrote:
>
> Hi, yes, this is a false positive!
>
> anyway, Built&Signed&Uploaded thanks for your contribution to Debian!
>
> cheers,
>
> G.
signature.asc
Description: Message signed with OpenPGP using G
it.
James
> On 20 Oct 2015, at 23:09, James Clarke wrote:
>
> For some reason, mentors is giving a lintian error for
> "postinst-must-call-ldconfig”, although I have extracted the control
> information from the package and the contents of triggers is:
>
>> # Tr
sed to make lintian happy. Running lintian locally
does not give this error which makes this even stranger.
James
> On 20 Oct 2015, at 22:45, James Clarke wrote:
>
> Hi Gianfranco,
> I’ve updated the package to support arm64 using a patch from upstream, and
> uploaded it to mentors as
Hi Gianfranco,
I’ve updated the package to support arm64 using a patch from upstream, and
uploaded it to mentors as 5.5.2-3. Could you please check and upload it?
Thanks,
James
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
debian-science-maintainers mailing list
debi
Hi Edmund,
Thanks; there's a similar patch upstream
(https://github.com/polyml/polyml/commit/9d84a491c4ec5fa95c085ddcc8f9cca84bbea870),
so I’ll be using that, but it’s good to know that it builds with either. I
just need to set up an arm64 environment and check it functions correctly
before com
Hi Gianfranco,
>> I have uploaded 5.5.2-2 to mentors (and updated my git repository) enabling
>> all hardening flags. I also realised that the new polyc shell script
>> requires gcc and >libffi-dev to produce standalone executables, so I have
>> added those as dependencies for polyml.
>
> wond
Hi Gianfranco,
> I sponsored the package
Thank you again for all your help.
> (BTW I was intending to subscribe to debian-science, but also debian-devel is
> nice to be subscribed)
I have subscribed to debian-science as well.
> However, I would appreciate a fix for the following missing flags
bian-science/packages/polyml.git to
http://anonscm.debian.org/cgit/users/jrtc27-guest/polyml.git/ and pushed all my
changes there.
Thanks,
James Clarke
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.
Hi Gianfranco,
> On 15 Oct 2015, at 10:56, Gianfranco Costamagna
> wrote:
>
> Hi James
>
>
>> I have uploaded 5.5.2-1~rc2 to mentors.
>
>
>
> please call it 5.5.2-1 and nothing more :)
> you can push the same version many times on mentors with no problems.
Changed
>> 1) Do I need to send
Hi Gianfranco,
I have uploaded 5.5.2-1~rc2 to mentors.
1) Do I need to send a separate email to this then? I also filed #801793 for a
transition, but that has already been closed as unnecessary since there are no
rdeps.
2) Added
6) The compiler is indeed forcing your code to be linked against
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal
X-Debbugs-CC: debian-science-maintainers@lists.alioth.debian.org
The latest upstream version of polyml has bumped the soname up to 6.0.0
(upstream had 2, 3, 4 and 5, including some minor
It’s been almost a year since the last message in this thread, and nothing has
happened; Poly/ML 5.5.2 is still the latest version. Are any of the current
maintainers still able to maintain this?
James
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.or
46 matches
Mail list logo
