Bug 905379 - Man-pages of wesnoth are in wrong directories and not gzipped
Summary: Man-pages of wesnoth are in wrong directories and not gzipped
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: wesnoth
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-29 09:50 UTC by Mike FABIAN
Modified: 2013-08-15 02:43 UTC (History)
5 users (show)

Fixed In Version: wesnoth-1.10.6-7.fc19
Clone Of:
Environment:
Last Closed: 2013-08-15 02:41:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
list of man pages for wesnoth-data-1.10.6-4.fc19.noarch (2.65 KB, text/plain)
2013-07-29 02:53 UTC, Steve Tyler
no flags Details
proposed wesnoth-1.10.6-6.spec.patch (617 bytes, patch)
2013-07-31 03:55 UTC, Steve Tyler
no flags Details | Diff
proposed wesnoth-1.10.6-6.spec.patch (v2) (747 bytes, patch)
2013-07-31 12:22 UTC, Steve Tyler
no flags Details | Diff
wesnoth-data-1.10.6-7-man-pages-1.txt (7.93 KB, text/plain)
2013-07-31 15:37 UTC, Steve Tyler
no flags Details
wesnoth-data-1.10.6-7-man-pages-1.txt (v2) (5.43 KB, text/plain)
2013-08-01 15:57 UTC, Steve Tyler
no flags Details
another proposed wesnoth.spec (19.91 KB, text/plain)
2013-08-01 16:48 UTC, Will Woods
no flags Details
wesnoth-1.10.6 man page directory structure from upstream (8.78 KB, text/plain)
2013-08-01 17:39 UTC, Steve Tyler
no flags Details

Description Mike FABIAN 2013-01-29 09:50:28 UTC
$ rpm -ql wesnoth-data | grep /usr/share/man/fr
/usr/share/man/fr
/usr/share/man/fr/man6
/usr/share/man/fr/wesnoth.6
/usr/share/man/fr/wesnothd.6
mfabian@ari:~
$ file /usr/share/man/fr/man6
/usr/share/man/fr/man6: directory
mfabian@ari:~
$ 

The manpage, wesnoth.6 should be gzipped to wesnoth.6.gz and it should
be in /usr/share/man/fr/man6/wesnoth.6.gz

Same for all languages.

Same problem in Fedora 17 and Fedora 18.

Comment 1 Fedora Update System 2013-02-04 18:38:28 UTC
wesnoth-1.10.5-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/wesnoth-1.10.5-3.fc18

Comment 2 Fedora Update System 2013-02-05 16:52:02 UTC
Package wesnoth-1.10.5-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing wesnoth-1.10.5-3.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1954/wesnoth-1.10.5-3.fc18
then log in and leave karma (feedback).

Comment 3 Fedora Update System 2013-02-14 02:32:05 UTC
wesnoth-1.10.5-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 4 Steve Tyler 2013-07-25 08:30:59 UTC
The wesnoth-data package and the filesystem package both own /usr/share/man/en_GB/:

$ rpm -qf /usr/share/man/en_GB/
filesystem-3.1-2.fc18.x86_64
wesnoth-data-1.10.5-3.fc18.noarch

This can cause kickstart install failures:

Bug 911877 - f18 installer isn't able install bigger packages? 
Bug 987735 - error: unpacking of archive failed on file /usr/share/man/de/man8/fatlabel.8.gz;51e5abf4: cpio: open failed - No such file or directory

I suggest reopening ...

Comment 5 Gwyn Ciesla 2013-07-25 13:00:18 UTC
I'm not sure this is a wesnoth issue.  Multiple packages owning a directory isn't a problem, in fact packages should own directories they ship files in if the don't directly require the package that provides it.

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

Is a package installed by the kickstart requiring a directory by path that's provided by both wesnoth-data and filesystem, which gets satisfied by wesnoth-data, but also needs a directory that filesystem provides, and is not provided by wesnoth-data?  Maybe that package simply needs to Require filesystem.

Comment 6 Steve Tyler 2013-07-25 14:54:08 UTC
Thanks for the link, Jon. This bug concerns filesystem and man directories:

"Directory ownership is a little more complex than file ownership. Packages must own all directories they put files in, except for:

    any directories owned by the filesystem, man, or other explicitly created -filesystem packages"

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

$ rpm -ql filesystem | grep man | wc -l
13293

Comment 7 Gwyn Ciesla 2013-07-25 15:43:31 UTC
D'oh, I forgot about that.  I see the issue.  Can you open a new BZ for this please, it's a separate problem.  I'll start on the fix now.  Thanks!

Comment 8 Steve Tyler 2013-07-25 15:58:50 UTC
Bug 988456 - wesnoth-data owns some man page directories

Comment 9 Steve Tyler 2013-07-25 17:05:16 UTC
(In reply to Jon Ciesla from comment #7)
> D'oh, I forgot about that.  I see the issue.  Can you open a new BZ for this
> please, it's a separate problem.  I'll start on the fix now.  Thanks!

Man page ownership should be checked by AutoQA, so packagers don't have to remember everything ... :-)

Jaroslav: Could the script you mention in Bug 569392, Comment 7 be integrated with AutoQA?

Comment 10 Steve Tyler 2013-07-26 18:46:49 UTC
While testing the fix for Bug 988456, I noticed two files in the wrong place:

$ ls -1 /usr/share/man/wesnoth*
/usr/share/man/wesnoth.6.gz
/usr/share/man/wesnothd.6.gz

[joeblow@f18-test-1 ~]$ rpm -qf /usr/share/man/wesnoth.6.gz 
wesnoth-data-1.10.6-4.fc18.noarch
[joeblow@f18-test-1 ~]$ rpm -qf /usr/share/man/wesnothd.6.gz 
wesnoth-data-1.10.6-4.fc18.noarch

Comment 11 Steve Tyler 2013-07-26 19:04:38 UTC
These man pages appear to be in the wrong place:

[joeblow@f18-test-1 ~]$ ls -1F /usr/share/man/en_GB/
man1/
man6/
wesnoth.6.gz
wesnothd.6.gz
[joeblow@f18-test-1 ~]$ ls -1F /usr/share/man/en_GB/man1
[joeblow@f18-test-1 ~]$ ls -1F /usr/share/man/en_GB/man6
[joeblow@f18-test-1 ~]$ rpm -qf /usr/share/man/en_GB/wesnoth.6.gz 
wesnoth-data-1.10.6-4.fc18.noarch
[joeblow@f18-test-1 ~]$ rpm -qf /usr/share/man/en_GB/wesnothd.6.gz 
wesnoth-data-1.10.6-4.fc18.noarch

Comment 12 Steve Tyler 2013-07-26 20:50:26 UTC
The build.log doesn't show any man page mv's being invoked.

Snippet from build.log:
http://kojipkgs.fedoraproject.org//work/tasks/232/5660232/build.log
...
+ pushd doc
+ pushd man
+ rm CMakeLists.txt
+ for i in '*/'
+ mkdir af//man6
+ '[' -f '*.6' ']' <<<<<<<<<<
+ for i in '*/'
...

Snippet from wesnoth.spec:
http://pkgs.fedoraproject.org/cgit/wesnoth.git/tree/wesnoth.spec#n189
...
mkdir -p $RPM_BUILD_ROOT/%{_mandir}/man6
pushd doc
pushd man
rm CMakeLists.txt
#rm cmake_install.cmake
#rm -rf CMakeFiles/
#rm Makefile
#mv *.6 $RPM_BUILD_ROOT/%{_mandir}/man6/
for i in */; do
	mkdir $i/man6
	if [ -f "*.6" ]; then   <<<<<<<<<<
		mv *.6 $i/man6/ <<<<<<<<<<
	fi
done
popd
popd
...

Information for task buildArch (wesnoth-1.10.6-4.fc18.src.rpm, x86_64)
ID	5660232
http://koji.fedoraproject.org/koji/taskinfo?taskID=5660232

Comment 13 Steve Tyler 2013-07-26 21:29:03 UTC
That test appears to always return false:

$ ls
bar1.6  bar2.6
$ [ -f "*.6" ]
$ echo $?
1
$ [ -f "*.7" ]
$ echo $?
1

Comment 14 Steve Tyler 2013-07-28 22:02:55 UTC
CCing Will Woods:

Will, your dracut url-lib.sh code makes you a shell expert, IMO.
Could you take a look at these? 
The "mv"s are not getting invoked (Comment 12 has more details.).

http://kojipkgs.fedoraproject.org//work/tasks/232/5660232/build.log
http://pkgs.fedoraproject.org/cgit/wesnoth.git/tree/wesnoth.spec#n189

Comment 15 Steve Tyler 2013-07-29 02:53:29 UTC
Created attachment 779568 [details]
list of man pages for wesnoth-data-1.10.6-4.fc19.noarch

$ rpm -ql wesnoth-data | grep /usr/share/man

Comment 16 Steve Tyler 2013-07-29 03:42:48 UTC
(In reply to Steve Tyler from comment #15)
> Created attachment 779568 [details]
> list of man pages for wesnoth-data-1.10.6-4.fc19.noarch
> 
> $ rpm -ql wesnoth-data | grep /usr/share/man

Based on these results, this bug should be reopened.

Comment 17 Gwyn Ciesla 2013-07-29 15:04:17 UTC
Unpushed the updates.

Comment 18 Steve Tyler 2013-07-29 16:23:44 UTC
Will may be busy, so here is an approach that I tested:

$ cat x.sh
#!/bin/bash

f=$(find * -prune -type f -name '*.6')
if [ ${#f} != 0 ]; then
  echo mv $f man6
fi

NB: The "echo" is for testing only.

Tested with this directory structure and with '*.6', '*.7', '*.8':

$ ls -1RF
.:
man6/
x1.6
x2.6
x.sh*
y1.7

./man6:
man6-file1.6

Comment 19 Steve Tyler 2013-07-29 17:49:29 UTC
These aren't getting moved:
/usr/share/man/wesnoth.6.gz
/usr/share/man/wesnothd.6.gz

into:
/usr/share/man/man6

There needs to be another "mv" for them.

Uncommenting line 196 below looks like it would work.
(This assumes that there are no directories matching "*.6".)

Snippet from wesnoth-1.10.6.spec:
...
    189 mkdir -p $RPM_BUILD_ROOT/%{_mandir}/man6
    190 pushd doc
    191 pushd man
    192 rm CMakeLists.txt
    193 #rm cmake_install.cmake
    194 #rm -rf CMakeFiles/
    195 #rm Makefile
    196 #mv *.6 $RPM_BUILD_ROOT/%{_mandir}/man6/
    197 for i in */; do
    198         mkdir $i/man6
    199         if [ -f "*.6" ]; then
    200                 mv *.6 $i/man6/
    201         fi
    202 done
    203 popd
    204 popd
...

Comment 20 Gwyn Ciesla 2013-07-30 18:37:45 UTC
See if this rawhide build implementing your suggestions is OK.  x86 and i686 are done, armv7hl is still going.

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

If so, I'll push through to f19 and f18.

Comment 21 Gwyn Ciesla 2013-07-30 18:38:11 UTC
Whoops, I dropped a _64. :)

Comment 22 Steve Tyler 2013-07-30 18:58:43 UTC
Thanks for the update.

The top-level mv appears to have worked, but none of the others did ...

Snippet from http://kojipkgs.fedoraproject.org//work/tasks/244/5680244/build.log
...
+ mkdir -p /builddir/build/BUILDROOT/wesnoth-1.10.6-6.fc20.x86_64//usr/share/man/man6
~/build/BUILD/wesnoth-1.10.6/doc ~/build/BUILD/wesnoth-1.10.6
~/build/BUILD/wesnoth-1.10.6/doc/man ~/build/BUILD/wesnoth-1.10.6/doc ~/build/BUILD/wesnoth-1.10.6
+ pushd doc
+ pushd man
+ rm CMakeLists.txt
+ mv wesnoth.6 wesnothd.6 /builddir/build/BUILDROOT/wesnoth-1.10.6-6.fc20.x86_64//usr/share/man/man6/
++ find af ang ang@latin ar bg ca ca_ES@valencia cs da de el en@shaw en_GB eo es et eu fi fr fur_IT ga gd gl he hr hu id it ja ko la lt lv mk mr nb_NO nl pl pt pt_BR racv ro ru sk sl sr sr@ijekavian sr@ijekavianlatin sr@latin sv tl tr uk vi zh_CN zh_TW -prune -type f -name '*.6'
~/build/BUILD/wesnoth-1.10.6/doc ~/build/BUILD/wesnoth-1.10.6
~/build/BUILD/wesnoth-1.10.6
+ f=
+ '[' 0 '!=' 0 ']'
+ popd
+ popd
...

Information for task buildArch (wesnoth-1.10.6-6.fc20.src.rpm, x86_64)
http://koji.fedoraproject.org/koji/taskinfo?taskID=5680244

Comment 23 Steve Tyler 2013-07-30 19:07:46 UTC
You need to keep the for loop and the mkdir.
The example in Comment 18 isn't a patch ... :-)

Before you start another build, attach your proposed commit as a patch, so I can review it. 

http://pkgs.fedoraproject.org/cgit/wesnoth.git/commit/?id=957be24d8d7ca7611a158d3a5639bfe7be286fc8

Comment 24 Steve Tyler 2013-07-31 03:55:58 UTC
Created attachment 780918 [details]
proposed wesnoth-1.10.6-6.spec.patch

After downloading the wesnoth source tar file, I found that some of the man page directories are in fact empty. This patch assumes that a man6 subdirectory does not need to be created, if there are no *.6 man pages present.

Comment 25 Steve Tyler 2013-07-31 12:22:25 UTC
Created attachment 781077 [details]
proposed wesnoth-1.10.6-6.spec.patch (v2)

This patch avoids creating a man/man6/man6/ directory and removes commented-out code.

The monolithic spec file makes it difficult to do unit tests, so I guess there needs to be a test build ...

F20/x86_64 should suffice.

Comment 26 Gwyn Ciesla 2013-07-31 14:45:42 UTC
Ok, have a look at http://fedorapeople.org/~limb/wesnoth/

I had to add back in mkdir -p $RPM_BUILD_ROOT/%{_mandir}.

Comment 27 Steve Tyler 2013-07-31 15:37:56 UTC
Created attachment 781200 [details]
wesnoth-data-1.10.6-7-man-pages-1.txt

Thanks. I noticed the "mkdir -p", but overlooked the subsequent:
cp -pr doc/man/* $RPM_BUILD_ROOT/%{_mandir}

The man directories and files look OK:
$ rpm -qlv -p wesnoth-data-1.10.6-7.fc20.noarch.rpm | grep /usr/share/man > wesnoth-data-1.10.6-7-man-pages-1.txt

Comment 28 Steve Tyler 2013-07-31 15:50:25 UTC
The man pages fail this consistency test:

$ cat wesnoth-data-1.10.6-7-man-pages-1.txt | grep '^d' | wc -l
28

$ cat wesnoth-data-1.10.6-7-man-pages-1.txt | grep -v '^d' | wc -l
53

There should be 2*28 = 56 man page files (two per directory).

Comment 29 Gwyn Ciesla 2013-07-31 16:05:17 UTC
I think 53 is correct, that's how many are in the tarball.  I think some simply have not been translated.  But the ownership looks good?

Comment 30 Steve Tyler 2013-07-31 16:12:50 UTC
OK, then that is an upstream problem and not ours ... :-)

I will need a while to check ownership -- have to do a rawhide install in a VM.

BTW, the spec file could use some white-space cleanup. It is inconsistently using spaces and tabs.

The packaging guidelines don't say anything about indentation, but I was using 4-space indenting. Maybe the packaging guidelines should have a coding style section:

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

Comment 31 Gwyn Ciesla 2013-07-31 16:53:13 UTC
Yeah, I know, it's old and been through the wringer.  I'll clean it up for 1.12.x.

Let me know when you've checked ownership.

Comment 32 Steve Tyler 2013-07-31 19:07:47 UTC
(In reply to Jon Ciesla from comment #31)
...
> Let me know when you've checked ownership.

Bug 988456, Comment 10.

Comment 33 Steve Tyler 2013-08-01 15:57:33 UTC
Created attachment 781666 [details]
wesnoth-data-1.10.6-7-man-pages-1.txt (v2)

Verifying that the wesnoth-data-1.10.6-7 (v2) package has no man page directories:

$ cat wesnoth-data-1.10.6-7-man-pages-1.txt | wc -l
53

Generated on F20 test system with:
# rpm -q wesnoth-data
wesnoth-data-1.10.6-7.fc20.noarch
# rpm -qlv wesnoth-data | grep /usr/share/man > wesnoth-data-1.10.6-7-man-pages-1.txt

Comment 34 Will Woods 2013-08-01 16:48:09 UTC
Created attachment 781670 [details]
another proposed wesnoth.spec

Most of the time, my response to "How do I make [some complicated thing] work in bash?" ends up being "Don't do it in bash."

In this particular case: why are you fighting the package's build system?

This seems to work just as well:


%build
scons all prefix=%{_prefix} \
          bindir=%{_bindir} \
          libdir=%{_libdir} \
          localedirname=locale \
          python_site_packages_dir=%{python_sitelib}/%{name} \
          extra_flags_release="$RPM_OPT_FLAGS $RPM_LD_FLAGS" \
          %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT
scons install install-pytools destdir=$RPM_BUILD_ROOT

# extra files we provide
install -Dpm 644 %{SOURCE1} $RPM_BUILD_ROOT%{_unitdir}/wesnothd.service
install -Dpm 644 %{SOURCE2} $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig/wesnoth

# create this so we can %ghost it
touch ${RPM_BUILD_ROOT}/var/run/wesnothd/socket

# move server stuff into sbindir
mkdir -p $RPM_BUILD_ROOT/%{_sbindir}
mv $RPM_BUILD_ROOT/%{_bindir}/wesnothd $RPM_BUILD_ROOT/%{_sbindir}
mv $RPM_BUILD_ROOT/%{_bindir}/campaignd $RPM_BUILD_ROOT/%{_sbindir}

# language stuff
%find_lang %{name} LANGFILES --with-man


%post
[...]

AFAICT this produces nearly the same RPM contents; the main difference is that it keeps the wesnoth-provided fonts.

You'd need to change the %files sections only slightly:

 %files
-%doc COPYING changelog README copyright doc/manual/
+%doc COPYING changelog README copyright
+%docdir %{_docdir}/wesnoth
+%{_docdir}/wesnoth

[...]

 %files server
 #%%config %%{_initrddir}/wesnothd
 %{_unitdir}/wesnothd.service
 %config(noreplace) %{_sysconfdir}/sysconfig/wesnoth
 %{_sbindir}/wesnothd
+%{_sbindir}/campaignd
 %attr(0700,wesnothd,wesnothd) %dir /var/run/wesnothd/
 %ghost /var/run/wesnothd/socket

[...]

-%files data -f %{name}*.*.lang
+%files data -f LANGFILES
 %{_datadir}/%{name}
 %{_datadir}/applications/wesnoth.desktop
-%{_datadir}/pixmaps/*
-%{_datadir}/fonts/*
+%{_datadir}/icons/*
 %{python_sitelib}/wesnoth
[...]

(what's with that goofy "%{name}*.*.lang" filename, anyway?)

You can clean that whole %files data block up to just:

%files data -f LANGFILES
%{_datadir}/%{name}
%{_datadir}/applications/wesnoth.desktop
%{_datadir}/icons/*
%{python_sitelib}/wesnoth
%{_mandir}/man6/wesnoth*.6.gz
%{_mandir}/*/man6/wesnoth*.6.gz


All of which would make the spec a *lot* cleaner - plus it'll build much faster on multiprocessor machines, since it's using %{?_smp_mflags}.

Anyway, the spec is attached. Feel free to use it, take inspiration from it, or just ignore it.

Comment 35 Fedora Update System 2013-08-01 17:34:46 UTC
wesnoth-1.10.6-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/wesnoth-1.10.6-7.fc19

Comment 36 Fedora Update System 2013-08-01 17:35:05 UTC
wesnoth-1.10.6-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/wesnoth-1.10.6-7.fc18

Comment 37 Gwyn Ciesla 2013-08-01 17:36:10 UTC
Honestly, because when I first started on this branch, that didn't work, and was poorly documented.  I'll incorporate this in the next iteration.  Thank you!

Comment 38 Steve Tyler 2013-08-01 17:39:10 UTC
Created attachment 781686 [details]
wesnoth-1.10.6 man page directory structure from upstream

Thanks, Will. That's way more than I was asking for and much better too.

The upstream man pages are basically in the wrong places, hence the shell script to move them. The attached file shows the man page directory structure from upstream. These are the only lines in the spec file that directly pertain to man pages, so are the man pages being mv'ed some other way? Or is there a better way to mv them using the packaging system? There is also a CMakeLists.txt file that needs to be removed.

%{_mandir}/man6/wesnoth*.6.gz
%{_mandir}/*/man6/wesnoth*.6.gz

Attached file generated with:
$ tar -tvf wesnoth-1.10.6.tar wesnoth-1.10.6/doc/man > tar-tvf-wesnoth-1.10.6-doc-man-1.txt

Jon: You know way more about this than I do, so please correct me if I said anything wrong.

Comment 39 Steve Tyler 2013-08-02 08:48:41 UTC
(In reply to Steve Tyler from comment #38)
> ... so are the man pages being mv'ed some other
> way? ...

Freely admitting my ignorance until now of "scons": http://www.scons.org
Thanks for the inspiration, Will.

$ less -N wesnoth-1.10.6/SConstruct
...
    539 def InstallManpages(env, component):
    540     env.InstallData("mandir", component, os.path.join("doc", "man", component + ".6"), "man6")
    541     for lingua in linguas:
    542         manpage = os.path.join("doc", "man", lingua, component + ".6")
    543         env.InstallData("mandir", component, manpage, os.path.join(lingua, "man6"))
...

At first, I thought "scons" had something to do with LISP: :-)
LISP 1.5 Programmer's Manual
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf

Comment 40 Steve Tyler 2013-08-02 09:30:32 UTC
(In reply to Jon Ciesla from comment #37)
> Honestly, because when I first started on this branch, that didn't work, and
> was poorly documented.  I'll incorporate this in the next iteration.  Thank
> you!

Bug 991376 - RFE: convert wesnoth.spec file to use scons

Comment 41 Will Woods 2013-08-02 17:58:37 UTC
(In reply to Steve Tyler from comment #39)

> Freely admitting my ignorance until now of "scons": http://www.scons.org
> Thanks for the inspiration, Will.

I'd never heard of it either. I just read the INSTALL file.

Comment 42 Fedora Update System 2013-08-02 21:53:41 UTC
Package wesnoth-1.10.6-7.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing wesnoth-1.10.6-7.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-14087/wesnoth-1.10.6-7.fc19
then log in and leave karma (feedback).

Comment 43 Steve Tyler 2013-08-02 22:05:56 UTC
(In reply to Will Woods from comment #41)
> (In reply to Steve Tyler from comment #39)
> 
> > Freely admitting my ignorance until now of "scons": http://www.scons.org
> > Thanks for the inspiration, Will.
> 
> I'd never heard of it either. I just read the INSTALL file.

LOL. You were more efficient than I was then: googling and grepping ... :-)

I completed a test package build with your spec file and it appears to have worked great. Followups are in Bug 991376.

Comment 44 Fedora Update System 2013-08-15 02:41:33 UTC
wesnoth-1.10.6-7.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 45 Fedora Update System 2013-08-15 02:43:49 UTC
wesnoth-1.10.6-7.fc19 has been pushed to the Fedora 19 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.