Bug#993333: weechat: FTBFS: Target "irc" links to item " use `command -v' in scripts instead
On Tue, Aug 31, 2021 at 12:18:52AM +0300, Niko Tyni wrote: > Source: weechat > Version: 3.0.1-1 > Severity: serious > Tags: ftbfs sid bookworm > > This package fails to build from source on current sid. > > It looks like this regressed with the recent change in debianutils > that made /usr/bin/which output a deprecation warning. > > >From a build log: > >-- Found GCRYPT: /usr/bin/which: this version of `which' is deprecated; > use `command -v' in scripts instead. >-L/usr/lib/x86_64-linux-gnu -lgcrypt > >[...] > >CMake Error at src/plugins/irc/CMakeLists.txt:20 (add_library): > Target "irc" links to item " use `command -v' in scripts instead. > > -L/usr/lib/x86_64-linux-gnu -lgcrypt" which has leading or trailing > whitespace. This is now an error according to policy CMP0004. > > A full log is available at > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/weechat.html > > -- > Niko Tyni nt...@debian.org Hi Niko, Thanks for your report. The problem is indirectly caused by the deprecation of the "which" command in the package debianutils. I opened the Debian bug #993244 two days ago (feel free to merge bugs if needed). The "which" command seems to be used inside CMake, not in WeeChat itself, but this breaks compilation of WeeChat (I suppose like many other packages). For now I have no fix available on WeeChat side. If the warning on stderr in "which" command stays as-is, I think CMake has to be fixed. -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.libera.chat
Bug#896091: gimp fails to run with a symbol lookup error: undefined symbol: babl_process_rows
Package: gimp Version: 2.8.22-1 Severity: grave Justification: renders package unusable gimp fails to run with this error: gimp: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgegl-0.3.so.0: undefined symbol: babl_process_rows -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gimp depends on: ii gimp-data2.8.22-1 ii libaa1 1.4p5-44+b1 ii libbabl-0.1-01:0.1.28-dmo1 ii libbz2-1.0 1.0.6-8.1 ii libc62.27-3 ii libcairo21.15.10-1 ii libdbus-1-3 1.12.6-2 ii libdbus-glib-1-2 0.110-2 ii libexif120.6.21-5 ii libfontconfig1 2.13.0-4 ii libfreetype6 2.8.1-2 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libgegl-0.3-00.3.28-4 ii libgimp2.0 2.8.22-1 ii libglib2.0-0 2.56.1-2 ii libgs9 9.22~dfsg-2 ii libgtk2.0-0 2.24.32-1 ii libgudev-1.0-0 232-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libpango-1.0-0 1.42.0-1 ii libpangocairo-1.0-0 1.42.0-1 ii libpangoft2-1.0-01.42.0-1 ii libpng16-16 1.6.34-1 ii libpoppler-glib8 0.62.0-2 ii librsvg2-2 2.40.20-2 ii libtiff5 4.0.9-5 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.5-1 ii libxcursor1 1:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii python 2.7.14-4 ii python-gtk2 2.24.0-5.1+b1 ii python2.72.7.14-8 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gimp recommends: ii ghostscript 9.22~dfsg-2 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help pn gvfs-backends ii libasound21.1.3-5 -- no debconf information
Bug#892072: weechat: build against ruby2.5
On Sun, Mar 04, 2018 at 07:57:11PM -0300, Antonio Terceiro wrote: > Source: weechat > Version: 1.9.1-1 > Severity: serious > Justification: will FTBFS soon > Tags: patch > > Hi, > > I am about to upload ruby-defaults to unstable, switching the default > Ruby to ruby2.5, and ruby2.3 support will be removed right after that. > Please consider applying the attached patch, obtained from upstream. > > Even better: please work with upstream to be able to build against the > default ruby, instead of hardcoding a list of ruby versions. Otherwise, > every time there is a Ruby transition, weechat will be a blocker. > Hunting down these issues is quite time consuming. > Hi Antonio, I agree with the need to detect Ruby and other libraries in WeeChat without hardcoding a list of supported versions in the CMake and configure files. I opened an issue, so this will be implemented as soon as possible: https://github.com/weechat/weechat/issues/1156 -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.freenode.net
