On 03/22/2014 04:20 AM, Miloslav Trmač wrote:
I'm not in this thread to discuss technical merits of the existing
implementation. It may be 100% crappy code. /All/ of what you say
above may be true, but that being true about a widely-used feature
/doesn't automatically mean that eliminating
Hi All,
There's a new devel release of the above just landed. I'll be looking
to get them into rawhide over the new couple of days but there's been
quite some change so I'm going to deal with it all locally first to
see what the impact is before I push it.
Peter
--
devel mailing list
devel@lists
On Sat, Mar 22, 2014 at 02:59:20AM +0100, Lennart Poettering wrote:
> No, firewalls don't do DNS-based filtering, since it's a security nightmare.
Lennart, this isn't true as a general statement. Both Juniper and Cisco
firewalls support FQDN-based access rules. Looks like Palo Alto Networks too
al
On Sat, Mar 22, 2014 at 10:04:51AM +, "Jóhann B. Guðmundsson" wrote:
> So here's the thing daemons and applications are inconsistent in
> their support for libwrap like for example sshd supports it while
> smbd does not which leads to incorrect configuration and
> administrative expectation whi
Am 22.03.2014 07:15, schrieb Reindl Harald:
> Am 22.03.2014 03:21, schrieb Lennart Poettering:
>> On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote:
>>> DNS queries can't really be done within the firewall (and due to the
>>> circular dependency between having the firewall up before al
Jóhann B. Guðmundsson wrote:
> So here's the thing daemons and applications are inconsistent in their
> support for libwrap like for example sshd supports it while smbd does
> not which leads to incorrect configuration and administrative
> expectation which in itself poses a security risk.
I don'
On Sat, Mar 22, 2014 at 6:33 AM, Peter Robinson wrote:
> Hi All,
>
> There's a new devel release of the above just landed. I'll be looking
> to get them into rawhide over the new couple of days but there's been
> quite some change so I'm going to deal with it all locally first to
> see what the im
>> There's a new devel release of the above just landed. I'll be looking
>> to get them into rawhide over the new couple of days but there's been
>> quite some change so I'm going to deal with it all locally first to
>> see what the impact is before I push it.
>
>
> Glad I read this although I alre
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote:
> On 03/19/2014 10:59 PM, Andrew Hughes wrote:>>
>> And JDK5 might be good enough for the use required. It doesn't claim
>> to be anything more than that, so I don't see the harm in leaving it there.
>
> Speaking as the upstream maintainer, I do
Stephen Gallagher wrote:
> 2) foo-config-cloud remains on the system, irrespective of the
> presence of fedora-release-cloud
That's what's going to happen, because there's nothing that enforces that
foo-config-default MUST be the one used by default. It's only preferred at
install time du
Adam Williamson wrote:
> just to note the facts: this issue could have been resolved much faster,
> and SELinux is not the reason why it wasn't.
But SELinux is the reason the bug was there in the first place. Without
SELinux, we wouldn't have had this bug! (Systems without SELinux were not
affec
Antonio Trande wrote:
> I need your help with F1LT application[1]. Its latest release (3.0.0)
> seems not work even if little things are changed in SPEC file.
I see you already resolved your problem with upstream's help:
https://bitbucket.org/pieczar/f1lt/issue/3/f1lt-commit-7440f9a-does-not-run
Tim Lauridsen wrote:
> The most common user case would to install a spin with DE you want to use.
> I dont think it matter much if Gnome software support installation of
> evironments.
> most other DE spins uses LightDM, so if you want a more lightweight DE,
> you don't
> install the Gnome Desktop
Dennis Jacobfeuerborn wrote:
> One example is the policy that patches for packages should first be
> submitted and accepted upstream before they make it into Fedora.
That "policy" is only a non-normative guideline (not part of any enforced
Fedora Guidelines or Policies). The decision is purely up
Miloslav Trmač wrote:
> When we say that there should be "high bar" for becoming a Fedora Product,
> that means that there should be few of them,
I see this repeated over and over by several people. This strikes me as
quite the opposite of being inclusive.
IMHO, ALL the current Spins should auto
On 23.03.2014 03:45, Kevin Kofler wrote:
Dennis Jacobfeuerborn wrote:
One example is the policy that patches for packages should first be
submitted and accepted upstream before they make it into Fedora.
That "policy" is only a non-normative guideline (not part of any enforced
Fedora Guidelines
16 matches
Mail list logo
