Re: [Help] Re: seqan autopkg test failures triggered by gcc-defaults
tags 966433 pending tags 966270 pending thanks I've got a fixed version of a release candidate of seqan3 3.0.2 in salsa. However it needs an updated range-v3 which has yet to be uploaded: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968053 I can upload the seqan3 3.0.2 release candidate with a code copy of the fixed range-v3, but as no packages build-depend on seqan3 I don't see the rush. Please feel free to correct my mis-understanding. On Thu, Aug 13, 2020 at 9:39 PM Andreas Tille wrote: > Hi folks, > > I tried to reproduce the issue. When I try to run the test in a chroot I > get: > > ... >Required dependency:Range-V3 found. > -- Required dependency:SDSL found. > -- Optional dependency:Cereal found. > -- Optional dependency:Lemon not found. > -- Optional dependency:ZLIB-1.2.11 found. > -- Optional dependency:BZip2-1.0.8 found. > -- Optional dependency:libexecinfo found. > -- SeqAn3 platform.hpp build: passed. > -- Found SeqAn3: /usr/include.. > CMake Error at > /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:104 (include): > include could not find load file: > > seqan3_test_component > Call Stack (most recent call first): > CMakeLists.txt:11 (include) > > > CMake Error at > /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:105 (include): > include could not find load file: > > seqan3_test_files > Call Stack (most recent call first): > CMakeLists.txt:11 (include) > > > CMake Error at > /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:106 (include): > include could not find load file: > > seqan3_require_ccache > Call Stack (most recent call first): > CMakeLists.txt:11 (include) > > > CMake Error at > /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:107 (include): > include could not find load file: > > seqan3_require_benchmark > Call Stack (most recent call first): > CMakeLists.txt:11 (include) > > > CMake Error at > /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:108 (include): > include could not find load file: > > seqan3_require_test > Call Stack (most recent call first): > CMakeLists.txt:11 (include) > > > CMake Error at > /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:109 (include): > include could not find load file: > > add_subdirectories > Call Stack (most recent call first): > CMakeLists.txt:11 (include) > > > CMake Error at CMakeLists.txt:32 (seqan3_require_ccache): > Unknown CMake command "seqan3_require_ccache". > > > -- Configuring incomplete, errors occurred! > See also > "/tmp/autopkgtest.olJ5KS/autopkgtest_tmp/build_unit/CMakeFiles/CMakeOutput.log". > See also > "/tmp/autopkgtest.olJ5KS/autopkgtest_tmp/build_unit/CMakeFiles/CMakeError.log". > > > For me this looks as if test/seqan3-test.cmake needs some patches. > > Kind regards > >Andreas. > > -- > http://fam-tille.de > -- Michael R. Crusoe
[RFS] scythe
gbp clone --pristine-tar https://salsa.debian.org/med-team/scythe OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and Regards Nilesh
Re: [RFS] scythe
On Fri, Aug 14, 2020 at 03:40:57PM +0530, Nilesh Patra wrote: > Grant DM access: PGP key fingerprint: > 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Granted. Thanks for your work on this, Andreas. -- http://fam-tille.de
Third Debian Med COVID-19 hackathon (August 16-22, 2020)
Dear Debian Community, Debian Med joined the virtual (online) [COVID-19 Biohackathon] from April 5-11 2020. We considered the outcome a great success in terms of the approached tasks, the new members we gained and the support of Debian infrastructure teams (namely the ftpmaster team). We tried to tie up to this success in a [second Debian Med hackathon] since COVID-19 is not over. The Debian Med team wants to do another week of hackathon as kind of "DebCamp effort". Thus our third sprint will be held from August 16th to August 22th 2020. A [recently shared pre-publication draft paper] highlights which software tools are considered useful "to Accelerate SARS-CoV-2 and Coronavirus Research". Many of these tools would benefit from being packaged in Debian and all the advantages that Debian brings for both users and upstream alike. As in the previous sprints most tasks do not require any knowledge of biology or medicine, and all types of contributions are welcome: bug triage, testing, documentation, CI, translations, packaging, and code contributions. 1. [Debian related bugs in COVID-19 related packages] 2. [COVID-19 related software that is awaiting packaging] please respond to the RFP with your intent so we don't duplicate work We also maintain some rough spreadsheet to assemble preconditions for [some frequently used workflows]. 3. You can also contribute directly to the upstream packages, linked from the [Debian Med COVID-19 task page]. Note: many biomedical software packages are quite resource limited, even compared to a typical FOSS project. Please be kind to the upstream author/maintainers and realize that they may have limited resources to review your contribution. Triaging open issues and opening pull requests to fix problems is likely to be more useful than nitpicking their coding style. 4. Architectures/porting: Please focus on amd64, as it is the primary architecture for biomedical software. A secondary tier would be arm64 / ppc64el / s390x (but beware the endian-related issues on s390x). From a free/open hardware perspective it would be great to see more riscv64 support, but that is not a priority right now 5. Python developers: The Debian Med team is also trying to [improve the availability of automated biomedical pipelines/workflows] using the Common Workflow Language open standard. The reference implementation of CWL is written in Python and there are many [open issues ready for work that don't require any biomedical background]. 6. It is very easy to contribute to Debian Med team. We have a lowNMU policy for all our packages. Merge requests on Salsa are usually processed quickly (but please ping some of the latest Uploaders of the package to make sure it will be noticed). Even better if you ask for membership to the team and push directly to the salsa repository. 7. The [debian-med-team-policy] should answer all questions how to contribute. 8. There is a [work-needed wiki] that will help keep track of who is working on which projects. 9. There is also a [NEW requests wiki] where we can request expedited NEW processing to support this effort. In the last sprint ftpmaster was picking from here with high priority. Thanks again for this. During the hackathon we will coordinate ourselves via the the Salsa coordination page, Debian Med mailing list and IRC: * https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/Covid-19-hackathon * https://lists.debian.org/debian-med/ * https://wiki.debian.org/IRC * irc://irc.debian.org/debian-med * https://jitsi.debian.social/DebianMedCovid19 on Monday 2020-08-17 and Friday 2020-08-21 as well as ad-hoc meetings if needed (in former sprints we did daily video meetings but it seems some kind of starting and ending meeting might be sufficient). Thanks in advance for considering to join our sprint. Sincerely Andreas Tille on behalf of the Debian Med team. [COVID-19 Biohackathon] https://github.com/virtual-biohackathons/covid-19-bh20 [second Debian Med hackathon] https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/2nd-Covid-19-Hackathon [recently shared pre-publication draft paper] https://doi.org/10.20944/preprints202005.0376.v1 [Debian related bugs in COVID-19 related packages] https://blends.debian.org/med/bugs/covid-19.html [COVID-19 related software that is awaiting packaging] https://blends.debian.org/med/tasks/covid-19 [some frequently used workflows] https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 [Debian Med COVID-19 task page] https://blends.debian.org/med/tasks/covid-19 [improve the availability of automated biomedical pipelines/workflows] https://doi.org/10.1007/s41019-017-0050-4 [open issues ready for work that don't require any biomedical background] https://github.com/common-workflow-language/cwltool/issues [debian-m
Re: Sepp has build issued (Was: semi-RFS: xenium - good enough for me (at the moment))
Hi Pranav,
Le 13/08/2020 à 10:14, Andreas Tille a écrit :
> Hi Pranav,
>
> On Thu, Aug 13, 2020 at 05:54:41AM +0530, Pranav Ballaney wrote:
>> Hi,
>> I was writing autopkgtests for busco and noticed that sepp is indeed a
>> dependency. I tried continuing the packaging work for sepp, and I found a
>> TODO in the changelog with the following:
>>
>> [javac] Note: Some input files use or override a deprecated API.
>> [javac] Note: Recompile with -Xlint:deprecation for details.
>> [javac] Note: Some input files use unchecked or unsafe operations.
>> [javac] Note: Recompile with -Xlint:unchecked for details.
>> [javac] Note: Some messages have been simplified; recompile with
>> -Xdiags:verbose to get full output
>> [javac] 3 errors
>> [javac] 5 warnings
>>
>> Is this because sun.java2d.SunGraphicsEnvironment API has been deprecated,
>> or is it just that it is missing a dependency so it can't import the API? I
>> don't know much about Java packages, but if someone could point me in the
>> right direction, I might be able to help.
>
> I admit I have no idea about those Java issues, but I've put Pierre
> Gruet in CC. If he can not help it might be sensible to ask at
> debian-j...@lists.debian.org.
>
I had not heard of this deprecation issue and I don't think it matters
for us. It only causes warnings.
Concerning the errors, they happen because JSONArray objects are passed
to an function that needs a sub-interface of Collection,
whereas JSONArray is a sub-interface of Collection. I have
written the patch json_collections.patch (enclosed), which solves the
errors by adding elements one by one instead of mistakingly calling a
global add function. I think this was the intent of upstream, but tell
me if you have build-time tests that fail.
The build can go on after using this patch.
Besides, I think you could use the other enclosed patch to build with a
more recent version of Java, this would suppress two other warnings.
Do not hesitate if you would like to discuss these issues more deeply.
Best regards,
Pierre
--- a/tools/merge/build.xml
+++ b/tools/merge/build.xml
@@ -29,7 +29,7 @@
-
+
--- a/tools/merge/src/phylolab/taxonamic/PPlacerJSONMerger.java
+++ b/tools/merge/src/phylolab/taxonamic/PPlacerJSONMerger.java
@@ -312,7 +312,9 @@
return name1.compareTo(name2);
}
});
- sortedPlacements.addAll(resultsPlacements);
+for (int i=0 ; i it=placements.iterator() ; it.hasNext() ;) {
+ sortedPlacements.add(it.next());
+}
double total = 0;
ArrayList < JSONArray > list = new ArrayList < JSONArray > ();
for (Iterator < JSONArray > itp = sortedPlacements.iterator(); threshold > total && itp.hasNext();) {
@@ -559,7 +561,9 @@
return name1.compareTo(name2);
}
});
- sortedPlacements.addAll(resultsPlacements);
+ for (int i=0 ; i
Re: Sepp has build issued (Was: semi-RFS: xenium - good enough for me (at the moment))
Hi Pierre,
On Fri, Aug 14, 2020 at 10:40:28PM +0200, Pierre Gruet wrote:
> I had not heard of this deprecation issue and I don't think it matters
> for us. It only causes warnings.
>
> Concerning the errors, they happen because JSONArray objects are passed
> to an function that needs a sub-interface of Collection,
> whereas JSONArray is a sub-interface of Collection. I have
> written the patch json_collections.patch (enclosed), which solves the
> errors by adding elements one by one instead of mistakingly calling a
> global add function. I think this was the intent of upstream, but tell
> me if you have build-time tests that fail.
> The build can go on after using this patch.
>
> Besides, I think you could use the other enclosed patch to build with a
> more recent version of Java, this would suppress two other warnings.
>
> Do not hesitate if you would like to discuss these issues more deeply.
I admit I love your explanation since it gives me a slight tiny bit of
understanding. In principle I'd prefer you commit those patches right
to Git for the very simple reason that our edit history has the correct
names of people who did the actual changes.
The Java part seems to build. Now I'm stumbling upon a strange
I: pybuild base:217: python3.8 setup.py config
Traceback (most recent call last):
File "setup.py", line 28, in
from setuptools import find_packages
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 8, in
import _distutils_hack.override # noqa: F401
ModuleNotFoundError: No module named '_distutils_hack'
E: pybuild pybuild:352: configure: plugin distutils failed with: exit code=1:
python3.8 setup.py config
dh_auto_configure: error: pybuild --configure -i python{version} -p 3.8
returned exit code 13
error - which needs to be investigated tomorrow (except somebody might
beat me which is always prefered).
Kind regards and thanks a lot for your Java patches
Andreas.
--
http://fam-tille.de
