Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 177106
Summary: | Review Request: libgdgeda - graphical library for gEDA | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Wojciech Kazubski <wk> |
Component: | Package Review | Assignee: | John Mahowald <jpmahowald> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | hdegoede, j, paul |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-06-16 17:26:28 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: | |||
Bug Blocks: | 177107 |
Description
Wojciech Kazubski
2006-01-06 12:51:25 UTC
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. |