Bug 1119197 - Review Request: gnushogi - Shogi (Japanese Chess) AI engine
Summary: Review Request: gnushogi - Shogi (Japanese Chess) AI engine
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ben Rosser
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-GAMESIG
TreeView+ depends on / blocked
 
Reported: 2014-07-14 09:04 UTC by Chen Chen
Modified: 2018-05-16 13:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-16 13:06:13 UTC
Type: ---
Embargoed:
rosser.bjr: fedora-review+


Attachments (Terms of Use)
gnushogi.spec (3rd submit) (1.56 KB, text/x-rpm-spec)
2014-07-15 09:48 UTC, Chen Chen
no flags Details
SRPM (3rd submit) (458.91 KB, application/x-rpm)
2014-07-16 09:29 UTC, Chen Chen
no flags Details
gnushogi.spec (1.58 KB, text/x-rpm-spec)
2014-07-17 09:31 UTC, Chen Chen
no flags Details
gnushogi-1.4.2-1.fc20.src.rpm (377.58 KB, application/x-rpm)
2014-07-17 09:32 UTC, Chen Chen
no flags Details
xshogi.spec (765 bytes, text/x-rpm-spec)
2014-07-17 09:33 UTC, Chen Chen
no flags Details
xshogi-1.4.2-1.fc20.src.rpm (252.45 KB, application/x-rpm)
2014-07-17 09:34 UTC, Chen Chen
no flags Details

Description Chen Chen 2014-07-14 09:04:22 UTC
Spec URL: https://dl.dropboxusercontent.com/u/56671522/gnushogi.spec
SRPM URL: https://dl.dropboxusercontent.com/u/56671522/gnushogi-20140714git29cc00c-1.fc20.src.rpm

Description:
GNU shogi is a program that plays shogi, the Japanese version of chess, against a human (or computer) opponent.
GNU Shogi proper is only the AI engine, and you will likely want to use a GUI frontend (XBoard, for example) to be more comfortable.
(This is a snapshot from git version, which has decent autotools support and recognize xboard protocol)

Fedora Account System Username: aflyhorse

Comment 1 Chen Chen 2014-07-14 09:31:41 UTC
Ouch, I forgot this etiquette:
this is my first package, and I am seeking a sponsor.

Comment 2 Chen Chen 2014-07-15 07:36:48 UTC
Following the advice of upstream maintainer (Thanks Yann)
I made some update to the package. The links in the first post were unlinked and here is the new version:

Spec URL: https://dl.dropboxusercontent.com/u/56671522/gnushogi.spec 
SRPM URL: https://dl.dropboxusercontent.com/u/56671522/gnushogi-1.4.2%2B-1.20140714gitf1d6e23.fc20.src.rpm

Comment 3 Christopher Meng 2014-07-15 07:44:55 UTC
The second spec is even worse than the initial submitted one.

Comment 4 Chen Chen 2014-07-15 08:15:32 UTC
Because I seperated my patch from the original git snapshot.

My patch involved tweaking the configure.ac, thus cause a full "autoreconf" in %prep stage and pulled in a long list of build dependency. The build dependency list is generated via auto-buildrequires (https://apps.fedoraproject.org/packages/auto-buildrequires)

Koji Build output:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7142190
http://koji.fedoraproject.org/koji/taskinfo?taskID=7142198

Comment 5 Christopher Meng 2014-07-15 08:37:29 UTC
(In reply to Chen Chen from comment #4)
> Because I seperated my patch from the original git snapshot.

You should use a released tarball from the official website, then rebase your patch. No comments around there, I don't know where you got the sources.

Your source0 contains no URL and as a result it's untrusted. Please use the full link.

> My patch involved tweaking the configure.ac, thus cause a full "autoreconf"
> in %prep stage and pulled in a long list of build dependency. The build
> dependency list is generated via auto-buildrequires
> (https://apps.fedoraproject.org/packages/auto-buildrequires)

That tool is a crap nowadays, and that long list generated is also a crap. You need to know what gnushogi needs for the building, not let tool teach you how to find the dependencies. Don't be sloppy.

Also your patch only invokes the check of the texinfo and it doesn't make sense to me that such a horrendous list of BRs should be pulled in, it's wrong. Please read carefully:

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

> Koji Build output:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=7142190
> http://koji.fedoraproject.org/koji/taskinfo?taskID=7142198

Successful build indicates nothing as the package you sent here doesn't match the guideline.

And your name also caught my eyes as well, just a note to ensure that please use your real name here if possible in most cases.

Comment 6 Chen Chen 2014-07-15 09:46:52 UTC
(In reply to Christopher Meng from comment #5)
> (In reply to Chen Chen from comment #4)
> > Because I seperated my patch from the original git snapshot.
> 
> You should use a released tarball from the official website, then rebase
> your patch. No comments around there, I don't know where you got the sources.
> 
> Your source0 contains no URL and as a result it's untrusted. Please use the
> full link.

I don't think use the released tarball is a good idea:
a) It doesn't talk to modern xboard, but use an outdated xshogi as GUI. xshogi is a years old folk of xboard.
b) The tarball also needs "autoreconf" on f20. The autotoolchain in tarball is too old and doesn't honor "make install DESTDIR="

I've updated the spec and added source in comments according to https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Using_Revision_Control

> Also your patch only invokes the check of the texinfo and it doesn't make
> sense to me that such a horrendous list of BRs should be pulled in, it's
> wrong. Please read carefully:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2

Thanks for the link. I've eliminated them in my 3rd submission in attachment.
 
> And your name also caught my eyes as well, just a note to ensure that please
> use your real name here if possible in most cases.

This is my real name. I can email you a photocopy of my passport if you want.

Comment 7 Chen Chen 2014-07-15 09:48:47 UTC
Created attachment 918089 [details]
gnushogi.spec (3rd submit)

Comment 8 Chen Chen 2014-07-16 09:29:04 UTC
Created attachment 918361 [details]
SRPM (3rd submit)

http://koji.fedoraproject.org/koji/taskinfo?taskID=7142468

Comment 9 Chen Chen 2014-07-17 09:31:06 UTC
Created attachment 918647 [details]
gnushogi.spec

After some struggle I decided to use the released tarball as initial package. So the package is splitted into two: gnushogi and xshogi.

http://koji.fedoraproject.org/koji/taskinfo?taskID=7156120

Comment 10 Chen Chen 2014-07-17 09:32:03 UTC
Created attachment 918648 [details]
gnushogi-1.4.2-1.fc20.src.rpm

Comment 11 Chen Chen 2014-07-17 09:33:30 UTC
Created attachment 918649 [details]
xshogi.spec

The xshogi is the X-11 front-end of GNU Shogi.

http://koji.fedoraproject.org/koji/taskinfo?taskID=7156126

Comment 12 Chen Chen 2014-07-17 09:34:12 UTC
Created attachment 918650 [details]
xshogi-1.4.2-1.fc20.src.rpm

Comment 13 Yann Dirson 2014-07-24 20:22:35 UTC
(In reply to Christopher Meng from comment #5)
> You need to know what gnushogi needs for the building, not let tool teach
> you how to find the dependencies. Don't be sloppy.

You can also get a look at the build-deps I used for the debian package.

Comment 14 Ben Rosser 2017-12-08 21:56:02 UTC
I'm sorry, I must have missed this when I went through looking for games tickets stuck in the review queue!

It has been several years, but please reply if you are still interested in this submission, and I'd be willing to review.

Comment 15 Chen Chen 2017-12-09 08:07:30 UTC
(In reply to Ben Rosser from comment #14)
> It has been several years, but please reply if you are still interested in
> this submission, and I'd be willing to review.

Hi Ben,

I'm still willing to package this game. Please let me have some time to catch up with the latest development and prepare a new SRPM.

Comment 16 Ben Rosser 2017-12-09 19:54:23 UTC
> I'm still willing to package this game. Please let me have some time to catch up with the latest development and prepare a new SRPM.

Great to hear you are still interested! Just let me know when the package is ready.

Once the time comes, I can also sponsor you.

Comment 18 Ben Rosser 2018-01-23 04:31:13 UTC
Great! I have a few comments just based off of reading the spec.

> Version:        1.5pre
> Release:        1.git%{shortcommit}%{?dist}

Fedora's Versioning guidelines say that to indicate a pre-release version, you should use the expected version number as the Version tag and put a leading "0." in the release tag. That is, something like this:

Version: 1.5
Release: 0.1.git%{shortcommit}%{?dist}

Then if and when upstream releases 1.5, you can remove the trailing 0 and rpm will see your package as an update.

https://fedoraproject.org/wiki/Packaging:Versioning#Prerelease_versions

> # The source of this package was pulled from upstreams's vcs.

While this is okay to do when necessary, it's always better to use an actual SourceURL if possible. After poking around the Savannah cgit interface I believe you can use the following SourceURL:

Source0: https://git.savannah.gnu.org/cgit/gnushogi.git/snapshot/gnushogi-%{commit}.tar.gz

In which case, you'll need to modify the "setup" macro appropriately:

%setup -qn %{name}-%{commit}

And then you need to add the invocation of autogen.sh to the spec as well, along with the necessary BuildRequires on autoconf/automake/texinfo as well.

> make %{?_smp_mflags}

While this works fine, it is recommended to replace this with the relatively new "%make_build" macro.

> %{__rm} -f %{buildroot}%{_infodir}/dir

This is frowned upon. You should just use "rm":

"Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, rm should be used in preference to %{__rm}, but %{__python} is acceptable."

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

> Requires:       ncurses-libs

This explicit dependency is probably unnecessary. RPM can generally figure out C/C++ library dependencies. You can check to make sure by running "rpm -qpR" over a spec to see the dependencies, like so:

[bjr@rannoch Downloads]$ rpm -qpR /var/lib/mock/fedora-rawhide-x86_64/result/gnushogi-1.5pre-1.git5bb0b5b.fc28.x86_64.rpm 
/bin/sh
/bin/sh
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libncurses.so.6()(64bit)
...

So, rpm was able to find the libncurses dependency on it's own.

In addition, according to https://fedoraproject.org/wiki/Packaging:Scriptlets#Texinfo you need to add the Requires for "info" for the post and preun triggers.

> Requires(post): info
> Requires(preun): info

You might want to consider adding a weak dependency on xboard. You can read more about them here: https://fedoraproject.org/wiki/Packaging:WeakDependencies

Otherwise the spec looks fine to me. I'll do a more detailed run through over the next few days and let you know if I find anything else.

Comment 19 Chen Chen 2018-01-23 07:24:56 UTC
SPEC updated as per your suggestion.

SPEC (Same link, you can read the change in gist):
https://gist.github.com/aflyhorse/dc5f37bd72008315ac323f66b88ead1e

SRPM:
https://www.lunes.faith/SRPMS/gnushogi-1.5-0.2.git5bb0b5b.fc26.src.rpm

Built Binaries (Same link):
https://copr.fedorainfracloud.org/coprs/aflyhorse/gnushogi


BTW, should I still upload to koji, or copr is OK?

Comment 20 Ben Rosser 2018-02-06 02:20:19 UTC
copr is fine for scratch builds these days (it uses Koji behind the scenes).

Just a  note, generally it's good to run "rpmlint" over your package before uploading (e.g. "rpmlint [rpm]"). It frequently produces spurious warnings that can safely be ignored (like "spelling errors"), but it can also detect actual problems. In this instance it found a few complaints.

On a related note, I'd encourage you to use the template format of:

> Spec URL:
> SRPM URL: 

when posting changes in a review ticket-- this makes it possible for the automated "fedora-review" tool to run properly. You can try running this yourself over a review ticket if you have mock installed:

$ dnf install fedora-review
$ fedora-review -b [bugzilla ID] -m fedora-rawhide-x86_64

This will try to fetch the spec and SRPM from bugzilla and automatically build and run some checks over them. (fedora-review can also be given files locally, but that adds a step for the reviewer of having to download the tickets). 

Anyway, here are a few problems pointed out by rpmlint:

> gnushogi.x86_64: E: description-line-too-long C GNU shogi is a program that plays shogi, the Japanese version of chess, against a human (or computer) opponent.
> gnushogi.x86_64: E: description-line-too-long C GNU Shogi proper is only the AI engine, and you will likely want to use a GUI frontend (XBoard, for example) to be more comfortable.

The lines in %description should be wrapped to 80 characters.

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

> gnushogi.x86_64: W: incoherent-version-in-changelog 1.5.0.2.git5bb0b5b ['1.5-0.2.git5bb0b5b.fc28', '1.5-0.2.git5bb0b5b']

Looks like you just made a small typo here, though it looks like you fixed it in the spec after building the SRPM. (In general, you should make sure that the version of the spec you upload is the same as the one you use to build the SRPM. For simple things like this it doesn't really matter, but it's just generally good practice).

> gnushogi.x86_64: E: shell-syntax-error-in-%post
> gnushogi.x86_64: E: shell-syntax-error-in-%preun

You seem to be missing "; then" after your conditionals:

https://gist.github.com/aflyhorse/dc5f37bd72008315ac323f66b88ead1e#file-gnushogi-spec-L48

https://gist.github.com/aflyhorse/dc5f37bd72008315ac323f66b88ead1e#file-gnushogi-spec-L58

When I attempted to install the RPM, I got similar errors from dnf.

In addition, I then tried to run gnushogi. It seems it wants to write out it's .bbk file in /usr/lib64/gnushogi, which is not user-writable. Looking at the documentation (doc/BOOKFILES), I believe "make -C gnushogi gnushogi.bbk" should be run under %build, in order to pre-compile the binary book file.

Please fix the above, and I'll be more than happy to approve the package and sponsor you-- everything else looks good.

Comment 21 Kevin Fenzi 2018-02-07 18:40:02 UTC
Just a small drive by comment: 

(In reply to Ben Rosser from comment #20)
> copr is fine for scratch builds these days (it uses Koji behind the scenes).

copr does not use koji at all. ;) Scratch builds in koji are similar to copr builds with the 'network access' turned off, but they aren't the exact same systems doing the building. Just wanted to note it... carry on.

Comment 22 Chen Chen 2018-02-08 09:31:43 UTC
Spec URL: https://github.com/aflyhorse/gnushogi-spec/raw/master/gnushogi.spec
SRPM URL: https://www.lunes.faith/SRPMS/gnushogi-1.5-0.3.git5bb0b5b.fc26.src.rpm

No sure why it wants to write .bbk into lib64. Might need to invent a patch to move it into share or generate into user's home.
BTW. Moved to Github in order to get a permanent direct link.

Comment 23 Ben Rosser 2018-02-08 16:49:03 UTC
> copr does not use koji at all. ;) Scratch builds in koji are similar to copr builds with the 'network access' turned off, but they aren't the exact same systems doing the building. 

Whoops, yes, I misspoke. What I meant to say was, both use *mock* behind the scenes and therefore are equally suitable for scratch builds.

> No sure why it wants to write .bbk into lib64. Might need to invent a patch to move it into share or generate into user's home.

That might be a good idea, since it seems like gnushogi expects to be able to write out the book files while it's running. Ideally, I guess it should be able to read them from both /usr/share and somewhere under /home?

I'd encourage you to try to improve this, but this isn't a blocker for review purposes. 

However... one final thing that is a blocker:

> %{_libdir}/%{name}/gnushogi.tbk
> %{_libdir}/%{name}/gnushogi.bbk

Should just be:

> %{_libdir}/%{name}

The former causes %{_libdir}/gnushogi to be a directory not owned by any package.

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

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed

===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "GPL (v1 or later) (with incorrect FSF address)", "Unknown or
     generated", "GPL (v3 or later)". 21 files have unknown license.

     (Note: this is weird but some of the Makefiles have GPL+ headers instead
     of GPLv3+ headers... but they don't actually get built into the package,
     so I think the GPLv3+ license tag is fine).

[x]: License file installed when any subpackage combination is installed.
[x]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/lib64/gnushogi
[!]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/lib64/gnushogi
[x]: Package does not own files or directories owned by other packages.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Texinfo files are installed using install-info in %post and %preun if
     package has .info files.
     Note: Texinfo .info file(s) in gnushogi
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 81920 bytes in 10 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: 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 %license.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[x]: Uses parallel make %{?_smp_mflags} macro.
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[-]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     gnushogi-debuginfo , gnushogi-debugsource
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: There are rpmlint messages (see attachment).
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Package should not use obsolete m4 macros
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: gnushogi-1.5-0.3.git5bb0b5b.fc28.x86_64.rpm
          gnushogi-debuginfo-1.5-0.3.git5bb0b5b.fc28.x86_64.rpm
          gnushogi-debugsource-1.5-0.3.git5bb0b5b.fc28.x86_64.rpm
          gnushogi-1.5-0.3.git5bb0b5b.fc28.src.rpm
gnushogi.x86_64: W: spelling-error Summary(en_US) Shogi -> Hoggish
gnushogi.x86_64: W: spelling-error %description -l en_US shogi -> hoggish
gnushogi.x86_64: W: spelling-error %description -l en_US frontend -> fronted, front end, front-end
gnushogi.x86_64: W: only-non-binary-in-usr-lib
gnushogi.x86_64: W: no-manual-page-for-binary gnuminishogi
gnushogi-debuginfo.x86_64: E: useless-provides debuginfo(build-id)
gnushogi-debugsource.x86_64: W: no-documentation
gnushogi.src: W: spelling-error Summary(en_US) Shogi -> Hoggish
gnushogi.src: W: spelling-error %description -l en_US shogi -> hoggish
gnushogi.src: W: spelling-error %description -l en_US frontend -> fronted, front end, front-end
4 packages and 0 specfiles checked; 1 errors, 9 warnings.




Rpmlint (debuginfo)
-------------------
Checking: gnushogi-debuginfo-1.5-0.3.git5bb0b5b.fc28.x86_64.rpm
gnushogi-debuginfo.x86_64: E: useless-provides debuginfo(build-id)
1 packages and 0 specfiles checked; 1 errors, 0 warnings.





Rpmlint (installed packages)
----------------------------
sh: /usr/bin/python: No such file or directory
gnushogi-debuginfo.x86_64: W: invalid-url URL: https://www.gnu.org/software/gnushogi <urlopen error [Errno -2] Name or service not known>
gnushogi-debuginfo.x86_64: E: useless-provides debuginfo(build-id)
gnushogi.x86_64: W: spelling-error Summary(en_US) Shogi -> Hoggish
gnushogi.x86_64: W: spelling-error %description -l en_US shogi -> hoggish
gnushogi.x86_64: W: spelling-error %description -l en_US frontend -> fronted, front end, front-end
gnushogi.x86_64: W: invalid-url URL: https://www.gnu.org/software/gnushogi <urlopen error [Errno -2] Name or service not known>
gnushogi.x86_64: W: only-non-binary-in-usr-lib
gnushogi.x86_64: W: no-manual-page-for-binary gnuminishogi
gnushogi-debugsource.x86_64: W: invalid-url URL: https://www.gnu.org/software/gnushogi <urlopen error [Errno -2] Name or service not known>
gnushogi-debugsource.x86_64: W: no-documentation
3 packages and 0 specfiles checked; 1 errors, 9 warnings.



Requires
--------
gnushogi-debuginfo (rpmlib, GLIBC filtered):

gnushogi (rpmlib, GLIBC filtered):
    /bin/sh
    info
    libc.so.6()(64bit)
    libm.so.6()(64bit)
    libncurses.so.6()(64bit)
    libtinfo.so.6()(64bit)
    rtld(GNU_HASH)

gnushogi-debugsource (rpmlib, GLIBC filtered):



Provides
--------
gnushogi-debuginfo:
    debuginfo(build-id)
    gnushogi-debuginfo
    gnushogi-debuginfo(x86-64)

gnushogi:
    gnushogi
    gnushogi(x86-64)

gnushogi-debugsource:
    gnushogi-debugsource
    gnushogi-debugsource(x86-64)



Source checksums
----------------
https://git.savannah.gnu.org/cgit/gnushogi.git/snapshot/gnushogi-5bb0b5b2f6953b3250e965c7ecaf108215751a74.tar.gz :
  CHECKSUM(SHA256) this package     : 3d3e4c0d7ce29cd0c18bcd2020a7330dd7d4b15b18b08ec493fffa13cc92a5f9
  CHECKSUM(SHA256) upstream package : 3d3e4c0d7ce29cd0c18bcd2020a7330dd7d4b15b18b08ec493fffa13cc92a5f9


Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02
Command line :/usr/bin/fedora-review -n gnushogi -m fedora-rawhide-x86_64
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Comment 24 Chen Chen 2018-02-09 04:07:49 UTC
Spec URL: https://github.com/aflyhorse/gnushogi-spec/raw/master/gnushogi.spec
SRPM URL: https://www.lunes.faith/SRPMS/gnushogi-1.5-0.4.git5bb0b5b.fc26.src.rpm
Koji URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=24862124

I need some time to prepare for lib patch. spec is modified as requested.
As this is probably the final commitment, package is also submitted on koji.

Online diff: https://github.com/aflyhorse/gnushogi-spec/commit/ce0bcae2da6118ea036ca5756911c1984b2e96ee

Comment 25 Ben Rosser 2018-02-12 16:37:36 UTC
Great, package is approved!

I have also gone ahead and sponsored you into packagers. If you have any future questions about packaging feel free to send me an email, or ask me on IRC (my username in Fedora IRC channels is TC01).

You can now follow the remaining steps in this wiki article to get gnushogi imported and built:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Add_Package_to_Source_Code_Management_.28SCM.29_system_and_Set_Owner

Comment 26 Gwyn Ciesla 2018-02-23 13:21:48 UTC
(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/gnushogi

Comment 27 Fedora Update System 2018-04-29 08:26:59 UTC
gnushogi-1.5-0.4.git5bb0b5b.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3e2d391d65

Comment 28 Fedora Update System 2018-04-29 08:39:12 UTC
gnushogi-1.5-0.4.git5bb0b5b.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4cf89ccb28

Comment 29 Fedora Update System 2018-04-30 01:18:07 UTC
gnushogi-1.5-0.4.git5bb0b5b.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-4cf89ccb28

Comment 30 Fedora Update System 2018-04-30 14:16:48 UTC
gnushogi-1.5-0.4.git5bb0b5b.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-3e2d391d65

Comment 31 Fedora Update System 2018-05-16 13:06:13 UTC
gnushogi-1.5-0.4.git5bb0b5b.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 32 Fedora Update System 2018-05-16 13:44:45 UTC
gnushogi-1.5-0.4.git5bb0b5b.fc27 has been pushed to the Fedora 27 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.