Re: Need Little IT advice Here...
On Thu, Aug 11, 2011 at 8:58 PM, Manuel Escudero jmlev...@gmail.com wrote: Hi, I was Wondering if there was a tool for Linux in general that let me undo the system changes at reboot or something like that, For example: I want to set a standard configuration in a machine and then let that machine to be used by many users, but as soon as the user Log Out (preferably in that moment) Why not keep a known good home directory on hand, and replace it on logout? With KDE it's as easy as: cat /home/kioskuser/.kde/shutdown/reset-home.sh #!/bin/sh rm -rf $HOME/* cp -pr /usr/local/share/kioskuser-home/* $HOME ^D chmod +x /home/kioskuser/.kde/shutdown/reset-home.sh Other desktops should have similar functionality. I want the machine to undo all the possible changes the user may have done while he/she was using it. I've seen this behavior on Windows Machines in Schools and Offices, and I know it has something to do about a server controlling all the individual computers but I want to apply that behavior to a Single Linux computer without having the server in the middle... If there's not a General Linux Tool I would like to Know wich distro and desktop enviroment are the best choice to get this done, using what tools, P.S. it's like... Having a customized LiveCD Behavior but with the system installed, so if I need to do changes, I can ensure I can do them without many problems, and then Lock the system again... Hope somebody knows, Thanks! -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick Blogger: Blog Xenode PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com - Conéctate a Tu Mundo -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On Thu, 2011-08-11 at 19:40 -0400, Doug Ledford wrote: I've never got around to working up a coherent proposed modification and submitting it, though - if anyone else can, that'd be great. I'll just go back to what I've said before. I don't care what system you create as long as there is something/someone responsible and accountable for getting things unblocked. Right now there is no one/thing responsible and accountable for getting things approved and you nag the one person who doesn't have the ability to do it. That's just flat backwards. I'm not sure what kind of a 'you' that was, but it ain't my job, mate ;) - FESCo came up with the current update approval process. Anyone can propose a change to it, you have as much standing as me (if not more) to do that. FESCo would have to discuss and approve it. The reason why the package maintainer gets nagged has been explained several times: part of the theory behind the current process is that it is, to some extent, your responsibility as a package maintainer to ensure your package gets tested. You can't perform the testing, but it's reasonably likely that you would be (or, at least, *could* be) in touch with people who could, and could contact them and encourage them to do the testing. -- 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: To Require or not to Require?
Michael Schwendt mschwe...@gmail.com writes: So, where are we now? yum install bar doesn't update foo-libs automagically. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On 08/12/2011 10:28 AM, Adam Williamson wrote: The reason why the package maintainer gets nagged has been explained several times: part of the theory behind the current process is that it is, to some extent, your responsibility as a package maintainer to ensure your package gets tested. You can't perform the testing, but it's reasonably likely that you would be (or, at least, *could* be) in touch with people who could, and could contact them and encourage them to do the testing. We could use a little help from Bodhi here: If people were able to sign up to get notifications for their favourite packages, that might help get some additional testing done. As it is right now, I am guessing that people often aren't even aware that an app they would like to test has a new build available in updates-testing. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need Little IT advice Here...
On Fri, 2011-08-12 at 00:05 -0700, T.C. Hollingsworth wrote: On Thu, Aug 11, 2011 at 8:58 PM, Manuel Escudero jmlev...@gmail.com wrote: Hi, I was Wondering if there was a tool for Linux in general that let me undo the system changes at reboot or something like that, For example: I want to set a standard configuration in a machine and then let that machine to be used by many users, but as soon as the user Log Out (preferably in that moment) Why not keep a known good home directory on hand, and replace it on logout? With KDE it's as easy as: cat /home/kioskuser/.kde/shutdown/reset-home.sh #!/bin/sh rm -rf $HOME/* cp -pr /usr/local/share/kioskuser-home/* $HOME ^D chmod +x /home/kioskuser/.kde/shutdown/reset-home.sh Other desktops should have similar functionality. Looking at this, btrfs' snapshots come to my mind. I think it could be easy to use for this case (just a simple init script [or sytemd unit file]). See https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots for more details. Vratislav Podzimek I want the machine to undo all the possible changes the user may have done while he/she was using it. I've seen this behavior on Windows Machines in Schools and Offices, and I know it has something to do about a server controlling all the individual computers but I want to apply that behavior to a Single Linux computer without having the server in the middle... If there's not a General Linux Tool I would like to Know wich distro and desktop enviroment are the best choice to get this done, using what tools, P.S. it's like... Having a customized LiveCD Behavior but with the system installed, so if I need to do changes, I can ensure I can do them without many problems, and then Lock the system again... Hope somebody knows, Thanks! -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick Blogger: Blog Xenode PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com - Conéctate a Tu Mundo -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review request - yourls
- Original Message - From: Martin Krizek mkri...@redhat.com To: t...@lists.fedoraproject.org, devel@lists.fedoraproject.org Sent: Wednesday, August 3, 2011 2:19:20 PM Subject: Package review request - yourls Hello all, I packaged yourls (http://yourls.org/), a url shortening service that can be run at one's own server, https://bugzilla.redhat.com/show_bug.cgi?id=726131. We, in AutoQA (http://fedoraproject.org/wiki/AutoQA), would really appreciate if someone could review this package. We are going to use this for shortening test result urls. And since this is my first package I need a sponsor as well. Still no one interested? Thanks, Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On 08/12/2011 09:40 AM, Kalev Lember wrote: On 08/12/2011 10:28 AM, Adam Williamson wrote: The reason why the package maintainer gets nagged has been explained several times: part of the theory behind the current process is that it is, to some extent, your responsibility as a package maintainer to ensure your package gets tested. You can't perform the testing, but it's reasonably likely that you would be (or, at least, *could* be) in touch with people who could, and could contact them and encourage them to do the testing. We could use a little help from Bodhi here: If people were able to sign up to get notifications for their favourite packages, that might help get some additional testing done. As it is right now, I am guessing that people often aren't even aware that an app they would like to test has a new build available in updates-testing. Perhaps an idea for the new fedora community platform? You could perhaps like some packages and receive all related information about them. Don't know if this is possible... Just an idea! Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, 12 Aug 2011 09:32:26 +0200, AS (Andreas) wrote: So, where are we now? yum install bar doesn't update foo-libs automagically. Which is why you may benefit from an explicit dependency *if* you publish such an updated bar that needs a specific minimum version of foo-libs: http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires In this thread Paul has given a real-world example: https://bugzilla.redhat.com/show_bug.cgi?id=642796 $ rpm -qR libcurl|grep ssh libssh2(x86-64) = 1.2.7 libssh2.so.1()(64bit) Such explicit deps are neither the norm nor mandatory. In Fedora-land, a full yum update (or the equivalent thereof with a different tool) is needed frequently anyway because of the updates-flood and because of yum install not considering newest packages only. It isn't any secret that Fedora users encounter lots of dep problems when installing without updating frequently. Back to subpackages. I could repeat my 1st reply in this thread, but let's see. We try to keep builds from the same src.rpm (and not limited to that) in sync for various reasons. Not just because a program/extension included in a subpkg may strictly require the very latest base pkg. Or vice versa (the guidelines even mention the pitfall of creating a circular dep): https://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage A foo.src.rpm that builds libs *and* programs doesn't need to be split into several packages. It could also be split into foo + foo-utils or libfoo + foo, and the naming scheme doesn't change which is the base pkg and which is the subpkg. So, if the build creates multiple subpackages, you *could* treat the libs pkg like a separate/external build. However, library subpkg builds are special because they build from the same src.rpm, with no risk that the library package will change its name and break the explicit subpkg dep created within the same package set, with no versioned BuildRequires on an external library package, with no configure script checking for a minimum library version - any programs built within the same src.rpm may immediately use this very latest lib API. So, what is safer? * To treat a foo-libs subpackage like a base package and have foo (or e.g. foo-utils) depend on it with full NEVR? * Or to treat it like an ordinary/individual library package with just the automatic SONAME dep and reconsider an explicit dep only when building against new library updates? http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
Michael Schwendt mschwe...@gmail.com writes: So, what is safer? Neither fixes the missing symbol. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, 12 Aug 2011 12:12:15 +0200, AS (Andreas) wrote: So, what is safer? Neither fixes the missing symbol. There is no missing symbol. Be more verbose. Your very brief replies don't give enough context. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
Michael Schwendt mschwe...@gmail.com writes: There is no missing symbol. Of course there is. See http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/152427. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Unicode-Casing-0.08.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Unicode-Casing: 11104e2aeecdaf256a8ddba7c61666d4 Unicode-Casing-0.08.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
[perl-Unicode-Casing] 0.08 bump
commit 134313ff5fd5a45110c71f2606fc2e18f6b29f50
Author: Petr Sabata con...@redhat.com
Date: Fri Aug 12 13:01:43 2011 +0200
0.08 bump
.gitignore |1 +
perl-Unicode-Casing.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 73a30d6..ad57800 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Unicode-Casing-0.07.tar.gz
+/Unicode-Casing-0.08.tar.gz
diff --git a/perl-Unicode-Casing.spec b/perl-Unicode-Casing.spec
index 9d5d77a..ced5876 100644
--- a/perl-Unicode-Casing.spec
+++ b/perl-Unicode-Casing.spec
@@ -1,7 +1,7 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Unicode-Casing
-Version:0.07
-Release:2%{?dist}
+Version:0.08
+Release:1%{?dist}
Summary:Perl extension to override system case changing functions
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Aug 12 2011 Petr Sabata con...@redhat.com - 0.08-1
+- 0.08 bump
+
* Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.07-2
- Perl mass rebuild
diff --git a/sources b/sources
index 296be64..a5becf9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-335647cf4a966f86f0ee6e8f2bc4ab13 Unicode-Casing-0.07.tar.gz
+11104e2aeecdaf256a8ddba7c61666d4 Unicode-Casing-0.08.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: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On 08/10/2011 03:02 PM, Doug Ledford wrote: Can we please either disable these nag messages or give developers the ability to push a package regardless of testing when it reaches nag age? I'm getting the same mail for some time now for my critpath security update. I'm just wondering how long it takes before update reaches users, so I'm not going to beg any proventester for help this time (yet). On 08/12/2011 09:28 AM, Adam Williamson wrote: - FESCo came up with the current update approval process. Anyone can propose a change to it, you have as much standing as me (if not more) to do that. FESCo would have to discuss and approve it. We've seen this flame^Wdiscussion already and my experience says: don't bother with it. Add mail filtering rule to delete this mail. It's more efficient way you can spent your time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, 12 Aug 2011 13:00:57 +0200, AS (Andreas) wrote: There is no missing symbol. Of course there is. See http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/152427. No, there isn't, because of a subpackage dependency with full NEVR, even if that may not be needed as a default. Elsewhere in this thread, Rex Dieter has also recommended that one with this rationale: | Since it's a subpkg from the same srpm, I'd opt to be on the safe side, | and add an explicit versioned Requires So, I think I understand your mission now. You're either just practising some troll skills or pedantry. :-/ The separate bar package still is entirely irrelevant up to the point when it is updated/upgraded and actually needs new symbols found only in a latest library update. Then we're back at https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires and you're free to act accordingly. If you prefer Explicit Library NEVR Requires in _all_ packages, take that up with the packaging committee. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On Thu, Aug 11, 2011 at 5:32 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2011-08-10 at 09:02 -0400, Doug Ledford wrote: Can we please either disable these nag messages or give developers the ability to push a package regardless of testing when it reaches nag age? You have that ability for non-critpath updates, but for critpath the thought is that updates really need to get tested before they go out. I've said a few times that I think this could be adjusted for old releases, on practical grounds. It makes no sense in theory - if anything, the testing requirements for old releases should be *tighter*, as there's a greater expectation of stability - but in practice, we just don't have the test coverage for old releases. Either not many people run them, or those who do just aren't interested in running updates-testing and providing feedback. One thing I noticed was with the updates reports is that the old updates disappear off the report so in some cases people aren't even aware they might need testing. It would be good to have an old_testing section so people are actually aware that they need testing. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110812 changes
Compose started at Fri Aug 12 08:15:20 UTC 2011 Broken deps for x86_64 -- 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) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) 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 cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(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) 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 emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.i686 requires libboost_system-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_serialization-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_filesystem-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_serialization-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) garden-1.0.8-3.fc15.x86_64 requires liballeg.so.4.2()(64bit) glom-1.18.3-1.fc16.x86_64 requires libepc-1.0.so.2()(64bit) glom-libs-1.18.3-1.fc16.i686 requires libepc-1.0.so.2 glom-libs-1.18.3-1.fc16.x86_64 requires libepc-1.0.so.2()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libupnp.so.3()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libthreadutil.so.2()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
Re: Need Little IT advice Here...
xguest is the way to do this because it involves much more than simply wiping the hard drive. xguest also locks down the account with selinux so that the vector for attacks is quite minimal. On Fri, Aug 12, 2011 at 3:21 AM, Dave Quigley seli...@davequigley.com wrote: You should look into the xguest package on Fedora. It provides a sandboxed user which gets wiped on logout. If you need to add more tools for the guest to use I'd suggest contacting Dan Walsh for additional help since he is the maintainer. Dave On 8/11/2011 11:58 PM, Manuel Escudero wrote: Hi, I was Wondering if there was a tool for Linux in general that let me undo the system changes at reboot or something like that, For example: I want to set a standard configuration in a machine and then let that machine to be used by many users, but as soon as the user Log Out (preferably in that moment) I want the machine to undo all the possible changes the user may have done while he/she was using it. I've seen this behavior on Windows Machines in Schools and Offices, and I know it has something to do about a server controlling all the individual computers but I want to apply that behavior to a Single Linux computer without having the server in the middle... If there's not a General Linux Tool I would like to Know wich distro and desktop enviroment are the best choice to get this done, using what tools, P.S. it's like... Having a customized LiveCD Behavior but with the system installed, so if I need to do changes, I can ensure I can do them without many problems, and then Lock the system again... Hope somebody knows, Thanks! -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick http://twitter.com/Jmlevick Blogger: Blog Xenode http://xenodesystems.blogspot.com/ PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ - Conéctate a Tu Mundo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, 12 Aug 2011 14:30:46 +0200, Andreas Schwab sch...@redhat.com wrote: The separate bar package still is entirely irrelevant It kills your entire argument. Andreas. It still doesn't. libfoo update would need to come first. First come, first served. And what packaging techniques to apply in the libfoo update has been the topic of this thread: | I have a package (keyutils) that produces three RPMs: keyutils | (programs), keyutils-libs and keyutils-devel. | | ... | | So does the keyutils rpm need an explicit Requires on the keyutils-libs | rpm in the specfile or is the implicit library dependency sufficient? Whether any other update built against libfoo would also benefit from an explicit dep is covered by the guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/152426 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need Little IT advice Here...
On fre, 2011-08-12 at 00:05 -0700, T.C. Hollingsworth wrote: Why not keep a known good home directory on hand, and replace it on logout? Though you still have the user's files in other locations on disk. It'd be better to just create a new user for each login. Or xguest, or LVM or btrfs snapshots. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Test-Mojibake-0.3.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Mojibake: 6387414378fc302582d7955e61f132e3 Test-Mojibake-0.3.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: To Require or not to Require?
Michael Schwendt mschwe...@gmail.com writes: libfoo update would need to come first. How? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conflict in packages in fedora 15
On Fri, 12 Aug 2011 02:29:14 +0300, MA (Muayyad) wrote: hello, what is the reason for this Transaction Check Error: file /lib/firmware/phanfw.bin from install of netxen-firmware-4.0.534-4.fc15.noarch conflicts with file from package linux-firmware-20110601-1.fc15.noarch It's an implicit conflict, which means that a file with the same path but different checksums is included in both packages. Implicit conflicts ( instead of explicit Conflicts: tags) often are accidents. A newer build of the linux-firmware package mentions a fix, however, on Aug 4th: http://koji.fedoraproject.org/koji/buildinfo?buildID=257227 and what requires netxen-firmware $ repoquery --whatrequires netxen-firmware netxen-firmware-0:4.0.534-4.fc15.noarch $ yum info netxen-firmware|grep Summ Summary : QLogic Linux Intelligent Ethernet (3000 and 3100 Series) Adapter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-CPAN-Meta-JSON/f15] Initial import (perl-Test-CPAN-Meta-JSON-0.10-2)
Summary of changes: 815cd6c... Initial import (perl-Test-CPAN-Meta-JSON-0.10-2) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: To Require or not to Require?
On Fri, 12 Aug 2011 15:54:45 +0200, Andreas Schwab sch...@redhat.com wrote: libfoo update would need to come first. How? Andreas. If you're serious about discussing this further, show that. I'm not going to reply to this thread anymore before tomorrow. With your single-word reply you [once again] demonstrate that we're likely talking past eachother. Perhaps it's due to language barriers or attitude. Dunno. I don't want to read between the lines to guess whether you understand the sentence you've quoted above. I think you've misunderstood it. You sound as if you now refer to the process of installing package updates rather than preparing and releasing packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Extract-VERSION/el4] Initial import (perl-Module-Extract-VERSION-1.01-3)
Summary of changes: 9d8959e... Initial import (perl-Module-Extract-VERSION-1.01-3) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-CPAN-Meta-JSON/f14] Initial import (perl-Test-CPAN-Meta-JSON-0.10-2)
Summary of changes: 815cd6c... Initial import (perl-Test-CPAN-Meta-JSON-0.10-2) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Mojibake] Initial import (perl-Test-Mojibake-0.3-2)
commit 43d4f14ea49c89102508d61f443de0203f44090c
Author: Paul Howarth p...@city-fan.org
Date: Fri Aug 12 14:52:55 2011 +0100
Initial import (perl-Test-Mojibake-0.3-2)
Many modern text editors automatically save files using UTF-8 codification.
However, the perl interpreter does not expect it by default. Whilst this
does
not represent a big deal on (most) backend-oriented programs, Web framework
(Catalyst, Mojolicious) based applications will suffer so-called Mojibake
(literally: unintelligible sequence of characters). Even worse: if an
editor
saves BOM (Byte Order Mark, U+FEFF character in Unicode) at the start of a
script with the executable bit set (on Unix systems), it won't execute at
all,
due to shebang corruption.
Avoiding codification problems is quite simple:
* Always use utf8/use common::sense when saving source as UTF-8
* Always specify =encoding utf8 when saving POD as UTF-8
* Do neither of above when saving as ISO-8859-1
* Never save BOM (not that it's wrong; just avoid it as you'll barely
notice its presence when in trouble)
However, if you find yourself upgrading old code to use UTF-8 or trying to
standardize a big project with many developers, each one using a different
platform/editor, reviewing all files manually can be quite painful,
especially
in cases where some files have multiple encodings (note: it all started
when I
realized that gedit and derivatives are unable to open files with character
conversion tables).
Enter the Test::Mojibake ;)
.gitignore |1 +
Test-Mojibake-0.3-old-Test::More.patch | 51 +++
Test-Mojibake-0.3-old-eu::mm.patch | 30 +++
perl-Test-Mojibake.spec| 148
sources|1 +
5 files changed, 231 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..a59e0cc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Test-Mojibake-[0-9.]*.tar.gz
diff --git a/Test-Mojibake-0.3-old-Test::More.patch
b/Test-Mojibake-0.3-old-Test::More.patch
new file mode 100644
index 000..deea6fe
--- /dev/null
+++ b/Test-Mojibake-0.3-old-Test::More.patch
@@ -0,0 +1,51 @@
+--- Test-Mojibake-0.3/t/06-pp-vs-xs.t
Test-Mojibake-0.3/t/06-pp-vs-xs.t
+@@ -1,7 +1,7 @@
+ #!perl -T
+ use strict;
+
+-use Test::More;
++use Test::More 'no_plan';
+
+ BEGIN {
+ use_ok('Benchmark', 'countit');
+@@ -10,7 +10,6 @@
+
+ unless ($Test::Mojibake::use_xs) {
+ diag('No XS module detected, will fallback to PP implementation!');
+-done_testing(2);
+ exit;
+ }
+
+@@ -33,8 +32,6 @@
+
+ diag(sprintf('XS/PP speed ratio is %0.2f', $t0-iters / $t1-iters));
+
+-done_testing(7);
+-
+ sub run {
+ my $i = 0;
+ for (@buf) {
+--- Test-Mojibake-0.3/t/release-cpan-changes.t
Test-Mojibake-0.3/t/release-cpan-changes.t
+@@ -1,15 +1,11 @@
+ #!perl
+
++use Test::More;
++
+ BEGIN {
+- unless ($ENV{RELEASE_TESTING}) {
+-require Test::More;
+-Test::More::plan(skip_all = 'these tests are for release candidate
testing');
+- }
++ plan skip_all = 'these tests are for release candidate testing' unless
($ENV{RELEASE_TESTING});
++ eval 'use Test::CPAN::Changes';
++ plan skip_all = 'Test::CPAN::Changes required for this test' if $@;
+ }
+
+-
+-use Test::More;
+-eval 'use Test::CPAN::Changes';
+-plan skip_all = 'Test::CPAN::Changes required for this test' if $@;
+ changes_ok();
+-done_testing();
diff --git a/Test-Mojibake-0.3-old-eu::mm.patch
b/Test-Mojibake-0.3-old-eu::mm.patch
new file mode 100644
index 000..15a5b82
--- /dev/null
+++ b/Test-Mojibake-0.3-old-eu::mm.patch
@@ -0,0 +1,30 @@
+--- Test-Mojibake/Makefile.PL
Test-Mojibake/Makefile.PL
+@@ -4,7 +4,7 @@
+
+
+
+-use ExtUtils::MakeMaker 6.30;
++use ExtUtils::MakeMaker;
+
+
+
+@@ -13,7 +13,7 @@
+ 'AUTHOR' = 'Stanislaw Pusep s...@sysd.org',
+ 'BUILD_REQUIRES' = {},
+ 'CONFIGURE_REQUIRES' = {
+-'ExtUtils::MakeMaker' = '6.30'
++'ExtUtils::MakeMaker' = '0'
+ },
+ 'DISTNAME' = 'Test-Mojibake',
+ 'EXE_FILES' = [],
+@@ -46,6 +46,9 @@
+ delete $WriteMakefileArgs{CONFIGURE_REQUIRES}
+ unless eval { ExtUtils::MakeMaker-VERSION(6.52) };
+
++delete $WriteMakefileArgs{LICENSE}
++ unless eval { ExtUtils::MakeMaker-VERSION(6.31) };
++
+ WriteMakefile(%WriteMakefileArgs);
+
+
diff --git a/perl-Test-Mojibake.spec b/perl-Test-Mojibake.spec
new file mode 100644
index 000..733cd0a
--- /dev/null
+++ b/perl-Test-Mojibake.spec
@@ -0,0 +1,148 @@
+# We don't really need ExtUtils::MakeMaker ≥ 6.30
+%global old_eumm %(perl -MExtUtils::MakeMaker -e 'printf %d\\n,
$ExtUtils::MakeMaker::VERSION 6.30 ? 1 : 0;' 2/dev/null || echo 0)
+
+# We need to patch the test suite if we have an old version of Test::More
+%global old_test_more %(perl -MTest::More -e 'printf %d\\n,
$Test::More::VERSION 0.88 ? 1 : 0;' 2/dev/null || echo 0)
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 02:30:46PM +0200, Andreas Schwab wrote: Michael Schwendt mschwe...@gmail.com writes: The separate bar package still is entirely irrelevant It kills your entire argument. AFAICS, your insistance that it is a blocker means that you aren't seeing something correctly. -Toshio pgp585U5GFWbP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Extract-VERSION] Created tag perl-Module-Extract-VERSION-1.01-3.el4
The lightweight tag 'perl-Module-Extract-VERSION-1.01-3.el4' was created pointing to: 9d8959e... Initial import (perl-Module-Extract-VERSION-1.01-3) -- 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
[perl-Module-Extract-VERSION] Created tag perl-Module-Extract-VERSION-1.01-3.el6
The lightweight tag 'perl-Module-Extract-VERSION-1.01-3.el6' was created pointing to: 9d8959e... Initial import (perl-Module-Extract-VERSION-1.01-3) -- 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
[perl-Module-Extract-VERSION] Created tag perl-Module-Extract-VERSION-1.01-3.fc14
The lightweight tag 'perl-Module-Extract-VERSION-1.01-3.fc14' was created pointing to: 9d8959e... Initial import (perl-Module-Extract-VERSION-1.01-3) -- 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
[perl-Module-Extract-VERSION] Created tag perl-Module-Extract-VERSION-1.01-3.fc15
The lightweight tag 'perl-Module-Extract-VERSION-1.01-3.fc15' was created pointing to: 9d8959e... Initial import (perl-Module-Extract-VERSION-1.01-3) -- 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
[perl-Module-Extract-VERSION] Created tag perl-Module-Extract-VERSION-1.01-3.fc16
The lightweight tag 'perl-Module-Extract-VERSION-1.01-3.fc16' was created pointing to: 9d8959e... Initial import (perl-Module-Extract-VERSION-1.01-3) -- 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: To Require or not to Require?
Your whole argument is just void. There is not a single difference between external packages and (sub-)packages. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Extract-VERSION] Created tag perl-Module-Extract-VERSION-1.01-3.fc17
The lightweight tag 'perl-Module-Extract-VERSION-1.01-3.fc17' was created pointing to: 9d8959e... Initial import (perl-Module-Extract-VERSION-1.01-3) -- 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
[perl-Test-CPAN-Meta-JSON/el6] Initial import (perl-Test-CPAN-Meta-JSON-0.10-2)
Summary of changes: 815cd6c... Initial import (perl-Test-CPAN-Meta-JSON-0.10-2) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Mojibake/f16] Initial import (perl-Test-Mojibake-0.3-2)
Summary of changes: 43d4f14... Initial import (perl-Test-Mojibake-0.3-2) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: To Require or not to Require?
Miloslav Trmač m...@volny.cz writes: There is one difference: with subpackages it is trivial to write a Requires: that 1) is always strict enough and 2) is always satisfied. For external packages achieving both requires non-trivial human effort. Yet you insist that your external package is always working. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 and mount points
Am 12.08.2011 00:43, schrieb Tom H: Seems this is a known *feature* of F-15 and no one is all that interested in changing it. Unfortunately, I have a good number of scripts that use the output of df and mount that would need modified for this. The /var/tmp mount is especially troubling... I thought that their outputs, especially that of findmnt, would've clarified the output of mount, except for the three sandbox bind mounts. Suggestions for replacing mount in your scripts: findmnt -lnu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -lnsu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -T / findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -T / this does not solve the problem with thousands of applications like df, mlocate and mount: if a change forces a lot of programs and scripts to be changed anybody who made it is a little naive to believe the world is turning around him and should hurry up fixing all this apllications he broke or revert his change! https://bugzilla.redhat.com/show_bug.cgi?id=709351 https://bugzilla.redhat.com/show_bug.cgi?id=730138 https://bugzilla.redhat.com/show_bug.cgi?id=723279 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 04:18:34PM +0200, Miloslav Trmač wrote: On Fri, Aug 12, 2011 at 4:15 PM, Andreas Schwab sch...@redhat.com wrote: Your whole argument is just void. There is not a single difference between external packages and (sub-)packages. There is one difference: with subpackages it is trivial to write a Requires: that 1) is always strict enough and 2) is always satisfied. For external packages achieving both requires non-trivial human effort. Not at all. The simplest thing to do is to ensure that any binary depends on at least the version of any libraries it was linked against, which is the way Debian handle this in the absence of maintainer overrides. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 and mount points
On Fri, Aug 12, 2011 at 10:46:27AM +0200, Reindl Harald wrote: I thought that their outputs, especially that of findmnt, would've clarified the output of mount, except for the three sandbox bind mounts. Suggestions for replacing mount in your scripts: findmnt -lnu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -lnsu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -T / findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -T / this does not solve the problem with thousands of applications like df, mlocate and mount: if a change forces a lot of programs and scripts to be changed anybody who made it is a little naive to believe the world is turning around him and should hurry up fixing all this apllications he broke or revert his change! One of Fedora's core values is “first”. We do introduce new things and instead of reverting them, we fix broken apps. If lot of programs have to be changed – life is hard. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 and mount points
Am 12.08.2011 17:00, schrieb Tomasz Torcz: On Fri, Aug 12, 2011 at 10:46:27AM +0200, Reindl Harald wrote: I thought that their outputs, especially that of findmnt, would've clarified the output of mount, except for the three sandbox bind mounts. Suggestions for replacing mount in your scripts: findmnt -lnu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -lnsu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -T / findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -T / this does not solve the problem with thousands of applications like df, mlocate and mount: if a change forces a lot of programs and scripts to be changed anybody who made it is a little naive to believe the world is turning around him and should hurry up fixing all this apllications he broke or revert his change! One of Fedora's core values is “first”. We do introduce new things and instead of reverting them, we fix broken apps. If lot of programs have to be changed – life is hard who is the we fixing df and when will this happen? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File ORLite-Mirror-1.22.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-ORLite-Mirror: 066119d0eba45875df2b29ee19e5ff84 ORLite-Mirror-1.22.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: To Require or not to Require?
On Fri, Aug 12, 2011 at 04:15:49PM +0200, Andreas Schwab wrote:
Your whole argument is just void. There is not a single difference
between external packages and (sub-)packages.
Here's a couple differences:
(libfoo-1.0 building subpackage foo-utils) is licensed LGPLv2
(libfoo-1.0.1 building subpackage foo-utils) is licensed LGPLv3
Our guidelines let you package the license information in the base package
when the subpackage depends on it. In this case, the subpackage won't pull
in the updated license information based on soname alone.
libfoo-1.0 has private data:
foopublic.h
struct Data {
int public;
void *private;
}
fooprivate.h
struct PrivateData {
[...]
}
Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that
access the PrivateData. Because the utilities are built from the libfoo
source, they can include the fooprivate.h header file and do this. When
libfoo goes to 1.0.1, upstream changes the definition of PrivateData and
updates the utilities to work with the new datastructure. Since the public
ABI stayed the same, the SONAME doesn't change and external programs
compiled against libfoo-1.0 continue to work but the utilities built as
a subpackage would be broken without stricter versioning.
-Toshio
pgp9ThY1dAchg.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 and mount points
On 08/12/2011 11:03 AM, Reindl Harald wrote: Am 12.08.2011 17:00, schrieb Tomasz Torcz: On Fri, Aug 12, 2011 at 10:46:27AM +0200, Reindl Harald wrote: I thought that their outputs, especially that of findmnt, would've clarified the output of mount, except for the three sandbox bind mounts. Suggestions for replacing mount in your scripts: findmnt -lnu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -lnsu -o SOURCE,TARGET,FSTYPE,OPTIONS findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS -T / findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -S /dev/sda1 findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS -T / this does not solve the problem with thousands of applications like df, mlocate and mount: if a change forces a lot of programs and scripts to be changed anybody who made it is a little naive to believe the world is turning around him and should hurry up fixing all this apllications he broke or revert his change! One of Fedora's core values is first. We do introduce new things and instead of reverting them, we fix broken apps. If lot of programs have to be changed -- life is hard who is the we fixing df and when will this happen? Yeah and all those broken apps weren't broken til you introduced your new better thing. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-Emulate-PSGI/el6] * First EPEL6 release (F15 SRPM)
commit a024edea4dc883d413e4fcf0d846d21ea78071f0
Author: Jose Pedro Oliveira j...@di.uminho.pt
Date: Fri Aug 12 16:33:58 2011 +0100
* First EPEL6 release (F15 SRPM)
perl-CGI-Emulate-PSGI.spec |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
---
diff --git a/perl-CGI-Emulate-PSGI.spec b/perl-CGI-Emulate-PSGI.spec
index bb5000f..fbacd56 100644
--- a/perl-CGI-Emulate-PSGI.spec
+++ b/perl-CGI-Emulate-PSGI.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Emulate-PSGI
Version:0.12
-Release:2%{?dist}
+Release:1%{?dist}
Summary:PSGI adapter for CGI applications
License:GPL+ or Artistic
Group: Development/Libraries
@@ -45,9 +45,6 @@ make test
%{_mandir}/man3/*
%changelog
-* Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.12-2
-- Perl mass rebuild
-
* Mon Jun 20 2011 Ralf Corsépius corse...@fedoraproject.org 0.12-1
- Upstream update.
- Remove BuildRoot.
--
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
[perl-CGI-Emulate-PSGI] Created tag perl-CGI-Emulate-PSGI-0.12-1.el6
The lightweight tag 'perl-CGI-Emulate-PSGI-0.12-1.el6' was created pointing to: a024ede... * First EPEL6 release (F15 SRPM) -- 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: To Require or not to Require?
On Fri, Aug 12, 2011 at 08:27:13AM -0700, Toshio Kuratomi wrote: Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that access the PrivateData. Because the utilities are built from the libfoo source, they can include the fooprivate.h header file and do this. When libfoo goes to 1.0.1, upstream changes the definition of PrivateData and updates the utilities to work with the new datastructure. Since the public ABI stayed the same, the SONAME doesn't change and external programs compiled against libfoo-1.0 continue to work but the utilities built as a subpackage would be broken without stricter versioning. Upstream can change the ABI as much as they want without bumping the SONAME providing that the old interfaces are also present. It's entirely possible to end up with a situation where external binaries built against 1.0.1 won't run on 1.0.0 - the problem isn't limited to subpackages. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-ORLite-Mirror] update to 1.22
commit fbf663e917605346c1d3a1bfaedf757c293b2cbd
Author: Iain Arnell iarn...@gmail.com
Date: Fri Aug 12 17:40:53 2011 +0200
update to 1.22
.gitignore |1 +
perl-ORLite-Mirror.spec | 12 ++--
sources |2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a01cae6..2cc9e3e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/ORLite-Mirror-1.20.tar.gz
/ORLite-Mirror-1.21.tar.gz
+/ORLite-Mirror-1.22.tar.gz
diff --git a/perl-ORLite-Mirror.spec b/perl-ORLite-Mirror.spec
index daa1add..dd45193 100644
--- a/perl-ORLite-Mirror.spec
+++ b/perl-ORLite-Mirror.spec
@@ -1,14 +1,11 @@
Name: perl-ORLite-Mirror
-Version:1.21
-Release:2%{?dist}
+Version:1.22
+Release:1%{?dist}
Summary:Extend ORLite to support remote SQLite databases
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/ORLite-Mirror/
Source0:
http://www.cpan.org/authors/id/A/AD/ADAMK/ORLite-Mirror-%{version}.tar.gz
-# add proxy support
-# https://rt.cpan.org/Public/Bug/Display.html?id=61795
-Patch0: rt61795-proxy-support.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::HomeDir) = 0.69
@@ -41,7 +38,6 @@ arbitrary URI in read-only form as well.
%prep
%setup -q -n ORLite-Mirror-%{version}
-%patch0 -p 1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -65,6 +61,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Aug 12 2011 Iain Arnell iarn...@gmail.com 1.22-1
+- update to latest upstream
+- drop proxy patch as proxy support is included now
+
* Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.21-2
- Perl mass rebuild
diff --git a/sources b/sources
index 44bdcc7..8f8992c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f8da3e3dc7b14f6691be9daa8558668f ORLite-Mirror-1.21.tar.gz
+066119d0eba45875df2b29ee19e5ff84 ORLite-Mirror-1.22.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: To Require or not to Require?
On Fri, 2011-08-12 at 16:40 +0100, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 08:27:13AM -0700, Toshio Kuratomi wrote: Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that access the PrivateData. Because the utilities are built from the libfoo source, they can include the fooprivate.h header file and do this. When libfoo goes to 1.0.1, upstream changes the definition of PrivateData and updates the utilities to work with the new datastructure. Since the public ABI stayed the same, the SONAME doesn't change and external programs compiled against libfoo-1.0 continue to work but the utilities built as a subpackage would be broken without stricter versioning. Upstream can change the ABI as much as they want without bumping the SONAME providing that the old interfaces are also present. It's entirely possible to end up with a situation where external binaries built against 1.0.1 won't run on 1.0.0 - the problem isn't limited to subpackages. If rpmbuild does not add an implicit requires with libraryX = version we built against then it is certainly broken. ABI *additions* w/o change of the SONAME happens every day in every library. If you do not want to set a require on the fedora package version, then you could check what is the highest symbol version for all symbols in the lib and require that. Unfortunately not all libraries do symbol versioning so that would not work in many cases. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-FCGI-Client/el6] * First EPEL6 release (based on the F15 SRPM)
commit 3a8621a5b3db4e4bf67045cca20e545a34e980de
Author: Jose Pedro Oliveira j...@di.uminho.pt
Date: Fri Aug 12 17:08:22 2011 +0100
* First EPEL6 release (based on the F15 SRPM)
perl-FCGI-Client.spec |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
---
diff --git a/perl-FCGI-Client.spec b/perl-FCGI-Client.spec
index 1d66d88..748c64d 100644
--- a/perl-FCGI-Client.spec
+++ b/perl-FCGI-Client.spec
@@ -1,7 +1,7 @@
Name: perl-FCGI-Client
Summary:Client library for the fastcgi protocol
Version:0.04
-Release:6%{?dist}
+Release:5%{?dist}.1
# lib/FCGI/Client.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
@@ -18,6 +18,7 @@ BuildRequires: perl(Filter::Util::Call)
BuildRequires: perl(IO::Socket::UNIX)
BuildRequires: perl(Test::More)
BuildRequires: perl(Try::Tiny)
+BuildRequires: perl(Time::HiRes)
%{?perl_default_filter}
@@ -54,8 +55,8 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
-* Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.04-6
-- Perl mass rebuild
+* Fri Aug 12 2011 Jose Pedro Oliveira jpo at di.uminho.pt - 0.04-5.1
+- EPEL6: missing BR perl(Time::HiRes)
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.04-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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
[perl-FCGI-Client] Created tag perl-FCGI-Client-0.04-5.el6.1
The lightweight tag 'perl-FCGI-Client-0.04-5.el6.1' was created pointing to: 3a8621a... * First EPEL6 release (based on the F15 SRPM) -- 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: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On Fri, 2011-08-12 at 11:30 +0200, Michal Hlavinka wrote: On 08/10/2011 03:02 PM, Doug Ledford wrote: Can we please either disable these nag messages or give developers the ability to push a package regardless of testing when it reaches nag age? I'm getting the same mail for some time now for my critpath security update. I'm just wondering how long it takes before update reaches users, so I'm not going to beg any proventester for help this time (yet). Under the current policy, unless you get the necessary karma, it won't ever get out of updates-testing. There's no timeout, or anything. It'll just sit in updates-testing forever. -- 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: To Require or not to Require?
On 08/12/2011 04:40 PM, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 08:27:13AM -0700, Toshio Kuratomi wrote: Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that access the PrivateData. Because the utilities are built from the libfoo source, they can include the fooprivate.h header file and do this. When libfoo goes to 1.0.1, upstream changes the definition of PrivateData and updates the utilities to work with the new datastructure. Since the public ABI stayed the same, the SONAME doesn't change and external programs compiled against libfoo-1.0 continue to work but the utilities built as a subpackage would be broken without stricter versioning. Upstream can change the ABI as much as they want without bumping the SONAME providing that the old interfaces are also present. It's entirely possible to end up with a situation where external binaries built against 1.0.1 won't run on 1.0.0 - the problem isn't limited to subpackages. I think Toshio is talking about the case where the subpackage executables are using things that are explicitly outside of any defined ABI (since they are compiled from the same source tree and have access to non-public headers and types defined within them). In his example PrivateData was never part of the interface that external code using -devel sees. Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It's easy to argue that this is a misuse of the interface or that the interface is inadequate/broken but I'm sure there are packages out there with this problem. Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 04:40:20PM +0100, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 08:27:13AM -0700, Toshio Kuratomi wrote: Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that access the PrivateData. Because the utilities are built from the libfoo source, they can include the fooprivate.h header file and do this. When libfoo goes to 1.0.1, upstream changes the definition of PrivateData and updates the utilities to work with the new datastructure. Since the public ABI stayed the same, the SONAME doesn't change and external programs compiled against libfoo-1.0 continue to work but the utilities built as a subpackage would be broken without stricter versioning. Upstream can change the ABI as much as they want without bumping the SONAME providing that the old interfaces are also present. It's entirely possible to end up with a situation where external binaries built against 1.0.1 won't run on 1.0.0 - the problem isn't limited to subpackages. Sure. But in this case, upstream isn't changing the public ABI. It's a different level of mistake that's being practiced here. -Toshio pgpe8XGzHTC67.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It is in this situation, but there are other situations where depending on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, anything built against it may fail to run against libfoo 1.0. But how will you know that in advance if all you have in your dependencies is the SONAME? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-asa/el6] * First EPEL6 release (F15 SRPM)
commit 9a9e79c474ff3f4e9ac7e8476fcba7dac177d197
Author: Jose Pedro Oliveira j...@di.uminho.pt
Date: Fri Aug 12 17:28:17 2011 +0100
* First EPEL6 release (F15 SRPM)
perl-asa.spec | 19 ++-
sources |2 +-
2 files changed, 11 insertions(+), 10 deletions(-)
---
diff --git a/perl-asa.spec b/perl-asa.spec
index 7d00bb1..123d772 100644
--- a/perl-asa.spec
+++ b/perl-asa.spec
@@ -1,12 +1,14 @@
+
Name: perl-asa
-Version:1.03
-Release:2%{?dist}
+Version:0.02
+Release:8%{?dist}
# see lib/asa.pm
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Lets your class/object say it works like something else
Source:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/asa-%{version}.tar.gz
Url:http://search.cpan.org/dist/asa
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
@@ -39,6 +41,8 @@ class it's not (that is, isn't in @ISA).
make %{?_smp_mflags}
%install
+rm -rf %{buildroot}
+
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
@@ -48,19 +52,16 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null
';'
%check
make test
+%clean
+rm -rf %{buildroot}
+
%files
+%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
-* Mon Jun 20 2011 Marcela Mašláňová mmasl...@redhat.com - 1.03-2
-- Perl mass rebuild
-
-* Sat May 07 2011 Iain Arnell iarn...@gmail.com 1.03-1
-- update to latest upstream version
-- clean up spec for modern rpmbuild
-
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.02-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index decdbde..ef36893 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ad3d82114f569892d65163e8623d50e4 asa-1.03.tar.gz
+b2b0358f0c8548dacdbdaeaa7c9fe5f7 asa-0.02.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
[perl-asa] Created tag perl-asa-0.02-8.el6
The lightweight tag 'perl-asa-0.02-8.el6' was created pointing to: 9a9e79c... * First EPEL6 release (F15 SRPM) -- 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: To Require or not to Require?
On Fri, Aug 12, 2011 at 09:26:33AM -0700, Toshio Kuratomi wrote: On Fri, Aug 12, 2011 at 04:40:20PM +0100, Matthew Garrett wrote: Upstream can change the ABI as much as they want without bumping the SONAME providing that the old interfaces are also present. It's entirely possible to end up with a situation where external binaries built against 1.0.1 won't run on 1.0.0 - the problem isn't limited to subpackages. Sure. But in this case, upstream isn't changing the public ABI. It's a different level of mistake that's being practiced here. What difference does it make? Even if you stick to the public ABI you can't guarantee that a matching SONAME is sufficient. You need to depend on the package version you build against. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Patching config files (or not)
Hi, Should configs files of a package be patched to have settings that make it work more or less out of the box (as far as possible, some setting like DB access etc. just can't be filled in in advance)? I came across a package that defines to use nogroup in its config file as effective group (Fedora has no nogroup, but has group nobody) and defines to put a pid file in /var/run (which fails, as it appears to do that as nobody/nobody when running). Should this config file have been patched to use nobody as group and should the package (for example) include a package-specific directory below /var/run to put its own pid file in (and patch the config file to use this directory for pid files)? Just wondering if it is worth filing bugs against this package because of the above (easy to solve) issues... Cheers, -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Patching config files (or not)
On Fri, 2011-08-12 at 18:50 +0200, Jos Vos wrote: Hi, Should configs files of a package be patched to have settings that make it work more or less out of the box (as far as possible, some setting like DB access etc. just can't be filled in in advance)? I came across a package that defines to use nogroup in its config file as effective group (Fedora has no nogroup, but has group nobody) and defines to put a pid file in /var/run (which fails, as it appears to do that as nobody/nobody when running). Should this config file have been patched to use nobody as group and should the package (for example) include a package-specific directory below /var/run to put its own pid file in (and patch the config file to use this directory for pid files)? Just wondering if it is worth filing bugs against this package because of the above (easy to solve) issues... I think the problem is twofold: if the package as shipped requires the existence of a particular group, it's the responsibility of the packager to ensure that the group exists on the system. So as part of the install scripts (probably in %pre) you need to create the group on the system. That said, it would be best to work with upstream to add a configure option to select the group most appropriate for each platform. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On 8/12/11 12:28 PM, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It is in this situation, but there are other situations where depending on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, anything built against it may fail to run against libfoo 1.0. But how will you know that in advance if all you have in your dependencies is the SONAME? In fairness, this is why rpm elaborates soname dependencies to also include symbol versions. It's a pity that symbol versions are so painful to use that really only glibc makes any effort to do it. Hilariously gcc _does_ let you specify symbol version in a __attribute__ tag, but only on HP/UX on ia64. Thanks for that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On 8/12/2011 1:28 PM, Adam Jackson wrote: On 8/12/11 12:28 PM, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It is in this situation, but there are other situations where depending on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, anything built against it may fail to run against libfoo 1.0. But how will you know that in advance if all you have in your dependencies is the SONAME? In fairness, this is why rpm elaborates soname dependencies to also include symbol versions. It's a pity that symbol versions are so painful to use that really only glibc makes any effort to do it. libibverbs uses symbol versions quite nicely. Hilariously gcc _does_ let you specify symbol version in a __attribute__ tag, but only on HP/UX on ia64. Thanks for that. - ajax -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On 8/12/2011 3:28 AM, Adam Williamson wrote: On Thu, 2011-08-11 at 19:40 -0400, Doug Ledford wrote: I've never got around to working up a coherent proposed modification and submitting it, though - if anyone else can, that'd be great. I'll just go back to what I've said before. I don't care what system you create as long as there is something/someone responsible and accountable for getting things unblocked. Right now there is no one/thing responsible and accountable for getting things approved and you nag the one person who doesn't have the ability to do it. That's just flat backwards. I'm not sure what kind of a 'you' that was, but it ain't my job, mate ;) A sort of rhetorical 'you' as in whoever fixes the process from where it stands ;-) - FESCo came up with the current update approval process. Anyone can propose a change to it, you have as much standing as me (if not more) to do that. FESCo would have to discuss and approve it. The reason why the package maintainer gets nagged has been explained several times: part of the theory behind the current process is that it is, to some extent, your responsibility as a package maintainer to ensure your package gets tested. You can't perform the testing, but it's reasonably likely that you would be (or, at least, *could* be) in touch with people who could, and could contact them and encourage them to do the testing. Theory and practice, especially on n-1 releases, don't seem to match up very well. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 01:28:59PM -0400, Adam Jackson wrote: On 8/12/11 12:28 PM, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It is in this situation, but there are other situations where depending on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, anything built against it may fail to run against libfoo 1.0. But how will you know that in advance if all you have in your dependencies is the SONAME? In fairness, this is why rpm elaborates soname dependencies to also include symbol versions. It's a pity that symbol versions are so painful to use that really only glibc makes any effort to do it. We make use of them in libvirt, via the '-Wl,--version-script=libvirt.syms'. While it is slightly unfortunate to have to specify versions outside the header file definitions, it isn't a significant problem. It is immediately obvious if you forget to add new public APIs to sym file, since you won't be able to link/test against them. So I wouldn't really call symbol versoning painful. What is unfortunate, is that if your library wants to also be maintained on non-Linux platforms, then you can't make full use of the things that glibc's versioning lets you do. eg introducing new APIs with the same name, but different ABI, while not breaking existing linked apps. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, 2011-08-12 at 13:28 -0400, Adam Jackson wrote: On 8/12/11 12:28 PM, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It is in this situation, but there are other situations where depending on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, anything built against it may fail to run against libfoo 1.0. But how will you know that in advance if all you have in your dependencies is the SONAME? In fairness, this is why rpm elaborates soname dependencies to also include symbol versions. It's a pity that symbol versions are so painful to use that really only glibc makes any effort to do it. FWIW: talloc, tdb, tevent, and ldb and all of samba4 also do symbol versioning since recently, thanks to waf build extensions that make it simple to do. Hilariously gcc _does_ let you specify symbol version in a __attribute__ tag, but only on HP/UX on ia64. Thanks for that. [fail] Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F16 Alpha Blocker Bug Review #5 Recap
=== #fedora-bugzappers: F16 Alpha Blocker Bug Review Meeting #5 === Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-08-12/fedora-bugzappers.2011-08-12-17.02.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2011-08-12/fedora-bugzappers.2011-08-12-17.02.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-08-12/fedora-bugzappers.2011-08-12-17.02.log.html Meeting summary --- * roll call (tflink, 17:02:08) * why are we here? (tflink, 17:07:59) * (tflink, 17:08:12) * Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. (tflink, 17:08:31) * LINK: https://fedoraproject.org/wiki/Current_Release_Blockers (tflink, 17:08:43) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (tflink, 17:08:54) * LINK: https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria (tflink, 17:09:05) * https://bugzilla.redhat.com/show_bug.cgi?id=729599 (tflink, 17:10:29) * PartitionException: msdos disk labels do not support partition names. (tflink, 17:10:38) * AGREED: - 729599 - custom partitioning is not part of the alpha release criteria. Re-propose as final blocker - The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above (tflink, 17:17:11) * https://bugzilla.redhat.com/show_bug.cgi?id=729500 (tflink, 17:17:29) * Error while installing updates on Fedora 16 Alpha RC3 (tflink, 17:17:40) * AGREED: - 729500 - Not enough reproductions to make a decision now, will hold off. If this has not been reproduced by next week, will reject as alpha blocker (tflink, 17:20:52) * https://bugzilla.redhat.com/show_bug.cgi?id=728576 (tflink, 17:21:04) * python-imgcreate looks for /selinux which has moved to /sys/fs/selinux (tflink, 17:21:13) * AGREED: - 728576 - RejectedBlocker - Does not hit any of the alpha release criteria and is not preventing official livecd spins (tflink, 17:26:08) * https://bugzilla.redhat.com/show_bug.cgi?id=726029 (tflink, 17:26:45) * [abrt] smolt-1.4.3-4.fc16 + kernel-3.x: smolt.py:283:__init__:TypeError: 'NoneType' object is not subscriptable (tflink, 17:26:55) * AGREED: - 726029 - RejectedNTH - It would be nice to have smolt working for alpha but it could impact firstboot and the risk seems to outweigh the potential benefit (tflink, 17:33:20) * https://bugzilla.redhat.com/show_bug.cgi?id=720070 (tflink, 17:33:54) * AttributeError: 'Iso9660FS' object has no attribute 'labelType' (tflink, 17:34:03) * AGREED: - 720070 - Two reports of being fixed, move to VERIFIED (tflink, 17:35:00) * https://bugzilla.redhat.com/show_bug.cgi?id=720070 (tflink, 17:35:18) * Wrongly SELinux-labelled files in /lib(64) prevent boot of Fedora 16 Alpha RC systems with SELinux enabled (tflink, 17:35:33) * AGREED: - 728863 - Two reports of being fixed, move to VERIFIED (tflink, 17:37:17) * https://bugzilla.redhat.com/show_bug.cgi?id=728863 (tflink, 17:38:18) * using the right bug this time (tflink, 17:38:25) * Wrongly SELinux-labelled files in /lib(64) prevent boot of Fedora 16 Alpha RC systems with SELinux enabled (tflink, 17:38:31) * AGREED: - 728863 - Two reports of being fixed, move to VERIFIED (tflink, 17:38:39) * https://bugzilla.redhat.com/show_bug.cgi?id=728657 (tflink, 17:39:06) * File conflicts in Fedora 16 Alpha RC1: kdesdk (kdesdk-libs not correctly obsoleted?) (tflink, 17:39:21) * AGREED: - 728657 - confirmed as fixed; move to VERIFIED (tflink, 17:40:34) * https://bugzilla.redhat.com/show_bug.cgi?id=723666 (tflink, 17:40:55) * libreport-python-2.0.5 FILE conflicts with report-gtk-0.23 (tflink, 17:41:06) * AGREED: - 723666 - issue is fixed if report* is blocked from the compose but need ticket from packagers to request blocking before closing the bug (tflink, 17:46:36) * https://bugzilla.redhat.com/show_bug.cgi?id=729528 (tflink, 17:46:51) * Unable to configure events in reporter to forward in anaconda for F-16-Alpha-RC3 (tflink, 17:46:59) * ACTION: tflink will update 729528 with findings from hacking (tflink, 17:51:19) * jmoskovc is hoping for a fix build today or tomorrow (tflink, 17:51:55) * AGREED: - 729528 - fix is in process, need to update bug with info and verify today (tflink, 18:03:38) * https://bugzilla.redhat.com/show_bug.cgi?id=729537 (tflink, 18:03:50) * Anaconda cannot report crashes in text mode in F16 Alpha RC3 due to missing report-cli (tflink, 18:04:00) * AGREED: -
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 05:28:56PM +0100, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It is in this situation, but there are other situations where depending on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, anything built against it may fail to run against libfoo 1.0. But how will you know that in advance if all you have in your dependencies is the SONAME? Yeah, this is what mschwendt was talking about with the potential of yum install package leading to brokenness unless yum update is also performed. My reply was really to refute Andreas's assertion that a subpackage doesn't have any further concerns than an external package wrt version dependencies which is wrong for both code-related reasons like this and for other factors (like the relicensing example). This thread has shown that we should probably update the guidelines to not appear so draconian about explicit library dependencies (and highlight the ABI/API implications and possibly get changes to rpmbuild), though. Working on an FPC ticket now. Simo or mjg, one of you want to file a bug against rpmbuild since you guys seem to know how Debian has already implemented this? -Toshio pgpUf1j3F5flE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110812 changes
Compose started at Fri Aug 12 17:30:01 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(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_iostreams-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_thread-mt.so.1.46.1()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_filesystem-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_regex-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_iostreams-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_thread-mt.so.1.46.1()(64bit) LuxRender-core-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_program_options-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_regex-mt.so.1.46.1()(64bit) OpenImageIO-0.10.0-2.fc15.i686 requires libboost_regex-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_program_options-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_thread-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_system-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libGLEW.so.1.5 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_filesystem-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_python-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_regex-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_program_options-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libGLEW.so.1.5()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_python-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_thread-mt.so.1.46.0()(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 libcamel-1.2.so.26()(64bit) 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) 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) apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler.so.13()(64bit) apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler-glib.so.6()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(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) 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 librvmlwp.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 librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(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 librvmlwp.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 librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) collectd-snmp-4.10.3-7.fc16.x86_64 requires
Re: Patching config files (or not)
Dne 12.8.2011 18:50, Jos Vos napsal(a): Should configs files of a package be patched to have settings that make it work more or less out of the box (as far as possible, some setting like DB access etc. just can't be filled in in advance)? There are many caveats to this answer, but I think generally speaking the answer is “Yes”. Isn't it a whole purpose of package maintenance to integrate all those various programs into one distribution which works together? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Defining build options based on available compiler version
On 2011-07-30 9:44, Jussi Lehtola wrote:
I tried using
%global gccver %(gcc -dumpversion)
%if %{gccver}= 4.6.0
foo here
%endif
to conditionalize usage of quadruple precision support in a spec file
that ships on multiple distros, but the comparison gives the error
parseExpressionBoolean returns -1
Is there a way to check if the gcc version is sufficient with some rpm
macro?
RPM 4.7 and later let you use a bit of inline Lua to do this:
%if %{lua:rpm.vercmp('%{gccver}', '4.6.0')} 0
This has the benefit of neither comparing lexically nor dragging in
extra build dependencies.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 728669] Please build for EPEL-6
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=728669 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-08-12 04:55:43 EDT --- Chris hasn't been active in Fedora for a while now (see https://fedorahosted.org/fesco/ticket/507). You should be able to directly make the branch request yourself. -- 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 728668] Please build for EPEL-6
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=728668 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-08-12 04:56:07 EDT --- Chris hasn't been active in Fedora for a while now (see https://fedorahosted.org/fesco/ticket/507). You should be able to directly make the branch request yourself. -- 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 728667] Please build for EPEL-6
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=728667 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-08-12 04:56:23 EDT --- Chris hasn't been active in Fedora for a while now (see https://fedorahosted.org/fesco/ticket/507). You should be able to directly make the branch request yourself. -- 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 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
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=712886 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||tcall...@redhat.com Component|perl-App-Asciio |perl-Gtk2 AssignedTo|cw...@alumni.drew.edu |tcall...@redhat.com --- Comment #3 from Iain Arnell iarn...@gmail.com 2011-08-12 05:51:17 EDT --- This is certainly fixed on f16 with perl-Gtk2-1.223 where Gtk2 upstream changelog mentions Cope with the rename of the keysym defines in gtk+ 2.22. And rebuilding rawhide's perl-Gtk2-1.224 locally on F15 fixes this for me. I also tested with dayplanner and found that it too has problems. With perl-Gtk2-1.203, ESC key doesn't work and Use of uninitialized value in numeric eq (==) at /usr/bin/dayplanner line 2451 appears on console. With perl-Gtk2-1.224, it's also fine. I think we probably just need to build perl-Gtk2-1.224 (or 1.223) for F15. -- 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 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
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=712886 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com External Bug ID||CPAN 68813 -- 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 715559] perl-Mojolicious-1.74 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=715559 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-1.72 is|perl-Mojolicious-1.74 is |available |available --- Comment #13 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-08-12 06:42:45 EDT --- Latest upstream release: 1.74 Current version in Fedora Rawhide: 1.65 URL: http://search.cpan.org/dist/Mojolicious/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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 730275] New: perl-Padre-0.88 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Padre-0.88 is available https://bugzilla.redhat.com/show_bug.cgi?id=730275 Summary: perl-Padre-0.88 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 0.88 Current version in Fedora Rawhide: 0.86 URL: http://search.cpan.org/dist/Padre/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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 730274] New: perl-Coro-6.06 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Coro-6.06 is available https://bugzilla.redhat.com/show_bug.cgi?id=730274 Summary: perl-Coro-6.06 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Coro AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, kwiz...@gmail.com, boche...@fedoraproject.org, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 6.06 Current version in Fedora Rawhide: 6.05 URL: http://search.cpan.org/dist/Coro/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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 730278] New: perl-Unicode-Casing-0.08 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Unicode-Casing-0.08 is available https://bugzilla.redhat.com/show_bug.cgi?id=730278 Summary: perl-Unicode-Casing-0.08 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Unicode-Casing AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 0.08 Current version in Fedora Rawhide: 0.07 URL: http://search.cpan.org/dist/Unicode-Casing/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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 730277] New: perl-Text-VimColor-0.12 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Text-VimColor-0.12 is available https://bugzilla.redhat.com/show_bug.cgi?id=730277 Summary: perl-Text-VimColor-0.12 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Text-VimColor AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 0.12 Current version in Fedora Rawhide: 0.11 URL: http://search.cpan.org/dist/Text-VimColor/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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 730279] New: perlbrew-0.28 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perlbrew-0.28 is available https://bugzilla.redhat.com/show_bug.cgi?id=730279 Summary: perlbrew-0.28 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perlbrew AssignedTo: iarn...@gmail.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 0.28 Current version in Fedora Rawhide: 0.27 URL: http://search.cpan.org/dist/App-perlbrew/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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 730274] perl-Coro-6.06 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=730274 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|ppi...@redhat.com |psab...@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 730277] perl-Text-VimColor-0.12 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=730277 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@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 730278] perl-Unicode-Casing-0.08 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=730278 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|ppi...@redhat.com |psab...@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 730278] perl-Unicode-Casing-0.08 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=730278 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Unicode-Casing-0.08-1. ||fc17 Resolution||RAWHIDE Last Closed||2011-08-12 07:09:42 -- 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
File Text-VimColor-0.12.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Text-VimColor: 1c5bb42060d5169f747dc47e4207f6c9 Text-VimColor-0.12.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-VimColor] 0.12 bump
commit bf7d1184acb2130ad8bd2580c33f419938f2eba2
Author: Petr Sabata con...@redhat.com
Date: Fri Aug 12 13:50:16 2011 +0200
0.12 bump
.gitignore |1 +
perl-Text-VimColor.spec | 18 +++---
sources |2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f2cac0a..6f228db 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Text-VimColor-0.11.tar.gz
+/Text-VimColor-0.12.tar.gz
diff --git a/perl-Text-VimColor.spec b/perl-Text-VimColor.spec
index 5c9cfcb..aa8650a 100644
--- a/perl-Text-VimColor.spec
+++ b/perl-Text-VimColor.spec
@@ -1,14 +1,14 @@
Name: perl-Text-VimColor
-Version:0.11
-Release:9%{?dist}
+Version:0.12
+Release:1%{?dist}
Summary:Syntax color text in HTML or XML using Vim
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Text-VimColor/
Source0:
http://www.cpan.org/authors/id/G/GE/GEOFFR/Text-VimColor-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Path::Class) = 0.02
+BuildRequires: perl(Term::ANSIColor)
BuildRequires: perl(Test::More)
# needed for test
BuildRequires: vim-enhanced
@@ -32,24 +32,16 @@ This program is a command line interface to the Perl module
Text::VimColor.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc ChangeLog README
%{_bindir}/text-vimcolor
%{perl_vendorlib}/Text
@@ -58,6 +50,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/text-vimcolor.1.gz
%changelog
+* Fri Aug 12 2011 Petr Sabata con...@redhat.com - 0.12-1
+- 0.12 bump
+- Remove now obsolete Buildroot and defattr
+
* Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.11-9
- Perl mass rebuild
diff --git a/sources b/sources
index c532fe6..f6d32ea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-268fb3f630b463fcec528d798dcf77c3 Text-VimColor-0.11.tar.gz
+1c5bb42060d5169f747dc47e4207f6c9 Text-VimColor-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-VimColor] Rename ChangeLog to Changes
commit 3ad6a20dcfb26c4dd77362f90d121bbc544f9adb
Author: Petr Sabata con...@redhat.com
Date: Fri Aug 12 13:58:36 2011 +0200
Rename ChangeLog to Changes
perl-Text-VimColor.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Text-VimColor.spec b/perl-Text-VimColor.spec
index aa8650a..a2cc8fd 100644
--- a/perl-Text-VimColor.spec
+++ b/perl-Text-VimColor.spec
@@ -42,7 +42,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
make test
%files
-%doc ChangeLog README
+%doc Changes README
%{_bindir}/text-vimcolor
%{perl_vendorlib}/Text
%{perl_vendorlib}/Text/*
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Coro-6.06.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Coro: 2ee54f58bced7471f77149e97c73a94f Coro-6.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Coro] 6.06 bump6.06 bump6.06 bump6.06 bump6.06 bump6.06 bump
commit d0188a7957cc8ed94654d927bae1388cc51e7ac4
Author: Petr Sabata con...@redhat.com
Date: Fri Aug 12 14:45:52 2011 +0200
6.06 bump6.06 bump6.06 bump6.06 bump6.06 bump6.06 bump
.gitignore |1 +
perl-Coro.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 59b035b..35c60e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Coro-6.02.tar.gz
/Coro-6.04.tar.gz
/Coro-6.05.tar.gz
+/Coro-6.06.tar.gz
diff --git a/perl-Coro.spec b/perl-Coro.spec
index 8c4853c..7d2f9ca 100644
--- a/perl-Coro.spec
+++ b/perl-Coro.spec
@@ -1,5 +1,5 @@
Name: perl-Coro
-Version:6.05
+Version:6.06
Release:1%{?dist}
Summary:The only real threads in perl
License:GPL+ or Artistic
@@ -120,6 +120,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Aug 12 2011 Petr Sabata con...@redhat.com - 6.06-1
+- 6.06 bump
+
* Fri Aug 05 2011 Petr Sabata con...@redhat.com - 6.05-1
- 6.05 bump
diff --git a/sources b/sources
index 2594d79..ce10dab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0b06b86bef50e0ac366edac1ca29cf91 Coro-6.05.tar.gz
+2ee54f58bced7471f77149e97c73a94f Coro-6.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-ISO8601] Created tag perl-DateTime-Format-ISO8601-0.07-7.el6
The unsigned tag 'perl-DateTime-Format-ISO8601-0.07-7.el6' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Fri Aug 12 14:53:01 2011 +0200 Perl mass rebuild Changes since the last tag 'perl-DateTime-Format-ISO8601-0_07-2_fc14': Dennis Gilmore (1): - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild Fedora Release Engineering (1): dist-git conversion Marcela Mašláňová (1): - 661697 rebuild for fixing problems with vendorach/lib Petr Sabata (3): Perl mass rebuild Perl mass rebuild Perl mass rebuild -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-ISO8601] Created tag perl-DateTime-Format-ISO8601-0.07-7.el5
The unsigned tag 'perl-DateTime-Format-ISO8601-0.07-7.el5' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Fri Aug 12 14:54:10 2011 +0200 Perl mass rebuild Changes since the last tag 'perl-DateTime-Format-ISO8601-0_07-2_fc14': Dennis Gilmore (1): - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild Fedora Release Engineering (1): dist-git conversion Marcela Mašláňová (1): - 661697 rebuild for fixing problems with vendorach/lib Petr Sabata (3): Perl mass rebuild Perl mass rebuild Perl mass rebuild -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 730274] perl-Coro-6.06 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=730274 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Coro-6.06-1.fc17 Resolution||RAWHIDE Last Closed||2011-08-12 08:54:41 -- 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
File DateTime-Format-XSD-0.2.tar.gz uploaded to lookaside cache by stevetraylen
A file has been added to the lookaside cache for perl-DateTime-Format-XSD: 8b78130ef8630d24935c8f1df3467a98 DateTime-Format-XSD-0.2.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-XSD] Import rhbz#729649
commit 56d294d75cfd5680443b2200d3da8391303d2dbd
Author: Steve Traylen steve.tray...@cern.ch
Date: Fri Aug 12 15:03:17 2011 +0200
Import rhbz#729649
.gitignore|1 +
perl-DateTime-Format-XSD.spec | 61 +
sources |1 +
3 files changed, 63 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..2266dcb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/DateTime-Format-XSD-0.2.tar.gz
diff --git a/perl-DateTime-Format-XSD.spec b/perl-DateTime-Format-XSD.spec
new file mode 100644
index 000..9799aff
--- /dev/null
+++ b/perl-DateTime-Format-XSD.spec
@@ -0,0 +1,61 @@
+Name: perl-DateTime-Format-XSD
+Version:0.2
+Release:1%{?dist}
+Summary:Format DateTime according to xsd:dateTime
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/DateTime-Format-XSD/
+Source0:
http://www.cpan.org/modules/by-module/DateTime/DateTime-Format-XSD-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildArch: noarch
+BuildRequires: perl(DateTime::Format::ISO8601)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+Requires: perl(DateTime::Format::ISO8601)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+#Not autodetermined.
+Provides: perl(DateTime::Format::XSD) = %{version}
+
+%description
+XML Schema defines a usage profile which is a subset of the ISO8601
+profile. This profile defines that
+ '-MM-DDTHH:MI:SS(Z|[+-]zh:zm)'
+is the only possible representation for a dateTime, despite
+all other options ISO provides.
+
+%prep
+%setup -q -n DateTime-Format-XSD-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+rm -rf %{buildroot}
+
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Aug 10 2011 Steve Traylen steve.tray...@cern.ch 0.2-1
+- Specfile autogenerated by cpanspec 1.78.
+- Change RPM_BUILD_ROOT for %%buildroot.
+- Change PERL_INSTALL_ROOT for DESTDIR.
+- Add BR: perl(Test::More)
diff --git a/sources b/sources
index e69de29..9426679 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+8b78130ef8630d24935c8f1df3467a98 DateTime-Format-XSD-0.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-XSD] Created tag perl-DateTime-Format-XSD-0.2-1.fc17
The unsigned tag 'perl-DateTime-Format-XSD-0.2-1.fc17' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Fri Aug 12 15:03:55 2011 +0200 Specfile autogenerated by cpanspec 1.78. Change RPM_BUILD_ROOT for %buildroot. Change PERL_INSTALL_ROOT for DESTDIR. Add BR: perl(Test::More) Changes: Fedora Release Engineering (1): Initial setup of the repo Steve Traylen (1): Import rhbz#729649 -- 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-DateTime-Format-XSD/f16] Import rhbz#729649
Summary of changes: 56d294d... Import rhbz#729649 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
