On Mon, Dec 05, 2016 at 05:57:11PM +0100, Gordon Ball wrote:
>
> Yes, sorry, I've been occupied by various things recently. The changes
> look fine (and in any case, the package is marked as team maintained and
> I'm fine with the team maintaining it).
:-)
> > I have converted several packages from cdbs to dh-r with no visible
> > problems so far. The usage of ${R:Depends} is very convenient and IMHO
> > increases the quality of packages since it makes sure no (versioned)
> > dependency will be forgotten in the binary package dependency list (I
> > noticed some examples that were definitely wrong before).
>
> Good to hear. Did you find any other cases in which existing variables
> would have been useful (as you reported in #842092), or any other
> recurrent packaging issues which should be added to dh-r?
Nothing except what I changed in Git or what was reported. I think
#842092 is not really hard to do I just have wiped it from my desk by
simply filing the bug report. :-P If you confirm that you are
overworked I'll have a look how to fix it.
> > However, yesterday I stumbled upon r-cran-yaml[1] which causes a problem
> > I was not able to solve quickly. Upstream has injected an additional
> > declaration to the code copy of libyaml which I injected via quilt patch
> > right into the C code which now enables building the code. Strangely
> > enough the resulting library does not end up in the target directory
> > location - or at least R can't find it there and the issue is hard to
> > debug since at the point when the build process gets control again and I
> > get a shell the files in questions are just removed by the Makefile:
> >
> > ** libs
> > make[1]: Entering directory '/build/r-cran-yaml-2.1.14+dfsg/src'
> > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic -g
> > -O2 -fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong
> > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -
> > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic -g
> > -O2 -fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong
> > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -
> > gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o yaml.so implicit.o
> > r-ext.o -lyaml -L/usr/lib/R/lib -lR
> > make[1]: Leaving directory '/build/r-cran-yaml-2.1.14+dfsg/src'
> > make[1]: Entering directory '/build/r-cran-yaml-2.1.14+dfsg/src'
> > make[1]: Leaving directory '/build/r-cran-yaml-2.1.14+dfsg/src'
> > installing to
> > /build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml/libs
> > ** R
> > ** inst
> > ** preparing package for lazy loading
> > ** help
> > *** installing help indices
> > ** building package indices
> > ** testing if installed package can be loaded
> > Error in dyn.load(file, DLLpath = DLLpath, ...) :.
> > unable to load shared object
> > '/build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml/libs/yaml.so':
> >
> > /build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml/libs/yaml.so:
> > undefined symbol: yaml_emitter_set_indent_mapping_sequence
> > Error: loading failed
> > Execution halted
> > ERROR: loading failed
> > * removing
> > '/build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml'
> >
> >
> > I admit my poor wisdom ends here. Any clue?
>
> Nothing from a quick look. I'll have a longer look tonight or tomorrow
> and see if I can spot anything.
That would be really nice.
> Thanks for all your efforts keeping R packages updated.
As per now there should be no outdated r-* packages left (except for
those where I faced some trouble). My goal is to keep the team
maintained packages in sync with upstream until the freeze. If I touch
any of those packages I convert to dh-r and will add autopkgtests if
upstream provides a test suite.
Kind regards
Andreas.
--
http://fam-tille.de
