July 2008 - package-review - Fedora Mailing-Lists

[Bug 439340] New: Review Request: mediawiki-OpenID - An extension for OpenID integration

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=439340 Summary: Review Request: mediawiki-OpenID - An extension for OpenID integration Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: ianweller(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com Spec URL: http://ianweller.fedorapeople.org/SRPMS/mediawiki-OpenID/0.8.2-1/mediawik... SRPM URL: http://ianweller.fedorapeople.org/SRPMS/mediawiki-OpenID/0.8.2-1/mediawik... Description: The OpenID extension for mediawiki. Depends on php-openid which is still in review, bug 439285. Requested by Infrastructure. -- 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, or are watching someone who is.

15 years, 10 months

1
4
0 / 0

[Bug 439285] New: Review Request: php-openid - The PHP OpenID Library

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=439285 Summary: Review Request: php-openid - The PHP OpenID Library Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: ianweller(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com Request from Infrastructure team. Spec URL: http://ianweller.fedorapeople.org/SRPMS/php-openid/2.0.1-1/php-openid.spec SRPM URL: http://ianweller.fedorapeople.org/SRPMS/php-openid/2.0.1-1/php-openid-2.0... Description: The PHP OpenID library lets you enable OpenID authentication on sites built using PHP. It features the OpenID consumer, Store implementations, and an OpenID server. Features of the 2.x.x series include: * Runs on a wide range of PHP versions: from 4.3.0 and up (tested on 5.2.4) * Licensed under the Apache Software License. * Includes extensive documentation, working example code, and a test suite * Attempts to use PHP extensions such as Curl, but does not depend on them * Includes extension modules for Attribute Exchange, Simple Registration, and PAPE * Supports i-names * Tested on Windows and Linux * Versions 2.x.x support both major OpenID protocol versions transparently -- 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, or are watching someone who is.

15 years, 10 months

1
6
0 / 0

[Bug 188542] Review Request: hylafax

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: hylafax https://bugzilla.redhat.com/show_bug.cgi?id=188542 ------- Additional Comments From faxguy(a)howardsilvan.com 2008-07-04 20:49 EST ------- (In reply to comment #88) I've made a change to %{_libdir}/libfax* (In reply to comment #89) This is a bug in the ghostscript package and not HylaFAX. HylaFAX is extracting the path from the 'gs -h' output. HylaFAX's faxsetup will compensate for this ghostscript bug later during setup and configuration. (In reply to comment #90) I've followed your fedora-devel discussion here: http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=57663&forum=... There seems to be a resounding consensus with respect to the FHS matter and a very undecided response to the naming matter. Please allow me to restate my positions on these. My positions are entirely based upon anticipation of user expectations, minimizing support cases, and making everything as intuitive as possible. In fact, these concerns are the only reason for my creating this review request in the first place: if there were a hylafax package in Fedora already I wouldn't have bothered - there would have been no reason for this effort. As HylaFAX is approaching it's 20th birthday and is almost certainly the most-popular open-source fax application for UNIXes, it's silly that Fedora does not have a hylafax package. RedHat 5.2 *did* have hylafax-4.0pl2 (that's the SGI flavor, not from hylafax.org). RedHat apparently decided to drop the hylafax package due to conflicts with the mgetty-sendfax package. (That is interesting because the mgetty author created the conflict... as his approach at the time was to write his own fax software instead of participate with HylaFAX development. And, in particular, he chose to use "sendfax" for one of the commands... and thus created the conflict. One could argue, and I would agree, that "sendfax" is generic enough to be the presumptive way to send a fax with a command. Nevertheless, this seems to be the reason why hylafax was tossed from RedHat 6.0.) Again, I'm okay with calling the package hylafax+ instead of hylafax. I think that would be a mistake, though. And I think having a "hylafax.org" and a "hylafax+" but no "hylafax" (cutting the baby in half) would be an even worse mistake. Why? Because all HylaFAX users, whether they use SGI's flavor, hylafax.org's flavor, iFax's flavor, or HylaFAX+ flavor... they all call that software "HylaFAX". And they're all right, too. If hylafax.org really wanted to submit a package request and maintain it, then I would wholeheartedly acquiesce and say to put that in as a "hylafax" package into Fedora. I would never use it, myself, of course... but my whole reason for creating this package review request in the first place has always been to see a HylaFAX package in Fedora for other users. You don't see me trying to bully-in a hylafax+ package into Debian/Ubuntu for exactly this reason. Both HylaFAXes at hylafax.org and Sourceforge (HylaFAX+) are so similar that it's really inaccurate to describe their differences as a fork. I don't think there's an accurate label, but a certain well-known open-source philosopher once called it a "pseudo-fork" when I brought up this concept to him. He said that this case is very similar to what happens when a distribution packager adds a few patches here and there to suit the distribution schema or to address bugs or even enhancements that appealed to the packager. He indicated that use and functionality were the criterion by which a fork was to be defined... and not so much on code specifics. In other words, we could create a software package called "hello_world" that was coded in shell this way: echo "Hello world!" And then someone came along and rewrote hello_world in this way: printf "Hello world!\n" Are they forks? Maybe there is a reason to prefer one over the other, but they're functionally the same, and there's absolutely no sane reason to try have both of them. Pick one or the other. If a time comes that one is preferred over the other, then simply change, and keep on calling it hello_world. I realize that's an over-simplified example, but I'm trying to illustrate my perspective here... and what I believe is the general user perspective. Users are going to want to do: 'yum install hylafax'. For users who already know that HylaFAX on Fedora is called "hylafax+" or "hylafax.org" then doing 'yum install hylafax+' may be beneficial, but it will create a support matter and a point of confusion for every first-time installer. There seems to be some suspicion on your part, Jason, that I have some nefarious intention "in (what seems to [you] to be) an attempt to gain legitimacy". I think that you've entirely misunderstood what I've done. I coded at hylafax.org for several years. There was an occasional flare-up with respect to opinions on aesthetics of the coding being committed to the repository, and an occasional flare-up with respect to design approaches, but as ugly as those sometimes got the code changes were almost always followed, and they weren't the reason why I moved my coding to Sourceforge. In fact, I set up the Sourceforge site as a download location for HylaFAX... specifically pre-release versions of HylaFAX. You see, I always had been frustrated with the slow release schedule at hylafax.org. Users were regularly and frequently (multiple times per week) requesting that I send them pre-release tarballs or pre-release RPMs. It became very frustrating to answer mailing-list questions over and over again for weeks and months about bugs that were "fixed in the next release". So I finally made the decision to just set up a site where users could just download those pre-releases for themselves. The end-result of this action was a complete rejection by other hylafax.org developers (all of whom were/are employed by iFax). They insisted that references inside of the tarball (code, manpages, and text files) should have no reference to hylafax.org or "The HylaFAX Development Team". The only way that I could sanely accommodate that was to set up a separate code repository. Then I embarked upon a number of months where I was trying to maintain two code repositories (and that never works: it's a real pain, as it had been when those same hylafax.org developers asked me to code in a 4.2 CVS branch while expecting me to also maintain the old 4.1 branch that eventually did nothing for open-source HylaFAX users and never had another release). So basically what happened was that iFax made it increasingly impossible for the largest code contributor, me, to continue to operate at hylafax.org. And, yet, they were as eager as always to absorb the developments I would make at the Sourceforge site. So we now have a situation, then, where there are two versions of HylaFAX that are basically following the same development path... one behind the other. There are some differences, but they're nominal for most users, and functionality and use are identical (the differences follow the hello_world example quite literally although not as simplistically). The HylaFAX+ name came about because some users were quite emphatic that they needed some distintion between "the Souceforge HylaFAX development project" and hylafax.org. In retrospect, I now tend to believe that those clamors were coming from hylafax.org enthusiasts whose intentions were really to strip legitimacy from my efforts. I hope that clarifies my intentions. If they continue to seem nefarious to you, then I sincerely apologize. I truly believe that my actions and intentions have always been done in good faith and with the users' interests in mind. So, again, I'm happy to change the name of the package to "hylafax+" if that's what's really the hold-up here. I disagree with it, but I'm willing to do it if, indeed, that's the hold-up. Unfortunately, I don't think that using "Provides: hylafax" helps any. In an 'rpm -Uvh' procedure (upgrade) this still happens (in extreme multiplicity): file /var/spool/hylafax/etc/dialrules from install of hylafax+-5.2.5-1.fc8.i386 conflicts with file from package hylafax-5.2.0-1.fc8.i386 Maybe someone better with spec files can tell me what I didn't do right. But this kind of thing is *exactly* what must be avoided. Users need to be able to transition between hylafax.org and HylaFAX+ (and Fedora) RPMs without these kinds of headaches. And as for the FHS matter... I hope that you can understand that I cannot change how the upstream package is installed or works in such a dramatic way as it would be to move "bin", "etc", and "config" elsewhere. The resulting support issues would simply be too great. Now, we may be able to get away with symlinking as the fedora-devel tread suggests, but it would be something that would be unique to the Fedora package... unless it were so interchangeable that it would work for all other platforms (e.g. Mac OS, Solaris, BSD, AIX, IRIX, SCO, etc.) too. And even then, I would be reluctant to do it. You see, having it all right there allows the hfaxd client (much like an ftp client) in an administrative mode to get in to the configuration files in those directories (yes, "bin" contains executable scripts which are largely considered configurable) and make adjustments that way. So it could be quite useful to have all of those things there. Certainly it's much more convenient to have them there. Thus, it is my perspective that those directories do very much belong under "var", and there really is no more-appropriate place to put them other than "spool"... in my estimation. Maybe that concept is stretching it a bit - nobody probably uses bin, etc, and config files in that way. But it's a design feature that I don't feel necessarily warrants change. However, if this is the only thing holding up getting this package into Fedora, and if we can make adjustments that prove to be transparent to the end-users, then I can work with that (I'll need some detailed explanations of what to do) in a Fedora-specific way as I've stated above. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

15 years, 10 months

1
0
0 / 0

[Bug 401101] New: Review Request: sleuthkit - The Sleuth Kit (TSK)

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=401101 Summary: Review Request: sleuthkit - The Sleuth Kit (TSK) Product: Fedora Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: kwizart(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com Spec URL: http://kwizart.fedorapeople.org/SPEC/sleuthkit.spec SRPM URL: http://kwizart.fedorapeople.org/SRPMS/sleuthkit-2.09-1.fc7.kwizart.src.rpm Description: The Sleuth Kit (TSK) This package could be part of : http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD As such it might be desirable to have it build statically (which is the case for now) or with dietlibc. I'm also working on a shared built (for libewf afflib) but this is not done yet... Advices welcome... A Previous request: https://bugzilla.redhat.com/204228 (closed) There is a need to block FE-LEGAL about the compatibility between license (BSD with advertising and CPL/IBM) and eventually the NTFS case (I think this last should not give problems since we have ntfs-3g in userspace) -- 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, or are watching someone who is.

15 years, 10 months

1
28
0 / 0

[Bug 453567] New: Review Request: libfonts - Java TrueType Font Layouting

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=453567 Summary: Review Request: libfonts - Java TrueType Font Layouting Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: caolanm(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com Spec URL: http://people.redhat.com/caolanm/jfreereport/libfonts.spec SRPM URL: http://people.redhat.com/caolanm/jfreereport/libfonts-0.3.4-1.fc9.src.rpm Description: Java TrueType Font Layouting libfonts is a dependency of jfreereport which is a dependency of OpenOffice.org3's report generating functionality -- 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, or are watching someone who is.

15 years, 10 months

1
6
0 / 0

[Bug 452516] New: Review Request: perl-AnyEvent - Framework for multiple event loops

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=452516 Summary: Review Request: perl-AnyEvent - Framework for multiple event loops Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: kwizart(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com Spec URL: http://kwizart.fedorapeople.org/SPECS/perl-AnyEvent.spec SRPM URL: http://kwizart.fedorapeople.org/SRPMS/perl-AnyEvent-4.152-1.fc8.kwizart.s... Description: Framework for multiple event loops http://koji.fedoraproject.org/koji/taskinfo?taskID=676522 This package filter the perl-Qt event module as it will need some special care, but is unmaintained until now. -- 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, or are watching someone who is.

15 years, 10 months

1
8
0 / 0

[Bug 453287] New: Review Request: perl-Term-ReadLine-Gnu - Perl extension for the GNU Readline/History Library

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=453287 Summary: Review Request: perl-Term-ReadLine-Gnu - Perl extension for the GNU Readline/History Library Product: Fedora Version: rawhide Platform: All URL: http://netbsd.sk/~lkundrak/SPECS/perl-Term-ReadLine- Gnu.spec OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: lkundrak(a)v3.sk QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com SPEC: http://netbsd.sk/~lkundrak/SPECS/perl-Term-ReadLine-Gnu.spec SRPM: http://netbsd.sk/~lkundrak/SRPMS/perl-Term-ReadLine-Gnu-1.17a-2.el5.src.rpm Description: An implementation of Term::ReadLine using the GNU Readline/History Library. -- 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, or are watching someone who is.

15 years, 10 months

1
10
0 / 0

[Bug 454006] New: Review-Request: s3cmd - Tool for accessing Amazon Simple Storage Service

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=454006 Summary: Review-Request: s3cmd - Tool for accessing Amazon Simple Storage Service Product: Fedora Version: 9 Platform: All URL: http://netbsd.sk/~lkundrak/SPECS/s3cmd.spec OS/Version: Linux Status: NEW Severity: low Priority: low Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: lkundrak(a)v3.sk QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com SPEC: http://netbsd.sk/~lkundrak/SPECS/s3cmd.spec SRPM: http://netbsd.sk/~lkundrak/SRPMS/s3cmd-0.9.8.1-1.el5.src.rpm Description: S3cmd lets you copy files from/to Amazon S3 (Simple Storage Service) using a simple to use command line client. -- 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, or are watching someone who is.

15 years, 10 months

1
8
0 / 0

[Bug 218581] Review Request: mediawiki-openid - The OpenID extension for MediaWiki

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: mediawiki-openid - The OpenID extension for MediaWiki https://bugzilla.redhat.com/show_bug.cgi?id=218581 axel.thimm(a)atrpms.net changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn|227191 | ------- Additional Comments From axel.thimm(a)atrpms.net 2008-07-04 17:04 EST ------- One of the dependencies is no dependency anymore in recent versions, so I'm dropping the block. It's now actually only one package to be reviewed and it's through, and the review comments look encouraging (nothing major). As to F7 builds: There will only be an oldest-Fedora-build as this package is trans-distro identical. koji has some magic to inherit this to all later releases automatically. Which means that once the dependencies are in, one will either stil find the F7 build and use that, or have an F8 build for F8/F9/devel. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

15 years, 10 months

1
0
0 / 0

[Bug 431386] New: Review Request: rkhunter - A host-based tool to scan for rootkits, backdoors and local exploits

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/show_bug.cgi?id=431386 Summary: Review Request: rkhunter - A host-based tool to scan for rootkits, backdoors and local exploits Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: kevin(a)tummy.com QAContact: extras-qa(a)fedoraproject.org CC: fedora-package-review@redhat.com,notting(a)redhat.com Spec URL: http://www.scrye.com/~kevin/fedora/rkhunter/rkhunter.spec SRPM URL: http://www.scrye.com/~kevin/fedora/rkhunter/rkhunter-1.3.0-1.fc9.src.rpm Description: Rootkit Hunter (RKH) is an easy-to-use tool which checks computers running UNIX (clones) for the presence of rootkits and other unwanted tools. This is a re-review of this package, as it's been orphaned for quite some time, and I wish to revive it. I have simplified the old spec a great deal and updated it to the latest version. This version does not ship the perl scripts for sha1/md5 summing, instead using installed executables, or nothing if they are not installed. Happy to take input on how better to handle this. There is also a (rather large) diff against the last spec in cvs at: http://www.scrye.com/~kevin/fedora/rkhunter/old-spec.diff -- 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, or are watching someone who is.

15 years, 10 months

1
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

package-review July 2008