dnf-0.4.12
Hi, We're releasing 0.4.12 today. See all the information at the usual places: blog [1], release notes [2] and f20 update [3]. Ales [1] http://dnf.baseurl.org/2014/01/21/dnf-0-4-12-released/ [2] http://akozumpl.github.io/dnf/release_notes.html#id23 [3] https://admin.fedoraproject.org/updates/dnf-0.4.12-1.fc20 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 05:09 PM, Matthew Garrett wrote: On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote: Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? The KMS driver only supports the g200 cores embedded in some server chipsets, it doesn't handle real hardware. We've already dropped 3D support for those chips, though, so it's arguably not of great importance. The only real difference in functionality by dropping -mga would be losing multihead support, and I don't think anyone ever made that work on the UMS driver without the HAL blob. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. The binary drivers don't need iopl(), so the only real question is whether they need root for anything else. It may just be permissions on device nodes, in which case we can probably just special-case them? Probably. TBH I'm not that interested in the binary drivers I know the nvidia one is actually quite decent and it has a lot of users. So I don't want to break them, but beyond that my interest stops. I assume they are still not exporting any kms API to userspace, so the helper I've in mind should just launch X as root for them and then things should just keep working. I know lots of shoulds ... It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. I don't see it being any harder than the blacklisting of nouveau/radeon that's already required. Well that can be done through a config file, this would require doing a chmod on the Xorg binary which would need to be redone after every update. This assumes that if we go the uvesafb route we completely remove the helper to launch Xorg as root. Then again as you've indicated above they may not need root at all and a couple of udev rules to open the right /dev/foo nodes to console users might be enough. And then we could simply forget about supporting ums at all I guess. That would be certainly be a glorious flying-car future. Yep, I think it is probably more realistic to go for the helper first though. I'm going to send a mail to xorg-devel to see how crazy people there think it is to turn uvesafb into a kms driver. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 07:19 PM, Andrew Lutomirski wrote: On Mon, Jan 20, 2014 at 7:48 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. I would like to not break the vesa driver, while still killing the suid bit on the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. Does uvesafb actually work? I submitted a patch to the uvesafb kernel driver a few months back, and not only is the upstream link [1][2] to the v86d helper dead, but no one on the dri-devel list answered my request to see if anyone had a copy. Fedora does not appear to package a copy (at least yum whatprovides '*/v86d' doesn't come up with anything). This means that I got a patch into upstream drm and that it's quite possible that no one (or maybe a grand total of one person) has ever tested. Or do you mean the older pre-uvesafb driver? [1] http://dev.gentoo.org/~spock/projects/uvesafb [2] http://lxr.free-electrons.com/source/Documentation/fb/uvesafb.txt Thanks for this info. It does indeed some not that widely used / tested atm. But if we change it to a kms driver an ship it by default that would certainly change. As for v86d, if I google for just v86d the first hit is: http://packages.ubuntu.com/lucid/v86d And that still has a link to a tarbal with sources. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: NetworkManager Bridges in Fedora
I have a half-working setup: I use a bridge on my home server to connect via vpn like if i was at home, but i am unable to create a tap device with NetworkManager. I have bridge0 and em1 managed by NetworkManager and an ifcfg-tap0 file to bring up tap0 before openvpn start. 2014/1/16 Steve Dickson ste...@redhat.com Hello, Has anybody had any luck with getting bridges consistently up in running in either F19 or F20? I know I have not... I go into setup/networks. Add a bridge which creates two file in /etc/sysconfig/network-scripts ifcfg-Bridge_connection_1 ifcfg-bridge0_slave_1 The contents seem reasonable. After I reboot, I go back in to setup/networks. The status of the bridge is connecting and the Bridge slaves are none??? Anybody know what has to happen to get this code working?? tia, steved. P.S. If there is a better list for me to ask this question, please point me to it... -- 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: RFC: what to do with ums when the X server is not suid root ?
On Mo, 2014-01-20 at 15:58 +, Richard W.M. Jones wrote: On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: We can probably kill -cirrus. qemu? (I know that people should be using QXL, but cirrus is still the default in plain qemu, and IMHO simpler and more secure.) qemu is covered pretty well. There are cirrus + qxl kms drivers for quite some time already. kms driver for '-vga std' is in -next and will probably land in 3.14. Only missing is vmware, where the qemu emulation is to old or to buggy or both for the needs of the vmgfx kms driver. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Tue, 21.01.14 09:26, Hans de Goede (hdego...@redhat.com) wrote: Probably. TBH I'm not that interested in the binary drivers I know the nvidia one is actually quite decent and it has a lot of users. So I don't want to break them, but beyond that my interest stops. I assume they are still not exporting any kms API to userspace, so the helper I've in mind should just launch X as root for them and then things should just keep working. I know lots of shoulds ... I never used that closed source crap myself, but I just wanted to mention that some Suse folks did some work on logind to do ACL management for the nvidia device nodes even though these device nodes do not appear in the Linux device model as used by udev (simply because the device model is only available to free code). Not sure if this fixes the whole problem, but there's at least a way to manage access to some nvidia bits for unprivileged userspace. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RPMbuild mystery parameters --with and --without
I first thought it was just kind of something like what gentoo packages do in their ebuilds, but then I also found that it's useless sometimes as described by Richard. Hereby comes a question, do we have any plans of let users install packages from sources(crazy of course...) with bcond defined also by them in the future? -- 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: RPMbuild mystery parameters --with and --without
Well, lpf ( in package lpf) is about this: it downloads, builds and installs a target package from sources. As of now, there are no user-defined options; no usecase so far. Wouldn't be hard to add if need be. On Tue, Jan 21, 2014 at 2:31 PM, Christopher Meng cicku...@gmail.comwrote: I first thought it was just kind of something like what gentoo packages do in their ebuilds, but then I also found that it's useless sometimes as described by Richard. Hereby comes a question, do we have any plans of let users install packages from sources(crazy of course...) with bcond defined also by them in the future? -- 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: Go packaging guidelines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/14/2014 02:18 PM, Matthew Miller wrote: On Tue, Jan 14, 2014 at 12:06:09PM +0100, Florian Weimer wrote: A couple of questions and comments. I think overall, the approach works. # Packaging Libraries This does not mention libraries which use cgo. Should they be handled the same way? What about additional C wrappers? I think for now, yes. Unless you have a better suggestion. # Security in Go Language Packages The repoquery invocations for checking for affected programs are incorrect because the archive may have evolved from the time the binary Go program has been built and no longer reflect those dependencies. The non-stripped nature of binaries should make it possible to see, based on the binaries alone, which libraries were used to compile it. Hmmm, okay. Would it be useful to have a script that generates a list automatically? On the other hand, I wonder if we should rebuild all dependent binary Go programs each time any of the libraries used to build it change. This ensure that we ship matching source code for the compiled binary, and it causes any breakage sooner. I'm worried that that would cause a lot of needless churn. But maybe it's for the best. I have added some go bindings for libselinux, which are used in the docker port. Currently I am shipping these in libselinux-devel. # rpm -q libselinux-devel libselinux-devel-2.2.2-2.fc21.x86_64 # rpm -ql libselinux-devel | grep go /usr/share/gocode/src/selinux /usr/share/gocode/src/selinux/selinux.go Is the correct way for C libraries that we ship to provide go bindings? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLegL0ACgkQrlYvE4MpobMumgCffnGnOxQr05KJ434TVzdG3XjH WW0Anj/bV06DBh6T/ZK+83q5PsAlsdJN =sqgm -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
recode - source url question
Hi, The author of recode moved the source tarballs to Github. There he provides release tags, see below: https://github.com/pinard/Recode/releases What 'Source tag' should I use in the recode.spec file for version 3.6 tarball? Zoltan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Module-Build-Tiny/epel7] (6 commits) ...Update to 0.028
Summary of changes: 3b28241... Update to 0.025 (*) bfee890... Perl 5.18 rebuild (*) b52c75d... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 931c6a5... Update to 0.026 (*) a5dd1a7... Update to 0.027 (*) 8bc552f... Update to 0.028 (*) (*) 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
Summary/Minutes from today's Env-and-Stacks WG Meeting (2014-01-21)
= #fedora-meeting: Env and Stacks (2014-01-21) = Meeting started by tjanez at 13:03:19 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-01-21/env-and-stacks.2014-01-21-13.03.log.html . Meeting summary --- * init process (tjanez, 13:05:29) * PRD follow-up (tjanez, 13:07:26) * We will wait for FESCo's comments/suggestions on the PRD and then make further clean-ups and modifications to it. (tjanez, 13:15:20) * Making a plan for the tasks/goals set in the PRD (tjanez, 13:15:54) * ACTION: juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML (tjanez, 13:55:35) * AGREED: : We will expand the tasks/goals' description in the PRD and create separate Wiki pages for their description and the summary of their status. For logging of progress we will use a ticketing system (e.g. Trac) (+6,-0,0) (tjanez, 14:00:33) * Next week's chair (tjanez, 14:01:32) * FESCo will discuss the PRD on Wednesday's meeting (2014-01-22) (tjanez, 14:03:49) * ACTION: mmaslano will chair next meeting (mmaslano, 14:04:38) * ACTION: juhp_ will chair the meeting the week after that (2014-02-04) (tjanez, 14:05:19) * Open Floor (tjanez, 14:06:10) Meeting ended at 14:16:21 UTC. Action Items * juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML * mmaslano will chair next meeting * juhp_ will chair the meeting the week after that (2014-02-04) Action Items, by person --- * juhp * juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML * juhp_ will chair the meeting the week after that (2014-02-04) * juhp_ * juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML * juhp_ will chair the meeting the week after that (2014-02-04) * mmaslano * mmaslano will chair next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * juhp_ (72) * tjanez (58) * mmaslano (18) * hhorak (16) * bkabrda (7) * zodbot (6) * samkottler (4) * hhorak1 (1) * pkovar (1) * abadger1999 (0) * juhp (0) * handsome_pirate (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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: recode - source url question
See [1], in particular the section on %version --alec [1] https://fedoraproject.org/wiki/Packaging:SourceURL#Github On Tue, Jan 21, 2014 at 3:47 PM, Zoltan Kota zolt...@gmail.com wrote: Hi, The author of recode moved the source tarballs to Github. There he provides release tags, see below: https://github.com/pinard/Recode/releases What 'Source tag' should I use in the recode.spec file for version 3.6 tarball? Zoltan -- 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
[perl-Module-Build-Tiny] Created tag perl-Module-Build-Tiny-0.028-1.el7
The lightweight tag 'perl-Module-Build-Tiny-0.028-1.el7' was created pointing to: 8bc552f... Update to 0.028 -- 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: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 23:18 -0800, Adam Williamson wrote: On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote: On 01/20/2014 11:48 AM, Adam Williamson wrote: The bug currently under discussion was caused by a change that came in inadvertently, not intentionally, and was actually intended for Rawhide. I can't help wondering if there's an opportunity for process/workflow improvement right there. Well, I'd have to leave that to the SELinux folks to comment, but I would say it's only happened once since I came to Fedora that I remember, and everyone makes mistakes sometimes :/ Exactly. And because everybody makes mistakes, we have processes to catch and prevent those inevitable mistakes from going out. I think it would be great to make adjustments to the process / policy so that we get better at preventing this... -- 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: Best Practices for Django App Packaging
On 01/21/2014 03:45 PM, john.flor...@dart.biz wrote: While I've been packaging Python apps for Fedora for a long time, I'm a complete novice to Django. I've just completed my first app (using the built-in development server) and now want to get it packaged. Thus far I've followed my normal model of using setuptools so that everything very cleanly lands in /usr/lib/python2.7/site-packages/my_package. My Django app is under there, along with other related Python modules that are used independently of the Django app. I'm not finding any docs in the Fedora package guidelines and am unaware of existing packages that might serve as excellent examples. My web searches are turning up lots, but nothing much specific to Fedora. At the moment, I'm particularly struggling with how to make my /etc/httpd/conf.d/myapp.conf point to my /usr/lib/python2.7/site-packages/my_package/my_site/wsgi.py in a good generic RPM spec sense. I'd rather not hard-code the Python version in myapp.conf. Any pointers would be greatly appreciated. If you want an exampple, please look at openstack-dashboard: [1] is the config file to be dropped at /etc/httpd/conf.d (for httpd-2.2) or [2] for httpd-2.4 The spec is here[3] for reference. HTH, Matthias [1] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/openstack-dashboard.conf [2] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/openstack-dashboard-httpd-2.4.conf [3] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/python-django-horizon.spec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Lingua-EN-Sentence] Initial import
commit abc17401e5c68bea6f310bec7a452252f9f1115d
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Tue Jan 21 16:28:47 2014 +0100
Initial import
.gitignore |1 +
perl-Lingua-EN-Sentence.spec | 52 ++
sources |1 +
3 files changed, 54 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..d368aaf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Lingua-EN-Sentence-0.25.tar.gz
diff --git a/perl-Lingua-EN-Sentence.spec b/perl-Lingua-EN-Sentence.spec
new file mode 100644
index 000..536a868
--- /dev/null
+++ b/perl-Lingua-EN-Sentence.spec
@@ -0,0 +1,52 @@
+Name: perl-Lingua-EN-Sentence
+Version:0.25
+Release:1%{?dist}
+Summary:Module for splitting text into sentences
+# same as perl, cf. lib/Lingua/EN/Sentence.pm
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Lingua-EN-Sentence/
+Source0:
http://www.cpan.org/authors/id/S/SH/SHLOMOY/Lingua-EN-Sentence-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(locale)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+The Lingua::EN::Sentence module contains the function get_sentences, which
+splits text into its constituent sentences, based on a regular expression
+and a list of abbreviations (built in and given).
+
+%prep
+%setup -q -n Lingua-EN-Sentence-%{version}
+iconv -f ISO-8859-1 -t utf-8 Changes Changes~
+mv Changes~ Changes
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Jan 17 2014 Ralf Corsépius corse...@fedoraproject.org 0.25-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..4a30970 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+4a846acfcb6eedd1c1557fc7f79f034d Lingua-EN-Sentence-0.25.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: Taskotron wiki page
- Original Message - From: Kamil Paral kpa...@redhat.com To: Fedora QA Development qa-de...@lists.fedoraproject.org, Josef Skladanka jskla...@redhat.com Sent: Tuesday, January 21, 2014 4:00:33 PM Subject: Re: Taskotron wiki page I also updated https://fedoraproject.org/wiki/QA/Tools with the list of our current projects. If you see something missing, please add it. Thanks. Josef, I find this quite confusing: https://bitbucket.org/rajcze/resultsdb https://bitbucket.org/rajcze/resultsdb_api https://bitbucket.org/rajcze/resultsdb_frontend https://fedorahosted.org/ResultsDB/ https://git.fedorahosted.org/git/ResultsDB.git What is the canonical source? Where should people report issues? Please, pick one location to keep the project in (it seems we're going bitbucket, or bitbucket+phab way) and kill the other site. Also make sure issues can't be reported on two different places, and forward people to the single one. And make sure your wiki page points to a correct location: https://fedoraproject.org/wiki/ResultsDB (I updated it before learning there are other sources of ResultsDB. You might have some more under your sleeve.) Thanks. As a general note, I'm not fully happy when the source code lives somewhere else than the issues do. It confuses people. But if we want to keep easy-to-browse-and-fork functionality (bitbucket) and full-featured-review functionality (phab), it seems we don't have much choice. At least we should always disable the issue support on bitbucket for every project. Weren't we going to move repos to phab as well? M. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Your packages in EPEL-7
These don't have an epel7 branch yet. Please let me know if you intend to request the branch for the package you maintain. perl-DBD-CSV (devel:psabata, EL-6:steve) perl-MIME-Lite (devel:psabata, EL-6:stevetraylen) perl-MLDBM (devel:steve, EL-6:spot) perl-SQL-Statement (devel:psabata, EL-6:kanarip) Thank you! On Wed, 2014-01-15 at 12:23 +0100, Lubomir Rintel wrote: Dear package maintainers, I rely on Perl module packages you maintain being in EPEL. Now that EPEL-7 is open for branch requests, I'd like to kindly ask you to either request an epel7 branch for your packages or let me know that you're not willing to do that (so that I can request the branches myself). Thank you! These are the packages I need (and one or more of them is the reason your received this message): perl-DBD-CSV (devel:psabata, EL-6:steve) perl-DateTime-Format-Builder (devel:iarnell, EL-6:pghmcfc) perl-DateTime-Format-Mail (devel:iarnell, EL-6:) perl-DateTime-Format-MySQL (devel:iarnell, EL-6:pghmcfc) perl-DateTime-Format-Strptime (devel:steve, EL-6:steve) perl-Email-Date-Format (devel:spot, EL-6:orphan) perl-Log-Dispatch (devel:spot, EL-6:spot) perl-Log-Log4perl (devel:jplesnik, EL-6:mmaslano) perl-MIME-Lite (devel:psabata, EL-6:stevetraylen) perl-MIME-Types (devel:spot, EL-6:spot) perl-MLDBM (devel:steve, EL-6:spot) perl-MRO-Compat (devel:pghmcfc, EL-6:pghmcfc) perl-Mail-Sender (devel:spot, EL-6:spot) perl-SQL-Statement (devel:psabata, EL-6:kanarip) perl-String-Random (devel:eseyman, EL-6:eseyman) perl-Test-Class (devel:steve, EL-6:steve) perl-Want (devel:corsepiu, EL-6:laxathom) Thanks! Lubo -- 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
LibRaw soname bump
The latest LibRaw is landing momentarily. The soname has changed so I'll be rebuilding evas-generic-loaders, libkdcraw, oyranos and shotwell. If I missed anything I'll fix that up as well. Thanks, J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: NetworkManager Bridges in Fedora
On Mon, 2014-01-20 at 23:18 -0500, Nico Kadel-Garcia wrote: My old notes at https://wikis.uit.tufts.edu/confluence/display/TUSKpub/Configure+Pair+Bonding,+VLANs,+and+Bridges+for+KVM+Hypervisor were pretty good. If you want stable KVM bridging, pair bonding, jumbo frames, or consistent network connections of any sort for server grade installations, my urgent advice is to rip NetworkManager out by the routes. It provides no useful benefit for a stable server environment, and is actively destabilizing because it rewrite and overwrites network configurations inconsistently, and in ways that are not idempotent: the same steps executed two times in a row do not produce the same results, and only approach consistency thorugh a sort of Newtonian approximation eventually, but only eventually, publishing a vaguely stable configuration. Networkmanager is not your friend for stable servers. We have spent the last few years ensuring this is not the case. We have been making tons of changes specifically to ensure stable networking, eliminate the surprises you may have experienced in the past. I'd encourage you to try out these changes in F20 and beyond, and if you find problems, by all means file bugs and we'll work to fix them. Dan On Sat, Jan 18, 2014 at 11:35 AM, Mateusz Marzantowicz mmarzantow...@osdf.com.pl wrote: On 16.01.2014 21:38, Dan Williams wrote: On Thu, 2014-01-16 at 14:53 -0500, Steve Dickson wrote: On 16/01/14 14:39, Steve Dickson wrote: On 16/01/14 14:09, Dan Williams wrote: Also, if wouldn't mind passing along the systemd journal output for NetworkManager, that might help us figure out what's going on: journalctl -b _SYSTEMD_UNIT=NetworkManager.service The log is at: http://steved.fedorapeople.org/tmp/nm.log I bet ya the hang has something to do with these messages: info (bridge0): IPv4 config waiting until carrier is on info (bridge0): IPv6 config waiting until carrier is on info Activation (bridge0) Stage 3 of 5 (IP Configure Start) complete. What carrier is it waiting on? em1 is already up and running... So what's happening here is that you two configurations/connections/profiles that apply to em1: ifcfg-em1, and ifcfg-bridge0_slave_1. And ifcfg-em1 is getting chosen, but it's not a bridge slave configuration, it's just a normal DHCP configuration. Since ifcfg-em1 is not a bridge slave configuration, it never gets added to the bridge master, and the bridge master sits around waiting for slaves because it has no carrier which is required for DHCP. Persistent fix #1: edit ifcfg-em1 and change ONBOOT=yes to ONBOOT=no nmcli con reload then do Runtime fix below Persistent fix #2: rm /etc/sysconfig/network-scripts/ifcfg-em1 nmcli con reload then do Runtime fix below (or use nm-connection-editor to delete 'em1' or uncheck Connect automatically from the General tab.) Runtime fix (not persistent): nmcli dev disconnect em1 nmcli con up bridge0 slave 1 -- (In old network service speak, the runtime operation would be: ifdown em1 ifup bridge0_slave_1 and we still expect these commands to work even when NetworkManager is managing the interface.) -- Dan I'm doing this differently and now I don't know which method is recommended by RH/Fedora gurus. I don't use /etc/sysconfig/network-scripts at all but placed all network related configuration in /etc/NetworkManager/system-connections/ directory. Now I'm not sure if I should convert back to using /etc/sysconfig or what? Not to mention that GUI tool is c... and I had to use text editor to configure network bridging. Mateusz Marzantowicz -- 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: Taskotron wiki page
On Tue, 21 Jan 2014 10:23:40 -0500 (EST) Martin Krizek mkri...@redhat.com wrote: snip As a general note, I'm not fully happy when the source code lives somewhere else than the issues do. It confuses people. But if we want to keep easy-to-browse-and-fork functionality (bitbucket) and full-featured-review functionality (phab), it seems we don't have much choice. At least we should always disable the issue support on bitbucket for every project. Weren't we going to move repos to phab as well? It's a possibility but not something that we'd discussed much as of yet. Phabricator is capable of hosting repositories but it would require some reconfiguration and testing. The feature is a newer addition and I'd want to test it a bit in staging before moving all of our code there. Any thoughts on how soon we might want to explore this? If we go this route, folks will have to upload their ssh pubkeys to phabricator because I strongly suspect there's no clean way of getting that data from FAS (if it's even possible at all). Tim signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
[perl-ExtUtils-Depends/epel7] (2 commits) ...Update to 0.306
Summary of changes: 553df2d... Update to 0.305 (*) eb64f0f... Update to 0.306 (*) (*) 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: Best Practices for Django App Packaging
On 01/21/2014 03:45 PM, john.flor...@dart.biz wrote: While I've been packaging Python apps for Fedora for a long time, I'm a complete novice to Django. I've just completed my first app (using the built-in development server) and now want to get it packaged. Thus far I've followed my normal model of using setuptools so that everything very cleanly lands in /usr/lib/python2.7/site-packages/my_package. My Django app is under there, along with other related Python modules that are used independently of the Django app. I'm not finding any docs in the Fedora package guidelines and am unaware of existing packages that might serve as excellent examples. My web searches are turning up lots, but nothing much specific to Fedora. At the moment, I'm particularly struggling with how to make my /etc/httpd/conf.d/myapp.conf point to my /usr/lib/python2.7/site-packages/my_package/my_site/wsgi.py in a good generic RPM spec sense. I'd rather not hard-code the Python version in myapp.conf. Any pointers would be greatly appreciated. If you want an exampple, please look at openstack-dashboard: [1] is the config file to be dropped at /etc/httpd/conf.d (for httpd-2.2) or [2] for httpd-2.4 The spec is here[3] for reference. HTH, Matthias [1] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard.conf [2] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard-httpd-2.4.conf [3] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ python-django-horizon.spec Thanks Matthias! That's quite a complicated example, although I can see there's much I can learn from it. Unfortunately, it's not the ideal example because it moves everything that setup.py builds into /usr/share/openstack-dashboard. I need to keep stuff under /usr/lib/pythonX.Y/site-packages so that the other, non-Django, parts continue to work as expected. (I suppose I could just relocate the Django-parts of the build, but sounds like it will break more things that it will help.) -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-ExtUtils-Depends] Created tag perl-ExtUtils-Depends-0.306-1.el7
The lightweight tag 'perl-ExtUtils-Depends-0.306-1.el7' was created pointing to: eb64f0f... Update to 0.306 -- 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
.spec file Source0 magic for github release source tarballs?
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
2014/1/21 Kaleb KEITHLEY kkeit...@redhat.com:
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
where there's a button for Source code (tar.gz) pointing at
https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
I'm using a different scheme (there are few at GitHub):
https://github.com/lemenkov/erlsyslog/archive/0.6.2/erlsyslog-0.6.2.tar.gz
E.g.
https://github.com/%{upstream}/%{name}/archive/%{version}/%{name}-%{version}.tar.gz
Actually we should teach our builsystem to work with Git, tags, and
branches and forget about tarballs forever.
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On 01/21/2014 12:09 PM, Richard Shaw wrote: Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. I agree, but practice has shown that few projects on github are using release tags. ~tom == ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Swig and -Werror=format-security
Is anybody addressing the output of Swig WRT this problem? Our project (Qpid) generates language bindings using Swig during the build process. Our build is now failing on F21. For example: /builddir/build/BUILD/qpid-0.24/cpp/bindings/qpid/ruby/rubyRUBY_wrap.cxx:2237:38:error: format not a string literal and no format arguments [-Werror=format-security] rb_raise(error, ex.what()); Has anybody addressed this issue with Swig? I brought this up when the idea of -Werror=format-security was being floated and a bug filed again qpid-cpp for this failure and even replied as such in the BZ [1]. [1] BZ#1037295 -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.fedorapeople.org/ What do you care what people think, Mr. Feynman? pgpwYnXWqh1Ro.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Font-TTF-1.04.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Font-TTF: ae3349a2259429c9327e183d8564d34a Font-TTF-1.04.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-Font-TTF] 1.04 bump
commit 4efddf58f5641f3bf777fffc8602a0ce2195e2d2
Author: Petr Šabata con...@redhat.com
Date: Tue Jan 21 18:25:07 2014 +0100
1.04 bump
.gitignore |1 +
perl-Font-TTF.spec | 22 +-
sources|2 +-
3 files changed, 15 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 516f88c..de55795 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Font-TTF-0.45.tar.gz
/Font-TTF-1.00.tar.gz
/Font-TTF-1.01.tar.gz
/Font-TTF-1.02.tar.gz
+/Font-TTF-1.04.tar.gz
diff --git a/perl-Font-TTF.spec b/perl-Font-TTF.spec
index bbbd5fc..4bff756 100644
--- a/perl-Font-TTF.spec
+++ b/perl-Font-TTF.spec
@@ -1,22 +1,25 @@
Name: perl-Font-TTF
-Version: 1.02
-Release: 5%{?dist}
+Version: 1.04
+Release: 1%{?dist}
Summary: Perl library for modifying TTF font files
Group: Development/Libraries
License: Artistic 2.0
URL: http://search.cpan.org/dist/Font-TTF/
Source0:
http://cpan.org/authors/id/M/MH/MHOSKEN/Font-TTF-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(Compress::Zlib)
-BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Compare)
+BuildRequires: perl(Getopt::Std)
BuildRequires: perl(IO::File)
BuildRequires: perl(IO::String)
+BuildRequires: perl(strict)
+BuildRequires: perl(Symbol)
BuildRequires: perl(Test::Simple)
-BuildRequires: perl(XML::Parser::Expat)
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+BuildRequires: perl(vars)
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo $version))
%description
Perl module for TrueType font hacking. Supports reading, processing and writing
@@ -30,17 +33,15 @@ module.
%prep
%setup -q -n Font-TTF-%{version}
-#dos2unix README.TXT COPYING lib/Font/TTF/Changes
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
@@ -60,6 +61,9 @@ make test
%exclude %{perl_vendorlib}/Font/TTF/Win32.pm
%changelog
+* Tue Jan 21 2014 Petr Šabata con...@redhat.com - 1.04-1
+- 1.04 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.02-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index f58c01f..0b15284 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d04e1f65a7edbedd9d150d9cd33c6ffe Font-TTF-1.02.tar.gz
+ae3349a2259429c9327e183d8564d34a Font-TTF-1.04.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: .spec file Source0 magic for github release source tarballs?
Actually, the GL are pretty clear here: the source should be referenced using the full commit, nothing else. There is some reasoning why. The tag should got to Version: (as long its 'sane'). Besides that this is the existing GL, there is also a subtle difference in git-archive (which supposedly runs this). When archiving a tag, the sources gets today's date. OTOH, when archiving a commit, the sources modification dates are their commit date. Last time I checked this was also true on github. On Tue, Jan 21, 2014 at 6:09 PM, Richard Shaw hobbes1...@gmail.com wrote: On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.comwrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. Richard -- 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: .spec file Source0 magic for github release source tarballs?
On 01/21/2014 12:39 PM, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com
mailto:leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be
referenced using the full commit, nothing else. There is some
reasoning why. The tag should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle
difference in git-archive (which supposedly runs this). When
archiving a tag, the sources gets today's date. OTOH, when
archiving a commit, the sources modification dates are their commit
date. Last time I checked this was also true on github.
Of course github could change it at any time but it looks to be working
properly right now, in the case of OpenColorIO:
Source0:
https://github.com/%{upstream}/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
Yes, that's the magick I needed. Works for me in nfs-ganesha.
Thanks,
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be referenced
using the full commit, nothing else. There is some reasoning why. The tag
should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle difference in
git-archive (which supposedly runs this). When archiving a tag, the
sources gets today's date. OTOH, when archiving a commit, the sources
modification dates are their commit date. Last time I checked this was also
true on github.
Of course github could change it at any time but it looks to be working
properly right now, in the case of OpenColorIO:
Source0:
https://github.com/%{upstream}/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
run through spectool:
https://github.com/imageworks/OpenColorIO/archive/v1.0.9/OpenColorIO-1.0.9.tar.gz
downloaded right now:
$ curl -LO
https://github.com/imageworks/OpenColorIO/archive/v1.0.9/OpenColorIO-1.0.9.tar.gz
$ ll OpenColorIO-1.0.9
total 72
-rw-rw-r--. 1 build build 11958 Oct 8 17:59 ChangeLog
-rw-rw-r--. 1 build build 15763 Oct 8 17:59 CMakeLists.txt
drwxrwxr-x. 6 build build 4096 Oct 8 17:59 docs
drwxrwxr-x. 5 build build 4096 Oct 8 17:59 export
drwxrwxr-x. 3 build build 4096 Oct 8 17:59 ext
-rw-rw-r--. 1 build build45 Oct 8 17:59 INSTALL
-rw-rw-r--. 1 build build 11286 Oct 8 17:59 LICENSE
-rw-rw-r--. 1 build build 1115 Oct 8 17:59 README
drwxrwxr-x. 6 build build 4096 Oct 8 17:59 share
drwxrwxr-x. 11 build build 4096 Oct 8 17:59 src
drwxrwxr-x. 2 build build 4096 Oct 8 17:59 testdata
Still has the Oct 8 tag date.
Is there a possibility of updating the guidelines? I like this method much
better, no only is it clearer but easier to maintain. Of course if upstream
does not tag releases, then the current method should be used.
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
You could file a issue at the FPC trac, preferably with a proposal for new
GL.
That said, I notice that we use what works for me, despite any GL so
maybe it doesn't matter. Dunno.
--alec
On Tue, Jan 21, 2014 at 6:41 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote:
On 01/21/2014 12:39 PM, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com
mailto:leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be
referenced using the full commit, nothing else. There is some
reasoning why. The tag should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle
difference in git-archive (which supposedly runs this). When
archiving a tag, the sources gets today's date. OTOH, when
archiving a commit, the sources modification dates are their commit
date. Last time I checked this was also true on github.
Of course github could change it at any time but it looks to be working
properly right now, in the case of OpenColorIO:
Source0:
https://github.com/%{upstream}/%{name}/archive/v%{version}/%
{name}-%{version}.tar.gz
Yes, that's the magick I needed. Works for me in nfs-ganesha.
Thanks,
--
Kaleb
--
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
[pkgdb] perl-Lingua-Stem-Snowball ownership changed
Package perl-Lingua-Stem-Snowball in Fedora EPEL 6 is now owned by lkundrak To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Lingua-Stem-Snowball -- 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: Best Practices for Django App Packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/21/2014 11:22 AM, john.flor...@dart.biz wrote: On 01/21/2014 03:45 PM, john.flor...@dart.biz wrote: While I've been packaging Python apps for Fedora for a long time, I'm a complete novice to Django. I've just completed my first app (using the built-in development server) and now want to get it packaged. Thus far I've followed my normal model of using setuptools so that everything very cleanly lands in /usr/lib/python2.7/site-packages/my_package. My Django app is under there, along with other related Python modules that are used independently of the Django app. I'm not finding any docs in the Fedora package guidelines and am unaware of existing packages that might serve as excellent examples. My web searches are turning up lots, but nothing much specific to Fedora. At the moment, I'm particularly struggling with how to make my /etc/httpd/conf.d/myapp.conf point to my /usr/lib/python2.7/site-packages/my_package/my_site/wsgi.py in a good generic RPM spec sense. I'd rather not hard-code the Python version in myapp.conf. Any pointers would be greatly appreciated. If you want an exampple, please look at openstack-dashboard: [1] is the config file to be dropped at /etc/httpd/conf.d (for httpd-2.2) or [2] for httpd-2.4 The spec is here[3] for reference. HTH, Matthias [1] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard.conf [2] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard-httpd-2.4.conf [3] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ python-django-horizon.spec Thanks Matthias! That's quite a complicated example, although I can see there's much I can learn from it. Unfortunately, it's not the ideal example because it moves everything that setup.py builds into /usr/share/openstack-dashboard. I need to keep stuff under /usr/lib/pythonX.Y/site-packages so that the other, non-Django, parts continue to work as expected. (I suppose I could just relocate the Django-parts of the build, but sounds like it will break more things that it will help.) Another example you may want to take a look at is ReviewBoard, which is pretty straightforward. http://pkgs.fedoraproject.org/cgit/ReviewBoard.git/tree/ReviewBoard.spec -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLeu4UACgkQeiVVYja6o6N22QCeJk4+xNa0tciSy4Iu//UaA8mi mNYAoIqoD9BCTI2lXX/LqKO0ikA0CYor =Lsln -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Phab: setting projects when creating a ticket
On Tue, 21 Jan 2014 09:08:01 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: I just tried to create a ticket in Phab. I understand that the Project field is similar to Component field that we used in Trac. (It's a bit unfortunate that a project can't be further separated into components). However, there's no text completion in that field unless you type in something. There's no list of projects nearby (unless you know which icon to click in Phab and find it in a separate page). I'm a bit afraid that people won't be able to report bugs in Phab unless it's easy to find taskotron or something through the Project field. Yeah, we're already seeing that a little - the last beaker ticket didn't have a project attached. Sure, I assume we can provide custom URLs which fill in the project field through GET arguments, but then you need to spread these links everywhere so that people don't find a different way to the system. There are URLs for creating tickets for a project, but they're kinda ugly: https://phab.qadevel.cloud.fedoraproject.org/maniphest/task/create/?projects=PHID-PROJ-prgpoumlmfdczdr4dyv3 Is the one for the taskotron project. Am I missing something? No, I don't think so. Unfortunately, the only way I can see to manage this is for us to keep an eye on incoming tickets. It's a pain, but I think that we'd need to do it even if there was an easier method for users to indicate projects in the tickets. I'll keep an eye on incoming tickets but some help in this would be appreciated. Keeping on top of our tickets will make our lives easier in the long run. Tim signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-qpid_proton
perl-qpid_proton has broken dependencies in the rawhide tree: On x86_64: perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid::proton::ExceptionHandling) On i386: perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid::proton::ExceptionHandling) On armhfp: perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid::proton::ExceptionHandling) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Environment and Stacks PRD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2014 08:33 AM, Marcela Mašláňová wrote: Environment and Stacks Working Group approved the first version of PRD. Feel free to comment what is missing or what should be altered. https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document I have some comments and feedback on this PRD that I figured I'd submit before it comes to FESCo. I'm very sorry this is so late, but I haven't had a chance to read it previously. In general, I think the content is good and the goals makes sense. I just have a few minor suggestions: * The Vision Statement isn't one. The purpose of a vision statement is to describe the state that you want to achieve. A better vision statement here might be Fedora is the preferred ecosystem of choice for new software development to occur in any language and on any framework. * The Mission Statement describes the working group. It should be a short, high-level description of the strategy to achieve the vision. Suggestion: The Environment and Stacks Working Group will research and develop new or improved methods of packaging and deploying software for the Fedora community. * An example of a Koji-git integration: a successful build of a package in Koji triggers automatic generation of a tag in package's git repository so that the packager can easily access the content of the particular build using pure git. This seems overly-specific for a PRD (and also the builds are already associated with a commit ID, so the tag is a convenience, not really an enhancement). * We will encourage upstream projects to move toward a CI model. +1000 * I'd like to see more about DevAssistant. I personally know a fair amount about it, but the average reader of this document will probably not. Same with COPR, Koji and Bodhi in several places; the document assumes that the reader is familiar with them (and the one-sentence definition section is a little light on detail). I realize you link out, but it would read easier with a little more content in the document itself. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLexg4ACgkQeiVVYja6o6OLAwCdHzDVVssnosyj7HzLwuU1/3MW u5sAnRn7KHJ9hespUfJoHKXuReLON3id =rqvS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best Practices for Django App Packaging
From: sgall...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Date: 01/21/2014 13:24 Subject: Re: Best Practices for Django App Packaging Sent by: devel-boun...@lists.fedoraproject.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/21/2014 11:22 AM, john.flor...@dart.biz wrote: On 01/21/2014 03:45 PM, john.flor...@dart.biz wrote: While I've been packaging Python apps for Fedora for a long time, I'm a complete novice to Django. I've just completed my first app (using the built-in development server) and now want to get it packaged. Thus far I've followed my normal model of using setuptools so that everything very cleanly lands in /usr/lib/python2.7/site-packages/my_package. My Django app is under there, along with other related Python modules that are used independently of the Django app. I'm not finding any docs in the Fedora package guidelines and am unaware of existing packages that might serve as excellent examples. My web searches are turning up lots, but nothing much specific to Fedora. At the moment, I'm particularly struggling with how to make my /etc/httpd/conf.d/myapp.conf point to my /usr/lib/python2.7/site-packages/my_package/my_site/wsgi.py in a good generic RPM spec sense. I'd rather not hard-code the Python version in myapp.conf. Any pointers would be greatly appreciated. If you want an exampple, please look at openstack-dashboard: [1] is the config file to be dropped at /etc/httpd/conf.d (for httpd-2.2) or [2] for httpd-2.4 The spec is here[3] for reference. HTH, Matthias [1] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard.conf [2] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard-httpd-2.4.conf [3] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ python-django-horizon.spec Thanks Matthias! That's quite a complicated example, although I can see there's much I can learn from it. Unfortunately, it's not the ideal example because it moves everything that setup.py builds into /usr/share/openstack-dashboard. I need to keep stuff under /usr/lib/pythonX.Y/site-packages so that the other, non-Django, parts continue to work as expected. (I suppose I could just relocate the Django-parts of the build, but sounds like it will break more things that it will help.) Another example you may want to take a look at is ReviewBoard, which is pretty straightforward. http://pkgs.fedoraproject.org/cgit/ReviewBoard.git/tree/ReviewBoard.spec -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLeu4UACgkQeiVVYja6o6N22QCeJk4+xNa0tciSy4Iu//UaA8mi mNYAoIqoD9BCTI2lXX/LqKO0ikA0CYor =Lsln -END PGP SIGNATURE- Thank you too Stephen! That indeed does look much more similar. Although I don't see any Apache httpd config in the package. Reading The Fine Manual briefly looks like it relies on 'rb-site install' to do this part. I was hoping to find an example where the RPM spec dropped a Django app setup right into /etc/httpd/conf.d -- in other words, a package that just assumes you will use Apache httpd, maybe even creates an empty sqlite db so things are just ready to run with a httpd restart. I may be just trying to do too much in my spec and perhaps should rely on puppet to do the deployment and integration work. -- John Florian -- 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: Go packaging guidelines?
On Tue, Jan 21, 2014 at 09:14:21AM -0500, Daniel J Walsh wrote: # rpm -ql libselinux-devel | grep go /usr/share/gocode/src/selinux /usr/share/gocode/src/selinux/selinux.go Is the correct way for C libraries that we ship to provide go bindings? libguestfs has shipped go bindings in Fedora for 7 months. We do it in a separate package which looks like this: $ repoquery -ql golang-guestfs /usr/lib64/golang/pkg/linux_amd64/libguestfs.org /usr/lib64/golang/pkg/linux_amd64/libguestfs.org/guestfs /usr/lib64/golang/src/pkg/libguestfs.org /usr/lib64/golang/src/pkg/libguestfs.org/guestfs /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_010_load_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_020_create_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_030_create_flags_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_040_create_multiple_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_050_handle_properties_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_060_explicit_close_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_070_optargs_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_100_launch_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_900_rstringlist_test.go /usr/share/doc/golang-guestfs /usr/share/doc/golang-guestfs/LICENSE /usr/share/doc/golang-guestfs/create-disk.go /usr/share/doc/golang-guestfs/inspect-vm.go /usr/share/man/man3/guestfs-golang.3.gz It's on my to-do list to take a look at the updated packaging draft to see how close we are to it. We matched the old packaging draft correctly at the time that I added the bindings. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- 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: SELinux RPM scriplet issue annoucement
On Mon, Jan 20, 2014 at 05:01:24PM -0800, Adam Williamson wrote: On Mon, 2014-01-20 at 17:00 -0800, Adam Williamson wrote: On Mon, 2014-01-20 at 15:35 -0500, Matthew Miller wrote: On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. *nod* Sounds good to me. what we have. I don't know how to quantify that point, though. All's I can do is reiterate that yes, this is a really significant pain point in our current processes, the proposed Bodhi 2.0 design would make things almost immeasurably better, and plead with anyone reading this who has the power to bump up the importance of / resources assigned to Bodhi 2.0's development to do so. So many things at top priority. :) I know Luke Macken is actually actively working it. I know he is. He's been actively working on it for the said three-four year period. Every FUDCon/Flock he tells me it's nearly done. ;) Not ragging Luke, but it rather seems like we need about six more of Unfortunately, bodhi has not had dedicated full-time development resources in a long time. Thankfully, I now have the cycles to put into new features, such as improving the feedback mechanisms. Many components of the Bodhi 2.0 vision are long-term, and rely on a plethora of other pieces to fall into place, such as python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so on. Other pieces of the puzzle can be implemented and deployed incrementally within the current tools now. My focus lately has been around the releng/infra side of the updates process, but for a feature that would make things 'immeasurably better' (even though I think it would actually be measurable :P), I'd be happy to shift gears to the QA/frontend side of things to help get it done sooner rather than later. As far as I can tell, you sent some ideas to a mailing list a few years ago about it, and then Mathieu started a prototype. I can't find any RFEs filed for it, so I'll create one and see what I can do about getting the existing prototype polished and integrated for testing. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Text-Reform] Fix bogus date in changelog
commit dab9364ebbb11e6e8966ec97e3f16cc1e58970df Author: Paul Howarth p...@city-fan.org Date: Tue Jan 21 19:40:13 2014 + Fix bogus date in changelog perl-Text-Reform.spec |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- diff --git a/perl-Text-Reform.spec b/perl-Text-Reform.spec index 2e2edee..b78ee8a 100644 --- a/perl-Text-Reform.spec +++ b/perl-Text-Reform.spec @@ -129,7 +129,7 @@ rm -rf $RPM_BUILD_ROOT - Minor spec cleanup. - Add Artistic. -* Fri Apr 7 2005 Michael Schwendt mschwendt[AT]users.sf.net +* Wed Apr 6 2005 Michael Schwendt mschwendt[AT]users.sf.net - rebuilt * Wed Jul 14 2004 Jose Pedro Oliveira jpo at di.uminho.pt - 0:1.11-0.fdr.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: Best Practices for Django App Packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/21/2014 02:12 PM, john.flor...@dart.biz wrote: From: sgall...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Date: 01/21/2014 13:24 Subject: Re: Best Practices for Django App Packaging Sent by: devel-boun...@lists.fedoraproject.org On 01/21/2014 11:22 AM, john.flor...@dart.biz wrote: On 01/21/2014 03:45 PM, john.flor...@dart.biz wrote: While I've been packaging Python apps for Fedora for a long time, I'm a complete novice to Django. I've just completed my first app (using the built-in development server) and now want to get it packaged. Thus far I've followed my normal model of using setuptools so that everything very cleanly lands in /usr/lib/python2.7/site-packages/my_package. My Django app is under there, along with other related Python modules that are used independently of the Django app. I'm not finding any docs in the Fedora package guidelines and am unaware of existing packages that might serve as excellent examples. My web searches are turning up lots, but nothing much specific to Fedora. At the moment, I'm particularly struggling with how to make my /etc/httpd/conf.d/myapp.conf point to my /usr/lib/python2.7/site-packages/my_package/my_site/wsgi.py in a good generic RPM spec sense. I'd rather not hard-code the Python version in myapp.conf. Any pointers would be greatly appreciated. If you want an exampple, please look at openstack-dashboard: [1] is the config file to be dropped at /etc/httpd/conf.d (for httpd-2.2) or [2] for httpd-2.4 The spec is here[3] for reference. HTH, Matthias [1] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard.conf [2] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ openstack-dashboard-httpd-2.4.conf [3] http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/ python-django-horizon.spec Thanks Matthias! That's quite a complicated example, although I can see there's much I can learn from it. Unfortunately, it's not the ideal example because it moves everything that setup.py builds into /usr/share/openstack-dashboard. I need to keep stuff under /usr/lib/pythonX.Y/site-packages so that the other, non-Django, parts continue to work as expected. (I suppose I could just relocate the Django-parts of the build, but sounds like it will break more things that it will help.) Another example you may want to take a look at is ReviewBoard, which is pretty straightforward. http://pkgs.fedoraproject.org/cgit/ReviewBoard.git/tree/ReviewBoard.spec Thank you too Stephen! That indeed does look much more similar. Although I don't see any Apache httpd config in the package. Reading The Fine Manual briefly looks like it relies on 'rb-site install' to do this part. I was hoping to find an example where the RPM spec dropped a Django app setup right into /etc/httpd/conf.d -- in other words, a package that just assumes you will use Apache httpd, maybe even creates an empty sqlite db so things are just ready to run with a httpd restart. I may be just trying to do too much in my spec and perhaps should rely on puppet to do the deployment and integration work. Well, part of the reasoning here is that Django supports sites. First of all, there's no default configuration that will likely ever work, because they need to create a custom Apache configuration for each hostname. Furthermore, you can install multiple different sites on the same machine in different URL paths. Finally, nobody uses SQLite for a real-world deployment (it's not built for that). It's good for development/testing, but it's not a real deployment case. So yes, the real expectation here should be that you deploy the bits you need and configure them with an appropriate tool. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLezk0ACgkQeiVVYja6o6PwEwCfZ1OFqYkG+x9WpD1MNalGt3Ky A+gAoKKggtn4GMGuieq2FaxQviKffx+m =WGKD -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best Practices for Django App Packaging
On 01/21/2014 05:22 PM, john.flor...@dart.biz wrote:
[1]
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
openstack-dashboard.conf
[2]
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
openstack-dashboard-httpd-2.4.conf
[3]
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
python-django-horizon.spec
Thanks Matthias! That's quite a complicated example, although I can see
there's much I can learn from it. Unfortunately, it's not the ideal
example because it moves everything that setup.py builds into
/usr/share/openstack-dashboard. I need to keep stuff under
/usr/lib/pythonX.Y/site-packages so that the other, non-Django, parts
continue to work as expected. (I suppose I could just relocate the
Django-parts of the build, but sounds like it will break more things
that it will help.)
Yes, you're right. It's not the ideal and simple example.
On the other side, it doesn't matter if you put all that stuff to
/usr/share or to %{python_sitelib}
Basically, you just need the two files. Stephen had another, more simple
example. This gets the job done. For most real world deployments you'd
need some more config changes (database, caching, ssl, and more securing).
Matthias
--
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 Server PRD Draft and call for participation
Stephen Gallagher (sgall...@redhat.com) said: The first deliverable that the Fedora Server Working Group was tasked with was the production of a Product Requirements Document. This document is intended to provide a high-level view of the goals and primary deliverables of the Fedora Server distribution. A great deal of discussion has gone on during the weekly Working Group meetings as well as on the mailing list. Admittedly late, but... Vision Fedora Server is the preferred [community] platform for system administrators and developers seeking to deploy applications and services that use the latest technology on a stable foundation with effective resource utilization. How does this differentiate from the market position of CentOS (community platform for deploying apps and services on a stable platform)? Do we care if it doesn't? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unannounced soname bump: libdbi?
Hi, Looks like yet another unannounced soname bump has occurred in Rawhide, this time libdbi. If there was an announcement, I haven't noticed it, and neither apparently have maintainers of dependent packages, and they haven't been addressed by anyone else either except for rrdtool which is currently being rebuilt. libdbi owners, comments? Please observe https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages Affected packages include at least: Io-language collectd-dbi gammu-libs gnucash python-gammu rrdtool rrdtool-lua rsyslog-libdbi syslog-ng-libdbi ulogd-libdbi -- 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: Environment and Stacks PRD
Marcela Mašláňová (mmasl...@redhat.com) said: Environment and Stacks Working Group approved the first version of PRD. Feel free to comment what is missing or what should be altered. https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document I don't see anything necessarily bad in what's written here, but the document seems to jump very quickly from the Vision statement into an itemized list of what appear to be work items, without an overarching framework or story linking the two. (Maybe moving the user stories up helps here, maybe not.) It seems hard to measure success against the vision for the group, as opposed to just measuring the success as 'implemented task/goal X'. Also, while it says that [t]his document does not dictate implementation details, the tasks and goals section does go into the weeds, especially in the SCL DevAssistant sections. Bill -- 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 Server PRD Draft and call for participation
On Tue, Jan 21, 2014 at 3:42 PM, Bill Nottingham nott...@redhat.com wrote: Stephen Gallagher (sgall...@redhat.com) said: The first deliverable that the Fedora Server Working Group was tasked with was the production of a Product Requirements Document. This document is intended to provide a high-level view of the goals and primary deliverables of the Fedora Server distribution. A great deal of discussion has gone on during the weekly Working Group meetings as well as on the mailing list. Admittedly late, but... Vision Fedora Server is the preferred [community] platform for system administrators and developers seeking to deploy applications and services that use the latest technology on a stable foundation with effective resource utilization. How does this differentiate from the market position of CentOS (community platform for deploying apps and services on a stable platform)? Do we care if it doesn't? I always thought that Fedora: o bleeding edge, where new stuff comes o new programs/kernels/drivers o Expect things might not be work or last o Versions change as fast as in ubuntu, if not faster o Trendsetter for RHES and CentOS RHES: o Takes stuff that can be used in servers that survived baptism of fire in Fedora o Long term FTW! o Slow changes, more security and patches CentOS: o Very very close to RHES, but by design 6 months behind it o Open support, open community like Fedora o More server related like RHES Bill -- 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
Security update process without CVEs
Hi: A few hours ago I submitted requests to push perl-MARC-XML directly to stable (by filling out the fedpkg update request with type=security and request=stable) I tried following https://fedoraproject.org/wiki/Security_Tracking_Bugs?rd=Security/TrackingBugs but it appears to depend on waiting on a CVE, which upstream did not yet have... but upstream had already pushed the new release to CPAN. Despite requesting stable, though, https://admin.fedoraproject.org/updates/perl-MARC-XML-1.0.2-1.fc19 shows that testing was requested. Should I wait, then push to stable? Or is this going to go to stable automatically? My apologies if I screwed up, but it didn't seem like a good idea to wait on the CVE... Thanks, Dan P.S. Please find here more apologies about only packaging updates on an irregular basis and therefore not being 100% plugged in :/ -- 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: Security update process without CVEs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Jan 21, 2014 at 04:26:19PM -0500, Dan Scott wrote: I tried following https://fedoraproject.org/wiki/Security_Tracking_Bugs?rd=Security/TrackingBugs but it appears to depend on waiting on a CVE, which upstream did not yet have... but upstream had already pushed the new release to CPAN. You may be able to request the CVE yourself. I'm trying to contact the guy that handles those things for FOSS but a netsplit is keeping me from talking to him at the moment. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJS3uccAAoJEB/kgVGp2CYvCuEL/3zXFKhsuD/0lFnejfugTw/P 9Lb+hV2BP9fDmcMZR1hW+feY8Wl8T/+nWfF3/GzTqLRn4HbfUMt3L86vo3piny1T Zzu/hPvDkvmOeMFdApko3+gyEF+ChUgWvtauj+yJ+/amLF6xC4btepH9RReBmesa cflhUxz2G7BH3hwQgt3sqNP9qbk58l7kXcFSAM6n7KT3PHoJv2JuJ+RL6g3bnGfh 5LgRZuCTqh821p0jMjq+Mps2P1dfCsyMLv3LjYR1noLGJlAVAMo9ulAD5j9ABSLc /z8O/0ZTDqcDQDV8WyhN2j70p/uhSy1XJ0IXVYskldmrnOQoT6y0bwMpD/zCG5jZ dGXpsepk6zud+0QVgvirK0/Dnidb51MU6n9zwSwK76rRgtTNUHa52D5VZ2EBgyDU 7pSfO95fzDXPnpD0VDeYwE2d3Y+sdCHnWIxyVyWxVSR0d1klPQ0+jXya1SgdThc1 R3R7yog5fne9P71qFndaZh9dGKihSPerBDPoSIPhCw== =LVnb -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unannounced soname bump: libdbi?
On 01/21/2014 03:53 PM, Ville Skyttä wrote: Hi, Looks like yet another unannounced soname bump has occurred in Rawhide, this time libdbi. If there was an announcement, I haven't noticed it, and neither apparently have maintainers of dependent packages, and they haven't been addressed by anyone else either except for rrdtool which is currently being rebuilt. FWIW, I only rebuilt rrdtool because it was preventing me from rebuilding ntop to fix a legal issue. :) ~tom == ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal -- 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: Security update process without CVEs
On Tue, 21 Jan 2014 16:26:19 -0500 Dan Scott deni...@gmail.com wrote: Hi: A few hours ago I submitted requests to push perl-MARC-XML directly to stable (by filling out the fedpkg update request with type=security and request=stable) You cannot push any update directly to stable. Security updates have to go though the same process as any other update. I tried following https://fedoraproject.org/wiki/Security_Tracking_Bugs?rd=Security/TrackingBugs but it appears to depend on waiting on a CVE, which upstream did not yet have... but upstream had already pushed the new release to CPAN. Despite requesting stable, though, https://admin.fedoraproject.org/updates/perl-MARC-XML-1.0.2-1.fc19 shows that testing was requested. Right. You cannot push directly to stable. Should I wait, then push to stable? Or is this going to go to stable automatically? You will need to wait until it gets +3 karma, or until the time (1 week) has elapsed. You could also adjust the karma needed down, but you will need it to be at least +1. My apologies if I screwed up, but it didn't seem like a good idea to wait on the CVE... No problem. Thanks, Dan P.S. Please find here more apologies about only packaging updates on an irregular basis and therefore not being 100% plugged in :/ It happens. Consider adding some co-maintainers to help out. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best Practices for Django App Packaging
From: mru...@matthias-runge.de
To: devel@lists.fedoraproject.org
Date: 01/21/2014 15:38
Subject: Re: Best Practices for Django App Packaging
Sent by: devel-boun...@lists.fedoraproject.org
On 01/21/2014 05:22 PM, john.flor...@dart.biz wrote:
[1]
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
openstack-dashboard.conf
[2]
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
openstack-dashboard-httpd-2.4.conf
[3]
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
python-django-horizon.spec
Thanks Matthias! That's quite a complicated example, although I can
see
there's much I can learn from it. Unfortunately, it's not the ideal
example because it moves everything that setup.py builds into
/usr/share/openstack-dashboard. I need to keep stuff under
/usr/lib/pythonX.Y/site-packages so that the other, non-Django, parts
continue to work as expected. (I suppose I could just relocate the
Django-parts of the build, but sounds like it will break more things
that it will help.)
Yes, you're right. It's not the ideal and simple example.
On the other side, it doesn't matter if you put all that stuff to
/usr/share or to %{python_sitelib}
Basically, you just need the two files. Stephen had another, more simple
example. This gets the job done. For most real world deployments you'd
need some more config changes (database, caching, ssl, and more
securing).
Matthias
Yup, I'm seeing it now. I realize sqlite is normally used for production
deployments, but in my case I would have been totally fine with it since I
know the number of user connections is always going to be less than 20
or so: one real human on rare occasions and the rest from machines that
are almost always going to get a cached page since they're each asking
once a minute for their own same page. However, SELinux made me adopt the
better practice of using Postgresql since all the policy is there for
that. :-)
I've got a deployed (test) setup roughly working now. Next step is to
clean up the hard to maintain it's fragile aspects. I will probably
wind up doing as openstack-dashboard does and moving some of the python
package/modules out of /usr/lib/pythonX.Y and into /usr/share/my_app since
the rpm spec can do that much smartly. Then my puppet manifests can refer
to things that aren't such moving targets.
I largely want to avoid a big mess of figuring out how to migrate the
deployed instance to new hosts as Fedora releases come out. (As a rule,
we never upgrade; just reinstall with much help from puppet. Think of it
as a fire drill.) Hopefully I'll get to keep playing with Django in the
future so it all doesn't become foreign 6 months from now.
Thanks to all for the pointers. They've been a big help.
--
John Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retiring my gnome-shell search providers
Hello, A while ago, I wrote a trio of gnome-shell search providers: https://apps.fedoraproject.org/packages/gnome-shell-search-fedora-packages https://apps.fedoraproject.org/packages/gnome-shell-search-github-repositories https://apps.fedoraproject.org/packages/gnome-shell-search-pinboard They once worked, and beautifully. I had big plans. Now, though, I can't muster the time to modernize and maintain them. None of them work against our current version of gnome-shell. All three have bugs filed against them. Is anyone interested in taking over any of them (both as Fedora package maintainer and as upstream?) If not, I plan to retire them in the next few weeks. pgptKozb6Os8N.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages up for grabs
On Wed, Jan 15, 2014 at 8:54 PM, Casper fan...@fedoraproject.org wrote: Mauricio Tavares a écrit : On Tue, Jan 14, 2014 at 1:07 AM, Casper fan...@fedoraproject.org wrote: Kevin Fenzi a écrit : Greetings. The following packages have been orphaned due to their former maintainer removing themselves from the packager group: NetPIPE checkdns taken, co-maintainers welcome I might volunteer as a co-maintainer so I learn the ropes and act like I know what I am doing. Good to hear :) but your FAS account is not actually in the packager group, so you can't take co-maintainership for any package in the pkgdb. The first step to apply in this group is described here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Thank you for the link! And, sorry for taking so long to reply, specially since only now I actually started reading it. So, let me finish with that so I can then start asking stupid questions. ;) -- Autorité de Certification: http://casperlefantom.net/root.pem Empreinte: 0975 864A 2036 0F94 A139 114A D32E 8EBE 30F2 2429 Clef GPG ID: 83288189 @ hkp://keys.fedoraproject.org Empreinte: CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 -- 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: Security update process without CVEs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Jan 21, 2014 at 04:31:10PM -0500, Eric H. Christensen wrote: On Tue, Jan 21, 2014 at 04:26:19PM -0500, Dan Scott wrote: I tried following https://fedoraproject.org/wiki/Security_Tracking_Bugs?rd=Security/TrackingBugs but it appears to depend on waiting on a CVE, which upstream did not yet have... but upstream had already pushed the new release to CPAN. You may be able to request the CVE yourself. I'm trying to contact the guy that handles those things for FOSS but a netsplit is keeping me from talking to him at the moment. And a response from the CVE guy... - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/21/2014 02:31 PM, Eric H. Christensen wrote: On Tue, Jan 21, 2014 at 04:26:19PM -0500, Dan Scott wrote: I tried following https://fedoraproject.org/wiki/Security_Tracking_Bugs?rd=Security/TrackingBugs but it appears to depend on waiting on a CVE, which upstream did not yet have... but upstream had already pushed the new release to CPAN. Has upstream requested a CVE yet? If so we'd be waiting on them. If not you can request one via the OSS-Security list: oss-secur...@lists.openwall.com and Mitre should assign one shortly. You may be able to request the CVE yourself. I'm trying to contact the guy that handles those things for FOSS but a netsplit is keeping me from talking to him at the moment. -- Eric - - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 - -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJS3u0gAAoJEBYNRVNeJnmT3e4QAKnxrlMTWPycff6+DSOrOEaE +VhUJVFgXwxT/9bFG8xXZKD/DPY5uigJF+DnLqtlrrLV5nZ3Dz+ZvTV1Vlb5N7xn Aa7LkmgDxnjVZVyutn77wBwc9Ga63CUTPCRnGQry/Fbshv9+kw7Jl+BERr7BMB/m z1xN3I98ig4FBnGRvg9SbXQgoQ8KGx8/JLLC1tMle6twK4xPM40FI8lkaG9eXluf MeyRzNknN2aiaWTL9qlPVw5RI5lJZnoQh+BYGNPiTCQcMH6FTlBAb1+hc7jkbPlL Lz0NL3g3FBDDXBq5tQ0oKm7q8hr/lF8/4EXhszAMCBXXWS7fxVF43wIXe3LMUmYx rYWzeuslDx3Sf9sbNPjURUkBif4sOioQ8O0rCbsC4n5iH4hkBH3XMOtJs/f4FsG9 WnTi1lwO6yK0uLsitYZISWBnru42R6o5kw61mygTyv8BbHV1v9gkCALNM3j1nwjB hQiitonD1fEHvTbXkm6qTpaKk6FmHZVazpAltRrwbfP5PP+a2nH/mfD0HKJx1U5B CvA4W30uNAnTXAe1H9nmhbnBHJbHXlOFT/zl+V5sRKmuHD5hf5m0/9zAgYOn0h1E SQZkxbXgCdH9jwWmSGsU9tgxJrMvuGJEr2KOpGVWsUX2bqSxmwqcFQieFa3QXNHF xjd3bjrT7cF5IgfmZADI =/7fk - -END PGP SIGNED MESSAGE- - --Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJS3u4ZAAoJEB/kgVGp2CYvKlIL/18Jk+/1iy9Homrb6CscmfDA V1+eNhoGAU8CZ8aCvAqzPk4AKktIZ6rdjuGV5axbGJBpCUfYSNRdaP5d/LY9YbNy cLfC+ShXUjObR8GKtwGaJhLlRZRaeQQte976ZvbntzXVCtwH/CcevNKmah0wpcFf QuKUToNT7HwQfv5/bRZOOYmwW1SZmRClzqNhExKcPUquZvahfd1NAf8uNopbamKA TgYzPkQ53Sn/dyfoQTaBKo9OpXsxlv8WxNIAwDRXDx8ZRkGjPZG6h2Xnt0Biuh2M F+epfd10BhUX9wrj+P2u2ztqWEQUXYCwTKaWGA8QiETrL/dRJ+dzSL+PKGT2/9jJ CvjStm6Y956hfAFTWCmgbYhf7bTu1mDiOlassQaNOZlMEO37zFl/ZMGP1MR5dYL8 tFAVFjWb4Ucxb0MGlddt3260LPxPFU9xgUaWtk+/+ci774oikQTsZSqfgWx9KbYF lm6tWLNBBRYDCuLDcNAvICBTrd7WXsJimGoaNBI3Wg== =ZTKy -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Re: Re: F20: Puppet depchain pulls in Java
On Sat, Jan 18, 2014 at 5:55 AM, Mo Morsi mmo...@redhat.com wrote: On 01/18/2014 01:40 AM, Michael Stahnke wrote: On Fri, Jan 17, 2014 at 6:53 PM, Rahul Sundaram methe...@gmail.com methe...@gmail.com wrote: Hi On Fri, Jan 17, 2014 at 9:43 PM, Mo Morsi wrote: Yes as others have mentioned puppet requires ruby(release) which is satisfied by both ruby-mri and jruby So should it just require ruby-mri? The divergence from the way upstreams handle ruby here is quite difficult to work with. I find ruby-pick and bundler patching to be less fun/friendly than having what I'd expect form upstream. I'm not in love with the way upstream handles/does things, but I don't really understand what happened to the 'upstream first' mantra. Here we (Fedora) just made up their own rules and moved forward. Could you elaborate on what the difficulty is? Just curious as to what issues there are. I've had issues in the past with Ruby pick when it was first being developed. I know some apps (and possibly some gems) expected env ruby to eval to a ruby and not ruby-pick shell helpers. That may not be the case any more, as I haven't run into that in a while. (Though I don't always use the Fedora ruby any more either). I remember having to unpatch bundler to do what I wanted. Now, I basically hate bundler, but when it works differently on Fedora than it does on other platforms that only makes it worse. Completely agree that the current Fedora/Ruby integration is not ideal, it is a work in progress afterall. That being said upstream Ruby practices and downstream Fedora guidelines do take different approaches to many various things, eg just the existence of bundler is counter to Fedora's 'no-vendored-deps' policy. So compromises will have to be made at some level. Yes, bundler is counter to the the philosophy. So is golang. Sadly, people spend person-years redoing this work then with statically linked or bundled stuff. I don't love it at all, but I do see big upticks in all-in-one packages (omnibus, fpm, etc) in the community -- at least around configuration/cloud automation. And they all complain about distro packaging because of maintainers modifying upstream behavior. This is normally a larger issue on other distros (not Fedora), but we are not immune to it. We try our best to make everyone happy, providing as much of the flexibility associated with upstream Ruby practices that we can while still adhering to Fedora's principles and strategies. Now if we could install multiple versions of a rubygem rpm via yum, that'd help us out a bit. ... which is fine. However yum install puppet should be pulling in only one. Not both. I would say almost everybody would expect that to be ruby-mri I would say exactly everybody, since on jruby there are issues. Didn't know puppet didn't work on JRuby, what about the other Ruby interpreters such as Rubinius? If MRI is the only supported solution for Puppet, then yes I'd agree that specific dep should be there (though am not the package maintainer myself), but if it can work against multiple backends then why not let the user decide? We (Puppet Labs) tries to keep test passing in Jruby, but there a few bugs. I think master side it works ok, unless you have providers that use C extension gems. Agent side, we do no testing of running on Jruby. We'll be doing much more with Jruby master side in the future, so those bugs (if they haven't already been) should be worked out soon. We don't test rubinius, but we have a few fans of it here. I'd be curious if our spec tests pass on that. I'd be happy to look into those details more, but we should probably move the conversation to a different thread. -Mo -- 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: Security update process without CVEs
On Tue, Jan 21, 2014 at 4:32 PM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 21 Jan 2014 16:26:19 -0500 Dan Scott deni...@gmail.com wrote: Hi: A few hours ago I submitted requests to push perl-MARC-XML directly to stable (by filling out the fedpkg update request with type=security and request=stable) You cannot push any update directly to stable. Security updates have to go though the same process as any other update. Okay, then I'll remove the conflicting information from http://fedoraproject.org/wiki/Package_update_HOWTO that says: If you feel that community testing is unnecessary for your update, you can choose to push it straight to the stable fedora-updates repository instead. Pushing directly to stable skips peer review and is strongly discouraged!! Note that security updates follow a slightly different process . (and which led me to the security update process that assumes that the packager is coming at this after the CVE has already been published and the Security Response Team has already opened a bug, rather than the packager him-or-herself proactively handling the issue). Hmm. Why does the fedpkg update template even offer a stable request option, then, if the only real option is testing? snip more reassurance that security updates follow normal update process P.S. Please find here more apologies about only packaging updates on an irregular basis and therefore not being 100% plugged in :/ It happens. Consider adding some co-maintainers to help out. I'm not entirely sure how to interpret that suggestion. I jumped on this within minutes of the upstream security release announcement, so I don't think you're suggesting that I was slacking. It is my first time handling a security release, and I ran into package update instructions that conflicted with what I was experiencing, so I asked questions to clarify that conflict--and I don't think they were stupid questions. I tried asking on #fedora-devel (but was ignored) before posting here for what I thought was a time-important matter due to the security considerations. What kind of help would co-maintainers have offered in this case? -- 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: Security update process without CVEs
On Tue, 21 Jan 2014 17:38:54 -0500 Dan Scott deni...@gmail.com wrote: Okay, then I'll remove the conflicting information from http://fedoraproject.org/wiki/Package_update_HOWTO that says: If you feel that community testing is unnecessary for your update, you can choose to push it straight to the stable fedora-updates repository instead. Pushing directly to stable skips peer review and is strongly discouraged!! Note that security updates follow a slightly different process . (and which led me to the security update process that assumes that the packager is coming at this after the CVE has already been published and the Security Response Team has already opened a bug, rather than the packager him-or-herself proactively handling the issue). Yeah, thats old/out of date... http://fedoraproject.org/wiki/Updates_Policy Hmm. Why does the fedpkg update template even offer a stable request option, then, if the only real option is testing? Historical reasons I guess. Could get that updated in bodhi... snip more reassurance that security updates follow normal update process P.S. Please find here more apologies about only packaging updates on an irregular basis and therefore not being 100% plugged in :/ It happens. Consider adding some co-maintainers to help out. I'm not entirely sure how to interpret that suggestion. I jumped on this within minutes of the upstream security release announcement, so I don't think you're suggesting that I was slacking. It is my first time handling a security release, and I ran into package update instructions that conflicted with what I was experiencing, so I asked questions to clarify that conflict--and I don't think they were stupid questions. I tried asking on #fedora-devel (but was ignored) before posting here for what I thought was a time-important matter due to the security considerations. What kind of help would co-maintainers have offered in this case? I was just responding to your irregular basis... not 100% plugged in comment. I thought you meant that you didn't have time for updates usually. If you do, then great. Sorry for missing your message on irc. Often people are busy. They aren't sitting there looking at your message and deliberately ignoring you. :) Repeating after a while is often good... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announce: fedostree/rpm-ostree v2014.3
On 21.01.2014 08:30, Colin Walters wrote: Hi Dennis, On Tue, 2014-01-21 at 07:40 +0100, Dennis Jacobfeuerborn wrote: Interesting. I've downloaded the VM Image and tried to understand the setup. Some bits are documented here https://people.gnome.org/~walters/ostree/doc/layout.html Apparently there exist sort of two root trees / and /sysroot in the system with some links targeting the /sysroot tree. With OSTree, you boot directly into a chroot - dracut switches root and starts systemd right after mounting the rootfs. See: https://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-prepare-root.c /sysroot is a bind mount to the real root /. What I'm wondering about is that /dev/mapper/fedora-root is mounted several times on /, /var, /usr and /sysroot (twice!) sometimes rw and sometimes ro. /usr is simply a bind mount to itself so it can be mounted read-only. This is important because otherwise one could corrupt the object store in /ostree/repo by mutating the hardlink farm in /usr. Note the /usr here is really /ostree/deploy/fedostree/deploy/checksum.serial/usr as seen from the physical root. /var is a special bind mount to /ostree/deploy/fedostree/var which is shared between each deployment (chroot). The impression I get is that /sysroot is the actual root fs in the image and / the ostree directory at least that's what the links seem to suggest. I still don't understand the mount-voodoo though. Is there some documentation about this available? I'll look at adding more to the gtk-doc, though I suspect I may need to make a separate system administrators new to OSTree document which is a bit distinct from the how to use OSTree underneath your package manager document that the current one is. Thanks for the information. I think I was thrown off by the fact that the root device is mounted in several places with different content but now I realize that's probably because the external path isn't available from inside the jail so mount can only display the device. Previously I've only used bind mounts in a non-chroot context. Regards, Dennis -- 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: Announce: fedostree/rpm-ostree v2014.3
On 21.01.2014 20:07, Richard W.M. Jones wrote: On Tue, Jan 21, 2014 at 07:40:00AM +0100, Dennis Jacobfeuerborn wrote: Interesting. I've downloaded the VM Image and tried to understand the setup. Apparently there exist sort of two root trees / and /sysroot in the system with some links targeting the /sysroot tree. What I'm wondering about is that /dev/mapper/fedora-root is mounted several times on /, /var, /usr and /sysroot (twice!) sometimes rw and sometimes ro. The impression I get is that /sysroot is the actual root fs in the image and / the ostree directory at least that's what the links seem to suggest. I still don't understand the mount-voodoo though. Is there some documentation about this available? Out of interest, did you boot into the alternate tree, ie: bls_import at the boot prompt? (Documented in http://rpm-ostree.cloud.fedoraproject.org/#/installation) Yes, hence the funky directory layout :) Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-01-22)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-01-22 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1197Procedure for suggesting/approving different Products and/or WGs? .fesco 1197 https://fedorahosted.org/fesco/ticket/1197 = New business = #topic #1222 PRD Approval Request: Server PRD .fesco 1222 https://fedorahosted.org/fesco/ticket/1222 #topic #1224 PRD Approval Request: Env and Stacks PRD .fesco 1224 https://fedorahosted.org/fesco/ticket/1224 #topic #1225 PRD Approval Request: Cloud PRD .fesco 1225 https://fedorahosted.org/fesco/ticket/1225 #topic #1226 Workstation PRD for approval .fesco 1226 https://fedorahosted.org/fesco/ticket/1226 #topic #1221 Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What to do about packaging beta, or rc as alternate installable
One of the packages I maintain is mercurial. Frequently (e.g., now), there
is a rc version available for test. It will probably break some other package
that depends on it.
I am thinking of a model like google uses for chrome. I could install any of:
google-chrome-{stable,beta,unstable}
I don't think fedora uses this model anywhere. AFAICT, in Fedora there is
always only 1 version available - although there could be one in updates-
testing. But the purpose of updates-testing is now for a long-lived parallel
development - it is designed for short term before promotion to stable.
Although the google-chrome model is perhaps not the ideal way to handle the
idea of alternative versions - it seems good enough.
Any thoughts?
--
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: What to do about packaging beta, or rc as alternate installable
On Tue, Jan 21, 2014 at 7:33 PM, Neal Becker ndbeck...@gmail.com wrote:
One of the packages I maintain is mercurial. Frequently (e.g., now), there
is a rc version available for test. It will probably break some other package
that depends on it.
I am thinking of a model like google uses for chrome. I could install any of:
google-chrome-{stable,beta,unstable}
I don't think fedora uses this model anywhere. AFAICT, in Fedora there is
always only 1 version available - although there could be one in updates-
testing. But the purpose of updates-testing is now for a long-lived parallel
development - it is designed for short term before promotion to stable.
Although the google-chrome model is perhaps not the ideal way to handle the
idea of alternative versions - it seems good enough.
Any thoughts?
You could provide it in a copr. That is what e.g. Ryan Lerch does
with unreleased builds of his corebird package.
http://copr.fedoraproject.org/
josh
--
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 Server PRD Draft and call for participation
On Tue, Jan 21, 2014 at 1:02 PM, Mauricio Tavares raubvo...@gmail.com wrote: Fedora: o bleeding edge, where new stuff comes Cutting edge. Let's not ride the metaphor overly far [1]. We do actually test a fair bit before releasing Fedora or package updates. [1] https://en.wikipedia.org/wiki/Bleeding_edge_technology -- 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: What to do about packaging beta, or rc as alternate installable
Seriously, it's harmful to provide unstable packages to users. And I don't think Fedora has a long term support. -- 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: What to do about packaging beta, or rc as alternate installable
On Tue, Jan 21, 2014 at 8:58 PM, Christopher Meng cicku...@gmail.com wrote: Seriously, it's harmful to provide unstable packages to users. Still, it makes sense to have a place to beta test either the package or the packaging (how to create a proper package?) itself. And I don't think Fedora has a long term support. -- 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: What to do about packaging beta, or rc as alternate installable
On Tue, 2014-01-21 at 21:03 -0500, Mauricio Tavares wrote: On Tue, Jan 21, 2014 at 8:58 PM, Christopher Meng cicku...@gmail.com wrote: Seriously, it's harmful to provide unstable packages to users. Still, it makes sense to have a place to beta test either the package or the packaging (how to create a proper package?) itself. That would be an ideal use for a copr or fedorapeople repo. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: What to do about packaging beta, or rc as alternate installable
On Jan 22, 2014 10:03 AM, Mauricio Tavares raubvo...@gmail.com wrote: Still, it makes sense to have a place to beta test either the package or the packaging (how to create a proper package?) itself. It's hard to say how to create a proper package testing in one slot of pkgdb. Also it may be a burden when you don't have enough time to contribute. But you can do this on copr IMO. Also update-testing is not just a place for updates to have a break, you can let it satisfy the needs of testing for unstable. -- 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: What to do about packaging beta, or rc as alternate installable
On Tue, 2014-01-21 at 19:33 -0500, Neal Becker wrote:
One of the packages I maintain is mercurial. Frequently (e.g., now), there
is a rc version available for test. It will probably break some other package
that depends on it.
I am thinking of a model like google uses for chrome. I could install any of:
google-chrome-{stable,beta,unstable}
I don't think fedora uses this model anywhere. AFAICT, in Fedora there is
always only 1 version available - although there could be one in updates-
testing.
Just for the record, of course we can have multiple different packages
that contain different versions of the same source. This is permitted in
specific situations, but generally frowned upon: details are in the
guidelines. It's most commonly used to provide multiple versions of
libraries where we really want to have packages that depend on different
versions of the library.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File JavaScript-Minifier-1.08.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-JavaScript-Minifier: 4ae40e970f657792720d42c92fe58cd1 JavaScript-Minifier-1.08.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-JavaScript-Minifier] 1.08 bump
commit 2fb5065183ebf6174ddfa5fafbbc47ffe8ea914f
Author: Jitka Plesnikova jples...@redhat.com
Date: Tue Jan 21 10:35:15 2014 +0100
1.08 bump
.gitignore|1 +
perl-JavaScript-Minifier.spec |9 ++---
sources |2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a7f9419..8c4057a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
JavaScript-Minifier-1.05.tar.gz
/JavaScript-Minifier-1.06.tar.gz
+/JavaScript-Minifier-1.08.tar.gz
diff --git a/perl-JavaScript-Minifier.spec b/perl-JavaScript-Minifier.spec
index 0a93c70..80b4715 100644
--- a/perl-JavaScript-Minifier.spec
+++ b/perl-JavaScript-Minifier.spec
@@ -1,14 +1,14 @@
Name: perl-JavaScript-Minifier
-Version:1.06
+Version:1.08
Release:1%{?dist}
Summary:Perl extension for minifying JavaScript code
-License:(GPL+ or Artistic) or Artistic 2.0
+License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/JavaScript-Minifier/
Source0:
http://www.cpan.org/authors/id/Z/ZO/ZOFFIX/JavaScript-Minifier-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
# Run-Time
BuildRequires: perl(Exporter)
BuildRequires: perl(strict)
@@ -47,6 +47,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jan 21 2014 Jitka Plesnikova jples...@redhat.com - 1.08-1
+- 1.08 bump
+
* Mon Jan 20 2014 Jitka Plesnikova jples...@redhat.com - 1.06-1
- 1.06 bump
- Modernize spec file
diff --git a/sources b/sources
index 9a52f1d..62ccafc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b82ecded33652b78b3ed8234a0b147fd JavaScript-Minifier-1.06.tar.gz
+4ae40e970f657792720d42c92fe58cd1 JavaScript-Minifier-1.08.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1055291] perl-JavaScript-Minifier-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055291 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-JavaScript-Minifier-1. ||06-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-01-21 04:37:33 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Y5Jk5ydLUSa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1055945] New: perl-DBI-1.631 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055945 Bug ID: 1055945 Summary: perl-DBI-1.631 is available Product: Fedora Version: rawhide Component: perl-DBI Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.631 Current version/release in Fedora Rawhide: 1.630-2.fc21 URL: http://search.cpan.org/dist/DBI/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=PHNHfDZ9Yya=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1055947] New: perl-IO-Socket-IP-0.27 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055947 Bug ID: 1055947 Summary: perl-IO-Socket-IP-0.27 is available Product: Fedora Version: rawhide Component: perl-IO-Socket-IP Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.27 Current version/release in Fedora Rawhide: 0.26-1.fc21 URL: http://search.cpan.org/dist/IO-Socket-IP/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gHuTwOtUTga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File DBD-mysql-4.026.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-DBD-MySQL: b18dc2795ec8628a9b84b6e5f1b58775 DBD-mysql-4.026.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-DBD-MySQL] 4.026 bump
commit 8b3744b00445cfa08dc582510e2f78a6d64af8a9
Author: Jitka Plesnikova jples...@redhat.com
Date: Tue Jan 21 11:00:53 2014 +0100
4.026 bump
.gitignore |1 +
perl-DBD-MySQL.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8b0a527..a54813b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ DBD-mysql-4.017.tar.gz
/DBD-mysql-4.023.tar.gz
/DBD-mysql-4.024.tar.gz
/DBD-mysql-4.025.tar.gz
+/DBD-mysql-4.026.tar.gz
diff --git a/perl-DBD-MySQL.spec b/perl-DBD-MySQL.spec
index b093de8..63136fc 100644
--- a/perl-DBD-MySQL.spec
+++ b/perl-DBD-MySQL.spec
@@ -1,5 +1,5 @@
Name: perl-DBD-MySQL
-Version:4.025
+Version:4.026
Release:1%{?dist}
Summary:A MySQL interface for Perl
Group: Development/Libraries
@@ -66,6 +66,9 @@ find %{buildroot} -type f -name '*.bs' -empty -exec rm -f {}
';'
%{_mandir}/man3/*.3*
%changelog
+* Tue Jan 21 2014 Jitka Plesnikova jples...@redhat.com - 4.026-1
+- 4.026 bump
+
* Tue Nov 05 2013 Jitka Plesnikova jples...@redhat.com - 4.025-1
- 4.025 bump
diff --git a/sources b/sources
index 67dacda..f3a7cc1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-093ed74c3bd327d4e0d0bc70d1035ac3 DBD-mysql-4.025.tar.gz
+b18dc2795ec8628a9b84b6e5f1b58775 DBD-mysql-4.026.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Net-SSLGlue-1.052.tar.gz uploaded to lookaside cache by remi
A file has been added to the lookaside cache for perl-Net-SSLGlue: 25823d8e45eefacc291e3373f84b27df Net-SSLGlue-1.052.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1054111] perl-DBD-MySQL-4.026 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1054111 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-DBD-MySQL-4.026-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-01-21 05:18:29 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=SIlD63Ow8ra=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLGlue] update to 1.052
commit 6c0021b1e3db4d9109653458d17fcb5f49211c2c
Author: Remi Collet r...@fedoraproject.org
Date: Tue Jan 21 11:19:43 2014 +0100
update to 1.052
.gitignore |1 +
perl-Net-SSLGlue-test.patch | 31 +--
perl-Net-SSLGlue.spec |9 ++---
sources |2 +-
4 files changed, 25 insertions(+), 18 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5ba8336..1e5d00f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Net-SSLGlue-1.01.tar.gz
/Net-SSLGlue-1.03.tar.gz
/Net-SSLGlue-1.04.tar.gz
+/Net-SSLGlue-1.052.tar.gz
diff --git a/perl-Net-SSLGlue-test.patch b/perl-Net-SSLGlue-test.patch
index 53b48a6..cb2b796 100644
--- a/perl-Net-SSLGlue-test.patch
+++ b/perl-Net-SSLGlue-test.patch
@@ -1,18 +1,21 @@
Makefile.PL.orig 2010-02-21 17:49:52.0 +0100
-+++ Makefile.PL2010-02-21 17:55:04.0 +0100
-@@ -1,14 +1,10 @@
+--- Makefile.PL.orig 2014-01-21 11:11:51.244004427 +0100
Makefile.PL2014-01-21 11:11:46.558989697 +0100
+@@ -1,16 +1,13 @@
use ExtUtils::MakeMaker;
require 5.008;
-my $xt = prompt( Should I do external tests?\n.
-- These tests will fail if there is no internet connection or if a
firewall\n.
-- blocks some traffic.\n.
-- [y/N], 'n' );
+-These tests will fail if there is no internet connection or if a
firewall\n.
+-blocks some traffic.\n.
+-[y/N], 'n' );
++
WriteMakefile(
- NAME = 'Net::SSLGlue',
- VERSION_FROM = 'lib/Net/SSLGlue.pm',
- PREREQ_PM = {
- 'IO::Socket::SSL' = 1.19,
- },
-- $xt =~m{^y}i ? ( test = { TESTS = 't/*.t t/external/*.t' }):(),
-+ test = { TESTS = 't/*.t' },
- );
+ NAME = 'Net::SSLGlue',
+ VERSION_FROM = 'lib/Net/SSLGlue.pm',
+ PREREQ_PM = {
+ 'IO::Socket::SSL' = 1.19,
+ },
+-$xt =~m{^y}i ? ( test = { TESTS = 't/*.t t/external/*.t' }):(),
++test = { TESTS = 't/*.t' },
+ META_MERGE = {
+ resources = {
+ repository = 'https://github.com/noxxi/p5-net-sslglue',
diff --git a/perl-Net-SSLGlue.spec b/perl-Net-SSLGlue.spec
index ccfa6f1..ff42e59 100644
--- a/perl-Net-SSLGlue.spec
+++ b/perl-Net-SSLGlue.spec
@@ -1,5 +1,5 @@
Name: perl-Net-SSLGlue
-Version:1.04
+Version:1.052
Release:1%{?dist}
Summary:Add/extend SSL support for common perl modules
License:GPL+ or Artistic
@@ -16,7 +16,9 @@ BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(IO::Socket::SSL) = 1.19
# Required to have tests effective
-BuildRequires: perl(LWP::Protocol::https) perl(Net::LDAP) perl(Net::SMTP)
+BuildRequires: perl(LWP::Protocol::https)
+BuildRequires: perl(Net::LDAP)
+BuildRequires: perl(Net::SMTP)
Requires: perl(IO::Socket::SSL) = 1.19
Requires: perl(LWP::Protocol::https)
@@ -70,12 +72,13 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc COPYRIGHT TODO README Changes examples
+%doc COPYRIGHT README Changes examples
%{perl_vendorlib}/Net
%{_mandir}/man3/Net*
%changelog
+* Tue Jan 21 2014 Remi Collet r...@fedoraproject.org - 1.052-1
* Mon Aug 5 2013 Remi Collet r...@fedoraproject.org - 1.04-1
- update to 1.04
diff --git a/sources b/sources
index 81ef2a2..1b3e46b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8a6116f625eb5cb58791359f89800234 Net-SSLGlue-1.04.tar.gz
+25823d8e45eefacc291e3373f84b27df Net-SSLGlue-1.052.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-Net-SSLGlue/f20] update to 1.052
Summary of changes: 6c0021b... update to 1.052 (*) (*) 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
File Fedora-Rebuild-v0.11.0.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Fedora-Rebuild: c9a76f94fff4abe96961727a2ba132eb Fedora-Rebuild-v0.11.0.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-Fedora-Rebuild] 0.11.0 bump
commit 5b802b4439f39f4171967bd8a286ff37e1b376ed
Author: Petr Písař ppi...@redhat.com
Date: Tue Jan 21 11:25:53 2014 +0100
0.11.0 bump
.gitignore |1 +
perl-Fedora-Rebuild.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 29e5646..7b7117c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
/Fedora-Rebuild-v0.9.0.tar.gz
/Fedora-Rebuild-v0.9.1.tar.gz
/Fedora-Rebuild-v0.10.0.tar.gz
+/Fedora-Rebuild-v0.11.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index 97ed8ed..c8ffc29 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,6 +1,6 @@
# This file is lincensed under the terms of GPLv2+.
Name: perl-Fedora-Rebuild
-Version:0.10.0
+Version:0.11.0
Release:1%{?dist}
Summary:Rebuilds Fedora packages from scratch
License:GPLv3+
@@ -81,6 +81,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jan 21 2014 Petr Pisar ppi...@redhat.com - 0.11.0-1
+- 0.11.0 bump
+
* Thu Nov 07 2013 Petr Pisar ppi...@redhat.com - 0.10.0-1
- 0.10.0 bump
diff --git a/sources b/sources
index f161634..c09891c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-651705dd3754fe2574843da5e67f2c52 Fedora-Rebuild-v0.10.0.tar.gz
+c9a76f94fff4abe96961727a2ba132eb Fedora-Rebuild-v0.11.0.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-Fedora-Rebuild/f20] 0.11.0 bump
Summary of changes: 5b802b4... 0.11.0 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Fedora-Rebuild/f19] 0.11.0 bump
commit 33f28df47bb5e40ef27c373e2c12fd1cc9113e61
Author: Petr Písař ppi...@redhat.com
Date: Tue Jan 21 11:25:53 2014 +0100
0.11.0 bump
.gitignore |1 +
perl-Fedora-Rebuild.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 29e5646..7b7117c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
/Fedora-Rebuild-v0.9.0.tar.gz
/Fedora-Rebuild-v0.9.1.tar.gz
/Fedora-Rebuild-v0.10.0.tar.gz
+/Fedora-Rebuild-v0.11.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index 8b7e3bf..63295eb 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,6 +1,6 @@
# This file is lincensed under the terms of GPLv2+.
Name: perl-Fedora-Rebuild
-Version:0.10.0
+Version:0.11.0
Release:1%{?dist}
Summary:Rebuilds Fedora packages from scratch
License:GPLv3+
@@ -81,6 +81,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jan 21 2014 Petr Pisar ppi...@redhat.com - 0.11.0-1
+- 0.11.0 bump
+
* Thu Nov 07 2013 Petr Pisar ppi...@redhat.com - 0.10.0-1
- 0.10.0 bump
diff --git a/sources b/sources
index f161634..c09891c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-651705dd3754fe2574843da5e67f2c52 Fedora-Rebuild-v0.10.0.tar.gz
+c9a76f94fff4abe96961727a2ba132eb Fedora-Rebuild-v0.11.0.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-Net-SSLGlue/f19] update to 1.052
commit 2e4aa0075c2c4ccb59df83121734caed9d90c826
Author: Remi Collet r...@fedoraproject.org
Date: Tue Jan 21 11:19:43 2014 +0100
update to 1.052
(cherry picked from commit 6c0021b1e3db4d9109653458d17fcb5f49211c2c)
.gitignore |1 +
perl-Net-SSLGlue-test.patch | 31 +--
perl-Net-SSLGlue.spec |9 ++---
sources |2 +-
4 files changed, 25 insertions(+), 18 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5ba8336..1e5d00f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Net-SSLGlue-1.01.tar.gz
/Net-SSLGlue-1.03.tar.gz
/Net-SSLGlue-1.04.tar.gz
+/Net-SSLGlue-1.052.tar.gz
diff --git a/perl-Net-SSLGlue-test.patch b/perl-Net-SSLGlue-test.patch
index 53b48a6..cb2b796 100644
--- a/perl-Net-SSLGlue-test.patch
+++ b/perl-Net-SSLGlue-test.patch
@@ -1,18 +1,21 @@
Makefile.PL.orig 2010-02-21 17:49:52.0 +0100
-+++ Makefile.PL2010-02-21 17:55:04.0 +0100
-@@ -1,14 +1,10 @@
+--- Makefile.PL.orig 2014-01-21 11:11:51.244004427 +0100
Makefile.PL2014-01-21 11:11:46.558989697 +0100
+@@ -1,16 +1,13 @@
use ExtUtils::MakeMaker;
require 5.008;
-my $xt = prompt( Should I do external tests?\n.
-- These tests will fail if there is no internet connection or if a
firewall\n.
-- blocks some traffic.\n.
-- [y/N], 'n' );
+-These tests will fail if there is no internet connection or if a
firewall\n.
+-blocks some traffic.\n.
+-[y/N], 'n' );
++
WriteMakefile(
- NAME = 'Net::SSLGlue',
- VERSION_FROM = 'lib/Net/SSLGlue.pm',
- PREREQ_PM = {
- 'IO::Socket::SSL' = 1.19,
- },
-- $xt =~m{^y}i ? ( test = { TESTS = 't/*.t t/external/*.t' }):(),
-+ test = { TESTS = 't/*.t' },
- );
+ NAME = 'Net::SSLGlue',
+ VERSION_FROM = 'lib/Net/SSLGlue.pm',
+ PREREQ_PM = {
+ 'IO::Socket::SSL' = 1.19,
+ },
+-$xt =~m{^y}i ? ( test = { TESTS = 't/*.t t/external/*.t' }):(),
++test = { TESTS = 't/*.t' },
+ META_MERGE = {
+ resources = {
+ repository = 'https://github.com/noxxi/p5-net-sslglue',
diff --git a/perl-Net-SSLGlue.spec b/perl-Net-SSLGlue.spec
index af92657..363c7f9 100644
--- a/perl-Net-SSLGlue.spec
+++ b/perl-Net-SSLGlue.spec
@@ -1,5 +1,5 @@
Name: perl-Net-SSLGlue
-Version:1.04
+Version:1.052
Release:1%{?dist}
Summary:Add/extend SSL support for common perl modules
License:GPL+ or Artistic
@@ -16,7 +16,9 @@ BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(IO::Socket::SSL) = 1.19
# Required to have tests effective
-BuildRequires: perl(LWP::Protocol::https) perl(Net::LDAP) perl(Net::SMTP)
+BuildRequires: perl(LWP::Protocol::https)
+BuildRequires: perl(Net::LDAP)
+BuildRequires: perl(Net::SMTP)
Requires: perl(IO::Socket::SSL) = 1.19
Requires: perl(LWP::Protocol::https)
@@ -70,12 +72,13 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc COPYRIGHT TODO README Changes examples
+%doc COPYRIGHT README Changes examples
%{perl_vendorlib}/Net
%{_mandir}/man3/Net*
%changelog
+* Tue Jan 21 2014 Remi Collet r...@fedoraproject.org - 1.052-1
* Mon Aug 5 2013 Remi Collet r...@fedoraproject.org - 1.04-1
- update to 1.04
diff --git a/sources b/sources
index 81ef2a2..1b3e46b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8a6116f625eb5cb58791359f89800234 Net-SSLGlue-1.04.tar.gz
+25823d8e45eefacc291e3373f84b27df Net-SSLGlue-1.052.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-Net-SSLGlue/epel7] update to 1.052
Summary of changes: 2e4aa00... update to 1.052 (*) (*) 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
File DBI-1.631.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-DBI: 444d3c305e86597e11092b517794a840 DBI-1.631.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-DBI] 1.631 bump
commit 768627669ac187b8e3e406f2dc11b76d89a650e7
Author: Jitka Plesnikova jples...@redhat.com
Date: Tue Jan 21 12:08:00 2014 +0100
1.631 bump
.gitignore|1 +
perl-DBI.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f660965..8f8db17 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@ DBI-1.613.tar.gz
/DBI-1.627.tar.gz
/DBI-1.628.tar.gz
/DBI-1.630.tar.gz
+/DBI-1.631.tar.gz
diff --git a/perl-DBI.spec b/perl-DBI.spec
index a009e9a..a27ad63 100644
--- a/perl-DBI.spec
+++ b/perl-DBI.spec
@@ -7,8 +7,8 @@
%endif
Name: perl-DBI
-Version:1.630
-Release:2%{?dist}
+Version:1.631
+Release:1%{?dist}
Summary:A database access API for perl
Group: Development/Libraries
License:GPL+ or Artistic
@@ -141,6 +141,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Jan 21 2014 Jitka Plesnikova jples...@redhat.com - 1.631-1
+- 1.631 bump
+
* Tue Nov 26 2013 Petr Pisar ppi...@redhat.com - 1.630-2
- Add a security warning about use of RPC::PlClient (bug #1030578)
diff --git a/sources b/sources
index 3ecf5de..ebfbc07 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-306020fe7b54a53773f54ad581af8c54 DBI-1.630.tar.gz
+444d3c305e86597e11092b517794a840 DBI-1.631.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1055945] perl-DBI-1.631 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055945 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-DBI-1.631-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-01-21 06:27:06 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fkjfypdR7ga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Sys-Virt-1.2.1.tar.gz uploaded to lookaside cache by berrange
A file has been added to the lookaside cache for perl-Sys-Virt: 6203ae7a5f1e62d27fba4ad4a168ad12 Sys-Virt-1.2.1.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-Sys-Virt] Update to 1.2.1 release
commit 932b359029b77fb56e418fdf15f98a497dfb9ad0
Author: Daniel P. Berrange berra...@redhat.com
Date: Tue Jan 21 12:19:47 2014 +
Update to 1.2.1 release
Signed-off-by: Daniel P. Berrange berra...@redhat.com
perl-Sys-Virt.spec |5 -
sources|2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index edc96d3..af97534 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,7 +1,7 @@
# Automatically generated by perl-Sys-Virt.spec.PL
Name: perl-Sys-Virt
-Version:1.2.0
+Version:1.2.1
Release:1%{?dist}%{?extra_release}
Summary:Represent and manage a libvirt hypervisor connection
License:GPLv2+ or Artistic
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Jan 21 2014 Daniel P. Berrange berra...@redhat.com - 1.2.1-1
+- Update to 1.2.1 release
+
* Mon Dec 2 2013 Daniel P. Berrange berra...@redhat.com - 1.2.0-1
- Update to 1.2.0 release
diff --git a/sources b/sources
index a891a6e..f3fc282 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bbb9c252ae785bd07d8a176b9be828e4 Sys-Virt-1.2.0.tar.gz
+6203ae7a5f1e62d27fba4ad4a168ad12 Sys-Virt-1.2.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-Socket-IP-0.27.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-IO-Socket-IP: 2bc43f6fb1e8c1c6350fe507cf5413e2 IO-Socket-IP-0.27.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
