Re: RFS: aspell-sr

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 grea

ITA-RFS: cronolog - logfile rotator

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 ht

Re: /usr/lib64 or /usr/lib

On Thu, 09 Jun 2011 15:41:34 -0700, Russ Allbery 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 that /usr/li

Re: /usr/lib64 or /usr/lib

Le vendredi 10 juin 2011 00:38:12, David Bremner a écrit : > On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery 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 w

Re: /usr/lib64 or /usr/lib

David Bremner writes: > On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery 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

Re: /usr/lib64 or /usr/lib

On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery 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 straightforward justif

Re: How to make a meta package unremovable?

"Erik Schanze (Debian)" 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 meta pack

Re: Bug#629815: No rule to make target `/usr/lib/libdl.so'

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

How to make a meta package unremovable?

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 def

Re: Multiarch question

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

Re: /usr/lib64 or /usr/lib

Richard Ulrich 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 handle this i

/usr/lib64 or /usr/lib

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? Rg

Re: Multiarch question

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-gn

Re: RFS: cityhash - family of non-cryptographic hash functions for strings

* Alessandro Ghedini , 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::pair uint128; | | inline uint64 Uint128Low64(const uint128& x

Re: RFS: cityhash - family of non-cryptographic hash functions for strings

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 : http://code.google.c

Re: RFS: RHash - Utility for computing hash sums and magnet links

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 oldsta

Re: RFS: RHash - Utility for computing hash sums and magnet links

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 Spons

Re: RFS: RHash - Utility for computing hash sums and magnet links

Hello! 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

Re: RFS: RHash - Utility for computing hash sums and magnet links

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

Multiarch with cmake seems to cause FTBFS (Was: Bug#629815: No rule to make target `/usr/lib/libdl.so')

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, Jun

Re: RFS: RHash - Utility for computing hash sums and magnet links

-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

Re: No rule to make target `/usr/lib/libdl.so'

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 buildi

Re: RFS: RHash - Utility for computing hash sums and magnet links

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 fo

Multiarch question

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 cas

Bug#629815: Info received (No rule to make target `/usr/lib/libdl.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 rep

Re: No rule to make target `/usr/lib/libdl.so'

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 someh

Re: No rule to make target `/usr/lib/libdl.so'

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'. S

Re: RFS: RHash - Utility for computing hash sums and magnet links

-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 >

Re: RFS: RHash - Utility for computing hash sums and magnet links

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 pro