Bug#1004814: r-cran-av: FTBFS with ffmpeg 5.0

[Jeroen Ooms]

On Tue, Feb 8, 2022 at 6:33 AM Andreas Tille  wrote:
>
> Control: tags -1 upstream
> Control: forwarded -1 Jeroen Ooms 
>
> Hi Jeroen,
>
> Debian will migrate to ffmpeg5.0 soon.  It would be great if you could
> adapt av to the new ffmpeg version.

Thanks. I have now released av version 0.7.0 to CRAN which works with ffmpeg-5.

Bug#995302: r-cran-magick: FTBFS with imagemagick 6.9.12.20

[Jeroen Ooms]

On Wed, Sep 29, 2021 at 9:40 PM Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi all,
>
> Quoting Jeroen Ooms (2021-09-29 20:54:17)
> > The relevant part of the build log is actually:
> >
> > > Package Magick++ was not found in the pkg-config search path.
> > > Perhaps you should add the directory containing `Magick++.pc'
> > > to the PKG_CONFIG_PATH environment variable
> > > No package 'Magick++' found
> > > Warning: found GraphicsMagick++ instead of ImageMagick++. GraphicsMagick 
> > > is not supported.
> >
> > You need to build the R package against imagemagick, not graphicsmagick!
>
> ah nice catch! Thank you!
>
> So the problem is, that graphicsmagick is installed because
> graphicsmagick-libmagick-dev-compat provides libmagick++-dev and thus 
> satisfies
> the build dependencies of r-cran-magick. Since r-cran-magick must not be built
> with graphicsmagick, the package should probably add something like:
>
> Build-Conflicts: graphicsmagick-libmagick-dev-compat, libgraphicsmagick1-dev
>
> Thanks!

I think the actual bug is that apt prefers
graphicsmagick-libmagick-dev-compat over the actual libmagick++-dev. I
don't understand why this has started happening (it wasn't the case
for previous releases, where this problem did not happen). The
graphicsmagick fork is quite different from imagemagick; I don't think
they should be considered interchangeable, and certainly not
preferred.

Bug#995302: r-cran-magick: FTBFS with imagemagick 6.9.12.20

[Jeroen Ooms]

The relevant part of the build log is actually:

> Package Magick++ was not found in the pkg-config search path.
> Perhaps you should add the directory containing `Magick++.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'Magick++' found
> Warning: found GraphicsMagick++ instead of ImageMagick++. GraphicsMagick is 
> not supported.

You need to build the R package against imagemagick, not graphicsmagick!



On Wed, Sep 29, 2021 at 6:48 PM Andreas Tille  wrote:
>
> Control: tags -1 upstream
> Control: forwarded -1 Jeroen Ooms 
>
> Hi Jeroen,
>
> I take the freedom to simply forward this bug report about the Debian
> packaged version of magick to you.  Please let me know if you need
> more information.
>
> Kind regards
>
>   Andreas.
>
> On Wed, Sep 29, 2021 at 03:12:06PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> > Source: r-cran-magick
> > Severity: normal
> > Tags: ftbfs
> > Control: block #994540 by -1
> >
> > Hi,
> >
> > r-cran-magick FTBFS with imagemagick 8:6.9.12.20+dfsg1-1.1 from 
> > experimental. The
> > build log is attached. The relevant part:
> >
> > g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG  
> > -I'/usr/lib/R/site-library/Rcpp/include'   -fvisibility=hidden -fpic  -g 
> > -O2 -ffile-prefix-map=/build/r-base-kpovBh/r-base-4.1.1=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -g  -c RcppExports.cpp -o RcppExports.o
> > In file included from RcppExports.cpp:4:
> > magick_types.h:36:9: error: ‘Point’ in namespace ‘Magick’ does not name a 
> > type
> >36 | Magick::Point Point(const char * str);
> >   | ^
> > magick_types.h:44:22: error: ‘FilterType’ in namespace ‘Magick’ does not 
> > name a type
> >44 | #define myFilterType FilterType
> >   |  ^~
> > magick_types.h:44:22: note: in definition of macro ‘myFilterType’
> >44 | #define myFilterType FilterType
> >   |  ^~
> > make[1]: *** [/usr/lib/R/etc/Makeconf:177: RcppExports.o] Error 1
> > make[1]: Leaving directory '/<>/src'
> > make[1]: Entering directory '/<>/src'
> > make[1]: Leaving directory '/<>/src'
> > ERROR: compilation failed for package ‘magick’
> >
> > Thanks!
> >
> > cheers, josch
>
> > sbuild (Debian sbuild) 0.81.2 (31 January 2021) on localhost
> >
> > +==+
> > | r-cran-magick (amd64)Tue, 28 Sep 2021 23:07:11 
> > + |
> > +==+
> >
> > Package: r-cran-magick
> > Distribution: unstable
> > Machine Architecture: amd64
> > Host Architecture: amd64
> > Build Architecture: amd64
> > Build Type: binary
> >
> > Unpacking /home/josch/.cache/sbuild/unstable-amd64.tar to 
> > /tmp/tmp.sbuild.MX75rqskEg...
> > adduser: The group `sbuild' does not exist.
> > adduser: The group `sbuild' does not exist.
> > I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' with 
> > '<>'
> > I: NOTICE: Log filtering will replace 
> > 'build/r-cran-magick-02cbAw/resolver-vgQKR2' with '<>'
> >
> > +--+
> > | Update chroot 
> >|
> > +--+
> >
> > Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
> > Get:2 http://deb.debian.org/debian experimental InRelease [75.4 kB]
> > Get:3 http://deb.debian.org/debian unstable/main Sources [9231 kB]
> > Get:4 http://deb.debian.org/debian unstable/main amd64 Packages [8778 kB]
> > Get:5 http://deb.debian.org/debian experimental/main amd64 Packages [536 kB]
> > Fetched 18.8 MB in 3s (6949 kB/s)
> > Reading package lists...
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > Calculating upgrade...
> > The following packages will be upgraded:
> >   linux-libc-dev tzdata
> > 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 1704 kB of archives.
> > After this operation, 69.6 kB disk space will be freed.
> > Get:1 http://deb.debian.org/debian unstable/main amd64 tzdata all 2021a-2 
> > [284 kB]
> > Get:2 http://deb.debian.org/debian unstable/main amd64 linux

Bug#923447: [Pkg-openssl-devel] Bug#923447: openssl breaks r-cran-openssl autopkgtest

[Jeroen Ooms]

On Fri, Mar 1, 2019 at 8:05 PM Sebastian Andrzej Siewior
 wrote:
>
> On 2019-03-01 11:16:35 [+0100], Jeroen Ooms wrote:
> > FWIW, the underlying problem in a regression in libssl though. So if
> > the problem appears for other packages you could also backport this
> > libssl patch: https://github.com/openssl/openssl/issues/8375
>
> Does this problem solve your problem or does it have nothing to do with
> the current situation?

As stated, that is the bug report in libssl which causes the crash in
r-cran-openssl (and the first reply links to a PR with a patch).

I have released a workaround in the R bindings so that it can work
with libssl 1.1.1b as-is. Hence in other to fix the crash in
r-cran-openssl, you either need to update to upstream version 1.2.2,
or alternatively, you could backport the libssl patch from the
discussion above.

Bug#923447: openssl breaks r-cran-openssl autopkgtest

[Jeroen Ooms]

FWIW, the underlying problem in a regression in libssl though. So if
the problem appears for other packages you could also backport this
libssl patch: https://github.com/openssl/openssl/issues/8375





On Fri, Mar 1, 2019 at 10:59 AM Jeroen Ooms  wrote:
>
> I have submitted a hotfix release openssl 1.2.2 to cran that should
> fix the issue. It should be there soon.
>
>
>
>
> On Thu, Feb 28, 2019 at 5:24 PM Andreas Tille  wrote:
> >
> > Hi,
> >
> > I'd be deligted if somebody from the team could care since I'm
> > basically offline-ish until 4.3.
> >
> > Thank you, Andreas.
> >
> > On Thu, Feb 28, 2019 at 12:29:12PM +0100, Paul Gevers wrote:
> > > Source: openssl, r-cran-openssl
> > > Control: found -1 openssl/1.1.1b-1
> > > Control: found -1 r-cran-openssl/1.2.1+dfsg-1
> > > Severity: important
> > > X-Debbugs-CC: debian...@lists.debian.org
> > > User: debian...@lists.debian.org
> > > Usertags: breaks needs-update
> > >
> > > Dear maintainers,
> > >
> > > With a recent upload of openssl the autopkgtest of r-cran-openssl fails
> > > in testing when that autopkgtest is run with the binary packages of
> > > openssl from unstable. It passes when run with only packages from
> > > testing. In tabular form:
> > >passfail
> > > opensslfrom testing1.1.1b-1
> > > r-cran-openssl from testing1.2.1+dfsg-1
> > > all others from testingfrom testing
> > >
> > > I copied some of the output at the bottom of this report. The error
> > > looks quite scary to me, but I have no idea if this means that
> > > r-cran-openssl is really failing, or if openssl has changed it's
> > > interface in a bad way.
> > >
> > > Currently this regression is blocking the migration of openssl to
> > > testing [1]. Due to the nature of this issue, I filed this bug report
> > > against both packages. Can you please investigate the situation and
> > > reassign the bug to the right package? If needed, please change the
> > > bug's severity.
> > >
> > > Please note that the window to fix this to allow openssl to migrate
> > > without intervention is closing extremely soon.
> > >
> > > More information about this bug and the reason for filing it can be found 
> > > on
> > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> > >
> > > Paul
> > >
> > > [1] https://qa.debian.org/excuses.php?package=openssl
> > >
> > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-openssl/2021380/log.gz
> > >
> > > autopkgtest [21:16:05]: test run-unit-test: [---
> > >
> > > R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
> > > Copyright (C) 2018 The R Foundation for Statistical Computing
> > > Platform: x86_64-pc-linux-gnu (64-bit)
> > >
> > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > You are welcome to redistribute it under certain conditions.
> > > Type 'license()' or 'licence()' for distribution details.
> > >
> > > R is a collaborative project with many contributors.
> > > Type 'contributors()' for more information and
> > > 'citation()' on how to cite R or R packages in publications.
> > >
> > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > 'help.start()' for an HTML browser interface to help.
> > > Type 'q()' to quit R.
> > >
> > > > library(testthat)
> > > > library(openssl)
> > > >
> > > > test_check("openssl")
> > > double free or corruption (fasttop)
> > > Aborted
> > > autopkgtest [21:16:05]: test run-unit-test: ---]
> > >
> >
> >
> >
> >
> > > ___
> > > R-pkg-team mailing list
> > > r-pkg-t...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
> >
> >
> > --
> > http://fam-tille.de
> >

Bug#923447: openssl breaks r-cran-openssl autopkgtest

[Jeroen Ooms]

I have submitted a hotfix release openssl 1.2.2 to cran that should
fix the issue. It should be there soon.




On Thu, Feb 28, 2019 at 5:24 PM Andreas Tille  wrote:
>
> Hi,
>
> I'd be deligted if somebody from the team could care since I'm
> basically offline-ish until 4.3.
>
> Thank you, Andreas.
>
> On Thu, Feb 28, 2019 at 12:29:12PM +0100, Paul Gevers wrote:
> > Source: openssl, r-cran-openssl
> > Control: found -1 openssl/1.1.1b-1
> > Control: found -1 r-cran-openssl/1.2.1+dfsg-1
> > Severity: important
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: breaks needs-update
> >
> > Dear maintainers,
> >
> > With a recent upload of openssl the autopkgtest of r-cran-openssl fails
> > in testing when that autopkgtest is run with the binary packages of
> > openssl from unstable. It passes when run with only packages from
> > testing. In tabular form:
> >passfail
> > opensslfrom testing1.1.1b-1
> > r-cran-openssl from testing1.2.1+dfsg-1
> > all others from testingfrom testing
> >
> > I copied some of the output at the bottom of this report. The error
> > looks quite scary to me, but I have no idea if this means that
> > r-cran-openssl is really failing, or if openssl has changed it's
> > interface in a bad way.
> >
> > Currently this regression is blocking the migration of openssl to
> > testing [1]. Due to the nature of this issue, I filed this bug report
> > against both packages. Can you please investigate the situation and
> > reassign the bug to the right package? If needed, please change the
> > bug's severity.
> >
> > Please note that the window to fix this to allow openssl to migrate
> > without intervention is closing extremely soon.
> >
> > More information about this bug and the reason for filing it can be found on
> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> >
> > Paul
> >
> > [1] https://qa.debian.org/excuses.php?package=openssl
> >
> > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-openssl/2021380/log.gz
> >
> > autopkgtest [21:16:05]: test run-unit-test: [---
> >
> > R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
> > Copyright (C) 2018 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> > > library(testthat)
> > > library(openssl)
> > >
> > > test_check("openssl")
> > double free or corruption (fasttop)
> > Aborted
> > autopkgtest [21:16:05]: test run-unit-test: ---]
> >
>
>
>
>
> > ___
> > R-pkg-team mailing list
> > r-pkg-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
>
>
> --
> http://fam-tille.de
>

Bug#882852: imagemagick: Latest ImageMagick no longer supports cairo and librsvg2

[Jeroen Ooms]

Package: imagemagick
Version: 6.9.7.4+dfsg-16
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After upgrading ImageMagick from Ubuntu Xenial to Artsy (the latter 
includes the current debian version), the package no longer has features
'cairo' and 'librsvg2' enabled. I suppose this is not intended because the
package still has build-depends on libcairo-dev and librsvg2-dev. However 
the macros MAGICKCORE_CAIRO_DELEGATE and MAGICKCORE_RSVG_DELEGATE are
actually disabled and output is really ugly.

These are stored in 
/usr/include/x86_64-linux-gnu/ImageMagick-6/magick/magick-baseconfig.h 

This is a pretty serious issue because without these features, rendering 
capabilities are very limited. Upstream maintainers highly recommend using
librsvg2 and not the internal libxml2 delegate for svg rendering. Also
cairo is needed for a lot of advanced rendering features.

To give an impression, below is a PNG file of the standard svg tigered
rendered with the current and previous IM: 

Current Debian version: https://i.imgur.com/YCrYDzH.png
Current Xenial version: https://i.imgur.com/uKtwNWK.png

I hope that this illustrates that these features are not just "nice to
have" but really needed to make imagemagick useful.

Thank you for looking into this!

Jeroen



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.49-moby (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages imagemagick depends on:
pn  imagemagick-6.q16  

imagemagick recommends no packages.

imagemagick suggests no packages.

Bug#828529: r-cran-openssl: FTBFS with openssl 1.1.0

[Jeroen Ooms]

On Thu, Oct 27, 2016 at 3:59 PM, Andreas Tille  wrote:
> It would be great if you could ping me once you have prepared a new
> release.

I have published an upstream release of openssl_0.9.5.tar.gz that
should fix the libssl1.1.0 problems:
https://cran.r-project.org/web/packages/openssl/index.html

Bug#773671: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues

[Jeroen Ooms]

On Wed, Jul 27, 2016 at 11:29 AM, Bálint Réczey  wrote:
>
> The .spec file linked from the Red Hat bugzilla lists CVE-s fixed:
> https://spot.fedorapeople.org/v8-314.spec
>
> Thanks to Jeroen for contacting us.

Let us know if there is anything we can do to help keep libv8-3.14
supported in Debian. We have a many software packages and researchers
depending on this version at UC Berkeley.

Bug#824840: libhunspell api change after upgrade to 1.4

[Jeroen Ooms]

Package: libhunspell-dev
Version: 1.4.1

The upgrade of libhunspell-dev to the 1.4 branch changed the API for
get_wordchars_utf16:

  const std::vector& get_wordchars_utf16() const;

However 'man 3 husnpell' still lists the old API:

  unsigned short * get_wordchars_utf16(int *" len)

The API change was not advertised elsewhere either. It is not clear if
the change was intended, but it breaks anything that uses this
function.

Upstream issue: https://github.com/hunspell/hunspell/issues/387