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#1070470: Rustc fails linking C code on some platforms

Package: rustc Version: 1.70.0+dfsg2-1 Attached is a simple program that combines Rust and C code with a statically compiled version of zlib. The project also has a shell script that compiles the code using only cc, ar and rustc, so there are no build systems or anything else within to mix things

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#1070241: Bindgen missing dependency on Clang

Package: bindgen Version: 0.66.1-4 If you do `apt install bindgen` and try to use it, it will fail with an error message like this: /usr/include/zconf.h: 254 fatal error 'stddef.h' not found Running `apt install clang` makes it work. As bindgen can't be run without it, the bindgen package

Bug#1060838: meson: should use the host gobject-introspection-1.0.pc for looking up g-ir-scanner

On Mon, 26 Feb 2024 at 17:58, Simon McVittie wrote: > I did consider that, but if I'm understanding what you propose > correctly, that would involve going through these steps for every > possible cross-tool: > > * inventing a new environment variable similar to CC and PKG_CONFIG, for > example

Bug#1060838: meson: should use the host gobject-introspection-1.0.pc for looking up g-ir-scanner

On Fri, 23 Feb 2024 at 14:27, Simon McVittie wrote: > On Wed, 21 Feb 2024 at 10:47:33 +0100, Johannes Schauer Marin Rodrigues wrote: > > I've just learned from Simon McVittie in #debian-devel that there is a way > > to > > cross-build packages using meson and gobject-introspection without this

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#1056117: meson: generates non-determinstic .pkgconfig files

On Fri, 17 Nov 2023 at 10:45, Chris Lamb wrote: > Whilst working on the Reproducible Builds effort, we noticed that > meson was generates .pkgconfig files that are not reproducible. Please file all changeslike these directly upstream. The Meson packaging prohibits patches that alter

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#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson

On Mon, 31 Jul 2023 at 21:21, Adrian Bunk wrote: > In this case Breaks would be required in both directions, otherwise a > build dependency on a new meson might result in using new meson and old > debhelper in backports. For reference we are currently discussing how to handle this. The original

Bug#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson

On Thu, 27 Jul 2023 at 17:45, Simon McVittie wrote: > As far as I'm aware, we never want to include .pyc in Debian packages, > so I think debhelper's meson build system plugin should be turning this off > as a standard setting for all Debian packages (similar to the way it > sets --prefix=/usr

Bug#1041653: meson: Drop gtk-sharp2* build deps

On Fri, 21 Jul 2023 at 20:42, Bastian Germann wrote: > Please drop gtk-sharp2 and gtk-sharp2-gapi from Build-Depends. > The package builds without them and this will help getting rid of gtk-sharp2 > and eventually gtk2. This will be fixed in the next point release upload at the latest.

Bug#1041246: Please update clang-format version

Package: clang-format Version: 1:14.0-55.7 The dependency on the clang-format package currently looks like this: dep: clang-format-14 (>= 14~) This means that it can not depend on a newer clang-format provider as those have a different name (latest seems to be clang-format-16). This means that

Bug#1033579: debcrossgen: wrong cpu family for ppc64el

On Mon, 27 Mar 2023 at 20:45, Helmut Grohne wrote: > dpdk fails to cross build from source for ppc64el, because its matching > on the host cpu family breaks. As it turns out, debcrossgen (yes, we are > still using this) does not map it to the correct value. I'm attaching a > patch for your

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#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Tue, 28 Feb 2023 at 22:44, Helmut Grohne wrote: > Would you agree to either include the PR in your upload or pass > --debarch=$DEB_HOST_ARCH instead of --debarch=auto in debcrossgen? Because of #1032168 the current priority is to get 1.0.1 to testing. Thus I'm not going to do any changes to

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#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Sun, 26 Feb 2023 at 21:39, Helmut Grohne wrote: > Given that, I think you can move forward with the change post bookworm. > Thanks for bearing with me and sorry for the inadequate remarks. I filed an MR upstream with all changes that should go in the next release (which is to say they won't

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Sun, 26 Feb 2023 at 09:22, Helmut Grohne wrote: > I also spent a brief look at the env2mfile implementation and am > bewildered that it essentially discards the experience gained with > debcrossgen over the years. The mapping replacements for armhf, i386 and > mips64el are missing. Compiler

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Sat, 25 Feb 2023 at 18:20, Helmut Grohne wrote: > While I appreciate the idea, I think the result is not useful. > debcrossgen is something that we want to delete before too long. It also > is platform logic by definition as it is specific to Debian. Carrying > platform logic (like touching

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Sat, 25 Feb 2023 at 12:08, Helmut Grohne wrote: > I think I understand this part. At no point did Simon or me ask for > changing the interface of env2mfile. What we asked for is to retain the > interface of debcrossgen, which is Debian-specific. These requirements > seem quite easy to

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Fri, 24 Feb 2023 at 23:29, Simon McVittie wrote: > The option seems to be debcrossgen --arch rather than --debarch, although > it becomes meson env2mfile --debarch. The reason for this is that env2file is meant to be general. It needs to support custom toolchains, distro package building and

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Fri, 24 Feb 2023 at 19:38, Helmut Grohne wrote: > > Could it be that you tested env2mfile, but not debcrossgen? It would > always exit non-zero no matter what. No error message. This really > should have been caught by the "crossbuild" autopkgtest, but wasn't. I > don't quite understand why.

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Fri, 24 Feb 2023 at 08:26, Helmut Grohne wrote: > I think you know, but let's include the answer here for clarity: You > change debcrossgen to become a wrapper of env2mfile. However doing so > requires that env2mfile actually works and last time you attempted this, > env2mfile was so horribly

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#1019413: debcrossgen: host_arch.cpu_family() reports powerpc64le on ppc64el but should report ppc64

On Thu, 8 Sept 2022 at 23:33, Helmut Grohne wrote: > host_arch.cpu_family() should be reporting ppc64 on ppc64el according to > https://mesonbuild.com/Reference-tables.html, but it actually reports > powerpc64le when debcrossgen is in use. The relevant mapping should be > fixed in debcrossgen.

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

On Tue, 16 Aug 2022 at 12:51, Simon McVittie wrote: > debcrossgen puts c_args, cpp_args, c_link_args and cpp_link_args in the > [properties] section of the cross-file that it generates, but recent > versions of Meson want this to be in the [built-in options] section > instead. We have been

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#1003535: meson: fails to build vala if 'metadata_dirs' option is specified

On Tue, 11 Jan 2022 at 16:30, Arnaud Ferraris wrote: > This bug has been fixed upstream[1] and the corresponding patch should be > backported > while waiting for the next point release. There are a couple of other Gnome stack issues so just fixing this on its own would not be that beneficial.

Bug#1000327: meson: please make the generated cmake files reproducible

On Sun, 21 Nov 2021 at 19:45, Chris Lamb wrote: > Whilst working on the Reproducible Builds effort we noticed that > meson is not generating reproducible .cmake files. > > A patch is attached that uses os.path.basename to only include > "meson-config.cmake.in" instead of the full path. This not

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#989823: meson: autopkgtest crossbuild is always skipped

On Mon, 14 Jun 2021 at 09:15, Helmut Grohne wrote: > The autopkgtest "crossbuild" is always skipped. It starts with checking > whether a command g++-arm-linux-gnueabhihf exists and exits 0 when it > doesn't. That command never exists as it is called > arm-linux-gnueabhihf-g++. Also exit code 0

Bug#988219: meson: Move package into unstable

On Fri, 7 May 2021 at 23:15, Andrea Pappacoda wrote: > Since Meson 0.57.1 Meson has been only packaged for experimental, even if it > seems that there isn't a good reason for it. Could it please be moved to > unstable? This also makes updated version unavailable for Ubuntu. Unstable is under

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#977633: meson: support cups-config in debcrossgen

On Thu, 17 Dec 2020 at 23:57, Helmut Grohne wrote: > cinnamon-settings-daemon fails to cross build from source, because meson > fails to locate cups. meson tried methods pkg-config and config-tool. > Unfortunately, cups upstream refuses to add a pkg-config file (see >

Bug#966425: include Meson cross files

On Tue, 28 Jul 2020 at 15:36, John Scott wrote: > I'm not close to being finished yet, but I'm working on writing Meson > cross files that would be suitable for inclusion. Meson recommends that > distros including cross-toolchains ship these somehow, be it with the > toolchain or in a separate

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#964171: meson build triggers blhc compiler-flags-hidden warning

On Fri, 3 Jul 2020 at 09:00, Kunal Mehta wrote: > All of the packages that I maintain which use meson (zimlib, libkiwix, > zimwriterfs) trigger blhc's compiler-flags-hidden[1] warning. I'm guessing > that > it's something in meson doing this. > > Specifically, it's for a non-verbose build.

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#959708: meson ignores --libdir when --cross-file is given

On Mon, 4 May 2020 at 13:27, Helmut Grohne wrote: > When one passes --libdir and --cross-file to meson, meson thinks it > knows better than the user and overrides the libdir with plain "lib". > Setting a libdir from the crossfile does not work either. It gets > ignores in the same way. There is

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#951487: The autopkgtests are failing with 0.53.1

On Mon, Feb 17, 2020 at 1:15 PM Sebastien Bacher wrote: > The autopkgtests are failing with the current version > https://ci.debian.net/data/autopkgtest/testing/amd64/m/meson/4301958/log.gz This should be fixed in 0.53.2 that should be released shortly (was going to be today but probably won't

Bug#948611: Fix is out

Hi We have released 0.53.1 which should fix this issue. The packaging is available on mentors: https://mentors.debian.net/package/meson Unfortunately Martin Pitt, who is the usual uploader, is on a devconf somewhere with poor connectivity and can't guarantee an upload until Monday evening. In

Bug#948611: Progress

Hi We are working on fixing this issue in this upstream PR: https://github.com/mesonbuild/meson/pull/6457 The PR requires some fixes still, but if someone could test and verify that it fixes the issue in this bug it would be useful. We'll make the 0.53.1 release immediately after that PR has

Bug#870314: Does not properly clean up /usr/share/meson/mesonbuild/ on purge

On Thu, Nov 21, 2019 at 7:15 AM wrote: > Attached is a patch that seems to fix the problem in this bug. I tested this and it seems to work. This will be in the next release upload. Thanks.

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#940298: debhelper: Should we use meson --native-file ?

On Sun, Sep 15, 2019 at 2:20 PM Niels Thykier wrote: > > > > AFAICT, it would just be a question of doing: > > > > """ > > /usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" > > -o"$DIR/meson-native-file.conf" > > /usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" > > -o"$DIR/meson-cross-file.conf"

Bug#935817: debhelper,meson: meson automatically tries to use ccache, which fails if $HOME is not writeable

On Mon, Aug 26, 2019 at 6:33 PM Simon McVittie wrote: > I'm not sure whether this should be considered to be a bug in meson itself, > or in debhelper's meson integration, or what... I'd say that this is a question of ccache support in general. FWICT this issue would appear for every build

Bug#931825: Dub executable does not run

Package: dub Version: 1.12.1-1 Installing dub on Debian unstable (tested on x86 and x64) and then running "dub" errors out immediately with the following error message: dub: symbol lookup error: dub: undefined symbol: _Dstd5stdio_.

Bug#920154:

On Tue, Feb 12, 2019 at 4:24 PM Bart Libert wrote: > I have just received an answer on #zsh-pkg: > > "should go to /usr/share/zsh/vendor-completions/_$cmd" > > So this means the "_meson" file from the source should be put in that folder. Thanks, this will be in the next release.

Bug#920154: meson: ship zsh completions

On Tue, Jan 22, 2019 at 10:42 AM Bart Libert wrote: > Meson ships some completions for zsh in its data/shell-completions directory. > It would be nice to have these shipped in debian as well. What is the correct way of doing that? The Debian zsh wiki page is not really helpful...

Bug#919117: meson ignores all compiler flags when a --cross-file is given

On Sun, Jan 13, 2019 at 5:35 PM Jussi Pakkanen wrote: > I updated the packaging to have the new debcrossgen script. > Unfortunately the repository is currently broken and pbuilder can not > install all the dependency packages needed to run the test suite so > binary packages can not

Bug#919117: meson ignores all compiler flags when a --cross-file is given

On Sun, Jan 13, 2019 at 2:31 PM Niels Thykier wrote: > I am happy to work with you to update debhelper in bullseye to use a > --native-file instead of passing ENV variables to meson provided we use > the same script for generating the cross file and the native file. Good to know. > The only

Bug#919117: meson ignores all compiler flags when a --cross-file is given

On Sun, Jan 13, 2019 at 12:42 AM Helmut Grohne wrote: > I think this discrepancy is a design bug in Meson. Meson should either > use environment variables or not. For native compilation, you can simply > use a native file. Artificially handling things differently just makes > cross compilation

Bug#919117: meson ignores all compiler flags when a --cross-file is given

On Sat, Jan 12, 2019 at 10:27 PM Helmut Grohne wrote: > We ask meson to include -DDEFINED_VIA_CFLAGS via the CFLAGS environment > variable and it says that it is appending the flag. However, when > running ninja, we see that the flag goes missing. When dropping the > --cross-file flag, the flag

Bug#919065: debcrossgen: cpu/cpu_family wrong for armhf and mips64el

On Sat, Jan 12, 2019 at 2:57 PM Helmut Grohne wrote: > debcrossgen yields wrong cpu and cpu_family values for armhf and > mips64el. The attached patch fixes that. Please consider applying it. Thanks. Will put this in 0.49.1 release which should be released soon (sadly there is no firm release

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#914543: meson adds both -fPIE and -fPIC options in LTO compiles with gcc-8

On Sun, Dec 2, 2018 at 6:34 PM John David Anglin wrote: > However, we didn't get PIE executables. The current version of meson is > 0.48.2-1 and b_pie was introduced in 0.49.0. 0.49.0 will be released next Sunday so the issue will get fixed in about a week.

Bug#913263: meson: wrongly caches dependency() results

On Sun, Dec 2, 2018 at 8:12 AM Helmut Grohne wrote: > Furthermore, I think that it is very inefficient if you ask me to try > various things. I put up with the cost of providing a minimized test > case. Effectively, I already did the work you are now requesting me to > do. Did you even attempt

Bug#914543: meson adds both -fPIE and -fPIC options in LTO compiles with gcc-8

On Sun, Dec 2, 2018 at 12:15 AM John David Anglin wrote: > > Thus it would seem that this is not a bug in Meson, but instead in > > systemd's build setup as the pie arguments are added by the latter. > I agree but Michael doesn't have a clear idea how to fix the issue. > Would the "b_pie" option

Bug#913263: meson: wrongly caches dependency() results

On Thu, Nov 8, 2018 at 9:51 PM Helmut Grohne wrote: > You notice that the native compiler invocation is asked to link the host > architecture libglib-2.0.so. That's wrong. > > To see that this is actually the first depenency() call leaking into the > next call, we can simply remove the first

Bug#914543: meson adds both -fPIE and -fPIC options in LTO compiles with gcc-8

On Sat, Nov 24, 2018 at 6:09 PM John David Anglin wrote: > My understanding is -fPIE should be used when creating objects for a > PIE executable. -fPIC should be used when creating objects for a shared > library. Only one is recorded when -flto is specified. I reviewed the code and we only

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#912559: /usr/share/meson/debcrossgen: Please add a way to set package-specific cross properties

On Thu, Nov 1, 2018 at 1:12 PM Simon McVittie wrote: > For now, I have prototyped this for GLib by including this patched > debcrossgen in its debian/ directory: > > but I would prefer it if there was a more official way to do this with > Meson and debhelper. > > Perhaps dh_auto_configure could

Bug#912560: dh_auto_test: run `meson test` instead of `ninja test` in new compat level or with an option

On Thu, Nov 1, 2018 at 1:21 PM Simon McVittie wrote: > Note that because `ninja test` and `meson test` take different command-line > options, this would be an incompatible change unless the package maintainer > has opted in somehow, either with a compat level upgrade or a new > command-line

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#911179: Seems to be fixed

Hi This seems to be fixed now, at least I could do pbuilder package builds today.

Bug#911179: Qt5 packages uninstallable in Sid

Package: libqt5core5a Version: 5.11.2+dfsg-3 Qt packages are currently uninstallable in Sid. Trying to do a pbuilder package build from scratch gives the following error: The following packages have unmet dependencies: libqt5sensors5 : Depends: qtbase-abi-5-11-0 which is a virtual package and is

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#907324: meson FTBFS on armhf - cannot find -lquadmath

On Tue, Aug 28, 2018 at 2:10 AM, Jeremy Bicha wrote: > Ubuntu has a patch related to this issue: This will be fixed in the next release. We removed the flag entirely since nothing seemed to be requiring it in our test suite. It was originally probably copypasted from somewhere without properly

Bug#907265: ftbfs in a sid chroot

On Sat, Aug 25, 2018 at 7:40 PM, Marc Haber wrote: > File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 162, in > __init__ > SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx) > File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 59, in > __init__ > unlink_now)

Bug#903279: closed by Jussi Pakkanen (Bug#903279: fixed in meson 0.47.1-1)

On Sun, Jul 15, 2018 at 8:28 AM, Helmut Grohne wrote: >>* Install depfixer again, it got lost accidentally. Closes: #903279. > > The bug being closed here is about debcrossgen. You closed the wrong > bug. debcrossgen is still missing. That was a typo, it should have said debcrossgen instead

Bug#903434: Valgrind reports errors on i386 for trivial programs

Package: valgrind Version: 3.13.0-2 If you compile the following program and run it with Valgrind on i386: int main(int argc, char **argv) { return 0; } The result is ten errors that look like this: ==757== Conditional jump or move depends on uninitialised value(s) ==757==at 0x401BB0D:

Bug#903279: meson removed debcrossgen

On Sun, Jul 8, 2018 at 3:23 PM, Helmut Grohne wrote: > The changelog does not give a reason for why this happened, which > suggests that this may be accidental. Please add it back where debhelper > expects it. > > Given the amount of packages that depend on meson, please fix this in a > timely

Bug#895636: meson: more tools missing from debcrossgen

On Fri, Apr 13, 2018 at 7:17 PM, Helmut Grohne wrote: > For Debian systems, most architecture-dependent tools carry the GNU > triplet as prefix. Thus we can assign "${DEB_HOST_GNU_TYPE}-" as the > tool_prefix and solve most of missing entries. > > Please consider implementing

Bug#894774: meson fails it's autopkg tests on i386

On Wed, Apr 4, 2018 at 10:25 AM, Matthias Klose wrote: > meson fails it's autopkg tests on i386. simd is not in the base architecture > of > the i386 target, so you probably should skip that test. There are two things to note here: 1) the test is written so that it compiles

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

  1   2   >