Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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'

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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'

[Jussi Pakkanen]

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'

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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'

[Jussi Pakkanen]

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'

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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'

[Jussi Pakkanen]

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:

[Jussi Pakkanen]

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:

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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)

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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=amd64=2.30.0-2=1536983011=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'

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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:

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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

[Jussi Pakkanen]

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