Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Martin Grigorov]

Hi,

Yesterday there was another email about Biostrings -
https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
I thought it might be related to your problem.

Regards,
Martin

On Thu, Apr 25, 2024 at 8:23 AM Ulrich Bodenhofer <
ulrich.bodenho...@gmail.com> wrote:

> Dear colleagues, dear BioC core team,
>
> One of my packages in the devel branch, the ‘msa’ package seems broken
> since
> yesterday. The vignette does not run anymore (therefore, the package does
> not build), and the reason is that the BLOSUM62 substitution matrix cannot
> be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
> package. In Version 2.70.3 in the release branch, the substitution matrices
> were still in the ‘data/’ directory. In the current devel version 2.71.6,
> they have disappeared. I found no hint to that in the NEWS file. So, I want
> to kindly ask the maintainers of the ‘Biostrings’ package to give me some
> advice how to fix that on my side or, in case that this is an error in the
> current devel version of the ‘Biostrings’ package, to have a look into
> this.
>
> Thanks a lot in advance, best regards,
> Ulrich
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Incorrect warning about failing package built

[Martin Grigorov]

Hi,

The issue has been resolved by not using the system's Python installation.
I.e. on kunpeng2 RETICULATE_PYTHON env var is no longer exported! The
reticulate package installs its own Python:

> reticulate::py_config()
python: /home/biocbuild/.virtualenvs/r-reticulate/bin/python
libpython:  /usr/lib64/libpython3.9.so
pythonhome:
/home/biocbuild/.virtualenvs/r-reticulate:/home/biocbuild/.virtualenvs/r-reticulate
version:3.9.9 (main, Oct 18 2023, 18:17:13)  [GCC 10.3.1]
numpy:
 /home/biocbuild/.virtualenvs/r-reticulate/lib/python3.9/site-packages/numpy
numpy_version:  1.26.3

ReactomeGSA.data is installed on kunpeng2!

Regards,
Martin


On Mon, Feb 5, 2024 at 12:08 PM Martin Grigorov 
wrote:

> Hi again,
>
> I tried to find the problem by (un)installing any (pip) global
> installations of pandas, leidenalg, umap-learn, igraph and python-igraph,
> and then installing them with biocbuild's pip, i.e. non-root user, via
> reticulate but the error persists!
>
> Then I tried:
>
>  reticulate::py_module_available("numpy")
>
>  *** caught segfault ***
> address 0x90, cause 'memory not mapped'
>
> Traceback:
>  1: py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0", interactive(),
> numpy_load_error)
>  2: (function() {Sys.setenv(PYTHONPATH = newpythonpath)
>  on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
>  py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0", interactive(),
> numpy_load_error)})()
>  3: doTryCatch(return(expr), name, parentenv, handler)
>  4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
>  5: tryCatchList(expr, classes, parentenv, handlers)
>  6: tryCatch({oldpythonpath <- Sys.getenv("PYTHONPATH")
>  newpythonpath <- Sys.getenv("RETICULATE_PYTHONPATH", unset =
> paste(config$pythonpath, system.file("python", package =
> "reticulate"), sep = .Platform$path.sep))local({
>  Sys.setenv(PYTHONPATH = newpythonpath)
>  on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
>  py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0",
> interactive(), numpy_load_error)})}, error = function(e) {
>  Sys.setenv(PATH = oldpath)if (is.na(curr_session_env)) {
>  Sys.unsetenv("R_SESSION_INITIALIZED")}else {
>  Sys.setenv(R_SESSION_INITIALIZED = curr_session_env)}stop(e)})
>  7: initialize_python()
>  8: ensure_python_initialized(required_module = module)
>  9: import(module)
> 10: doTryCatch(return(expr), name, parentenv, handler)
> 11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 12: tryCatchList(expr, classes, parentenv, handlers)
> 13: tryCatch({import(module)TRUE}, error =
> clear_error_handler(FALSE))
> 14: reticulate::py_module_available("numpy")
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
>
> That is, reticulate::py_module_available("XYZ") always fails with a
> segfault.
>
> > sessionInfo()
> R Under development (unstable) (2024-01-16 r85812)
> Platform: aarch64-unknown-linux-gnu
> Running under: openEuler 22.03 (LTS-SP1)
>
> Matrix products: default
> BLAS/LAPACK: /usr/lib64/libopenblas-r0.3.18.so;  LAPACK version 3.9.0
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_GB  LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> time zone: UTC
> tzcode source: system (glibc)
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] reticulate_1.35.0
>
> loaded via a namespace (and not attached):
>  [1] compiler_4.4.0 Matrix_1.6-5   cli_3.6.2  tools_4.4.0
>  Rcpp_1.0.12
>  [6] grid_4.4.0 jsonlite_1.8.8 rlang_1.1.3png_0.1-8
>  lattice_0.22-5
>
> On Mon, Feb 5, 2024 at 9:39 AM Martin Grigorov 
> wrote:
>
>> Hi,
>>
>> Here is the issue - https://github.com/TomKellyGenetics/leiden/issues/26
>> I realized that we have discussed it a few months back!
>>
>> Martin
>>
>> On Sun, Feb 4, 2024 at 10:27 PM Martin Grigorov <
>> martin.grigo...@gmail.com> wrote:
>>
>>> Hi ,
>>>
>>> ReactomeGSA.data packag

Re: [Bioc-devel] Check time on macOS (MIRit)

[Martin Grigorov]

Hi Kasper,

According to
https://github.com/Bioconductor/BBS/blob/9ebb2cf20e70e4bebf24a2a824a67193de821b08/3.19/bioc-mac-arm64/kjohnson3/config.sh#L17-L20
the machine has 24 vCPUs.
The automatic/weekly build utilizes 12-16 out of those at any given time!
With the respective RAM and disk usage.

By "by hand" do you mean to run the build/check of a given package on a
"calm" machine ?
It would be expected that it will be faster if it has all/most resources
just for it.

Martin

On Wed, Feb 7, 2024 at 5:12 PM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> To be a bit more clear and vague at the same time: currently, some of our
> macOS builders exhibit weird slowdowns when the build system is run
> automatically compared to running builds "by hand". This is pretty weird,
> and hopefully we can figure out the cause and fix it. Specifically, builds
> on kjohnson3 is (at the moment) weirdly slow.
>
> Best,
> Kasper
>
> On Wed, Feb 7, 2024 at 7:24 AM Jacopo Ronchi 
> wrote:
>
> > Ok, understood. Thanks
> >
> > Il mer 7 feb 2024, 12:46 Vincent Carey  ha
> > scritto:
> >
> > > We need a bit of internal discussion before committing to this
> notion.  I
> > > will get back to the list on this.
> > >
> > > On Wed, Feb 7, 2024 at 6:34 AM Jacopo Ronchi 
> > > wrote:
> > >
> > >> Dear Vincent, thanks for your answer. So, at least for now, can I
> ignore
> > >> the warning on macOS for the submission of MIRit?
> > >>
> > >> Il mer 7 feb 2024, 12:26 Vincent Carey 
> ha
> > >> scritto:
> > >>
> > >>> Thanks Jacopo.  You shouldn't have to struggle.  We are aware of
> > >>> disparities of platform
> > >>> performance and are working to improve the build process.  It will
> take
> > >>> time.  I believe that
> > >>> achievement of acceptable timings on the linux platform should be the
> > >>> key goal at
> > >>> this time.
> > >>>
> > >>> On Wed, Feb 7, 2024 at 5:18 AM Jacopo Ronchi <
> jacopo.ron...@unimib.it>
> > >>> wrote:
> > >>>
> >  Dear developers,
> > 
> >  I am struggling to reduce R CMD check times for my package, MIRit,
> on
> >  macOS. The check on linux takes 4 minutes, while on macOS it needs
> > 9/10
> >  minutes. I have severely reduced the size of examples and tests,
> which
> >  now
> >  use smaller datasets and cached resources.
> > 
> >  On linux, unit tests require 30 seconds more or less, and examples
> 40
> >  seconds. On the other hand, macOS tests take 100 seconds, and 75 for
> > the
> >  examples. The issue is that sometimes the check runs in less than 10
> >  minutes, sometimes it needs a little bit more.
> > 
> >  However I am out of ideas on how to further reduce examples and
> > tests...
> >  The vignette is really extensive, but since SPB uses the
> > "--no-vignette"
> >  option this should not influence heavily on this behavior, at least
> to
> >  my
> >  understanding.
> > 
> >  Sorry for bothering you,
> >  Best regards,
> >  Jacopo
> > 
> >  [[alternative HTML version deleted]]
> > 
> >  ___
> >  Bioc-devel@r-project.org mailing list
> >  https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > 
> > >>>
> > >>> The information in this e-mail is intended only for the person to
> whom
> > >>> it is
> > >>> addressed. If you believe this e-mail was sent to you in error and
> the
> > >>> e-mail
> > >>> contains patient information, please contact the Partners Compliance
> > HelpLine
> > >>> at
> > >>> http://www.partners.org/complianceline . If the e-mail was sent to
> you
> > >>> in error
> > >>> but does not contain patient information, please contact the sender
> and
> > >>> properly
> > >>> dispose of the e-mail.
> > >>
> > >>
> > > The information in this e-mail is intended only for th...{{dropped:16}}
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
> --
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Incorrect warning about failing package built

[Martin Grigorov]

Hi again,

I tried to find the problem by (un)installing any (pip) global
installations of pandas, leidenalg, umap-learn, igraph and python-igraph,
and then installing them with biocbuild's pip, i.e. non-root user, via
reticulate but the error persists!

Then I tried:

 reticulate::py_module_available("numpy")

 *** caught segfault ***
address 0x90, cause 'memory not mapped'

Traceback:
 1: py_initialize(config$python, config$libpython, config$pythonhome,
config$virtualenv_activate, config$version >= "3.0", interactive(),
numpy_load_error)
 2: (function() {Sys.setenv(PYTHONPATH = newpythonpath)
 on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
 py_initialize(config$python, config$libpython, config$pythonhome,
config$virtualenv_activate, config$version >= "3.0", interactive(),
numpy_load_error)})()
 3: doTryCatch(return(expr), name, parentenv, handler)
 4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
 5: tryCatchList(expr, classes, parentenv, handlers)
 6: tryCatch({oldpythonpath <- Sys.getenv("PYTHONPATH")
 newpythonpath <- Sys.getenv("RETICULATE_PYTHONPATH", unset =
paste(config$pythonpath, system.file("python", package =
"reticulate"), sep = .Platform$path.sep))local({
 Sys.setenv(PYTHONPATH = newpythonpath)
 on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
 py_initialize(config$python, config$libpython, config$pythonhome,
config$virtualenv_activate, config$version >= "3.0",
interactive(), numpy_load_error)})}, error = function(e) {
 Sys.setenv(PATH = oldpath)if (is.na(curr_session_env)) {
 Sys.unsetenv("R_SESSION_INITIALIZED")}else {
 Sys.setenv(R_SESSION_INITIALIZED = curr_session_env)}stop(e)})
 7: initialize_python()
 8: ensure_python_initialized(required_module = module)
 9: import(module)
10: doTryCatch(return(expr), name, parentenv, handler)
11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
12: tryCatchList(expr, classes, parentenv, handlers)
13: tryCatch({import(module)TRUE}, error =
clear_error_handler(FALSE))
14: reticulate::py_module_available("numpy")

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

That is, reticulate::py_module_available("XYZ") always fails with a
segfault.

> sessionInfo()
R Under development (unstable) (2024-01-16 r85812)
Platform: aarch64-unknown-linux-gnu
Running under: openEuler 22.03 (LTS-SP1)

Matrix products: default
BLAS/LAPACK: /usr/lib64/libopenblas-r0.3.18.so;  LAPACK version 3.9.0

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_GB  LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

time zone: UTC
tzcode source: system (glibc)

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] reticulate_1.35.0

loaded via a namespace (and not attached):
 [1] compiler_4.4.0 Matrix_1.6-5   cli_3.6.2  tools_4.4.0
 Rcpp_1.0.12
 [6] grid_4.4.0 jsonlite_1.8.8 rlang_1.1.3png_0.1-8
 lattice_0.22-5

On Mon, Feb 5, 2024 at 9:39 AM Martin Grigorov 
wrote:

> Hi,
>
> Here is the issue - https://github.com/TomKellyGenetics/leiden/issues/26
> I realized that we have discussed it a few months back!
>
> Martin
>
> On Sun, Feb 4, 2024 at 10:27 PM Martin Grigorov 
> wrote:
>
>> Hi ,
>>
>> ReactomeGSA.data package fails to install because it depends on leiden
>> and Seurat
>>
>> > BiocManager::install("ReactomeGSA.data", force = TRUE)
>> Bioconductor version 3.19 (BiocManager 1.30.22), R Under development
>> (unstable)
>>   (2024-01-16 r85812)
>> Installing package(s) 'ReactomeGSA.data'
>> also installing the dependencies ‘leiden’, ‘Seurat’
>>
>> trying URL 'https://cloud.r-project.org/src/contrib/leiden_0.4.3.1.tar.gz
>> '
>> Content type 'application/x-gzip' length 2864241 bytes (2.7 MB)
>> ==
>> downloaded 2.7 MB
>>
>> trying URL 'https://cloud.r-project.org/src/contrib/Seurat_5.0.1.tar.gz'
>> Content type 'application/x-gzip' length 2225638 bytes (2.1 MB)
>> ==
>> downloaded 2.1 MB
>>
>> trying URL '
>> https://bioconductor.org/packages/3.19/data/experiment/src/contrib/ReactomeGSA.data_1.17.1.tar.gz
>> '
>> Content type 'application/x-gzip' length 24200519 bytes (23.1 MB)
>> ==
>> downloaded 23.1 MB
>>
>> * installing *source* 

Re: [Bioc-devel] Incorrect warning about failing package built

[Martin Grigorov]

Hi,

Here is the issue - https://github.com/TomKellyGenetics/leiden/issues/26
I realized that we have discussed it a few months back!

Martin

On Sun, Feb 4, 2024 at 10:27 PM Martin Grigorov 
wrote:

> Hi ,
>
> ReactomeGSA.data package fails to install because it depends on leiden and
> Seurat
>
> > BiocManager::install("ReactomeGSA.data", force = TRUE)
> Bioconductor version 3.19 (BiocManager 1.30.22), R Under development
> (unstable)
>   (2024-01-16 r85812)
> Installing package(s) 'ReactomeGSA.data'
> also installing the dependencies ‘leiden’, ‘Seurat’
>
> trying URL 'https://cloud.r-project.org/src/contrib/leiden_0.4.3.1.tar.gz'
> Content type 'application/x-gzip' length 2864241 bytes (2.7 MB)
> ==
> downloaded 2.7 MB
>
> trying URL 'https://cloud.r-project.org/src/contrib/Seurat_5.0.1.tar.gz'
> Content type 'application/x-gzip' length 2225638 bytes (2.1 MB)
> ==
> downloaded 2.1 MB
>
> trying URL '
> https://bioconductor.org/packages/3.19/data/experiment/src/contrib/ReactomeGSA.data_1.17.1.tar.gz
> '
> Content type 'application/x-gzip' length 24200519 bytes (23.1 MB)
> ==
> downloaded 23.1 MB
>
> * installing *source* package ‘leiden’ ...
> ** package ‘leiden’ successfully unpacked and MD5 sums checked
> ** using staged installation
> ** R
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded from temporary location
>
>  *** caught segfault ***
> address 0x90, cause 'memory not mapped'
>
> Traceback:
>  1: py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0", interactive(),
> numpy_load_error)
>  2: (function() {Sys.setenv(PYTHONPATH = newpythonpath)
>  on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
>  py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0", interactive(),
> numpy_load_error)})()
>  3: doTryCatch(return(expr), name, parentenv, handler)
>  4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
>  5: tryCatchList(expr, classes, parentenv, handlers)
>  6: tryCatch({oldpythonpath <- Sys.getenv("PYTHONPATH")
>  newpythonpath <- Sys.getenv("RETICULATE_PYTHONPATH", unset =
> paste(config$pythonpath, system.file("python", package =
> "reticulate"), sep = .Platform$path.sep))local({
>  Sys.setenv(PYTHONPATH = newpythonpath)
>  on.exit(Sys.setenv(PYTHONPATH = oldpythonpath), add = TRUE)
>  py_initialize(config$python, config$libpython, config$pythonhome,
> config$virtualenv_activate, config$version >= "3.0",
> interactive(), numpy_load_error)})}, error = function(e) {
>  Sys.setenv(PATH = oldpath)if (is.na(curr_session_env)) {
>  Sys.unsetenv("R_SESSION_INITIALIZED")}else {
>  Sys.setenv(R_SESSION_INITIALIZED = curr_session_env)}stop(e)})
>  7: initialize_python()
>  8: ensure_python_initialized(required_module = module)
>  9: import(module)
> 10: doTryCatch(return(expr), name, parentenv, handler)
> 11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 12: tryCatchList(expr, classes, parentenv, handlers)
> 13: tryCatch({import(module)TRUE}, error =
> clear_error_handler(FALSE))
> 14: reticulate::py_module_available("pandas")
> 15: fun(libname, pkgname)
> 16: doTryCatch(return(expr), name, parentenv, handler)
> 17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 18: tryCatchList(expr, classes, parentenv, handlers)
> 19: tryCatch(fun(libname, pkgname), error = identity)
> 20: runHook(".onAttach", ns, dirname(nspath), nsname)
> 21: attachNamespace(ns, pos = pos, deps, exclude, include.only)
> 22: doTryCatch(return(expr), name, parentenv, handler)
> 23: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 24: tryCatchList(expr, classes, parentenv, handlers)
> 25: tryCatch({attr(package, "LibPath") <- which.lib.locns <-
> loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos,
> deps, exclude, include.only)}, error = function(e) {P <- if
> (!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L])
>  else ""msg <- gettextf("package or namespace load failed for %s%s:\n
> %s", sQuote(package), P, conditionMessage(e))if (logical.return
> && !quietly) message

Re: [Bioc-devel] Incorrect warning about failing package built

[Martin Grigorov]

)) {if (identical(call[[1L]], quote(doTryCatch)))
call <- sys.call(-4L)dcall <- deparse(call, nlines = 1L)
 prefix <- paste("Error in", dcall, ": ")LONG <- 75Lsm
<- strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall,
type = "w") + nchar(sm[1L], type = "w")if (is.na(w)) w
<- 14L + nchar(dcall, type = "b") + nchar(sm[1L], type =
"b")if (w > LONG) prefix <- paste0(prefix, "\n  ")}
   else prefix <- "Error : "msg <- paste0(prefix, conditionMessage(e),
"\n").Internal(seterrmessage(msg[1L]))if (!silent &&
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile)
   .Internal(printDeferredWarnings())}invisible(structure(msg,
class = "try-error", condition = e))})
33: try(suppressPackageStartupMessages(library(pkg_name, lib.loc = lib,
character.only = TRUE, logical.return = TRUE)))
34: tools:::.test_load_package("leiden",
"/home/biocbuild/R/R-devel_2024-01-16_r85812/site-library/00LOCK-leiden/00new")
An irrecoverable exception occurred. R is aborting now ...
ERROR: loading failed
* removing ‘/home/biocbuild/R/R-devel_2024-01-16_r85812/site-library/leiden’
ERROR: dependency ‘leiden’ is not available for package ‘Seurat’
* removing ‘/home/biocbuild/R/R-devel_2024-01-16_r85812/site-library/Seurat’
ERROR: dependency ‘Seurat’ is not available for package ‘ReactomeGSA.data’
* removing
‘/home/biocbuild/R/R-devel_2024-01-16_r85812/site-library/ReactomeGSA.data’

The downloaded source packages are in
‘/home/biocbuild/tmp/RtmpjFiqDm/downloaded_packages’
Warning messages:
1: In install.packages(...) :
  installation of package ‘leiden’ had non-zero exit status
2: In install.packages(...) :
  installation of package ‘Seurat’ had non-zero exit status
3: In install.packages(...) :
  installation of package ‘ReactomeGSA.data’ had non-zero exit status

Any hints on what is the problem ?

Martin

On Fri, Feb 2, 2024 at 9:52 AM Griss Johannes <
johannes.gr...@meduniwien.ac.at> wrote:

> Dear Hervé,
>
> Thanks a lot for the explanation and clarification! Issue should be fixed
> by now.
>
> Kind regards,
>
> Johannes
>
>
> Am 2024-02-02 01:37, schrieb Hervé Pagès:
>
> Just to clarify: we build the vignettes on all platforms, via 'R CMD
> build'. However when a package contains more than one vignette like here,
> keep in mind that 'R CMD build' evaluates them all in the same R session.
> This "feature" can help a vignette succeed even if it's broken. For example
> if ReactomeGSA got loaded by a previous vignette then evaluation of
> reanalysing-public-data.Rmd would still succeed even though it doesn't do
> 'library(ReactomeGSA)'.
>
> To complicate things even more, it could be that the order in which
> vignettes are evaluated is platform-dependent. This could explain why a
> vignette succeeds on one platform and not the other.
>
> Best,
>
> H.
>
>
> On 2/1/24 13:30, Johannes Griss wrote:
>
> Hi,
>
> Thanks a lot for the quick reply!
>
> Vignette is already fixed and committed.
>
> Kind regards,
> Johannes
>
> On 01.02.24 22:24, Martin Grigorov wrote:
>
> Hi,
>
> On Thu, 1 Feb 2024 at 23:05, Jennifer Wokaty  <mailto:jennifer.wok...@sph.cuny.edu> >
> wrote:
>
> Hi Johannes,
>
> Looking at R CMD Check on devel, it looks like you're missing a
> `library(ReactomeGSA)` in reanalysing-public-data.Rmd, which is why
> it doesn't find the function `get_public_species()`. We only build
> the vignettes on the Linux builders, which this error is only caught
> there.
>
> Regarding the error kunpeng2, we could ask its maintainer to install
> ReactomeGSA.data, which appears to be missing. If this happens
> again, you can reach out to Martin on the Bioc Community Slack
> channel #arm-linux. He's very active and responsive.
>
>
> I will take a look early next week!
>
> Martin
>
>
>
> Lastly, regarding the notification that happened on the 2024/01/08,
> it's possible that it failed due to an issue with another package at
> that time which has since been resolved.
>
>
> Jennifer Wokaty (they/them)
>
> Waldron Lab at CUNY SPH
> Bioconductor Core Team
> 
> From: Bioc-devel  <mailto:bioc-devel-boun...@r-project.org>
> > on behalf of Johannes
> Griss  <mailto:johannes.gr...@meduniwien.ac.at>
> >
> Sent: Thursday, February 1, 2024 3:18 PM
> To: bioc-devel@r-project.org <mailto:bioc-devel@r-project.org>

Re: [Bioc-devel] Incorrect warning about failing package built

[Martin Grigorov]

Hi,

On Thu, 1 Feb 2024 at 23:05, Jennifer Wokaty 
wrote:

> Hi Johannes,
>
> Looking at R CMD Check on devel, it looks like you're missing a
> `library(ReactomeGSA)` in reanalysing-public-data.Rmd, which is why it
> doesn't find the function `get_public_species()`. We only build the
> vignettes on the Linux builders, which this error is only caught there.
>
> Regarding the error kunpeng2, we could ask its maintainer to install
> ReactomeGSA.data, which appears to be missing. If this happens again, you
> can reach out to Martin on the Bioc Community Slack channel #arm-linux.
> He's very active and responsive.


I will take a look early next week!

Martin


>
> Lastly, regarding the notification that happened on the 2024/01/08, it's
> possible that it failed due to an issue with another package at that time
> which has since been resolved.
>
>
> Jennifer Wokaty (they/them)
>
> Waldron Lab at CUNY SPH
> Bioconductor Core Team
> 
> From: Bioc-devel  on behalf of Johannes
> Griss 
> Sent: Thursday, February 1, 2024 3:18 PM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] Incorrect warning about failing package built
>
> * This email originates from a sender outside of CUNY. Verify the sender
> before replying or clicking on links and attachments. *
>
> Hello,
>
> I just received a second warning the our package ReactomeGSA is failing
> in both release and devel on all platforms.
>
> Quickly checking the respective reports shows that this is not the case:
>
>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fbioconductor.org%2FcheckResults%2Frelease%2Fbioc-LATEST%2FReactomeGSA%2F__%3B!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0e-zXx6o%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C0e7c021440214cf1ba5708dc2362f85a%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638424155200958363%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=tbYEx3lk0V%2BBLNUdbLHtclDpeGm9sq5W7Tv9lK%2BnNx8%3D=0
> <
> https://urldefense.com/v3/__https://bioconductor.org/checkResults/release/bioc-LATEST/ReactomeGSA/__;!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0e-zXx6o$
> >
>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2FReactomeGSA%2F__%3B!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0rnxJ23U%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C0e7c021440214cf1ba5708dc2362f85a%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638424155200973059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=EZnvSQ0zSzlNuW5DocjOsROuDVk6e7GH0Hg%2ByRnhdwQ%3D=0
> <
> https://urldefense.com/v3/__https://bioconductor.org/checkResults/devel/bioc-LATEST/ReactomeGSA/__;!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0rnxJ23U$
> >
>
> On release we have no errors or warnings at all, on devel, everything is
> fine in two instances while the others seem to have issues that we will
> look into.
>
> Is there anything I can do to fix that?
>
> Kind regards,
> Johannes
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel__%3B!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0ArxoE98%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C0e7c021440214cf1ba5708dc2362f85a%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638424155200977608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=0x4xNPvAHnkGyUcEz4PVIOM8eCVTEWNpNUOkskspUEQ%3D=0
> <
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0ArxoE98$
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] build reports for apple silicon

[Martin Grigorov]

Hi,

https://bioconductor.org/checkResults/3.19/bioc-mac-arm64-LATEST/

Regards,
Martin

On Wed, Jan 24, 2024 at 5:55 PM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> We're clearly producing binary builds for Apple Silicon. Why do we not have
> a build report for this platform?
>
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Workflow package build all OK but no vignette and red Package propagation status LED

[Martin Grigorov]

Hi,

If you hover over the red LED you will see the following hint: NO, package
depends on 'miRBaseConverter' which is not available"

Regards,
Martin

On Mon, Nov 13, 2023 at 11:31 AM James Perkins  wrote:

> Hi,
>
> I am the maintainer of the Workflow package ExpHunterSuite.
>
> In the build report for the release branch, 3.18, my build and install
> status are green-OK.
>
> However, I have a red LED for Package Propagation. How can I tell what's
> gone wrong, and how could I fix it?
>
> https://bioconductor.org/checkResults/3.18/workflows-LATEST/ExpHunterSuite/
>
> I've had a look through the documentation and the nearest I've found
> was: "propagation is still determined by the results of the nightly
> builds." - but I cannot find/workout the relevant section in the output
> of the nightly build report that is related to propagation status.
>
> The landing page of the package is not showing the documentation
> (vignette etc.), or letting me download the package source.
>
> https://bioconductor.org/packages/3.18/workflows/html/ExpHunterSuite.html
>
> I suspect this is related, because the devel version of the package IS
> showing blue propagation status, and IS showing the
> documentation/package source etc.
>
> https://bioconductor.org/packages/3.19/workflows/html/ExpHunterSuite.html
>
> Cheers!
>
> Jim
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] atena build error on kunpeng2 Linux openEuler 22.03 LTS-SP1 / aarch64

[Martin Grigorov]

Hi,

>  quickBamFlagSummary(eh[["EH8081"]])
see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
documentation
loading from cache
[E::hts_hopen] Failed to open file
/home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133
[E::hts_open_format] Failed to open file
"/home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133" : Exec format
error
Error in value[[3L]](cond) :
  failed to open BamFile: failed to open SAM/BAM file
  file: '/home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133'
>  eh[["EH8081", force=TRUE]]
see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
documentation
downloading 2 resources
retrieving 2 resources
  |==|
100%

  |==|
100%

loading from cache
class: BamFile
path: /home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133
index: /home/biocbuild/.cache/R/ExperimentHub/1d1f2d19075fb4_8134
isOpen: FALSE
yieldSize: NA
obeyQname: FALSE
asMates: FALSE
qnamePrefixEnd: NA
qnameSuffixStart: NA
>  quickBamFlagSummary(eh[["EH8081"]])
see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
documentation
loading from cache
[E::idx_find_and_load] Could not retrieve index file for
'/home/biocbuild/.cache/R/ExperimentHub/1d1f2d19075fb4_8134'
group |nb of |nb of | mean / max
   of |  records |   unique | records per
  records | in group |   QNAMEs | unique QNAME
All records A |   215602 |   10 | 2.16 / 20
  o template has single segment S |0 |0 |   NA / NA
  o template has multiple segments. M |   215602 |   10 | 2.16 / 20
  - first segment.. F |   107801 |   10 | 1.08 / 10
  - last segment... L |   107801 |   10 | 1.08 / 10
  - other segment.. O |0 |0 |   NA / NA

Note that (S, M) is a partitioning of A, and (F, L, O) is a partitioning of
M.
Indentation reflects this.

Details for group M:
  o record is mapped.. M1 |   215602 |   10 | 2.16 / 20
  - primary alignment. M2 |   20 |   10 |2 / 2
  - secondary alignment... M3 |15602 | 4085 | 3.82 / 18
  o record is unmapped M4 |0 |0 |   NA / NA

Details for group F:
  o record is mapped.. F1 |   107801 |   10 | 1.08 / 10
  - primary alignment. F2 |   10 |   10 |1 / 1
  - secondary alignment... F3 | 7801 | 4085 | 1.91 / 9
  o record is unmapped F4 |0 |0 |   NA / NA

Details for group L:
  o record is mapped.. L1 |   107801 |   10 | 1.08 / 10
  - primary alignment. L2 |   10 |   10 |1 / 1
  - secondary alignment... L3 | 7801 | 4085 | 1.91 / 9
  o record is unmapped L4 |0 |0 |   NA / NA


Looks good ?

Regards,
Martin


On Mon, Oct 23, 2023 at 7:26 PM Hervé Pagès 
wrote:

> Hi Robert,
>
> There's the possibility that some of these BAM files got corrupted when
> downloaded to kunpeng2 local cache.
>
> @Martin Gregorov: Would you be able to try to run the following on
> kunpeng2?
>
>  library(Rsamtools)
>  library(ExperimentHub)
>  eh <- ExperimentHub()
>  quickBamFlagSummary(eh[["EH8081"]])
>
> If you get an error that the file cannot be opened, then maybe try to
> re-download it with:
>
>  eh[["EH8081", force=TRUE]]
>
> Then try quickBamFlagSummary(eh[["EH8081"]]) again and hopefully it will
> work.
>
> Thanks,
>
> H.
>
> On 10/23/23 08:03, Robert Castelo wrote:
> > hi,
> >
> > our package atena fails to build **only** in kunpeng2 Linux openEuler
> > 22.03 LTS-SP1 / aarch64:
> >
> >
> https://bioconductor.org/checkResults/3.18/bioc-LATEST/gDNAx/kunpeng2-buildsrc.html
> >
> >
> > concretely, the vignette fails to find a BAM file downloaded via
> > ExperimentHub. This does not happen in any of the other platforms.
> > Should we do anything about this?
> >
> > Thanks!
> >
> > robert.
> >
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Build error for CaDrA package on kunpeng2 Linux machine

[Martin Grigorov]

Hi Reina,

I tried to debug it but without success!
I think the problem is at
https://code.bioconductor.org/browse/CaDrA/blob/devel/src/score_fun.c#L613
because it fails only with method = "ks_score"
It does a lot of calculations with doubles and I am almost sure FMA [1] is
to blame.
You could try to replace the "manual" calculations with fma() [2] or
disable it at compile time

1. https://accurate-algorithms.readthedocs.io/en/latest/ch03fma.html
2. https://www.oreilly.com/library/view/c-in-a/0596006977/re80.html

Martin

On Thu, Oct 19, 2023 at 4:49 PM Chau, Reina  wrote:

> Hi Martin,
>
> Yes, I removed that specified test case that failed the check in order to
> meet Bioconductor 3.18 release deadline.
>
> Thanks again for looking into this!
>
> Best,
>
> Reina C.
>
> On Oct 19, 2023, at 4:20 AM, Martin Grigorov 
> wrote:
>
> Hello Reina,
>
> The checks pass now after your last commit:
>
> ```
> ...
> * checking for unstated dependencies in ‘tests’ ... OK
> * checking tests ...
>   Running ‘testthat.R’
>  OK
> * checking for unstated dependencies in vignettes ... OK
> * checking package vignettes in ‘inst/doc’ ... OK
> * checking running R code from vignettes ...
>   ‘permutation_based_testing.Rmd’ using ‘UTF-8’... OK
>   ‘scoring_functions.Rmd’ using ‘UTF-8’... OK
>  NONE
> * checking re-building of vignette outputs ... OK
> * checking PDF version of manual ... OK
> * DONE
>
> Status: OK
> ```
>
> biocbuild@kunpeng2 ~/g/CaDrA (devel)> git log -1
> commit ae6513e0877d5866fc8240eb123b8bc83af73e19 (HEAD -> devel,
> origin/master, origin/devel, origin/HEAD)
> Author: RC-88 
> Date:   Wed Oct 18 16:14:42 2023 -0400
>
> remove testing for ks_score method due to inconsistent results on
> linux and macOS amd64
>
>
> I will try to debug the disabled code later !
>
> Martin
>
>
> On Thu, Oct 19, 2023 at 12:21 AM Chau, Reina  wrote:
>
>> Hi Martin,
>>
>> That would be very helpful. Thanks so much! Right now, it is failing in
>> one of the unit test cases. In particular, our core function, CaDrA::CaDrA,
>> which is used to run permutation-based tests to determine whether the
>> strength of the association between the set of features and the observed
>> input scores (e.g., pathway activity, drug sensitivity, etc.) is greater
>> than it would be expected by chance.
>>
>> Here is a snippet of where the test failed in Mac and Linux ARM64 machine
>> :
>>
>> # R library
>> library(CaDrA)
>> library(testthat)
>>
>> data("sim_FS”)
>> data("sim_Scores")
>>
>> # Set seed
>> set.seed(21)
>>
>> # ks_score
>> result <- CaDrA::CaDrA(
>> FS = sim_FS,
>> input_score = sim_Scores,
>> method = "ks_score",
>> weights = NULL,
>> alternative = "less",
>> top_N = 1,
>> search_start = NULL,
>> search_method = "both",
>> max_size = 7,
>> n_perm = 10,
>> plot = FALSE,
>> smooth = TRUE,
>> obs_best_score = NULL,
>> ncores = 1,
>> cache = FALSE,
>> cache_path = NULL
>> )
>>
>> testthat::expect_length(result, 4L)
>> testthat::expect_type(result, "list")
>> testthat::expect_named(result,
>>
>>  c("key","perm_best_scores","obs_best_score","perm_pval"))
>> testthat::expect_type(result$key, "list")
>> testthat::expect_length(result$key, 11L)
>> testthat::expect_named(result$key,
>>  c("FS", "input_score", "method",
>> "custom_function",
>>"custom_parameters", "alternative",
>> "weights", "top_N",
>>"search_start", "search_method",
>> "max_size"))
>> testthat::expect_type(result$key$FS, "double")
>>
>> testthat::expect_equal(round(result$perm_best_scores[1:10], 5),
>>  c('TP_8'=0.34,
>>'TP_10'=0.54,
>>'TP_9'=0.37,
>>        'TP_6'=0.40,
>>'TP_9'=0.38,
>>'TP_9'=0.52,
>>'TP_2'=0.44,
>>'TP_2'=0.40,
>>'TP_4'=0.44,
>>'TP_9'=0.49))
>>
>> testthat::expect_equal(round(result$obs_best_score, 2), c("TP_9

Re: [Bioc-devel] Build error for CaDrA package on kunpeng2 Linux machine

[Martin Grigorov]

Hello Reina,

The checks pass now after your last commit:

```
...
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ...
  Running ‘testthat.R’
 OK
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in ‘inst/doc’ ... OK
* checking running R code from vignettes ...
  ‘permutation_based_testing.Rmd’ using ‘UTF-8’... OK
  ‘scoring_functions.Rmd’ using ‘UTF-8’... OK
 NONE
* checking re-building of vignette outputs ... OK
* checking PDF version of manual ... OK
* DONE

Status: OK
```

biocbuild@kunpeng2 ~/g/CaDrA (devel)> git log -1
commit ae6513e0877d5866fc8240eb123b8bc83af73e19 (HEAD -> devel,
origin/master, origin/devel, origin/HEAD)
Author: RC-88 
Date:   Wed Oct 18 16:14:42 2023 -0400

remove testing for ks_score method due to inconsistent results on linux
and macOS amd64


I will try to debug the disabled code later !

Martin


On Thu, Oct 19, 2023 at 12:21 AM Chau, Reina  wrote:

> Hi Martin,
>
> That would be very helpful. Thanks so much! Right now, it is failing in
> one of the unit test cases. In particular, our core function, CaDrA::CaDrA,
> which is used to run permutation-based tests to determine whether the
> strength of the association between the set of features and the observed
> input scores (e.g., pathway activity, drug sensitivity, etc.) is greater
> than it would be expected by chance.
>
> Here is a snippet of where the test failed in Mac and Linux ARM64 machine:
>
> # R library
> library(CaDrA)
> library(testthat)
>
> data("sim_FS”)
> data("sim_Scores")
>
> # Set seed
> set.seed(21)
>
> # ks_score
> result <- CaDrA::CaDrA(
> FS = sim_FS,
> input_score = sim_Scores,
> method = "ks_score",
> weights = NULL,
> alternative = "less",
> top_N = 1,
> search_start = NULL,
> search_method = "both",
> max_size = 7,
> n_perm = 10,
> plot = FALSE,
> smooth = TRUE,
> obs_best_score = NULL,
> ncores = 1,
> cache = FALSE,
> cache_path = NULL
> )
>
> testthat::expect_length(result, 4L)
> testthat::expect_type(result, "list")
> testthat::expect_named(result,
>
>  c("key","perm_best_scores","obs_best_score","perm_pval"))
> testthat::expect_type(result$key, "list")
> testthat::expect_length(result$key, 11L)
> testthat::expect_named(result$key,
>  c("FS", "input_score", "method",
> "custom_function",
>"custom_parameters", "alternative",
> "weights", "top_N",
>"search_start", "search_method",
> "max_size"))
> testthat::expect_type(result$key$FS, "double")
>
> testthat::expect_equal(round(result$perm_best_scores[1:10], 5),
>  c('TP_8'=0.34,
>'TP_10'=0.54,
>'TP_9'=0.37,
>'TP_6'=0.40,
>'TP_9'=0.38,
>'TP_9'=0.52,
>'TP_2'=0.44,
>'TP_2'=0.40,
>'TP_4'=0.44,
>'TP_9'=0.49))
>
> testthat::expect_equal(round(result$obs_best_score, 2), c("TP_9"=0.66))
>
> # A smooth factor of 1
> c <- 1
>
> # Add a smoothing factor of 1
> # This is just to not return a p-value of 0
> testthat::expect_equal(
> round((sum(result$perm_best_scores[1:10] >
> result$obs_best_score)+c)/(10+c), 6),
> c(0.090909)
> )
>
> Any helps or directions on how to resolve this problem would be be greatly
> appreciated!
>
> Best,
>
> Reina C.
>
>
> On Oct 18, 2023, at 4:35 PM, Martin Grigorov 
> wrote:
>
>
>
> On Wed, Oct 18, 2023 at 11:11 PM Chau, Reina  wrote:
>
>> Thank you both! I will look thru the links and see if I can implement a
>> fix.
>>
>
> I'd be happy to test any patches if it will be easier for you !
>
> Martin
>
>
>
>>
>> Best,
>>
>> Reina C.
>>
>> On Oct 18, 2023, at 4:03 PM, Martin Grigorov 
>> wrote:
>>
>> Hi,
>>
>> On Wed, Oct 18, 2023 at 10:48 PM Hervé Pagès 
>> wrote:
>>
>>> Hi Reina,
>>>
>>> Note that CaDrA results on Mac ARM64 are also affected:
>>> https://bioconductor.org/checkResults/devel/bioc-mac-arm64-LATEST/CaDrA/
>>>
>>> See Martin Grigorov's blog post here
>>>
>>> https://blog.bioconductor.org/posts/2023-06-09-debu

Re: [Bioc-devel] Build error for CaDrA package on kunpeng2 Linux machine

[Martin Grigorov]

On Wed, Oct 18, 2023 at 11:11 PM Chau, Reina  wrote:

> Thank you both! I will look thru the links and see if I can implement a
> fix.
>

I'd be happy to test any patches if it will be easier for you !

Martin



>
> Best,
>
> Reina C.
>
> On Oct 18, 2023, at 4:03 PM, Martin Grigorov 
> wrote:
>
> Hi,
>
> On Wed, Oct 18, 2023 at 10:48 PM Hervé Pagès 
> wrote:
>
>> Hi Reina,
>>
>> Note that CaDrA results on Mac ARM64 are also affected:
>> https://bioconductor.org/checkResults/devel/bioc-mac-arm64-LATEST/CaDrA/
>>
>> See Martin Grigorov's blog post here
>>
>> https://blog.bioconductor.org/posts/2023-06-09-debug-linux-arm64-on-docker/
>>
>> for how to debug Linux ARM64 related issues on a x86_64 host.
>>
>> Note that different architectures use slightly different floating point
>> arithmetic with slightly different precision. This can affect the
>> results of your numerical calculations. The degree to which they are
>> affected will vary greatly depending on what calculations you perform
>> and how you perform them. So it's important to implement things in a way
>> that tries to minimize the impact of these variations as much as possible.
>>
>
> See https://go.dev/ref/spec#Floating_point_operators for some further
> explanation of the problem and possible fix by explicit rounding (in
> Golang, but I guess something similar happens in R)
>
>
>>
>> Best,
>>
>> H.
>>
>>
>> On 10/18/23 10:46, Chau, Reina wrote:
>> > Hi Bioconductor Core Team,
>> >
>> > I’m the maintainer of CaDrA package, and recently, I notice that my
>> package built successfully for all platforms except on Kunpeng2 Linux
>> machine (seehttps://
>> bioconductor.org/checkResults/devel/bioc-LATEST/CaDrA/  andhttps://
>> bioconductor.org/checkResults/devel/bioc-LATEST/CaDrA/kunpeng2-checksrc.html
>> )
>> >
>> > I did try to figure out what is causing the different results using
>> this particular platform compare with others but with no resolves.
>> >
>> > Hope you can give me some guidance or feedback of why the build is
>> failing for this particular case.
>> >
>> > Thanks so much!
>> >
>> > Best,
>> >
>> > Reina C.
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > ___
>> > Bioc-devel@r-project.org  mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>> --
>> Hervé Pagès
>>
>> Bioconductor Core Team
>> hpages.on.git...@gmail.com
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] groHMM package error

[Martin Grigorov]

Hi,

On Wed, Oct 18, 2023 at 11:31 PM Tulip Nandu 
wrote:

> Hi,
>
> I just got an email from the Bioconductor stating,
>
> According to the Multiple platform build/check report for BioC 3.18,
> the groHMM package has the following problem(s):
>
>  o ERROR for 'R CMD build' on nebbiolo2. See the details here:
>
> https://urldefense.com/v3/__https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/groHMM/nebbiolo2-buildsrc.html__;!!MznTZTSvDXGV0Co!EKNuDHTauIdmqCovMhm5TdBQxvFkgq7fpBEFI3kj-5n280k-q3LRrRl6Ob_W0vidU06EefTKfoj0ioHb1yG9hu35fXhzALBpFkA$
>
>
> I feel it's the version issue 3.17 to 3.18 and I need to release the
> package to 3.18 too. But moment I try to update it throws up a error
> message:
>
> git checkout RELEASE_3_18
> error: pathspec 'RELEASE_3_18' did not match any file(s) known to git
>

Use "devel" instead of "RELEASE_3_18".
3.18 is not released yet.

Martin


> Can anyone help me with this update and error.
>
> Regards,
>
> Tulip.
>
>
> 
>
> UT Southwestern
>
> Medical Center
>
> The future of medicine, today.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Build error for CaDrA package on kunpeng2 Linux machine

[Martin Grigorov]

Hi,

On Wed, Oct 18, 2023 at 10:48 PM Hervé Pagès 
wrote:

> Hi Reina,
>
> Note that CaDrA results on Mac ARM64 are also affected:
> https://bioconductor.org/checkResults/devel/bioc-mac-arm64-LATEST/CaDrA/
>
> See Martin Grigorov's blog post here
> https://blog.bioconductor.org/posts/2023-06-09-debug-linux-arm64-on-docker/
> for how to debug Linux ARM64 related issues on a x86_64 host.
>
> Note that different architectures use slightly different floating point
> arithmetic with slightly different precision. This can affect the
> results of your numerical calculations. The degree to which they are
> affected will vary greatly depending on what calculations you perform
> and how you perform them. So it's important to implement things in a way
> that tries to minimize the impact of these variations as much as possible.
>

See https://go.dev/ref/spec#Floating_point_operators for some further
explanation of the problem and possible fix by explicit rounding (in
Golang, but I guess something similar happens in R)


>
> Best,
>
> H.
>
>
> On 10/18/23 10:46, Chau, Reina wrote:
> > Hi Bioconductor Core Team,
> >
> > I’m the maintainer of CaDrA package, and recently, I notice that my
> package built successfully for all platforms except on Kunpeng2 Linux
> machine (seehttps://bioconductor.org/checkResults/devel/bioc-LATEST/CaDrA/
> andhttps://
> bioconductor.org/checkResults/devel/bioc-LATEST/CaDrA/kunpeng2-checksrc.html
> )
> >
> > I did try to figure out what is causing the different results using this
> particular platform compare with others but with no resolves.
> >
> > Hope you can give me some guidance or feedback of why the build is
> failing for this particular case.
> >
> > Thanks so much!
> >
> > Best,
> >
> > Reina C.
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org  mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Release Package Update Issue

[Martin Grigorov]

Hi,

3.17 (release) has been frozen:
https://stat.ethz.ch/pipermail/bioc-devel/2023-October/019920.html
https://stat.ethz.ch/pipermail/bioc-devel/2023-October/019928.html

Regards,
Martin

On Tue, Oct 17, 2023 at 6:59 AM Guy Hunt  wrote:

> Hi
>
> I have updated the devel version of my Bioconductor package successfully.
>
> However, I am having issues updating my package's release version.
>
> This is the command I am using to push my updates:
> git push upstream RELEASE_3_17
>
> This is the error message I received:
> Enumerating objects: 5, done.
> Counting objects: 100% (5/5), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 295 bytes | 295.00 KiB/s, done.
> Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
> remote: FATAL: W refs/heads/RELEASE_3_17 packages/GEOexplorer guypwhunt
> DENIED by fallthru
> remote: error: hook declined to update refs/heads/RELEASE_3_17
> To git.bioconductor.org:packages/GEOexplorer.git
>  ! [remote rejected] RELEASE_3_17 -> RELEASE_3_17 (hook declined)
> error: failed to push some refs to 'git.bioconductor.org:
> packages/GEOexplorer.git'
>
> I have looked through the documentation online but I am struggling to
> overcome this issue.
>
> Thank you for all your help in advance.
>
> All the best,
> Guy
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] cfTools build error

[Martin Grigorov]

Hi,

https://pypi.org/project/tensorflow/2.10.0/#files is the first release that
provides a wheel for Linux ARM64 (aarch64).
Would it be OK to update from 2.8.0 to 2.10.0 ? Or even better to 2.14.0
(latest and greatest)!

Regards,
Martin

On Tue, Oct 10, 2023 at 9:30 PM RAN HU  wrote:

> Dear Bioc Team,
>
> I have a build error on palomino4 and kunpeng2 due to an environment
> problem: Multiple platform build/check report for BioC 3.18 - All results
> for package cfTools (bioconductor.org)
> 
> PackagesNotFoundError: The following packages are not available from
> current channels:
>   - tensorflow=2.8.0
>
> Could you help me solve this? Thank you in advance!
>
> Best,
>
> Ran
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] extraChIPs build error on kunpeng2

[Martin Grigorov]

Hi,

On Tue, Oct 10, 2023 at 10:30 AM Stevie Pederson <
stephen.pederson...@gmail.com> wrote:

> Hi,
>
> I've got a build error on kunpeng2 which has me a bit stuck, with the build
> report available here:
>
> https://bioconductor.org/checkResults/3.18/bioc-LATEST/extraChIPs/kunpeng2-checksrc.html


I see no ERRORs for this package on any of the build runners!


>
> I'm
> struggling to understand where it's coming from as it doesn't seem related
> to the package itself. I think the key section is this one:
>
> * checking examples ... ERROR
> Running examples in ‘extraChIPs-Ex.R’ failed
> The error occurred in:
>
> R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
> Copyright (C) 2023 The R Foundation for Statistical Computing
> Platform: aarch64-unknown-linux-gnu (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
>   Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
> > pkgname <- "extraChIPs"
> > source(file.path(R.home("share"), "R", "examples-header.R"))
> > options(warn = 1)
> > base::assign(".ExTimings", "extraChIPs-Ex.timings", pos = 'CheckExEnv')
> > base::cat("name\tuser\tsystem\telapsed\n", file=base::get(".ExTimings",
> pos = 'CheckExEnv'))
> > base::assign(".format_ptime",
> + function(x) {
> +   if(!is.na(x[4L])) x[1L] <- x[1L] + x[4L]
> +   if(!is.na(x[5L])) x[2L] <- x[2L] + x[5L]
> +   options(OutDec = '.')
> +   format(x[1L:3L], digits = 7L)
> + },
> + pos = 'CheckExEnv')
> >
> > ### * 
>
> I also tried setting up the docker locally using the instructions here:
> https://blog.bioconductor.org/posts/2023-06-09-debug-linux-arm64-on-docker/
> .
> After adding a step to install all of my package dependencies, I can't
> reproduce the error on my local ARM64 image. However, I do get the
> following, quite different error:
>
> * checking PDF version of manual without index ... ERROR
> Re-running with no redirection of stdout/stderr.
> Hmm ... looks like a package
> Converting parsed Rd's to LaTeX 
> Creating pdf output from LaTeX ...
> Warning in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,
>  :
>   texi2dvi script/program not available, using emulation
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
>   pdflatex is not available
> Warning in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,
>  :
>   texi2dvi script/program not available, using emulation
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
>   pdflatex is not available
> Error in running tools::texi2pdf()
>
> Is anyone able to shed some insights as to what may be up? The key part of
> the kunpeng2 error doesn't resemble any of my code, and I'm guessing the
> docker image doesn't have pdflatex. Maybe?
>

You can install pdflatex with: apt install texlive-latex-extra
It installs many dependencies. I guess this is the reason why it is not
pre-installed on ghcr.io/bioconductor/bioconductor:devel-r-latest



>
> Thanks in advance,
>
> Stevie
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] magpie package failing unit test

[Martin Grigorov]

Dear Daoyu,

I can reproduce the test failure at kunpeng2 build runner!
I'd be happy to test any suggestions you might have!

Regards,
Martin

On Fri, Sep 22, 2023 at 6:34 PM Daoyu Duan  wrote:

> Dear Bioconductor team,
>
> I have received emails that my package "magpie" is failing the unit test
> in devel, but I have not made any changes after the last release where the
> unit test passed. I tried to investigate this issue but the unit test
> passed on my local machines (MacOS and Windows) and was not able to
> replicate the error. Are there any possible reasons for this to happen?
> Thank you so much for any suggestions!
>
> Best regards,
>
> Daoyu
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Including large files for the package

[Martin Grigorov]

Hello,

Perhaps you could use https://bioconductor.r-universe.dev/BiocFileCache to
download the big file on demand.
The benefit is that the file would be stored in ~/.cache/R/yourPackage/
(for Linux; something similar for Windows/Mac) and reused between sessions.

Regards,
Martin

On Tue, Aug 29, 2023 at 5:15 AM Ali Sajid Imami 
wrote:

> Hi BioConductor Team,
>
> I am a PhD Candidate in the Cognitive Disorders Research lab at the
> university of Toledo. I am responsible for a number of R packages and our
> intention is to submit them to bioconductor over the next several months. I
> had just submitted a package drugfindR (
> https://github.com/CogDisResLab/drugfindR). This was immediately closed as
> my repo had a single file over the 5MB limit.
>
> I wanted to ask both if you would reconsider/make an exception or guide me
> in the right direction.
>
> This package serves as a way to quickly learch through the LINCS data
> stored at the ilincs.org portal. The file in question is one of three
> metadata files that allows the package to function efficiently and without
> having to go through the expensive network requests. It would really be
> helpful if we could include the file as is. I do not expect more files like
> that to be added to the package at all.
>
> Barring that, I have seen the suggestion of using AnnotationHub or
> ExperimentHub. While I have gone through the documentation, I'm not
> entirely sure how those services work. Are those services where we can
> store the data itself or we are expected to host the data elsewhere and
> create lightweight "pointer" packages. Similarly, I'm not entirely sure
> which Hub this would go to.
>
> Any advice or guidance will be appreciated.
>
>
> Regards,
> Dr. Ali Sajid Imami
> LinkedIn 
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Cherry picking error - SiPSiC package

[Martin Grigorov]

Hi,

Maybe I wasn't very clear: "SHA" should be replaced with the commit hash

For example:

$ git log --oneline -1
f367ed608 (HEAD -> openeuler-22.03-sp2, origin/openeuler-22.03-sp2) Update
all references of "22.03 LTS" to "22.03 LTS SP2"

Here the SHA is f367ed608.
So the command would be: git cherry-pick -x f367ed608

Regards,
Martin


On Mon, Aug 14, 2023 at 4:09 PM Daniel Davis 
wrote:

> Thank you Martin!
>
> I tried it. When I execute the git cherry-pick -x SHA command, I get
> "fatal: bad revision '' "
>
> Any idea?
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#m_1308354042402282384_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, Aug 14, 2023 at 4:03 PM Martin Grigorov 
> wrote:
>
>> Hi Daniel,
>>
>> You could try `git cherry-pick -x SHA` instead. Where "SHA" is the commit
>> hash in devel branch. This way you will cherry-pick only your particular
>> commit.
>>
>> - git reset --hard
>> - git switch devel
>> - git log --oneline -1   # to get the SHA
>> - git switch RELEASE_3_17
>> - git pull --rebase
>> - git cherry-pick -x $SHA
>> - git push
>>
>> Regards,
>> Martin
>>
>>
>> On Mon, Aug 14, 2023 at 3:56 PM Daniel Davis 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I would like to update the description of the released version of my
>>> package.
>>> Following the developer guide, I executed the git checkout and pull
>>> commands on the devel branch, changed the description file as necessary,
>>> then committed and pushed it - everything was fine.
>>> However, when I try to checkout RELEASE_3_17 then execute git cherry-pick
>>> devel, a conflict error is thrown on the description file. Now that makes
>>> sense, but I'm not familiar enough with git to try and handle the
>>> situation
>>> myself.. So - what is the right thing to do if I would like to apply the
>>> devel version of the description file to the current release of the
>>> package?
>>>
>>> Thanks,
>>>
>>> Daniel
>>>
>>> <
>>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>>> >
>>> Virus-free.www.avast.com
>>> <
>>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>>> >
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Cherry picking error - SiPSiC package

[Martin Grigorov]

Hi Daniel,

You could try `git cherry-pick -x SHA` instead. Where "SHA" is the commit
hash in devel branch. This way you will cherry-pick only your particular
commit.

- git reset --hard
- git switch devel
- git log --oneline -1   # to get the SHA
- git switch RELEASE_3_17
- git pull --rebase
- git cherry-pick -x $SHA
- git push

Regards,
Martin


On Mon, Aug 14, 2023 at 3:56 PM Daniel Davis 
wrote:

> Hello everyone,
>
> I would like to update the description of the released version of my
> package.
> Following the developer guide, I executed the git checkout and pull
> commands on the devel branch, changed the description file as necessary,
> then committed and pushed it - everything was fine.
> However, when I try to checkout RELEASE_3_17 then execute git cherry-pick
> devel, a conflict error is thrown on the description file. Now that makes
> sense, but I'm not familiar enough with git to try and handle the situation
> myself.. So - what is the right thing to do if I would like to apply the
> devel version of the description file to the current release of the
> package?
>
> Thanks,
>
> Daniel
>
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> Virus-free.www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] [+externe Mail+] Re: pwOmics package get error message for Linux check

[Martin Grigorov]

Dear Maren,

Do you need more help with this ?
Both https://code.bioconductor.org/browse/pwOmics/commits/devel and
https://github.com/MarenS2/pwOmics don't have the change yet.

Regards,
Martin

On Tue, Aug 8, 2023 at 3:39 PM Sitte, Maren <
maren.si...@med.uni-goettingen.de> wrote:

> Dear Martin,
>
>
> thank you very much for the quick response.
>
> I will apply your advice and add the package to "Suggests".
>
>
> Kind regards
>
> Maren
>
>
> --
>
> NGS Integrative Genomics (NIG), Core Unit
> Department of Human Genetics
> University Medical Center Göttingen (UMG)
> Justus-von-Liebig-Weg 11, 37077 Göttingen, Germany
> Contact : 0551 39-60778
> --
> *Von:* Martin Grigorov 
> *Gesendet:* Dienstag, 8. August 2023 14:36:27
> *An:* Sitte, Maren
> *Cc:* Schoeps, Torsten; bioc-devel@r-project.org
> *Betreff:* [+externe Mail+] Re: [Bioc-devel] pwOmics package get error
> message for Linux check
>
> Hi,
>
> On Tue, 8 Aug 2023 at 12:32, Sitte, Maren <
> maren.si...@med.uni-goettingen.de> wrote:
>
>> Dear Bioconductor Developers,
>>
>>
>>  I received an email that my package "pwOmics" gets an error in the check
>> under Linux.
>>  Install and build gets an OK, but check shows an error.
>>
>>  I had a look and the problem seems to be:
>>
>>  > BiocGenerics:::testPackage("pwOmics")
>> Error in library("RUnit", quietly = TRUE) :
>> there is no package called 'RUnit'
>> Calls:  -> library
>> Execution halted
>>
>> I checked and the RUnit package is still available on Bioconductor and
>> can still be installed. So I can't fully understand the error message.
>> Could you help me resolve this error message?
>
>
> You need to add RUnit in the list of “Suggests” in the DESCRIPTION file.
>
> Regards,
> Martin
>
>
>>
>> Thank you for the support!
>> Kind regards
>> Maren
>>
>>
>> --
>>
>> NGS Integrative Genomics (NIG), Core Unit
>> Department of Human Genetics
>> University Medical Center Göttingen (UMG)
>> Justus-von-Liebig-Weg 11, 37077 Göttingen, Germany
>> Contact : 0551 39-60778
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Omada package failing due to removed dependency

[Martin Grigorov]

Hi,

All is green at
https://bioconductor.org/checkResults/3.18/bioc-LATEST/omada/

Regards,
Martin

On Thu, Aug 10, 2023 at 9:44 AM Sokratis Kariotis <
sokratiskario...@gmail.com> wrote:

> Hey all,
>
> Is this fixed now? I think I can see all pass, but on the actual website
> its still on error. Thanks!
>
> Cheers,
> Sokratis
>
> On Tue, Aug 1, 2023 at 4:25 PM Sokratis Kariotis <
> sokratiskario...@gmail.com> wrote:
>
>> Hey,
>>
>> I believe I have resolved the conflicts and now can run: *git push
>> upstream main:devel*
>> with Everything up-to-date as a result. However, *git push origin main*
>> does not yield
>> anything and it keeps hanging without a message. I checked 
>> https://bioconductor.org/checkResults/3.18/bioc-LATEST/omada/
>> and the last commit is April.
>>
>>
>> On Mon, Jul 31, 2023 at 10:01 PM Kern, Lori <
>> lori.sheph...@roswellpark.org> wrote:
>>
>>> You'll need to find the merge conflicts and resolve them. Recommit those
>>> files and then it should go.
>>>
>>> Lori Shepherd - Kern
>>>
>>> Bioconductor Core Team
>>>
>>> Roswell Park Comprehensive Cancer Center
>>>
>>> Department of Biostatistics & Bioinformatics
>>>
>>> Elm & Carlton Streets
>>>
>>> Buffalo, New York 14263
>>> --
>>> *From:* Bioc-devel  on behalf of
>>> Sokratis Kariotis 
>>> *Sent:* Monday, July 31, 2023 7:27 AM
>>> *To:* Martin Grigorov 
>>> *Cc:* bioc-devel@r-project.org 
>>> *Subject:* Re: [Bioc-devel] Omada package failing due to removed
>>> dependency
>>>
>>> Tried but its Already up to date.
>>>
>>> On Mon, 31 Jul 2023, 7:22 pm Martin Grigorov, >> >
>>> wrote:
>>>
>>> > Hi Sokratis,
>>> >
>>> > You need to do "git pull --rebase" before trying to push.
>>> > Most probably the version has been bumped upstream.
>>> >
>>> > Regards,
>>> > Martin
>>> >
>>> > On Mon, Jul 31, 2023 at 2:16 PM Sokratis Kariotis <
>>> > sokratiskario...@gmail.com> wrote:
>>> >
>>> >> Hey all,
>>> >>
>>> >> I created a new key and now I can commit etc but there is a conflict
>>> that
>>> >> is not allowing me to go ahead.
>>> >>
>>> >> My commands:
>>> >> git add .
>>> >> git commit -m "Update metrics"
>>> >> git push upstream main:devel
>>> >>
>>> >> *The above results in the following error:*
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> *Enumerating objects: 19, done.Counting objects: 100% (17/17),
>>> done.Delta
>>> >> compression using up to 16 threadsCompressing objects: 100% (11/11),
>>> >> done.Writing objects: 100% (11/11), 4.78 KiB | 4.78 MiB/s, done.Total
>>> 11
>>> >> (delta 7), reused 0 (delta 0), pack-reused 0remote: Error: You cannot
>>> push
>>> >> without resolving merge conflicts.remote:remote: Please check the
>>> files in
>>> >> the commit pushed to the git-serverremote: for merge conflict markers
>>> like
>>> >> '<<<<<<<', '', '>>>>>>>'.remote:To
>>> >> git.bioconductor.org:packages/omada ! [remote rejected] main -> devel
>>> >> (pre-receive hook declined)error: failed to push some refs to
>>> >> 'git.bioconductor.org:packages/omada'*
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Jul 31, 2023 at 3:36 PM Mike Smith 
>>> wrote:
>>> >>
>>> >> > Hi Sokratis,
>>> >> >
>>> >> > Everything in Bioconductor is built around the central Bioconductor
>>> git
>>> >> > repositories.  The only way to get changes out to users is to commit
>>> >> them
>>> >> > to git.bioconductor.org and then the build system will pick those
>>> up,
>>> >> run
>>> >> > the tests and checks, create new versions of packages, and make them
>>> >> > available for distr

Re: [Bioc-devel] pwOmics package get error message for Linux check

[Martin Grigorov]

Hi,

On Tue, 8 Aug 2023 at 12:32, Sitte, Maren 
wrote:

> Dear Bioconductor Developers,
>
>
>  I received an email that my package "pwOmics" gets an error in the check
> under Linux.
>  Install and build gets an OK, but check shows an error.
>
>  I had a look and the problem seems to be:
>
>  > BiocGenerics:::testPackage("pwOmics")
> Error in library("RUnit", quietly = TRUE) :
> there is no package called 'RUnit'
> Calls:  -> library
> Execution halted
>
> I checked and the RUnit package is still available on Bioconductor and can
> still be installed. So I can't fully understand the error message. Could
> you help me resolve this error message?


You need to add RUnit in the list of “Suggests” in the DESCRIPTION file.

Regards,
Martin


>
> Thank you for the support!
> Kind regards
> Maren
>
>
> --
>
> NGS Integrative Genomics (NIG), Core Unit
> Department of Human Genetics
> University Medical Center Göttingen (UMG)
> Justus-von-Liebig-Weg 11, 37077 Göttingen, Germany
> Contact : 0551 39-60778
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Omada package failing due to removed dependency

[Martin Grigorov]

Hi Sokratis,

You need to do "git pull --rebase" before trying to push.
Most probably the version has been bumped upstream.

Regards,
Martin

On Mon, Jul 31, 2023 at 2:16 PM Sokratis Kariotis <
sokratiskario...@gmail.com> wrote:

> Hey all,
>
> I created a new key and now I can commit etc but there is a conflict that
> is not allowing me to go ahead.
>
> My commands:
> git add .
> git commit -m "Update metrics"
> git push upstream main:devel
>
> *The above results in the following error:*
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Enumerating objects: 19, done.Counting objects: 100% (17/17), done.Delta
> compression using up to 16 threadsCompressing objects: 100% (11/11),
> done.Writing objects: 100% (11/11), 4.78 KiB | 4.78 MiB/s, done.Total 11
> (delta 7), reused 0 (delta 0), pack-reused 0remote: Error: You cannot push
> without resolving merge conflicts.remote:remote: Please check the files in
> the commit pushed to the git-serverremote: for merge conflict markers like
> '<<<', '', '>>>'.remote:To
> git.bioconductor.org:packages/omada ! [remote rejected] main -> devel
> (pre-receive hook declined)error: failed to push some refs to
> 'git.bioconductor.org:packages/omada'*
>
>
>
> On Mon, Jul 31, 2023 at 3:36 PM Mike Smith  wrote:
>
> > Hi Sokratis,
> >
> > Everything in Bioconductor is built around the central Bioconductor git
> > repositories.  The only way to get changes out to users is to commit them
> > to git.bioconductor.org and then the build system will pick those up,
> run
> > the tests and checks, create new versions of packages, and make them
> > available for distribution.
> >
> > Perhaps you can include the git command you're running to submit the
> > changes and a copy of the exact error you're receiving.  That might help
> > the team suggest a solution.
> >
> > Best regards,
> > Mike
> >
> > On Fri, 28 Jul 2023 at 08:32, Sokratis Kariotis <
> > sokratiskario...@gmail.com> wrote:
> >
> >> Hey both,
> >>
> >> I have edited the package code but I'm having some difficulties pushing
> it
> >> to trigger another build (github passphrase). Is there another way to
> >> trigger the build? Thanks!
> >>
> >> Cheers,
> >> Sokratis
> >>
> >> On Wed, Jul 12, 2023 at 1:43 AM Kern, Lori <
> lori.sheph...@roswellpark.org
> >> >
> >> wrote:
> >>
> >> > We can give you a little more time (a few weeks) to fix the package
> but
> >> > please fix as soon as possible to avoid deprecation.
> >> >
> >> > Cheers,
> >> >
> >> > Lori Shepherd - Kern
> >> >
> >> > Bioconductor Core Team
> >> >
> >> > Roswell Park Comprehensive Cancer Center
> >> >
> >> > Department of Biostatistics & Bioinformatics
> >> >
> >> > Elm & Carlton Streets
> >> >
> >> > Buffalo, New York 14263
> >> > --
> >> > *From:* Sokratis Kariotis 
> >> > *Sent:* Monday, July 10, 2023 10:27 AM
> >> > *To:* Kern, Lori 
> >> > *Cc:* Oleksii Nikolaienko ;
> >> > bioc-devel@r-project.org 
> >> > *Subject:* Re: [Bioc-devel] Omada package failing due to removed
> >> > dependency
> >> >
> >> > Hey both,
> >> >
> >> > I have checked the package license (GPL) and it should be fine to use
> >> the
> >> > code. However, I am having difficulty finding the actual code to
> >> calculate
> >> > the internal metrics I am using (used in Omada's function
> >> > cluster_voting.R). I can only find the wrapper function but not the
> ones
> >> > that actually calculate the metrics. I am not sure how to proceed with
> >> this
> >> > in time, so the Omada package won't get deprecated.
> >> >
> >> > Regards,
> >> > Sokratis
> >> >
> >> > On Fri, Jul 7, 2023 at 1:03 AM Kern, Lori <
> >> lori.sheph...@roswellpark.org>
> >> > wrote:
> >> >
> >> > We would not hunt down the lab especially for CRAN packages,  but you
> >> > could reach out if you like.  That would probably be a recommended
> >> action
> >> > to either ask someone from their lab to maintain or if you are willing
> >> and
> >> > you really want the package around you could ask the lab if they mind
> >> you
> >> > volunteering to be the new maintainer.
> >> >
> >> > There could see two options for rewriting/maintaining.
> >> >
> >> > 1. Take over maintenance of the package and resubmit to CRAN
> >> > It's a little tricky cause this is a CRAN package so I'm not sure on
> >> their
> >> > exact policy of taking over an abandoned package. If this is
> desired,  I
> >> > would reach out to CRAN to find out their exact policy
> >> > 2. Move needed code to your Bioconductor package
> >> > You'll have to check the original package license to make sure this is
> >> > allowed under the license of the package. You will still want to give
> >> the
> >> > original authors/maintainer credit. I would say to be safe I would
> >> include
> >> > them as contributors/authors in the DESCRITPION Authors@R field and
> in
> >> > the R code I would add a comment above the code to reference original
> >> > package citation and stating it was copied from there.  I'm not a
> >> lawyer or
> >> > license/copy right 

Re: [Bioc-devel] benchdamic TIMEOUT in merida1 and kunpeng2

[Martin Grigorov]

HI,

I don't have a good explanation why it was timing out on kunpeng2 but I
think it will pass from now on!

Here is what I did:

1) I tried to build benchdamic on kunpeng2:

$ R CMD build --keep-empty-dirs --no-resave-data benchdamic
* checking for file ‘benchdamic/DESCRIPTION’ ... OK
* preparing ‘benchdamic’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ...

and it hung here for several minutes...

2) I checked the single vignette in the package and I noticed that it
uses/depends on data package HMP16SData

3) in a new terminal session I started R and installed the data package:

BiocManager::install("HMP16SData")
Bioconductor version 3.18 (BiocManager 1.30.21), R 4.3.1 (2023-06-16)
Installing package(s) 'HMP16SData'
trying URL '
https://bioconductor.org/packages/3.18/data/experiment/src/contrib/HMP16SData_1.21.0.tar.gz
'
Content type 'application/x-gzip' length 17066704 bytes (16.3 MB)
==
downloaded 16.3 MB

* installing *source* package ‘HMP16SData’ ...
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation
path
* DONE (HMP16SData)

Since it didn't stop early with a message like "The package is already
installed with the last version" it seems this data package was not
installed until now. Should this data package be listed as
dependency/suggest in the DESCRIPTION file ?1

4) and now the build in the first terminal session finished successfully:
...
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘benchdamic_1.7.3.tar.gz’

Since the data package is installed I think from now on
the benchdamic package will not timeout on kunpeng2 until the next update
of the R installation/version when all installed packages in site-library
will be lost and they will have to be downloaded again (automatically or
manually, as I did for HMP16SData)

Regards,
Martin

On Sun, Jul 16, 2023 at 1:19 PM Matteo Calgaro  wrote:

> Dear all,
> my package benchdamic has been giving TIMEOUT in the build results on
> merida1
> 
> (release macOS) and kunpeng2
> 
> (devel Linux).
>
> The devel and release versions of benchdamic are equal due to some updates
> I had to do in both versions to avoid errors. Interestingly, the package
> builds well in the macOS platform in devel (Iconway) while it gives TIMEOUT
> in release. I held off reporting the issue until I had implemented the new
> features, even though the TIMEOUT state has been present since the last
> Bioconductor release.
> The build report only seems to indicate that it times out while building
> vignettes. How should I solve this?
>
> Thanks a lot in advance.
> Best regards.
> Matteo Calgaro
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SVMDO Bioc 3.18 Kunpeng2 error

[Martin Grigorov]

Hi,

Last week we updated R from 4.3.0 to 4.3.1 with empty site-library/ folder.
All packages are being re-installed and some of them timed out.

I just checked and both klaR and org.Hs.eg.db are installed. Please
re-check the results later today!

Regards,
Martin

On Tue, Jun 27, 2023 at 11:25 AM erhanozer19 via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Dear Bioconductor Community,
>
> In BioC 3.18 build/check, kunpeng2 linux ARM64 reports this error:
>
> ERROR: dependencies ‘klaR’, ‘org.Hs.eg.db’ are not available for package
> ‘SVMDO’
>
> Is this a kunpeng2 related problem?
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Rhtslib on arm64

[Martin Grigorov]

Hi Ulrich,

The issue with the LOCK files and folders have been addressed with
https://github.com/Bioconductor/BBS/pull/291
https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/Rhtslib/kjohnson2-install.html
says "This page was generated on 2023-06-02 11:02:20". I guess the issue
will be gone with the next report.

In addition I could say that Rhtslib builds fine on Linux ARM64 -
https://bio-arm.github.io/latest/report/Rhtslib/

Regards,
Martin



On Wed, Jun 7, 2023 at 12:29 PM  wrote:

> Dear Hervé, dear Rhtslib developers, dear BioC core team,
>
> I am regularly checking all BioC check results in order to make sure that I
> do not miss any issues of the four Bioconductor packages that I am
> maintaining. It seems that the ‘podkat’ package in BioC 3.17 release has
> not
> been built for arm64 yet. On the results page
> https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/,
> ‘podkat’
> has been “red” for weeks now. It seems to me that the reason for this is
> that ‘Rhtslib’ does not build either. I have now looked at the results page
> of ‘Rhtslib’
> (https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/Rhtslib/
> )
> and it seems that it is a simple issue with a lock file on the build
> server,
> but not a major problem why the package is not built (who knows, but I
> suppose so). I am therefore asking if anybody is able to resolve that issue
> such that the ‘Rhtslib’ package builds for arm64 and , as a consequence,
> hopefully, my ‘podkat’ package too.
>
> Thanks a lot in advance and best regards,
> Ulrich
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Cannot push to BioC git repo

[Martin Grigorov]

Hi Ulrich,

Your problem looks like another problem of which the Bioc core team is
aware but yours looks a bit different so it might be something new.

Last Friday another developer shared

this in the Slack #bioc_git channel:

OSCA.basic % git push upstream RELEASE_3_16
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 4 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 829 bytes | 165.00 KiB/s, done.
Total 8 (delta 5), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote:   File "hooks/pre-receive.h00-pre-receive-hook-dataexp-workflow",
line 89, in 
remote: apply_hooks(hooks_dict)
remote:   File "hooks/pre-receive.h00-pre-receive-hook-dataexp-workflow",
line 71, in apply_hooks
remote: if hooks_dict["pre-receive-hook-merge-markers"]:  # enable hook
remote: KeyError: 'pre-receive-hook-merge-markers'
To git.bioconductor.org:packages/OSCA.basic
 ! [remote rejected] RELEASE_3_16 -> RELEASE_3_16 (pre-receive hook declined)
error: failed to push some refs to
'g...@git.bioconductor.org:packages/OSCA.basic'


 and here is the answer of Lori Shepherd:

Lori Shepherd  2:21 PM

sorry thats on me most likely -- I updated the hooks yesterday . I'll
investigate (edited)
I found the issue and am actively working on the remedy.  This should not
affect software packages but data experiment, workflows, and books are
affected. I hope to have it remedied shortly.

On Mon, Feb 20, 2023 at 5:33 PM Ulrich Bodenhofer 
wrote:

> Hi,
>
> I am the maintainer of the 'msa' package which has been in Bioconductor
> for eight years now. The package is hosted on github and synchronized with
> the BioC git repo. Today I merged a pull request that had been contributed
> by a github user. I further updated the package's DESCRIPTION and inst/NEWS
> file and wanted to push the latest version to the BioC git repo. No matter
> what I did, I did not succeed. The error messages are attached below. I am
> not a very skilled git user. Does anybody have an idea what I could/should
> do? Any help is gratefully appreciated!
>
> Thanks,
> Ulrich
>
> --
>
> Enumerating objects: 22, done.
> Counting objects: 100% (22/22), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (13/13), done.
> Writing objects: 100% (13/13), 19.57 KiB | 1.96 MiB/s, done.
> Total 13 (delta 9), reused 0 (delta 0), pack-reused 0
> remote: Traceback (most recent call last):
> remote:   File "hooks/pre-receive.h00-pre-receive-hook-software", line 93,
> in 
> remote: apply_hooks(hooks_dict)
> remote:   File "hooks/pre-receive.h00-pre-receive-hook-software", line 79,
> in apply_hooks
> remote: prevent_duplicate_commits(oldrev, newrev, refname)
> remote:   File
> "/home/git/.gitolite/local/hooks/repo-specific/prevent_duplicate_commits.py",
> line 67, in prevent_duplicate_commits
> remote: rev2 = get_svn_revision(second)
> remote:   File
> "/home/git/.gitolite/local/hooks/repo-specific/prevent_duplicate_commits.py",
> line 43, in get_svn_revision
> remote: revision = SVN_COMMIT_REGEX.match(body.decode())
> remote: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa1 in
> position 25709: invalid start byte
> To git.bioconductor.org:packages/msa.git
>  ! [remote rejected] master -> master (pre-receive hook declined)
> error: failed to push some refs to 'git.bioconductor.org:packages/msa.git'
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Support for Linux ARM64

[Martin Grigorov]

t; which is
>> said to require lower power consumption for equivalent throughput.  It
>> may be
>> environmentally beneficial to be ahead of the curve in being able to work
>> with
>> this platform.  Earlier I linked to a github issue indicating that rocker
>> now has a dual
>> platform container image including arm64 support but I don't know if that
>> really
>> addresses the issue at hand. Maybe I need to go onto a graviton machine
>> to find out.
>>
>
> So I did this, and here are some notes:
>
> 1) it is easy to get such a machine in AWS, a1.2xlarge
> Linux 10a568f32a1c 4.14.296-222.539.amzn2.aarch64 #1 SMP Wed Oct 26
> 20:36:51 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
> 2) using the rocker/rstudio:latest-daily I could get DESeq2 installed in
> about 20 minutes of
> compilation of dependent packages
> 3)  to get a checkable version of DESeq2 I needed to enhance the rocker
> environment
> 4  apt-get install libxml2-dev
> 8  apt install libpng-dev
>12  apt install libgit2-dev
>14  apt install -y libmagick++-dev
>16  apt install -y libharfbuzz-dev libfribidi-dev
> 4) DESeq2 check in release version (1.38.2) failed (but it passes on intel
> linux):
>
> Running examples in ‘DESeq2-Ex.R’ failed
> The error most likely occurred in:
>
> > ### Name: unmix
> > ### Title: Unmix samples using loss in a variance stabilized space
> > ### Aliases: unmix
> >
> > ### ** Examples
> >
> >
> > # some artificial data
> > cts <- matrix(c(80,50,1,100,
> + 1,1,60,100,
> + 0,50,60,100), ncol=4, byrow=TRUE)
> > # make a DESeqDataSet
> > dds <- DESeqDataSetFromMatrix(cts,
> +   data.frame(row.names=seq_len(ncol(cts))), ~1)
> converting counts to integer mode
> > colnames(dds) <- paste0("sample",1:4)
> >
> > # note! here you would instead use
> > # estimateSizeFactors() to do actual normalization
> > sizeFactors(dds) <- rep(1, ncol(dds))
> >
> > norm.cts <- counts(dds, normalized=TRUE)
> >
> > # 'pure' should also have normalized counts...
> > pure <- matrix(c(10,0,0,
> +  0,0,10,
> +  0,10,0), ncol=3, byrow=TRUE)
> > colnames(pure) <- letters[1:3]
> >
> > # for real data, you need to find alpha after fitting
> estimateDispersions()
> > mix <- unmix(norm.cts, pure, alpha=0.01)
> Warning in sqrt(alpha * q) : NaNs produced
> Error in optim(par = rep(1, ncol(pure)), fn = sumLossVST, gr = NULL, i,  :
>   L-BFGS-B needs finite values of 'fn'
> Calls: unmix -> lapply -> lapply -> FUN -> optim
>
> Hmm.. this ain't good :-(
>
>
> Is there bugged/nonportable code somewhere in the stack underlying this
> example?
>
> Probably.
>
> That could take some time to figure out.
>
> I conclude that the mechanics of working with ARM64 and R to process
> Bioconductor
> packages are very tractable, but the work needed to get the whole
> ecosystem to a
> favorable state, as usable as it is for intel linux or mac or windows, may
> be laborious.
>
> OK so maybe a good start would be to try to set up the daily builds (BBS)
> on one of those AWS 1.2xlarge or a1.4xlarge instances, or, even better, on
> one of the VMs that Martin is offering? If we use ARM64 Ubuntu on it,
> setting up the builds there should be very similar to what we do for our
> current Intel Ubuntu build machines, which is easy and well-documented.
>
I've sent you privately the SSH details for an Ubuntu 22.04 ARM64 VM!
Please let me know if I can help you anyhow with the setup and testing !

Kind regards,
Martin

> H.
>
>
>
>
>
>
>> In any case it is not so often that we get a request for enhancements
>> that includes
>> an offer of VMs and person power so I want to be sure we don't lose the
>> thread
>> prematurely.
>>
>>
>>
>>
>>
>>
>>
>>> - R is supported on your ARM64-based Linux machine
>>>
>>> - you have compilers that are supported by R
>>>
>>> - you have the external libraries that are required by some CRAN and/or
>>> Bioconductor packages.
>>>
>>> Hope this helps,
>>>
>>> H.
>>>
>>> On 05/01/2023 02:01, Martin Grigorov wrote:
>>> > Dear community,
>>> >
>>> > Happy and successful new year!
>>> >
>>> > Appologies if this has been discussed before but
>>> > https://stat.ethz.ch/pipermail/bioc-devel/ does not provide search
>>> > facilities and my googling didn't help much!
>>> >
>>

Re: [Bioc-devel] Support for Linux ARM64

[Martin Grigorov]

Hello Hervé,

Thank you for your detailed response!

I very much agree with you that the number of combinations (OSes, OS
flavors, CPU architectures, ...) are endless and it is impossible to test
them all!

I work for one of the cloud providers and I can say that the demand for
Linux ARM64 deployments increases steadily in the last few years!
All of the major cloud providers started offering Linux ARM64 compute
instances in addition to the "standard" Linux x86_64 ([1], [2], [3], [4],
[5], [6]). Only IBM offers its own s390x [7] in addition to x86_64.

Microsoft is pushing hard for Windows on ARM64 [8] [9] too! I guess sooner
or later someone will contact the Bioconductor community with a request for
Windows on ARM64.

I hope the Bioconductor community will recognize Linux ARM64 as an
important platform to be supported!

1. https://aws.amazon.com/ec2/instance-types/ (A1)
2. https://cloud.google.com/compute/docs/instances/arm-on-compute (Tau T2A)
3.
https://azure.microsoft.com/en-us/blog/azure-virtual-machines-with-ampere-altra-arm-based-processors-generally-available/

4. https://www.oracle.com/cloud/compute/arm/
5.
https://www.alibabacloud.com/product/ecs?spm=a3c0i.7938564.8215766810.5.20ff441eQxRIsn
6.
https://support.huaweicloud.com/intl/en-us/productdesc-ecs/en-us_topic_0035470096.html
(Kunpeng)
7. https://cloud.ibm.com/vpc-ext/provision/vs
8. https://www.microsoft.com/en-us/search/explore?q=arm64+windows
9.
https://devblogs.microsoft.com/visualstudio/arm64-visual-studio-is-officially-here/

Regards,
Martin

P.S. I am not a native english speaker! I recognize that "man power" is not
the most appropriate wording in my previous message. I meant "people"!


On Thu, Jan 5, 2023 at 8:43 PM Hervé Pagès 
wrote:

> Hi Martin,
>
> Linux runs on many architectures, ARM64 is just one of them.
>
> Our daily builds have traditionally focused on 3 platforms: Intel-based
> Linux (Ubuntu 22.04), Windows, and Intel-based Mac. Note that we
> recently added ARM64-based Mac to our daily builds.
>
> One big difference between Linux and the other platforms is that we only
> produce binary packages for the latter. More precisely:
>
> - on the Linux builders: the daily builds only run 'R CMD INSTALL', 'R
> CMD build', and 'R CMD check', on each Bioconductor package,
>
> - on the Windows and Mac builders: the daily builds run all the above
> plus an additional step that we call the BUILD BIN step that produces a
> binary for each Bioconductor package.
>
> This means that on Linux, as well as on any other Unix-like OS that is
> not macOS (e.g. FreeBSD, OpenBSD, Solaris, HP-UX, etc...), users will
> install all their packages (Bioconductor and CRAN) **from source**. This
> should work as long as they are on a platform where R is supported and
> have the required compilers (C, C++, and Fortran).
>
> Note that if officially supporting a given platform means running the
> daily builds on that particular platform, then there's no way for us to
> do that because platform == OS + architecture, and the list of
> combinations of Unix-like OS's (Linux, FreeBSD, Solaris, etc...) +
> architectures (Intel, ARM64, Sparc, powerpc) is endless. Even if we
> narrow this list to Intel-based Linux, there are hundreds of Linux
> distributions around that use different kernel, compilers, package
> managers, etc...
>
> All this to say that, as far as the daily builds are concerned, we had
> to make choices, and those choices are based on the most commonly used
> platforms. Since all Bioconductor packages are tested daily on
> Intel-based Linux (Ubuntu 22.04), Windows, Intel-based Mac, and
> ARM64-based Mac, we have some reasonable confidence that they will work
> properly on these 4 platforms (still not a 100% guarantee of course,
> there's nothing like that).
>
> My understanding is that ARM64-based Linux is still a marginally used
> platform so probably not worth for us to allocate resources on adding it
> to our daily builds at the moment. If it ever becomes more mainstream in
> the future, then we will certainly reconsider. That does not mean that
> you can't use Bioconductor on a ARM64-based Linux machine **now**. I see
> no reason a priori why you couldn't install (from source) Bioconductor
> packages on this platform, and use them, as long as:
>
> - R is supported on your ARM64-based Linux machine
>
> - you have compilers that are supported by R
>
> - you have the external libraries that are required by some CRAN and/or
> Bioconductor packages.
>
> Hope this helps,
>
> H.
>
> On 05/01/2023 02:01, Martin Grigorov wrote:
> > Dear community,
> >
> > Happy and successful new year!
> >
> > Appologies if this has been discussed before but
> > https://stat.ethz.ch/pipermail/bioc-devel/ does not provide 

[Bioc-devel] Support for Linux ARM64

[Martin Grigorov]

Dear community,

Happy and successful new year!

Appologies if this has been discussed before but
https://stat.ethz.ch/pipermail/bioc-devel/ does not provide search
facilities and my googling didn't help much!

I'd like to ask whether Linux ARM64 is officially supported ?
I know that Mac ARM64 is supported since 3.16 [1] [2].
I cannot find such test results for Linux ARM64 and the site search [3]
also mentions "arm64" only in context of "macOS".
In addition the Docker images are also single-platform [4] (linux/amd64).

How can we help to add support for Linux ARM64 ?
My employer is willing to donate VMs and man power if the community is
interested in adding support for Linux ARM64!


Regards,
Martin

1. https://bioconductor.org/news/bioc_3_16_release/
2. https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/
3. https://bioconductor.org/help/search/index.html?q=arm64/
4. https://hub.docker.com/r/bioconductor/bioconductor_docker/tags

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel