Re: libsundials-dev

[Dima Kogan]

James Tocknell  writes:

> Using CMAKE_SKIP_INSTALL_PATH or CMAKE_SKIP_RPATH instead of
> CMAKE_SKIP_BUILD_PATH appear to produce the same result as
> CMAKE_SKIP_BUILD_PATH with respect to RPATHs, so unless there was a bug in
> cmake, I'm not sure what I tried previously.

Thanks for looking. Apparently I needed to update cmake and
libopenmpi-dev to make the rpath logic work properly. I guess that's
fine. I pushed another small fix to the debian/copyright. There's
ANOTHER problem where the .a files aren't being stripped for some reason
(or so says lintian), but it's supposed to "just work", so I'm happy to
leave it alone for now.

OK. I'm sufficiently satisfied.

Re: Upcoming new round of R package rebuilds [FWD: [Rd] R-devel object header changes that require reinstalling packages]

[Dirk Eddelbuettel]

On 18 September 2017 at 22:41, Charles Plessy wrote:
| Hello everybody,
| 
| I just wanted to relay the information that some R packages will need a
| rebuild after the next upgrade of R.  (see the email forwarded below.)

Common knowledge. I referenced it half-a-dozen times in the damned thread
about the binNMUs.  The ALTREP branch for R was announced as coming earlier
in the year, and is now in the r-devel master branch (ie R upstream).

We will switch to r-api-4 then which will finally break the effing block
posed upon by the release team in response to the 'R 3.4.0 has a change' bug
report by Johannes.

| (By the way, I apologise in advance that I am being crushed for time
| currently and will not be able to help much).

This will happen in April 2018.  Hopefully you will have more spare cycles then.

Dirk

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

Re: Upcoming new round of R package rebuilds [FWD: [Rd] R-devel object header changes that require reinstalling packages]

[Johannes Ranke]

Uff, thanks for letting us know in advance!! I believe this means another 
fresh repository in CRAN for the corresponding R release...

Johannes

Am Montag, 18. September 2017, 22:41:04 CEST schrieb Charles Plessy:
> Hello everybody,
> 
> I just wanted to relay the information that some R packages will need a
> rebuild after the next upgrade of R.  (see the email forwarded below.)
> 
> (By the way, I apologise in advance that I am being crushed for time
> currently and will not be able to help much).
> 
> Cheers,
> 
> -- Charles
> 
> - Forwarded message -
> 
> Date: Tue, 12 Sep 2017 13:28:48 -0500 (CDT)
> To: r-de...@r-project.org
> Subject: [Rd] R-devel object header changes that require reinstalling
> packages Message-ID: 
> 
> For anyone using the development version of R:
> 
> svn revision 73243 introduces some changes to the memory layout of R
> objects that require reinstalling packages using compiled
> code. Attempting to load incompatible packages should signal an
> error. These changes are to support a new extension framework for
> basic R objects
> (https://svn.r-project.org/R/branches/ALTREP/ALTREP.html outlines the
> framework).  Merging the remainder of the framework should not
> introduce more binary changes and is expected to occur in the next few
> months.
> 
> Best,
> 
> luke


-- 
Johannes Ranke
Wissenschaftlicher Berater
https://jrwb.de/contact

Re: libsundials-dev

[James Tocknell]

Using CMAKE_SKIP_INSTALL_PATH or CMAKE_SKIP_RPATH instead of
CMAKE_SKIP_BUILD_PATH appear to produce the same result as
CMAKE_SKIP_BUILD_PATH with respect to RPATHs, so unless there was a bug in
cmake, I'm not sure what I tried previously.

James

On 18 September 2017 at 19:41, James Tocknell  wrote:

> Building with gbp buildpackage --git-builder='debuild -i -I -uc -us'
> --git-no-pbuilder (so no cowbuilder) also produces libraries with no
> RPATHs, it does however produce new lintian warnings (compared to
> cowbuilder) about missing copyright entries for LICENSE, README and
> config/FindMPI.cmake.
>
> The documentation for the option is at https://cmake.org/cmake/help/
> v3.0/variable/CMAKE_SKIP_BUILD_RPATH.html, I think I had tried
> https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_RPATH.html or
> https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_INSTALL_RPATH.html,
> I wrote this months ago and rebased it, but I remember the obvious option
> didn't work...
>
> James
>
> On 18 September 2017 at 17:24, Dima Kogan  wrote:
>
>> James Tocknell  writes:
>>
>> > I looked at the RPATH change, lintian doesn't show any RPATH warnings
>> > for me, I also ran readelf on the shared libraries, no RPATH or
>> > RUNPATH. I'm building via gbp and cowbuilder on amd64 (with sid as the
>> > target distro), could that be the problem?
>>
>> Hmmm. I see no rpath lintian warnings when building inside sbuild, but
>> many of them without sbuild (same behavior as what you're seeing with
>> cowbuilder).
>>
>> Looking deeper (sysdig -c spy_users), this isn't because sbuild builds
>> are causing RUNPATH tags to be removed, but because for whatever reason
>> under sbuild they're never put in place to begin with. Can you confirm
>> the lintian warnings if building without cowbuilder?
>>
>> What is that CMAKE flag you added supposed to do? I'm pretty sure it's
>> not doing what we think it should be doing in at least on of the yes/no
>> sbuild cases.
>>
>> Thanks
>>
>
>
>
> --
> Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.). It
> isn't good enough for Tim Berners-Lee
> ,
> and it isn't good enough for me either. For more information visit
> http://www.gnu.org/philosophy/no-word-attachments.html.
>
> Truly great madness cannot be achieved without significant intelligence.
>  - Henrik Tikkanen
>
> If you're not messing with your sanity, you're not having fun.
>  - James Tocknell
>
> In theory, there is no difference between theory and practice; In
> practice, there is.
>



-- 
Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.). It
isn't good enough for Tim Berners-Lee
,
and it isn't good enough for me either. For more information visit
http://www.gnu.org/philosophy/no-word-attachments.html.

Truly great madness cannot be achieved without significant intelligence.
 - Henrik Tikkanen

If you're not messing with your sanity, you're not having fun.
 - James Tocknell

In theory, there is no difference between theory and practice; In practice,
there is.

Re: libsundials-dev

[James Tocknell]

Building with gbp buildpackage --git-builder='debuild -i -I -uc -us'
--git-no-pbuilder (so no cowbuilder) also produces libraries with no
RPATHs, it does however produce new lintian warnings (compared to
cowbuilder) about missing copyright entries for LICENSE, README and
config/FindMPI.cmake.

The documentation for the option is at
https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_BUILD_RPATH.html, I
think I had tried
https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_RPATH.html or
https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_INSTALL_RPATH.html, I
wrote this months ago and rebased it, but I remember the obvious option
didn't work...

James

On 18 September 2017 at 17:24, Dima Kogan  wrote:

> James Tocknell  writes:
>
> > I looked at the RPATH change, lintian doesn't show any RPATH warnings
> > for me, I also ran readelf on the shared libraries, no RPATH or
> > RUNPATH. I'm building via gbp and cowbuilder on amd64 (with sid as the
> > target distro), could that be the problem?
>
> Hmmm. I see no rpath lintian warnings when building inside sbuild, but
> many of them without sbuild (same behavior as what you're seeing with
> cowbuilder).
>
> Looking deeper (sysdig -c spy_users), this isn't because sbuild builds
> are causing RUNPATH tags to be removed, but because for whatever reason
> under sbuild they're never put in place to begin with. Can you confirm
> the lintian warnings if building without cowbuilder?
>
> What is that CMAKE flag you added supposed to do? I'm pretty sure it's
> not doing what we think it should be doing in at least on of the yes/no
> sbuild cases.
>
> Thanks
>



-- 
Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.). It
isn't good enough for Tim Berners-Lee
,
and it isn't good enough for me either. For more information visit
http://www.gnu.org/philosophy/no-word-attachments.html.

Truly great madness cannot be achieved without significant intelligence.
 - Henrik Tikkanen

If you're not messing with your sanity, you're not having fun.
 - James Tocknell

In theory, there is no difference between theory and practice; In practice,
there is.

Re: Python 3 Statsmodels & Pandas

[Stuart Prescott]

Hi Diane,

On Sunday, 17 September 2017 22:14:18 AEST Diane Trout wrote:
> I just did it that way because it was the least disruptive change I
> could make that would let me build and test the package.

Sure, that's entirely sensible.

> In my experience I'm much more likely to to notice a build time test
> failure than one from the CI system. 

Absolutely agreed. I'm thinking that this is a rather exceptional situation 
because of the circular dependency and the fall-out that we regularly see from 
that.

> What do other people think? If there are autopkgtests, should you still
> let dh_auto_test run tests?

(I know I'm not the 'other people' from whom you solicit replies, I was just 
perhaps unclear in what I was musing on before so I want to be more clear now)

Like you, I would *normally* run all tests in both places: buildd tests catch 
severe problems right now; ci.d.n reruns the tests each time new versions of 
dependencies are uploaded too and later breakage is caught.

Perhaps this is not a normal situation, however. Either one of "circular 
dependencies" or "packages that often FTBFS on one or more architectures" 
would be unusual enough to justify doing something different. All I am 
wondering (from my position of ignorance!) if in this case, perhaps the tests 
that cause the circular dependency can be disabled or xfailed, with the 
remaining tests run as normal.

cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Re: libsundials-dev

[Dima Kogan]

James Tocknell  writes:

> I looked at the RPATH change, lintian doesn't show any RPATH warnings
> for me, I also ran readelf on the shared libraries, no RPATH or
> RUNPATH. I'm building via gbp and cowbuilder on amd64 (with sid as the
> target distro), could that be the problem?

Hmmm. I see no rpath lintian warnings when building inside sbuild, but
many of them without sbuild (same behavior as what you're seeing with
cowbuilder).

Looking deeper (sysdig -c spy_users), this isn't because sbuild builds
are causing RUNPATH tags to be removed, but because for whatever reason
under sbuild they're never put in place to begin with. Can you confirm
the lintian warnings if building without cowbuilder?

What is that CMAKE flag you added supposed to do? I'm pretty sure it's
not doing what we think it should be doing in at least on of the yes/no
sbuild cases.

Thanks