[arch-multilib] lib32-gtk-engine-murrine
Hi, Sorry if this appears twice, I forgot to send it through my +arch address. I have recently become a Trusted User and would like to help out with multilib support. For starters, I have created a lib32 package for gtk-engine-murrine. The normal package is in community already, and a multilib version would be useful for flashplugin and skype (using QGtkStyle). Here is the PKGBUILD: # Maintainer: Jonathan Conder <jonno dot conder at gmail dot com> _pkgbasename=gtk-engine-murrine pkgname=lib32-$_pkgbasename pkgver=0.90.3 pkgrel=1 pkgdesc="GTK2 engine to make your desktop look like a 'murrina' (32-bit)" arch=('x86_64') url="http://cimitan.com/murrine/project/murrine" license=('GPL') depends=('lib32-gtk2' "$_pkgbasename") makedepends=('gcc-multilib' 'intltool' 'perl') options=('!libtool') source=("http://ftp.gnome.org/pub/GNOME/sources/murrine/0.90/murrine-$pkgver.tar.bz2") md5sums=('58a10b5c7b5e114a8a7ff5705fe274f5') build() { export CC='gcc -m32' export PKG_CONFIG_PATH='/usr/lib32/pkgconfig' cd "$srcdir/murrine-$pkgver" ./configure --prefix=/usr \ --libdir=/usr/lib32 \ --enable-animation make } package() { cd "$srcdir/murrine-$pkgver" make DESTDIR="$pkgdir/" install rm -rf "$pkgdir/usr/share" } I have tried to model it on other lib32 packages, but if I got something wrong please let me know. Running namcap reports 2 errors which I think are irrelevant: lib32-gtk-engine-murrine W: Dependency included and not needed ('gtk-engine-murrine') lib32-gtk-engine-murrine E: ELF file ('usr/lib32/gtk-2.0/2.10.0/engines/libmurrine.so') outside of a valid path. If this is all ok, I would like to have access to the multilib repository. Let me know if any extra information is required for this. Thanks, Jonathan
Am 03.09.2010 04:08, schrieb Jonathan Conder:
lib32-gtk-engine-murrine W: Dependency included and not needed ('gtk-engine-murrine') lib32-gtk-engine-murrine E: ELF file ('usr/lib32/gtk-2.0/2.10.0/engines/libmurrine.so') outside of a valid path.
One thing which we all forgot is to add /usr/lib32 to makepkg.conf's STRIP_DIRS - namcap doesn't show that. The dependency on the non-lib32 package is only needed if there are any the header or data files in it, so check that, too.
If this is all ok, I would like to have access to the multilib repository. Let me know if any extra information is required for this.
We need to agree on a policy for these theme engines. Do we want to add every single theme engine to multilib? Do we want to add any? And why? This is a topic that needs to be discussed before we start pushing lots of packages into multilib. As for access - I'd like to bring more people on board, not necessarily for adding new packages, but also for keeping the existing ones up to date.
On 03/09/10 19:50, Thomas Bächler wrote:
Am 03.09.2010 04:08, schrieb Jonathan Conder:
lib32-gtk-engine-murrine W: Dependency included and not needed ('gtk-engine-murrine') lib32-gtk-engine-murrine E: ELF file ('usr/lib32/gtk-2.0/2.10.0/engines/libmurrine.so') outside of a valid path.
One thing which we all forgot is to add /usr/lib32 to makepkg.conf's STRIP_DIRS - namcap doesn't show that.
The dependency on the non-lib32 package is only needed if there are any the header or data files in it, so check that, too.
Yeah, there is one data file, hence the rm command in package().
If this is all ok, I would like to have access to the multilib repository. Let me know if any extra information is required for this.
We need to agree on a policy for these theme engines. Do we want to add every single theme engine to multilib? Do we want to add any? And why? This is a topic that needs to be discussed before we start pushing lots of packages into multilib.
Personally I would like to have GUI consistency across all applications, regardless of architecture. It would also reduce warning messages from flash. There aren't that many GTK engines that I know of, and I think murrine is one of the most popular. On the other hand, 32-bit theme engines would have to be installed manually, and murrine for one doesn't update often, which might favour leaving it in the AUR. The current package still uses the old lib32 system, but I could update it if need be.
As for access - I'd like to bring more people on board, not necessarily for adding new packages, but also for keeping the existing ones up to date.
Ok, well I use wine, flash and skype (plus dependencies of course) so I wouldn't mind helping out with that either. Jonathan
participants (2)
-
Jonathan Conder
-
Thomas Bächler