Re: Question about dist-cvs make targets
DC == David Cantrell dcantr...@redhat.com writes:
DC I was using 'unused-patches' until the packaging guidelines had us
DC change Patch lines to use %{name} if that applied.
Please quote chapter and verse there. I don't recall any guidelines
requiring such a thing.
- J
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Need a sponsor: mod_proxy_html (apache)
MB == Mat Booth fed...@matbooth.co.uk writes: MB Here is a list of review requests that are not yet assigned to a MB reviewer: Rather than huge bugzilla queries, why not just http://fedoraproject.org/PackageReviewStatus/ ? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
IRP == Itamar Reis Peixoto ita...@ispbrasil.com.br writes: IRP because renaming it will cause problems, Actually not if done in conjunction with a release bump, such as we do with a mass rebuild. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
RK == Rudolf Kastl che...@gmail.com writes: RK 2. qstat and torque-client both provide a qstat binary... is there RK anything done to get that resolved upstream? or is it a conflicts RK and forget scenario? This one, I think, should be easily resolvable with alternatives. Actually I think all but a small number of the currently conflicting packages could be fixed up pretty easily. Currently it doesn't seem that there's any sort of enforcement outside of the original package review. The way around this is, of course, for someone to spend some time generating the current list of conflicting packages, proposing solutions, and working with FESCo in the case that those solutions are not applied. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
ST == Steve Traylen steve.tray...@cern.ch writes: ST Would be happy for an alternatives solution. I have yet another ST /usr/bin/qstat for a POSIX interface to batch on the way at some ST point. Turns out that the other queuing systems (torque and gridengine) have already renamed their qstat binaries (to qstat-torque and qstat-ge). I would expect that other queuing packages should do the same. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Ubuntu shows updates / security updates on shell logins
RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ Newly installed Ubuntu 9.10, when you log in over ssh you may see: RWMJ 34 packages can be updated. 10 updates are security updates. What a terrible idea. My users, who are welcome to ssh into a number of machines at my site, have no need to see that information. RWMJ Actually I was trying to work out how it's implemented. Get information, append to /etc/motd. You could parse yum output in a cron job if you really wanted it. It would almost certainly be better to mail that information, though, if the admin really wants it. I often go some time without actually having to ssh into many of my server. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pyhton image
JM == Jonathan MERCIER bioinfornat...@gmail.com writes: JM Dear sir, I have open a bug: JM https://bugzilla.redhat.com/show_bug.cgi?id=532248 JM But i have any answer! What can i do? Somehow acquire patience? Work on debugging the problem yourself? You haven't given much time at all for the volunteer on the other end of that bug report to look at it (not even three weekdays). - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
SD == Steve Dickson ste...@redhat.com writes: SD On the server (Which is suggested): Add the following entry to the SD /etc/exports file: SD / *(ro,fsid=0) SD Note: 'fsid=0' is explained in the exports(5) man pages. Could someone comment on any potential security issues that exporting the root in this way exposes? If all of my exported filesystems happen to live under /export, can I export that directory instead of '/' and have things work properly? If, for whatever reason, I need to export a file system that doesn't live in /export, would I still be able to mount it? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Perl RPM Requires/Provides
ES == Emmanuel Seyman emmanuel.sey...@club-internet.fr 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: Removing provide statement from an existing spec file
SSF == Stefan Schulze Frielinghaus ste...@seekline.net writes: SSF If I interpret the naming guidelines right, then a period is not SSF allowed in a package name. Could you indicate where in the naming guidelines you see that a period is not valid in a package name? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
FJR == Jaroslav Reznik jrez...@redhat.com writes: FJR * Phonon backend not as mature as Xine one FJR - missing functionality Perhaps you could supply more detail as to which functionality is missing? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Where is Callum Lerwick / seg?
I know that Callum has in the past had periods where he is very busy. Given that he's asked for assistance before, and that no reasonable maintainer wouldn't want help from experienced packagers when busy, I went ahead and approved agoode and rdieter's requests for watchbugzilla, watchcommits and commit privileges on the openjpeg package. I did not approve oliver's requests as he only requested commit access without asking for watchbugzilla or watchcommits, which I don't think it a terribly good idea. I also did not approve the requests for approveacls, just in case Callum still wishes to maintain control over that. Also, note the EPEL is orthogonal to this; if the maintainer doesn't respond one way or another to a request to branch for EPEL, the policy says that you can just branch for EPEL without them. http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fwd: [Bug 249824] Review Request: last.fm - listen to last.fm radio stations
MAS == Michel Alexandre Salim michael.silva...@gmail.com writes: MAS Who is this Piotr Drag and why is he suddenly Cc:ing himself on MAS very old bug requests? I assume you mean un-ccing himself. Do you believe he has violated some rule by removing himself from the CC list of several bugs? I can't see how he's done anything even remotely improper. I can't see why his identity eveen remotely of any concern. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about .bs files
OP == Orion Poplawski or...@cora.nwra.com 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: how to determain those no longer required packages
AT == Axel Thimm axel.th...@atrpms.net writes: AT I don't think apt traces whether a packages was a pulled in manually AT or automatically, does it? yum does keep track of many things in the yumdb and I think the reason key is supposed to track this, but for me it seems reason is always user. I think the intent is to track packages which were installed because the user requested them directly separately from packages which were pulled in purely because of dependencies. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tests in %doc?
SK == Stepan Kasal ska...@redhat.com 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: Strange message from Bugzilla
MAS == Michel Alexandre Salim michael.silva...@gmail.com writes: MAS When a review is granted, the mail always says $REVIEWER has MAS granted $REVIEWER's request for fedora-review. Shouldn't the MAS second $REVIEWER be $PACKAGER ? That's just a by-product of the way we abuse bugzilla's flags for the review process. '?' is supposed to indicate the request and '+' the resolution, as with CVS requests. But for reviews we need three states (review not started, review in progress, approval), hence no flag, '?' and '+', respectively. When a flag goes from '?' to '+', bugzilla generates the message you mention. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Emacs packaging guidelines fix for XEmacs
JJ == Jerry James loganje...@gmail.com writes: JJ Would someone who has editing rights to JJ https://fedoraproject.org/wiki/Packaging:Emacs please do a global JJ search and replace: Could we have some explanation of why these changes are needed? Have these directories changed location recently? Are there versions of Fedora where these changes will not apply? What about RHEL/EPEL? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Emacs packaging guidelines fix for XEmacs
Certainly the text not agreeing with the templates is something we need to fix. I've changed four references of xemacs/site-packages to xemacs/site-packages/lisp in two specfile templates. Please double-check that everything is correct. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2009 for Fedora
JN == Jindrich Novy jn...@redhat.com writes: JN These virtual provides, such as tex(tex), tex(latex) or tex(xetex) JN were added at the beginning of the year 2008 so it works at least JN for Fedora 9 and higher. JN We should file bugs for these packages. There are many, many more packages that require tetex-latex at build time. Notably every R package, most likely because of http://fedoraproject.org/wiki/Packaging:R. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2009 for Fedora
JLT == Jason L Tibbitts ti...@math.uh.edu writes: JLT There are many, many more packages that require tetex-latex at JLT build time. Notably every R package, most likely because of JLT http://fedoraproject.org/wiki/Packaging:R. I have adjusted the guideline page to reference tex(latex), but I believe this will cause issues for EPEL as no RHEL version seems to have tex(latex). - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
SG == Steve Grubb sgr...@redhat.com writes: SG It would have been in before feature freeze if sc-audit hadn't SG gotten stuck in package review. A couple of points here, since you seem to be blaming the review process for the lateness of this package: Submitting a new package request and expecting it to be reviewed in under a week is simply not reasonable. Sorry, it just isn't. If reviews are going to be blocked on package reviews, get those reviews in early, not at the last minute. If something important, like a new feature or something disruptive like this is going to be held up by a package review but needs to get done by feature or alpha freeze time, please make an announcement to that effect, or at least indicate that in the review itself. The review in question (https://bugzilla.redhat.com/show_bug.cgi?id=514602) said nothing about this issue. Otherwise the reviewers have no idea that they should prioritize this review. People go on vacation occasionally, or run out of free time. As far as I know, nobody is paid to review packages and we all have other work to do. If an important review gets blocked behind someone who is not responding, let someone know about it. I stole and finished the xz review because it turns out the person doing the review went on vacation and the entire mass rebuild was blocked on us getting xz in. Bottom line: We can get things done when we know about them needing to get done. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
SG == Steve Grubb sgr...@redhat.com writes: SG I was doing the package review and someone else took it from me. You had it assigned to yourself with the fedora-review flag set? Looking at https://bugzilla.redhat.com/show_activity.cgi?id=514602, it seems that it was assigned to you but the flag was not set. I certainly would have asked before taking the review in that case; I can't say why Jochen didn't but you're certainly welcome to ask him. Were I you, I also would have just taken the review back, especially after Jochen failed to reply to the updated package in comment 5. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review
JL == Jussi Lehtola jussileht...@fedoraproject.org writes: JL (I'm not very sure, however, about the current policy of wanting JL sponsors to review first packages. IMHO anyone should be able to JL review them, just as long as a sponsor goes through them and some JL inofficial reviews by the submitter. It's less work for the sponsor JL that way :D) Anyone can review anything, sponsor, sponsored, or not a packager at all. The difference is who can approve a package and sponsor contributors. It is certainly quite reasonable for a non-sponsor to review that package and get it into shape so that a sponsor can come along, double check, and click the various buttons. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review
JL == Jussi Lehtola jussileht...@fedoraproject.org writes: JL That's what I think, too, but JL http://fedoraproject.org/wiki/PackageMaintainers/Join#Get_Sponsored JL thinks otherwise: Actually it just says what I said more succinctly. An informal review can be done by anyone. The actual full review and approval must be done by a sponsor. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 rpm on F11 (rpmlib(PayloadIsXz))
AT == Axel Thimm axel.th...@atrpms.net writes: AT Is there an upgrade-rpm-for-F11 available? In updates-testing. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rawhide mock builds broken
JK == Jesse Keating jkeat...@redhat.com writes: JK Hrm, so I wonder about this. Does exim rely on the group ownership JK at all for anything? Would it make sense to have a general JK 'service' or 'nobody' group that these things could be tossed in if JK the group isn't to be used, to avoid taking dynamic GIDs on the JK host? It just so happens that I actually use Exim (on mail servers, ssmtp on everything else), and it does use group memberships for various things. It also happens that in F-11 it also somehow got GID 93 for itself in addition to the UID 93 that it requests. So useradd must have changed its behavior quite recently. JK Or should we say that if you are going to take a specific UID, you JK need to take the GID to match it? Past behavior of useradd seems to do that automatically (or at least it tried). I don't think it's bad for exim to groupadd 93 first, but honestly I don't know what happens to existing installations that may have a different GID set up and I don't want to break anything. I guess such systems would be running rawhide and this is a bug fix, so - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rawhide mock builds broken
JLT == Jason L Tibbitts ti...@math.uh.edu writes: JLT So useradd must have changed its behavior quite recently. It could be shadow-4.1.4.1-sysacc.patch, I guess, but that was built in rawhide on the 16th of this month and I've done plenty of builds since then. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rawhide mock builds broken
Today I tried to do some rawhide builds in my usual mock setup (running on updated x86_64 F11), but somehow I can't even init a chroot due to: Executing command: ['/usr/sbin/groupadd', '-g', '498', 'mockbuild'] Child returncode was: 4 GID 498 is already occupied by exim, which gets pulled in because cronie depends on /usr/bin/sendmail and exim has the shortest name. (cronie is needed because of crontabs, which is a dependency of rpm.) Exim has no requirement that it get group 498; it only calls useradd so this must just be bad luck. Obviously this didn't always happen; I have no idea what has changed to cause this situation. Anyone have any ideas for getting mock going again? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rawhide mock builds broken
JK == Jesse Keating jkeat...@j2solutions.net writes: JK Mock is trying to add a user / group that matches the user / group JK calling it. Is the user calling it of gid 498? That's the GID of the mock group on the host. It's not my primary GID, but I guess that doesn't matter. It would explain why I'm the only person unlucky enough to run into this. JK I thought there was a bug open asking rpm to split off the cron job JK into its own package (or drop it all together, or put it in a doc as JK an example) so that we could avoid this in the minimal install JK cases. That might help this specific case, I guess, but perhaps there's a more general problem. If mock absolutely requires that it be able to create a group in the chroot with the same GID as the mock group on the host, then perhaps we should reserve a static GID for mock. JK exim may need to adjust it's scriptlets to make use of the proper JK uid/gid. Exim doesn't actually create a GID. It just creates UID 93 and does not call useradd with -g, so an 'exim' group is created with a random GID. As far as I know it's always done this. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/kmess/F-11 kmess.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
TM == Till Maas opensou...@till.name writes: TM Please explain why. The details are in the review ticket; I neglected to check where my message was going before I sent it. But basically, it's not permissible to say your package is a clone of X where X is a trademark. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: openssh-blacklist - careless waste of space.
YK == Yanko Kaneti yan...@declera.com writes: YK Seriously wtf!? Can't answer that. YK And where is the frikken package review for it? https://bugzilla.redhat.com/show_bug.cgi?id=509990 Unfortunately neither the reviewer nor the packager updated the ticket title with the changed name of the package. I've fixed that. I don't see any mention of the size of the package in the review. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Is BuildRoot still mandatory?
BP == Björn Persson bj...@rombobjörn.se writes: BP So my question is: If there are no plans to build a package on any BP distribution release where a BuildRoot tag is needed, and it is BP known that the package won't build cleanly on such a release, is a BP BuildRoot tag still required for the package to be approved for BP Fedora? The packaging guidelines have yet to be changed to indicate any circumstances where a buildroot tag is not required. That may happen in the future, but it has not happened yet. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
d == drago01 drag...@gmail.com writes: d Afaik those are blocking on xz review request rel-eng to coordinate d a mass rebuild The xz review had stalled; notting asked me to step in but somehow it slipped my mind for a day. I just went ahead and took it over; there are a couple of things to look at but it should all be wrapped up tomorrow if notting's around. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: epel-release in Fedora repos?
JK == Jesse Keating jkeat...@redhat.com writes: JK At 7000+ srpms there is no way I could evaluate each and every one JK for validity before submitting it for a rebuild. I think the point is that the package owner should have deleted it from devel so that there would be nothing for rel-eng to rebuild. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: epel-release in Fedora repos?
TM == Till Maas opensou...@till.name writes: TM Imho if the devel branch is a problem, then it should not be TM created when the package is imported to CVS, if it is a epel-only TM package. The devel branch is mandatory, but that doesn't mean that the package owner has to import anything there if they don't need it. Honestly, though, packages that will be in EPEL but not in Fedora at all are very rare exceptions and retooling the infrastructure to handle them specially would be something of a waste of effort. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass-Package Orphanage
NDN == Nathanael D Noblet nathan...@gnat.ca writes: NDN I'm wondering if it is possible to be a co-maintainer with NDN someone willing? In general, all you need is a sponsor. The usual route to that is via the submission of new packages, but it's not the only way. I happen to be a sponsor, so that's not an issue. What is an issue is that fact that the horde suite is somewhat delicate and security sensitive, and not really the best set of packages for a first-time packager. This is somewhat offset by the fact that the packages already exist and just need maintenance. I think that if you're interested, you should start by requesting watchcommits and watchbugzilla on at least the Fedora branches of those packages. (I have no desire to maintain the EPEL5 branch, so someone else needs to step in to take care of that one.) The URLs are: https://admin.fedoraproject.org/pkgdb/packages/name/horde https://admin.fedoraproject.org/pkgdb/packages/name/imp https://admin.fedoraproject.org/pkgdb/packages/name/ingo https://admin.fedoraproject.org/pkgdb/packages/name/jeta https://admin.fedoraproject.org/pkgdb/packages/name/kronolith https://admin.fedoraproject.org/pkgdb/packages/name/turba Later we can progress to sponsorship and commit access. I still hope we can find at least one other person to assist in maintaining these packages. Otherwise I fear I will just end up orphaning them again. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass-Package Orphanage
DS == Dodji Seketeli do...@redhat.com writes: DS Interesting. I thought people were obliged to submit _new_ DS packages to request sponsorship, Any user can request sponsorship without doing anything. That doesn't mean they're going to get it, of course. It is the sponsor's responsibility to monitor and mentor the person they've sponsored, and they make the decision about who they wish to sponsor. (And here I'm talking about the packager group only, not any other group which also has sponsors and which may have their own rules.) It is true that one significant path to this is the submission of new packages. I don't think you'll find it anywhere documented that the only possible path is the submission of new packages. DS Out of curiosity, could you point me to a reference documentation DS that explains the process to sponsor a co-maintainer who is not a DS fedora packager already ? If you're a sponsor, you just go to the account system and sponsor them (assuming they've already applied, of course). The procedure isn't any different than any other situation where someone is sponsored into a group. DS The only link I was aware of was this one: DS http://fedoraproject.org/wiki/PackageMaintainers/Join#Make_a_Package, DS where it's stated: You should make sure that it is a new DS package. That's the document on submitting new packages, yes. As such, you can expect that it talks about submitting new packages. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
MC == Matej Cepl mc...@redhat.com writes: MC So, how should I propose to FESCO exclusion of DiveIntoPython MC (BTW, wonderful book), Jules Verne and anything else we find? Open a ticket on their trac (https://fedorahosted.org/fesco/). The issue here is that the guidelines explicitly permit documentation and help files; diveintopython is obviously documenting Python, and if it was bundled with the Python tarball then there wouldn't be any question at all about this. So I'm not really sure that the place where you draw the line is all that clear. At least the python package itself includes some reasonable documentation about the language. But the package that spawned this duscussion, the device drivers book, actually documents the kernel where the kernel doesn't really document itself. And there are other reviews for this kind of thing pending: javanotes, for example (https://bugzilla.redhat.com//show_bug.cgi?id=507916) covers Java for which we have little in-distro documentation, and there's at least one other package submitted by the same person. Make sure that the line you draw is clear with regards those packages as well. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
MC == Matej Cepl mc...@redhat.com writes: MC Well, I always understood, that documentation which is part of MC normal package is OK, but source package which contains nothing MC else than documentation isn't. If that was the case, then I see 17 -docs packages that build completely separately from any other package. Some upstreams package their documentation in separate tarballs, and so these can be built from separate source packages. (And often this makes sense, as the documentation package doesn't have to change when a bug is fixed in the main package.) So you could have a rule that says the package has to directly document some program in the distro, but then the Linux device drivers book does just that. I don't think anyone would reasonably want to exclude the python-docs package (built as a separate source package containing nothing other than documentation) but I know I can't articulate just how diveintopython is different. Honestly I think this would be easier if we had a separate content repository, because then the decision wouldn't be about excluding some things completely but instead about which repository to put them in. I recall some discussion about that but I don't know what the end result was. Honestly I don't care either way except that I need to know what to do with this javanotes review ticket I've taken; I'd just like to be able to point people to a clear decision. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora LaTeX SIG?
JL == Jussi Lehtola jussileht...@fedoraproject.org writes: JL On 06/02/2009 07:27 AM, Jindrich Novy wrote: New version texlive-2008 (to be in f12): one single texlive package generating 3944 subpackages / 1065 MiB JL Oh. My. God. Please read the whole thread; that was the initial proposal, not the final one. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora LaTeX SIG?
NM == Nicolas Mailhot nicolas.mail...@laposte.net writes: NM I didn't see this before but I can only agree with the replies: NM this is an insane plan. Nobody is ever going to review properly a NM 2.7 MiB spec file, updating will be hell, etc. Isn't it nice, then that the final plan is different from the initially proposed one? I see that you read the thread, so why bother commenting on something that's not currently being proposed? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
MB == Mathieu Bridon (bochecha) boche...@fedoraproject.org writes: MB After each item in the review guidelines, add a [more] link that MB points to the relevant section in the packaging guidelines ? Do you realize that the document already has footnotes doing exactly that? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
J == Jason L Tibbitts ti...@math.uh.edu writes: J The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC J in the #fedora-meeting channel on chat.freenode.net. Due to lack of quorum, this meeting is postponed to Tuesday, 2009-06-02. I will send an updated agenda as the meeting approaches. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
TC == Tom \spot\ Callaway tcall...@redhat.com writes: TC Is anyone opposed to that? It's hard to oppose anything that frees us from carrying around all of this useless crap in every specfile. If we ever want our packaging to be considered sane, we have to make progress towards getting rid of stuff we don't really need and dumping the inexplicable random stuff that just gets included verbatim in every specfile without most folks understanding why it's there. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Agenda for the 2009-05-26 Packaging Committee meeting
The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 Users who wish to bring proposals before the committee are encouraged to read https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure Anyone is welcome to create drafts under https://fedoraproject.org/wiki/PackagingDrafts and to update https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo; such updates will automatically appear on our agenda. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-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
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
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: 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: 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
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: 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
Kernel for SMP VIA C3 machines
I have a couple of VT310-DP boards (together in a little 1U case, nice) and found that FC-5 won't do SMP on them. (The i686 kernels won't run on this chip.) What's the cleanest way to add an i586-smp (or better yet, MVIAC3_2-smp) build target to the existing kernel SRPM? Currently I'm working from Fedora CVS (FC-5 branch) which looks like it has reorganized the config generation a bit. - J
