Bug 783825 - Review Request: suil - A lightweight C library for loading and wrapping LV2 plugin UIs
Review Request: suil - A lightweight C library for loading and wrapping LV2 p...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Orcan Ogetbil
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FedoraAudio 797418
  Show dependency treegraph
 
Reported: 2012-01-22 11:13 EST by Brendan Jones
Modified: 2012-05-26 03:28 EDT (History)
5 users (show)

See Also:
Fixed In Version: suil-0.4.4-8.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-11 06:27:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
oget.fedora: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)
#lv2 IRC discussion excerpt (1.63 KB, text/x-log)
2012-04-10 00:15 EDT, Brendan Jones
no flags Details

  None (edit)
Description Brendan Jones 2012-01-22 11:13:18 EST
Suil makes it possible to load a UI of any toolkit in a host using any other 
toolkit (assuming the toolkits are both supported by suil). Hosts do not need
to build against or link to foreign toolkit libraries to use UIs written with 
that toolkit (suil performs its magic at runtime using dynamically 
loaded modules).

SRPM: http://bsjones.fedorapeople.org/lv2/sord-0.4.4-1.fc16.src.rpm
SPEC: http://bsjones.fedorapeople.org/lv2/suil.spec

fedora16:~ $ rpmlint rpmbuild/RPMS/x86_64/suil*  rpmbuild/SPECS/lv2-other/suil.spec rpmbuild/SRPMS/suil-0.4.4-1.fc16.src.rpm 
suil.x86_64: W: spelling-error %description -l en_US toolkits -> toolkit, tool kits, tool-kits
suil.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
suil.src: W: spelling-error %description -l en_US toolkits -> toolkit, tool kits, tool-kits
suil.src: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
Comment 1 Volker Fröhlich 2012-01-22 17:40:15 EST
That is the wrong SRPM or something.
Comment 2 Arangamanikkannan Manickam 2012-01-22 19:59:15 EST
It seems like Brendan provided the SRPM file for sord instead of suil. As the title says it is suil, I believe the following links should be the appropriate ones.
SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-1.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec
Comment 3 Brendan Jones 2012-01-23 02:15:13 EST
Apologies, thanks.
Comment 4 Volker Fröhlich 2012-01-23 13:59:34 EST
Using the current F16 RPMs from Koji:

Suil Configuration 
Checking for header lv2/lv2plug.in/ns/extensions/ui/ui.h : not found 
The configuration failed
Comment 5 Brendan Jones 2012-01-23 15:52:58 EST
I'm not sure what dependencies you've installed, but this is currently building in rawhide (I believe lv2core-6.0-2 could be the problem)

http://koji.fedoraproject.org/koji/taskinfo?taskID=3726522

lv2core will be updated in f16 shortly
Comment 6 Volker Fröhlich 2012-01-23 16:01:00 EST
lv2-ui-2.4-4.fc16.x86_64
lv2-ui-devel-2.4-4.fc16.x86_64
lv2core-4.0-3.fc16.x86_64
lv2core-devel-4.0-3.fc16.x86_64
Comment 7 Brendan Jones 2012-01-25 17:20:33 EST
Thanks - added BR lv2core-devel >= 6.0


SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-2.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec
Comment 8 Michael Schwendt 2012-02-06 07:39:46 EST
> %files devel
> %{_libdir}/lib%{name}*.so
> %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so
> %{_libdir}/pkgconfig/%{name}*.pc
> %{_includedir}/%{name}*/
> ...

Please review  http://fedoraproject.org/wiki/Packaging:UnownedDirectories  as there are several unowned directories in this %files list.

> %files devel
> ...
> %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so

Highly dubious to put these into the -devel package. Please prove that these are not dynamically loaded plugins/modules.
Comment 9 Brendan Jones 2012-02-06 08:09:45 EST
(In reply to comment #8)
> > %files devel
> > %{_libdir}/lib%{name}*.so
> > %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> > %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so
> > %{_libdir}/pkgconfig/%{name}*.pc
> > %{_includedir}/%{name}*/
> > ...
> 
> Please review  http://fedoraproject.org/wiki/Packaging:UnownedDirectories  as
> there are several unowned directories in this %files list.
> 
> > %files devel
> > ...
> > %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> > %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so
> 
> Highly dubious to put these into the -devel package. Please prove that these
> are not dynamically loaded plugins/modules.
Quite right, they're the point of the package after all :)

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-3.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec
Comment 10 Volker Fröhlich 2012-02-21 17:03:23 EST
Please remove the version constraints for qt-devel and gtk2-devel. qt-devel will always be newer than 4.0; analogue gtk2.

The author expresses a few specific wishes in PACKAGING. What do you think about them? Do they make sense for Fedora?

Especially having sub-packages for the different toolkits sounds appealing to me. Why would you drag in Qt or GTK if you don't need it? But as far as I can see, both libraries are linked to both toolkits at the moment.

The wish for major version in package names makes sense, given the name of the .so and when I look at where the header file goes:

/usr/include/suil-0/suil/suil.h

Please make {_mandir}/man3/%{name}.3.gz {_mandir}/man3/%{name}.3* in case the compression method changes.

Parts of the build don't use the optflags.

" * Debuggable build                                      : False"

... and rpmlint's ...

  suil-debuginfo.x86_64: E: debuginfo-without-sources

... indicate something is wrong.
Comment 11 Brendan Jones 2012-02-21 17:46:34 EST
(In reply to comment #10)
> Please remove the version constraints for qt-devel and gtk2-devel. qt-devel
> will always be newer than 4.0; analogue gtk2.

Fair enough.

> 
> The author expresses a few specific wishes in PACKAGING. What do you think
> about them? Do they make sense for Fedora?
> 
> Especially having sub-packages for the different toolkits sounds appealing to
> me. Why would you drag in Qt or GTK if you don't need it? But as far as I can
> see, both libraries are linked to both toolkits at the moment.

They are build requirements only. The whole point of the package is to enable linking plugins dynamically at runtime regardless of which toolkit they use. 

> 
> The wish for major version in package names makes sense, given the name of the
> .so and when I look at where the header file goes:
> 
> /usr/include/suil-0/suil/suil.h
> 
> Please make {_mandir}/man3/%{name}.3.gz {_mandir}/man3/%{name}.3* in case the
> compression method changes.

OK

> 
> Parts of the build don't use the optflags.
> 
> " * Debuggable build                                      : False"
> 
> ... and rpmlint's ...
> 
>   suil-debuginfo.x86_64: E: debuginfo-without-sources
> 
> ... indicate something is wrong.

OK, new SRPM imminent
Comment 12 Brendan Jones 2012-02-21 17:57:40 EST
(In reply to comment #10)
> The author expresses a few specific wishes in PACKAGING. What do you think
> about them? Do they make sense for Fedora?

You are quite right. Quoted from PACKAGING
"
The purpose of Suil is to abstract plugin UI toolkits away from host code.  To
achieve this, Suil performs its magic by dynamically loading modules for each
toolkit.  The main Suil library does NOT depend on any toolkit libraries, and
thus neither should your package.  Please package the individual modules
(e.g. libsuil_gtk2_in_qt4.so) as separate packages, which themselves depend on
the involved toolkits.  These packages should also be versioned as described
above to support parallel installation.
"

So, my question is should I provide suil-qt-devel and suil-gtk-devel subpackages from this?
Comment 13 Volker Fröhlich 2012-02-21 17:59:17 EST
I'm under the impression, something went wrong:

rpm -qp --requires suil-0.4.4-3.fc16.x86_64.rpm 
/sbin/ldconfig  
/sbin/ldconfig  
libQtCore.so.4()(64bit)  
libQtGui.so.4()(64bit)  
libatk-1.0.so.0()(64bit)  
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libcairo.so.2()(64bit)  
libdl.so.2()(64bit)  
libdl.so.2(GLIBC_2.2.5)(64bit)  
libfontconfig.so.1()(64bit)  
libfreetype.so.6()(64bit)  
libgcc_s.so.1()(64bit)  
libgcc_s.so.1(GCC_3.0)(64bit)  
libgdk-x11-2.0.so.0()(64bit)  
libgdk_pixbuf-2.0.so.0()(64bit)  
libgio-2.0.so.0()(64bit)  
libglib-2.0.so.0()(64bit)  
libgmodule-2.0.so.0()(64bit)  
libgobject-2.0.so.0()(64bit)  
libgthread-2.0.so.0()(64bit)  
libgtk-x11-2.0.so.0()(64bit)  
libm.so.6()(64bit)  
libpango-1.0.so.0()(64bit)  
libpangocairo-1.0.so.0()(64bit)  
libpangoft2-1.0.so.0()(64bit)  
libpthread.so.0()(64bit)  
librt.so.1()(64bit)  
libstdc++.so.6()(64bit)  
libstdc++.so.6(CXXABI_1.3)(64bit)  
libstdc++.so.6(GLIBCXX_3.4)(64bit)  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1


[ 9/11] cxxshlib: build/src/gtk2_in_qt4.cpp.2.o -> build/libsuil_gtk2_in_qt4.so
23:57:11 runner ['/usr/lib64/ccache/g++', 'src/gtk2_in_qt4.cpp.2.o', '-o', '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_gtk2_in_qt4.so', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0', '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0', '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore', '-shared', '-pthread', '-pthread', '-pthread', '-pthread']
[10/11] cxxshlib: build/src/qt4_in_gtk2.cpp.3.o -> build/libsuil_qt4_in_gtk2.so
23:57:11 runner ['/usr/lib64/ccache/g++', 'src/qt4_in_gtk2.cpp.3.o', '-o', '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_qt4_in_gtk2.so', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0', '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0', '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore', '-shared', '-pthread', '-pthread', '-pthread', '-pthread']
Comment 14 Volker Fröhlich 2012-02-21 18:01:13 EST
One devel package should be fine. What would you put in a second devel package?
Comment 15 Brendan Jones 2012-02-21 18:13:05 EST
Apologies (long day here), I need to create two binary packages (one for each .so) ?
Comment 16 Volker Fröhlich 2012-02-21 18:19:45 EST
No problem!

Yes. Create a suil-gtk and a suil-qt. Both require suil. Common files go to suil.
Comment 17 Brendan Jones 2012-02-22 13:50:36 EST
I can split the packages as you suggest but both binaries still link both toolkits as you've shown. What do you suggest here?

(In reply to comment #13)
> [ 9/11] cxxshlib: build/src/gtk2_in_qt4.cpp.2.o -> build/libsuil_gtk2_in_qt4.so
> 23:57:11 runner ['/usr/lib64/ccache/g++', 'src/gtk2_in_qt4.cpp.2.o', '-o',
> '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_gtk2_in_qt4.so',
> '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0',
> '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0',
> '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0',
> '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore',
> '-shared', '-pthread', '-pthread', '-pthread', '-pthread']
> [10/11] cxxshlib: build/src/qt4_in_gtk2.cpp.3.o -> build/libsuil_qt4_in_gtk2.so
> 23:57:11 runner ['/usr/lib64/ccache/g++', 'src/qt4_in_gtk2.cpp.3.o', '-o',
> '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_qt4_in_gtk2.so',
> '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0',
> '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0',
> '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0',
> '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore',
> '-shared', '-pthread', '-pthread', '-pthread', '-pthread']
Comment 18 Brendan Jones 2012-02-25 13:02:14 EST
OK, I think we can ignore the last comment. I have rebuilt qtractor with suil and it seems to link as expected with the split packages.

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-4.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec
Comment 19 Volker Fröhlich 2012-02-26 13:02:54 EST
While the gtk sub-package seems fine from a dependency point of view, the qt sub-package still requires libgtk-x11-2.0.so.0, which is provided by gtk2. Installing the qt sub-package would therefore drag in gtk, which is not desireable.

I recommend to write %{name}.3* instead of %{name}.3.gz, as the type of compression could change in the future.

You're not using the name macro consistently.

The first couple of files are still not compiled with optflags.
Comment 20 Brendan Jones 2012-02-28 07:49:30 EST
OK, updated the man, macros and optflags (good catch).

Can't do anything about about the gtk dependencies in the qt lib - have a look at the source. 

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-5.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec
Comment 21 Volker Fröhlich 2012-03-05 17:55:54 EST
Link is dead.
Comment 23 Volker Fröhlich 2012-03-27 15:30:27 EDT
You're right and this claim is not precise:

"Suil currently supports Gtk 2 and Qt 4, i.e. with Suil a Gtk program can embed a Qt plugin UI without depending on Qt, and a Qt program can embed a Gtk plugin UI without depending on Gtk." -- http://drobilla.net/software/suil/

Your description explains it better, in my opinion.
Comment 24 Orcan Ogetbil 2012-03-29 22:11:43 EDT
My comments:
* The license tag should be MIT:
   https://fedoraproject.org/wiki/Licensing/MIT#Old_Style_with_legal_disclaimer_2

* The description of the gtk subpackage is the same as the qt package. Copy/paste error?
At this point I want to question the rationale of splitting the package into subpackages. Why do we need this? If we really need this please make the descriptions more descriptive, as
   "This package contains the Qt library for %{name}."
is ambiguous for such a package.

! I need to make a note that in Fedora the Qt4 packages usually use
   BuildRequires:  qt4-devel

- The rpmlints
   suil-gtk.x86_64: W: no-documentation
   suil-qt.x86_64: W: no-documentation
   suil.x86_64: W: spelling-error %description -l en_US toolkits -> toolkit, tool kits, tool-kits
   suil.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
can be ignored
Comment 25 Brendan Jones 2012-03-29 23:39:04 EDT
(In reply to comment #24)
> My comments:
> * The license tag should be MIT:
>   
> https://fedoraproject.org/wiki/Licensing/MIT#Old_Style_with_legal_disclaimer_2

OK as the ISC license is an MIT derivative and is word for word the same as your link I will change the license (https://www.isc.org/software/license)
Both are good licenses, this package will report ISC when using licensecheck however.

> 
> * The description of the gtk subpackage is the same as the qt package.
> Copy/paste error?
> At this point I want to question the rationale of splitting the package into
> subpackages. Why do we need this? If we really need this please make the
> descriptions more descriptive, as
>    "This package contains the Qt library for %{name}."
> is ambiguous for such a package.

I'm happy to question this again. If I have this correctly, any host which is build against suil will require both libraries. It won't know at runtime what toolkits a plugin may use until its asked to instantiate it, and the way the package is split at the moment we run the risk of a missing a runtime  dependency. The only advantage I see at the moment is that it would be possible to have a Qt host that only loads Qt plugins but I think that's inviting trouble without having any Gtk libraries (in which case the user decides which suil library they have to install manually - yeuch).
Is that your take? I think we should probably move them back into the main package

> 
> ! I need to make a note that in Fedora the Qt4 packages usually use
>    BuildRequires:  qt4-devel
> 
> - The rpmlints
>    suil-gtk.x86_64: W: no-documentation
>    suil-qt.x86_64: W: no-documentation
>    suil.x86_64: W: spelling-error %description -l en_US toolkits -> toolkit,
> tool kits, tool-kits
>    suil.x86_64: W: spelling-error %description -l en_US runtime -> run time,
> run-time, rudiment
> can be ignored
Comment 26 Brendan Jones 2012-04-07 00:24:13 EDT
OK, I've merged the two sub-packages back into the main package and manually removed Gtk and Qt requires from the suil package. These libraries should be required by the plugin and need not be pulled in here.

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-6.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec
Comment 27 Orcan Ogetbil 2012-04-09 00:46:31 EDT
Hi Brendan, thanks for the update. Yes I would go with putting everything in one package, but...

(In reply to comment #26)
> OK, I've merged the two sub-packages back into the main package and manually
> removed Gtk and Qt requires from the suil package. These libraries should be
> required by the plugin and need not be pulled in here.

I am not sure that I follow you here. From my understanding, any plugin that uses suil will need both gtk and Qt libraries installed, since the plugin will convert a gtk ui to Qt, or vice versa.

What is the difference between this situation, and a library package X requiring another binary package Y? We don't typically filter out the Y requirement from the library X and expect the application Z to require both X and Y.
Comment 28 Orcan Ogetbil 2012-04-09 00:48:23 EDT
Sorry, it should be s/binary/library/ in the previous comment.
Comment 29 Brendan Jones 2012-04-09 04:06:18 EDT
Hi Orcan,

I have discussed this with Dave Robillard and some of the other Fedora devs and after a lengthy discussion this was considered the best way to satisfy the intentions/purpose of the library.

The suil package was designed not to depend on either toolkit. So if we have a Qt host and a Gtk plugin, then the Qt dependencies are provided by the host and the Gtk dependencies are provided by the plugin. The host cannot know at runtime what toolkit it maybe required to use to instantiate a plugin and shouldn't be expected to require both.

The filtered requires ensures that only the toolkit of the host is pulled in.  This may be advantageous where it is not desirable to pull in libraries unnecessarily.
Comment 30 Orcan Ogetbil 2012-04-09 23:31:09 EDT
Thanks for the explanation. Do you have any links for the discussions?

Please correct me if I am wrong: If gtk and Qt are the only supported toolkits by suil, then the plugin will drag in the Qt and the host will drag in gtk, or vice versa. Since both gtk and Qt will be dragged in in either case, it does not matter if the toolkit dependencies of suil are filtered out or not. However the story changes if suil supports more than these 2 toolkits (which is not the case for the time being). 

On the other hand, my biggest concern was not the above scenario exactly. It is not uncommon that Qt updates come  with ABI incompatibility. In such circumstances, the Fedora-KDE SIG works well-coordinated to rebuild all Qt dependant packages. If you filter out the Qt dependency from suil, they will not know about the existence of it. The suil maintainer (that will be you until you give it up) will need to follow all the ABI related changes in the underlying toolkit Qt and has to coordinate manually with the Qt updates at all times.
A similar argument applies for gtk rebuilds (although admittedly I don't have much experinence with gtk), or any other toolkit that will be supported by suil in the future. 

Are you sure do you want to walk that road? Shall we ask this in the Fedora-packaging list perhaps? What is so bad about dragging in the toolkits (seriously)?
Comment 31 Brendan Jones 2012-04-10 00:14:49 EDT



(In reply to comment #30)
> On the other hand, my biggest concern was not the above scenario exactly. It is
> not uncommon that Qt updates come  with ABI incompatibility. In such
> circumstances, the Fedora-KDE SIG works well-coordinated to rebuild all Qt
> dependant packages. If you filter out the Qt dependency from suil, they will
> not know about the existence of it. The suil maintainer (that will be you until
> you give it up) will need to follow all the ABI related changes in the
> underlying toolkit Qt and has to coordinate manually with the Qt updates at all
> times.
> A similar argument applies for gtk rebuilds (although admittedly I don't have
> much experinence with gtk), or any other toolkit that will be supported by suil
> in the future.

Sure, understand that this is a real concern.
 
> 
> Are you sure do you want to walk that road? Shall we ask this in the
> Fedora-packaging list perhaps? What is so bad about dragging in the toolkits
> (seriously)?

Attached (part of) a discussion on IRC with #lv2. 

Sure, I understand what you are saying. Whilst both toolkits are *likely* to be present anyway I can also envision a scenario whereby this may not be the case (e.g. a remix on an embedded device)

I could package without the requires, make a note of it in the spec file and revisit again if presented with a requirement to remove the unnecessary dependencies. Although it does irk me to go against upstream's recommendations
Comment 32 Brendan Jones 2012-04-10 00:15:53 EDT
Created attachment 576375 [details]
#lv2 IRC discussion excerpt
Comment 33 Brendan Jones 2012-04-13 09:37:32 EDT
I raised this on the packaging list as asked. Comments from Toshio only at this stage, confirming my approach.

http://lists.fedoraproject.org/pipermail/packaging/2012-April/008276.html
Comment 34 Orcan Ogetbil 2012-04-15 22:52:05 EDT
Alright then, we do not have any other issues, thus we can approve the package.

But please consider the versioned BR suggestion of Toshio, also please make a note in the specfile for tracking the changes in the underlying toolkits.

---------------------------------------
This package (suil) is APPROVED by oget
---------------------------------------
Comment 35 Brendan Jones 2012-04-16 15:29:06 EDT
Thanks for the review Orcan. Will do.

New Package SCM Request
=======================
Package Name: suil
Short Description: A lightweight C library for instantiating LV2 plugin UIs 
Owners: bsjones
Branches: f15 f16 f17
InitialCC:
Comment 36 Jon Ciesla 2012-04-16 15:40:21 EDT
Git done (by process-git-requests).
Comment 37 Fedora Update System 2012-05-02 06:17:34 EDT
suil-0.4.4-8.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/suil-0.4.4-8.fc16
Comment 38 Fedora Update System 2012-05-02 06:18:10 EDT
suil-0.4.4-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/suil-0.4.4-8.fc17
Comment 39 Fedora Update System 2012-05-02 16:31:11 EDT
suil-0.4.4-8.fc17 has been pushed to the Fedora 17 testing repository.
Comment 40 Fedora Update System 2012-05-11 06:27:26 EDT
suil-0.4.4-8.fc16 has been pushed to the Fedora 16 stable repository.
Comment 41 Fedora Update System 2012-05-26 03:28:55 EDT
suil-0.4.4-8.fc17 has been pushed to the Fedora 17 stable repository.

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