Can't sponsor, but I am interested in circuit software.


** Configuration summary for libgdgeda 2.0.15:

   Support for PNG library:          yes
   Support for JPEG library:         no
   Support for Freetype 2.x library: no
   Support for Xpm library:          no

Why not add these? It's usually a good idea to enable as many features as
possible. All it would take is adding libjpeg-devel and freetype-devel to
BuildRequires.


# install will be a bit complicated because we are not assured
# that the builder has root privileges

What do you mean by this? All packages are built by a non root user, and I did
sucessfully. You have defined a BuildRoot you don't need root to write to.

The source in the tarball isn't matching what I downloaded for some reason.
d4978ce4e8eb9fa2e7c0d7dba40b3c5b  libgdgeda-2.0.15.tar.gz (downloaded)
1580beb2bd224f38ce8637c67a5512f8  /tmp/libgdgeda-2.0.15.tar.gz (src rpm)


rpmlint checks are clean, which is good.

This test about JPEG and Freetype support is something left from original libgd
library or something unfinished yet. Some part of configure.ac is commented out,
so support for JPEG and Freetype will be disabled even if proper -devel files
are present. Adding the option --with-jpeg to configure does not help too. 
More, JPEG is not optimal for line graphs produced by gschem and currently the
only bitmap format supported by gschem is png.

The two comment lines are very old, maybe building rpms as user was not usual
for someone before me.

I'll check md5sums of the sources, my version of libgeda source is from 2003 and
is one byte shorter. It could be repackaged without bumping the version.

Some proposals on your spec files:
1. The *-devel package provides *.pc files. 
Therefore I'd propose to let it Requires: pkgconfig

2. Why not simply use %{_includedir}/gdgeda, instead of:
%files devel
%dir %{_includedir}/gdgeda
[..]
%{_includedir}/gdgeda/*

3. I'd strongly recommend not to ship the static libs.

1. OK, libgdgeda-devel put files into pkgconfig directory so the dependency is 
necessary. 
 
2. I was not sure that if package owns a directory then it owns everything 
inside. There is some risk of strange files getting into a package, if the 
files are named in %files you have more control what is packaged. 
 
3 OK, I will make a test with --disable-static. 

Few days ago I upgraded specfiles for all gEDA stuff including libgdgeda. 
Specfiles are at:  
http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/specs2/  
Source RPM is at:    
http://www.sp5pbe.waw.pl/~sp5smk/fedora-extras/srpms/   

These apply to the other gEDA specs as well.

* The gd license is really BSD, change it
* If you are going to tag the package for a distro use the %{?dist} tag as
described in DistTag on the wiki
The current hardcoded value results in fc4 in the Release tag on this rawhide box.

License and distro tag changed. It seems that the %{?dist} tag does not work on 
my machine, got no .fc4 suffix. 

(In reply to comment #7)
> License and distro tag changed. It seems that the %{?dist} tag does not work on 
> my machine, got no .fc4 suffix. 

Build your package in mock, and then it will pull in the buildsys-macros and
define the macro.

Alternatively, just install the buildsys-macros package from
http://fedoraproject.org/buildgroups/4/i386/

Better still, don't worry about the missing disttag - %{?dist} will work as
designed in the Extras buildsystem.

Do not hardcode the distribution in the spec file though.

This was done to work in my private repository. Yestersay I had to bump fedora 
release number manually. And there is good news: build goes trough on FC5/386. 
 
Please look into other specfiles of gEDA 

John (Mahowald)

I'm a teacher in electronics and as such I'm interested in circuit software too.
Also I've got a student who is currently using a self-compiled version of geda
on top of FC-5. He has tested Wojciech Kazubski's SRPMS and they work (as good
as the original, which has a few bugs).

I can't sponsor either, but I have "acquired" the support of a sponser: Paul
Howarth (added to CC-list). My agreement with Paul is that I'll do the full
review and that he will look over my shoulder and do the sponsoring when he is
happy with my review and Wojciech Kazubski's work. As such I would like todo a
full review soon, starthing with this package and then chewing my way through
the other geda packages.

Questions: Can you do a full review soon, are shall I take over and do it? Maybe
we can share the review load there are a lot of packages that together make up geda?

About comment 6: I tend to agree however interesting in this light is are bug
185215 and bug 185501, where to reverse is being advocated (use "zlib License"
instead of BSD) I think we need some kinda policy on this.

I have since become a sponsor. 

Yes I am interested in delegating the review of the several packages here,
however this one needs to go through before nearly all of the others.

Please explain the differences this library has from standard gd and why . From
the version numbers it appears to be based on the gd version from FC1.
Duplication, and an older version at that, should be avoided IMO.

In the mean time I have become a sponsor too, so sponsors a plenty :)

Wojciech,

Can you please answer John's question: "Please explain the differences this
library has from standard gd and why . From the version numbers it appears to be
based on the gd version from FC1" ask upstream for clarification if nescesarry,
I believe that John is asking a very valid question.

If you don't have an answer atleast answer that you don't have an answer,
silence is one way to make sure we are not going to get anywhere.

The differences are surprisingly small. The only significant difference is the 
direction of drawing arcs. This can be compensated by changing one line in 
libgeda. Now I am testing the libgeda with gd 2.0.33 and it seems that it is 
working fine. So in my opinion libgdgeda can be dropped completly. The only 
problem now is that nor gd or libgd.so.2 is in REQUIRES.

Wojciech Kazubski

(In reply to comment #13)
> The differences are surprisingly small. The only significant difference is the 
> direction of drawing arcs. This can be compensated by changing one line in 
> libgeda. Now I am testing the libgeda with gd 2.0.33 and it seems that it is 
> working fine. So in my opinion libgdgeda can be dropped completly. The only 
> problem now is that nor gd or libgd.so.2 is in REQUIRES.

You're saying you've replaced libgdgeda-devel with gd-devel as the buildreq for
libgeda and the resulting package doesn't have an auto-dep on libgd.so.2?

Yes. I investigated this a bit and found that gd package does not have 
pkgconfig file (libgdgeda has it), so I disabled a test for library version 
(PKG_CHECK_MODULES, line 177 of configure.ac). Unfortunately this test provides 
some compile and link flags, including -lgdgeda.
  
Both gd and libgdgeda have their own config scripts (gdlib-config and 
libgdgeda-config) that should also give the flags but gdlib.config --libs do 
not return anything like -lgd. I will try to add it manually and see the 
result.

> gdlib-config --libs does not return anything like -lgd.

Strange, adding -lgd manualy should make rpm pick up the libgd dependency for
libgeda. Let me know if you need any help with this.

Adding "-lgl " to GDGEDA_LIBS makes libgeda to require libgd.so.2. Now I am 
going to try a complete build without libgdgeda. 

Cool, keep up the good work!

Erm, ping?

Second ping, are you still interested in this? If not please let me know I think
I know someoneelse who is willing to package the entire geda suite for FE.

Shouldn't you respond within one week from now, I'll presume you have
lost interest into getting this package into FE and close this PR.

It's not looking good.

Agreed closing as won't fix.

A student at my daytime job (I'm an electronics  teacher at a university) uses
geda for some projects. I'm stimulating him to become an FE contributer and for
starters to pick geda. So I hope we will get geda into FE in a reasonable
timeframe through him.