Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Here are my random two cents On 1/5/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2006-01-04 at 19:57 -0800, Greg KH wrote: On Thu, Jan 05, 2006 at 03:58:57AM +, Kurt Lieber wrote: On Tue, Jan 03, 2006 at 01:17:06PM -0500 or thereabouts, Chris Gianelloni wrote: Gentoo is not a distribution of Linux. Gentoo is not anything more than a loosely bound group of developers all doing their own thing in a collaborative and collective manner. You cannot use corporate thinking to manage such a beast. We don't have mission statements. We don't have road maps. We don't have quarterly earnings and market projections. We simply exist. Which is why Gentoo has jumped the shark and is now on a long, slow decline. Ok, then what should Gentoo do to fix this percieved decline? Pander to the enterprise crowd, of course. You know, take away all of the stuff that makes Gentoo what it is and slow down development with more committees, peer review boards, and meetings. We need to all take a step back and make sure that we're all a part of the big picture for Gentoo. You know, subscribe to the group think. Personally, I *love* the fact that the Hardened team has differing goals from Release Engineering. I also don't see how our goals could ever really be guided by a single vision. That doesn't keep us from working together to each accomplish our individual goals. Apparently it does. How many huge threads have you seen lately that accomplished nothing? How many threads have people started with great ideas, only to give up in disgust because people cause a huge fuss about small details, and nothing ever gets accomplished? Quite a few. Do you want to be a part of a project that doesn't allow you to implement some cool new feature because it might make Gentoo slightly harder to use for some people and that's against the mission statement so not allowed? Yes, absolutely. We need a mission statement first :) Our mission: To seek out new life and civilization, and to bring Gentoo to them, by force, if necessary. *grin* -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A New Linux Way
On 1/9/06, Mark Stewart [EMAIL PROTECTED] wrote: Subject line: A New Linux Way Learn to send emails correctly? Text as follows: Hello fellow Linux Users! We here at SaviourLinux.com desire to create a united universal way. Please visit the website for more information, but here is the purpose: Saviour Linux is an easy and universal Linux distribution that pays community programmers. Saviour Linux is not just another distribution. Saviour Linux will be unified and run by the community. We will bring in a new business that gives out completely free software instead of closed source. All of our profit will come from services and it will pay volunteer programmers. Only a little of the profit will go towards overhead. Saviour Linux is Linux united. Every distribution can still be independent, but we wanted to help the community in a new way. Please contact me if you are interested. Please don't spam other distrobutions mailing lists with your trash. Thank you! Sincerely, Mark Stewart SaviourLinux.com Coordinator and Website Maintainer -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Find apps not ported to modular X
On 1/19/06, Donnie Berkholz [EMAIL PROTECTED] wrote: Lares Moreau wrote: Could you post updates once a week(or two), similar to what [EMAIL PROTECTED] does with the aging ebuilds. I don't feel a play-by-play is necessary. I will be posting daily updates until it goes into ~arch, planned for Jan. 25. Would you considder putting these daily updates on your devspace instead of sending a huge email daily? Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: bootstrapping since gcc 3.4 is stable
On 1/25/06, Mikey [EMAIL PROTECTED] wrote: On Wednesday 25 January 2006 19:13, Stephen P. Becker wrote: Ahh, so you were the idiot that ran those tests. Congratulations...you needlessly did a --emptytree world after you had already done --emptrytree system in order to bloat your results. RTFM - http://www.gentoo.org/doc/en/gcc-upgrading.xml SO you uhh.. just proved you have very little idea about gentoo, whats next? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
What eactly is your point? Of course they are. On 1/26/06, Mikey [EMAIL PROTECTED] wrote: On Thursday 26 January 2006 08:06, Chris Gianelloni spammed: On Wed, 2006-01-25 at 20:23 -0600, Mikey wrote: If you actually downloaded a pristine stage1 or a stage3 tarball you might notice that there are, in fact, packages already present in world. Glibc, gettext, nano, gzip, and linux-headers. Not that that matters one iota to this conversation, but you need to get your own facts straight before running around calling people idiots. Damn. I have to bite. All of these are in system, so please, give up until you have a clue what you're talking about. They are also already present in /var/lib/portage/world in the official release stage1/stage3 tarballs. At least for x86. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for Comment
On 2/10/06, Klaus-J. Wolf [EMAIL PROTECTED] wrote: Hi, I am new to this list, but I am not new to Gentoo. Would you please discuss a GLEP draft, which I believe it might improve the usability of Gentoo? Text at: http://www.seismic.de/gentoo/gentoo_mask_proposal.html Seems like a huge amount of work for a little amount of benefit.. There is no need for 10 versions of a package, it only serves to create more maintainence problems. Technical details still missing... Regards k.j. ps. I can also post the text, it just doesn't look very pretty when reformatted... -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On 2/28/06, Renat Lumpau [EMAIL PROTECTED] wrote: On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote: today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org I don't think that's the lesson. It oughtta be: we need a way to figure out which QA issues are important and which are less so. A QA team member's opinion (personal attacks, whatever) should be an important input but not the final say. eh, see, from what I can tell you are just deciding to make it complicated. Do a quick bugzie search for bugs reported in the last week by ciaranm, I don't think he's singling you out. I think he's responding to your stubbornness. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Making the developer community more open
Asking developers to proxy takes almost as much time as it does to ask them to maintain a package by themselves. The developer is directly responsible for anything he commits, so he will have to still test the ebuild, still test any revisions, and still follow the package to make sure there are no problems. The writing the ebuild part of the process is not that much of the commitment, I don't see the point. On 3/22/06, Thomas Cort [EMAIL PROTECTED] wrote: A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. The easiest way to handle contrib as far as that big warning is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to risk it, don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Why would the packages need a big warning/overlay/eclass if they were checked by a developer to make sure they don't do anything malicious, or break QA, or whatever? There are many user contributed ebuilds that have made their way into portage after being reviewed by devs that don't have any such warnings. I don't think creating a contrib overlay as an official part of Gentoo would be a good idea because making it an official Gentoo project conveys a certain level of quality. If the quality is there, then why not add the ebuilds to portage in the first place? If the quality isn't there, then you will have a lot of unhappy users complaining that an official Gentoo overlay broke their system. Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea either IMO because the contributors wouldn't be contributing to Gentoo, and they wouldn't be interacting as much with the Gentoo developer community. Sure they would learn a lot of the skills required to be a Gentoo developer, but they wouldn't be increasing the value of anything in portage (unless they got a proxy to commit some of their work to portage). Also, there are many overlays out there already. Adding another one won't help with making the developer community more open. Additionally, I don't personally know of a lot of people who actually use third party overlays except to get an ebuild for a particular package they want or to beta test ebuilds. -Thomas -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
On 3/23/06, Daniel Goller [EMAIL PROTECTED] wrote: On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: Asking developers to proxy takes almost as much time as it does to ask them to maintain a package by themselves. wrong The developer is directly responsible for anything he commits, so he will have to still test the ebuild, still test any revisions, and still follow the package to make sure there are no problems. The writing the ebuild part of the process is not that much of the commitment, I don't see the point. we are not just talking about new ebuilds/bumps having someone do all the work and having to only verify the end results of the users work is a big help, instead of having to look into the problem, checking if a fix exists elsewhere, or digging through the source yourself, you verify the fix solves the problem and does only that. and everyone wins So it sounds like you are asking them to do everything developers do, why not just make them be developers? On 3/22/06, Thomas Cort [EMAIL PROTECTED] wrote: A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. The easiest way to handle contrib as far as that big warning is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to risk it, don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Why would the packages need a big warning/overlay/eclass if they were checked by a developer to make sure they don't do anything malicious, or break QA, or whatever? There are many user contributed ebuilds that have made their way into portage after being reviewed by devs that don't have any such warnings. I don't think creating a contrib overlay as an official part of Gentoo would be a good idea because making it an official Gentoo project conveys a certain level of quality. If the quality is there, then why not add the ebuilds to portage in the first place? If the quality isn't there, then you will have a lot of unhappy users complaining that an official Gentoo overlay broke their system. Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea either IMO because the contributors wouldn't be contributing to Gentoo, and they wouldn't be interacting as much with the Gentoo developer community. Sure they would learn a lot of the skills required to be a Gentoo developer, but they wouldn't be increasing the value of anything in portage (unless they got a proxy to commit some of their work to portage). Also, there are many overlays out there already. Adding another one won't help with making the developer community more open. Additionally, I don't personally know of a lot of people who actually use third party overlays except to get an ebuild for a particular package they want or to beta test ebuilds. -Thomas -- gentoo-dev@gentoo.org mailing list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEIx8o/aM9DdBw91cRAmVoAKC8JtAm2vvWGBG2YMzpI+EGu8RFJwCeOMll lCv/CsLde+6MbDHgX8EuKhU= =w+ap -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
A secondary package manager is a package manager that instead of directly aiming at replacing portage as primary package manager. What does it do instead? The first restriction is that no packages in the tree must rely on the secondary package manager. While packages may provide a level of support (while being compatible with the primary package manager) this may not result in a significant increase of features. Why can a certain ebuild not DEPEND specifically on a third party package manager? I think you raise some good points in this email, however I think the overall aim is flawed. The package manager should be just as switching as the compiler, the libc, the baselayout, or the kernel. None of these require anywhere near as many hoops to jump through to be supported in gentoo, and they all have their own fixes that need to be made. No changes should be made to the tree which directly impedes the ability of the primary package manager to do its job, but at the same time, no changes should be made which impede other package managers from outperforming the primary package manager. Forcing package managers to stay even with all of portages ideosyncrocies is just holding back new package managers from making progress. On 5/20/06, Paul de Vrieze [EMAIL PROTECTED] wrote: The promissed glep on package manager requirements. Please comment on it. There are some parts that may be controversial (portage has in the past not provided support for reverting to stable either), but please keep the discussion on topic. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net GLEP: 49 Title: Alternative Package Manager requirements Version: $Revision: 2214 $ Last-Modified: $Date: 2006-05-20 14:51:41 +0200 (Sat, 20 May 2006) $ Author: Paul de Vrieze [EMAIL PROTECTED], Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 18-May-2006 Post-History: 19-May-2006 Abstract This GLEP describes four classes of package managers. What the requirements for them are, and what support they can receive. Motivation == To set a standard that package managers that seek gentoo project approval and support should adhere to. Rationale = Currently portage is showing its age. The code of portage does not seem to be salvageable for new versions. There are two known alternative package managers that claim a level of portage compatibility. These alternatives are `paludis`_ and `pkgcore`_. Before these alternatives are developed further, a set of rules should be created to level the playing field and ensuring that decisions can be made clearly. Backwards Compatibility === Not a problem for this GLEP. There is no previous standard as the issue did not exist before. This GLEP is to prevent future compatibility issues. Categories of package managers == We distinguish four categories of package managers. While a package manager can transition from one category to another, it can not be in two categories at the same time. It can be in a state of transition though. *Primary Package Manager* There is one primary package manager. Currently this position is held by portage. The primary package manager is assigned by the council and all packages in the official tree must be installable by a useable version of the primary package manager. *Candidate Primary Package Managers* A candidate Primary Package Manager does aim, or show an aim, at replacing the current primary package manager. At a point where the package manager is deemed stable a decision must be made whether this package manager should become the new primary package manager. At that point the `primary package manager transition phase`_ starts. *Secondary Package Managers* A secondary package manager is a package manager that coexists with the primary package manager, while not aiming to replace it. Package managers that would fall into this category are: - Experimental package managers. Package managers whose purpose it is to try out new features. - Focussed package managers. For example a package manager that allows the use of rpm formatted binary packages would be an example. *Third Party Package Managers* A third party package manager is any package manager that lacks recognition from gentoo as being in any other category. A third party package manager may or may not have a gentoo package, but is not supported beyond that. Package manager requirements As a package manager is in a state of higher support there are higher requirements to it. The purpose of these requirements is to ensure the unity of the distribution and the package tree. For this purpose it is needed that there is only one primary package manager. primary package manager requirements
Re: [gentoo-dev] Project Sunrise -- Proposal
On 6/10/06, Markus Ullmann [EMAIL PROTECTED] wrote: Okay, so after figuring out open problems (thanks to kloeri and various other people for help here), we now have a resolution that should satisfy all involved parties here. This should adress dostrow's demands as well. 1) m-w / m-n requirement Only ebuilds that are reported to bugzie (valid bug#) and set to maintainer-wanted are allowed here as well as maintainer-needed ones. maintainer-needed are only allowed if they're removed from the tree and moved over to sunrise (and thus end up as maintainer-wanted again). 2) Not one large tree but subdirs, one per herd to help herds better keeping track of which parts are alive in the overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be a netmon/ dir with net-analyzer/specialapp below it. If its unofficially part of a herd, then isn't it no longer a m-w/m-n ebuild? 3) a yes from herds required, keeping a timeout to avoid bugspam after a comment has been placed on a maintainer-wanted bug in bugzie, there's a grace time of two weeks for herds to either leave a comment on whether they're fine with take over or not. When this time is over and it is assigned to maintainer-wanted, then and only then it is implied as an OK to keep it also in the sunrise project. 4) work needed by herds - take a look at the homepage of the new program - take a look at the ebuild If you're at least partly happy with the new app, drop a note on the bug or just ping sunrise that you're ok with it. Then sunrise takes it over and improves the ebuild together with the contributor so that it reaches a level where it could theoretically be committed to the tree. Herds are more than welcome to help here if they feel like it but basic checks whether the app should ever be on gentoo will be sufficient. 5) commit access to the overlay We implement two levels of commit rights: 1. As there are people out there who just want to maintain one app for start, the ebuild should reach a level that project devs are fine with it, then the user is given permission to commit on that single app. An automated check makes sure that he doesn't commit anywhere else. If violations arise, the access is revoked immediately. 2. People who contribute good ebuilds over a certain period of time are allowed upon decision by project devs to actively help maintaining the project. They'll be given commit rights for the project then. Same frome above applies here: If we notice any abuse, we revoke access immediately. 6) QA assurance Of course there are minor issues with the ebuilds, otherwise they could be committed straight forward. Important thing is that it only finds the way into overlaye if the trusted committers (project devs and users who are given permission explicitely, see above) are fine with it. Additional note on arch issues: initially, just ~x86 and ~amd64 may be set. The rest would need successful test reports for other ~arch keywords. Stable keywording isn't permitted at all, there will be some automated check to make sure no one does it (by accident) here. Additional note: we won't start adding this to layman and making it available easier until the QA checks have been implemented. 7) tag on bugs All ebuilds that are made available on sunrise get an InOverlay KEYWORDS entry on bugs.g.o so that everyone, who looks at the bug, knows about it. 8) Grace time also given from the go point on. When we see that this gets a bit fine-tuning / acceptance among devs, we will explicitely call out a two weeks notice for ebuilds currently assigned to maintainer-wanted so that herds can keep an eye on them and either comment as given, reject take over permission completely, close as WONTFIX in case they're against the app for the tree in futures or just drop a note that they're fine with the take over and the development can be started on the ebuild. Remember the way they need to be reviewed as said in 4). The ebuild is subject to development, the sunrise devs do help with it in case your herd lacks time to completely take care of it. 9) Security In this early stage we have no security liaison on board yet. If one is willing to help out here, we'd be more than glad on welcoming him :) Greetz, Jokey I think this is a much improved//thought out version of the proposal. From the looks of things sunrise should never make it to layman however, because as we all know, anything that makes things more easily accessible to users is going to be (mis)used by more of them. From what I understand, you see Sunrise as an overlay for users to improve their ebuilds because they are insufficient quality to be in the main tree. If they are of this poor quality, they should be no where near users hands, this doesn't make sense. If on the other hand you saw sunrise as a way for more packages to be available to users due to there being a lack of maintainers, asking herds to check out ebuilds as part of the proposal seems
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On 6/14/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2006-06-14 at 22:34 +0200, Jakub Moc wrote: It's not irrelevant; you're just not reading it properly. You might notice that metadata.xml contains tags other than herd, like, say, maintainer. In the example that sparked this, herd is games and maintainer the individual dev who maintains it. Simple enough, no? Please, go through the tree and see at least so many metadata.xml files as I have seen, before claiming something that simply doesn't reflect current practice. There are many ebuilds with no maintainer tag and herd only. Are you claiming that they are unmaintained? Well, that Nobody said that they were unmaintained. Again, why do people *insist* on trying bullshit arguments like this? Are you claiming.. No, he's not claiming that, or he would have *said* that. obviously doesn't match the reality. So, if they actually _are_ maintained by the relevant herd, then you shouldn't dump stuff on that herd without discussing it w/ them first. I'm pretty sure mcummings will gladly explain to you what will happen if you do, as well as a bunch of other devs... :P A herd is a group of packages, not a listing of people. When you get information from the herds.xml, you are getting the listing of the people that *maintain* that herd. You are not getting a listing of the people *in* the herd. According to the devmanual [1] A herd is a collection of developers who maintain a collection of related packages are you sure you are using the correct term? [1] http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html Please go back and read the herds project page[1] and try to understand this. It really is printed quite simply. To make it pretty clear and explicit - bugs gets assigned to maintainer (if there's any in metadata.xml), and get CCed to herd (if there's any in metadata.xml). If there's no maintainer, whoever is in herd will get that bug assigned and can happily smack you butt once they've find out you've dumped the package on them without their knowledge... That's how the large part of current ~600 dev-perl/* ebuilds has made it into the tree and that mistake doesn't need to be repeated. You are correct. This is *exactly* how it works. Also, you'll notice that nothing either I or Stephen has said contradicts this, if you actually went back and contemplated what we both said. [1] http://www.gentoo.org/proj/en/metastructure/herds/ -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkIGskT4lNIS36YERAlg2AKCmitk2Pwd7XSP+ysarJDc1imbnUgCgt2wv OYJuhhIg+vG5wom7DRcwHEg= =Tprl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On 6/20/06, Donnie Berkholz [EMAIL PROTECTED] wrote: Diego 'Flameeyes' Pettenò wrote: [snip] I don't see how any other suggestion is simpler than mine for developers or users. Maybe I missed something in skimming the discussion. To summarize: - USE=qt enables support for the most current qt. - USE=qt3 enables qt3 if there is also qt4 interface. This will be an easy switch now, because very few packages have a qt4 flag, and it will get progressively harder. - Add qt3 to make.defaults to avoid breaking things like KDE. I suppose it will also need some clause for the mutually exclusive cases: USE=qt -qt3 enables most recent any USE combination containing qt3 forces back to qt3 One problem I see with this is users that currently have -qt are going to be confused when it no longer does what they expect Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?
On 6/21/06, Duncan [EMAIL PROTECTED] wrote: Caleb Tennis [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 21 Jun 2006 10:03:21 -0400: [Stefan Schweizer wrote...] qt3 - enable optional qt3 support qt4 - enable optional qt4 support Maybe I just need a little time to warm up to this. :) [snip] This should be the clearest from a user perspective, and should require the minimal amount of package.use magic, yet it remains an option where a user finds it necessary. There will be a bit of disruption when KDE4 ultimately stabilizes, but handled correctly, it shouldn't be any more of a problem than any major version upgrade on a major desktop environment would be -- that is, while some problems should be expected (and well published in GWN and the like before stabilization), they should be resolvable, and temporary. When do you propose qt4 hits make.defaults? When kde4 hits p.mask, when it hits ~arch, or when it hits arch? I think mr_bones__ idea was the most appropriate thus far. -- 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@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: unicode and userlocales useflag
On 6/22/06, Graham Murray [EMAIL PROTECTED] wrote: Duncan [EMAIL PROTECTED] writes: There's a newer way to control the same thing that userlocales controlled, but I didn't understand it when it was posted here. Though, AFAIK, there is no way of retaining the old behaviour, of building all locales, when the local userlocales flag was not set. keep /etc/locale.gen empty -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
On 7/30/06, Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 30 July 2006 18:07, Ciaran McCreesh wrote: Personally I'd expect the council to block the thing permanently. hard to address any sort of concerns here, so i guess i'll just regurgitate the council log to you it's hard for users to get involved in our development process ... i imagine some consider that a feature, but it leaves a large portion of our community out in the cold I do not see why it is considdered hard for users to get involved. Users have at least two choices that I can think of right now, and probably a number that I cannot think of. 1) Users can submit patches/ideas to bugs.g.o at whatever frequency they desire, contributing to gentoo casually. 2) Users can take the quizzes and become a developer, I do not see why two quizzes is considdered an insurmountable task, the quizzes are specifically designed to ensure that people writing ebuilds understand what ebuilds can contain and what they cannot, I could not imagine a user wanting to install a package from an ebuild written by someone that does not know this. sunrise is attempting to fill that gap via some controversial methods ... in review, we deemed that the many concerns raised were pretty much addressed and any more requests for criticism and useful critiques either went unanswered or people piped up saying that they were happy with the latest state i (nor anyone else) cannot say whether this venture will succeed, only time will prove out the project ... sitting around and clamoring for more openness while killing every attempt at it gets us nowhere we take a risk with this project (like every single other project) ... if sunrise turns out to suck and cause problems, then we kill it, no big deal -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The gnome king is dead, long live the gnome king
On 7/31/06, foser [EMAIL PROTECTED] wrote: Hello dear followers, tonight after a some deliberation I have decided to step down as gnome lead in favor of AllanonJL. As far as I am concerned AllanonJL has been the acting lead for quite a while now, while I was too busy to devote much time to Gentoo and as such it was the only logical next step. This doesn't mean I will leave Gentoo, it just means I'm going to get myself out of a few herds and positions I don't belong in anymore. Trying to focus on the things I can still do to keep Gentoo the one distro I love to use. I'd like to say thanks to Spider, Obz, Leonardop, Dang, Compnerd, AllanonJL, Zaheer and all the other contributors over time on bugzilla and IRC for bringing gnome on Gentoo where it currently is. Also I'd like to invite everyone interested in helping gnome on Gentoo to join #gentoo-desktop on freenode IRC, mail us directly or triage bugs on bugzilla. We can certainly use more help on pretty much any level, from user-testing to full blown fresh developers getting their hands dirty. thanks for your time, Marinus -- s/gnome king/gnome/ My troll bait for the year! gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo 2006.1
On 9/2/06, Stuart Herbert [EMAIL PROTECTED] wrote: On 9/2/06, Alec Warner [EMAIL PROTECTED] wrote: Give us about 3000 more developers, and sure* ;) I don't think that that's good thing to be saying to our users. Is it a bad thing to be saying to your developers? We didn't need 3000 more developers ... we just needed to give the developers we have more reasonable notice. This is the second time in recent weeks that we've acted like this, by stabilising a major package with little or no notice. It's the same group of folks involved both times. The gcc-4.1 stabilization bug has been open for a month and a half. Thats fairly good notice... Warnings have also appeared on planet.gentoo.org, and in the GWN. Best regards, Stu -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo 2006.1
On 9/2/06, Stuart Herbert [EMAIL PROTECTED] wrote: On 9/2/06, Dan Meltzer [EMAIL PROTECTED] wrote: On 9/2/06, Stuart Herbert [EMAIL PROTECTED] wrote: On 9/2/06, Alec Warner [EMAIL PROTECTED] wrote: Give us about 3000 more developers, and sure* ;) I don't think that that's good thing to be saying to our users. Is it a bad thing to be saying to your developers? It wasn't said to developers, it was said to a user. It was in response to gimli, who unless he stole his @g.o address is a developer. The gcc-4.1 stabilization bug has been open for a month and a half. That's great, but that's not an announcement. Folks aren't going to go digging through bugs to find stuff like this. Thats fairly good notice... Only to the folks who knew about that bug. For the wider community ... it's not notice. The wider community will not be effected until they manually make the switch to 4.1, just like any other gcc upgrade. Before doing this one would assume they would do a little research. Warnings have also appeared on planet.gentoo.org, and in the GWN. Tsunam posted that there was a push on to get gcc-4.1 stable, but there was no target date, and no firm statement that said it would definitely be happening. He posted this on July 19th. Was there another warning, with dates and stuff? The GWN warning was last week. My apologies if there was an earlier one that I missed. My apologies, but I've been unable to find an announcement on -dev. I do not know if there was on on -dev, I remember hearing for a little while now that 2006.1 was going to be gcc-4.1.1, but I don't remember if I read that or heard it in the -x86 irc channel, it may have been there which doesn't really count :) Beyond the stabilization warnings however, I would think that gcc-4.1.1 entering unstable (which had a number of announcements IIRC) should be warning to all users that it was now on track to be stable, and to be prepared. I really do not see what kind of further warning was necessary or even possible... maybe I'm missing something. (Other than the yet-to-be-implemented GLEP42 of course) Dan, Best regards, Stu -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gcc-3.3.5.20050110-r1 for stable
One thing... Maybe its just me... or maybe they are in no way related, but I seem to have heard of a lot more 'libtool' problems when using a snapshot version instead of a regularly numbered version, is there a reason? On Apr 7, 2005 11:46 PM, Mike Frysinger [EMAIL PROTECTED] wrote: can stable uses of gcc-3.3.5-r1 upgrade to gcc-3.3.5.20050110-r1 and see if they hit any fun and exciting bugs ? if not i'd like to move this to stable this weekend -mike -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion: alternative compatible utilities
Well it would be nice to have it all abstracted, wouldn't stablizing a package get exponetially harder? Not only would each arch need to be tested, each combination of packages on each arch would need to be tested, if FEX openpam became usable on linux instead of just linuxpam, each arch that stableized would now need to say works for this arch for linuxpam, and works for this arch for openpam, which would cause lots and lots of keywords mess. Or am I misunderstanding your post? On 6/16/05, Luca Barbato [EMAIL PROTECTED] wrote: Diego 'Flameeyes' Petten wrote: Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar, sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin I don't really know :P This limits a bit the user because to use other kind of utilities it must use aliases and he can't change, for example, the tar used by portage or by other scripts. Surely it would be interesting for developer that want to make sure their code will build in other userspaces w/out switching os, and if that won't be so painful, would worth testing it. Obviously having it now isn't really needed. Thinking about that when committing/updating ebuild would be good. ( still I do hate bsd core utils implementations but that is just my opinion =) ) lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Bugzilla handling for maintainer-wanted things
This time I'll say something useful :) Nathan, you seem to be misunderstanding open source. You get the I can ask for features or suggest things part, but not that I can add features or do things part. No one is stopping you, or me, or an average joe, or George W. Bush, from peer reviewing. You can see the basic things that are commonly wrong by looking at a few resolvedwontfix bugs with ciaranm as the commenter. Most make the same mistakes. After seeing this, what is to stop you from either manually looking through the tree, or writing a script to check for you, and fixing some of the problems, submitting them as bugs when they are fixed. I cannot imagine any developer would say no to a well written ebuild, they may wait for a version bump to switch to it, but they most likely would not ignore it all together. Hell, maybe if you do a good enough job, and show enough devotion, the gentoo guru's will even think about making you a developer in charge of fixing those things. who knows? On 8/21/05, Duncan [EMAIL PROTECTED] wrote: Donnie Berkholz posted [EMAIL PROTECTED], excerpted below, on Sun, 21 Aug 2005 03:02:36 -0700: Nathan L. Adams wrote: | What I see with Gentoo is this 'cathedral' being built where only those | folks who have been 'approved' or 'blessed' as being l33t enough are | allowed to review the code and actually cause a positive change when | some bug is found. If you believe Chris Gianelloni's argument, then only | those blessed developers who are also blessed by a particular group | within Gentoo are allowed. Eventually the meritocracy degrades into a | popularity contest. Our code is all available in the portage tree or ViewCVS, and so are all the ebuild bugs in Bugzilla. Nobody's stopping anybody else from reviewing any submissions or filing new bugs. It's just a question of who makes (and therefore approves of) the actual commit. I don't see where your cathedral is coming from. I'm with Donnie on this. Gentoo's quite the bazaar, IMO. When I read that cathedral thing, my reaction (strong enough to cause a verbal outburst as I read your post), was Oh, brother! You don't have any idea! That as I was physically shaking my head. I don't know where you got the idea that Gentoo's a cathedral at all, as it sure looks to be a bazaar from this viewpoint. You /totally/ lost me with that one. I couldn't disagree more! -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Fixing the TERM mess
putty pretends to be an xterm and dies at xtermcontrol --get-bg... I can test other things if you need.. just give me some idea :) On 8/21/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 22 Aug 2005 00:00:26 +0200 Henrik Brix Andersen [EMAIL PROTECTED] wrote: | * Install, either with the terminal (as is done by rxvt-unicode |currently), or as part of ncurses, proper terminfo definitions for |these terminals. | | One could argue for both solutions here: it would make sense to | install it along with the offending terminal, since this is where we | change the value of the $TERM variable. The problem with this is that non-X boxes will be missing the terminfo descriptions. | Perhaps we should just once-and-for-all submit a patch to ncurses | which includes these new terminfo definitions? We will then patch our | foo-terminal ebuilds to set a proper value of $TERM. Then when | upstream (hopefully) decides to change their $TERM value to something | sane, ncurses will already have the support, and we can remove the | local patch along with the version bump of foo-terminal. The problem with this is that some terminals gain new capabilities fairly regularly. One example is rxvt-unicode, which is still putting out regular releases. A third possibility is to split out the terminfo db from ncurses. This will let us do frequent updates if necessary. It may also help the embedded people -- we could add a USE=minimal which only installs 'common' definitions and leaves out support for obscure 1950s line printers. There may be a gaping hole in this idea. I haven't thought it through much... | * Include TERM stuff in policy so that the problem doesn't crop up | again a few months later. | | I'm not sure what you mean by policy? That thing we don't have yet. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Fixing the TERM mess
mine ended up spitting out large amounts of gibberish and ruining the readability of the terminal... why would it be so different? On 8/22/05, Tavis Ormandy [EMAIL PROTECTED] wrote: --On Monday, August 22, 2005 08:18:42 +0100 Tavis Ormandy [EMAIL PROTECTED] wrote: --On Monday, August 22, 2005 00:21:16 + Renat Lumpau [EMAIL PROTECTED] wrote: On Mon, Aug 22, 2005 at 12:08:00AM +0100, Ciaran McCreesh wrote: Thanks. The other useful one is to see whether it does 256 colours properly like real xterm does. The following bash script, when run with '256' as its argument, should look the same as it does when run under a real xterm. Not even close here. Your script produces 256 different colours here, the shades dont match xterm's exactly, but there are definitely 256 distinct colours. http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/256-colours-match-xterm.html Ahh, apparently it matches an old version, but they plan to update it. Tavis. -- - [EMAIL PROTECTED] | finger me for my gpg key. --- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] EAPI
Maybe I'm incorrect, but I believe Kristian was not saying use XML, but using xml as a comparasison (I know there is a better word.. but its escaping me... that comparassion thing on the SAT's). He's not saying to use xml, but in order to extend portage, extend it much like xml extends html, with a pluggable script referenced as the dtd equivvelent. On 8/26/05, Kristian Benoit [EMAIL PROTECTED] wrote: On the EAPI subject Brian just brought back, I had this idea that we could use the same approch XML took with HTML. The ebuild could define which EAPI to use, but instead beiing a version, the EAPI would be an ebuild API definition. The equivalent to the XML's dtd. The ebuild could point to a directory named $PORTDIR/eapi/eapi-name/ which would contain a python script named eapi-name.py. If not already loaded, that plugable eapi would be loaded before processing the ebuild. That way, there is no outdated ebuild format. There is just a default format which is the actual format. It could also be an XML defining the ebuild's build sequence and other particularities a group of ebuild could have. Kristian -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
If it was an extra ebuild, the profiles directory would need to exist outside of /usr/portage, would it not? This to prevent it from being blown up at next sync. On 8/29/05, Patrick Lauer [EMAIL PROTECTED] wrote: On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. Just a crazy idea - why not create a package containing some profiles? You can use the default profile, and if you want a different profile, emerge portage-profiles or whatever it is called and use that. I guess I've missed something obvious here? I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. which are not much work if kde = desktop -gtk -gnome +kde As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. Or provide them in an extra ebuild that throws lots of warnings so that any users that don't read the warnings can be RESOLVED WONTFIXed? -- Stand still, and let the rest of the universe move -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDE0+EqER3hOUoZM4RAoExAJ9vJH9lSOug5o8gVYljtNewLucYnwCcCgL5 uBwy5L+fKeOF2nw/YzyfjSM= =WwNl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Player, Stage, Gazebo eBuilds
bugs.gentoo.org On 8/31/05, Forrest Voight [EMAIL PROTECTED] wrote: Hello, I made ebuilds for the player, stage and gazebo projects. (playerstage.sf.net) How can I commit them to the ebuild tree? Thank You, Forrest -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: ROX: maintainer-wanted and apps out of date
The problem is, trying to fix ebuilds in tree is a lot more complicated.. You have to fight with multiple herds, and multiple developers, and explain to them why it should occur, in order to get anything to happen.. In addition, even a global gigantic one liner to add quotes to $D and $S would cause huge rsync loads... which makes the mirror admins hate you... Combine this with the first issue, and just improving the incoming ebuilds and hoping that the devs watching this list pay attention, and make some of these changes in newly added ebuilds, will improve the quality of the tree slowly. If a user submits an ebuild, they should be prepared to make fixes to bring it up to a standard. Many of the ebuilds do not even follow ebuild-submit.xml, and the maintainer fixing them only causes more problems for other maintainers further down, assuming the user submits multiple ebuilds. Once they learn the rules, later ebuilds will hopefully be up to the same standards. On 9/12/05, Carsten Lohrke [EMAIL PROTECTED] wrote: On Monday 12 September 2005 19:56, Jakub Moc wrote: Since you said above, that you really don't care if those user-submitted ebuilds will ever get into portage or will stay in maintainer-wanted queue forever and that's the stuff in portage that actually matters QA-wise, I'm missing why are you worried about people not submitting their ebuilds any more. Two points: 1. The biggest share of maintenance isn't getting an ebuild right, but the ongoing effort keeping it up to date, applying patches, interact with upstream developers, test, stabilize,... To me it absolutely doesn't matter, if an ebuild is broken or not before taking into account to maintain it. 2. People are interested in applications, but may not have the skills or interest to get an ebuild 100% perfect. WONTFIX will look like PISSOFF for them. I think we just look a bit petty-minded. At the very least, reviewing user-submitted ebuilds and marking things WONTFIX/CANTFIX/REVIEWED makes it possible to filter out the outdated and dead-upstream crap, as well as things about which those people who filed the bugs don't care any more. And, if someone picks those ebuilds up and decides to maintain them, he can focus more on testing the actual app then fixing a broken ebuild (or even committing a broken ebuild into the tree). As I said: Ebuilds in Portage should be reviewed before you think about those in bugzilla. Carsten -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: The tree is now utf-8 clean
Assuming, as I do... that ~arch is utf-8 clean, it must not be that wierd a character, and therefore, probably acceptable for sed also. On 9/17/05, Fernando J. Pereda [EMAIL PROTECTED] wrote: On Sat, Sep 17, 2005 at 02:42:09AM +0100, Ciaran McCreesh wrote: | Something strange I noticed... Some people are using funny quotes and | non breaking spaces in ebuilds. Some people are using weird characters | as substitution delimiters for sed. Don't! It will break on many | systems. I'm going to go and purge all of those, UTF-8 or not, whenever | my brain recovers. I hope ~ is not considered a weird character... if it is, tell me and I'll fix all my ebuilds. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: grub reiser4
On 10/2/05, Chris Bainbridge [EMAIL PROTECTED] wrote: On 02/10/05, Alec Warner [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: On 02/10/05, R Hill [EMAIL PROTECTED] wrote: I still think it's retarded to have a reiser 4 boot partition, but whatever stirs your pot. ;P It makes sense if you're actually using reiser4 for everything else. Why bloat your kernel with an extra FS just for /boot? In addition, why bloat your fs by having a journaled filesystem for essentially static files? Because most people want a tried and true fs on /boot, because if that tanks your system doesn't boot. I'm not trying to bash reiser here, I still use ext2 on /boot even if xfs is my main fs of choice for this reason. Being able to boot a kernel isn't much use without a root fs. If I can't boot, I have a livecd sitting on my desk. I guess if I had a ramdisk on /boot with a shell and some recovery tools then I might care, but I don't. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Interactive emerge
Hi, I would just like some clarification if at all possible.
Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran
into some interactivity. I was under the impression that emerge was
supposed to be completely autonomous, and any user interaction should
take place in ebuild ... config.
Apparantly one of us is {in,}correct, but I cannot find any
documentation although I'm fairly sure I have read it..
Opinions?
Dan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Interactive emerge
This is what I have found thanks to research of friendly people! http://article.gmane.org/gmane.linux.gentoo.devel/29810 (pkg_config only interactive) and, somewhere in dev manual it does say test can be interactive also.. not sure about that though On 10/2/05, Fernando J. Pereda [EMAIL PROTECTED] wrote: On Sun, Oct 02, 2005 at 06:41:47PM +0100, Ciaran McCreesh wrote: | On Sun, 2 Oct 2005 13:21:58 -0400 Dan Meltzer | [EMAIL PROTECTED] wrote: | | Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran | | into some interactivity. I was under the impression that emerge was | | supposed to be completely autonomous, and any user interaction should | | take place in ebuild ... config. | | emerge is non-interactive. Also when FEATURES=test ? In such case the mod_php and php packages are broken. They ask you to save, reject or send the result of the tests if I'm not mistaken Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo Classes, a possible new method of spreading information
Hello, I am a frequenter of #gentoo-*, as many of you know :) Tonight, hanging out in #gentoo, I observed a huge amount of incorrect information once again.. tonight about profiles, cascading and all that jazz, which to be honest is fairly undocumented. I decided to give a miniclass on how it worked. ferringb and antarus sat in, and it was just an off the cuff information/QA session. Okay, so that worked, but then I got to thinking, why not do these fairly regularly? I do not profess to know enough to hold them about a large amount of topics, but I think this could surely supplant the current documentation process. Here is basic rundown and example. Developer A decides to speak about a specific aspect of portage, the discussion is announced on lists and in gwn a week or so in advance. The discussion could take place in a channel such as #gentoo-class, and logged. The developer would cover it as he saw fit, and then have a Q/A period after. The entire class is logged, and added to the website on a publically accessible page. If the docs team thinks its a useful subject, they could translate into a more formal page, and use the logs for reference, if not, it would still be availible information to anyone wishing to read it. My thoughts are this would be best suited to Gentoo-specific things, portage, gentoo's infrastructure, baselayout, anything else ideosynconatic (sp?). But, I suppose it could be on anything if the developer so wished. Ideas? thoughts? comments? Lets hear em :) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Tomcat 5.5 in portage
Most likely because no one has added it, why do you ask? On 10/12/05, Norguhtar [EMAIL PROTECTED] wrote: RUMI Szabolcs wrote: Hello! Tomcat 5.5 is out since a year now and still didn't make it into portage. It doesn't even depend on JDK 1.5.0 in a sense that there is a compat tarball which makes it work with JDK 1.4 so why isn't there a tomcat-5.5 ebuild in portage? Is there some reason for this? Interesting question :). I'm search ebuild for tomcat 5.5 in bugs.gentoo.org. It exist and last actvity dated at 2/005-08-06. I'm added resin ebuild (for version 3.0.14) at //2005-08-25. But this still in bugs.gentoo.org. Java related projects slowly added and modifed :) / -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On 10/20/05, Mike Frysinger [EMAIL PROTECTED] wrote: On Thursday 20 October 2005 10:34 pm, Spider (D.m.D. Lj.) wrote: On Thu, 2005-10-20 at 22:26 -0400, Mike Frysinger wrote: On Thursday 20 October 2005 10:19 pm, Dave Nebinger wrote: i still dont see how this addresses the nocxx / USE=-* noFOO is used because FOO is on by default, and noFOO turns it off. AutoUSE is the same way, package bar is included in the buildplan and to have sane defaults, certain flags are turned on. that was a great explanation however irrelevant it may have been i guess we will have to make 'nocxx' a special case as we strip all other 'no*' USE flags from portage Sorry, guys, but isn't that what -FOO is supposed to be for? If we already have support for -FOO, why then do we need a noFOO also? Or is there some distinction I'm missing here? you're missing the fact that if we change 'nocxx' to 'cxx' then everyone who uses '-*' in their USE flags will emerge their gcc without C++ support Really, Don't refuse an idea because this. Having IUSE=cxx USE=-* and getting -cxx is expected behaviour. i never said i was against the idea of getting rid of no* flags in fact, i said we should change all flags *except* nocxx -mike Why single out this one? ones system will not break irreperbly without a cxx compiler, it'll just cause a another recompile to get it to work after breakage if the person is using -* (which has already been said to be hackish and ill-advised, so doom on them! -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
s/where headstarted by a blog post by Stuart/where headstarted by bug 11359/ To jump right in :) On 10/31/05, Chris White [EMAIL PROTECTED] wrote: Attached in plain text form is glep 42 for the discussed thread. It's rather long, but I hope it details any sort of questions that may be brought up. Chris White -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Bah, replied to fast. Other points of note... 1) Why post to forums.g.o if its on www, why would one check forums instead of www. 2) Theoretically it could be crossposted to the forums, probably simplest to do as a direct mysql insert, which'd be messy. 3) --news, my point of reamage. This is what bug 11359 was all about, I'm not quite sure why the wheel has been brought up for reinvention, this is most likely going to be a large change, and it seems that, instead of bugging portage developers to add more stuff to 2.0 series, which is basically relegated to bugfixes, we should just let them hack away at savior, which will have this support integrated (hell, it has it already). Having a temporary hack is pointless IMNSHO. In addition, seems like this could simply be something like glsa-check, call it news-update why don't we, which simply reads from the RSS feed (oh wow, i'm a genius!). Make this part of system, convince the baselayout guys (this is a lot easier even) to make emerge an alias that calls $(news-update) after emerge, and whaddya know, we have liftoff! On 10/31/05, Dan Meltzer [EMAIL PROTECTED] wrote: s/where headstarted by a blog post by Stuart/where headstarted by bug 11359/ To jump right in :) On 10/31/05, Chris White [EMAIL PROTECTED] wrote: Attached in plain text form is glep 42 for the discussed thread. It's rather long, but I hope it details any sort of questions that may be brought up. Chris White -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP ??: Critical News Reporting
That works, I suppose my point was, if you are going to be adminning from a box with a webbrowser anyways, why not just use that aforementioned webbrowser to check www.g.o? what is the benefit of news/ over that? On 10/31/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 31 Oct 2005 21:08:19 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | WRT links in file updates, this seems completely backwards. If a user | was admining over ssh, it would be far easier for them to load www.g.o | in their browser vs. copying link from terminal to their browser, but | for that matter, why is ssh relevent wrt links in files, but not when | we are talking about it being lightweight? If a user is not expected | to have a browser to recieve the news, how can they be expected to | have one to view doc's about it. The user isn't expected to have a browser on the system on which the news item is being displayed. For example, I have a router box which does not have lynx or X or anything like that which would still be generating news item hits -- expecting me to install a browser on that system to read HTML or XML content is unreasonable. However, admin work on the router is done over ssh, and it's trivial to copy and paste a link from the output of some command on a remote box into a firefox window on my desktop. Perhaps I should add a note that news items should not simply be of a see this link form, and that any links which are used should only be for reference, not the primary source... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP ??: Critical News Reporting
Two things. One, if users run --sync in a cronjob, which many do, this preemptive goes out the window. Two, an alternative to that, if we are all recoding portage anyways :) Have portage place a special note next to any items with relevent news when -a or -p is passed, and then, emerge --news cat/package could show relvent stuff, or --news to see it all. On 11/1/05, Georgi Georgiev [EMAIL PROTECTED] wrote: maillog: 01/11/2005-11:45:08(+0100): Jakub Moc types 1.11.2005, 11:00:22, Thierry Carrez wrote: Aren't those messages displayed after the damage is done ? Typical use : - emerge --sync run as a daily cron job - emerge -a mysql - great, a new version is there. Typing Yes - system gets borken - emerge spits out message saying 14 files need updating and there is 1 unread news item I'm probably missing something here. Please elaborate on how this GLEP meets the Preemptive design goal... I'm probably missing something obvious here, because I can't see why *existing* emerge --changelog code cannot be recycled for this feature to display upgrade messages when running emerge -uDav world... That reminds me of the idea to stick tags in the ChangeLog: http://groups.google.com/group/linux.gentoo.dev/msg/8f2dc84619be5c5b?fwc=1 But still, I'm guessing the idea of --news is to tell people that they need to do something A.S.A.P. This means as soon as the news are obtained, and the users are nagged about the news on *every invocation of emerge*, similar to the /etc messages, and not only when they decide to install some package, which is when --changelog kicks in. And then, I am not sure why glsa-check cannot do the same job... -- () Georgi Georgiev () Computers are unreliable, but humans are () ()[EMAIL PROTECTED]() even more unreliable. Any system which () () http://www.gg3.net/ () depends on human reliability is() () --- () unreliable. -- Gilb() -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
erm, and how exactly do you propose that the user who doesn't-read-the-site-because-it-has-no-useful-information-currently will learn about errata.g.o? On 11/3/05, Nathan L. Adams [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: Not necessarily the website imo, some central store where it's pushed out to all of the locations though (which I suspect you're getting at). I forgot to clarify one point. I'm saying that http://errata.g.o/ should be the *official* source where users go to find the info, not neccessarity the place where the raw data is stored and pushed to other places (although it certainly could be). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarzS2QTTR4CNEQARAlB7AJsHfqCVL160KApWZU7iuqNtCb9SWwCcCtRR D2e1H1U208kQQNzLDo9CpGk= =kiyo -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
For simple translations? No. For translations that span the same bredth (old version checking is probably going to be fairly needed if we used xml as a main version, and all other pretifying stuff is necessary. On 11/4/05, Jan Kundrát [EMAIL PROTECTED] wrote: On Friday 04 of November 2005 19:39 Ciaran McCreesh wrote: On Fri, 04 Nov 2005 15:26:28 +0100 Xavier Neys [EMAIL PROTECTED] wrote: | Oh? Our GuideXML to HTML conversion is thousands of lines of code... | | Plain wrong, but you have always made it clear that you are not only | biased against XML for anything, but also very much XML challenged. Run a wc -l on guide.xsl sometime. Either wc is lying or that alone is thousands of lines of code. Run a `less` or `gvim` or anything which actually displays the contents of the file. Are you sure that checking for obsoleted translations, highlighting top-page links and other stuff is really required for simple transformations? WKR, -jkt -- cd /local/pub more beer /dev/mouth -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
``Content-Type:`` Must be ``text/plain``. Mandatory. Why have this header at all then? ``Posted:`` Date of posting, in ``dd-mmm-`` format (e.g. 14-Aug-2001). UTC time in ``hh-mm-ss +`` format may also be included. This field is mandatory. How will prescendse be handled if two have the same date, and one has a time and the other doesn't? On 11/4/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: Attached is a substantially reworked draft. I've restructured the whole thing, fleshed it out in places, clarified some parts and incorporated the useful stuff from previous discussions. Note: this is now GLEP 42 as allocated by Grant. AFAIK ChrisWhite's GLEP of the same number never made it to official status. Feedback from people who have something useful to say would be very much welcomed, assuming of course that they've read the GLEP. If you're going to rant on about XML or anything that assumes we have a static release Debian-style against which we somehow make 'corrections', you'll be ignored unless you come up with a very good justification based upon requirements and implementation rather than hand waving and incoherent rants. If you don't like it, you're welcome to write a competing GLEP. To give those who like arguing endlessly something else to go on about, the eselect news module is now upgraded to the 'suggested' tool for displaying news items. Look! I'm sneakily and evilly pushing a sekrit agenda here! Also, I murdered three puppies last night. Grant, please commit this to CVS. I'm too scared of docutils to do it myself. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Becoming Mirror
this can be found in the docs at http://www.gentoo.org/doc/ On 11/5/05, Armindo Silva [EMAIL PROTECTED] wrote: Hi! I am member of LUG, and we are interested in becoming a Gentoo Mirror! We are wanting to know info about system requirements and configuration. Cumps Armindo Silva -- -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. Sir Arthur C. Clarke -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 43: GLEP File Hosting
I suppose my only question is, why can't examples be inlined at the bottom of the glep, and simply use a in document link to reference them? On 11/7/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: Ok, this is a change to the GLEP process, so it itself needs to be a GLEP... All it does is propose that GLEPs be allowed to stick example code in a subdirectory rather than having to inline things or shove them off on someone's devspace. Text version attached. An HTML version will be up on the main site whenever the web nodes next sync -- may be wise to read that instead if you aren't familiar with RST :: blocks. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
An internation standard that utilizes an international language... hrm On 11/7/05, Philip Webb [EMAIL PROTECTED] wrote: 051107 Ciaran McCreesh wrote: 7 Nov 2005 15:12:20 -0500 Philip Webb [EMAIL PROTECTED] wrote: I'm serious -- Gentoo should try to follow international standards The format specified in GLEP 1 is an international standard. It's just not the same international standard that you're after. I'm not sure how it can be an international standard when it uses an English abbreviation 'Aug' for the month (raised eyebrow), but as someone said: I love standards: there are so many to choose from. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 43: GLEP File Hosting
Okay, it works according to my useless opinion :) On 11/7/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 7 Nov 2005 19:34:44 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | I suppose my only question is, why can't examples be inlined at the | bottom of the glep, and simply use a in document link to reference | them? They can be, it's just really frickin' messy. It also makes it slightly harder to copy the code out, especially if tab/space indenting needs to be preserved. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Forever. Gentoo releases mean absolutely nothing, they do absolutely nothing. The news should stay until the upgrade occurs On 11/10/05, Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 10 Nov 2005 16:07:37 -0800 Mike Owen [EMAIL PROTECTED] wrote: | What about something like /etc/portage/news.read, which contains a | single news file per line. Perhaps have support for something like | =2006-01-01 in order to be able to manually mark date ranges as | read. Eh, yet another file. No real need for it really, it just adds complexity. Besides, /etc isn't for program-generated data. Modify anything within PORTDIR is wrong. I'd put a /var/db/news and a /etc/portage/news to handle that. Which should be a reasonable timeframe for the news to stay? Till the next gentoo release? lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need Help: Creating a new third party package
On 11/16/05, Zou, Yixiong [EMAIL PROTECTED] wrote: Hi, I am trying to create a gentoo package for some internal software. I followed several Howtos online and created the ebuild file for my package. But somehow ebuild always return me the same error over and over again: $ ebuild ./component-template-0.1.0.ebuild digest Invalid package name in package.provided: component-template-0.1 !!! aux_get(): ebuild path for 'mycat/component-template-0.1.0' not specified: !!!None !!! aux_get(): ebuild path for 'mycat/component-template-0.1.0' not specified: !!!None doebuild(): aux_get() error reading mycat/component-template-0.1.0; aborting. Most likely the ebuild is not in the component-template folder. This is a requirement. I did google for this error, most say that it is because of the PORTDIR_OVERLAY. But I do have PORTDIR_OVERLAY=/usr/local/portage in my /etc/make.conf file. And I can upgrade existing Gentoo packages after modifying them. For example, I copied over the xmlrpc-c-0.9 to the /usr/local/portage/dev-libs/ and changed it to xmlrpc-c-1.03.07 and it worked liked a charm. It is just my packages are somehow not recognized by portage. I read it somewhere that the category name mycat has to be an entry listed in /usr/portage/profiles/categories. I added mycat into the categories, still the same result. Plus, this doesn't make sense because the emerge --sync would remove it. put it in /etc/portage/profiles/categories Any body has any ideas where I am doing wrong? It can't be this difficult to create a new package for Gentoo, can it? Or do I have to use gensync to create my own portage tree for this? And if I have to, anyone can point me to how to do that? There are documents on how to use gensync, but not how to create a 3rd-party portage tree. BTW, my emerge --sync takes more than 15 minutes to finish. Anybody has the same problem? http://dev.gentoo.org/~ferringb/blog/archives/2005-10.html#e2005-10-12T23_59_53.txt Thank you very much for your help. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] FEATURES=test and the internet
I've been running my latest install with features=test, makes it simple to test packages requiring stablizization and all that... at least partially.. However, I've seen a few packages that fetch stuff during the test phase from the internet, which seems like a _really_ bad idea to me. For 1, what if I -f while dialed up and then disconnect, and for two, what happens if the site it's connecting to is down? These can both effect the outcome of my emerge. So far, I've seen one of each libxml2 fetches a DTD, it fetched fine, but if I had not had internet... it probably would have died, a simple possible fix to this is to add the dtd to SRC_URI, but this an extra thing to handle for people without FEATURES=test, and without feature-specific deps (farily useless overall), there would have to be a USE=test to take advantage of this. The other is net-misc/neon, this one has a down upstream server, and the build died because of this Only way I can think of to fix this is to disable the test. Test policy seems fairly vague in general, maybe this is a good time to clarify//enforce it? Opinions? Comments? Flames? Thats what the mailing list is for! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Email subdomain
As an AT... albiet a very busy/cannot help as much as I'd like one... The only useful thing I see in here is ro-cvs access. This facilitates testing by allowing the tester to get the ebuilds as they are committed, instead of syncing and hoping not to get banned from rsync servers. I could care less about another email address, I've got enough as it is :/ On 11/18/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 18 Nov 2005 21:03:26 -0500 Scott Stoddard [EMAIL PROTECTED] wrote: | I wholeheartedly disagree. The fact that I am an AT with aspirations | towards becoming a full dev does not in any way imply that all ATs | fill the same mindset. I see the AT position as a wonderful | opportunity to give something back to Gentoo without the added | responsibility (or hassle) that comes along with being a full dev. I | get the feeling from talking to several of the other ATs that some | may not wish to become devs -- does that mean that their contribution | (direct contribution) should not be recognized? Sure, recognise their contributions, by giving them credit in ChangeLogs. -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implementation details for GLEP 41
On 11/19/05, Kurt Lieber [EMAIL PROTECTED] wrote: On Sat, Nov 19, 2005 at 05:44:41PM -0500 or thereabouts, Dan Meltzer wrote: Funy, I was just pondering that myself... is authenticated rsync really possible? Yes, it has its own auth mechanism. We actually use it for some automated cron jobs that we have. The only downside to this that I can see would be the lack of history... FEX an upgraded -rX ebuild breaks something, I could test against previous -rX's in turn to find out exactly which broke it, and other history like stuff. This may or may not be necessary/helpful, hard to say without it having happened :) So, can other arch testers please pitch in with their $.02? If we gave you rsync instead of CVS, would that be sufficient? Or do you need the revision history, etc. of CVS? And, any objections to a ~30 minute delay between CVS-this solution? 30 minutes is much better than 24 hours :) --kurt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implementation details for GLEP 41
Sorry for two mails in a row.. but out of curiosity, instead of using 30 minute rsync, why not 30 minute mirror of cvs? KDE does this fairly well, they even have it something like every 5 minutes, is there any reason mirrored cvs is not possible//feasible? is this something svn has gotten better at? On 11/19/05, Kurt Lieber [EMAIL PROTECTED] wrote: On Sat, Nov 19, 2005 at 05:44:41PM -0500 or thereabouts, Dan Meltzer wrote: Funy, I was just pondering that myself... is authenticated rsync really possible? Yes, it has its own auth mechanism. We actually use it for some automated cron jobs that we have. The only downside to this that I can see would be the lack of history... FEX an upgraded -rX ebuild breaks something, I could test against previous -rX's in turn to find out exactly which broke it, and other history like stuff. This may or may not be necessary/helpful, hard to say without it having happened :) So, can other arch testers please pitch in with their $.02? If we gave you rsync instead of CVS, would that be sufficient? Or do you need the revision history, etc. of CVS? And, any objections to a ~30 minute delay between CVS-this solution? --kurt -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Personally, I do not think the tree is the place for anything besides that which relates to the tree. I really do not think users would appreciate there sync being burdoned by Developer x broke his toe this week ; developer y is going to italy ; We recently recieved 3 new mirrors and have all this shown on their screen. This feature should only be used for things that are directly related to the tree, and will cause mass breakage if ignored. On 11/20/05, Stuart Herbert [EMAIL PROTECTED] wrote: On Sun, 2005-11-20 at 13:06 -0500, Chris Gianelloni wrote: Huh? I was using it as an example of something that I would not be interested in seeing in *my* tree since I wouldn't ever be able to attend. What did you think I meant by it. Did I at any point say that the UK dev meets are a bad thing? I felt that you laboured the point beyond what was reasonable. It's a mis-understanding on my part, and I apologise. The events I've been involved in organising have been events for users, and they've always been put together by both developers and users. I believe that some of our users *are* interested in exactly this type of news - and, from the enquiries I've had in the past, not just UK-based people. Not in the tree. There is already a place for this stuff. Delivering news via this mechanism allows us to reach far more people than we can via the other places. If we could already reach everyone, we wouldn't need this mechanism in the first place. It really sounds like you are wanting to make this proposal way too complex, but I'll wait for the actual GLEP text before making any more comments. I don't see the complexity here. We're proposing a capability to deliver news direct to our users, in a way that can be completely disabled or personalised. How many large corporations would kill to have something that could do that? ;-) If I can't convince you of the merits, I guess there's nothing else for it but to continue work on delivering the proposal without your support :( Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Dev: Thunder
BSD is dead jokes are dead. Lets move on to the next thing! Developers working on bsd are dead! SHortest development time ever thunder! oh, and who let ferringb write the intro's, needs more verbosity WHens Gentoo/Opensolaris coming? /me hides On 11/20/05, Brian Harring [EMAIL PROTECTED] wrote: Hola list, Damian Florczyk has joined the Alt project to help with the FBSD port, and NetBSD port he's been working on externally. He's 22. lives in Wroclaw (Breslau) PL, and is in his third year of CS. It goes without saying that now would be the time to unleash a few BSD is dead jokes (might as well get them out of you system). :) Please make 'em feel welcome. ~harring -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
On 11/22/05, R Hill [EMAIL PROTECTED] wrote: Chris Gianelloni wrote: On Tue, 2005-11-22 at 16:26 +0100, Marc Hildebrand wrote: Chris Gianelloni wrote: [..] Now, on the topic of the tarballs. Give me one example of something that you can do with a stage1 or stage2 tarball that you cannot with a stage3 tarball. Answer: Download it in less than 10 minutes. I'd love to see you do the same with a stage1 tarball + all the distfiles you'll need to go from stage1 to stage3. What about someone on dialup who needs a rescue CD to boot into their system after they've trashed the MBR? 88MiB vs 14MiB is a big difference in this case. Erm, why would I need a stage 1 for a rescue cd? In case you're wondering, it's more than the size of a stage3 tarball, by quite a bit. The question of interest is: Will we keep changing things without a GLEP that should *never* be touched without one? Since when is this GLEP material? Are you kidding? Since it's a fundamentally significant and highly visible change in the workings of Gentoo. The three-stage build system is one of the distinguishing characteristics of Gentoo, up there with source-based, install from scratch, and highly customizable. Every review of Gentoo I've ever seen at least mentions it. It removes no functionality, it adds no functionality. It simply changes it. How is this GLEP materiel? For the record, I don't think it matters if stage 1 goes away. Make stage 3 the Official and Supported Way of installing Gentoo, but provide stage 1 as a minimal LiveCD/RescueCD option. Make a mention in the install documentation along the lines of It is also possible to do a full install of Gentoo using a minimal Rescue LiveCD and a network connection. This method is depreciated and should only be used if circumstances prevent you using the Universal LiveCD. Note that we do _not_ provide support for systems built using minimal installations, so you're on your own. (linkity to a new separate stage 1 doc page) --de. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Possible solution: email subdomain
On 11/23/05, Duncan [EMAIL PROTECTED] wrote: Marius Mauch posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 15:40:49 +0100: On Wed, 23 Nov 2005 03:39:08 -0700 Duncan [EMAIL PROTECTED] wrote: Here's the proposal again. If there's an issue with it, shoot it down, but from here, it certainly seems to fit the bill. Again, I'd /love/ to say I was the one that came up with it, but I wasn't. =8^) * give [AH]Ts a name[EMAIL PROTECTED] address. - It's not a subdomain, so the existing infrastructure should have no problems with it. - [EMAIL PROTECTED] remains distinctive enough it should alleviate any doubts or confusion over status. Has the same problem as a subdomain as it creates two classes of devs. So it would solve the potential technical problems, but we still have the semantic issues. Viewpoint seen, and thanks for posting it. However, the proposed solution still appears from here to fit the bill, because... - The folks to whom it will apply are /not/ full devs, as they haven't gone thru the dev process, so it's not creating two classes of devs, but rather creating a distinction between devs and this not-dev class. Can we get all current developers renamed to nick.developer then? just to alleiviate any confusion someone may have... [snip a buttload or two] -- gentoo-dev@gentoo.org mailing list
Re: Re[2]: [gentoo-dev] Re: Possible solution: email subdomain
forgot my sarcasm tags :) Get the idea though? On 11/23/05, Jakub Moc [EMAIL PROTECTED] wrote: 23.11.2005, 20:07:15, Dan Meltzer wrote: Can we get all current developers renamed to nick.developer then? just to alleiviate any confusion someone may have... [snip a buttload or two] NO (I sincerely hope at least), and please let's finally stop messing w/ email addresses causing further confusion and administrative overhead for no good reason. :=( *sigh* -- jakub -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On 11/23/05, Mike Owen [EMAIL PROTECTED] wrote: On 11/22/05, Chris Gianelloni [EMAIL PROTECTED] wrote: Give me one example of something that you can do with a stage1 or stage2 tarball that you cannot with a stage3 tarball. I may not be the typical user, but I use Stage1 to build servers, because I can fit a boot image + stage1 tarball on a small usb drive, boot to that, and then I nfs mount $DISTDIR and $PORTDIR from a central server. Correct me if I am wrong, but doesn't the boot image itself have nfs built in? why a stage1 at all... Mike -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On 11/27/05, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: On Sunday 27 November 2005 00:10, Luca Barbato wrote: It's great! Make it a FEATURE default on for common profiles. +1, and it would be better if the FEATURES, instead of removing the generated files, would disable the building of them completely, mainly because work systems with limited CPU, RAM and HDD space would probably prefer not having to create and store them :) Err, maybe I am incorrect, but isn't it more work to ungenerate them (using strip) then to just not install them? /me thinks of laptops -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
Random thought May be completely off base. Could this debug info be NFS shared? assuming like computers, or would it be different on each computer. On 11/27/05, Tavis Ormandy [EMAIL PROTECTED] wrote: On Sat, Nov 26, 2005 at 12:50:30PM -0500, Ned Ludd wrote: I'm in favor of it enabled per default but I'd like to know what you think and why. (advantages of on/off by default etc..) This should definitely be enabled by default, we dont need to enable debugging information for this to be useful, just having the symbol table available will make getting backtraces and diagnosing problems many times easier with little extra diskspace requirements. Gentoo is way behind on this feature, all the other major distributions have caught on to how useful detatched debugging symbols can be. If we dont enable this by default, I think the users who really need it (ie, the ones who want us to track down a bug but are unable to provide enough debugging information to do so) probably wont have the foresight to turn it on. This could also be a major boon for administrators imho, if a service is dumping core unpredicatbly this feature and enabling coredumps would be enough to start tracking down the problem, or at least identifying the culprit. -- - [EMAIL PROTECTED] | finger me for my pgp key. --- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild suggestion: texmaker
bugs.gentoo.org http://dev.gentoo.org/~plasmaroo/devmanual/ http://www.gentoo.org/doc/en/ebuild-submit.xml not gentoo-dev@lists.gentoo.org On 12/10/05, Herbert Lists [EMAIL PROTECTED] wrote: Hi, A great software that would be fun to have on Gentoo is texmaker. http://www.xm1math.net/texmaker/ I don't know how to help on get this ebuild on Gentoo but I can try to help with this one if you guys tell me how. Thanks, Herbert -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The deal with epkgmove
Gcc has also moved to subversion... On 12/10/05, Jason Stubbs [EMAIL PROTECTED] wrote: On Sunday 11 December 2005 00:56, Luca Barbato wrote: svn so far was good but I don't know which big projects had it deployed. KDE uses subversion, depending on what you call big of course. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On 12/10/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 7 Dec 2005 23:49:59 + Mike Frysinger [EMAIL PROTECTED] wrote: | current agenda: | none ?! How about a decision on what's to be done to fix the GLEP 41 mess? glep 41 was approved... people ranted, it fell off the maps... I don't see where the mess is, its between infra and the glep authors, who seem to have fallen off the screen for at least a little while -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Point of Clarity, and the ``mysql-5`` database format changes. These changes actually occured in mysql 4.1, not mysql-5 On 12/10/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: Main changes since the previous edition: * File format tweaks. * Changes to the way relevance headers work to make it easy to do things like show this to gcc-3.3 users on x86 or sparc. * News items are no longer copied. This makes it considerably easier to install news items -- there's no longer a need to do clever directory syncing tricks. For those of you who can't read RST, an updated version will appear on the website sometime in the not too distant future. For those of you who can, see the attached. For the sake of keeping this vaguely sane, replies that meet any of the following criteria will be ignored: * Top or HTML posting * Lack of coherent English sentences, complete with proper punctuation and capitalisation. * The sender's first name ends in 'an', and they are not me. * Questions about why the GLEP doesn't address hypothetical vapourware concepts. * Questions about why the GLEP doesn't provide a way to tell users that there's a pissup at Reuben's house next Tuesday. * Questions about why the GLEP doesn't require integration with other systems, rather than leaving it merely as something that should be easily doable. * Anything involving XML. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On 12/11/05, Wernfried Haas [EMAIL PROTECTED] wrote: On Sun, Dec 11, 2005 at 01:35:50AM +, Ciaran McCreesh wrote: Although most package updates are clean and require little user action, occasionally an upgrade requires user intervention during the upgrade process. Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-5`` database format changes. There are currently several ways of delivering important news items to our users, none of them particularly effective: I'd suggest changing this to something more constructive - calling our current efforts none of them particularly effective isn't exactly a constructive way of critizing things. * Gentoo Weekly News * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists * The Gentoo Forums * The main Gentoo website * RSS feeds of Gentoo news Einfo is currently being used for that purpose as well - even if the GLEP will leave it for less important news in the future. So i guess it should be listed here. A more reliable way of getting news of critical updates out to users is required to avoid repeats of the various recent upgrade debacles. As it was mentioned above, gcc 3.4 went pretty well on x86, can't comment on mysql as i don't use it myself. I'd suggest changing this text for something more diplomatic as i don't see much sense in having council approved GLEPs talking about council approved upgrade debacles. I'd suggest: A more reliable way of getting news of critical updates out to users is required to prevent problems during upgrades. My opinion? The gcc-3.4 upgrade has appeared to go fairly well because it doesn't automagically upgrade, it requires manual intervention before it is used. People see this and investigate. This is not something that always happens (apache anyone?, baselayout ~arch anyone?) And due to this, I don't believe we can judge success on the gcc upgrade alone. .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages which are displayed post-install. That is a separate issue which is handled by ``elog`` [#bug-11359]_. Thanks for clearing this quite important point up. Thus, at least 72 hours before a proposed news item is committed, it must be posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to [EMAIL PROTECTED] (exceptions may be made in exceptional circumstances). Any complaints ??? for example regarding wording, clarity or accuracy ??? **must** be addressed before the news item goes live. I know you think it is beyond the scope of this GLEP, but i believe having a new tool with rules for publication and OTOH all the old tools mentioned above without clear guidelines/hints how to use them doesn't make perfect sense. The gcc upgrade on x86 has shown so far that combining our efforts does work quite well. Even if not within this GLEP there should be some documentation how to make use of all available tools to inform users. Otherwise we just have another tool that gets more or less acceptance within the community. I'd suggest extending the process of creating a news item to also create a text to be posted to www.gentoo.org, the announce-mailinglist, the forums, RSS feeds, GWN, etc. Of course depending on the importance it may be decided to e.g. not post it on announce but only www.gentoo.org. Do you think this can be done within this GLEP or rather outside? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP XX: Fix the GLEP process
If everyone but infra was in favor of glep 41, are you saying it should be approved? /devils advocate On 12/12/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | A GLEP should list whom has been solicited and provide evidence that | each has given their explicit approval of the GLEP. A GLEP without | explicit approval of all teams involved cannot receive managerial | approval. So... If, hypothetically speaking, someone were to write a GLEP saying move developer documentation into the QA group, restructure said documentation to this new format etc etc, and the QA group were in favour, and the developer community in general were in favour, and the council were in favour, and the people proposed by the GLEP to manage the new documentation were in favour, but the existing owners of the developer documentation were not, you're saying that it shouldn't be approved? -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
Alrighty then, good enough for me :) One other thing .. Note:: A previous draft of this GLEP allowed news items to be sent to ``gentoo-core`` instead of ``gentoo-dev``. It is possible that a situation may arise where this will be necessary (for example, a security update which must break backwards compatibility and which cannot be revealed to the public before a given date). The seems like a half complete thought, I realize you want to discourage it from happening, but maybe change it to read It is possible that a situation and in only this case may it be sent to -core instead On 12/12/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 12 Dec 2005 22:30:52 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | Internationalisable |Being able to provide messages in multiple languages may be | beneficial. | | Not quite sure, is it required for GLEP's to be in american English or | is UK English fine? | | Pointing at Internationalizable The standard for Gentoo documentation is to use whichever variant the original author prefers. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
Well, it would be changing Glep 1... which probably needs an ammendatory GLEP On 12/13/05, Danny van Dyk [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh schrieb: | | Proposed change: | | | | ``Posted:`` | | Date of posting, in ``-mm-dd`` format (e.g. 2001-08-14) for | | compatibility with ISO-8601. UTC time in ``T19:53:46+`` | | format may also be included (`date --iso-8601=seconds`). Mandatory. | | I'll accept that change if you get Grant to accept a mini-GLEP | switching the GLEPs over to use that format too. I don't think that we need a GLEP for it, no matter how 'mini' it would be.. Just asked Grant if I can convert dates in current GLEPs, and he's ok with, though he wanted to have input from -dev first, so: Anyone objecting to change those dates from dd-mon- format to -mm-dd? If not, i'll commit my diff in 24h... Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDnzCgaVNL8NrtU6IRAgcOAJ0b/to61rIrLyyMLfNpx4rRrvDRDwCeLufm vqe7CvpCLGklzdgsb3DUq54= =offW -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RE: Changes to date format of current GLEPs
Whoops, sending to the list is a good idea -- Forwarded message -- From: Dan Meltzer [EMAIL PROTECTED] Date: Tue, 13 Dec 2005 15:51:16 -0500 Subject: Re: Changes to date format of current GLEPs To: Danny van Dyk [EMAIL PROTECTED] Nope, but the changes further on. Created: date created on, in dd-mmm- format The Created header records the date that the GLEP was assigned a number, while Post-History is used to record the dates of when new versions of the GLEP are posted to gentoo-dev. Both headers should be in dd-mmm- format, e.g. 14-Aug-2001. Should On 12/13/05, Danny van Dyk [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dan, Dan Meltzer schrieb: | Well, it would be changing Glep 1... which probably needs an ammendatory GLEP I would apply these changes to glep-0001.txt: [EMAIL PROTECTED] glep $ cvs diff glep-0001.txt Index: glep-0001.txt === RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0001.txt,v retrieving revision 1.8 diff -u -b -B -r1.8 glep-0001.txt - --- glep-0001.txt 4 Apr 2004 23:05:35 - 1.8 +++ glep-0001.txt 13 Dec 2005 20:45:37 - @@ -6,8 +6,8 @@ ~ Status: Active ~ Type: Informational ~ Content-Type: text/x-rst - -Created: 31-May-2003 - -Post-History: 1-Jun-2003, 2-Jul-2003 +Created: 2003-05-31 +Post-History: 2003-06-01, 2003-07-02 Do you _really_ think this make a GLEP necessary? Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDnzUXaVNL8NrtU6IRAnruAJ4zXT5+gtyvKHi3BbD1EPvJYACCYwCgmG6z FW28Kz5W3N1nFz3ZJuPOEh8= =tVHu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] UPGRADE bugs.gentoo.org
Here, have a goat. It's on me no, literally, get it off! On 12/16/05, Jeffrey Forman [EMAIL PROTECTED] wrote: To all, After blowing my upgrade window by almost 2 hours bugzilla is back up, albeit missing the pretty Gentoo theme. I will be putting that in after I've taken a break, because this upgrade was NOT FUN. First and foremost I want to thank some people over in #mozwebtools on irc.mozilla.org for their unbelievable help. Dave Miller (justdave) Gregary Hendricks (ghendricks) Justin C. De Vries (cardinal) These guys single handedly saved me from suicide. I know the look of bugs.gentoo.org is not what you expected. But i wanted to get bugs back up and then put in the cosmetic changes after some time it's been proven to work. Once again, I apologize for the extended downtime. I will now being adding prayer to my bugzilla upgrade checklist. Thanks for everyone's patience. I really appreciated t. Wish you all a happy holidays. Gentoo appreciates t. Regards, Jeffrey -- --- Jeffrey Forman Gentoo Infrastructure Gentoo Release Engineering Bugs.Gentoo.org Administrator [EMAIL PROTECTED] --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDoxn2/VRN5BlQ3dQRAiGiAKC1wcSNe6Tdt8jNMVT2m/Zx23YxVwCZAX3U AdgVj2cuJUlzKcDpMyZOHCU= =SVYc -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
Why not $(portageq newsdir) ? Currently, that would return only the one for main tree, but if/whenever multi repo support it added, it could return a space delimted list. This makes it simple to manage, and lets the portage crew a) figure out what they want to do b) implement it while keeping this working On 12/16/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 16 Dec 2005 13:18:45 -0800 Zac Medico [EMAIL PROTECTED] wrote: | I get it. The Portage team asks you to extend your spec, so you turn | it around and ask them to extend their spec. Ha ha ha. Funny | game. :) No no no. The Portage team asked me to extend GLEP 42 to include support for some random thing that they might introduce in the future. I tell them no, unless they be a lot more specific about what said random thing is going to be. | Brian agreed with you that the extended dep syntax will be necessary | at some point in the future. I also agree. So, knowing that glep 42 | doesn't require extended depset syntax, can we stop playing this game | and just settle on something like newsdir=$(portageq newsdir | gentoo)? What the heck is this 'gentoo' thing, and how does it help? Shoving newsdir into portageq doesn't help *at all* with multiple repository support. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On 12/16/05, Zac Medico [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: | Brian agreed with you that the extended dep syntax will be necessary | at some point in the future. I also agree. So, knowing that glep 42 | doesn't require extended depset syntax, can we stop playing this game | and just settle on something like newsdir=$(portageq newsdir | gentoo)? What the heck is this 'gentoo' thing, and how does it help? Shoving newsdir into portageq doesn't help *at all* with multiple repository support. Like I said in a previous email, 'gentoo' corresponds to 'magic-chicken' in your news-magic-chicken.unread files. The news reader app gets the repo identifier from the news-*.unread files and plugs that into portageq to get the directory where the corresponding new items can be found. uhh, isn't this kind of circular? It gets the repo identifier from the files in the repo... oh wait Zac -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.0 Release
http://dev.gentoo.org/~spyderous/xorg-x11/migrating_to_modular_x_howto.txt followed it this morning :) On 12/23/05, Greg KH [EMAIL PROTECTED] wrote: On Fri, Dec 23, 2005 at 03:40:57PM -0700, Joshua Baergen wrote: As many of you no doubt have noticed, spyderous and I finished bumping the modular packages to the newly released 7.0, which includes many changes and bug fixes since 6.8.2. Over the next few weeks we'll be finalizing licenses and other necessities. To whoever has been using modular for awhile: please let us know of any issues you currently have, or had during upgrading. For those of us who want to try modular now, where's the pointer to how to do this (I can't seem to find it in the archives, sorry...) thanks, greg k-h -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support
On 12/24/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring [EMAIL PROTECTED] wrote: | It's really pretty simple- get off your butt and chip in if you want | it, else you're on _our_ timeline (eg, we implement it when we deem | it sane/ready to go). Is Portage development done to support the needs of those of us who provide the tree, or is the tree expected to be restricted to whatever Portage developers feel like implementing? I'd say the latter. The tree is restricted to what is implemented in portage, and as it is a volunteer organization, what is implemented is what the portage dev's feel like implementing. If you want more to be implemented, submit patches. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support
On 12/24/05, Curtis Napier [EMAIL PROTECTED] wrote: Dan Meltzer wrote: On 12/24/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring [EMAIL PROTECTED] wrote: | It's really pretty simple- get off your butt and chip in if you want | it, else you're on _our_ timeline (eg, we implement it when we deem | it sane/ready to go). Is Portage development done to support the needs of those of us who provide the tree, or is the tree expected to be restricted to whatever Portage developers feel like implementing? I'd say the latter. The tree is restricted to what is implemented in portage, and as it is a volunteer organization, what is implemented is what the portage dev's feel like implementing. If you want more to be implemented, submit patches. hmmm, from reading the emails, bug reports and irc chats of portage devs, non-portage devs and end users I would say it's a little bit of both. The non-portage devs are using a tool provided by the portage devs that allows them to create the Gentoo distro. Those two teams work together to ensure the best possible tool. If the portage devs ONLY did what they felt like (or the opposite, only did what the other devs told them and ignored their own intimate knowledge of portage) then portage would not be where it is today. True developement is a subtle play of ideas back and forth between everyone involved resulting in an excellent piece of software. snip For the most part, yes. However, following these same lists, one notices ciaranm always taking potshots at the portage team, yet never contributing anything useful. So my previous response was directed primarily at him. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On 12/26/05, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: On Monday 26 December 2005 13:59, Simon Stelling wrote: Actually stricter, and there are way too many people to put that in without knowing what that do... or is it a default nowadays, I'm not even sure. You're mixing up 'strict' with 'stricter'. Well if I'm mixing up, someone moved the QA checks from stricter to strict lately ;) I don't run strict as I usually have modified ebuilds if I'm working on them; I don't run stricter as lot of packages that fails are not mine, I usually use it only when I'm testing my packages or my changes. strict is in make.defaults... This causes packages with executable stacks to die, and fairly arbitrarily imo (with portage 2.1_pre2 that is) (see bug 116611). IMUO, portage should never die when an issue of questionable merit comes up and features are simply those set by default. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
and my bad. I am not yet awake. It died cause of runpaths on strict, it just showed both, and I wasn't thinking when I sent earlier email... On 12/26/05, Dan Meltzer [EMAIL PROTECTED] wrote: On 12/26/05, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: On Monday 26 December 2005 13:59, Simon Stelling wrote: Actually stricter, and there are way too many people to put that in without knowing what that do... or is it a default nowadays, I'm not even sure. You're mixing up 'strict' with 'stricter'. Well if I'm mixing up, someone moved the QA checks from stricter to strict lately ;) I don't run strict as I usually have modified ebuilds if I'm working on them; I don't run stricter as lot of packages that fails are not mine, I usually use it only when I'm testing my packages or my changes. strict is in make.defaults... This causes packages with executable stacks to die, and fairly arbitrarily imo (with portage 2.1_pre2 that is) (see bug 116611). IMUO, portage should never die when an issue of questionable merit comes up and features are simply those set by default. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On 12/26/05, Lares Moreau [EMAIL PROTECTED] wrote: On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer [EMAIL PROTECTED] wrote: | That will increase the sync time for all of our users - can we please | keep this info out of the sync-tree? Learn to use the rsync exclude list. I think the point was that the 'average' user needs to pull it as well and has _no_ use for it. There are already complaints about syncs taking to long. The complaints was about the cache, not about the actual sync time This is what, maybe the equivilent of a new ebuild once, and a -rX any time somethings changed? It won't effect much at all and end up being a lot more helpful (and quickly implemented) than waiting around for someone to write a web database and pushing that through. We have metadata.xml's, why not use them? -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDsJPRfZRIPg1Gu24RAuwnAJ4uLZw5Vu2dHM1pe2xSdiGwvPXH7wCg2yCt Hpb7QrVs/RJ5Tiz4iyI0ipM= =k3qI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On 12/26/05, Brian Harring [EMAIL PROTECTED] wrote: On Mon, Dec 26, 2005 at 08:12:03PM -0500, Dan Meltzer wrote: On 12/26/05, Lares Moreau [EMAIL PROTECTED] wrote: On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer [EMAIL PROTECTED] wrote: | That will increase the sync time for all of our users - can we please | keep this info out of the sync-tree? Learn to use the rsync exclude list. I think the point was that the 'average' user needs to pull it as well and has _no_ use for it. There are already complaints about syncs taking to long. The complaints was about the cache, not about the actual sync time Complaints about both actually- try sync'ing on a crap connection. Rsync doesn't scale well the larger the dataset gets (the fact it still performs well is a testament to it being mostly a damn fine tool). We've got at least a 2.4mB overhead just for doing filelist/chksum transfers; that's not getting into pulling the _actual_ updates. This is what, maybe the equivilent of a new ebuild once, and a -rX any time somethings changed? It won't effect much at all and end up being a lot more helpful (and quickly implemented) than waiting around for someone to write a web database and pushing that through. Quicker balanced against proper; debate right now is if it's the proper place to do this (thus address that concern) :) We have metadata.xml's, why not use them? We have ebuilds, why don't we stick it there? Arguement doesn't work well there ;) Because its package specific, not version specific :) This is one of the reasons metadata came about in the first place. (No I'm not advocating tagging this into ebuilds btw). ~harring -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozextension.eclass last call!
On 12/29/05, Jory A. Pratt [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Unless there are any major objections tomorrow night I will commit mozextension.eclass to the tree. You can find mozextension.eclass at http://dev.gentoo.org/~anarchy/eclass . You can also find the firefox and firefox-bin ebuilds at http://dev.gentoo.org/~anarchy/ebuilds that are waiting to go to be added to the tree which inherit mozextension. Do you mind addressing http://article.gmane.org/gmane.linux.gentoo.devel/34397 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDtLXYGDfjNg8unQIRAlIUAJ9zqAw9woC2vyIOwv8LX4dR3GZ1AQCeJwPY Mmu6Xk5Qt8rJxh5n1k770oc= =RH5S -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozextension.eclass last call!
On 12/30/05, Stefan Schweizer [EMAIL PROTECTED] wrote: On 12/30/05, Dan Meltzer [EMAIL PROTECTED] wrote: On 12/29/05, Jory A. Pratt [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Unless there are any major objections tomorrow night I will commit mozextension.eclass to the tree. You can find mozextension.eclass at http://dev.gentoo.org/~anarchy/eclass . You can also find the firefox and firefox-bin ebuilds at http://dev.gentoo.org/~anarchy/ebuilds that are waiting to go to be added to the tree which inherit mozextension. Do you mind addressing http://article.gmane.org/gmane.linux.gentoo.devel/34397 You are kidding? It had enough time now. And it was already addressed as the eclass was not added on monday. My appologies, time off has been messing with my sense of what day it is :) Carry on! - Stefan -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
On 10/5/06, Jakub Moc [EMAIL PROTECTED] wrote: Peter Weber wrote: You don't unterstand me, sorry. There is no Universal-CD, a User must to download the LiveCD which forces he/she to use the Ncurses/X11-Installer, because there is no Stage3-Tarball. OH RLY? Maybe just read the options you can pass to bootloader to get CLI? The missing Stage3 is the real problem. Apparently... http://gentoo.osuosl.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/amd64/2006.1/stages/stage3-amd64-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/ppc/2006.1/ppc32/stages/stage3-ppc-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/ppc/2006.1/ppc64/stages/stage3-ppc64-32ul-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/ppc/2006.1/ppc64/stages/stage3-ppc64-64ul-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/sparc/2006.1/sparc32/stages/stage3-sparc-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/sparc/2006.1/sparc64/stages/stage3-sparc64-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/ia64/2006.1/stages/stage3-ia64-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/alpha/2006.1/stages/stage3-alpha-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/hppa/2006.1/stages/hppa2.0/stage3-hppa2.0-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/hppa/2006.1/stages/hppa1.1/stage3-hppa1.1-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/mips/2006.1/stages/mips3/stage3-mips3-2006.1.tar.bz2 http://gentoo.osuosl.org/releases/mips/2006.1/stages/mips4/stage3-mips4-2006.1.tar.bz2 None of which are that helpful for a networkless install :/ -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Gentoo Commitfests
On 10/20/06, Mike Doty [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a random thought that popped into my head: We could have a commit fest where everyone who wants to compete kicks in some small amount of money(say $5) maybe the foundation kicks in a little something too. Then the person with the highest amount of commits at the end of some time period(say 8 hours) gets the money, or perhaps it's split 75%/25% between the top 2. I think this is a fun way to build some team spirit. /me can see the kde team (flameeyes) holding off on committing a new release until a commit fest :/ Thoughts? - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRTkq14BrouQZ9K4FAQLZtgP8CrnN8wphHmrNqs5Powtiq/rMde4HpsXy RJiYplsLYFaV76iuY93Bn2h7Q5JlyPnRFM2GbdKtkwTTyEsawbMzqlccx+R3w46/ ns0UQJ+pNhyDbSzvEMWpMGh8QBtAdnE/VpVJX+xJtH6/+8BRzXE3SseVLgAhA4JZ hn7ERB0eN/Q= =fqp+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for XMMS
On 10/22/06, Josh Saddler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: [snip] I think masking is premature; there was never any sort of decision made in the previous discussion(s) about this. Relooking at the discussion, it appears it was quite clear, the sound herd does not want to maintain it, no one else stepped up, it would be put in an overlay once it was punted. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFO/lYrsJQqN81j74RAiZDAJ9s5u8Dntg6CWnuz6dyRlnusiI8BQCgjBXX Cx8XGA7mn9gqRBhyXbMMsS4= =DwTN -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Devrel Subproject: Gentoo Devmatch
How much would gentoo make in a ciaran vs. devrel fight? On 10/22/06, Alec Warner [EMAIL PROTECTED] wrote: Purpose: To increase funding for Gentoo Infrastructure and events. Overview: Developers volunteer to dual off against other developers (including retired developers!) in the ring. We then allow betting on the outcome of the match with Gentoo taking a percentage of the profits to cover event costs and to add to our pool of enormous moneys. Special Events: Large donations are taken up for prize fights like NeddySeagoon versus Avenj, Devrel versus UserReps, and Gentoo Developers vs Users. Problems: People may not volunteer. I do not have intricate knowledge of gambling rules within the US, we may need to hold the devmatches in another country. Bonuses: Developers with long-standing conflicts will be able to voice their personal feelings via fists and feets. Source: #gentoo-dev ramblings. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Package Removal
I think you gave the wrong forum link :) On 10/23/06, George Prowse [EMAIL PROTECTED] wrote: A user has stated this in a thread. Could someone respond please? http://forums.gentoo.org/viewtopic-t-510146.html I suggest that the devs don't hard mask packages, especially ones depended on by several other ebuilds, until notice has been given in the GWN's pending package removal section. If proper notice were given, then there would be much less user outrage when they suddenly can't update their systems after syncing their portage tree. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for meeting on 20060914
On 11/9/06, Bryan Østergaard [EMAIL PROTECTED] wrote: Hi all, here's the complete log from the Council Meeting + a short summary. Summary: All council members was present (Andrew Gaffney (agaffney) proxied for Chris Gianello (wolf31o2)). Agenda was: 1. Reply-to-list 2. SPF 3. QA update / plans 4. Bugzilla status 1. Council decided that there were no need to change mailinglist behaviour regarding reply-to-list. Bryan Østergaard (kloeri) mentioned that a replytolist plugin for thunderbird-2 had just been committed the day before. Bryan will update the handbook to include information on procmail recipes to change reply-to behaviour on an individual basis. Bug 154595 tracks progress of this update. Just out of curiosity (as it doesn't affect me anyways) is there any reason that some lists display different behavior? it would seem to me it would make more sense from a maintaince point of view if there was some standard. 2. Council decided that Infra needs to document use of third party smtp servers and usage of dev.gentoo.org SMTP server. Bug 154594 tracks this issue. 3. Bryan Østergaard gave a short update on QA team on behalf of Stephen Bennett (spb). Plans currently include: - Documenting EAPI-0 and PMS (Package Manager Standard) - Doing more automated QA checks. - Implementing GLEP 48 (see http://glep.gentoo.org/glep-0048.html) - Working out what each QA team member wants to work on. 4. Robin Johnson (robbat2) gave a quick status update on bugzilla. The load-balanced mysql is working very well now but there's still some webserver tuning that needs to be done. There's no timeframe as such as there might still be unexpected issues cropping up. Open floor discussion: Torsten Veller asked if there was any news on portage tree signing. Robin Johnson said there was no news as he'd spend all his time working on new bugzilla setup and anonymous cvs. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for IRC channel/ user forum
I don't think that officially supported ebuilds that are officially unsupported is a good idea. If they were officially supported then they would in effect never be removed, just simply placed somewhere else. It seems to me that this should be a third party project if anything. On 12/19/06, Steve Long [EMAIL PROTECTED] wrote: antarus posted recently to the user reps forum asking for feedback on how to solve user experience glitches like the recent xmms removal. (I do *not* want to discuss that thanks ;) The thread is at: http://forums.gentoo.org/viewtopic-t-516142.html richfish came up with the simplest solution to the problem of old ebuilds: The best possible case I can think of for most of these ebuilds is to push them upstream assuming upstream is alive and willing to maintain them (possibly with some user-supplied patches now and then). Users would then be responsible for installing the ebuilds to their local overlays, and filing bugs with upstream if something doesn't work. In fact, my strong preference in this is to just tell users to use their local overlay regardless of whether upstream accepts ownership of the ebuilds. I would even suggest we encourage this by providing a dedicated forum and IRC channel for users to help each other with their 'private' ebuilds. This requires a new IRC channel and forum (one suggestion was `sunset' 8) so I thought I'd post in here to see what everyone thought. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
see http://dev.gentoo.org/~antarus/projects/soc/glep-0052.txt and http://article.gmane.org/gmane.linux.gentoo.devel/42044/match= On 1/17/07, Georgi Georgiev [EMAIL PROTECTED] wrote: Quoting Robin H. Johnson [EMAIL PROTECTED]: 2. See the results (and as-yet unpublished GLEP) of Antarus's Summer of Code research into VCS migrations. Where can I see these results? The Gentoo SOC page only has a link to Planet Gentoo, Planet Gentoo has a link to a dead blog (http://scriptkitty.com/blog) and the RSS feed has exactly one post by antarus. The Google SOC page does not have a link for antarus' project... This message was sent using IMP, the Internet Messaging Program. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 help
Isn't this kind of against what glep40 set out to do? On 1/28/07, Christian Faulhammer [EMAIL PROTECTED] wrote: Hi, As we all notice from time to time, amd64 team is lacking behind a bit, due to various reasons. a) manpower, b) a lot of keywording. Java team asked arch teams if they object when Java team marks stable generation-2 ebuilds on their own, due to the long time it takes and to the amount of ebuilds to be stabilised. So, maybe we can discuss here another helping hand for amd64. Devs that work with a given software (not necessarily the maintainer) on amd64 architecture and when there is a keywording bug open, then said devs can keyword the ebuild. For a short period of time this could be allowed to all devs. Any objections? V-Li -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 help
On 1/28/07, Petteri Räty [EMAIL PROTECTED] wrote: Dan Meltzer wrote: Isn't this kind of against what glep40 set out to do? Top posting... Any way the thing was that the only change in these ebuilds are the eclasses/eclass functions used and the new eclasses have been proven stable already. Regards, Petteri okay, i'll bottom post this time just for variety. From opfers post it sounded like he was proposing to allow this for all packages (not just java). I was enquiring after that. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
I'm replying here because I couldn't decide whether or not it made more sense to reply to your email, your blog post, your reply to flameeyes blog post, your radio commercial, your television advertisement, or your phone call. The things that this doesn't do (Or if it does it isn't documented) is account for: *packages where there is no stable version on that arch. (Or does adjutrix still suggest keywording.. its unclear) * This doesn't address the initial claim that versions of packages are in the tree waiting on only a mips/lesser supported arch to keyword them. It only says that some arch has keyworded a package stable, and others havn't, this does not show that version N is only in the tree because of arch xyz (which is why I stated that adjutrix doesn't do this). * The numberes themselves could be considdered useless as it only shows packages which have been marked ~ on that arch in the past (not missing keywords)-- Therefore on an arch like x86/amd64 where more packages have been tested, there will be more to stabilize. (I realize that this doesn't really affect the initial claim any, just pointing out how the numbers are not that representative. On 2/19/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. I think the first step is to establish what all the problem architectures are. We all know that mips is by far the worst offender, but by how much? Rather than speculating wildly, I decided to make use of adjutrix and wc to find out. So, here we have a table showing just how much mips is a slacker arch: Arch Number of packages where this arch is slacking == m68k 37 ppc-macos 56 sh84 s390 87 arm 120 sparc155 hppa 176 ia64 221 ppc64278 mips 292 ppc 359 alpha361 amd64413 x86 560 As expected, supporting minority archs is leading to tree-wide bloat and huge initial rsync times for users. Clearly something has to be done to protect Gentoo from those useless minority archs! I mean, how many users do we *really* have using amd64 or x86? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On 3/5/07, Stephen Bennett [EMAIL PROTECTED] wrote: On Mon, 05 Mar 2007 12:49:10 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: What we want to discuss is a possible timeline for completion, and what resources you may need to get it done within the agreed timeline. Notice that I used timeline, instead of deadline. It was done on purpose really just to shut people the hell up. We're not out to get anybody, we're just wanting to make sure we're all on track and moving forward. And, now that what was actually meant has been clarified, I'll be more than happy to provide relevant information and answer questions the Council might have related to the matter. 300 messages, two developers, and 17 cups of coffee later.. :) -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Something positive! (was Re: Client-serve flags (again ;))
This thread is gay. On 3/11/07, Stephen Bennett [EMAIL PROTECTED] wrote: On Sun, 11 Mar 2007 15:34:41 + Jeff Rollin [EMAIL PROTECTED] wrote: Huh? Excuse me, but as I tried to indicate in another message, I'm as much on YOUR side as anyone else's. Then stop continuing the thread. Everyone stop continuing the thread. It's over. Dead. Gone. Etc. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Some council topics for March meeting
On 3/13/07, Steve Long [EMAIL PROTECTED] wrote: Duncan wrote: Has anyone stopped to think... he might have an ulterior motive here? Clearly, it's trolling, the quote above should demonstrate that beyond doubt. However, one must ask what the reason might be for such deliberate trolls. Yes it was, and I apologise unreservedly both to spb and the readers of this list who have shown such patience with me. Looks like trolling to me... code of conduct needs a test dummy perhaps? Perhaps the reason is to see (and demonstrate in the process) just how far one can go before one /does/ get pushed off the list. I was frankly shocked at both active sides earlier in the thread, perhaps this is just trying to push it as far as possible, maybe with the motive of driving the council to /some/ sort of action to institute enforceable and enforced list guidelines. I was trying to show spb that reading personal attacks against oneself in this forum is not a nice feeling. It was a stupid, priggish thing to do. Ya think? -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo's problems
On 3/14/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Thu, 15 Mar 2007 03:45:01 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: QA is supposed to avoid fixing other people's code where things are actively maintained. I usually ask before messing with other's stuff but if I find something wrong I rather fix it myself while I'm at it (and I'm quite happy if people does the same for my stuff). in the genstef vs hansmi example if hansmi just asked genstef if he mind if he just change the masking to the proper one and just commit the local fix he had in place to make paludis happy probably won't be much to argue. Paludis had nothing to do with that. It was a Portage change that required the update. hansmi's log was from 1-06-2007. The change in portage was added 1-23-07. This was before the discussion and portage fix, when the reason was pure paludis. (http://sources.gentoo.org/viewcvs.py/portage?rev=5760view=rev) -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Resignation
On 4/17/07, Steve Long [EMAIL PROTECTED] wrote: Jakub Moc wrote: So Since devrel has been so kind and suspended me, based on our brand new CoC, I don't feel any need to stay on this project any more. I'm therefore resigning from this project. OMG NO! Please reconsider. I'm pretty sure it will be actually no loss for Gentoo, since those folks that contributed to my retirement far outweigh the benefit I could ever possibly be to this project. This can be clearly evidenced by their long-lasting good record as in [1] and [2] and [3]. In devrel's own words, one needs to respect the wishes of maintainers. Man first you devs think it's your god-given right to behave nastily to any usr, then you get all sensitive about Jakub on bugzilla. That is lame, imo. Maybe there should be something about requiring a thick skin to be a dev, since you so clearly require it of usrs. Please do some research before spouting off. Watch the bug-wranglers@ alias for a few weeks (its too late now) to see that jakub tended to yell and scream and make a bigger mess than he resolved a lot of the time when it came to bug wrangling. Finally, my thanks go to devrel and especially our devrel lead, for the professional, unbiased etc. conduct they've presented on my devrel bug [5] (sorry, ask your friendly devrel member to unrestrict if you can't read it, after all I can't access it either), as well as before. I indeed entirely failed when I removed myself from the discussion about possible misbehaviour on [my] side. I'm pretty sure the fact that noone CCed me there in the first place for about 9 months was just an unfortunate oversight of our fully professional devrel. So who watches the watchmen? IOW who does one take a complaint about devrel to, and will there be any action? The classic answer was always We watch each other, but that's clearly not working if you are left out of a discussion regarding yourself for 9 months. /me eyes sourceMage in desperation. -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Planning for automatic assignment of bugs
On Thursday 26 April 2007 3:40:06 pm Robin H. Johnson wrote: So as a not-so-brief follow-up to solar's email, here is a brief proposal on the automatic assignment stuff, incl. one spot that we might need to add an attribute to metadata.xml. Assignment process, triggering: === Auto-assignment will be be applied/available in the following cases: 1. New bugs created with the guided process, having a Product equal to 'Gentoo Linux' and a component not equal to 'Eclasses and Profiles'. 2. Open bugs will have a new action available: 'Reassign by metadata', with a text input field. The text field will be auto-filled with a package atom $CAT/$PN by parsing the summary line. Using the action will provide the package atom to the next stage. If multiple package atoms are present in a summary line, the first one wins. Assignment process, after the package is known: === We have a package spec now, so we can find who to assign the bug to. Objectives in this section are to reduce unwanted duplicate mail, while still preserving the data in metadata for non-automated usage. Case 1 - Metadata contains only a herd -- - The herd will have @gentoo.org appended, and this must be a valid bugzilla account. Case 2 - Metadata contains a single maintainer -- - The herd field is not used. - The maintainer address is used as the bugzilla assignee. This is important for all the herds that have aliases that are NOT the same as their herd name! This diverges from existing manual practice, to avoid unnecessary duplicate mail, and means that existing metadata may need a cleanup. Case 3 - Metadata contains multiple maintainers --- - Follow case 2 first. - Further maintainer addresses are used in the CC field. Case 4 - Metadata contains multiple maintainers, some special - - Follow case 3 first. - If a maintainer is listed in the metadata for special reasons (eg only for some special patch), they should include the 'contact=0' attribute on their maintainer element AND have a role element present describing why. - This also allows for cases where the herd address should be used as the assignee, and the maintainer does NOT want a duplicate CC. Comments etc welcome. Sounds good... one suggestion I have is to try and detect new ebuild submissions and resassign them to m-w automatically as well. maybe a checkbox this is a new ebuild or some other way to automatically detect it? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] KDE 4 alpha 1 packages for Gentoo?
On Thursday 03 May 2007 9:12:35 am Jos Poortvliet wrote: Dear people, In a few days KDE 4 alpha 1 will be released, and we would like to give as many people as possible the opportunity to have a look at the next generation linux desktop. Thus an article is being prepared to explain to people how they can obtain KDE 4 Alpha 1 packages. A Suse-based livecd exists, and packages will be available for Suse, Ubuntu, Debian, Fedora and OS X, but we haven't heard from the Gentoo community yet. So, as to ensure the article will be reasonable complete, we'd like to inquire if Gentoo will have Alpha 1 packages available to it's users. AFAIK, kde4 alpha one packages will be availible in the same overlay as the kde4 tech preview packages and the kde4 live svn packages, that is--the kde4 overlay. We thank you for any comments on this matter. Greetings, Jos Poortvliet (KDE-nl) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [news-item] Paludis 0.24
On Friday 04 May 2007 4:49:47 pm Piotr Jaroszyński wrote: Hello, Thanks to zmedico we now have support for news items on infra-side and heck they are ready to use. And we should use them! Attaching news item for paludis 0.24. Justification: major config format change. How does this fit the following parts of the GLEP? Preemptive Users should be told of changes before they break a system, not after the damage has already been done. Ideally, the system administrator would be given ample warning to plan difficult upgrades and changes, rather than only being told just before action is necessary. A more reliable way of getting news of critical updates Additionally, what about this is so critical that it will not allow elog to be used? -- [EMAIL PROTECTED] mailing list
