This is a new introduction for python-gammu-2.4.ebuild, and contains the gammu python modules included within previous gammu-1.36.0 versions. Basically, >=gammu-1.36.0 versions have had the gammu python modules moved into a seperate source package now called python-gammu. For users and packages utilizing these packages, gammu includes a "python" USE flag, and future gammu-1.36 ebuilds will have a runtime depend requiring this package. I would suggest pushing this EBuild into the tree along side the gammu-1.36.ebuild at the same time. (It is also noteworthy, Wammu is a graphical frontend also building upon these same tools.) Please refer also to Bug #536722 app-mobilephone/gammu-1.36.1 version bump Reproducible: Always
Created attachment 417322 [details] python-gammu-2.4.ebuild New ebuild, a runtime depend for gammu when >=gammu-1.36 is built using the python USE Flag.
Please note, I have not included the 20-30 example .py files by including an examples USE flag. I do not use Python (and I use other languages), nor do I have any clue if I've built this package correctly due to it's usage of Python. I'd suggest double checking my work here. If users would like the examples (and I know I would if I used Python), then simply searching the /usr/portage folder for "examples" (ie. fgrep /usr/portage -r -e examples) and copying some lines into this ebuild file should be quite easy for somebody else interested in doing so. In the meantime, I'll remain focused on stability.
There's not much more I can say other than this is unusable. You are attempting to use the defunct / almost deprecated distutils eclass which implies you aren't familiar with the new python eclasses. You havestabled keywords and all phases are simply commented out. Just join in the channel cited in the link https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers and we can restart from scratch
Shrugs. Like I already stated, I do not use Python. (ie. I tend to use C/Bash.) And the attached (gammu & python-gammu) are not completed ebuilds. No where did I state the attached ebuilds were finalized, especially the python-gammu.ebuild. The attached here are for testing and feedback. Please note, I am only a volunteer and do not get paid for my time. I have submitted many ebuilds in the past here, with the trivial (ie. Keywords) being adjusted by maintainers after the ebuild was pushed to the tree. I've already briefly scanned over the "Project:Proxy Maintainers" and am kind of stumped as to what you're asking. Within the past, I've always just proxy maintained ebuild through bugs.gentoo.org. I do not have time to chat via IRC. If distutils or whatever handles python "make" and "make install" scripts, please just simply advise or point in the correct direction.
If you submit a pythonic ebuild, it follows you need be prepared to learn basics of pythonic ebuilds. While the changes are not a trivial as you treat them, they are in fact relatively simple. You cna start here: https://wiki.gentoo.org/wiki/Project:Python/Python.eclass_conversion. Whatever minimal edits and changes might have worked in the past don't work here. If it's too much effort I'll simply write and add it myself and / or under a different proxy user of the project. <Please note, I am only a volunteer and do not get paid for my time.> ditto
The Python.eclass_conversion Wiki page is exactly the direction or tip I needed. The remainder of your statements have me puzzled. What exactly does Pythonic mean? Your last statements seem to be innuendo.
(NOTE: I came across that Gentoo Wiki Python eclass conversion page while writing this ebuild, but scanning into the "Phase functions" sections, I thought the distutils-r1.eclass were lacking features of the distutils.eclass ... ie. Likely misinterpreted the "no unpack" feature of distutils-r1.eclass.) I have no problems with somebody else writing these ebuilds. I'm pretty sure I can see where you're leading, and I likely do not desire to follow.
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.
Created attachment 423174 [details] python-gammu-2.4.ebuild
Created attachment 423576 [details, diff] python-gammu-2.5.ebuild Attached is an ebuild for version 2.5, which contains bugfixes and support for newer versions of gammu. The ebuild is also fixed up a little and has support for running the test suite.
Andrew Wilcox is the proxied maintainer for this ebuild after direct discussions in irc. Roger has basically ruled himself out by his own hand. The ebuild submitted by awilfox pass all required qa tests in the overlay with all deps emerged. This cannot be added to portage until the bumped version of app-mobilephone/gammu is firstly added to portage.
Are the docs (news and readme) intentionally removed from the ebuild? Concerning the test suite, I didn't add it just because of the failed test.
Ian Delaney: "Roger has basically ruled himself out by his own hand." More exactly, I do not wish to be exploited by your apparent leadership. Your direction of defamation towards a volunteer is unimpressive. You could have just continued onward without stating the above. Please simply move on as I do not want to take part with your agenda, and please Mr. Delaney, refrain from further defamatory remarks.
(In reply to Roger from comment #13) > Ian Delaney: "Roger has basically ruled himself out by his own hand." > > More exactly, I do not wish to be exploited by your apparent leadership. > Your direction of defamation towards a volunteer is unimpressive. You could > have just continued onward without stating the above. Please simply move on > as I do not want to take part with your agenda, and please Mr. Delaney, > refrain from further defamatory remarks. Defamatory is your description and your selection of it, one that doesn't surprise. I offered to you to come join the channel for the opportunity of support, and you did not. I reviewed the suggested ebuild and subsequently you did not budge. Those that do participate in the channel did pick up on this package, and rest assured they do not share your overview. The very suggestion of exploitation is frankly absurd. Just accept the fact that we have no adequate common ground upo which to operate and do me the courtesy of refraining form your inflammatory remarks that feign indignation.
Mr Delaney: Defamation is your plain intent here. We already know I did not choose to accept your offer to join IRC (due to your previous comments), and due to that I have absolutely no problems with choosing another proxy if joining IRC is now a Gentoo protocol. I have far more better important items on my agenda, then to be ordered over further hurdles in order just to volunteer. I do have a problem with people talking down to volunteers though. A person in your position already likely knows you have better choices then to further argue here. Your proper choice (as a leader or developer) should have been to simply move on and not further provoke people. Gentoo has had a past history with so-called developers being rude to volunteers. Although that has somewhat ceased over the year(s), things as of this moment, seem to be getting a little more organized rather than subsiding. I have already forwarded this thread and made additional notes to a Gentoo supervisor. As I slept on this, if for some reason the title was misleading and sounded politically provoking to the Python community (ie. stripping of python modules) that was not my intent. (Albeit I'm not a fan of python.) Mr Delaney, again I do not work for you and have no obligations to (or not required to) follow orders to join IRC. Again I beg you, please move on, I have no intentions of further inflaming your situation. You are going in the wrong direction. If your friends are encouraging you to argue or fight this further, I have to mention, those activities are illegal under most US State laws. As for me, I stand by US State's laws, and am requesting you to cease this now.
(In reply to Andrey Tikhomirov from comment #12) > Are the docs (news and readme) intentionally removed from the ebuild? > Concerning the test suite, I didn't add it just because of the failed test. Yes, because the new (now not so new) eclass has a default install of DOCS[@]. This was one of the few tips passed over to awilfox within irc as a matter of course. Leaving out a whole testsuite because it failed one test is no reason to leave out a whole testsuite. Python(ic) ebuilds are notorious for not passing their testsuites for a litany of poor reasons. The OP warrants no further input. He has said more than enough.
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.
Please do not close bugs that are not yet fixed. We are working together, Andrey and Ian and I, to add this ebuild to the tree. In fact, it is waiting on #536722 and then it should be merged. Thank you for reporting that this was required and posting the initial ebuild. Your work is appreciated. Since you no longer seem to be interested, I have removed you from the CC list. You may feel free to ignore any additional mail that this thread may generate, but again, please do not close bugs - especially as 'RESOLVED WONTFIX' - when the ebuild is being actively worked on.
Although I agree Andrew (with what you previously stated), the attempt at closing the bug was required due to the escalation and silence. There were no other better options within my authority. Although I do agree closing causes calamity within bug tracking, this closing becomes a moot point, because of further risks. If you consult with a lawyer, I'm sure they will eventually, if not immediately, agree it's a good sound option. And, it is better to wipe the plate and start with a refreshed attempt, rather than having a history reminding others of previous social incapabilities. (Had I realized I had such authority earlier I would have closed the bug earlier, but was thinking I only had the authority of a volunteer and it was up to other Developers for closing the bug. Quite obviously from the time line, it doesn't look like others were doing much to aide, if not just watching in amusement.) Closing the bug was not done with the intent to further inflame others. It was closed at that specific time as I was in the shower and (all of a sudden) realized I likely had such authority. It was the good peaceful choice as previously mentioned. As you can see, I have very little time and is quite obvious as I haven't even so-called "wikified" my last article some time ago. (In my opinion the article looks like crap but give the kids interested, as well as others; the information to move further, if they're even interested.) And yet, I acquired the time on-a-whim and spent several hours quickly scripting-up these EBuild's so I, myself and others could enjoy. Time now completely lost in one sense. Good luck. I can further explain in legal terminology the rationalization, but as somebody already mentioned (and they are likely correct on this note), I talk too much. ;-) ... but it's for good reasons.
The way you are going you may possibly have alot more explaining to do. And it won't be to me. For whatever naive and poorly thought reasons lead to your closing this, be informed, once made, it is the property of the Gentoo project of which bugzilla is merely a public interface. Despite your illusion that this is the case, this bug was never all about you. You do not own it so it is not yours to close or otherwise mis-manage. I assigned it to you initially and that was in fact a mistake on my part. since then I have held off assigning such bugs until all the required boxes are ticked. You never came anywhere near close The several hours quickly scripting-up these EBuild's resulted in what I have already described in the Comment 3. If you think that because you 'invested' several hours which in the end amounted to "Time now completely lost in one sense", do you think this is somehow something unique to you and thus tragic? Happens all the time including the most experienced gentoo developers making releases of tarballs. Tread carefully on entering another single word in this bug.
I wasn't going to kowtow to your level, Roger, and dignify your nastygrams with a response; but reading over your replies has ignited righteous indignation in me, as a Gentoo contributor and possible future developer. "Answer a fool according to his folly, or he will be wise in his own eyes." -- Proverbs 26:5 (In reply to Roger from comment #19) > Although I agree Andrew (with what you previously stated), the attempt at > closing the bug was required due to the escalation and silence. There were > no other better options within my authority. Although I do agree closing > causes calamity within bug tracking, this closing becomes a moot point, > because of further risks. If you consult with a lawyer, I'm sure they will > eventually, if not immediately, agree it's a good sound option. Is this to be construed as a legal threat? Do note that this tracker is private property of the Gentoo Foundation, incorporated as a non-profit in New Mexico and governed by US law. Since you submitted the bug here, it is now property of the Gentoo Foundation to be used as they see fit. This is also not to mention that you would not have any case for libel or defamation (according to a roommate who is studying to be a paralegal; I can't afford high-powered attorneys for insipid things like this) as nothing untrue has been said or stated here. > better to wipe the plate and start with a refreshed attempt, rather than > having a history reminding others of previous social incapabilities. (Had I > realized I had such authority earlier I would have closed the bug earlier, > but was thinking I only had the authority of a volunteer and it was up to > other Developers for closing the bug. Quite obviously from the time line, > it doesn't look like others were doing much to aide, if not just watching in > amusement.) No, it wouldn't be better. Attacking others by accusing them of having social ineptitude is a very low ad hominem attack. You are the one who has turned an anthill into a mountain. As for your authority, you have no more authority regarding this bug; you lost that when you made the conscious choice to behave in a clearly anti-social manner. This is not a matter of others being willing to work with you; such willingness has been demonstrated. Rather, this is a matter of you being unwilling to work with others. To me it looks like you are simply upset being told your work was deficient, and you deliberately ignored constructive criticism. About this being amusing: no part of this is amusing to me, nor do I think it's amusing to anyone else. I'm certainly not laughing. I don't find such puerile behaviour to be endearing or cute. > Closing the bug was not done with the intent to further inflame others.It > was closed at that specific time as I was in the shower and (all of a > sudden) realized I likely had such authority. It was the good peaceful > choice as previously mentioned. I frankly do not believe you given the way you have behaved. > As you can see, I have very little time and > is quite obvious as I haven't even so-called "wikified" my last article some > time ago. (In my opinion the article looks like crap but give the kids > interested, as well as others; the information to move further, if they're > even interested.) I apologise the wiki is not in perfect prose, handwritten in calligraphy and penned by the finest writers money could buy. The wiki open for anyone to edit, so if you wish to rewrite it in the finest phrasing as the fine wordsmith you seem to be, then feel welcome to on a weekend or some such. However, keep in mind that like you, Gentoo's developers and contributors (like myself) also have things to do; thus, things are often written in haste. After all, everyone has jobs, lives, children, families, a need to go to the shops for food, get the oil changed, get the cat to the vet, go to college full-time, and everything else imaginable; plus, people aren't paid to work on Gentoo full-time. If you want a distribution where they are, go use Ubuntu, SuSE, or RHEL. I wouldn't suggest behaving on their trackers like you did here though. > And yet, I acquired the time on-a-whim and spent several > hours quickly scripting-up these EBuild's so I, myself and others could > enjoy. Time now completely lost in one sense. You refused the suggestions of others who were only trying to help, and went up in arms when others decided to take over the work you refused to do. In response, you claimed you had no time (as if others have any more time than you do; see above). You certainly found the time to write the ebuild, then insult and denigrate us. I'm pretty sure you could have found the time to make the necessary changes (which, by the way, would have taken less time than your colossal rants). Plus, I think that time is not the only thing lost here; it's also your credibility. > Good luck. We clearly don't need luck; we already worked it out. > I can further explain in legal terminology the rationalization, but as > somebody already mentioned (and they are likely correct on this note), I > talk too much. ;-) ... but it's for good reasons. Again, is this to be construed as a legal threat? Regarding talking too much: at least we have common ground; say no more!
If you haven't noticed, I didn't waste my time reading the above. You were already advised I want nothing more to do with this bug and further including my name herein is further considered defamation. If that was not your intent above, then forgive me as I'm growing tired of a discussion leading downward, especially after already explicitly stating I had no intent to follow-up here. (However I did just briefly scan the above, just to ensure somebody wasn't peacefully debating.) If the above was to further debate legally what is transpiring here, I would suggest you take it to your lawyer.
(In reply to Ian Delaney from comment #16) > (In reply to Andrey Tikhomirov from comment #12) > > Are the docs (news and readme) intentionally removed from the ebuild? > > Concerning the test suite, I didn't add it just because of the failed test. > > Yes, because the new (now not so new) eclass has a default install of > DOCS[@]. This was one of the few tips passed over to awilfox within irc as a > matter of course. You're wrong in this case. "Default install" installs AUTHORS and README.rst, but NEWS.rst is not installed. (In reply to Andrew Wilcox (awilfox) from comment #10) > Attached is an ebuild for version 2.5, which contains bugfixes and support > for newer versions of gammu. The ebuild is also fixed up a little and has > support for running the test suite. The fixes are questionable. 1. DOCS are mentioned above. 2. You've removed python3_3 which is the stable python version and is still in the portage. You've added python3_5 which is not officially supported by python-gammu. Officially supported versions are 2.6-3.4.
3. Also you've moved build-time dependency (virtual/pkgconfig) from DEPEND to RDEPEND.
#1. It was discussed in IRC that NEWS.rst was not necessary, however, if you feel it is I can certainly add it back. #2. Python 3.5 is being added to all ebuilds that pass test suites with 3.5, as there are many projects that need no code change to support 3.5 and in this way it allows people to use the new version with their existing libraries. #3. I'm not sure what you mean; virtual/pkgconfig is listed in DEPEND in the ebuild I have attached.
(In reply to Andrew Wilcox (awilfox) from comment #25) > #1. It was discussed in IRC that NEWS.rst was not necessary, however, if you > feel it is I can certainly add it back. That's basically a changelog. I think it should be added back. > #2. Python 3.5 is being added to all ebuilds that pass test suites with 3.5, > as there are many projects that need no code change to support 3.5 and in > this way it allows people to use the new version with their existing > libraries. Ok. But what is the reason for python 3.3 removal? > #3. I'm not sure what you mean; virtual/pkgconfig is listed in DEPEND in the > ebuild I have attached. Your version: DEPEND="virtual/pkgconfig ... RDEPEND="${DEPEND}" My version: DEPEND="${RDEPEND} virtual/pkgconfig" In my version virtual/pkgconfig is only the build-time dependency. In your version it is both the build-time and the run-time dependency.
Created attachment 424098 [details] Better ebuild This ebuild adds back the DOCS for NEWS.rst. It also factors out COMMON_DEPEND for cleaner RDEPEND. Python 3.3 is no longer supported for new ebuilds so it will be not be considered for PYTHON_TARGETS for dev-python/python-gammu.
(In reply to Andrew Wilcox (awilfox) from comment #27) > It also factors out > COMMON_DEPEND for cleaner RDEPEND. That's much better, however I'd prefer to not introduce a bunch of unnecessary variables and just write like this: RDEPEND=">=app-mobilephone/gammu-1.34.0" DEPEND="${RDEPEND} virtual/pkgconfig test? ( app-mobilephone/gammu[dbi] )" > Python 3.3 is no longer supported for new ebuilds so it will be not be > considered for PYTHON_TARGETS for dev-python/python-gammu. Just to know, is this an official position of Gentoo developers? I didn't see any news on Python 3.3 removal, and according to the Gentoo wiki the state of Python 3.3 is "supported". That's why I listed 2.7, 3.3 and 3.4 in my ebuild.
DEPEND containing RDEPEND is frowned upon, hence use of the COMMON_DEPEND variable instead. For the official Python 3.3 deprecation notice, please see the gentoo-dev-announce mailing list archive: https://archives.gentoo.org/gentoo-dev-announce/message/6818ba7d0ff829800ee4faecb60c329c
(In reply to Andrew Wilcox (awilfox) from comment #29) > For the official Python 3.3 deprecation notice, please see the > gentoo-dev-announce mailing list archive: > https://archives.gentoo.org/gentoo-dev-announce/message/ > 6818ba7d0ff829800ee4faecb60c329c Thank you, got it. > DEPEND containing RDEPEND is frowned upon, hence use of the COMMON_DEPEND > variable instead. Why? Is this a personal point of view or is there any official notice too?
(In reply to Roger from comment #22) > If you haven't noticed, I didn't waste my time reading the above. > Well how could we? Are we looking over your shoulder? This is self righteous tripe, otherwise termed trolling. > You were already advised I want nothing more to do with this bug and further > including my name herein is further considered defamation. You were already advised to "Tread carefully on entering another single word in this bug". Yet more advice shunned as uninformed drivvle based on the illusion the mechanics of this bug and gentoo are centred around you. > If that was not > your intent above, then forgive me as I'm growing tired of a discussion YOU'RE tired of discussion! . and us ? > leading downward, especially after already explicitly stating I had no > intent to follow-up here. (However I did just briefly scan the above, just > to ensure somebody wasn't peacefully debating.) > > If the above was to further debate legally what is transpiring here, I would > suggest you take it to your lawyer. You have a thing about law and lawyers. We have an authoritative body that exists in order to deal with the form of unambiguous abuse which you have delivered in spades here. It is hight time this was moved onto the forum / body where your communications are to be dealt with. They are in fact the closest thing to lawyers around here. And relax, you won't need a lawyer, this is not corporate America. This is something else. Corporate America is merely one cog in the wheel of the global society, yet once again it is deemed the ultimate model of law and justice. (It never was) NEVER have I seen such a unanimous reaction of community outrage towards a single user that compares to what I have witnessed of you and your manner of conduct within my time in gentoo.
(In reply to Andrey Tikhomirov from comment #30) > (In reply to Andrew Wilcox (awilfox) from comment #29) > > For the official Python 3.3 deprecation notice, please see the > > gentoo-dev-announce mailing list archive: > > https://archives.gentoo.org/gentoo-dev-announce/message/ > > 6818ba7d0ff829800ee4faecb60c329c > Thank you, got it. > > > DEPEND containing RDEPEND is frowned upon, hence use of the COMMON_DEPEND > > variable instead. > Why? Is this a personal point of view or is there any official notice too? Andrey; so far so good, however remember this is a form of collaboration. You tend to say I'd prefer as if yours ought take precedence. Neither preference ought take precedence. There are always a number of 'right' or acceptable ways of writing code in ebuilds. The final result is often decided by convention based on popularity in the developer community and for no other reason. It is quite arbitrary. Note that awilfox is bending over backwards to accommodate you, and I am pleased . I am pleased with both of you, and that you show a real interest in the ebuild writing for this package. re DEPEND RDEPEND; the setting of DEPEND="${RDEPEND}" is often plain wrong and is a throwback from pre EAPI 4 when both vars were demanded by PMS to have values. Now, the modern EAPIs allow them to be deleted entirely from an ebuild if they require no value. I AM a python dev and I have removed DEPEND="${RDEPEND}" over a long time from dozens of ebuilds. It was used because it was both convenient and it worked. afaiac having packages defined in DEPEND that are not build deps is plain wrong and requires correction. Oddly most other devs appear content to perpetuate the mistake. Not I.
Mr.Ian Delaney: You were advised to cease discussing this issue with myself. (If you would simply open your eyes, some of us have much more important things to do then to debate an issue leading nowhere.) As you can see it took three times to advise you cease and quit; and I thought you did get the hint upon the third time. Now I have advised you a fourth time. Readers here were also already advised to open a new bug for good reasons.
(In reply to Ian Delaney from comment #32) > re DEPEND RDEPEND; > the setting of DEPEND="${RDEPEND}" is often plain wrong and is a throwback > from pre EAPI 4 when both vars were demanded by PMS to have values. Now, > the modern EAPIs allow them to be deleted entirely from an ebuild if they > require no value. Sorry, but this is not correct. Both the DEPEND and the RDEPEND variable are optional in all EAPIs. PMS reference: https://projects.gentoo.org/pms/6/pms.html#x1-670007.3 (In reply to Andrey Tikhomirov from comment #28) > That's much better, however I'd prefer to not introduce a bunch of > unnecessary variables and just write like this: > > RDEPEND=">=app-mobilephone/gammu-1.34.0" > DEPEND="${RDEPEND} > virtual/pkgconfig > test? ( app-mobilephone/gammu[dbi] )" +1 This is perfectly valid code, and there is no need to pollute the environment with a COMMON_DEPEND variable which would have a value identical to RDEPEND.
This has been in the tree for some time now. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3f265d8d81c6d1c58888391ae449077feb9c70b
