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: ??
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 ma
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 the proposed tool_pr
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 all the things tha
On Mon, Apr 2, 2018 at 8:35 AM, Matthias Klose wrote:
> The java and cross tests fail. and I don't see how these could succeed in the
> past. This package is uploaded including the binary package, so the only
> explanation I have is that the tests were disabled during these local builds.
> Pleas
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
Hi
The -llibfoo thing is obviously wrong, we'll need to get that fixed.
The private one is a bit trickier. We generate private requires
because they are needed for static linkin. This is where pkg-config
behaves a bit strangely:
For --libs, private depends are not listed unless you use --static.
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.
On Sat, Oct 28, 2017 at 12:08 AM, Jeremy Bicha wrote:
>> I think this is because pitti's sbuilder had an issue and it crashed
>> the test runner when trying to determine the number of CPUs in the
>> system. IIRC the same issue was in reproducible build environment ages
>> ago. Under pbuilder the
On Fri, Oct 27, 2017 at 11:37 PM, Jeremy Bicha wrote:
> meson 0.43.0-1 fails to build from source in Ubuntu and with Debian
> Reproducible Builds
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meson.html
>
> https://launchpad.net/ubuntu/+source/meson/0.43.0-1/+build/13633070
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
> alternatives in e.g. "rustc | b
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 cpu_family are incapable of
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 don't have access t
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
> packages. I also made
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; which
> means there's a
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
default setting from 1
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
Meson leaves no pyc fil
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 as I understand.
Tha
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 would make for very blo
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 change this. It could
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
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 being used for
> testin
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 obtain a copy of the Licens
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
still a bit rough.
Yo
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 compiler".
This is ju
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
> interfaces certainly
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 runs
> 4 threads,
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 processes.
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 the latter case, the
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 upload that should happ
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
recog
reassign 846742 gdc
stop
On Sat, Dec 3, 2016 at 9:21 AM, Lucas Nussbaum wrote:
> Relevant part (hopefully):
>> /usr/bin/ld: dsimpleapp@exe/utils.d.o: relocation R_X86_64_PC32 against
>> symbol
>> `_D3std5array17__T8appenderTAyaZ8appenderFNaNbNfZS3std5array17__T8AppenderTAyaZ8Appender'
>> can
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 c
> 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 i
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: https://github.com/mesonbuild/meson/pull/946
Is it possible th
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 in
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 build test
The first
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:
https://ci.debian.net/data/packages/unstable/amd64/m/meson/20160218_083321
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 va
On Wed, Aug 12, 2015 at 4:31 PM, Niels Thykier 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 maintainers of som
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 configur
Hi
An NMU has been pushed to DELAYED/7. It should fix all open bugs apart from
the sparc bus error one.
Thanks,
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 eithe
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
- Chromi
On Tue, Oct 28, 2014 at 8:48 PM, Jakub Wilk 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 indeed p
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 dependencies
> 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.
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
On Sun, Jun 23, 2013 at 7:51 PM, Jakub Wilk 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 wishlist b
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 Information
On Thu, Jun 20, 2013 at 12:43 AM, Jakub Wilk 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 package on a VCS sna
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/
Package: wnpp
Severity: wishlist
Owner: Jussi Pakkanen
* Package name: meson
Version : 0.4.1-22-gea3e8f1
Upstream Author : Jussi Pakkanen
* URL : https://sourceforge.net/p/meson
* License : Apache 2.0
Programming Lang: Python
Description : high
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"
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
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 UNSUBSCRI
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...@list
> 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
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 abov
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 D
. 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]
101 - 161 of 161 matches
Mail list logo
