Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
Hi, recount has built well on the last 2 builds (Aug 14 and 11th) on Linux and I see that now https://bioconductor.org/packages/devel/bioc/html/recount.html is up. My guess is that the directory that Dan removed fixed things in time for the Aug 11th build. Thanks again! Best, Leo On Fri, Aug 12, 2016 at 7:31 PM, Martin Morgan <martin.mor...@roswellpark.org> wrote: > On 08/12/2016 07:49 PM, Dan Tenenbaum wrote: >> >> >> >> - Original Message - >>> >>> From: "Martin Morgan" <martin.mor...@roswellpark.org> >>> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "lcollado" >>> <lcoll...@jhu.edu> >>> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" >>> <bioc-devel@r-project.org>, "Andrew Jaffe" <andreweja...@gmail.com>, >>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> >>> Sent: Friday, August 12, 2016 4:43:59 PM >>> Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it >>> using rtracklayer >= 1.33.11? >> >> >>> On 08/12/2016 03:27 PM, Dan Tenenbaum wrote: >>>> >>>> Well, I wrote my email to you on August 9th and the latest build report >>>> is from >>>> Aug 10 and we see the same error as before. >>>> >>>> I just manually went to zin1 and was able to remove /tmp/udcCache >>>> without having >>>> to be a superuser, I could do it as the user that the build system runs >>>> as >>>> (biocbuild). >>>> >>>> I then rebuilt the recount package (successfully, btw) and it created >>>> the >>>> /tmp/udcCache directory again (but again it was removable without >>>> superuser >>>> powers). >>>> >>>> So I am not sure what is going on. Hopefully the next build will not >>>> have this >>>> error. Maybe when I touched it last time the build was already in >>>> progress and >>>> what I did came too late to affect the build. >>>> >>>> Anyway it would be good to know which package is creating that >>>> /tmp/udcCache >>>> directory. Ideally that package would instead use tmpdir() and then the >>>> directory would be removed when recount is done building, and this issue >>>> would >>>> never come up again. >>>> >>> >>> Only rtracklayer references this. it might not be such a good idea to >>> use tempdir(), because then the cache wouldn't be available for use >>> during the builds... in what sense was it a permissions issue? >>> >> >> >> >> >> When I initially went onto zin1 and installed and then stangled and >> sourced the vignette I saw some sort of permissions error with this >> directory. Unfortunately I did not save the exact error message. >> >> When I initially tried >> >> rm -rf /tmp/udcCache >> >> ...as the biocbuild user I got a permission denied error. >> >> I should have investigated further to see which file(s) could not be >> deleted by biocbuild and what their permissions/ownership were but instead I >> just removed the entire directory as superuser. >> >> So there was a permissions issue which caused the problem Leonardo >> reported. > > > I'll ask Michael about a Sys.info()[["user"]]-specific cache. > > >> >> >> Dan >> >> >>> Martin >>> >>>> Dan >>>> >>>> >>>> - Original Message - >>>>> >>>>> From: "lcollado" <lcoll...@jhu.edu> >>>>> To: "Dan Tenenbaum" <dtene...@fredhutch.org> >>>>> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" >>>>> <bioc-devel@r-project.org>, >>>>> "Andrew Jaffe" <andreweja...@gmail.com>, >>>>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" >>>>> <anell...@gmail.com> >>>>> Sent: Friday, August 12, 2016 10:44:20 AM >>>>> Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it >>>>> using >>>>> rtracklayer >= 1.33.11? >>>> >>>> >>>>> Thanks Dan for finding the /tmp/udcCache error and fixing it! I assume >>>>> that recount will build properly next time. >>&
Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
On 08/12/2016 07:49 PM, Dan Tenenbaum wrote: - Original Message - From: "Martin Morgan" <martin.mor...@roswellpark.org> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "lcollado" <lcoll...@jhu.edu> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, "Andrew Jaffe" <andreweja...@gmail.com>, "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> Sent: Friday, August 12, 2016 4:43:59 PM Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11? On 08/12/2016 03:27 PM, Dan Tenenbaum wrote: Well, I wrote my email to you on August 9th and the latest build report is from Aug 10 and we see the same error as before. I just manually went to zin1 and was able to remove /tmp/udcCache without having to be a superuser, I could do it as the user that the build system runs as (biocbuild). I then rebuilt the recount package (successfully, btw) and it created the /tmp/udcCache directory again (but again it was removable without superuser powers). So I am not sure what is going on. Hopefully the next build will not have this error. Maybe when I touched it last time the build was already in progress and what I did came too late to affect the build. Anyway it would be good to know which package is creating that /tmp/udcCache directory. Ideally that package would instead use tmpdir() and then the directory would be removed when recount is done building, and this issue would never come up again. Only rtracklayer references this. it might not be such a good idea to use tempdir(), because then the cache wouldn't be available for use during the builds... in what sense was it a permissions issue? When I initially went onto zin1 and installed and then stangled and sourced the vignette I saw some sort of permissions error with this directory. Unfortunately I did not save the exact error message. When I initially tried rm -rf /tmp/udcCache ...as the biocbuild user I got a permission denied error. I should have investigated further to see which file(s) could not be deleted by biocbuild and what their permissions/ownership were but instead I just removed the entire directory as superuser. So there was a permissions issue which caused the problem Leonardo reported. I'll ask Michael about a Sys.info()[["user"]]-specific cache. Dan Martin Dan - Original Message - From: "lcollado" <lcoll...@jhu.edu> To: "Dan Tenenbaum" <dtene...@fredhutch.org> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, "Andrew Jaffe" <andreweja...@gmail.com>, "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> Sent: Friday, August 12, 2016 10:44:20 AM Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11? Thanks Dan for finding the /tmp/udcCache error and fixing it! I assume that recount will build properly next time. The error related to SRP009615-results.Rmd is likely related to https://github.com/leekgroup/recount/blob/master/vignettes/Makefile. I'm using that Makefile trick to include the HTML output of a regionReport::DESeq2Report() created via https://github.com/leekgroup/recount/blame/master/vignettes/recount-quickstart.Rmd#L343-L359 which re-writes SRP009615-results.Rmd. regionReport::DESeq2Report() specifies the `software` variable which is then used when rendering the Rmd file. Given that it works well on the OS build machine, I suspect it'll work well now with Linux thanks to the /tmp/udcCache issue you resolved. If you use R CMD build from a clean `recount` dir, it should all work. Best, Leo On Tue, Aug 9, 2016 at 2:30 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote: Actually it looks like it was a permissions issue with the directory /tmp/udcCache. I removed this directory (as superuser) and that error no longer happens. Now I get a different error which seems unrelated: ... * creating vignettes ... ERROR Quitting from lines 2-32 (SRP009615-results.Rmd) Error: processing vignette 'SRP009615-results.Rmd' failed with diagnostics: object 'software' not found Execution halted Probably because of line 20: Basic `r software` results exploration `r software` is interpreted as a chunk of code to be executed by R. Dan - Original Message - From: "Dan Tenenbaum" <dtene...@fredhutch.org> To: "lcollado" <lcoll...@jhu.edu> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, "Andrew Jaffe" <andreweja...@gmail.com>, "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> Sent: Tuesday, Augu
Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
- Original Message - > From: "Martin Morgan" <martin.mor...@roswellpark.org> > To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "lcollado" <lcoll...@jhu.edu> > Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, > "Andrew Jaffe" <andreweja...@gmail.com>, > "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> > Sent: Friday, August 12, 2016 4:43:59 PM > Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it using > rtracklayer >= 1.33.11? > On 08/12/2016 03:27 PM, Dan Tenenbaum wrote: >> Well, I wrote my email to you on August 9th and the latest build report is >> from >> Aug 10 and we see the same error as before. >> >> I just manually went to zin1 and was able to remove /tmp/udcCache without >> having >> to be a superuser, I could do it as the user that the build system runs as >> (biocbuild). >> >> I then rebuilt the recount package (successfully, btw) and it created the >> /tmp/udcCache directory again (but again it was removable without superuser >> powers). >> >> So I am not sure what is going on. Hopefully the next build will not have >> this >> error. Maybe when I touched it last time the build was already in progress >> and >> what I did came too late to affect the build. >> >> Anyway it would be good to know which package is creating that /tmp/udcCache >> directory. Ideally that package would instead use tmpdir() and then the >> directory would be removed when recount is done building, and this issue >> would >> never come up again. >> > > Only rtracklayer references this. it might not be such a good idea to > use tempdir(), because then the cache wouldn't be available for use > during the builds... in what sense was it a permissions issue? > When I initially went onto zin1 and installed and then stangled and sourced the vignette I saw some sort of permissions error with this directory. Unfortunately I did not save the exact error message. When I initially tried rm -rf /tmp/udcCache ...as the biocbuild user I got a permission denied error. I should have investigated further to see which file(s) could not be deleted by biocbuild and what their permissions/ownership were but instead I just removed the entire directory as superuser. So there was a permissions issue which caused the problem Leonardo reported. Dan > Martin > >> Dan >> >> >> - Original Message - >>> From: "lcollado" <lcoll...@jhu.edu> >>> To: "Dan Tenenbaum" <dtene...@fredhutch.org> >>> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, >>> "Andrew Jaffe" <andreweja...@gmail.com>, >>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> >>> Sent: Friday, August 12, 2016 10:44:20 AM >>> Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it >>> using >>> rtracklayer >= 1.33.11? >> >>> Thanks Dan for finding the /tmp/udcCache error and fixing it! I assume >>> that recount will build properly next time. >>> >>> >>> The error related to SRP009615-results.Rmd is likely related to >>> https://github.com/leekgroup/recount/blob/master/vignettes/Makefile. >>> I'm using that Makefile trick to include the HTML output of a >>> regionReport::DESeq2Report() created via >>> https://github.com/leekgroup/recount/blame/master/vignettes/recount-quickstart.Rmd#L343-L359 >>> which re-writes SRP009615-results.Rmd. regionReport::DESeq2Report() >>> specifies the `software` variable which is then used when rendering >>> the Rmd file. Given that it works well on the OS build machine, I >>> suspect it'll work well now with Linux thanks to the /tmp/udcCache >>> issue you resolved. If you use R CMD build from a clean `recount` dir, >>> it should all work. >>> >>> Best, >>> Leo >>> >>> On Tue, Aug 9, 2016 at 2:30 PM, Dan Tenenbaum <dtene...@fredhutch.org> >>> wrote: >>>> Actually it looks like it was a permissions issue with the directory >>>> /tmp/udcCache. I removed this directory (as superuser) and that error no >>>> longer >>>> happens. >>>> >>>> Now I get a different error which seems unrelated: >>>> >>>> ... >>>> * creating vignettes ...
Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
On 08/12/2016 03:27 PM, Dan Tenenbaum wrote:
Well, I wrote my email to you on August 9th and the latest build report is from
Aug 10 and we see the same error as before.
I just manually went to zin1 and was able to remove /tmp/udcCache without
having to be a superuser, I could do it as the user that the build system runs
as (biocbuild).
I then rebuilt the recount package (successfully, btw) and it created the
/tmp/udcCache directory again (but again it was removable without superuser
powers).
So I am not sure what is going on. Hopefully the next build will not have this
error. Maybe when I touched it last time the build was already in progress and
what I did came too late to affect the build.
Anyway it would be good to know which package is creating that /tmp/udcCache
directory. Ideally that package would instead use tmpdir() and then the
directory would be removed when recount is done building, and this issue would
never come up again.
Only rtracklayer references this. it might not be such a good idea to
use tempdir(), because then the cache wouldn't be available for use
during the builds... in what sense was it a permissions issue?
Martin
Dan
- Original Message -
From: "lcollado" <lcoll...@jhu.edu>
To: "Dan Tenenbaum" <dtene...@fredhutch.org>
Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, "Andrew
Jaffe" <andreweja...@gmail.com>,
"Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com>
Sent: Friday, August 12, 2016 10:44:20 AM
Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it using
rtracklayer >= 1.33.11?
Thanks Dan for finding the /tmp/udcCache error and fixing it! I assume
that recount will build properly next time.
The error related to SRP009615-results.Rmd is likely related to
https://github.com/leekgroup/recount/blob/master/vignettes/Makefile.
I'm using that Makefile trick to include the HTML output of a
regionReport::DESeq2Report() created via
https://github.com/leekgroup/recount/blame/master/vignettes/recount-quickstart.Rmd#L343-L359
which re-writes SRP009615-results.Rmd. regionReport::DESeq2Report()
specifies the `software` variable which is then used when rendering
the Rmd file. Given that it works well on the OS build machine, I
suspect it'll work well now with Linux thanks to the /tmp/udcCache
issue you resolved. If you use R CMD build from a clean `recount` dir,
it should all work.
Best,
Leo
On Tue, Aug 9, 2016 at 2:30 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote:
Actually it looks like it was a permissions issue with the directory
/tmp/udcCache. I removed this directory (as superuser) and that error no longer
happens.
Now I get a different error which seems unrelated:
...
* creating vignettes ... ERROR
Quitting from lines 2-32 (SRP009615-results.Rmd)
Error: processing vignette 'SRP009615-results.Rmd' failed with diagnostics:
object 'software' not found
Execution halted
Probably because of line 20:
Basic `r software` results exploration
`r software` is interpreted as a chunk of code to be executed by R.
Dan
- Original Message -
From: "Dan Tenenbaum" <dtene...@fredhutch.org>
To: "lcollado" <lcoll...@jhu.edu>
Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>,
"Andrew Jaffe" <andreweja...@gmail.com>,
"Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com>
Sent: Tuesday, August 9, 2016 11:46:32 AM
Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it using
rtracklayer >= 1.33.11?
1.33.11 is the latest version in svn.
https://www.bioconductor.org/checkResults/3.4/bioc-LATEST/zin1-R-instpkgs.html
will tell you (with a reasonable degree of accuracy) which version of which
package is installed on zin1, it reports that it has version 1.33.11 installed.
The issue with recount looks like it's a (hopefully transient) UCSC connection
problem.
Dan
- Original Message -
From: "lcollado" <lcoll...@jhu.edu>
To: "bioc-devel" <bioc-devel@r-project.org>
Cc: "Jeff Leek" <jtl...@gmail.com>, "Andrew Jaffe" <andreweja...@gmail.com>,
"Ben Langmead" <lang...@cs.jhu.edu>, "Abhi
Nellore" <anell...@gmail.com>
Sent: Tuesday, August 9, 2016 11:33:50 AM
Subject: [Bioc-devel] Debugging build error on Linux machine: is it using
rtracklayer >= 1.33.11?
Hi,
Currently the build for `recount` is failing in the Linux build
machine
http://www.bioconductor.org/checkResults/3.4/bioc-LATEST/recount/zin1-buildsrc.html.
It's been failing with the same error message for a while. The build
message ends with:
Setting options('download.file.method.GEOquery'='auto')
Setting options('GEOquer
Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
Well, I wrote my email to you on August 9th and the latest build report is from Aug 10 and we see the same error as before. I just manually went to zin1 and was able to remove /tmp/udcCache without having to be a superuser, I could do it as the user that the build system runs as (biocbuild). I then rebuilt the recount package (successfully, btw) and it created the /tmp/udcCache directory again (but again it was removable without superuser powers). So I am not sure what is going on. Hopefully the next build will not have this error. Maybe when I touched it last time the build was already in progress and what I did came too late to affect the build. Anyway it would be good to know which package is creating that /tmp/udcCache directory. Ideally that package would instead use tmpdir() and then the directory would be removed when recount is done building, and this issue would never come up again. Dan - Original Message - > From: "lcollado" <lcoll...@jhu.edu> > To: "Dan Tenenbaum" <dtene...@fredhutch.org> > Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, > "Andrew Jaffe" <andreweja...@gmail.com>, > "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> > Sent: Friday, August 12, 2016 10:44:20 AM > Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it using > rtracklayer >= 1.33.11? > Thanks Dan for finding the /tmp/udcCache error and fixing it! I assume > that recount will build properly next time. > > > The error related to SRP009615-results.Rmd is likely related to > https://github.com/leekgroup/recount/blob/master/vignettes/Makefile. > I'm using that Makefile trick to include the HTML output of a > regionReport::DESeq2Report() created via > https://github.com/leekgroup/recount/blame/master/vignettes/recount-quickstart.Rmd#L343-L359 > which re-writes SRP009615-results.Rmd. regionReport::DESeq2Report() > specifies the `software` variable which is then used when rendering > the Rmd file. Given that it works well on the OS build machine, I > suspect it'll work well now with Linux thanks to the /tmp/udcCache > issue you resolved. If you use R CMD build from a clean `recount` dir, > it should all work. > > Best, > Leo > > On Tue, Aug 9, 2016 at 2:30 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote: >> Actually it looks like it was a permissions issue with the directory >> /tmp/udcCache. I removed this directory (as superuser) and that error no >> longer >> happens. >> >> Now I get a different error which seems unrelated: >> >> ... >> * creating vignettes ... ERROR >> Quitting from lines 2-32 (SRP009615-results.Rmd) >> Error: processing vignette 'SRP009615-results.Rmd' failed with diagnostics: >> object 'software' not found >> Execution halted >> >> >> Probably because of line 20: >> >> Basic `r software` results exploration >> >> `r software` is interpreted as a chunk of code to be executed by R. >> >> >> Dan >> >> >> - Original Message - >>> From: "Dan Tenenbaum" <dtene...@fredhutch.org> >>> To: "lcollado" <lcoll...@jhu.edu> >>> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>, >>> "Andrew Jaffe" <andreweja...@gmail.com>, >>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com> >>> Sent: Tuesday, August 9, 2016 11:46:32 AM >>> Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it >>> using >>> rtracklayer >= 1.33.11? >> >>> 1.33.11 is the latest version in svn. >>> >>> https://www.bioconductor.org/checkResults/3.4/bioc-LATEST/zin1-R-instpkgs.html >>> will tell you (with a reasonable degree of accuracy) which version of which >>> package is installed on zin1, it reports that it has version 1.33.11 >>> installed. >>> >>> The issue with recount looks like it's a (hopefully transient) UCSC >>> connection >>> problem. >>> >>> Dan >>> >>> >>> - Original Message - >>>> From: "lcollado" <lcoll...@jhu.edu> >>>> To: "bioc-devel" <bioc-devel@r-project.org> >>>> Cc: "Jeff Leek" <jtl...@gmail.com>, "Andrew Jaffe" >>>> <andreweja...@gmail.com>, >>>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi >>>> Nellor
Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
Thanks Dan for finding the /tmp/udcCache error and fixing it! I assume
that recount will build properly next time.
The error related to SRP009615-results.Rmd is likely related to
https://github.com/leekgroup/recount/blob/master/vignettes/Makefile.
I'm using that Makefile trick to include the HTML output of a
regionReport::DESeq2Report() created via
https://github.com/leekgroup/recount/blame/master/vignettes/recount-quickstart.Rmd#L343-L359
which re-writes SRP009615-results.Rmd. regionReport::DESeq2Report()
specifies the `software` variable which is then used when rendering
the Rmd file. Given that it works well on the OS build machine, I
suspect it'll work well now with Linux thanks to the /tmp/udcCache
issue you resolved. If you use R CMD build from a clean `recount` dir,
it should all work.
Best,
Leo
On Tue, Aug 9, 2016 at 2:30 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote:
> Actually it looks like it was a permissions issue with the directory
> /tmp/udcCache. I removed this directory (as superuser) and that error no
> longer happens.
>
> Now I get a different error which seems unrelated:
>
> ...
> * creating vignettes ... ERROR
> Quitting from lines 2-32 (SRP009615-results.Rmd)
> Error: processing vignette 'SRP009615-results.Rmd' failed with diagnostics:
> object 'software' not found
> Execution halted
>
>
> Probably because of line 20:
>
> Basic `r software` results exploration
>
> `r software` is interpreted as a chunk of code to be executed by R.
>
>
> Dan
>
>
> - Original Message -
>> From: "Dan Tenenbaum" <dtene...@fredhutch.org>
>> To: "lcollado" <lcoll...@jhu.edu>
>> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>,
>> "Andrew Jaffe" <andreweja...@gmail.com>,
>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com>
>> Sent: Tuesday, August 9, 2016 11:46:32 AM
>> Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it
>> using rtracklayer >= 1.33.11?
>
>> 1.33.11 is the latest version in svn.
>>
>> https://www.bioconductor.org/checkResults/3.4/bioc-LATEST/zin1-R-instpkgs.html
>> will tell you (with a reasonable degree of accuracy) which version of which
>> package is installed on zin1, it reports that it has version 1.33.11
>> installed.
>>
>> The issue with recount looks like it's a (hopefully transient) UCSC
>> connection
>> problem.
>>
>> Dan
>>
>>
>> ----- Original Message -
>>> From: "lcollado" <lcoll...@jhu.edu>
>>> To: "bioc-devel" <bioc-devel@r-project.org>
>>> Cc: "Jeff Leek" <jtl...@gmail.com>, "Andrew Jaffe" <andreweja...@gmail.com>,
>>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi
>>> Nellore" <anell...@gmail.com>
>>> Sent: Tuesday, August 9, 2016 11:33:50 AM
>>> Subject: [Bioc-devel] Debugging build error on Linux machine: is it using
>>> rtracklayer >= 1.33.11?
>>
>>> Hi,
>>>
>>> Currently the build for `recount` is failing in the Linux build
>>> machine
>>> http://www.bioconductor.org/checkResults/3.4/bioc-LATEST/recount/zin1-buildsrc.html.
>>> It's been failing with the same error message for a while. The build
>>> message ends with:
>>>
>>> Setting options('download.file.method.GEOquery'='auto')
>>> Setting options('GEOquery.inmemory.gpl'=FALSE)
>>> trying URL 'http://duffel.rail.bio/recount/SRP009615/rse_gene.Rdata'
>>> Content type 'application/octet-stream' length 1383643 bytes (1.3 MB)
>>> ==
>>> downloaded 1.3 MB
>>>
>>> Quitting from lines 400-406 (recount-quickstart.Rmd)
>>> Error: processing vignette 'recount-quickstart.Rmd' failed with diagnostics:
>>> UCSC library operation failed
>>> Execution halted
>>>
>>>
>>> The lines of code from the recount vignette this refers to are:
>>>
>>> ## Define expressed regions for study SRP009615, only for chromosome Y
>>> regions <- expressed_regions('SRP009615', 'chrY', cutoff = 5L,
>>>maxClusterGap = 3000L)
>>>
>>> ## Briefly explore the resulting regions
>>> regions
>>>
>>>
>>>
>>> The UCSC error is something I've seen in previous versions of
>>> rtracklayer, which have been addressed in rtracklayer 1.33.11. recount
>>> version 0.99.25 (which is the one from the buil
Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
Actually it looks like it was a permissions issue with the directory
/tmp/udcCache. I removed this directory (as superuser) and that error no longer
happens.
Now I get a different error which seems unrelated:
...
* creating vignettes ... ERROR
Quitting from lines 2-32 (SRP009615-results.Rmd)
Error: processing vignette 'SRP009615-results.Rmd' failed with diagnostics:
object 'software' not found
Execution halted
Probably because of line 20:
Basic `r software` results exploration
`r software` is interpreted as a chunk of code to be executed by R.
Dan
- Original Message -
> From: "Dan Tenenbaum" <dtene...@fredhutch.org>
> To: "lcollado" <lcoll...@jhu.edu>
> Cc: "Jeff Leek" <jtl...@gmail.com>, "bioc-devel" <bioc-devel@r-project.org>,
> "Andrew Jaffe" <andreweja...@gmail.com>,
> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi Nellore" <anell...@gmail.com>
> Sent: Tuesday, August 9, 2016 11:46:32 AM
> Subject: Re: [Bioc-devel] Debugging build error on Linux machine: is it using
> rtracklayer >= 1.33.11?
> 1.33.11 is the latest version in svn.
>
> https://www.bioconductor.org/checkResults/3.4/bioc-LATEST/zin1-R-instpkgs.html
> will tell you (with a reasonable degree of accuracy) which version of which
> package is installed on zin1, it reports that it has version 1.33.11
> installed.
>
> The issue with recount looks like it's a (hopefully transient) UCSC connection
> problem.
>
> Dan
>
>
> - Original Message -
>> From: "lcollado" <lcoll...@jhu.edu>
>> To: "bioc-devel" <bioc-devel@r-project.org>
>> Cc: "Jeff Leek" <jtl...@gmail.com>, "Andrew Jaffe" <andreweja...@gmail.com>,
>> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi
>> Nellore" <anell...@gmail.com>
>> Sent: Tuesday, August 9, 2016 11:33:50 AM
>> Subject: [Bioc-devel] Debugging build error on Linux machine: is it using
>> rtracklayer >= 1.33.11?
>
>> Hi,
>>
>> Currently the build for `recount` is failing in the Linux build
>> machine
>> http://www.bioconductor.org/checkResults/3.4/bioc-LATEST/recount/zin1-buildsrc.html.
>> It's been failing with the same error message for a while. The build
>> message ends with:
>>
>> Setting options('download.file.method.GEOquery'='auto')
>> Setting options('GEOquery.inmemory.gpl'=FALSE)
>> trying URL 'http://duffel.rail.bio/recount/SRP009615/rse_gene.Rdata'
>> Content type 'application/octet-stream' length 1383643 bytes (1.3 MB)
>> ==
>> downloaded 1.3 MB
>>
>> Quitting from lines 400-406 (recount-quickstart.Rmd)
>> Error: processing vignette 'recount-quickstart.Rmd' failed with diagnostics:
>> UCSC library operation failed
>> Execution halted
>>
>>
>> The lines of code from the recount vignette this refers to are:
>>
>> ## Define expressed regions for study SRP009615, only for chromosome Y
>> regions <- expressed_regions('SRP009615', 'chrY', cutoff = 5L,
>>maxClusterGap = 3000L)
>>
>> ## Briefly explore the resulting regions
>> regions
>>
>>
>>
>> The UCSC error is something I've seen in previous versions of
>> rtracklayer, which have been addressed in rtracklayer 1.33.11. recount
>> version 0.99.25 (which is the one from the build report) had under
>> suggests rtracklayer (>= 1.33.11). I thought that this would mean that
>> the build would fail if rtracklayer below version 1.33.11 was being
>> used. I'm no longer sure, which is why in recount version 0.99.27 I
>> moved rtracklayer to imports to test this. The latest build report
>> shows that rtracklayer 1.33.11 did build correctly in the Linux
>> machine.
>>
>>
>> Everything seems to be working fine in my local tests and in R Travis
>> https://travis-ci.org/leekgroup/recount/builds/150995800. Below is
>> some code showing that everything is working as expected in my local
>> Linux test. So I'm a tad confused and can't reproduce this issue when
>> using rtracklayer version 1.33.11. Which is why I'm guessing that
>> somehow the Linux build machine is not using rtracklayer >= 1.33.11.
>>
>>
>>
>>
>> ## The url redirects as expected to the correct url
>>> rtracklayer:::expandURL('http://duffel.rail.bio/recount/SRP009615/rse_gene.Rdata')
>> [1] "http://idies.jhu.edu/recount/data/SRP009615/rse_gene.Rdata;
>>> library('recount')
>> Loading required package: SummarizedExperiment
>> Lo
Re: [Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
1.33.11 is the latest version in svn.
https://www.bioconductor.org/checkResults/3.4/bioc-LATEST/zin1-R-instpkgs.html
will tell you (with a reasonable degree of accuracy) which version of which
package is installed on zin1, it reports that it has version 1.33.11 installed.
The issue with recount looks like it's a (hopefully transient) UCSC connection
problem.
Dan
- Original Message -
> From: "lcollado" <lcoll...@jhu.edu>
> To: "bioc-devel" <bioc-devel@r-project.org>
> Cc: "Jeff Leek" <jtl...@gmail.com>, "Andrew Jaffe" <andreweja...@gmail.com>,
> "Ben Langmead" <lang...@cs.jhu.edu>, "Abhi
> Nellore" <anell...@gmail.com>
> Sent: Tuesday, August 9, 2016 11:33:50 AM
> Subject: [Bioc-devel] Debugging build error on Linux machine: is it using
> rtracklayer >= 1.33.11?
> Hi,
>
> Currently the build for `recount` is failing in the Linux build
> machine
> http://www.bioconductor.org/checkResults/3.4/bioc-LATEST/recount/zin1-buildsrc.html.
> It's been failing with the same error message for a while. The build
> message ends with:
>
> Setting options('download.file.method.GEOquery'='auto')
> Setting options('GEOquery.inmemory.gpl'=FALSE)
> trying URL 'http://duffel.rail.bio/recount/SRP009615/rse_gene.Rdata'
> Content type 'application/octet-stream' length 1383643 bytes (1.3 MB)
> ==
> downloaded 1.3 MB
>
> Quitting from lines 400-406 (recount-quickstart.Rmd)
> Error: processing vignette 'recount-quickstart.Rmd' failed with diagnostics:
> UCSC library operation failed
> Execution halted
>
>
> The lines of code from the recount vignette this refers to are:
>
> ## Define expressed regions for study SRP009615, only for chromosome Y
> regions <- expressed_regions('SRP009615', 'chrY', cutoff = 5L,
>maxClusterGap = 3000L)
>
> ## Briefly explore the resulting regions
> regions
>
>
>
> The UCSC error is something I've seen in previous versions of
> rtracklayer, which have been addressed in rtracklayer 1.33.11. recount
> version 0.99.25 (which is the one from the build report) had under
> suggests rtracklayer (>= 1.33.11). I thought that this would mean that
> the build would fail if rtracklayer below version 1.33.11 was being
> used. I'm no longer sure, which is why in recount version 0.99.27 I
> moved rtracklayer to imports to test this. The latest build report
> shows that rtracklayer 1.33.11 did build correctly in the Linux
> machine.
>
>
> Everything seems to be working fine in my local tests and in R Travis
> https://travis-ci.org/leekgroup/recount/builds/150995800. Below is
> some code showing that everything is working as expected in my local
> Linux test. So I'm a tad confused and can't reproduce this issue when
> using rtracklayer version 1.33.11. Which is why I'm guessing that
> somehow the Linux build machine is not using rtracklayer >= 1.33.11.
>
>
>
>
> ## The url redirects as expected to the correct url
>> rtracklayer:::expandURL('http://duffel.rail.bio/recount/SRP009615/rse_gene.Rdata')
> [1] "http://idies.jhu.edu/recount/data/SRP009615/rse_gene.Rdata;
>> library('recount')
> Loading required package: SummarizedExperiment
> Loading required package: GenomicRanges
> Loading required package: stats4
> Loading required package: BiocGenerics
> Loading required package: parallel
>
> Attaching package: ‘BiocGenerics’
>
> The following objects are masked from ‘package:parallel’:
>
>clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
>clusterExport, clusterMap, parApply, parCapply, parLapply,
>parLapplyLB, parRapply, parSapply, parSapplyLB
>
> The following objects are masked from ‘package:stats’:
>
>IQR, mad, xtabs
>
> The following objects are masked from ‘package:base’:
>
>anyDuplicated, append, as.data.frame, cbind, colnames, do.call,
>duplicated, eval, evalq, Filter, Find, get, grep, grepl, intersect,
>is.unsorted, lapply, lengths, Map, mapply, match, mget, order,
>paste, pmax, pmax.int, pmin, pmin.int, Position, rank, rbind,
>Reduce, rownames, sapply, setdiff, sort, table, tapply, union,
>unique, unsplit, which, which.max, which.min
>
> Loading required package: S4Vectors
>
> Attaching package: ‘S4Vectors’
>
> The following objects are masked from ‘package:base’:
>
>colMeans, colSums, expand.grid, rowMeans, rowSums
>
> Loading required package: IRanges
> Loading required package: GenomeInfoDb
> Loading required package: Biobase
> Welcome to Bioconductor
>
>Vignettes contain introductory material; view with
>'browseVignett
[Bioc-devel] Debugging build error on Linux machine: is it using rtracklayer >= 1.33.11?
Hi,
Currently the build for `recount` is failing in the Linux build
machine
http://www.bioconductor.org/checkResults/3.4/bioc-LATEST/recount/zin1-buildsrc.html.
It's been failing with the same error message for a while. The build
message ends with:
Setting options('download.file.method.GEOquery'='auto')
Setting options('GEOquery.inmemory.gpl'=FALSE)
trying URL 'http://duffel.rail.bio/recount/SRP009615/rse_gene.Rdata'
Content type 'application/octet-stream' length 1383643 bytes (1.3 MB)
==
downloaded 1.3 MB
Quitting from lines 400-406 (recount-quickstart.Rmd)
Error: processing vignette 'recount-quickstart.Rmd' failed with diagnostics:
UCSC library operation failed
Execution halted
The lines of code from the recount vignette this refers to are:
## Define expressed regions for study SRP009615, only for chromosome Y
regions <- expressed_regions('SRP009615', 'chrY', cutoff = 5L,
maxClusterGap = 3000L)
## Briefly explore the resulting regions
regions
The UCSC error is something I've seen in previous versions of
rtracklayer, which have been addressed in rtracklayer 1.33.11. recount
version 0.99.25 (which is the one from the build report) had under
suggests rtracklayer (>= 1.33.11). I thought that this would mean that
the build would fail if rtracklayer below version 1.33.11 was being
used. I'm no longer sure, which is why in recount version 0.99.27 I
moved rtracklayer to imports to test this. The latest build report
shows that rtracklayer 1.33.11 did build correctly in the Linux
machine.
Everything seems to be working fine in my local tests and in R Travis
https://travis-ci.org/leekgroup/recount/builds/150995800. Below is
some code showing that everything is working as expected in my local
Linux test. So I'm a tad confused and can't reproduce this issue when
using rtracklayer version 1.33.11. Which is why I'm guessing that
somehow the Linux build machine is not using rtracklayer >= 1.33.11.
## The url redirects as expected to the correct url
> rtracklayer:::expandURL('http://duffel.rail.bio/recount/SRP009615/rse_gene.Rdata')
[1] "http://idies.jhu.edu/recount/data/SRP009615/rse_gene.Rdata;
> library('recount')
Loading required package: SummarizedExperiment
Loading required package: GenomicRanges
Loading required package: stats4
Loading required package: BiocGenerics
Loading required package: parallel
Attaching package: ‘BiocGenerics’
The following objects are masked from ‘package:parallel’:
clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
clusterExport, clusterMap, parApply, parCapply, parLapply,
parLapplyLB, parRapply, parSapply, parSapplyLB
The following objects are masked from ‘package:stats’:
IQR, mad, xtabs
The following objects are masked from ‘package:base’:
anyDuplicated, append, as.data.frame, cbind, colnames, do.call,
duplicated, eval, evalq, Filter, Find, get, grep, grepl, intersect,
is.unsorted, lapply, lengths, Map, mapply, match, mget, order,
paste, pmax, pmax.int, pmin, pmin.int, Position, rank, rbind,
Reduce, rownames, sapply, setdiff, sort, table, tapply, union,
unique, unsplit, which, which.max, which.min
Loading required package: S4Vectors
Attaching package: ‘S4Vectors’
The following objects are masked from ‘package:base’:
colMeans, colSums, expand.grid, rowMeans, rowSums
Loading required package: IRanges
Loading required package: GenomeInfoDb
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")'.
Setting options('download.file.method.GEOquery'='auto')
Setting options('GEOquery.inmemory.gpl'=FALSE)
>
> ## Define expressed regions for study SRP009615, only for chromosome Y
> regions <- expressed_regions('SRP009615', 'chrY', cutoff = 5L,
+ maxClusterGap = 3000L)
2016-08-09 14:16:59 loadCoverage: loading BigWig file
http://duffel.rail.bio/recount/SRP009615/bw/mean_SRP009615.bw
2016-08-09 14:17:01 loadCoverage: applying the cutoff to the merged data
2016-08-09 14:17:02 filterData: originally there were 57227415 rows,
now there are 57227415 rows. Meaning that 0 percent was filtered.
2016-08-09 14:17:02 findRegions: identifying potential segments
2016-08-09 14:17:02 findRegions: segmenting information
2016-08-09 14:17:02 .getSegmentsRle: segmenting with cutoff(s) 5
2016-08-09 14:17:02 findRegions: identifying candidate regions
2016-08-09 14:17:03 findRegions: identifying region clusters
>
> ## Briefly explore the resulting regions
> regions
GRanges object with 808 ranges and 6 metadata columns:
seqnames ranges strand |value area
|
1 chrY [2929794, 2929829] * | 14.7265009482702 530.154034137726
2 chrY [2956678, 2956701] * | 12.8106340567271 307.45521736145
3 chrY
