On Mon, Sep 26, 2016 at 09:55:21AM +0200, Adam Borowski wrote:
> > >This "must" policy requirement has long gone past "pointless" deep into the
> > >"actively harmful" land. It is universally ignored, and I'd advise you to
> > >do so too.
> >
> > what about changing the policy? I admit I never ca
On Mon, Sep 26, 2016 at 07:31:37AM +, Gianfranco Costamagna wrote:
> >This "must" policy requirement has long gone past "pointless" deep into the
> >"actively harmful" land. It is universally ignored, and I'd advise you to
> >do so too.
>
> what about changing the policy? I admit I never care
Hi Adam,
>This "must" policy requirement has long gone past "pointless" deep into the
>"actively harmful" land. It is universally ignored, and I'd advise you to
>do so too.
what about changing the policy? I admit I never cared too much about
such priorities, and I would like it to be relaxed/
On Sun, Sep 25, 2016 at 11:50:19PM +0200, Tim Dengel wrote:
> I was looking at debcheck[0] and saw that my package (with "optional"
> priority) depends on a package with "extra" priority (libpeas-1.0-0),
> which is not allowed by policy.
> After re-reading the policy chapter about priorities[1] it
Hello Tim,
When Debian had less than 1000 packages it meant something to talk
about "specialised requirements", and divide packages between extra and
optional based on that, but that division has broken down now we have
50,000 packages. As I understand it, the current consensus is that
the differ
On Tue, Jun 18, 2013 at 9:42 PM, Jeroen Massar wrote:
> Please see:
> http://clang.debian.net/
Also:
http://buildd-clang.debian.net/package.php
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe".
On 2013-06-18 12:05 , Richi Lists wrote:
> Hi everybody,
>
> gcc is the default compiler for debian, and all the libraries in the
> repository are compiled with gcc.
> clang is also in the repository. But if I want to compile anything other
> than the simplest toy program, I also need libraries. M
On 18 June 2013 11:05, Richi Lists wrote:
> Hi everybody,
>
> gcc is the default compiler for debian, and all the libraries in the
> repository are compiled with gcc.
> clang is also in the repository. But if I want to compile anything other
> than the simplest toy program, I also need libraries.
On Mon, Dec 27, 2004 at 08:17:19PM +0200, [EMAIL PROTECTED] wrote:
> > What package? Is it itself a library? Do other packages actually use
> > its library?
> No
Are there multiple executables? If not, then you might as well just
use static linking. Maybe note your rationale in README.Debian.
What package? Is it itself a library? Do other packages actually use
its library?
Justin
On Mon, Dec 27, 2004 at 08:06:07PM +0200, [EMAIL PROTECTED] wrote:
> Hello
>
> >>> On Mon, Dec 27, 2004 at 12:36:44AM +0200, [EMAIL PROTECTED] wrote:
> >>> I was looking into packaging a software that has
Hello
>>> On Mon, Dec 27, 2004 at 12:36:44AM +0200, [EMAIL PROTECTED] wrote:
>>> I was looking into packaging a software that has a soname:
>>> SONAME libyate.so
>>> but no version, and also upstream doesn't want any version on this
> library.
>>> During dh_shlibdeps i get :
>>> dpkg-shlibd
> On Mon, Dec 27, 2004 at 12:36:44AM +0200, [EMAIL PROTECTED] wrote:
>> Hello
>>
>> I was looking into packaging a software that has a soname:
>> SONAME libyate.so
>> but no version, and also upstream doesn't want any version on this
library.
>> During dh_shlibdeps i get :
>> dpkg-shlibdeps:
On Mon, Dec 27, 2004 at 12:36:44AM +0200, [EMAIL PROTECTED] wrote:
> Hello
>
> I was looking into packaging a software that has a soname:
> SONAME libyate.so
> but no version, and also upstream doesn't want any version on this library.
> During dh_shlibdeps i get :
> dpkg-shlibdeps: warning
Marcin Owsiany <[EMAIL PROTECTED]> immo vero scripsit:
> I read somewhere that code compiled with -fPIC is a little larger and
> slower. Is this the only reson for that policy requirement? If not,
> please give me for some information/pointers on that requirement.
I think that is mostly so.
With
Marcin Owsiany <[EMAIL PROTECTED]> immo vero scripsit:
> I read somewhere that code compiled with -fPIC is a little larger and
> slower. Is this the only reson for that policy requirement? If not,
> please give me for some information/pointers on that requirement.
I think that is mostly so.
Wit
On Mon, 9 Oct 2000, Yves Arrouye wrote:
[...]
> so I guess all the compilers they support also handle -o w/ -c nicely.
I see. Have you reported the static initializer thing to the libtool
maintainers?
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fin
> > I don't use libtool because libtool has problems when gcc
> is used with the
> > platform's ld on Solaris for example: static initializers
> aren't called.
>
> Does the Solaris runtime linker support that?
It does for CC output, not for gcc. That's the problem. libtool should
recognize that
> There are some strange commercial compilers out there that have this
> problem. Since this is the upstream package, not the Debian one, you
> cannot assume a certain compiler. Also, two suffixes don't
> work with BSD
> make.
The library does require gmake :) I guess I could use .ao or whatever.
On Mon, 9 Oct 2000, Yves Arrouye wrote:
[.static.o]
> Do you mean that non-gcc compilers won't obey -o at the same time as -c?
Possibly.
> I don't use libtool because libtool has problems when gcc is used with the
> platform's ld on Solaris for example: static initializers aren't called.
Does
On Mon, 9 Oct 2000, Antti-Juhani Kaijanaho wrote:
> > .static.o is bad because it is not portable to other compilers.
> Um, what compilers do not allow the user to specify the input/output
> file name?
There are some strange commercial compilers out there that have this
problem. Since this is th
> > In any case, since I'm one of the upstream maintainers of
> the package I'm
> > packaging, I just changed it so that it will compile both
> .o and .static.o
> > w/ different flags. But I'm still interested in clarifying
> your answer.
>
> .static.o is bad because it is not portable to other
On 20001009T214211+0200, Simon Richter wrote:
> .static.o is bad because it is not portable to other compilers.
Um, what compilers do not allow the user to specify the input/output
file name?
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
On Mon, 9 Oct 2000, Yves Arrouye wrote:
[Compiling a library, --enable-shared and --enable-static]
> "All libraries must have a shared version in the lib package and a static
> version in the lib-dev package. The shared version must be compiled with
> -fPIC, and the static version must not be. In
> > Any well-known trick to compile the .c twice w/o changing
> too much of the
> > original package? For example, does it make sense to
> configure in two
> > different locations, once with --enable-shared and once with
> > --enable-static, for example? Do we have an example of a
> small librar
On Mon, 9 Oct 2000, Yves Arrouye wrote:
> Any well-known trick to compile the .c twice w/o changing too much of the
> original package? For example, does it make sense to configure in two
> different locations, once with --enable-shared and once with
> --enable-static, for example? Do we have an e
On Mon, 9 Oct 2000, Yves Arrouye wrote:
[...]
> so I guess all the compilers they support also handle -o w/ -c nicely.
I see. Have you reported the static initializer thing to the libtool
maintainers?
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fi
> > I don't use libtool because libtool has problems when gcc
> is used with the
> > platform's ld on Solaris for example: static initializers
> aren't called.
>
> Does the Solaris runtime linker support that?
It does for CC output, not for gcc. That's the problem. libtool should
recognize tha
> There are some strange commercial compilers out there that have this
> problem. Since this is the upstream package, not the Debian one, you
> cannot assume a certain compiler. Also, two suffixes don't
> work with BSD
> make.
The library does require gmake :) I guess I could use .ao or whatever
> Alexander Kotelnikov <[EMAIL PROTECTED]> wrote:
> >But I want to know where it is written about what should go to -dev
> >package, and what to the library one.
>
> /usr/share/doc/debian-policy/policy.html/ch4.html#s4.3
> /usr/share/doc/packaging-manual/packaging.html/ch-sharedlibs.html
Any
On Mon, 9 Oct 2000, Yves Arrouye wrote:
[.static.o]
> Do you mean that non-gcc compilers won't obey -o at the same time as -c?
Possibly.
> I don't use libtool because libtool has problems when gcc is used with the
> platform's ld on Solaris for example: static initializers aren't called.
Does
On Mon, 9 Oct 2000, Antti-Juhani Kaijanaho wrote:
> > .static.o is bad because it is not portable to other compilers.
> Um, what compilers do not allow the user to specify the input/output
> file name?
There are some strange commercial compilers out there that have this
problem. Since this is t
> > In any case, since I'm one of the upstream maintainers of
> the package I'm
> > packaging, I just changed it so that it will compile both
> .o and .static.o
> > w/ different flags. But I'm still interested in clarifying
> your answer.
>
> .static.o is bad because it is not portable to othe
On 20001009T214211+0200, Simon Richter wrote:
> .static.o is bad because it is not portable to other compilers.
Um, what compilers do not allow the user to specify the input/output
file name?
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
--
To UNSUBSCRIBE,
On Mon, 9 Oct 2000, Yves Arrouye wrote:
[Compiling a library, --enable-shared and --enable-static]
> "All libraries must have a shared version in the lib package and a static
> version in the lib-dev package. The shared version must be compiled with
> -fPIC, and the static version must not be. I
> > Any well-known trick to compile the .c twice w/o changing
> too much of the
> > original package? For example, does it make sense to
> configure in two
> > different locations, once with --enable-shared and once with
> > --enable-static, for example? Do we have an example of a
> small libra
On Mon, 9 Oct 2000, Yves Arrouye wrote:
> Any well-known trick to compile the .c twice w/o changing too much of the
> original package? For example, does it make sense to configure in two
> different locations, once with --enable-shared and once with
> --enable-static, for example? Do we have an
> Alexander Kotelnikov <[EMAIL PROTECTED]> wrote:
> >But I want to know where it is written about what should go to -dev
> >package, and what to the library one.
>
> /usr/share/doc/debian-policy/policy.html/ch4.html#s4.3
> /usr/share/doc/packaging-manual/packaging.html/ch-sharedlibs.html
Any
Alexander Kotelnikov <[EMAIL PROTECTED]> wrote:
>But I want to know where it is written about what should go to -dev
>package, and what to the library one.
/usr/share/doc/debian-policy/policy.html/ch4.html#s4.3
/usr/share/doc/packaging-manual/packaging.html/ch-sharedlibs.html
--
Colin Watson
On Sun, Oct 08, 2000 at 11:49:09PM +0200, Christian Marillat wrote:
>
> AK> I have not packaged libraries yet, and I'm going to do. What is the
> easyest
> AK> way to start?
>
> Take a diff file from a lib package (maybe libgdk-pixbuf2) and see how this
> work.
of course I did so. But I want
Alexander Kotelnikov <[EMAIL PROTECTED]> wrote:
>But I want to know where it is written about what should go to -dev
>package, and what to the library one.
/usr/share/doc/debian-policy/policy.html/ch4.html#s4.3
/usr/share/doc/packaging-manual/packaging.html/ch-sharedlibs.html
--
Colin Watso
On Sun, Oct 08, 2000 at 11:49:09PM +0200, Christian Marillat wrote:
>
> AK> I have not packaged libraries yet, and I'm going to do. What is the easyest
> AK> way to start?
>
> Take a diff file from a lib package (maybe libgdk-pixbuf2) and see how this
> work.
of course I did so. But I want to
"AK" == Alexander Kotelnikov <[EMAIL PROTECTED]> writes:
AK> Hi.
Hi,
AK> I have not packaged libraries yet, and I'm going to do. What is the easyest
AK> way to start?
Take a diff file from a lib package (maybe libgdk-pixbuf2) and see how this
work.
Christian
"AK" == Alexander Kotelnikov <[EMAIL PROTECTED]> writes:
AK> Hi.
Hi,
AK> I have not packaged libraries yet, and I'm going to do. What is the easyest
AK> way to start?
Take a diff file from a lib package (maybe libgdk-pixbuf2) and see how this
work.
Christian
--
To UNSUBSCRIBE, emai
43 matches
Mail list logo
