date:20140403

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Scriptalicious-1.17-1.
   ||fc21



-- 
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=BdpW4XNO4Na=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: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)

2014-04-03 Thread Miroslav Suchý

On 04/03/2014 03:46 AM, Toshio Kuratomi wrote:

I saw that this got voted on in the meeting even though it didn't get
recorded as such for the meeting minutes. The proposal seemed to be:
use obs-sign to sign packages. That's not actually a proposal that we
can approve here. The proposal here should probably be: is signing
of packages a blocker for making the playground repo, nice to have, or
optional?

In terms of how to get the packages signed, that's something that the
infrastructure team has to decide. IIRC past conversations correctly,
adding another signing server (meaning a different code base) to
infrastructure is at the bottom of their list of ways to sign packages
in copr (and by extension in the playground repo).

When I saw the vote in the meeting logs I mentioned it to nirik. In
turn he told me that he hadn't heard anything about this and had only
glanced briefly at obs-sign (mentioning that it wasn't even packaged
for Fedora yet). As I related to tjanez on IRC today, I think lack of
packaging probably slows down infra's ability to deploy it but is only
a foottnote to the real problems. Compromising signing servers and
gaining access to the private keys on them is a very high value target
for an attacker. The more signing servers we have the greater the
attack surface infrastructure has to protect. probably in the ideal
scenario infra would run a single signing server and everything
needing signing would be sent to that. (Jesse Kating had that use in
mind when he designed sigul but I don't know if that design goal
actually became part of the software that we are currently running).
A step down from there might be running multiple instances of the same
signing software to handle the various needs as infra would then have
to protect the keys on these multiple hosts. At the bottom of the
list is running separate signing software as that places the
additional burden of auditing and protecting the software stack of the
multiple signing servers.

For whoever is going to approach infra about signing the packages in
copr it probably makes more sense to either talk about enhancing sigul
to work with copr or getting obs-sign to be able to sign packages from
koji. We'd probably also want to ask bressers or someone else from
the security team to do some sort of evaluation of the code bases that
we're looking at.

That would be probably me. I mean the guy who will be implementing signing of
packages in Copr.

I investigated several possibilities and talked to several people. But you are correct that I did not send conclusion to
mailing list yet. Maybe it is right time to do it now.

* we would need to do some development of Sigul before deploying new instance
* and we would likely should migrate to gpg2 (from gpg1)
* Sigul have very restricted network setup, which is probably not needed for
Copr

On the other hand obs-sign:
* is actively maintained
* is more simple
* used in OBS as well (which mean community and so on)
* have security model and network setup good enough for Copr (I arranged meeting of Adrian Shröter from OBS and Mirek
Trmač during DevConf.cz where they discussed technical details and none of them seen any blocker).

Yes, obs-sign is not packaged for Fedora (yet), but the spec exists and I can get it in Fedora withing week. I do not
see that as problem.

If I sum it up, then obs-sign is clear winner to me. Therefore this is the way
I would like to go in Copr.

But it still does not bubble up in my TODO list. So we have plenty of time for
discussion :)

(*) You suggested that having one signing server is better as The more signing
servers we have the greater the
attack surface infrastructure has to protect. I disagree.
First: it is not technical possible. Because Koji and current Sigul is in different networks and I'm not sure if we want
to change it. Likely not.
Second: if you compromise Copr signing server then you have compromised main distribution. Therefore even from security
POV is better to have different signing server for main distribution and for Copr.

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-03 Thread Simo Sorce

On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote:
 On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote:
  How does someone express strong disagreement to this change ?
 
 Posting here is a good start. You can also add a note in the FESCo ticket
 for approval once one is filed, and if you are incredibly passionate you can
 come to the FESCo meeting (although I'm hoping we can make those meetings
 more efficient, so that's not a good place for back and forth -- if possible
 we should work out the issues before the meeting).

Ticket number ?

  This change makes it very hard to do necessary maintenance. I can
  understand blocking SSH login as root with password by default, but I do
  not understand what is the point of blocking console login as root.
 
 I assume that it's for a kiosk or public (or at least managed) lab
 situation. It makes sense for that, but I'm not convinced of a benefit
 otherwise, and I don't think that situation is the default

I am not even sure it makes sense in a kiosk, unless people want to use
password as their root password. But even if it made sense in that
situation it is far from being a useful *default*. This kind of severely
restricting measure is best left to hardening manuals.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)

2014-04-03 Thread Marcela Mašláňová

On 04/03/2014 02:29 PM, Miroslav Suchý wrote:

On 04/03/2014 03:46 AM, Toshio Kuratomi wrote:

That would be probably me. I mean the guy who will be implementing
signing of packages in Copr.

I investigated several possibilities and talked to several people. But
you are correct that I did not send conclusion to mailing list yet.
Maybe it is right time to do it now.

One of the guy to who I talked to is Miroslav Trmac, who is current
maintainer and main author of Sigul since 2009.
The conclusion from discussion with him is that:
* we would need need different instance, because to use the same
instance for main distribution and for relaxed ring (Copr,
Playground...) is not best idea. Neither from security POV nor for
technical implementation. (*)
* we would need to do some development of Sigul before deploying new
instance
* and we would likely should migrate to gpg2 (from gpg1)
* Sigul have very restricted network setup, which is probably not needed
for Copr

On the other hand obs-sign:
* is actively maintained
* is more simple
* used in OBS as well (which mean community and so on)
* have security model and network setup good enough for Copr (I arranged
meeting of Adrian Shröter from OBS and Mirek Trmač during DevConf.cz
where they discussed technical details and none of them seen any blocker).

Yes, obs-sign is not packaged for Fedora (yet), but the spec exists and
I can get it in Fedora withing week. I do not see that as problem.

If I sum it up, then obs-sign is clear winner to me. Therefore this is
the way I would like to go in Copr.

But it still does not bubble up in my TODO list. So we have plenty of
time for discussion :)

(*) You suggested that having one signing server is better as The more
signing servers we have the greater the
attack surface infrastructure has to protect. I disagree.
First: it is not technical possible. Because Koji and current Sigul is
in different networks and I'm not sure if we want to change it. Likely not.
Second: if you compromise Copr signing server then you have compromised
main distribution. Therefore even from security POV is better to have
different signing server for main distribution and for Copr.

The summary of Mirek's notes was for a long time in Open Questions
section [1]. I removed it yesterday, because it was voted for obs-signd.
Mirek is member of infra, so I leave the discussion up to him.

[1]
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#Open_Questions

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

Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard

2014-04-03 6:09 GMT+02:00 Peter Hutterer peter.hutte...@who-t.net:

 This _will_ break some setups. If you have AutoAddDevices off in your
 xorg.conf then this will break. The main question to ask here is: do these
 setups still exist and if so why do you have that option set and can we fix
 the reason for it being set in the first place?


Would it be at all possible to write a %post script that modifies the
configs to keep users' systems working?  I suspect the answer is no but
it's still worth asking.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging of libdb-6+

2014-04-03 Thread Honza Horak


On 04/03/2014 11:20 AM, H. Guémar wrote:

Since AGPL is fedora-compliant license, there's no blocker to get
libdb6 into packages collection.
Besides, libdb5 is still critical for many packages (like RM), until
we get rid of it, I can only agree with your proposal.

Maybe, it's still time to rename the current libdb = libdb5 and get
newer releases named libdb starting F21


This would be possible only by co-operation with the depended packages, 
since they usually use BuildRequire: libdb-devel. So after just 
rebuilding those to link against libdb-6, some of the packages would 
start to suffer from license incompatibilities. But I agree that 
libdb-6.x + libdb5-5.x scenario looks better than libdb-5.x + libdb6-6.x.


Anyway, to make some marketing for this change, we should have a Self 
contained change page for this [1]. Change Proposals Submission Deadline 
is 2014-04-08 btw.


[1] http://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes

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

Re: F21 System Wide Change: RPM-4.12

2014-04-03 Thread Mikolaj Izdebski

On 04/02/2014 07:47 PM, Jaroslav Reznik wrote:
 * Support for weak dependencies

Does this mean that rpm-build will be able to create packages with weak
dependencies?  Will Fedora packages be allowed to declare weak
dependencies?  Is dependency generator interface going to be extended so
that we can generate auto-recommends and auto-suggests for packages?

 * Support for packaging files  4GB
 * Support for real package reinstallation
 * New API for accessing files and file contents
 * New tool for converting rpm packages to tar files
 * Internal plugin interface

Are there any details abuout this interface available somewhere?  Will
packages be able to provide plugins, like for example they can install
RPM macros now?

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard

2014-04-03 Thread Adam Jackson

On Thu, 2014-04-03 at 16:35 +1000, Peter Hutterer wrote:

 If fixes the problem but that doesn't tell the whole story. You have a conf
 that implicitly says load the mouse driver and then fails because you
 didn't have the mouse driver installed. Which is fair enough, the question
 here is why is that setting there in the first place? Is the goal to not add
 any devices, or is this just an accidental leftover?

I think the goal _is_ to not add any devices, yes.  Bumblebee is
basically a second X server to run on the nvidia gpu and pipe the pixels
off that to the integrated gpu.  So input only ever happens on the
integrated gpu's server, so you want to keep the bumblebee server away
from event devices.  (I think; I've never actually run it.)

- ajax

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

Re: GnuTLS issue (Mandos Server/Client)

2014-04-03 Thread Nikos Mavrogiannopoulos

On Wed, 2014-04-02 at 10:50 -0600, Nathanael D. Noblet wrote:
 CentOS 6 = gnutls 2.8.5
 F20  = gnutls 3.1.20
 The server is a python app and sets the priority string as follows:
 priority=SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP
 this is fed to some gnutls function somewhere in the stack.

Does it really use TLS with openpgp certificates? If yes, I doubt you
could make 2.8.5 interoperate with gnutls 3.1.20. GnuTLS was modified in
3.1.x to adhere with RFC6091 which was incompatible the previous attempt
to have openpgp keys to TLS.

regards,
Nikos


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

[Bug 1084058] New: perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21 FTBFS

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

Bug ID: 1084058
   Summary: perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21
FTBFS
   Product: Fedora
   Version: rawhide
 Component: perl-MooseX-Types-DateTime-MoreCoercions
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com



perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21 fails to build in F21:

Provádění(%build): /bin/sh -e /var/tmp/rpm-tmp.miIpx2
+ umask 022
+ cd /builddir/build/BUILD
+ cd MooseX-Types-DateTime-MoreCoercions-0.11
+ perl Makefile.PL INSTALLDIRS=vendor
include
/builddir/build/BUILD/MooseX-Types-DateTime-MoreCoercions-0.11/inc/Module/Install.pm
include inc/Module/Install/Metadata.pm
include inc/Module/Install/Base.pm
include inc/Module/Install/Makefile.pm
include inc/Module/Install/AutoInstall.pm
include inc/Module/Install/Include.pm
include inc/Module/AutoInstall.pm
*** Module::AutoInstall version 1.06
*** Checking for Perl dependencies...
[Core Features]
- Test::use::ok   ...loaded. (0.11 = 0.02)
- Test::Exception ...loaded. (0.32 = 0.27)
- Test::More  ...loaded. (1.001003)
- Moose   ...loaded. (2.1005 = 0.41)
- MooseX::Types   ...loaded. (0.35 = 0.04)
- namespace::clean...loaded. (0.25 = 0.08)
- Time::Duration::Parse   ...loaded. (0.11 = 0.06)
- MooseX::Types::Moose...loaded. (0.35 = 0.04)
- MooseX::Types::DateTime ...loaded. (0.08 = 0.07)
- DateTime...loaded. (1.08 = 0.4302)
- DateTime::Duration  ...loaded. (1.08 = 0.4302)
- DateTimeX::Easy ...loaded. (0.089 = 0.085)
*** Module::AutoInstall configuration finished.
include inc/Module/Install/WriteAll.pm
include inc/Module/Install/Win32.pm
include inc/Module/Install/Can.pm
include inc/Module/Install/Fetch.pm
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for MooseX::Types::DateTime::MoreCoercions
Writing MYMETA.yml and MYMETA.json
Error reading from file 'META.yml': utf8 \xE5 does not map to Unicode
 at /usr/share/perl5/vendor_perl/Module/Install/Admin/Metadata.pm line 14.

The META.yml file is not in Unicode and unbundled modules in F21 are stricter
and bail out.

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

Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Matthias Clasen

Hey,

so the time has come to consider this - thanks to the great work of
Richard and Kalev on the copr, we have a set of 3.12 packages that have
already received fairly wide testing.

But we should be careful, so I want to ask for concrete problem reports
with the copr packages, besides dependency problems caused by the
parallel nature of the copr itself.

Did any of your gnome-shell extensions break ?

Did you experience crashes or other serious problems with applications ?

If so, please let us know on the desktop list. If I don't hear of major
problems by next week, I'll file a Fesco ticket to ask for an exception.


Matthias

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

[Bug 1084058] perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21 FTBFS

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-MooseX-Types-DateTime-
   ||MoreCoercions-0.11-3.fc21
 Resolution|--- |RAWHIDE
Last Closed||2014-04-03 10:23:14



-- 
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=LDR8Qu0YuBa=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: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard

2014-04-03 Thread Gary Gatling

On Thu, Apr 3, 2014 at 9:58 AM, Adam Jackson a...@redhat.com wrote:

 I think the goal _is_ to not add any devices, yes.  Bumblebee is
 basically a second X server to run on the nvidia gpu and pipe the pixels
 off that to the integrated gpu.  So input only ever happens on the
 integrated gpu's server, so you want to keep the bumblebee server away
 from event devices.  (I think; I've never actually run it.)

 - ajax


Thanks a lot for the feedback.

I have asked the developers for input. I opened a issue of the github issue
tracker here:

 https://github.com/Bumblebee-Project/Bumblebee/issues/568

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

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-03 Thread quickbooks office

This change will not affect logging into the console using the local
account and then doing su to get root privileges.

Is there a problem with logging into the local user account and then
typing su and the root password?

You are as such prompted to make a local user account when doing an
install from the Live CD.


3.1.4.2.2. Disabling Root Logins

To further limit access to the root account, administrators can
disable root logins at the console by editing the /etc/securetty file.
This file lists all devices the root user is allowed to log into. If
the file does not exist at all, the root user can log in through any
communication device on the system, whether via the console or a raw
network interface. This is dangerous, because a user can log in to his
machine as root via Telnet, which transmits the password in plain text
over the network. By default, Fedora's /etc/securetty file only allows
the root user to log in at the console physically attached to the
machine. To prevent root from logging in, remove the contents of this
file by typing the following command:

echo  /etc/securetty

Warning

A blank /etc/securetty file does not prevent the root user from
logging in remotely using the OpenSSH suite of tools because the
console is not opened until after authentication. 


The change will NOT affect: Programs that do not log in as root, but
perform administrative tasks through setuid or other mechanisms...The
following programs are NOT PREVENTED from accessing the root account:
su, sudo, ssh, scp, sftp

On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce s...@redhat.com wrote:
 On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote:
 On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote:
  How does someone express strong disagreement to this change ?

 Posting here is a good start. You can also add a note in the FESCo ticket
 for approval once one is filed, and if you are incredibly passionate you can
 come to the FESCo meeting (although I'm hoping we can make those meetings
 more efficient, so that's not a good place for back and forth -- if possible
 we should work out the issues before the meeting).

 Ticket number ?

  This change makes it very hard to do necessary maintenance. I can
  understand blocking SSH login as root with password by default, but I do
  not understand what is the point of blocking console login as root.

 I assume that it's for a kiosk or public (or at least managed) lab
 situation. It makes sense for that, but I'm not convinced of a benefit
 otherwise, and I don't think that situation is the default

 I am not even sure it makes sense in a kiosk, unless people want to use
 password as their root password. But even if it made sense in that
 situation it is far from being a useful *default*. This kind of severely
 restricting measure is best left to hardening manuals.

 Simo.

 --
 Simo Sorce * Red Hat, Inc * New York

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

Re: [CHANGE PROPOSAL] The securetty file is empty by default


Am 03.04.2014 16:32, schrieb quickbooks office:
 This change will not affect logging into the console using the local
 account and then doing su to get root privileges.
 
 Is there a problem with logging into the local user account and then
 typing su and the root password?

i do *not* need a local user account on machines typically running
without any local user and *if i need to login there* i do that
*because* i need to maintain that machine as root

and that is why i *do not* have a user besides root because all
other users for cronjobs and services have no shell at all

so no, don't break useful setups with defaults



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

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-03 Thread Simo Sorce

On Thu, 2014-04-03 at 07:32 -0700, quickbooks office wrote:
 This change will not affect logging into the console using the local
 account and then doing su to get root privileges.

What local account ?

 Is there a problem with logging into the local user account and then
 typing su and the root password?

Yes, in most installation I do not have any local user, I have only
users coming via LDAP, and if the problem I need to solve is that the
LDAP part of the equation is broken I have no user to log in if root is
disabled.

 You are as such prompted to make a local user account when doing an
 install from the Live CD.

Which is not the only mean of installing, nor the main mean for me (I
never used the LiveCD for installing).

You are clearly making assumptions that do not hold for the general
case.

Simo.

 3.1.4.2.2. Disabling Root Logins
 
 To further limit access to the root account, administrators can
 disable root logins at the console by editing the /etc/securetty file.
 This file lists all devices the root user is allowed to log into. If
 the file does not exist at all, the root user can log in through any
 communication device on the system, whether via the console or a raw
 network interface. This is dangerous, because a user can log in to his
 machine as root via Telnet, which transmits the password in plain text
 over the network. By default, Fedora's /etc/securetty file only allows
 the root user to log in at the console physically attached to the
 machine. To prevent root from logging in, remove the contents of this
 file by typing the following command:
 
 echo  /etc/securetty
 
 Warning
 
 A blank /etc/securetty file does not prevent the root user from
 logging in remotely using the OpenSSH suite of tools because the
 console is not opened until after authentication. 
 
 
 The change will NOT affect: Programs that do not log in as root, but
 perform administrative tasks through setuid or other mechanisms...The
 following programs are NOT PREVENTED from accessing the root account:
 su, sudo, ssh, scp, sftp
 
 On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce s...@redhat.com wrote:
  On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote:
  On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote:
   How does someone express strong disagreement to this change ?
 
  Posting here is a good start. You can also add a note in the FESCo ticket
  for approval once one is filed, and if you are incredibly passionate you 
  can
  come to the FESCo meeting (although I'm hoping we can make those meetings
  more efficient, so that's not a good place for back and forth -- if 
  possible
  we should work out the issues before the meeting).
 
  Ticket number ?
 
   This change makes it very hard to do necessary maintenance. I can
   understand blocking SSH login as root with password by default, but I do
   not understand what is the point of blocking console login as root.
 
  I assume that it's for a kiosk or public (or at least managed) lab
  situation. It makes sense for that, but I'm not convinced of a benefit
  otherwise, and I don't think that situation is the default
 
  I am not even sure it makes sense in a kiosk, unless people want to use
  password as their root password. But even if it made sense in that
  situation it is far from being a useful *default*. This kind of severely
  restricting measure is best left to hardening manuals.
 
  Simo.
 
  --
  Simo Sorce * Red Hat, Inc * New York
 
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: F21 System Wide Change: RPM-4.12

2014-04-03 Thread Rex Dieter

Mikolaj Izdebski wrote:

 Re: F21 System Wide Change: RPM-4.12
 From:
 Mikolaj Izdebski mizde...@redhat.com
   Reply-To:
 Development discussions related to Fedora devel@lists.fedoraproject.org
   Date:
 Thursday, April 03, 2014 08:54:18 AM
   To:
 devel@lists.fedoraproject.org
   Groups:
 gmane.linux.redhat.fedora.devel
   References: 1
 On 04/02/2014 07:47 PM, Jaroslav Reznik wrote:
 * Support for weak dependencies

 Does this mean that rpm-build will be able to create packages with weak
 dependencies? 

Yes.

 Will Fedora packages be allowed to declare weak dependencies?

I suspect the best short answer would be: no (for now), at least until 
packaging tools (yum, dnf, packagekit) and some packaging guidelines are 
written to support this new feature.

-- Rex

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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Matthew Garrett

On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote:

 Did any of your gnome-shell extensions break ?

Isn't this inevitable? If any extensions only claim to support 3.10 then 
they'll stop working until updated.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard

2014-04-03 Thread Gary Gatling

On Thu, Apr 3, 2014 at 10:23 AM, Gary Gatling gsgat...@ncsu.edu wrote:


 Thanks a lot for the feedback.

 I have asked the developers for input. I opened a issue of the github
 issue tracker here:

  https://github.com/Bumblebee-Project/Bumblebee/issues/568



After further experimentation it seems that xorg-x11-drv-mouse and
xorg-x11-drv-keyboard are not needed for bumblebee after all in fedora. So
I don't have any objections to you retiring both of those packages. Thanks
a lot for all the useful feedback on this.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 16:52 GMT+02:00 Matthew Garrett mj...@srcf.ucam.org:

 On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote:

  Did any of your gnome-shell extensions break ?

 Isn't this inevitable? If any extensions only claim to support 3.10 then
 they'll stop working until updated.


One, at least theoretical, way to resolve this would be to update all
extensions hosted at extensions.gnome.org to support 3.12.
 Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-03 Thread Chris Adams

Once upon a time, quickbooks office quickbooks.off...@gmail.com said:
 This change will not affect logging into the console using the local
 account and then doing su to get root privileges.

The only local account on many (most?) systems with network
authentication is root.

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

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-03 Thread Paul Wouters


On Thu, 3 Apr 2014, Simo Sorce wrote:


On Thu, 2014-04-03 at 07:32 -0700, quickbooks office wrote:

This change will not affect logging into the console using the local
account and then doing su to get root privileges.


What local account ?



Is there a problem with logging into the local user account and then
typing su and the root password?


Yes, in most installation I do not have any local user


+1

The ability to login as root over the (virtual) serial console is
very important. If anything, securetty should include all those
(virtual) serials ports per default.

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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Matthew Garrett

On Thu, Apr 03, 2014 at 04:57:10PM +0200, Miloslav Trmač wrote:
 2014-04-03 16:52 GMT+02:00 Matthew Garrett mj...@srcf.ucam.org:
  Isn't this inevitable? If any extensions only claim to support 3.10 then
  they'll stop working until updated.
 
 One, at least theoretical, way to resolve this would be to update all
 extensions hosted at extensions.gnome.org to support 3.12.

Don't the extensions end up in the user's home directory? How can we 
forcibly update them?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Jóhann B. Guðmundsson



On 04/03/2014 02:20 PM, Matthias Clasen wrote:

Hey,

so the time has come to consider this - thanks to the great work of
Richard and Kalev on the copr, we have a set of 3.12 packages that have
already received fairly wide testing.

But we should be careful, so I want to ask for concrete problem reports
with the copr packages, besides dependency problems caused by the
parallel nature of the copr itself.

Did any of your gnome-shell extensions break ?

Did you experience crashes or other serious problems with applications ?

If so, please let us know on the desktop list. If I don't hear of major
problems by next week, I'll file a Fesco ticket to ask for an exception.


Are you going to be delivering drastic changes to peoples UI interface 
by updating Gnome to a new Gnome release in a middle of GA cycle?


Has FESCo approved this?

JBG

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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/03/2014 10:52 AM, Matthew Garrett wrote:
 On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote:
 
 Did any of your gnome-shell extensions break ?
 
 Isn't this inevitable? If any extensions only claim to support 3.10
 then they'll stop working until updated.
 

There's an option in Gnome Shell buried in the gsettings that allows
you to ignore this check and just run them. I've got that on and it
worked successfully with all the extensions I run[1] (I need to go and
inform the extension upstreams of that fact).

One option we could look into would be for GNOME to set this option on
by default for a month or so to give extension authors time to catch
up while not breaking any user extension that works unmodified.


[1]
http://sgallagh.wordpress.com/2013/06/27/one-week-with-gnome-3-classic-twenty-eight-days-later/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM9ej4ACgkQeiVVYja6o6MrOACgnyrLB0/y1E94hdoTs7PAdSnf
fOQAmwZBcaIzX4RJ4bp3/EepKI0n2XhS
=moGK
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread drago01

On Thu, Apr 3, 2014 at 5:07 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:

 On 04/03/2014 02:20 PM, Matthias Clasen wrote:

 Hey,

 so the time has come to consider this - thanks to the great work of
 Richard and Kalev on the copr, we have a set of 3.12 packages that have
 already received fairly wide testing.

 But we should be careful, so I want to ask for concrete problem reports
 with the copr packages, besides dependency problems caused by the
 parallel nature of the copr itself.

 Did any of your gnome-shell extensions break ?

 Did you experience crashes or other serious problems with applications ?

 If so, please let us know on the desktop list. If I don't hear of major
 problems by next week, I'll file a Fesco ticket to ask for an exception.


 Are you going to be delivering drastic changes to peoples UI interface by
 updating Gnome to a new Gnome release in a middle of GA cycle?

 Has FESCo approved this?

Did you read more than just the subject?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/03/2014 11:07 AM, Jóhann B. Guðmundsson wrote:
 
 On 04/03/2014 02:20 PM, Matthias Clasen wrote:
 Hey,
 
 so the time has come to consider this - thanks to the great work
 of Richard and Kalev on the copr, we have a set of 3.12 packages
 that have already received fairly wide testing.
 
 But we should be careful, so I want to ask for concrete problem
 reports with the copr packages, besides dependency problems
 caused by the parallel nature of the copr itself.
 
 Did any of your gnome-shell extensions break ?
 
 Did you experience crashes or other serious problems with
 applications ?
 
 If so, please let us know on the desktop list. If I don't hear of
 major problems by next week, I'll file a Fesco ticket to ask for
 an exception.
 
 Are you going to be delivering drastic changes to peoples UI
 interface by updating Gnome to a new Gnome release in a middle of
 GA cycle?
 
 Has FESCo approved this?
 

Your question was answered in the quote you included: he's asking for
the general devel list to discuss this before he brings it to FESCo
for their approval or refusal.

Also, as someone who has been testing this update in the COPR for
about a month now, there are a few striking changes (the redesign of
gedit is thoroughly perplexing), but on the whole I haven't found
anything fundamentally out of place in the desktop environment (just
in a few of the apps).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM9ey4ACgkQeiVVYja6o6PDFgCePoMjYKi+F5bNcEsTvnJ04uVM
fyEAnR701UCZzN0t5Jth6p5ka4ROiRCI
=IhU8
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1084093] New: perl-CPAN-Inject-1.14-4.fc21 FTBFS in non-koji mock

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

Bug ID: 1084093
   Summary: perl-CPAN-Inject-1.14-4.fc21 FTBFS in non-koji mock
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN-Inject
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-de...@lists.fedoraproject.org



perl-CPAN-Inject-1.14-4.fc21 fails to build in local mock environment. A test
fails:

t/01_compile.t .. ok
Use of uninitialized value $ping_cache_limit in numeric gt () at
/usr/share/per
l5/CPAN/Mirrors.pm line 384.
Use of uninitialized value $ping_cache_limit in numeric gt () at
/usr/share/per
l5/CPAN/Mirrors.pm line 384.
Attempting to create directory /builddir/perl5
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/CPAN/Distr
ibution.pm line 2685.
The directory 't/sources' does not exist at t/02_main.t line 100.
# Looks like you planned 24 tests but ran 15.
# Looks like your test exited with 2 just after 15.
t/02_main.t . 
Dubious, test returned 2 (wstat 512, 0x200)
Failed 9/24 subtests 
(less 1 skipped subtest: 14 okay)
Test Summary Report
---
t/02_main.t   (Wstat: 512 Tests: 15 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 24 tests but ran 15.

-- 
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=5yuerY1C89a=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: Considering GNOME 3.12 as an F20 update

On Thu, Apr 03, 2014 at 03:52:49PM +0100, Matthew Garrett wrote:
  Did any of your gnome-shell extensions break ?
 Isn't this inevitable? If any extensions only claim to support 3.10 then 
 they'll stop working until updated.

I've had a pretty good experience here this time around. Almost everything
worked when I told it to not do the check, and others were updated. Also,
when I look at https://extensions.gnome.org/ sorted by popularity, _most_ of
the top ones are already updated. I'd like to see an effort to get the
remaining few that are on the top N pages updated, and then I'd be pretty
comfortable recommending this as an F20 update.

When I'm _running_ 3.12, I can get the web site to give me a list of all
the extensions sorted by popularity, with the ones that aren't compatible
grayed out. Can one do that _for 3.12_ from a 3.10 system? Then I can send
out a link that says Check if the stuff you really care about needs a
update.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
  Tepid change for the somewhat better!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Matthew Garrett

On Thu, Apr 03, 2014 at 11:11:58AM -0400, Stephen Gallagher wrote:

 One option we could look into would be for GNOME to set this option on
 by default for a month or so to give extension authors time to catch
 up while not breaking any user extension that works unmodified.

My understanding was that there was no mechanism for automatically 
updating extensions at present.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

On Thu, Apr 03, 2014 at 04:23:02PM +0100, Matthew Garrett wrote:
  One option we could look into would be for GNOME to set this option on
  by default for a month or so to give extension authors time to catch
  up while not breaking any user extension that works unmodified.
 My understanding was that there was no mechanism for automatically 
 updating extensions at present.

Hmmm, yeah; I'm fairly diligent about going to the
https://extensions.gnome.org/local/ and clicking the update button.

I can see the reservations with doing this automatically. Is an upgrade
helper app of some sort a good idea?

For the future, maybe we need to look at shipping more of these as RPMs. I
know RPMs are not the General Statement for the Future Of Distros, but it is
an existing mechanism we have for solving basically this exact problem.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
  Tepid change for the somewhat better!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Andre Robatino

Matthias Clasen mclasen at redhat.com writes:

 Did any of your gnome-shell extensions break ?

gnome-shell-extension-fedmsg is still not working in Rawhide (see
https://bugzilla.redhat.com/show_bug.cgi?id=1045669 ). This only affects
Fedora so thought I should mention it here.




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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Jóhann B. Guðmundsson



On 04/03/2014 03:15 PM, Stephen Gallagher wrote:

Also, as someone who has been testing this update in the COPR for
about a month now


Did you ( and others ) run through QA release blocking test cases for 
Gnome or is this more I have been running Gnome for about a month now 
kinda thing?



, there are a few striking changes (the redesign of
gedit is thoroughly perplexing), but on the whole I haven't found
anything fundamentally out of place in the desktop environment (just
in a few of the apps).


Let me rephrase my question

Do we allow for ui changes being made how small they might be or how big 
they might be to our default desktop on GA releases?


If the answer is yes, Gnome would be allowed to be made rebase-able 
between release


If the answer is no well things remain the same.



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

Re: F21 System Wide Change: lbzip2 as default bzip2 implementation

2014-04-02 19:24 GMT+02:00 Jaroslav Reznik jrez...@redhat.com:

 = Proposed System Wide Change:  lbzip2 as default bzip2 implementation =
 https://fedoraproject.org/wiki/Changes/lbzip2


While the speedup is desirable, it's not really obvious that this is the
right time to do the change.

Looking at http://lbzip2.org/news , lbzip2 is still fixing crashes during
compression and decompression.  That's rather troubling: we need the bzip2
implementation to be roughly as stable as file system*.*  The Change page
implies that bzip2 is not actively maintained; that may be true but looking
at bugzilla.redhat.com, there has AFAICT never been a bug reporting that
something can't be compressed or decompressed--that's a *very* high bar to
match.  (I do appreciate that assertion failure and silent miscompression
are not the same thing.)

Having the library implementation and the command-line implementation
completely separate may frustrate debugging efforts when using an
application-builtin compression and saving uncompressed and compressing
manually may give different results.  That's not a deal-breaker but having
a single implementation would certainly simplify things.

Ultimately the easiest way to make this implementation change happen, not
only in Fedora but in all distributions, would be for the improvements to
be integrated into the upstream bzip2 codebase; has that possibility been
explored at all?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Ralf Corsepius


On 04/03/2014 04:20 PM, Matthias Clasen wrote:

Hey,

so the time has come to consider this - thanks to the great work of
Richard and Kalev on the copr, we have a set of 3.12 packages that have
already received fairly wide testing.

But we should be careful, so I want to ask for concrete problem reports
with the copr packages, besides dependency problems caused by the
parallel nature of the copr itself.

Did any of your gnome-shell extensions break ?

Did you experience crashes or other serious problems with applications ?

If so, please let us know on the desktop list. If I don't hear of major
problems by next week, I'll file a Fesco ticket to ask for an exception.

You didn't mention the most important question:

Did the API or ABI change in backward-incompatible way?

If the answer to this question is yes, then the answer to updating to 
gnome-3.12 needs to be no, because such changes in released versions of 
Fedora are not allowed.


Ralf


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

Re: Considering GNOME 3.12 as an F20 update

On Thu, Apr 03, 2014 at 06:09:43PM +0200, Ralf Corsepius wrote:
 You didn't mention the most important question:
 
 Did the API or ABI change in backward-incompatible way?
 
 If the answer to this question is yes, then the answer to updating
 to gnome-3.12 needs to be no, because such changes in released
 versions of Fedora are not allowed.

I think we should ground the discussion in the actual policy, which doesn't
say that, but does say ABI changes in general are very strongly discouraged
and Avoid Major version updates, ABI breakage or API changes if at all
possible. That is significantly more qualifed. And more to the point, it
says
  
   Some classes of software will not fit in these guidelines. If your
   package does not fit in one of the classes below, but you think it should
   be allowed to update more rapidly, propose a new exception class to FESCO
   and/or request an exception for your specific update case.

   Note that you should open this dialog BEFORE you build or push updates.

which is exactly what is happening here.

http://fedoraproject.org/wiki/Updates_Policy

Now, in reading that policy, there are quite a few things that match the
Things that would make it less likely to grant a request list. But, on the
other hand, by having a longer-than-typical Fedora release cycle this time
around, we are already in special circumstances territory.



-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
  Tepid change for the somewhat better!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Jóhann B. Guðmundsson



On 04/03/2014 04:22 PM, Matthew Miller wrote:

Now, in reading that policy, there are quite a few things that match the
Things that would make it less likely to grant a request list. But, on the
other hand, by having a longer-than-typical Fedora release cycle this time
around, we are already in special circumstances territory.



Gnome community is not know for their stability in their UI so we are 
talking about user visible changes.


Sysadmins on these parts brought out their voodoo dolls and started 
stabbing them while cursing the new and improved//network settings 
that came with F20 and Gnome 3.10 and other docket breakage that 
followed in other words Gnome community is not know for their stability 
in their UI so we are talking about user visible changes being 
introduced into GA release.


And I have yet to see any request have been made to the test list to at 
least do the same validation on Gnome as is done before we release an 
new GA release.


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

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-03 15:06 GMT+02:00 Simo Sorce s...@redhat.com:

 On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote:
  On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote:
   How does someone express strong disagreement to this change ?
 
  Posting here is a good start. You can also add a note in the FESCo ticket
  for approval once one is filed, and if you are incredibly passionate you
 can
  come to the FESCo meeting (although I'm hoping we can make those meetings
  more efficient, so that's not a good place for back and forth -- if
 possible
  we should work out the issues before the meeting).

 Ticket number ?


The ticket will be filed around the end of the comment period (which hasn't
even started for this change, because it hasn't been announced by the
Wrangler), and visible to devel@ in the FESCo agenda mail usually sent
about a day before the meeting.

(Yes, you would need to do some work to track all of this.  But you should
expect FESCo members to carefully read all comments on the mailing list
without having to explicitly raise concerns in the ticket.)
 Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-02 20:12 GMT+02:00 Simo Sorce s...@redhat.com:

 On Wed, 2014-04-02 at 09:12 -0700, quickbooks office wrote:
  [CHANGE PROPOSAL] The securetty file is empty by default
 
  All the info has been sitting here @
 
 https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default

 I often install machines with root only as my users are all in my
 FreeIPA/LDAP server and I expect to be able to login as root on the
 console for maintenance purposes.

 This change makes it very hard to do necessary maintenance. I can
 understand blocking SSH login as root with password by default, but I do
 not understand what is the point of blocking console login as root.


In larger organizations there is a legitimate need to be able to attribute
every action as root to a specific individual, which is easiest to do by
requiring a login from a non-root account to establish the session, and
then tracking actions done by that session.  OTOH this all works reliably
enough only with a non-default auditing setup, so restricting root logins
by default is alone not at all sufficient.


 Please explain the logic of blocking console logins but allowing SSH
 logins, it is completely backwards.


Of the various problems with the proposal[1], this one seems the easiest to
fix :)
 Mirek

[1] I'm not listing them here; I'd much rather have the Change officially
announced and have the official comment period, instead of starting a
tradition of pre-announcements.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Matthias Clasen

On Thu, 2014-04-03 at 16:32 +, Jóhann B. Guðmundsson wrote:
 
 On 04/03/2014 04:22 PM, Matthew Miller wrote:
 
  Now, in reading that policy, there are quite a few things that match the
  Things that would make it less likely to grant a request list. But, on the
  other hand, by having a longer-than-typical Fedora release cycle this time
  around, we are already in special circumstances territory.
  
 
 Gnome community is not know for their stability in their UI so we are
 talking about user visible changes.
 
 Sysadmins on these parts brought out their voodoo dolls and started
 stabbing them while cursing the new and improved network settings
 that came with F20 and Gnome 3.10 and other docket breakage that
 followed in other words Gnome community is not know for their
 stability in their UI so we are talking about user visible changes
 being introduced into GA release.
 
 And I have yet to see any request have been made to the test list to
 at least do the same validation on Gnome as is done before we release
 an new GA release.

Note that I am not asking about armchair opinions about whether this
idea would theoretically fit the guidelines.

Neither am I asking for war stories of sysadmins whose life was ruined
by f20.

I am interested in concrete problems that have been experienced by the
people who have tried out Richards copr. If you are not in that group of
people, maybe you should actually try the copr before participating in
this discussion.

Thanks,

Matthias

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

Re: GnuTLS issue (Mandos Server/Client)

2014-04-03 Thread Nathanael D. Noblet

On Thu, 2014-04-03 at 16:05 +0200, Nikos Mavrogiannopoulos wrote:
 On Wed, 2014-04-02 at 10:50 -0600, Nathanael D. Noblet wrote:
  CentOS 6 = gnutls 2.8.5
  F20  = gnutls 3.1.20
  The server is a python app and sets the priority string as follows:
  priority=SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP
  this is fed to some gnutls function somewhere in the stack.
 
 Does it really use TLS with openpgp certificates? If yes, I doubt you
 could make 2.8.5 interoperate with gnutls 3.1.20. GnuTLS was modified in
 3.1.x to adhere with RFC6091 which was incompatible the previous attempt
 to have openpgp keys to TLS.

Hello,

  Yes it uses TLS and opengpg certificates. So gnutls 3.1.20 can't use
both new and old methods I presume?



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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Rahul Sundaram

Hi


On Thu, Apr 3, 2014 at 10:20 AM, Matthias Clasen mcla...@redhat.com wrote:



 Did any of your gnome-shell extensions break ?


Yes but I got updates for most of them.   Couple of them are still broken

https://extensions.gnome.org/extension/8/places-status-indicator/
https://extensions.gnome.org/extension/696/skype-integration/



 Did you experience crashes or other serious problems with applications ?


Nope.  GNOME Shell used to crash now and then earlier but not anymore.

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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Gerard Ryan

On Thu, Apr 3, 2014 at 7:50 PM, Matthias Clasen mcla...@redhat.com wrote:
 Did you experience crashes or other serious problems with applications ?

Hi Matthias,

I had a problem with the new totem/Videos having a non-responsive UI.
I'm away on a work assignment until the 13th so unfortunately I can't
verify that it's still a problem or if it was some bad configuration
that I had.

From what I remember, videos directly in my home directory were
displayed as thumbnails on the main window and they would play fine.
If I tried to add/open a local video from another location (even
subdirectory of my home) by clicking on the + at the corner, nothing
happened. I wasn't given an open file dialog or anything like that.

As I said, it may not actually still be a problem. Maybe someone else
can verify?

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

Re: Considering GNOME 3.12 as an F20 update

On Thu, Apr 03, 2014 at 01:09:32PM -0400, Matthias Clasen wrote:
  And I have yet to see any request have been made to the test list to
  at least do the same validation on Gnome as is done before we release
  an new GA release.
 Note that I am not asking about armchair opinions about whether this
 idea would theoretically fit the guidelines.

Let's keep this friendly and in line with the be excellent guideline,
please. I know you are both very passionate about this.

Phrasing aside, the basic concern about bad user experience due to changing
UI mid-cycle is completely valid and has nothing to do with any general
perception of Gnome. That's why the policy is there, after all. There's no
reason any contributor can't raise those sort of points even if it wasn't
what you asked. It's an important point of the overall decision.

And, Jóhann's note about working with the QA team to develop a test plan and
run through it seems worth pursuing if the members of QA team are interested
and willing (or interested in helping Gnome people or volunteers figure out
how it's normally done). I think it's pretty reasonable to assume that extra
review would making doing the rebase a lot more comfortable -- anecdotal
reports from people running Rawhide or using the Copr are useful for what
they are, but they're not formal QA.


-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
  Tepid change for the somewhat better!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread drago01

On Thu, Apr 3, 2014 at 7:31 PM, Reindl Harald h.rei...@thelounge.net wrote:
 will that below ever get fixed in F20?

Maybe  ... maybe not.

 should i file a bug against the distribution?

No .. this makes no sense.

 should i file a bug against Red Hat as upstream employer?

Neither does this (unless you have a support contract but last time I
checked they do not offer one for fedora).

 and if someone asks why i called Lennart in #1072368
 names - [..]

That does not help your case at all ... you cannot force people to do
work for you that's not how open source works.

So your options are either:

1) Convince someone to fix it (that works by rational arguments not by
calling people idiots)

or

2) Fix it and file patches

or

3) Pay someone to do 2)

Note: I didn't look at the bugs.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs in F20/F21 - bug against the distribution?



Am 03.04.2014 19:47, schrieb drago01:
 Note: I didn't look at the bugs

then please don't answer at all



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

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread drago01

On Thu, Apr 3, 2014 at 7:52 PM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 03.04.2014 19:47, schrieb drago01:
 Note: I didn't look at the bugs

 then please don't answer at all

What I wrote does not depend on what the bugs actually are.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs in F20/F21 - bug against the distribution?



Am 03.04.2014 19:54, schrieb drago01:
 On Thu, Apr 3, 2014 at 7:52 PM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 03.04.2014 19:47, schrieb drago01:
 Note: I didn't look at the bugs

 then please don't answer at all
 
 What I wrote does not depend on what the bugs actually are

it does and honestly bugs which are reported before release
and open 7 months later in a core-component ar enot doing
the distribution a favour as well as upstream developers
of such a component even discuss against kernel upstream
that they are doing the right thing until Linus has that
muche enough to impend prohibit one of the core developers
to commit code in the future

this ignorance against downstream and users and break things
careless which where not broken, make maintaining machines
more and more complicated by spew nonsense in the logs and
demand users to change their way of work to make upstream
happy is a real bad attitude and in case of but reportes
are not friendly enough - well, cause and effect

 It does become a problem when you have a system service
 developer who thinks the universe revolves around him,
 and nobody else matters, and people sending him bug-reports
 are annoyances that should be ignored rather than acknowledged
 and fixed. At that point, it's a problem.



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

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Rahul Sundaram

Hi

On Thu, Apr 3, 2014 at 2:01 PM, Reindl Harald wrote:

 Am 03.04.2014 19:54, schrieb drago01:
 
  Am 03.04.2014 19:47, schrieb drago01:
 
  What I wrote does not depend on what the bugs actually are

 it does


No.  You are not entitled to escalate it to any employer unless you have a
commercial agreement with them.   If some maintainer closes a bug
prematurely (which does happen more than once in any major component), it
still doesn't mean you get to call them names and it does not excuse your
behavior.  You should really apologize.  Learn to work with people better
as has been suggested to you strongly many times before.  If you continue
to ignore the advice and keep resorting to calling people names now and
then, you will likely get yourself moderated from Bugzilla and/or Fedora
mailing lists again.

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

Re: F21 System Wide Change: lbzip2 as default bzip2 implementation

2014-04-03 Thread Mikolaj Izdebski

On 04/03/2014 06:08 PM, Miloslav Trmač wrote:
 Looking at http://lbzip2.org/news , lbzip2 is still fixing crashes during
 compression and decompression.  That's rather troubling: we need the bzip2
 implementation to be roughly as stable as file system*.*

They say that every non-trivial piece of software has at least one bug.
 bzip2 also has bugs, myself I am aware of a few of them.

 The Change page
 implies that bzip2 is not actively maintained; that may be true but looking
 at bugzilla.redhat.com, there has AFAICT never been a bug reporting that
 something can't be compressed or decompressed--that's a *very* high bar to
 match.  (I do appreciate that assertion failure and silent miscompression
 are not the same thing.)

Neither was for lbzip2.  And as a matter of fact, bzip2 is compiled with
most of assertions disabled.  But I understand the point.

It may be true that bzip2 is more stable, but that's because it has been
given a chance being included in popular operating systems and after
initial bugs were fixed it has been there without any changes for years.

I care about lbzip2 quality very much.  I run a test suite consisting of
over 320,000 automated test cases, I compile it with all possible
warnings enabled I test it with multiple static analysis tools.  Any
bugs that may be found during testing in Fedora will be taken care of
with high priority.

I believe that lbzip2 deserves to be given a chance and if for some
reason it turns out not to be ready, the Change can be reverted very
easily with a single spec file modification.

 Having the library implementation and the command-line implementation
 completely separate may frustrate debugging efforts when using an
 application-builtin compression and saving uncompressed and compressing
 manually may give different results.  That's not a deal-breaker but having
 a single implementation would certainly simplify things.

Users will still be able to run bzip2 explicitly if needed or configure
alternatives to used it as implementation of /usr/bin/bzip2 on their
systems.

Besides that I am willing to provide a library interface for lbzip2 in
future if there is demand.

 Ultimately the easiest way to make this implementation change happen, not
 only in Fedora but in all distributions, would be for the improvements to
 be integrated into the upstream bzip2 codebase; has that possibility been
 explored at all?

lbzip2 as it is now is a merger of 2 projects -- a parallel bzip2-like
tool using libbz2 by Laszlo Ersek (started in 2008) and improved
low-level bzip2 library by me (started in 2007).  The 2 projects were
merged in 2010 and since then I took maintenance of lbzip2.

While I would like the improvements and new features of lbzip2 to be
included in bzip2, I lost my hopes of this ever happening.  Both Laszlo
me and tried contacting Julian Seward (the author or bzip2) and
contributing to bzip2, but without any success.

Initially Julian admited that it would be desirable to parallelise
bzip2.  The plan was to evaluate existing implementations and decide
which one to integrate with bzip2, or start the work from scratch.  But
nothing of that happened.  The last conversation about improving bzip2
took place in 2009 and only a single patch was included in bzip2 since
then -- a fix for important security bug which I discovered
(CVE-2010-0405 [1], it took it 6 months to be applied in bzip2).

That said, I am still willing to cooperate with Julian and discuss
possibilities of merging some code or improving bzip2 in any way.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0405

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Adam Jackson

On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:

 and if someone asks why i called Lennart in #1072368
 names

We didn't, and no justification would matter.  It's not acceptable
behaviour, and you need to knock it off.

- ajax

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

Re: systemd bugs in F20/F21 - bug against the distribution?



Am 03.04.2014 20:00, schrieb Adam Jackson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
 
 and if someone asks why i called Lennart in #1072368
 names
 
 We didn't, and no justification would matter.  It's not acceptable
 behaviour, and you need to knock it off.

i know that - on the other hand developers need to knock
out the reflex your bugreport annoys me and close it
within minutes because they don't care about users

and only if *both sides* starts to play nicely it can work
and one part of that is to *respect* reporters and realize
taht report bugs and describe problems in daily use is
a important sort of contribution - i am developer too and
i am well aware without the users point of view i would
develop blindly - anybody not awawre of this should stop
calling himslef a serious developer

developers need to knock of that attitude:
https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10

without users the developers would be meaningless



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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Elad Alfassa

On Thu, Apr 3, 2014 at 8:30 PM, Gerard Ryan gali...@fedoraproject.orgwrote:


 I had a problem with the new totem/Videos having a non-responsive UI.


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


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

Re: Packaging of libdb-6+

2014-04-03 Thread Paul Howarth

On Thu, 03 Apr 2014 15:53:04 +0200
Honza Horak hho...@redhat.com wrote:

 On 04/03/2014 11:20 AM, H. Guémar wrote:
  Since AGPL is fedora-compliant license, there's no blocker to get
  libdb6 into packages collection.
  Besides, libdb5 is still critical for many packages (like RM), until
  we get rid of it, I can only agree with your proposal.
 
  Maybe, it's still time to rename the current libdb = libdb5 and get
  newer releases named libdb starting F21
 
 This would be possible only by co-operation with the depended
 packages, since they usually use BuildRequire: libdb-devel. So
 after just rebuilding those to link against libdb-6, some of the
 packages would start to suffer from license incompatibilities. But I
 agree that libdb-6.x + libdb5-5.x scenario looks better than
 libdb-5.x + libdb6-6.x.
 
 Anyway, to make some marketing for this change, we should have a Self 
 contained change page for this [1]. Change Proposals Submission
 Deadline is 2014-04-08 btw.
 
 [1]
 http://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes

It's not a self-contained change really. Without a good deal of
co-ordination it'll end up causing problems like
https://bugzilla.redhat.com/show_bug.cgi?id=768846

in which there are symbol conflicts when a process ends up trying to
load two different versions of libdb.

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

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Martin Langhoff

On Thu, Apr 3, 2014 at 3:08 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 03.04.2014 20:00, schrieb Adam Jackson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:

 and if someone asks why i called Lennart in #1072368
 names

 We didn't, and no justification would matter.  It's not acceptable
 behaviour, and you need to knock it off.

 i know that -

Then do. Your behavior is toxic, don't excuse it with others' behavior.



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs in F20/F21 - bug against the distribution?


Am 03.04.2014 21:44, schrieb Martin Langhoff:
 On Thu, Apr 3, 2014 at 3:08 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 03.04.2014 20:00, schrieb Adam Jackson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:

 and if someone asks why i called Lennart in #1072368
 names

 We didn't, and no justification would matter.  It's not acceptable
 behaviour, and you need to knock it off.

 i know that -
 
 Then do. Your behavior is toxic, don't excuse it with others' behavior

as explained most of that behavior started with F15 and destroy years
of optimization on perfect running systems which now repeats by put
the head in the sand, ignore problems over months and if a reaction
besides ignore happens it is close because i don't care

there is a reason today even Linus choosed words like and I personally
find it annoying that it's always the same f*cking primadonna involved
in direction of systemd-upstream



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

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Kevin Fenzi

Bad behavior in response to bad behavior just feeds a positive feedback
cycle ( http://en.wikipedia.org/wiki/Positive_feedback ). 

The way to break out of it is for the person you control (namely YOU)
to behave well. If others don't do so, things can calmly escalate and
proper measures taken.

So, be reasonable. Use logical arguments to convince maintainers that
your bug is reasonable and your proposed solutions or patches are also
reasonable. If you cannot do this, step back and let others do so. 

If the problems are persistent or highly impact-full, it's likely that
higher levels of project management may get involved, but only in good
time and after looking at the behavior of all the parties involved. 

kevin


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

Re: systemd bugs in F20/F21 - bug against the distribution?



Am 03.04.2014 22:04, schrieb Kevin Fenzi:
 Bad behavior in response to bad behavior just feeds a positive feedback
 cycle ( http://en.wikipedia.org/wiki/Positive_feedback ). 
 
 The way to break out of it is for the person you control (namely YOU)
 to behave well. If others don't do so, things can calmly escalate and
 proper measures taken.
 
 So, be reasonable. Use logical arguments to convince maintainers that
 your bug is reasonable and your proposed solutions or patches are also
 reasonable. If you cannot do this, step back and let others do so. 

what logical arguments do you have if the developer is living in his
own world where he is happy about every log message his baby writes
while at the same time that burries critical and relevant messages for
anybody else who cares?

you can come up with logical arguments in case of interested
developers but not in case of we do what we want, break what
we want when we want to break it and everything falling left
and right is buggy and wrong developers

 If the problems are persistent or highly impact-full, it's likely that
 higher levels of project management may get involved, but only in good
 time and after looking at the behavior of all the parties involved.

writing thousands of log-lines on a completly stripped down Rawhide
VM with only the default cronjobs *is highly impact-full* because
on production workloads and a central machine receiving all that
messages and store them in a database that is a DOS attack

if there would be a prefix or a specific binary thrwoing all that
messages you could filter them out in rsyslog.conf (by keep useless
overhead burried) but not the way it is implemented

use journalctl and filter out is pure ignorance



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

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Adam Williamson

On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
 will that below ever get fixed in F20?

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

The developer does not consider it to be a bug. You may disagree, but so
far, you don't seem to have convinced him or any other systemd
developers or, well, anyone else.

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

This is an entirely trivial issue: a failed attempt to access something
with no apparent negative consequences. Doesn't seem like it'd be a high
priority. It also doesn't seem like it would be too difficult to track
down and propose a fix, if it's bugging you so much.

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

You yourself have reported in
https://bugzilla.redhat.com/show_bug.cgi?id=626477#c44 that this is
fixed on the systemd 208 branch, which F20 is tracking. Then you went
nuts and started yelling at people, which as you've been told fifty six
thousand goddamn times by now, never ever helps. From the latest
comments it sounds like whenever f20 is updated to the latest
systemd-208 code, this fix will come in. It's up to the package
maintainer when they want to do that.

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

Apparently fixed in 20 and Rawhide, you just want a backport to 19?

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

Is another extremely trivial one: you're throwing your toys out of the
pram over slightly sub-optimal autocomplete? Really?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Richard Hughes

On 3 April 2014 20:00, Adam Jackson a...@redhat.com wrote:
 We didn't, and no justification would matter.  It's not acceptable
 behaviour, and you need to knock it off.

I'm not the only developer considering unsubscribing from fedora-devel
because of emails like the original email. Either the moderators start
enforcing stricter rules, warning and then banning certain users, on
the number of developers on this -devel mailing list is going to
start going down really fast. Without developers this mailing list is
pointless.

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

Re: systemd bugs in F20/F21 - bug against the distribution?



Am 03.04.2014 22:32, schrieb Adam Williamson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
 will that below ever get fixed in F20?
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1072368
 
 The developer does not consider it to be a bug. You may disagree, but so
 far, you don't seem to have convinced him or any other systemd
 developers or, well, anyone else.

than the developer should explain his point of view and
ask for further input instead react with WONT FIX

 https://bugzilla.redhat.com/show_bug.cgi?id=1010572
 
 This is an entirely trivial issue: a failed attempt to access something
 with no apparent negative consequences. Doesn't seem like it'd be a high
 priority. It also doesn't seem like it would be too difficult to track
 down and propose a fix, if it's bugging you so much.

i expect from a serious developer to face that message because i
expect that he reads his syslogs, if it is meaningless than the
code around of that is also meaningless and has to be removed
for the sake of clean software

 https://bugzilla.redhat.com/show_bug.cgi?id=626477
 
 You yourself have reported in
 https://bugzilla.redhat.com/show_bug.cgi?id=626477#c44 that this is
 fixed on the systemd 208 branch, which F20 is tracking. Then you went
 nuts and started yelling at people, which as you've been told fifty six
 thousand goddamn times by now, never ever helps. From the latest
 comments it sounds like whenever f20 is updated to the latest
 systemd-208 code, this fix will come in. It's up to the package
 maintainer when they want to do that.

well, if someone reports problems and even has testing environments
as well is willing to verify and test he can expect respect in form
of a scratch build

 https://bugzilla.redhat.com/show_bug.cgi?id=1047148
 
 Apparently fixed in 20 and Rawhide, you just want a backport to 19?

since the no distributeable systemctl reboot and much more the scary
fact that a workaround is based ona typo prevents from update any
production server to F20 i will face that until F20 is useable in
production which is not the case caused by systemd - chicken/egg problem

 https://bugzilla.redhat.com/show_bug.cgi?id=1024379
 
 Is another extremely trivial one: you're throwing your toys out of the
 pram over slightly sub-optimal autocomplete? Really?

it's anotehr drop into a full sea and affects my workload all the time
because i distribute commands from one machine having all packages
installed

systemctl stop whatever.service; do something; do something; systemctl start 
whatever.service





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

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Martin Langhoff

On Thu, Apr 3, 2014 at 4:41 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 03.04.2014 22:32, schrieb Adam Williamson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
 will that below ever get fixed in F20?

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

 The developer does not consider it to be a bug. You may disagree, but so
 far, you don't seem to have convinced him or any other systemd
 developers or, well, anyone else.

 than the developer should explain his point of view and
 ask for further input instead react with WONT FIX

Reindl. You are reading to retort, not to understand.

Please take a long moment to try to understand -- many folks that
would in some cases agree with some of your points think that overall
you are way wrong.

You should not answer every email addressed to you. Instead of
answering... read it :-)



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs in F20/F21 - bug against the distribution?


Am 03.04.2014 22:37, schrieb Richard Hughes:
 On 3 April 2014 20:00, Adam Jackson a...@redhat.com wrote:
 We didn't, and no justification would matter.  It's not acceptable
 behaviour, and you need to knock it off.
 
 I'm not the only developer considering unsubscribing from fedora-devel
 because of emails like the original email. 

what exactly is your personal problem with that original mail?
exceot taht you don't like me?

 Either the moderators start enforcing stricter rules, warning and then 
 banning certain users, on the number of developers on this -devel 
 mailing list is going to start going down really fast. Without developers 
 this mailing list is pointless.

speak for yourself and not for others - opposite to people like
Lennart, Kay and yourself other including me don't need moderation
and killfiles to not face critism




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

Re: systemd bugs in F20/F21 - bug against the distribution?



Am 03.04.2014 22:46, schrieb Martin Langhoff:
 On Thu, Apr 3, 2014 at 4:41 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 03.04.2014 22:32, schrieb Adam Williamson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
 will that below ever get fixed in F20?

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

 The developer does not consider it to be a bug. You may disagree, but so
 far, you don't seem to have convinced him or any other systemd
 developers or, well, anyone else.

 than the developer should explain his point of view and
 ask for further input instead react with WONT FIX
 
 Reindl. You are reading to retort, not to understand

i understand more than you imagine

but you need also to understand that a WON'T FIX for the reporter
of a bug is the same as spit into his face and so the only correct
reaction of a developer is:

* explain his point of view
* wait for a addtional response
* hestitate to press NO BUG or WON'T FIX aka leave me in peace

if developers are not greatful for users input users are not greatful
for breaking and changing things right and left of them which worked
as expected before



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

Re: systemd bugs in F20/F21 - bug against the distribution?

On Thu, Apr 03, 2014 at 10:41:58PM +0200, Reindl Harald wrote:
  https://bugzilla.redhat.com/show_bug.cgi?id=1072368
  The developer does not consider it to be a bug. You may disagree, but so
  far, you don't seem to have convinced him or any other systemd
  developers or, well, anyone else.
 than the developer should explain his point of view and
 ask for further input instead react with WONT FIX

The developer is under no obligation at all.

As Fedora, we *do* have a degree of collective concern -- although, still,
no _obligation_, because that's not the way community support works either.
But, when you start calling names, it *completely* cancels the ability for
anyone to help you.

So don't do that. It is actively counter-productive for your goals. Even if
you feel the other person is being unreasonable, *take the high road*. It
will win in the end.

You've gotten a lot of reasonable advice from other people here already.

I've seen you *give* reasonable advice in other threads.

Relax, calm down, come back, and let's work on building things and fixing
things instead of fighting.


-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
  Tepid change for the somewhat better!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs in F20/F21 - bug against the distribution?

2014-04-03 Thread Kevin Fenzi

On Thu, 3 Apr 2014 22:37:19 +0200
Richard Hughes hughsi...@gmail.com wrote:

 On 3 April 2014 20:00, Adam Jackson a...@redhat.com wrote:
  We didn't, and no justification would matter.  It's not acceptable
  behaviour, and you need to knock it off.
 
 I'm not the only developer considering unsubscribing from fedora-devel
 because of emails like the original email. Either the moderators start
 enforcing stricter rules, warning and then banning certain users, on
 the number of developers on this -devel mailing list is going to
 start going down really fast. Without developers this mailing list is
 pointless.

Feel free to actually mail the moderator(s): 
devel-ow...@lists.fedoraproject.org
when you feel moderation is required.

As one of the list moderators, I will tell you that for the most part
I value any input to the list and try and avoid moderation. If you
don't think this is good, feel free to file a fesco or board ticket to
replace me with different moderators that moderate differently. 

I have also closed this thread and warned the orig poster. 

kevin


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

Re: [CHANGE PROPOSAL] The securetty file is empty by default

2014-04-03 Thread Przemek Klosowski


On 04/03/2014 10:32 AM, quickbooks office wrote:

3.1.4.2.2. Disabling Root Logins

To further limit access to the root account, administrators can
disable root logins at the console by editing the /etc/securetty file.

This is done in the name of accountability, by forcing an administrative 
login through an account attributable to a specific person. This, 
however, only makes sense if there _actually_are_ such individual 
accounts on the system.


Would this proposal be acceptable if it wasn't implemented if 'root' is 
the only account?


I personally don't think even such amended proposal is a reasonable 
default configuration, because systems authenticating against a domain, 
and having only one local (root) account, could lock the admin out if 
something happens to the network or to the domain server.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard

2014-04-03 Thread Peter Hutterer

On Thu, Apr 03, 2014 at 09:58:59AM -0400, Adam Jackson wrote:
 On Thu, 2014-04-03 at 16:35 +1000, Peter Hutterer wrote:
 
  If fixes the problem but that doesn't tell the whole story. You have a conf
  that implicitly says load the mouse driver and then fails because you
  didn't have the mouse driver installed. Which is fair enough, the question
  here is why is that setting there in the first place? Is the goal to not add
  any devices, or is this just an accidental leftover?
 
 I think the goal _is_ to not add any devices, yes.  Bumblebee is
 basically a second X server to run on the nvidia gpu and pipe the pixels
 off that to the integrated gpu.  So input only ever happens on the
 integrated gpu's server, so you want to keep the bumblebee server away
 from event devices.  (I think; I've never actually run it.)

hmm, in that case that line wouldn't actually do what it should.
AutoAddDevices off enables the old defaults, i.e. the mouse and keyboard
drivers. The mouse driver hooks onto /dev/input/mice and would receive
events. The correct solution here is to explicitly ignore devices:

Section InputClass
Identifier ignore all event devices
MatchDevicePath /dev/input/event*
Option Ignore on
EndSection

I'll post that on the github bug as well 

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

Re: [CHANGE PROPOSAL] The securetty file is empty by default

On Thu, Apr 3, 2014 at 2:46 PM, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
 On 04/03/2014 10:32 AM, quickbooks office wrote:

 3.1.4.2.2. Disabling Root Logins

 To further limit access to the root account, administrators can
 disable root logins at the console by editing the /etc/securetty file.

 This is done in the name of accountability, by forcing an administrative
 login through an account attributable to a specific person. This, however,
 only makes sense if there _actually_are_ such individual accounts on the
 system.

 Would this proposal be acceptable if it wasn't implemented if 'root' is the
 only account?

 I personally don't think even such amended proposal is a reasonable default
 configuration, because systems authenticating against a domain, and having
 only one local (root) account, could lock the admin out if something happens
 to the network or to the domain server.


It's worse: the admin could lock themselves out just by creating
another user account.

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

sextractor license change

2014-04-03 Thread Sergio Pascual

sextractor (source extraction from astronomical images) has change its
license from CeCiLL to GPLv3+ in upstream version 2.19.5

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

swarp license change

2014-04-03 Thread Sergio Pascual

swarp (astronomical imaging resampling and coadding) has change its license
from CeCILL to GPLv3+ in upstream version 2.38.0

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

Reinstalling the bootloader

Once upon a time (Fedora 15? -- I've lost track), it was possible to
reinstall the bootloader using grub-install.

Nowadays it's a clusterfsck.  I've managed to screw up my bootloader.  Is
there a way to reinstall it without reinstalling the world?  Would it make
sense to split the whole bootloader thing out of Anaconda such that it
would be possible to re-run it?  I can access my install just fine using
chroot.

FWIW, the same question applies to upgrading the bootloader.  Somehow I'm
on Fedora 20 using grub 0.97.

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

Re: Reinstalling the bootloader



Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
 Once upon a time (Fedora 15? -- I've lost track), it was possible to 
 reinstall the bootloader using grub-install.

besides that it is the wrong list: grub2-install

 Nowadays it's a clusterfsck.  I've managed to screw up my bootloader.  Is 
 there a way to reinstall it without
 reinstalling the world?  Would it make sense to split the whole bootloader 
 thing out of Anaconda such that it would
 be possible to re-run it?  I can access my install just fine using chroot.
 
 FWIW, the same question applies to upgrading the bootloader.  Somehow I'm on 
 Fedora 20 using grub 0.97

how comes? grub2 took over with F16 or F17



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

[perl-HTML-FormatText-WithLinks/el6] new package for el6

2014-04-03 Thread Rüdiger Landmann

commit 6ada91085a2fa69ef7fc111ad871505bc4bf596d
Author: Ruediger Landmann r.landm...@redhat.com
Date:   Thu Apr 3 14:05:56 2014 +1000

new package for el6

 perl-HTML-FormatText-WithLinks.spec |  115 ---
 1 files changed, 26 insertions(+), 89 deletions(-)
---
diff --git a/perl-HTML-FormatText-WithLinks.spec 
b/perl-HTML-FormatText-WithLinks.spec
index c780bfa..a79bdee 100644
--- a/perl-HTML-FormatText-WithLinks.spec
+++ b/perl-HTML-FormatText-WithLinks.spec
@@ -1,118 +1,55 @@
 Name:   perl-HTML-FormatText-WithLinks
 Version:0.14
-Release:6%{?dist}
+Release:1%{?dist}
 Summary:HTML to text conversion with links as footnotes
-
-Group:  Development/Libraries
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/HTML-FormatText-WithLinks
-Source0:
http://search.cpan.org/CPAN/authors/id/S/ST/STRUAN/HTML-FormatText-WithLinks-%{version}.tar.gz
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/HTML-FormatText-WithLinks/
+Source0:
http://www.cpan.org/authors/id/S/ST/STRUAN/HTML-FormatText-WithLinks-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
 BuildArch:  noarch
-BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires:  perl(HTML::FormatText) perl(HTML::TreeBuilder)
+BuildRequires:  perl(HTML::FormatText) = 2
+BuildRequires:  perl(HTML::TreeBuilder)
+BuildRequires:  perl(Module::Build)
+BuildRequires:  perl(Test::More)
 BuildRequires:  perl(URI::WithBase)
-BuildRequires:  perl(Test::MockObject) perl(Test::Pod::Coverage) 
-BuildRequires:  perl(Test::Pod) perl(Test::More)
-Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
-# not picked up automatically since it is called through SUPER
-Requires:  perl(HTML::FormatText) = 2
+Requires:   perl(HTML::FormatText) = 2
+Requires:   perl(HTML::TreeBuilder)
+Requires:   perl(URI::WithBase)
+Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
 
 %description
-HTML::FormatText::WithLinks takes HTML and turns it into plain text but 
-prints all the links in the HTML as footnotes. By default, it attempts 
-to mimic the format of the lynx text based web browser's --dump option.
+HTML::FormatText::WithLinks takes HTML and turns it into plain text but
+prints all the links in the HTML as footnotes. By default, it attempts to
+mimic the format of the lynx text based web browser's --dump option.
 
 %prep
 %setup -q -n HTML-FormatText-WithLinks-%{version}
 
-
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
-
+%{__perl} Build.PL installdirs=vendor
+./Build
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
 
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
 
-%check
-make test
+%{_fixperms} $RPM_BUILD_ROOT/*
 
+%check
+./Build test
 
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-
 %files
 %defattr(-,root,root,-)
-%doc Changes README
+%doc Changes examples README
 %{perl_vendorlib}/*
-%{_mandir}/man3/*.3*
-
+%{_mandir}/man3/*
 
 %changelog
-* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.14-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
-
-* Thu Jun 21 2012 Petr Pisar ppi...@redhat.com - 0.14-5
-- Perl 5.16 rebuild
-
-* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.14-4
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
-
-* Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.14-3
-- Perl mass rebuild
-
-* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.14-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
-* Mon Dec 13 2010 Petr Sabata psab...@redhat.com - 0.14-1
-- 0.14 bump
-
-* Thu Dec  2 2010 Petr Sabata psab...@redhat.com - 0.12-1
-- 0.12 bump
-
-* Wed Sep 15 2010 Petr Pisar ppi...@redhat.com - 0.11-1
-- 0.11 bump
-
-* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-8
-- Mass rebuild with perl-5.12.0
-
-* Mon Dec  7 2009 Stepan Kasal ska...@redhat.com - 0.09-7
-- rebuild against perl 5.10.1
-
-* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.09-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.09-5
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.09-4
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Fri Jul 11 2008 Tom spot Callaway tcall...@redhat.com - 0.09-3
-- fix license

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Ralf Corsepius


On 04/03/2014 06:22 PM, Matthew Miller wrote:

On Thu, Apr 03, 2014 at 06:09:43PM +0200, Ralf Corsepius wrote:

You didn't mention the most important question:

Did the API or ABI change in backward-incompatible way?

If the answer to this question is yes, then the answer to updating
to gnome-3.12 needs to be no, because such changes in released
versions of Fedora are not allowed.


I think we should ground the discussion in the actual policy, which doesn't
say that, but does say ABI changes in general are very strongly discouraged
and Avoid Major version updates, ABI breakage or API changes if at all
possible. That is significantly more qualifed. And more to the point, it
says

Some classes of software will not fit in these guidelines. If your
package does not fit in one of the classes below, but you think it should
be allowed to update more rapidly, propose a new exception class to FESCO
and/or request an exception for your specific update case.

Note that you should open this dialog BEFORE you build or push updates.


You should take the spirit behind this into account:

ABI/API breakages are bad and should be avoided, unless they are 
inevitable, because they break and disturb user installations.



which is exactly what is happening here.


That's why I am asking. I want Mr. Clasen or somebody else from Gnome to 
provide a clear answer. So far, as I perceive Mr. Clasen, he 
deliberately avoided to answer.



http://fedoraproject.org/wiki/Updates_Policy

Now, in reading that policy, there are quite a few things that match the
Things that would make it less likely to grant a request list. But, on the
other hand, by having a longer-than-typical Fedora release cycle this time
around, we are already in special circumstances territory.


Ralf

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

Re: Reinstalling the bootloader

On Apr 3, 2014 7:18 PM, Reindl Harald h.rei...@thelounge.net wrote:



 Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
  Once upon a time (Fedora 15? -- I've lost track), it was possible to 
  reinstall the bootloader using grub-install.

 besides that it is the wrong list:

What's the right list?

 grub2-install

$ grub2-install
/usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1.
Check your device.map.

This is with efi.  WTF is a GRUB drive?  Will this set up the boot
menu in anything resembling a sensible manner?  (I doubt it, since I
don't consider having kernel entries listed in the ESP to be sensible,
but that's a separate issue.)  Will it set up EFI boot manager
entries?  Is the efibootmgr program usable by mortals?

For non-EFI, I have to do some i386-pc crap.  At least I think I have
some idea how that's supposed to work.

FWIW, the last time I got grub2-mkconfig to work, it generated a
config that, strictly speaking, functioned, but it spewed warnings
every time I booted.  That was a while ago.


  Nowadays it's a clusterfsck.  I've managed to screw up my bootloader.  Is 
  there a way to reinstall it without
  reinstalling the world?  Would it make sense to split the whole bootloader 
  thing out of Anaconda such that it would
  be possible to re-run it?  I can access my install just fine using chroot.
 
  FWIW, the same question applies to upgrading the bootloader.  Somehow I'm 
  on Fedora 20 using grub 0.97

 how comes? grub2 took over with F16 or F17


Upgrades.

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

Self Introduction: Michael McCune

2014-04-03 Thread Michael McCune

hi all,

I'm writing today because I have just submitted my first package for review, 
huzzah!

My name is Michael McCune and I am a newly minted associate at Red Hat. I have 
been a software developer for just shy of 20 years, doing most of my work in 
the embedded realm of automotive GPS devices. Within the last 7-8 years I have 
started to do an increasing amount of work building virtual machine 
infrastructures and coding higher up the stack than the C code of the embedded 
world. I have had a long term interest with Linux and have wanted to become 
more involved with the community since I helped bring a custom kernel and open 
source based root filesystem to the last two products I was involved with. The 
last month or so has been a whirlwind experience for me, and a dream come true.

Hopefully I have dotted my i's and crossed my t's with this initial package 
request. I am, of course, looking for a sponsor.

https://bugzilla.redhat.com/show_bug.cgi?id=1084246 is the review I am 
submitting. This review is not only a version upgrade but a rename as well.

hope to hear from you all soon,
mike
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Michael Catanzaro

On Thu, 2014-04-03 at 23:00 +0530, Gerard Ryan wrote:
 From what I remember, videos directly in my home directory were
 displayed as thumbnails on the main window and they would play fine.
 If I tried to add/open a local video from another location (even
 subdirectory of my home) by clicking on the + at the corner, nothing
 happened. I wasn't given an open file dialog or anything like that.
 
 As I said, it may not actually still be a problem. Maybe someone else
 can verify?

Hey Gerard,

This looks like https://bugzilla.gnome.org/show_bug.cgi?id=725063


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

2014-04-03 Thread Ankur Sinha

On Thu, 2014-04-03 at 18:08 -0700, Andrew Lutomirski wrote:
 Once upon a time (Fedora 15? -- I've lost track), it was possible to
 reinstall the bootloader using grub-install.

Just wondering if you've read this page yet:

https://fedoraproject.org/wiki/GRUB_2?rd=Grub2

-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Diagrams and images used in documentation

2014-04-03 Thread William Brown

Hi,

What is the software that is used to make images like :

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png

Or 

http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png

I haven't been able to find references to this, but would like to be
able to use this style of images in my own documentation.

-- 
William Brown will...@firstyear.id.au


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

On Thu, Apr 3, 2014 at 8:09 PM, Ankur Sinha sanjay.an...@gmail.com wrote:
 On Thu, 2014-04-03 at 18:08 -0700, Andrew Lutomirski wrote:
 Once upon a time (Fedora 15? -- I've lost track), it was possible to
 reinstall the bootloader using grub-install.

 Just wondering if you've read this page yet:

 https://fedoraproject.org/wiki/GRUB_2?rd=Grub2

I did, but this:

This is an untested write-up from memory and guessing - be careful

didn't inspire much confidence.

--Andy


 --
 Thanks,
 Warm regards,
 Ankur (FranciscoD)

 http://fedoraproject.org/wiki/User:Ankursinha

 Join Fedora! Come talk to us!
 http://fedoraproject.org/wiki/Fedora_Join_SIG


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

Re: Considering GNOME 3.12 as an F20 update

2014-04-03 Thread Rex Dieter

Matthias Clasen wrote:
 
 so the time has come to consider this - thanks to the great work of
 Richard and Kalev on the copr, we have a set of 3.12 packages that have
 already received fairly wide testing.

I'll share here what I mentioned on desktop list...

The gnome-3.12 copr includes a couple of low-level package updates that 
change abi/api that affects other desktops, notably:
upower-0.99
PackageKit-0.9.x

Are these 2 required by gnome-3.12 or would it be possible to use the 
(current) f20 versions?  

If required, then some extra work will be required (particularly for upower) 
to minimize the chances of breakage outside of gnome.

One example, I'm not entirely sure if cinnamon-settings-daemon is fully 
ready yet, see also
https://bugzilla.redhat.com/show_bug.cgi?id=1048276

-- Rex


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

Re: Diagrams and images used in documentation

2014-04-03 Thread Pete Travis

On Apr 3, 2014 9:27 PM, William Brown will...@firstyear.id.au wrote:

 Hi,

 What is the software that is used to make images like :


http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png

 Or


http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png

 I haven't been able to find references to this, but would like to be
 able to use this style of images in my own documentation.

 --
 William Brown will...@firstyear.id.au

 --


Didn't want to cross post, but I've passed this on to the Docs list.

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

Re: Diagrams and images used in documentation

2014-04-03 Thread Kushal Das

On Fri, Apr 4, 2014 at 8:57 AM, William Brown will...@firstyear.id.au wrote:
 Hi,

 What is the software that is used to make images like :

 http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png

 Or

 http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png

 I haven't been able to find references to this, but would like to be
 able to use this style of images in my own documentation.

It is called Inkscape [1].

[1] http://inkscape.org/en/

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

Re: Diagrams and images used in documentation

2014-04-03 Thread Suchakra

Libreoffice Draw works just fine too in some simpler cases. Inkscape
however is more comprehensive. Libreoffice Draw can export in svg
format also so that your graphic can later on be edited/enhanced in
Inkscape.

--
Suchakra

On Fri, Apr 4, 2014 at 1:11 AM, Kushal Das kushal...@gmail.com wrote:
 On Fri, Apr 4, 2014 at 8:57 AM, William Brown will...@firstyear.id.au wrote:
 Hi,

 What is the software that is used to make images like :

 http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png

 Or

 http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png

 I haven't been able to find references to this, but would like to be
 able to use this style of images in my own documentation.

 It is called Inkscape [1].

 [1] http://inkscape.org/en/

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

[Bug 1083915] New: perl-CPAN-Checksums-2.08-8.fc21 FTBFS in non-koji mock

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

Bug ID: 1083915
   Summary: perl-CPAN-Checksums-2.08-8.fc21 FTBFS in non-koji mock
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN-Checksums
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
   External Bug ID: CPAN 94397



Non-koji mock allows DNS resolution, but forbids network connections. This
causes a test to fail:

+ make test
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -MTest::Harness
-e
 undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')
t/*.
t
gpg: new configuration file `/builddir/.gnupg/gpg.conf' created
gpg: WARNING: options in `/builddir/.gnupg/gpg.conf' are not yet active during
t
his run
gpgkeys: HTTP fetch error 7: Failed to connect to pool.sks-keyservers.net port
1
1371: Network is unreachable
gpg: Signature made Tue Aug 30 08:30:20 2011 CEST using DSA key ID A317C15D
gpg: requesting key A317C15D from hkp server pool.sks-keyservers.net
gpg: no valid OpenPGP data found.
gpg: Can't check signature: public key not found
== BAD/TAMPERED signature detected! ==
t/00signature.t .. 
Failed 1/1 subtests 

This is causes by insufficient skip-test condition in t/00signature.t.

Reported to upstream https://rt.cpan.org/Public/Bug/Display.html?id=94397
with proposed fix.

-- 
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=1b68frENYIa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1083915] perl-CPAN-Checksums-2.08-8.fc21 FTBFS in non-koji mock

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
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=u3ctm47krIa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-CPAN-Checksums] Fix test skip-condition to pass in mock

2014-04-03 Thread Petr Pisar

commit 2f5171ebe57317144913e65115ad3082b3089106
Author: Petr Písař ppi...@redhat.com
Date:   Thu Apr 3 09:13:12 2014 +0200

Fix test skip-condition to pass in mock

 CPAN-Checksums-2.08-New-signature.patch|   61 
 ...Try-to-connect-to-pool.sks-keyservers.net.patch |   45 ++
 perl-CPAN-Checksums.spec   |   11 +++-
 3 files changed, 116 insertions(+), 1 deletions(-)
---
diff --git a/CPAN-Checksums-2.08-New-signature.patch 
b/CPAN-Checksums-2.08-New-signature.patch
new file mode 100644
index 000..d5524fb
--- /dev/null
+++ b/CPAN-Checksums-2.08-New-signature.patch
@@ -0,0 +1,61 @@
+From 6d03608c83e9ac68492ab03a208cc1499d7af96b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Thu, 3 Apr 2014 11:16:26 +0200
+Subject: [PATCH] New signature
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This resigns 2.08 with CPAN RT #94397 patch.
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ SIGNATURE | 14 +++---
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/SIGNATURE b/SIGNATURE
+index 23272c4..627fae8 100644
+--- a/SIGNATURE
 b/SIGNATURE
+@@ -1,5 +1,5 @@
+ This file contains message digests of all files listed in MANIFEST,
+-signed via the Module::Signature module, version 0.68.
++signed via the Module::Signature module, version 0.73.
+ 
+ To verify the content in this distribution, first make sure you have
+ Module::Signature installed, then type:
+@@ -12,7 +12,7 @@ the distribution may already have been compromised, and you 
should
+ not run its Makefile.PL or Build.PL.
+ 
+ -BEGIN PGP SIGNED MESSAGE-
+-Hash: SHA1
++Hash: SHA256
+ 
+ SHA1 6587f782cbd9cb71036f2e2492ca3daa389521c3 MANIFEST
+ SHA1 1c21142a9af69d1da5c027b924b8b0c052beb1da MANIFEST.SKIP
+@@ -22,7 +22,7 @@ SHA1 98d4acdec8e5b42574f8f32f453c0c0933fa569f Makefile.PL
+ SHA1 378ba4b97d5a989790877de0214ca23ac5aeef37 README
+ SHA1 b929ff9f01730419548cab2dfcc30003b49fbbfb Todo
+ SHA1 b8158703f7dbb962c56a07183b375a766951e4f1 lib/CPAN/Checksums.pm
+-SHA1 8091e870af6f081607bab636ab1e8fcfa18b12be t/00signature.t
++SHA1 89bb8f97f25483d5f618e6a63d2a4361ed0bb84c t/00signature.t
+ SHA1 51e1c061bc02e9a38948a5d8e3ca7352830f0fac t/42.gz
+ SHA1 23e182506f4b883d8aae3d29d08e044c55b04deb t/43
+ SHA1 0d942b3ef6791694fde4693d3329a0ff924cb583 t/44.bz2
+@@ -31,9 +31,9 @@ SHA1 2d74a36030efca3a42026e2ceab6837c052e8a53 t/CHECKSUMS
+ SHA1 6a79f15a10337bd3450604abf39d4462df2a550b t/pod.t
+ SHA1 3a73818d40fce12a21bf9d4d2c38ee2145cc0628 t/updatedir.t
+ -BEGIN PGP SIGNATURE-
+-Version: GnuPG v1.4.11 (GNU/Linux)
++Version: GnuPG v2.0.22 (GNU/Linux)
+ 
+-iEYEARECAAYFAk5cg3wACgkQ7IA58KMXwV0uzQCfc/vBboe7anyS25qj+zBglXSv
+-gJkAn2f3uvbHfXjdSN/XXNvss5YLH1Yc
+-=snWE
++iF4EAREIAAYFAlM9KBsACgkQEsnFx2fG+qLnuwD9Ekd3QDUjoSTbmrL4/UMZvNFa
++J6Zdq6cawLqWI6L6PZcA/3s0NjLsWiwVTvb7ddsuYnGldjSF1JFFSs3lyTBYXnZG
++=I43x
+ -END PGP SIGNATURE-
+-- 
+1.9.0
+
diff --git 
a/CPAN-Checksums-2.08-Try-to-connect-to-pool.sks-keyservers.net.patch 
b/CPAN-Checksums-2.08-Try-to-connect-to-pool.sks-keyservers.net.patch
new file mode 100644
index 000..b7c7711
--- /dev/null
+++ b/CPAN-Checksums-2.08-Try-to-connect-to-pool.sks-keyservers.net.patch
@@ -0,0 +1,45 @@
+From 341641c72e5c102b37bdaf349cb718f086e0e9c5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Thu, 3 Apr 2014 09:07:29 +0200
+Subject: [PATCH] Try to connect to pool.sks-keyservers.net
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+t/00signature.t fails if pool.sks-keyservers.net can be resolved, but
+you cannot connect to it. This patch augments the Cannot connect to
+the keyserver precheck to do real TCP connect.
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ t/00signature.t | 14 +-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/t/00signature.t b/t/00signature.t
+index c7da469..75ae6d4 100644
+--- a/t/00signature.t
 b/t/00signature.t
+@@ -49,7 +49,19 @@ BEGIN {
+ }
+ }
+ unless ($exit_message) {
+-if (!eval { require Socket; 
Socket::inet_aton('pool.sks-keyservers.net') }) {
++if (!eval {
++use Socket qw(AF_INET SOCK_STREAM pack_sockaddr_in inet_aton);
++my $socket;
++socket($socket, AF_INET, SOCK_STREAM, 0) and
++connect(
++$socket,
++pack_sockaddr_in(
++scalar getservbyname('hkp', 'tcp'),
++inet_aton('pool.sks-keyservers.net')
++)
++) and
++close($socket)
++}) {
+ $exit_message = Cannot connect to the keyserver;
+ }
+ }
+-- 
+1.9.0
+
diff --git a/perl-CPAN-Checksums.spec b/perl-CPAN-Checksums.spec
index 192c0b2..da35a14 100644
---

[Bug 1083960] New: perl-autodie-2.25 is available

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

Bug ID: 1083960
   Summary: perl-autodie-2.25 is available
   Product: Fedora
   Version: rawhide
 Component: perl-autodie
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 2.25
Current version/release in Fedora Rawhide: 2.24-1.fc21
URL: http://search.cpan.org/dist/autodie/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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=ynYezuc623a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1083961] New: perl-Carp-1.3301 is available

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

Bug ID: 1083961
   Summary: perl-Carp-1.3301 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Carp
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.3301
Current version/release in Fedora Rawhide: 1.33-1.fc21
URL: http://search.cpan.org/dist/Carp/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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=bjM150WSNga=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1083964] New: perl-File-MimeInfo-0.24 is available