Bugzilla Bug 21849

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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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?