date:20110802



perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon as possible.


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

Broken dependencies: perl-NOCpulse-Gritch



perl-NOCpulse-Gritch has broken dependencies in the rawhide tree:
On x86_64:
perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
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

rawhide report: 20110802 changes

2011-08-02 Thread Rawhide Report

Compose started at Tue Aug  2 08:15:21 UTC 2011

Broken deps for x86_64
--
LuxRender-0.7.1-6.fc16.x86_64 requires 
libboost_thread-mt.so.1.46.1()(64bit)
LuxRender-0.7.1-6.fc16.x86_64 requires 
libboost_system-mt.so.1.46.1()(64bit)
LuxRender-0.7.1-6.fc16.x86_64 requires 
libboost_serialization-mt.so.1.46.1()(64bit)
LuxRender-0.7.1-6.fc16.x86_64 requires 
libboost_regex-mt.so.1.46.1()(64bit)
LuxRender-0.7.1-6.fc16.x86_64 requires 
libboost_program_options-mt.so.1.46.1()(64bit)
LuxRender-0.7.1-6.fc16.x86_64 requires 
libboost_iostreams-mt.so.1.46.1()(64bit)
LuxRender-0.7.1-6.fc16.x86_64 requires 
libboost_filesystem-mt.so.1.46.1()(64bit)
LuxRender-core-0.7.1-6.fc16.x86_64 requires 
libboost_thread-mt.so.1.46.1()(64bit)
LuxRender-core-0.7.1-6.fc16.x86_64 requires 
libboost_system-mt.so.1.46.1()(64bit)
LuxRender-core-0.7.1-6.fc16.x86_64 requires 
libboost_serialization-mt.so.1.46.1()(64bit)
LuxRender-core-0.7.1-6.fc16.x86_64 requires 
libboost_regex-mt.so.1.46.1()(64bit)
LuxRender-core-0.7.1-6.fc16.x86_64 requires 
libboost_program_options-mt.so.1.46.1()(64bit)
LuxRender-core-0.7.1-6.fc16.x86_64 requires 
libboost_iostreams-mt.so.1.46.1()(64bit)
LuxRender-core-0.7.1-6.fc16.x86_64 requires 
libboost_filesystem-mt.so.1.46.1()(64bit)
QuantLib-test-1.1-1.fc16.x86_64 requires 
libboost_unit_test_framework.so.1.46.1()(64bit)
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libcryptui.so.0()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit)
1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26
1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit)
assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit)
awstats-7.0-3.fc16.noarch requires perl(Switch)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
bluetile-0.5.3-11.fc16.x86_64 requires ghc(xmonad-contrib-0.9.2) = 
0:d669bbdb9b9f7adb145fcb61825dec73
1:cheese-3.0.2-1.fc16.x86_64 requires libcogl.so.1()(64bit)
1:cheese-libs-3.0.2-1.fc16.i686 requires libcogl.so.1
1:cheese-libs-3.0.2-1.fc16.x86_64 requires libcogl.so.1()(64bit)
claws-mail-plugins-geolocation-3.7.9-7.fc16.x86_64 requires 
libcogl.so.1()(64bit)
cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit)
clutter-gtk-1.0.2-1.fc16.i686 requires libcogl.so.1
clutter-gtk-1.0.2-1.fc16.x86_64 requires libcogl.so.1()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools
coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
collectl-3.5.1-1.fc16.noarch requires perl(Switch)
comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py
comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet
dh-make-0.55-3.fc15.noarch requires debhelper
ease-0.4-5.fc16.i686 requires libcogl.so.1
ease-0.4-5.fc16.x86_64 requires libcogl.so.1()(64bit)
easystroke-0.5.4-1.fc16.x86_64 requires 
libboost_serialization-mt.so.1.46.1()(64bit)
emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave
empathy-3.1.3-4.fc16.x86_64 requires libcogl.so.1()(64bit)
eog-plugins-3.1.2-1.fc16.x86_64 requires libcogl.so.1()(64bit)
evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-provider-1.2.so.27

Strange RPM versioning problem in qemu in Rawhide

2011-08-02 Thread Richard W.M. Jones

Below are two packages.  The first one is installed, the second one is
built for Koji.  Yum refuses to upgrade the installed package to the
second one, saying:

Examining qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: 
2:qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64
qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: does not update installed 
package.

But I don't understand why, since it seems clear that the second
package has a higher release than the first package.

In any case, this appears to be a bug in the versioning of these
packages, since the 0.2 part of the release string should have been
changed to 0.3 when it was built.

Rich.

$ rpm -qi qemu
Name: qemu
Epoch   : 2
Version : 0.15.0
Release : 0.2.20110718525e3df.fc16
Architecture: x86_64
Install Date: Tue 19 Jul 2011 19:34:05 BST
Group   : Development/Tools
Size: 0
License : GPLv2+ and LGPLv2+ and BSD
Signature   : (none)
Source RPM  : qemu-0.15.0-0.2.20110718525e3df.fc16.src.rpm
Build Date  : Tue 19 Jul 2011 10:55:49 BST
Build Host  : x86-12.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager: Fedora Project
Vendor  : Fedora Project
URL : http://www.qemu.org/
Summary : QEMU is a FAST! processor emulator
Description :
QEMU is a generic and open source processor emulator which achieves a good
emulation speed by using dynamic translation. QEMU has two operating modes:

 * Full system emulation. In this mode, QEMU emulates a full system (for
   example a PC), including a processor and various peripherials. It can be
   used to launch different Operating Systems without rebooting the PC or
   to debug system code.
 * User mode emulation. In this mode, QEMU can launch Linux processes compiled
   for one CPU on another CPU.

As QEMU requires no host kernel patches to run, it is safe and easy to use.

$ rpm -qip qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm 
Name: qemu
Epoch   : 2
Version : 0.15.0
Release : 0.2.2011072859fadcc.fc17
Architecture: x86_64
Install Date: (not installed)
Group   : Development/Tools
Size: 0
License : GPLv2+ and LGPLv2+ and BSD
Signature   : (none)
Source RPM  : qemu-0.15.0-0.2.2011072859fadcc.fc17.src.rpm
Build Date  : Thu 28 Jul 2011 18:24:13 BST
Build Host  : x86-07.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager: Fedora Project
Vendor  : Fedora Project
URL : http://www.qemu.org/
Summary : QEMU is a FAST! processor emulator
Description :
QEMU is a generic and open source processor emulator which achieves a good
emulation speed by using dynamic translation. QEMU has two operating modes:

 * Full system emulation. In this mode, QEMU emulates a full system (for
   example a PC), including a processor and various peripherials. It can be
   used to launch different Operating Systems without rebooting the PC or
   to debug system code.
 * User mode emulation. In this mode, QEMU can launch Linux processes compiled
   for one CPU on another CPU.

As QEMU requires no host kernel patches to run, it is safe and easy to use.


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trouble with building packages in F16: The moc has changed too much

2011-08-02 Thread Nils Philippsen

On Mon, 2011-08-01 at 19:08 +0100, Richard Hughes wrote:
 On 1 August 2011 15:24, Jaroslav Reznik jrez...@redhat.com wrote:
  It's not very good idea to ship pre-generated moc files, better to
  autogenerate them during the build-time. PackageKit is using automake,
  so it's a little bit more difficult but possible, check for example [1].
 
 Right, I *think* I'm doing the right thing in
 https://gitorious.org/packagekit/packagekit/blobs/master/lib/packagekit-qt/src/Makefile.am
 with the only difference being that I'm shipping the moc files in the
 tarball. Can I just nuke the moc files in the fedora spec file, and
 they'll get regenerated at build time? Or should I remove MOCFILES
 from EXTRA_DIST?

I'm no authority on qt/kde, but the original issue seems to indicate
that moc files should be generated during compilation time (i.e.
shouldn't be shipped in the tarball). Other than increasing compilation
time, this shouldn't be an issue as moc is part of qt-devel.

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unresponsive maintainer: gresistor

2011-08-02 Thread Jon Ciesla

Richard Shaw wrote:
 I have submitted a bug report[1] for a bundled library I found in the
 gresistor package while working on a review request of my own.

 Both my package, and the bundled library, have been accepted which now
 means there are two packages that provide the same file.

 I have not gotten a response from the maintainer.

 Does anyone know how to get a hold of him?

 Chitlesh GOORAH chitl...@gmail.com

 Thanks,
 Richard

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=710199
   
Email I have is chitlesh.goo...@gmail.com, don't know if that's right.  CCd.

http://www.facebook.com/chitlesh
http://chitlesh.wordpress.com
http://twitter.com/chitlesh http://chitlesh.fedorapeople.org
http://chitlesh.fedorapeople.org

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

2011-08-02 Thread Justin M. Forbes

On Tue, 2011-08-02 at 13:37 +0100, Richard W.M. Jones wrote:
 Below are two packages.  The first one is installed, the second one is
 built for Koji.  Yum refuses to upgrade the installed package to the
 second one, saying:
 
 Examining qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: 
 2:qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64
 qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: does not update installed 
 package.
 
 But I don't understand why, since it seems clear that the second
 package has a higher release than the first package.
 
 In any case, this appears to be a bug in the versioning of these
 packages, since the 0.2 part of the release string should have been
 changed to 0.3 when it was built.
 
Indeed it should, though like you, I am not sure why.  with the date
change, the release is higher and should be a clear update.  When I
tried to submit the update to bodhi, I got the same thing. Though I am
doing another update today.

Justin

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-DBD-XBase] Rebase to 1.03.

2011-08-02 Thread Jan Pazdziora

commit 023bcc6630ac4480b121cf90da53fe6c0fb415d8
Author: Jan Pazdziora jpazdzi...@redhat.com
Date:   Tue Aug 2 14:50:56 2011 +0200

Rebase to 1.03.

 .gitignore   |2 +-
 DBD-XBase-0.241-dbfdump-rename.patch |  593 --
 perl-DBD-XBase.spec  |   19 +-
 sources  |2 +-
 4 files changed, 15 insertions(+), 601 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e0ae989..87d6a19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-DBD-XBase-0.241.tar.gz
+DBD-XBase-1.03.tar.gz
diff --git a/perl-DBD-XBase.spec b/perl-DBD-XBase.spec
index fe3aa2a..2805516 100644
--- a/perl-DBD-XBase.spec
+++ b/perl-DBD-XBase.spec
@@ -1,14 +1,13 @@
 Name:   perl-DBD-XBase
-Version:0.241
-Release:14%{?dist}
+Version:1.03
+Release:1%{?dist}
 Summary:Perl module for reading and writing the dbf files
 
 Group:  Development/Libraries
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/DBD-XBase/
-Source0:
http://www.cpan.org/authors/id/J/JA/JANPAZ/DBD-XBase-%{version}.tar.gz
+URL:http://www.adelton.com/perl/DBD-XBase/
+Source0:
http://www.adelton.com/perl/DBD-XBase/DBD-XBase-%{version}.tar.gz
 Patch0: DBD-XBase-0.241-indexdump.PL.patch
-Patch1: DBD-XBase-0.241-dbfdump-rename.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildArch:  noarch
@@ -28,9 +27,14 @@ DBI modules and their man pages.
 %prep
 %setup -q -n DBD-XBase-%{version}
 %patch0 -p1
-%patch1 -p1
 chmod a-x eg/*table
 
+# We want to distribute dbfdump.pl, not dbfdump
+find . -type f | xargs %{__perl} -i.theorig -pe 
's/(?!\$)\bdbfdump/dbfdump.pl/g'
+find . -type f -name '*.theorig' | %{__perl} -pe 's/\.theorig$//' | while read 
i ; do touch -r $i.theorig $i ; done
+find . -type f -name '*.theorig' -exec rm -f {} ';'
+mv bin/dbfdump.PL bin/dbfdump.pl.PL
+
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
@@ -64,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Tue Aug  2 2011 Jan Pazdziora jpazdzi...@redhat.com - 1.03-1
+- Rebase to 1.03.
+
 * Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.241-14
 - Perl mass rebuild
 
diff --git a/sources b/sources
index d94aedd..7c159e1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ed36f8722f09406d35c8af801fa78c3b  DBD-XBase-0.241.tar.gz
+cbfae03a28dcae0aa0d00bec60ca710d  DBD-XBase-1.03.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: PokerTH orphaned

2011-08-02 Thread Jason L Tibbitts III

 HdG == Hans de Goede hdego...@redhat.com writes:

HdG Hi,HHdG Tomas has chosen to fix this problem by simply disabling the
HdG openssl compat part of gnutls (which as the above bug shows is
HdG broken by design) given that only 3 apps use this, this seems like
HdG a sane choice to me.

Except, of course, it appears that someone completely forgot to contact
the people who maintain those applications.  That's not how it's
supposed to work.  Given that it's only three applications, that should
have been pretty easy.  The point is that it's not OK to think we're
only screwing three maintainers; it's OK to do this without actually
talking to them.

My upstream (zoneminder) explicitly removed openssl support because of
the licensing issues.  It can still be made to work, but of course that
violates their license and I can't imagine that at this point they're
going to just change their license to allow us to ship the software.  Of
course I'll try, but in the meantime I certainly can't actually build
the software in Fedora.

 - J
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

2011-08-02 Thread Nils Philippsen

On Tue, 2011-08-02 at 13:37 +0100, Richard W.M. Jones wrote:
 Below are two packages.  The first one is installed, the second one is
 built for Koji.  Yum refuses to upgrade the installed package to the
 second one, saying:
 
 Examining qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: 
 2:qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64
 qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: does not update installed 
 package.
 
 But I don't understand why, since it seems clear that the second
 package has a higher release than the first package.

The version comparison method of RPM is a bit quirky and non-obvious: It
separates elements at dots (obvious) but also at changes between digits
and other characters (non-obvious). Let's look at only the releases of
the two packages:

0.2.20110718525e3df.fc16
0.2.2011072859fadcc.fc17

Split up into the elements that RPM compares, these are:

0, 2, 20110718525, e, 3,  df, fc, 16
0, 2, 2011072859,  fadcc, fc, 17
  
The third elements cause this evr-comparison to have a result which you
don't expect. Bump the second element 2 to 3 and you should be
fine :-).

BTW, rpmdev-vercmp lets you compare arbitrary [e:]v[-r] combinations on
the command line without having  to have the affected packages handy.

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

2011-08-02 Thread Michael Schwendt

On Tue, 02 Aug 2011 07:49:53 -0500, JMF (Justin) wrote:

 On Tue, 2011-08-02 at 13:37 +0100, Richard W.M. Jones wrote:
  Below are two packages.  The first one is installed, the second one is
  built for Koji.  Yum refuses to upgrade the installed package to the
  second one, saying:
  
  Examining qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: 
  2:qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64
  qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: does not update installed 
  package.
  
  But I don't understand why, since it seems clear that the second
  package has a higher release than the first package.
  
  In any case, this appears to be a bug in the versioning of these
  packages, since the 0.2 part of the release string should have been
  changed to 0.3 when it was built.
  
 Indeed it should, though like you, I am not sure why.  with the date
 change, the release is higher and should be a clear update.  When I
 tried to submit the update to bodhi, I got the same thing. Though I am
 doing another update today.

RPM version comparison is not hexadecimal. You need to split the value
into numerical and non-numerical parts:

// full value
# rpmdev-vercmp 20110718525e3df 2011072859fadcc
20110718525e3df  2011072859fadcc

  that's the one you wondered about


// just the numerical/decimal prefix, longer one wins
# rpmdev-vercmp 2011072859 20110718525
2011072859  20110718525

// just the decimal prefix, longer one truncated, hence it loses already
# rpmdev-vercmp 2011072859 2011071852
2011072859  2011071852
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 726022] perl-POE-Component-IRC-6.69 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Petr Sabata psab...@redhat.com changed:

   What|Removed |Added

 Depends on||727559

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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: PokerTH orphaned

2011-08-02 Thread Tomas Mraz

On Tue, 2011-08-02 at 07:51 -0500, Jason L Tibbitts III wrote: 
  HdG == Hans de Goede hdego...@redhat.com writes:
 
 HdG Hi,HHdG Tomas has chosen to fix this problem by simply disabling the
 HdG openssl compat part of gnutls (which as the above bug shows is
 HdG broken by design) given that only 3 apps use this, this seems like
 HdG a sane choice to me.
 
 Except, of course, it appears that someone completely forgot to contact
 the people who maintain those applications.  That's not how it's
 supposed to work.  Given that it's only three applications, that should
 have been pretty easy.  The point is that it's not OK to think we're
 only screwing three maintainers; it's OK to do this without actually
 talking to them.
 
 My upstream (zoneminder) explicitly removed openssl support because of
 the licensing issues.  It can still be made to work, but of course that
 violates their license and I can't imagine that at this point they're
 going to just change their license to allow us to ship the software.  Of
 course I'll try, but in the meantime I certainly can't actually build
 the software in Fedora.

The problem is I tried repoquery against the rawhide repository before
the disabling and either the repository was somehow broken or I made
some mistake because the repoquery returned empty results. That's why I
thought that there is no package depending on the libgnutls-openssl
anymore and so I dropped it. But I really do not plan to add it back
because upstream does not care about it and it seems to be left in the
experimental state forever. I do not think any other software should
depend on it for the SSL support. Either rewrite the SSL support to use
the native GNUTLS API, or use the NSS OpenSSL compatibility layer which
is written in such way that it does not conflict with the native OpenSSL
libraries.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trouble with building packages in F16: The moc has changed too much

2011-08-02 Thread Laurent Rineau

On lundi 01 août 2011 20:08:12 Richard Hughes wrote:
 On 1 August 2011 15:24, Jaroslav Reznik jrez...@redhat.com wrote:
  It's not very good idea to ship pre-generated moc files, better to
  autogenerate them during the build-time. PackageKit is using automake,
  so it's a little bit more difficult but possible, check for example [1].
 
 Right, I *think* I'm doing the right thing in
 https://gitorious.org/packagekit/packagekit/blobs/master/lib/packagekit-qt/
 src/Makefile.am with the only difference being that I'm shipping the moc
 files in the tarball. Can I just nuke the moc files in the fedora spec
 file, and they'll get regenerated at build time? Or should I remove
 MOCFILES from EXTRA_DIST?

Yes. MOC files are generated files like .o files. The difference is that it is 
generated *source* files. MOC files are with a version of Qt is not guaranted 
to be usable with another one x.y.z, even if only the .z version number is 
changed.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new cg-manager gui tool for managin cgroups

2011-08-02 Thread Vivek Goyal

On Thu, Jul 21, 2011 at 06:36:55PM +0200, Lennart Poettering wrote:
 On Thu, 21.07.11 11:28, Vivek Goyal (vgo...@redhat.com) wrote:
 
   It is already possible for different applications to use cgroups
   without stepping on each other, and without requiring every app
   to communicate with each other.
   
   As an example, when it starts libvirt will look at what cgroup
   it has been placed in, and create the VM cgroups below this point.
   So systemd can put libvirtd in an arbitrary location and set an
   overall limits for the virtualization service, and it will cap
   all VMs. No direct communication between systemd  libvirt is
   required.
   
   If applications similarly take care to honour the location in
   which they were started, rather than just creating stuff directly
   in the root cgroup, they too will interoperate nicely.
   
   This is one of the nice aspects to the cgroups hierarchy, and
   why having tools/daemons which try to arbitrarily re-arrange
   cgroups systemwide are not very desirable IMHO.
  
  This will work as long as somebody has done the top level setup and
  planning. For example, if somebody is running bunch of virtual machines
  and hosting some native applications and services also on the machine,
  then he might decide that all the virt machines can only use 8 out of
  10 cpus and keep 2 cpus free for native services.
  
  In that case an admin ought to be able to do this top level planning
  before handing out control of sub-hierarchies to respective applications.
  Does systemd allow that as of today?
 
 Right now, systemd only offers you to place services in the cgroups of
 your choice, it will not configure any settings on those cgroups. (This
 is very likely to change soon though as there is a patch pending that
 makes a number of popular controls available as native config options in
 systemd.)
 
 For the controllers like cpuset or the RT part of cpu where you
 assign resources from a limited pool we currently have no solution at
 all to deal with conflicts. Neither in libcgroup and friends, not in
 systemd, not in libvirt.

It is not just cpuset or RT part of cpu. This resource thing can apply
to simple thing like cpu shares or blkio controller weigts. For example,
one notion people seem to have to be able view division of system
resources in terms of percentage. Currently we don't have any way to
deal with it and if we want to achieve it then one would require overall
view of the hierarchy to be able to tell whether a certain group has got
certain % of something or not. If there is a separate manager for separate
parts of hierarchy, it is hard to do so.

So if we want to offer more sophisticated features to admin, then design
becomes somewhat complex and I am not sure if it is worth or not.

Also there is a question what kind of interface should be exposed to a
user/admin when it comes to allocating resources to cgroup. Saying that
give a virtual machine/group a cpu weight of 512 does not mean much. If
one wants to translate this number to a certain %, then he needs the
gloabl view.

Similarly some absolute max limits like offered by some controllers like
blkio, cpu might not make much sense if parent has been throttled to even
a smaller limit.

All this raises the question of how the design of UI/command line look
like for configuring cgroups/limits on various things like
users/services/virtual machines. Right now libvirt seems to be allowing
to specify name of the guest domain and some cgroups parameters (cpu
shares, blkio weight etc) for that domain. Again, in an hierarchy
specifying that does not mean anything in absolute system picture until
and unless somebody has overall view of the system.

This also raises the interesting question how cgroup interface of other
UIs in the system should evolve. 

So I have lots of questions/concerns but do not have good answers.
Hopefully this discussion can lead to some of the answers.

Thanks
Vivek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trouble with building packages in F16: The moc has changed too much

2011-08-02 Thread Richard Hughes

On 2 August 2011 14:54, Laurent Rineau
laurent.rineau__fed...@normalesup.org wrote:
 Yes. MOC files are generated files like .o files. The difference is that it is
 generated *source* files. MOC files are with a version of Qt is not guaranted
 to be usable with another one x.y.z, even if only the .z version number is
 changed.

Agreed. I fixed the problem upstream by not including the moc files in
the tarball, and in the Fedora spec file for the last release by
manually deleting the moc files, causing them to be regenerated.

Thanks to all of you! :)

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

disttags from f16 on

2011-08-02 Thread Dennis Gilmore

Hey all, this is a heads up that with the branching of f16  we have dropped 
dist- from the tags and targets in koji.

the target that should be used is always git branch-candidate so f16-
candidate it will always be correct. they have been added retroactively. as a 
result after f16 is out i plan to take an outage and rename all of the epel 
branches from el4 -epel-4 el5-epel5 el6-epel6 git to make it a bit clearer.

Dennis


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Broken dependencies: perl-Perlbal-XS-HTTPHeaders



perl-Perlbal-XS-HTTPHeaders has broken dependencies in the F-16 tree:
On x86_64:
perl-Perlbal-XS-HTTPHeaders-0.20-3.fc15.x86_64 requires 
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-Perlbal-XS-HTTPHeaders-0.20-3.fc15.i686 requires 
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon as possible.


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

Broken dependencies: perl-CGI-Application-Structured-Tools



perl-CGI-Application-Structured-Tools has broken dependencies in the F-16 tree:
On x86_64:
perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires 
perl(tmpl_var)
perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires 
main_module)
perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires 
perl(tmpl_var
On i386:
perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires 
perl(tmpl_var)
perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires 
main_module)
perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires 
perl(tmpl_var
Please resolve this as soon as possible.


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

Broken dependencies: perl-Pugs-Compiler-Rule



perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon as possible.


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

Broken dependencies: perl-Shipwright



perl-Shipwright has broken dependencies in the F-16 tree:
On x86_64:
perl-Shipwright-2.4.24-2.fc16.noarch requires perl(that)
On i386:
perl-Shipwright-2.4.24-2.fc16.noarch requires perl(that)
Please resolve this as soon as possible.


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

Broken dependencies: perl-NOCpulse-Gritch



perl-NOCpulse-Gritch has broken dependencies in the F-16 tree:
On x86_64:
perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires 
perl(:MODULE_COMPAT_5.12.3)
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: PokerTH orphaned

2011-08-02 Thread Ryan Rix

On Tue 2 August 2011 11:36:20 Hans de Goede wrote:
 Hi,
 
 On 08/01/2011 09:44 PM, Ryan Rix wrote:
  On Mon 1 August 2011 19:43:37 Tomas Mraz wrote:
  On Mon, 2011-08-01 at 10:29 -0700, Ryan Rix wrote:
  On Mon 1 August 2011 11:46:00 Jussi Lehtola wrote:
  Hi,
  
  
  I've just orphaned PokerTH, since I'm trying to free myself some
  time
  and I don't use it myself.
  
  PokerTH does not currently build on rawhide, since OpenSSL support
  has
  been dropped from GnuTLS a week ago (BZ #726697). Getting it to
  build
  again would then require building against OpenSSL (and asking
  upstream
  for a GPL license exception), or shipping a private copy of
  GnuTLS.
  
  I picked up rawhide through F-14. If I cant get this building, I'll
  orphan it again in a week's time.
  
  Shipping a private copy of GnuTLS would have to get an exception I do
  not think such exception should/would be granted. I can only recommend
  you to look at the NSS OpenSSL compatibility support library and
  patching PokerTH to use it instead of the GnuTLS.
  
  I've talked to a few people about this now, including some folks at
  PokerTH about it, and they're confused as to why this change is
  happening in GnuTLS at all, and your comment in the bug report did not
  seem to explain it to them; could you (or anyone) explain better why
  OpenSSL support in gnutls is a Bad Thing?
 
 Ryan, have you read the initial description of:
 https://bugzilla.redhat.com/show_bug.cgi?id=460310
 
 ?
 
 The problem is that gnutls's openssl compatibility uses the same symbol
 names as openssl itself thus polluting the dynamic linker symbol namespace.
 So if an application uses a library which is linked against openssl (for
 example ldap libs through pam) and uses gnutls-openssl then the ldap
 libraries will end up calling functions inside gnutls-openssl rather then
 inside openssl, since the gnutls-openssl symbols are already present in the
 dynamic linkers symbol namespace. This then goes boom big time, since the 2
 are not ABI compatible.
 
 Since gnutls-openssl is not ABI compatible it should not be using the same
 function / variable names.
 
 Tomas has chosen to fix this problem by simply disabling the openssl compat
 part of gnutls (which as the above bug shows is broken by design) given that
 only 3 apps use this, this seems like a sane choice to me.
 
 The best way forward is probably to ask PokerTH upstream to add the
 standard openssl license exception boilerplate to their license, I did
 so successfully with gkrellm and switched to simply using the real openssl.

Makes sense, thanks Hans. :)

I actually talked to them, and they say that openssl is pulled in only for 
linking libcurl, and that PokerTH itself is using gcrypt for the Big Stuff, so 
it should be fairly easy to fix/work around. 

r

-- 
Ryan Rix -- http://rix.si
== OpenSource.com: Where Open Source Happens! ==
   _
 \//_ All Hail the Beefy Miracle!
 /_/
 \ \


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

abiword

Abiword is currently broken in f16/rawhide due to the retiring of
link-grammar (a FTBFS retiree). 

This is currently breaking the Xfce, LXDE, and soas spins. 

Would someone be interested in reviving link-grammar and possibly
helping out updating/maintaining abiword? 

I've also sent email to the abiword maintainer, but they haven't
commited to abiword in almost a year. Others have been fixing it. ;( 

I'd guess the next steps would be: 

* update link-grammar and get it building/working.
* submit a review for it and get it back in. 
* update abiword and rebuild to use that version of link-grammar. 

kevin


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

Re: abiword

2011-08-02 Thread Adam Miller

On Tue, Aug 02, 2011 at 11:00:43AM -0600, Kevin Fenzi wrote:
 Abiword is currently broken in f16/rawhide due to the retiring of
 link-grammar (a FTBFS retiree). 
 
 This is currently breaking the Xfce, LXDE, and soas spins. 
 
 Would someone be interested in reviving link-grammar and possibly
 helping out updating/maintaining abiword? 
 
 I've also sent email to the abiword maintainer, but they haven't
 commited to abiword in almost a year. Others have been fixing it. ;( 
 
 I'd guess the next steps would be: 
 
 * update link-grammar and get it building/working.
 * submit a review for it and get it back in. 
 * update abiword and rebuild to use that version of link-grammar. 
 
 kevin


Would an option be to just retire abiword? Its slowly gotten less useful
in most cases because it doesn't handle formats near as well as it once
did (even .odt ... going from libreoffice to abiword is ... well,
painful) and if upstream isn't contuning development on it is there much
motivation to keep it alive? (I'm not entirely familiar with its user
base so my suggestion might be heavily greated with OMG NOES! replies
and if that's the case then by all means keep the train moving forward
... I just hate to unnessecary work done.)

Also, I think with the new compression on the Live images all the spins
have the spare space for LibreOffice.

Just my $0.02.

-AdamM
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

2011-08-02 Thread Simon Wesp

Am Mittwoch, 20 Juli 2011 15:28:05 schrieb Bill Nottingham:
BN Orphan: libglfw
BN hosts3d requires libglfw.so.2.6
BN hosts3d requires libglfw-devel = 2.6-6.fc15
BN hosts3d-sampler requires libglfw.so.2.6
BN taoframework-glfw requires libglfw = 2.6-6.fc15

hosts3d can't be in after one of the dependencies is kicked out. 
no one will take care of libglfw, so hosts3d should be kicked too.

-- 
Mit freundlichen Grüßen aus dem schönen Hainzell
Simon Wesp

http://fedoraproject.org/wiki/User:Cassmodiah
2.6.38.2-9.fc15.i686
Today is Prickle-Prickle, the 68th day of Confusion in the YOLD 3177


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

Re: abiword

2011-08-02 Thread Jon Ciesla

Adam Miller wrote:
 On Tue, Aug 02, 2011 at 11:00:43AM -0600, Kevin Fenzi wrote:
   
 Abiword is currently broken in f16/rawhide due to the retiring of
 link-grammar (a FTBFS retiree). 

 This is currently breaking the Xfce, LXDE, and soas spins. 

 Would someone be interested in reviving link-grammar and possibly
 helping out updating/maintaining abiword? 

 I've also sent email to the abiword maintainer, but they haven't
 commited to abiword in almost a year. Others have been fixing it. ;( 

 I'd guess the next steps would be: 

 * update link-grammar and get it building/working.
 * submit a review for it and get it back in. 
 * update abiword and rebuild to use that version of link-grammar. 

 kevin
 


 Would an option be to just retire abiword? Its slowly gotten less useful
 in most cases because it doesn't handle formats near as well as it once
 did (even .odt ... going from libreoffice to abiword is ... well,
 painful) and if upstream isn't contuning development on it is there much
 motivation to keep it alive? (I'm not entirely familiar with its user
 base so my suggestion might be heavily greated with OMG NOES! replies
 and if that's the case then by all means keep the train moving forward
 ... I just hate to unnessecary work done.)

 Also, I think with the new compression on the Live images all the spins
 have the spare space for LibreOffice.

 Just my $0.02.

 -AdamM
   
I'd like to see abiword stick around, my $0.02.

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abiword

2011-08-02 Thread Johannes Lips

I just initiated a scratch build with the new upstream version, which is 
failing due to missing files.
It seems as if the jar files aren't generated during the build/install 
process.
http://koji.fedoraproject.org/koji/taskinfo?taskID=3247252

I also don't see the reasoning of dropping an app just because one 
dependency was kicked out.

johannes

On 08/02/2011 07:07 PM, Adam Miller wrote:
 On Tue, Aug 02, 2011 at 11:00:43AM -0600, Kevin Fenzi wrote:
 Abiword is currently broken in f16/rawhide due to the retiring of
 link-grammar (a FTBFS retiree).

 This is currently breaking the Xfce, LXDE, and soas spins.

 Would someone be interested in reviving link-grammar and possibly
 helping out updating/maintaining abiword?

 I've also sent email to the abiword maintainer, but they haven't
 commited to abiword in almost a year. Others have been fixing it. ;(

 I'd guess the next steps would be:

 * update link-grammar and get it building/working.
 * submit a review for it and get it back in.
 * update abiword and rebuild to use that version of link-grammar.

 kevin


 Would an option be to just retire abiword? Its slowly gotten less useful
 in most cases because it doesn't handle formats near as well as it once
 did (even .odt ... going from libreoffice to abiword is ... well,
 painful) and if upstream isn't contuning development on it is there much
 motivation to keep it alive? (I'm not entirely familiar with its user
 base so my suggestion might be heavily greated with OMG NOES! replies
 and if that's the case then by all means keep the train moving forward
 ... I just hate to unnessecary work done.)

 Also, I think with the new compression on the Live images all the spins
 have the spare space for LibreOffice.

 Just my $0.02.

 -AdamM

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abiword

2011-08-02 Thread Ian Weller

On Tue, Aug 02, 2011 at 12:07:36PM -0500, Adam Miller wrote:
 Would an option be to just retire abiword? Its slowly gotten less useful
 in most cases because it doesn't handle formats near as well as it once
 did (even .odt ... going from libreoffice to abiword is ... well,
 painful) and if upstream isn't contuning development on it is there much
 motivation to keep it alive? (I'm not entirely familiar with its user
 base so my suggestion might be heavily greated with OMG NOES! replies
 and if that's the case then by all means keep the train moving forward
 ... I just hate to unnessecary work done.)

I'm very certain that it's because libreoffice-writer (and more
importantly, what it pulls in) is much much larger than abiword, and
live CD ISOs are small.

 Also, I think with the new compression on the Live images all the spins
 have the spare space for LibreOffice.

I'd love to see this actually happen. ;)

-- 
Ian Weller i...@ianweller.org
  _
\//_ All Hail the Beefy Miracle!
/_/   beefymiracle.org
\ \


pgpLNIx2QdBLX.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abiword

On Tue, 02 Aug 2011 19:35:22 +0200
Johannes Lips johannes.l...@googlemail.com wrote:

 I just initiated a scratch build with the new upstream version, which
 is failing due to missing files.
 It seems as if the jar files aren't generated during the
 build/install process.
 http://koji.fedoraproject.org/koji/taskinfo?taskID=3247252

Right. It is not detecting java for some reason... 

 I also don't see the reasoning of dropping an app just because one 
 dependency was kicked out.

Well, it's not just that, it's that it's not being maintained. ;) 

kevin


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

Re: abiword

On Tue, 2 Aug 2011 12:07:36 -0500
Adam Miller maxamill...@fedoraproject.org wrote:

 Would an option be to just retire abiword? Its slowly gotten less
 useful in most cases because it doesn't handle formats near as well
 as it once did (even .odt ... going from libreoffice to abiword
 is ... well, painful) and if upstream isn't contuning development on
 it is there much motivation to keep it alive? (I'm not entirely
 familiar with its user base so my suggestion might be heavily greated
 with OMG NOES! replies and if that's the case then by all means
 keep the train moving forward ... I just hate to unnessecary work
 done.)

If no one steps up to maintain it sure. Upstream is still very much
alive as far as I can see. It's just the Fedora package thats lagging. 

 Also, I think with the new compression on the Live images all the
 spins have the spare space for LibreOffice.

They might. 

kevin


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

Re: abiword

2011-08-02 Thread Johannes Lips

On 08/02/2011 07:39 PM, Kevin Fenzi wrote:
 On Tue, 02 Aug 2011 19:35:22 +0200
 Johannes Lipsjohannes.l...@googlemail.com  wrote:

 I just initiated a scratch build with the new upstream version, which
 is failing due to missing files.
 It seems as if the jar files aren't generated during the
 build/install process.
 http://koji.fedoraproject.org/koji/taskinfo?taskID=3247252

 Right. It is not detecting java for some reason...
Fixed, it's just a missing BuildRequirement of libgcj-devel. If you like 
I could open a Review Request.

 I also don't see the reasoning of dropping an app just because one
 dependency was kicked out.

 Well, it's not just that, it's that it's not being maintained. ;)

 kevin




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abiword

On Tue, 02 Aug 2011 19:45:25 +0200
Johannes Lips johannes.l...@googlemail.com wrote:

...snip...

  Right. It is not detecting java for some reason...
 Fixed, it's just a missing BuildRequirement of libgcj-devel. If you
 like I could open a Review Request.

Sure. Feel free. 

kevin


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

Re: abiword

2011-08-02 Thread Johannes Lips

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

Hope someone is reviewing it in a short while.

Johannes

On 08/02/2011 07:52 PM, Kevin Fenzi wrote:
 On Tue, 02 Aug 2011 19:45:25 +0200
 Johannes Lipsjohannes.l...@googlemail.com  wrote:

 ...snip...

 Right. It is not detecting java for some reason...
 Fixed, it's just a missing BuildRequirement of libgcj-devel. If you
 like I could open a Review Request.

 Sure. Feel free.

 kevin




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abiword

2011-08-02 Thread Martin Langhoff

On Tue, Aug 2, 2011 at 1:55 PM, Johannes Lips
johannes.l...@googlemail.com wrote:
 Done.
 https://bugzilla.redhat.com/show_bug.cgi?id=727646

 Hope someone is reviewing it in a short while.

thanks! Abiword (actually libabiword) is an important part of the OLPC
 Sugar desktop environment.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 2011-07-29 - F16 Alpha blocker bug review #3 - recap

On Sun, 2011-07-31 at 11:40 +0200, Andreas Tunek wrote:
 2011/7/29 James Laska jla...@redhat.com:
 
 
  * http://bugzilla.redhat.com/show_bug.cgi?id=711489  (jlaska, 17:42:29)
   * atl1c: transmit queue timeout (ASUS 522)  (jlaska, 17:42:33)
   * AGREED: 711489 - RejectedBlocker - nasty, but impacts limited
 hardware and has a workaround.  May re-evaluate if new information
 surfaces  (jlaska, 17:48:14)
 
 What is the workaround for this bug? None is given in bugzilla.

Yes, it is:

https://bugzilla.redhat.com/show_bug.cgi?id=711489#c2
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File dspam-3.10.0.tar.gz uploaded to lookaside cache by gnat

2011-08-02 Thread Nathanael Noblet

A file has been added to the lookaside cache for dspam:

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

Re: Power and brightness issue

On Sun, 2011-07-31 at 15:37 -0300, Sergio Belkin wrote:
 I've read 
 http://fedoraproject.org/wiki/Bugs/Common#Laptop_screen_dims_when_switching_to_battery_power_or_idle_mode_but_never_brightens_again
 
 My system suffers the same symptoms but I use KDE. So it seems that is
 not GNOME restricted.
 
 
 Using F15 on x86_64
 
 cat /sys/module/pcie_aspm/parameters/policy
 default performance [powersave]
 
 any ideas?

That bug certainly was GNOME specific: it was a bug in
gnome-power-manager 's logic. There's no way that specific bug could
affect KDE, unless somehow you're running g-p-m in KDE. If you're seeing
a similar issue in KDE, it must track down to a different bug, so please
file it. Be aware, though, that the display dimming somewhat when you
disconnect the AC power is 'normal': both KDE and GNOME do this to save
battery power. The bug in this case was that when you re-connected to AC
the brightness did not increase again, but if you then disconnected from
AC once more the brightness would decrease further - so you got stuck in
a descending spiral of darkness until the screen was stuck at its lowest
possible brightness setting until you adjusted it manually or rebooted.
If the screen dims somewhat (to, say, 50%) when you unplug, goes back up
to 100% when you plug back in, then dims back to 50% when you unplug
again, that's intended behaviour and not a bug (though if you don't like
it, it's configurable).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[dspam] new upstream release

2011-08-02 Thread Nathanael Noblet

commit bea0e744b37b480c1e924dca6bb8d849940a3ea3
Author: Nathanael D. Noblet nathan...@gnat.ca
Date:   Tue Aug 2 12:50:08 2011 -0600

new upstream release

 .gitignore |1 +
 dspam.spec |   15 ++-
 sources|2 +-
 3 files changed, 12 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b369bb4..91880e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 dspam-3.9.0.tar.gz
+dspam-3.10.0.tar.gz
diff --git a/dspam.spec b/dspam.spec
index 7f20636..206c73e 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -10,8 +10,8 @@
 
 Summary:A library and Mail Delivery Agent for Bayesian SPAM 
filtering
 Name:   dspam
-Version:3.9.0
-Release:22%{?dist}
+Version:3.10.0
+Release:1%{?dist}
 License:GPLv2
 Group:  System Environment/Daemons
 Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -24,7 +24,7 @@ Source6:dspam-sysconfig
 Source7:   dspam-tmpfiles
 Source8:   dspam-systemd
 Source99:   dspam-filter-requires.sh
-Patch0: dspam-3.9.0-file-name.patch
+#Patch0: dspam-3.9.0-file-name.patch
 Patch1: dspam-3.9.0-docs.patch
 Patch2: dspam-3.9.0-dspamsock.patch
 URL:http://www.nuclearelephant.com/
@@ -134,7 +134,7 @@ Web-based interface for DSPAM's powerful Anti-Spam engine.
 %prep
 
 %setup -q
-%patch0 -p1
+#%patch0 -p1
 %patch1 -p0
 %patch2 -p0
 
@@ -324,6 +324,7 @@ exit 0
 %{_bindir}/dspam_merge
 %{_bindir}/dspam_stats
 %{_bindir}/dspam_train
+%{_bindir}/dspam_notify
 %{_bindir}/dspam-front
 
 %files client
@@ -341,7 +342,7 @@ exit 0
 
 %files hash
 %defattr(-,root,root,-)
-%doc README.cssclean
+#%doc README.cssclean
 %{_libdir}/dspam/libhash_drv.so*
 %{_bindir}/css*
 
@@ -379,6 +380,10 @@ exit 0
 %config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
 
 %changelog
+* Tue Aug 2 2011 Nathanael Noblet nathan...@gnat.ca - 3.10.0-1
+- New upstream release
+- Removed README.cssclean
+
 * Wed Jul 13 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-22
 - Systemd unit file
 
diff --git a/sources b/sources
index 8633caa..3624e90 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-10d092b57d628d8c91655fee5dc0d0cd  dspam-3.9.0.tar.gz
+2e83e98a03af492df82532441e4ce335  dspam-3.10.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Power and brightness issue

2011-08-02 Thread Genes MailLists

On 08/02/2011 02:41 PM, Adam Williamson wrote:
On Sun, 2011-07-31 at 15:37 -0300, Sergio Belkin wrote:
I've read
http://fedoraproject.org/wiki/Bugs/Common#Laptop_screen_dims_when_switching_to_battery_power_or_idle_mode_but_never_brightens_again

My system suffers the same symptoms but I use KDE. So it seems that is
not GNOME restricted.

Using F15 on x86_64

cat /sys/module/pcie_aspm/parameters/policy
default performance [powersave]

any ideas?

That bug certainly was GNOME specific: it was a bug in
gnome-power-manager 's logic. There's no way that specific bug could
affect KDE, unless somehow you're running g-p-m in KDE. If you're seeing
a similar issue in KDE, it must track down to a different bug, so please
file it. Be aware, though, that the display dimming somewhat when you
disconnect the AC power is 'normal': both KDE and GNOME do this to save
battery power. The bug in this case was that when you re-connected to AC
the brightness did not increase again, but if you then disconnected from
AC once more the brightness would decrease further - so you got stuck in
a descending spiral of darkness until the screen was stuck at its lowest
possible brightness setting until you adjusted it manually or rebooted.
If the screen dims somewhat (to, say, 50%) when you unplug, goes back up
to 100% when you plug back in, then dims back to 50% when you unplug
again, that's intended behaviour and not a bug (though if you don't like
it, it's configurable).

I've seen a different bug on KDE - specifically - after a sleep/resume
cycle (I think) - going to battery off A/C - the applet says its in
powersave mode but the screen is NOT dimmed - using the applet to switch
to performance and then back to powersave mode - dims the screen.

This is (as far as I know) specific to KDE but I could be wrong ...

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

On Tue, 2011-08-02 at 15:00 +0200, Nils Philippsen wrote:
 On Tue, 2011-08-02 at 13:37 +0100, Richard W.M. Jones wrote:
  Below are two packages.  The first one is installed, the second one is
  built for Koji.  Yum refuses to upgrade the installed package to the
  second one, saying:
  
  Examining qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: 
  2:qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64
  qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: does not update installed 
  package.
  
  But I don't understand why, since it seems clear that the second
  package has a higher release than the first package.
 
 The version comparison method of RPM is a bit quirky and non-obvious: It
 separates elements at dots (obvious) but also at changes between digits
 and other characters (non-obvious). Let's look at only the releases of
 the two packages:
 
 0.2.20110718525e3df.fc16
 0.2.2011072859fadcc.fc17
 
 Split up into the elements that RPM compares, these are:
 
 0, 2, 20110718525, e, 3,  df, fc, 16
 0, 2, 2011072859,  fadcc, fc, 17
   
 The third elements cause this evr-comparison to have a result which you
 don't expect. Bump the second element 2 to 3 and you should be
 fine :-).

Well, in this case yes, but this problem could emerge again in a case
where there's no version bump that 'should have' been carried out. The
fundamental problem here is that git commit IDs are a single hex string,
but RPM version comparison doesn't do hex, it splits out base-10
'numeric' fields and 'alphabetic' fields.

So, we should probably update
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag to
cover this problem: perhaps it should say that if you're going to
include the git commit ID in the package EVR at all, it should be after
the date _and a . separator_. If these had been versioned:

0.2.20110718.525e3df.fc16
0.2.20110728.59fadcc.fc17

then I believe things would have worked as expected. So that should
probably be in the guidelines. (There still remains the corner case that
you ship two different git revisions in the same day, I guess...)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

On Tue, 2011-08-02 at 11:58 -0700, Adam Williamson wrote:

 Well, in this case yes, but this problem could emerge again in a case
 where there's no version bump that 'should have' been carried out. The
 fundamental problem here is that git commit IDs are a single hex string,
 but RPM version comparison doesn't do hex, it splits out base-10
 'numeric' fields and 'alphabetic' fields.

I suppose also, of course, git commit IDs don't increment, so even if
RPM spoke hex, they'd be unsuitable for use in version comparison. I
don't know if anyone would argue it's fundamentally 'wrong' for git
commit IDs to be in RPM EVRs, or if it's okay for them to be there as
long as you make sure there's stuff ahead of them which will always
compare correctly. Maybe the RPM team has an opinion.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

2011-08-02 Thread Michael Schwendt

On Tue, 02 Aug 2011 11:58:08 -0700, AW (Adam) wrote:

  0.2.20110718525e3df.fc16
  0.2.2011072859fadcc.fc17
  
  Split up into the elements that RPM compares, these are:
  
  0, 2, 20110718525, e, 3,  df, fc, 16
  0, 2, 2011072859,  fadcc, fc, 17

  The third elements cause this evr-comparison to have a result which you
  don't expect. Bump the second element 2 to 3 and you should be
  fine :-).
 
 Well, in this case yes, but this problem could emerge again in a case
 where there's no version bump that 'should have' been carried out.

When would that be?

Packagers ought to bump the most-significant portion of %{release}
with every build where %{version} stays the same. In this case:
  0.2.somelongstuff = 0.3.somesimilarlylongstuff

-- 
For the pre-release versioning scheme, it's not the left-most part
of %release, but the one right of the leading '0.', of course.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: ipython-0.11 breaking anything :)

2011-08-02 Thread Jerry James

On Sun, Jul 31, 2011 at 12:53 PM, Thomas Spura
toms...@fedoraproject.org wrote:
 Hi list,

 I just build ipython-0.11 in rawhide, which changed pretty much
 anything internally, so *ALL* dependant packages will be possible
 broken.

 repoquery just reports 2 packages, but it should be more...:
 python-networkx
 python-polybori

I comaintain these two.  I think python-networkx should not depend on
ipython.  One example mentions in a comment that it should be run with
ipython, but there is no direct dependency.  As for python-polybori,
the command-line tool ipbori invokes ipython, but by running it in a
subshell, not via the library interface.  So as long as the command
line options haven't changed, python-polybori should be okay, too.

Unfortunately, I can't test it.  I waited for today's Rawhide update
so I could get the new version of ipython.  About 2 seconds after the
yum transaction finished, X suddenly quit.  I rebooted (since there
was a new kernel and a new systemd, after all), but now I can't login.
 Logging in from GDM results in the screen clearing for a fraction of
a second, and then GDM starts back up.  Likewise, Ctrl-Alt-F2 gives me
a TTY.  If I attempt to login, the screen clears momentarily, and then
the TTY login prompt reappears.  Plus, GDM keeps restarting every few
seconds, which makes working on a TTY problematic anyway.  Something
is really broken.  As soon as the brokenness gets cleared up, I'll
test python-polybori to see if it is okay with the new ipython.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

On Tue, 2011-08-02 at 21:24 +0200, Michael Schwendt wrote:
 On Tue, 02 Aug 2011 11:58:08 -0700, AW (Adam) wrote:
 
   0.2.20110718525e3df.fc16
   0.2.2011072859fadcc.fc17
   
   Split up into the elements that RPM compares, these are:
   
   0, 2, 20110718525, e, 3,  df, fc, 16
   0, 2, 2011072859,  fadcc, fc, 17
 
   The third elements cause this evr-comparison to have a result which you
   don't expect. Bump the second element 2 to 3 and you should be
   fine :-).
  
  Well, in this case yes, but this problem could emerge again in a case
  where there's no version bump that 'should have' been carried out.
 
 When would that be?
 
 Packagers ought to bump the most-significant portion of %{release}
 with every build where %{version} stays the same. In this case:
   0.2.somelongstuff = 0.3.somesimilarlylongstuff

oh, yes, you're right, my mistake. I was mistaking the 0.2 / 0.3 bit for
an upstream version number, but of course it's not that, it's the
'failsafe' revision bump, which does indeed solve this kinda problem. I
think it might still be a good idea to split the date from the git rev,
but since we have the extra revision digit there, it's not really
crucial. I was forgetting about that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 727671] New: perl-DateTime-Set-0.28-1.el6.src.rpm and perl-DateTime-Event-Recurrence-0.16-8.el6.src.rpm BuildRequires dependencies loop

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-DateTime-Set-0.28-1.el6.src.rpm and 
perl-DateTime-Event-Recurrence-0.16-8.el6.src.rpm BuildRequires dependencies 
loop

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

   Summary: perl-DateTime-Set-0.28-1.el6.src.rpm and
perl-DateTime-Event-Recurrence-0.16-8.el6.src.rpm
BuildRequires dependencies loop
   Product: Fedora EPEL
   Version: el6
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: unspecified
  Priority: unspecified
 Component: perl-DateTime-Set
AssignedTo: st...@silug.org
ReportedBy: giamteckch...@gmail.com
 QAContact: extras...@fedoraproject.org
CC: st...@silug.org, xav...@bachelot.org,
fedora-perl-devel-l...@redhat.com
Classification: Fedora
  Story Points: ---
  Type: ---


Description of problem:

While trying to rebuild perl-DateTime-Set-0.28-1.el6.src.rpm and
perl-DateTime-Event-Recurrence-0.16-8.el6.src.rpm from a test repo using mock
which doesn't contain any of the two rpm packages, I noticed either of them
can't be rebuild in that environment since both depends on each other.

ERROR: Command failed:
 # ['/usr/bin/yum-builddep', '--nogpgcheck', '--installroot',
'/var/lib/mock/sl-6-i386-choonrpms-testing/root/',
'/home/mockbuild/Downloads/epel6/perl-DateTime-Set-0.28-1.el6.src.rpm']
Getting requirements for perl-DateTime-Set-0.28-1.el6.src
 -- 1:perl-DateTime-0.5300-1.el6.i686
Error: No Package found for perl(DateTime::Event::Recurrence)

ERROR: Command failed: 
 # ['/usr/bin/yum-builddep', '--nogpgcheck', '--installroot',
'/var/lib/mock/sl-6-i386-choonrpms-testing/root/',
'/home/mockbuild/Downloads/epel6/perl-DateTime-Event-Recurrence-0.16-8.el6.src.rpm']
Getting requirements for perl-DateTime-Event-Recurrence-0.16-8.el6.src
 -- 1:perl-DateTime-0.5300-1.el6.i686
Error: No Package found for perl(DateTime::Set) = 0.17

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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

Review Request Need Sponsor: Ruby 2.3.12 in Fedora 15+

2011-08-02 Thread Emanuel Rietveld

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

Although Rails 3 was released, there are still rails projects working
with rails 2.3 series. Rails 3 is not backwards compatible and some key
features are not yet working in Rails 3. One notable project still on rails 2.3
is the issue tracker redmine http://www.redmine.org

Since rails 2 and rails 3 are perfectly parallel installable, I would like to
maintain rails 2.3 series in Fedora until it really becomes obsolete.

Therefore I have packaged Ruby 2.3.12 for F15/F16, basing them on the
Rails 2.3.8 packages already in F14.

This is my first package for Fedora and I welcome any feedback.

Thank you for your time.

-Emanuel

-- Forwarded message --
From: Mo Morsi m...@morsi.org
Date: Tue, Aug 2, 2011 at 9:24 PM
Subject: Re: Rails 2 in F16
To: Emanuel Rietveld codehot...@gmail.com


Hey Emanuel, appreciate the effort. Will look at it if I get the chance,
but time is short nowadays so not sure when that is going to be.

Most likely you will have luck if you email the ruby sig directly.

http://lists.fedoraproject.org/pipermail/ruby-sig/

Since you are a new packager though, you will have to go through the
sponsorship process. Not hard, but it could take longer.

Take care,
  -Mo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abiword

2011-08-02 Thread Rahul Sundaram

On 08/02/2011 11:09 PM, Kevin Fenzi wrote:
 If no one steps up to maintain it sure. Upstream is still very much
 alive as far as I can see. It's just the Fedora package thats lagging. 

You can ping uwog in #abiword in irc.gimp.net for any future
discussions.  I just had a quick chat with him and he is going to build
Abiword with grammar support disabled for the time being till link
grammar is back in the repo.   I have informed him of the FTBFS policy. 

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: ipython-0.11 breaking anything :)

2011-08-02 Thread Jerry James

On Tue, Aug 2, 2011 at 1:29 PM, Jerry James loganje...@gmail.com wrote:
 Unfortunately, I can't test it.  I waited for today's Rawhide update
 so I could get the new version of ipython.  About 2 seconds after the
 yum transaction finished, X suddenly quit.  I rebooted (since there
 was a new kernel and a new systemd, after all), but now I can't login.
  Logging in from GDM results in the screen clearing for a fraction of
 a second, and then GDM starts back up.  Likewise, Ctrl-Alt-F2 gives me
 a TTY.  If I attempt to login, the screen clears momentarily, and then
 the TTY login prompt reappears.  Plus, GDM keeps restarting every few
 seconds, which makes working on a TTY problematic anyway.  Something
 is really broken.  As soon as the brokenness gets cleared up, I'll
 test python-polybori to see if it is okay with the new ipython.

It looks like the problem is SELinux-related.  I did a full relabel to
see if it would clear things up, but it didn't.  I can login
successfully after booting with enforcing=0, though.  I'm seeing lots
of AVC denials in the logs.  Here are the denials I see in
/var/log/messages (with enforcing=0):

[8.206691] type=1400 audit(1312314954.461:3): avc:  denied  {
dyntransition } for  pid=1 comm=systemd
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=process
[   11.777659] type=1400 audit(1312314958.032:4): avc:  denied  { read
} for  pid=572 comm=systemd-sysctl name=sysctl.conf dev=dm-1
ino=131521 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_conf_t:s0 tclass=file
[   11.781152] type=1400 audit(1312314958.035:5): avc:  denied  { open
} for  pid=572 comm=systemd-sysctl name=sysctl.conf dev=dm-1
ino=131521 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_conf_t:s0 tclass=file
[   11.800415] type=1400 audit(1312314958.055:6): avc:  denied  {
getattr } for  pid=572 comm=systemd-sysctl path=/etc/sysctl.conf
dev=dm-1 ino=131521 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_conf_t:s0 tclass=file
[   17.387700] type=1400 audit(1312314963.642:7): avc:  denied  {
relabelto } for  pid=663 comm=systemd-tmpfile name=seats dev=tmpfs
ino=12579 scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=dir
[   17.393413] type=1400 audit(1312314963.648:8): avc:  denied  {
relabelto } for  pid=663 comm=systemd-tmpfile name=sessions
dev=tmpfs ino=12583 scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=dir
[   19.280082] type=1400 audit(1312314965.535:9): avc:  denied  {
unlink } for  pid=677 comm=NetworkManager name=resolv.conf
dev=dm-1 ino=131244 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file
[   19.629917] type=1400 audit(1312314965.884:10): avc:  denied  {
name_bind } for  pid=840 comm=dhclient src=11807
scontext=system_u:system_r:dhcpc_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
[   20.125998] type=1400 audit(1312314966.380:11): ac:  denied  {
rename } for pid=904 comm=Xorg name=Xorg.0.log dev=dm-1 ino=392488
scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_log_t:s0 tclass=file
[   20.130982] type=1400 audit(1312314966.384:12): avc:  denied  {
unlink } for  pid=904 comm=Xorg name=Xorg.0.log.old dev=dm-1
ino=392491 scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_log_t:s0 tclass=file
[  607.234395] type=1400 audit(1312315564.790:13): avc:  denied  {
read } for  pid=1745 comm=sendmail name=online dev=sysfs ino=34
scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sysfs_t:s0 tclass=file
[  607.234488] type=1400 audit(1312315564.790:14): avc:  denied  {
open } for  pid=1745 comm=sendmail name=online dev=sysfs ino=34
scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sysfs_t:s0 tclass=file

In addition, looking back farther in the log, I see LOTS of these when
SELinux was in enforcing mode:

avc:  denied  { sigchld } for pid=1 comm=systemd
scontext=system_u:system_r:loadkeys_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=process


Also, I can test now, and it looks like python-polybori is broken by
the new ipython.  When I try to run ipbori, I get an ipython help
message, followed by this:

[TerminalIPythonApp] Unrecognized flag: '-rcfile'

So ... what?  Is --ipython-dir what we should use now?
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fwd: Rapid DHCP

2011-08-02 Thread Bill McGonigle

On 08/01/2011 07:25 PM, Adam Williamson wrote:
 It seems like there's SOMETHING which has to happen after
 wake before NM even attempts to re-establish a connection, and that's
 the longest delay, at least for me. Anyone know what that something is,
 and whether it can be optimized?

I don't know what your networks look like, but are you perhaps seeing
the delay in (not)discovering IPv6 on an IPv4-only network?  My wife's
f15 machine was doing this on our home network and I just disabled IPv6
in the connection definition and it got much faster.  Not sure if that's
a good default behavior given typical use cases.

-Bill

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: b...@bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 2011-07-29 - F16 Alpha blocker bug review #3 - recap

2011-08-02 Thread Andreas Tunek

2011/8/2 Adam Williamson awill...@redhat.com:
 On Sun, 2011-07-31 at 11:40 +0200, Andreas Tunek wrote:
 2011/7/29 James Laska jla...@redhat.com:

 
  * http://bugzilla.redhat.com/show_bug.cgi?id=711489  (jlaska, 17:42:29)
   * atl1c: transmit queue timeout (ASUS 522)  (jlaska, 17:42:33)
   * AGREED: 711489 - RejectedBlocker - nasty, but impacts limited
     hardware and has a workaround.  May re-evaluate if new information
     surfaces  (jlaska, 17:48:14)

 What is the workaround for this bug? None is given in bugzilla.

 Yes, it is:

 https://bugzilla.redhat.com/show_bug.cgi?id=711489#c2

Do you mean that having an active ethernet connection at all times is
the workaround?
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel


/Andreas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abiword

2011-08-02 Thread Peter Robinson

On Tue, Aug 2, 2011 at 6:07 PM, Adam Miller
maxamill...@fedoraproject.orgwrote:

 On Tue, Aug 02, 2011 at 11:00:43AM -0600, Kevin Fenzi wrote:
  Abiword is currently broken in f16/rawhide due to the retiring of
  link-grammar (a FTBFS retiree).
 
  This is currently breaking the Xfce, LXDE, and soas spins.
 
  Would someone be interested in reviving link-grammar and possibly
  helping out updating/maintaining abiword?
 
  I've also sent email to the abiword maintainer, but they haven't
  commited to abiword in almost a year. Others have been fixing it. ;(
 
  I'd guess the next steps would be:
 
  * update link-grammar and get it building/working.
  * submit a review for it and get it back in.
  * update abiword and rebuild to use that version of link-grammar.
 
  kevin


 Would an option be to just retire abiword? Its slowly gotten less useful
 in most cases because it doesn't handle formats near as well as it once
 did (even .odt ... going from libreoffice to abiword is ... well,
 painful) and if upstream isn't contuning development on it is there much
 motivation to keep it alive? (I'm not entirely familiar with its user
 base so my suggestion might be heavily greated with OMG NOES! replies
 and if that's the case then by all means keep the train moving forward
 ... I just hate to unnessecary work done.)

 Also, biw


OMG NOES! It is used by OLPC and I use it constantly as its infinitely
faster than oowriter for basic documents.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange RPM versioning problem in qemu in Rawhide

2011-08-02 Thread Toshio Kuratomi

On Tue, Aug 02, 2011 at 12:31:15PM -0700, Adam Williamson wrote:
 On Tue, 2011-08-02 at 21:24 +0200, Michael Schwendt wrote:
  On Tue, 02 Aug 2011 11:58:08 -0700, AW (Adam) wrote:
  
0.2.20110718525e3df.fc16
0.2.2011072859fadcc.fc17

Split up into the elements that RPM compares, these are:

0, 2, 20110718525, e, 3,  df, fc, 16
0, 2, 2011072859,  fadcc, fc, 17
  
The third elements cause this evr-comparison to have a result which you
don't expect. Bump the second element 2 to 3 and you should be
fine :-).
   
   Well, in this case yes, but this problem could emerge again in a case
   where there's no version bump that 'should have' been carried out.
  
  When would that be?
  
  Packagers ought to bump the most-significant portion of %{release}
  with every build where %{version} stays the same. In this case:
0.2.somelongstuff = 0.3.somesimilarlylongstuff
 
 oh, yes, you're right, my mistake. I was mistaking the 0.2 / 0.3 bit for
 an upstream version number, but of course it's not that, it's the
 'failsafe' revision bump, which does indeed solve this kinda problem. I
 think it might still be a good idea to split the date from the git rev,
 but since we have the extra revision digit there, it's not really
 crucial. I was forgetting about that.

That is the intention of the Guideline, where you substitute
s/\./(git|cvs|svn|bzr|hg)/

So the above releases should have been:
  0.2.20110718git525e3df.fc16
  0.2.20110728git59fadcc.fc17

(Note that the git hash is optional, so they could also have been:
  0.2.20110718git
  0.2.20110728git
)

I can see how people would misinterpret the guidelines as currently written,
though:

If a snapshot package is considered a pre-release package, you should
follow the guidelines listed in Pre-Release Packages , and use an
%{alphatag} beginning with the date in MMDD format and followed by up to
16 (ASCII) alphanumeric characters of your choosing. The date should
reference the date the checkout was taken; the rest can be as simple as
cvs or snap, or a subversion change number like svn12345 or an
abbreviated git hash like git5aef11739b.

If a snapshot package is considered a post-release package, the following
applies:

Release Tag for Post-Release Snapshot Packages: %{X}.%{alphatag}

Where %{X} is the build number from any previous stable package build,
incremented by one (if no previous stable package build, use 1), and
%{alphatag} is the checkout string, as described above.

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

I'm updating this now.

* Reorder the section to have snapshot, pre-release, post-release.
* Rewrite the snapshot package section as below

Snapshot packages contain data about where the snapshot came from as well as
ordering information for rpm.  The information about the snapshot will be
called %{checkout} in this section.

%{checkout} consists of the date that the snapshot is made in MMDD
format, a short (2-5 characters) string identifying the type of revision
control system or that this is a snapshot, and optionally, up to 13
characters (ASCII) alphanumeric characters that could be useful in finding
the revision in the revision control system.

For instance, if you create a snapshot from a git repository on January 2,
2011 with git hash 9e88d7e9efb1bcd5b41a408037bb7cfd47220a64, %{checkout}
string could be any of the following::
   20110102snap
   20110102git
   20110102git9e88d7e

If the snapshot package is considered a pre-release package, you should
follow the guidelines listed in Pre-Release Packages for snapshot packages,
using the %{checkout} that you decide on above.  (For instance, in
kismet-0.0.3.20040204svn, 20040204svn is the %{checkout})

If the snapshot is a post-release package, you should follow the
guidelines in the Post-Release Packages section.  Where the %{posttag} in
that section is the %{checkout} string you decided on above.


-Toshio


pgpduC7KrWKA2.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Python 2.7.1?

2011-08-02 Thread Josh Stone

On 07/31/2011 05:07 PM, Michel Alexandre Salim wrote:
 On 08/01/2011 12:21 AM, Richard Shaw wrote:
 I figure there's a reason but I went ahead and tried a mock build of
 the F15 source in F14 and ran into a build problem[1]. I'm assuming
 that's the reason?

 That build problem is similar to a recent problem affecting F-16 Python
 builds:
 
   https://bugzilla.redhat.com/show_bug.cgi?id=711427
 
 While the systemtap in F-14 is of a higher revision than the one which
 fixes one Python build problem (comment #3) on that report, it appears
 that the Python Makefile fix (comment #6) introduced in 2.7.2-3.fc16
 hasn't been backported to F-15 yet.

Despite the apparent sync of revision numbers, systemtap in F14  doesn't
actually have all the same patches applied.  I just ran a few mock
builds to confirm python's FTBFS, and I also confirmed that this is
fixed by systemtap 1.6.  That update is now waiting in bodhi...

Josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] 2011-08-04 Fedora 15 EC2 Test Day

2011-08-02 Thread Tim Flink

This is a little later than originally planned, but the Fedora 15
(yes, Fedora 15 - not a typo) EC2 test day will be on this Thursday
2011-08-04 [1].

Fedora 15 AMIs are available for testing and are listed on the test
day wiki page [1]. The tests are designed to ensure basic functionality
for the AMIs (MTA, httpd, yum etc.).

Since these tests require an Amazon AWS account, we are offering some
compensation (up to US$5) for the first 10 people to go through the EC2
test cases. This will be done on a first come, first served basis -
make sure that you contact rbergeron to verify that you are one of the
10 people or you may not get the credit.

Tim

PS - If you have the means to pay for the EC2 time or a free account,
please use that. We're just trying to make sure that everyone who wants
to participate can.

[1]
https://fedoraproject.org/wiki/Test_Day:2011-08-04_Cloud_SIG_Fedora_EC2




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

Re: GLIB_GSETTINGS: command not found

2011-08-02 Thread Richard Shaw

2011/8/1 Miloslav Trmač m...@volny.cz:
 On Tue, Aug 2, 2011 at 12:15 AM, Richard Shaw hobbes1...@gmail.com wrote:
 ./configure: line 4193: GLIB_GSETTINGS: command not found

 While I found quite a few hits on google, it seemed to be short on 
 solutions...

 I checked out the configuration file and it just has a single line:

 GLIB_SETTINGS

 Is this an environment variable that's supposedly magically set to something?
 This is an attempt to use an autoconf macro that is not defined on your 
 system.

 Is it SETTINGS or _G_SETTINGS?  GLIB_GSETTINGS is defined in
 glib2-devel's /usr/share/aclocal/gsettings.m4 on F15, so adding a
 BuildRequires: might help.

That got it!

Of course a better (more useful) error message would have helped...

Thanks,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning moovida*

2011-08-02 Thread Graeme Gillies

Hi,

I am orphaning the following packages
moovida
moovida-plugins-bad
moovida-plugins-good

Due to pigment (which it depends on) being depreciated, as well as
upstream being essentially dead (new versions of the Moovida have been
re-licensed as closed source, and noone in the community is interested
in continuing the Moovida 1.X branch).

If someone is desperate to keep maintaining Moovida, note that they
would need to also pickup the depreciated pigment library, and maintain
both pigment and Moovida themselves. At the moment Moovida will not
build in Fedora 16 or Rawhide due to the missing pigment dependency.

Regards,

Graeme
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

String Freeze 2011-08-02

2011-08-02 Thread Noriko Mizumoto

Fedora Packagers

It is String Freeze date on 2011-08-02.
Fedora Localization team will soon start translating latest packages via
Transifex. Our goal is Fedora software translation to be 100% completed
as many languages as possible.

Please make sure that your latest POT file has been uploaded to
Transifex for translators.
If you think that you need to break the string freeze, then you should
ask for approval from the Fedora Localization Team prior to breaking the
freeze. Software string freeze policy can be found at [1].

Thank you so much for your support in advance.

[1]:https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy

Regards,

noriko
Fedora L10N
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

2.6.40 kernel update broke my ALSA apps

2011-08-02 Thread Sam Varshavchik


After update to 2.6.40:

$ arecord -L

…

default:CARD=CODEC
   USB Audio CODEC, USB Audio
   Default Audio Device

In prior kernels, this device was listed by alsa as default:CARD=default.

This is the --device parameter to aplay, and friends. My scripts that run  
aplay broke spectacularly after the update.


Is this the kind of a kernel update we want to push out, in the middle of a  
release? Seems to me that this kind of backwards compatibility-breaking  
stuff belongs in the next release.




pgp24k2XatF8o.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 695597] Providing native systemd file for upcoming F15 Feature Systemd

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Marcela Mašláňová mmasl...@redhat.com changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution||DUPLICATE
Last Closed||2011-08-02 03:39:58

--- Comment #3 from Marcela Mašláňová mmasl...@redhat.com 2011-08-02 03:39:58 
EDT ---


*** This bug has been marked as a duplicate of bug 695584 ***

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 695584] Providing native systemd file for upcoming F15 Feature Systemd

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #5 from Marcela Mašláňová mmasl...@redhat.com 2011-08-02 03:39:53 
EDT ---
*** Bug 695589 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 695584] Providing native systemd file for upcoming F15 Feature Systemd

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #6 from Marcela Mašláňová mmasl...@redhat.com 2011-08-02 03:39:59 
EDT ---
*** Bug 695597 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 695589] Providing native systemd file for upcoming F15 Feature Systemd

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Marcela Mašláňová mmasl...@redhat.com changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution||DUPLICATE
Last Closed||2011-08-02 03:39:53

--- Comment #7 from Marcela Mašláňová mmasl...@redhat.com 2011-08-02 03:39:53 
EDT ---


*** This bug has been marked as a duplicate of bug 695584 ***

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 695597] Providing native systemd file for upcoming F15 Feature Systemd

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Jóhann B. Guðmundsson johan...@hi.is changed:

   What|Removed |Added

 Status|CLOSED  |ASSIGNED
 Resolution|DUPLICATE   |
   Keywords||Reopened

--- Comment #4 from Jóhann B. Guðmundsson johan...@hi.is 2011-08-02 05:15:15 
EDT ---
Triager please do some proper research before closing bugs as duplicates this
report contains the native systemd service files for amavisd snmp daemon

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 695584] Providing native systemd file for upcoming F15 Feature Systemd

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Jóhann B. Guðmundsson johan...@hi.is changed:

   What|Removed |Added

 CC||jsafr...@redhat.com
  Component|amavisd-new |net-snmp
 AssignedTo|st...@silug.org |jsafr...@redhat.com

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 695589] Providing native systemd file for upcoming F15 Feature Systemd

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #9 from Marcela Mašláňová mmasl...@redhat.com 2011-08-02 06:35:37 
EDT ---
You might pay more attention to creating bugs. Three bugs with same summary on
same component is confusing.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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-DBD-XBase/f16] Rebase to 1.03.

2011-08-02 Thread Jan Pazdziora

commit 91963f87ae1b925f08190a781646c84e9459605e
Author: Jan Pazdziora jpazdzi...@redhat.com
Date:   Tue Aug 2 14:50:56 2011 +0200

Rebase to 1.03.

(cherry picked from commit 023bcc6630ac4480b121cf90da53fe6c0fb415d8)

 .gitignore   |2 +-
 DBD-XBase-0.241-dbfdump-rename.patch |  593 --
 perl-DBD-XBase.spec  |   19 +-
 sources  |2 +-
 4 files changed, 15 insertions(+), 601 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e0ae989..87d6a19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-DBD-XBase-0.241.tar.gz
+DBD-XBase-1.03.tar.gz
diff --git a/perl-DBD-XBase.spec b/perl-DBD-XBase.spec
index fe3aa2a..2805516 100644
--- a/perl-DBD-XBase.spec
+++ b/perl-DBD-XBase.spec
@@ -1,14 +1,13 @@
 Name:   perl-DBD-XBase
-Version:0.241
-Release:14%{?dist}
+Version:1.03
+Release:1%{?dist}
 Summary:Perl module for reading and writing the dbf files
 
 Group:  Development/Libraries
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/DBD-XBase/
-Source0:
http://www.cpan.org/authors/id/J/JA/JANPAZ/DBD-XBase-%{version}.tar.gz
+URL:http://www.adelton.com/perl/DBD-XBase/
+Source0:
http://www.adelton.com/perl/DBD-XBase/DBD-XBase-%{version}.tar.gz
 Patch0: DBD-XBase-0.241-indexdump.PL.patch
-Patch1: DBD-XBase-0.241-dbfdump-rename.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildArch:  noarch
@@ -28,9 +27,14 @@ DBI modules and their man pages.
 %prep
 %setup -q -n DBD-XBase-%{version}
 %patch0 -p1
-%patch1 -p1
 chmod a-x eg/*table
 
+# We want to distribute dbfdump.pl, not dbfdump
+find . -type f | xargs %{__perl} -i.theorig -pe 
's/(?!\$)\bdbfdump/dbfdump.pl/g'
+find . -type f -name '*.theorig' | %{__perl} -pe 's/\.theorig$//' | while read 
i ; do touch -r $i.theorig $i ; done
+find . -type f -name '*.theorig' -exec rm -f {} ';'
+mv bin/dbfdump.PL bin/dbfdump.pl.PL
+
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
@@ -64,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Tue Aug  2 2011 Jan Pazdziora jpazdzi...@redhat.com - 1.03-1
+- Rebase to 1.03.
+
 * Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.241-14
 - Perl mass rebuild
 
diff --git a/sources b/sources
index d94aedd..7c159e1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ed36f8722f09406d35c8af801fa78c3b  DBD-XBase-0.241.tar.gz
+cbfae03a28dcae0aa0d00bec60ca710d  DBD-XBase-1.03.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 726998] bioperl 1.6.9 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #1 from Jack Tanner i...@hotmail.com 2011-08-02 11:35:00 EDT ---
Created attachment 516343
  -- https://bugzilla.redhat.com/attachment.cgi?id=516343
BioPerl paths patch, updated for 1.6.901

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 726998] bioperl 1.6.9 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #2 from Jack Tanner i...@hotmail.com 2011-08-02 11:35:40 EDT ---
Created attachment 516346
  -- https://bugzilla.redhat.com/attachment.cgi?id=516346
New paths patch for BioPerl-Run

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 726998] bioperl 1.6.9 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #3 from Jack Tanner i...@hotmail.com 2011-08-02 11:42:37 EDT ---
Created attachment 516350
  -- https://bugzilla.redhat.com/attachment.cgi?id=516350
BioPerl spec, updated for 1.6.901

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 726998] bioperl 1.6.9 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #4 from Jack Tanner i...@hotmail.com 2011-08-02 11:43:20 EDT ---
Created attachment 516351
  -- https://bugzilla.redhat.com/attachment.cgi?id=516351
BioPerl-Run spec, updated for 1.006900

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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 726998] bioperl 1.6.9 is available