Re: F21 System Wide Change: Workstation: Disable firewall

[Igor Gnatenko]

On Apr 15, 2014 1:02 PM, "Jaroslav Reznik"  wrote:
>
> = Proposed System Wide Change: Workstation: Disable firewall =
> https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall
>
> Change owner(s): Matthias Clasen 
>
> The firewalld service will not be enabled by default in the workstation
> product.
>
> == Detailed Description ==
> The current level of integration into the desktop and applications does
not
> justify enabling the firewalld service by default. Additionally, the set
of
> zones that we currently expose is excessive and not user-friendly.
Therefore,
> we will disable the firewall service while we are working on a more user-
> friendly way to deal with network-related privacy issues.
>
> It will of course still be possible to enable the firewall manually.
>
> == Scope ==
> * Proposal owners/Other developers: Add a Workstation-specific service
> configuration (preset ?) to the firewalld package that disables firewalld
for
> the Workstation product
> * Release engineering: No action required
> * Policies and guidelines: No action required
>
Probably we should write something like setroubleshoot?
It will scan listen ports and with oneclick provide "open" "ignore", etc.
-- 
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: Workstation: Disable firewall

[William]

> On 17 Apr 2014, at 2:26, Thomas Woerner  wrote:
> 
>> On 04/16/2014 06:43 PM, Tomasz Torcz wrote:
>> On Wed, Apr 16, 2014 at 12:32:02PM -0400, Simo Sorce wrote:
> I think what you are describing could be probably realized with SELinux
> today, just with a special setroubleshoot frontend that catches the AVC
> when the service tries to listen and ask the user if he wants to allow
> it.
> 
> However this would still not be completely sufficient as you completely
> lack any context about what network you are operating on.
> 
> The firewall's purpose is to block access to local services on bad
> networks too, it is not a binary open/close equation when you have
> machines (laptops) that roam across a variety of networks.
> 
> Simo.
 Nothing worse then asking Users Security related questions about opening
 firewall ports.
 Users will just answer yes, whether or not they are being hacked.
 
 firefox wants to listen on port 9900 in order to see this page, OK?
>>> 
>>> 
>>> Which is not what I proposed Dan.
>>> 
>>> I in fact said we should *NOT* ask per application.
>>> 
>>> What we should ask is one single question, upon connecting to an unknown
>>> network: "Is this network trusted ?"
>>> 
>>> If yes you open up to the local network. If no you keep ports not
>>> accessible on that network.
>> 
>>   But firewalld currently lacks flexibility to express this fully.
>> Firewalld only classifies ”whole” interfaces, which breaks badly in
>> many situations.  Consider following scenario:  VM with single
>> network interface.  This single interface has RFC1918 IPv4 address AND
>> globally accesible IPv6 address.  How it should be described
>> in firewalld?
> firewalld supports to have rules for IPv4 and/or IPv6.
> 
>>   – for any IPv4 incoming connection, this interface is in ”trusted” (”home”?
>> I never know what home/work/dmz/etc really mean)
> You can full customize all zones. This is the reason there is no simple 
> description for each zone.
> 
>>   – for IPv6 incoming connection from 2001:6a0:138:1::/64 subnet, the zone
>> is still ”trusted”
>>   – for any other incoming connection the zone is ”public” (I hope this
>> means ”general Internet”).
>> 
>>   Above is trivial in iptables, but impossible with firewalld's zones.
> firewalld also has the ability to bind zones to source addresses and address 
> ranges. This might help here.

You should define the trust based on the current subnet?

Also links to documentation on this please for source binding
-- 
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: Workstation: Disable firewall

[William]

> On 18 Apr 2014, at 7:37, Mattia Verga  wrote:
> 
> +1
> 
> Can't UPnP be used also for opening ports in iptables firewall (maybe 
> developing some tools for that)?

Upnp is almost always abused. Please don't use it. 


> 
> Il 15/04/2014 15:42, Simone Caronni ha scritto:
>>> On 15 April 2014 14:35, Christopher  wrote:
>>> Whoa, the fact that the Firewall is on by default in Fedora (along
>>> with SELinux) is one of the reasons I choose Fedora over alternatives.
>> 
>> Same thing here, It was really surprising to see it as a proposed feature.
>> How can it be that after years we are disabling the firewall by default?
>> I personally find it a big, big step backwards.
>> 
>> Instead of disabiling it, wouldn't be a better approach to have a more 
>> relaxed firewall policy for the workstation product that opens the 
>> additional ports for DAAP, UPnp, etc.?
>> 
>> Regards,
>> --Simone
>> 
>> 
>> -- 
>> You cannot discover new oceans unless you have the courage to lose sight of 
>> the shore (R. W. Emerson).
>> 
>> http://xkcd.com/229/
>> http://negativo17.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
-- 
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: Workstation: Disable firewall

[Mattia Verga]

+1

Can't UPnP be used also for opening ports in iptables firewall (maybe 
developing some tools for that)?


Il 15/04/2014 15:42, Simone Caronni ha scritto:
On 15 April 2014 14:35, Christopher > wrote:


Whoa, the fact that the Firewall is on by default in Fedora (along
with SELinux) is one of the reasons I choose Fedora over alternatives.


Same thing here, It was really surprising to see it as a proposed feature.
How can it be that after years we are disabling the firewall by default?
I personally find it a big, big step backwards.

Instead of disabiling it, wouldn't be a better approach to have a more 
relaxed firewall policy for the workstation product that opens the 
additional ports for DAAP, UPnp, etc.?


Regards,
--Simone


--
You cannot discover new oceans unless you have the courage to lose 
sight of the shore (R. W. Emerson).


http://xkcd.com/229/
http://negativo17.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: F21 System Wide Change: Workstation: Disable firewall

[Miloslav Trmač]

2014-04-17 23:51 GMT+02:00 Chuck Anderson :

> > To be perfectly clear, vast majority of network applications work
> perfectly
> > fine.  Network *servers* need manual intervention.
>
> Not just servers.  Clients that do broadcast or multicast discovery of
> other systems acting as servers can also fail with a firewall enabled.
> The classic case is SMB browsing.
>

Sorry, you're right.  I was thinking of an idealized
"outgoing-connections-only" firewall as opposed to the defaults we actually
have.
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: F21 System Wide Change: Workstation: Disable firewall

[Chuck Anderson]

On Thu, Apr 17, 2014 at 11:42:30PM +0200, Miloslav Trmač wrote:
> Hello,
> 2014-04-16 14:28 GMT+02:00 Josh Boyer :
> 
> > For a quick summary:
> >
> > 1) With a firewall enabled, network services don't work without manual
> > intervention.
> >
> 
> To be perfectly clear, vast majority of network applications work perfectly
> fine.  Network *servers* need manual intervention.

Not just servers.  Clients that do broadcast or multicast discovery of
other systems acting as servers can also fail with a firewall enabled.
The classic case is SMB browsing.
-- 
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 Self Contained Change: Remote Journal Logging

[Miloslav Trmač]

2014-04-17 23:34 GMT+02:00 Zbigniew Jędrzejewski-Szmek :

> On Thu, Apr 17, 2014 at 10:17:28PM +0200, Miloslav Trmač wrote:
> > 2014-04-16 19:08 GMT+02:00 Chris Adams :
> >
> > > It would be good if systemd could
> > > use or extend an existing logging protocol, rather than invent yet
> > > another method.
> > >
> >
> > Yes.  Going by the feature page and from what I can see from
> > journal-remote.c, because Transfer-Encoding: chunked does not require
> > application-level acknowledgment from the recipient, and there is no
> other
> > mechanism to synchronize state, the proposed use of HTTP will be *losing
> > data*!
> There's another mechanism to synchronize state: the server replies with
> 202 accepted after it has successfully parsed and saved the transmission to
> disk. The client can send each journal entry as a single POST upload
> (using the same connection, so it's not terrible inefficient).
>

Sure, single POST per entry, or even per batch, would work (AFAICS
equivalently with a 200 OK)—note that the data really needs to be on disk
before the acknowledgment is sent.
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: F21 Self Contained Change: Remote Journal Logging

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 17, 2014 at 10:12:24PM +0200, Miloslav Trmač wrote:
> Hello,
> 2014-04-16 15:04 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> 
> > I'll reconsider using SASL instead. I have the HTTPS-transport version
> > almost ready, so for now I'll go with that, to have a working
> > solution. There's still some other questions, mostly related to how
> > the data should be stored on the receiver, so I want to get it out for
> > people to test. The underlying transport is an implementation detail,
> > mostly visible in the way that authentication is done, so a new
> > transport can be added, and the old one deprecated or even removed.
> >
> 
> After this first ships in a product, that's not how networks work;
> protocols, once defined, are pretty much forever—or, well, until users'
> setups are broken and users are unhappy.
> Mirek
It was an error on my part: I should have added a few big fat warnings
that this code (and protocol) is not yet ready for general consumption.
I'll add that now... I'd be pretty hard for anyone to use it so far, since
the client part is missing.

Zbyszek
-- 
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: Workstation: Disable firewall

[Miloslav Trmač]

Hello,
2014-04-15 16:28 GMT+02:00 Christian Schaller :

> - Original Message -
> > From: "Reindl Harald" 
> > To: devel@lists.fedoraproject.org
> > Sent: Tuesday, April 15, 2014 11:40:20 AM
> > Subject: Re: F21 System Wide Change: Workstation: Disable firewall
> >
> >
> > Am 15.04.2014 11:32, schrieb drago01:
> > > On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald <
> h.rei...@thelounge.net>
> > > wrote:
>
> > allow any random application to open a unprivlieged
> > port which is reachable from outside is dangerous
> >
> We already allow that and have for a long while. Any application bothering
> to support the firewalld dbus interface can open any port
> they wish to.
>

We don't, actually.  *Only* applications running in a session of a member
of the wheel group would have that right, and those applications are pretty
much root-equivalent anyway.  (Many GNOME users probably use such a setup,
but it's not at all the only one possible.)

The thread discussing this ended up with mostly being a discussion if the
> firewall would be a useful way to help users from accidentally
> oversharing on a public network. Which is important and something we want
> to work on, but a lot less so than security issues.
>

"Oversharing on a public network" *absolutely is a security issue*.
Heartbleed is exactly that, "oversharing" and nothing more!
 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: F21 System Wide Change: Workstation: Disable firewall

[Miloslav Trmač]

Hello,
2014-04-15 11:01 GMT+02:00 Jaroslav Reznik :

> = Proposed System Wide Change: Workstation: Disable firewall =
> https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall
>
> == Detailed Description ==
> The current level of integration into the desktop and applications does not
> justify enabling the firewalld service by default.


This line of argument doesn't make any sense to me.  Enabling a firewall is
justified by *needing a firewall*, not any kind, or level, of integration
into other software.


Therefore,
> we will disable the firewall service while we are working on a more user-
> friendly way to deal with network-related privacy issues.
>

(combined with...)

== Benefit to Fedora ==
> The Workstation will boot faster, and the firewall will not interfere with
> sharing protocols such as DAAP, UPnP and others.
>

So this actually means "we will disable the firewall, *explicitly intending
to allow exposing user's data over DAAP and the like*", *now*, and "be
working on... the privacy issues" [not as a part of this Change], i.e.
*later*?

I do hope I'm misunderstanding the proposal, because this reads like a *highly
irresponsible* and *completely unacceptable* transition plan.  If the users
needs to share data and have control over whether/how it is shared, we
just can't take away that control now, and promise to return it sometime
later[1].

(I could actually see a good case for not having a restrictive firewall on
the Workstation by default, assuming some conditions were met; but if
the *explicit
intent* is to give up on users' control over their data like that, there's
really no point in discussing the detailed requirements because the
underlying intent is unacceptable and needs to be revisited.)
Mirek

[1] Actually, we can't even credibly promise to return it later—if we
haven't had time or interest to develop the better controls now, why should
the users trust us that we'll develop them later when without the firewall
"things work correctly for the intended use case" and the work on better
firewall integration is now even less urgent?
-- 
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-Cpanel-JSON-XS] Update to 3.0102

[Paul Howarth]

commit 2ae1fcb26cb2f79f9edee422d088163effcf8e69
Author: Paul Howarth 
Date:   Thu Apr 17 22:42:15 2014 +0100

Update to 3.0102

- New upstream release 3.0102
  - Added PERL_NO_GET_CONTEXT for better performance on threaded Perls
  - MANIFEST: added t/96_interop.t
  - Document deprecated functions
  - Change booleans interop logic for JSON-XS-3.01
- Enable CLZF support via Compress::LZF

 Cpanel-JSON-XS-2.3404-no-clzf.patch |   37 ---
 perl-Cpanel-JSON-XS.spec|   23 -
 sources |2 +-
 3 files changed, 14 insertions(+), 48 deletions(-)
---
diff --git a/perl-Cpanel-JSON-XS.spec b/perl-Cpanel-JSON-XS.spec
index 8a8d86c..df954da 100644
--- a/perl-Cpanel-JSON-XS.spec
+++ b/perl-Cpanel-JSON-XS.spec
@@ -1,14 +1,10 @@
-# Note: Compress::LZF format support has been disabled until such
-# time as the Compress::LZF module becomes available in Fedora (#1074129)
-
 Name:  perl-Cpanel-JSON-XS
 Summary:   JSON::XS for Cpanel, fast and correct serializing
-Version:   3.0101
+Version:   3.0102
 Release:   1%{?dist}
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/Cpanel-JSON-XS/
 Source0:   
http://search.cpan.org/CPAN/authors/id/R/RU/RURBAN/Cpanel-JSON-XS-%{version}.tar.gz
-Patch0:Cpanel-JSON-XS-2.3404-no-clzf.patch
 # Module Build
 BuildRequires: perl
 BuildRequires: perl(ExtUtils::MakeMaker)
@@ -18,7 +14,7 @@ BuildRequires:perl(Exporter)
 BuildRequires: perl(overload)
 BuildRequires: perl(XSLoader)
 # Script Runtime
-#BuildRequires:perl(Compress::LZF)
+BuildRequires: perl(Compress::LZF)
 BuildRequires: perl(Convert::Bencode)
 BuildRequires: perl(Data::Dump)
 BuildRequires: perl(YAML)
@@ -28,6 +24,8 @@ BuildRequires:perl(Config)
 BuildRequires: perl(Data::Dumper)
 BuildRequires: perl(Encode) >= 1.9081
 BuildRequires: perl(Hash::Util)
+BuildRequires: perl(JSON)
+BuildRequires: perl(JSON::XS)
 BuildRequires: perl(strict)
 BuildRequires: perl(Test)
 BuildRequires: perl(Test::More)
@@ -46,7 +44,7 @@ BuildRequires:perl(Test::Pod::Coverage) >= 1.04
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:  perl(Carp)
-#Requires: perl(Compress::LZF)
+Requires:  perl(Compress::LZF)
 Requires:  perl(Convert::Bencode)
 Requires:  perl(Data::Dump)
 Requires:  perl(YAML)
@@ -62,9 +60,6 @@ reach the latter goal it was written in C.
 %prep
 %setup -q -n Cpanel-JSON-XS-%{version}
 
-# Drop CLZF support for now
-%patch0 -p1
-
 # Fix shellbangs
 perl -pi -e 's|^#!/opt/bin/perl|#!/usr/bin/perl|' eg/*
 
@@ -95,6 +90,14 @@ make test IS_MAINTAINER=1 RELEASE_TESTING=1
 %{_mandir}/man3/Cpanel::JSON::XS::Boolean.3pm*
 
 %changelog
+* Thu Apr 17 2014 Paul Howarth  - 3.0102-1
+- Update to 3.0102
+  - Added PERL_NO_GET_CONTEXT for better performance on threaded Perls
+  - MANIFEST: added t/96_interop.t
+  - Document deprecated functions
+  - Change booleans interop logic for JSON-XS-3.01
+- Enable CLZF support via Compress::LZF
+
 * Wed Apr 16 2014 Paul Howarth  - 3.0101-1
 - Update to 3.0101
   - Added ithreads support: Cpanel::JSON::XS is now thread-safe
diff --git a/sources b/sources
index bf7ef08..fac63e9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-622895d23ff710f837a6e82953e15819  Cpanel-JSON-XS-3.0101.tar.gz
+06398ad4ea8d02d0fe8323cad811b703  Cpanel-JSON-XS-3.0102.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F21 System Wide Change: Workstation: Disable firewall

[Miloslav Trmač]

Hello,
2014-04-16 14:28 GMT+02:00 Josh Boyer :

> For a quick summary:
>
> 1) With a firewall enabled, network services don't work without manual
> intervention.
>

To be perfectly clear, vast majority of network applications work perfectly
fine.  Network *servers* need manual intervention.

2) With firewalld active, any privileged application can open a port
> in the firewall (and most will be privileged because they will be
> packaged that way.)
>

No; most applications are not packaged in any way to get extra privilege to
manage a firewall, and they *shouldn't*; applications poking holes in a
firewall for themselves is pointless cargo-cult nonsense.

Some *user accounts* (members of wheel) are set up to be sufficiently
privileged/root-equivalent so that they can open a port, but they really
*are* root-equivalent so the specifics of what they can do to the firewall
are not much relevant... at that point you really either trust all software
you run, or not.

There *could* be applications specifically dexigned to open a port in the
firewall even for unprivileged users (e.g. by having a separate privileged
helper talk to firewalld), I don't think there actually are any.

3) With no firewall enabled and no network services started, there is
> no security issue because there are no open ports.
>

There still are all the security issues with outgoing communication; in
particular, the browser does matter (much more than say portmap) and the
firewall cannot protect it.

4) With no firewall but active network services, you have open ports
> just as you would in the firewalld or manual intervention firewall
> case
>

No because 2) is false... or yes for the wheel-member users.
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: F21 Self Contained Change: Remote Journal Logging

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 17, 2014 at 10:17:28PM +0200, Miloslav Trmač wrote:
> 2014-04-16 19:08 GMT+02:00 Chris Adams :
> 
> > It would be good if systemd could
> > use or extend an existing logging protocol, rather than invent yet
> > another method.
> >
> 
> Yes.  Going by the feature page and from what I can see from
> journal-remote.c, because Transfer-Encoding: chunked does not require
> application-level acknowledgment from the recipient, and there is no other
> mechanism to synchronize state, the proposed use of HTTP will be *losing
> data*!
There's another mechanism to synchronize state: the server replies with
202 accepted after it has successfully parsed and saved the transmission to
disk. The client can send each journal entry as a single POST upload
(using the same connection, so it's not terrible inefficient).

Zbyszek
-- 
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: Workstation: Disable firewall

[Miloslav Trmač]

2014-04-16 1:28 GMT+02:00 Simo Sorce :

> if the users wants more flexibility then they would create new
> zones (like home, work, cafe, library, etc..) perhaps by cloning
> existing ones and then tweak the list of applications allowed to serve
> content in those zones.
> It would be better if the association were per-application rather then
> nameless ports.
>

firewalld has a concept of "services", so the port numbers don't need to,
and *shouldn't*, appear in UIs.  It still might make sense to discuss a
true per-*application* privileges (e.g. Empathy is allowed to listen on any
port), but only after we get reliable application isolation.
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: F21 System Wide Change: Workstation: Disable firewall

[Miloslav Trmač]

2014-04-15 22:49 GMT+02:00 Matthias Clasen :
(firewalld features)

> So, what you have currently is a raw bit of infrastructure that is
> directly exposed to the end user, without any design or integration.
>

That's *precisely* what the underlying infrastructure should do, isn't it?
It's up to the UI projects like GNOME or Cockpit to provide "design and
integration".

What I envision is that we will notify the user when we connect to a new
> network, with a message along the lines of:
>
> You have connected to an new network.


This might be a misunderstanding, so just to be explicit: As written,
that's too late.  This user's decisions must happen *before* any traffic is
possible and the user "has connected".
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: F21 System Wide Change: Workstation: Disable firewall

[Miloslav Trmač]

2014-04-15 18:13 GMT+02:00 Andrew Lutomirski :

> > Example: user installs software X... but oops, they didn't realize it
> > was going to listen on port Y but that's okay, because no firewall
> > rule has been enabled to allow traffic on port Y, so the user is
> > secure.
>
> This sounds like a problem that should be separately fixed.


Well, yes, but then *we really need to be 100% sure we have fixed it*.  See
also your own report that installing gnome-boxes pulls in running services
with open ports.


> With firewalls, a service, system or otherwise, can be in one of three
> states: a) listening w/ firewall open, b) listening w/ firewall
> closed, c) and not listening.
>
d) not listening, actively opening connections to the outside, and sending
users' private data over there, or receiving commands from there to send
arbitrary data.

Just so we are clear on the relative threat levels, malicious applications
(if you are lucky, "only collecting data for the purpose of advertising")
are so frequent nowadays that *they* are the primary threat of unwanted
network communication, perhaps comparable only to automated ssh password
guessing bots.  Linux has so far been "lucky" in not having enough
third-party applications for this to be a threat yet, but Workstation
intends that to change.  (And no, a firewall won't help you at all for d) ).

I keep thinking that, if I had unlimited time, I'd write a totally
> different kind of firewall.  It would allow some policy (userspace
> daemon or rules loaded into the kernel) to determine when programs can
> listen on what sockets and when connections can be accepted on those
> sockets.


Similarly, ports (what I assume you mean) are getting less and less
important nowadays.  So much happens multiplexed over HTTP, and there are
various "zero-config" browsing/advertising mechanisms that don't require
use of fixed ports, only the privilege to advertise a port through the
browsing mechanism.


> Wouldn't it be great if, when you start some program that wants to
> listen globally, your system could prompt you and ask whether it was
> okay, even if that program didn't know about firewalld?
>

In general (assuming "unknown software" and not just specific 3 services
that can be individually handled in control-center, or software
specifically adjusted by Fedora to know about firewalld), no.  I have no
idea what the program is going to send over that connection, so I don't
know how to answer, and the program can send the same data through an
outgoing connection without ever interacting with the restricted listening
functionality; I simply must trust the author of that program—or to prevent
the program from accessing my data at all, and then the answer doesn't
matter.
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: F21 System Wide Change: Workstation: Disable firewall

[Miloslav Trmač]

Hello,
Just some clarifications so that we are all on the same page; those don't
significantly affect the larger discussion though...

2014-04-15 17:40 GMT+02:00 Andrew Lutomirski :

> Can someone explain what threat is effectively mitigated by a firewall
> on a workstation machine?  Here are some bad answers:
>


>   - WebRTC, VOIP, etc. issues?  These use NAT traversal techniques that
> are specifically designed to prevent your firewall from operating as
> intended.
>

That's imprecise; NAT traversal techniques are designed to allow a
*specific* counterparty through the firewall, not everyone on the Internet
like disabling the firewall would do.

  - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible
> for these things to be off until specifically requested?

That would be about equivalent to controlling them only via a firewall.

>  Who actually
> uses a so-called "zone" UI correctly to configure them?


"Who actually uses any other UI correctly to configure sharing
zones?"—nobody because there apparently isn't any.  Firewalld has a zone
implementation that can be improved upon.

>  How about
> having an API where things like DLNA can simply not run until you're
> connected to your home network?
>

Firewalld has a zone implementation that can be improved upon.

Also, having a firewall on exposes you to a huge attack surface in
> iptables, and it doesn't protect against attacks targeting the
> kernel's IP stack.
>

*Nothing* will ever protect you against attacks targetting the kernel's IP
sack, that's a strawman.  And the entire premise of a firewall is that the
attack surface of the firewall (iptables in this case) is smaller than the
attack premise of applications behind; intuitively it's very likely to be
true, and AFAICT it's also been true historically.
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: F21 System Wide Change: Workstation: Disable firewall

[Miloslav Trmač]

2014-04-15 15:59 GMT+02:00 Michael Catanzaro :

> On Tue, 2014-04-15 at 14:35 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > What needs to be done to improve the firewall integration?
> >
> > Zbyszek
>
> The rule in the Workstation technical spec is: "A firewall in its
> default configuration may not interfere with the normal operation of
> programs installed by default." [1] There's a discussion on the desktop
> list beginning at [2] that has some brainstorming and explanation as to
> why this would be hard.
>
> [1]
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Firewall
>
> [2]
> https://lists.fedoraproject.org/pipermail/desktop/2014-February/009142.html
>

For the benefit of keeping everything on this list:

AFAICS this discussion basically says "applications can't depend on
firewalld, therefore they can't use firewalld APIs, therefore they wouldn't
know whether the firewall restircts them, therefore firewalld must be
removed".

The only given reason why the applications can't depend on firewalld is
vague claims that the D-Bus API is somehow unusable, which is clearly false
because firewall-cmd is using exactly the same API.
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: F21 System Wide Change: Smaller Cloud Image Footprint

[Miloslav Trmač]

2014-04-17 22:27 GMT+02:00 Miloslav Trmač :

> 2014-04-17 21:54 GMT+02:00 Matthew Miller :
>
> On Thu, Apr 17, 2014 at 09:47:21PM +0200, Miloslav Trmač wrote:
>> > > (NetworkManager and initscripts) and one that's available but not
>> used by
>> > > default anywhere (systemd-networkd). This would simply swap the
>> status of
>> > > systemd-networkd and initscripts.
>> > Is NetworkManager already at the *100% complete* feature parity that
>> would
>> > make this possible?  (Keeping in mind that "possible" and "a good idea"
>> are
>> > still not the same...)
>>
>> I don't think I accept your premise here. 100% (possibly spread between
>> networkd and NetworkManager) would be necessary for dropping initscripts
>> completely, but that's not being proposed.
>>
>
> You were arguing that we would be going from 2 used + 1 unused systems to
> a different set of 2 used + 1 unused; for that to happen, users of
> initscripts must have somewhere to migrate to.
>

Writing too fast... you were actually arguing for a situation "2 used by
default + 1 used but not used by default" I think.  In that case your
argument is right but it's my turn to not accept your premise :)  networkd
was introduced in systemd-209, and F20 ships with -208,  I.e. it has never
shipped in a Fedora release, so it is not "1 used but not used by default";
it's entirely new to Fedora *in F21*.
   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: F21 System Wide Change: Smaller Cloud Image Footprint

[Miloslav Trmač]

2014-04-17 21:54 GMT+02:00 Matthew Miller :

> On Thu, Apr 17, 2014 at 09:47:21PM +0200, Miloslav Trmač wrote:
> > > (NetworkManager and initscripts) and one that's available but not used
> by
> > > default anywhere (systemd-networkd). This would simply swap the status
> of
> > > systemd-networkd and initscripts.
> > Is NetworkManager already at the *100% complete* feature parity that
> would
> > make this possible?  (Keeping in mind that "possible" and "a good idea"
> are
> > still not the same...)
>
> I don't think I accept your premise here. 100% (possibly spread between
> networkd and NetworkManager) would be necessary for dropping initscripts
> completely, but that's not being proposed.
>

You were arguing that we would be going from 2 used + 1 unused systems to a
different set of 2 used + 1 unused; for that to happen, users of
initscripts must have somewhere to migrate to.

> > It is _largely_ the case that complex networking is done outside of the
> > > guests and presented to the guests as simple interfaces. Usually that's
> > > one device with DHCP, but there may be additional interfaces with DHCP
> > > or static interfaces.
> > Well, this particular possibility is strictly black/white—either the
> > completely different configuration and API is exposed, or it isn't; if
> > there are any alternatives to configure at all, it is exposed.
>
> Not following you.
>

As a background, I *really* don't want the fragmentation; I don't see the
benefits, and I very much see the costs.  In the original mail I have tried
to outline a scenario in which there would "technically" be fragmentation,
but only in a setup that users would never touch so it would be
"invisible".  But as soon as this is something users need to interact with,
it's no longer "invisible" and we are in the, for me undesirable, full
fragmentation scenario.
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: F21 Self Contained Change: Remote Journal Logging

[Miloslav Trmač]

2014-04-16 19:08 GMT+02:00 Chris Adams :

> It would be good if systemd could
> use or extend an existing logging protocol, rather than invent yet
> another method.
>

Yes.  Going by the feature page and from what I can see from
journal-remote.c, because Transfer-Encoding: chunked does not require
application-level acknowledgment from the recipient, and there is no other
mechanism to synchronize state, the proposed use of HTTP will be *losing
data*!

See
http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.htmland
http://blog.gerhards.net/2008/05/why-you-cant-build-reliable-tcp.html , and
http://www.rsyslog.com/doc/relp.html .  Am I missing something?
 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: F21 Self Contained Change: Remote Journal Logging

[Miloslav Trmač]

Hello,
2014-04-16 15:04 GMT+02:00 Zbigniew Jędrzejewski-Szmek :

> I'll reconsider using SASL instead. I have the HTTPS-transport version
> almost ready, so for now I'll go with that, to have a working
> solution. There's still some other questions, mostly related to how
> the data should be stored on the receiver, so I want to get it out for
> people to test. The underlying transport is an implementation detail,
> mostly visible in the way that authentication is done, so a new
> transport can be added, and the old one deprecated or even removed.
>

After this first ships in a product, that's not how networks work;
protocols, once defined, are pretty much forever—or, well, until users'
setups are broken and users are unhappy.
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: F21 System Wide Change: Smaller Cloud Image Footprint

[Matthew Miller]

On Thu, Apr 17, 2014 at 09:47:21PM +0200, Miloslav Trmač wrote:
> > (NetworkManager and initscripts) and one that's available but not used by
> > default anywhere (systemd-networkd). This would simply swap the status of
> > systemd-networkd and initscripts.
> Is NetworkManager already at the *100% complete* feature parity that would
> make this possible?  (Keeping in mind that "possible" and "a good idea" are
> still not the same...)

I don't think I accept your premise here. 100% (possibly spread between
networkd and NetworkManager) would be necessary for dropping initscripts
completely, but that's not being proposed.


> > Yeah, as I've said elsewhere, I'd love to see a network unit generator
> > which takes traditional ifcfg-* files as input. I think we need
> > ifup/ifdown compatibility scripts, too.
> Would these be prerequisites to making the change?

ifup/ifdown are probably real prerequisites (some of the ec2 tools assume
their presence), and an ifcfg generator a high-value nice-to-have.

> > It is _largely_ the case that complex networking is done outside of the
> > guests and presented to the guests as simple interfaces. Usually that's
> > one device with DHCP, but there may be additional interfaces with DHCP
> > or static interfaces.
> Well, this particular possibility is strictly black/white—either the
> completely different configuration and API is exposed, or it isn't; if
> there are any alternatives to configure at all, it is exposed.

Not following you.

-- 
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: F21 System Wide Change: Smaller Cloud Image Footprint

[Miloslav Trmač]

2014-04-17 1:42 GMT+02:00 Matthew Miller :

> On Thu, Apr 17, 2014 at 01:24:50AM +0200, Miloslav Trmač wrote:
> > I don't think we can, or should, have three separate network
> configuration
> > systems in Fedora at the same time.  We already know how long and painful
>
> I think we'd stay at two, basically -- right now, we have two in use
> (NetworkManager and initscripts) and one that's available but not used by
> default anywhere (systemd-networkd). This would simply swap the status of
> systemd-networkd and initscripts.
>

Is NetworkManager already at the *100% complete* feature parity that would
make this possible?  (Keeping in mind that "possible" and "a good idea" are
still not the same...)

> the migration to NetworkManager has been—and AFAICS networkd doesn't
> > support any of the icfg-* files, unlike NetworkManager, so it would mean
> a
> > *more* painful migration.
>
> Yeah, as I've said elsewhere, I'd love to see a network unit generator
> which
> takes traditional ifcfg-* files as input. I think we need ifup/ifdown
> compatibility scripts, too.
>

Would these be prerequisites to making the change?


> With what I know so far, this would only make sense to me if the Cloud
> > images were explicitly designed to run in a very specific network
> > environment (say, everything via DHCP, no VPNs, no IPSec, no bridges,
> > nothing else), and telling both users and application developers not to
> > touch the configuration in any way.
>
> It is _largely_ the case that complex networking is done outside of the
> guests and presented to the guests as simple interfaces. Usually that's one
> device with DHCP, but there may be additional interfaces with DHCP or
> static
> interfaces.
>

Well, this particular possibility is strictly black/white—either the
completely different configuration and API is exposed, or it isn't; if
there are any alternatives to configure at all, it is exposed.
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: libreoffice broken again in updates-testing

[Sérgio Basto]

On Sex, 2014-04-18 at 01:55 +0800, Mathieu Bridon wrote: 
> On Thu, 2014-04-17 at 16:24 +0200, Reindl Harald wrote:
> > and before you tell me now about outdated mirrors - no, see repo-file below
> > what you are installing *now* don't matter, *now* 4.2.3.3-4 is in the repo
> > starting with tuesday evening until today the broken one was
> > 
> > to make it short: i can handle yum and repos
> > 
> > [root@rh:~]$ cat /etc/yum.repos.d/fedora-updates.repo
> > [updates]
> > name=Fedora $releasever - $basearch - Updates
> > failovermethod=priority
> > baseurl=https://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
> 
> Just thought I'd let you know: download.fedoraproject.org is in fact an
> alias that redirects you to a mirror.
> 
> That doesn't change anything about your main point (that the update
> wasn't pushed yet when you were trying but had been before Sergio
> replied), but it would still be theoretically possible for you to get
> sent to an outdated mirror, just like using mirrorlist.

Yes , I'd say the same, you should use mirrorlist instead use directly
download.fedora you will have more probably of success in refresh yum
cache . 
I used baseurl when I knew that I have a good mirror which is more
faster than others , for example : 

baseurl=http://mirrors.eu.kernel.org/fedora/updates/$releasever/$basearch


-- 
Sérgio M. B.

-- 
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: Workstation: Disable firewall

[Michael Catanzaro]

On Thu, 2014-04-17 at 12:26 -0400, Paul Wouters wrote:
> For DNS issues we have similar issues. A sane default seems to be that
> if you plugin a cable or you enter wifi WPA(2) details, you are
> trusting the network you are connecting to per default. (with NM
> override options for corner cases like using WPA2 on your phone as
> hotspot but you don't trust the telco network)

Ah, that would make everything too easy. :(

For WPA Enterprise networks, of course. But a WPA PSK network is as
likely to be a trusted home network as it is a coffee shop that puts on
a password so that you have to be inside to see the password on a flier
or something, or a university network open to thousands of people.
Asking seems safest.

But another danger: if I am at home but my computer is not behind a
personal router with a NAT, do I select Home or Public? The average user
does not know and will pick Home. A prompt to select a network zone
needs to be carefully thought out to make it less likely that the user
picks wrong.


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: F21 System Wide Change: SCL

[Marcela Mašláňová]

On 04/17/2014 05:40 PM, Toshio Kuratomi wrote:

On Thu, Apr 17, 2014 at 04:35:25PM +0200, Miloslav Trmač wrote:

2014-04-14 14:13 GMT+02:00 Jaroslav Reznik :

 2. Upload packages into git - specific branch based on Fedora version and
 name
 of collection. For stable repo we must be able to replicate builds from git
 repo, which Fedora own.


I'm confused; what precisely is the layout you are proposing for pkgs git?  I
read this as ruby.git/{f20,f21,f21-$sclname}; is that really the proposal?


I'm not sure what the proposal is but the FPC wants to have all scls live in
a separate package than the "mainstream" package.  Like this:

ruby.git/{f20,f21}
fdr-ruby1.9.3-ruby.git/{f20,f21}

This matches with what mingw does and after working on creating an SCL, it
seems to be a better plan to keep the two sources separate as scl spec files
are much different than mainstream specs.

-Toshio



I still believe using tested workflow, which means one git for normal 
and scl packages is much better approach from release engineering point 
of view. You are creating new problems, which weren't seen by SCL team 
yet. I already stated my view many times, changes for Fedora must be 
done anyway, so I as maintainer doesn't care much about branch or new git.


Which parts of the draft are approved? [1] If I read it correctly I 
should rename the metapackage ruby193 to scl-ruby1.9.3 and ruby193-ruby 
to scl-ruby1.9.3-ruby. Is that right?


[1] 
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#Naming_the_SCL


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: libreoffice broken again in updates-testing

[Mathieu Bridon]

On Thu, 2014-04-17 at 16:24 +0200, Reindl Harald wrote:
> and before you tell me now about outdated mirrors - no, see repo-file below
> what you are installing *now* don't matter, *now* 4.2.3.3-4 is in the repo
> starting with tuesday evening until today the broken one was
> 
> to make it short: i can handle yum and repos
> 
> [root@rh:~]$ cat /etc/yum.repos.d/fedora-updates.repo
> [updates]
> name=Fedora $releasever - $basearch - Updates
> failovermethod=priority
> baseurl=https://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/

Just thought I'd let you know: download.fedoraproject.org is in fact an
alias that redirects you to a mirror.

That doesn't change anything about your main point (that the update
wasn't pushed yet when you were trying but had been before Sergio
replied), but it would still be theoretically possible for you to get
sent to an outdated mirror, just like using mirrorlist.


-- 
Mathieu

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

[Marcela Mašláňová]

On 04/16/2014 07:36 PM, Dennis Gilmore wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 14 Apr 2014 14:13:24 +0200
Jaroslav Reznik  wrote:


= Proposed System Wide Change: SCL =
https://fedoraproject.org/wiki/Changes/SCL

Change owner(s): Marcela Mašláňová 

SCL - Software Collections - are popular packaging format above rpm.
Let's enable them for Fedora. More details on upstream page [1].

== Detailed Description ==
My first draft [2] is obsoleted by current state of SCL, Copr... I
would keep the SCL workflow simple as possible.

Playground repo

1. Build SCL in Copr
2. Add SCL into Playground repo

Fedora main repo

0. Build SCL in Copr (or use existing SCL)
1. Do standard package review
2. Upload packages into git - specific branch based on Fedora version
and name of collection. For stable repo we must be able to replicate
builds from git repo, which Fedora own.
3. Build SCL in koji or magically add SCL builds from Copr (depends
on preference of releng)

SCL living on Copr can be good candidates for inclusion in Fedora.
Maintainer of such SCL must be able create Change proposal for his
collection. Review of packages in the collection should depend on
repository (Playground - almost no rules, Fedora - standard
guidelines).

== Scope ==
* Proposal owners:
0. Approve SCL guidelines by FPC
1. Include one collection into Fedora Playground repository or into
main Fedora repository (probably the one wanted by Cloud WG). It
might be this one rebuild for Fedora [3]. Updates of some gems or
addition of other gems might be needed. Review by Cloud projects is
needed.

* Other developers: If SCL is in Fedora, maybe some other project can
use it for their work.

* Release engineering: Magically add SCLs builds into compose or set
up koji for SCLs.


building in koji is a must

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTTr+GAAoJEH7ltONmPFDRhmgQAM/wINQyNmOjyBzgTHCNAe3D
pfndiCl7O39EQPTs6vV9PpPGN5TXUhgStwtRTTMuRegevgFchhjxWXknjp9RQSEo
StrHxkJZ5+pEcFaR+2hTqIKSg10O3hYYT+p9kZjMKEfJ3+NUqvJNv9hmcBdeTI0F
/hDDqezQsE+Gk8xWMVv0GeCN1+HPM9GWotO4YpnITgCU+IMleM5Nxjr1mJzab8nA
/vS+Zh9VnV6wpxuegqcmR8qSufDEsptyU3ZxqddqP+ZNehtag4GnMCwX7w30XQH7
FlhIeTYrDFrbMowVnEtur6Udwi2PHe4vBe6jZILclCyJ3si7hXrCEsaRP/a7a9OX
bkownl9Lvo/v+w19SKDYm0c/Ojn1U8Ej4RN9pjVmpgJLFC/XARWI7Eov57MFPkZF
k3IYppkAUreaXBxsLcnKdx3EJNBKTqjqJL3dFBCJJmn0Py1M2K9Q5Pp9Rr+BrtSW
Faac9g4xh+fk1zIV8j5ItcQGrZg5ZJvmkXGeZjksQyIS99HrazYMG5cWe6n58jbM
bikvItU9NKNpuxUK0/sBDhxsBn0XjYdXPl32A29QxIC6oX6sSaEAOrzEDOGW1M5n
8F7+zcTT0gF4gJh3e3/Hr2tR4pv3+hiKWVPutQLWYbIO/JWthdnWIc+QQ6WRegit
LxRI4dsdJg5wrJS1JmPu
=Mw6h
-END PGP SIGNATURE-

Great, we can discuss how to do it. Usually it's needed to add into 
buildroot the meta-package for the collection. I guess what's needed 
from release engineering point of view can be explained by your 
colleagues from release engineering like Lubos.


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: F21 Self Contained Change: Playground repository

[Marcela Mašláňová]

On 04/17/2014 06:14 PM, Kevin Fenzi wrote:

On Thu, 17 Apr 2014 09:03:20 +0200
Marcela Mašláňová  wrote:


On 04/15/2014 05:58 PM, Kevin Fenzi wrote:

...snip...


Packages for the repository are built in COPR. The COPR owner can
propose the repository as a whole for inclusion into the Playground
repository by marking it as such in COPR. Repositories/packages
successfully built and satisfying the Playground repository's
Policies are copied into the Playgroud repository. The one
Playground repository includes many Copr repositories.


I'm a bit confused here. Is there another repo that all playground
packages are copied to? Or are they just seperate copr repos?
Ok, on further reading there is a seperate repo. This would be
mirrored?


No copying, there is not so much space on Copr. It's not a real
repository, but set of Copr projects marked as Playground. They will
be installed by dnf plugin, I recommend to look how the plugin works:
http://dnf.baseurl.org/2014/03/19/copr-plugin/

It will be almost the same for Playground plugin.


ok, then you might rephrase the parts of the change that have "copied
into the playground repository". Perhaps:

Repositories/packages successfully built and satisfying the playground
repositories policies are made available to users via the dnf
playground plugin.

kevin



Thanks, fixed too.

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: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 17.04.2014 18:26, schrieb Paul Wouters:
> On Thu, 17 Apr 2014, Daniel J Walsh wrote:
> 
>> Didn't mean to accuse you of saying that.  I do like the idea of asking
>> if you are on a "trusted" network.
> 
> For DNS issues we have similar issues. A sane default seems to be that
> if you plugin a cable or you enter wifi WPA(2) details, you are
> trusting the network you are connecting to per default. (with NM
> override options for corner cases like using WPA2 on your phone as
> hotspot but you don't trust the telco network)

by plugin a cable you trust the network?
seriously?

you may live in a world with only wireless clients and that's why
plugin a cable is something special that it only happens at your
home network - i can tell for sure that's not really true

you have to be *asked* if you trust that network and no i do
not buy the argumentation "the user anyways says yes" because
even don't ask shoots also the one which would think about or
say "no" for good reasons





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: F21 System Wide Change: Workstation: Disable firewall

[Paul Wouters]

On Thu, 17 Apr 2014, Daniel J Walsh wrote:


Didn't mean to accuse you of saying that.  I do like the idea of asking
if you are on a "trusted" network.


For DNS issues we have similar issues. A sane default seems to be that
if you plugin a cable or you enter wifi WPA(2) details, you are
trusting the network you are connecting to per default. (with NM
override options for corner cases like using WPA2 on your phone as
hotspot but you don't trust the telco network)

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

Broken dependencies: perl-Catalyst-Controller-HTML-FormFu

[buildsys]

perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide 
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On i386:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On armhfp:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
Please resolve this as soon as possible.


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

Broken dependencies: perl-GnuPG-Interface

[buildsys]

perl-GnuPG-Interface has broken dependencies in the rawhide tree:
On x86_64:
perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late)
On i386:
perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late)
On armhfp:
perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late)
Please resolve this as soon as possible.


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

Broken dependencies: mojomojo

[buildsys]

mojomojo has broken dependencies in the rawhide tree:
On x86_64:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On i386:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On armhfp:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
Please resolve this as soon as possible.


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

Broken dependencies: perl-Language-Expr

[buildsys]

perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


--
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: F21 Self Contained Change: Playground repository

[Kevin Fenzi]

On Thu, 17 Apr 2014 09:03:20 +0200
Marcela Mašláňová  wrote:

> On 04/15/2014 05:58 PM, Kevin Fenzi wrote:
> > ...snip...
> >
> >> Packages for the repository are built in COPR. The COPR owner can
> >> propose the repository as a whole for inclusion into the Playground
> >> repository by marking it as such in COPR. Repositories/packages
> >> successfully built and satisfying the Playground repository's
> >> Policies are copied into the Playgroud repository. The one
> >> Playground repository includes many Copr repositories.
> >
> > I'm a bit confused here. Is there another repo that all playground
> > packages are copied to? Or are they just seperate copr repos?
> > Ok, on further reading there is a seperate repo. This would be
> > mirrored?
> >
> No copying, there is not so much space on Copr. It's not a real 
> repository, but set of Copr projects marked as Playground. They will
> be installed by dnf plugin, I recommend to look how the plugin works:
> http://dnf.baseurl.org/2014/03/19/copr-plugin/
> 
> It will be almost the same for Playground plugin.

ok, then you might rephrase the parts of the change that have "copied
into the playground repository". Perhaps: 

Repositories/packages successfully built and satisfying the playground
repositories policies are made available to users via the dnf
playground plugin. 

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: F21 System Wide Change: Workstation: Disable firewall

[Daniel J Walsh]

On 04/16/2014 09:32 AM, Simo Sorce wrote:
> On Wed, 2014-04-16 at 05:40 -0700, Daniel J Walsh wrote:
>> On 04/15/2014 09:31 AM, Simo Sorce wrote:
>>> On Tue, 2014-04-15 at 09:13 -0700, Andrew Lutomirski wrote:
 I keep thinking that, if I had unlimited time, I'd write a totally
 different kind of firewall.  It would allow some policy (userspace
 daemon or rules loaded into the kernel) to determine when programs can
 listen on what sockets and when connections can be accepted on those
 sockets.  This avoids the attack surface of iptables, it will be
 faster, it can cause programs to actually report errors if you want
 them to, and it could be a lot easier to configure.

 Wouldn't it be great if, when you start some program that wants to
 listen globally, your system could prompt you and ask whether it was
 okay, even if that program didn't know about firewalld?

>>> I think what you are describing could be probably realized with SELinux
>>> today, just with a special setroubleshoot frontend that catches the AVC
>>> when the service tries to listen and ask the user if he wants to allow
>>> it.
>>>
>>> However this would still not be completely sufficient as you completely
>>> lack any context about what network you are operating on.
>>>
>>> The firewall's purpose is to block access to local services on bad
>>> networks too, it is not a binary open/close equation when you have
>>> machines (laptops) that roam across a variety of networks.
>>>
>>> Simo.
>>>
>> Nothing worse then asking Users Security related questions about opening
>> firewall ports.
>> Users will just answer yes, whether or not they are being hacked.
>>
>> firefox wants to listen on port 9900 in order to see this page, OK?
>
> Which is not what I proposed Dan.
>
> I in fact said we should *NOT* ask per application.
>
> What we should ask is one single question, upon connecting to an unknown
> network: "Is this network trusted ?"
>
> If yes you open up to the local network. If no you keep ports not
> accessible on that network.
>
> We can hint that a cafe wifi is usually not trusted and users should say
> no, or perhaps we do not even ask and default to untrusted on open wifi
> networks, and only ask on secured networks (this would be my
> preference).
Didn't mean to accuse you of saying that.  I do like the idea of asking
if you are on a "trusted" network.
>> %99.999 will answer yes, and be aggravated.
>>
>> Setting up a rule that says app XYZ is allowed to open certain ports
>> would be a great step forward.  But there would need to be a provable
>> way to guarantee that only the XYZ application is able to open those
>> ports.  You could do this with SELinux, but we would need to transition
>> user apps to certain domains, but we would need to run users with a
>> confined domain, and stop disabling SELinux...
> I think we can do this in steps, I certainly agree with the long term
> goal.
>
> Simo.
>

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

[Toshio Kuratomi]

On Thu, Apr 17, 2014 at 04:35:25PM +0200, Miloslav Trmač wrote:
> 2014-04-14 14:13 GMT+02:00 Jaroslav Reznik :
> 
> 2. Upload packages into git - specific branch based on Fedora version and
> name
> of collection. For stable repo we must be able to replicate builds from 
> git
> repo, which Fedora own.
> 
> 
> I'm confused; what precisely is the layout you are proposing for pkgs git?  I
> read this as ruby.git/{f20,f21,f21-$sclname}; is that really the proposal?

I'm not sure what the proposal is but the FPC wants to have all scls live in
a separate package than the "mainstream" package.  Like this:

ruby.git/{f20,f21}
fdr-ruby1.9.3-ruby.git/{f20,f21}

This matches with what mingw does and after working on creating an SCL, it
seems to be a better plan to keep the two sources separate as scl spec files
are much different than mainstream specs.

-Toshio


pgp1QXELqWbXO.pgp
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: Documentation and Docstring Format

[Tim Flink]

On Thu, 17 Apr 2014 10:03:24 -0400 (EDT)
Kamil Paral  wrote:

> > > https://pythonhosted.org/an_example_pypi_project/sphinx.html#auto-directives
> > > 
> > > 
> > > I'm not suggesting that we drop everything and fix all the
> > > docstrings right now but I am suggesting that we start following
> > > the sphinx docstring format for new code and fix other-formatted
> > > docstrings as we come across them.
> > > 
> > > Any objections?
> > 
> > Well, my only objection is, that the Sphinx format has IMHO the
> > worst impact on how docstrings look.
> 
> That is my impression as well [1]. The improved versions of Markdown
> are more legible and easier to remember than ReST (+Sphinx) [2].
> OTOH, there are certain Sphinx features that look really great (for
> example documentation of attributes or global variables). So let's
> try it. 

This gets down to personal preference but in general, I prefer ReST to
markdown.

I thought that we had already decided to use sphinx when mike did his
documentation tool survey a couple of months ago.

> > Maybe it is just me, but I use help() more often than html docs.
> 
> The Spyder editor shows HTML output of docstrings, even though it
> seems it uses plain ReST conversion instead of Sphinx conversion.
> 
> > 
> > But other than that, I have no issues.
> 
> I played with it a little and the syntax is quite complex. If we are
> to use it, we will need at least:
> 1. basic sphinx config committed into the repository
> 2. some instructions in the readme how to generate the docs

Yeah, my plan is to have sphinx docs live in the same repo as
libtaskotron so changes can be built locally before submitting any
patches.

"build docs" sounds like a reasonable section to have in the dev
documentation.

> so that we can at least generate the docs locally and look at it
> before posting the patch. As Tim already said, sphinx is pretty
> strict in its syntax.
>
> There is one more alternative, I think - use Sphinx for docs
> generation, but keep the docstrings free-form (I assume there must be
> an option in Sphinx to do that). That way we lose some pretty
> formatting, but won't be forced to adhere to a particular syntax.

I put an example of the output from both sphinx-style docstrings and
freeform docstrings up on fedorapeople:

http://tflink.fedorapeople.org/taskotron/test-libtaskotron-docs/library.html

It sounds like the general consensus is that sphinx-style docstrings
are ugly but generate nice html output and it's not clear whether the
ugly-ness of the docstrings is worth the nice html api docs.

How do we want to decide which format to use going forward? Get the
docs started and try out the different docstring formats?

I'm +1 to using sphinx-style docstrings but could likely be persuaded
to use something different as long as it doesn't require too much
custom code. We have enough custom tools as it is and I'd rather use
something standard for api docs.

Tim


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

Re: Taskotron and Cloud Image tests

[Matthew Miller]

On Thu, Apr 17, 2014 at 02:25:03PM +0200, Vitaly Kuznetsov wrote:
> 2mattdm: Matt, I remember you telling me that someone is working on such
> uploader. Can you please shed some light on what's the status now and
> what can be done in before f21?

Yeah. Still manual process. It feels like a very long time ago that we were
talking about this in Brno! But David Gay (oddshocks) has been hired as a
summer intern and will be working on this. Some related tickets:

 https://fedorahosted.org/cloud/ticket/35
 https://fedorahosted.org/cloud/ticket/38



> Ok, I think that having something ready in f21 timeframe is really
> doable in case releng can automate AMIs uploading process. I'll take a
> look at the runner in libtaskotron and existing tasks examples.


Awesome!

-- 
Matthew Miller--   Fedora Project--
  "Tepid change for the somewhat better!"
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: F21 Self Contained Change: Remote Journal Logging

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 17, 2014 at 07:33:16AM -0400, Martin Langhoff wrote:
> On Wed, Apr 16, 2014 at 5:08 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> >> So I'll ask you about this other aspect -- what about stateless
> >> clients with very limited or no local storage?
> > Not supported by this, unfortunately. There needs to be at least
> > temporary storage in tmpfs for this scheme to work.
> 
> Can the storage space used be limited with a parameter to avoid
> ENOSPC? Can journald be told to start discarding the data (oldest or
> latest) when it reaches the limit?

Yeah, it's standard journald behaviour. By default journald will limit
both the total disk usage, and will also not fill the fs above 90% (iirc).
There were various issues with this logic in the past, but it seems to
behave fairly robustly now. The idea is
that journald does the "right thing" without any configuration or
maintenance.  The logic is suitable for normal fs layout, but if
something different is needed, especially if you have a dedicated fs
for log storage that can be filled to the brim, the limits and
thresholds are all configurable (see
http://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse=
for available options).

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

[Miloslav Trmač]

2014-04-14 14:13 GMT+02:00 Jaroslav Reznik :

> 2. Upload packages into git - specific branch based on Fedora version and
> name
> of collection. For stable repo we must be able to replicate builds from git
> repo, which Fedora own.
>

I'm confused; what *precisely* is the layout you are proposing for pkgs
git?  I read this as ruby.git/{f20,f21,f21-$sclname}; is that really the
proposal?


> 3. Build SCL in koji or magically add SCL builds from Copr (depends on
> preference of releng)

== Benefit to Fedora==
>
> Cool programs depending on specific version of software can still run on
> Fedora.
>
That would, strictly speaking, only be true if the SCL actually ends up in
Fedora main repo if I'm not mistaken.
   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

[perl-MooseX-Types-Stringlike] Created tag perl-MooseX-Types-Stringlike-0.003-1.fc21

[Paul Howarth]

The lightweight tag 'perl-MooseX-Types-Stringlike-0.003-1.fc21' was created 
pointing to:

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

[perl-MooseX-Types-Stringlike] Created tag perl-MooseX-Types-Stringlike-0.003-1.el7

[Paul Howarth]

The lightweight tag 'perl-MooseX-Types-Stringlike-0.003-1.el7' was created 
pointing to:

 c4c2fde... Update to 0.003
--
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: libreoffice broken again in updates-testing

[Reindl Harald]

Am 17.04.2014 16:19, schrieb Reindl Harald:
> Am 17.04.2014 16:16, schrieb Sérgio Basto:
>> I don't broken deps [1] , the important is why you got broken deps 
>>
>> [1] yum  --enablerepo=updates-testing update --advisory FEDORA-2014-5062
>>
>> I'm installing libreoffice-4.2.3.3-4, and you are installing
>> libreoffice-4.2.3.3-3, so that is the problem, you need refresh yours
>> yum cache 
> 
> if you would have followed the thread you would have seen the below:
> 
> i did *multiple* rm -rf /var/cache/yum/* all day long as also statet on bodhi
> like a wonder this morning the update was pushed, see also the other comment
> on bodhi about the not pushed 4.2.3.3-4
> 
> the broken one should have been unpushed anyways

and before you tell me now about outdated mirrors - no, see repo-file below
what you are installing *now* don't matter, *now* 4.2.3.3-4 is in the repo
starting with tuesday evening until today the broken one was

to make it short: i can handle yum and repos

[root@rh:~]$ cat /etc/yum.repos.d/fedora-updates.repo
[updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
baseurl=https://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch



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: libreoffice broken again in updates-testing

[Reindl Harald]

Am 17.04.2014 16:16, schrieb Sérgio Basto:
> On Qui, 2014-04-17 at 00:48 +0200, Reindl Harald wrote: 
>> why do whe have that always with libreoffice?
>> the broken build hangs around for 30 hours in the repo
>> the supposed to fix that one is not pushed
>> even with using the koji-repo no way t osolve that
>>
>> https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=05a8ab02f2593f3e95b04291696587c8234d903a
>>
>> Error: Package: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 (updates-testing)
>>Requires: libxmlsecurity.so()(64bit)
>>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
>> (@updates-testing)
>>libxmlsecurity.so()(64bit)
>>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
>> (updates-testing)
>>Not found
>>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>>libxmlsecurity.so()(64bit)
>> Error: Package: 1:libreoffice-calc-4.2.3.3-3.fc20.x86_64 (updates-testing)
>>Requires: libcomphelper.so()(64bit)
>>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
>> (@updates-testing)
>>libcomphelper.so()(64bit)
>>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
>> (updates-testing)
>>Not found
>>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>>libcomphelper.so()(64bit)
> 
> I don't broken deps [1] , the important is why you got broken deps 
> 
> [1] yum  --enablerepo=updates-testing update --advisory FEDORA-2014-5062
> 
> I'm installing libreoffice-4.2.3.3-4, and you are installing
> libreoffice-4.2.3.3-3, so that is the problem, you need refresh yours
> yum cache 

if you would have followed the thread you would have seen the below:

i did *multiple* rm -rf /var/cache/yum/* all day long as also statet on bodhi
like a wonder this morning the update was pushed, see also the other comment
on bodhi about the not pushed 4.2.3.3-4

the broken one should have been unpushed anyways




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: libreoffice broken again in updates-testing

[Sérgio Basto]

On Qui, 2014-04-17 at 00:48 +0200, Reindl Harald wrote: 
> why do whe have that always with libreoffice?
> the broken build hangs around for 30 hours in the repo
> the supposed to fix that one is not pushed
> even with using the koji-repo no way t osolve that
> 
> https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=05a8ab02f2593f3e95b04291696587c8234d903a
> 
> Error: Package: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 (updates-testing)
>Requires: libxmlsecurity.so()(64bit)
>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
> (@updates-testing)
>libxmlsecurity.so()(64bit)
>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
> (updates-testing)
>Not found
>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>libxmlsecurity.so()(64bit)
> Error: Package: 1:libreoffice-calc-4.2.3.3-3.fc20.x86_64 (updates-testing)
>Requires: libcomphelper.so()(64bit)
>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
> (@updates-testing)
>libcomphelper.so()(64bit)
>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
> (updates-testing)
>Not found
>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>libcomphelper.so()(64bit)

Hi, 
I don't *have* broken deps [1] , the important is why you got broken deps 

[1] yum  --enablerepo=updates-testing update --advisory FEDORA-2014-5062

I'm installing libreoffice-4.2.3.3-4, and you are installing
libreoffice-4.2.3.3-3, so that is the problem, you need refresh yours
yum cache . 

Best regards,

-- 
Sérgio M. B.

-- 
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: libreoffice broken again in updates-testing

[Sérgio Basto]

On Qui, 2014-04-17 at 00:48 +0200, Reindl Harald wrote: 
> why do whe have that always with libreoffice?
> the broken build hangs around for 30 hours in the repo
> the supposed to fix that one is not pushed
> even with using the koji-repo no way t osolve that
> 
> https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=05a8ab02f2593f3e95b04291696587c8234d903a
> 
> Error: Package: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 (updates-testing)
>Requires: libxmlsecurity.so()(64bit)
>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
> (@updates-testing)
>libxmlsecurity.so()(64bit)
>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
> (updates-testing)
>Not found
>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>libxmlsecurity.so()(64bit)
> Error: Package: 1:libreoffice-calc-4.2.3.3-3.fc20.x86_64 (updates-testing)
>Requires: libcomphelper.so()(64bit)
>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
> (@updates-testing)
>libcomphelper.so()(64bit)
>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
> (updates-testing)
>Not found
>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>libcomphelper.so()(64bit)

Hi, 
I don't broken deps [1] , the important is why you got broken deps 

[1] yum  --enablerepo=updates-testing update --advisory FEDORA-2014-5062

I'm installing libreoffice-4.2.3.3-4, and you are installing
libreoffice-4.2.3.3-3, so that is the problem, you need refresh yours
yum cache . 

Best regards,
-- 
Sérgio M. B.

-- 
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: Documentation and Docstring Format

[Tim Flink]

On Thu, 17 Apr 2014 05:31:30 -0400 (EDT)
Josef Skladanka  wrote:

> > https://pythonhosted.org/an_example_pypi_project/sphinx.html#auto-directives
> > 
> > 
> > I'm not suggesting that we drop everything and fix all the
> > docstrings right now but I am suggesting that we start following
> > the sphinx docstring format for new code and fix other-formatted
> > docstrings as we come across them.
> > 
> > Any objections?
> 
> Well, my only objection is, that the Sphinx format has IMHO the worst
> impact on how docstrings look. Maybe it is just me, but I use help()
> more often than html docs.

I guess that I'm the opposite - I rarely use help() and am more likely
to be looking at the html docs.

Does anyone have an alternate suggestion for docstring format? I think
that having html docs is important but I'm open to other suggestions
that don't involve keeping docs in two places.

Tim


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

[perl-Term-ProgressBar/f20] 2.15 bump

[Petr Šabata]

Summary of changes:

  a05e676... 2.15 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
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: F21 Self Contained Change: Playground repository

[Florian Weimer]

On 04/08/2014 08:23 PM, Kevin Fenzi wrote:


So, I need to fully read the change before making more comments, but I
thought I would mention Chromium since it seems to come up a lot.

Yes, it has a number of bundled things that cannot be easily unbundled.


And I would expect that every library bundled by Chromium has already 
been bundled by something else in Fedora. :-)  So it can't be just 
bundling that blocks Chromium.


--
Florian Weimer / Red Hat Product Security Team
--
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 Self Contained Change: Playground repository

[Marcela Mašláňová]

On 04/17/2014 03:03 PM, Florian Weimer wrote:

On 04/08/2014 06:17 PM, Jaroslav Reznik wrote:

The Playground repository gives contributors a place to host packages
that are
not up to the standards of the main Fedora repository but may still be
useful
to other users. For now the Playground repository contains both
packages that
are destined for eventual inclusion into the main Fedora repository and
packages that are never going to make it there. Users of the
repository should
be willing to endure a certain amount of instability when using
packages from
there.


Are there any restrictions on obsoletes/provides between the base Fedora
repositories and these playground repositories, (undeclared) file
conflicts, paths that can be touched, or restrictions on RPM scripts?

In fact, it's still an open question [1]. I guess only experienced users 
will allow Playground, so no worries. But I can be persuaded both ways 
with good arguments.


[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: F21 Self Contained Change: Playground repository

[Florian Weimer]

On 04/08/2014 06:17 PM, Jaroslav Reznik wrote:

The Playground repository gives contributors a place to host packages that are
not up to the standards of the main Fedora repository but may still be useful
to other users. For now the Playground repository contains both packages that
are destined for eventual inclusion into the main Fedora repository and
packages that are never going to make it there. Users of the repository should
be willing to endure a certain amount of instability when using packages from
there.


Are there any restrictions on obsoletes/provides between the base Fedora 
repositories and these playground repositories, (undeclared) file 
conflicts, paths that can be touched, or restrictions on RPM scripts?


--
Florian Weimer / Red Hat Product Security Team
--
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 Self Contained Change: Playground repository

[Marcela Mašláňová]

On 04/17/2014 02:34 PM, Josh Boyer wrote:

On Thu, Apr 17, 2014 at 3:03 AM, Marcela Mašláňová  wrote:

On 04/15/2014 05:58 PM, Kevin Fenzi wrote:


...snip...


Packages for the repository are built in COPR. The COPR owner can
propose the repository as a whole for inclusion into the Playground
repository by marking it as such in COPR. Repositories/packages
successfully built and satisfying the Playground repository's
Policies are copied into the Playgroud repository. The one Playground
repository includes many Copr repositories.



I'm a bit confused here. Is there another repo that all playground
packages are copied to? Or are they just seperate copr repos?
Ok, on further reading there is a seperate repo. This would be mirrored?


No copying, there is not so much space on Copr. It's not a real repository,
but set of Copr projects marked as Playground. They will be installed by dnf
plugin, I recommend to look how the plugin works:
http://dnf.baseurl.org/2014/03/19/copr-plugin/

It will be almost the same for Playground plugin.


This reminds me of something else that wasn't clear to some FESCo
members yesterday.  The wording around dnf being required can seem to
imply that you require dnf to replace yum across the entire system.
 From my understanding, that isn't required and people only need to use
dnf if they wish to use the playground plugin.  Is that correct?  If
so you might want to clarify the wording in the requirements section.

josh



My bad, I thought everyone is testing dnf heavily these days :) You can 
install yum and dnf without conflicts. Dnf must be used for installation 
and management of Playground repo, rest of the system can be still 
handled by yum.


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: F21 Self Contained Change: Playground repository

[Josh Boyer]

On Thu, Apr 17, 2014 at 3:03 AM, Marcela Mašláňová  wrote:
> On 04/15/2014 05:58 PM, Kevin Fenzi wrote:
>>
>> ...snip...
>>
>>> Packages for the repository are built in COPR. The COPR owner can
>>> propose the repository as a whole for inclusion into the Playground
>>> repository by marking it as such in COPR. Repositories/packages
>>> successfully built and satisfying the Playground repository's
>>> Policies are copied into the Playgroud repository. The one Playground
>>> repository includes many Copr repositories.
>>
>>
>> I'm a bit confused here. Is there another repo that all playground
>> packages are copied to? Or are they just seperate copr repos?
>> Ok, on further reading there is a seperate repo. This would be mirrored?
>>
> No copying, there is not so much space on Copr. It's not a real repository,
> but set of Copr projects marked as Playground. They will be installed by dnf
> plugin, I recommend to look how the plugin works:
> http://dnf.baseurl.org/2014/03/19/copr-plugin/
>
> It will be almost the same for Playground plugin.

This reminds me of something else that wasn't clear to some FESCo
members yesterday.  The wording around dnf being required can seem to
imply that you require dnf to replace yum across the entire system.
From my understanding, that isn't required and people only need to use
dnf if they wish to use the playground plugin.  Is that correct?  If
so you might want to clarify the wording in the requirements section.

josh
-- 
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 Self Contained Change: Remote Journal Logging

[Martin Langhoff]

On Wed, Apr 16, 2014 at 5:08 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
>> So I'll ask you about this other aspect -- what about stateless
>> clients with very limited or no local storage?
> Not supported by this, unfortunately. There needs to be at least
> temporary storage in tmpfs for this scheme to work.

Can the storage space used be limited with a parameter to avoid
ENOSPC? Can journald be told to start discarding the data (oldest or
latest) when it reaches the limit?

cheers,


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: F21 System Wide Change: Ruby193 in SCL

[Lukas Zapletal]

This is a great change that actually allows other teams that heavily
relies on Fedoras to put their software "on hold" for two Fedora
releases.

Fedora is really a fast moving target and the same for Ruby. Catching up
costs lot of effort. This gives us usually "one extra" release to put
things on hold when huge changes are in the Fedora/Ruby world. Which is
- ehm - every single release? :-)

Big up for this change.

LZ

On Mon, Apr 14, 2014 at 04:16:42PM +0200, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Ruby193 in SCL = 
> https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL
> 
> Change owner(s): Marcela Mašláňová 
> 
> Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's 
> provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 
> version, which means v8 3.14 must have also their own SCL as part of the SCL. 
> 
> == Detailed Description ==
> Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. This 
> change aims to provide Ruby 1.9.3 and Rails 3.2.8. Rails depends on exact v8 
> version, which means v8 3.14 must have also their own SCL as part of this 
> change. 
> 
> == Scope ==
> * Proposal owners: Marcela
> ** create the actual collections, at start in Copr and on SCL upstream [1]
> 
> * Other developers: Cloud WG
> ** test SCL with their apps
> 
> * Release engineering:
> ** create branches in dist-git
> ** add Ruby193 packages into compose
> 
> [1] https://www.softwarecollections.org/en/
> ___
> devel-announce mailing list
> devel-annou...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel-announce
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
Later,

 Lukas "lzap" Zapletal
 irc: lzap #theforeman
-- 
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: Ruby193 in SCL

[Lukas Zapletal]

> Stupid question: what in rails depends on v8 exactly?

Not sure if this has been answered already, but it's the asset pipeline
precompilation, a build requirement.

-- 
Later,

 Lukas "lzap" Zapletal
 irc: lzap #theforeman
-- 
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: Workstation: Disable firewall

[Tomas Radej]

On 04/16/2014 01:11 AM, William Brown wrote:

On Tue, 2014-04-15 at 13:49 -0700, Matthias Clasen wrote:

On Tue, 2014-04-15 at 20:41 +0200, Thomas Woerner wrote:



What you need is clearly different "zones" that the user can configure
and associate to networks, with the default being that you trust nothing
and everything is firewalled when you roam a new network.


We have that already with zones in firewalld.


Kindof. If I open the network panel and find the 'Firewall zone' combo,
I am presented with a choice of:
Default
block
dmz
drop
external
home
internal
public
trusted
work

This list is far too long, and none of it is translated or even properly
capitalized. And there is no indication at all why one would choose any
zone over any other, and what consequences it has.


Agreed

Perhaps shorten to:

block
public
work
home


Oh yes. And when accompanied by a short explanation of what happens (how 
much is shared/blocked, what you may need to do manually to override the 
settings if setting up a service etc.), I think the user experience 
leaves little to be desired.



The other network zone names really seem targeted at servers. Maybe each
zone needs an attr that states if it's a workstation zone or not to
determine if it joins this list?



So, what you have currently is a raw bit of infrastructure that is
directly exposed to the end user, without any design or integration.





Additionally, the command line syntax to manage firewalld is obscene.
(maybe slightly off topic ...)

firewall-cmd --zone=foo --add-port=12345/tcp --permanent

It doesn't autocomplete in bash either (zsh at least prefills the -- and
gives you some options, but it's not great)

At least for the "power" user on a workstation, fixing this syntax to at
the minimum remove all the -- would be great. Follow that by nm-cli
style short hand, and I would be a happy person. You could do:

firewalld-cmd z=foo a-p=12345/tcp perm



Because this syntax is "hard" I think that it even excludes power users
from wanting to make their firewall work on their system.




I don't think we want a 'firewall' UI anyway; the firewall is not
something most users can or should understand and make decisions of.


Never take decisions away from users.

The OSX style firewall works well when enabled. It blocks all by
default, then when an application wants a listening port, the user is
prompted to allow or deny it. I think this is a good model.



What I envision is that we will notify the user when we connect to a new
network, with a message along the lines of:

You have connected to an new network. If this is a public network, you
may want to stop sharing your Music and disable Remote Logins.
[Turn off sharing] [Continue sharing] [Sharing Preferences...]

And we will remember this for when you later reconnect to the same
network.


Why not set the firewall zone when you join the network? And the above
prompts alter that currently active zone?



I've filed a bug for this:
https://bugzilla.gnome.org/show_bug.cgi?id=727580


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: libreoffice broken again in updates-testing

[drago01]

On Thu, Apr 17, 2014 at 10:39 AM, Reindl Harald  wrote:
>
>
> Am 17.04.2014 09:50, schrieb David Tardon:
>> On Thu, Apr 17, 2014 at 12:48:47AM +0200, Reindl Harald wrote:
>>> why do whe have that always with libreoffice?
>>
>> I will send a note to the editors of Oxford English Dictionary that
>> "always" has been redefined to mean "in less than 10 % of cases". If I
>> count correctly, we have issued 26 updates for F-20 that made it into
>> stable (plus a few others that were obsoleted by a later one). One of
>> these had a problem. Now there is a second one.
>
> the main question is why
>
>>> the broken build hangs around for 30 hours in the repo
>>
>> Good. Since you are so concerned about it, what have you done to make me
>> aware of the problem?
>
> https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=18bde034162ac31ef2045718cb3349921b85b388
>
>  hreindl - 2014-04-16 09:02:37
> independent of how often i do rm -rf /var/cache/yum* i still have the broken 
> previous build in updates-testing
> starting with yesterday evening Processing Dependency: libtllo.so()(64bit) 
> for package:
> 1:libreoffice-writer-4.2.3.3-3.fc20.x86_64
>
>> Hint: I consider the mails from various Fedora tools as nonessential
>
> which seemes to be a problem if you don't verify your builds


No the problem here is that our tools are broken and have been for a
long time. Dep check is something that can and should be automated.
This is being worked on though to finally have something that works.
-- 
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: libreoffice broken again in updates-testing

[Reindl Harald]

Am 17.04.2014 09:50, schrieb David Tardon:
> On Thu, Apr 17, 2014 at 12:48:47AM +0200, Reindl Harald wrote:
>> why do whe have that always with libreoffice?
> 
> I will send a note to the editors of Oxford English Dictionary that
> "always" has been redefined to mean "in less than 10 % of cases". If I
> count correctly, we have issued 26 updates for F-20 that made it into
> stable (plus a few others that were obsoleted by a later one). One of
> these had a problem. Now there is a second one.

the main question is why

>> the broken build hangs around for 30 hours in the repo
> 
> Good. Since you are so concerned about it, what have you done to make me
> aware of the problem? 

https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=18bde034162ac31ef2045718cb3349921b85b388

 hreindl - 2014-04-16 09:02:37
independent of how often i do rm -rf /var/cache/yum* i still have the broken 
previous build in updates-testing
starting with yesterday evening Processing Dependency: libtllo.so()(64bit) for 
package:
1:libreoffice-writer-4.2.3.3-3.fc20.x86_64

> Hint: I consider the mails from various Fedora tools as nonessential

which seemes to be a problem if you don't verify your builds

> to be read when I have time. But there are other ways, more suitable 
> for urgent problems, like IRC...

well you could simply try updates-testing at your own

> Btw, 30 hours is not so much, considering that it takes f*ing 14 hours
> just to build new packages because of ARM...

the 30 hours starts couting *after* that and has to be added

>> the supposed to fix that one is not pushed
> 
> https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20
> got +2 karma and passed AutoQA. Whatever has happened after that is
> hardly my fault.

i don't care who's fault it is - that build does not help as long the
previous made it already in a repo




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: libreoffice broken again in updates-testing

[David Tardon]

On Thu, Apr 17, 2014 at 12:48:47AM +0200, Reindl Harald wrote:
> why do whe have that always with libreoffice?

I will send a note to the editors of Oxford English Dictionary that
"always" has been redefined to mean "in less than 10 % of cases". If I
count correctly, we have issued 26 updates for F-20 that made it into
stable (plus a few others that were obsoleted by a later one). One of
these had a problem. Now there is a second one.

> the broken build hangs around for 30 hours in the repo

Good. Since you are so concerned about it, what have you done to make me
aware of the problem? Hint: I consider the mails from various Fedora
tools as nonessential, to be read when I have time. But there are other
ways, more suitable for urgent problems, like IRC...

Btw, 30 hours is not so much, considering that it takes f*ing 14 hours
just to build new packages because of ARM...

> the supposed to fix that one is not pushed

https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20
got +2 karma and passed AutoQA. Whatever has happened after that is
hardly my fault.

D.
-- 
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 Self Contained Change: Playground repository

[Marcela Mašláňová]

On 04/15/2014 05:58 PM, Kevin Fenzi wrote:

...snip...


Packages for the repository are built in COPR. The COPR owner can
propose the repository as a whole for inclusion into the Playground
repository by marking it as such in COPR. Repositories/packages
successfully built and satisfying the Playground repository's
Policies are copied into the Playgroud repository. The one Playground
repository includes many Copr repositories.


I'm a bit confused here. Is there another repo that all playground
packages are copied to? Or are they just seperate copr repos?
Ok, on further reading there is a seperate repo. This would be mirrored?

No copying, there is not so much space on Copr. It's not a real 
repository, but set of Copr projects marked as Playground. They will be 
installed by dnf plugin, I recommend to look how the plugin works:

http://dnf.baseurl.org/2014/03/19/copr-plugin/

It will be almost the same for Playground plugin.


How is is composed? Just a simple pull all packages from these copr's
and createrepo? Will it support multilib, signing, drpms or updateinfo?
I see mention that multilib isn't planned at first and that you want to
use obs-signd to sign packages. Wouldn't it make sense to look at just
using mash (which we use for all other composes). If you did that we
could look at signing with sigul and you could get multilib/drpms/etc
along for the ride?

No compose either, there is nothing to compose, when it stays on Copr. 
At this point I don't think multilib is possible because Copr repos have 
to be somehow regenerated and we have to force users to run rebuild for 
both x86_64 and i686. I'd like to see signing of packages, but our 
proposal to use obs-signd wasn't accepted well as I heard and sigul is 
according to his author not nice and should be improved. It was already 
discussed on devel list before, when Mirek asked about signing packages.


Let's do it easy and use only repository of repositories. We can create 
a real repository with automatic checks for F22, when Taskotron is 
ready. I guess automatic control and disc space would limit a real 
repository and I don't believe we could finish it until F21.



"To avoid any potential confusion, we want to make it clear that the
Playground repository will not host packages that have bad licenses,
include proprietary software or include patented software."

Might change this to "all packages advertised in the playground must
meet the same legal guidelines as packages in Fedora proper". Some
software we ship does have patents, just ones that have patent grants
attached.


Fine by me, I'll change it.


Can you expand on:
"The repository's repodata is continuously regenerated. All the builds
in the COPR repositories that are selected to feed the Playground
repository are composed once a day and pushed to the Playground
repository and its mirrors."

Is the repo composed once a day? Or everytime there is a new build?

Hm, I should remove this. The plugin was finished after we discussed 
these things :) It doesn't make any sense now, I'll update the content.

Thanks for review,


kevin




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