Stephen Kitt [2014-03-19 23:25 +0100]:
Wouldn't it make sense to change DEP8 to encourage building
whatever is strictly required for the tests, and perhaps drop
build-needed altogether?
I wouldn't want to drop build-needed, as it only complicates things
for the cases where
Stephen Kitt [2014-03-19 23:54 +0100]:
On Wed, 19 Mar 2014 13:49:52 +0100, Andreas Tille andr...@an3as.eu wrote:
On Wed, Mar 19, 2014 at 11:47:02AM +0100, Jakub Wilk wrote:
Long answer:
You can declare that a test needs to be run from a built source
tree. Then the test runner will
Hi Stephen,
On Wed, Mar 19, 2014 at 11:54:03PM +0100, Stephen Kitt wrote:
...
Thanks for the clarification / sharing your opinion.
Moreover I observed another issue with autopkgtest which is quite
astonishing to me: In bug #741274 it was reported that the autopkgtest
would fail and the
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package geos
Package name: geos
Version : 3.4.2-4
Upstream Author : GEOS Developers geos-de...@lists.osgeo.org
URL : http://trac.osgeo.org/geos/
License :
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package osgearth
Package name: osgearth
Version : 2.5.0+dfsg-1
Upstream Author : Glenn Waldron
URL : http://osgearth.org/
License : LGPL-3
Section :
Hi Bas,
I guess you forgot to `git push` ...
Kind regards
Andreas.
PS: Please CC me if you did.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Hi Andreas,
I guess you forgot to `git push` ...
I did, sorry for my oversight. The branch on git.d.o is update to date now.
Kind Regards,
Bas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Jakub Wilk [2014-03-19 11:52 +0100]:
autopkgtest calls dpkg-buildpackage to do the actual package
build, so for adding this to autopkgtest explicitly, we could add
a flag for that and call dpkg-buildpackage --target.
If by a flag you meant a new restriction, then it sounds good to
me. :)
I
* Martin Pitt mp...@debian.org, 2014-03-20, 07:51:
I'm happy to add a stanza to its documentation to avoid it for
packages which take a nontrivial amount of time to build; does that
sound like an acceptable compromise?
It does indeed, with Jakub's idea of copying only the required code to
Actually, you usually don't get these kind of warnings for Python extension
modules. The warning is emitted only if a module has SONAME, and it
typically doesn't.
You might want to get rid of SONAMEs
That indeed was the problem. Thanks!
It's a CMake/SWIG build, and I now added a patch to set
Package: sponsorship-requests
Severity: normal
Dear mentors,
As part of the SpatiaLite transition I am looking for a sponsor for
my package qgis
https://release.debian.org/transitions/html/libspatialite5.html
https://release.debian.org/transitions/html/librasterlite2.html
Please refer to the
Hi all,
I'm building a package for a library A that depends on another
library, libB.so (from its dev-version). When installing library A,
the package libb is installed, containing libB.so.7.2 and libB.so.7.
When linking an executable against libA.so, the linker rightfully
complains about a
* Martin Pitt mp...@debian.org, 2014-03-20, 11:17:
autopkgtest calls dpkg-buildpackage to do the actual package build,
so for adding this to autopkgtest explicitly, we could add a flag for
that and call dpkg-buildpackage --target.
If by a flag you meant a new restriction, then it sounds good to
Le 20/03/2014 13:22, Nico Schlömer a écrit :
Hi all,
I'm building a package for a library A that depends on another
library, libB.so (from its dev-version). When installing library A,
the package libb is installed, containing libB.so.7.2 and libB.so.7.
When linking an executable against
which must depend on libB-dev.
libB-dev is indeed not explicitly listed as a dependency of libA-dev,
mostly because I was under the impression that ${shlibs:Depends} takes
care of this, cf. https://wiki.debian.org/IntroDebianPackaging. Is
that not the case?
Cheers,
Nico
On Thu, Mar 20, 2014
On Wed, Mar 19, 2014 at 11:47:02AM +0100, Jakub Wilk wrote:
I hope that ci.debian.net is configured in such a way it uses binary
packages from the archive.
It is.
--
Antonio Terceiro terce...@debian.org
signature.asc
Description: Digital signature
Le 20/03/2014 14:06, Nico Schlömer a écrit :
which must depend on libB-dev.
libB-dev is indeed not explicitly listed as a dependency of libA-dev,
mostly because I was under the impression that ${shlibs:Depends} takes
care of this, cf. https://wiki.debian.org/IntroDebianPackaging. Is
that
Hi,
I tried to clean up only those debs from pbuilder apt cache which are
outdated and not used any more. Since --autocleanaptcache only results
in printing the help page I did some research and the only hint on the
weg is this quite old bug in Ubuntu:
Hi
On 3/20/14, Nico Schlömer nico.schloe...@gmail.com wrote:
I'm building a package for a library A that depends on another
library, libB.so (from its dev-version). When installing library A,
the package libb is installed, containing libB.so.7.2 and libB.so.7.
When linking an executable
On 20/03/14 14:27, Andreas Tille wrote:
Hi,
I tried to clean up only those debs from pbuilder apt cache which are
outdated and not used any more. Since --autocleanaptcache only results
in printing the help page I did some research and the only hint on the
weg is this quite old bug in
* Stephen Kitt sk...@debian.org, 2014-03-19, 23:25:
FTR, we explicitly make use of that for our toolchain packages: gcc,
binutils, linux, and eglibc have a bin/true test with needs build
to ensure that whenever we update one piece, the others are still
buildable and their tests succeed (which
Stephen Kitt writes (Re: DEP8 tests using the built package source):
(Hi Ian, I'm adding you to the discussion since I'm talking about changes to
DEP8. I've snipped the exchanges but I hope you can get the gist of it
without needing to spend time looking anything else up!)
Hi. Sorry about the
Hi,
On 2014-03-13 05:57, Robert Ransom wrote:
I am looking for a sponsor for my package libb2:
I'm not a DD so I can't sponsor your package, but here is a quick review:
Building
There is one troublesome aspect of the upstream code: AFAICT,
CPU-specific optimizations such as MMX,
* Johannes Schauer j.scha...@email.de, 2014-03-19, 06:31:
[I don't intend to sponsor this package. Sorry!]
dont worry, I'm happy for any help that can improve my packaging! :)
All right… :-P
I wouldn't repack the .orig.tar just to remove debian/. If you're using
the 3.0 (quilt) format,
On 2013-11-14 00:32, Bryan Conrad wrote:
I am looking for a sponsor for my package libpoly2tri
I'm not a DD so I cannot sponsor your package, but hoping that you are
still interested in contributing to Debian (despite the long time passed
since your ITP) I'd like to offer some feedback.
* Christian Kastner deb...@kvr.at, 2014-03-20, 22:49:
This is problematic. First, you need to demangle the symbols in there
with c++filt (for examples, your package FTBFS on my host without
this).
I haven't looked into details of this particular package, but in general
unmangling rarely
On 2014-03-20 23:21, Jakub Wilk wrote:
* Christian Kastner deb...@kvr.at, 2014-03-20, 22:49:
This is problematic. First, you need to demangle the symbols in there
with c++filt (for examples, your package FTBFS on my host without this).
I haven't looked into details of this particular
On 2014-03-20 23:21, Jakub Wilk wrote:
For example, symbol names for a f(size_t) function are:
_Z1fj on i386,
_Z1fm on amd64.
After unmangling it becomes:
f(unsigned int) on i386,
f(unsigned long) on amd64.
Well, after researching a bit, the only somewhat manageable solutions I
can think
On 2014-03-21 00:00, Christian Kastner wrote:
On 2014-03-20 23:21, Jakub Wilk wrote:
A) using symbols.common + symbols.$arch
B) using symbols.common + symbols.arch, using (arch= ) tags
C) using symbols + (c++|regex) tags
Missed an obvious one:
D) using symbols + (c++|arch=) tags
--
To
Your message dated Fri, 21 Mar 2014 04:36:16 +
with message-id e1wqrbo-000300...@quantz.debian.org
and subject line closing RFS: geos/3.4.2-4
has caused the Debian Bug report #742173,
regarding RFS: geos/3.4.2-4
to be marked as done.
This means that you claim that the problem has been dealt
Your message dated Fri, 21 Mar 2014 04:36:22 +
with message-id e1wqrbu-00033h...@quantz.debian.org
and subject line closing RFS: osgearth/2.5.0+dfsg-1
has caused the Debian Bug report #742175,
regarding RFS: osgearth/2.5.0+dfsg-1
to be marked as done.
This means that you claim that the
31 matches
Mail list logo
