date:20150127

Re: F22 System Wide Change: Django 1.8

2015-01-27 Thread Matthias Runge

On 27/01/15 11:51, Miloslav Trmač wrote:
 Hello,
 ** A build containing latest Django will be pushed to f22 branch late in dev
 cycle. If we decide not to push Django-1.8, nothing will be broken.
 ** Django 1.8 final release is expected around April 1st, 2015: [2]
 
 Note that the “Change checkpoint: completion deadline (testable)” is on Feb 
 24; do you plan to have a beta version built by then?
 Mirek
 
According to schedule[1], the beta is planned for Feb 16th.

[1] https://code.djangoproject.com/wiki/Version1.8Roadmap

So: yes!

Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Apps using default Python in Fedora vs. EPEL

2015-01-27 Thread Nick Coghlan

On 27 January 2015 at 21:26, Bohuslav Kabrda bkab...@redhat.com wrote:
 Hey all,
 I just wanted to ask for some thoughts on a problem (or rather a 
 hardship) that is starting to show with the Python 3 transition in Fedora.
 I've been contacted by two maintainers of applications in Fedora for advice 
 and have been thinking for some time how to solve this:

 Note: by applications I mean packages that provide end-user benefit and 
 don't need to be packaged for both Python interpreters. They just use some 
 Python (preferably the default one) to deliver functionality to user. Let's 
 take copr-cli as an example - this is a thin CLI wrapper around python-copr.

 Current state:
 - Up until F21, maintainers were encouraged to build applications with Python 
 2, but weren't discouraged from building with Python 3.
 - From F22 on, packagers will be encouraged to build with Python 3 rather 
 than Python 2.
 - Lots of packagers want to keep the same specfile for EPEL and Fedora.
 - Fedora guidelines mandate explicit usage of %__python2 and %__python3 (and 
 all the sitelib/sitearch macros).

 The Problem:
 If packagers want to build against Python 3 in Fedora and Python in EPEL 
 *and* keep the same specfile, they have to invent some ugly hacks, since 
 Fedora's guidelines require explicit usage of versioned Python macros. This 
 affects Requires and BuildRequires and %prep, %build, %install, %check 
 sections. People who want to do this either redefine %__python in Fedora to 
 point to Python 3 or something like that - I'm afraid that we could end up 
 with a huge pile of crazy macro redefinitions in tons of packages and I want 
 to avoid that.

 Proposed Solution:
 After thinking a few days about this, here's what I propose:
 - Every specfile will have a minimal header with macro definitions that will 
 look like this:

 %if 0%{?fedora}
 %global default_python python3
 %else
 %global default_python python
 %endif

I'm wary of this proposed solution mostly due to the fact that in the
middle of last year, the Beaker team had to go through and completely
redesign the way the automatic kickstart generation worked, because
the templates were full of checks that assumed RHEL 6 as the default
basis for derived distros. Once RHEL 7 and CentOS 7 were generally
available, that assumption became problematically wrong (e.g. systemd
wasn't a Fedora only feature any more), so the templates were all
rewritten to be based on operating system feature flags instead (which
had the added bonus of also making them more tolerant of Fedora
derivatives).

I see the seeds of a similar problem being planted with the above
proposal: what happens when, at some point in the future, Python 3 as
default is no longer a Fedora-only feature? Do we have to go edit all
the spec files again?

What if, instead, we were able to add a new macro that let folks
*explicitly* opt in to running in the system Python, but then define
the recommended spec file usage such that it falls back to Python 2 if
the system Python macro isn't defined?

That would give people 3 explicit options to choose from:

* always run in Python 2
* always run in Python 3
* run in the same Python as Anaconda and yum

Single source Python 2/3 compatibility could then be made a policy
requirement for packages opting in to running in the system Python
rather than explicitly running in Python 3.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: DNF replacing yum: fedup?

2015-01-27 Thread Matthias Clasen

On Tue, 2015-01-27 at 01:26 +, Naheem Zaffar wrote:
 
 
 On 26 January 2015 at 22:52, Will Woods wwo...@redhat.com wrote:
 
 (As an aside, PackageKit should also support these operations,
 so we can
 use PackageKit to make a Upgrade GUI Thing.)
 
 
 Gnome Software has had some interesting work done in the 3.16 cycle to
 handle upgrades.

This sounds like a legend in the making.

We have looked at this, and we have initial designs for how this could
look, but no code has been written yet.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF replacing yum: fedup?

2015-01-27 Thread Peter Robinson

https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
   
says nothing about fedup. However, fedup uses yum:
   
  
   Seems like fedup is only used on Fedora 21 and older to upgrade to
   Fedora 22. So dnf support would be needed to get Fedora 22 to
   fedup to Fedora 23. No?
 
  I guess right after Fedora 22 branch, it would break the ability to
  use fedup to upgrade from Fedora 22 to Rawhide...
 

 There is in fact no strict *technical* requirement for anything to
 move from yum to dnf in F22. yum will remain in the F22 package set,
 it is not being removed.

 However, the Change seems to me to have been written with the basic
 idea that yum shouldn't be installed by default any more and nothing
 that's a core part of Fedora should use it any more - for e.g., the
 Change incorporates moving anaconda to dnf, even though technically
 speaking there's no *need* for this, we could if we wanted to ship F22
 with anaconda using yum but the installed system using dnf.

 This has implications on another Change - moving to Python 3. See
 Scope section - http://fedoraproject.org//wiki/Changes/Python_3_as_Default

 Yum means moving both DNF and Python 3 to Fedora 23.

When I was testing the other day I was somewhat surprised to see that
dnf doesn't depend on python3 but rather still py2 at least on F-21.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF and mock

2015-01-27 Thread Jan Zelený

On 27. 1. 2015 at 03:54:38, Peter Robinson wrote:
 On Mon, Jan 26, 2015 at 3:43 PM, Kevin Fenzi ke...@scrye.com wrote:
  On Mon, 26 Jan 2015 09:43:55 +
  
  Peter Robinson pbrobin...@gmail.com wrote:
   The kernel, grub and a few other packages are built on the RHEL6
   boxes, not everything was migrated off of RHEL
   
   Just out of curiosity, what are the reasons?
  
  Signing infrastructure for secure boot.
  
  Actually, as I noted to Dennis the other day, I did move the secure
  boot builders over to Fedora. They are currently running Fedora 20, I
  still need to upgrade them to Fedora 21.
  
  The last builders that aren't running Fedora are our ppc builders.
  (2 of them for epel ppc builds). I'm not sure how easy it will be to
  move them to Fedora.
 
 The Fedora secondary PPC builders are all F-20 now, we've got some new
 Power8 kit coming at some point in Q1 so the plan is to move them all
 over to PowerKVM so we should be able to deploy all builders in the
 same manner across all architectures before long.

Does it mean that everything either migrated to Fedora or at least considered 
to be migrated soon?

Thanks
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF replacing yum: fedup?

2015-01-27 Thread Igor Gnatenko

On Tue, Jan 27, 2015 at 4:35 PM, Peter Robinson pbrobin...@gmail.com wrote:
https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
   
says nothing about fedup. However, fedup uses yum:
   
  
   Seems like fedup is only used on Fedora 21 and older to upgrade to
   Fedora 22. So dnf support would be needed to get Fedora 22 to
   fedup to Fedora 23. No?
 
  I guess right after Fedora 22 branch, it would break the ability to
  use fedup to upgrade from Fedora 22 to Rawhide...
 

 There is in fact no strict *technical* requirement for anything to
 move from yum to dnf in F22. yum will remain in the F22 package set,
 it is not being removed.

 However, the Change seems to me to have been written with the basic
 idea that yum shouldn't be installed by default any more and nothing
 that's a core part of Fedora should use it any more - for e.g., the
 Change incorporates moving anaconda to dnf, even though technically
 speaking there's no *need* for this, we could if we wanted to ship F22
 with anaconda using yum but the installed system using dnf.

 This has implications on another Change - moving to Python 3. See
 Scope section - http://fedoraproject.org//wiki/Changes/Python_3_as_Default

 Yum means moving both DNF and Python 3 to Fedora 23.

 When I was testing the other day I was somewhat surprised to see that
 dnf doesn't depend on python3 but rather still py2 at least on F-21.
you can install python3-dnf and use dnf-3 as package-manager.

all plugins has py3 version
 Peter
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
-Igor Gnatenko
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python-sig and retiring python3-dateutil

2015-01-27 Thread Bohuslav Kabrda

- Original Message -

 Pete Travis  m...@petetravis.com  schrieb am Mon Jan 26 2015 at 5:24:32 PM:

  On 01/26/2015 08:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
 
   Hi,
 
  
 
   since bug #1126521 seems to be progressing nicely, I think it would be
 
   nice to get in touch with python-sig, the maintainers of
 
   python3-dateutil, about retiring python3-dateutil and adding a python3
 
   subpackage to python-dateutil. They might want to do it the other way
 
   around, which would be fine too, but either way, something should be
 
   arranged.
 
  
 
   I tried to sign up for the python-sig mailing list, but it is
 
   private and I haven't received any welcome letter, so I think I'm
 
   stuck in some moderation queue.
 
  
 
   Zbyszek
 

  Yes, I think it's a good time to bring up retiring python3-dateutil.
 
  I've also requested membership for that list, and included the list
 
  owners here, maybe they can expedite our requests.
 

 As python-dateutil is not (yet) under the python-sig group maintainership
 [1], you could reach the maintainers of python-dateutil under ther -owner
 mail address (CC'ed).
 python-sig@fp.o is for all group maintained package maintainers and general
 python related questions are handled on python-devel@fp.o (also CC'ed).
 (Sorry for the confusion, the python-sig groupmaintainership started very
 recently and is still a work in process.)

 I'd say it depends, how python3 will be introduced in F22, which package
 should provide the subpackage and the other one should be retired.
 Maybe someone from [2] could comment on what they like to see in the future.
 I don't mind having two separate packages until we approach F22 and the
 future process is here.

 Greetings,
 Tom

 [1] https://admin.fedoraproject.org/pkgdb/package/python-dateutil/
 [2] http://fedoraproject.org/wiki/Changes/Python_3_as_Default

Packaging Python extension modules should keep working the way it did up until 
F21. python-dateutil will still be the Python2 build, python3-datetuil will 
still be the Python3 build. There are some guidelines changes that I proposed 
for F22 [1], but I think they don't influence dateutil. 

Slavek 

[1] https://fedorahosted.org/fpc/ticket/475#comment:5 
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: F22 System Wide Change: Atomic Host

2015-01-27 Thread Miloslav Trmač

Hello,
 == Scope ==
 * Other developers: Unknown.
 * Policies and guidelines: May need updates for RpmOstree.
This is too vague.  What basis do have the other developers for commenting 
about how they would be affected, knowing only the above?

 == Detailed Description ==
 The original Changes/Atomic_Cloud_Image was a host system delivered just as a
 cloud image. This Change for Fedora 22 expands it to a multitude of delivery
 vehicles:
OK, “expands… delivery vehicles”.

 == Contingency Plan ==
 If something fails and this product can't ship, some upgrade mechanism for
 Fedora 21 Atomic Cloud Image users would need to be evaluated.

How is this related to “expanding… delivery vehicles” as described above?  The 
F21 cloud image is the original delivery vehicle, not one of the expanded ones. 
 Is this a copypaste from one of the other Change proposals, or a missing part 
in the Detailed Description?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: Tunir

2015-01-27 Thread Kushal Das

On Thu, Jan 22, 2015 at 9:14 PM, Miloslav Trmač m...@redhat.com wrote:
 Hello,
 Tunir is a self contained CI Continuous Integration [1] which will be used to
 test Fedora Cloud images nightly.
 What relationship, if any, does this have with Taskotron?
Right now none. Though I am talking with  the upstream on design and ideas.


 Do I understand correctly that this Change does not involve / require setting 
 up automated test runs by rel-eng or Fedora infrastructure?

We will have to run one instance under Fedora Infrastructure for
nightly builds testing.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
Director Python Software Foundation
http://kushaldas.in
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

2015-01-27 Thread Reindl Harald




Am 27.01.2015 um 20:50 schrieb Nico Kadel-Garcia:

On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
adamw...@fedoraproject.org wrote:

On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:


* KVM bridge configuration


Works fine in F21+, I'm using NM on both my main desktop/test box and
my server VM host.


Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
to work after installation with the Server installation ISO than I
could spend, even after I brought in enough debris to get a GUI
screen.

I'll also point out that with either installation, it's unusably slow,
it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
video card and 2 Gig of RAM allocated, so that makes testing awkward
for me. I can switch window managers to something remotely sane, but
then I lose the complex integration that makes the NetworkManager
configuration utilities available.

The modern anaconda tools and NetworkManager do indeed have access to
installation time configuration of tagged VLAN's and pair bonding,
although the interface is quite poor. Please refer to Eric Raymond's
old essay on The Luxury of Ignorance for guidelines on why it is so
poor, the lack of display of what am I going to change from the
current status is merely one of its many issues, and the lack of a
usable 'Help' key is pretty serious.

Bridges for KVM are not supported. What is apparent is that
NetworkManager supports 'DCB', data center bridging. That's a
different technology. And that puts us right into one of the
guidelines Eric added to his essay as a postscript:

  Are there settings you can do from the command line or
hand-editing config files that cannot be done from the GUI? Are they
documented anywhere? Does using the GUI erase these settings?

I have to admit that I remain pretty unhappy with NetworkManager. It's
a complex GUI on top of the underlying actual iinit scrupts, it
doesn't do a good job of exposing the available options and there's no
usable 'help' interface. Altogether, I'm afraid I have to classify it
as a bad tool and recommend strongly against it for producton use.
It's also partly why I try to put 'NM_CONTROLLED=no' in every
/etc/sysconfig/network for servers that I work with


signed!

and the main point is: there is no need to replace network.service on 
*any* static configured machine and nobody with responsibility for 
complex networks right in his mind is playing games if he is running a 
magnitude of machines, all similar configured, all with differnt jobs 
and a mix of Fedora/RHEL5,6,7


that won't change for many years

there is a usecase for NM, surely, but not for me and not for a lot of 
other people working professional in serious setups and tend to 
configure personal workstations left and right as much as possible ike 
the production environment


frankly i have enough of change for the sake of change as well i won't 
use notebooks or other mobile devices for serious tasks for the rest 
of my life - period




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[EPEL-devel] Fedora EPEL 7 updates-testing report

2015-01-27 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  75  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3989/cross-binutils-2.23.88.0.1-2.el7.1
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0290/python-django-1.6.10-1.el7
   3  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0399/polarssl-1.3.9-3.el7
   0  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0465/mingw-jasper-1.900.1-26.el7
   0  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0437/qpid-cpp-0.30-7.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

drupal7-email-1.3-2.el7
drupal7-site_map-1.2-3.el7
getdns-0.1.6-1.el7
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el7
nodejs-escodegen-1.3.2-2.el7
nodejs-esutils-1.0.0-4.el7
php-horde-Horde-Imap-Client-2.26.1-1.el7
php-phpunit-PHP-CodeCoverage-2.0.15-1.el7
php-phpunit-PHPUnit-4.4.4-1.el7
php-phpunit-exporter-1.1.0-1.el7
php-xmlseclibs-1.3.1-3.el7
python-fedmsg-meta-fedora-infrastructure-0.3.11-1.el7
qpid-dispatch-0.3-1.el7
xiphos-3.2.2-1.el7

Details about builds:



 drupal7-email-1.3-2.el7 (FEDORA-EPEL-2015-0490)
 Defines an email field type.

Update Information:

This module provides a field type for email addresses.

References:

  [ 1 ] Bug #1103539 - Review Request: drupal7-email - This module provides a 
field type for email addresses
https://bugzilla.redhat.com/show_bug.cgi?id=1103539




 drupal7-site_map-1.2-3.el7 (FEDORA-EPEL-2015-0469)
 Provides a site map that gives visitors an overview of your site

Update Information:

This module provides a site map that gives visitors an overview of your site.

References:

  [ 1 ] Bug #1103852 - Review Request: drupal7-site_map - This module provides 
a site map that gives visitors an overview of your site
https://bugzilla.redhat.com/show_bug.cgi?id=1103852




 getdns-0.1.6-1.el7 (FEDORA-EPEL-2015-0488)
 Modern asynchronous API to the DNS

Update Information:

Updated to 0.1.6 with minor bugfixes

ChangeLog:

* Mon Jan 19 2015 Paul Wouters pwout...@redhat.com - 0.1.6-1
- Updated to 0.1.6 with minor bugfixes
- Remove spurious execute bits from some *.[ch] files




 mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el7 (FEDORA-EPEL-2015-0486)
 Firefox and Seamonkey extension that gives you control over cross-site requests

Update Information:

- **New package**

References:

  [ 1 ] Bug #1128754 - Review Request: mozilla-requestpolicy - Firefox and 
Seamonkey extension that gives you control over cross-site requests
https://bugzilla.redhat.com/show_bug.cgi?id=1128754




 nodejs-escodegen-1.3.2-2.el7 (FEDORA-EPEL-2015-0477)
 ECMAScript code generator

Update Information:

Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild

References:

  [ 1 ] Bug #1174142 - Please add EPEL7 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1174142




 nodejs-esutils-1.0.0-4.el7 (FEDORA-EPEL-2015-0482)
 Utility box for ECMAScript language tools

Update Information:

Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild

References:

  [ 1 ]

Re: initscripts

2015-01-27 Thread Nico Kadel-Garcia

On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:

 * KVM bridge configuration

 Works fine in F21+, I'm using NM on both my main desktop/test box and
 my server VM host.

Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
to work after installation with the Server installation ISO than I
could spend, even after I brought in enough debris to get a GUI
screen.

I'll also point out that with either installation, it's unusably slow,
it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
video card and 2 Gig of RAM allocated, so that makes testing awkward
for me. I can switch window managers to something remotely sane, but
then I lose the complex integration that makes the NetworkManager
configuration utilities available.

The modern anaconda tools and NetworkManager do indeed have access to
installation time configuration of tagged VLAN's and pair bonding,
although the interface is quite poor. Please refer to Eric Raymond's
old essay on The Luxury of Ignorance for guidelines on why it is so
poor, the lack of display of what am I going to change from the
current status is merely one of its many issues, and the lack of a
usable 'Help' key is pretty serious.

Bridges for KVM are not supported. What is apparent is that
NetworkManager supports 'DCB', data center bridging. That's a
different technology. And that puts us right into one of the
guidelines Eric added to his essay as a postscript:

 Are there settings you can do from the command line or
hand-editing config files that cannot be done from the GUI? Are they
documented anywhere? Does using the GUI erase these settings?

I have to admit that I remain pretty unhappy with NetworkManager. It's
a complex GUI on top of the underlying actual iinit scrupts, it
doesn't do a good job of exposing the available options and there's no
usable 'help' interface. Altogether, I'm afraid I have to classify it
as a bad tool and recommend strongly against it for producton use.
It's also partly why I try to put 'NM_CONTROLLED=no' in every
/etc/sysconfig/network for servers that I work with.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

2015-01-27 Thread Dan Williams

On Tue, 2015-01-27 at 14:50 -0500, Nico Kadel-Garcia wrote:
 On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
 adamw...@fedoraproject.org wrote:
  On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:
 
  * KVM bridge configuration
 
  Works fine in F21+, I'm using NM on both my main desktop/test box and
  my server VM host.
 
 Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
 to work after installation with the Server installation ISO than I
 could spend, even after I brought in enough debris to get a GUI
 screen.
 
 I'll also point out that with either installation, it's unusably slow,
 it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
 video card and 2 Gig of RAM allocated, so that makes testing awkward
 for me. I can switch window managers to something remotely sane, but
 then I lose the complex integration that makes the NetworkManager
 configuration utilities available.
 
 The modern anaconda tools and NetworkManager do indeed have access to
 installation time configuration of tagged VLAN's and pair bonding,
 although the interface is quite poor. Please refer to Eric Raymond's
 old essay on The Luxury of Ignorance for guidelines on why it is so
 poor, the lack of display of what am I going to change from the
 current status is merely one of its many issues, and the lack of a
 usable 'Help' key is pretty serious.

I'll assume you're talking about either anaconda or nm-connection-editor
here?  eg, the GUI tools?

 Bridges for KVM are not supported. What is apparent is that
 NetworkManager supports 'DCB', data center bridging. That's a
 different technology. And that puts us right into one of the
 guidelines Eric added to his essay as a postscript:

Not sure what you mean about bridges for KVM not being supported.  NM
can create bridges/bonds/vlans/teams/etc and assign slaves to any of
them, and also set up a NAT-ed configuration much like libvirt does for
a bridge.  Obviously there needs to be a way for the kvm/qemu instance
to figure out what interface to use for connecting the guest, but that's
somewhat out of scope for NetworkManager.  

  Are there settings you can do from the command line or
 hand-editing config files that cannot be done from the GUI? Are they
 documented anywhere? Does using the GUI erase these settings?

Yes, there are things the GUI cannot do that nmcli and text files can
do.  The GUIs present in GNOME Shell and nm-connection-editor are not
intended to expose the full configuration possibilities of
NetworkManager, much like you don't expect a GUI to expose all the
options in apache or freeradius configuration.  For that, you can use
your favorite text editor along with 'man', or the built-in nmcli help.
We don't plan to significantly duplicate all the functionality of nmcli
or config files in nm-connection-editor, since that's not the target
audience of the tool.

Yes, there could be GUI online help for nm-connection-editor that
explains everything that it cannot do, but that misses the most of the
point of a general purpose GUI.  A more server-oriented GUI (like
Cockpit) could certainly expose more of the server-oriented
configuration options.

Note that nm-connection-editor has tooltips that give more information
about what most of the options are.  You may find these useful.

 I have to admit that I remain pretty unhappy with NetworkManager. It's
 a complex GUI on top of the underlying actual iinit scrupts, it
 doesn't do a good job of exposing the available options and there's no
 usable 'help' interface. Altogether, I'm afraid I have to classify it
 as a bad tool and recommend strongly against it for producton use.
 It's also partly why I try to put 'NM_CONTROLLED=no' in every
 /etc/sysconfig/network for servers that I work with.

nmcli (the command-line tool) has what I would consider very good
built-in help when modifying configuration.  eg, nmcli con edit name |
UUID and then desc dcb.app-fcoe-flags will give you a description of
what that is and what values are allowed.  Obviously it can always be
better.

There are also detailed manpages for nmcli, that refer you to
nmcli-examples(5), nm-settings(5), and others.

We're happy to take concrete suggestions on how to improve the
documentation, both in the manpages, GUI tooltips, nmcli interactive
help, etc.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

2015-01-27 Thread Dan Williams

On Tue, 2015-01-27 at 20:56 +0100, Reindl Harald wrote:
 
 Am 27.01.2015 um 20:50 schrieb Nico Kadel-Garcia:
  On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
  adamw...@fedoraproject.org wrote:
  On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:
 
  * KVM bridge configuration
 
  Works fine in F21+, I'm using NM on both my main desktop/test box and
  my server VM host.
 
  Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
  to work after installation with the Server installation ISO than I
  could spend, even after I brought in enough debris to get a GUI
  screen.
 
  I'll also point out that with either installation, it's unusably slow,
  it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
  video card and 2 Gig of RAM allocated, so that makes testing awkward
  for me. I can switch window managers to something remotely sane, but
  then I lose the complex integration that makes the NetworkManager
  configuration utilities available.
 
  The modern anaconda tools and NetworkManager do indeed have access to
  installation time configuration of tagged VLAN's and pair bonding,
  although the interface is quite poor. Please refer to Eric Raymond's
  old essay on The Luxury of Ignorance for guidelines on why it is so
  poor, the lack of display of what am I going to change from the
  current status is merely one of its many issues, and the lack of a
  usable 'Help' key is pretty serious.
 
  Bridges for KVM are not supported. What is apparent is that
  NetworkManager supports 'DCB', data center bridging. That's a
  different technology. And that puts us right into one of the
  guidelines Eric added to his essay as a postscript:
 
Are there settings you can do from the command line or
  hand-editing config files that cannot be done from the GUI? Are they
  documented anywhere? Does using the GUI erase these settings?
 
  I have to admit that I remain pretty unhappy with NetworkManager. It's
  a complex GUI on top of the underlying actual iinit scrupts, it
  doesn't do a good job of exposing the available options and there's no
  usable 'help' interface. Altogether, I'm afraid I have to classify it
  as a bad tool and recommend strongly against it for producton use.
  It's also partly why I try to put 'NM_CONTROLLED=no' in every
  /etc/sysconfig/network for servers that I work with
 
 signed!
 
 and the main point is: there is no need to replace network.service on 
 *any* static configured machine and nobody with responsibility for 
 complex networks right in his mind is playing games if he is running a 
 magnitude of machines, all similar configured, all with differnt jobs 
 and a mix of Fedora/RHEL5,6,7
 
 that won't change for many years
 
 there is a usecase for NM, surely, but not for me and not for a lot of 
 other people working professional in serious setups and tend to 
 configure personal workstations left and right as much as possible ike 
 the production environment
 
 frankly i have enough of change for the sake of change as well i won't 
 use notebooks or other mobile devices for serious tasks for the rest 
 of my life - period

NetworkManager is not intended only for mobile devices or notebooks,
because that's a small part of the networking story.  Plus, more than
just notebooks have needs for the things that NetworkManager brings to
the table.

If it's useful for you, that's great.  If you do not find it useful,
that's also fine, and it can be masked.  However, we have put great
effort into NM so that even if it *is* enabled, it can coexist
peacefully with whatever you do on the system outside of NM, and we are
constantly improving this.

We hope that NM can be installed on most systems, and will be there when
required and useful, but will get out of the way when not required.

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Flash plugin 0-day vulnerability in the wild

2015-01-27 Thread Ahmad Samir

On 26 January 2015 at 15:17, Martin Stransky stran...@redhat.com wrote:
 On 01/26/2015 02:03 PM, drago01 wrote:

 On Mon, Jan 26, 2015 at 2:01 PM, Ahmad Samir ahmadsamir3...@gmail.com
 wrote:

 On 26 January 2015 at 14:55, Martin Stransky stran...@redhat.com wrote:



 Where have you got that? Official Adobe site [1] says the latest is
 11.2.202.438 and flash download page [2] gives me the same. I see the
 Ubuntu
 update with .440 package but what's that?

 ma.

 [1] http://www.adobe.com/software/flash/about/
 [2] https://get.adobe.com/flashplayer/


 flash-plugin-11.2.202.440 is available in the yum repo hosted by
 Adobe. But on[1] it doesn't say anything about the issue being fixed
 for Linux.


 Sure it does Adobe Flash Player 11.2.202.438 and earlier versions for
 Linux ... 440  438 ...


 There's no official confirmation of the fix of the CVE-2015-0311 in 440 yet,
 you can only assume that.


They've finally updated[1], it's official now that flash 11.2.202.440
includes the fix for CVE-2015-0311.

[1]http://helpx.adobe.com/security/products/flash-player/apsb15-03.html

-- 
Ahmad Samir
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] RESENT please review: Ticket 47999 - lib389 tests - fix race conditions in various tests

2015-01-27 Thread Mark Reynolds


Resending review request...

https://fedorahosted.org/389/ticket/47999

https://fedorahosted.org/389/attachment/ticket/47999/0001-Ticket-47999-address-several-race-conditions-in-test.patch



--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: DNF replacing yum: fedup?

2015-01-27 Thread Jan Zelený

On 26. 1. 2015 at 17:52:36, Will Woods wrote:
 On Mon, 2015-01-26 at 13:26 -0800, Adam Williamson wrote:
  I note the ReplaceYumWithDnf Change page:
  
  https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
  
  says nothing about fedup. However, fedup uses yum:
  
  [adamw@adam fedup (master %)]$ grep -R yum * | wc -l
  74
  
  Has this been considered yet?
 
 Oh sure. I consider lots of things. I am large, I contain multitudes.
 
  Should porting fedup to dnf be in the scope of this Change?
 
 If you want upgrades to work without yum, yes.
 
  Does that affect its practicability for F22?
 
 That depends on how much help you expect to be able to find for that
 porting effort, since I haven't ever worked with DNF.
 
 It's not actually that complicated; 90% of what fedup does with yum
 would be equivalent to a DNF command like:
 
   dnf --releasever=22 upgrade --testonly \
   --pkglist=/var/lib/system-upgrade/package.list
 
 which would:
 
   * download (and verify) updates for all packages using the F22 repos,
   * run a test transaction of those updates, and report errors, and
   * write a list of packages used in the update to the named file[1].
 
 After that, you'd just need something like a 'treeinfo' command[2] that
 could handle a command line:
 
   dnf --releasever=22 treeinfo download kernel upgrade.img
 
 Which would:
 * download .treeinfo.signed from the configured repo(s)
 * verify it using the RPM trusted key(s)[3]
 * use that to download/verify the items listed (kernel, upgrade.img)
 
 That's about it. Everything else is outside the scope of dnf.
 
 (As an aside, PackageKit should also support these operations, so we can
 use PackageKit to make a Upgrade GUI Thing.)
 
 If anyone from the DNF/PackageKit teams wants to talk more about getting
 these things working, I'm happy to discuss the requirements in more
 detail. I'll also be at DevConf in Brno next weekend if anyone wants to
 discuss it in person.
 
 -w
 
 [1] This is so that upgrade.img knows which packages to install after we
 reboot. Alternately we'd just need a guarantee that every RPM file under
 $SOMEDIR is part of the upgrade transaction, and then fedup could
 construct package.list itself.
 [2] For more information about .treeinfo, see
 https://github.com/wgwoods/fedup/blob/master/fedup/treeinfo.py
 [3] The F22 key(s) get automatically trusted during the process of
 verifying the F22 packages, so after that you can verify F22 stuff
 against the RPM keyring.


CCing Michael Mraka who is handling migration of 3rd party tools from yum to 
dnf. I'm also interested in meeting you at DevConf, but let's arrange that off 
list.

Thanks
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why is fedoraproject.org only indexed by Google?

2015-01-27 Thread Petr Spacek

On 26.1.2015 16:46, Kevin Fenzi wrote:
 On Mon, 26 Jan 2015 07:53:27 -0700 Brandon Vincent
 brandon.vinc...@asu.edu wrote:
 
 On Mon, Jan 26, 2015 at 7:21 AM, Florian Weimer fwei...@redhat.com 
 wrote:
 Any idea why?
 
 https://lists.fedoraproject.org/robots.txt
 
 User-agent: * Crawl-delay: 10
 
 From Bing, This means the higher your crawl delay is, the fewer pages 
 BingBot will crawl. As crawling fewer pages may result in getting less 
 content indexed, we usually do not recommend it, although we also 
 understand that different web sites may have different bandwidth 
 constraints. [1].
 
 [1] 
 http://blogs.bing.com/webmaster/2012/05/03/to-crawl-or-not-to-crawl-that-is-bingbots-question/

 
 Not sure that explains why there are no results at all though.
 
 I think we added the Crawl-delay several years ago when we were having 
 storage issues. We could definitely try removing it and see if things 
 improve.

Yes please. We definitely should get archives indexed by search engines!

-- 
Petr Spacek  @  Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: perl-Net-Twitter

2015-01-27 Thread buildsys



perl-Net-Twitter has broken dependencies in the rawhide tree:
On x86_64:
perl-Net-Twitter-4.01008-1.fc22.noarch requires perl(authentication)
On i386:
perl-Net-Twitter-4.01008-1.fc22.noarch requires perl(authentication)
On armhfp:
perl-Net-Twitter-4.01008-1.fc22.noarch requires perl(authentication)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rawhide report: 20150127 changes

2015-01-27 Thread Fedora Rawhide Report

Compose started at Tue Jan 27 05:15:06 UTC 2015
Broken deps for i386
--
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6
[barman]
barman-1.3.3-4.fc22.noarch requires python-dateutil  0:2.0
[boswars]
boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so
[bro]
broccoli-2.3-1.fc22.i686 requires bro-2.3
python-broccoli-2.3-1.fc22.i686 requires bro-2.3
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14
[fawkes]
fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
[gcc-python-plugin]
gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
[gitg]
gitg-3.14.1-1.fc22.i686 requires libgit2.so.21
gitg-libs-3.14.1-1.fc22.i686 requires libgit2.so.21
[golang-github-goraft-raft]
golang-github-goraft-raft-devel-0-0.5.git73f9c44.fc22.noarch requires 
golang(code.google.com/p/goprotobuf)
[golang-github-influxdb-influxdb]

golang-github-influxdb-influxdb-datastore-0.8.5-0.1.git9485e99.fc22.noarch 
requires golang(code.google.com/p/goprotobuf/proto)
golang-github-influxdb-influxdb-devel-0.8.5-0.1.git9485e99.fc22.noarch 
requires golang(code.google.com/p/goprotobuf/proto)
[guacamole-server]
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-utils.so.1.2
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-core.so.1.2
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-codec.so.1.2
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-cache.so.1.2
[libhocr]
libhocr-gtk-0.10.17-18.fc22.i686 requires python-imaging-sane
[libreoffice]
1:libreoffice-pdfimport-4.4.0.2-1.fc22.i686 requires libpoppler.so.47
[nifti2dicom]
nifti2dicom-0.4.9-1.fc22.i686 requires libitksys-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libitkopenjpeg-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libitkdouble-conversion-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libitkNetlibSlatec-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_hl.so.8
nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_cpp.so.8
nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5.so.8
nifti2dicom-0.4.9-1.fc22.i686 requires libITKznz-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKniftiio-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKgiftiio-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKWatersheds-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVtkGlue-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoIO-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoCore-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVTK-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVNLInstantiation-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKStatistics-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKSpatialObjects-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKReview-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKQuadEdgeMesh-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKPolynomials-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKPath-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizersv4-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizers-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKNrrdIO-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKMetaIO-4.6.so.1

Re: GUI applications writing garbage to stdout/stderr

2015-01-27 Thread Kamil Paral

 The warnings only happen when using development versions of GTK+. So it
 shouldn't happen in F21, or in the future in F22, just in rawhide.

So when I talked about GTK, I meant the whole GNOME stack, like GLib, gvfs, st, 
clutter, mutter, gnome-shell, gstreamer, etc. I guess not all of these parts 
behave the same currently? I see a lot of garbage from them. But I also see 
some GTK warnings, in F21, and I don't have development builds. This is an 
example from today (I pruned it manually a bit):

$ journalctl -a --since=today | grep -iE 
'(warning|error|critical|debug|obsol|deprec)'
Jan 27 09:07:31 medusa gnome-session[1924]: (gnome-shell:2086): Clutter-WARNING 
**: Attempting to add actor of type 'StBoxLayout' to a container of type 
'ShellGenericContainer', but the actor has already a parent of type 
'ShellGenericContainer'.
Jan 27 09:08:21 medusa firefox-home.desktop[20760]: ** (firefox:20760): 
CRITICAL **: gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
Jan 27 09:08:21 medusa firefox-home.desktop[20760]: ** (firefox:20760): 
CRITICAL **: gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
Jan 27 09:08:21 medusa firefox-home.desktop[20760]: ** (firefox:20760): 
CRITICAL **: gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
Jan 27 09:23:15 medusa gnome-session[1924]: (gnome-shell:2086): Clutter-WARNING 
**: Attempting to add actor of type 'StBoxLayout' to a container of type 
'ShellGenericContainer', but the actor has already a parent of type 
'ShellGenericContainer'.
Jan 27 09:26:13 medusa org.gnome.Caribou.Daemon[1961]: ** (caribou:): 
WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The 
name :1.56 was not provided by any .service files
Jan 27 09:27:30 medusa org.gnome.Terminal[1961]: (gnome-terminal-server:22537): 
GLib-CRITICAL **: g_child_watch_add_full: assertion 'pid  0' failed
Jan 27 09:31:20 medusa gnome-session[1924]: (gnome-shell:2086): St-CRITICAL **: 
setup_framebuffers: assertion 'width  0' failed
Jan 27 09:31:20 medusa gnome-session[1924]: (gnome-shell:2086): St-CRITICAL **: 
setup_framebuffers: assertion 'width  0' failed
Jan 27 09:31:20 medusa gnome-session[1924]: (gnome-shell:2086): St-CRITICAL **: 
setup_framebuffers: assertion 'width  0' failed
Jan 27 09:32:41 medusa org.gnome.Caribou.Daemon[1961]: ** (caribou:): 
WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The 
name :1.59 was not provided by any .service files
Jan 27 09:34:44 medusa org.gtk.vfs.Daemon[1961]: ** (process:29027): WARNING 
**: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path 
/org/gtk/vfs/client/enumerator/1 (g-dbus-error-quark, 19)
Jan 27 09:34:44 medusa org.gtk.vfs.Daemon[1961]: ** (process:29027): WARNING 
**: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path 
/org/gtk/vfs/client/enumerator/1 (g-dbus-error-quark, 19)
Jan 27 09:34:44 medusa org.gtk.vfs.Daemon[1961]: ** (process:29027): WARNING 
**: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path 
/org/gtk/vfs/client/enumerator/1 (g-dbus-error-quark, 19)
Jan 27 09:34:44 medusa org.gtk.vfs.Daemon[1961]: ** (process:29027): WARNING 
**: send_done_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path 
/org/gtk/vfs/client/enumerator/1 (g-dbus-error-quark, 19)
Jan 27 09:34:57 medusa gnome-session[1924]: Window manager warning: Buggy 
client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x340004a 
(Unsaved Do)
Jan 27 09:35:17 medusa gnome-session[1924]: Window manager warning: Buggy 
client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3400010 
(Red Hat - )
Jan 27 09:35:23 medusa gnome-session[1924]: (gnome-abrt:23530): Gtk-CRITICAL 
**: gtk_header_bar_pack: assertion 'gtk_widget_get_parent (widget) == NULL' 
failed
Jan 27 09:35:40 medusa gnome-session[1924]: (gnome-abrt:23625): Gtk-CRITICAL 
**: gtk_header_bar_pack: assertion 'gtk_widget_get_parent (widget) == NULL' 
failed
Jan 27 09:36:30 medusa evolution.desktop[23734]: (evolution:23734): 
GLib-GObject-WARNING **: g_object_weak_unref: couldn't find weak ref 
0x302680b470(0x98e800)
Jan 27 09:36:30 medusa evolution.desktop[23734]: (evolution:23734): 
GLib-GObject-WARNING **: g_object_weak_unref: couldn't find weak ref 
0x302680b470(0x98e800)
Jan 27 09:36:30 medusa evolution.desktop[23734]: ** (evolution:23734): WARNING 
**: Shell not finalized on exit
Jan 27 09:37:15 medusa gnome-session[1924]: (gnome-shell:2086): St-CRITICAL **: 
setup_framebuffers: assertion 'width  0' failed
Jan 27 09:37:15 medusa gnome-session[1924]: (gnome-shell:2086): St-CRITICAL **: 
setup_framebuffers: assertion 'width  0' failed
Jan 27 09:37:15 medusa gnome-session[1924]: (gnome-shell:2086): St-CRITICAL **: 
setup_framebuffers: assertion 'width  0' failed
Jan 27 09:37:15 medusa gajim.desktop[23957]: ** Message: 
pygobject_register_sinkfunc is deprecated (GstObject)
Jan 27 09:37:15 medusa gajim.desktop[23957]: **

Re: DNF replacing yum: fedup?

2015-01-27 Thread Jaroslav Reznik

- Original Message -
 On Mon, 2015-01-26 at 14:37 -0700, Chris Murphy wrote:
  On Mon, Jan 26, 2015 at 2:36 PM, Chris Murphy 
  li...@colorremedies.com wrote:
   On Mon, Jan 26, 2015 at 2:26 PM, Adam Williamson 
   adamw...@fedoraproject.org wrote:
I note the ReplaceYumWithDnf Change page:

https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF

says nothing about fedup. However, fedup uses yum:

   
   Seems like fedup is only used on Fedora 21 and older to upgrade to
   Fedora 22. So dnf support would be needed to get Fedora 22 to
   fedup to Fedora 23. No?
  
  I guess right after Fedora 22 branch, it would break the ability to
  use fedup to upgrade from Fedora 22 to Rawhide...
  
 
 There is in fact no strict *technical* requirement for anything to
 move from yum to dnf in F22. yum will remain in the F22 package set,
 it is not being removed.
 
 However, the Change seems to me to have been written with the basic
 idea that yum shouldn't be installed by default any more and nothing
 that's a core part of Fedora should use it any more - for e.g., the
 Change incorporates moving anaconda to dnf, even though technically
 speaking there's no *need* for this, we could if we wanted to ship F22
 with anaconda using yum but the installed system using dnf.

This has implications on another Change - moving to Python 3. See 
Scope section - http://fedoraproject.org//wiki/Changes/Python_3_as_Default

Yum means moving both DNF and Python 3 to Fedora 23.

Jaroslav

 So given that, I wanted to clarify the status of fedup.
 
 If F22's fedup depends on yum, then people with 'clean' dnf-only
 systems are going to get yum installed when they want to upgrade to
 F23. Of course, we could ship F22 on release day with a yum-based
 fedup then provide a dnf-based one as an update, but that seems a bit
 messy.
 --
 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
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

2015-01-27 Thread Dan Williams

On Tue, 2015-01-27 at 14:50 -0500, Nico Kadel-Garcia wrote:
 On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
 adamw...@fedoraproject.org wrote:
  On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:
 
  * KVM bridge configuration
 
  Works fine in F21+, I'm using NM on both my main desktop/test box and
  my server VM host.
 
 Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
 to work after installation with the Server installation ISO than I
 could spend, even after I brought in enough debris to get a GUI
 screen.
 
 I'll also point out that with either installation, it's unusably slow,
 it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
 video card and 2 Gig of RAM allocated, so that makes testing awkward
 for me. I can switch window managers to something remotely sane, but
 then I lose the complex integration that makes the NetworkManager
 configuration utilities available.

I'd also point out that there are three different NetworkManager GUIs,
and one TUI:

1) GNOME Shell network settings - not really targeted for server
environments, has a smaller set of options that are suitable for
desktop/workstation use-cases

2) nm-connection-editor - presents a larger set of options than #1, and
only modifies *saved configuration*, not runtime configuration.  eg, it
is basically a much more capable system-config-network but without the
up/down buttons

3) KDE's network configuration dialogs

4) nmtui - a slightly simpler version of nm-connection-editor intended
for GUI-less environments, like a more capable system-config-network-tui

#2 and #4 obviously run much better in desktop environments like LXDE,
XFCE, etc where the full GNOME stack is not available.

It's important to note which one you're talking about when suggesting
improvements, since they are developed by different projects and each
one has a different target audience.  That said, I understand it can be
confusing which one is for who and available where...

Dan

 The modern anaconda tools and NetworkManager do indeed have access to
 installation time configuration of tagged VLAN's and pair bonding,
 although the interface is quite poor. Please refer to Eric Raymond's
 old essay on The Luxury of Ignorance for guidelines on why it is so
 poor, the lack of display of what am I going to change from the
 current status is merely one of its many issues, and the lack of a
 usable 'Help' key is pretty serious.
 
 Bridges for KVM are not supported. What is apparent is that
 NetworkManager supports 'DCB', data center bridging. That's a
 different technology. And that puts us right into one of the
 guidelines Eric added to his essay as a postscript:
 
  Are there settings you can do from the command line or
 hand-editing config files that cannot be done from the GUI? Are they
 documented anywhere? Does using the GUI erase these settings?
 
 I have to admit that I remain pretty unhappy with NetworkManager. It's
 a complex GUI on top of the underlying actual iinit scrupts, it
 doesn't do a good job of exposing the available options and there's no
 usable 'help' interface. Altogether, I'm afraid I have to classify it
 as a bad tool and recommend strongly against it for producton use.
 It's also partly why I try to put 'NM_CONTROLLED=no' in every
 /etc/sysconfig/network for servers that I work with.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

2015-01-27 Thread Adam Williamson

On Tue, 2015-01-27 at 14:50 -0500, Nico Kadel-Garcia wrote:

I have to admit that I remain pretty unhappy with NetworkManager.
It's a complex GUI on top of the underlying actual iinit scrupts, it

Um. No it isn't. I think you have fundamentally misunderstood what
NetworkManager is. You seem to be treating nm-connection-editor, a
small GUI configuration tool for NetworkManager, as if it *was*
NetworkManager.

NetworkManager is a daemon for controlling network connections. nm-
connection-editor is *one* configuration tool for it; there are many
others, and you can also configure it by editing configuration files.

NetworkManager, per se, supports KVM bridging fine. Refer to
https://www.happyassassin.net/2014/07/23/bridged-networking-for-libvirt-with-networkmanager-2014-fedora-21/
, but note that the udev rule workaround documented there is not, I
think, required with F21 final. Also note that, there, I tried to
document the GUI way of doing it via GNOME Shell to demonstrate that
it's possible; in practice, for sysadmins, I'd simply recommend doing
it with ifcfg files, as described in 'Background and details'.
Fundamentally all it needs is two ifcfg files, one for the bridge, one
for the slave interface, with a few directives in each; in fact, the
same configuration files will work for both network.service and
NetworkManager.
--
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

2015-01-27 Thread Reindl Harald




Am 27.01.2015 um 21:18 schrieb Dan Williams:

On Tue, 2015-01-27 at 20:56 +0100, Reindl Harald wrote:

there is a usecase for NM, surely, but not for me and not for a lot of
other people working professional in serious setups and tend to
configure personal workstations left and right as much as possible ike
the production environment

frankly i have enough of change for the sake of change as well i won't
use notebooks or other mobile devices for serious tasks for the rest
of my life - period


NetworkManager is not intended only for mobile devices or notebooks,
because that's a small part of the networking story.  Plus, more than
just notebooks have needs for the things that NetworkManager brings to
the table.

If it's useful for you, that's great.  If you do not find it useful,
that's also fine, and it can be masked.  However, we have put great
effort into NM so that even if it *is* enabled, it can coexist
peacefully with whatever you do on the system outside of NM, and we are
constantly improving this.

We hope that NM can be installed on most systems, and will be there when
required and useful, but will get out of the way when not required


i am fine with that

but i am not fine with the unacceptable attitude of the thread-starter 
asking when things get removed which are mature and perfect working 
because i have *zero* understanding for the remove this and that and 
replace whatever can be replaced attitude the last recent years at all




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

1 2 >

1 - 100 of 105 matches

Mail list logo