Compose started at Sun Apr 13 08:15:03 UTC 2014
Broken deps for x86_64
--
2ping-2.0-2.el7.noarch requires perl(Digest::CRC)
RemoteBox-1.7-1.el7.noarch requires rdesktop
RemoteBox-1.7-1.el7.noarch requires perl-Gtk2
On Sat, 2014-04-12 at 17:46 -0700, Andrew Lutomirski wrote:
On Sat, Apr 12, 2014 at 5:18 PM, William Brown will...@firstyear.id.au
wrote:
Now can we go back to actually discussion technical arguments again?
Actually no.
This whole thread has forgotten one major thing ... use cases.
On Sun, 2014-04-13 at 06:35 +0200, Reindl Harald wrote:
and if you believe that in a not trustable network you don't
know if you get the signing informations at all - fine, but
you hardly an enforce that with a local software
That is the WHOLE point of DNSSEC, really.
if i control the
On Sun, 2014-04-13 at 00:52 -0400, Felix Miata wrote:
On 2014-04-12 16:12 (GMT-0400) Simo Sorce composed:
On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote:
I've been doing that myself for years on installations that think my
ethernet-only non-wireless LAN host connections need managing
On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
A system wide resolver I am not opposed to. I am against a system wide
*caching* resolver.
In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a
cache is a severe detriment.
About the above 2, can you explain *why*
Am 13.04.2014 08:42, schrieb Simo Sorce:
* DNS cache should be flushed on route or interface state change.
I do not see why, the only reason to flush a cache is when there is a
DNS change (new interface, eg VPN coming up, or going away)
because if i change my routing from ISP to VPN i want
Proposal is to add a local caching DNS server to fedora systems. This
may or may not accept a DHCP provided forwarder(?).
Yes. It depends on the trustworthiness of the network and or
preconfiguration of some of your own networks you join.
Not really: Every network you join, you have to
On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
A system wide resolver I am not opposed to. I am against a system wide
*caching* resolver.
In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a
cache is a
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:
On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
A system wide resolver I am not opposed to. I am against a system wide
*caching* resolver.
In this case, a cache
A new version of a package I maintain added an appdata.xml. As I haven't
handled such files before, I looked up the internet for some
information. The only helpful hint I found, was a commit adding appdata
support to the qt-creator package in fedora git. [1]
As more packages will add appdata
William Brown wrote:
The cache is never fully flushed. It is only flushed for the domain
obtained via DHCP or VPN, because those entries can change. They are
not changed for anything else. If the upstream ISP could have
spoofed them, so be it - the publisher of the domains could have
used
William Brown wrote:
In businesses, it's also common place to have a low-ish ttl (Say 5
minutes) and when a system is migrated, they swap the A/ records to
the new system. The dns servers on the network are updated, but the
workstation has the old record cached. Without a local cache, they
william wrote:
[...]
Internal and external zone views in a business. These records may
different, and so would need flushing between network interface state
changes.
Sure, let's make it easy to restart the cache upon such transitions.
Additionally, local DNS caches may issues and delay
On Sun, 13 Apr 2014, William Brown wrote:
Yes. It depends on the trustworthiness of the network and or
preconfiguration of some of your own networks you join.
Not really: Every network you join, you have to semi-trust. If you don't
trust it, why did you join it?
You don't always control
On Sun, 13 Apr 2014, William Brown wrote:
PS: It also seemed like the proposal was to *bypass* the networks
provided forwarders from DHCP. This *is* a serious issue if it's the
case.
We only bypass DHCP provided forwarders that are broken. We actually
WANT to use them as much as possible,
On Sun, 2014-04-13 at 16:29 +0930, William Brown wrote:
That depends. You need caching for DNSSEC validation, so really,
every
device needs a cache, unless you want to outsource your DNSSEC
validation over an insecure transport (LAN). That seems like a very
bad
idea.
If your lan is
On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote:
So you've gone out of your way to run a daemon but prevent it from
working as configured, instead of just reconfiguring it to do what you
need.
I have to go out of my way to *stop* NetworkManager from running and
to configure a fixed
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:
On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
A system wide resolver I am not opposed to. I am against a system wide
*caching* resolver.
In this case, a cache
On Sun, 2014-04-13 at 18:18 +0100, Richard W.M. Jones wrote:
On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote:
So you've gone out of your way to run a daemon but prevent it from
working as configured, instead of just reconfiguring it to do what you
need.
I have to go out of my
On Mon, 2014-04-07 at 18:29 +0100, Andrew Haley wrote:
On 04/07/2014 03:23 PM, Peter Robinson wrote:
There have been a few discussions about this in the past but no action.
With feature freeze approaching for F21, I think this is a good time to
address this.
I will be orphaning
On Sun, 13 Apr 2014, Richard W.M. Jones wrote:
So you've gone out of your way to run a daemon but prevent it from
working as configured, instead of just reconfiguring it to do what you
need.
I have to go out of my way to *stop* NetworkManager from running and
to configure a fixed IP address.
On Sun, Apr 13, 2014 at 10:18 AM, Richard W.M. Jones
rjo...@redhat.com wrote:
Unfortunately NetworkManager can't handle brief network outages
without dropping the connection (RHBZ#1022954 comment 3). This isn't
desirable for servers that have ethernet and fixed IP addresses.
Hello,
Please see:
- http://www.ietf.org/mail-archive/web/dane/current/msg06469.html
- https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
These two threads are about handling of Authenticated Data(AD) bit by the stub
resolvers. There two proposed solutions for this problem:
On 04/11/2014 05:19 PM, Lennart Poettering wrote:
On Fri, 11.04.14 19:05, Miloslav Trmač (m...@volny.cz) wrote:
There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data model
of /etc/{passwd,shadow} is too
On Sun, Apr 13, 2014 at 02:21:03PM +0200, Markus Mayer wrote:
A new version of a package I maintain added an appdata.xml. As I
haven't handled such files before, I looked up the internet for some
information. The only helpful hint I found, was a commit adding
appdata support to the qt-creator
But you can't account for every captive portal in the world. This is why
the cache is a bad idea, because you can't possibly account for every
system that is captive like this.
Yes we can by monitoring for captivity signs when a new network is
joined. Again, please yum install
On Mon, 14 Apr 2014, William Brown wrote:
What is a captivity-sign as you so put it?
Check for clean port 80. It fetches the url specified in
dnssec-triggerd.conf's url: option
(default http://fedoraproject.org/static/hotspot.txt)
If it returns a redirect or a page that does not contain the
On Mon, 2014-04-14 at 00:42 -0400, Paul Wouters wrote:
On Mon, 14 Apr 2014, William Brown wrote:
What is a captivity-sign as you so put it?
Check for clean port 80. It fetches the url specified in
dnssec-triggerd.conf's url: option
(default http://fedoraproject.org/static/hotspot.txt)
A file has been added to the lookaside cache for perl-Mojolicious:
c35b941873cf115ec9a59e901d102e7e Mojolicious-4.93.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit af9bf5a347a06294dfd460994d617314f3d669f6
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Apr 13 10:17:36 2014 +0200
Update to 4.93
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2
https://bugzilla.redhat.com/show_bug.cgi?id=1087029
Bug ID: 1087029
Summary: Please branch for el6
Product: Fedora
Version: rawhide
Component: perl-CPAN-Meta
Severity: low
Assignee: iarn...@gmail.com
Reporter:
perl-PDL has broken dependencies in the epel-7 tree:
On ppc64:
perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
https://bugzilla.redhat.com/show_bug.cgi?id=1087029
Paul Howarth p...@city-fan.org changed:
What|Removed |Added
CC||p...@city-fan.org
https://bugzilla.redhat.com/show_bug.cgi?id=1087029
David Dick dd...@cpan.org changed:
What|Removed |Added
Status|NEW |CLOSED
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
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-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-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
https://bugzilla.redhat.com/show_bug.cgi?id=1087087
Bug ID: 1087087
Summary: Apache-LogFormat-Compiler-0.30 is available
Product: Fedora
Version: rawhide
Component: perl-Apache-LogFormat-Compiler
Assignee: rc040...@freenet.de
https://bugzilla.redhat.com/show_bug.cgi?id=1087087
Ralf Corsepius rc040...@freenet.de changed:
What|Removed |Added
Depends On||1087085
https://bugzilla.redhat.com/show_bug.cgi?id=1085905
--- Comment #4 from Fedora Update System upda...@fedoraproject.org ---
perl-Catalyst-Model-DBIC-Schema-0.61-2.fc20 has been submitted as an update for
Fedora 20.
https://bugzilla.redhat.com/show_bug.cgi?id=1085905
--- Comment #5 from Fedora Update System upda...@fedoraproject.org ---
perl-Catalyst-Model-DBIC-Schema-0.60-5.fc19 has been submitted as an update for
Fedora 19.
https://bugzilla.redhat.com/show_bug.cgi?id=1085905
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
Status|MODIFIED|ASSIGNED
Fixed In
43 matches
Mail list logo
