Is there a recommended way to naming KF5 additional components (like applets
or themes) in AUR? We have a paper  which describes compnent naming for
KDE4, but haven't one for KF5.
For example atm we have applet "plasma-nm"  so should applet be named as
"plasma-appletname"? I suppose they should be named as "kf5plasma-applet-
appletname" on the analogy of KDE4 components.
Hello AUR general & Compiz package maintainers.
There was some discussion about Compiz packages a little while ago, i
don't think that much came of it. I'd like to re-open the discussion.
Calling the 0.8 series "compiz" and the 0.9 series "compiz-devel" is
no longer correct, it hasn't been for quite some time.
All information on this page:
is completely wrong and out of date, like 5 years out of date, and
should not be used as a reference for anything.
Tracking of the state of Compiz should be done from here:
Development of the 0.8 series is as close to being dead as it could
be. Unless you count 2 tiny commits 5 months ago, nothing has been
done in 16 months, and even that 16 month old commit was a minor
change just to get it working with KDE 4.10, with the commit prior to
that being an additional 5 months back.
My suggestion is pretty simple, "compiz" becomes the 0.9 series, the
0.8 series becomes "compiz-legacy".
Any 0.9 series packages that have "core" in their name should have it
removed, since the concept of Compiz being split up has been dropped
since the 0.9 series. The 0.9 series doesn't have a "core" component,
it's just "compiz".
martadinata666's "compiz-core" package would become "compiz-legacy-core"
dev_rs0's "compiz-core-devel" package would become simply "compiz"
Chazza's "compiz-core-bzr" package would become "compiz-bzr"
flexiondotorg's "compiz-core-mate" package would become
My "compiz-gtk-standalone" package would become "compiz-legacy-gtk-standalone"
All the "compiz-fusion-plugins-*" packages would become
...and so on.
What are everyone's thoughts?
I first came across this problem while working on mmug-qq (a project to
create updated and upstream packages for various build dependencies of
pcsx2) when I found that some cmake packages would not compile in 32bit
with any configuration.
It took some digging, but I finally determined that I had indeed exhausted
every appropriate option. Something was blocking, ignoring, or removing my
settings; preventing packages from being built with the parameters I
specified in makepkg.conf and in the PKGBUILDs.
The problem is cmake, or more specifically it's various layers of macros.
Many cmake packages fail to pass CFLAGS, CXXFLAGS, and LDFLAGS through the
various macros to make; some packages ignore these variables entirely. This
does not appear to be intentional; I did not find code explicitly stripping
away or replacing flags. I found that many of the macros just lost them
somewhere; failed to transfer them to cmake variables that would be used
later; or inexplicably make with no flags at all for no reason.
The only way I could convince cmake packages to always use all of the flags
specified in makepkg.conf and/or in the PKGBUILD was to deceive it; to
force it to use compilers and a linker with the flags built in.
So I created three files:
gcc-flagged: /usr/bin/gcc $CFLAGS "$@"
g++-flagged: /usr/bin/g++ $CXXFLAGS "$@"
ld-flagged: /usr/bin/ld $LDFLAGS "$@"
and added this to sources():
and this to the cmake call:
For an example, check out my sdl2-hg-multilib packaging: