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

[Kevin Horan]

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 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
>>>
>>
>>
>