Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386
On Thu, 9 May 2024 at 19:51, Shmerl wrote: > Do you think it's worth it it to file the bug to rust > upstream too: https://github.com/rust-lang/rust/issues > May be wider Rust developers can have an insight. > Or it's something very Debian specific? I don't use Rust, but I would imagine that if someone manages to replicate the issue with an up to date rustup or whatever it is that that people use to get their up to date toolchain, then it might make sense to for them to report it upstream.
Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386
On Sun, 5 May 2024 at 04:33, Shmerl wrote: > May be for rustc? It's worth filing the bug if it's not clear what the > root cause is. If it's not really rustc, developers will point that out. Filed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070470
Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386
On Sat, 4 May 2024 at 13:27, Jussi Pakkanen wrote: > Disabling tests is also not a great because it just hides the bug. > Thus other packages that actually use this functionality are going to > hit this eventually and file more bugs on Meson. That is a waste of > everybody's time and energy. I managed to replicate this bug without Meson. Attached is sample code plus a build script that runs a few compilation commands in a shell script. The script runs fine on x64_64 but fails on arm64 (and probably also x86, but I did not test it). This would imply something wonky going on in the toolchain. The question then becomes where this should be reported to. rustcmixbug.tar.gz Description: GNU Zip compressed data
Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386
On Fri, 3 May 2024 at 06:42, Shmerl wrote: > If real solution for this requires upstream involvement, may be it's worth > disabling > these tests, until upstream is actually not broken? That would at least move > things > forward, otherwise it might be stuck for who knows how long? I am the upstream. All of this works in our CI and other distros meaning that the only person who can reasonably fix this is also me. Disabling tests is also not a great because it just hides the bug. Thus other packages that actually use this functionality are going to hit this eventually and file more bugs on Meson. That is a waste of everybody's time and energy.
Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386
On Thu, 2 May 2024 at 01:48, Shmerl wrote: > > Ubuntu fixed it with this patch: > > https://launchpadlibrarian.net/715235929/meson_1.3.2-1_1.3.2-1ubuntu1.diff.gz > > > > Can this fix be added to Debian? Meson has been stuck without > moving to testing for a very long time and now it seems to be > stalling Mesa in result too. I looked into this and the answer is sadly no. That patch explicitly adds -lc to every link which breaks other tests that depend on it not being there. These tests have been added after Ubuntu made that change, so they won't show up there. They will once they update Meson to a newer version. Along the way I found other bugs, such as bindgen not working at all out of the box. I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070241 for that. All in all this is getting into very deep Debian toolchain magic, of which I have little knowledge. :(
Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386
On Thu, 21 Dec 2023 at 14:57, Paul Gevers wrote: > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 30 days as having a Release Critical bug in > testing [1]. Your package src:meson has been trying to migrate for 31 > days [2]. Hence, I am filing this bug. The version in unstable fails its > own autopkgtest on arm64 and i386 (and armel, but that's not a regression). The reason for this is the following (on i86, but the same applies to arm64 too): 2428s = note: /usr/bin/ld: /usr/lib/gcc/i686-linux-gnu/13/../../../i386-linux-gnu/libz.a(inflate.o): in function `.L707': 2428s (.text+0x2c79): undefined reference to `__stack_chk_fail_local' 2428s /usr/bin/ld: /usr/lib/gcc/i686-linux-gnu/13/../../../i386-linux-gnu/libz.a(inflate.o): in function `inflateSync': 2428s (.text+0x3471): undefined reference to `__stack_chk_fail_local' 2428s /usr/bin/ld: /usr/lib/gcc/i686-linux-gnu/13/../../../i386-linux-gnu/libz.a(inftrees.o): in function `inflate_table': 2428s (.text+0xea7): undefined reference to `__stack_chk_fail_local' 2428s /usr/bin/ld: prog: hidden symbol `__stack_chk_fail_local' isn't defined 2428s /usr/bin/ld: final link failed: bad value 2428s collect2: error: ld returned 1 exit status This happens when mixing code compiled natively with code compiled with rustc. To the best of our knowledge, this is a Rust toolchain bug because the exact same compilation commands work on other platforms. The missing symbol has double leading underscores implying it is a compiler internal thing and the test we are using does not attempt to do anything magical, only compile and link C and Rust code together in the same binary.
Bug#1041537: python3 platlib points again to /usr/local
On Wed, 2 Aug 2023 at 12:01, Enrico Zini wrote: > > I'm confused. Why is this not set by default when building packages? > > FWICT this is a custom patch in Debian to make Python use deb paths.In > > this case Meson is doing exactly what you ask it to do, which is to > > use local paths because that environment variable is not set to `deb`. > > It will, though it's not there yet. Based on that thread I'd say that this is not a bug in Meson at all. Can I just close it or should it be reassigned to some other package so it is not forgotten?
Bug#1041537: python3 platlib points again to /usr/local
On Fri, 21 Jul 2023 at 14:09, Jeremy BĂcha wrote: > We have been working around this in several Debian packages by setting > this in debian/rules: > export DEB_PYTHON_INSTALL_LAYOUT = deb I'm confused. Why is this not set by default when building packages? FWICT this is a custom patch in Debian to make Python use deb paths.In this case Meson is doing exactly what you ask it to do, which is to use local paths because that environment variable is not set to `deb`.
Bug#1042050: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4:(.text.startup+0x3): undefined reference to `hidden_function'
On Wed, 26 Jul 2023 at 00:16, Lucas Nussbaum wrote: > Relevant part (hopefully): > > /usr/bin/ld: bobuser.p/bobuser.c.o: in function `main': > > ./b 52a78b9866/../test cases/failing build/2 hidden > > symbol/bobuser.c:4:(.text.startup+0x3): undefined reference to > > `hidden_function' > > collect2: error: ld returned 1 exit status As before, that is not the real issue. It is this: --- ==796327==ERROR: LeakSanitizer: detected memory leaks Direct leak of 280 byte(s) in 2 object(s) allocated from: #0 0x7fcf1c99ef97 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x7fcf1c77e2a5 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x602a5) (BuildId: 3ca2ab24e2ecf8bb465ae4b321ee5d69412afd50) Indirect leak of 4172 byte(s) in 2 object(s) allocated from: #0 0x7fcf1c99f5bf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x7fcf1c77e25d in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x6025d) (BuildId: 3ca2ab24e2ecf8bb465ae4b321ee5d69412afd50) Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0x7fcf1c99ef97 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x7fcf1c77e2a5 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x602a5) (BuildId: 3ca2ab24e2ecf8bb465ae4b321ee5d69412afd50) Indirect leak of 28 byte(s) in 1 object(s) allocated from: #0 0x7fcf1c99f5bf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x7fcf1c394017 in __vasprintf_internal libio/vasprintf.c:116 #2 0x8876f375b14d25ff () SUMMARY: AddressSanitizer: 4576 byte(s) leaked in 6 allocation(s). -- This is actually a bug in gobject-introspection. It has already been fixed upstream. Dunno what the schedule is for getting that into a release and on to Debian.
Bug#1032168: meson: autopkgtest fills disk completely
On Thu, 9 Mar 2023 at 13:54, Paul Gevers wrote: > Of course I expect you can also just use a porterbox which are there for > this reason: https://wiki.debian.org/PorterBoxHowToUse I have requested access to those but nothing has happened as of yet and I have no idea how long that processing is going to take.
Bug#1032168: meson: autopkgtest fills disk completely
On Thu, 9 Mar 2023 at 12:24, Paul Gevers wrote: > I manually started an test run on s390x and so far (still running) the > tests consumes 100 GB of disk. I found it has a big file at least here: > > /scratch/tmp/autopkgtest-lxc.o724mxl4/downtmp/build.pyq/src/b > ffd9f21ec8/host_test.p > > # ls -alh res1-cpp.h This file is created by a custom executable: https://github.com/mesonbuild/meson/blob/master/test%20cases/common/105%20generatorcustom/gen.c What _probably_ happens is that this piece gets stuck in an eternal loop: char c; while((c = fgetc(input)) != EOF) { fputc(c, output); } Looking at the docs, that should probably be an "unsigned char c". But the question is why did this use to work. What has changed? Something in the toolchain? If you have shell access to the problematic machines, then you can run this test manually with these commands: cd ./meson.py test\ cases/common/105\ generatorcustom build ninja -C build
Bug#1032168: meson: autopkgtest fills disk completely
On Wed, 8 Mar 2023 at 20:47, Paul Gevers wrote: > Having said that, let me open the discussion on what I expect from this > bug. I *don't* expect all tests on our infrastructure to be totally > resilient to all restrictions we have. Although several tens of GB is a > lot, I also realize that it isn't *that* much, so if you understand why > meson suddenly needs considerably more disk space and that's to be > expected, then I'm fine with closing this bug and have meson on the In my opinion this is definitely a bug. I don't know where, though. Whenever I do a new release I run a full package build + test suite run and all that in an isolated VM (with pbuilder). That image has only a single 40 GB file system. I have never had a problem with disk space usage even though this image has all the dependency packages installed twice: once on the main install and once in pbuilder. I just checked and the image has 8 GB of free disk space so doing a full package rebuild should take less than that.
Bug#1032168: meson: autopkgtest fills disk completely
On Wed, 1 Mar 2023 at 21:09, Paul Gevers wrote: > No, but e.g. on s390x it never ever came close to filling the disk, so > the peaks of before today here are really new: > https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html > (but apparently another package is also suddenly misbehaving, so maybe > it's indeed something *below* meson. I'll try to figure out tonight or > tomorrow morning. Did you manage to discover whether that is the same issue or something different?
Bug#1032168: meson: autopkgtest fills disk completely
On Tue, 28 Feb 2023 at 23:30, Paul Gevers wrote: > With your last upload of meson, we're seeing issues on > ci.debian.net. It turns out that the autopkgtest of meson is using so > much disk space that the most of our hosts runs out of it when meson > is tested. This is weird. As far as we know we have not made any changes that should affect disk usage in 1.0.1. Is /tmp on the same file system as the rest of the image or is it a separate partition? Is it possible to know how close to filling up the disk the old succeeding builds got? And how much disk space is given to the build in total?
Bug#1029250: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'
On Fri, 20 Jan 2023 at 13:06, Lucas Nussbaum wrote: > Relevant part (hopefully): > > /usr/bin/ld: bobuser.p/bobuser.c.o: in function `main': > > ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: > > undefined reference to `hidden_function' > > collect2: error: ld returned 1 exit status This is the umpteenth time this has been reported and the error message is as wrong as always. The actual error has to do with TAP parsing. It should be fixed by this, which will be in the next point release: https://github.com/mesonbuild/meson/pull/11324
Bug#1015132: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'
On Sat, 16 Jul 2022 at 17:04, Lucas Nussbaum wrote: > Relevant part (hopefully): > > /usr/bin/ld: bobuser.p/bobuser.c.o: in function `main': > > ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: > > undefined reference to `hidden_function' > > collect2: error: ld returned 1 exit status This is the second time (at least) that this issue has been incorrectly reported. This is not a test failure. As you can tell the test name has "failing build" in it, which means that failing to compile is the correct behaviour. If this report has been done by hand, please in the future report the thing that actually failed (if any). If this is an automated test then please fix it to not report spurious failures like this. Thanks,
Bug#1004107: meson: flaky autopkgtest on armhf: dictionary changed size during iteration -> timeout
On Thu, 5 May 2022 at 22:39, Paul Gevers wrote: > It just occurred to me that it may be useful to try and reduce the > number of concurrent running tests to something you would expect on a > more normal computer (under conditions where the framework is better > tested). Our armel host has 160 cores, similar, our amd64 ci-worker13 > host has 56. No harm in trying I guess: https://github.com/mesonbuild/meson/pull/10358
Bug#1009097: meson: (autopkgtest) needs update for python3.10: MesonVersionMismatchException.__init__() missing 1 required positional argument: 'current_version'
On Fri, 8 Apr 2022 at 22:21, Paul Gevers wrote: > >> I copied some of the output at the bottom of this report. I noticed that > >> there is a new version of meson in unstable, it fails too, but in a > >> different way. > > > > Can you provide the logs for that? > > Traceback (most recent call last): >File "/usr/bin/meson", line 29, in > sys.exit(mesonmain.main()) > > mesonbuild.interpreterbase.exceptions.InterpreterException: Problem > encountered: Python3 purelib path seems invalid? This should be fixed by https://github.com/mesonbuild/meson/pull/10254 This is due to we having to poke distutils internals because Debian patched distutils to produce different results for install directories than sysconfig (the latter was incorrect). Is there now a guarantee that starting with 3.10 sysconfig points to the correct place (I don't remember the details, but it had something to do with dist-packages vs site-packages).
Bug#1009097: meson: (autopkgtest) needs update for python3.10: MesonVersionMismatchException.__init__() missing 1 required positional argument: 'current_version'
On Thu, 7 Apr 2022 at 11:36, Paul Gevers wrote: > I copied some of the output at the bottom of this report. I noticed that > there is a new version of meson in unstable, it fails too, but in a > different way. Can you provide the logs for that? I have looked at the error message and it makes zero sense. It's complaining about a missing argument to a constructor but grepping says that every place we create said classes we pass two arguments. In fact it seems like something goes wrong in Python's serialisation/deserialisation code. In fact I have a vague suspicion that the underlying issue might be the same as for #1004107. Sadly nobody has managed to reproduce either of those. If one could run a full distro built with tsan, this issue would probably reveal itself fairly quickly.
Bug#1008189: meson: gnome module incorrectly requires gtk4-update-icon-cache
On Thu, 24 Mar 2022 at 05:03, Jeremy Bicha wrote: > Therefore, please cherry-pick this commit: > https://github.com/mesonbuild/meson/commit/dac212e1bba7 This has already been tagged for the .1 release: https://github.com/mesonbuild/meson/milestone/79?closed=1 Is that sufficient or do you need an interim distropatch upload?
Bug#1004107: meson: flaky autopkgtest on armhf: dictionary changed size during iteration -> timeout
On Thu, 20 Jan 2022 at 23:33, Paul Gevers wrote: > I looked at the results of the autopkgtest of you package on armhf > because it was showing up as a regression for the upload of > python-defaults and setuptools. I noticed that the test regularly fails, > what's worse, it also seems to hang as the test is killed because it > hits an autopkgtest timeout. If we look at the backtrace: > Running tests with 160 workers > Exception in thread Thread-1: > Traceback (most recent call last): >File "/usr/lib/python3.9/threading.py", line 973, in _bootstrap_inner > self.run() >File "/usr/lib/python3.9/concurrent/futures/process.py", line 317, in run > result_item, is_broken, cause = self.wait_result_broken_or_wakeup() >File "/usr/lib/python3.9/concurrent/futures/process.py", line 376, in > wait_result_broken_or_wakeup > worker_sentinels = [p.sentinel for p in self.processes.values()] >File "/usr/lib/python3.9/concurrent/futures/process.py", line 376, in > > worker_sentinels = [p.sentinel for p in self.processes.values()] > RuntimeError: dictionary changed size during iteration This is all Python's internal code. Further, Meson does not do any fancy threading stuff itself, it uses Python's thread and process executors to queue up a bunch of work and then wait for it to be done. According to Python's documentation you don't need to do any locking or similar to submit new work, you can call the submit method directly. All of this would seem to indicate that the issue might lie somewhere in Python's multithreading code. At the very least I have no idea how I should go about debugging that issue.
Bug#998124: meson: gnome module missing install_dir fix for c_template
On Mon, 1 Nov 2021 at 23:33, Joshua Peisach wrote: > Nemo (Cinnamon's file manager) is failing to build with this same "KeyError: > 'install_dir'" issue, and I feel like it is a 0.60 regression as previous > versions didn't fail. > > Hope this gets fixed soon. This is already fixed upstream and will be in 0.60.1 which will be out soonish; https://github.com/mesonbuild/meson/pull/9484
Bug#997121: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'
On Sat, 23 Oct 2021 at 22:07, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > /usr/bin/ld: bobuser.p/bobuser.c.o: in function `main': > > ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: > > undefined reference to `hidden_function' > > collect2: error: ld returned 1 exit status That is not the reason it failed. That is a test that verifies that building a project with missing symbols fails and it is working as expected. The real reason is this one: /usr/src/rustc-1.56.0//library/std/src/f64.rs:(.text._ZN3std3f6421_$LT$impl$u20$f64$GT$4lerp17h11b1be7b614aa463E+0x22): undefined reference to `fma' /usr/bin/ld: libstuff.a(std-80e93fdce0e07191.std.9561c7b1-cgu.6.rcgu.o): in function `std::f32lerp': /usr/src/rustc-1.56.0//library/std/src/f32.rs:(.text._ZN3std3f3221_$LT$impl$u20$f32$GT$4lerp17he122406d489ebe9dE+0x20): undefined reference to `fmaf' This is due to the fact that Rust changed something and now requires -lm whereas earlier it did not. This has already been fixed in master and will be in the next release that should hopefully come out tomorrow.
Bug#982865:
On Tue, 9 Mar 2021 at 21:51, Nicholas Brown wrote: > Will 0.57.1 be migrated to unstable? Or perhaps even to testing? > (I'm keen to see the parallel LTO support in 0.57 available in Bullseye) Unstable is frozen for build systems so 0.57 won't be allowed in Bullseye. The version in unstable will only be updated after the release.
Bug#982865:
On Wed, 24 Feb 2021 at 21:57, Nicholas Brown wrote: > Is this fixed in the 0.57.1 release? Yes. You can test it yourself if you want, 0.57.1 is in experimental.
Bug#982865: meson: diff for NMU version 0.57.0+really0.56.2-0.1
On Mon, 15 Feb 2021 at 23:21, Sebastian Ramacher wrote: > Silently breaking hardening build flags of roughly 430 packages is > definitely a large and disruptive change. The rc was uploaded to experimental a week ago so that people could use it to flush out problems like these. Apparently no-one did. Would it be possible to set up an automatic gating system of some kind for build-essential packages so these sort of things will never happen again in the future?
Bug#965278: meson 0.55.0 causes build failures
On Sat, 18 Jul 2020 at 20:12, Adrian Bunk wrote: > I cannot judge whether this is a meson regression, > or existing bugs that just happened to work with > older meson. I don't know much about the internals of gobject-introspection but this seems like a case of broken typelib files or paths to them. At least one of those bugs is related to Vala. A new version of Vala was uploaded at the beginning of this month. This might or might not be related.
Bug#963546: meson: autopkgtest failures
On Fri, 26 Jun 2020 at 14:09, Gianfranco Costamagna wrote: > > > I asked in Ubuntu to move the meson autopkgtests to a machine with more > > > ram memory, and > > > now the test passes. > > > The Ubuntu VMs have 1536MB of ram, probably not enough for the testsuite > > > to pass. > > > > Good that it works, but that seems a bit strange. I run the test suite > > on an x86 Debian VM with 4 gigs of ram and it passes without problems. > > Probably if you lower the 4GB to 1.5GB you will get the same failure? D'oh! I accidentally read that as 15 GB rather than 1.5GB because I blindly assumed that there is no way the default value can be that low. Compiling e.g. any C++ program of decent size makes the linker take several gigabytes of ram easily.
Bug#963546: meson: autopkgtest failures
On Fri, 26 Jun 2020 at 10:48, Gianfranco Costamagna wrote: > I asked in Ubuntu to move the meson autopkgtests to a machine with more ram > memory, and > now the test passes. > The Ubuntu VMs have 1536MB of ram, probably not enough for the testsuite to > pass. Good that it works, but that seems a bit strange. I run the test suite on an x86 Debian VM with 4 gigs of ram and it passes without problems.
Bug#963546: meson: autopkgtest failures
On Tue, 23 Jun 2020 at 16:36, Gianfranco Costamagna wrote: > Hello, as you can see, two tests can't be run on ppc64el and s390x, because > of missing: > g++-arm-linux-gnueabihf and ldc > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/m/meson/6017346/log.gz > Marking the two tests as "skip-not-installed" works Thanks, this will be in the next upload. > Also, I noticed a failure on Ubuntu: > c++ -Iextralibexe@exe -I. '-I../test cases/frameworks/1 boost' -I/usr/include > -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch > -Wnon-virtual-dtor -std=c++14 -g -pthread -DBOOST_DATE_TIME_DYN_LINK=1 > -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_SETUP_DYN_LINK=1 > -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_USE_DLL=1 > -DBOOST_LOG_DYN_LINK=1 -DBOOST_ALL_NO_LIB -MD -MQ > 'extralibexe@exe/extralib.cpp.o' -MF 'extralibexe@exe/extralib.cpp.o.d' -o > 'extralibexe@exe/extralib.cpp.o' -c '../test cases/frameworks/1 > boost/extralib.cpp' > c++: fatal error: Killed signal terminated program cc1plus > > do you have any clue? At this point Meson is no longer involved. Ninja has invoked c++ and that process then crashes. Running that command by hand in the same system should result in the same crash. >From what I can tell this is either a bug in GCC or there is some watchdog that kills the process for whatever reason such as running out of memory. The latter can be a symptom of the former.
Bug#952610: fixed in meson 0.53.2-2
On Tue, 10 Mar 2020 at 11:30, Gianfranco Costamagna wrote: > > Can you test if the issue is fixed fro you if you add > > stderr=subprocess.DEVNULL to debcrossgen line 38? > > > > ./debian/tests/crossbuild 1> /dev/null > dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf > does not match CC system type x86_64-linux-gnu, try setting a correct CC > environment variable D'oh, that line number should have been 83, not 38. :facepalm:
Bug#952610: fixed in meson 0.53.2-2
On Mon, Mar 2, 2020 at 4:27 PM Gianfranco Costamagna wrote: > lets see the sum of the issues without the stderr change > > amd64: > crossbuild FAIL stderr: dpkg-architecture: warning: specified GNU > system type arm-linux-gnueabihf does not match CC system type > powerpc64le-linux-gnu, try setting a correct CC environment variable Can you test if the issue is fixed fro you if you add stderr=subprocess.DEVNULL to debcrossgen line 38? > > That should already be happening. AFAIUI the exhaustive test has a > > dependency on all build deps of Meson, which includes valac and rustc. > > > > nack on this. Fortunately there is a valac in unstable but not in testing, > and you can see there is no mention of meson autopkgtest against it. That is strange, because if you look at the install log for Ubuntu tests: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/m/meson/20200303_171925_00939@/log.gz both valac and rustc are installed. Maybe the autopkg dependency lookup code gets confused by @builddeps@ somehow?
Bug#952610: fixed in meson 0.53.2-2
On Mon, Mar 2, 2020 at 1:15 PM Gianfranco Costamagna wrote: > The following patch is not enough, because of something printed on stderr. > > I'm attaching a "fix" (better would be do not throw stuff on stderr) > crossbuild FAIL stderr: dpkg-architecture: warning: specified GNU > system type arm-linux-gnueabihf does not match CC system type > x86_64-linux-gnu, try setting a correct CC environment variable I hate, hate, hate, hate this feature. It is the stupidest policy choice and for some reason many test frameworks do that, sometimes even silently. The only thing this accomplishes is that people will run their tests with a wrapper script that does ./realcommand 2>&1, because if you call any external program then you have lost control of what gets printed to stderr. Some of those programs are chatty. The proper way of detecting failures is the exit code. That being said, does this happen on all platforms or only a subset of them? > I also cherry-picked an upstream test failure when python is removed and > changed to python2 (a change that is retro-compatible, and will break also > Debian on the next few days) Please file this as a pull request upstream. All big changes like these should go in master first. > Also, please depend on rustc and valac on autopkgtests, so on > each new rustc and valac upstream releases, meson autopkgtests will be > triggered for regressions! That should already be happening. AFAIUI the exhaustive test has a dependency on all build deps of Meson, which includes valac and rustc.
Bug#952610: meson: autopkgtests regressions
On Wed, Feb 26, 2020 at 6:12 PM Gianfranco Costamagna wrote: > +-self._simple_test('python', 'python') > ++self._simple_test('python', 'python2') This fix is not correct, because it breaks the test suite in master: https://github.com/mesonbuild/meson/pull/6700 > meson.build:1:0: ERROR: Unknown compiler(s): ['cc', 'gcc', 'clang', 'pgcc', > 'icc'] > The follow exceptions were encountered: > Running "cc --version" gave "[Errno 2] No such file or directory: 'cc': 'cc'" > Running "gcc --version" gave "[Errno 2] No such file or directory: 'gcc': > 'gcc'" > Running "clang --version" gave "[Errno 2] No such file or directory: 'clang': > 'clang'" > Running "pgcc --version" gave "[Errno 2] No such file or directory: 'pgcc': > 'pgcc'" > Running "icc --version" gave "[Errno 2] No such file or directory: 'icc': > 'icc'" This should be fixed by changing debian/tests/control's deps for the crossbuild test to be these: Depends: meson, g++, g++-arm-linux-gnueabihf Would it be possible for you to test this fix?
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 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#917501: meson: FTBFS (failing tests)
On Fri, Dec 28, 2018 at 1:57 AM Santiago Vila wrote: > The build was made in my autobuilder with "dpkg-buildpackage -A" > but it also fails here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meson.html > > where you can get a full build log if you need it. The actual error message was not in your snippet, but from the log it is this: Traceback (most recent call last): File "run_unittests.py", line 2044, in test_rpath_uses_ORIGIN self.assertTrue(rpath) AssertionError: None is not true The test is verifying that libraries and executables have the correct rpath. However in this case, for some reason I don't understand, the files built in the second step do not have rpaths at all. I made a PR improving the message here: https://github.com/mesonbuild/meson/pull/4684 It's probably not particulary useful but still. Does anyone have any suggestions on what the second build setup has would cause rpaths to not be there?
Bug#911697: at-spi2-core: causes SIGSEGV because of improper quoting of G_LOG_DOMAIN
On Fri, Nov 2, 2018 at 10:00 PM Samuel Thibault wrote: > > Simply running your build with current Meson trunk is enough to test the > > issue. > > I simply applied the patch on top of my 0.48.1-1 package, and it fixed > the documentation build without breaking the binary indeed. Backporting the patch turned out to be slightly trickier than expected. Can you test again with the head of branch 0.48 as discussed here: https://github.com/mesonbuild/meson/issues/4452 If your test passes we will do a release immediately after that. Thanks.
Bug#911697: at-spi2-core: causes SIGSEGV because of improper quoting of G_LOG_DOMAIN
On Wed, Oct 24, 2018 at 10:32 AM Samuel Thibault wrote: > So the issue is in meson itself: it seems one can't get > > compile_args: [ '-DG_LOG_DOMAIN="dbind"' ], > > to be correctly interpreted as making G_LOG_DOMAIN #defined to "dbind" > both for the binary compilation and for the documentation generation. > > FTR, this was working with meson 0.47.2-1 (see > https://buildd.debian.org/status/fetch.php?pkg=at-spi2-core&arch=amd64&ver=2.30.0-2&stamp=1536983011&raw=0 > ), so I guess it's 0.48.0 which broke this. Can you test if the commit mentioned in https://github.com/mesonbuild/meson/issues/4452#issuecomment-434870441 fixes the issue for you? Simply running your build with current Meson trunk is enough to test the issue. Thanks,
Bug#909851: meson fails: AttributeError: 'list' object has no attribute 'absolute_path'
On Sat, Sep 29, 2018 at 6:36 PM Adrian Bunk wrote: > Package: meson > Version: 0.48.0-1 > Severity: serious > Control: affects -1 src:gnome-initial-setup src:file-roller The fix for this is pending review upstream and will be in the next point release: https://github.com/mesonbuild/meson/pull/4308
Bug#909440: meson: missing dependency on python3-pkg-resources
On Sun, Sep 23, 2018 at 10:03 AM Jeremy Bicha wrote: > I tried building a package (gnome-games-app) using meson but the build > fails now. I guess meson needs to depend on python3-pkg-resources . No. We are not permitted to depend on anything outside of Python standard library. Thought looking at the package info that package is provided by setuptools which is a bit of an edge case because distutils is a bit neglected AFAICT.
Bug#894594: fix test errors, and please stop uploading binary packages without having the testsuite run
On Mon, Apr 2, 2018 at 8:35 AM, Matthias Klose wrote: > The java and cross tests fail. and I don't see how these could succeed in the > past. This package is uploaded including the binary package, so the only > explanation I have is that the tests were disabled during these local builds. > Please don't do that, and do source only uploads instead so you can see what > fails. The reason the Java tests now fail is that in the past javac would write its version number to stderr and not stdout and the versioned dependency kept it pinned to the old version (accidentally, though). The fix for this was already in a PR and has now been merged to master. The tests themselves pass. Whenever there is a new Meson release I run the full testsuite in pbuilder. A release will _not_ be made until it fully passes. As for the actual package upload it is really out of my hands as it is done by pitti. I will let him know about the issue, though.
Bug#892956: Request for testing
Hi We have a proposed patch (not yet ready for merging but almost there) available here: https://github.com/mesonbuild/meson/pull/3251 Could people who who encountered this issue test if that fixes the issue for them? Thanks. Also, earlier in this someone said this: > -llibinput-util would be liblibinput-util.a, that's clearly bogus. That's not actually true. If you look at the build definitions of libinput, it uses the following declaration: static_library('libinput-util', ... Meson automatically adds the library prefix to the target name so the file name is indeed "liblibinput-util" and the contents of the pkg-config file are correct in this regard (of course the library should not be in the output at all but that is a different issue).
Bug#892956: Additional info
Hi The -llibfoo thing is obviously wrong, we'll need to get that fixed. The private one is a bit trickier. We generate private requires because they are needed for static linkin. This is where pkg-config behaves a bit strangely: For --libs, private depends are not listed unless you use --static. For --cflags, private depends are always listed. The problem here is that an arguable case can be made for listing the headers without --static and also for not doing that. I would have expected the latter behaviour but apparently based on pkg-config's Git repo they have explicitly made it do the former.
Bug#884627:
The reason this is happening is that starting with 0.44.0 Meson got stricter about subproject names. Slashes in the names have never been supported but due to an oversight, it was not a proper error earlier even though it should have been.
Bug#879976: meson: 0.43.0-1 fails to build, test failures
On Sat, Oct 28, 2017 at 12:08 AM, Jeremy Bicha wrote: >> I think this is because pitti's sbuilder had an issue and it crashed >> the test runner when trying to determine the number of CPUs in the >> system. IIRC the same issue was in reproducible build environment ages >> ago. Under pbuilder the compilation works without issues. > > What do you suggest for Ubuntu's builders which do use sbuild and I'm > guessing gcc-8 is still months away. Based on the log, the builders are working fine. It just failed on pitti's machine for some reason we don't know. We can bump the version requirement of GDC tests to be >= 8. This is would be equivalent to what we had before. We're going to have a point release soon so this could go in that.
Bug#879976: meson: 0.43.0-1 fails to build, test failures
On Fri, Oct 27, 2017 at 11:37 PM, Jeremy Bicha wrote: > meson 0.43.0-1 fails to build from source in Ubuntu and with Debian > Reproducible Builds > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meson.html > > https://launchpad.net/ubuntu/+source/meson/0.43.0-1/+build/13633070 This is caused by the fact that GDC's standard library is not compiled with fPIC even though it should support shared libraries. We skipped this test on GCC versions earlier than 7 (because it was known broken, but should have started working in 7, and won't be fully fixed until GCC 8 IIRC). I ran the full test suite on packaging on i386 and it passed without errors. > By the way, I notice that this version was uploaded as a binary upload > instead of a source-only upload. I think this is because pitti's sbuilder had an issue and it crashed the test runner when trying to determine the number of CPUs in the system. IIRC the same issue was in reproducible build environment ages ago. Under pbuilder the compilation works without issues.
Bug#846742: meson: FTBFS: ld: final link failed: Bad value
reassign 846742 gdc stop On Sat, Dec 3, 2016 at 9:21 AM, Lucas Nussbaum wrote: > Relevant part (hopefully): >> /usr/bin/ld: dsimpleapp@exe/utils.d.o: relocation R_X86_64_PC32 against >> symbol >> `_D3std5array17__T8appenderTAyaZ8appenderFNaNbNfZS3std5array17__T8AppenderTAyaZ8Appender' >> can not be used when making a shared object; recompile with -fPIC >> /usr/bin/ld: final link failed: Bad value >> collect2: error: ld returned 1 exit status This seems to be a bug in GDC since it happens on only this one platform and net searching says that GCC has had problems with symbol interpositioning in the past. This is easy to replicate without Meson. Write this code to source.d: import std.stdio; import utils; import std.string : format; void printGreeting (string name) { writeln ("Hello, I am %s.".format (name)); } void main () { printGreeting ("a Meson D test"); } Compiling it with 'gdc -o prog source.d' gives the same error. Removing the string formatting portion makes it work again as does compiling with -fPIC, but if that is somehow always needed GDC should either add -fPIC itself, error out earlier or, at the very least, print a more relevant error message. LDC compiles this same program without errors without needing -fPIC. If this issue is in GDC and it is not fixed until the next release, Meson will fix the issue by changing the build dep from gdc to ldc. Thanks,
Bug#583603: Upstream fixed
Hi This file was just removed from upstream trunk. It's not used so you can just delete it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org