date:20150302

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

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System upda...@fedoraproject.org ---
Package perl-Pod-Usage-1.67-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-Pod-Usage-1.67-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-2963/perl-Pod-Usage-1.67-1.fc22
then log in and leave karma (feedback).

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

Re: bodhi: Notified can be pushed, but refuses to push

2015-03-02 Thread Luke Macken

On Sun, Mar 01, 2015 at 11:33:35AM +0100, Ralf Corsepius wrote:
 On 03/01/2015 10:20 AM, Samuel Sieb wrote:
 On 02/28/2015 10:42 PM, Ralf Corsepius wrote:
 I receive a yellow box telling me: This update has not yet met the
 minimum testing requirements defined in the Package Update Acceptance
 Criteria
 
 Something definitely doesn't work right.
 
 Isn't it Alpha freeze right now?
 
 Well, then bodhi likely should not send out such false notifications.

The bodhi backend/frontend configuration got out of sync. This problem
should now be resolved in production.

luke


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

Orphaned Packages in branched (2015-03-02)

2015-03-02 Thread opensource

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers  Status Change 
===
aptorphan, athimm 0 weeks ago   
bfgminer   orphan, pwouters   2 weeks ago   
clc-intercal   orphan, iarnell2 weeks ago   
cone   orphan, steve  2 weeks ago   
dbus-tools orphan, miminar2 weeks ago   
dircproxy  orphan, jwilson, kevin 2 weeks ago   
egtk   orphan, cicku, odysseus,   2 weeks ago   
   raphgro  
fedora-package-config-apt  orphan, athimm 0 weeks ago   
fldigi-doc orphan, dp67   2 weeks ago   
freenx-server  orphan, athimm, limb   0 weeks ago   
gtk-smooth-engine  orphan, raveit65, vicodan  0 weeks ago   
ip6sic orphan, davej  2 weeks ago   
isic   orphan, davej  2 weeks ago   
ivtv-firmware  orphan, athimm, jwilson,   0 weeks ago   
   kwizart  
ivtv-utils orphan, athimm 0 weeks ago   
kmplayer   orphan, rdieter, tuxbrewr  1 weeks ago   
libcdaudio orphan, athimm 0 weeks ago   
mate-user-shareorphan, raveit65, vicodan  2 weeks ago   
maven-anno-plugin  orphan, goldmann   2 weeks ago   
mediawiki-openid   orphan, athimm, kevin, 0 weeks ago   
   kurtseifried 
mojomojo   orphan, iarnell, perl-sig  2 weeks ago   
ncid   orphan, sandeen0 weeks ago   
ninja  orphan, adrian 2 weeks ago   
pympdtouchgui  orphan, slankes2 weeks ago   
python-asyncmongo  orphan, silas  2 weeks ago   
python-django- orphan 1 weeks ago   
socialregistration  
python-gflags  orphan, silas  2 weeks ago   
python-tvrage  orphan 1 weeks ago   
rubygem-spruz  orphan, maxamillion0 weeks ago   
spambayes  orphan 1 weeks ago   
synaptic   orphan, athimm 0 weeks ago   
tuxcmd orphan 0 weeks ago   
umlgraph   orphan, akurtakov, fabiand,2 weeks ago   
   raphgro  
visualvm   orphan, davidcl, dbhole,   2 weeks ago   
   jerboaa, jvanek  
xnoise orphan, salimma2 weeks ago   
zukini orphan, odysseus   2 weeks ago   
zukiwi orphan, odysseus   2 weeks ago   

The following packages require above mentioned packages:
Depending on: apt (1), status change: 2015-02-25 (0 weeks ago)
perl-Test-AutoBuild (maintained by: berrange, perl-sig)
perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires 
/usr/bin/genbasedir


Depending on: gtk-smooth-engine (1), status change: 2015-03-02 (0 weeks ago)
mate-themes-extras (maintained by: raveit65, vicodan)
mate-themes-extras-3.14.5-2.fc22.noarch requires 
gtk-smooth-engine = 2.14.3-6.fc22


Depending on: ivtv-firmware (1), status change: 2015-02-25 (0 weeks ago)
xorg-x11-drv-ivtv (maintained by: kwizart, glisse)
xorg-x11-drv-ivtv-1.2.0-0.16.fc22.i686 requires ivtv-firmware = 
2:20080701-26


Depending on: libcdaudio (31), status change: 2015-02-25 (0 weeks ago)
gstreamer-plugins-bad-free (maintained by: company, fabiand, hadess, 
kwizart, wtaymans)

Re: RFC: Audacious 3.6 build options

2015-03-02 Thread Michael Schwendt

On Sun, 1 Mar 2015 23:28:48 +0100, Dominik 'Rathann' Mierzejewski wrote:

 I do use it from time to time, but I'm currently on F21.

Me too, but the Copr builds of 3.6 feature a repo for F21, too.
The Qt UI is not a port, but more of a rewrite/redesign. Various dialogs
look very different.

 I'd say: follow upstream and build with GTK2. You are allowed to change
 application behaviour or appearance between distribution releases.

Ah, a good idea for F22. I'll also consult upstream about their
preferences.

 I'd wait with building against Qt5 in F22 until there is no dependency
 on both Qt and GTK anymore.

Agreed.
-- 
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: RFC: Audacious 3.6 build options

2015-03-02 Thread Michael Schwendt

On Mon, 2 Mar 2015 09:20:07 +1100, Dan Fruehauf wrote:

 Is it possible to compile audacious on its own and then supply gtk3 and qt
 packages on top of it?

No. First of all, Qt has always been more than a GUI-library. It's a C++
development framework, and Audacious' core libs will likely use it where
they have used GLib before. I doubt the devs will limit themselves to the
C++ standard libs, so all GUIs and their dependencies could be put into
plugins. That's these, so one could change the different UIs at run-time,

  $ rpm -ql audacious-plugins|grep -i ui
  /usr/lib64/audacious/General/gtkui.so
  /usr/lib64/audacious/General/qtui.so

but libaudgui depends on both Qt and GTK, for example. And if both
GUIs are enabled, one needs to run audacious --qt to start the Qt UI.
Hmmm...
-- 
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: koji is broken

On Tuesday, March 3, 2015, Kevin Fenzi ke...@scrye.com wrote:

 I think this is some kind of connectivity issue.

 Next time this happens can you run the koji command again with
 '--debug' and see if anything stands out? Also make sure you can ping
 and reach the koji web page.

 There's also a '--debug-xmlrpc' but I think that will show your cert
 and other info that shouldn't be public, so you can run it, but don't
 share that output in a bug ticket or anything.



Sure.


-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
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 1197924] perl-Locale-Codes-3.34 is available

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



--- Comment #1 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Scratch build succeeded
http://koji.fedoraproject.org/koji/taskinfo?taskID=9125033

-- 
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=xExz9p2DTRa=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 1197915] perl-Date-Manip-6.49 is available

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



--- Comment #1 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Scratch build succeeded
http://koji.fedoraproject.org/koji/taskinfo?taskID=9124747

-- 
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=jyPVk6Mf5ja=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 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command

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



--- Comment #13 from Ben Boeckel maths...@gmail.com ---
As I hit Save Changes, I realized I forgot to add BR: perl. Added locally. I
can upload again if you want or import it with the change.

-- 
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=yhn9a2DwBfa=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 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command

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



--- Comment #12 from Ben Boeckel maths...@gmail.com ---
Spec URL: http://mathstuf.fedorapeople.org//dropbox-api-command.spec
SRPM URL:
http://mathstuf.fedorapeople.org//dropbox-api-command-1.17-5.fc23.src.rpm

-- 
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=u7Mr78LfVsa=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 WebService-Linode-0.27.tar.gz uploaded to lookaside cache by cicku

A file has been added to the lookaside cache for perl-WebService-Linode:

c1f0ead7867202af8ecae6b33fa32bc1  WebService-Linode-0.27.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 1197467] perl-WebService-Linode-0.27 is available

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



--- Comment #2 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
cicku's perl-WebService-Linode-0.27-1.fc23 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=617392

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

Re: Intend to retire kde-plasma-daisy

2015-03-02 Thread Garrett Holmstrom


On 2015-03-02 2:52, Michael J Gruber wrote:

Retired in f22 and rawhide now. Two remarks about the process:

- 'fedpkg' always makes me feel uneasy. I don't know what's going on
under the hood, and it messes up the git DAG. Those two separate
retirement commits should have been one plus a merge. I'd rather use
pure git here (but fedpkg also does some message bus thing).


FWIW, using fedpkg for that isn't mandatory.  I use git directly all the 
time and all the usual fedmsg stuff still seems to fire.


--
Garrett Holmstrom
--
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-WebService-Linode] Update to 0.27

commit 8fa72c3db1e0b7ecea1f5d819e80e6ebd72afd1f
Author: Christopher Meng i...@cicku.me
Date:   Mon Mar 2 22:24:50 2015 -0500

Update to 0.27

 .gitignore  | 1 +
 perl-WebService-Linode.spec | 8 ++--
 sources | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ba411dd..6b4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
 /WebService-Linode-0.22.tar.gz
 /WebService-Linode-0.23.tar.gz
 /WebService-Linode-0.26.tar.gz
+/WebService-Linode-0.27.tar.gz
diff --git a/perl-WebService-Linode.spec b/perl-WebService-Linode.spec
index 81b067b..ada148a 100644
--- a/perl-WebService-Linode.spec
+++ b/perl-WebService-Linode.spec
@@ -1,5 +1,5 @@
 Name:   perl-WebService-Linode
-Version:0.26
+Version:0.27
 Release:1%{?dist}
 Summary:Perl Interface to the Linode.com API
 License:GPL+ or Artistic
@@ -42,11 +42,15 @@ the same. For additional information see 
http://www.linode.com/api/ .
 ./Build test
 
 %files
-%doc Changes LICENSE README examples/
+%doc Changes README examples/
+%license LICENSE
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 02 2015 Christopher Meng r...@cicku.me - 0.27-1
+- Update to 0.27
+
 * Sun Feb 01 2015 Christopher Meng r...@cicku.me - 0.26-1
 - Update to 0.26
 
diff --git a/sources b/sources
index 424ec7f..d00d9b1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a8b8b8887b064ca031efb415ecec6672  WebService-Linode-0.26.tar.gz
+c1f0ead7867202af8ecae6b33fa32bc1  WebService-Linode-0.27.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 1197915] New: perl-Date-Manip-6.49 is available

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

Bug ID: 1197915
   Summary: perl-Date-Manip-6.49 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Date-Manip
  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: 6.49
Current version/release in rawhide: 6.48-1.fc22
URL: http://search.cpan.org/dist/Date-Manip/

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

Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Orion Poplawski


On 03/02/2015 05:11 AM, Dan Callaghan wrote:


Is there any reason why we shouldn't just upgrade applications to the
python35-* stack straight away, by providing python3-*?



The main issue here is that EPEL doesn't have releases, so there is no 
way to take time to build everything and then push it out as a group.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[Bug 1197924] New: perl-Locale-Codes-3.34 is available

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

Bug ID: 1197924
   Summary: perl-Locale-Codes-3.34 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Locale-Codes
  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: 3.34
Current version/release in rawhide: 3.33-1.fc22
URL: http://search.cpan.org/dist/Locale-Codes/

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=3M0IEgtAPba=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

Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Dan Callaghan

Excerpts from Bohuslav Kabrda's message of 2015-03-02 22:17 +10:00:
 - Original Message -
  Excerpts from Bohuslav Kabrda's message of 2015-03-02 21:59 +10:00:
   - Original Message -
Under the current proposal every package with Python 3 dependencies
would have to depend on a specific python3x-* package, so then it would
be up to the maintainers of all those packages to manually bump their
Requires from python34-* to python35-* at some point. Which, now that
I think about it, is not that great. Even worse, if any packages form
a transitive dependency chain then *all* packages in the chain have to
update their Requires at the same time to avoid having a mix of
python34-* and python35-* requirements.
   
   Not really. The requires/buildrequires should be in form of
   Requires: python%{python3_pkgversion}-six
   so when we change %python3_pkgversion in the minimal buildroot,
   maintainer just rebuilds and gets updated requires.
  
  Hmm okay. I didn't realise this.
  
  So that means that:
  * Fedora specfiles can't be used unchanged (they will require python3-*,
needs to have %{python3_pkgversion} macro inserted)
 
 True, but note that we'll make %python3_pkgversion macro available 
 also in Fedora (always defined to 3), so once this change is done, 
 it'll be possible to have the same specfile both in Fedora and EPEL.

Okay that's good.

  * applications will need to be rebuilt to pick up a change from
python34-* to python35-*
  which is a bit unfortunate.
  
  Is there any reason why we shouldn't just upgrade applications to the
  python35-* stack straight away, by providing python3-*?
 
 Yeah. First of all, it may happen that there are some minor backwards 
 incompatibilities. Lots of packages run tests during buildtime, so 
 these will be caught.
 Another reason is that there are applications, which store files in 
 /usr/lib/python3.X/site-packages - these need to be rebuilt anyway, 
 since they have the Python minor version incorporated in path of 
 files.
 I really think that we should rebuild applications with new Python 
 3.X.

Well, they should really be using pkg_resources instead of hardcoding 
the path... but yes I take your point. Rebuilding for the newer Python 
stack makes sense.

We will need to make sure that setuptools-generated entry points have 
a shebang of /usr/bin/python3.4 rather than just /usr/bin/python3 
though, so that the scripts are always invoked with the same Python 
stack they are built for. Currently on Fedora they have 
/usr/bin/python3. This might need a patch to 
setuptools/distutils/whatever it is?

-- 
Dan Callaghan dcall...@redhat.com
Software Engineer, Hosted  Shared Services
Red Hat, Inc.


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

Re: rawhide report: 20150302 changes

2015-03-02 Thread Ben Boeckel

On Mon, Mar 02, 2015 at 09:00:02 -0500, Ben Boeckel wrote:
 I'll look at them tonight.

5/6 reviewed; one is a transitive dep, so I'll wait for that one.

--Ben
-- 
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-WebService-Linode/epel7] (2 commits) ...Update to 0.27

Summary of changes:

  2c42411... Add missing deps for tests. (*)
  8fa72c3... Update to 0.27 (*)

(*) 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

[perl-WebService-Linode/f21] (2 commits) ...Update to 0.27

Summary of changes:

  2c42411... Add missing deps for tests. (*)
  8fa72c3... Update to 0.27 (*)

(*) 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

[perl-WebService-Linode/f22] Update to 0.27

Summary of changes:

  8fa72c3... Update to 0.27 (*)

(*) 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 1197467] perl-WebService-Linode-0.27 is available

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

Christopher Meng i...@cicku.me changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-WebService-Linode-0.27
   ||-1.fc23
 Resolution|--- |RAWHIDE
Last Closed||2015-03-02 23:46:40



-- 
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=91bszn8O40a=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

Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Orion Poplawski


On 03/02/2015 04:53 AM, Bohuslav Kabrda wrote:

- Original Message -

This is a followup to the EPEL IRC meeting discussion about python 3.  I had
a
couple questions which led me to take Slavek's excellent work and try some
changes here: https://fedoraproject.org/wiki/User:Orion/EPEL7_Python3

Main ideas:
- (bikeshedding) - I didn't like the wording other, so I went with next.


Right, this naming makes more sense due to the way your proposal works - in other words, 
next is always the higher version, assuming there are two parallel stacks. This isn't 
always the case in my proposal, which is why I used other.


- I didn't like having to toggle a macro in the spec files, I'm lazy


+1, this can be done globally in python3-pkgversion-macros regardless which 
proposal we use.


Agreed.


- What happens on the user's end?

So:

Lifecycle of python3X stacks, rebuilding:

 when a new python3X+1 is built in EPEL - let's say that there is python34
and python35 has just been introduced:
 A new python3-pkgversion-macros is build defining the %python3_next*
macros.


I think that macro file *in python35-devel* should define this - the main python3 defines 
%python3* macros, the next/other python3 defines %python3_next*.


Sure - I guess I was using the presence of python3_next_pkgversion in 
python3-pkgversion-macros as the toggle.  But we could define 
with_python3_other directly there depending on what naming scheme is used.





 (scripted) mass rebuild is run to build as much of the new stack
possible automatically.
 At some point /usr/bin/python3 is switched from python34 to python35.
 at a certain point at time an announcement is made that python34 is
 to
be retired and python35 is to be *the* one. At this point:
 python3-pkgversion-macros is rebuilt removing the %python3_next*
macros.


As per my comment above, we wouldn't need to remove the next macros, we would rebuild 
python35 as main python3, thus giving it the normal %python3 macros.


I see:
- swapping python3_pkgversion and python3_other_pkgversion by rebuilding 
both 3X and 3X+1

- dropping 3X and renaming python3_next_* to python3_ in 3X+1

as functionally equivalent.  As I say, bikeshedding :)

-



 python35 is rebuilt defining the normal %python3_* macros
 all python34 packages are retired

 At this point all packages build just python35-X subpackages



What I still don't understand is what this looks like on the user end, how do
they go from 34 to 35?  For app users (#!/usr/bin/python3), it seems like
this
should be as automatic as possible.  So shouldn't they still use
/usr/bin/python3 rather than /usr/bin/python3X so they get updated
automatically?


I think applications should use /usr/bin/python3.4 (at least packaged 
applications). Otherwise we could theoretically end up in a situation where 
/usr/bin/python3 is owned by python35, but the application RPM still has 
python34- dependencies and thus the app doesn't work.

I think this is actually one of the reasons why I thought it makes sense to keep both 
python34 and python35 living together in the state where python35 is the main python3 
(having the default macros and owning /usr/bin/python3) and python34 is the 
other. Let's take this example:
- there's an application foo written in python, which requires six
- it doesn't make sense to build the application for both python34 and 
python35, since it's an application, not a library
- this means it doesn't make sense for package maintainer to introduce the 
%python3_{other or next}* macros to the specfile, maintainer just wants to build with 
the python3
- so this means that we should do this:
-- python 3.5 is released, we build it in EPEL and turn with_python3_other to 1 
in python3-pkgversion-macros
-- then there's a period when python34 and python35 coexist and python34 is the 
main python - in this period, *libraries* are rebuilt to provide both python34- and 
python35- subpackages
-- python34 and python35 are switched (the default macros now point to 35 and 
it also owns /usr/bin/python3 now)
-- then there's a period when python34 and python35 coexist and python35 is the 
main python - in this period, *applications* are rebuilt for python35 (may take 
some time, there will likely be a period when there are some apps on python34 and some 
already on python35)
-- when all applications are rebuilt for 35, with_python3_other is set to 0 and we now 
have just python35 and it's the main python3

Does this make sense or am I missing something? I'd need to do some minor 
changes+explanations to my proposal to accomodate this, but I still think it 
makes sense.


Okay, a pure python app (named app) that used /usr/bin/python3.4, 
would have to get rebuilt, version/release would get bumped, and pull in 
3.5.


But if it used /usr/bin/python3, there wouldn't be a need for a rebuild. 
 It would require /usr/bin/python3, and the installed python34

Full OS rebuild task available for Beaker

2015-03-02 Thread Nick Coghlan

Hi folks,

The Beaker team have put together a task that makes it feasible to
pre-test full rebuilds across all architectures (or at least primary
ones) before toolchain updates are landed in Koji:

Docs:
https://beaker-project.org/docs-develop/user-guide/beaker-provided-tasks.html#distribution-rebuild
Task: http://beaker.fedoraproject.org/bkr/tasks/25

It's designed primarily for testing toolchain changes, so it currently
just builds everything in alphabetical order and doesn't inject the
results back into the build root. It also doesn't replace Koschei, since
that's better for picking up unexpected interactions between different
components, while this new task is intended specifically to help with
major toolchain updates.

Regards,
Nick.

-- 
Nick Coghlan
Red Hat Hosted  Shared Services
Software Engineering  Development, Brisbane

HSS Provisioning Architect
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Apps using default Python in Fedora vs. EPEL

2015-03-02 Thread Bohuslav Kabrda

- Original Message -
 On 27 February 2015 at 11:02, Toshio Kuratomi a.bad...@gmail.com wrote:
 
  On Feb 25, 2015 3:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
 
  For those not following along with the FPC ticket, Toshio and Tomspur
  have a nice write-up of the options at
  https://etherpad.mozilla.org/2Uqk0ikCll
 
  I came back to this question myself due to a couple of different
  ideas, discussed in https://fedorahosted.org/fpc/ticket/498#comment:19
 
  * How does the situation in Fedora change if the upstream PEP 494
  recommendation to downstream Linux distros was to change in
  conjunction with the Python 3.5 release currently scheduled for
  September? That release (https://www.python.org/dev/peps/pep-0478/)
  amongst other things, automatically handles EINTR errors for syscalls,
  restores binary interpolation support and adds matrix multiplication
  support and os.scandir().
 
 
  I would be against making the switch to /usr/bin/python at this time but
  would do most of that fighting upstream.  If the pep were updated then I'd
  at least want to see that the other major distros are committed to changing
  their /usr/bin/python at the same time.
 
  Changing the behavior of a well known program like this is a bad idea.  As
  it breaks compatibility: with people's home grown scripts, with their self
  installed programs, and between os's and os releases. The pep is palatable
  because the arguments in favor of someday changing the value revolve around
  someday there not being a /usr/bin/python on most systems. At that point it
  becomes reasonable to reallocate /usr/bin/python and let the systems where
  /usr/bin/python be declared legacy and the behavior of /usr/bin/python on
  those legacy systems is the quirk, not ours.
 
  We could cut over sooner than this argument actually makes the case for but
  now is definitely not that day.  Fedora, rhel, ubuntu, aren't yet at the
  point where /usr/bin/python isn't present on most of their installed
  systems
  in their latest version, let alone all of their versions.people are still
  pulling /usr/bin/python onto their systems through dependencies for common
  applications even if their os is advanced enough not to need it by default.
  We have quite a ways to go before /usr/bin/python can be switched.
 
 Yeah, that's fair - a staggered release with the distros switching
 first before end user scripts makes sense. That would make the likely
 target date for a PEP 394 update some time in early 2017 with Python
 3.6.
 
 We could *potentially* switch the recommendation some time in 2016 if
 all goes well with the distro migrations and significant libraries
 start dropping Python 2.7 support, but switching in conjunction with
 Python 3.5 would still be too soon.

+1 to switch with Python 3.6. PEP 394 should however be made to reflect this 
ASAP - I mean it should be made to say that this change will happen with Python 
3.6. The sooner it says that, the more time for people to notice it and more 
time for distros to prepare.

  * With the default interpreter change postponed to Fedora 23, would it
  make sense to patch the system Python in Fedora 22 to emit Python 3
  warnings by default when it was run using the unqualified python
  reference rather than being run as the qualified python2? And then
  switch the symlink along with the RPM macros in Fedora 23?
 
 
  No to switching the value of /usr/bin/python and stated above.  The test
  makes some sense. If your warning is restricted to warning not to use
  /usr/bin/python (use /usr/bin/python 2 instead) that sounds really good to
  me.  (Your wording sounded like we should turn on warnings like python2 -3
  does which I don't think is such a good idea for fedora 22 but might be
  good
  in the future... our perhaps, like the kernel does with extra kernel
  debugging, we should turn it on in rawhide and fedora.n+1 but turn it off
  before release.)
 
 I did mean the latter (turning on -3 warnings), but I like your idea
 of only doing that in Rawhide and the Alpha releases for F23, and then
 switching to a simple use a qualified Python reference warning in
 the Betas and the actual release.

I'm also +1 on emitting a warning about /usr/bin/python usage, although I'm 
almost sure that will break something. There are always apps that expect 
certain form of subprocess output etc - and this will break them. IMO this 
should only be done in F23, not in F22 which is already in alpha.
I'm assuming that there is no builtin configure option to emit this warning and 
we'd have to patch this ourselves, is that right or have I just missed such 
option?

  It's also worth noting that the change I am considering to the
  upstream recommendation would place a qualifier on the distro
  providing a C.UTF-8 locale, so the C.UTF-8 in upstream glibc RFE
  (https://sourceware.org/bugzilla/show_bug.cgi?id=17318) would become a
  key enabler for making the symlink switch in Fedora (associated Fedora
  RFE:

[perl-Pod-Usage/f22] 1.67 bump

Summary of changes:

  58690a3... 1.67 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

Orphaning NCID (Caller ID server/client)

2015-03-02 Thread Eric Sandeen

I've not been keeping up with NCID (a caller id server/client system;
pretty neat, being able to send caller ID to mythtv, desktop notifications,
etc).

It needs some systemd love, and has newer upstream releases.  I was using
it on a CentOS 6 server, and have no good way to test it on newer releases.

There aren't a lot of bugs open; it just needs a little help to get it up
to snuff for current Fedora.

So if anyone wants it, have at it.  I'll go push the buttons on the pkgdb.
I don't mind hanging on to EPEL, because, well, it's been 0 work.  ;)
(and I have the system to test those).

Thanks,
-Eric
-- 
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: [EPEL-devel] distribution component in bugzilla

On Fri, 27 Feb 2015 19:15:46 -0700
Orion Poplawski or...@cora.nwra.com wrote:

 Could we get a Distribution component for Fedora EPEL in Bugzilla? 
 Might be useful for things like 
 https://bugzilla.redhat.com/show_bug.cgi?id=1197264

Well, we could make such a thing, but not sure it's really suited to
these kinds of bugs. Or it might end up with 'I want XYZ in epel, but I
don't want to/can't maintain it, please do it for me distribution' and
without lots of people manning that, I don't think we can do it. 

We do also have the epel trac? But I guess that doesn't help if you
want to depend on bugs in bugzilla.

kevin


pgpGwlqZcVaRY.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: koji is broken

On Sat, 28 Feb 2015 12:49:39 +0800
Christopher Meng cicku...@gmail.com wrote:

 I still met
 
 Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
 handshake failure')]
 
 this morning (2 hrs ago).

I think this is some kind of connectivity issue. 

Next time this happens can you run the koji command again with
'--debug' and see if anything stands out? Also make sure you can ping
and reach the koji web page. 

There's also a '--debug-xmlrpc' but I think that will show your cert
and other info that shouldn't be public, so you can run it, but don't
share that output in a bug ticket or anything. 

kevin


pgpXgRGOVE9UV.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi: Notified can be pushed, but refuses to push

On Sun, 01 Mar 2015 17:25:23 +0100
Ralf Corsepius rc040...@freenet.de wrote:

 In short: I don't see any reason, why bodhi should not accept push 
 requests.

This was a configuration bug/issue. Someone filed a ticket this morning
and we got it fixed up hopefully. 

Please re-try your requests now. 

kevin


pgpuhExK5mRmi.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Spec file - build requires systemd

2015-03-02 Thread Florian Weimer

On 03/02/2015 03:50 PM, Dave Melia wrote:
 On 2015-03-02 14:47, Dave Melia wrote:
 Hey,

 Sorry if this isn't the place to ask, but I'm looking at the spec file
 for nginx 1.7.10 and build requires systemd.  I'm wondering if this is
 actually the case for this version of nginx or is it just because
 Fedora has replaced init with systemd now?

 I'm assuming the only reason it matters is because of the locations of
 the service scripts etc?

Build requires on systemd are usually required for the definition of
systemd-related RPM macros:

https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations

-- 
Florian Weimer / Red Hat Product Security
-- 
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: Is systemd within a Docker container still recommended?

2015-03-02 Thread Daniel J Walsh


On 03/01/2015 10:41 PM, Michael DePaulo wrote:
 Hi,

 I am developing a Dockerfile for X2Go. I intend to submit a PR to
 fedora-Dockerfiles within a week.

 https://github.com/mikedep333/Fedora-Dockerfiles/tree/add-x2go

 (X2Go was already added in F20)
 https://fedoraproject.org/wiki/Changes/X2Go

 Example Dockerfile with systemd:
 https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/systemd/apache/Dockerfile

 However, I would like to know if the Fedora project still recommends
 that I use systemd, or if I should resort to using supervisord or a
 shell script.

 I merely need to start sshd and x2gocleansessions. Both have systemd
 unit files, but can be run via an init script too.

 When I do try systemd, I am experiencing known issues with cgroups and
 with mounting /run, unless I run a privileged container. It has been a
 while since there were any comments on the CLOSED NOTABUG bz on these
 issues.
 https://bugzilla.redhat.com/show_bug.cgi?id=1033604

 -Mike
We are continuing to work on making running systemd within a container
better.
I am trying to get a /run on tmpfs patch to be acceptable upstream.  But
we still
have a problem with systemd requiring /sys/fs/cgroup to be mounted
inside the container
to run.  Which allows for an information leak.


-- 
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: Is systemd within a Docker container still recommended?

2015-03-02 Thread Dave Melia


Hey,

Sorry if this isn't the place to ask, but I'm looking at the spec file 
for nginx 1.7.10 and build requires systemd.  I'm wondering if this is 
actually the case for this version of nginx or is it just because Fedora 
has replaced init with systemd now?


I'm assuming the only reason it matters is because of the locations of 
the service scripts etc?


Thanks,

Dave
--
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: Is systemd within a Docker container still recommended?

2015-03-02 Thread Reindl Harald




Am 02.03.2015 um 16:03 schrieb Mauricio Tavares:

On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering mzerq...@0pointer.de wrote:

That said, containers on Linux are not really about security, the
whole thing has more holes than a swiss cheese. Maybe one day the
security holes can be fixed, but as of now, it's simply not
secure. And this information leak is certainly the least of your
problems...


What would then be the recommended solution if containers are insecure?


full virtualized systems like KVM or whatever hypervisor



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is systemd within a Docker container still recommended?

2015-03-02 Thread Mauricio Tavares

On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering mzerq...@0pointer.de wrote:
On Mon, 02.03.15 09:17, Daniel J Walsh (dwa...@redhat.com) wrote:

On 03/01/2015 10:41 PM, Michael DePaulo wrote:
Hi,

I am developing a Dockerfile for X2Go. I intend to submit a PR to
fedora-Dockerfiles within a week.

https://github.com/mikedep333/Fedora-Dockerfiles/tree/add-x2go

(X2Go was already added in F20)
https://fedoraproject.org/wiki/Changes/X2Go

Example Dockerfile with systemd:
https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/systemd/apache/Dockerfile

However, I would like to know if the Fedora project still recommends
that I use systemd, or if I should resort to using supervisord or a
shell script.

I merely need to start sshd and x2gocleansessions. Both have systemd
unit files, but can be run via an init script too.

When I do try systemd, I am experiencing known issues with cgroups and
with mounting /run, unless I run a privileged container. It has been a
while since there were any comments on the CLOSED NOTABUG bz on these
issues.
https://bugzilla.redhat.com/show_bug.cgi?id=1033604

-Mike
We are continuing to work on making running systemd within a container
better.
I am trying to get a /run on tmpfs patch to be acceptable upstream. But
we still
have a problem with systemd requiring /sys/fs/cgroup to be mounted
inside the container
to run. Which allows for an information leak.

You'd have to get the kernel changed for that information leak to be
fixed.

That said, containers on Linux are not really about security, the
whole thing has more holes than a swiss cheese. Maybe one day the
security holes can be fixed, but as of now, it's simply not
secure. And this information leak is certainly the least of your
problems...

What would then be the recommended solution if containers are insecure?

Lennart

--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Dan Callaghan

Excerpts from Bohuslav Kabrda's message of 2015-03-02 21:59 +10:00:
 - Original Message -
  Under the current proposal every package with Python 3 dependencies
  would have to depend on a specific python3x-* package, so then it would
  be up to the maintainers of all those packages to manually bump their
  Requires from python34-* to python35-* at some point. Which, now that
  I think about it, is not that great. Even worse, if any packages form
  a transitive dependency chain then *all* packages in the chain have to
  update their Requires at the same time to avoid having a mix of
  python34-* and python35-* requirements.
 
 Not really. The requires/buildrequires should be in form of
 Requires: python%{python3_pkgversion}-six
 so when we change %python3_pkgversion in the minimal buildroot, 
 maintainer just rebuilds and gets updated requires.

Hmm okay. I didn't realise this.

So that means that:
* Fedora specfiles can't be used unchanged (they will require python3-*, 
  needs to have %{python3_pkgversion} macro inserted)
* applications will need to be rebuilt to pick up a change from 
  python34-* to python35-*
which is a bit unfortunate.

Is there any reason why we shouldn't just upgrade applications to the 
python35-* stack straight away, by providing python3-*?

-- 
Dan Callaghan dcall...@redhat.com
Software Engineer, Hosted  Shared Services
Red Hat, Inc.


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

[perl-Text-VimColor] 0.25 bump

commit 693797f78d258b2caa1312c469f3296384ed5b5d
Author: Petr Šabata con...@redhat.com
Date:   Mon Mar 2 13:49:58 2015 +0100

0.25 bump

 .gitignore  |  1 +
 perl-Text-VimColor.spec | 30 +-
 sources |  2 +-
 3 files changed, 19 insertions(+), 14 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b6e4c5f..5d09be2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Text-VimColor-0.11.tar.gz
 /Text-VimColor-0.22.tar.gz
 /Text-VimColor-0.23.tar.gz
 /Text-VimColor-0.24.tar.gz
+/Text-VimColor-0.25.tar.gz
diff --git a/perl-Text-VimColor.spec b/perl-Text-VimColor.spec
index 10ea49c..b895ca2 100644
--- a/perl-Text-VimColor.spec
+++ b/perl-Text-VimColor.spec
@@ -1,6 +1,6 @@
 Name:   perl-Text-VimColor
-Version:0.24
-Release:3%{?dist}
+Version:0.25
+Release:1%{?dist}
 Summary:Syntax color text in HTML or XML using Vim
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/Text-VimColor/
 Source0:
http://www.cpan.org/authors/id/R/RW/RWSTAUNER/Text-VimColor-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl
-BuildRequires:  perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires:  perl(ExtUtils::MakeMaker) = 6.76
 BuildRequires:  perl(File::ShareDir::Install) = 0.03
 BuildRequires:  perl(File::Temp)
 BuildRequires:  perl(IO::File)
@@ -20,14 +20,14 @@ BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(File::Copy)
 BuildRequires:  perl(File::ShareDir)
-BuildRequires:  perl(Path::Class)
+BuildRequires:  perl(Getopt::Long)
+BuildRequires:  perl(Path::Class) = 0.04
 BuildRequires:  perl(Symbol)
 BuildRequires:  perl(Term::ANSIColor) = 1.03
 # Tests
 BuildRequires:  perl(Config)
 BuildRequires:  perl(Exporter)
-BuildRequires:  perl(File::Spec::Functions)
-BuildRequires:  perl(Getopt::Long)
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(lib)
 BuildRequires:  perl(Test::More) = 0.88
@@ -37,10 +37,13 @@ BuildRequires:  vim-enhanced
 BuildRequires:  perl(Encode)
 BuildRequires:  perl(Tie::StdHandle)
 BuildRequires:  perl(XML::Parser)
-Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires:   perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo 
$version))
+Requires:   perl(Path::Class) = 0.04
 Requires:   perl(Term::ANSIColor) = 1.03
 Requires:   vim-enhanced
 
+%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}^perl\\(Path::Class\\)$
+
 %description
 This module tries to markup text files according to their syntax. It can be
 used to produce web pages with pretty-printed colorful source code samples.
@@ -52,12 +55,11 @@ interface to the Perl module Text::VimColor:
 %setup -q -n Text-VimColor-%{version}
 
 %build
-perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags} NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
 find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} +
 %{_fixperms} %{buildroot}/*
 
@@ -65,15 +67,17 @@ find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f 
{} +
 make test
 
 %files
+%license LICENSE
 %doc Changes README
 %{_bindir}/text-vimcolor
-%{perl_vendorlib}/Text
-%{perl_vendorlib}/Text/*
-%{perl_vendorlib}/auto/share/dist/Text-VimColor/*
+%{perl_vendorlib}/*
+%{_mandir}/man1/*
 %{_mandir}/man3/*
-%{_mandir}/man1/text-vimcolor.1.gz
 
 %changelog
+* Mon Mar 02 2015 Petr Šabata con...@redhat.com - 0.25-1
+- 0.25 bump
+
 * Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.24-3
 - Perl 5.20 rebuild
 
diff --git a/sources b/sources
index 756ebba..d80ea91 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-760eb75865168a5e6ede4287c9cf39af  Text-VimColor-0.24.tar.gz
+91ae616a8925bbf6bac3b8c85a003c1b  Text-VimColor-0.25.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

File Text-VimColor-0.25.tar.gz uploaded to lookaside cache by psabata

A file has been added to the lookaside cache for perl-Text-VimColor:

91ae616a8925bbf6bac3b8c85a003c1b  Text-VimColor-0.25.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-Text-VimColor/f22] 0.25 bump

Summary of changes:

  693797f... 0.25 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 1197404] perl-Text-VimColor-0.25 is available

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



--- Comment #4 from Fedora Update System upda...@fedoraproject.org ---
perl-Text-VimColor-0.25-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/perl-Text-VimColor-0.25-1.fc21

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=ODMX5sjuPPa=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

Yum-utils and DNF

2015-03-02 Thread Michael Mraka

Hi developers,

I'm trying to finish port of yum-utils scritps to DNF and I came across
couple of scripts I'm not sure whether they are just legacy stuff or
someone still uses them.  Do you need them? If so raise your voice and
tell us your use case so we can find the best way to support it.

I'm talking about:

show-changed-rco, show-installed - just a different dependency list formats,
   anyone uses it?

yum-groups-manager, verifytree - these are not client tool but rather repo group
manipulation and checks so if needed at all they should be better a part
of createrepo or similar package (librepo?)


Thanks for your feedback,

--
Michael Mráka
Software Management Engineering, Red Hat

-- 
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: Libinput now enabled as default xorg driver for F-22 workstation installs

2015-03-02 Thread drago01

On Mon, Mar 2, 2015 at 1:32 AM, Peter Hutterer peter.hutte...@who-t.net wrote:
On Thu, Feb 26, 2015 at 09:49:48AM +0100, Hans de Goede wrote:
Hi,

On 24-02-15 18:34, drago01 wrote:
On Mon, Feb 23, 2015 at 1:32 PM, Hans de Goede hdego...@redhat.com wrote:
Hi All,

As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg

We've been working on making xorg-x11-drv-libinput the default input driver
for the Xorg xserver under Fedora 22. All the necessary changes for this
are
in place for the GNOME and KDE desktops. So starting with the next Fedora
22
compose new Fedora 22 Workstation installations will be using
xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.

For existing installations the move to libinput will not happen
automatically, as we have not added a hard dependency on
xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the old
drivers until they have adopted their mouse/touchpad configuration settings
tools to also work with xorg-x11-drv-libinput.

If you're running F-22 with GNOME or KDE, please do the following to switch
to the new driver:

sudo dnf install xorg-x11-drv-libinput

And let us know if you experience any issues while using the new driver.

So we'd have two sets of users ... those who upgraded and those how
reinstalled running different drivers for the same hardware?

Yes, we need to maintain both stacks for a while anyways for e.g. lxde users,
etc. Given that XFCE now supports libinput too, we could reconsider this
and make xorg-drv-libinput a hard dep of the X server so that everyone gets
it, but officially we are past the end of the feature merge window.

Peter, any thoughts on this ?

not this cycle, IMO. there are some behaviour changes between
evdev/synaptics and libinput. That's fine for a new install, but changing
that on update can be considered a regression for some. At least
for F22 I think we should leave things as is.

Well going by the workstation PRD:

Upgrading the system multiple times through the upgrade process
should give *a result that is the same as an original install of
Fedora Workstation*. [...]
(https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Overall_plans_and_policies_for_the_product)

if it is good enough for new installs it is good enough for upgrades.
--
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: rawhide report: 20150302 changes

2015-03-02 Thread Ben Boeckel

On Mon, Mar 02, 2015 at 05:05:28 -0500, Jens Petersen wrote:
 If you want to help get Agda out of the rawhide and branched reports
 then please help with reviewing the 6 new deps packages in the bug dependency 
 tree:
 
   https://bugzilla.redhat.com/showdependencytree.cgi?id=1164120

I'll look at them tonight.

--Ben
-- 
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 1197767] New: perl-Math-Int64 FTBFS on s390 due to failing test

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

Bug ID: 1197767
   Summary: perl-Math-Int64 FTBFS on s390 due to failing test
   Product: Fedora
   Version: rawhide
 Component: perl-Math-Int64
  Assignee: dd...@cpan.org
  Reporter: jca...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org
Blocks: 467765 (ZedoraTracker)



Created attachment 997110
  -- https://bugzilla.redhat.com/attachment.cgi?id=997110action=edit
Possible fix

Build fails probably due to overflow in Math-Int64.t with:
.
.
.
+ make test
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -MTest::Harness
-e undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')
t/*.t
t/as_int64.t  ok
t/die_on_overflow.t . ok
t/Math-Int64-Native.t ... ok
#   Failed test 'max int64  63'
#   at t/Math-Int64.t line 183.
#  got: '0'
# expected: '1'
#   Failed test 'max int64 = 63'
#   at t/Math-Int64.t line 187.
#  got: '0'
# expected: '1'
# Looks like you failed 2 tests of 1139.
t/Math-Int64.t .. 
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/1139 subtests 
t/Math-UInt64-Native.t .. ok
t/Math-UInt64.t . ok
t/MSC.t . ok
t/pods.t  skipped: Only the author needs to check that POD docs
are right
t/pow.t . ok
t/storable.t  ok
Test Summary Report
---
t/Math-Int64.t(Wstat: 512 Tests: 1139 Failed: 2)
  Failed tests:  1138-1139
  Non-zero exit status: 2
Files=10, Tests=2511,  0 wallclock secs ( 0.14 usr  0.01 sys +  0.33 cusr  0.02
csys =  0.50 CPU)
Result: FAIL
.
.
.

Using int64 in ipow sub-routine seems to make test pass. In attachment is patch
with this change. Could you please review this patch and forward it to upstream
if correct.

Failed build:

http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=304185


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=467765
[Bug 467765] Fedora for System z (s390): Bug Tracker
-- 
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=BPeE66ROi4a=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 1197692] perl-Gnome2-GConf-1.044-21.fc23 FTBFS: blib/arch/auto/Gnome2/GConf/GConf.so: undefined symbol: gconf_engine_key_is_writable

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

External Bug ID||CPAN 91577



-- 
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=8ShjFvCvJda=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-SQL-Translator] Avoid X11 dependency by Subpackaging SQL::Translator::Producer::Diagram

commit 042f51b30ae101d48a56cc7b53580c5d2f672c35
Author: Petr Šabata con...@redhat.com
Date:   Mon Mar 2 15:19:30 2015 +0100

Avoid X11 dependency by Subpackaging SQL::Translator::Producer::Diagram

 perl-SQL-Translator.spec | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)
---
diff --git a/perl-SQL-Translator.spec b/perl-SQL-Translator.spec
index 360135f..425d920 100644
--- a/perl-SQL-Translator.spec
+++ b/perl-SQL-Translator.spec
@@ -1,7 +1,7 @@
 Name:   perl-SQL-Translator
 Summary:Manipulate structured data definitions (SQL and more)
 Version:0.11021
-Release:1%{?dist}
+Release:2%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/I/IL/ILMARI/SQL-Translator-%{version}.tar.gz
@@ -127,6 +127,12 @@ producers, or to manipulate the parsed data via the 
built-in object model.
 Presently only the definition parts of SQL are handled (CREATE, ALTER),
 not the manipulation of data (INSERT, UPDATE, DELETE).
 
+%package Producer-Diagram
+Summary:ER diagram producer for SQL::Translator
+
+%description Producer-Diagram
+ER diagram producer for SQL::Translator.
+
 %prep
 %setup -q -n SQL-Translator-%{version}
 # Remove bundled modules
@@ -154,8 +160,17 @@ make test
 %{_bindir}/*
 %{perl_vendorlib}/*
 %{_mandir}/man[13]/*
+%exclude %{perl_vendorlib}/SQL/Translator/Producer/Diagram.pm
+%exclude %{_mandir}/man3/SQL::Translator::Producer::Diagram.*
+
+%files Producer-Diagram
+%{perl_vendorlib}/SQL/Translator/Producer/Diagram.pm
+%{_mandir}/man3/SQL::Translator::Producer::Diagram.*
 
 %changelog
+* Mon Mar 02 2015 Petr Šabata con...@redhat.com - 0.11021-2
+- Avoid X11 dependency by Subpackaging SQL::Translator::Producer::Diagram
+
 * Tue Feb 03 2015 Petr Šabata con...@redhat.com - 0.11021-1
 - 0.11021 bump
 
--
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

Re: Is systemd within a Docker container still recommended?

2015-03-02 Thread Lennart Poettering

On Mon, 02.03.15 09:17, Daniel J Walsh (dwa...@redhat.com) wrote:

On 03/01/2015 10:41 PM, Michael DePaulo wrote:
Hi,

I am developing a Dockerfile for X2Go. I intend to submit a PR to
fedora-Dockerfiles within a week.

https://github.com/mikedep333/Fedora-Dockerfiles/tree/add-x2go

(X2Go was already added in F20)
https://fedoraproject.org/wiki/Changes/X2Go

Example Dockerfile with systemd:
https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/systemd/apache/Dockerfile

However, I would like to know if the Fedora project still recommends
that I use systemd, or if I should resort to using supervisord or a
shell script.

I merely need to start sshd and x2gocleansessions. Both have systemd
unit files, but can be run via an init script too.

You'd have to get the kernel changed for that information leak to be
fixed.

Lennart

Re: Is systemd within a Docker container still recommended?

2015-03-02 Thread Dave Melia


My apologies -- I forgot the change the title! /embarrassment

 2015-03-02 14:47, Dave Melia wrote:

Hey,

Sorry if this isn't the place to ask, but I'm looking at the spec file
for nginx 1.7.10 and build requires systemd.  I'm wondering if this is
actually the case for this version of nginx or is it just because
Fedora has replaced init with systemd now?

I'm assuming the only reason it matters is because of the locations of
the service scripts etc?

Thanks,

Dave


--
Dave Melia
Site : http://www.thinklinux.co.uk
Email: d...@thinklinux.co.uk
Linkedin : http://uk.linkedin.com/in/davemelia
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Spec file - build requires systemd

2015-03-02 Thread Dave Melia


On 2015-03-02 14:47, Dave Melia wrote:

Hey,

Sorry if this isn't the place to ask, but I'm looking at the spec file
for nginx 1.7.10 and build requires systemd.  I'm wondering if this is
actually the case for this version of nginx or is it just because
Fedora has replaced init with systemd now?

I'm assuming the only reason it matters is because of the locations of
the service scripts etc?

Thanks,

Dave


--
Dave Melia
Site : http://www.thinklinux.co.uk
Email: d...@thinklinux.co.uk
Linkedin : http://uk.linkedin.com/in/davemelia
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: polymake

2015-03-02 Thread buildsys



polymake has broken dependencies in the rawhide tree:
On x86_64:
polymake-2.13-18.git20141013.fc22.x86_64 requires perl = 4:5.20.1
On i386:
polymake-2.13-18.git20141013.fc22.i686 requires perl = 4:5.20.1
On armhfp:
polymake-2.13-18.git20141013.fc22.armv7hl requires perl = 4:5.20.1
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

Re: [EPEL-devel] Python 3 discussion

On Mon, 2 Mar 2015 06:59:29 -0500 (EST)
Bohuslav Kabrda bkab...@redhat.com wrote:

 - Original Message -
  Excerpts from Orion Poplawski's message of 2015-02-28 04:36 +10:00:
   all python34 packages are retired
  
  Except there is no way to retire an individual subpackage, is there?
  Instead we are saying, the python34-* subpackage will just go away.
 
 Yeah, I'm still not sure how this should be handled. Does anyone know
 whether the python34- subpackage will disappear from the repo if only
 python35- is built in a newer build? I'd tend to think so, since I
 think Koji builds repos from the newest builds, so if the package is
 rebuilt without python34- subpackage, it won't be there when the repo
 regenerates... But maybe I'm completely wrong here.

It would. mash pulls the 'latest tagged' build from the tag. So, if the
newer one has different subpackages that will get used and the old one
is completely gone. 

kevin


pgpUr5qrvSQLJ.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[perl-Git-CPAN-Patch] Do not use /usr/bin/env to interpret git-cpan

commit 860bbb3cc00cf1b4acdad62f45f7ef1ac5be9885
Author: Petr Písař ppi...@redhat.com
Date:   Mon Mar 2 13:47:31 2015 +0100

Do not use /usr/bin/env to interpret git-cpan

 perl-Git-CPAN-Patch.spec | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
---
diff --git a/perl-Git-CPAN-Patch.spec b/perl-Git-CPAN-Patch.spec
index 6e6b36a..2344d6b 100644
--- a/perl-Git-CPAN-Patch.spec
+++ b/perl-Git-CPAN-Patch.spec
@@ -1,7 +1,7 @@
 Name:   perl-Git-CPAN-Patch
 Summary:Patch CPAN modules using Git
 Version:2.0.3
-Release:9%{?dist}
+Release:10%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/Y/YA/YANICK/Git-CPAN-Patch-%{version}.tar.gz
@@ -92,6 +92,8 @@ sending back patches to its maintainer.
 
 %prep
 %setup -q -n Git-CPAN-Patch-%{version}
+# Fix shellbang
+sed -i -e '1 s|^#!/usr/bin/env perl|#!perl|' bin/git-cpan
 
 %build
 perl Build.PL installdirs=vendor
@@ -122,6 +124,9 @@ git config --global user.name Git-CPAN-Patch Owner
 %{_mandir}/man1/*
 
 %changelog
+* Mon Mar 02 2015 Petr Pisar ppi...@redhat.com - 2.0.3-10
+- Do not use /usr/bin/env to interpret git-cpan
+
 * Thu Dec 18 2014 Petr Šabata con...@redhat.com - 2.0.3-9
 - Correct MODULE_COMPAT
 
--
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

Re: Fwd: hotness tried to map perl-Class-Virtual to an upstream project, but failed due to ambiguity. 5682 other projects share the same homepage

On Sat, Feb 28, 2015 at 05:25:51AM +0600, Denis Fateyev wrote:
 Recently, I've got several such messages for each of new submitted packages.
 Is there something wrong with the upstream monitoring for Perl modules?

 -- Forwarded message --
 From: notificati...@fedoraproject.org
 Date: Fri, Feb 27, 2015 at 11:59 PM
 Subject: hotness tried to map perl-Class-Virtual to an upstream project,
 but failed due to ambiguity. 5682 other projects share the same homepage

 hotness tried to map perl-Class-Virtual to an upstream project, but failed
 due to ambiguity.  5682 other projects share the same homepage
 https://bugzilla.redhat.com/1195862

Upstream monitoring is performed by https://release-monitoring.org/. Please
find contact there and report you issue there. There is nothing Perl packagers
can do with it.

-- Petr

pgpSxHrBmg7v1.pgp
Description: PGP signature
--
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 1197694] New: perl-Dancer2-0.158000-1.fc23 FTBFS: t/route-pod-coverage/route-pod-coverage.t test fails

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

Bug ID: 1197694
   Summary: perl-Dancer2-0.158000-1.fc23 FTBFS:
t/route-pod-coverage/route-pod-coverage.t test fails
   Product: Fedora
   Version: rawhide
 Component: perl-Dancer2
  Assignee: dd...@cpan.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



perl-Dancer2-0.158000-1.fc23 fails to build because tests fail:

t/roles/hook.t  ok

#   Failed test 'post /in_testpod/* is documented'
#   at /builddir/build/BUILD/Dancer2-0.158000/blib/lib/Dancer2/Test.pm line
494.

#   Failed test 'post /me:id is documented'
#   at /builddir/build/BUILD/Dancer2-0.158000/blib/lib/Dancer2/Test.pm line
494.

#   Failed test 'get /in_testpod is documented'
#   at /builddir/build/BUILD/Dancer2-0.158000/blib/lib/Dancer2/Test.pm line
494.

#   Failed test 'get /hello is documented'
#   at /builddir/build/BUILD/Dancer2-0.158000/blib/lib/Dancer2/Test.pm line
494.

#   Failed test 'get /me:id is documented'
#   at /builddir/build/BUILD/Dancer2-0.158000/blib/lib/Dancer2/Test.pm line
494.
# Looks like you failed 5 tests of 5.
#   Failed test 't::lib::TestPodis pod covered'
#   at t/route-pod-coverage/route-pod-coverage.t line 9.
#   Failed test 'my pod looks like expected'
#   at t/route-pod-coverage/route-pod-coverage.t line 24.
# Structures begin differing at:
#  $got-{t::lib::TestPod}{has_pod} = '0'
# $expected-{t::lib::TestPod}{has_pod} = '1'
# Looks like you failed 2 tests of 2.
t/route-pod-coverage/route-pod-coverage.t . 
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/2 subtests 
[...]
Test Summary Report
---
t/route-pod-coverage/route-pod-coverage.t   (Wstat: 512 Tests: 2
Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
Files=116, Tests=1437, 43 wallclock secs ( 0.46 usr  0.12 sys + 38.75 cusr 
3.21 csys = 42.54 CPU)
Result: FAIL

Not so accurate difference between working and failing build root:

Removed packages:
kernel-headers-3.20.0
libxml2-2.9.2
ncurses-5.9
ncurses-base-5.9
ncurses-libs-5.9
nss-tools-3.17.4
openldap-2.4.40
p11-kit-0.23.1
p11-kit-trust-0.23.1
pcre-8.36
perl-CPAN-Meta-Requirements-2.132
perl-Getopt-Long-2.44
perl-Module-CoreList-5.20150214
perl-Params-Validate-1.17
perl-Pod-Simple-3.29
perl-Pod-Usage-1.65
perl-strictures-1.005006
perl-URI-1.65
redhat-rpm-config-28
which-2.20
Added packages:
basesystem-10.0
curl-7.41.0
gc-7.4.2
gmp-6.0.0
libcurl-7.41.0
libgcrypt-1.6.2
perl-CPAN-Meta-Requirements-2.133
perl-Getopt-Long-2.45
perl-Module-CoreList-5.20150220
perl-Params-Validate-1.18
perl-Pod-Simple-3.30
perl-Pod-Usage-1.66
perl-strictures-2.00
perl-URI-1.67
python3-setuptools-12.3
sqlite-3.8.8.3

-- 
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=VR5vCa6lrPa=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 1197404] perl-Text-VimColor-0.25 is available

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



--- Comment #2 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
psabata's perl-Text-VimColor-0.25-1.fc23 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=617100

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

Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Bohuslav Kabrda

- Original Message -
 This is a followup to the EPEL IRC meeting discussion about python 3.  I had
 a
 couple questions which led me to take Slavek's excellent work and try some
 changes here: https://fedoraproject.org/wiki/User:Orion/EPEL7_Python3
 
 Main ideas:
 - (bikeshedding) - I didn't like the wording other, so I went with next.

Right, this naming makes more sense due to the way your proposal works - in 
other words, next is always the higher version, assuming there are two 
parallel stacks. This isn't always the case in my proposal, which is why I used 
other.

 - I didn't like having to toggle a macro in the spec files, I'm lazy

+1, this can be done globally in python3-pkgversion-macros regardless which 
proposal we use.

 - What happens on the user's end?
 
 So:
 
 Lifecycle of python3X stacks, rebuilding:
 
 when a new python3X+1 is built in EPEL - let's say that there is python34
 and python35 has just been introduced:
 A new python3-pkgversion-macros is build defining the %python3_next*
 macros.

I think that macro file *in python35-devel* should define this - the main 
python3 defines %python3* macros, the next/other python3 defines 
%python3_next*.

 (scripted) mass rebuild is run to build as much of the new stack
 possible automatically.
 At some point /usr/bin/python3 is switched from python34 to python35.
 at a certain point at time an announcement is made that python34 is
 to
 be retired and python35 is to be *the* one. At this point:
 python3-pkgversion-macros is rebuilt removing the %python3_next*
 macros.

As per my comment above, we wouldn't need to remove the next macros, we would 
rebuild python35 as main python3, thus giving it the normal %python3 macros.

 python35 is rebuilt defining the normal %python3_* macros
 all python34 packages are retired
 
 At this point all packages build just python35-X subpackages
 
 
 
 What I still don't understand is what this looks like on the user end, how do
 they go from 34 to 35?  For app users (#!/usr/bin/python3), it seems like
 this
 should be as automatic as possible.  So shouldn't they still use
 /usr/bin/python3 rather than /usr/bin/python3X so they get updated
 automatically?

I think applications should use /usr/bin/python3.4 (at least packaged 
applications). Otherwise we could theoretically end up in a situation where 
/usr/bin/python3 is owned by python35, but the application RPM still has 
python34- dependencies and thus the app doesn't work.

I think this is actually one of the reasons why I thought it makes sense to 
keep both python34 and python35 living together in the state where python35 is 
the main python3 (having the default macros and owning /usr/bin/python3) and 
python34 is the other. Let's take this example:
- there's an application foo written in python, which requires six
- it doesn't make sense to build the application for both python34 and 
python35, since it's an application, not a library
- this means it doesn't make sense for package maintainer to introduce the 
%python3_{other or next}* macros to the specfile, maintainer just wants to 
build with the python3
- so this means that we should do this:
-- python 3.5 is released, we build it in EPEL and turn with_python3_other to 1 
in python3-pkgversion-macros
-- then there's a period when python34 and python35 coexist and python34 is 
the main python - in this period, *libraries* are rebuilt to provide both 
python34- and python35- subpackages
-- python34 and python35 are switched (the default macros now point to 35 and 
it also owns /usr/bin/python3 now)
-- then there's a period when python34 and python35 coexist and python35 is 
the main python - in this period, *applications* are rebuilt for python35 
(may take some time, there will likely be a period when there are some apps on 
python34 and some already on python35)
-- when all applications are rebuilt for 35, with_python3_other is set to 0 and 
we now have just python35 and it's the main python3

Does this make sense or am I missing something? I'd need to do some minor 
changes+explanations to my proposal to accomodate this, but I still think it 
makes sense.

 What about all of the old python34 packages left on their systems after
 retirement?  Is there some way they can get cleaned up automatically?

I'm not sure about that... and I'm also not sure we want to do that, people may 
still want to keep these around for their own non-system applications to 
migrate.

Thanks a lot for this discussion,
Slavek

 --
 Orion Poplawski
 Technical Manager 303-415-9701 x222
 NWRA, Boulder/CoRA Office FAX: 303-415-9702
 3380 Mitchell Lane   or...@nwra.com
 Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org

[Bug 1197692] New: perl-Gnome2-GConf-1.044-21.fc23 FTBFS: blib/arch/auto/Gnome2/GConf/GConf.so: undefined symbol: gconf_engine_key_is_writable

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

Bug ID: 1197692
   Summary: perl-Gnome2-GConf-1.044-21.fc23 FTBFS:
blib/arch/auto/Gnome2/GConf/GConf.so: undefined
symbol: gconf_engine_key_is_writable
   Product: Fedora
   Version: rawhide
 Component: perl-Gnome2-GConf
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com



perl-Gnome2-GConf-1.044-21.fc23 fails to build in F23:

/usr/bin/perl -MExtUtils::Command::MM -e 'cp_nonempty' -- GConf.bs
blib/arch/auto/Gnome2/GConf/GConf.bs 644
Generating POD...
Can't load 'blib/arch/auto/Gnome2/GConf/GConf.so' for module Gnome2::GConf:
blib/arch/auto/Gnome2/GConf/GConf.so: undefined symbol:
gconf_engine_key_is_writable at /usr/lib/perl5/DynaLoader.pm line 193.
 at -e line 0.
Compilation failed in require.

Difference between working and failing build root:

Removed packages:
acl-2.2.52-7.fc22
audit-libs-2.4.1-1.fc22
binutils-2.25-5.fc22
bzip2-1.0.6-14.fc22
bzip2-libs-1.0.6-14.fc22
coreutils-8.23-6.fc22
cpio-2.11-33.fc22
curl-7.40.0-1.fc22
dbus-glib-0.104-1.fc22
diffutils-3.3-9.fc22
dwz-0.11-4.fc22
expat-2.1.0-10.fc22
file-5.22-1.fc22
file-libs-5.22-1.fc22
fipscheck-1.4.1-7.fc22
fipscheck-lib-1.4.1-7.fc22
gawk-4.1.1-6.fc22
GConf2-3.2.6-11.fc22
GConf2-devel-3.2.6-11.fc22
gdb-7.8.90.20150214-7.fc23
gdbm-1.11-4.fc22
gdbm-devel-1.11-4.fc22
glib2-2.43.90-1.fc23
glib2-devel-2.43.90-1.fc23
glibc-2.21.90-3.fc23
glibc-common-2.21.90-3.fc23
glibc-devel-2.21.90-3.fc23
glibc-headers-2.21.90-3.fc23
gnupg2-2.1.2-1.fc23
grep-2.21-3.fc22
groff-base-1.22.3-3.fc22
guile-2.0.11-4.fc22
gzip-1.6-6.fc22
info-5.2-8.fc22
keyutils-libs-1.5.9-4.fc22
kmod-19-1.fc22
kmod-libs-19-1.fc22
libacl-2.2.52-7.fc22
libarchive-3.1.2-10.fc22
libattr-2.4.47-9.fc22
libcom_err-1.42.12-2.fc23
libcurl-7.40.0-1.fc22
libdb-5.3.28-9.fc22
libdb-devel-5.3.28-9.fc22
libdb-utils-5.3.28-9.fc22
libgcrypt-1.6.2-2.fc22
libidn-1.29-2.fc22
libpwquality-1.2.4-2.fc22
libuser-0.60-6.fc22
libxml2-2.9.2-3.fc23
libxml2-devel-2.9.2-3.fc23
lua-5.3.0-1.fc22
make-4.0-3.1.fc22
ncurses-5.9-18.20150214.fc23
ncurses-base-5.9-18.20150214.fc23
ncurses-libs-5.9-18.20150214.fc23
nss-3.17.4-3.fc22
nss-sysinit-3.17.4-3.fc22
nss-tools-3.17.4-3.fc22
openssl-libs-1.0.1k-2.fc22
p11-kit-0.23.1-1.fc23
p11-kit-trust-0.23.1-1.fc23
patch-2.7.4-1.fc22
perl-5.20.2-321.fc23
perl-devel-5.20.2-321.fc23
perl-libs-5.20.2-321.fc23
perl-macros-5.20.2-321.fc23
perl-Pod-Escapes-1.06-321.fc23
pkgconfig-0.28-6.fc22
psmisc-22.21-5.fc22
rpm-4.12.0.1-7.fc23
rpm-build-4.12.0.1-7.fc23
rpm-build-libs-4.12.0.1-7.fc23
rpm-libs-4.12.0.1-7.fc23
rpm-plugin-selinux-4.12.0.1-7.fc23
sed-4.2.2-9.fc22
shared-mime-info-1.4-2.fc22
sqlite-3.8.8-2.fc22
tar-1.28-3.fc22
unzip-6.0-20.fc23
which-2.20-10.fc23
Added packages:
acl-2.2.52-8.fc23
audit-libs-2.4.1-2.fc23
binutils-2.25-6.fc23
bzip2-1.0.6-15.fc23
bzip2-libs-1.0.6-15.fc23
coreutils-8.23-7.fc23
cpio-2.11-34.fc23
curl-7.40.0-2.fc23
dbus-glib-0.104-2.fc23
diffutils-3.3-10.fc23
dwz-0.11-5.fc23
expat-2.1.0-11.fc23
file-5.22-2.fc23
file-libs-5.22-2.fc23
fipscheck-1.4.1-8.fc23
fipscheck-lib-1.4.1-8.fc23
gawk-4.1.1-7.fc23
GConf2-3.2.6-12.fc23
GConf2-devel-3.2.6-12.fc23
gdb-7.8.90.20150214-8.fc23
gdbm-1.11-5.fc23
gdbm-devel-1.11-5.fc23
glib2-2.43.90-2.fc23
glib2-devel-2.43.90-2.fc23
glibc-2.21.90-3.fc23.1
glibc-common-2.21.90-3.fc23.1
glibc-devel-2.21.90-3.fc23.1
glibc-headers-2.21.90-3.fc23.1
gnupg2-2.1.2-2.fc23
grep-2.21-4.fc23
groff-base-1.22.3-4.fc23
guile-2.0.11-5.fc23
gzip-1.6-7.fc23
info-5.2-9.fc23
keyutils-libs-1.5.9-5.fc23
kmod-19-2.fc23
kmod-libs-19-2.fc23
libacl-2.2.52-8.fc23
libarchive-3.1.2-11.fc23
libattr-2.4.47-10.fc23
libcom_err-1.42.12-3.fc23
libcurl-7.40.0-2.fc23
libdb-5.3.28-10.fc23
libdb-devel-5.3.28-10.fc23
libdb-utils-5.3.28-10.fc23
libgcrypt-1.6.2-3.fc23
libidn-1.29-3.fc23
libpwquality-1.2.4-3.fc23
libuser-0.60-7.fc23
libxml2-2.9.2-4.fc23
libxml2-devel-2.9.2-4.fc23
lua-5.3.0-2.fc23
make-4.0-4.1.fc23
ncurses-5.9-19.20150214.fc23
ncurses-base-5.9-19.20150214.fc23
ncurses-libs-5.9-19.20150214.fc23
nss-3.17.4-4.fc23
nss-sysinit-3.17.4-4.fc23
nss-tools-3.17.4-4.fc23
openssl-libs-1.0.1k-3.fc23
p11-kit-0.23.1-2.fc23
p11-kit-trust-0.23.1-2.fc23

[perl-Text-VimColor/f21] (2 commits) ...0.25 bump

Summary of changes:

  76347ba... Perl 5.20 rebuild (*)
  693797f... 0.25 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 1197404] perl-Text-VimColor-0.25 is available

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



--- Comment #3 from Fedora Update System upda...@fedoraproject.org ---
perl-Text-VimColor-0.25-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/perl-Text-VimColor-0.25-1.fc22

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

[POC-change] Fedora packages point of contact updates

2015-03-02 Thread nobody

Change in package status over the last 168 hours


28 packages were orphaned
-
apt [f22, f21, f20, master] was orphaned by kevin
 Debian's Advanced Packaging Tool with RPM support
 https://admin.fedoraproject.org/pkgdb/package/apt
django-annoying [el6] was orphaned by sundaram
 Eliminate annoying things in the Django framework
 https://admin.fedoraproject.org/pkgdb/package/django-annoying
django-avatar [el6] was orphaned by sundaram
 A django module for handling user avatars
 https://admin.fedoraproject.org/pkgdb/package/django-avatar
django-celery [el6] was orphaned by sundaram
 Django Celery Integration
 https://admin.fedoraproject.org/pkgdb/package/django-celery
django-countries [el6] was orphaned by sundaram
 Provides a country field for Django models
 https://admin.fedoraproject.org/pkgdb/package/django-countries
django-keyedcache [el6] was orphaned by sundaram
 Utilities for simplified development of cache aware objects
 https://admin.fedoraproject.org/pkgdb/package/django-keyedcache
django-kombu [el6] was orphaned by sundaram
 Kombu transport using the Django database as a message store
 https://admin.fedoraproject.org/pkgdb/package/django-kombu
django-picklefield [el6] was orphaned by sundaram
 Implementation of a pickled object field
 https://admin.fedoraproject.org/pkgdb/package/django-picklefield
django-pylibmc [el6] was orphaned by sundaram
 Django cache backend using pylibmc
 https://admin.fedoraproject.org/pkgdb/package/django-pylibmc
django-recaptcha [el6] was orphaned by sundaram
 A Django application for adding ReCAPTCHA to a form
 https://admin.fedoraproject.org/pkgdb/package/django-recaptcha
django-registration [el6] was orphaned by sundaram
 A user-registration application for Django
 https://admin.fedoraproject.org/pkgdb/package/django-registration
django-threaded-multihost [el6] was orphaned by sundaram
 Django app to enable multi-site awareness in Django apps
 https://admin.fedoraproject.org/pkgdb/package/django-threaded-multihost
fedora-package-config-apt [f22, f21, f20, master] was orphaned by kevin
 Fedora configuration files for the apt-rpm package manager
 https://admin.fedoraproject.org/pkgdb/package/fedora-package-config-apt
fpc [el6, epel7, el5] was orphaned by tbzatek
 Free Pascal Compiler
 https://admin.fedoraproject.org/pkgdb/package/fpc
freenx-server [f22, f21, f20, master] was orphaned by kevin
 Free Software (GPL) Implementation of the NX Server
 https://admin.fedoraproject.org/pkgdb/package/freenx-server
greylistd [f20] was orphaned by kevin
 Greylisting daemon
 https://admin.fedoraproject.org/pkgdb/package/greylistd
gtk-smooth-engine [f22, master] was orphaned by raveit65
 The Smooth engine for GTK+-2.0
 https://admin.fedoraproject.org/pkgdb/package/gtk-smooth-engine
ingo [f20] was orphaned by tibbs
 The Horde web-based Email Filter Rules Manager
 https://admin.fedoraproject.org/pkgdb/package/ingo
ivtv-firmware [f22, f21, f20, master] was orphaned by kevin
 Firmware for the Hauppauge PVR 250/350/150/500/USB2 model series
 https://admin.fedoraproject.org/pkgdb/package/ivtv-firmware
ivtv-utils [f22, f21, f20, master] was orphaned by kevin
 Tools for the iTVC15/16 and CX23415/16 driver
 https://admin.fedoraproject.org/pkgdb/package/ivtv-utils
kronolith [f20] was orphaned by tibbs
 The Horde calendar application
 https://admin.fedoraproject.org/pkgdb/package/kronolith
lazarus [el6, epel7, el5] was orphaned by tbzatek
 Lazarus Component Library and IDE for Freepascal
 https://admin.fedoraproject.org/pkgdb/package/lazarus
libcdaudio [f22, f21, f20, master] was orphaned by kevin
 Control operation of a CD-ROM when playing audio CDs
 https://admin.fedoraproject.org/pkgdb/package/libcdaudio
mediawiki-openid [f22, f21, f20, master] was orphaned by kevin
 The OpenID extension for MediaWiki
 https://admin.fedoraproject.org/pkgdb/package/mediawiki-openid
rubygem-spruz [f22, f21, f20, el6, master] was orphaned by vondruch
 Useful tools library in Ruby
 https://admin.fedoraproject.org/pkgdb/package/rubygem-spruz
synaptic [f22, f21, f20, master] was orphaned by kevin
 Graphical frontend for APT package manager.
 https://admin.fedoraproject.org/pkgdb/package/synaptic
turba [f20] was orphaned by tibbs
 The Horde contact management application
 https://admin.fedoraproject.org/pkgdb/package/turba
tuxcmd [f22, f21, f20, el6, master] was orphaned by tbzatek
 Tux Commander: file manager with 2 panels side by side using GTK2
 https://admin.fedoraproject.org/pkgdb/package/tuxcmd

1 packages were retired

python3-dateutil [f22, master] was retired by tomspur
 Powerful extensions to the standard datetime module

Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Bohuslav Kabrda

- Original Message -
 Excerpts from Bohuslav Kabrda's message of 2015-03-02 21:59 +10:00:
  - Original Message -
   Under the current proposal every package with Python 3 dependencies
   would have to depend on a specific python3x-* package, so then it would
   be up to the maintainers of all those packages to manually bump their
   Requires from python34-* to python35-* at some point. Which, now that
   I think about it, is not that great. Even worse, if any packages form
   a transitive dependency chain then *all* packages in the chain have to
   update their Requires at the same time to avoid having a mix of
   python34-* and python35-* requirements.
  
  Not really. The requires/buildrequires should be in form of
  Requires: python%{python3_pkgversion}-six
  so when we change %python3_pkgversion in the minimal buildroot,
  maintainer just rebuilds and gets updated requires.
 
 Hmm okay. I didn't realise this.
 
 So that means that:
 * Fedora specfiles can't be used unchanged (they will require python3-*,
   needs to have %{python3_pkgversion} macro inserted)

True, but note that we'll make %python3_pkgversion macro available also in 
Fedora (always defined to 3), so once this change is done, it'll be possible 
to have the same specfile both in Fedora and EPEL.

 * applications will need to be rebuilt to pick up a change from
   python34-* to python35-*
 which is a bit unfortunate.
 
 Is there any reason why we shouldn't just upgrade applications to the
 python35-* stack straight away, by providing python3-*?

Yeah. First of all, it may happen that there are some minor backwards 
incompatibilities. Lots of packages run tests during buildtime, so these will 
be caught.
Another reason is that there are applications, which store files in 
/usr/lib/python3.X/site-packages - these need to be rebuilt anyway, since they 
have the Python minor version incorporated in path of files.
I really think that we should rebuild applications with new Python 3.X.

Slavek

 --
 Dan Callaghan dcall...@redhat.com
 Software Engineer, Hosted  Shared Services
 Red Hat, Inc.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Failed to load vesa with undefined symbol (was: Re: hardening breaks X.org)

2015-03-02 Thread Hans de Goede


Hi,

On 02-03-15 12:00, Moez Roy wrote:

On Mon, Mar 2, 2015 at 1:30 AM, Christopher Meng cicku...@gmail.com wrote:

Ok, this time is vesa's problem:

http://lists.x.org/archives/xorg/2015-February/057183.html

But hardening breaks it indeed.

--

Yours sincerely,
Christopher Meng

http://cicku.me


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


Hmm, people seem to be confusing 2 different issues here, AFAICT the
hardening problem is a F23/rawhide only problem. The vesa driver
failing to load on F-22 seems to have nothing to do with
missing symbols, The X log file attached to the above bug says:

[82.967] (II) VESA(0): initializing int10
[82.970] (EE) VESA(0): Cannot read int vect

So the vesa driver is loaded, but something else goes wrong...

Regards,

Hans

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

File Pod-Usage-1.67.tar.gz uploaded to lookaside cache by ppisar

A file has been added to the lookaside cache for perl-Pod-Usage:

1570995a48e048d16c879906e4acb51e  Pod-Usage-1.67.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-Pod-Usage] 1.67 bump

commit 58690a3151acac8a939cc308d3679b3c83bd426c
Author: Petr Písař ppi...@redhat.com
Date:   Mon Mar 2 10:41:05 2015 +0100

1.67 bump

 .gitignore  | 1 +
 perl-Pod-Usage.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6c6db16..2e14c38 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Pod-Usage-1.64.tar.gz
 /Pod-Usage-1.65.tar.gz
 /Pod-Usage-1.66.tar.gz
+/Pod-Usage-1.67.tar.gz
diff --git a/perl-Pod-Usage.spec b/perl-Pod-Usage.spec
index 81ebaa7..a0bb719 100644
--- a/perl-Pod-Usage.spec
+++ b/perl-Pod-Usage.spec
@@ -1,7 +1,7 @@
 Name:   perl-Pod-Usage
 # Compete with perl.spec's epoch
 Epoch:  4
-Version:1.66
+Version:1.67
 Release:1%{?dist}
 Summary:Print a usage message from embedded POD documentation
 License:GPL+ or Artistic
@@ -80,6 +80,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 02 2015 Petr Pisar ppi...@redhat.com - 4:1.67-1
+- 1.67 bump
+
 * Mon Feb 23 2015 Petr Pisar ppi...@redhat.com - 4:1.66-1
 - 1.66 bump
 
diff --git a/sources b/sources
index ab27c9f..4662f42 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6a8f08a61c0e0c3b8e0b674eb5a6f11  Pod-Usage-1.66.tar.gz
+1570995a48e048d16c879906e4acb51e  Pod-Usage-1.67.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

Re: Failed to load vesa with undefined symbol (was: Re: hardening breaks X.org)

On 3/2/15, Moez Roy moez@gmail.com wrote:
 https://bugzilla.redhat.com/show_bug.cgi?id=1196676

 proposed as F22 alpha blocker

Thanks, I was about to do that.

-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
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 1197403] perl-Pod-Usage-1.67 is available

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



--- Comment #2 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
ppisar's perl-Pod-Usage-1.67-1.fc23 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=617054

-- 
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=vVqEamQM1ia=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-Pod-Usage/f21] 1.67 bump

commit 5a72874ae7594148b117c70f5452e763b78a4985
Author: Petr Písař ppi...@redhat.com
Date:   Mon Mar 2 10:41:05 2015 +0100

1.67 bump

 .gitignore  | 1 +
 perl-Pod-Usage.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6c6db16..2e14c38 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Pod-Usage-1.64.tar.gz
 /Pod-Usage-1.65.tar.gz
 /Pod-Usage-1.66.tar.gz
+/Pod-Usage-1.67.tar.gz
diff --git a/perl-Pod-Usage.spec b/perl-Pod-Usage.spec
index 2b347d4..77ed21a 100644
--- a/perl-Pod-Usage.spec
+++ b/perl-Pod-Usage.spec
@@ -1,7 +1,7 @@
 Name:   perl-Pod-Usage
 # Compete with perl.spec's epoch
 Epoch:  4
-Version:1.66
+Version:1.67
 Release:1%{?dist}
 Summary:Print a usage message from embedded POD documentation
 License:GPL+ or Artistic
@@ -80,6 +80,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 02 2015 Petr Pisar ppi...@redhat.com - 4:1.67-1
+- 1.67 bump
+
 * Mon Feb 23 2015 Petr Pisar ppi...@redhat.com - 4:1.66-1
 - 1.66 bump
 
diff --git a/sources b/sources
index ab27c9f..4662f42 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6a8f08a61c0e0c3b8e0b674eb5a6f11  Pod-Usage-1.66.tar.gz
+1570995a48e048d16c879906e4acb51e  Pod-Usage-1.67.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-Pod-Usage/f20] 1.67 bump

commit 5c9ebb3a931dd5d1c02cdea538b64ae321cc991b
Author: Petr Písař ppi...@redhat.com
Date:   Mon Mar 2 10:41:05 2015 +0100

1.67 bump

 .gitignore  | 1 +
 perl-Pod-Usage.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6c6db16..2e14c38 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Pod-Usage-1.64.tar.gz
 /Pod-Usage-1.65.tar.gz
 /Pod-Usage-1.66.tar.gz
+/Pod-Usage-1.67.tar.gz
diff --git a/perl-Pod-Usage.spec b/perl-Pod-Usage.spec
index a4604d9..327085e 100644
--- a/perl-Pod-Usage.spec
+++ b/perl-Pod-Usage.spec
@@ -1,7 +1,7 @@
 Name:   perl-Pod-Usage
 # Compete with perl.spec's epoch
 Epoch:  4
-Version:1.66
+Version:1.67
 Release:1%{?dist}
 Summary:Print a usage message from embedded POD documentation
 License:GPL+ or Artistic
@@ -80,6 +80,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 02 2015 Petr Pisar ppi...@redhat.com - 4:1.67-1
+- 1.67 bump
+
 * Mon Feb 23 2015 Petr Pisar ppi...@redhat.com - 4:1.66-1
 - 1.66 bump
 
diff --git a/sources b/sources
index ab27c9f..4662f42 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6a8f08a61c0e0c3b8e0b674eb5a6f11  Pod-Usage-1.66.tar.gz
+1570995a48e048d16c879906e4acb51e  Pod-Usage-1.67.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 1197403] perl-Pod-Usage-1.67 is available

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Pod-Usage-1.67-1.fc23



--- Comment #3 from Petr Pisar ppi...@redhat.com ---
Enhancement release suitable for all Fedoras.

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

GNOME 3.15.91 megaupdate

2015-03-02 Thread Kalev Lember


Hi all,

It's that time of the year again: GNOME 3.15.91 beta release is coming
out [1] this week while we're deep in the Alpha freeze in the Fedora land.

I'm running point on the 3.13.91 builds and will submit them as a single
megaupdate in Bodhi later this week.

If you are helping with builds, please use the f22-gnome side tag where
we collect all the F22 builds. Use 'fedpkg build --target f22-gnome' to
submit builds there [2].

In addition to the koji side tag, we also have the 3.15.91 spreadsheet
at 
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHcpli=1#gid=0

For the f22-gnome side tag builds, there's no need to duplicate the
builds in the spreadsheet; I'll pick up everything in the side tag
anyway. But if you have anything extra to add, other builds that aren't
in f22-gnome, feel free to add those to the spreadsheet and I'll pick
them up for the megaupdate.

The spreadsheet can also be useful to add extra bugzilla ticket numbers
that should be listed as fixed by the Bodhi update.

Thanks for the attention and I'll submit the update later this week when
all the builds are done and it passes my own testing.

--
Thanks,
Kalev

[1] https://wiki.gnome.org/ThreePointFifteen
[2] Rawhide builds are done as normal, this is only for F22
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: polymake

2015-03-02 Thread buildsys



polymake has broken dependencies in the F-22 tree:
On x86_64:
polymake-2.13-18.git20141013.fc22.x86_64 requires perl = 4:5.20.1
On i386:
polymake-2.13-18.git20141013.fc22.i686 requires perl = 4:5.20.1
On armhfp:
polymake-2.13-18.git20141013.fc22.armv7hl requires perl = 4:5.20.1
Please resolve this as soon as possible.


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

Re: rawhide report: 20150302 changes

2015-03-02 Thread Jens Petersen

 [Agda]
   ghc-Agda-2.3.2.2-5.fc22 requires libHSzlib-0.5.4.1-ghc7.6.3.so
   ghc-Agda-2.3.2.2-5.fc22 requires libHSxhtml-3000.2.1-ghc7.6.3.so
   ghc-Agda-2.3.2.2-5.fc22 requires libHSvector-0.10.0.1-ghc7.6.3.so
 [Agda-stdlib]
   ghc-agda-lib-ffi-0.0.2-5.fc22.i686 requires 
 libHSbase-4.6.0.1-ghc7.6.3.so

If you want to help get Agda out of the rawhide and branched reports
then please help with reviewing the 6 new deps packages in the bug dependency 
tree:

  https://bugzilla.redhat.com/showdependencytree.cgi?id=1164120

Thanks, Jens
-- 
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: hardening breaks X.org

2015-03-02 Thread Peter Robinson

On Mon, Mar 2, 2015 at 1:16 AM, David Airlie airl...@redhat.com wrote:
 So the rebuild to use hardened builds by default in rawhide, broke X.org.

 Thanks guys, my system is more secure, but I can't run any apps.

 Anyways enough snark from me, the problem seems to be that hardening
 makes bind now override RTLD_LAZY options, and the X server relies
 on the RTLD_LAZY on its drivers being lazy.

 So should I

 a) turn off hardened builds for all Xorg server/driver packages?

 b) or is there a way to get partial relro back?

I suggest you engage with the Change owners.
-- 
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 1195096] perl-Pod-Usage-1.66 is available

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



--- Comment #8 from Fedora Update System upda...@fedoraproject.org ---
perl-Pod-Usage-1.67-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/perl-Pod-Usage-1.67-1.fc21

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=PnVRJi0Ucla=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 1197403] perl-Pod-Usage-1.67 is available

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



--- Comment #4 from Fedora Update System upda...@fedoraproject.org ---
perl-Pod-Usage-1.67-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/perl-Pod-Usage-1.67-1.fc22

-- 
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=OmPVplTheza=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 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command

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



--- Comment #11 from Petr Šabata psab...@redhat.com ---
(In reply to Ben Boeckel from comment #10)
 Spec URL: http://mathstuf.fedorapeople.org//dropbox-api-command.spec
 SRPM URL:
 http://mathstuf.fedorapeople.org//dropbox-api-command-1.17-4.fc23.src.rpm
 
 http://koji.fedoraproject.org/koji/taskinfo?taskID=9096834
 
 So --prefix is required and %{perl_vendorlib} is the wrong path.

No, neither is true ;) The problem is you're using non-existant Module::Build
option; I missed that earlier.  Change `INSTALLDIRS' (used by
ExtUtils::MakeMaker) to `installdirs' or `--installdirs' (the latter also works
with Module::Build::Tiny).  Then you will be installing to the correct path,
you won't have to define prefix and you will be able to use the standard noarch
perl path macro.

Also, the `perl' buildtime dependency is still missing.

And I ack the rest of the issues were fixed.

-- 
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=jt0Zct9Mria=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 1197403] perl-Pod-Usage-1.67 is available

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



--- Comment #5 from Fedora Update System upda...@fedoraproject.org ---
perl-Pod-Usage-1.67-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/perl-Pod-Usage-1.67-1.fc21

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=gO7T1O4OYna=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 1192380] perl-Pod-Usage-1.65 is available

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



--- Comment #8 from Fedora Update System upda...@fedoraproject.org ---
perl-Pod-Usage-1.67-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/perl-Pod-Usage-1.67-1.fc21

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=vUe3LWfk03a=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

Re: Intend to retire kde-plasma-daisy

2015-03-02 Thread Michael J Gruber

Kevin Kofler venit, vidit, dixit 01.03.2015 06:43:
 Michael J Gruber wrote:
 this is a heads up notice that I intend to retire kde-plasma-daisy, the
 reasons being:

 - no upstream updates in almost 3 years
 
 Then retiring it is pretty much the only option you have.
 
 - FTBFS in rawhide because there's no kde-workspace{-devel}
 
 That's expected. Plasma 4 and thus kde-workspace 4 is dead. We ship Plasma 5 
 in Fedora 22 and newer.
 
 - I don't use it myself.

 - Repackaging for Plasma 5 would probably require a new package
 plasma-daisy (which should not pass review, given upstream is dead), or
 a kde5-plasma-daisy subpackage (but then the spec would still FTBFS), or
 who knows what. I certainly don't know and don't see any specs to follow.
 
 It is not merely a matter of repackaging, the whole code would have to be 
 ported, which includes rewriting the entire user interface in QML (QML 2, to 
 be precise). Plasmoids are what requires most work to port to the KDE 
 Frameworks 5 world.
 
 If anyone would like to take over I'm happy to pass the package on
 rather than retire it.
 
 Said volunteer would also have to take up upstream maintainership and do the 
 porting described above. If they aren't already a KDE developer, chances of 
 success are grim.
 
 Retirement is planned for rawhide and, possibly also the F22 branch,
 depending on what will remain in there kde-wise.
 
 Fedora 22 will also ship with (only) Plasma 5, so please retire the obsolete 
 plasmoid also in Fedora 22.
 
 Kevin Kofler
 

Good to know, thanks!

Retired in f22 and rawhide now. Two remarks about the process:

- 'fedpkg' always makes me feel uneasy. I don't know what's going on
under the hood, and it messes up the git DAG. Those two separate
retirement commits should have been one plus a merge. I'd rather use
pure git here (but fedpkg also does some message bus thing).

- New badge, yay :)

Michael
-- 
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: Failed to load vesa with undefined symbol (was: Re: hardening breaks X.org)

2015-03-02 Thread Moez Roy

On Mon, Mar 2, 2015 at 1:30 AM, Christopher Meng cicku...@gmail.com wrote:
 Ok, this time is vesa's problem:

 http://lists.x.org/archives/xorg/2015-February/057183.html

 But hardening breaks it indeed.

 --

 Yours sincerely,
 Christopher Meng

 http://cicku.me

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

proposed as F22 alpha blocker
-- 
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: Subject: Self Introduction: Sandro Bonazzola

2015-03-02 Thread Paulo César Pereira de Andrade

2015-03-02 3:34 GMT-03:00 Sandro Bonazzola sbona...@redhat.com:
 Il 27/02/2015 18:26, Paulo César Pereira de Andrade ha scritto:
 2015-02-27 13:02 GMT-03:00 Sandro Bonazzola sbona...@redhat.com:
 Hi,

   Hello and Welcome Sandro!

 following [1] I'm writing for introducing myself.
 My name is Sandro Bonazzola and I'm a Senior Software Engineer at Red Hat.
 I'm leading RHEV integration team and I'm oVirt[2] project release manager.
 I'm also representing oVirt project in CentOS Virt SIG[3].
 In the past I contributed to several open source projects[4] and I was a 
 former Gentoo Linux developer[5] several years ago.
 My FAS account is sbonazzo[6].
 I'm interested in packaging oVirt and its missing dependencies within 
 Fedora.

   I am a Fedora packager sponsor, and have particular interest in learning
 more about virtualization related projects, so, I can help and sponsor you.
 Do you already have a review request?

 Yes I have one:
 Bug 1197132 - Review Request: reflections - a Java runtime metadata analysis
 But now I see it's a duplicate of
 Bug 834574 - Review Request: reflections - Java run time meta data analysis

 So no requests open for now. Other request will follow, for packaging oVirt 
 under Fedora, a long list of deps is sitll missing.
 Thanks for your welcome and your offer of sponsorship!

  We can continue later on private mail, but at first I would suggest
comparing your package with the other, still under review.
  You can also test most common problems running fedora
review, for example, even before making a review request, you
can run:

$ fedora-review -n NAME -r

where NAME is output of rpm -qp --qf %{NAME} $SRPM, -r is to
tell it to use the spec from the srpm. You may also add something
like -m fedora-rawhide-x86_64 to the fedora-review command line,
if your /etc/mock/default.cfg is not already pointing to a rawhide
config.

 [1] 
 http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself
 [2] http://www.ovirt.org
 [3] http://wiki.centos.org/SpecialInterestGroup/Virtualization
 [4] https://www.openhub.net/accounts/sanchan
 [5] 
 http://archives.gentoo.org/gentoo-dev/message/bb8da84f01bdba83c88ddf5d300eeafc
 [6] https://fedoraproject.org/wiki/User:Sbonazzo

Thanks,
Paulo
-- 
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: Is systemd within a Docker container still recommended?

2015-03-02 Thread Lennart Poettering

On Mon, 02.03.15 10:03, Mauricio Tavares (raubvo...@gmail.com) wrote:

 On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering mzerq...@0pointer.de 
 wrote:
  We are continuing to work on making running systemd within a container
  better.
  I am trying to get a /run on tmpfs patch to be acceptable upstream.  But
  we still
  have a problem with systemd requiring /sys/fs/cgroup to be mounted
  inside the container
  to run.  Which allows for an information leak.
 
  You'd have to get the kernel changed for that information leak to be
  fixed.
 
  That said, containers on Linux are not really about security, the
  whole thing has more holes than a swiss cheese. Maybe one day the
  security holes can be fixed, but as of now, it's simply not
  secure. And this information leak is certainly the least of your
  problems...
 
   What would then be the recommended solution if containers are insecure?

Well, use containers, but don't have any illusions about them adding
much security. You get the usual security guarantess that Unix gives
you. not more and not less. But the containers are really not isolated
from the host as much as people think. For example, if you use the same
user ID in two containers (and that's what Docker more often than not
ends up doing), they share the same struct user in the kernel, and
hence things like RLIMIT_NPROC (which are per-user) will affect not
only the originating container, but the host and all other containers
on the host too. (This specific issue is easily triggerable btw: just
run avahi inside a container and on the host, and you'll have
fun. Avahi sets RLIMIT_NPROC to 2, to prohibit forking should it be
exploited, but since it requires two processes, and RLIMIT_NPROC is
shared between all containers and the host you can hence runonly a
single avahi per machine...) 

And there are many many other issues like this... (the per-user
keyring is shared for example, yuck!)


Lennart

-- 
Lennart Poettering, Red Hat
-- 
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 1197692] perl-Gnome2-GConf-1.044-21.fc23 FTBFS: blib/arch/auto/Gnome2/GConf/GConf.so: undefined symbol: gconf_engine_key_is_writable

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Depends On||1197773




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1197773
[Bug 1197773] /usr/include/gconf/2/gconf/gconf.h declares
gconf_engine_key_is_writable, but /usr/lib64/libgconf-2.so.4.1.5 does not
export it
-- 
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=ijaJOwrW6wa=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

Re: Is systemd within a Docker container still recommended?

2015-03-02 Thread Stephen John Smoogen

On 2 March 2015 at 08:03, Mauricio Tavares raubvo...@gmail.com wrote:

 .
 
  That said, containers on Linux are not really about security, the
  whole thing has more holes than a swiss cheese. Maybe one day the
  security holes can be fixed, but as of now, it's simply not
  secure. And this information leak is certainly the least of your
  problems...
 
   What would then be the recommended solution if containers are
 insecure?



insecure/secure are the wrong words as they treat a spectrum as binary. All
computers are insecure by various definitions (even the ones inside of 10
feet of concrete at the bottom of the ocean). The issue is what risks and
problems are you willing to trade for certain benefits. If you ignore that
there are risks and problems you end up with a world of hurt later, but if
you don't accept any risks/problems you can never have any solution. [fully
virtualized has its own problems and ways to be 'escape' that have to be
mitigated and watched. the base computer has so many external controllers
which might be risks that it is basically virtualized, etc.]



 Lennart
 
  --
  Lennart Poettering, Red Hat
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
Stephen J Smoogen.
-- 
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-Hardware-Vhdl-Parser] Fix a FTBFS failure with recent File::Find

commit a12c6e5022159c4b008aace3c66f51f8a6346b92
Author: Petr Šabata con...@redhat.com
Date:   Mon Mar 2 16:48:03 2015 +0100

Fix a FTBFS failure with recent File::Find

- Fix broken grammar for entity_declaritive_item
- Modernize the spec
- Enable tests

 Hardware-Vhdl-Parser-0.12-unreachable.patch | 13 +++
 perl-Hardware-Vhdl-Parser.spec  | 54 ++---
 2 files changed, 40 insertions(+), 27 deletions(-)
---
diff --git a/Hardware-Vhdl-Parser-0.12-unreachable.patch 
b/Hardware-Vhdl-Parser-0.12-unreachable.patch
new file mode 100644
index 000..6b4375e
--- /dev/null
+++ b/Hardware-Vhdl-Parser-0.12-unreachable.patch
@@ -0,0 +1,13 @@
+diff --git a/Parser.pm b/Parser.pm
+index ddcc82f..90cdb1f 100644
+--- a/Parser.pm
 b/Parser.pm
+@@ -461,7 +461,7 @@ passive_process_statement :
+   process_statement
+ 
+ entity_declaritive_item : 
+-  | signal_declaration 
++signal_declaration
+   | constant_declaration 
+   | type_declaration 
+   | subtype_declaration 
diff --git a/perl-Hardware-Vhdl-Parser.spec b/perl-Hardware-Vhdl-Parser.spec
index f62c477..f0a9821 100644
--- a/perl-Hardware-Vhdl-Parser.spec
+++ b/perl-Hardware-Vhdl-Parser.spec
@@ -1,22 +1,22 @@
 Name:   perl-Hardware-Vhdl-Parser
 Version:0.12
-Release:18%{?dist}
+Release:19%{?dist}
 Summary:Complete grammar for parsing VHDL code using perl
-
 License:GPL+ or Artistic
-Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Hardware-Vhdl-Parser/
 Source0:
http://www.cpan.org/authors/id/G/GS/GSLONDON/Hardware-Vhdl-Parser-%{version}.tar.gz
-
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+# rt#102452
+Patch0: Hardware-Vhdl-Parser-0.12-unreachable.patch
 BuildArch:  noarch
-
-BuildRequires:  perl(ExtUtils::MakeMaker)
+# Build
+BuildRequires:  perl
+BuildRequires:  perl(ExtUtils::MakeMaker) = 6.76
+# Runtime
 BuildRequires:  perl(Parse::RecDescent)
-
-Requires:   perl(Parse::RecDescent)
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
-
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+# Tests only
+Requires:   perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo 
$version))
 
 %description
 This module defines the complete grammar needed to parse any VHDL code. By
@@ -25,36 +25,36 @@ which run through VHDL code and perform specific functions.
 
 %prep
 %setup -q -n Hardware-Vhdl-Parser-%{version}
-
-find . -type f | xargs %{__perl} -pi -e 's|#! /bin/perl|#! /usr/bin/perl|'
+%patch0 -p1
+find . -type f | xargs perl -pi -e 's|#!\s*/bin/perl|#!%{__perl}|'
+# rt#102450
+rm -rf Hardware
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
+make pure_install DESTDIR=%{buildroot}
+rm -f %{buildroot}%{perl_vendorlib}/Hardware/Vhdl/*.pl
+%{_fixperms} %{buildroot}/*
 
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{__rm} -f $RPM_BUILD_ROOT%{perl_vendorlib}//Hardware/Vhdl/*.pl
-
-%{_fixperms} $RPM_BUILD_ROOT/*
-
-%clean
-rm -rf $RPM_BUILD_ROOT
+%check
+make test
 
 %files
-%defattr(-,root,root,-)
 %doc Changes readme.txt test1.vhd
 %doc parser.pl hierarchy.pl
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 02 2015 Petr Šabata con...@redhat.com - 0.12-19
+- Fix a FTBFS failure with recent File::Find
+- Fix broken grammar for entity_declaritive_item
+- Modernize the spec
+- Enable tests
+
 * Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.12-18
 - Perl 5.20 rebuild
 
--
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

Re: systemd-219 issues with 22 and Rawhide composes

2015-03-02 Thread Brian C. Lane

On Fri, Feb 27, 2015 at 04:21:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote:
  On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
  mzerq...@0pointer.de wrote:
   On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote:
  
  [ notes snipped, ]
  
   You know, that systemd creates a symlink if the file is missing is not
   going to change behaviour of anything, since it will only do something
   if the file is *missing*.
  
  Congratulations. We now have inconsistent behavior if anyone, *ever*,
  edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp
  reproduce it from a known good repository, and with a symlink in place
  we're storing absolutely critical system information in a non /etc
  location, meaning that non-modified backup systems won't get a copy
  with valid content.
  
  Just. great.
  
  Look, deciding to ignore the File System Hierarchy for installing
  config files and creating new locations to store system configuration
 Actually it might be considered that we are *starting* to follow FHS.
 In many (most?) setups /etc/resolv.conf configuration is very dynamic:
 the set of resolvers depends on dhcp leases, VPNs, network interfaces
 coming and going. Storing this information in /etc/ is wrong. It's good
 that this ephmeral content is not backed up. If the machine reboots, you
 do not want to restore it, you want to recreate it from scratch.
 
 If someone has a static setup and a static resolv.conf is fine for them,
 there's no problem: just create a normal file.

The underlying problem here is that it isn't just created when it is
missing. It is created *before* other tools have a chance to create it.
As I explained in 1197204 the boot.iso is created without a
/etc/resolv.conf, this means that NM should create it with whatever
content it needs. Except that systemd-tmpfiles comes along first,
assumes it can create it and then breaks NM.

Upstream has declined to fix this, so we're going to need the patch
that's been applied to f21 and f22 carried forward until that changes.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

libgps (gpsd) soname bump

2015-03-02 Thread Miroslav Lichvar

The gpsd package in rawhide will be updated to 3.13, it's in git now
and will be built later this week or the next week if there are no
objections.

It bumps the libgps soname and there are also small API changes,
probably the most important change is that some arrays (used, PRN,
elevation, azimuth, ss) in gps_data_t are now split into the skyview
array of satellite_t inside gps_data_t.

Please let me know if you have any troubles with updating clients.

The following packages seem to depend on libgps:

gpsdrive-0:2.11-26.fc22
marble-widget-1:14.12.2-1.fc23
plasma-workspace-0:5.2.1-2.fc23
qlandkartegt-0:1.8.1-2.fc23
qtgpsc-0:0.3.1-10.fc22
vfrnav-0:20141211-1.fc22
vifir-0:0.9-27.fc22
viking-0:1.5.1-3.fc22
xtide-0:2.14-2.fc22

A scratch build of gpsd is here: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=9120407

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

LLVM OCaml bindings disabled

2015-03-02 Thread Richard W.M. Jones


LLVM, the C compiler, has OCaml bindings to its internals[1].

In the latest version they are generated using an OCaml library called
'ctypes'[2] (instead of however they were generated before -- maybe
written by hand or something).

Since we don't yet package ocaml-ctypes for Fedora, we've decided to
disable the LLVM OCaml bindings.

If this is something you care about this, please add ocaml-ctypes to
Fedora and then the bindings can be reenabled in LLVM.

Rich.

[1] http://llvm.org/docs/tutorial/OCamlLangImpl1.html

http://nopaniers.calepin.co/getting-started-with-ocaml-bindings-for-llvm.html
[2] https://github.com/ocamllabs/ocaml-ctypes

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

File Text-CSV_XS-1.16.tgz uploaded to lookaside cache by pghmcfc

A file has been added to the lookaside cache for perl-Text-CSV_XS:

62fadae9a88cc9fc921280a5bf1ff161  Text-CSV_XS-1.16.tgz
--
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 1150528] perl-POE-1.365 is available

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



--- Comment #2 from Fedora Update System upda...@fedoraproject.org ---
perl-POE-1.365-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/perl-POE-1.365-1.fc21

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=44iqSC75oqa=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-Text-CSV_XS] Update to 1.16

commit 02f856b8cd1be5b73013bb1f2349588cc20d3756
Author: Paul Howarth p...@city-fan.org
Date:   Mon Mar 2 17:32:17 2015 +

Update to 1.16

- New upstream release 1.16
  - filter made more useful (access to other fields)

 perl-Text-CSV_XS.spec | 6 +-
 sources   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 047e9b3..62e138a 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -1,5 +1,5 @@
 Name:   perl-Text-CSV_XS
-Version:1.15
+Version:1.16
 Release:1%{?dist}
 Summary:Comma-separated values manipulation routines
 Group:  Development/Libraries
@@ -69,6 +69,10 @@ make %{?_smp_mflags} test
 %{_mandir}/man3/Text::CSV_XS.3*
 
 %changelog
+* Mon Mar  2 2015 Paul Howarth p...@city-fan.org - 1.16-1
+- Update to 1.16:
+  - filter made more useful (access to other fields)
+
 * Wed Feb 11 2015 Paul Howarth p...@city-fan.org - 1.15-1
 - Update to 1.15:
   - Remove perl recommendation from META as it breaks cpan clients
diff --git a/sources b/sources
index 2d160f1..eba68ce 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-eb677157de7ddcd00563c9c4c60528b8  Text-CSV_XS-1.15.tgz
+62fadae9a88cc9fc921280a5bf1ff161  Text-CSV_XS-1.16.tgz
--
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

Re: systemd-219 issues with 22 and Rawhide composes

2015-03-02 Thread Dan Williams

On Mon, 2015-03-02 at 08:42 -0800, Brian C. Lane wrote:
 On Fri, Feb 27, 2015 at 04:21:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
  On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote:
   On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
   mzerq...@0pointer.de wrote:
On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote:
   
   [ notes snipped, ]
   
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*.
   
   Congratulations. We now have inconsistent behavior if anyone, *ever*,
   edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp
   reproduce it from a known good repository, and with a symlink in place
   we're storing absolutely critical system information in a non /etc
   location, meaning that non-modified backup systems won't get a copy
   with valid content.
   
   Just. great.
   
   Look, deciding to ignore the File System Hierarchy for installing
   config files and creating new locations to store system configuration
  Actually it might be considered that we are *starting* to follow FHS.
  In many (most?) setups /etc/resolv.conf configuration is very dynamic:
  the set of resolvers depends on dhcp leases, VPNs, network interfaces
  coming and going. Storing this information in /etc/ is wrong. It's good
  that this ephmeral content is not backed up. If the machine reboots, you
  do not want to restore it, you want to recreate it from scratch.
  
  If someone has a static setup and a static resolv.conf is fine for them,
  there's no problem: just create a normal file.
 
 The underlying problem here is that it isn't just created when it is
 missing. It is created *before* other tools have a chance to create it.
 As I explained in 1197204 the boot.iso is created without a
 /etc/resolv.conf, this means that NM should create it with whatever
 content it needs. Except that systemd-tmpfiles comes along first,
 assumes it can create it and then breaks NM.

With NM = 1.0, it will create a tempfile in /etc and then rename that
over top of the existing /etc/resolv.conf, though it does try to follow
a link (with realpath(2)) and replace that file atomically (with
rename(2)).  If that's being broken by systemd we should probably handle
this case better in NM too, along with whatever systemd changes need to
happen.

With NM  1.0, NM will stop touching resolv.conf at all if it's a
symlink, because that file is owned by some other process.  NM will
still write out it's own resolv.conf to /var/run.  If resolv.conf is a
file, and NM is allowed to manage DNS through its config, then NM will
make resolv.conf a symlink to its file in /var/run, much like I
understand systemd does.

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: systemd-219 issues with 22 and Rawhide composes

On Mon, 2 Mar 2015 08:42:25 -0800
Brian C. Lane b...@redhat.com wrote:

 The underlying problem here is that it isn't just created when it is
 missing. It is created *before* other tools have a chance to create
 it. As I explained in 1197204 the boot.iso is created without a
 /etc/resolv.conf, this means that NM should create it with whatever
 content it needs. Except that systemd-tmpfiles comes along first,
 assumes it can create it and then breaks NM.

Perhaps the tmpfiles entry for /etc/resolv.conf should be moved to a
systemd-networkd tmpfile entry? Then, if you do not install that it's
assumed NM or whatever will create the entry, if you do, it can then
manage that file that gets created.

 Upstream has declined to fix this, so we're going to need the patch
 that's been applied to f21 and f22 carried forward until that changes.

Is there an upstream bug or discussion we can look at? 

Yeah, I was hoping to get a nice rawhide Xfce 4.12 image to test with
today, but of course it hit this bug and didn't get created. ;( 

kevin
 



pgp2J6kiCg3AY.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Yum-utils and DNF

2015-03-02 Thread Michael Catanzaro

On Mon, Mar 2, 2015 at 7:55 AM, Michael Mraka 
michael.mr...@redhat.com wrote:

Hi developers,

I'm trying to finish port of yum-utils scritps to DNF


Hi, thanks for working on this.

One request: when you get to debuginfo-install, can you please change 
it to not disable the debuginfo repository when it's done? Currently 
PackageKit leaves old debuginfo packages unchanged when it updates the 
packages they correspond to, which is annoying, and ABRT does not seem  
to do so either, which is not fun for anyone. That's by design since 
debuginfo-install leaves the debuginfo repository disabled, and of 
course PackageKit isn't going to look for updates from a repo that's 
disabled.


An alternative would be to enable this repository by default. I guess 
it's currently disabled by default to make yum go faster, but that 
mostly makes sense for those who don't have any debuginfo installed.


Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Anyone wants Pound?

2015-03-02 Thread Pete Zaitcev

Hi, guys:

I stopped using Pound for myself (replaced with stunnel + HAproxy),
so I was looking at shedding its maintainership. Anyone wants to
take it over or should I instigate EOL?

Cheers,
-- Pete
-- 
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-Text-CSV_XS/f22] Update to 1.16

Summary of changes:

  02f856b... Update to 1.16 (*)

(*) 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

[perl-Text-CSV_XS] Created tag perl-Text-CSV_XS-1.16-1.fc22