Re: Perl RPM Requires/Provides
> "ES" == Emmanuel Seyman writes: ES> Note that there's only the option of selectively removing the ES> automatically found values: ES> http://fedoraproject.org/wiki/Packaging:Perl#Filtering_Requires:_and_Provides Well, actually if you look at what's on that page, it should be pretty obvious how to simply not call the old __perl_provides or __perl_requires scripts and not get any automatic Perl dependencies. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Question about .bs files
> "OP" == Orion Poplawski writes:
OP> Can anyone tell me what the purpose of an empty *.bs files in the
OP> auto directory tree would be? Do we need to package them?
You shouldn't package them. There's a reason the specfle template
deletes them:
# Remove the next line from noarch packages (unneeded)
find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
- J<
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: tests in %doc?
> "SK" == Stepan Kasal writes: SK> Hello, I have noticed that some of the perl module packages do pack SK> their tests in the %doc subdirectory. Is that intentional? One maintainer insists on doing it. I think it's pointless, but I gave up arguing long ago. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Packaging CPAN modules for Fedora, the Oslo QA Hackathon, CPAN::Porters
> "GS" == Gabor Szabo <[EMAIL PROTECTED]> writes: GS> What others would you include in that list? The current set of approved licenses should be at http://fedoraproject.org/wiki/Licensing (which isn't responding for me at the moment, so I can't cut'n'paste for you). - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Packaging CPAN modules for Fedora, the Oslo QA Hackathon, CPAN::Porters
> "GS" == Gabor Szabo <[EMAIL PROTECTED]> writes: GS> So if you do find a module with problematic licenses it would be GS> great if you could check if CPANTS http://cpants.perl.org/ has GS> also caught that issue. This is good news; Perl modules have often been a source of licensing trouble due to missing or contradictory licenses. Please also note that in Fedora, "problematic license" applies to the plain Artistic license, so if a package licensed under the original Artistic license (not the clarified or 2.0 versions) and does not also have some other license (such as in the "Same as Perl" "GPL+ or Artistic") then it is unfortunately not acceptable for Fedora. For example, Net-SinFP has 104.17% "Kwalitee" on the CPANTS site but is not acceptable for Fedora because it carries only the Artistic license. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Packaging CPAN modules for Fedora, the Oslo QA Hackathon, CPAN::Porters
> "DC" == Dave Cross <[EMAIL PROTECTED]> writes: DC> I've always had a sneaking suspicion that what I've got are good DC> enough for me, but not for Fedora's repositories. Well, modern cpanspec generates pretty good specs. Generally what you need to do is verify the license (which unfortunately seems to be the most time-consuming bit these days), change the License: tag appropriately, and add build dependencies (BuildRequires:) sufficient to get the module to build in mock and be able to run as much of its test suite properly. A quick glance over the Summary: and %description helps as well. If the license is unambiguous, this takes a couple of minutes plus whatever time it takes mock to run. Submitting the review takes a couple of minutes more. Generally Perl packages are reviewed quickly because the reviewer usually just needs to verify that you've done the stuff in the previous paragraph. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: How to have Perl packages co-maintained by perl-sig?
> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes: SK> But I'm not going to make a request now, as I do not want to SK> interfere with Jason's activity. I was done with what I was doing about ten minutes after I sent my message, which is over six days ago. I only did Alex's packages. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: How to have Perl packages co-maintained by perl-sig?
> "AL" == Alex Lancaster <[EMAIL PROTECTED]> writes: AL> I have a number of Perl packages that don't have the Perl SIG AL> There doesn't seem to be any way to add (or request that) a AL> co-maintainer be added via PackageDB. My Perl packages can are AL> listed here: Normally the co-maintainer makes the request, but that would require someone to log into pkgdb as perl-sig which I am not sure is possible. So an admin needs to this. I'm working through them but if I miss any you can just make a regular CVS request. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: perl-DBI - split?
> "RN" == Robin Norwood <[EMAIL PROTECTED]> writes: RN> Hi, The issue of .h files in a non-devel RPM rears its head again. RN> In the package review for perl-DBI, my package reviewer points out RN> rpmlint warnings about .h files in a non-devel package. Pretty much every arch-specific Perl module will have a .h file buried fifteen directories under /usr/lib/perl5. It would be insanity to split them all out. There's no directory ownership issue like there is with .pc files, and frankly I don't know what on earth would actually use those .h files. In all of the Perl package reviews I have done, I have allowed those files to remain in the main package. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: License tag for perl modules
> "IB" == Ian Burrell <[EMAIL PROTECTED]> writes: IB> Why would Artistic license be considered unacceptable for Fedora? It's in the "Bad Licenses" list at the bottom of http://fedoraproject.org/wiki/Licensing IB> Also, the Artistic 2.0 license is different. Yes, as recognized on the above page. IB> It should be tagged separately. It isn't? It sure seems to be tagged separately to me, according to the above page. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: License tag for perl modules
> "PH" == Paul Howarth <[EMAIL PROTECTED]> writes: PH> rpmlint (at least up to rpmlint-0.80-2) still complains about PH> this: Yes, Ville has indicated that he's fixing this. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: License tag for perl modules
> "RN" == Robin Norwood <[EMAIL PROTECTED]> writes: RN> So you may want to update the license field as you go (Not RN> blindly, of course...there are probably exceptions). I think there may be a few modules out there which are Artistic _only_, which it seems makes them unacceptable for Fedora. I honestly had no clue that the artistic license was considered non-free until spot started the recent licensing work. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: mark pod files as %doc?
> "CG" == Chris Grau <[EMAIL PROTECTED]> writes:
CG> Which means they'd be installed under
CG> /usr/share/doc/%{name}-%{version}, right?
No, it means they'd be marked as %doc and therefore wouldn't be
installed with an --excludedocs install.
- J<
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Archive::Zip - 'unauthorized' release.
> "RN" == Robin Norwood <[EMAIL PROTECTED]> writes: RN> Is there a general policy for this sort of situation, and if not, RN> should there be? I'm not sure we could make one. When upstream forks (or pseudo-forks as seems to have happened here), we're going to have to figure out what to do on a case-by-case basis. RN> Should something be added to the perl packaging guidelines, I don't see that any of the basic issues are perl-specific. RN> and what do you think we should do in this instance, other than RN> wait for a response from Adam? Well, I think we should always try to stay well-informed as to the state of the upstream developers and in good communication with them. It never hurts to ask them what's up and get their opinions on what we should be doing with their packages. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Test::Pod::Coverage tests...
> "RC" == Ralf Corsepius <[EMAIL PROTECTED]> writes: RC> You don't want to know about the bugs and deficits your packages RC> suffer from? Well, to play devil's advocate, if we're to consider lack of documentation coverage a bug and block inclusion of packages due to those bugs, then we shouldn't even have a kernel. Of course we should run test suites, and we should of course block packages when those test suites fail but are expected to pass. But blocking due to lack of documentation coverage is pushing things a bit beyond the bounds of reason. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: The next time you need to build a stack of modules...
> "SP" == Steven Pritchard <[EMAIL PROTECTED]> writes: SP> I just tried this with OpenFrame (something I manually built all SP> the dependencies for a while back), and it looks like I'm down to SP> 5 required modules that aren't in Extras already. Looks like I'll have more Perl modules to review. - J< -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Filtering requires/provides
> "SP" == Steven Pritchard <[EMAIL PROTECTED]> writes:
SP> Yes, this changes filter-requires.sh, so any source rpm built from
SP> this will have @@PERL_REQ@@ pre-substituted, but is that really a
SP> major problem?
I think any modification to the source directory is going to be
problematic. There's no guarantee that the RPM builder is going to
have write access to that directory. (It won't work one of my setups,
where that directory is readable but not writable by the user I build
RPMs as.)
So where are we at? We can't mess with buildroot (because the
module's signing stuff will complain) and we can't mess with
sourcedir. How about just making another directory:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)-blah
emitting the script there (or copying it through sed to do the
expansion) and then cleaning it up in %clean?
- J<
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
