Re: F21 System Wide Change: The securetty file is empty by default
On 2014-04-11, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: The securetty file is empty by default = https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default [...] Disabling root access via any console device (tty). This is silly. If a system has been broken very badly, then one goes to the machine and fix if from the local TTY. With local access, there is no way how to prevent from rooting the machine. (Let's forget on TPM-guarded or on-line-audited systems now.) So preventing from logging as root on Linux virtual terminal is pointless. Hiding a root access behind two passwords does not bring any better security than using one strong root password. You are making simple things over-complicated. -- Petr -- 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: appdata handling
On 13 April 2014 13:21, Markus Mayer lotharl...@gmx.de wrote: What I'm interested in is: - Directory, Name, ownership and permissions for appdata.xml files Just the default permissions and groups are required, no special handling. - %post/%postun scriptlets (if needed) Nope, none. - If appdata-validate must be run during package build This is up to you as the packager. I would say it's a really good idea, but it depends if you want to deal with upstream not playing by the rules. There are already some upstreams doing things like screenshot/screenshot which until recently tripped up the metadata extractor. - How long does it take that the new appdata is propagated to gnome-software I do new builds nearly every day, but the builds that are shipped in gnome-software and pushed to users is usually updated every month or so. As a side note: build.log contains the following error: error: Couldn't exec /usr/lib/rpm/appdata.prov: No such file or directory Doesn't exist on my system either, so no idea, sorry. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is
substantial work I will just remove the java binding and ask rel eng to
pull the subpackage.
You can't just pull packages. You'll have to properly Obsoletes:
lasso-java it. I am attaching a patch which worked for me (including a
scratchbuild with openjdk). I haven't actually tested the code, but I
guess it should work (it's JNI though so...meh)
A side note: I believe we generally start release numbering at 1 instead
of 0, but of course it doesn't hurt anything...
pgp5kMEDIZEET.pgp
Description: PGP signature
From ef5fd12e46974858b25c2aa032e943514a0bf921 Mon Sep 17 00:00:00 2001
From: Stanislav Ochotnicky sochotni...@redhat.com
Date: Mon, 14 Apr 2014 09:42:19 +0200
Subject: [PATCH] Use OpenJDK instead of GCJ for java bindings
---
lasso.spec | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lasso.spec b/lasso.spec
index e96e39b..d060cf0 100644
--- a/lasso.spec
+++ b/lasso.spec
@@ -11,7 +11,7 @@
Summary: Liberty Alliance Single Sign On
Name: lasso
Version: 2.4.0
-Release: 0%{?dist}
+Release: 1%{?dist}
License: GPLv2+
Group: System Environment/Libraries
Source: https://dev.entrouvert.org/attachments/download/3874/lasso-2.4.0.tar.gz
@@ -55,8 +55,10 @@ Perl language bindings for the lasso (Liberty Alliance Single Sign On) library.
%package java
Summary: Liberty Alliance Single Sign On (lasso) Java bindings
Group: Development/Libraries
-BuildRequires: java-devel, jpackage-utils
-Requires: jre-gcj, jpackage-utils
+BuildRequires: java-devel
+BuildRequires: jpackage-utils
+Requires: java
+Requires: jpackage-utils
Requires: %{name}%{?_isa} = %{version}-%{release}
%description java
@@ -197,6 +199,9 @@ rm -fr %{buildroot}%{_defaultdocdir}/%{name}
%endif
%changelog
+* Mon Apr 14 2014 Stanislav Ochotnicky sochotni...@redhat.com - 2.4.0-1
+- Use OpenJDK instead of GCJ for java bindings
+
* Sat Jan 11 2014 Simo Sorce s...@redhat.com 2.4.0-0
- Update to final 2.4.0 version
- Drop all patches, they are now included in 2.4.0
--
1.9.0
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
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: appdata handling
On Mon, Apr 14, 2014 at 08:44:29AM +0100, Richard Hughes wrote:
On 13 April 2014 13:21, Markus Mayer lotharl...@gmx.de wrote:
As a side note: build.log contains the following error:
error: Couldn't exec /usr/lib/rpm/appdata.prov: No such file or directory
Doesn't exist on my system either, so no idea, sorry.
$ cat /usr/lib/rpm/fileattrs/appdata.attr
%__appdata_provides %{_rpmconfigdir}/appdata.prov
%__appdata_path ^%{_datadir}/appdata/.*\\.appdata\\.xml$
$ rpm -qf /usr/lib/rpm/fileattrs/appdata.attr
rpm-build-4.11.2-2.fc20.x86_64
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
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: Orphaning java-1.5.0-gcj
On 14 April 2014 08:44, Stanislav Ochotnicky sochotni...@redhat.com wrote: On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote: [snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage. You can't just pull packages. You'll have to properly Obsoletes: lasso-java it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh) Not Requires: java-headless ? -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Orphaning java-1.5.0-gcj
On Mon 14 Apr 2014 10:24:46 AM CEST Mat Booth wrote: On 14 April 2014 08:44, Stanislav Ochotnicky sochotni...@redhat.com wrote: On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote: [snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage. You can't just pull packages. You'll have to properly Obsoletes: lasso-java it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh) Not Requires: java-headless ? Haha, you are right. I am violating guidelines I myself proposed :-) A -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpJ2aJH7ilE7.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: fedora-atomic discussion point: /usr/lib/passwd
On 11. 4. 2014 at 17:08:49, Colin Walters wrote: On Fri, Apr 11, 2014 at 1:05 PM, Miloslav Trmač m...@volny.cz wrote: So, having /usr/lib/passwd storing the same limited set of data is not the right long-term thing. Unfortunately, AFAIK the fuller interface isn't ready yet. Yeah, it'd be nice to merge the accountsservice database in to the system db. (And in general, have more consolidation among shadow-utils/sssd/accountsservice) In the really-long-term, really-hand-wavy, future, I think we need to move away from the 32-bit UIDs[3], I agree: http://www.redhat.com/archives/rhl-devel-list/2009-April/msg02456.html [2] Overall I'm strongly convinced that the fully-stateless == fully-atomic-updates model is simply unworkable. We can have stateless/atomic software installation, but we absolutely do need to allow for arbitrary operations to be done on system's state between loading the new version on disk and starting it. Fedora-atomic can have special support for a few classes of state know in advance, but fully general software needs fully general post-installation adjustments. (E.g., where does ALTER TABLE ADD COLUMN on software upgrade fit in the Fedora-atomic model?) An ExecStartPre= entry in the systemd unit. I will play devil's advocate here: 1) What if I don't use systemd to start whatever program needs the updated data? (might not be a daemon for example) 2) Wouldn't that start the migration script every time the daemon starts? Doesn't sound like a pretty solution. Thanks Jan -- 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: default local DNS caching name server
One thing I would like to note is that in machines which don't have a hardware clock, I had problems starting bind and unbound, because the date was back to 1970 in each boot, so the root dns key was not yet valid and there were no valid dns resolvers to update time by ntp. I had to hardcode some ntp servers IP addresses to perform the ntp queries at boot time. This was using the OpenWrt distro in a mips router, I don't know if we can face this kind of problem in ARM machines. I guess all x86 have hardware clock, doesn't they? Regards, Juan. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: SCL
= Proposed System Wide Change: SCL = https://fedoraproject.org/wiki/Changes/SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com 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. * Policies and guidelines: https://fedorahosted.org/fpc/ticket/339 https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29 [1] https://www.softwarecollections.org/en/ [2] https://fedoraproject.org/wiki/User:Mmaslano/SCLinFedora [3] http://copr.fedoraproject.org/coprs/rhscl/ruby193/ ___ 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
[perl-XML-LibXML] 2.0116 bump
commit bd828da35526bd0416750515033f9a57deaeb6f8
Author: Jitka Plesnikova jples...@redhat.com
Date: Mon Apr 14 14:14:19 2014 +0200
2.0116 bump
.gitignore |1 +
perl-XML-LibXML.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d4b1594..22f69f3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,3 +34,4 @@ XML-LibXML-1.70.tar.gz
/XML-LibXML-2.0111.tar.gz
/XML-LibXML-2.0113.tar.gz
/XML-LibXML-2.0115.tar.gz
+/XML-LibXML-2.0116.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index 00942c1..1b7e418 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -3,7 +3,7 @@ Name: perl-XML-LibXML
# https://bugzilla.redhat.com/show_bug.cgi?id=469480
# it might not be needed anymore
# this module is maintained, the other is not
-Version:2.0115
+Version:2.0116
Release:1%{?dist}
Epoch: 1
Summary:Perl interface to the libxml2 library
@@ -114,6 +114,9 @@ fi
%{_mandir}/man3/*.3*
%changelog
+* Mon Apr 14 2014 Jitka Plesnikova jples...@redhat.com - 1:2.0116-1
+- 2.0116 bump
+
* Fri Apr 04 2014 Jitka Plesnikova jples...@redhat.com - 1:2.0115-1
- 2.0115 bump
diff --git a/sources b/sources
index 75417b4..2a4d0e8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-456cde9d6733792e35bc45df566e82ad XML-LibXML-2.0115.tar.gz
+a53a743bf053a0cb4afb41513fb8a684 XML-LibXML-2.0116.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: The securetty file is empty by default
On 04/11/2014 07:23 PM, Kevin Fenzi wrote: You are coming to this conclusion how exactly? The baseWG having to send special endorsement of the proposal in their name. So let's just clear this matter once and for all... Is the baseWG supposed to be responsible for the decisions and direction and the length of maintenance of those 1806 components they self defined as a part of the baseWG? Simple yes or no official response from those driving the .next or wg effort and or FESCo will suffice. That answer will also answer some of the larger questions that have been conveniently left out of those driving the .next and wg effort. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: Fedora 21 Make 4.0 Update
= Proposed System Wide Change: Fedora 21 Make 4.0 Update = https://fedoraproject.org/wiki/Changes/F21Make40 Change owner(s): Patsy Franklin pfran...@redhat.com This change brings Make 4.0 to Fedora 21. == Detailed Description == The purpose of this update is to synchronize Fedora with the most recent Make release. Several new features, new command line options, new variables, and bug fixes have been implemented in Make 4.0. Improved error reporting may result in log file differences. If a recipe fails, the makefile name and linenumber of the recipe are shown. There is one backwards-incompatibility regarding the use of .POSIX. Make 4.0 will adhere to POSIX requirements for backshlash/newline handling. See the link included under Documentation for more details. A new subpackage make-devel will be created containing gnumake.h,a new file containing externally-visible content. == Scope == * Proposal owners: ** Rebase to make-4.0 ** 6 patches need to be updated to work with new sources ** 14 patches will be removed as they are already supported by the make-4.0 rebase ** make.spec will be updated ** local build and test (already completed for glibc and gcc) ** patch created and submitted ** build * Other developers: There are some minor error message changes that may show up as log file differences. If a package's makefile requires a specific version of make, the makefiles may need editing to include make 4.0. * Release engineering: There will be a new subpackage make-devel. * Policies and guidelines: N/A ___ 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
F21 Self Contained Change: Move to ImageFactory For Cloud Image Creation
= Proposed Self Contained Change: Move to ImageFactory For Cloud Image Creation = https://fedoraproject.org/wiki/Changes/Move_to_ImageFactory_For_Cloud_Image_Creation Change owner(s): Ian McLeod imcl...@redhat.com, Dennis Gilmore dgilm...@fedoraproject.org Create images using Anaconda in Koji rather than appliance-creator. Allows non-scratch builds with fedmsg integration for upload service, and also could produce official Docker images. == Detailed Description == Jay Greguske recently added a feature to koji that allows it to create full system disk images using Image Factory. These images can be output both as raw and qcow2 disk images, as well as OVA/OVF bundles compatible with OVirt, VMWare and RHEV-M. They are created by running Anaconda kickstart installs in virt containers and then packaging/encapsulating the results. == Scope == * Proposal owners: The Image Factory support in Fedora koji has already landed and images are already being built using this technique. The work for F21 should mainly involve making sure that the existing cloud kickstart files work when run directly by Anaconda and making any chances needed to ensure that they do. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ 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
Re: Orphaning java-1.5.0-gcj
Thanks a lot,
I will push this patch and rebuild in rawhide.
Simo.
On Mon, 2014-04-14 at 09:44 +0200, Stanislav Ochotnicky wrote:
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is
substantial work I will just remove the java binding and ask rel eng to
pull the subpackage.
You can't just pull packages. You'll have to properly Obsoletes:
lasso-java it. I am attaching a patch which worked for me (including a
scratchbuild with openjdk). I haven't actually tested the code, but I
guess it should work (it's JNI though so...meh)
A side note: I believe we generally start release numbering at 1 instead
of 0, but of course it doesn't hurt anything...
differences between files attachment
(0001-Use-OpenJDK-instead-of-GCJ-for-java-bindings.patch)
From ef5fd12e46974858b25c2aa032e943514a0bf921 Mon Sep 17 00:00:00 2001
From: Stanislav Ochotnicky sochotni...@redhat.com
Date: Mon, 14 Apr 2014 09:42:19 +0200
Subject: [PATCH] Use OpenJDK instead of GCJ for java bindings
---
lasso.spec | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lasso.spec b/lasso.spec
index e96e39b..d060cf0 100644
--- a/lasso.spec
+++ b/lasso.spec
@@ -11,7 +11,7 @@
Summary: Liberty Alliance Single Sign On
Name: lasso
Version: 2.4.0
-Release: 0%{?dist}
+Release: 1%{?dist}
License: GPLv2+
Group: System Environment/Libraries
Source:
https://dev.entrouvert.org/attachments/download/3874/lasso-2.4.0.tar.gz
@@ -55,8 +55,10 @@ Perl language bindings for the lasso (Liberty Alliance
Single Sign On) library.
%package java
Summary: Liberty Alliance Single Sign On (lasso) Java bindings
Group: Development/Libraries
-BuildRequires: java-devel, jpackage-utils
-Requires: jre-gcj, jpackage-utils
+BuildRequires: java-devel
+BuildRequires: jpackage-utils
+Requires: java
+Requires: jpackage-utils
Requires: %{name}%{?_isa} = %{version}-%{release}
%description java
@@ -197,6 +199,9 @@ rm -fr %{buildroot}%{_defaultdocdir}/%{name}
%endif
%changelog
+* Mon Apr 14 2014 Stanislav Ochotnicky sochotni...@redhat.com - 2.4.0-1
+- Use OpenJDK instead of GCJ for java bindings
+
* Sat Jan 11 2014 Simo Sorce s...@redhat.com 2.4.0-0
- Update to final 2.4.0 version
- Drop all patches, they are now included in 2.4.0
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
On Mon, 2014-04-14 at 09:24 +0100, Mat Booth wrote: On 14 April 2014 08:44, Stanislav Ochotnicky sochotni...@redhat.com wrote: On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote: [snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage. You can't just pull packages. You'll have to properly Obsoletes: lasso-java it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh) Not Requires: java-headless ? It may be better I guess, I will change it before pushing a build unless someone tells me otherwise. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: appdata handling
On 04/14/2014 10:51 AM, Richard W.M. Jones wrote:
On Mon, Apr 14, 2014 at 08:44:29AM +0100, Richard Hughes wrote:
On 13 April 2014 13:21, Markus Mayer lotharl...@gmx.de wrote:
As a side note: build.log contains the following error:
error: Couldn't exec /usr/lib/rpm/appdata.prov: No such file or directory
Doesn't exist on my system either, so no idea, sorry.
$ cat /usr/lib/rpm/fileattrs/appdata.attr
%__appdata_provides %{_rpmconfigdir}/appdata.prov
%__appdata_path ^%{_datadir}/appdata/.*\\.appdata\\.xml$
$ rpm -qf /usr/lib/rpm/fileattrs/appdata.attr
rpm-build-4.11.2-2.fc20.x86_64
Its a bug in rpm makefiles. Will fix...
- Panu -
--
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: The securetty file is empty by default
On 04/11/2014 11:18 PM, Jaroslav Reznik wrote: - Original Message - = Proposed System Wide Change: The securetty file is empty by default = https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default Change owner(s): quickbooks quickbooks.off...@gmail.com The securetty file is empty by default There's on-going discussion for this Change on the devel list. https://lists.fedoraproject.org/pipermail/devel/2014-April/197344.html Fedora Base Working Group discussed this Change on today's meeting (2014-04-11) and tends to support counter proposal to remove securetty entirely from the default PAM configuration (not from distribution) as discussed in the thread mentioned above. Base WG would like to ask FESCo to weight it as part of decision making (once this change hits FESCo meeting). Apologies for being late to the discussion as well - just wanted to note that I've been running root-password-less configurations for some time (by using passwd -l to lock out the root account post-install), and later encountered this scenario whereby one of the disks failed fsck and I was dropped into a single-user mode login for maintenance, where I was prompted for... you get it, the root password. Resorted to rebooting and disabling fsck from grub, but how to handle fsck errors should probably be considered as part of this proposed change. Best regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: michel-...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: Remote Journal Logging
= Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. == Detailed Description == Systemd's journal currently provides a replacement for most functionality offered by traditional syslog daemons, with two notable exceptions: arbitrary filtering of messages and forwarding of messages over the network. This Change targets the latter. The high-level goal is to have a mechanism where journal logging can be extended to keep a copy of logs on a remote server, without requiring any maintenance, done fairly efficiently and in a secure way. Two new daemons are added as part of the systemd package: * on the receiver side systemd-journal-remote accepts messages in the Journal Export Format [1]. The export format is a simple serialization of journal entries, supporting both text and binary fields. This means that the messages are transferred intact, apart from the cursors, which specify the location in the journal file. Received entries are stored in local journal files underneath /var/log/journal. Those files are subject to normal journald rules for rotation, and the older ones will be removed as necessary to stay within disk usage limits. Once entries have been written to the journal file, they can be read using journalctl and the journal APIs, and are available to all clients, e.g. Gnome Logs [2]. * on the sender side systemd-journal-upload is a journal client, which exports all available journal messages and uploads them over the network. The (local) cursor of the last message successfully forwarded is stored on disk, so when systemd-journal-upload is restarted (possibly after a reboot of the machine), it will send all recent messages found in the journal and then new ones as they arrive. The communication between the two daemons is done over standard HTTPS, following rather simple rules, so it is possible to create alternate implementations without much work. For example, curl can be easily used to upload journal entries from a text file containing entries in the export format. Basically, the data are sent in an HTTP POST to /upload with Content- Type: application/vnd.fdo.journal. When doing live forwarding, the size of the transfer cannot be known in advance, so Transfer-Encoding: chunked is used. All communication is encrypted, and the identity of both sides is verified by checking for appropriate signatures on the certificates. == Scope == * Proposal owners: The code in systemd for systemd-journal-remote and systemd-journal-upload will have to be added. The first is done, and has already been released in the latest Rawhide systemd package. The second is mostly done, and will be submitted upstream soon. Necessary units will have to be created, and a location with suitable permissions will have to be created so that systemd- journal-remote can run unprivileged. This means that systemd-journal-remote should probably be packaged as a separate subpackage, similarly to systemd- journal-gatewayd. systemd-journal-upload uses libcurl, and thus should be also packaged as a separate subpackage to avoid introducing a new dependency for systemd. Suitable defaults for timeouts for transfers and maximum accepted entry sizes have to be chosen. A port will have to be picked: systemd-journal-gatewayd uses 19531, so systemd-journal-remote should probably use 19532. Two new users will have to be created when the packages are installed. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] http://www.freedesktop.org/wiki/Software/systemd/export/ [2] https://wiki.gnome.org/Apps/Logs ___ 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
F21 System Wide Change: Ruby193 in SCL
= Proposed System Wide Change: Ruby193 in SCL = https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com 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
Re: F21 Self Contained Change: Remote Journal Logging
On Mon, 14 Apr 2014, Jaroslav Reznik wrote: = Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. == Detailed Description == Systemd's journal currently provides a replacement for most functionality offered by traditional syslog daemons, with two notable exceptions: arbitrary filtering of messages and forwarding of messages over the network. This Change targets the latter. The high-level goal is to have a mechanism where journal logging can be extended to keep a copy of logs on a remote server, without requiring any maintenance, done fairly efficiently and in a secure way. Two new daemons are added as part of the systemd package: * on the receiver side systemd-journal-remote accepts messages in the Journal Export Format [1]. The export format is a simple serialization of journal entries, supporting both text and binary fields. This means that the messages are transferred intact, apart from the cursors, which specify the location in the journal file. Received entries are stored in local journal files underneath /var/log/journal. Those files are subject to normal journald rules for rotation, and the older ones will be removed as necessary to stay within disk usage limits. Once entries have been written to the journal file, they can be read using journalctl and the journal APIs, and are available to all clients, e.g. Gnome Logs [2]. * on the sender side systemd-journal-upload is a journal client, which exports all available journal messages and uploads them over the network. The (local) cursor of the last message successfully forwarded is stored on disk, so when systemd-journal-upload is restarted (possibly after a reboot of the machine), it will send all recent messages found in the journal and then new ones as they arrive. The communication between the two daemons is done over standard HTTPS, following rather simple rules, so it is possible to create alternate implementations without much work. For example, curl can be easily used to upload journal entries from a text file containing entries in the export format. Basically, the data are sent in an HTTP POST to /upload with Content- Type: application/vnd.fdo.journal. When doing live forwarding, the size of the transfer cannot be known in advance, so Transfer-Encoding: chunked is used. All communication is encrypted, and the identity of both sides is verified by checking for appropriate signatures on the certificates. How certificates are managed for sender and receiver parts? Who generates them? Do you require explicit placement of the certificates prior to enabling the service? -- / Alexander Bokovoy -- 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: default local DNS caching name server
On Mon, Apr 14, 2014 at 02:07:07PM +0200, Juan Orti Alcaine wrote: One thing I would like to note is that in machines which don't have a hardware clock, I had problems starting bind and unbound, because the date was back to 1970 in each boot, so the root dns key was not yet valid and there were no valid dns resolvers to update time by ntp. I had to hardcode some ntp servers IP addresses to perform the ntp queries at boot time. This was using the OpenWrt distro in a mips router, I don't know if we can face this kind of problem in ARM machines. I guess all x86 have hardware clock, doesn't they? The NTP Bootstrapping problem is well known. There is an effort to deal with that here (in the context of dnsmasq DNSSEC on OpenWRT/CeroWRT): http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/2244 Search for the word prototype to find a description of one implementation. The nice thing about this switch to dnsmasq is that it does validation of the chain, just ignoring validity times; which presumably would make it harder to exploit as you'd need an actual valid key, rather than just be able to spoof the packets reply of the non-validated query.. There are many other ideas in that thread. -- 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: default local DNS caching name server
On Mon, 14 Apr 2014, William Brown wrote: This seems like a sane(ish) method of doing this. What happens if the hotspot page is down? Why not use a mirror-like setup with yum where you try 2 or 3 mirrors and if they fail then you declare it to be a portal? It has multiple A records matching the redundancy of the fedora infrastructure. *how* can you tell if it's dodgy. You can tell captivity from above, but you can't easily see if an ISP is say TTL tampering or data tampering? TTL tampering does not really affect our operation. When caches are chained, you always get lower TTLs. That's how cached data works. Raising the TTL is only allowed within our confines. Data tampering is detectable by DNSSEC. For those domains that are not protected by DNSSEC we cannot detect tampering. If the publisher want their data integrity, they will have to sign their zones. unbound does not really care about transparent proxy's on port 53. As long as they don't break DNS (and DNSSEC). If they redirect port 53 to some broken DNS server, unbound will try to work around it. If port 53 is broken it will attempt DNS over port 80 of various fedoraproject DNS servers, or DNS over TLS on port 443. How do you setup DNS over TLS? Unbound has this capability already build in. unbound-control activates via (currently via dnssec-triggerd, in the future via NM) using the keywords tcp-upstream or ssl-upstream. Again, how can you guarantee that the fedora infrastructure won't go down? My devils advocate points out we are adding more reliance on third party infrastructure here. Could it again be a case similar to the mirrors where you can become a fedoraproject DNS node to help load balance? Not yet, but it is a thought. Although it is probably more stable and better to than see about getting sponsored services from one of the large ANYcast DNS cloud providers. Note that when you get to the point of needing port 80 or 443 for DNS, you are arguably already on a pretty disfunctional rogue network where you probably shouldn't be on. It hampers your (DNSSEC) security. So you can see these services as better than disconnecting from the network. It's not as much the case, which makes me happier, but I want to know the conditions on which you decide a DNS server is dodgy or not. For a detailed list you will have to check the source code. But it includes thing like DNSSEC records, proper wildcard NSEC(3) records, CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older versions of common DNS software. Cases the IETF actually experienced in the wild. * If a forwarder exists on the network, unbound uses it for all queries. Yes, but not for open wifi. Only for physical wire and secured wifi. Okay. Can this point be made clear on the proposal page? Also the conditions for Physical wire, and secured wifi? Yes, we can do that. There are also a number of tethering situations that may actually be mis-interpreted as secure. IE my phone has a WPA2 hotspot with DNS that goes via 3g. How does unbound treat this? It would only see the secure wifi ... We cannot protect against wired or secure wifi running insecure DNS. We do run our tests and if it works install the forward. If it fails to work we won't install the forward. Consider also some wifi hotspots have their own local zones that are needed, so again, I do think that unbound should use the local forwarder irrespective of network security, because else you may risk breaking things. You sometimes cannot, because often those hotspot routers are old and broken and have crappy DNS proxy/mangling, breaking DNSSEC. That's the premise of how this entire DNS mess started - we could not use DNSSEC when using DNS servers obtained from the network. Anyone injecting rogue domains (what you call local zones) cannot be distinguished from an attack. Those hotspots should use proper DNS names and/or http redirection for those local zones. Although note that currently dnssec-trigger does give you the option to remain in insecure mode which would use the local DNS, and give access to those zones. Or how would you suggest this is solved. For arguments sake lets say: SSID: myawesomeopenhotspot DHCP provides no domain-name info. I CNAME all records to my.hotspot. until authenticated. If this does not do http(s) redirection, than it is a very very broken setup. You would also need to block port 53 to prevent people using 8.8.8.8 to bypass your authentication. So I do not see this in the wild (and I've done the hard work of sitting in many coffee shops for science). hotspots tend to intercept port 80 to a mini web server that only serves a redirect, sometimes without any DNS name, often with a DNS name only resolvable by using their DNS. And that is fully supported by the current solution. There are many possible scenarios to come up with that will not work. There are manual overrides for that. In my years of experience, these kind of problems are far more rare than
Re: F21 System Wide Change: The securetty file is empty by default
On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim sali...@fedoraproject.org wrote: On 04/11/2014 11:18 PM, Jaroslav Reznik wrote: - Original Message - = Proposed System Wide Change: The securetty file is empty by default = https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default Change owner(s): quickbooks quickbooks.off...@gmail.com The securetty file is empty by default There's on-going discussion for this Change on the devel list. https://lists.fedoraproject.org/pipermail/devel/2014-April/197344.html Fedora Base Working Group discussed this Change on today's meeting (2014-04-11) and tends to support counter proposal to remove securetty entirely from the default PAM configuration (not from distribution) as discussed in the thread mentioned above. Base WG would like to ask FESCo to weight it as part of decision making (once this change hits FESCo meeting). Apologies for being late to the discussion as well - just wanted to note that I've been running root-password-less configurations for some time (by using passwd -l to lock out the root account post-install), and later encountered this scenario whereby one of the disks failed fsck and I was dropped into a single-user mode login for maintenance, where I was prompted for... you get it, the root password. Resorted to rebooting and disabling fsck from grub, but how to handle fsck errors should probably be considered as part of this proposed change. You're not the only one: https://bugzilla.redhat.com/show_bug.cgi?id=1045574 https://bugzilla.redhat.com/show_bug.cgi?id=1087528 but I don't think that this is really related to securetty. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
= Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Change owner(s): Martin Briza mbr...@redhat.com KDE SIG Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. == Detailed Description == As described in many articles and discussions, KDM is nearing its end of life and it's time we decided upon the successor. I'm proposing to switch to SDDM, which is a new project that suits our needs perfectly despite its immaturity: As of July 2013, KDM's maintenance consists of bugfixes for the most painful bugs, consisting of only about 20 actual commits to the repository in last two years (excluding translation, themes and merges), adding many new features would require major changes to a lot of the code and there is no active maintainer. SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable against Qt4, supports QtQuick theming and its upstream is quite active. Compared to the current DM, KDM, it currently lacks a few features (such as XDMCP) but adds some other ones (QtQuick themes) or is currently adding them (Keyboard layout switching in the greeter). == Scope == * Proposal owners: ** Create sddm and sddm-kcm packages. ** Change kde-settings and the spin-kickstarts to provide SDDM package instead of KDM ** (eventually) exclude KDM from the kde-workspace package * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ 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
[perl-Test-Aggregate] Do not touch Test::Builder internals
commit 0fd4f7174d73d1163d65a94bca92ae6adaeadf9f
Author: Petr Písař ppi...@redhat.com
Date: Mon Apr 14 16:22:04 2014 +0200
Do not touch Test::Builder internals
371-Don-t-grab-at-Test-Builder-hash-keys.patch | 38
perl-Test-Aggregate.spec |8 -
2 files changed, 45 insertions(+), 1 deletions(-)
---
diff --git a/Test-Aggregate-0.371-Don-t-grab-at-Test-Builder-hash-keys.patch
b/Test-Aggregate-0.371-Don-t-grab-at-Test-Builder-hash-keys.patch
new file mode 100644
index 000..41ab6f2
--- /dev/null
+++ b/Test-Aggregate-0.371-Don-t-grab-at-Test-Builder-hash-keys.patch
@@ -0,0 +1,38 @@
+From a58e3c83d93dae030de7cbba025d69298b93fd64 Mon Sep 17 00:00:00 2001
+From: Michael G. Schwern mschw...@cpan.org
+Date: Mon, 14 Apr 2014 16:17:37 +0200
+Subject: [PATCH] Don't grab at Test::Builder hash keys
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Test::Aggregate grabs at an internal Test::Builder hash key rather
+than going through an accessor. $BUILDER-{Test_Results} can be
+gotten through $BUILDER-details. Since you only want the current
+test number, $BUILDER-current_test is fine.
+
+Undocumented assumptions about Test::Builder will break in 2.0.
+
+https://rt.cpan.org/Public/Bug/Display.html?id=64604
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ lib/Test/Aggregate.pm | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/Test/Aggregate.pm b/lib/Test/Aggregate.pm
+index aeb3ea9..f4c1f6c 100644
+--- a/lib/Test/Aggregate.pm
b/lib/Test/Aggregate.pm
+@@ -303,7 +303,7 @@ sub run {
+ # some tests may have been run in BEGIN blocks. This is deprecated and
+ # now warns
+ my $tab = 'Test::Aggregate::Builder';
+-$BUILDER-{$tab}{last_test} = @{ $BUILDER-{Test_Results} } || 0;
++$BUILDER-{$tab}{last_test} = $BUILDER-current_test || 0;
+ $BUILDER-{$tab}{aggregate_program} = $self-{aggregate_program};
+
+ my $current_test = 0;
+--
+1.9.0
+
diff --git a/perl-Test-Aggregate.spec b/perl-Test-Aggregate.spec
index 9a2e4c8..58ce36c 100644
--- a/perl-Test-Aggregate.spec
+++ b/perl-Test-Aggregate.spec
@@ -1,12 +1,14 @@
Name: perl-Test-Aggregate
Version:0.371
-Release:1%{?dist}
+Release:2%{?dist}
# lib/Test/Aggregate.pm - GPL+ or Artistic
# lib/Test/Aggregate/Builder.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Aggregate *.t tests to make them run faster
Source:
http://search.cpan.org/CPAN/authors/id/R/RW/RWSTAUNER/Test-Aggregate-%{version}.tar.gz
+# Do not touch Test::Builder internals that will change in 2.0, CPAN RT#64604
+Patch0: Test-Aggregate-0.371-Don-t-grab-at-Test-Builder-hash-keys.patch
Url:http://search.cpan.org/dist/Test-Aggregate
BuildArch: noarch
@@ -52,6 +54,7 @@ are expensive to load, this can dramatically speed up a test
suite.
%prep
%setup -q -n Test-Aggregate-%{version}
+%patch0 -p1
%build
perl Build.PL installdirs=vendor
@@ -70,6 +73,9 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/*.3*
%changelog
+* Mon Apr 14 2014 Petr Pisar ppi...@redhat.com - 0.371-2
+- Do not touch Test::Builder internals (CPAN RT#64604)
+
* Mon Apr 14 2014 Petr Pisar ppi...@redhat.com - 0.371-1
- 0.371 bump
--
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: Orphaning java-1.5.0-gcj
On Mon, 2014-04-14 at 09:44 +0200, Stanislav Ochotnicky wrote: On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote: [snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage. You can't just pull packages. You'll have to properly Obsoletes: lasso-java it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh) A side note: I believe we generally start release numbering at 1 instead of 0, but of course it doesn't hurt anything... Ok the patch worked fine for building on my F20, which I did as a test, however it failed the build in rawhide. The only clue I can get is this: configure: WARNING: unable to include jni.h however I got the same warning in F20 w/o causing the build to fail. Here build fails in the sense that the configure script thinks there is no java available at all and just skips building the jni stuff and then rpm fails to find the .so and .jar files. Help ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-atomic discussion point: /usr/lib/passwd
On Mon, Apr 14, 2014 at 1:43 AM, Jan Zelený jzel...@redhat.com wrote: 1) What if I don't use systemd to start whatever program needs the updated data? (might not be a daemon for example) Right, for say Evolution which runs in a user session, it obviously has to do any mail format migrations when it starts in the session. One way to view this is we're making system software behave the same way user session software always was forced to. And in a modern world where we have systemd, everything is consistently tracked and logged. 2) Wouldn't that start the migration script every time the daemon starts? Doesn't sound like a pretty solution. There are a few ways around this. The simplest is to keep around a stamp file. It works a lot better of course if schema migrations are a builtin function of the service. Then again I'd say neither of these are good for services which are actually important - if your servers are dedicated to running Wordpress, you're probably going to want to manage it more directly and not out of %post or ExecStartPre. -- 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: SDDM as the default KDE display manager instead of KDM
On Mon, Apr 14, 2014 at 9:40 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Change owner(s): Martin Briza mbr...@redhat.com KDE SIG Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. snip == Scope == * Proposal owners: ** Create sddm and sddm-kcm packages. ** Change kde-settings and the spin-kickstarts to provide SDDM package instead of KDM ** (eventually) exclude KDM from the kde-workspace package Could you elaborate how this would impact using GDM to boot into a KDE session? From a packaging perspective, would KDE now Require SDDM or would it be possible to install it without having SDDM installed? 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
[Bug 1085432] perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085432 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Depends On||1087536 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1087536 [Bug 1087536] Review Request: perl-HTML-FormFu-MultiForm - Handle multi-page/stage forms -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9payU2GCFya=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 3 packages were orphaned openstack-nova [EL-6,devel,f19,f20] was orphaned by xqueralt OpenStack Compute (nova) https://admin.fedoraproject.org/pkgdb/acls/name/openstack-nova openstack-glance [EL-6,devel,f19,f20] was orphaned by markmc OpenStack Image Service https://admin.fedoraproject.org/pkgdb/acls/name/openstack-glance python-novaclient [EL-6,f19,f20] was orphaned by markmc Python API and CLI for OpenStack Nova https://admin.fedoraproject.org/pkgdb/acls/name/python-novaclient 4 packages unorphaned - vpopovicunorphaned : openstack-nova [EL-6,devel,f19,f20] pbrady unorphaned : openstack-glance [EL-6,devel,f19,f20] dbhole unorphaned : java-1.5.0-gcj [f20] jruzickaunorphaned : python-novaclient [EL-6,f20] 5 packages were retired rubygem-clouddb [EL-6,devel,f19,f20] was retired by aeperezt Ruby interface into the Rackspace Cloud DB service https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-clouddb appliance-tools [EL-5] was retired by ausil Tools for building Appliances https://admin.fedoraproject.org/pkgdb/acls/name/appliance-tools rubygem-bcrypt-ruby [devel] was retired by jstribny bcrypt-ruby provides a simple, humane wrapper to bcrypt() for safely handling passwords https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-bcrypt-ruby java-1.5.0-gcj [devel,f19,f20] was retired by dbhole JPackage runtime compatibility layer for GCJ https://admin.fedoraproject.org/pkgdb/acls/name/java-1.5.0-gcj django-typepad [EL-6] was retired by lbazan A helper Django app for making TypePad applications https://admin.fedoraproject.org/pkgdb/acls/name/django-typepad 8 packages changed owner limbgave to sochotni : python-dpath [epel7] limbgave to lkundrak : Pound [epel7,epel7] limbgave to jpopelka : netplug [EL-6] limbgave to ktdreyer : unrtf [EL-6,epel7] limbgave to mmorsi : rubygem-net-http-persistent [EL-6,epel7] limbgave to pghmcfc: perl-Convert-Bencode [EL-6,epel7] limbgave to lkundrak : fakeroot [epel7] limbgave to ramkrsna : python-posix_ipc [EL-6,epel7] Sources: https://github.com/pypingou/fedora-owner-change -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Nightly live and image composes - mailing list
- Nightly live and image composes http://dl.fedoraproject.org/pub/alt/nightly-composes This page lists testing composes created nightly for all currently approved spins from the Spins SIG git repository. Any questions or problems, please post to the Spins SIG mailing list. a href=mailto:fedora-sp...@lists.fedoraproject.org;mailing list/a. - lists.fedoraproject.org Mailing Lists https://lists.fedoraproject.org/mailman/listinfo/fedora-spins No such list fedora-spins Should it point to sp...@lists.fedoraproject.org? poma -- 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: Nightly live and image composes - mailing list
On Mon, Apr 14, 2014 at 14:53:04 +0200, poma pomidorabelis...@gmail.com wrote: - Nightly live and image composes http://dl.fedoraproject.org/pub/alt/nightly-composes This page lists testing composes created nightly for all currently approved spins from the Spins SIG git repository. Any questions or problems, please post to the Spins SIG mailing list. a href=mailto:fedora-sp...@lists.fedoraproject.org;mailing list/a. - lists.fedoraproject.org Mailing Lists https://lists.fedoraproject.org/mailman/listinfo/fedora-spins No such list fedora-spins Should it point to sp...@lists.fedoraproject.org? Yes. -- 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: default local DNS caching name server
unbound does not really care about transparent proxy's on port 53. As long as they don't break DNS (and DNSSEC). If they redirect port 53 to some broken DNS server, unbound will try to work around it. If port 53 is broken it will attempt DNS over port 80 of various fedoraproject DNS servers, or DNS over TLS on port 443. How do you setup DNS over TLS? Unbound has this capability already build in. unbound-control activates via (currently via dnssec-triggerd, in the future via NM) using the keywords tcp-upstream or ssl-upstream. I meant for say bind, but okay. It's not as much the case, which makes me happier, but I want to know the conditions on which you decide a DNS server is dodgy or not. For a detailed list you will have to check the source code. But it includes thing like DNSSEC records, proper wildcard NSEC(3) records, CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older versions of common DNS software. Cases the IETF actually experienced in the wild. IE, If I have an out of box bind9 setup with a few zones, or even 100s of zones, these cases should never be triggered. I would hate to see the dodgy DNS check giving a false positive on networks that are actually sane ... Such checks need to be conservative in their triggers IMO. * If a forwarder exists on the network, unbound uses it for all queries. Yes, but not for open wifi. Only for physical wire and secured wifi. Okay. Can this point be made clear on the proposal page? Also the conditions for Physical wire, and secured wifi? Yes, we can do that. Thanks. okay, but lets combine these two points. My ISP mucks with the TTL of some website from say 300 to 3000. Unbound would respect this to that amount, or to the TTL max (Which is still 86400 iirc). If you aren't flushing the cache between networks you could end up with: * Suboptimal routes causing a poor user experience. * Incorrect cached zone data moving between networks with different DNS views of the world. If we believe that artificial increase of TTL is a common manglement, we can have dnssec-trigger (or the NM integrated version of that) check for such mangling. I'm reluctant to try and solve every _imaginable_ problem out there. If your ISPs badness causes suboptimal routes, than that's not the end of the world, and you have your ISP to blame. One ISP shouldn't be responsible for every fedora user flushing caches all the time. Let's deal with this problem when we actually find it is a real world problem. It actually is quite common from certain Australian ISPs especially the cheap ones (You get what you pay for ... ) Even if we ignore the TTL mangling, the first issue of incorrect cached zone data moving between networks is a real world issue IMO. As previously mention, split view business networks. I believe you have said this is solved by flushing . forwarder between networks that are secure. * On an open (Insecure) access point, unbound bypasses the local forwarder, except for names listed in the single valued attribute options domain-name from dhcp No, we cannot do that. As I said, a rogue hotspot could give the domain-name corp.paypal.com to fool me into thinking I'm connecting to my internal corporate network. We cannot automatically insert those forwards on open wifi, unless the user manually performs an override. Okay, This is another point to make clear on the wiki. I thought this was what you were saying was the case on open wifi. * On a secure network (Encrypted wifi, lan) unbound will use the forwarders as provided by DHCP. Provided they are functional (eg don't break DNSSEC) Again, can you on the wiki detail the functional requirements. The reason I ask these are documented, is so that when other network admins (like myself) come along, you have already had the argument and provided the justification and detailed explanations of these edge cases. * Unbound will flush the cache between authenticated networks. (If I read your last point correctly) If we did a . forward, yes. Moved ... Ignoring the TTL change, lets just look at flushing between network state change. This would solve both the dot points listed. You only need to rebuild the cache on first network reconnect meaning: only rebuild? You are asking everyone else to do hundreds of queries for each time to join their 3G network. Remember, when validating, you don't just have one record for a queried A record. Since you need to recurse and do all the intermediate queries too because otherwise you don't have the records to do full DNSSEC validation. It's not a reasonably thing to flush the cache. We are working hard on ensuring the user _hits_ their cache and gains speed up (including pre-fetching). Waiting on various roundtrips for DNS over 3G is going to cause a lot more delays than a suboptimal route. Your workaround will actually
F21 System Wide Change: Smaller Cloud Image Footprint
= Proposed System Wide Change: Smaller Cloud Image Footprint = https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint Change owner(s): Sandro Mathys r...@fedoraproject.org Cloud SIG Shrink the footprint of our cloud images as far as reasonably, and within the given timeframe, possible. == Detailed Description == Space is precious in the cloud, therefore the Cloud SIG tries to keep the images' footprint as small as reasonably possible. Several approaches are ongoing in this regard and while they are hardly worth mentioning individually, the combined effort is going to be noticeable. == Scope == As mentioned, there's really various changes that are quite independent of each other but share the common goal. * Proposal owners: ** Replace NetworkManager, etc. with systemd-networkd. ** Make sure only just kernel-core, not kernel and kernel-drivers, is installed (see the related change: Modular Kernel Packaging for Cloud [1]). ** Make sure only the packages really required are installed. ** Use %packages --excludedocs to to skip installing docs. ** Use %packages --instLangs= to ship only just English. ** Tweak the locales (in %post) so that local-archive ships with only just English instead of all languages. We might skip this one if it seems too much tinkering. Work is going on to have proper support for this in the glibc package (see rhbz#156477 [2] - also, c#30 shows the necessary tinkering). * Other developers: ** Packages that are part of any cloud image (and in the long run all packages) must use %license instead of %doc for the license file(s) so we can skip shipping docs but still ship licenses. (See separate change Use license macro in RPMs for packages in Cloud Image [3] ** cloud-init should no longer require python-cheetah and needs to be refactored (upstream) accordingly. * Release engineering: Nothing. * Policies and guidelines: ** Packaging Guidelines need to reflect that license files must be tagged with %license instead of %docs (FPC#411 [4]). [1] https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud [2] https://bugzilla.redhat.com/show_bug.cgi?id=156477 [3] https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_packages_in_Cloud_Image packages in Cloud Image [4] https://fedorahosted.org/fpc/ticket/411 ___ 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
F21 System Wide Change: Use license macro in RPMs for packages in Cloud Image
= Proposed System Wide Change: Use license macro in RPMs for packages in Cloud Image = https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_packages_in_Cloud_Image Change owner(s): Matthew Miller mattdm at fedoraproject, Tom Callaway spot at fedoraproject Use new %license macro to separate license files from documentation, so the latter can be excluded from container images without stripping license information which must be included. == Detailed Description == Background: 1. Right now, license files are required to be marked as %doc files. 2. There has long been a nodocs parameter to RPM which skips all doc files. 3. In addition to the desired space-savings, this installs packages without their possibly-mandatory license files This interaction hasn't been problematic before, because generally using nodocs is an endpoint choice with no distribution after that. But now, we are looking at building some official cloud and container images with nodocs, so it suddenly becomes important. As a bonus, in the future, %license may handle automatic hardlinking of identical license files. Specifically, I propose: 1. We change the guidelines 2. We start doing it for new packages 3. We file a F21 system-wide change (that is, this change) for a proven packager to change all the packages that land in the cloud image for F21 (roughly, @core + dependencies plus a few extras) 4. We may file a similar change for other packages in the base design for F22, but the work/reward ratio is much lower. 5. It may also be valuable to focus on a few key packages commonly used in Docker images (like httpd) 6. Other packages updated on a as-time-permits/best-effort basis. == Scope == * Proposal owners: Update guidelines. Identify target packages. Tom will use provenpackager to make changes to spec files. * Other developers: Be aware of possible provenpackager changes. Update other packages on best-effort basis if interested. * Release engineering: none * Policies and guidelines: Yes; packaging guidelines change. See [1] [1] https://fedorahosted.org/fpc/ticket/411 ___ 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
Re: Nightly live and image composes - mailing list
On Mon, 14 Apr 2014 10:01:00 -0500 Bruno Wolff III br...@wolff.to wrote: On Mon, Apr 14, 2014 at 14:53:04 +0200, poma pomidorabelis...@gmail.com wrote: - Nightly live and image composes http://dl.fedoraproject.org/pub/alt/nightly-composes This page lists testing composes created nightly for all currently approved spins from the Spins SIG git repository. Any questions or problems, please post to the Spins SIG mailing list. a href=mailto:fedora-sp...@lists.fedoraproject.org;mailing list/a. - lists.fedoraproject.org Mailing Lists https://lists.fedoraproject.org/mailman/listinfo/fedora-spins No such list fedora-spins Should it point to sp...@lists.fedoraproject.org? Yes. Fixed. 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: default local DNS caching name server
On Mon, 2014-04-14 at 10:21 -0400, Paul Wouters wrote: Or how would you suggest this is solved. For arguments sake lets say: SSID: myawesomeopenhotspot DHCP provides no domain-name info. I CNAME all records to my.hotspot. until authenticated. If this does not do http(s) redirection, than it is a very very broken setup. You would also need to block port 53 to prevent people using 8.8.8.8 to bypass your authentication. So I do not see this in the wild (and I've done the hard work of sitting in many coffee shops for science). hotspots tend to intercept port 80 to a mini web server that only serves a redirect, sometimes without any DNS name, often with a DNS name only resolvable by using their DNS. And that is fully supported by the current solution. Many of the captive portals I've seen block all access to anything except the portal login. You don't get to ping anything, you don't get to DNS anything (let alone 8.8.8.8) and you certainly don't get to send traffic outside the portal. Only when you've authenticated does it release you. Sometimes that's done with VLANs and DHCP renewal, sometimes it's done internally with firewall rules or something. But another scenario I've seen: older Netgear routers which intercept www.routerlogin.net as the setup page. The instructions literally are: 1) connect your computer to the router with a cable 2) go to www.routerlogin.net 3) follow the setup guide instructions Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the portal would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router. Dan -- 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
On Mon, Apr 14, 2014 at 05:19:17PM +0300, Alexander Bokovoy wrote: How certificates are managed for sender and receiver parts? By some external means... This could be automated, e.g. using certmaster, but I don't want to tie to a specific certificate distribution implementation. Who generates them? Do you require explicit placement of the certificates prior to enabling the service? Yes. I want to push towards having the certificates in place in the default location, although it is of course possible to specify an alternate location through the config file, or even turn off certificate checking, but the defaults are supposed to be secure. 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 Self Contained Change: Remote Journal Logging
On Mon, 14 Apr 2014, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 14, 2014 at 05:19:17PM +0300, Alexander Bokovoy wrote: How certificates are managed for sender and receiver parts? By some external means... This could be automated, e.g. using certmaster, but I don't want to tie to a specific certificate distribution implementation. Ok. I was worried you'll do the opposite. ;) Who generates them? Do you require explicit placement of the certificates prior to enabling the service? Yes. I want to push towards having the certificates in place in the default location, although it is of course possible to specify an alternate location through the config file, or even turn off certificate checking, but the defaults are supposed to be secure. Agreed. -- / Alexander Bokovoy -- 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: default local DNS caching name server
On Mon, 14 Apr 2014, Dan Williams wrote: But another scenario I've seen: older Netgear routers which intercept www.routerlogin.net as the setup page. The instructions literally are: 1) connect your computer to the router with a cable 2) go to www.routerlogin.net 3) follow the setup guide instructions Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the portal would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router. I don't know what they do when you query for anything else. If there is no hotspot redirection on port 80/443 and their DNS server works properly, and your wifi was secure, you would then get their forward and the above would work. If it is an open wifi, we would not install the forward and you would not get there. but in the current setup, you can pick hotspot login mode and it puts their DNS in place, and than you will reach it. Note that manual hotspot login sessions require you to manually mark them for reprobe as well because apparently we cannot probe for it because you manually overrode it. If you switch networks, and bring up the VPN, you'll encounter weird things. While still in hotspot mode, the VPN forward put into unbound is not active because you are not using unbound yet (until you hit reprobe to leave hotspot signon mode. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote: On Mon, 14 Apr 2014, Dan Williams wrote: But another scenario I've seen: older Netgear routers which intercept www.routerlogin.net as the setup page. The instructions literally are: 1) connect your computer to the router with a cable 2) go to www.routerlogin.net 3) follow the setup guide instructions Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the portal would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router. I don't know what they do when you query for anything else. If there is no hotspot redirection on port 80/443 and their DNS server works properly, and your wifi was secure, you would then get their forward and the above would work. If it is an open wifi, we would not install Since the user is setting things up, they can pick whether it's open or protected wifi. We don't control that. the forward and you would not get there. but in the current setup, you can pick hotspot login mode and it puts their DNS in place, and than you will reach it. Note that manual hotspot login sessions require you Ok, that could be a problem. This is a user setting up wifi on a router they just bought, so it has no upstream connection yet, is not yet configured at all, and they are just following the directions in the printed brochure they got with the router. Which obviously won't say anything about hotspot login mode. Also, this is the procedure you follow if you reset the router to factory defaults, which support people sometimes tell you to do. So we'd run into the issue if/when the user contacted Netgear technical support too. Dan to manually mark them for reprobe as well because apparently we cannot probe for it because you manually overrode it. If you switch networks, and bring up the VPN, you'll encounter weird things. While still in hotspot mode, the VPN forward put into unbound is not active because you are not using unbound yet (until you hit reprobe to leave hotspot signon mode. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Tue, 15 Apr 2014, William Brown wrote: How do you setup DNS over TLS? Unbound has this capability already build in. unbound-control activates via (currently via dnssec-triggerd, in the future via NM) using the keywords tcp-upstream or ssl-upstream. I meant for say bind, but okay. bind does not support this. For a detailed list you will have to check the source code. But it includes thing like DNSSEC records, proper wildcard NSEC(3) records, CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older versions of common DNS software. Cases the IETF actually experienced in the wild. IE, If I have an out of box bind9 setup with a few zones, or even 100s of zones, these cases should never be triggered. I would hate to see the dodgy DNS check giving a false positive on networks that are actually sane ... Such checks need to be conservative in their triggers IMO. Correct. It only happens for bind4/bind8 or broken old bind9s, djbdns/cache, but mostly because of 5 year old dnsmasq versions embedded in the platforms as dns proxy. Even if we ignore the TTL mangling, the first issue of incorrect cached zone data moving between networks is a real world issue IMO. As previously mention, split view business networks. I believe you have said this is solved by flushing . forwarder between networks that are secure. Correct. If an ISP starts modifying DNS content, it is simply an attack. You have no trust relationship with them. The reason I ask these are documented, is so that when other network admins (like myself) come along, you have already had the argument and provided the justification and detailed explanations of these edge cases. Understood. suboptimal route. Your workaround will actually be detrimental to the user experience. Note, I'm trying to optimise that path too, see: http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-00 These two statements really seem to contradict. On one hand you say that moving between secure networks, the . forwarder gets flushed. But then you say the whole point is that it isn't flushed! The number of flushes should be limited as much as possible. It is only to accomdate certain networks that we flush the cache. Our preference is to never flush. But we accept sometimes it cannot be avoided to support certain type of DNS deployments. On my 3g tether, and work, both would be secure wifi, so according to this both flush (Which really, I like :) ) But according to what you are saying they shouldn't do that, but they do? The price we have to pay to support some kind of setups. We can also add an option that tells us to not flush certain (secure) networks because we know there is no special casing there. Those are tunings we can do later. Really, it seems like the only time the cache *won't* flush is when I move from a secure wifi to an insecure wifi. What happens when I move from the insecure wifi back? I would like to argue that given not all domains have DNSSEC yet, you can't trust the records from the insecure wifi, so at the least on insecure wifi interface down, you should flush the non-dnssec cached records. Whether the network is secure or insecure only has an effect on the forwarder state, and thus potentially certain domains handled by that forwarder. DNSSEC validation is not skipped in those cases, so data can still be trusted. Non-DNSSEC domains are always vulnerable to a MITM. Since they can just sign their domains, I don't feel personally that we need to go out of our ways to accomodate those insecure setups. If people will differently, again we could tune and make a toggle. Which collecting this seems to mean (Current functional state): Secure to secure network - Flush . cache. Secure to insecure network - Keep cache Insecure to Insecure network - Keep cache Insecure to secure network - Keep cache. I think in the perfect world, assuming that insecure networks are insecure shouldn't it be? Secure to secure network - Flush . cache. Secure to insecure network - Keep cache Insecure to insecure network - Keep DNSSEC cache only. Insecure to secure network - Keep DNSSEC cache only. I'll think about these a little more. Note that keep DNSSEC cache only is currently not an option implemented by unbound. The only records you can really guarantee as being the same on all network views are ones signed by DNSSEC. Not really, you can have differently signed zones for the same name for internal and external view. Hopefully with at least the same DNSKEY, but even that could be different. It would require a manual configuration though of files in /etc/unbound/*.d/ Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 14 Apr 2014, Dan Williams wrote: Ok, that could be a problem. This is a user setting up wifi on a router they just bought, so it has no upstream connection yet, is not yet configured at all, and they are just following the directions in the printed brochure they got with the router. Which obviously won't say anything about hotspot login mode. But dnssec-trigger detects the hotspot detection portal page didn't return the expected page content of OK and will suggest to the user to go into hotspot signon mode. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, Apr 14, 2014 at 9:06 AM, Dan Williams d...@redhat.com wrote: On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote: On Mon, 14 Apr 2014, Dan Williams wrote: But another scenario I've seen: older Netgear routers which intercept www.routerlogin.net as the setup page. The instructions literally are: 1) connect your computer to the router with a cable 2) go to www.routerlogin.net 3) follow the setup guide instructions Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the portal would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router. I don't know what they do when you query for anything else. If there is no hotspot redirection on port 80/443 and their DNS server works properly, and your wifi was secure, you would then get their forward and the above would work. If it is an open wifi, we would not install Since the user is setting things up, they can pick whether it's open or protected wifi. We don't control that. the forward and you would not get there. but in the current setup, you can pick hotspot login mode and it puts their DNS in place, and than you will reach it. Note that manual hotspot login sessions require you Ok, that could be a problem. This is a user setting up wifi on a router they just bought, so it has no upstream connection yet, is not yet configured at all, and they are just following the directions in the printed brochure they got with the router. Which obviously won't say anything about hotspot login mode. Also, this is the procedure you follow if you reset the router to factory defaults, which support people sometimes tell you to do. So we'd run into the issue if/when the user contacted Netgear technical support too. If you want to get really fancy, you could try to detect a state in which there is no connection to the internet, the router has an address 192.168.*.1, and the router is listening on TCP port 80, and suggest an alternate you are connected to a possibly unconfigured router mode. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Python 3 and mod_wsgi
I naively ported my Django app to Python 3 and didn't realize WSGI was going to be an issue. I saw python3-django was available for Fedora 20 and thought I was all set until I saw in my httpd logs that python2.7 seems to be the assumed default for mod_wsgi. After reading the README and more, I see the writing on the wall: If you have multiple versions of Python installed and you are not using that which is the default, you may have to organise that the PATH inherited by the Apache application when run will result in Apache finding the alternate version. Alternatively, the WSGIPythonHome directive should be used to specify the exact location of the Python installation corresponding to the version of Python compiled against. If this is not done, the version of Python running within Apache may attempt to use the Python modules from the wrong version of Python. I take this to mean that merely fiddling with WSGIPythonHome alone will be insufficient and that I would need to recompile the package. Is that correct, or did I miss a Python3-specific mod_wsgi package or some other neater solution? If I am truly forced to recompile -- as reversing the Python 3 is really undesirable at this point -- is there any reason Fedora couldn't have two mod_wsgi packages (one for Python2 and another for Python3)? -- John Florian -- 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: default local DNS caching name server
On Mon, 14 Apr 2014, Juan Orti Alcaine wrote: One thing I would like to note is that in machines which don't have a hardware clock, I had problems starting bind and unbound, because the date was back to 1970 in each boot, so the root dns key was not yet valid and there were no valid dns resolvers to update time by ntp. I had to hardcode some ntp servers IP addresses to perform the ntp queries at boot time. This was using the OpenWrt distro in a mips router, I don't know if we can face this kind of problem in ARM machines. I guess all x86 have hardware clock, doesn't they? That's a problem we are aware of. tlsdate is one method, but I believe the openwrt people now also do some other things. Possibly saving the time on shutdown so you have a reasonable time on startup. For DNSSEC, we found that you need accurancy within a couple of hours because some RRSIGs in the path to .org (for ntp.pool.org) were pretty short. But I think adding a few ntp servers by IP address could be good for the standard ntp config as well - provided there are IPs that can be used for that in the pool. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
On 04/14/2014 07:32 AM, Simo Sorce wrote: Ok the patch worked fine for building on my F20, which I did as a test, however it failed the build in rawhide. The only clue I can get is this: configure: WARNING: unable to include jni.h What's in the configure log file regarding this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: The securetty file is empty by default
Jóhann B. Guðmundsson (johan...@gmail.com) said: So let's just clear this matter once and for all... Is the baseWG supposed to be responsible for the decisions and direction and the length of maintenance of those 1806 components they self defined as a part of the baseWG? In the same way that I'd expect the WS, Server, or Cloud WGs to comment on changes filed that affect their deliverables if they feel they aren't what Fedora should be doing in those areas, I'd expect the Base WG to comment on system-wide changes that affect the common base of the products if they think there may be issues. It can be discussed where the border of what the base WG might look at is, but I'm comfortable with the default PAM configuration being inside it. Bill -- 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: appdata handling
Richard Hughes (hughsi...@gmail.com) said: - How long does it take that the new appdata is propagated to gnome-software I do new builds nearly every day, but the builds that are shipped in gnome-software and pushed to users is usually updated every month or so. A FAQ related to this that's not on the upstream page: How do I locally check changes to my appdata inside gnome-software, as opposed to just appdata-validate? I tried this once, and it seemed to be a rather convoluted process. Wondering if I did it wrong? Bill -- 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: Fedora 21 Make 4.0 Update
Jaroslav Reznik (jrez...@redhat.com) said: == Scope == * Proposal owners: ** Rebase to make-4.0 ** 6 patches need to be updated to work with new sources ** 14 patches will be removed as they are already supported by the make-4.0 rebase ** make.spec will be updated ** local build and test (already completed for glibc and gcc) ** patch created and submitted ** build * Other developers: There are some minor error message changes that may show up as log file differences. If a package's makefile requires a specific version of make, the makefiles may need editing to include make 4.0. We'd want this available before the mass rebuild, so we can catch any issues related to it. Has an out-of-band rebuild been done that sees if there are common failures? Bill -- 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
Jaroslav Reznik (jrez...@redhat.com) said: == Scope == As mentioned, there's really various changes that are quite independent of each other but share the common goal. * Proposal owners: ** Replace NetworkManager, etc. with systemd-networkd. ** Make sure only just kernel-core, not kernel and kernel-drivers, is installed (see the related change: Modular Kernel Packaging for Cloud [1]). ** Make sure only the packages really required are installed. ** Use %packages --excludedocs to to skip installing docs. ** Use %packages --instLangs= to ship only just English. ** Tweak the locales (in %post) so that local-archive ships with only just English instead of all languages. We might skip this one if it seems too much tinkering. Work is going on to have proper support for this in the glibc package (see rhbz#156477 [2] - also, c#30 shows the necessary tinkering). How do these changes (especially the first two) work in terms of the cattle-to-pets feature? Bill -- 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
Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. What's the future of gatewayd if this becomes more widely used? Bill -- 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
Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: Ruby193 in SCL = https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com 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. Is the intent to only provide SCL versions of the older ruby rails, or also the current versions (i.e., move to SCL as the rails delivery mechanism going forward)? Bill -- 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: appdata handling
On 14 April 2014 21:10, Bill Nottingham nott...@splat.cc wrote: How do I locally check changes to my appdata inside gnome-software, as opposed to just appdata-validate? Now it's a case of cloning and building https://github.com/hughsie/createrepo_as and then doing ./createrepo_as --basename=test path/to/package.rpm and then copying the ./test.xml.gz file to /usr/share/app-info/xmls/ and then explode test-icons.tar.gz into /usr/share/app-info/icons/test/ -- If you file a ticket here https://github.com/hughsie/createrepo_as/issues then I'll add a script that makes it easy to install the data and write a FAQ entry. I tried this once, and it seemed to be a rather convoluted process. Wondering if I did it wrong? You are an early adopter; somewhat simpler now :) Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Python 3 and mod_wsgi
- Original Message - I naively ported my Django app to Python 3 and didn't realize WSGI was going to be an issue. I saw python3-django was available for Fedora 20 and thought I was all set until I saw in my httpd logs that python2.7 seems to be the assumed default for mod_wsgi. After reading the README and more, I see the writing on the wall: If you have multiple versions of Python installed and you are not using that which is the default, you may have to organise that the PATH inherited by the Apache application when run will result in Apache finding the alternate version. Alternatively, the WSGIPythonHome directive should be used to specify the exact location of the Python installation corresponding to the version of Python compiled against. If this is not done, the version of Python running within Apache may attempt to use the Python modules from the wrong version of Python. I take this to mean that merely fiddling with WSGIPythonHome alone will be insufficient and that I would need to recompile the package. Is that correct, or did I miss a Python3-specific mod_wsgi package or some other neater solution? If I am truly forced to recompile -- as reversing the Python 3 is really undesirable at this point -- is there any reason Fedora couldn't have two mod_wsgi packages (one for Python2 and another for Python3)? AFAIK you can't have 2 mod_wsgi's, each one compiled against a different Python major.minor, loaded by Apache at the same time for various reasons. So the best solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), that would conflict with mod_wsgi. It should be perfectly doable and it shouldn't break anything. CCing Matthias, the owner of mod_wsgi in Fedora - Matthias, what do you think? Regards, Slavek -- John Florian-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1071125] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=1071125 Massimo Paladin massimo.pala...@gmail.com changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |CURRENTRELEASE Last Closed||2014-04-14 16:55:23 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=8Ft6CyC2Hxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F21 System Wide Change: Smaller Cloud Image Footprint
On Mon, Apr 14, 2014 at 04:15:50PM -0400, Bill Nottingham wrote: ** Replace NetworkManager, etc. with systemd-networkd. ** Make sure only just kernel-core, not kernel and kernel-drivers, is installed (see the related change: Modular Kernel Packaging for Cloud [1]). ** Make sure only the packages really required are installed. ** Use %packages --excludedocs to to skip installing docs. ** Use %packages --instLangs= to ship only just English. ** Tweak the locales (in %post) so that local-archive ships with only just English instead of all languages. We might skip this one if it seems too much tinkering. Work is going on to have proper support for this in the glibc package (see rhbz#156477 [2] - also, c#30 shows the necessary tinkering). How do these changes (especially the first two) work in terms of the cattle-to-pets feature? Good question. That script may have options to undo some of this; generally, this kind of minimization isn't so interesting for pets, and some aspects (lack of man pages!) are probably actively unwanted. Also, I know you know this but just as a general clarification: the cloud image isn't currently using NetworkManager anyway but is using the good ol' network initscripts. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-No-Worries/el5] Updating to upstream 1.2, rhbz #1086545.
Summary of changes: 68b8927... Updating to upstream 1.2, rhbz #1086545. (*) (*) 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: Remote Journal Logging
On Mon, Apr 14, 2014 at 04:20:16PM -0400, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. What's the future of gatewayd if this becomes more widely used? gatewayd works in pull mode. Here I'm proposing a push model, where the client (i.e. machine generating the logs) pushes logs to the server at the time of its own chosing. gatewayd is probably better for some use cases, this for others. 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: Reinstalling the bootloader
On Apr 9, 2014, at 12:59 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy li...@colorremedies.com wrote: You need to install or reinstall grub2-efi and shim packages. Aha, a correct answer! Thanks! Based on this hint, I think I figured it out. I updated the wiki accordingly. Can you take a quick look at: https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_systems Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise. It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed. Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg. https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957 I'm not familiar with this usage: efibootmgr -B -b 0 If 0 is the same as then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel. A valid command would be efibootmgr -b 0003 -B or, even better, if anaconda's bootloader installation process were factored out into a command I could run. I don't understand what this means. Being able to do: $ sudo fedora-configure-bootloader would be awesome. It would probably have to take some command line arguments. Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reinstalling the bootloader
On Mon, Apr 14, 2014 at 2:55 PM, Chris Murphy li...@colorremedies.com wrote: On Apr 9, 2014, at 12:59 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy li...@colorremedies.com wrote: You need to install or reinstall grub2-efi and shim packages. Aha, a correct answer! Thanks! Based on this hint, I think I figured it out. I updated the wiki accordingly. Can you take a quick look at: https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_systems Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise. Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh. I tried to clarify it a bit, though. It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed. Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg. https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957 I'm not familiar with this usage: efibootmgr -B -b 0 If 0 is the same as then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel. A valid command would be efibootmgr -b 0003 -B -B -b 0 seems to be the same as -B -b , and my isn't the same as your :) The kernel crash is something else, in any case. or, even better, if anaconda's bootloader installation process were factored out into a command I could run. I don't understand what this means. Being able to do: $ sudo fedora-configure-bootloader would be awesome. It would probably have to take some command line arguments. Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it. Anaconda does this somehow, I think. Even just exposing that would be nice. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby193 in SCL
On Mon, Apr 14, 2014 at 2:17 PM, Bill Nottingham nott...@splat.cc wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: Ruby193 in SCL = https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com 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. Is the intent to only provide SCL versions of the older ruby rails, or also the current versions (i.e., move to SCL as the rails delivery mechanism going forward)? Personally I like the direction that Django is taking by shipping parallel-installable packages. I think this would be doable for Rails. /usr/bin/rails could be handled with alternatives. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reinstalling the bootloader
On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski l...@mit.edu wrote: Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise. Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh. Huh, you're sure? You have to either remove all removable NVRAM boot entries, or you have to remove the file/device the entry points to trigger the use of //BOOT/BOOTarch.efi. If this isn't working, what does happen instead? It just hangs? I tried to clarify it a bit, though. It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed. Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg. https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957 I'm not familiar with this usage: efibootmgr -B -b 0 If 0 is the same as then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel. A valid command would be efibootmgr -b 0003 -B -B -b 0 seems to be the same as -B -b , and my isn't the same as your :) I'm basing it off the entry in your bug 73761. It points to a DVD drive. Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it. Anaconda does this somehow, I think. Even just exposing that would be nice. No all it does is look for a Fedora boot entry in NVRAM and then uses efibootmgr -b -B against it. It doesn't have a mechanism, nor should it, to obliterate everything in NVRAM which can contain a lot more than just boot entries. ls -l /sys/firmware/efi/efivars Two dozen variables. On my Mac there's 50+ items including speaker and brightness level. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reinstalling the bootloader
On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy li...@colorremedies.com wrote: On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski l...@mit.edu wrote: Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise. Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh. Huh, you're sure? You have to either remove all removable NVRAM boot entries, or you have to remove the file/device the entry points to trigger the use of //BOOT/BOOTarch.efi. If this isn't working, what does happen instead? It just hangs? Hmm. I assumed that just asking the system to boot off that disk would do the trick. Apparently not. Removing other entries is hard, given the aforementioned OOPS. :( I tried to clarify it a bit, though. It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed. Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg. https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957 I'm not familiar with this usage: efibootmgr -B -b 0 If 0 is the same as then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel. A valid command would be efibootmgr -b 0003 -B -B -b 0 seems to be the same as -B -b , and my isn't the same as your :) I'm basing it off the entry in your bug 73761. It points to a DVD drive. Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it. Anaconda does this somehow, I think. Even just exposing that would be nice. No all it does is look for a Fedora boot entry in NVRAM and then uses efibootmgr -b -B against it. It doesn't have a mechanism, nor should it, to obliterate everything in NVRAM which can contain a lot more than just boot entries. ls -l /sys/firmware/efi/efivars Two dozen variables. On my Mac there's 50+ items including speaker and brightness level. I meant that I assumed that anaconda set up a new boot manager entry. If it doesn't, and just relies on fallback, then I guess there's nothing to ask for. Of course, that'll change once anaconda becomes sensible enough to set up each ESP once and keep it unmounted from then on, since that'll involve changing the RPMs so they don't install to /boot/efi. Unless, of course, /boot/efi just becomes the efi boot template, in which case some script will need to propagate the contents. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: JavaScript bundling (was Re: F21 System Wide Change: Cockpit Management Console)
On Fri, Apr 11, 2014 at 8:19 AM, Peter MacKinnon pmack...@redhat.com wrote: Is there circumstances whereby new reviews can be approved without FPC exception if those assets have not yet been packaged under the new web asset packaging guidelines and layout? There's currently a blanket exception for jQuery: https://fedorahosted.org/fpc/ticket/408#comment:9 To my knowledge, there is no such exception for any other libraries. Feel free to request one though; FPC will likely approve and I'll add my support just as I did with jQuery. :-) -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reinstalling the bootloader
On Apr 14, 2014, at 4:27 PM, Andrew Lutomirski l...@mit.edu wrote: On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy li...@colorremedies.com wrote: On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski l...@mit.edu wrote: Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise. Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh. Huh, you're sure? You have to either remove all removable NVRAM boot entries, or you have to remove the file/device the entry points to trigger the use of //BOOT/BOOTarch.efi. If this isn't working, what does happen instead? It just hangs? Hmm. I assumed that just asking the system to boot off that disk would do the trick. Apparently not. No. Boot entries in NVRAM come first. See UEFI spec 2.4.0, section 3.4.1.2, and 12.3.1.3 This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost. Removing other entries is hard, given the aforementioned OOPS. :( Sure. OOPS isn't good. But chances are it's naughty firmware. I tried to clarify it a bit, though. It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed. Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg. https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957 I'm not familiar with this usage: efibootmgr -B -b 0 If 0 is the same as then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel. A valid command would be efibootmgr -b 0003 -B -B -b 0 seems to be the same as -B -b , and my isn't the same as your :) I'm basing it off the entry in your bug 73761. It points to a DVD drive. Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it. Anaconda does this somehow, I think. Even just exposing that would be nice. No all it does is look for a Fedora boot entry in NVRAM and then uses efibootmgr -b -B against it. It doesn't have a mechanism, nor should it, to obliterate everything in NVRAM which can contain a lot more than just boot entries. ls -l /sys/firmware/efi/efivars Two dozen variables. On my Mac there's 50+ items including speaker and brightness level. I meant that I assumed that anaconda set up a new boot manager entry. If it doesn't, and just relies on fallback, then I guess there's nothing to ask for. It does create a new boot manager entry using efibootmgr. Of course, that'll change once anaconda becomes sensible enough to set up each ESP once and keep it unmounted from then on, since that'll involve changing the RPMs so they don't install to /boot/efi. Has there been buy off on this? Chris Murphy -- 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
On Mon, Apr 14, 2014 at 7:16 AM, Jaroslav Reznik jrez...@redhat.com wrote: Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Stupid question: what in rails depends on v8 exactly? The only thing that Requires v8 in Fedora besides nodejs and mongodb is rubygem-therubyracer, and that FTBFS for the F20 mass rebuild and my recent v8/libicu mini-mass rebuild: http://koji.fedoraproject.org/koji/packageinfo?packageID=14305 I'm in touch with someone from IBM to get PPC support for v8/nodejs (which means no more random failures when nodejs packages get sent to EPEL PPC builders, yay!), which requires finally switching to gyp from scons (which has been deprecated for years now), and so far I've been ignoring ruby in my preliminary work [1] on this since it has been broken for other reasons. If you're going to continue to need rubygem-therubyracer, please fix it so I can make sure we don't break it. (Or at least rebuild it when the time comes. It probably still works in F20 since nothing changed v8-wise since F18, but I wouldn't be surprised if it's completely busted in rawhide right now.) Thanks, -T.C. [1] http://copr.fedoraproject.org/coprs/patches/v8-gyp/ -- 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: The securetty file is empty by default
On 04/14/2014 09:21 PM, Andrew Lutomirski wrote: On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim sali...@fedoraproject.org wrote: Apologies for being late to the discussion as well - just wanted to note that I've been running root-password-less configurations for some time (by using passwd -l to lock out the root account post-install), and later encountered this scenario whereby one of the disks failed fsck and I was dropped into a single-user mode login for maintenance, where I was prompted for... you get it, the root password. Resorted to rebooting and disabling fsck from grub, but how to handle fsck errors should probably be considered as part of this proposed change. You're not the only one: https://bugzilla.redhat.com/show_bug.cgi?id=1045574 https://bugzilla.redhat.com/show_bug.cgi?id=1087528 Well, the fastboot flag in Grub works as a workaround, my problem is different from those that lost their root password -- I intentionally didn't set one, and expected tasks that in the past required the use of the root password to be doable by the user account nominated to be administrators, whether through %wheel membership or pkcon or other means. but I don't think that this is really related to securetty. If the use of root account is to be further discouraged, I'm pointing out that workflows that currently require it have to be revised as well. Best regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: michel-...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: The securetty file is empty by default
On Tue, 2014-04-15 at 08:49 +0700, Michel Alexandre Salim wrote: On 04/14/2014 09:21 PM, Andrew Lutomirski wrote: On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim sali...@fedoraproject.org wrote: Apologies for being late to the discussion as well - just wanted to note that I've been running root-password-less configurations for some time (by using passwd -l to lock out the root account post-install), and later encountered this scenario whereby one of the disks failed fsck and I was dropped into a single-user mode login for maintenance, where I was prompted for... you get it, the root password. Resorted to rebooting and disabling fsck from grub, but how to handle fsck errors should probably be considered as part of this proposed change. You're not the only one: https://bugzilla.redhat.com/show_bug.cgi?id=1045574 https://bugzilla.redhat.com/show_bug.cgi?id=1087528 Well, the fastboot flag in Grub works as a workaround, my problem is different from those that lost their root password -- I intentionally didn't set one, and expected tasks that in the past required the use of the root password to be doable by the user account nominated to be administrators, whether through %wheel membership or pkcon or other means. but I don't think that this is really related to securetty. If the use of root account is to be further discouraged, I'm pointing out that workflows that currently require it have to be revised as well. I do not think it makes any sense to lock the root account. It is perfectly sane to discourage from using root for day to day operation and avoid or even disallow to login into the display manager with root. But disabling it has no useful purpose, you are just going to make another account all powerful to compensate, either by giving sudo powers or other similar mechanism, what you loose is the ability to properly recover a system. I am not saying you shouldn't be allowed to do passwd -l, but that should not be mandated by the system configuration, purely a choice of individual admins. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: The securetty file is empty by default
On Mon, 2014-04-14 at 23:57 -0400, Simo Sorce wrote: On Tue, 2014-04-15 at 08:49 +0700, Michel Alexandre Salim wrote: On 04/14/2014 09:21 PM, Andrew Lutomirski wrote: On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim sali...@fedoraproject.org wrote: Apologies for being late to the discussion as well - just wanted to note that I've been running root-password-less configurations for some time (by using passwd -l to lock out the root account post-install), and later encountered this scenario whereby one of the disks failed fsck and I was dropped into a single-user mode login for maintenance, where I was prompted for... you get it, the root password. Resorted to rebooting and disabling fsck from grub, but how to handle fsck errors should probably be considered as part of this proposed change. You're not the only one: https://bugzilla.redhat.com/show_bug.cgi?id=1045574 https://bugzilla.redhat.com/show_bug.cgi?id=1087528 Well, the fastboot flag in Grub works as a workaround, my problem is different from those that lost their root password -- I intentionally didn't set one, and expected tasks that in the past required the use of the root password to be doable by the user account nominated to be administrators, whether through %wheel membership or pkcon or other means. but I don't think that this is really related to securetty. If the use of root account is to be further discouraged, I'm pointing out that workflows that currently require it have to be revised as well. I do not think it makes any sense to lock the root account. It is perfectly sane to discourage from using root for day to day operation and avoid or even disallow to login into the display manager with root. But disabling it has no useful purpose, you are just going to make another account all powerful to compensate, either by giving sudo powers or other similar mechanism, what you loose is the ability to properly recover a system. I am not saying you shouldn't be allowed to do passwd -l, but that should not be mandated by the system configuration, purely a choice of individual admins. Simo. -- Simo Sorce * Red Hat, Inc * New York If you could enter the rescue.target with a username/password instead of just enter the password for root I wouldn't mind a default locked root account. Yes, you would have an account that would need at least ALL command access in sudo. For the rescue.target you could attempt to start sssd perhaps if you wanted to access network based accounts ... You also don't lose that ability to recover a system anyway. Because you can then use physical access and init=/bin/bash if you really got desperate. I guess it's more to discourage the shared root password scenario than anything. Really, in the same token, should root ssh be disabled by default? -- William Brown will...@firstyear.id.au -- 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: The securetty file is empty by default
On 04/14/2014 08:57 PM, Simo Sorce wrote: But disabling it has no useful purpose, you are just going to make another account all powerful to compensate, either by giving sudo powers or other similar mechanism, what you loose is the ability to properly recover a system. However, one benefit to disabling root is that it removes that as a potential brute forcing attack. Even if you have another account that is just as powerful, it still requires the attacker to find the username as well as the password. But this is getting further off-topic... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1087318] New: perl-Dancer-1.3123 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087318 Bug ID: 1087318 Summary: perl-Dancer-1.3123 is available Product: Fedora Version: rawhide Component: perl-Dancer Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.3123 Current version/release in Fedora Rawhide: 1.3121-1.fc21 URL: http://search.cpan.org/dist/Dancer/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CPGiUdEbfWa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087319] New: perl-DBD-Pg-3.1.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087319 Bug ID: 1087319 Summary: perl-DBD-Pg-3.1.1 is available Product: Fedora Version: rawhide Component: perl-DBD-Pg Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: dev...@gunduz.org, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 3.1.1 Current version/release in Fedora Rawhide: 3.0.0-1.fc21 URL: http://search.cpan.org/dist/DBD-Pg/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=oWTOmzfBO1a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087320] New: perl-Encode-2.59 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087320 Bug ID: 1087320 Summary: perl-Encode-2.59 is available Product: Fedora Version: rawhide Component: perl-Encode Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 2.59 Current version/release in Fedora Rawhide: 2.58-1.fc21 URL: http://search.cpan.org/dist/Encode/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=eqqefuRYVia=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 917265] perl-EV-4.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=917265 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-EV-4.16 is available |perl-EV-4.17 is available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 4.17 Current version/release in Fedora Rawhide: 4.11-4.fc21 URL: http://search.cpan.org/dist/EV/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UZYQlrXn3Da=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087321] New: perl-Exporter-5.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087321 Bug ID: 1087321 Summary: perl-Exporter-5.70 is available Product: Fedora Version: rawhide Component: perl-Exporter Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 5.70 Current version/release in Fedora Rawhide: 5.68-293.fc20 URL: http://search.cpan.org/dist/Exporter/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pEapT646Uya=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087322] New: perl-ExtUtils-MakeMaker-6.96 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087322 Bug ID: 1087322 Summary: perl-ExtUtils-MakeMaker-6.96 is available Product: Fedora Version: rawhide Component: perl-ExtUtils-MakeMaker Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 6.96 Current version/release in Fedora Rawhide: 6.94-1.fc21 URL: http://search.cpan.org/dist/ExtUtils-MakeMaker/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=2pfzVYhFQ7a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087326] New: perl-LDAP-0.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087326 Bug ID: 1087326 Summary: perl-LDAP-0.62 is available Product: Fedora Version: rawhide Component: perl-LDAP Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 0.62 Current version/release in Fedora Rawhide: 0.61-1.fc21 URL: http://search.cpan.org/dist/perl-ldap/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gj6craTzM3a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087327] New: perl-Locale-SubCountry-1.63 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087327 Bug ID: 1087327 Summary: perl-Locale-SubCountry-1.63 is available Product: Fedora Version: rawhide Component: perl-Locale-SubCountry Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 1.63 Current version/release in Fedora Rawhide: 1.62-2.fc20 URL: http://search.cpan.org/dist/Locale-SubCountry/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=W6dli6aoSYa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087328] New: perl-Math-NumSeq-70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087328 Bug ID: 1087328 Summary: perl-Math-NumSeq-70 is available Product: Fedora Version: rawhide Component: perl-Math-NumSeq Keywords: FutureFeature, Triaged Assignee: mhron...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mhron...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 70 Current version/release in Fedora Rawhide: 69-1.fc21 URL: http://search.cpan.org/dist/Math-NumSeq/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ovckajPRvja=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087329] New: perl-Math-PlanePath-115 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087329 Bug ID: 1087329 Summary: perl-Math-PlanePath-115 is available Product: Fedora Version: rawhide Component: perl-Math-PlanePath Keywords: FutureFeature, Triaged Assignee: mhron...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mhron...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 115 Current version/release in Fedora Rawhide: 114-2.fc21 URL: http://search.cpan.org/dist/Math-PlanePath/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FPGEV3kuu9a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087330] New: perl-MooseX-AttributeShortcuts-0.023 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087330 Bug ID: 1087330 Summary: perl-MooseX-AttributeShortcuts-0.023 is available Product: Fedora Version: rawhide Component: perl-MooseX-AttributeShortcuts Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.023 Current version/release in Fedora Rawhide: 0.022-1.fc21 URL: http://search.cpan.org/dist/MooseX-AttributeShortcuts/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gqo71a077wa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087331] New: perl-MooseX-CoercePerAttribute-1.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087331 Bug ID: 1087331 Summary: perl-MooseX-CoercePerAttribute-1.001 is available Product: Fedora Version: rawhide Component: perl-MooseX-CoercePerAttribute Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.001 Current version/release in Fedora Rawhide: 1.000-1.fc21 URL: http://search.cpan.org/dist/MooseX-CoercePerAttribute/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=f0FfgXqb76a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087334] New: perl-Net-Twitter-4.01004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087334 Bug ID: 1087334 Summary: perl-Net-Twitter-4.01004 is available Product: Fedora Version: rawhide Component: perl-Net-Twitter Keywords: FutureFeature, Triaged Assignee: jd...@aquezada.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jd...@aquezada.com, perl-devel@lists.fedoraproject.org Latest upstream release: 4.01004 Current version/release in Fedora Rawhide: 4.01003-1.fc21 URL: http://search.cpan.org/dist/Net-Twitter/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=i8vQ8keRs2a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087336] New: perl-Term-ProgressBar-2.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087336 Bug ID: 1087336 Summary: perl-Term-ProgressBar-2.15 is available Product: Fedora Version: rawhide Component: perl-Term-ProgressBar Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 2.15 Current version/release in Fedora Rawhide: 2.14-2.fc20 URL: http://search.cpan.org/dist/Term-ProgressBar/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vTfcjOBrqBa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087339] New: perl-Text-VimColor-0.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087339 Bug ID: 1087339 Summary: perl-Text-VimColor-0.24 is available Product: Fedora Version: rawhide Component: perl-Text-VimColor Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.24 Current version/release in Fedora Rawhide: 0.23-3.fc20 URL: http://search.cpan.org/dist/Text-VimColor/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kyBfawN07Ea=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087337] New: perl-Text-Table-1.130 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087337 Bug ID: 1087337 Summary: perl-Text-Table-1.130 is available Product: Fedora Version: rawhide Component: perl-Text-Table Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 1.130 Current version/release in Fedora Rawhide: 1.129-1.fc21 URL: http://search.cpan.org/dist/Text-Table/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gkgOu9Wjsfa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087340] New: perl-XML-LibXML-2.0116 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087340 Bug ID: 1087340 Summary: perl-XML-LibXML-2.0116 is available Product: Fedora Version: rawhide Component: perl-XML-LibXML Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 2.0116 Current version/release in Fedora Rawhide: 2.0115-1.fc21 URL: http://search.cpan.org/dist/XML-LibXML/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fdRQnZW82ma=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Encode-2.59.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Encode: 98afe078b82375c457b28b054be09aa3 Encode-2.59.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087341] New: perl-XML-LibXSLT-1.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087341 Bug ID: 1087341 Summary: perl-XML-LibXSLT-1.92 is available Product: Fedora Version: rawhide Component: perl-XML-LibXSLT Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, z...@fastmail.fm Latest upstream release: 1.92 Current version/release in Fedora Rawhide: 1.89-1.fc21 URL: http://search.cpan.org/dist/XML-LibXSLT/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=yeg0cQCcTqa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Encode] 2.59 bump
commit e49a9d8114c82caab2ed917a5302931e88def7e6
Author: Petr Písař ppi...@redhat.com
Date: Mon Apr 14 10:57:02 2014 +0200
2.59 bump
.gitignore |1 +
perl-Encode.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f6c40f2..abe40a1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
/Encode-2.55.tar.gz
/Encode-2.57.tar.gz
/Encode-2.58.tar.gz
+/Encode-2.59.tar.gz
diff --git a/perl-Encode.spec b/perl-Encode.spec
index 0f3f678..9c93556 100644
--- a/perl-Encode.spec
+++ b/perl-Encode.spec
@@ -1,6 +1,6 @@
Name: perl-Encode
Epoch: 1
-Version:2.58
+Version:2.59
Release:1%{?dist}
Summary:Character encodings in Perl
License:GPL+ or Artistic
@@ -113,6 +113,9 @@ make test
%{perl_vendorarch}/Encode/encode.h
%changelog
+* Mon Apr 14 2014 Petr Pisar ppi...@redhat.com - 1:2.59-1
+- 2.59 bump
+
* Mon Mar 31 2014 Petr Pisar ppi...@redhat.com - 1:2.58-1
- 2.58 bump
diff --git a/sources b/sources
index d1ce1ca..9293273 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-99cebfff1f664feb183d0e1b697ae7e7 Encode-2.58.tar.gz
+98afe078b82375c457b28b054be09aa3 Encode-2.59.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
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 perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Exporter-5.70.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Exporter: 37174097220148df0c44ad28d10d3980 Exporter-5.70.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Exporter] 5.70 bump
commit 88052cd35d59f5e28d218b6fe43ad7f31d94be09
Author: Petr Písař ppi...@redhat.com
Date: Mon Apr 14 11:03:33 2014 +0200
5.70 bump
.gitignore |1 +
perl-Exporter.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4b99cfd..d260aa5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Exporter-5.67.tar.gz
/Exporter-5.68.tar.gz
+/Exporter-5.70.tar.gz
diff --git a/perl-Exporter.spec b/perl-Exporter.spec
index 081e8a0..0d1fa3c 100644
--- a/perl-Exporter.spec
+++ b/perl-Exporter.spec
@@ -1,6 +1,6 @@
Name: perl-Exporter
-Version:5.68
-Release:293%{?dist}
+Version:5.70
+Release:1%{?dist}
Summary:Implements default import method for modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -52,6 +52,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Apr 14 2014 Petr Pisar ppi...@redhat.com - 5.70-1
+- 5.70 bump
+
* Wed Aug 14 2013 Jitka Plesnikova jples...@redhat.com - 5.68-293
- Perl 5.18 re-rebuild of bootstrapped packages
diff --git a/sources b/sources
index 69c674f..3f865ef 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b952dfeae12c41f9b8ec9a4c79d700b7 Exporter-5.68.tar.gz
+37174097220148df0c44ad28d10d3980 Exporter-5.70.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Exporter/f20] 5.70 bump
Summary of changes: 88052cd... 5.70 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087321] perl-Exporter-5.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087321 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Exporter-5.70-1.fc21 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fix release suitable for F≥20. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gx6hbbUlXya=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087320] perl-Encode-2.59 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087320 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Encode-2.59-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-04-14 05:13:35 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This restores ABI broken in 2.58. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=JFdROVvpa1a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087321] perl-Exporter-5.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087321 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Exporter-5.70-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Exporter-5.70-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zlnGGo8M22a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087408] New: Parallel-Prefork-0.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087408 Bug ID: 1087408 Summary: Parallel-Prefork-0.15 is available Product: Fedora Version: rawhide Component: perl-Parallel-Prefork Assignee: rc040...@freenet.de Reporter: rc040...@freenet.de QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Description of problem: Parallel-Prefork-0.15 is available. This is a bug fix release which should be applied to all active versions of Fedora. Unfortunately Parallel-Prefork-0.15 introduces new deps which currently are not available in Fedora. Additional info: This BZ is meant to be a tracking bug to remind myself when Fedora provides the necessary deps. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=u2T9twWHcEa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1087408] Parallel-Prefork-0.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087408 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Depends On||1087401 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1087401 [Bug 1087401] Review Request:perl-Signal-Mask - Signal masks made easy -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=PekcSshwO1a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
