On Wed, Jun 08, 2011 at 11:28:52PM +0200, Andreas Tille wrote:
On Wed, Jun 08, 2011 at 11:26:22AM +0200, Andreas Tille wrote:
make[3]: *** No rule to make target `/usr/lib/libdl.so', needed by
`src/cadxcore/libCADxCore.so.2.4.1.1'. Stop.
I suspect removing the --parallel in
Hi Arno,
On Thu, 2011-06-09 at 01:19 +0200, Arno Töll wrote:
-(snip)-
* Do you really need the minor version in the SONAME (and hence
correctly reflected in the package name)? It is not wrong to do so, but
since your package is new and your both, major and minor version are 0
you could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kilian,
On 09.06.2011 09:28, Kilian Krause wrote:
the package name should be in sync with SONAME - no matter what ugly or
nice that makes the (binary) package name. ...
That being said, as Alexey is the upstream himself he can surely decide
On 2011-06-09 08:11 +0200, Andreas Tille wrote:
On Wed, Jun 08, 2011 at 11:28:52PM +0200, Andreas Tille wrote:
On Wed, Jun 08, 2011 at 11:26:22AM +0200, Andreas Tille wrote:
make[3]: *** No rule to make target `/usr/lib/libdl.so', needed by
`src/cadxcore/libCADxCore.so.2.4.1.1'. Stop.
On Thu, Jun 09, 2011 at 10:00:40AM +0200, Sven Joachim wrote:
However, the problem I was facing in the not yet released package
ginkocadx[1] seems to be quite common currently. It is in #629815 and
some similar case happens in #618094 and thus I'm suspecting a general
problem somehow. So
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will
Hi all
I have a question concerning multiarch [1,2]. From what I read it is
conceivable to have something like this on a system:
/usr/{lib,include}/i386-linux-gnu
/usr/{lib,include}/x86_64-linux-gnu
/usr/{lib,include}/x86_64-kfreebsd-gnu
/usr/{lib,include}/sparc64-linux-gnu
Particularly, the
Hi Arno,
thanks for the review!
I've done several changes, you proposed, partially added the
README.Debian with explanation on the SONAME change.
Some notes:
* Please push debhelper compatibility to version 8 (debian/compat,
debian/control), see debhelper(7).
Ok, switched to 8th version for
On 2011-06-09 11:19 +0200, Andreas Tille wrote:
On Thu, Jun 09, 2011 at 10:00:40AM +0200, Sven Joachim wrote:
The problem is that libdl.so has been moved to the multiarch paths in
libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you
done that already?
I'm building an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Alexey,
On 09.06.2011 12:45, rhash.admin wrote:
Ok, switched to 8th version for auto-running dpkg-gensymbols, but some
DDs (on #d-mentor) prefer to package with 7th debhelper to simplify
backporting.
That's right for oldstable. But Lenny is
Hi,
in case people might wonder about strange FTBFS like #629815 (which does
not seem to be the only bug of this type): There is a fair chance that this
will solve with some (future?) cmake package version. Just to let you know
before everybody needs to do the same investigation ...
On Thu,
Hi Alexey,
On Thu, 2011-06-09 at 17:45 +0700, rhash.admin wrote:
P.S. still looking for a Sponsor
where is the new and updated dsc? Same location?
--
Best regards,
Kilian
signature.asc
Description: This is a digitally signed message part
Hello!
http://mentors.debian.net http://mentors.debian.net/ gone down, so
can't check if server accepted the package,
though dupload has finished successfuly.
09.06.2011 18:30, Kilian Krause wrote:
Hi Alexey,
On Thu, 2011-06-09 at 17:45 +0700, rhash.admin wrote:
P.S. still looking for
Hello!
I was pointed that *rhash* packages are currently sitting unprocessed on
ftp://mentors.debian.net/
E.g. ftp://mentors.debian.net/rhash_1.2.5-1.dsc
09.06.2011 18:30, Kilian Krause wrote:
Hi Alexey,
On Thu, 2011-06-09 at 17:45 +0700, rhash.admin wrote:
P.S. still looking for a
On Thu, Jun 09, 2011 at 01:09:15PM +0200, Arno Töll wrote:
On 09.06.2011 12:45, rhash.admin wrote:
Hi,
Ok, switched to 8th version for auto-running dpkg-gensymbols, but some
DDs (on #d-mentor) prefer to package with 7th debhelper to simplify
backporting.
That's right for oldstable. But
On Thu, Jun 02, 2011 at 03:57:58PM +0200, Alessandro Ghedini wrote:
I am looking for a sponsor for my package cityhash.
* Package name: cityhash
Version : 1.0.2-1
Upstream Author : Geoff Pike and Jyrki Alakuijala (Google, Inc.)
* URL :
* Alessandro Ghedini al3x...@gmail.com, 2011-06-02, 15:57:
http://mentors.debian.net/debian/pool/main/c/cityhash/cityhash_1.0.2-1.dsc
I saw this in city.h:
| typedef uint8_t uint8;
| typedef uint32_t uint32;
| typedef uint64_t uint64;
| typedef std::pairuint64, uint64 uint128;
|
| inline
Den 09. juni 2011 12:18, skrev Michael Wild:
Hi all
I have a question concerning multiarch [1,2]. From what I read it is
conceivable to have something like this on a system:
/usr/{lib,include}/i386-linux-gnu
/usr/{lib,include}/x86_64-linux-gnu
/usr/{lib,include}/x86_64-kfreebsd-gnu
Hi Mentors,
I want to package a library which hast the following lines in
CMakeLists.txt
IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib64)
ELSE (CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
now, how do I have to handle this in debian/libxyz.install?
Richard Ulrich ri...@paraeasy.ch writes:
I want to package a library which hast the following lines in
CMakeLists.txt
IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib64)
ELSE (CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
now, how do I have to
Den 09. juni 2011 20:08, skrev Ove Kaaven:
In general, it's *native* compilation that would change; libs would be
installed into /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)
Hmm, I think I meant $(dpkg-architecture -qDEB_HOST_MULTIARCH), it might
be different if cross-compiling (though
Hi mentors,
hope this is the right list for it, I wouldn't abuse debian-devel for it.
[please keep me on CC, I'm not subscribed]
I maintain a custom Debian installation on Clients without any user
interaction during upgrade, so everything has to go automatically.
I created a meta package to
On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote:
The problem is that libdl.so has been moved to the multiarch paths in
libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you
done that already?
I'm building an unstable pbuilder chroot. It is using the cmake
Erik Schanze (Debian) schan...@gmx.de writes:
I maintain a custom Debian installation on Clients without any user
interaction during upgrade, so everything has to go automatically.
I created a meta package to define dependencies to all packages I need
on the clients and I'd like to make this
On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery r...@debian.org wrote:
On Debian, you should always install into lib and never use lib64.
(Eventually, you may want to use the multiarch directory, but it will
still not be lib64.)
That was my first thought, but I couldn't find a
David Bremner brem...@debian.org writes:
On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery r...@debian.org wrote:
On Debian, you should always install into lib and never use lib64.
(Eventually, you may want to use the multiarch directory, but it will
still not be lib64.)
That was my first
Le vendredi 10 juin 2011 00:38:12, David Bremner a écrit :
On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery r...@debian.org wrote:
On Debian, you should always install into lib and never use lib64.
(Eventually, you may want to use the multiarch directory, but it will
still not be lib64.)
On Thu, 09 Jun 2011 15:41:34 -0700, Russ Allbery r...@debian.org wrote:
9.1.1 point 2:
The requirement for amd64 to use /lib64 for 64 bit binaries is
removed.
Yeah, that is the point that confused me. For me, removing the
requirement is not the same as forbidding.
Also note
Hi,
I ITA cronolog a couple of weeks ago, after some learning and bug
fixing, the package is ready. This package need now a sponsor to
continue his life. =)
It appear to be lintian clean. and can be found here:
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=cronolog
On Mon, 6 Jun 2011, Filip Brcic wrote:
Just bumping the thread.
I would really appreciate if somebody would sponsor the serbian support for
aspell package. The package itself is mostly identical to any other aspell-*
package, so too much reviewing shouldn't be necessary, I think.
This is
30 matches
Mail list logo
