Bugzilla Bug 206792

A new version (1.1.2) of mumble has been released 5 days ago (15th of January).
The currently keyworded mumble package is broken (for me) and highly outdated.
The hardmasked 1.1.1 version is broken for me, too.
Old discussion for mumble-1.1.1 (and earlier):
http://bugs.gentoo.org/show_bug.cgi?id=183781


Hint: 1.1.2 now uses pkg-config to detect if Pulse/Portaudio is available and
support should be built. Therefore dev-util/pkgconfig should now be added as a
dependency in the ebuild (even though most systems have that package anyway).
The use of pkg-config can be seen in /trunk/src/mumble/mumble.pro, ll. 44-45.

Reproducible: Always

Steps to Reproduce:
version bump

1.1.3 is out.

Created an attachment (id=145356) [details]
ebuild for mumble-1.1.3

This ebuild contains optional portaudio and pulseaudio support, but optional
alsa and oss support is still missing. At the moment alsa and oss are
mandatory.
Needs the following files:
mumble-1.1.3-disablePulseaudio.patch
mumble-1.1.3-disablePulseaudio-disablePortaudio.patch
mumble-1.1.3-disablePortaudio.patch
mumble-1.1.3-disableMurmur.patch

Created an attachment (id=145358) [details]
disables the compiling of murmur

patch needed by mumble-1.1.3.ebuild

Created an attachment (id=145359) [details]
disables portaudio support

needed by mumble-1.1.3

Created an attachment (id=145361) [details]
disables pulseaudio support

needed by mumble-1.1.3.ebuild

Created an attachment (id=145363) [details]
disables portaudio and pulseaudio support

needed by mumble-1.1.3.ebuild

Any progress in this bug + with the mask for the 1.1.1 version?

Created an attachment (id=145915) [details]
Patch to remove dbus deps

As i see no reason, why the client needs dbus, i remove the lines with this
patch.

Created an attachment (id=145916) [details]
New version without dbus deps

Hmmm, if you don't want DBus - alright.

But this build shouldn't be a starting point for others to improve, as DBus is
needed and used by the client. I just talked with slicer (the dev of mumble),
DBus enables the mumble:// protocol, for instance.
Also, it might bring some more interesting queries in the future.


If anyone is going to remove DBus - then it should be done via useflags at
LEAST (I wouldn't remove it at all).

Created an attachment (id=145945) [details]
enhanced mumble-1.1.3 ebuild

This version installs the following things as well:
- the mumble man pages
- mumble protocol to enable e.g. konqueror to handle links like
mumble://somehost.com/channel/subchannel

Added festival useflag, which just adds dependency to festival if set.
If emerged without the festival useflag and festival is not installed already
on the system the text to speech options will still show up in mumble, but just
wont work.
Changed the RDEPEND variable to be more correct.
Still missing is the optional alsa and oss support.

so dbus is neither needed nor used atm. If you like dbus and automatic linking
for mumble://, ok, but not everyone uses or wants dbus and it still is and
should stay optional.
As adding a useflag + patching with the flag disabled is trivial, i wont attach
a new build only for this.

Created an attachment (id=146652) [details]
mumble-1.1.3-r2 with optional dbus support

this ebuild needs the following patches to work properly:
mumble-1.1.3-disableDBus.patch
mumble-1.1.3-disableMurmur.patch
mumble-1.1.3-disablePortaudio.patch
mumble-1.1.3-disablePulseaudio.patch
mumble-1.1.3-disablePulseaudio-disablePortaudio.patch

Ebuild is working for me.

For me it doesn't work. I'm using sys-devel/gcc-3.4.6-r2 and PCH (precompiled
headers) don't seem to work there with mumble. So i made a small workaround
after which mumble compiles and runs:
In src_compile() i added after "emake":
cd "${S}/src/mumble"
mv Makefile.Release Makefile.Release.orig
cat Makefile.Release.orig | sed -e 's/-include release\/mumble //g' >
Makefile.Release
cd "${S}"
emake

I know it's more a hack than a solution but it was the easiest way for me to
get it to work. Maybe others find this useful.

(In reply to comment #15)
> For me it doesn't work. I'm using sys-devel/gcc-3.4.6-r2 and PCH (precompiled
> headers) don't seem to work there with mumble. 

Same here (using the 1.1.3-r2), but I shortened your workaround to a single
line which goes between qmake and emake:

sed -i -e 's/include release\/mumble //g' ${S}/src/mumble/Makefile.Release

Which seems to do the trick.

Ok, this works for me. Sorry for omitting the emake qmake line. 

src_compile() {
        qmake "${S}/main.pro"
        emake qmake
        sed -i -e 's/include release\/mumble //g'
${S}/src/mumble/Makefile.Release
        emake
}

1.1.4 released

Yes, and almost ALL things can now be configured via qmake (CONFIG+=no-dbus
etc). So we don't need all the patches anymore, we can specify upon compiling
what to include and exclude.

Maybe someone with the proper ebuild knowledge can now slap together a
functional and stable ebuild? ;)

Created an attachment (id=153277) [details]
ebuild for mumble-1.1.4

This is my very first ebuild. Based on version 1.1.1, plus ebuilds and comments
for version 1.1.3 posted here. I'm not sure if DEPEND part is fully correct,
but the script works good on my system.

1.1.4 ebuild works also for me on Gentoo ~amd64

Created an attachment (id=153657) [details]
Cleaned up, more complete ebuild

I attached a new ebuild. This is based on Mikhail's ebuild, however I did a few
cleanups and bugfixes (one bug still left though, if someone could mangle that,
I'd be happy).

The changes I applied:
- removed all the sed magic and used qmake for configuration instead
- fixed speex dependency
- fixed texttospeech dependencies
- added debug flag
- added ssl check to qt package
- install link plugin
- install mumble protocol even if dbus useflag is not set
- make die-messages a bit clearer
- fixed a bit of syntax here and there

Now, one bug is left: Mumble needs all its libs to reside in /usr/lib/mumble/
instead of /usr/lib/. However, using dolib.so I was not able to put the libs to
that folder. I tried it with "into /usr/lib/mumble/" but that didn't work. An
easy workaround would of course be to just use cp to copy them to the right
place, but I'm not sure if that is correct according to the Gentoo ebuild
guidelines. So if anyone knows how to install the libs and link plugin lib to
/usr/lib/mumble, go ahead and fix it please.

Except for that, the ebuild should now be complete, tidied up and work.

Created an attachment (id=153705) [details]
more fixes for 1.1.4

- fixed inverted logic of the debug use-flag
- fixed syntax of qmake call (use-flags didn't apply)
- use CONF_LIBDIR variable so that libs install into /usr/lib/mumble, it's what
Sascha was talking about.

(From update of attachment 153657 [details])
Oooops, sorry for the 2 bugs I introduced :)

Thanks for fixing them and thanks for fixing the library issue. Learned a new
thing today :)

I tested the ebuild and it works fine.

Mumble works, mumble-overlay works, man entries work, menu entry (with icon)
works... If it was me, this could finally go live after a few more testreports
:)

On another note, I would suggest to put the server, murmur, into a seperate
ebuild. Someone might want to have dbus with the server but not with the
client. To achieve that within one ebuild we would have to introduce custom
cflags which will break the simple "dbus" continuity. So I think a seperate
murmur ebuild and keeping this one client-only would be the best approach.

Created an attachment (id=153737) [details]
another cleanup

Sorry for the spam, but now that Mikhail fixed the libraries thing, we don't
need to create the folder manually anymore. dolib does that on its own, so I
removed the line.

PS: In my comment above I meant custom "useflags" and not "cflags" of course
;).

This should be mumble only, murmur already has a seperate bug (bug 207627)

So, I have referred multiple people to this ebuild to use it for installing
mumble, but no more complaints/bugs/errors have been posted here.

Commit to portage tree and close bug?

Two notes about the latest "cleanup":
- There's a pointless src_unpack-function
- the einfo part says "(obsolete as of mumble-1.1.4)" - if it's obsolete, why
is this info still there?

(In reply to comment #28)
> Two notes about the latest "cleanup":
> - There's a pointless src_unpack-function

Well, the unpack function unpacks? Or can that be left out and emerge will
still automatically unpack, even if it's not explicitly called (sorry, although
I checked ebuild docs again, I couldn't find any information if it could be
left out, or not and I'm rather new to ebuilds :) )?

> - the einfo part says "(obsolete as of mumble-1.1.4)" - if it's obsolete, why
> is this info still there?
> 

The feature still works in 1.1.4, but is antiquated due to a new input method
introduced in 1.1.4 (x input polling). However, should the new method fail
(which works without configuration), people could still fall back to XEVIE
(although Xevie itself is pretty bugged and rarely works...).
So, yeah, that message might be useful, it also might not be necessary. I guess
that's the tree mainter's call to include it, or not.

Created an attachment (id=156409) [details]
compilation faillure

i have a compilation faillure...

qt-opengl or opengl in qt4 was lacking
so make it check for opengl use flag

Created an attachment (id=156447) [details]
fixed missing opengl dep, removed obsolete info, removed src_unpack

Thanks for your bugreport. The issue has been fixed in this ebuild. I also
removed the obsolete info and the src_unpack function.

Created an attachment (id=158515) [details]
ebuild with split qt4 dependencies

I'm a n00b to ebuilds but I gave this a shot.
starting with qt-4.4 Qt is split into separate packages. this should be
reflected in the dependencies. 
see http://bugs.gentoo.org/show_bug.cgi?id=217194

Thank you Lorenz, I just read about the split qt4 things a few days ago, too,
and wanted to implement that. Thanks for doing this ;)

However, as I have no idea about how to deal with those new split dependencies,
I'm just throwing in my thoughts:

- qt-gui got a dbus useflag, too. Do we probably need it and therefore add
another check for it in pkg_setup?

- as can be read in bug #217161 comment 6, the dependencies should somehow
contain the different slots or versions or however you would call them. As
qt4.4 is currently hardmasked, mumble could not build with your current setup.
Therefore we also need to somehow allow <qt.4.4 versions.

- should this bug here be marked as blocker for bug #217194 ?

Created an attachment (id=158981) [details]
ebuild with split qt4 dependencies

(In reply to comment #34)
> Thank you Lorenz, I just read about the split qt4 things a few days ago, too,
> and wanted to implement that. Thanks for doing this ;)

No Problem. I'm always happy to find a place to give something back to the
community :)

> However, as I have no idea about how to deal with those new split dependencies,
> I'm just throwing in my thoughts:
> 
> - qt-gui got a dbus useflag, too. Do we probably need it and therefore add
> another check for it in pkg_setup?

done

> - as can be read in bug #217161 comment 6, the dependencies should somehow
> contain the different slots or versions or however you would call them. As
> qt4.4 is currently hardmasked, mumble could not build with your current setup.
> Therefore we also need to somehow allow <qt.4.4 versions.

I agree. I tried my best but it wasn't that easy (see last note below).

> - should this bug here be marked as blocker for bug #217194 ?
> 

I don't think so. It will just stay open as long as no new ebuild exists. One
could maybe write a comment that a new ebuild with split dependencies is on
it's way.

Some notes on the ebuild:
 * I removed the check for the gcc version to a RDEPEND. I hope that's ok.
 * I moved the check for the debug flag from the src_install to the pkg_setup
function.
 * As a switch between >=qt4.4 and <qt4.4 I check if x11-libs/qt-core:4 is
installed. I don't know if this is a good idea or if there is a better way.
 * As a test I unmerged qt-gui and tried to emerge my ebuild and it tried to
pull qt-4.3 which got blocked by qt-core and the other qt-4.4 ebuilds. I don't
know how to tell emerge to favor the split ebuilds especially when only one is
missing.

- For the various qt useflag checks there is QT4_BUILT_WITH_USE_CHECK="sqlite3
dbus"

- pkg_setup() contains a spurious "echo"

- I do have this in my ebuild in src_compile():
       local dir
       for dir in src/mumble overlay_gl; do
               cd "${S}/$dir"
               eqmake4 ${dir##*/}.pro  || die "qmake failed"
               lrelease ${dir##*/}.pro || die "lrelease failed"
               emake CC="$(tc-getCC) ${CFLAGS}" \
                       CXX="$(tc-getCXX) ${CXXFLAGS}" \
                       LINK="$(tc-getCXX)" || die "emake failed"
       done
  I do not know whether the for-loop is still needed (maybe to avoid building
murmur?), but
  - eqmake4 probably contains some extension over plain qmake,
  - the current variant seems not to call lrelease and thus does not build
translations,
  - and can someone explain to me why the CC,CXX,LINK commands needed to be
passed to emake earlier? Would the qmake generated Makefile otherwise ignore
the C(XX)- and LDFLAGS?

- I always wondered why Mumble ended up in such an odd place in the menu, now I
see: make_desktop_entry ... "KDE;Qt;AudioVideo". Should this not be
"KDE;Qt;Internet" or similar? That is where I would expect it.

Created an attachment (id=162167) [details]
ebuild with described changes

- texttospeech useflag replaced by speech (that one is already in
use.local.desc)
- pkg_setup() replaced by QT4_BUILT_WITH_USE_CHECK="ssl sqlite3 dbus", though
that does not check "debug" anymore. If this cannot generate compile-time
problems, I assume this is not an issue since someone using that flag will know
what to do anyway.
- there was a indention mistake in src_compile()
- qmake -> eqmake4
- handle release/debug config better. Previously it seemed as if debug would
always be overridden by release later. (Did not test to verify this.)
- error out on emake failure
- Categories=Qt;KDE;Network;Telephony; for the .desktop file

Created an attachment (id=162181) [details]
Improved ebuild

Corrected a typo in DEPEND (should include RDEPEND and not itself) and do not
depend on qt-core, since that is already demanded by all other qt-* ebuilds.

Version bump : 1.1.5

Renaming the 1.1.4 ebuild to mumble-1.1.5.ebuild works for me.
Useflags: alsa dbus oss pulseaudio speech -debug -portaudio

(In reply to comment #39)
> Version bump : 1.1.5
> 

1.1.6 is out - please bump and remove the betas instead.

Version bump: 1.1.6

mumble-1.1.6 compiles with http://bugs.gentoo.org/attachment.cgi?id=162181

Any chance to have the bumped version on portage?

Can someone please update the summary to 1.1.6?

Created an attachment (id=168150) [details]
EAPI 2 ebuild

Updated the ebuild for media-sound/mumble-1.1.6 to EAPI 2. If there are any
mistakes, please tell me.

PS: If no one in Gentoo wants to maintain this ebuild, I'd be willing to
support it in Sunrise (or wherever you decide).

I'd like to see this either in sunrise or in the normal tree. As there is
currently no working in-tree version for me.

Tried Dennis' 1.1.6 ebuild. Compiles fine and everything works without problems
and as expected.
I'd also like to finally see this in the tree (murmur 1.1.6 has already been
commited recently). The mumble repo could be cleaned up anyway - remove the
0.9.x built as it's completely broken and unusable (but in ~arch anyway, lol)
and either unmask 1.1.1 or (even better) remove it aswell. Instead, push out
this 1.1.6 ebuild. There's no reason in my eyes not to commit it, as nobody can
report any real problems. Unless the current version is finally made available
for others to easily install and run, there won't be any reports either. Get
that thing out finally :)

I second Saschas request.

The mumble-1.1.6.ebuild compiles fine, and I see no missing feature or
unnecessary dependency.

In CVS, thanks Dennis for the updated ebuild and everyone else who contributed
to this bug. Please report any issues you might run into in a new bug.

*** Bug 241682 has been marked as a duplicate of this bug. ***