date:20130130

On Fri, Jan 25, 2013 at 03:53:09PM +0100, Petr Pisar wrote:
 On Fri, Jan 25, 2013 at 02:27:40PM +, Fedora Koji Build System wrote:
  Package: perl
  NVR: perl-5.16.2-248.fc19
  User: ppisar
  Status: complete
  Tag Operation: untagged
  From Tag: f19
  
  perl-5.16.2-248.fc19 successfully untagged from f19 by ppisar
  
 I've untagged this build from F19, because it does not build manual pages
 from POD after sub-packaging Pod-LaTeX probably
 http://koji.fedoraproject.org/koji/taskinfo?taskID=4902055. I have no time
 to resolve it now, thus the untagging. I will investigate more on Monday.

Solved.

I'd like to announce that Pod::LaTeX is has been split from binary perl
package as perl-Pod-LaTeX in rawhide.

-- Petr


pgpU6uJN5a7Gn.pgp
Description: PGP signature
--
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: Developers Assistant

2013-01-30 Thread Jan Zelený

On 30. 1. 2013 at 08:50:23, Dan Horák wrote:
 Jan Zelený píše v St 30. 01. 2013 v 08:22 +0100:
  On 29. 1. 2013 at 19:18:32, Miloslav Trmač wrote:
   On Tue, Jan 29, 2013 at 9:14 AM, Jan Zelený jzel...@redhat.com wrote:
On 28. 1. 2013 at 14:28:06, Bill Nottingham wrote:
Michael Scherer (m...@zarb.org) said:
 Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit :
  Currently we are working on some proof-of-concept stuff. But as
  an
  example, you can imagine a script for creation of C program
  templates.
  You will specify directory where it should create the program and
  (possibly) some specifics, like I want to use threads or I
  need
  glib
  support.
 
  On output of that script you will have a template of C program
  with
  Makefile and you can start coding right away, no need for
  preparing
  the
  environment first.

 Something like https://wiki.ubuntu.com/Quickly ?

 Some work have been started by Mathieu bridon and Didier Roche for
 quickly on Fedora a few years ago. Not sure where it went, but this
 would be easier to use it rather than start from scratch.
   
Do we know whether our target users for these quick-onroad scripts
are
using the commandline vs something like Eclipse? Just curious where
the
bang-for-the-buck is.
   
Actually we want to address both. Use cases for Eclipse users will be
addressed in second stage of the project, hopefully utilizing whatever
we
produce.
  
   Eclipse already has some of this, see e.g.
   http://wiki.eclipse.org/CDT/Autotools/User_Guide .
 
  I thought so, even though I didn't do much research on this front. Thanks
  for the link, I'll check it out.

 From my knowledge every good IDE has its own kind of developer
 assistant so IMHO it would be hard to come up with an universal
 concept. And not everyone uses Eclipse ...

Yes, I know that but these are usually IDE specific (you have to build/run your
project directly from the IDE). This might serve as a common way of doing
things in IDE and on CLI. It won't be as advanced as those assistants in IDEs
but then again - that's not our goal, just some basic support will do for now.

Those who don't use Eclipse will still have the CLI toolset we are working on
right now. Also we don't prevent anyone to come and build support for other
IDEs :-)

Thanks
Jan

signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Developers Assistant

2013-01-30 Thread Aleksandar Kurtakov

- Original Message -
 From: Jan Zelený jzel...@redhat.com
 To: devel@lists.fedoraproject.org
 Cc: Miloslav Trmač m...@volny.cz
 Sent: Wednesday, January 30, 2013 9:22:07 AM
 Subject: Re: Proposed F19 Feature: Developers Assistant

 On 29. 1. 2013 at 19:18:32, Miloslav Trmač wrote:
  On Tue, Jan 29, 2013 at 9:14 AM, Jan Zelený jzel...@redhat.com
  wrote:
   On 28. 1. 2013 at 14:28:06, Bill Nottingham wrote:
   Michael Scherer (m...@zarb.org) said:
Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit :
 Currently we are working on some proof-of-concept stuff. But
 as an
 example, you can imagine a script for creation of C program
 templates.
 You will specify directory where it should create the
 program and
 (possibly) some specifics, like I want to use threads or
 I need
 glib
 support.

 On output of that script you will have a template of C
 program with
 Makefile and you can start coding right away, no need for
 preparing
 the
 environment first.

Something like https://wiki.ubuntu.com/Quickly ?

Some work have been started by Mathieu bridon and Didier Roche
for
quickly on Fedora a few years ago. Not sure where it went, but
this
would be easier to use it rather than start from scratch.

   Do we know whether our target users for these quick-onroad
   scripts are
   using the commandline vs something like Eclipse? Just curious
   where the
   bang-for-the-buck is.

   Actually we want to address both. Use cases for Eclipse users
   will be
   addressed in second stage of the project, hopefully utilizing
   whatever we
   produce.

  Eclipse already has some of this, see e.g.
  http://wiki.eclipse.org/CDT/Autotools/User_Guide .

 I thought so, even though I didn't do much research on this front.
 Thanks for
 the link, I'll check it out.
Hi, 
Eclipse is one step ahead on this already. FYI 
http://rgrunber.fedorapeople.org/eclipse_packagekit_2.ogv and 
http://rgrunber.fedorapeople.org/eclipse_packagekit_2.ogv . 
Having IDE users as a post-thought never works - either one tool is thought 
with both kind console and ide users from the beginning or it will stay console 
or ide only. Simply wrapping console calls with some UI doesn't work because 
you need to make the tool work in a familiar way for the group you target. 
I would be happy to join such conversations so please either add me to any 
mails flowing on the topic or tell me if there is some mailing list to join.

Alexander Kurtakov
Red Hat Eclipse team

 Jan
 --
 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: kworker is using up a lot of CPU

2013-01-30 Thread Eberhard Schruefer


On Jan 29, 2013, at 20:59 UTC, Chris Murphy wrote:
 


On Jan 29, 2013, at 11:44 AM, Eberhard Schruefer eschruefer at ca-musings.de  
https://admin.fedoraproject.org/mailman/listinfo/devel wrote:



/  I'm seeing kworker using up around 80% CPU time constantly and the laptop 
is running hot.
//  
/ This is in cases when you expect the system to be idle? i.e. no disk access, no active processes running, or network activity? Or is there something going on, like a file copy, but you just don't expect kworker to be consuming 80%? If the latter, I have a similar case with two (U)EFI laptops; I haven't narrowed it down to network access or disk access. But if neither are occurring, then I do get idle and no kworker process CPU % is significant.



Chris Murphy



The system is absolutely idle. As other people reported in between, issuing on 
this Samsung Laptop

echo disable  /sys/firmware/acpi/interrupts/gpe13

the high kworker load disappears. But I find it scary to do this without 
knowing what effect this has on the system.


Eberhard

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

Re: Proposed F19 Feature: New firstboot

2013-01-30 Thread Martin Sivak

Hi,

  When I install a freeipa server I do not want firstboot because I
  am not
  going to create local users anyway. I am going to install freeipa
  and
  then create users in LDAP.
 
 Could such use cases not be built into firstboot?

Right you are, see another proposed feature that works with FreeIPA and AD: 
https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration

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

Re: Proposed F19 Feature: systemd features

2013-01-30 Thread Gerd Hoffmann

On 01/30/13 01:08, Kay Sievers wrote:
 On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham nott...@redhat.com wrote:
 Kay Sievers (k...@vrfy.org) said:
 Realistically, it's new textual files, replacing old textual files, which
 are then compiled into a binary file. I'm not sure why there's the
 intermediate step of a second textual format, but there is.

 Because the original text file is a hack and a format specific to the
 PCI/USB IDs, and makes no sense at all for a generic hwdb.

 pci:v0010*
  ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc

 It's not like that's that much more of a generic format. :)
 
 It is entirely generic. It can carry arbitrary numbers of freely named
 key/value pairs basically unlimited in their size. Is extensible, uses
 flexible and extensible string matches like modaliases for kernel
 modules. Nothing you would find in the PCI/USB IDs hack.
 
 So what do you criticize here?

Still looks pointless.

You convert the old-format into new-format, then compile new-format into
the database.  It's not obvious why you don't go straight from
old-format to the database.  hwdata package updates would directly show
up in the database then, without having to touch systemd.

cheers,
  Gerd

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

Re:

2013-01-30 Thread Bryn M. Reeves

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2013 10:09 PM, G.Wolfe Woodbury wrote:
 This is simply not true.
 
 There are hundreds of thousands of older desktops that are not 
 technically servers that have lots of older interfaces.

Evidence is better than unsupported claims. Although smolt has been
retired for some time now it may be possible to use the data that was
collected to get some numbers as well as a sense of how non-standards
based adapters are declining in the field.

 To say that non-AHCI controllers don't matter is to place a
 dignificant barrier to use or adoption of Linux or Fedora.

Nobody is saying that these controllers don't matter. What we're
talking about is making something /possibly/ require the use of rescue
media where it hasn't since F12 (but always did previously when this
hardware was much more common).

 I suspect that working in a situation where one is not buying or 
 maintaining ones own computer has produced a newrsighted view of
 what the computing ecoshpere has lurking in it.

I buy and maintain my own systems as I guess do most people interested
enough in Linux to be working on it full time.

Certainly for commercial Linux users I think this set is now
vanishingly small (although obviously there is a much broader range of
high-end storage adapters to contend with).

Regards,
Bryn.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEI+f0ACgkQ6YSQoMYUY96cXACgpxs8kAwjd6S4a14AQj86044I
cwsAoKiegAxvFWYpNS6VMjypQqfCy02P
=Yy0L
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

2013-01-30 Thread Kay Sievers

On Wed, Jan 30, 2013 at 11:42 AM, Gerd Hoffmann kra...@redhat.com wrote:
 On 01/30/13 01:08, Kay Sievers wrote:
 On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham nott...@redhat.com wrote:
 Kay Sievers (k...@vrfy.org) said:
 Realistically, it's new textual files, replacing old textual files, which
 are then compiled into a binary file. I'm not sure why there's the
 intermediate step of a second textual format, but there is.

 Because the original text file is a hack and a format specific to the
 PCI/USB IDs, and makes no sense at all for a generic hwdb.

 pci:v0010*
  ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc

 It's not like that's that much more of a generic format. :)

 It is entirely generic. It can carry arbitrary numbers of freely named
 key/value pairs basically unlimited in their size. Is extensible, uses
 flexible and extensible string matches like modaliases for kernel
 modules. Nothing you would find in the PCI/USB IDs hack.

 So what do you criticize here?

 Still looks pointless.

 You convert the old-format into new-format, then compile new-format into
 the database.  It's not obvious why you don't go straight from
 old-format to the database.  hwdata package updates would directly show
 up in the database then, without having to touch systemd.

It's as pointless as shipping a parser for a foreign and irrelevant
format in the hwdb code.

And it is as pointless as adding weird code and ./configure stuff
again to udev to find these files in the place of the month, where
some distro poeple decided again where to put it, and every distro in
a different place, with different names or file types.

And it is as pointless as inventing magic rules in the hwdb to
overwrite the old files with possibly new data shipped in the new
format.

We don't want to pointlessly do any of that. Also, the textual strings
are just one, and not the interesting part of the hwdb, and all should
be uniform and not pull in some not convincing legacy formats, or
weird rules how things are located and overwritten.

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

Re: f18+gnome3: mail-notification problem

2013-01-30 Thread Dario Lesca

Someone have some help for me?
Thanks

Il giorno mar, 29/01/2013 alle 16.10 +0100, Dario Lesca ha scritto:
 When I run mail-notification and add some Evolution folder to
 monitoring, the application crash with this error:
 
  [lesca@dodo ~]$ mail-notification 
  
  (mail-notification:24093): GLib-GObject-CRITICAL **: g_object_ref: 
  assertion `G_IS_OBJECT (object)' failed
  
  (mail-notification:24093): Gtk-CRITICAL **: _gtk_widget_list_devices: 
  assertion `GTK_IS_WIDGET (widget)' failed
  
  (mail-notification:24093): GLib-GObject-WARNING **: instance of invalid 
  non-instantiatable type `invalid'
  
  (mail-notification:24093): GLib-GObject-CRITICAL **: g_signal_emit_valist: 
  assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
  
  (mail-notification:24093): GLib-GObject-CRITICAL **: g_object_unref: 
  assertion `G_IS_OBJECT (object)' failed
  
  (mail-notification:24093): GLib-GObject-CRITICAL **: g_object_ref: 
  assertion `G_IS_OBJECT (object)' failed
  
  (mail-notification:24093): Gtk-CRITICAL **: _gtk_widget_list_devices: 
  assertion `GTK_IS_WIDGET (widget)' failed
  
  (mail-notification:24093): GLib-GObject-CRITICAL **: g_object_unref: 
  assertion `G_IS_OBJECT (object)' failed
  
  (mail-notification:24093): GLib-GObject-CRITICAL **: g_object_ref: 
  assertion `G_IS_OBJECT (object)' failed
  
  (mail-notification:24093): Gtk-CRITICAL **: _gtk_widget_list_devices: 
  assertion `GTK_IS_WIDGET (widget)' failed
  
  (mail-notification:24093): GLib-GObject-CRITICAL **: g_object_unref: 
  assertion `G_IS_OBJECT (object)' failed
 
 And show an error panel with this message:
 
 A fatal error has occurred in Mail Notification
 A GConf error has occurred: Type mismatch: Expected list, got int.
 
 It's possible to fix this error?
 There is another apps for check evolution mail local folder?
  
 Many thanks
 
 -- 
 Dario Lesca - sip:da...@solinos.it
 (Inviato dal mio Linux Fedora18+Gnome3)
 
 

-- 
Dario Lesca - sip:da...@solinos.it
(Inviato dal mio Linux Fedora18+Gnome3)


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

Re: Proposed F19 Feature: CUPS 1.6

2013-01-30 Thread Jiri Popelka


On 01/29/2013 07:10 PM, Benjamin De Kosnik wrote:

1) is there a way to test just the cups-1.6 stuff on F18? Or will
people who want to help with this effort be running rawhide?


Either run rawhide or use builds from
http://jpopelka.fedorapeople.org/cups-1.6/
which is what I run here on F18.


2) will there be a way to parallel install current-1.5 with the beta-1.6
stack?


No


3) in how to test there is no mention of print quality regressions.
I'm concerned that in the effort to sync with cups-1.6 and upstream,
mostly just the mechanics of finding a printer and getting a
page out are being tested.

This is just scratching the surface. How are you going to evaluate
quality? I'm concerned about the rasterization changes, the filter
changes. Hopefully 1.6 may solve some of the image-quality regressions
I've been seeing.


'How to test' needs to be enhanced, yes.


4) In the past, I've found it difficult to debug cups filters step by
step. Especially with so many rasterization/filter changes. As part of
the move to 1.6, will things like:
http://fedoraproject.org/wiki/How_to_debug_printing_problems
be updated?


These instructions are still valid with cups-1.6  cups-filters.


I would love it if issues like what driver am I using
could be re-integrated into the UI, or perhaps an admin level of the
ui. Also, what filters did I run to get to this point of output in a
log file.


What UI do you have in mind ? system-config-printer ?


Will the running cups filters by hand thing be updated?


Maybe later when we have 1.6 in all releases. I don't see a reason at 
the moment. The example there is just an example and what filters are 
run depends on the PPD.



5) integration with common printing dialog. (IMHO localhost:631).
I think integrating Fedora's print dialogs with the wider user
communities on macos and ubuntu would be very useful.


Not sure what you mean with Fedora's. The print dialogs we use on 
Fedora are part of GTK/QT and therefore are used on Ubuntu too.


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

Re: Proposed F19 Feature: New firstboot

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


On 01/30/2013 10:08 AM, Martin Sivak wrote:

Hi,


When I install a freeipa server I do not want firstboot because I
am not
going to create local users anyway. I am going to install freeipa
and
then create users in LDAP.
  

Could such use cases not be built into firstboot?

Right you are, see another proposed feature that works with FreeIPA and AD: 
https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration


In rawhide I see that realmd is constantly running how can I turn it off?

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

Re: Proposed F19 Feature: systemd features

2013-01-30 Thread Gerd Hoffmann

On 01/30/13 11:55, Kay Sievers wrote:
  Hi,

 Still looks pointless.

 You convert the old-format into new-format, then compile new-format into
 the database.  It's not obvious why you don't go straight from
 old-format to the database.  hwdata package updates would directly show
 up in the database then, without having to touch systemd.
 
 It's as pointless as shipping a parser for a foreign and irrelevant
 format in the hwdb code.

You need the parser anyway, for converting the old format into the new,
don't you?

 And it is as pointless as adding weird code and ./configure stuff
 again to udev to find these files in the place of the month, where
 some distro poeple decided again where to put it, and every distro in
 a different place, with different names or file types.

That is a bit nasty indeed.

 And it is as pointless as inventing magic rules in the hwdb to
 overwrite the old files with possibly new data shipped in the new
 format.

You could use import $format $file syntax in the new format, then
plumb a file with a single import line instead of the converted file
into the directory.  You get the same ordering then.

cheers,
  Gerd

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

Re: Proposed F19 Feature: Developers Assistant

- Original Message -
 Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit :
 
  
  Currently we are working on some proof-of-concept stuff. But as an
  example, you
  can imagine a script for creation of C program templates. You will
  specify
  directory where it should create the program and (possibly) some
  specifics,
  like I want to use threads or I need glib support.
  
  On output of that script you will have a template of C program with
  Makefile
  and you can start coding right away, no need for preparing the
  environment
  first.
 
 Something like https://wiki.ubuntu.com/Quickly ?

And I'd say - not only Quickly as a tool but what do we need more is
something like http://developer.ubuntu.com/ (and yes, Quickly is part
of it). Same did Nokia with Harmattan Developer web.

Documentation, how to start (based on the tools we provide), guides,
how to's should be the main part of this effort.

Jaroslav

 Some work have been started by Mathieu bridon and Didier Roche for
 quickly on Fedora a few years ago. Not sure where it went, but this
 would be easier to use it rather than start from scratch.
 
 --
 Michael Scherer
 
 --
 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: Developers Assistant

2013-01-30 Thread Jan Zelený

On 30. 1. 2013 at 06:27:48, Jaroslav Reznik wrote:
 - Original Message -

  Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit :
   Currently we are working on some proof-of-concept stuff. But as an
   example, you
   can imagine a script for creation of C program templates. You will
   specify
   directory where it should create the program and (possibly) some
   specifics,
   like I want to use threads or I need glib support.
  
   On output of that script you will have a template of C program with
   Makefile
   and you can start coding right away, no need for preparing the
   environment
   first.
 
  Something like https://wiki.ubuntu.com/Quickly ?

 And I'd say - not only Quickly as a tool but what do we need more is
 something like http://developer.ubuntu.com/ (and yes, Quickly is part
 of it). Same did Nokia with Harmattan Developer web.

 Documentation, how to start (based on the tools we provide), guides,
 how to's should be the main part of this effort.

I've already started to work on that as well. Currently I'm putting together
topics from Fedora wiki that are eligible to be on such page, either as they
are or with some (rather minor) modifications.

I'd like them to be structured, easy to comprehend and most importantly as
short as possible.

If you know any such topic, feel free to let me know.

Thanks
Jan

signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Developers Assistant

- Original Message -
 On 30. 1. 2013 at 06:27:48, Jaroslav Reznik wrote:
  - Original Message -
  
   Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit :
Currently we are working on some proof-of-concept stuff. But as
an
example, you
can imagine a script for creation of C program templates. You
will
specify
directory where it should create the program and (possibly)
some
specifics,
like I want to use threads or I need glib support.

On output of that script you will have a template of C program
with
Makefile
and you can start coding right away, no need for preparing the
environment
first.
   
   Something like https://wiki.ubuntu.com/Quickly ?
  
  And I'd say - not only Quickly as a tool but what do we need more
  is
  something like http://developer.ubuntu.com/ (and yes, Quickly is
  part
  of it). Same did Nokia with Harmattan Developer web.
  
  Documentation, how to start (based on the tools we provide),
  guides,
  how to's should be the main part of this effort.
 
 I've already started to work on that as well. Currently I'm putting
 together
 topics from Fedora wiki that are eligible to be on such page, either
 as they
 are or with some (rather minor) modifications.
 
 I'd like them to be structured, easy to comprehend and most
 importantly as
 short as possible.

Would you need anything from Design/Web team to support it?

Jaroslav

 
 If you know any such topic, feel free to let me know.
 
 Thanks
 Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

2013-01-30 Thread Kay Sievers

On Wed, Jan 30, 2013 at 12:19 PM, Gerd Hoffmann kra...@redhat.com wrote:
 On 01/30/13 11:55, Kay Sievers wrote:
   Hi,

 Still looks pointless.

 You convert the old-format into new-format, then compile new-format into
 the database.  It's not obvious why you don't go straight from
 old-format to the database.  hwdata package updates would directly show
 up in the database then, without having to touch systemd.

 It's as pointless as shipping a parser for a foreign and irrelevant
 format in the hwdb code.

 You need the parser anyway, for converting the old format into the new,
 don't you?

Right, but only in the build process, or the packaging. It's a dumb
perl script. Doing it in shipped tools on the host has much higher
requirements. :)

 And it is as pointless as adding weird code and ./configure stuff
 again to udev to find these files in the place of the month, where
 some distro poeple decided again where to put it, and every distro in
 a different place, with different names or file types.

 That is a bit nasty indeed.

Yeah, it was a mess. Some even only shipped the .gz versions of it.

 And it is as pointless as inventing magic rules in the hwdb to
 overwrite the old files with possibly new data shipped in the new
 format.

 You could use import $format $file syntax in the new format, then
 plumb a file with a single import line instead of the converted file
 into the directory.  You get the same ordering then.

That could work, yeah. If we wanted to make it a swiss army knife,
which brings-in a whole bunch of other problems, and people's
creativity, which we intentionally wanted to leave out here. :)

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

Re: Proposed F19 Feature: Developers Assistant

2013-01-30 Thread Jan Zelený

On 30. 1. 2013 at 06:54:14, Jaroslav Reznik wrote:
 - Original Message -

  On 30. 1. 2013 at 06:27:48, Jaroslav Reznik wrote:
   - Original Message -
  
Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit :
 Currently we are working on some proof-of-concept stuff. But as
 an
 example, you
 can imagine a script for creation of C program templates. You
 will
 specify
 directory where it should create the program and (possibly)
 some
 specifics,
 like I want to use threads or I need glib support.

 On output of that script you will have a template of C program
 with
 Makefile
 and you can start coding right away, no need for preparing the
 environment
 first.
   
Something like https://wiki.ubuntu.com/Quickly ?
  
   And I'd say - not only Quickly as a tool but what do we need more
   is
   something like http://developer.ubuntu.com/ (and yes, Quickly is
   part
   of it). Same did Nokia with Harmattan Developer web.
  
   Documentation, how to start (based on the tools we provide),
   guides,
   how to's should be the main part of this effort.
 
  I've already started to work on that as well. Currently I'm putting
  together
  topics from Fedora wiki that are eligible to be on such page, either
  as they
  are or with some (rather minor) modifications.
 
  I'd like them to be structured, easy to comprehend and most
  importantly as
  short as possible.

 Would you need anything from Design/Web team to support it?

 Jaroslav

Yes, probably. But it's not that critical at this moment. First we need a
content, then design and other stuff ;-)

Thanks
Jan

signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: New firstboot

2013-01-30 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2013 10:40 AM, Matthew Miller wrote:
 On Tue, Jan 29, 2013 at 09:15:05AM -0500, Martin Sivak wrote:
 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.
 
 That's not necessarily true; please don't force the creation of
 users or setting of a root password.
 

In what situation would you ever have a system that requires neither
users nor root access? Or are you saying that root access would be via
SSH keys? I think it's probably a valid feature request to be able to
specify in a kickstart that the system should have no root password,
but I can't really think of an example where you are doing an attended
install and you wouldn't want at least one of the set of:
1) A local user
2) Joining a domain for centralized users
3) A root password

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEJGbIACgkQeiVVYja6o6MDEwCgozFnTaPnXdsBD8aBZUmysoHC
l5kAnAkOkij35nAOvLXiu0EKDbgsv5py
=musg
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: New firstboot

2013-01-30 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/30/2013 05:08 AM, Martin Sivak wrote:
 Hi,
 
 When I install a freeipa server I do not want firstboot because
 I am not going to create local users anyway. I am going to
 install freeipa and then create users in LDAP.
 
 Could such use cases not be built into firstboot?
 
 Right you are, see another proposed feature that works with FreeIPA
 and AD:
 https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration
 

You're confusing what he said here. That feature is great for joining
an existing domain. Simo was saying that firstboot gets in the way if
he is actually setting up the domain controller (which would have no
local users besides root).

That said, the current firstboot allows you to just walk through and
skip user creation, last I checked. So I'm not sure why you need to
cancel it. If you just don't enter anything in the username and
password fields, it doesn't stop you.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEJGnEACgkQeiVVYja6o6OCOwCfaUu5jfRDcg1SMe+qp6v0jNp4
h/0An0uFRn1/ExV09xfhqrSgw47Jcdbq
=jJBJ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: Apache OpenOffice

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

Feature owner(s): Andrea Pescetti pesce...@apache.org

Add Apache OpenOffice, the free productivity suite, to Fedora. 

== Detailed description ==
Apache OpenOffice (formerly OpenOffice.org) is the the leading free and open-
source office software suite.

Donated by Oracle to the Apache Software Foundation in 2011, it is now 
developed and supported by a thriving community; it graduated from the Apache 
Incubator in October 2012 and it is now an Apache Top-Level Project.

Two new versions, 3.4.0 and 3.4.1, were released in the last 8 months and a 
major update, 4.0, is in the works and scheduled for April 2012. Versions 
3.4.0 and 3.4.1 totalled 35 million downloads so far (not counting mirrors).

To be clear, this proposal is about merely adding Apache OpenOffice: it doesn't 
affect existing office suites included in Fedora and it doesn't require that 
Apache OpenOffice is made the default office suite in Fedora.
___
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: Federated VoIP

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

Feature owner(s): Daniel Pocock dan...@pocock.com.au

Make it easier for the deployment of federated SIP and XMPP (Jabber) networks, 
functioning much like federated SMTP email. 

== Detailed description ==
Many VoIP installations still operate on a standalone basis, often with a 
single SIP proxy or soft PBX trunking all calls to an external provider. 
Ideally, VoIP should be fully federated, with no central provider other than 
perhaps the DNS. This feature aims to bring that vision closer to reality, by 
making it easier to start a SIP proxy in federated mode, using TLS by default 
for security/identity of external peers and benefiting from ENUM for legacy 
phone numbers.
___
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: firewalld Lockdown

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

Feature owner(s): Thomas Woerner twoer...@redhat.com

This feature adds a simple configuration setting for firewalld to be able to 
lock down configuration changes from local applications. 

== Detailed description ==
Local applications are able to change the firewall configuration. With this 
feature the administator can lock the firewall configuration and these 
applications are not able to modify the firewall anymore.

The lockdown feature is the first part of user and application policies for 
firewalld and will be disabled by default. 
___
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: firewalld Rich Language

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

Feature owner(s): Thomas Woerner twoer...@redhat.com

This feature adds a rich (high level) language to firewalld, that allows to 
easily create complex firewall rules without the knowledge of iptables syntax.

= Detailed Description =
Currently, complex firewall rules can only be added using the direct interface 
of firewalld. But this requires to know the syntax of iptables and the rules 
are not permanent.

With the rich language more complex firewall rules can be created in an easy to 
understand way. The language will use keywords with (sometimes multiple) 
values and will be an abstract representation of ip*tables and ebtables rules. 
Services and zones can be configured using this language, the current 
configuration will still be supported.

A mixture of the old and new configuration of services and zones might be 
possible, but this needs to be verified. With the possibility to use the rich 
language in services and zones, the configuration will also be permanent.

The configuration with files will be available for Fedora 19. The D-BUS 
interface with the command line client should be finished, but this depends on 
Fedora 19 schedule. UI work will most likely be available later (depends on 
Fedora 19 schedule also). 
___
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: NetworkManager Bonding Support

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

Feature owner(s):  Pavel Šimerda psimerda at redhat.com, Dan Williams dcbw 
at redhat dot com 

NetworkManager should be able to configure bond master interfaces with commonly 
used options and recognize their existing configuration on startup without 
disrupting their operation.

== Detailed description ==
NetworkManager's existing support for bond interfaces covers a limited number 
of use-cases and can conflict with existing bonding configurations created by 
tools like libvirt. The purpose of this Fedora feature is to implement more 
flexible bonding infrastructure in NetworkManager to support an expanded number 
of use-cases and to be more cooperative with other users of bonding.

Support will be added to NetworkManager to detect the existing configuration of 
a bond interface and its slaves and to seamless take over that connection 
without disrupting it. Even if the existing configuration is not backed by 
ifcfg files on-disk, NetworkManager will leave that configuration on the 
interface unless told to change it by the user via GUI or CLI tools. 
Additional bond interface configuration will be added to expand the use-cases 
and hardware that NetworkManager can configure (eg primary, use_carrier, 
xmit_hash_policy, etc). 
___
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: NetworkManager Bridging Support

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

Feature owner(s):  Pavel Šimerda psimerda at redhat.com, Dan Williams dcbw 
at redhat dot com 

NetworkManager should be able to configure bridge interfaces with commonly used 
options and recognize their existing configuration on startup without 
disrupting their operation.

== Detailed description ==
A bridge connects two or more physical or virtual network interfaces to allow 
network traffic to flow between the two interfaces at a low level. Bridging is 
commonly used to connect Virtual Machines to the outside world; a bridge 
interface is created, to which a physical interface (typically ethernet) is 
assigned as a slave, and a virtual interface (typically TAP) is created and 
also assigned to the bridge as a slave, and then given to the Virtual Machine. 
Thus traffic from one or more VMs can be combined and sent out of the machine 
via the physical interface.

This setup is currently done either manually using ifcfg files and ifup/ifdown, 
or by a tool like libvirt/netcf. NetworkManager should be able to configure 
bridge interfaces and their slaves with the same functionality as provided by 
libvirt, and should recognize and not disrupt existing bridge connections when 
it starts up. 
___
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: Apache OpenOffice

2013-01-30 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/30/2013 07:44 AM, Jaroslav Reznik wrote:
 = Features/ApacheOpenOffice = 
 https://fedoraproject.org/wiki/Features/ApacheOpenOffice
 
 Feature owner(s): Andrea Pescetti pesce...@apache.org
 
 Add Apache OpenOffice, the free productivity suite, to Fedora.
 
 == Detailed description == Apache OpenOffice (formerly
 OpenOffice.org) is the the leading free and open- source office
 software suite.
 
 Donated by Oracle to the Apache Software Foundation in 2011, it is
 now developed and supported by a thriving community; it graduated
 from the Apache Incubator in October 2012 and it is now an Apache
 Top-Level Project.
 
 Two new versions, 3.4.0 and 3.4.1, were released in the last 8
 months and a major update, 4.0, is in the works and scheduled for
 April 2012. Versions 3.4.0 and 3.4.1 totalled 35 million downloads
 so far (not counting mirrors).
 
 To be clear, this proposal is about merely adding Apache
 OpenOffice: it doesn't affect existing office suites included in
 Fedora and it doesn't require that Apache OpenOffice is made the
 default office suite in Fedora.

Given that OpenOffice and LibreOffice share a common history (and not
that far back), are there going to be any efforts made to allow them
to be parallel-installable on the system, or will they be
fully-fledged Conflicts: packages?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEJHpoACgkQeiVVYja6o6NKTwCdHQNiLQ2/0hvnPEool39c/EHG
QYsAoKcrEJFBrYnh6rhUpFJZ/1B70OyL
=/hEX
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/30/2013 07:44 AM, Jaroslav Reznik wrote:
  = Features/ApacheOpenOffice =
  https://fedoraproject.org/wiki/Features/ApacheOpenOffice
  
  Feature owner(s): Andrea Pescetti pesce...@apache.org
  
  Add Apache OpenOffice, the free productivity suite, to Fedora.
  
  == Detailed description == Apache OpenOffice (formerly
  OpenOffice.org) is the the leading free and open- source office
  software suite.
  
  Donated by Oracle to the Apache Software Foundation in 2011, it is
  now developed and supported by a thriving community; it graduated
  from the Apache Incubator in October 2012 and it is now an Apache
  Top-Level Project.
  
  Two new versions, 3.4.0 and 3.4.1, were released in the last 8
  months and a major update, 4.0, is in the works and scheduled for
  April 2012. Versions 3.4.0 and 3.4.1 totalled 35 million downloads
  so far (not counting mirrors).
  
  To be clear, this proposal is about merely adding Apache
  OpenOffice: it doesn't affect existing office suites included in
  Fedora and it doesn't require that Apache OpenOffice is made the
  default office suite in Fedora.
 
 Given that OpenOffice and LibreOffice share a common history (and not
 that far back), are there going to be any efforts made to allow them
 to be parallel-installable on the system, or will they be
 fully-fledged Conflicts: packages?

As stated in Feature page - it's definitely not going to be solved by
conflicting these two packages, the problem seems to be soffice alias
only, see the Scope section.

Jaroslav

 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iEYEARECAAYFAlEJHpoACgkQeiVVYja6o6NKTwCdHQNiLQ2/0hvnPEool39c/EHG
 QYsAoKcrEJFBrYnh6rhUpFJZ/1B70OyL
 =/hEX
 -END PGP SIGNATURE-
 --
 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

2013-01-30 Thread John . Florian

 From: Stephen Gallagher sgall...@redhat.com

 That said, the current firstboot allows you to just walk through and
 skip user creation, last I checked. So I'm not sure why you need to
 cancel it. If you just don't enter anything in the username and
 password fields, it doesn't stop you.


Exactly right, and that's all I'm asking for out of the new firstboot -- 
preferably with a keystroke or click from the initial firstboot dialog.

I just want to avoid what happened for a few old Fedora releases (10-13 
ish) where you were not allowed to skip user creation/joining a domain 
short of having to go out out of your way by booting into a non-default 
run-level, removing firstboot, etc.

--
John Florian

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

[perl] Sub-package Text-Soundex

commit 041bd01ba4573d768795a9ed1e067db0db93fd98
Author: Petr Písař ppi...@redhat.com
Date:   Wed Jan 30 13:41:13 2013 +0100

Sub-package Text-Soundex

 perl.spec |   37 ++---
 1 files changed, 34 insertions(+), 3 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index e2ff79d..e527324 100644
--- a/perl.spec
+++ b/perl.spec
@@ -29,7 +29,7 @@
 Name:   perl
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:249%{?dist}
+Release:250%{?dist}
 Epoch:  %{perl_epoch}
 Summary:Practical Extraction and Report Language
 Group:  Development/Languages
@@ -1214,6 +1214,24 @@ BuildArch:  noarch
 %description Test-Simple-tests
 This package provides the test suite for package perl-Test-Simple.
 
+%package Text-Soundex
+Summary:Implementation of the soundex algorithm
+Group:  Development/Libraries
+License:Copyright only
+Epoch:  0
+# perl's 3.03_1 copy is identical to CPAN 3.03
+Version:3.03
+Requires:   %perl_compat
+Requires:   perl(Carp)
+Requires:   perl(Text::Unidecode)
+Conflicts:  perl  4:5.16.2-250
+
+%description Text-Soundex
+Soundex is a phonetic algorithm for indexing names by sound, as pronounced in
+English. This module implements the original soundex algorithm developed by
+Robert Russell and Margaret Odell, as well as a variation called American
+Soundex.
+
 %package Time-Piece
 Summary:Time objects from localtime and gmtime
 Group:  Development/Libraries
@@ -1376,8 +1394,8 @@ Requires:   perl-Params-Check, perl-Parse-CPAN-Meta, 
perl-Perl-OSType
 Requires:   perl-Pod-Escapes, perl-Pod-LaTeX, perl-Pod-Parser,
 Requires:   perl-Pod-Perldoc, perl-podlators, perl-Pod-Simple
 Requires:   perl-Socket, perl-Term-UI, perl-Test-Harness, perl-Test-Simple
-Requires:   perl-Time-Piece, perl-Version-Requirements, perl-version
-Requires:   perl-threads, perl-threads-shared, perl-parent
+Requires:   perl-Text-Soundex, perl-Time-Piece, perl-Version-Requirements,
+Requires:   perl-version, perl-threads, perl-threads-shared, perl-parent
 
 %description core
 A metapackage which requires all of the perl bits and modules in the upstream
@@ -2158,6 +2176,11 @@ sed \
 %exclude %{_mandir}/man3/Test::Simple*
 %exclude %{_mandir}/man3/Test::Tutorial*
 
+# Text-Soundex
+%exclude %{archlib}/auto/Text/Soundex/
+%exclude %{archlib}/Text/Soundex.pm
+%exclude %{_mandir}/man3/Text::Soundex.*
+
 # Time::Piece
 %exclude %{archlib}/Time/Piece.pm
 %exclude %{archlib}/Time/Seconds.pm
@@ -2742,6 +2765,11 @@ sed \
 %{perl5_testdir}/Test-Simple
 %endif
 
+%files Text-Soundex
+%{archlib}/auto/Text/Soundex/
+%{archlib}/Text/Soundex.pm
+%{_mandir}/man3/Text::Soundex.*
+
 %files Time-Piece
 %{archlib}/Time/Piece.pm 
 %{archlib}/Time/Seconds.pm
@@ -2785,6 +2813,9 @@ sed \
 
 # Old changelog entries are preserved in CVS.
 %changelog
+* Wed Jan 30 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-250
+- Sub-package Text-Soundex (bug #905889)
+
 * Tue Jan 29 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-249
 - Run-require POD convertors by Module-Build and ExtUtils-MakeMaker to
   generate documentation when building other packages
--
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

[perl] Fix conflict declaration at perl-Pod-LaTeX

commit 907fd9bb7dab48cf9fc6bb66fb4c8e6edc32ec3f
Author: Petr Písař ppi...@redhat.com
Date:   Wed Jan 30 13:52:58 2013 +0100

Fix conflict declaration at perl-Pod-LaTeX

 perl.spec |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index e527324..846cc5a 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1057,7 +1057,7 @@ Epoch:  0
 Version:0.60
 Requires:   %perl_compat
 BuildArch:  noarch
-Conflicts:  perl  4:5.16.1-248
+Conflicts:  perl  4:5.16.2-248
 
 %description Pod-LaTeX
 Pod::LaTeX is a module to convert documentation in the POD format into
@@ -2815,6 +2815,7 @@ sed \
 %changelog
 * Wed Jan 30 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-250
 - Sub-package Text-Soundex (bug #905889)
+- Fix conflict declaration at perl-Pod-LaTeX (bug #904085)
 
 * Tue Jan 29 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-249
 - Run-require POD convertors by Module-Build and ExtUtils-MakeMaker to
--
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

[perl] Remove bundled Module-Pluggable

commit a0837e73998de6f544e544f7d0f7cfdfd2b0c786
Author: Petr Písař ppi...@redhat.com
Date:   Wed Jan 30 14:17:40 2013 +0100

Remove bundled Module-Pluggable

 perl.spec |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 846cc5a..0e9bfbd 100644
--- a/perl.spec
+++ b/perl.spec
@@ -921,6 +921,7 @@ Requires:   %perl_compat
 Gather package and POD information from perl module files
 %endif
 
+%if %{dual_life} || %{rebuild_from_scratch}
 %package Module-Pluggable
 Summary:Automatically give your module the ability to have plugins
 Group:  Development/Libraries
@@ -935,6 +936,7 @@ BuildArch:  noarch
 %description Module-Pluggable
 Provides a simple but, hopefully, extensible way of having 'plugins' for your
 module.
+%endif
 
 
 %package Object-Accessor
@@ -2600,12 +2602,14 @@ sed \
 %{_mandir}/man3/Module::Metadata.3pm*
 %endif
 
+%if %{dual_life} || %{rebuild_from_scratch}
 %files Module-Pluggable
 %{privlib}/Devel/InnerPackage.pm
 %{privlib}/Module/Pluggable/
 %{privlib}/Module/Pluggable.pm
 %{_mandir}/man3/Devel::InnerPackage*
 %{_mandir}/man3/Module::Pluggable*
+%endif
 
 %files Object-Accessor
 %{privlib}/Object/
@@ -2816,6 +2820,7 @@ sed \
 * Wed Jan 30 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-250
 - Sub-package Text-Soundex (bug #905889)
 - Fix conflict declaration at perl-Pod-LaTeX (bug #904085)
+- Remove bundled Module-Pluggable (bug #903624)
 
 * Tue Jan 29 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-249
 - Run-require POD convertors by Module-Build and ExtUtils-MakeMaker to
--
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: Apache OpenOffice

2013-01-30 Thread Michael Scherer

Le mercredi 30 janvier 2013 à 12:44 +, Jaroslav Reznik a écrit :

 Two new versions, 3.4.0 and 3.4.1, were released in the last 8 months and a 
 major update, 4.0, is in the works and scheduled for April 2012.

I assume that's planned for 2013, not 2012 ?

-- 
Michael Scherer

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

Re: Proposed F19 Feature: Apache OpenOffice

2013-01-30 Thread François Cami

Hello,

On Wed, Jan 30, 2013 at 1:44 PM, Jaroslav Reznik jrez...@redhat.com wrote:
 = Features/ApacheOpenOffice =
 https://fedoraproject.org/wiki/Features/ApacheOpenOffice

 Feature owner(s): Andrea Pescetti pesce...@apache.org

 Add Apache OpenOffice, the free productivity suite, to Fedora.

 == Detailed description ==
 Apache OpenOffice (formerly OpenOffice.org) is the the leading free and open-
 source office software suite.

I would object to the use of the word leading there, merely on
subjective grounds.

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

Proposed F19 Feature: Pcsd Configuration Wizards

= Features/Pcsd Configuration Wizards =
https://fedoraproject.org/wiki/Features/Pcsd_Configuration_Wizards

Feature owner(s): Chris Feist cfe...@redhat.com

This feature will allow easier building of configuration wizards for pcsd (the 
Pacemaker/Corosync GUI), so through a simple configuration file we can create 
wizards for some common configurations (such as setting up a 2 nodes HA 
webserver). 

== Detailed description ==
The new feature will allow for a configuration file to be used to create 
wizards 
(instead of manually creating javascript/html, etc.) for each separate wizard.

Initially the simple configuration wizards will include the following:
* 2 node HA webserver 
___
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: oVirt engine 3.2

= Features/oVirtEngine 3.2 =
https://fedoraproject.org/wiki/Features/oVirtEngine_3.2

Feature owner(s): Juan Hernández juan.hernan...@redhat.com

The oVirt engine is the management application of the oVirt virtualization 
platform. Version 3.2 is the latest version, including many new features. 

== Detailed description ==
Version 3.1 of the oVirt engine was already included in Fedora 18, but we want 
to bring the new features provided by version 3.2.

The version 3.2 of the oVirt engine includes the web based user interface for 
administrators and users, and many new features, for example:

* UI plugins
* Make network a main tab
* Import of existing gluster clusters
* Bootstrap improvements
* PKI improvments
* MOM
* Improved quota
* Integrate smartcard support
* Display address override
* VM creation base on pre-defined profiles (instance types)
* Storage live migration (needs to be checked)
* Sync network
* Port mirroring
* User level api
* Automatic storage domain upgrade
* Unidirectional Gluster geo-replication support
* Support for asynchronous Gluster volume tasks
* Gluster volume performance statistics
* Configuration sync with Gluster CLI
* Monitoring Gluster Volumes and Bricks
___
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: Realmd FreeIPA Support

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

Feature owner(s): Stef Walter st...@redhat.com

realmd currently supports discovery and configuring of Active Directory 
domains. With this feature it will also include support for FreeIPA domains.  

== 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.

realmd will be able to be used with FreeIPA. Current GUI and CLI tools that 
use realmd to join Active Directory domains will now be able to seamlessly 
join FreeIPA domains as well. 
___
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: New firstboot

2013-01-30 Thread Martin Sivak

Hi,

the this should be not a problem.

The intended logic here is requiring enabled root OR user(s). We might add ssh 
keys as a valid option if needed too (but I am not sure about entering the key, 
typing it manually is probably not a good idea).

Moreover, initial-setup has a working quit button.

Martin

- Original Message -
 
  From: Stephen Gallagher sgall...@redhat.com
 
  That said, the current firstboot allows you to just walk through
  and
  skip user creation, last I checked. So I'm not sure why you need to
  cancel it. If you just don't enter anything in the username and
  password fields, it doesn't stop you.
 
 
 Exactly right, and that's all I'm asking for out of the new firstboot
 -- preferably with a keystroke or click from the initial firstboot
 dialog.
 
 I just want to avoid what happened for a few old Fedora releases
 (10-13 ish) where you were not allowed to skip user creation/joining
 a domain short of having to go out out of your way by booting into a
 non-default run-level, removing firstboot, etc.
 
 --
 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

Proposed F19 Feature: Systemtap 2.2

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

Feature owner(s): Lukas Berk lb...@redhat.com, Frank Ch. Eigler 
f...@redhat.com

A new feature release of Systemtap.

== Detailed description ==
Systemtap 2.2 will introduce several new features:
* Native Java per-method probing capabilities (using byteman)

Plus new features coming from the impending systemtap 2.1:
* A suite of error-explanation man pages.
* Perf event probes may now be read on demand
* Perf event probes may now be bound to a specific task using the process name
* The dyninst backend's runtime has been improved to allow much more 
concurrency when probing multi-threaded processes
___
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: Thermostat 1.0

= Features/Thermostat1.0 =
https://fedoraproject.org/wiki/Features/Thermostat1.0

Feature owner(s): Omair Majid oma...@redhat.com

== Detailed description ==
Thermostat is a serviceability and instrumentation tool for OpenJDK. The 1.0 
release of thermostat brings a number of new features that developers may find 
very useful.
* More information for Hosts and Java Virtual Machines being monitored
* A stable API for external plugin developers
* Ability to use thermostat, securely, in a network or a cluster 
* An experimental eclipse plugin that lets developers use eclipse as a 
thermostat GUI 

The goal is to get the 1.0 release of thermostat into Fedora 19. If upstream 
also releases 1.1 before the alpha deadline for Fedora 19, we may use that 
instead.
___
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: Apache OpenOffice

2013-01-30 Thread Caolán McNamara

On Wed, 2013-01-30 at 12:44 +, Jaroslav Reznik wrote:
 = Features/ApacheOpenOffice =
 https://fedoraproject.org/wiki/Features/ApacheOpenOffice
 
 Feature owner(s): Andrea Pescetti pesce...@apache.org
 
 Add Apache OpenOffice, the free productivity suite, to Fedora.

A considerable cleanup has been performed since the 3.3.0 times (when
Fedora shipped ooo-build and not a pristine copy of OpenOffice anyway).

Fedora only shiped ooo-build before OpenOffice.org 2.0, so hasn't
shipped ooo-build since early 2005.

C.

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

Re: Proposed F19 Feature: New firstboot

2013-01-30 Thread Matthew Miller

On Wed, Jan 30, 2013 at 08:01:38AM -0500, Stephen Gallagher wrote:
 In what situation would you ever have a system that requires neither
 users nor root access? Or are you saying that root access would be via
 SSH keys? I think it's probably a valid feature request to be able to

Root access via SSH key is one case, yeah. The other is with cloud-init,
where the user is created automatically at boot time using information from
the metadata source.

Either of these can be covered with a kickstart directive.

For the cloud images, and anywhere else where size matters, I'd also like to
avoid pulling in a big one-time-setup infrastructure which won't be used, so
hopefully the dependency integration won't be so tight that the package
itself can't be avoided.


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

Re: Proposed F19 Feature: Apache OpenOffice

2013-01-30 Thread Michael Ekstrand

On 01/30/2013 07:57 AM, François Cami wrote:
 Hello,
 
 On Wed, Jan 30, 2013 at 1:44 PM, Jaroslav Reznik jrez...@redhat.com wrote:
 = Features/ApacheOpenOffice =
 https://fedoraproject.org/wiki/Features/ApacheOpenOffice

 Feature owner(s): Andrea Pescetti pesce...@apache.org

 Add Apache OpenOffice, the free productivity suite, to Fedora.

 == Detailed description ==
 Apache OpenOffice (formerly OpenOffice.org) is the the leading free and open-
 source office software suite.
 
 I would object to the use of the word leading there, merely on
 subjective grounds.

+1. I don't at all object to having Apache OpenOffice available again,
if people want it, but I am skeptical about marketing it as leading.
If that can be objectively demonstrated by some metric (it may well
surpass LibreOffice counting Windows downloads, I do not know), then the
language can stay. But repeating unproven assertions of fact in feature
marketing and messaging does not seem to me to be a good idea.

- Michael

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

Re: Proposed F19 Feature: Checkpoint/Restore

2013-01-30 Thread Josh Boyer

On Thu, Jan 24, 2013 at 11:11 AM, Adrian Reber adr...@lisas.de wrote:
 On Thu, Jan 24, 2013 at 11:02:57AM -0500, Josh Boyer wrote:
  CONFIG_NAMESPACES seems to be required to make all those activated _NS
  options actually enabled:
 
  config-generic:CONFIG_PID_NS=y
  config-generic:CONFIG_UTS_NS=y
  config-generic:CONFIG_IPC_NS=y
  config-generic:CONFIG_NET_NS=y

 Those might be doable.

 To make it clear. This already what is in the kernel package and not a
 change I made. It just needs CONFIG_NAMESPACES to actually be enabled.

The kernel team discussed this at last week's public kernel meeting.  I
think we're comfortable enabling these options.  We're going to patch
the Kconfig so that it doesn't depend on CONFIG_EXPERT, but aside from
that things should be as you suggest.

We'd really like to see some kind of testing framework for this though.
Do you know of any testcases that could be added to the Fedora kernel
testing git tree to cover CRIU?  If not, do you think you could create
some minimal ones?

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

2013-01-30 Thread Reindl Harald



Am 29.01.2013 19:38, schrieb Matthew Garrett:
 On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote:
 
 Except then you run into phones or WWAN cards that show up as Ethernet
 devices, but aren't really Ethernet but just IP-in-8023-frames because
 that was easier to do on Windows.  That one is quite fun, and there's no
 good way to catch them all.  We're obviously behind by marking them
 FLAG_WWAN in the kernel, which has to be done by device IDs, becasue
 some devices use standard cdc-ether or cdc-eem and you can't reliably
 tell them apart from some random D-Link DUB100.
 
 Sure, but that's a fundamentally unsolvable problem - if my primary 
 network connection is via a USB device there's a reasonable chance that 
 it'll be called usb0 anyway. The name isn't providing extra information 
 here

however, as long on virtual machines with ONE network
card get a random name PLEASE leave me in peace with
this feature as also biosdevname did not provide
any benefit for such machines with 1-2 network devices

[root@rawhide ~]# ifconfig
ens160: flags=4163UP,BROADCAST,RUNNING,MULTICAST  mtu 1500
inet 192.168.196.18  netmask 255.255.255.0  broadcast 192.168.196.255
inet6 fe80::20c:29ff:fe85:353c  prefixlen 64  scopeid 0x20link
ether 00:0c:29:85:35:3c  txqueuelen 1000  (Ethernet)
RX packets 169  bytes 17562 (17.1 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 123  bytes 15292 (14.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73UP,LOOPBACK,RUNNING  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10host
loop  txqueuelen 0  (Lokale Schleife)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



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

[Bug 905995] New: perl-Mozilla-LDAP upstream tarball checksum mismatch

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=905995

Bug ID: 905995
   Summary: perl-Mozilla-LDAP upstream tarball checksum  mismatch
   Product: Fedora
   Version: rawhide
 Component: perl-Mozilla-LDAP
  Severity: medium
  Priority: medium
  Reporter: socho...@redhat.com

Your package contains sources which have different checksums from upstream
versions. Please verify they are correct and differences do not pose a problem
for Fedora.
MD5-sum check
-
ftp://ftp.mozilla.org/pub/mozilla.org/directory/perldap/releases/1.5.3/src/perl-mozldap-1.5.3.tar.gz
:
  CHECKSUM(SHA256) this package :
9d707be3a126dd6001205ef72e59e4b892dcda3b3a1e7d061f6f7fc0dba20a68
  CHECKSUM(SHA256) upstream package :
9d707be3a126dd6001205ef72e59e4b892dcda3b3a1e7d061f6f7fc0dba20a68
ftp://ftp.mozilla.org/pub/mozilla.org/directory/perldap/releases/1.5/src/Makefile.PL.rpm
:
  CHECKSUM(SHA256) this package :
946e337be7a112b1e29bce67d495fdf74b50a72303c4aa2f4ddfad5759030e6a
  CHECKSUM(SHA256) upstream package :
8b42cb7f2242afdaf912abe9fd490f783afa453b9bc9c1ae425b12a40dd44cd1
diff -r also reports differences

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=KmiNj70NDfa=cc_unsubscribe
--
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

F19: system-config-kickstart

2013-01-30 Thread Gene Czarcinski

Much is made of the great new anaconda introduced in Fedora 18. But, 
this great new anaconda completely broke system-config-kickstart because 
old-anaconda code used but s-c-k disappeared.


Obviously there was little or no testing of s-c-k or perhaps nobody uses 
it and/or nobody cares.

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

Perhaps there needs to be a F19 Feature which either fixes it or 
eliminates this package.  The current situation is just plain ridiculous.


A lot of what s-c-k did involved software selection.  Perhaps the s-c-k 
interface for this needs to borrow from the Package Manager rather 
than anaconda.


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

Re: Proposed F19 Feature: Checkpoint/Restore

2013-01-30 Thread Adrian Reber

On Wed, Jan 30, 2013 at 10:13:44AM -0500, Josh Boyer wrote:
 On Thu, Jan 24, 2013 at 11:11 AM, Adrian Reber adr...@lisas.de wrote:
  On Thu, Jan 24, 2013 at 11:02:57AM -0500, Josh Boyer wrote:
   CONFIG_NAMESPACES seems to be required to make all those activated _NS
   options actually enabled:
  
   config-generic:CONFIG_PID_NS=y
   config-generic:CONFIG_UTS_NS=y
   config-generic:CONFIG_IPC_NS=y
   config-generic:CONFIG_NET_NS=y
 
  Those might be doable.
 
  To make it clear. This already what is in the kernel package and not a
  change I made. It just needs CONFIG_NAMESPACES to actually be enabled.
 
 The kernel team discussed this at last week's public kernel meeting.  I
 think we're comfortable enabling these options.  We're going to patch
 the Kconfig so that it doesn't depend on CONFIG_EXPERT, but aside from
 that things should be as you suggest.
 
 We'd really like to see some kind of testing framework for this though.
 Do you know of any testcases that could be added to the Fedora kernel
 testing git tree to cover CRIU?  If not, do you think you could create
 some minimal ones?

The userspace part of CRIU (crtools) contains about 100 testcases. Some
of them probably require some kernel patches which are not yet
upstreamed, but I think that most of them would work. I would be happy to
include them in the Fedora kernel testing git tree. No problem.

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

[Bug 906007] New: Please revert the unbundling of inc::Module::Install::DSL, at least when bootstrapping

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=906007

Bug ID: 906007
   Summary: Please revert the unbundling of
inc::Module::Install::DSL, at least when
bootstrapping
   Product: Fedora
   Version: rawhide
 Component: perl-File-Remove
  Severity: unspecified
  Priority: unspecified
  Reporter: p...@city-fan.org

A recent change to the perl-File-Remove package involved removing the bundled
Module::Install::DSL and adding a BuildRequires for it. A side-effect of this
is that perl-File-Remove and perl-Module-Install now BuildRequire each other,
which will prevent a clean bootstrapping of the next major perl release.

Please consider reverting this change, or conditionalizing it on not being a
bootstrap build (using the %{?perl_bootstrap} macro).

I can't understand why this was done in the first place, as it's not a library
bundling issue (the bundled module is not shipped in the built package), and
seems akin to deleting a configure script and re-running the autotools, which
goes contrary to upstream methodology.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=zHGYSD1qi4a=cc_unsubscribe
--
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: F19: system-config-kickstart

On Wed, 30 Jan 2013 11:00:31 -0500
Gene Czarcinski g...@czarc.net wrote:

 Much is made of the great new anaconda introduced in Fedora 18. But, 
 this great new anaconda completely broke system-config-kickstart
 because old-anaconda code used but s-c-k disappeared.
 
 Obviously there was little or no testing of s-c-k or perhaps nobody
 uses it and/or nobody cares.
 https://bugzilla.redhat.com/show_bug.cgi?id=859928
 
 Perhaps there needs to be a F19 Feature which either fixes it or 
 eliminates this package.  The current situation is just plain
 ridiculous.

...snip...

https://fedoraproject.org/wiki/Features/AnacondaNewUI_Followup

...
* Make system-config-kickstart work again. The removal of 
iw/GroupSelector.py from anaconda caused it to break. (#859928)
...

kevin


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

Re: Proposed F19 Feature: systemd features

On Wed, Jan 30, 2013 at 1:08 AM, Kay Sievers k...@vrfy.org wrote:
 And because a major part of the data the hwdb will carry in the future
 will be the equivalent of udev rules, and should not be shipped by a
 different package, because it it might carry specifics needed for a
 certain functionality, just like the udev rules do today.

 If we want to artificially declare the PCI+USB IDs different from the
 rest of the growing hwdb data, and split that into a different package
 and the rest not;

Just because two sets of information have the same primary key does
not necessarily mean they belong even in the same table, let alone the
same database.  udev rules and naming databases are rather different
in purpose, development process, required testing, update frequency,
impact of bugs.

 sure, we can do that when things have stabilized,
 but so far I'm not really sure if that will give is a significant
 advantage, considering that updates just can be installed along with
 the default data.

Things are not stable now, so let's change them, and after they have
stabilized, let's possibly revert the change?  I can't quite see the
rationale for doing things that way.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: MEMSTOMP

From the feature page: 

If the executable does not make undefined calls, then it will run
normally. If it does make undefined calls you will either get an abort
as soon as the undefined call is detected or you will get a backtrace
when the undefined call is detected.

Does this mean abrt will trigger and a bug could be filed?

On the one hand it would be nice to know about problems found by this,
but a bunch of abrt reports might not be nice. 

kevin


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

[perl-Module-Install] Don't unbundle Module::Install as we end up build-requiring ourselves

2013-01-30 Thread Paul Howarth

commit 9489f626259a5c33217558518f8295900f95a981
Author: Paul Howarth p...@city-fan.org
Date:   Wed Jan 30 16:22:31 2013 +

Don't unbundle Module::Install as we end up build-requiring ourselves

 perl-Module-Install.spec |8 
 1 files changed, 4 insertions(+), 4 deletions(-)
---
diff --git a/perl-Module-Install.spec b/perl-Module-Install.spec
index 0dc654f..c1dd274 100644
--- a/perl-Module-Install.spec
+++ b/perl-Module-Install.spec
@@ -1,6 +1,6 @@
 Name:   perl-Module-Install
 Version:1.06
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Standalone, extensible Perl module installer
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -22,11 +22,9 @@ BuildRequires:  perl(File::Remove) = 1.42
 BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::Spec) = 3.28
 BuildRequires:  perl(File::Temp)
-BuildRequires:  perl(inc::Module::Install)
 BuildRequires:  perl(JSON) = 2.14
 BuildRequires:  perl(lib)
 BuildRequires:  perl(LWP::UserAgent) = 5.812
-BuildRequires:  perl(Module::AutoInstall)
 BuildRequires:  perl(Module::Build) = 0.29
 BuildRequires:  perl(Module::CoreList) = 2.17
 BuildRequires:  perl(Module::ScanDeps) = 0.89
@@ -55,7 +53,6 @@ version 5.005 or newer.
 
 %prep
 %setup -q -n Module-Install-%{version}
-rm -rf inc
 
 %build
 perl Makefile.PL INSTALLDIRS=vendor
@@ -76,6 +73,9 @@ make test AUTOMATED_TESTING=1
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jan 30 2013 Paul Howarth p...@city-fan.org - 1.06-3
+- Don't unbundle Module::Install as we end up build-requiring ourselves
+
 * Tue Nov 20 2012 Petr Šabata con...@redhat.com - 1.06-2
 - Add missing deps
 - Unbundle Module::Install
--
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: New firstboot

2013-01-30 Thread Stef Walter

On 01/30/2013 12:14 PM, Jóhann B. Guðmundsson wrote:
 On 01/30/2013 10:08 AM, Martin Sivak wrote:
 Hi,

 When I install a freeipa server I do not want firstboot because I
 am not
 going to create local users anyway. I am going to install freeipa
 and
 then create users in LDAP.
  
 Could such use cases not be built into firstboot?
 Right you are, see another proposed feature that works with FreeIPA
 and AD: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration
 
 In rawhide I see that realmd is constantly running how can I turn it off?

That's a bug. Could you file one in in RHBZ, and we can try and figure
it out together?

Stef

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

Proposed F19 Feature: Network Team driver - Update for new features

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

Feature owner(s): Jiri Pirko j...@pirko.cz

Network Team driver allows multiple network interfaces to be teamed together 
and act like a single one. This update adds several kind of new features to 
it.

== Detailed description ==
The goal is to extend current Team driver experience in Fedora. In order to do 
that, following features will be implemented:

* ARP link validation over VLAN
* Transmit hashing involving L4 headers
* Support for NICs which do now allow mac change on run
* Load balancing support for incoming traffic
* Corrected carrier detection

___
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

[perl] Sub-package B-Lint

commit c68375d963cb969402071887e266fcf1d2901579
Author: Petr Písař ppi...@redhat.com
Date:   Wed Jan 30 17:16:05 2013 +0100

Sub-package B-Lint

 perl.spec |   32 ++--
 1 files changed, 30 insertions(+), 2 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 0e9bfbd..e3e5b91 100644
--- a/perl.spec
+++ b/perl.spec
@@ -29,7 +29,7 @@
 Name:   perl
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:250%{?dist}
+Release:251%{?dist}
 Epoch:  %{perl_epoch}
 Summary:Practical Extraction and Report Language
 Group:  Development/Languages
@@ -295,6 +295,22 @@ IO::Zlib module installed, Archive::Tar will also support 
compressed or
 gzipped tar files.
 %endif
 
+%package B-Lint
+Summary:Perl lint
+Group:  Development/Libraries
+License:GPL+ or Artistic
+Epoch:  0
+Version:1.14
+Requires:   %perl_compat
+Requires:   perl(constant)
+BuildArch:  noarch
+Conflicts:  perl  4:5.16.2-251
+
+%description B-Lint
+The B::Lint module is equivalent to an extended version of the -w option of
+perl. It is named after the program lint which carries out a similar process
+for C programs.
+
 %if %{dual_life} || %{rebuild_from_scratch}
 %package Carp
 Summary:Alternative warn and die for modules
@@ -1377,7 +1393,8 @@ Requires:   perl-libs = 
%{perl_epoch}:%{perl_version}-%{release}
 Requires:   perl-devel = %{perl_epoch}:%{perl_version}-%{release}
 Requires:   perl-macros
 
-Requires:   perl-Archive-Extract, perl-Archive-Tar, perl-Compress-Raw-Bzip2
+Requires:   perl-Archive-Extract, perl-Archive-Tar, perl-B-Lint,
+Requires:   perl-Compress-Raw-Bzip2,
 Requires:   perl-Carp, perl-Compress-Raw-Zlib, perl-CGI, perl-CPAN,
 Requires:   perl-CPAN-Meta, perl-CPAN-Meta-YAML, perl-CPANPLUS,
 Requires:   perl-Data-Dumper, perl-Digest, perl-Digest-MD5, 
perl-Digest-SHA,
@@ -1747,6 +1764,10 @@ sed \
 %exclude %{_mandir}/man1/ptargrep.1*
 %exclude %{_mandir}/man3/Archive::Tar*
 
+# B-Lint
+%exclude %{privlib}/B/Lint*
+%exclude %{_mandir}/man3/B::Lint*
+
 # Carp
 %exclude %{privlib}/Carp
 %exclude %{privlib}/Carp.*
@@ -2265,6 +2286,10 @@ sed \
 %{_mandir}/man3/Archive::Tar* 
 %endif
 
+%files B-Lint
+%{privlib}/B/Lint*
+%{_mandir}/man3/B::Lint*
+
 %if %{dual_life} || %{rebuild_from_scratch}
 %files Carp
 %{privlib}/Carp
@@ -2817,6 +2842,9 @@ sed \
 
 # Old changelog entries are preserved in CVS.
 %changelog
+* Wed Jan 30 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-251
+- Sub-package B-Lint (bug #906015)
+
 * Wed Jan 30 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-250
 - Sub-package Text-Soundex (bug #905889)
 - Fix conflict declaration at perl-Pod-LaTeX (bug #904085)
--
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

Static Analysis: tweaks to data model and added cpychecker support

2013-01-30 Thread David Malcolm

Short version:
Updates to mock-with-analysis [1]:
(a) changes to the data model
(b) cpychecker support added

Longer version:
I've been hacking on mock-with-analysis, my tool for running static
code analysis as a side-effect within a regular srpm rebuild (see [1]).

I've tweaked the data model (the firehose XML format [2]): before, we
were outputting one XML file every time an analysis tool found a
problem. This approach doesn't capture coverage: we wouldn't know which
tools were run on which code. So I've reworked things so that each XML
file represents a run of an analysis tool on a source file, and contains
zero or more issues (all in a common XML format). It also can contain
stats e.g. the wall-clock time of how long the analysis tool on that
file. We probably should extend it to capture other metadata like what
arguments were passed to GCC (e.g. the -W options).

I've also been working on the cpychecker analyser [3] that's part of
my gcc-python-plugin. This is an analyzer for C code. It looks for
common mistakes in usage of the CPython extension API, such as
reference-counting bugs.

The firehose branch of the gcc-python-plugin [4] now uses the firehose
Python API as the internal representation format within cpychecker, and
can thus natively emit XML files in our format, and I've hooked it up
in mock-with-analysis so it gets run on all C code.

So the mock-with-analysis prototype now has the following run in a mock
build:
* cppcheck
* clang-analyzer
* gcc warnings
* cpychecker

You can see an example of the output here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool-0.7-4.fc19.src.rpm/

As before, it's the results from mock, with a new static-analysis
directory containing XML result files, and any source files mentioned in
the results (grep for FAKE-GCC in the build.log to see copious debug
spew from the analysis tools). The raw XML results can be seen here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool-0.7-4.fc19.src.rpm/static-analysis/reports/
though most of them are empty (most source files had no issues).

To make things slightly easier to read, I wrote a primitive HTML
summarizer, and you can see the (ugly) result here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool-0.7-4.fc19.src.rpm/ugly-summary.html

Note though that this output is really just for debugging. (In
particular, it's violating my #1 UI requirement, which is that any time
I see an analysis report, I want to also see the *code* so that a
developer can easily determine if she needs to act on the report -
though the sources have been captured - it's just a case of writing a
nice UI to this).

(Note that this version of cpychecker can emit reports showing a trace
of execution needed to reach certain error, and this makes it into the
XML - it's just that no such errors were present in this rpm).

Next steps are to try running it on more packages, to make things more
robust, and to build a good UI (e.g. to present a comparative view of
two builds: what new warnings appeared? etc).

If you're interested in getting involved, I've started making a list of
things to try here:
https://fedoraproject.org/wiki/StaticAnalysis#Tasks_seeking_volunteers

Dave

[1] see
http://lists.fedoraproject.org/pipermail/devel/2013-January/176872.html
and https://github.com/fedora-static-analysis/mock-with-analysis
[2] https://github.com/fedora-static-analysis/firehose
[3] https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html
[4]
http://git.fedorahosted.org/cgit/gcc-python-plugin.git/log/?h=firehose

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

[perl-Image-Info] Created tag perl-Image-Info-1.33-2.fc19

2013-01-30 Thread Paul Howarth

The lightweight tag 'perl-Image-Info-1.33-2.fc19' was created pointing to:

 b1a6842... Don't BR: perl(Image::TIFF); it's provided by this package
--
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: NetworkManager Bridging Support

2013-01-30 Thread Robert Kukura

On 01/30/2013 08:03 AM, Jaroslav Reznik wrote:
 = Features/NetworkManagerBridging =
 https://fedoraproject.org/wiki/Features/NetworkManagerBridging
 
 Feature owner(s):  Pavel Šimerda psimerda at redhat.com, Dan Williams dcbw 
 at redhat dot com 
 
 NetworkManager should be able to configure bridge interfaces with commonly 
 used 
 options and recognize their existing configuration on startup without 
 disrupting their operation.

Is the scope of this feature intended to cover both traditional (brctl)
bridges and Open vSwitch (i.e. ovs-vsctl, ...) bridges? Both types of
bridging are supported by plugins for openstack-quantum, and it would be
great to make sure this feature works nicely with quantum.

-Bob

 
 == Detailed description ==
 A bridge connects two or more physical or virtual network interfaces to allow 
 network traffic to flow between the two interfaces at a low level. Bridging 
 is 
 commonly used to connect Virtual Machines to the outside world; a bridge 
 interface is created, to which a physical interface (typically ethernet) is 
 assigned as a slave, and a virtual interface (typically TAP) is created and 
 also assigned to the bridge as a slave, and then given to the Virtual 
 Machine. 
 Thus traffic from one or more VMs can be combined and sent out of the machine 
 via the physical interface.
 
 This setup is currently done either manually using ifcfg files and 
 ifup/ifdown, 
 or by a tool like libvirt/netcf. NetworkManager should be able to configure 
 bridge interfaces and their slaves with the same functionality as provided by 
 libvirt, and should recognize and not disrupt existing bridge connections 
 when 
 it starts up. 
 ___
 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

[Bug 906007] Please revert the unbundling of inc::Module::Install::DSL, at least when bootstrapping

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=906007

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

   Fixed In Version||perl-File-Remove-1.52-5.fc1
   ||9

--- Comment #2 from Petr Šabata psab...@redhat.com ---
I've reverted the change in perl-File-Remove-1.52-5.fc19.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=gaqjjgaiP5a=cc_unsubscribe
--
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

[Bug 906007] Please revert the unbundling of inc::Module::Install::DSL, at least when bootstrapping

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=906007

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2013-01-30 11:40:07

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=87QDScQmiYa=cc_unsubscribe
--
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

Fedora ARM weekly status meeting 2013-01-30

2013-01-30 Thread Paul Whalen

This weeks Fedora ARM status meeting will take place today (Wednesday Jan 30th) 
in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):

PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm

Current items on the agenda:

0) Status of ACTION items from previous meeting

1) Problem packages

2) F18 final RC planning

3) Mass Rebuild - Does anything need to be done?

4) Your topic here!

If you have any other items you would like to discuss that are not mentioned, 
please feel free to send an email to the list or bring it up at the end of the 
meeting.

Paul
-- 
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 2:12 PM, Jiri Eischmann eischm...@redhat.com wrote:
 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.

If you want a more statistically representative sample, I hear there
is an office of about 500 mostly Linux users somewhere in Czech
Republic :)  Just go through all the floors and ask everyone to avoid
self-selection bias.  (The single-company bias is still there, but at
least that can't be accused of being anti-GNOME.)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how reload udev rules and systemd on F18

2013-01-30 Thread Sérgio Basto

On Ter, 2013-01-29 at 17:59 +, Sérgio Basto wrote: 
 On Ter, 2013-01-29 at 01:52 +0100, Lennart Poettering wrote:
  Yes, even then. udev will notice rules dropped there.
 
 OK I will test that 

Sorry other question , if this is True since when is True ? is
applicable on F16 ? 

Many thanks, 
-- 
Sérgio M. B.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Wed, Jan 30, 2013 at 4:13 AM, Máirín Duffy du...@fedoraproject.org wrote:
 On 01/29/2013 04:59 PM, Eric Smith wrote:
 I don't disagree with the more research and reason part, but the
 current default desktop has only been our default for four releases,
 F15 through F18.  I don't recall any serious research and reason
 having been involved in the switch that occurred when F15 was being
 developed.  As far as I can tell, it was just thrust upon us without
 much consideration as to whether it was good, bad, or indifferent.

 Actually a lot of research and reason went into GNOME 3's development
 [1],
That's about as relevant as a lot of coding went into $project,
which is... not a whole lot when considering which project to make the
default.

 and we picked it up because we are an upstream distro [2].
GNOME isn't the only possible upstream.  We picked it up at that time
implicitly because it was presented as an upgrade instead of basically
a new project with a new direction.

 https://live.gnome.org/GnomeShell/Design#Research.2C_testing_and_validation
To save others time... the testing and validation part has no
results on the wiki that I can see.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

Kay Sievers (k...@vrfy.org) said: 
  Either you're intending for the lifetime of your OS to be shipping systemd
  updates that update the base data set,
 
 I don't intend to ship update packages in the context of systemd, we
 can just update the data in the package like we add patches for other
 fixes, in case we need an update. In the end PCI+USB IDs are just
 pretty boring names for humans, not used in the system itself. What
 makes them so special? It really sounds more like cosmetic care, than
 a real technical need to update these more often than we will need to
 update systemd anyway.
 
  or you're intending to be shipping
  updated data sets in a separate package.
 
 We can just do that, but still could ship the default data in the main 
 package.

Would we be moving the other data to this model as well? I note that in
F18 we ended up building systemd many many times just to update keymap
conversions; it's wasteful in terms of builds and updates for users to be
updating all of systemd just to add a new French keymap conversion, or
to add a quirk just for some new laptop.

The point is, we've done this in the past where we shipped the data with
the tools, and we very quickly moved to shipping the data separate - it's
cleaner, allows for just updating the data when necessary, and it forces
people to keep their API  ABI for accessing it stable. :)

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

Re: Proposed F19 Feature: Network Team driver - Update for new features

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Features/TeamDriverUpdate =
 https://fedoraproject.org/wiki/Features/TeamDriverUpdate
 
 Feature owner(s): Jiri Pirko j...@pirko.cz
 
 Network Team driver allows multiple network interfaces to be teamed together 
 and act like a single one. This update adds several kind of new features to 
 it.
 
 == Detailed description ==
 The goal is to extend current Team driver experience in Fedora. In order to 
 do 
 that, following features will be implemented:
 
 * ARP link validation over VLAN
 * Transmit hashing involving L4 headers
 * Support for NICs which do now allow mac change on run
 * Load balancing support for incoming traffic
 * Corrected carrier detection

These seem like reasonable changes for the team driver, but I'm not seeing
how this merits a full Feature compared to the feature for its initial
addition.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, Jan 28, 2013 at 10:07 AM, Aleksandar Kurtakov
akurt...@redhat.com wrote:
 Regarding Cinnamon as Default Desktop - how many active contributors do 
 really take care of Cinnamon packaging? I don't think that anything that has 
 less than 3-4 can even be considered. Last time I checked the only options 
 that were satisfying such requirement were KDE and Gnome. I would be happy to 
 be proven wrong and we gained 10+ contributors for all the various desktops 
 we ship.
 Quantity really matters in this case.

Quantity doesn't tell the whole story.

There are projects that handle every bug report, and publish about
bi-weekly bug fix updates in Fedora. There are also projects in which
some members are quite public about never looking at the Fedora
bugzilla mail.

(From a quick look, and taking into the different number of current
users and existing history, it's unclear whether there is a noticeable
difference between Cinnamon and GNOME 3 with respect to Fedora-focused
maintenance manpower of the relevant packages.)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

2013-01-30 Thread Tomas Mraz

On Wed, 2013-01-30 at 13:07 -0500, Bill Nottingham wrote: 
 Kay Sievers (k...@vrfy.org) said: 
   Either you're intending for the lifetime of your OS to be shipping systemd
   updates that update the base data set,
  
  I don't intend to ship update packages in the context of systemd, we
  can just update the data in the package like we add patches for other
  fixes, in case we need an update. In the end PCI+USB IDs are just
  pretty boring names for humans, not used in the system itself. What
  makes them so special? It really sounds more like cosmetic care, than
  a real technical need to update these more often than we will need to
  update systemd anyway.
  
   or you're intending to be shipping
   updated data sets in a separate package.
  
  We can just do that, but still could ship the default data in the main 
  package.
 
 Would we be moving the other data to this model as well? I note that in
 F18 we ended up building systemd many many times just to update keymap
 conversions; it's wasteful in terms of builds and updates for users to be
 updating all of systemd just to add a new French keymap conversion, or
 to add a quirk just for some new laptop.
 
 The point is, we've done this in the past where we shipped the data with
 the tools, and we very quickly moved to shipping the data separate - it's
 cleaner, allows for just updating the data when necessary, and it forces
 people to keep their API  ABI for accessing it stable. :)

+1 million - another data point - ca-certificates package - it was much
cleaner to split it out of openssl.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Sun, Jan 27, 2013 at 3:53 PM, Jaroslav Reznik jrez...@redhat.com wrote:
 = Features/Cinnamon as Default Desktop =
 https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

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

Most if not all packages are actually owned by Leigh Scott, who I
haven't seen participate in the discussion in the feature.  Leigh,
what do you think about the proposal?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

On Wed, 30 Jan 2013 19:18:40 +0100
Tomas Mraz tm...@redhat.com wrote:

 +1 million - another data point - ca-certificates package - it was
 much cleaner to split it out of openssl.

+1 a lot from me too. Adding to churn of a core system component to
simply update data files is bad. 

kevin


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-30 Thread Máirín Duffy

On 01/30/2013 01:05 PM, Miloslav Trmač wrote:
 Actually a lot of research and reason went into GNOME 3's development
 [1],
 That's about as relevant as a lot of coding went into $project,
 which is... not a whole lot when considering which project to make the
 default.

But every release is not a decision point, which desktop will we make
default this time? Certainly it is *not* a given or granted that any
given software project we have as an upstream has done *any* usability
or user experience research whatsoever, so in that aspect GNOME is
pretty rare.

 and we picked it up because we are an upstream distro [2].
 GNOME isn't the only possible upstream.  We picked it up at that time
 implicitly because it was presented as an upgrade instead of basically
 a new project with a new direction.

I meant in the sense, 'do we stick with GNOME 2.x or move to 3.x FWIW.
 
 https://live.gnome.org/GnomeShell/Design#Research.2C_testing_and_validation
 To save others time... the testing and validation part has no
 results on the wiki that I can see.

That's a very fair point: I'd very much like to see data there as well.

~m

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-30 Thread Dan Mashal

On Wed, Jan 30, 2013 at 10:22 AM, Miloslav Trmač m...@volny.cz wrote:
 On Sun, Jan 27, 2013 at 3:53 PM, Jaroslav Reznik jrez...@redhat.com wrote:
 = Features/Cinnamon as Default Desktop =
 https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

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

 Most if not all packages are actually owned by Leigh Scott, who I
 haven't seen participate in the discussion in the feature.  Leigh,
 what do you think about the proposal?
 Mirek
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

If I may comment here, as someone who has been working with Leigh for
the past few months on various things.

Leigh's getting a kick out of it (this discussion) as far as I an tell
and I don't think he'd be opposed to it provided he actually had some
support besides upstream and myself. I didn't really do much except
watch Bugzilla and commits since I did his package review which was
stalled for 7+ months.

You see the Cinnamon/MATE community is pretty closely tied together.

FYI Cinnamon upstream the Linux Mint development team.

https://github.com/linuxmint/cinnamon

Linux Mint it is actually how I discovered both DEs.

I spoke with Clem Lefebvre (creator of Linux Mint) last night they
have a great upstream core of developers.

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

Re: Proposed F19 Feature: systemd features

2013-01-30 Thread Jakub Jelinek

On Wed, Jan 30, 2013 at 07:18:40PM +0100, Tomas Mraz wrote:
  The point is, we've done this in the past where we shipped the data with
  the tools, and we very quickly moved to shipping the data separate - it's
  cleaner, allows for just updating the data when necessary, and it forces
  people to keep their API  ABI for accessing it stable. :)
 
 +1 million - another data point - ca-certificates package - it was much
 cleaner to split it out of openssl.

Ditto splitting of timezone data from glibc-common to tzdata.

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

Re: Proposed F19 Feature: MATE Desktop 1.6

2013-01-30 Thread Dan Mashal

On Tue, Jan 29, 2013 at 7:28 AM, Kevin Fenzi ke...@scrye.com wrote:
 On Mon, 28 Jan 2013 22:52:28 -0800
 Dan Mashal dan.mas...@gmail.com wrote:

 On Mon, Jan 28, 2013 at 4:57 PM, Adam Williamson
 awill...@redhat.com wrote:

 ...snip...

 
  I note this feature doesn't seem to incorporate adding a MATE spin
  - is a separate feature page proposed for that, or is it considered
  parallel to the feature process? Thanks.


 Parallel. Will be submitted to the spins sig. Waiting to see what
 happens with ansible and formulas. Currently there is no defined
 deadline for spins.

 There will not be anything with formulas ready in the f19 cycle I don't
 think, or if there is, it will be a tech preview type of thing. Also,
 formulas don't handle all the use cases for desktop spins at least.

 Please submit your ks asap if you intend to add a mate spin in f19. See
 the spins-sig list. Christoph is going to try and get the current
 process more usable with trac ticketing, etc.

 Spins very much definitely need to be submitted early.

 http://fedoraproject.org/wiki/Spins_Process#Timeline

 kevin

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

Thank you Kevin.

MATE 1.6 + Compiz spin submitted last night.

https://fedoraproject.org/wiki/MATE_%2B_Compiz_Spin

Live image available for testing here:

http://bitchx.ca/Image-FedoraMateCompiz.iso

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

Re: Proposed F19 Feature: MATE Desktop 1.6

On Wed, 30 Jan 2013 11:21:15 -0800
Dan Mashal dan.mas...@gmail.com wrote:

 Thank you Kevin.
 
 MATE 1.6 + Compiz spin submitted last night.
 
 https://fedoraproject.org/wiki/MATE_%2B_Compiz_Spin
 
 Live image available for testing here:
 
 http://bitchx.ca/Image-FedoraMateCompiz.iso
 
 Have at it.

Can you please mail this to the spins-sig list and make sure they know
it's submitted, etc?

thanks, 

kevin


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

Re: Proposed F19 Feature: CUPS 1.6

2013-01-30 Thread Benjamin De Kosnik


Thanks!

  3) in how to test there is no mention of print quality
  regressions. I'm concerned that in the effort to sync with cups-1.6
  and upstream, mostly just the mechanics of finding a printer and
  getting a page out are being tested.
 
  This is just scratching the surface. How are you going to evaluate
  quality? I'm concerned about the rasterization changes, the filter
  changes. Hopefully 1.6 may solve some of the image-quality
  regressions I've been seeing.  
 
 'How to test' needs to be enhanced, yes.
 
  4) In the past, I've found it difficult to debug cups filters step
  by step. Especially with so many rasterization/filter changes. As
  part of the move to 1.6, will things like:
  http://fedoraproject.org/wiki/How_to_debug_printing_problems
  be updated?  
 
 These instructions are still valid with cups-1.6  cups-filters.
 
  I would love it if issues like what driver am I using
  could be re-integrated into the UI, or perhaps an admin level of the
  ui. Also, what filters did I run to get to this point of output
  in a log file.  
 
 What UI do you have in mind ? system-config-printer ?

No. I find system-config-printer cannot correctly render or otherwise
limits many parts of these more complicated drivers. YMMV.

I always end up going to the current cups
universal interface, ie localhost:631.

Say for print quality, I would check output against the following print
queues.

- whatever default thing Fedora suggests
- whatever additional thing suggested via additional FOSS filters
- stock pdfraster via ghostscript/cairo
- espr raster (compat with Apple output)

My questions, rephrased are:

1. How do I set this up on the GUI? How do I set this up on the TUI? Do
the GUI/TUI/WebUI's sync?
2. If I have a test file, and want to print it on all the above
configs on the same printer in the same setup to test quality, how do
I do it?  (Or any multi-config setup) How do I log the filter steps so
I can pinpoint quality errors? What components do I pay attention to,
what versions and interactions are important?

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

[Bug 906095] New: perl-IO-Compress confusion

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=906095

Bug ID: 906095
   Summary: perl-IO-Compress confusion
   Product: Fedora
   Version: 18
 Component: perl
  Severity: unspecified
  Priority: unspecified
  Reporter: mic...@harddata.com

Description of problem:

perl comes with perl-IO-Compress.arch module (after current updates this is
perl-IO-Compress-2.048-237.fc18) and IO::Compress wrapper for modules
summary. 
Nothing wrong with that except that in a distro there is also
perl-IO-Compress-2.058-1.fc18.noarch, dated Tue 13 Nov 2012 which says:

The following modules used to be distributed separately, but are now
included with the IO-Compress distribution:
* Compress-Zlib
* IO-Compress-Zlib
* IO-Compress-Bzip2
* IO-Compress-Base

Due to versions the later is currently installed but quite possibly this
ordering may flip in the future.  So which of these should be there?  It is
not likely that a presence of all variations was really intended.

Version-Release number of selected component (if applicable):
perl-5.16.2-237.fc18
perl-IO-Compress-2.058-1.fc18

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=9ePLq2BT7ya=cc_unsubscribe
--
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: MATE Desktop 1.6

2013-01-30 Thread Dan Mashal

On Wed, Jan 30, 2013 at 11:34 AM, Kevin Fenzi ke...@scrye.com wrote:
 On Wed, 30 Jan 2013 11:21:15 -0800
 Dan Mashal dan.mas...@gmail.com wrote:

 Thank you Kevin.

 MATE 1.6 + Compiz spin submitted last night.

 https://fedoraproject.org/wiki/MATE_%2B_Compiz_Spin

 Live image available for testing here:

 http://bitchx.ca/Image-FedoraMateCompiz.iso

 Have at it.

 Can you please mail this to the spins-sig list and make sure they know
 it's submitted, etc?

 thanks,

 kevin

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


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

Re: Proposed F19 Feature: CUPS 1.6

2013-01-30 Thread Chris Murphy


On Jan 29, 2013, at 11:10 AM, Benjamin De Kosnik b...@redhat.com wrote:
 
 This is just scratching the surface. How are you going to evaluate
 quality? I'm concerned about the rasterization changes, the filter
 changes. Hopefully 1.6 may solve some of the image-quality regressions
 I've been seeing. 

Quality evaluation needs test targets/documents, and eyeballs. Many test 
targets are free or easily produced and could be CC0 licensed or something 
reasonable. This is something I've briefly discussed with Richard Hughes, and 
also participants in OpenICC, that are needed not just for print, but also for 
display. Perhaps some OpenICC and OpenPrinting collaboration is appropriate for 
acquiring test metrics.

Since CUPS itself doesn't rasterize, I don't expect you'd see changes in this 
area; but if there are filter changes, or an application decides to produce PDF 
job instead of PostScript, then it's possible, but probably not intended. If 
there are features or effects that need to be performed on a job after the 
application has produced the job, there are advantages to doing this on PDF 
than PostScript. But my expectation is even applications that today still use 
PostScript, they would be subject to the pstopdf filter, which in turn defers 
to Ghostscript on linux (Quartz2D by default on OS X) to turn it into a PDF. 
Such normalization of postscript to pdf is something that's been going on for 
many years, and is well tested (with many bug carcasses  along the way).

 
 4) In the past, I've found it difficult to debug cups filters step by
 step. Especially with so many rasterization/filter changes.

Yes this is tedious. Figuring out the sequence for a job isn't so difficult. 
But in case of problems, it would be useful to break the sequence, i.e. get 
access to the print job in a particular state in between filters. I've got some 
material on how to do this, for the purposes of troubleshooting the OS X print 
pipeline which of course uses CUPS, but different print drivers, raster engine, 
and color management philosophy.


 be updated? I would love it if issues like what driver am I using
 could be re-integrated into the UI, or perhaps an admin level of the
 ui. Also, what filters did I run to get to this point of output in a
 log file.

This is useful. At least on OS X each PDF print job also has a job ticket. I 
think this is a CUPS thing. Even once the job is complete, and the original 
document and raster files are deleted, the job ticket remains and it should 
contain all of this information. Making it more readable somehow might be 
useful.

 
 5) integration with common printing dialog. (IMHO localhost:631). 
 I think integrating Fedora's print dialogs with the wider user
 communities on macos and ubuntu would be very useful.

I'm not sure what common printing dialog refers to here. If it's the CPD, 
that's dead as far as I know, unless it's been raised in the last 2 months.

As for using Mac OS as a model for print dialogs, I'm happy to discuss exactly 
what areas I think this is useful and areas it's to be avoided. OS X for 
professional printing is nothing short of a clusterf|ck. It has been a huge 
PITA for me for ~8 years. Central to this problem is color, but also rather 
significantly is the UI/UX. We get *two* print dialogs for every print job with 
such applications due to lack of integration between the OS dialog and the 
application dialog. So we get an application dialog, and then later get an OS 
dialog, and they each contain mutually exclusive features, or settings that 
conflict between application and the OS. And the arbitration and assumption for 
this is not great, and not well documented. And this is aside from the separate 
interactions that occur with the print driver which does integrate with the OS 
dialog, but can itself have settings that conflict with the OS, or the 
application.

The UI/UX part isn't much different on Windows, but the color management 
ideology is, and that actually helps rather significantly for those who 
actually care about such things. So the hopeful idea is to mimic the successes 
of these companies, and avoid the mistakes. Should be easy. Ha!

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

Re: Proposed F19 Feature: Developers Assistant

Jan Zelený (jzel...@redhat.com) said: 
 I've already started to work on that as well. Currently I'm putting together 
 topics from Fedora wiki that are eligible to be on such page, either as they 
 are or with some (rather minor) modifications.
 
 I'd like them to be structured, easy to comprehend and most importantly as 
 short as possible.
 
 If you know any such topic, feel free to let me know.

Does this go all the way into libraries you should use and libraries you
shouldn't?

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

Summary/Minutes for today's FESCo Meeting (2013-01-30)

2013-01-30 Thread Marcela Mašláňová



Title: #fedora-meeting: FESCO (2013-01-30)





#fedora-meeting: FESCO (2013-01-30)

Meeting started by mmaslano at 18:01:17 UTC
(full logs).





Meeting summary

init process (mmaslano, 18:01:39)

#1001 F19 Feature: JRuby 1.7 - https://fedoraproject.org/wiki/Features/JRuby_1.7 (mmaslano, 18:03:40)

  AGREED: JRuby 1.7 is
F19 feature if FPC acks it (+7,-0) (mmaslano,
18:05:53)


#1002 F19 Feature: Ruby 2.0.0 - https://fedoraproject.org/wiki/Features/Ruby_2.0.0 (mmaslano, 18:05:58)

  AGREED: Ruby 2.0 is
F19 feature if FPC acks it (+7,-0) (mmaslano,
18:07:45)


#1004 Mass rebuild schedule (mmaslano, 18:08:05)

#1006 F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB (mmaslano, 18:12:27)

#1025 En bloc features for January 30 (mmaslano, 18:20:00)

  AGREED: All features
from #1025 will be accepted as F19 features execpt
FirstClassCloudImages and SharedSystemCertificates which shall be
discussed separately (+9,0) (mmaslano,
18:21:48)


#1008 F19 Feature: First-Class Cloud Images -  https://fedoraproject.org/wiki/Features/FirstClassCloudImages (mmaslano, 18:22:09)

  AGREED: defer to next
week, more discussion with other relengs needed (+6,-0) (mmaslano,
18:39:08)


#1019 F19 Feature: Shared System Certificates - https://fedoraproject.org/wiki/Features/SharedSystemCertificates (mmaslano, 18:39:47)

  AGREED: Shared System
Certificates are F19 feature (+8,-0, 1 abstain) (mmaslano,
18:51:03)


#1006 F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB (mmaslano, 18:52:11)

  http://markmail.org/message/q5fk6lxlniq2p6gz?q=python#query:python+page:1+mid:oybas2zmjrpo2hap+state:results
(mattdm,
18:54:48)
  http://lists.fedoraproject.org/pipermail/devel/2013-January/176635.html
(abadger1999,
19:04:10)
  AGREED: Replace MySQL
with MariaDB is F19 feature (+7,-0) (mmaslano,
19:12:26)


#1006 F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB (mmaslano, 19:13:46)

  AGREED: Feature
accepted as proposed (including obsoletion as a transition
mechanism).  If new MySQL maintainers appear, feature owners are
asked to make it possible to install the MySQL stand-alone server
(only) (+7,-0) (mmaslano,
19:15:29)


#1007 F19 Feature: Checkpoint/Restore - https://fedoraproject.org/wiki/Features/Checkpoint_Restore (mmaslano, 19:16:08)

  AGREED: Checkpoint/Restore is F19 feature (+9,-0)
(mmaslano,
19:18:15)


#1009 F19 Feature: Fedora Upgrade - https://fedoraproject.org/wiki/Features/FedoraUpgrade (mmaslano, 19:19:19)

  ACTION: sgallagh to
ask fedora-upgrade maintainers to consider renaming to avoid
confusion (nirik,
19:28:24)
  ACTION: sgallagh will
speak with Board about formalizing a request process for adding
packages with fedora in their name (mmaslano,
19:28:24)
  AGREED: Fedora
Upgrade feature is rejected (+0,-7) (mmaslano,
19:31:44)


#1022 F19 Feature: systemd/udev Predictable Network Interface Names - https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames (mmaslano, 19:33:42)

  AGREED: systemd/udev
Predictable Network Interface Names are accepted as F19 feature
(+7,-0) (mmaslano,
19:46:30)
  AGREED: systemd/udev
Predictable Network Interface Names - upgrades shouldn't change
naming (+5,-0) (mmaslano,
19:46:59)
  AGREED: eno=em
tweak is required (+5, -1) (mmaslano,
19:57:08)


#1024 F19 Feature: MEMSTOMP - https://fedoraproject.org/wiki/Features/MEMSTOMP (mmaslano, 19:57:17)

  AGREED: MEMSTOMP is
F19 feature (+7,-0) (mmaslano,
19:58:43)


#1004 Mass rebuild schedule (mmaslano, 19:58:52)

  AGREED: mass rebuild
on 8th (+6,-0) (mmaslano,
20:03:38)


Next week's chair (mmaslano, 20:05:50)

  ACTION: nirik will
chair next meeting (mmaslano,
20:06:20)


Open Floor (mmaslano, 20:06:28)

  ACTION: jreznik will
propose schedule (mmaslano,
20:06:38)
  SB: pjones will to SWG and try to get
clarification that expiration cannot be honored. (mmaslano,
20:15:13)
  SB: pjones will got to USWG and try to get
clarification that expiration cannot be honored. (mmaslano,
20:15:38)
  AGREED: nodejs
guideliens were approved contingent on a fesco multilib exemption,
odejs wants to install and find modules in one path under /usr/lib
rather than %{_libdir} which may be /usr/lib64 (+6,-0) (mmaslano,
20:21:18)
  http://lists.fedoraproject.org/pipermail/devel/2013-January/176796.html
(abadger1999,
20:41:01)
  AGREED: rubypick will
be implemented as proposed by domain experts in JRuby feature
(+5,-0) (mmaslano,
20:53:07)








Meeting ended at 20:54:15 UTC
(full logs).





Action items

  sgallagh to ask fedora-upgrade maintainers to consider renaming to avoid confusion
  sgallagh will speak with Board about

ARM arches in F19 and forward.

2013-01-30 Thread Dennis Gilmore

Hi all,

This is just a note for a wider audience. the Fedora ARM has dropped
support for software floating point going forward,  we will only be
building hardware floating point binaries from Fedora 19 on.  it was
discussed at FUDCon and on the arm list the FUDCon notes
https://fedoraproject.org/wiki/Architectures/ARM/Meetings/FUDCon_Lawrence_2013#Future
show that we were going to look at having F19 be the last softfp
supporting release after further thought and discussion we are dropping
from F19 and F18 will be the last release supporting sfp so those with
sfp only devices, which the only supported ones are kirkwood based
devices like the guruplug will get software support for about 1 year
more.

The Raspberry Pi will be supported by the efforts at Seneca College
with armv6hl it will support hardware floating point. 

Longer term we will start to support aarch64 

Regards

Dennis
___
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: Dracut HostOnly

On Tue, Jan 29, 2013 at 4:53 PM, Dennis Gilmore den...@ausil.us wrote:
 even loading a 20mb initramfs from a sdcard on a slow
 arm box doesnt take that long, and id personally much rather be able to
 change hardware or yank the drive  and put it into a different box
 without worrying about making sure i have the right initramfs bits in
 place. at least to me the costs outweigh the benefits. the grub timeout
 on my laptop/desktops is longer than the time it takes to load the
 initramfs.

This actually suggests a different way to achieve the same result:
Teach grub to preload the kernel and initrd while waiting for the
timeout.  That gives us _even better_ speedup, and doesn't sacrifice
the generic usability of the initrd.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F19: system-config-kickstart

2013-01-30 Thread Gene Czarcinski


On 01/30/2013 11:10 AM, Kevin Fenzi wrote:

On Wed, 30 Jan 2013 11:00:31 -0500
Gene Czarcinski g...@czarc.net wrote:


Much is made of the great new anaconda introduced in Fedora 18. But,
this great new anaconda completely broke system-config-kickstart
because old-anaconda code used but s-c-k disappeared.

Obviously there was little or no testing of s-c-k or perhaps nobody
uses it and/or nobody cares.
https://bugzilla.redhat.com/show_bug.cgi?id=859928

Perhaps there needs to be a F19 Feature which either fixes it or
eliminates this package.  The current situation is just plain
ridiculous.

...snip...

https://fedoraproject.org/wiki/Features/AnacondaNewUI_Followup

...
 * Make system-config-kickstart work again. The removal of
iw/GroupSelector.py from anaconda caused it to break. (#859928)
...



Good!  Thank you.

Here is some unsolicited suggestions.

I only became interested in kickstart when I felt that the Fedora 18 
installer was not meeting my needs.  This was especially true installing 
(and re-installing) test configurations into virtual systems.  Taking a 
look at s-c-k under Fedora 17, I believe that it mostly has the right 
options.


Two areas that should be expanded beyond what is available in the 
anaconda gui:


1.  File systems (and especially btrfs) and how things are configured.

2. Software selection ... more like what is available with yumex and the 
add/remove software application.


Then again, at this point I just might stick with the old standard unix 
tool for configuration files: a text editor.


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

Re: Summary/Minutes for today's FESCo Meeting (2013-01-30)

2013-01-30 Thread Marcela Mašláňová

I realized I sent the wrong (html) minutes. Therefore, these minutes are 
for those who ignore html emails.


===
#fedora-meeting: FESCO (2013-01-30)
===


Meeting started by mmaslano at 18:01:17 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-01-30/fesco.2013-01-30-18.01.log.html
.



Meeting summary
---
* init process  (mmaslano, 18:01:39)

* #1001 F19 Feature: JRuby 1.7 -
  https://fedoraproject.org/wiki/Features/JRuby_1.7  (mmaslano,
  18:03:40)
  * AGREED: JRuby 1.7 is F19 feature if FPC acks it (+7,-0)  (mmaslano,
18:05:53)

* #1002 F19 Feature: Ruby 2.0.0 -
  https://fedoraproject.org/wiki/Features/Ruby_2.0.0  (mmaslano,
  18:05:58)
  * AGREED: Ruby 2.0 is F19 feature if FPC acks it (+7,-0)  (mmaslano,
18:07:45)

* #1004 Mass rebuild schedule  (mmaslano, 18:08:05)

* #1006 F19 Feature: Replace MySQL with MariaDB -
  https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB
  (mmaslano, 18:12:27)

* #1025 En bloc features for January 30  (mmaslano, 18:20:00)
  * AGREED: All features from #1025 will be accepted as F19 features
execpt FirstClassCloudImages and SharedSystemCertificates which
shall be discussed separately (+9,0)  (mmaslano, 18:21:48)

* #1008 F19 Feature: First-Class Cloud Images -
  https://fedoraproject.org/wiki/Features/FirstClassCloudImages
  (mmaslano, 18:22:09)
  * AGREED: defer to next week, more discussion with other relengs
needed (+6,-0)  (mmaslano, 18:39:08)

* #1019 F19 Feature: Shared System Certificates -
  https://fedoraproject.org/wiki/Features/SharedSystemCertificates
  (mmaslano, 18:39:47)
  * AGREED: Shared System Certificates are F19 feature (+8,-0, 1
abstain)  (mmaslano, 18:51:03)

* #1006 F19 Feature: Replace MySQL with MariaDB -
  https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB
  (mmaslano, 18:52:11)
  * LINK:

http://markmail.org/message/q5fk6lxlniq2p6gz?q=python#query:python+page:1+mid:oybas2zmjrpo2hap+state:results
(mattdm, 18:54:48)
  * LINK:
http://lists.fedoraproject.org/pipermail/devel/2013-January/176635.html
(abadger1999, 19:04:10)
  * AGREED: Replace MySQL with MariaDB is F19 feature (+7,-0)
(mmaslano, 19:12:26)

* #1006 F19 Feature: Replace MySQL with MariaDB -
  https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB
  (mmaslano, 19:13:46)
  * AGREED: Feature accepted as proposed (including obsoletion as a
transition mechanism).  If new MySQL maintainers appear, feature
owners are asked to make it possible to install the MySQL
stand-alone server (only) (+7,-0)  (mmaslano, 19:15:29)

* #1007 F19 Feature: Checkpoint/Restore -
  https://fedoraproject.org/wiki/Features/Checkpoint_Restore  (mmaslano,
  19:16:08)
  * AGREED: Checkpoint/Restore is F19 feature (+9,-0)  (mmaslano,
19:18:15)

* #1009 F19 Feature: Fedora Upgrade -
  https://fedoraproject.org/wiki/Features/FedoraUpgrade  (mmaslano,
  19:19:19)
  * ACTION: sgallagh to ask fedora-upgrade maintainers to consider
renaming to avoid confusion  (nirik, 19:28:24)
  * ACTION: sgallagh will speak with Board about formalizing a request
process for adding packages with fedora in their name  (mmaslano,
19:28:24)
  * AGREED: Fedora Upgrade feature is rejected (+0,-7)  (mmaslano,
19:31:44)

* #1022 F19 Feature: systemd/udev Predictable Network Interface Names -

https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
  (mmaslano, 19:33:42)
  * AGREED: systemd/udev Predictable Network Interface Names are
accepted as F19 feature (+7,-0)  (mmaslano, 19:46:30)
  * AGREED: systemd/udev Predictable Network Interface Names - upgrades
shouldn't change naming (+5,-0)  (mmaslano, 19:46:59)
  * AGREED: eno=em tweak is required (+5, -1)  (mmaslano, 19:57:08)

* #1024 F19 Feature: MEMSTOMP -
  https://fedoraproject.org/wiki/Features/MEMSTOMP  (mmaslano, 19:57:17)
  * AGREED: MEMSTOMP is F19 feature (+7,-0)  (mmaslano, 19:58:43)

* #1004 Mass rebuild schedule  (mmaslano, 19:58:52)
  * AGREED: mass rebuild on 8th (+6,-0)  (mmaslano, 20:03:38)

* Next week's chair  (mmaslano, 20:05:50)
  * ACTION: nirik will chair next meeting  (mmaslano, 20:06:20)

* Open Floor  (mmaslano, 20:06:28)
  * ACTION: jreznik will propose schedule  (mmaslano, 20:06:38)
  * SB: pjones will to SWG and try to get clarification that expiration
cannot be honored.  (mmaslano, 20:15:13)
  * SB: pjones will got to USWG and try to get clarification that
expiration cannot be honored.  (mmaslano, 20:15:38)
  * AGREED: nodejs guideliens were approved contingent on a fesco
multilib exemption, odejs wants to install and find modules in one
path under /usr/lib rather than %{_libdir} which may be /usr/lib64
(+6,-0)  (mmaslano, 20:21:18)
  * LINK:
http://lists.fedoraproject.org/pipermail/devel/2013-January/176796.html
(abadger1999, 20:41:01)
  * AGREED: rubypick will be implemented as proposed

[389-devel] please review: Ticket 497 - Console logins fail intermittently (adminutil)

2013-01-30 Thread Mark Reynolds


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

https://fedorahosted.org/389/attachment/ticket/479/0001-Ticket-497-Console-logins-fail-intermittenly.patch

--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-01-30 Thread TK009

On Wed, Jan 30, 2013 at 1:28 PM, Máirín Duffy du...@fedoraproject.org wrote:

 But every release is not a decision point, which desktop will we make
 default this time?

I believe it is a point where review where are we are, and where we
would like to be, now and in the future.

 Certainly it is *not* a given or granted that any
 given software project we have as an upstream has done *any* usability
 or user experience research whatsoever, so in that aspect GNOME is
 pretty rare.

From where I sit, I am not convinced the Gnome team did any of that
either beyond lip service. 6 versions to return shutdown speaks for
itself.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Replace MySQL with MariaDB

2013-01-30 Thread Naheem Zaffar

On 30 January 2013 04:24, James Hogarth james.hoga...@gmail.com wrote:

  Second, if mariadb differs more in the future and stops to be drop-in
 replacement, then we'll need an alternative for applications, where mariadb
 won't be suitable enough. Nevertheless, this is not a current issue right
 now.
 

 Indeed this is a straw man effectively.

 Is it?

http://blog.mariadb.org/explanation-on-mariadb-10-0/ and
http://blog.mariadb.org/mariadb-10-0-and-mysql-5-6/ seem to suggest that
MariaDB will no longer be following Mysql as religiously as the feature
suggests
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 906095] perl-IO-Compress confusion

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=906095

Paul Howarth p...@city-fan.org changed:

   What|Removed |Added

 CC||p...@city-fan.org

--- Comment #1 from Paul Howarth p...@city-fan.org ---
It's OK for both to be there; yum will just pick the latest.

It's much the same situation as in Bug 620937#c4

Arguably the perl-IO-Compress package built from the main perl package should
be noarch, like the independent one though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=BQxvUNbjlWa=cc_unsubscribe
--
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

using rpms for non-root installs

2013-01-30 Thread Mátyás Selmeci


  
  
Hi,

This may be a long shot, but I am interested in repackaging some
RPMs (for example, some of the Globus packages in EPEL, as well as
grid software that my group builds) such that the software in them
may be installed by unprivileged users, or into a non-standard
location such as an NFS share. I'd like to use existing RPMs,
preferably binaries, as a starting point to avoid duplicating work.
(Naturally a lot of post-install scripting would be needed to fix
binaries such that they'd work with the path they were installed
into).

Have there been any projects with this goal in mind?
Have any of you had experience with this sort of thing and have
tips, tools, etc. that might help me out in this?

Thanks in advance,
-Mat
-- 
  -Matyas Selmeci
  Open Science Grid Software Team
  Center for High Throughput Computing
  University of Wisconsin-Madison 
  




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly