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 attachment 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 attachment 145358 [details, diff] disables the compiling of murmur patch needed by mumble-1.1.3.ebuild
Created attachment 145359 [details, diff] disables portaudio support needed by mumble-1.1.3
Created attachment 145361 [details, diff] disables pulseaudio support needed by mumble-1.1.3.ebuild
Created attachment 145363 [details, diff] 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 attachment 145915 [details, diff] Patch to remove dbus deps As i see no reason, why the client needs dbus, i remove the lines with this patch.
Created attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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.
Comment on attachment 153657 [details] Cleaned up, more complete ebuild 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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. ***
