Bug 211626 - Review Request: xtide - Calculate tide all over the world
Review Request: xtide - Calculate tide all over the world
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Package Reviews List
: Reopened
: 211623 211625 (view as bug list)
Depends On: 212258 217277
Blocks: FE-ACCEPT 217279
  Show dependency treegraph
 
Reported: 2006-10-20 10:52 EDT by Mamoru TASAKA
Modified: 2009-09-14 01:10 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-27 09:54:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
kevin: fedora‑cvs+


Attachments (Terms of Use)
modified tcd-utils Makefile patch which adds LDFLAGS. (864 bytes, patch)
2006-10-21 09:51 EDT, Patrice Dumas
no flags Details | Diff
test for conf file only if there is a need for the default file (575 bytes, patch)
2006-10-21 21:21 EDT, Patrice Dumas
no flags Details | Diff
use CFLAGS set by the user (2.51 KB, patch)
2006-10-21 21:22 EDT, Patrice Dumas
no flags Details | Diff
Availability and installation of harmonics files README (1.54 KB, text/plain)
2006-10-23 10:35 EDT, Patrice Dumas
no flags Details
ideEditor-wrapper.sh (fixed) (1.07 KB, text/plain)
2006-10-25 16:13 EDT, Mamoru TASAKA
no flags Details
alternative xttpd to write (1.57 KB, text/plain)
2006-10-26 06:31 EDT, Mamoru TASAKA
no flags Details
minor change to remove unneeded substitutions of nobody by xttpd (2.49 KB, patch)
2006-10-27 18:04 EDT, Patrice Dumas
no flags Details | Diff

  None (edit)
Description Mamoru TASAKA 2006-10-20 10:52:29 EDT
Spec URL: http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
SRPM URL: http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.1.dev20061015.src.rpm
Description: 
XTide is a package that provides tide and current
predictions in a wide variety of formats.  Graphs, text listings, and
calendars can be generated, or a tide clock can be provided on your
desktop.

XTide can work with X-windows, plain text terminals, or the web.  This
is accomplished with three separate programs: the interactive
interface (xtide), the non-interactive or command line interface
(tide), and the web interface (xttpd).

The algorithm that XTide uses to predict tides is the one used by the
National Ocean Service in the U.S.  It is significantly more accurate
than the simple tide clocks that can be bought in novelty stores.
However, it takes more to predict tides accurately than just a spiffy
algorithm -- you also need some special data for each and every
location for which you want to predict tides.  XTide reads this data
from harmonics files.  See http://www.flaterco.com/xtide/files.html
for details on where to get these.

Ultimately, XTide's predictions can only be as good as the available
harmonics data.  Due to issues of data availability and of
compatibility with non-U.S. tide systems, the predictions for
U.S. locations tend to be a lot better on average than those for
locations outside of the U.S.  It is up to you to verify that the
predictions for your locale match up acceptably well with the
officially sanctioned ones.

    * Deviations of 1 minute from official predictions are typical for
      U.S. locations having the latest data.

    * Deviations of 20 minutes are typical for non-U.S. locations or
      U.S. locations that are using obsolete data.

    * Much longer deviations indicate a problem.

--------------------------------------------------------------------
Note: xtide seems to have been included in Fedora Extras by FE4,
however, it seems that this package got orphaned by FE5.

I submitted new re-review request because
* More than one year passed since this package got orphaned.
* I changed the dependency for this package.
Comment 1 Mamoru TASAKA 2006-10-21 06:12:29 EDT
Once close, then reopen because I cannot get back the status
of this bug to NEW .
Comment 2 Patrice Dumas 2006-10-21 06:43:30 EDT
If I understand well, libtcd is needed for tcd-utils, and tcd-utils
is needed to create the harmonics*.tcd required by xtide at
runtime.

The sane thing would be a packaging of libtcd in his own tarball
upstream. Could it be possible to convince upstream?

In the mean time, with the current upstream organization, I think that 
the 3 must be packaged together.
Comment 3 Mamoru TASAKA 2006-10-21 07:09:10 EDT
(In reply to comment #2)
> If I understand well, libtcd is needed for tcd-utils, and tcd-utils
> is needed to create the harmonics*.tcd required by xtide at
> runtime.

Yes. Surely as you said.

> The sane thing would be a packaging of libtcd in his own tarball
> upstream. Could it be possible to convince upstream?

Well, upstream used to distribute libtcd package, however 
upstream seems to have stopped it perhaps because it is
convenient?

Well, upstream distribute harminocs*.tcd binary directory.
If using it tcd-utils is not needed for xtide, however, I think
including binaries such as some data should be avoid if it is
possible.

> 
> In the mean time, with the current upstream organization, I think that 
> the 3 must be packaged together.

Umm, you also think so? Well, actually "all in once" srpm and spec are
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide-unified.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.2.dev20061015.src.rpm

( For a moment I changed spec file's name so that you can browser
  another xtide.spec file (not unified version) and srpm under
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/ ).


Comment 4 Mamoru TASAKA 2006-10-21 07:12:07 EDT
*** Bug 211623 has been marked as a duplicate of this bug. ***
Comment 5 Mamoru TASAKA 2006-10-21 07:13:27 EDT
*** Bug 211625 has been marked as a duplicate of this bug. ***
Comment 6 Patrice Dumas 2006-10-21 09:49:28 EDT
It seems to me that it should be (with 0 instead of 1)
%define          libtcd_rel       0.%{fedora_rel}
%define          tcdutils_rel     0.%{fedora_rel}.date%{tcdutils_date2}



For libtcd
instead of 
export CC="gcc `rpm --eval %%optflags` -DCOMPAT114"
there should be something along 
%{__make} %{?_smp_mflags} \
  OPTFLAGS="$RPM_OPT_FLAGS -DCOMPAT114" \
......

For xtide
-L/usr/lib shouldn't be there, it is allready on the linker path.
(and anyway it should be -L%{_libdir})
-L./libtcd is certainly unneeded in extracxxflags

`rpm --eval %%optflags` should be replaced by %{optflags}, rpm
shouldn't be called explicitely.

The 
/sbin/ldconfig $(pwd)/libtcd || :
is very dubious. In my opinion it shouldn't be there.

You should use consistently %optflags and $RPM_BUILD_ROOT.

I propose the following for tcd-utils:
%{__make} %{?_smp_mflags} \
  CXXFLAGS="$RPM_OPT_FLAGS -I../libtcd -DCOMPAT114" \
  CFLAGS="$RPM_OPT_FLAGS -I../libtcd -DCOMPAT114" \
  LDFLAGS="-L../libtcd"
together with the modified tcd-utils-1.3.7-shared.patch I'll attach,
which adds LDFLAGS. 

I don't see why the somajor/minor/ver should be different from 0.0.0.
Comment 7 Patrice Dumas 2006-10-21 09:51:00 EDT
Created attachment 139055 [details]
modified tcd-utils Makefile patch which adds LDFLAGS.
Comment 8 Michael Schwendt 2006-10-21 10:14:51 EDT
> # local user fails on writing ld.so.cache file
> /sbin/ldconfig $RPM_BUILD_ROOT%{_libdir} || :

Um, no. You don't want to update the ld.so cache at all. The original
suggestion in bug 211623 was to run ldconfig with option -n to make
it create the necessary symlink reliably based on the soname it finds,
instead of overloading your spec file with many many many sed expressions
which try to get the library versions right.

Paving spec files with macros and inline substitutions creates more
trouble than it helps decreasing maintenance requirements. Updating the
top of the spec file is non-trivial already due to a dozen non-obvious
macro definitions.
Comment 9 Mamoru TASAKA 2006-10-21 10:52:38 EDT
Well, before fixing this...

(In reply to comment #6)
> It seems to me that it should be (with 0 instead of 1)
> %define          libtcd_rel       0.%{fedora_rel}
> %define          tcdutils_rel     0.%{fedora_rel}.date%{tcdutils_date2}

Well, I have been troubled with versioning. Usually your proposition
is appropriate. However, "0." means (in fedora) "this is a pre or beta version"
and 
* by libtcd.html, xtide src includes the "formal" (what I mean is not pre)
  2.1.3 version.
* for tcdutils, this is actually not pre version.

> For libtcd
> instead of 
> export CC="gcc `rpm --eval %%optflags` -DCOMPAT114"
> there should be something along 
> %{__make} %{?_smp_mflags} \
>   OPTFLAGS="$RPM_OPT_FLAGS -DCOMPAT114" \
> ......
> 
> For xtide
> -L/usr/lib shouldn't be there, it is allready on the linker path.
> (and anyway it should be -L%{_libdir})
> -L./libtcd is certainly unneeded in extracxxflags
> 
> `rpm --eval %%optflags` should be replaced by %{optflags}, rpm
> shouldn't be called explicitely.
> 
> The 
> /sbin/ldconfig $(pwd)/libtcd || :
> is very dubious. In my opinion it shouldn't be there.
I thought that, however, without this I get:

+ LD_LIBRARY_PATH=/home/tasaka1/rpmbuild/BUILD/xtide-2.9dev/libtcd
+ ./tcd-utils/build_tide_db harmonics-2004-06-14.tcd harmonics-2004-06-14.txt
./tcd-utils/build_tide_db: error while loading shared libraries: libtcd.so.2:
cannot open shared object file: No such file or directory

> You should use consistently %optflags and $RPM_BUILD_ROOT.
Okay, I will fix.

> I propose the following for tcd-utils:
> %{__make} %{?_smp_mflags} \
>   CXXFLAGS="$RPM_OPT_FLAGS -I../libtcd -DCOMPAT114" \
>   CFLAGS="$RPM_OPT_FLAGS -I../libtcd -DCOMPAT114" \
>   LDFLAGS="-L../libtcd"
> together with the modified tcd-utils-1.3.7-shared.patch I'll attach,
> which adds LDFLAGS. 

Okay, I will check it later.

> I don't see why the somajor/minor/ver should be different from 0.0.0.
Umm, upstream has released libtcd version 1, which is API imcompatible
with version 2. Through version 2 libctd seems API compatible.
So I want to have SOMAJOR number 2 (and others similar).

How do you think of soname versioning?
 

(In reply to comment #8)
> > # local user fails on writing ld.so.cache file
> > /sbin/ldconfig $RPM_BUILD_ROOT%{_libdir} || :
> 
> Um, no. <snip> The original
> suggestion in bug 211623 was to run ldconfig with option -n to  ...
Okay. I will fix this.

-------------------------------------------------------------------------
In short:

Well, before fixing this, will you tell me how do you think of
A. libtcd and tcd-utils release numbering (0<->1)
B. libtcd.so share object loading problem
C. soname versioning 
?
Comment 10 Mamoru TASAKA 2006-10-21 10:54:16 EDT
Oh forgot, I will stop using %%optflags.
Comment 11 Patrice Dumas 2006-10-21 11:02:35 EDT
Some more comments:

* I noticed that in general you use pushd/popd, but at some places 
  you use cd.

* tideEditor needs to have a variable HFILE_PATH set (I guess for
  harmonic files localization?). So it certainly requires an /etc/profile.d
  file.

  it also certainly requires a .desktop and icon.

* in libtcd install a $f crept in

  I agree with Michael about how links should be done using ldonfig -n

* xttpd certainly would benefit from an init script. Regarding xttpd, could 
  you please look at some basic security issues, like which user the daemon
  runs at. It would certainly make sense to put xttpd in another package, it 
  is really a different beast from xtide.
Comment 12 Patrice Dumas 2006-10-21 11:34:54 EDT
(In reply to comment #9)


> > /sbin/ldconfig $(pwd)/libtcd || :
> > is very dubious. In my opinion it shouldn't be there.
> I thought that, however, without this I get:
> 
> + LD_LIBRARY_PATH=/home/tasaka1/rpmbuild/BUILD/xtide-2.9dev/libtcd
> + ./tcd-utils/build_tide_db harmonics-2004-06-14.tcd harmonics-2004-06-14.txt
> ./tcd-utils/build_tide_db: error while loading shared libraries: libtcd.so.2:
> cannot open shared object file: No such file or directory

Strange. It works for me when I go to the tcd-utils directory
and run it by hand. It gives me the error without LD_LIBRARY_PATH=


> > I don't see why the somajor/minor/ver should be different from 0.0.0.
> Umm, upstream has released libtcd version 1, which is API imcompatible
> with version 2. Through version 2 libctd seems API compatible.
> So I want to have SOMAJOR number 2 (and others similar).
>
> How do you think of soname versioning?

If I'm not wrong upstream has never release any dynamic library, they
may (in fact they should) begin with a soname of 0. The soname tracks
ABI incompatible changes, not API changes.
  

 
> -------------------------------------------------------------------------
> In short:
> 
> Well, before fixing this, will you tell me how do you think of
> A. libtcd and tcd-utils release numbering (0<->1)

libtcd 0., tcd-utils directly the release number

> B. libtcd.so share object loading problem

It works when doing things by hand, I'll try a rpmbuild.

> C. soname versioning 

Begin with 0 for soname and 0.0.0 for library.
Comment 13 Patrice Dumas 2006-10-21 11:45:23 EDT
(In reply to comment #12)

> Strange. It works for me when I go to the tcd-utils directory
> and run it by hand. It gives me the error without LD_LIBRARY_PATH=

I guess it worked because the directory was somehow in the cache.
That's strange.

The following seems to work:

LD_PRELOAD=$(pwd)/libtcd/libtcd.so \
   ./tcd-utils/build_tide_db $TCD harmonics-*.txt &>harmonics_build.out
Comment 14 Mamoru TASAKA 2006-10-21 11:58:56 EDT
(In reply to comment #11)
> Some more comments:
> * tideEditor needs to have a variable HFILE_PATH set (I guess for
>   harmonic files localization?). So it certainly requires an /etc/profile.d
>   file.
> 
>   it also certainly requires a .desktop and icon.

profile files and desktop files are useless for tideEditor because:
* HFILE_PATH should be under wher user has write access (For example,
  HFILE_PATH=/usr/share/xtide/harminocs-????.tcd tideEditor
  immediately exits).
* tideEditor surely requires HFILE_PATH environ. With no HFILE_PATH
  environ, this cannot be launched.

> * xttpd certainly would benefit from an init script. Regarding xttpd, could 
>   you please look at some basic security issues, like which user the daemon
>   runs at. It would certainly make sense to put xttpd in another package, it 
>   is really a different beast from xtide.

Currently I am checking debian's script.

(In reply to comment #12)
> > Well, before fixing this, will you tell me how do you think of
> > A. libtcd and tcd-utils release numbering (0<->1)
> libtcd 0., tcd-utils directly the release number

Well, when I directly use release number, i.e.
tcd-utils: 1.3.7-1  2  3  4  5 ...
xtide versioning become
2.9-dev 0.1.dev   0.2.dev..  0.3.dev.. 0.4.dev.. 
(then formal release) 5 (suddenly jump)

> > B. libtcd.so share object loading problem
> 
> It works when doing things by hand, I'll try a rpmbuild.
I will try preload
> 
> > C. soname versioning 
> 
> Begin with 0 for soname and 0.0.0 for library.
Well, for now I will apply this.

Comment 15 Michael Schwendt 2006-10-21 12:16:45 EDT
Slow.

No LD_PRELOAD hacks, please. All you need is the "libtcd.so.2" symlink,
as it is the SONAME the executables want at run-time. ldconfig creates
this symlink, when it finds libtcd.so.2.1.3 which is the full-version.
"man ldconfig" has the details on what option -n does and why the ld.so
cache is irrelevant in this case.

[...]

The SONAME versioning will only work if upstream (who is used to static
libs) is strict about keeping the API compatible and never removes
anything from it prior to v3 as that would break the ABI when using
a shared lib.
Comment 16 Mamoru TASAKA 2006-10-21 12:25:58 EDT
(In reply to comment #15)
> > No LD_PRELOAD hacks, please. All you need is the "libtcd.so.2" symlink,
> as it is the SONAME the executables want at run-time. ldconfig creates
> this symlink, when it finds libtcd.so.2.1.3 which is the full-version.
> "man ldconfig" has the details on what option -n does and why the ld.so
> cache is irrelevant in this case.

I switch back to
/sbin/ldconfig -n $(pwd)/libtcd/
LD_LIBRARY_PATH=(pwd)/libtcd/ \
   ./tcd-utils/build_tide_db $TCD harmonics-*.txt &> harmonics.out

> The SONAME versioning will only work if upstream (who is used to static
> libs) is strict about keeping the API compatible and never removes
> anything from it prior to v3 as that would break the ABI when using
> a shared lib.

I understand. Currently upstream seems to keep this rule.

Comment 17 Patrice Dumas 2006-10-21 13:03:04 EDT
(In reply to comment #14)

> profile files and desktop files are useless for tideEditor because:
> * HFILE_PATH should be under wher user has write access (For example,
>   HFILE_PATH=/usr/share/xtide/harminocs-????.tcd tideEditor
>   immediately exits).
> * tideEditor surely requires HFILE_PATH environ. With no HFILE_PATH
>   environ, this cannot be launched.

Hrm. A wrapper which sets HFILE_PATH to the argument would be 
better. And even better a file choser for tideEditor when no
HFILE_PATH and no arg is set.
 

> Well, when I directly use release number, i.e.
> tcd-utils: 1.3.7-1  2  3  4  5 ...
> xtide versioning become
> 2.9-dev 0.1.dev   0.2.dev..  0.3.dev.. 0.4.dev.. 
> (then formal release) 5 (suddenly jump)

Why 5? Why not 1? The version/release of tcd-utils is not linked
in a very precise way to xtide verson/release? I even hope that
some day they are split.

Comment 18 Mamoru TASAKA 2006-10-21 13:25:47 EDT
(In reply to comment #17)
> (In reply to comment #14)
> 
> > profile files and desktop files are useless for tideEditor because:
> > * HFILE_PATH should be under wher user has write access (For example,
> >   HFILE_PATH=/usr/share/xtide/harminocs-????.tcd tideEditor
> >   immediately exits).
> > * tideEditor surely requires HFILE_PATH environ. With no HFILE_PATH
> >   environ, this cannot be launched.
> 
> Hrm. A wrapper which sets HFILE_PATH to the argument would be 
> better. And even better a file choser for tideEditor when no
> HFILE_PATH and no arg is set.

copy tcd file to /tmp when invoked (with no arg specified)? 
Some wrapper script to change ENV to arg as you said is preferable anyway.

Well, is there a way to pass a argument (in general) to binary
when called by desktop files (icon in panel)?

>  
> 
> > Well, when I directly use release number, i.e.
> > tcd-utils: 1.3.7-1  2  3  4  5 ...
> > xtide versioning become
> > 2.9-dev 0.1.dev   0.2.dev..  0.3.dev.. 0.4.dev.. 
> > (then formal release) 5 (suddenly jump)
> 
> Why 5? Why not 1? The version/release of tcd-utils is not linked
> in a very precise way to xtide verson/release? I even hope that
> some day they are split.

Well, xtide<->tcd-utils versioning splitting is allowed, there is
no problem.
Comment 20 Patrice Dumas 2006-10-21 21:18:33 EDT
This is in much better shape! The Editor wrapper seems to
be almost what is needed. I have a small patch for it, to
check for config file only if there is no argument.


* I also propose to standardize the libtcd building such that
it can be done with

export CFLAGS="$RPM_OPT_FLAGS -DCOMPAT114"
%configure
%{__make} %{?_smp_mflags} \
%if %{build_libtcd}
   libtcd.so \
   SOMAJOR=`echo %{libtcd_soname} | sed -e 's|^\(.*\)\.\(.*\)\.\(.*\)$|\1|'` \
   SOMINOR=`echo %{libtcd_soname} | sed -e 's|^\(.*\)\.\(.*\)\.\(.*\)$|\2|'` \
   SOVER=`  echo %{libtcd_soname} | sed -e 's|^\(.*\)\.\(.*\)\.\(.*\)$|\3|'`
%endif

I attach the updated libtcd-2.3.1-shared.patch.


* Now there is the issue of missing dependency of tideEditor and xttpd which 
requires /etc/xtide.conf and /usr/share/xtide/harmonics-2004-06-14.tcd.
To workaround this issue I propose to add a package which will 
contain those common datas, called, for example tcd-utils-data and
which will contain

%dir %{_datadir}/%{name}
%{_datadir}/%{name}/harmonics-*.tcd
%config(noreplace) %{_sysconfdir}/%{name}.conf

And then xtide, tcd-utils and xttpd would have a

Requires: tcd-utils-data = %{tcdutils_ver}-%{tcdutils_rel}%{?dist}


* There is a strange $f on the following line
%{__install} -c -p -m755 libtcd.so.*.*.* $f $RPM_BUILD_ROOT%{_libdir}


* In my opinion /etc/xttpd.conf should be instead /etc/sysconfig/xttpd,
with the corresponding adjustment of xttpd.init
Comment 21 Patrice Dumas 2006-10-21 21:21:25 EDT
Created attachment 139070 [details]
test for conf file only if there is a need for the default file

The patch is for tideEditor-wrapper.sh
Comment 22 Patrice Dumas 2006-10-21 21:22:53 EDT
Created attachment 139071 [details]
use CFLAGS set by the user
Comment 23 Patrice Dumas 2006-10-21 21:31:47 EDT
The second patch replaces libtcd-2.3.1-shared.patch.
Comment 24 Mamoru TASAKA 2006-10-21 22:51:15 EDT
Thank you for checking.
Well..

(In reply to comment #20)
> * I also propose to standardize the libtcd building such that
> it can be done with
> 
> export CFLAGS="$RPM_OPT_FLAGS -DCOMPAT114"
> %configure
> %{__make} %{?_smp_mflags} \
> %if %{build_libtcd}
>    libtcd.so \
>    SOMAJOR=`echo %{libtcd_soname} | sed -e 's|^\(.*\)\.\(.*\)\.\(.*\)$|\1|'` \
>    SOMINOR=`echo %{libtcd_soname} | sed -e 's|^\(.*\)\.\(.*\)\.\(.*\)$|\2|'` \
>    SOVER=`  echo %{libtcd_soname} | sed -e 's|^\(.*\)\.\(.*\)\.\(.*\)$|\3|'`
> %endif
> 
> I attach the updated libtcd-2.3.1-shared.patch.
Okay, I will recheck CFLAGS issue again.

> 
> 
> * Now there is the issue of missing dependency of tideEditor and xttpd which 
> requires /etc/xtide.conf and /usr/share/xtide/harmonics-2004-06-14.tcd.
> To workaround this issue I propose to add a package which will 
> contain those common datas, called, for example tcd-utils-data and
> which will contain .......

I think that "xtide-data" is more preferable and I will introduce
this.

> * There is a strange $f on the following line
> %{__install} -c -p -m755 libtcd.so.*.*.* $f $RPM_BUILD_ROOT%{_libdir}

!? Oops.... I will correct this.

> * In my opinion /etc/xttpd.conf should be instead /etc/sysconfig/xttpd,
> with the corresponding adjustment of xttpd.init

Okay.

(In reply to comment #21) 
> The patch is for tideEditor-wrapper.sh

Oh, good catch. I will apply.
Comment 25 Mamoru TASAKA 2006-10-22 08:34:33 EDT
Well, I made a change for tideEditor-wrapper.sh .

Again I uploaded new spec and srpm.

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.4.dev20061015.src.rpm

Now this creates 6 + debuginfo binary rpms.
Comment 26 Patrice Dumas 2006-10-22 12:37:44 EDT
I still have 3 comments:

* there are icons in iconsrc/, I think it would be better 
to use them.

* the Group for -devel should better be something like
Development/Libraries

* It seems to me that you should add the sourcing of qt.sh 
snippet of Michael. I won't make it a blocker, but I think
it is better if the following works without relogin:

yum install qt-devel
rpmbuild -ba xtide.spec
Comment 27 Mamoru TASAKA 2006-10-22 13:21:43 EDT
(In reply to comment #26)
> * there are icons in iconsrc/, I think it would be better 
> to use them.
Oh, I didn't notice this.

> * the Group for -devel should better be something like
> Development/Libraries
This should be.

> * It seems to me that you should add the sourcing of qt.sh 
> snippet of Michael. I won't make it a blocker, but I think
> it is better if the following works without relogin:

Um, okay.

Again uploaded:

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.5.dev20061015.src.rpm
Comment 28 Patrice Dumas 2006-10-22 15:40:36 EDT
In the icon directory there is a 48x48 icon, it should be 
installed in the hicolor theme, too.
Comment 29 Mamoru TASAKA 2006-10-22 18:59:36 EDT
(In reply to comment #28)
> In the icon directory there is a 48x48 icon, it should be 
> installed in the hicolor theme, too.

Why? Icons are not used but by desktop files and we don't have to install
icons which will be never used, I think.
Comment 30 Patrice Dumas 2006-10-22 19:44:25 EDT
They will be used in menu because they are in desktop
files. The application formatting the menu will chose the
size it prefers, so there should be as many size as possible.
Comment 31 Mamoru TASAKA 2006-10-22 20:12:08 EDT
(In reply to comment #30)
> They will be used in menu because they are in desktop
> files. The application formatting the menu will chose the
> size it prefers, so there should be as many size as possible.

Ah, I tried and this is true. Thanks.

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.6.dev20061015.src.rpm
Comment 32 Patrice Dumas 2006-10-23 05:22:02 EDT
I cannot find the harmonics source file by using the provided
Source.

I found the licence of the file, and it seems that it isn't free
data like free software (no selling):
http://www.flaterco.com/xtide/harmonics_boilerplate.txt

I don't know exactly how to deal with this issue. First the issue of
mixing with xtide. It may be legal to distribute it together with 
GPLed programs if the GPL don't apply to data, only to software, and 
if it isn't the case, it would be possible to put the harmonics file 
in a separate package. I personnally think that it would be better to 
put the harmonics file in a separate src.rpm if the licence is really 
for non commercial use only.

That kind of data may be legally redistributed by fedora, however
it will be troublesome if somebody sells fedora. So they definitively
cannot be packaged as-is. It seems to me that the best thing to do 
would be to add a README/something in the description in the packages 
needing the harmonics file and provide a shell script which does a 
wget on the file, run the tcd-util conversion on it and install, 
or alternatively download directly the .tcd file.



The wvs file should be used (provided the licence is acceptable for
fedora). I couldn't find the licence at the url provided at the xtide 
page. Maybe ask upstream or the NOAA?
http://www.ngdc.noaa.gov/mgg/fliers/93mgg01.html
http://www.ngdc.noaa.gov/mgg/global/relief/ETOPO5/BOUNDARY/WVS/

From reading of the code, one can set the WVS_DIR variable to
the directory holding the wvs data files, or it may be listed in 
xtide.conf. 

It seems to me that WVS_DIR must be set for tideEditor.
Comment 33 Mamoru TASAKA 2006-10-23 08:08:54 EDT
(In reply to comment #32)

> That kind of data may be legally redistributed by fedora, however
> it will be troublesome if somebody sells fedora. So they definitively
> cannot be packaged as-is. It seems to me that the best thing to do 
> would be to add a README/something in the description in the packages 
> needing the harmonics file and provide a shell script which does a 
> wget on the file, run the tcd-util conversion on it and install, 
> or alternatively download directly the .tcd file.

Well, I will try to contact upstream (perhaps for harmonics data,
It is Bob Kenney <rmk@unh.edu> according to
http://bel-marduk.unh.edu/xtide/files.html ), however, perhaps the 
best plan FOR NOW is not to provide harmonics data from Fedora
and provide some document as of how to get harmonics tcd data.

> The wvs file should be used (provided the licence is acceptable for
> fedora). I couldn't find the licence at the url provided at the xtide 
> page. Maybe ask upstream or the NOAA?
> http://www.ngdc.noaa.gov/mgg/fliers/93mgg01.html
> http://www.ngdc.noaa.gov/mgg/global/relief/ETOPO5/BOUNDARY/WVS/

Well, once I tried to check WVS data, however this are binary data and
perhaps I cannot verify legal issue until I contact to upstream.

> 
> From reading of the code, one can set the WVS_DIR variable to
> the directory holding the wvs data files, or it may be listed in 
> xtide.conf. 
> 
> It seems to me that WVS_DIR must be set for tideEditor.

Well, I must check the code because currently don't know how
the environment WVS_DIR is used (is this needed?)

--------------------------------------------------------------------------------
Summary:
A. I will try to contact upstream, however, my current plan is to
    completely drop harmonics data from binary rpm and add a document
    for this issue (I would appeciate it if you make some template for
    this). 
A-1 By the way providing some shell script is necessary?
     I think only explaining how to get tcd data is more preferable
     because anyway people have to browse a URL to choose the original
     harmonics text.

B. I will check WVS_DIR in source code.

----------------------------------------------------------------------------------
Is it okay?
    

Comment 34 Mamoru TASAKA 2006-10-23 08:10:26 EDT
Ah...

C. Well I won't include WVS data until the license of this data
    get clear.
Comment 35 Patrice Dumas 2006-10-23 09:26:08 EDT
Ok, I'll come with something today.
Comment 36 Mamoru TASAKA 2006-10-23 10:07:43 EDT
(In reply to comment #35)
> Ok, I'll come with something today.

Thanks. By the way, I mailed to upstream to ask him/her about harmonics
data license issue.
Comment 37 Patrice Dumas 2006-10-23 10:28:25 EDT
(In reply to comment #34)
> Ah...
> 
> C. Well I won't include WVS data until the license of this data
>     get clear.

I've just noticed that it is said on the download page:
http://www.flaterco.com/xtide/files.html
"and are public domain"

They are at:
ftp://ftp.flaterco.com/xtide/wvs.tar.bz2

I think that these should be in a separate source package, without %{?dist}
and installed below %_datadir (for example in %{_datadir}/xtide_wvs/). 
The xtide package would depend on these.

There may be directories in /etc/xtide.conf (xtide will use all
the files from these directories), so I think the simplest thing to 
do would be to have directories in /etc/xtide.conf, along

%{_sysconfdir}/xtide/:%{_datadir}/xtide/
%{_sysconfdir}/xtide_wvs/:%{_datadir}/xtide_wvs/

and adjust the tideEditor wrapper such that it takes the first file
appearing in the directories listed in xtide.conf, and set WVS_DIR
to the first directory in the second line containing one of the
wvs files.
Comment 38 Patrice Dumas 2006-10-23 10:35:46 EDT
Created attachment 139129 [details]
Availability and installation of harmonics files README

First attempt for a README for the harmonics files.

In my opinion doing a script, called for example
xtide_get_harmonics.sh containing the 4 lines at the
bottom of the README wouldn't hurt, on the contrary.
Comment 39 Patrice Dumas 2006-10-23 10:39:30 EDT
Also I propose to change the %descrption, such that

"See http://www.flaterco.com/xtide/files.html
for details on where to get these."

becomes

"See the included README.fedora or http://www.flaterco.com/xtide/files.html
for details on where to get these."

And if we provide a script, add

"Alternatively you can run the provided script xtide_get_harmonics.sh 
to install these files."
Comment 40 Mamoru TASAKA 2006-10-23 11:17:23 EDT
Thank you for lots of help!!
Well, I will look into them.....
Comment 41 Mamoru TASAKA 2006-10-24 12:25:55 EDT
Today I take a rest.
Comment 42 Mamoru TASAKA 2006-10-25 14:12:34 EDT
Well, I feel like including WVS file into -common package.

Please check the following.
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.7.dev20061015.src.rpm

Note: spec file is 17K and SRPM is 36M.
Comment 43 Patrice Dumas 2006-10-25 15:44:09 EDT
(In reply to comment #42)
> Well, I feel like including WVS file into -common package.

I don't think it is a good idea. It is a different package with different 
source. It is allready 13 years old information and not expected
to change ever. Besides it could be usefull for another package.
It is noarch. It don't need to have a %{dist} tag. It should 
never need to have the version bumped. It should be reviewed very
fastly.

Comment 44 Mamoru TASAKA 2006-10-25 16:13:02 EDT
Created attachment 139401 [details]
ideEditor-wrapper.sh (fixed)

(In reply to comment #42)
Aside for WVS data;
>
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec

>
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.7.dev20061015.src.rpm


tideEditor-wrapper.sh in this srpm is quite buggy. Please check the
attachment
Comment 47 Patrice Dumas 2006-10-25 19:00:13 EDT
* rpmlint warnings:
This one should be acted upon:
W: xtide strange-permission xtide-README.fedora 0600

Others are ignorable
W: xtide strange-permission tideEditor-wrapper.sh 0755
W: xtide dangling-relative-symlink /usr/share/icons/hicolor/48x48/apps/xtide.png
../../../../xtide/icon_48x48_orig.png
W: xtide dangling-relative-symlink /usr/share/icons/hicolor/16x16/apps/xtide.png
../../../../xtide/icon_16x16_orig.png
W: tcd-utils dangling-relative-symlink
/usr/share/icons/hicolor/16x16/apps/tideEditor.png
../../../../xtide/icon_16x16_orig.png
W: tcd-utils dangling-relative-symlink
/usr/share/icons/hicolor/48x48/apps/tideEditor.png
../../../../xtide/icon_48x48_orig.png

* spec is not very legible, with tons of macros and building of
  3-4 different programs with different build systems. This is
  unavoidable, however as we may have to build packages together
  due to inter-dependencies:
libtcd, part of xtide is needed by tcd-utils. tcd-utils generates
the harmonics files which are needed by the xtide programs.

In the current situation we cannot redistribute the harmonics
file, so it could be possible to have tcd-utils in another
package, but in that case it wouldn't be possible to have a 
package which also includes the harmonics (there is a %with
ready for that situation).

* free software with licence included or excerpted (GPL and Public
  Domain)
* names are right. This package case is not completly unambigously
  covered by the guidelines, given all the peculiarities: libtcd
  which has a version is included in xtide. Although xtide is a 
  development snippet, libtcd is a stable version; tcd_utils also has
  a version, but it is not in the tarball name, the tarball name 
  uses a date. All are packaged together...
* follows guidelines
* match upstream
730880e830eed1b4585b89fec55b9358  tcd-utils_2004-08-15.tar.gz
04d7f6346204a728441b51f9f6377979  xtide-2.9dev-20061015.tar.bz2
* gui apps have desktop and icon files
The guideline for desktop files are not followed exactly, but
the guidelines break with desktop-file-utils-0.11-1.fc7.
* libraries rightly packaged (no rpath, no .la, .so and headers in
  -devel, ldconfig called).
* doc don't affect runtime
* directory ownership is right
* works correctly off-the-box
* RPM_OPT_FLAGS are correctly used
* %files right
* snippets clean

BLOCKERS:
- The rpmlint warning above

- the common subpackage sould Requires wget and bzip2 for the 
script.

COMMENTS:
- the README.fedora could be ameliorated:
There is a reference to a scriptlet, but the scriptlet isn't there:

  The following scriptlet does all which is needed to install the 
  harmonics file (last command must be done with the administrator
  privileges):

  Alternatively you can run the provided script xtide-get_harmonics.sh 

The paths with xtide-wvs/ should be updated.

- the licence of the common package is certainly more Public Domain than
GPL

- the package which install in hicolor could depend on hicolor-icon-theme
for directory ownership, but this is not very clear to whether this is
really right since it adds an otherwise unneeded dependency to a lot 
of packages.

- I think that a note about README.fedora should be in all the packages
description needing the harmonics file. It is allready in xtide, it may
be relevant to add to the xttpd and tcd-utils %description something along:
 
 Please read README.fedora in common package for Fedora specific issue.

Accepted provided the BLOCKERS issues are fixed.


Michael, do you have any comment?
Comment 48 Michael Schwendt 2006-10-25 20:50:23 EDT
xttpd:

* initscript should return 2 as "Usage" error return code.

* With default install, it is very quiet:

# /etc/init.d/xttpd start
# service xttpd status
# service xttpd start
# service xttpd status
# service xttpd stop
# service xttpd restart

So, looking for the sysconfig file and uncommenting defaults lead to this:

# service xttpd start
Starting xttpd:                                            [  OK  ]
# service xttpd status
xttpd dead but subsys locked

And in /var/log/messages:

: XTide Fatal Error:  NOHOMEDIR The environment variable HOME is not set. 

# echo $HOME
/root
Comment 49 Mamoru TASAKA 2006-10-26 02:17:03 EDT
Well,
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.10.dev20061015.src.rpm
should fix all the issues that needs fixing. Please check.

(In reply to comment #47)
> Others are ignorable
> W: xtide strange-permission tideEditor-wrapper.sh 0755
> W: xtide dangling-relative-symlink /usr/share/icons/hicolor/48x48/apps/xtide.png
> ../../../../xtide/icon_48x48_orig.png
> W: xtide dangling-relative-symlink /usr/share/icons/hicolor/16x16/apps/xtide.png
> ../../../../xtide/icon_16x16_orig.png
> W: tcd-utils dangling-relative-symlink
> /usr/share/icons/hicolor/16x16/apps/tideEditor.png
> ../../../../xtide/icon_16x16_orig.png
> W: tcd-utils dangling-relative-symlink
> /usr/share/icons/hicolor/48x48/apps/tideEditor.png
> ../../../../xtide/icon_48x48_orig.png
By the way, these warning are avoided once we install this and
execute rpmlint for *INSTALLED* rpm, for example, "rpmlint xtide".

> * spec is not very legible, with tons of macros and building of
>   3-4 different programs with different build systems. 
Well, I leave it for now though this is a bit complicated...

> the guidelines break with desktop-file-utils-0.11-1.fc7.
Maybe desktop-file-utils will change.
 
> - the package which install in hicolor could depend on hicolor-icon-theme
> for directory ownership, but this is not very clear to whether this is
> really right since it adds an otherwise unneeded dependency to a lot 
> of packages.
Well, there is a agreement that hicolor-icon-theme can be treated as
something like "filesystem" rpm. Actually trying to remove
hicolor-icon-theme (by yum) also tries to remove lots of packages
(even gtk2). 

(In reply to comment #48)
> xttpd:
> * initscript should return 2 as "Usage" error return code.
Well, I checked some init scripts in /etc/rc.d/init.d and usually
they return the value 1 so I use 1.

> * With default install, it is very quiet:
> .............................

I hope the updated init script (and wrapper shell script) should
fix this problem.
Comment 50 Patrice Dumas 2006-10-26 06:02:40 EDT
The xttpd start script don't do what I would have expected. Indeed
when PORT is not set I don't get any error message, only a failed
error (ÉCHOUÉ means FAILED):

# /etc/init.d/xttpd start
Starting xttpd:                                            [ÉCHOUÉ]

Nothing appears in logs (a grep PORT in /var/log/* /var/log/*/*
don't return anything).
Comment 51 Mamoru TASAKA 2006-10-26 06:31:15 EDT
Created attachment 139451 [details]
alternative xttpd to write

It seems that initlog is commented out so
nothing is written in any logs.

The attached xttpd writes the error message to stderr.
Comment 52 Mamoru TASAKA 2006-10-26 09:25:23 EDT
Well, please check the  attachment in my comment #51 ?
If it is okay, I will replace xttpd.init with the attachment.
Comment 53 Patrice Dumas 2006-10-26 09:32:13 EDT
It works better now, but I am not convinced that it is
the proper fix. I don't see why you need to send the 
echo output on STDERR? It works the same without redirection?
Anyway redirection to log should be done explicitely. So
if you want errors to be logged, I guess you should call
logger yourself.

And also it seems that failure should be used instead of echo_failure
since it does something when with rhgb (show details).
Moreover I think the [ FAILED ] should appear before the explanation.

It leads to the following code:

    if test -z "$PORT" ; then
        failure
        echo
        echo $"PORT environment is not set."
        RETVAL=1
        return $RETVAL

Another remark is that I think having HOME defaulting to /root is wrong,
it should be set to a directory below sysconfig, for example 
%{_sysconfig}/xtide. And I am not completly convinced that using 
nobody as a user is the right thing to do, maybe a specific user
would be better.
Comment 54 Patrice Dumas 2006-10-26 09:37:36 EDT
(In reply to comment #49)

> Maybe desktop-file-utils will change.

Indeed this is rawhide breakage. Either the guidelines or 
desktop-file-utils should be updated.


> Well, there is a agreement that hicolor-icon-theme can be treated as
> something like "filesystem" rpm. Actually trying to remove
> hicolor-icon-theme (by yum) also tries to remove lots of packages
> (even gtk2). 

I am not sure that there is such agreement. But as I said it is 
acceptable, since it is not clear what is the right way to do. 
As a side note, gtk2 isn't a package that is always installed 
(on a server, if using  fluxbox, or using X apps only through 
ssh....).
Comment 55 Mamoru TASAKA 2006-10-26 10:09:03 EDT
(In reply to comment #53)
> Indeed this is rawhide breakage. Either the guidelines or 
> desktop-file-utils should be updated.

Jesse Keating commented on fedora-extras-list.
https://www.redhat.com/archives/fedora-extras-list/2006-October/msg00722.html

> It works better now, but I am not convinced that it is
> the proper fix. I don't see why you need to send the 
> echo output on STDERR? 
Simply because I wanted to send to stderr because it is a error.
Removing.

> And also it seems that failure should be used instead of echo_failure
> since it does something when with rhgb (show details).
Okay.

> Moreover I think the [ FAILED ] should appear before the explanation.
> It leads to the following code:
> 
>     if test -z "$PORT" ; then
>         failure
>         echo
>         echo $"PORT environment is not set."
>         RETVAL=1
>         return $RETVAL
> 
My recognition is that usually OK of FAILED appears at the last
and the location of "failure" should be under the explanation.

> Another remark is that I think having HOME defaulting to /root is wrong,
> it should be set to a directory below sysconfig, for example 
> %{_sysconfig}/xtide. 
Okay.

> And I am not completly convinced that using 
> nobody as a user is the right thing to do, maybe a specific user
> would be better.
Well, for this I will reply later.
Comment 56 Mamoru TASAKA 2006-10-26 11:08:41 EDT
Well, I leave "failure" function below "echo $"PORT environment is not set.""
I tried to change "nobody" to "xttpd". Check:

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.11.dev20061015.src.rpm

(In reply to comment #54)
> > Maybe desktop-file-utils will change.
> 
> Indeed this is rawhide breakage. Either the guidelines or 
> desktop-file-utils should be updated.

Well, discussion seems to be proceeding to the direction that "X-Fedora" should
be removed.
Comment 57 Patrice Dumas 2006-10-26 19:01:23 EDT
* Regarding the user, I'd prefer a patch such that it doesn't
  silently fail if the user name change or something along (at
  least in the code, in the documentation, I don't care).

*
Requires(pre):   /sbin/nologin

  isn't needed, useradd don't fail even if the shell don't exist and
  it is in util-linux.

  useradd I don't know. Maybe it is needed for proper ordering, but
  it is not obvious since rpm depends on it.

* xttpd user may be deleted at the uninstall since he shouldn't own
  any directory (nor any file).

* Regarding the init file, if you want to have the message on the same
  line that the 'starting message', no problem but currently there 
  is an additional end of line, so it isn't clear what failed. In 
  my opinion, the code should be (added -n for the first echo)

        echo -n $"PORT environment is not set."
        failure
        echo
        RETVAL=1
        return $RETVAL

* from a look at the code it seems that the group isn't changed, it 
  should be. And also if setuid fails, there is only a log, the
  program should exit.
Comment 58 Mamoru TASAKA 2006-10-27 10:51:47 EDT
I leave not to call userdel on postun as it is usually considered as
dangerous.

Please check:
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.12.dev20061015.src.rpm

Well, I feel that we are doing some extra work than reviewing process.....
Comment 59 Patrice Dumas 2006-10-27 18:02:34 EDT
(In reply to comment #58)
> I leave not to call userdel on postun as it is usually considered as
> dangerous.

Right, do what you prefer. I think I myself wouldn't have called userdel
too.

> Well, I feel that we are doing some extra work than reviewing process.....

What makes you think that? The xttpd.init formatting output is 
not very important, but otherwise I see only relevant issues being 
raised.

I attach a modified version of the user patch, there were 2 unneeded
changes of nobody to xttpd (one in documentation is quite funny).


All my blockers have been solved. 


Michael, do you have other comments?
Comment 60 Patrice Dumas 2006-10-27 18:04:25 EDT
Created attachment 139619 [details]
minor change to remove unneeded substitutions of nobody by xttpd
Comment 61 Mamoru TASAKA 2006-10-27 20:08:30 EDT
(In reply to comment #59)
> (In reply to comment #58)
> (one in documentation is quite funny).

Exactly. "nobody" is really "nobody" at one point......
(In reply to comment #59)
> What makes you think that? The xttpd.init formatting output is 

Well, I just wanted to release this as soon as possible, just ignore it.
I appreciate any comment from you and Michael very much (and of course from
other people).

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.13.dev20061015.src.rpm

-------------------------------------------------------------------------
By the way, I have another question.
I submitted a re-review request as this because it has passed "long" since
xtide got dead, and actually it became to be clear that many changes are
needed as we discussed on this bug.

However in general is there any agreement when we should submit re-review
requests for orphaned/dead packages? I cannot see any reference on
http://fedoraproject.org/wiki/Extras/OrphanedPackages .
( again I comment that for xtide I really think that re-review was
  needed )
Comment 62 Patrice Dumas 2006-10-28 05:22:38 EDT
(In reply to comment #61)

> By the way, I have another question.
> I submitted a re-review request as this because it has passed "long" since
> xtide got dead, and actually it became to be clear that many changes are
> needed as we discussed on this bug.

Also many packages from the early days of fedora extras, and from the
days when fedora core package entered in extras without a review don't
attain the same level of quality than more recently reviewed packages.
(and of course the guidelines change over time).

> However in general is there any agreement when we should submit re-review
> requests for orphaned/dead packages? I cannot see any reference on
> http://fedoraproject.org/wiki/Extras/OrphanedPackages .

I remember that being evoked and I think the rule was that if the package
was marked as dead in a previous release, (it is pretty tight here since
previous release is fc5) it needed a rereview.

> ( again I comment that for xtide I really think that re-review was
>   needed )

Indeed! I guess that a full security audit of xttpd would be nice, however
it would go beyond a review.

If Michael hasn't said anything on monday, you can import it on that day.
Comment 63 Patrice Dumas 2006-10-29 18:22:50 EST
It seems to ome that the upstream split of xtide is 
broken. Indeed, it seems to me that it would make
more sense to have 2 packages:

one with libtcd and the conversion utilities, build_tide_db
and restore_tide_db.

the other with xtide, xttpd, tide and tideEditor. It
would depend on the other package.

Could it be possible for you to ask upstream for this
resplit, if you also think it makes sense, of course, and
if upstream agrees, we could reflect this in the package
split of xtide.
Comment 64 Mamoru TASAKA 2006-10-29 21:00:41 EST
In my opition, tideEditor should be in tcd-utils component because
this is for editing tcd file and have less relation with xtide or xttpd
than with build_tide_db and restore_tide_db.

(In reply to comment #63)
> tideEditor. It
> would depend on the other package.
What do you mean by this? tideEditor should work if original tcd file exists.
Comment 65 Mamoru TASAKA 2006-10-30 03:08:35 EST
Well, source is updated.

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.14.dev20061027.src.rpm

"-DCOMPAT114" is removed, which leads to libtcd API change!!
So I bumped somajor.
Comment 66 Patrice Dumas 2006-10-30 04:05:27 EST
(In reply to comment #64)
> In my opition, tideEditor should be in tcd-utils component because
> this is for editing tcd file and have less relation with xtide or xttpd
> than with build_tide_db and restore_tide_db.

I disagree. xtide is a graphical viewer, tideEditor is a graphical 
editor (so also a viewer). While build_tide_db and restore_tide_db
are command line conversion tools, with much less dependencies. 
libtcd and the command line apps are like development tools while the
others are utilities. libtcd and the command line tools are likely to
change less often than the graphical apps or the dameon.


> (In reply to comment #63)
> > tideEditor. It
> > would depend on the other package.
> What do you mean by this? tideEditor should work if original tcd file exists.

It depends on libtcd, and a convertor may also be of use for tideEditor,
and it is exactly the same for xttpd and xtide.
Comment 67 Michael Schwendt 2006-10-30 05:49:45 EST
The rationale behind the package split cannot be seen.

First, multiple upstream packages are merged into a single source rpm
just to distribute their contents to multiple rpms afterwards.

What are the benefits of creating the sub-packages like this?
Are package dependency requirements reduced?
Is the size of the installation reduced?

1) As unfortunate as upstream's libtcd static library packaging inside
xtide is, I understand that it makes sense to split off libtcd{-devel},
provided that at least another program is included with Fedora Extras
(e.g. harmgen). The SONAME versioning scheme is unfortunate, but that
is something to discuss with the upstream developer.

2) tcd-utils is a separate tarball, a small one, but needed for building
your "xtide" rpms. So, you decided to include it, thereby defeating the
purpose of the upstream split. Among other side-effects, you need to
push new  xtide, libtcd, libtcd-devel, xttpd, tcd-utils  packages whenever
one out of two upstream packages changes. Further, tideEditor, which is
part of tcd-utils and not put into a separate rpm, adds a dependency on
the rather large Qt. This reduces the benefit of a separate tcd-utils rpm,
as now Qt is needed when installing the small *tide_db tools.

3) And finally, XTide, split into multiple small rpms, is "enhanced" with
a strict dependency on a 40M data rpm.

The current package split is neither obvious nor convenient for the users.
Seriously, considering the special target group of XTide and friends,
I wouldn't even mind an all-in-one package with *optional* data.
Comment 68 Mamoru TASAKA 2006-10-30 06:37:02 EST
Umm... well I want to make it clear 
* what blocks re-releasing xtide (and related packages) for Fedora Extras
  currently
* what should we discuss with upstream before or after releasing xtide to
  Fedora Extras

Patrice and Michael, would you point them? I think it is a pity that
we cannot release xtide for Fedora Extras because of packaging issue.
Comment 69 Patrice Dumas 2006-10-30 07:35:04 EST
(In reply to comment #67)

> 2) tcd-utils is a separate tarball, a small one, but needed for building
> your "xtide" rpms. So, you decided to include it, thereby defeating the
> purpose of the upstream split. Among other side-effects, you need to
> push new  xtide, libtcd, libtcd-devel, xttpd, tcd-utils  packages whenever
> one out of two upstream packages changes. Further, tideEditor, which is
> part of tcd-utils and not put into a separate rpm, adds a dependency on
> the rather large Qt. This reduces the benefit of a separate tcd-utils rpm,
> as now Qt is needed when installing the small *tide_db tools.

I my opinion this is the result of a broken upstream split, since upstream
should have put tideEditor with xtide, and not with the *tide_db tools.
Maybe this comes from historical reasons (because the original tcd-utils 
author isn't the xtide author), and not from technical reasons.

> 3) And finally, XTide, split into multiple small rpms, is "enhanced" with
> a strict dependency on a 40M data rpm.

Without wvs, xtide or tideEditor are ugly. Admitedly the 2 high resolution
wvs data files are certainly not very usefull for xtide, but removing them
from wvs adds complexity.

> The current package split is neither obvious nor convenient for the users.
> Seriously, considering the special target group of XTide and friends,
> I wouldn't even mind an all-in-one package with *optional* data.

wvs cannot really be optional, there are no coast boundaries without it.  

I don't really like having xttpd installed together with the graphical
tools, but I wouldn't object a all-in-one package (or with only libtcd, 
libtcd-devel subpackages), since indeed it is more convenient.
Comment 70 Michael Schwendt 2006-10-30 07:41:44 EST
What these packages need is more time to mature. The more disagreement
during review, the more time it takes for things to settle down.

The rushed submission and release of wvs-data has shown that the plan
is to release all this for FC-5, FC-6 and not just development.

To put it bluntly, the many comments to this ticket and the history of
the spec demonstrate that these packages are still subject to major
changes from one day to the other and that they have a fuzzy target
only. This is enough reason to believe that the heavy changes might
continue after approval.

Since the original submission, not just the soname has changed thrice.
From an initial libtcd.so.21{.0.3} to libtcd.so.0{.0.0}, and now once
more. And interestingly, due to an upstream change. Hear, hear! This
is the proof that an uncoordinated library versioning scheme like this
is much too fragile.

It would be irresponsible to approve these packages. The veto situation
is unclear. Hence the only way to block this from entering FE is to not
approve all this for now.

[...]

For reference:

http://packages.debian.org/unstable/science/xtide
http://packages.debian.org/testing/science/xtide
http://packages.debian.org/stable/science/xtide
Comment 71 Patrice Dumas 2006-10-30 08:04:01 EST
(In reply to comment #70)

> Since the original submission, not just the soname has changed thrice.
> From an initial libtcd.so.21{.0.3} to libtcd.so.0{.0.0}, and now once
> more. And interestingly, due to an upstream change. Hear, hear! This
> is the proof that an uncoordinated library versioning scheme like this
> is much too fragile.

Indeed this is something that should be discussed with upstream.

> It would be irresponsible to approve these packages. The veto situation
> is unclear. Hence the only way to block this from entering FE is to not
> approve all this for now.

I'm clearly waiting for your agreement before approving.

On the positive side, I think that the package has been improved
a lot during the review, with the dynamic library handling, the 
xttpd init file, the squashing of non free file, the dependency 
on wvs and other items.
Comment 72 Patrice Dumas 2006-10-30 08:05:37 EST
(In reply to comment #68)

> Patrice and Michael, would you point them? I think it is a pity that
> we cannot release xtide for Fedora Extras because of packaging issue.

I have never seen a package in fedora being blocked by anything
else than packaging issues ;-)
Comment 73 Mamoru TASAKA 2006-10-30 08:32:12 EST
Well, then what blocks this for now is:

0. First of all, should we split files related to "this" src package
   to several binary packages?

A. should we provide libtcd (and libtcd-devel) packages for now, or
   use static libtcd.a?

A-1 If we should provide libtcd dynamic library, how we should decide
         soname versioning? 
A-2 Is this be discussed with upstream [before/after]
         releasing this to Fedora Extras?

B. To what component should tideEditor belong to? 

B-1 Also, should the discussion of tideEditor assignment be discussed 
     with upstream [before/after] releasing to Fedora Extras?

Is it okay?
Comment 74 Michael Schwendt 2006-10-31 07:26:31 EST
Have any of you two perused the Debian packaging work?
http://ftp.debian.org/debian/pool/main/x/xtide/xtide_2.8.2-3.diff.gz

Surprise, surprise, it's an all-in-one package. Except for wvs-data,
which they ship as an optional xtide-data (trimmed down by 7M). They
include a minimal set of harmonics data, btw.

[...]

Upstream's requirement to break the ABI/API so soon after you had
created a shared library forces libtcd to become static. Unless you
try to talk to David Flater about whether maybe he accepts patches
and what he thinks about separating libtcd into a separate tarball.

tideEditor makes only sense to be put into an own sub-package if you
insist on doing that because of its Qt requirement. However, it does
not make sense to merge it with tcd-utils or to put the small utils
into a separate package when a) you include them in the xtide src.rpm
anyway and b) they are linked statically.
Comment 75 Patrice Dumas 2006-10-31 08:23:12 EST
(In reply to comment #74)
> Have any of you two perused the Debian packaging work?
> http://ftp.debian.org/debian/pool/main/x/xtide/xtide_2.8.2-3.diff.gz

The patches seem not to be relevant in the cvs snapshot anymore.
It is not easy to use the debian stuff since their patch patches
the code directly. However it should be very relevant to work
together with debian people on that package. For example we could
use their harmonics data, and they will certainly benefit from
what is done on the fedora package, for example the wrappers.

Mamoru, you should certainly contact them to ask them to rearrange
their debian patchset such that the patches are applied as part of
the rules, and not directly such that you can apply it simply to
xtide in spec.

> Surprise, surprise, it's an all-in-one package. Except for wvs-data,
> which they ship as an optional xtide-data (trimmed down by 7M). They
> include a minimal set of harmonics data, btw.

I don't see the wvs data in the xtide-data package, it seems to me that
it contains only harmonics, and in the debian help files it is mentionned
that wvs-data is too big to be uploaded in debian. I don't see tideEditor
in debian either.

> [...]
> 
> Upstream's requirement to break the ABI/API so soon after you had
> created a shared library forces libtcd to become static. Unless you
> try to talk to David Flater about whether maybe he accepts patches
> and what he thinks about separating libtcd into a separate tarball.
> 
> tideEditor makes only sense to be put into an own sub-package if you
> insist on doing that because of its Qt requirement. However, it does
> not make sense to merge it with tcd-utils or to put the small utils
> into a separate package when a) you include them in the xtide src.rpm
> anyway and b) they are linked statically.

I agree with both remarks. 

(In reply to comment #73)
> Well, then what blocks this for now is:
> 
> 0. First of all, should we split files related to "this" src package
>    to several binary packages?
> 
> A. should we provide libtcd (and libtcd-devel) packages for now, or
>    use static libtcd.a?
> 
> A-1 If we should provide libtcd dynamic library, how we should decide
>          soname versioning? 
> A-2 Is this be discussed with upstream [before/after]
>          releasing this to Fedora Extras?

I think we should release dynamically linked binaries, but after having
upsteram accept the soname naming and the build patches.

> B. To what component should tideEditor belong to? 
> 
> B-1 Also, should the discussion of tideEditor assignment be discussed 
>      with upstream [before/after] releasing to Fedora Extras?
> 
> Is it okay?

Not exactly. In my opinion there are 2 issues that are distinct:

1) the split of the source package. It is to be done upstream, and, to
repeat myself I think the current split is broken, tideEditor should be
with xtide, while libtcd should be split out with the *tide_db.

I think that this should be discussed with upstream.

2) the split of the rpm binary packages. This is our task, here, and 
somehow independent from the choices done upstream, in case we have only
one src.rpm as it is the case for now.

Regarding this issue, I am fine with a all-in-one package, but I am also
fine with a split package. Indeed, having subpackages for libtcd(-devel)
is fine by me since makes sense to build other software against that 
library. The *tide_db convertors may be in the libtcd package, but then,
unless I'm wrong it won't be possible to be multilib. So they could also
be in a standalone package (tcd-utils) or included with a big xtide package.
I wouldn't object to a separate xttpd package because I think that it is 
right to have the choice to install a network daemon or not. I am also 
fine with a separate package for tideEditor because of the huge dependency.
If xttpd/tideEditor/xtide are not in the same package, then a -common
subpackage is also needed for the conf file and harmonics (real files or
instructions).

I am open to any combination implied by the above, I think they all make 
sense, and it should be left to Mamoru to chose, but not in a hurry, please.

My personal choice would depend on upstream. If upstream agrees with 
dynamic library, and split the source as I advertise above I would 
go for libtcd, libtcd-devel, tcd-utils (only with *tide_db 
convertors) and a xtide package with the remaining. If upstream don't 
put the *tide_db in a separate package, I would go for libtcd, 
libtcd-devel and all the remaining grouped together. And if upstream
don't want dynamic libtcd, I would go for a all-in-one package.

The current situation with tideEditor packaged only with the *tide_db 
convertors seems wrong, however.
Comment 76 Mamoru TASAKA 2006-11-01 12:05:31 EST
Well, I will mail to upstream today (in Japan).

NOTE: I will be busy through next Wednesday and I may have less connectibity.
Comment 77 Mamoru TASAKA 2006-11-02 06:16:22 EST
I mailed to upstream.
Comment 78 David Flater 2006-11-12 20:38:15 EST
Upstream here.  I was AFK for two weeks.

In a message dated 2006-11-02 19:47+0900, Mamoru Tasaka wrote:
> A.
> Well, currently libtcd library are packaged in XTide tarball and
> only static archive are provided. libtcd is used not only for XTide,
> but also some utilities in tcd-utils and others, so I think
> providing libtcd seperately is a good idea.

The reason things are packaged the way they are is that 99% of users
are only interested in running XTide to get tide predictions.  They
have no interest in nor any need for an ability to generate or edit
the tide data, and anything I do to make that possible for them just
adds complexity, hurts performance, and makes them yell at me.  I have
been there and done that, and it was a mistake.

tcd-utils is for the other 1% who actually do know enough to edit tide
data in a meaningful way and have reason to do it.  It was never
cleaned up for the 99% market.  The people who use it (counted on one
hand) have never complained about having to compile it from ugly
source snapshots.

The inclusion of tcd-utils in Fedora was perhaps motivated by some
policy that discouraged shipping binary files?  For the legacy
harmonics data (still distributed by Bob Kenney, but not maintained),
the TCD was in fact built from text and XML source, so building a TCD
using tcd-utils might have made sense.  But that is all ancient
history.  harmonics-dwf now starts with scraping web pages from the
NOAA web site using software that has to be updated every year as
their web site changes, then these are processed into an SQL database
where they merge with other countries' data, then manual fixes are
made as needed to correct upstream errors, then eventually the whole
mess is exported directly to TCD.  The closest you could get to what
you want is to start with the SQL dump, but then you would need to
have PostgreSql running, and harmbase2, and ... just don't go there.
99% of users will not benefit from this approach.  They just want the
tide prediction part of the program to install easily and run easily.

I don't advise use of the legacy data.  harmonics-dwf from
http://www.flaterco.com/xtide/files.html is maintained by me.  The
legalese for harmonics-dwf is at
http://www.flaterco.com/xtide/harmonics_boilerplate.txt.  See
http://www.flaterco.com/xtide/faq.html#60 for background on why there
is so much of it.

> A-1: How do you think of providing libtcd shared dynamic library seperately?

This makes sense if you really do want to deliver tideEditor or other
extras in Fedora.  But do you *really* want to do that?

> A-2: If you agree with provide libtcd.so, how should we determine soname?

Deferred pending answers to previous.

> A-3: Related to A-2, should we provide libtcd.so (if you agree) with COMPAT114
>       defined or undefined? (Note: tcd-utils 2005-08-11 can _NOT_ be compiled
>       with COMPAT114 _defined_).

Do not define COMPAT114.  AFAIK only the Naval Oceanographic Office
ever used this, and they might not even still use it.

> A-4: Do you have any plan to provide seperate libtcd tarball?

Deferred pending answers to previous.

Separate maintenance of libtcd would help me in case libtcd needs
maintenance when XTide doesn't, but for the 99% of users it would be
an annoyance to have to do two installs instead of just one.

FYI, the libtcd bundled in XTide 2.9 DEVELOPMENT incorporates bug
fixes that are important ONLY to tideEditor, but for tideEditor they
are serious.  If Fedora wants to ship tideEditor as part of its
distribution, then we (including me) need to do whatever is necessary
to enable tideEditor to be linked with the newest libtcd, rather than
the one that is bundled with the stable XTide 2.8.3.

> B.
> Another issue of packaging are tideEditor issue. The reviewers of XTide says
> that tideEditor should belong to XTide package as:
> * the other binaries in tcd-utils (build_tide_db and restore_tide_db) are only
>   command line conversion tools and have less dependency.
> * on the other hand XTide, tideEditor is a graphical viewer (tideEditor is also
>   a viewer) and have a lot of dependency (especially tideEditor depends on Qt).
> 
> So,
> B-1: how do you think of moving tideEditor to XTide tarball?

It would make sense if it were used by more than 1% of users.  But I
don't think that it is, or would be, even if it were installed for
them automagically.  It is only potentially useful if an end user
manages to find some tide data that they want to add, and then only if
they know what they are doing.  This happy coincidence just doesn't
happen as often as you would hope.

FYI, I am currently in the midst of a 100% code review and cleanup for
XTide.  This is a good time to incorporate changes to make life easier
for Fedora, but not a good time to assume that the latest snapshot is
stable.

Patrice Dumas wrote:
> I guess that a full security audit of xttpd would be nice, however
> it would go beyond a review.

I will cooperate with a security audit of xttpd and implement any
mitigations that are indicated, but if it does show any problems that
are hard to address it might be better to retire it.  I constructed
xttpd as a proof-of-concept that you could put an HTTP interface on
XTide, hoping that web developers would pick up the ball and run with
it.  They didn't.  They preferred to stick with CGI, or nowadays with
PHP.

Other FYIs:

With respect to patching configure to do CFLAGS etc. as expected, I
have a guy who is supposedly reorganizing the whole thing according to
current best practices and making it NetBSD-friendly.  Haven't heard
from him in a month or so, but I can put you in touch to coordinate
changes.
Comment 79 Mamoru TASAKA 2006-11-13 06:20:34 EST
(In reply to comment #78)
> Upstream here. 
Thank you for replying to me and joining this bugzilla ticket.

> tcd-utils is for the other 1% who actually do know enough to edit tide
> data in a meaningful way and have reason to do it.  It was never
> cleaned up for the 99% market.  The people who use it (counted on one
> hand) have never complained about having to compile it from ugly
> source snapshots.
My idea is that providing tcd-utils is very preferable for people
who lives where the tcd data is not provided originally (like me, in
Japan). The person may get harmonics data near their location and
may have to create tcd data by their own.

> 
> The inclusion of tcd-utils in Fedora was perhaps motivated by some
> policy that discouraged shipping binary files?
Originally it was so.

> harmonics-dwf from
> http://www.flaterco.com/xtide/files.html is maintained by me.  The
> legalese for harmonics-dwf is at
> http://www.flaterco.com/xtide/harmonics_boilerplate.txt. 
Umm, anyway I cannot include harmonics-dwf data into this package
because the restriction of 'non-commercial' or 'without charge' cannot
be accepted.

> > A-1: How do you think of providing libtcd shared dynamic library seperately?
> 
> This makes sense if you really do want to deliver tideEditor or other
> extras in Fedora.  But do you *really* want to do that?
For the left two utilities in tcd-utils (build_tide_db, restore_tide_db) 
is preferable as described above. Those who have to get harmonics data
by themself may want to use tideEditor, too.

> > So,
> > B-1: how do you think of moving tideEditor to XTide tarball?
> 
> It would make sense if it were used by more than 1% of users.  But I
> don't think that it is, or would be, even if it were installed for
> them automagically.  
Patrice and Michael, what do you think of this?

Comment 80 Patrice Dumas 2006-11-13 07:36:33 EST
(In reply to comment #79)

> Patrice and Michael, what do you think of this?

First I'd like to thank David for joining to this ticket.

I am not sure that the argument about 1% users is a show
stopper for inclusion in extras. As strange as it may look,
having 1 fedora user use a program may be a sufficient reason 
to include it in extras. Indeed if this user really want to 
have a rpm to ease system management he will rebuild it 
locally anyway. But then if he rebuilds it locally, building it
in extras isn't much additional work and then you get 'for free'
easy reinstallation with yum install, interesting in case you move
to another location or have to reinstall your computer, rebuild on 
all extras supported arches - interesting in case you buy a new 
computer, and more visibility for others to help you fix your 
package. And then if you have 2 users it becomes very interesting
since it avoids double work on creating and rebuilding local rpms.
Others may have different opinions, but even for packages I may 
be the only one to use in fedora (or even on earth) I prefer to
have it in extras for the ease of system management it brings with.

Anyway I don't think that build_tide_db, restore_tide_db should be
shipped with libtcd anymore, as, if I understand well they aren't of
much use now. However I still think that tideEditor may be usefull and
is worth packaging.

My current thoughts are that:
* the issue of inter-dependencies is in fact moot, we want to use the
  tcd shipped by David, and since we cannot package it in fedora due to
  licensing the way things are done to help the user get it are right.
* If David don't want to bring tideEditor in with Xtide, resplit
  tcd-utils .src.rpm and submit it separately.
* split the main package the way you like, as I still think that most
  of what I said at the end of #Comment 75 is relevant. At least
  split off libtcd and libtcd-devel which would contain only the libtcd
  library and devel package. For xttpd/common package do what you prefer.
* follow David decision regarding shared libraries.
Comment 81 David Flater 2006-11-13 23:22:25 EST
I will split out libtcd as a separate tarball and make it build as a
shared lib if a GNU/Linux environment is present.  (XTide still tries
to be portable to Solaris, HP-UX and others, but I have no prayer of
guessing the syntax to build shared libs on every platform.)

Previous transgressions notwithstanding, as of now, the libtcd version
numbering convention is intended to be compatible with the shared
library interpretation of soname = major rev = incompatible API,
except for the COMPAT114 option.  For that, I'm thinking that
COMPAT114 could be made a configure option, and if enabled, the shared
library is not built at all.  It should also add a visible qualifier
to the version string produced by the library.

I will change the XTide configure script to test for existence of
libtcd and barf if a compatible version isn't found.

I have pinged the guy who promised to fix up the configure scripts.
However that works out, I will look at the build patches attached here
and see what changes I should incorporate.

As for tideEditor, upon further review I think probably it should be
made a separate tarball too, separate from XTide and separate from the
other tcd-utils.  It is the only thing here that requires Qt, and it
is not on the same maintenance schedule as XTide at all, nor is it
especially connected to the other tcd-utils except by historical
reasons.  It will be a pain updating all the references to tcd-utils
but it seems like the right thing to do.

Does that address everything?

I hope there are no imminent deadlines looming.
Comment 82 Ralf Corsepius 2006-11-13 23:28:42 EST
(In reply to comment #81)
> I will split out libtcd as a separate tarball and make it build as a
> shared lib if a GNU/Linux environment is present.  (XTide still tries
> to be portable to Solaris, HP-UX and others, but I have no prayer of
> guessing the syntax to build shared libs on every platform.)
Using libtool should solve this problem for you.
Comment 83 Mamoru TASAKA 2006-11-14 10:37:22 EST
Okay, I keep watching for xtide repackaging by upstream
(again, thanks to David for joining this bugzilla ticket).

I will repackage xtide again when some repackaing changes are
done.
Comment 84 Patrice Dumas 2006-11-16 03:39:25 EST
(In reply to comment #81)

> Does that address everything?

I think so. Regarding libtool, it is very easy to use it when also 
using autoconf/automake, maybe it is less simple without automake,
but certainly still doable.
Comment 85 David Flater 2006-11-16 22:45:16 EST
I'm finding success with automake and libtool.  For libtool, is it still safe to
start my libtcd.so version-info at 0:0:0 or will this conflict with previously
deployed Fedora packages?  What's a safe "current" number to start with?
Comment 86 Ralf Corsepius 2006-11-16 23:30:04 EST
(In reply to comment #85)
> I'm finding success with automake and libtool.  For libtool, is it still safe to
> start my libtcd.so version-info at 0:0:0 or will this conflict with previously
> deployed Fedora packages?

Don't care about the Fedora packages. You are the upstream. It's you who has the
liberty to choose them to your personal preference. Those people who released
different versions with different SONAMEs were not legitmated to do so and
committed a mistaked. Also their choices should not be a problem, because no
packages have been released so far.

>  What's a safe "current" number to start with?
For general recommendations, you might want to read:
info libtool Versioning

0:0.0 should be fine.
Comment 87 Ralf Corsepius 2006-11-16 23:32:14 EST
(In reply to comment #86)
> 0:0.0 should be fine.
Of cause, I meant 0:0:0
Comment 88 Mamoru TASAKA 2006-11-16 23:38:17 EST
(In reply to comment #85)
> What's a safe "current" number to start with?
It is up to your choice. I will repackage xtide according to your
packaging.

Only you have to take care of is that
soname should be changed according to the source code change, especially
API change.
Comment 89 Mamoru TASAKA 2006-11-21 15:10:34 EST
( Only writing the information that repackaging is in progress )
Comment 90 Mamoru TASAKA 2006-11-23 11:22:28 EST
Now packages are updated. David, thank you for
repackaing and improving xtide related packages.

All the related srpms/rpms are under
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/

The following is a copy from the mail sent from David.

---------------------------------------------------------
I made the following changes.

xtide tarball:

- To change the user and/or group under which xttpd tries to run (the
defaults are nobody/nobody), set the variables xttpd_user and/or
xttpd_group for configure.  xttpd now exits if it cannot change to the
specified user/group.

    bash-3.1$ xttpd_user=xttpd xttpd_group=xttpd ./configure

You can also set the webmaster address for xttpd this way if you like.

    bash-3.1$ webmasteraddr="somebody@somewehere.else" ./configure

- Instead of always barfing when HOME is unset, barf only when the
need arises to write something to the home directory, and do without
any config files that would normally be there.  Setting HOME for xttpd
thus becomes optional, eliminating a common source of confusion.

tideEditor tarball:

- Get name of TCD file to edit from command line instead of HFILE_PATH.
- Check /etc/xtide.conf for WVS_PATH if environment variable is not set.
- Provided icon-64x64.png for use with desktop environments.

tcd-utils tarball:

- Automaked and cleaned up without tideEditor.

I was going to review the RPMs to see if I missed anything (it is not
trivial since under Slackware we do not use RPMs) but I was unable to
access http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/
when I tried this afternoon.  So I downloaded the xttpd rc script from
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211626 (attached
on 2006-10-26) and put this in the XTide tarball as
scripts/Fedora/rc.xttpd.
-------------------------------------------------------------------------------
Then:

* For xttpd
  xttpd binary is still wrapped so that we change the enviroment needed
  by xttpd to arguments (which is needed for using 'daemon' function
  in /etc/rc.d/init.d/functions)

* For tideEditor
  Now tideEditor take a tcd file as a argument, not environment. For launching
  tideEditor from GNOME Menu, we have to give one argument (tcd file) to
  tideEditor. So for GNOME/KDE Menu usage only I give a wrapper script for
  tideEditor (i.e. normally there is no need for tideEditor wrapper script
  so usually I don't call the script, only for GNOME/KDE menu usage).

* Packaging:
  Now libtcd, xtide, tcd-utils, tideEditor are seperated.
  xtide, tcd-utils, tideEditor all require libtcd.

  Still I create small package 'xtide-common' which is required by
  xtide and tideEditor.
  xtide/xttpd package are unified.

Perhaps at last I have to submit a new review request for libtcd, tcd-utils,
tideEditor, however, before doing so I want to have a discussion on
this bug report, especially for packaging issue.

FILES:
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SPECS/libtcd.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SPECS/tcd-utils.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SPECS/tideEditor.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SPECS/xtide.spec

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SRPMS/libtcd-2.2-1.fc7.src.rpm
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SRPMS/tcd-utils-20061120-1.fc7.src.rpm
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SRPMS/tideEditor-1.3.12-1.fc7.src.rpm
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SRPMS/xtide-2.9-0.1.date20061122.fc7.src.rpm
Comment 91 Patrice Dumas 2006-11-24 04:43:21 EST
I have checked all the packages, everything seems right. Much thanks
to David for changing his packages, now the packaging is much simpler.
Hoping that it also profits to him...
The recursive dependency issue is even sorted out as a side effect
of rearranging the sources, and libtcd should be multilib.

I have spotted those issues:

* I think that libtcd qualifies for keeping the static library
  since it could be used to handle trusted data in numerical
  experiments where compiling statically enhance portability. 
  You can keep it out, as long as you respond favorably to
  users asking to have it back.

*
/usr/libexec/tideEditor-desktop: line 30: [: too many arguments
there is a -or instead of -o

* in the latest line of xtide-README.fedora one should read
/usr/share/xtide-harmonics instead of /usr/share/wvs-data. Also
maybe administer should be changed to administrator.

* tideEditor-desktop may be in %{_bindir} to avoid hardcoding
/usr/lib/libexec in desktop file (since using %{_libexecdir} is 
not easy)

* for the xttpd wrapper it is less easy to use properly the
macro. Maybe a simple 
sed -e 's,/usr/libexec/,%{_libexecdir},' ....
on the script would do the trick.

* there are other hardcoded file path in the -common subpackage, but
these ones are not problematic in my opinion since they are in clearly 
fedora packaging specific parts under our complete control.


Now I think you should submit reviews for each package, I think that
you can reuse your closed tickets or open new ones, at your will.
Comment 92 Mamoru TASAKA 2006-11-24 11:47:24 EST
Thanks, Patrice.
I will recheck my package and resubmit them. I would rather
open new bug reports to avoid confusion.

NOTE: I am now taking a semi-vacation with my parents and so
resubmitting new package may be on Sunday or Monday 
(in Japan, EST+14h. Currently it is around 2 AM on 25th, Sat).
Comment 93 Mamoru TASAKA 2006-11-26 04:29:39 EST
Well, for tideEditor-desktop.sh, David mailed to me:

------------------------------------------------------
For tideEditor-desktop.sh I have the concern that the user who invokes
it will not realize that the edits are occurring to a local copy and
won't show up in XTide without changing HFILE_PATH.
------------------------------------------------------

Patrice, how do you think of this?
* I think that providing tideEditor desktop is preferable and in
  that case a local copy of tcd file is necessary as tideEditor requires
  tcd data to be launched.
* If copying tcd file to local with silence should be avoided, then
  providing tideEditor desktop should be stopped accordingly, however,
  perhaps it is not preferred.
Comment 94 Patrice Dumas 2006-11-26 05:17:01 EST
(In reply to comment #93)
> Well, for tideEditor-desktop.sh, David mailed to me:
> 
> ------------------------------------------------------
> For tideEditor-desktop.sh I have the concern that the user who invokes
> it will not realize that the edits are occurring to a local copy and
> won't show up in XTide without changing HFILE_PATH.
> ------------------------------------------------------
> 
> Patrice, how do you think of this?

I think that David is right. As long as there is no file chooser
it is not very convenient to start tideEditor without command line 
argument.

So I think the best would be to drop the wrapper and .desktop file,
tideEditor users are certainly knowledgable enough to be able to
open a shell to launch tideEditor.

This is against the guidelines, but I think this is acceptable since
tideEditor is not meant to be started without argument.
Comment 95 Mamoru TASAKA 2006-11-26 06:04:59 EST
(In reply to comment #94)
> (In reply to comment #93)

> > Patrice, how do you think of this?
> 
> I think that David is right. As long as there is no file chooser
> it is not very convenient to start tideEditor without command line 
> argument.

Actually I have no objection to drop desktop file so I will
drop it.
Comment 96 Mamoru TASAKA 2006-11-26 08:17:24 EST
spec, srpm is updated.

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SRPMS/xtide-2.9-0.2.date20061122.fc7.src.rpm
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/packages/xtide/SPECS/xtide.spec

* Sun Nov 26 2006 Mamoru Tasaka <mtasaka@ioa.s.u-tokyo.ac.jp> - 2.9-0.2.date20061122
- Ensure the hardcorded directories in some scripts can be 
  appropriately changed.
- Fix some typo in README.fedora

Also, (as you have noticed) I submitted libtcd tcd-utils tideEditor
review requests.
Comment 97 Patrice Dumas 2006-11-26 08:35:18 EST
* rpmlint gives the ignorable
W: xtide incoherent-init-script-name xttpd
* name and release right
* follow guidelines, legible
* free software license, included
* desktop file present for X app
* init file right for daemon
* right use of macros. Not used for files in xtide-common, but the
  files are fedora specific
* match upstream
efc6b3eb603e5b51c13c5dbb7bd29548  xtide-2.9dev-20061122.tar.bz2
* %files section right

Using cvs snapshot should, in general, be avoided, but in that
case it is the way to go given that new things are needed, and also
that David worked with us.

APPROVED
Comment 98 Mamoru TASAKA 2006-11-27 09:54:16 EST
Well,
* Rebuild for FE-devel succeeded.
* SyncNeeded is requested for FE6 (FE5 branch is already there, so
  when syncing to FE6 is done, I will rebuild for FE5/6).
So I will close this bug as CLOSED NEXTRELEASE.

Now libtcd, tcd-utils, xtide and tideEditor are all imported into
Fedora Extras.
Patrice and Michael, thank you for reviewing and approving xtide 
related packages with a lot of helpful suggestion.
David, thank you for joining this discussion and repackaging and improving
upstream tarball.

Again, thank you for helping me with xtide related packages!!

NOTE: 
* I asked David about versioning issue.
* For libtcd static archive issue, I will try to keep track of
  the discussion currently proceeding on fedora-devel-list (titled 
  'Static linking considered harmful')
Comment 99 Mamoru TASAKA 2009-09-13 12:47:56 EDT
Package Change Request
======================
Package Name: xtide
New Branches: F-12
Owners: mtasaka

Early branch request.
Comment 100 Kevin Fenzi 2009-09-14 01:10:18 EDT
cvs done.

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