[Bug 188542] Review Request: hylafax

Tue Nov 20 22:33:59 UTC 2007

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 at howardsilvan.com  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.