Re: [R-pkg-devel] What to do when a package is archived from CRAN

[Tim Taylor]

Could you have been caught out with the precompiled binary that serde started 
distributing in a few of it’s versions 
(https://github.com/serde-rs/serde/issues/2538)? That could have been a reason 
if you pinned a version with it present but only CRAN could confirm if that was 
the reason.

Tim

> On 26 Aug 2023, at 22:22, Ivan Krylov  wrote:
> 
> On Sat, 26 Aug 2023 11:46:44 +0900
> SHIMA Tatsuya  wrote:
> 
>> I noticed that my submitted package `prqlr` 0.5.0 was archived from
>> CRAN on 2023-08-19.
>> 
>> 
>> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only 
>> received word from CRAN that it passed the automated release process. 
> 
> Sarah gave a good guess (although there are CRAN packages containing
> C++ and Rust code with NOTEs about size of their libs, 18.2Mb is still
> a lot), though I do find it strange that you didn't receive anything
> from CRAN prior to having your package archived. I don't think I ever
> had problems with e-mails being delivered from CRAN to GMail, but we
> can't rule that out.
> 
> You've obviously made an effort to follow the Rust policy, and I don't
> see any obvious problems with this part of the package, although I
> haven't tried it myself to verify the installation working offline from
> bundled source code.
> 
> You've also made an effort to list all the authors of the code
> comprising your package in inst/AUTHORS, which is the right thing to do
> to avoid making the list of authors in DESCRIPTION long enough to be
> unreadable.
> 
> You licensed the package as MIT. Are your dependencies compatible with
> MIT? All direct dependencies of your Rust code seem to be licensed
> under either MIT or Apache-2.0, which seems to be compatible. You named
> the copyright holder of your package as "prqlr authors", which may be a
> problem. (I think I saw it somewhere that for MIT license, CRAN prefers
> the copyright holder to be some kind of legal entity: either the legal
> name of a person, or a company, or something like that.)
> 
> Could the Rust code or any of the dependencies accidentally write under
> the user's home directory or take over the terminal or something like
> that?
> 
> We might need a response from CRAN after all.
> 
> -- 
> Best regards,
> Ivan
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[SHIMA Tatsuya]

Sarah,

Thanks for taking a look at this.
But what we see in the results page is the compiled size, and I think it 
is common for it to be huge.

For example, looking at the arrow package 12.0.1.1 
>, the size of the lib seems 
to be 41MB.

Indeed, the size of the first submission of prqlr 0.5.0, which vendored 
all dependent crates, was 12 MB, which of course was not accepted by CRAN.
The second submission, which was eventually accepted, was submitted with 
the vendored tarballs removed, so the source package was smaller.
(By the way, I wrote the following comment when I submitted the second 
time I removed the tarball, which I thought asked for explicit 
permission to download, but I don't know if that was actually read by 
CRAN. 
)

Best,
Tatsuya

On 2023/08/27 5:29, Sarah Goslee wrote:
> Hi,
>
> You can generally see what the reason is from the archive page, where it says:
> A summary of the most recent check results can be obtained from the
> check results archive.
>
> On that 
> page,https://cran-archive.r-project.org/web/checks/2023/2023-08-19_check_results_prqlr.html
> is the note:
>
> Version: 0.5.0
> Check: installed package size
> Result: NOTE
>   installed size is 18.5Mb
>   sub-directories of 1Mb or more:
>   libs 18.2Mb
>
> This is too big for CRAN, see
> https://cran.r-project.org/web/packages/policies.html  quoted here:
>
> Packages should be of the minimum necessary size. Reasonable
> compression should be used for data (not just .rda files) and PDF
> documentation: CRAN will if necessary pass the latter through qpdf.
>
> As a general rule, neither data nor documentation should exceed 5MB
> (which covers several books). A CRAN package is not an appropriate way
> to distribute course notes, and authors will be asked to trim their
> documentation to a maximum of 5MB.
>
> Where a large amount of data is required (even after compression),
> consideration should be given to a separate data-only package which
> can be updated only rarely (since older versions of packages are
> archived in perpetuity).
>
> Similar considerations apply to other forms of “data”, e.g., .jar files.
>
> Source package tarballs should if possible not exceed 10MB. It is much
> preferred that third-party source software should be included within
> the package (as e.g. a vendor.tar.xz file) than be downloaded at
> installation: if this requires a larger tarball a modestly increased
> limit can be requested at submission.
>
> Sarah
>
> On Sat, Aug 26, 2023 at 4:26 PM SHIMA Tatsuya  wrote:
>> Hi,
>>
>> I noticed that my submitted package `prqlr` 0.5.0 was archived from CRAN
>> on 2023-08-19.
>> 
>>
>> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only
>> received word from CRAN that it passed the automated release process.
>> 
>> So I was very surprised to find out after I returned from my trip that
>> this was archived.
>>
>> The CRAN page says "Archived on 2023-08-19 for policy violation. " but I
>> don't know what exactly was the problem.
>> I have no idea what more to fix as I believe I have solved all the
>> problems when I submitted 0.5.0.
>>
>> Is there any way to know what exactly was the problem?
>> (I thought I sent an e-mail to CRAN 5 days ago but have not yet received
>> an answer, so I decided to ask my question on this mailing list,
>> thinking that there is a possibility that there will be no answer to my
>> e-mail, although I may have to wait a few weeks for an answer. My
>> apologies if this idea is incorrect.)
>>
>> Best,
>> Tatsuya
>>
>> __
>> R-package-devel@r-project.org  mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[SHIMA Tatsuya]

Simon,

Thank you for taking a look at this.

 > One related issue with respect to CRAN policies that I don't see a 
good solution for is that inst/AUTHORS is patently unhelpful, because 
most of them say "foo (version ..): foo authors" with no contact, or 
real names or any links.

I understand your thoughts, but if we look for the inst/AUTHOURS files 
contained in the packages on CRAN, I don't think they always contain the 
contact information.
For example, this is from the igraph package.


Also, I have listed the URLs of the dependent crates (the `repository` 
field of Cargo.toml) in the LICENSE.note file, so we can see where the 
dependent crates are being developed.

Best,
Tatsuya

On 2023/08/27 14:36, Hiroaki Yutani wrote:
> Simon,
>
> Ok, let's take a look at a real example. The first item of 
> inst/AUTHORS of prqlr (GitHub version) is this:
>
>     addr2line (version 0.20.0):
>       addr2line authors
>
> You can find addr2line's owners on crates.io  [1], 
> while its manifest file (Cargo.toml) [2] doesn't contain the names of 
> its owners or authors. In Rust's manifest, the "authors" field is 
> optional [3] unlike R. You might argue "owners" is not the same as 
> "authors," but at least crates.io  provides the 
> names of those who are responsible for the crate.
>
> Let's go back to your question.
>
> > So are you saying you have to use crates.io  and 
> do some extra step during the (misnamed) "vendor" step?
>
> "cargo vendor" doesn't take care of generating the list of authors, so 
> it's not "during the vender step." It has to be done separately 
> anyway. I was just saying you **can** use crates.io  
> in that step instead of searching for the authors manually one by one 
> (or filling it with "foo authors" when the manifest file doesn't 
> contain any names).
>
> That said, I agree with you in general that the Rust community is 
> relatively loose about authorship and licensing when compared with R. 
> I don't think it's necessarily a problem, but the impedance mismatch 
> is a headache. I was just trying to point out this part of your opinion
>
> > the Rust community as there doesn't seem to be any accountability 
> with respect to ownership and attribution.
>
> was not quite true. I hope the R community and the Rust community have 
> respect for each other.
>
> Best,
> Yutani
>
> [1]: https://crates.io/crates/addr2line
> [2]: https://github.com/gimli-rs/addr2line/blob/0.20.0/Cargo.toml
> [3]: 
> https://doc.rust-lang.org/cargo/reference/manifest.html#the-authors-field
>
>
> 2023年8月27日(日) 12:07 Simon Urbanek :
>
> Yutani,
>
>
>> On Aug 27, 2023, at 2:19 PM, Hiroaki Yutani
>>  wrote:
>>
>> Simon,
>>
>> > it's assumed that GitHub history is the canonical source with
>> the provenance, but that gets lost when pulled into the package.
>>
>> No, not GitHub. You can usually find the ownership on crates.io
>> . So, if you want a target to blame, it's
>> probably just a problem of the script to auto-generate
>> inst/AUTHORS in this specific case. But, clearly, Rust's
>> ecosystem works soundly under the existence of crates.io
>> , so I think this is the same kind of pain
>> which you would feel if you use R without CRAN.
>>
>
> Can you elaborate? I have not found anything that would have a
> list of authors in the sources. I fully agree that I know nothing
> about it, but even if you use R without CRAN, each package
> contains that information in the DESCRIPTION file since it's so
> crucial. So are you saying you have to use crates.io
>  and do some extra step during the (misnamed)
> "vendor" step? (I didn't see the submitted tar ball of plqrl and
> its release on GitHub is not the actual package so can't check -
> thus just trying reverse-engineer what happens by looking at the
> dependencies which leads to GitHub).
>
>
>> Sorry for nitpicking.
>>
>
> Sure, good to get the fact straight.
>
> Cheers,
> Simon
>
>
>
>> Best,
>> Yutani
>>
>> 2023年8月27日(日) 6:57 Simon Urbanek :
>>
>> Tatsuya,
>>
>> What you do is contact CRAN. I don't think anyone here can
>> answer your question, only CRAN can, so ask there.
>>
>> Generally, packages with sufficiently many Rust dependencies
>> have to be handled manually as they break the size limit, so
>> auto-rejections are normal. Archival is unusual, but it may
>> have fallen through the cracks - but the way to find out is
>> to ask.
>>
>> One related issue with respect to CRAN policies that I don't
>> see a good solution for is that inst/AUTHORS is patently
>> unhelpful, because most of them say "foo (version ..): foo
>> authors" with

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[SHIMA Tatsuya]

Hi Ivan, thanks for taking the time to look at all the details of this.

 > You licensed the package as MIT. Are your dependencies compatible 
with MIT? All direct dependencies of your Rust code seem to be licensed 
under either MIT or Apache-2.0, which seems to be compatible.

I am not a legal expert, but as you have seen all of prqlr's dependent crates 
are compatible with the MIT license, and I interpret this to mean that there is 
no problem distributing anything containing them under the MIT license.

 > You named the copyright holder of your package as "prqlr authors", 
which may be a problem. (I think I saw it somewhere that for MIT 
license, CRAN prefers the copyright holder to be some kind of legal 
entity: either the legal name of a person, or a company, or something 
like that.)

I believe some popular R packages (e.g. dplyr) use this notation.

In the first submission of prqlr 0.5.0, CRAN pointed out that the role 
of "The authors of the dependency Rust crates" should be changed to 
author, but nothing else was pointed out.

Best,
Tatsuya

On 2023/08/27 6:22, Ivan Krylov wrote:
> On Sat, 26 Aug 2023 11:46:44 +0900
> SHIMA Tatsuya  wrote:
>
>> I noticed that my submitted package `prqlr` 0.5.0 was archived from
>> CRAN on 2023-08-19.
>> 
>>
>> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only
>> received word from CRAN that it passed the automated release process.
> Sarah gave a good guess (although there are CRAN packages containing
> C++ and Rust code with NOTEs about size of their libs, 18.2Mb is still
> a lot), though I do find it strange that you didn't receive anything
> from CRAN prior to having your package archived. I don't think I ever
> had problems with e-mails being delivered from CRAN to GMail, but we
> can't rule that out.
>
> You've obviously made an effort to follow the Rust policy, and I don't
> see any obvious problems with this part of the package, although I
> haven't tried it myself to verify the installation working offline from
> bundled source code.
>
> You've also made an effort to list all the authors of the code
> comprising your package in inst/AUTHORS, which is the right thing to do
> to avoid making the list of authors in DESCRIPTION long enough to be
> unreadable.
>
> You licensed the package as MIT. Are your dependencies compatible with
> MIT? All direct dependencies of your Rust code seem to be licensed
> under either MIT or Apache-2.0, which seems to be compatible. You named
> the copyright holder of your package as "prqlr authors", which may be a
> problem. (I think I saw it somewhere that for MIT license, CRAN prefers
> the copyright holder to be some kind of legal entity: either the legal
> name of a person, or a company, or something like that.)
>
> Could the Rust code or any of the dependencies accidentally write under
> the user's home directory or take over the terminal or something like
> that?
>
> We might need a response from CRAN after all.
>
[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[SHIMA Tatsuya]

Hi Tim, thank you for sharing this information. i didn't know this.

If this is the cause, the problem seems to have been resolved in the 
latest serde , so it seems 
to be possible to deal with it.


Best,
Tatsuya

On 2023/08/27 20:24, Tim Taylor wrote:
Could you have been caught out with the precompiled binary that serde 
started distributing in a few of it’s versions 
(https://github.com/serde-rs/serde/issues/2538)? That could have been 
a reason if you pinned a version with it present but only CRAN could 
confirm if that was the reason.


Tim


On 26 Aug 2023, at 22:22, Ivan Krylov  wrote:

On Sat, 26 Aug 2023 11:46:44 +0900
SHIMA Tatsuya  wrote:


I noticed that my submitted package `prqlr` 0.5.0 was archived from
CRAN on 2023-08-19.


I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only
received word from CRAN that it passed the automated release process.


Sarah gave a good guess (although there are CRAN packages containing
C++ and Rust code with NOTEs about size of their libs, 18.2Mb is still
a lot), though I do find it strange that you didn't receive anything
from CRAN prior to having your package archived. I don't think I ever
had problems with e-mails being delivered from CRAN to GMail, but we
can't rule that out.

You've obviously made an effort to follow the Rust policy, and I don't
see any obvious problems with this part of the package, although I
haven't tried it myself to verify the installation working offline from
bundled source code.

You've also made an effort to list all the authors of the code
comprising your package in inst/AUTHORS, which is the right thing to do
to avoid making the list of authors in DESCRIPTION long enough to be
unreadable.

You licensed the package as MIT. Are your dependencies compatible with
MIT? All direct dependencies of your Rust code seem to be licensed
under either MIT or Apache-2.0, which seems to be compatible. You named
the copyright holder of your package as "prqlr authors", which may be a
problem. (I think I saw it somewhere that for MIT license, CRAN prefers
the copyright holder to be some kind of legal entity: either the legal
name of a person, or a company, or something like that.)

Could the Rust code or any of the dependencies accidentally write under
the user's home directory or take over the terminal or something like
that?

We might need a response from CRAN after all.

--
Best regards,
Ivan

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


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

[R-pkg-devel] package submissions no auto-processed message

[John Harrold]

Howdy Folks,

I submitted a package on Friday. I got the normal email where you have to
click on the link to confirm. Then I got an email saying that the package
was uploaded. Normally after that I get an email saying the package was
auto-processed. That generally doesn't take very long (typically less than
an hour). I wanted to know if there was something on the backend that was
causing a delay, or if there was something wrong and I needed to resubmit
it.

Thank you,
John
:wq

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] package submissions no auto-processed message

[Uwe Ligges]

On 27.08.2023 22:51, John Harrold wrote:

Howdy Folks,

I submitted a package on Friday. I got the normal email where you have to
click on the link to confirm. Then I got an email saying that the package
was uploaded. Normally after that I get an email saying the package was
auto-processed. That generally doesn't take very long (typically less than
an hour). I wanted to know if there was something on the backend that was
causing a delay, or if there was something wrong and I needed to resubmit
it.


Not that I know. If you told us which package this is about ...

Best,
Uwe Ligges






Thank you,
John
:wq

[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] package submissions no auto-processed message

[Lluís Revilla]

Hi,

Are you referring to your package formods?
I see it was released the same Friday 17 and it is already on CRAN.

If this is not the package, it might be on the backlog of packages
submitted to CRAN.
You can check the queue at:
https://r-hub.github.io/cransays/articles/dashboard.html

Best,

Lluís


On Sun, 27 Aug 2023 at 23:16, John Harrold  wrote:

> Howdy Folks,
>
> I submitted a package on Friday. I got the normal email where you have to
> click on the link to confirm. Then I got an email saying that the package
> was uploaded. Normally after that I get an email saying the package was
> auto-processed. That generally doesn't take very long (typically less than
> an hour). I wanted to know if there was something on the backend that was
> causing a delay, or if there was something wrong and I needed to resubmit
> it.
>
> Thank you,
> John
> :wq
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] package submissions no auto-processed message

[Uwe Ligges]

Thanks.This was pending a manual inspection for newbies (packages). 
ALthough, we also have no mail with test results (I guess a CRAN 
server's mail issue when this hot checked), so I just triggered new checks.


Best,
Uwe Ligges



On 28.08.2023 00:37, John Harrold wrote:

Oh I'm sorry. It's the ruminate package.

On Sun, Aug 27, 2023 at 2:22 PM Uwe Ligges 
> wrote:




On 27.08.2023 22:51, John Harrold wrote:
 > Howdy Folks,
 >
 > I submitted a package on Friday. I got the normal email where you
have to
 > click on the link to confirm. Then I got an email saying that the
package
 > was uploaded. Normally after that I get an email saying the
package was
 > auto-processed. That generally doesn't take very long (typically
less than
 > an hour). I wanted to know if there was something on the backend
that was
 > causing a delay, or if there was something wrong and I needed to
resubmit
 > it.

Not that I know. If you told us which package this is about ...

Best,
Uwe Ligges




 >
 > Thank you,
 > John
 > :wq
 >
 >       [[alternative HTML version deleted]]
 >
 > __
 > R-package-devel@r-project.org
 mailing list
 > https://stat.ethz.ch/mailman/listinfo/r-package-devel




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

Re: [R-pkg-devel] package submissions no auto-processed message

[John Harrold]

Oh I'm sorry. It's the ruminate package.

On Sun, Aug 27, 2023 at 2:22 PM Uwe Ligges 
wrote:

>
>
> On 27.08.2023 22:51, John Harrold wrote:
> > Howdy Folks,
> >
> > I submitted a package on Friday. I got the normal email where you have to
> > click on the link to confirm. Then I got an email saying that the package
> > was uploaded. Normally after that I get an email saying the package was
> > auto-processed. That generally doesn't take very long (typically less
> than
> > an hour). I wanted to know if there was something on the backend that was
> > causing a delay, or if there was something wrong and I needed to resubmit
> > it.
>
> Not that I know. If you told us which package this is about ...
>
> Best,
> Uwe Ligges
>
>
>
>
> >
> > Thank you,
> > John
> > :wq
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [Rd] R packages to send plottable data to external apps

[Iñaki Ucar]

I think r-package-devel is a better place for this. CC'ing there.

On Sun, 27 Aug 2023 at 23:50, Mike Marchywka  wrote:
>
> I was curious what R packages, or indeed any other applications, exist
> to plot streamed data from arbitrary data generators. It need not
> be publication quality plotting but it should be easy to use  like
> an oscilloscope.

The last time I checked, there wasn't any R package suitable for
plotting high-throughput streaming data.

There's a nice command-line utility called trend [1] that I
extensively used in the past as an oscilloscope to visualize the
output from a DAQ card. I don't see any new development there, but it
does exactly what it promises; it's easy to use, quite configurable
and very fast. Old but gold.

I also explored VisPy, which is much more ambitious, but at that time
the API had a limitation that didn't allow me to achieve what I
required, and I haven't looked at it ever since, but the project seems
in good shape.

[1] https://www.thregr.org/wavexx/software/trend/
[2] https://vispy.org/

Hope it helps,
Iñaki

> I was working on something called datascope that I
> am using for 1D finite difference monitoring and recently interfaced it
> to freefem. I also created an R package. If there is any interest in something
> like this I guess I could put it up somewhere when it is more usable
> or if you can suggest some similar popular packages that would be good
> too. Is there something I could drop-in to the attached code and get
> something like the attached output that could also be switched to other
> data sources?  This right now works via linux fifo and somewhat by UDP.
> It can queue data and stop making it if no one seems to be  consuming
> it depending on the channel.
>
> Thanks.
>
>  Mike Marchywka
> 44 Crosscreek Trail
> Jasper GA 30143
> was 306 Charles Cox Drive  Canton, GA 30115
> 470-758-0799
> 404-788-1216
>
>
> __
> r-de...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Iñaki Úcar

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

Re: [R-pkg-devel] package submissions no auto-processed message

[John Harrold]

I got it. Thanks Uwe.

On Sun, Aug 27, 2023 at 4:05 PM Uwe Ligges 
wrote:

> Thanks.This was pending a manual inspection for newbies (packages).
> ALthough, we also have no mail with test results (I guess a CRAN
> server's mail issue when this hot checked), so I just triggered new checks.
>
> Best,
> Uwe Ligges
>
>
>
> On 28.08.2023 00:37, John Harrold wrote:
> > Oh I'm sorry. It's the ruminate package.
> >
> > On Sun, Aug 27, 2023 at 2:22 PM Uwe Ligges
> >  > > wrote:
> >
> >
> >
> > On 27.08.2023 22:51, John Harrold wrote:
> >  > Howdy Folks,
> >  >
> >  > I submitted a package on Friday. I got the normal email where you
> > have to
> >  > click on the link to confirm. Then I got an email saying that the
> > package
> >  > was uploaded. Normally after that I get an email saying the
> > package was
> >  > auto-processed. That generally doesn't take very long (typically
> > less than
> >  > an hour). I wanted to know if there was something on the backend
> > that was
> >  > causing a delay, or if there was something wrong and I needed to
> > resubmit
> >  > it.
> >
> > Not that I know. If you told us which package this is about ...
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> >
> >  >
> >  > Thank you,
> >  > John
> >  > :wq
> >  >
> >  >   [[alternative HTML version deleted]]
> >  >
> >  > __
> >  > R-package-devel@r-project.org
> >  mailing list
> >  > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > 
> >
>

[[alternative HTML version deleted]]

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