Thread: [Barry-devel] RPM spec file patch
Status: Beta
Brought to you by:
ndprojects
From: Chris F. <cd...@fo...> - 2007-03-02 23:01:34
|
Hi Troy, Thanks very much for your RPM spec file patch. I'm impressed that root is not needed, according to your patch notes. You seem to have a good handle on the RPM side of things. Would you be willing to create the RPM spec files for the full Barry release? This is something I'd really like to get underway, but if you would like to tackle it, it would free me up to work on the OpenSync module. Here's what is needed from a package layout point of view: libbarry Contains the runtime libraries libbarry-devel Contains the headers and example code libbarry-doc Possibly the doxygen documentation barry-util Contains the tools/ programs barry-backup Contains the backup GUI barry-opensync Contains the opensync module, when ready Currently "barry-bcharge" is outside this, and is great for those who just need charging capability. We could keep this a separate package, or include it in barry-util. Thanks again for your spec file patch, - Chris |
From: troy e. <te...@so...> - 2007-03-02 23:58:24
|
On 3/2/07, Chris Frey <cd...@fo...> wrote: > > You seem to have a good handle on the RPM side of things. Would you be Surely -- when I get time I'll cook it up and submit, it will of course be a bit more difficult since I'll be playing with the real Makefiles, but nothing too bad. I've made a few hundred over the years. ;) I'll try and whip it up this weekend. -te -- some live, some die in the way of the samurai |
From: Chris F. <cd...@fo...> - 2007-03-03 00:03:11
|
On Fri, Mar 02, 2007 at 03:58:20PM -0800, troy engel wrote: > Surely -- when I get time I'll cook it up and submit, it will of > course be a bit more difficult since I'll be playing with the real > Makefiles, but nothing too bad. I've made a few hundred over the > years. ;) I'll try and whip it up this weekend. Sounds great, thanks! - Chris |
From: <ch...@th...> - 2007-03-03 17:26:44
|
SSB3YW50IHRvIHRoYW5rIGV2ZXJ5b25lIGZvciBhbGwgdGhlIHdvcmsgYmVpbmcgZG9uZSB0byBz dXBwb3J0IHRoZSBwZWFybC4gSSBob3BlIHRvIGNvbnRyaWJ1dGUgc29tZSBkb2N1bWVudGF0aW9u IHRvIHRoaXMgYW5kIHRoZSBvcGVuc3luYyBwcm9qZWN0IHNvb24uDQoNCktlZXAgdXAgdGhlIGV4 Y2VsbGVudCB3b3JrISENClNlbnQgdmlhIEJsYWNrQmVycnkgZnJvbSBULU1vYmlsZSAgDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpcyBGcmV5IDxjZGZyZXlAZm91cnNx dWFyZS5uZXQ+DQpEYXRlOiBGcmksIDIgTWFyIDIwMDcgMTk6MDI6NDYgDQpUbzpCYXJyeSBwcm9q ZWN0IGRldmVsb3BtZW50IGRpc2N1c3Npb24gPGJhcnJ5LWRldmVsQGxpc3RzLnNvdXJjZWZvcmdl Lm5ldD4NClN1YmplY3Q6IFJlOiBbQmFycnktZGV2ZWxdIFJQTSBzcGVjIGZpbGUgcGF0Y2gNCg0K T24gRnJpLCBNYXIgMDIsIDIwMDcgYXQgMDM6NTg6MjBQTSAtMDgwMCwgdHJveSBlbmdlbCB3cm90 ZToNCj4gU3VyZWx5IC0tIHdoZW4gSSBnZXQgdGltZSBJJ2xsIGNvb2sgaXQgdXAgYW5kIHN1Ym1p dCwgaXQgd2lsbCBvZg0KPiBjb3Vyc2UgYmUgYSBiaXQgbW9yZSBkaWZmaWN1bHQgc2luY2UgSSds bCBiZSBwbGF5aW5nIHdpdGggdGhlIHJlYWwNCj4gTWFrZWZpbGVzLCBidXQgbm90aGluZyB0b28g YmFkLiBJJ3ZlIG1hZGUgYSBmZXcgaHVuZHJlZCBvdmVyIHRoZQ0KPiB5ZWFycy4gOykgSSdsbCB0 cnkgYW5kIHdoaXAgaXQgdXAgdGhpcyB3ZWVrZW5kLg0KDQpTb3VuZHMgZ3JlYXQsIHRoYW5rcyEN Ci0gQ2hyaXMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUYWtlIFN1cnZleXMuIEVhcm4gQ2FzaC4g SW5mbHVlbmNlIHRoZSBGdXR1cmUgb2YgSVQNCkpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNh eSBwYW5lbCBhbmQgeW91J2xsIGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXINCm9waW5pb25z IG9uIElUICYgYnVzaW5lc3MgdG9waWNzIHRocm91Z2ggYnJpZWYgc3VydmV5cy1hbmQgZWFybiBj YXNoDQpodHRwOi8vd3d3LnRlY2hzYXkuY29tL2RlZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1z b3VyY2Vmb3JnZSZDSUQ9REVWREVWDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KQmFycnktZGV2ZWwgbWFpbGluZyBsaXN0DQpCYXJyeS1kZXZlbEBsaXN0 cy5zb3VyY2Vmb3JnZS5uZXQNCmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xp c3RpbmZvL2JhcnJ5LWRldmVsDQoNCg== |
From: troy e. <te...@so...> - 2007-03-03 20:49:35
|
On 3/2/07, Chris Frey <cd...@fo...> wrote: > On Fri, Mar 02, 2007 at 03:58:20PM -0800, troy engel wrote: > > Surely -- when I get time I'll cook it up and submit, it will of > > Sounds great, thanks! (long winded here, sorry) OK I played around last night and took some notes; the short comment here is that "btool/bcharge et. al are a no brainer, gui/ creates some options how to do it". So I'd like to get some feedback on which way you want to go before wasting time. All code is 'DESTDIR' install friendly which makes it great for us RPM/DEB people. Basically out of my notes it works like this: tools/ is just a generic compile that requires libusb(-devel) and g++, alone and by itself run from the top level ./configure it'll install cleanly and I could package that alone in minutes. (NOTE: udev/ and hotplug/ aren't installed by make install, is it supposed to be that way?) Now comes gui/ - in order to compile it realtime without libbarry installed you have to do a little voodoo with gui/configure, like so: cd gui/ export PKG_CONFIG_PATH=../; export CXXFLAGS=-I../..; export LDFLAGS=-L../../src; ./configure (option option option option, tons of --options) This allows the subconfigure to find all the parts that were previously built for tools/; I can then do a normal make/make install without problems. The compile of this, however, requires a litany of dependencies; lemme just paste my "yum install" output for various pieces I had to go get: ==snip== yum install gtkmm24-devel: Installing: gtkmm24-devel Installing for dependencies: cairomm cairomm-devel glibmm24 glibmm24-devel gtkmm24 libsigc++20 libsigc++20-devel perl-XML-Parser perl-libwww-perl yum install libglademm24-devel: Installing: libglademm24-devel Installing for dependencies: libglademm24 yum install libtar-devel: Installing: libtar-devel ==snip== (NOTE: libtar-devel was not checked for during ./configure, I had to compile-and-fail to discover that it was needed. bug? If so I'll report.) OK that's the picture; the question is now how should we approach it? There are several options, each with it's pluses and minuses: A) Create one SPEC file to rule them all. The spec file would require optional parameters passed into it like so: 'rpmbuild -ba barry.spec --with gui --with opensync' Internally the spec file would then dynamically adjust it's BuildRequires: and Requires: lines and so forth to tighten up the needs on the fly. Positive: one file to maintain, one command builds everything as desired Negative: you have to "know" to pass in --with gui, etc. Not n00b friendly. B) Create separate SPEC files for each piece, since there are actually 3 different, separate, unique ./configures within the barry tarball. barry.spec, barry-gui.spec, and barry-opensync.spec. gui and opensync would require libbarry-devel.rpm installed, etc. Positive: able to release separate compiles of sub-pieces, can have different maintainers, distributions, etc. Negative: three files to maintain (which might be a positive), have to compile pieces separately, etc. C) Break apart the original barry tarball, and not distribute gui/ and opensync/ as part of the main ball of joy. barry-tools.tar.gz, barry-gui.tar.gz, barry-opensync.tar.gz. Positive: distro maintainers can more easily maintain and patch (do a "yum list libopensync* for example to see other opensync plugins). Code could be easier to add unique developers to (i.e. only opensync coders). Compile problems could be addressed uniquely. Negative: more work for barry project to maintain and release. Possibly introduce out-of-sync problems (but not likely). D) Rework the top level ./configure to integrate the subprojects, one SPEC file and one ./configure. This doesn't much change from (A) above, but is cleaner all around. All positive/negative are pretty much the same. E) Go drink beers and watch hockey. Personally I'm a fan of (E) being the choice made, but I'm sure the Barry project won't go for it. :) Or maybe they will! Let's fly to Waterloo/Mississauga and take RIM out (or let them take us out, heelllooo). Seriously, I'd love some input. -te PS: gmail caught that I misspelled Mississauga. tight. :) -- some live, some die in the way of the samurai |
From: Chris F. <cd...@fo...> - 2007-03-03 23:20:46
|
On Sat, Mar 03, 2007 at 12:49:35PM -0800, troy engel wrote: > OK I played around last night and took some notes; the short comment > here is that "btool/bcharge et. al are a no brainer, gui/ creates some > options how to do it". So I'd like to get some feedback on which way > you want to go before wasting time. All code is 'DESTDIR' install > friendly which makes it great for us RPM/DEB people. Thanks for spending time on this! > Basically out of my notes it works like this: tools/ is just a generic > compile that requires libusb(-devel) and g++, alone and by itself run > from the top level ./configure it'll install cleanly and I could > package that alone in minutes. (NOTE: udev/ and hotplug/ aren't > installed by make install, is it supposed to be that way?) Yes... so far, hotplug and udev have been somewhat system specific sometimes, at least between Fedora/Debian/Ubuntu, that I've seen. I don't really care to put system specific stuff in the makefiles when, in my opinion, this stuff probably belongs in the binary packages anyway. They are there as guides for the binary maintainers and source tarball users. > Now comes gui/ - in order to compile it realtime without libbarry > installed you have to do a little voodoo with gui/configure, like so: > > cd gui/ > export PKG_CONFIG_PATH=../; export CXXFLAGS=-I../..; export > LDFLAGS=-L../../src; > ./configure (option option option option, tons of --options) > > This allows the subconfigure to find all the parts that were > previously built for tools/; I can then do a normal make/make install > without problems. I'm surprised you need CXXFLAGS, etc. Does this add to the existing compile flags or replace them? For the GUI it shouldn't matter, but when compiling the library, it is important that -fno-strict-aliasing is set. Of course, I usually do a make install on the library, then set PKG_CONFIG_PATH to the installed lib directory. This tends to make binaries that are hard linked to that path (libtool uses -rpath), so that may not be desireable for a binary package. > The compile of this, however, requires a litany of > dependencies; lemme just paste my "yum install" output for various > pieces I had to go get: > > ==snip== > yum install gtkmm24-devel: > Installing: > gtkmm24-devel > Installing for dependencies: > cairomm > cairomm-devel > glibmm24 > glibmm24-devel > gtkmm24 > libsigc++20 > libsigc++20-devel > perl-XML-Parser > perl-libwww-perl > > yum install libglademm24-devel: > Installing: > libglademm24-devel > Installing for dependencies: > libglademm24 > > yum install libtar-devel: > Installing: > libtar-devel > ==snip== Yep, the GUI has a fair number of dependencies. :-) The main dependencies are listed in the GUI README, and those dependencies themselves (gtkmm, glibmm, etc) have fairly large subdependencies. I don't expect you'll need to depend on all of the above in your binary packages. As long as the main ones are met (see README), yum or apt-get should be able to figure out the rest. > (NOTE: libtar-devel was not checked for during ./configure, I had to > compile-and-fail to discover that it was needed. bug? If so I'll > report.) libtar doesn't have pkg-config support on some of the systems I've put it on (Debian stable for instance), so this check would need special configure.ac logic. Currently this is only specified via command line, and it tries to guess by default. Patches are welcome of course. :-) > OK that's the picture; the question is now how should we approach it? > There are several options, each with it's pluses and minuses: > > A) Create one SPEC file to rule them all. The spec file would require > optional parameters passed into it like so: 'rpmbuild -ba barry.spec > --with gui --with opensync' Internally the spec file would then > dynamically adjust it's BuildRequires: and Requires: lines and so > forth to tighten up the needs on the fly. > > Positive: one file to maintain, one command builds everything as desired > Negative: you have to "know" to pass in --with gui, etc. Not n00b friendly. I like this option merely for the fact that when updating things, it will be harder to forget things if it's all in one place. I'm not wedded to it though, and can see the advantage of separate spec files, especially for clarity. I'm quite open to adding a script in the rpm/ directory that shows how to build things with the proper rpmbuild command line, if that helps. > B) Create separate SPEC files for each piece, since there are actually > 3 different, separate, unique ./configures within the barry tarball. > barry.spec, barry-gui.spec, and barry-opensync.spec. gui and opensync > would require libbarry-devel.rpm installed, etc. > > Positive: able to release separate compiles of sub-pieces, can have > different maintainers, distributions, etc. > Negative: three files to maintain (which might be a positive), have > to compile pieces separately, etc. This is fine too. > C) Break apart the original barry tarball, and not distribute gui/ and > opensync/ as part of the main ball of joy. barry-tools.tar.gz, > barry-gui.tar.gz, barry-opensync.tar.gz. > > Positive: distro maintainers can more easily maintain and patch (do > a "yum list libopensync* for example to see other opensync plugins). > Code could be easier to add unique developers to (i.e. only opensync > coders). Compile problems could be addressed uniquely. > Negative: more work for barry project to maintain and release. > Possibly introduce out-of-sync problems (but not likely). I could see this sometime in the distant future, but I don't believe Barry is big enough to split up. Each subproject is a separate compile as well, so while you do get all the source in one tarball, there is nothing forcing users to compile it all, only what they need. For now, Barry will stay as a single source tarball. > D) Rework the top level ./configure to integrate the subprojects, one > SPEC file and one ./configure. This doesn't much change from (A) > above, but is cleaner all around. All positive/negative are pretty > much the same. I see great value in keeping them separate. I want it to be as easy as possible for people to get started with the base library and command line tools. If it is all one big project with a huge list of dependencies for the single compile, non-programmers, or even programmers with little time on their hands, will give up as soon as they hit a compile error. The Barry library, btool, and friends should Just Work (tm). The other items should be enticing enough to those interested to handle the extra compile, while not being a barrier for those who don't need it. > E) Go drink beers and watch hockey. Isn't that the afterparty? :-) - Chris |
From: troy e. <te...@so...> - 2007-03-04 21:47:18
|
(sent using wrong email address, trying a resend. sorry if I break your email client threading) On 3/3/07, Chris Frey <cd...@fo...> wrote: > > I don't really care to put system specific stuff in the makefiles > when, in my opinion, this stuff probably belongs in the binary packages > anyway. Fair enough, I'm taking care of it during packaging. > I'm surprised you need CXXFLAGS, etc. Does this add to the existing compile > flags or replace them? For the GUI it shouldn't matter, but when compiling > the library, it is important that -fno-strict-aliasing is set. It adds to them. Well, there are various methods to use but the way I do it is an additive approach. I am specifically seeing -fno-strict-aliasing during the builds. A hard -rpath ../ is not included, it just sorta all works out. > The main dependencies are listed in the GUI README, and those dependencies > themselves (gtkmm, glibmm, etc) have fairly large subdependencies. I'm with you -- I took a modularized approach so it should work out. It's at least not throwing errors so far, but I'm the design/build system. :) Of course I have all the right things installed now; we'll have to let a poor end-user QA for me. > libtar doesn't have pkg-config support on some of the systems I've put it > on (Debian stable for instance), so this check would need special configure.ac Fair enough, I just added it as a BuildRequires for -gui subpackage; I named it -gui to make it match other things -- like beagle, libbeagle and beagle-gui for instance. That way we can add more/newer gui apps later and the package name stays generic. Future-proof. > > A) Create one SPEC file to rule them all. The spec file would require > > I like this option merely for the fact that when updating things, it will > be harder to forget things if it's all in one place. I have gone this route; there can be only one, highlander. I've got a clean compile (step #1), the rest is to clean up (like add that hotplug, examine for missing docs, etc.) and test. I'll upload it to the Patches section when done. I backported a RPM macro from rpm-4.4 into the barry.spec so that this can compile (I hope!) on CentOS/Red Hat Enterprise 4 systems, which have rpm-4.3. Wrote: /usr/src/redhat/SRPMS/barry-0.6-1.src.rpm Wrote: /usr/src/redhat/RPMS/i386/barry-0.6-1.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/libbarry-0.6-1.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/libbarry-devel-0.6-1.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/barry-util-0.6-1.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/barry-gui-0.6-1.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/barry-debuginfo-0.6-1.i386.rpm 'barry-opensync' is in the SPEC (--with opensync), but because I can't get a good compile (and really, no ./configure yet) I'm not exercising it's usage. It's mainly a copy of -gui, not a whole lot can go wrong when we get there. All subpackages require 'barry', which contains nothing more than the GPL license, README, etc. - I figure it was a good way to compartmentalize the generic docs and not clutter every single package with them. This also ensures the user has to install the license and README. :) We can break out the doxygen/ later when it's ready into a barry-doc or whatever. $ rpm -qlp /usr/src/redhat/RPMS/i386/barry-0.6-1.i386.rpm /usr/share/doc/barry-0.6 /usr/share/doc/barry-0.6/AUTHORS /usr/share/doc/barry-0.6/COPYING /usr/share/doc/barry-0.6/ChangeLog /usr/share/doc/barry-0.6/Exceptions /usr/share/doc/barry-0.6/Hacking /usr/share/doc/barry-0.6/NEWS /usr/share/doc/barry-0.6/README /usr/share/doc/barry-0.6/ReleaseChecklist.txt /usr/share/doc/barry-0.6/TODO /usr/share/doc/barry-0.6/TimeZones.txt /usr/share/doc/barry-0.6/USB-capture.txt /usr/share/doc/barry-0.6/VersionNotes /usr/share/doc/barry-0.6/doxygen /usr/share/doc/barry-0.6/doxygen/.cvsignore /usr/share/doc/barry-0.6/doxygen/README -te -- some live, some die in the way of the samurai |
From: Chris F. <cd...@fo...> - 2007-03-09 00:09:46
|
On Sun, Mar 04, 2007 at 01:47:18PM -0800, troy engel wrote: > (sent using wrong email address, trying a resend. sorry if I break > your email client threading) It worked fine. First of all, Thanks! This is a great benefit, and should make version 0.7 the first release with binary RPM's included for Fedora 5 and 6. Comments below: > > I'm surprised you need CXXFLAGS, etc. Does this add to the existing compile > > flags or replace them? For the GUI it shouldn't matter, but when compiling > > the library, it is important that -fno-strict-aliasing is set. > > It adds to them. Well, there are various methods to use but the way I > do it is an additive approach. I am specifically seeing > -fno-strict-aliasing during the builds. A hard -rpath ../ is not > included, it just sorta all works out. Excellent, glad to hear it. > > The main dependencies are listed in the GUI README, and those dependencies > > themselves (gtkmm, glibmm, etc) have fairly large subdependencies. > > I'm with you -- I took a modularized approach so it should work out. > It's at least not throwing errors so far, but I'm the design/build > system. :) Of course I have all the right things installed now; we'll > have to let a poor end-user QA for me. It's working great here on Fedora 5... will test with 6 shortly. The idea is to put binary releases on the file download page, so hopefully only developers or people with different architectures will need to build the RPMs. > > libtar doesn't have pkg-config support on some of the systems I've put it > > on (Debian stable for instance), so this check would need special configure.ac > > Fair enough, I just added it as a BuildRequires for -gui subpackage; I > named it -gui to make it match other things -- like beagle, libbeagle > and beagle-gui for instance. That way we can add more/newer gui apps > later and the package name stays generic. Future-proof. Sounds good. I wasn't aware of the -gui convention, so I'll agree with that. > I have gone this route; there can be only one, highlander. > > I've got a clean compile (step #1), the rest is to clean up (like add > that hotplug, examine for missing docs, etc.) and test. I'll upload it > to the Patches section when done. I backported a RPM macro from > rpm-4.4 into the barry.spec so that this can compile (I hope!) on > CentOS/Red Hat Enterprise 4 systems, which have rpm-4.3. I've tested the build on a RHEL4 system just now, and rpm-4.3 chokes on the %if statements for some reason. I also had to tweak the autoconf scripts a bit to get it to compile, as it needs libusb explicitly given on the command line. Once that was done (the autoconf fixes are in CVS), I removed the gui and opensync parts of the spec file, and it built fine. So we just need a fix or workaround for the %if statements. > 'barry-opensync' is in the SPEC (--with opensync), but because I can't > get a good compile (and really, no ./configure yet) I'm not exercising > it's usage. It's mainly a copy of -gui, not a whole lot can go wrong > when we get there. Yes, opensync isn't ready yet. It's only half coded at this point. > All subpackages require 'barry', which contains nothing more than the > GPL license, README, etc. - I figure it was a good way to > compartmentalize the generic docs and not clutter every single package > with them. This also ensures the user has to install the license and > README. :) We can break out the doxygen/ later when it's ready into a > barry-doc or whatever. I didn't like the barry base package, as it seemed a bit wasteful to me, and we need the license in every package anyway. Since libbarry is really the common package that all the others depend on, I've moved the common documentation files there, and moved some of the more techy ones into libbarry-devel. I'll commit my changes into CVS soon, and if you have more comments, please let me know. Thanks again! - Chris |
From: troy e. <te...@so...> - 2007-03-09 00:58:51
|
On 3/8/07, Chris Frey <cd...@fo...> wrote: > > I've tested the build on a RHEL4 system just now, and rpm-4.3 chokes > on the %if statements for some reason. I also had to tweak the autoconf I have a CentOS4 system (server parts only) and see that it's even more dumb than I thought; a new patch is on the way, I made the initial macro definitions as lowly basic as possible, which makes it a lot more portable. Basically RHEL4 doesn't know an empty macro definition is '0', unlike newer systems. OK tests on my FC6 box and a CentOS4 box, all working for the basics. Patch #1676900 against CVS. > I didn't like the barry base package, as it seemed a bit wasteful to me, > and we need the license in every package anyway. Since libbarry is > really the common package that all the others depend on, I've moved > the common documentation files there, and moved some of the more techy > ones into libbarry-devel. Coolness - I was a bit on the "well what do I do?" front as well about that whole point, whatever is cleaner and works out. I thought having to install 'barry' to get 'libbarry' was lame myself... :) BTW: the second paragraph of %description -n libbarry now goes over the 80char boundry, you should hard wrap it after "You most" and yank up the following line. Makes the display of rpm -qi(p) pretty. -te -- some live, some die in the way of the samurai |
From: Chris F. <cd...@fo...> - 2007-03-09 01:20:26
|
On Thu, Mar 08, 2007 at 04:58:51PM -0800, troy engel wrote: > I have a CentOS4 system (server parts only) and see that it's even > more dumb than I thought; a new patch is on the way, I made the > initial macro definitions as lowly basic as possible, which makes it a > lot more portable. Basically RHEL4 doesn't know an empty macro > definition is '0', unlike newer systems. > > OK tests on my FC6 box and a CentOS4 box, all working for the basics. > Patch #1676900 against CVS. Thanks, applied! > BTW: the second paragraph of %description -n libbarry now goes over > the 80char boundry, you should hard wrap it after "You most" and yank > up the following line. Makes the display of rpm -qi(p) pretty. Fixed. - Chris |