Re: [gentoo-user] terminal spreadsheet - sc fork
On Sun, Nov 02, 2014 at 08:16:30PM -0300, Andrés Martinelli wrote Hello there!! I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Thanks! git newbie alert. I'm not a programmer. I Googled for instructions, built git, cloned the scim repo, read the instructions, changed one line in Makefile... prefix=/home/waltdnes/.local ...so that if things went wrong, it wouldn't clobber root. I ran make. I got the familiar gcc screens of text output. But there's nothing installed in ~/.local. Should there be a make install command somewhere? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] terminal spreadsheet - sc fork
Hello! Could you please attach the complete make output?? El 04/11/2014, a las 08:36, Walter Dnes waltd...@waltdnes.org escribió: On Sun, Nov 02, 2014 at 08:16:30PM -0300, Andrés Martinelli wrote Hello there!! I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Thanks! git newbie alert. I'm not a programmer. I Googled for instructions, built git, cloned the scim repo, read the instructions, changed one line in Makefile... prefix=/home/waltdnes/.local ...so that if things went wrong, it wouldn't clobber root. I ran make. I got the familiar gcc screens of text output. But there's nothing installed in ~/.local. Should there be a make install command somewhere? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] Bounces on gentoo-user
Hi Are any of you guys getting bounces from list? Does it mean that my message didn't go to the list? Or it didn't go to one of the recipients on the list? Or is this some other error? I've getting these every once in a while for few weeks now. Any actions required? Below you'll find the bounced message attached. -- Matti Begin forwarded message: From: gentoo-user+bounces-159671-matti.nykyri=iki...@lists.gentoo.org Date: November 4, 2014 at 13:36:34 GMT+2 To: undisclosed-recipients:; This message has no content.
Re: [gentoo-user] terminal spreadsheet - sc fork
On 11/04/2014 06:36 AM, Walter Dnes wrote: On Sun, Nov 02, 2014 at 08:16:30PM -0300, Andrés Martinelli wrote Hello there!! I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Thanks! git newbie alert. I'm not a programmer. I Googled for instructions, built git, cloned the scim repo, read the instructions, changed one line in Makefile... prefix=/home/waltdnes/.local ...so that if things went wrong, it wouldn't clobber root. I ran make. I got the familiar gcc screens of text output. But there's nothing installed in ~/.local. Should there be a make install command somewhere? There's actually no 'install' command in the Makefile. You should be able to run it by executing the 'scim' binary in src/. It doesn't create any of its own libraries or anything, so you should be able to run the standalone binary anywhere without needing to install; if you would like to install it to your ~/.local, a simple cp src/scim ~/.local/bin/scim should suffice. Alec
Re: [gentoo-user] terminal spreadsheet - sc fork
On 11/02/2014 06:16 PM, Andrés Martinelli wrote: Hello there!! I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Thanks! -- Andrés M. If I can offer some constructive criticism based on my short experience helping Walter: * Your build process could use some work; you shouldn't be hard-coding variable values like LN and CC in a Makefile, these are handled by make. Your Makefile could be shortened by ~150 lines by relying on built-in rules and using some built-in make expressions to list your source files as well. * A bunch of your .c or .h files are marked as executable... why? * No install command. Not really a huge deal as only one important file is produced (src/scim), but would be nice to have If you're unfamiliar with make and have no immediate plans to switch to either the autotools or cmake, I would be more than willing to make some changes to your Makefile and open a pull request. If you would like to email me personally with questions about make, feel free to do that as well. There are a couple things I saw in the code as well: * system(echo -n 'Press enter to return.') * Lot of ignored return values on functions that you should check, like write() and fgets() If these were in the sc code and you know about them but just haven't gotten to fixing them yet, no worries. Alec
Re: [gentoo-user] terminal spreadsheet - sc fork
Hello! Please feel free to modify the Makefile and open a pull request! What you mention about return values not checked, I believe they are part of sc, but please specify them if you can, since there's still a lot of sc for modify. Thanks! Andrés M. 2014-11-04 10:23 GMT-03:00 Alec Ten Harmsel a...@alectenharmsel.com: On 11/02/2014 06:16 PM, Andrés Martinelli wrote: Hello there!! I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Thanks! -- Andrés M. If I can offer some constructive criticism based on my short experience helping Walter: * Your build process could use some work; you shouldn't be hard-coding variable values like LN and CC in a Makefile, these are handled by make. Your Makefile could be shortened by ~150 lines by relying on built-in rules and using some built-in make expressions to list your source files as well. * A bunch of your .c or .h files are marked as executable... why? * No install command. Not really a huge deal as only one important file is produced (src/scim), but would be nice to have If you're unfamiliar with make and have no immediate plans to switch to either the autotools or cmake, I would be more than willing to make some changes to your Makefile and open a pull request. If you would like to email me personally with questions about make, feel free to do that as well. There are a couple things I saw in the code as well: * system(echo -n 'Press enter to return.') * Lot of ignored return values on functions that you should check, like write() and fgets() If these were in the sc code and you know about them but just haven't gotten to fixing them yet, no worries. Alec -- Andrés Martinelli
[gentoo-user] Nagios testers wanted
We're collecting more and more Nagios bugs every day, and we've been stuck on the 3.x series for a while even though upstream has moved to 4.x. The main problem as far as I can see is that nagios-plugins is a big mess, and it's hard for any one person to test. (We use it at work, but there's no ipv6 there, or ldap, or snmp, or game servers...) I've rewritten the nagios, nagios-core, and nagios-plugins ebuilds, and will eventually ask permission to commit them to ~arch. That will rip the band-aid off, so to speak, after which I can work on addressing the existing bugs. But before I do, I'd like to have a few people test it and tell me it works. So if anyone is using nagios, please give these a try. net-analyzer/nagios and net-analyzer/nagios-core: https://bugs.gentoo.org/show_bug.cgi?id=485756 nagios-plugins: https://bugs.gentoo.org/show_bug.cgi?id=522946 If you see any problems, just comment on the bug or email me or whatever. I am actually using these ebuilds, so they won't delete your system32 or anything. If there are bugs they're likely in one of the parts I don't use. I'm also pretty sure that most of the open bugs on b.g.o still apply, but this version at least shouldn't be any worse than the one in the tree.
Re: [gentoo-user] KDE monitor configuration disappeared!
On Sun, Nov 2, 2014 at 6:38 AM, Nikos Chantziaras rea...@gmail.com wrote: What happened? Where are the KDE settings for my monitor? from kde-misc/kscreen postinstall: LOG: postinst Disable the old screen management: # qdbus org.kde.kded /kded org.kde.kded.unloadModule randrmonitor # qdbus org.kde.kded /kded org.kde.kded.setModuleAutoloading randrmonitor false Enable the kded module for the kscreen based screen management: # qdbus org.kde.kded /kded org.kde.kded.loadModule kscreen Now simply (un-)plugging displays should enable/disable them, while the last state is remembered. Does that correct your issue? -- Douglas J Hunley (doug.hun...@gmail.com) Twitter: @hunleyd Web: about.me/douglas_hunley G+: http://google.com/+DouglasHunley
Re: [gentoo-user] terminal spreadsheet - sc fork
Hi, I'm interested in this project, so I have some considerations: I found that already exist a project called scim (wikipedia.org/wiki/Smart_Common_Input_Method) so you might have problems in the future related to the name. And second, something I care, is about file formats. I never used sc, so I don't know wich file format it saves. But I would like to see SCIM (if it doesn't already) saving files in a way I can open in other softwares. Wikipedia showed me that CSV is the most accepted format, and it is very simple. Regards -- Henrique Lengler https://gitorious.org/~henriqueleng Skype: No way! That's nonfree (freedom-denying) software. Wanna talk with me? Ask me for my TOX ID.
Re: [gentoo-user] terminal spreadsheet - sc fork
Yes. Saving in CSV format is the next to be cleaned from sc and reimplemented! 2014-11-04 13:30 GMT-03:00 Henrique Lengler henriquel...@openmailbox.org: Hi, I'm interested in this project, so I have some considerations: I found that already exist a project called scim (wikipedia.org/wiki/Smart_Common_Input_Method) so you might have problems in the future related to the name. And second, something I care, is about file formats. I never used sc, so I don't know wich file format it saves. But I would like to see SCIM (if it doesn't already) saving files in a way I can open in other softwares. Wikipedia showed me that CSV is the most accepted format, and it is very simple. Regards -- Henrique Lengler https://gitorious.org/~henriqueleng Skype: No way! That's nonfree (freedom-denying) software. Wanna talk with me? Ask me for my TOX ID. -- Andrés Martinelli
[gentoo-user] using python 2.7
RIP python 3 how do I get rid of it
[gentoo-user] Re: using python 2.7
On 2014-11-04, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it uninstall it -- Grant Edwards grant.b.edwardsYow! A dwarf is passing out at somewhere in Detroit! gmail.com
Re: [gentoo-user] using python 2.7
On Tue, Nov 4, 2014 at 10:44 AM, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it It's possible that you can't. Some (or many) packages could depend on Python 2.7 because they don't work with Python 3.x. You can check that with: equery depends dev-lang/python:2.7 In my main system (full GNOME 3 desktop), 174 packages depend on Python 2.7. Some of them probably can be made to work only with Python 3.x, but I'm willing to bet that the majority doesn't. Maybe in the future, but I don't think it will be possible for at least a few years. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
[gentoo-user] The end of Herds
Hello, If you follog gentoo-dev you can see Rich's summary interpretation (which I do agree with) posted at the bottom of this thread. Recently I was asked to help clean up some of the Java bugs. OK, as a non-maintainer I agreed. I went through over 100 java bugs, mostly pre 2010, as to make a dent in the backlog of ~500 java bugs that would probably be the easiest to clean up. Sure enough, there were only a few that were still relevant (Hm) So I proposed, to one of the Java Herd members we blast out a few emails notifying everyone that if folks did not reaffrim these (very old) java bugs, they would be mass-closed. If you look at those (old bugs) most would agree with my assessment. However, I listed a few as blatant examples that needed to be closed. It seems there is no closer for java bugs. Nobody around with the authority (will?) to close any old Java bugs. The herd is descimated, on furlog or just burnt out and non-responsive. So all of my work and effort was for nothing. Over the years, I have made at least 3 attemps to use java on gentoo; all resulted in using other linix distros. For me, java is a reality that cannot be wished away. What I have learn in the last few months is that Java on Gentoo is alive and properous; folks with Java ebuilds just do not bother with getting them into Gentoo because of the morass of apathy the gentoo java hers has become. So now is the time for folks to read and post to gentoo-dev on thread: : Deprecating and killing the concept of herds if you have any issues with herds being removed from Gentoo. Ideas on how to best organize bug_cleaning is also welcome. I think there will be an uptake in proxy-maintainers, if the gentoo-dev club is sincere about treating these proxy maintainers with respect and mutual professionalism. I think the concept of Projects will persist, but herds have to become active and request to become Projects as defined on the gentoo wiki or they will be erased. Like many others, I have been burned in the past with trying to get directly involved with Gentoo (been here since 2004). That's all water under the bridge. So I am tip_toeing behind the scenes willing to be a grunt and clean up some of the java mess, participate in clustering and contribute to the science project. We'll see just how long it lasts before I get bitch_slapped like my previous attempts That's why I named by current /usr/local/portage jackslap. We shall see what happens. I see the enabling of user patches directly into ebuilds in the tree (EAPI 6) and the cleansing of the irresponsible amongst the herds with exclusive control over bugs as a very positive sign that the gentoo dev community is one again dedicated to making Gentoo an excellent platform. Whatever your experiences have been, I hope you read, post and give direct participation in Gentoo your deepest consideration. James snip My (rich) proposal: For the steady state: 1. For the maintainer tag in metadata, have a type attribute that can be developer, project, or proxy. 2. Add a contacts tag in metadata that takes an email. 3. Package without maintainers (individuals or projects - regardless of presence of aliases) get assigned to maintainer-needed and get treecleaned as usual. I'm also fine with normalizing this and just switching to a contact tag that can have a type of developer, project, proxy, or contact. That is a bigger change. However, it would probably simplify scripting and be a bit cleaner for the long-term. For the transition to the steady state: a. We generate a list of all current herds and email their aliases to see if they want to be converted to a non-maintainer alias, or be disbanded entirely. One reply to the email is enough to keep the alias around, no replies means retirement. b. Anybody in Gentoo can start a project already by following GLEP 39. It is encouraged for these projects to take over existing aliases where they feel it is appropriate. There is no need for all aliases to have a project - just ones that want some kind of structure (ie this is strictly voluntary). When this is done the project will remove the herd from metadata and add the project alias as a maintainer with the agreed-upon tagging. c. We generate a list of all current packages that do not have a maintainer (either one or more individuals or projects (NOT herds)). That gets posted so that individuals can claim them. I suggest not doing the usual treecleaning email since there could be a LOT of them. Or we could do it herd-by-herd over time to ease the load. d. We remove all herds from the existing packages. Where aliases were kept in (a) above they are converted to aliases with appropriate tagging. If no maintainer exists the package is handled per the result of (c). Comments, alternatives, etc?
Re: [gentoo-user] using python 2.7
Sorry for the dumb message, I figured out how to use eselect python (the syntax is a little weird and not very well documented.) This fixed my issue as near as I can tell. On 11/04/14 17:16, Canek Peláez Valdés wrote: On Tue, Nov 4, 2014 at 10:44 AM, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it It's possible that you can't. Some (or many) packages could depend on Python 2.7 because they don't work with Python 3.x. You can check that with: equery depends dev-lang/python:2.7 In my main system (full GNOME 3 desktop), 174 packages depend on Python 2.7. Some of them probably can be made to work only with Python 3.x, but I'm willing to bet that the majority doesn't. Maybe in the future, but I don't think it will be possible for at least a few years. Regards.
Re: [gentoo-user] Re: using python 2.7
oh thanks good idea On 11/04/14 17:08, Grant Edwards wrote: On 2014-11-04, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it uninstall it
Re: [gentoo-user] using python 2.7
Paige Thompson wrote: Sorry for the dumb message, I figured out how to use eselect python (the syntax is a little weird and not very well documented.) This fixed my issue as near as I can tell. For future reference, make sure nothing depends on whatever version of python you want to remove before you remove it. If you don't, it could get very interesting in a really bad way. Python is one of those packages that you have to watch out for gotchas on. It sometimes comes back and bites you. Dale :-) :-)
Re: [gentoo-user] using python 2.7
On 11/05/14 00:01, Dale wrote: Paige Thompson wrote: Sorry for the dumb message, I figured out how to use eselect python (the syntax is a little weird and not very well documented.) This fixed my issue as near as I can tell. For future reference, make sure nothing depends on whatever version of python you want to remove before you remove it. If you don't, it could get very interesting in a really bad way. Python is one of those packages that you have to watch out for gotchas on. It sometimes comes back and bites you. Dale :-) :-) I don't think I removed it, just figured out how to change it with eselect. Here's what I mean: laptop#eselect python Usage: eselect python action options Standard actions: help Display help text usageDisplay usage information version Display version information Extra actions: list List installed Python interpreters --python2 List installed Python 2 interpreters --python3 List installed Python 3 interpreters set target Set main active Python interpreter --python2 Set active Python 2 interpreter without setting of main active Python interpreter if it is not set to Python 2 --python3 Set active Python 3 interpreter without setting of main active Python interpreter if it is not set to Python 3 show Show main active Python interpreter --ABI Show Python ABI in format of PYTHON_ABI variable --python2 Show active Python 2 interpreter --python3 Show active Python 3 interpreter update Switch to the most recent CPython interpreter --if-unsetDo not override existing implementation --ignore SLOT Ignore SLOT when setting symlinks --python2 Set active Python 2 interpreter without setting of main active Python interpreter if it is not set to Python 2 --python3 Set active Python 3 interpreter without setting of main active Python interpreter if it is not set to Python 3 laptop# From this information I wouldn't expect : laptop#eselect python set python2.7 laptop# To have been correct... since it lists --python2 and --python3 below set in the help but: laptop#python --version Python 2.7.7 laptop# It does, and thats pretty much all I needed. No need to unmerge anything but the thought did cross my mind and if I were going to I would've made a binpkg first. Thanks, -Paige
[gentoo-user] Re: KDE monitor configuration disappeared!
On 04/11/14 18:28, Douglas J Hunley wrote: On Sun, Nov 2, 2014 at 6:38 AM, Nikos Chantziaras rea...@gmail.com wrote: What happened? Where are the KDE settings for my monitor? from kde-misc/kscreen postinstall: LOG: postinst Disable the old screen management: # qdbus org.kde.kded /kded org.kde.kded.unloadModule randrmonitor # qdbus org.kde.kded /kded org.kde.kded.setModuleAutoloading randrmonitor false Enable the kded module for the kscreen based screen management: # qdbus org.kde.kded /kded org.kde.kded.loadModule kscreen Now simply (un-)plugging displays should enable/disable them, while the last state is remembered. Does that correct your issue? Already solved on the KDE mailing list. The problem was that the controls don't appear until you click on the gray box that represents your monitor. I wouldn't have found that out in a million years. So it was just bad and confusing GUI design. The controls once, they appear, don't actually work (meaning the GUI elements are broken,) but that's another issue. Bottom line: not impressed is putting it mildly :-/
Re: [gentoo-user] The end of Herds
On 11/04/2014 03:13 PM, James wrote: Hello, If you follog gentoo-dev you can see Rich's summary interpretation (which I do agree with) posted at the bottom of this thread. Recently I was asked to help clean up some of the Java bugs. ... So I proposed, to one of the Java Herd members we blast out a few emails notifying everyone that if folks did not reaffrim these (very old) java bugs, they would be mass-closed. If you look at those (old bugs) most would agree with my assessment. However, I listed a few as blatant examples that needed to be closed. It seems there is no closer for java bugs. Nobody around with the authority (will?) to close any old Java bugs. The herd is descimated, on furlog or just burnt out and non-responsive. So all of my work and effort was for nothing. This is exactly the problem we're trying to solve (and I'm sorry to hear it, many of us have been in a similar position). Herds as a group of developers have always been very poorly-defined. As I've heard it repeated, originally packages were supposed to belong to herds, and developers were supposed to belong to projects. But herds almost always had an associated email address, so people who cared about groups of packages would add themselves to the herd to get on the email alias. But projects were there all along, too, and we wound up with a bunch of people in herds who were never going to fix bugs and some smaller number of people in projects (who might fix bugs) that weren't in the herds. It was all very confusing, so the council is voting to replace them with something that makes sense. Basically we want to fix the situation we have right now where it's impossible to tell who is actually working on Java packages. Once herds are replaced, you should be able to get an accurate reading out of metadata.xml and/or the wiki page. (And I'm sure anyone actually working on Java would appreciate your help.) For you personally, I would try to find one or two people on the Java project (actually working on Java right now) and explain to them that you'd like to help close old bugs. Then you can CC or reassign the Java bugs to those people. When bug mail gets sent to a herd or project, it's too easy to say screw it, someone else will deal with it. Bugs addressed to me personally get attention much sooner, even if only for psychological reasons. So reassigning those to a single person might prompt action sooner than you'd get otherwise.
Re: [gentoo-user] terminal spreadsheet - sc fork
On Tue, Nov 04, 2014 at 07:57:01AM -0500, Alec Ten Harmsel wrote There's actually no 'install' command in the Makefile. You should be able to run it by executing the 'scim' binary in src/. It doesn't create any of its own libraries or anything, so you should be able to run the standalone binary anywhere without needing to install; if you would like to install it to your ~/.local, a simple cp src/scim ~/.local/bin/scim should suffice. Actually, what I did was... cd ~/bin ln -s ../scim/src/scim scim This way, I'll always be invoking the latest version. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] using python 2.7
Paige Thompson wrote: I don't think I removed it, just figured out how to change it with eselect. Here's what I mean: laptop#eselect python Usage: eselect python action options Standard actions: help Display help text usageDisplay usage information version Display version information Extra actions: list List installed Python interpreters --python2 List installed Python 2 interpreters --python3 List installed Python 3 interpreters set target Set main active Python interpreter --python2 Set active Python 2 interpreter without setting of main active Python interpreter if it is not set to Python 2 --python3 Set active Python 3 interpreter without setting of main active Python interpreter if it is not set to Python 3 show Show main active Python interpreter --ABI Show Python ABI in format of PYTHON_ABI variable --python2 Show active Python 2 interpreter --python3 Show active Python 3 interpreter update Switch to the most recent CPython interpreter --if-unsetDo not override existing implementation --ignore SLOT Ignore SLOT when setting symlinks --python2 Set active Python 2 interpreter without setting of main active Python interpreter if it is not set to Python 2 --python3 Set active Python 3 interpreter without setting of main active Python interpreter if it is not set to Python 3 laptop# From this information I wouldn't expect : laptop#eselect python set python2.7 laptop# To have been correct... since it lists --python2 and --python3 below set in the help but: laptop#python --version Python 2.7.7 laptop# It does, and thats pretty much all I needed. No need to unmerge anything but the thought did cross my mind and if I were going to I would've made a binpkg first. Thanks, -Paige You may want to look into the buildpkg option in make.conf. It builds them automatically for you as you emerge things. I've had a close call or two so I have had that set for many years now. If you do set that, remember to use eclean-pkg on occasion if you start using a lot of hard drive space. You also may want to look into eclean-dist too. ;-) Dale :-) :-)
Re: [gentoo-user] terminal spreadsheet - sc fork
On Tue, Nov 04, 2014 at 08:39:56AM -0300, Andrés Martinelli wrote Hello! Could you please attach the complete make output?? As others have pointed out, the scim executable exists in scim/src, and it does run. Anyhow, here is the gzipped output of make /dev/shm/makelog.txt 21 -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications makelog.txt.gz Description: Binary data
Re: [gentoo-user] using python 2.7
On Tue, Nov 04 2014, Canek Peláez Valdés wrote: On Tue, Nov 4, 2014 at 10:44 AM, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it It's possible that you can't. Some (or many) packages could depend on Python 2.7 because they don't work with Python 3.x. You can check that with: equery depends dev-lang/python:2.7 In my main system (full GNOME 3 desktop), 174 packages depend on Python 2.7. Some of them probably can be made to work only with Python 3.x, but I'm willing to bet that the majority doesn't. Maybe in the future, but I don't think it will be possible for at least a few years. Regards. I believe the OP wants to keep 2.7 and ditch 3. allan
Re: [gentoo-user] using python 2.7
On Tue, Nov 4, 2014 at 7:20 PM, gottl...@nyu.edu wrote: On Tue, Nov 04 2014, Canek Peláez Valdés wrote: On Tue, Nov 4, 2014 at 10:44 AM, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it It's possible that you can't. Some (or many) packages could depend on Python 2.7 because they don't work with Python 3.x. You can check that with: equery depends dev-lang/python:2.7 In my main system (full GNOME 3 desktop), 174 packages depend on Python 2.7. Some of them probably can be made to work only with Python 3.x, but I'm willing to bet that the majority doesn't. Maybe in the future, but I don't think it will be possible for at least a few years. Regards. I believe the OP wants to keep 2.7 and ditch 3. Right. Even so, that's going to be even more difficult as long as more and more packages switch to Python 3. Which is happening really slowly, but happening nonetheless. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] using python 2.7
On 11/05/14 01:32, Canek Peláez Valdés wrote: On Tue, Nov 4, 2014 at 7:20 PM, gottl...@nyu.edu wrote: On Tue, Nov 04 2014, Canek Peláez Valdés wrote: On Tue, Nov 4, 2014 at 10:44 AM, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it It's possible that you can't. Some (or many) packages could depend on Python 2.7 because they don't work with Python 3.x. You can check that with: equery depends dev-lang/python:2.7 In my main system (full GNOME 3 desktop), 174 packages depend on Python 2.7. Some of them probably can be made to work only with Python 3.x, but I'm willing to bet that the majority doesn't. Maybe in the future, but I don't think it will be possible for at least a few years. Regards. I believe the OP wants to keep 2.7 and ditch 3. Right. Even so, that's going to be even more difficult as long as more and more packages switch to Python 3. Which is happening really slowly, but happening nonetheless. Regards. Yeah right.. this is not going to change any faster than people are going to abandon dual homing ipv4 and ipv6 let alone ipv4 all together. Absolutely hopeless, some people just cannot be convinced (shouldn't be allowed to use a computer) a lot of people simply don't have the time. I foresee python being dual stack indefinitely without cross compatibility. When the day comes and you prove me wrong, I owe you $20. But... the need for python 2.7 has to be COMPLETELY eliminated and just saying RIP Python2.7 or gtfo doesn't count coming from any source. -Paige
Re: [gentoo-user] using python 2.7
On 11/05/14 01:32, Canek Peláez Valdés wrote: On Tue, Nov 4, 2014 at 7:20 PM, gottl...@nyu.edu wrote: On Tue, Nov 04 2014, Canek Peláez Valdés wrote: On Tue, Nov 4, 2014 at 10:44 AM, Paige Thompson erra...@yourstruly.sx wrote: RIP python 3 how do I get rid of it It's possible that you can't. Some (or many) packages could depend on Python 2.7 because they don't work with Python 3.x. You can check that with: equery depends dev-lang/python:2.7 In my main system (full GNOME 3 desktop), 174 packages depend on Python 2.7. Some of them probably can be made to work only with Python 3.x, but I'm willing to bet that the majority doesn't. Maybe in the future, but I don't think it will be possible for at least a few years. Regards. I believe the OP wants to keep 2.7 and ditch 3. Right. Even so, that's going to be even more difficult as long as more and more packages switch to Python 3. Which is happening really slowly, but happening nonetheless. Regards. Also I should merely point out... I didn't remove it I just figured out how to switch to 2.7 as the default. Also I do occasionally use sandbox (virtualenv) but stuff breaks.
Re: [gentoo-user] using python 2.7
141105 Paige Thompson wrote: I didn't remove it I just figured out how to switch to 2.7 as the default. Also I do occasionally use sandbox (virtualenv) but stuff breaks. You sound new to Gentoo : if so, welcome. One area you need to understand is slots : look around the dox, then ask again if you need more help. This is a friendly place, but mb you tripped over the doorstep (smile). -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] using python 2.7
On Nov 5, 2014, at 2:01, Dale rdalek1...@gmail.com wrote: Paige Thompson wrote: Sorry for the dumb message, I figured out how to use eselect python (the syntax is a little weird and not very well documented.) This fixed my issue as near as I can tell. For future reference, make sure nothing depends on whatever version of python you want to remove before you remove it. If you don't, it could get very interesting in a really bad way. Python is one of those packages that you have to watch out for gotchas on. It sometimes comes back and bites you. Luckily it is not poisonous :) -- -Matti
