gammu 1.34.0 is available: http://wammu.eu/news/2014/12/30/gammu-1-34-0/ simply renaming the 1.33.0 ebuild to the new version works.
Meanwhile, we actually have gammu 1.36.1, cf. http://wammu.eu/news/2015/05/20/gammu-1-36-1/ but this version actually can't be built with the current ebuild. The Python module is not created properly anymore. Thanks in advance for updating the ebuild and the tree :-)
are you willing to proxy mainytain this? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Thanks
I just picked up a "Samsung Rugby 4" (which uses an Intel processor ;-) and just found the Samsung upper-end models utilize AT Commands when in Kies Mode. (ie. Gammu is a front-end for terminal AT Commands for mobile phones, and other devices.) I'll attach the latest gammu, and only commented one line within the ebuild concerning a bash patch. (Change logs of gammu since the current stable within Portage, seem to have implemented a bash completion fixes.) Might want to quickly verify what the bash patch is, and if it's already applied upstream? Else I'll get a little more free time later on, or later this week. In the meantime, users will be able to test with the attached gammu ebuilds here. I'll proxy maintain gammu, as it looks like I'm back to using gammu!
Created attachment 417248 [details] gammu-1.36.6.ebuild Commented one line, a bash completion patch, for which may have already been applied upstream due to a comment within the Gammu change logs concerning a bash completion fix.
I just noticed the notes concerning the Python module. Sorry, I'm a ASM/C/Bash kind of guy. So the Python module might still be broken. This will take a little more time if I need to fix Python.
I will CC proxy maintainers then, thanks for volunteering
Seems like I was a bit too slow responding ;-) But if we now have a proxy maintainer for it, it's nice. Thanks!
Created attachment 417252 [details] gammu-1.36.6.ebuild Confirmed bash completion file location is fixed. (Bash completion file is being installed within /usr instead of /etc now.) Removed epatch line for bash completion file.
It maybe the other ${PN}-skip-locktest.patch may not be needed either, but since we're not building Gentoo package on a WIN32 platform, this patch won't hurt either if the patch isn't removed. Since there's no reference to a Bug number, or proper comments, I don't want to break something that doesn't seem to be bugging us for now. Python parts of Gammu are now being distributed separately of the main gammu package. (The following are Gammu change log snippets.) gammu-1.34.0 - Removed deprecated Python modules gammu.Data and gammu.Worker. gammu-1.36.0 - New release to accompany standalone python-gammu. Besides removing Python code, this also fixes several bugs. (The python-gammu module is now shipped separately.)
I'm thinking, create a new separate ebuild for the python-gammu modules. (ie. http://wammu.eu/download/python-gammu/source/) Also, likely can also add me as a proxy maintainer for the wammu ebuild as well. (Wammu is a GUI front-end for Gammu console tools. And the current version of Wammu-0.36 in Gentoo Portage seems to have bugs, and not up to date as the current released version is wammu-0.39.)
Bug #566168, python-gammu-2.4.ebuild Cheers! Please check my work within python-gammu-2.4.ebuild and read my quick notes there. TODO: Strip the old python script lines from within gammu-1.36.6.ebuild, for which are now contained within python-gammu-2.4.ebuild. Once this is complete, we can push both gammu and python-gammu ebuilds into Portage. TODO: Commit an updated ebuild for Wammu.
this is rather extensive. Can you join in #gentoo-proxy-maintianers to discyss this further?
Created attachment 423122 [details] gammu-1.36.8.ebuild
Created attachment 423124 [details, diff] gammu-1.36.8-bashcompdir.patch
I've attached my ebuild for gammu-1.36.8. 1) It is based on gammu-1.33.0-r1.ebuild, not gammu-1.33.0.ebuild. So it includes missing dependencies. 2) Removed all the Python stuff. BTW, it is completely broken even in gammu-1.33.0.ebuild & gammu-1.33.0-r1.ebuild Cmake output of gammu-1.33.0 & gammu-1.33.0-r1 -- Found PythonInterp: /usr/bin/python (found suitable version "3.4.3", minimum required is "2") -- Found PythonLibs: /usr/lib64/libpython3.4.so (found suitable version "3.4.3", minimum required is "2") Python 3.x is not currently supported! 3) Added missing linguas (bn, ro). 4) Updated gammu-1.36.8-bashcompdir.patch. It IS needed. The new Gentoo policy is to install the bash completions unconditionally, but the gammu installer relies on app-shells/bash-completion for determining the correct path.
"Removing all the Python stuff" is imo a very bad idea – speaking of me, the "Python stuff" is the only reason why I use gammu, because I wrote a program managing SMS data which uses gammu's Python bindings as a backend. With gammu 1.34.0 installed, everything works perfectly, so I don't see why Python is "completely broken" with 1.33.0. The fact that there are no Python 3 bindings is surely a problem which should be fixed by upstream. But it's no reason not to install the gammu Python bindings anymore. This is surely not the only program lacking Python 3 support at the moment. Please don't remove the Python part of gammu!
Since 1.36.0 Python module is a separate standalone package which needs a separate ebuild. It should be removed from gammu ebuild as gammu itself doesn't contain anything Python-related anymore. >> With gammu 1.34.0 installed, everything works perfectly, so I don't see why Python is "completely broken" with 1.33.0. It is broken: Python module is not built. I have a default Gentoo install with Python versions 2.7 & 3.4 and version 3.4 being active. # eselect python list Available Python interpreters: [1] python2.7 [2] python3.4 * Both gammu-1.33.0.ebuild & gammu-1.33.0-r1.ebuild doesn't work, cmake complain that "Python 3.x is not currently supported!". But as far I understand, portage should switch to version 2.x during install (python_set_active_version 2 in 1.33.0 and the new python-single-r1 eclass in 1.33.0-r1). This doesn't happen for some reason. That's why I say that building Python module is already broken.
This bug is already a whole year old! I'd prefer to have a new version even without a Python module ebuild.
Well, then the new ebuild without Python support should bot be added (or at least being marked as stable) until the separate package is also in portage. I think this split should also be announced via a news item.
Well, I have prepared a basic ebuild for python-gammu. It seems to work for me with gammu-1.36.8, but it needs more testing since I'm not using Python. Please check bug 566168
Thank you Andrey for seconding my opinion concerning the separation of python-gammu modules from the main gammu ebuild. Most users of Gammu likely only use the main Gammu package. Python developers (I'm guessing here as I have no idea what python-gammu does), would likely use the extra python-gammu package, or any secondary packages requiring python-gammu. If I'm not mistaken, this separate also coincides with the current maintainers plans as well. (As for me and for future maintenance, I think this is obviously the best choice.) If people want to use the developer python-gammu modules, then probably should use a USE=python flag for pulling in the extra python-gammu modules. As to why I have not completed any further work on this, I volunteer and have no need to get into bickering over nothing, Due to the lack of respect, I tended to completely loose interest writing or maintaining any further Gentoo EBuilds.
(In reply to Roger from comment #21) > > As to why I have not completed any further work on this, I volunteer and > have no need to get into bickering over nothing, Due to the lack of respect, > I tended to completely loose interest writing or maintaining any further > Gentoo EBuilds. I have no idea what events lead to those comments but things have changed. I suggest you join to #gentoo-proxy-maint and discover how things have changed. It saves me typing out a 'speal' here, and we do our best work in the channel. Note you siad "I tended". Somewhere in the distant past.
Please re-open a new bug concerning this issue. I am no longer interested, and will only pursue this further if people can respect and work with each other.
Reopening since this ebuild is still pending addition to the tree, and removing Roger from CC
Please note that my ebuild has no python use flag. 1. Is it needed? dev-python/python-gammu is a separate package. The use flag may be added only to pull it in. It has no impact on gammu itself. 2. If it is needed, I don't know how to deal with circular dependencies. dev-python/python-gammu already depends on app-mobilephone/gammu.
I don't think that gammu itself needs a Python USE flag when dev-python/python-gammu will be added to the tree and nothing changes for gammu itself, especially when it makes thing more complicated.
Thanks for removing from CC, but I still prefer this bug to be closed per my notes within Bug #566168, "New ebuild: dev-python/python-gammu (required for >=app-mobilephone/gammu-1.36.0[python])" Basically, both these bugs should be closed and restarted from anew as documented within my previous notes under Bug #566168. Otherwise, just removing myself from the CC appears to poke further pun, etc. (For example, you and/or others could be construed as supporting previous comments rather than remaining neutral.) I know I loose my work and time devoted here on this bug, but remember there are no winners in a fight, only losers. I do not plan to further post within this bug, as I am off the CC list. Good luck.
(In reply to Roger from comment #27) > Thanks for removing from CC, but I still prefer this bug to be closed per my > notes within Bug #566168, "New ebuild: dev-python/python-gammu (required for > >=app-mobilephone/gammu-1.36.0[python])" > > Basically, both these bugs should be closed and restarted from anew as > documented within my previous notes under Bug #566168. This bug is no longer in your hands and therefore a new one will not be opened; not to sound rude or offend, your participation is not required. > Otherwise, just removing myself from the CC appears to poke further pun, > etc. (For example, you and/or others could be construed as supporting > previous comments rather than remaining neutral.) You don't have to comment any further on the bug nor will you get notifications about it. The bug is getting fixed no matter what. There is no "support" or "remaining neutral;" it's just business. > I know I loose my work and time devoted here on this bug, but remember there > are no winners in a fight, only losers. I do not plan to further post > within this bug, as I am off the CC list. Nobody's making you participate. This is all I will say on the matter.
(In reply to Andrey Tikhomirov from comment #20) > Well, I have prepared a basic ebuild for python-gammu. > It seems to work for me with gammu-1.36.8, but it needs more testing since > I'm not using Python. > Please check bug 566168 I seem to have missed absorbing your ebuild here. User awilfox has been working this ebuild, however it would be discourteous to ignore your one here. I'll just repeat my prompt to you here that the bulk of the preparation and work done for 'ebuilding' is done in the channel #gentoo-proxy-maint. You have done nothing but offer a suggested ebuild, meaning an attempt to contribute. You participation is still welcome and the optimum forum to do so is the channel where you can exchange directly with users like awilfox. While awilfox is currently planned as the proxy maintainer, if inclined, you could be a co-maintainer. After all, the assignment will not be done until there is a final satisfactory ebuild.
(In reply to Ian Delaney from comment #29) > > I seem to have missed absorbing your ebuild here. User awilfox has been > working this ebuild, however it would be discourteous to ignore your one > here. I'll just repeat my prompt to you here that the bulk of the > preparation and work done for 'ebuilding' is done in the channel > #gentoo-proxy-maint. You have done nothing but offer a suggested ebuild, > meaning an attempt to contribute. I think you've missed something. My ebuild is already attached to bug 566168. I posted a remark here only for Tobias and others who may be interested in it. Awilfox's version is just a slightly fixed version of mine, however the fixes are questionable. I'll continue the discussion on python-gammu in bug 566168.
If nobody else wants this, I'll take it.
Well, I'm just waiting for acception or rejection of the ebuild.
(In reply to Andrey Tikhomirov from comment #32) > Well, I'm just waiting for acception or rejection of the ebuild. Andrey even that is over simplifying it. I have put a stop to the progress in order to bring you into this, Really can you just foin in the channel #gentoo-proxy-maint. Every-one else has been working this and you are outside the loop. At he moment there is no decided proxy maintainer and you may be the maintainer, but you have never asked to be a maintainer you have submitted an ebuild and we are not to know if your interest stretches only as far as having an ebuild accepted or not your ebuild like any needs to be dev reviewed. That has already occured with Elizabeth Myers however for reason I will not describe here, they are all on pause.
Please don't reassign bugs until maintainer metadata information is updated finally
Pacho, I think it would be instructive if you could visit the IRC channel, and perhaps guide those of us that are attempting to deal with the bugs backlogs. Thanks.
Anecdotally, if you don't have an IRC client, or are otherwise unfamiliar with IRC, you can get to our channel via this webchat link - https://webchat.freenode.net/?channels=gentoo-proxy-maint .
Sadly I hardly have time to dig with the bugs from gnome, maintainer-needed... I remember that I should also help more in systemd... :S, then, I don't have much time to stop to talk a lot on IRC but, of course, we can talk via mail if you want :) (that will let me to reply when I am able to ;)) Regarding the concern about the assignment of the bug -> the idea is to ensure it's assigned to the real maintainer (even being maintainer-needed, that is an alias followed by a few people like me) than on random mails because we have seen cases of people volunteering at some moment, getting the bugs, finally nothing was fixed in the tree, and the bugs were completely ignored because they were completely out of our radar :S Once the bug is solved and metadata updated with the final new maintainer, of course the bugs can/should be reassigned to the new person :) See you
