SPEC: http://bochecha.fedorapeople.org/packages/perl-AnyEvent-DBus.spec SRPM: http://bochecha.fedorapeople.org/packages/perl-AnyEvent-DBus-0.31-1.fc15.src.rpm Description: Loading this module will install the necessary magic to seamlessly integrate Net::DBus into AnyEvent. $ rpmlint -i perl-AnyEvent-DBus.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint -i perl-AnyEvent-DBus-0.31-1.fc15.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint -i perl-AnyEvent-DBus-0.31-1.fc15.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
This a small noarch package (no locales, no large documentation, etc ...) MUST: rpmlint must be run on src.rpm and rpm OK $rpmlint -iv perl-AnyEvent-DBus-0.31-1.fc15.src.rpm perl-AnyEvent-DBus.src: I: checking perl-AnyEvent-DBus.src: I: checking-url http://search.cpan.org/dist/AnyEvent-DBus/ (timeout 10 seconds) perl-AnyEvent-DBus.src: I: checking-url http://www.cpan.org/authors/id/M/ML/MLEHMANN/AnyEvent-DBus-0.31.tar.gz (timeout 10 seconds) 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint -iv perl-AnyEvent-DBus-0.31-1.fc15.noarch.rpm perl-AnyEvent-DBus.noarch: I: checking perl-AnyEvent-DBus.noarch: I: checking-url http://search.cpan.org/dist/AnyEvent-DBus/ (timeout 10 seconds) 1 packages and 0 specfiles checked; 0 errors, 0 warnings. MUST: package named accordingly to package naming guidelines OK MUST: spec file name match %{name} OK MUST: package meets packaging guidelines OK MUST: package must be licensed under a fedorfa-compliant license OK (GPL or artistic) MUST: License field in package spec match actual license OK MUST: spec in legible american english OK MUST: sources provided match upstream's OK provided sources sha1sum: fe86814d372149acc7f7c264c50b1d6f548af90b CPAN sources sha1sum: fe86814d372149acc7f7c264c50b1d6f548af90b MUST: package successfully compiles on at least one primary architecture (all of them) OK MUST: all build dependencies are listed in BR OK MUST: package must own all directories it creates OK MUST: package does not list a file more than once in %files section OK MUST: permissions are properly set OK MUST: package consistenly use macros OK MUST: package contains permissable content OK MUST: package does not own directories owned by other packages OK MUST: all filenames in package are valid UTF-8 OK SHOULD: packager should request upstream to include a proper license file (and not just telling that it is licensed in the same terms are perl-AnyDBus which is already provided by Fedora) NOTABLOCKER SHOULD: mock builds were done for fedora 14/devel on all primary architectures (x86/x86_64) OK SHOULD: the module provided works (yuck, i had to write some Perl) OK SHOULD: man pages are provided, not mandatory since it does not provide any binary/script but worth mentionning it. Hereby, i give you my blessing for importing this package into our packages collection ! Have fun !
Thanks Haikel! New Package SCM Request ======================= Package Name: perl-AnyEvent-DBus Short Description: Adapt Net::DBus to AnyEvent Owners: bochecha Branches: el6 InitialCC: perl-sig
Why only an el6 branch and no fedora branches? I don't consider it reasonable to add a package to an EHEL class distro without supporting Fedora branches.
(In reply to comment #3) > Why only an el6 branch and no fedora branches? Because I only am interested in el6. > I don't consider it reasonable to add a package to an EHEL class distro without > supporting Fedora branches. I think it's perfectly reasonable, and it happens for some packages already. Rawhide will be created anyway (no need to ask for it in the SCM request), so I'll support that of course. And after the mass branching, there will be an F15 branch, and I'll have to support that as well. And then... I have absolutely no interest whatsoever in **current** Fedora releases for this package, that doesn't mean I won't take care of the **future** ones once they get created. And if you want to maintain the f13/f14 branches, I would be more than happy to have a co-maintainer. :)
I think it's time to call FESCO and let them decide whether directly pushing packages into EPEL without also pushing them into Fedora is helpful.
(In reply to comment #5) > I think it's time to call FESCO and let them decide whether directly pushing > packages into EPEL without also pushing them into Fedora is helpful. http://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F And like I said, it **will** be in Fedora since the Rawhide branch will be created, even though I don't explicitly request it.
https://fedorahosted.org/fesco/ticket/560 (In reply to comment #6) > (In reply to comment #5) > > I think it's time to call FESCO and let them decide whether directly pushing > > packages into EPEL without also pushing them into Fedora is helpful. > > http://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F New ticked filed: https://fedorahosted.org/fesco/ticket/560 > And like I said, it **will** be in Fedora since the Rawhide branch will be > created, even though I don't explicitly request it. You actually mean: Fedora will inevitably inherit it from rawhide.
are you bored or what ? Maintainers are only compelled to maintain new packages from rawhide and branched versions onwards, other branches are left to maintainer's appreciation. Since we have branch-grained ownership, that does not prevent anyone to maintain branches for older releases. Filling a ticket at fesco's tracker for such non-sense is ridiculous.
(In reply to comment #8) [Hostile rude offenses deleted] > Filling a ticket at fesco's tracker for such non-sense is ridiculous. It's the appropriate response to people whom of who I feel have not understood Fedora and do not want to comprehend the consequences of their deeds.
> It's the appropriate response to people whom of who I feel have not understood Fedora and do not want to comprehend the consequences of their deeds. I would not qualify an active and well behaved contributor for now years as someone who "have not understood Fedora and do not want to comprehend the consequences of their deeds". Looks like your standards for offenses are pretty low but anyway please don't bring private issues into the public arena. I don't care what, why and how it happened, but *this* is a non-issue, no matter how you look at it. I know you're way much better than that.
Ralf's discourse may be bereft of tact, but the point remains that he's concerned about statements such as "I only am interested in el6." As am I, honestly. EPEL is supposed to be an easy way to get Fedora packages on RHEL, but statements such at that make it seem that Fedora is merely an annoyance required to get things into EPEL. I don't have much faith in the maintenance of this package in Fedora branches moving forward if that's the case. But, Ralf, honestly you should look at the pile of python26 packages if you really want to have this discussion. They have no relevance anywhere except RHEL5. Picking a fight in this ticket isn't going to help matters.
(In reply to comment #11) > But, Ralf, honestly you should look at the pile of python26 packages if you > really want to have this discussion. They have no relevance anywhere except > RHEL5. ... and of no relevance in rawhide, either. > Picking a fight in this ticket isn't going to help matters. Well, life is too short and valuable to not tell people about their wrong-doings. Anyway, let me reduce this to a pragmatical issue: Shall I take over this package right now or shall I wait until I can't avoid to interfere in my role as "perl-sig participator", because the original maintainer "is only interested in el6"?
(In reply to comment #11) > Ralf's discourse may be bereft of tact, but the point remains that he's > concerned about statements such as "I only am interested in el6." As am I, > honestly. Perhaps I didn't chose my words carefully enough though, please put that on account of me not being a native english speaker and allow me to rephrase: I only depend on this package being in EPEL6, so I have a particular interest for this branch. In other words, that is a positive statement about the EPEL6 branch, it is not a negative statement about the Fedora ones. I will take care of this packages in all the branches it has been pushed to, but as a maintainer, I have always thought I had the right to decide in which branch I would push my package. > EPEL is supposed to be an easy way to get Fedora packages on RHEL, > but statements such at that make it seem that Fedora is merely an annoyance > required to get things into EPEL. That's not the case. In the past I have only ever contributed to Fedora, since I have never needed anything in EPEL. But if someone had asked me to push one of my packages to EPEL (and if I had the required amount of time to take care of it afterwards), then I would have. This time, it is the other way around: I only need this package in EPEL6, but I will take care of it in Fedora as well. Actually, if Ralf's (or anyone else's for that matter) initial comment had been « I'd like to see this package in Fedora 14 as well, and will help you maintain it in this branch », then I would have asked for it and set him as co-maintainer. I would even have made the initial builds and update requests, since I was doing all that for Rawhide and EPEL6 anyway, and we'd have coordinated the next builds/updates, as is certainly the case for any package maintained by more than one person. But you'll agree that it would have been a very different request from « I don't consider it reasonable », which (at least to me) sounds more like « you will do all the work because I say so ».
Git done (by process-git-requests).