[Bioc-devel] is it possible to disable i386 builds on bioconductor
Hervé Pagès
hp@ge@@on@g|thub @end|ng |rom gm@||@com
Wed Mar 17 07:40:31 CET 2021
Hi Thomas, Kevin,
openbabel3 is now on malbec1 (Ubuntu 18.04). Kevin's
ubuntu_18.04_openbabel3_debs.tar.gz worked like a charm. Thanks for
making it so easy.
Note that this addition will affect ChemmineOB build/check results on
malbec1 on Thursday only:
https://bioconductor.org/checkResults/3.12/bioc-LATEST/ChemmineOB/malbec1-install.html
Cheers,
H.
On 3/16/21 10:24 AM, Hervé Pagès wrote:
> @Kevin: Thanks for providing openbabel3 for Ubuntu 18.04. Will take a
> look ASAP.
>
> @Thomas: Yes, the Ubuntu 18.04 builds are only used for the BioC 3.12
> builds (release). BioC 3.13 and further BioC releases are/will be using
> Ubuntu >= 20.04.
>
> Best,
> H.
>
>
> On 3/15/21 1:59 PM, Thomas Girke wrote:
>> Thanks Hervé for your help with this.
>>
>> Kevin has provided the *.deb package for installing OpenBabel 3.x on
>> Ubuntu 18.04. Just in case, below is how we usually install OpenBabel
>> 3.x.x across different Ubuntu/Debian systems.
>>
>> BTW: is it correct to assume that the Ubuntu 18.04 builds will be
>> discontinued in the next release in April?
>>
>> Thanks,
>>
>> Thomas
>>
>>
>> ## Install ChemmineOB with OpenBabel 3.x from source
>>
>> ## First uninstall libopenbabel-dev (which is version 2.x.x) if
>> already installed via
>> sudo apt-get remove libopenbabel-dev; sudo apt-get purge
>> libopenbabel-dev; sudo apt-get --purge autoremove libopenbabel-dev
>> ## Some dependencies to install
>> sudo apt install cmake libeigen3-dev libboost-all-dev
>> ## Clone OpenBabel 3.x.x from GitHub here:
>> https://github.com/openbabel/openbabel
>> <https://github.com/openbabel/openbabel>
>> git clone git using github.com:openbabel/openbabel.git
>> mkdir build; cd build
>> cmake ../openbabel
>> make
>> sudo make install
>> ## Install ChemmineOB where you provide environment variables
>> including header files and ChemmineOB package iprovided as *.tar.gz
>> (adjust paths if not correct)
>> R CMD INSTALL
>> --configure-args='--with-openbabel-include=/usr/local/include/openbabel3/
>> --with-openbabel-lib=/usr/local/lib/openbabel/3.1.1'
>> ChemmineOB_1.28.0.tar.gz
>>
>> On Mon, Mar 15, 2021 at 1:12 PM Kevin Horan <khoran using cs.ucr.edu
>> <mailto:khoran using cs.ucr.edu>> wrote:
>>
>> 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
>>
>> <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
>> <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/
>> <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 <mailto: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
>> <mailto:bioc-devel-bounces using r-project.org> on behalf of
>> khoran using cs.ucr.edu <mailto: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 <mailto:Bioc-devel using r-project.org>
>> mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> <https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>> >>> _______________________________________________
>> >>> Bioc-devel using r-project.org <mailto:Bioc-devel using r-project.org>
>> mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> <https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>> >>>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Thomas Girke, Ph.D.
>> Professor of Bioinformatics
>> 1207F Genomics Building
>> University of California
>> Riverside, CA 92521
>>
>> E-mail: thomas.girke using ucr.edu <mailto:thomas.girke using ucr.edu>
>> URL: https://girke.bioinformatics.ucr.edu
>> <https://girke.bioinformatics.ucr.edu>
>> Phone/Cell/Text: 951-732-7072
>> Fax: 951-827-4437
>
--
Hervé Pagès
Bioconductor Core Team
hpages.on.github using gmail.com
More information about the Bioc-devel
mailing list