Bug#496264: RFP: Cuneiform -- A high quality OCR system

Package: wnpp Severity: wishlist Cuneiform is a high quality OCR system that supports multiple languages. The code is released under the BSD license. Project homepage: https://launchpad.net/cuneiform-linux There is already an unofficial debianisation that works on Ubuntu, so packaging it for

Bug#222046: Not reproducible

). The only one who gets it consistently right is unfortunately Acrobat Reader. :( -- Jussi Pakkanen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#602117: RFP: Glyphtracer -- a program to convert raster images to fonts

Package: wnpp Severity: wishlist Glyphtracer is a GPL 3 program to easily generate fonts from scanned letter images. The project home page is here: https://launchpad.net/glyphtracer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe.

Bug#496264: [Cuneiform] cuneiform license troubles

On Sun, Dec 7, 2008 at 10:33 AM, Daniel Baumann [EMAIL PROTECTED] wrote: my cuneiform packages were rejected from debian with the following message, will you take care about fixing it? ---snip--- Hi Maintainer, rejected, upstream blindly copied its own license/copyright header above all

Bug#496264: Keeping this one alive

Hi Let's not allow this to fall into limbo again. I have not heard from Cognitive people but as far as I know: - there is no (publicly) available source for the dat files - they were in the original source release, which was under BSD, so they should be BSD as well -- To

Bug#496264: cuneiform_0.5+dfsg-1_i386.changes REJECTED

3) The issue with the libraries. Their names are really too generic and they really aren't packaged as proper shared libraries, so you can't put them into /usr/lib. I think you can change install.cmake so that SET(LIBDIR lib[64]) becomes SET(LIBDIR lib[64]/cuneiform) CMake sets

Bug#496264: cuneiform_0.5+dfsg-1_i386.changes REJECTED

Jussi Pakkanen wrote: 3) is not a problem, don't worry about that. what i wanted from you was a statement for 2). I have sent a mail to the original developers. I'll let you know once they answer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org

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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#712605: ITP: meson -- high-productivity build system

Package: wnpp Severity: wishlist Owner: Jussi Pakkanen jpakk...@gmail.com * Package name: meson Version : 0.4.1-22-gea3e8f1 Upstream Author : Jussi Pakkanen jpakk...@gmail.com * URL : https://sourceforge.net/p/meson * License : Apache 2.0 Programming Lang

Bug#712610: RFS: meson/0.4.1-22-gea3e8f1-1 [ITP]

Package: sponsorship-requests Severity: normal [wishlist] Dear mentors, I am looking for a sponsor for my package meson * Package name: meson Version : 0.4.1-22-gea3e8f1-1 Upstream Author : Jussi Pakkanen * URL : https://sourceforge.net/p/meson/ * License

Bug#712610: RFS: meson/0.4.1-22-gea3e8f1-1 [ITP]

On Thu, Jun 20, 2013 at 12:43 AM, Jakub Wilk jw...@debian.org wrote: Thanks for your comments. I have uploaded a new version to mentors. How was .orig.tar generated? There's neither get-orig-source target nor README.source that would explain it... Is there a reason you based the Debian

Bug#714099: python3-ply: Add dh_python3-ply functionality

Package: python3-ply Version: 3.4-3 Severity: wishlist Dear Maintainer, The python-ply package comes with dh_python-ply to generate proper package dependencies. Unfortunately it only works with Python 2. Please consider creating a script that achieves the same for Python 3. -- System

Bug#712610: RFS: meson/0.4.1-22-gea3e8f1-1 [ITP]

On Sun, Jun 23, 2013 at 7:51 PM, Jakub Wilk jw...@debian.org wrote: You put dh_python3 call in such a place, that is run when .deb has already been created. No wonder it's a no-op that late. :P That's where some googling told me to put it. Location fixed and now it works. Thanks. Filing a

Bug#712610: RFS re-request: The Meson Build system

Hello I'm (still) looking for a sponsor for the Meson build system. The original RFS was in June. There were some issues raised and almost all of them were fixed then. The code base has evolved quite a lot since then so a new review is probably in order, though the packaging bits have not changed

Bug#673538: transition: gnustep-base, gnustep-gui

Well, meson is a build system, there could be legitimate reasons for the build-dependency (determining compiler flags, etc.). The reason Meson build-depends on objc is that as part of its test suite it compiles a test project for all languages that it supports.

Bug#767107: Lintian reports error on dependency to qt5-default but removing it causes build failures

Package: lintian Version: 2.5.30 Lintian reports an error for depending on metapackages. One of them is qt5-default. Depending on it causes errors such as this one: https://lintian.debian.org/maintainer/jpakk...@gmail.com.html#meson However if you remove qt5-default from the list of

Bug#767107: Lintian reports error on dependency to qt5-default but removing it causes build failures

On Tue, Oct 28, 2014 at 8:48 PM, Jakub Wilk jw...@debian.org wrote: This happens whether or not you have qtchooser in your package dependencies. IANA Qt expert, but my understanding is that meson should pass the -qt5 option to moc and friends; then the error will go away. I tried this and

Bug#767813: Please update Ninja to to newest upstream version

Package: ninja-build Version: 1.3.4-1.2 Debian currently has version 1.3.4 of Ninja but upstream has released 1.5.1 almost half a year ago. It would be nice to get this version into Debian for the following reasons: - it has new functionality that e.g. the Meson package would like to use -

Bug#767813: Further info

Hi I ran a few tests and if you install newest Ninja from git (1.5.1 + some bits) it will happily compile Debian's Chromium package. Thus it is almost certain that 1.5.1 release does so as well. As Chromium is NInja's biggest user by far, it is very unlikely that any other package will break

Bug#767813: NMU of Ninja

Hi An NMU has been pushed to DELAYED/7. It should fix all open bugs apart from the sparc bus error one. Thanks,

Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system

On Wed, Aug 12, 2015 at 4:31 PM, Niels Thykier ni...@thykier.net wrote: I got a couple of questions: * How many packages in Debian are (or will in the near future) be using this build system? As far as I can tell, at the moment the number is zero. There have been talks with upstream

Bug#795253: Add support for Meson build system

Package: debhelper Version: 9.20150811 Severity: wishlist Please add support for building packages using the Meson build system. The exact build steps to take are the following. Configuring Create a build directory. Meson supports all the standard CFLAGS etc so assuming they are set the

Bug#809259: Please add letsencrypt certificates

Package: ca-certificates Version: 20151214 Currently trying to connect to a server that has letsencrypt enabled will fail. For example this command: wget https://wrapdb.mesonbuild.com will error out saying that the certificate is not trusted because it has no known issuer. The connection will

Bug#815253: Seems to fail when gcc is not available

Package: libdpkg-perl Version: 1.18.4 The Meson package is running debtests that compile a test project separately with gcc and clang. This has started failing with an error message from libdpkg-perl. The full log is here:

Bug#815253: Seems to fail when gcc is not available

On Sun, Feb 21, 2016 at 11:27 AM, Guillem Jover wrote: In this case just setting CC=clang before anything that involves a > call to a script in dpkg-dev, should make it work. Thus reassigning. > Here are the relevant bits from the test script: CC=clang meson build ninja -C

Bug#832157: Please use -v with Ninja

Package: gnome-twitch Version: 0.2.0-3 Debian's quality bots check that all code is compiled with proper hardening flags. To do this compiler invocations need to be visible in the compile logs. By default Ninja does not print them so they can not be scanned. Please update your rules file so all

Bug#851601: mesontest Python script fails to find required package.

On Mon, Jan 16, 2017 at 8:40 PM, Russel Winder wrote: > I am guessing that the Python path at the moment of the import does not > include /usr/share/meson and so the > package is not findable with the current installation structure. This will be fixed in the next version

Bug#841846: meson: breaks DT_MIPS_RLD_MAP_REL elf entry when removing RPATH entry

On Sun, Oct 23, 2016 at 10:23 PM, Aurelien Jarno wrote: > The patch below fixes the issue by adjusting the value of the > DT_MIPS_RLD_MAP_REL tag when it is shifted, the same way it is done in > chrpath. Created an upstream MR here:

Bug#841846: meson: breaks DT_MIPS_RLD_MAP_REL elf entry when removing RPATH entry

> The strategy adopted by meson is the same than the one adopted by > chrpath, and chrpath also adjusts the value of DT_MIPS_RLD_MAP_REL. > I don't know if there is another way to do that, at least I don't > think there is another obvious way to do it. Ok, thanks. Committed to master and will be

Bug#844252: Making a dist package loses files

Package: python3 Version: 3.5.1-4 When creating a dist package of a Python project using newest Python 3, it leaves out a bunch of files from the final tarball. The omitted files seem to be random, but they are deterministically the same on every run. Running the same packaging command on Jessie

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#850191: Can not cross compile to arm from x86

Package: gcc-6-arm-linux-gnueabihf Version: 6.2.1-5cross1 Trying to cross compile a simple helloworld application on 32 bit x86 with this command: arm-linux-gnueabihf-gcc-6 hello.c -o hello fails with the following error message: /usr/lib/gcc-cross/arm-linux-gnueabihf/6/libgcc.a: file not

Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system

On Fri, Mar 24, 2017 at 6:05 PM, Michael Biebl wrote: > a/ Add support for DEB_BUILD_OPTIONS="parallel=N"? > By default ninja runs N jobs in parallel, where N is derived > from the number of CPUs. > Should this be only done for the build step or install and test as well? > In

Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system

On Mon, Mar 27, 2017 at 7:24 PM, Michael Biebl wrote: > So, when running "ninja test -j1" will the -j1 be ignored? Well yes and no. It tells Ninja to use only one parallel process. Which it uses to spawn the test runner which then uses MESON_TESTTHREADS amount of parallel

Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system

On Mon, Mar 27, 2017 at 8:07 PM, Michael Biebl wrote: > Ok, os ninja does not automatically translate -j1 to MESON_TESTTHREADS=1 No. > To understand this properly: Say I have 4 cores, does that mean that by > default I have 4 ninja processes which run mesontest, which in turn

Bug#859177: meson is unuseable for package cross compilation

On Fri, Mar 31, 2017 at 10:37 AM, Helmut Grohne wrote: > When running `meson` on a project without supplying a `--cross-file`, > `meson` will pick default system compilers. Those compilers will produce > architecture-dependent output, which `meson` inherits. Thus `meson`'s >

Bug#859177: meson is unuseable for package cross compilation

On Fri, Mar 31, 2017 at 4:31 PM, Helmut Grohne wrote: > The `makefile` buildsystem in `debhelper` even just sets > `CC=${DEB_HOST_GNU_TYPE}-gcc`. The convention is: prefix host tools with the > host's GNU triplet. This does not work. For Meson, CC always means "the native

Bug#859177: meson is unuseable for package cross compilation

o Meson to use it. It only takes care of host, not target. Consider it an MVP. :) #!/usr/bin/env python3 # Copyright 2017 Jussi Pakkanen # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may

Bug#859185: meson: ship vim syntax highlighters

On Fri, Mar 31, 2017 at 12:21 PM, James Cowgill wrote: > Please can you install the vim syntax highlighting files found in > syntax-highlighting/vim/ so I don't have to download and install them > manually. We should probably get those in vim upstream instead, but they are

Bug#861055: meson: please make package backportable

On Mon, Apr 24, 2017 at 9:51 AM, Martin Pitt wrote: > I backported ninja-build and meson to Ubuntu 16.04 (to provide CI build > dependencies for systemd), and noticed that c++-compiler-arm-linux-gnueabihf > is > not yet available there. Same goes for Stretch. As it's only

Bug#859177: meson is unuseable for package cross compilation

On Sat, Jul 29, 2017 at 10:19 AM, Michael Biebl wrote: > Jussi, would this be hard to implement? Is there a good reason why > cross-compilation uses a separate file? There are many reasons. The fils contains a lot of options and passing all those in command line arguments

Bug#859177: meson is unuseable for package cross compilation

On Sun, Jul 30, 2017 at 8:20 AM, Helmut Grohne wrote: > When debcrossgen.py is shipped in a "known" location (e.g. $PATH), I > can simply run it myself, modify its output, and pass "--cross-file > myfile" to dh_auto_configure. The later --cross-file takes precedence as > far

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

On Tue, Aug 1, 2017 at 12:56 AM, Michael Biebl wrote: > when purging the meson package, the following files are not removed > properly: > > /usr/share/meson/mesonbuild/wrap/__pycache__/wrap.cpython-35.pyc I can not reproduce this. Installing, running and then uninstalling

Bug#862514: Gcc creates illegal instructions when combining C + ASM on arm on sid

Package: gcc Version: 6.3.0-4 Gcc creates binaries that fail with "invalid instruction". To reproduce create the following main.c: int get_retval(void); int main(int argc, char **argv) { return get_retval(); } and the following retval-arm.S .text .globl get_retval get_retval: mov

Bug#863598: meson: Please include converter tools

On Mon, May 29, 2017 at 8:00 AM, Jeremy Bicha wrote: > According to http://mesonbuild.com/Porting-from-autotools.html > "Meson comes with a helper script ac_converter" > > Neither of the two scripts in the tools/ directory are provided in the > Debian binary package. Please

Bug#875703: debcrossgen defaults to a non-default gcc

On Wed, Sep 13, 2017 at 10:01 PM, Helmut Grohne wrote: > I'm not sure why you felt the need to append a version, but my attached > patch supports your need by adding a --gccsuffix option to debcrossgen > while defaulting to an unversioned gcc as is expected by most Debian >

Bug#875703: debcrossgen defaults to a non-default gcc

On Thu, Sep 14, 2017 at 7:52 AM, Helmut Grohne wrote: >> This script should probably do the same thing as that one. With a bit >> of refactoring it could even import that function since it ships in >> the same (private) directory as the code itself. The problem here is that I

Bug#873831: debhelper: [meson] Default to a UTF8 locale?

On Thu, Aug 31, 2017 at 5:37 PM, Jeremy Bicha wrote: > I believe that meson assumes it's built using a UTF-8 locale. Is this > something we can have debhelper handle automatically for the meson > buildsystem? A more interesting question is why does Debian insist on using a

Bug#873831: [debhelper-devel] Bug#873831: debhelper: [meson] Default to a UTF8 locale?

On Fri, Sep 1, 2017 at 12:37 AM, Steve Langasek wrote: > Because the transition is fraught. C.UTF-8 is now built and always > available as part of the libc package, but it's not built into the binary > and making libc itself treat it as a built-in default is problematic;

Bug#875703: debcrossgen defaults to a non-default gcc

On Wed, Oct 11, 2017 at 8:23 PM, Helmut Grohne wrote: >> Is cpu_family intended to describe a CPU family, or an ABI? Some CPU >> families have more than one incompatible ABI: > > It's not clear to me what the intention is. My experience matches yours > though: cpu and

Bug#879704: meson: nocheck build profile still requires rustc and c++-compiler-arm-linux-gnueabihf

On Tue, Oct 24, 2017 at 10:43 PM, Daniel Schepler wrote: > Currently, if you build meson with the nocheck build profile, it still > requires rustc and c++-compiler-arm-linux-gnueabihf. That looks like > a mistake, that the was probably intended to apply to both >

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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 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#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#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#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 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#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 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#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#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#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#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#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#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#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#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#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: 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: 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#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#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#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#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#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.

  1   2   >