I've made ebuilds for gEDA (www.geda.seul.org), gzipped ebuilds will be attached... Testing would be appreciated, but the compiling seems to go fine at my end...
Created attachment 12511 [details] gEDA ebuilds
1/ geda-projman-20030525 has been replaced by geda-20030525 2/ geda-gschem-20030525.ebuild should have libgdgeda as a dependency otherwise gschem can't produce PNG pics of the schematics, a useful function. 3/ geda-gnetlist-20030525.ebuild shows various Xfree dependencies yet its a cli app that would most often be run thru a xterm. 4/ ditto with geda-gsymcheck-20030525.ebuild
Release candidate 1 will be attached... a) Projman now intergrated -> gEDA package b) GSchem has a libgdgeda dependancy c+d) gnetlist+gsymcheck KEEP their XFree dependancy (it's in the config script) (no clue why...) z) Please test this and tell me if you have any GTK errors: I might need to make a patch to remove them. This only applies to the "geda" application...
Created attachment 13851 [details] gEDA ebuilds - RC1
Taking over development and testing for this; the bug will be reassigned back to component managers once a working finalized version is done (the current one is about 100%-1% ready; i.e. "geda" doesn't work...)... Everything tested and works; expect the "geda" application - currently investigating...
:) no problem. let me know once its all working Thanks!
Update: version bump to RC2--; looks like a) I missed two needed files out in the RC1 release and b) geda-gschem should now work on standalone (and with the geda-metapackage if one wants it!)... Not tested here though; please test...
Created attachment 13913 [details] gEDA -- RC2 Now with libstroke; libgeda/libgdgeda (somehow missing in RC1); and a standalone geda-gschem (?)...
I htnik there is problem in libgdgdea because only 2.0.15 is available : >>> emerge (7 of 16) app-sci/libgdgeda-2.0.9 to / >>> Downloading http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo//distfiles/libgdgeda-2.0.9.tar.gz --20:06:06-- http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/distfiles/libgdgeda-2.0.9.tar.gz => `/usr/portage/distfiles/libgdgeda-2.0.9.tar.gz' R
I htnik there is problem in libgdgdea because only 2.0.15 is available : >>> emerge (7 of 16) app-sci/libgdgeda-2.0.9 to / >>> Downloading http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo//distfiles/libgdgeda-2.0.9.tar.gz --20:06:06-- http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/distfiles/libgdgeda-2.0.9.tar.gz => `/usr/portage/distfiles/libgdgeda-2.0.9.tar.gz' Résolution de cachedaim... complété. Connexion vers cachedaim[172.20.0.6]:3128...connecté. requête Proxy transmise, en attente de la réponse...404 Not Found 20:06:07 ERREUR 404: Not Found. >>> Downloading http://www.geda.seul.org/dist/libgdgeda-2.0.9.tar.gz --20:06:07-- http://www.geda.seul.org/dist/libgdgeda-2.0.9.tar.gz => `/usr/portage/distfiles/libgdgeda-2.0.9.tar.gz' Résolution de cachedaim... complété. Connexion vers cachedaim[172.20.0.6]:3128...connecté. requête Proxy transmise, en attente de la réponse...404 Not Found 20:06:07 ERREUR 404: Not Found. !!! Couldn't download libgdgeda-2.0.9.tar.gz. Aborting.
Yes, this ebuild is horribly out of date and I need to update it.
plasmaroo, I have made some new ebuilds for the 20030901 release of geda. You have probably already done the same perhaps? If not I can send you the files, along with the problems I have. There are not too many problems. The only ones are to do with gwave and gtkwave, but geda itself seems fine, and gtk2 is working in gschem! It looks pretty nice with gtk2. Let me know your status... Thanks, Dave
I also now have patches which patch the geda-20030901 source to the latest gsch2pcb version 1.0.1
Would it be stupid to create a bug report for all the new ebuilds? It seems slightly more convenient, yet less at the same time.
Just attach things here...
Created attachment 21395 [details] geda-releated-ebuilds.tar.gz ver. 20030901 untar in the app-sci directory of your local portage
TODO: -Make gschem have IUSE="gtk2" and pass to configure. This probably takes two seconds to do, but I just thought of it now. Please let me know if you work on anything major related to these ebuilds, so I don't repeat the work. -Make some of the rc* files go to /etc/ so there can be system level config files and user doesn't need to edit stuff in /usr/
Okay, the tarball system where we branch gEDA components is getting scrapped. I'm currently working on getting * all * dependencies to compile and work, and once I'm done with those I will release the gEDA ebuild [ with GTK+2 support ].
Just curious, what's the reason for scrapping the current method? I mean I know that Gentoo seems to like to put everything into one package, like kdetoys as an example, includes many useless packages even though all I really want is kweather. I'd just like to understand the reasoning behind it. I haven't quite decided which way is better. I'm sure once I can get a bigger hard drive I'll prefer single ebuilds, but right now, hard drive space is premium for me, so I prefer many packages rather than a few.
The reason kmultimedia is released as such is to best follow the KDE releases. The reason I'm scrapping the tarball and have an expanded chain of gEDA tools is that it would be * much * easier to update packages when new gEDA releases are rolled out. Secondly, I don't think this is as bad as some of the KDE packages: there, you often do get fluff you don't want. Here, gEDA "requires" [ quote ] all the gEDA components like the libraries and the symbols.
Created attachment 21512 [details] [ plasmaroo ] gEDA 20030901 ebuilds
Added gEDA 20030901 ebuilds. All the dependancies for these three ebuilds in the file are already in portage, so just run an 'emerge sync'.
I had a look at the ebuild, I'll try it out today. You're right, updating the ebuild will be a lot easier now.
It's too bad you can't use unpack ${A}, but I guess the Makefile gets in the way.
Well, for src_unpack() I don't see why one can't just do:- A_FILTERED=`echo ${A} | sed -e 's/Makefile//'` unpack ${A_FILTERED}
Can you put in the patch I made for gsch2pcb? It's necessary to make gsch2pcb work. I talked to the author of gsch2pcb and he didn't get 1.0.1 out in time for the 0901 release and thus the gsch2pcb that ships with 0901 is broken.
Can we remove the depends on gwave and gtkwave? I don't think these are necessary. And if gentoo was debian, I would say they are "recommended" or "optional" not required. I'm also not sure why gerbv is required. Maybe these should all be listed post_inst() using einfo statements, like what is done in the kdevelop ebuild nowadays. One of the biggest reasons to remove gwave dependancy is that gwave doesn't compile for me right now: gcc -march=athlon-tbird -O3 -pipe -fomit-frame-pointer -fforce-addr -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -DDATADIR=\"/usr/share\" -DBINGWAVE=\"/usr/bin/gwave\" -o gwave -lguile -lguile-ltdl -lqthreads -lpthread -lcrypt -lm cmd.o wavewin.o draw.o gwave.o event.o gtkmisc.o pixmaps.o wavelist.o dnd.o scwm_guile.o guile-compat.o init_scheme_string.o wavepanel.o rgeval.o xgserver.o measurebtn.o GtkTable_indel.o ../spicefile/libspicefile.a -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -L/usr/lib -lguilegtk-1.2 -L/usr/lib -lguile -lqthreads -lpthread -lm -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm /usr/lib/libguilegtk-1.2.so: undefined reference to `scm_listify'
Sure, I'll put the patch in. And it was version 1.0 which had the M4 fixes, not 1.0.1 according to the ChangeLogs...
Created attachment 23183 [details] [ plasmaroo ] gEDA 20030901 ebuilds V2
New ebuilds, these get the latest gsch2pcb and patch the gEDA files and I've also changed the GTKWave dependency as _pre4 was said to be unstable and very broken by the author - so I've lowered the dependency back to the next snapshot.
I just installed twice using the 20030901 V2 tar ball. I removed the packages geda, gerbv, gnucap, gperf, gtkwave, guile-gtk, gwave, iverilog, libgdgeda, libgeda, ng-spice-rework, and pcb before starting each emerge. I installed everything possible without ~x86 and then set ACCEPT_KEYWORDS="~x86" to finish off. The new ebuilds work mostly okay with the following problems observed: 1) x11-libs/guile-gtk-1.2.0.31 would fail to build with the error: checking libguile compile flags... ERROR: Unbound variable: include-deprecated-f eatures checking libguile link flags... ERROR: Unbound variable: include-deprecated-feat ures checking whether we have at least Guile 1.5.1... ERROR: Unbound variable: includ e-deprecated-features configure: error: Your Guile is too old. You need Guile at least 1.5.1 !!! ERROR: x11-libs/guile-gtk-1.2.0.31 failed. !!! Function econf, Line 339, Exitcode 1 !!! econf failed even though guile-1.6.4-r1 was installed. I found that I had to re-emerge guile to get past this. I ran into this problem both times I installed everything. It may be due to the broken ebuild for guile-gtk-0.19-r1 or the fact that running ebuild -C guile-gtk removes more than it should. 2) After installing ng-spice-rework, any following ebuilds generate the error: install-info: warning: no info dir entry in `//usr/share/info/ngspice.info.gz' 3) geda still installs gsch2pcb 0.9 instead of the more recent version available on it's home site. 4) geda still doesn't include vbs. The resulting executables look okay.
Oops. I mistyped myself. That shouldn't be "due to the broken ebuild for guile-gtk-0.19-r1 or the fact that running ebuild -C guile-gtk removes more than it should" since that is conjecture on my part. When you read this, please replace "due to the" with "due to a" and replace "or the fact" with "or that". I think that the latter is more likely since the install of guile-gtk-0.19-r1 would also fail with the error: ERROR: Unbound variable: include-deprecated-features
Fixed in ia64-sources-2.4.22-r2.ebuild...
Hmm. Wrong bug, ignore that.
I think I have fixed problems #3 and #4 above. A context diff follows: sabre geda # diff -C 1 geda-20030901.ebuild.old geda-20030901.ebuild *** geda-20030901.ebuild.old Mon Jan 5 06:12:59 2004 --- geda-20030901.ebuild Wed Jan 7 14:38:35 2004 *************** *** 40,41 **** --- 40,42 ---- >=app-sci/iverilog-0.7 + >=app-sci/vbs-1.4.0 >=app-sci/ng-spice-rework-14" *************** *** 57,59 **** # Fix a problem with the gsch2pcb in the gEDA release ! cp ${S}/gsch2pcb-1.2/*.c ${S}/geda-utils-${PV} cp ${S}/gsch2pcb-1.2/gnet-gsch2pcb.scm ${S}/geda-gnetlist-${PV}/scheme --- 58,60 ---- # Fix a problem with the gsch2pcb in the gEDA release ! cp ${S}/gsch2pcb-1.2/*.c ${S}/geda-utils-${PV}/src cp ${S}/gsch2pcb-1.2/gnet-gsch2pcb.scm ${S}/geda-gnetlist-${PV}/scheme sabre geda #
gEDA 20040111 is now in CVS and Portage. If something doesn't work; please reopen this bug! Thanks for all the testing!
I would like to re-open this bug, but bugzilla won't let me. I am having problems with digest files. sabre site-lisp # ACCEPT_KEYWORDS="~x86" emerge -v geda ... >>> Downloading http://www.geda.seul.org/devel/20040111/geda-gnetlist-20040111.tar.gz --18:33:24-- http://www.geda.seul.org/devel/20040111/geda-gnetlist-20040111.tar.gz => `/usr/portage/distfiles/geda-gnetlist-20040111.tar.gz' Resolving www.geda.seul.org... 18.244.0.188 Connecting to www.geda.seul.org[18.244.0.188]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 303,503 [application/x-gzip] 100%[=====================================================================================================================================================================>] 303,503 144.34K/s 18:33:26 (144.08 KB/s) - `/usr/portage/distfiles/geda-gnetlist-20040111.tar.gz' saved [303503/303503] >>> md5 src_uri ;-) geda-20040111.tar.gz >>> md5 src_uri ;-) geda-docs-20040111.tar.gz >>> md5 src_uri ;-) geda-examples-20040111.tar.gz >>> md5 src_uri ;-) geda-gnetlist-20040111.tar.gz >>> md5 src_uri ;-) geda-gschem-20040111.tar.gz >>> md5 src_uri ;-) geda-gsymcheck-20040111.tar.gz >>> md5 src_uri ;-) geda-setup-20040111.tar.gz >>> md5 src_uri ;-) geda-symbols-20040111.tar.gz >>> md5 src_uri ;-) geda-utils-20040111.tar.gz >>> md5 src_uri ;-) libgeda-20040111.tar.gz !!! File is corrupt or incomplete. (Digests do not match) >>> our recorded digest: f057ee687f3da618eaff9988959a0b9c >>> your file's digest: c92889f314669b454067c40852e896bd !!! File does not exist: /usr/portage/distfiles//Makefile I can't find any Manifest file anywhere in the portage tree that contains either of the listed MD5 digests.
John: The gEDA Makefiles all use the singlar name of "Makefile" for each release of gEDA [ so I think you've got a Makefile from the previous release ] - if you remove /usr/portage/distfiles/Makefile and try merging gEDA again it should not complain about the digest any mo
That did it. Is there some way to force the ebuild to always download the Makefile? I can see this potentially causing problems with other packages that follow a similar scheme.
I think I'll just mirror the Makefiles; which is what I should have done in the first place.
when I emerge geda, it compiles for a while then ends with: In file included from /usr/local/include/libgeda/libgeda.h:30, from ../noweb/a_pan.nw:53: /usr/local/include/libgeda/struct.h:539: parse error before "GtkMenuFactory" /usr/local/include/libgeda/struct.h:816: parse error before '}' token ../noweb/a_pan.nw: In function `a_pan_general': ../noweb/a_pan.nw:119: dereferencing pointer to incomplete type ... much more of the same. It appears that GtkMenuFactory is not defined. I believe my gtk+ is up-to-date, but the ebuild should have complained anyway if it wasn't. Any ideas?
Is this ever going to be unmasked? Or are there still some problems with it?
I think ~x86 flag would be more to do with the unstability of the package at this point. If you want it added to portage, why don't you post a report of what you've tested and how much, and any problems you've had, or lack thereof.
As per my comment #38, and a bunch of old emails back and forth between Tim and myself that you couldn't read (:-), I had no problems with the ebuild(s) at that time. I gave all the resulting apps a once over and couldn't find any problems. Any problems that may have been left at that time would be upstream problems. I did find comment #40 disturbing though, so I tried to re-emerge libgeda. The build worked okay. My GTK+ is currently 2.4.9-r1. In addition, gwave-20031224 depends on guile-gtk-1.2.0.31, which is still masked off with ~x86. I can't find any relevant bugs for either gwave or guile-gtk that could be set as dependancies. I guess I will have to create bugs for them and try to chain them here, since they are the only things left I can think of that blocks this ebuild. Out of curiosity, should bugs be marked as "RESOLVED FIXED" if you can't run an emerge without ACCEPT_KEYWORDS set to e.g. ~x86? I don't know what the various fix levels are supposed to mean. Is there a web page somewhere that describes them?
Well, fixed just means that the bug is deemed to fix what is was opened for - which was to provide gEDA ebuild in this case. Regarding stabling gEDA - I don't see any problems. I'll speak to the GNOME team regarding guile-gtk-1.2.0.31, and if they have no objections, I'll mark it all stable.
Ah, I see. I shall be sure to open all my bug reports with a request that the ebuild be stable. Regarding guile-gtk: bug #22755 implies that there may still be an issue with guile slots, and bug #34918 implies that there isn't anybody to look at the problem anyway. You have a lot on your plate. Are you sure you want to become the guile guy?
