date:20130129

On Mon, 28 Jan 2013 23:56:50 -0800, Dan Mashal wrote:

  cpptest -- A portable and powerful and simple unit testing framework for C++
 
 
 I'll take this one.

Only uriparser uses it currently.
And there's an 1.1.2 upstream release, too.

-- 
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git5.1.fc19.x86_64
loadavg: 0.11 0.04 0.07
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libcacard can never be installed (was: Re: Another unannounced soname bump: libseccomp)

2013-01-29 Thread Richard W.M. Jones

On Tue, Jan 29, 2013 at 08:57:11AM +, Peter Robinson wrote:
 On Tue, Jan 29, 2013 at 8:52 AM, Richard W.M. Jones rjo...@redhat.com wrote:
  I have a filed a bug about this:
 
  https://bugzilla.redhat.com/show_bug.cgi?id=905345
  libcacard can never be installed
 
 Is there a reason that qemu ships a bundled version of libcacard?
 What's the difference between the two of them? Can qemu use the
 unbundled version or are they essentially two completely different
 libraries with the same name?

It looks as if the qemu source contains the one canonical copy of
libcacard.  The separate 'libcacard' package has the following sources
file:

$ cat sources 
189bc5b87281a72f8c72a0f7ebaa6d00  qemu-1.2.1.tar.bz2

So probably the 'libcacard' package should be removed.  I'm not
exactly sure why it exists in the first place.  Perhaps the library
was originally separate?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
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
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: cogl soname bump

2013-01-29 Thread Andrey Ponomarenko


Peter Robinson wrote:

Sorry, I missed the cogl soname bump when I pushed the build last
night, I'll work to rebuild associated deps now, any help appreciated.


See future cogl soname bumps and ABI breaks analysis here: 
http://upstream-tracker.org/versions/cogl.html


--
Andrey Ponomarenko, ROSA Lab.

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

uriparser / Re: releasing ownership (maintainers/co-maintainers required)

Just forwarding, because I've had a look:

On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 uriparser -- URI parsing library - RFC 3986

http://bugz.fedoraproject.org/uriparser

There's an open ticket requesting an upgrade, claiming that the current
release in Fedora is more than three years old. The package is also in
EPEL, similarly out-of-date.

$ repoquery --whatrequires uriparser
fapg-0:0.41-5.fc18.x86_64
uriparser-devel-0:0.7.5-6.fc18.i686
uriparser-devel-0:0.7.5-6.fc18.x86_64

$ yum info fapg|grep Summ
Summary : Fast Audio Playlist Generator

Written in C.

-- 
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git5.1.fc19.x86_64
loadavg: 0.15 0.19 0.14
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Simplify Java/Maven Packaging using XMvn

2013-01-29 Thread Stanislav Ochotnicky

Quoting Toshio Kuratomi (2013-01-28 23:52:30)
 On Mon, Jan 28, 2013 at 09:51:42AM +, Jaroslav Reznik wrote:
  
  Goal of this feature is to migrate all packages to use XMvn instead of mvn-
  rpmbuild script. Several packages have already been converted as part of 
  initial testing:
  
  http://pkgs.fedoraproject.org/cgit/maven-surefire.git/tree/maven-
  surefire.spec
  http://pkgs.fedoraproject.org/cgit/maven-doxia.git/tree/maven-doxia.spec
  http://pkgs.fedoraproject.org/cgit/slf4j.git/tree/slf4j.spec
  http://pkgs.fedoraproject.org/cgit/apache-commons-
  compress.git/tree/apache-commons-compress.spec
 
 From a quick look at one of these specs, this Feature will need a packaging
 guidelines update.
 
 But also from that quick look, the packaging guidelines update doesn't look
 like it will be too hard or controversial.

Yes that is part of the plan. I just need to think of nice way to do it so we
don't create unnecessary mess of current guidelines and allow for transition
period. I don't want to force anyone to migrate who isn't (yet) convinced.
I'll update the wiki with this info in a bit

-- 
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

Just forwarding, because I've had a look:

On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 enet -- Thin, simple and robust network layer on top of UDP

http://bugz.fedoraproject.org/enet
There have been a few upstream releases.
There are three co-maintainers for this already.

$ repoquery --whatrequires enet
0ad-0:0.0.12-3.fc19.x86_64
enet-devel-0:1.3.3-2.fc18.i686
enet-devel-0:1.3.3-2.fc18.x86_64
redeclipse-0:1.3.1-1.fc19.x86_64
redeclipse-server-0:1.3.1-1.fc19.x86_64
speed-dreams-0:2.1.0-12.trunk_r4810.fc19.1.i686
speed-dreams-0:2.1.0-12.trunk_r4810.fc19.1.x86_64
sumwars-0:0.5.6-10.fc19.x86_64

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

Re: releasing ownership (maintainers/co-maintainers required)

On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 freeimage -- Multi-format image decoder library

This one is a mystery:

2009-05-21 (!) https://bugzilla.redhat.com/501993
RFE: update to 3.12.0

No reply at all. :(

There's a co-maintainer, two more for EPEL, and other people have done
builds: http://koji.fedoraproject.org/koji/packageinfo?packageID=5982

Guys, don't you talk to eachother about the packages you co-maintain?
Or just in private?

Can you tell anything about version 3.12.0? Has it been tested?
Is it bad?

Btw, EPEL works a lot better, if the EPEL package maintainers are also
actively taking care of the corresponding Fedora packages.

Regards,
-- 
Michael Schwendt
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git5.1.fc19.x86_64
loadavg: 0.00 0.06 0.11
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange subscriptions to Bugzilla bugs

2013-01-29 Thread Patrick Monnerat

rutadeevacuacion continues its crazy job: (s)he's just subscribed to one
of my review request (closed 2009-08-07) BZ#505356.
Although this does not affect me personally, I think this is some
obscure way of mass parasitizing our infrastructure. No way to blacklist
this address ?

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

Re: Proposed F19 Feature: Yum Groups as Objects

On Monday 28 of January 2013 10:12:29 Stephen Gallagher wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On Mon 28 Jan 2013 09:43:56 AM EST, Jan Zelený wrote:
  On 28. 1. 2013 at 08:21:57, Stephen Gallagher wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 01/28/2013 07:58 AM, Jaroslav Reznik wrote:
  = Features/YumGroupsAsObjects =
  https://fedoraproject.org/wiki/Features/YumGroupsAsObjects
  
  Feature owner(s): James Antill ja...@fedoraproject.org
  
  Change the default yum configuration from group_command=compat to
  group_command=objects.
  
  == Detailed description == Currently yum groups work as a simple
  substitution, so yum group remove foo works as though you took
  every package from foo and passed it to yum remove. This tends to
  not be what users expect, for example yum group install kde-
  desktop and then yum group remove kde-desktop will end up
  removing packages (like abrt-desktop). This feature changes that so
  that groups are installed as real objects, meaning that when a user
  does yum group install foo yum will mark that the packages from
  foo are being installed (as before) but also that a group called
  foo is being installed and that those packages are installed
  because of it. Later if the group is removed, yum will remove the
  group and only those packages that were installed because of the
  group install/upgrade commands.
  
  This doesn't really seem like the optimal solution here. It seems to
  me that it might be a better solution that you note which groups
  were installed and then at 'yum group remove foo' you remove any
  packages in it that are not ALSO owned by other installed groups. That
  seems less prone to issues if you uninstall groups that have shared
  packages in anything other than reverse order of installation.
  
  Of course, after that we also have the issue of leaf nodes. Perhaps we
  should ignore any packages that are dependencies of other installed
  software too?
  
  Thank you for pointing this out. We are aware of this issue and we plan to
  address it. James already implemented something similar for repositories
  and to implement the same thing for groups, we first need groups to be
  treated as objects.
  
  Anyway as the proposal indicates, changing the default (treating groups as
  objects) won't have any impact on the behavior in this way. If you
  uninstall group, it will remove any packages that have been installed as
  dependencies. But the same thing happens today. AFAIU the only difference
  in behavior observed by users will be that packages that are explicitly
  installed won't be removed once the group is removed.
 
 While this is obviously an enhancement over the current state of
 things, I'm not certain it's a sufficient improvement to warrant a
 Feature. In my mind, the difficulty with handling the descendant
 packages on removal is a more interesting problem.

When I announced the feature, I understood it the same way - it's going to 
solve the problem in your mind. Also it changes defaults but seems even with 
defaults changes, the result will be same (very similar).

So yes, now I'm not sure this is really a Feature, even you know I'm fan of as 
many features as we can have not to miss anything important. And actually it 
served this purpose - there's discussion and clarification...

Jaroslav

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iEYEARECAAYFAlEGlV0ACgkQeiVVYja6o6PuoACfYM8rex0M06mRgUrMuFOGrQtj
 qMcAn329k7jfDUgz3ccbyfoTk1pSZxGB
 =4YsU
 -END PGP SIGNATURE-

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

Re: Strange subscriptions to Bugzilla bugs

2013-01-29 Thread Christopher Meng

I've helped ccing infrastructure team.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: GLIBC 2.17

2013-01-29 Thread Florian Weimer


On 01/28/2013 06:31 PM, Bill Nottingham wrote:

Florian Weimer (fwei...@redhat.com) said:

See http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv
for code snippets to implement in the change in a
backwards-compatible fashion.  Unfortunately, glibc upstream
insistent on renaming before making the symbol official.


I'm a little confused by the 'unfortunately' here - if apps are using a
private symbol, they should expect that they may need to change later.


Precisely because it's in the private namespace, glibc could just have 
documented the existing __secure_getenv symbol.  It's not that there 
aren't any public functions starting with __.  But this was rejected by 
upstream, and now we have the __secure_getenv compatibility symbol (not 
usable for fresh linking), secure_getenv, and __libc_secure_getenv for 
internal glibc use (but which is still public for technical reasons).


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: cpptest / Re: releasing ownership (maintainers/co-maintainers required)

Sounds good. I'll update it.

Dan

On Tue, Jan 29, 2013 at 1:02 AM, Michael Schwendt mschwe...@gmail.com wrote:
 On Mon, 28 Jan 2013 23:56:50 -0800, Dan Mashal wrote:

  cpptest -- A portable and powerful and simple unit testing framework for 
  C++


 I'll take this one.

 Only uriparser uses it currently.
 And there's an 1.1.2 upstream release, too.

 --
 Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git5.1.fc19.x86_64
 loadavg: 0.11 0.04 0.07
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: GLIBC 2.17

2013-01-29 Thread Jakub Jelinek

On Tue, Jan 29, 2013 at 10:39:21AM +0100, Florian Weimer wrote:
 On 01/28/2013 06:31 PM, Bill Nottingham wrote:
 Florian Weimer (fwei...@redhat.com) said:
 See http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv
 for code snippets to implement in the change in a
 backwards-compatible fashion.  Unfortunately, glibc upstream
 insistent on renaming before making the symbol official.
 
 I'm a little confused by the 'unfortunately' here - if apps are using a
 private symbol, they should expect that they may need to change later.
 
 Precisely because it's in the private namespace, glibc could just
 have documented the existing __secure_getenv symbol.  It's not that
 there aren't any public functions starting with __.  But this was
 rejected by upstream, and now we have the __secure_getenv
 compatibility symbol (not usable for fresh linking), secure_getenv,
 and __libc_secure_getenv for internal glibc use (but which is still
 public for technical reasons).

A @@GLIBC_PRIVATE symbol is not public.

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

unhide / Re: releasing ownership (maintainers/co-maintainers required)

Just forwarding, because I've had a look:
The final one for today. ;)

On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 unhide -- Tool to find hidden processes and TCP/UDP ports from rootkits

Sounds interesting, didn't knew that one.


Project site tells rkhunter uses it:
  $ repoquery --whatrequires unhide
  $
Hmmm?
What's known here?


Unhide 20100201
http://www.security-projects.com/?Unhide

says: ** This project has been moved to http://www.unhide-forensics.info ***
Please update your bookmark


Current Stable Version:
--  2012-12-29

Apparently much newer.

Similarly to chkrootkit (but not limited to that one), a tool like this
can break in funny ways without anything discovering it. For example, if
it starts parsing something incorrectly, it can happen that it doesn't
find anything. This can be hard to debug without a test-case.

-- 
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git5.1.fc19.x86_64
loadavg: 1.08 0.36 0.16
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

2013-01-29 Thread Tomas Radej

Hi,

On Tue, 29 Jan 2013 03:37:43 +0200
Rakesh Pandit rakesh.pan...@gmail.com wrote:

 taskcoach -- Your friendly task manager
 xsel -- Command line clipboard and X selection tool

I'll take these two.

TR

-- 
Tomas Radej tra...@redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libcacard can never be installed (was: Re: Another unannounced soname bump: libseccomp)

On Tue, 29 Jan 2013 09:03:42 +, Richard W.M. Jones wrote:

 It looks as if the qemu source contains the one canonical copy of
 libcacard.  The separate 'libcacard' package has the following sources
 file:
 
 $ cat sources 
 189bc5b87281a72f8c72a0f7ebaa6d00  qemu-1.2.1.tar.bz2
 
 So probably the 'libcacard' package should be removed.  I'm not
 exactly sure why it exists in the first place.  Perhaps the library
 was originally separate?

It seems so. Years ago:

  $ rpmls -p libcacard-0.1.2-1.fc15.src.rpm
  -rw-rw-r--  libcacard-0.1.2.tar.bz2
  -rw-r--r--  libcacard.spec
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

icu 50 rebuilt without --disable-renaming again

2013-01-29 Thread Eike Rathke

Hi,

As there seems no proper way to resolve the mess of rhbz#856594
I rebuilt icu-50.1.2-3.fc19 without --disable-renaming again.

Please, if you built between Friday and today against icu-50.1.2-1.fc19
or icu-50.1.2-2.fc19 do another round against icu-50.1.2-3.fc19

Please accept my apology, I'm very unhappy with how this went.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack


pgp9BEatOBY4Q.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Native vagrant packages for Fedora

2013-01-29 Thread Ingvar Hagelund


Vagrant offers scripted provisioning and deployment of virtual
instances, removing the infamous but it works om my laptop
obstacle. Vagrant is well-known and much used and praised in the
devops community. Its home page is http://vagrantup.com/

Though VirtualBox is the current supported target, future versions of
vagrant may support other hypervizors as well, including kvm. Being in
itself free software under the MIT license, I think vagrant could be
included in fedora.

While an upstream rpm exists (putting all dependent packages in /opt)
a native fedora package of vagrant was missing. So I wrapped one up.

Review request: https://bugzilla.redhat.com/show_bug.cgi?id=905396

It depends on the following packages missing from fedora 18:

rubygem-log4r = 1.1.9  2.0.0
  Fix: Build new package.
  Package review request: 
https://bugzilla.redhat.com/show_bug.cgi?id=905240


rubygem-childprocess =0.3.1  0.4.0 (0.3.6 in rawhide)
  Fix: Grab 0.3.6 package from rawhide

rubygem-json = 1.5.1,  1.6.0 (1.6.5 in f18, 1.9.1 in rawhide)
  Fix: Build rubygem-json15, roughly based on current package.
  Package review request: 
https://bugzilla.redhat.com/show_bug.cgi?id=905389


rubygem-net-ssh = 2.2.2  2.3.0 (2.2.1 in rawhide)
  Fix: Build 2.2.2 package based on current package.
  Update request: bz https://bugzilla.redhat.com/show_bug.cgi?id=905393

yum repo with prebuilt packages for f17 and f18 available here:
http://users.linpro.no/ingvar/vagrant/


Ingvar

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

Re: Proposed F19 Feature: GLIBC 2.17

2013-01-29 Thread Florian Weimer


On 01/29/2013 10:47 AM, Jakub Jelinek wrote:


Precisely because it's in the private namespace, glibc could just
have documented the existing __secure_getenv symbol.  It's not that
there aren't any public functions starting with __.  But this was
rejected by upstream, and now we have the __secure_getenv
compatibility symbol (not usable for fresh linking), secure_getenv,
and __libc_secure_getenv for internal glibc use (but which is still
public for technical reasons).


A @@GLIBC_PRIVATE symbol is not public.


nss_hesiod needs secure_getenv, so a non-private symbol is needed.  In 
any case, I can link against __libc_secure_getenv in Fedora rawhide:


mock-chroot[root@oldenburg tmp]# rpm -q glibc
glibc-2.17-1.fc19.x86_64
mock-chroot[root@oldenburg tmp]# cat t.c
void __libc_secure_getenv();

int main()
{
  __libc_secure_getenv();
  return 0;
}
mock-chroot[root@oldenburg tmp]# gcc t.c
mock-chroot[root@oldenburg tmp]#

--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

RAWHIDE USERS: BEWARE RPM 4.11.0-0.beta1.2.fc19!

2013-01-29 Thread Panu Matilainen



Apologies for shouting but we have a genuine, rare, rpmdb-eating bug 
(shade of dark paperbag) at hand:


DO NOT UPGRADE TO rpm-4.11.0-0.beta1.2.fc19!

The buggy version is expected to appear in todays rawhide-push. I've 
built a new version where the broken %ghost-related patch is reverted 
but there's a day-long danger-zone before the new build will be pushed.


It's best just to avoid upgrading to the buggy rpm version at all, but
if you have already happened to update to it one way or the other, DONT 
PANIC but BACK UP /var/lib/rpm/ before anything else. Merely upgrading 
to that version wont kill your rpmdb, but on the next update of rpm 
itself, it will COMPLETELY ERASE /var/lib/rpm/ contents. Recovering 
isn't exactly hard if you have an up-to-date backup, but otherwise...


- Panu -


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

Re: Another unannounced soname bump: libseccomp

2013-01-29 Thread Andrey Ponomarenko



Adam Williamson wrote:

On Mon, 2013-01-28 at 19:44 +, Richard W.M. Jones wrote:

DEBUG util.py:264:  Error: Package: 2:qemu-system-mips-1.3.0-5.fc19.x86_64 
(build)
DEBUG util.py:264: Requires: libseccomp.so.1()(64bit)
DEBUG util.py:264:  Error: Package: 2:qemu-system-or32-1.3.0-5.fc19.x86_64 
(build)
DEBUG util.py:264: Requires: libseccomp.so.1()(64bit)
DEBUG util.py:264:  Error: Package: 
2:qemu-system-microblaze-1.3.0-5.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libseccomp.so.1()(64bit)
[etc]
full log: http://kojipkgs.fedoraproject.org//work/tasks/9474/4909474/root.log

This seems to have been caused by this build:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=380981

Affected packages:

- libcacard-tools
- qemu

So, just as a path for anyone who's interested to take a look down, I
think we could potentially Do Something about all these unannounced
soname bumps. We do have a test in autoqa that catches them, and doesn't
seem to have a huge amount of 'false positives'.


FYI

http://upstream-tracker.org/versions/libseccomp.html


The test case is
rpmguard, and here is it noticing this soname bump:

http://autoqa.fedoraproject.org/resultsdb/frontend/testrun?id_=956918
http://autoqa.fedoraproject.org/results/511987-autotest/virt02.qa/rpmguard/results/libseccomp-2.0.0-0.f.html

N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs:
i686) ...
W: provision-added libseccomp.so.2
W: provision-removed libseccomp.so.1

N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs: 
x86_64) ...
W: provision-added libseccomp.so.2()(64bit)
W: provision-removed libseccomp.so.1()(64bit)

now rpmguard does various other things, so we'd need to filter out the
provision-removed (especially) results for this case. But we do at least
have this information being captured by autoqa, I think.

That's all I got!


--
Andrey Ponomarenko, ROSA Lab.

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

Re: Releasing ownership

2013-01-29 Thread Brendan Jones


On 01/29/2013 07:59 AM, lakshminaras2...@gmail.com wrote:

I am releasing ownership of the following packages due to lack of time
gnome-guitar -- A small suite of applications for the guitarist


I have taken this one.

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

Re: icu 50 rebuilt without --disable-renaming again

2013-01-29 Thread Mamoru TASAKA


Eike Rathke wrote, at 01/29/2013 07:11 PM +9:00:

Hi,

As there seems no proper way to resolve the mess of rhbz#856594
I rebuilt icu-50.1.2-3.fc19 without --disable-renaming again.

Please, if you built between Friday and today against icu-50.1.2-1.fc19
or icu-50.1.2-2.fc19 do another round against icu-50.1.2-3.fc19

Please accept my apology, I'm very unhappy with how this went.

   Eike


Note that with this change, libicu-50.1.2-2.fc19 and libicu-50.1.2-3.fc19
has the libraries with the same sonames, but containing _different_
symbols:

# rpmsodiff libicu-50.1.2-*rpm
common sonames:
libicudata.so.50/usr/lib/libicudata.so.50.1.2   
/usr/lib/libicudata.so.50.1.2
libicui18n.so.50/usr/lib/libicui18n.so.50.1.2   
/usr/lib/libicui18n.so.50.1.2
libicuio.so.50  /usr/lib/libicuio.so.50.1.2 /usr/lib/libicuio.so.50.1.2
libicule.so.50  /usr/lib/libicule.so.50.1.2 /usr/lib/libicule.so.50.1.2
libiculx.so.50  /usr/lib/libiculx.so.50.1.2 /usr/lib/libiculx.so.50.1.2
libicutest.so.50/usr/lib/libicutest.so.50.1.2   
/usr/lib/libicutest.so.50.1.2
libicutu.so.50  /usr/lib/libicutu.so.50.1.2 /usr/lib/libicutu.so.50.1.2
libicuuc.so.50  /usr/lib/libicuuc.so.50.1.2 /usr/lib/libicuuc.so.50.1.2

libicudata.so.50 definitions unchanged

--- libicu-50.1.2-2.fc19/libicui18n.so.50   2013-01-29 05:38:25.0 
+0900
+++ libicu-50.1.2-3.fc19/libicui18n.so.50   2013-01-29 19:05:41.0 
+0900
@@ -1,4343 +1,4343 @@
 _Z17ucol_tok_doSetTopP15UColTokenParserP10UErrorCode   W
-_Z21ucol_freeOffsetBufferPN3icu11collIterateE  T
+_Z24ucol_freeOffsetBuffer_50PN6icu_5011collIterateET
 _Z26ucol_tok_addToExtraCurrentP15UColTokenParserPKtiP10UErrorCode  W
-_Z27ucol_tok_getRulesFromBundlePvPKcS1_PiP10UErrorCode T
-_Z31uspoof_getSkeletonUnicodeStringPK13USpoofCheckerjRKN3icu13UnicodeStringERS3_P10UErrorCode
  T
...
...
+_Z30ucol_tok_getRulesFromBundle_50PvPKcS1_PiP10UErrorCode  T
+_Z34uspoof_getSkeletonUnicodeString_50PK13USpoofCheckerjRKN6icu_5013UnicodeStringERS3_P10UErrorCode
T
...
...
4966 symbols removed
4966 symbols added

So packages rebuilt against icu-50.1.2-1.fc19  or icu-50.1.2-2.fc19
won't receive any errors from rpm dependency resolver if icu is
to be upgraded to icu-50.1.2-3.fc19, but they will break silently
(unless they are rebuilt against newer icu).

Regards,
Mamoru



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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Monday, January 28, 2013, Máirín Duffy wrote:

 On Mon 28 Jan 2013 02:17:29 PM EST, Michael Cronenworth wrote:
  Going away isn't the correct phrase. The UI of Fallback Mode is going
  to transition to a new feature called Classic Mode. It's an official
  feature of Gnome 3.8.
 
  http://blogs.gnome.org/mclasen/2013/01/25/gnome-3-7-at-the-halfway-mark/

 Won't the new GNOME 3 classic mode effectively render Cinnamon, MATE,
 and friends obsolete?

 ~m
 --
 devel mailing list
 devel@lists.fedoraproject.org javascript:;
 https://admin.fedoraproject.org/mailman/listinfo/devel


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Monday, January 28, 2013, Máirín Duffy wrote:

 On 01/28/2013 02:06 AM, Dan Mashal wrote:
  You don't see the point of MATE or Cinnamon? How long did you play with
  them 5 minutes?

 Do you remember the GNOME 1.x = 2.x transition? Similarly to how there
 are forks of GNOME now to 'keep the GNOME 2 candle burning,' there were
 forks of GNOME 1.x to 'keep the GNOME 1 candle burning.'

 Do you remember what they were called? I didn't; I had to look 'em up.
 Do you ever wonder what happened to them? Dead projects nobody seems to
 remember. Do we really want to switch to a desktop that history has
 shown is likely to become a dead project in a few years?

 http://osdir.com/modules.php?op=modloadname=Newsfile=articlesid=1295

 It also doesn't seem smart to switch from a desktop on the basis that
 Linus Torvalds and Alan Cox - kernel developers, not UI experts or even
 typical desktop users by any means - don't like it. I think switching
 the desktop that has been our default for over 10 years and 18 releases
 requires just a bit more research and reason than that.

 ~m


Lets all listen to Miami because she did a great job with anaconda 18 UI
design, knows more than Linus, Alan Cox and is absolutely right on
everything!

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tuesday, January 29, 2013, Dan Mashal wrote:



 On Monday, January 28, 2013, Máirín Duffy wrote:

 On 01/28/2013 02:06 AM, Dan Mashal wrote:
  You don't see the point of MATE or Cinnamon? How long did you play with
  them 5 minutes?

 Do you remember the GNOME 1.x = 2.x transition? Similarly to how there
 are forks of GNOME now to 'keep the GNOME 2 candle burning,' there were
 forks of GNOME 1.x to 'keep the GNOME 1 candle burning.'

 Do you remember what they were called? I didn't; I had to look 'em up.
 Do you ever wonder what happened to them? Dead projects nobody seems to
 remember. Do we really want to switch to a desktop that history has
 shown is likely to become a dead project in a few years?

 http://osdir.com/modules.php?op=modloadname=Newsfile=articlesid=1295

 It also doesn't seem smart to switch from a desktop on the basis that
 Linus Torvalds and Alan Cox - kernel developers, not UI experts or even
 typical desktop users by any means - don't like it. I think switching
 the desktop that has been our default for over 10 years and 18 releases
 requires just a bit more research and reason than that.

 ~m


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

F18: Anaconda installer: Are there going to be any updates to this

2013-01-29 Thread Terry Barnaby

I am trying to build a spin of Fedora18 for local use as I normally do with
Fedora releases using pungi. All has been built fine but the installation
fails with an Anaconda popup stating The following error occurred ... with
no information on the error at all and nothing in the various virtual terminal
windows.

Obviously the Anaconda installer is pretty rough at the moment.

1. Is there a good way to debug it ?
2. Are there likely to be updated releases of Anaconda during F18's life time ?

Cheers


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop


On 01/27/2013 03:53 PM, Jaroslav Reznik wrote:

= Features/Cinnamon as Default Desktop =
https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

Feature owner(s): Eric Smith e...@brouhaha.com

This feature proposes that Fedora switch the default desktop interface from
Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that is more
familiar to Windows and Gnome 2 users than the standard Gnome Shell interface,
while being built from Gnome 3 components.

== Detailed description ==
The Gnome 3 interface is substantially different that the traditional desktop
interfaces on both Linux and Windows. While it is good that there is research
into new user interface concepts, many users prefer to have a traditional
interface that they are accustomed to. Unfortunately it is difficult or
impossible to assess what fraction of the user base prefers Gnome Shell vs. a
more traditional interface. I'm not trying to start (or continue) a flame war
here, so I won't state any of my own criticisms of Gnome Shell here, but I
will observe that a number of very high profile people in the Linux community,
such as Linus Torvalds and Alan Cox, have publicly announce that due to
problems with Gnome Shell they are switching to a different desktop and/or
Linux distribution.

I submit the proposition that it is easier for a user doing a new Fedora
install to start with a traditional desktop, and switch to the Gnome Shell if
they prefer that, than to start with Gnome Shell and switch to a traditional
desktop.

The Cinnamon desktop provides a traditional desktop while being based on the
latest Gnome and GTK components, so it seems like a better candidate for a
default desktop than MATE, which is based on older components.
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce


Eric,
do you have support of all teams, which will work with you? Design, QA, 
docs, releng to create spin, ...? It's not only about popularity of DE, 
but also about future support of Cinnamon in Fedora.


I'm personally not interested in any gnome fork, so I'm interested only 
in stability of the default.


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread drago01

On Tue, Jan 29, 2013 at 12:52 PM, Dan Mashal dan.mas...@gmail.com wrote:


 On Monday, January 28, 2013, Máirín Duffy wrote:

 On 01/28/2013 02:06 AM, Dan Mashal wrote:
  You don't see the point of MATE or Cinnamon? How long did you play with
  them 5 minutes?

 Do you remember the GNOME 1.x = 2.x transition? Similarly to how there
 are forks of GNOME now to 'keep the GNOME 2 candle burning,' there were
 forks of GNOME 1.x to 'keep the GNOME 1 candle burning.'

 Do you remember what they were called? I didn't; I had to look 'em up.
 Do you ever wonder what happened to them? Dead projects nobody seems to
 remember. Do we really want to switch to a desktop that history has
 shown is likely to become a dead project in a few years?

 http://osdir.com/modules.php?op=modloadname=Newsfile=articlesid=1295

 It also doesn't seem smart to switch from a desktop on the basis that
 Linus Torvalds and Alan Cox - kernel developers, not UI experts or even
 typical desktop users by any means - don't like it. I think switching
 the desktop that has been our default for over 10 years and 18 releases
 requires just a bit more research and reason than that.

 ~m


 Lets all listen to Miami because she did a great job with anaconda 18 UI
 design, knows more than Linus, Alan Cox and is absolutely right on
 everything!

Stop trolling please.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Monday, January 28, 2013, Matthias Clasen wrote:

 - Original Message -
  = Features/Cinnamon as Default Desktop =


  I submit the proposition that it is easier for a user doing a new
  Fedora
  install to start with a traditional desktop, and switch to the Gnome
  Shell if
  they prefer that, than to start with Gnome Shell and switch to a
  traditional
  desktop.
 
  The Cinnamon desktop provides a traditional desktop while being based
  on the
  latest Gnome and GTK components, so it seems like a better candidate
  for a
  default desktop than MATE, which is based on older components.

 Some facts:

 - Cinnamon started out as 'using GNOME components', but it is not a full
 fork of mutter, gnome-shell and nautilus, at least, and bug-fixes are not
 going either way...

 - GNOME 3.8 will replace the dismal fallback mode with a new 'classic'
 mode that is actually based on the latest GNOME components, and will be a
 more 'traditional desktop', whatever that means.
 --
 devel mailing list
 devel@lists.fedoraproject.org javascript:;
 https://admin.fedoraproject.org/mailman/listinfo/devel


Let's see how lightweight, bug free and usable it is. Why don't you just
merge the 3 projects instead of wasting your time? We could all work
together.

There could be different flavors of Gnome. Now I know that we are both
biased here, however what it really feels like here is REDHAT
employees want Gnome 3 and they are giving a bunch of bullshit excuses on
why it should be, referencing various stupid apple to orange comparisons
from 10 years ago. Why don't we take a poll where no Red Hat employees can
vote. Only non Red Hat Fedora employees and the board itself can make a
final decision after considering what FESCO has to say about it. Face it.
Fedora 15 Gnome 3 cause a major uproar. Anaconda on RHEL6 is easier to use
than Anaconda 18. Almost 3 years later and oh yeah we realized we should
probably add a real fallback mode to Gnome 3. Meanwhile the main people
writing code are not the community.  Meanwhile MATE is lighter weight than
Gnome 2.3, has numerous bug fixes, will have full support for
systems/logind.. Something even Gnome 3 still has trouble with.

Is it really that scary for you guys to think about something else besides
Gnome 3 and KDE?

Not enough support? Then step up and quit whining. You know how to help,
Red Hat employees. Don't be selfish. This is Fedora not RHEL. This is a
community based distribution not Red Hats playground. Please feel free to
correct me if I'm wrong.

Everyone loves to dance around the fact about what Fedora is or isn't.

This isn't one persons decision and its not 2003.

Get with the times. Your projects failed. Sure a lot of people like it.
Then again a lot of people don't. And we wonder why there are less people
using Fedora.

And then we wonder why MATE and Cinnamon got the most press coverage in
Fedora 18 and why there has been a huge user spike in the last 30 days. It
hasn't been because of systemd, Gnome 3.6, and Anaconda 18. You are on
serious drugs if you believe that.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Martin Sourada

Hi Dan,

On Tue, 29 Jan 2013 03:52:03 -0800 
Dan Mashal wrote:
 
 Lets all listen to Miami because she did a great job with anaconda 18
 UI design, knows more than Linus, Alan Cox and is absolutely right on
 everything!
 
Now, as much as I strongly disagree with the UI changes anaconda made
in F18, I just as much loathe, maybe even more, getting personal in
technical discussion. You're going overboard, I strongly believe, with
this comment. Please calm down.

And now, while I'm at it -- something on topic:
-1 from me for Cinnamon. As much as I'd like to see something different
as our default desktop than Gnome Shell (which is, just as the new
Anaconda, going down the dumbing-down road where your PC is supposedly
more clever than you and knows better than you what you want), I don't
think it's wise to switch to something that has been only recently
imported into Fedora, has next to none history and does not have that
kind of strong developers' support (aka people working on it either
upstream or in Fedora) Gnome does.

When you've got a strong developer base, come back again and we can
consider it seriously.

Martin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Olav Vitters

On Tue, Jan 29, 2013 at 04:13:34AM -0800, Dan Mashal wrote:
 Let's see how lightweight, bug free and usable it is. Why don't you just
 merge the 3 projects instead of wasting your time? We could all work
 together.

MATE developers actually have GNOME git accounts now.

 There could be different flavors of Gnome. Now I know that we are both
 biased here, however what it really feels like here is REDHAT
 employees want Gnome 3 and they are giving a bunch of bullshit excuses on
 why it should be, referencing various stupid apple to orange comparisons
 from 10 years ago. Why don't we take a poll where no Red Hat employees can

bullshit, stupid

 vote. Only non Red Hat Fedora employees and the board itself can make a
 final decision after considering what FESCO has to say about it. Face it.
 Fedora 15 Gnome 3 cause a major uproar. Anaconda on RHEL6 is easier to use
 than Anaconda 18. Almost 3 years later and oh yeah we realized we should
 probably add a real fallback mode to Gnome 3. Meanwhile the main people

GNOME classic is not the same as a fallback mode.

 writing code are not the community.  Meanwhile MATE is lighter weight than
 Gnome 2.3, has numerous bug fixes, will have full support for
 systems/logind.. Something even Gnome 3 still has trouble with.

MATE did not have that much development, nor that many developers if you
compare it to the amount of work done between a GNOME 2.x release.

Could you reference the bugs that GNOME 3 has problems with systemd?
Because it works fine for me.

 Is it really that scary for you guys to think about something else besides
 Gnome 3 and KDE?
 
 Not enough support? Then step up and quit whining. You know how to help,
 Red Hat employees. Don't be selfish. This is Fedora not RHEL. This is a
 community based distribution not Red Hats playground. Please feel free to
 correct me if I'm wrong.

I suggest you actually do some work instead of showing that you dislike
Red Hat employees.

 Everyone loves to dance around the fact about what Fedora is or isn't.
 
 This isn't one persons decision and its not 2003.
 
 Get with the times. Your projects failed. Sure a lot of people like it.
 Then again a lot of people don't. And we wonder why there are less people
 using Fedora.

You say projects: which projects exactly?

 And then we wonder why MATE and Cinnamon got the most press coverage in
 Fedora 18 and why there has been a huge user spike in the last 30 days. It
 hasn't been because of systemd, Gnome 3.6, and Anaconda 18. You are on
 serious drugs if you believe that.

serious drugs

Quit with attacking people, then maybe people will actually listen. At
the moment you are very vague and unspecific (e.g. bug references, not
vague claims). The only think you make clear is that you're angry.

-- 
Regards,
Olav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tuesday, January 29, 2013, Marcela Mašláňová wrote:

On 01/27/2013 03:53 PM, Jaroslav Reznik wrote:

= Features/Cinnamon as Default Desktop =
https://fedoraproject.org/**wiki/Features/Cinnamon_as_**Default_Desktophttps://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

Feature owner(s): Eric Smith e...@brouhaha.com

This feature proposes that Fedora switch the default desktop interface
from
Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that is more
familiar to Windows and Gnome 2 users than the standard Gnome Shell
interface,
while being built from Gnome 3 components.

== Detailed description ==
The Gnome 3 interface is substantially different that the traditional
desktop
interfaces on both Linux and Windows. While it is good that there is
research
into new user interface concepts, many users prefer to have a traditional
interface that they are accustomed to. Unfortunately it is difficult or
impossible to assess what fraction of the user base prefers Gnome Shell
vs. a
more traditional interface. I'm not trying to start (or continue) a flame
war
here, so I won't state any of my own criticisms of Gnome Shell here, but I
will observe that a number of very high profile people in the Linux
community,
such as Linus Torvalds and Alan Cox, have publicly announce that due to
problems with Gnome Shell they are switching to a different desktop and/or
Linux distribution.

I submit the proposition that it is easier for a user doing a new Fedora
install to start with a traditional desktop, and switch to the Gnome
Shell if
they prefer that, than to start with Gnome Shell and switch to a
traditional
desktop.

The Cinnamon desktop provides a traditional desktop while being based on
the
latest Gnome and GTK components, so it seems like a better candidate for a
default desktop than MATE, which is based on older components.
__**_
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/devel-**announcehttps://admin.fedoraproject.org/mailman/listinfo/devel-announce

Eric,
do you have support of all teams, which will work with you? Design, QA,
docs, releng to create spin, ...? It's not only about popularity of DE, but
also about future support of Cinnamon in Fedora.

I'm personally not interested in any gnome fork, so I'm interested only in
stability of the default.

Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel

I'm sure QA, releng, docs, etc will go with what the community decides.

Lets have a poll. A very public one.

On the main website. Not somebody's blog. And let's let the users decide
what they want.

I'll tell you what, last time I checked #1 spin is KDE.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tue, Jan 29, 2013 at 5:52 AM, Dan Mashal dan.mas...@gmail.com wrote:



 On Monday, January 28, 2013, Máirín Duffy wrote:

 On 01/28/2013 02:06 AM, Dan Mashal wrote:
  You don't see the point of MATE or Cinnamon? How long did you play with
  them 5 minutes?

 Do you remember the GNOME 1.x = 2.x transition? Similarly to how there
 are forks of GNOME now to 'keep the GNOME 2 candle burning,' there were
 forks of GNOME 1.x to 'keep the GNOME 1 candle burning.'

 Do you remember what they were called? I didn't; I had to look 'em up.
 Do you ever wonder what happened to them? Dead projects nobody seems to
 remember. Do we really want to switch to a desktop that history has
 shown is likely to become a dead project in a few years?

 http://osdir.com/modules.php?op=modloadname=Newsfile=articlesid=1295

 It also doesn't seem smart to switch from a desktop on the basis that
 Linus Torvalds and Alan Cox - kernel developers, not UI experts or even
 typical desktop users by any means - don't like it. I think switching
 the desktop that has been our default for over 10 years and 18 releases
 requires just a bit more research and reason than that.

 ~m


 Lets all listen to Miami because she did a great job with anaconda 18 UI
 design, knows more than Linus, Alan Cox and is absolutely right on
 everything!

 While I support your right to express disagreement, kindly do so without
personal attacks.

-J


 Dan

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




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 08:33, Emmanuel Seyman wrote:
 * Rakesh Pandit [29/01/2013 03:37] :

 perl-Search-Xapian -- Xapian perl bindings

 I'll gladly take this one.

[..]

You can take it now.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Martin Sourada

On Mon, 28 Jan 2013 14:27:42 -0500 
Máirín Duffy wrote:

 On Mon 28 Jan 2013 02:17:29 PM EST, Michael Cronenworth wrote:
  Going away isn't the correct phrase. The UI of Fallback Mode is
  going to transition to a new feature called Classic Mode. It's an
  official feature of Gnome 3.8.
 
  http://blogs.gnome.org/mclasen/2013/01/25/gnome-3-7-at-the-halfway-mark/
 
 Won't the new GNOME 3 classic mode effectively render Cinnamon, MATE, 
 and friends obsolete?
 
It's just a set of extensions. We, who abandoned gnome when it became
gnome shell, didn't so only because of the DE interface, but also
because removing features, forcing choices on you, arrogant
know-it-better-than-you devs etc. Just having two panels with applets
won't make me happy if it's littered with symbolic icons, just as much
as the gnome apps which are having with each new release less and less
(useful) features. 

I only wish those people hell bent on keeping forking gnome would
invest their time on improving the existing alternatives instead (XFCE
and LXDE), it makes more sense to me, as at least XFCE-4.10 isn't much
lacking and with a bit of tweaking even looks and behaves rather similar
when compared to gnome-2.32...

Martin



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 08:41, Remi Collet  wrote:
 Le 29/01/2013 02:37, Rakesh Pandit a écrit :

 php-markdown -- Markdown implementation in PHP
 php-oauth -- PHP Authentication library for desktop to web applications
 php-pear-Auth -- Authentication provider for PHP
 php-xmpphp -- XMPPHP is the successor to Class.Jabber.PHP

 I have request co_owner on this ones.
 Can become owner if you want to release them


Released them. You can take ownership.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Pierre-Yves Chibon

On Tue, Jan 29, 2013 at 03:52:03AM -0800, Dan Mashal wrote:
On Monday, January 28, 2013, M�ir�n Duffy wrote:
 
  On 01/28/2013 02:06 AM, Dan Mashal wrote:
   You don't see the point of MATE or Cinnamon? How long did you play
  with
   them 5 minutes?
 
  Do you remember the GNOME 1.x = 2.x transition? Similarly to how there
  are forks of GNOME now to 'keep the GNOME 2 candle burning,' there were
  forks of GNOME 1.x to 'keep the GNOME 1 candle burning.'
 
  Do you remember what they were called? I didn't; I had to look 'em up.
  Do you ever wonder what happened to them? Dead projects nobody seems to
  remember. Do we really want to switch to a desktop that history has
  shown is likely to become a dead project in a few years?
 
  
 [1]http://osdir.com/modules.php?op=modloadname=Newsfile=articlesid=1295
 
  It also doesn't seem smart to switch from a desktop on the basis that
  Linus Torvalds and Alan Cox - kernel developers, not UI experts or even
  typical desktop users by any means - don't like it. I think switching
  the desktop that has been our default for over 10 years and 18 releases
  requires just a bit more research and reason than that.
 
  ~m
 
Lets all listen to Miami because she did a great job with anaconda 18 UI
design,�knows more than Linus, Alan Cox and is absolutely right on
everything!�
Dan

You are completely out of line here, please stop this or I'll ask the hall
monitor to take action.

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

File Pod-Perldoc-3.19_01.tar.gz uploaded to lookaside cache by ppisar

2013-01-29 Thread Petr Pisar

A file has been added to the lookaside cache for perl-Pod-Perldoc:

e586d0e1638156f2d69921cb18a94937  Pod-Perldoc-3.19_01.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 09:30, Matthias Runge wrote:
 On 01/29/2013 02:37 AM, Rakesh Pandit wrote:
 Hi,

 I request existing fedora packagers if they can take up these
 packages. For packages which already have active co-maintainers
 already, you can collaborate with them.


 django-mako -- Mako Templates Plugin for Django
 I'd take django-mako to retire it. There's also a bug for this.
 https://bugzilla.redhat.com/show_bug.cgi?id=848705

[..]

Thank you. You can take ownership now.

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

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 09:56, Dan Mashal wrote:
 cpptest -- A portable and powerful and simple unit testing framework for C++


 I'll take this one.
[..]

You can take it now.

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

[perl-Pod-Perldoc] 3.19_01 bump

2013-01-29 Thread Petr Pisar

commit 387d7de6fdd8862a26a72d8469f5cf2fc5a033eb
Author: Petr Písař ppi...@redhat.com
Date:   Tue Jan 29 13:31:47 2013 +0100

3.19_01 bump

 .gitignore|1 +
 perl-Pod-Perldoc.spec |7 +--
 sources   |2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8b7d583..0672df5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Pod-Perldoc-3.15_10.tar.gz
 /Pod-Perldoc-3.17.tar.gz
 /Pod-Perldoc-3.19.tar.gz
+/Pod-Perldoc-3.19_01.tar.gz
diff --git a/perl-Pod-Perldoc.spec b/perl-Pod-Perldoc.spec
index 1ea4f8c..26cfe52 100644
--- a/perl-Pod-Perldoc.spec
+++ b/perl-Pod-Perldoc.spec
@@ -1,7 +1,7 @@
-%global cpan_version 3.19
+%global cpan_version 3.19_01
 Name:   perl-Pod-Perldoc
 # let's overwrite the module from perl.srpm
-Version:%{cpan_version}.00
+Version:%(echo '%{cpan_version}' | sed 's/_/./')
 Release:1%{?dist}
 Summary:Look up Perl documentation in Pod format
 License:GPL+ or Artistic
@@ -90,6 +90,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Jan 29 2013 Petr Pisar ppi...@redhat.com - 3.19.01-1
+- 3.19_01 bump
+
 * Mon Jan 28 2013 Petr Pisar ppi...@redhat.com - 3.19.00-1
 - 3.19 bump
 
diff --git a/sources b/sources
index 7260605..213c356 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-74575be98a9539c473eaef18e1a49d26  Pod-Perldoc-3.19.tar.gz
+e586d0e1638156f2d69921cb18a94937  Pod-Perldoc-3.19_01.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop


On 01/29/2013 01:25 PM, Dan Mashal wrote:


On Tuesday, January 29, 2013, Marcela Mašláňová wrote:

On 01/27/2013 03:53 PM, Jaroslav Reznik wrote:

= Features/Cinnamon as Default Desktop =
https://fedoraproject.org/__wiki/Features/Cinnamon_as___Default_Desktop
https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

Feature owner(s): Eric Smith e...@brouhaha.com

This feature proposes that Fedora switch the default desktop
interface from
Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that
is more
familiar to Windows and Gnome 2 users than the standard Gnome
Shell interface,
while being built from Gnome 3 components.

== Detailed description ==
The Gnome 3 interface is substantially different that the
traditional desktop
interfaces on both Linux and Windows. While it is good that
there is research
into new user interface concepts, many users prefer to have a
traditional
interface that they are accustomed to. Unfortunately it is
difficult or
impossible to assess what fraction of the user base prefers
Gnome Shell vs. a
more traditional interface. I'm not trying to start (or
continue) a flame war
here, so I won't state any of my own criticisms of Gnome Shell
here, but I
will observe that a number of very high profile people in the
Linux community,
such as Linus Torvalds and Alan Cox, have publicly announce that
due to
problems with Gnome Shell they are switching to a different
desktop and/or
Linux distribution.

I submit the proposition that it is easier for a user doing a
new Fedora
install to start with a traditional desktop, and switch to the
Gnome Shell if
they prefer that, than to start with Gnome Shell and switch to a
traditional
desktop.

The Cinnamon desktop provides a traditional desktop while being
based on the
latest Gnome and GTK components, so it seems like a better
candidate for a
default desktop than MATE, which is based on older components.
_
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.__org/mailman/listinfo/devel-__announce
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Eric,
do you have support of all teams, which will work with you? Design,
QA, docs, releng to create spin, ...? It's not only about popularity
of DE, but also about future support of Cinnamon in Fedora.

I'm personally not interested in any gnome fork, so I'm interested
only in stability of the default.

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



I'm sure QA, releng, docs, etc will go with what the community decides.

Lets have a poll. A very public one.

On the main website. Not somebody's blog. And let's let the users decide
what they want.

I'll tell you what, last time I checked #1 spin is KDE.

Dan


Dan, voting about DE of choice is one thing. Doing the work is 
something different. I was waiting for reply from the one who wants to 
work on the change, not from you ;-)


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tuesday, January 29, 2013, Olav Vitters wrote:

 MATE developers actually have GNOME git accounts now.


I know that.

GNOME classic is not the same as a fallback mode.


I am skeptical.



 MATE did not have that much development, nor that many developers if you
 compare it to the amount of work done between a GNOME 2.x release.


 Paid full time employees vs non paid hobbyists.

 Could you reference the bugs that GNOME 3 has problems with systemd?
 Because it works fine for me.

You know how search RHBZ?


  Is it really that scary for you guys to think about something else
 besides
  Gnome 3 and KDE?
 
  Not enough support? Then step up and quit whining. You know how to help,
  Red Hat employees. Don't be selfish. This is Fedora not RHEL. This is a
  community based distribution not Red Hats playground. Please feel free to
  correct me if I'm wrong.

 I suggest you actually do some work instead of showing that you dislike
 Red Hat employees.


 Done.

 Everyone loves to dance around the fact about what Fedora is or isn't.
 
  This isn't one persons decision and its not 2003.
 
  Get with the times. Your projects failed. Sure a lot of people like it.
  Then again a lot of people don't. And we wonder why there are less people
  using Fedora.

 You say projects: which projects exactly?

  And then we wonder why MATE and Cinnamon got the most press coverage in
  Fedora 18 and why there has been a huge user spike in the last 30 days.
 It
  hasn't been because of systemd, Gnome 3.6, and Anaconda 18. You are on
  serious drugs if you believe that.

 serious drugs

 Quit with attacking people, then maybe people will actually listen. At
 the moment you are very vague and unspecific (e.g. bug references, not
 vague claims). The only think you make clear is that you're angry.


Nobody has been listening for the last 3 years.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop


On 01/29/2013 12:53 PM, Dan Mashal wrote:



On Tuesday, January 29, 2013, Dan Mashal wrote:



On Monday, January 28, 2013, Máirín Duffy wrote:

On 01/28/2013 02:06 AM, Dan Mashal wrote:
  You don't see the point of MATE or Cinnamon? How long did you
play with
  them 5 minutes?

Do you remember the GNOME 1.x = 2.x transition? Similarly to
how there
are forks of GNOME now to 'keep the GNOME 2 candle burning,'
there were
forks of GNOME 1.x to 'keep the GNOME 1 candle burning.'

Do you remember what they were called? I didn't; I had to look
'em up.
Do you ever wonder what happened to them? Dead projects nobody
seems to
remember. Do we really want to switch to a desktop that history has
shown is likely to become a dead project in a few years?

http://osdir.com/modules.php?op=modloadname=Newsfile=articlesid=1295

It also doesn't seem smart to switch from a desktop on the basis
that
Linus Torvalds and Alan Cox - kernel developers, not UI experts
or even
typical desktop users by any means - don't like it. I think
switching
the desktop that has been our default for over 10 years and 18
releases
requires just a bit more research and reason than that.

~m


Mizmo*



Please stop. This discussion stopped to be helpful ~10 emails ago and 
you are not helping to make a consensus about this topic by personal 
attacks.


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

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 11:16, Michael Schwendt wrote:
 Just forwarding, because I've had a look:


Thank you. Added enet-owner email to CC.

 On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 enet -- Thin, simple and robust network layer on top of UDP

 http://bugz.fedoraproject.org/enet
 There have been a few upstream releases.
 There are three co-maintainers for this already.

 $ repoquery --whatrequires enet
 0ad-0:0.0.12-3.fc19.x86_64
 enet-devel-0:1.3.3-2.fc18.i686
 enet-devel-0:1.3.3-2.fc18.x86_64
 redeclipse-0:1.3.1-1.fc19.x86_64
 redeclipse-server-0:1.3.1-1.fc19.x86_64
 speed-dreams-0:2.1.0-12.trunk_r4810.fc19.1.i686
 speed-dreams-0:2.1.0-12.trunk_r4810.fc19.1.x86_64
 sumwars-0:0.5.6-10.fc19.x86_64

@enet co-maintainers

Anyone wants to take it ?

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

Re: Proposed F19 Feature: Yum Groups as Objects

2013-01-29 Thread Stijn Hoop

On Mon, 28 Jan 2013 17:31:33 -0500
James Antill ja...@fedoraproject.org wrote:

 On Mon, 2013-01-28 at 15:04 +, Daniel P. Berrange wrote:
  On Mon, Jan 28, 2013 at 12:58:56PM +, Jaroslav Reznik wrote:
   = Features/YumGroupsAsObjects =
   https://fedoraproject.org/wiki/Features/YumGroupsAsObjects
  
  I don't have an immediate better suggestion, but with my Fedora
  end user hat on  Yum groups as objects is essentially
  meaningless as a feature title to me. It might as well have said
  Yum groups as aardvarks.
  
  I think it needs a title that reflects what it means to the user,
  rather than reflecting the internal implementation detail.
 
  I agree, and am open to suggestions on a better feature name. But I'd
 thought most users would be happy if the summary / description /
 release-notes were something they'd understand.
 

BetterGroupsSupportForYum ?

(note that I don't expect people to find these changes to be for the
worse)

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

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 11:27, Michael Schwendt mschwe...@gmail.com wrote:
 On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 freeimage -- Multi-format image decoder library

 This one is a mystery:

 2009-05-21 (!) https://bugzilla.redhat.com/501993
 RFE: update to 3.12.0

 No reply at all. :(

Yes I am responsible here.

@co-maintainers

Any one interested in taking ownership ?

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

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 12:02, Tomas Radej wrote:
 Hi,

 On Tue, 29 Jan 2013 03:37:43 +0200
 Rakesh Pandit rakesh.pan...@gmail.com wrote:

 taskcoach -- Your friendly task manager
 xsel -- Command line clipboard and X selection tool

 I'll take these two.


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

Re: Proposed F19 Feature: Shared System Certificates

2013-01-29 Thread Petr Pisar

On 2013-01-28, Florian Weimer fwei...@redhat.com wrote:
 On 01/28/2013 03:45 PM, Petr Pisar wrote:
 On 2013-01-25, Florian Weimer fwei...@redhat.com wrote:
 On 01/24/2013 12:30 PM, Stef Walter wrote:

 So yes, as noted in the 'Detailed Description' of the feature, long term
 we hope to follow this up with further work to make all the crypto
 libraries be able to process the information in its entirety.

 Okay.  In the long term, it might make sense to offload the entire
 certificate chain validation to a daemon.

 Something like dirmngr?

 Good point, dirmngr comes pretty close.  But if I recall correctly, 
 dirmngr is mainly used to retrieve user certificates over LDAP, for use 
 with S/MIME.

dirmngr's purpose is to answer question `Has this certificate been
revoked?'. It traverses whole authority chain, it support OCSP and CRL
over HTTP and LDAP with proper caching. (It does not support partial
CRLs, but that's a detail.) There is dirmngr-client tool to submit the
question. I'm not sure if it verifies the certificate itself.

The only problem is the upstream (Werner Koch  Co.) is a little bit
unresponsive.

-- Petr

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

Re: releasing ownership (maintainers/co-maintainers required)

Hello,

On Tue, Jan 29, 2013 at 2:37 AM, Rakesh Pandit rakesh.pan...@gmail.com wrote:

I'll take these if not accounted for already:

 djvulibre -- DjVu viewers, encoders, and utilities
 jed -- Fast, compact editor based on the S-Lang screen library
 libogg -- The Ogg bitstream file format library
 libosip2 -- oSIP is an implementation of SIP
 linphone -- Phone anywhere in the whole world by using the Internet
 ntop -- A network traffic probe similar to the UNIX top command
 octave -- A high-level language for numerical computations
 opencv -- Collection of algorithms for computer vision
 pdf2djvu -- PDF to DjVu converter

Cheers,
François
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Olav Vitters

On Tue, Jan 29, 2013 at 04:36:22AM -0800, Dan Mashal wrote:
 On Tuesday, January 29, 2013, Olav Vitters wrote:
 
  MATE developers actually have GNOME git accounts now.
 
 I know that.
 
 GNOME classic is not the same as a fallback mode.
 
 
 I am skeptical.

That is not what I meant. Fallback was due to the lack of hardware
accelleration. It could be changed into something with a panel. Classic
provides a few small changes to change the workflow to more match what
GNOME 2 did.

  MATE did not have that much development, nor that many developers if you
  compare it to the amount of work done between a GNOME 2.x release.
 
  Paid full time employees vs non paid hobbyists.

For one: I'd like to see your comparison. There are loads of people
contributing to GNOME. It is translated to 40-50 languages, almost all
of that work is done by volunteers.

Secondly: You suggested that MATE received a lot of work. Now it seems
you agree with my assertion that GNOME did way more work.

  Could you reference the bugs that GNOME 3 has problems with systemd?
  Because it works fine for me.
 
 You know how search RHBZ?

You're being vague.

You said that MATE has better support than GNOME 3. Please stay on topic
and provide references. Note that my intention is to get such issues
fixed upstream. You said you don't feel heard by GNOME, but I am
specifically asking what troubles you see with GNOME 3 and systemd.

   This isn't one persons decision and its not 2003.
  
   Get with the times. Your projects failed. Sure a lot of people like it.
   Then again a lot of people don't. And we wonder why there are less people
   using Fedora.
 
  You say projects: which projects exactly?

I noticed you did not respond to this.

  serious drugs
 
  Quit with attacking people, then maybe people will actually listen. At
  the moment you are very vague and unspecific (e.g. bug references, not
  vague claims). The only think you make clear is that you're angry.
 
 
 Nobody has been listening for the last 3 years.

I've seen the changes that various GNOME developers as well as Red Hat
employees have made. I've seen GNOME developers trying to understand
issues and make changes. I've even tried to summarize this in various
release notes.

Now I'm not sure who you mean with nobody. I assume Red Hat employees
working on GNOME. In which case that's factually wrong.

More importantly: Not feeling heard is no excuse for attacking people.

-- 
Regards,
Olav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

On Tue, Jan 29, 2013 at 1:48 PM, Rakesh Pandit rakesh.pan...@gmail.com wrote:
 On 29 January 2013 11:27, Michael Schwendt mschwe...@gmail.com wrote:
 On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 freeimage -- Multi-format image decoder library

 This one is a mystery:

 2009-05-21 (!) https://bugzilla.redhat.com/501993
 RFE: update to 3.12.0

 No reply at all. :(

 Yes I am responsible here.

 @co-maintainers

 Any one interested in taking ownership ?

I'll take it as well if no one else is interested.

François
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 14:52, François Cami  wrote:
 Hello,

 On Tue, Jan 29, 2013 at 2:37 AM, Rakesh Pandit wrote:

 I'll take these if not accounted for already:

 djvulibre -- DjVu viewers, encoders, and utilities
 jed -- Fast, compact editor based on the S-Lang screen library
 libogg -- The Ogg bitstream file format library
 libosip2 -- oSIP is an implementation of SIP
 linphone -- Phone anywhere in the whole world by using the Internet
 ntop -- A network traffic probe similar to the UNIX top command
 octave -- A high-level language for numerical computations
 opencv -- Collection of algorithms for computer vision
 pdf2djvu -- PDF to DjVu converter


You can take all. Released ownership.

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

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 14:55, François Cami wrote:
 On Tue, Jan 29, 2013 at 1:48 PM, Rakesh Pandit  wrote:
 On 29 January 2013 11:27, Michael Schwendt  wrote:
 On Tue, 29 Jan 2013 03:37:43 +0200, Rakesh Pandit wrote:

 freeimage -- Multi-format image decoder library

 This one is a mystery:

 2009-05-21 (!) https://bugzilla.redhat.com/501993
 RFE: update to 3.12.0

 No reply at all. :(

 Yes I am responsible here.

 @co-maintainers

 Any one interested in taking ownership ?

 I'll take it as well if no one else is interested.


Released ownership.

Thank you.

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

File Module-Build-WithXSpp-0.13.tar.gz uploaded to lookaside cache by churchyard

2013-01-29 Thread Miro Hrončok

A file has been added to the lookaside cache for perl-Module-Build-WithXSpp:

8e4f4ab5782d2916f182129d48172e10  Module-Build-WithXSpp-0.13.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Mathieu Bridon


On 01/29/2013 08:25 PM, Dan Mashal wrote:

I'm sure QA, releng, docs, etc will go with what the community decides.


Why would they?

They are community too, they don't have to follow on what other 
decide, they are free to go on working on the QA and docs of GNOME if 
they prefer, just like you were free to package MATE instead of GNOME.



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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tue, Jan 29, 2013 at 5:07 AM, Mathieu Bridon
boche...@fedoraproject.org wrote:
 On 01/29/2013 08:25 PM, Dan Mashal wrote:

 I'm sure QA, releng, docs, etc will go with what the community decides.


 Why would they?

 They are community too, they don't have to follow on what other decide,
 they are free to go on working on the QA and docs of GNOME if they prefer,
 just like you were free to package MATE instead of GNOME.


 --
 Mathieu

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

Well, I guess it just goes back to the subtle point I was making
earlier of exactly how much of a community based distro Fedora
REALLY is. I guess it's a little less subtle now.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Jiri Eischmann

Dan Mashal píše v Út 29. 01. 2013 v 04:25 -0800:
 I'll tell you what, last time I checked #1 spin is KDE.

1. because the Desktop spin is not included in the counter.
2. I doubt those numbers are accurate. Only 54 downloads of Xfce spin
for this release? I hope you understand it's completely out of the
reality since there have been over 200,000 direct downloads of F18. I
think those numbers have been in question several times. Someone even
suggested we'd remove them.

Polls are not a good way to find out what the majority wants. Because
the subset of users that usually participate in such polls don't
represent the whole user base. It's just not a statistically
representative sample.

BTW I've got slightly different stats:
http://eischmann.wordpress.com/2012/08/09/what-desktop-environments-are-czech-fedora-users-using/
It may not be a 100% accurate, but it's based on a survey with over 4000
submitted results, so it has some relevance.

And please stop all that talk about excluding RHT employees from any
decisions. I think we're all equal and one big community. I spend a lot
of my free time working for Fedora and this really offends me.

Jiri



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

Re: RAWHIDE USERS: BEWARE RPM 4.11.0-0.beta1.2.fc19!

2013-01-29 Thread Dennis Gilmore

On Tue, 29 Jan 2013 13:09:49 +0200
Panu Matilainen pmati...@laiskiainen.org wrote:

 
 Apologies for shouting but we have a genuine, rare, rpmdb-eating bug 
 (shade of dark paperbag) at hand:
 
 DO NOT UPGRADE TO rpm-4.11.0-0.beta1.2.fc19!
 
 The buggy version is expected to appear in todays rawhide-push. I've 
 built a new version where the broken %ghost-related patch is reverted 
 but there's a day-long danger-zone before the new build will be
 pushed.

I killed the rawhide push today so that this wont land.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Thomas Bendler

2013/1/29 Olav Vitters o...@vitters.nl

 [...]
 I've seen the changes that various GNOME developers as well as Red Hat
 employees have made. I've seen GNOME developers trying to understand
 issues and make changes. I've even tried to summarize this in various
 release notes.
 Now I'm not sure who you mean with nobody. I assume Red Hat employees
 working on GNOME. In which case that's factually wrong.
 [...]


The UI will always be an emotional and subjective thing. Personally I
think that Gnome 3 is a good development but could still do things better
(i.e. take a look at  Unity and think about there ideas to save space on
the desktop like global menu and stuff like this which would be helpfull
for guys like me using 14 laptop displays). But I don't think you can do
much against posts like I would like to have my old Gnome 2 desktop back.
They will always have the impression not to be heard anymore, that's the
nature of radically change the UI design.

Regards, Thomas
-- 
Linux ... enjoy the ride!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)

2013-01-29 Thread Christophe Fergeau

On Thu, Jan 24, 2013 at 12:25:19PM +0100, Simone Caronni wrote:
   For this use case, all they need to do is to grab the spice-guest-tools
installer and run that, the mess you describe is the exact reason why
  I'm
building this installer.
   
  
   The installer works good and is a very nice addition, but the QXL drivers
   do not work, as it's not signed.
 
  I'm not sure how to test whether it's signed or not, but I just tested that
  the driver works in a winxp 32 bit install.
 
 
 That's exactly the problem, XP allows unsigned drivers; windows 7 doesn't.

Win7 32 bit does allow unsigned (by MS/WHQL) drivers, Win7 64 bit does not.
I've tested the latest qxl driver on a Win7 32 bit installation and it
installed properly, so I don't know what problem you are trying to point
at, I don't see any different behaviour between the qxl driver and the
virtio ones.

 Anyway the problem leads back to the QXL drivers; if the latest QXL drivers
 were signed and parked at spice-space.org it would not be a big deal even
 if not included in the iso; but unfortunately they are not.

Please be more specific about the signature issue you keep mentioning, I
haven't been able to reproduce any different behaviour between the qxl
driver and the virtio drivers from alt.fedoraproject.org.

Christophe


pgp5ggitN1gGz.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RAWHIDE USERS: BEWARE RPM 4.11.0-0.beta1.2.fc19!

2013-01-29 Thread Panu Matilainen


On 01/29/2013 03:14 PM, Dennis Gilmore wrote:

On Tue, 29 Jan 2013 13:09:49 +0200
Panu Matilainen pmati...@laiskiainen.org wrote:



Apologies for shouting but we have a genuine, rare, rpmdb-eating bug
(shade of dark paperbag) at hand:

DO NOT UPGRADE TO rpm-4.11.0-0.beta1.2.fc19!

The buggy version is expected to appear in todays rawhide-push. I've
built a new version where the broken %ghost-related patch is reverted
but there's a day-long danger-zone before the new build will be
pushed.


I killed the rawhide push today so that this wont land.


Oh, good. I think I'll sleep my night better this way, thanks :)

- Panu -

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Ralf Corsepius


On 01/27/2013 03:53 PM, Jaroslav Reznik wrote:

= Features/Cinnamon as Default Desktop =
https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

Feature owner(s): Eric Smith e...@brouhaha.com

This feature proposes that Fedora switch the default desktop interface from
Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that is more
familiar to Windows and Gnome 2 users than the standard Gnome Shell interface,
while being built from Gnome 3 components.


Though I certainly would welcome Fedora to switch away from Gnome3 as 
default desktop, I do not see much sense in switching to Cinnamon, 
because Cinnamon is too similar to Gnome3.


Instead, I'd propose Fedora to switch away from having *any* default GUI 
and offer Fedora users an equal choice between all different major DE 
Fedora ships (e.g. Gnome3, Cinnamon, MATE, KDE. xfce ...).


Ralf


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

Re: Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

2013-01-29 Thread Miloslav Trmač

Hello,
just a minor point, not getting into the wider should getaddrinfo()
be the primary interface debate...

On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones nick.fa.jo...@gmail.com wrote:
 As a quick summary: I would suggest, in addition to addressing
 the outstanding bugs and issues covered by the Fedora feature,
 a flag be added to the set of getaddrinfo parameters that
 instructs it NOT to do DNS lookups, only perform alternative
 resource lookups supported by nss.  This flag would be something
 like: AI_NODNS

 This will allow application developers to make use of
 getaddrinfo for resolving names using non dns sources (hosts
 file is DNS, so this means ldap and others), then perform
 internet domain lookups using an alternative DNS library that
 is standardised in Fedora.

That's unnecessarily difficult for the application developers.
Application should have a single API to call; if they have to call two
separate APIs, some of them won't.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

2013-01-29 Thread Bruno Wolff III


enet -- Thin, simple and robust network layer on top of UDP


http://bugz.fedoraproject.org/enet
There have been a few upstream releases.
There are three co-maintainers for this already.



@enet co-maintainers

Anyone wants to take it ?


I'll give fcami first crack since he seems to have particular interest 
in it and is working on getting it up to date. But if he doesn't want to, 
I'll take it since a few games need it. It should be safe for you to 
release ownership so one of us can grab it.

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

Re: releasing ownership (maintainers/co-maintainers required)

On Tue, Jan 29, 2013 at 2:48 PM, Bruno Wolff III br...@wolff.to wrote:
 enet -- Thin, simple and robust network layer on top of UDP

 http://bugz.fedoraproject.org/enet
 There have been a few upstream releases.
 There are three co-maintainers for this already.

 @enet co-maintainers

 Anyone wants to take it ?

 I'll give fcami first crack since he seems to have particular interest in it
 and is working on getting it up to date. But if he doesn't want to, I'll
 take it since a few games need it. It should be safe for you to release
 ownership so one of us can grab it.

Yes, I'll take it.

François
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tue, Jan 29, 2013 at 7:09 AM, Dan Mashal dan.mas...@gmail.com wrote:

 On Tue, Jan 29, 2013 at 5:07 AM, Mathieu Bridon
 boche...@fedoraproject.org wrote:
  On 01/29/2013 08:25 PM, Dan Mashal wrote:
 
  I'm sure QA, releng, docs, etc will go with what the community decides.
 
 
  Why would they?
 
  They are community too, they don't have to follow on what other decide,
  they are free to go on working on the QA and docs of GNOME if they
 prefer,
  just like you were free to package MATE instead of GNOME.
 
 
  --
  Mathieu
 
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel

 Well, I guess it just goes back to the subtle point I was making
 earlier of exactly how much of a community based distro Fedora
 REALLY is. I guess it's a little less subtle now.


Almost homeopathically so, I'm afraid.  I'm missing where Fedora isn't a
community distro.  I see the Secret Red Hat Cabal canard a lot, and have
yet to see any evidence of it.  I myself am a great example.  I am not now,
nor have I ever been, a Red Hat employee.  Still, over the last several
year, I have managed to join the community, participate in discussions and
decsions, fix bugs, get packages in, and even serve a term in FESCO.  Then
I was voted out, because other individuals more qualified and popular than
myself got more votes from the community than I did.  ERMAHGERD TEH SHADOWY
REDHAT CONSPIRACY.

Seriously, relax.  Yes, there is Red Hat influence on Fedora.  You know
why?  It's because lots of Red Hat employees contribute, and Fedora evolved
from Red Hat Linux.  They bring great heaps of valuable contributions of
code, time, resources and expertise, both as part of Red Hat and as
individual members of the community.  Their influence is overt and
positive, not covert and malignant.  You may not agree with every choice
they make, but that's life.

I get that you're angry that a DE you don't like is the default and your DE
of choice isn't.  But tossing out unfounded accusations and personal
attacks on the -devel list isn't going to win you hearts and minds.  Making
the spin that uses your chosen DE the most popular and bug-free probably
would, over time.  People tend to use what works well for them, which is
why most of us are here, working on and using Fedora.  It's why Fedora
supports heaps of DEs in the first place.  We've seen it with GNOME, KDE,
XFCE (Open|Libre)Office, X11R6/Xorg, systemd, NetworkManager, distributed
SCM, and the list goes on.  If things really bring great value to users,
they will absolutely catch fire, working their way into prominent places
organically.  Some things never dominate their niche, but still fill a
definite need.  If a default setting is important enough to enough people,
they will vote for (or become) the candidates for the bodies that vote to
change it.  It can take time, lobbying, etc.  If that isn't working for you
personally, you can always fork, and build your own distro with whatever
defaults you like, and even be free from Red Hat influence*.  But I think
we're all better off if we, as a community, can remain civil, work
together, and continue to benefit from each other's work.  There's room for
everyone's contributions, but we have to play nicely together.

Kum ba ya  my lord, kum ba yaaa. . . . .

-J

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



*Except for the kernel, anaconda, NetworkManager, and a host of other
components.  But you can replace those if you like.

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: BuildRequires for texlive stuff for F18 and beyond


On 01/25/2013 09:42 PM, Frank Ch. Eigler wrote:


Hi -

jonathan.underwood wrote:


[...]
With the more fine grained texlive packaging in F18 where tex(latex) is
provided by texlive-collection-latex I am finding that this is insufficient to
build most documents. I see two options in these cases:

1) Add BuildRequires; texlive-collection-latexextra  (nb.
texlive-collection-latexrecommended isn't usually sufficient)

2) Generate a list of specific style files [...]
and turn this into a list of specific BuildRequires: tex(foo.sty) lines.
[...]



What do folks think?


FWIW, we didn't enjoy finding the magic tex(XXX) buildreq's to build
systemtap docs during %build; not sure how confident we can be that
they'll stay valid.  (1) sounds good to me.


- FChE

The magic something(something_else) should still work. At least 
languages like Java, Perl, Ruby are using it. If it's not working, then 
it's a bug.


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Christopher Meng

Funny...I suggest that we can submit a changing desktop feature per release.

Maybe this is the best solution.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re:

2013-01-29 Thread Christopher Meng

which board?ARM?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

On 29 January 2013 15:51, François Cami wrote:
 On Tue, Jan 29, 2013 at 2:48 PM, Bruno Wolff III wrote:
 enet -- Thin, simple and robust network layer on top of UDP

 http://bugz.fedoraproject.org/enet
 There have been a few upstream releases.
 There are three co-maintainers for this already.

 @enet co-maintainers

 Anyone wants to take it ?

 I'll give fcami first crack since he seems to have particular interest in it
 and is working on getting it up to date. But if he doesn't want to, I'll
 take it since a few games need it. It should be safe for you to release
 ownership so one of us can grab it.

 Yes, I'll take it.

[..]

You can take it now.

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

Re: IDLE state:High CPU utilization

2013-01-29 Thread Matthew Miller

On Tue, Jan 29, 2013 at 06:47:21PM +0530, magina antimage wrote:
 I have ported fedora  for my target board,
i am getting high CPU utilisation(30-35%) even when my system is idle
 (no gnome / X session).
 i used top command to see which process is consuming CPU,but couldn't find

How are you measuring CPU utilization? Is it user or system time?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: releasing ownership (maintainers/co-maintainers required)

On Tue, Jan 29, 2013 at 2:58 PM, Rakesh Pandit rakesh.pan...@gmail.com wrote:
 On 29 January 2013 15:51, François Cami wrote:
 On Tue, Jan 29, 2013 at 2:48 PM, Bruno Wolff III wrote:
 enet -- Thin, simple and robust network layer on top of UDP

 http://bugz.fedoraproject.org/enet
 There have been a few upstream releases.
 There are three co-maintainers for this already.

 @enet co-maintainers

 Anyone wants to take it ?

 I'll give fcami first crack since he seems to have particular interest in it
 and is working on getting it up to date. But if he doesn't want to, I'll
 take it since a few games need it. It should be safe for you to release
 ownership so one of us can grab it.

 Yes, I'll take it.

 [..]

 You can take it now.

Taken, thank you Rakesh.

François
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Frank Murphy

On Tue, 29 Jan 2013 21:56:17 +0800
Christopher Meng cicku...@gmail.com wrote:

 Funny...I suggest that we can submit a changing desktop feature per
 release.
 
 Maybe this is the best solution.

No, it's not a Screensaver.

-- 
Regards,
Frank
http//www.frankly3d.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Vít Ondruch


Dne 29.1.2013 14:56, Christopher Meng napsal(a):


Funny...I suggest that we can submit a changing desktop feature per 
release.


Maybe this is the best solution.




It might be nice extension to different wallpaper in every release ;)

Vít

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

Re: Proposed F19 Feature: New firstboot

Hi Adam,

it will use Anaconda screens that already exist (like Time and Date, Root 
password) or are planned for F19 (User creation). So the project itself does 
not require any heavy coding. The 3rd party screens are out of our hands, but 
are not necessary for the system to work.

The current firstboot does very little, it can create user and somehow update 
date and time. But yes, if we fail to accomplish this, the old firstboot is not 
going away, because it already does all the mandatory tasks.

Martin

- Original Message -
 On Mon, 2013-01-28 at 11:46 +, Jaroslav Reznik wrote:
  = Features/NewFirstboot =
  https://fedoraproject.org/wiki/Features/NewFirstboot
  
  Feature owner(s): Martin Sivák msi...@redhat.com
  
  This feature proposes new initial setup application with better
  integration to
  the NewUI anaconda and to Gnome Initial Experience.
  
  == Detailed description ==
  Since the Anaconda installer moved to the NewUI Hub and Spoke
  concept, we can
  reuse much of it's architecture and screens in the after reboot
  configuration
  utility -- initial-setup. So the idea behind the firstboot
  replacement is that
  we will have a new app that will use the same Hub and Spoke model
  and the same
  API as Anaconda.
  
  This will give us the possibility of letting the user configure his
  system
  either during the package extraction or after reboot (important for
  OEMs). It
  will also allow other teams (power management, security team, IPA)
  to prepare
  their own screens for Anaconda and initial-setup and so further
  enhancing the
  user experience.
  
  Anaconda, initial-setup and Gnome Inital Experience will
  communicate to ensure
  the screens are not shown multiple times. So for example the root
  password
  setup or user creation process will be done only in one place,
  depending on
  the installed system.
  
  The old Firstboot will still stay as a fallback in case somebody
  still has his
  old Firstboot plugins he needs to use.
 
 I am concerned about the timeframe on this. The completion percentage
 seems rather optimistic:
 
 Percentage of completion: 70% (the engine is working, package
 undergoing review, no configuration screens present)
 
 To me, 'initial framework coding is complete but we haven't written
 any
 of the code that actually does stuff yet' is a long way short of 70%.
 Especially since this is just re-using anaconda's hub/spoke setup, as
 I
 read it, so presumably implementing the 'engine' was the *easy* bit
 of
 the work.
 
 Does FESCo agree that 70% is a realistic completion percentage for
 the
 current state? Has a reliable evaluation of the likely amount of work
 involved here, and the necessary time, been completed?
 
 At the least I'd suggest we take care to make sure the old firstboot
 works in the F19 context as part of testing, and Martin prioritizes
 fixes for it if we find any, so the contingency plan is viable if
 work
 on the new one is not sufficiently complete by Beta.
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: New firstboot

Hi,

no, system-config-* is not going to be used anywhere.

Martin

- Original Message -
 Jaroslav Reznik jrez...@redhat.com wrote:
  = Features/NewFirstboot =
  https://fedoraproject.org/wiki/Features/NewFirstboot
 
  Feature owner(s): Martin Sivák msi...@redhat.com
 ...
 
 Firstboot currently depends on system-config-users,
 system-config-authentication and system-config-date, causing them to
 be included in a new Fedora installation. Those of us in the GNOME
 community have been working to eliminate the need for these utilities
 for some time. Will your proposal enable firstboot to lose its
 dependencies on them?
 
 Allan
 --
 IRC:  aday on irc.gnome.org
 Blog: http://afaikblog.wordpress.com/
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: New firstboot

Hi,

the tool will be started using systemd unit file which can be disabled. It will 
have to be explicit (even minimal install needs users or root password), but we 
can figure something out.

Martin

- Original Message -
 
  From: Jaroslav Reznik jrez...@redhat.com
  
  = Features/NewFirstboot =
  https://fedoraproject.org/wiki/Features/NewFirstboot
 
 Please consider in the development of this to provide a simple means
 to bypass this as easily as is currently possible with firstboot.
 Our use case rarely involves making a custom kickstart (where we
 could exclude this), but we do use the standard install image either
 in Mimimal mode or with a user's preferred DE and then we have
 puppet (or ansible or the like) do the rest, including
 authentication set up, etc. I only mention this because in a Fedora
 of long ago, firstboot insisted on creating a local user and it was
 obnoxious to have to boot into single user mode first just so that
 firstboot could be removed, puppet installed and the rest of the set
 up be automated as desired.
 
 Firstboot is great for those who need it, but please remember that
 not all need it.
 
 --
 John Florian
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Jóhann B. Guðmundsson


On 01/29/2013 01:38 PM, Ralf Corsepius wrote:

On 01/27/2013 03:53 PM, Jaroslav Reznik wrote:

= Features/Cinnamon as Default Desktop =
https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

Feature owner(s): Eric Smith e...@brouhaha.com

This feature proposes that Fedora switch the default desktop 
interface from

Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that is more
familiar to Windows and Gnome 2 users than the standard Gnome Shell 
interface,

while being built from Gnome 3 components.


Though I certainly would welcome Fedora to switch away from Gnome3 as 
default desktop, I do not see much sense in switching to Cinnamon, 
because Cinnamon is too similar to Gnome3.


Instead, I'd propose Fedora to switch away from having *any* default 
GUI and offer Fedora users an equal choice between all different major 
DE Fedora ships (e.g. Gnome3, Cinnamon, MATE, KDE. xfce ...)


That's the only right and correct way forward and then this default 
*DE dispute can finally be put to rest...


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Michał Piotrowski

2013/1/29 Vít Ondruch vondr...@redhat.com:
 Dne 29.1.2013 14:56, Christopher Meng napsal(a):


 Funny...I suggest that we can submit a changing desktop feature per
 release.

 Maybe this is the best solution.



 It might be nice extension to different wallpaper in every release ;)

How about installing random desktop? This feature can be called
surprise desktop ;)


 Vít


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



-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tue, Jan 29, 2013 at 8:18 AM, Michał Piotrowski mkkp...@gmail.comwrote:

 2013/1/29 Vít Ondruch vondr...@redhat.com:
  Dne 29.1.2013 14:56, Christopher Meng napsal(a):
 
 
  Funny...I suggest that we can submit a changing desktop feature per
  release.
 
  Maybe this is the best solution.
 
 
 
  It might be nice extension to different wallpaper in every release ;)

 How about installing random desktop? This feature can be called
 surprise desktop ;)

 Or write a service to change it daily.  We could have TWM Tuesdays. . .

-J

 
  Vít
 
 
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel



 --
 Best regards,
 Michal

 http://eventhorizon.pl/
 https://getactive.pl/
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: Proposed F19 Feature: New firstboot

Hi,

yes, all the screens are shared with the Anaconda installer and the internal 
data structure is closely tied to kickstart. This allows us to configure almost 
everything using kickstart and then dump the final kickstart for the admin to 
see (as we always did).

Headless is a bit harder, someone has to setup the users and root password. The 
init script supports it properly on s390, but not on the other platforms yet.

How do you think we should detect headless mode? If the system was installed 
using serial console, systemd will ensure that the text interface is accessible 
there (the default terminal device) I hope.

Martin 

- Original Message -
 On Mon, Jan 28, 2013 at 11:46:40AM +, Jaroslav Reznik wrote:
  Anaconda, initial-setup and Gnome Inital Experience will
  communicate to ensure
  the screens are not shown multiple times. So for example the root
  password
  setup or user creation process will be done only in one place,
  depending on
  the installed system.
 
 Will it be possible to do all of the things within kickstart?
 
 Will there be a text-mode interface?
 
 Will the firstboot system be able to detect headless boots and do
 something
 sensible, or will such systems be stuck waiting for someone to attach
 and
 poke buttons?
 
 
 --
 Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁
  mat...@fedoraproject.org
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread drago01

On Tue, Jan 29, 2013 at 3:18 PM, Michał Piotrowski mkkp...@gmail.com wrote:
 2013/1/29 Vít Ondruch vondr...@redhat.com:
 Dne 29.1.2013 14:56, Christopher Meng napsal(a):


 Funny...I suggest that we can submit a changing desktop feature per
 release.

 Maybe this is the best solution.



 It might be nice extension to different wallpaper in every release ;)

 How about installing random desktop? This feature can be called
 surprise desktop ;)

How about not feeding trolls? This feature can be called troll starvation ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: New firstboot

Hi,

this has nothing to do with Gnome. Initial-setup will prepare system-wide 
settings regardless on the WM as firstboot did.

The only difference here (which is not implemented yet) is to skip the user 
creation screens in case GDM is the login manager and Gnome asks for it. In 
that case GIE part of GDM will setup the users instead of firstboot.

Rest of the screens will be shown as usual.

Martin

- Original Message -
 On 01/28/2013 11:46 AM, Jaroslav Reznik wrote:
  = Features/NewFirstboot =
  https://fedoraproject.org/wiki/Features/NewFirstboot
 
  Feature owner(s): Martin Sivák msi...@redhat.com
 
  This feature proposes new initial setup application with better
  integration to
  the NewUI anaconda and to Gnome Initial Experience.
 
 
 Will this work with other *DE's then Gnome?
 
 JBG
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Pierre-Yves Chibon

On Tue, Jan 29, 2013 at 05:17:20AM -0800, Dan Mashal wrote:
On Tue, Jan 29, 2013 at 5:12 AM, Jiri Eischmann eischm...@redhat.com wrote:
Dan Mashal píše v Út 29. 01. 2013 v 04:25 -0800:
I'll tell you what, last time I checked #1 spin is KDE.

1. because the Desktop spin is not included in the counter.
2. I doubt those numbers are accurate. Only 54 downloads of Xfce spin
for this release? I hope you understand it's completely out of the
reality since there have been over 200,000 direct downloads of F18. I
think those numbers have been in question several times. Someone even
suggested we'd remove them.

Polls are not a good way to find out what the majority wants. Because
the subset of users that usually participate in such polls don't
represent the whole user base. It's just not a statistically
representative sample.

BTW I've got slightly different stats:
http://eischmann.wordpress.com/2012/08/09/what-desktop-environments-are-czech-fedora-users-using/
It may not be a 100% accurate, but it's based on a survey with over 4000
submitted results, so it has some relevance.

And please stop all that talk about excluding RHT employees from any
decisions. I think we're all equal and one big community. I spend a lot
of my free time working for Fedora and this really offends me.

Jiri

You think you're the only one that's been offended?

BTW your graphs do not include Sugar, MATE, Cinnamon, and others.

Just for the record, below the first graph is written:
GNOME 2 also includes GNOME 3 Fallback, MATE.

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

Re: Proposed F19 Feature: New firstboot

2013-01-29 Thread Alec Leamas


Answer below :)

On 2013-01-29 15:20, Martin Sivak wrote:

Hi,

yes, all the screens are shared with the Anaconda installer and the internal 
data structure is closely tied to kickstart. This allows us to configure almost 
everything using kickstart and then dump the final kickstart for the admin to 
see (as we always did).

Headless is a bit harder, someone has to setup the users and root password. The 
init script supports it properly on s390, but not on the other platforms yet.

How do you think we should detect headless mode? If the system was installed 
using serial console, systemd will ensure that the text interface is accessible 
there (the default terminal device) I hope.

Martin

- Original Message -

On Mon, Jan 28, 2013 at 11:46:40AM +, Jaroslav Reznik wrote:

Anaconda, initial-setup and Gnome Inital Experience will
communicate to ensure
the screens are not shown multiple times. So for example the root
password
setup or user creation process will be done only in one place,
depending on
the installed system.

Will it be possible to do all of the things within kickstart?

Will there be a text-mode interface?

[cut]

Please don't top-post [1]

[1] 
http://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message

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

Re: Proposed F19 Feature: NFStest

2013-01-29 Thread Steve Dickson

Hello,

On 24/01/13 12:33, Paul Wouters wrote:
 For libreswan we use a system that generates various VM images using a
 network install and libvirt, and then fires off multiple VMs, login in
 over serial, and run various tests and output. Then we compare the
 output with known good output. This includes a tcpdump of the network.
 Additionally, we use 9p filesystem mounts to install updated versions
 and read/write configs/logs, so we can still access binaries and write
 logs even if IPsec has hosed full network connectivity.
Ok... that sounds good... but what does that have to do with testing 
the NFS 4.0 and 4.1 protocol? Granted I know nothing about libreswan
other than I just read in the libreswan-3.0/README, but just don't
see how libreswan fits in...

Note, NFStest is a set of python scripts that explicitly tests the NFS 
v4.0 and v4.1 protocol by sending packets and then analysing the network 
traffic to make sure the correct protocol is being followed. 

So, again, I just don't see how an IPsec implementation would help 
with that. 

steved.
 
 
 There is nothing really specific to libreswan for this, and it could be
 used generally for other systems that need to perform network based
 tests.
 
 It might be worth it to look at what we have already built and see if we
 can stick to one version of a testing harness for multiple packages?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: Anaconda Realm Integration

= Features/AnacondaRealmIntegration =
https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration

Feature owner(s): Vratislav Podzimek vpodz...@redhat.com, Stef Walter 
st...@redhat.com

Kickstart will have a 'realm join example.com' command, to join the machine 
during install to an AD or FreeIPA domain. This will take place using one time 
passwords or password-less joins to an AD or FreeIPA domain. 

== Detailed description ==
realmd is an on demand system DBus service, which allows callers to configure 
network authentication and domain membership in a standard way. realmd 
discovers information about the domain or realm automatically and does not 
require complicated configuration in order to join a domain or realm.

By integrating realmd with Kickstart and Anaconda, administrators will be able 
to add machines to a domain en-masse. This can be done without leaking 
administrative domain credentials into the kickstart fail.

In addition there will be a GUI for joining a domain during the anaconda 
install process.

This will be implemented as an Anaconda addon, to help keep the scope and base 
feature set of Anaconda in check. 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: AnacondaNewUI Followup

= Features/AnacondaNewUI Followup =
https://fedoraproject.org/wiki/Features/AnacondaNewUI_Followup

Feature owner(s): Chris Lumens clum...@redhat.com

The purpose of this feature is to describe the high level work items we have 
for anaconda related to newui in F-19.

== Detailed description ==
* Add in advanced storage capabilities in to the UI (device filtering, 
multipath/iscsi/zfcp/fcoe configuration, etc).
* Make system-config-kickstart work again. The removal of 
iw/GroupSelector.py from anaconda caused it to break. (#859928)
* Move to a some tool that prevents or avoids the GTK+ redraw ugliness 
(e.g., mutter). (#858684)
* Review UX design suggestions from different users and groups and 
incorporate adjustments that make sense and work well with the overall design.
* Improve anaconda's threading. Right now it is difficult to tell what 
thread a method is executing in and whether or not you can do GTK calls 
directly. We need either a policy or a technical solution to this.
* Allow selecting multiple disks. (#864707)
* Allow a faster way of deleting everything on a disk. (#880686)
* Add repo needs to work.
* Updates checkbox needs to work. Needs backend code and then made visible 
in the UI.
* Add new firstboot-type questions to the second hub (dependent on the 
firstboot work, which is another feature).
* Expand text mode to offer more or the same installation options as the 
graphical mode. We don't anticipate the text mode being capable of 100% 
similarity to the graphical mode, but we want it to be closer than where it is 
now. As it stands, it is comparable to the former reduced text mode in F-17 
and earlier.
* Use the blivet storage module in anaconda once that code is broken out 
in to a separate project (blivet is the name of the anaconda storage library 
becoming a standalone Python module).
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: Better NetworkManager IPSec Integration

= Features/BetterNetworkManagerIPSecIntegration =
https://fedoraproject.org/wiki/Features/BetterNetworkManagerIPSecIntegration

Feature owner(s): Dan Williams dcbw at redhat dot com

IPSec usage is becoming more popular and the existing NetworkManager IPSec VPN 
plugin will be enhanced to better support these use-cases and fix known bugs.

== Detailed description ==
The existing VPN plugin uses the openswan IPSec package to provide IPSec 
functionality for NetworkManager users. Communication with openswan could be 
much more robust and secure by communicating directly with openswan's tools 
rather than writing secrets and other configuration out to temporary files like 
openswan current requires. Furthermore, NetworkManager should be enhanced to 
allow for route-based tunnel connections instead of requiring a TUN/TAP 
interface for each VPN connection.
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: CUPS 1.6

= Features/CUPS1.6 =
https://fedoraproject.org/wiki/Features/CUPS1.6

Feature owner(s):  Tim Waugh twa...@redhat.com, Jiri Popelka 
jpope...@redhat.com 

Update CUPS to the latest upstream release and use PDF rather than PostScript 
as baseline document format.

== Detailed description ==
CUPS 1.6 was released in July 2012 and has brought several important changes
* Merged Fedora's patch for color management using colord
* Merged Fedora's patch for mDNS/DNS-SD support using Avahi
* Removed support for CUPS Browsing and Polling
* The CUPS Browsing protocol is currently the primary mechanism for CUPS-
to-CUPS printer queue discovery on Linux. It works by having each CUPS server 
periodically broadcast UDP packets on port 631 announcing its available 
queues, and listening for broadcasts from other CUPS servers. CUPS Browsing 
protocol has no longer been meeting the requirements of current networking 
technologies, and in fact has had some bad effects on wireless networks due to 
the use of UDP broadcasts. Rather than trying to address these issues by 
introducing a new and incompatible update to the protocol, the existing 
mDNS/DNS-SD standards can serve as a ready replacement and actually has been 
used in CUPS for many years now. 
* All filters and backends not used by Mac OS X have been dropped
* These filters and backends, together with the filters for the PDF 
printing 
workflow are now hosted as the cups-filters project at linuxfoundation.org. 

PDF printing workflow
* Currently CUPS uses PostScript as the common format for manipulating print 
jobs. We want to switch the standard print job transfer format from PostScript 
to PDF, which has many important advantages.
* Additional filters for the PDF printing workflow have been added to the cups-
filters project. 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-29 Thread Aleksandar Kurtakov

- Original Message -
 From: Dan Mashal dan.mas...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, January 29, 2013 2:13:34 PM
 Subject: Re: Proposed F19 Feature: Cinnamon as Default Desktop

 On Monday, January 28, 2013, Matthias Clasen wrote:

 - Original Message -
  = Features/Cinnamon as Default Desktop =

  I submit the proposition that it is easier for a user doing a new
  Fedora
  install to start with a traditional desktop, and switch to the
  Gnome
  Shell if
  they prefer that, than to start with Gnome Shell and switch to a
  traditional
  desktop.

  The Cinnamon desktop provides a traditional desktop while being
  based
  on the
  latest Gnome and GTK components, so it seems like a better
  candidate
  for a
  default desktop than MATE, which is based on older components.

 Some facts:

 - Cinnamon started out as 'using GNOME components', but it is not a
 full fork of mutter, gnome-shell and nautilus, at least, and
 bug-fixes are not going either way...

 - GNOME 3.8 will replace the dismal fallback mode with a new
 'classic' mode that is actually based on the latest GNOME
 components, and will be a more 'traditional desktop', whatever that
 means.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

 Let's see how lightweight, bug free and usable it is. Why don't you
 just merge the 3 projects instead of wasting your time? We could all
 work together.

 There could be different flavors of Gnome. Now I know that we are
 both biased here, however what it really feels like here is REDHAT
 employees want Gnome 3 and they are giving a bunch of bullshit
 excuses on why it should be, referencing various stupid apple to
 orange comparisons from 10 years ago. Why don't we take a poll where
 no Red Hat employees can vote. 

Since when my work(hence vote) in Fedora is unwanted because I'm Red Hat 
employee?
I don't give a sh*t about what the default is but one should tell you - SHUT 
UP!!! And yes this is exactly what you were trying to tell me.
So please send your next message once you learned to deal with technical 
questions in a technical way or if you can't never would be better!!!

Alexander Kurtakov
Red Hat Eclipse team

 Only non Red Hat Fedora employees and
 the board itself can make a final decision after considering what
 FESCO has to say about it. Face it. Fedora 15 Gnome 3 cause a major
 uproar. Anaconda on RHEL6 is easier to use than Anaconda 18. Almost
 3 years later and oh yeah we realized we should probably add a real
 fallback mode to Gnome 3. Meanwhile the main people writing code
 are not the community. Meanwhile MATE is lighter weight than Gnome
 2.3, has numerous bug fixes, will have full support for
 systems/logind.. Something even Gnome 3 still has trouble with.

 Is it really that scary for you guys to think about something else
 besides Gnome 3 and KDE?

 Not enough support? Then step up and quit whining. You know how to
 help, Red Hat employees. Don't be selfish. This is Fedora not RHEL.
 This is a community based distribution not Red Hats playground.
 Please feel free to correct me if I'm wrong.

 Everyone loves to dance around the fact about what Fedora is or
 isn't.

 This isn't one persons decision and its not 2003.

 Get with the times. Your projects failed. Sure a lot of people like
 it. Then again a lot of people don't. And we wonder why there are
 less people using Fedora.

 And then we wonder why MATE and Cinnamon got the most press coverage
 in Fedora 18 and why there has been a huge user spike in the last 30
 days. It hasn't been because of systemd, Gnome 3.6, and Anaconda 18.
 You are on serious drugs if you believe that.

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

Re: IDLE state:High CPU utilization

2013-01-29 Thread Chris Tyler

On Tue, 2013-01-29 at 18:47 +0530, magina antimage wrote:
 Hi,
 I have ported fedora  for my target board,
i am getting high CPU utilisation(30-35%) even when my system is
 idle (no gnome / X session).
 i used top command to see which process is consuming CPU,but couldn't
 find any.
 any help.

Hi Magina,

You're on the right track. Three questions:

(1) How do you know you have 30-35% CPU utilization when idle? I.e.,
which tool is reporting this?

(2) What does top show? Can you paste the first 10 lines of top output?

(3) Is your system multi-core?

-Chris

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Tue, Jan 29, 2013 at 8:47 AM, Aleksandar Kurtakov akurt...@redhat.comwrote:

 - Original Message -
  From: Dan Mashal dan.mas...@gmail.com
  To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
  Sent: Tuesday, January 29, 2013 2:13:34 PM
  Subject: Re: Proposed F19 Feature: Cinnamon as Default Desktop

  On Monday, January 28, 2013, Matthias Clasen wrote:

  - Original Message -
   = Features/Cinnamon as Default Desktop =

   I submit the proposition that it is easier for a user doing a new
   Fedora
   install to start with a traditional desktop, and switch to the
   Gnome
   Shell if
   they prefer that, than to start with Gnome Shell and switch to a
   traditional
   desktop.

   The Cinnamon desktop provides a traditional desktop while being
   based
   on the
   latest Gnome and GTK components, so it seems like a better
   candidate
   for a
   default desktop than MATE, which is based on older components.

  Some facts:

  - Cinnamon started out as 'using GNOME components', but it is not a
  full fork of mutter, gnome-shell and nautilus, at least, and
  bug-fixes are not going either way...

  - GNOME 3.8 will replace the dismal fallback mode with a new
  'classic' mode that is actually based on the latest GNOME
  components, and will be a more 'traditional desktop', whatever that
  means.
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel

  Let's see how lightweight, bug free and usable it is. Why don't you
  just merge the 3 projects instead of wasting your time? We could all
  work together.

  There could be different flavors of Gnome. Now I know that we are
  both biased here, however what it really feels like here is REDHAT
  employees want Gnome 3 and they are giving a bunch of bullshit
  excuses on why it should be, referencing various stupid apple to
  orange comparisons from 10 years ago. Why don't we take a poll where
  no Red Hat employees can vote.

 Since when my work(hence vote) in Fedora is unwanted because I'm Red Hat
 employee?
 I don't give a sh*t about what the default is but one should tell you -
 SHUT UP!!! And yes this is exactly what you were trying to tell me.
 So please send your next message once you learned to deal with technical
 questions in a technical way or if you can't never would be better!!!

That's not helpful.

-J

 Alexander Kurtakov
 Red Hat Eclipse team

  Only non Red Hat Fedora employees and
  the board itself can make a final decision after considering what
  FESCO has to say about it. Face it. Fedora 15 Gnome 3 cause a major
  uproar. Anaconda on RHEL6 is easier to use than Anaconda 18. Almost
  3 years later and oh yeah we realized we should probably add a real
  fallback mode to Gnome 3. Meanwhile the main people writing code
  are not the community. Meanwhile MATE is lighter weight than Gnome
  2.3, has numerous bug fixes, will have full support for
  systems/logind.. Something even Gnome 3 still has trouble with.

  Is it really that scary for you guys to think about something else
  besides Gnome 3 and KDE?

  Not enough support? Then step up and quit whining. You know how to
  help, Red Hat employees. Don't be selfish. This is Fedora not RHEL.
  This is a community based distribution not Red Hats playground.
  Please feel free to correct me if I'm wrong.

  Everyone loves to dance around the fact about what Fedora is or
  isn't.

  This isn't one persons decision and its not 2003.

  Get with the times. Your projects failed. Sure a lot of people like
  it. Then again a lot of people don't. And we wonder why there are
  less people using Fedora.

  And then we wonder why MATE and Cinnamon got the most press coverage
  in Fedora 18 and why there has been a huge user spike in the last 30
  days. It hasn't been because of systemd, Gnome 3.6, and Anaconda 18.
  You are on serious drugs if you believe that.

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

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Proposed F19 Feature: Dracut HostOnly