Re: EPEL -ANNOUNCE Puppet 2.7 upgrade in 6
On Wed, Dec 04, 2013 at 05:02:09AM -0500, Sam Kottler wrote: Will you do a 2.7 for EPEL5 as well? That's the plan. I pushed EPEL6 first since I figured more people would be running masters on the newer distro and masters need to be on newer versions than agents. I'd expect the opposite. We're constantly rolling out RHEL6 servers, but finding time to upgrade the puppetmaster to RHEL6 is not as easy. But thanks for the push :-) I'm hoping to get the EPEL5 upgrade into testing by the end of the week. Great, thanks! -jf ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL -ANNOUNCE Puppet 2.7 upgrade in 6
On Sat, Nov 30, 2013 at 11:53:46AM -0500, Sam Kottler wrote: Hi! Puppet 2.7 is waiting to get pushed to stable and I just wanted to give people a heads up about the upgrade procedure. Please ensure that your master(s) get upgraded before your agents. I'd recommend following this [1] guide. This upgrade is critical because 2.6 is no longer supported and doesn't receive security releases, leaving both masters and agents potentially susceptible to attack. Thanks for the heads up. Let me know if you've got any issues or questions. Will you do a 2.7 for EPEL5 as well? -jf ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Anyone else using and interested in co-maintaining sogo?
I'm using sogo on RHEL6 at work, and would gladly help maintaining it for Fedora. But, I've been expecting this would be a difficult job because I thought SOGo/inverse maintained their own patched gnustep, sope or something like that. Is that not the case? For RHEL6 we're using sope 4.9 from SOGo's own repository, not the 2.0.7 version you have packaged.. And what's the real upstream for SOPE? sogo.nu or http://sope.opengroupware.org/en/source/index.html ? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Anyone else using and interested in co-maintaining sogo?
Ludovic, could you please comment on the status here? Can we build SOGo and all it's dependencies from upstream gnustep, SOPE, etc.. or are there special SOGo-versions of these we'll need? And what is the relationship between SOPE 2.0.7 from http://www.sogo.nu/files/downloads/SOGo/Sources/ and SOPE from http://sope.opengroupware.org/ ? Which one should Fedora provide? Ref: https://lists.fedoraproject.org/pipermail/devel/2013-October/190217.html for start of thread. -jf On Wed, Oct 16, 2013 at 06:22:41PM +0200, Sandro Mani wrote: On 16.10.2013 18:13, Jan-Frode Myklebust wrote: I'm using sogo on RHEL6 at work, and would gladly help maintaining it for Fedora. But, I've been expecting this would be a difficult job because I thought SOGo/inverse maintained their own patched gnustep, sope or something like that. Is that not the case? The only change I needed for GNUStep was applied to Fedora [1]. Now, everything works fine from what I see (though my current setup is not terribly complex). Obviously, more testing is more than welcome :) For RHEL6 we're using sope 4.9 from SOGo's own repository, not the 2.0.7 version you have packaged.. And what's the real upstream for SOPE? sogo.nu or http://sope.opengroupware.org/en/source/index.html ? That also confused me. Ultimately I ended up looking at the release dates (SOPE-2.0.7 from [2] was released 23 Jul 2013, sope-4.7.1 from opengroupware was released 01 Jul 2007). Plus, I also had a look at what debian did, and they packaged 2.0.7 from sogo. Sandro [1] https://bugzilla.redhat.com/show_bug.cgi?id=1005328 [2] http://www.sogo.nu/files/downloads/SOGo/Sources/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GPG verification in SPECs
On Tue, Oct 08, 2013 at 10:22:57AM -0400, Konstantin Ryabitsev wrote:
gpgv --homedir /tmp --keyring %{SOURCE2} --status-fd=1 %{SOURCE1}
%{SOURCE0} | grep -q '^\[GNUPG:\] GOODSIG'
snip
That one-liner is pretty much all that's required for valid gpg verification.
Hope this helps.
Yes it does. Thanks!
-jf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Aug 26, 2013 at 11:07:29AM +0200, Florian Weimer wrote: On 08/24/2013 11:38 AM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=319901 looks like Redhat based systems are the only remaining which does not support EECDHE which is a shame these days in context of PRISM and more and more Ciphers are going to be unuseable (BEAST/CRIME weakness) Current Fedora supports perfect forward secrecy just fine. Just fine -- assuming one ignores the 4-5x performance penalty of DH (vs. non-PFS/ECDHE), and also ignore IE and Safari as clients ? It's just that web server operators routinely refuse to offer it. The perf penalty of DH-RSA seems a bit high, and web server operators are likely fighting anything that is likely to introduce latency.. (The situation is different with mail servers.) Operational benefits look rather marginal to me. It may discourage interested parties from requesting server private keys, but even that isn't assured. It does not help against server operators which provide third parties with cleartext copies of transmissions, obviously. It helps against broad prism-style interception of all traffic, with the intention of decrypting at some later point. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Aug 26, 2013 at 04:57:15PM +0200, Reindl Harald wrote: Not Found The requested URL /roller/blog/entry/enable_elliptical_curve_diffie_hellman was not found on this server. http://www.theverge.com/2013/6/26/4468050/facebook-follows-google-with-tough-encryption-standard and how can i quote from the URL? http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman Probably by using the old internett. The new one is broken for that URL :-) $ curl -6 --head http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman HTTP/1.1 404 Not Found Date: Mon, 26 Aug 2013 16:41:45 GMT Server: Apache Content-Type: text/html; charset=iso-8859-1 $ curl -4 --head http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman HTTP/1.1 200 OK Date: Mon, 26 Aug 2013 16:41:49 GMT Server: Apache Last-Modified: Sun, 21 Jul 2013 17:30:14 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 18886 Content-Type: text/html;charset=utf-8 -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Should MariaDB touch my.cnf in %post?
On Thu, Feb 14, 2013 at 10:17:00AM -0500, Tom Lane wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. I'm quite amazed at how MariaDB is allowed to do this takeover of mysql in fedora. Why can't MariaDB use it's own configuration files, own datadir, own socket, own binary names, etc.. ? I'm no Oracle or Mysql fan, but as far as I see it Oracle/mysql is the original branch of the mysql project, and I think a competing fork should do it's best not to conflict with it. No effort not to conflict seems to be happening here, rather the opposite. What happens when MariaDB and Mysql start diverging? Will it be impossible to have a client that connects to both mysql and mariadb servers ? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: stop service ; remove some files ; start service in RPM %postun ?
On Mon, Jan 28, 2013 at 6:29 PM, Bill Nottingham nott...@redhat.com wrote: I'm curious - why would you need to do this? Seems somewhat fragile to be doing automatically on upgrade. I want to make the upgrade between apache traffic server v3.0 and 3.2 as smooth as possible. There were a couple of state-files that had incompatible changes between these releases, so they need to be deleted while v3.0 is down, before 3.2 is started. Ref: https://cwiki.apache.org/confluence/display/TS/Upgrading+to+3.2 This will probably only be done for EPEL6. v3.2.x was already included in f18, and I don't think I'll bother requesting the incompatible upgrade for f17 or older.. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
stop service ; remove some files ; start service in RPM %postun ?
I have an rpm package where I need to stop the running service, remove some files and start the service again depending on which package version was already installed. I assume I need to do this in %postun, where we normally do condrestart, but I don't know how to check the version of the previously installed package. Could someone help me here / does anybody have examples doing something similar ? For sysv-init i guess it should be trivial to check service $name status to see if it was running, and then stop/start it. But what's the equivalent for systemd ? Currently I use %systemd_postun_with_restart, but that needs to be split up so that I can delete the files while the service is down.. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Sat, Oct 20, 2012 at 1:04 AM, Michael Stahnke stah...@puppetlabs.com wrote: Puppet in the Fedora/EPEL ecosystem is a bit wonky currently. I'd really like to fix it. Problems: * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x. 2.7.x is not 100% compatible with 1.9.3. The number of issues in this space continues to grow. * Puppet 3.0.x is out and is the fully supported branch from Puppet Labs and supports Ruby 1.9.3+ fully. My proposal would be the following: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. What about ruby on RHEL6? Will puppet 3.0 work with RHEL6's ruby 1.8.7, or do you expect RHEL6 users to replace the distro native ruby stack ? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: incompatible upgrade of apache traffic server
On Wed, Jun 27, 2012 at 07:11:32PM +0200, Gregor Tätzner wrote: On Tuesday 26 June 2012 20:56:24 Jan-Frode Myklebust wrote: Will it be OK to do this upgrade in F15/F16/F17, or are we stuck on v3.0 ? I'm not a user of this particular apache service, but in general I would vote -1 There is a reason why those update policies exist: Fedora is no rolling release :) I know, but I think this is a packaged that is not much used (quite new), most serious users will likely be reachable from the traffic-server-users mailinglist, and it's only two options that are not used by default that changes. * The update fixes serious bugs that many fedora users are encountering [Applies, fixes segfault] How do you know. Are you getting many bug reports? I've hit the bug myself, and I know it's also been reported by others in the ATS issue tracker. https://issues.apache.org/jira/browse/TS-1276 I've not received any bugreports, and have actually never received any feedback from any users (adding weight to my assumption that there are very few users). If v3.0 is basically broken an upgrade is imho justified, else the cons seems to overweight, especially the manual intervention for adjusting the config files. v3.0 is still maintained, so the crash bug will likely be fixed. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
incompatible upgrade of apache traffic server
I would like to upgrade Apache Traffic Server (ATS) from v3.0.x to new stable branch v3.2.x. The 3.2 branch has lots of improvements for IPv6 and SSL that are important to me, and also fixes a crash I've been hitting in v3.0. But, unfortunately there are a couple of incompatible config file changes, ref: https://cwiki.apache.org/confluence/display/TS/Upgrading+to+3.2 Only the SSL certificate configuration and HTTP Quick filtering configuration needs to be handled by the user (if they are used). The hostdb and stats-changes can be handled automatically during upgrade. So, IMHO the incompatibilities are very small, and I believe the userbase is also quite small. Hopefully I should be able to reach most users trough the trafficserver-devel and users mailinglist. Looking trough the exceptions lists on http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases: Things that would make it more likely to grant a request: * The package is a leaf node. Nothing depends on it or requires it. [Applies] * The update fixes a security issue that would affect a large number of users. [No] * The update doesn't change ABI/API and nothing needs to be rebuilt against the new version [Applies] * The update fixes serious bugs that many fedora users are encountering [Applies, fixes segfault] Things that would make it less likely to grant a request: * The update converts databases or resources one way to a new format. [internal cache files only] * The update requires admin intervention for the service to keep working (config file format changes, etc). [Maybe -- if the two relevant features are in use] * The update causes behavior changes (something that was denied is allowed, etc) [No] * The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line) [No] * The update fixes bugs that no fedora user has reported nor would affect many fedora users (ie, fixes for other platforms or configurations). [No, I've personally hit crashes on EPEL and expect the same crash should happen on Fedora] Will it be OK to do this upgrade in F15/F16/F17, or are we stuck on v3.0 ? Highlights of this release includes: * Over 800 commits, and 300 Jira tickets closed since v3.0. * Several SSL improvements, including SNI (Server Name Indication) and NPN (Next Protocol Negotiation). Overall SSL stability is also improved. * Full IPv6 support, v3.0 only had client side IPv6. All IP related plugin APIs are now also IPv6 aware. * New, flexible configurations for managing inbound and outgoing IP addresses and ports. You can now bind any number, and combinations, of addresses and ports for both HTTP and HTTPS. * Range request for large objects in cache are now much (much) faster. * Several new, and improved, plugin APIs are now available. * Performance and stability improvements in the Cluster Cache feature. * Much better performance when proxying to a Keep-Alive HTTP backend server connection. Overall cache performance is also significantly better. * Several stable plugins are now included with the core distributions. * Supports all gcc versions 4.1.2 and higher, Clang / LLVM 3, and the Intel compiler suite. Builds and runs on Linux, FreeBSD, Solaris and OSX. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap requests for Lars Wirzenius' new Obnam backup tool
On Sun, Jun 03, 2012 at 02:39:07PM +0700, Michel Alexandre Salim wrote: It consists of 8 packages, and there are two more (seivot, for benchmarking, and summain, for generating diff-able file manifests) that I have not packaged yet, all eight are in Bugzilla, in descending order (packages at the bottom are depended on by the ones on top) Could you please do EL6 branches for these packages as well? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: changelog in spec file, was Re: Stop the git abuse
On Thu, May 24, 2012 at 11:15:38AM +0200, Thomas Spura wrote: On Thu, May 24, 2012 at 11:02 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: * If a git commit is tagged in a specific way, omit from rpm changelog. What I mean by tagged is a git tag, in form of let's say silentXXX. Where XXX has to be unique, but that can be figured out by fedpkg easily. I'd prefer a SILENT: directly in the commit instead of tags... The only tags that should be necessary are the fXX and elX ones. Is there a sane way to change typos in past changelogs? * a REPLACE$githash: line in a later commit? How about generating a Changelog-file based on all previous commits initially. When doing new commits, it should be updated with the previous commit with a pre-commit hook. The rpm-changelog should then contain this changelog-file + the last commit. Then the changelog-history would contain full commits by default, while still being editable. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Tue, Apr 10, 2012 at 07:47:25AM -0400, Daniel J Walsh wrote: Because we are trying to protect the logged in user, where we currently do not confine that many domains, and even if you are using confined users we do not prevent a confined user process from ptrace on another user process, since they could be programmers of admin who need gdb or strace. I run always as staff_t but staff_t is allowed ptrace of staff_t, unless the deny_ptrace boolean is set. Would it not be possible to wrap gdb/strace/etc. in something that presents a password prompt before switching to a context that's allowed to ptrace? Then it wouldn't be allowed to happen behind the users back, but still give all users the ability to ptrace. F.ex. something like a sudoers: ALL ALL=(ALL) TYPE=ptracer_t ROLE=ptrace_r PASSWD: /usr/bin/gdb, /usr/bin/strace ideally only unconfined_u, staff_u, sysadm_u and user_u should be allowed to do this. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swap
On Wed, Mar 07, 2012 at 09:35:09AM +0530, Kalpa Welivitigoda wrote: I would like for a review swap for the following packages. They are sugar activities. https://bugzilla.redhat.com/show_bug.cgi?id=795069 https://bugzilla.redhat.com/show_bug.cgi?id=768700 I'll have a go :-) Could you please take apache traffic server: https://bugzilla.redhat.com/show_bug.cgi?id=787020 -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Advanced IPv6 in NetworkManager
On Mon, Nov 14, 2011 at 11:06:36AM +0100, Ola Thoresen wrote: There is - however - one option I am missing: Some form of combined static and dynamic configuration. IE. I want the server to obtain an IPv6-address dynamically, but i ALSO want it to have one (or more) static IP-address(es) in the same prefix. Not sure if you want to solve this exclusively in network manager, or am just looking for a solution.. but, adding a IPV6ADDR_SECONDARIES to your ifcfg-eth* files should achieve this. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Advanced IPv6 in NetworkManager
On Mon, Nov 14, 2011 at 02:43:10PM +0100, Ola Thoresen wrote: So you say that both IPV6_AUTOCONF=yes IPV6ADDR_SECONDARIES=2001:840:0:11::30/64 Shoudl work? (Have not tested yet, but might do that later today). I believe IPV6INIT=yes IPV6_AUTOCONF=yes IPV6ADDR=2001:840:0:11::30/64 should work and give you both the static IPV6ADDR plus a dynamic address from RA. At least with that config I'm getting these addresses: inet6 addr: 2a01:798:0:8012::5/64 Scope:Global# IPV6ADDR inet6 addr: 2a01:798:0:8012:21a:4aff:fea8:8501/64 Scope:Global # RA inet6 addr: fe80::21a:4aff:fea8:8501/64 Scope:Link # link local I think you only need IPV6ADDR_SECONDARIES if you need to add more than one static address. So for your original example: IPV6INIT=yes IPV6_AUTOCONF=yes IPV6ADDR=2001:840:0:11::10/64 IPV6ADDR_SECONDARIES=2001:840:0:11::20/64 -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
On Fri, Sep 16, 2011 at 10:37:10PM +0200, Volker Fröhlich wrote: https://bugzilla.redhat.com/show_bug.cgi?id=737401 https://bugzilla.redhat.com/show_bug.cgi?id=722709 https://bugzilla.redhat.com/show_bug.cgi?id=710648 I did a couple of reviews lately, but I would swap. I've never done a review, but am in dire need of someone to continue this review: https://bugzilla.redhat.com/show_bug.cgi?id=683463 It would be great of you could take over the review of this traffic server package, and maybe help me in the review process of one of your packages. Which one of your packages do you want me to pick ? #722709 looks like the easiest package... -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review request: Apache Traffic Server
Could someone please help review the Apache Traffic Server: https://bugzilla.redhat.com/show_bug.cgi?id=683463 I believe it should be more or less complete as far as I see it, but the current reviewer doesn't have time to complete it so it's been stalled for months now.. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request: Apache Traffic Server
On Tue, Sep 13, 2011 at 11:20:51AM +, Jóhann B. Guðmundsson wrote: Just out of curiosity I'am assuming this contains a daemon and if so has it been converted to native systemd service files? Yes it contains a daemon, but no, I haven't created the systemd service files yet. I intended to get this into EPEL first, then start looking at the other fedora releases. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PackageUserRegistry
We're trying to package Apache Traffic Server for fedora, and need a dedicated uid/gid for user/group ats running this services since it includes clustering and config management over more than one node. I've found the PackageUserRegistry wiki page at: https://fedoraproject.org/wiki/PackageUserRegistry but it doesn't seem quite right, as there are many users there conflicting with the RHEL standard users: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-users-groups-standard-users.html So, could anybody help me with the procedure for getting a new user/group registered ? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageUserRegistry
On Wed, Jun 22, 2011 at 11:55:33AM +0200, Michael Schwendt wrote: You are misreading the PackageUserRegistry page. Or more likely, you haven't read it carefully enough to follow the link in the first sentence. RHEL doesn't use the 'fedora-usermgmt' feature. Not even Fedora uses it everywhere. Yes, I see that -- but my problem is still the same, I need to register a user/group with a static numerical id. So, is there any way to get a number assigned and know that no other RHEL/Fedora packages will be allowed to conflict ? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageUserRegistry
On Wed, Jun 22, 2011 at 12:09:14PM +0100, Daniel P. Berrange wrote: I have always filed a BZ against the 'setup' RPM asking for a static uid/gid pair to be allocated, and the changelogs support this approach: Great, thanks! https://bugzilla.redhat.com/show_bug.cgi?id=715266 -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-SOAP-Lite/el5] (30 commits) ...Merge branch 'f14' into el5
Summary of changes: 09188de... fix br, license (*) 421be62... Fixed BR (*) 183bdce... new perl (*) 6783404... upstream released new version (*) 3b3a5a6... - Re-add the nil patch (*) 56cd550... Clean up the unused patches (*) 30f6f75... - New upstream release - Enable tests - Include examples in (*) ca7e7a8... Add sources, which have been forgotten (*) 39fae46... - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass (*) a30d56b... - Filter out perl(LWP::Protocol) Provides, which comes from (*) a922a1d... - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass (*) c1f24d5... - new upstream release - drop upstreamed patch - add missin (*) 3a21799... - new upstream version (*) 68c76f0... Fix typo that causes a failure to update the common directo (*) 757a10e... limit BR perl(FCGI) to Fedora (*) 927203c... Initialize branch F-13 for perl-SOAP-Lite (*) 7f9650b... - Mass rebuild with perl-5.12.0 (*) 59858a3... - BR: perl(version) (Fix perl-5.12.0 build breakdown). (*) 6a6992c... - update and apply fix from https://rt.cpan.org/Public/ (*) c16d29f... - update and apply fix from https://rt.cpan.org/Public/ (*) 66fa380... dist-git conversion (*) deb8493... dist-git conversion (*) 74db7e0... 649372 add missing requirement LWP::UserAgent (*) 352ad10... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) 7ef3be6... 0.712 bump (*) a35bc2b... Fix Requires typo (*) 04bf135... BuildArch: noarch, rhbz#694559 (*) 8858a02... Merge branch 'master' into f13 (*) 59b5269... Do not pull optional mod_perl in, do not use sysread() unde (*) 828ccc8... Merge branch 'f14' into el5 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-SOAP-Lite/el5: 30/30] Merge branch 'f14' into el5
commit 828ccc8a3a2c51f3018f029e6943f38434778781 Merge: df4968d 59b5269 Author: Jan-Frode Myklebust janfr...@tanso.net Date: Thu May 19 12:26:35 2011 +0200 Merge branch 'f14' into el5 Conflicts: .gitignore perl-SOAP-Lite.spec sources .gitignore |2 +- perl-SOAP-Lite-0.712-mod_perl.patch | 24 + perl-SOAP-Lite.spec | 169 --- sources |2 +- 4 files changed, 141 insertions(+), 56 deletions(-) --- -- 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-SOAP-Lite/el5] Missing buildroot.
commit 6ab40d14516473d00a6966785411444c7ed88106
Author: Jan-Frode Myklebust janfr...@tanso.net
Date: Thu May 19 12:34:34 2011 +0200
Missing buildroot.
perl-SOAP-Lite.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-SOAP-Lite.spec b/perl-SOAP-Lite.spec
index ff2d7f0..baa243a 100644
--- a/perl-SOAP-Lite.spec
+++ b/perl-SOAP-Lite.spec
@@ -1,6 +1,6 @@
Name: perl-SOAP-Lite
Version:0.712
-Release:4%{?dist}
+Release:4%{?dist}.1
Summary:Client and server side SOAP implementation
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,6 +9,7 @@ Source0:
http://search.cpan.org/CPAN/authors/id/M/MK/MKUTTER/SOAP-Lite-%{vers
# rhbz#663931, rt#58538
Patch0: perl-SOAP-Lite-0.712-mod_perl.patch
BuildArch: noarch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
# Core package
BuildRequires: perl(Class::Inspector)
--
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
[amavisd-new/el6/master: 4/4] Merge branch 'f14' into el6
commit 366067a4a1a5ec30bbe005af5044f748210bb77a Merge: 8f85069 b4f33d3 Author: Jan-Frode Myklebust janfr...@tanso.net Date: Mon Mar 28 23:52:44 2011 +0200 Merge branch 'f14' into el6 amavisd-new-2.6.4-stdout.patch | 21 + amavisd-new.spec |7 ++- 2 files changed, 27 insertions(+), 1 deletions(-) --- -- 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
