I have begun a wiki page with something that looks like guidelines, but
that are opened for everyone, and allow to have controversial
It would be nice if reviewers, especially those with a lot of
experience who have said more than once something in reviews, to
document their knowledge. Also I think that controversial packaging
issues that result in long threads on mailing lists could be
One of the oldest review tickets still open is
https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server
hylafax. Earlier this month I picked this up an attempt to try and
shepherd it through the process, but I'm stuck on a couple of issues
and the submitter does not seem to be willing to address them
satisfactorily. Maybe I should just say "hell no" and drop the
review, but I guess my objections could be wrong so I figured I'd try
to start some discussion.
Issue one is the name: There are multiple pieces of software claiming
to be hylafax. There's the software at hylafax.org, and then there's
the package at hylafax.sourceforge.net, where it is called
"hylafax+". I quote:
The "+" means that it is better.
There's also an "enterprise" version from ifax.com. The second
version, which upstream calls itself "hylafax+" is the one being
submitted, but the submitter argues against using that name (see
However, my suggestion would follow what I've said above about the
Apache http server. The distinction of the "+" will mean very
little to Fedora users (and in-fact may make the package
more-difficult to identify) unless there is more than one HylaFAX
package being distributed by Fedora (say, for example, separate
"hylafax+" and "hylafax.org" packages).
Anyone else agree with that reasoning? What about using
until the hylafax.org package makes it into the distro (assuming
someone actually wants to submit it)?
The second issue is an FHS violation: several directories are
installed under /var/spool which contain things that aren't really in
the spirit of /var/spool. There's a /var/spool/hylafax/bin directory
which, you guessed it, contains executables, a
/var/spool/hylafax/config directory containing config files, and
/var/spool/hylafax/etc containing other, different config files.
Here's what the submitter has to say (see comment 83):
While the vast majority of HylaFAX binaries and their respective
configuration files are installed outside of /var/spool/hylafax,
those three directories (etc, bin, and config) are configuration
files and configuration utility scripts, etc., that control how the
spools are handled.
Due to the way that HylaFAX daemons operate it would be extremely
cumbersome (if not impossible - as in the case of a chroot) for
these to be elsewhere. They're very much like the configuration
files that LPRng had under /var/spool/lpd.
So, that's my argument. I hope that it's acceptable. But if it's
not... unfortunately there's not much that I am willing to do about
Now, lprng isn't in the distro and I really don't think it would have
passed review like that, so I can't buy that as an argument.
"cumbersome", well, too bad I guess. I'm not sure about a chroot. I
mean, just fix the code to look elsewhere. How hard could it be?
But even if, it's too hard to fix, what about a few symlinks? (To
somewhere under /usr/libexec for the bin stuff, and somewhere under
/etc for for config and etc directories.) Do three symlinks violate
the FHS significantly enough to cause issues? My understanding is
that this should be OK with chroots (as long as the links are
relative.) And how does all of this square with selinux?
I'd be appreciative of any suggestions.
automake / autoconf newbie here. I have a package that isn't currently
being built with _GNU_SOURCE defined and is running into compile
problems when a portion of it attempts to access hostent->h_addr.
If I compile with -D_GNU_SOURCE all is well, but I want to get this
fixed correctly upstream. What is the proper / preferred way to do
this? I see a couple options:
- Get it added to acinclude.m4 and it will show up somewhere in a
- Modify configure.ac (or other) to generage a configure.in that
tacks it onto DEFS which shows up then as DEFS in configure and
populates DEFS in the resultant Makefile so we have -D_GNU_SOURCE
passed to the compiler
What other ways are there to do this and what's the preferred way?
I'll answer my own question if I find the answer in the automake /
autoconf docs. :)
I got the following mail from Fedora updates. It says "The following
package has been moved to stable from testing". The Karma value
corresponding to this package is still zero (mentioned in the below
thread). Correct me if i am wrong, if the value reaches 3 its moved to
stable, thats how i understood it. I gave a comment for that package
that i am not able to test it because i was not aware what needs to be
tested for that enhancement.
Apart from this i ve an other problem. Suggestions and Comments
Welcome for this problem :) .
I browse through the Fedora Updates repository to start testing
packages which are under the fedora testing branch, but for some of
the packages, i see that its given as an enhancement (like the below
one) but i am not able to go ahead testing it because it does not
specifiy whats the enhnacement is about. I did notice that there are
some bug fixes too made which has got the word "bugfix" but does not
map to a Bug ID i.e, the Bug ID is not mentioned in the updates. It
becomes diffficult to test those packages and give appropriate and
correct feedback.I shouldnt give back a report saying that it works or
it does not work which might be a wrong test result because i might be
testing something but the fix would be for something else.
I would really appreciate if you all could help me with a suggestion
on this. I went a step ahead by raising a ticket in the bodhi system
so that we could have a field in the updates system where in when a
packager uploads the packages, a mandatory field on whats fixed if its
a bug fix could be stated and if its an enhanement , a small note on
what the enhancement is. Will this suggestion work ?
This would really help people testing packages from the bodhi
repository and thereby make Fedora a real rock solid distro.
Thanks for reading this . Hope people don't mistake me for this :)
On 5/29/08, updates(a)fedoraproject.org <updates(a)fedoraproject.org> wrote:
> The following comment has been added to the gedit-2.22.1-1.fc9 update:
> balajig8 - 2008-05-25 14:44:49 (karma: 0)
> It would be really helpful if you could let me know what the enhancement is so that i could test it and let you know the result. I would also really appreciate if the bugID( in this case the enhancement ID) could also be given so that i could test it specifically
> To reply to this comment, please visit the URL at the bottom of this mail
> Update ID: FEDORA-2008-3797
> Release: Fedora 9
> Status: stable
> Type: enhancement
> Karma: 0
> Submitter: hadess
> Submitted: 2008-04-30 10:57:01
> Comments: bodhi - 2008-05-29 02:43:33 (karma 0)
> This update has been pushed to stable
> bodhi - 2008-05-13 15:29:10 (karma 0)
> This update has been pushed to testing
> balajig8 - 2008-05-25 14:44:49 (karma 0)
> Hi It would be really helpful if you could let me
> know what the enhancement is so that i could test it
> and let you know the result. I would also really
> appreciate if the bugID( in this case the enhancement
> ID) could also be given so that i could test it
> specifically Cheers Balaji