Re: [Help Wanted] PPC64LE build for thrift

2017-03-14 Thread Dan Horák 
On Tue, 14 Mar 2017 01:10:32 +
Christopher  wrote:

> Hi,
> 
> I'm trying to build the latest version of thrift, and am running into
> a problem with one of the build tests, which has a dependency on
> boost-static for "%{_libdir}/libboost_unit_test_framework.a"
> 
> I really have no expertise with PPC at all, and also very limited
> knowledge of autotools, but it looks like it's looking in the wrong
> libdir on PPC64LE.
> 
> Any help would be much appreciated.
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=18366919
> https://koji.fedoraproject.org/koji/taskinfo?taskID=18366921

g++: error: /usr/lib/libboost_unit_test_framework.a: No such file or
directory

the thrift  buildsystem doesn't treat ppc64le as a 64-bit arch
with /usr/lib64, probably there is a hard-coded list of arches ...


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

Re: Intent to orphan netty package

2017-03-14 Thread Michael Šimáček 

On 2017-03-10 14:40, Severin Gehwolf wrote:

Hi,

I'm going to orphan the netty package in Fedora next week since I no
longer using it. Please let me know if you are interested in
maintaining it.

Here is a list of packages that depend on netty (it's probably
incomplete):

artemis-commons
artemis-core-client
artemis-maven-plugin
artemis-rest
artemis-server
cassandra-java-driver
cassandra-java-libs
cxf-rt
hadoop-hdfs
hadoop-tests
hornetq-commons
hornetq-core-client
hornetq-rest
hornetq-server
infinispan
jython
littleproxy
mongo-java-driver
netty-xnio-transport
qpid-jms-client
wildfly-lib
xchange

Hopefully some maintainer of those packages will step up and take
netty. I'm going to orphan it next week. At that point it'll be up for
grabs :)



I can (co)maintain it as well.

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

Packages dropping anything in /etc/systemd/system

2017-03-14 Thread Simo Sorce 
Hello,
as per subject, what is the stance on dropping anything there from a
rpm ? Either marked as %{config} or not ?

My naive reading of the Packaging guidelines is that nothing should be
dropped in there by a package, but the guidelines only explicitly talk
about not putting "service" files in there.

There is now a debate with a package maintainer that is putting in the
etc/systemd/system/<..> directory what he calls a "configuration file,
not a unit file".

I seek clarification about this so that we can settle this matter.

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

Re: Intent to orphan netty package

2017-03-14 Thread Severin Gehwolf 
On Fri, 2017-03-10 at 18:36 +, Christopher wrote:
> I can take it.
> 
> > On Fri, Mar 10, 2017 at 9:38 AM Severin Gehwolf  wrote:
> > Hi,
> > 
> > I'm going to orphan the netty package in Fedora next week since I no
> > longer using it. Please let me know if you are interested in
> > maintaining it.
> > 
> > Here is a list of packages that depend on netty (it's probably
> > incomplete):
> > 
> > artemis-commons
> > artemis-core-client
> > artemis-maven-plugin
> > artemis-rest
> > artemis-server
> > cassandra-java-driver
> > cassandra-java-libs
> > cxf-rt
> > hadoop-hdfs
> > hadoop-tests
> > hornetq-commons
> > hornetq-core-client
> > hornetq-rest
> > hornetq-server
> > infinispan
> > jython
> > littleproxy
> > mongo-java-driver
> > netty-xnio-transport
> > qpid-jms-client
> > wildfly-lib
> > xchange
> > 
> > Hopefully some maintainer of those packages will step up and take
> > netty. I'm going to orphan it next week. At that point it'll be up for
> > grabs :)

I've orphaned the package. Feel free to take it.

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

Re: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> libldns.so.2)

2017-03-14 Thread Simo Sorce 
On Thu, 2017-03-09 at 15:10 -0800, Adam Williamson wrote:
> ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26 on
> 2017-03-06. This update bumped the soname from libldns.so.1 to
> libldns.so.2 . This soname bump was not announced, as it is supposed
> to
> be, and dependent packages were not rebuilt.
> 
> opendnssec depends on libldns and freeipa-server-dns requires
> opendnssec, so this resulted in FreeIPA server deployment - which is
> a
> core Fedora Server feature, and in the Alpha release requirements -
> breaking on both 26 and Rawhide.
> 
> We will now need to go through the blocker process to have the
> opendnssec rebuild pulled into Fedora 26 composes, as this
> unannounced
> soname bump landed right before the Alpha freeze.
> 
> Other packages that depend on libldns appear to be dnssec-trigger and
> netresolve. dnssec-trigger has been rebuilt (but will need to go
> through the blocker or FE process to make it into 26 Alpha),
> netresolve
> has not, yet. I will try to rebuild netresolve.
> 
> Once again, folks, *please* announce your soname bumps, and co-
> ordinate 
> rebuilds.

Can we simply have a mechanism that blocks packages from going through
if a soname bump id detected and an appropriate bugzilla with a
specific keyword of SONAMEBUMP is not present, or something like that ?

This would force maintainers to pay attention and coordinate perhaps ?

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

Re: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> libldns.so.2)

2017-03-14 Thread Dan Horák 
On Tue, 14 Mar 2017 06:35:17 -0400
Simo Sorce  wrote:

> On Thu, 2017-03-09 at 15:10 -0800, Adam Williamson wrote:
> > ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26 on
> > 2017-03-06. This update bumped the soname from libldns.so.1 to
> > libldns.so.2 . This soname bump was not announced, as it is supposed
> > to
> > be, and dependent packages were not rebuilt.
> > 
> > opendnssec depends on libldns and freeipa-server-dns requires
> > opendnssec, so this resulted in FreeIPA server deployment - which is
> > a
> > core Fedora Server feature, and in the Alpha release requirements -
> > breaking on both 26 and Rawhide.
> > 
> > We will now need to go through the blocker process to have the
> > opendnssec rebuild pulled into Fedora 26 composes, as this
> > unannounced
> > soname bump landed right before the Alpha freeze.
> > 
> > Other packages that depend on libldns appear to be dnssec-trigger
> > and netresolve. dnssec-trigger has been rebuilt (but will need to go
> > through the blocker or FE process to make it into 26 Alpha),
> > netresolve
> > has not, yet. I will try to rebuild netresolve.
> > 
> > Once again, folks, *please* announce your soname bumps, and co-
> > ordinate 
> > rebuilds.
> 
> Can we simply have a mechanism that blocks packages from going through
> if a soname bump id detected and an appropriate bugzilla with a
> specific keyword of SONAMEBUMP is not present, or something like
> that ?
> 
> This would force maintainers to pay attention and coordinate perhaps ?

the existing libabigail taskotron task should be able to help here


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

Re: [Help Wanted] PPC64LE build for thrift

2017-03-14 Thread Christopher 
On Tue, Mar 14, 2017 at 3:26 AM Dan Horák  wrote:

> On Tue, 14 Mar 2017 01:10:32 +
> Christopher  wrote:
>
> > Hi,
> >
> > I'm trying to build the latest version of thrift, and am running into
> > a problem with one of the build tests, which has a dependency on
> > boost-static for "%{_libdir}/libboost_unit_test_framework.a"
> >
> > I really have no expertise with PPC at all, and also very limited
> > knowledge of autotools, but it looks like it's looking in the wrong
> > libdir on PPC64LE.
> >
> > Any help would be much appreciated.
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=18366919
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=18366921
>
> g++: error: /usr/lib/libboost_unit_test_framework.a: No such file or
> directory
>
> the thrift  buildsystem doesn't treat ppc64le as a 64-bit arch
> with /usr/lib64, probably there is a hard-coded list of arches ...
>
>

Thanks! I looked for a list of hard-coded arches (I wasn't expecting
upstream to be doing that), filed an upstream bug, and fixed the package:
https://issues.apache.org/jira/browse/THRIFT-4122


>
> Dan
> ___
> 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: Packages dropping anything in /etc/systemd/system

2017-03-14 Thread Daniel P. Berrange 
On Tue, Mar 14, 2017 at 06:31:46AM -0400, Simo Sorce wrote:
> Hello,
> as per subject, what is the stance on dropping anything there from a
> rpm ? Either marked as %{config} or not ?
> 
> My naive reading of the Packaging guidelines is that nothing should be
> dropped in there by a package, but the guidelines only explicitly talk
> about not putting "service" files in there.

The packaging guidelines actually use 'unit file' as the term

  https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations

  "Packages with systemd unit files *must* put them into %{_unitdir}. 
   %{_unitdir} evaluates to /lib/systemd/system"

From that I'd say any RPM putting unit files into /etc/systemd/system is
not compliant, regardless of whether its a full unit file, or a override
unit file in a '.d' directory.

> There is now a debate with a package maintainer that is putting in the
> etc/systemd/system/<..> directory what he calls a "configuration file,
> not a unit file".

A unit file provides configuration for a service (or other type of
systemd resource). So saying 'configuration file, not a unit file'
doesn't make conceptual sense - they're one & the same thing.

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

Intent to retire fleet in F-27 (F-26?)

2017-03-14 Thread Peter Lemenkov 
Hello All!
Upstream decided to abandon fleet in favor of Kubernetes:

* https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html

I believe we should do the same and retire it. I'll mark it as retired
this weekend (18-19 March).

-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> libldns.so.2)

2017-03-14 Thread Simo Sorce 
On Tue, 2017-03-14 at 11:39 +0100, Dan Horák wrote:
> On Tue, 14 Mar 2017 06:35:17 -0400
> Simo Sorce  wrote:
> 
> > On Thu, 2017-03-09 at 15:10 -0800, Adam Williamson wrote:
> > > ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26
> > > on
> > > 2017-03-06. This update bumped the soname from libldns.so.1 to
> > > libldns.so.2 . This soname bump was not announced, as it is
> > > supposed
> > > to
> > > be, and dependent packages were not rebuilt.
> > > 
> > > opendnssec depends on libldns and freeipa-server-dns requires
> > > opendnssec, so this resulted in FreeIPA server deployment - which
> > > is
> > > a
> > > core Fedora Server feature, and in the Alpha release requirements
> > > -
> > > breaking on both 26 and Rawhide.
> > > 
> > > We will now need to go through the blocker process to have the
> > > opendnssec rebuild pulled into Fedora 26 composes, as this
> > > unannounced
> > > soname bump landed right before the Alpha freeze.
> > > 
> > > Other packages that depend on libldns appear to be dnssec-trigger
> > > and netresolve. dnssec-trigger has been rebuilt (but will need to
> > > go
> > > through the blocker or FE process to make it into 26 Alpha),
> > > netresolve
> > > has not, yet. I will try to rebuild netresolve.
> > > 
> > > Once again, folks, *please* announce your soname bumps, and co-
> > > ordinate 
> > > rebuilds.
> > 
> > Can we simply have a mechanism that blocks packages from going
> > through
> > if a soname bump id detected and an appropriate bugzilla with a
> > specific keyword of SONAMEBUMP is not present, or something like
> > that ?
> > 
> > This would force maintainers to pay attention and coordinate
> > perhaps ?
> 
> the existing libabigail taskotron task should be able to help here

Yeah I had that in mind, we can detect this, I guess the harder part is
 to tell the composer "it's ok, we handled it", unless perhaps a soname
bump causes automatically to create a build target that tries to
rebuild all the recorded dependencies and gives the green light (or
files bugs) if everything rebuilds fine ?

Just an idea...

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

Self Introduction: Xavier Delaruelle

2017-03-14 Thread xavier.delarue...@cea.fr 
Dear Fedora developers,

My name is Xavier and I would like to introduce myself. I am French and
I work in a computing center at CEA, near Paris. I am 35 years old and I
work as a system administrator of supercomputers since 12 years. I use
Fedora since its first release and all the machines in our computing
center are based on RedHat-like distribution (EL or CentOS).

Among others, I currently maintain the Modules-Tcl software. This
software is part of the Environment Modules project
(http://modules.sourceforge.net/) which provides for the dynamic
modification of a user's environment via modulefiles.

Typically users initialize their environment when they log in by setting
environment information for every application they will reference during
the session. The Environment Modules package is a tool that simplify
shell initialization and lets users easily modify their environment
during the session with modulefiles.

This Environment Modules project has two sides. A C version, well known
and already part of the Fedora distribution through the
"environment-modules" package. And a native Tcl version, Modules-Tcl,
which is a full rewrite of the C version that handles same kind of
modulefiles and command-line syntax. The C version does not evolve much
in the last years whereas Modules-Tcl is in an active development state
(fixes, new features, etc).

So I would like to apply as package maintainer in the Fedora project in
order to provide and maintain a package for Modules-Tcl. My review
request for this package can be found at:

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

I am looking forward being sponsored and having Modules-Tcl part of
Fedora. :)

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

Re: Review Swaps: (mostly) very simple golang packages

2017-03-14 Thread Athos Ribeiro 
On Mon, Mar 13, 2017 at 10:52:06PM +, Fabio Valentini wrote:
> 
> 1) golang-github-edsrzf-mmap-go - Portable mmap package for Go
> https://bugzilla.redhat.com/show_bug.cgi?id=1431568

This is duplicated (closed)

> 
> 2) golang-github-cznic-mathutil - Supplemental utilities for Go's rand and
> math packages
> https://bugzilla.redhat.com/show_bug.cgi?id=1431587

This is duplicated (closed)

> 
> 3) golang-github-oschwald-maxminddb-golang - MaxMind DB Reader for Go
> https://bugzilla.redhat.com/show_bug.cgi?id=1431759

I took this one

> 5) golang-github-zillode-notify - File system event notification library on
> steroids
> https://bugzilla.redhat.com/show_bug.cgi?id=1431867

I took this one as well


Would you be able to review these packages (simple golang packages as
well)?

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

-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Voice recognition packages need a new maintainer

2017-03-14 Thread Peter Robinson 
On Tue, Mar 14, 2017 at 2:35 AM, Jerry James  wrote:
> Hello everybody,
>
> I am the primary point of contact for a handful of voice
> recognition-related packages:
> - cmusphinx3
> - irstlm
> - openfst
> - opengrm-ngram
> - pocketsphinx
> - sphinxbase
> - sphinxtrain
>
> I have not used these packages myself for quite some time, and am
> unlikely to start using them again anytime soon, so I think a new
> primary point of contact is appropriate.  I do get the occasional bug
> report, as well as the occasional email thanking me for keeping these
> packages in Fedora, so they do have users.
>
> All of them are up to date with their latest released versions,
> although the CMU Sphinx packages go years in between releases, so some
> distributions track the upstream SCM instead of sticking to releases.
>
> If you are interested in picking up these packages, let me know.  If
> you are interested, but not a packager, let me know anyway.

You can assign pocketsphinx and it's dep sphinxbase to me as I need
them for a project I'm investigating ATM.

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

revelation password manager depends on orphaned libgnome-media-profiles

2017-03-14 Thread Globe Trotter 
Hello,
I have been getting notices about revelation being impacted by the orphaning of 
libgnome-media-profiles which impacts gnome-python2-desktop.
I do not use gnome or a desktop and I was wondering what would be the best 
course in rebuilding this password manager. 

Thank you.aarem

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

Re: Packages dropping anything in /etc/systemd/system

2017-03-14 Thread Neil Horman 
On Tue, Mar 14, 2017 at 06:31:46AM -0400, Simo Sorce wrote:
> Hello,
> as per subject, what is the stance on dropping anything there from a
> rpm ? Either marked as %{config} or not ?
> 
> My naive reading of the Packaging guidelines is that nothing should be
> dropped in there by a package, but the guidelines only explicitly talk
> about not putting "service" files in there.
> 
> There is now a debate with a package maintainer that is putting in the
> etc/systemd/system/<..> directory what he calls a "configuration file,
> not a unit file".
> 
> I seek clarification about this so that we can settle this matter.
> 
> Regards,
> Simo.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Given that the packaging guidelines are vague, I'd say theres nothing that
explicitly prevents him from adding configuration there.  That said, it seems to
make very little sense to do so, given that there is no precident, and there is
lots of precident for alternate locations (environment settings should go in
/etc/sysconfig, i.e. %sysconfdir, application specific settings in private
/etc/ subdirectory, and so on).  At the very least I would argue that
configuration in /etc/systemd should be configuration specific to the systemd
daemon (see the various *.conf files there), and stuff under .../system is
clearly for the placement of unit files.  Adding non-unit files to that location
just makes systemd have to iterate longer when reloading units as it scans the
directory there.

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

Re: Packages dropping anything in /etc/systemd/system

2017-03-14 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Mar 14, 2017 at 10:50:57AM +, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 06:31:46AM -0400, Simo Sorce wrote:
> > Hello,
> > as per subject, what is the stance on dropping anything there from a
> > rpm ? Either marked as %{config} or not ?
> > 
> > My naive reading of the Packaging guidelines is that nothing should be
> > dropped in there by a package, but the guidelines only explicitly talk
> > about not putting "service" files in there.
> 
> The packaging guidelines actually use 'unit file' as the term
> 
>   https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations
> 
>   "Packages with systemd unit files *must* put them into %{_unitdir}. 
>%{_unitdir} evaluates to /lib/systemd/system"
> 
> From that I'd say any RPM putting unit files into /etc/systemd/system is
> not compliant, regardless of whether its a full unit file, or a override
> unit file in a '.d' directory.

Exactly. Distro packages putting files in /etc/systemd is also contrary
to systemd logic (/usr/lib is for packaging, /etc is for the admin).
Everything which can be put underneath /etc/systemd/system can be put under
/usr/lib/systemd/system also.

This nicely avoids any questions about %config vs %config(noreplace) vs.
anything else.

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

Re: revelation password manager depends on orphaned libgnome-media-profiles

2017-03-14 Thread Stephen John Smoogen 
I would start with trying to build the software without that include.
If it can't be done I would try and contact the upstream. Since the
code has not had a release since 2012, I expect it is 'dead' so there
may not be any fixes unless you dive into the code to fix the
requirements yourself.

On 14 March 2017 at 09:08, Globe Trotter  wrote:
> Hello,
>
> I have been getting notices about revelation being impacted by the orphaning
> of libgnome-media-profiles which impacts gnome-python2-desktop.
>
> I do not use gnome or a desktop and I was wondering what would be the best
> course in rebuilding this password manager.
>
> Thank you.
> aarem
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

Re: Self Introduction: Milovidov Mikhail

2017-03-14 Thread Zbigniew Jędrzejewski-Szmek 
On Thu, Mar 09, 2017 at 11:58:15AM +0300, Михаил Миловидов wrote:
> Hello all!
> I'm a Software Developer and I want to add my utility to the Fedora
> repository.
> The utility is helpfull for me and my collegues (testers and developers) to
> obtain data from multiple servers simultaniosly via ssh commands.
> 
> My review request - https://bugzilla.redhat.com/show_bug.cgi?id=1429226.
> Project url - https://bitbucket.org/milovidov/dataagregatorproject

Hi Михаил,

welcome! Please consider participating in the community, comment
on other reviews of new packages, look at bugs, test packages, etc.
This will help you get acquainted with the processes and people and
to take your package through review.

You didn't write too much about yourself. What are your
areas-of-expertise / interests / strengths?

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

[HEADS UP] udisks 2.6.4 released, replacing storaged

2017-03-14 Thread Vojtěch Trefný 
Hi, we released a new version of the udisks storage management daemon. 
The biggest news is actually the name itself -- udisks was replaced by 
storaged in Fedora 25[1] but since then we have agreed with udisks 
maintainer on merging both projects back (storaged was originally fork 
of udisks) using the original name 'udisks'. This is the first release 
of 'storaged' using the old 'udisks' name[2].


We will also retire the storaged package and use the 'old' udisks2 
package for Fedora starting with this release. Only cockpit currently 
depends on the storaged package, other projects still depend on the 
udisks2 package (which had been provided by the storaged  package), so 
this change won't affect them.


The 2.6.4 release contains numerous bugfixes and a lot of new tests. For 
full list of changes visit our GitHub[3].


--
[1] https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged
[2] https://github.com/storaged-project/udisks/pull/191
[3] https://github.com/storaged-project/udisks/blob/master/NEWS
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken dependencies: perl-ZMQ-LibZMQ2

2017-03-14 Thread buildsys 


perl-ZMQ-LibZMQ2 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZMQ-LibZMQ2-1.09-9.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZMQ-LibZMQ2-1.09-9.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

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

Re: revelation password manager depends on orphaned libgnome-media-profiles

2017-03-14 Thread Yaakov Selkowitz 

On 2017-03-14 08:08, Globe Trotter wrote:

I have been getting notices about revelation being impacted by the
orphaning of libgnome-media-profiles which impacts gnome-python2-desktop.

I do not use gnome or a desktop and I was wondering what would be the
best course in rebuilding this password manager.


gnome-python2-desktop was only required when the GNOME 2 panel applet is 
enabled.  Obviously that is no longer applicable, so just add 
--without-applet to %configure and drop the "BuildRequires: 
gnome-python2-extras gnome-python2-desktop".


--
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Help Wanted] PPC64LE build for thrift

2017-03-14 Thread Tomasz Kłoczko 
On 14 March 2017 at 07:24, Dan Horák  wrote:

> g++: error: /usr/lib/libboost_unit_test_framework.a: No such file or
> directory
>
> the thrift  buildsystem doesn't treat ppc64le as a 64-bit arch
> with /usr/lib64, probably there is a hard-coded list of arches ...
>

Despite such simple to fix bug using static libraries should be removed.

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

Upcoming BackupPC 4.0

2017-03-14 Thread Richard Shaw 
BackupPC 4.0 has been released but there major changes that prevent a
seamless upgrade and some new dependencies that are not in Fedora.

With version 4.0 hard links are no longer used for deduplication and
instead attribute files are stored in each directory.

While 4.0 is backwards compatible with 3.X backups there are some client
side configuration changes that may cause problems.

Additionally there are two new requirements:

rsync-bpc - A fork of rsync to speed up the previous perl based version in
3.X that has added capabilities needed for BackupPC

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

BackupPC-XS - Several BackupPC functions in a perl module

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

My plan is to get both of these packages in f26 and rawhide and upgrade
both branches to 4.0.

If there is enough demand I may also create a BackupPC-4 package for F25
and EPEL 6 & 7 so those that want to upgrade can choose to do so.

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

Re: Different icu from upstream

2017-03-14 Thread Marek Skalický 
So there are no Fedora requirements/recommendations about this?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> libldns.so.2)

2017-03-14 Thread Dennis Gilmore 
On Tue, 2017-03-14 at 06:35 -0400, Simo Sorce wrote:
> On Thu, 2017-03-09 at 15:10 -0800, Adam Williamson wrote:
> > ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26 on
> > 2017-03-06. This update bumped the soname from libldns.so.1 to
> > libldns.so.2 . This soname bump was not announced, as it is
> > supposed
> > to
> > be, and dependent packages were not rebuilt.
> > 
> > opendnssec depends on libldns and freeipa-server-dns requires
> > opendnssec, so this resulted in FreeIPA server deployment - which
> > is
> > a
> > core Fedora Server feature, and in the Alpha release requirements -
> > breaking on both 26 and Rawhide.
> > 
> > We will now need to go through the blocker process to have the
> > opendnssec rebuild pulled into Fedora 26 composes, as this
> > unannounced
> > soname bump landed right before the Alpha freeze.
> > 
> > Other packages that depend on libldns appear to be dnssec-trigger
> > and
> > netresolve. dnssec-trigger has been rebuilt (but will need to go
> > through the blocker or FE process to make it into 26 Alpha),
> > netresolve
> > has not, yet. I will try to rebuild netresolve.
> > 
> > Once again, folks, *please* announce your soname bumps, and co-
> > ordinate 
> > rebuilds.
> 
> Can we simply have a mechanism that blocks packages from going
> through
> if a soname bump id detected and an appropriate bugzilla with a
> specific keyword of SONAMEBUMP is not present, or something like that
> ?

We are trying to address it in 
https://fedoraproject.org/wiki/Changes/NoMoreAlpha

Dennis

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: iproute package update policy

2017-03-14 Thread Phil Sutter 
Hi,

On Mon, Mar 14, 2016 at 12:47:25PM +0100, Phil Sutter wrote:
> So far my idea of maintaining Fedora's iproute package was to do full
> version updates only in Rawhide and backport patches selectively to
> stable versions on behalf of bug reports.
> 
> But since stable versions indeed receive full kernel updates (not just
> backported patches), there is an understandable amount of frustration
> amongst users when the shiny new kernel that comes with e.g. F22
> provides features userspace does not support.
> 
> Especially since upstream iproute2 does not really have a concept of
> stable versions, I'm in a bit of a dilemma here: update to keep in sync
> with the kernel or not update to not unnecessarily destabilize the
> system?
> 
> Any comments/advice are highly appreciated.

I have been asked by various people why I don't update iproute in stable
releases to match the shipped kernel version and then had a longer
brainstorming with Lubomir about how to limit the involved risks.

My plan is to indeed do the updates, but I will adjust karma thresholds
to very conservative values for them. I'm thinking about having a stable
threshold of 10 and and unstable one of -1 to enforce a longer review
time and have the process fail early in case problems occur.

Please drop me a note if you have strong feelings against this.

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

Re: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> libldns.so.2)

2017-03-14 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Mar 14, 2017 at 06:35:17AM -0400, Simo Sorce wrote:
> On Thu, 2017-03-09 at 15:10 -0800, Adam Williamson wrote:
> > ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26 on
> > 2017-03-06. This update bumped the soname from libldns.so.1 to
> > libldns.so.2 . This soname bump was not announced, as it is supposed
> > to
> > be, and dependent packages were not rebuilt.
> > 
> > opendnssec depends on libldns and freeipa-server-dns requires
> > opendnssec, so this resulted in FreeIPA server deployment - which is
> > a
> > core Fedora Server feature, and in the Alpha release requirements -
> > breaking on both 26 and Rawhide.
> > 
> > We will now need to go through the blocker process to have the
> > opendnssec rebuild pulled into Fedora 26 composes, as this
> > unannounced
> > soname bump landed right before the Alpha freeze.
> > 
> > Other packages that depend on libldns appear to be dnssec-trigger and
> > netresolve. dnssec-trigger has been rebuilt (but will need to go
> > through the blocker or FE process to make it into 26 Alpha),
> > netresolve
> > has not, yet. I will try to rebuild netresolve.
> > 
> > Once again, folks, *please* announce your soname bumps, and co-
> > ordinate 
> > rebuilds.
> 
> Can we simply have a mechanism that blocks packages from going through
> if a soname bump id detected and an appropriate bugzilla with a
> specific keyword of SONAMEBUMP is not present, or something like that ?
There's also the old school technique of specifying the soname in %files:

%global somajor 11
%global sominor 2.3
%files
%_libdir/lib%name.so.%soversion.%sominor
%_libdir/lib%name.so.%soversion
%files devel
%_libdir/lib%name.so

And then one cannot do an announcement so-bump by mistake.

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

Re: Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages

2017-03-14 Thread Michael Catanzaro 
On Mon, 2017-01-23 at 07:35 -0600, Michael Catanzaro wrote:
> Hi,
> 
> This is a reminder that the webkitgtk and webkitgtk3 packages will be
> retired from rawhide shortly after F26 is branched from rawhide. This
> is due to numerous security issues affecting those packages (I just
> counted 204 CVEs), many of which could allow remote code execution.
> Bugs have already been filed against all directly-affected packages
> [1].

Hi,

This is now complete in rawhide. The packages have *not* been retired
from F26, so if this broke your package you have the rest of the F27
development cycle to decide how to handle it. The best option is to
port to the modern webkitgtk4 package, but alternatively you could try
bundling older WebKit with your package.

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

Re: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> libldns.so.2)

2017-03-14 Thread Stephen Gallagher 
On 03/14/2017 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 14, 2017 at 06:35:17AM -0400, Simo Sorce wrote:
>> On Thu, 2017-03-09 at 15:10 -0800, Adam Williamson wrote:
>>> ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26 on
>>> 2017-03-06. This update bumped the soname from libldns.so.1 to
>>> libldns.so.2 . This soname bump was not announced, as it is supposed
>>> to
>>> be, and dependent packages were not rebuilt.
>>>
>>> opendnssec depends on libldns and freeipa-server-dns requires
>>> opendnssec, so this resulted in FreeIPA server deployment - which is
>>> a
>>> core Fedora Server feature, and in the Alpha release requirements -
>>> breaking on both 26 and Rawhide.
>>>
>>> We will now need to go through the blocker process to have the
>>> opendnssec rebuild pulled into Fedora 26 composes, as this
>>> unannounced
>>> soname bump landed right before the Alpha freeze.
>>>
>>> Other packages that depend on libldns appear to be dnssec-trigger and
>>> netresolve. dnssec-trigger has been rebuilt (but will need to go
>>> through the blocker or FE process to make it into 26 Alpha),
>>> netresolve
>>> has not, yet. I will try to rebuild netresolve.
>>>
>>> Once again, folks, *please* announce your soname bumps, and co-
>>> ordinate 
>>> rebuilds.
>>
>> Can we simply have a mechanism that blocks packages from going through
>> if a soname bump id detected and an appropriate bugzilla with a
>> specific keyword of SONAMEBUMP is not present, or something like that ?
> There's also the old school technique of specifying the soname in %files:
> 
> %global somajor 11
> %global sominor 2.3
> %files
> %_libdir/lib%name.so.%soversion.%sominor
> %_libdir/lib%name.so.%soversion
> %files devel
> %_libdir/lib%name.so
> 
> And then one cannot do an announcement so-bump by mistake.
> 

The libabigail approach would be more versatile, though. Mostly because
upstreams don't always remember to bump soname when they break compatibility.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages dropping anything in /etc/systemd/system

2017-03-14 Thread Remi Collet 
Le 14/03/2017 à 11:31, Simo Sorce a écrit :
> Hello,
> as per subject, what is the stance on dropping anything there from a
> rpm ? Either marked as %{config} or not ?

s/anything/any file/

Some packages own directories there as it is the right place to drop
additional configuration options.

e.g. rpm -ql php-fpm | grep /etc/systemd
/etc/systemd/system/php-fpm.service.d

And perhaps we could own (%ghost) the override.conf file


Remi


P.S. this directory wad added, because of comments in deprecated
/etc/sysconfig/php-fpm about dropping a file there, now mostly replaced
by a comment about using "systemctl edit" command.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Help Wanted] PPC64LE build for thrift

2017-03-14 Thread Christopher 
On Tue, Mar 14, 2017 at 11:18 AM Tomasz Kłoczko 
wrote:

>
> On 14 March 2017 at 07:24, Dan Horák  wrote:
>
> g++: error: /usr/lib/libboost_unit_test_framework.a: No such file or
> directory
>
> the thrift  buildsystem doesn't treat ppc64le as a 64-bit arch
> with /usr/lib64, probably there is a hard-coded list of arches ...
>
>
> 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 accept your help patching what upstream is doing to move
from boost-static to boost-test (I'm not sufficiently knowledgeable about
C/C++ tooling to switch on my own), but since the dependency is limited to
unit testing during the build, I think it's probably fine.


> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Milovidov Mikhail

2017-03-14 Thread Михаил Миловидов 
Hi Zbyszek,

thank you for attention!
As I said before, I'm a software developer, and my main areas-of-expertise
are Qt cross-platform applications and c++ network servers. Also I
interesting in ruby language.
I think, that my main strength is simple solutions, such as DataAgregator
utility :)

2017-03-14 17:21 GMT+03:00 Zbigniew Jędrzejewski-Szmek :

> On Thu, Mar 09, 2017 at 11:58:15AM +0300, Михаил Миловидов wrote:
> > Hello all!
> > I'm a Software Developer and I want to add my utility to the Fedora
> > repository.
> > The utility is helpfull for me and my collegues (testers and developers)
> to
> > obtain data from multiple servers simultaniosly via ssh commands.
> >
> > My review request - https://bugzilla.redhat.com/show_bug.cgi?id=1429226.
> > Project url - https://bitbucket.org/milovidov/dataagregatorproject
>
> Hi Михаил,
>
> welcome! Please consider participating in the community, comment
> on other reviews of new packages, look at bugs, test packages, etc.
> This will help you get acquainted with the processes and people and
> to take your package through review.
>
> You didn't write too much about yourself. What are your
> areas-of-expertise / interests / strengths?
>
> Best,
> Zbyszek
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

gdm processes

2017-03-14 Thread Tomasz Kłoczko 
Hi,

Just started looking why in lat few weeks my gnome desktop los a lot of its
previous speed. I found that already it is consequence of some issues in
last chrome. Seems chrome developers managed to kill few most annoying
memory leaks causing that time to time crome processes associated with some
tabs age exploding consuming +2GB memory.
Despite this I found some fact that I was not aware about GDM.
Theoretically GDM should provide just application running on top of raw
X11/Wayland diplay to provide authentication service.I remember that few
years ago it was really like this but seems not it is no longer so simple
picture.
Just simple ps output:

$ ps auxwf| grep ^gdm*gdm*   2097  0.0  0.0 428140  4220 tty1
Ssl+ Mar12   0:00  |   \_ /usr/libexec/gdm-wayland-session
gnome-session --autostart /usr/share/gdm/greeter/autostart*gdm*
2102  0.0  0.0 672184  4320 tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gnome-session-binary --autostart
/usr/share/gdm/greeter/autostart*gdm*   2109  0.0  0.6 2657052
49872 tty1Sl+  Mar12   1:17  |   \_
/usr/bin/gnome-shell*gdm*   2183  0.0  0.0 260800  7864 tty1
Sl+  Mar12   0:00  |   |   \_ /usr/bin/Xwayland :1024
-rootless -noreset -listen 4 -listen 5 -displayfd 6*gdm*   
0.0  0.0 459832  3752 tty1 Sl   Mar12   0:01  |   |   \_
ibus-daemon --xim --panel disable*gdm*   2225  0.0  0.0 382688
3348 tty1 Sl   Mar12   0:00  |   |   \_
/usr/libexec/ibus-dconf*gdm*   2298  0.0  0.0 308892  2732 tty1
 Sl   Mar12   0:00  |   |   \_
/usr/libexec/ibus-engine-simple*gdm*   2238  0.0  0.0 364388  3072
tty1 Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-sound*gdm*
  2241  0.0  0.0 481768  6540 tty1 Sl+  Mar12   0:00  |
   \_ /usr/libexec/gsd-wacom*gdm*   2242  0.0  0.0 477592  6692
tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-xsettings*gdm*   2246  0.0  0.0 483812  6660 tty1
Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-a11y-keyboard*gdm*   2247  0.0  0.0 326508  2712
tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-a11y-settings*gdm*   2248  0.0  0.0 475136  6580
tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-clipboard*gdm*   2249  0.0  0.0 729808  7220 tty1
Sl+  Mar12   0:20  |   \_ /usr/libexec/gsd-color*gdm*
 2250  0.0  0.0 362740  2776 tty1 Sl+  Mar12   0:00  |
\_ /usr/libexec/gsd-datetime*gdm*   2254  0.0  0.0 557560  6376
tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-housekeeping*gdm*   2255  0.0  0.0 557756  6868
tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-keyboard*gdm*   2256  0.0  0.0 537876  6520 tty1
   Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-media-keys*gdm*
 2257  0.0  0.0 326512  2612 tty1 Sl+  Mar12   0:00  |
  \_ /usr/libexec/gsd-mouse*gdm*   2261  0.0  0.0 326508  2728
tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-orientation*gdm*   2262  0.0  0.0 578980  6408
tty1 Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-power*gdm*
  2267  0.0  0.0 521884  6540 tty1 Sl+  Mar12   0:00  |
   \_ /usr/libexec/gsd-print-notifications*gdm*   2268  0.0  0.0
326524  3352 tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-rfkill*gdm*   2269  0.0  0.0 400248  3020 tty1
 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-screensaver-proxy*gdm*   2270  0.0  0.0 157972
3288 tty1 Sl+  Mar12   0:00  |   \_
/usr/libexec/gsd-sharing*gdm*   2278  0.0  0.0 345124  2772 tty1
  Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-smartcard*gdm*
   2280  0.0  0.0 483980  6444 tty1 Sl+  Mar12   0:00  |
\_ /usr/libexec/gsd-xrandr*gdm*   2906  0.0  0.1 188904  8344 tty1
S+   Mar12   0:00  |   \_
/usr/libexec/gnome-session-failed*gdm*   1927  0.0  0.0  74532
1608 ?Ss   Mar12   0:00 /usr/lib/systemd/systemd --user*gdm*
2090  0.0  0.0 250440   440 ?SMar12   0:00  \_
(sd-pam)*gdm*   2100  0.0  0.0  49104  2680 ?Ss   Mar12
0:00  \_ /usr/bin/dbus-daemon --session --address=systemd: --nofork
--nopidfile --systemd-activation --syslog-only*gdm*   2190  0.0
0.0 344848  3208 ?Ssl  Mar12   0:00  \_
/usr/libexec/at-spi-bus-launcher*gdm*   2195  0.0  0.0  48800
2628 ?SMar12   0:00  |   \_ /bin/dbus-daemon
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork
--print-address 3*gdm*   2197  0.0  0.0 223708  3720 ?Sl
Mar12   0:00  \_ /usr/libexec/at-spi2-registryd
--use-gnome-session*gdm*   2368  0.0  0.0 187540  2924 ?Sl
  Mar12   0:00  \_ /usr/libexec/dconf-service*gdm*   2203  0.0
0.0 985696  3872 ?Sl   Mar12   0:00 /usr/bin/pulseaudio
--start --log-target=syslog*gdm*   2228  0.0  0.0 482088  6724
tty1 Sl   Mar12   0:00 /usr/libexec/ibus-x11 --kill-daemon

shows that gdm user is running whole set of processes running in full
separated X/Wayland sess

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

2017-03-14 Thread Igor Gnatenko 
> The following comment has been added to the beignet-1.3.0-4.fc25
> clang-3.9.1-1.fc25 compiler-rt-3.9.1-1.fc25 gnome-builder-3.22.4-
> 2.fc25 kdevelop-5.0.4-3.fc25 lldb-3.9.1-1.fc25 llvm-3.9.1-1.fc25
> mesa-13.0.4-2.fc25 pocl-0.14-0.3.git3fef5b5.fc25 qt-creator-4.1.0-
> 2.fc25.2 rust-1.15.1-1.fc25.3 update:
> 
> bodhi - 2017-03-14 17:23:50.280569 (karma: 0)
> This update has been pushed to stable.
Why it got pushed to stable?
* gnome-builder now has broken dependencies which is not acceptable
* F25->F26 upgradepath is broken
>   https://bodhi.fedoraproject.org/updates/FEDORA-2017-82d76412cf
> 
-- 
-Igor Gnatenko

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: gdm processes

2017-03-14 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Mar 14, 2017 at 06:37:05PM +, Tomasz Kłoczko wrote:
> Hi,
> 
> Just started looking why in lat few weeks my gnome desktop los a lot of its
> previous speed. I found that already it is consequence of some issues in
> last chrome. Seems chrome developers managed to kill few most annoying
> memory leaks causing that time to time crome processes associated with some
> tabs age exploding consuming +2GB memory.
> Despite this I found some fact that I was not aware about GDM.
> Theoretically GDM should provide just application running on top of raw
> X11/Wayland diplay to provide authentication service.I remember that few
> years ago it was really like this but seems not it is no longer so simple
> picture.
> Just simple ps output:
> 
> $ ps auxwf| grep ^gdm*gdm*   2097  0.0  0.0 428140  4220 tty1
> Ssl+ Mar12   0:00  |   \_ /usr/libexec/gdm-wayland-session
> gnome-session --autostart /usr/share/gdm/greeter/autostart*gdm*
> 2102  0.0  0.0 672184  4320 tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gnome-session-binary --autostart
> /usr/share/gdm/greeter/autostart*gdm*   2109  0.0  0.6 2657052
> 49872 tty1Sl+  Mar12   1:17  |   \_
> /usr/bin/gnome-shell*gdm*   2183  0.0  0.0 260800  7864 tty1
> Sl+  Mar12   0:00  |   |   \_ /usr/bin/Xwayland :1024
> -rootless -noreset -listen 4 -listen 5 -displayfd 6*gdm*   
> 0.0  0.0 459832  3752 tty1 Sl   Mar12   0:01  |   |   \_
> ibus-daemon --xim --panel disable*gdm*   2225  0.0  0.0 382688
> 3348 tty1 Sl   Mar12   0:00  |   |   \_
> /usr/libexec/ibus-dconf*gdm*   2298  0.0  0.0 308892  2732 tty1
>  Sl   Mar12   0:00  |   |   \_
> /usr/libexec/ibus-engine-simple*gdm*   2238  0.0  0.0 364388  3072
> tty1 Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-sound*gdm*
>   2241  0.0  0.0 481768  6540 tty1 Sl+  Mar12   0:00  |
>\_ /usr/libexec/gsd-wacom*gdm*   2242  0.0  0.0 477592  6692
> tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-xsettings*gdm*   2246  0.0  0.0 483812  6660 tty1
> Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-a11y-keyboard*gdm*   2247  0.0  0.0 326508  2712
> tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-a11y-settings*gdm*   2248  0.0  0.0 475136  6580
> tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-clipboard*gdm*   2249  0.0  0.0 729808  7220 tty1
> Sl+  Mar12   0:20  |   \_ /usr/libexec/gsd-color*gdm*
>  2250  0.0  0.0 362740  2776 tty1 Sl+  Mar12   0:00  |
> \_ /usr/libexec/gsd-datetime*gdm*   2254  0.0  0.0 557560  6376
> tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-housekeeping*gdm*   2255  0.0  0.0 557756  6868
> tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-keyboard*gdm*   2256  0.0  0.0 537876  6520 tty1
>Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-media-keys*gdm*
>  2257  0.0  0.0 326512  2612 tty1 Sl+  Mar12   0:00  |
>   \_ /usr/libexec/gsd-mouse*gdm*   2261  0.0  0.0 326508  2728
> tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-orientation*gdm*   2262  0.0  0.0 578980  6408
> tty1 Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-power*gdm*
>   2267  0.0  0.0 521884  6540 tty1 Sl+  Mar12   0:00  |
>\_ /usr/libexec/gsd-print-notifications*gdm*   2268  0.0  0.0
> 326524  3352 tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-rfkill*gdm*   2269  0.0  0.0 400248  3020 tty1
>  Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-screensaver-proxy*gdm*   2270  0.0  0.0 157972
> 3288 tty1 Sl+  Mar12   0:00  |   \_
> /usr/libexec/gsd-sharing*gdm*   2278  0.0  0.0 345124  2772 tty1
>   Sl+  Mar12   0:00  |   \_ /usr/libexec/gsd-smartcard*gdm*
>2280  0.0  0.0 483980  6444 tty1 Sl+  Mar12   0:00  |
> \_ /usr/libexec/gsd-xrandr*gdm*   2906  0.0  0.1 188904  8344 tty1
> S+   Mar12   0:00  |   \_
> /usr/libexec/gnome-session-failed*gdm*   1927  0.0  0.0  74532
> 1608 ?Ss   Mar12   0:00 /usr/lib/systemd/systemd --user*gdm*
> 2090  0.0  0.0 250440   440 ?SMar12   0:00  \_
> (sd-pam)*gdm*   2100  0.0  0.0  49104  2680 ?Ss   Mar12
> 0:00  \_ /usr/bin/dbus-daemon --session --address=systemd: --nofork
> --nopidfile --systemd-activation --syslog-only*gdm*   2190  0.0
> 0.0 344848  3208 ?Ssl  Mar12   0:00  \_
> /usr/libexec/at-spi-bus-launcher*gdm*   2195  0.0  0.0  48800
> 2628 ?SMar12   0:00  |   \_ /bin/dbus-daemon
> --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork
> --print-address 3*gdm*   2197  0.0  0.0 223708  3720 ?Sl
> Mar12   0:00  \_ /usr/libexec/at-spi2-registryd
> --use-gnome-session*gdm*   2368  0.0  0.0 187540  2924 ?Sl
>   Mar12   0:00  \_ /usr/libexec/dconf-service*gdm*   2203  0.0
> 0.0 985696  3872 ?Sl   Mar12   0:00 /usr/bin/pulseaudio

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

2017-03-14 Thread Tomasz Kłoczko 
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 accept your help patching what upstream is doing to move
> from boost-static to boost-test (I'm not sufficiently knowledgeable about
> C/C++ tooling to switch on my own), but since the dependency is limited to
> unit testing during the build, I think it's probably fine.
>

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

(above is against rawhide)
and this is not all because some static libraries are scattered across some
non-static subpackages.

One of the most bizarre IMO static packages is glibc-static.
This package is produced only because (IIRC) binutils in set of tests
executed in %check does some test against linking with -static. However
those tests are not done against some test.a library but thyey wants to use
libc.a.
By this compilation of the glibc package is probably almost two times
longer than it could be.
Some people seems are really trying to follow blindly some processes
defined in some build frameworks without thinking does it make any sense to
follow what was original defined.

For example Solaris 11 userland which is using exactly the the same version
of binutils as current fedora rawhide has disabled these test .. because
Solaris does not provide (at all almost two decades) libc.a and Solaris ABI
guideline does not recommend link any user space programs against static
libraries if it is only possible.

If package like glibc-static will be still propagated to commercial RH
sooner or later it will blow up into the face RH support as some customer
will have some issue with some his own binary linked against some ancient
version of glibc static library still used on some quite fresh distro
resources (a little more than year ago I had case when production Linux
based on OL 6 was still using binary program statically linked 10 years
ago, and yes ..  this binary was even "correctly" packaged into regular rpm
package :) ).

Solutions:

1) Of course get rid of *ALL* -static packages with all roots like this one
in binutils.

2) Probably it would be not so bad to add at the end of rpms package
assembly process print kind of big warning that someone is trying to build
package which will provide static libraries.

3) Another idea of some long term solution consider to implement.
Add in %prep post script checking are any of configure.{in.ac}  files
contains AC_ENABLE_STATIC aclocal macro and recommend push to original
source tree change this to AC_DIABLE_STATIC and/or at least make sure that
in %build in %configure parameters is s used --disable-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: Wrongly handled LLVM update [Fwd: [Fedora Update] [CRITPATH] [comment] llvm-3.9.1-1.fc25]

2017-03-14 Thread Michael Cronenworth 

On 03/14/2017 01:38 PM, Igor Gnatenko wrote:

Why it got pushed to stable?
* gnome-builder now has broken dependencies which is not acceptable
* F25->F26 upgradepath is broken

   https://bodhi.fedoraproject.org/updates/FEDORA-2017-82d76412cf


Hi Igor,

When you see "This update has been submitted for stable by bodhi." and you know the 
update will break things please hit the Unpush button. There needs to be more 
acceptance in action that will prevent broken stable repos. We all get busy and I 
saw this update only yesterday and knew it was going to break, but I didn't have 
time to check on it and now it has reached stable. I'm not extremely alarmed by 
these cases, but it's totally fixable and we should Just Do It.


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

Fedora Rawhide-20170314.n.0 compose check report

2017-03-14 Thread Fedora compose checker 
Missing expected images:

Cloud_base qcow2 x86_64
Server dvd i386
Cloud_base raw-xz x86_64
Server boot i386

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

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

ID: 64663   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/64663
ID: 64701   Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/64701
ID: 64707   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/64707
ID: 64728   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/64728
ID: 64732   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/64732
ID: 64734   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/64734

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

ID: 64640   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/64640
ID: 64642   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/64642
ID: 64659   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/64659
ID: 64662   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/64662
ID: 64666   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/64666
ID: 64680   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/64680
ID: 64733   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/64733

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-20170313.n.0):

ID: 64632   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/64632
ID: 64638   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/64638

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

ID: 64629   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/64629
ID: 64630   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/64630
ID: 64631   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/64631
ID: 64639   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/64639
ID: 64648   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/64648
ID: 64650   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/64650
ID: 64651   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/64651
ID: 64682   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/64682
ID: 64683   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/64683
ID: 64685   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/64685
ID: 64686   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/64686
ID: 64687   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/64687
ID: 64688   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/64688
ID: 64689   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/64689
ID: 64690   Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/64690
ID: 64691   Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/64691
ID: 64692   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/64692
ID: 64693   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/64693
ID: 64694   Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/64694
ID: 64695   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/64695
ID: 64696   Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/64696
ID: 64697   Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/64697
ID: 64698   Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/64698
ID: 64699   Test: x86_64 universal ins

Re: gdm processes

2017-03-14 Thread Michael Catanzaro 
On Tue, 2017-03-14 at 19:39 +, Zbigniew Jędrzejewski-Szmek wrote:
> > Is it really needs to be so complicated?
> 
> Yeah, mostly.

The login screen is a full gnome-shell instance run by the gdm user, as
you see from your process tree, so yes indeed.

The real problem here is the login screen should *really* not be
running when it's not displayed to the user. That's a regression
introduced in Fedora 22 when Wayland support was added:

https://bugzilla.gnome.org/show_bug.cgi?id=747339

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

Re: gdm processes

2017-03-14 Thread Tomasz Kłoczko 
On 14 March 2017 at 19:39, Zbigniew Jędrzejewski-Szmek 
wrote:

> This doesn't show much, after being wrapped ;)
>

OK. Please tell a bit more about what kind of wrapping you been using here
:)

> shows that gdm user is running whole set of processes running in full
> > separated X/Wayland session.
> It's not so bad really. The next-to-last column is cpu time. It's
> completely negligible if you consider that this machine has been up
> since Feb 26. The column before ?/tty1 is RSS, and it's also small.
> gnome-shell is a bit big with 88MB, but that's the price we pay for
> feature-full login screen.
>

As long as gdm user has some possibility to log in to the system other
users I would be really unhappy to discover that some security bug in those
processes was used to login into my system some parasites :)

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

Default permissions on /dev/kvm

2017-03-14 Thread Richard W.M. Jones 
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.

Should we include the qemu udev rule [to make /dev/kvm 0666] in the
base RHEL install?  Or something else?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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)

2017-03-14 Thread Richard W.M. Jones 
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
> > boost-static. If not, why is it even packaged?
> > I'd be happy to accept your help patching what upstream is doing to move
> > from boost-static to boost-test (I'm not sufficiently knowledgeable about
> > C/C++ tooling to switch on my own), but since the dependency is limited to
> > unit testing during the build, I think it's probably fine.
> >
> 
> 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

The problem being what exactly?

> One of the most bizarre IMO static packages is glibc-static.

The problem being what exactly?

> By this compilation of the glibc package is probably almost two times
> longer than it could be.

OK, so we suffer that problem only once (during the glibc build).  But
it's a benefit to have glibc-static because it enables people to build
staticly linked programs.

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.

> If package like glibc-static will be still propagated to commercial RH
> sooner or later it will blow up into the face RH support as some customer
> will have some issue with some his own binary linked against some ancient
> version of glibc static library still used on some quite fresh distro
> resources

It's nice that you're thinking so much about Red Hat and their support
problems, but I think Red Hat can deal with that themselves.  In the
case you describe it wouldn't be a supported configuration and there
would be no support issues.

> Solutions:
> 
> 1) Of course get rid of *ALL* -static packages with all roots like this one
> in binutils.

That's a terrible idea.

> 2) Probably it would be not so bad to add at the end of rpms package
> assembly process print kind of big warning that someone is trying to build
> package which will provide static libraries.

Also a terrible idea.  Static libraries are useful in several
situations, and we should not disable this capability.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

2017-03-14 Thread Richard W.M. Jones 
On Tue, Mar 14, 2017 at 08:09:00PM +, Richard W.M. Jones wrote:
> base RHEL install?  Or something else?

Bleah yes I've been spending too long today doing RHEL security fixes.

I meant of course the base _Fedora_ install.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

2017-03-14 Thread Daniel P. Berrange 
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.

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

2017-03-14 Thread Daniel J Walsh 


On 03/14/2017 04:29 PM, 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.
>
> Regards,
> Daniel
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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

2017-03-14 Thread Dusty Mabe 


On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
> 
> 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.

$user here. 

The problem was real, but I don't know how legitimate the need for
change is. I opened the bug so that we could have a discussion about
it.

Basically as a user that wants to run libvirt inside a container I was
facing issues (permission denied). I noticed randomly that if I had
installed qemu on the host before I tried to run libvirt inside of a
container everything was fine. If I started from a fresh system (no
qemu ever installed on the host) and tried to run that same container,
I could not do it. Cole Robinson helped me track down that it was a
permissions issue on /dev/kvm itself. Then I found the permission
fixup code in the qemu rpm, which led me to think it might be better
to open up the permissions even if qemu is not installed so that
containerized libvirt use cases could succeed without having to
workaround it.

To workaround the person starting the container would need to change
perms on /dev/kvm or have the container do that itself before running
libvirt. I'm just saying that if we put this "hack" in qemu, then it
seems like we might as well have it outside of qemu so that the 'qemu
is delivered by a container' use case can work.

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

2017-03-14 Thread Dusty Mabe 


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

Re: Default permissions on /dev/kvm

2017-03-14 Thread Daniel J Walsh 


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. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 26-20170314.n.0 compose check report

2017-03-14 Thread Fedora compose checker 
Missing expected images:

Atomic qcow2 x86_64
Server dvd i386
Server boot i386
Atomic raw-xz x86_64

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

New failures (same test did not fail in 26-20170312.n.0):

ID: 64840   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/64840
ID: 64859   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/64859
ID: 64862   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/64862
ID: 64884   Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/64884
ID: 64886   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/64886
ID: 64907   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/64907
ID: 64908   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/64908
ID: 64911   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/64911

Old failures (same test failed in 26-20170312.n.0):

ID: 64863   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/64863
ID: 64868   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/64868
ID: 64880   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/64880
ID: 64925   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/64925
ID: 64928   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/64928
ID: 64933   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/64933

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

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

ID: 64830   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/64830
ID: 64831   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/64831
ID: 64832   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/64832
ID: 64838   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/64838
ID: 64839   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/64839
ID: 64848   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/64848
ID: 64850   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/64850
ID: 64851   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/64851
ID: 64893   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/64893
ID: 64897   Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/64897
ID: 64898   Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/64898
ID: 64904   Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/64904
ID: 64905   Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/64905
ID: 64910   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/64910
ID: 64912   Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/64912
ID: 64913   Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/64913
ID: 64917   Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/64917
ID: 64924   Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/64924
ID: 64926   Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/64926
ID: 64929   Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/64929
ID: 64930   Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/64930
ID: 64931   Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/64931
ID: 64936   Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/64936
ID: 64942   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/64942
ID: 64944   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/64944

Old soft fail

Re: Default permissions on /dev/kvm

2017-03-14 Thread Dusty Mabe 


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.

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

Re: gdm processes

2017-03-14 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Mar 14, 2017 at 08:05:20PM +, Tomasz Kłoczko wrote:
> On 14 March 2017 at 19:39, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > This doesn't show much, after being wrapped ;)
> >
> 
> OK. Please tell a bit more about what kind of wrapping you been using here
> :)
In mutt your message appears to be wrapped to ~80 columns. I think mine
is not wrapped, at least it appears this way to me.
But in the web interface, both look the same, bad:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E7WZA3UNFI6PI3KV2SOTB4PEXEBKC2YE/.

> > shows that gdm user is running whole set of processes running in full
> > > separated X/Wayland session.
> > It's not so bad really. The next-to-last column is cpu time. It's
> > completely negligible if you consider that this machine has been up
> > since Feb 26. The column before ?/tty1 is RSS, and it's also small.
> > gnome-shell is a bit big with 88MB, but that's the price we pay for
> > feature-full login screen.
> >
> 
> As long as gdm user has some possibility to log in to the system other
> users I would be really unhappy to discover that some security bug in those
> processes was used to login into my system some parasites :)
gdm does not listen on the network, so whether or not gdm is still
running after you log doesn't make that much difference. A local user
can always cause gdm to be launched, by using the switch-user functionality.
It would be nicer of course for it to go away after login, since many
people just log in once per reboot.

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

application and header files

2017-03-14 Thread Randy Barlow 
Hello!

During a package review[0], I suggested that a CLI application's header
files need to go into a -devel subpackage (they are currently not being
packaged, except for the -debuginfo subpackage.) The reviewer
disagrees, but fedora-review uses the word must. I went to the
packaging guidelines[1] to find out if they say that header files must
be packaged for applications, but it seems that they don't explicitly
say that. By my reading, they say that if you package header files they
must go into a -devel subpackage, but they don't say that you must
package header files.

Is it OK to leave header files unpackaged for CLI applications?


[0] https://bugzilla.redhat.com/show_bug.cgi?id=1422555
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

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: Default permissions on /dev/kvm

2017-03-14 Thread Daniel J Walsh 


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.
>
> Dusty
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Most likely libvirt or whoever is launching the containers is not running
as root, so it is being blocked access.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: application and header files

2017-03-14 Thread Michael Schwendt 
On Tue, 14 Mar 2017 17:34:16 -0400, Randy Barlow wrote:

> During a package review[0], I suggested that a CLI application's header
> files need to go into a -devel subpackage (they are currently not being
> packaged, except for the -debuginfo subpackage.) The reviewer
> disagrees, but fedora-review uses the word must. I went to the
> packaging guidelines[1] to find out if they say that header files must
> be packaged for applications, but it seems that they don't explicitly
> say that. By my reading, they say that if you package header files they
> must go into a -devel subpackage, but they don't say that you must
> package header files.

The review is highly misleading, and the latest spec file does not
include any headers in the package:

  %files
  %license COPYING
  %doc EXTENDING.html FAQ NEWS README
  %{_bindir}/arduino-ctags
  %{_mandir}/man1/arduino-ctags.1.gz

> Is it OK to leave header files unpackaged for CLI applications?

Yes, of course, if the headers aren't used by the application itself
and not by anyone either. What sort of headers are they? What do they
do? Do they need a library to link with? Question, questions!

> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1422555
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Re: 2017-03-13 @ ** 1600 ** UTC - Fedora 26 Blocker Review

2017-03-14 Thread Björn Persson 
Pierre-Yves Chibon wrote:
> On Mon, Mar 13, 2017 at 09:55:48AM +0100, Silvia Sanchez wrote:
> >Now I'm confused...  Is it 17:00 UTC  or  16:00 UTC?  
> >I'm in Germany so at what time should I join?  
> 
> Since Europe hasn't changed time, the meeting is at 16:00 UTC for
> you, ie: one hour earlier.

Note: UTC is always UTC, regardless of how politicians in various
countries play with their clocks. UTC does not jump around. Writing
"since" is therefore misleading. The fact that the meeting was at
16:00 UTC is independent of the fact that Europe hasn't changed time.

Björn Persson


pgpFzZGsCUsMU.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Re: 2017-03-13 @ ** 1600 ** UTC - Fedora 26 Blocker Review

2017-03-14 Thread Adam Williamson 
On Tue, 2017-03-14 at 23:42 +0100, Björn Persson wrote:
> Pierre-Yves Chibon wrote:
> > On Mon, Mar 13, 2017 at 09:55:48AM +0100, Silvia Sanchez wrote:
> > >Now I'm confused...  Is it 17:00 UTC  or  16:00 UTC?  
> > >I'm in Germany so at what time should I join?  
> > 
> > Since Europe hasn't changed time, the meeting is at 16:00 UTC for
> > you, ie: one hour earlier.
> 
> Note: UTC is always UTC, regardless of how politicians in various
> countries play with their clocks. UTC does not jump around. Writing
> "since" is therefore misleading. The fact that the meeting was at
> 16:00 UTC is independent of the fact that Europe hasn't changed time.

Right. From now until the end of North American DST, the meeting is at
1600 UTC everywhere. :) The difference is whether that's the same
*local* time for you as before, or not. If you started daylight savings
time during the week before the meeting time change - as most of North
America did - then the meeting would be at the same *local* time for
you as it was before. If you didn't, then the meeting would be one hour
earlier in local time.

The easiest thing to do is just run 'date -u' to see what the current
UTC time is. The canonical time of Fedora meetings is always given in
UTC, and you can always find the current UTC time with that command.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: application and header files

2017-03-14 Thread Randy Barlow 
On Tue, 2017-03-14 at 22:55 +0100, Michael Schwendt wrote:
> The review is highly misleading, and the latest spec file does not
> include any headers in the package:
> 
>   %files
>   %license COPYING
>   %doc EXTENDING.html FAQ NEWS README
>   %{_bindir}/arduino-ctags
>   %{_mandir}/man1/arduino-ctags.1.gz

What do you find misleading about the review?

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

> > Is it OK to leave header files unpackaged for CLI applications?
> 
> Yes, of course, if the headers aren't used by the application itself
> and not by anyone either. What sort of headers are they? What do they
> do? Do they need a library to link with? Question, questions!

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? Without the
headers this would not be possible (or at least not easy). I don't know
of anyone explicitly wanting to do this of course, and I suppose a bug
could always be filed requesting the headers if needed.

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.

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: [Help Wanted] PPC64LE build for thrift

2017-03-14 Thread Jonathan Wakely 

On 14/03/17 17:57 +, Christopher wrote:

Your comment makes me wonder if there is *any* appropriate use of
boost-static. If not, why is it even packaged?


For Fedora users to link their own applications against.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: application and header files

2017-03-14 Thread Jonathan Wakely 

On 14/03/17 19:04 -0400, Randy Barlow wrote:

On Tue, 2017-03-14 at 22:55 +0100, Michael Schwendt wrote:

The review is highly misleading, and the latest spec file does not
include any headers in the package:

  %files
  %license COPYING
  %doc EXTENDING.html FAQ NEWS README
  %{_bindir}/arduino-ctags
  %{_mandir}/man1/arduino-ctags.1.gz


What do you find misleading about the review?

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


> Is it OK to leave header files unpackaged for CLI applications?

Yes, of course, if the headers aren't used by the application itself
and not by anyone either. What sort of headers are they? What do they
do? Do they need a library to link with? Question, questions!


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? Without the
headers this would not be possible (or at least not easy). I don't know
of anyone explicitly wanting to do this of course, and I suppose a bug
could always be filed requesting the headers if needed.


It's an executable, not a library, so how could users link to it?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

2017-03-14 Thread Zbigniew Jędrzejewski-Szmek 
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.

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 (Was: Re: [Help Wanted] PPC64LE build for thrift)

2017-03-14 Thread Jonathan Wakely 

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 wonder if there is *any* appropriate use of
> boost-static. If not, why is it even packaged?
> I'd be happy to accept your help patching what upstream is doing to move
> from boost-static to boost-test (I'm not sufficiently knowledgeable about
> C/C++ tooling to switch on my own), but since the dependency is limited to
> unit testing during the build, I think it's probably fine.
>

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


The problem being what exactly?


One of the most bizarre IMO static packages is glibc-static.


The problem being what exactly?


By this compilation of the glibc package is probably almost two times
longer than it could be.


OK, so we suffer that problem only once (during the glibc build).  But
it's a benefit to have glibc-static because it enables people to build
staticly linked programs.

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.


If package like glibc-static will be still propagated to commercial RH
sooner or later it will blow up into the face RH support as some customer
will have some issue with some his own binary linked against some ancient
version of glibc static library still used on some quite fresh distro
resources


It's nice that you're thinking so much about Red Hat and their support
problems, but I think Red Hat can deal with that themselves.  In the
case you describe it wouldn't be a supported configuration and there
would be no support issues.


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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gdm processes

2017-03-14 Thread Tomasz Kłoczko 
On 14 March 2017 at 21:32, Zbigniew Jędrzejewski-Szmek 
wrote:

> gdm does not listen on the network, so whether or not gdm is still
> running after you log doesn't make that much difference. A local user
> can always cause gdm to be launched, by using the switch-user
> functionality.
> It would be nicer of course for it to go away after login, since many
> people just log in once per reboot.
>

You forgot that with some of those processes is possible to communicate
over unix sockets.
Keeping things simple as possible is always is main principle :)

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

Rotation logs - use or not to use

2017-03-14 Thread Michal Schorm 
Cheers all,

I'm trying to do something with a patch in MariaDB, but I need to know
current situation about rotation logs.

*What's the problem:*
Upstream ship rotation log, we drop it out.
This started sometimes between F15 and F16. Mostly because (for what I
read) Fedora didn't like rotation logs, there were issues in them, they
were often broken and so on.
What's more, nearly nobody used them in MariaDB and MySQL, so it was easier
to drop it (comment it out) but lets those who wants to use them on their
own risk.

*Current situation:*
Now I'm here, with a patch that comment's upstream's log rotation settings
out.
I can tell upstream, rotation is broken in Fedora and they should not use
it here, or I can find out, it works fine nowadays and I should start
shipping it.

*Questions:*
1) How's the current situation, around rotation logs - do they work?
2) What about other packages - do you use rotation logs in them?




-- 

Michal Schorm
Core Services - Databases Team
mail: msch...@redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review Swaps: (mostly) very simple golang packages

2017-03-14 Thread Ben Rosser 
On Mon, Mar 13, 2017 at 6:52 PM, Fabio Valentini  wrote:
> 7) golang-github-cznic-sortutil - Supplemental utilities for Go's sort
> package (depends on [2])
> https://bugzilla.redhat.com/show_bug.cgi?id=1431735
>
> 8) golang-github-cznic-strutil - Supplemental utilities for Go's strings
> package (depends on [2])
> https://bugzilla.redhat.com/show_bug.cgi?id=1431736

I took these two; I'll review them once the dependencies get reviewed.

I also have two small golang packages in the review queue, any chance
you could look at them in return?

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

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

systemd-coredump-python

2017-03-14 Thread Zbigniew Jędrzejewski-Szmek 
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.

The advantage is that it provides a backtrace in the journal (in
red!), which coredumpctl list/info know about. Various stuff that
systemd-coredump gathers (fdinfo, cgroups, mounts, unit, slices,
limits, uid, gid, etc) are recorded. No call stack of the process is
gathered though, just the python backtrace.

I'm not 100% convinced that this will be useful myself. If you have
Python services, maybe. I'd be interested to hear what people think
about this.

To try it out:
1. make sure you're on systemd 233 (currently only rawhide or F26)
2. dnf install python3-systemd-coredump (or python2-system-coredump)
3. uninstall or disable abrt
   (two separate things matter:
- systemd-coredump-python checks if systemd-coredump is configured
  in sysctl kernel.core_pattern, and does nothing if not,
- abrt-addon-python3 installs its handler unconditionally and
  exclusively.
So instead of removing abrt it is enough to:
systemctl stop abrt\* && rm /usr/lib64/python*/site-packages/abrt.pth
This conflict should be temporary, the patch to make the abrt
handler non-exclusive should be trivial.)
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
5. check 'coredumpctl' and 'journalctl' output, a backtrace should be
   logged.

$ coredumpctl info -1
   PID: 29688 (python3)
   UID: 1000 (zbyszek)
   GID: 1000 (zbyszek)
Reason: ZeroDivisionError
 Timestamp: Tue 2017-03-14 22:41:41 EDT (6min ago)
  Command Line: python3 
/usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py
Executable: /usr/bin/python3.5
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
  Unit: user@1000.service
 User Unit: gnome-terminal-server.service
 Slice: user-1000.slice
 Owner UID: 1000 (zbyszek)
   Boot ID: b3ca39ca747e4cd896e9e5fbb0e07f5e
Machine ID: ad18f69b80264b52bb3b766240742383
  Hostname: fedora
   Storage: none
   Message: Process 29688 
(/usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py)
of user zbyszek failed with ZeroDivisionError: division by zero

Traceback (most recent call last):
  File 
"/usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py", line 
165, in 
g()
  File 
"/usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py", line 
164, in g
f()
  File 
"/usr/lib/python3.5/site-packages/systemd_coredump_exception_handler.py", line 
162, in f
div0 = 1 / 0
ZeroDivisionError: division by zero

Local variables in innermost frame:
  h=
  a=3

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

Re: Voice recognition packages need a new maintainer

2017-03-14 Thread Jerry James 
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
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