[gentoo-dev] New app-eselect category?
As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? Ulrich
Re: [gentoo-dev] Re: better support for binary packages
Hi Duncan, I don't see the connection between the email Fabio wrote and your answer. Do you want to say, that you agree that he's doing what i described and that it works the way i described it? I doubt it. If you really care, could you answer my first email and state there the problems you see with the approach and why you think this is making Gentoo worse? On Mon, 2009-05-25 at 11:43 +, Duncan wrote: Gentoo is in general a from-source metadistribution. There's limited support for binary packages in at least one of the package managers (portage), but honestly, that's not what Gentoo's best at, and I don't believe that will ever change without making it significantly worse at what it IS best at now, the normal from-source Gentoo we know and love. But how would you make it worse? It already has the functionality to add repositories for binpackages, why not improve it? Why leave it the way it is? Better to leave the serious distribution level binary repackaging to the Gentoo-based distributions like Sabayon. Let them do what they do best, and let Gentoo continue doing what it does best. By definition, binary packaging isn't broken and doesn't need fixed, as that's not part of what defines Gentoo, so don't fix what ain't broken! =:^) Well actually, some time ago Gentoo was by definition running a linux kernel or a BSD kernel and now it runs in a prefix on Windows and AIX and Solaris. Some time ago there was some guy called drobbins who was kind of the leader of Gentoo and now we have a council. If you really don't want changes, you could stop running emerge --sync. That said, I could envision an eselect like binary profile switcher, that subject to settings in a config file, changes USE flags, CFLAGS, gcc- configs an appropriate gcc version, etc, changing PKGDIR appropriately as well, so one could easily enough create as many binary profiles as desired and as the use case dictated. It's likely various reasonably large Gentoo deployments are already doing something like this as it could certainly be scripted, but an emergable package to make it easy for ordinary joe Gentoo user would be useful, and I believe appreciated by many. (Here, I'd put it to use when testing new gcc versions, making it easy to swap out PKGDIRs and revert to the old version either per-package or system-wide, if the new version was breaking too much.) So here: No to the whole big complicated let's fix Gentoo binaries thing. There's already Gentoo-based binary solutions like Sabayon for those so interested, and I can't see Gentoo doing better than they're doing, at least not without breaking the from-source that Gentoo's good at. But yes to anyone interested in developing a nice new binary profile switcher to make managing binary package sets easier for those Gentoo admins that would find such a thing useful. Whether they then start making those profiles public and whether anyone else chooses to use them is entirely up to the individual admins whose systems would be affected. Not sure, what the binary profile switcher really would change here. What I was talking about were mostly USE-flags and packages, and I guess your binary profile switcher doesn't change too much, there. It would be ok to do all this stuff in an extra project, without Gentoo. But there are some downsides: You are not Gentoo anymore. The communication channels get longer and more complicated. In my first post i described some things that would need to be changed. Either in portage or in the policy how packages are dealt with. Well, the last is a little bit impossible outside of Gentoo (I don't want to fork the tree) and I also don't want to fork portage, so the first is complicated, too. And all this layer thing Fabio was talking about. I did not try it and I did not read the code, but I think it makes things much more complicated. See also the discussion about mixing package managers between Gentoo and Sabayon. I do not want these problems. Philipp
Re: [gentoo-dev] better support for binary packages
On Mon, 2009-05-25 at 11:54 +0200, Philipp Riegger wrote: The current situation: Binary packages are (usually) stored in /usr/portage/packages/$category/$package-$version.tbz2. The package consists of the real binary package and the metadata (combined using xpak or whatever). No, the metadata is stored in a separate Packages file. Regards, Kobboi
[gentoo-dev] Last rites: sci-geosciences/osm2mp
osm2mp was a tool needed for conversion of openstreetmap maps into an intermediate format, which could be used for further conversion into garmin maps with mkgmap. Latest versions of mkgmap accept osm files as an input, osm2mp is not maintained and imho not of any use nowadays, so I'll remove it soon. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de http://ausdenaugenausdemsinn.de - Kein Sicherheitsrabatt für CO2-Speicher http://tinyurl.com/dceu73 - Internetzensur stoppen! http://schokokeks.org - professional webhosting signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
So, :: vs @ apart, is it something that is worth looking and implementing in future EAPIs? -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: better support for binary packages
Philipp Riegger li...@anderedomain.de posted 1243321504.9661.14.ca...@hspc30.informatik.uni-stuttgart.de, excerpted below, on Tue, 26 May 2009 09:05:03 +0200: I don't see the connection between the email Fabio wrote and your answer. Do you want to say, that you agree that he's doing what i described and that it works the way i described it? I doubt it. If you really care, could you answer my first email and state there the problems you see with the approach and why you think this is making Gentoo worse? I agree that an independent approach is the way to go. Gentoo (or rather, its PMs, package managers, all three of them, of which portage is only one) doesn't do binaries really well, certainly, but I really don't see that changing within Gentoo itself, except at the expense of from- source, which it does quite well indeed. But how would you make it worse? It already has the functionality to add repositories for binpackages, why not improve it? Why leave it the way it is? Sure, improve it, but what you are talking about isn't a simple improvement, but a massive rearchitecting. That's not easily doable without a chance of focus. It's that change of focus that would eventually kill the quality from-source support we have and that continues to develop, now. That said, I could envision an eselect like binary profile switcher, that subject to settings in a config file, changes USE flags, CFLAGS, gcc- configs an appropriate gcc version, etc, changing PKGDIR appropriately as well, so one could easily enough create as many binary profiles as desired and as the use case dictated. Not sure, what the binary profile switcher really would change here. What I was talking about were mostly USE-flags and packages, and I guess your binary profile switcher doesn't change too much, there. Sure it does, but incrementally. Basically, your proposal laid out a complicated tree based on metadata, a tree the package manager would have to understand and support, what I'm proposing is to allow the same thing, but not by adding all that complication to the package manager, but rather, by using a newly created application to switch among the branches of that tree on request. Portage (or other PM) would use its configured PKGDIR and wouldn't understand the tree, but it wouldn't need to, because the switcher would manage switching between the branches according to its configuration. The result would be that in a large enough deployment to have build- servers, the build server(s) could build a particular set of CFLAGS/USE- flags/gcc-version/arch/whatever, then switch to another branch and build that set. Individual package clients could simply point at the appropriate tree and get most of their packages, at least the common ones, that way. Now this wouldn't directly give you the flexibility of the package name changes you proposed, but it could do so indirectly, putting that information in the directory tree if configured to do so. Clients may need to use the binprofile switcher as well, for individual packages they chose to build outside their normal USE profile, but the process could be automated once properly configured, using PM hooks as appropriate. It would be ok to do all this stuff in an extra project, without Gentoo. The proposal above wouldn't be without Gentoo. It'd simply be a package level thing rather than a distribution level thing. But either that or the independent distribution based on Gentoo route that lxnay has taken, either one works, without defocusing Gentoo on its meta-distrib-wide from- source vision. For that matter, Gentoo already has three package managers, and binary support (or the lack thereof) has been deliberately left up to the package manager at this point -- it's NOT part of PMS. It'd be equally possible to either take one of the current PMs and add your enhanced binary package scheme to it, or to start an independent forth package manager, and have it focus on binaries rather than from-source. (It could even take the existing portage binpkgs and rename or otherwise manage them as necessary, thereby avoiding the from-source side entirely, if so desired.) Well, the last is a little bit impossible outside of Gentoo (I don't want to fork the tree) and I also don't want to fork portage, so the first is complicated, too. You mention portage, but don't mention the other PMs at all. As mentioned, binary packages aren't part of PMS (the Package Management Specification, the app-doc/pms package, the standard that allows PMs besides portage, currently, paludis and pkgcore) at all. Gentoo really doesn't have an official binary package format at all (see PMS, Appendix B, Unspecified Items), only individual package managers like portage do, and at present they may conflict with each other. That's both a good and a bad thing. As it's not specified, you're free to define it as necessary to meet your needs for any tool you
Re: [gentoo-dev] Re: better support for binary packages
On Tue, May 26, 2009 at 9:05 AM, Philipp Riegger li...@anderedomain.de wrote: Hi Duncan, And all this layer thing Fabio was talking about. I did not try it and I did not read the code, but I think it makes things much more complicated. See also the discussion about mixing package managers between Gentoo and Sabayon. I do not want these problems. incorrect. Give it a spin ;) Problems we have were *only* related to Portage world file handling, fixed some time ago. I am sorry to say that the issue reported here doesn't seem to be valid. Of course, if you mix both, you need to pay attention to not change USE flags (for eg.) that trigger libraries compilation, but that's a known binary-world problem. I agree with you that there could be some more room for improvements here and there (especially in kernel module ebuilds), but with EAPI=2 we're going in the right direction. Philipp -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: better support for binary packages
On Tue, 2009-05-26 at 11:27 +0200, lx...@sabayonlinux.org wrote: On Tue, May 26, 2009 at 9:05 AM, Philipp Riegger li...@anderedomain.de wrote: And all this layer thing Fabio was talking about. I did not try it and I did not read the code, but I think it makes things much more complicated. See also the discussion about mixing package managers between Gentoo and Sabayon. I do not want these problems. incorrect. Give it a spin ;) I'll do, if i find the time. Problems we have were *only* related to Portage world file handling, fixed some time ago. I am sorry to say that the issue reported here doesn't seem to be valid. Of course, if you mix both, you need to pay attention to not change USE flags (for eg.) that trigger libraries compilation, but that's a known binary-world problem. You're talking about binary-world problems here that Gentoo as a source based distribution does not have, I assume. This is a strength of Gentoo and I think we can keep it for binary packages by a good design. If you emerge a package in Gentoo it gets build from source. If you use a binary distribution, you cannot influence, what flags were used for building the package. But with a hybrid approach (I was aming for that one in my proposal), you would simply have the choice to either install a binary package and be restricted, if it's not available in the way you want it, or install it from source. And it would work together, because you don't have 2 package managers that need to interface, talk, share, work together, whatever, but you have 1 package manager that does it all and can keep it consistent. I agree with you that there could be some more room for improvements here and there (especially in kernel module ebuilds), but with EAPI=2 we're going in the right direction. Kernel packages and kernel modules are not really of interest for me. I would keep them as source packages. My aim is not to make thigns easier, but to provide the user with the tools to save 8 hours of compiling openoffice or something like that. Not a binary distribution, but some kind of -bin packages, just packaged by Gentoo and better. Philipp
Re: [gentoo-dev] Re: better support for binary packages
On Tue, 2009-05-26 at 08:48 +, Duncan wrote: Philipp Riegger li...@anderedomain.de posted 1243321504.9661.14.ca...@hspc30.informatik.uni-stuttgart.de, excerpted below, on Tue, 26 May 2009 09:05:03 +0200: I don't see the connection between the email Fabio wrote and your answer. Do you want to say, that you agree that he's doing what i described and that it works the way i described it? I doubt it. If you really care, could you answer my first email and state there the problems you see with the approach and why you think this is making Gentoo worse? I agree that an independent approach is the way to go. Gentoo (or rather, its PMs, package managers, all three of them, of which portage is only one) doesn't do binaries really well, certainly, but I really don't see that changing within Gentoo itself, except at the expense of from- source, which it does quite well indeed. Again, I see this as completely independent features. Binary packages would only support the building from source and binary packages could never be created without ebuilds. This might even improve the quality of the ebuilds in the tree, because they would get built from time to time, build failures would get reported and all that. But how would you make it worse? It already has the functionality to add repositories for binpackages, why not improve it? Why leave it the way it is? Sure, improve it, but what you are talking about isn't a simple improvement, but a massive rearchitecting. That's not easily doable without a chance of focus. It's that change of focus that would eventually kill the quality from-source support we have and that continues to develop, now. Are you sure? How code would it take to look for a binary package in a different path than now? 1 additional line or 1 line exchanged? How much code would it take to create this packed bit vector out of the USE-flags? 5-10 lines? Changing portage to _also_ support the new kind of binary packages might be done in 1 day. And this is the first step. That said, I could envision an eselect like binary profile switcher, that subject to settings in a config file, changes USE flags, CFLAGS, gcc- configs an appropriate gcc version, etc, changing PKGDIR appropriately as well, so one could easily enough create as many binary profiles as desired and as the use case dictated. Not sure, what the binary profile switcher really would change here. What I was talking about were mostly USE-flags and packages, and I guess your binary profile switcher doesn't change too much, there. Sure it does, but incrementally. Basically, your proposal laid out a complicated tree based on metadata, a tree the package manager would have to understand and support, what I'm proposing is to allow the same thing, but not by adding all that complication to the package manager, but rather, by using a newly created application to switch among the branches of that tree on request. Which might work, but would lead to a really strange package tree with really big restrictions and disadvantages (no package sharing, no way of finding out if an update is necessary,...). Portage (or other PM) would use its configured PKGDIR and wouldn't understand the tree, but it wouldn't need to, because the switcher would manage switching between the branches according to its configuration. And there the flexibility goes. If you want to emerge PHP and there is a binary package with the same USE-flage but also cli enabled or something like that, it would really get complicated to inform you (the user) that a simple and probably not too important change for you might save you an hour of compilation. The result would be that in a large enough deployment to have build- servers, the build server(s) could build a particular set of CFLAGS/USE- flags/gcc-version/arch/whatever, then switch to another branch and build that set. Individual package clients could simply point at the appropriate tree and get most of their packages, at least the common ones, that way. Now this wouldn't directly give you the flexibility of the package name changes you proposed, but it could do so indirectly, putting that information in the directory tree if configured to do so. Clients may need to use the binprofile switcher as well, for individual packages they chose to build outside their normal USE profile, but the process could be automated once properly configured, using PM hooks as appropriate. And as soon as you use PM hooks, you ask yourself, why you did it that way, if not that change had made it easier, if it would have been better to discuss the issue with portage/pkgcore/paludis developers and all that. Since I really like PM hooks, I'm not sure if they are really helpfull for users. They are too cryptic. Maybe it would be wise to create some eselect like thing for those hooks provide some basic scripts with that. For that matter, Gentoo
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Tue, 26 May 2009 10:13:51 +0200 (CEST) lx...@sabayonlinux.org wrote: So, :: vs @ apart, is it something that is worth looking and implementing in future EAPIs? Isn't it just a user issue, not one we want used anywhere where EAPI rules are in effect? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: better support for binary packages
Philipp Riegger li...@anderedomain.de posted 1243335643.9661.46.ca...@hspc30.informatik.uni-stuttgart.de, excerpted below, on Tue, 26 May 2009 13:00:43 +0200: Bit it seems to be quite an uninteresting topic, since the people most affected by it (Gentoo developers) did not join the conversation, yet. Maybe I should take this to gentoo-server@ and gentoo-portage@, it might fit there. Agreed on the participation observation and taking it elsewhere, both. I'd think the gentoo-portage-dev list (which I also read) would be a good place for hopefully more discussion, with people actually interested. I still think it's likely better, at least at first, as a separate helper app, but a number of such helpers have ultimately been integrated into either portage itself, or into gentoolkit over time. Also, by doing it that way rather than by trying to change Gentoo as a whole, you avoid the prospect of /years/ of debate that has occurred over GLEP55 and with it 54, which also set about to change the package naming conventions, in this case for ebuilds. And given that PMS specifically defines binary package formats as out of its domain, I really do see that as the more practical approach... unless of course you /want/ to debate it for /years/ before anything gets done. =:^\ Then as it proves its value, it'll ultimately become the de-facto standard and be integrated into some future version of PMS or whatever. -- 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
[gentoo-dev] Last rites: net-analyzer/ns and net-analyzer/nam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Federico Ferri mescali...@gentoo.org (26 May 2008) # Deprecated cause depending on unmaintained dev-tcltk/otcl. # Everything being moved to 'abandonware' overlay. # Possible replacement: net-misc/gns3 (sunrise overlay) # Going for removal in ~30 days if no one objects. # removal bug #271305 net-analyzer/ns net-analyzer/nam # Federico Ferri mescali...@gentoo.org (26 May 2008) # Unmaintained upstream. # Going for removal in ~30 days. # removal bug #271307 dev-tcltk/otcl dev-tcltk/tclcl -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkob8bEACgkQV/B5axfzrPvnFQCeId9Sg1yOsOPzqJjfAJZpWPBO hTkAnj8d5lpl/TvXMSF3KjxVXNyswKvA =tlPp -END PGP SIGNATURE-
[gentoo-dev] Re: The fallacies of GLEP55
Duncan wrote: Tobias Klausmann klaus...@gentoo.org posted I was under the impression that it's illegal to change/set the EAPI after using inherit. The short answer, based on my understanding of posts to this point, would be that it's illegal for Gentoo (in-tree, council decided), but not necessarily for all the overlays and Gentoo based projects out there. On the one hand, as a result of the above, Gentoo doesn't have to concern itself with the others and can decide what's best for the Gentoo tree and dev-sponsored overlays presumably targeted at eventual tree inclusion. On the other, regardless of what Gentoo decides, PMs wishing widest compatibility must be prepared for it anyway. If I'm not mistaken, paludis has the widest deployment footprint both in practice and by goal at this point, so naturally, those developing it have broader concerns than just Gentoo. Well is it okay for the Gentoo developer list to be focussed firstly on Gentoo product and solving the real issues people actually face as opposed to non-issues like typing in a version specifier? Further, if there is a valid use-case for setting EAPI after inherit, could you (or someone else) explain what it is and why Gentoo, or indeed anyone working on a Gentoo-based product, should care? ATM it looks like a classic case of obfuscation; it's frankly well below par to post code that isn't allowed and then claim it as a use-case requiring such massive changes. I'd ask you also to consider prefix-portage when you assess the deployment footprint (however you're coming to that conclusion.) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
[gentoo-dev] Re: The fallacies of GLEP55
Ciaran McCreesh wrote: On Sat, 16 May 2009 00:28:36 +0530 Arun Raghavan ford_pref...@gentoo.org wrote: As I've stated a long time ago, I'm for this solution. My understanding is that there are 2 objections to this: 3) It doesn't solve the problem. It doesn't allow things like version format extensions. That's the big one, not the other two. Debian-style epochs, which were mooted to this list over a year ago, do however, given that we already have SLOT. They're also a lot simpler and do not 'require' a potentially unlimited set of new extensions for every new format (look, shiny!) that a herd might experiment with. And again, you haven't explained why an internal format specification should allow NN variants on the format (beyond your usual sniping at the level of developer expertise, which you propose to address by making it easy to mess up the spec, instead of simply expecting people to learn; which they certainly appear capable of doing, as the ebuild tree attests.) In summary, the proposed benefit doesn't seem like one, and certainly not enough to justify the fundamental noob mistake of breaking encapsulation. Personally I remain unconvinced this is even enough to merit the use of epochs. I'd much rather see them kept in reserve for a real issue, and an innovation which actually solves a problem our end-users face. So no, not a big one at all; just yet another student attempt at coercion cloaked in obfuscation. No more, no less. 'Sometimes I find it hard to believe that people can attach so much of their ego to one particular design, even when the obvious flaws are pointed out. As a wise man once said to me: There also comes a point where you realise that no one can know everything, so it's not a problem to ask someone or on occasion be wrong..'[1] Think about it. No? Ah well never mind, didn't really expect you to ever accept you might still have something to learn. No doubt there'll be another 50 or so emails from you next time I catch up on the list. And of course if each one doesn't have a detailed objection, it's enough for you to claim that you've run it past the list. And if they do, it's simply because the person doesn't understand (despite your clear and lucid explanations to the list.) /sarcasm [project] You are aware that many Gentoo developers simply cba to argue with you? Since the stuff you're proposing often makes no effective difference to what they're doing anyway (it's /that/ useful), it can seem easier simply to let you have your way. Believe it or not, that's how I feel; I'm only speaking now as your GLEPs are so massively flawed, that I've been told I would have to maintain a patched portage were they to go ahead. Happily the only patches required would be to get rid of the crap you're proposing. I *still* resent the extra workload, and the fact that it's only necessitated because you haven't got over the rejection of being the only developer ever to be kicked in such a fashion. Twice. [/project] [1] http://igliot.blogspot.com/ -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
[gentoo-dev] RFC: GLSA-2, a new DTD for GLSAs
Hello, the Security Team would like to create a new DTD for our GLSAs. GLSAs are distributed via our web site and the tree. Their format is defined by a DTD. When the format was initially defined in 2004, some use cases were considered that never got implemented or used. Other use cases only came up later. For this reason, we want to update the GLSA for the needs of 2009. Since this includes changes that make existing GLSAs invalid we are going to introduce a new DTD called glsa-2.dtd. I would like to announce the changes we want to introduce. If you have any feedback, please speak up. This can include feature requests. After this discussion, we would like to freeze the DTD and ask all consumers of GLSA XML files (such as package managers) to implement said changes. The first GLSA using the new DTD will be at the earliest six weeks after the DTD was frozen. Once the new GLSA format is in use, we are going to convert some or all of the existing GLSAs to use the format. Find the existing DTD here: http://dev.gentoo.org/~rbu/glsa-2/glsa.dtd The new DTD here: http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd And a diff between them here: http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd.diff Here's a list of changes: (-) Dropping of the product type. GLSAs will be used solely to announce security issues in the Portage Tree. The infrastructure and informational product type are not needed and the type attribute will be dropped altogether. (-) Dropping of service tag. Same rationale as above, if we drop infrastructure, we do not need the service tag. (-) Drop the 'name' attribute to unaffected. This is not implemented in glsa-check or Portage 2.2 and it was never part of our Policy to mix GLSAs with package moves or similar. (+) SLOT support. An implied attribute 'slot' to the 'vulnerable' and 'unaffected' tag will be introduced. This limits the scope of the range specifiers to ebuilds in the specified slot. The default is '*' meaning all slots. [1] (+) Addition of a 'count' attribute to the 'revised' tag. We stop formatting revision dates as 'May 26, 2009: 03' and use 'revised count=32009-05-26/revised' instead. (*) UTF-8 support. We would like to release GLSAs containing UTF-8 characters in places where they make sense (that is, not package names, version information, etc.). Please check whether your tools support this. A GLSA XML file containing said changes, including UTF-8 characters, is up here: http://dev.gentoo.org/~rbu/glsa-2/glsa-200012-34.txt Robert [1] This does not allow for undefined situations if you employ the following algorithm: An ebuild is vulnerable if falls into any of the ranges specified by the 'vulnerable' tags unless it also falls into any of the ranges specified by the 'unaffected' tags. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New app-eselect category?
Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? Yes in general. Maybe think about what happens when the Universal Select Tool gets released/used. Possible alternative: app-select? -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] RFC: GLSA-2, a new DTD for GLSAs
On Tue, May 26, 2009 4:49 pm, Tiziano Müller wrote: Am Dienstag, den 26.05.2009, 16:19 +0200 schrieb Robert Buchholz: [...] (+) SLOT support. An implied attribute 'slot' to the 'vulnerable' and 'unaffected' tag will be introduced. This limits the scope of the range specifiers to ebuilds in the specified slot. The default is '*' meaning all slots. [1] I don't think this is really a good idea since the version may or may not be tied to a slot (at the moment it is in most cases I know). Yes, but in the few cases where another version is added to a lower slot, we need to edit all the old glsas, which can turn into a real nightmare in some cases. see bug #255116 and glsa-200804-20 for example. Having slot support would really make things a lot easier in these cases, and wouldn't change anything in the other cases. -- Pierre-Yves Rofes Gentoo Linux Security Team
Re: [gentoo-dev] RFC: GLSA-2, a new DTD for GLSAs
On Tuesday 26 May 2009, Tiziano Müller wrote: Am Dienstag, den 26.05.2009, 16:19 +0200 schrieb Robert Buchholz: I would like to announce the changes we want to introduce. If you have any feedback, please speak up. This can include feature requests. Maybe add a 'tag' attribute to the reference link to give them a meaning, like: uri tag='upstream' link='http://bugs.samba.org/...'.../uri or keeping a table of tags in the XSL and replace it on transformation: uri tag='samba-bugs' id='1234'Upstream Bug 1234/uri not sure whether uri would be the right point for such stuff though. In 98% of all cases, these are either links to the corresponding CVE identifiers or previous GLSAs. The CVE identifier then features a list of references of different types, such as upstream bugs, patches, advisories. See this CVE id for example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4316 You will notice that some links carry machine-readable information such as DEBIAN:DSA-1747 and upstream bugs and the like are usually called confirm (such as CONFIRM:http://svn.gnome.org/...). With how we use our references, we could define three types of elements: uri link='', cve id='' / and glsa id='' / The latter two could then be transformed to either URIs or local links (say, in applications displaying the content). After this discussion, we would like to freeze the DTD and ask all consumers of GLSA XML files (such as package managers) to implement said changes. The first GLSA using the new DTD will be at the earliest six weeks after the DTD was frozen. Once the new GLSA format is in use, we are going to convert some or all of the existing GLSAs to use the format. I wouldn't do that since a properly written tool should be able to handle both versions anyway. That is true. I was referring (at least) to existing GLSAs that can benifit from added slot support that we must keep updated by hand today. Also, I think there were issues with the date formatting in current XML files and how they are displayed on our site. (+) SLOT support. An implied attribute 'slot' to the 'vulnerable' and 'unaffected' tag will be introduced. This limits the scope of the range specifiers to ebuilds in the specified slot. The default is '*' meaning all slots. [1] I don't think this is really a good idea since the version may or may not be tied to a slot (at the moment it is in most cases I know). I'm not following -- maybe we had a misunderstanding. The slot attribute is additional to the tag, but its value is implied as '*' if it is not specified. This is what we have today (from GLSA 200804-20): package name=dev-java/sun-jdk auto=yes arch=* vulnerable range=lt1.6.0.05/vulnerable unaffected range=ge1.6.0.05/unaffected unaffected range=rge1.5.0.15/unaffected unaffected range=rge1.5.0.16/unaffected unaffected range=rge1.5.0.17/unaffected unaffected range=rge1.5.0.18/unaffected unaffected range=rge1.4.2.17/unaffected unaffected range=rge1.4.2.18/unaffected unaffected range=rge1.4.2.19/unaffected /package This is would imply the following (in glsa-2): package name=dev-java/sun-jdk auto=yes arch=* vulnerable slot=* range=lt1.6.0.05/vulnerable unaffected slot=* range=ge1.6.0.05/unaffected unaffected slot=* range=rge1.5.0.15/unaffected unaffected slot=* range=rge1.5.0.16/unaffected unaffected slot=* range=rge1.5.0.17/unaffected unaffected slot=* range=rge1.5.0.18/unaffected unaffected slot=* range=rge1.4.2.17/unaffected unaffected slot=* range=rge1.4.2.18/unaffected unaffected slot=* range=rge1.4.2.19/unaffected /package And (thank god!) should be equivalent to: package name=dev-java/sun-jdk auto=yes arch=* vulnerable slot=* range=lt1.6.0.05/vulnerable unaffected slot=* range=ge1.6.0.05/unaffected unaffected slot=1.5 range=rge1.5.0.15/unaffected unaffected slot=1.4 range=rge1.4.2.17/unaffected /package Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New app-eselect category?
On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? I hate package moves, so is it really *really* necessary? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] New app-eselect category?
On Tuesday 26 May 2009 18:31:17 AllenJB wrote: Fabian Groffen wrote: On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? I hate package moves, so is it really *really* necessary? I have to agree. app-admin is hardly among the largest categories. Perhaps we should consider splitting up the 400 odd packages in kde-base (kde-graphics, kde-admin, kde-games, etc) =P As for app-admin-eselect, I'd favor tags over increasing the category levels, tho I'm not convinced either is necessary at the current time (tho tags might make searching easier, in some ways). AllenJB kde-base is OK please don't touch :) Also i removed one package from kde-base today :P -- Theo Chatzimichos (tampakrap) Gentoo KDE Team
Re: [gentoo-dev] New app-eselect category?
Fabian Groffen wrote: On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? I hate package moves, so is it really *really* necessary? I have to agree. app-admin is hardly among the largest categories. Perhaps we should consider splitting up the 400 odd packages in kde-base (kde-graphics, kde-admin, kde-games, etc) =P As for app-admin-eselect, I'd favor tags over increasing the category levels, tho I'm not convinced either is necessary at the current time (tho tags might make searching easier, in some ways). AllenJB
Re: [gentoo-dev] New app-eselect category?
Hello world! On Tue, 2009-05-26 at 16:24 +0200, Tiziano Müller wrote: Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? Yes in general. Maybe think about what happens when the Universal Select Tool gets released/used. Possible alternative: app-select? How will that tool be called? Maybe uselect? Another alternative: app-xselect. Philipp
Re: [gentoo-dev] New app-eselect category?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp Riegger wrote: Hello world! On Tue, 2009-05-26 at 16:24 +0200, Tiziano Müller wrote: Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? Yes in general. Maybe think about what happens when the Universal Select Tool gets released/used. Possible alternative: app-select? How will that tool be called? Maybe uselect? Another alternative: app-xselect. seems like here two-level categories are a limitation. if three-level categories were available, I'd say app-admin-xselect. since the last two levels make more sense, compared to the 1+3, if you believe the app-admin category is too crowded, why not just make a new category admin-XYZ, thus adding the missing third level? - -- Federico Ferri (mescalinum) Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocAeQACgkQV/B5axfzrPv12gCeO8tVVCvJcqb0OK4qsFBxELe3 VuoAoKub0H7s1u0yvPR9n4DSNeKmN+rE =dovF -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: GLSA-2, a new DTD for GLSAs
Am Dienstag, den 26.05.2009, 16:19 +0200 schrieb Robert Buchholz: Hello, the Security Team would like to create a new DTD for our GLSAs. GLSAs are distributed via our web site and the tree. Their format is defined by a DTD. When the format was initially defined in 2004, some use cases were considered that never got implemented or used. Other use cases only came up later. For this reason, we want to update the GLSA for the needs of 2009. Since this includes changes that make existing GLSAs invalid we are going to introduce a new DTD called glsa-2.dtd. I would like to announce the changes we want to introduce. If you have any feedback, please speak up. This can include feature requests. Maybe add a 'tag' attribute to the reference link to give them a meaning, like: uri tag='upstream' link='http://bugs.samba.org/...'.../uri or keeping a table of tags in the XSL and replace it on transformation: uri tag='samba-bugs' id='1234'Upstream Bug 1234/uri not sure whether uri would be the right point for such stuff though. After this discussion, we would like to freeze the DTD and ask all consumers of GLSA XML files (such as package managers) to implement said changes. The first GLSA using the new DTD will be at the earliest six weeks after the DTD was frozen. Once the new GLSA format is in use, we are going to convert some or all of the existing GLSAs to use the format. I wouldn't do that since a properly written tool should be able to handle both versions anyway. Find the existing DTD here: http://dev.gentoo.org/~rbu/glsa-2/glsa.dtd The new DTD here: http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd And a diff between them here: http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd.diff Here's a list of changes: (-) Dropping of the product type. GLSAs will be used solely to announce security issues in the Portage Tree. The infrastructure and informational product type are not needed and the type attribute will be dropped altogether. (-) Dropping of service tag. Same rationale as above, if we drop infrastructure, we do not need the service tag. (-) Drop the 'name' attribute to unaffected. This is not implemented in glsa-check or Portage 2.2 and it was never part of our Policy to mix GLSAs with package moves or similar. (+) SLOT support. An implied attribute 'slot' to the 'vulnerable' and 'unaffected' tag will be introduced. This limits the scope of the range specifiers to ebuilds in the specified slot. The default is '*' meaning all slots. [1] I don't think this is really a good idea since the version may or may not be tied to a slot (at the moment it is in most cases I know). Looks good so far. -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New app-eselect category?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AllenJB wrote: Fabian Groffen wrote: On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? I hate package moves, so is it really *really* necessary? I have to agree. app-admin is hardly among the largest categories. Perhaps we should consider splitting up the 400 odd packages in kde-base (kde-graphics, kde-admin, kde-games, etc) =P As for app-admin-eselect, I'd favor tags over increasing the category levels, tho I'm not the three-levels-category was an example. the realistic approach I proposed is splitting app-admin in many two-level categories: + admin-eselect + admin-sysconf + admin-www + admin-apache ... as it usually has been done in such cases. - -- Federico Ferri (mescalinum) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocHNoACgkQV/B5axfzrPsCzgCeJZknEWRV1o2SjPpPc9HJ0k1u bUoAnRygFK/mRPfAguutyUmZWssnPyXh =hZFu -END PGP SIGNATURE-
Re: [gentoo-dev] New app-eselect category?
On Tue, 26 May 2009, Fabian Groffen wrote: We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). I hate package moves, so is it really *really* necessary? Of course it is not necessary, only a matter of organisation (as most package moves are). Since there's also no agreement on the name of the category, let's postpone it. Maybe the situation will be clearer after the release of the Universal Select Tool. Ulrich
Re: [gentoo-dev] Re: better support for binary packages
lx...@sabayonlinux.org wrote: On Tue, May 26, 2009 at 9:05 AM, Philipp Riegger li...@anderedomain.de wrote: See also the discussion about mixing package managers between Gentoo and Sabayon. I do not want these problems. incorrect. Give it a spin ;) Problems we have were *only* related to Portage world file handling, fixed some time ago. I am sorry to say that the issue reported here doesn't seem to be valid. Of course, if you mix both, you need to pay attention to not change USE flags (for eg.) that trigger libraries compilation, but that's a known binary-world problem. So are we going to discuss this or not? To quote your own words back at you: This is gentoo-dev and you are OFF TOPIC. Next time, please post Sabayon specific stuff on our ML/com. channels. ... *If* you want to promote entropy/equo (or other sabayon work) as a possible solution here, you should be open to discuss its shortcomings. If not, then you should refrain from bringing it up again. To get back on topic: I think portage's current binary support works reasonably well, based on some experience I have with building packages for a second, slower machine. But I can see there are shortcomings, mainly in the described problem of storing multiple versions of a binpkg (with different useflags etc.). I agree with Duncan that we do not want a change of focus away from being a source-based distribution, but then that is not a change you would be able to sell to the current developers anyway. That said, there could very well be a Gentoo project, or people contributing to portage development, to try and improve binary package support. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Tue, May 26, 2009 at 6:50 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 26 May 2009 10:13:51 +0200 (CEST) lx...@sabayonlinux.org wrote: So, :: vs @ apart, is it something that is worth looking and implementing in future EAPIs? Isn't it just a user issue, not one we want used anywhere where EAPI rules are in effect? Indeed. Since the consensus is for using it as part of the UI, you don't need to wait for EAPI=4, you (lxnay) can start writing patches for portage (regardless of which operator is used) to recognize such atoms on the command line. -- ~Nirbheek Chauhan
Re: [gentoo-dev] New app-eselect category?
Tuesday, 26. May 2009, Federico Ferri Ви написали: seems like here two-level categories are a limitation. if three-level categories were available, I'd say app-admin-xselect. Argh, should we suffer the same issues over again? What about just dropping the two/three/etc tier requirement and just go for arbitrary nestedness? So, your example would become app/admin/xselect (plus we would have a tidier top-level of portage) Its not like tree walker is prohibitively sophisticated piece of code.. NOTE: I am not proposing to do this now (considering how things go, such a move is unrealistic to expect in any foreseeable future :)). However if we do (eventually; right, if this is ever gonna happen), lets do it right, so that we do not have to readdress the same issue over and over again.. George
Re: [gentoo-dev] Re: better support for binary packages
On Tue, May 26, 2009 at 7:08 PM, Ben de Groot yng...@gentoo.org wrote: lx...@sabayonlinux.org wrote: On Tue, May 26, 2009 at 9:05 AM, Philipp Riegger li...@anderedomain.de wrote: See also the discussion about mixing package managers between Gentoo and Sabayon. I do not want these problems. incorrect. Give it a spin ;) Problems we have were *only* related to Portage world file handling, fixed some time ago. I am sorry to say that the issue reported here doesn't seem to be valid. Of course, if you mix both, you need to pay attention to not change USE flags (for eg.) that trigger libraries compilation, but that's a known binary-world problem. So are we going to discuss this or not? To quote your own words back at you: This is gentoo-dev and you are OFF TOPIC. Next time, please post Sabayon specific stuff on our ML/com. channels. ... My answer was completely in-topic. Even because it was just an answer. Your rants were totally OT, OTOH. *If* you want to promote entropy/equo (or other sabayon work) as a possible solution here, you should be open to discuss its shortcomings. If not, then you should refrain from bringing it up again. If you are just trying to annoy me, give up. It's not working ;) I was just answering, my friend. To get back on topic: I think portage's current binary support works reasonably well, based on some experience I have with building packages for a second, slower machine. But I can see there are shortcomings, mainly in the described problem of storing multiple versions of a binpkg (with different useflags etc.). I agree with Duncan that we do not want a change of focus away from being a source-based distribution, but then that is not a change you would be able to sell to the current developers anyway. That said, there could very well be a Gentoo project, or people contributing to portage development, to try and improve binary package support. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __ -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New app-eselect category?
090526 Ulrich Mueller wrote: We could move the 27 eselect-* packages to a new app-eselect category; eselect itself would stay in app-admin. I hate package moves, so is it really *really* necessary? Of course it is only a matter of organisation (as most package moves are). Since there's also no agreement on the name of the category, let's postpone it. Maybe the situation will be clearer after the release of the Universal Select Tool. As a mere user who tries to keep track of his pkgs, may I register a '+1' for keeping categories reasonably small for retaining the 'major-minor' syntax of the dir names ? So the new category should help us users slightly 'app-select' looks like the most appropriate name for the new dir. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-dev] Gentoo Council Reminder for May 28
This is your friendly reminder! Same bat time (typically the 2nd 4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Following is the preliminary meeting agenda. First we'll have to fill the empty spot. After a short upgrade on EAPI-3 implementation we will discuss the removal of old eclasses, followed by our old friend GLEP 55. If we still have time we can dive into the topic of general EAPI development. Approval/voting of new council member replacing Donnie Berkholz --- Unfortunately Donnie resigned as a member of the council (for details please read his mail on the g-council ml). Next in line are ulm and ssuominen. EAPI 3: Short discussion of the progress zmedico will provide an update on the progress of the implementation. Short discussion of problems and implementation decisions if needed. Removing old eclasses - Goal: Decide whether developers are allowed to remove eclasses. Problem: Upgrading using portage with a version before 2.1.4 will fail since portage always used eclasses from the tree instead of the ones from environment.bz2, even though the environment fail has been generated. Portage 2.1.4 got stabled over a year ago. Handling EAPI versioning in a forwards-compatible way - Goal: Discuss whether one of the alternatives given in GLEP 55 is appropriate to solve the problem. Decide which one should be chosen. Define EAPI development/deployment cycles - Goal: Start discussion about EAPI development/deployment. For example: Collect problems of eapi introductions in the past, like reverting ebuilds to former eapis to get them stable, not waiting for the pm support a certain eapi before requesting stable keywords for ebuilds using the new eapi, Collect problems of EAPI development like feature-freeze, late feature removals (due to implementation problems). Eventually develop a lightweight EAPI development model. Cheers, Tiziano -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New app-eselect category?
Hello, I am the student doing the Universal Select Tool for this year's Geetoo's SoC. On Tue, 2009-05-26 at 16:35 +0200, Philipp Riegger wrote: How will that tool be called? Maybe uselect? Everything points out to that until now. =) The way it's done, current eselect modules can continue working with uselect with very few changes needed. I didn't want to add full backwards compatibility because the utilities are slightly different and therefore creating the sense that uselect is not yet another eselect. At this time (SoC starts in a few hours) the prototype is written in python, does everything eselect does and supports any scripting language for module's actions. Oh, it's extremely faster too. Drop me a line at [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool thread if you have any ideas. Thank you! Cheers, Sérgio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: sci-geosciences/osm2mp
Hanno Böck wrote: osm2mp was a tool needed for conversion of openstreetmap maps into an intermediate format, which could be used for further conversion into garmin maps with mkgmap. Latest versions of mkgmap accept osm files as an input, osm2mp is not maintained and imho not of any use nowadays, so I'll remove it soon. Where's the gentoo-dev-announce mail and why not use the customary month? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: net-analyzer/ns and net-analyzer/nam
Federico Ferri wrote: # Federico Ferri mescali...@gentoo.org (26 May 2008) # Deprecated cause depending on unmaintained dev-tcltk/otcl. # Everything being moved to 'abandonware' overlay. # Possible replacement: net-misc/gns3 (sunrise overlay) # Going for removal in ~30 days if no one objects. # removal bug #271305 net-analyzer/ns net-analyzer/nam # Federico Ferri mescali...@gentoo.org (26 May 2008) # Unmaintained upstream. # Going for removal in ~30 days. # removal bug #271307 dev-tcltk/otcl dev-tcltk/tclcl gentoo-dev-announce please signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
lx...@sabayonlinux.org wrote: So, :: vs @ apart, is it something that is worth looking and implementing in future EAPIs? I don't see the main tree referring to other repositories any time soon so this is not a pressing issue. But as said earlier this makes sense for /etc/portage stuff so there going forward seems prudent. I suggest using :: as it's more established in these circles. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New app-eselect category?
2009/5/27 Sérgio Almeida meph...@gmail.com: this time (SoC starts in a few hours) the prototype is written in python, does everything eselect does and supports any scripting language for module's actions. Oh, it's extremely faster too. You have a working prototype right now? Awesome! Where's the ebuild for it? -- ~Nirbheek Chauhan
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
Am Montag, den 04.05.2009, 22:01 +0100 schrieb Sérgio Almeida:
Gentoo Dev's,
My name is Sérgio Almeida, I am Portuguese and I am a student for this
year's Google SoC coding the Universal Select Tool project for Gentoo
being Sébastien Fabbro (bicatali) my mentor.
Abstract:
Universal Select Tool is an utility to manage system configuration.
This tool is similar to the unmaintained eselect utility of Gentoo or
Exherbo's eclectic. The idea is to create a tool that manages both
system settings and user settings with profile creation possibilities.
The utility will use mostly concepts from modules, softenv, and
both eselect and eclectic.
My initial proposal does not get in-depth with implementation details
and I need to make some decisions as soon as possible. Implementation
language will be python as it is easy to maintain, easy to code and
faster and more flexible than bash. See attachment for more details.
Besides introducing myself, the purpose of this e-mail is a
call-to-ideas to all Gentoo developers, mainly all eselect-* and
*-config developers.
Here are the main interest ideas:
* keep eselect structure of modules - actions
* symlinking, environment and aliases actions can consist of something
like:
# module moo comments
description Example Module description
version Example Module Version
author m...@farm.moo
# action system moo
description Moo Action Description
symlink regexp regexp
env regexp regexp
alias regexp regexp
# end moo
These should get the job done for most of the modules and opens the door
to automatic module creation prior to a successful emerge (if some USE
flag set)
* Actions that consist of code blocks that support any scripting
language (what about binaries?) to do more complex actions (full module
example):
# module moo comments
description Example Module description
version Example Module Version
author m...@farm.moo
# action user moo
description Example Module will moo for any user
type runnable
runner /bin/bash
# file moo.bash
#!/bin/bash
do_moo() {
echo This is the Example Module mooing
}
do_moo()
# end moo.bash
# end moo
* actions can be run system-wide and per-user:
# action user moo
# action system moo
* automatic module loading and profile management can be managed by some
env.d python scripts that are user-aware and follow some database
I've been given this difficult task of unifying all of these tools
together and as you all can understand, I won't be having the time to
read through all eselect-* modules and *-config utilities code.
Please drop me a line here or at freenode if you have anything to add to
these ideas or have any further ideas that can help me on this project.
Thank you all in advance.
What I'd like to see is the possibility to
... localize messages (will be difficult since modules need translations
as well, but maybe you find a way :)
... encapsulation of methods to set/list/change such that instead of a
CLI- a NCurses- or GUI-Frontend could be developed.
Cheers,
Tiziano
--
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New app-eselect category?
On Wed, 2009-05-27 at 01:19 +0530, Nirbheek Chauhan wrote: 2009/5/27 Sérgio Almeida meph...@gmail.com: this time (SoC starts in a few hours) the prototype is written in python, does everything eselect does and supports any scripting language for module's actions. Oh, it's extremely faster too. You have a working prototype right now? Awesome! Where's the ebuild for it? Hello, There isn't yet. The code is still pretty ugly and I'm still refactoring to the new architecture before I can make it public (or even officially git it). I will post it on this mailing list as soon as experimentations are possible. As a teaser... sym /usr/src/linux /usr/src/ linux-(.*) This is all that the kernel module needs so that it can list available options, select a new option, view the current option. The new uselect Kernel module has 10 lines instead of eselect's 100. Cheers, Sérgio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
On Tue, 2009-05-26 at 22:04 +0200, Tiziano Müller wrote:
Am Montag, den 04.05.2009, 22:01 +0100 schrieb Sérgio Almeida:
Gentoo Dev's,
My name is Sérgio Almeida, I am Portuguese and I am a student for this
year's Google SoC coding the Universal Select Tool project for Gentoo
being Sébastien Fabbro (bicatali) my mentor.
Abstract:
Universal Select Tool is an utility to manage system configuration.
This tool is similar to the unmaintained eselect utility of Gentoo or
Exherbo's eclectic. The idea is to create a tool that manages both
system settings and user settings with profile creation possibilities.
The utility will use mostly concepts from modules, softenv, and
both eselect and eclectic.
My initial proposal does not get in-depth with implementation details
and I need to make some decisions as soon as possible. Implementation
language will be python as it is easy to maintain, easy to code and
faster and more flexible than bash. See attachment for more details.
Besides introducing myself, the purpose of this e-mail is a
call-to-ideas to all Gentoo developers, mainly all eselect-* and
*-config developers.
Here are the main interest ideas:
* keep eselect structure of modules - actions
* symlinking, environment and aliases actions can consist of something
like:
# module moo comments
description Example Module description
version Example Module Version
author m...@farm.moo
# action system moo
description Moo Action Description
symlink regexp regexp
env regexp regexp
alias regexp regexp
# end moo
These should get the job done for most of the modules and opens the door
to automatic module creation prior to a successful emerge (if some USE
flag set)
* Actions that consist of code blocks that support any scripting
language (what about binaries?) to do more complex actions (full module
example):
# module moo comments
description Example Module description
version Example Module Version
author m...@farm.moo
# action user moo
description Example Module will moo for any user
type runnable
runner /bin/bash
# file moo.bash
#!/bin/bash
do_moo() {
echo This is the Example Module mooing
}
do_moo()
# end moo.bash
# end moo
* actions can be run system-wide and per-user:
# action user moo
# action system moo
* automatic module loading and profile management can be managed by some
env.d python scripts that are user-aware and follow some database
I've been given this difficult task of unifying all of these tools
together and as you all can understand, I won't be having the time to
read through all eselect-* modules and *-config utilities code.
Please drop me a line here or at freenode if you have anything to add to
these ideas or have any further ideas that can help me on this project.
Thank you all in advance.
What I'd like to see is the possibility to
... localize messages (will be difficult since modules need translations
as well, but maybe you find a way :)
... encapsulation of methods to set/list/change such that instead of a
CLI- a NCurses- or GUI-Frontend could be developed.
Cheers,
Tiziano
Hello,
These are the reasons of my current prototype refactoring phase. All
this will be possible.
Thanks!
Cheers,
Sérgio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: better support for binary packages
For the record: Fabio (lxnay) and I had a chat on IRC and cleared some things up. He also reproduced the problem I had encountered with mixed portage/entropy usage, and concluded that it was a bug in entropy. I'm glad we got to a constructive point. So things turn out not to be as bad as I was initially led to believe, and I'll give the entropy approach the benefit of the doubt. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] New app-eselect category?
Le 26/05/2009 22:43, Sérgio Almeida a écrit : Hello, There isn't yet. The code is still pretty ugly and I'm still refactoring to the new architecture before I can make it public (or even officially git it). I will post it on this mailing list as soon as experimentations are possible. Please do try to make it available somewhere (even if only with a dumb live - git ebuild) so that we can actually try it out. I can't remember when was the last Gentoo GSoC project that we were actually able to use/see/build... Good luck for your Summer of Code :) Rémi
Re: [gentoo-dev] New app-eselect category?
AllenJB wrote: I'd favor tags over increasing the category levels, tho I'm not convinced either is necessary at the current time (tho tags might make searching easier, in some ways). Heck yes! Tags are a good idea. The idea's been raised on -dev a few times. I suppose they're not (yet) essential, but from a user point of view, if the tools supported searching for tags buried in metadata.xml, it would make life much, much nicer. And if wishes were horses . . . maybe one day we'd all ride. Or at least argue about what shade of pink to paint the ponies. :p signature.asc Description: OpenPGP digital signature
