Re: [Help] Test failures in q2-feature-classifier
Hi Étienne On Wed, Jan 27, 2021 at 10:55:08PM +0100, Étienne Mollier wrote: > I would vote against skipping this test, as it shows the > underlying code is not functional. I reinforced a bit my patch, > given that the initial implementation was rather fragile and > pushed another iteration. I'm fine about `dch -r` the package > and upload tomorrow to close presently open bugs, if there are > no objections; I see I have DM permissions on this one. Ahhh, now you have DM permissions twice. I've checked the package and granted permissions without reading this until end. So feel free to upload (or ping me about doing so). > There is an ever growing breadcrumb of patches not forwarded > upstream behind me, I think I'll have to spend some time > forwarding them appropriately, at the end of the week hopefully. Cool. Kind regards Andreas. -- http://fam-tille.de
Re: Build time test failures for latest version of picard-tools
Le jeu. 28 janv. 2021 à 07:37, Andreas Tille a écrit :
> On Thu, Jan 28, 2021 at 06:52:23AM +0100, olivier sallou wrote:
> > Will have a look on this tomorrow. Is git repo up to date ?
>
> I think I can deal with it now thanks to Pierre's patch and hint.
>
Having a look, I indeed got gbp build failure due to removal of cleanup
step: find testdata -iname "*.bai" -exec rm {} \;
gbp was by the way not happy for file not being present
regarding other test failure with data provider error, there are already
several tests removed with patch 30-tests-fix-dataprovider.patch , this is
common issue at each release.
Olivier
>
> Kind regards
> Andreas.
>
> --
> http://fam-tille.de
>
Re: Build time test failures for latest version of picard-tools
On Thu, Jan 28, 2021 at 06:52:23AM +0100, olivier sallou wrote: > Will have a look on this tomorrow. Is git repo up to date ? I think I can deal with it now thanks to Pierre's patch and hint. Kind regards Andreas. -- http://fam-tille.de
Re: Build time test failures for latest version of picard-tools
Le mer. 27 janv. 2021 à 21:47, Andreas Tille a écrit : > Hi, > > I've tried to upgrade picard-tools in Git. Unfortunately (and > admittedly not unexpected) the build time tests are failing: > Not failing would indeed have been a surprise ;-) Will have a look on this tomorrow. Is git repo up to date ? Olivier > ... > Running Test: Test method > testForVcf(picard.vcf.processor.WidthLimitingDecoratorTest) > Gradle Test Executor 1 finished executing tests. > Results: FAILURE (4972 tests, 4970 successes, 2 failures, 0 skipped) > > 4972 tests completed, 2 failed > Finished generating test XML results (0.188 secs) into: > /build/picard-tools-2.24.1+dfsg/build/test-results/test > Generating HTML test report... > Finished generating test html results (0.191 secs) into: > /build/picard-tools-2.24.1+dfsg/build/reports/tests/test > :test FAILED > :test (Thread[Task worker for ':' Thread 2,5,main]) completed. Took 7 mins > 33.86 secs. > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':test'. > > There were failing tests. See the report at: > file:///build/picard-tools-2.24.1+dfsg/build/reports/tests/test/index.html > > * Try: > Run with --debug option to get more log output. Run with --scan to get > full insights. > > * Exception is: > org.gradle.api.tasks.TaskExecutionException: Execution failed for task > ':test'. > at > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100) > at > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70) > at > org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51) > at > org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62) > at > org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54) > at > org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60) > at > org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97) > at > org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87) > at > org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52) > at > org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) > at > org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54) > at > org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) > at > org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98) > at > org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626) > at > org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98) > at >
Re: Build time test failures for latest version of picard-tools
Hi Andreas, Le 27/01/2021 à 21:46, Andreas Tille a écrit : Hi, I've tried to upgrade picard-tools in Git. Unfortunately (and admittedly not unexpected) the build time tests are failing: ... Running Test: Test method testForVcf(picard.vcf.processor.WidthLimitingDecoratorTest) Gradle Test Executor 1 finished executing tests. Results: FAILURE (4972 tests, 4970 successes, 2 failures, 0 skipped) 4972 tests completed, 2 failed Finished generating test XML results (0.188 secs) into: /build/picard-tools-2.24.1+dfsg/build/test-results/test Generating HTML test report... Finished generating test html results (0.191 secs) into: /build/picard-tools-2.24.1+dfsg/build/reports/tests/test :test FAILED :test (Thread[Task worker for ':' Thread 2,5,main]) completed. Took 7 mins 33.86 secs. FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':test'. There were failing tests. See the report at: file:///build/picard-tools-2.24.1+dfsg/build/reports/tests/test/index.html * Try: Run with --debug option to get more log output. Run with --scan to get full insights. * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':test'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70) at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62) at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97) at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87) at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248) at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336) at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328) at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98) at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626) at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) at
Re: [Help] Test failures in q2-feature-classifier
Hi Andreas, Andreas Tille, on 2021-01-27 21:42:41 +0100: > I think, if the test might pass without this option we could go with > this or even remove those tests temporarily and discuss the issue with > upstream without pressure of an open RC bug (which is unrelated). I would vote against skipping this test, as it shows the underlying code is not functional. I reinforced a bit my patch, given that the initial implementation was rather fragile and pushed another iteration. I'm fine about `dch -r` the package and upload tomorrow to close presently open bugs, if there are no objections; I see I have DM permissions on this one. There is an ever growing breadcrumb of patches not forwarded upstream behind me, I think I'll have to spend some time forwarding them appropriately, at the end of the week hopefully. Have a good evening, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/0, please excuse my verbosity. signature.asc Description: PGP signature
Build time test failures for latest version of picard-tools
Hi, I've tried to upgrade picard-tools in Git. Unfortunately (and admittedly not unexpected) the build time tests are failing: ... Running Test: Test method testForVcf(picard.vcf.processor.WidthLimitingDecoratorTest) Gradle Test Executor 1 finished executing tests. Results: FAILURE (4972 tests, 4970 successes, 2 failures, 0 skipped) 4972 tests completed, 2 failed Finished generating test XML results (0.188 secs) into: /build/picard-tools-2.24.1+dfsg/build/test-results/test Generating HTML test report... Finished generating test html results (0.191 secs) into: /build/picard-tools-2.24.1+dfsg/build/reports/tests/test :test FAILED :test (Thread[Task worker for ':' Thread 2,5,main]) completed. Took 7 mins 33.86 secs. FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':test'. > There were failing tests. See the report at: > file:///build/picard-tools-2.24.1+dfsg/build/reports/tests/test/index.html * Try: Run with --debug option to get more log output. Run with --scan to get full insights. * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':test'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70) at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62) at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97) at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87) at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248) at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336) at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328) at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98) at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626) at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55) Caused by: org.gradle.api.GradleException: There
Re: [Help] Test failures in q2-feature-classifier
Hi Étienne, On Wed, Jan 27, 2021 at 07:58:51PM +0100, Étienne Mollier wrote: > > Your guess is right; setting the PYTHONPATH to the build > directory allows most tests to run. There were a couple of > tests which then still failed to execute with the following > symptom though: > > Command: vsearch --search_exact > /<>/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/data/se-dna-sequences.fasta > --id 0.8 --query_cov 0.8 --strand both --maxaccepts 10 --maxrejects 0 --db > /<>/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/data/se-dna-sequences.fasta > --threads 1 --output_no_hits --blast6out /tmp/tmpomuor76d > > - Captured stderr call > - > Fatal error: Invalid options to command search_exact > Invalid option(s): --id --maxaccepts --maxrejects --query_cov > The valid options for the search_exact command are: --alnout --biomout > --blast6out --bzip2_decompress --db --dbmask --dbmatched --dbnotmatched > --fasta_width --fastapairs --gzip_decompress --hardmask --log --match > --matched --maxhits --maxqsize --maxqt --maxseqlength --maxsizeratio --maxsl > --mincols --minqt --minseqlength --minsizeratio --minsl --mintsize --mismatch > --mothur_shared_out --no_progress --notmatched --notrunclabels --otutabout > --output_no_hits --qmask --quiet --relabel --relabel_keep --relabel_md5 > --relabel_self --relabel_sha1 --rowlen --samheader --samout --self --sizein > --sizeout --strand --threads --top_hits_only --uc --uc_allhits --userfields > --userout --xee --xsize > > I believe this is not caught by upstream because their CI seems > to stick to vsearch <= 2.7.0. I could devise a patch to remove > the use of invalid options with search_exact. It is sufficient > to enable the test suite to pass through and pushed changes to > Salsa[1]. However I am unsure whether just skipping invalid > options is the right way to go, or if there are some other > options that might need setting instead. Are there people at > ease with vsearch use around ? I think, if the test might pass without this option we could go with this or even remove those tests temporarily and discuss the issue with upstream without pressure of an open RC bug (which is unrelated). As always: Thanks a lot for your work on this Andreas. > [1] https://salsa.debian.org/med-team/q2-feature-classifier -- http://fam-tille.de
Re: [Help] Test failures in q2-feature-classifier
Hi Andreas, Andreas Tille, on 2021-01-23 08:09:20 +0100: > E ImportError: cannot import name 'feature_classifier' from > 'qiime2.plugins' (/usr/lib/python3/dist-packages/qiime2/plugins.py) > _ ERROR collecting > .pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_cutter.py _ > ... > > My guess is that this is some simple (PYTHON)PATH issue but I'm busy > with real life this weekend and it would be great to have another > RC bug off the table. Your guess is right; setting the PYTHONPATH to the build directory allows most tests to run. There were a couple of tests which then still failed to execute with the following symptom though: Command: vsearch --search_exact /<>/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/data/se-dna-sequences.fasta --id 0.8 --query_cov 0.8 --strand both --maxaccepts 10 --maxrejects 0 --db /<>/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/data/se-dna-sequences.fasta --threads 1 --output_no_hits --blast6out /tmp/tmpomuor76d - Captured stderr call - Fatal error: Invalid options to command search_exact Invalid option(s): --id --maxaccepts --maxrejects --query_cov The valid options for the search_exact command are: --alnout --biomout --blast6out --bzip2_decompress --db --dbmask --dbmatched --dbnotmatched --fasta_width --fastapairs --gzip_decompress --hardmask --log --match --matched --maxhits --maxqsize --maxqt --maxseqlength --maxsizeratio --maxsl --mincols --minqt --minseqlength --minsizeratio --minsl --mintsize --mismatch --mothur_shared_out --no_progress --notmatched --notrunclabels --otutabout --output_no_hits --qmask --quiet --relabel --relabel_keep --relabel_md5 --relabel_self --relabel_sha1 --rowlen --samheader --samout --self --sizein --sizeout --strand --threads --top_hits_only --uc --uc_allhits --userfields --userout --xee --xsize I believe this is not caught by upstream because their CI seems to stick to vsearch <= 2.7.0. I could devise a patch to remove the use of invalid options with search_exact. It is sufficient to enable the test suite to pass through and pushed changes to Salsa[1]. However I am unsure whether just skipping invalid options is the right way to go, or if there are some other options that might need setting instead. Are there people at ease with vsearch use around ? [1] https://salsa.debian.org/med-team/q2-feature-classifier Kind Regards, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Re: bedtools 2.29.2+dfsg-6
Hi John, John Marshall, on 2021-01-25 11:28:33 +: > Andreas Tille wrote: > > Sounds good. I think we should prefer this once the new version is > > available. > > FYI bedtools 2.30.0 was released over the weekend. Thanks for the notice, I had some spare cycles this afternoon to inline changes you suggested earlier and reduce the footprint of the bedtools package. The installed size reduced from 2583 kiB to 2109 kiB. After checking the reverse dependencies, I have uploaded the package. Also, Thanks for the forwarded patches! Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Re: Reminders about using SIMDe
Hi Michael On Wed, 27 Jan 2021 at 14:51, Michael R. Crusoe wrote: > Hello, > > After scheduling a binary rebuild[0] of packages using libsimde-dev > First off, thanks a lot for doing this! > I noticed that there are a few new packages using SIMDe (yay!) but aren't > listed on https://wiki.debian.org/SIMDEverywhere > It is at my end, I added simde support to plast, ngmlr and scrappie but completely missed adding them to the wiki, sorry about that. I actually wanted to know answers of a couple of questions before I open a PR for them upstream: * In the simde wiki, point no.3, it is written to remove -msse3, -march=native et al flags, however in a few PRs that you opened up, this[1] for example, I do not see this change it is however appended with a -D__SIM_SSE3 - does this allow the -msse3 flag to work well? And am I expected to do the same stuff in the upstream build system? * There is no need to add in arguments: "-DSIMDE_ENABLE_OPENMP -fopenmp-simd" into the upstream build system right? Just to be sure that I'm doing it the right way, could you please review the PR I sent for plast[2] (sent this PR last month)? (Building the upstream repository locally, it looked okay) I apologize if these questions might somehow sound stupid, but I do not know SIMDe's working well enough to take a judgement without being clear. [1]: https://github.com/stamatak/standard-RAxML/pull/50/files#diff-8bf5a567e3d917cc040b7bf12f499844b30961ed930b421b717d25039efdd94aR6 [2]: https://github.com/PLAST-software/plast-library/pull/8 Thanks a lot, Nilesh
Reminders about using SIMDe
Hello, After scheduling a binary rebuild[0] of packages using libsimde-dev I noticed that there are a few new packages using SIMDe (yay!) but aren't listed on https://wiki.debian.org/SIMDEverywhere Please do add them to the table and forward your patch upstream. For upstream, you may need to add a git submodule [1] or if only one #include of simde is needed, you can produce a single file using the amalgamate.py [2] script. If upstream already uses git submodules, then that is recommended. Packages that need adding to the table include - ngmlr - scrappie Thanks! [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980997 [1] https://github.com/simd-everywhere/simde-no-tests [2] https://github.com/simd-everywhere/simde/blob/master/amalgamate.py -- Michael R. Crusoe
Re: [RFS] libjsonp-java and pixelmed
Hi Pierre, On Wed, Jan 27, 2021 at 09:07:22AM +0100, Pierre Gruet wrote: > The last upstream version of libjsonp-java, uploaded to the archive 1 week > ago, had ABI changes which caused some packages to FTBFS. > > I have worked again on libjsonp-java to set the classpath of its two jars, > and also on its reverse dependency pixelmed to account for the ABI change. Thanks a lot for your work on this. > dcut dm --uid "Pierre Gruet" --allow libjsonp-java pixelmed Granted, Andreas. -- http://fam-tille.de
[RFS] libjsonp-java and pixelmed
Hi, The last upstream version of libjsonp-java, uploaded to the archive 1 week ago, had ABI changes which caused some packages to FTBFS. I have worked again on libjsonp-java to set the classpath of its two jars, and also on its reverse dependency pixelmed to account for the ABI change. Could you please either review them in Salsa or grant me DM rights? dcut dm --uid "Pierre Gruet" --allow libjsonp-java pixelmed Thanks a lot, Pierre
