Bug 521909 (ne7ssh) - Review Request: ne7ssh - SSH Library is a Secure Shell client software written in C++
Summary: Review Request: ne7ssh - SSH Library is a Secure Shell client software writte...
Keywords:
Status: CLOSED ERRATA
Alias: ne7ssh
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ruediger Landmann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-08 16:48 UTC by Pavel Alexeev
Modified: 2011-02-23 21:50 UTC (History)
6 users (show)

Fixed In Version: ne7ssh-1.3.2-10.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-16 19:17:15 UTC
rlandman: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Pavel Alexeev 2009-09-08 16:48:51 UTC
Spec URL: http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh.spec
SRPM URL: http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh-1.3.1-1.fc11.src.rpm
Description:
It utilizes Botan library for it's cryptographic functions, allowing for a
large choice of algorithms to be used in SSH communications.

As a developer you may wish to integrate SSH client functionality into your
applications. You can now use the NetSieben's API, instead of spending countless
hours developing your own solution.

The SSH library was created by the NetSieben developers who, after researching
the limited number of options available to them from both commercial and open
source communities, found these solutions limited and at best, still in early
stages of development.

P.S. Spec file formated with tabs by 5-space width. Please do not start review if it is big problem for you.

Comment 1 Pavel Alexeev 2009-09-08 17:59:40 UTC
Some fix install on 64-bit systems.

http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh-1.3.1-2.fc11.src.rpm
Spec URL the same.

Built successful: http://koji.fedoraproject.org/koji/taskinfo?taskID=1663037

Comment 2 Stefan Schulze Frielinghaus 2009-09-24 08:14:07 UTC
A few comments about the spec file:

- Tabs aren't aligned properly

- I'm not sure about this comment:
# It still required for EPEL5
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRoot is required on Fedora too or do I miss something?

- What about this comment (line 15)?

#Requires:

- You should write a patch instead of using sed here:
# Hack to correct install on 64-bit systems.
sed -i ...

sed will return 0/no error if it substitutes something or even does nothing but patch will fail if it cannot be applied. With a patch you are on the save side.

- The example package only contains 7 CPP files. Maybe you want to pack them into the main package as docs too? What do you think?

- I guess it is a typo in the Changelog
Fix installation on 54-bit systems.

should be

Fix installation on 64-bit systems.

Comment 3 Pavel Alexeev 2009-09-24 11:15:47 UTC
(In reply to comment #2)
> A few comments about the spec file:
> 
> - Tabs aren't aligned properly
Tabs aligned properly. Just you use another tab with (see first post).

> - I'm not sure about this comment:
> # It still required for EPEL5
> BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>
> BuildRoot is required on Fedora too or do I miss something?
Yes BuildRoot is obsoleted for Fedora.
http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag

> - What about this comment (line 15)?
> #Requires:
This is atavism. Deleted.

> - You should write a patch instead of using sed here:
> # Hack to correct install on 64-bit systems.
> sed -i ...
> 
> sed will return 0/no error if it substitutes something or even does nothing but
> patch will fail if it cannot be applied. With a patch you are on the save side.

Yes, there sed behavior is preferred.
1) We must be conditionally apply patch only on 64-bit systems.
2) sed always replace in this string, even if "lib" to "lib". So, it is normal.


> - The example package only contains 7 CPP files. Maybe you want to pack them
> into the main package as docs too? What do you think?
For what? Especially when work to split it was done.

> - I guess it is a typo in the Changelog
> Fix installation on 54-bit systems.
> 
> should be
> 
> Fix installation on 64-bit systems.  

Off course. Thank you.

Comment 4 Stefan Schulze Frielinghaus 2009-09-24 11:51:11 UTC
(In reply to comment #3)
> Tabs aligned properly. Just you use another tab with (see first post).

I red your first comment and just wanted to encourage you to use "normal" tabs or 8 whitespaces. I guess this not a big problem but why do you want to go a different why than most of the other packages? In a very strict sense this may fell under https://fedoraproject.org/wiki/Packaging/ReviewGuidelines#cite_note-5

> > - I'm not sure about this comment:
> > # It still required for EPEL5
> > BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> >
> > BuildRoot is required on Fedora too or do I miss something?
> Yes BuildRoot is obsoleted for Fedora.
> http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag

Oh. Haven't noticed that before. Thanks.

> > - You should write a patch instead of using sed here:
> > # Hack to correct install on 64-bit systems.
> > sed -i ...
> > 
> > sed will return 0/no error if it substitutes something or even does nothing but
> > patch will fail if it cannot be applied. With a patch you are on the save side.
> 
> Yes, there sed behavior is preferred.
> 1) We must be conditionally apply patch only on 64-bit systems.
> 2) sed always replace in this string, even if "lib" to "lib". So, it is normal.

Then why not write a patch and wrap it with a conditional for 64bit like you already mentioned? This would solve it. I'm not that familiar with this package but what does upstream say about this? Maybe they have the same problem?

> > - The example package only contains 7 CPP files. Maybe you want to pack them
> > into the main package as docs too? What do you think?
> For what? Especially when work to split it was done.

Since it is a library the example files may help developers to build against it. But again this is not a problem and I guess up to the packagers freedom.

Comment 5 Pavel Alexeev 2009-09-24 12:27:09 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Tabs aligned properly. Just you use another tab with (see first post).
> 
> I red your first comment and just wanted to encourage you to use "normal" tabs
> or 8 whitespaces. I guess this not a big problem but why do you want to go a
> different why than most of the other packages? In a very strict sense this may
> fell under
> https://fedoraproject.org/wiki/Packaging/ReviewGuidelines#cite_note-5
No "most of the other"!!!
I tired say about it. There was discussion on this theme -
http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/6214/focus=6224
And accordingly it proposed draft guidelines change -
https://fedoraproject.org/wiki/PackagingDrafts/Tabs
So, until it is not part Guidelines it can not be required.

> Then why not write a patch and wrap it with a conditional for 64bit like you
> already mentioned? This would solve it.
Sed also solve problem. So, I have opposite question - why I should write additionally patch? And what of benefit of it over sed solution??

> I'm not that familiar with this package
> but what does upstream say about this? Maybe they have the same problem?
No, they have-not. According to mail, he mention about /lib as symlink to /lib64. I don't known what system they use.

> Since it is a library the example files may help developers to build against
> it. But again this is not a problem and I guess up to the packagers freedom.  
Thanks. I think external package give more flexibility to user in any case.

Comment 6 Stefan Schulze Frielinghaus 2009-09-24 13:14:43 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Tabs aligned properly. Just you use another tab with (see first post).
> > 
> > I red your first comment and just wanted to encourage you to use "normal" tabs
> > or 8 whitespaces. I guess this not a big problem but why do you want to go a
> > different why than most of the other packages? In a very strict sense this may
> > fell under
> > https://fedoraproject.org/wiki/Packaging/ReviewGuidelines#cite_note-5
> No "most of the other"!!!
> I tired say about it. There was discussion on this theme -
> http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/6214/focus=6224
> And accordingly it proposed draft guidelines change -
> https://fedoraproject.org/wiki/PackagingDrafts/Tabs
> So, until it is not part Guidelines it can not be required.

You pointed to the right discussion and if you read the last few posts you will see my point of view.

> > Then why not write a patch and wrap it with a conditional for 64bit like you
> > already mentioned? This would solve it.
> Sed also solve problem. So, I have opposite question - why I should write
> additionally patch? And what of benefit of it over sed solution??

Like I already said e.g. if a new release is made available extra attention should always go to the sed line because sed my return without an error even when it didn't change a single bit. A patch would automate this. It would fail and raise an error. What about the next ten upstream releases? If they change the line e.g. from

install(TARGETS net7ssh LIBRARY DESTINATION lib)

to

install(TARGETS net7ssh LIBRARY DESTINATION LIB)

your sed section wouldn't fail and build fine e.g. on PPC. But then you should really make sure that you tested your package on every supported architecture. I'm not sure if it's worth that. If you submit your package to koji and automatically build for all supported architectures then koji would raise an error for 64bit. I would say it is more clean. But that's up to you.

Comment 7 Pavel Alexeev 2009-09-24 13:27:10 UTC
(In reply to comment #6)
> You pointed to the right discussion
I known :)

> and if you read the last few posts you will see my point of view.
You also known my point. I think its all now. I do not see any problem change tab width if you want in any editor what you like.

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 ne7ssh.spec | ./tab-convert.php > x11vnc.spec.spaces

Or, with power of UNIX-WAY, off course directly in shell f.e:
$ cat ne7ssh.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;}' >
ne7ssh.spec.spaces

> Like I already said e.g. if a new release is made available extra attention
> should always go to the sed line because sed my return without an error even
[snip]
> I'm not sure if it's worth that. If you submit your package to koji and
> automatically build for all supported architectures then koji would raise an
> error for 64bit. I would say it is more clean. But that's up to you.  
Yes, there no problem in any case, because koji build fails in case if something changed there.

Comment 8 Michael Schwendt 2009-09-24 20:31:01 UTC
Only those "sed" transformations, which would fail to substitute something silently _without_ causing the package build to fail with errors, are dangerous. In this case, however, on 64-bit multiarch targets the files would be installed into /lib and not found by %{_lib} in the %files section. A failing sed would lead to rpmbuild errors. That's okay.

[...]

About the -examples sub-package:

> I think external package give more flexibility to user in any case.  

So? What flexibility would that be? First of all, it requires the -devel package. Second, the -devel package requires the main package. Third, the included Makefile explicitly links with libbotan, so a dependency on botan-devel is missing => ne7ssh-devel is missing "Requires: botan-devel" as its headers include botan headers. Fourth, one cannot install the -example package like a separate -doc package to peruse the source code. Fifth, the examples are stored in their own directory instead of together with the API documentation. Sixth, the examples are just 25K uncompressed. Seventh, the base ne7ssh package contains 1.7M of API %doc files. Better split those files into a -doc package. It's covered by the guidelines even.

Convinced? I hope so. ;o)

[...]

The package %description doesn't explain what the package contains. A first sentence like the %summary is missing. Don't assume that %summary and %description are displayed above eachother.

There is typo in the %description:  s/it's/its/

Comment 9 Pavel Alexeev 2009-09-25 09:06:00 UTC
(In reply to comment #8)
> Only those "sed" transformations, which would fail to substitute something
> silently _without_ causing the package build to fail with errors, are
> dangerous. In this case, however, on 64-bit multiarch targets the files would
> be installed into /lib and not found by %{_lib} in the %files section. A
> failing sed would lead to rpmbuild errors. That's okay.
No, build package will be filed later in %files section when file not found in %{_lib} will be raised. This is why it hack appeared.

> > I think external package give more flexibility to user in any case.  
> 
> So? What flexibility would that be? First of all, it requires the -devel
> package. Second, the -devel package requires the main package.
Yes, off course. I expect what all my dependencies is correct and installation of ne7ssh-examples would require ne7ssh and ne7ssh-devel and all other required dependencies. BUT, you are free ot do not install ne7ssh-example - it is not required by anything other.

> Third, the
> included Makefile explicitly links with libbotan, so a dependency on
> botan-devel is missing => ne7ssh-devel is missing "Requires: botan-devel" as
> its headers include botan headers.
Why? BuildRequires: cmake botan-devel present in spec.

> Fourth, one cannot install the -example
> package like a separate -doc package to peruse the source code.
Yes, I known. This is because it contain Makefile to build examples, and its will fail, if ne7ssh-devel is not present in system. So, it is ok. If you only want read examples and known what you do, you always can install it forced without dependencies.

> Fifth, the
> examples are stored in their own directory instead of together with the API
> documentation.
And what? This is incorrect?

> Sixth, the examples are just 25K uncompressed.
And what? It can't be separate package because it?

> Seventh, the base
> ne7ssh package contains 1.7M of API %doc files. Better split those files into a
> -doc package.
Yes, there you are right. I'll do that.

> It's covered by the guidelines even.
Please, can you point me where?


> The package %description doesn't explain what the package contains. A first
> sentence like the %summary is missing. Don't assume that %summary and
> %description are displayed above eachother.
Should I repeat Summary in %description?? I believe not.

> There is typo in the %description:  s/it's/its/  
Thank you, fixed.


P.S. I'll

Comment 10 Michael Schwendt 2009-09-25 10:00:24 UTC
> No, build package will be filed later in %files section
> when file not found in %{_lib} will be raised.

Calm down. I had pointed that out already and confirmed that the "sed" usage is okay in this case.


> BUT, you are free ot do not install ne7ssh-example -
> it is not required by anything other.

Is that the only benefit you could think of? To save 25KB of example files you introduce a separate package (and corresponding repository metadata)? A separate package which developers, who may have interest in those files, would need to search for. It would be much more plausible to include those files in the -devel package. Examples in source code form are Documentation.


> BuildRequires: cmake botan-devel present in spec.

You didn't understand or you didn't pay attention to what I wrote.
"Requires: botan-devel" is missing in ne7ssh-devel


> > It's covered by the guidelines even.
> Please, can you point me where?

https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation


> Should I repeat Summary in %description?? I believe not.

You should start with a sentence that explains what the package contains and what "It" refers to. Is it an application? A library? What is it? Instead, the current description starts with "It utilizes Botan library for...". Moving the third paragraph at the beginning of the description and making it start with "This SSH library..." would make *a lot* of sense. Give it a second thought, please. I'm not making up things just for fun.

Comment 11 Pavel Alexeev 2009-09-25 21:06:56 UTC
(In reply to comment #10)
> Is that the only benefit you could think of? To save 25KB of example files you
> introduce a separate package (and corresponding repository metadata)?
No. For having choose :)

Ok, I'm turn it into doc subpackage, as we speak before.

> You didn't understand or you didn't pay attention to what I wrote.
> "Requires: botan-devel" is missing in ne7ssh-devel
Thanks, fixed.

About documentation you are right. I move first paragraph to the end. I think now it is more transparent for understanding.

http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh-1.3.1-3.fc11.src.rpm
spec URL the same

Comment 12 Stefan Schulze Frielinghaus 2009-09-26 11:58:31 UTC
rpmlint reports some errors and a warning:

ne7ssh.ppc: E: description-line-too-long applications. You can now use the NetSieben's API, instead of spending countless
ne7ssh.src: E: description-line-too-long applications. You can now use the NetSieben's API, instead of spending countless
ne7ssh-debuginfo.ppc: E: debuginfo-without-sources
ne7ssh-devel.ppc: W: no-documentation
ne7ssh-doc.noarch: E: devel-dependency ne7ssh-devel
5 packages and 1 specfiles checked; 4 errors, 1 warnings.

I guess the warning about no documentation can be ignored since the base package contains license information and so on. All others should be checked.

Comment 13 Pavel Alexeev 2009-09-26 18:36:12 UTC
(In reply to comment #12)
> rpmlint reports some errors and a warning:
> 
> ne7ssh.ppc: E: description-line-too-long applications. You can now use the
> NetSieben's API, instead of spending countless
> ne7ssh.src: E: description-line-too-long applications. You can now use the
> NetSieben's API, instead of spending countless
Hm, I don't see this warnings. What version of rpmlint you are using?

$ rpm -q rpmlint
rpmlint-0.90-1.fc11.noarch

> ne7ssh-debuginfo.ppc: E: debuginfo-without-sources
I have deep search but nothing found relevant this. Grep all files by "strip" also does no results. So, really this is applicable to library, not executable binary?

> ne7ssh-devel.ppc: W: no-documentation
I think it is may be safely ignored.

> ne7ssh-doc.noarch: E: devel-dependency ne7ssh-devel
Yes. And it also commented in spec. So, it come from -examples subpackage what you suggest merge with -doc. I do that. But examples required ne7ssh for compilation. So, no error there.


http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh-1.3.1-3.fc11.src.rpm

Comment 14 Michael Schwendt 2009-09-26 18:57:31 UTC
> ne7ssh-doc.noarch: E: devel-dependency ne7ssh-devel

I've thought you're a guy who preaches of "flexibility". What flexibility do you gain by making a separate noarch -doc package strictly require two -devel packages and their dependency-chain? None. It has become less flexible.

Technically, ne7ssh-doc does not need ne7ssh-devel for anything. The examples and a build environment are fully optional. Somebody who actually wants to compile stuff will need to install the development group's packages first, anyway.

Comment 15 Stefan Schulze Frielinghaus 2009-09-27 16:28:24 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > rpmlint reports some errors and a warning:
> > 
> > ne7ssh.ppc: E: description-line-too-long applications. You can now use the
> > NetSieben's API, instead of spending countless
> > ne7ssh.src: E: description-line-too-long applications. You can now use the
> > NetSieben's API, instead of spending countless
> Hm, I don't see this warnings. What version of rpmlint you are using?
> 
> $ rpm -q rpmlint
> rpmlint-0.90-1.fc11.noarch

I'm using the same version. But you should make yourself familiar with mock. It ensures that you have a clean build area. If you are really really unsure about your build you can try using koji. But before that you should use mock. I did a built for you on koji and still get the following errors/warnings:

ne7ssh.ppc: E: description-line-too-long applications. You can now use the NetSieben's API, instead of spending countless
ne7ssh.src: E: description-line-too-long applications. You can now use the NetSieben's API, instead of spending countless
ne7ssh-devel.ppc: W: no-documentation
ne7ssh-doc.noarch: E: devel-dependency ne7ssh-devel
5 packages and 0 specfiles checked; 3 errors, 1 warnings.

> http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh-1.3.1-3.fc11.src.rpm

Whenever you change something at your package then do a release bump. I have two versions of your package (release 3):

$ md5sum ne7ssh-1.3.1-3.fc11.src.rpm*
61b1be340be8e6572101f6a0d293ac3d  ne7ssh-1.3.1-3.fc11.src.rpm
bc8156ac376386796d5ef319b582d6f1  ne7ssh-1.3.1-3.fc11.src.rpm-BUMP_RELEASE_FORGOTTEN

$ rpmdiff ne7ssh-1.3.1-3.fc11.src.rpm ne7ssh-1.3.1-3.fc11.src.rpm-BUMP_RELEASE_FORGOTTEN 
S.5.......T ne7ssh.spec

$ diff -u a/ne7ssh.spec b/ne7ssh.spec 
...
-cmake .
+CFLAGS="%{optflags}" CXXFLAGS="%{optflags}" cmake .
...

This is the reason why the new package does not complain about debuginfo-without-sources anymore.

Btw. it is also good practice to include the output of rpmlint everytime you create a new package (I forget that sometimes too). This helps you to find bugs before posting the new version and also helps reviewers etc. as a first impression.

Comment 16 Pavel Alexeev 2009-09-29 11:58:20 UTC
(In reply to comment #14)
> > ne7ssh-doc.noarch: E: devel-dependency ne7ssh-devel
> 
> I've thought you're a guy who preaches of "flexibility". What flexibility do
> you gain by making a separate noarch -doc package strictly require two -devel
> packages and their dependency-chain? None. It has become less flexible.

Have it in separate subpackage -examples, which solve it trouble, also do not acceptable by your.

> Technically, ne7ssh-doc does not need ne7ssh-devel for anything. The examples
> and a build environment are fully optional. Somebody who actually wants to
> compile stuff will need to install the development group's packages first,
> anyway.  
Technically ne7ssh-doc contain examples and Makefile which actually need ne7ssh-devel to demonstrate it. So, if I omit it dependency make will be fail. I do not want intensionally make broken dependency. I think it is a main maintainer task create correct package dependencies. So, who install any package may expect what installed package work without any manual manipulation. And there have no mater this is game, o package for developer.

Comment 17 Pavel Alexeev 2009-09-29 12:12:00 UTC
(In reply to comment #15)
> I'm using the same version. But you should make yourself familiar with mock. It
> ensures that you have a clean build area. If you are really really unsure about
> your build you can try using koji. But before that you should use mock. I did a
> built for you on koji and still get the following errors/warnings:

Is especially strange, because when I do not found these errors on locally built files I built it on koji and check, only after that I wrote what I do not see it...

> Whenever you change something at your package then do a release bump. I have
> two versions of your package (release 3):
Typically I do that. This obviously is mistake, sorry.

Please check last package from site.

Comment 18 Michael Schwendt 2009-09-29 12:26:38 UTC
Splitting-hairs. You *could* include these tiny example source files in the -devel package, but it really doesn't matter. It's cleaner to treat them as documentation.

* The examples don't even build from scratch. They fail. You haven't tried to compile them at all, which shows how unimportant they are to you. Most of them are missing to include the cstdio header.

* The examples won't build inside their directory as only superuser root can write to that directory. A normal user would need to copy them somewhere else.

* The examples don't even work if built without modifications, since some contain only examplary values instead of real-life configuration values. They are really just an add-on to the API documentation, not ready-to-run demos.

* Documentation packages also need a program that can display the documentation. For example, a browser for HTML pages. Or a viewer for PDF files. Such requirements are _not_ hardcoded as package dependencies.

* All -devel packages need a matching development environment, i.e. compilers and tools, standard libraries. Such requirements are _not_ hardcoded as package dependencies either.

* A packaging issue is left, too.
  This is Fedora's cmake invocation with the %{cmake} macro:

 %build
-CFLAGS="%{optflags}" CXXFLAGS="%{optflags}" cmake .
+%{cmake} .
 make all %{?_smp_mflags}

Look at "rpm --eval %cmake" to see what it does. Not only does it set the optflags, it also increases verbosity to fill the build log with relevant output.

Comment 19 Pavel Alexeev 2009-10-01 19:27:40 UTC
(In reply to comment #18)
> Splitting-hairs. You *could* include these tiny example source files in the
> -devel package, but it really doesn't matter. It's cleaner to treat them as
> documentation.
If we treat this as documentation it should be included in -doc.
What is a big problem set nw7ssh-devel as dependency for nw7ssh-doc?

> * The examples don't even build from scratch. They fail. You haven't tried to
> compile them at all, which shows how unimportant they are to you. Most of them
> are missing to include the cstdio header.
You are wrong. I try build it. I can say more - I start learning this library by examples (as many do, it is why I pay such attention for that). But you a right, there is cstdio header issue. As I mail about it to upstream author in main library. This is trivial to fix errors. So, I hope it will be fixed soon. Or you think I should expand my patch on examples too?

> * The examples won't build inside their directory as only superuser root can
> write to that directory. A normal user would need to copy them somewhere else.
Yes. I known. But user can copy example "as is" and build it.

> * The examples don't even work if built without modifications, since some
> contain only examplary values instead of real-life configuration values. They
> are really just an add-on to the API documentation, not ready-to-run demos.
Modifications needed only dfor user/password. Other work fine with included Makefile. Furthermore, examples built ok (except cstdio header issue) it only may not functional properly (but user/pass is extremal private values to provide "commons").

> * Documentation packages also need a program that can display the
> documentation. For example, a browser for HTML pages. Or a viewer for PDF
> files. Such requirements are _not_ hardcoded as package dependencies.
No special tools needed. Standard cat, more or less commands may act as documentation reader. Especially for C-files. It is generic, it is not required listed as dependencies.

> * All -devel packages need a matching development environment, i.e. compilers
> and tools, standard libraries. Such requirements are _not_ hardcoded as package
> dependencies either.
Off course. But -devel packages itself must be listed as dependencies.

> 
> * A packaging issue is left, too.
>   This is Fedora's cmake invocation with the %{cmake} macro:
> 
>  %build
> -CFLAGS="%{optflags}" CXXFLAGS="%{optflags}" cmake .
> +%{cmake} .
>  make all %{?_smp_mflags}
> 
> Look at "rpm --eval %cmake" to see what it does. Not only does it set the
> optflags, it also increases verbosity to fill the build log with relevant
> output.  
This is very helpful hint. Thank you. I've fixed it.

http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh.spec

Comment 20 Michael Schwendt 2009-10-01 20:39:03 UTC
> What is a big problem set nw7ssh-devel as dependency for nw7ssh-doc?

It creates a superfluous chain of dependencies. It adds several packages, which
are not really needed by anyone who may want to evaluate the API Documentation (such as the included PDF). At least the following four packages would be pulled in: ne7ssh-devel + ne7ssh + botan-devel + botan. It's unexpected for a Documentation package to have such requirements.


> Or you think I should expand my patch on examples too?

No. Unless you insist on claiming it would be important that users could simply build them by executing "make" without having to install any needed packages. ;-)

Just like many _optional_ test-suites, such examples often are out-of-sync with the main library anyway. Especially if they are not built by default. That means less users will build them and will notice build problems. Less users will report build failures with _optional_ files to upstream.


> No special tools needed.

You misunderstood me. Surely, a PDF file needs a special viewer to display it. With that my earlier comments should be more clear.

Comment 21 Pavel Alexeev 2009-10-01 22:09:30 UTC
Ok, ok. Proposed soft-dependencies in RPM will be cool in this situation. But in nowadays we haven't them...

So, now I've delete ne7ssh-devel dependency from ne7ssh-doc, but add warning about it in description. Do you are agree with that solution?

> No. Unless you insist on claiming it would be important that users could
> simply build them by executing "make" without having to install any needed
> packages.
I'm insist on claiming it important :)

> You misunderstood me. Surely, a PDF file needs a special viewer to display it.
> With that my earlier comments should be more clear.
I understood you. You misunderstood my point. Such dependency is very generic and very ambiguous to be explicit. Really, all binary file require elf-interpreter, but we do not add kernel into any binary package as dependency!!! PDF also have many graphical tools and also many console converters like pdf2text. Absolutely different situation with source code. BR-dependency like gcc in most cases automatically deducted and written in package. And we also do not want explicit add it. But, if we want compile some code, we MUST write all dependency on concrete package to do that. It is a main work of maintainers.
Off course, I partial agree with yours arguments what it is not fully logical in -doc package (it is why it was listed as Requires, not BuildRequires) and it why I try search reasonable compromise in this situation.

Comment 23 Michael Schwendt 2009-10-02 07:08:25 UTC
We're going in circles...

As pointed out before, source code examples are technical documentation. The guidelines are explicit on where to put "API Documentation":

  https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation

Nothing wrong with putting them into the -devel package as %doc examples. It's the right place for them. Except that they still lack <cstdio> and fail to compile. ;)

> But, if we want compile some code, we MUST write all dependency on
> concrete package to do that. It is a main work of maintainers.

No, that doesn't apply to documentation. More often than not, in documentation we explicitly get rid of superfluous dependencies. For example: Perl scripts included as %doc. Typically, these are explicitly made non-executable, so rpmbuild's dependency generator does not add any Perl Module dependencies automatically.

Comment 24 Pavel Alexeev 2009-10-02 08:06:46 UTC
(In reply to comment #23)
> We're going in circles...
> 
> As pointed out before, source code examples are technical documentation. The
> guidelines are explicit on where to put "API Documentation":
> 
>   https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
> 
> Nothing wrong with putting them into the -devel package as %doc examples. It's
> the right place for them.
Cite from this link: "Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use *-doc as the subpackage name, and Documentation as the value of the Group tag."
So, I think we must threat it as "documentation in -devel OR -doc" (as I make decision what it is big and create this sub-package), not in both!

> Except that they still lack <cstdio> and fail to
> compile. ;)
Well, I extend patch to examples too.

> No, that doesn't apply to documentation. More often than not, in documentation
> we explicitly get rid of superfluous dependencies. For example: Perl scripts
> included as %doc. Typically, these are explicitly made non-executable, so
> rpmbuild's dependency generator does not add any Perl Module dependencies
> automatically.  
Yes, I known rpmlint have this check check - http://rpmlint.zarb.org/cgi-bin/trac.cgi/browser/trunk/DocFilesCheck.py#L88

Please run command:
$ repoquery '*-doc' --requires
and you can see ho many -doc subpackages have dependencies. There perl, perl modules, -devel packages and just many other programs. Off course some of that is errors, but I do not see any trouble have such dependency when it can have worth.

http://hubbitus.net.ru/rpm/Fedora11/ne7ssh/ne7ssh-1.3.1-6.fc11.src.rpm

Comment 25 Michael Schwendt 2009-10-02 10:03:05 UTC
> So, I think we must threat it as "documentation in -devel OR -doc"

There is one unwritten guideline above all others. It's called "consider common sense".

If a -devel package included a couple of "man 3" pages for its API headers and also at least one large PDF file or a huge HTML tree, would you move _all_ %doc files into a separate -doc package? No. Nothing in the guidelines says you must decide between either -devel OR -doc. You are free to move the large files into -doc and keep other documentation files in -devel. It's the obvious solution. And convenient, too. Just as you're free to put further non-development oriented documentation files into other sub-packages.

The original idea to create a -examples package for only six tiny source files was a weird and unpractical idea, and I think now you just don't want to let loose. That's why you show resistance. ;)

> Please run command:
> $ repoquery '*-doc' --requires
> and you can see ho many -doc subpackages have dependencies. 

So what? --v

> Off course some of that is errors,

Exactly. :-) Don't treat them as good examples.

Comment 26 Pavel Alexeev 2009-10-02 11:49:34 UTC
(In reply to comment #25)
> There is one unwritten guideline above all others. It's called "consider common
> sense".
Only after real guidelines.

> If a -devel package included a couple of "man 3" pages for its API headers and
> also at least one large PDF file or a huge HTML tree, would you move _all_ %doc
> files into a separate -doc package?
Man file must stay in main package I though, not in -devel.

> No. Nothing in the guidelines says you must
> decide between either -devel OR -doc. You are free to move the large files into
> -doc and keep other documentation files in -devel. It's the obvious solution.
> And convenient, too. Just as you're free to put further non-development
> oriented documentation files into other sub-packages.
I don't known really. I ask in devel ml:
https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00109.html

> The original idea to create a -examples package for only six tiny source files
> was a weird and unpractical idea, and I think now you just don't want to let
> loose. That's why you show resistance. ;)
What? Loose? What loose?? I'm 2 times remade it as you want! But also I want do work as best as can. I only search best way.

> Exactly. :-) Don't treat them as good examples.  
Why? I try "consider common sense". ;)

Comment 27 Ralf Corsepius 2009-10-02 12:50:27 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > There is one unwritten guideline above all others. It's called "consider common
> > sense".
> Only after real guidelines.
Nonsense. The guidelines are supposed to be a reflection of the "common sense" and are not a law (and even laws can be changed).


> > If a -devel package included a couple of "man 3" pages for its API headers and
> > also at least one large PDF file or a huge HTML tree, would you move _all_ %doc
> > files into a separate -doc package?
> Man file must stay in main package I though, not in -devel.
Wrong again. Man pages must be part of the subpackage they document.
This normally means,  *1's need to go to the base package, *3's need to go
to *-devel.


 
> > No. Nothing in the guidelines says you must
> > decide between either -devel OR -doc. You are free to move the large files into
> > -doc and keep other documentation files in -devel.
The same as with man-pages. In general, doc's need to be part (Or be pulled in through package deps) of the package they document.
=> user-documentation goes into the base package
=> devel-docs into *devel packages
unless there are technical reasons to do otherwise

Comment 28 Pavel Alexeev 2009-10-02 14:02:43 UTC
(In reply to comment #27)
> Nonsense. The guidelines are supposed to be a reflection of the "common sense"
> and are not a law (and even laws can be changed).
Off course. There procedure propose draft and change guidelines if "common case" changed. After ratification new guidelines must be required for anything without exception.


> Wrong again. Man pages must be part of the subpackage they document.
> This normally means,  *1's need to go to the base package, *3's need to go
> to *-devel.
I did not know. Please, can you point where it is described more precisely.

> The same as with man-pages. In general, doc's need to be part (Or be pulled in
> through package deps) of the package they document.
> => user-documentation goes into the base package
> => devel-docs into *devel packages
> unless there are technical reasons to do otherwise  
We speak about separate -doc sub-packages now instead of "user-documentation goes into the base package"

Comment 29 Ralf Corsepius 2009-10-04 04:59:01 UTC
(In reply to comment #28)
> > Wrong again. Man pages must be part of the subpackage they document.
> > This normally means,  *1's need to go to the base package, *3's need to go
> > to *-devel.
> I did not know. Please, can you point where it is described more precisely.
It's "common sense" - c.f. the "MANUAL SECTIONS" in man man.

> > The same as with man-pages. In general, doc's need to be part (Or be pulled in
> > through package deps) of the package they document.
> > => user-documentation goes into the base package
> > => devel-docs into *devel packages
> > unless there are technical reasons to do otherwise  
> We speak about separate -doc sub-packages now instead of "user-documentation
> goes into the base package"  
I don't understand this remark.

In general, separate *-doc (sub-)packages only make real sense in very few occasions, e.g.
1) when docs are optional supplements (e.g. a pdf's formated docs, which are already available in some other formats)
2) when docs are "big" and can be shared as "noarch"-subpackages between architectures.
3) when upstream ships docs as separate package
...

Comment 30 Pavel Alexeev 2009-10-04 19:43:43 UTC
(In reply to comment #29)
> > I did not know. Please, can you point where it is described more precisely.
> It's "common sense" - c.f. the "MANUAL SECTIONS" in man man.
Its nothing say about packaging... In any case, man pages even shouldn't be marked as %doc as I known... Or not?

> In general, separate *-doc (sub-)packages only make real sense in very few
> occasions, e.g.
> 1) when docs are optional supplements (e.g. a pdf's formated docs, which are
> already available in some other formats)
> 2) when docs are "big" and can be shared as "noarch"-subpackages between
> architectures.
> 3) when upstream ships docs as separate package
> ...  
Guidelines mention only case 2.
3 - I think is clear, it is not our case now.
Global, you are speak about cases when we should make separate -doc sub-package, but I think it is not forbidden in other cases too. I repeat, decision make separate -doc was done, so, nowadays question another: in described 1 and 2 (in 3 content is known from upstream) should be all documentation go into sub-package, or we free separate it as we want?? And one more - would (can) -doc sub-package have any dependency (in concrete situation to build examples)?

Comment 31 Michael Schwendt 2009-10-04 20:20:12 UTC
> man pages even shouldn't be marked as %doc as I known...

You are mistaken. %{_mandir} is automatically marked as %doc.

> should be all documentation go into sub-package, or we free
> separate it as we want??

Apply "common sense".

Btw, that question has been answered before in this ticket, too.

> would (can) -doc sub-package have any dependency (in concrete
> situation to build examples)?

It would reduce flexibility if you added such dependencies to a Documentation package.

[...]

The problem in this review is that you put way too much emphasis on those six tiny example source code files. The target group of that 25K of source code is *very* small, the target group of built examples is even smaller. IMHO, including the files in the -devel package (without adding any extra dependencies) would be the most convenient thing to do for developers. Anything beyond that would not be worth the effort.

Comment 32 Pavel Alexeev 2009-10-08 20:26:42 UTC
(In reply to comment #31)
> You are mistaken. %{_mandir} is automatically marked as %doc.
Hm...
Where?
$ rpm --showrc | grep '[[:space:]]_mandir'
-14: _mandir    /usr/share/man

> Apply "common sense".
> Btw, that question has been answered before in this ticket, too.
No "common sense" there. Mystique "common sense" you do not want accept when we see many dependency in doc packages in our repository! Also see before.

> It would reduce flexibility if you added such dependencies to a Documentation
> package.
What flexibility it would reduce? You free to do not install Documentation at all. As required in guidelines main package can't rely on documentation in any case.

Again, when I make separate examples sub-package you are speak about "excessive flexibility"...

> [...]
> 
> The problem in this review is that you put way too much emphasis on those six
> tiny example source code files. The target group of that 25K of source code is
> *very* small, the target group of built examples is even smaller.
What exactly can mean size of examples in our situation?? Yes, it is not big, but why we should pay to that less attention?

> IMHO,
> including the files in the -devel package (without adding any extra
> dependencies) would be the most convenient thing to do for developers.
What is main - I do NOT strongly disagree with you there...
But also I'm not sure what it is strongly correct way or it is mentioned "common sense"...

> Anything beyond that would not be worth the effort.
If I known what can do anything better, usually (unfortunately not always) I ready spent some additional effort to do that. And there no difference how many files or kilobytes in work.

Comment 33 Michael Schwendt 2009-10-09 08:18:11 UTC
> Hm...
> Where?

See "rpm --eval %__docdir_path". Btw, directories themselves _cannot_ be marked as %doc, it's files inside them which are marked as %doc.

[...]

With regard to the old -examples subpackage and my recommendation on where to place the files instead, I've said everything. It doesn't make any sense to go in circles.

Comment 34 Rafael Aquini 2010-08-20 01:32:00 UTC
PING

It's been almost a year with no progress; This review should be closed soon if there is no response, shouldn't it?

Comment 35 Pavel Alexeev 2010-08-24 08:10:53 UTC
Guyes, sorry for delay - I forgot it review.

Update version, remove old patch, add license in subpackage.
http://hubbitus.net.ru/rpm/Fedora13/ne7ssh/ne7ssh-1.3.2-9.fc13.src.rpm
http://hubbitus.net.ru/rpm/Fedora13/ne7ssh/ne7ssh.spec

What issues we have there left now?

Comment 36 R P Herrold 2010-08-24 15:18:48 UTC
ne7ssh-1.3.2-9.fc13.src.rpm

I get a lot of unpackaged files chatter , attempting a build of this on CentOS 5 ... 

error: Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/lib64/libnet7ssh.so.0.3.1.debug
   /usr/lib/debug/usr/lib64/libnet7ssh.so.0.debug
   /usr/lib/debug/usr/lib64/libnet7ssh.so.debug
   /usr/src/debug/ne7ssh-1.3.2/src/crypt.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/crypt.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_channel.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_channel.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_connection.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_connection.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_error.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_error.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_kex.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_kex.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_keys.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_keys.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_mutex.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_mutex.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_session.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_session.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp_packet.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp_packet.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_string.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_string.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_transport.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_transport.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_types.h


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/lib64/libnet7ssh.so.0.3.1.debug
   /usr/lib/debug/usr/lib64/libnet7ssh.so.0.debug
   /usr/lib/debug/usr/lib64/libnet7ssh.so.debug
   /usr/src/debug/ne7ssh-1.3.2/src/crypt.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/crypt.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_channel.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_channel.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_connection.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_connection.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_error.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_error.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_kex.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_kex.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_keys.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_keys.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_mutex.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_mutex.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_session.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_session.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp_packet.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_sftp_packet.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_string.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_string.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_transport.cpp
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_transport.h
   /usr/src/debug/ne7ssh-1.3.2/src/ne7ssh_types.h
[herrold@centos-5 ne7ssh]$

Comment 37 Pavel Alexeev 2010-08-25 07:53:02 UTC
El5 build fails, I think because old version of botan.
But El6 build just fine - http://koji.fedoraproject.org/koji/taskinfo?taskID=2425307

Comment 38 Ruediger Landmann 2011-02-01 05:39:23 UTC
Thanks Pavel -- it looks like you've addressed all the concerns that Michael raised about this package. It builds fine for F14 and F15

Just two more little issues:

1. Because it looks like we cannot build this package for EPEL5, we can now drop:
* the Buildroot: declaration
* the cleaning of the Buildroot from %install 
* the whole %clean section

2. We can clean up the English expression in %description doc to say:

========
API documentation and example code to try the %{name} library.
It also contains a Makefile that builds all the examples with a single
command.

WARNING: To build the included examples of code, you must have the 
%{name}-devel package installed. Install the %{name}-devel package manually 
if you plan to compile these examples.
========

Beyond that, the package looks good to me:

 - = N/A
 / = Check
 ! = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [/] Rpmlint output is clean:
$ rpmlint SPECS/ne7ssh.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
$ rpmlint SRPMS/ne7ssh-1.3.2-9.fc14.src.rpm
ne7ssh.src: W: spelling-error %description -l ru своё -> свои, свое, свор
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
$ rpmlint RPMS/x86_64/ne7ssh-1.3.2-9.fc14.x86_64.rpm
ne7ssh.x86_64: W: spelling-error %description -l ru своё -> свои, свое, свор
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
$ rpmlint RPMS/x86_64/ne7ssh-devel-1.3.2-9.fc14.x86_64.rpm
ne7ssh-devel.x86_64: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
$ rpmlint RPMS/noarch/ne7ssh-doc-1.3.2-9.fc14.noarch.rpm
ne7ssh-doc.noarch: W: spelling-error %description -l en_US devel -> delve, devil, revel
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
$ rpmlint RPMS/x86_64/ne7ssh-debuginfo-1.3.2-9.fc14.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

 [/] Package is named according to the Package Naming Guidelines.
 [/] Spec file name must match the base package %{name}, in the format
%{name}.spec.
 [/] Package meets the Packaging Guidelines including the Language specific
items
 [/] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.
 [/] License field in the package spec file matches the actual license.
     License type: QPL
 [/] If (and only if) the source package includes the text of the license(s) in
its own file, then that file, containing the text of the license(s) for the
package is included in %doc.
 [/] Spec file is legible and written in American English.
 [/] Sources used to build the package matches the upstream source, as provided
in the spec URL.
$ md5sum SOURCES/ne7ssh-1.3.2.tar.bz2 
3f9ce5b8414177fc5bbcce6332238658  SOURCES/ne7ssh-1.3.2.tar.bz2
$ md5sum ~/Download/ne7ssh-1.3.2.tar.bz2 
3f9ce5b8414177fc5bbcce6332238658  /home/rlandmann/Download/ne7ssh-1.3.2.tar.bz2

 [/] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested: http://koji.fedoraproject.org/koji/taskinfo?taskID=2754031
 [/] Package is not known to require ExcludeArch
 [/] All build dependencies are listed in BuildRequires, except for any that
are listed in the exceptions section of Packaging Guidelines.
 [-] The spec file handles locales properly (with the %find_lang macro)
 [/] ldconfig called in %post and %postun if required.
 [/] Package does not bundle copies of system libraries
 [/] Package is not relocatable.
 [/] Package must own all directories that it creates.
 [/] Package does not contain duplicates in %files.
 [/] Permissions on files are set properly
 [/] %files section includes a %defattr(...) line
 [/] Package consistently uses macros.
 [/] Large documentation files are in a -doc subpackage, if required.
 [/] Package uses nothing in %doc for runtime.
 [/] Header files in -devel subpackage, if present.
 [-] Static libraries in -static subpackage, if present.
 [/] Development .so files in -devel subpackage, if present.
 [/] -devel packages require base package with full versioning.
 [/] Package does not contain any libtool archives (.la).
 [-] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [/] Package does not own files or directories owned by other packages.
 [/] Filenames are valid UTF-8

Comment 39 Pavel Alexeev 2011-02-02 18:54:17 UTC
Ruediger Landmann, thank you very much for the review. May I do response review for you?

Today I not so interesting in this library, but let it be when so much work was done.
All issues addressed, thank you again to help.
http://hubbitus.net.ru/rpm/Fedora13/ne7ssh/ne7ssh.spec
http://hubbitus.net.ru/rpm/Fedora13/ne7ssh/ne7ssh-1.3.2-10.fc13.src.rpm

Comment 40 Ruediger Landmann 2011-02-03 03:13:09 UTC
Pozalsta ;) And no, I don't need any reviews right now, but since you offered, I might call on you in future. :)

ACCEPTED -- go ahead and make your SCM request.

Comment 41 Pavel Alexeev 2011-02-04 15:46:25 UTC
Ruediger, thank you for the review again.

New Package SCM Request
=======================
Package Name: ne7ssh
Short Description: SSH Library is a Secure Shell client software written in C++
Owners: hubbitus
Branches: F-13 F-14 EL-6
InitialCC:

Comment 42 Kevin Fenzi 2011-02-06 22:43:45 UTC
Git done (by process-git-requests).

Comment 43 Fedora Update System 2011-02-06 23:41:24 UTC
ne7ssh-1.3.2-10.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/ne7ssh-1.3.2-10.el6

Comment 44 Fedora Update System 2011-02-06 23:41:52 UTC
ne7ssh-1.3.2-10.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/ne7ssh-1.3.2-10.fc13

Comment 45 Fedora Update System 2011-02-06 23:42:17 UTC
ne7ssh-1.3.2-10.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ne7ssh-1.3.2-10.fc14

Comment 46 Fedora Update System 2011-02-07 17:53:08 UTC
ne7ssh-1.3.2-10.el6 has been pushed to the Fedora EPEL 6 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ne7ssh'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ne7ssh-1.3.2-10.el6

Comment 47 Fedora Update System 2011-02-16 19:17:07 UTC
ne7ssh-1.3.2-10.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 48 Fedora Update System 2011-02-16 19:20:01 UTC
ne7ssh-1.3.2-10.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 49 Fedora Update System 2011-02-23 21:50:23 UTC
ne7ssh-1.3.2-10.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.