Re: [gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two
Mint Shows wrote: This feature should only be used for things that are directly related to the tree, and will cause mass breakage if ignored. I fully agree with this statement. I am behind the adoption of the GLEP only if it does what (I originally believed) was its purpose...to get CRITICAL news regarding package upgrades..etc. If a user wants to know what's going on with the developers..they can subscribe to this -dev list. If a user wants to know how to NOT break his system by performing an 'emerge -u world' portage should tell them. -- Mint Shows I fully agree here, or in the case of Apache, which my its self is not a critical system component, but its is a very important part of many user's systems, that is also worthy of a NEWS Item. On another note, i'm not exactly sure how this would be implemented, but perferably wouldn't the new NEWS Items be best if provided before a package upgrade? for example emerge -avu apache These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuildU ] net-www/apache-2.0.54-r31 *(1 News Item) [2.0.54-r30] +apache2 -debug -doc -ldap -mpm-leader -mpm-peruser -mpm-prefork -mpm-threadpool -mpm-worker -no-suexec (-selinux) +ssl -static-modules -threads 5,488 kB Total size of downloads: 5,488 kB Would you like to read the unread News Item? [Yes/No] Do you want me to merge these packages? [Yes/No] Of course, running emerge -vu apache shouldn't be stopped, it should continue with its own risk. Thats just one thing i would like to see. Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
Kurt Lieber wrote: We have received *numerous* complaints from users about the decision to remove stage 1 and 2 from the installation documentation. I realize it's still available if users are willing to dig for it, but not all users do. In my years of monitoring [EMAIL PROTECTED], we've received the most complaints about this decision than any other single decision. Is there a way we can re-introduce the stages into the installation documentation, perhaps with gigantic warnings saying, "for advanced users only" or "use at your own risk"? --kurt (I've read all of the comments up until now, but my response is not directed at any particular post.) Facts: (according to me, and what I've read) -The releng team DID make a good decision by making stage 3 default in the instructions. -The releng team _DID_NOT_ do a sufficient job of making the community aware of the changes BEFORE they occurred (I didn't know about this change until after it was done, and Gentoo.org is my home page, I read the GWN) -Stage 1 & 2 tar balls and instructions ARE available OPINION: - This change should be GLEP'd, as it effects everyone that installs Gentoo (to some degree, most do not suffer tho) - Stage 1 SHOULD continue to be released and maintained, instructions clearly stating risks and LACK of SUPPORT and easily visibility from the install docs (which it seems it does not have (according to posts), although, It is perfectly clear to me.) to the releng team: Good Decision, Bad Execution Thats whats leading to this entire reaction. Andrew www.leetworks.com [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Chris Gianelloni wrote:
On Tue, 2005-11-29 at 15:01 +, Mike Williams wrote:
On Monday 28 November 2005 14:22, Mark Loeser wrote:
This is basically a heads-up email to everyone to say that we are probably
going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the
archs that have already done the move from having 3.3 stable to 3.4 could
give us a heads up on what to expect, that would be great. Only thing I
see as lacking is we might want to get a doc together on how to properly
upgrade your toolchain so we don't get an influx of bugs from users that
have a system half compiled with 3.3 and the other half with 3.4 so they
get linking errors.
Shouldn't this be a profile thing? i.e. 200{4,5}.X stays at 3.3.X, 2006.X-> go
to 3.4.X
Nope.
While it would be possible to limit it to a specific profile, it really
makes it a pain in the ass, especially for two versions that are almost
compatible, as opposed to the profiles that we have done in the past
where we were going from things like gcc2 to gcc3, that were not very
compatible, at all.
Out of curiosity, if this goes into effect before 2006.0 is released,
then ALL the stages for x86 and the livecd would be built with gcc34? If
so then I think this may benefit alot of users, especially ones that do
a stage1/2 just so they can shove gcc34 into there system at an early
stage. Also, if gcc34 gets moved to x86, would gcc40 be ~x86? This I see
as a bigger problem for those of us that are already running gcc34. But
I'm sure many ~x86 users would welcome that, after all what fun is ~x86
without some breakage every now and then ;-)
Greetings,
Tuxp3
Andrew Muraco
www.leetworks.com
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Wernfried Haas wrote: On Wed, Nov 30, 2005 at 01:56:40PM -0500, Mark Loeser wrote: Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I don't think a whole doc is necessary, but instructions for a safe upgrade would be fine. A think a one-liner like emerge -u gcc && emerge -e system && emerge -e world && emerge -P gcc && emerge whateverneedstobedoneafterwards should suffice as documentation. I believe adding "It is recommended that you `emerge -e system && emerge -e world` after merging gcc-3.4" to the einfo at the end of the gcc-3.4.4 install should be good enough. Maybe people look closer if they upgrade gcc, but einfo still gets overlooked easily. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. Assuming a clear upgrade path is provided i think it would be fine. We'll make some sticky thread on the forum mentioning that instructions, i bet it couldn't hurt to put them on the gentoo mainpage, as topic in #gentoo etc. I'm also pretty sure next GWN is likely to report about the update. Just because we haven't got emerge --news it doesn't mean we haven't got lots of ways to reach our users. Every user that gets to read them in time is a potential bug report less. cheers, Wernfried Personally, I would set a date next week, so that way GWN and other places can be prepare for this, a definate date for users to know that it IS going to happen, and I personally think that a sticky on the forum (i would even be willing to write a little something, but i'm no expert) is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world && emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. just my $.02 Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Mark Loeser wrote: Andrew Muraco <[EMAIL PROTECTED]> said: is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world && emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. That makes me feel a bit more comfortable. I still think that something more then an einfo warning should be provided, as its easy to overlook those. Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Georgi Georgiev wrote: maillog: 30/11/2005-15:16:35(-0500): Andrew Muraco types Mark Loeser wrote: Andrew Muraco <[EMAIL PROTECTED]> said: is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world && emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. That makes me feel a bit more comfortable. I still think that something more then an einfo warning should be provided, as its easy to overlook those. So make gcc-config produce warnings when changing the compiler. "Switching to gcc-MAJOR.MINOR may break your system. Upgrade instructions can be found at http://thedoc"; Trigger the message only when switching minor versions. I like that idea alot actually. Perhaps also include in that warning message that switching back is OKAY aslong as nothing has been compiled with the new minor version. :-P I vote for this choice. Greetings, Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Creating a Sketeton System
George Prowse wrote: After some talk in the forums a point came up that we need a way to reduce the long used gentoo system to a bare point before X but after any baselayout upgrade had been applied. Isn't that what the stages are, Barebone systems? This script would enable two things: a person to rebuild his system after a library malfunction and also if a person wanted to switch from 100% gtk to 100% qt or vice-versa. At present we have depclean to reduce anything past xorg-x11 but that doesn't get as far as anything that doesn't rely on a package being able to depend on an GUI, libraries need to be brought in and all but baselayout needs to be cleaned out so a "bare bone" is left. Why not just move world out of the way and then emerge what you want to keep/install then emerge depclean the rest (although this could easily fubar a system if they do it blindly removing important system packages) This would be useful as an arch tester because snapshots could be made of various stages and tested. George Tux Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. -- Jason Stubbs Your Point is Moot because an overlay (at present) is going to be exprimental software, (unsupported offically anyways) and so you _should_ know what risks your taking, this GLEP is to warn you about supported updates/changes which you _need_ to know about. Why should an overlay need to have news if the user has the consciensely update and maintain it to begin it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
Ciaran McCreesh wrote: Ok, new draft. Changes are as follows: I Think That You've tweaked this GLEP to death ;-) Anyways, I can't wait until everybody is happy with it and it gets moving, because I know that gcc 4 and qt4 and glibc 2.3.6 are right around the corner, and those would be great chances to use this new news dohicker and see how it goes. Thanks for the continuous hard work on this, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five
Ciaran McCreesh wrote: Ok, new draft. Changes are as follows: ... * Added emerge --ask thingie Perhaps it would be a good idea to have an extra prompt during -av and a forced prompt (perhaps with a timeout) for just plain old emerge. And to make people that just don't care happy, a FEATURES="nonews" for making portage ignore news. Just an idea to add some more redunancy in the way news is delivered. comment on multi-repo support: -Perhaps someone should write a formal GLEP for multiple repo support before we get flustered over that here. Greetings, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Multiple Repo Support
As i sit reading the current list of list emails about GLEP 42 I see that the topic of Multiple Repos coming up over and over again. I wanted to ask to see where that support is, and based on what feedback help move along so that a standard can be produced. So, now with a few short questions: 1. Would Multiple Repo support be GLEP worthy? 1.1. If so, Should I write a GLEP, or poke at some dev to do it? (i'm more then willing and able to write a GLEP if that is what is required.) 2. What choices/options are on the table for this feature? 2.1. Which routes are more likely to be implemented? 2.2. Which method would you like to see? 2.3. Does backwards compatiblity really matter, as long as it doesn't break people that are using older portage? (ex. once portage is upgraded it will move x to y/x and so older versions wouldn't work, but since only the new version would be installed it wouldn't be an issue.) Now, that I've asked for some information I want to share one (hackish, I guess) way that it could be done with minimal changing. in /etc/make.conf: RSYNC_REPONAME="rsync://.../" with RSYNC=" .." being defaultly called 'gentoo' or 'portage' that REPONAME would be used for the tree's folder name /usr/repositories/REPONAME/ and 'emerge sync REPONAME' would sync only that repo, or 'emerge sync [all]' would sync all Anyways, thats just a quick thought I had on the topic. Flames, comments, questions (and answers) welcome Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
Curtis Napier wrote:
Ciaran McCreesh wrote:
On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <[EMAIL PROTECTED]>
wrote:
| 2. What choices/options are on the table for this feature?
The big controversy seems to be over whether repositories carry a
unique identifier string (for example, in metadata/repository_id) or
whether it's user-assigned. The former is clearly the more sensible
option, since it lets you do things like (syntax made up):
DEPEND=">=foo-bar/baz-2.1::ciaranmssekritrepo"
which would add a restriction that only packages in ciaranmssekritrepo
would be considered. This only works if the repository knows its own
identifier, however...
Incidentally, the ::repo syntax (or whatever) would also be useful in
the world file, along with :slot. So something like:
foo-bar/baz:2::ciaranmssekritrepo
would tell the package manager that you want baz SLOT 2 from
ciaranmssekritrepo.
*shrug* But it seems the Portage guys want repository names to be
user-assigned, which makes them far less useful.
This functionality would come in very very handy. Would user assigned
repository names be able to mimic this functionality somehow?
What about giving each repo an identifier? That way repos with ebuilds
can have the repo_id in the ebuilds and not have to worry, repo_ids
would take precedence when in conflict. Identifiers would just be
provided for user-stuff, like ex # emerge sync MyRepo or # emerge -av
MyRepo://foo ? [foo being the name of a package in repo tree with the
identifier of MyRepo]
what about having a portage config file
/etc/portage/repositories:
priority MyRepo,gentoo
repository {
identifer = "gentoo"
rsync= "rsync://../"
repo_path= "/usr/portage"
}
repository {
identifer = "MyRepo"
rsync= "rsync://../"
repo_path= "/usr/MyRepoTree"
}
(an example for someone that wants to have MyRepo be prefered over
gentoo tree)
Just tossing out ideas,
Andrew Muraco
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] DRAFT GLEP: MULTI-REPO
Attached is a draft of a glep for formalizing multiple-repository support This is far from ideal in many ways, but i'm too tired and I drank too much caffine to be sane. Also, i have no clue how to use docutils so i just tried my best. (** is my way of doing another level of bullets, please let me know how to properly do this) Comments, objections, anything consructive is welcome. Thanks, Andrew Muraco GLEP: XX Title: Multiple Repository Support in Portage Version: $Revision: 1.0 $ Author: Andrew Muraco <[EMAIL PROTECTED]> Last-Modified: $Date: 2005/12/17 03:13:10 $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Dec-2005 Post-History: 17-Dec-2005 Abstract To implement a functional and expandable method for Portage to support multiple repositories. Motivation == Multiple Repository support is needed, this GLEP is to address this need. Specification = Portage will make use of two (2) ways to address repositories: * A User-defined name, which is likely to be used as a convinance in most situations - this will be referred to as REPO_NAME in this GLEP * A hard-coded repository-id which will be found in the repository tree at: metadata/repo_id - this will be referred to as REPO_ID in this GLEP Both names will contain no spaces, and only standard characters [TODO: references] Repositories Each repository will contain: * the repo name in metadata/repo_id * repo information such as maintainer of the repo, notes on who hosts it, etc will be contained metadata/repo_info * unique packages.mask which will only apply to ebuilds within that specific repo. The REPO_ID must match the name that will be used for rsync Therefore, rsync://MyServer.tdl/REPO_ID/ /etc/portage/* - In order to provide users with the current set of options and extend them so they can be customized to each repository, the structure of /etc/portage will remain similar with these changes: * /etc/portage/REPO_NAME/* will be the location of repository-specific portage files. * /etc/portage/ will continue to function over all repos ** ex) =sys-devel/gcc-4 -* in /etc/portage/package.keywords would use the latest gcc-4 regardless of what tree it comes from. The following new files will be added to /etc/portage: * /etc/portage/repositories.perfer - will contain each REPO_NAME in order of preferance, higher is more perfered. (Each REPO_NAME will be on a seperate line) ** In the absence of this file portage should use repositories in alphabetical order. * /etc/portage/REPO_NAME/repository.id - contains the specific REPO_ID which REPO_NAME applies to. */etc/portage/REPO_NAME/repository.conf - will contain any repository-specific options, which can include, but is not limited to, FEATURES="" C[XX]FLAGS="". ** This will also include a new variable; OPTIONS="" of which is similar to FEATURES, but modifies the way portage will handle that specific repository. A few examples of options which could be useful: *** EXCLUDESYNC - Prevents portage from doing a sync on this repo. *** EXCLUDEUPDATE - Prevents portage from using ebuilds in this repo as updates for packages which currently reside in a different repo. *** EXCLUSIVEUPDATE - forces any update to any package which is from this repository to a newer version which resides inside of this repo. *** et al. All of the repository rsync URIs will be stored in /etc/make.conf SYNC="rsync://myfavoriterepo.org/myportage \ rsync://rsync.namerica.gentoo.org/gentoo-portage" The Tree: /usr/portage -> /var/repositories/REPO_ID/ -- The repository tree will need to be moved, each repository will have its own folder: /var/repositories/REPO_ID/. For compatibility reasons, /usr/portage will be treated as /var/repositories/gentoo-portage Ebuilds --- Ebuilds will now be able to have dependencies based on packages from specific repositories. * DEP Atoms now support the following format: =REPO_ID:SLOTNUM:CAT/EBUILD-X.Y.Z ** Ex1) >=MyRepo:2:sys-devel/gcc-4.0 ** Ex2)
Re: [gentoo-dev] DRAFT GLEP: MULTI-REPO
I apologize for the caps in the subject. Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Petteri Räty wrote: Bastiaan Visser wrote: On Monday 26 December 2005 09:33, Mike Frysinger wrote: On Monday 26 December 2005 02:24, Doug Goldstein wrote: well there is always USE enabling... (i.e. When I emerge x11-libs/qt, it'll turn on the "qt" USE flag) which we've already established quite clearly as something we wish to get rid of completely -mike aint it worth it to mention "-*" in the handbook ? And then mentioning stuff like pam that almost everyone wants? There are also things that should be on by default. Regards, Petteri Actually, Pam is a pain for me and i always turn it off. But thats just my $.02, alot of the very specific use flags shouldn't be turned on by default. Which ones need to be removed is up to _a_lot_ of discussion. -Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Lares Moreau wrote: On Mon, 2005-12-26 at 12:36 -0600, Joe McCann wrote: For the record, the eds flag was added as a default flag because every 3rd gnome user would file bugs or complain via forums because they installed gnome, found no evolution-data-server integration, and then be bummed when they had to recompile packages again. This whole thread seems to have come from a misunderstanding of how use.defaults work and 20 min of boredom. I'm relatively ignorant of USE Flag intricacies, so please forgive me if things don't 'fit'. Is it feasible and or useful to have a 'meta-flag' that that enables all the 'necessary' USE flags for a given group of packages? So something like USE='meta-'. This has the distinction of being a meta-flag, and as such nothing really gets turned on 'behind the users back', advanced users can look into it and see what is being enabled by it and USE='-flag' for the flags the users doesn't need/want, and expert users would just not use it. This way meta packages like KDE and Gnome can have their own meta-flag to do what the need with. It also seems to me that more things will need to 'just work' as our user-base becomes larger and, on average, less advanced. We could amend the desktop guide to include something like USE='meta-gnome' to the gnome section. And similar to other meta-flags. This may add an unnecessary level of complexity to the use flag system, but also may be very useful. If I remember right theres a GLEP (#29) that purposes to do something very similar (USE Groups I think it was called), but I believe its withdrawn. Regards, Andrew Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] relocation.
Curtis Napier wrote: 051230 John Mylchreest wrote: as of tonight I pack up my most valued of possessions -- my computer kit -- and get ready to board a one-way ticket to York. I guess that means I won't be the only American in ##uk anymore. ;-) Have fun in New York John! I live in Buffalo, NY (the other side of NY) but maybe its high time we had some gentoo meet for the region. Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] relocation.
Benjamin Judas wrote: Am Samstag 31 Dezember 2005 16:10 schrieb Lares Moreau: Uhh.. in this case. I don't think York == NewYork maps.google.com | search 'York UK' just FYI -Lares Some americans have a limited horizon, you know ;) ... just a flat new-years joke, folks ;) ... I know that New York isn't the only 'York' but.. Curtis Napier wrote: I guess that means I won't be the only American in ##uk anymore. ;-) Have fun in New York John! leads me to think that it might just be New York that he is referring to. Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Chandler Carruth wrote: Lance Albertson wrote: Yeah, maybe so :-) Reflecting on this more, I see that most of the council members are a very important part of the active Gentoo development model (toolchain, etc). They need to keep those roles active as much as possible, then help on the council. I guess I view this person as a sole chairmen of the board that just focuses on council type duties and roles. I think the current council has lots of great people, but they're all busy with their subprojects and can't take on a role like this. We really need a single voice to bind everything together, but doesn't have total control like Daniel did. Hopefully I'm making sense.. As perhaps a good way of thinking of this, the common term used in commitees (as I have interacted with them in various beaurocratic situations) is a "non-voting chair". This person would organize, schedule, direct, communicate, and facilitate the work of the committee, to allow the voting members to more effectively handle the issues arising for the committee. The voting members need not take on much of a workload to vote and serve on the committee because most (if not all) of the time consuming tasks and aspects of the committee are handled by a non-voting chair. Simultaneously, the singular nature of the chair is less of a concern because they are non-voting. The lack of a vote checks their singular power, while still allowing them to very efficiently organize and direct information in and out of the committee. *shrug* I'm not entirely sure that I agree or disagree with this solution, but wanted to give an example of what (I think?) Lance is getting at here. I'm not sure if this would apply, but in the US Government System, the supreme courts are basicly a committee (or council, which ever word you like better), the "leader" (Chief Justice) of the supreme court doesn't have any extra power, but has extra duties, and has senority over the other Justices. Perhaps a situation like that would the Gento Council, or maybe it should stay in the Justice System. wkr, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Lares Moreau wrote: On Tue, 2006-01-03 at 18:19 +0100, Simon Stelling wrote: My point is, either you have to generalize each project's goal to a real triviality or you have to define a goal which doesn't match some project's goals. Conclusion: Let it be. Maybe we are looking at this problem the wrong way. Instead of trying to have Gentoo be the distro, perhaps Gentoo can be thought of as a provider of infrastructure and tools to allow 'sub-distros' to flourish. THere are many projects which now are trying to pull Gentoo in many different directions, such as bianary distro vs. enterprise distro. If we remove "Gentoo as distro" from out thinking and replace it with "Gentoo as provider of tools and infrastucture", These two seemingly contradictory goals can each flourish in their own way. Haveing sub-distros, lack of a better term, is not new to Gentoo. Hardened has their own LiveCD, profile and tools. I feel this can be nurtured. Allowing the Binanary group to move in one direction, and 'tweakers' in an other, and die-hard security people in yet another, while not severely conficting with each other. Maybe what we need is a clearer definition of what each herd does? I am considering writing a GLEP about this, having each herd answer three questions periodicly (say 6mths). - What do we want to do? - How are we going to get there? - How to we measure success? and /maybe/ add a section about current devs and AT/HTs. Just a thought. I like your idea of having gentoo not being a distro, but moreso a collection of tools. Mostly because gentoo's method of dealing with problems (problems that binary distros tend to have, like keeping software uptodate) are handled in a way thats just a tad more managable, plus when multiple repo support gets added, its just another way that gentoo can be customized and reflavored. +1 for that thinking Tux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
Hi, I was recently reading this post [1] about gentoo's future, it mentioned a few items in relation to enterprise Gentoo, and that it currently needs features that just aren't available yet. One such example of a feature thats not available yet is GLEP 19: Gentoo Stable Tree [2]. Now, I notice that it is over a year old since last edit, and that it is still Draft, not Differed or Rejected. So, I propose to change it in hopes of making it a feasible, implementable idea. The part of this GLEP that specifically is the issue, and making it unable to be voted on, is the section concerning the exact details of how/where the 'stable' tree would be located; currently this GLEP lists a few ideas but settles on using KEYWORDS="stable". However, the point was brought up (and noted inside of the GLEP) that in order for that new keyword to work for independent archs, it would have to be 'stable:arch'. So, I am here to say 'No' to that idea. Specifically because I believe it will make dev even greater then what it currently is. Hence I propose that instead of a separate tree based on these 'stable:arch' keywords, the existing tree is used /with/ a new keywording system: KEYWORDS="+arch" will denote these stable ebuilds. Also, in order to prevent excess dev-work and to make a predictable cycle, the following will also occur: prior to the release of the year's .0 media (ex 2006.0) a script would be ran that add +arch for each arch keyword (max one +arch per arch). Over the course of time, major bug fixes and security updates would allow for items to be marked +arch quickly, without necessarily waiting for the next media release. When the .0 media is released, it would include the usual portage tree in tar.bz2 which will serve as a static place for enterprise to install Gentoo from. All security and Major bug fixes would be included in .1 and .2 releases, but the vast majority of the tree would remain the same over the course of the year (enterprise's goals). Also, a few items which can be considered for this stable tree: - using a simple script it would be possible to make a copy of the tree which only contains these +arch entries, this could be used to make easier to manage tar balls of the stable tree for distribution to clients. - the existing portage code would consider +arch as a subset of arch, the reason both keywords will exist is to maintain compatibility with older versions of portage which will not recognize this. Anyways, I would personally like to see if this can stir some interest. I would be willing to help test and help make this GLEP a reality, however I can not implement this myself as I lack python skills, but I do want to help the portage team, as much as I can, to make this happen, as I have some great benefit from this added feature. Also, I hope I covered everything, and if the response from the mailing list is good I may consider revising the existing GLEP and prepare it for submittal to the council in feburary, or march, depending on how much revision the GLEP needs, and if my idea is better or worse then the current solution proposed. Thanks for taking the time to look at this, Please respond with personal opinions (+ and -) Andrew Muraco Tuxp3 [1] http://article.gmane.org/gmane.linux.gentoo.devel/34870 [2] http://www.gentoo.org/proj/en/glep/glep-0019.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
noticed something that doesn't make any sense: Andrew Muraco wrote: - the existing portage code would consider +arch as a subset of arch, the reason both keywords will exist is to maintain compatibility with older versions of portage which will not recognize this. would make more sense as: - portage should consider +arch as a subset of arch, however, the reason both keywords will exist is to maintain compatibility with older versions of portage, which will not recognize this new keyword. Thanks, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo "Stable" Portage/Releases
Chris Gianelloni wrote: First off, let me just say that this was just an idea I'd cooked up a while back, so I am sure there's lots of holes in it for you guys to rip apart. Anyway, without further ado... The proposal is quite simple insofar as it requires no changes to portage, whatsoever (though there are possibilities to make extensions to portage). It introduces no new KEYWORDS and adds no load on the current ebuild developers, other than those that wish to work on the stable tree. Allow me to explain. First, there is the creation of the "release" tree. This tree is tied to a specific release of Gentoo Linux. The tree is based on the release snapshot used to build the release. The tree consists of the highest version stable ebuild per slot and architecture for each package. This means if there is no stable version of, say, vmware-player, then the entire package is omitted. For things like GTK+, there would be at least 2 versions in the tree, since there are 2 slots and both are stable on at least one architecture. By only limiting the tree in this manner, it can be built entirely by a script and require no manual interactions to repair dependencies, etc. So let's imagine that 2006.0 is rolling around. The 2006.0 snapshot is frozen, and the release-building begins. This snapshot tarball is run through our "stable" script, and a new gentoo-2006.0 CVS module is created. A corresponding rsync module is created for this tree. I like this Idea alot actually, the only think I can see as a downside is that the SYNC=".." could be changed accdentally, making it just another Gentoo tree. Another thing that I don't like, is the feel of this method does seem "offical" enough.. mostly because portage is not 'stable'-aware, Its just using a stripped down tree. I think your idea is good, its just the details that need to be worked out, (how long to keep the trees?) My little piece on GLEP19 seems to have just been obsoleted. Perhaps more people could respond so we can see how everyone feels (I want this route.) Tux To facilitate "enterprise" usage, we break up the releases into a "desktop" and "server" set. This means the current "default-linux/$arch/2006.0" profile would be "default-linux/$arch/2006.0/desktop" with a "default-linux/$arch/2006.0/server" profile, also. The stages would be built against the "default-linux/$arch/2006.0" profile, which would have any USE, etc. that are common between desktop and server. During installation, the user can choose to use either the desktop or server profiles, or stay with the more "generic" 2006.0 profile (good for developers, etc. that might need components of both, or want a more minimal default set of USE flags). The desktop and server profiles will have a defined set of default USE flags that will benefit the most people, similar to how the current profiles are designed to be "desktop" profiles, to benefit the most people. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo "Stable" Portage/Releases
Chris Gianelloni wrote: To facilitate "enterprise" usage, we break up the releases into a "desktop" and "server" set. This means the current "default-linux/$arch/2006.0" profile would be "default-linux/$arch/2006.0/desktop" with a "default-linux/$arch/2006.0/server" profile, also. The stages would be built against the "default-linux/$arch/2006.0" profile, which would have any USE, etc. that are common between desktop and server. During installation, the user can choose to use either the desktop or server profiles, or stay with the more "generic" 2006.0 profile (good for developers, etc. that might need components of both, or want a more minimal default set of USE flags). The desktop and server profiles will have a defined set of default USE flags that will benefit the most people, similar to how the current profiles are designed to be "desktop" profiles, to benefit the most people. Oh yea, I know how it would fit with GLEP 19 nicely, but I think you might want to make it a seperate issue. Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo "Stable" Portage/Releases
Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Muraco wrote: | Another thing that I don't like, is the feel of this method does seem | "offical" enough.. mostly because portage is not 'stable'-aware, Its | just using a stripped down tree. What do you want then? If an entire standalone tree distributed by Gentoo doesn't feel official enough, what will? What I meant to say is, having this alternative tree method (as described here) would mean that portage would handle everything the exact same as it already does, which means that if someother tree was accidently sync'd or replaced the local one, portage would react and want to update everything, because its not 'aware' that there is a difference in the first place. (now that I think about it, how likely is it that something like that will happen?) The method described here would also open up the oppurtunity for "fake" enterprise trees, without having something to double check that the tree that we have is indeed the one that is wanted, it would be possible for a hacked rsync server (or a bogus one) to host the enterprise (stable) trees with extra ebuilds which could compromise security (/me thinks of emails warning about Microsoft's patchs and links which point to infectious websites.) Maybe this is something thats not very likely to happen, but it still is important to note that an enterprise tree has to be secure. Wkr, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2006.0 - me having a bad day?
Kalin KOZHUHAROV wrote: Contgrats to the release team :-) But let me whine a bit, even a few KB: I just saw the GWN and the news about 2006.0 ... So reading at the release notes: This is also the first release with the Gentoo Linux Installer officially debuting on the x86 LiveCD, which will fully replace the Universal and PackageCD set. The LiveCD also features a fully-fledged Gnome environment. However the (normal) link to download it: http://www.gentoo.org/main/en/where.xml Shows: Gentoo 2006.0 Minimal install CD (around 125 megabytes depending on arch) alpha amd64 hppa ia64 ppc (32 bit) ppc64 sparc64 x86 Gentoo 2006.0 Universal install CD (up to 600 megabytes depending on arch) alpha amd64 hppa ppc (32 bit) ppc (64 bit) sparc64 Gentoo 2006.0 Package CD (up to 700 megabytes depending on arch) amd64 ppc (ppc) ppc (g4) ppc (64 bit - 32bit userland) ppc (64 bit - 64bit userland) sparc64 So there are the Minimal, Universal and Package CDs... No word of a LiveCD... No link to a Universal CD for x86... Browsing trough the torrents, there is a x86-livecd-2006.0 and x86-installcd-2006.0 ... yes, I figured out that x86-installcd-2006.0 is the "Gentoo 2006.0 Minimal install CD" for x86 or is it... will any n00b figure it out? And probably the properly(?) named livecd-amd64-installer-2006.0 and install-amd64-universal-2006.0 are here just to add some spice to the soup... Aha if I track all links in the bouncer, I start to understand... So, a link like that: http://bouncer.gentoo.org/?productgentoo-2006.0-universal&os=amd64 is for the Gentoo 2006.0 Universal install CD for amd64 arch - cool! And it will bring you to install-amd64-universal-2006.0.iso! So just s/gentoo/install/ and stuff the os=(.*) in the middle - a piece of cake. Aaah, however forget about the "Gentoo 2006.0 Package CD" - they have a naming on their own and its scheme is too difficult to explain in a long mail like that. Just to toss a random example: packages-ppc64-32ul-2006.0.iso comes for ppc (64 bit - 32bit userland) of a "Gentoo 2006.0 Package CD". The correspondence between "Universal install CD" and "install-", "Package CD" and "packageS" is a drill left to the reader :-) And we are talking consistency here, yes simple as that. There are probably(?) good reasons behind the naming of the iso files (the torrent list does not show the .iso, but who cares, once you stuff it in your client you'll see it is an iso, right!), but are they good enough for inconsistent naming? Or there is a scheme I cannot guess... They might be good reasons not to include the Universal instal CD (i.e. which one in the torrents? aha, probably after all there is no Universal install CD for x86, it is called a LiveCD??? or /me again wrong...) in the bouncer - sure that is the most wanted CD, but that eats the most bandwidth. Or is it because it was hard to write the XML of the page because it is a structured, clerly defined language and makes it difficult to use inconsistent naming of the iso files?? Well, if that was the reason... But who knows. I might be just having a bad morning transforming into a bad day... I din't have enough time or will to help with the release, so I can only whine out loud. If you've read so far, fell free to light up your flamethrower, I should be able to stand it, or simply turn to ash. Kalin. I second that there is a massive confusion of naming, and this needs to get sorted out (or atleast explained) Because I'm sure the mirrors will start getting slamed with people downloading 2006.0. Lets not waste anyone's bandwidth nor the mirrors by leading people to download the wrong thing. Regards, Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 0042 (news) final draft
Mike Frysinger wrote: On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote: Unless there are any huge flaws found, I'd like this to be voted on by the council -- looks like it'll have to wait until April's meeting to fit in with the two weeks rule. may push council meeting back to 3rd tuesday if people wish -mike Is this a resubmission? Or would it be the first time this GLEP is being presented to the council? Regards, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enroll users for testing packages
Daniel Goller wrote: On Tue, 2006-04-11 at 09:36 -0400, Stephen P. Becker wrote: Eldad Zack wrote: Hello, Sometimes it becomes a problem whenever a new release or a tricky bugfix comes up for a certain package. To improve QA we can let our userbase help, especially people who use certain packages quite heavily - they can provide good or even superior QA than devs. I think it would be a nice idea to keep a userlist for anyone who'd like to volunteer testing packages they regularly use. We can consider a web interface for enrolling users to specific packages, and maybe even get a bug.g.o account for the list, this way a bug can be opened for the testers to comment on whenever a change that requires testing or maybe just aiding arch teams to stablize packages. Maybe this was already pitched but it has just occured to me. Comments? Isn't this why we already have the arch tester position as described by GLEP 41 (http://www.gentoo.org/proj/en/glep/glep-0041.html)? Furthermore, are you saying that users would enroll themselves via this hypothetical web interface, or that an arch team would do so for users who have proven themselves to be worthy? If the former, this would be a serious step back in terms of QA (think about sorting out all the crap reports from ricer overlay users with OMGFAST CFLAGS from the decent ones). If the latter, I think the arch tester position already covers this sort of thing. -Steve didn't he ask for people who know a particular application very well? i think there is a big difference between agreeing to test one particular package since they know it very well and want to make sure noone breaks it vs. being a full AT with all the things they get asked to test I understand the idea, and I like it. However inorder to really get this to work smoothly and be useful some type of user-feedback tool that would help report back the exact build environment with times dates and warnings & errors + user notes would really make this type of system shine. For example, package xyz-1.1 comes out, and user is on this hypothetical list and gets notified of it. package xyz-1.1 is ~arch (given), user decides they want to test it and they emerge it the usual way. After emerging version 1.1, user should (inorder to give his report) run a tool that will send the ebuild's environment (CFLAGS, etc) and prompt for the user to it a "rating" (value of whether or not the package works) & give some notes (say, special requirments to make it work, or a patch, or just simply , "Works".) Anyways, I like the idea. +1 Regards, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Looking for a new media-sound/easytag maintainer
Daniel Drake wrote: Hi, Is anyone interested in taking over maintenance of easytag? I still use it, but am looking to free up some time for other things. It doesn't require much commitment: there aren't many bugs filed for it (none open at the moment either). Easytag 2.0 is just around the corner and will be the first GTK+ 2.x version to go stable (finally!). Daniel I also am a user on this app, the 1.99.x series, and can help out chris, but again i'm not familiar with the code base either. Thanks, Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Carsten Lohrke wrote: On Monday 05 June 2006 20:08, Harald van Dijk wrote: No, the decision with the gtk/gtk2 USE flag mess was to have package maintainers decide for each ebuild whether to support only gtk1 or only gtk2, but not have support for both in a single ebuild. I know about the decision of the Gnome team, but there also was a thread with maintainers refusing to remove optional gtk1|2 support, if I recall correctly. Personally I couldn't care less, as long as the gtk2 flag is history. Sorry for the offtopic of this, but what would a user set as the useflags to have GTK-2 used by default, and GTK-1 for apps that only support it? (but not build GTK-2-capable apps with GTK-1) Just wondering, because I know that gmplayer is from the mplayer package's gtk flag.. its gtk-1 so its not the optimal, but since i don't know of a gtk2 version (i do have kmplayer tho.. so its sorta a moot point for me.. i think its time i clean my install..) Anyways, I agree that some of the defaults are a bit more liberal then i would perfer, but hey, i can change anything i want (thats the power of gentoo) Thanks, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Who wants to tinker with a Palm Zire 71?
Steev Klimaszewski wrote: Noack, Sebastian wrote: Hi, I have a Palm Zire 71 device, with Palm OS on it and a 400 MHz ARM-Processor in it. Actually I don't use this device anymore, so if somebody wants try to get Gentoo Linux run on it, I would give it to him. There is an SD/MMC-Slot which could become used to get data on the devie an there is also an IR interface and a USB-Adapter. But the biggest problem I see is that the OS is on a ROM, but maybe there would be a way to manipulate the BIOS if it has one, to boot from somewhere on the RAM. In any case I guess it would require to maipulate the hardware. If somebody here have the skills and motivation to try that, he or she should tell me and I will send him or her my device. Best Regards Sebastian Noack I'd love to - if anyone else hasn't already claimed it :) I'll take his sloopy seconds, I've had enough of my original palm zire one that only has 2mb ram.. I think i might just be able to pull it off too :-D Tux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] dev-lang/icc and dev-lang/ifc maintainer position
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm interested in taking over the dev-lang/icc and dev-lang/ifc maintainer position, if no one is actively working on it, and i see that portage needs lots of work in this category, and i have worked with my own ebuilds of ICC to be able to say that its stable enough that we could have it updated in the tree with the changes needed in a few weeks. Things I Hope to accomplish as maintainer: - - make a new system profile, one specific for icc that will shift the default from gcc to icc for as much of the tree as possible, and would also turn on the icc use flag which would be only used in cases where a specific patch is needed for ICC to work (especially for patchs that would break gcc compiles, but it wouldst hurt to keep the patchs separate) - - compile a list of packages that will be "black-listed" ones that absolutely do not work with ICC, on the Gentoo-wiki.org I have already started to accumulate a list of these such packages, along with some notes on specific packages that need special circumstances to work (C FLAGS, ETC) - - as shown in the Gentoo-wiki.org that a simple bashrc enables "selective" compiling with icc, this will be hopefully be somehow integrated into portage, in the native python language, but will serve as a basis to begin making the whole of the ICC-compiled system work. ** note that bashrc was contributed by another member not me** I am a student with the summer off so i can spend at least 10 hours a week on Gentoo duties, if not more. I have skill with C/C++ so its possible that i can make patchs, although my skill is extremely limited its a benefit to me I have followed Gentoo for the past 2 years, ditching all windows about 10 months ago, and only using Gentoo. This is a way i hope to contribute back to the Gentoo community. Thanks, Andrew Muraco ([EMAIL PROTECTED]) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkmA+w+RlvG4WXdIRAvK6AJ9nnQAr4/7rU7yfGPgMaUzXRWtItwCghgKV 8PiT16Xtx7hxRsErNslszG0= =Ki21 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] newb question about emerge ...
ian douglas wrote: >I've been using Gentoo since one of the 2003 releases, and never understood this >behavior and was wondering if someone could enlighten me: > >Currently on a 2005.0 install: > ># emerge --sync;emerge -puvN world >( spits out the usual sync output, and ends with this: ) >These are the packages that I would merge, in order: >Calculating world dependencies ...done! >Total size of downloads: 0 kB > >So I think to myself, "Self, there's nothing to update." > >But I saw a security update yesterday for 'gaim' which I *have* installed, so >for kicks, I do the following: > ># emerge -puvN gaim >These are the packages that I would merge, in order: >Calculating dependencies ...done! >... >[ebuild U ] x11-libs/gtk+-2.6.7 [2.6.4-r1] -debug -doc +jpeg -static +tiff >11,174 kB >... >[ebuild U ] net-im/gaim-1.3.1 [1.3.0] -cjk -debug +eds -gnutls -krb4 +nas >+nls +perl -silc +spell* +tcltk 5,725 kB >Total size of downloads: 37,862 kB > >... why wouldn't "emerge -puvN world" pick up on all of these available >upgrades? Well, actually thats not that uncommon. first of all (some people will disagree with me on this) # emerge -avuDN world does a much more through job, because it not only checks the packages you have installed, but all the dependancies to make sure they are up to date.. for example gtk+ is a dependancy of gaim.. so when it checks to see if gaim is uptodate, it would also check gtk+ to see if it is uptodate. Secondly.. # regenworld run that command occassionally as sometimes things that get emerged for whatever reason are not part of the world file AND not a direct dependancy of something and so the emerge -avuDN world would not check -- running this command will check and add these entries to the world file so they will be included with updates. I hope this helps, btw this doesnt belong in -dev, but its not a big deal.. Regards, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] newb question about emerge ...
Chris Gianelloni wrote: >On Wed, 2005-06-15 at 12:34 -0700, ian douglas wrote: > >>I've been using Gentoo since one of the 2003 releases, and never understood this >>behavior and was wondering if someone could enlighten me: >> >>Currently on a 2005.0 install: >> >># emerge --sync;emerge -puvN world > > >Ehh... what does "emerge -N" do? I see no mention of such a thing in >"emerge --help". > >Also, try using --deep (-D) when doing checks against world. > Actually i believe -N is documented, but it might not be clear.. -N is a short option equal to --newuse .. its a good idea to do. Regards, Andrew -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] linux-2.6.12
Linux-2.6.12 is officially out according to kernel.org I have not tried this, I'm waiting on an official announcement on slashdot or some other similar news site with a list of the major changes between 2.6.11 and 2.6.12 -- i heard that it might have reiser4 stock, but i can not confirm that. Just an FYI for you all, and the vanilla-sources maintainers :) post back any links to any articles you see about this release (not -rc) Thanks, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] linux-2.6.12
Mike Frysinger wrote: >On Saturday 18 June 2005 12:22 am, Andrew Muraco wrote: > > >>Linux-2.6.12 is officially out according to kernel.org >>Just an FYI for you all, and the vanilla-sources maintainers :) >> >> > >/me looks around ... nope, this doesnt look like bugs.gentoo.org to me ... >-mike > > Im not expecting it to be added to the tree that quickly it hasnt even been officially announced, i just wanted to get an idea of what it has to offer once the articles start poping up :-P Regards, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] linux-2.6.12
Jason Stubbs wrote: >On Saturday 18 June 2005 13:52, Andrew Muraco wrote: > > >>Mike Frysinger wrote: >> >> >>>On Saturday 18 June 2005 12:22 am, Andrew Muraco wrote: >>> >>> >>>>Linux-2.6.12 is officially out according to kernel.org >>>>Just an FYI for you all, and the vanilla-sources maintainers :) >>>> >>>> >>>/me looks around ... nope, this doesnt look like bugs.gentoo.org to me ... >>>-mike >>> >>> >>Im not expecting it to be added to the tree that quickly it hasnt even >>been officially announced, i just wanted to get an idea of what it has >>to offer once the articles start poping up :-P >> >> > >As far as I know, the only official announcement is the one that goes out on >LKML. kernel.org is then updated some time after that. The ebuild for the >kernel is already in the tree and, according to posts I read on gentoo-user, >was in the tree before kernel.org was updated. > >Regards, >Jason Stubbs > > LKML announcement http://lkml.org/lkml/2005/6/18/2/index.html doesnt seem to be that specific about the major changes that were supposed to happen.. reiser4, pie/ssp hardened, etc oh well, maybe 2.6.13 ... Regards, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] linux-2.6.12
Kumba wrote: > Jason Wever wrote: > >> >> The ChangeLog[1] is your friend. Live it, love it, use it! >> >> [1] - http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.12 > > > Thankfully, I see no mention of reiserfs4 in it. So we may yet be > spared another release before the post-processed organic material > hits the proverbial high-speed turbine. > > Yeah, I'll probably get flamed for this, but I <3 my ext3 :P > > > --Kumba > keep your wity comments to yourself -lol i dont think ext3 is going anywhere for a long time.. reiserfs4 will merely be an option for those of us that like post-proscessed organic material.. Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] linux-2.6.12
Mike Frysinger wrote: >On Saturday 18 June 2005 01:53 am, Andrew Muraco wrote: > > >>reiser4, pie/ssp hardened, etc >> >> > >what would the mainline kernel care about ssp ? >-mike > > actually i dont know if they were talking about ssp/pie but the correct term is SELinux (known to gentooers as hardened) and trusted computing are also things that were reported to be up for mainline kernel http://www.linuxworld.com.au/index.php/id;669959914;fp;16;fpid;0 http://kerneltrap.org/node/3736 -- reiserfs4 article also a few other things are mentioned in article one, but need not mention them here, for they could've very well made it into the kernel (i didnt look too throughly) Regards, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] linux-2.6.12
Mike Frysinger wrote: >On Saturday 18 June 2005 02:21 am, Andrew Muraco wrote: > > >>Mike Frysinger wrote: >> >> >>>On Saturday 18 June 2005 01:53 am, Andrew Muraco wrote: >>> >>> >>>>reiser4, pie/ssp hardened, etc >>>> >>>> >>>what would the mainline kernel care about ssp ? >>>-mike >>> >>> >>actually i dont know if they were talking about ssp/pie but the correct >>term is SELinux >> >> > >ssp/pie is very different from selinux >-mike > > Yea... but either way i dont know if the SELinux stuff ended up in there.. (thats what i meant initally-- i had pie/ssp on the mind for some reason - ignore that..) time for bed for me - i have work tommorrow, but hopefully i will thinking clearer tommorrow. Regards, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] linux-2.6.12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Drake wrote: >Omkhar Arasaratnam wrote: > >>That said, we're not RedHat. We ship as MANY features as we can and let >>the user decide. I agree that it is valuable to get reiser4 testing done >>up front. Eventually - some people will use it. Last I checked "I think >>$FOO is stupid" wasn't a valid closure code in bugzilla ;-) > > >Then you have different views from the kernel project :) > >We and try and make our kernel (gentoo-sources) _more_ stable than the >official Linux releases. We mainly stick to bug fixes decreed worthy by the >upstream developers, etc. We never include patches when we know of problems >that they will introduce. > >Daniel i know this has been said before many many times, but i really can't wait until i can see reiserfs4 in a "stable" kernel (vanilla or gentoo) but i doubt that the gentoo-sources crew is going to budge [whining]please.. USE flag'd reiser4? please pretty please[/whinning] Anyways, I can understand the hesitence for the kernel project to add things that have so many possibilties of problems like reiserfs4.. But for me its stable enough that I've only had to run reiserfsck once, and that was right after i set it up, and i had a powerloss.. i ended up just mkreiser4'ing and starting over because it was before i even unpacked a stage.. Anyways, Sorry that this wasnt in gentoo-user, Regards, Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtIhAphOMdPLugR4RApBEAKDTV1G40VuPiP5OfVdc0YbezIZF8QCgn/sF e9s+42bIyQ0e+J/4UXchN20= =pqyn -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Release files/portage snapshots auxiliary files naming scheme
Henrik Brix Andersen wrote: Hi, Currently the files that accompany our release files (ISO images, stages) are named in the following scheme: *.asc for GPG signatures *.md5 for MD5 sums while the files that accompany our portage snapshots are named: *.gpgsig for GPG signatures *.md5sum for MD5 sums I suggest we unify the naming scheme to the one currently in use by our release files to avoid unnecessary confusion amongst our end-users - unless of course there is a good reason for having different naming schemes for release files and portage snapshots? Sincerely, Brix Don't you think its a bit trival, but on the other hand, yes i agree that unifying them wouldnt be a bad thing, its just a matter of getting it done, and updating the documentation to reflect the changes (minor changes :-P) I say 'Do it.' -------- Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
In response to all replies Thus far, I as a User, I expect that arch works (no matter what) - no arguments there I assume that ~arch will work 95% of the time. I never ever touch anything in p.mask. Now, where do we put packages that could work for most users, but they might not work for the other 49% of users? p.mask seems to prevent that 49% of users from trying it, and reporting those bugs, but on the other hand ~arch means that 49% of users using ~arch will have problem x,y, or z. Now understand, this is the viewpoint of myself, and I have used a full ~arch system for a while, and i didn't ever run into anything more then the occasional package with a new config, or config update that i didnt do properly. (lazy-ness) things to consider 1) would ?arch become the old ~arch, if it was implemented? 2) would people actually try to run a full ?arch system? 3) #2, would it be possible without breakage? I personally like the idea of the UNSTABLE="" because to me, it changes nothing, but allows the AT and PM to communicate, on a per-ebuild basis. (comments welcome) just some thoughts, Andrew -- gentoo-dev@gentoo.org mailing list
