Re: Should .a library contains non-reallocatable code?
On 23/02/2015 19:17, Ian Jackson wrote:
> Ian Jackson writes ("Re: Should .a library contains non-reallocatable code?"):
>> Jeff is correct.
> ...
>> That not usually a problem. Providing that only the relevant symbols
>> are exported from the .so, the executable simply results in multiple
>> completely independent copies of the static library.
> I should say that I agree with the conclusions of others in this
> thread, that policy's rules about -fPIC for static libraries are
> wrong.
>
> Where only a static library is provided, it should be built _with_
> -fPIC unless it is expected never to be included in any shared object
> (which is probably hard to predict, but I guess there might be cases
> where the maintainer might know).
>
> Where a .so is provided too then the static library is normally used
> only in cases where no dynamic linking is done at all, and then
> -fPIC is probably undesirable. This is of course the usual case.
>
> Ian.
>
>
I agree with this; are there any cases where only a static library _is_
provided, and if so why? why not provide a .so?
The original examples are only problematic because they are linked
to a static .a rather than .so.
In my packages I always provide a -fPIC .so and non-fPIC .a library,
the latter for performance where it matters (these days typically slight).
regards
Alastair
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ec4bdd.1060...@sceal.ie
Re: Should .a library contains non-reallocatable code?
On 2015-02-24 11:01, Alastair McKinstry wrote: > I agree with this; are there any cases where only a static library _is_ > provided, and if so why? why not provide a .so? One use case that was described to me was about libraries with APIs that were not yet considered stable enough to be (properly) supported as a shared lib. Regards, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8d05031c007b19790eff117cca12c...@kvr.at
Bug#779087: ITP: libmoops-perl -- moops object-oriented programming sugar
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libmoops-perl Version : 0.034 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Moops * License : Artistic or GPL-1+ Programming Lang: Perl Description : moops object-oriented programming sugar Moops is sugar for declaring and using roles and classes in Perl. . The syntax is inspired by MooseX::Declare, and Stevan Little's p5-mop-redux project (which is in turn partly inspired by Perl 6). . Moops has fewer than half of the dependencies as MooseX::Declare, loads in about 25% of the time, and the classes built with it run significantly faster. Moops does not use Devel::Declare, instead using Perl's pluggable keyword API. . Moops uses Moo to build classes and roles by default, but allows you to use Moose if you desire. (And Mouse experimentally.) Package will be maintained in the perl team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7GPNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhslAP/2pKfH4FRKEHxErVu9/u9GOr txo6+ROiAcia8U0NRDScNQ6bHUWdO3MlpMLsMXotGZk/8aFG97+X1P05aOpRa03H R468XP3oK/ujo94CMxfyHiV+CN7PGgQWL85kl57l6V0BH+fOH8nwtKaOOPWh8czv LG5BMDRZwPvcbL7JEZHUxROqfUMvtay2sTGkxR37GxHrEGa8v3YKfeSl63a1cWPH J1YHKFlFjAvAwXiDMry12MLBK7/v9KS/DODd1cWakn+YJ83kHZHSxz/HdtLm9Tvp eb8YtT0+yCczJZnoxvbXieddnvVFyUIaefiu/lLEvHafkuq6nHA6vGm6fSU5ndWy Bu2HAi1qUwvnWgoD+e0fr/txUF8CQWdIBVRBQzlkcoWTYV9Qs2AvrBWItp/QLyaD UC1Baw5rTXGN7BtChGekH/HRazhAS1leguuBurtR+0cx5acsUlsGLCx32bACiWPK zyHGISDBJwL/NAoWwetg8BSh3yGD9G4CoLvcgHQCZcwrm5d6o3KsQ5OPawkfbDKy mtHuzWS61bmtaD+eQbsxeqO18Jc5perv9XENFv0Y9WD+Pf6rtvEIqOwYwi59I16X jAhlTe/mwd4XHXj6qKTp+s3gNwkGz+QmP5nj64SnwTBZvBrB8pigoRe6klbzTF3+ ii3B32F7JcSwfdH0NjN7 =08bp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224114312.18854.11683.report...@bastian.jones.dk
Bug#779088: ITP: libkavorka-perl -- function signatures with the lure of the animal
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libkavorka-perl Version : 0.035 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Kavorka * License : Artistic or GPL-1+ Programming Lang: Perl Description : function signatures with the lure of the animal Kavorka provides "fun" and "method" keywords for declaring functions and methods. It uses Perl 5.14's keyword API, so should work more reliably than source filters or Devel::Declare-based modules. . The syntax provided by Kavorka is largely inspired by Perl 6, though it has also been greatly influenced by Method::Signatures and Function::Parameters. Packaging will be done in the perl team. Package is needed by libmoops-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7GZsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhk1UP+gOvfC/u1b6fQlaT1zn+OHai PWUcHNtjzid9k9tzw49YYHiZLo80Z5Kipah2YS+p6yIYnccpx6bnWWii3ie73AZy vYh+X/ALepjLva8/UxUS6wlmsXB5COcRLiRye4tIdKuCKgFwlYSAYy6AxIo7a0jO WVIdkWLiwtXiufvg+H2mxb/9PoKjB0UO6BJlMOAuFU4+kVCG6LVpeynThh9zAcbv vImwFtDXoI0+oUaG77tvVE6mS3HhRBHuhUqXfSEBdyomaEvyRwherh7Zr/C4etc7 lti2vXOARWIKbeDQXX8/O9ZS9/KSmAOaNtvkVmIOrMtz8UmYqVaAIKWzN5mA8FnB xZW23zZ2KSDdIGUre36H8z9HvjoxQs/kJM6dZnoDxekp827DGA2eNvgseCRb6xuw C0u+yDCPgf0fWReVEI7g0Y329EYXHFUS3d50r0HkWq2cYXUn6nlo3xg3v2jzTjr8 eZtHqPfmYIN5xSmsKI0Y7A5yinaDHe0qWHeCj+JlcMtNEuJHEBx1r84mtLFJ3cAt dJVzht8XEkTctbPqJLKavM7n/vWoyIYzjj/WHH4qKHvHftGVrJb/LUcHnWhZT/oG eWD2cZprxx7PsqFKpNe8LFQVxQ+1SljtUDtjgvMwoTDVMA5VnbwLQhG9oDdIiHgS wA46LWCGAX5mtzL4X0IX =Y5SM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224115420.19662.38052.report...@bastian.jones.dk
Bug#779091: ITP: libreturn-type-perl -- specify a return type for a function (optionally with coercion)
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libreturn-type-perl Version : 0.005 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Return-Type * License : Artistic or GPL-1+ Programming Lang: Perl Description : specify a return type for a function (optionally with coercion) Return::Type allows you to specify a return type for your subs. Type constraints from any Type::Tiny, MooseX::Types or MouseX::Types type library are supported. Packaging will be maintained in the perl team. Package is needed by libmoops-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7HRzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhqM4P/jXX6s4SJFAfZNReFVF0KiqG UA0tseL43LqQaxLTBgXD1MNGrxKxlJew5yLBs1ms630hvDJK6lDHMQ6ce4fvjRcP Pxl4Ak2kC3TgAe1HFe6Zciecczd+qrgKWdOffuWPEr2N/O+eonCh6eS7npAorXd4 a8gQBnwqMA5nmdorRg6gD8MZ6y5rmKLXdP0/m4Zu6UCk8AEDXU7fomuVisUe+IK6 B+gg8tsufPGyHwtWNPs1qS4F/GxVPViqfOXQc+CP1GHyyLRr3r8Qum9fJM04vdes ksGffbwzLj8fFHOd04a5p63gKF9m0pyfeeku/dymc4ApmZ9StJsa9tPQsBRRts/R hf/qQR58iENP4sYRblETR0sqTPwdG6KvqEumXXyP7PMaFFIfR66bJQdy0ik84EYB 5zOiLECTC5MQuFgc0J6+dIkIn26TP6EjC6B/rCLk4+AKyZ3IJBMERheioYdfeflf 8LXHtJq2G2bk2vcTiaUPxHvlpUAWhGpilSb8zMY8r52suIuCtfV+OQuGZmrK9zWW hn5Ha3i9UE4u7VmZ9STH/5vIpg6GKbSHA/e8/Icle+9+neveB0WsQfAWvzSmxjCY anyKvZQumWwmYylUvWRHTwHqvOuoEaMYnHiITlIBJeNRd9r75eQ2Vw7d06sQNNse agTs2tkcT+pegM4gT2rX =wbho -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224125415.22499.19900.report...@bastian.jones.dk
Bug#779096: ITP: python-requests-aws -- S3 AWS authentication for the requests module
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-requests-aws Version : 0.1.6 Upstream Author : Paul Tax * URL : https://github.com/tax/python-requests-aws * License : BSD-3-clause Programming Lang: Python Description : S3 AWS authentication for the requests module AWS authentication for Amazon S3 for the wonderful Python requests library. At the moment only S3 is supported. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224135439.23785.79438.report...@buzig.gplhost.com
Re: jessie for x32
On 02/22/2015 03:56 AM, Adam Borowski wrote: > Hi folks! > Here's some news about the x32 port. > [...] What you've done is just awesome. I'm sure there's a ton of application, especially on the server side. It's great to have the full power of the 64 bits arch without doubling the RAM usage (famously, on the server side, PHP & Perl comes to mind...). Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ec8557.8000...@debian.org
Re: conflicts between Debian's and upstream's Debian package
Hi Andreas, On 02/20/15 18:54, Andreas Tille wrote: > Hi Harald, > > Is there any reason why you do not even now are talking about package > name and upstream URL featuring the same name? Its not fruitful to > leave your discussion partners in the dark. > Sorry, but I don't want to blame anybody producing "bad" packages. It shouldn't matter here. Hope you agree? Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ec860b.1060...@aixigo.de
Re: conflicts between Debian's and upstream's Debian package
On 02/24/15 15:09, Harald Dunkel wrote: > > Sorry, but I don't want to blame anybody producing "bad" packages. > It shouldn't matter here. > Should be: Sorry, but I don't want to blame anybody to produce "bad" packages. Name and upstream URL shouldn't matter here. Sorry for my bad English. Regards Harri -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ec884a.1030...@aixigo.de
Re: Should .a library contains non-reallocatable code?
(I have reordered Bernard's mail and my responses to try to produce a
coherent whole.)
Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
code?"):
> [examples not involving -Bsymbolic]
My view is that when trying to build a shared library that depends on
a static library, -Bsymbolic should always be used and the static
library should always be included in the shared library.
The fact that not using -Bsymbolic causes breakage is IMO expected.
The main thrust of your mail is arguments (A) against including the
static library in the .so which depends on it and (B) against using
-Bsymbolic. I am not convinced.
I still maintain that shared libraries depending on static libraries
should include a copy of the static library (rather than having
unresolved symbols and expecting the static library to be in the
executable). Consequently a static library which might have to be
used for this purpose must be built with -fPIC. (If there is a
corresponding shared library then this problem doesn't arise.)
Firstly, (A), whether to include a static library in a shared library
which uses it; or, alternatively, whether to expect executables
dynamically linked against the shared library to be also statically
linked against and hence contain the shared library:
> Unresolved symbols is just the way dependencies of libraries
> works. The only thing missing here is the missing dependency on the
> static library. But that is simply not possible with static
> libraries.
In practice, a .so built in the way you suggest (with unresolved
references to the dependent static libraries) is not sanely useable in
the ways people normally want to use shared libraries. See just below
for a detailed explanation:
> Ian Jackson [150223 20:09]:
> > (In particular, this would vitiate libbar's stable API/ABI.)
>
> This you have to explain.
For libbar.so to be a reasonable thing to ship separately, it must
have a stable ABI. This is necessary so that programs
compile-time-linked against one version of libbar can be later
run-time-linked against a different version of libbar.
But if compile-time-linking against libbar.so requires statically
linking to a libfoo.a which does /not/ have a stable API, then any
executable which is built against a particular libbar.so contains
copies of parts of libfoo.a in the executable. When that executable
is then run-time-linked against a different version of libbar.so,
which was built against a different version of libfoo.a, things will
go wrong:
The code in the new libbar.so will contain references to symbols
(functions and data) in libfoo.a, but will have been compiled to
expect those functions and data to have the ABI in the new libfoo.a.
But the run-time linker will resolve those undefined symbol references
in the new libbar.so to the definitions provided by the copy of
libfoo.a in the executable, which have the ABI for the old libfoo.a.
So a .so built this way is not useful. In fact, it is worse than a
static library. At least with a static library the correct
corresponding versions of everything are assembled together at
compile-time-link, and the risk of ABI mismatches is much reduced.
So if (for a particular upper library) we can't make a .so which
includes the static lower library, then there should be no .so at all.
> If you think there is another way a dynamic library can use a static
> library please tell so.
I have done so. It involves -Bsymbolic. See my example.
(B) on whether to use -Bsymbolic.
> Note that this uses -Bsymbolic, by which you hide some issues and might
> introduce other problems (depending on your library).
This is FUD.
It's true that you need to be aware of what you're doing and that
there are still ways to screw up. But that does not mean that it is
impossible to do correctly. See below where I address those specific
issues you raise.
> There are only two possibilities:
>
> You want a static library, then the static library has to be linked into
> the executeable directly.
As my example demonstrates, this is not true. It is possible to link
the static library into a shared object.
Usually, there is no problem with two different copies of the static
library being contained within the process and both being in use.
The exceptions are:
(a) the ABI/API of the shared library mentions things in the API/ABI
of the static library. But in such a case the shared library itself
obviously does not have a stable ABI and making a shared library out
of it was probably a mistake.
(b) the static library expects exclusive use of process-global system
facilities (the most obvious examples being some uses of fork and
signals, especially in multithreaded programs). But in such a case
the shared library also demands (in the semantics of its API) such
exclusive use; so it is unreasonable to also link into the program,
and simultaneously use, a different shared library which also demands
such exclusive use (by virtue of its use of the the sa
Re: Should .a library contains non-reallocatable code?
Jeff Epler writes ("Re: Should .a library contains non-reallocatable code?"):
> On Thu, Feb 19, 2015 at 05:19:30PM -0600, Jeff Epler wrote:
> > * foomodule is a Python wrapper for libfoo, so it must be shipped
> >as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
> >it is not possible to build foomodule at all
> >
> >(The same goes for wrapping the library for most other interpreted
> >languages)
>
> So here is a concrete example of this. I chose libtomcrypt at
> semi-random, because in libtomcrypt-dev 1.17-6 there is both a shared
> library and a static library; the latter has non-PIC code.
This is of course an artificial example. Because libtomcrypt has a
shared library, it would be better to use that and avoid all of these
problems.
But if libtomcrypt had only a .a (perhaps because it has no stable
ABI) then it ought to be compiled -fPIC, to avoid the problem you
describe.
In that case your tommodule.o ought to be compiled with -Bdynamic (or
use a version file, as you demonstrate).
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21740.36969.435710.598...@chiark.greenend.org.uk
Re: conflicts between Debian's and upstream's Debian package
Quoting Harald Dunkel (2015-02-24 15:09:15) > On 02/20/15 18:54, Andreas Tille wrote: >> Is there any reason why you do not even now are talking about package >> name and upstream URL featuring the same name? Its not fruitful to >> leave your discussion partners in the dark. >> > > Sorry, but I don't want to blame anybody producing "bad" packages. > It shouldn't matter here. > > Hope you agree? I disagree: We won't hide problems. (Sure I agree that we shouldn't throw blame, but that's on you to collide those two, not me) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224145535.15462.78...@bastian.jones.dk
Re: conflicts between Debian's and upstream's Debian package
On Tue, Feb 24, 2015 at 03:55:35PM +0100, Jonas Smedegaard wrote: > I disagree: We won't hide problems. > > (Sure I agree that we shouldn't throw blame, but that's on you to > collide those two, not me) The "bad" packages Harald is talking about, I think, are external to Debian — I don't think he's trying to protect a DD here. So this is courtesy rather than hiding problems. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224155344.ga17...@chew.redmars.org
Bug#779106: ITP: libmoosex-xsaccessor-perl -- use Class::XSAccessor to speed up Moose accessors
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libmoosex-xsaccessor-perl Version : 0.007 Upstream Author : * URL : * License : Programming Lang: Perl Description : use Class::XSAccessor to speed up Moose accessors MooseX::XSAccessor accelerates Moose-generated accessor, reader, writer and predicate methods using Class::XSAccessor. You get a speed-up for no extra effort. It is automatically applied to every attribute in the class. Packaging will be maintained in the perl team. Package is (optionally) needed by libmoops-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7KONXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEh/rMP/AxtNIXaI7bLnwyXelh4FgNS diI1APMfyHqHVT6VPnr+tqZeOGBz8gFHSb+x4LRX0GguKOkNGL1FsNROzY5UuA/V krMzKWGqs8zW6ZYFi4oXZN8+R/LPwN/kplAgGKsoKPl6WhxK6bSbF8VHacmFMjTl Yv8BX6IhKWUXCU19zZ3ZABqXgp8FtsSydvO4M5zW04Y6kAufKiMQF9W1Wy2pa9kv txXCDKA6g6gJCIR3OxQIY9PiM4W+ddsxvqFrbbjDA4UHL94EN0+fC4t1299QvH9D nkxs1l8ktt4Fvj0zy6qtUrprRaAoq1GsJBzRve2Kl3+OxS36jIBhiYirF+gsvbUN W48mwzVBXWXIV6ZRooIQsrUnwTmegutv25+7jj24Kz7lRDVPKcNsm2wAHWrBRYY0 40LqWQIKm5Vm3FHHR91fOkzihBjz+revsU/QIGL9PegrhSwJhTWSQ8e3SYI+LHg1 hdraGRQkuT8vqhx7YMpVSrwFAEmbwMQlMbzSgdbrSpg3Weo6gBGX4e5LboKpKeMQ 5HGZ2k2XdtDZuKN3+Lg10Mhce49aidAyxoaKRBeFaUAQW5svQxPwZsuLWKmLojec HHmLk3j+6OqjDfdJBk1Q6e4EAvqGAlXWTefOQTPDTZV6DPG/Lz/zt6c5t8TzMA5k cKhcKIVCJuHeiGB9bW8p =yF3X -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224161509.3770.74208.report...@bastian.jones.dk
Re: conflicts between Debian's and upstream's Debian package
Jonathan Dowland writes ("Re: conflicts between Debian's and upstream's Debian
package"):
> The "bad" packages Harald is talking about, I think, are external to
> Debian — I don't think he's trying to protect a DD here. So this is
> courtesy rather than hiding problems.
I don't think reference to the Social Contract is really helpful as an
argument (in other direction) on these kind of matters.
I think in most cases it would be perfectly possible to name the
upstream in question without "shaming" them.
Just because an upstream (or indeed anyone else) has done something
technical differently to the way we would have done it doesn't mean
that they are wrong. And even if they are wrong, we recognise that
(a) everyone makes mistakes (b) everyone has limited effort for doing
thins well.
The questions raised in this thread are mixed social and technical
ones. It is difficult to properly suggest how to improve matters
without knowing lots more about the context, including the technical
constraints and the factors behind the various people's
decisionmaking.
In other words I don't think that there is much that can be usefully
be said about the original abstract question, as posed.
If the OP would tell us what, specifically, we are talking about, it
might be possible to come up with useful answers and suggestions.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21740.45200.824215.710...@chiark.greenend.org.uk
Bug#779130: ITP: libdevel-strictmode-perl -- determine whether strict (but slow) tests should be enabled
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libdevel-strictmode-perl Version : 0.003 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Devel-StrictMode * License : Artistic or GPL-1+ Programming Lang: Perl Description : determine whether strict (but slow) tests should be enabled Devel::StrictMode provides you with a constant `STRICT` which you can use to determine whether additional strict (but slow) runtime tests are executed by your code. Packaging will be maintained in the perl team. Package is needed by libmoops-perl -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7LLbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhBEIP/2Sp5osS/FRav2n62vjkyN1n mIKGu40Ie8iMVgdbVg9rn/oQrnWaq6d3lpWDHEcPk32f9usWjWdYF8P4RY/N1iPo lXdGSQ94bWjwLcn7DuVbcpiRp3teCR/i9ni6p9zfQBvjklO/FR0bPUsUJ8SU/cJQ AXrZjYZIZJaSXhOH3wTJN5Ly93mBA48APAJTgaq9Y0lTC6WHFA9DUaA8t0/IfljD ZrMuagVJHYy77u0eJ1viMKbMW0pjBwIV0QmcBPYg4n9eByrvFqpqVjcOF4ziXqiQ VpNSrKgC/1J6Zicxfztrro4lO6Dkf3IFM8DZcDzzspE3Ys9iWni72zO5eTHYoT2l +fhy0T8fOfv8n7buUMTzGGh3GClFlaut2vmcTwIUE4fe0nyIih8TaFnLVUgan/MH +ktYf/BguyQ057oQp1wqguaQJM3rhig8GBuSX3x22VZ7WJBskerLt4FWUZS1zXEw ZyY9YiLb5sVV/dNu1cQ9lQ1YH7eNTisDvZR0DHA2A3QoC49BoCHDGsLac+JkZnxA 2GskQqUMUVpzrC7H9ngPxjMydYBGdnwrOizjzFr28BuCRuO4VQkU1y8uYPdenWAr 63JkT4po6HVydHg6/O3hSX0uXdrTV7Mruy16tu3/BztrCAMz7Rnu6nH5mGss5shS wzWd7/0936gd94bX+zPe =jR6G -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224172027.9329.69010.report...@bastian.jones.dk
Re: Should .a library contains non-reallocatable code?
* Ian Jackson [150224 15:50]:
> > You still pollute the ABI with the details of the internals:
> >
> > if you try to change main.c to:
> > #include
> > #include "foo1.h"
> > #include "bar2.h"
> > int main() {
> > double rr1;
> > foo(&rr1);
> > int r1 = rr1;
> > int r2 = bar2();
> > printf("%d %d\n", r1, r2);
> > return 0;
> > }
> >
> > and run gcc -Wall main.c -L. -lbar2 -lfoo1 ; LD_LIBRARY_PATH=. ./a.out
> > you get:
> > foo2: 0x7f42db6f0a48
> > foo2: 0x7f42db6f0a48
> > 0 17
> >
> > (In this specific case a version script might helps, but I'd not bet
> > on helping in all cases).
>
> I don't know what exactly you ran. Your transcript is not complete
> and I don't get the same results. I suspect you didn't pass
> -Bsymbolic everywhere.
>
> I changed main.c to contain the code you just showed, and reran by
> ./build script (same as before), and got this:
[...]
>
> (64)ian@zealot:~$ ./build
> + egrep . bar.c bar1.c bar1.h bar2.c bar2.h foo.c foo1.c foo1.h foo2.c foo2.h
> main.c t.c build
> [...]
> main.c:#include
> main.c:#include "foo1.h"
> main.c:#include "bar2.h"
> main.c:int main() {
> main.c: double rr1;
> main.c: foo(&rr1);
> main.c: int r1 = rr1;
> main.c: int r2 = bar2();
> main.c: printf("%d %d\n", r1, r2);
> main.c: return 0;
> main.c:}
> [...]
> + gcc -Wall main.c -L. -lbar1 -lbar2
You forgot to change that line as I said to change it.
main.c now uses libfoo1 and libbar2, so in my example I build against
those. Now you only need a bit of bad luck to use -lbar2 -lfoo1 in
that order and you get the problem. -Bsymbolic only helps against bar
being poluted. It does not help against libbar polluting the main
program. (For this you need at least something like symbol versioning
to hide the symbols).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150224173825.ga1...@client.brlink.eu
Bug#779132: ITP: libperlx-assert-perl -- yet another assertion keyword
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libperlx-assert-perl Version : 0.904 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/PerlX-Assert * License : Artistic or GPL-1+ Programming Lang: Perl Description : yet another assertion keyword PerlX::Assert is a framework for embedding assertions in Perl code. Under normal circumstances, assertions are not checked; they are optimized away at compile time. . However if, at compile time, any of the following environment variables is true, assertions are checked, and if they fail, throw an exception. . - PERL_STRICT - AUTHOR_TESTING - EXTENDED_TESTING - RELEASE_TESTING . That is, assertions will only typically be checked when the test suite is being run on the authors' machine, or otherwise opted into. Packaging will be maintained in the perl team. Package is needed by libmoops-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7LZzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhWTIP/i6cET9yenLjBdTT/iD8Oj+x WR+6/MaGjM+SSbsoLxOQCvGia9275QXTFQjZs52bSHFnwyMZ+t77raE3Wfm2FarZ E+ojqRYtCD3A+zKUfFAil5TalsElDItYfoQmdOCX7Ve18V2UkWW7g40dExfXmyBn PbKy0tUWXPf3fmjdAcUYpJpbO0v4Y4AFPXno+zH9Lz7Ydk2wadEmTKn4qAHcVkft U+RLM96vFHEgfNW9ZQ7CSgE0kN1bGaXdo8LD4GWuFErMc11mVwC8rA4WC4MGjTOA TDNCaN51yr25jQETZG3pV0kN5nBZN03j6uL7tZAlMet+3GUoEy80Svg4/7lgWjZc xakaJZjtbu5CswS92GvhQx6ovsiwfJwqOesKyoVxCNmKiyJzpF0ASGckdgJNLynC rhiL+HRCVOsLU3XBKMIa7yVi6INC5kF8zC2SRFoV+/VmjY3ScvINT/8aZK7A0UrJ KwlR04HRJWUM/nMU5Q/2VBekxnj1uSuqKNc3g6zt8kg57yE/GYOVIkNAZQ+w5s4F v60xqQwg6pQKW0xBdQnxRRJ5U5lydJqjCWGesA5q+wWFcsdIbYB318OPdxuIXx0W eJuq76dLaENPVVxoyf4Rfezla0Yc07FfIoaxoNpnkhNlOQdRmBpIyH1+PYOh4PUy KPXka9k5DsnMXcDBXTlI =eLet -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224173548.21283.8567.report...@bastian.jones.dk
Re: Should .a library contains non-reallocatable code?
Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
code?"):
> Ian Jackson [150224 15:50]:
> > + gcc -Wall main.c -L. -lbar1 -lbar2
>
> You forgot to change that line as I said to change it.
Ah yes, sorry. I can reproduce the problem that way.
It works if I say
gcc -Wall main.c -L. -lbar1 -lbar2 -lfoo
but not the other way round.
> main.c now uses libfoo1 and libbar2, so in my example I build against
> those. Now you only need a bit of bad luck to use -lbar2 -lfoo1 in
> that order and you get the problem.
Right. I think that the right answer to this, in these cases, is
either to use an explicit symbol export file or to adjust the link
command lines.
Doing it the other way (not including libfoo.a in libbar.so) doesn't
work properly at all for the reasons I've explained.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21740.47632.625206.231...@chiark.greenend.org.uk
Fwd: Bug#778417: RE:Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library
Forgot to add debian-devel back in the loop On 02/24/2015 10:29 AM, Konrad Hinsen wrote: > On Tue, 24 Feb 2015 06:44:54 + Nick Papior Andersen > wrote: > >> In my experience many of the features are quite similar. >> >> However, > netcdf4-python has the advantage of full CDF4 capabilities. >> Konrads > excellent package allows reading a NetCDF4 format in "CLASSIC" >> format, it > also allows writing the CDF3 and CDF3-64 bit files. But it does >> not allow > writing the full NetCDF4 format (I do not know if he has just >> implemented > it, but last time I checked, 2.9.3, he hadn't). > > > > The netCDF interface in ScientificPython has no support for the > functionality specific to netCDF4, for two reasons: (1) I don't need it > and (2) I want to maintain compatibility with netCDF3, which is (or at > least used to be a while ago) much less problematic to install than > netCDF4 with its enormous dependency (HDF5). > > I cannot dedicate much energy to netCDF support because I am migrating > my own software to a direct use of HDF5. I continue to support netCDF > merely for keeping my legacy software usable. I'd be happy to abandon my > netCDF interface in the long run and use netcdf4-python for my legacy > code. However, the last time I checked, this didn't look like a viable > option. > > For the pure Python interface, I could probably replace > Scientific.IO.NetCDF by a thin wrapper on top of netcdf4-python. But for > the C interface, I do not see a solution. I have application code (the > Molecular Modelling Toolkit, http://dirac.cnrs-orleans.fr/MMTK/) that > accesses a single opened netCDF file both from Python code and from C > extension modules. To make this work portably, supporting shared > libraries on all platforms, the C API calls must pass through the C > extension module that is linked to the netCDF library. Last time I > checked, netcdf4-python did not support this. Is there perhaps a > different solution for this scenario? > > Konrad. Thanks very much to Nick and Konrad for your help here. I think there is enough extra functionality in netcdf4-python (and I probably should change the package name to include the 4) to warrant the effort involved in maintaining netcdf4-python in Debian. Checking the reverse dependencies of python-netcdf in Debian, I can see that there are three other packages depending on it: python-tables, python-mmtk and python-dolfin (all in the Debian Science Team). So it would not make sense to remove python-netcdf at this point in time. But as long as there are no namespace clashes, I see no reason to not have both in the archive. Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#779137: ITP: liblexical-accessor-perl -- true private attributes for Moose/Moo/Mouse
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: liblexical-accessor-perl Version : 0.008 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Lexical-Accessor * License : Artistic or GPL-1+ Programming Lang: Perl Description : true private attributes for Moose/Moo/Mouse Lexical::Accessor generates coderefs which can be used as methods to access private attributes for objects. . The private attributes are stored inside-out, and do not add any accessors to the class' namespace, so are completely invisible to any outside code, including any subclasses. This gives your attribute complete privacy: subclasses can define a private (or even public) attribute with the same name as your private one and they will not interfere with each other. Packaging will be maintained in the perl team. Package is needed by libmoops-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7MspXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhRwoQAItQshzYTTB2azXownbN5uyw bKp0J+WxfAYov6ZljWKrN0hGb9tVGIwRTw2NCcgU7j1FTP/zoq87FwIfHRGMAJAO MhLzUgMbVy2bf59SZKgSZ3GGPx3+ENzIocQe8yMYpoZ0EvAFnHJNpNYcNe6p8cNx 5vSc6AlsISUUGKO/hXqEj15u+iMI5U4LKeeUf8YIsaOQIYGqS2naTaRc9dnyPt+X R1mwkk5KVPamG3HixVApJSNYSO5T/q2Wzgg3/HLvNfRZdJy/J3OrTcmArbS2mcn/ cfTlupEbaH6DVmY7HZpHnLm7xE9lZkXCipW7+hUAjtt9ETkz8g1gZRznJFtTHUSu UaaQWntEB3tzu+z7YEhtK5YMpbZSlgv3Jq6O2I87OIAARQegwU1kyuFF6dlzRSUZ xb1tOwR2R2QkUCmP4BCjP4tU99g10BmlkjUC34wmmbRL0INQi7f1crQkHPhXEsHv umd2kUzIc/cyf41kUdS0vgYH4B3X+XamG0Tk9Nw0CUBBq1F0baVsjKb+1aUIsv4Q uMZw+MrznXmqTXssVNPVGw2Q9oussLYk8zYq1NsHC3ck019PAOY1zjWDJtoIArtQ wyLSbMQhNBizYU1WyAoe3tvPTRycvVbpVL0yMVtvXFEB/9EBuqhREsCasY87kscf FhjrnueFWH69JUv+zzGt =OIKq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224190412.14505.19787.report...@bastian.jones.dk
Bug#779138: ITP: libtypes-xsd-lite-perl -- type constraints based on a subset of XML schema datatypes
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libtypes-xsd-lite-perl Version : 0.005 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Types-XSD-Lite * License : Artistic or GPL-1+ Programming Lang: Perl Description : type constraints based on a subset of XML schema datatypes Types::XSD::Lite provides all the type constraints from XML Schema that could be implemented without introducing extra runtime dependencies (above Type::Tiny). That's basically all of the XSD types, except datetime-related ones, and XML-specific ones (QNames, IDRefs, etc). . If you want the full set of XML Schema types, see Types::XSD. Packaging will be maintained in the perl team. Package is needed by libmoops-perl and libtypes-xsd-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7M5zXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhDtoP/2Y8HCGC2Y8QXlW+IK/n1tn2 chPMtNNN4LVf1WV/dVZZ0r9iBAe/ieoIF1L8ih3Nqz0hLn3wUp27Ui7PJomIShfi tQ73+BBWGqBf4H0tojlEL2J9IgJJ1pGFg3B8ZB/B8cnYD2vw6JXoN6DAYoBcpuQs UojPaqBjqz5vsA0illGKyEs/Ordf41a8YHy7KjEM+qnx896DwYkbxCuaV+6vC5vn +Jgh79e770I5FcwfNYtOKJR4DzFvVBn7D61EPof05VnM1T379qCG5JXGsZuKoDM9 komwXvb55Q85CBmZpcnh5n8XuImOpZUy1yA0HOIZG+0Ks61+vJmRZhV01YkWZwHM fCKqrpHox8KMTcwbuzkDE9JfU3jQHy6i+wRyCPg3w0sIRYDmZ9CvzlxfHSSM/yrc Ns2GsfrsLId+jNOob+7Xyd+JOZm6RxIwi4AftfY1gQbeqVRArmCVxng7OyaJNOFN hJGV34rlm/hV8+ib8TbfsDOgV6d0wT436ev8wRdfXcWNbCSvd9sxK2ArGKAYfsKf 2Ycc+rkeXqId+4fwWC7lrx7xlou9Vh8KKHo10ax8vxXFXPLLIhpACafWbq/DvuQI xiJUgAu5VSz8p5LN7bt+D2FhpeTujfXbCyLeYBH9sXEdSZ0VTi2ltphDIEjRXsO+ wnrNsxoibCrTNXdkD8zO =C7iu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224191812.16552.4001.report...@bastian.jones.dk
Bug#779140: ITP: python-zaqarclient -- OpenStack queueing API client
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-zaqarclient Version : 0.1.0 Upstream Author : OpenStack Foundation * URL : http://github.com/openstack/python-zaqarclient * License : Apache-2.0 Programming Lang: Python Description : OpenStack queueing API client Zaqar is a multi-tenant cloud messaging service for web developers. It combines the ideas pioneered by Amazon's SQS product with additional semantics to support event broadcasting. . The service features a fully RESTful API, which developers can use to send messages between various components of their SaaS and mobile applications, by using a variety of communication patterns. Underlying this API is an efficient messaging engine designed with scalability and security in mind. . Other OpenStack components can integrate with Zaqar to surface events to end users and to communicate with guest agents that run in the "over-cloud" layer. Cloud operators can leverage Zaqar to provide equivalents of SQS and SNS to their customers. . By installing python-zaqarclient you get programmatic access to the Zaqar v1.0 API library. Plus, it installs a plugin to python-openstackclient that allows you to perform simple queue operations. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224192823.5851.81969.report...@buzig.gplhost.com
Bug#779141: ITP: libtypes-xsd-perl -- type constraints based on XML schema datatypes
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libtypes-xsd-perl Version : 0.005 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Types-XSD * License : Artistic or GPL-1+ Programming Lang: Perl Description : type constraints based on XML schema datatypes Types::XSD is a type constraint library inspired by XML Schema, and built with Type::Library. It can be used as a type constraint library for Moo, Mouse or Moose, or used completely independently of any OO framework. . This module is an extension of Types::XSD::Lite which has fewer type constraints, but fewer dependencies. Packaging will be maintained in the perl team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7NKwXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEh6DUQAJda9HfsaaGkT+4hsbqprEtP gvUQBK2W5ZfWGegQ4W60bWQlzuZpGSUqO2z74g9YACAOC6IbXmnLQkxOazFFBE9k vSPKwPKDDEwhUE4VaX91cHb3TeAVA3tLMZ3R+CqLblPQz1Cry4NdwcNK5vCUu/xJ ffgoT341Wskiiz079iO9Dz2I9HjtGkn/NpLOTqeV8lOLTpXS6WwmKl5nSLh7/N21 KbGj6P9n0IEaP9Gh91PR7V07FUbxPUxtAyjkHw1/ptlnHj0GpTNPgS6pl4EsIpDy pjJajHAWXkj+G8IC1BenOoGzdAR1AxG4oR4kIYL4dDOjRgmJXfduoe8+zeo/VXl4 msjI4+LL+cMoBsgRPVwujL+oIgzTEfTg6ZR5002krziu87RMGBnVx+w9JsGhlEyl nXfVWSjOTnKM0RWwNEOjVh49oW0gWGovV1PQi1LlU1ZNWGQ2+kB5QSP4ZPLkfH5x 8RKwFDpeWtD8Crx41hA+ZapsYS27nV15klNpo+H7ZQ1BVJzet4av0WqSKp+yR4bD aDoSmagYUaQnUpNw21So52AEaCFpPFwA3FrwecbPLrt3qcVyQIy5aIJF9XTlGCtc gNccK1+Z5vYt9dkU02ItpIgrvSJiT52cMWZ7n47KDTNysSHnzMTqKzrkV5Z8vtAx 3or07psR0eND2l5194Ix =3OsK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224193617.8145.1844.report...@bastian.jones.dk
Bug#779143: ITP: libdatetimex-auto-perl -- use DateTime without needing to call constructors
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libdatetimex-auto-perl Version : 0.008 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/DateTimeX-Auto * License : Artistic or GPL-1+ Programming Lang: Perl Description : use DateTime without needing to call constructors DateTime is awesome, but constructing `DateTime` objects can be annoying. You often need to use one of the formatter modules, or call 'DateTime->new()' with a bunch of values. If you've got a bunch of constant dates in your code, then DateTimeX::Auto makes all this a bit simpler. Packaging will be maintained in the perl team. Package is needed by libtypes-xsd-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7NYwXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhkw4P/2zBaIgHfzd5vjP6T4kLGld7 eN2gMJa1M/5gTB6o3H6Qqkec3b9OHvloSnU01m1nhhmVLK3/rjd18tC0QbLuF6WM 29wgD/9iLrXDfnNGLPyDDG4pprspmaBVxpMi8IKLLOXWrZt4jTFWlc4He7bJdV5q piU3iMluxM1JFXoBeTSaKcaQDAXeGsGu/ComTSWNLno3lrvtn1jc+u0Kwmxhl/bU BE4GN4PPhO+yXeH8KRlFUvSg1VfwDoa4vBgfER0oST0WJmuM0h1t2xPeh1pGk7WP 6/kluqQSu+q9YhTeGVt3aehBBQvx6i6IP9Ck6ZfAvFQR7kOlMX+wvXWgcs/a6f0I YKYGxWzaHDNgzAlz39kOHlSWobx6dp+K0tlvRnRqvW/+Frdp3rCOU5pMEj44vbCw qyGEsMJt4S12QucbZUbitv5aYNItPjKPWSTi1OL33JSAEwvOcECprQ0Viz/heQ/1 niainWk1JKYQZzrqIcDHpElDuqaGPwGlozB6UxS9A78qYbawNjM8Esmq90c1pnmB N9jtOFMq5UyFNhZPbZQhOVZP8OIUEcTeHOlkv+vlPCQOlTUhqcjw0pSGapjH1AjV nuZkETi02asNrMXE5RdtcB1kOOor+8VSWwyXLZmbPfyXIPmSp0exLMOnzwTpR25w eFUMwJTShhVT3xRZFkfV =46rp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224195112.8893.26030.report...@bastian.jones.dk
Bug#779147: ITP: libuniversal-ref-perl -- turns ref() into a multimethod
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libuniversal-ref-perl Version : 0.14 Upstream Author : Joshua ben Jore * URL : https://metacpan.org/release/UNIVERSAL-ref * License : Artistic or GPL-1+ Programming Lang: Perl Description : turns ref() into a multimethod UNIVERSAL::ref changes the behavior of the builtin function ref(). If ref() is called on an object that has requested an overloaded ref, the object's ->ref method will be called and its return value used instead. Packaging will be maintained in the perl team. Package is needed by libtypes-xsd-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7N5YXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhJAgQAKl4tmPLL796QMJTgzT9jP36 or2PQVkSIaoinNwGwdZbZnFVkY9FE/NfgZ0c5JPpAAQeQETaUcFao2xjD62QEQOb 5zNEOHKKRMklHD86wrNKIlmRoGarocBNQhRxWkgRHsrR2PAtJaoNoTVkU2XFo86V aykDtDvtPCxDh7do65BGAjqMAoPstd4i2N84T8g3kdekCb13fNweIrb+FG09/ne+ NvUOc2CAhRuDUfZB4DKeY/G59nIIGF/LFKkhgl57Cpg+dNeucSXTTsQNUkyvzSdk dCdk52QIB3AXRm1ja6RvyfhZeZn3wemWOINcGMONA4UwQc0lXZ/brwgbjvbNKk/K tOVyohx9K3qmknGQny5QsOItDnGIWv0FZ0WE4dLXEbrcKX5lwAZPC4IAmsSgUcFX BbeRIR25TjaO9RV+HNuM1RQeXiOl4twMJZ2+eWgM76kPv3v1S494c8H4golKV04q oUoK2PEl/Xz6t+FTdvw2FGvnQHhdQjwbuXTGVCi9yRpYb+1YFJ+Qp9APx3ss5r/9 G+MOk8MfaA97QGfAt3XEtHBxRjGpyYJCWYHYE3kzkIwpIgDkbg4uTP6MykOgJdze RIw/WmfJca4GgJJcnO4r0cVQhxIvLsqv/0HdxkN6Mfe42ATq7oSzv4Ulzxq6hzfg OE5I5/Em9NybtAYjsF1P =qAC7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224202603.10283.25299.report...@bastian.jones.dk
Bug#779148: ITP: libdatetime-incomplete-perl -- library to handle incomplete datetime like January 5
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libdatetime-incomplete-perl Version : 0.07 Upstream Author : Flavio S. Glock * URL : https://metacpan.org/release/DateTime-Incomplete * License : Artistic or GPL-1+ Programming Lang: Perl Description : library to handle incomplete datetime like January 5 DateTime::Incomplete is a class for representing partial dates and times. . These are actually encountered relatively frequently. For example, a birthday is commonly given as a month and day, without a year. Packaging will be maintained in the perl team. Package is needed by libtypes-xsd-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7OH0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEh07cP/Ak0KtscTW4JQ7UjFiuqpa7d XdmunwPVGPsWsPDHx/SDNm1sTjqF4zcj4n+vVAPx5JrV3RaSOjgloGgsC0quF5wr Nhd/PYYUqnDrJ4EGq81T/K1kpC+EiydX2x+bkjELgDCcwFgoxbLfwJFPBUNOC4Y3 hUJ0vML3UcPbhFmXTH3xs1L2i6Lnv3D0gWFCNviiKTbsDU9LD9Wrj7ZTQ7UJqRFB YY2s4zfHzDgFQDFwhBwm0It/XTdtkGpey503zOrw9zgXsu8JpJqTtRKNQ8M3YpRX L8BnHHGiRaEa6UWw1QTkmcjT5udyKK/sViScmdYPQFlChGj2/UC+fYK/TwMb7FNq CM/R4XARqytXc9Gq3FIX56QPL/5Vgjw0qGlBb6WZKYuLU+7y3ppz4xT9CSJfTDWJ Dnjbg7KDqhM66sjttQkgg/THPGlssTSyG7/3CeUasC3HWugg1jJxL/8ilGjsQ5no Pz2iB7kuqN7yf9q/FgnR+EZeMRTDKFT9epuSLNQvfSUZPajnyevE/Ygb/ksC8Zq5 Ktv9TJ4/QJtqq1NKJTA+A7cCMaEbDllWArnr4B/2zrOUzvgXBP/GaWVCgsBa+Vsl rUptrm5hMGIT+RFcy5GhcW31ZkXgRyIwTHsTHNrne9UJYpd0aaIZbZblf56lXPu7 xLCs4b7Frx0fZgwwZPzH =+25z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224204125.11617.37551.report...@bastian.jones.dk
Bug#779152: ITP: r-cran-rsdmx -- GNU R package for the Statistical Data and Metadata Exchange (SDMX) framework
Package: wnpp Severity: wishlist Owner: "Sébastien Villemot" * Package name: r-cran-rsdmx Version : 0.4.5 Upstream Author : Emmanuel Blondel * URL : http://cran.r-project.org/web/packages/rsdmx/index.html * License : GPL-2+ Programming Lang: R Description : GNU R package for the Statistical Data and Metadata Exchange (SDMX) framework This package provides a set of classes and methods to read data and metadata documents exchanged through the Statistical Data and Metadata Exchange (SDMX) framework, currently focusing on the SDMX XML standard format (SDMX-ML). SDMX is an initiative to foster standards for the exchange of statistical information. It is sponsored by several major providers of statistical information: the Bank for International Settlements, the European Central Bank, Eurostat (the statistical office of the European Union), the International Monetary Fund (IMF), the Organisation for Economic Co-operation and Development (OECD), the United Nations Statistics Division, the United Nations Educational, Scientific and Cultural Organization and the World Bank. The package can therefore be used to download statistical information from the servers of those organizations, and from those of several other institutions. This package will be maintained within the Debian Science Team. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: Digital signature
Re: Should .a library contains non-reallocatable code?
Hi, Am 24.02.2015 um 11:01 schrieb Alastair McKinstry: > I agree with this; are there any cases where only a static library _is_ > provided, and if so why? why not provide a .so? In libvxi-dev I provide a -fPIC .a library only, mainly for size reasons (the library consists of RPC proxy/stub code for the VXI-11 protocol, and is completely generated with rpcgen). Simon signature.asc Description: OpenPGP digital signature
Re: Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library
> The netcdf4-python package is the only one described as having > implemented most of the newest features of NetCDF-4. It was actually > modelled on the Scientific.IO.NetCDF module API. netCDF4 module is required by basemap, so it'll be nice to have it in the archive. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxz1tef7h3pza3mozujn46khyzqbcsmkhzkkfpthnr+...@mail.gmail.com
Bug#779157: ITP: libmoosex-mungehas-perl -- munge your "has" (works with Moo, Moose and Mouse)
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libmoosex-mungehas-perl Version : 0.007 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/MooseX-MungeHas * License : Artistic or GPL-1+ Programming Lang: Perl Description : munge your "has" (works with Moo, Moose and Mouse) MooseX::MungeHas alters the behaviour of the attributes of your Moo, Moose or Mouse based class. It manages to support all three because it doesn't attempt to do anything smart with metathingies; it simply installs a wrapper for 'has' that munges the attribute specification hash before passing it on to the original 'has' function. Packaging will be maintained in the perl team. Package is needed by libmoops-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJU7PxvXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhADIP/iUGevxDRC70k3azNT5m45d6 P3197pewNDy4ptKOjQmyYtr6fXNifrdHvdUBuvQhXvwHNpHM8cS4mxC6M64IgXSu 8prykTlnTqGH3zIBLh7tbzCe+zURj/b1+712255MfzNH2TcYs1c/BYqzBaeDvn0x mdj6TwO7zEMo/FFyBXttzBR0SGsxWJKXvJ5qxb8mxQ45PMfNubuhaXZoThANbx96 rMqP8mEFzzZPq9cYl5fik5FKxMgslCVDLHamcsRHYWju9l3RO0MaWesVBDiAUKSu dHi01siPK+/CF3Cp1b6unC2WWD4yK3aGiBGYBZnEkY/YFhaLKCUyeiPsNLnpUAz+ dc0YvlerGF0luzj7r6X3Y/EDFLXevCdPr3XO2sLqPfaGrCyKn38L4CbdcqtjmglP ZcMxLe0//HDYK92vEevE3qb8wfNdafu6r5C8L4g6cAUWsGI26sDuVpfy4LoF1o1e QWj6ct0Dpfx3foIuZVh0iPYTuaDvt1RSU6dRJJb0ZGxdLNMolDmnoyvj7HuTUIUu g+JBZVlJaW7dsIc3MOW9EjALfsn3g1nVsThkrgKaan77NNTPeOyTfJRtFz0pUvNi I2eN5OtRa4zrixVLqz0kCC81Z/lUTaB32cNX0r1tOdmBx/uxzV5XTXexK/JjjGvD 1WRuypyTXIgC3xrhyiBX =qKNA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224223423.23976.62574.report...@bastian.jones.dk
