Daniel P. Berrange wrote:
> Ulrich hasn't worked for Red Hat for many many many years.
As far as I know, he works for Goldman Sachs now.
He is also no longer "the glibc maintainer". There are now a whole bunch of
people responsible:
https://sourceware.org/glibc/wiki/MAINTAINERS
Kevin
On 20 March 2017 at 13:25, Daniel P. Berrange wrote:
> > Please don't try to convince me. Rally forget about me. I'm probably one
> of
> > the smallest beatles here.
> > Just please sit down with him and try to convince *him* that there is no
> at
> > all risk here.
>
> I'm
On Mon, Mar 20, 2017 at 01:16:56PM +, Tomasz Kłoczko wrote:
> On 20 March 2017 at 09:50, Daniel P. Berrange wrote:
>
> > > I've already described this multiple times trying to use different
> > > descriptions/analogies about well known *glibc NSS ABI issue*.
> > > You
On 20 March 2017 at 09:50, Daniel P. Berrange wrote:
> > I've already described this multiple times trying to use different
> > descriptions/analogies about well known *glibc NSS ABI issue*.
> > You cannot fix this issue in *any libc implementation which is using
> NSS*.
>
>
On Sun, Mar 19, 2017 at 01:38:31AM +, Tomasz Kłoczko wrote:
> On 18 March 2017 at 22:26, Richard W.M. Jones wrote:
>
> > I read through the whole thread and I still don't understand why
> > packaging glibc-static in Fedora is not a good thing.
> >
>
> I've already
On 18 March 2017 at 22:26, Richard W.M. Jones wrote:
> I read through the whole thread and I still don't understand why
> packaging glibc-static in Fedora is not a good thing.
>
I've already described this multiple times trying to use different
descriptions/analogies about
On 18 March 2017 at 06:21, Nico Kadel-Garcia wrote:
[..]
> > So here is kind contradiction because my past experience that such
> binaries
> > are used so long (+6 years) that it causes silent issues with conflicts
> on
> > kernel<->user space and sooner or later initial
On Sat, Mar 18, 2017 at 10:25:38PM +, Tomasz Kłoczko wrote:
> On 18 March 2017 at 19:58, Richard W.M. Jones wrote:
>
> > Although I'm nit-picking, this isn't entirely true.
> >
> > OCaml doesn't statically link C code, as you can see from:
> >
> > $ ldd
On Sat, Mar 18, 2017 at 10:21:06PM +, Tomasz Kłoczko wrote:
> On 18 March 2017 at 21:40, Richard W.M. Jones wrote:
>
> > > Did you try to link it against uClibc?
> >
> > Yes, supermin supports several alternate libc.
>
>
> So it is -1 from critical glibc-static using
On 18 March 2017 at 19:58, Richard W.M. Jones wrote:
> Although I'm nit-picking, this isn't entirely true.
>
> OCaml doesn't statically link C code, as you can see from:
>
> $ ldd /usr/bin/virt-builder
>
[..]
So am I right that it looks like Ocaml can be removed as well from
On 18 March 2017 at 21:40, Richard W.M. Jones wrote:
> > Did you try to link it against uClibc?
>
> Yes, supermin supports several alternate libc.
So it is -1 from critical glibc-static using projects :)
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH
On Sat, Mar 18, 2017 at 09:11:56PM +, Tomasz Kłoczko wrote:
> On 18 March 2017 at 20:01, Richard W.M. Jones wrote:
>
> > It would break supermin which compiles a tiny statically linked init.
> >
> > Actually as of today we are using dietlibc instead of glibc-static on
> >
On 18 March 2017 at 20:01, Richard W.M. Jones wrote:
> It would break supermin which compiles a tiny statically linked init.
>
> Actually as of today we are using dietlibc instead of glibc-static on
> every architecture that Fedora supports resulting in massive savings
> in
On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
> This may still be a useful consideration for Fedora itself. Would we
> alienate anyone if Fedora removed glibc-static?
It would break supermin which compiles a tiny statically linked init.
Actually as of today we are using dietlibc
On Wed, Mar 15, 2017 at 05:08:50PM +, Daniel P. Berrange wrote:
> There are entire non-C language toolchains in
> Fedora that are based on static compilation - eg OCaml
Although I'm nit-picking, this isn't entirely true.
OCaml doesn't statically link C code, as you can see from:
$ ldd
On Thu, Mar 16, 2017 at 6:58 AM, Tomasz Kłoczko
wrote:
>
> On 16 March 2017 at 04:50, Nico Kadel-Garcia wrote:
> [..]
>>
>> > And one more clarification: remove static libraries from glibc distro
>> > packages does not blocks static linking.
>> > It
Tomasz Kłoczko wrote:
> [mode=kidding]
> So stop provide glibc-static and redirect those guys to /dev/tree in
> uClibc garden may be kind of "solution" how to block (easy way) violating
> LGPL ..
> [/mode]
I'm not kidding, and uClibc is also under the LGPL.
>> ucLibc has the same issue, by the
On 16 March 2017 at 16:17, Tomasz Kłoczko wrote:
> BTW: during checking that current Fedora glibc static binaries are not
> ready even solve those well known scenarios I found that already glibc spec
> file is generating glibs-nss-devel subpackage.
>
> S rpm -qpl
On Fri, 17 Mar 2017 15:40:34 +0100, Tomasz Kłoczko wrote:
> (Resending below as looks like I've replied only to Jan)
also resending
On Fri, 17 Mar 2017 06:18:56 +0100, Tomasz Kłoczko wrote:
> I saw already such tweaks in many Fedora specs %check sections.
> IMO such %ifing inside or around
(Resending below as looks like I've replied only to Jan)
On 16 March 2017 at 18:01, Jan Kratochvil wrote:
> On Thu, 16 Mar 2017 01:32:06 +0100, Tomasz Kłoczko wrote:
> > OK here is full list of spec files which have glibc-static in
> BuildRequires:
> >
> >
On 16/03/17 23:24 +0100, Kevin Kofler wrote:
Jonathan Wakely wrote:
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically link their applications would be a
showstopper for some, and
On 16 March 2017 at 22:24, Kevin Kofler wrote:
> The thing is, proprietary applications statically linking to glibc are
> highly likely to be in violation of the LGPL. Or how many proprietary
> applications do you know that distribute their object files (and/or their
>
On Fri, 17 Mar 2017 06:18:56 +0100, Tomasz Kłoczko wrote:
> I saw already such tweaks in many Fedora specs %check sections.
> IMO such %ifing inside or around %check is incorrect/not needed and can be
> removed.
> Why? Because:
> - all possible to use package tests should be by default enabled
> -
Tomasz Kłoczko wrote:
> BuildRequires:qt5-qtbase*-static*
There are a few small libraries that Qt upstream ships only as static,
because they are not covered by the binary compatibility guarantees:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase.spec#n874
The main
Jonathan Wakely wrote:
> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.
>
> Being unable to statically link their applications would be a
> showstopper for some, and would cause them to move to a
Tomasz Kłoczko wrote:
> Long time ago I've been able to gain minimize number of dependencies by
> injecting LDFLAGS="-Wl,--as-needed" into %configure macros. As on mean
> time cmake emerged this move will be not so effective as it was decade
> ago. Today I think that better solution could apply
On 03/15/2017 05:32 PM, Tomasz Kłoczko wrote:
> ./r/rust.git/rust.spec:BuildRequires: llvm-static
This one is conditional, generally disabled. We use it to break rust's
bootstrap dependency when llvm is being rebased to a new soname.
___
devel mailing
On Thu, 16 Mar 2017 01:32:06 +0100, Tomasz Kłoczko wrote:
> OK here is full list of spec files which have glibc-static in BuildRequires:
>
> ./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}
This is a false positive as it is enclosed by:
%if 0%{?_with_testsuite:1}
I have no
On 16 March 2017 at 12:20, Jonathan Wakely
wrote:
[..]
> I can only repeat that such people should consider linking own binaries
>> against uClibc as this implementation is not affected by issue with hidden
>> loading NSS DSOs which probably make such binaries useless
On 15/03/17 19:26 +, Tomasz Kłoczko wrote:
On 15 March 2017 at 18:53, Jonathan Wakely
wrote:
There are people who use the static libraries, for their own reasons,
and don't expect support when they do so.
I can only repeat that such people should consider
On 16 March 2017 at 04:50, Nico Kadel-Garcia wrote:
[..]
> > And one more clarification: remove static libraries from glibc distro
> > packages does not blocks static linking.
> > It will only removes possibility linking against static glibc libraries.
>
> Yes. This is a
On Wed, Mar 15, 2017 at 9:51 AM, Tomasz Kłoczko
wrote:
>
> On 15 March 2017 at 00:05, Jonathan Wakely
> wrote:
>>
>> If glibc-static was removed from Fedora and that change propagated to
>> RHEL I know of companies that might stop being
OK here is full list of spec files which have glibc-static in BuildRequires:
./g/gcc.git/gcc.spec:BuildRequires: glibc-static
./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}
./g/gdb.git/gdb.spec:# multilib glibc-static is open Bug 488472:
./g/gdb.git/gdb.spec:#BuildRequires:
Please turn off HTML in GMail.
On 03/15/2017 02:26 PM, Tomasz Kłoczko wrote:
I can only repeat that such people should consider linking own binaries against
uClibc as this implementation is not affected by issue with hidden loading NSS
DSOs which probably make such binaries useless on moving
On 03/14/2017 03:46 PM, Tomasz Kłoczko wrote:
This problem is wy bigger than you may be thinking. Above it is
only tip of the iceberg ..
# dnf list | grep -- -static | grep -c x86_64
196
This includes all available packages, but if you look at the actual
usage on an average system, i.e.
On 15 March 2017 at 18:53, Jonathan Wakely
wrote:
> There are people who use the static libraries, for their own reasons,
> and don't expect support when they do so.
>
I can only repeat that such people should consider linking own binaries
against uClibc as this
On 15/03/17 18:24 +0100, Florian Weimer wrote:
On 03/15/2017 01:05 AM, Jonathan Wakely wrote:
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
This is not the right list for discussing Red Hat Enterprise
On 15/03/17 13:51 +, Tomasz Kłoczko wrote:
On 15 March 2017 at 00:05, Jonathan Wakely
wrote:
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically
On 03/15/2017 10:08 AM, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
>> On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
>>> If glibc-static was removed from Fedora and that change propagated to
>>> RHEL I know of companies that might stop being customers
On 03/15/2017 01:05 AM, Jonathan Wakely wrote:
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
This is not the right list for discussing Red Hat Enterprise Linux
matters, but please be advised that the
On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
> On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
> > If glibc-static was removed from Fedora and that change propagated to
> > RHEL I know of companies that might stop being customers of Red Hat.
>
> Even if Fedora removed it, we could
> Wiadomość napisana przez Josh Stone w dniu 15.03.2017, o
> godz. 17:56:
>
> This may still be a useful consideration for Fedora itself. Would we
> alienate anyone if Fedora removed glibc-static?
I think that this particular case should not be removed. Some tools do need
On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.
Even if Fedora removed it, we could still make the business decision to
add it back to RHEL.
> Being
On 14 March 2017 at 20:15, Richard W.M. Jones wrote:
> These are very useful for building embedded systems, initramfses,
> static linked binaries of large proprietary programs, and any case
> where you don't want to depend on the system libraries.
>
There are still none of
On 15 March 2017 at 00:05, Jonathan Wakely
wrote:
> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.
>
> Being unable to statically link their applications would be a
>
On 14/03/17 20:15 +, Richard W.M. Jones wrote:
On Tue, Mar 14, 2017 at 07:46:38PM +, Tomasz Kłoczko wrote:
On 14 March 2017 at 17:57, Christopher wrote:
> Despite such simple to fix bug using static libraries should be removed.
>
> Your comment makes me
On Tue, Mar 14, 2017 at 07:46:38PM +, Tomasz Kłoczko wrote:
> On 14 March 2017 at 17:57, Christopher wrote:
>
> > Despite such simple to fix bug using static libraries should be removed.
> >
> > Your comment makes me wonder if there is *any* appropriate use of
> >
On 14 March 2017 at 17:57, Christopher wrote:
> Despite such simple to fix bug using static libraries should be removed.
>>
>>
>
> Your comment makes me wonder if there is *any* appropriate use of
> boost-static. If not, why is it even packaged?
> I'd be happy to
48 matches
Mail list logo