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

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 an

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

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

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

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

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

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' > >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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 >

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 >

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 >

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?

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

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

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

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

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:

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

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

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

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

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.

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 > >

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 >>

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