Re: [gentoo-dev] On git and pushing official gentoo branches
2009/4/26 Gilles Dartiguelongue e...@gentoo.org: Well I'm more looking into giving upstream the possibility to pick what we've done by a single git cherry-pick or merge. format-patch works well, it's what I'm using to keep patches in sync with upstream changes but what I'm really looking for is a way to say to upstream look, that's where patches for your project are hold in gentoo land, come and pick everything you think is worth it (sure I can point to sources.gentoo.org but that's not what I'm looking for). you could also use sendemail to send them... or one of the other mailing options. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] gSoC add Multiple Repository support to sys-apps/portage
On Thu, Mar 26, 2009 at 1:59 PM, Timothy Redaelli dri...@gentoo.org wrote: Iirc portage can already sync from rsync, cvs and git I'm aware ;) but without patches that I've already implemented even this support is buggy and limited (and even those could probably be improved). the point though is not so much the 'protocols' as the ability to do it with more than 1 repository, which portage currently can't handle. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] gSoC add Multiple Repository support to sys-apps/portage
On Thu, Mar 26, 2009 at 1:59 PM, Timothy Redaelli dri...@gentoo.org wrote: Iirc portage can already sync from rsync, cvs and git I'm aware ;) but without patches that I've already implemented even this support is buggy and limited (and even those could probably be improved). the point though is not so much the 'protocols' as the ability to do it with more than 1 repository, which portage currently can't handle. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Gsoc Idea: EeePC Script/Build
On Wed, Mar 25, 2009 at 1:42 PM, Aaron Lebahn cplusplus...@gmail.com wrote: an EeePC. This will involve creating scripts and code that will preconfigure the Gentoo instalation to be optimized for the EeePC, and to contain all of the appropriate modules and configurations to enable all hardware on the EeePC. I own an EeePC 900 with which I wil be abe to test. I am uncertain if this or something similar has been done before, or if this is an appropriate Google SOC project. Please give feedback or questions, thankyou. wouldn't one problem with this be that different EeePC's have different hardware? I believe, that your's has an atom processor while older models have a celeron. being that I'm not a gentoo dev, and although I think the project is worthwhile, I personally don't see that it's a gsoc worthwhile, esp since gentoo doesn't really do it for anything else. tbh, would this take more than a week to do? I'm not overtly familliar with the EeePC but it doesn't seem that unless you were highly un-gentoo-ing it that this would be a long process, given that I believe the architecture is all x86.. (maybe x86_64?) -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Gsoc Idea: EeePC Script/Build
On Wed, Mar 25, 2009 at 5:22 PM, Aaron Lebahn cplusplus...@gmail.com wrote: The difference would be that that proposition is web-based. I propose either a locally built or pre-built installer. and the advantage over say... stage4's? -- Caleb Cushing http://xenoterracide.blogspot.com
[gentoo-dev] updating baselayout PERMS_PROTECT
so from what I can see there doesn't appear to be any 'official' way of adding new directories, updating perms and the like in baselayout. my thought is someone who does an emerge -aveD world's system should for the most part be reset to 'factory' defaults. of course this leads to the problem... what if the 'admin' explicitly changed the permissions... Maybe we should have something like PERMS_PROTECT (similar to config_protect). where portage won't update the permissions if file/directory is protected. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] timezone and other moving rc variables.
On Mon, Mar 16, 2009 at 2:46 AM, Ben de Groot yng...@gentoo.org wrote: As per http://www.gentoo.org/doc/en/openrc-migration.xml under the Clock heading. I know, reading documentation is an acquired taste... ;-) I've never seen this documentation before, didn't know it existed. maybe things like the timezone-data ebuild could refer to it in the 'info' message (the kernel used to do this with the kernel migration guide) -- Caleb Cushing http://xenoterracide.blogspot.com
[gentoo-dev] timezone and other moving rc variables.
* You have an invalid TIMEZONE setting in /etc/timezone * Your /etc/localtime has been reset to Factory; enjoy! * Updating /etc/localtime with /usr/share/zoneinfo/Factory cat /etc/timezone TIMEZONE=EST5EDT I can't figure out what this file wants. I've tried several settings and I don't seem to be able to get it right. (maybe a bug?) so maybe timezone-data should install the file with a default, and some examples. because updating documentation is always a good thing. It's getting hard to keep track of where things are moving to. like where I'm supposed to set things like EDITOR, and XSESSION with openrc moving everything around, could we please put these things in one place? /etc/env.d or /etc/conf.d? also could all the necessary files be created for us? I think this should apply to /etc/env.d/02locale as well. I don't see why this isn't created with some comments by default. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
On Fri, Mar 6, 2009 at 3:44 PM, Marijn Schouten (hkBst) hk...@gentoo.org wrote: Don't you get that? the janitor gets hit by a car and no ones around to clean the bathrooms. You can't fire him because of contract, his job has to be waiting for him when he gets back in 2 months. what do you do? the answer is you get someone else to do it. If you had really been prepared you already had 2 or more janitors. the answer is not to fire people, but not to be as reliant on single points of failure. if you make it more than 1 persons job then when 1 person can't do it there's another there to pick up the slack, who's just as competent. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
On Sat, Mar 7, 2009 at 6:06 AM, Rémi Cardona r...@gentoo.org wrote: While I really appreciate you comparing us to janitors, ... it's an analogy, get over it. I could have called you a secretary or a school teacher, or bus driver, or basically any other job where a replacement has to be found if the regular can't be around. maybe I should have called it 'custodial services expert' or some other 3 word title. So, I'll leave this bug open because I definitely don't want to start a flamewar over this, but do know that you've red-flagged yourself. thank you for that. I'm glad to know you've taken this personally. it means I really hit home. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Re: How to speed up maintenance and other Gentoo work?
On Sat, Mar 7, 2009 at 2:27 PM, Alec Warner anta...@gentoo.org wrote: People are working on the whole 'replace cvs with git' thing on the gentoo-scm list. I'm supposedly on that list and I haven't gotten a message all week? is it low traffic? or do I have a subscription/other problem. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] QA Overlay Layout support.
On Wed, Mar 4, 2009 at 8:52 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: One of the reasons we had to split the work in the 2 overlays was to move the live ebuilds to the experimental overlay so that casual users wouldn't be affected by them. if they're properly masked/keyworded why would 'casual' users be affected by them? -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
I've found that git's patches aren't really what we want in the case of bumping. For bug reports we usually ask for a patch against the last ebuild in the tree. Is there perhaps a way to make git do that automatically? well, git has copy detection, you can tell if a file is merely a copy of the previous (if git format-patch is done right) you can also just do a diff on it? you could probably put it in a hook. or write a script... or numerous other ways. once the work is done, getting any amount of varying diffs is easy. the problem with git right now, is all the things that gentoo does for cvs and rsync. git doesn't need as much manifesting, it doesn't need the cvs headers, or ChangeLog files, all this stuff just clutters things with git. but this is a 'right now' problem, that I'm working to solve, most of it leads right back to manifests. It's great that people are doing their own thing, but to get it into OUR tree it will need to be comitted to OUR tree by someone who has access to OUR tree. Patches are great, but commits are better. yes but your commit process is made more complicated by your tools. I for the most part require that the entire commit be ready to go. Your demands because of your feelings of entitlement are what are costing you respect. why do people keep telling me what I feel? anyone else ever notice feelings don't convey well over text. Yes, it's extremely frowned upon to step on another developers toes; Gentoo is not a one-man show. Would you like ME to stomp all over your tree? Didn't think so. that depends on what you mean by 'stomp' if by stomp you mean fix problems for users, stomp away. if by stomp you mean break stuff, then no. I don't care if you change something I changed if it's better, it's better. Just so we're clear. I really hope you change your attitude and take Peter Alfredsen (loki_val) up on his generous offer. and my attitude is? what is it that you think I think? I may take him up. but I'm also considering the possible conflict of interest, as well as the additional time requirement. I hope you understand. even if I do I have a commitment to what I've already started. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
On Fri, Mar 6, 2009 at 7:12 AM, Marijn Schouten (hkBst) hk...@gentoo.org wrote: right now you are the kind of person that thinks being a volunteer is a privilege and not a responsibility. You think that because you don't get paid that you don't have to do it. I assure you that if you look at most non foss volunteer jobs you either have to do your job or quit. it is the same in open source. perhaps I'm judging you wrongly. -- https://bugs.gentoo.org/show_bug.cgi?id=260582#c6 It seems like you want to tell us how to do our jobs. It seems like you think you have the right to tell us what to do. Now, I'm happy to be wrong about those views, but that's what it looks like to me. and what's your perspective? who gets to tell you what to do? it's not that I get to. but what I said I do believe, is common among foss developers. they don't take volunteering as a responsibility. They don't think of it as their other job. I think they should. It's also a pet peeve of mine so I kinda flew off the handle. question is do you understand what I've written? given your statement below on my blogpost on what you think I've implied (I'll respond directly) you might be wrong about this to. this is also the reason that I have to carefully consider being a gentoo dev. if I do, I have a responsibility to the users of my packages. The point is that you don't know whether someone else has a good judgement of better. People that have been taking care of certain parts of the tree may just know something you don't. This is why we encourage people to talk to maintainers when they touch their packages but also encourage maintainers not to feel too possessive. sometimes it's just a difference of opinion. it depends on your opinion of what's right and what's better. but sometimes even the smartest person is wrong. I do not claim to be always right, and I'm most certainly not. but I don't think I'm wrong when I say it's wrong not to version bump a package when all it takes is the copy of a previous ebuild. I don't think I'm wrong when a bug is put on hold due to other bugs, (for 6+ months) but the maintainer never answers what other bugs. On your blog[1] you imply that if you decide to not, that you wouldn't be able to to talk to people to understand something. I just want to stress that this is not so. Many of us are available on #gentoo-dev-help and this mailing list for technical questions. no that's not what I'm saying at all. I'm saying that it's easier to get help if you got 1 or more specific mentor's to help you. asking for help on irc, forums, mailing lists, is often a crap shoot at best. given I get help more often than not. but sometimes you still don't get any (for various reasons, don't know, don't care, not around, don't understand). You read an implication that I didn't actually say. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
On Fri, Mar 6, 2009 at 9:51 AM, Marijn Schouten (hkBst) hk...@gentoo.org wrote: Why do you think they should? you must have not read what I said on that bugtracker because I'm thought I was pretty clear, that when you work as a volunteer it's still a job. Don't believe me, go volunteer for community service or something. Then try saying I don't have to I'm a volunteer. They might just ask you to leave on that note. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Re: How to speed up maintenance and other Gentoo work?
On Wed, Mar 4, 2009 at 7:50 AM, Nicolas Sebrecht nicolas.s-...@laposte.net wrote: Give a git access to the developpers beside the current CVS ? or replace cvs with git... oh and you can replace rsync too... because git is faster there as well. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
Bugzilla is a tool for developers to track progress, not for third-party distributions to track progress. You've forked the tree. That's fine. The license allows that. But it doesn't obligate us to adapt our tools to fit your purpose. I've done lots of version bump bugs over the years. my reasons for doing so may have changed. But the general process has not. Does it matter if I've forked? doesn't the package still need an update? Your behavior on bug 260582 was clearly unacceptable. You seem to think that we owe you something. Please re-examine your premises. Donnie already told you he was working on it. Our job is not to support your distribution. It is to make the best distro for ourselves. In the case of xorg-server, that means getting something into the tree that works. A masked ebuild will in this case be more bother than it's worth because the mask would have to encompass a bunch of other packages. Which leads me on to the next paragraph... this and all the cases given are examples, and perhaps my behavior was unacceptable. But I think the response to my bug was too. No gentoo doesn't owe me or regen2, a thing. It might, however, owe users something. I agree on committing ebuilds that work, that doesn't mean I don't have the right to open a bug and watch for progress reports. In many cases that's true, but on average, the QA of the tree is much better than overlays. I couldn't say... I suppose I agree yes on most overlays, but a few are supposed to be more 'exceptional'. the biggest problem is the bugs that result between ebuilds in the tree and those of overlays. like one I filed on virtual/perl-Mime-Base64. or like how inkscape won't build against 5.10, except with patches already in bugzilla, but both cases seemed to be one of 'perl 5.10 isn't in the tree so we won't fix' I think they should put it in before 5.10 is in the tree. put that's just me. We Need Git. It would really ease the workflow of accepting user contributions if users could just set up their own overlay and sent me an email asking to merge their changesets. git's great. but I've actually found 'merging' changesets to be a bad idea from people. It can lead to some really sloppy commits, and merging is a less stringent review than cherry-picking patches. You could have made thousands of commits already, fixing a substantial amount of the problems you've raised. thousands seem like a high number. I think I've been pushing an average one 1 patch per day since january to the tree (my tree). *laughing* I'm still the #1 contributor of git patches to funtoo. This isn't a quick fix. You'll have to work with people and that can sometimes be frustrating. I already have to 'work' with these people, the difference would be what? how much respect I get? in gentoo land having @gentoo.org seems to mean something... if you don't have that, you seem to auto-magically get less respect, than you would if you did have it. But you'll get to be part of the development process and you'll get to work with the things you care about. you mean I'll be part of 'a' development process and work on some of the things I care about. Obviously stepping on other developers toes seems to be a taboo. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
On Wed, Mar 4, 2009 at 8:59 AM, Thomas Anderson gentoofa...@gentoo.org wrote: eh, that's the problem with ~arch. ~amd64 keywords aren't added for every new version; keywords are carried over from the previous version. Having to test each new version of a package before it receiving a keyword puts far too much stress on the arch teams I'm not talking about testing before... I was talking about removing it after. I understand that not everything can always be tested before. But when it's found to be broken, there shouldn't have been an argument about the kewords removal in lieu of a proper fix. -- Caleb Cushing http://xenoterracide.blogspot.com
[gentoo-dev] Regen2 ( was QA Overlay Layout support )
I'd like to start with, I'm not trying to stir up trouble but since questions were asked i'll answer them. If you think neither should exist why do you have an opinion about this at all? I merged the java-overlay into regen2 a couple of weeks ago. as of right now I've no plans to support java-experimental. I'm fine with overlays so long as working ebuilds spend no more than a few weeks in them. I have my own development branch and half the stuff that's in there that isn't in the main tree doesn't work. Things like perl 5.10 have been rotting in an overlay for a year. Funtoo ( under my direction ) and Regen2 have had it ~arch for over a month now. We found one bug post release thus far. I filed a bug on xorg-server 1.6.0 not being in tree. It was resolved fixed (in overlay) (which another bug clearly states it has amd64 build issues). since when has (in overlay) been an acceptable solution to a missing package? I said it before, the reason I like gentoo* distro's is I don't have to find the repository to get the latest package, that's just a pain, in ubuntu, in opensuse, in fedora... etc. But no more... officially supported huge overlays have ruined this. on the topic of sunrise, I approve of sunrise to a degree. I like the non-reviewed half, but once they're reviewed they should be put in tree. Isn't it true that some of those packages never get maintainers? What makes you think that overlays aren't for developers, aspiring developers and interested users where they are working on stuff? users don't know how to hack. the very definition of user says that, imo. There are developers, admins, and users. admins don't want overlays, they are supposed to be unstable. users can't hack, so what do they care. the problem is, an overlay has become a repo, I'm not sure that it was originally intended for that. It is desirable IMO that all such people can easily be given full access to muck around and learn. this does not mean officially supported overlays. You obviously won't commit just anything to an officially supported overlay which suggests that you don't allow 'mucking around'. Further, overlays are good places to put ebuilds for software that is more experimental than what's expected for ~arch. That includes live ebuilds. In the end, overlays have a (far) lower level of guaranteed quality than the main tree, for their ebuilds because ~arch is supposed to work? take open bug on wine-1.1.16 it doesn't build on amd64 and yet it's ~amd64. how about that nam ebuild that has invalid bash that I mentioned? that's some quality work there. The point is the tree is no better or worse than the overlays in many cases. might even argue that Funtoo is one big overlay. When your own ability to contribute directly depends on an overlay, then why are you arguing against other people's overlays? perhaps this is the real problem gentoo's primary way to accept user contributions is via overlays. I disagree with the calling of Funtoo as one big overlay, it's a replacement tree, and it provides everything needed within that tree, as does regen2. overlays however rely on an external tree, and now you've been discussing making them rely on other overlays. Please point me to the people willing and having the time to maintain those 100 new ebuilds in the main tree. given all the problems with the in tree ebuilds that aren't properly maintained, I see no difference. Regen2, is attempting to fix these problems, and more. I do try to get my fixes back upstream here, but more often than not the bug languishes. I don't think Gentoo is bad, but I do think it's taken a wrong turn. But I suppose that these things are problems are simply my opinion. I've probably already offended a large share of people on this list, now lets see if I can offend a few more by soliciting. I consider Regen2 ready for use, but pre-release since I have yet to roll ISO's and tarballs. Anyone who wants to help is welcome, be you current, former or aspiring developer. More info at http://regen2.org I will not discuss regen2 further on this list as I feel this is not really the place, but I was asked. I am willing to discuss overlays further, but I'm not sure I really have more to say. I suppose the last thing would be back in the day I got everything from the tree, if I wanted, needed something else I downloaded an individual ebuild, and put it in /my/ local overlay. I didn't download a bunch of incomplete mini-trees using a tool. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] bash-4.0-r1 for ~arch
On Mon, Mar 2, 2009 at 10:56 PM, Donnie Berkholz dberkh...@gentoo.org wrote:
Actually seems like quite a few of the bash-completion scripts have
issues with 4.0 ... might want to just run through those.
nam-1.11.ebuild has the same error. repoman can't source it.
/mnt/sda8/portdev/tree/regen2/net-analyzer/nam/nam-1.11.ebuild: line
36: unexpected EOF while looking for matching `)'
/mnt/sda8/portdev/tree/regen2/net-analyzer/nam/nam-1.11.ebuild: line
75: syntax error: unexpected end of file
*
* ERROR: net-analyzer/nam-1.11 failed.
* Call stack:
* ebuild.sh, line 1881: Called die
* The specific snippet of code:
* source ${EBUILD} || die error sourcing ebuild
* The die message:
* error sourcing ebuild
*
* If you need support, post the topmost build error, and the call
stack if relevant.
*
!!! getFetchMap(): aux_get() error reading net-analyzer/nam-1.11;
aborting.
Unable to generate manifest.
out of all the ebuilds in the tree... it seems to be the only one with
a problem given that -r1 doesn't seem to have the issue removing it
sounds like a good idea.
--
Caleb Cushing
http://xenoterracide.blogspot.com
Re: [gentoo-dev] bash-4.0-r1 for ~arch
On Tue, Mar 3, 2009 at 1:39 AM, Mike Frysinger vap...@gentoo.org wrote: look closely and you'll see it's simply wrong. it's a bug if older versions of bash didnt reject it. they didn't. given it's the one ebuild that failed to source by emerge --regen in the whole tree and therefore failed reverse-transfer, further investigation seems like a waste of time considering nam-1.11-r1 sources fine. no idea what the code is trying to do with: $(#i) a bug should be filed if one isnt already I haven't, I suppose I could. I still suggest just removing it. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] QA Overlay Layout support.
Are we to say that we shouldn't allow tools to have support for this. I think that it is a nature progression that if we are to allow overlays to extend the portage tree that we should allow overlays to extend other overlays. I probably shouldn't butt in... first, no I don't want you to merge java-overlay and java-experimental, that's a bad idea (well at least for me) second. I generally think anything beyond a personal overlay is crap. All these overlays like sunrise, java-overlay, and on and on... basically official, overlays that have qa and are pretty stable. are crap. they should be in the tree. an overlay for developers is fine, you know. where you are working on stuff... stuff that someone who wouldn't want to hack on it wouldn't want, because it's too broken. but one of the few good things about gentoo, in relation to other distro's, 1 tree no repos, continues to fall further and further apart. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Tue, Feb 24, 2009 at 5:21 PM, Petteri Räty betelge...@gentoo.org wrote: My notes so far: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository c) .ebuild in current directory - needs one year wait I don't see the point of some of these... a shorter extension would be nice but not really necessary. .eapi.ebuild so like .2.ebuild 'cause that'd work great? smith-1.3.6.2.ebuild better yet vanilla-sources-2.6.28.2.2.ebuild yeah I can see that working out... no it wouldn't or maybe smith-1.3.6.eapi-2.ebuild just too long here's an idea, perhaps not a great one... but perhaps it'll make someone else think... how about this on the first line # eapi-2 and instead of sourcing it, have portage match it with a regex first, figure out the eapi, then source it. I don't know if I really like like what I'm proposing, but I don't see anything else that looks good. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] working on mysql-community 5.0.77 - mysql-extras
On Fri, Feb 27, 2009 at 2:01 AM, Robin H. Johnson robb...@gentoo.org wrote: Yes. There is a well defined order, you can get it from their SRPM specfile. Also check to see which patches it deliberately DOESN'T apply. Percona 5.0.75-b12 skipped the binlog-mirroring patch EG. http://www.percona.com/mysql/5.0.77-b13/patches/ found their patches there, I don't see any SRPM (source rpm?) on their download page. patch documentation doesn't seem to imply an order either. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] working on mysql-community 5.0.77 - mysql-extras
I went ahead and use the order you used previously all the patches apply, but it still doesn't build. 86_64-pc-linux-gnu-g++ -DEMBEDDED_LIBRARY -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME=\/usr\ -DDATADIR=\/var/lib/mysql\ -DSHAREDIR=\/usr/share/mysql\ -I. -I../include -I../innobase/include -I../innobase/include -I../include -I../include -I../sql -I../sql -I../sql/examples -I../regex -DDBUG_OFF -O2 -pipe -DHAVE_ERRNO_AS_DEFINE=1 -fno-exceptions -fno-strict-aliasing -felide-constructors -fno-rtti -fno-implicit-templates -fno-implicit-templates -fno-exceptions -fno-rtti -MT field_conv.o -MD -MP -MF .deps/field_conv.Tpo -c -o field_conv.o field_conv.cc In file included from lib_sql.cc:34: ../sql/mysqld.cc: In function ‘int init_server_components()’: ../sql/mysqld.cc:3436: error: ‘make_master_open_index’ was not declared in this scope ../sql/mysqld.cc:3488: error: ‘make_master’ was not declared in this scope make[3]: *** [lib_sql.o] Error 1 make[3]: *** Waiting for unfinished jobs mv -f .deps/derror.Tpo .deps/derror.Po mv -f .deps/field_conv.Tpo .deps/field_conv.Po mv -f .deps/field.Tpo .deps/field.Po make[3]: Leaving directory `/mnt/sda8/tmp/portage/dev-db/mysql-community-5.0.77/work/mysql/libmysqld' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/mnt/sda8/tmp/portage/dev-db/mysql-community-5.0.77/work/mysql/libmysqld' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt/sda8/tmp/portage/dev-db/mysql-community-5.0.77/work/mysql' make: *** [all] Error 2 I'm going to try attaching the git patch to the version bump bug (send-email won't handle it ) -- Caleb Cushing http://xenoterracide.blogspot.com
[gentoo-dev] working on mysql-community 5.0.77 - mysql-extras
this is semi-targeted @ robbat2 So I've been working on getting this ebuild working... here's what I know * 1001_all_show_patches-percona-5.0.75-b12.patch ... [ ok ] all patches before this work and mysql builds --- these are the only later patches that will cleanly apply * 1005_all_innodb_io_patches-percona-5.0.75-b12.patch ... [ ok ] * 1007_all_mysqld_safe_syslog-percona-5.0.75-b12.patch ... [ ok ] * 1008_all_innodb_locks_held-percona-5.0.75-b12.patch ... [ ok ] * 1010_all_innodb_show_hashed_memory-percona-5.0.75-b12.patch ... [ ok ] * 1011_all_innodb_check_fragmentation-percona-5.0.75-b12.patch ... [ ok ] * 1013_all_innodb_fsync_source-percona-5.0.75-b12.patch ... [ ok ] * 1101_all_innodb_rw_lock-percona-5.0.75-b12.patch ... [ ok ] but with these patches mysql fails to build. srv0srv.c: In function ‘srv_printf_innodb_monitor’: srv0srv.c:1763: error: ‘buf_pool_t’ has no member named ‘io_counter_heap’ srv0srv.c:1764: error: ‘buf_pool_t’ has no member named ‘io_counter_heap’ srv0srv.c:1817: error: ‘buf_pool_t’ has no member named ‘io_counter_hash’ srv0srv.c:1818: error: ‘buf_pool_t’ has no member named ‘io_counter_hash’ srv0srv.c:1820: error: ‘buf_pool_t’ has no member named ‘io_counter_hash’ srv0srv.c:1821: error: ‘buf_pool_t’ has no member named ‘io_counter_hash’ I just thought I'd post you on the fact that I'm working on it, and if anyone wants to help get the latest 5.0 mysql working... the process is a bit of a pita. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] http://bugs.gentoo.org/show_bug.cgi?id=232084
fyi my email client doesn't recognize urls in the subject line, don't know about anyone elses... but it'd be nice to click the link to the bug, and you know have some clue what this is about without reading the bug (e.g. a useful subject line). /endrant sorry I can't be of any further help here. On Tue, Feb 24, 2009 at 12:57 AM, Andrew D Kirch trel...@trelane.net wrote: Thanks for the help. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]
On Jan 20, 2008 8:43 AM, Richard Freeman [EMAIL PROTECTED] wrote: Stefan de Konink wrote: ..very offtopic but how are you all compiling stuff like firefox on a ram disk. Or is 8GB of ram very cheap suddenly? not to mention, last time I checked open office only required ~2GB of space to compile and it takes more than firefox. Most apps can be done in less than 512MB -- Caleb Cushing I currently only check my email once or twice a week, due to lack of internet in home. I apologize for the inconvenience
Re: [gentoo-dev] Re: Suggestion: INVALID - NOCHANGE in bugzilla
a semi on topic thought. could bugzilla be changed so that the default search includes bugs in all status. instead of just open bugs. I know sometimes I'll miss closed bugs because I'll forget to do an advanced search. -- Caleb Cushing
Re: [gentoo-dev] Re: Distrowatch
Perhaps they're more interested in generating ad revenue from whipped-up scandals... or maybe they have a point. distrowatch hpd ranking show's us down from a few years ago we were 7 in '04 9 '05 10 '06 11-12 '07 right now were 12 going up probably from all the sites saying negative things. funny sabayon a gentoo fork and overlay is in 8. I know these statistics aren't 100% accurate (given how they're generated) but maybe they mean something.
Re: [gentoo-dev] Why I don't think the CoC is a good idea
I have no idea if it's possible but if a topic is deemed to be off topic then can any further replies with that subject be forwarded automatically to another address like gentoo-dev-offtopic so they dont go to gentoo-dev? I believe you can change the destination based on subject with an mta. the question is what does implementing this entail? and being that a subject might be re-used in a completely unrelated (to the original topic) or be put back on topic how do you decide when to remove the forward.
Re: [gentoo-dev] Gentoo's problems
What on earth is going to be a major visible improvement to a command line based package manager that any average Gentoo user is going to realise? The average user probably only uses a few commands: emerge -u/p/a/v/--sync/package/world/system and then use package.keywords/mask/unmask so there are really no fundamental differences that the average user will notice How about the speed of search's? the speed of resolving dependancy's? how about the speed that it takes to calculate a dependancy listing after you've already done it once? portage is SLOW. how about getting it to the point where it could be made to incorporate a graphical frontend if wanted. how about providing me a list of packages that are masked instead of making me read and unmask them one at a time.
[gentoo-dev] NTP and DST problem
if I'm using a pre-fix timezone file and using ntp will it correct my machine to the correct time? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] forwarding a video
interesting video. I think many could learn from this I know I did. On 3/5/07, Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: no, i'm not directing this at any one person as i dont believe singling out any one person addresses anything in our case a video sent to out by a good mate http://video.google.com/videoplay?docid=-4216011961522818645 -mike what a nice flash website, Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6/x9p/VmCx0OL2wRAjV9AJ9c1OgLwocywRO4OeMYqaVjMMBTmQCePS3F YvCSh58axX4tl0O8JSOX4YE= =J5G2 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Little respect towards Daniel please
I wish you guys would just let the forum moderators moderate this mailing list. You'd soon see why the gentoo forums are the envy of the support world. I agree. I also agree with temporary ban's to reduce flame wars. people need to cool down sometimes. ---concerned gentoo user. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Little respect towards Daniel please
these are where warnings and apologies come in. plus I think only repeated behavior should result in permanent removal. On 3/5/07, Stephen Bennett [EMAIL PROTECTED] wrote: On Mon, 5 Mar 2007 23:07:58 +0100 [EMAIL PROTECTED] wrote: 1. Anyone who is impolite get's kicked off. Who defines 'impolite'? It's a cultural thing, and given that we have developers and users from all over the world, we span a lot of vastly different cultures. 2. Anyone who repeatedly and seemingly on purpose tries to harm the discussion will be kicked off. And how do you judge whether someone is deliberately trying to harm the discussion or is just being careless with his wording or generally misguided? -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
I personnally would like to see stage tarballs updated more frequently if an arch receives a major update in system, like gcc or glibc, even if this is only an r patch because these are a pain to install, and by update I mean something new goes stable. Such releases are infrequent, but make it painful when doing a new install because you know that you have to rebuild world from the start. On 3/1/07, Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Gaffney wrote: Also, what's the point? Everything you use to install from the minimal is fetched from the internet. The only thing that an updated minimal would give us is a slightly more hardware support during the install. This slightly more hardware support is almost always what new boxen need. Of course people can install Gentoo from another more up to date other distro, but wouldn't it be better if that were optional and not mandatory? That if people have new hardware which is not supported by their own distro, that they can pop in the latest gentoo cd and know that if there is any distro whose install cd supports their hardware, that gentoo will too? There would also be many more chances to fix things, since these images would be relatiely short lived. Since each image would be more similar than the previous one than our current 6 months apart releases are to eachother, testing could be spread out more. And our users would get more chances to help us test. Releng might not have to take a snapshot and try to stable it a la debian. Instead all developers could work together to fix bugs in stable found by users testing the install cd. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5t+5p/VmCx0OL2wRAnoBAJ93c8wOmeVYVtDuLwVO5Qwly9sNogCfbPON 7Leo1TTCqecCdo3sFJ0huRY= =tcD4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Timezone /etc/conf.d/clock
I see a timezone variable was added. good idea! how is it implemented exactly? seeing as I have a symlink in /etc/localtime what will this change if I set it? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timezone /etc/conf.d/clock
which most probably aren't since that was changed in the handbook (wonders why it was). On 2/15/07, Roy Marples [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007 23:16:18 +1030 Raymond Lewis Rebbeck [EMAIL PROTECTED] wrote: On Thursday, 15 February 2007 23:11, Caleb Cushing wrote: I see a timezone variable was added. good idea! how is it implemented exactly? seeing as I have a symlink in /etc/localtime what will this change if I set it? AFAIK it currently does nothing and will be used in the future. It's used by the timezone-data ebuild to update /etc/localtime if it's not a symlink :) Thanks Roy -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timezone /etc/conf.d/clock
never thought of that. thx for the info. On 2/15/07, Anders Bruun Olsen [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2007 at 08:01:11AM -0500, Caleb Cushing wrote: which most probably aren't since that was changed in the handbook (wonders why it was). It might have something to do with the fact that FHS specifies that /usr does not have to be on the root partition and thus using a symlink in /etc to somewhere in /usr is bad because most of the stuff in /etc is needed during boot, before other partitions are mounted. Moving away from using a symlink for localtime is therefore a step in the right direction for FHS compliance. -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=getsearch=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Stricter --newuse settings
I know that newuse is stricter now. but do my packages really have to want to rebuild because a flag was hard masked. e.g. arts when I had -arts in my make.conf already? seems like it's a little too strict. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Versioning the tree
they could pull the more current ebuilds and put them in an overlay. also correct me if I'm wrong isn't it possible only to sync certain parts of the tree using excludes. maybe some additional functionality saying only sync package X for updates. On 11/28/06, James Potts [EMAIL PROTECTED] wrote: On 11/28/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Mon, 2006-11-27 at 16:18 +0100, Kevin F. Quinn wrote: One method could be to snapshot all package versions at the time that Release Engineering make a release, building a package.mask file out of it masking out all packages of higher revisions (i.e. having 'CPVR' entry for every package in the tree in stable, and 'CPVR' if no versions are stable). It would be infinitely easier to create a tree just for this. Then, rather than back-port security fixes, this list would be updated with security-fixed version numbers, along with minimum required updates to dependent packages. The lists could be stored in the tree; for example as profiles/default-linux/x86/stable.mask. This is essentially the idea that my release tree uses, except the tree itself is completely stripped down to stable packages. I have a script which already does several things: #1. grabs best_visible for stable on each arch #2. repeat for each SLOT #3. purge unnecessary files from FILESDIR #4. strip to only stable profiles from profiles.desc #5. purge unnecessary USE from use.local.desc and use.desc #6. strip unused eclasses #7. regenerate Manifest (via ebuild $foo digest) I had also planned on it doing the following, but they haven't been implemented just yet: - strip all USE flags that aren't used from use.mask (per-profile) - strip all packages that aren't available from package.mask (per-profile) What this gives us is a *much* smaller tree, as it only includes stable packages/versions. Obviously maintaining that list is some work; predominantly watching the announcements from the security team and fixing up dependencies, and masking out new packages (for what that's worth). It could be regenerated on some or all releases, or perhaps on a yearly basis. It would also mean that versions listed there cannot be removed from the tree (until they're bumped in the list). Well, the simpler approach was to simply copy over the newer, secure ebuilds, and any required dependencies, into the release tree. There'd be no need to update mask files and such this way. It would also be generated with the releases, automatically. Some of that maintenance could be tool-assisted; in particular masking new packages and finding the minimum required bumps to support a package that was bumped for a security fix. People who want to use it could then just soft-link from /etc/portage/package.mask to that list. It's just a suggestion - I'm not prepared to do the work ;) However it might be a simple but effective method to help people maintain secure but relatively stable systems, without having to upgrade umpteen packages a week. Well, I am willing, and have been doing, some of the work. The one disadvantage to my design is it needs infra. It needs it's own repository and rsync. Basically, it makes the system act a bit more like some other development models. We end up with the following: rsync://rsync.gentoo.org/gentoo-portage (this is equivalent to -current) rsync://rsync.gentoo.org/2007.0-release (this is the release tree) Now, the release trees are non-moving. The 2007.0-release tree is *always* the 2007.0-release tree for as long as we decide to support it. Likely, this support period would begin as a single release and get extended as volunteers came around to support it. New releases get their own tree. I also started writing a tool to upgrade the distribution. The tool reads pre and post scripts for the upgrade, and performs the necessary steps. Basically, a user can dist-upgrade 2007.1 and the system would: - switch to the 2007.1 tree and emerge --sync - perform all pre steps from 2007.1 - update world + revdep-rebuild + whatever else is necessary - perform all post steps With this, there would be a special version called current which would put the user on the gentoo-portage tree, AKA the tree we all know and love/loathe. Release trees wouldn't have arch and ~arch as everything would be stable there. Testing would be done in the main tree. This, in essence, gives us testing, release candidate and stable environments, with the release trees being stable, and the current tree becoming test/release candidate. Anything marked stable in the current tree would be a candidate for stable in the next release tree. Users who want to use the current portage tree get what they want. Users who want a more stable tree get what they want. Basically, everyone (hopefully) is happy, or at least as happy as we can feasibly make them. This looks good on the surface, Chris, but what
Re: [gentoo-dev] firefox-2.0
I wouldn't do it until mplayerplug-in works on it. I just realized it doesn't, last night. lot of people would probably be upset if it were stabilized. but they couldn't watch movies. On 10/29/06, Josh Saddler [EMAIL PROTECTED] wrote: Michal Kurgan wrote: Hello! Recently new firefox-2.0 was released. I (and probably many other users) am interested when this new version would be unmasked and stabilized. If there are any problems, what are they and what to expect if i would force installation now? Is there any roadmap or timeline for stabilization already? Thanks in advance for any answers. There's no need to rush stabilization; being overly hasty leads to broken systems. If you want it, it's in ~arch, so go get it. Our own documentation gives a guideline of 1 month without outstanding problems/open bugs. A quick search for firefox 2.0 in Bugzilla shows a few open bugs: http://tinyurl.com/yjoy3w -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: firefox-2.0
I'm using the -bin version and it seems to be working fine. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Global USE flags (Was: mplayer global use flag)
cairo and openexr, good idea, AFAIK. udev has come up before but from that discussion, the flag means slightly different things in some cases. Keeping it local allows individual per-pkg descriptions, so where it means something different, the description can say so. In both meanings, udev defaulting to on remained best, but with the slightly different meanings... There was some discussion about modifying things or changing the flag where it meant something else, but I don't know what came of that. maybe it would be a lot of work. to even develop the tools. but it would be nice if a global use flag could have a detailed option. example. euse -i mplayer [+ C ] mplayer - Enable mplayer support for playback or encoding is what we currently get. add a -d option for --descriptive euse -id mplayer could show something like [+ C ] mplayer - Enable mplayer support for playback or encoding media-video/kmplayer - adds the ability to play back media using the mplayer engine or maybe something better... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Global USE flags (Was: mplayer global use flag)
And that's the problem - the user doesn't know what benefit will it bring her to use or not use a global USE flag for this particular package. yeah and it would be really nice to know these. I just thought of another useful feature. a flag for emerge that assumes --verbose but defines what the use flag's do. maybe we could have one similar to lspci? where -vv is more verbose that just -v. thx Mart for giving a better example than me. because I couldn't come up with a good one at the time. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
reporting additions of new programs aren't feasible? or are you referring to version updates and package bumps and such -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: games-fps/quake3-tremulous
yummy I want some. is it going to be stuffed? On 10/23/06, Chris Gianelloni [EMAIL PROTECTED] wrote: I'm masking games-fps/quake3-tremulous for removal. There's really no point in having it now that games-fps/tremulous is in the tree as a standalone version of the game. I figure I'll make this a Thanksgiving day surprise when I cut its head off with an axe and baste it before cooking it in the oven for a few hours. Speak now, or forever hold your peace. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 and ia64 architecture
But as i consider, it was ahead of it's time. although I've never used the Itanium. I agree it was ahead of it's time. nothing when it was released could run on it (for the most part). which is why athlon64 made it big it was backwards compatable. if OS's ever go to 64-bit it may come back. I'm not sure why apple when backwards instead of emulating or using select 32-bit programs. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resurrecting Project Dolphin
Hmm.. what about a minimal-media like system which could exploit unionfs and provide similar functionality to DSL (Damn Small Linux)? I was working on livecd's a few months ago. DSL turned unionfs off by default do to buginess. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.1 is Stable
I was running evdev under Xorg 7.0 and 7.1 for my mouse without problems. It works if you use it the way they intend it to use it. Read the man page. Otherwise yea it will crash. I used it under 7.0 fine but when I upgraded to 7.1 it started causing xorg to crash on startup same configuration. I'll try it again, maybe this weekend. I confirmed it was evdev removing it's module from the xorg.conf fixed the issue. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.1 is Stable
is evdev (for 7.1) stable now? and by stable I mean can I use it without it crashing xorg? I should probably test this because I don't recall it getting updated which means it is still broken. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
don't forget the gentoo-catalyst@lists.gentoo.org if you want I can put together some spec files that would build a universal cd for you. I can understand chris's position. but it would be nice if he would consider the development of a script for the livecd that could extract the stage4 on it and include documentation in the handbook on how to do it. because as is the installers don't allow for enough flexibility. I personally would like to know who decided to put bottom and I think top partition size limits in the installer. the limits should have been dictated by the filesystem limits themselves. my system my choice. another option might be a skip section of the installer. that way we can on do the stage4 part, and forget the rest if we want. would any of this be such a hard and impossible thing for releng to do and support? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
partition limits are decided by the size of the drive and the other partitions on it. really that seems impossible. GLI told me I couldn't have a boot partion smaller than ~50MB it complained about it. and I think I remember it complaining less because I was able to continue ... about having 140GB /home partition it only wanted to make a 20GB partition. but it absolutely would not do 32MB boot partion I have. it was like giving me a negative number, I assumed these are features not bugs. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
As for the 20GB partition, I have no idea. Perhaps that's a limit imposed by libparted, but it's not a limit that *I* put into the code. don't remember much... it wasn't a limit. maybe that was when I tried the gentoo suggested settings... Patches are welcome. I'd help but I'm no dev. sys admin student/intern. about the only thing I could do to help is testing, and in this case even that is somewhat limited because I like gentoo because I don't have to install all the time. in fact the only reason I reinstalled this last time is because a windows machine with putty had been compromised. I feared my linux system might have been compromised too. so I waited and reinstalled on the next release. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a new TLP to unify programming langiages?
This isn't going to bring any benefits to anyone. If you want to help users find docs on programming languages on Gentoo (assuming there _are_ any users who don't know how to Google for such things), just get the docs team to organise 'Programming Languages on Gentoo' docs category on [1]. _That_ would be much more useful to users. Creating a TLP just to order some docs ... sorry, but it seems a very bizarre thing to do. [1] http://www.gentoo.org/doc/en/index.xml I would like to say that the docs are second to... probably only IBM developerworks which seems like where 1/4 of our docs come from. perhaps the wrong time to bring this up but the list for documentation is a MESS I've been using gentoo docs for 3 years back when they were 1/10-ish this size and back then the organization worked. but I can never remember whether the reference I'm looking for is Gentoo Desktop Documentation Resources Upgrade Guides System Administration Documentation etc. so the index page rare does me any good I suggested this on bugzilla a long time ago... and can't remember what happened with it. but docs could use a search function. better yet if it could somehow be integrated also into the forum search might save some time with some questions. example search grub on the forums get the grub error listing doc, and the handbook chapter on it, then forum threads. even if the forum thing wasn't possible say I was looking for a doc on iptables. http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1chap=12 http://www.gentoo.org/doc/en/articles/dynamic-iptables-firewalls.xml http://www.gentoo.org/doc/en/articles/linux-24-stateful-fw-design.xml those are 3 references that I'm aware of and in 2 different places and only one even mentions iptables in the title, and if I don't know the linux firewall is called iptables and I search firewall only one is labeled firewall in the link and the other I would have to know it was mentioned in the security handbook. I also think that via common sense these would all be under System Administration Documentation, but none of them are. If I were new to the docs I would be completely confused at the organization. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
I know what unsupported means chris. what I'm referring to though are bugs that would affect i686 as well. but possibly get closed because a dev, like yourself, requested emerge --info and saw it was build on i686 and closes it for that reason. probably RESOLVED WONTFIX . On 10/11/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2006-10-11 at 12:18 -0400, Caleb Cushing wrote: I fear the idea that valid bugs may be closed do to a -march=i586. If they're a bug dealing with an issue only present on i686, then yes, they likely would be, at least for release media, unless you also provide a patch. This is what being unsupported means. Now, if you give me a patch for some bug that only affects i686, I'll apply it, provided it doesn't break = i686, but I simply don't have the time to support i686 with the release media anymore. By the way, the stage1 tarball and Minimal InstallCD are both built as i386 and will remain that way for the foreseeable future. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Troubleshooters for Gentoo
I have a couple of questions: 1) Does this sound like a good idea? 2) Does anyone feel like pouring his/her troubleshooting skills into content for my program? 1.) maybe microsofts troubleshooter sucks, it never solved a single problem I had. this will only be a good Idea if we're guaranteed to do better. on gentoo this would be harder than say red hat. because of almost infinite combinations of ways to have your software built. 2.) maybe... but I think you'll need someone before me. this is too unreliable too many variables / ways of doing things. first question do you use command line / gnome / kde /. answer use program x in this way to solver your problem. user huh. I don't have this program wtf. program x is not installed. checks portage. program x was hardmasked last week. this would be insane open source moves to fast good luck having your troubleshooter keep up. pgpTSnYlXja72.pgp Description: PGP signature
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
I fear the idea that valid bugs may be closed do to a -march=i586. release media should not have to be tuned to i386. perhaps thes older machines shouldn't be a priority, but that doesn't mean they should become completely unsupported. if a general move to i686 is desired perhaps the archs should split x86 and i686 or some such. and applications that are unable to be supported on i686 be removed from the x86 tree. On 10/11/06, Duncan [EMAIL PROTECTED] wrote: Paul de Vrieze [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Oct 2006 16:46:05 +0200: A couple of years ago (when we were still using gcc-2.95 I used to run gentoo on my server machine which was a pentium-60 (with fdiv bug). While it took a while to compile the bigger packages it was certainly workable. I did it because I didn't have a better machine, not to be able to say I did it. Well yes, except that I'd guess that was a bit more than a couple of years ago (I've been on Gentoo since 2004.0/2004.1, and IIRC it was gcc-3.3 then, so 2.95 would have been what, at least three years ago??). That means the archs are a third(-ish) of a decade further out of date than they were then. That's a significant amount of time in computer terms. Anyway, not supported doesn't mean can't do it. As I suggested in a different reply, it could and would likely still be done, just as Gentoo based systems are run on all sorts of stuff according to embedded, and in fact they may choose to continue some support, as I believe pentium-class embedded is quite popular. Not supported just means less frequent install media or bootstrapping from other distributions instead of Gentoo install media, and that bugs can be closed if desired and appropriate, based on that alone. -- 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] Missing: Universal-CD - Gentoo discriminates shell and networkless users
I would like to state my opinion on this... debate. the installer for me... is inadequate it does not allow for nearly enough customization. I generally keep my boot partitions at 32 MB why? because I don't need anymore space than that( I have never even used half that much). I optomize my ext3 partions using tune2fs as well. I also have a seperate partition for portage and distfiles. also not supported. fortunately my network works. however I would prefer myself not to have to dowload tarballs which seem to only be updated on the next release anyway. I am hoping that one day that the GLI will support full customization, but I won't complain as long as I can get stage3 tarballs. as far as older than i686 I do have 1 or 2 i586s that I have gentoo on. I would like to see a generic tarball kept around for anything older than i686. because gentoo is one of the few distributions I've been able to get working on older systems. It would be really sad to see such support go. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
umm... I don't that was the point (that it can't work for everyone). However it would be nice if I didn't have to download a tarball. I see the point in why it's hard with distfiles but how hard would it be to add tarballs and limited distfiles. to a minimal cd) and make it universal and put it up for download? maybe and make a note in the handbook distfiles are not supported or some such. I really don't understand why this is so difficult? the tarballs wouldn't be changing from the ones that are on the mirrors. so what is the hangup? I doubt it's storage space and bandwidth. (btw I've built livecds using catalyst) On 10/9/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 9 Oct 2006 19:11:47 -0400 Caleb Cushing [EMAIL PROTECTED] wrote: | I would like to state my opinion on this... debate. the installer for | me... is inadequate it does not allow for nearly enough customization. Then don't use the installer. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 -- gentoo-dev@gentoo.org mailing list
