rawhide broken because of /usr/lib/.build-id in binary packages

[Remi Collet]

Hi,

It seems some recent changes (rawhide) result in tons of files in
/usr/lib/.build-id which are obviously not needed, and as non-unique
create conflicts

ex: https://kojipkgs.fedoraproject.org/work/tasks/1239/18391239/root.log


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Tue, Mar 14, 2017 at 11:38:51PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 14, 2017 at 08:29:00PM +, Daniel P. Berrange wrote:
> > On Tue, Mar 14, 2017 at 08:09:00PM +, Richard W.M. Jones wrote:
> > > Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
> > > 
> > > Currently if you install a minimal-ish, non-"Virtualization Host"
> > > Fedora, then the permissions on the /dev/kvm device are:
> > > 
> > >   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> > > 
> > > (I believe this is because of some kernel defaults for the device.  In
> > > any case there seems to be no base install udev rule which applies a
> > > `MODE=' line explicitly for /dev/kvm).
> > > 
> > > There mere act of installing the qemu package adds a new udev rule
> > > which changes the permissions:
> > > 
> > >   [root@rawhide ~]# ll /dev/kvm 
> > >   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> > >   [root@rawhide ~]# dnf -y install qemu-system-x86
> > >   //...
> > >   [root@rawhide ~]# ll /dev/kvm
> > >   crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> > > 
> > > I don't have a problem with any of that and I'm not saying that the
> > > permissions should be more restrictive, but for balance I will note
> > > that in Debian /dev/kvm is more restrictive (see comment in the bug
> > > above).
> > > 
> > > The problem raised in the bug above is that with containers people
> > > will wish to install qemu or libvirt or other tools inside the
> > > containers, but not necessarily have qemu installed on the host.  In
> > > that case, they will always see /dev/kvm with mode 0600, ie. generally
> > > unusable for them.
> > 
> > I'm fuzzy about the issue faced with containers. Containers will usually
> > have a separate /dev that is populated by the container mgmt engine (whether
> > docker, libvirt, lxc or something else). That mgmt engine is responsible for
> > setting permissions of /dev/kvm in the container's /dev if the user asked 
> > for
> > /dev/kvm to be made available. udev should never run inside a container - it
> > is only supposed to run in host context. So any udev rules that manipulate
> > /dev/kvm permissions will only ever be used in host context and never have
> > any effect on containers.
> > 
> > The bug listed above doesn't actually describe any real problem with
> > containers & /dev/kvm - my reading is that the bug is just thinking
> > about a hypothetical  future problem, but since udev isn't involved
> > in containers' /dev mgmt, I don't think there's a bug that needs fixing
> > here.
> 
> This applies to any system where kvm is to be used by unprivileged users
> without qemu package being installed. It is possible to use kvm in this
> way, e.g. by using self-compiled qemu, or some alternative or whatever.
> So maybe we should move the rules for /dev/kvm to
> /usr/lib/udev/rules.d/50-udev-default.rules.

Sure, if udev maintainers are willing to ship the kvm rule by default,
that's fine with me for reason you suggest. I simply don't think it'll
have any effect on usage of /dev/kvm inside containers

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide broken because of /usr/lib/.build-id in binary packages

[Remi Collet]

=> https://bugzilla.redhat.com/1432372
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

jplesnik uploaded XML-LibXML-2.0129.tar.gz for perl-XML-LibXML

[notifications]

f17c61052975ecc188c285ee93dbb07926c880a28e49afdd5af0c7c997e8b12be72412d0964391f1232f853935ee0ff2838cd5d62f8f3b4f52c341904069ccea
  XML-LibXML-2.0129.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-XML-LibXML/XML-LibXML-2.0129.tar.gz/sha512/f17c61052975ecc188c285ee93dbb07926c880a28e49afdd5af0c7c997e8b12be72412d0964391f1232f853935ee0ff2838cd5d62f8f3b4f52c341904069ccea/XML-LibXML-2.0129.tar.gz
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
> 
> 
> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
> >
> > On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
> >>
> >> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
> >>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>  On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>  I guess if you volume/bind mount the device into the container you could
>  see an issue,
>  but most containers that deal with /dev/kvm are going to be run as root,
>  anyways.
> >>> I was running with --privileged, still got permission denied until I
> >>> changed permissions of /dev/kvm to 666.
> >>> ___
> >>> devel mailing list -- devel@lists.fedoraproject.org
> >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
> >> crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 
> >> 232 Mar 14 21:12 /dev/kvm
> >> # chmod 600 /dev/kvm 
> >> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm 
> >> crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 
> >> 232 Mar 14 21:13 /dev/kvm
> >>
> >> So using --device to add the device to the container just maintains the 
> >> permission of the host
> >> for the device you added.  Whether it is volume mounted in or specified 
> >> via --device, at least
> >> from dockers point of view. 
> > I'm not sure of your point. I was just trying to say that whether i
> > was root or not did not seem to matter. I still got permission denied
> > if perms were 600 and not 666. I'm working off of memory here, so it's
> > possible somebody will prove me wrong.
>
> Most likely libvirt or whoever is launching the containers is not running
> as root, so it is being blocked access.

It is simpler than that. When you ask libvirt to assign a device to a
container it will simply mknod() in the container's private /dev, with
permissions 0700. If the container needs to make that available to
mon-privileged users inside the container, its "init" has to arrange
to set permissions further.

For Docker, I'm unclear whether it is also just doing a mknod in the
container's /dev, or whether it is bind mounting the host device node.
Either way, udev isn't involved inside the container.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: application and header files

[Michael Schwendt]

On Tue, 14 Mar 2017 19:04:22 -0400, Randy Barlow wrote:

> What do you find misleading about the review?

It has discussed headers that are not installed anywhere. I expected
to find a spec file that either deletes headers from the buildroot or
includes them in a non-devel package to begin with. Instead, the
reviewed package includes only an executable binary and no comments
on any API or library.

> Yes, the spec doesn't include the headers - my question is whether it
> should.

For that you would need to come up with a rationale. If you don't trust
upstream's distribution and default installation method, you need to
examine the sources and develop a theory why to package headers upstream
doesn't install by default.

This program is built from a set of C source files, where it is very
common to use internal headers as soon as the code grows and is split into
multiple reusable pieces. Most of the headers are useless without their
corresponding .c source files.

> They are the headers for the code in the binary itself. How could we
> predict whether any user of this package might want to build another
> program on top of this one that does link with this binary?

Have you run into any package that does that?

We don't predict anything like that. It is a very weird idea in general.
If someone wanted to reuse code from this package, copying source code
files is the way it's done with FLOSS. And the src.rpm packages are good
enough for that. Alternatively, someone would develop a reusable library
together with a stable API/ABI, and that could be packaged separately.
We don't repackage the entire source files (from a src.rpm) in -devel
packages (or other subpackages).

> I'm more asking for clarification on what the packaging requirements
> are since fedora-review's text seemed to suggest that the files are
> required but I did not get that impression after reading the packaging
> guidelines. Since I do not see requirements for these headers in the
> guidelines I'm inclined to +1 the package, but I wanted to double check
> with the list first.

The fedora-review tool examines the buildroot contents, the files that are
included in the package(s). It doesn't care about uninstalled files.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide broken because of /usr/lib/.build-id in binary packages

[Mark Wielaard]

On Wed, 2017-03-15 at 10:12 +0100, Remi Collet wrote:
> Hi,
> 
> It seems some recent changes (rawhide) result in tons of files in
> /usr/lib/.build-id which are obviously not needed, and as non-unique
> create conflicts
> 
> ex: https://kojipkgs.fedoraproject.org/work/tasks/1239/18391239/root.log

Thanks for the report and bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=1432372
The issue is not the files themselves but the directories they are in.
The files got moved to a new location but obviously in a wrong way since
previously the directories didn't conflict. I'll look into it.

BTW. This is controlled by the following rpm macro:

#
# Defines how and if build_id links are generated for ELF files.
# The following settings are supported:
#
# - none
#   No build_id links are generated.
#
# - alldebug
#   build_id links are generated only when the __debug_package global is
#   defined. This will generate build_id links in the -debuginfo package
#   for both the main file as /usr/lib/debug/.build-id/xx/yyy and for
#   the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug.
#   This is the old style build_id links as generated by the original
#   find-debuginfo.sh script.
#
# - separate
#   build_id links are generate for all binary packages. If this is a
#   main package (the __debug_package global isn't set) then the
#   build_id link is generated as /usr/lib/.build-id/xx/yyy. If this is
#   a -debuginfo package (the __debug_package global is set) then the
#   build_id link is generated as /usr/lib/debug/.build-id/xx/yyy.
#
# - compat
#   Same as for "separate" but if the __debug_package global is set then
#   the -debuginfo package will have a compatibility link for the main
#   ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy
%_build_id_links compat

So setting it to alldebug would give you the previous location.

Cheers,

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1432280] perl-XML-LibXML-2.0129 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1432280

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-XML-LibXML-2.0129-1.fc
   ||27



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Voice recognition packages need a new maintainer

[Peter Robinson]

On Wed, Mar 15, 2017 at 4:59 AM, Jerry James  wrote:
> On Tue, Mar 14, 2017 at 5:27 AM, Peter Robinson  wrote:
>> You can assign pocketsphinx and it's dep sphinxbase to me as I need
>> them for a project I'm investigating ATM.
>
> Packagedb is claiming that you are not in the packager group, from

Oh I'm there alright:
https://admin.fedoraproject.org/pkgdb/packager/pbrobinson/

> which I conclude that one of the following is true:
> - the FAS account name given here is not correct:
> https://fedoraproject.org/wiki/User:Pbrobinson
> - packagedb is currently experiencing issues retrieving information from FAS
> - I am really, really tired from the stupid time change and have done
> something idiotic while trying to give these packages to you
>
> I'll be really interested to find out which of those is the case.
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/15/2017 05:27 AM, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
>>
>> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
>>> On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
 On 03/14/2017 05:02 PM, Dusty Mabe wrote:
> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>> I guess if you volume/bind mount the device into the container you could
>> see an issue,
>> but most containers that deal with /dev/kvm are going to be run as root,
>> anyways.
> I was running with --privileged, still got permission denied until I
> changed permissions of /dev/kvm to 666.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
 # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
 crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 
 232 Mar 14 21:12 /dev/kvm
 # chmod 600 /dev/kvm 
 # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm 
 crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 
 232 Mar 14 21:13 /dev/kvm

 So using --device to add the device to the container just maintains the 
 permission of the host
 for the device you added.  Whether it is volume mounted in or specified 
 via --device, at least
 from dockers point of view. 
>>> I'm not sure of your point. I was just trying to say that whether i
>>> was root or not did not seem to matter. I still got permission denied
>>> if perms were 600 and not 666. I'm working off of memory here, so it's
>>> possible somebody will prove me wrong.
>> Most likely libvirt or whoever is launching the containers is not running
>> as root, so it is being blocked access.
> It is simpler than that. When you ask libvirt to assign a device to a
> container it will simply mknod() in the container's private /dev, with
> permissions 0700. If the container needs to make that available to
> mon-privileged users inside the container, its "init" has to arrange
> to set permissions further.
>
> For Docker, I'm unclear whether it is also just doing a mknod in the
> container's /dev, or whether it is bind mounting the host device node.
> Either way, udev isn't involved inside the container.
>
> Regards,
> Daniel
My point was that docker is just matching the permissions from the host.

In the case of using docker run --device /dev/kvm
It is creating a different device


#ls -i /dev/kvm

18835 /dev/kvm

# docker run -ti --device /dev/kvm fedora sh

# ls -lZ /dev/kvm 
crw---. 1 root 36 system_u:object_r:container_file_t:s0:c516,c728 10, 232 
Mar 15 11:44 /dev/kvm
# ls -i /dev/kvm 
669570 /dev/kvm

If I chmod 666 outside of the container the mode of the container is still 600, 
so they are different devices.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Upgrade of lv2 audio plugin system related packages in rawhide

[Guido Aulisi]

Hi,
I'm upgrading some LV2 audio plugin system related packages in rawhide.
The packages are:

lv2
serd
sord
sratom
lilv
suil

I'm not using a build tag, so the entire work will last some days.
Any packages that depend on these should rebuild after this update
ends.

There are no soname bumps, so old packages should work fine, but you
could get enhancements if dependent packages use #ifdef in the source
(like Ardour).

A list of possible affected packages:

lv2-abGate
lv2-amsynth-plugin
lv2-artyfx-plugins
lv2-avw-plugins
lv2-calf-plugins
lv2-devel
lv2-drumkv1
lv2-EQ10Q-plugins
lv2-fabla
lv2-fomp-plugins
lv2-guitarix-plugins
lv2-invada-plugins
lv2-ir-plugins
lv2-kn0ck0ut
lv2-ll-plugins
lv2-mdaEPiano
lv2-mdala-plugins
lv2-newtonator
lv2-samplv1
lv2-setBfree-plugins
lv2-sorcer
lv2-swh-plugins
lv2-synthv1
lv2-triceratops
lv2-vocoder-plugins
lv2-x42-plugins
lv2-zynadd-plugins

ardour2
ardour4
ardour4-audiobackend-alsa
ardour4-audiobackend-dummy
ardour4-audiobackend-jack
ardour5
ardour5-audiobackend-alsa
ardour5-audiobackend-dummy
ardour5-audiobackend-jack
guitarix
jalv
jalv-gtk
jalv-gtkmm
jalv-qt
ladspa-guitarix-plugins
lcd4linux
muse
qtractor
serdisplib-devel
serdisplib-tools
sonic-visualiser

Thanks
Guido Aulisi (fas account name: tartina)

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd-coredump-python

[Miroslav Suchý]

Dne 15.3.2017 v 04:14 Zbigniew Jędrzejewski-Szmek napsal(a):
> This conflict should be temporary, the patch to make the abrt
> handler non-exclusive should be trivial.)

Patches are welcome.

> 4. run a python script that throws an exception
>e.g. python3 
> /usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py,
>this should print a traceback to stdout

Commands:
will_python_raise
will_python3_raise
will_python_sigsegv

from package will-crash are probably more comfortable

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wrongly handled LLVM update [Fwd: [Fedora Update] [CRITPATH] [comment] llvm-3.9.1-1.fc25]

[Kevin Kofler]

Igor Gnatenko wrote:
> Why it got pushed to stable?

Because the maintainer enabled autokarma, which is always a mistake.

Updates should only ever be pushed after carefully considering the feedback 
inside and outside Bodhi, including the actual text of the comments, which 
the Bodhi software cannot fathom. Allowing a push to happen based only on 
the numeric score is always a mistake.

The decision when to push an update to stable should be made by a human. And 
the maintainer can only make that decision after the feedback actually 
arrived, it cannot be done in advance by setting some karma thresholds.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd-coredump-python

[Bastien Nocera]

- Original Message -
> There's a new tiny package which provides a python traceback logging in
> the journal for python processes. It's very similar to the existing
> handler provided by abrt, it also installs itself as sys.excepthook
> using a .pth file, but instead of communicating with abrt, it talks to
> systemd-coredump directly.

If it's an upstream feature, could you please update:
https://bugs.freedesktop.org/show_bug.cgi?id=82507
?

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

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
> showstopper for some, and would cause them to move to a different
> distro.
>

So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100%
sure that exactly this part is not in RH support small prints. In other
words you may have only impression that this part is already covered in
support conditions.

Again try to answer on question why long time ago other OSes abandoned
providing static libc?
Internally this part is and always will be affected by definition by any
future changes in kernel ABI. glibc it is not only libc library. Glibc
provides couple of other components which are using internal glibc ABI/API.
Shared libc wraps all those changes and allows handle (in long term) even
quite significant changes beneath own glibc public API/ABI and on boundary
between kernel<->user space without hurting user space binaries.

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.

Remove static libc it is not new idea. It is +20 years around and none of
the Solaris users moved away from this OS by this reason.
No .. it is completely opposite situation. Because OS like Solaris does not
provides libc.a still even on latest Solaris is possible execute and use
more than decade old binaries.

Linux kernel ABI is changing constantly and flexibility on boundary between
kernel and userspace is covered in Linux kernel documentation *literally*.
>From Documentation/ABI/README:

stable/
This directory documents the interfaces that the developer has
defined to be stable.  Userspace programs are free to use these
interfaces with no restrictions, and backward compatibility for
them will be *guaranteed for at least 2 years*.  Most interfaces
(like syscalls) are expected to never change and always be
available.


Possibility of future changes between kernel and user space was even one of
the fundamental reasons why libc was developed looog time ago before Linus
started thinking about porting Minix to i386.

You can ignore me but you cannot ignore facts behind why something like
libc exist and why no one should use static version of the libc libraries.

Especially static linking with glibc is very dangerous as long if linked
binary is using NSS libc interface. Some people are thinking that "fully"
statically linked program does not use or will not need any DSOs. In case
of using by such binary NSS libc interface this not true as depends on NSS
map type and NSS settings (described in /etc/nsswitch.conf) will be causing
loading nss_.so DSOs.
Number of changes in glibc in internal NSS interface where quite big in
recent years, and if someone will/is using statically linked binary where
NSS interface is in use such binary will be loading NSS modules (probably)
compiled against not correct glibc.Result: execution of such binaries will
fail or even crash with SIGSEV.
This scenario is covered literally as well in glibc documentation:
https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F

It is already known that within next few years NSS area in glibc it will be
probably one of the fastest changing area in glibc whole project. Solaris
already coverers in his own libc many NSS security related extensions.
Glibc has a lot to catch up here. All those upcoming changes will
definitely even harder kick back all people linking own executables against
glibc static libraries. This will be probably even bigger problem than all
potential kernel<->user space ABI changes.

Other static libraries used by distribution are carrying as well real and
potential security risk.
Example: RH/Fedora is using bash which is linked against own copy of
readline (provided within bash original source tree). It was few CVEs in
readline in recent years and some people been exploiting fact that bash
was/is linked against readline with well known security issue.
So here is surprise: in case finding new 0-day bug(s) in readline it will
be necessary to provide not one readline fixed package but two .. readline
and bash.

Yes. RH/Fedora bash has some *very well known security flaw* which hanging
above whole distro reputation like a Damocles sword!!!
In last 20 years I've been trying to convince few people to remove exactly
this bash risk but last time when I've been trying this my English was not
good enough to express this enough clear and strong. Maybe this time ..

Reality is that remove building and providing all of those +190 -static
packages will as well a

Re: Wrongly handled LLVM update [Fwd: [Fedora Update] [CRITPATH] [comment] llvm-3.9.1-1.fc25]

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 15, 2017 at 01:47:18PM +0100, Kevin Kofler wrote:
> Igor Gnatenko wrote:
> > Why it got pushed to stable?
> 
> Because the maintainer enabled autokarma, which is always a mistake.
> 
> Updates should only ever be pushed after carefully considering the feedback 
> inside and outside Bodhi, including the actual text of the comments, which 
> the Bodhi software cannot fathom. Allowing a push to happen based only on 
> the numeric score is always a mistake.
> 
> The decision when to push an update to stable should be made by a human. And 
> the maintainer can only make that decision after the feedback actually 
> arrived, it cannot be done in advance by setting some karma thresholds.

I don't think this can be the case. It says "Autopush Disabled",
and IIRC recent bodhi updates disable autopush after a single negative karma.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd-coredump-python

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 15, 2017 at 01:39:48PM +0100, Miroslav Suchý wrote:
> Dne 15.3.2017 v 04:14 Zbigniew Jędrzejewski-Szmek napsal(a):
> > This conflict should be temporary, the patch to make the abrt
> > handler non-exclusive should be trivial.)
> 
> Patches are welcome.

It's on my todo list ;)

> > 4. run a python script that throws an exception
> >e.g. python3 
> > /usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py,
> >this should print a traceback to stdout
> 
> Commands:
> will_python_raise
> will_python3_raise
> will_python_sigsegv

Ah, cool, a very nice set of commands ;)

$ coredumpctl --since today
TIMEPID   UID   GID SIG COREFILE  EXE
Wed 2017-03-15 10:09:35 EDT3270  1000  1000   - - /usr/bin/python3.5
Wed 2017-03-15 10:10:37 EDT3362  1000  1000   - - /usr/bin/python2.7
Wed 2017-03-15 10:12:25 EDT3514  1000  1000  11 present   /usr/bin/python2.7

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution

[Florian Weimer]

On 03/15/2017 02:51 PM, Tomasz Kłoczko wrote:

So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100%
sure that exactly this part is not in RH support small prints. In other
words you may have only impression that this part is already covered in
support conditions.


A statically linked libc isn't much different from a dynamically linked 
libc in a container.  Both rely on stable kernel interfaces.  Same for 
alternative toolchains not based on GNU.


The main problem with static linking in Fedora is that we do not rebuild 
all static libraries once we update glibc-static.  glibc only provides 
ABI compatibility for dynamic linking.  The only saving grace is that we 
gradually cut back on the use of compatibility symbols to make header 
file changes, so incompatible changes have been quite rare for a while.


This isn't really glibc-specific, though, it probably applies to other 
static libraries, too.  The impact of changes to glibc-static are just 
more visible.



Again try to answer on question why long time ago other OSes abandoned
providing static libc?


I think those other operating systems simply do not expose internal 
development tools externally.  They still use static linking in some places.


Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

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 the real embedded systems distributions which are
using statically linked binaries lined with glibc libraries.
Fedora is not for embedded systems and using it on even small systems lie
tv box (with +.5GB RAM) binaries with statically linked glibc will be waste
of memory as already some other running processes will be using shared
glibc libraries.
In such use cases it will be better to link such binaries against uClibc or
link some custom binary in busybox tree (both are part of the Fedora).
Those packages does not provides shared libc ABI .. only static libc.a

Glibc libc code as general libs simple is so bloated that using it on
embedded systems as regular libc is pointless (and still is very hard even
with constantly growing system memory of such systems). This is why
projects like OpenWRT/Lede and other are not using glibc.
Reality is that glibc provides some functions which are really hard to find
even single binary which are using them.

You can easily chop probably half of the glibc libc binary and 99.99% of
whole Fedora distribution binaries will be working. Good that each library
is not loaded as whole object into memory (paging) and only by this it does
not hurts to much (hever whole library public symbols jump table must be
fully initialized and loaded into memory so it is some noticeable cost of
it ..).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Dusty Mabe]

On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
> 
> Sure, if udev maintainers are willing to ship the kvm rule by default,
> that's fine with me for reason you suggest. I simply don't think it'll
> have any effect on usage of /dev/kvm inside containers
> 

Does that mean you assume my scenario I outlined is incorrect? The
only reason we are having this discussion is because i found that
changing the permissions of /dev/kvm on the host from 600 to 666 made
it so that I could run libvirt inside a container, which would mean
that if does have an effect on usage of /dev/kvm inside a container.

I could be "using it wrong", but would like for you to tell me why
what I'm doing is invalid.

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
> 
> 
> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
> > 
> > Sure, if udev maintainers are willing to ship the kvm rule by default,
> > that's fine with me for reason you suggest. I simply don't think it'll
> > have any effect on usage of /dev/kvm inside containers
> > 
> 
> Does that mean you assume my scenario I outlined is incorrect? The
> only reason we are having this discussion is because i found that
> changing the permissions of /dev/kvm on the host from 600 to 666 made
> it so that I could run libvirt inside a container, which would mean
> that if does have an effect on usage of /dev/kvm inside a container.

Oh, wait I think I see - you don't have qemu installed in the host
at all - you only installed it inside a docker image, but docker
is just copying the host permissions, and thus see the default
permissions from the kernel.

> I could be "using it wrong", but would like for you to tell me why
> what I'm doing is invalid.

While Docker copies the permissions from host devices, I don't think
that is something it is nice to rely on. Different operating systems
have different views on what default permissions are. So if you build
a Docker image that relies on the host OS having given /dev/kvm
particular permissions, your Docker image is going to be non-portable.

IOW while moving the udev rule out of the QEMU rpm into the udev RPM
would fix it for future Fedora, your docker image is going to be
unable to reliably run on other OS distros (whether older Fedora or
Debian which has restrictive /dev/kvm by default).

I don't see any way to force docker to give the device different
permissions when using the --device flag to launch a container.
In absence of that the only other option is to use an entrypoint
script to chmod the file when your container starts, but that
requires the container to run privileged which is bad. I think
ideally Docker would provide some way to give explicit permissions
so your container is isolated from decisions OS distros make about
default permissions in the host. 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/15/2017 11:49 AM, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
>>
>> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>>> Sure, if udev maintainers are willing to ship the kvm rule by default,
>>> that's fine with me for reason you suggest. I simply don't think it'll
>>> have any effect on usage of /dev/kvm inside containers
>>>
>> Does that mean you assume my scenario I outlined is incorrect? The
>> only reason we are having this discussion is because i found that
>> changing the permissions of /dev/kvm on the host from 600 to 666 made
>> it so that I could run libvirt inside a container, which would mean
>> that if does have an effect on usage of /dev/kvm inside a container.
> Oh, wait I think I see - you don't have qemu installed in the host
> at all - you only installed it inside a docker image, but docker
> is just copying the host permissions, and thus see the default
> permissions from the kernel.
>
>> I could be "using it wrong", but would like for you to tell me why
>> what I'm doing is invalid.
> While Docker copies the permissions from host devices, I don't think
> that is something it is nice to rely on. Different operating systems
> have different views on what default permissions are. So if you build
> a Docker image that relies on the host OS having given /dev/kvm
> particular permissions, your Docker image is going to be non-portable.
>
> IOW while moving the udev rule out of the QEMU rpm into the udev RPM
> would fix it for future Fedora, your docker image is going to be
> unable to reliably run on other OS distros (whether older Fedora or
> Debian which has restrictive /dev/kvm by default).
>
> I don't see any way to force docker to give the device different
> permissions when using the --device flag to launch a container.
> In absence of that the only other option is to use an entrypoint
> script to chmod the file when your container starts, but that
> requires the container to run privileged which is bad. I think
> ideally Docker would provide some way to give explicit permissions
> so your container is isolated from decisions OS distros make about
> default permissions in the host. 
>
> Regards,
> Daniel
Lets open a bugzilla on this for docker, although I am not sure upstream
would be amenable to a decent solution.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution

[Tomasz Kłoczko]

On 15 March 2017 at 14:16, Florian Weimer  wrote:
[..]

> The main problem with static linking in Fedora is that we do not rebuild
> all static libraries once we update glibc-static.  glibc only provides ABI
> compatibility for dynamic linking.  The only saving grace is that we
> gradually cut back on the use of compatibility symbols to make header file
> changes, so incompatible changes have been quite rare for a while.
>
> This isn't really glibc-specific, though, it probably applies to other
> static libraries, too.  The impact of changes to glibc-static are just more
> visible.
>
> Again try to answer on question why long time ago other OSes abandoned
>> providing static libc?
>>
>
> I think those other operating systems simply do not expose internal
> development tools externally.  They still use static linking in some places.
>

You are not even trying to answer on above question .. a bit sad because
you are simple ignoring some very good technical arguments.
Trying to crush what you are thinking about subject using stronger phrases
would illogical and I'm not going to follow this path. Really pleas try to
stick to technical arguments.
Discussion it is like fencing but using arguments. It is really hard try to
convince someone using what "I think". Look again on what I've already
wrote and you will find that none of my argumentation relies on what "I'm
thinking".

Again: there was already enough bad cases in Unix history to form
conclusion that none of the regular distribution consumers should rely on
things below libc public ABI/API because unconsciously using such parts
they been doing for themselves more harm than real financial/reputation or
other damages to anyone who is trying to provide commercial or
non-commercial support of any OS distribution.

I'll try to rephrase above. In the past I've been working on whole rpm
based distribution and more than decade ago I made decision about separate
all static libraries into -static subpackages. After what we (me and few my
colleagues) done other distros started mimicking this pattern. It was done
consequently on scale +6k source packages (used by ~few thousands end
users) and after this I found that it was none real case scenario where
those static packages are really needed.
Look on what is now in Fedora and you will find that binutils has some
quite strange or easy to handle other way modifications in spec file only
to fully follow what is in source code binutils test suit.

What I've personally tested long time ago still stands firmly against you
honest impression (that such resources still may be good to have around in
form of packages).
In other words: what you see now in distribution like Fedora like some
-static subpackages it is because what I've personally started more than
decade ago.
IMO now is enough good sample of using such approach (separating static
libraries) to form conclusion that this was kind of mistake and all those
static libraries can be dropped without any noticeable consequences ..  on
even some hard/nasty developers oriented install profiles.

With all what you are trying (honestly) to tell is like with some aspects
of quantum physics which says that probability that bucket of water
standing on top of open fire may freeze is non-zero.
Problem is that in real word maintained by real engineers it is really hard
to observe something like this :)
Many years ago I've been thinking just like you because same like you I've
been using intuition.
Trust me. If you are still *thinking* that you are right, it may be really
truth .. that you are *only thinking* that you are right  :)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Josh Stone]

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 unable to statically link their applications would be a
> showstopper for some, and would cause them to move to a different
> distro.

This may still be a useful consideration for Fedora itself.  Would we
alienate anyone if Fedora removed glibc-static?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Zygmunt Krynicki]

> 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 
static linking (e.g. initrd bits) and while those are obscure they are not 
really gone or on their way out. I would prefer not to remove static libraries 
even if they cause the well known issues as people that use them typically know 
why they are doing it.

Best regards
ZK
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Daniel P. Berrange]

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 still make the business decision to
> add it back to RHEL.
> 
> > Being unable to statically link their applications would be a
> > showstopper for some, and would cause them to move to a different
> > distro.
> 
> This may still be a useful consideration for Fedora itself.  Would we
> alienate anyone if Fedora removed glibc-static?

Yes, you would prevent us from being able to build static binaries for
the QEMU system emulators in Fedora QEMU packages. This in turn prevents
them from being used to provide seemless execution from non-native
architecture chroots / containers. This is used for example, by flatpack
to allow non-native architecture compilation, or as well as by myself
for various personal projects needing non-native compilation environments.

I agree there are many reasons why static libraries are a bad idea in
general, particularly the security implications, but they are none the
less useful at times and not every usage scenario has the same security
requirements.

NB, throwing out all the -static RPMs doesn't magically remove static
compilation from Fedora. There are entire non-C language toolchains in
Fedora that are based on static compilation - eg OCaml and Go 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution

[Florian Weimer]

On 03/15/2017 05:45 PM, Tomasz Kłoczko wrote:

You are not even trying to answer on above question .. a bit sad because
you are simple ignoring some very good technical arguments.


Please read again what I wrote.

In a container (and multi-toolchain) world, static linking of glibc does 
not add a significant support burden because we cannot use glibc as an 
abstraction layer for the kernel, unlike what other operating systems 
do.  (This is independently of what is actually supported.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Florian Weimer]

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 above statement shall not be 
interpreted in such a way that indicates that static linking of glibc is 
supported on Red Hat Enterprise Linux.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Josh Stone]

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 of Red Hat.
>>
>> Even if Fedora removed it, we could still make the business decision to
>> add it back to RHEL.

To be clear, I'm not advocating removal, just trying to say that
worrying about RHEL is the wrong approach.

>>> Being unable to statically link their applications would be a
>>> showstopper for some, and would cause them to move to a different
>>> distro.
>>
>> This may still be a useful consideration for Fedora itself.  Would we
>> alienate anyone if Fedora removed glibc-static?
> 
> Yes, you would prevent us from being able to build static binaries for
> the QEMU system emulators in Fedora QEMU packages. This in turn prevents
> them from being used to provide seemless execution from non-native
> architecture chroots / containers. This is used for example, by flatpack
> to allow non-native architecture compilation, or as well as by myself
> for various personal projects needing non-native compilation environments.
> 
> I agree there are many reasons why static libraries are a bad idea in
> general, particularly the security implications, but they are none the
> less useful at times and not every usage scenario has the same security
> requirements.
> 
> NB, throwing out all the -static RPMs doesn't magically remove static
> compilation from Fedora. There are entire non-C language toolchains in
> Fedora that are based on static compilation - eg OCaml and Go 

Yep, I maintain Rust which is one of these.  But it does still default
to shared linking for libc and any other FFI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fwd: Broken dependencies: boost

[Jonathan Wakely]

Does anybody know why I'd have got this today?

The only recent change to Boost is to enabled the MPI packages on
ppc64le, but that shouldn't have affected all arches:


--- a/boost.spec
+++ b/boost.spec
@@ -7,11 +7,8 @@
%global boost_docdir __tmp_docdir
%global boost_examplesdir __tmp_examplesdir

-%ifarch ppc64le
-  %bcond_with mpich
-%else
-  %bcond_without mpich
-%endif
+# All arches have mpich
+%bcond_without mpich

%ifarch s390
  # No OpenMPI support on these arches


The packages are complaining about a missing dependency *that is
provided by that package itself*!

Maybe relevant is that the "missing" libs are not installed to the
usual %{_libdir} location but to %{_libdir}/mpich/lib/ (for the mpich
variants) or %{_libdir}/openmpi/lib/ (for the openmpi variants).



- Forwarded message from build...@fedoraproject.org -

Date: Wed, 15 Mar 2017 17:17:47 + (UTC)
From: build...@fedoraproject.org
To: boost-ow...@fedoraproject.org
Cc: 
Subject: Broken dependencies: boost




boost has broken dependencies in the rawhide tree:
On x86_64:
boost-graph-openmpi-1.63.0-5.fc27.x86_64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On armhfp:
boost-graph-openmpi-1.63.0-5.fc27.armv7hl requires 
libboost_graph_parallel.so.1.63.0
On ppc64le:
boost-graph-openmpi-1.63.0-5.fc27.ppc64le requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On aarch64:
boost-graph-openmpi-1.63.0-5.fc27.aarch64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On ppc64:
boost-graph-openmpi-1.63.0-5.fc27.ppc64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On i386:
boost-graph-openmpi-1.63.0-5.fc27.i686 requires 
libboost_graph_parallel.so.1.63.0
On x86_64:
boost-openmpi-1.63.0-5.fc27.x86_64 requires 
libboost_mpi.so.1.63.0()(64bit)
On armhfp:
boost-openmpi-1.63.0-5.fc27.armv7hl requires libboost_mpi.so.1.63.0
On ppc64le:
boost-openmpi-1.63.0-5.fc27.ppc64le requires 
libboost_mpi.so.1.63.0()(64bit)
On aarch64:
boost-openmpi-1.63.0-5.fc27.aarch64 requires 
libboost_mpi.so.1.63.0()(64bit)
On ppc64:
boost-openmpi-1.63.0-5.fc27.ppc64 requires 
libboost_mpi.so.1.63.0()(64bit)
On i386:
boost-openmpi-1.63.0-5.fc27.i686 requires libboost_mpi.so.1.63.0
On x86_64:
boost-openmpi-python-1.63.0-5.fc27.x86_64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On armhfp:
boost-openmpi-python-1.63.0-5.fc27.armv7hl requires 
libboost_mpi_python.so.1.63.0
On ppc64le:
boost-openmpi-python-1.63.0-5.fc27.ppc64le requires 
libboost_mpi_python.so.1.63.0()(64bit)
On aarch64:
boost-openmpi-python-1.63.0-5.fc27.aarch64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On ppc64:
boost-openmpi-python-1.63.0-5.fc27.ppc64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On i386:
boost-openmpi-python-1.63.0-5.fc27.i686 requires 
libboost_mpi_python.so.1.63.0
On x86_64:
boost-mpich-1.63.0-5.fc27.x86_64 requires 
libboost_mpi.so.1.63.0()(64bit)
On armhfp:
boost-mpich-1.63.0-5.fc27.armv7hl requires libboost_mpi.so.1.63.0
On ppc64le:
boost-mpich-1.63.0-5.fc27.ppc64le requires 
libboost_mpi.so.1.63.0()(64bit)
On aarch64:
boost-mpich-1.63.0-5.fc27.aarch64 requires 
libboost_mpi.so.1.63.0()(64bit)
On ppc64:
boost-mpich-1.63.0-5.fc27.ppc64 requires libboost_mpi.so.1.63.0()(64bit)
On i386:
boost-mpich-1.63.0-5.fc27.i686 requires libboost_mpi.so.1.63.0
On x86_64:
boost-mpich-python-1.63.0-5.fc27.x86_64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On armhfp:
boost-mpich-python-1.63.0-5.fc27.armv7hl requires 
libboost_mpi_python.so.1.63.0
On ppc64le:
boost-mpich-python-1.63.0-5.fc27.ppc64le requires 
libboost_mpi_python.so.1.63.0()(64bit)
On aarch64:
boost-mpich-python-1.63.0-5.fc27.aarch64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On ppc64:
boost-mpich-python-1.63.0-5.fc27.ppc64 requires 
libboost_mpi_python.so.1.63.0()(64bit)
On i386:
boost-mpich-python-1.63.0-5.fc27.i686 requires 
libboost_mpi_python.so.1.63.0
On x86_64:
boost-graph-mpich-1.63.0-5.fc27.x86_64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On armhfp:
boost-graph-mpich-1.63.0-5.fc27.armv7hl requires 
libboost_graph_parallel.so.1.63.0
On ppc64le:
boost-graph-mpich-1.63.0-5.fc27.ppc64le requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On aarch64:
boost-graph-mpich-1.63.0-5.fc27.aarch64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On ppc64:
boost-graph-mpich-1.63.0-5.fc27.ppc64 requires 
libboost_graph_parallel.so.1.63.0()(64bit)
On i386:
boost-graph-mpich-1.63.0-5.fc27.i686 requires 
libboost_graph_parallel.so.1.63.0
Please resolve this as soon as possible.



- End forwarded message -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution

[Tomasz Kłoczko]

On 15 March 2017 at 17:22, Florian Weimer  wrote:

> Please read again what I wrote.
>
> In a container (and multi-toolchain) world, static linking of glibc does
> not add a significant support burden because we cannot use glibc as an
> abstraction layer for the kernel, unlike what other operating systems do.
> (This is independently of what is actually supported.)
>

Please try to have look first on "dnf list | grep -- - static" list maybe
after this you will realise that current list of packages with static
libraries is not enough to have such static linking dev environment because *in
last years many packages already dropped building and packaging static
libraries,* and no one been crying by this.
For cases which will mainly require for some reasons static linking with
libc.a probably it would be good consider switch to uClibc because in such
cases size of the binaries probably is quite important.

I have no idea from where it comes but glibc never was and never will be
abstraction layer for the kernel on any existing operating systems because
kernel provides abstraction layer on which sits (g)libc.

I'm still greping across all packages repos but so far I found only two
fedora packages which requires during build glibc-static. One is binutils
and second one is golang. Both packages uses static linking in own test
suits.
To test binutils ld that it able to link elf binary or DSO using some test
static libraries you don't need to link such test binary with libc.a.

Will have shortly full assessment of what really is using in Fedora
glibc-static.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Jonathan Wakely]

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 link their applications would be a
showstopper for some, and would cause them to move to a different
distro.



So you want to say that RH already guarantees Linux ABI compatibility below
glibc?


I don't think that's what I want to say. If I wanted to say that I'd
have said it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Jonathan Wakely]

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 Linux 
matters, but please be advised that the above statement shall not be 
interpreted in such a way that indicates that static linking of glibc 
is supported on Red Hat Enterprise Linux.


Right, that's definitely not what I meant.

There are people who use the static libraries, for their own reasons,
and don't expect support when they do so.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

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 implementation is not affected by issue with hidden
loading NSS DSOs which probably make such binaries useless on moving around
against latest fedora/RH7 and RH5.

Even at the end and idea of dropping building and providing glibc-static
will be not accepted at least current list of packages which are using
static linking with glibc libraries should be carefully reviewed. Looking
on not full list of spec files which have listed "BuildRequires:
glibc-static" i see for example mdadm abandoned static linking and again ..
no one is crying about this.
Definitely almost all of the those +190 static packages can be abandoned
without even single change in other Fedora spec files.

So far most of the cases which already found are using static linking with
glibc is related to some test suits.
For example only binutils provides ld and ld-gold and they are responsible
for linking with other libraries, and software like golang probably should
not be doing own static linking tests because for such static linking is
responsible binutils ld.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Przemek Klosowski]

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. only static packages that are actually 
pulled in by requirements, it is much, much less. It seems that static 
packages are primarily available because some package managers perceive 
a potential need for static linking; for instance I see many scientific 
libraries (HDF, CDF, scalapack, FFTW), and in that case there is a 
residual speed effect and the statically linked applications have a 
(perhaps no longer deserved) reputation for being more easily distributable.


I checked on my F25 where I pretty much install everything I might ever 
need (6400 packages), and there are just 2 static packages:


   llvm-static-3.8.1-2.fc25.x86_64
   rust-std-static-1.14.0-2.fc25.x86_64

I think you'd have to explicitly load most of them to get up to 196.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Michael Cronenworth]

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 around against latest 
fedora/RH7 and RH5.


Let's cut to the chase: You don't like glibc. OK. Do we need to create a 100+ email 
chain to thousands of Fedora developers who have more important things to do in 
their day? Feel free to discuss this on your blog or another medium.




Even at the end and idea of dropping building and providing glibc-static will be 
not accepted at least current list of packages which are using static linking with 
glibc libraries should be carefully reviewed. Looking on not full list of spec 
files which have listed "BuildRequires: glibc-static" i see for example mdadm 
abandoned static linking and again .. no one is crying about this.
Definitely almost all of the those +190 static packages can be abandoned without 
even single change in other Fedora spec files.


You'll have to do better than "because I don't like it." Just yesterday I had to 
create a binary that was SLES 10 compatible and thank-the-lord I had static 
libraries available in RHEL5 to be able to do it. There will be really strange cases 
that need static libraries around. They are not hurting anyone by having them 
present. Note: The previous sentence was brought to you buy a dynamic library supporter.




So far most of the cases which already found are using static linking with glibc 
is related to some test suits.
For example only binutils provides ld and ld-gold and they are responsible for 
linking with other libraries, and software like golang probably should not be 
doing own static linking tests because for such static linking is responsible 
binutils ld.


Those test suites are only executed during build time in Koji. They're not hurting 
you or any other Fedora user.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170315.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Xfce raw-xz armhfp
Server boot i386

Failed openQA tests: 14/107 (x86_64), 1/2 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170314.n.0):

ID: 65287   Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/65287
ID: 65290   Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/65290
ID: 65291   Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/65291
ID: 65307   Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/65307
ID: 65310   Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/65310
ID: 65313   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/65313
ID: 65355   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/65355
ID: 65362   Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/65362
ID: 65369   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/65369

Old failures (same test failed in Rawhide-20170314.n.0):

ID: 65286   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/65286
ID: 65305   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/65305
ID: 65308   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/65308
ID: 65326   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/65326
ID: 65374   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/65374
ID: 65378   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/65378
ID: 65379   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/65379

Soft failed openQA tests: 53/107 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170314.n.0):

ID: 65347   Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/65347
ID: 65380   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/65380

Old soft failures (same test soft failed in Rawhide-20170314.n.0):

ID: 65275   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/65275
ID: 65276   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/65276
ID: 65277   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/65277
ID: 65278   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/65278
ID: 65284   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/65284
ID: 65285   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/65285
ID: 65294   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/65294
ID: 65296   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/65296
ID: 65297   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/65297
ID: 65328   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/65328
ID: 65329   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/65329
ID: 65331   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/65331
ID: 65332   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/65332
ID: 65333   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/65333
ID: 65334   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/65334
ID: 65335   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/65335
ID: 65336   Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/65336
ID: 65337   Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/65337
ID: 65338   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/65338
ID: 65339   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/65339
ID: 65340   Test: x86_64 unive

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

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: glibc-static%{bits_other}
./g/glibc.git/glibc.spec:# before glibc is built and therefore we need
a glibc-static for that
./g/glibc.git/glibc.spec:BuildRequires: glibc-static
./g/glibc.git/glibc.spec:The glibc-static package contains the C
library static libraries
./g/glibc.git/glibc.spec:- Require glibc-static for C++ tests.
./g/glibc.git/glibc.spec:- Require gcc-c++, libstdc++-static, and
glibc-static only when needed.
./g/golang.git/golang.spec:BuildRequires:  pcre-devel, glibc-static, perl
./g/grub2.git/grub2.spec:BuildRequires:  /usr/lib64/crt1.o glibc-static
./g/grub2.git/grub2.spec:BuildRequires:  /usr/lib/crt1.o glibc-static
./b/binutils.git/binutils.spec:BuildRequires: dejagnu, zlib-static,
glibc-static, sharutils, bc
./b/binutils.git/binutils.spec:- Add glibc-static to BuildRequires
when running the testsuite.
./b/busybox.git/busybox.spec:BuildRequires: glibc-static
./c/cadvisor.git/cadvisor.spec:BuildRequires: glibc-static
./c/chkrootkit.git/chkrootkit.spec:BuildRequires:  glibc-static
./c/chkrootkit.git/chkrootkit.spec:- Fedora > 10: conditional BR
glibc-static as needed for strings-static
./c/compat-gcc-296.git/compat-gcc-296.spec:BuildRequires: glibc-devel
>= 2.2.90-12, glibc-static
./c/compat-gcc-32.git/compat-gcc-32.spec:BuildRequires: glibc-devel >=
2.2.90-12, glibc-static
./c/cscppc.git/cscppc.spec:BuildRequires: glibc-static
./c/cswrap.git/cswrap.spec:BuildRequires: glibc-static
./d/docker.git/docker.spec:BuildRequires: glibc-static
./d/docker-latest.git/docker-latest.spec:BuildRequires: glibc-static
./d/dyninst.git/dyninst.spec:BuildRequires: gcc-gfortran glibc-static
libstdc++-static nasm
./d/dyninst.git/dyninst.spec:Requires: glibc-static
./e/efivar.git/efivar.spec:BuildRequires:  popt-devel popt-static git
glibc-static libabigail
./k/kexec-tools.git/kexec-tools.spec:- Add BR glibc-static
./l/libguestfs.git/libguestfs.spec:BuildRequires: glibc-static
./l/libguestfs.git/libguestfs.spec:- BRs glibc-static for the new command tests.
./l/libhugetlbfs.git/libhugetlbfs.spec:BuildRequires: glibc-static
./l/libibmad.git/libibmad.spec:BuildRequires: glibc-static
./l/libibumad.git/libibumad.spec:BuildRequires: glibc-static
./l/libibumad.git/libibumad.spec:- Add build requires on glibc-static
./l/libvirt-sandbox.git/libvirt-sandbox.spec:BuildRequires: glibc-static
./m/mash.git/mash.spec:- allow glibc-static as a devel package
./m/mdadm.git/mdadm.spec:- Remove the glibc-static buildreq and don't
build the static mdadm since
./n/nacl-arm-binutils.git/nacl-arm-binutils.spec:BuildRequires:
dejagnu, zlib-static, glibc-static, sharutils
./n/nacl-binutils.git/nacl-binutils.spec:BuildRequires: dejagnu,
zlib-static, glibc-static, sharutils
./o/ocid.git/ocid.spec:BuildRequires:  glibc-static
./o/ORBit.git/ORBit.spec:BuildRequires: glibc-static
./o/ORBit.git/ORBit.spec:- BR: glibc-static for EL-6 onwards
./o/ORBit.git/ORBit.spec:- Buildreq glibc-static for test code in
bundled popt library (F-11 onwards)
./q/qemu-sanity-check.git/qemu-sanity-check.spec:BuildRequires:   glibc-static
./q/qemu.git/qemu.spec:BuildRequires: glibc-static pcre-static
glib2-static zlib-static
./r/redhat-lsb.git/redhat-lsb.spec:BuildRequires: glibc-static
./r/rkt.git/rkt.spec:BuildRequires: glibc-static
./s/scantailor.git/scantailor.spec:BuildRequires:  glibc-static
./s/supermin.git/supermin.spec:# To use glibc-static instead, do
``--without dietlibc''.  This
./s/supermin.git/supermin.spec:BuildRequires: glibc-static
./s/supermin.git/supermin.spec:- Enable dietlibc, remove glibc-static,
xz-static, zlib-static.
./s/supermin.git/supermin.spec:- New BRs on mke2fs, libext2fs, glibc-static.


Looking on this list without looking deeper into the packages it is easy to
figure out that almost half of the glibc-static using cases are related to
test suits.

BTW I found current Fedora guidelines about static linking and static
libraries and they are already forming set of rules which are recommending
what I've wrote here
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

In other words such subject has been discussed already and I'm not the only
one who is thinking that cutting to absolute minimum using static linking
and provide static libraries is right direction and/or thinking that Fedora
already provides some env to produce statically linked binaries is more or
less only kind of wrong impression.

And yet another grep output (this time a bit longer) which shows which
packages are using other packages static libraries:

./g/gcc.git/gcc.spec:BuildRequires: glibc*-static*
./g/gcl.git/gcl.spec:BuildRequires:  binutils*-static*
./g/gdal.git/gdal.spec:BuildRequires:   g2clib*-static*
./g/gdal.git/gdal.spec:BuildRequires: 

Schedule for Thursday's FPC Meeting (2017-03-16 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-03-16 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2017-03-16 09:00 Thu US/Pacific PDT
2017-03-16 12:00 Thu US/Eastern EDT
2017-03-16 16:00 Thu UTC <-
2017-03-16 16:00 Thu Europe/London <-
2017-03-16 17:00 Thu Europe/Paris   CET
2017-03-16 17:00 Thu Europe/Berlin  CET
2017-03-16 21:30 Thu Asia/Calcutta  IST
--new day--
2017-03-17 00:00 Fri Asia/Singapore SGT
2017-03-17 00:00 Fri Asia/Hong_Kong HKT
2017-03-17 01:00 Fri Asia/Tokyo JST
2017-03-17 02:00 Fri Australia/BrisbaneAEST


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

[Ed. note, this is intentionally blank
 there is currently an empty schedule]

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Nico Kadel-Garcia]

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 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 different
>> distro.
>
>
> So you want to say that RH already guarantees Linux ABI compatibility below
> glibc? I would be really surprised if it would be truth .. and I'm 100% sure
> that exactly this part is not in RH support small prints. In other words you
> may have only impression that this part is already covered in support
> conditions.
>
> Again try to answer on question why long time ago other OSes abandoned
> providing static libc?
> Internally this part is and always will be affected by definition by any
> future changes in kernel ABI. glibc it is not only libc library. Glibc
> provides couple of other components which are using internal glibc ABI/API.
> Shared libc wraps all those changes and allows handle (in long term) even
> quite significant changes beneath own glibc public API/ABI and on boundary
> between kernel<->user space without hurting user space binaries.
>
> 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 blocker for some people, who want *completely* static
binaries to have complete binary control of their active package.
glibc changing from a random update and possibly introducing a
regression problem is anathema to some critical software developers,
and the compilation of completely static binaries has been helpful for
cross-platform compatibility, for building chroot cages, and for
building well managed containers of various sorts.

Been there, done that with sorting out the library dependencies for
rssh chroot cages some time ago.

> You can ignore me but you cannot ignore facts behind why something like libc
> exist and why no one should use static version of the libc libraries.

I think you're mixing orthogonal concerns.

> Especially static linking with glibc is very dangerous as long if linked
> binary is using NSS libc interface. Some people are thinking that "fully"
> statically linked program does not use or will not need any DSOs. In case of
> using by such binary NSS libc interface this not true as depends on NSS map
> type and NSS settings (described in /etc/nsswitch.conf) will be causing
> loading nss_.so DSOs.

Well, yes. nsswitch.conf has been a mess since it was invented, for
reasons beyond the scope of this discussion.

> Number of changes in glibc in internal NSS interface where quite big in
> recent years, and if someone will/is using statically linked binary where
> NSS interface is in use such binary will be loading NSS modules (probably)
> compiled against not correct glibc.Result: execution of such binaries will
> fail or even crash with SIGSEV.
> This scenario is covered literally as well in glibc documentation:
> https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F

You seem to pointing out that NSS is a stability problem. You're quite
right. Saying that "NSS is unstable, therefore glibc should be forced
to dynamic libraries only" does not follow. The underlying API for
nsswitch.conf and NSS does not change that quickly, it's the feature
churn for add-ons that are being tied into NSS. For high stability
software, *who cared*? You won't use the most recent NSS changes, and
if you do, they're quite likely to be available the the glibc static
library at the time you compile them. Statically.

> It is already known that within next few years NSS area in glibc it will be
> probably one of the fastest changing area in glibc whole project. Solaris
> already coverers in his own libc many NSS security related extensions. Glibc
> has a lot to catch up here. All those upcoming changes will definitely even
> harder kick back all people linking own executables against glibc static
> libraries. This will be probably even bigger problem than all potential
> kernel<->user space ABI changes.

You've a point about NSS instability. That's actually quite
frightening. I lack your confidence that it justifies enforcing
dynamic libraries, and it seems *very* unlikely that the API's will
change enough to break older, stable software.

> Other static libraries used by distribution are carrying as well real and
> potential security risk.

It's true that it's a trade-off. The potential instability issue of a
glibc regression error is quite noticeable for high reliability
components, and even the "dnf update" process is vulnerable to glibc
update issues under some circumstances, such as running out of disk or
failing power during the update. High churn in

[Fedocal] Reminder meeting : Fedora 26 Alpha Go/No-Go Meeting

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Fedora 26 Alpha Go/No-Go Meeting on 2017-03-16 from 17:00:00 to 19:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Before each public release Development, QA and Release Engineering meet to 
determine if the release criteria are met for a particular release. This 
meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are 
met is the responsibility of the QA Team.

Release Candidate (RC) availability and good QA coverage are prerequisites for 
the Go/No-Go meeting. If you have any bug on the list, please help us with 
Alpha release. If we won't be ready by Thursday, we will use this meeting to 
review blockers and decide what to do.


Source: https://apps.fedoraproject.org/calendar/meeting/5305/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide broken because of /usr/lib/.build-id in binary packages

[Remi Collet]

Le 15/03/2017 à 10:24, Remi Collet a écrit :
> => https://bugzilla.redhat.com/1432372

It seems this report is only raised during PHP build (but other package
can be affected).

The issue is now fixed
- in php (dropping some old unneeded %attr)
- in rpm

Everything works now as expected (Koschei have start its work, and all
php packages slowing go back to normal)



Remi.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org