[Bioc-devel] is it possible to disable i386 builds on bioconductor

Herve,

     I've backported openbabel3 from 20.04 to 18.04. You can download a
tarball with all the deb files in here:

http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz

Kevin

On 3/15/21 10:10 AM, Herv? Pag?s wrote:

Hi Thomas, Kevin,

We still need to install the system deps on the devel Windows builders
(riesling1 and tokay2). We'll do it this week. Thanks for the reminder
and for making the OpenBabel-3.0.0 Windows Binaries available on your
GitHub repo.

Note that OpenBabel 3 is installed on machv2 (devel macOS builders):

  machv2:~ biocbuild$ which obabel
  /usr/local/bin/obabel

  machv2:~ biocbuild$ obabel -V
  Open Babel 3.1.0 -- Oct 21 2020 -- 21:57:42

  machv2:~ biocbuild$ pkg-config --cflags openbabel-3
  -I/usr/local/Cellar/open-babel/3.1.1_1/include/openbabel3

  machv2:~ biocbuild$ pkg-config --libs openbabel-3
  -L/usr/local/Cellar/open-babel/3.1.1_1/lib -lopenbabel

In release: The reason ChemmineOB does not compile on malbec1 is
because it requires OpenBabel 3 but malbec1 only has OpenBabel 2 which
is what Ubuntu 18.04 comes with. OpenBabel 3 only became available
starting with Ubuntu 20.04.

To workaround this we could propagate the ChemmineOB_1.28.2.tar.gz
source tarball produced on nebbiolo1 (Ubuntu 20.04), or, if you know
an easy way to get OpenBabel 3 installed on an Ubuntu 18.04 system,
let us know and we will do that. The best thing would be to be able to
use a .deb package for this. The easiest the procedure, the more
likely people that are still using Ubuntu 18.04 will be able to
install ChemmineOB.

Best,
H.



On 3/12/21 11:10 AM, Thomas Girke wrote:

Dear Herv? and Martin,

It seems the above problem on the Windows builds has been resolved
for some
time now. However, any updates on Linux in the release branch are not
taking effect since some/all of the Openbabel dependencies are not
available on the corresponding Linux build system (here Ubuntu 18.04).
However, Ubuntu 20.04 seems to be fine but may not be used to create the
source download instance at the moment? As a result, the package is only
up-to-date for Windows and OSX (ChemmineOB_1.28.2.) but not Linux
(still at
ChemmineOB_1.28.0.tar.gz):
http://bioconductor.org/packages/release/bioc/html/ChemmineOB.html.
To fix
this, one suggestion would be whether the functional build from the
20.04
system could be pushed instead of 18.04? Not sure whether this is less
effort than installing the dependencies on 18.04 that may be
discontinued
soon - just a suggestion/question?

On the development branch the situation is opposite where the
dependencies are missing on Windows and OSX but Linux is fine:
http://bioconductor.org/checkResults/devel/bioc-LATEST/ChemmineOB/.

We realize that the dependencies of the ChemmineOB package creates extra
workload for the Bioc team, and we are extremely grateful for the
support
by the Bioc core team. Please let us know if there is anything on our
end
that could be done to resolve this and/or to minimize your workload
as much
as possible.

Thanks,

Thomas

On Mon, Feb 8, 2021 at 10:02 AM Martin Morgan <mtmorgan.bioc at gmail.com>
wrote:

It's likely failing because your package has C source code that
accesses
memory in an invalid way. Likely the bug is present on all
platforms, but
only apparent, for the tests you have written, on Windows. The right
thing
to do is to fix the bug, rather than avoid by not running on the
troublesome platform.

Under Linux you'd likely have success with valgrind or UBSAN; if you
were
reasonably confident that the package occurred in unit tests, and
you have
a script to run the unit tests run_tests.R then something like

   R -d valgrind -f run_tests.R

may be productive. valgrind is slow so it pays to narrow the problem
down
as much as possible.

Maartin

?On 2/8/21, 12:43 PM, "Bioc-devel on behalf of Kevin Horan" <
bioc-devel-bounces at r-project.org on behalf of khoran at cs.ucr.edu>

wrote:

          I have a package which randomly segfaults when running my
unit
     tests only on windows i386, but never on x64, or any other OS.
I can't
     imagine there are many out there still running i386 systems are
there?
     Is it possible to just disable the i386 build on bioconductor
so that
     the tests are not run on that architecture?

          I have of course done my best to debug the issue, but all
I get
is
     an error in some nt dll file, with no useful message or
location. I'm
I
     Linux guy, I don't know how to do the in-depth debugging that
would be
     required to track this bug down on windows. I tried disabling each
test
     one by one to see which one caused the crash, but as is typical
with
     segfaults, changing the setup can mask the bug even when the
bad code
is
     still be executed. Each test runs fine in isolation.

     Thanks

     Kevin