Bug 177747

(Adding blocker on FE-NEW.)

First off, is there still any interest in getting this package into Extras? 
Unfortunately this ticket did not properly block FE-NEW, it seems nobody ever
noticed that it was even here.  It looks like it wasn't submitted through the
normal review request submission form.

Secondly, if there is still interest, could we get direct links to a specfile
and a src.rpm?

Finally, I don't see that the submitter is a member of cvsextras, so I'll block
FE-NEEDSPONSOR.  Feel free to unblock if that's incorrect.

Hi,

I'm not an FE contributor, and I didn't bother reading those instructions.
Please help me if anyone would sponsor me, thanks! No, there is no standalone
spec and src.rpm, only cvs version available. We may have a directory on
ftp.fedora.cn for this purpose later.

We're going to need something to actually review, so a spec and an SRPM are
absolutely necessary.

Sponsorship is granted only after the packager has demonstrated familiarity with
the packaging guidelines; please see
http://fedoraproject.org/wiki/Extras/HowToGetSponsored for more information.

spec and srpm uploaded to ftp for review, which is at
ftp://ftp.fedora.cn/pub/fedora-cn/fe-review/glade3
mock build passed, there is something I'm not sure, that is
BuildRequires: perl(XML::Parser)
since I don't know if it is an intltool dependency or glade3's.

> BuildRequires: perl(XML::Parser)

The included intltool needs this. If intltool were not included, you
would do  "BuildRequires: intltool"  instead.


>  --add-category X-Red-Hat-Base

No. This is Extras, not Core.


> rm -rf $RPM_BUILD_ROOT/var/scrollkeeper

What's that? Unusual enough to add a comment in the spec file, please.


> scrollkeeper-update -q || :
> scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :

There are no such files in the package(s).


> update-mime-database

The package does not install such files which need this.


* The package description refers to a "glade2" package and GTK+ 2.0,
whereas this is glade3 for GTK+ >= 2.8.  It is not spelled "GLADE"
either. Upstream calls it "Glade".

* Run "yum install glade2 glade3" and look at the desktop menus.
They are almost identical and don't say which one is Glade3.
As long as both shall coexist, I suggest you patch that.

* %doc AUTHORS ChangeLog COPYING NEWS README TODO

You have these duplicated in both packages. Including them in either
one is more than enough, preferably "libgladeui" (or the main pkg
if nothing is split off).

* The build.log says:

| checking for GTK... yes
| checking for GNOME... configure: creating ./config.status
| config.status: creating Makefile

| Configuration:
| 
|         Source code location:   .
|         Compiler:               gcc
|         GnomeUI Catalog:        no

Adding  "BuildRequires: libgnomeui-devel" changes that to "yes".
If not wanted, use the --disable-gnome switch for reproducible builds.

* glade3-devel is missing:

Requires: gtk2-devel libxml2-devel


> %package devel
> Requires:	%name = %{version}

Ought to be full  %{version}-%{release}

> Requires:	gail-devel 

Huh? No reference to libgail can be found.

> Provides:	glade-devel

Splitting of  libgladeui  and  libgladeui-devel  instead of this sounds
sane. You don't really want to occupy both the "glade3-devel" and
"glade-devel" namespace.

I think you should split up the package. I see there three (or two depends on
point of view) independent parts: glade3, libgladeui and libgladeui-devel. I
have one good reason for such division - for anjuta2 glade3 plug-in you need
only libgladeui(-devel), not whole glade3. I think that glade3 is front-end for
libgladeui, from a development point of view. You can compare my package with
yours; the specfile is here:
http://forums.fedoraforum.org/forum/attachment.php?attachmentid=10171

Is there a persistent need to change the package name with each major glade
release? The package "glade" hasn't appeared in Fedora Core since 2. Do there
continue to be reasons someone might want to have packages for glade 0.6.x and
glade 3.x installed concurrently?

spec updated according to your advice, thank you!

please have a look:

ftp://ftp.fedora.cn/pub/fedora-cn/fe-review/glade3/glade3.spec
ftp://ftp.fedora.cn/pub/fedora-cn/fe-review/glade3/glade3-3.0.2-0.6.src.rpm

changes:

* split to 3 packages: glade3, libgladeui, libgladeui-devel
glade3 is the binary, the desktop related files including a proposed icon from
tango project
libgladeui is the library and shared resource files (pixmaps and catalog xml)
libgladeui-devel is the headers and development documentation

* changed requires and buildrequires

* update description from the website. Still looking for a better description
for libgladeui

* incorporate various things from Martin's sample file

Okay, this is a dup of something I've submitted for FE.

The problem with libgladeui is the potential for clash with the current
libgladeui (okay, different version I know)...

As it's Christmas day, I'm doing nothing today other than with my family, so
I'll hack on with this tomorrow. In the meantime, my version of the spec and
srpm are available at

http://nodoid.homelinux.org/fedora/glade3-3.1.4-1.src.rpm
http://nodoid.homelinux.org/fedora/glade3.spec

Personally, I'd rather not separate out the libgladeui from the main package.

*** Bug 220710 has been marked as a duplicate of this bug. ***

Hmm, I can't see the logic (to be honest) of splitting the package in the way
you have. To me, it makes far more sense to have glade3 with the binary and any
shared  libs (will the glade3 binary run without the libs?) and having a devel
file with the .so files.

Also, why have you moved from the standard version-release system to
version-release.number?

Please re-instate any changes that you made to the spec file prior to the
version you want reviewing in the changelog - it helps people learn.

3.0.2 is quite an old version now - any chance of moving it to 3.1.4?

libgladeui belongs in its own package because it is useful on its own (i.e.,
without the glade3 binary).

Hmm, is it going to be a painless dropin replacement for older versions of glade
available in core?

Regarding the packaging.

1. Builds fine in mock (x86)
2. glade3 rpm contains no documentation as does the -devel package (which is
fine for the devel).
3. src.rpm has the mixed spaces/tabs warning
4. Why does this have an epoch number? As glade3 is a new package, it shouldn't
need an epoch.

(In reply to comment #14)
> Hmm, is it going to be a painless dropin replacement for older versions of 
glade
> available in core?

We can infer from the name of the source distribution and the binary--i.e., 
deliberately different from the 2.x series--that the answer is "no". But I 
don't see how this is a packaging issue. (I asked Yuan Yijun to ignore my 
comment #8 and I ask that others do the same. This is an upstream issue.) I 
think it's up to the Core and glade2 package maintainers whether they want to 
keep that package alive alongside a glade3 package.

Hi,

I made an update to the spec file, to use the latest 3.1.4 package. Besides
that, the spec and srpm download URL has been changed a little. Please have a
look and tell me what to do next, thank you all!

URL?

(In reply to comment #17)
> URL?

I think he means the URL in additional bug info:
ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3.spec

and for the srpm:
ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3-3.1.4-0.8.src.rpm

Hmm, would people be offended if I offered to just update the current glade2
package to glade 3 ? assuming that glade3 can read all glade2 files and libglade
can read all glade3 files, I don't really see any reason to keep both.
The only downside is the number mismatch between the package name and the
tarball version; but I don't think reusing glade as a package name is an option
at this point.

And a mismatch between the RPM package name and the tarball package name.

What makes what you're suggesting a good idea?

Update to 3.2.0

Spec URL: ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3.spec
SRPM URL: ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3-3.2.0-1.src.rpm

> And a mismatch between the RPM package name and the tarball package name.

So what ? How is it important ?

> What makes what you're suggesting a good idea?

The fact that there is no real need to maintain glade2 and glade3 in parallel.

(In reply to comment #22)
> > And a mismatch between the RPM package name and the tarball package name.
> 
> So what ? How is it important ?
> 
> > What makes what you're suggesting a good idea?
> 
> The fact that there is no real need to maintain glade2 and glade3 in parallel.
> 
> 

well, go a head and take it please. 

Thanks.

(In reply to comment #22)
> > And a mismatch between the RPM package name and the tarball package name.
> 
> So what ? How is it important ?
> 
> > What makes what you're suggesting a good idea?
> 
> The fact that there is no real need to maintain glade2 and glade3 in parallel.
> 
> 

What about making a glade3 package there obsoletes the glade2 package.
Having a glade2 package with the glade3 code inside, sound a little weird to me.

 

(In reply to comment #22)
> > And a mismatch between the RPM package name and the tarball package name.
> 
> So what ? How is it important ?

It's completely non-important.

> > What makes what you're suggesting a good idea?
> 
> The fact that there is no real need to maintain glade2 and glade3 in parallel.
This would be news to me.  Has glade3 been made glade2 compatible?

Last time, I tried, nothing could be further from truth.

Any news on when Glade3 becomes available for fedora.

Hi,

Please anyone feel free to take this or submit it again, thanks!

http://glade.gnome.org/

"One of the main differences from glade-2 is that C code generation has been
removed from glade-3: this has been done on purpose, since using generated code
is deprecated; the preferred way to use glade files is with libglade (if code
generation is needed, this can be provided as another tool or plugin, code
generation is simply not a part of the glade-3 project).
[...]
It has a few useful new features such as stacked Undo/Redo and Multiple Project
supportand respects the same XML format as glade-2."

It seems that Glade-3 does have some compatibility with Glade-2.

So what is the current status? Is the Glade-2 package going to be replaced by
Glade-3, or they are going to be kept side-by-side?

Debian is already providing Glade-3 in Lenny (testing) and Sid (unstable). See
http://packages.debian.org/search?keywords=glade&searchon=names&suite=all&section=all

Shall I pick up this review request and submit a fresh pair of Spec & SRPM?

That'd be great! You'd want to open a new review ticket though. Cc: me and I'll
review it.

(In reply to comment #30)
> That'd be great! You'd want to open a new review ticket though. Cc: me and I'll
> review it.

Hey Michel, thanks for the offer. However a few people (like Matthias Clasen)
were suggesting that I reopen this bug. Would that be fine? Since you are
probably going to review it, I shall leave the choice to you.

Unfortunately I could not locate any of the Spec/SRPM pairs submitted for Glade3
till now. So I am writing it from scratch with a bit of help from the Glade2
package. Should be done by today or tomorrow.

You can finde spec file etc here.
http://timlau.fedorapeople.org/files/pkgs/glade3/

(In reply to comment #32)
> You can finde spec file etc here.
> http://timlau.fedorapeople.org/files/pkgs/glade3/

Thanks a lot. That would make my job much simpler. This looks like the Spec
submitted by Yijun Yuan <bbbush.yuan>.

(In reply to comment #33)
> (In reply to comment #32)
> > You can finde spec file etc here.
> > http://timlau.fedorapeople.org/files/pkgs/glade3/
> 
> Thanks a lot. That would make my job much simpler. This looks like the Spec
> submitted by Yijun Yuan <bbbush.yuan>.

Yes, it is, i have just uploaded a new one with some rpath fixes.

(In reply to comment #34)
> Yes, it is, i have just uploaded a new one with some rpath fixes.

I am curious as to why you wanted to apply those RPath fixes. I have good reason
to believe there are no such issues. I used
"%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot"
in my ~/.rpmmacros as mentioned in
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544
and found no problem.

Spec URL: http://rishi.fedorapeople.org/glade3.spec
SRPM URL: http://rishi.fedorapeople.org/glade3-3.4.0-1.fc8.src.rpm

Description:

Glade is a RAD tool to enable quick and easy development of user interfaces for
the GTK+ toolkit and the GNOME desktop environment.

The user interfaces designed in Glade are saved as XML, which can be used in
numerous programming languages including C, C++, Java, Perl, Python, C#, Pike,
Ruby, Haskell, Objective Caml and Scheme. Adding support for other languages
is easy too.

Glade-3 is meant for GTK+ 2.8 or newer.

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=228611

I have opened a new review request at
https://bugzilla.redhat.com/show_bug.cgi?id=369381 and will close this as a
duplicate.

*** This bug has been marked as a duplicate of 369381 ***

(In reply to comment #35)
> (In reply to comment #34)
> > Yes, it is, i have just uploaded a new one with some rpath fixes.
> 
> I am curious as to why you wanted to apply those RPath fixes. I have good reason
> to believe there are no such issues. I used
> "%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot"
> in my ~/.rpmmacros as mentioned in
>
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544
> and found no problem.
> 
> 

I got some rpath errors when building on a x86_64 system, i didn't see any on a
i686 system.

(In reply to comment #39)
 
> I got some rpath errors when building on a x86_64 system, i didn't see any on a
> i686 system.

Ok, I shall fix it. Looks like Koji does not check for RPath errors.

Let us continue the discussion on bug #369381.