[Bioc-devel] Bioconductor git credentials

[Wagner, Jake]

Hello,


My name is Jacob Wagner and I will be helping Mike Jiang to maintain most of 
the packages he works on involving analysis of flow cytometry data. If possible 
I would like to:


1) Get set up with an account in the credentials database so that I can add my 
public key to be able to at least pull from the git repos

2) Get added as a maintainer so that I can push to the repos as well


The repositories are:

cytolib

CytoML

flowClust

flowCore

flowQ

flowStats

flowViz

flowWorkspace

ggcyto

ncdfFlow

openCyto

QUALIFIER

RProtoBufLib


The email I would like for the account is jpwag...@fredhutch.org


Please let me know how I might go about setting this up or what further 
information you may need from me. I am CCing Mike Jiang so he can monitor the 
progress and can if necessary provide approval for the change.


Thanks much,

Jake Wagner

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor git credentials

[Jiang, Mike]

Lori,
Would you be able to help with this?
Thanks!
Mike

From: Wagner, Jake
Sent: Wednesday, February 6, 2019 3:20 PM
To: bioc-devel@r-project.org
Cc: Jiang, Mike
Subject: Bioconductor git credentials


Hello,


My name is Jacob Wagner and I will be helping Mike Jiang to maintain most of 
the packages he works on involving analysis of flow cytometry data. If possible 
I would like to:


1) Get set up with an account in the credentials database so that I can add my 
public key to be able to at least pull from the git repos

2) Get added as a maintainer so that I can push to the repos as well


The repositories are:

cytolib

CytoML

flowClust

flowCore

flowQ

flowStats

flowViz

flowWorkspace

ggcyto

ncdfFlow

openCyto

QUALIFIER

RProtoBufLib


The email I would like for the account is jpwag...@fredhutch.org


Please let me know how I might go about setting this up or what further 
information you may need from me. I am CCing Mike Jiang so he can monitor the 
progress and can if necessary provide approval for the change.


Thanks much,

Jake Wagner

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Submission of packages located at within a repository

[Turaga, Nitesh]

Hi Britta,

You could use submodules in git. I took some time to create an example use case 
for you, at 

https://github.com/nturaga/main_repository

The “main_repository” contains a README.md file which you might find useful to 
go about creating the submodule for your packages/

The example there, shows,

main_repository, (parent repo) located at 
https://github.com/nturaga/main_repository

submodule_one (as submodule) located at 
https://github.com/nturaga/submodule_one


To give you a gist of what you could do:

Main repository is “MOFA_main”, located at https://github.com/bioFAM/MOFA_main

submodule 1: MOFA software package located at 
https://github.com/bioFAM/MOFA

submodule 2: MOFA data package located at 
https://github.com/bioFAM/MOFAdata

They would both live in the MOFA_main repository but would act as submodules 
within their own independent repos. This will allow you to submit from their 
separate repos.

https://github.com/nturaga/main_repository/blob/master/README.md gives you 
details on how to create submodules, if you need any assistance. But, I’ll 
highlight some steps,

Step 0: Rename the main MOFA directory which already exists to MOFA_main.

Step 1: Create two new repos in the bioFAM username, with MOFA, and MOFAdata. 

Step 2: Create submodules in MOFA_main, 

git submodule init

git submodule add g...@github.com:bioFAM/MOFA MOFA

git submodule add g...@github.com:bioFAM/MOFAdata MOFAdata


Step 3: Add the submodules to MOFA_main

git commit -m “Add MOFA and MOFAdata as submodules”.

The “.gitmodules” should show,

$ cat .gitmodules

[submodule “MOFA"]
path = MOFA
url = g...@github.com:bioFAM/MOFA

[submodule “MOFAdata”]
path  = MOFAdata
url = g...@github.com:bioFAM/MOFAdata


But to answer your question, bioconductor doesn’t have a way to submit multiple 
packages from within one repository. 

I can assist you in creating submodules, and submitting the repos as required 
to Bioconductor. Please let me know if you have any questions. Please check the 
example and the documentation I wrote up in the README.md at 
https://github.com/nturaga/main_repository.


Best,

Nitesh 




> On Feb 4, 2019, at 11:24 AM, Britta Velten  wrote:
> 
> Dear Bioconductor team,
> 
> we would like to submit two R packages (software and accompanying data 
> package) that are located in a git repository jointly with a Python package 
> that one of them depends upon.
> These two R packages are located at 
> - https://github.com/bioFAM/MOFA/tree/master/MOFA
> - https://github.com/bioFAM/MOFA/tree/master/MOFAdata
> within the repository https://github.com/bioFAM/MOFA.
> 
> However, the submission via the git submission system fails as it requires 
> the package to sit at https://github.com/yourusername/yourpackagename 
> .
> We would like to avoid breaking up the repository 
> https://github.com/bioFAM/MOFA into separate repositories for each package as 
> they are inter-dependent and new developments or fixes often involve changes 
> to both the python package (mofapy) and the R package (MOFA) (e.g. having 
> common branches for the two packages is very useful).
> 
> Is there a way to submit the packages at their current paths, i.e. make the 
> submission system look at https://github.com/bioFAM/MOFA/tree/master/MOFA and 
> /MOFAdata instead of https://github.com/bioFAM/MOFA? If not, do you have 
> other suggestions how to solve this without breaking up the repository?
> 
> Thanks for your help!
> 
> Best,
> Britta Velten
> 
>   [[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] error pushing changes

[Turaga, Nitesh]

Hi Marta,

That’s good to know that nothing is awry as far as versions go. 

There is no active web hook once a package is accepted, the web hook is for 
building and checking while the package is going through the submission 
process. 

Once it is accepted into Bioconductor, we just have the package registered on 
the build machines so that the developers and core team can check if it builds 
successfully on the devel and RELEASE branches. 

Best,

Nitesh 


> On Feb 6, 2019, at 11:07 AM, Marta Hidalgo  wrote:
> 
> Hi Nitesh, 
> 
> Thank you so much for your help. I think I have managed not to mess it up 
> again. 
> Btw, I have a small question regarding the webhook that should be added to 
> the github repository when submitting a package: is this webhook still 
> necessary once the package has been acepted?
> 
> Well, thanks again for your help, 
> Best, 
> 
> Marta
> 
> Marta Hidalgo 
> 
> De: Turaga, Nitesh 
> Enviado: miércoles, 30 de enero de 2019 18:27
> Para: Marta Hidalgo
> Cc: Bioc-devel; Morgan, Martin
> Asunto: Re: [Bioc-devel] error pushing changes
>  
> Hi Marta,
> 
> I have fixed your repository in the Bioconductor repo. 
> g...@git.bioconductor.org:packages/hipathia.git
> 
> Please follow this document exactly as is, to sync your GitHub repository 
> (http://bioconductor.org/developers/how-to/git/sync-existing-repositories/). 
> If you are having issues with this, feel free to reach out in this thread. 
> It’s easier to point to the correct git resources, than to fix the versions. 
> 
> As a precaution in the future, do not merge the ‘master’ branch into 
> ‘RELEASE_X_Y’ that is the issue which caused the version numbering to go bad. 
> 
> Best,
> 
> Nitesh
> 
> 
> > On Jan 30, 2019, at 5:00 AM, Marta Hidalgo  wrote:
> > 
> > Hi Nitesh,
> > 
> > Thank you for your quick answer and sorry for the trouble.
> > Yes please, I think I'll need some help to fix this. Can you give me some 
> > instructions?
> > 
> > Thank you again!
> > 
> > Marta
> > 
> > 
> > 
> > Marta Hidalgo
> > 
> > 
> > 
> > De: Nitesh Turaga 
> > Enviado: miércoles, 30 de enero de 2019 1:36
> > Para: Bioc-devel; Morgan, Martin
> > Cc: marta.hida...@outlook.es
> > Asunto: Re: error pushing changes
> > 
> > Hi Marta,
> > 
> > There are a few issues with your repository. Let’s take a look at your 
> > commit history.
> > 
> > t/hipathia (RELEASE_3_8)❯❯❯ git log —oneline
> > d93efc9 (HEAD -> RELEASE_3_8, origin/RELEASE_3_8) Fixing bug in Wilcoxon 
> > test
> > bd245a5 fixing version number in NEWS file
> > bdfe551 fixing version number after merging
> > 33addfa bumping version and updating NEWS file
> > 2331dac Merge branch 'RELEASE_3_8' of 
> > git.bioconductor.org:packages/hipathia
> > 4686268 Fixing bug in get_pathways_summary when comp is ordered
> > f5e8ef4 minor adding to vignette
> > b96521e bump x.y.z versions to odd y after creation of RELEASE_3_8 branch
> > f7bc056 bump x.y.z versions to even y prior to creation of RELEASE_3_8 
> > branch
> > 
> > The commit b96521e is not supposed to exist on the RELEASE_3_8 branch. It 
> > is supposed to be only in the devel (master) branch of your repository. So 
> > when you merged, you seem to have merged the master branch into RELEASE_3_8.
> > 
> > So, your RELEASE_3_8 versioning is wrong. As shown, below, your RELEASE_3_8 
> > should just be incrementing after commit f7bc056 where the version number 
> > was set by the core team as Version: 1.2.0. The next one should be 1.2.1 
> > and 1.2.2 and so on. The ‘y’ in the x.y.z should always be even.
> > 
> > /t/hipathia(RELEASE_3_8) ❯❯❯ git show f7bc056
> > commit f7bc056e55a220b8bea8793a9b3b375c0ab66e7a
> > Author: vobencha mailto:voben...@gmail.com>>
> > ...
> >bump x.y.z versions to even y prior to creation of RELEASE_3_8 branch
> > ….
> > -Version: 1.1.3
> > +Version: 1.2.0
> > 
> > When you pushed, the current version of your repository in RELEASE_3_8 is 
> > being shown as 1.3.1. This is not allowed. I’m investigating how you were 
> > able to even pass through the commit hook with the bad version number, but 
> > the commit below should have been an indicator that something is seriously 
> > going wrong. Particularly the highlighted bits below where there are three 
> > version numbers which are being changed, moving ‘y’ from odd to even. The 
> > developer should never ever touch the ‘y’ version of number, only the ‘z’.
> > 
> > /t/hipathia(RELEASE_3_8) ❯❯❯ git show 
> > bdfe551514f0cf33798c45ae0475ff42eb4285e8
> > commit bdfe551514f0cf33798c45ae0475ff42eb4285e8
> > Merge: 33addfa b96521e
> > Author: Marta R. Hidalgo 
> > mailto:marta.hida...@outlook.es>>
> > Date:   Mon Dec 17 11:14:39 2018 +0100
> > 
> >fixing version number after merging
> > 
> > diff --cc DESCRIPTION
> > index 7b35af2,24c9d19..491fbd6
> > --- a/DESCRIPTION
> > +++ b/DESCRIPTION
> > @@@ -1,6 -1,6 +1,6 @@@
> >  Package: hipathia
> >  Title: HiPathia: 

Re: [Bioc-devel] error pushing changes

[Marta Hidalgo]

Hi Nitesh,

Thank you so much for your help. I think I have managed not to mess it up again.
Btw, I have a small question regarding the webhook that should be added to the 
github repository when submitting a package: is this webhook still necessary 
once the package has been acepted?

Well, thanks again for your help,
Best,

Marta



Marta Hidalgo



De: Turaga, Nitesh 
Enviado: miércoles, 30 de enero de 2019 18:27
Para: Marta Hidalgo
Cc: Bioc-devel; Morgan, Martin
Asunto: Re: [Bioc-devel] error pushing changes

Hi Marta,

I have fixed your repository in the Bioconductor repo. 
g...@git.bioconductor.org:packages/hipathia.git

Please follow this document exactly as is, to sync your GitHub repository 
(http://bioconductor.org/developers/how-to/git/sync-existing-repositories/). If 
you are having issues with this, feel free to reach out in this thread. It’s 
easier to point to the correct git resources, than to fix the versions.

As a precaution in the future, do not merge the ‘master’ branch into 
‘RELEASE_X_Y’ that is the issue which caused the version numbering to go bad.

Best,

Nitesh


> On Jan 30, 2019, at 5:00 AM, Marta Hidalgo  wrote:
>
> Hi Nitesh,
>
> Thank you for your quick answer and sorry for the trouble.
> Yes please, I think I'll need some help to fix this. Can you give me some 
> instructions?
>
> Thank you again!
>
> Marta
>
> 
>
> Marta Hidalgo
>
>
> 
> De: Nitesh Turaga 
> Enviado: miércoles, 30 de enero de 2019 1:36
> Para: Bioc-devel; Morgan, Martin
> Cc: marta.hida...@outlook.es
> Asunto: Re: error pushing changes
>
> Hi Marta,
>
> There are a few issues with your repository. Let’s take a look at your commit 
> history.
>
> t/hipathia (RELEASE_3_8)❯❯❯ git log —oneline
> d93efc9 (HEAD -> RELEASE_3_8, origin/RELEASE_3_8) Fixing bug in Wilcoxon test
> bd245a5 fixing version number in NEWS file
> bdfe551 fixing version number after merging
> 33addfa bumping version and updating NEWS file
> 2331dac Merge branch 'RELEASE_3_8' of 
> git.bioconductor.org:packages/hipathia
> 4686268 Fixing bug in get_pathways_summary when comp is ordered
> f5e8ef4 minor adding to vignette
> b96521e bump x.y.z versions to odd y after creation of RELEASE_3_8 branch
> f7bc056 bump x.y.z versions to even y prior to creation of RELEASE_3_8 branch
>
> The commit b96521e is not supposed to exist on the RELEASE_3_8 branch. It is 
> supposed to be only in the devel (master) branch of your repository. So when 
> you merged, you seem to have merged the master branch into RELEASE_3_8.
>
> So, your RELEASE_3_8 versioning is wrong. As shown, below, your RELEASE_3_8 
> should just be incrementing after commit f7bc056 where the version number was 
> set by the core team as Version: 1.2.0. The next one should be 1.2.1 and 
> 1.2.2 and so on. The ‘y’ in the x.y.z should always be even.
>
> /t/hipathia(RELEASE_3_8) ❯❯❯ git show f7bc056
> commit f7bc056e55a220b8bea8793a9b3b375c0ab66e7a
> Author: vobencha mailto:voben...@gmail.com>>
> ...
>bump x.y.z versions to even y prior to creation of RELEASE_3_8 branch
> ….
> -Version: 1.1.3
> +Version: 1.2.0
>
> When you pushed, the current version of your repository in RELEASE_3_8 is 
> being shown as 1.3.1. This is not allowed. I’m investigating how you were 
> able to even pass through the commit hook with the bad version number, but 
> the commit below should have been an indicator that something is seriously 
> going wrong. Particularly the highlighted bits below where there are three 
> version numbers which are being changed, moving ‘y’ from odd to even. The 
> developer should never ever touch the ‘y’ version of number, only the ‘z’.
>
> /t/hipathia(RELEASE_3_8) ❯❯❯ git show bdfe551514f0cf33798c45ae0475ff42eb4285e8
> commit bdfe551514f0cf33798c45ae0475ff42eb4285e8
> Merge: 33addfa b96521e
> Author: Marta R. Hidalgo 
> mailto:marta.hida...@outlook.es>>
> Date:   Mon Dec 17 11:14:39 2018 +0100
>
>fixing version number after merging
>
> diff --cc DESCRIPTION
> index 7b35af2,24c9d19..491fbd6
> --- a/DESCRIPTION
> +++ b/DESCRIPTION
> @@@ -1,6 -1,6 +1,6 @@@
>  Package: hipathia
>  Title: HiPathia: High-throughput Pathway Analysis
> - Version: 1.2.1
> -Version: 1.3.0
> ++Version: 1.3.1
>
> You will have to fix your last few commits. I can help you revert it back to 
> the previous release, and we can go from there. Please let me know how you 
> want to proceed.
>
> Best,
>
> Nitesh
>
>
>
> On Jan 29, 2019, at 4:24 PM, Martin Morgan 
> mailto:mtmorgan.b...@gmail.com>> wrote:
>
> Hi Nitesh -- can you help Marta please? Thanks, Martin
>
>
>
> On 1/29/19, 12:20 PM, "Marta Hidalgo" 
> mailto:marta.hida...@outlook.es>> wrote:
>
>
>   Hi,
>
>
>   I'm trying to push some changes to the RELEASE_3_8 branch of package 
> Hipathia and I'm getting the following error:
>
>
>   Agent admitted failure to sign using the key.
>   Total 0 

Re: [R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R

[Sebastian Meyer]

The DESCRIPTION's Author field is auto-generated from Authors@R during R
CMD build. You are right, the format has slightly changed since R 3.3.3
(e.g., support for ORCID ID).

The CRAN repository policy says:

> Uploads must be source tarballs created by R CMD build and following
> the PACKAGE_VERSION.tar.gz naming scheme. This should be done with
> current R-patched or the current release of R.

-> https://cran.r-project.org/web/packages/policies.html

Further to that, note that you are using a non-standard role ("con").
See the details in help("person") for the roles used in the context of R
packages: aut, com, ctr, ctb, cph, cre, dtc, fnd, ths, trl.

Cheers,

Sebastian


Am 06.02.19 um 13:26 schrieb Ivan Krylov:
> Hi!
> 
> I'm relying on Authors@R to generate the Author: and Maintainer:
> headers. When checking my package at win-builder using R-unstable, I
> got a NOTE that Author field differs from that derived from Authors@R:
> 
>>> Author: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [cph], Alexander Semke [cph], Tilman Benkert [cph], Kasper Peeters
>>> [cph], Russell Standish [cph], Ivan Krylov [cre, cph]'
> 
>>> Authors@R: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [con, cph], Alexander Semke [con, cph], Tilman Benkert [con, cph],
>>> Kasper Peeters [con, cph], Russell Standish [con, cph], Ivan Krylov
>>> [cre, cph]'
> 
> Link to full check output:
> https://win-builder.r-project.org/EWz9zWS0niO3/
> 
> The actual field from DESCRIPTION now looks like this:
> 
>>> Authors@R: c(person('Miquel', 'Garriga', email =
>>> 'gbmiq...@gmail.com', role = c('aut', 'cph')), person('Stefan',
>>> 'Gerlach', email = 'stefan.gerl...@uni-konstanz.de', role = c('aut',
>>> 'cph')), person('Ion', 'Vasilief', email = 'ion_vasil...@yahoo.fr',
>>> role = c('aut', 'cph')), person('Alex', 'Kargovsky', email =
>>> 'kargov...@yumr.phys.msu.su', role = c('aut', 'cph')),
>>> person('Knut', 'Franke', email = 'knut.fra...@gmx.de', role =
>>> c('con', 'cph')), person('Alexander', 'Semke', email =
>>> 'alexander.se...@web.de', role = c('con', 'cph')), person('Tilman',
>>> 'Benkert', email = 't...@gmx.net', role = c('con', 'cph')),
>>> person('Kasper', 'Peeters', email = 'kasper.peet...@aei.mpg.de',
>>> role = c('con', 'cph')), person('Russell', 'Standish', role =
>>> c('con', 'cph')), person('Ivan', 'Krylov', email =
>>> 'krylov.r...@gmail.com', role = c('cre', 'cph')))
> 
> The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
> stable, which might explain the differences in utils:::format.person.
> 
> What should I do to avoid the NOTE?
>

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R

[peter dalgaard]

The difference is obviously in the "con" men. The definition of role="con" in 
the MARC code list is

Conservator [con]
A person or organization responsible for documenting, preserving, or treating 
printed or manuscript material, works of art, artifacts, or other media
UF Preservationist

Is this as intended?

-pd

> On 6 Feb 2019, at 13:26 , Ivan Krylov  wrote:
> 
> Hi!
> 
> I'm relying on Authors@R to generate the Author: and Maintainer:
> headers. When checking my package at win-builder using R-unstable, I
> got a NOTE that Author field differs from that derived from Authors@R:
> 
>>> Author: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [cph], Alexander Semke [cph], Tilman Benkert [cph], Kasper Peeters
>>> [cph], Russell Standish [cph], Ivan Krylov [cre, cph]'
> 
>>> Authors@R: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [con, cph], Alexander Semke [con, cph], Tilman Benkert [con, cph],
>>> Kasper Peeters [con, cph], Russell Standish [con, cph], Ivan Krylov
>>> [cre, cph]'
> 
> Link to full check output:
> https://win-builder.r-project.org/EWz9zWS0niO3/
> 
> The actual field from DESCRIPTION now looks like this:
> 
>>> Authors@R: c(person('Miquel', 'Garriga', email =
>>> 'gbmiq...@gmail.com', role = c('aut', 'cph')), person('Stefan',
>>> 'Gerlach', email = 'stefan.gerl...@uni-konstanz.de', role = c('aut',
>>> 'cph')), person('Ion', 'Vasilief', email = 'ion_vasil...@yahoo.fr',
>>> role = c('aut', 'cph')), person('Alex', 'Kargovsky', email =
>>> 'kargov...@yumr.phys.msu.su', role = c('aut', 'cph')),
>>> person('Knut', 'Franke', email = 'knut.fra...@gmx.de', role =
>>> c('con', 'cph')), person('Alexander', 'Semke', email =
>>> 'alexander.se...@web.de', role = c('con', 'cph')), person('Tilman',
>>> 'Benkert', email = 't...@gmx.net', role = c('con', 'cph')),
>>> person('Kasper', 'Peeters', email = 'kasper.peet...@aei.mpg.de',
>>> role = c('con', 'cph')), person('Russell', 'Standish', role =
>>> c('con', 'cph')), person('Ivan', 'Krylov', email =
>>> 'krylov.r...@gmail.com', role = c('cre', 'cph')))
> 
> The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
> stable, which might explain the differences in utils:::format.person.
> 
> What should I do to avoid the NOTE?
> 
> -- 
> Best regards,
> Ivan
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R

[Dirk Eddelbuettel]

On 6 February 2019 at 15:26, Ivan Krylov wrote:
| The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
| stable, which might explain the differences in utils:::format.person.

In case you were unaware you _can_ get current R versions, now R 3.5.2, for
Debian stable thanks to the backports administered by Johannes Ranke -- see
http://cloud.r-project.org/bin/linux/debian/

I see no real reason for a package developer aiming for CRAN to use a
twice-outdated R version.

| What should I do to avoid the NOTE?

I suspect locale and sorting settings but I don't know for sure. In any case,
I would not start by debugging on an outdated R version.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R

[Ivan Krylov]

Hi!

I'm relying on Authors@R to generate the Author: and Maintainer:
headers. When checking my package at win-builder using R-unstable, I
got a NOTE that Author field differs from that derived from Authors@R:

>> Author: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>> [cph], Alexander Semke [cph], Tilman Benkert [cph], Kasper Peeters
>> [cph], Russell Standish [cph], Ivan Krylov [cre, cph]'

>> Authors@R: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>> [con, cph], Alexander Semke [con, cph], Tilman Benkert [con, cph],
>> Kasper Peeters [con, cph], Russell Standish [con, cph], Ivan Krylov
>> [cre, cph]'

Link to full check output:
https://win-builder.r-project.org/EWz9zWS0niO3/

The actual field from DESCRIPTION now looks like this:

>> Authors@R: c(person('Miquel', 'Garriga', email =
>> 'gbmiq...@gmail.com', role = c('aut', 'cph')), person('Stefan',
>> 'Gerlach', email = 'stefan.gerl...@uni-konstanz.de', role = c('aut',
>> 'cph')), person('Ion', 'Vasilief', email = 'ion_vasil...@yahoo.fr',
>> role = c('aut', 'cph')), person('Alex', 'Kargovsky', email =
>> 'kargov...@yumr.phys.msu.su', role = c('aut', 'cph')),
>> person('Knut', 'Franke', email = 'knut.fra...@gmx.de', role =
>> c('con', 'cph')), person('Alexander', 'Semke', email =
>> 'alexander.se...@web.de', role = c('con', 'cph')), person('Tilman',
>> 'Benkert', email = 't...@gmx.net', role = c('con', 'cph')),
>> person('Kasper', 'Peeters', email = 'kasper.peet...@aei.mpg.de',
>> role = c('con', 'cph')), person('Russell', 'Standish', role =
>> c('con', 'cph')), person('Ivan', 'Krylov', email =
>> 'krylov.r...@gmail.com', role = c('cre', 'cph')))

The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
stable, which might explain the differences in utils:::format.person.

What should I do to avoid the NOTE?

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] nlminb with constraints failing on some platforms

[Avraham Adler]

If it helps, the BLAS I used is compiled to use 6 threads.

On Wed, Feb 6, 2019 at 3:47 AM Berend Hasselman  wrote:

>
>
> > On 6 Feb 2019, at 10:58, Martin Maechler 
> wrote:
> >
>
> .
> >
> ---
> >
> > I summarize what has been reported till:
> >
> > Failure in these cases
> > 
> > 1. Kasper K ("Scientific Linux", self compiled R, using Intel's MKL
> >   for BLAS/LAPACK)
> > 2. (By Bill Dunlap): Microsoft R Open (MRO) 3.4.2, also using
> >   MKL with 12 cores
> > 3. (By Brad Bell)  : R 3.5.2 Fedora 28 (x86_64) pkg, OpenBLAS(?)
> > 4. (by MM) : R 3.5.2 Fedora 28 (x86_64) pkg, BLAS+Lapack =
> OpenBLAS
> >
> > Success
> > ===
> >
> > - (by MM): R-devel, R 3.5.2 patched on FC28, *self compiled* gcc
> 8.2,
> >using R's BLAS/Lapack
> > - (by Ralf Stubner): R 3.5.2 from Debian Stable (gcc 6.2) + OpenBLAS
> > - (by Berend H.)   : R 3.5.2 [from CRAN] on macOS 10.14.3 (BLAS/Lapack
> ??)
>
> R 3.5.2 from CRAN using R's BLAS/Lapack.
>
> Berend
>
> 
>
> > It would be great if this could be solved...
> >
> > Martin
> >
> >
> >
> >> I have tried passing in the gradient and turning on the trace and it
> gives nearly the exact same trace with and without the gradient.
> >[...]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] nlminb with constraints failing on some platforms

[Berend Hasselman]

> On 6 Feb 2019, at 10:58, Martin Maechler  wrote:
> 

.
> ---
> 
> I summarize what has been reported till:
> 
> Failure in these cases
> 
> 1. Kasper K ("Scientific Linux", self compiled R, using Intel's MKL
>   for BLAS/LAPACK)
> 2. (By Bill Dunlap): Microsoft R Open (MRO) 3.4.2, also using
>   MKL with 12 cores
> 3. (By Brad Bell)  : R 3.5.2 Fedora 28 (x86_64) pkg, OpenBLAS(?)
> 4. (by MM) : R 3.5.2 Fedora 28 (x86_64) pkg, BLAS+Lapack = OpenBLAS
> 
> Success
> ===
> 
> - (by MM): R-devel, R 3.5.2 patched on FC28, *self compiled* gcc 8.2,
>using R's BLAS/Lapack 
> - (by Ralf Stubner): R 3.5.2 from Debian Stable (gcc 6.2) + OpenBLAS
> - (by Berend H.)   : R 3.5.2 [from CRAN] on macOS 10.14.3 (BLAS/Lapack ??)

R 3.5.2 from CRAN using R's BLAS/Lapack.

Berend



> It would be great if this could be solved...
> 
> Martin
> 
> 
>   
>> I have tried passing in the gradient and turning on the trace and it gives 
>> nearly the exact same trace with and without the gradient.
>[...]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] nlminb with constraints failing on some platforms

[Martin Maechler]

Thank you, Brad (and others),

> Brad Bell on Mon, 4 Feb 2019 07:21:18 -0700 writes:

> I get the failure message. To be specific:

adcomp.git> R CMD BATCH --quiet test_nlminb.R
adcomp.git> cat test_nlminb.Rout
>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>> xhat <- rep(1, 10)
>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] FALSE

ok... [I gave a version of the above which reveals a bit more ...]

> My system is described by:
adcomp.git> uname -a
> Linux localhost.localdomain 4.17.7-200.fc28.x86_64 #1 SMP Tue Jul 17 
16:28:31 UTC 2018 x86_64 x86_64 
> x86_64 GNU/Linux

That (uname -a) is almost only a description of your kernel + hardware
(including of where the kernel was possibly built), and by the
way, almost equivalent to R's

   Sys.info()

In your case, I guess Fedora 28 Linux (which I also use, ..),
but we'd like a bit more information, notably  sessionInfo()

> My version of R is described by:
> Source   : R-3.5.2-2.fc28.src.rpm

The above also is not so informative.
I assume it means this is /usr/bin/R you got as a regular Fedora
package, and the above would actually by one of the output lines
of
   dnf inst /usr/bin/R

Indeed, now when I also try Fedora 28's /usr/bin/R,
I do see the same problem
... and it is *also* *not* using R's own BLAS + LAPACK, but the
OpenBLAS  BLAS+LAPACK combination that comes with Fedora's R, 
 /usr/lib64/R/lib/libRblas.so :

> R.home()
[1] "/usr/lib64/R"
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
List of 6
 $ par: num [1:10] 0.797 0.303 0.285 0.271 0.258 ...
 $ objective  : num -37.7
 $ convergence: int 1
 $ iterations : int 150
 $ evaluations: Named int [1:2] 155 1611
  ..- attr(*, "names")= chr [1:2] "function" "gradient"
 $ message: chr "iteration limit reached without convergence (10)"
> xhat <- rep(1, 10)   # 64b Lnx/Win: -- 32bit even better
> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
[1] "Mean relative difference: 2.233284"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
[1] "Mean relative difference: 0.0979214"
> print(abs(opt$objective- f(xhat) )) < 1e-4 # see 7.53 e-11  [Must be TRUE]
[1] 3.696533
[1] FALSE
> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Fedora 28 (Twenty Eight)

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

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

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

other attached packages:
[1] fortunes_1.5-4 sfsmisc_1.1-3 

loaded via a namespace (and not attached):
[1] compiler_3.5.2 tools_3.5.2   
>
-

And indeed BLAS/LAPACK  is  /usr/lib64/R/lib/libRblas.so
and that is described as

$ dnf info /usr/lib64/R/lib/libRblas.so
Updating  repositories.
Last metadata expiration check: 0:08:10 ago on Wed 06 Feb 2019 09:31:40 AM CET.
Installed Packages
Name : openblas-Rblas
Version  : 0.3.5
Release  : 1.fc28
Arch : x86_64
Size : 39 M
Source   : openblas-0.3.5-1.fc28.src.rpm
Repo : @System
>From repo: updates
Summary  : A version of OpenBLAS for R to use as libRblas
URL  : https://github.com/xianyi/OpenBLAS/
License  : BSD
Description  : 
 : OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD
 : version. The project is supported by the Lab of Parallel 
Software and
 : Computational Science, ISCAS. http://www.rdcps.ac.cn

---

I summarize what has been reported till:

Failure in these cases

1. Kasper K ("Scientific Linux", self compiled R, using Intel's MKL
for BLAS/LAPACK)
2. (By Bill Dunlap): Microsoft R Open (MRO) 3.4.2, also using
MKL with 12 cores
3. (By Brad Bell)  : R 3.5.2 Fedora 28 (x86_64) pkg, OpenBLAS(?)
4. (by MM) : R 3.5.2 Fedora 28 (x86_64) pkg, BLAS+Lapack = OpenBLAS

Success
===

- (by MM)  : R-devel, R 3.5.2 patched on FC28, *self compiled* gcc 8.2,
 using R's BLAS/Lapack 
- (by Ralf Stubner): R 3.5.2 from Debian Stable (gcc 6.2) + OpenBLAS
- (by Berend H.)   : R 3.5.2 [from CRAN] on macOS 10.14.3 (BLAS/Lapack ??)
- (by MM)  : R-devel & R 3.5.2 (from CRAN) on Windows 32-bit & 64-b
- (by Rui Barradas): R 3.5.2 on ubuntu 18.04.1, BLAS/Lapack separate, 
/usr/lib/..
- (by Oliver Dechant)R 3.5.2 on