| Summary: | net-im/emesene ebuild request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Marcello Magaldi <magowiz> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | fabiano.francesconi, ighea, ircalf, kevin.fullerton, marcopaolone, net-im, pacho, phobosk, r3pek, remy.suen |
| Priority: | High | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://emesene.org/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emesene-999.ebuild
emesene-1.0.ebuild emesene-1.0.1.ebuild emesene-1.0.1.ebuild emesene-1.5.ebuild emesene-1.6 ebuild libmimic with python bindings patch libmimic's python binding patch cleaner version of previous ebuild emesene 1.6.1 mate emesene 1.6.2 gpg use added for EncryptMessage plugins spell and gpg use flag added |
||
|
Description
Marcello Magaldi
2008-02-23 14:58:40 UTC
There's already an ebuild on the emesene trac site for this - http://emesene.org/trac/attachment/ticket/147/emesene-9999.ebuild - this builds from the latest SVN version, but shouldn't be much to build against a released .tar.gz Created attachment 144496 [details]
emesene-999.ebuild
I made an emesene-r999 ebuild since is the last stable, using the other live is not the best thing to do.
emesene 1.0 is out! http://www.emesene.org/ Created attachment 147513 [details]
emesene-1.0.ebuild
I modified the last emesene-999.ebuild to suite the new 1.0.
this is already in sunrise overlay: https://overlays.gentoo.org/proj/sunrise/browser/reviewed/net-im/emesene?rev=6053 i hope it can get into official portage soon I hope it too.It's widely use in my office. Works well on my amd64... hope to see in portage too... It's avaiable a new fix release: 1.0.1. I tried to rename e digest the current ebuild to use 1.0.1, and it works, except for a few problems, so I leave it to someone more skilled here... Created attachment 161463 [details]
emesene-1.0.1.ebuild
this is emesene-1.0.1.ebuild for upstream 1.0.1 released on July 21, 2008,
some installation process is adjusted, and is neccessary to some upstream release layout changes.
Created attachment 161474 [details]
emesene-1.0.1.ebuild
According to review from darc on #gentoo-sunrise, make two changes:
1. python_mod_cleanup added into pkg_postrm
2. domenu misc/emesene.desktop to install the desktop entry
Now it can be checked into the sunrise overlay.
i really hope it can get into official portage soon. All my friends are using emesene on a variant of different Linux distribution so it seems gentoo is lagging behind the worst Created attachment 202207 [details]
emesene-1.5.ebuild
Not able to install stuff for using webcam. I tryed with "python ${MY_D}/setup.py build_ext -i", but it doesn't work.
If I use this command in the unpacked directory of the program it does not work anyway, but at leat it creates the "build" directory with the object files inside it.
Any ideas to solve these problems?
(In reply to comment #13) > Created an attachment (id=202207) [edit] > emesene-1.5.ebuild > > Not able to install stuff for using webcam. I tryed with "python > ${MY_D}/setup.py build_ext -i", but it doesn't work. > If I use this command in the unpacked directory of the program it does not work > anyway, but at leat it creates the "build" directory with the object files > inside it. > Any ideas to solve these problems? > You have to install libmimic and gst-python in order to make webcam support work, then run that command 'setup.py build_ext -i' I don't know how to make an ebuild, but make a webcam flag e add libmimic and gst-python as depedencies for that flag err, you actually did just that, sorry Hi all, I'm currently using net-im/emesene-1.0.1 from 'sunrise' overlay Spell Plugin doesn't work for me, no matter what language I select in the properties window. It says gtk-spell is not loaded or something similar. Installing 'dev-python/gtkspell-python' seems to fix this. Maybe we need to insert this as a dependency. Also, is emesene-1.5 getting into the tree or in an overlay? (In reply to comment #16) > Also, is emesene-1.5 getting into the tree or in an overlay? 1.5.1 is currently in sunrise overlay (In reply to comment #17) > (In reply to comment #16) > > Also, is emesene-1.5 getting into the tree or in an overlay? > > 1.5.1 is currently in sunrise overlay > I sync everyday. It wasn't there yesterday, I swear :P Thanks anyway, emerging it now ;-) (In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > Also, is emesene-1.5 getting into the tree or in an overlay? > > > > 1.5.1 is currently in sunrise overlay > > > > I sync everyday. It wasn't there yesterday, I swear :P > Thanks anyway, emerging it now ;-) > Sure, I sync every day too, 1.5.1 hit sunrise today ;) (In reply to comment #16) > Hi all, > > I'm currently using net-im/emesene-1.0.1 from 'sunrise' overlay > Spell Plugin doesn't work for me, no matter what language I select in the > properties window. It says gtk-spell is not loaded or something similar. > Installing 'dev-python/gtkspell-python' seems to fix this. Maybe we need to > insert this as a dependency. > OK, same goes for emesene-1.5.1 that's currently in 'sunrise' overlay The spell plugin doesn't work without 'dev-python/gtkspell-python' Also the flag for 'libmimic' is not there. (In reply to comment #20) > (In reply to comment #16) > > Hi all, > > > > I'm currently using net-im/emesene-1.0.1 from 'sunrise' overlay > > Spell Plugin doesn't work for me, no matter what language I select in the > > properties window. It says gtk-spell is not loaded or something similar. > > Installing 'dev-python/gtkspell-python' seems to fix this. Maybe we need to > > insert this as a dependency. > > > > OK, same goes for emesene-1.5.1 that's currently in 'sunrise' overlay > The spell plugin doesn't work without 'dev-python/gtkspell-python' > can anyone else confirm that and maybe add the dependency? emesene 1.6 is out. Just download the tarball and run ./emesene. To add in webcam suport, you must have dev-python and run `python setup.py build_ext -i`, which will build libmimic. Having libmimic installed via portage doesn't seem to work. Apparently it has to be built with python. Seems to me to be very easy to make an ebuild for it, which I would myself, if only I knew how. I have no idea how to make it show up in the DE's menu and stuff like that. Other than that, it is really just a matter of running the script inside the extracted tarball directory. Created attachment 220437 [details]
emesene-1.6 ebuild
Ok, this is a ebuild I *tried* writing.
It's my first time messing around with ebuilds, so I don't know how good it is. It did work on my system, though.
(In reply to comment #23) > Created an attachment (id=220437) [details] > emesene-1.6 ebuild > > Ok, this is a ebuild I *tried* writing. > > It's my first time messing around with ebuilds, so I don't know how good it is. > It did work on my system, though. > There's actually a mine ebuild that's going to be uploaded on official portage tree as soon as possible. I saw that you added that "libmimic" dependency although emesene I think don't use it. Do you think it's necessary? (In reply to comment #24) > (In reply to comment #23) > > Created an attachment (id=220437) [details] [details] > > emesene-1.6 ebuild > > > > Ok, this is a ebuild I *tried* writing. > > > > It's my first time messing around with ebuilds, so I don't know how good it is. > > It did work on my system, though. > > > > There's actually a mine ebuild that's going to be uploaded on official portage > tree as soon as possible. > > I saw that you added that "libmimic" dependency although emesene I think don't > use it. Do you think it's necessary? > Emesene uses libmimic to handle webcam conversations. You can add a flag like "webcam" to only emerge libmimic if user wants webcam support like Satoshi Hayazaki has ;) Created attachment 225889 [details]
libmimic with python bindings patch
Created attachment 225891 [details, diff]
libmimic's python binding patch
Created attachment 225893 [details]
cleaner version of previous ebuild
just added 3 new patchs that should fix the webcam problem people are having. be sure to add the new libmimic version as you have to have the python bindings of it. It's works here but the ebuilds aren't 100% yet... Created attachment 226899 [details]
emesene 1.6.1 mate
emesene 1.6.2 released. Added a missing dep for spell plugin (dev-python/gtkspell-python); fixed media-libs/libmimic dep, since it doesn't have a python use flag. Created attachment 234035 [details]
emesene 1.6.2
Nevermind my previous comment about libmimic, I just lost some steps of conversation. Sorry. I want to point out to your attention that an updated ebuild could be found on my github repo: http://github.com/elbryan/elbryan-s-ebuilds/tree/master/net-im/emesene/ Since I'm still looking for a cleaner solution to install it, I don't want to push it officially somewhere.. I think this ebuild needs to be polished a bit There is an undocumented (as far as I know) dependency: gst-plugins-v4l2 It complains about missing v4l2src if this is not installed. After installing it, everything worked. It seems this is maintaned in the sunrise overlay. Perhaps I should also warn the folks there (don't know how, though), since gst-plugins-v4l2 is not in their ebuild's depency list either. This appears to be the dependency list in Arch: gnome-python-extras: for spell-check plugin gtkspell: for spell-check plugin cabextract: for Wink preview plugin gnash-common: for Wink preview plugin gstreamer0.10-python: for webcam support The current ebuilds do not honor those. I will probably try writing a new, improved, ebuild, but I can't promise anything. How does ebuilds in the sunrise overlay work? Is there a maintainer I can contact with this information? I am the one that maintains the ebuild in sunrise. You can post everything you think oughts to be said. First of all I want to say that you shouldn't take ARCH linux pkgbuild dependancies and throw them inside a gentoo ebuild. Few deps (like the spell checker plugin) are mentioned in elog (you can install that package separately in order to acheive that result). You should check the ebuild for any missing deps rightly inside a gentoo system and, most important thing, you should avoid to pull double dependancies. For instance: (gtkspell would be pulled by dev-python/gtkspell-python, that's the right package to install in order to have spell checker plugin). What about media-plugins/gst-plugins-v4l2? Are you sure it's needed? If so, tell me and I'll fix the ebuild in sunrise-overlay. However, feel free to mail something to me or to query me on irc.freenode.net since I'm hosted in #gentoo-sunrise chan v1.6.3 released in sunrise-overlay (pending for a developer approval). Added media-plugins/gst-plugins-v4l2 as dependency when webcam useflag is set. Created attachment 256386 [details]
gpg use added for EncryptMessage plugins
Created attachment 256410 [details]
spell and gpg use flag added
I have to disagree about "spell" and "gpg" USEFLAGs. When we put USEFLAGs inside an ebuild, those will somehow modify the behaviour of the compilation process. Those packages ( pexpect and gtkspell-python ) are not taken into account during the compilation phase. For this reason I can't accept these new useflags. Furthermore, gtkspell-python usage for spell-checking feature was already promoted in the postinst phase. This is exactly the good spot where to place such information-related content. (In reply to comment #41) > I have to disagree about "spell" and "gpg" USEFLAGs. > > When we put USEFLAGs inside an ebuild, those will somehow modify the behaviour > of the compilation process. Those packages ( pexpect and gtkspell-python ) are > not taken into account during the compilation phase. For this reason I can't > accept these new useflags. Actually this is not true. You create USE flags to activate or deactivate features of some applications and that does not have to necessarily change the way that same software compiles. It could just install some needed package to make the feature work. The correct place to do that is in RDEPEND (as it is), so the ebuild looks good to me. > > Furthermore, gtkspell-python usage for spell-checking feature was already > promoted in the postinst phase. This is exactly the good spot where to place > such information-related content. > Yep, the einfo should be removed as there's a use flag for it. actually, the whole postinst could be removed. True or not that is my ebuild and I don't want it to be filled with useflag for every wannabe optional thing. I'll just drop a message about that existing option in the postinst, as I did before. (In reply to comment #43) > True or not that is my ebuild and I don't want it to be filled with useflag for > every wannabe optional thing. I'm sorry but you wanna do things the right way or *your* way? And it's not *your* ebuild. You made it, but it's in the gentoo bugzilla, so it's _*everybody's*_ ebuild. > > I'll just drop a message about that existing option in the postinst, as I did > before. > Do you really read all the messages that appear during emerge? do you thing i'm gonna read a backlog of messages just to read the messages a simple ebuild like this made out?! einfo's, ewarn's, etc are made to alert the user of something, give information, not change the way that package works. > > And it's not *your* ebuild. You made it, but it's in the gentoo bugzilla, so > it's _*everybody's*_ ebuild. > Man, come on. That's what I meant. > Do you really read all the messages that appear during emerge? do you thing i'm > gonna read a backlog of messages just to read the messages a simple ebuild like > this made out?! einfo's, ewarn's, etc are made to alert the user of something, > give information, not change the way that package works. You should do it. It is a good habit to have. I'm telling you that I do not want to modify the ebuild that way and, furthermore, I have been lectured in #gentoo-sunrise IRC channel about not to provide useflags for just trivial things (such as plugins). Useflags are justified only when they modify the application's behaviour a lot. > You should do it. It is a good habit to have. Yeah it is a "very" good habit and it is a "time saver" to read the emerge logs ESPECIALLY when you upgrade a system with 300+ packages :D :D :D > I'm telling you that I do not want to modify the ebuild that way and, > furthermore, I have been lectured in #gentoo-sunrise IRC channel about not to > provide useflags for just trivial things (such as plugins). > Useflags are justified only when they modify the application's behaviour a lot. Well either you did not got the lecture the right way or your lecturer spoke to you about the useflags in general... Do not forget that there are specifics for every app ! ... Back on the topic... : 'spell' and 'gpg' are systemwide flags that DO ADD an important functionality to all the apps that use them ('ufed' will be the easiest way for you to check this up)... So this ebuild should have those flags and should not have any ewarn/elog hooks in postinst().... BTW it is really a shame this ebuild is not in the official gentoo tree... but i guess the ones responsible for the upload are too busy with other "important" uploads .... On tree. Thanks |
