Bug 428567 - Review Request: ETL - Extended Template Library
Review Request: ETL - Extended Template Library
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nicolas Chauvet (kwizart)
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 428568
  Show dependency treegraph
 
Reported: 2008-01-13 09:14 EST by Marc Wiriadisastra
Modified: 2009-10-29 09:25 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-01 07:32:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kwizart: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
workaround for the pkgconfig on lib64 system (1.75 KB, patch)
2008-01-15 09:41 EST, Nicolas Chauvet (kwizart)
no flags Details | Diff
Rewrite ETL-config as wrapper to pkgconfig (1.01 KB, text/x-patch)
2008-01-23 23:52 EST, Ralf Corsepius
no flags Details
profile cleanup (4.31 KB, patch)
2008-03-07 06:57 EST, Marc Wiriadisastra
no flags Details | Diff

  None (edit)
Description Marc Wiriadisastra 2008-01-13 09:14:42 EST
Spec URL: http://mwiriadi.fedorapeople.org/packages/ETL/ETL.spec
SRPM URL: http://mwiriadi.fedorapeople.org/packages/ETL/ETL-devel-0.04.10-1.fc8.src.rpm
Description: ETL is a multi-platform class and template library designed to add
new datatypes and functions which combine well with the existing
types and functions from the C++ Standard Template Library (STL).
Comment 1 Nicolas Chauvet (kwizart) 2008-01-15 06:32:33 EST
starting review
Comment 2 Nicolas Chauvet (kwizart) 2008-01-15 07:32:06 EST
* You need to download the sources with wget -N in order to prevent timestamps
changes
-rw-rw-r-- 1 builder builder 335182 jan 11 16:37 ETL-0.04.10.tar.gz
instead of 
-rw-rw-r-- 1 builder builder 335182 oct 10 04:37 ETL-0.04.10.tar.gz

* if the package name is ETL-devel, the spec file have to be ETL-devel.spec

* License is GPLv2+ - good

* The package do not seems to be arch independent but only because it has ETL.pc
in /usr/lib64 on lib64 system - seems strange

* you need to use: make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
-rw-r--r-- 1 builder builder   1249 jan 15 12:39 value
instead of
-rw-r--r-- 1 builder builder   1249 mar 16  2007 value

* etl_profile.h is a config.h kind of file. usually it shouldn't be installed.
same as etl_config.h - If upstream claims they are really needed, then it might
be interesting to keep a timestamps reference from a file to avoid multiarches
conflict (but only if they are the same on i386 and x86_64, and also ppc and
ppc64 at least). Might be safe to remove ETL-config then. (and to patch
dependant apps to use pkg-config if needed).
see http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

* The package bundle no library - as such it is not needed to have
/sbin/ldconfig in post and postun.

* pkg-config file: ETL.pc - it Requires only
But includedir remains includedir=/usr/include instead of
includedir=/usr/include/ETL as such they is a need to check if headers of
dependent packages have ETL/spline or only spline (for example). Might need to
test package that links against it... specially if others libs are missing.

* As the package isn't marked as noarch (might evaluate if it could be with a
tweak for pkg-config) a debuginfo is generated. If the package remains arch
dependant, we might consider to use %define debug_package %{nil}. If the package
could be noarch, then it might need to work on x86 x86_64 ppc ppc64 (and maybe
others arch). then no debuginfo package will be created.



Comment 3 Nicolas Chauvet (kwizart) 2008-01-15 07:39:07 EST
should be read:
* pkg-config file: ETL.pc - it Requires only -lpthread

koji scratch build request at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=350044

Looking at the headers looks differents or same for each arches...
Comment 4 Ralf Corsepius 2008-01-15 08:54:21 EST
Blocker: /usr/bin/ETL-config is not multilib ready.

I recommend to re-write it as a wrapper around pkg-config.

Comment 5 Nicolas Chauvet (kwizart) 2008-01-15 09:41:04 EST
Thx for your advice Ralf:

Actually the only difference between ppc and x86_64 (for example and expect for
the pkgconfig path for libdir is:
----------------
diff -uNr usr/include/ETL/etl_profile.h usr-x86_64/include/ETL/etl_profile.h
--- usr/include/ETL/etl_profile.h	2008-01-15 13:49:01.000000000 +0100
+++ usr-x86_64/include/ETL/etl_profile.h	2008-01-15 13:49:01.000000000 +0100
@@ -129,7 +129,7 @@
 
 /* Define to 1 if your processor stores words with the most significant byte
    first (like Motorola and SPARC, unlike Intel and VAX). */
-#define WORDS_BIGENDIAN 1
+/* #undef WORDS_BIGENDIAN */
 
 /* define if the vsnprintf function is mangled */
 /* #undef vsnprintf */
----------
But this define isn't used elsewhere than in etl_profile.h. If we can consider
this as a noach package, then we might need to rip out these lines...

Instead of using ETL-config, i was think about having this: (see attachement)
Comment 6 Nicolas Chauvet (kwizart) 2008-01-15 09:41:59 EST
Created attachment 291713 [details]
workaround for the pkgconfig on lib64 system
Comment 7 Marc Wiriadisastra 2008-01-15 09:58:41 EST
I have sent an email upstream to get some further information. I think it is
prudent to talk to upstream to see where they view the current situation and
what the best method is to go about sorting it out.

If nothing comes of it I'll start working on patching what I can and trying to
fix things.  Thanks Nic for the updated Spec file that will come in handy.

What I might do to get further information is to actually scan the source files
of synfig to see what else is needed from in here as per one of your points then
go from there.
Comment 8 Ralf Corsepius 2008-01-15 10:44:18 EST
(In reply to comment #5)
> Thx for your advice Ralf:
The killer is this:

-- i386/bin/ETL-config 2008-01-15 13:39:03.000000000 +0100
+++ x86_64/bin/ETL-config       2008-01-15 13:38:56.000000000 +0100
@@ -9,7 +9,7 @@
 sysconfdir=/etc
 sharedstatedir=/usr/com
 localstatedir=/var
-libdir=/usr/lib
+libdir=/usr/lib64
 infodir=/usr/share/info
 mandir=/usr/share/man
 includedir=/usr/include

This is a blocker, because it prevent you from installing 386 and the x86_64
packages in parallel.

> Actually the only difference between ppc and x86_64 (for example and expect
for the pkgconfig path for libdir is:


> ----------------
> diff -uNr usr/include/ETL/etl_profile.h usr-x86_64/include/ETL/etl_profile.h
> --- usr/include/ETL/etl_profile.h	2008-01-15 13:49:01.000000000 +0100
> +++ usr-x86_64/include/ETL/etl_profile.h	2008-01-15 13:49:01.000000000 +0100
> @@ -129,7 +129,7 @@
>  
>  /* Define to 1 if your processor stores words with the most significant byte
>     first (like Motorola and SPARC, unlike Intel and VAX). */
> -#define WORDS_BIGENDIAN 1
> +/* #undef WORDS_BIGENDIAN */

Bummer. This is yet another blocker. They are exporting a define which clashes
with autoconf's autoheaders. This will render this package unusable with any
autoconf based package using AC_BIG_ENDIAN (cf. info autoconf) and gcc43.
 
Worse. Your remark had caused me to have a closer look into the headers.
They are scattered with autoheader defines which all will trigger the same issue
as outlined above.

IMO, this package is not in a shape to be added. I recommend to withdraw it.


Comment 9 Nicolas Chauvet (kwizart) 2008-01-15 20:07:39 EST
Well Ralf raise a real problem... And i would give a chance to have an answear
from upstream...But indeed, I won't approve anything that isn't gcc43 compliant.

There is also the question to add some headers without any libs...
I wonder if this make sense, specially if only one package use it. Does theses
headers could be merged with another package ? 

Comment 10 Ralf Corsepius 2008-01-22 00:05:46 EST
(In reply to comment #9)
> And i would give a chance to have an answear
> from upstream...
Yes, this is an issue that should be fixed upstream.

> There is also the question to add some headers without any libs...
> I wonder if this make sense, specially if only one package use it. Does theses
> headers could be merged with another package ? 
I don't understand this remark. Could you elaborate?
Comment 11 Paul Wise (Debian) 2008-01-22 04:28:22 EST
Hi, I'm one of the people helping with development upstream.

We inherited the synfig source code - it was GPLed after being proprietary:

http://synfig.org/History

We'd appreciate it if you could come to #synfig on irc.freenode.net, explain the
issues that need fixing and help us to fix them. Look for either dooglus or
pabs3. Alternatively please file bugs/patches in the tracker linked here:

http://synfig.org/Bugs

Once ETL/synfig/synfigstudio are in Fedora, please edit these pages:

http://synfig.org/Download
http://synfig.org/Bugs
Comment 12 Paul Wise (Debian) 2008-01-22 04:32:01 EST
Forgot to ask you to edit this to indicate the Fedora package names of the
build-dependencies:

http://synfig.org/Build_instructions
Comment 13 Marc Wiriadisastra 2008-01-22 04:36:11 EST
I don't know if you got my email before. There are few issues with etl as you
can see from this thread.

The bugs listed are in the thread itself if you would like to comment.  At the
moment the package is on hold and will not make it into Fedora without the fixes
to the code listed above.
Comment 14 Paul Wise (Debian) 2008-01-23 19:17:19 EST
I was able to build synfig with Debian's g++ 4.3 fine, but not synfigstudio due
to this bug in sigc++:

http://bugs.debian.org/456971

When that is resolved, I'll try it again. If Fedora has a fix for it, please try
building synfigstudio with it.
Comment 15 Marc Wiriadisastra 2008-01-23 19:53:41 EST
Have you checked your defines to make sure they don't clash with other packages.
The example given was in your etl_profile_.h.in

ETL-config This is a blocker, because it prevent you from installing 386 and the
x86_64 packages in parallel.

quoting from ralf btw:
Your remark had caused me to have a closer look into the headers.
They are scattered with autoheader defines which all will trigger the same issue
as outlined above. In reference to the clash's if you change your defines they
should be fine. The etl-config issue as well.

One other question why does it need a static library since we remove it after
building?
Comment 16 Paul Wise (Debian) 2008-01-23 20:26:32 EST
Defines: not yet, help welcome.

ETL-config is generated from ETL-config.in at configure time. Removing it
upstream would be OK, since synfig/studio don't use it as far as I can see.

Not sure which static library you mean, ETL is just a bunch of C++ templates.
Comment 17 Ralf Corsepius 2008-01-23 23:49:31 EST
(In reply to comment #16)
> Defines: not yet, help welcome.
Provided how this package is designed, fixing this is close to impossible.

One way to work around this would be to rename all defines and to use a second,
private, manually written autoheader, which would be installed into $(libdir)
instead of $(includedir). Packages using ETL then would be required to use
-I$(libdir)/ETL to pickup this header (c.f. how glib2 and gtk2 install their
headers)

> ETL-config is generated from ETL-config.in at configure time.
This is pretty easy to fix. The key is not to store any configuration info in
files which are not in multilib'ed dirs. I.e. not to store @libdir@ in
$(bindir)/ETL-config, but to let $(bindir)/ETL-config pick up this info from a
different location.

A common trick is to implement $(bindir)/*-config as wrappers around pkgconfig.
(*.pc's are being stored into $(libdir)/pkgconfig (libdir is multilib'ed. e.g.
*/lib on ix32 and */lib64 on ix64)

> Removing it
> upstream would be OK, since synfig/studio don't use it as far as I can see.
Exactly this is the cause of your problems with the #defines. 
If they were, you could move these headers into $(libdir) and let ETL.pc use
Cflags= -I$(libdir)/ETL or similar.
Comment 18 Ralf Corsepius 2008-01-23 23:52:26 EST
Created attachment 292726 [details]
Rewrite ETL-config as wrapper to pkgconfig

This patch implements $(bindir)/ETL-config as a wrapper around pkg-config.

c.f. my previous comment. It avoids hardcoding config values into files inside
of non-multilib'ed dirs.
Comment 19 Paul Wise (Debian) 2008-01-24 00:31:54 EST
Patch committed to synfig svn.
Comment 21 Nicolas Chauvet (kwizart) 2008-02-02 06:21:16 EST
From the package point of view:
This seems fine. I would just remove ETL-config as this will lead to mutliarch
conflict (as Ralf state). As synfig do not use it, this shouldn't matter)

From the code point of view:
When trying to build synfig I've had:
/usr/include/ETL/_surface.h:196: error: 'memcpy' was not declared in this scope
So you need to add the missing include (cstring in this case).

One note about synfig, there are a lot of missing BR (see the Configuration
Summary) - That would be fine to add them when they are available within Fedora. 
There is also a libavcodec optionnal requirement, and maybe it would be good to
provide it as a plugin form third part repository...

Comment 22 Paul Wise (Debian) 2008-02-02 06:41:39 EST
ETL-config has been rewritten as a pkg-config wrapper (see patch above).

_surface.h error has a one-line fix (#include <cstring>) and was fixed in SVN
ages ago thanks to Debian.
Comment 23 Nicolas Chauvet (kwizart) 2008-02-02 06:51:25 EST
OK! so about gcc4.3.0 the packager also need to backport the patch.
(as we now have pre gcc 4.3.0 in rawhide).

About the ETL-config, since this file is generated at a configure step, packager
will need to set the same timestamps from a reference file for all arches .
This can be done using touch -r any_reference_file
$RPM_BUILD_ROOT%{_bindir}/ETL-config
Comment 24 Marc Wiriadisastra 2008-02-02 06:52:37 EST
Upstream is planning on releasing a new version at the end of this month early
next month to be compliant with gcc43. As F-9 will contain gcc43 I will wait
till the new release and repackage for that.

The wrapper is included in upstream already so I will be closer to upstream.
Comment 25 Nicolas Chauvet (kwizart) 2008-02-02 11:49:01 EST
As you like, but this patch is often trivial, and that would be a good thing to
have backported and tested so we could start review synfig.
Comment 26 Marc Wiriadisastra 2008-02-02 17:59:33 EST
Actually you make a fair point since there are still 2 other packages linked to
this one.

http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel-0.04.10-3.fc8.src.rpm
http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel.spec

Updated with the patch.
Comment 27 Nicolas Chauvet (kwizart) 2008-03-05 18:29:26 EST
oups! I was close to ping you but actually you should have ping me !
so i'm testing 0.04.10-3 but 0.01.11 is here...





Comment 28 Nicolas Chauvet (kwizart) 2008-03-05 19:21:08 EST
synfig failed with on Rawhide with gcc43
blur.cpp:134: error: explicit template specialization cannot have a storage class

As synfig is a known package using ETL-devel I cannot approve ETL-devel until
synfig is fixed.

starting prelimary review of synfig

Comment 29 Marc Wiriadisastra 2008-03-06 04:24:45 EST
That is correct. It is fixed in cvs currently in upstream. They are planning a
release shortly. Hence I haven't done anything yet. I was hoping this would work
so it would be a simple upgrade/update.

Comment 30 Marc Wiriadisastra 2008-03-06 04:55:21 EST
My bad, upstream has released a new version. I've re-packaged it.

http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel-0.4.11-1.fc9.src.rpm
http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel.spec
Comment 31 Ralf Corsepius 2008-03-07 00:16:42 EST
Two show stoppers:

1. The header files are still as dirty as they used to be.
This package's headers are polluted with HAVE_* defines.


2. Why is this package called ETL-devel?
The package's name is ETL => ETL.spec, ETL-<version>-<release>.src.rpm
There is nothing wrong in letting this ETL.src.rpm only build an ETL-devel.rpm.


Comment 32 Marc Wiriadisastra 2008-03-07 05:00:04 EST
I originally had the spec file as ETL.spec but changed it to ETL-devel as part
of the review.

Ralf if I removed the HAVE_* would that work since the requirements for the
packages are there anyway the HAVE seem to be doing the packagers job. The
configure finds it anyways.
Comment 33 Marc Wiriadisastra 2008-03-07 06:06:46 EST
Ralf it seems like the only file is etl_profile.h

[marc@localhost ETL-0.4.11]$ grep -r '#define HAVE_ *' ./*
./configure:#define HAVE_LIBUSER32 1
./configure:#define HAVE_LIBKERNEL32 1
./configure:#define HAVE_LIBPTHREAD 1
./configure:#define HAVE_VSNPRINTF 1
./ETL/etl_profile.h:#define HAVE_FORK 1
./ETL/etl_profile.h:#define HAVE_GETTIMEOFDAY 1
./ETL/etl_profile.h:#define HAVE_INTTYPES_H 1
./ETL/etl_profile.h:#define HAVE_KILL 1
./ETL/etl_profile.h:#define HAVE_LIBPTHREAD 1
./ETL/etl_profile.h:#define HAVE_MEMORY_H 1
./ETL/etl_profile.h:#define HAVE_PIPE 1
./ETL/etl_profile.h:#define HAVE_PTHREAD_CREATE 1
./ETL/etl_profile.h:#define HAVE_PTHREAD_H 1
./ETL/etl_profile.h:#define HAVE_PTHREAD_RWLOCK_INIT 1
./ETL/etl_profile.h:#define HAVE_PTHREAD_YIELD 1
./ETL/etl_profile.h:#define HAVE_SCHED_H 1
./ETL/etl_profile.h:#define HAVE_SCHED_YIELD 1
./ETL/etl_profile.h:#define HAVE_SSCANF 1
./ETL/etl_profile.h:#define HAVE_STDINT_H 1
./ETL/etl_profile.h:#define HAVE_STDLIB_H 1
./ETL/etl_profile.h:#define HAVE_STRINGS_H 1
./ETL/etl_profile.h:#define HAVE_STRING_H 1
./ETL/etl_profile.h:#define HAVE_SYS_STAT_H 1
./ETL/etl_profile.h:#define HAVE_SYS_TIMES_H 1
./ETL/etl_profile.h:#define HAVE_SYS_TIME_H 1
./ETL/etl_profile.h:#define HAVE_SYS_TYPES_H 1
./ETL/etl_profile.h:#define HAVE_UNISTD_H 1
./ETL/etl_profile.h:#define HAVE_VASPRINTF 1
./ETL/etl_profile.h:#define HAVE_VSNPRINTF 1
./ETL/etl_profile.h:#define HAVE_VSPRINTF 1
./ETL/etl_profile.h:#define HAVE_VSSCANF 1
./ETL/etl_profile.h:#define HAVE___CLONE 1
./ETL.pbproj/etl_profile.h:#define HAVE_GETTIMEOFDAY
./ETL.pbproj/etl_profile.h:#define HAVE_PTHREAD_H
./ETL.pbproj/etl_profile.h:#define HAVE_SCHED_H
./ETL.pbproj/etl_profile.h:#define HAVE_PTHREAD_CREATE
./ETL.pbproj/etl_profile.h:#define HAVE_VASPRINTF
./ETL.pbproj/etl_profile.h:#define HAVE_VSNPRINTF
./ETL.pbproj/etl_profile.h:#define HAVE_VSPRINTF
Comment 34 Marc Wiriadisastra 2008-03-07 06:57:22 EST
Created attachment 297176 [details]
profile cleanup

Ralf would this work provided the other etl_profile.h are removed.
Comment 35 Marc Wiriadisastra 2008-03-07 07:03:46 EST
bleh ignore this it needs more testing doesn't compile with synfig
Comment 36 Marc Wiriadisastra 2008-03-07 07:32:08 EST
I think it works...........Ralf can you verify that this no longer has a blocker.

http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL.spec

http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-0.4.11-2.fc9.src.rpm
Comment 37 Marc Wiriadisastra 2008-03-10 06:47:37 EDT
Ping
Comment 38 Nicolas Chauvet (kwizart) 2008-03-12 10:43:30 EDT
/var/tmp/rpm-tmp.41093: line 40: autoreconf: command not found
Missing BR: automake

But the etl_profile.h is still here! In my mind it should be removed and the
tests for definitions should be done by synfig. This would remove the need of
using autotools for ETL and thus, produce a clean noarch package for ETL
(without pkgconfig nor ETL-config needs as it just need to find where are the
headers, use -lpthread and the proper HAVE_ definitions for ETL).

On the other side: this is a special case here as no lib is built. So, removing
any config.h-like file is like removing it after the configure step and before
building the software on the usual case. 
In this case, this is senseless and in my mind we may keep this etl_profile.h ...

Others point of view can be expressed...
for now, T'm test building synfig for F-9 with this package...
Comment 39 Marc Wiriadisastra 2008-03-12 17:29:17 EDT
For me provided I can build synfig and synfig-studio is all I'm concerned about.
Synfig-studio is not up for review as of yet because I want etl and synfig ready
before I bring that for review.
Comment 40 Nicolas Chauvet (kwizart) 2008-03-12 17:52:16 EDT
I forgot to say that it has failed to build on F-9 x86_64
undefined reference to g_uri_get_scheme
collect2: 
ld returned 1 exit status

I don't knwo where this symbol is present, i don't seems to have it available on
my system.
Comment 41 Paul Wise (Debian) 2008-03-12 20:32:19 EDT
ETL/synfig/synfigstudio don't use that function. From google it looks like it
was part of glib at one point but was renamed.
Comment 42 Marc Wiriadisastra 2008-03-13 08:21:10 EDT
Is this really an issue the following code.

/* Define to the address where bug reports for this package should be sent. */
#define ETL_BUGREPORT "http://synfig.org/Bugs"

/* Define to the full name of this package. */
#define ETL_NAME "Extended Template Library"

/* Define to the full name and version of this package. */
#define ETL_STRING "Extended Template Library 0.4.11"

/* Define to the one symbol short name of this package. */
#define ETL_TARNAME "ETL"

/* Define to the version of this package. */
#define ETL_VERSION "0.4.11"
Comment 43 Nicolas Chauvet (kwizart) 2008-03-18 09:32:54 EDT
(In reply to comment #41)
> ETL/synfig/synfigstudio don't use that function. From google it looks like it
> was part of glib at one point but was renamed.

Maybe there is a missing -lstdc++ somewhere ?
Comment 44 Marc Wiriadisastra 2008-04-13 19:11:43 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=564701

I don't see any issue? Sorry my computer died and I'm now using my laptop
instead of my other box.

Well PSU died and I haven't fixed it as of yet.
Comment 45 Nicolas Chauvet (kwizart) 2008-04-16 16:24:02 EDT
The problem isn't with ETL but with synfig using ETL.
I cannot approve ETL if the dependent package that is supposed to be useful fails. 
(at least on Rawhide x86_64)
I will give a retry...
Comment 46 Paul Wise (Debian) 2008-04-16 20:47:26 EDT
Can you paste the build errors or a link to them?
Comment 47 Nicolas Chauvet (kwizart) 2008-05-01 05:32:44 EDT
Ok this time the build went fine on x86_64.
(either synfig or others dependencies have been fixed probably)

So we are close.
About ETL, it still miss BuildRequires libtool
and /usr/bin/ETL-config /usr/include/ETL/etl_profile.h need to have a timestamps
reference like:
touch -r ChangeLog $RPM_BUILD_ROOT%{_bindir}/ETL-config
touch -r ChangeLog $RPM_BUILD_ROOT%{_includedir}/ETL/etl_profile.h

As they are already the same files but have different timestamps

Comment 49 Nicolas Chauvet (kwizart) 2008-05-05 10:23:54 EDT
>Buildrequires:  automake, libtool
>Requires:       pkgconfig, automake

Buildrequires: libtool will be enought as it will bring autoconf automake
But Adding Requires automake isn't needed by ETL itself.

Fix that and i will approve the package. (it finally built with synfig and F-9
x86_64) might be a bug with a dependency or fixed in newer version...

Comment 50 Marc Wiriadisastra 2008-05-05 18:29:34 EDT
http://mwiriadi.fedorapeople.org/packages/ETL/ETL.spec
http://mwiriadi.fedorapeople.org/packages/ETL/ETL-0.4.11-4.fc9.src.rpm

Removed automake and automake

Buildrequires: libtool
Requires: pkgconfig

Cheers Nicolas for your help.
Comment 51 Nicolas Chauvet (kwizart) 2008-05-05 19:36:39 EDT
Ok - Why do you have no space between this:
Requires:       pkgconfig
%description

That's important to have a spec file readable, as everyone can take a look on it
and watch commit logs. (same for one line BuildRequires).
Anyway...

----------------

This package (ETL) is approved by me

----------------
Comment 52 Ralf Corsepius 2008-05-06 01:43:40 EDT
(In reply to comment #51)
> This package (ETL) is approved by me
Urgh, why did you do this?

IMNSHO, this package is of a too poor quality to let in into Fedora.

In particular, none of its silly HAVE_ define issues have been fixed.
Comment 53 Nicolas Chauvet (kwizart) 2008-05-06 06:05:22 EDT
> IMNSHO, this package is of a too poor quality to let in into Fedora.
Do you see other problem than the etl_profile.h to say it's poor ?
> In particular, none of its silly HAVE_ define issues have been fixed.
> 
Well as ETL and synfig build fine i would only see this a an improvement.
Many packages still use a config.h like package (for example mozilla-config.h
from mozilla/firefox/xulrunner).
But as you disagree I won't object.

NEED_WORK: remove all config.h like files from the package. Thoses need to be
checked by the dependant application at configure time.

Comment 54 Ralf Corsepius 2008-05-06 10:07:08 EDT
(In reply to comment #53)
> > IMNSHO, this package is of a too poor quality to let in into Fedora.
> Do you see other problem than the etl_profile.h to say it's poor ?
This bug alone a BLOCKER and a MUSTFIX.

The problem behind this and the fact nobody has been able to come up with a
quick-fix are caused by this package suffering from fundamental design flaws.

> > In particular, none of its silly HAVE_ define issues have been fixed.

> Well as ETL and synfig build fine i would only see this a an improvement.
The point is: You are trying to ship ETL as standalone devel-package.
The HAVE_ defines disqualifies it from such usages.

> Many packages still use a config.h like package (for example mozilla-config.h
> from mozilla/firefox/xulrunner).
I haven't checked this particular case, but it's likely the a similar
mis-design. There have been several of similar cases around, with some of them
having been ironed out over time, and some of them not having been fixed.


Comment 55 Nicolas Chauvet (kwizart) 2008-05-14 07:49:12 EDT
@Marc
Did you understood what you need to do ?
upstream agreed to add the patch but i have no time for providing it.
Would be better if you can work on it as you want to be the maintainer of this
package.
Comment 56 Marc Wiriadisastra 2008-05-14 20:26:44 EDT
Yeah I have been  busy with $RL work so I'll start on it tonight hopefully.
Comment 57 Nicolas Chauvet (kwizart) 2008-06-12 20:37:29 EDT
ping ?
Comment 58 Nicolas Chauvet (kwizart) 2008-07-02 20:18:53 EDT
Again, ping ? don't forget to ask if you get lost with what to do...
Comment 59 Jason Tibbitts 2008-07-02 21:59:23 EDT
Nicholas, you might want to check bug 429809.
Comment 60 Lorenzo Villani 2008-08-25 10:58:27 EDT
Any progress with this package? I can take it, if necessary.
Comment 61 Paul Wise (Debian) 2008-10-23 01:20:21 EDT
New version released, please update. If there are any patches you need, please send them our way.
Comment 62 Lubomir Rintel 2009-01-10 12:24:39 EST
New upstream release (stepping in since the original submitter seems unresponsive):

SRPMS: http://v3.sk/~lkundrak/SRPMS/ETL-0.04.12-4.el5.src.rpm
SPEC: http://v3.sk/~lkundrak/SPECS/ETL.spec

* HAVE_* macros have been renamed to avoid clash with autoconf. "config.h-like" file etl_profile.h was not removed, since upstream does not do that, and I tend to think that it's the good way to go.

See -- this would add a requirement for programs that use this to define ~10 macros prior to include the header, which can be non-trivial and ugly for programs that don't rely on autoconf && friends. And in case a new one gets added it could unnecessarily break compatibility, possibly resulting into builds with feature set smaller than intended. I don't think doing that with this added maintenance cost is a good idea. There is a prior art as well -- many packages hardcode feature set at build time.

Rpmlint is silent, this builds in f11 mock and synfig with synfig studio build cleanly against this as well.
Comment 63 Lubomir Rintel 2009-01-10 12:26:42 EST
Sorry; I forgot to reset the revision, here are new packages:

SRPMS: http://v3.sk/~lkundrak/SRPMS/ETL-0.04.12-1.el5.src.rpm
SPEC: http://v3.sk/~lkundrak/SPECS/ETL.spec
Comment 64 Lorenzo Villani 2009-01-13 10:27:13 EST
ETL is an header-only package, why split in ETL and ETL-devel? I've been told that you can proceed either way but I think that having only ETL is better.

By the way: are you a sponsored packager (I couldn't find you in the packager group). If not, you'll have to wait a sponsor to step in and review the package.
Comment 65 Lubomir Rintel 2009-01-13 14:31:19 EST
(In reply to comment #64)
> ETL is an header-only package, why split in ETL and ETL-devel? I've been told
> that you can proceed either way but I think that having only ETL is better.

I don't split the package. The only binary (well, non-src) package that gets built from this package is ETL-devel, there's no main package, since because there's no %files section other than one for -devel subpackage.

Package guidelines suggest that packages with content like this should be in -devel subpackage.
https://fedoraproject.org/wiki/Packaging/Guidelines#Devel_Packages

It could be argued that this package is exceptional, since it is only useful for development, but I find it much more consistent to call it -devel. It is only useful for development, not run-time and the -devel name makes is easily distinguishable as such not only to the user, but also to the tools (such as rpmdev-rmdevelrpms).

This is also more future-proof (for the unlikely cause it gains some library code). It might be a good idea to provide ETL now though.

> By the way: are you a sponsored packager (I couldn't find you in the packager
> group). If not, you'll have to wait a sponsor to step in and review the
> package.

Yup, I am sponsored.
I believe you can view my groups there, and packager is among those:
https://admin.fedoraproject.org/accounts/user/view/lkundrak
Comment 66 Nicolas Chauvet (kwizart) 2009-01-20 06:23:51 EST
Look at 
https://bugzilla.redhat.com/show_bug.cgi?id=428567#c17
The current package miss the etl_profile.h move into %{_libdir}/ETL and the related adds in ETL.pc (Cflags: -I${includedir} -I${libdir}/ETL)
If ever the current ETL_HAS_ are the same with both arches on multilibs system, I would still prefer this solution since it will still be valid if others ETL_HAVE need to be introduced later.

About the package name. One could say this is not a -devel but a -headers subpackage only, since it doesn't contain the symlink to a shared object.
But -devel and -headers only exist when there is a "main" package also.
(kernel-headers and kernel-devel exist because they are for a different usage than the kernel package itself.)
Since there is no such "main" package, I think the current package is the main.

In other words:
From one side, I don't see anything to override the Fedora guideline which tell to use the upstream source archive name as the "source" package name.
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#General_Naming
See also https://bugzilla.redhat.com/show_bug.cgi?id=428567#c31

On the other side, it remains possible for the ETL source package to only build an ETL-devel or ETL-headers package. (or to have only the ETL-%{version}-%{release}.src.rpm just build a plain ETL-%{version}-%{release}.%{_target_cpu}.rpm)

(either using ETL-devel or ETL, the pkgconfig(ETL) provides will be properly extracted).
Comment 67 Nicolas Chauvet (kwizart) 2009-02-03 10:43:52 EST
any question / tought ?
Comment 68 Lubomir Rintel 2009-02-03 14:56:02 EST
(In reply to comment #66)
> Look at 
> https://bugzilla.redhat.com/show_bug.cgi?id=428567#c17
> The current package miss the etl_profile.h move into %{_libdir}/ETL and the
> related adds in ETL.pc (Cflags: -I${includedir} -I${libdir}/ETL)
> If ever the current ETL_HAS_ are the same with both arches on multilibs system,
> I would still prefer this solution since it will still be valid if others
> ETL_HAVE need to be introduced later.

etl_profile.h can not be moved there, apart from it not being a good idea, FHS forbids that. In case the include files become arch-dependent (which is not likely anyways), the be renamed and a header that would include one depending on __WORD_SIZE will be in their original place. This is a common practice.

> About the package name. One could say this is not a -devel but a -headers
> subpackage only, since it doesn't contain the symlink to a shared object.
> But -devel and -headers only exist when there is a "main" package also.
> (kernel-headers and kernel-devel exist because they are for a different usage
> than the kernel package itself.)
> Since there is no such "main" package, I think the current package is the main.
> 
> In other words:
> From one side, I don't see anything to override the Fedora guideline which tell
> to use the upstream source archive name as the "source" package name.
> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#General_Naming
> See also https://bugzilla.redhat.com/show_bug.cgi?id=428567#c31
> 
> On the other side, it remains possible for the ETL source package to only build
> an ETL-devel or ETL-headers package. (or to have only the
> ETL-%{version}-%{release}.src.rpm just build a plain
> ETL-%{version}-%{release}.%{_target_cpu}.rpm)
> 
> (either using ETL-devel or ETL, the pkgconfig(ETL) provides will be properly
> extracted).

When someone says "devel package", what comes to my mind is "useful for development", not "having a symlink to shared object" and I'd like to leave it that way. I think you see that this might be a matter of personal taste and doesn't violate guidelines, so I'm not going to change it unless there's a really serious objection.
Comment 69 Nicolas Chauvet (kwizart) 2009-02-03 16:27:38 EST

(In reply to comment #68)
> (In reply to comment #66)
> likely anyways), the be renamed and a header that would include one depending
> on __WORD_SIZE will be in their original place. This is a common practice.

It would be an accurate solution, indeed.

> When someone says "devel package", what comes to my mind is "useful for
> development"
Actually the package name is already ETL which only produce an ETL-devel.

So I think we are good. I'm looking synfig/synfig studio to have usability tests of the ETL package...
Comment 70 Nicolas Chauvet (kwizart) 2009-02-05 13:08:27 EST
package ETL is APPROVED
Comment 71 Nicolas Chauvet (kwizart) 2009-02-23 14:56:36 EST
any news ?
Comment 72 Lubomir Rintel 2009-02-26 12:35:19 EST
New Package CVS Request
=======================
Package Name: ETL
Short Description: Extended Template Library
Owners: lkundrak (anyone who wants to comaintiain this, feel free to opt in)
Branches: EL-5 F-10
Comment 73 Kevin Fenzi 2009-02-26 19:26:41 EST
cvs done.
Comment 74 Lubomir Rintel 2009-03-01 07:32:17 EST
Imported and built.
Thanks for good review and CVS.
Comment 75 Paul Wise (Debian) 2009-05-10 22:23:23 EDT
Lubomir etc, could you please review this alternate patch:

http://patches.synfig.org/r/25/diff/#index_header

Please note that some of the Fedora changes are already committed in SVN and some related changes are also in SVN.

The patch does the following:

Generate etl_profile.h in a less hacky way.

Move the tests needed for generating etl_profile.h into configure.ac.

Use less generic defines in the etl_profile.h header

Prefix private defines with a double underscore.

Move the etl_profile.h header to an arch-specific dir to prepare for multi-arch.
Comment 76 Lubomir Rintel 2009-06-07 05:09:08 EDT
(In reply to comment #75)
> Lubomir etc, could you please review this alternate patch:
> 
> http://patches.synfig.org/r/25/diff/#index_header

Seems very well. Thanks!

Note You need to log in before you can comment on or make changes to this bug.