On Tue, 2016-11-01 at 22:54 +0200, Adrian Bunk wrote:
> I do not see any reason for waiting instead of sending the binNMU
> request right now.
I didn't see any movement on the dpkg front so I went ahead and did so:
#843139.
Thanks,
Ian.
On Tue, Nov 01, 2016 at 10:54:33PM +0200, Adrian Bunk wrote:
> LUA
The language is named "Lua", which means "moon" in Portuguese.
https://www.lua.org/about.html#name
LUA is an acronym for "Lua Uppercase Accident" ;-).
Peter
On Mon, Oct 31, 2016 at 03:23:51PM +0100, Bálint Réczey wrote:
> Hi Ian,
>
> 2016-10-31 14:19 GMT+01:00 Ian Campbell :
> > On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> >> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> >> > If possible I'd also prefer a solution which fixed qcontrol-stati
Hi Ian,
2016-10-31 14:19 GMT+01:00 Ian Campbell :
> On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
>> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
>> > If possible I'd also prefer a solution which fixed qcontrol-static
>> > without opting out for the normal dynamic/non-udeb binary.
>>
>> I r
On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> > If possible I'd also prefer a solution which fixed qcontrol-static
> > without opting out for the normal dynamic/non-udeb binary.
>
> I ran the build tests on amd64, this is why I have not caugh
2016-10-31 12:52 GMT+01:00 Henrique de Moraes Holschuh :
> On Mon, 31 Oct 2016, Ian Campbell wrote:
>> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> > ?
>>
>> Thanks, but that doesn't appear to help, I think the issue is to do
>> w
On Mon, 31 Oct 2016, Ian Campbell wrote:
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> > ?
>
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening setting
Hi Ian,
2016-10-31 10:38 GMT+01:00 Ian Campbell :
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> ?
>
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening
On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> ?
Thanks, but that doesn't appear to help, I think the issue is to do
with the changed default in gcc rather than the hardening settings
injected into the build by dpkg-buildpackage/dpkg-b
export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
?
2016-10-31 10:21 GMT+01:00 Ian Campbell :
> Hi,
>
> I maintain qcontrol[0] which builds on armel and armhf only (it's a
> tool specific to certain NAS machines). It links a version against
> liblua statically for use in a udeb (the resulting
* Jonas Smedegaard (d...@jones.dk) wrote:
> Quoting Eric Dorland (2015-05-19 21:44:50)
> > What's the current thinking on embedded libraries in source code? One
> > of my packages has an embedded (and slightly modified) version of
> > libevent that it links statically. It doesn't seem like Built-
Quoting Eric Dorland (2015-05-19 21:44:50)
> What's the current thinking on embedded libraries in source code? One
> of my packages has an embedded (and slightly modified) version of
> libevent that it links statically. It doesn't seem like Built-Using is
> the right thing to use in this situati
On 19/05/2015 07:43, Bastien Roucaries wrote:
>
> Le 19 mai 2015 03:30:30 GMT+02:00, Paul Wise a écrit :
>> Hi all,
>>
>> I have prepared a short document on static linking and Debian, with the
>> aim to reduce existing static linking, document unavoidable static
>> linking and find ways to mitig
* Paul Wise (p...@debian.org) wrote:
> Hi all,
>
> I have prepared a short document on static linking and Debian, with the
> aim to reduce existing static linking, document unavoidable static
> linking and find ways to mitigate unavoidable static linking.
>
> https://wiki.debian.org/StaticLinking
Hi!
On Tue, 2015-05-19 at 18:21:40 +0100, Rebecca N. Palmer wrote:
> What's the preferred way to set Built-Using:
> http://sources.debian.net/src/chromium-browser/42.0.2311.135-2/debian/control/?hl=82#L82
This one is wrong in two ways, it's missing the exact version, and the
field does not belon
What's the preferred way to set Built-Using:
http://sources.debian.net/src/chromium-browser/42.0.2311.135-2/debian/control/?hl=82#L82
,
http://sources.debian.net/src/binutils/2.25-7/debian/rules/?hl=998#L998
, or something else?
The existing statically-linked-binary /
shared-lib-without-depe
❦ 19 mai 2015 09:30 +0800, Paul Wise :
> I have prepared a short document on static linking and Debian, with the
> aim to reduce existing static linking, document unavoidable static
> linking and find ways to mitigate unavoidable static linking.
>
> https://wiki.debian.org/StaticLinking
I have
Le 19 mai 2015 03:30:30 GMT+02:00, Paul Wise a écrit :
>Hi all,
>
>I have prepared a short document on static linking and Debian, with the
>aim to reduce existing static linking, document unavoidable static
>linking and find ways to mitigate unavoidable static linking.
>
>https://wiki.debian.org
reassign 757941 src:glibc
affects 757941 busybox-static
thanks
On Mon, Oct 06, 2014 at 07:32:17PM -0700, Russ Allbery wrote:
> Paul Wise writes:
> > On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:
> >> But with jessie, for one, all network name resolution (gethostby* etc
> >> APIs) don't
Paul Wise writes:
> On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:
>> But with jessie, for one, all network name resolution (gethostby* etc
>> APIs) don't work anymore, because glibc does not provide them instatic
>> libraries. So usual network utilities in busybox does not anymore,
>>
On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:
> But with jessie, for one, all network name resolution (gethostby* etc APIs)
> don't work anymore, because glibc does not provide them instatic libraries.
> So usual network utilities in busybox does not anymore, they just return
> `host not
* Russ Allbery schrieb:
> pkg-config is much superior to libtool, since libtool includes all the
> libraries on dynamic links as well, which creates unwanted shared library
> dependencies and causes other problems. Because of that, the trend in
> Debian is to empty that information from libtool
]] Simon McVittie
| On Sat, 20 Nov 2010 at 21:58:56 +0100, Tollef Fog Heen wrote:
| > | Upstreams are only meant to change the .pc filename when they make an
| > | incompatible change to the API
| >
| > This seems to be the trend, but there's nothing in pkg-config's policies
| > or best practice
Dmitry Katsubo writes:
> Russ, thank you for comments. To answer your question I quote only one
> important section from the document I've referred:
> === quote ===
> 3.2.4 pkg-config File
> Many libraries deliver a .pc file for use by the pkg-config helper
> utility, which aids other libraries
On Mon, 22 Nov 2010 at 16:18:52 +0100, Dmitry Katsubo wrote:
> On 19.11.2010 22:51, Russ Allbery wrote:
> > Dmitry Katsubo writes:
> >> * Some libraries (e.g.) do not follow the agreement for .NET/CLI
> >> (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-pkg-config-file)
> >> whic
On 19.11.2010 22:51, Russ Allbery wrote:
> Dmitry Katsubo writes:
>
>> The first problem I faced is that it is difficult to explore what should
>> be the list of libraries for static linking (as I have to provide the
>> list of libraries which are direct dependencies as well as indirect). I
>> kn
On Sat, 20 Nov 2010 at 21:58:56 +0100, Tollef Fog Heen wrote:
> | Upstreams are only meant to change the .pc filename when they make an
> | incompatible change to the API
>
> This seems to be the trend, but there's nothing in pkg-config's policies
> or best practices guide that specifies this. I'
]] Simon McVittie
| Upstreams are only meant to change the .pc filename when they make an
| incompatible change to the API - if XFCE 4 is still compatible with the API
| (but not necessarily the ABI) of the earliest version that had xfprint-1.0.pc,
| then it shouldn't be renamed.
This seems to b
On Fri, 19 Nov 2010 at 22:30:09 +0100, Dmitry Katsubo wrote:
> * Some libraries (e.g. GraphicsMagick) does not provide the list of
> libraries for statis linking via .pc (compare 'pkg-config --static
> --libs GraphicsMagick++' and 'GraphicsMagick++-config --libs'). Should
> it be fired as a bug for
Dmitry Katsubo writes:
> The first problem I faced is that it is difficult to explore what should
> be the list of libraries for static linking (as I have to provide the
> list of libraries which are direct dependencies as well as indirect). I
> know this problem is solved with libtool (which con
On Fri, Dec 15, 2006 at 02:23:26PM +, Alastair McKinstry wrote:
> It looks like providing .la and pkg-config files to explain how to build
> it statically
> looks like necessary. newt doesn't ordinarily use libtool, so I need to
> generate a .la
> file and include it in the libnewt-dev. Current
Goswin von Brederlow wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
>
>
>> On Dec 14, Alastair McKinstry <[EMAIL PROTECTED]> wrote:
>>
>>
>>> So where do people think the bug lies?
>>> - Should libdl be compiled into libnewt.a ?
>>>
>> Yes.
>>
>
> Is there even a libdl.a?
>
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 14, Alastair McKinstry <[EMAIL PROTECTED]> wrote:
>
>> So where do people think the bug lies?
>> - Should libdl be compiled into libnewt.a ?
> Yes.
Is there even a libdl.a?
And what if I have libfoo.a libbar.a libblub.a all using dlopen?
Should
Le jeudi 14 décembre 2006 à 11:56 +, Alastair McKinstry a écrit :
> partimage depends on libnewt, which I maintain. libnewt-dev ships libnewt.a.
> libnewt opportunistically links to libfribidi if it is present; it uses
> dlopen() to do so.
>
> However the partimage build fails when done with '
On Dec 14, Alastair McKinstry <[EMAIL PROTECTED]> wrote:
> So where do people think the bug lies?
> - Should libdl be compiled into libnewt.a ?
Yes.
> - Should the static version of libnewt be built differently so as to
> not call dlopen()?
Maybe.
> - if so, any recommendations on how?
Rem
35 matches
Mail list logo
