Bug#1004814: r-cran-av: FTBFS with ffmpeg 5.0
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
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
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 tzda
Bug#923447: [Pkg-openssl-devel] Bug#923447: openssl breaks r-cran-openssl autopkgtest
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
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
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
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
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
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
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