Re: PokerTH orphaned
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. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On 07/27/2011 09:39 PM, Michael Schwendt wrote: On Wed, 27 Jul 2011 09:19:08 -0700, JK (Jesse) wrote: On 7/27/11 2:03 AM, Michael Schwendt wrote: There is a big difference between a package going backwards in its EVR and staying there and a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed. If it goes backwards to await a fix, that fix needs to be happening within the same day or so. Panu has mentioned that he will be looking into fixing this unexpected breakage. If that isn't acceptable to you, feel free to provide a fix faster. Rawhide now has rpm 4.9.1.1 which should fix the regressions. Apologies for taking so long with it, I didn't expect to be this busy AFK just like I did not expect such breakage with the 4.9.1 release. If further breakage is spotted (I certainly hope not, but...), untag and ping ffesti and jnovy in addition to me. Not prolonged so that updates fail on users' systems. Do they fail in this case? Do you prefer rpm-build in koji buildroot to fail even longer? An issue with rpm-build on Rawhide installations is minor compared with Fedora's offical buildsys. In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build. We are trying very hard to kill the notion that rawhide may eat babies. It's non-productive. There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground. Take off your pink glasses. Rawhide *is* a dumping ground. It breaks users' installations regularly because of package maintainers using it as exactly that, a dumping ground for potentially untested builds. In this case, nobody's system was at risk of being eaten alive, these issues only affected rpmbuild. Obviously rpm generating buggy packages is bad enough as it affects everything and the world, but sometimes s*** just happens no matter how much testing gets done before a release. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: ipython-0.11 breaking anything :)
Thomas Spura 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 Missing packages (maybe more): python-matplotlib scipy Dear dependant package maintainers please test the new ipython with your package and let me know, if it works well, so we could add it also into f16... For more information about this new, exciting release see: http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html Happy testing, Tom I'm happily using ipython-0.11 of F15. No problems other than needing to fix my .matplotlibrc file. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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 :)
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+
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
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 :)
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
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/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
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
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?
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
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/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*
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
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
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.
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
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 #5 from Jack Tanner i...@hotmail.com 2011-08-02 11:47:25 EDT --- The above specs and patches allow BioPerl 1.6.901 and BioPerl-Run 1.006900, latest as of today, to build and install on RHEL 6. The specs are crude and will require much further linting, but it took me a while to even get this far, so perhaps this will be a useful starting point. Note that the BioPerl-Run version number underwent a change of format, and is now less than the number of the previous version. -- 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
String Freeze 2011-08-02
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-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce