Bug 652971 (code-editor)

Hi,

Just to clarify, I'm the upstream author of the package. I've already had it built on Koji.

-Ilyes

Hi,

I have rebased code-editor against Qt Creator commit a23a45d and published a new src.rpm at http://ilyes.fedorapeople.org/code-editor-1-1.fc14.src.rpm and spec file at http://ilyes.fedorapeople.org/code-editor.spec

rpmlint doesn't report any issue on the spec file.

I'm also adding in CC Rex Dieter and Itamar Reis Peixoto the packagers of Qt Creator in Fedora, in an attempt to get sponsored to become a packager for code-editor.

-Ilyes

> License:        LGPLv2 with exceptions

Just curious, what exceptions are those? I see the spec file mentions a %doc file, so JFYI: The guidelines say that you would need approval from Fedora Legal.
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses


> Source0:        code-editor-src.tar.bz2

Is the tarball available at some URL?
https://fedoraproject.org/wiki/Packaging/SourceURL


> Requires:       qt >= 4.7.0

https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires

Hi Michael,

> Just curious, what exceptions are those? I see the spec file mentions a %doc
> file, so JFYI: The guidelines say that you would need approval from Fedora
> Legal.

Right. Actually that's wrongly mentioned in the spec file. I intend to release the entire package under an LGPL license.

code-editor is derived from QtCreator which has an internal architecture based on plugins implementing the various functionalities and services of the tool, and these are released by Nokia under a Commercial and LGPL licenses. code-editor reuses a subset of these plugins, sometimes applying slight changes to mainly remove a little bit of functionality, where this one should be provided by another plugin that I didn't pickup for inclusion in code-editor.

The same applies for QtCreator in terms of licensing. QtCreator acts as a loader/containers for these plugins and in the case of code-editor I'm actually bringing in some few modifications, such as to open files from the command line, re-organize the application's menu a little bit, changing the name of the application, to the original source code.

> Is the tarball available at some URL?

Yes, both the srpm and the spec files are available at:

http://ilyes.fedorapeople.org/code-editor-1-1.fc14.src.rpm
http://ilyes.fedorapeople.org/code-editor.spec

> Requires:       qt >= 4.7.0
> https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires

I'll fix that asap and publish the new spec file and package on fedorapeople.

Thanks!

-Ilyes

Hi Michael,

I just pushed these updates on fedorapeople.org:

http://ilyes.fedorapeople.org/code-editor.spec
http://ilyes.fedorapeople.org/code-editor-1-2.fc14.src.rpm

These include the license clarification: code-editor is now advertised as released under LGPL v2.

Just for reference, the original software Qt Creator as released by Nokia is released under both a Commercial license and LGPL v2 + Exceptions, where these exceptions actually grant additional liberty in the form of linking closed-form resource files (art, macros, numeric data, etc.) against the rest of the code.

I've also made available a tarball with all the source code and build scripts at:

http://ilyes.fedorapeople.org/code-editor-src.tar.bz2

Regards,

-Ilyes

Hi,

I just pushed a new srpm and specfile to http://ilyes.fedorapeople.org

Regards,

-Ilyes

Hi,

I've been updating CodeEditor all along, re-basing regularly on Qt Creator 2.3 branch. Qt Creator 2.3.0 was officially released few days ago.

Again, CodeEditor is all about customizing Qt Creator by taking its code editing capabilities a part and making it available as a standalone application (a lightweight, cut down Qt Creator) which can be used to edit individual text/code files comfortably.

Latest code is on http://gitorious.org/~ilyesgouta/code-editor
Latest SRPMs are on http://ilyes.fedorapeople.org/
Latest release is http://ilyes.fedorapeople.org/code-editor-1-8.fc15.src.rpm, build-able for Fedora 15. I has been a long time since my last build on koji.

-Ilyes

I can review.

naming: not sure.  Shouldn't code-editor version (roughly) match qt-creator?  ie, your intention isn't to call it version 1 forever, is it? :)

sources: NOT ok, cannot verify sources
could you either provide release tarballs, or some script/recipe to generate reproducible sources based on upstream tag or something?

license: ok

scriptlets: ok

macros: ok

SHOULD: simplify %files, what you have could be simplified using dirs and globs, to something like:
%files
%{_bindir}/code-editor
%{_libdir}/code-editor/
%{_datadir}/code-editor/
%{_datadir}/icons/hicolor/*/*/codeeditor.*
%{_datadir}/applications/code-editor.desktop

SHOULD: .desktop file improvements,
add Comment= tag (for non-kde DE's, ie, gnome)
add more Categories, like Qt and maybe IDE (like qt-creator has), see also
http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#category-registry

SHOULD: replace
BuildRequires: qt-devel
Requires: qt
with
BuildRequires: qt4-devel
%{?_qt4_version:Requires: qt4%{?_isa} >= %{_qt4_version}}
(the latter will ensure that a dependency on at least version of qt that was used to build it with).
(for fun, see /etc/rpm/macros.qt4 for other qt-related rpm macros)

SHOULD: I see a lot of items removed at end of %install section, please document what these are and why they're omitted from packaging.

So, the only real blocker here that I'd like at least some clarification is the upstream version/sources thing.  The rest are all nice-to-have's.

s/BuildRequires: qt4-devel/BuildRequires: qt4-devel >= 4.7/
versioning these as appropriate is good. :)

Thanks a lot Rex, I'm going to fix up the spec file and provide the missing information, asap.

-Ilyes

Hi Rex,

> naming: not sure.  Shouldn't code-editor version (roughly) match qt-creator?
> ie, your intention isn't to call it version 1 forever, is it? :)

I updated the .spec file to indeed reflect qt-creator's actual version. Yes, I'm always rebasing on Qt Creator's stable branches, so using the same version makes sense.

> sources: NOT ok, cannot verify sources
> could you either provide release tarballs, or some script/recipe to
> generate reproducible sources based on upstream tag or something?

I just finished uploading a .tar.bz2 snapshot at http://ilyes.fedorapeople.org/code-editor-src.tar.bz2

The same code base can be obtained from the git repository, by issuing a:

$ git clone git://gitorious.org/~ilyesgouta/qt-creator/code-editor.git -b code-editor_2.3

> SHOULD: simplify %files, what you have could be simplified using dirs
> and globs, to something like:

I corrected and simplified the .spec file and uploaded it on fedorapeople.org. It's available at: http://ilyes.fedorapeople.org/code-editor.spec

I've also regenerated the SRPM and uploaded it there.

-Ilyes

Looks good, 

MUST: remove Vendor: tag from .spec

I'll leave it to you to remove that prior to importing

APPROVED.

Give me your FAS username, and I'll sponsor you (post here or send to me privately ok)

Hi Rex,

> MUST: remove Vendor: tag from .spec

Done. Would you mind to explain why? Is this automatically appended/generated by Fedora's build system?

My FAS username is: ilyes

Thanks! :)

-Ilyes

> Done. Would you mind to explain why? Is this automatically appended/generated
> by Fedora's build system?

Yes, Koji automatically fills in:
Packager    : Fedora Project
Vendor      : Fedora Project

Hi,

I've also submitted the package to koji for building for dist-f15, f16, f17 and rawhide:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3322930
http://koji.fedoraproject.org/koji/taskinfo?taskID=3322940
http://koji.fedoraproject.org/koji/taskinfo?taskID=3322954
http://koji.fedoraproject.org/koji/taskinfo?taskID=3322973

and it completed successfully.

-Ilyes

FYI:
* Rawhide and F17 are the same thing, and will stay the same thing for ~5 more months.
* You should build for dist-f15-updates-candidate and f16-updates-candidate rather than dist-f15 and dist-f16.
* You may want to build this for F14 (dist-f14-updates-candidate) too; AFAIK, f14 git branches can still be created. (The deadline is the F16 release.) But of course you don't have to add this to F14 if you don't want.

Actually, the correct build targets to use are:
rawhide
f16-candidate
f15-candidate
f14-candidate
(fedpkg still uses "dist-rawhide", it seems, but "rawhide" got created. The new "f*-candidate" targets are already in use.)

(The new names without the "dist" also don't have "updates" in it, and they also got created for F15 and F14.)

Hi Kevin,

Alright, I'll build for those targets too. And yes, having the package for f14 would also be interesting, at least for my immediate entourage :)

-Ilyes

Kevin,

It also looks good for f16-candidate, f15-candidate and f14-candidate:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3323034
http://koji.fedoraproject.org/koji/taskinfo?taskID=3323049
http://koji.fedoraproject.org/koji/taskinfo?taskID=3323054

-Ilyes

OK, I'd suggest you now do some non-scratch builds, 

http://fedoraproject.org/wiki/PackageMaintainers/Join#Import.2C_Commit.2Cand_Build_Your_Package

and submit these as updates so they are made available to users in fedora repos,

http://fedoraproject.org/wiki/PackageMaintainers/Join#Submit_Package_as_Update_in_Bodhi

Oh, back up a couple steps, need a scm module created first too:

http://fedoraproject.org/wiki/PackageMaintainers/Join#Add_Package_to_Source_Code_Management_.28SCM.29_system_and_Set_Owner

(I'd suggest you review that whole document to familiarize yourself with the whole process)

New Package SCM Request
=======================
Package Name: code-editor
Short Description: A lightweight and cross-platform text and code editor based on Qt Creator
Owners: ilyes
Branches: f15 f16 f17
InitialCC:

Hi Rex,

I also need to get sponsored first (which I believe still not) in the packager group before being able to request for an SCM. This is a separate process item, isn't?

Thanks,

-Ilyes

Of course!  Sorry.  ;)  sponsored now.

Thanks a lot Rex!

I'll do my best contributing to Fedora!

-Ilyes

New Package SCM Request
=======================
Package Name: code-editor
Short Description: A lightweight and cross-platform text and code editor based
on Qt Creator
Owners: ilyes
Branches: f15 f16 f17
InitialCC:

Git done (by process-git-requests).

f17==devel, should not be requested at present.

Hi Jon,

Alright, thanks a lot!

-Ilyes

Hi,

I imported code-editor into Fedora's SCM and successfully built it via fedpkg on Koji for f15, f16 and master branches. Following is the Koji's (simplified) log:

Building code-editor-2.3.0-9.fc15 for f15-candidate
Created task: 3389622
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3389622
3389622 build (f15-candidate, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508): open (ppc10.phx2.fedoraproject.org)
3389622 build (f15-candidate, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508): open (ppc10.phx2.fedoraproject.org) -> closed
3389622 build (f15-candidate, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508) completed successfully


Building code-editor-2.3.0-9.fc16 for f16-candidate
Created task: 3389599
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3389599
3389599 build (f16-candidate, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508): open (ppc05.phx2.fedoraproject.org)
3389599 build (f16-candidate, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508): open (ppc05.phx2.fedoraproject.org) -> closed
3389599 build (f16-candidate, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508) completed successfully


Building code-editor-2.3.0-9.fc17 for dist-rawhide
Created task: 3389554
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3389554
3389554 build (dist-rawhide, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508): free -> open (ppc05.phx2.fedoraproject.org)
3389554 build (dist-rawhide, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508): open (ppc05.phx2.fedoraproject.org) -> closed
3389554 build (dist-rawhide, /code-editor:2a396b35baf31dc45c3dca35d72d636256a01508) completed successfully

Next step would be pushing to Bodhi for testing, right?

Thanks, :)

-Ilyes

Correct

$ rpm -qp --provides code-editor-2.3.0-9.fc16.i686.rpm|grep so
libAggregation.so.1  
libBinEditor.so  
libCPlusPlus.so.1  
libCore.so  
libCppEditor.so  
libCppTools.so  
libExtensionSystem.so.1  
libFakeVim.so  
libFind.so  
libLanguageUtils.so.1  
libLocator.so  
libQtConcurrent.so.1  
libTextEditor.so  
libUtils.so.1  

The versioned ones in there are potentially dangerous as they bear a bigger risk of confusing depsolvers. These shared libs are stored in a private path in %_libdir/code-editor -- outside run-timer linker's search paths that is -- and hence the package should not "Provides" these library SONAMEs.

# repoquery --whatprovides libAggregation.so.1
freemedforms-0:0.5.9-0.1.alpha1.fc16.i686
qt-creator-0:2.3.0-0.0.beta.fc16.i686

Hi Michael,

Yes, those are plug-ins loaded by the editor at run-time, where each one provide a bit of functionality so that the whole make up the entire program. This is Qt Creator's design. They're *private* to the program itself and shouldn't be loaded by any other party.

Do you suggest to modify to .spec file so that to avoid advertising them as provided?

> # repoquery --whatprovides libAggregation.so.1
> freemedforms-0:0.5.9-0.1.alpha1.fc16.i686
> qt-creator-0:2.3.0-0.0.beta.fc16.i686

Does it also mean that qt-creator and freemedforms should also be revised?

Thanks,

-Ilyes

Hi,

Just to clarify a little bit more:

Plugins/libraries providing the program's functionality:
libBinEditor.so    
libCore.so  
libCppEditor.so  
libCppTools.so  
libFakeVim.so  
libFind.so  
libLocator.so  
libTextEditor.so  

Supporting libraries:
libAggregation.so.1  
libExtensionSystem.so.1  
libLanguageUtils.so.1  
libQtConcurrent.so.1  
libUtils.so.1  
libCPlusPlus.so.1

Both kind of libraries live in a private location (%_libdir/code-editor) and are internal and *exclusively* used by the program itself. No other program or library is meant to link against these. The build system (qmake based) indeed relies on RPATH to load these libraries at run-time:

ilyes@whitebird ~/rpmbuild  $ readelf -d /usr/bin/code-editor | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN:$ORIGIN/..:$ORIGIN/../lib64/code-editor]

Is this acceptable? Any suggestions?

Thanks,

-Ilyes

> Do you suggest to modify to .spec file so that to avoid advertising
> them as provided?

For the versioned libraries that would be better. Not mandatory however with our current guidelines. Primarly I want you to be aware of this.

Even if currently there are no other packages in the package collection, which share these library names, it is not nice to pollute the global namespace with versioned SONAME Provides.

# repoquery --whatrequires libAggregation.so.1
freemedforms-devel-0:0.5.9-0.1.alpha1.fc16.i686

If we didn't had a base package dependency in the guidelines, this would break here already.

[...]

> Does it also mean that qt-creator and freemedforms should also be revised?

freemedforms is mispackaged IMO: bug 742396

Hi Michael,

> For the versioned libraries that would be better. Not mandatory however
> with our current guidelines. Primarly I want you to be aware of this.

Yes, indeed. It's important, as similar versioned shared libraries provided by more than one package would cause associated binaries to clash and potentially misbehaving. This is nicely documented over https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

> Even if currently there are no other packages in the package collection,
> which share these library names, it is not nice to pollute the global
> namespace with versioned SONAME Provides.

Do I need to include a:

rm -f %{buildroot}%{_libdir}/code-editor/lib*.so.1

In my %install section?

Thanks,

-Ilyes

No, that's not a good idea. Your stuff will most likely not run at all anymore if you do that.

You probably need to filter the automatic Provides.

See http://lists.fedoraproject.org/pipermail/devel/2011-February/148317.html and https://fedorahosted.org/fpc/ticket/76 for the macros which are available to filter Provides and Requires, but those require at least RPM 4.9, i.e. at least Fedora 15.

You can use:
%global __provides_exclude_from %{_libdir}/code-editor/.*
but you'll probably also need to filter the corresponding Requires. I guess this should work:
%global __requires_exclude lib[A-PR-Z].*\\.so\\.1(\\\(\\\)\\\(64bit\\\))?
(There are no Requires on the unversioned .so plugins.)

This has nothing to do with rpaths.

Imagine the following scenario:

1) A future separate package in the Fedora package collection, give it the lame name "liblanguageutils" although it could have a different name. It includes a system-wide library libLanguageUtils.so.1 and therefore "Provides: libLanguageUtils.so.1" automatically.

2) A future separate package in the Fedora package collection, name it "foo", which builds with liblanguageutils-devel and therefore creates an automatic dependency "Requires: libLanguageUtils.so.1".

3) Attempting to "yum install foo" might decide to pull in code-editor because it "Provides: libLanguageUtils.so.1" for its private library outside run-time linker's search path.

4) Attempting to run the foo program will fail, because the needed shared library from package "liblanguageutils" is not installed yet.

[Similar scenarios are possible when working with sub-packages. Simple inter-package dependencies can fail to resolve correctly already if multiple packages provide the same things but for stuff outside standard system search paths.]


> Do I need to include a:
> 
> rm -f %{buildroot}%{_libdir}/code-editor/lib*.so.1

No, of course not! That would remove the plugin library and might break the program, because it could not no longer dlopen the library at run-time. :)

You can find documentation about filtering automatic Provides/Requires here:
http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

Remember, however, that currently there is no such conflict with any other package. No damage is done yet. It's just an increased risk to create a sudden problem some time in the future.

The guidelines say:

| MUST: Packages must not provide RPM dependency information when that
| information is not global in nature, or are otherwise handled (e.g. through
| a virtual provides system). e.g. a plugin package containing a binary shared | library must not "provide" that library unless it is accessible through the
| system library paths.

You might also need 1 backslash before the parentheses which aren't escaped now, i.e.:
%global __requires_exclude lib[A-PR-Z].*\\.so\\.1\(\\\(\\\)\\\(64bit\\\)\)?
(i.e. escape them for RPM, but not for the regex engine).

If this doesn't work as is, try to play a bit with the backslashes.

> You can find documentation about filtering automatic Provides/Requires here:
> http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

That's the deprecated mechanism which is required for RPM 4.8 (Fedora <= 14), but which the RPM developers recommend strongly against using, because it changes the dependency extractor used, which breaks things such as ELF file coloring for multilib.

Hmmm, nevermind, looks like the macros in use there are new wrappers which should do the right thing both with old and new RPM. So I guess using the macros from https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering is the best thing to do.

Michael, Kevin,

Thanks for the explanations! Understood :)

I'll fix up my .spec file and check out the --provides again.

> rm -f %{buildroot}%{_libdir}/code-editor/lib*.so.1

Please, never mind! :) I was actually thinking about going back to the build system and reworking certain parts.. But then it would be pointless, since this is a packaging and not a build detail.

Is there an automatic tool in place to detect such an issue (so leading to false and run-time broken dependencies) among a set of packages (such as in a repo.)?

-Ilyes

> Is there an automatic tool [...]

Not that I know of.

Unresolvable dependencies (aka "broken deps") are detected by AutoQA when submitting packages via bodhi. Repoclosure (from yum-utils) can check remote repositories for broken deps.

But I'm not aware of any tool that tries to detect packaging mistakes, such as superfluous, dangerous or conflicting Requires/Provides pairs. It wouldn't be a simple script, because it would need to implement quite a lot to get it right. Also to avoid false positives. E.g. ld.so.conf parsing, rpath checking, handling of alternative packages which are permitted to provide the same stuff, exceptions such as libraries that don't set a versioned SONAME yet, ...

If you're familiar with your package, you take a look at "rpm -qp --provides ..." and "... -requires" output once or twice a year. ;-) A brief plausibility check. Perhaps also a "repoquery --whatrequires code-editor" to check whether any other package in the repos is marked as depending on something provided by the "code-editor" package.

For example, provided that code-editor were available in the repos already:

# repoquery --whatrequires code-editor
freemedforms-devel-0:0.5.9-0.1.alpha1.fc16.x86_64

Hi Michael,

Based on the https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering page, I updated my .spec file with these few lines:

%{?filter_setup:
%filter_from_provides /.*\.so\.1$/d; /.*\.so\.1()(64bit)$/d
%filter_from_requires /.*\.so\.1$/d; /.*\.so\.1()(64bit)$/d
%filter_setup
}

/.*\.so\.1$/d would remove the provides/requires for a 32bit build and
/.*\.so\.1()(64bit)$/d would do the same for a 64bit build

Now rpm -qp --provides RPMS/x86_64/code-editor-2.3.0-9.fc15.x86_64.rpm returns:

ilyes@whitebird ~/rpmbuild  $ rpm -qp --provides RPMS/x86_64/code-editor-2.3.0-9.fc15.x86_64.rpm 
libBinEditor.so()(64bit)  
libCore.so()(64bit)  
libCppEditor.so()(64bit)  
libCppTools.so()(64bit)  
libFakeVim.so()(64bit)  
libFind.so()(64bit)  
libLocator.so()(64bit)  
libTextEditor.so()(64bit)  
mimehandler(text/x-c++hdr)  
mimehandler(text/x-chdr)  
mimehandler(text/x-c++src)  
mimehandler(text/x-csrc)  
mimehandler(text/x-xsrc)  
code-editor = 2.3.0-9.fc15
code-editor(x86-64) = 2.3.0-9.fc15

Looks good, isn't?

-Ilyes

* If you filter the Requires/Provides, you could also filter out the non-versioned library names, because those are also private to code-editor.

* Filtering on just ".so.1$" is unsafe. It currently drops the libgcc_s.so.1 dependency. The hardcoded ".1" may cause problems if code-editor's plugin lib version is changed to .2 or higher. Then more valid dependencies would be filtered out, such as libdl.so.2. Qt's libs are .4, C/C++ stdlib is .6, for example.

For filtering Provides, you could ignore the entire plugins directory by using
%filter_provides_in.

For filtering Requires, a logical OR list of the library base names would work, such as a regexp based on: libAggregation | libCore | libCppTools | ...

If the list of plugin libs changes frequently during upgrades, you could add a guard somewhere in %install or %check section, where to terminate the build if the filter_from_requires regexp needed an update.

> Looks good, isn't?

No, looks completely wrong!

(I started writing this before Michael's reply, so there is some overlap.)

These bogus Provides are still there:
libBinEditor.so()(64bit)  
libCore.so()(64bit)  
libCppEditor.so()(64bit)  
libCppTools.so()(64bit)  
libFakeVim.so()(64bit)  
libFind.so()(64bit)  
libLocator.so()(64bit)  
libTextEditor.so()(64bit)  
You also need to filter Provides of unversioned .so files.

And your regex for Requires also excludes the valid Requires: libgcc_s.so.1()(64bit). You should be matching only lib[A-Z].*\.so\.1 instead of .*\.so\.1.

Hi Kevin, Michael,

Makes sense.

I updated my .spec so that:

%{?filter_setup:
%filter_provides_in code-editor/plugins
%filter_provides_in code-editor/lib[A-Z].*\.so.*
%filter_from_requires /\(libAggregation\|libCPlusPlus\|libExtensionSystem\|libLanguageUtils\|libQtConcurrent\|libUtils\)\.so.*/d
%filter_from_requires /\(libBinEditor\|libCore\|libCppEditor\|libCppTools\|libFakeVim\|libFind\|libLocator\|libTextEditor\)\.so.*/d
%filter_setup
}

provides are filtered so that irrelevant .so don't reach to rpmdeps -P (pre-scan) and then for the requires, all the .so are retrieved from %BUILD% and then the private libraries are fully specified and filtered out (post-scan). This is tedious but should be safer since we also get the dependencies for the shared libraries that we don't want to advertise.

$ cd rpmbuild/BUILD/code-editor

$ find . -name "*.so*" | /bin/grep -v  'code-editor/plugins' | /bin/grep -v  'code-editor/lib[A-Z].*\.so.*' | while read FILE; do /usr/lib/rpm/rpmdeps -P ${FILE}; done | /bin/sort -u
(doesn't return anything)

$ find . -name "*.so*" | while read FILE; do /usr/lib/rpm/rpmdeps -R ${FILE}; done | /bin/sort -u  | /bin/sed -e '/\(libAggregation\|libCPlusPlus\|libExtensionSystem\|libLanguageUtils\|libQtConcurrent\|libUtils\)\.so.*/d' | /bin/sed -e '/\(libBinEditor\|libCore\|libCppEditor\|libCppTools\|libFakeVim\|libFind\|libLocator\|libTextEditor\)\.so.*/d'
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdl.so.2()(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libQtCore.so.4()(64bit)
libQtGui.so.4()(64bit)
libQtHelp.so.4()(64bit)
libQtNetwork.so.4()(64bit)
libQtScript.so.4()(64bit)
libQtSql.so.4()(64bit)
libQtXml.so.4()(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3.1)(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
rtld(GNU_HASH)

Is this OK?

-Ilyes

Yes, this looks fine now.

(Your new regexes are probably even more specific than what I'd have used, but better too cautious than not enough. :-) )

If the output looks okay, it works, doesn't it? ;-)

> %filter_provides_in code-editor/plugins
> %filter_provides_in code-editor/lib[A-Z].*\.so.*

Could be replaced with just one line for %_libdir/code-editor/

Hi Michael, Kevin,

> Could be replaced with just one line for %_libdir/code-editor/

Yes, sure.

Now:

%{?filter_setup:
%filter_provides_in %_libdir/code-editor/
%filter_from_requires /\(libAggregation\|libCPlusPlus\|libExtensionSystem\|libLanguageUtils\|libQtConcurrent\|libUtils\)\.so.*/d
%filter_from_requires /\(libBinEditor\|libCore\|libCppEditor\|libCppTools\|libFakeVim\|libFind\|libLocator\|libTextEditor\)\.so.*/d
%filter_setup
}

and:

ilyes@whitebird ~/rpmbuild  $ rpm -qp --provides RPMS/x86_64/code-editor-2.3.0-9.fc15.x86_64.rpm 
mimehandler(text/x-c++hdr)  
mimehandler(text/x-chdr)  
mimehandler(text/x-c++src)  
mimehandler(text/x-csrc)  
mimehandler(text/x-xsrc)  
code-editor = 2.3.0-9.fc15
code-editor(x86-64) = 2.3.0-9.fc15

ilyes@whitebird ~/rpmbuild  $ rpm -qp --requires RPMS/x86_64/code-editor-2.3.0-9.fc15.x86_64.rpm 
hicolor-icon-theme  
xdg-utils  
qt4(x86-64) >= 4.7.4
/bin/sh  
/bin/sh  
/bin/sh  
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.14)(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libdl.so.2()(64bit)  
libgcc_s.so.1()(64bit)  
libgcc_s.so.1(GCC_3.0)(64bit)  
libm.so.6()(64bit)  
libm.so.6(GLIBC_2.2.5)(64bit)  
libpthread.so.0()(64bit)  
libpthread.so.0(GLIBC_2.2.5)(64bit)  
libQtCore.so.4()(64bit)  
libQtGui.so.4()(64bit)  
libQtHelp.so.4()(64bit)  
libQtNetwork.so.4()(64bit)  
libQtScript.so.4()(64bit)  
libQtSql.so.4()(64bit)  
libQtXml.so.4()(64bit)  
libstdc++.so.6()(64bit)  
libstdc++.so.6(CXXABI_1.3.1)(64bit)  
libstdc++.so.6(CXXABI_1.3)(64bit)  
libstdc++.so.6(GLIBCXX_3.4)(64bit)  
rtld(GNU_HASH)  
rpmlib(PayloadIsXz) <= 5.2-1

The software is functional and:

[root@whitebird rpmbuild]# ldd /usr/bin/code-editor (trying out just the main binary)
	linux-vdso.so.1 =>  (0x00007ffffbbff000)
	libExtensionSystem.so.1 => /usr/bin/../lib64/code-editor/libExtensionSystem.so.1 (0x00007f13b78e1000)
	libAggregation.so.1 => /usr/bin/../lib64/code-editor/libAggregation.so.1 (0x00007f13b76dc000)
	libQtGui.so.4 => /usr/lib64/libQtGui.so.4 (0x0000003be7200000)
	libQtNetwork.so.4 => /usr/lib64/libQtNetwork.so.4 (0x0000003be8000000)
	libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x0000003be6c00000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00000035a5800000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000035abc00000)
	libm.so.6 => /lib64/libm.so.6 (0x00000035a5c00000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000035a6800000)
	libc.so.6 => /lib64/libc.so.6 (0x00000035a5400000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00000035a6000000)
	libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00000035a7400000)
	librt.so.1 => /lib64/librt.so.1 (0x00000035a6400000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00000035a7000000)
	libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00000035a9c00000)
	libz.so.1 => /lib64/libz.so.1 (0x00000035a6c00000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003bee200000)
	libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00000035a7800000)
	libSM.so.6 => /usr/lib64/libSM.so.6 (0x00000035ac800000)
	libICE.so.6 => /usr/lib64/libICE.so.6 (0x00000035ac400000)
	libXi.so.6 => /usr/lib64/libXi.so.6 (0x0000003e4a600000)
	libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00000035aa400000)
	libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00000035aac00000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00000035aa800000)
	libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00000035ab400000)
	libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00000035ab800000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003bee600000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00000035a9800000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00000035a8000000)
	libssl.so.10 => /usr/lib64/libssl.so.10 (0x00000033f1200000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00000033f0e00000)
	/lib64/ld-linux-x86-64.so.2 (0x00000035a5000000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00000035ac000000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00000035a8c00000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00000035a8400000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00000035af800000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00000035b0c00000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00000035aec00000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00000035b0000000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00000035a8800000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00000035afc00000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000035b0400000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00000035a9000000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00000035a7c00000)

We're doing good, right?

If yes, I'm going to update the SCM, build again on Koji and then push for Bodhi updates.

Thanks,

-Ilyes

One thing you may want to (but don't have to) fix in the upstream code is canonicalizing those /usr/bin/../lib64/code-editor rpaths. But I guess that's the same in the original upstream Qt Creator.

code-editor-2.3.0-10.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/code-editor-2.3.0-10.fc15

code-editor-2.3.0-10.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/code-editor-2.3.0-10.fc16

code-editor-2.3.0-10.fc16 has been pushed to the Fedora 16 testing repository.

code-editor-2.3.0-10.fc16 has been pushed to the Fedora 16 stable repository.

code-editor-2.3.0-10.fc15 has been pushed to the Fedora 15 stable repository.