date:20140403

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

Petr Pisar  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=BdpW4XNO4N&a=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 :

> 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=WvI6OXYlrB&a=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  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=LDR8Qu0YuB&a=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  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  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  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 
>   Reply-To:
> Development discussions related to Fedora 
>   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  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 :

> 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  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 
-- 
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 :
> > 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"
 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=5yuerY1C89&a=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--
  "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--
  "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  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 :

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

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--
  "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 :

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

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

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

will that below ever get fixed in F20?
should i file a bug against the distribution?
should i file a bug against Red Hat as upstream employer?

and if someone asks why i called Lennart in #1072368
names - because over weeks nobody cared and after i
asked again on this list within 5 minutes Lennarts first
reaction within 5 minutes was close the bugreport because
he decides what is OK for users and don't care that about
different worksloads

in that context 2 links with a quote of Linus 100% matching:
>> 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.

https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF
http://www.spinics.net/lists/kernel/msg1716484.html


https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1010572
https://bugzilla.redhat.com/show_bug.cgi?id=626477
https://bugzilla.redhat.com/show_bug.cgi?id=1047148
https://bugzilla.redhat.com/show_bug.cgi?id=1024379



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

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--
  "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  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  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  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 wrote:

>
> 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  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  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  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  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  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  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  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--
  "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  wrote:

> On 3 April 2014 20:00, Adam Jackson  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
 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 
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  
- 0.14-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
-
-* Thu Jun 21 2012 Petr Pisar  - 0.14-5
-- Perl 5.16 rebuild
-
-* Fri Jan 13 2012 Fedora Release Engineering  
- 0.14-4
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
-
-* Wed Jul 20 2011 Petr Sabata  - 0.14-3
-- Perl mass rebuild
-
-* Tue Feb 08 2011 Fedora Release Engineering  
- 0.14-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
-* Mon Dec 13 2010 Petr Sabata  - 0.14-1
-- 0.14 bump
-
-* Thu Dec  2 2010 Petr Sabata  - 0.12-1
-- 0.12 bump
-
-* Wed Sep 15 2010 Petr Pisar  - 0.11-1
-- 0.11 bump
-
-* Sun May 02 2010 Marcela Maslanova  - 0.09-8
-- Mass rebuild with perl-5.12.0
-
-* Mon Dec  7 2009 Stepan Kasal  - 0.09-7
-- rebuild against perl 5.10.1
-
-* Sat Jul 25 2009 Fedora Release Engineering  
- 0.09-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering  
- 0.09-5
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering  
- 0.09-4
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Fri Jul 11 2008 Tom "spot" Callaway  - 0.09-3
-- fix license tag (it may be correct, but its flagging as a false positive on 
checks)
-
-* Thu Mar 06 2008 Tom "spot" Callaway  - 0.09-2
-- Rebuild for new perl
-
-* Wed Aug  8 2007 Patrice Dumas  0.09-1
-- update to 0.09
-
-* Sun Sep 17 2006 Patrice Dumas  0.07-1
-- update to 0.07
-
-* Fri Sep 15 2006 Patrice Dumas  0.06-3
-- add Requires for perl(

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.





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"  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 


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