[Bioc-devel] Question about Access to Bioconductor through Git

[George Wu]

Hi Bioc-Devel List,

I am having trouble pushing to the git bioconductor repository, most likely
due to not requesting for access correctly.

I was able to follow the instructions to open a github account and link the
github repository to the one on my local machine, and then sync both with
the g...@git.bioconductor.org for my package. I also submitted the
information and had my key added to have access to push.

When I tried to push my changes I got the following messages:

*"*
*FATAL: W any packages/... DENIED by fallthru*
*(or you mis-spelled the reponame)*
*fatal: Could not read from remote repository.*

*Please make sure you have the correct access rights*
*and the repository exists.*
*"*


My guess is that I submitted my key incorrectly? I used to have a SVN
account a long time ago, but do not remember the details, so I put my
GitHub id. And then I copy-pasted directly using '*clip < ~/.ssh/id_rsa.pub*'
to add my key. The key should work because I used the process to link to my
github account from my local machine. Did I make a mistake somewhere?

Thanks for your help in advance,
George

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

[Andrzej Oleś]

Thanks for you feedback Aaron!

On Tue, Dec 12, 2017 at 9:49 PM, Aaron Lun  wrote:

> Thanks Andrzej.
>
> > Thank you. I've edited the workflow index page by introducing a separate
> > "Single-cell Workflows" section, and by substituting the previous link to
> > your workflow by links to the individual parts.
>
> Great, I'm looking forward to seeing it. Do you know how frequently the
> index page (I assume we're talking about
> https://bioconductor.org/help/workflows/) updates? I assume your edits
> haven't propagated through the system yet.
>

Not sure, should be online by now
https://github.com/Bioconductor/bioconductor.org/commit/a60c46f0942d9825f9a643321890ba5987de109b


>
> > As discussed during EuroBioc, I'm happy to restructure the index page by
> > grouping workflows by topic. It would be really helpful if authors would
> > chime in to suggest the most relevant sections for their workflows.
>
> I can chip in with two that I'm involved in:
>
> "Differential Binding from ChIP-seq data
> " => ChIP-seq
> workflows
> "Gene-level RNA-seq differential expression and pathway analysis
> " => RNA-seq
> workflows
>
> Of course, it depends on how granular you want the topics to be. For
> example, I only see one ChIP-seq workflow, so that particular section
> might be a bit lonely for a while (I am planning to split that into two
> workflows later).
>
>
Right, we should probably avoid hair-splitting. We can start with a few,
say 6, and split up further according to demand as new ones are introduced.

Best,
Andrzej

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

[Aaron Lun]

Thanks Andrzej.

> Thank you. I've edited the workflow index page by introducing a separate
> "Single-cell Workflows" section, and by substituting the previous link to
> your workflow by links to the individual parts.

Great, I'm looking forward to seeing it. Do you know how frequently the
index page (I assume we're talking about
https://bioconductor.org/help/workflows/) updates? I assume your edits
haven't propagated through the system yet.

> As discussed during EuroBioc, I'm happy to restructure the index page by
> grouping workflows by topic. It would be really helpful if authors would
> chime in to suggest the most relevant sections for their workflows.

I can chip in with two that I'm involved in:

"Differential Binding from ChIP-seq data
" => ChIP-seq workflows
"Gene-level RNA-seq differential expression and pathway analysis
" => RNA-seq
workflows

Of course, it depends on how granular you want the topics to be. For
example, I only see one ChIP-seq workflow, so that particular section
might be a bit lonely for a while (I am planning to split that into two
workflows later).

Cheers,

Aaron

> On Tue, Dec 12, 2017 at 7:19 PM, Aaron Lun  wrote:
>
>> The split-up workflows seem to have built successfully:
>>
>> http://docbuilder.bioconductor.org:8080/job/simpleSingleCell/
>>
>> Is there something I have to do to get a blurb specific to each
>> vignette, as observed for "Annotation_Resources" vs
>> "Annotating_Genomic_Ranges"?
>>
>> The various vignettes are ordered pedagogically, so the order in which
>> they are presented in the workflow page might require some manual
>> specification. It would also be nice if the multiple simpleSingleCell
>> workflows are grouped together, to avoid being intermingled with other
>> workflows on the page.
>>
>> Finally, could we get a separate "single-cell workflows" section? The
>> current "Basic/Advanced" partition is pretty crude, and I can see
>> opportunities for more detailed stratification, e.g., by ChIP-seq,
>> RNA-seq, single-cell RNA-seq, proteomics (including mass cytometry).
>>
>> Cheers,
>>
>> Aaron
>>
>>
>> On 11/12/17 20:24, Aaron Lun wrote:
>>> Thanks Val:
>>>
>>> Obenchain, Valerie wrote:
 Hi,

 On 12/11/2017 08:49 AM, Aaron Lun wrote:
> Following up on our earlier discussion:
>
> https://stat.ethz.ch/pipermail/bioc-devel/2017-October/011949.html
>
> I have split the simpleSingleCell workflow into three (four, if you
> include the introductory overview) self-contained Rmarkdown files. I am
> preparing them for submission to BioC's workflow builder, and I would
> like to check what is the best way to do this:
>
> i) Each workflow file goes into its own package.
>
> ii) All workflow files go into a single package.
>
> Option (i) is logistically easier but probably a bit odd conceptually,
> especially if users need to download "simpleSingleCell1",
> "simpleSingleCell2", "simpleSingleCell3", etc.
> Option (ii) is nicer but requires more coordination, as the BioC
>> webpage
> builder needs to know that that multiple HTMLs have been generated.
>> It's
> also unclear to me whether this will run into problems with the DLL
> limit - does R restart when compiling each vignette?
 You could do either but I'd say option 2 is easier from a maintenance
 standpoint and probably for the user. Maybe you've seen this but an
 example is the annotation workflow package which houses 2 workflows:

 ~/repos/svn/workflows >ls annotation/vignettes/
 Annotating_Genomic_Ranges.Rmd  Annotation_Resources.Rmd
 databaseTypes.png  display.png

 Each has an informative name and is presented on the website as an
 individual workflow:

 https://bioconductor.org/help/workflows/
>>> I didn't know that, thanks.
>>>
 I don't think more coordination is involved - you just have multiple
 files in vignettes/. And, as you mentioned, it's a bonus that when a
 user downloads the annotation package they get all related workflows.

 A fresh R session is started for each package but not for each
 vignette in the package.
>>> Ah. That's a shame, I was hoping to reduce the sensitivity to the DLL
>> limit.
>>> But now that I think about it: maybe that's not actually a problem,
>>> provided the BioC workflow builders have a high DLL limit. The main
>>> issue was that *users* were running into the DLL limit; by splitting the
>>> workflow up, users should no be tempted to run everything at once, thus
>>> avoiding the limit on their machines. Of course, Bioconductor can
>>> control its own build machines, so as long as they set the MAX_DLLs
>>> high, it should still build and show up on the website.
>>>
> Any thoughts would be appreciated. I'm also happy to be a guinea pig
>> for
> any SVN->Git 

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

[Andrzej Oleś]

Hi Aaron,

Thank you. I've edited the workflow index page by introducing a separate
"Single-cell Workflows" section, and by substituting the previous link to
your workflow by links to the individual parts.

As discussed during EuroBioc, I'm happy to restructure the index page by
grouping workflows by topic. It would be really helpful if authors would
chime in to suggest the most relevant sections for their workflows.

Cheers,
Andrzej

On Tue, Dec 12, 2017 at 7:19 PM, Aaron Lun  wrote:

> The split-up workflows seem to have built successfully:
>
> http://docbuilder.bioconductor.org:8080/job/simpleSingleCell/
>
> Is there something I have to do to get a blurb specific to each
> vignette, as observed for "Annotation_Resources" vs
> "Annotating_Genomic_Ranges"?
>
> The various vignettes are ordered pedagogically, so the order in which
> they are presented in the workflow page might require some manual
> specification. It would also be nice if the multiple simpleSingleCell
> workflows are grouped together, to avoid being intermingled with other
> workflows on the page.
>
> Finally, could we get a separate "single-cell workflows" section? The
> current "Basic/Advanced" partition is pretty crude, and I can see
> opportunities for more detailed stratification, e.g., by ChIP-seq,
> RNA-seq, single-cell RNA-seq, proteomics (including mass cytometry).
>
> Cheers,
>
> Aaron
>
>
> On 11/12/17 20:24, Aaron Lun wrote:
> > Thanks Val:
> >
> > Obenchain, Valerie wrote:
> >> Hi,
> >>
> >> On 12/11/2017 08:49 AM, Aaron Lun wrote:
> >>> Following up on our earlier discussion:
> >>>
> >>> https://stat.ethz.ch/pipermail/bioc-devel/2017-October/011949.html
> >>>
> >>> I have split the simpleSingleCell workflow into three (four, if you
> >>> include the introductory overview) self-contained Rmarkdown files. I am
> >>> preparing them for submission to BioC's workflow builder, and I would
> >>> like to check what is the best way to do this:
> >>>
> >>> i) Each workflow file goes into its own package.
> >>>
> >>> ii) All workflow files go into a single package.
> >>>
> >>> Option (i) is logistically easier but probably a bit odd conceptually,
> >>> especially if users need to download "simpleSingleCell1",
> >>> "simpleSingleCell2", "simpleSingleCell3", etc.
> >>> Option (ii) is nicer but requires more coordination, as the BioC
> webpage
> >>> builder needs to know that that multiple HTMLs have been generated.
> It's
> >>> also unclear to me whether this will run into problems with the DLL
> >>> limit - does R restart when compiling each vignette?
> >> You could do either but I'd say option 2 is easier from a maintenance
> >> standpoint and probably for the user. Maybe you've seen this but an
> >> example is the annotation workflow package which houses 2 workflows:
> >>
> >> ~/repos/svn/workflows >ls annotation/vignettes/
> >> Annotating_Genomic_Ranges.Rmd  Annotation_Resources.Rmd
> >> databaseTypes.png  display.png
> >>
> >> Each has an informative name and is presented on the website as an
> >> individual workflow:
> >>
> >> https://bioconductor.org/help/workflows/
> >
> > I didn't know that, thanks.
> >
> >> I don't think more coordination is involved - you just have multiple
> >> files in vignettes/. And, as you mentioned, it's a bonus that when a
> >> user downloads the annotation package they get all related workflows.
> >>
> >> A fresh R session is started for each package but not for each
> >> vignette in the package.
> >
> > Ah. That's a shame, I was hoping to reduce the sensitivity to the DLL
> limit.
> >
> > But now that I think about it: maybe that's not actually a problem,
> > provided the BioC workflow builders have a high DLL limit. The main
> > issue was that *users* were running into the DLL limit; by splitting the
> > workflow up, users should no be tempted to run everything at once, thus
> > avoiding the limit on their machines. Of course, Bioconductor can
> > control its own build machines, so as long as they set the MAX_DLLs
> > high, it should still build and show up on the website.
> >
> >>> Any thoughts would be appreciated. I'm also happy to be a guinea pig
> for
> >>> any SVN->Git transition for the workflow packages, if that's on the
> radar.
> >>
> >> Nitesh has created git repos for the workflow packages and Andrzej is
> >> adapting the BBS code to incorporate them into the builds. We
> >> guesstimate this will be done by the end of the year. You shouldn't
> >> have to do anything on your end - once we're ready to switch over
> >> we'll let you know and send the new location of the workflow in git.
> >
> > Cool, looking forward to it.
> >
> > -A
> >
> >> Val
> >>> Cheers,
> >>>
> >>> Aaron
> >>> ___
> >>> 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 

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

[Aaron Lun]

The split-up workflows seem to have built successfully:

http://docbuilder.bioconductor.org:8080/job/simpleSingleCell/

Is there something I have to do to get a blurb specific to each 
vignette, as observed for "Annotation_Resources" vs 
"Annotating_Genomic_Ranges"?

The various vignettes are ordered pedagogically, so the order in which 
they are presented in the workflow page might require some manual 
specification. It would also be nice if the multiple simpleSingleCell 
workflows are grouped together, to avoid being intermingled with other 
workflows on the page.

Finally, could we get a separate "single-cell workflows" section? The 
current "Basic/Advanced" partition is pretty crude, and I can see 
opportunities for more detailed stratification, e.g., by ChIP-seq, 
RNA-seq, single-cell RNA-seq, proteomics (including mass cytometry).

Cheers,

Aaron


On 11/12/17 20:24, Aaron Lun wrote:
> Thanks Val:
> 
> Obenchain, Valerie wrote:
>> Hi,
>>
>> On 12/11/2017 08:49 AM, Aaron Lun wrote:
>>> Following up on our earlier discussion:
>>>
>>> https://stat.ethz.ch/pipermail/bioc-devel/2017-October/011949.html
>>>
>>> I have split the simpleSingleCell workflow into three (four, if you
>>> include the introductory overview) self-contained Rmarkdown files. I am
>>> preparing them for submission to BioC's workflow builder, and I would
>>> like to check what is the best way to do this:
>>>
>>> i) Each workflow file goes into its own package.
>>>
>>> ii) All workflow files go into a single package.
>>>
>>> Option (i) is logistically easier but probably a bit odd conceptually,
>>> especially if users need to download "simpleSingleCell1",
>>> "simpleSingleCell2", "simpleSingleCell3", etc.
>>> Option (ii) is nicer but requires more coordination, as the BioC webpage
>>> builder needs to know that that multiple HTMLs have been generated. It's
>>> also unclear to me whether this will run into problems with the DLL
>>> limit - does R restart when compiling each vignette?
>> You could do either but I'd say option 2 is easier from a maintenance
>> standpoint and probably for the user. Maybe you've seen this but an
>> example is the annotation workflow package which houses 2 workflows:
>>
>> ~/repos/svn/workflows >ls annotation/vignettes/
>> Annotating_Genomic_Ranges.Rmd  Annotation_Resources.Rmd
>> databaseTypes.png  display.png
>>
>> Each has an informative name and is presented on the website as an
>> individual workflow:
>>
>> https://bioconductor.org/help/workflows/
> 
> I didn't know that, thanks.
> 
>> I don't think more coordination is involved - you just have multiple
>> files in vignettes/. And, as you mentioned, it's a bonus that when a
>> user downloads the annotation package they get all related workflows.
>>
>> A fresh R session is started for each package but not for each
>> vignette in the package.
> 
> Ah. That's a shame, I was hoping to reduce the sensitivity to the DLL limit.
> 
> But now that I think about it: maybe that's not actually a problem,
> provided the BioC workflow builders have a high DLL limit. The main
> issue was that *users* were running into the DLL limit; by splitting the
> workflow up, users should no be tempted to run everything at once, thus
> avoiding the limit on their machines. Of course, Bioconductor can
> control its own build machines, so as long as they set the MAX_DLLs
> high, it should still build and show up on the website.
> 
>>> Any thoughts would be appreciated. I'm also happy to be a guinea pig for
>>> any SVN->Git transition for the workflow packages, if that's on the radar.
>>
>> Nitesh has created git repos for the workflow packages and Andrzej is
>> adapting the BBS code to incorporate them into the builds. We
>> guesstimate this will be done by the end of the year. You shouldn't
>> have to do anything on your end - once we're ready to switch over
>> we'll let you know and send the new location of the workflow in git.
> 
> Cool, looking forward to it.
> 
> -A
> 
>> Val
>>> Cheers,
>>>
>>> Aaron
>>> ___
>>> 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.
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 

-- 
Aaron Lun
Research Associate, CRUK Cambridge Institute
University of Cambridge
___
Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

[Aaron Lun]

The split-up workflows seem to have built successfully:

http://docbuilder.bioconductor.org:8080/job/simpleSingleCell/

The various vignettes are ordered pedagogically, so the order in which 
they are presented in the workflow page might require some manual 
specification. It would also be nice if the multiple simpleSingleCell 
workflows are grouped together, to avoid being intermingled with other 
workflows on the page.

Is there something I have to do to get a blurb specific to each 
vignette, as observed for "Annotation_Resources" vs 
"Annotating_Genomic_Ranges"? I'm happy to only have a blurb for the 
first workflow, given that I'd be just repeating myself for the others; 
but this depends on how it's organized on the webpage.

Finally, could we get a separate "single-cell workflows" section? The 
current "Basic/Advanced" partition is pretty crude, and I can see 
opportunities for more detailed stratification, e.g., by ChIP-seq, 
RNA-seq, single-cell RNA-seq, proteomics (including mass cytometry).

Cheers,

Aaron

On 11/12/17 20:24, Aaron Lun wrote:
> Thanks Val:
> 
> Obenchain, Valerie wrote:
>> Hi,
>>
>> On 12/11/2017 08:49 AM, Aaron Lun wrote:
>>> Following up on our earlier discussion:
>>>
>>> https://stat.ethz.ch/pipermail/bioc-devel/2017-October/011949.html
>>>
>>> I have split the simpleSingleCell workflow into three (four, if you
>>> include the introductory overview) self-contained Rmarkdown files. I am
>>> preparing them for submission to BioC's workflow builder, and I would
>>> like to check what is the best way to do this:
>>>
>>> i) Each workflow file goes into its own package.
>>>
>>> ii) All workflow files go into a single package.
>>>
>>> Option (i) is logistically easier but probably a bit odd conceptually,
>>> especially if users need to download "simpleSingleCell1",
>>> "simpleSingleCell2", "simpleSingleCell3", etc.
>>> Option (ii) is nicer but requires more coordination, as the BioC webpage
>>> builder needs to know that that multiple HTMLs have been generated. It's
>>> also unclear to me whether this will run into problems with the DLL
>>> limit - does R restart when compiling each vignette?
>> You could do either but I'd say option 2 is easier from a maintenance
>> standpoint and probably for the user. Maybe you've seen this but an
>> example is the annotation workflow package which houses 2 workflows:
>>
>> ~/repos/svn/workflows >ls annotation/vignettes/
>> Annotating_Genomic_Ranges.Rmd  Annotation_Resources.Rmd
>> databaseTypes.png  display.png
>>
>> Each has an informative name and is presented on the website as an
>> individual workflow:
>>
>> https://bioconductor.org/help/workflows/
> 
> I didn't know that, thanks.
> 
>> I don't think more coordination is involved - you just have multiple
>> files in vignettes/. And, as you mentioned, it's a bonus that when a
>> user downloads the annotation package they get all related workflows.
>>
>> A fresh R session is started for each package but not for each
>> vignette in the package.
> 
> Ah. That's a shame, I was hoping to reduce the sensitivity to the DLL limit.
> 
> But now that I think about it: maybe that's not actually a problem,
> provided the BioC workflow builders have a high DLL limit. The main
> issue was that *users* were running into the DLL limit; by splitting the
> workflow up, users should no be tempted to run everything at once, thus
> avoiding the limit on their machines. Of course, Bioconductor can
> control its own build machines, so as long as they set the MAX_DLLs
> high, it should still build and show up on the website.
> 
>>> Any thoughts would be appreciated. I'm also happy to be a guinea pig for
>>> any SVN->Git transition for the workflow packages, if that's on the radar.
>>
>> Nitesh has created git repos for the workflow packages and Andrzej is
>> adapting the BBS code to incorporate them into the builds. We
>> guesstimate this will be done by the end of the year. You shouldn't
>> have to do anything on your end - once we're ready to switch over
>> we'll let you know and send the new location of the workflow in git.
> 
> Cool, looking forward to it.
> 
> -A
> 
>> Val
>>> Cheers,
>>>
>>> Aaron
>>> ___
>>> 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.
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 

[Bioc-devel] R: DaMiRseq: error while pushing

[Mattia Chiesa]

Hi Nitesh,
I read but I just wanted to be sure.
So, I typed:
git pull upstream master
Update the Version in DESCRIPTION
git add .
git commit -m "new message"
git push upstream master

and, I hope that everything will be ok now.
Many Thanks Nitesh!
Mattia



Da: Turaga, Nitesh 
Inviato: marted� 12 dicembre 2017 16:35
A: Mattia Chiesa
Cc: bioc-devel@r-project.org
Oggetto: Re: [Bioc-devel] DaMiRseq: error while pushing

Hi Mattia,

If you read the �error� and �hint� messages carefully, it says do a

> hint: (e.g., 'git pull ...') before pushing again.

Did you try that?

Best,

Nitesh

> On Dec 12, 2017, at 10:21 AM, Mattia Chiesa  wrote:
>
> Dear All,
> I am the mantainer of the DaMiRseq package.
> I performed some relevant modificantions in the package (i.e. added 
> functions, added the CITATION file, updated vignette and NEWS file) and now 
> I'm ready to push (from a local folder to github and Bioconductor).
> So, as usually, I typed:
> git add .
> git commit -m "message"
> git push origin master
> git push upstream master
> (and typed the password)
>
> Everything was ok for github (origin) but for Bioconductor an error occured:
>
> Enter passphrase for key '/c/Users/mchiesa/.ssh/id_rsa':
> To git.bioconductor.org:packages/DaMiRseq.git
> ! [rejected]master -> master (fetch first)
> error: failed to push some refs to 
> 'g...@git.bioconductor.org:packages/DaMiRseq.git'
> hint: Updates were rejected because the remote contains work that you do
> hint: not have locally. This is usually caused by another repository pushing
> hint: to the same ref. You may want to first integrate the remote changes
> hint: (e.g., 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
> What should I do?
> Thanks in advance,
> Mattia
>
>
>[[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

Re: [Bioc-devel] DaMiRseq: error while pushing

[Turaga, Nitesh]

Hi Mattia,

If you read the “error” and “hint” messages carefully, it says do a 

> hint: (e.g., 'git pull ...') before pushing again.

Did you try that?

Best,

Nitesh 

> On Dec 12, 2017, at 10:21 AM, Mattia Chiesa  wrote:
> 
> Dear All,
> I am the mantainer of the DaMiRseq package.
> I performed some relevant modificantions in the package (i.e. added 
> functions, added the CITATION file, updated vignette and NEWS file) and now 
> I'm ready to push (from a local folder to github and Bioconductor).
> So, as usually, I typed:
> git add .
> git commit -m "message"
> git push origin master
> git push upstream master
> (and typed the password)
> 
> Everything was ok for github (origin) but for Bioconductor an error occured:
> 
> Enter passphrase for key '/c/Users/mchiesa/.ssh/id_rsa':
> To git.bioconductor.org:packages/DaMiRseq.git
> ! [rejected]master -> master (fetch first)
> error: failed to push some refs to 
> 'g...@git.bioconductor.org:packages/DaMiRseq.git'
> hint: Updates were rejected because the remote contains work that you do
> hint: not have locally. This is usually caused by another repository pushing
> hint: to the same ref. You may want to first integrate the remote changes
> hint: (e.g., 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> 
> What should I do?
> Thanks in advance,
> Mattia
> 
> 
>   [[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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Version update question and an error?

[Shepherd, Lori]

  1.   Here is a page that describes versioning:

http://bioconductor.org/developers/how-to/version-numbering/


x.y.z


When there is a Bioconductor release we bump the 'y' version of the package to 
even for release and then again in devel so devel is odd and a version above 
the current release.  (when a package is accepted the first release version is 
1.0.0 and devel 1.1.0)


So yes the next commit you would push should have a version 1.1.1.  You might 
also want to look at pulling changes from Bioconductor and pushing to local:

http://bioconductor.org/developers/how-to/git/pull-upstream-changes/




2.  If your package is building on linux and mac you can ignore the windows 
ERROR.  Most of these ERRORs are do to CRAN package binaries not being 
available yet for R 3.5.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Christopher 
John 
Sent: Tuesday, December 12, 2017 7:33:43 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Version update question and an error?

Hi

I have had a package quite recently accepted to the bioconductor. I have
two questions:

1. My version is listed as 0.99.98 in my local description file, 1.1.0 in
my bioconductor development web page, and 1.0.0 in the non development
bioconductor web page. Do I bump to 1.1.1 in my next commit to the github?

2. I may have missed another email about this, but I noticed my development
page has an error for build check for windows, but many other packages have
this for windows atm, I checked the whole list. Is this something I need to
worry about?

Below is the error code:

* checking for file 'M3C/DESCRIPTION' ... OK
* preparing 'M3C':
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR

Many thanks,

Chris

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

[Bioc-devel] Version update question and an error?

[Christopher John]

Hi

I have had a package quite recently accepted to the bioconductor. I have
two questions:

1. My version is listed as 0.99.98 in my local description file, 1.1.0 in
my bioconductor development web page, and 1.0.0 in the non development
bioconductor web page. Do I bump to 1.1.1 in my next commit to the github?

2. I may have missed another email about this, but I noticed my development
page has an error for build check for windows, but many other packages have
this for windows atm, I checked the whole list. Is this something I need to
worry about?

Below is the error code:

* checking for file 'M3C/DESCRIPTION' ... OK
* preparing 'M3C':
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR

Many thanks,

Chris

[[alternative HTML version deleted]]

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

[Bioc-devel] SummarizedExperiment: duplication of metadata, when modifying colData

[Felix Ernst]

Hi all,

 

I got a bit of weird behaviour with SummarizedExperiments in Bioc 3.6 and
3.7. I suppose it is a bug, but I might be wrong, since the accession to the
SummarizedExperiment object is not really straight forward. Any suggestions?

library(GenomicRanges)

library(SummarizedExperiment)

 

nrows <- 200; ncols <- 6

counts <- matrix(runif(nrows * ncols, 1, 1e4), nrows)

colnames(counts) <- LETTERS[1:6]

rownames(counts) <- 1:nrows

counts2 <- counts-floor(counts)

rowRanges <- GRanges(rep(c("chr1", "chr2"), c(50, 150)),

 IRanges(floor(runif(200, 1e5, 1e6)), width=100),

 strand=sample(c("+", "-"), 200, TRUE),

 feature_id=sprintf("ID%03d", 1:200)) 

colData <- DataFrame(Treatment=rep(c("ChIP", "Input"), 3),

 row.names=LETTERS[1:6])

 

se <- SummarizedExperiment(assays=list(counts=counts),

   rowRanges=rowRanges,

   colData=colData)

colData(se)$xyz <- rep("",ncol(se))

metadata(se) <- list("meep" = "meep")

 

str(metadata(se))

colData(se[, 1])$xyz <- "abc"

str(metadata(se))

The first metadata() returns a list, length of 1, with the correct data. The
second call returns a list of two, with a duplicated entries and every
further colData modification (and replacing data) duplicates the entries in
the metadata further.

> str(metadata(se))

List of 1

$ meep: chr "meep"

> colData(se[, 1])$xyz <- "abc"

> str(metadata(se))

List of 2

$ meep: chr "meep"

$ meep: chr "meep"
> colData(se[, 2])$xyz <- "abc"

> str(metadata(se))

List of 4

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

> colData(se[, 2])$xyz <- "abc"

> str(metadata(se))

List of 8

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

Thanks for any advice and suggestions.

Felix



---



Felix Ernst, PhD

Universit� Libre de Bruxelles

RNA MOLECULAR BIOLOGY

BIOPARK Charleroi Brussels-South CAMPUS

Rue Profs Jeener & Brachet, 12

B-6041 Charleroi - Gosselies

BELGIUM

+32(2)650 9774 (office phone)

  felix.er...@ulb.ac.be

 






[[alternative HTML version deleted]]

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