Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Collaboratively creating a compiz-reloaded ebuild ?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Mon Apr 18, 2016 8:41 pm    Post subject: Reply with quote

kajzer wrote:

Yep, gtk3 flag isn't needed since it's defaulted if there's -gtk2, so I would suggest just leaving gtk2.
Also, pyrex dep isn't needed at all and xvinfo is needed for compiz-manager, but otherwise it's not.


Right. Well I'm going to try and figure out how to pull Myu's changes without completely screwing up my repo (it's not a competition, but despite it being unconventional, I like my builds in their own category... that just makes everything so much easier.) and I'll go ahead and fix those use flags.

After that I'll copy the changes over to the live ebuilds and then it ought to be in pretty good shape I think.
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Mon Apr 18, 2016 8:50 pm    Post subject: Reply with quote

Myu wrote:
Yeah it would be great to rebase all of this, there's useful changes on both repos here and there :)

You could use diff to see the differences and cherry-pick what you want to be on your ebuilds. It's not super efficient though

The thing is, I did some filesystem hierarchy changes which makes sharing code back and forth kinda broken, my idea was to get a portage-like hierarchy but yeah, it's not practical

In the end, I think I'll restart my repo from yours and merge the changes ( so you can add them as well if you wish ) and only then make another project for implementing a portage-like hierarchy.

But that's a story for another day since I'll need to sleep soon :)


Yeah it is becoming tedious... I do think you are doing it the correct way, but I like being able to eix -I compiz-reloaded/ --only-names | xargs emerge -C or whatever the case may be... not to mention easily for-looping through them all to rebuild manifests and such :)

That sounds good though, and I can certainly help with the final portage one if you want, but there's so many compiz versions in portage and overlays plus my 0.9 hacky local overlay ughhh... I'm gonna stick with compiz-reloaded/ just to keep my sanity lol.
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Mon Apr 18, 2016 9:39 pm    Post subject: Reply with quote

nasaiya wrote:
kajzer wrote:

Yep, gtk3 flag isn't needed since it's defaulted if there's -gtk2, so I would suggest just leaving gtk2.
Also, pyrex dep isn't needed at all and xvinfo is needed for compiz-manager, but otherwise it's not.


Right. Well I'm going to try and figure out how to pull Myu's changes without completely screwing up my repo (it's not a competition, but despite it being unconventional, I like my builds in their own category... that just makes everything so much easier.) and I'll go ahead and fix those use flags.

After that I'll copy the changes over to the live ebuilds and then it ought to be in pretty good shape I think.


Nice, I'll test new changes and I'll switch to live ebuild as soon as you make them available.

Anyway, spoke with developer over at irc, that problem I got with emerging that package with m4/glib-gettext.m4:39: error: m4_copy: won't overwrite defined macro: glib_DEFUN was caused by the latest glib
Quote:
<XRevan86> kajzer: glib-gettext problem is caused by the latest glib


Take a look at this and apply that macro instead of the old one, old one is deprecated.
https://git.gnome.org/browse/glib/commit/?id=6b57719

As for gtk3 and gtk2 he said this, so maybe you should take that into account :

Quote:
<XRevan86> kajzer: I would use the gtk2 USE flag everywhere but core
<XRevan86> and in compiz core I'd use gtk3
<XRevan86> USE flag
<XRevan86> To make it synced with Marco.
<kajzer> XRevan86: but I thought it's defaulted to gtk3 if you don't specify gtk2
<XRevan86> kajzer: Everywhere but core
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Mon Apr 18, 2016 10:30 pm    Post subject: Reply with quote

Thanks for all the info kajzer! I'll take that all into account.

Not sure how long it'll take me now since I actually had to go back to work :( but hopefully it'll be done soon!
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Mon Apr 18, 2016 10:40 pm    Post subject: Reply with quote

Your welcome, no rush at all, actually I might take a look into that myself, good chance to finally get involved with ebuilds :)
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Mon Apr 18, 2016 10:51 pm    Post subject: Reply with quote

kajzer wrote:
Your welcome, no rush at all, actually I might take a look into that myself, good chance to finally get involved with ebuilds :)


Feel like testing a patch? While admittedly I have no idea what all that m4 file crap does, I can change glib_DEFUN to AU_DEFUN and make a patch!

It compiled on mine... which thankfully means I don't have to figure out how to make it only patch for the newer glib... if it works that is...

Code:
--- m4/glib-gettext.m4.orig     2016-02-13 01:55:14.000000000 -0700
+++ m4/glib-gettext.m4  2016-04-18 16:35:33.933241366 -0600
@@ -45,7 +45,7 @@
 
 # GLIB_LC_MESSAGES
 #--------------------
-glib_DEFUN([GLIB_LC_MESSAGES],
+AU_DEFUN([GLIB_LC_MESSAGES],
   [AC_CHECK_HEADERS([locale.h])
     if test $ac_cv_header_locale_h = yes; then
     AC_CACHE_CHECK([for LC_MESSAGES], am_cv_val_LC_MESSAGES,
@@ -61,7 +61,7 @@
 #----------------------------
 dnl GLIB_PATH_PROG_WITH_TEST(VARIABLE, PROG-TO-CHECK-FOR,
 dnl   TEST-PERFORMED-ON-FOUND_PROGRAM [, VALUE-IF-NOT-FOUND [, PATH]])
-glib_DEFUN([GLIB_PATH_PROG_WITH_TEST],
+AU_DEFUN([GLIB_PATH_PROG_WITH_TEST],
 [# Extract the first word of "$2", so it can be a program name with args.
 set dummy $2; ac_word=[$]2
 AC_MSG_CHECKING([for $ac_word])
@@ -99,7 +99,7 @@
 
 # GLIB_WITH_NLS
 #-----------------
-glib_DEFUN([GLIB_WITH_NLS],
+AU_DEFUN([GLIB_WITH_NLS],
   dnl NLS is obligatory
   [USE_NLS=yes
     AC_SUBST(USE_NLS)
@@ -313,7 +313,7 @@
 # on various variables needed by the Makefile.in.in installed by
 # glib-gettextize.
 dnl
-glib_DEFUN([GLIB_GNU_GETTEXT],
+AU_DEFUN([GLIB_GNU_GETTEXT],
   [AC_REQUIRE([AC_PROG_CC])dnl
   
    GLIB_LC_MESSAGES
@@ -389,7 +389,7 @@
 # -------------------------------
 # Define VARIABLE to the location where catalog files will
 # be installed by po/Makefile.
-glib_DEFUN([GLIB_DEFINE_LOCALEDIR],
+AU_DEFUN([GLIB_DEFINE_LOCALEDIR],
 [glib_REQUIRE([GLIB_GNU_GETTEXT])dnl
 glib_save_prefix="$prefix"
 glib_save_exec_prefix="$exec_prefix"
 


You can stick that in compiz-plugins-experimental/files/compiz-plugins-experimental-0.8.12-fix-glib-getext-m4.patch and add:
Code:
    epatch "${FILESDIR}"/${P}-fix-glib-getext-m4.patch
to the src_prepare function of the ebuild... need to add eutils to the inherit line at the top too...

EDIT: Here is the changed ebuild to make it easy
Code:
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI="5"

inherit autotools eutils

DESCRIPTION="Compiz Fusion Window Decorator Experimental Plugins"
HOMEPAGE="https://github.com/compiz-reloaded"
SRC_URI="https://github.com/compiz-reloaded/compiz-plugins-experimental/releases/download/v${PV}/compiz-plugins-experimental-${PV}.tar.xz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="-*"
IUSE=""

RDEPEND="
   >=gnome-base/librsvg-2.14.0:2
   virtual/jpeg:0
   >=compiz-reloaded/compiz-bcop-0.8.12
   >=compiz-reloaded/compiz-plugins-main-0.8.12
   >=compiz-reloaded/compiz-0.8.12
"

DEPEND="${RDEPEND}
   >=dev-util/intltool-0.35
   virtual/pkgconfig
   >=sys-devel/gettext-0.15
   x11-libs/cairo
"

DOCS="AUTHORS INSTALL NEWS"

src_prepare(){
    epatch "${FILESDIR}"/${P}-fix-glib-getext-m4.patch
    eautoreconf
}

pkg_postinst() {
    elog "Do NOT report bugs about this package!"
    elog "This is a homebrewed ebuild and is not"
    elog "maintained by anyone. In fact, it might"
    elog "self-destruct at any moment... :)"
}


_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Mon Apr 18, 2016 11:13 pm    Post subject: Reply with quote

Actually deleting :

Code:

src_prepare(){
    eautoreconf
}


from that ebuild worked, I guess your patch would work too, it's simpler this way :)
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Mon Apr 18, 2016 11:21 pm    Post subject: Reply with quote

kajzer wrote:
Actually deleting :

Code:

src_prepare(){
    eautoreconf
}


from that ebuild worked, I guess your patch would work too, it's simpler this way :)


Well that's interesting... come to think of it I may have added that originally to get it to actually build... several of the original ebuilds would "install" as far as portage was concerned, but didn't actually compile the source or do anything at all for that matter. I guess that's what happens when you duct tape stuff together!

I guess I'll be needing to research eautoreconf and when/why/if it's necessary... EDIT: looking at the other ebuilds it definitely seems to be necessary when there's any patching done to configure.ac... I guess I'm just not really familiar with autoconf this sort of thing would probably be obvious to someone that is...
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Mon Apr 18, 2016 11:34 pm    Post subject: Reply with quote

Yeah, anyway I did try to test your patch and it didn't work, I guess versions do not match, I could probably figure out the proper lines in my case but there's really no need for that in this particular ebuild.

Here's the error log :

Code:

=======================================================================
checking file m4/glib-gettext.m4
Hunk #1 FAILED at 45.
Hunk #2 FAILED at 61.
Hunk #3 FAILED at 99.
Hunk #4 FAILED at 313.
Hunk #5 FAILED at 389.
5 out of 5 hunks FAILED

patch program exited with status 1
=======================================================================

PATCH COMMAND:  patch -p1 -g0 -E --no-backup-if-mismatch  --dry-run -f < '/usr/local/portage/compiz-reloaded/compiz-plugins-experimental/fi$

=======================================================================
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- m4/glib-gettext.m4.orig     2016-02-13 01:55:14.000000000 -0700
|+++ m4/glib-gettext.m4  2016-04-18 16:35:33.933241366 -0600
--------------------------
No file to patch.  Skipping patch.
5 out of 5 hunks ignored

patch program exited with status 1
=======================================================================

PATCH COMMAND:  patch -p2 -g0 -E --no-backup-if-mismatch  --dry-run -f < '/usr/local/portage/compiz-reloaded/compiz-plugins-experimental/fi$

=======================================================================
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- m4/glib-gettext.m4.orig     2016-02-13 01:55:14.000000000 -0700
|+++ m4/glib-gettext.m4  2016-04-18 16:35:33.933241366 -0600
--------------------------
No file to patch.  Skipping patch.
5 out of 5 hunks ignored

patch program exited with status 1
=======================================================================

PATCH COMMAND:  patch -p4 -g0 -E --no-backup-if-mismatch  --dry-run -f < '/usr/local/portage/compiz-reloaded/compiz-plugins-experimental/fi$

=======================================================================
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- m4/glib-gettext.m4.orig     2016-02-13 01:55:14.000000000 -0700
|+++ m4/glib-gettext.m4  2016-04-18 16:35:33.933241366 -0600
--------------------------
No file to patch.  Skipping patch.
5 out of 5 hunks ignored

patch program exited with status 1
=======================================================================

PATCH COMMAND:  patch -p4 -g0 -E --no-backup-if-mismatch  --dry-run -f < '/usr/local/portage/compiz-reloaded/compiz-plugins-experimental/fi$

=======================================================================
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- m4/glib-gettext.m4.orig     2016-02-13 01:55:14.000000000 -0700
|+++ m4/glib-gettext.m4  2016-04-18 16:35:33.933241366 -0600
--------------------------
No file to patch.  Skipping patch.
5 out of 5 hunks ignored

patch program exited with status 1


Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Mon Apr 18, 2016 11:43 pm    Post subject: Reply with quote

Oh well it was a shot in the dark anyway... why mess with things we don't need to mess with ;)

edit: looking more closely though it looks like you tried to patch the overlay? That patch needs to be applied to the source tarball... but still removing the autoreconfing is probably better.
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Mon Apr 18, 2016 11:53 pm    Post subject: Reply with quote

Yep you're right, I rushed through it, kinda multitasking here atm, but really there's no need to use eautoreconf for this ebuild.
I can try it a bit later again, in any case you can move from this issue to the next one without any worries ;)
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Tue Apr 19, 2016 1:52 pm    Post subject: Reply with quote

kajzer wrote:

As for gtk3 and gtk2 he said this, so maybe you should take that into account :

Quote:
<XRevan86> kajzer: I would use the gtk2 USE flag everywhere but core
<XRevan86> and in compiz core I'd use gtk3
<XRevan86> USE flag
<XRevan86> To make it synced with Marco.
<kajzer> XRevan86: but I thought it's defaulted to gtk3 if you don't specify gtk2
<XRevan86> kajzer: Everywhere but core


So here's a question for anyone following... I started on fixing up the gtk flags but haven't commited yet, will have to finish it up later today after work, however I'm wondering, is there any reason why anyone might not want to have gtk3 installed on their system?

It's easy enough to make compiz-core default to gtk3 or make a gtk2 use flag if people really want it, but having a gtk2 use flag would make people tend to use it especially people trying to achieve the same thing as kajzer with using gtk2 on the other packages... but if it just defaults to gtk3 with no use flag then you're stuck with gtk3 being required no matter what you choose for use flags.

I suppose the other option would be to make the gtk2 use flag just like the others, but if they want the marco theme support force gtk3...

Unless I misunderstood XRevan86 and he/she is saying leave it gtk2 and let people choose gtk3 if they want...

For me this doesn't matter... so the question is would it matter to anyone?
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Tue Apr 19, 2016 2:08 pm    Post subject: Reply with quote

Depends on the DE that you are using, I'm on Mate and there is no gtk3 support there yet, it's not a question of do I want it or not.
If there's a option to use it in compiz I don't see why that option would be excluded because USE flags aren't in the ebuilds.
Besides, your non-live ebuilds already include gtk2 and they work as it should, so I don't see exactly what's the problem.
For me it's not a problem to include what I need, but ultimately it's up to you.
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Tue Apr 19, 2016 2:18 pm    Post subject: Reply with quote

I'm just trying to figure out what a sensible default would be...

I'm off to work though!
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Apr 19, 2016 5:58 pm    Post subject: Reply with quote

nasaiya wrote:
..is there any reason why anyone might not want to have gtk3 installed on their system?
..
For me this doesn't matter... so the question is would it matter to anyone?

Absolutely; we have later versions of gtk-3 masked (and the USE flag off, ofc) to avoid pulling in gdbust, and to at least one professional sysadmin I know (who happens to be a Gentoo developer) "gtk3 is crazy."
Quote:
Unless I misunderstood XRevan86 and he/she is saying leave it gtk2 and let people choose gtk3 if they want...

That makes sense: if the user doesn't want gtk3, and there's no option but to use gtk2, build with that.
There's no other decision to be made, so don't overload IUSE.

Users tend to have newer flags turned off more usually than older, stable ones. Quite often they come in (hard-)masked for testing in any case.
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Tue Apr 19, 2016 6:19 pm    Post subject: Reply with quote

XRevan86 also said that compiz and emerald are using more memory when built with gtk3

Anyway, I would listen to him and make gtk2 default for everything but compiz-core (to make it synced with Marco).
Personally I don't care about Marco so I would turn gtk2 for compiz-core as well.
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Tue Apr 19, 2016 8:15 pm    Post subject: Reply with quote

Thanks steveL and kajzer, I think that settles it then...

I'll set it up with gtk2 default for everything (including core) with a gtk3 use flag in case they want it, but I'll make gtk3 mandatory on compiz core if they use marco since marco is optional and I already made a use flag for it and anyone that uses marco should be able to figure out they ought to enable the marco flag.
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Tue Apr 19, 2016 11:17 pm    Post subject: Reply with quote

Okay, after 5 effing power outages in 20 minutes, and having to repair the resulting completely ruined git repo, I think I've finally managed to get the changes uploaded.

I reworked all the gtk useflags as discussed, and updated the live ebuilds to match.
Presuming I didn't make a mistake somewhere due to the power outage/git disaster, it should all work!
EDIT: before that I merged Myu's fixes as well.

Kajzer, the eautoreconf does seem to be necessary in live ebuild or else there is no configure script to run, so its possible you might get that same glib-gettext error again... but since it was the upstream that told you how to fix it I expect they have fixed it themselves so hopefully you won't...

Edit: Oops, missed a few things in the meta package... that was the only one I didn't test :/ will have it fixed in a few minutes
Edit2: Okay that should do it :) sorry
_________________
If it ain't broke - fix it till it is!


Last edited by nasaiya on Tue Apr 19, 2016 11:42 pm; edited 3 times in total
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Tue Apr 19, 2016 11:18 pm    Post subject: Reply with quote

Just to throw one more anecdote in...

I've *tried* gtk3 in the past. It does not integrate well with software outside of a GNOME DE, and last I heard they were so trigger-happy/malicious with breaking changes it made oxygen-gtk's developer drop support out of frustration.

So I run my machines entirely without gtk3 and it hasn't significantly impaired my quality of life (save for gucharmap having outdated data, but that's patchable). GTK+2 is nearly impossible to avoid, so I don't even try.
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Tue Apr 19, 2016 11:41 pm    Post subject: Reply with quote

nasaiya wrote:
Kajzer, the eautoreconf does seem to be necessary in live ebuild or else there is no configure script to run, so its possible you might get that same glib-gettext error again... but since it was the upstream that told you how to fix it I expect they have fixed it themselves so hopefully you won't...

Edit: Oops, missed a few things in the meta package... that was the only one I didn't test :/ will have it fixed in a few minutes


Good job, I'll try the live ebuild this time, let me know when you make those final changes.
If there's glib error I'll fix it manually, but if I understood correctly there shouldn't be this error for the live version, I'll let you know about that too.

Edit : btw should I just replace the current ebuilds and update to live from already installed version or uninstall everything first then install it again ?
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Tue Apr 19, 2016 11:45 pm    Post subject: Reply with quote

kajzer wrote:
nasaiya wrote:
Kajzer, the eautoreconf does seem to be necessary in live ebuild or else there is no configure script to run, so its possible you might get that same glib-gettext error again... but since it was the upstream that told you how to fix it I expect they have fixed it themselves so hopefully you won't...

Edit: Oops, missed a few things in the meta package... that was the only one I didn't test :/ will have it fixed in a few minutes


Good job, I'll try the live ebuild this time, let me know when you make those final changes.
If there's glib error I'll fix it manually, but if I understood correctly there shouldn't be this error for the live version, I'll let you know about that too.


Yep should be good now... I don't think you'll get the error in the live version but anything is possible...

Quote:
Edit : btw should I just replace the current ebuilds and update to live from already installed version or uninstall everything first then install it again ?


Probably not a bad idea to uninstall first... that's what I did...
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Wed Apr 20, 2016 12:40 am    Post subject: Reply with quote

nasaiya wrote:
Probably not a bad idea to uninstall first... that's what I did...


That's what I did, all went well, no glib error with experimental plugins, as expected.
It's gtk2 so that worked as well, I see you removed gtk2 flag and now there's only gtk3 flag, that's a good move too :)
Don't know what else to say at this point.
Great job !
Back to top
View user's profile Send private message
nasaiya
Apprentice
Apprentice


Joined: 17 May 2007
Posts: 157

PostPosted: Wed Apr 20, 2016 12:45 am    Post subject: Reply with quote

kajzer wrote:
nasaiya wrote:
Probably not a bad idea to uninstall first... that's what I did...


That's what I did, all went well, no glib error with experimental plugins, as expected.
It's gtk2 so that worked as well, I see you removed gtk2 flag and now there's only gtk3 flag, that's a good move too :)
Don't know what else to say at this point.
Great job !


Awesome! Glad to hear it worked!

With Myu's help removing most of the outdated crap, I think the only major thing left to do is get it to build python 3 targets for the python packages... but I'm not sure I'm the right person to tackle that one...
_________________
If it ain't broke - fix it till it is!
Back to top
View user's profile Send private message
The Main Man
Veteran
Veteran


Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000

PostPosted: Wed Apr 20, 2016 4:28 pm    Post subject: Reply with quote

I had one small problem, it didn't auto-start after login, it appears some changes were made and now --enable-mate and --disable-mate are introduced.

I had mate USE flag disabled since there was nothing configured for it anyway, so I added two lines in compiz-9999.ebuild to fix that problem I mentioned above.

Code:

...
        use mate && myconf+=" --enable-mate"
        use mate || myconf+=" --disable-mate"
...


Then I recompiled compiz with mate USE flag and after login compiz autostarted.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Apr 20, 2016 4:40 pm    Post subject: Reply with quote

You can do that in one line, kajzer:
Code:
use mate && myconf+=" --enable-mate" || myconf+=" --disable-mate"

Assignments return true (unless there's a command substitution going on and it errors, or you're doing something naughty.)

Similarly for an array:
Code:
use mate && myconf+=(--enable-mate) || myconf+=(--disable-mate)
expanded with "${myconf[@]}" when passed to a command, or for iteration.

It is inspiring to see how you three work together so well, btw.
Don't stop now. ;-)


Last edited by steveL on Wed Apr 20, 2016 7:46 pm; edited 1 time in total
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 3 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum