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

[Hervé Pagès]

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 using 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 using r-project.org on behalf of khoran using 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
>>
>>      _______________________________________________
>>      Bioc-devel using r-project.org mailing list
>>      https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> _______________________________________________
>> Bioc-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
> 
> 

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.github using gmail.com