Hello, Attached is an ebuild for gempak-5.6.j. It requires lesstif (and consequently, xfree). GEMPAK is a powerful meteorological plotting and analysis package which produces many of the graphics which are seen on the web on a daily basis, and is particularly popular with educational institutions. I suggest placing this ebuild in app-sci/gempak, and strongly recommend keeping it masked as the vast majority of users have no need for it and one of the component GUI applications, nmap2, is not functioning correctly. This is a minor detail, however, as everything else seems to be working well, and the real power of GEMPAK lies in scripting. Thanks, --Don Giuliano
Created attachment 19767 [details] GEMPAK ebuild tarball (includes several supporting files) This tarball attachment contains the GEMPAK ebuild, as well as several supporting files which are used in the build process.
Created attachment 20143 [details] **REVISED** GEMPAK ebuild tarball (with supporting files) Revised the ebuild to change the motif dependency from lesstif to openmotif at the suggestion of Stonie Cooper. This fixes the GUI issues I had been having with nmap2 and garp (not previously mentioned). Also, made lesstif a != dependency as a result, as well as gcc-3.3, since the f77 compiler for gcc-3.3 is reported (also by Stonie) as being broken at present. Thanks Stonie!
This is a valuable entry to the portage tree; please make Don's ebuild part of the standard *stable* gentoo installation. Stonie Cooper
It would be very much appreciated if, in the future, you would attach files as plain-text, with the ebuild and supporting files as separate attachments. I'm taking a look at them now.
OK, I'll be sure to submit the files as individual attachments from now on. I thought I was making things easier by submitting it as a single tarball, but I guess not. :-\ Thanks for pointing that out. Also, in just a moment I'll be submitting an updated ebuild and change the gui.c supporting file into a patch (I'd overlooked this before!).
Created attachment 20147 [details] Updated Ebuild for gui.c patch
Created attachment 20148 [details, diff] gui.c patch file
Created attachment 20149 [details] **REVISED** Updated Ebuild for gui.c patch Fixed an oops in the ebuild that caused the patch to not apply at all (incorrect filename).
This ebuild could use a little work. Take a look at the savagedemo ebuild for a rough idea of how to force fetching. It should use RESTRICT="fetch" and messages should be in pkg_setup(). Unpacking and pre-compilation things should be done in src_unpack(). As for the run_make.bash, that's really bad. You can just export the variables in the ebuild, or preferably set them in src_compile() as local variables if that works. Also as I was hinting earlier, the compilation needs to take place in src_compile() and the installation (e.g., make install and other things) in src_install(). Try to get any version-number-specific things out of the ebuild if possible (VERSION=5.6.j). Instead see if you can figure out a way to get that from PV and some bash. 'man bash /Parameter Expansion' may prove helpful in this. MY_PV="${PV/[a-z]/.[a-z]}" seems like it might work out fairly well. The dependency on !=sys-devel/gcc-3.3 is pretty ridiculous. Could you please test using the latest ~arch gcc in portage to see if g77 is broken as suggested?
I notice that even though you're attaching as single files, the type is still binary. Make sure you change the type to text/plain. Also when making diffs, please use diff -urN.
Oh yeah. I was reminded that the fetching message should go in pkg_nofetch(), not pkg_setup(). I confused the two.
OK, I'll work on these issues. I also have a question for you. When I'm done making modifications to the ebuild and I repost the ebuild/patch, should I also repost all the other supporting files individually so as to make them more easily available? Or should I just leave things as they are, only providing updated files as necessary? Thanks for your patience.
It would be helpful for all the files (not including digest, Manifest or the run_make.bash which is going to disappear) to be posted individually as text/plain. Then you can obsolete individual files as necessary if they change.
MY_PV="${PV:0:${#PV}-1}.${PV:${#PV}-1}" might be even better. mr_bones_ suggested it.
Many thanks for the bash tip, that works great. I have the issues you raised resolved, and am in the process of testing the gcc-3.3 compatibility. I'll be posting updated files as soon as I finish up.
OK, the code for one of the GUI applications (garp) is in fact incompatible with gcc-3.3 due to its use of now-obsolete header files that gcc-3.2 would still accept. However, I do not see this as sufficient reason to ban gcc-3.3, esp. as it is simply a matter of writing a small patch to make Garp gcc-3.3 compliant, and everything else seems to work fine. Therefore, I am uploading the updated files, and believe that this ebuild is ready to go. The Garp problem with gcc-3.3 is, in my opinion, almost a non-issue, though I'll try to fix it as soon as I can. If there are any other problems with the ebuild, please let me know and I will take care of them.
Created attachment 20158 [details] Gemenviron.bash: GEMPAK configuration file The Gemenviron.bash file is simply a bash version of the main GEMPAK environment configuration file.
Created attachment 20159 [details] Gemenviron.tcsh: GEMPAK configuration file The Gemenviron.bash file is simply a tcsh version of the main GEMPAK environment configuration file.
Created attachment 20160 [details] Makeinc.common.1: Part 1 of the Makeinc.common config file The first part of the Makeinc.common file, the purpose of splitting it up like this is evident in the ebuild.
Created attachment 20161 [details] Makeinc.common.2: Part 2 of the Makeinc.common config file The second part of the Makeinc.common file.
Created attachment 20162 [details] gemdatadir_create: Shell script for creating skeleton gem data dir This shell script automatically creates a skeleton GEMPAK data directory tree.
Created attachment 20164 [details, diff] gui.c.patch: Patch file for fixing hard-coded bitmap paths The Garp file gui.c ($GEMPAK_SOURCE_HOME/comet/garp/gui/gui.c) has the paths to a number of bitmaps hard-coded into the source. This patch changes the paths appropriately given the location the ebuild installs the package to.
Created attachment 20165 [details] unset_vars: A list of all variables in the Gemenviron file This file contains a list of all the variables present in the Gemenviron file. It is necessary to unset all of these variables before attempting to compile, as otherwise they will cause problems with the build process.
Created attachment 20166 [details] gempak-5.6j.ebuild This is the GEMPAK ebuild.
Comment on attachment 20164 [details, diff] gui.c.patch: Patch file for fixing hard-coded bitmap paths Marked gui.c.patch as being, in fact, a patch.
One additional note: I neglected to delete the gcc-3.3 anti-dependency, though it is commented out.
OK I've been looking through this some more. I reworked the ebuild (attached shortly). Things left to do: 1) Changing the Makeinc.common thing to a sed. It's just cleaner. The general idea is to make the number of files in addition to the ebuild as minimal as reasonable. 2) Fix a couple of errors compiling, presumably a header problem. Log of errors coming shortly. 3) Stop installing everything! Source files should not be installed! Cause 'make install' to install to ${D}/usr/gempak instead of that nasty cp -Rf. If absolutely necessarily, we could delete all the Makefile-type things, *.c, *.h, *.o files, but that is poor. 4) See if the 'ebuild config' part actually works. It should, but it needs verification. 5) Make sure it works...anything else we didn't think of.
Created attachment 20227 [details] gempak-5.6j.ebuild
Created attachment 20228 [details] Errors from attachment #20227 [details].
Created attachment 20229 [details, diff] gui.c.patch version 2
Created attachment 20230 [details] gempak-5.6j.ebuild Slight modifications to reduce verbosity on unpacking, and a couple of other things.
OK... 1.) Easy, I thought about doing it before and should have. Silly me. 2.) Just so I know, are you using gcc-3.3? I've never had that problem with gcc-3.2, and would like to make sure it's not something odd that I haven't seen. I'll see if I can fix it. 3.) The only reason I left it like this was because conventionally GEMPAK is installed as I did it--agreed, it is very unclean and poor practice. Thus I'll see what I can do about it. GEMPAK is not a clean application suite by any stretch of the imagination, but you're right, I can make the typical install much cleaner. 4.) I like what you did with pkg_config(), that's pretty cool. I'll check it to make sure it works. 5.) Any other problems I run across I'll take care of.
$ gcc --version gcc (GCC) 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)
Alright, I've been working on your suggestions and here's what I have: 1.) Done. 2.) I haven't found a solution for this. I've searched on the web quite a bit, and the only suggestions I find are "change <varargs.h> to <stdarg.h> in your source files", which of course we've already done. Thus Garp still doesn't work with gcc-3.3. 3.) It would be inadvisable to attempt to get the Makefile(s) to install everything to /usr/gempak. There are a large number of files (configs, maps, tables, and quite a bit of other stuff) which the Makefiles never touch that are absolutely necessary, and would not be transferred into /usr/gempak without doing several "cp -Rf" commands anyway. I've opted for removing all the unnecessary files first and then doing a "cp -Rf" on the remainder. It's not pretty, but I consider it to be the "least ugly" solution. 4.) pkg_config() does not appear to want to accept command-line arguments. I tried searching through other ebuilds that have a pkg_config(), as well as looking through the forums, but I couldn't find any packages that wanted to accept arguments for the ebuild config process, or anyone that wanted to do something similar. Should I try posting to the forums about this? 5.) I've made a couple small changes to the ebuild other than this, but nothing particularly spectacular. Basically I just versioned it up to gempak-5.6k (I'd avoided it earlier because I'm always paranoid about moving up to a different gempak version, and I knew I had 5.6j working correctly on my machine). Also, I commented out the obsolete header update (see below). -------------- Current Status -------------- With gcc-3.2, everything seems to work flawlessly, so long as varargs.h is used instead of stdarg.h. With gcc-3.3, everything but Garp installs and works fine (I tried using the gcc-3.2 varargs.h in place of stdarg.h as someone suggested online, but that did not work). Since Garp is really a very small part of the GEMPAK suite, gcc-3.3 is still experimental anyway, and practically everyone installing this will be doing so in a stable environment (i.e., stable gcc), I propose just placing an einfo comment at the end of the install notifying gcc-3.3 users that Garp does not currently function properly. Then as soon as Garp is updated to account for the new version of gcc, the problem (small as it is anyway) will simply go away.
Created attachment 20245 [details] **Revised** Makeinc.common
Created attachment 20246 [details, diff] gui.c.patch -- Changed paths to /usr/gempak
Created attachment 20247 [details] gempak-5.6k.ebuild
Is is possible to do all the deletion before needlessly copying it over to ${D}? 2) Still needs some looking into. I haven't been able to track it down. 4) Fixed. looks like GEMDATADIR was getting set somehow, so I changed the variable name. 5) Since obsolete headers aren't only in garp, I re-added the update for >=gcc-3.3. Also some general cleanup and update to 5.6l, which they versioned 5.6l.1 so I added EXTRAVER near the top.
Created attachment 20504 [details] gempak-5.6l.ebuild
There's absolutely no reason to copy the files and then delete them, so I fixed that. Also, I added in an ebegin for copying the files, and added in a check for the existence of the data directory in pkg_config().
Created attachment 20508 [details] gempak-5.6l.ebuild Updated the ebuild as described above.
Created attachment 20509 [details] gempak-5.6l.ebuild Noticed I had indented a couple things improperly.
Created attachment 20511 [details] gempak-5.6l.ebuild Switched DEPEND and RDEPEND, pulled gcc checking and variable unsetting/setting out to functions to reduce code duplication, moved a sed up to src_unpack(), made the installation verbose, changed some echos to einfos, and a few other tweaks.
Any idea why a 'sed -i' doesn't work on the Makeinc.common? It acts as if NAWIPS isn't set if I try to do that.
The Makeinc.common I've included as an attachment includes a number of changes to it as compared to the original one, and NAWIPS must be the first variable defined in the file. I'm not sure if this is what you were asking, though. Also, I tried making a patch from Makeinc.common.gentoo to Makeinc.common (similar to the gui.c.patch file), and for whatever reason GEMPAK will not compile correctly using the patch, even though I verified that the patched Makeinc.common file in ${S}/config is, in fact, completely correct after a sed -i has been applied to it, and identical to the Makeinc.common file generated by the working method currently used in the ebuild! This makes no sense to me at all, but that's what is happening. I'm attaching the Makeinc.common.patch file if that helps at all.
Created attachment 20557 [details, diff] Makeinc.common.patch
To clarify my earlier comment, the "original" Makeinc.common file I refer to is the one in the gempak tarball, and the Makeinc.common attachment is the one marked as **Revised**.
OK, I guess we're stuck copying over instead of just applying a patch, because it mysteriously won't work. The last thing we need to look at is those compilation errors on gcc 3.3. It would be really nice to track those down and provide a patch.
I've done a little more research into the gcc-3.3 issues, and discovered that the problem lies in the way variadic functions (ones accepting a variable number of variables) have historically been handled in UNIX. The ISO-defined way of doing it is with stdarg.h, the older way of doing it in gcc was with varargs.h. There are a couple differences with regards to how variadic functions are defined that are causing the errors. Unfortunately, wprint() is such a variadic function, and is spread throughout the code in a number of locations--I'm not totally sure exactly how it all works, but I think wprint() might be something of a proxy for vsprintf() since vsprintf() is not defined on older BSD systems, as noted in the comments in comet/garp/gui/log.c. You can read more about it at the following URL: http://docs.linux.cz/glibc-manual/libc_35.html#SEC685
Nice find. Looks like if you fix va_start and get rid of va_dcl so it uses the new form instead of the old form things might work. I'm not sure why there was no error in ./comet/garp/gui/status.c. Looks like a bunch of other files that use va_start might have it dually defined from a quick grep, one in each format. Try 'grep -r va_start ./' (and va_dcl) from the top of the source and see if you can figure out how to fix it. Or you could just wait until a fixed version is released. However I want this to work on gcc 3.3 before it's in portage, because although it's not stable now it may be anytime.
OK, I'll take a closer look at this issue--I hadn't realized gcc-3.3 was that close to going stable. I'll post the results of my investigation in a few hours.
I don't know the status of gcc 3.3, that's my point. Regardless, GEMPAK will need to be safe for >=3.3 at some point. You could try contacting the developers and pointing out that garp is broken on new gcc.
Good point. I admire your attention to detail...this type of approach is what makes Gentoo the best Linux distribution out there, in my opinion. As far as this issue is concerned, I think I have solved it and am recompiling now. After examining some of the other files which had it dual-defined, I believe the solution to be very trivial and am testing it now.
Alright, I've got it working. I'll be attaching patches for log.c and gprint.c, as well as an updated ebuild that only applies the patches if for gcc-3.3 or greater.
Created attachment 20564 [details, diff] gprint.c.patch
Created attachment 20565 [details, diff] log.c.patch
Created attachment 20566 [details] gempak-5.6l.ebuild
Sorry, I've been distracted by other things. I'll get to this again after Thanksgiving weekend.
That's what I figured, esp. after I saw this week's GWN stuff relating to freedesktop.org, etc. Thanks for the update!
OK, I'm back to this. You redid the whole gcc_check() by hand for your check, so I'm changing that. Also, does this stuff actually break gcc-3.2? I thought the old version was deprecated and the new worked in 3.2, but perhaps not?
Presumably it's a good idea to actually have the stuff be runnable after install. I've never gotten to that point before so haven't run into this yet. Something like this in src_install(): echo "BINDIR=/usr/gempak/bin/linux" >> ${T}/10gempak insinto /etc/env.d doins ${T}/10gempak ought to work...
Created attachment 21753 [details] ebuild with gcc_check fixes, but lacking env.d file.
Created attachment 21754 [details] ebuild with env.d stuff.
Good call with the gcc-3.2 issue, you're absolutely right about that. I compiled/tested it just to make sure, and it works fine when using gcc_check "3" "2". As far as the /etc/env.d stuff is concerned, it must be noted that in order for GEMPAK to function, the Gemenviron.{bash,tcsh} file must be sourced, as it is loaded with environmental variables that need to be set. I tried copying Gemenviron.bash to /etc/env.d/10gempak, but it didn't work, and I got the following error when running env-update: !!! Invalid token (not "=") NAWIPS !!! Parsing error in /etc/env.d/10gempak Any ideas?
Geez, sorry about the lack of returns in the previous comment...here it is again, this time in a more screen-friendly format: Good call with the gcc-3.2 issue, you're absolutely right about that. I compiled/tested it just to make sure, and it works fine when using gcc_check "3" "2". As far as the /etc/env.d stuff is concerned, it must be noted that in order for GEMPAK to function, the Gemenviron.{bash,tcsh} file must be sourced, as it isGood call with the gcc-3.2 issue, you're absolutely right about that. I compiled/tested it just to make sure, and it works fine when using gcc_check "3" "2". As far as the /etc/env.d stuff is concerned, it must be noted that in order for GEMPAK to function, the Gemenviron.{bash,tcsh} file must be sourced, as it is loaded with environmental variables that need to be set. I tried copying Gemenviron.bash to /etc/env.d/10gempak, but it didn't work, and I got the following error when running env-update: !!! Invalid token (not "=") NAWIPS !!! Parsing error in /etc/env.d/10gempak Any ideas? loaded with environmental variables that need to be set. I tried copying Gemenviron.bash to /etc/env.d/10gempak, but it didn't work, and I got the following error when running env-update: !!! Invalid token (not "=") NAWIPS !!! Parsing error in /etc/env.d/10gempak Any ideas?
OK, whatever, I don't know what I did in the text box on the webpage, but sorry for the messy comments. I'm not going to clutter the bug report page even more attempting to re-post the comment again.
Created attachment 21767 [details] env.d file
Created attachment 21768 [details] updated ebuild
einfo is still outdated, refers to Gemenviron files. env.d file has datadir hardcoded. We might want to hardcode it to somewhere other than /data/gempak (/usr/gempak/data?) both in env.d file and auto-create it there as well instead of having that configurable.
OK, I think making GEMDATA be /usr/gempak/data sounds fine, especially since anyone using a different location can simply symlink it there. I've updated both the ebuild and env.d file to reflect this change, and also fixed a couple typos in the env.d file.
Created attachment 21779 [details] Updated Ebuild
Created attachment 21780 [details] Updated env.d File
Created attachment 21781 [details] Updated Ebuild Fixed problem with hrs & hds symlinks in the ebuild.
Created attachment 23219 [details] Update Ebuild Fixed typo in pkg_postinst(), and added wording encouraging people with pre-existing data directories to symlink it to /usr/gempak/data.
I just checked in 5.6m with a few changes, keyworded ~x86 only. Let me know how it works and whether it works on other arches.
OK, I've been using this for over a week now with no problems whatsoever. The only thing I really noticed is that the name of the file downloaded from Unidata is different from the filename expected by the ebuild in the distfiles directory, so I had to change the filename myself. I'm not sure how the gempak ebuild works on other arches, because I don't have administrative access to any non-x86 machines running gentoo. At any rate, on x86 machines gempak seems to be working perfectly. Thanks again for your help.
That's odd, the filename matches perfectly here. donnie@supernova molden $ emerge gempak -fp Calculating dependencies ...done! >>> md5 src_uri ;-) gempak_upc5-1.6.m.tar.gz >>> md5 src_uri ;-) gempak_upc5-1.6.m.tar.gz
Shouldn' that be: gempak_upc5.6.m.tar.gz instead of: gempak_upc5-1.6.m.tar.gz
Nope, because that's the name of the tarball I downloaded.
The only source file I see on there right now is gempak_upc5.6.m.tar.gz. Perhaps they changed the filename at some point?
