Re: [gentoo-dev] useful profiles.desc
On Sat, Nov 05, 2005 at 01:34:55PM -0500, Chris Gianelloni wrote: > On Sat, 2005-11-05 at 09:23 -0500, Aaron Walker wrote: > > Continuing a subject I've brought up several times in the past... > > > > Are we any closer to having a profiles.desc that lists all valid profiles? > > IIRC the current stable portage should be ok with it. Are there any other > > issues preventing this from becoming a reality? > > Also, what are the valid "status" entries? Is it just dev and stable? well, repoman only cares about "dev", but yes, those are the only two status values we are using atm -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.defaults ( auto-use )
On Mon, Nov 07, 2005 at 02:05:37AM -0500, Alec Warner wrote: > Could we by chance, mandate some sort of comment field in that file not > unlike package.mask? what really needs explanation ? i mean, why do you need a comment for say: aalib media-libs/aalib canna app-i18n/canna and every package in there is the same way > I'm also a bit worried that things were placed in there a while ago and > are no longer needed, may also be a good idea to date the entries. like what ? dating is pointless imo, use `cvs ann` :P -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.defaults ( auto-use )
On Mon, Nov 07, 2005 at 10:08:45AM -0500, Alec Warner wrote: > Mike Frysinger wrote: > > On Mon, Nov 07, 2005 at 02:05:37AM -0500, Alec Warner wrote: > > > >>Could we by chance, mandate some sort of comment field in that file not > >>unlike package.mask? > > > > > > what really needs explanation ? i mean, why do you need a comment for say: > > aalib media-libs/aalib > > canna app-i18n/canna > > and every package in there is the same way > > Because I want to know WHY this flag is required to be in use.defaults > vs a normal flag? Because maybe flags were added in the past to cover > situation X and now that situation is fixed another way and we can pull > the flag out of use.defaults i think you're confusing use.defaults with the USE in profile make.defaults use.defaults is there to simply automatically enable USE flags if a package is installled, nothing more and nothing less > >>I'm also a bit worried that things were placed in there a while ago and > >>are no longer needed, may also be a good idea to date the entries. > > > > > > like what ? dating is pointless imo, use `cvs ann` :P > > Right..cvs ann...how do I do that from viewCVS again? :) well, if i had to guess, i'd say try clicking the link that says '(annotate)' > In the end I just wonder at the use of these things. They are both > helpful and bad. if you want to start a thread about punting use.defaults, then do it ... trying to slowly bleed the file of entries is dumb -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.defaults ( auto-use )
On Mon, Nov 07, 2005 at 10:50:14AM -0500, Alec Warner wrote: > A. use.defaults exists for a reason, and developers are using it to > enable functionality. > B. Turning off a flag in use.defaults may cause undesired behavior. > > that reason is. If it doesn't do anything useful, then yeah, I'd like > to see the flag punted from use.defaults because then it's just fluff. then your comment about people putting packages in there to work around problem X doesnt make any sense entries exist in use.defaults to map a USE flag to the package it represents (when such a package exists, things like nptl obviously dont have a mapping by definition, no entry in there is a 'work around' or 'fluff', but exists *only* because a USE flag <-> package mapping exists ... if anything, our use.defaults file is *missing* a ton of entries (i'll toss in more tonight for fun :P) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] divx4linux sudden death
On Sunday 30 October 2005 03:22 pm, Diego 'Flameeyes' Pettenò wrote: > On Sunday 30 October 2005 21:09, Peter Ruskin wrote: > > Steady on Diego - what replaces divx4linux then? > > ffmpeg and xvid are enough to decode and encode divx files. that avoids the implied question can ffmpeg/xvid be used as drop-in replacements ? or do upstream peeps need to write completely new code to use ffmpeg/xvid ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, Nov 15, 2005 at 02:52:28PM -0500, Chris Gianelloni wrote: > On Tue, 2005-11-15 at 20:19 +0100, Marius Mauch wrote: > > Was just about to finally commit the elog related config stuff into > > make.conf just to notice (again) that there are 14 (in words: fourteen) > > different make.conf files there, with almost all of them just differing > > in CFLAGS and CHOST (only exception is make.conf.mac which isn't used > > anymore in any way AFAICT). > > Where are these files that you're even talking about? before catalyst started nuking make.conf, they were the standard /etc/make.conf files ... now though, you can find them at /etc/make.conf.example -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, Nov 15, 2005 at 04:01:07PM -0500, Chris Gianelloni wrote: > On Tue, 2005-11-15 at 20:01 +0000, Mike Frysinger wrote: > > On Tue, Nov 15, 2005 at 02:52:28PM -0500, Chris Gianelloni wrote: > > > On Tue, 2005-11-15 at 20:19 +0100, Marius Mauch wrote: > > > > Was just about to finally commit the elog related config stuff into > > > > make.conf just to notice (again) that there are 14 (in words: fourteen) > > > > different make.conf files there, with almost all of them just differing > > > > in CFLAGS and CHOST (only exception is make.conf.mac which isn't used > > > > anymore in any way AFAICT). > > > > > > Where are these files that you're even talking about? > > > > before catalyst started nuking make.conf, they were the standard > > /etc/make.conf files ... now though, you can find them at > > /etc/make.conf.example > > Ahh... and there's different ones installed based on some criteria, > rather than a single example? Now it makes sense. congrats, the last horse just came in -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/realone, media-video/realvideo-codecs and old versions of realplayer
On Wed, Nov 16, 2005 at 07:48:56PM +0100, Diego 'Flameeyes' Petten?? wrote: > On Wednesday 16 November 2005 19:34, Julien Allanos (dju`) wrote: > > So, what are the substitutes? > > win32codecs and realplayer-10.0.0.6 ? you asking or telling ? didnt you learn anything in elementary school ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] FEATURES=test and the internet
On Thu, Nov 17, 2005 at 02:38:13AM +, Dan Meltzer wrote: > However, I've seen a few packages that fetch stuff during the test > phase from the internet if you have any packages other than libxml2 that do this, you should file bug reports about each one -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/realone, media-video/realvideo-codecs and old versions of realplayer
On Thu, Nov 17, 2005 at 09:28:00PM +0100, Francesco R. wrote: > Alle 20:16, mercoled? 16 novembre 2005, Mike Frysinger el ga butta: > > |On Wed, Nov 16, 2005 at 07:48:56PM +0100, Diego 'Flameeyes' Petten?? > wrote: > > |> On Wednesday 16 November 2005 19:34, Julien Allanos (dju`) wrote: > > |> > So, what are the substitutes? > > |> > > |> win32codecs and realplayer-10.0.0.6 ? > > | > > |you asking or telling ? didnt you learn anything in elementary > > | school ? > > noone here speak english at elementary school, I suggest you to follow > one course here to learn about it. well when you learned english, you clearly skipped the class where they explained the concept of a 'joke' studyhardernexttimekthxbye -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/realone, media-video/realvideo-codecs and old versions of realplayer
On Thu, Nov 17, 2005 at 09:20:10PM +, Ciaran McCreesh wrote: > On Thu, 17 Nov 2005 21:03:04 +0000 Mike Frysinger <[EMAIL PROTECTED]> > wrote: > | On Thu, Nov 17, 2005 at 09:28:00PM +0100, Francesco R. wrote: > | > Alle 20:16, mercoled? 16 novembre 2005, Mike Frysinger el ga butta: > | > > |you asking or telling ? didnt you learn anything in elementary > | > > | school ? > | > > | > noone here speak english at elementary school, I suggest you to > | > follow one course here to learn about it. > | > | well when you learned english, you clearly skipped the class where > | they explained the concept of a 'joke' > > I'm glad to see that you studiously attended the classes where they > taught 'capital letters' and 'punctuation'. i had a bad habit of playing hl:cs when i should have been going to class :( -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] punting the use.defaults feature
On Fri, Nov 18, 2005 at 04:33:08PM +0100, Jakub Moc wrote: > would someone more competent explain to me, why you approached this all wrong ... you were supposed to say something like "can we get rid of this hidden feature please" i see no reason to keep use.defaults around anymore, i think the rest of our config/profile system covers for it adequately and in a manner that doesnt confused people > - this feature even exists it made sense when it was designed ... back in the much, much older days of portage > - why has a mass of things been commited in there recently because they belong there > - confusing users the file has always confused people, whether they be user or dev > - rendering /etc/portage/package.keywords useless (install a dep for one > particular ebuild and enjoy the USE flag enabled globally) unrelated > - causing unwanted results (I did not really install app-text/recode for the > purpose of enabling USE=recode globally and make it clash with half of php USE > flags e.g.) > - causing pointless breakage/bailing out in current ebuilds for users that > have > not touched USE flags on their system at all you're confusing "feature" with "bug" ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] punting the use.defaults feature
On Fri, Nov 18, 2005 at 11:18:58AM -0800, Drake Wyrm wrote: > Jakub Moc <[EMAIL PROTECTED]> wrote: > > Well, I don't think so... If I want to enable a feature for one > > specific ebuild and a USE flag in /etc/portage/package.use pulls in a > > dep, that in turn enables that use flag globally, it's obviously not > > what I intended and forces me to add yet another -flag into make.conf > > If you don't want portage to employ dark magic in guessing which use > flags you want enabled, don't let it. Specify your use flags explicitly. or we can just remove the dark magic and be done with it use.defaults is almost like letting ./configure scripts auto detect settings on the fly imho -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Email subdomain
On Fri, Nov 18, 2005 at 10:06:02PM +0100, Max wrote: > On 11/18/05, Homer Parker <[EMAIL PROTECTED]> wrote: > > > > Thoughts, better ideas appreciated. > > Well, they are called testers, so why not @testers.g.o? because the idea was to put all future 'staff' there, not just AT's -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Email subdomain
On Fri, Nov 18, 2005 at 09:09:29PM -0400, Luis F. Araujo wrote: > What is the problem of giving them @g.o addresses? read the first meeting where GLEP 41 was covered ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Email subdomain
On Sat, Nov 19, 2005 at 05:54:44AM +, Kurt Lieber wrote: > On Sat, Nov 19, 2005 at 05:33:17AM + or thereabouts, Mike Frysinger wrote: > > On Fri, Nov 18, 2005 at 09:09:29PM -0400, Luis F. Araujo wrote: > > > What is the problem of giving them @g.o addresses? > > > > read the first meeting where GLEP 41 was covered ... > > If I'm understanding it correctly, the concern was that by giving folks > "real" gentoo.org addresses if they were "only" doing arch testing, there > would be no incentive for them to contribute any more than that. not really ... more like handing out @gentoo.org addresses to people was becoming a gimmick. i'm quite proud to have a @gentoo.org e-mail and dont really like the idea of trivializing it. > * There are a lot of Gentoo devs right now with full gentoo.org addresses > who don't do squat for this project, so exactly what bar are we holding > these arch testers to? this is why we have been retiring people. if a Gentoo dev is useless, then lets go with iggy's GLEP and vote the worthless cruft off the island. being a 'full dev' implies you can be held accountable and are required to fulfill a significant amount of responsibility. AT's dont generally want that level of commitment. i'm not saying that what they contribute is meaningless (they have a useful role in the Gentoo project), just that i'd like to think that i, and other 'full devs', take it to the next level. uNF -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Email subdomain
On Sat, Nov 19, 2005 at 06:23:41PM +0900, Jason Stubbs wrote: > B) What should be done with the @(subdomain_to_be_determined) email after an >AT becomes a full dev (and presumably gets a @gentoo.org address)? For how >long? this is in the GLEP ... it clearly states that it will become a forward to their new @gentoo.org address. the implied part is that when the user feels they no longer need it, they punt it. > E) What criteria must an AT meet to be able to receive the shortened >probationary when moving on to becoming a full dev? they express interest in becoming a full dev at which point they enter the normal 'becoming a dev' recruitment track. why should they have to do something special to become a normal dev ? all devs are allowed to be AT's. > G) What criteria must be met during the inital 30 day mentoring period? > H) What criteria are there for maintaining one's status as an AT? > I) What input does DevRel have in the process of becoming an AT? http://www.gentoo.org/proj/en/base/amd64/tests/index.xml -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for changes to GLEP 41
On Sat, Nov 19, 2005 at 04:26:20PM +, Kurt Lieber wrote: > * Drop the idea of giving the arch testers an email alias altogether works for me but i think makes the GLEP less meaningful > * Change @subdomain.gentoo.org to @gentoo.org. i'd be against this and i'm pretty sure others would be to (just see the first log for GLEP 41) > * Create an entirely new domain isnt .gentoo.org a new domain ? i dont see how this is any different (assuming you mean a new 2nd level domain in the .org tld) -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] opinion on how to improve the website redesign
- the 'about' blurb has way too much vertical spacing == wasted - the ad bar on the left should be thrown behind a purple bar like the current site does ... it helps the user visually tune the space out as crap they can safely ignore (at least it helps me) - can we cut out the ads alogether for known textmode browsers ? - the bar at the top which blathers on about what Gentoo has to offer i could do without completely (imo, you can read the About page) - if people insist on keeping the aforementioned bar which proclaims Gentoo's strengths, can we at least tighten up all the wasted vertical space on it ? - the links in the site index thingies at the bottom dont have mouse over behavior like the other links - the 'gentoo' text in the upper left of the page should use the cool red bubble letters [1] ... or at least drop the infinity sign ... yeah, the infinity sign is cool, but since it is in such a 'high profile' location like that, it makes people think of it as a new logo [1] http://www.gentoo.org/images/gentoo-new.gif - the little pic of larry the cow ... could we get some tiny text under his head that says 'Larry' ? - wheres the ufo guy [2] ? at least hide him in the bottom left corner of the page ... it'd keep with the mysterious nature of the fellow [2] http://www.gentoo.org/images/gridtest.gif -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] opinion on how to improve the website redesign
On Mon, Nov 21, 2005 at 03:49:42PM +0100, Thomas de Grenier de Latour wrote: > On Mon, 21 Nov 2005 14:09:55 + > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > - the bar at the top which blathers on about what Gentoo has to > > offer i could do without completely (imo, you can read the About > > page) > > What about keeping it on front page only? (with the vertical size > issue fixed sure) that'd be much better than the current situation -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] opinion on how to improve the website redesign
On Mon, Nov 21, 2005 at 06:14:15PM -0600, Grant Goodyear wrote: > One of the things that I always liked about the original design was > the fact that the front page held a considerable amount of > information without needing much vertical scrolling. on that note, here is another opinion of mine that occured to me: - the stuff on the bottom is nice (sweet pics btw), but i think it'd be more useful if it replaced the left sidebar we use now ... i.e. just stack em on the left ... > In fact, I've been thinking that it might be nice to remove the news > from the front page altogether which would leave plenty of > space for the "Documentation", "Resources", and "Community" panels with > limited scrolling. my opinion above would address this concern (which i agree with) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] opinion on how to improve the website redesign
On Tue, Nov 22, 2005 at 01:53:01AM +0100, Ingo Bormuth wrote: > > - Where is the "Search for __ in section __" field ? I would expect it > somewhere on the top. See http://php.net for a good and tiny one. ah, excellent idea ... we get people who ask for this from time to time in bugzilla ... > - I don't like the big, purple bar (portage, packages, get gentoo, forums, > donage). Get rid of it. Instead, put the headliners from the bottom > (documentation, resources, community) here. It just has to be a bit smaller > in height (multi column instead?). > You could add another Headline (maybe 'Introduction') for new users (topics > could be 'Why Gentoo Linux', 'Download', 'Handbook', 'Packages', 'Portage'). condensing the big purple panel into a smaller one would work nicely i think ... and it'd help condense information without losing too much -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] opinion on how to improve the website redesign
On Monday 21 November 2005 10:08 pm, Georgi Georgiev wrote: > maillog: 22/11/2005-12:05:38(+0900): Георги Георгиев types > > > > > > > That ought to be > > of course. or you could make it the dropdown list so people can pick bugs.gentoo.org/gentoo.org/forums.gentoo.org/whatever -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] opinion on how to improve the website redesign
On Tue, Nov 22, 2005 at 08:09:44AM -0600, Lance Albertson wrote: > Luis F. Araujo wrote: > > > I agree. Why we don't use that original design? , i think removing all that > > vertical scrolling for the front page is a good thing, and the search > > box looks > > handy too. > > They would need to coordinate with infra on how they would like to > implement a search function. For now, I think its best if they focus > their attention on the design and navigation and try to work on the > search box later. why does infra need to be involved ? cant we just have the form send users to google ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Tue, Nov 22, 2005 at 10:38:34AM -0500, Stephen P. Becker wrote: > >I don't care what you do with the docs, but the stages 1, 3 need to > >stay. stage2 has always been a bonus stage more or less added into the > >mix cuz it's a byproduct of stage building (pre catalyst days). > > I don't think anyone has implied that we're not going to distribute > stage1 anymore. They are still useful for folks that know what they are > doing. i was under the impression we were merely changing our docs and that we were going to continue to mirror stage1 and stage2 files this i am OK with -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] punting the use.defaults feature
On Tue, Nov 22, 2005 at 07:22:42PM +0100, Marius Mauch wrote: > Personally I'd just kill auto-use support in the next "big" portage > upgrade (and USE_ORDER with it as disabling auto-use is the only > real application of it that I'm aware of). works for me -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] opinion on how to improve the website redesign
On Tue, Nov 22, 2005 at 06:51:44PM +0100, Sven Vermeulen wrote: > On Tue, Nov 22, 2005 at 03:53:22AM +0100, Thomas de Grenier de Latour wrote: > > A good start could be to do that the quick and ugly way, thanks to > > Google (with some "site:www.gentoo.org/some/thing/" and other black > > magic in the query terms). > [...] > > Two major obstacles are > - Google bases its search functionality on cached pages. > I would assume that most people use the search functionality to find > documentation which gets updated quite a lot. Google might offer outdated > links or forget to point to a valuable resource > - We would depend on Google a bit i dont think these are real issues ... but no reason we cant use this as the quick 'now' solution and then follow it up with stuff on our own infrastructure later on down the road -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, Nov 23, 2005 at 01:40:45AM -0500, Curtis Napier wrote: > If there are no more outstanding issues reported I will submit this > current layout for approval. there's still a ton of wasted space in the purple bar ... if that was tightened up, more news could be displayed ... having the last two or three news items on the front page is pretty helpful imo and would help to offset all the space created by the large ad sidebar > The artwork is all part of the winning design. Any issues with the > infinity symbol should have been addressed a year ago. well it clearly wasnt, might as well cover it now before the site goes live ... as i pointed out, considering its location, this means that our new logo basically becomes gentoo with an infinity sign > I actually implemented a search that used google much like the example > that was posted here. The search was discussed at length with the > project lead and it was decided that using a third party search engine > such as google was unacceptable. why ? we all know google is great and the implementation would be both cheap and quite usable > Gentoo is a not-for-profit but, > unfortunetly, it is the wrong kind of non-profit so Google will not > sponsor us. i dont see why a simple form redirect to google would require any sort of sponsorship ... the thread fork to hardware at google was weird anyways > *all extraneous information and decorative news headers were removed > from the front page to help readability and to bring focus to the > information. This includes the cow image and text. Overwhelming amounts > of information on the front page should no longer be a problem. This > also brings the jumppads closer to the top so new users will be better > able to spot them. seems like everything was cut ... now the frontpage is just a simple site index page ? i liked the simple cow/about blurb myself -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
On Tue, Nov 22, 2005 at 08:29:36PM -0800, Tuan Van wrote: > Luis F. Araujo wrote: > >Hello everyone, > > > >A few days ago i glanced over package.mask , and i was surprised > >about how many non-existent ebuild/packages entries are there. > > > > please adjust your script. > >=cat/foo-1.2 is valid even though foo-1.2 is no longer in the tree. I > looked at the top 4 line in your list, they are all valid entries. yes, i imagine there are a bunch of these false positives ... you can see the gcc-config mask is wrongly flagged for this reason -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, Nov 23, 2005 at 01:40:45AM -0500, Curtis Napier wrote: > If there are no more outstanding issues reported I will submit this > current layout for approval. the links in the footbars still dont have 'on mouse over' behavior like all the other links -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote: > OK. I've been looking at some of these issues we've been having, and > I've been thinking of moving enewuser, egetent, and enewgroup to their > own eclass. This will resolve some issues with things in system, or > otherwise early on, requiring shadow on Linux to get useradd. Two > examples of this are bug #113298 and bug #94745. By putting them in > their own eclass, we can keep from adding shadow to DEPEND in eutils, > while still putting the dependency in the eclass that uses it. i think i suggested this somewhere before, but why dont we just add shadow to packages.build ... then it'll be in stage[123] and the DEPEND will be a moot point -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Thu, Nov 24, 2005 at 06:23:37AM +0100, Sven Vermeulen wrote: > On Wed, Nov 23, 2005 at 06:05:53PM +, Ciaran McCreesh wrote: > > > Afaicr, the infinity sign will be kept, but I know a huge discussion > > > will be held on this. It's not important in this stage of the > > > development though... > > > > And now we're told that it *was* important at that stage and it's too > > late to change things? Riiight. > > Like I said before, I rather like the infinity sign. The trustees have had a > discussion on this part too. Their decision was that we need a "strong, > compelling case for not using it since it is something the community has > voted on". by 'voted on' you mean the vote that happened on the forums ? i thought that vote was for the different website designs, they didnt really cover aspects of different designs -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Thu, Nov 24, 2005 at 08:54:41AM -0500, Chris Gianelloni wrote: > On Thu, 2005-11-24 at 03:44 +0000, Mike Frysinger wrote: > > On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote: > > > OK. I've been looking at some of these issues we've been having, and > > > I've been thinking of moving enewuser, egetent, and enewgroup to their > > > own eclass. This will resolve some issues with things in system, or > > > otherwise early on, requiring shadow on Linux to get useradd. Two > > > examples of this are bug #113298 and bug #94745. By putting them in > > > their own eclass, we can keep from adding shadow to DEPEND in eutils, > > > while still putting the dependency in the eclass that uses it. > > > > i think i suggested this somewhere before, but why dont we just add > > shadow to packages.build ... then it'll be in stage[123] and the DEPEND > > will be a moot point > > That doesn't solve the issue. of course it does ... putting a package in packages.build means it will be in all stages which means no package (like cronbase) will ever fail again because the useradd binaries will always exist -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Fri, Nov 25, 2005 at 12:46:54PM +0200, Marius Mauch wrote:
> Ciaran McCreesh wrote:
> >On Fri, 25 Nov 2005 00:49:23 +0100 "Diego 'Flameeyes' Petten??"
> ><[EMAIL PROTECTED]> wrote:
> >| Hi everybody, a little question that I'd like to be answered (so that
> >| we can make it a sort of rule).
> >| How should manpages that are generated be managed?
> >|
> >| The common sense and looking to other ebuilds would say to always
> >| build man pages, but when it asks me to install something like
> >| docbook-sgml-utils, I'm tempted not to do that ;)
> >
> >man pages can't be considered optional (despite what RMS says). They're
> >not fancy extra HTML API documentation, they're core, so they don't get
> >a USE flag.
> >
> >Of course, if FEATURES were in the USE expand list, you could use
> >! features_noman ? ( ) ...
>
> Except that no{man,info,doc} are on the to-die list anyway.
which doesnt make much sense when they can actually be pretty useful
in controlling DEPEND and/or steps in src functions which take quite a
long time to complete
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Fri, Nov 25, 2005 at 09:24:44AM -0500, Chris Gianelloni wrote: > On Thu, 2005-11-24 at 19:34 +0000, Mike Frysinger wrote: > > On Thu, Nov 24, 2005 at 08:54:41AM -0500, Chris Gianelloni wrote: > > > On Thu, 2005-11-24 at 03:44 +0000, Mike Frysinger wrote: > > > > On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote: > > > > > OK. I've been looking at some of these issues we've been having, and > > > > > I've been thinking of moving enewuser, egetent, and enewgroup to their > > > > > own eclass. This will resolve some issues with things in system, or > > > > > otherwise early on, requiring shadow on Linux to get useradd. Two > > > > > examples of this are bug #113298 and bug #94745. By putting them in > > > > > their own eclass, we can keep from adding shadow to DEPEND in eutils, > > > > > while still putting the dependency in the eclass that uses it. > > > > > > > > i think i suggested this somewhere before, but why dont we just add > > > > shadow to packages.build ... then it'll be in stage[123] and the DEPEND > > > > will be a moot point > > > > > > That doesn't solve the issue. > > > > of course it does ... putting a package in packages.build means it will > > be in all stages which means no package (like cronbase) will ever fail > > again because the useradd binaries will always exist > > I'm looking to minimize what is in a stage1 tarball, not increase it. I > would much prefer that we instead had a proper dependency tree, than > hacking around it. Applications that need to add users on Linux > *should* DEPEND on shadow. They should not rely on it being already > present. and when we move the user management hacks out of eclasses and into portage itself, where do you think shadow will end up ? in stage1 is my guess i wouldnt qualify shadow as a part of a proper dependency tree since it's the ebuild itself that requires it, not the package > Plus, your solution does not work retroactively to repair > issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does. tell users to stop using stage[12], you're already going that route :p -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sat, Nov 26, 2005 at 12:50:30PM -0500, Ned Ludd wrote: > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF > executables by default in order to aid in better debugging by or do we > want to only emit it when a FEATURE= is defined. would make more sense to have it be a FEATURE and then put the FEATRE into our profiles that way users can disable it via standard make.conf config rather than having to add some weird INSTALL_MASK setting -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sun, Nov 27, 2005 at 11:12:32AM -0500, Ned Ludd wrote: > On Mon, 2005-11-28 at 00:48 +0900, Jason Stubbs wrote: > > On Monday 28 November 2005 00:05, Jason Stubbs wrote: > > > 3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages" > > > > > > In light of the above requirements and the fact that dyn_* will likely be > > > moved into the tree down the track, #3 seems to be the best in my mind. > > > Similarly, it would solve the previously discussed problems related to > > > FEATURES="test". this seems like the best idea imo too ... > > I'd be very interested in people's thoughts on this. The more I think about > > it, the more I think it's the most appropriate solution. Nothing in > > FEATURES="noman nodoc noinfo test" affects portage whatsoever other than > > "noinfo" which (only recently) prevents emerge from regenerating info > > indexes. That one could be handled by a hook (although not yet available) > > and > > the rest could easily be switched to USE flags. > > USE=(man|info|doc) wont quite work. > While they could have an advantage that you can use them to control > depend strings the doc use flag has already been heavily used for other > things which everybody surely wont want. i dont see what USE=doc has to do with this ? doc should never be used to control manpages in ebuilds now ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Are there valid uses for repoman --ignore-other-arches?
On Sun, Nov 27, 2005 at 06:08:53PM +0200, Petteri R??ty wrote: > --ignore-other-arches Instructs repoman to ignore arches that are not > relevent to the committing arch. REPORT/FIX issues you work around. > > Are there any valid uses for this switch or can it be deprecated? From a > QA point of view this seems like a very bad option. uhh yeah, like people who want to commit a fix unrelated to any arch breakage someone else may have caused arch breakage is for arch teams to worry over ... without the -I option, maintainers are basically fucked and unable to commit any fixes until the arch issue is resolved and in case i wasnt clear, i'd be very against removing this -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Mon, Nov 28, 2005 at 09:22:33AM -0500, Mark Loeser wrote: > Only thing I see > as lacking is we might want to get a doc together on how to properly upgrade > your toolchain so we don't get an influx of bugs from users that have a > system half compiled with 3.3 and the other half with 3.4 so they get linking > errors. there is a bug open about this issue ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Mon, Nov 28, 2005 at 05:24:52PM -0500, Daniel Gryniewicz wrote: > On Mon, 2005-11-28 at 19:12 +0100, Bjarke Istrup Pedersen wrote: > > Does this mean that we can get rid of the libstd++ dependency of gcc, > > and move it to the binary packages that depends on gcc 3.3 . > > I know this has been discussed before, but once it's stable I see no > > reason to keep the dependency in the gcc ebuild, when it could be in the > > binary packages. > > Well, right after the upgrade, there will still be tons of non-binary > programs built against the old libstdc++, so no. Unless you want to > force everyone to emerge -e world after the upgrade (which will make you > very unpopular). not really an issue ... gcc is SLOTed for everyone to gccmajor.gccminor that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their system until they remove it so if user fails to rebuild all their packages before unmerging gcc-3.3 they will be screwed, but OH WELL -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > what's the official status of /usr/libexec directory? there is none afaik ... it's something we've been leaving alone for the time being because it hasnt been that critical of an issue personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, Nov 29, 2005 at 09:50:34AM -0500, Chris Gianelloni wrote: > On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: > > Every user _must_ be instructed to run > > 'revdep-rebuild --soname libstdc++.so.5', > > if a system contains things linking to libstdc++.so.5 and things linking to > > libstdc++.so.6 I consider it horribly broken. > > ...and when it tries to "recompile" openoffice-bin? doom3? revdep-rebuild should ignore those packages -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 10:18:05AM -0500, Olivier Cr?te wrote: > On Tue, 2005-29-11 at 14:53 +0000, Mike Frysinger wrote: > > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > > > what's the official status of /usr/libexec directory? > > > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc > > Why move the libexec content to libdir? They are all executables, not > libraries. Its in the same category as /usr/bin. i know they are executables, that's why we're talking about a specific subdir of lib libexec clutters /usr while /usr/lib/misc hides it nicely ... afterall, this are internal binaries that end user should never run themselves -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, Nov 29, 2005 at 10:52:11AM -0500, Chris Gianelloni wrote: > broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires > libORBit-2.so.0 libgconf-2.so.4) binary packages should never be in /usr/ > Is /opt ignored? yes, because our policy specifically says binary packages in /opt -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 04:41:20PM +0100, Thomas de Grenier de Latour wrote: > On Tue, 29 Nov 2005 15:27:10 + > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > i know they are executables, that's why we're talking about a > > specific subdir of lib > > > > libexec clutters /usr while /usr/lib/misc hides it nicely ... > > afterall, this are internal binaries that end user should never > > run themselves > > Random thought of the day: why not /usr/bin/misc? subdirs are not allowed in /usr/bin or /usr/sbin or any other bin dir -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 10:48:10AM -0500, Olivier Cr?te wrote: > On Tue, 2005-29-11 at 15:27 +0000, Mike Frysinger wrote: > > On Tue, Nov 29, 2005 at 10:18:05AM -0500, Olivier Cr?te wrote: > > > On Tue, 2005-29-11 at 14:53 +0000, Mike Frysinger wrote: > > > > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? > > > > wrote: > > > > > what's the official status of /usr/libexec directory? > > > > > > > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc > > > > > > Why move the libexec content to libdir? They are all executables, not > > > libraries. Its in the same category as /usr/bin. > > > > libexec clutters /usr while /usr/lib/misc hides it nicely ... afterall, > > this are internal binaries that end user should never run themselves > > I was going to quote the FHS to prove you were wrong but it turns > out that libexec/ has been pull out of it. And they seem to recommend a > libdir subdirectory... i know it, but i wasnt about to start quoting FHS on you :P i was hoping we could scrounge up better reasons before resorting to throwing spec files at each other > In the end it doesn't really matter, but if we > change from libexec to lib/misc.. which is why i havent really started a thread on the topic already > will need to modify a lot of gnome package at least. yeah, a bunch of packages will need to be tweaked slightly, but i dont think it should be a big deal to do ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, Nov 30, 2005 at 09:16:40AM -0500, [EMAIL PROTECTED] wrote: > Again, would anyone know what will happen to ~x86 gcc?, Will it become > gcc40 or just use the stable x86 gcc for everyone? 4.0.2-r1 wont be going into ~arch, but 4.0.2-r2 most likely will i think we've done a good deal of polishing off most of the common gcc4 issues in portage -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] contents of /dev after initial installation
On Fri, Dec 02, 2005 at 12:45:00PM +0900, Georgi Georgiev wrote: > maillog: 02/12/2005-02:47:55(+): Stephen Bennett types > > On Fri, 02 Dec 2005 03:35:23 +0100 > > Matthias Langer <[EMAIL PROTECTED]> wrote: > > > > > revealed that there are in fact hundrets of premade device nodes in > > > the /dev directory. And this is not only true for the box where i > > > discovered this, which was brought up from a 2004.x cd, but also true > > > for the box where i just installed gentoo from 2005.1-r1. > > > > > > Is there any reason for this ? > > > > Not all systems use udev or devfs. Plus, it's nice to be able to boot > > the system when your dynamic /dev management fails for whatever reason. > > I don't need a fully populated /dev to get a working shell with > init=/bin/bash on the kernel cmdline. And at that point it is easy to > run /dev/MAKEDEV and get whatever devices are needed for > troubleshooting. assuming the user knows what MAKEDEV is let alone how to use it -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] contents of /dev after initial installation
On Thu, Dec 01, 2005 at 08:43:32PM -0800, Greg KH wrote: > That being said, my boxes have an empty /dev... you so sure about that ? if your /dev is completely empty, you wont get any init output because the kernel cant find /dev/console ... and the init scripts will get pissed when they try to pipe output into /dev/null (before udev is started) and the command errors out with /dev being read-only -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] contents of /dev after initial installation
On Fri, Dec 02, 2005 at 04:15:30PM +0200, Petteri R??ty wrote: > Matthias Langer wrote: > > revealed that there are in fact hundrets of premade device nodes in the > > /dev directory. > > And this is not only true for the box where i discovered this, which was > > brought up from a > > 2004.x cd, but also true for the box where i just installed gentoo from > > 2005.1-r1. > > # UDEV OPTION: > # Set to "yes" if you want to save /dev to a tarball on shutdown > # and restore it on startup. This is useful if you have a lot of > # custom device nodes that udev does not handle/know about. > > RC_DEVICE_TARBALL="no" > > Do you have this set to yes in /etc/conf.d/rc ? he's talking about the /dev that is on the / partition, not the /dev that gets mounted for udev -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] contents of /dev after initial installation
On Fri, Dec 02, 2005 at 09:00:25AM -0800, Greg KH wrote: > On Fri, Dec 02, 2005 at 01:17:38PM +0000, Mike Frysinger wrote: > > On Thu, Dec 01, 2005 at 08:43:32PM -0800, Greg KH wrote: > > > That being said, my boxes have an empty /dev... > > > > you so sure about that ? if your /dev is completely empty, you wont > > get any init output because the kernel cant find /dev/console ... and > > the init scripts will get pissed when they try to pipe output into > > /dev/null (before udev is started) and the command errors out with > > /dev being read-only > > No, all of the /dev/null reliance has been fixed. sure, in Gentoo it's been fixed (i know cause i fixed it), but every other distro i know of the boot system would bomb my e-mail was just a follow up because a lot of people think they can safely nuke /dev and then dont understand why their machines dont boot -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] contents of /dev after initial installation
On Fri, Dec 02, 2005 at 09:18:24PM +0100, Matthijs van der Vleuten wrote: > On 12/2/05, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > sure, in Gentoo it's been fixed (i know cause i fixed it), but every > > other distro i know of the boot system would bomb > > Since when is Gentoo supporting other distro's boot systems? you missed the point i didnt want an e-mail that says 'an empty /dev is A-OK, your system will boot' hanging around for people to locate via google -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] vendors.gentoo.org
On Mon, Dec 05, 2005 at 04:24:37PM -0800, Drake Wyrm wrote: > Kurt Lieber <[EMAIL PROTECTED]> wrote: > > On Mon, Dec 05, 2005 at 04:40:28PM + or thereabouts, George Prowse > > wrote: > > > Is vendors.gentoo.org going to have the new redesign that curtis119 > > > is implementating? > > > > The eventual plan is for all web sites residing under the *.gentoo.org > > domain to have the new look and feel. > > I don't see that happening at . uhh, what ? dev.gentoo.org is a redirect to www.gentoo.org other wise it just hosts users' home dirs ... i dont see what the redesign has to do with either -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] http://people.gentoo.org/
On Tue, Dec 06, 2005 at 12:34:32PM -0600, Brian Harring wrote: > On Mon, Dec 05, 2005 at 06:39:45PM +0100, Henrik Brix Andersen wrote: > > Allowing toucan:~brix/public_html/ to be accessed under either of the > > http://dev.gentoo.org/~brix/ and http://people.gentoo.org/brix/ URLs? > *cough* > http://www.gentoo.org/~brix > > No clue if that's a hold over from older days, but perhaps that > redirect might be inline with what you're after. the more the merrier ! http://vapier.people.gentoo.org/ -> http://dev.gentoo.org/~vapier/ http://people.gentoo.org/~vapier/ -> http://dev.gentoo.org/~vapier/ http://www.gentoo.org/~vapier/ -> http://dev.gentoo.org/~vapier/ -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] December Council Meeting
this is your [belated] reminder of the December council meeting. future reminders will not be late anymore ... we've proven that we cant remember it so i've gone ahead and crontab-ed future reminders to go out on the first :) current agenda: none ?! -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix_libtool_files.sh enhancement needed for KDE upgrade.
On Thu, Dec 08, 2005 at 08:56:42AM +0100, Dirk Heinrichs wrote: > However, there already exists fix_libtool_files.sh, which does the same > after GCC upgrade. Could this be enhanced to also handle the KDE upgrade > case? i would say no ... re-emerge offending packages -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Looking for DirectFB maintainers
On Thu, Dec 08, 2005 at 09:10:28AM -0500, Chris Gianelloni wrote: > On Thu, 2005-12-08 at 14:19 +0100, Diego 'Flameeyes' Petten?? wrote: > > Another series of packages that lies around, this time for media-video > > team. > > DirectFB requires some new maintainers to take care of it and its > > applications. I'm not using it and seems like nobody else on the team is > > taking care of it, so if someone uses it, it would be good if it stepped > > up... > > Umm... > > !meta DirectFB > wolf31o2-work: Package: dev-libs/DirectFB Herd: games > Maintainer: [EMAIL PROTECTED] > > What are you talking about? yeah, you better not start pawning off my packages or i'll KLL you -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/dvdrip
On Thu, Dec 08, 2005 at 08:46:31PM +0100, Diego 'Flameeyes' Petten? wrote: > If a new maintainer is found, fine, it can remain, but currently the > resources > of Video team are limited and we have enough problems to take care of without > dvdrip. so the video herd policy is to remove packages until you're left with a small enough subset of packages you can handle ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On Thu, Dec 08, 2005 at 09:24:57PM +0100, Marius Mauch wrote: > On Wed, 7 Dec 2005 23:49:59 + > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > this is your [belated] reminder of the December council meeting. > > future reminders will not be late anymore ... we've proven that we > > cant remember it so i've gone ahead and crontab-ed future reminders > > to go out on the first :) > > Would be nice if you'd inform -dev when you change the meeting date > again in the future, esp. when both the channel and the council project > page still refer to the old date. the upcoming date is supposed to be 'tentative' which the council page says right above 'Dec 8th' but in the future we'll label future meetings dates with 'tentative' so there isnt any confusion -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/dvdrip
On Sat, Dec 10, 2005 at 01:09:50AM +0100, Luca Barbato wrote: > Mike Frysinger wrote: > >so the video herd policy is to remove packages until you're left with > >a small enough subset of packages you can handle ? > > I'd rather say that we select packages that evolve and fit the needs and > kill what isn't suitable anymore. fair enough, but i thought we've establish that there are *no* alternatives to dvdrip regardless of what diego may think -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On Thu, Dec 08, 2005 at 09:24:57PM +0100, Marius Mauch wrote: > On Wed, 7 Dec 2005 23:49:59 + > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > this is your [belated] reminder of the December council meeting. > > future reminders will not be late anymore ... we've proven that we > > cant remember it so i've gone ahead and crontab-ed future reminders > > to go out on the first :) > > Would be nice if you'd inform -dev when you change the meeting date > again in the future, esp. when both the channel and the council project > page still refer to the old date. yet another reminder ... council meeting: Dec 15th current agenda: portage hash funk decision asked by Marius web page status: UPDATED -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On Sat, Dec 10, 2005 at 06:21:20PM +, Ciaran McCreesh wrote: > On Sat, 10 Dec 2005 13:07:19 -0500 Dan Meltzer > <[EMAIL PROTECTED]> wrote: > | 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 > > GLEP 41 was approved when it should not have been, people pointed out a > huge number of flaws demonstrating its unimplementability and it's not > going to go anywhere in its current state. It's back to the council to > either unaccept it or explain how they intend to make pigs fly. there's no point in bringing it back to the council in the current form as we're just likely to approve it again -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On Sat, Dec 10, 2005 at 08:05:40PM +, Ciaran McCreesh wrote: > On Sat, 10 Dec 2005 19:40:59 +0000 Mike Frysinger <[EMAIL PROTECTED]> > wrote: > | there's no point in bringing it back to the council in the current > | form as we're just likely to approve it again > > So the council is aware of all the shortcomings and impossibilities > with the GLEP in its current form, and would still approve it? we were happy with the state of things with the GLEP in its current state. if others are not, then fix the GLEP and send it back. theres no point in trying to get the council to "fix" the GLEP when we were for the current changes (such as the e-mail domains idea). -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On Saturday 10 December 2005 18:13, Lance Albertson wrote: > I think we'll be able to work out the anonymous CVS access soon, however > it will not be implemented as stated in the GLEP. exact spec in the GLEP was more of an idea ... anon cvs is available -> OK > On the other point, infra has serious issues trying to manage a > subdomain for email addresses. This part of the GLEP we cannot > implement and we ask the GLEP authors to come up with a better solution. > Either we give them an alias that recruiters can manage, or we don't do > anything. The logistical headache of managing moving people around is > too much of a hassle for us to deal with. i would still vote for the subdomain e-mail addresses > Of course, all of these points would have made it into the GLEP *if* it > had been posted with plenty of time for people to comment on it instead > of one day. harping on this old point solves nothing. we've already established quite clearly that this will not happen again in the future. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December Council Meeting
On Mon, Dec 12, 2005 at 08:25:52AM -0500, Stephen P. Becker wrote: > >>Of course, all of these points would have made it into the GLEP *if* it > >>had been posted with plenty of time for people to comment on it instead > >>of one day. > > > > > >harping on this old point solves nothing. we've already established quite > >clearly that this will not happen again in the future. > > Technically, no. It does, however, point out that the council basically > screwed infra up the rear without using lube, and then told infra, "we > don't care, we won't discuss changing it, and we would approve it again!" it's really more up to the GLEP author(s) and infra to find the middle ground as to what's feasible. if none can be found, then yes, i would whip out my virtual wang and take it to infra again with the subdomain idea (i would however offer lube; more for myself though). -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
On Tue, Dec 13, 2005 at 03:36:33PM -0500, Dan Meltzer wrote: > Well, it would be changing Glep 1... which probably needs an ammendatory GLEP or we avoid all the redtape bs and just do it, let anarchy rule the docs team already require dates to be in -MM-DD format and it makes sense to me -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 03:59:03PM -0500, Mark Loeser wrote: > Basically what I'm looking for here is an easy to understand explanation of > what textrels are, why they are bad, and why they should hold back marking a > package stable. The only information I've been able to find states that they > could cause a performance hit, but this doesn't seem to warrant banning them > completely in my eyes. erm, this e-mail comes a bit early ... i was hoping to have more stuff written before moving this info into gentoo-dev mailing list realm ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 10:30:59PM +, Saleem A. wrote: > On Tue, 13 Dec 2005, Mark Loeser wrote: > > > Basically what I'm looking for here is an easy to understand explanation of > > what textrels are, why they are bad, and why they should hold back marking a > > package stable. The only information I've been able to find states that > > they > > could cause a performance hit, but this doesn't seem to warrant banning them > > completely in my eyes. > > The big issue with > this is that the text segment is usually suppose to be read only for > security reasons. But because the text segment needs a relocation, it > needs to be read-write since the relocation happens at runtime > dynamically. this is correct, a very good reason to fix TEXTRELs. another good reason is that since the segment cannot be mapped readonly, the memory cannot be shared across multiple processes ... each will need to have its own copy, thus wasting what could be significant memory resources. > The constant need to look up the address is what causes > the performance degredation. The performance degredation however is of > no worry to us. if by "constant" you mean "once everytime the code is loaded", then you are correct ... the relocations need to be rewritten everytime the image is loaded into memory by the dynamic loader (ldso), but after the first fixup, that's it, nothing else to be done. > > Getting a clear cut policy on exactly what issues should hold a package > > back > > from being marked stable is what I'm looking for. Issues like textrels, > > executable stacks, etc is what I'm looking for to be defined and explained > > why > > we are to always avoid them. This should be added to existing documentation > > policy so it is somewhere for new devs to know about, and existing devs to > > have for a reference. > > I agree, this would be very nice to have. It would make stabilization > of packages a little bit easier. working on it as i said ... i wish this e-mail could have been posted once i had more easier things to read :p -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 05:59:17PM -0600, Jory A. Pratt wrote: > Mark Loeser wrote: > > Basically what I'm looking for here is an easy to understand explanation of > > what textrels are, why they are bad, and why they should hold back marking a > > package stable. The only information I've been able to find states that > > they > > could cause a performance hit, but this doesn't seem to warrant banning them > > completely in my eyes. > > > > Getting a clear cut policy on exactly what issues should hold a package > > back > > from being marked stable is what I'm looking for. Issues like textrels, > > executable stacks, etc is what I'm looking for to be defined and explained > > why > > we are to always avoid them. This should be added to existing documentation > > policy so it is somewhere for new devs to know about, and existing devs to > > have for a reference. > > Only problem I see with this is binary packages. We can not control > upstream binaries as everyone is aware of. So when does it become safe > to override stable packages that have texrel's and executable stacks? no idea what you mean by "override", but here's a crazy idea ... ask upstream to fix the issues. for example, we just reported executable stacks with the ut2004 game and Ryan of epicgames was so kind as to fix it up for us. some upstream peeps dont even know about these sort of things until you point them out. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 08:02:27PM -0500, Mark Loeser wrote: > Mike Frysinger <[EMAIL PROTECTED]> said: > > working on it as i said ... i wish this e-mail could have been posted > > once i had more easier things to read :p > > You are working on a policy, or just docs to explain the issues? documentation on PIC/TEXTRELs/etc... the policy i consider a no-brainer, fix TEXTRELs -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 01:07:53AM +, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 00:22:36 +0000 Mike Frysinger <[EMAIL PROTECTED]> > | another good reason is that since the segment cannot be mapped > | readonly, the memory cannot be shared across multiple processes ... > | each will need to have its own copy, thus wasting what could be > | significant memory resources. > > Again, that's a big "could be". it's more often an "is be" considering the fact we're talking about shared library code here. > We don't avoid marking stable code > that, say, mallocs lots of space, then fills it with some calculated > numbers (for example, the first million prime numbers), even though a > better program would allow for that data to be shared. no one said that broken code with TEXTRELs cannot be marked stable they're something to be fixed down the road as time permits > Oh, and don't accept reasons like "but they don't work if we enable > $obscure_voodoo in the compiler" either. If $obscure_voodoo breaks on > legitimate TEXTRELs then $obscure_voodoo is broken, not the code using > TEXTRELs. majority of the time, if a build process is generating poor code with textrels, it wont work on most architectures. x86 just tends to be pretty lenient when it comes to poor code, so no one notices/cares. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 01:37:57AM +, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 01:20:29 +0000 Mike Frysinger <[EMAIL PROTECTED]> > wrote: > | the policy i consider a no-brainer, fix TEXTRELs > > So... Say libfoo is > blah blah blah i didnt read this e-mail, i imagine it's your normal stuff though, so i'm not missing much as i said, i'm pro-fixing TEXTRELs, not pro-preventing-packages-from-getting-into-stable-because-it-has-TEXTRELs -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Tue, Dec 13, 2005 at 07:59:02PM -0700, Jason Wever wrote: > On Wed, 14 Dec 2005 00:25:57 + > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > no idea what you mean by "override", but here's a crazy idea ... ask > > upstream to fix the issues. for example, we just reported executable > > stacks with the ut2004 game and Ryan of epicgames was so kind as to > > fix it up for us. some upstream peeps dont even know about these sort > > of things until you point them out. > > Not to redirect the thread, but can someone point me to stuff on > executable stacks (what they are and the background info on the > warnings in portage)? my gnu stack docs are actually complete: http://hardened.gentoo.org/gnu-stack.xml > If these are anywhere near critical, then I think a lot of us non-x86 > arch monkeys have a lot of work on our hands. gnu-stack tends to be broken for everyone, not just x86 or !x86 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 09:19:56AM +0100, Harald van D??k wrote: > LDFLAGS? Assuming you meant ASFLAGS, this doesn't affect C files, correct > would need rechecking of the assembly code on updates just as much as > patches which add .note.GNU-stack would, right? no you were supposed to send that patch upstream, i guess you didnt huh bad dev -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gee, wouldn't it be nice (security bugs)...
On Wed, Dec 14, 2005 at 06:00:21AM -0500, Michael Cummings wrote: > Gee, wouldn't it be nice for us lazy folks if the word [Security] (in > some common fashion) were included in the summary line of security > related bugs? this really should have been sent to the security mailing list and cc-ed the security team this has come up before on those lists, i just dont remember the outcome :P -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 03:27:54PM +0100, Harald van D??k wrote: > On Wed, Dec 14, 2005 at 01:43:28PM +0000, Mike Frysinger wrote: > > On Wed, Dec 14, 2005 at 09:19:56AM +0100, Harald van D??k wrote: > > > would need rechecking of the assembly code on updates just as much as > > > patches which add .note.GNU-stack would, right? > > > > no > > > > you were supposed to send that patch upstream, i guess you didnt huh > > In my first message I explained the reason for asking about these kinds > of patches: because your reason against them -- that they can't be sent > upstream -- didn't apply. there's a few problems with trying to get configure to detect whether the host assembler supports the --noexecstack option: - it's very easy to get the detection wrong and i'd bet money that anyone doing it for the first time would screw it up - it'll only fix the package if the host binutils are new enough ... this is becoming less of a problem every day, but it's still not uncommon - patching the code to use .note.GNU-stack would work regardless of the binutils version > So I guess this situation would be that I did > send a patch upstream, but it simply wasn't accepted yet. This can > happen with any patch, even those of your preferred kind. then you convince upstream that they're being stupid -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 10:27:19AM -0500, Chris Gianelloni wrote: > On Wed, 2005-12-14 at 00:25 +0000, Mike Frysinger wrote: > > On Tue, Dec 13, 2005 at 05:59:17PM -0600, Jory A. Pratt wrote: > > > Only problem I see with this is binary packages. We can not control > > > upstream binaries as everyone is aware of. So when does it become safe > > > to override stable packages that have texrel's and executable stacks? > > > > no idea what you mean by "override", but here's a crazy idea ... ask > > upstream to fix the issues. for example, we just reported executable > > stacks with the ut2004 game and Ryan of epicgames was so kind as to > > fix it up for us. some upstream peeps dont even know about these sort > > of things until you point them out. > > Let me take that back again. This is resolved on amd64, but not on x86. > There's 2 binaries. This also explains why I didn't see the error and > closed the bug, I'm on amd64, whereas the bug reporter is on x86. yeah, Ryan's one cool cat -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gee, wouldn't it be nice (security bugs)...
On Thu, Dec 15, 2005 at 02:37:54AM +0900, Chris White wrote: > er.. why not just do an advanced query for all bugs assigned / cc'ed to > [EMAIL PROTECTED] How that doesn't accomplish the same thing... didnt know e-mail clients were integrated with bugzilla oh, they're not, so it's still hard to pick out e-mails from your inbox which are security related when you're simply cc-ed -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] UPGRADE ANNOUNCEMENT bugs.gentoo.org
On Wed, Dec 14, 2005 at 06:28:04PM +0100, Jakub Moc wrote: > 14.12.2005, 18:12:05, Georgi Georgiev wrote: > > > And for the network challenged, output in local time: > > And for the bandwidth/time-challenged, who do not wish to waste their time > reading useless emails: > > :0: > * ^From:[EMAIL PROTECTED] > /dev/null s/[EMAIL PROTECTED]/[EMAIL PROTECTED]/ -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] mod_rewrite .htaccess support on dev.g.o ? (was: jforman touches himself)
On Thu, Dec 15, 2005 at 05:27:39AM +0900, Chris White wrote: > On Thursday 15 December 2005 04:30, Simon Stelling wrote: > > http://dev.gentoo.org/~chriswhite/flame.html > > Moved it: > > http://dev.gentoo.org/~chriswhite/docs/flame.html speaking of which, am i retarded, or does mod rewrite not work in .htaccess files on dev.g.o ? last time i tried, i got internal server errors which usually means that the feature has been disabled -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] December 15th Meeting Summary
this months meeting wasnt too eventful, kind of quiet ... on the agenda: - Marius: decision on multi-hash for Manifest1 there was a bit of hearsay about why the council was asked to review/decide on this issue since we werent able to locate any portage devs at the time of the meeting ... so our decision comes with a slight caveat. assuming the reasons our input was asked for was summarized in the e-mail originally sent by Marius [1], then we're for what we dubbed option (2.5.1). that is, the portage team should go ahead with portage 2.0.54 and include support for SHA256/RMD160 hashes on top of MD5 hashes. SHA1 should not be included as having both SHA256/SHA1 is pointless. further more, we hope this is just a hold over until Manifest2 is ironed out/approved/implemented/deployed. it was also noted that we should probably omit ChangeLog and metadata.xml files from the current Manifest schema as digesting them serves no real purpose. [1] http://article.gmane.org/gmane.linux.gentoo.devel/33434 - Council: portage signing shortly after our November meeting, a nice summary was posted by Robin Johnson that covered signing issues from top to bottom. as such, it was felt that trying to throw together a GLEP would not be beneficial. instead we will be adding a constant agenda item to future council meetings as to the status of portage signing issues to keep the project from slipping into obscurity again. full meeting log: http://www.gentoo.org/proj/en/council/meeting-logs/20051215.txt -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] problems crosscompiling libXt
On Sat, Dec 17, 2005 at 06:20:33PM -0500, David Thomas wrote: > Here is a fix for libXt, similar to the problems I had with libX11 > last week. I don't see an obvious way to patch the Makefile.am. > Please send comments. yeah, no good ... you need to add logic for a CC_FOR_BUILD which would then be used to compile the helper programs like makestrs -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: disallowing multiple votes per person in council meetings
On Thursday 15 December 2005 15:20, Ciaran McCreesh wrote: > one of the following two clauses: > > Each person at a council meeting may represent only one voting role. > > Or: > > A proxy must not be an existing council member, and any single person > > may not be a proxy for more than one person at any given meeting. i'm for the latter version > * It makes it harder for council members to all go "oops, can't make > it, so vapier is my proxy" at the last minute. well, i could proxy for three of them and SpanKY could proxy for the other three ... i bet we'd put on a good show > On the same subject, I'd also like to see the "meeting participants" > table updated to explicitly list proxies, for example in the form > "jaervosz (for koon)". i pointed out that we were already going to do this and it was done earlier this weekend ... however, i did "koon (proxied by jaervosz)" ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] problems crosscompiling libXt
On Saturday 17 December 2005 18:20, David Thomas wrote: > Here is a fix for libXt, similar to the problems I had with libX11 > last week. I don't see an obvious way to patch the Makefile.am. > Please send comments. you should startup a bug for this if one hasnt been already -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, Dec 19, 2005 at 06:37:16PM +0100, Marius Mauch wrote: > On Thu, 15 Dec 2005 22:47:21 -0500 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > there was a bit of hearsay about why the council was asked to > > review/decide on this issue since we werent able to locate any > > portage devs at the time of the meeting ... > > Well, it would help if the actual meeting date would be announced and > not pushed back without notice ;) we've taken steps with automating future announcements since this months meeting was a bit under-publicized > One thing solar has pointed out is that in countries with stupid laws > pycrypto violates some patents so currently we cannot ship it in stages > or binary packages (so I'm told, I'm neither a lawyer nor someone who > is affected by such laws). This is probably something releng and the > python herd have to deal with. this shouldnt be too much of an issue Lukasz: mind if i commit support for USE=bindist or you guys want a bug to track it ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, Dec 19, 2005 at 08:04:19PM +, Ciaran McCreesh wrote: > On Mon, 19 Dec 2005 11:44:24 -0800 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | I know some of you have done research on how gentoo-x86 converts over > | to other systems besides CVS such as SVN, arch, etc. But I can't find > | the info anywhere in my archives. > > As for Arch, I managed to find three different "FATAL ERROR!" bugs in > tla within the first five minutes of using it. Two of them were > reported and known, with no fix forthcoming. Plus, we don't use a > distributed development model so Arch doesn't really suit us... along those same lines, ive used monotone with a project or two and found it to be highly unstable and very incompatible across minor releases -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Mon, Dec 19, 2005 at 11:48:52PM +0200, Petteri R??ty wrote: > /usr/portage/profiles/use.desc:xml - Check/Support flag for XML library > (version 1) > > I think the xml use flag should be more generic. There are after all > other alternatives for xml support than dev-libs/libxml. Maybe something > like Adds xml support? then you'd have to deprecate the usage of xml2 is there any package which uses both xml and xml2 ? if not, i dont see why we cant condense the two down into one -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Tue, Dec 20, 2005 at 12:19:01AM +0200, Petteri R??ty wrote: > Mike Frysinger wrote: > > On Mon, Dec 19, 2005 at 11:48:52PM +0200, Petteri R??ty wrote: > > > >>/usr/portage/profiles/use.desc:xml - Check/Support flag for XML library > >>(version 1) > >> > >>I think the xml use flag should be more generic. There are after all > >>other alternatives for xml support than dev-libs/libxml. Maybe something > >>like Adds xml support? > > > > > > then you'd have to deprecate the usage of xml2 > > > > is there any package which uses both xml and xml2 ? if not, i dont see > > why we cant condense the two down into one > > [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e "xml[^2]" > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml xml2 debug > doc gtk" > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome nls" > net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp > xml xml2" > net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp xml > xml2" > net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp xml > xml2" > > Found a couple. then these will have to be reconciled first ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Mon, Dec 19, 2005 at 04:04:55PM -0700, Lares Moreau wrote: > On Tue, 2005-12-20 at 00:19 +0200, Petteri R?ty wrote: > > [EMAIL PROTECTED] ~/test/java $ qgrep -v IUSE | grep xml2 | grep -e > > "xml[^2]" > > dev-tcltk/tclxml/tclxml-3.0.ebuild: IUSE="expat threads xml2" > > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: IUSE="jpeg X xml xml2 debug > > doc gtk" > > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild: IUSE="ssl xml xml2 gnome nls" > > net-print/pykota/pykota-1.22_p1548.ebuild: IUSE="ldap postgres snmp xml > > xml2" > > net-print/pykota/pykota-1.23_p1869-r1.ebuild: IUSE="ldap postgres snmp > > xml xml2" > > net-print/pykota/pykota-1.23_p1869.ebuild: IUSE="ldap postgres snmp xml > > xml2" > > net-print/pykota/pykota-1.23_p1874.ebuild: IUSE="ldap postgres snmp xml > > xml2" > > > > Found a couple. > > [EMAIL PROTECTED] pykota # qgrep -v -e 'xml2\??' |egrep 'pykota|sitecopy| > libwmf' > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: xml2? ( !xml? > ( dev-libs/libxml2 ) ) > media-libs/libwmf/libwmf-0.2.8.3-r1.ebuild: xml? ( dev-libs/expat ) > net-misc/sitecopy/sitecopy-0.13.4-r2.ebuild:xml? ( dev-libs/libxml ) > net-print/pykota/pykota-1.22_p1548.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.22_p1548.ebuild: xml2? > ( dev-python/jaxml ) " > net-print/pykota/pykota-1.23_p1869-r1.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.23_p1869-r1.ebuild: xml2? > ( dev-python/jaxml ) " > net-print/pykota/pykota-1.23_p1869.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.23_p1869.ebuild: xml2? > ( dev-python/jaxml ) " > net-print/pykota/pykota-1.23_p1874.ebuild: xml? > ( dev-python/jaxml ) > net-print/pykota/pykota-1.23_p1874.ebuild: xml2? > ( dev-python/jaxml ) " > > pykote draws the same package, and doesn't compile anything, so I don't > think they are relavent good > sitecopy-0.13.4-r2 does IUSE both, But uses them to determine weather or > not to use XML1 || XML2. It doens't enable both. sitecopy maintainer should comment here ... > On the other hand libwmf-0.2.8.3-r1 warns you about using both. actually, this usage is sort of bogus ... the USE=xml should be changed to USE=expat > Could we have one XML flag and an xml.eclass to determine which XML > version is installed on a particular system. one XML USE flag yes, an xml.eclass no ... that's just useless cruft -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [SEMI-OFF-TOPIC] PSU for a Cobalt Qube 2
On Mon, Dec 19, 2005 at 10:51:08AM +, Gustavo Felisberto wrote: > 3- The pinout of the psu so i can hack another solution here's what mine says: AC ADAPTER ZVC36FS12 50-60Hz 12V 3.0A EOS Corp you might be able to google up something -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] baselayout-1.11.14 stabilization
since we have baselayout-1.12.x in ~arch, the new stable candidate (1.11.14) isnt getting much air time ... can people try upgrading to it and post any feedback they have with it ? it should mostly be a bugfix release over 1.11.13 since we arent doing any more real features for the 1.11.x branch ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.14 stabilization
On Wed, Dec 21, 2005 at 07:49:37AM -0500, Chris Gianelloni wrote: > On Tue, 2005-12-20 at 14:36 +0000, Mike Frysinger wrote: > > since we have baselayout-1.12.x in ~arch, the new stable candidate > > (1.11.14) isnt getting much air time ... can people try upgrading to > > it and post any feedback they have with it ? it should mostly be a > > bugfix release over 1.11.13 since we arent doing any more real features > > for the 1.11.x branch ... > > Does this preclude any bug fixes going into 1.11 that affect the > release? I have at least two that I would love to get resolved before > 2006.0's release if you're referring to the multilib issue for amd64/ppc64, then no, that is not in the ebuild yet ... talk to eradicator > and waiting for the eventual stabilization of 1.12 > isn't exactly the best plan for this. and almost certainly wont happen, not to mention i'm pretty sure both 1.11.x and 1.12.x are broken in the same regard -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.14 stabilization
On Wed, Dec 21, 2005 at 09:30:56AM -0500, Chris Gianelloni wrote: > On Wed, 2005-12-21 at 13:13 +, Roy Marples wrote: > > On Wednesday 21 December 2005 12:49, Chris Gianelloni wrote: > > > On Tue, 2005-12-20 at 14:36 +0000, Mike Frysinger wrote: > > > > since we have baselayout-1.12.x in ~arch, the new stable candidate > > > > (1.11.14) isnt getting much air time ... can people try upgrading to > > > > it and post any feedback they have with it ? it should mostly be a > > > > bugfix release over 1.11.13 since we arent doing any more real features > > > > for the 1.11.x branch ... > > > > > > Does this preclude any bug fixes going into 1.11 that affect the > > > release? I have at least two that I would love to get resolved before > > > 2006.0's release, and waiting for the eventual stabilization of 1.12 > > > isn't exactly the best plan for this. > > > > Got bug numbers? > > 57229 not an issue with baselayout, lvm code has been moved to the lvm ebuild > 99682 that bug is still waiting for feedback from you releng peeps :P -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2006 and ebuild headers
On Wed, Dec 21, 2005 at 09:33:14PM +0200, Petteri R??ty wrote: > What I don't remember is if we > set some kind of policy then, but best to put this issue on the table > well before New Year so that everyone will be aware of what to do when > the time comes. we did the policy is that you only update the copyright on files when you update them for other reasons echangelog will automatically do this -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Tcl/Tk correction
On Wed, Dec 21, 2005 at 11:36:43PM +0300, Vadim Konovalov wrote: > I've noticed wrong homepage specified for tclpython (shoud be > http://jfontain.free.fr/tclpython.htm ) use http://bugs.gentoo.org/ > Also, I want Perl module for Tcl/Tk interconnection to be available > within as ebuild. use http://bugs.gentoo.org/ -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] tcltk splitting [again]
came someone please remind me why we havent split the tcltk USE flag into tcl and tk ? wanting tcl support on a server makes sense, and doing something like 'tcltk? ( X? ( tk ) )' is just dumb -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tcltk splitting [again]
On Wed, Dec 21, 2005 at 11:24:10PM +0100, George Shapovalov wrote: > Um, I cannot remind why we did not split, because I remember (unless I am > hallucinating of course. That was like 2 years ago, or more..) that we > actually had them split and then they were joined.. For whatever it is > worth.. i cant say i ever remember them being sep ... afaik, they've always been one USE flag ... but viewcvs says that we had a "tcl" and a "tcltk" rather than a "tcl" and "tk" flag ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Tuesday 20 December 2005 02:55, Duncan wrote: > What about doing with xml what was done with gtk, when gtk2 was > deprecated? IOW, where both are possible, default to one or the other, > which ever one is merged, or choose one (preferably making it a > Gentoo-wide default, for consistency) if both or neither are merged. not really needed seeing as how very few (well pretty much no) packages offer both xml and xml2 support ive started a bug here for those who wish to follow progress: http://bugs.gentoo.org/show_bug.cgi?id=116346 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] another global use flag...
On Fri, Dec 23, 2005 at 02:03:39PM +, Marcus D. Hanwell wrote: > That is why I don't quite understand why Mozilla based browsers use the > mozsvg > use flag when there is already a global svg use flag available and if you > enable svg you can pretty much guarantee you will want it in mozilla too. maybe a bug ? 'mozsvg' has existed for much longer than 'svg' afaik -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing description for the xml global use flag
On Thu, Dec 22, 2005 at 10:58:03PM +, Stuart Herbert wrote: > On Mon, 2005-12-19 at 23:48 +0200, Petteri R??ty wrote: > > /usr/portage/profiles/use.desc:xml - Check/Support flag for XML library > > (version 1) > > > > I think the xml use flag should be more generic. There are after all > > other alternatives for xml support than dev-libs/libxml. Maybe something > > like Adds xml support? > > I can see where you're coming from, but I'm not sure it's worth the > potential disruption that this will cause our users. > > Unless I'm missing something, won't every user who has any form of > USE=xml, USE=-xml, USE=xml2, or USE=-xml2 in make.conf and packages.use > get a nasty surprise the next time they emerge -u world? > > I haven't seen any discussion taking this into account yet. i dont really see this being an issue ... i dont think anyone really has 'xml -xml2' or '-xml xml2' ... much more likely they have 'xml xml2' or '-xml -xml2' -mike -- gentoo-dev@gentoo.org mailing list
