Re: Fails to build at my side but works somewhere else
On Wed, Sep 23, 2020 at 08:08:01AM +0200, olivier sallou wrote: > > Given that you also have detailed knowledge in Java do you feel able > > to > > fix those 8 issues? That would really help several other packages. > > I had a look but could not fix. > Pierre, for info, I do my testing inside a debian sid docker container. > > Don't know if related to hdf5 related binding. Issue seems related to > deletion of files. > Some tests *pass* but seem not to delete created files (with > file.delete or file.deleteOnExit) as expected, leading to other tests > failure (where they test that library do not contain any file). > > I have no hdf5 knowledge. I do not know if deletion could be *delayed* > depending on machine/chroot/... and lead to test failure because file > is deleted *too late*... When reading this and considering that partly unreproducible results sometimes are happening due to parallelisation I'm wondering whether this could be an issue. I admit I can not really see from that Java command line whether the call is parallelized or not - but may be you can try to explicitly switch parallel processing off. Kind regards Andreas. -- http://fam-tille.de
Re: Join you
Hi, On Wed, Sep 23, 2020 at 03:23:33AM +0200, ود علم الهدي wrote: > Join you to help medical team working well Thanks a lot for your interest in Debian Med. Could you please be a bit more verbose about your skills and your intention to contribute in what field. Kind regards Andreas. -- http://fam-tille.de
[RFS] python-colormap
gbp clone --pristine-tar https://salsa.debian.org/med-team/python-colormap OR dcut dm --uid npatra...@gmail.com --allow python-colormap Thanks and Regards Nilesh
Re: [RFS] python-colormap
On Wed, Sep 23, 2020 at 03:43:48PM +0530, Nilesh Patra wrote: > dcut dm --uid npatra...@gmail.com --allow python-colormap Granted. Thanks for your work on this, Andreas. -- http://fam-tille.de
Re: Fails to build at my side but works somewhere else
Hi Olivier and Andreas, Le 23/09/2020 à 09:27, Andreas Tille a écrit : > On Wed, Sep 23, 2020 at 08:08:01AM +0200, olivier sallou wrote: >>> Given that you also have detailed knowledge in Java do you feel able >>> to >>> fix those 8 issues? That would really help several other packages. >> >> I had a look but could not fix. >> Pierre, for info, I do my testing inside a debian sid docker container. Thanks for telling me! >> >> Don't know if related to hdf5 related binding. Issue seems related to >> deletion of files. >> Some tests *pass* but seem not to delete created files (with >> file.delete or file.deleteOnExit) as expected, leading to other tests >> failure (where they test that library do not contain any file). >> >> I have no hdf5 knowledge. I do not know if deletion could be *delayed* >> depending on machine/chroot/... and lead to test failure because file >> is deleted *too late*... > > When reading this and considering that partly unreproducible results > sometimes are happening due to parallelisation I'm wondering whether > this could be an issue. I admit I can not really see from that Java > command line whether the call is parallelized or not - but may be you > can try to explicitly switch parallel processing off. > Thanks for the idea! Yet, gathering information about the test tool TestNG [0], I see that parallel threads are currently not used for the tests of libsis-jhdf5-java, as no "parallel" parameter is passed in debian/rules nor in sourceTest/java/tests.xml. By adding "-parallel tests -threadcount 4" to the TestNG call in debian/rules, I allow parallel testing but get no failing test. I will be going on investigating... > > Kind regards > > Andreas. > All the best, Pierre [0] https://testng.org/doc/documentation-main.html#running-testng
Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andreas,
Just to check if you got my previous mail.
Thanks!
Best
AndreiR
--- Forwarded message ---
From: Andrei Rozanski rozansk...@gmail.com
Date: September 21, 2020 09:56:40
Subject: Re: [MoM] ampl-netlib-solvers
To: debian-med@lists.debian.org
Hi Andreas,
Many thanks for reaching out and sorry for the delay in getting back to you.
I was reading and trying to understand a bit more of the whole process.
I guess some of the steps on packaging are still not clear to me.
I have added d/ampl-netlib-solvers.links as Aaron has kindly suggested
(thanks Aaron!). (commit 1d6f7cabaf956738f7e6b7adafa24e9b53d66746)
Thanks,
Best
AndreiR
On 9/21/20 9:03 AM, Andreas Tille wrote:
Hi Andrei,
is the task to rename the *.a file to lib*.a clear? Do you have
any problem with this. (If its just spare time issue at your side
that's fine. I'm just checking whether you need more help.)
Kind regards
Andreas.
On Wed, Sep 16, 2020 at 06:10:50AM +0200, Andreas Tille wrote:
On Tue, Sep 15, 2020 at 03:51:50PM -0400, Aaron M. Ucko wrote:
Andreas Tille writes:
I: ampl-netlib-solvers: unstripped-static-library
usr/lib/x86_64-linux-gnu/amplsolver.a(asldate.o)
[...]
I have not seen this info before but considering the size of
usr/lib/x86_64-linux-gnu/amplsolver.a I suspect all needed libraries
are statically linked which is what we do not want.
Not necessarily; the library may in fact simply be unstripped. In
particular, it looks like dh_strip covers static (*.a) libraries only
when their names start with the usual "lib" prefix. If you specifically
need an unprefixed name, I suppose it would work to install the library
as libamplsolver.a so that dh_strip will see it, and direct dh_link to
establish an unprefixed symlink. If you're using Debhelper level 13 or
higher, you can do so without touching debian/rules by simply listing
usr/lib/${DEB_HOST_MULTIARCH}/libamplsolver.a
usr/lib/${DEB_HOST_MULTIARCH}/amplsolver.a
in debian/ampl-netlib-solvers.links.
I admit that would have been my next suggestion to name the file lib*.a.
I did not expexted that this might solve the issue that the library
might be unstripped right now. Thanks a lot for the hint.
Making a shared version of this library might be a good idea regardless.
Definitely. It will be the next step.
Thanks a lot for your hints
Andreas.
--
http://fam-tille.de
Re: Autopkgtest failure with new version of kaptive - may be related to new version of biopython
Hi Aaron, Aaron M. Ucko, on 2020-09-20 22:13:59 -0400: > u...@debian.org (Aaron M. Ucko) writes: > > > No problem. It's too bad that unrelated changes in this release > > resulted in compilation errors on mips(64)el, but I do at least have > > ideas on how to fix them. > > 2.10.1-2 (uploaded a little while ago) should be good all around. It took a little while due to transient errors, but I can confirm test suites are working like a charm. Thanks for your efforts on these topics. Have a nice day, :) -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/4, please excuse my verbosity. signature.asc Description: PGP signature
Bug#963630: Aparapi license has changed to a more liberal license
Hi I noticed you had a conversation sometime back here: https://github.com/aparapi/aparapi/issues/50 I wanted to mention that Aparapi is no longer maintained at the address you specified and all developers, including the founder, have moved onto the new repository which is now active and well funded here: https://git.qoto.org/aparapi/aparapi During that port back in 2016 the license was reviewed by a paid lawyer hired by the new foundation and the license was legally changed. As our lawyer had assured us the original additional verbiage in the license for the original release of Aparapi did not functionally change the license in any way, it simply allowed AMD to protect themselves against any liability should the software be misused. The original added verbiage basically amounted to "You can not break the law when you exercise your rights under this license", which is already implied with an MIT license but not explicitly stated. As such we were able to legally and effectively relicense the software under the apache license and the new software is licensed wholly under the Apache license with no additional restrictions of any kind. You are free to repackage and redistribute the license exactly as you would under the Apache license. Let me know if you have any questions.
Bug#963630: Aparapi license has changed to a more liberal license
Glad to hear it. If you have any questions at all reach out to me anytime. I've been the package maintainer for some time. While I am not the founder I handle most of the day to day coding and project management and am in close contact with the original founder who is still a contributor and active participant but not as active as myself these days. So I try to handle any of the day to day issues that come up. Always happy to answer any questions if you need anything. On Wed, Sep 23, 2020 at 3:38 PM Andreas Tille wrote: > Dear Jeffrey, > > thanks a lot for the good news. We will package from the new location > for Debian then. > > Kind regards > > Andreas. > > On Wed, Sep 23, 2020 at 12:03:12PM -0400, Jeffrey Freeman wrote: > > Hi I noticed you had a conversation sometime back here: > > https://github.com/aparapi/aparapi/issues/50 > > > > I wanted to mention that Aparapi is no longer maintained at the address > you > > specified and all developers, including the founder, have moved onto the > > new repository which is now active and well funded here: > > https://git.qoto.org/aparapi/aparapi > > > > During that port back in 2016 the license was reviewed by a paid lawyer > > hired by the new foundation and the license was legally changed. As our > > lawyer had assured us the original additional verbiage in the license for > > the original release of Aparapi did not functionally change the license > in > > any way, it simply allowed AMD to protect themselves against any > liability > > should the software be misused. The original added verbiage basically > > amounted to "You can not break the law when you exercise your rights > under > > this license", which is already implied with an MIT license but not > > explicitly stated. > > > > As such we were able to legally and effectively relicense the software > > under the apache license and the new software is licensed wholly under > the > > Apache license with no additional restrictions of any kind. You are free > to > > repackage and redistribute the license exactly as you would under the > > Apache license. > > > > Let me know if you have any questions. > > -- > http://fam-tille.de >
