[gentoo-ppc-dev] Is PPC support being dropped for Gentoo?
I've just --synced on my PPC box (Kurobox HG) and now there is no PPC profile directory: /usr/portage/profiles/default-linux/ppc/ but the profiles for the other various CPU types are present. Did PPC get dropped or become something optional that I need to enable somehow? I've googled and searched the PPC FAQ and forums but no mention of the removal of that directory tree. Sorry if this is a well-known issue. -Jeff
Re: [gentoo-ppc-dev] Is PPC support being dropped for Gentoo?
Jeff Rush wrote: I've just --synced on my PPC box (Kurobox HG) and now there is no PPC profile directory: /usr/portage/profiles/default-linux/ppc/ but the profiles for the other various CPU types are present. Did PPC get dropped or become something optional that I need to enable somehow? I've googled and searched the PPC FAQ and forums but no mention of the removal of that directory tree. Sorry if this is a well-known issue. -Jef It's not an issue and support isn't being dropped. Those profiles were old and deprecated. Use the tool eselect profile --list to display the profiles that are compatible with your machine. As far as I know, the current latest profile is default/linux/powerpc/ppc32/2008.0 for ppc32. Hope that helps, -Joe
[gentoo-dev] Re: 2009 Council Elections
Dale rdalek1...@gmail.com posted 4a480ec2.7030...@gmail.com, excerpted below, on Sun, 28 Jun 2009 19:45:54 -0500: It's also what I hate about our government here. From the context, I understood here /not/ to mean Gentoo. FYI, while it's tempting to make comments paralleling various wider world political happenings, it's generally not wanted on this list, lest even /more arguments start, with these being /entirely/ off topic. So please do steer clear of such parallels in the future. If you have something about Gentoo to add to the conversation, fine (tho do remember it's a Gentoo dev list and those of us who are not Gentoo devs are guests), just keep the comments Gentoo related and don't stray elsewhere, /particularly/ politics (or religion... etc), even if it's as parallels or analogies. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] 2009 Council Elections
On Sun, 2009-06-28 at 23:53 +0100, Roy Bamford wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.06.28 23:14, Ferris McCormick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 28 Jun 2009 16:40:00 +0100 Roy Bamford neddyseag...@gentoo.org wrote: [snip] What if an entire meeting and therefore any votes were staffed by entirely by non gentoo developer proxies? Unlikely, but perfectly possible under GLEP39. Would Gentoo feel bound by decisions that such a meeting reached? Currently, yes. Oh. Don't talk about 'common sense' GLEP39 does not mention it, so it doesn't count ... and its much rarer than you may think. It's worse than that. I think 'common sense' is subjective and thus not a useful method of interpretation. Even if one disagrees with that statement, 'common sense' is certainly cultural (do you suppose common sense in N. Korea is the same as common sense in S. Korea? I don't think so at all.). So, 'common sense' for Gentoo still cannot be all that useful a method of interpretation, because Gentoo most certainly is multi-cultural. Lastly, as a trustee and partly legally responsible for decisions made on behalf of Gentoo, I am uneasy with the concept of non developers making those decisions. Now reread my 'what if' above with that liability in mind. It's not that bad. as long as council meets every two weeks, any decision can be undone within 2 weeks (and council can always hold a special session. Although under your 'what if' scenario, we have a council which does not take its responsibilities very seriously.) Note: Other trustees may have a different view of the world I'm sure we all have different views of the world. But I generally agree with what you have written here, I think. You agree that common sense can't be used and admit that a corner case exists that would in effect have the trustees pointing out to the council that they had made an error of judgement and need to reverse a decision that the last meeting made. I would prefer never to have to go there. I meant that the council can reverse itself. I did not intend to imply any trustee action --- I intended to imply that council should be able to see when they had made an error of judgment. I do not agree that an all proxy council meeting shows that the council does not take its responsibilities very seriously, rather that real life has hit everyone at the same time and they have appointed proxies. GLEP39 does not even set a limit on the maximum number of council members who may be proxied at any single meeting. Fair enough. But I don't think such a meeting should ever happen. Surely, council can reschedule a meeting if they see this coming up. :) As I have already said, I'm against the idea of proxies altogether. We should amend glep39 to remove proxies and ensure that council members are drawn from the developer community. Of course, that does not eliminate the possibility of the trustees pointing out to the council that they need to reverse a decision but it does ensure that decisions are made only by council members who are Gentoo developers. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkpH9GAACgkQTE4/y7nJvavFPwCguehKyVF6Ep294VWSHB14Dlq/ mKIAmwWe9bHlEHwYayljnsisUW8p3VsK =Npgw -END PGP SIGNATURE- Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2009 Council Elections
On Sun, 2009-06-28 at 18:12 -0500, Dale wrote: Roy Bamford wrote: You agree that common sense can't be used and admit that a corner case exists that would in effect have the trustees pointing out to the council that they had made an error of judgement and need to reverse a decision that the last meeting made. I would prefer never to have to go there. I do not agree that an all proxy council meeting shows that the council does not take its responsibilities very seriously, rather that real life has hit everyone at the same time and they have appointed proxies. GLEP39 does not even set a limit on the maximum number of council members who may be proxied at any single meeting. As I have already said, I'm against the idea of proxies altogether. We should amend glep39 to remove proxies and ensure that council members are drawn from the developer community. Of course, that does not eliminate the possibility of the trustees pointing out to the council that they need to reverse a decision but it does ensure that decisions are made only by council members who are Gentoo developers. I'm just picking a random message so no fingers being pointed here. As a long time Gentoo user, I have to ask. Why is that EVERYONE on the council must be there or have someone there to represent them? Would Gentoo come to a end if one person or even two people were not present? All that's required is a quorum (4 out of 7) to hold a meeting. I do agree that if a proxy is going to be used, they should be a developer. If it is not that way now, it should be changed. I been using Gentoo for years and wouldn't even consider serving as a proxy. I would certainly not want to be a tie breaker on a vote. As a American that sees his own country's government getting out of control, never count on common sense. Elected people rarely have any. If they do during the election, it disappears after taking their position. I think the vast majority of people here have seen that over the years. My $0.02 worth. Dale :-) :-) Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] EAPI Feature Request Bugs
Following discussion on the PMS list about how we can keep track of new EAPI feature requests [1], and from the Council's discussions on the development model for new EAPIs: For 'Future EAPI' bugs, please do the following: * Try to make sure there's a single bug describing the feature, rather than co-opting an existing bug report. * Set 'Product' to 'Gentoo Hosted Projects' and 'Component' to 'PMS / EAPI'. * Set the 'Status Whiteboard' field to 'unclassified'. * Mark the bug as blocking 174380. Every now and again, the PMS team will go through and change the 'unclassified's to one of: * feasible-for-next-eapi, if we think this is something that's probably doable in the next EAPI (basically if it's not going to be insanely difficult to implement in Portage). * distant-future-eapi, if it's probably not an easy feature, or if there's not enough detail on how the change will work. These are merely helpful indicators, and they'll get changed based upon feedback from Portage people etc. When we start work on the next EAPI, we'll change the bugs in the initial list to be 'active-consideration-for-eapi-4'. As the process goes on and the list gets narrowed down by Council and Portage feedback, we'll kick things back to 'unclassified' and start thinking about them again once the EAPI's over. Things that make it to the approved draft, to be accepted once Portage support is there will get 'in-eapi-4' instead. Hopefully this'll make it easier to make sure we all know what's going on, and harder for simple things to get missed because no-one remembers them at the time. [1]: http://archives.gentoo.org/gentoo-pms/msg_927530a070199c51f553df8360337de2.xml -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Progress on Universal Select Tool
Hello,
Last week has been a very paradigmatic working week. Several problems
urged with the addition of symlinking dependency/inheritance functions.
sym actions where converted to the form of:
user action bin {
description Change Python's Version
type sym
sym python {
bin python
target /usr/bin/python
prefix /usr/bin/
regexp python([0-9]+\.[0-9]+$)
sym python-config {
bin python-config
destination /usr/bin/python-config
prefix /usr/bin/
regexp python([0-9]+\.[0-9]+)-config($)
} python-config
} python
} bin
Soon urged the need for more complex lexical analysis and started
implementing lex rules and yacc skeleton.
With this step a question bounced into my head.
Am I reinventing the wheel?
Why implement lex/yacc to translate a block of code into a python's
block of code?
Why not use plain python in modules?
After discussing with mentor, we decided to adopt python as the base
language for uselect modules.
The final objective is something similar to this:
# Start of Module
# Define the module
module = Module(description = Python Version Switcher, version =
0.1, author =meph...@gmail.com)
# Define a Symlinking Action
bin = Action (description = Change Python's Version, type = sym)
#Define the SymLinks
python = Link(bin = python, target = /usr/bin/python, prefix =
/usr/bin/, regexp = python([0-9]+\.[0-9]+$)
python-config = Link(bin = python-config, target =
/usr/bin/python-config, prefix = /usr/bin/, regexp =
python-config([0-9]+\.[0-9]+$)
python.add_link(python-config) # For inheritance
bin.add_link(python) # Adding The Link to the action
module.add_action(bin) #Adding the action to the module
# End of Module
This may seem complex at a glance. But why learn uselect scripting
language when you do modules without even knowing python?
Keep in mind that runnable actions will still be supported and therefore
supporting any scripting language for actions. Python will be the
easiest one as will depend on basic class inheritance and implementation
of functions.
All this lead to the start of a new phase. Define a strong and simple
API definition for all of uselect's capabilities creating the interfaces
easily usable.
uselect's profiles will also be in plain python, using the API of
uselect's Python Module umodule.
Last week had no commits to git due to all this.
I intend to clean up all the basic (ang buggy) lexical analysis that
was already implemented and re-implement the new module API during this
week.
Stay tuned on git for more updates during this week.
http://git.overlays.gentoo.org/gitweb/?p=proj/uselect.git;a=summary
Cheers,
Sérgio
--
Sérgio Almeida - meph...@gmail.com
mephx @ freenode
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool
Sérgio Almeida wrote:
user action bin {
description Change Python's Version
type sym
sym python {
bin python
target /usr/bin/python
prefix /usr/bin/
regexp python([0-9]+\.[0-9]+$)
sym python-config {
bin python-config
destination /usr/bin/python-config
prefix /usr/bin/
regexp python([0-9]+\.[0-9]+)-config($)
} python-config
} python
} bin
Soon urged the need for more complex lexical analysis and started
implementing lex rules and yacc skeleton.
With this step a question bounced into my head.
Am I reinventing the wheel?
Why implement lex/yacc to translate a block of code into a python's
block of code?
Why not use plain python in modules?
After discussing with mentor, we decided to adopt python as the base
language for uselect modules.
It seems to me that the original langauge is static/descriptive
while Python is not. Why not move to XML or JSON (former seems more
common with Gentoo) instead of Python? Think about how much easier it
is to pull information from metadata.xml than from .ebuild files - it's
the same difference in your case.
You know much better where you want to go with this than I do, but
please triple-check this move, as you cannot go back.
Thanks for listening,
Sebastian
[gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool
Sebastian, It seems to me that the original langauge is static/descriptive while Python is not. Why not move to XML or JSON (former seems more common with Gentoo) instead of Python? Think about how much easier it is to pull information from metadata.xml than from .ebuild files - it's the same difference in your case. I considered XML/JSON in this decision and did not even discussed it with my mentor. This is indeed not and abandoned idea as I explain below. You know much better where you want to go with this than I do, but please triple-check this move, as you cannot go back. I'm in no position to chose the path to take but for now python still seems the chosen vehicle. Remember that using XML/JSON for modules would never need a re-write from uselect but would only be an extension to the module system. Let us see. In uselect everything are objects. Module is a class Action is a class Module(s) have Action(s) Actions are interfaces to many kinds of actions, Sym, Path, Runnable Sym and Path actions have Link(s) Runnable actions have code and know how to execute it. Therefore the backend scenario (object space) is the same as the new suggested module syntax. Basically this decision is not adding a feature. It is abandoning the uselect syntax thus removing a feature. This will help during development as parsing is the task that has been more time consuming during uselect's development. With this uselect will have an open interface for extension to any markup language that comes in handy in module readability/programming. Thanks for listening, Sebastian I thank you. Will now add the markup language support to the to-do list, not to implement right away but to have in mind while expanding the API. Cheers, Sérgio -- Sérgio Almeida - meph...@gmail.com mephx @ freenode signature.asc Description: This is a digitally signed message part
[gentoo-dev] New eselect news item for kdeprefix
Hello, I'm sending you the following news item for review: Title: kdeprefix and monolithic ebuilds issues Author: Theo Chatzimichos tampak...@gentoo.org Content-Type: text/plain Posted: Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/kdelibs The Gentoo KDE Guide has been updated and now covers the two most serious issues affecting KDE users: masking of the kdeprefix USE flag (for KDE 4 users) and upgrade to KDE 3.5.10 for users of monolithic ebuilds. Please refer to the guide to solve those issues. [0] http:///www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Team
Re: [gentoo-dev] 2009 Council Elections
On E, 2009-06-29 at 12:32 +, Ferris McCormick wrote: On Sun, 2009-06-28 at 18:12 -0500, Dale wrote: Roy Bamford wrote: You agree that common sense can't be used and admit that a corner case exists that would in effect have the trustees pointing out to the council that they had made an error of judgement and need to reverse a decision that the last meeting made. I would prefer never to have to go there. I do not agree that an all proxy council meeting shows that the council does not take its responsibilities very seriously, rather that real life has hit everyone at the same time and they have appointed proxies. GLEP39 does not even set a limit on the maximum number of council members who may be proxied at any single meeting. As I have already said, I'm against the idea of proxies altogether. We should amend glep39 to remove proxies and ensure that council members are drawn from the developer community. Of course, that does not eliminate the possibility of the trustees pointing out to the council that they need to reverse a decision but it does ensure that decisions are made only by council members who are Gentoo developers. I'm just picking a random message so no fingers being pointed here. As a long time Gentoo user, I have to ask. Why is that EVERYONE on the council must be there or have someone there to represent them? Would Gentoo come to a end if one person or even two people were not present? All that's required is a quorum (4 out of 7) to hold a meeting. And when you have one less, it apparently immediately means a new council election. I guess that's one reason these days to always appoint proxies. The other is otherwise getting a missed meeting record, then a slacker mark and then a boot. And then there's the long tradition of always when a meeting un-attendance is foreseen a proxy getting appointed. I guess the new council can think about this, but a) time spent on figuring out such rules and whatnot to have to deal with unfortunately happening corner cases is time better spent on getting actual Gentoo improving done b) I don't think the council itself should be having so much to do with any such figuring out c) there are far bigger reaching restructuring ideas in the works for future proposals I do agree that if a proxy is going to be used, they should be a developer. If it is not that way now, it should be changed. I been using Gentoo for years and wouldn't even consider serving as a proxy. I would certainly not want to be a tie breaker on a vote. As a American that sees his own country's government getting out of control, never count on common sense. Elected people rarely have any. If they do during the election, it disappears after taking their position. I think the vast majority of people here have seen that over the years. My $0.02 worth. Dale :-) :-) Regards, Ferris -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Portage API questions
Hi, My 2 cents: Sebastian Pipping wrote: - installed packages with version numbers vardb = portage.db[portage.settings[ROOT]][vartree].dbapi vardb.cpv_all() will return cat/package-version vardb.cp_all() will return cat/package of installed packages - entries for /var/lib/portage/world You should think about world + system : for s in (system, world): set = portage._sets.base.InternalPackageSet( initial_atoms=rootconfig.setconfig.getSetAtoms(s)) for cp in set: print cp # print cat/package in world/system Good luck :) Mounir
Re: [gentoo-portage-dev] Portage API questions
On Mon, Jun 29, 2009 at 05:00:10AM +0200, Sebastian Pipping wrote: Hi, first I should note that I'm not involved with the development of portage so take everything I write with a good grain of salt ;) I come here to ask for precise pointers related to gathering these sets of data: - publically known distfile mirror URLs - publically known global use flags I assume you mean only the stuff the user has overridden, not collapsed together with the corresponding files in the profiles? - entries for package.keywords - entries for package.mask - entries for package.unmask - entries for package.use - installed packages with version numbers - entries for /var/lib/portage/world - available local use for ebuild file F - applied use flags for installed package P As I had a few minutes of spare time, and I'm much better at writing code than explaining stuff I hacked together a small script that showcases the API's I would use to get at the above data. (see attachment) So my two questions are: - Which of these sets of data can be obtained through the Portage API, which of them not? Unless I forgot something, or made some stupid mistake all of them ;) - Which classes and functions should I look at? As you can see in the attached script, most of the interesting stuff is either available through a portage.config instance, or via the applicable dbapi (porttree for anything that can be installed, vartree for anything regarding installed packages, etc.) Best regards, Andy -- We all know that no one understands anything that isn't funny. import os, sys from collections import defaultdict try: import portage except ImportError: sys.path.insert(0, /usr/lib/portage/pym) import portage import portage.sets import portage.util portage._disable_legacy_globals() def dump_mirrors(settings): # see portage.fetch(), snipped most of the interresting parts from there thirdpartymirrors = settings.thirdpartymirrors().items() thirdpartymirrors.sort(key = lambda x: x[0]) custommirrors = portage.grabdict(os.path.join(settings[PORTAGE_CONFIGROOT], portage.CUSTOM_MIRRORS_FILE.lstrip(os.path.sep)), recursive = 1).items() custommirrors.sort(key = lambda x: x[0]) gentoomirrors = [x.rstrip(/) for x in settings[GENTOO_MIRRORS].split() if x] gentoomirrors.sort() print(thirdpartymirrors:) for name, mirrors in thirdpartymirrors: print( %s % name) print(\n.join(4* + x for x in mirrors)) print() print(custom mirrors:) for name, mirrors in custommirrors: print( %s % name) print(\n.join(4* + x for x in mirrors)) print() print(gentoo mirrors:) print(\n.join( %s % x for x in gentoomirrors)) print() def dump_global_use(settings): # not sure wether there is a better way, but AFAIK portage doesn't really # care wether a flag is 'global' and use.desc is the only place I # know of that should contain all global use flags fp = os.path.join(settings[PORTDIR], profiles, use.desc) with open(fp) as f: for l in f: if not l.strip() or l[0] == #: continue s = l.split(None, 1) print(l.split(None, 1)[0]) def dump_package_foo(settings): # stacked together with the active profiles this is available in # settings.pusedict, settings.pkeywordsdict, settings.p(un)maskdict # suspecting you only want the local config of the user it is probably # easiest to use grabdict etc. directly (see portage.config.__init__) abs_user_config = os.path.join( settings[PORTAGE_CONFIGROOT], portage.USER_CONFIG_PATH.lstrip(os.path.sep)) puse = portage.grabdict_package( os.path.join(abs_user_config, package.use), recursive = 1) pkeywords = portage.grabdict_package( os.path.join(abs_user_config, package.keywords), recursive = 1) pmask = defaultdict(list) punmask = defaultdict(list) for x in portage.grabfile_package( os.path.join(abs_user_config, package.mask), recursive = 1): cp = portage.dep_getkey(x) pmask[cp].append(x) for x in portage.grabfile_package( os.path.join(abs_user_config, package.unmask), recursive = 1): cp = portage.dep_getkey(x) punmask[cp].append(x) print(package.use:) for atom, flags in sorted(puse.items(), key = lambda x: x[0]): print( %s %s % (atom, .join(flags))) print() print(package.keywords:) for atom, kw in sorted(pkeywords.items(), key = lambda x: x[0]): print( %s %s % (atom, .join(kw))) print() print(package.mask:) for cp, atoms in sorted(pmask.items(), key = lambda x: x[0]): print( %s %s % (cp, .join(atoms))) print() print(package.unmask:) for cp, atoms in sorted(punmask.items(), key = lambda x: x[0]): print( %s %s % (cp, .join(atoms))) print() def dump_world_set(settings, db): setconf =
