Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons

[Spencer Graves]

On 11/2/23 2:52 PM, Rolf Turner wrote:


On Wed, 1 Nov 2023 16:10:34 +
David Hugh-Jones  wrote:


Aside from the package question, surely the other issue here is that
Prof Ripley’s email is extraordinarily rude. Any paid employee would
be sacked for that. I appreciate R and CRAN are volunteer-run
organisations, but I don’t think that should be an excuse for this
level of, frankly, toxicity. Why is he allowed to get away with it?

David


I've just had a look at the initial posting in this thread

https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009810.html

and can see nothing rude or offensive in the email from Prof. Ripley
that was copied and pasted into that posting.

I find *your* email far more offensive than anything that Prof. Ripley
has ever written.  Get a life.

cheers,

Rolf Turner

P.S.  See fortunes::fortune(88).

R. T.



Hi, David:


	  You do, of course, know that "Ripley" is a verb? People on this list 
take pride in how many times they've been Ripleyed ;-)



	  I've been in the military, and I've learned to ignore the tone and 
look for the value in comments I receive. I've learned a lot from 
Professor Ripley, and others. When the tone seemed less supportive or 
even insulting, I'm very glad the person took the time to comment and 
didn't decide not to reply for fear of offending me. I'm more productive 
and a better human for all the help I've gotten from this and other 
R-related lists.



fortunes::fortune('Spencer Graves')


  sg




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

Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons

[Rolf Turner]

On Wed, 1 Nov 2023 16:10:34 +
David Hugh-Jones  wrote:

> Aside from the package question, surely the other issue here is that
> Prof Ripley’s email is extraordinarily rude. Any paid employee would
> be sacked for that. I appreciate R and CRAN are volunteer-run
> organisations, but I don’t think that should be an excuse for this
> level of, frankly, toxicity. Why is he allowed to get away with it?
> 
> David

I've just had a look at the initial posting in this thread

https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009810.html

and can see nothing rude or offensive in the email from Prof. Ripley
that was copied and pasted into that posting.

I find *your* email far more offensive than anything that Prof. Ripley
has ever written.  Get a life.

cheers,

Rolf Turner

P.S.  See fortunes::fortune(88).

R. T.

-- 
Honorary Research Fellow
Department of Statistics
University of Auckland
Stats. Dep't. (secretaries) phone:
 +64-9-373-7599 ext. 89622
Home phone: +64-9-480-4619

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

Re: [R-pkg-devel] Matrix and Mac OS

[Mikael Jagan]

A hack that seems to work is (whitespace added for readability):

\newcommand{\Seqn}{
  \ifelse{latex}{
\Sexpr[results=rd]{if (getRversion() < "4.2.2") "eqn{#1}" else 
"eqn{#2}"}

  }{
\ifelse{html}{
  \Sexpr[results=rd]{if (getRversion() < "4.2.0") "eqn{#1}" 
else "eqn{#2}"}

}{
  \Sexpr[results=rd]{"eqn{#2}"}
}
  }
}

as amsmath support for PDF output and KaTeX support for HTML output
were introduced in R 4.2.2 and 4.2.0, respectively.

Sadly I really do seem to need 8 escapes:

\Seqn{text{min}(m,n) times n}{min(m,n)-by-n}

Maybe one of the Rd experts here can suggest an improvement ...

Mikael

On 2023-11-01 5:06 am, Martin Maechler wrote:

Uwe Ligges
 on Wed, 1 Nov 2023 06:26:23 +0100 writes:


 > On 01.11.2023 03:51, Mikael Jagan wrote:
 >> Thanks.  It seems that we were mistaken in our feeling (IIRC) that it 
would
 >> be "OK" to implicitly require '--no-manual' on versions of R from 3.5.0 
to
 >> 4.2.1, not changing our Depends.
 >>
 >> We will fix this in Matrix 1.6-2, probably by conditionalizing or 
otherwise
 >> replacing the amsmath commands and probably _not_ by changing to depend 
on
 >> R >= 4.2.2.  Martin may have more to say in "the morning".

I agree (*not* to raise Matrix pkg's R version dependency).

 > Note that dependin on R >= 4.2.2 does not work. We need dependencies of
 > the form R >= x.y.0. This is also part of the checks.

Yes, indeed.
And as we learned, R >= 4.2.0 would not help for r-oldrel-macos

I (am unhappy but) agree to take the responsibility for our
decision to go ahead and use much nicer LaTeX formula for
matrices etc, in our help pages {thinking that indeed people who'd
install Matrix on an old R version would always be able to read
Matrix manual pages via web search (as it seems to me 95% of
people do nowadays) ... or then have someone in their
organization to figure out how to use a newer amsmath (latex) package if
  they really really want the Matrix pdf manual offline}.

Martin

 > Reason is that we have only one binary repository for one R-x.y.?
 > series. On WIndows, where we check with R-4.2.3, a binary would be
 > created and hence R-4.2.[0-1] would not see any valid Matrix binaries.

 > So please either make this work on R >= 4.2.0 or require R >= 4.3.0. If
 > the latter, ideally with an interim version that works for R >= 4.2.0,
 > so that we valid binaries with correct dependency declarations again.

 > Best,
 > Uwe

 >> In the mean time (i.e., while we are stuck with Matrix 1.6-1.1), it may
 >> help
 >> to update to R 4.2.3 on r-oldrel-macos-* and/or to have EdSurvey revert 
its
 >> strict version requirement, unless there are clear examples justifying 
one.
 >>
 >> Mikael
 >>
 >>
 >> On 2023-10-31 8:17 pm, Simon Urbanek wrote:
 >>> Mikael,
 >>>
 >>> in that case I think your requirements are wrong - Matrix says R >=
 >>> 3.5.0 which is apparently incorrect - from what you say it should be
 >>> 4.2.2?. I can certainly update to 4.2.3 if necessary.
 >>>
 >>> Cheers,
 >>> Simon
 >>>
 >>>
 >>>
  On 1/11/2023, at 9:19 AM, Mikael Jagan  wrote:
 
  Thanks.  We did see those ERRORs, stemming from use (since Matrix 
1.6-0)
  of amsmath commands in Rd files.  These have been supported since R
  4.2.2,
  but r-oldrel-macos-* (unlike r-oldrel-windows-*) continues to run R
  4.2.0.
  My expectation was that those machines would begin running R >= 4.2.2
  well
  before the R 4.4.0 release, but apparently that was wrong.
 
  I am hesitant to complicate our Rd files with conditions on R versions
  only to support PDF output for R < 4.2.2, but maybe we can consider it
  for the Matrix 1.6-2 release if it is really a barrier for others ...
 
  Mikael
 
  On 2023-10-31 3:33 pm, Simon Urbanek wrote:
 > Mikael,
 > current Matrix fails checks on R-oldrel so that's why only the last
 > working version is installed:
 > https://cran.r-project.org/web/checks/check_results_Matrix.html
 > Cheers,
 > Simon

On 1/11/2023, at 4:05 AM, Mikael Jagan  wrote:

 >>

I am guessing that they mean EdSurvey:

 >>

     https://cran.r-project.org/web/checks/check_results_EdSurvey.html

 >>

Probably Matrix 1.6-1.1 is not installed on r-oldrel-macos-arm64,
even though it can be, because it was not released until R 4.3-z.

 >>

AFAIK, methods for 'qr' have not been touched since Matrix 1.6-0, and
even those changes should have been backwards compatible, modulo
handling
of dimnames (class sparseQR gained a Dimnames slot in 1.6-0).

 >>

So I don't see a clear reason for requiring 1.6-1.1. 

Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons

[David Hugh-Jones]

Aside from the package question, surely the other issue here is that Prof
Ripley’s email is extraordinarily rude. Any paid employee would be sacked
for that. I appreciate R and CRAN are volunteer-run organisations, but I
don’t think that should be an excuse for this level of, frankly, toxicity.
Why is he allowed to get away with it?

David

On Wed, 1 Nov 2023 at 11:15, Alberto Garre  wrote:

> Dear community,
>
> I feel dismay for having to write this email, but the issue must be brought
> up. On the 20th of October, I received an email from CRAN warning me of an
> issue with one of the packages I maintain (bioOED). The package depended on
> MEIGOR, a package that was no longer available in Bioconductor. I was given
> until 2023-11-03 to fix the issue.
>
> I contacted the MEIGOR maintainers and they told me they were migrating to
> CRAN. Yesterday, they contacted me again, telling me they needed more time
> for the migration. Hence, I responded to the email I received from CRAN,
> asking for an extension of the previous deadline (2023-11-03).
>
> To my surprise, it is not just that the extension was not granted, but the
> package has been removed from CRAN today (2023-11-01). Two days before the
> deadline (2023-11-03): https://cran.r-project.org/package=bioOED
>
> Then, I checked my inbox and I saw an email from one of the CRAN
> maintainers, showing that the package was removed because he had felt
> offended by my email. I copy-paste the email below.
>
> I understand that maintaining CRAN must be a huge work. I also work in
> academia, so I am totally aware of all the extra work that is required from
> us. But it is unreasonable that a package can be removed just because a
> maintainer throws a tantrum
>
> Again, I am really sorry I had to write this email, but CRAN cannot work if
> we allow this type of situation.
>
> Kind regards,
> Alberto Garre
>
> ## Mail from rip...@stats.ox.ac.uk on 2023-11-01 8:28
>
> On 31/10/2023 17:21, Alberto Garre wrote:
> > Dear Brian,
>
> Do be respectful whoever you are (you lack the manners to use a
> signature block but send HTML when you agreed not to!).  What exactly
> have you done for me that would allow you treat me as if I were your peer?
>
> Your ingratitude (for CRAN and R) is deafening.
>
> > I have talked to the MEIGOR developers and they need a bit more time to
> > update their package. Would it be possible to get a 4 weeks extension for
> > the update of bioOED?
>
> No one can even install it in current R, so it has been removed.
>
> "The time of the volunteers is CRAN’s most precious resource"
>
> Professor Ripley
>
> >
> > Thank you very much,
> > Alberto
> >
> >
> > El vie, 20 oct 2023 a las 9:24, Alberto Garre ( >)
> > escribió:
> >
> >> Thank you very much, Brian.
> >>
> >> I have just contacted the developers of MEIGOR because I think they were
> >> planning a migration to CRAN. I will update the package asap.
> >>
> >> Best,
> >> Alberto
> >>
> >>
> >> El vie, 20 oct 2023 a las 9:22, Prof Brian Ripley (<
> rip...@stats.ox.ac.uk
> >)
> >> escribió:
> >>
> >>> On 20/10/2023 08:17, Prof Brian Ripley wrote:
>  Dear maintainer,
> 
>  Please see the problems shown on
>  .
> 
>  Please correct before 2023-11-03 to safely retain your package on
> CRAN.
> 
>  The CRAN Team
> 
> >>> This requires package MEIGOR which is not part of BioC 3.18 and has
> been
> >>> deprecated so it very unlikely to be part of the final release next
> week.
> >>>
> >>>
> >>> --
> >>> Brian D. Ripley,  rip...@stats.ox.ac.uk
> >>> Emeritus Professor of Applied Statistics, University of Oxford
> >>>
> >>>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Writing: wyclif.substack.com
Book: www.wyclifsdust.com

[[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] Matrix and Mac OS

[Mikael Jagan]

On 2023-11-01 12:59 pm, Mikael Jagan wrote:

A hack that seems to work is (whitespace added for readability):

  \newcommand{\Seqn}{
\ifelse{latex}{
  \Sexpr[results=rd]{if (getRversion() < "4.2.2") "eqn{#1}" else
"eqn{#2}"}
}{
  \ifelse{html}{
\Sexpr[results=rd]{if (getRversion() < "4.2.0") "eqn{#1}"
else "eqn{#2}"}
  }{
\Sexpr[results=rd]{"eqn{#2}"}
  }
}
  }


Er, the above is wrong, because '<' should be '>=' and because '#2' (which
is conceptually verbatim text) should use \verb{} for PDF and HTML output,
not \eqn{}.  For Matrix 1.6-2 I have created man/macros/local.Rd and added:

\newcommand{\Seqn}{\ifelse{latex}{\Sexpr[results=rd]{if (getRversion() >= 
"4.2.2") "eqn{#1}" else 
"verb{#2}"}}{\ifelse{html}{\Sexpr[results=rd]{if (getRversion() >= 
"4.2.0") "eqn{#1}" else 
"verb{#2}"}}{\Sexpr[results=rd]{"eqn{#2}"


\newcommand{\Sdeqn}{\ifelse{latex}{\Sexpr[results=rd]{if (getRversion() >= 
"4.2.2") "deqn{#1}" else 
"preformatted{#2}"}}{\ifelse{html}{\Sexpr[results=rd]{if (getRversion() 
>= "4.2.0") "deqn{#1}" else 
"preformatted{#2}"}}{\Sexpr[results=rd]{"deqn{#2}"


Now Matrix 1.6-2 passes its Rd checks under my checkout of R-3-5-branch.
Some examples and tests fail for unrelated reasons.  I'll fix those, too ...

Mikael



as amsmath support for PDF output and KaTeX support for HTML output
were introduced in R 4.2.2 and 4.2.0, respectively.

Sadly I really do seem to need 8 escapes:

  \Seqn{text{min}(m,n) times n}{min(m,n)-by-n}

Maybe one of the Rd experts here can suggest an improvement ...

Mikael

On 2023-11-01 5:06 am, Martin Maechler wrote:

Uwe Ligges
  on Wed, 1 Nov 2023 06:26:23 +0100 writes:


  > On 01.11.2023 03:51, Mikael Jagan wrote:
  >> Thanks.  It seems that we were mistaken in our feeling (IIRC) that it 
would
  >> be "OK" to implicitly require '--no-manual' on versions of R from 
3.5.0 to
  >> 4.2.1, not changing our Depends.
  >>
  >> We will fix this in Matrix 1.6-2, probably by conditionalizing or 
otherwise
  >> replacing the amsmath commands and probably _not_ by changing to 
depend on
  >> R >= 4.2.2.  Martin may have more to say in "the morning".

I agree (*not* to raise Matrix pkg's R version dependency).

  > Note that dependin on R >= 4.2.2 does not work. We need dependencies of
  > the form R >= x.y.0. This is also part of the checks.

Yes, indeed.
And as we learned, R >= 4.2.0 would not help for r-oldrel-macos

I (am unhappy but) agree to take the responsibility for our
decision to go ahead and use much nicer LaTeX formula for
matrices etc, in our help pages {thinking that indeed people who'd
install Matrix on an old R version would always be able to read
Matrix manual pages via web search (as it seems to me 95% of
people do nowadays) ... or then have someone in their
organization to figure out how to use a newer amsmath (latex) package if
   they really really want the Matrix pdf manual offline}.

Martin

  > Reason is that we have only one binary repository for one R-x.y.?
  > series. On WIndows, where we check with R-4.2.3, a binary would be
  > created and hence R-4.2.[0-1] would not see any valid Matrix binaries.

  > So please either make this work on R >= 4.2.0 or require R >= 4.3.0. If
  > the latter, ideally with an interim version that works for R >= 4.2.0,
  > so that we valid binaries with correct dependency declarations again.

  > Best,
  > Uwe

  >> In the mean time (i.e., while we are stuck with Matrix 1.6-1.1), it may
  >> help
  >> to update to R 4.2.3 on r-oldrel-macos-* and/or to have EdSurvey 
revert its
  >> strict version requirement, unless there are clear examples justifying 
one.
  >>
  >> Mikael
  >>
  >>
  >> On 2023-10-31 8:17 pm, Simon Urbanek wrote:
  >>> Mikael,
  >>>
  >>> in that case I think your requirements are wrong - Matrix says R >=
  >>> 3.5.0 which is apparently incorrect - from what you say it should be
  >>> 4.2.2?. I can certainly update to 4.2.3 if necessary.
  >>>
  >>> Cheers,
  >>> Simon
  >>>
  >>>
  >>>
   On 1/11/2023, at 9:19 AM, Mikael Jagan  wrote:
  
   Thanks.  We did see those ERRORs, stemming from use (since Matrix 
1.6-0)
   of amsmath commands in Rd files.  These have been supported since R
   4.2.2,
   but r-oldrel-macos-* (unlike r-oldrel-windows-*) continues to run R
   4.2.0.
   My expectation was that those machines would begin running R >= 4.2.2
   well
   before the R 4.4.0 release, but apparently that was wrong.
  
   I am hesitant to complicate our Rd files with conditions on R 
versions
   only to support PDF

Re: [R-pkg-devel] RFC: an interface to manage use of parallelism in packages

[Ivan Krylov]

В Wed, 25 Oct 2023 13:54:53 -0700
"Reed A. Cartwright"  пишет:

> For a comparison, I'd recommend looking at how GNU make does parallel
> processing. It uses the concept of job server and job slots. What I
> like about it is that it is implemented at the OS level because make
> needs to support interacting with non-make processes. On Windows it
> uses a named semaphore, and on Unix-like system it uses named pipes
> or simple pipes to pass tokens around.

Thank you for pointing me towards the job server in GNU make! This is
exactly the kind of suggestion I was looking for. I also appreciate you
signing up for an account on Codeberg to give me a more detailed
writeup.

I agree that named semaphores seem to be a better fit for the job than
my first design. There are some corner cases to handle (what if the
parent process starts up and the semaphore already exists? what if the
user wants to reduce the allowance but the semaphore count is lower than
expected? what are the stongest restrictions on a POSIX semaphore name?
I've seen implementations placing them under /dev/shm%s and /tmp/%s.sem
so far), but it should be possible for me to implement the core concept
in a few days.

Additional care might be needed regarding the number of BLAS threads. R
might have to become its own FlexiBLAS and pass an additional
environment variable to children to ensure the limit being taken into
account.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Issue with R Package on CRAN - OpenMP and clang17

[Ivan Krylov]

В Thu, 2 Nov 2023 10:38:56 +0100 (CET)
Romain Pierlot  пишет:

> Does a compiler bug imply that the issue doesn't come from from the
> code?

Yes. I'm sure (corrections welcome!) that it's not an error to use a
Fortran variable before an OpenMP parallel block that also uses it for
a reduction operation.

One more OpenMP-related problem that may still bite you is having to
limit the number of threads. Since there's currently no centralised way
of regulating all kinds of parallelism used in a given R session [1],
you will have to use no more than two threads by default [2], although
you are always welcome to start more if the user explicitly passes such
an option to one of your functions.

(I'm trying to help with this [3], but it may take a long while to
implement properly and even longer to ensure that this is the right
solution from both technical and social viewpoints.)

-- 
Best regards,
Ivan

[1] https://stat.ethz.ch/pipermail/r-package-devel/2023q3/009513.html

[2] https://cran.r-project.org/web/packages/policies.html

[3] https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009769.html

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

Re: [R-pkg-devel] Issue with R Package on CRAN - OpenMP and clang17

[Romain Pierlot]

I really appreciate your assistance, and the time you dedicated to building 
LLVM ! 

I noticed that you've posted the issue on GitHub, thanks for this too, I'll 
stay updated and regularly check the answers. 

Does a compiler bug imply that the issue doesn't come from from the code?

Once again, thank you for your help!

Romain 








- Mail original -
De: "Ivan Krylov" 
À: "Romain Pierlot" 
Cc: "r-package-devel" 
Envoyé: Mardi 31 Octobre 2023 17:58:05
Objet: Re: [R-pkg-devel] Issue with R Package on CRAN - OpenMP and clang17

В Mon, 30 Oct 2023 18:52:29 +0300
Ivan Krylov  пишет:

> I'll try to reproduce your problem, starting by downloading and
> compiling flang from https://github.com/llvm/llvm-project.git commit
> 092b6c5ee3707ea10b9f10d0a674e8d12395369b (as stated at
> )

Wow. Building LLVM is an adventure, and I don't mean it in a good way.
I had to patch flang/include/flang/Semantics/symbol.h because it
declares `friend class std::array` while my copy of the C++ standard
library has a `struct std::array`, which makes the friend declaration
an error. Naively thinking that I would be helping debug the problem, I
tried compiling a debugging build of LLVM, only to watch in horror as
it consumed all disk space I could offer it. I eventually ran out of
things to delete after the build directory reached 100 gigabytes in
size, while the build still had 1000 out of 6000 targets to compile and
link. Even the release build failed at 410 remaining targets because of
a missing -fPIC somewhere in the compiler command line. Thankfully, it
still produced a working `flang-new` executable.

A release build of LLVM + flang-new takes a relatively reasonable 
8.2 GBytes of storage. The computers that helped launch the first
people into space had 2 kWords of memory, but nowadays you need more
than 256 MBytes of RAM to launch a bird into a pig and 10 GBytes of
storage in order to compile a compiler. This is what progress looks
like.

I was able to reduce the example to the following program:

program main
implicit none

real :: sum = 0
integer :: i, n = 10

sum = sum + 1. ! <-- error here if followed by OpenMP reduction

!$OMP PARALLEL DO default(none) PRIVATE (i) SHARED(n) &
!$OMP REDUCTION(+:sum) SCHEDULE(Dynamic,1)
do i=1,n
sum = sum + real(i)
end do
!$OMP END PARALLEL DO

print *, sum
end

% flang-new -c -o /dev/null src.f90 -fopenmp
error: loc("src.f90":7:5): 'omp.reduction' op must be used within an
operation supporting reduction clause interface
error: verification of lowering to FIR failed

gfortran raises no errors or warnings for the test program. Bug
reported at .

Would that be enough proof of a compiler bug, or do we need a
confirmation from the developers?

-- 
Best regards,
Ivan
-- 
[ https://www.u-bordeaux.fr/ ] [ 
http://www.aquitaine-poitou-charentes.inserm.fr/ ] 

[ mailto: | Romain Pierlot ] 
Ingénieur de recherches Bio-Informatique 
Équipe BIOSTAT 


[ https://www.u-bordeaux.fr/ | https://www.u-bordeaux.fr ]

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

Re: [R-pkg-devel] Unclear NOTE for r-devel-linux-x86_64-debian-clang

[Ivan Krylov]

On Thu, 2 Nov 2023 07:58:12 +
Tony Wilkes  wrote:

> pkgs.html:66:9 (pkgs.Rd:24): Warning:  anchor "pkgs" already
> defined

Looks like the same problem as here:
https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009790.html

Should have been fixed in SVN r85440. Unfortunately, the check machine
is still running r85433. This NOTE should go away by itself after a
while.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Unclear NOTE for r-devel-linux-x86_64-debian-clang

[Duncan Murdoch]

On 02/11/2023 3:58 a.m., Tony Wilkes wrote:

Hi everyone,

I updated my package, but found a NOTE for r-devel-linux-x86_64-debian-clang.
See 
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/tinycodet-00check.html.

The NOTE is:
checking HTML version of manual ... [3s/5s] NOTE
Found the following HTML validation problems:
pkgs.html:66:9 (pkgs.Rd:24): Warning:  anchor "pkgs" already defined

As is often the case, these NOTES do not inform me at all. What does this NOTE 
entail exactly, and why is the issue only present for Debian?


That sounds like a bug in the check code which has been fixed.  Do you 
have a function named pkgs() with an argument also named pkgs?


Duncan Murdoch

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

[R-pkg-devel] Unclear NOTE for r-devel-linux-x86_64-debian-clang

[Tony Wilkes]

Hi everyone,

I updated my package, but found a NOTE for r-devel-linux-x86_64-debian-clang.
See 
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/tinycodet-00check.html.

The NOTE is:
checking HTML version of manual ... [3s/5s] NOTE
Found the following HTML validation problems:
pkgs.html:66:9 (pkgs.Rd:24): Warning:  anchor "pkgs" already defined

As is often the case, these NOTES do not inform me at all. What does this NOTE 
entail exactly, and why is the issue only present for Debian?

Kind regards,

Tony.

[[alternative HTML version deleted]]

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