Bug 211626
| Summary: | Review Request: xtide - Calculate tide all over the world | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mamoru TASAKA <mtasaka> |
| Component: | Package Review | Assignee: | Patrice Dumas <pertusus> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dave, pertusus |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | Flags: | kevin:
fedora-cvs+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-11-27 14:54:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 212258, 217277 | ||
| Bug Blocks: | 163779, 217279 | ||
| Attachments: | |||
|
Description
Mamoru TASAKA
2006-10-20 14:52:29 UTC
Once close, then reopen because I cannot get back the status of this bug to NEW . 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. (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/ ). *** Bug 211623 has been marked as a duplicate of this bug. *** *** Bug 211625 has been marked as a duplicate of this bug. *** 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.
Created attachment 139055 [details]
modified tcd-utils Makefile patch which adds LDFLAGS.
> # 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. 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 ? Oh forgot, I will stop using %%optflags. 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. (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. (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 (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. 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. (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. (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. (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. Well, new spec & srpm is 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.3.dev20061015.src.rpm 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
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
Created attachment 139071 [details]
use CFLAGS set by the user
The second patch replaces libtcd-2.3.1-shared.patch. 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. 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. 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 (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 In the icon directory there is a 48x48 icon, it should be installed in the hicolor theme, too. (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. 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. (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 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. (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> 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? Ah...
C. Well I won't include WVS data until the license of this data
get clear.
Ok, I'll come with something today. (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. (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. 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.
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." Thank you for lots of help!! Well, I will look into them..... Today I take a rest. 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. (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. 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 Well, I split WVS data. 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.8.dev20061015.src.rpm And https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212258 Changed slicely for wvs-data directory change. 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.9.dev20061015.src.rpm * 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? 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 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. 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). 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.
Well, please check the attachment in my comment #51 ? If it is okay, I will replace xttpd.init with the attachment. 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.
(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....). (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. 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. * 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.
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..... (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? Created attachment 139619 [details]
minor change to remove unneeded substitutions of nobody by xttpd
(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 ) (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. 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. 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. 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. (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. 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.
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. (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. 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
(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. (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 ;-) 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?
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. (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. Well, I will mail to upstream today (in Japan). NOTE: I will be busy through next Wednesday and I may have less connectibity. I mailed to upstream. 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. (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? (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. 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. (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. 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. (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. 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? (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. (In reply to comment #86) > 0:0.0 should be fine. Of cause, I meant 0:0:0 (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. ( Only writing the information that repackaging is in progress ) 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" ./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 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.
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). 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. (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. (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. 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.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. * 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 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') Package Change Request ====================== Package Name: xtide New Branches: F-12 Owners: mtasaka Early branch request. cvs done. |