R devel - Apr 2018 - R 3.5.0 fails its regression test suite on Linux/x86_64

Hi Dirk,

 > I have been doing for R for about 20 years (if you count the time I
 > assisted Doug Bates when he was still the maintainer) (and longer for
 > Debian), and you seem to follow the same model we set up years ago of
 > splitting the content of r-recommended (itself a virtual package) off
 > r-base-core.
 >
 > You simply need to do this in stages.

I have packaged free software for 20+ years for many different distributions,
and, in fact, I'm doing that professionally these days as an employee of one
of
the largest commercial Linux distributors. So please trust my expertise when I
tell you that this is not what I want.

What I want is

  ./configure --without-recommended-packages && make && make
check

to succeed without error, and I don't think that's an unreasonable
expectation.

I have reported these kind of errors before in past, and back then a friendly R
developer simply took a moment to disable the offending tests when the build
was configured with this particular flag and that solved the problem. I would
hope that this is the outcome we can achieve this time, too.

If no-one wants to make those changes for whatever reason, then that's fine
and
I'll just disable the test suite in NixOS to make the build succeed. I feel
like
that would be a sub-optimal solution, though.

Best regards,
Peter

Peter,

I think we are on the same page, but there is little I can do for you here.
Ultimately you are asking R Core to do you a favor. More below.

On 23 April 2018 at 18:28, Peter Simons wrote:
| Hi Dirk,
| 
|  > I have been doing for R for about 20 years (if you count the time I
|  > assisted Doug Bates when he was still the maintainer) (and longer for
|  > Debian), and you seem to follow the same model we set up years ago of
|  > splitting the content of r-recommended (itself a virtual package) off
|  > r-base-core.
|  >
|  > You simply need to do this in stages.
| 
| I have packaged free software for 20+ years for many different distributions,
| and, in fact, I'm doing that professionally these days as an employee of
one of
| the largest commercial Linux distributors. So please trust my expertise when I
| tell you that this is not what I want.
| 
| What I want is
| 
|   ./configure --without-recommended-packages && make && make
check
| 
| to succeed without error, and I don't think that's an unreasonable
expectation.

Sure. You "merely" have to get R Core to implement it for you.  Given
that it
does not help them (they just build 'with recommended') and is not
strictly
needed (it will pass in a second pass once you used the first pass to build
the recommended packages) it is a little hard to see how this 'nice to
have'
item may bubble higher on anybody's priorities.  But the general rules is
that if and when well-written patches are submitted on topics where there is
agreement that a fix may help, then they are considered. So *you* could work
on this.
 
| I have reported these kind of errors before in past, and back then a friendly
R
| developer simply took a moment to disable the offending tests when the build
| was configured with this particular flag and that solved the problem. I would
| hope that this is the outcome we can achieve this time, too.

R Core disabled tests in base R for you?  Hm. Are you sure?  Or are you by
chance confusing R Core with a random package maintainer (like myself) who
may have disabled a test?
 
| If no-one wants to make those changes for whatever reason, then that's
fine and
| I'll just disable the test suite in NixOS to make the build succeed. I
feel like
| that would be a sub-optimal solution, though.

You could comment it out now, and re-enable it once your package stack is
refilled.  Or you could make it 'make -k check' for now.

It's really under your control as it your build environment.

Dirk

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

On 23/04/2018 12:28 PM, Peter Simons wrote:
> Hi Dirk,
> 
>   > I have been doing for R for about 20 years (if you count the time I
>   > assisted Doug Bates when he was still the maintainer) (and longer
for
>   > Debian), and you seem to follow the same model we set up years ago
of
>   > splitting the content of r-recommended (itself a virtual package)
off
>   > r-base-core.
>   >
>   > You simply need to do this in stages.
> 
> I have packaged free software for 20+ years for many different
distributions,
> and, in fact, I'm doing that professionally these days as an employee
of one of
> the largest commercial Linux distributors. So please trust my expertise
when I
> tell you that this is not what I want.
> 
> What I want is
> 
>    ./configure --without-recommended-packages && make &&
make check
> 
> to succeed without error, and I don't think that's an unreasonable
expectation.
So you're getting paid to do what you do, but you want the volunteers in 
R Core to do some work for you for free.  I *do* think that's an 
unreasonable expectation.
> 
> I have reported these kind of errors before in past, and back then a
friendly R
> developer simply took a moment to disable the offending tests when the
build
> was configured with this particular flag and that solved the problem. I
would
> hope that this is the outcome we can achieve this time, too.
Perhaps back then you were also a volunteer.
> 
> If no-one wants to make those changes for whatever reason, then that's
fine and
> I'll just disable the test suite in NixOS to make the build succeed. I
feel like
> that would be a sub-optimal solution, though.
I agree.  You should spend some time working out a better one.

Duncan Murdoch

Duncan Murdoch writes:

 >> ./configure --without-recommended-packages && make &&
make check
 >
 > So you're getting paid to do what you do, but you want the volunteers
 > in R Core to do some work for you for free.

You are jumping to conclusions. Nobody pays me a single cent to package
R for Nix; I do that purely as a hobby.


 >> If no-one wants to make those changes for whatever reason, then
that's fine and
 >> I'll just disable the test suite in NixOS to make the build
succeed. I feel like
 >> that would be a sub-optimal solution, though.
 >
 > I agree. You should spend some time working out a better one.

Well, you know, every so often, I reach out to people in a free software
community to make them aware of some issue I've run into. On some
occasions, members of those communities respond in a helpful and
friendly manner that impresses me because these people are obviously
thoughtful and issue-oriented and offer nuanced insight into the problem
I've brought up, and then I feel like it would be fun to interact with
those people to learn new stuff and maybe contribute something useful.
That's the point about volunteering, right? People do it because they
*enjoy it*, not because someone tells them to.

So, you go ahead and have a very nice day, Duncan.

Best regards,
Peter