[Bug 510734] Review Request: x11vnc - VNC server for the current X11 session

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=510734





--- Comment #63 from Pavel Alexeev (aka Pahan-Hubbitus) <pahan at hubbitus.info>  2009-09-03 06:38:13 EDT ---
Sorry for delay. As rebuild is requirement to ensure of all binaries born from
longtime sources, I done this. And now, I think it good idea also include it. I
pack it in subpackage.

(In reply to comment #56)
> Yes, I've also read this thread. However, it is for sure not wrong to use a
> standard tab width. And you would do nearly all other packagers the favor that
> they could easily read your spec file with a proper formatting.
As you can read no single "all other packagers thing" about it question.

> The alternative would be to use just spaces. This would work for everyone and
> since there is usually not that many changes in a spec file, it should not have
> that much overhead. Would you agree on this solution?
No. Spaces off course always was second solution there, but (IMHO off course)
add only mesh. The main reason of it - easy distinguish leaved space in
formatting.

But, you may wish do it. I think you favorite editor can do it. If not, I wrote
little script for that on PHP:
http://hubbitus.net.ru/rpm/Fedora11/x11vnc/tab-convert.phps

Yo may use it like:
$ cat x11vnc.spec | ./tab-convert.php > x11vnc.spec.spaces

Or, with power of UNIX-WAY, off course directly in shell f.e:
$ cat x11vnc.spec | php -r 'define("TAB_WIDTH", 5);foreach(file("php://stdin")
as $l){preg_match_all("/\t+/", $l, $m, PREG_OFFSET_CAPTURE);foreach($m[0] as
$mm){$l = str_replace($mm[0],str_repeat(" ", (TAB_WIDTH - ($mm[1] % TAB_WIDTH))
+ (  TAB_WIDTH * ( strlen($mm[0]) - 1 )  )), $l);}echo $l;}' >
x11vnc.spec.spaces

> I think basic indentation is a well-accepted coding standard for nearly all
> languages. Especially the inner blocks of constructs like "if () then ... else
> ..." or "for" loops should be indented one step more than the surrounding code.
May be you will surprised, but even in one language different projects has own
"coding standards".

> Here are the missing minor pieces:
> 
> 1. tab width: it would really be nice if you could use either a tab width of 8
> or just convert the spec file to spaces
I provide script and command before - with it you can easy convert tabs to
spaces if you wish see it.

> 2. According to Tom it is not necessary to re-package the tarball. However, he
> suggests that the pre-built binaries are deleted in the %prep section. My
> suggestion:
> - add "find -name '*.jar' -exec rm {} \;" to the end of the %prep section
> - add the attached patch to prevent that "make" will enter the "classes"
> directory
I add string to remove all prebuilt jars and built it again. So, I think there
no more to discuss.

> 3. Please make sure that the comments in the spec file and the %changelog
> entries don't exceed 80 chars per line. Sure, that's also not strictly required
> but nearly all spec files do it this way. ;-)  
As I remember rpmlint fire warning at one time if string exceeded 79 characters
in description. But our days it is not (I especially check).
And additionally I have for example Source0 string which is greater. So, it is
not impossible in common case.

Meantime I truncate some very long lines especially for you.


http://hubbitus.net.ru/rpm/Fedora11/x11vnc/x11vnc-0.9.8-11.fc11.src.rpm

-- 
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.