Spec URL: https://github.com/hroncok/SPECS/raw/master/perl-Growl-GNTP.spec SRPM URL: https://github.com/downloads/hroncok/SPECS/perl-Growl-GNTP-0.15-1.fc17.src.rpm Description: Perl implementation of GNTP Protocol (Client Part) Fedora Account System Username: churchyard
Picking this one, since it looks like we are working on/packaging same thing. * spec file clean, in american english * license ok * source matches upstream, clean without binaries * rpmlint silent, package builds - many BR are redundant and useless, while most of them is pulled in by perl or automatically generated by rpmbuild. list only what you really need to build (in mock). - is there anything to filter out with this? %{?perl_default_filter} # Filters (not)shared c libs - use dos2unix BR rather than this: sed -i "s/\r//" README - specfile is not consistent with provided srpm
> many BR are redundant and useless, while most of them is pulled in by perl or automatically generated by rpmbuild. list only what you really need to build (in mock). I've noticed Requires are autogenerated, but how this works with BR? I supposed the autogeneration is done during the build procces, while chcecking if BRs are present is done before the build. May I simply remove BRs provided by the perl package?
Blah, you are right (should have corrected myself after correcting myself). Requires are only auto generated for install, not for build. Anyway, don't pull pull in explicitly packages provided by perl itself. cpanspec usually generates sane BR list. Test with minimum, in mock, if it builds and tests are run.
Spec URL: https://github.com/hroncok/SPECS/raw/master/perl-Growl-GNTP.spec SRPM URL: https://github.com/downloads/hroncok/SPECS/perl-Growl-GNTP-0.15-2.fc17.src.rpm - Removed BRs provided by perl package - Removed useless perl autofilter - Using dos2unix
Still, you don't need to require each module used at runtime, just to build a package. I was able to build this package with as minimum as this: BuildRequires: perl(Crypt::CBC) >= 2.29 BuildRequires: perl(Data::UUID) >= 0.149 BuildRequires: perl(Digest::MD5) >= 2.36 BuildRequires: perl(Digest::SHA) >= 5.45 BuildRequires: perl(ExtUtils::MakeMaker) BuildRequires: perl(ExtUtils::MM_Unix) Another thing is, there are bundled modules of Module::Install in 'inc/' added by author via Module::Install. You should remove this and use Module::Install from fedora. In this phase, there will be missing Module::Install::AuthorTests (not in repositories) and probably others (that are not listed above). Or you can disable author_tests in Makefile.PL. This tests are not run anyway.
I was told I need all modules in BR, so tests can run. How it works?
The only test that will run, in this case, is t/00 (simple inclusion). t/01 will fail softly, as there is no growl backend to send to. xt are not run, because you are not "author". Build in mock, look into build output in build.log. So remove 'inc' directory, and see, where that will lead; what packages you will (really) need. I would consider it optional, whether you want to run author_tests or not. As of f18 there is perl(Module::Install::AuthorTests), #809931.
Spec URL: https://github.com/hroncok/SPECS/raw/master/perl-Growl-GNTP.spec SRPM URL: https://github.com/downloads/hroncok/SPECS/perl-Growl-GNTP-0.15-3.fc17.src.rpm - Removed local inc and xs directories - Patched source so it doesn't need them - Removed lots of BR (builds in mock)
It's perl(Module::Install), not perl(inc::Module::Install) (provided by the same package). Otherwise OK. APPROVED
It seems to be inc::Module::Install. If I use Module::Install it yells.
(In reply to comment #10) > It seems to be inc::Module::Install. If I use Module::Install it yells. Use it as BR, not in Makefile.PL. That one should use inc::Module::Install, so it can override system module from 'inc/' directory.
Spec URL: https://github.com/hroncok/SPECS/raw/master/perl-Growl-GNTP.spec SRPM URL: https://github.com/downloads/hroncok/SPECS/perl-Growl-GNTP-0.15- 4.fc17.src.rpm - perl(inc::Module::Install) to perl(Module::Install)
New Package SCM Request ======================= Package Name: perl-Growl-GNTP Short Description: Perl implementation of GNTP Protocol (Client Part) Owners: churchyard ksyz Branches: f17 f18 InitialCC:
Git done (by process-git-requests).
(In reply to comment #9) > It's perl(Module::Install), not perl(inc::Module::Install) (provided by the > same package). > > Otherwise OK. > > APPROVED @Michal, perhaps you should read the review guidelines once again: http://fedoraproject.org/wiki/Packaging:ReviewGuidelines A review shouldn't be picking this and that from the spec file and having a look around... We need a Mock or Koji build, the rpmlint output for all packages (srpm, rpm, debug packages if any), comparing the original and packaged sources and so on. Should you actually know as a sponsored packager.
(In reply to comment #15) > @Michal, perhaps you should read the review guidelines once again: > http://fedoraproject.org/wiki/Packaging:ReviewGuidelines > A review shouldn't be picking this and that from the spec file and having a > look around... We need a Mock or Koji build, the rpmlint output for all > packages (srpm, rpm, debug packages if any), comparing the original and > packaged sources and so on. Should you actually know as a sponsored packager. @mario, it's hard to reply to your rant, when it looks like, you didn't even read the review. That guideline, you cited, can you, probably, provide a source? Or a reason, why you think a reviewer should not look around in the package, and pick parts from spec file? "If it builds, ship it" is not a good policy.
(In reply to comment #16) > "If it builds, ship it" is not a good policy. That's not what I said. Of course rpmlint doesn't find all problems, but this is no reason to omit it. Have a look at some of my reviews to see what I mean [1]. The rpmlint output and a complete checklist is always present, and if there are some other issues, I report them, as far as I've found them. By the way, I'm even not convinced about fedora-review. Well, it seems to make the reviewers' job easier, but it tempts to _not_ looking around the files and assume to that all is already done by this tool. That's why I don't use it. I've had such reviews for my own packages, with lots of impressive output and even a lot of useless stuff. But the actual problems haven't been found, so that I had to do more work after pushing it to testing. Just for clarifying that I don't prefer semi-automatic workflow. However, the package has been approved, the Git repo created, and it is on the way to the users. I know, most issues in packages come up after the review. But if we would consider this as a thing which happens anyway, we could stop reviewing packages in general. [1] https://bugzilla.redhat.com/buglist.cgi?resolution=CURRENTRELEASE&resolution=RAWHIDE&resolution=ERRATA&resolution=NEXTRELEASE&resolution=---&classification=Fedora&emailtype1=substring&query_format=advanced&emailassigned_to1=1&bug_status=ON_QA&bug_status=CLOSED&email1=mario.blaettermann%40gmail.com&component=Package%20Review&product=Fedora&list_id=853171
(In reply to comment #17) > However, the package has been approved, the Git repo created, and it is on > the way to the users. I know, most issues in packages come up after the > review. But if we would consider this as a thing which happens anyway, we > could stop reviewing packages in general. I've stopped working on this, the repo was created, however, I wait for this discusion to end somehow, before I continue.
(In reply to comment #18) > I've stopped working on this, the repo was created, however, I wait for this > discusion to end somehow, before I continue. Go ahead as usual. Don't misunderstand me, I don't want to roll back anything. The repo has been created, and you should build your packages now. The only thing which I would show is that I don't recognize this as the right way to review packages. We have the review guidelines, and we should follow them. This is not about the quality of your package, it was just about the quality of the review. Of course, we can change everything once the packages have been built and some bugs come up. But we could perhaps avoid this by doing reviews according to the guidelines.
(In reply to comment #18) > I've stopped working on this, the repo was created, however, I wait for this > discusion to end somehow, before I continue. Until Mario (or anyone else) raises any objection or blocker, you are free to continue and submit builds. (In reply to comment #19) > The only thing which I would show is that I don't recognize this as the > right way to review packages. We have the review guidelines, and we should > follow them. This is not about the quality of your package, it was just > about the quality of the review. Of course, we can change everything once > the packages have been built and some bugs come up. But we could perhaps > avoid this by doing reviews according to the guidelines. There is no guideline, that requires use of fedora-review(1). As sponsor, you should know that. If you found that any of (and even 'SHOULD') guidelines were violated, please, state it here, so we can fix it. While doing review-review, if there are any parts of review, that are not clear to you, I will happily explain them. Community projects are about cooperation and communication, not only guidelines, even if there is no guideline for that. If this should go more OT, please contact me (cc my sponsor) via mail. Thanks.
Hi, I have some troubles with fedora-scm. I've run fedpkg import xxx.src.rpm I've commited the changes and pushed. Now if I want to run fedpkg build or fedpkg switch-branch f18, I get this error: Could not execute switch_branch/update: /home/churchyard/rpmbuild/fedora-scm/perl-Growl-GNTP has uncommitted changes. Use git status too see details $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: .gitignore # new file: perl-Growl-GNTP-0.15-3.inc-and-xt-dereference.patch # new file: perl-Growl-GNTP.spec # modified: sources # $ git commit -am "Some message" $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: .gitignore # new file: perl-Growl-GNTP-0.15-3.inc-and-xt-dereference.patch # new file: perl-Growl-GNTP.spec # modified: sources # How is this possible?
Never mind, I deleted the folder and cloned it again.
perl-Growl-GNTP-0.15-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Growl-GNTP-0.15-4.fc17
perl-Growl-GNTP-0.15-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Growl-GNTP-0.15-4.fc18
perl-Growl-GNTP-0.15-4.fc18 has been pushed to the Fedora 18 testing repository.
perl-Growl-GNTP-0.15-4.fc18 has been pushed to the Fedora 18 stable repository.
perl-Growl-GNTP-0.15-4.fc17 has been pushed to the Fedora 17 stable repository.
Package Change Request ====================== Package Name: perl-Growl-GNTP Branches: f17 f18 Owners: InitialCC: perl-sig Please add perl-sig user with watch* permissions only to all Fedora branches.
Done.