Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
On Mon, Oct 28, 2019 at 11:15 PM Scott Talbert wrote: > The fpga test failure is also occurring with autopkgtest: > https://ci.debian.net/data/packages/unstable/amd64/m/meson/latest-autopkgtest/log.gz > > Jussi also mentioned it. Perhaps it's related to the recent upload of > fpga-icestorm? This is a bug in either yosys or arachne-pnr, I reported it here: https://github.com/YosysHQ/yosys/issues/1467
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
On Mon, Oct 28, 2019 at 05:15:15PM -0400, Scott Talbert wrote: > The fpga test failure is also occurring with autopkgtest: > https://ci.debian.net/data/packages/unstable/amd64/m/meson/latest-autopkgtest/log.gz > > Jussi also mentioned it. Perhaps it's related to the recent upload of > fpga-icestorm? I see meson also FTBFS in reproducible build testing: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meson.html Given meson already FTBFS in unstable for unrelated reasons and will be trivial to update to use wxwidgets3.0's GTK3 flavour once that is addressed, I've made a wxwidgets3.0 upload to drop the GTK2 flavour packages. Cheers, Olly
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
On Mon, 28 Oct 2019, Olly Betts wrote: However, then the build fails for me running tests using ccache - the problem is that $HOME is /sbuild-nonexistent under sbuild, which doesn't exist, and cache tries to create its cache under $HOME/.ccache by default. I don't have that, but I also have failing tests. I think this is #935817 - if so it's not tests using ccache that are the problem, but that meson automatically tries to use ccache if it's installed, plus mk-sbuild seems to install ccache in chroots. (That seems a mis-feature to me - the usual ways to use ccache are to either something like `CC="ccache gcc"`, or to add /usr/lib/ccache to your PATH ahead of /usr/bin, which both require a concious extra action, but I think that's a good thing - it's surprising for building some software to create a persistent hidden directory under your home directory potentially using a lot of diskspace just because the package happens to use meson for its build system and you're on a multi-user system which happens to have ccache installed). It seems brittle for a build to fail because an extra package is installed, especially one like ccache which might reasonably have been added to a chroot to speed up builds. [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' spin.blif -o spin.asc FAILED: spin.asc /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' spin.blif -o spin.asc spin.blif:50: fatal error: invalid formal-actual ninja: build stopped: subcommand failed. For me, fpga also fails, but the failure looks different: I also see that eatmydata seems to cause problems (#917501), which again is something that might reasonably be in use. I've been running my package builds under it for the best part of a decade (including many NMUs) and this is the first issue I've hit. I tried temporarily disabling that, but meson still fails to build. The fpga test failure is also occurring with autopkgtest: https://ci.debian.net/data/packages/unstable/amd64/m/meson/latest-autopkgtest/log.gz Jussi also mentioned it. Perhaps it's related to the recent upload of fpga-icestorm? Scott
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
On Mon, Oct 28, 2019 at 07:53:24AM +0100, Martin Pitt wrote: > Olly Betts [2019-10-27 11:52 +1300]: > > However, then the build fails for me running tests using ccache - the > > problem is that $HOME is /sbuild-nonexistent under sbuild, which > > doesn't exist, and cache tries to create its cache under $HOME/.ccache > > by default. > > I don't have that, but I also have failing tests. I think this is #935817 - if so it's not tests using ccache that are the problem, but that meson automatically tries to use ccache if it's installed, plus mk-sbuild seems to install ccache in chroots. (That seems a mis-feature to me - the usual ways to use ccache are to either something like `CC="ccache gcc"`, or to add /usr/lib/ccache to your PATH ahead of /usr/bin, which both require a concious extra action, but I think that's a good thing - it's surprising for building some software to create a persistent hidden directory under your home directory potentially using a lot of diskspace just because the package happens to use meson for its build system and you're on a multi-user system which happens to have ccache installed). It seems brittle for a build to fail because an extra package is installed, especially one like ccache which might reasonably have been added to a chroot to speed up builds. > > [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 > > simple/spin.pcf' spin.blif -o spin.asc > > FAILED: spin.asc > > /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' > > spin.blif -o spin.asc > > spin.blif:50: fatal error: invalid formal-actual > > ninja: build stopped: subcommand failed. > > For me, fpga also fails, but the failure looks different: I also see that eatmydata seems to cause problems (#917501), which again is something that might reasonably be in use. I've been running my package builds under it for the best part of a decade (including many NMUs) and this is the first issue I've hit. I tried temporarily disabling that, but meson still fails to build. Cheers, Olly
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
Hello Jussi, Olly, Olly Betts [2019-10-27 11:52 +1300]: > However, then the build fails for me running tests using ccache - the > problem is that $HOME is /sbuild-nonexistent under sbuild, which > doesn't exist, and cache tries to create its cache under $HOME/.ccache > by default. I don't have that, but I also have failing tests. > [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 > simple/spin.pcf' spin.blif -o spin.asc > FAILED: spin.asc > /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' > spin.blif -o spin.asc > spin.blif:50: fatal error: invalid formal-actual > ninja: build stopped: subcommand failed. For me, fpga also fails, but the failure looks different: Found ninja-1.9.0 at /usr/bin/ninja [0/1] /usr/bin/python3 /tmp/meson-0.52.0/meson.py --internal regenerate '/tmp/meson-0.52.0/test cases/fpga/1 simple' '/tmp/meson-0.52.0/b 2eab81bce2' --backend ninja The Meson build system Version: 0.52.0 Source dir: /tmp/meson-0.52.0/test cases/fpga/1 simple Build dir: /tmp/meson-0.52.0/b 2eab81bce2 Build type: native build Project name: lattice Project version: undefined C compiler for the host machine: cc (gcc 9.2.1 "cc (Debian 9.2.1-14) 9.2.1 20191025") C linker for the host machine: GNU ld.bfd 2.33.1 Host machine cpu family: x86_64 Host machine cpu: x86_64 Build targets in project: 5 Found ninja-1.9.0 at /usr/bin/ninja [1/3] /usr/bin/yosys -q -p 'synth_ice40 -blif spin.blif' '../test cases/fpga/1 simple/spin.v' [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' spin.blif -o spin.asc FAILED: spin.asc /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' spin.blif -o spin.asc spin.blif:50: fatal error: invalid formal-actual ninja: build stopped: subcommand failed. ninja explain: output build.ninja older than most recent input ../test cases/fpga/1 simple/meson.build (1572245204477705522 vs 1572245204489705475) ninja explain: output spin.blif doesn't exist ninja explain: spin.blif is dirty ninja explain: spin.asc is dirty ninja explain: spin.bin is dirty This is an up to date Debian sid amd64 chroot, with /dev/shm bind-mounted from the host (otherwise it fails way earlier). So I'm afraid I can't upload this either :/ Martin
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
On Fri, Oct 25, 2019 at 01:52:31AM +0100, Olly Betts wrote: > I'll try to sort out my chroots over the weekend, but meanwhile if you > can get somebody else to sponsor please go for it. I've rebuilt my build chroots in a larger partition. However, then the build fails for me running tests using ccache - the problem is that $HOME is /sbuild-nonexistent under sbuild, which doesn't exist, and cache tries to create its cache under $HOME/.ccache by default. Debian policy says: | Secondly, required targets may write to | "/tmp", "/var/tmp" and to the directory specified by the "TMPDIR" | environment variable, but must not depend on the contents of any of | these. | | This restriction is intended to prevent source package builds creating | and depending on state outside of themselves, thus affecting multiple | independent rebuilds. In particular, the required targets must not | attempt to write into "HOME". So the package build really shouldn't assume it can write under the home directory. If I add this to debian/rules that avoids that problem: export CCACHE_DIR=/tmp/ccache But I still see a number of test failures (sorry about the unhelpful wrapping): [58/75] Generating MesonDep2-1.0.gir with a custom command. FAILED: gir/dep1/dep2/MesonDep2-1.0.gir /usr/bin/g-ir-scanner -pthread -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include --no-libtool --namespace=MesonDep2 --nsversion=1.0 --warn-all --output gir/dep1/dep2/MesonDep2-1.0.gir '-I/<>/test cases/frameworks/7 gnome/gir/dep1/dep2' -I/<>/tmpuyjyogvd/gir/dep1/dep2 --filelist=/<>/tmpuyjyogvd/gir/dep1/dep2/7cbf35a@@dep2lib@sha/MesonDep2_1.0_gir_filelist --include=GObject-2.0 --symbol-prefix=meson --identifier-prefix=Meson --cflags-begin -DMESON_TEST -fsanitize=address -fno-omit-frame-pointer -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include --cflags-end -lasan --library dep2lib -L/<>/tmpuyjyogvd/gir/dep1/dep2 --extra-library=gobject-2.0 --extra-library=glib-2.0 --sources-top-dirs '/<>/test cases/frameworks/7 gnome/subprojects/' --sources-top-dirs /<>/tmpuyjyogvd/subprojects/ g-ir-scanner: link: x86_64-linux-gnu-gcc -pthread -o /<>/tmpuyjyogvd/tmp-introspect8x4pya0_/MesonDep2-1.0 /<>/tmpuyjyogvd/tmp-introspect8x4pya0_/MesonDep2-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/<>/tmpuyjyogvd/gir/dep1/dep2 -Wl,-rpath,/<>/tmpuyjyogvd/gir/dep1/dep2 -lasan -ldep2lib -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 ==19640==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Command '['/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/MesonDep2-1.0', '--introspect-dump=/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/functions.txt,/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/dump.xml']' returned non-zero exit status 1. (that seems to occur twice?!) [1/4] ccache cc -Ivalaprog@exe -I. '-I../test cases/failing build/1 vala c werror' -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 'valaprog@exe/unused-var.c.o' -MF 'valaprog@exe/unused-var.c.o.d' -o 'valaprog@exe/unused-var.c.o' -c '../test cases/failing build/1 vala c werror/unused-var.c' FAILED: valaprog@exe/unused-var.c.o ccache cc -Ivalaprog@exe -I. '-I../test cases/failing build/1 vala c werror' -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 'valaprog@exe/unused-var.c.o' -MF 'valaprog@exe/unused-var.c.o.d' -o 'valaprog@exe/unused-var.c.o' -c '../test cases/failing build/1 vala c werror/unused-var.c' ../test cases/failing build/1 vala c werror/unused-var.c:1:2: error: #warning "something" [-Werror=cpp] 1 | #warning "something" | ^~~ ../test cases/failing build/1 vala c werror/unused-var.c: In function ‘somelib’: ../test cases/failing build/1 vala c werror/unused-var.c:6:7: error: unused variable ‘unused_var’ [-Werror=unused-variable] 6 | int unused_var; | ^~ cc1: all warnings being treated as errors [5/5] cc -o bobuser 'bobuser@exe/bobuser.c.o' -Wl,--as-needed -Wl,--no-undefined -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,--start-group libbob.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/' '-Wl,-rpath-link,/<>/b 52a78b9866/' FAILED: bobuser cc -o bobuser 'bobuser@exe/bobuser.c.o' -Wl,--as-needed -Wl,--no-undefined -g -O2 -fdebug-prefix-map=/<>=.
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
On Thu, Oct 24, 2019 at 10:12:08PM +0100, Olly Betts wrote: > On Fri, Oct 25, 2019 at 12:02:11AM +0300, Jussi Pakkanen wrote: > > https://mentors.debian.net/package/meson > > > > Feel free to upload it to the archive. > > Thanks for the quick response. Building now. It seems this package requires more diskspace to build than my build chroot partition has (or perhaps I've just managed to break my chroot recently). I'll try to sort out my chroots over the weekend, but meanwhile if you can get somebody else to sponsor please go for it. Cheers, Olly
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
Control: tags -1 +pending On Fri, Oct 25, 2019 at 12:02:11AM +0300, Jussi Pakkanen wrote: > On Thu, Oct 24, 2019 at 11:03 PM Olly Betts wrote: > > > However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that > > your package has a build-dependency on libwxgtk3.0-dev which doesn't > > result in any shlib dependencies in the built packages. If this package > > is not actually used this build dependency should be dropped; if it's > > used during the build then you want to update to use > > libwxgtk3.0-gtk3-dev instead; if it should result in a shlib dependency, > > please debug! > > The reason for this is that Meson only needs wxwidgets to build and > execute its unit tests. They are not installed or used, because we > only test that people can find and build against wxwidgets libraries. > > I have updated the packaging to use the new package. It can be found in > mentors: > > https://mentors.debian.net/package/meson > > Feel free to upload it to the archive. Thanks for the quick response. Building now. > You should note that the FPGA tests don't pass now. This has nothing > to do with this change, it seems that Icestorm packages are broken in > some way. Presumably these are autopkgtests rather than tests run during the package build? Cheers, Olly
Processed: Re: Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
Processing control commands: > tags -1 +pending Bug #943437 [src:meson] src:meson: Please update/remove libwxgtk3.0-dev build-dependency Added tag(s) pending. -- 943437: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943437 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
On Thu, Oct 24, 2019 at 11:03 PM Olly Betts wrote: > However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that > your package has a build-dependency on libwxgtk3.0-dev which doesn't > result in any shlib dependencies in the built packages. If this package > is not actually used this build dependency should be dropped; if it's > used during the build then you want to update to use > libwxgtk3.0-gtk3-dev instead; if it should result in a shlib dependency, > please debug! The reason for this is that Meson only needs wxwidgets to build and execute its unit tests. They are not installed or used, because we only test that people can find and build against wxwidgets libraries. I have updated the packaging to use the new package. It can be found in mentors: https://mentors.debian.net/package/meson Feel free to upload it to the archive. You should note that the FPGA tests don't pass now. This has nothing to do with this change, it seems that Icestorm packages are broken in some way.
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
Package: src:meson Version: 0.52.0-1 Severity: serious Justification: blocks the almost-complete wxwidgets3.0-gtk3 transition According to the transition tracker, the wxwidgets3.0-gtk3 transition is 96% and the only remaining blockers are a missing mips64el build of codelite (currently building) and a missing mipsel build of mrpt (due for AUTORM from testing on 2019-10-28): https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that your package has a build-dependency on libwxgtk3.0-dev which doesn't result in any shlib dependencies in the built packages. If this package is not actually used this build dependency should be dropped; if it's used during the build then you want to update to use libwxgtk3.0-gtk3-dev instead; if it should result in a shlib dependency, please debug! Let me know if you'd like me to NMU a fix for this. Cheers, Olly
