Re: Is there any value to per-Fedora branch ACLs?
Toshio Kuratomi venit, vidit, dixit 08.12.2010 01:44: On Tue, Dec 07, 2010 at 10:20:28AM -0800, Jesse Keating wrote: While I'm looking into the git setup and ACLs and all this, I have a question. Is anybody seeing any real value of having different commit ACLs per Fedora branch? I've seen some argument for EPEL vs Fedora, but is there real value in ACLs for f13, f14, devel, etc...? Somethng I jsut thought of is whether package maintainers can create new branches in git by themselves. If the answer is still no, then we'd probably want to keep that information in pkgdb. If the answer is yes, then there's already the chance htat the branches could get out of sync. Another couple of issues are: 1) Statistics. People like to get statistics relating to packages in a release from pkgdb. We'd need to switch these around to somehow extract the information from git. 2) Bodhi work on a per-branch level. Storing critpath information in pkgdb pretty much means that we have to keep separate records for separate releases. So although I'd like to simplify things, it seems like there's lots of work to implement this but not a whole lot of benefit (other than making things less complex). Well, I currently have an issue where unretiring a package lead to some weird problems for some branches, see: https://fedorahosted.org/rel-eng/ticket/4290#preview pkgdb would let me take over the f13 branch from orphan, but not f14 nor master (which ahd been created automatically, probably during dist-git conversion). Since they've been set up via SCM request, I am able to push to git but not fedpkg build on master. (I can push to all branches haven't tried fedpkg build on them since I'm supposed to build master first.) It seems to me that at least the fact I was able to take over f13 from orphan but not the others is related to per-branch ACLs. But what do I know ;) Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-Compile] - Add BR: perl(CGI) (Fix FTBFS: BZ 660891).
commit eddaacb9ad39b4e4606e7ac5dc1e1392ca7ba22f
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Wed Dec 8 09:35:19 2010 +0100
- Add BR: perl(CGI) (Fix FTBFS: BZ 660891).
perl-CGI-Compile.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Compile.spec b/perl-CGI-Compile.spec
index 5156504..dbbdf85 100644
--- a/perl-CGI-Compile.spec
+++ b/perl-CGI-Compile.spec
@@ -1,7 +1,7 @@
Name: perl-CGI-Compile
Summary:Compile .cgi scripts to a code reference like ModPerl::Registry
Version:0.11
-Release:2%{?dist}
+Release:3%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/CGI-Compile-%{version}.tar.gz
@@ -10,6 +10,7 @@ BuildRoot:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
+BuildRequires: perl(CGI)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(File::pushd)
BuildRequires: perl(Filter::Util::Call)
@@ -56,6 +57,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Wed Dec 08 2010 Ralf Corsépius corse...@fedoraproject.org - 0.11-3
+- Add BR: perl(CGI) (Fix FTBFS: BZ 660891).
+
* Tue Jun 22 2010 Petr Pisar ppi...@redhat.com - 0.11-2
- Rebuild against perl-5.12
--
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
[Bug 660891] FTBFS perl-CGI-Compile-0.11-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660891 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED CC||rc040...@freenet.de Resolution||RAWHIDE Last Closed||2010-12-08 03:35:53 --- Comment #7 from Ralf Corsepius rc040...@freenet.de 2010-12-08 03:35:53 EST --- Missing BR: perl(CGI) Fixed in perl-CGI-Compile-0.11-3. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed package blocking due to FTBFS
On Wed, 2010-12-08 at 01:05 +, Bastien Nocera wrote: And I'll go back to fixing actual bugs encountered by people instead of random bot-driven bugs. every abrt report, ever, is an actual bug encountered by an actual person. They have to be sufficiently narked about the app crashing (and it really must have crashed) to click through a rather convoluted process (the first time, anyway) to send in a report. so are all these bugs, for that matter: they're actual bugs encountered by Matt. The package failing to build is clearly a bug. Matt tried to build it and so encountered the bug. Where does it fail to meet your criteria? I agree it's a bit questionable whether we should block packages for FTBFS, but the argument can clearly be made; being self-hosting is obviously important for an F/OSS project. At some point it devolves into Stallmanite wankery about whether you can flash your mouse, but where exactly we should draw the line isn't a slam-dunk :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
On 12/08/2010 04:25 AM, Jeff Spaleta wrote: On Wed, Dec 8, 2010 at 2:39 AM, BJ Dierkes wdier...@5dollarwhitebox.org wrote: Hello all, Just to be clear... PyPI has an implied one source requirement embedded in its repository structure and you have optimized your upstream project release structure to meet PyPI's implied requirement. Question does PyPI handle dependency tracking? If I easy_install cement.devtools does cement get installed automagically? Yes, setup function from python setuptools has named argument 'install_requires' that causes dependencies to be pulled in during install time. Assuming cement.devtools has install_requires = ['cement'] this will work as you'd expect -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
Monday Miloslav Trma said: Just disable the firewall and you'll get pretty much equivalent functionality. How? Now that the filter table and stateful connection tracking, aren't modules anymore. They now appear to be built monolithic into the Fedora kernel. ../C -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Wed, Dec 08, 2010 at 03:53:34AM +0100, Matej Cepl wrote: Dne 7.12.2010 22:30, Richard W.M. Jones napsal(a): The issue we face with libvirt is it needs to be able to add extra rules to the existing firewall, and have those rules added in the right place, and preserved across firewall restarts, reboots and so on. There are other services which need to add rules too (see cups mentioned previously in this thread). a) libvirt somehow manages to work just fine on my computer even with my script, so why to change it? libvirtd (the daemon) does currently add firewall rules, and those rules are necessary. If you restart the iptables service, or otherwise drop those rules, all your guests will lose their network. Either you're not using libvirtd, not running guests, or not rerunning your firewall script. In any case, a fixed shell script is not flexible enough for libvirt and some other services. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 618349 : Can I get some input please?
On Tue, Dec 07, 2010 at 09:28:55PM -0500, Arthur Pemberton wrote: Bug: https://bugzilla.redhat.com/show_bug.cgi?id=618349 The bug is blocking my ability, or at least my willingness to upgrade to F14. I would appreciate some assistance so that I can finally do the upgrade. It would really help if you'd summarize the bug in the subject line, so that everyone reading this email doesn't have to click through to BZ. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 12 End of Life
On Thu, Dec 2, 2010 at 10:49 PM, Kevin Fenzi ke...@scrye.com wrote: This announcement is a reminder that as of 2010-12-02, Fedora 12 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 12. Fedora 13 will continue to receive updates until approximately one month after the release of Fedora 15. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki: https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule Please see http://fedoraproject.org/wiki/DistributionUpgrades for more information on upgrading to a supported release. kevin Hi there think the wiki as not been updated accordingly to this announce. Does anyone could update it[1]? (I don't know yet how to dynamically add the date) [1] https://fedoraproject.org/wiki/End_of_life Cheers, -- Kévin Raymond (shaiton) GPG-Key: A5BCB3A2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 12 End of Life
Kévin Raymond venit, vidit, dixit 08.12.2010 11:27: On Thu, Dec 2, 2010 at 10:49 PM, Kevin Fenzi ke...@scrye.com wrote: This announcement is a reminder that as of 2010-12-02, Fedora 12 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 12. Fedora 13 will continue to receive updates until approximately one month after the release of Fedora 15. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki: https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule Please see http://fedoraproject.org/wiki/DistributionUpgrades for more information on upgrading to a supported release. kevin Hi there think the wiki as not been updated accordingly to this announce. Does anyone could update it[1]? You're right, anyone could :) (With a wiki account, that is.) (I don't know yet how to dynamically add the date) ? I've updated it for F12. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On 12/08/2010 09:50 AM, Adam Williamson wrote: On Wed, 2010-12-08 at 01:05 +, Bastien Nocera wrote: I agree it's a bit questionable whether we should block packages for FTBFS, IMO, there can't be any doubt about FTBFS's to be must fixes and them to release blockers for packages being affected. Rationale: - It's important packages are buildable at any time, to be able to quickly react on bugs. - Packages, which are hit by FTBFS issues often suffer from other but mere technical issues, e.g. maintainers having gone AWOL, the package being of low quality, maintainers not being sufficiently skilled etc. - Packages, which are hit by FTBFS issue often reveil hidden packaging issues (e.g. broken deps having silently being introduced), which should be addressed as soon as possible to prevent other packages from being infected with work-arounds (e.g. redundant package deps or configuration hackery). - FTBFS issues occasionally reveil global issues, which so far have managed to get away unaddressed/unnoticed (e.g. compiler bugs, toolchain issues etc.) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 660827] FTBFS perl-POE-Component-DBIAgent-0.26-7.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660827 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED CC||rc040...@freenet.de Resolution||RAWHIDE Last Closed||2010-12-08 06:01:28 --- Comment #7 from Ralf Corsepius rc040...@freenet.de 2010-12-08 06:01:28 EST --- Missing BR: perl(ExtUtils::MakeMaker) Fixed in perl-POE-Component-DBIAgent-0.26-8.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Getopt-Euclid-v0.2.3.tar.gz uploaded to lookaside cache by ron
A file has been added to the lookaside cache for perl-Getopt-Euclid: 6055aab59fe5cd7b5e522d9829ba5882 Getopt-Euclid-v0.2.3.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed package blocking due to FTBFS
On Tue, 2010-12-07 at 18:12 -0700, Kevin Fenzi wrote: On Wed, 08 Dec 2010 01:05:06 + Bastien Nocera bnoc...@redhat.com wrote: ...snip... The lists may be broken down by when they last did build. With 3 exceptions, these 110 bugs are all still in NEW state as well, so they haven't had much maintainer love in quite some time (6-18 months). All the Fedora bugzilla bugs assigned to you, ever: http://bit.ly/dTndTs A whole 73. Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me: http://bit.ly/gBtVRP 810 bugs. When you deal with as many bugs as I (or some other people) do can you take executive decisions on blocking packages in newer revisions. How about asking for help? Co-maintainers on packages that get lots of bugs? Have you considered training up some bugzappers to help triage your components? They could at least work on de-duping abrt reports. Lets try and get you help... I bet most of those packages are still functional, and fail to build due to some minor changes in the build system, or breakage in dependency libraries. The ones he's refering to have not built since f12. It's a wonder if they work at all. ;) Well, they probably did, or at least I didn't get any reports saying they don't. snip ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make) dcbw NetworkManager-openvpn-0.8.1-1.fc14 [u'63 NEW'] (build/make) dcbw,choeger,huzaifas,steve NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw And I'm guessing this list didn't get read by humans either. You are refering to the wrong list. From Matt: I would like to propose blocking packages at the F15 alpha compose point if they have not resolved their FTBFS from F14 or earlier. So that means that those packages would have gotten blocked. That was a list of all things that don't currently build right now in rawhide. The proposed block list was much smaller and contained things that have not been built since f12. Again, that's not what's mentioned above. Feel free to insert here complaints about how the Red Hat bugzilla is slow, bad at reporting, and that abrt reports with missing attachments, poor backtraces and no support for tools like GNOME Bugzilla's simple-dup-finedr aren't helping us keep the bug count down. I'm intrigued. Can we modify 'simple-dup-finder' to work on our bugzilla? Any docs or pointers to what it does? GNOME's dup finder: http://git.gnome.org/browse/bugzilla-newer/tree/dupfinder The README is probably outdated, as per: http://live.gnome.org/BugzillaUpgrade/UpgradeStatus#Simple-dup-finder KDE and a number of other bugzillas seem to have similar infrastructure. I'm pretty sure it wouldn't work due to abrt's use of attachments instead of full backtraces. Also sorely missing from the RH bugzilla is an equivalent to the browse functionality in the GNOME BZ: https://bugzilla.gnome.org/browse.cgi And the fact that NEEDINFO is a real status, not a flag, which makes it easier to filter. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, Dec 8, 2010 at 1:12 AM, Kevin Fenzi ke...@scrye.com wrote: On Wed, 08 Dec 2010 01:05:06 + Bastien Nocera bnoc...@redhat.com wrote: ...snip... The lists may be broken down by when they last did build. With 3 exceptions, these 110 bugs are all still in NEW state as well, so they haven't had much maintainer love in quite some time (6-18 months). All the Fedora bugzilla bugs assigned to you, ever: http://bit.ly/dTndTs A whole 73. Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me: http://bit.ly/gBtVRP 810 bugs. When you deal with as many bugs as I (or some other people) do can you take executive decisions on blocking packages in newer revisions. How about asking for help? Co-maintainers on packages that get lots of bugs? Have you considered training up some bugzappers to help triage your components? They could at least work on de-duping abrt reports. I agree with Bastien on this one. Its very hard and if I spent all my time dealing with abrt bug reports I'd never do anything else. Besides I thought abrt was support to support de-dupe. I bet most of those packages are still functional, and fail to build due to some minor changes in the build system, or breakage in dependency libraries. The ones he's refering to have not built since f12. It's a wonder if they work at all. ;) For some reason I thought we'd had a mass rebuild since f-12 but maybe that was just python and other sub group stuff. That aside I know of a number of packages that haven't been rebuilt since F-12 and work just fine. snip ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make) dcbw NetworkManager-openvpn-0.8.1-1.fc14 [u'63 NEW'] (build/make) dcbw,choeger,huzaifas,steve NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw And I'm guessing this list didn't get read by humans either. You are refering to the wrong list. That was a list of all things that don't currently build right now in rawhide. The proposed block list was much smaller and contained things that have not been built since f12. I don't think blocking things that haven't been rebuilt is such a good criteria. I also happen to know of at least 1 library that fails to build on rawhide and F-14 and works perfectly well and if it was removed I think a large chunk of gnome 3 would fail based on the dependency tree. I bet that would put the cat amongst the pigeons! Feel free to insert here complaints about how the Red Hat bugzilla is slow, bad at reporting, and that abrt reports with missing attachments, poor backtraces and no support for tools like GNOME Bugzilla's simple-dup-finedr aren't helping us keep the bug count down. It was my understanding that abrt was suppose to block on backtraces without debuginfo but I still regularly get bugs with little or no decent info. What's worse is often they are the first report and abrt de-dupes against that report and still doesn't automatically either update the backtrace with a complete one from other reports or attach a new one. So you end up in a situation with a bug report with 30 dupes and have to ask the users to attach a manual complete one. Not ideal! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, Dec 8, 2010 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-12-08 at 01:05 +, Bastien Nocera wrote: And I'll go back to fixing actual bugs encountered by people instead of random bot-driven bugs. every abrt report, ever, is an actual bug encountered by an actual person. They have to be sufficiently narked about the app crashing (and it really must have crashed) to click through a rather convoluted process (the first time, anyway) to send in a report. Or 1 person submits a report 30 times each time with an incomplete backtrace and then asks why you haven't fixed their bug yet which you can't recreate or debug! so are all these bugs, for that matter: they're actual bugs encountered by Matt. The package failing to build is clearly a bug. Matt tried to build it and so encountered the bug. Where does it fail to meet your criteria? I agree it's a bit questionable whether we should block packages for FTBFS, but the argument can clearly be made; being self-hosting is obviously important for an F/OSS project. At some point it devolves into Stallmanite wankery about whether you can flash your mouse, but where exactly we should draw the line isn't a slam-dunk :) I'm sitting on the fence on this one. There are packages built on F-12 that work perfectly well on rawhide that don't build on rawhide. What about an instance where there's dependant packages. Do they automatically get blocked too or do we go through another route of FTBFS on those too? In the case of a leaf one it might be that by it not building currently doesn't affect anything and the maintainer is aware of the problem but needs the time to fix the issue properly when he gets time. In this case the maintainer then has to jump through the review process all over again to get it unblocked and then will likely just not be bothered. I have this case with moblin-panel-media. Its been dropped by upstream but people have shown interest in it remaining so they don't need to have mono. It needs patches to build but I've not had time to deal with it (see the issues with meego in general atm) but I'm aware of the problem and will get to it eventually. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
NM: could not get owner of name
Should I be concerned about these? Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.539204] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.577737] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.578084] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, 2010-12-08 at 11:37 +, Bastien Nocera wrote: snip GNOME's dup finder: http://git.gnome.org/browse/bugzilla-newer/tree/dupfinder The README is probably outdated, as per: http://live.gnome.org/BugzillaUpgrade/UpgradeStatus#Simple-dup-finder Filed as: https://bugzilla.redhat.com/show_bug.cgi?id=661270 Also sorely missing from the RH bugzilla is an equivalent to the browse functionality in the GNOME BZ: https://bugzilla.gnome.org/browse.cgi https://bugzilla.redhat.com/show_bug.cgi?id=661273 And the fact that NEEDINFO is a real status, not a flag, which makes it easier to filter. https://bugzilla.redhat.com/show_bug.cgi?id=661276 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, 2010-12-08 at 00:50 -0800, Adam Williamson wrote: On Wed, 2010-12-08 at 01:05 +, Bastien Nocera wrote: And I'll go back to fixing actual bugs encountered by people instead of random bot-driven bugs. every abrt report, ever, is an actual bug encountered by an actual person. They have to be sufficiently narked about the app crashing (and it really must have crashed) to click through a rather convoluted process (the first time, anyway) to send in a report. Given the time it takes triage them, compared to how long it takes to file them, I'm not sure it's a win for us. so are all these bugs, for that matter: they're actual bugs encountered by Matt. The package failing to build is clearly a bug. Matt tried to build it and so encountered the bug. Where does it fail to meet your criteria? It's a file'n'dump bug. There's no one that actually looked at the bugs to try and analyse them, nobody to offer a reminder in the bugs (they were filed and left untouched). I agree it's a bit questionable whether we should block packages for FTBFS, but the argument can clearly be made; being self-hosting is obviously important for an F/OSS project. At some point it devolves into Stallmanite wankery about whether you can flash your mouse, but where exactly we should draw the line isn't a slam-dunk :) I'm not sure what this has to do with anything. The signal to noise ratio in the RH bugzilla is far too low to be anything useful, and piling another bug on top of other bugs, with no reminder apart from this mail is rude. FWIW, the bug I found in gnokii was really a bug in pcsc which just removed a enum member without bumping soname, thus breaking API, and possibly ABI. I should have received an automated mail about broken dependencies, and not be having discussions about the quality of our bugzilla. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NM: could not get owner of name
on 12/08/2010 08:51 PM, Neal Becker wrote: Should I be concerned about these? Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.539204] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.577737] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.578084] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name It looks same as following reports. btw, according to #655322, it's been fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=652761 https://bugzilla.redhat.com/show_bug.cgi?id=655322 Cheers, -- Masami Ichikawa mail to: masami...@gmail.com mas...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101208 changes
Compose started at Wed Dec 8 08:15:06 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) esmtp-1.0-6.fc12.x86_64 requires libesmtp.so.5()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-bluetooth-moblin-2.91.2-1.fc15.x86_64 requires libmoblin-panel.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) inkscape-0.48.0-6.fc15.x86_64 requires libwpd-0.8.so.8()(64bit) inkscape-0.48.0-6.fc15.x86_64 requires libwpg-0.1.so.1()(64bit) inkscape-0.48.0-6.fc15.x86_64 requires libwpg-stream-0.1.so.1()(64bit) inkscape-view-0.48.0-6.fc15.x86_64 requires libwpd-0.8.so.8()(64bit) inkscape-view-0.48.0-6.fc15.x86_64 requires libwpg-0.1.so.1()(64bit) inkscape-view-0.48.0-6.fc15.x86_64 requires libwpg-stream-0.1.so.1()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) 3:koffice-filters-2.2.84-2.fc15.i686 requires libwpd-0.8.so.8 3:koffice-filters-2.2.84-2.fc15.i686 requires libwpg-0.1.so.1 3:koffice-filters-2.2.84-2.fc15.i686 requires libwpg-stream-0.1.so.1 3:koffice-filters-2.2.84-2.fc15.x86_64 requires libwpg-0.1.so.1()(64bit) 3:koffice-filters-2.2.84-2.fc15.x86_64 requires libwpd-0.8.so.8()(64bit) 3:koffice-filters-2.2.84-2.fc15.x86_64 requires libwpg-stream-0.1.so.1()(64bit) 1:libabiword-2.8.6-3.fc15.x86_64 requires libwpd-0.8.so.8()(64bit) 1:libabiword-2.8.6-3.fc15.x86_64 requires libwpg-0.1.so.1()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) 1:libtheora-devel-1.1.1-1.fc13.i686 requires libogg-devel = 2:1.1 1:libtheora-devel-1.1.1-1.fc13.x86_64 requires libogg-devel = 2:1.1 1:libvorbis-devel-1.3.1-2.fc14.i686 requires libogg-devel = 2:1.1 1:libvorbis-devel-1.3.1-2.fc14.x86_64 requires libogg-devel = 2:1.1 log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 mars-sim-2.84-6.fc14.noarch requires commons-collections moblin-panel-media-0.0.8-0.2.fc13.x86_64 requires libmoblin-panel.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libmoblin-panel.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit)
Mono.Cecil
Hi, Mono.Cecil has been a pain in the backside for many moons with the advice being to ditch the version which ships with package and try and use the version bundled with mono itself (which is version 0.6-ish). Unfortunately, this is leading to a number of problems (db4o 7.4 up won't work like this and many other packages are starting to creak) The lead developer for Mono.Cecil has released version 0.9.4 and it's rapidly approaching version 1.0 (not sure about the eta on it). I've packaged 0.9.4 up as a new package (mono-cecil) and will put it up for review shortly (got a few minor things to sort out first). This will break quite a few of the scripts currently being used (for example, monodevelop-2.4.1 won't build). However, there are advantages to using a new Mono.Cecil, especially as the old version really is old and broken in places. Does anyone have a problem with a new mono.cecil package being imported? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mono.Cecil
Hi, Mono.Cecil has been a pain in the backside for many moons with the advice being to ditch the version which ships with package and try and use the version bundled with mono itself (which is version 0.6-ish). Unfortunately, this is leading to a number of problems (db4o 7.4 up won't work like this and many other packages are starting to creak) The lead developer for Mono.Cecil has released version 0.9.4 and it's rapidly approaching version 1.0 (not sure about the eta on it). I've packaged 0.9.4 up as a new package (mono-cecil) and will put it up for review shortly (got a few minor things to sort out first). This will break quite a few of the scripts currently being used (for example, monodevelop-2.4.1 won't build). However, there are advantages to using a new Mono.Cecil, especially as the old version really is old and broken in places. Does anyone have a problem with a new mono.cecil package being imported? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, Dec 08, 2010 at 12:01:39PM +, Bastien Nocera wrote: On Wed, 2010-12-08 at 00:50 -0800, Adam Williamson wrote: On Wed, 2010-12-08 at 01:05 +, Bastien Nocera wrote: And I'll go back to fixing actual bugs encountered by people instead of random bot-driven bugs. every abrt report, ever, is an actual bug encountered by an actual person. They have to be sufficiently narked about the app crashing (and it really must have crashed) to click through a rather convoluted process (the first time, anyway) to send in a report. Given the time it takes triage them, compared to how long it takes to file them, I'm not sure it's a win for us. so are all these bugs, for that matter: they're actual bugs encountered by Matt. The package failing to build is clearly a bug. Matt tried to build it and so encountered the bug. Where does it fail to meet your criteria? It's a file'n'dump bug. There's no one that actually looked at the bugs to try and analyse them, nobody to offer a reminder in the bugs (they were filed and left untouched). I agree it's a bit questionable whether we should block packages for FTBFS, but the argument can clearly be made; being self-hosting is obviously important for an F/OSS project. At some point it devolves into Stallmanite wankery about whether you can flash your mouse, but where exactly we should draw the line isn't a slam-dunk :) I'm not sure what this has to do with anything. The signal to noise ratio in the RH bugzilla is far too low to be anything useful, and piling another bug on top of other bugs, with no reminder apart from this mail is rude. I'm confused. You want reminders filed in the bugs, but then you say the S-to-N ratio is to low to be useful. I could add automatic reminders in bugzilla, but I don't think that solves your key concern. The packages I posted last night were since F12 only. Personally, I'd like to see all FTBFS since even F14 fixed (they all have bugs filed). -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, Dec 08, 2010 at 12:01:39 +, Bastien Nocera bnoc...@redhat.com wrote: It's a file'n'dump bug. There's no one that actually looked at the bugs to try and analyse them, nobody to offer a reminder in the bugs (they were filed and left untouched). I went through a number of FTBFS bugs for other people's packages. A few other volunteers did as well. We didn't get full coverage, but we did help some of them get fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
g++ -shared -pthread doesn't link -lpthread ?
I'm trying to find the best solution to: https://bugzilla.redhat.com/show_bug.cgi?id=661115 Where a shlib is generated using g++ -shared -pthread ... but the result is a library with undefined symbols to pthread_create (and friends). Do I really need to explicity link -lpthread , or is there a better solution? -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: g++ -shared -pthread doesn't link -lpthread ?
Rex Dieter wrote, at 12/08/2010 11:50 PM +9:00: I'm trying to find the best solution to: https://bugzilla.redhat.com/show_bug.cgi?id=661115 Where a shlib is generated using g++ -shared -pthread ... but the result is a library with undefined symbols to pthread_create (and friends). Do I really need to explicity link -lpthread , or is there a better solution? -- Rex Maybe this? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 -pthread should have priority over -nostdlib - CLOSED INVALID Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Vacation/devaway system
Hi, there have been quite a few unresponsive maintainers processes in past few months + there are people that don't respond to emails in timely fashion. I'd like to have a system where anyone can see which maintainers are not available at the moment and approximate time of return to normal. It would serve several purposes: 1. co-maintainers won't wait for main maintainer to fix something 2. when high-priority problems arise provenpackages can act immediately instead of waiting for non-responsive maintainer to not respond 3. This could serve as a factor in speeding up non-responsive maintainer process. For example developer has no away status, but hasn't responded to emails in ~ 2 weeks = gone (numbers just an example) 4. Probably a few more... I know we have [1], but as you can see, there are 4 people listed on that page. That leads me to believe two things: 1. Most people don't know the page exists (I didn't until tibbs pointed it out to me) 2. It's cumbersome to edit wiki for things like this Obviously not every fedora maintainer has shell account so exact replica of [2] wouldn't work, but I was thinking some nicer interface could be provided. Maybe simple email with special subject line: FAS-name - $messsage And then FAS-name - RE to a special mailing list that would be processed by a bot? Or any other alternative, just something simple that (most) people would use. I'd even volunteer to create an app that would sit in the tray if it got people to actually announce when they go away for longer than a weekend... [1] http://fedoraproject.org/wiki/Vacation [2] http://dev.gentoo.org/devaway/ -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAML-Syck] Update to 1.17. Update Source0 URL. BR JSON (for tests).
commit 30612deec31dd0a16cc09f535839c82e7ad80dce
Author: Steven Pritchard steven.pritch...@gmail.com
Date: Wed Dec 8 09:09:43 2010 -0600
Update to 1.17.
Update Source0 URL.
BR JSON (for tests).
.gitignore |1 +
perl-YAML-Syck.spec | 14 ++
sources |2 +-
3 files changed, 12 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 26c8a26..ac17710 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
YAML-Syck-1.07.tar.gz
+/YAML-Syck-1.17.tar.gz
diff --git a/perl-YAML-Syck.spec b/perl-YAML-Syck.spec
index 2b23766..2e1a5d4 100644
--- a/perl-YAML-Syck.spec
+++ b/perl-YAML-Syck.spec
@@ -1,15 +1,16 @@
Name: perl-YAML-Syck
-Version:1.07
-Release:4%{?dist}
+Version:1.17
+Release:1%{?dist}
Summary:Fast, lightweight YAML loader and dumper
License:BSD and MIT
Group: Development/Libraries
URL:http://search.cpan.org/dist/YAML-Syck/
-Source0:
http://search.cpan.org/CPAN/authors/id/A/AU/AUDREYT/YAML-Syck-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/A/AV/AVAR/YAML-Syck-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRequires: perl(Devel::Leak)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(JSON)
BuildRequires: perl(Test::More)
-BuildRequires: perl(Devel::Leak)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -52,6 +53,11 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 07 2010 Steven Pritchard st...@kspei.com 1.17-1
+- Update to 1.17.
+- Update Source0 URL.
+- BR JSON (for tests).
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 1.07-4
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index c92767c..5d41c86 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-410ef7e24185de2a04390e0543876cad YAML-Syck-1.07.tar.gz
+f788529ad4b2c2fd037ccdfd5e7a88ab YAML-Syck-1.17.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: g++ -shared -pthread doesn't link -lpthread ?
Mamoru Tasaka wrote: Rex Dieter wrote, at 12/08/2010 11:50 PM +9:00: I'm trying to find the best solution to: https://bugzilla.redhat.com/show_bug.cgi?id=661115 Where a shlib is generated using g++ -shared -pthread ... but the result is a library with undefined symbols to pthread_create (and friends). Do I really need to explicity link -lpthread , or is there a better solution? Maybe this? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 -pthread should have priority over -nostdlib - CLOSED INVALID Ah, yes, -nostdlib is used in this context. fun. :( -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File YAML-0.72.tar.gz uploaded to lookaside cache by steve
A file has been added to the lookaside cache for perl-YAML: 35f8107367a5ba8c50965eca0ea7c370 YAML-0.72.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
[Bug 660952] FTBFS perl-VCS-LibCVS-1.0002-7.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660952 Thomas Moschny thomas.mosc...@gmx.de changed: What|Removed |Added Status|CLOSED |ASSIGNED CC||thomas.mosc...@gmx.de Resolution|NOTABUG | Keywords||Reopened --- Comment #5 from Thomas Moschny thomas.mosc...@gmx.de 2010-12-08 10:19:39 EST --- Reproducible on F14/x86_64: Creating test repository, please be patient:done # Test 23 got: UUB UMB (t/lcvs-st.t at line 69 fail #21) #Expected: UMB UMB # t/lcvs-st.t line 69 is: ok (shift (@result_lines), $file $file); # Test 25 got: UUM UMM (t/lcvs-st.t at line 69 fail #23) #Expected: UMM UMM # Test 26 got: UUU UMU (t/lcvs-st.t at line 69 fail #24) #Expected: UMU UMU # Test 50 got: UUB UMB\n (t/lcvs-st.t at line 76 fail #21) #Expected: UMB UMB\n # t/lcvs-st.t line 76 is: ok(`cd $base/sandbox1/dir1; $lcvs_st $file`, $file $file\n); # Test 52 got: UUM UMM\n (t/lcvs-st.t at line 76 fail #23) #Expected: UMM UMM\n # Test 53 got: UUU UMU\n (t/lcvs-st.t at line 76 fail #24) #Expected: UMU UMU\n # Test 78 got: UUB dir1/UMB (t/lcvs-st.t at line 87 fail #21) #Expected: UMB dir1/UMB # t/lcvs-st.t line 87 is: ok (shift (@result_lines), $file dir1/$file); # Test 80 got: UUM dir1/UMM (t/lcvs-st.t at line 87 fail #23) #Expected: UMM dir1/UMM # Test 81 got: UUU dir1/UMU (t/lcvs-st.t at line 87 fail #24) #Expected: UMU dir1/UMU # Test 105 got: UUB dir1/UMB\n (t/lcvs-st.t at line 94 fail #21) # Expected: UMB dir1/UMB\n # t/lcvs-st.t line 94 is: ok(`cd $base/sandbox1; $lcvs_st dir1/$file`, $file dir1/$file\n); # Test 107 got: UUM dir1/UMM\n (t/lcvs-st.t at line 94 fail #23) # Expected: UMM dir1/UMM\n # Test 108 got: UUU dir1/UMU\n (t/lcvs-st.t at line 94 fail #24) # Expected: UMU dir1/UMU\n t/lcvs-st.t .. Failed 12/111 subtests Test Summary Report --- t/lcvs-st.t (Wstat: 0 Tests: 111 Failed: 12) Failed tests: 23, 25-26, 50, 52-53, 78, 80-81, 105, 107-108 Files=1, Tests=111, 57 wallclock secs ( 0.03 usr 0.01 sys + 4.87 cusr 1.28 csys = 6.19 CPU) Result: FAIL Failed 1/1 test programs. 12/111 subtests failed. make[1]: *** [test_dynamic] Error 255 make[1]: Leaving directory `.../rpmbuild/perl-VCS-LibCVS/VCS-LibCVS-1.0002/examples' make: *** [subdirs-test] Error 2 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-YAML] Update to 0.72.
commit 2e0508e99bfaf9c8624e80d0edd67c7c462c65d7
Author: Steven Pritchard steven.pritch...@gmail.com
Date: Wed Dec 8 09:26:35 2010 -0600
Update to 0.72.
.gitignore |1 +
perl-YAML.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a14ebdd..e754a87 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
YAML-0.71.tar.gz
+/YAML-0.72.tar.gz
diff --git a/perl-YAML.spec b/perl-YAML.spec
index cfd841f..33d3c86 100644
--- a/perl-YAML.spec
+++ b/perl-YAML.spec
@@ -1,5 +1,5 @@
Name: perl-YAML
-Version:0.71
+Version:0.72
Release:1%{?dist}
Summary:YAML Ain't Markup Language (tm)
License:GPL+ or Artistic
@@ -61,6 +61,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/YAML*.3*
%changelog
+* Wed Dec 08 2010 Steven Pritchard st...@kspei.com 0.72-1
+- Update to 0.72.
+
* Wed Aug 18 2010 Paul Howarth p...@city-fan.org - 0.71-1
- Update to 0.71 (use UTF-8 encoding in LoadFile/DumpFile: CPAN RT#25434)
- Enable AUTOMATED_TESTING
diff --git a/sources b/sources
index 4fe9055..ec13446 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d0f7cf232dd43c28c0e3767d672d6887 YAML-0.71.tar.gz
+35f8107367a5ba8c50965eca0ea7c370 YAML-0.72.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: Vacation/devaway system
On Wed, 2010-12-08 at 16:07 +0100, Stanislav Ochotnicky wrote: Obviously not every fedora maintainer has shell account so exact replica of [2] wouldn't work, but I was thinking some nicer interface could be provided. Maybe simple email with special subject line: FAS-name - $messsage And then FAS-name - RE to a special mailing list that would be processed by a bot? Or any other alternative, just something simple that (most) people would use. I like the mail idea, it is probably the most flexible. We could also use/combine it with fedorapeople since to have one you need every fedora packager fills the condition to have one: You need an active Fedora account You must be sponsored in a group (other than the CLA groups) source: http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org The only thing I would ask is to keep the page for people with a FAS account. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libtool c++ shlib target + -pthread doesn't link -lpthread
Mamoru Tasaka wrote: Rex Dieter wrote, at 12/08/2010 11:50 PM +9:00: I'm trying to find the best solution to: https://bugzilla.redhat.com/show_bug.cgi?id=661115 Where a shlib is generated using g++ -shared -pthread ... but the result is a library with undefined symbols to pthread_create (and friends). Do I really need to explicity link -lpthread , or is there a better solution? Maybe this? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 -pthread should have priority over -nostdlib - CLOSED INVALID Confirmed, libtool c++ shlib target + -pthread doesn't link -lpthread , filed bug to track, https://bugzilla.redhat.com/show_bug.cgi?id=661333 -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Tue, 2010-12-07 at 20:29 -0600, Matt Domsch wrote: My goal isn't to make life difficult for everyone. My goal is to keep the distribution in a form where it can actually build from the open source we provide. Thanks Matt. What you're doing is vitally important for the distribution, since it should build from source always. You do a lot of great work in this area and I hope you continue for a long time! :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Vacation/devaway system
Am Mittwoch, den 08.12.2010, 16:07 +0100 schrieb Stanislav Ochotnicky: Hi, there have been quite a few unresponsive maintainers processes in past few months + there are people that don't respond to emails in timely fashion. I'd like to have a system where anyone can see which maintainers are not available at the moment and approximate time of return to normal. The point is not the system I think. A wiki page might not be the optimal solution, but it defintely works. There also is a way to set your FAS account to vacation. Maybe the fact that it'd be a good idea to write down somewhere that you're going to be unresponsive for some weeks just needs more promotion? The new maintainer guide might be a good place to hint at it. Regards, Julian signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 618349 : Can I get some input please?
On Wed, Dec 8, 2010 at 4:41 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Dec 07, 2010 at 09:28:55PM -0500, Arthur Pemberton wrote: Bug: https://bugzilla.redhat.com/show_bug.cgi?id=618349 The bug is blocking my ability, or at least my willingness to upgrade to F14. I would appreciate some assistance so that I can finally do the upgrade. It would really help if you'd summarize the bug in the subject line, so that everyone reading this email doesn't have to click through to BZ. The problem was that my Windows guest was blue-screening with the then latest 'seabion-bin' package bin in fedora-updates I have since posting this message here found out that there is a new update to the package that isn't bad. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
insane -19 nice level for system service (mailgraph) - is it acceptable?
Hi, I noticed that this service uses insane nice level -19 http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/mailgraph 8-| PRIORITY=-19 [..] daemon nice $PRIORITY $exe -l $MAILLOG -d \ --daemon-pid=/var/run/mailgraph.pid \ --daemon-rrd=/var/lib/mailgraph $OPTIONS The same priority is used in the sample script. Does this service _really_ needs such insane nice level? -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I noticed that this service uses insane nice level -19 http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/mailgraph 8-| PRIORITY=-19 [..] daemon nice $PRIORITY $exe -l $MAILLOG -d \ --daemon-pid=/var/run/mailgraph.pid \ --daemon-rrd=/var/lib/mailgraph $OPTIONS The same priority is used in the sample script. Does this service _really_ needs such insane nice level? Why do you (repeatedly) call it insane? That's kind of rude. The process is running at a low priority level; do you have a problem with that? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
2010/12/8 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I noticed that this service uses insane nice level -19 http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/mailgraph 8-| PRIORITY=-19 [..] daemon nice $PRIORITY $exe -l $MAILLOG -d \ --daemon-pid=/var/run/mailgraph.pid \ --daemon-rrd=/var/lib/mailgraph $OPTIONS The same priority is used in the sample script. Does this service _really_ needs such insane nice level? Why do you (repeatedly) call it insane? That's kind of rude. Sorry :) The process is running at a low priority level; Nice -19 is the _higest_ priority - not low. do you have a problem with that? Yes, I think that it's wrong. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
On Wed, Dec 08, 2010 at 10:57:21 -0600, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: PRIORITY=-19 Why do you (repeatedly) call it insane? That's kind of rude. The process is running at a low priority level; do you have a problem with that? Aren't negative priorities higher? I think this is running at the max priority, not the min one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
Perhaps the issue is that the coding of the priority isn't intuitive. I thought -20 was 'highest priority' and high numbers were 'lower priority' Would something more meaningful and unambiguous be better? -Cam On Wed, Dec 8, 2010 at 4:57 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I noticed that this service uses insane nice level -19 http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/mailgraph 8-| PRIORITY=-19 [..] daemon nice $PRIORITY $exe -l $MAILLOG -d \ --daemon-pid=/var/run/mailgraph.pid \ --daemon-rrd=/var/lib/mailgraph $OPTIONS The same priority is used in the sample script. Does this service _really_ needs such insane nice level? Why do you (repeatedly) call it insane? That's kind of rude. The process is running at a low priority level; do you have a problem with that? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
On Wed, 8 Dec 2010 18:01:02 +0100 Michał Piotrowski mkkp...@gmail.com wrote: ...snip... do you have a problem with that? Yes, I think that it's wrong. File a bug on it? Is there any reason this needs to be discussed on the devel list? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
Once upon a time, Michał Piotrowski mkkp...@gmail.com said: 2010/12/8 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I noticed that this service uses insane nice level -19 http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/mailgraph 8-| PRIORITY=-19 [..] daemon nice $PRIORITY $exe -l $MAILLOG -d \ --daemon-pid=/var/run/mailgraph.pid \ --daemon-rrd=/var/lib/mailgraph $OPTIONS The same priority is used in the sample script. Does this service _really_ needs such insane nice level? Why do you (repeatedly) call it insane? That's kind of rude. Sorry :) The process is running at a low priority level; Nice -19 is the _higest_ priority - not low. I suggest you try the exact command given (and yes, the nice command is confusing). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
2010/12/8 Bruno Wolff III br...@wolff.to: On Wed, Dec 08, 2010 at 10:57:21 -0600, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: PRIORITY=-19 Why do you (repeatedly) call it insane? That's kind of rude. The process is running at a low priority level; do you have a problem with that? Aren't negative priorities higher? I think this is running at the max priority, not the min one. Exactly -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
W dniu 8 grudnia 2010 18:02 użytkownik Kevin Fenzi ke...@scrye.com napisał: On Wed, 8 Dec 2010 18:01:02 +0100 Michał Piotrowski mkkp...@gmail.com wrote: ...snip... do you have a problem with that? Yes, I think that it's wrong. File a bug on it? I'll just post systemd service without this sh... Is there any reason this needs to be discussed on the devel list? I wanted to know if it's a bug or feature. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
Once upon a time, Bruno Wolff III br...@wolff.to said: On Wed, Dec 08, 2010 at 10:57:21 -0600, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: PRIORITY=-19 Why do you (repeatedly) call it insane? That's kind of rude. The process is running at a low priority level; do you have a problem with that? Aren't negative priorities higher? I think this is running at the max priority, not the min one. Negative priorities are higher, but that's not what is being set. For historical compatibilty, nice takes a numeric option as a nice value, so nice -n X is the same as nice -X (it appears this behavior is not documented). You can verify this: $ nice -n 19 ps -o nice,cmd NI CMD 19 ps -o nice,cmd $ nice -19 ps -o nice,cmd NI CMD 19 ps -o nice,cmd -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
Michał Piotrowski mkkp...@gmail.com writes: 2010/12/8 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I noticed that this service uses insane nice level -19 http://notendur.hi.is/~johannbg/systemd/etc/rc.d/init.d/mailgraph 8-| PRIORITY=-19 [..] daemon nice $PRIORITY $exe -l $MAILLOG -d \ --daemon-pid=/var/run/mailgraph.pid \ --daemon-rrd=/var/lib/mailgraph $OPTIONS The same priority is used in the sample script. Does this service _really_ needs such insane nice level? Why do you (repeatedly) call it insane? That's kind of rude. Sorry :) The process is running at a low priority level; Nice -19 is the _higest_ priority - not low. No, it isn't. This is nice -19 == nice -n 19. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: insane -19 nice level for system service (mailgraph) - is it acceptable?
2010/12/8 Chris Adams cmad...@hiwaay.net: Once upon a time, Bruno Wolff III br...@wolff.to said: On Wed, Dec 08, 2010 at 10:57:21 -0600, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: PRIORITY=-19 Why do you (repeatedly) call it insane? That's kind of rude. The process is running at a low priority level; do you have a problem with that? Aren't negative priorities higher? I think this is running at the max priority, not the min one. Negative priorities are higher, but that's not what is being set. For historical compatibilty, nice takes a numeric option as a nice value, so nice -n X is the same as nice -X (it appears this behavior is not documented). You can verify this: $ nice -n 19 ps -o nice,cmd NI CMD 19 ps -o nice,cmd $ nice -19 ps -o nice,cmd NI CMD 19 ps -o nice,cmd Indeed, sorry for noice. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
Curtis Doty píše v St 08. 12. 2010 v 01:02 -0800: Monday Miloslav Trma said: Just disable the firewall and you'll get pretty much equivalent functionality. How? Now that the filter table and stateful connection tracking, aren't modules anymore. They now appear to be built monolithic into the Fedora kernel. a) you trust the in-kernel firewall state connection tracking to track connection state and handle unexpected packets according to the firewall configuration. b) you trust the in-kernel protocol stack (TCP/UDP) to track connection state and handle unexpected packets according to ordinary rules of the protocol. Is there a significant difference? I don't know. The protocol stack code might be more complex and thus more risky, on the other hand the firewall state tracking is an additional code that is activated only for the firewall and can also contain bugs. Yes, there is a difference in code, but the resulting difference in security seems quite small to me. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perlbrew/el5/master] update to 0.14
Summary of changes: a4d167b... update to 0.14 (*) (*) 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
hosted reproducible package building with multiple developers?
Riddle me this. We want to provide a server for developers within our organization to build RPM packages for use within our organization. These are our requirements: 1. The developers must not be able to leverage the package build process to obtain root access on the server. 2. If a package has a build dependency that is not explicitly specified, the build must fail. 3. If two developers are building packages simultaneously, their builds must not conflict. The only way satisfy requirements #2 and #3 is to use a chroot'ed build environment. mock(1) uses a chroot'ed build environment, but mock fails requirement #1, as anyone in the mock group can trivially root the box. I think that koji would satisfy all three requirements, because koji uses mock to build, but doesn't allow developers to interface with mock directly. But setting up a koji infrastructure seems like a highly non-trivial task. Is there really no way to meet all three of these requirements without going the full-blown koji route? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
On Dec 8, 2010, at 2:55 AM, Stanislav Ochotnicky wrote: On 12/08/2010 04:25 AM, Jeff Spaleta wrote: On Wed, Dec 8, 2010 at 2:39 AM, BJ Dierkes wdier...@5dollarwhitebox.org wrote: Hello all, Just to be clear... PyPI has an implied one source requirement embedded in its repository structure and you have optimized your upstream project release structure to meet PyPI's implied requirement. Question does PyPI handle dependency tracking? If I easy_install cement.devtools does cement get installed automagically? Yes, setup function from python setuptools has named argument 'install_requires' that causes dependencies to be pulled in during install time. Assuming cement.devtools has install_requires = ['cement'] this will work as you'd expect That is exactly right. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, 2010-12-08 at 13:03 -0500, James Ralston wrote: Riddle me this. We want to provide a server for developers within our organization to build RPM packages for use within our organization. These are our requirements: 1. The developers must not be able to leverage the package build process to obtain root access on the server. 2. If a package has a build dependency that is not explicitly specified, the build must fail. 3. If two developers are building packages simultaneously, their builds must not conflict. The only way satisfy requirements #2 and #3 is to use a chroot'ed build environment. mock(1) uses a chroot'ed build environment, but mock fails requirement #1, as anyone in the mock group can trivially root the box. I think that koji would satisfy all three requirements, because koji uses mock to build, but doesn't allow developers to interface with mock directly. But setting up a koji infrastructure seems like a highly non-trivial task. Is there really no way to meet all three of these requirements without going the full-blown koji route? the mock chroots that koji uses could still be rooted by someone who can submit their own build-requirement-providing packages. in order to protect the builders they must be: 1. disposable 2. in a vm or possibly both. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 2010-12-08 at 13:07-05 seth vidal skvi...@fedoraproject.org wrote: the mock chroots that koji uses could still be rooted by someone who can submit their own build-requirement-providing packages. Well, we vet all packages our developers submit before releasing them to our repositories, so we would catch a developer submitting (e.g.) a suid-bash-shell-1.0.0-1.el5.x86_64.rpm package. Does koji provide a mechanism for the submitter to specify his own yum repositories for mock to use? in order to protect the builders they must be: 1. disposable 2. in a vm or possibly both. Well, the ultimate protection would be to use this procedure for each build: 1. Instantiate VMs for all architectures specified by the build, via cloning known good build VMs. 2. Use koji to build on each VM. 3. Destroy each VM that was instantiated. But that's some *serious* overhead. Plus, I'm not sure that we could automate steps #1 and #3, which would be a dealbreaker. Honestly, given current trends, it might be that before too much longer, the best solution might be to simply give each developer his own VM for each OS/architecture he wants to build for, and tell him to use mock directly. Before each build, he snapshots the VM, and after each build, he reverts to the snapshot (discarding whatever changes the build process made to the system)... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, 2010-12-08 at 13:50 -0500, James Ralston wrote: On 2010-12-08 at 13:07-05 seth vidal skvi...@fedoraproject.org wrote: the mock chroots that koji uses could still be rooted by someone who can submit their own build-requirement-providing packages. Well, we vet all packages our developers submit before releasing them to our repositories, so we would catch a developer submitting (e.g.) a suid-bash-shell-1.0.0-1.el5.x86_64.rpm package. Does koji provide a mechanism for the submitter to specify his own yum repositories for mock to use? not that I'm aware of - the folks on the buildsys list who maintain koji may be able to help you more https://lists.fedoraproject.org/mailman/listinfo/buildsys Well, the ultimate protection would be to use this procedure for each build: 1. Instantiate VMs for all architectures specified by the build, via cloning known good build VMs. 2. Use koji to build on each VM. 3. Destroy each VM that was instantiated. But that's some *serious* overhead. Plus, I'm not sure that we could automate steps #1 and #3, which would be a dealbreaker. sure you can. :) I'm dabbling in that right at this moment :) Honestly, given current trends, it might be that before too much longer, the best solution might be to simply give each developer his own VM for each OS/architecture he wants to build for, and tell him to use mock directly. Before each build, he snapshots the VM, and after each build, he reverts to the snapshot (discarding whatever changes the build process made to the system)... perhaps. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo meeting (2010-12-08) NEW TIME
=== #fedora-meeting: FESCO (2010-12-08) === Meeting started by nirik at 17:30:03 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-12-08/fesco.2010-12-08-17.30.log.html Meeting summary --- * init process (nirik, 17:30:03) * kylem unable to attend. (nirik, 17:30:34) * Updates policy / Vision implementation status (nirik, 17:33:14) * LINK: https://fedoraproject.org/wiki/Updates_Policy (nirik, 17:35:33) * LINK: http://www.mail-archive.com/epel-devel-l...@redhat.com/msg03432.html (nirik, 17:42:42) * Meeting time (nirik, 17:54:28) * LINK: http://whenisgood.net/99a9zq/results/p585aa (mjg59, 17:55:16) * AGREED: will stick with this time at least for now. (nirik, 18:00:21) * #505 FPC guidelines for review (nirik, 18:00:33) * LINK: https://fedorahosted.org/fesco/ticket/505 (nirik, 18:00:34) * AGREED: FESCo has no problem with these two FPC guidelines. (nirik, 18:08:56) * #508 improve the general standard of packagers/maintainers in the distribution. (nirik, 18:09:13) * LINK: https://fedorahosted.org/fesco/ticket/508 (nirik, 18:09:13) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=450013 (nirik, 18:18:22) * LINK: https://fedoraproject.org/wiki/How_to_debug_Dracut_problems (Viking-Ice, 18:29:25) * ACTION: notting will look at folding these into the maintainers best practices. (nirik, 18:39:51) * AGREED: nirik will ping FPC about a) a review template and b) adding SHOULD/best practices to guidelines? (nirik, 18:42:11) * #509 F15Feature: F15Boost146 - http://fedoraproject.org/wiki/Features/F15Boost146 (nirik, 18:42:48) * LINK: https://fedorahosted.org/fesco/ticket/509 (nirik, 18:42:48) * AGREED: Feature is approved. (nirik, 18:44:38) * #510 F15Feature: FourkBSectorBooting - http://fedoraproject.org/wiki/Features/FourkBSectorBooting (nirik, 18:44:44) * LINK: https://fedorahosted.org/fesco/ticket/510 (nirik, 18:44:44) * AGREED: Feature is approved. (nirik, 18:45:50) * #511 F15Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3 (nirik, 18:45:55) * LINK: https://fedorahosted.org/fesco/ticket/511 (nirik, 18:45:55) * AGREED: feature was already approved. ;) (nirik, 18:47:21) * #512 F15Feature: LibreOffice - http://fedoraproject.org/wiki/Features/LibreOffice (nirik, 18:47:27) * LINK: https://fedorahosted.org/fesco/ticket/512 (nirik, 18:47:27) * AGREED: Feature is approved. (nirik, 18:49:05) * #513 F15Feature: Maven3 - http://fedoraproject.org/wiki/Features/Maven3 (nirik, 18:49:11) * LINK: https://fedorahosted.org/fesco/ticket/513 (nirik, 18:49:12) * AGREED: Feature is approved. (nirik, 18:50:12) * #514 F15Feature: Sugar 0.92 - http://fedoraproject.org/wiki/Features/Sugar_0.92 (nirik, 18:50:18) * LINK: https://fedorahosted.org/fesco/ticket/514 (nirik, 18:50:18) * AGREED: Feature is approved. (nirik, 18:51:20) * Open Floor (nirik, 18:51:25) Meeting ended at 19:01:40 UTC. Action Items * notting will look at folding these into the maintainers best practices. Action Items, by person --- * notting * notting will look at folding these into the maintainers best practices. * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (159) * cwickert (66) * mjg59 (36) * notting (31) * mmaslano (19) * ajax (17) * Viking-Ice (16) * SMParrish (12) * mclasen (12) * zodbot (7) * mclasen_ (1) * fenrus02 (1) * rbergeron (1) * vinzv (1) * Southern_Gentlem (1) * dtardon (1) * kylem (0) -- 17:30:03 nirik #startmeeting FESCO (2010-12-08) 17:30:03 zodbot Meeting started Wed Dec 8 17:30:03 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:03 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:03 nirik #meetingname fesco 17:30:03 nirik #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:03 nirik #topic init process 17:30:03 zodbot The meeting name has been set to 'fesco' 17:30:03 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:28 nirik who all is here for fesco meeting? 17:30:32 * cwickert is here 17:30:33 mjg59 ! 17:30:34 nirik #info kylem unable to attend. 17:30:41 * mmaslano here 17:30:41 * SMParrish here 17:30:56 * notting is here 17:33:00 nirik ok, lets go ahead and dive in. 17:33:14 nirik #topic Updates policy / Vision implementation status 17:33:14 nirik .fesco 351 17:33:14 nirik .fesco 382 17:33:15 zodbot nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 17:33:18 nirik * Adjustments to updates policy: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container 17:33:19 zodbot nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac -
Re: Proposed package blocking due to FTBFS
Matt Domsch wrote: I would like to propose blocking packages at the F15 alpha compose point if they have not resolved their FTBFS from F14 or earlier. The lists may be broken down by when they last did build. With 3 exceptions, these 110 bugs are all still in NEW state as well, so they haven't had much maintainer love in quite some time (6-18 months). I trust module-init-tools will get resolved with an impending upstream release. Not like that can go unfixed forever. :-) Last built on Fedora 12 (52): celestia-1.5.1-2.fc12 [u'631077 NEW'] (build/make) steve,mmahut classpathx-jaf-1.0-15.1.fc12 [u'600031 NEW'] (build/make) devrim,akurtakov,dwalluck cone-0.78-3.fc12 [u'631345 NEW'] (build/make) steve coq-8.2pl1-1.fc12 [u'631302 NEW'] (build/make) amdunn,ocamlmaint cpm-0.23-0.3.beta.fc12 [u'631463 NEW'] (build/make) mmahut drgeo-1.1.0-16.fc12 [u'631320 NEW'] (build/make) jdieter gdmap-0.8.1-6.fc12 [u'599984 NEW'] (build/make) mebourne genius-1.0.7-1.fc12 [u'631241 NEW'] (build/make) orphan gnokii-0.6.28-1.fc12 [u'631240 NEW'] (build/make) snirkel,hadess,snirkel gnome-do-plugins-0.8.2-1.fc12 [u'599889 NEW'] (build/make) nushio gpsk31-0.5-4.fc12 [u'599920 NEW'] (build/make) bjensen,dp67,sindrepb gshutdown-0.2-6.fc12 [u'599784 NEW'] (build/make) laxathom gsql-0.2.1-4.fc12 [u'631022 NEW'] (build/make) orphan gtkglextmm-1.2.0-10.fc12 [u'631285 NEW'] (build/make) cwickert guile-gnome-platform-2.16.1-4.fc12 [u'599864 NEW'] (build/make) laxathom htmldoc-1.8.27-13.fc12 [u'631135 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) agoode,pertusus imgtarget-0.1.4-4.fc12 [u'599895 NEW'] (build/make) grof kanatest-0.4.8-3.fc12 [u'631023 NEW'] (build/make) robmv kdetv-0.8.9-13.fc12 [u'631359 NEW'] (build/make) subhodip kpolynome-0.1.2-15.fc12 [u'599875 NEW'] (build/make) chitlesh ktechlab-0.3.70-3.20090304svn.fc12 [u'631203 NEW'] (build/make) chitlesh libctl-3.0.2-10.fc12 [u'599894 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) edhill,deji libfreebob-1.0.11-6.fc12 [u'631129 NEW'] (build/make) green libopensync-plugin-kdepim-0.22-6.fc12 [u'599881 NEW'] (build/make) awjb manaworld-0.0.29.1-2.fc12 [u'631455 NEW'] (build/make) wart maven-embedder-2.0.4-6.fc12 [u'631430 NEW'] (build/make) akurtakov,akurtakov,java-sig maven-plugin-cobertura-2.3-3.fc12 [u'631461 NEW'] (build/make) akurtakov,java-sig mingw32-libglademm24-2.6.7-8.fc12 [u'631374 NEW'] (build/make) sailer,rjones mingw32-pangomm-2.26.0-1.fc12 [u'631208 NEW'] (build/make) sailer,rjones mingw32-plotmm-0.1.2-4.fc12 [u'631082 NEW'] (build/make) sailer,rjones mod_auth_kerb-5.4-5.fc12 [u'599754 NEW'] (build/make) jorton multiget-1.2.0-7.fc12 [u'631052 NEW'] (build/make) guidoledermann,mtasaka netgo-0.5-12.fc12 [u'631087 NEW'] (build/make) spot notecase-1.6.1-6.fc12 [u'631448 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) bouska oorexx-4.0.0-2.4801.fc12 [u'631137 NEW'] (build/make) orphan petitboot-0.2-4.fc12 [u'599949 NEW'] (build/make) dwmw2,jwboyer,tbreeds pigment-0.3.17-3.fc12 [u'599828 NEW'] (build/make) thias postgresql-pgpool-ha-1.1.0-8.fc12 [u'599834 NEW'] (build/make) devrim qgo-1.5.4r2-3.fc12 [u'631091 NEW'] (build/make) kaboom qtgpsc-0.2.3-6.fc12 [u'599878 ASSIGNED'] (build/make) fab quarry-0.2.0-5.fc12 [u'631185 NEW'] (build/make) salimma qucs-0.0.15-4.fc12 [u'631404 NEW'] (build/make) tanguy raidem-0.3.1-11.fc12 [u'599876 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) laxathom rubygem-attributes-5.0.1-5.fc12 [u'599891 NEW'] (unpackaged_files/python-egg-info?) kanarip,stahnma rubygem-cobbler-1.6.1-1.fc12 [u'599799 NEW'] (unpackaged_files/python-egg-info?) jeckersb sear-0.6.3-14.fc12 [u'599825 NEW'] (build/make) wart,atorkhov starlab-4.4.3-7.fc12 [u'599988 NEW'] (build/make) lkundrak,mmahut subtitlecomposer-0.5.3-3.fc12 [u'599833 NEW'] (build/make) tuxbrewr tuxpaint-stamps-2008.06.30-3.fc12 [u'631086 NEW'] (build/make) steve valknut-0.4.9-3.fc12 [u'631171 NEW'] (build/make) mjakubicek,mjakubicek xscorch-0.2.1-0.4.pre2.fc12 [u'599848 NEW'] (build/make) mgarski xsri-2.1.0-17.fc12 [u'599802 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) ssp Last built on Fedora 13 (26): alsa-plugins-1.0.22-1.fc13 [u'631366 NEW'] (build/make) perex,npajkovs automake15-1.5-29.fc13.1 [u'631216 NEW'] (build/make) karsten automake16-1.6.3-18.fc13.1 [u'631215 NEW'] (build/make) karsten db4o-7.4-2.fc13 [u'631066 NEW'] (build/make) pfj eina-0.9.1-1.fc13 [u'599929 NEW'] (build/make) sundaram ember-0.5.6-5.fc13 [u'631439 NEW'] (build/make) atorkhov,wart etherboot-5.4.4-18.fc13 [u'631148 NEW'] (build/make) ehabkost,glommer,virtmaint flexdock-0.5.1-17.fc13 [u'599813 NEW'] (build/make) mycae fsvs-1.2.1-1.fc13 [u'631437 NEW'] (build/make)
Re: Python Packages + Multiple Sources
On Wed, Dec 8, 2010 at 6:06 PM, BJ Dierkes wdier...@5dollarwhitebox.org wrote: That is exactly right. reading over the instructions on the pypi page for cement.devtools explicitly tells people to easy_install cement prior to easy_install'ing cement.devtools, so I wanted clarification as to whether that was necessasry. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing Xfce 4.8 pre 2 packages available
Am Montag, den 06.12.2010, 14:42 +0200 schrieb Gilboa Davara: On Mon, 2010-12-06 at 00:01 +0100, Christoph Wickert wrote: Hi there, I have packaged Xfce 4-8 pre 2 for Fedora 14 and Rawhide. You can find the packages at http://repos.fedorapeople.org/repos/cwickert/xfce-4.8/ The repo is far from complete. ATM it is still rsyncing and Fedora 13 is still building. Also a couple of applications that need a rebuild (e.g. xfce4-mixer) are missing and so are most of the goodies. I will continue to work on this. Thanks! Should I report missing deps? Not necessary, I am aware of it, that's why it is not in rawhide yet. If somebody has the time to go through all the panel plugins and see if they still build, a list of the failed ones is appreciated. Thanks, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
On Tue, Dec 07, 2010 at 08:39:50PM -0600, BJ Dierkes wrote: All three pieces follow each release meaning, when 0.8.12 (current stable) was released... new tarbals were released for all three. The reason for separate tarbals is primarily for maintaining releases via PyPi [2]. I need all three pieces to be separate so that users can 'easy_install cement', without pulling in a dozen dependencies for cement.devtools or cement.test. I don't have the luxury of creating 'subpackages' in PyPi, so I have to break up the sources. What I would like to see is if this type of situation would lend itself to making an exception to the FPG regarding 'one source per package'. I assume the section 'Bundling of multiple projects' [4] is relevant, though it is pretty vague. I guess what I'm looking for is for someone with more time in the community to give some advice on this situation. Ideally, I would like to be able to maintain a single package set for say 'cement', but with Source0 (cement), Source1 (cement.devtools), Source2 (cement.test). To quote the guidelines: | Fedora packages should make every effort to avoid having multiple, | separate, upstream projects bundled together in a single package. Since all tarballs belong to the same upstream project, there is nothing wrong with using all three in one SPEC. Or would it be recommended to have a separate tarbal like 'cement-all-0.8.12.tar.gz' which would include all parts of the project, and use that as Source0? I do not see any additional value for Fedora when doing this. Regards Till [4] http://fedoraproject.org/wiki/PackagingGuidelines#Bundling_of_multiple_projects pgpyLc8OX2WAM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, Dec 08, 2010 at 01:50:22PM -0500, James Ralston wrote: Well, the ultimate protection would be to use this procedure for each build: 1. Instantiate VMs for all architectures specified by the build, via cloning known good build VMs. 2. Use koji to build on each VM. 3. Destroy each VM that was instantiated. IIRC Seth is working on this. To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. Regards Till pgp8FYyQg4Y6e.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, Dec 08, 2010 at 04:50:11PM -0500, seth vidal wrote: On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. If we're being picky then the hypervisor might be exploited during the package build, with the exploit escalating to root on the host. It's very hard to pull this off, but with security never say 'never'. In any case, using sVirt (libvirt + SELinux) should help. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 12/08/2010 02:02 PM, Richard W.M. Jones wrote: On Wed, Dec 08, 2010 at 04:50:11PM -0500, seth vidal wrote: On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. If we're being picky then the hypervisor might be exploited during the package build, with the exploit escalating to root on the host. It's very hard to pull this off, but with security never say 'never'. In any case, using sVirt (libvirt + SELinux) should help. Rich. Meh, take it one step further, do bare hardware kickstarts, then fire up the vm within... Or maybe flash the bios first, then do the kickstart then... :) -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, 2010-12-08 at 22:02 +, Richard W.M. Jones wrote: On Wed, Dec 08, 2010 at 04:50:11PM -0500, seth vidal wrote: On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. If we're being picky then the hypervisor might be exploited during the package build, with the exploit escalating to root on the host. It's very hard to pull this off, but with security never say 'never'. In any case, using sVirt (libvirt + SELinux) should help. and this is where I stop caring. putting it in a vm means I don't care about it for MY systems b/c the systems are thrown away at the end of us. How the vendor/serviceprovider/etc of the vm-hosting-infrastructure protects themselves falls into the SEP category. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
On Dec 8, 2010, at 1:53 PM, Jeff Spaleta wrote: On Wed, Dec 8, 2010 at 6:06 PM, BJ Dierkes wdier...@5dollarwhitebox.org wrote: That is exactly right. reading over the instructions on the pypi page for cement.devtools explicitly tells people to easy_install cement prior to easy_install'ing cement.devtools, so I wanted clarification as to whether that was necessasry. I've updated this to be more accurate, thank you. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using anonymous git
Sunday Curtis Doty said: 8:08pm Ricky Zhou said: On 2010-12-05 04:56:36 PM, Curtis Doty wrote: But the equivalent 'git pull' doesn't work as I'd expect. It appears the clone -B option above sets the wrong non-anonymous url inside each branch. Am I missing something? Nope, looks like you found a bug. Here's a patch that should fix it. http://ricky.fedorapeople.org/fedpkg/0001-Handle-anonymous-clones-in-clone_with_dirs.patch patching file __init__.py Hunk #1 succeeded at 403 (offset -28 lines). Hunk #2 succeeded at 434 (offset -28 lines). Righton, thanks. It even works here against f14 current. Logged http://bugzilla.redhat.com/660183 FYI and a workaround posted. ../C -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NM: could not get owner of name
On Wed, 2010-12-08 at 21:09 +0900, Masami Ichikawa wrote: on 12/08/2010 08:51 PM, Neal Becker wrote: Should I be concerned about these? Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.539204] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.577737] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Dec 8 06:44:29 nbecker1 NetworkManager[22066]: error [1291808669.578084] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name It looks same as following reports. btw, according to #655322, it's been fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=652761 https://bugzilla.redhat.com/show_bug.cgi?id=655322 And I think we'll cherry-pick it into the next update too. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Text-Reform] Update to 1.20. Update Source0 URL. BR Module::Build and build with it. Add demo directory to docs.
commit db9c6442be0f89ce9106d5abfc671f39cfac9027
Author: Steven Pritchard steven.pritch...@gmail.com
Date: Wed Dec 8 18:04:13 2010 -0600
Update to 1.20.
Update Source0 URL.
BR Module::Build and build with it.
Add demo directory to docs.
.gitignore|1 +
perl-Text-Reform.spec | 30 ++
sources |2 +-
3 files changed, 20 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9c1a914..048cfc6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Text-Reform-v1.12.2.tar.gz
+/Text-Reform-1.20.tar.gz
diff --git a/perl-Text-Reform.spec b/perl-Text-Reform.spec
index 5c1b001..0115ac7 100644
--- a/perl-Text-Reform.spec
+++ b/perl-Text-Reform.spec
@@ -1,16 +1,17 @@
Name: perl-Text-Reform
-Version:1.12.2
-Release:11%{?dist}
+Version:1.20
+Release:1%{?dist}
Summary:Manual text wrapping and reformatting
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Text-Reform/
-Source0:
http://www.cpan.org/authors/id/D/DC/DCONWAY/Text-Reform-v%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/C/CH/CHORNY/Text-Reform-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More)
-BuildRequires: perl(version)
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod) = 1.14
+BuildRequires: perl(version)
Requires: perl(TeX::Hyphen)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -20,19 +21,18 @@ The module supplies a re-entrant, highly configurable
replacement for the
built-in Perl format() mechanism.
%prep
-%setup -q -n Text-Reform-v%{version}
+%setup -q -n Text-Reform-%{version}
chmod 644 Changes README lib/Text/*.pm
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
+%{__perl} Build.PL installdirs=vendor
+./Build
%install
rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
@@ -40,18 +40,24 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
# the testsuite fails for locales with decimal point != ., i.e. it
# fails for almost all European languages except en
-LC_NUMERIC=C make test
+LC_NUMERIC=C ./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc Changes README
+%doc Changes README demo/
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Wed Dec 08 2010 Steven Pritchard st...@kspei.com 1.20-1
+- Update to 1.20.
+- Update Source0 URL.
+- BR Module::Build and build with it.
+- Add demo directory to docs.
+
* Fri May 14 2010 Ralf Corsépius corse...@fedoraproject.org - 1.12.2-11
- Bump release for perl-5.12.0.
diff --git a/sources b/sources
index 6ba74de..66efa2f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c2dc7c1d885e5d977831d798dd31e99b Text-Reform-v1.12.2.tar.gz
+f37f5834f3dc221eacd09bdfcfe40918 Text-Reform-1.20.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: Request for comment: Potential change to dist-git branch structure
On 12/03/2010 04:34 PM, Jesse Keating wrote: So please, tell me what you think! I've created a wiki page to track this effort. Feel free to reply to this email thread or to comment on the wiki page: https://fedoraproject.org/wiki/Dist_Git_Branch_Proposal -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, Dec 08, 2010 at 11:48:26AM +, Peter Robinson wrote: On Wed, Dec 8, 2010 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: so are all these bugs, for that matter: they're actual bugs encountered by Matt. The package failing to build is clearly a bug. Matt tried to build it and so encountered the bug. Where does it fail to meet your criteria? I agree it's a bit questionable whether we should block packages for FTBFS, but the argument can clearly be made; being self-hosting is obviously important for an F/OSS project. At some point it devolves into Stallmanite wankery about whether you can flash your mouse, but where exactly we should draw the line isn't a slam-dunk :) I'm sitting on the fence on this one. There are packages built on F-12 that work perfectly well on rawhide that don't build on rawhide. What about an instance where there's dependant packages. Do they automatically get blocked too or do we go through another route of FTBFS on those too? Yes, they should get automatically blocked too. In the case of a leaf one it might be that by it not building currently doesn't affect anything and the maintainer is aware of the problem but needs the time to fix the issue properly when he gets time. In this case the maintainer then has to jump through the review process all over again to get it unblocked and then will likely just not be bothered. They shouldn't have to go through a re-review unless they've let the package sit in retirement for (I believe it's six months but someone else might have the policy URL handy). -Toshio pgpYtIzcjb51e.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
trac-0.12 in rawhide
Trac-0.12 was built in rawhide on Oct 12 (by me). I forgot that all the plugins need to be rebuilt as well. I've been working on getting trac-0.12 into EPEL6, along with the plugins. I've built trac-git-plugin and trac-mercurial-plugin (for both rawhide and epel6). I plan on doing more tomorrow, but I wouldn't turn down help along the way. Here is a list of plugins and their owner. Owners will get a nearly identical message, this one doesn't have cc's due to mailman getting annoyed. trac-accountmanager-plugin - mathstuf trac-bazaar-plugin - toshio trac-customfieldadmin-plugin - jstanley trac-doxygen-plugin - sergiopr trac-monotone-plugin - thm trac-peerreview-plugin - chitlesh trac-privateticketsplugin - jstanley trac-tickettemplate-plugin - jstanley trac-tracnav-plugin - thm trac-watchlist-plugin - jstanley trac-xmlrpc-plugin - sergiopr For testing I've got publictest03.fedoraproject.org setup as an EL6 host with trac-0.12.1 installed. I plan on copying over some project spaces from fedorahosted to play with, although some of these plugins look like things we don't necessarily use, so I could use some help testing them. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-12-08) NEW TIME
On Wed, Dec 08, 2010 at 12:02:52PM -0700, Kevin Fenzi wrote: * #512 F15Feature: LibreOffice - http://fedoraproject.org/wiki/Features/LibreOffice (nirik, 18:47:27) * LINK: https://fedorahosted.org/fesco/ticket/512 (nirik, 18:47:27) * AGREED: Feature is approved. (nirik, 18:49:05) Hm, do we require a 'feature' for every added package now? Anyway, there was nothing for FeSCo to decide there: LibO is in Rawhide (has been there for 2 months, in fact) and OO.o is not. That's all... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-12-08) NEW TIME
On Thu, 9 Dec 2010 07:25:35 +0100 David Tardon dtar...@redhat.com wrote: On Wed, Dec 08, 2010 at 12:02:52PM -0700, Kevin Fenzi wrote: * #512 F15Feature: LibreOffice - http://fedoraproject.org/wiki/Features/LibreOffice (nirik, 18:47:27) * LINK: https://fedorahosted.org/fesco/ticket/512 (nirik, 18:47:27) * AGREED: Feature is approved. (nirik, 18:49:05) Hm, do we require a 'feature' for every added package now? No. Just very visible ones. ;) See: http://fedoraproject.org/wiki/Features/Policy/Definitions Anyway, there was nothing for FeSCo to decide there: LibO is in Rawhide (has been there for 2 months, in fact) and OO.o is not. That's all... Just to decide if it was worth trumpeting as a feature. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-WWW-Mechanize] - Add BR: perl(CGI) (Fix FTBFS: BZ 661092).
commit c4031d52cbe628fd9b81bf6deb768c8565a47376
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Wed Dec 8 11:03:46 2010 +0100
- Add BR: perl(CGI) (Fix FTBFS: BZ 661092).
perl-Test-WWW-Mechanize.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-WWW-Mechanize.spec b/perl-Test-WWW-Mechanize.spec
index 2359a1b..6a82efa 100644
--- a/perl-Test-WWW-Mechanize.spec
+++ b/perl-Test-WWW-Mechanize.spec
@@ -1,6 +1,6 @@
Name: perl-Test-WWW-Mechanize
Version:1.28
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Testing-specific WWW::Mechanize subclass
Group: Development/Libraries
@@ -13,6 +13,7 @@ BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildRequires: perl(Carp::Assert::More)
+BuildRequires: perl(CGI)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTML::Lint)
BuildRequires: perl(HTTP::Server::Simple) = 0.07
@@ -64,6 +65,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Dec 08 2010 Ralf Corsépius corse...@fedoraproject.org - 1.28-2
+- Add BR: perl(CGI) (Fix FTBFS: BZ 661092).
+
* Thu May 13 2010 Petr Pisar ppi...@redhat.com - 1.28-1
- Version bump
- Sort dependencies
--
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 661092] FTBFS perl-Test-WWW-Mechanize-1.28-1.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=661092 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED CC||rc040...@freenet.de Resolution||RAWHIDE Last Closed||2010-12-08 05:09:10 --- Comment #7 from Ralf Corsepius rc040...@freenet.de 2010-12-08 05:09:10 EST --- Missing perl(CGI) Fixed in perl-Test-WWW-Mechanize-1.28-2.fc15. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POE-Component-DBIAgent] - Add BR: perl(ExtUtils::MakeMaker) (Fix FTBFS: BZ 660827).
commit 6190605525a3ad4c8bec0d8b1bc1614bdf522b4e
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Wed Dec 8 11:40:26 2010 +0100
- Add BR: perl(ExtUtils::MakeMaker) (Fix FTBFS: BZ 660827).
perl-POE-Component-DBIAgent.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Component-DBIAgent.spec b/perl-POE-Component-DBIAgent.spec
index 371ce63..df53d74 100644
--- a/perl-POE-Component-DBIAgent.spec
+++ b/perl-POE-Component-DBIAgent.spec
@@ -1,6 +1,6 @@
Name: perl-POE-Component-DBIAgent
Version:0.26
-Release:7%{?dist}
+Release:8%{?dist}
Summary:POE Component for running asynchronous DBI calls
# see tail of DBIAgent.pm
License:GPL+ or Artistic
@@ -10,6 +10,7 @@ Source0:
http://www.cpan.org/authors/id/R/RD/RDB/POE-Component-DBIAgent-%
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Class::MethodMaker), perl(DBI), perl(POE) = 0.17
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -56,6 +57,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Wed Dec 08 2010 Ralf Corsépius corse...@fedoraproject.org - 0.26.8
+- Add BR: perl(ExtUtils::MakeMaker) (Fix FTBFS: BZ 660827).
+
* Thu May 06 2010 Marcela Maslanova mmasl...@redhat.com - 0.26-7
- Mass rebuild with perl-5.12.0
--
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-Getopt-Euclid] Updated to 0.2.3
commit 590285ae26d021765e07076dfc70c8e87b72ccb3
Author: Rasmus Ory Nielsen r...@fedoraproject.org
Date: Wed Dec 8 12:05:04 2010 +0100
Updated to 0.2.3
.gitignore |1 +
perl-Getopt-Euclid.spec | 11 +++
sources |2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 303189e..f15ea2a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Getopt-Euclid-0.2.1.tar.gz
+/Getopt-Euclid-v0.2.3.tar.gz
diff --git a/perl-Getopt-Euclid.spec b/perl-Getopt-Euclid.spec
index 2d8289c..1f875c5 100644
--- a/perl-Getopt-Euclid.spec
+++ b/perl-Getopt-Euclid.spec
@@ -1,11 +1,11 @@
Name: perl-Getopt-Euclid
-Version:0.2.1
-Release:4%{?dist}
+Version:0.2.3
+Release:1%{?dist}
Summary:Executable Uniform Command-Line Interface Descriptions
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Getopt-Euclid/
-Source0:
http://search.cpan.org/CPAN/authors/id/K/KG/KGALINSKY/Getopt-Euclid-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/K/KG/KGALINSKY/Getopt-Euclid-v%{version}.tar.gz
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
BuildArch: noarch
BuildRequires: perl(Module::Build)
@@ -22,7 +22,7 @@ line argument parser. This ensures that your program's
documented interface
and its actual interface always agree.
%prep
-%setup -q -n Getopt-Euclid-%{version}
+%setup -q -n Getopt-Euclid-v%{version}
%build
%{__perl} Build.PL installdirs=vendor
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Dec 8 2010 Rasmus Ory Nielsen r...@ron.dk - 0.2.3-1
+- Updated to 0.2.3
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.2.1-4
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index bfb1918..3d96caf 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c5ffa92cce7a4561934ca0b9d20ba617 Getopt-Euclid-0.2.1.tar.gz
+6055aab59fe5cd7b5e522d9829ba5882 Getopt-Euclid-v0.2.3.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-Getopt-Euclid/f14/master] Updated to 0.2.3
Summary of changes: 590285a... Updated to 0.2.3 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Getopt-Euclid] (3 commits) ...Merge from master
Summary of changes: 87f952a... Initialize branch F-13 for perl-Getopt-Euclid (*) 11c38c4... dist-git conversion (*) 860cf7d... Merge from master (*) 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-Getopt-Euclid: 3/3] Merge from master
commit 860cf7dfd08576b066b8d70448cfb4fed7a1db80 Merge: 11c38c4 590285a Author: Rasmus Ory Nielsen r...@fedoraproject.org Date: Wed Dec 8 12:24:39 2010 +0100 Merge from master .gitignore |1 + perl-Getopt-Euclid.spec | 14 ++ sources |2 +- 3 files changed, 12 insertions(+), 5 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 660952] FTBFS perl-VCS-LibCVS-1.0002-7.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660952 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG Last Closed||2010-12-08 06:31:58 --- Comment #4 from Marcela Mašláňová mmasl...@redhat.com 2010-12-08 06:31:58 EST --- False positive. It was built in F-15 without problems. http://koji.fedoraproject.org/koji/taskinfo?taskID=2651256 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Getopt-Euclid/f14/master] (3 commits) ...Merge from master
Summary of changes: 87f952a... Initialize branch F-13 for perl-Getopt-Euclid (*) 11c38c4... dist-git conversion (*) 860cf7d... Merge from master (*) (*) 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-Getopt-Euclid/f13/master] (4 commits) ...Merge from master
Summary of changes: c18713e... - Mass rebuild with perl-5.12.0 (*) 7ae1e61... dist-git conversion (*) 590285a... Updated to 0.2.3 (*) 860cf7d... Merge from master (*) (*) 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-LWP-UserAgent-Determined] - We install into vendorlib, need proper perl version require
commit 21559b4db867c007104814e161e0ea28f79b1530
Author: Lubomir Rintel lkund...@v3.sk
Date: Wed Dec 8 14:51:56 2010 +0100
- We install into vendorlib, need proper perl version require
perl-LWP-UserAgent-Determined.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-LWP-UserAgent-Determined.spec
b/perl-LWP-UserAgent-Determined.spec
index e5676cd..9cbefb4 100644
--- a/perl-LWP-UserAgent-Determined.spec
+++ b/perl-LWP-UserAgent-Determined.spec
@@ -1,7 +1,7 @@
Summary: A virtual browser that retries errors
Name: perl-LWP-UserAgent-Determined
Version: 1.03
-Release: 7%{?dist}
+Release: 8%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/%{pkg_name}/
@@ -11,6 +11,7 @@ BuildRoot: %(mktemp -ud
%{_tmppath}/%{name}-%{version}-%{release}-XX)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(LWP::UserAgent)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
@@ -54,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Dec 08 2010 Lubomir Rintel lkund...@v3.sk - 1.03-8
+- We install into vendorlib, need proper perl version require
+
* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 1.03-7
- Mass rebuild with perl-5.12.0
--
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-Amazon-S3] - We install into vendorlib, need proper perl version require
commit cb7953b2192de4dd4362fb4596ea1e948fb5cc2d
Author: Lubomir Rintel lkund...@v3.sk
Date: Wed Dec 8 14:52:01 2010 +0100
- We install into vendorlib, need proper perl version require
perl-Net-Amazon-S3.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Net-Amazon-S3.spec b/perl-Net-Amazon-S3.spec
index 094f1e7..06ddcd6 100644
--- a/perl-Net-Amazon-S3.spec
+++ b/perl-Net-Amazon-S3.spec
@@ -1,7 +1,7 @@
Summary: Use the Amazon Simple Storage Service (S3)
Name: perl-Net-Amazon-S3
Version: 0.43
-Release: 6%{?dist}
+Release: 7%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Net-Amazon-S3/
@@ -23,6 +23,7 @@ Requires: perl(LWP::UserAgent::Determined)
Requires: perl(XML::LibXML)
Requires: perl(XML::LibXML::XPathContext)
Requires: perl(Class::Accessor)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
@@ -77,6 +78,9 @@ rm -rf %{buildroot}
%changelog
+* Wed Dec 08 2010 Lubomir Rintel lkund...@v3.sk - 0.43-7
+- We install into vendorlib, need proper perl version require
+
* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 0.43-6
- Mass rebuild with perl-5.12.0
--
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 661056] FTBFS perl-POE-Component-Server-SOAP-1.14-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=661056 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED CC||rc040...@freenet.de Resolution||RAWHIDE Last Closed||2010-12-08 11:35:36 --- Comment #7 from Ralf Corsepius rc040...@freenet.de 2010-12-08 11:35:36 EST --- Breakdown was caused by rawhide shipping an ancient perl-MooseX-POE package. I just upgraded perl-MooseX-POE and the FTBFS vanished. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MooseX-Singleton] - Upstream update (Fix FTBFS: BZ 661030). - Remove requires-filter. - Adjust BR's.
commit 5b73c083c01c694084126a7edd4203542f7650c9
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Wed Dec 8 18:41:02 2010 +0100
- Upstream update (Fix FTBFS: BZ 661030).
- Remove requires-filter.
- Adjust BR's.
.gitignore |1 +
perl-MooseX-Singleton.spec | 30 ++
sources|2 +-
3 files changed, 12 insertions(+), 21 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 444175a..3ed2b9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
MooseX-Singleton-0.21.tar.gz
+/MooseX-Singleton-0.25.tar.gz
diff --git a/perl-MooseX-Singleton.spec b/perl-MooseX-Singleton.spec
index 44e7738..a9fec97 100644
--- a/perl-MooseX-Singleton.spec
+++ b/perl-MooseX-Singleton.spec
@@ -1,6 +1,6 @@
Name: perl-MooseX-Singleton
-Version:0.21
-Release:4%{?dist}
+Version:0.25
+Release:1%{?dist}
Summary:Turn your Moose class into a singleton
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,16 +9,15 @@ Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/MooseX-Singl
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
-BuildRequires: perl(Moose) = 0.82
+BuildRequires: perl(Moose) = 1.10
BuildRequires: perl(Test::Exception)
-BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::More) = 0.88
+BuildRequires: perl(Test::Requires)
BuildRequires: perl(Test::Warn)
BuildRequires: perl(MooseX::StrictConstructor)
BuildRequires: perl(Test::Exception)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(Moose) = 0.82
-
%description
A singleton is a class that has only one instance in an application.
MooseX::Singleton lets you easily upgrade (or downgrade, as it were) your
@@ -27,20 +26,6 @@ Moose class to a singleton.
%prep
%setup -q -n MooseX-Singleton-%{version}
-# Filter requires
-cat \EOF %{name}-req
-#!/bin/sh
-%{__perl_requires} $* |\
-sed -e '/perl(MooseX::Singleton::Meta::Class)/d' |\
-sed -e '/perl(MooseX::Singleton::Meta::Instance)/d' |\
-sed -e '/perl(MooseX::Singleton::Meta::Method::Constructor)/d' |\
-sed -e '/perl(MooseX::Singleton::Object)/d'
-EOF
-
-%define __perl_requires %{_builddir}/MooseX-Singleton-%{version}/%{name}-req
-chmod +x %{__perl_requires}
-
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -68,6 +53,11 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Dec 08 2010 Ralf Corsépius corse...@fedoraproject.org - 0.25.1
+- Upstream update (Fix FTBFS: BZ 661030).
+- Remove requires-filter.
+- Adjust BR's.
+
* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 0.21-4
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 6385db5..d2549ab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e7f909e849af402aff480053e8be1cbe MooseX-Singleton-0.21.tar.gz
+24275a99350ab6ac2942dbe976f4edfb MooseX-Singleton-0.25.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 661030] FTBFS perl-MooseX-Singleton-0.21-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=661030 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED CC||rc040...@freenet.de Resolution||RAWHIDE Last Closed||2010-12-08 12:45:52 --- Comment #7 from Ralf Corsepius rc040...@freenet.de 2010-12-08 12:45:52 EST --- The package's infrastructure had been updated, but the package is too old for it. Upgrading helps Fix in perl-MooseX-Singleton-0.25-1.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 661002] FTBFS perl-POE-Component-Server-XMLRPC-0.05-8.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=661002 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED CC||rc040...@freenet.de Resolution||RAWHIDE Last Closed||2010-12-08 13:00:43 --- Comment #7 from Ralf Corsepius rc040...@freenet.de 2010-12-08 13:00:43 EST --- Missing BR: perl(ExtUtils::MakeMaker) Fixed in perl-POE-Component-Server-XMLRPC-0.05-9.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 661470] New: perl-Class-XSAccessor-1.11 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Class-XSAccessor-1.11 is available https://bugzilla.redhat.com/show_bug.cgi?id=661470 Summary: perl-Class-XSAccessor-1.11 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-Class-XSAccessor AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, psab...@redhat.com Classification: Fedora Latest upstream release: 1.11 Current version in Fedora Rawhide: 1.10 URL: http://search.cpan.org/dist/Class-XSAccessor/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 661472] New: perl-Padre-0.76 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Padre-0.76 is available https://bugzilla.redhat.com/show_bug.cgi?id=661472 Summary: perl-Padre-0.76 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 0.76 Current version in Fedora Rawhide: 0.74 URL: http://search.cpan.org/dist/Padre/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 654773] perlbrew-0.15 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=654773 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perlbrew-0.14 is available |perlbrew-0.15 is available Bug 654773 depends on bug 653049, which changed state. Bug 653049 Summary: Review Request: perl-File-Path-Tiny - Recursive versions of mkdir() and rmdir() without as much overhead as File::Path https://bugzilla.redhat.com/show_bug.cgi?id=653049 What|Old Value |New Value Resolution||ERRATA Status|ON_QA |CLOSED --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2010-12-08 14:43:49 EST --- Latest upstream release: 0.15 Current version in Fedora Rawhide: 0.14 URL: http://search.cpan.org/dist/App-perlbrew/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Text-WordDiff-0.05.tar.gz uploaded to lookaside cache by steve
A file has been added to the lookaside cache for perl-Text-WordDiff: e0dd883f1b208b02a63f8da1de4a2061 Text-WordDiff-0.05.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 Text-Reform-1.20.tar.gz uploaded to lookaside cache by steve
A file has been added to the lookaside cache for perl-Text-Reform: f37f5834f3dc221eacd09bdfcfe40918 Text-Reform-1.20.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-WordDiff] Update to 0.05.
commit 1a3b167071a87f5180f83c98c3fb20e06119c5bb
Author: Steven Pritchard steven.pritch...@gmail.com
Date: Wed Dec 8 17:46:53 2010 -0600
Update to 0.05.
.gitignore |1 +
perl-Text-WordDiff.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index afbe874..1e6ac7d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Text-WordDiff-0.04.tar.gz
+/Text-WordDiff-0.05.tar.gz
diff --git a/perl-Text-WordDiff.spec b/perl-Text-WordDiff.spec
index 7930e7b..32018c4 100644
--- a/perl-Text-WordDiff.spec
+++ b/perl-Text-WordDiff.spec
@@ -1,6 +1,6 @@
Name: perl-Text-WordDiff
-Version:0.04
-Release:5%{?dist}
+Version:0.05
+Release:1%{?dist}
Summary:Track changes between documents
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Dec 08 2010 Steven Pritchard st...@kspei.com 0.05-1
+- Update to 0.05.
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.04-5
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index b18d4c5..0049624 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c647ac82c5d63f022a152ab298c7b331 Text-WordDiff-0.04.tar.gz
+e0dd883f1b208b02a63f8da1de4a2061 Text-WordDiff-0.05.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 Text-Diff-HTML-0.06.tar.gz uploaded to lookaside cache by steve
A file has been added to the lookaside cache for perl-Text-Diff-HTML: 27d6447eebebcfb620977aba8a9b9300 Text-Diff-HTML-0.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
