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@xxxxxxxxxxxxxxxx 2007-11-20 17:33 EST ------- (In reply to comment #62) > But build is failing on F-8 x86_64: > > ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied > make[1]: *** [installDSO] Error 1 > So you need to removes the ldconfig call from the makefile I can remove the ldconfig, but for the source installation it is needed, and I have seen other packages run ldconfig from their makefiles. Furthermore, I just did an 'rpmbuild --rebuild hylafax-5.1.11-1.src.rpm' on a Fedora 8 x86 system and it turned out just fine: Wrote: /usr/src/redhat/RPMS/x86_64/hylafax-5.1.11-1.fc8.x86_64.rpm > There is also two program founds: > WARNING, /usr/lib/sendmail does not seem to be an executable program; > WARNING, /sbin/mgetty does not seem to be an executable program; > I don't knwo if it will change to have them at build instead of runtime.... These should be fine this way... however, with the --rebuild that I just did I got: [16] Location of sendmail program: /usr/sbin/sendmail > About JBIG-in-TIFF conversion support not found. > I wonder if this is expected.. > 7068 Segmentation fault $TIFFBIN/tiffcp -c g4 misc/jbig.tif misc/foo.tif > > /dev/null 2>&1 This is somewhat expected to happen. I could hide the error more carefully, but the test is appropriate. We have to test to see if libtiff was built with JBIG support or not. And in this case it was not built with JBIG support and thus is causing the segfault. > You can prevent timestamp changes by adding make install CPPROG="cp -p" \ Understood. I'm not sure that this concerns me very much, unless it does concern you. (In reply to comment #63) > Howard, I suggest you focus on this review instead of opening another one at > rpmfusion. You will run into the same problems there as you are doing here. I feel that I have been focused on this review. I do not understand why progress has not been occurring. I had hoped that at rpmfusion this process would be more attentively supported. I am happy to see this at Fedora or at rpmfusion... I just would like to see it *somewhere*. If I am not doing something that is needed to get this package included then please tell me what is lacking. > Biggest of all is the naming issue. Well, I had thought that we resolved the problem by simply calling this package hylafax+. But, from reading this (lengthy) thread... > https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00308.html ... it seems that there is a bigger problem with provides and conflicts, and it's really not so much to do with naming as it has to do with those. On a theoretical level you could potentially see this same issue come up on many levels in the future. RedHat/Fedora have already had to deal with similar situations before (conflicts), and it's been done in different ways... alternatives, version-numbering, renaming, etc. As for whether or not one or none of those are appropriate in this case is what is at debate, I suppose. I don't really want to get into a big ruckus over this matter, but let me try to explain (again) why I believe that all of that really should not be a factor in this package submission's case... Basically, back in 2005 I took my direct HylaFAX development away from hylafax.org and continued it at Sourceforge due to issues that are publicly discussed elsewhere and are not particularly relevant here. From my perspective I was doing HylaFAX development, and if the hylafax.org wanted my development work they were free to "port" it to their code tree, and I have been very vigilant about porting any developments at the hylafax.org repository into my code tree (certainly I have omitted a few things by deliberate choice). Basically, as I saw/see it, it's not much different than two branches of a CVS codebase. Sure, there are some (perhaps only minor) differences, but it's really not enough to say that they're different things altogether. Let's say that package foo decided to split their CVS repository into a "maintenance" branch and a "development" branch... but for whatever (probaby even silly) reason some people preferred the develoment branch and some people preferred the maintenance branch. If that were to happen would there be some debate at Fedora over which branch of the codebase to use? No, there wouldn't be. The package maintainer would call the shots as far as Fedora is concerned. If the package maintainer chose to stay with the maintenance branch then Fedora would so stay... at least until the maintainer was convinced otherwise. If the package maintainer chose to move to the development branch, then that's what would happen. Many other distributions already have HylaFAX in their package offerings. Some of the package maintainers are using HylaFAX+ code base and some are using hylafax.org code base. And it wasn't that long ago that some were even using SGI code base. Some distributions are offering both packages (usually by different maintainers), some offer only one. My point being that this issue is a silly one that is unnecessarily proving to be a road block. Call it hylafax+ or call it hylafax... there is still neither package in Fedora (and Darren/Paul/Arlington apparently has yet to even start up the reveiew request for his, despite his interjections)... and thus there is no reason to worry about conflicts now. All of that said... step back a bit and observe things from a distanced perspective. HylaFAX+ usually proves to be the upstream for hylafax.org. And, when code work is done at hylafax.org then it serves as the upstream for HylaFAX+. There are a few nuances between them that apparently are permanent, but for the most part the two are similar enough (or will be similar enough) that they're more of a "pseudo-fork" (like CVS branches) than they are true forks. Are these nuances enough to warrant two packages in Fedora? If they are, then that is fine... however, right now there is neither. > Then we still have no debug information (why?) I don't know. I don't even know what debug information is *supposed* to be there. I'm not even sure why it's important or why it's a problem to not have it there. > unused-direct-shlib-dependency, some undefined non weak symbols and the problems I'm fairly sure those things were resolved between then and now. Please refer to the 5.1.11 SPEC and SRPM: SPEC: http://osdn.dl.sourceforge.net/sourceforge/hylafax/hylafax.spec SRPM: http://osdn.dl.sourceforge.net/sourceforge/hylafax/hylafax-5.1.11-1.src.rpm -- 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review