Re: [Bioc-devel] muleaData problems reported in the Build/check report for BioC 3.19 experimental data

[Mike Smith]

Hi Eszter,

If you're using ExperimentHub in your vignette then you need to add that to
the Suggests field in your DESCRIPTION file.

The R CMD check output you linked to mentions a similar issue for the code
in your examples:

* checking for unstated dependencies in examples ... WARNING
'::' or ':::' imports not declared from:
  ‘ExperimentHub’ ‘dplyr’
'library' or 'require' calls not declared from:
  ‘ExperimentHub’ ‘dplyr’

That should also be fixed by putting those packages in Suggests.

Cheers,
Mike

On Wed, 20 Mar 2024 at 09:54, Eszter Ari  wrote:

> Hi,
>
> I have a question a problem reported in the Build/check report for BioC
> 3.19 experimental data:
> I have created an experimental data package:
> https://github.com/ELTEbioinformatics/muleaData
> I have got this message from
> bbs-nore...@bioconductor.org:
> According to the Build/check report for BioC 3.19 experimental data,
> the muleaData package has the following problem(s):  o ERROR for 'R CMD
> check' on nebbiolo1. See the details here:
>
>
> https://master.bioconductor.org/checkResults/3.19/data-experiment-LATEST/muleaData/nebbiolo1-checksrc.htmlAs
> I see on the link there is a problem with the muleaData.Rmd file.
> Previously I have been asked by @lshepherd
>  to make the 'install' R
> code chunk to eval=FALSE:
>
> https://github.com/Bioconductor/Contributions/issues/3291#issuecomment-1978971419
>
> ```{r 'install', eval=FALSE}
> if (!require("BiocManager", quietly = TRUE))
> install.packages("BiocManager")
>
> BiocManager::install("ExperimentHub")
> BiocManager::install("muleaData")
> ```
>
> Then the next 'example' chunk cannot be run:
>
> ```{r 'example'}
>
> # Calling the ExperimentHub library.
> library(ExperimentHub)
>
> # Downloading the metadata from ExperimentHub.
> eh <- ExperimentHub()
>
> # Creating the muleaData variable.
> muleaData <- query(eh, "muleaData")
>
> # Checking the muleaData variable.
> muleaData
>
> # Looking for the ExperimentalHub ID of i.e. target genes of transcription
> # factors from TFLink in Caenorhabditis elegans.
> mcols(muleaData) %>%
> as.data.frame() %>%
> dplyr::filter(species == "Caenorhabditis elegans" &
> sourceurl == "https://tflink.net/;)
>
> # Creating a variable for the GMT data.frame of EH8735.
> # EH8735 contains small-scale measurement results, where the target genes
> are
> # coded with Ensembl ID-s
> Transcription_factor_TFLink_Caenorhabditis_elegans_SS_EnsemblID <-
> muleaData[["EH8735"]]
> ```
>
> *Should I change to eval=FALSE this chunk as well? *
>
> Ari, Eszter, habil, PhD
> ariesz...@gmail.com +36 (70) 380 9833
> postdoctoral researcher at *Synthetic and Systems Biology Unit, Biological
> Research Centre, ELKH, Szeged, Hungary*
> assistant professor at *Dep. Genetics, Eötvös Loránd University, Budapest,
> Hungary*
>
> [[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] xcms error with R CMD check "checking loading without being on the library search path"

[Mike Smith]

Hi Johannes,

I think RCurl is imported via the package dependency chain of xcms ->
SummarizedExperiment -> GenomeInfoDb -> RCurl.

It looks like Hervé removed this dependency from GenomeInfoDb recently (
https://code.bioconductor.org/browse/GenomeInfoDb/commit/9562907f6800cf6052fff9fb2f85329ff44790b6),
and the change is present in both RELEASE_3_18 and devel.  There was a post
a few weeks ago about how a few heavily used CRAN packages are essentially
abandoned (XML and RCurl) and there's been a bit of a concerted effort to
move away from them in the core BioC packages if possible - hence why Hervé
has made that change.

As for why R CMD check is complaining, my guess would be that you have some
saved data in xcms that expects RCurl to be available when it is loaded -
presumably this object was created when the dependency chain above was
valid.  Now GenomeInfoDb has been changed, RCurl doesn't get installed with
xcms in a fresh R/Bioconductor install like your Docker container.  Then
when you load the object via data() R complains about missing the expected
RCurl package.  That's just an educated guess, but seems plausible to me.

Best,
Mike

On Wed, 13 Mar 2024 at 10:10, Rainer Johannes 
wrote:

> Dear all,
>
> we're having some rather strange errors with R CMD check on the xcms
> package recently: it will fail with this warning (which then becomes an
> error):
>
> ✔  checking whether the namespace can be loaded with stated dependencies
> (5.9s)
> ✔  checking whether the namespace can be unloaded cleanly (6.1s)
> W  checking loading without being on the library search path (5.3s)
>Loading required package: BiocParallel
>Loading required package: MSnbase
>Loading required package: BiocGenerics
>
>Attaching package: ‘BiocGenerics’
>
>The following objects are masked from ‘package:stats’:
>
>IQR, mad, sd, var, xtabs
>
>The following objects are masked from ‘package:base’:
>
>Filter, Find, Map, Position, Reduce, anyDuplicated, aperm, append,
>as.data.frame, basename, cbind, colnames, dirname, do.call,
>duplicated, eval, evalq, get, grep, grepl, intersect, is.unsorted,
>lapply, mapply, match, mget, order, paste, pmax, pmax.int, pmin,
>pmin.int, rank, rbind, rownames, sapply, setdiff, sort, table,
>tapply, union, unique, unsplit, which.max, which.min
>
>Loading required package: Biobase
>Welcome to Bioconductor
>
>Vignettes contain introductory material; view with
>'browseVignettes()'. To cite Bioconductor, see
>'citation("Biobase")', and for packages 'citation("pkgname")'.
>
>Loading required package: mzR
>Loading required package: Rcpp
>Loading required package: S4Vectors
>Loading required package: stats4
>
>Attaching package: ‘S4Vectors’
>
>The following object is masked from ‘package:utils’:
>
>findMatches
>
>The following objects are masked from ‘package:base’:
>
>I, expand.grid, unname
>
>Loading required package: ProtGenerics
>
>Attaching package: ‘ProtGenerics’
>
>The following object is masked from ‘package:stats’:
>
>smooth
>
>
>This is MSnbase version 2.28.1
>  Visit https://lgatto.github.io/MSnbase/ to get started.
>
>
>Attaching package: ‘MSnbase’
>
>The following object is masked from ‘package:base’:
>
>trimws
>
>Loading required package: RCurl
>Error: package or namespace load failed for ‘xcms’ in
> .requirePackage(package):
> unable to find required package ‘RCurl’
>In addition: Warning message:
>In library(package, lib.loc = lib.loc, character.only = TRUE,
> logical.return = TRUE,  :
>  there is no package called ‘RCurl’
>Execution halted
>
>It looks like this package has a loading problem when not on .libPaths:
>see the messages for details.
>
>
> This is rather puzzling, since we're not using, requiring or importing
> RCurl at all. Also, so far I've never seen this check "checking loading
> without being on the library search path" before.
>
> I will try to figure out what is going on and where/which package is
> causing this problem, but would be great if someone has a solution or at
> least a hint.
>
> thanks!
> jo
>
> I was running this for xcms from the RELEASE_3_18 branch using the
> bioconductor/bioconductor_docker:RELEASE_3_18. The sessionInfo (after
> loading xcms):
>
> > sessionInfo()
> R version 4.3.2 (2023-10-31)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 22.04.3 LTS
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
> LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;
> LAPACK version 3.10.0
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_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
> 

Re: [Bioc-devel] Possible https://code.bioconductor.org SSL certificate issue

[Mike Smith]

Certificate updated with the full chain.  Strike this one down to user
error on my part.

It looks like it's now working with curl from my perspective.  Please let
me know if that's not the case, either by replying here or opening an issue
at https://github.com/Bioconductor/code.bioconductor.org

Cheers,
Mike

On Wed, 6 Mar 2024 at 16:39, Mike Smith  wrote:

> Maintainer of the code.bioconductor.org site here.  Thanks for the
> report.
>
> The certificate is exactly the same as the one used by all other
> bioconductor.org sites, however we recently changed (February 21st) how
> it is applied to the code.bioconductor.org subdomain.  Did you happen to
> try this more than a few weeks ago and it worked?  Our testing was done in
> the browser, which as others have said seems to work, but I also see the
> issue with curl.
>
> I'll talk to our IT department about whether this is related to that
> change we made - they'll probably be interested in case the issue would
> also apply to other sites we host.  I'll report back here if we change
> things.
>
> Cheers,
> Mike
>
> On Wed, 6 Mar 2024 at 09:00, Gábor Csárdi  wrote:
>
>> Anyone know where to report issues with code.bioconductor.org?
>>
>> This is what I see from a vanilla Ubuntu 22.04 (and also from Fedora
>> 40/41, etc.):
>>
>> root@6bff5eca88b0:~# curl https://code.bioconductor.org/
>> curl: (60) SSL certificate problem: unable to get local issuer certificate
>> More details here: https://curl.se/docs/sslcerts.html
>>
>> curl failed to verify the legitimacy of the server and therefore could not
>> establish a secure connection to it. To learn more about this situation
>> and
>> how to fix it, please visit the web page mentioned above.
>>
>> Gabor
>>
>> ___
>> 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] Possible https://code.bioconductor.org SSL certificate issue

[Mike Smith]

Maintainer of the code.bioconductor.org site here.  Thanks for the report.

The certificate is exactly the same as the one used by all other
bioconductor.org sites, however we recently changed (February 21st) how it
is applied to the code.bioconductor.org subdomain.  Did you happen to try
this more than a few weeks ago and it worked?  Our testing was done in the
browser, which as others have said seems to work, but I also see the issue
with curl.

I'll talk to our IT department about whether this is related to that change
we made - they'll probably be interested in case the issue would also apply
to other sites we host.  I'll report back here if we change things.

Cheers,
Mike

On Wed, 6 Mar 2024 at 09:00, Gábor Csárdi  wrote:

> Anyone know where to report issues with code.bioconductor.org?
>
> This is what I see from a vanilla Ubuntu 22.04 (and also from Fedora
> 40/41, etc.):
>
> root@6bff5eca88b0:~# curl https://code.bioconductor.org/
> curl: (60) SSL certificate problem: unable to get local issuer certificate
> More details here: https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
>
> Gabor
>
> ___
> 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

[Mike Smith]

Hi Sokratis,

You can view the commit history of your package in the Bioconductor
repository by visiting
https://code.bioconductor.org/browse/omada/commits/devel

You can select the different branches from the drop down in  the top left
corner.  It looks like you successfully pushed to the devel branch, but
there aren't any recent updates to RELEASE_3_18.

If you do make more changes, be aware it might take 15 minutes before they
appear on that site. It updates frequently, so that's the longest you
should need to wait.

Best,
Mike

On Fri, 9 Feb 2024 at 03:28, Sokratis Kariotis 
wrote:

> Hey,
>
> Hope I find you well! I have pushed some changes in devel and (I believe)
> in branch RELEASE_3_18. Could you check if it was done correctly and
> whether it can reflect in the current available version? The updates were
> minor but required for journal publication. Thanks!
>
> Regards,
> Dr. Sokratis Kariotis
>
> On Wed, Sep 13, 2023 at 12:42 AM Lori Shepherd 
> wrote:
>
>> It would be great if you were able to also update the current release
>> RELEASE_3_17 branch so that the current users can use the package and so
>> that a broken version of the package is not saved for the Bioc 3.17 version
>> of packages.  But the package will be ok for the new release as long as it
>> is fixed in devel and will progate the fixed package at the end of October
>> to the new release.
>>
>>
>>
>> Lori Shepherd - Kern
>>
>> Bioconductor Core Team
>>
>> Roswell Park Comprehensive Cancer Center
>>
>>
>> On Mon, Sep 11, 2023 at 10:05 PM Sokratis Kariotis <
>> sokratiskario...@gmail.com> wrote:
>>
>>> Hey,
>>>
>>> Will the package be ok for the new release even though I still get the
>>> same
>>> error?
>>>
>>> Cheers,
>>> Sokratis
>>>
>>> On Thu, Aug 17, 2023 at 3:38 PM Mike Smith  wrote:
>>>
>>> > Hi Sokratis,
>>> >
>>> > You've address the problems successfully in the devel branch (3.18) but
>>> > they remain in the release (3.17), so you're probably still getting the
>>> > messages relating to these builds (
>>> > https://bioconductor.org/checkResults/3.17/bioc-LATEST/omada/).
>>> >
>>> > To fix this you'll need to checkout the RELEASE_3_17 branch, and then
>>> make
>>> > the same changes you've already applied.  You can either do that via
>>> git
>>> > cherry-pick and select the appropriate commits from devel branch, or
>>> > perhaps more straightforward is to just copy/paste the relevant
>>> sections.
>>> > Then bump the RELEASE_3_17 version number to 1.2.1 and push that
>>> branch.
>>> > Hopefully this will fix the issues there too.
>>> >
>>> > Best,
>>> > Mike
>>> >
>>> > On Thu, 17 Aug 2023 at 03:47, Sokratis Kariotis <
>>> > sokratiskario...@gmail.com> wrote:
>>> >
>>> >> Hey all,
>>> >>
>>> >> I can see all is green but I still get messages about failing builds
>>> and
>>> >> on
>>> >> the website shows build error. Do I still have to do something?
>>> Thanks in
>>> >> advance.
>>> >>
>>> >> Regards,
>>> >> Sokratis
>>> >>
>>> >> On Thu, Aug 10, 2023 at 2:53 PM Martin Grigorov <
>>> >> martin.grigo...@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > 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,
>>> >> >>>
&

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

[Mike Smith]

Hi Martin,

A very short summary is that on kjohnson3 a build/check on package launched
by cron takes significantly longer than if one runs the same command
manually in a terminal.

There's some further discussion on this at
https://community-bioc.slack.com/archives/CEQ04GKEC/p1706816310942079 and
and Jen has some nice documentation of their investigation at
https://github.com/Bioconductor/BBS/issues/387

However since the original inquiry in this thread is about a package in
submission, and so the relevant tests are run by the single package builder
on merida1, I'm not sure it's pertinent to this particular issue.

Cheers,
Mike

On Wed, 7 Feb 2024 at 16:34, Martin Grigorov 
wrote:

> 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 <
> jacopo.ron...@unimib.it>
> > > > 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
> > 

Re: [Bioc-devel] Diverging version numbering on Bioconductor RELEASE

[Mike Smith]

Personally I do as Steffen mentioned, and grab the upstream changes
manually.  Changes not introduced by me only happen once every 6 months,
and I'm involved enough with Bioconductor that I generally know when the
release and version bump has occurred, so it's never quite felt like enough
work to implement an automatic workflow.  I think I'm just as likely to
forget to put the changes from GitHub to my local machine, and still end up
with a merge conflict at some point.

However, I think you should be able to use this action from the
marketplace to achieve the automatic syncing without too much work creating
the workflow:

https://github.com/marketplace/actions/upstream-sync

Cheers,
Mike

On Wed, 15 Nov 2023 at 12:22, migdal migdal  wrote:

> Awesome, thanks for the response!
>
> I think it should be possible to put what you are doing manually into
> GithubActions script, but I am not sure how to do that.
>
> On Wed, Nov 15, 2023, 12:12 Neumann, Steffen 
> wrote:
>
> > Hi,
> >
> > so far I am doing this manually, I have my github as remote origin,
> > and the bioc git as upstream, and indeed after the releases I pull from
> > upstream the changed version number and push it to my origin on github.
> >
> > Yours,
> > Steffen
> >
> > On Sat, 2023-11-11 at 09:35 +0100, migdal migdal wrote:
> > > Hi guys,
> > >
> > > recently I have realized that the version number in one of my
> > > packages does
> > > not match with the version in the bioconductor repository (
> > > https://github.com/Genentech/midasHLA/issues/27
> > > ). The reason is that, while
> > > I have been doing no changes past the last few releases a version
> > > bump was
> > > happening on each Bioconductor RELEASE.
> > >
> > > Does anyone use some automated way to synchronise between the
> > > repositories?
> > > GitHub Actions would be an ideal solution.
> > >
> > > Cheers Maciek
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> > --
> > Upcoming events:
> >
> > * 2nd ELIXIR-DE Hackathon, 11-15 December 2023 in Bielefeld
> >  https://www.denbi.de/de-nbi-events/1547-biohackathon-germany-2
> >
> >
> > ---
> > IPB HalleComputational Plant Biochemistry (CPB)
> > Dr. Steffen Neumann  http://www.ipb-halle.de/
> > Weinberg 3   Tel. +49 (0) 345 5582 - 1470
> > 06120 Halle   +49 (0) 345 5582 - 0
> > sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> [[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] Package check error under BiocVersion 3.18

[Mike Smith]

Hi,

As you surmise, it looks like this is a conflict between Matrix and
SeuratObject.  It's reported in quite a few places e.g.
https://github.com/satijalab/seurat/issues/7986

I don't think there's much you can do except wait for the Seurat
maintainers to release an update to their package.  Given that the issue is
already closed as complete, hopefully that won't be too long. Then you'll
need to wait a bit longer for the Bioconductor Build System to install that
updated version - I'm not sure how often the BBS updates non-Bioconductor
packages.

Slightly frustrating, but this is the risk we take when using other
packages.  Generally speaking the effort saved in not reinventing all the
cool stuff in Matrix & Seurat yourself is worth this hassle.  Personally, I
trust the Seurat developers will address this in a timely manner.

Cheers,
Mike

On Sun, 12 Nov 2023 at 04:48, Jinjin Chen via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hi,
>
> I got check error for my package after new release 3.18 of bioconductor on
> all 3 platforms (linux, windows and macOS). The build report shows the
> error like this:
>
> Error in validObject(.Object) :
>   invalid class “LogMap” object: superclass "mMatrix" not defined in the
> environment of the object's class
>
> But when I check the devel BiocVersion 3.19 report, it's OK under linux OS
> but failed with the same error under windows and macOS.
>
> I guess this is caused by the conflicts between Seurat and Matrix package?
> Could you please help me figure out how to fix this?
>
> Thanks!
>
> PhD student, Davis Laboratory
> Bioinformatics Division
> The Walter and Eliza Hall Institute of Medical Research
>
>
> [WEHI Logo]
>
>
> Walter and Eliza Hall Institute of Medical Research
> 1G Royal Parade Parkville Victoria 3052 Australia
>
> www.wehi.edu.au
>
> Twitter  |  Facebook<
> https://www.facebook.com/WEHIresearch/>  |  Instagram<
> https://www.instagram.com/wehi_research>  |  Youtube<
> https://www.youtube.com/user/WEHImovies>  |  LinkedIn<
> https://www.linkedin.com/company/wehi_research>
>
>
> WEHI acknowledges the Wurundjeri people of the Kulin Nation as the
> traditional owners of the land where our campuses are located and the
> continuing connection to country and community.
>
> Private and confidential
> The content of this e-mail and any attachments may be private and
> confidential, intended only for use of the individual or entity named. If
> you are not the intended recipient of this message you must not read,
> forward, print, copy, disclose, use or store in any way the information
> this e-mail or any attachment contains. If you are not the intended
> recipient, please notify the sender immediately and delete or destroy all
> copies of this e-mail and any attachment.
>
> [[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

[Mike Smith]

Hi Ali,

I don't know the specifics of how the bioc-issue-bot checks submissions
(someone from the core team would know better), but I suspect you're
failing that file size test before the package is built.  Thus adding to
.Rbuildignore probably wont help for this specific issue.  I would still
think about compressing those files and then cleaning the git repository of
the original uncompressed versions by following
http://contributions.bioconductor.org/git-version-control.html#remove-large-data-files-and-clean-git-tree

More generally, yes you want to exclude those files from the built packages
if they aren't useful to the end user of the package.  However it looks
like you're already excluding the raw and data-raw directories via
.Rbuildignore, so I don't think you need to do more than that.

Best,
Mike



On Tue, 5 Sept 2023 at 19:15, Ali Sajid Imami 
wrote:

> Hi Mike,
>
> These are raw data files that I use to createte internal data. They don’t
> end up being used in the final package themselves. Are you suggesting that
> adding them to .Rbuildignore should be sufficient? They are in the repo
> because I want to keep track of them.
>
> On Sep 5, 2023, at 4:54 AM, Mike Smith  wrote:
>
> Hi Ali,
>
> Looking at the files, it seems although the file extension is .xls,
> they're actually just plain text TSV files.  They compress pretty well with
> standard tools and R is able to easily read a tsv compressed with something
> like GZIP. I wonder if you've considered just compressing the files and
> otherwise using them as they are.  The Hub approaches are neat, but maybe
> overkill if the files are < 2MB compressed.
>
> However, I wonder if it's necessary to distribute them with the package at
> all.  Perhaps I'm missing it, but I don't see any reference to reading
> those files in your code, and the contents already appear to be held in
> sysdata.rda.  IMO it would be sufficient to document how sysdata.rda was
> created in a README so others can see how it was created (perhaps hosting
> those files on your own S3 storage if you have permission to do so) and
> then remove the raw files from the package.
>
> Best wishes,
> Mike
>
> On Thu, 31 Aug 2023 at 20:08, Ali Sajid Imami 
> wrote:
>
>> Hi,
>>
>> The file is downloaded and filtered from the ilincs website. Unfortunately
>> it is not readily available from ilincs.org itself. We have the
>> capability
>> of storing the file in our S3 buckets, however.
>>
>> The metadata under discussion is metadata related to each individual
>> signature stored in iLINCS, including information about the cell lines,
>> the
>> time points and the dosages. From what I understand this is more likely to
>> be suited for ExperimentHub since it's processed.
>>
>>
>> Regards,
>> Dr. Ali Sajid Imami
>> LinkedIn <https://pk.linkedin.com/pub/ali-sajid-imami/50/956/2a6>
>>
>>
>> On Thu, Aug 31, 2023 at 12:02 PM Kern, Lori via Bioc-devel <
>> bioc-devel@r-project.org> wrote:
>>
>> > Hello,
>> >
>> > Regarding Hub use:
>> > What sort of information does the metadata contain? That would determine
>> > whether ExperimentHub or AnnotationHub is more appropriate. Is the file
>> > accessed directly from the http://ilincs.org/ portal with a url link or
>> > is there processing/filtering that occurs?  The hubs can access data
>> stored
>> > on other websites/hosts as long as they are trusted sites (ilincs would
>> > fall in this category) if you can access it directly with a url link.
>> The
>> > way the hubs work is the data is stored elsewhere either directly from
>> site
>> > access or on some hosting serve (S3, Azure, etc) if its processed. The
>> data
>> > would be removed from directly being in the package, and downloaded then
>> > using the hub interface when needed (and also cached in the backend so
>> its
>> > not done every time).
>> >
>> >
>> >
>> >
>> >
>> > 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
>> Vincent
>> > Carey 
>> > Sent: Thursday, August 31, 2023 8:29 AM
>> > To: Martin Grigorov 
>> > Cc: bioc-devel@r-project.org 
>> > Subject: Re: [Bioc-devel] Including large files for the packa

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

[Mike Smith]

Hi Ali,

Looking at the files, it seems although the file extension is .xls, they're
actually just plain text TSV files.  They compress pretty well with
standard tools and R is able to easily read a tsv compressed with something
like GZIP. I wonder if you've considered just compressing the files and
otherwise using them as they are.  The Hub approaches are neat, but maybe
overkill if the files are < 2MB compressed.

However, I wonder if it's necessary to distribute them with the package at
all.  Perhaps I'm missing it, but I don't see any reference to reading
those files in your code, and the contents already appear to be held in
sysdata.rda.  IMO it would be sufficient to document how sysdata.rda was
created in a README so others can see how it was created (perhaps hosting
those files on your own S3 storage if you have permission to do so) and
then remove the raw files from the package.

Best wishes,
Mike

On Thu, 31 Aug 2023 at 20:08, Ali Sajid Imami 
wrote:

> Hi,
>
> The file is downloaded and filtered from the ilincs website. Unfortunately
> it is not readily available from ilincs.org itself. We have the capability
> of storing the file in our S3 buckets, however.
>
> The metadata under discussion is metadata related to each individual
> signature stored in iLINCS, including information about the cell lines, the
> time points and the dosages. From what I understand this is more likely to
> be suited for ExperimentHub since it's processed.
>
>
> Regards,
> Dr. Ali Sajid Imami
> LinkedIn 
>
>
> On Thu, Aug 31, 2023 at 12:02 PM Kern, Lori via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
> > Hello,
> >
> > Regarding Hub use:
> > What sort of information does the metadata contain? That would determine
> > whether ExperimentHub or AnnotationHub is more appropriate. Is the file
> > accessed directly from the http://ilincs.org/ portal with a url link or
> > is there processing/filtering that occurs?  The hubs can access data
> stored
> > on other websites/hosts as long as they are trusted sites (ilincs would
> > fall in this category) if you can access it directly with a url link.
> The
> > way the hubs work is the data is stored elsewhere either directly from
> site
> > access or on some hosting serve (S3, Azure, etc) if its processed. The
> data
> > would be removed from directly being in the package, and downloaded then
> > using the hub interface when needed (and also cached in the backend so
> its
> > not done every time).
> >
> >
> >
> >
> >
> > 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 Vincent
> > Carey 
> > Sent: Thursday, August 31, 2023 8:29 AM
> > To: Martin Grigorov 
> > Cc: bioc-devel@r-project.org 
> > Subject: Re: [Bioc-devel] Including large files for the package
> >
> > On Thu, Aug 31, 2023 at 7:28 AM Martin Grigorov <
> martin.grigo...@gmail.com
> > >
> > wrote:
> >
> > > Hello,
> > >
> > > Perhaps you could use
> >
> https://secure-web.cisco.com/1PWeIBsHtYFpwnIBjpsq_YN8z0VkqqbOqtHQk4ITS1RC58_4Mploz6OJS4-Uxw4jq_g9JHqlT9Wq6tkKR-aBwYiSF6Bf-ajT-d7vnHBJlAHNLxs2Y3F979xVFa07xAiyrpeXtgfU0dHry6aNaTQmruT5HzYIplDg0UVfcLK9976qFmnnwuRbo24PxtCSMLTLKbVqlHi_URSb7MYdKpuxIP8SmFalHHQUUZWSG9NT1XSeuTkw8pXPtGzJPB2vyj-zO3-cy9RUHz5gLoFe53a3qV2cRVz7ov7WXhLErjX9fqk7A-EQOQSq5QeyWzmoonEUu/https%3A%2F%2Fbioconductor.r-universe.dev%2FBiocFileCache
> > 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.
> > >
> >
> > Thanks Martin.  I think that is a possible approach, but the proposals at
> >
> >
> http://secure-web.cisco.com/1PN99uHlZGkagOQGmEM4lhVob-mny_wuOMrU_eG-JFkBnBX5W-tXbKupcTbZ-gSq-XMcO9_rg2sGp_3KwriGP5nkPGjk_bL8O5IxcEaPE04uFIvB_UVQh-2NzX-1LfalQo2nPrpuxM3FDJJJPRBz8pjayIb27ThNpZZQI50lyjOLdJUikYdS5-Y4TlTMDGCPfs_854qpfJREWoKeYTJOpRb-95SzxaPxDp2qePIkigSmQzj1JrjIfCYyLGCVIIq1Zz1-kbIEqem7cvMtWe2ZE_Af1yG9wA-51shDuYxapn9yaETK7E8Rsg_OTsp4yfB-R/http%3A%2F%2Fcontributions.bioconductor.org%2Fnon-software.html%3Fq%3DAnnotationHub%23annotationexperiment-hub-packages
> > should also be considered.
> >
> > Ali, if the documentation regarding *Hub contributions is unclear, please
> > file an
> > issue or write back here with the difficulties so that we can improve the
> > material and
> > the methods!
> >
> > Thanks!
> >
> >
> >
> > >
> > > Regards,
> > > Martin
> > >
> > > On Tue, Aug 29, 2023 at 5:15 AM Ali Sajid Imami <
> > ali.sajid.im...@gmail.com
> > > >
> > > 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
> > 

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

[Mike Smith]

Hi Sokratis,

You've address the problems successfully in the devel branch (3.18) but
they remain in the release (3.17), so you're probably still getting the
messages relating to these builds (
https://bioconductor.org/checkResults/3.17/bioc-LATEST/omada/).

To fix this you'll need to checkout the RELEASE_3_17 branch, and then make
the same changes you've already applied.  You can either do that via git
cherry-pick and select the appropriate commits from devel branch, or
perhaps more straightforward is to just copy/paste the relevant sections.
Then bump the RELEASE_3_17 version number to 1.2.1 and push that branch.
Hopefully this will fix the issues there too.

Best,
Mike

On Thu, 17 Aug 2023 at 03:47, Sokratis Kariotis 
wrote:

> Hey all,
>
> I can see all is green but I still get messages about failing builds and on
> the website shows build error. Do I still have to do something? Thanks in
> advance.
>
> Regards,
> Sokratis
>
> On Thu, Aug 10, 2023 at 2:53 PM Martin Grigorov  >
> wrote:
>
> > 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, <
> >>>> martin.grigo...@gmail.com>
> >>>> 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:*
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >>
&g

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

[Mike Smith]

Hi Sokratis,

You won't see an update in the build report for 24-48 hours.  The build
process happens at a specific time each day across all packages, you can't
trigger it manually, and the reports don't update until every package has
been built.  That takes about a day to complete.  If you're lucky and
commit just before the process starts it'll still be ~24 hours before you
see the results.  If you're unlucky and submit just after it'll be 2 days
before the changes are reflected in the report.

If you're interested, on
https://bioconductor.org/checkResults/3.18/bioc-LATEST/omada/ there's a
section called "Snapshot Data" which tells you when the build process
started.  At the top of the page there's "This page was generated on" which
indicates when the report was posted.

However, you can check your commits have arrived in the repository by
taking a look at https://code.bioconductor.org/browse/omada/commits/devel
That site updates every 15 minutes, and I see three new commits in the last
day, so it looks like the git commands are working for you.  Now you can
just wait to see how the next report looks.

On Tue, 1 Aug 2023 at 10:26, Sokratis Kariotis 
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  >
> 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

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

[Mike Smith]

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 
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 
> 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  >
> > 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 expert so not sure if that would be good enough but
> that
> > would be my take on it.
> >
> > Lori Shepherd - Kern
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> > --
> > *From:* Oleksii Nikolaienko 
> > *Sent:* Thursday, July 6, 2023 1:58 AM
> > *To:* Sokratis Kariotis 
> > *Cc:* Kern, Lori ;
> bioc-devel@r-project.org
> > 
> > *Subject:* Re: [Bioc-devel] Omada package failing due to removed
> > dependency
> >
> > https://nonstationarity.sciencesconf.org/resource/page/id/7
> > <
> https://secure-web.cisco.com/1pCvxIL3lfzw2yMAoq1pXQ5JiavYeyZHI2qtDauHw4xwZZBxaV-dAKGWcVKgwz09vF4YJJGVvkcQloDj0mJOUxj7BI3WPu_1Ze3vDW0a9syxuRsiQNOGsRkJ8BaWBdlxOdRBAw39KujDDGqb_DPfL6IsjHK5UCqoCpzw39GduVcBLFIutoPM8Nqjgp8ArDuh-oK-Bxe-huDYCoLXUX5GyU_fEG81AEtF-osCFtJNLRiQBggrsxcViF8mNihzVj8-UT4cNawHmz7xye_KNs45WZOxnVljiq5QQHuIGCeXRkbYBUvrpcEoTootlVxLloYK0/https%3A%2F%2Fnonstationarity.sciencesconf.org%2Fresource%2Fpage%2Fid%2F7
> >
> > That is, perhaps, not surprising...
> >
> > Package seems to be too good to be abandoned. I wonder if anyone from
> > their lab
> > <
> https://secure-web.cisco.com/1IisY82Mh0-7_0tTgq7v7MgjvGFKIBucg15oqE_SNpUPzwuvYYaCPgz427Efo9Xga7j3PYM6msIsM8GJAK7ofsjmhrfAG3_kBGCmTdF0gVYBUz17CdZjNygLUpDMXPSt6h5CfKAjX_SrymhwTWvvEuyH1cH3nCYhVkVd5xfdd2W5azA0g9MJ4bPASnxJwY9quFxu_6CAIuYXkkO_DqiO9NC6Nb22USMev1V4qh5A3IX2kg6l60sRbM9gDQWjNwbJAPSnWq9G5setIw9CNP8avnjON5nhm_cjNhhn6s6kY07wwiSQ4sSQqsekskzOjhbm1/https%3A%2F%2Fmodalx.parisnanterre.fr%2Fmembres
> >
> > could take over maintenance, if you still bother to 

Re: [Bioc-devel] Can't reproduce a latex error

[Mike Smith]

Hi Mark,

I don't know how to identify the Latex used on the build system, but I see
the same problem with GRridge on my system that uses Latex installed via
the tinytex package.

I think the issue is the use of \describe{} in
https://code.bioconductor.org/browse/GRridge/blob/master/man/GRridge-package.Rd#L28

Writing R Extensions suggests the entries in this environment should have
two arguments and might not work otherwise (
https://rstudio.github.io/r-manuals/r-exts/Writing-R-documentation-files.html#lists-and-tables
).

Best regards,
Mike

On Thu, 20 Apr 2023 at 16:14, Wiel, M.A. van de (Mark) <
mark.vdw...@amsterdamumc.nl> wrote:

> My package renders a latex error when compiled by the BioC compilers. I
> can’t, however, reproduce that error when checking locally
> in Rstudio. How can I make sure the same latex settings are used as the
> BioC compilers do?
> -Mark van de Wiel
>
> __
> AmsterdamUMC disclaimer : www.amsterdamumc.org/disclaimers
>
> [[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] Issue with setting Maintainer in new package submission

[Mike Smith]

Hi Andrew,

Perhaps I'm not understanding your workflow correctly, but it looks like
your email in the DESCRIPTION that was uploaded to the Bioc submission
system is an @dfci.harvard.edu one.  That's what I see at
https://github.com/NKInstinct/flowGate/blob/master/DESCRIPTION and it is
the same if I checkout the version on the git.bioconductor.org.

I don't see any problem with the way you've formatted the maintainer field,
so I think if you update both the email and package version number and then
push the changes to the Bioc repository you should see that error go away.

Best,
Mike

On Wed, 22 Feb 2023 at 22:54, Andrew Wight  wrote:

> Hi all - I've just had my new package submission error on build with
>
> ERROR: Maintainer must register at the support site; visit
>   https://support.bioconductor.org/accounts/signup/
>
> However, I am registered on the support site, so I think I've specified the
> maintainer wrong somehow in the DESCRIPTION file, and would appreciate any
> help figuring out what I'm messing up here. Relevant files & debugging I've
> tried is listed below:
>
> *1. Package DESCRIPTION file:*
>
> Package: flowGate
> Type: Package
> Title: Interactive Cytometry Gating in R
> Version: 0.99.0
> Authors@R: c(person("Andrew",
> "Wight",
> email = "andrew.wigh...@gmail.com",
> role = c("aut", "cre")),
>  person("Harvey",
> "Cantor",
> email = "harvey_can...@dfci.harvard.edu",
> role = c("ldr")))
> Description: flowGate adds an interactive Shiny app to allow manual
> GUI-based gating of flow cytometry data in R. Using flowGate,
> you can draw 1D and 2D span/rectangle gates, quadrant gates,
> and polygon gates on flow cytometry data by interactively drawing
> the gates on a plot of your data, rather than by specifying gate
> coordinates. This package is especially geared toward wet-lab
> cytometerists looking to take advantage of R for cytometry
> analysis, without necessarily having a lot of R experience.
> License: MIT + file LICENSE
> Encoding: UTF-8
> LazyData: false
> Imports:
> shiny (>= 1.5.0),
> BiocManager (>= 1.30.10),
> flowCore (>= 2.0.1),
> dplyr (>= 1.0.0),
> ggplot2 (>= 3.3.2),
> rlang (>= 0.4.7),
> purrr,
> tibble,
> methods
> Depends:
> flowWorkspace (>= 4.0.6),
> ggcyto (>= 1.16.0),
> R (>= 4.2)
> RoxygenNote: 7.2.3
> Suggests:
> knitr,
> rmarkdown,
> stringr,
> tidyverse,
> testthat
> VignetteBuilder: knitr
> biocViews:
> Software,
> WorkflowStep,
> FlowCytometry,
> Preprocessing,
> ImmunoOncology,
> DataImport
>
> *2. Confirming that I'm registered to the support site:*
> https://support.bioconductor.org/api/email/andrew.wight10%40gmail.com/
> returns TRUE
>
> *3. Some debugging I've done:*
>
>- calling maintainer("flowGate") returns an empty character, but calling
>desc::desc_get_maintainer() correctly returns me as the maintainer
>- Adding a "Maintainer: Andrew Wight " line
> to
>the DESCRIPTION file completely corrects this error in BiocCheck but
> then
>introduces a new error (since BiocCheck doesn't want me to use the
>Maintainer field)
>- Taken together, this suggests that I've specified the maintainer wrong
>in Authors@R, but for the life of me the only way I can see to do it is
>to add role = "cre" to one of the authors which I've done
>
>
> Again, huge thanks for any help pointing me in the correct direction for
> fixing this!
>
> -Andrew
>
> [[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] Broken stringi install on bioconductor_docker:RELEASE_3_16

[Mike Smith]

Hi Stevie,

I also found this same problem after our emails yesterday and opened an
issue on the Bioconductor_docker repo at
https://github.com/Bioconductor/bioconductor_docker/issues/59

In the short term I think Vince's suggestion of reinstalling stringi should
at least fix your workflow, and hopefully the underlying issue won't be too
tricky for the Bioc team to resolve.

Cheers,
Mike

On Fri, 11 Nov 2022 at 06:17, Stevie Pederson 
wrote:

> Hi,
>
> I've just instantiated a local container for RELEASE_3_16 & have this
> problem:
>
> library(stringi)
> Error: package or namespace load failed for ‘stringi’ in dyn.load(file,
> DLLpath = DLLpath, ...):
>  unable to load shared object
> '/usr/local/lib/R/site-library/stringi/libs/stringi.so':
>   libicui18n.so.66: cannot open shared object file: No such file or
> directory
>
> Not really sure how to fix it and I'm not sure how to file issues for
> docker containers so I hope reporting it here is OK
>
> Thanks,
>
> 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] BiocCheck not available in bioc-devel docker container

[Mike Smith]

Hi Stevie,

To follow up on this, BiocCheck is missing from devel because some changes
in R-devel tripped up a few unit tests, and the package hasn't been built
successfully.  It looks like Marcel has fixed those issues (
https://code.bioconductor.org/browse/BiocCheck/commits/master) and it
should be available in a day or so once the build system has next run.

I see you also ran into the problem where calling system_requirements("ubuntu",
"22.04") gives an error about not being able to use Ubuntu 22.04.  This is
unfortunate as the fix for this was merged into remotes in April (
https://github.com/r-lib/remotes/pull/705) but that version has never made
it to CRAN!  However, since you're running in the Docker container all of
the system requirements are already installed (that's one of the key
reasons to use the container), so you can actually just remove that step
entirely.  If you ever stop using the container you'd need to reinstate it.

Cheers,
Mike



On Wed, 9 Nov 2022 at 12:04, Mike Smith  wrote:

> Hi Stevie,
>
> It might be helpful to link to the workflow runs so people can see exactly
> what you're doing and what's happening.  Hopefully I'm looking in the right
> place at https://github.com/steveped/ngsReports/actions/runs
>
> I'm not sure about the error message regarding BiocCheck.  However there
> are couple of things I noticed in your workflow files for the most recent
> failures, which might help:
>
> In the devel workflow (
> https://github.com/steveped/ngsReports/actions/runs/3425103022/) I'm
> pretty sure r-lib/actions/setup-r has to be given the version 'devel'.
> Using 4.3 won't work because there isn't a URL for R with that version
> until it becomes the latest release.
>
> In the latest release workflow run:
>
>- At line 54 (
>
> https://github.com/steveped/ngsReports/actions/runs/3426634604/workflow#L54)
>you using the RSPM for Ubuntu Focal and
>- At line 118 (
>
> https://github.com/steveped/ngsReports/actions/runs/3426634604/workflow#L118)
>you're calling 'remotes::system_requirements("ubuntu", "20.04"))'
>
> but the docker containers are actually built on Ubuntu 22.04, which is
> Ubuntu Jammy.  I suspect that's the reason you're getting
> the libicui18n.so.66 error, because the binary packages you're installing
> are for a different version of Ubuntu.
>
> Also, this might not simplify your workflow too much, but you could try my
> setup-bioc action (
> https://github.com/grimbough/bioc-actions/tree/v1-branch/setup-bioc)
> which tries to make keeping R and Bioconductor versions in sync a bit
> easier.
>
> Cheers,
> Mike
>
>
> On Wed, 9 Nov 2022 at 04:43, Stevie Pederson <
> stephen.pederson...@gmail.com> wrote:
>
>> Hi,
>>
>> I also can't get my github actions bioc-check workflow running for devel,
>> so I checked the bioc-devel docker image & can't seem to install BiocCheck
>> on that container. Is this likely to be available for devel soon? Error
>> from my local installation of the container below:
>>
>>  BiocManager::install("BiocCheck")
>> 'getOption("repos")' replaces Bioconductor standard repositories, see
>> '?repositories' for details
>>
>> replacement repositories:
>> CRAN: https://cloud.r-project.org
>>
>> Bioconductor version 3.17 (BiocManager 1.30.19), R Under development
>> (unstable) (2022-11-07 r83308)
>> Installing package(s) 'BiocCheck'
>> Warning message:
>> package ‘BiocCheck’ is not available for Bioconductor version '3.17'
>>
>> A version of this package for your version of R might be available
>> elsewhere,
>> see the ideas at
>>
>> https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Installing-packages
>>
>> [[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] BiocCheck not available in bioc-devel docker container

[Mike Smith]

Hi Stevie,

It might be helpful to link to the workflow runs so people can see exactly
what you're doing and what's happening.  Hopefully I'm looking in the right
place at https://github.com/steveped/ngsReports/actions/runs

I'm not sure about the error message regarding BiocCheck.  However there
are couple of things I noticed in your workflow files for the most recent
failures, which might help:

In the devel workflow (
https://github.com/steveped/ngsReports/actions/runs/3425103022/) I'm pretty
sure r-lib/actions/setup-r has to be given the version 'devel'.  Using 4.3
won't work because there isn't a URL for R with that version until it
becomes the latest release.

In the latest release workflow run:

   - At line 54 (
   https://github.com/steveped/ngsReports/actions/runs/3426634604/workflow#L54)
   you using the RSPM for Ubuntu Focal and
   - At line 118 (
   https://github.com/steveped/ngsReports/actions/runs/3426634604/workflow#L118)
   you're calling 'remotes::system_requirements("ubuntu", "20.04"))'

but the docker containers are actually built on Ubuntu 22.04, which is
Ubuntu Jammy.  I suspect that's the reason you're getting
the libicui18n.so.66 error, because the binary packages you're installing
are for a different version of Ubuntu.

Also, this might not simplify your workflow too much, but you could try my
setup-bioc action (
https://github.com/grimbough/bioc-actions/tree/v1-branch/setup-bioc) which
tries to make keeping R and Bioconductor versions in sync a bit easier.

Cheers,
Mike


On Wed, 9 Nov 2022 at 04:43, Stevie Pederson 
wrote:

> Hi,
>
> I also can't get my github actions bioc-check workflow running for devel,
> so I checked the bioc-devel docker image & can't seem to install BiocCheck
> on that container. Is this likely to be available for devel soon? Error
> from my local installation of the container below:
>
>  BiocManager::install("BiocCheck")
> 'getOption("repos")' replaces Bioconductor standard repositories, see
> '?repositories' for details
>
> replacement repositories:
> CRAN: https://cloud.r-project.org
>
> Bioconductor version 3.17 (BiocManager 1.30.19), R Under development
> (unstable) (2022-11-07 r83308)
> Installing package(s) 'BiocCheck'
> Warning message:
> package ‘BiocCheck’ is not available for Bioconductor version '3.17'
>
> A version of this package for your version of R might be available
> elsewhere,
> see the ideas at
>
> https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Installing-packages
>
> [[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] Trouble with version bump

[Mike Smith]

Hi Alex,

Where are you pushing this too?  Maybe the output from git remote -v will
be helpful.

The reason I'm asking is that it looks like SpliceWiz has already been
accepted to Bioconductor, so I wouldn't expect to see messages like "post
on the Github issue where your package is being reviewed", since you've
already completed the review process.

Best regards,
Mike

On Tue, 8 Nov 2022 at 05:35, Alex Wong via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hi there,
>
> I am having difficulty bumping a new version of SpliceWiz onto devel. Below
> is the error on my git bash:
>
> $ git push upstream main:master
> Enumerating objects: 7, done.
> Counting objects: 100% (7/7), done.
> Delta compression using up to 20 threads
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 384 bytes | 384.00 KiB/s, done.Total 4 (delta
> 3), reused 0 (delta 0), pack-reused 0
> remote: Error: Please bump the version again and push.
> remote:
> remote: The build did not start as expected. If the issue persists,
> remote: please reach out at bioc-devel@r-project.org or post on the
> remote: Github issue where your package is being reviewed.
> remote:
> remote: 500 Server Error: Internal Server Error for url:
> https://issues.bioconductor.org/start_build
>
> I have already bumped from 1.1.0 to 1.1.1 and again to 1.1.2 but the error
> message persists.
>
> Thanks in advance,
>
> Alex
>
> --
>
> *Alex Wong BSc(Med)/MBBS FRACP FRCPA PhD*
> Research Officer, Gene and Stem Cell Therapy Program, Centenary Institute
>
> --
>  
>
> [[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

[Bioc-devel] Bioconductor Developers' Forum - The R Universe Project - Thursday 18th November

[Mike Smith]

Hi everyone,

After a hiatus the Developers Forum will be back next Thursday 18th
November at 09:00 PST / 12:00 EST / 18:00 CET - You can find a calendar
invite attached and at https://tinyurl.com/BiocDevel-2021-11

This month Jeroen Ooms will give an overview of the R Universe project (
https://r-universe.dev/).  This project offers individuals or organisations
a platform to build, test and release R packages outside of CRAN or
Bioconductor. As well as being potentially useful to those who are
developing packages, there's also a tonne of infrastructure engineering to
create the build system, and it should be really interesting to learn more
about this.

Please note the meeting details have changed; We're now on Zoom:
https://embl-org.zoom.us/j/99712225827
passcode: bioc-devel

Looking forward to seeing people there,
Best wishes

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

Re: [Bioc-devel] SSL certificate error on nebbiolo2

[Mike Smith]

Hi Nico,

Please try changing your calls to useMart() to useEnsembl().  That function
has some checking that should detect this problem (it's real for all Ubuntu
20.04 users, plus various other Linux distros) and will try to apply the
appropriate fix in the background.  There's some further suggestions in the
biomaRt vignette at if that doesn't work -
https://bioconductor.org/packages/release/bioc/vignettes/biomaRt/inst/doc/accessing_ensembl.html#connection-troubleshooting


The weird certificates that produce the issue are only on the Ensembl
mirror sites, so it should not happen with the default arguments to
useMart(), but if biomaRt finds it's taking > 10 seconds to get a response
it will see if one of the mirrors is more responsive.  That's why it might
take a variable number of tries before reproducing the problem.

Best,
Mike

On Thu, 4 Nov 2021 at 20:42, Hervé Pagès  wrote:

> Hi Nico,
>
> This looks like the usual flakiness of the Ensembl Mart service. I see
> these errors on the build report every day for various packages. The
> exact set of packages varies.
>
> I can reproduce on my laptop (Ubuntu 21.04):
>
>> library(biomaRt)
>
>> ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>
>> ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>
>> ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>
>Ensembl site unresponsive, trying uswest mirror
>
>Error in curl::curl_fetch_memory(url, handle = handle) :
>
>  SSL certificate problem: unable to get local issuer certificate
>
>
> See my sessionInfo() below.
>
> Note that I had to try 3 times before getting the error.
>
> I can also reproduce this with the Docker container for RELEASE_3_14 but
> this time it took me 12 attempts:
>
>  > library(biomaRt)
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset =
> "dmelanogaster_gene_ensembl")
> Ensembl site unresponsive, trying asia mirror
> Error in curl::curl_fetch_memory(url, handle = handle) :
>SSL certificate problem: unable to get local issuer certificate
>
> See my sessionInfo() below.
>
> I'm not sure there's something we can do on our Linux builders about
> this, or if it would be a good idea at all to try to do something (the
> problem is real and can affect anybody using Ubuntu). Maybe discuss this
> with Mike Smith by opening an issue here
> https://github.com/grimbough/biomaRt
>
> Best,
> H.
>
>
> sessionInfo() for my laptop session:
>
>
> R version 4.1.1 (2021-08-10)
>
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> Running under: Ubuntu 21.04
>
>
>
> Matrix products: default
>
> BLAS:   /home/hpages/R/R-4.1.1/lib/libRblas.so
>
> LAPACK: /home/hpages/R/R-4.1.1/lib/libRlapack.so
>
>
>
> 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
>
>
>
> attached base packages:
>
> [1] stats graphics  grDevices utils datasets  methods   base
>
>
>
> other attached packages:
>
> [1] biomaRt_2.50.0
>
>
>
>

Re: [Bioc-devel] Do we have an unpacked archive for BioC, so that we can URL link to individual files ?

[Mike Smith]

Hi Steffen,

Thanks for the feedback.  I've been referencing this email thread when
presenting about developing the code website, so it might be old but it
wasn't forgotten!

Right now I think we still don't quite meet your use case, as
https://code.bioconductor.org/ currently only lists the software packages,
so msdata can't actually be found there.  That choice was because I had
limited disk-space in my prototypes of the site and so didn't try copying
any other type of package, but it doesn't have to remain that way.  I don't
know how much space might be needed for the other types of package, and
it's something I'm happy to consider for the future.

Cheers,
Mike

On Mon, 10 May 2021 at 09:10, Neumann, Steffen 
wrote:

> Hi,
>
> this is a follow-up to a rather old thread, but with
> Mike Smith's (twitter: @grimbough)
>
> https://code.bioconductor.org/
>
> We now have exactly what I had been looking for.
> Thanks Mike and BioC team !
>
> Yours,
> Steffen
>
> On Mon, 2017-11-20 at 17:07 -0500, Martin Morgan wrote:
> > On 11/20/2017 04:58 PM, Robert M. Flight wrote:
> > > So, what if there was a MetaBioconductor site and repo similar to
> > > the
> > > MetaCRAN project? https://www.r-pkg.org/about
> > >
> > > Not sure exactly who maintains it (probably someone at RStudio),
> > > but it
> > > is largely automatic I believe, and it provides a full GitHub
> > > archive of
> > > *all* the packages on CRAN, which if this were done for
> > > Bioconductor
> > > would satisfy what I think Steffen is looking for, as well as lots
> > > of
> > > other advantages.
> > >
> > > It also has the advantage that it looks like 90% of the work would
> > > be
> > > done for Bioconductor with likely very little work required for
> > > the
> > > Bioconductor Admins (ideally 100% of work would be done for them).
> >
> > there has been some discussion of that, e.g.,
> >
> >
> > https://stat.ethz.ch/pipermail/bioc-devel/2017-September/011455.html
> >
> > but we will not do it (maintain a github mirror), for instance
> > because
> > some experiment data packages have commits that would require lfs,
> > because of issues with reliably  syncing data, and because of
> > confusion
> > it introduces on the 'official' repository.
> >
> > We do intend to provide a browsable interface to the official
> > git.bioconductor.org that would allow Steffen's use case during the
> > present release cycle; it is not currently available.
> >
> > A different solution would be to update the relevant ExperimentData
> > package to use ExperimentHub (see, e.g.,
> > https://github.com/LTLA/TENxBrainData for a relatively simple
> > example,
> > though not yet in Bioconductor) and the resource would then be
> > available
> > at a URL https://annotationhub.bioconductor.org/fetch/...
> >
> > Martin
> >
> > > Just a thought.
> > >
> > > -Robert
> > >
> > > Robert M Flight, PhD
> > > Bioinformatics Research Associate
> > > Puller of Rabbits from Hats
> > > Research Parasite
> > > Resource Center for Stable Isotope Resolved Metabolomics
> > > Manager, Systems Biology and Omics Integration Journal Club
> > > Markey Cancer Center
> > > CC434 Roach Building
> > > University of Kentucky
> > > Lexington, KY
> > >
> > > Twitter: @rmflight
> > > Web: rmflight.github.io 
> > > ORCID: http://orcid.org/-0001-8141-7788
> > > EM rfligh...@gmail.com 
> > > PH 502-509-1827 
> > >
> > > To call in the statistician after the experiment is done may be no
> > > more
> > > than asking him to perform a post-mortem examination: he may be
> > > able to
> > > say what the experiment died of. - Ronald Fisher
> > >
> > > On Mon, Nov 20, 2017 at 8:51 AM Martin Morgan
> > >  > > martin.mor...@roswellpark.org>>
> > > wrote:
> > >
> > > On 11/19/2017 06:11 PM, Neumann, Steffen wrote:
> > >  > Hi,
> > >  >
> > >  > thanks for the answer, unfortunately
> > >  > not exactly what I meant. To be more precise:
> > >  >
> > >  > I want to point Galaxy to download (test) MS data files
> > >  > from either the faahKO package, or msdata or mtbls2 in BioC.
> > >  >
> > >  > For that I need an ftp/http/https link to the files,
> > >  > and I was able to use
> > >  >
> > >  >
> > >
> > >
> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/msdata/inst/cdf/ko15.CDF
> > >  >
> > >  > (which still works, but is probably outdated)
> > >  > So is there anything equivalent in the new git setup ?
> > >
> > > no, not from git.bioconductor.org 
> > > ;.
> > >
> > > Martin
> > >
> > >  >
> > >  > Yours,
> > >  > Steffen
> > >  >
> > >  >
> > >  > On Fri, 2017-11-17 at 04:31 -0500, Martin Morgan wrote:
> > >  >> On 11/17/2017 04:08 AM, Neumann, Steffen wrote:
> > >  >>> Hi,
> > >  >>>
> > >  >>> I would like to have a URL to individual files
> > >  >>> we have in BioC packages. This is useful
> > >   

Re: [Bioc-devel] biomaRt error during nigthly 'devel' build

[Mike Smith]

Dear Ilyess,

The Ensembl BioMart server seems to have been intermittent over the last
few days. It looks like both conclus and biomaRt are now building
successfully - hopefully it stays that way.

These issues happen occasionally with packages that access internet
resources, and it's normally worth waiting a couple of build cycles to see
if they clear up on their own.  There's nothing you can do to restart the
build.  There's an automated process managed by the Bioconductor core team,
which builds and checks all the Bioconductor packages once every 24 hours.
If you or another package developer introduce some changes you have to wait
for the following day's report to see their impact.

Best,
Mike



On Fri, 23 Apr 2021 at 13:31, Ilyess RACHEDI  wrote:

> Dear all,
>
> My package has just been accepted but an error occured during the nigthly
> devel build
> Here the report :
> https://master.bioconductor.org/checkResults/3.13/bioc-LATEST/conclus/
>
> It seems to be a SSL certificate problem relative to biomaRt package and
> connection timed out to ensembl server.
>
> What can I do and how can I restart the nigthly devel build ?
>
> Ilyess
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Suppressing messages from Rprofile

[Mike Smith]

Thanks both for the suggestions.

I ended up piping the output to tail -n1 I've no idea how portable that is,
but presumably similar to trying a grep/sed approach.

Cheers,
Mike

On Thu, 8 Apr 2021 at 15:48, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> You could also preprend your cat so it outputs something like
>   INCLUDE_DIR=..
> and then use grep and sed to trim it. Of course that can also end up being
> brittle.
>
> On Wed, Apr 7, 2021 at 10:48 PM Henrik Bengtsson <
> henrik.bengts...@gmail.com> wrote:
>
>> Correcting: the env var is R_LIBS_USER and nothing else.
>>
>> /Henrik
>>
>> On Wed, Apr 7, 2021 at 1:20 PM Henrik Bengtsson
>>  wrote:
>> >
>> > Can you go via a temporary file instead, i.e. output what you want to
>> > grab to a temporary file and pull the info from that instead?
>> >
>> > Side tracking ...
>> >
>> > > I thought about using --vanilla but I use .Rprofile to set my library
>> path,
>> > > so ignoring that file completely defeats the point in my setup.
>> >
>> > I'm a proponent of customizing the library path via .Renviron instead
>> > of via .Rprofile.  In your case, you can have a line in ~/.Renviron
>> > with:
>> >
>> >   R_USER_LIBS=~/R/%p-library/%v-bioc_3.12
>> >
>> > Alternatively, you can set it elsewhere, e.g. ~/.bashrc, in a Linux
>> > environment module that is loaded, and so on.
>> >
>> > BTW, using Rscript --no-init-file ... would skip .Rprofile while still
>> > parsing .Renviron.
>> >
>> > /Henrik
>> >
>> > On Wed, Apr 7, 2021 at 8:16 AM Mike Smith  wrote:
>> > >
>> > > I have the following line in the configure.ac for rhdf5filters, which
>> > > returns the location of the HDF5 headers distributed with Rhdf5lib:
>> > >
>> > > RHDF5_INCLUDE=`"${R_HOME}/bin${R_ARCH_BIN}/Rscript" -e
>> > > 'cat(system.file("include", package="Rhdf5lib"))'`
>> > >
>> > > For me the output is a path like
>> > >  /mnt/data/R-lib/4.0.3-bioc_3.12/Rhdf5lib/include, which gets
>> inserted into
>> > > the package Makevars file, and the package compilation works.
>> > >
>> > > However I've had multiple reports (
>> > > https://github.com/grimbough/rhdf5filters/issues/11) where this
>> doesn't
>> > > work, all of which seem to relate to messages printed when an
>> Rprofile is
>> > > loaded.  They have well intentioned messages like below, which don't
>> work
>> > > so well when passed as compiler flags
>> > >
>> > > [1] "[BMRC] You have sourced the BMRC Rprofile provided at
>> > > /apps/misc/R/bmrc-r-user-tools/Rprofile"
>> > > [1] "[BMRC] Messages coming from this file (like this one) will be
>> > > prefixed with [BMRC]"
>> > > [1] "[BMRC] You are running R on host 
>> > > with CPU "
>> > > [1] "[BMRC] While running on this host, local R packages will be
>> > > sourced from and installed to
>> > > /well/combat/users/ifl143/R/4.0/ivybridge"
>> > > /gpfs3/well/combat/users/ifl143/R/4.0/ivybridge/Rhdf5lib/include
>> > >
>> > > I thought about using --vanilla but I use .Rprofile to set my library
>> path,
>> > > so ignoring that file completely defeats the point in my setup.  Is
>> anyone
>> > > aware of either a more reliable way of getting the information I want
>> > > (maybe suppressing messages, different mechanism entirely, etc)?
>> > > Alternatively, is there anything definitive in WRE or the like that
>> > > suggests printing messages Rprofile is a bad idea that I can pass on
>> to the
>> > > users?
>> > >
>> > > Cheers,
>> > > Mike
>> > >
>> > > [[alternative HTML version deleted]]
>> > >
>> > > ___
>> > > Bioc-devel@r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>> ___
>> 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

[Bioc-devel] Suppressing messages from Rprofile

[Mike Smith]

I have the following line in the configure.ac for rhdf5filters, which
returns the location of the HDF5 headers distributed with Rhdf5lib:

RHDF5_INCLUDE=`"${R_HOME}/bin${R_ARCH_BIN}/Rscript" -e
'cat(system.file("include", package="Rhdf5lib"))'`

For me the output is a path like
 /mnt/data/R-lib/4.0.3-bioc_3.12/Rhdf5lib/include, which gets inserted into
the package Makevars file, and the package compilation works.

However I've had multiple reports (
https://github.com/grimbough/rhdf5filters/issues/11) where this doesn't
work, all of which seem to relate to messages printed when an Rprofile is
loaded.  They have well intentioned messages like below, which don't work
so well when passed as compiler flags

[1] "[BMRC] You have sourced the BMRC Rprofile provided at
/apps/misc/R/bmrc-r-user-tools/Rprofile"
[1] "[BMRC] Messages coming from this file (like this one) will be
prefixed with [BMRC]"
[1] "[BMRC] You are running R on host 
with CPU "
[1] "[BMRC] While running on this host, local R packages will be
sourced from and installed to
/well/combat/users/ifl143/R/4.0/ivybridge"
/gpfs3/well/combat/users/ifl143/R/4.0/ivybridge/Rhdf5lib/include

I thought about using --vanilla but I use .Rprofile to set my library path,
so ignoring that file completely defeats the point in my setup.  Is anyone
aware of either a more reliable way of getting the information I want
(maybe suppressing messages, different mechanism entirely, etc)?
Alternatively, is there anything definitive in WRE or the like that
suggests printing messages Rprofile is a bad idea that I can pass on to the
users?

Cheers,
Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Methods to speed up R CMD Check

[Mike Smith]

Hi Alan,

I wonder if there are instances in your tests where you can use pseudo data
or mock the behaviour of certain functions.  For me the aim of unit testing
is to confirm the behaviour of functions under controlled conditions, but
it doesn't necessarily have to be done using 'real' data.

For example, in test_fix_bad_mgi_symbols.R you download a 40mb text file
with 300,000 lines - this takes ~20 seconds for me.  Do you really need
such a large file to test the functionality?  Perhaps you could create a
data.frame of only a few rows, where each row encapsulates something you
want to test for.  Then write this to a temporary file and use that to test
the functions.

I'll also note that for me each call to fix.bad.mgi.symbols() calls
ExperimentHub() via ewceData::all_mgi() which adds quite a bit to the
runtime of that test file.  However it sounds like maybe you're already
addressing that.  If not, I think this is something you could mock in your
tests.  You could mock the output of ewceData::all_mgi() to either be
output of eh[["EH5369"]] (so you'd only query the hub once), or mock it
manually to be a small subset of gene names that trigger the behaviour
you're testing for.

I don't think I've done a good job explaining that, so I'll point you to
the mockery package (https://github.com/r-lib/mockery) and some examples
where I've used mocking in the biomaRt package to fake results without
having to query a web server (
https://github.com/grimbough/biomaRt/blob/master/tests/testthat/test_ensembl_ssl_settings.R
)

Finally I'll point out there's a testthat::skip_on_bioc() function that
will allow you to skip a test on the Bioc builder, but still run that test
locally/on GitHub etc.  However, I think we'd all agree it'd be better to
get all the tests running universally, rather than take that route.

Mike

On Tue, 23 Mar 2021 at 12:11, Murphy, Alan E 
wrote:

> Hi,
>
> Thank you very much Martin and Hervé for your suggestions. I have reverted
> my zzz.R on load function to that advised by ExperimentHub and had used the
> ID look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions
> and unit tests. However, the check is still taking ~18 minutes so I need to
> do a bit more work. Even with my new on load function, calling datasets by
> name still takes substantially longer, see below for the example Hervé gave
> on my new code:
>
> a<-function(){
>   eh <- query(ExperimentHub(), "ewceData")
>   tt_alzh <- eh[["EH5373"]]
> }
> microbenchmark::microbenchmark(a,
>tt_alzh <- ewceData::tt_alzh(),
>times=20L,unit="s")
> >Unit: seconds
> >expr min  lq
>  mean  median  uq max neval
> >a  0.0003 0.00031
> 0.002995 0.00045 0.00684 0.0106420
> t>t_alzh <- ewceData::tt_alzh() 2.71135788 2.755388420 2.9922968274
> 2.993737666 3.144241330 3.84242267920
>
> My question is would it be acceptable to change my data load calls in my
> examples and the vignette to reduce the runtime or is this against best
> practice and should I look for improvements elsewhere? I ask because I feel
> I'm running out of easy options at reducing the overall runtime.
>
> Kind regards,
> Alan.
>
>
> 
> From: Martin Morgan 
> Sent: 22 March 2021 18:17
> To: Kern, Lori ; Murphy, Alan E <
> a.mur...@imperial.ac.uk>; bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] Methods to speed up R CMD Check
>
> (sticking bioc-devel back in the recipient list so others can learn /
> improve / disagree with this suggestion.)
>
> my suggestion was to memorize the function in your package, not in the
> example. Examples are not run independently, but collated into a single
> file (EWCR-Ex.R in the EWCR.Rcheck directory, after running R CMD check)
> and sourced. And the suggestion was not to solve the problem of examples
> running slowly, but avoiding repeatedly calculating the same value. For
> instance, from Hervé’s email ewceData::tt_alzh could be memorized in the
> package. The first call would take several seconds, but subsequent calls
> would be instantaneous. But as Hervé says that function should be cleaned
> up anyway so that 'tricks' like memorization might not be necessary.
>
>
> From: "Murphy, Alan E" 
> Date: Monday, March 22, 2021 at 12:37 PM
> To: Martin Morgan 
> Subject: Re: [Bioc-devel] Methods to speed up R CMD Check
>
> Hey Martin,
>
> Thanks for the suggestion but how would I go about using this, let's say,
> for the examples? If I redefine the memoise function in each example (as it
> won't otherwise exist) would this not take the same amount of time?
>
> Kind regards,
> Alan.
>
> From: Martin Morgan 
> Sent: 22 March 2021 13:34
> To: Kern, Lori ; Murphy, Alan E <
> a.mur...@imperial.ac.uk>; bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re: 

Re: [Bioc-devel] EXTERNAL: Resolve mismatch between master and release branches

[Mike Smith]

Hi Sarah,

Just to reiterate Marcel's point, if these are new features or tweaks to
your package, then they shouldn't be committed to the release branch at
all.  The Bioconductor ethos is that the release version of a package
should remain stable for a 6 month window (the release cycle), and changes
to that release version should only be made for critical bugs, patches to
fix errors introduced by an update to a CRAN package you depend on, etc.
This is to try and ensure that all Bioconductor packages within a release
present a stable interface; both for users and for packages that
interoperate.  There's an expectation that things in the release branch
will "just work" and will produce consistent results during a release
cycle.  On the other hand, in the devel branch you can make more dramatic
changes, add new features, update options or defaults arguments etc.  It's
still nice to inform users if the result of a function might change between
versions, but it's fine to introduce a change like that.

Assuming your changes are bug fixes, it's also perfectly reasonable to have
a divergence like "7 commits behind master and 3 commits ahead" between the
master and release branches.  The two branches should have
different package version numbers, and that's going to require a different
commit to each branch.  As soon as you've done that you'll see a message
like this, because there's now a commit in master that doesn't appear in
release, and likewise one that's in release that doesn't appear in master.
This doesn't mean anything has gone wrong, the Bioconductor versioning
guidelines have been followed, GitHub just likes to let you know the two
branches have both diverged from their common ancestor.

Best,
Mike

On Mon, 22 Mar 2021 at 23:59, Marcel Ramos <
marcel.ramospe...@roswellpark.org> wrote:

> Hi Sarah,
>
> The release branch is meant for bug fixes that ensure the stability of
> the code.
> It does not usually include 'updates' from the devel.
>
> The way to cleanly do this is to hard reset to a previous commit. The
> commit
> where your packages version was bumped for the 3.12 release. You
> can then force push the release branch to your GitHub repository
> RELEASE_3_12 branch.
> https://bioconductor.org/developers/how-to/git/abandon-changes/
> 
>
> After emailing Nitesh and he would apply a force push to the Bioc git
> repo.
>
> You will then be able to apply your changes from the devel branch by
> cherry-picking those changes** onto the release branch.
>
> ** your changes in the devel branch should be atomic, meaning they do not
> include version bumps, so that cherry-picking is easier, if that is not
> the case
> you may have to apply a diff or manually update the version.
>
>
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> <
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> >
>
> Hope that helps.
>
> Best,
>
> Marcel
>
>
>
> On 3/22/21 4:43 PM, Sarah Voisin wrote:
> > Hi,
> >
> > I have updated the master branch of my MEAT package yesterday (
> > https://github.com/sarah-voisin/MEAT), and I tried updating the release
> > branch as well (RELEASE_3_12), but I must have messed up since the
> release
> > branch is now 7 commits behind master and 3 commits ahead, and I am
> stuck.
> > How do I do this again cleanly so I can push all changes from the master
> > branch to the release branch without messing up further?
> >
> > Thank you for your help.
> >
> > Kind regards,
> >
> > *Sarah Voisin*
> > *Senior Lecturer*
> > Institute for Health and Sport (IHES)
> > Victoria University, Footscray Park Campus, VIC 3011 Australia
> > *Email*: sarah.voisin.ae...@gmail.com
> > *Office phone*: +61 3 9919 5744
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ---
> Marcel Ramos
> Bioconductor Core Team
> Roswell Park Comprehensive Cancer Center
> Dept. of Biostatistics & Bioinformatics
> Elm St. & Carlton St.
> Buffalo, New York 14263
>
>
>
> This email message may contain legally privileged and/or...{{dropped:4}}
>
> ___
> 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

[Bioc-devel] Bioconductor Developers Forum - 18th March

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is this Thursday 18th March at
09:00 PST / 12:00 EST / 17:00 CET - You can find a calendar invite
attached and at https://tinyurl.com/BiocDevel-2021-03

PLEASE NOTE: this is an hour earlier for those of us not yet in daylight
savings time!

   - This month we're discussing object orientated programming in R -
   specifically the efforts of the RConsortium Object Orientated Working Group
   and how Bioconductor could be ported to the new OO system they're
   proposing.
   - We'll be led by Michael Lawrence, plus others from the working group.
   This should be a really interesting insight into the current progress
   they're making, and give the Bioconductor community a chance to shape the
   direction of a cornerstone R's future.
   - As a primer there's a really great short summary of the S3 and S4
   systems at
   https://github.com/RConsortium/OOP-WG/blob/master/proposal/proposal.org
   which I thoroughly enjoyed reading.

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Please let me know if you have future topics you'd like to discuss in the
Developers' Forum.

Best wishes,

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

Re: [Bioc-devel] Removal of large items in git history - BiocCheck warning

[Mike Smith]

I've used something like this approach in the past.  All the normal caveats
about making sure you've got a backup apply.

Find the names of largest objects in the pack file (not necessarily in size
order).  In this case they're almost all .rda files.

git rev-list --objects --all | grep -f <(git verify-pack -v
.git/objects/pack/*.idx| sort -k 3 -n | cut -f 1 -d " " | tail -15)

e63fb55738f4d6643939863ec7799776d4b161c5 EWCE.html
f67b528ec5e029fbeb45c2ff90d619de0d7ae4c0 articles/EWCE.html
b871cbacac1c1fe1b372a8eca9f7c68122fc4bf4
articles/EWCE_files/figure-html/unnamed-chunk-21-1.png
ae0e4cda88322aaff0b064136c84096d16dc219f reference/ewce.plot-1.png
8946eeb7255c328676a61da71276a29002e34d1f data/all_hgnc.rda
60814dfe9cbf3cb77b846a9fc0270bc7cc00d50c data/all_hgnc_wtEnsembl.rda
d152a56e7290abb06eab1112910a499145dbd3e1 data/all_mgi.rda
7075962fb2ccc78b826c7fc1823d0e3d5e5d7b01 data/all_mgi_wtEnsembl.rda
5d7d0a395c104ad39f105ad85c7a84663e0e6002
data/ensembl_transcript_lengths_GCcontent.rda
100a7fa8df12deb1803a437b442c0897811916df data/mgi_synonym_data.rda
f890d2bbd63b7ecff94e4917b6b7188399659221 data/mouse_to_human_homologs.rda
fd7022bc96d24d75cf71d65c097d84bade88 data/tt_alzh.rda
98aba69ade5c09a2100248c963bb5397860ae089 data/tt_alzh_BA36.rda
0f006997c7a45a5647dd5ce21be650d6c197ea29 data/tt_alzh_BA44.rda
67b2d63f55531f85ece47e298213fd25cacdaa01 data/cortex_mrna.rda

Filter files with the .rda extension.  I guess you should be more careful
here if there are rda files you want to retain, but I don't see any in the
main branch on Github.  I get a pretty scary looking warning from git, but
it seems to have worked out ok for me in the past.

git filter-branch --index-filter 'git rm --cached --ignore-unmatch *.rda'
-- --all

Apply the removal to the repo.

rm -Rf .git/refs/original
rm -Rf .git/logs/
git gc --aggressive --prune=now

Check the new size of the pack folder.

du -h .git/objects/pack
3,9M .git/objects/pack

You could probably apply this approach to remove the large .html files too,
but it looks like they're part of the pkgdown site for your package so I
imagine you want to keep them.

Mike



On Tue, 9 Mar 2021 at 10:09, Murphy, Alan E  wrote:

> Hi both,
>
> Thank you for your suggestions. Yes, I am still having problems with the
> size of my git history in the EWCE package. To clarify, I have already
> tried the BFG cleaner to no avail even when I set the max limit to 1 MB
> (see my first email for details).
>
> The issue is that a .git/objects/pack/ file is still greater than the
> allotted 5MB, it appears to be 8.9MB in size. As mentioned, I have used the
> BFG cleaner and yet this still remains too large. If anyone has suggestions
> on how else I could reduce this size that would be great.
>
> @Nitesh Turaga how would I go about
> checking (and removing?) hidden files from the .git/objects/pack history?
>
> Kind regards,
> Alan.
> 
> From: stefano 
> Sent: 08 March 2021 22:18
> To: Nitesh Turaga 
> Cc: Murphy, Alan E ; bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] Removal of large items in git history -
> BiocCheck warning
>
>
> This email from mangiolastef...@gmail.com originates from outside
> Imperial. Do not click on links and attachments unless you recognise the
> sender. If you trust the sender, add them to your safe senders list<
> https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping
> for this address.
>
>
>
> Hello,
>
> you can use  bfg-repo-cleaner  ,
>
> have a read to this document, in the section "eliminate big files from
> repo"
>
>
> https://docs.google.com/document/d/1jxg7KCMQq3kiCcvodQk9JgtU51LqczOwLit1gHiTP4Q/edit?usp=sharing
>
>
> Best wishes.
>
> Stefano
>
>
>
> Stefano Mangiola | Postdoctoral fellow
>
> Papenfuss Laboratory
>
> The Walter Eliza Hall Institute of Medical Research
>
> +61 (0)466452544
>
>
> Il giorno mar 9 mar 2021 alle ore 09:11 Nitesh Turaga <
> nturaga.b...@gmail.com> ha scritto:
> Hi Alan,
>
> Did you manage to solve this?
>
> There seems to be objects in your git repo which are bigger than the size
> which is required by Bioconductor for a software package. Please check
> hidden files as well.
>
> One test you can do is, to clone your package from github and see how much
> MB are downloaded to this new location. This is a good test to check which
> files are still larger than the limit.
>
> Best,
>
> Nitesh
>
> On 3/4/21, 11:19 AM, "Bioc-devel on behalf of Murphy, Alan E" <
> bioc-devel-boun...@r-project.org
> on behalf of a.mur...@imperial.ac.uk>
> wrote:
>
> Hi all,
>
> I am working on the development of EWCE<
> https://github.com/NathanSkene/EWCE> for submission to Bioconductor. I
> have removed some large objects from the package and moved them to a
> separate ExperimentHub package however, after their removal, I got a
> 

[Bioc-devel] Bioconductor Developers Forum - 25th February

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is this Thursday 25th February at
09:00 PST / 12:00 EST / 18:00 CET - You can find a calendar invite
attached and at https://tinyurl.com/BiocDevel-2021-02


   - This month we're going to focus on Unit Testing!  We'll introduce what
   unit tests are and why they might be useful for your R package
   development.
   - We'll also introduce some of the common R packages that help us write
   and run unit tests.  To that end Dirk Eddelbuettel will give an overview of
   'tinytest' and how he makes use of it in his work.
   - If you're a fan (or indeed not!) of testthat, RUnit, or any other
   testing strategies and would be willing to give a 10 minute overview please
   let me know ASAP!

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Please let me know if you have future topics you'd like to discuss in the
Developers' Forum.

Best wishes,

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

[Bioc-devel] Bioconductor Developers Forum - 21st January

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is this Thursday 21st January at
09:00 PST / 12:00 EST / 18:00 CET - You can find a calendar invite
attached and at *https://tinyurl.com/BiocDevel-2021-01
*


   - This month we will hear from Jass Bagga and Erdal Cosgun from
   Microsoft Genomics.  They will introduce the work they've been doing in
   collaboration with the Bioconductor core team to provide access to
   Bioconductor and other genomics tools in the Azure cloud.  If you're
   interested in discussing scalable platforms for running analysis workflows,
   interactive notebook environments, or accessing large-scale public datasets
   this should be a great event.

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Please let me know if you have future topics you'd like to discuss in the
Developers' Forum.

Best wishes,

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

Re: [Bioc-devel] Bioconductor package CNVRanger

[Mike Smith]

Hi Ludwig,

I think this actually a result of changes in rtracklayer that aren't
playing well with Gviz::IdeogramTrack().  It looks like the error message
is a bit misleading, it's not really a connection issue, just that
something unexpected happens because some of the
rtracklayer::ucscTableQuery() arguments are no longer in the same order.

I've submitted a pull request to Gviz at
https://github.com/ivanek/Gviz/pull/40 which allows Gviz to pass
build/check.  Hopefully that'll straighten things out for you if it gets
accepted.

Cheers,
Mike

On Fri, 1 Jan 2021 at 23:38, Geistlinger, Ludwig <
ludwig_geistlin...@hms.harvard.edu> wrote:

> I am not 100% sure what the problem is but it seems as if there is a
> problem with receiving resources from UCSC, a problem that also other
> packages encounter, eg
>
> Gviz (http://bioconductor.org/checkResults/devel/bioc-LATEST/Gviz/)
> ensembldb (
> http://bioconductor.org/checkResults/devel/bioc-LATEST/ensembldb<
> http://bioconductor.org/checkResults/devel/bioc-LATEST/ensembldb/malbec2-buildsrc.html
> >)
>
> or more generally an internet connection problem on the devel builders as
> CNVRanger builds fine for me locally using
> a recent version of R-devel. Also, the exact same code builds fine in the
> release branch:
>
> http://bioconductor.org/checkResults/release/bioc-LATEST/CNVRanger/
>
> sessionInfo for my local setup:
>
> > sessionInfo()
> R Under development (unstable) (2020-12-23 r79675)
> Platform: x86_64-apple-darwin18.6.0 (64-bit)
> Running under: macOS Mojave 10.14.5
>
> Matrix products: default
> BLAS:   /Users/ludwig/Downloads/R-devel/lib/libRblas.dylib
> LAPACK: /Users/ludwig/Downloads/R-devel/lib/libRlapack.dylib
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] parallel  stats4stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
> [1] CNVRanger_1.7.2 RaggedExperiment_1.15.1 GenomicRanges_1.43.1
> [4] GenomeInfoDb_1.27.3 IRanges_2.25.6  S4Vectors_0.29.6
> [7] BiocGenerics_0.37.0
>
> loaded via a namespace (and not attached):
>  [1] lattice_0.20-41 matrixStats_0.57.0
>  [3] bitops_1.0-6grid_4.1.0
>  [5] zlibbioc_1.37.0 XVector_0.31.1
>  [7] Matrix_1.2-18   tools_4.1.0
>  [9] Biobase_2.51.0  RCurl_1.98-1.2
> [11] DelayedArray_0.17.6 MatrixGenerics_1.3.0
> [13] compiler_4.1.0  SummarizedExperiment_1.21.1
> [15] GenomeInfoDbData_1.2.4
>
>
>
> 
> From: Kern, Lori 
> Sent: Wednesday, December 23, 2020 7:23 AM
> To: Geistlinger, Ludwig 
> Subject: Bioconductor package CNVRanger
>
> Hello Package Maintainer,
>
> The Bioconductor Team would like to notify you that your package is
> currently
> failing on the devel 3.13 version of Bioconductor, and has been for an
> extended
> period of time.  Please fix your package to R CMD build and R CMD check
> cleanly
> immediately to avoid deprecation of your package. While devel is a place to
> experiment with new features, we expect packages to build and check
> cleanly in a
> reasonable time period and not stay broken for any extended period of
> time. If
> you are having trouble or have any further questions please do not
> hesitate to
> reach out to the developers mailing list at bioc-devel@r-project.org. The
> package has been failing consistently since 12/07/20
>
> bioconductor.org/checkResults/devel/bioc-LATEST/CNVRanger
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>
> [[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] Warnings about man pages for assignment operators on Windows builds

[Mike Smith]

Hi Vince and Stephanie,

There was some discussion in the Bioconductor slack about these warnings,
and they definitely seem to be related to a change in R-devel, which tries
to create files with names that are invalid on the Windows filesystem.

However, the reason you may not see them on your local machine is due to
the way the Bioconductor build system runs the package checks, which are a
little more convoluted than you probably run locally.  Using my typical
approach I see the warning messages printed in the output of R CMD INSTALL,
but it doesn't trigger anything in R CMD check.

I suspect that the build system warnings will persist for a while longer as
the issue is still there, but I don't think there's anything you can do as
a package developer, so there's no need to worry about it for now.
Hopefully a fix will make it's way into R-devel fairly soon.

Mike

On Wed, 30 Dec 2020 at 12:04, Vincent Carey 
wrote:

> Hi Stephanie
>
> I see similar problems for GenomicFiles, so it is not a problem unique to
> your package.
> I was not able to generate this error with r79717 in Windows 10, so I
> conjecture that this
> will go away when the R-devel for windows is upgraded.
>
> Best regards
> Vince
>
> On Tue, Dec 29, 2020 at 1:58 PM Stephanie Gogarten 
> wrote:
>
> > Hi all,
> >
> > Several of my packages have a set of warnings on the Windows devel builds
> > that have persisted for a while now, all of this form:
> >
> > Rd warning: cannot open file
> >
> >
> 'C:/Users/biocbuild/bbs-3.13-bioc/meat/SeqVarTools.buildbin-libdir/00LOCK-SeqVarTools/00new/SeqVarTools/help/lastFilter<-.html':
> > Invalid argument
> >
> > I have the following in my .Rd file:
> >
> > \alias{lastFilter<-}
> > \alias{lastFilter<-,SeqVarIterator,numeric-method}
> >
> > Is there a different way I should be documenting assignment operators in
> > R-devel?
> >
> > thanks,
> > Stephanie
> >
> > [[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 th...{{dropped:10}}

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

[Bioc-devel] Problem with download count tables

[Mike Smith]

Hi,

It looks like there's an issue with the download count tables for the
annotation packages.  I get either "permission denied" or "not found"
errors if I try to follow any of the links from
https://bioconductor.org/packages/stats/data-annotation.html This is also
breaking the BiocPkgTools::biocDownloadStats() function.

The issue also seems to be affecting the count tables for the experiment
data and workflow packages.  Software seems ok.

Cheers,
Mike

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor Developers Forum - 10th December

[Mike Smith]

Dear all,

The next Developers Forum will take place next Thursday 10th Dec at 09:00
PST / 12:00 EST / 18:00 CET - You can find a calendar invite at
*https://tinyurl.com/BiocDevel-2020-12-10
*

Please note this is one week earlier than originally scheduled to avoid
clashing with EuroBioc2020.  The event calendar has now been updated.


   -  This call will be a direct follow on from our introduction to ALTREP
   last month.  Jiefei Wang will show us some of the difficulties with working
   with ALTREP in practice, and introduce the Travel package (
   https://github.com/Jiefei-Wang/Travel) he's been developing to ease some
   of these limitation when writing C++ code.


Please let me know if you have any other topics you'd like to discuss.

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Missing knitcitations package on devel for PharmacoGx

[Mike Smith]

Hi Christopher,

It looks like the knitcitations package is no longer on CRAN.  Heading to
https://cran.r-project.org/web/packages/knitcitations/index.html results in:

  Package ‘knitcitations’ was removed from the CRAN repository.

  Formerly available versions can be obtained from the archive.

  Archived on 2020-10-27 as reauired archived package 'RefManageR'.

My guess is the release branch has a copy of knitcitations installed from
before it was removed from CRAN, so you don't see the error, but a fresh R
installation using either release or devel would throw the same problem.

The latest commit message to https://github.com/cboettig/knitcitations is
'prep for release', so it looks likely that the author of knitcitations is
addressing the CRAN issue.  I would hang tight for a while longer and hope
it gets smoothed out there.

Mike

On Thu, 26 Nov 2020 at 04:26, Eeles, Christopher <
christopher.ee...@uhnresearch.ca> wrote:

> Hello Bioc community,
>
> I am the maintainer for PharmacoGx and have noticed that I have an error
> on all platforms of the devel branch related to the knitcitations package.
>
>
> * checking for file ‘PharmacoGx/DESCRIPTION’ ... OK
> * preparing ‘PharmacoGx’:
> * checking DESCRIPTION meta-information ... OK
> * installing the package to build vignettes
> * creating vignettes ... ERROR
> --- re-building ‘CreatingPharmacoSet.Rmd’ using rmarkdown
> Quitting from lines 79-82 (CreatingPharmacoSet.Rmd)
> Error: processing vignette 'CreatingPharmacoSet.Rmd' failed with
> diagnostics:
> there is no package called 'knitcitations'
> --- failed re-building ‘CreatingPharmacoSet.Rmd’
>
> --- re-building ‘PharmacoGx.Rmd’ using rmarkdown
> Quitting from lines 79-82 (PharmacoGx.Rmd)
> Error: processing vignette 'PharmacoGx.Rmd' failed with diagnostics:
> there is no package called 'knitcitations'
> --- failed re-building ‘PharmacoGx.Rmd’
>
> SUMMARY: processing the following files failed:
>   ‘CreatingPharmacoSet.Rmd’ ‘PharmacoGx.Rmd’
>
> Error: Vignette re-building failed.
> Execution halted
>
> The package builds fine on the release branch with the same vignettes and
> knitcitations in the suggests field of the description.
>
> Any advice on how I can fix this? It seems like my suggests aren't being
> installed on the devel branch.
>
> Thanks for your assistance.
>
> Best,
> Christopher Eeles
> Software Developer
> Benjamin Haibe-Kains Lab
> Princess Margaret Cancer Centre
>
> This e-mail may contain confidential and/or privileged i...{{dropped:22}}
>
> ___
> 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] Issues with images in vignette

[Mike Smith]

Thanks for the information Sudeep.

I'm not sure there should be any changes in BiocStyle between 2.18.0 and
2.19.0 (other than the version number!) but there's clearly something weird
going on.  I'll take a look tomorrow and report back in
https://github.com/Bioconductor/BiocStyle/issues/83

Cheers,
Mike

On Thu, 19 Nov 2020 at 15:14, Sudeep Sahadevan 
wrote:

> Thank you...
> Perhaps I can add some additional info here. I was comparing the
> sessionInfo from my local build based on RELEASE 3_12 docker image (where
> the images are rendered fine) against the sessionInfo from the release
> vignette. This is what I found:
> Packages/Package versions unique to sessionInfo from bioconductor
> release:  R6_2.4.1,  dbplyr_1.4.4,  generics_0.0.2,  png_0.1-7,
> xfun_0.18
> Packages/Package versions unique to sessionInfo from local build based on
> RELEASE_3_12 docker image:R6_2.5.0, dbplyr_2.0.0, generics_0.1.0,
> xfun_0.19
> I've pasted both sessionInfos below.
> Kind regards,Sudeep.
> ### sessionInfo from bioconductor release vignette
> ## R Under development (unstable) (2020-10-17 r79346)## Platform:
> x86_64-pc-linux-gnu (64-bit)
> ## Running under: Ubuntu 20.04.1 LTS
> ##
> ## Matrix products: default
> ## BLAS:   /home/biocbuild/bbs-3.13-bioc/R/lib/libRblas.so
> ## LAPACK: /home/biocbuild/bbs-3.13-bioc/R/lib/libRlapack.so
> ##
> ## locale:
> ##  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> ##  [3] LC_TIME=en_US.UTF-8LC_COLLATE=C
> ##  [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
> ##
> ## attached base packages:
> ## [1] parallel  stats4stats graphics  grDevices utils
>  datasets
> ## [8] methods   base
> ##
> ## other attached packages:
> ##  [1] data.table_1.13.2   forcats_0.5.0
> ##  [3] stringr_1.4.0   dplyr_1.0.2
> ##  [5] purrr_0.3.4 readr_1.4.0
> ##  [7] tidyr_1.1.2 tibble_3.0.4
> ##  [9] ggplot2_3.3.2   tidyverse_1.3.0
> ## [11] IHW_1.19.0  DEWSeq_1.5.0
> ## [13] BiocParallel_1.25.0 DESeq2_1.31.0
> ## [15] SummarizedExperiment_1.21.0 Biobase_2.51.0
> ## [17] MatrixGenerics_1.3.0matrixStats_0.57.0
> ## [19] GenomicRanges_1.43.0GenomeInfoDb_1.27.0
> ## [21] IRanges_2.25.0  S4Vectors_0.29.0
> ## [23] BiocGenerics_0.37.0 R.utils_2.10.1
> ## [25] R.oo_1.24.0 R.methodsS3_1.8.1
> ## [27] BiocStyle_2.19.0
> ##
> ## loaded via a namespace (and not attached):
> ##  [1] fs_1.5.0   bitops_1.0-6   lubridate_1.7.9
>
> ##  [4] bit64_4.0.5RColorBrewer_1.1-2 httr_1.4.2
>
> ##  [7] tools_4.1.0backports_1.1.10   utf8_1.1.4
>
> ## [10] R6_2.4.1   DBI_1.1.0  colorspace_1.4-1
>
> ## [13] withr_2.3.0tidyselect_1.1.0   bit_4.0.4
>
> ## [16] compiler_4.1.0 fdrtool_1.2.15 cli_2.1.0
>
> ## [19] rvest_0.3.6xml2_1.3.2 DelayedArray_0.17.0
>
> ## [22] bookdown_0.21  slam_0.1-47scales_1.1.1
>
> ## [25] genefilter_1.73.0  digest_0.6.27  rmarkdown_2.5
>
> ## [28] XVector_0.31.0 pkgconfig_2.0.3htmltools_0.5.0
>
> ## [31] lpsymphony_1.19.0  dbplyr_1.4.4   highr_0.8
>
> ## [34] readxl_1.3.1   rlang_0.4.8rstudioapi_0.11
>
> ## [37] RSQLite_2.2.1  generics_0.0.2 jsonlite_1.7.1
>
> ## [40] RCurl_1.98-1.2 magrittr_1.5
>  GenomeInfoDbData_1.2.4
> ## [43] Matrix_1.2-18  fansi_0.4.1Rcpp_1.0.5
>
> ## [46] munsell_0.5.0  lifecycle_0.2.0stringi_1.5.3
>
> ## [49] yaml_2.2.1 zlibbioc_1.37.0grid_4.1.0
>
> ## [52] blob_1.2.1 crayon_1.3.4   lattice_0.20-41
>
> ## [55] haven_2.3.1splines_4.1.0  annotate_1.69.0
>
> ## [58] hms_0.5.3  magick_2.5.0   locfit_1.5-9.4
>
> ## [61] ps_1.4.0   knitr_1.30 pillar_1.4.6
>
> ## [64] geneplotter_1.69.0 reprex_0.3.0   XML_3.99-0.5
>
> ## [67] glue_1.4.2 evaluate_0.14  modelr_0.1.8
>
> ## [70] BiocManager_1.30.10png_0.1-7  vctrs_0.3.4
>
> ## [73] cellranger_1.1.0   gtable_0.3.0   assertthat_0.2.1
>
> ## [76] xfun_0.18  xtable_1.8-4   broom_0.7.2
>
> ## [79] survival_3.2-7 AnnotationDbi_1.53.0   memoise_1.1.0
>
> ## [82] ellipsis_0.3.1
>
> ### sessionInfo from local build based on RELEAE_3_12 docker image
> ## R version 4.0.3 (2020-10-10)
> ## Platform: x86_64-pc-linux-gnu (64-bit)
> ## Running under: Ubuntu 20.04 LTS
> ##
> ## Matrix products: default
> ## BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/
> libopenblasp-r0.3.8.so
> ##
> ## locale:
> ##  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> ##  [3] LC_TIME=en_US.UTF-8 

[Bioc-devel] Bioconductor Developers Forum - 19th November

[Mike Smith]

Dear all,

The next Developers Forum will take place this coming Thursday 19th Nov at
09:00 PST / 12:00 EST / 18:00 CET - You can find a calendar invite at
*https://tinyurl.com/BiocDevel-2020-09-19
*

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

This month Gabe Becker (https://twitter.com/groundwalkergmb) will introduce
the topic of Alternate Representations of R Objects or ALTREP.  First
introduced in R-3.5.0, ALTREP was the most requested Developers' Forum
topic in our recent Slack survey, and it's sure to be an interesting look
into some of the fundamentals of how R works.

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Unable to install "msdata" package in current BioC 3.13 docker

[Mike Smith]

Hi Jo,

There was some discussion of a similar issue on the support forum at
https://support.bioconductor.org/p/p132470/

The suggestion there was to try changing  R's download.file.method option
e.g. options(download.file.method = "curl")

Best,
Mike

On Thu, 5 Nov 2020 at 13:21, Rainer Johannes 
wrote:

> Dear all,
>
> I'm unable to install the "msdata" package for the current BioC 3.13
> release. I keep getting the following error:
>
> > BiocManager::install("msdata")
> Bioconductor version 3.13 (BiocManager 1.30.10), R Under development
> (unstable)
>   (2020-10-24 r79367)
> Installing package(s) 'msdata'
> trying URL '
> https://bioconductor.org/packages/3.13/data/experiment/src/contrib/msdata_0.31.0.tar.gz
> '
> Content type 'application/x-gzip' length 446179202 bytes (425.5 MB)
> 
> downloaded 274.7 MB
>
> Error in download.file(url, destfile, method, mode = "wb", ...) :
>   download from '
> https://bioconductor.org/packages/3.13/data/experiment/src/contrib/msdata_0.31.0.tar.gz'
> failed
> In addition: Warning messages:
> 1: In download.file(url, destfile, method, mode = "wb", ...) :
>   downloaded length 288082900 != reported length 446179202
> 2: In download.file(url, destfile, method, mode = "wb", ...) :
>   URL '
> https://bioconductor.org/packages/3.13/data/experiment/src/contrib/msdata_0.31.0.tar.gz':
> Timeout of 60 seconds was reached
> Warning in download.packages(pkgs, destdir = tmpd, available = available,
> :
>   download of package ‘msdata’ failed
> Installation path not writeable, unable to update packages: codetools
>
>
> I'm using the docker image (bioconductor/bioconducto_docker:devel),
> sessionInfo below - so this error should be reproducible
>
> thanks for any hints/suggestion how I could solve this
>
> jo
>
>
> sessionInfo:
>
> > sessionInfo()
> R Under development (unstable) (2020-10-24 r79367)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 20.04 LTS
>
> Matrix products: default
> BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/
> libopenblasp-r0.3.8.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=C
>  [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
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] BiocManager_1.30.10
>
> loaded via a namespace (and not attached):
> [1] compiler_4.1.0 tools_4.1.0
>
>
> Johannes Rainer, PhD
> Eurac Research
>
> Institute for Biomedicine
> Via Galvani 31, I-39100 Bolzano, Italy
> M +39 327 4075490
> T +39 0471 055 491
> email: johannes.rai...@eurac.edu
> github: jorainer
> twitter: jo_rainer
>
> Legal Seat
> Viale Druso 1, I-39100 Bolzano, Italy
> www.eurac.edu
>
> This transmission is intended only for the use of the addressee and may
> contain confidential or legally privileged information.
> If you receive this transmission by error, please notify the author
> immediately by mail and delete all copies of this transmission and any
> attachments.
> Any use or dissemination of this commu­nication is strictly prohibited by
> the „Privacy-Code“, D.Lgs. 196/2003, and may lead to penal prosecution and
> liability for damages.
>
> ___
> 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

[Bioc-devel] Bioconductor Developers Forum - 22th October

[Mike Smith]

Dear all,

The next Developers Forum will take place this coming Thursday 22th Oct at
09:00 PDT / 12:00 EDT / 18:00 CEST - You can find a calendar invite at
https://tinyurl.com/y4y2xptb

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Constantin Ahlmann-Eltze is going to introduce us to the sparseMatrixStats
package for high-performance computation on sparse matrices.  Some of the
benchmarking in the package vignette looks very impressive, and I'm excited
to learn more about both sparse matrices in general and the performance
gains the package might help us realise.

Please let me know if you'd like anything else added to the agenda.

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R 4.0.3 for Windows R CMD check finds 'abort'

[Mike Smith]

Thanks for the self contained example Gordon.  Just to add to the
confusion, I'm unable to replicate this on my Windows machine.  Both the
toy example and running R CMD check on limma or Biobase fail to produce the
NOTE.

I've tried within RStudio, RGui and at the command line.

The only differences I can see in our systems are the locale and a 1 digit
change in the Windows build.

> sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)

Matrix products: default

locale:
[1] LC_COLLATE=English_United Kingdom.1252  LC_CTYPE=English_United
Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252 LC_NUMERIC=C

[5] LC_TIME=English_United Kingdom.1252

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

other attached packages:
[1] devtools_2.3.2 usethis_1.6.3

loaded via a namespace (and not attached):
 [1] rstudioapi_0.11   magrittr_1.5  rcmdcheck_1.3.3   pkgload_1.1.0
  R6_2.4.1
 [6] rlang_0.4.8   fansi_0.4.1   tools_4.0.3   pkgbuild_1.1.0
 xopen_1.0.0
[11] sessioninfo_1.1.1 cli_2.1.0 withr_2.3.0   ellipsis_0.3.1
 remotes_2.2.0
[16] assertthat_0.2.1  digest_0.6.25 rprojroot_1.3-2   crayon_1.3.4
 processx_3.4.4
[21] callr_3.5.1   fs_1.5.0  ps_1.4.0  testthat_2.3.2
 memoise_1.1.0
[26] glue_1.4.2compiler_4.0.3desc_1.2.0backports_1.1.10
 prettyunits_1.1.1

On Mon, 19 Oct 2020 at 23:03, Gordon K Smyth  wrote:

> Sorry, there was mistype in previous email. Here is the reproducible
> example again. This code produces the NOTE when run in a fresh R 4.0.3 for
> Windows session:
>
>   library(Rcpp)
>   Rcpp.package.skeleton("TestPack", example_code = TRUE)
>   library(devtools)
>   check("TestPack")
>
>
> > -Original Message-
> > From: Gordon K Smyth
> > Sent: Tuesday, 20 October 2020 7:58 AM
> > To: Martin Morgan ; bioc-devel@r-project.org
> > Subject: RE: [Bioc-devel] R 4.0.3 for Windows R CMD check finds 'abort'
> >
> > If you're interested, here is a small reproducible example. This example
> uses
> > Rcpp, but I think that any src code will give the same NOTE:
> >
> >   library(Rcpp)
> >   Rcpp.package.skeleton("TestPack", example_code = TRUE)
> >   library(devtools)
> >   install.package("devtools")
> >   check("TestPack")
> ___
>
> The information in this email is confidential and intended solely for the
> addressee.
> You must not disclose, forward, print or use it without the permission of
> the sender.
>
> The Walter and Eliza Hall Institute acknowledges the Wurundjeri people of
> the Kulin
> Nation as the traditional owners of the land where our campuses are
> located and
> the continuing connection to country and community.
> ___
> ___
> 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] Orchid ID invalid according to BiocCheck

[Mike Smith]

Well I learnt something new today!

"The final character, which may also be a letter "X" representing the value
"10" [..], is a MOD 11-2 check digit
 conforming to the ISO/IEC
7064:2003  standard." -
https://en.wikipedia.org/wiki/ORCID

I guess the check in BiocCheck isn't aware of this either.  I don't want to
speak for the author of that code, but I suspect you can ignore it for now
and it'll be fixed soon.


On Mon, 19 Oct 2020 at 12:33, Manders-2, F.M. <
f.m.mand...@prinsesmaximacentrum.nl> wrote:

> Yes, the X is correct (https://orcid.org/-0001-6197-347X). I don’t
> know why I have an X there and not a number.
>
> From: Vincent Carey 
> Date: Monday, 19 October 2020 at 12:20
> To: "Manders-2, F.M." 
> Cc: Alessandro Lussana via Bioc-devel 
> Subject: Re: [Bioc-devel] Orchid ID invalid according to BiocCheck
>
>  person("Freek", "Manders", email = "f.m.mand...@prinsesmaximacentrum.nl
> ", role = c("aut"),
> comment = c(ORCID = "-0001-6197-347X")),
>
> is what I see in a current checkout.  is "X" at the end correct?  maybe
> there is an encoding issue?
>
> On Mon, Oct 19, 2020 at 6:14 AM Manders-2, F.M. <
> f.m.mand...@prinsesmaximacentrum.nl f.m.mand...@prinsesmaximacentrum.nl>> wrote:
> Hi all,
>
> BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID
> ID for Freek Manders").
> However, I see nothing wrong with the ID. It also seems to work well on
> the dev page of my package (MutationalPatterns)
> Clicking on the green ID circle, sends me to my page just fine.
> Is there a mistake in BiocCheck? Should I just ignore this?
>
> With kind regards,
> Freek Manders
>
> [[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 th...{{dropped:22}}

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

Re: [Bioc-devel] Time-out error on Ubuntu 20.04 build

[Mike Smith]

I think this information will probably just confuse the issue, but I've
successfully checked out ncRNAtools and run R CMD build / check without
issue on my Ubuntu 20.04 test machine.  It took a couple of minutes.
Rolling back to an older version prior to the SSL patch would lead to
failure and the original error.

I'm afraid that doesn't offer much guidance, but perhaps this is something
more specific to the setup on nebbiolo1 ?

Mike

On Wed, 14 Oct 2020 at 07:52, Pages, Herve  wrote:

> On 10/13/20 15:18, Selles Vidal, Lara wrote:
> > Hi Hervé,
> >
> > Thanks a lot for your reply and clarification. It is reassuring to know
> > that Ubuntu 18.04 is still the primary Linux target!
> >
> > I am not running Ubuntu 20.04 on a Docker image, but I am running it on
> > a virtual machine (VirtualBox) on RedHat 7. Do you think this could be a
> > similar case as for the Docker image?
>
> Probably.
>
> > Interestingly, my other package on Bioconductor rfaRm had the same issue
> > related to SSL on Ubuntu 20.04.
>
> Yep, I know ;-)
>
> > I was able to solve it by using the same
> > workaround, and am now getting OK on R CMD install, build and check on
> > nebbiolo1 (http://bioconductor.org/checkResults/devel/bioc-LATEST/rfaRm/
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_rfaRm_=DwMGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=c1ETpOKFrZFp9E7pXw9m7rKkDFSAu3LXirxKvpof68A=7ruZcWM501J5RQVuoEFDPhJ7ZbP_7HLfezgTXJUPpKg=>
>
> > ).
>
> Glad it worked. Even though Ubuntu 20.04 is not our primary target, many
> users are probably going to use your package on Ubuntu 20.04 so it's
> worth trying to address this issue.
>
> >
> > This seems to indicate that the same workaround has different effects
> > depending on the URL being accessed possibly?
>
> Apparently. I didn't try Mike Smith's suggested workaround myself so I
> don't know for sure. Based on what you are reporting, we know that it
> works for some of the websites affected by the SSL certificate issue but
> not for all of them. Always good to know even though I have no idea why
> that would be.
>
> >
> > Interestingly, the workaround has at least led to a TIMEOUT in the case
> > of ncRNAtools, and not an ERROR, as was previously the case.  The
> > TIMEOUT seems to happen when creating the vignettes. Is it safe to
> > assume then than knitting the vignette under the same environment should
> > also get stuck at some endless/very long step? I will try to see if I
> > can get access to a native Ubuntu 20.04 environment, to try knitting the
> > vignette with different code chunks removed. Maybe we can figure out
> > some additional extra setting to pass to config() for the specific URL
> > that is leading to the TIMEOUT, that will provide a temporary workaround.
>
> Thanks for investigating. FWIW, here is what I get on nebbiolo1 (our
> Ubuntu 20.04 builder):
>
>$ cd ncRNAtools/vignettes
>
>$ R CMD Stangle ncRNAtools.Rmd
>Output file:  ncRNAtools.R
>
>$ R
>
>R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
>Copyright (C) 2020 The R Foundation for Statistical Computing
>Platform: x86_64-pc-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.
>
>> source("ncRNAtools.R", echo=TRUE)
>
>> ## setup,
> echo=FALSE
>> knitr::opts_chunk$set(message=FALSE, fig.path='figures/')
>
>> ## tidy = TRUE, eval =
> FALSE
>> ## if (!requireNamespace("BiocManager", quietly = TRUE))
>> ##  [TRUNCATED]
>
>> library(GenomicRanges)
>
>...
>
>> ## tidy =
> TRUE--
>> tRNAfragment <- "UGCGAGAGGCACAGGGUUCGAUUCCCUGCAUCUCCA"
>
>> centroidFoldPrediction <- predictSecondaryStructure(tRNAfragment,
> "centroidFold")
>Secondary structure prediction is running, please wait.
>Secondary structure prediction is running, please wait.
>Secondary structure prediction is running, please wait.
>Secondary structure prediction is running, please wait.
>Secondary structure prediction is running, please wait.
>Secondary structure prediction is running, please wait.
>...
>etc.. (seems like the while loop in predictSecondaryStructure
>never ends)
>
> Doesn't look like this has anything to do 

Re: [Bioc-devel] SSL error on Ubuntu 20.04

[Mike Smith]

Hi Lara,

I've encountered this issue with biomaRt too.

I found I could get the connection to work with the following:

library(httr)
url <- "https://www.ensembl.org/;
httr_config <-  config(ssl_cipher_list = "DEFAULT@SECLEVEL=1")
res <- with_config(config = httr_config, GET(url))

I haven't quite decided the best way to integrate that into my package, for
now it uses the httr_config if it's running on any Linux, which seems quite
heavy handed. It may be that specifying a particular cipher or determining
the host capabilities would be preferable to "DEFAULT", but does seem to
work for now on Ubuntu 20.04 and hasn't thrown any problems for my tests on
16.04 and 18.04.

Best,
Mike

On Wed, 30 Sep 2020 at 21:02, Selles Vidal, Lara <
lara.selle...@imperial.ac.uk> wrote:

> Dear BioC community,
>
> We were recently informed that a multilayered bug due to an increased
> security level in Ubuntu 20.04, configuration issues on server side and a
> bug in OpenSSL 1.1.1 caused our packages to fail on Ubuntu 20.04 with the
> following error:
>
>error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
> failure
>
> This affects the two packages I maintain, rfaRm and ncRNAtools. As a
> temporary fix, we were suggested to use HTTP instead of HTTPS. However,
> some of the web resources accessed with our packages do not seem to be
> accessible via HTTP. This is reflected in the latest build for rfaRm for
> example (http://bioconductor.org/checkResults/devel/bioc-LATEST/rfaRm/) ,
> which fails as a consequence of all the URLs being changed to the “http”
> version instead of “https”.
>
> The problem seems to have been discussed here
> https://github.com/Ensembl/ensembl-rest/issues/427 , with a temporary fix
> suggested here
> https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level
> . However, this seems to involve changing some openssl options through the
> openssl config file. We are unsure on whether this temporary fix could be
> implemented from within our package. We would greatly appreciate any
> guidance on how to implement it, or on any other alternative temporary
> workarounds.
>
> Thanks a lot in advance!
>
> Best wishes,
>
> Lara
>
> [[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] Help finding helpful diagnostic info in the build results report

[Mike Smith]

Hi Lillian,

For the most part skipping happens because there is a hierarchy to the
package testing.  If you can't BUILD a package, then you automatically
can't CHECK or build a binary version (BUILD BIN), so the build system will
simply skip trying those steps if it fails at the BUILD stage.  (The
exception in the BUILD BIN step on Linux, which is skipped because for the
most part it doesn't make sense to build binary versions Linux).

So you don't need to worry about the skipped steps for now, but then the
question is "why is your package failing to BUILD on the Windows
machine?".  My gut instinct is that it's down to the use of left- and
right-quotation marks (“/”) in your Title field, rather than just the
regular quotation mark (").

I don't know why it would be OK on Linux, but not Windows, but character
encoding is fiddly and different across operating systems. Also the
get_dcf_info error actually looks like it comes from the python code that
runs the build system - so it's pretty hard for you to debug directly, and
might behave differently from similarly named functions in R.  I'd try
changing out the quotes and then giving it another try.

Best,
Mike

On Fri, 25 Sep 2020 at 23:17, Thistlethwaite, Lillian Rosa <
lillian.thistlethwa...@bcm.edu> wrote:

> The newest build report for the checking of a package I submitted to
> Bioconductor skipped both the Mac and Windows builds. The Mac build was
> skipped because of a known issue with another R package dependency, gmp,
> and this can be ignored.
>
> However, the Windows build being skipped is a mystery to me. I did see the
> "get_dcf_info failed" message in the build tokay1 (Windows) Summary, but
> the read.dcf() function call from devtools and the system build works just
> fine on a Windows machine I tested the package on. There isn't much else
> diagnostic information as to why tokay1 is skipping the checks which I can
> use besides this. How are these undiagnostic SKIPS typically debugged?
>
> For reference, please view the most recent build results report here:
> http://bioconductor.org/spb_reports/CTD_buildreport_20200917232759.html
>
>
>
>
> Warmest wishes,
>
> Lillian Thistlethwaite
>
>
> Baylor College of Medicine
>
> Quantitative & Computational Biosciences Program
>
> Houston, TX
>
>
> [[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

[Bioc-devel] Bioconductor Developers Forum - 20th August

[Mike Smith]

Dear all,

Sorry for the short notice, the next Developers Forum will take place this
coming Thursday 20th August at 09:00 PDT / 12:00 EDT / 18:00 CEST - You can
find a calendar invite at https://bit.ly/3iUidMb

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Aaron Lun is going to discuss the steps required to wrangle compilation of
the OSCA book into the Bioconductor build system - it's much more than just
pressing 'knit' in RStudio!

I will present a prototype interface for browsing the Bioconductor git
repository and rapid searching of the entire codebase across all packages.

Please let me know if you'd like anything else added to the agenda.

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BiocCheck space indentation in Rmakrdown vignette documents

[Mike Smith]

Hi Carlos,

I don't think you need to worry about this.

The 4 space indentation is a style recommendation (not a requirement), and
if the only place that your code isn't meeting that recommendation is the
YAML header then I can't imagine that any reviewer will worry too much
about this.  The review process is also a dialog between the package author
and reviewer, so you have a chance to explain reasons why your code may be
triggering BiocCheck messages, and if the explanation is reasonable (as
this sounds) then it will probably be accepted by the reviewer.

Best wishes,
Mike

On Thu, 23 Jul 2020 at 22:17, Carlos A. Catania (AKA Harpo) <
harpom...@gmail.com> wrote:

> Hello BioConductor Team,
>
> We are in the final steps prior to submitting a new package to
> Bioconductor.  As recommended, we want our package to pass BiocCheck with
> no Errors, Warnings, or Notes. However, we have a problem regarding the
> indentation of a vignette written rmarkdown.
>
> -- BEGIN BiocCheck output --
> [3] "Consider multiples of 4 spaces for line indents, 11 lines(0%) are not
> -- END BiocCheck output --
>
> The problem seems to be the indentation required for yaml syntax of the
> author section.  In the section, we have several authors, affiliations, and
> emails using just multiple of 2 space indentation. The problem is that we
> could found a way to correctly indent such a section without breaking the
> vignette construction process.
>
> We have observed that In section 3.1 of the biocstyle vignette about
> authoring using Rmarkdown (
>
> https://www.bioconductor.org/packages/release/bioc/vignettes/BiocStyle/inst/doc/AuthoringRmdVignettes.html
> )
> The author and affiliation sections uses just 2 spaces instead of the
> recommended multiple of 4.
>
> So, in your opinion, what would the recommended strategy for dealing with
> this issue?
> Regards,
>
> Carlos A. Catania (AKA Harpo)
>
> [[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

[Bioc-devel] Bioconductor Developers Forum - Thursday 16th July

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 16th July
at 09:00 PDT/ 12:00 EDT / 18:00 CEST
Calendar invite available from https://bit.ly/3gCsFXO

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

This month we'll be focusing on continuous integration with Github Actions
and how we can use this relatively new platform for a wide variety of
development tasks, including cross-platform testing of code and website
deployment.

Remember you can join the discussion any time in #developers-forum on
Bioconductor Slack (https://bioc-community.herokuapp.com/).

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Unable to reproduce OS/X build error for "netDx" package

[Mike Smith]

Hi Shraddha,

I don't know what Java the build system uses, but I can reproduce the error
with Java 13.  It's fine with Java 8 as you say.

I wont copy the whole error message as it's the same as I see on the build
system, but I do notice that in the middle I see:

Java 8 detected

This seems wrong for my system:

> system2('java', '-version')
java version "13.0.2" 2020-01-14
Java(TM) SE Runtime Environment (build 13.0.2+8)
Java HotSpot(TM) 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)

Perhaps there's an issue with whatever part of the code is detecting the
version of java?

Mike


On Wed, 24 Jun 2020 at 18:10, Shraddha Pai 
wrote:

> Hi BioC community,
> My package relies on a Java jar and detects whether the OS has Java 8 or
> 11, to be accordingly compatible. I can't seem to resolve the build error
> on the BioC Mac system; the error message is a symptom of Java 8
> incompatibility.
>
> However, on my 2014 Mac Air which runs Java 8, the offending example
> ("Predict_CaseControl_from_CNV.Rmd") runs through to completion. What is
> the issue here? It would be great to have all operating systems building
> successfully.
>
> Details below. Thanks!
>
> Shraddha
> ---
> Error: This is the error: "WARNING: An illegal reflective access operation
> has occurred
>
> WARNING: Illegal reflective access by net.sf.cglib.core.ReflectUtils$2
>
> (file:/Users/biocbuild/Library/Caches/netDx/763502120e4_genemania-netdx.jar)
> to method
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of
> net.sf.cglib.core.ReflectUtils$2"
>
> Mac specs: MacBook Air early 2014; High Sierra 10.13.6
>
> "java -version"  output:
> java version "1.8.0_31"
> Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
>
> R: 4.0.2 ; BioC 3.11
>
> sessionInfo output:
> > sessionInfo()
> R version 4.0.2 (2020-06-22)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS High Sierra 10.13.6
>
> Matrix products: default
> BLAS:
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
> LAPACK:
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
>
> locale:
> [1] C/C/C/C/C/en_CA.UTF-8
>
> attached base packages:
> [1] parallel  stats4stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
> [1] BiocFileCache_1.12.0 dbplyr_1.4.4 GenomicRanges_1.40.0
> [4] GenomeInfoDb_1.24.2  IRanges_2.22.2   S4Vectors_0.26.1
> [7] BiocGenerics_0.34.0  netDx_1.1.1  BiocStyle_2.16.0
>
> loaded via a namespace (and not attached):
>  [1] Biobase_2.48.0  httr_1.4.1
>  [3] splines_4.0.2   bit64_0.9-7
>  [5] foreach_1.5.0   R.utils_2.9.2
>  [7] assertthat_0.2.1BiocManager_1.30.10
>  [9] blob_1.2.1  GenomeInfoDbData_1.2.3
> [11] yaml_2.2.1  pillar_1.4.4
> [13] RSQLite_2.2.0   lattice_0.20-41
> [15] glue_1.4.1  digest_0.6.25
> [17] RColorBrewer_1.1-2  XVector_0.28.0
> [19] colorspace_1.4-1plyr_1.8.6
> [21] htmltools_0.5.0 Matrix_1.2-18
> [23] R.oo_1.23.0 XML_3.99-0.3
> [25] pkgconfig_2.0.3 bookdown_0.20
> [27] zlibbioc_1.34.0 purrr_0.3.4
> [29] scales_1.1.1MultiAssayExperiment_1.14.0
> [31] pracma_2.2.9combinat_0.0-8
> [33] tibble_3.0.1generics_0.0.2
> [35] ggplot2_3.3.2   ellipsis_0.3.1
> [37] SummarizedExperiment_1.18.1 ROCR_1.0-11
> [39] survival_3.1-12 RJSONIO_1.3-1.4
> [41] magrittr_1.5crayon_1.3.4
> [43] memoise_1.1.0   evaluate_0.14
> [45] R.methodsS3_1.8.0   doParallel_1.0.15
> [47] graph_1.66.0tools_4.0.2
> [49] lifecycle_0.2.0 matrixStats_0.56.0
> [51] stringr_1.4.0   glmnet_4.0-2
> [53] munsell_0.5.0   DelayedArray_0.14.0
> [55] compiler_4.0.2  rlang_0.4.6
> [57] grid_4.0.2  RCurl_1.98-1.2
> [59] iterators_1.0.12rappdirs_0.3.1
> [61] bigmemory.sri_0.1.3 igraph_1.2.5
> [63] bitops_1.0-6rmarkdown_2.3
> [65] gtable_0.3.0codetools_0.2-16
> [67] RCy3_2.8.0  DBI_1.1.0
> [69] curl_4.3reshape2_1.4.4
> [71] bigmemory_4.5.36R6_2.4.1
> [73] knitr_1.29  dplyr_1.0.0
> [75] bit_1.1-15.2shape_1.4.4
> [77] stringi_1.4.6   Rcpp_1.0.4.6
> [79] vctrs_0.3.1 tidyselect_1.1.0
> [81] xfun_0.15
>
>
> --
> Shraddha Pai, PhD
> http://shraddhapai.com ; @spaiglass on Twitter
> Post-doctoral Fellow, http://baderlab.org
> The Donnelly Centre for Cellular and Biomolecular Research
> University of Toronto
>
> [[alternative HTML version deleted]]
>
> 

Re: [Bioc-devel] Passing BiocCheck with roxygen2 tags.

[Mike Smith]

Hi Erik,

I think the #' @return tag will create the \value{} section in the Rd file.

Mike

On Thu, 25 Jun 2020 at 17:24, Erik Christensen  wrote:

> Hello,
>
> Is there a way to add the value section in man pages using roxygen tags? I
> am currently using "@section Value: ..." but this fails biocheck with
>
> "WARNING: Add non-empty \value sections to the following...{{dropped:18}}
>
> ___
> 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] Vignette Building Latex Errors on Windows Release Branch

[Mike Smith]

Reading around, it looks more likely this is an issue with pandoc than
LaTeX directly.  I guess it'd help to know what version of pandoc is
running on the build machine, I'm unable to recreate either using the
pandoc supplied with RStudio.

Mike

On Fri, 15 May 2020 at 21:09, Sergio Picart Armada 
wrote:

> Dear bioc devel,
>
> We are having the same problem with our package FELLA.
> Any help is appreciated!
>
> Best,
> Sergi
>
> Missatge de petr smirnov  del dia dv., 15 de maig
> 2020 a les 19:42:
>
> > I am having trouble reproducing some vignette build errors for our
> > PharmacoGx package on Windows (tokay2).
> >
> > The error is a Latex error:
> > LaTeX Error: Environment cslreferences undefined.
> >
> > It seems likely to be due to a missing dependency for the style file
> > we are using, however, I do not understand why it works on all other
> > build machines. tokay1 does not have the same error, and is building
> > the same vignette. Likewise, none of the other OS machines are missing
> > this dependency.
> >
> > I also tried to reproduce in a newly reinstalled Windows environment.
> > After installing R 4.0, Rtools, all the package dependencies, and:
> > knitr, knitcitations, rmarkdown, pander, and tinytex, the package
> > builds on the machine. As far as I can tell, all these packages are
> > also installed on tokay2.
> >
> > Does tokay2 use a different Latex distribution from what is installed
> > by tinytex ?
> >
> > --
> > Petr Smirnov
> >
> > psmirnov2...@gmail.com
> >
> > ___
> > 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
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] EBImage/cytomapper check error on tokay2 i386

[Mike Smith]

It looks like this is upstream of EBImage, and is an issue in the tiff
package, which is also currently failing on the 32-bit CRAN builder (
https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/tiff-00check.html).
The tiff::readTIFF() function is what's being used internally by EBImage in
the failing test.


On Wed, 22 Apr 2020 at 09:57, Mike Smith  wrote:

> I can confirm that I can reproduce this error on my own Windows machine.
> My first thought is that it's related to the new Windows toolchain.  I'll
> try to take a look today and see if there's a simple fix in the code.
>
> On Mon, 20 Apr 2020 at 11:12, Nils Eling  wrote:
>
>> Hi all,
>>
>> the checks for my newly submitted package seem to be failing on tokay2
>> i386 for a couple of days now:
>>
>>
>> https://bioconductor.org/checkResults/devel/bioc-LATEST/cytomapper/tokay2-checksrc.html
>> <
>> https://bioconductor.org/checkResults/devel/bioc-LATEST/cytomapper/tokay2-checksrc.html
>> >
>>
>> And it looks like this is coming from checks/examples failing for the
>> EBImage::readImage function.
>>
>>
>> https://bioconductor.org/checkResults/devel/bioc-LATEST/EBImage/tokay2-checksrc.html
>> <
>> https://bioconductor.org/checkResults/devel/bioc-LATEST/EBImage/tokay2-checksrc.html>
>>
>>
>> I can’t really figure out where this is coming from and how to address
>> this issue.
>> Does anyone have recommendations on how to proceed?
>> Best and thanks in advance,
>>
>> Nils
>> [[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] EBImage/cytomapper check error on tokay2 i386

[Mike Smith]

I can confirm that I can reproduce this error on my own Windows machine.
My first thought is that it's related to the new Windows toolchain.  I'll
try to take a look today and see if there's a simple fix in the code.

On Mon, 20 Apr 2020 at 11:12, Nils Eling  wrote:

> Hi all,
>
> the checks for my newly submitted package seem to be failing on tokay2
> i386 for a couple of days now:
>
>
> https://bioconductor.org/checkResults/devel/bioc-LATEST/cytomapper/tokay2-checksrc.html
> <
> https://bioconductor.org/checkResults/devel/bioc-LATEST/cytomapper/tokay2-checksrc.html
> >
>
> And it looks like this is coming from checks/examples failing for the
> EBImage::readImage function.
>
>
> https://bioconductor.org/checkResults/devel/bioc-LATEST/EBImage/tokay2-checksrc.html
> <
> https://bioconductor.org/checkResults/devel/bioc-LATEST/EBImage/tokay2-checksrc.html>
>
>
> I can’t really figure out where this is coming from and how to address
> this issue.
> Does anyone have recommendations on how to proceed?
> Best and thanks in advance,
>
> Nils
> [[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

[Bioc-devel] Updates to BiocStyle

[Mike Smith]

Dear All,

Andrzej Oleś and I have just added responsive layout support to the
devel branch of BiocStyle.  This should make the HTML vignettes produced by
the package work better on small screen sizes like phones & tablets.

The changes are summarised on Github at
https://github.com/Bioconductor/BiocStyle/pull/67

We've tested the updates with a number of vignettes on various devices, but
it's likely that there will be some edge cases that aren't covered.  If you
notice any vignettes rendering in unexpected or unhelpful ways we'd
appreciate feedback either here on the mailing list or via a Github issue (
https://github.com/Bioconductor/BiocStyle/issues).

Cheers,
Mike

[[alternative HTML version deleted]]

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

[Bioc-devel] Announcement: Update to Rhdf5lib

[Mike Smith]

Dear all,

This is a heads up that I've updated the version of HDF5 distributed in
Rhdf5lib to 1.10.6.

The change was principally motivated to allow the use of the S3 virtual
file driver allowing read access to HDF5 files stored in S3 buckets.  As
such the library compilation now uses the --enable-ros3-vfd flag if the
appropriate system libraries are installed.  Pre-compiled Windows binaries
are included and have been built with both the Rtool 3.5 and 4.0 toolchains.

Ideally the change should be transparent to users and packages, and all my
tests have found no required changes.  However those tests are not
exhaustive, and I will be keeping a close eye on the build system in case
something unexpected happens.  Those who maintain packages that link with
Rhdf5lib may wish to bump their version numbers to ensure the new version
is used.

Please let me know if you see any errors that may be related to this.

Best regards,
Mike

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor Developers Forum - Thursday 16th April

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 16th
April at 09:00 PDT/ 12:00 EDT / 18:00 CEST (Note: This is back to the usual
time in Europe, Check here!

)

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Currently we have two topics for this month

   - Joselyn Chavez will present "regutools" and discuss package
   development and submission from the point of view of a first time
   Bioconductor submission
   - Generally strategies for unit testing in packages, dealing with
   'problematic tests' e.g. internet resources, OS dependent results

Please let me know if you have any other topics to raise, and join
#developers-forum on Bioconductor Slack (
https://bioc-community.herokuapp.com/).

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] How can I maintain a stable list of source urls

[Mike Smith]

I was talking with another nix user a while back about this problem, and I
don't think there's a good solution at the moment.

One thing that strikes me is that when release packages get updated the old
versions get put in an archive and the source tarball remains available
e.g.
https://bioconductor.org/packages/3.10/bioc/src/contrib/Archive/biomaRt/
Currently
this archive is only created if a package is updated during the release
cycle.  Would it be sufficient for all packages to get an archive URL as
default?  Then if they aren't updated during a release cycle that URL is
fine, and if there are updates you get a new link to the new package source.

Something I'm not clear about is when you say this could be affected by
"changes inside the repo that affect the hash output".  AFAIK a new tarball
will only propagate to the download page if the version number has been
bumped, and so a new link will be generated.  I'm not sure how it's
possible to get a tarball with the same name but a different hash.

On Tue, 31 Mar 2020 at 23:03, Tim Sears  wrote:

> Hi
> I am working to make bioconductor packages available through the nix
> package manager (https://nixos.org/). Currently nixpkgs points to a source
> url on one of the bioconductor mirrors. nixpkgs tracks the url and a sha256
> hash of the unpacked source link. Unfortunately the links themselves often
> disappear as the packages get updated either due to a version number change
> or changes inside the repo that affect the hash output. This breaks
> corresponding nix package. This happens even for stable bioconductor
> versions like 3.10. nixpkgs aims for reproducible builds, which means when
> things change, the url should reflect the change too and the contents
> behich old urls should be preserved long enough to manage the  change. Do
> you have any suggestions short of rebuilding a bioconductor mirror with
> immutable urls?
>
> Thanks,
> TIm
>
> [[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] Bioconductor Developers Forum - Thursday 19th March

[Mike Smith]

Dear all,

Just a reminder that the next Bioconductor Developers' Forum is scheduled
for Thursday 19th March at 09:00 PDT/ 12:00 EDT / 17:00 CET (Note: Due to
daylight savings this is 1 hour earlier than normal in Europe, Check here!
<https://www.timeanddate.com/worldclock/converter.html?iso=20200319T16=991=422=224>
)

   - With the upcoming release and switch to R-4.0 Lori and the BioC core
   team will give us an overview of some of the changes that developers need
   to be looking out for.
   - I'd also like to review topics we've covered in previous calls, and
   get participant feedback on future directions and topics for the
   Developers' Forum.

Looking forward to it.

Mike

On Mon, 16 Mar 2020 at 13:27, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 19th
> March at 09:00 PST/ 12:00 EST / 18:00 CET
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/114067881 (Meeting ID: 114 067 881)
>
> As part of this month's call I thought would be good to guage peoples
> opinions on the type of topic we've been covering and the direction we
> should take things in the future.  If you have any thoughts on what you'd
> like covered by the Developers' Forum please bring it to the meeting, reply
> to this email, or use #developers-forum on Bioconductor Slack (
> https://bioc-community.herokuapp.com/).  Feel free to suggest anything of
> interest, don't feel like you need to match with the sort of direction
> we've gone previously.
>
> Best wishes,
>
> Mike
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor Developers Forum - Thursday 19th March

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 19th
March at 09:00 PST/ 12:00 EST / 18:00 CET

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

As part of this month's call I thought would be good to guage peoples
opinions on the type of topic we've been covering and the direction we
should take things in the future.  If you have any thoughts on what you'd
like covered by the Developers' Forum please bring it to the meeting, reply
to this email, or use #developers-forum on Bioconductor Slack (
https://bioc-community.herokuapp.com/).  Feel free to suggest anything of
interest, don't feel like you need to match with the sort of direction
we've gone previously.

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor Developers Forum - Thursday 20th February

[Mike Smith]

Dear all,

Just a reminder that the next Developers' Forum is today at 09:00 PST/
12:00 EST / 18:00 CET.  We have two schedule topics for today:

   - Nitesh Turaga will be talking about developments, potential use cases,
   and future directions for the Bioconductor docker containers
   - Robert Castelo is presenting the surprisingly tricky problem of
   determining the exact dependency path that leads to unexpected packages
   being loaded by your code

Looking forward to it.

Mike

On Mon, 17 Feb 2020 at 15:50, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 20th
> February at 09:00 PST/ 12:00 EST / 18:00 CET
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/114067881 (Meeting ID: 114 067 881)
>
> If you have any specific topics you'd like to raise please let me know or
> post in #developers-forum on Bioconductor Slack (
> https://bioc-community.herokuapp.com/)
>
> Best wishes,
>
> Mike
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor Developers Forum - Thursday 20th February

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 20th
February at 09:00 PST/ 12:00 EST / 18:00 CET

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

If you have any specific topics you'd like to raise please let me know or
post in #developers-forum on Bioconductor Slack (
https://bioc-community.herokuapp.com/)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor Developers Forum - Thursday 23rd January

[Mike Smith]

Just as a reminder, the next call is taking place today at 09:00 PST/ 12:00
EST / 18:00 CET

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

One topic for discussion is the new Windows toolchain being trialled on
CRAN.  Any other topics are welcome.

See you later,

Mike

On Mon, 20 Jan 2020 at 12:56, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 23rd
> January at 09:00 PST/ 12:00 EST / 18:00 CET
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/114067881 (Meeting ID: 114 067 881)
>
> If you have any specific topics you'd like to raise please let me know or
> post in #developers-forum on Bioconductor Slack (
> https://bioc-community.herokuapp.com/)
>
> Best wishes,
>
> Mike
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor Developers Forum - Thursday 23rd January

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 23rd
January at 09:00 PST/ 12:00 EST / 18:00 CET

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

If you have any specific topics you'd like to raise please let me know or
post in #developers-forum on Bioconductor Slack (
https://bioc-community.herokuapp.com/)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor Developers Forum - Thursday 19th December

[Mike Smith]

Dear all,

Just a reminder that this is happening today.

It appears I am resolutely wishing for summer time still - the intended
time is 09:00 PST/ 12:00 EST / 18:00 CET

Best wishes,
Mike

On Mon, 16 Dec 2019 at 15:49, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 19th
> December at 09:00 PDT/ 12:00 EDT / 18:00 CEST
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/114067881 (Meeting ID: 114 067 881)
>
> If you have any specific topics you'd like to raise please let me know or
> post in #developers-forum on Bioconductor Slack (
> https://bioc-community.herokuapp.com/)
>
> Best wishes,
>
> Mike
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Question regarding pruning release of large files

[Mike Smith]

Hi Saskia,

There's some documentation on this at
https://bioconductor.org/developers/how-to/git/remove-large-data/

I guess the most pertinent part is "The Bioconductor git server does not
allow -f or to force push to the git.bioconductor.org location. Please
email bioc-devel@r-project.org explaining the package has been cleaned for
large data files and needs to be reset.".  Seems like you've done the
emailing part, so I'm sure someone will be in touch soon.

Mike

On Thu, 19 Dec 2019 at 05:20, Saskia Freytag <
saskia.frey...@perkins.uwa.edu.au> wrote:

> Hi,
>
> I stupidly added and tracked some large files in my package repo at the
> start. I have since deleted these files and would like to permanently
> remove them form my GitHub history. I have been able to this locally.
> However when I try to do ‘git push upstream RELEASE_3_10’, it asks me to
> fetch first. This results in the history being restored. I have tried to do
> ‘git push —force’, but this results in an error. Is there any way to delete
> the history of these files from the upstream?
>
> Cheers,
>
> Saskia
> ___
> 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

[Bioc-devel] Bioconductor Developers Forum - Thursday 19th December

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 19th
December at 09:00 PDT/ 12:00 EDT / 18:00 CEST

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

If you have any specific topics you'd like to raise please let me know or
post in #developers-forum on Bioconductor Slack (
https://bioc-community.herokuapp.com/)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Long Tests builds

[Mike Smith]

Thanks Hervé for documenting this, should be very useful.

Do you think there's any merit in identifying if there are currently
packages that take very close to the 40 minutes mark at the moment, and
pointing this feature out to the maintainers directly?  I don't know how
tight for time the build process currently is.

Cheers,
Mike

On Thu, 5 Dec 2019 at 19:11, Pages, Herve  wrote:

> Hello developers,
>
> These builds were announced on this list in Nov. 2017 (see
> https://stat.ethz.ch/pipermail/bioc-devel/2017-November/012326.html).
>
> The purpose of the "Long Tests builds" is to run tests that are too long
> to run in the 40 min. allowed by the daily builds. With the Long Tests
> builds, tests are allowed to run for a maximum of **6 hours** before a
> TIMEOUT is raised. These builds are run once a week (every Saturday).
>
> Setting long tests in your package is easy and is now documented:
>
>https://bioconductor.org/developers/how-to/long-tests/
>
> Also these builds are now running on all 3 platforms:
>
>https://bioconductor.org/checkResults/devel/bioc-longtests-LATEST/
>
> Don't hesitate to use them!
>
> Questions/feedback welcome.
>
> Cheers,
> H.
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
> ___
> 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] Error in building vignette for previously stable version

[Mike Smith]

Hi Jakob,

This looks like the same problem a few others have reported.  The latest
advice was to wait for BiocStyle to be updated to reflect changes in
rmarkdown, so you don't need to do anything for now:

https://stat.ethz.ch/pipermail/bioc-devel/2019-December/015870.html

Mike

On Thu, 5 Dec 2019 at 08:59, Jakob Willforss 
wrote:

> Hi all,
>
>
> I am the developer of NormalyzerDE. A few days ago the release version of
> NormalyzerDE started getting errors in the vignette building (with no
> updates from my side). I saw in the mailing list that others also had
> encountered issues in the vignette. I don't know how widespread the issue
> is though.
>
>
> Is this something I should try to address myself, or just leave it be for
> now?
>
>
> I attach the error below.
>
>
> Best wishes,
>
> Jakob
>
>
> * checking for file ‘NormalyzerDE/DESCRIPTION’ ... OK
> * preparing ‘NormalyzerDE’:
> * checking DESCRIPTION meta-information ... OK
> * installing the package to build vignettes
> * creating vignettes ... ERROR
> --- re-building ‘vignette.Rmd’ using rmarkdown
> Warning in file(con, "r") :
>   file("") only supports open = "w+" and open = "w+b": using the former
> ! LaTeX Error: Command \VerbBar already defined.
>Or name \end... illegal, see p.192 of the manual.
>
> Error: processing vignette 'vignette.Rmd' failed with diagnostics:
> Failed to compile vignette.tex. See
> https://yihui.name/tinytex/r/#debugging for debugging tips. See
> vignette.log for more info.
> --- failed re-building ‘vignette.Rmd’
>
> SUMMARY: processing the following file failed:
>   ‘vignette.Rmd’
>
> Error: Vignette re-building failed.
> Execution halted
>
>
> [[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] Problem with uncompressing files on tokay1?

[Mike Smith]

Could this be another instance where you need to specify mode = "wb" when
you call download.file()?  I've seen many examples of Windows downloads
being corrupted because it uses mode = "w" by default.

Presumably BiocFileCache would both handle this correctly and save multiple
downloads, so it's a double win.



On Mon, 25 Nov 2019 at 15:40, Martin Morgan  wrote:

> Thanks this seems like a problem with large file size on Windows, probably
> in Rhtslib.
>
> It might be better practice and more reliable to use BiocFileCache for
> downloads, e.g.,
>
> url = "
> ftp://ftp.plantgenie.org/Tutorials/RnaSeqTutorial/data/star/unitTest/213.1_subset_sortmerna_trimmomatic_sorted.bam.bai
> "
> BiocFileCache::bfcrpath(rnames = url)
>
> which downloads (once) and returns the path to the cached file.
>
> Martin
>
> On 11/25/19, 8:24 AM, "Bioc-devel on behalf of Nicolas Delhomme" <
> bioc-devel-boun...@r-project.org on behalf of nicolas.delho...@umu.se>
> wrote:
>
> Hej!
>
> The easyRNASeq package is not building on tokay1, with what seems to
> be a file decompression issue?
>
>
> https://master.bioconductor.org/checkResults/3.10/bioc-LATEST/easyRNASeq/tokay1-buildsrc.html
>
> It works fine on the other OSs.
>
> The error is triggered while downloading a small dataset during the
> vignette creation. I use `download.file` as the function to fetch the data,
> so it should be cross-platform compatible. I have no easy access to a
> windows machine, so I can’t easily reproduce the problem. Any insight into
> what could be the reason would be much appreciated :-)
>
> The easy solution would be to turn off the evaluation of that section
> of the vignette, but I’d rather not as it is a good test of the complete
> functionality of the package (something that would feel ill-fitted as a
> unit test).
>
> Thanks in advance,
>
> Nico
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> 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] Bioconductor Developers Forum - Thursday 21st November

[Mike Smith]

Dear all,

Just a reminder of the Bioconductor Developers' Forum today (Thursday 21st
November).

It has been pointed out to me that my last email gave timezones not
currently in use!  The schedued time is 09:00 PST / 12:00 EST / 18:00
CET (Check
Here
<https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=11=21=17=0=0=991=137=179>
)

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Updated agenda for today:

   - Update on issues and need-to-know items post BioC 3.10 release - Lori
   Shepherd & Hervé Pagès
   - Improving finability of BioC packages - Steffen Neumann
   - User and Developer session at EuroBioc2019 - Laurent Gatto

Best wishes,

Mike

On Mon, 18 Nov 2019 at 10:18, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 21st
> November at 09:00 PDT/ 12:00 EDT / 18:00 CEST
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/114067881 (Meeting ID: 114 067 881)
>
> This month we currently don't have any presentations, so it's going to be
> more of a round table discussion about things that have cropped up on the
> devel mailing list and Slack channel recently.
>
> If you have any specific topics you'd like to raise please let me know or
> post in #developers-forum on Bioconductor Slack (
> https://bioc-community.herokuapp.com/)
>
> Best wishes,
>
> Mike
>
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor Developers Forum - Thursday 21st November

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 21st
November at 09:00 PDT/ 12:00 EDT / 18:00 CEST

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

This month we currently don't have any presentations, so it's going to be
more of a round table discussion about things that have cropped up on the
devel mailing list and Slack channel recently.

If you have any specific topics you'd like to raise please let me know or
post in #developers-forum on Bioconductor Slack (
https://bioc-community.herokuapp.com/)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor Developers Forum - Thursday 17th October

[Mike Smith]

Dear all,

Just as a reminder, the next call is scheduled for today (Thursday 17th
October) at 09:00 PDT/ 12:00 EDT / 18:00 CEST

We will be using BlueJeans and  the meeting can be joined via:
https://bluejeans.com/528142528 (Meeting ID: 528 142 528)

Best wishes,

Mike

On Thu, 10 Oct 2019 at 16:56, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 17th
> October at 09:00 PDT/ 12:00 EDT / 18:00 CEST
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/528142528 (Meeting ID: 528 142 528)
>
> This month, motivated by some community suggestions, I thought we would
> take a break from the PowerPoint presentation style and instead listen to /
> share experiences of working with some of the core BioC packages.  If you
> have opinions on whether SummarizedExperiment is too complex, the best way
> to add data to ExperimentHub, the optimal parameters for disk-backed
> datasets, or anything similar come prepared to share them.
>
> I also thought, with the upcoming release of BioC 3.10, it might be
> interesting to discuss how we as developers prepare for the release date &
> update our systems afterwards.  Do you cease development, create a new
> branch, cram as many bug fixes as possible in the last week, or go on
> holiday until it's all over?
>
> More details and discussion can be found in the #developers-forum channel
> of the Bioconductor Slack (https://bioc-community.herokuapp.com/)
>
> Best wishes,
>
> Mike
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] download statistics for 2019?

[Mike Smith]

Also, if you're interested, I've been collating the downloads recorded via
bioconda at:

https://github.com/grimbough/anaconda-download-stats

On Thu, 10 Oct 2019 at 19:59, Sean Davis  wrote:

> Just a note that the BiocPkgTools package has a biocDownloadStats()
> function. It doesn't do anything special with the data, but it avoids
> having to remember the URLs, etc.
>
>
> https://bioconductor.org/packages/release/bioc/vignettes/BiocPkgTools/inst/doc/BiocPkgTools.html
>
> Sean
>
>
> On Thu, Oct 10, 2019 at 1:35 PM Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
> > Yes.  I was running updates on the machine that generates these statistic
> > when they were running on Monday which caused incomplete results. They
> > should be regenerated tomorrow. Sorry for the inconvenience.
> > 
> > From: Bioc-devel  on behalf of
> > Stephanie Gogarten 
> > Sent: Thursday, October 10, 2019 1:24:37 PM
> > To: bioc-devel@r-project.org 
> > Subject: [Bioc-devel] download statistics for 2019?
> >
> > Dear Bioc Core team,
> >
> > Are package download statistics available for the current year? On the
> > statistics page I only see previous years:
> > http://bioconductor.org/packages/stats/bioc/GENESIS/
> >
> > and the table does not exist:
> >
> https://bioconductor.org/packages/stats/bioc/GENESIS/GENESIS_2019_stats.tab
> >
> > thanks,
> > Stephanie
> >
> > --
> >
> > Stephanie M. Gogarten, PhD
> >
> > Team Lead, Sample QC and Analysis Software / TOPMed Data Coordinating
> > Center
> > 
> >
> > Senior Research Scientist / Genetic Analysis Center
> > 
> >
> > Department of Biostatistics 
> >
> > UNIVERSITY OF WASHINGTON
> >
> >
> >
> > UW Tower Box 359461
> >
> > 4333 Brooklyn Ave NE, Seattle, WA 98195
> >
> > 206.221.0757
> >
> > sdmor...@uw.edu 
> >
> > she/her/hers
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
> > This email message may contain legally privileged and/or confidential
> > information.  If you are not the intended recipient(s), or the employee
> or
> > agent responsible for the delivery of this message to the intended
> > recipient(s), you are hereby notified that any disclosure, copying,
> > distribution, or use of this email message is prohibited.  If you have
> > received this message in error, please notify the sender immediately by
> > e-mail and delete this email message from your computer. Thank you.
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
> --
> Sean Davis, MD, PhD
> Center for Cancer Research
> National Cancer Institute
> National Institutes of Health
> Bethesda, MD 20892
> https://seandavi.github.io/
> https://twitter.com/seandavis12
>
> [[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

[Bioc-devel] Bioconductor Developers Forum - Thursday 17th October

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 17th
October at 09:00 PDT/ 12:00 EDT / 18:00 CEST

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/528142528 (Meeting ID: 528 142 528)

This month, motivated by some community suggestions, I thought we would
take a break from the PowerPoint presentation style and instead listen to /
share experiences of working with some of the core BioC packages.  If you
have opinions on whether SummarizedExperiment is too complex, the best way
to add data to ExperimentHub, the optimal parameters for disk-backed
datasets, or anything similar come prepared to share them.

I also thought, with the upcoming release of BioC 3.10, it might be
interesting to discuss how we as developers prepare for the release date &
update our systems afterwards.  Do you cease development, create a new
branch, cram as many bug fixes as possible in the last week, or go on
holiday until it's all over?

More details and discussion can be found in the #developers-forum channel
of the Bioconductor Slack (https://bioc-community.herokuapp.com/)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Error in HDF5 - Package submission - Not detected locally

[Mike Smith]

Hi Tiago,

I suspect what has happened here is that when create the mini_pbmc3k
object, you're doing this by subsetting the PBMC, 3k scRNA-seq data from
ExperimenHub. The assay data for that are are actually stored in an HDF5
file which will be downloaded and stored in your ExperimentHub cache on
your local machine. When you take the subset for your new object it still
points to the same HDF5 file, and when you save mini_pbmc3k all it actually
saves is the location of the HDF5 rather than putting the data in the
object. This works locally, but naturally the BioC build server doesn't
have the original HDF5 in exactly the same location, and so it fails.

Is there a reason you don't want to use the whole dataset and make the
first section of the vignette demonstrate how to download it via
ExperimentHub? Alternatively there is a way to transform from an HDF5 back
SingleCellExperiment to using the data in memory, but I can't remember it
right now - hopefully someone else will be along shortly.

This also seems like the perfect opportunity to point out that our next
BioC Developers' Forum (
https://stat.ethz.ch/pipermail/bioc-devel/2019-September/015499.html) will
have a discussion on object serilaisation which should cover exactly this
type of issue.

Best,
Mike



On Sat, 14 Sep 2019 at 23:26, Tiago Lubiana Alves <
tiago.lubiana.al...@usp.br> wrote:

> Hello,
>
> I am having a problem with a package submission build.
>
> This is the package issue:
> https://github.com/Bioconductor/Contributions/issues/1241
> And this is the ERROR:
>
> HDF5-DIAG: Error detected in HDF5 (1.10.5) thread 0:
>   #000: C:/hdf5_build/CMake-hdf5-1.10.5/hdf5-1.10.5/src/H5F.c line 509
> in H5Fopen(): unable to open file
> major: File accessibilty
> minor: Unable to open file
>   #001: C:/hdf5_build/CMake-hdf5-1.10.5/hdf5-1.10.5/src/H5Fint.c line
> 1498 in H5F_open(): unable to open file: time = Fri Sep 13 15:05:35
> 2019
> , name = '/home/lubianat/.cache/ExperimentHub/5486ffbe0e3_1605',
> tent_flags = 0
> (...)
>
> Quitting from lines 46-51 (fcoex.Rmd)
> Error: processing vignette 'fcoex.Rmd' failed with diagnostics:
> failed to open file '/home/lubianat/.cache/ExperimentHub/5486ffbe0e3_1605'
> --- failed re-building 'fcoex.Rmd'
>
>
> It looks like something is pointing in the wrong direction, but I have not
> been able to figure out exactly what. I've tried re-saving the data file
> ("mini_pbmc3k"), which is loaded in the vignette chunk of the error, but
> that did not help.
>
> Does anyone have a suggestion of what might be happening?
>
> Thank you very much for your time,
> Best,
> Tiago
>
> Tiago Lubiana
> Mestrando em Bioinformática, FCF/USP
> *Computational Systems Biology Laboratory (CSBL)*
> Telefone (laboratório): +55 (11) 2648-0240
> Telefone (pessoal): +55 (11) 954258000
>
> [[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] new package for accessing some chemical and biological databases

[Mike Smith]

I've lost track of whether the infrastructure is actually used, but
certainly some package have a 'longtests' folder e.g.
https://github.com/LTLA/beachmat

On Fri, 13 Sep 2019 at 16:02, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> We used to have (? or at least discussed the possibility of) occasional
> extensive checking so we could have
>   tests
>   long_tests
> (names made up).
>
> On Fri, Sep 13, 2019 at 9:50 AM Martin Morgan 
> wrote:
>
> > Putting bioc-devel back in the loop.
> >
> > I think that the straight-forward answer to your original query is 'no,
> > git modules are not supported'.
> >
> > I think we'd carry on and say 'packages should be self-contained and
> > conform to the Bioconductor size and time constraints', so you cannot
> have
> > a very large package or a package that takes a long time to check, and
> you
> > can't download part of the package from some alternative source (except
> > perhaps AnnotationHub or ExperimentHub). I agree that the hubs are not
> > suitable for regularly updated files, and that they are meant for
> > biologically motivated rather than purely test-related data resources.
> >
> > While we 'could' make special accommodations on the build systems to
> > support your package, we have found that this is not a fruitful endeavor.
> >
> > A natural place to put files used in tests would be in the /tests
> > directory; these are not included in the installed package. But it seems
> > likely that including your tests would violate the time and / or space
> > limitations we place on packages.
> >
> > It seems likely that this leads to the question you pose below, which is
> > how do you know that you're running on the build system so that you can
> > perform more modest computations? This is similar to here, where special
> > resources are normally required
> >
> >   https://stat.ethz.ch/pipermail/bioc-devel/2019-September/015518.html
> >
> > Herve seems not willing to commit to an easy answer, perhaps because this
> > opens the door to people circumventing even minimal tests of their
> > package...
> >
> > Martin
> >
> > On 9/13/19, 7:49 AM, "Shepherd, Lori" 
> > wrote:
> >
> >
> > I'm including Martin and Herve for their opinions and to chime in too
> > since you took this conversation off the mailing list...
> >
> >
> > Could you please describe what you mean by works transparently?
> >
> >
> > We realize there isn't a function to call -  we were suggesting you
> > make a function to call that could be utilized
> >
> >
> > How does your caching system work?  I would also advise looking into
> > BiocFileCache - the Bioconductor suggested package for data caching of
> > files.
> >
> >
> >
> >
> > The relevant files to look at for the environment calls can be found
> > https://github.com/Bioconductor/Contributions
> >
> > esp.
> >
> https://github.com/Bioconductor/Contributions#r-cmd-check-environment
> >
> >
> >
> > Please also be mindful of:
> >
> > Submission Guidelines
> > https://bioconductor.org/developers/package-submission/
> >
> > Package Guidelines
> > https://bioconductor.org/developers/package-guidelines/
> >
> >
> >
> >
> > More specifically on the single package builder we use:
> > R CMD BiocCheckGitClone 
> > R CMD build --keep-empty-dirs --no-resave-data  
> >
> > R CMD check --no-vignettes --timings 
> >
> > R CMD BiocCheck --build-output-file= --new-package
> > 
> >
> >
> >
> > With the environment variables set up as described in the above link
> >
> >
> > special files are not encouraged and as far as I am aware not
> > allowed.  Herve who has more experience with the builders may be able to
> > chime in further here.
> >
> >
> >
> >
> >
> >
> >
> > Lori Shepherd
> > Bioconductor Core Team
> > Roswell Park Cancer Institute
> > Department of Biostatistics & Bioinformatics
> > Elm & Carlton Streets
> > Buffalo, New York 14263
> >
> >
> > 
> > From: Pierrick Roger 
> > Sent: Friday, September 13, 2019 2:48 AM
> > To: Shepherd, Lori 
> > Subject: Re: [Bioc-devel] new package for accessing some chemical and
> > biological databases
> >
> > Thank you for the example. However I do not think it is relevant.
> This
> > package has no examples, no tests and just one vignette. The `get`
> > function is part of the interface, so it makes sens to use it inside
> > the vignette. But for my package biodb, there is no function to call,
> > the cache works transparently.
> >
> > Could you please give me more details about the build process of
> > packages in
> > Bioconductor? Are there some environment variables set during the
> build
> > so a package can now it is being built or checked by Bioconductor? If
> > this is the case, maybe I could write a tweak in my code in order to
> > download the cache when needed.
> > If not, would it be 

[Bioc-devel] Bioconductor Developers Forum - Thursday 19th September

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 19th
September at 09:00 PDT/ 12:00 EDT / 18:00 CEST

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/645510122?src=join_info (Meeting ID: 645 510 122)

More details can be found in the #developers-forum channel of the
Bioconductor Slack (https://bioc-community.herokuapp.com/)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Biocondutor Developers Forum

[Mike Smith]

Just a reminder/confirmation that this is happening today (August 15th) at
09:00 PDT/ 12:00 EDT / 18:00 CEST using BlueJeans and can be joined via:

https://bluejeans.com/136043474?src=join_info (Meeting ID: 136 043 474)

The call should last no more than one hour.

We also have a slack channel for more discussion, sharing of slides, etc at:

https://app.slack.com/client/T35G93A5T/CLUJWDQF4/details/info

Today's agenda will be a bit flexible based on who joins and how things
proceed, but I will present recent changes to & discussion on biomaRt and
hopefully Aaron Lun will give an update on the status of some of his recent
work.  If you have anything burning to discuss or present, please let me
know.

Cheers,
Mike

On Thu, 8 Aug 2019 at 10:31, Mike Smith  wrote:

> Dear all,
>
> I am excited to announce a new initiative within the Bioconductor project
> - the Bioconductor Developers' Forum.  This monthly teleconference is
> intended as a platform for Bioconductor developers to describe existing
> software infrastructure to other members of the BioC community, to present
> plans for future developments, and discuss changes that may impact other
> developers or software tools within the Bioconductor.
>
> The intended audience is anyone interested in software development and
> infrastructure, whether you're a member of the BioC core team with
> responsibility for multiple packages, or you're just getting started with
> creating a Bioconductor package.
>
> Our first meeting will take place on Thursday 15th August at 09:00 PDT/
> 12:00 EDT / 18:00 CEST using BlueJeans and can be joined via:
>
> https://bluejeans.com/136043474?src=join_info (Meeting ID: 136 043 474)
>
> More details on the intentions for this initiative, including a list of
> proposed topics, can found at:
>
>
> https://www.huber.embl.de/users/msmith/Bioconductor-Developers-Forum-Proposal.pdf
>
>
> The agenda for the first meeting is still open, so if you have a proposal
> or a particular topic you wish to prioritise please reach out to me.
>
> Best wishes,
>
> Mike
>
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Resetting to previous commits

[Mike Smith]

Yes, the Bioconductor build system will only try to build the most recent
version in the git repository.  If it never managed to successfully build a
particular version then that version should not appear anywhere on the Bioc
site.  For example biomaRt is now on release 2.40.3, but version 2.40.2
never passed all the checks, and so is absent from the archive at
https://bioconductor.org/packages/3.9/bioc/src/contrib/Archive/biomaRt/  In
theory someone could get hold of it via git, anyone doing so it probably
experienced enough to look after themselves.

Best,
Mike

On Wed, 14 Aug 2019 at 18:12, Erik Fasterius 
wrote:

> Thank you for the prompt response! I will just add more versions on top of
> what I have already added. Would it be correct to assume that Bioconductor
> will try to build the most recent version available, even though it failed
> builds for previous versions?
>
> Regarding the change, it was indeed a breaking change, and I thus believed
> that it would have been counted as a bug-fix for the release branch.
>
> All the best,
> Erik
>
> On 14 Aug 2019, at 17:15, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
> Also, it is not clear to me if this qualifies for a update to the release
> branch. Updates to release should be restricted to critical bug fixes
> (although if tidyr updates will break your package, that sounds like a
> critical bug fix to me)
>
> Note to others: this (again) emphasizes that we may need to "copy" a
> snapshot of CRAN into release.
>
> Best,
> Kasper
>
> On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> You cannot revert. By pushing those updates, you released a version into
> the wild. It is true that as long as it doesn't build on the build servers,
> it would have been hard to obtain for anyone, but it is still possible
> through git. You need to update the version.
>
> Best,
> Kasper
>
> On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <
> erik.faster...@outlook.com> wrote:
> I made some changes to my seqCAT package the last few days in order to
> prepare for version 1.0.0 of tidyr, which was apparently harder than I
> initially thought. I was also a bit too quick with pushing to Bioconductor
> (both the release and devel branches), and now I’ve got several updates and
> versions that don’t work - very stupid of me, I know. I do seem to have a
> working version now, though, and I finally learnt my lesson and have NOT
> pushed this to Bioconductor yet. Now I want to reset to the previously
> working versions of my package (1.6.0 for release and 1.7.2 for devel)
>
> I did try to make (temporary) hard resets and force push these to
> Bioconductor (as per the “reset to a previous commit” in the “abandon
> changes” developer section), but these did not work: all I got was errors
> say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
> (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have to
> make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
> those, leaving several non-functional versions at Bioconductor? If at all
> possible I’d like to avoid this.
>
> Again, I realise these problems are because of errors on my part, and
> would like to know if I can solve them somehow or if I’ll just have to live
> with them.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> --
> Best,
> Kasper
>
>
> --
> 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

[Bioc-devel] Biocondutor Developers Forum

[Mike Smith]

Dear all,

I am excited to announce a new initiative within the Bioconductor project -
the Bioconductor Developers' Forum.  This monthly teleconference is
intended as a platform for Bioconductor developers to describe existing
software infrastructure to other members of the BioC community, to present
plans for future developments, and discuss changes that may impact other
developers or software tools within the Bioconductor.

The intended audience is anyone interested in software development and
infrastructure, whether you're a member of the BioC core team with
responsibility for multiple packages, or you're just getting started with
creating a Bioconductor package.

Our first meeting will take place on Thursday 15th August at 09:00 PDT/
12:00 EDT / 18:00 CEST using BlueJeans and can be joined via:

https://bluejeans.com/136043474?src=join_info (Meeting ID: 136 043 474)

More details on the intentions for this initiative, including a list of
proposed topics, can found at:

https://www.huber.embl.de/users/msmith/Bioconductor-Developers-Forum-Proposal.pdf


The agenda for the first meeting is still open, so if you have a proposal
or a particular topic you wish to prioritise please reach out to me.

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] HiCBricks build error

[Mike Smith]

I've pushed an update to the configure script that will hopefully find zlib
correctly now.  This wil be in Rhdf5lib 1.7.4.  The installation is
supposed to fail if zlib isn't found, so there was clearly at least two
problems in the existing script.  I'll keep an eye on the build reports and
push more changes if this doesn't fix the problem.

Mike

On Tue, 30 Jul 2019 at 09:53, Mike Smith  wrote:

> There are many other packages affected by this
> e.g. biomformat, BiocSklearn, CoGAPS, ...  It looks like Rhdf5lib is being
> built without linking to zlib, and so files written with zlib compression
> can't be read.  I've been trying to get Rhdf5lib to play more smoothly for
> systems that use conda as a package manager, but it seems I've introduced a
> regression.  I'll look into why this is the case, I'm a bit confused as to
> why rhdf5 is not failing in a similar way.
>
> Mike
>
> On Mon, 29 Jul 2019 at 17:53, Koustav Pal  wrote:
>
>> Hi,
>>
>> My package HiCBricks is producing build errors on malbec1 and merida1,
>> but build has passed on tokay1. The corresponding build on travis-ci has
>> also passed. I can also confirm that the last commits on travis is the same
>> as that on the bioconductor build machines.
>>
>> Herein, is the build logs from the malbec1. travis-ci vignette building
>> also completes successfully.
>>
>> > * checking for file ‘HiCBricks/DESCRIPTION’ ... OK
>> > * preparing ‘HiCBricks’:
>> > * checking DESCRIPTION meta-information ... OK
>> > * installing the package to build vignettes
>> > * creating vignettes ... ERROR
>> > --- re-building ‘IntroductionToHiCBricks.rmd’ using rmarkdown
>> > Loading required package: curl
>> > Loading required package: rhdf5
>> > Loading required package: R6
>> > Loading required package: grid
>> > HDF5-DIAG: Error detected in HDF5 (1.10.5) thread 0:
>> >   #000: H5Dio.c line 199 in H5Dread(): can't read data
>> > major: Dataset
>> > minor: Read failed
>> >   #001: H5Dio.c line 601 in H5D__read(): can't read data
>> > major: Dataset
>> > minor: Read failed
>> >   #002: H5Dchunk.c line 2259 in H5D__chunk_read(): unable to read raw
>> data chunk
>> > major: Low-level I/O
>> > minor: Read failed
>> >   #003: H5Dchunk.c line 3624 in H5D__chunk_lock(): data pipeline read
>> failed
>> > major: Dataset
>> > minor: Filter operation failed
>> >   #004: H5Z.c line 1301 in H5Z_pipeline(): required filter 'deflate' is
>> not registered
>> > major: Data filters
>> > minor: Read failed
>> >   #005: H5PLint.c line 270 in H5PL_load(): search in path table failed
>> > major: Plugin for dynamically loaded library
>> > minor: Can't get value
>> >   #006: H5PLpath.c line 604 in H5PL__find_plugin_in_path_table():
>> search in path /usr/local/hdf5/lib/plugin encountered an error
>> > major: Plugin for dynamically loaded library
>> > minor: Can't get value
>> >   #007: H5PLpath.c line 656 in H5PL__find_plugin_in_path(): can't open
>> directory: /usr/local/hdf5/lib/plugin
>> > major: Plugin for dynamically loaded library
>> > minor: Can't open directory or file
>> > Quitting from lines 286-289 (IntroductionToHiCBricks.rmd)
>> > Error: processing vignette 'IntroductionToHiCBricks.rmd' failed with
>> diagnostics:
>> > Unable to read dataset.
>> > Not all required filters available.
>> > Missing filters: deflate
>> > --- failed re-building ‘IntroductionToHiCBricks.rmd’
>> >
>> > SUMMARY: processing the following file failed:
>> >   ‘IntroductionToHiCBricks.rmd’
>> >
>> > Error: Vignette re-building failed.
>> > Execution halted
>>
>> Koustav Pal, PhD
>> Post-Doctoral Fellow in Genome Architecture,
>> Computational Genomics Group,
>> IFOM - The FIRC Institute of Molecular Oncology,
>> Via Adamello 16,
>> 20139 Milano, Italy.
>> Phone: +393441130157
>> E-mail: koustav@ifom.eu
>>
>>
>>
>>
>> [[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] HiCBricks build error

[Mike Smith]

There are many other packages affected by this
e.g. biomformat, BiocSklearn, CoGAPS, ...  It looks like Rhdf5lib is being
built without linking to zlib, and so files written with zlib compression
can't be read.  I've been trying to get Rhdf5lib to play more smoothly for
systems that use conda as a package manager, but it seems I've introduced a
regression.  I'll look into why this is the case, I'm a bit confused as to
why rhdf5 is not failing in a similar way.

Mike

On Mon, 29 Jul 2019 at 17:53, Koustav Pal  wrote:

> Hi,
>
> My package HiCBricks is producing build errors on malbec1 and merida1, but
> build has passed on tokay1. The corresponding build on travis-ci has also
> passed. I can also confirm that the last commits on travis is the same as
> that on the bioconductor build machines.
>
> Herein, is the build logs from the malbec1. travis-ci vignette building
> also completes successfully.
>
> > * checking for file ‘HiCBricks/DESCRIPTION’ ... OK
> > * preparing ‘HiCBricks’:
> > * checking DESCRIPTION meta-information ... OK
> > * installing the package to build vignettes
> > * creating vignettes ... ERROR
> > --- re-building ‘IntroductionToHiCBricks.rmd’ using rmarkdown
> > Loading required package: curl
> > Loading required package: rhdf5
> > Loading required package: R6
> > Loading required package: grid
> > HDF5-DIAG: Error detected in HDF5 (1.10.5) thread 0:
> >   #000: H5Dio.c line 199 in H5Dread(): can't read data
> > major: Dataset
> > minor: Read failed
> >   #001: H5Dio.c line 601 in H5D__read(): can't read data
> > major: Dataset
> > minor: Read failed
> >   #002: H5Dchunk.c line 2259 in H5D__chunk_read(): unable to read raw
> data chunk
> > major: Low-level I/O
> > minor: Read failed
> >   #003: H5Dchunk.c line 3624 in H5D__chunk_lock(): data pipeline read
> failed
> > major: Dataset
> > minor: Filter operation failed
> >   #004: H5Z.c line 1301 in H5Z_pipeline(): required filter 'deflate' is
> not registered
> > major: Data filters
> > minor: Read failed
> >   #005: H5PLint.c line 270 in H5PL_load(): search in path table failed
> > major: Plugin for dynamically loaded library
> > minor: Can't get value
> >   #006: H5PLpath.c line 604 in H5PL__find_plugin_in_path_table(): search
> in path /usr/local/hdf5/lib/plugin encountered an error
> > major: Plugin for dynamically loaded library
> > minor: Can't get value
> >   #007: H5PLpath.c line 656 in H5PL__find_plugin_in_path(): can't open
> directory: /usr/local/hdf5/lib/plugin
> > major: Plugin for dynamically loaded library
> > minor: Can't open directory or file
> > Quitting from lines 286-289 (IntroductionToHiCBricks.rmd)
> > Error: processing vignette 'IntroductionToHiCBricks.rmd' failed with
> diagnostics:
> > Unable to read dataset.
> > Not all required filters available.
> > Missing filters: deflate
> > --- failed re-building ‘IntroductionToHiCBricks.rmd’
> >
> > SUMMARY: processing the following file failed:
> >   ‘IntroductionToHiCBricks.rmd’
> >
> > Error: Vignette re-building failed.
> > Execution halted
>
> Koustav Pal, PhD
> Post-Doctoral Fellow in Genome Architecture,
> Computational Genomics Group,
> IFOM - The FIRC Institute of Molecular Oncology,
> Via Adamello 16,
> 20139 Milano, Italy.
> Phone: +393441130157
> E-mail: koustav@ifom.eu
>
>
>
>
> [[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] Help needed: Rdisop on Windows "File format not recognized"

[Mike Smith]

I can reproduce the error using R-3.6.0beta and running the following two
steps to replicate the Bioc builder commands:

R CMD build --keep-empty-dirs --no-resave-data Rdisop
rm -rf Rdisop.buildbin-libdir && mkdir Rdisop.buildbin-libdir &&
C:\Users\biocbuild\bbs-3.9-bioc\R\bin\R.exe CMD INSTALL --merge-multiarch
--build --library=Rdisop.buildbin-libdir Rdisop_1.43.4.tar.gz

Bit of a guess, and I don't know why this would have changed, but
the Rdisop_1.43.4.tar.gz produced by step one contains the *.o files
referenced in the error.  If these were produced for 64-bit architecture
then they'll fail when the build process tries to use them for the 32-bit
binary.  Perhaps your Rcpp edits removed some cleanup code that was there
before?  I note there's no Makevars.win or cleanup.win but my memory is a
bit fuzzy on whether only versions with *.win will be run on Windows or if
that's just a way to provide alternative code if needed.

On Thu, 18 Apr 2019 at 11:35, Neumann, Steffen 
wrote:

> Hi,
>
> with the next release coming up, I am out of wits regarding the failure at
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/Rdisop/tokay2-buildbin.html
> which exists since before April this year, when we committed
> some changes to get rid of the RcppClassic dependency.
>
> Max Helf succeeded to build locally on windows without problem.
>
> So it seems that Rdisop has issues with the BioC windows build
> environment, but I totally fail to see the reason.
>
> Could it be the new staged installation ?
> But I wouldn't know why that'd affect the compile/linking.
>
> The issue is tracked at
> https://github.com/sneumann/Rdisop/issues/13
>
> Any help/pointers appreciated.
>
> Yours,
> Steffen
>
> --
>
> IPB HalleAG Massenspektrometrie & Bioinformatik
> Dr. Steffen Neumann  http://www.IPB-Halle.DE
> Weinberg 3   Tel. +49 (0) 345 5582 - 1470
> 06120 Halle   +49 (0) 345 5582 - 0
> sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409
> ___
> 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] ddply causes error during R check

[Mike Smith]

If you're sure these are false positives (and it looks like they are) then
you can use utils::globalVariables() outside of your function to get rid of
the note.  It might also be worth pointing out that there are also plenty
of Bioconductor packages that don't do this and simply have this mentioned
in the check results e.g
http://bioconductor.org/checkResults/devel/bioc-LATEST/beadarray/malbec2-checksrc.html
 .

Mike

On Tue, 12 Feb 2019 at 08:35, web working  wrote:

> Hi,
>
> I am developing a Bioconductor package and can not get rid of some
> warning messages. During devtools::check() I get the following warning
> messages:
>
> ...
> summarizeDataFrame: no visible binding for global variable ‘name’
> summarizeDataFrame: no visible binding for global variable ‘gene’
> summarizeDataFrame: no visible binding for global variable ‘value’
> ...
>
> Here a short version of the function:
>
> #' Collapse rows with duplicated name column
> #'
> #' @param dat a \cite{tibble} with the columns name, gene and value
> #' @importFrom plyr ddply
> #' @import tibble
> #' @return a \cite{tibble}
> #' @export
> #'
> #' @examples
> #' dat <- tibble(name = c(paste0("position", 1:5), paste0("position",
> c(1:3))), gene = paste0("gene", 1:8), value = 1:8)
> #' summarizeDataFrame(dat)
> summarizeDataFrame <- function(dat){
>ddply(dat, "name", "summarize",
>  name=unique(name),
>  gene=paste(unique(gene), collapse = ","),
>  value=mean(value))
> }
>
> R interprets the "name", "gene" and "value" column names as variables
> during the check. Does anyone has an idea how to change the syntax of
> ddply or how to get rid of the warning message?
>
> Thanks in advance!
>
> Tobias
>
> ___
> 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] Fwd: singscore problems reported in the Multiple platform build/check report for BioC 3.8

[Mike Smith]

Hi Ruqian,

I think this is a consequence of your internal data.frames have column
names that include the minus sign i.e. "-".  The code clearly tries to deal
with this by wrapping them in back-ticks at certain points, but I think it
doesn't do this successfully in projectScoreLandscape()

First, consider this example, which I think is a simplified version of what
happens in plotScoreLandscape()

df <- data.frame(x = 1:10, y = 1:10)
colnames(df) <-  c("tgca-EPI","tgca-MES")
ggplot(df, aes_string("`tgca-EPI`", "`tgca-MES`")) +
  geom_point()

For me this works & produces a plot where the axis labels include the
backticks i.e. `tgca-EPI` and `tgca-EPI`

Now we rename the columns of our data.frame to include the back-ticks,
which is what happens when plabs = c(plotObj$labels$x, plotObj$labels$y) is
called within projectScoreLandscape(). We plot in the same fashion and get
an error similar to what you're seeing.

colnames(df) <-  c("`tgca-EPI`","`tgca-MES`")
ggplot(df, aes_string("`tgca-EPI`", "`tgca-MES`")) +
  geom_point()

Error in FUN(X[[i]], ...) : object 'tgca-EPI' not found

Why this behavior would change I don't know, but presumably something in
one of the tidyverse packages has led to this.  You should probably
investigate more, but if this is the problem then you can modify that plabs
line in projectScoreLandscape() to strip the back-ticks. However, perhaps a
more robust solution is to enforce the use of "_" rather than "-" in column
names, that way you don't have to worry about using back-ticks to quote the
non-syntactic names.

Best regards,

Mike

On Mon, 5 Nov 2018 at 14:21, Ruqian Lyu 
wrote:

> Hi Bioconductor,
>
> I received a notification email regarding the building error for our
> package 'singscore'.
>
> I pull the RELEASE_3_8 branch and checked/built on my local machine, it was
> successful without errors.
>
> The error message was within the vignette which hasn't been updated for
> several months.
>
> Would please help with identifying the problem?
>
> Thanks a lot!
>
> Best regards,
> Ruqian
>
> -- Forwarded message -
> From: 
> Date: Fri, Nov 2, 2018 at 12:14 AM
> Subject: singscore problems reported in the Multiple platform build/check
> report for BioC 3.8
> To: 
>
>
> [This is an automatically generated email. Please don't reply.]
>
> Hi singscore maintainer,
>
> According to the Multiple platform build/check report for BioC 3.8,
> the singscore package has the following problem(s):
>
>   o ERROR for 'R CMD build' on malbec1. See the details here:
>
>
> https://master.bioconductor.org/checkResults/3.8/bioc-LATEST/singscore/malbec1-buildsrc.html
>
> Please take the time to address this by committing and pushing
> changes to your package at git.bioconductor.org
>
> Notes:
>
>   * This was the status of your package at the time this email was sent to
> you.
> Given that the online report is updated daily (in normal conditions)
> you
> could see something different when you visit the URL(s) above,
> especially if
> you do so several days after you received this email.
>
>   * It is possible that the problems reported in this report are false
> positives,
> either because another package (from CRAN or Bioconductor) breaks your
> package (if yours depends on it) or because of a Build System problem.
> If this is the case, then you can ignore this email.
>
>   * Please check the report again 24h after you've committed your changes
> to the
> package and make sure that all the problems have gone.
>
>   * If you have questions about this report or need help with the
> maintenance of your package, please use the Bioc-devel mailing list:
>
>   https://bioconductor.org/help/mailing-list/
>
> (all package maintainers are requested to subscribe to this list)
>
> For immediate notification of package build status, please
> subscribe to your package's RSS feed. Information is at:
>
> https://bioconductor.org/developers/rss-feeds/
>
> Thanks for contributing to the Bioconductor project!
>
> [[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

[Bioc-devel] Major update to rhdf5 and Rhdf5lib

[Mike Smith]

Hi all,

I've just submitted updated versions of rhdf5 (2.25.7) and Rhdf5lib (1.3.2)
to the BioC devel branch.  These represent a significant change as the
underlying version of HDF5 has now changed from 1.8.19 to 1.10.2.  This has
been done in response to an increasing prevalence of files that cannot be
read with HDF5 1.8.

The most significant change from an R package point of view is that the
internal handles for HDF5 objects switched to being 64bit integers, which
are more tricky to deal with directly in R.  Hopefully I have caught and
handled these cases, and the packages are building/passing check for me on
Linux and Windows.  I have also run the tests distributed with HDF5Array,
DelayedArray, and DelayedMatrixStats and all seem fine.  However, if you
encounter a new and exciting error please reply here or open an issue at
https://github.com/grimbough/rhdf5/issues

HDF5 1.10 provides a number of new features that you can read about at
https://support.hdfgroup.org/HDF5/docNewFeatures/ If you need access to one
of these and it's not obviously available via rhdf5 then again please
contact me & I'll prioritise things accordingly.

Thanks,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Git file size limits

[Mike Smith]

Thanks Martin.  I'll wait til Nitesh is back.  Hopefully I've successfully
reverted my changes to rhdf5 that depended on this!

Cheers,
Mike

On Wed, 22 Aug 2018 at 19:20, Martin Morgan  wrote:

> exceptions can be made; this will take just a little bit of time, as our
> expert (Nitesh) is out of communication for a bit...
>
> On 08/22/2018 10:01 AM, Mike Smith wrote:
> > Hi,
> >
> > I'm trying to commit an update to Rhdf5lib but run into the 5MB file size
> > restriction.  The file in question is the pre-compiled Windows binary so
> > I'm not sure there's anything I can do to make it smaller.  Is is
> possible
> > to make exceptions on a per-package basis?
> >
> > Thanks,
> > Mike
> >
> >   [[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

[Bioc-devel] Git file size limits

[Mike Smith]

Hi,

I'm trying to commit an update to Rhdf5lib but run into the 5MB file size
restriction.  The file in question is the pre-compiled Windows binary so
I'm not sure there's anything I can do to make it smaller.  Is is possible
to make exceptions on a per-package basis?

Thanks,
Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Synching version numbers went wrong

[Mike Smith]

Hi Shana,

Sorry for the delay in replying - I've been on vacation.  I tested this
with one of my own packages and found the same problem.  I'm not sure how
you managed to commit the lower version number in the first place (I'm not
going to test that since I'll get stuck too!) but I guess the logic for
allowing commits has a loophole somewhere.  I'll raise a query in the Slack
channel and hopefully someone with power over the git repository will get
back to you soon.

Mike

On Mon, 23 Jul 2018 at 21:20, White, Shana (vandersm) 
wrote:

> Hi Mike,
>
>
> My colleague and I have spent a few hours attempting to fix this problem;
> we can only propogate changes with version numbers 1.5x and cannot do 1.6x
> or 1.7x on the devel branch - it seems like the  Bioconductor automatic
> checks are preventing us from updating the files and at this point we
> believe the version number can only be fixed from within Bioconductor.
> Does the Bioconductor team need to manually change the version number or
> should we try to force push the changes ourselves? Please let me know if
> you need any additional details.
>
>
> Best,
>
>
>
> Shana White
> Ph. D Candidate  - Biostatistics + Bioinformatics
> <https://med.uc.edu/eh/divisions/bio>
> Predoctoral Fellow - MECEH
> <https://med.uc.edu/eh/divisions/epi/programs/meceh>
> Room 318 Kettering Labs
> vande...@mail.uc.edu
> 937-657-8289
>
>
> --
> *From:* Mike Smith 
> *Sent:* Thursday, July 12, 2018 4:57:55 AM
> *To:* White, Shana (vandersm)
> *Cc:* bioc-devel
> *Subject:* Re: [Bioc-devel] Synching version numbers went wrong
>
> Hi Shana,
>
> It looks like the release version of KEGGlincs is 1.6.x and the devel
> version should be 1.7.x.When you're committing to the master branch of
> git.bioconductor.org this equates to the devel version and there's a
> check in place to prevent even version numbers being committed here.  My
> recommendation is to make sure that your DESCRIPTION file for that commit
> has a version number of 1.7.x which should put things back on track.
>
> If you also need to add your changes to the release version (I guess the
> current build error means you do) then you can see the instructions at
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> Step 4 details incorporating changes from one branch to another, and then
> you need to manually make sure the DESCRIPTION file for committing to the
> RELEASE_3_7 branch contains a 1.6.x version number.
>
> Mike
>
> On Wed, 11 Jul 2018 at 18:19, White, Shana (vandersm) <
> vande...@mail.uc.edu> wrote:
>
> Hello, when attempting to fix a bug [introduced into my package] and
> propagate the changes I somehow managed to roll back the middle version
> number on one of my branches and ended up with the following error message
> when attempting to correct my mistake:
>
>
>
> Error message:
>
>
> shanas-macbook:KEGGlincs shanabanana$ git push upstream master
>
> Counting objects: 3, done.
>
> Delta compression using up to 4 threads.
>
> Compressing objects: 100% (3/3), done.
>
> Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done.
>
> Total 3 (delta 2), reused 0 (delta 0)
>
> remote: Error: Illegal version bump from '1.5.1' to '1.6.1'. Check
>
> remote: http://bioconductor.org/developers/how-to/version-numbering/
>
> remote: for details
>
>
> Many thanks,
>
>
> Shana White
> Ph. D Candidate  - Biostatistics + Bioinformatics<
> https://med.uc.edu/eh/divisions/bio>
> Predoctoral Fellow - MECEH<
> https://med.uc.edu/eh/divisions/epi/programs/meceh>
> Room 318 Kettering Labs
> vande...@mail.uc.edu
> 937-657-8289
>
>
> [[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] Fixing bugs in release version

[Mike Smith]

Hi Jason,

There is no explicit connection between Github and git.bioconductor.org
(I'm going to call this git.bioc from now on)  Only changes that are pushed
to git.bioc will be reflected in the packages available via
www.bioconductor.org and biocLite().  You can make any changes you like to
a repo on Github and similarly create branches with any name you want, but
this is completely separate from Bioconductor.  Having a  RELEASE_X_Y
branch on Github and making a change there does not automatically mean it
gets sent to git.bioc.

Many people like to maintain a Github repository in addition to git.bioc as
it provides many useful features for social coding (comments, issues, text
search etc) but it's entirely possible to ignore Github completely after
your package has been accepted.

It sounds like you're interested in using both git.bioc and Github, in
which case the instructions at
https://bioconductor.org/developers/how-to/git/push-to-github-bioc/ might
help with keeping them in sync.

Mike

On Thu, 12 Jul 2018 at 11:53, Jason Serviss  wrote:

> Mike,
>
> It would appear that the version on Eugenia’s RELEASE_3_7 branch on her
> git repo is 1.3.1 (
> https://github.com/eugeniaeueu/Onassis/commit/def6111f80db3ed03a991416ce724425d2027d01)
> so why is it 1.2.1 on the Bioconductor repo?
>
> p.s. have recently been struggling with a similar issue so, just asking to
> try to get a better understanding
>
> Kind Regards,
> Jason
>
> > On 12 Jul 2018, at 11:12, Mike Smith  wrote:
> >
> > It looks to me like you have made the changes correctly.  When I checkout
> > your packages you have versions 1.3.1 and 1.2.1 for the master and
> > RELEASE_3_7 branches respectively.
> >
> > -> % git checkout --quiet master && cat DESCRIPTION | grep Version
> > Version: 1.3.1
> >
> > -> % git checkout --quiet RELEASE_3_7 && cat DESCRIPTION | grep Version
> > Version: 1.2.1
> >
> > The reason it still says 1.2.0 on the landing page is that there can be
> > delay before changes in the git repository propagate to the home pge.
> You
> > can check the last time a snapshot of your packages was taken on
> > http://bioconductor.org/checkResults/release/bioc-LATEST/Onassis/ For
> you
> > this was Snapshot Date: 2018-07-10 16:46:08 -0400 (Tue, 10 Jul 2018)
> which
> > is before your commit with the version bump.  It would expect the change
> to
> > propagate through sometime today.
> >
> > Mike
> >
> > On Thu, 12 Jul 2018 at 10:52, Eugenia Galeota  >
> > wrote:
> >
> >> Good morning,
> >> I'm writing because I tried to fix some bugs in the current release
> version
> >> of my package Onassis.
> >> I followed these instructions (
> >>
> >>
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> >> )
> >> but maybe I messed up with the version in the DESCRIPTION file. In the
> >> Bioconductor page RELEASE_3_7
> >> https://www.bioconductor.org/packages/3.7/bioc/html/Onassis.html
> Onassis
> >> has 1.2.0 version, while actually in the repository I don't know how I
> am
> >> at version 1.3.1 (shouldn't it be a development version?).
> >> Will my bug fixes be available in the RELEASE_3_7 to users installing
> the
> >> package?
> >>
> >> I thought that Onassis version after the bug fixes, should have been
> 1.2.1.
> >> Is that correct? How can I update just the current Onassis package in
> >> RELEASE_3_7 (the current one) ?
> >> Thanks Eugenia
> >>
> >> --
> >> Eugenia Galeota, PhD
> >> Center for Genomic Science of IIT@SEMM
> >> Computational Epigenomics
> >> Email: eugenia.gale...@iit.it
> >> Tel: +39 02 9437 5046
> >> Via Adamello 16, 20139 Milan, Italy
> >>
> >>[[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
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Fixing bugs in release version

[Mike Smith]

It looks to me like you have made the changes correctly.  When I checkout
your packages you have versions 1.3.1 and 1.2.1 for the master and
RELEASE_3_7 branches respectively.

-> % git checkout --quiet master && cat DESCRIPTION | grep Version
Version: 1.3.1

-> % git checkout --quiet RELEASE_3_7 && cat DESCRIPTION | grep Version
Version: 1.2.1

The reason it still says 1.2.0 on the landing page is that there can be
delay before changes in the git repository propagate to the home pge.  You
can check the last time a snapshot of your packages was taken on
http://bioconductor.org/checkResults/release/bioc-LATEST/Onassis/ For you
this was Snapshot Date: 2018-07-10 16:46:08 -0400 (Tue, 10 Jul 2018) which
is before your commit with the version bump.  It would expect the change to
propagate through sometime today.

Mike

On Thu, 12 Jul 2018 at 10:52, Eugenia Galeota 
wrote:

> Good morning,
> I'm writing because I tried to fix some bugs in the current release version
> of my package Onassis.
> I followed these instructions (
>
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> )
> but maybe I messed up with the version in the DESCRIPTION file. In the
> Bioconductor page RELEASE_3_7
> https://www.bioconductor.org/packages/3.7/bioc/html/Onassis.html Onassis
> has 1.2.0 version, while actually in the repository I don't know how I am
> at version 1.3.1 (shouldn't it be a development version?).
> Will my bug fixes be available in the RELEASE_3_7 to users installing the
> package?
>
> I thought that Onassis version after the bug fixes, should have been 1.2.1.
> Is that correct? How can I update just the current Onassis package in
> RELEASE_3_7 (the current one) ?
> Thanks Eugenia
>
> --
> Eugenia Galeota, PhD
> Center for Genomic Science of IIT@SEMM
> Computational Epigenomics
> Email: eugenia.gale...@iit.it
> Tel: +39 02 9437 5046
> Via Adamello 16, 20139 Milan, Italy
>
> [[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] Synching version numbers went wrong

[Mike Smith]

Hi Shana,

It looks like the release version of KEGGlincs is 1.6.x and the devel
version should be 1.7.x.When you're committing to the master branch of
git.bioconductor.org this equates to the devel version and there's a check
in place to prevent even version numbers being committed here.  My
recommendation is to make sure that your DESCRIPTION file for that commit
has a version number of 1.7.x which should put things back on track.

If you also need to add your changes to the release version (I guess the
current build error means you do) then you can see the instructions at
https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
Step 4 details incorporating changes from one branch to another, and then
you need to manually make sure the DESCRIPTION file for committing to the
RELEASE_3_7 branch contains a 1.6.x version number.

Mike

On Wed, 11 Jul 2018 at 18:19, White, Shana (vandersm) 
wrote:

> Hello, when attempting to fix a bug [introduced into my package] and
> propagate the changes I somehow managed to roll back the middle version
> number on one of my branches and ended up with the following error message
> when attempting to correct my mistake:
>
>
>
> Error message:
>
>
> shanas-macbook:KEGGlincs shanabanana$ git push upstream master
>
> Counting objects: 3, done.
>
> Delta compression using up to 4 threads.
>
> Compressing objects: 100% (3/3), done.
>
> Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done.
>
> Total 3 (delta 2), reused 0 (delta 0)
>
> remote: Error: Illegal version bump from '1.5.1' to '1.6.1'. Check
>
> remote: http://bioconductor.org/developers/how-to/version-numbering/
>
> remote: for details
>
>
> Many thanks,
>
>
> Shana White
> Ph. D Candidate  - Biostatistics + Bioinformatics<
> https://med.uc.edu/eh/divisions/bio>
> Predoctoral Fellow - MECEH<
> https://med.uc.edu/eh/divisions/epi/programs/meceh>
> Room 318 Kettering Labs
> vande...@mail.uc.edu
> 937-657-8289
>
>
> [[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] Windows, normalizePath(), and non-ASCII characters

[Mike Smith]

Hi Val,

I think I achieved some resolution, if not total clarity.  It's to do with
the encoding of the of the two path variables:

> Encoding(path1)
[1] "unknown"
> Encoding(path2)
[1] "UTF-8"

I don't understand why recursive calls to normalizePath() changes the
encoding, but the combination of HDF5 & Windows fails when given UTF-8
paths.  I've updated rhdf5 to try and ensure paths are encoded in Latin-1
which Windows is fine with, but it'll still go awry if you use characters
outside that set.  I'm still searching for a more comprehensive solution.

Thanks,
Mike

On Thu, 31 May 2018 at 20:09, Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> Hi Mike,
> Is this still an issue or has it been resolved?
> Val
>
>
> On 05/22/2018 02:19 PM, Mike Smith wrote:
>
> In trying to diagnose this issue athttps://support.bioconductor.org/p/108548/ 
> I've found some weird behaviour
> with Windows, normalizePath(), and non-ASCII characters.  Essentially, if I
> run normalizePath() recursively on a path that contains  'é' (I haven't
> tried other characters) something 'changes' in the string, but I can't work
> out what, and it breaks a subsequent .Call() which uses the path.
>
> The example below tries to demonstrate this in a fairly concise manner. It
> works fine if normalizePath() is run once, but fails after it's run a
> second time on itself.
>
> However, change "éxample" for "example" and both instances work. Similarly,
> both run fine on my Linux machine with the non-ASCII character inplace.
>
> I'd be grateful if anyone else with a Windows machine could verify this
> behaviour, or to shed any light on what might be the difference between path1
> and path2 below.
>
> Thank,
> Mike
>
> --
>
> ## setup some HDF5 components required later
> flags <- rhdf5:::h5checkConstants("H5F_ACC", h5default("H5F_ACC"))
> fcpl <- rhdf5:::h5checktypeAndPLC(NULL, "H5P_FILE_CREATE", allowNULL = TRUE)
> fapl <- rhdf5::H5Pcreate("H5P_FILE_ACCESS")
>
> ## create a folder with non-ASCII character
> dir.create('éxample')
> setwd("éxample")
>
> ## create two normalized paths recursively - these are 'identical'
> path1 <- normalizePath('test.h5', mustWork = FALSE)
> path2 <- normalizePath(path1, mustWork = FALSE)
> identical(path1, path2)
>
> ## create an HDF5 file using path1 - this works
> fid <- .Call("_H5Fcreate", path1, flags, fcpl@ID, fapl@ID,
>  PACKAGE = "rhdf5")
> .Call("_H5Fclose", fid, PACKAGE = "rhdf5")
> file.remove(path1)
>
> ## create an HDF5 file using path2 - this fails
> fid <- .Call("_H5Fcreate", path2, flags, fcpl@ID, fapl@ID,
>  PACKAGE = "rhdf5")
> if(exists('fid2')) {
>   .Call("_H5Fclose", fid2, PACKAGE = "rhdf5")
>   file.remove(path2)
> }
>
> ## tidy up
> rhdf5::h5closeAll()
> setwd("../")
>
>   [[alternative HTML version deleted]]
>
> ___bioc-de...@r-project.org 
> mailing listhttps://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.

[[alternative HTML version deleted]]

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

[Bioc-devel] Windows, normalizePath(), and non-ASCII characters

[Mike Smith]

In trying to diagnose this issue at
https://support.bioconductor.org/p/108548/ I've found some weird behaviour
with Windows, normalizePath(), and non-ASCII characters.  Essentially, if I
run normalizePath() recursively on a path that contains  'é' (I haven't
tried other characters) something 'changes' in the string, but I can't work
out what, and it breaks a subsequent .Call() which uses the path.

The example below tries to demonstrate this in a fairly concise manner. It
works fine if normalizePath() is run once, but fails after it's run a
second time on itself.

However, change "éxample" for "example" and both instances work. Similarly,
both run fine on my Linux machine with the non-ASCII character inplace.

I'd be grateful if anyone else with a Windows machine could verify this
behaviour, or to shed any light on what might be the difference between path1
and path2 below.

Thank,
Mike

--

## setup some HDF5 components required later
flags <- rhdf5:::h5checkConstants("H5F_ACC", h5default("H5F_ACC"))
fcpl <- rhdf5:::h5checktypeAndPLC(NULL, "H5P_FILE_CREATE", allowNULL = TRUE)
fapl <- rhdf5::H5Pcreate("H5P_FILE_ACCESS")

## create a folder with non-ASCII character
dir.create('éxample')
setwd("éxample")

## create two normalized paths recursively - these are 'identical'
path1 <- normalizePath('test.h5', mustWork = FALSE)
path2 <- normalizePath(path1, mustWork = FALSE)
identical(path1, path2)

## create an HDF5 file using path1 - this works
fid <- .Call("_H5Fcreate", path1, flags, fcpl@ID, fapl@ID,
 PACKAGE = "rhdf5")
.Call("_H5Fclose", fid, PACKAGE = "rhdf5")
file.remove(path1)

## create an HDF5 file using path2 - this fails
fid <- .Call("_H5Fcreate", path2, flags, fcpl@ID, fapl@ID,
 PACKAGE = "rhdf5")
if(exists('fid2')) {
  .Call("_H5Fclose", fid2, PACKAGE = "rhdf5")
  file.remove(path2)
}

## tidy up
rhdf5::h5closeAll()
setwd("../")

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BioC 2018 poster / talk / scholarship / workshop application deadline May 17

[Mike Smith]

Dear Pijush,

Once a package has been accepted to Bioconductor, a copy is made in
Bioconductor's own git repository and this is the source from which the
packages are made available to users.  Any change you make in Github won't
be automatically reflected there, you have to explicitly make the change in
git.bioconductor.org.

It sounds like you should take a look at
https://bioconductor.org/developers/how-to/git/new-package-workflow/ to
make sure you have access to the Bioconductor repository (maybe you've
already done this if you've added an SSH key) and then
https://bioconductor.org/developers/how-to/git/push-to-github-bioc/ which
describes how to make sure you commit changes both to your Github
repository and the version at Bioconductor.

Regards,

Mike

On 11 May 2018 at 05:48, Pijush Das  wrote:

> Dear Martin Morgan,
>
>
> I have successfully added the SSH key in github account and Bioconductor.
> After rechecking the package in Bioconductor I have found that there is a
> mistake
> in the DESCRIPTION file.
> In the Description portion inside the DESCRIPTION file, there are
> words " Bayesian
> T statistic",
> it is wrongly placed there. This should be only "t- statistic".
> I have change it in the github with a version bump.
>
> Is that change can be seen in Bioconductor automatically?
> Or I have to do anything else? Please let me know.
>
> Thank you
>
>
> regards
> Pijush
>
>
>
>
>
>
>
>
> On Wed, May 9, 2018 at 7:15 PM, Martin Morgan <
> martin.mor...@roswellpark.org
> > wrote:
>
> > The scholarships support up to $500 travel. The scholarship also covers
> > accommodation and registration.
> >
> > A letter inviting you to the conference will be sent separately.
> >
> > Martin
> >
> > On 05/09/2018 01:13 AM, Pijush Das wrote:
> >
> >> Dear Martin Morgan,
> >>
> >>
> >> Thank you Morgan for informing me to join your annual conference BioC
> >> 2018.
> >> I am very much interested to attend the BioC 2018 conference.
> >> Presently I am perusing my PhD from CSIR-Indian Institute of Chemical
> >> biology.
> >> So it is not possible to collect all the money to pay all the expenses
> >> myself.
> >>
> >>
> >> I would like to know if I am selected for the scholarship, they will pay
> >> for costs such as
> >> travel, accommodation, and registration ? Or they will pay only $500 per
> >> person?
> >>
> >>
> >> If it is possible please send me an invitation letter for the annual
> >> conference BioC 2018.
> >> The invitation letter will help me for grant application to the indian
> >> funding body such as DBT or CSIR etc.
> >>
> >>
> >>
> >>
> >>
> >> Thank you
> >>
> >>
> >>
> >> regards
> >> Pijush
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, May 7, 2018 at 2:59 AM, Martin Morgan <
> >> martin.mor...@roswellpark.org >
> >> wrote:
> >>
> >> Join us for our annual conference BioC 2018: Where Software and
> >> Biology Connect, at Victoria University on the University of Toronto
> >> campus
> >>
> >> http://bioc2018.bioconductor.org 
> >>
> >> The deadline for poster, talk, scholarship (travel, accommodation,
> >> and registration), and workshop applications is May 17, see
> >>
> >> http://bioc2018.bioconductor.org/call-for-abstracts
> >> 
> >> http://bioc2018.bioconductor.org/scholarships
> >> 
> >>
> >> Martin Morgan
> >> Bioconductor
> >>
> >>
> >> This email message may contain legally privileged
> >> and/or...{{dropped:2}}
> >>
> >> ___
> >> Bioc-devel@r-project.org  mailing
> >> list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >> 
> >>
> >>
> >>
> >
> > This email message may contain legally privileged and/or confidential
> > information.  If you are not the intended recipient(s), or the employee
> or
> > agent responsible for the delivery of this message to the intended
> > recipient(s), you are hereby notified that any disclosure, copying,
> > distribution, or use of this email message is prohibited.  If you have
> > received this message in error, please notify the sender immediately by
> > e-mail and delete this email message from your computer. Thank you.
> >
>
> [[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] biomaRt uswest mirror ERROR

[Mike Smith]

Hi Lori,

There should be no issue with switching to an alternative mirror with
regards to the content.

However, in the current release you will also need to set the argument
ensemblRedirect
= FALSE otherwise it'll end up at the uswest mirror regardless of the host
you specify.  This is not the case in the devel version, as I've disabled
the geo-redirect by default after talking to the people at Ensembl, and the
host argument is always obeyed.

Cheers,

Mike

On 24 April 2018 at 17:30, Shepherd, Lori 
wrote:

> Hello,
>
>
> OrganismDbi is failing.
>
> http://bioconductor.org/checkResults/3.7/bioc-LATEST/
> OrganismDbi/malbec2-checksrc.html
>
>
> It appears that this link is not available for the uswest mirror:
> http://uswest.ensembl.org:80/biomart/martservice?type=
> registry=biomaRt
>
>
> when specifying the host = "uswest.ensembl.org"
>
>
> Is there any consequence to changing this to the us east mirror instead of
> west as that one appears to be up?
>
> It has been a week since this weblink has been unavailable and wasn't sure
> what the time frame of having it back up was.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Subsetting Multiple platform build/check report

[Mike Smith]

I do something similar and have a local 'dashboard' page populated with the
build status shields pulled from the package landing pages e.g.
http://bioconductor.org/shields/build/devel/bioc/biomaRt.svg Then I can
glance at that to see if anything isn't green.

Mike

On 20 April 2018 at 10:06, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> Steffen, my hackish solution is to have links on my homepage to all the
> build pages I am interested in (www.hansenlab.org/software).
>
> Best,
> Kasper
>
> On Thu, Apr 19, 2018 at 3:33 PM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:
>
> > It's not obvious or easy to test, and not meant cynically, but pull
> > requests welcome
> >
> >   https://github.com/Bioconductor/BBS/blob/master/3.8/report.js
> >
> > and FWIW there is the single package version
> >
> >   https://bioconductor.org/checkResults/devel/bioc-LATEST/mzR
> >
> > Martin
> >
> > On 04/19/2018 08:53 AM, Neumann, Steffen wrote:
> >
> >> Hi,
> >>
> >> we currently can easily check for broken packages using:
> >> http://bioconductor.org/checkResults/devel/bioc-LATEST/
> >> index.html#show=timeout,error
> >>
> >> It would be great to also subset the packages:
> >> http://bioconductor.org/checkResults/devel/bioc-LATEST/
> >> index.html#package=mzR,MSnbase,xcms,CAMERA
> >>
> >> to easily show the status of packages I am interested in.
> >>
> >> Yours,
> >> Steffen
> >>
> >>
> >
> > This email message may contain legally privileged and/or...{{dropped:2}}
> >
> >
> > ___
> > 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
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] [Bioconductor/Contributions] GIGSEA (#720)

[Mike Smith]

You had the right idea with your commit
https://github.com/zhushijia/GIGSEA/commit/431af209590f905452b5f10b0ad3a282ab2534e3
but the wrong version of R.  You need to put  Depends: R (>= 3.5) in your
DESCRIPTION file and it should be good.

Mike

On 17 April 2018 at 10:49, Shijia Zhu  wrote:

> Hi Everyone,
>
>   I submitted my package to Bioconductor, but always meet with the
> following warning:
>
>
> ** Checking R Version dependency...* WARNING: Update R version
> dependency from 2.15 to 3.5.*
>
> Does anyone know how to fix the warning?
>
> Any help will be appreciated very much.
>
> Best
> Shijia
>
>
>
>
> On Tue, Apr 17, 2018 at 4:18 AM, bioc-issue-bot 
> wrote:
>
> > Dear Package contributor,
> >
> > This is the automated single package builder at bioconductor.org.
> >
> > Your package has been built on Linux, Mac, and Windows.
> >
> > On one or more platforms, the build results were: "WARNINGS".
> > This may mean there is a problem with the package that you need to fix.
> > Or it may mean that there is a problem with the build system itself.
> >
> > Please see the build report
> >  20180417041834.html>
> > for more details.
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> >  381894378>,
> > or mute the thread
> >  AFKtsVCF2VeX6vhwJ5S3toxysjFC10VDks5tpaVfgaJpZM4TPAoV>
> > .
> >
>
> [[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] Windows

[Mike Smith]

Martin mentioned that he changed the wording in
https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e
, so more recently than your version of R-devel.

Mike

On 16 April 2018 at 11:57, Rainer Johannes <johannes.rai...@eurac.edu>
wrote:

> Thanks Mike,
>
> I somehow missed the discussion you mentioned. I would really not like to
> include the name of the Rd file I want to link to. The *default* way that
> works on Linux and macOS should also work on Windows - otherwise what's the
> matter of the alias? Interestingly, on my Windows test machine (Windows 7)
> I don't get these warnings (R-devel from 2018-01-07 r74091).
>
> jo
>
> > On 16 Apr 2018, at 10:49, Mike Smith <grimbo...@gmail.com> wrote:
> >
> > Hi Johannes,
> >
> > xcms is certainly not alone with the warning, and it was discussed in
> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html
> >
> > I think you should be able to get round it by including the name of Rd
> file you're linking to e.g.  \code{\link[MSnbase:pickpeaks-method]{pickPeaks}}
> (I haven't actually tested this though).
> >
> > Mike
> >
> > On 16 April 2018 at 09:06, Rainer Johannes <johannes.rai...@eurac.edu>
> wrote:
> > Dear all,
> >
> > we're experiencing WARNINGS in xcms on Tokay2 that are all related to
> links in Rd files to functions and methods in other packages.
> > Example:
> > we have \code{\link[MSnbase]{pickPeaks}} in
> XCMSnExp-inherited-methods.Rd that links to the method in MSnbase, that
> works nicely on Linux and macOS build machines, but on tokay2 we get:
> >
> >   Rd warning: C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmpw7qeJw/R.
> INSTALL1e704df56ca9/xcms/man/XCMSnExp-inherited-methods.Rd:59: file link
> 'pickPeaks' in package 'MSnbase' does not exist and so has been treated as
> a topic
> >
> > is there any other solution to removing all links to external packages?
> >
> > thanks, jo
> >
> > ___
> > 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] Windows

[Mike Smith]

Hi Johannes,

xcms is certainly not alone with the warning, and it was discussed in
https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html

I think you should be able to get round it by including the name of Rd file
you're linking to e.g.  \code{\link[MSnbase:pickpeaks-method]{pickPeaks}}
(I haven't actually tested this though).

Mike

On 16 April 2018 at 09:06, Rainer Johannes 
wrote:

> Dear all,
>
> we're experiencing WARNINGS in xcms on Tokay2 that are all related to
> links in Rd files to functions and methods in other packages.
> Example:
> we have \code{\link[MSnbase]{pickPeaks}} in XCMSnExp-inherited-methods.Rd
> that links to the method in MSnbase, that works nicely on Linux and macOS
> build machines, but on tokay2 we get:
>
>   Rd warning: C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmpw7qeJw/R.
> INSTALL1e704df56ca9/xcms/man/XCMSnExp-inherited-methods.Rd:59: file link
> 'pickPeaks' in package 'MSnbase' does not exist and so has been treated as
> a topic
>
> is there any other solution to removing all links to external packages?
>
> thanks, jo
>
> ___
> 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