On Tue, 10 Sept 2024 at 13:27, Matthias Klose wrote:
> the autopkg test uses the deprecated tool debcrossgen:
>
> def internal_impl():
> print('WARNING: this tool is deprecated, use "meson env2mfile"
> instead.')
> options = parser.parse_args()
> run(options)
> print('Remember
On Wed, 4 Sept 2024 at 15:15, Matthias Klose
wrote:
> meson needs to be made aware of LLVM 19.
This is now upstream: https://github.com/mesonbuild/meson/pull/13635
Will the next release be enough or does this need to get in faster than that?
> Could you add this to meson's dependencies?
>
> Depends: pkgconf
>
> meson's standard dependency function uses pkg-config in most cases.
>
> https://mesonbuild.com/Dependencies.html
>
> Recommends would not be enough since meson is primarily used in Debian
> as a build dependency and the official
On Fri, 2 Aug 2024 at 19:03, Boyuan Yang wrote:
> To prevent this issue in the future, you may consider managing your packaging
> work using git-buildpackage or dgit. On the very least, doing a plain
> debdiff(1)
> between each upload against the /debian/ dir would still be useful.
Will be fixe
On Wed, 10 Jul 2024 at 23:45, Phil Wyett wrote:
> Please create a salsa repository for meson and allow for collaborative
> development and improvement of the package.
The problem here is that it is exactly what I do _not_ want. The Meson
packaging has made a strict policy decision that _all_ fun
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
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
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
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 ti
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 up
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
>
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 should
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
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
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 fili
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 functionalit
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 t
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
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'
> > colle
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
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 as
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.
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
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 conven
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 g
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 -a
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 i
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
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 t
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 w
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 m
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 fl
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 D
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 reconcil
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
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. I
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
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
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. I'
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 movin
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
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 cor
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 las
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 ze
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
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 t
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. We
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 o
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 an
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/bobus
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 is
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 r
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
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.
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
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
> https://github.com/apple/cup
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 pa
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 th
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. Here'
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 th
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
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 "sk
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
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
>
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
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
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
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 b
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 th
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 be
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.
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?
Thi
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
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"
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 system
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_.
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.
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...
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
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 cav
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 un
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 i
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 da
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 er
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.
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 to
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
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 (unn
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 add
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
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 e
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 optio
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
Hi
This seems to be fixed now, at least I could do pbuilder package builds today.
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
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/4
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 a
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
v
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)
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
1 - 100 of 161 matches
Mail list logo