Simon Richter writes:
> With my embedded hat on, it would be nice if there was an easy way to
> drop this extra dependency, as it means a lot of essentially dead code
> loaded on systems that don't use systemd.
Like others, I'd be happy to support that as a build profile or build
option or somet
On Feb 18, Simon Richter wrote:
> With my embedded hat on, it would be nice if there was an easy way to
> drop this extra dependency, as it means a lot of essentially dead code
> loaded on systems that don't use systemd.
http://anonscm.debian.org/cgit/users/md/libsystemd-dummy.git/
--
ciao,
Mar
Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta
* Package name: statsite
Version : 0.7.0
Upstream Author : Armon Dadgar
* URL : http://armon.github.io/statsite/
* License : BSD-3-clause
Programming Lang: C
Description : metrics aggregation serv
On Wed, Feb 18, 2015 at 07:21:44PM +0100, Simon Richter wrote:
> > If the argument is that it should be opened with dlopen at runtime, I'm
> > quite confident that there are *many* people on debian-devel who have
> > worked with shared libraries and can spell out many reasons why that's a
> > horri
Hello, I am the maintainer of python-scientific
> How does this differ from the existing python-netcdf package?
I CC the upstream autor of python-scientific, maybe he can clarify this point
but before a question to the netcdf4-python guyes.
Does netcdf4-python will support python3 ?
@Konrad do
As a transitional measure, you could patch lcmaps so it searches
/usr/lib/lcmaps with lower priority than ${libdir}/lcmaps, so that these
older plugin packages continue to work for a couple of years.
openscenegraph does that (currently openscenegraph-plugin-citygml-shared
and libopenscenegraph's
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-pex
Version : 0.8.6
Upstream Author : Brian Wickman
* URL : https://pypi.python.org/pypi/pex
* License : Apache-2.0
Programming Lang:
Hi,
Am 18.02.2015 um 04:32 schrieb Russ Allbery:
> If the argument is that it should be opened with dlopen at runtime, I'm
> quite confident that there are *many* people on debian-devel who have
> worked with shared libraries and can spell out many reasons why that's a
> horrible idea.
Correct.
Hi,
First, thanks for working on this subject. I know that I will personally
benefit from it to experiment a few ideas and move some project of mine
(that I host on my personal server for now) there to be able to develop
it further.
On Wed, Feb 18, 2015 at 08:33:20AM +0100, Lucas Nussbaum
wrote
Hi,
Am 18.02.2015 um 11:49 schrieb Dennis van Dok:
> It's harder to reversely state that the new framework conflicts with
> older plugin packages: they would all have to be listed in the control
> file, and then only the known ones could be listed (it's not
> inconceivable other parties made thei
On February 18, 2015 7:54:00 AM EST, Luke Kenneth Casson Leighton
wrote:
>On Wed, Feb 18, 2015 at 12:27 AM, Steve Langasek
>wrote:
>> On Tue, Feb 17, 2015 at 11:52:21PM +, Luke Kenneth Casson
>Leighton wrote:
>>> On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett
> wrote:
>>
>>> > So, please go
On 2015-02-18 13:54, Luke Kenneth Casson Leighton wrote:
> that's right - i haven't. because (a) i have complete confidence in
> your technical abilities, as a group. i wouldn't use debian
> otherwise! :) and (b) this isn't a technical issue, it's a strategic
> one.
No, it's not. The issue is
On Wed, Feb 18, 2015 at 12:27 AM, Steve Langasek wrote:
> On Tue, Feb 17, 2015 at 11:52:21PM +, Luke Kenneth Casson Leighton wrote:
>> On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett
>> wrote:
>
>> > So, please go educate yourself on what libsystemd0 actually does,
>
>> i know what it does,
On Wed, Feb 18, 2015, at 04:32, Russ Allbery wrote:
> (Removing every package whose name contains the string "systemd" is not a
> practical, useful purpose. It's just silly.)
Perhaps we could rename the library (and the package) to:
libthis-is-not-the-library-you-are-looking-for.so.0
I guess th
On 18/02/15 10:49, Dennis van Dok wrote:
> I'm maintaining a framework package (lcmaps) with several plugins that
> traditionally install under /usr/lib/lcmaps. With the move to debhelper
> 9, the default for dh_auto_configure is to pass
> --libdir=/usr/lib/x86_64-linux-gnu which changes the plugin
On Wed, 18 Feb 2015 11:49:50 +0100
Dennis van Dok wrote:
> Hi,
>
> I'm maintaining a framework package (lcmaps) with several plugins that
> traditionally install under /usr/lib/lcmaps. With the move to
> debhelper 9, the default for dh_auto_configure is to pass
> --libdir=/usr/lib/x86_64-linux-g
Hi,
I'm maintaining a framework package (lcmaps) with several plugins that
traditionally install under /usr/lib/lcmaps. With the move to debhelper
9, the default for dh_auto_configure is to pass
--libdir=/usr/lib/x86_64-linux-gnu which changes the plugin path.
This is not a big deal except that t
17 matches
Mail list logo
