Re: [gentoo-dev] merge amd64 x86 arches? (was: crap use flags in the profiles)
On 31/8/2005 9:18:53, Stephen P. Becker ([EMAIL PROTECTED]) wrote: Keep in mind that the *stable* trees of x86 and amd64 are actually pretty close to the same versions anyway, I just ran gmsoft's imlate script for amd64 vs. x86 keywords: hmm; missed a biggie - sys-devel/gcc which is stable for amd64 at 3.4.4-r1 and stable for x86 on 3.3.5.20050130-r1. The only way I can think of to deal with amd64/x86 differences other than via an arch keyword is to use masking in profiles. i.e. to mark both versions stable and mask the unwanted version in 'packages'. The downside is that what would have been a testing version is now masked by the profile, and profile masking is a much stronger statement than simply keywording ~. Is there a way to deal with this sort of thing in profiles, without masking? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Player, Stage, Gazebo eBuilds
On Wed, 31 Aug 2005 21:43:31 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: | Is it possible for me to mantain the packages? We don't (or at least shouldn't...) give out CVS to people just for a few ebuilds. If you contribute a lot of high quality stuff then someone may offer to mentor you. There is no fidonet stuff in the portage tree. I can write ebuilds for that. To get fidonet system worked user needs mailer, tosser, reader. Those programms in logic can not be added to existent categories. So I want to add four new categoies to portage tree: ftn-mailer, ftn-tosser, ftn-reader, ftn-stuff. But I'm not sure if I submit these ebuilds to bugzilla somebody wants to commit them to cvs. So do I have chance to become gentoo developer and get access to CVS? And does somebody want to mentor me? -- Cheers! Дмитрий Лукашин -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Election results
Thanks to the 148 people who voted. I think that's slightly less than a 50% turnout, but it's still not too shabby. The new Gentoo Council is: seemant vapier agriffis solar azarah Swift Koon The master ballot is attached, and confirmation e-mails to those who voted will follow shortly. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 - confirmation 294d - Stuart bonsaikitten kugelfang mcummings Koon seemant lcars tigger Weeve KingTaco azarah jaervosz Plasmaroo spb SwifT agriffis vapier slarti tomk Ramereth genone Mr_Bones_ solar Kumba ciaranm - confirmation 0439 - solar tigger ciaranm vapier spb seemant agriffis azarah mcummings - confirmation 2b3b - agriffis tigger ciaranm solar Mr_Bones_ Plasmaroo SwifT Weeve KingTaco seemant Koon genone tomk lcars azarah Ramereth Stuart Kumba mcummings jaervosz slarti vapier bonsaikitten kugelfang spb - confirmation 006f - seemant solar Stuart Plasmaroo Weeve jaervosz vapier Koon lcars agriffis Ramereth SwifT azarah mcummings ciaranm genone tigger spb Mr_Bones_ Kumba bonsaikitten tomk kugelfang slarti KingTaco - confirmation 2ba3 - ciaranm bonsaikitten kugelfang KingTaco vapier seemant spb SwifT agriffis jaervosz Koon azarah solar Mr_Bones_ tomk genone Kumba lcars Weeve Plasmaroo Stuart tigger slarti Ramereth mcummings - confirmation 2c0d - seemant SwifT ciaranm agriffis mcummings azarah genone kugelfang Weeve Kumba solar tigger Plasmaroo vapier Mr_Bones_ KingTaco - confirmation 2d33 - vapier Stuart ciaranm bonsaikitten spb agriffis Koon tigger azarah solar SwifT seemant Kumba jaervosz Mr_Bones_ Plasmaroo slarti KingTaco lcars kugelfang genone Weeve tomk mcummings Ramereth - confirmation 2d4a - agriffis azarah seemant Mr_Bones_ Koon genone solar slarti vapier tigger SwifT Weeve Ramereth Kumba spb lcars kugelfang Plasmaroo jaervosz bonsaikitten KingTaco tomk Stuart mcummings ciaranm - confirmation 2dbe - seemant azarah agriffis bonsaikitten Stuart Ramereth Kumba genone mcummings slarti SwifT vapier ciaranm Plasmaroo Koon KingTaco Mr_Bones_ jaervosz solar spb kugelfang tomk tigger Weeve lcars - confirmation 2ed1 - agriffis vapier Plasmaroo ciaranm Weeve jaervosz Koon seemant azarah SwifT tigger spb slarti mcummings lcars Mr_Bones_ KingTaco genone Kumba kugelfang Ramereth tomk solar Stuart bonsaikitten - confirmation 3012 - KingTaco seemant SwifT Weeve lcars azarah Plasmaroo vapier agriffis kugelfang slarti solar Mr_Bones_ bonsaikitten Ramereth jaervosz Stuart Kumba Koon genone ciaranm tigger tomk spb mcummings - confirmation 303a - tigger Mr_Bones_ Stuart azarah seemant SwifT kugelfang bonsaikitten mcummings Weeve KingTaco jaervosz genone lcars slarti Kumba agriffis Ramereth solar Koon Plasmaroo vapier spb tomk ciaranm - confirmation 32fd - Koon Mr_Bones_ vapier agriffis ciaranm azarah Plasmaroo SwifT solar seemant lcars Ramereth slarti jaervosz genone KingTaco spb tomk Kumba tigger Weeve kugelfang mcummings Stuart bonsaikitten - confirmation 3337 - seemant ciaranm SwifT Koon vapier tigger azarah bonsaikitten agriffis Stuart mcummings Plasmaroo Weeve kugelfang Mr_Bones_ KingTaco genone jaervosz Ramereth slarti spb Kumba tomk lcars solar - confirmation 33db - agriffis Mr_Bones_ seemant vapier azarah Ramereth Koon solar Kumba SwifT kugelfang ciaranm slarti bonsaikitten Plasmaroo tigger spb KingTaco Weeve tomk Stuart lcars jaervosz genone mcummings - confirmation 34ec - vapier azarah agriffis solar Mr_Bones_ ciaranm kugelfang Weeve Kumba jaervosz Plasmaroo seemant Koon genone Stuart lcars KingTaco slarti tigger bonsaikitten Ramereth tomk SwifT spb - confirmation 3599 - ciaranm solar seemant agriffis Ramereth Koon Mr_Bones_ spb lcars kugelfang jaervosz SwifT slarti Weeve vapier bonsaikitten azarah tomk genone Plasmaroo Kumba mcummings tigger KingTaco Stuart - confirmation 36dc - ciaranm seemant lcars azarah solar Stuart vapier spb Mr_Bones_ Ramereth Koon tigger Plasmaroo kugelfang SwifT genone agriffis mcummings KingTaco slarti jaervosz Kumba tomk Weeve bonsaikitten - confirmation 3788 - KingTaco kugelfang bonsaikitten Koon slarti agriffis azarah Mr_Bones_ seemant tigger vapier solar jaervosz tomk SwifT Weeve mcummings Kumba Stuart Ramereth genone Plasmaroo lcars spb ciaranm - confirmation 3828 - agriffis solar mcummings Plasmaroo azarah ciaranm tigger lcars Weeve Koon Mr_Bones_ KingTaco Ramereth seemant SwifT vapier tomk bonsaikitten genone jaervosz slarti Kumba spb kugelfang Stuart - confirmation 3844 - agriffis azarah vapier Kumba Weeve ciaranm solar tigger seemant Ramereth spb Koon Mr_Bones_ Plasmaroo mcummings
[gentoo-dev] Re: [gentoo-core] Election results
On Thu, 2005-01-09 at 07:09 -0500, Grant Goodyear wrote: Thanks to the 148 people who voted. I think that's slightly less than a 50% turnout, but it's still not too shabby. The new Gentoo Council is: seemant vapier agriffis solar azarah Swift Koon As your friendly election official, I confirm that this result is valid (ie consistent with the master ballot). Congratulations to our new council! Now lets get to work! -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Election results
Grant Goodyear wrote: Thanks to the 148 people who voted. I think that's slightly less than a 50% turnout, but it's still not too shabby. The new Gentoo Council is: seemant vapier agriffis solar azarah Swift Koon As one of the election officials, I confirm that the above mentioned members are indeed the top 7 and my verification of the votes tallies with Grant's original count. Congrats to the new council members! Regards, -- Shyam Mani | [EMAIL PROTECTED] docs-team | http://gdp.gentoo.org GPG Key| 0xFDD0E345 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Election results
On Thu, 1 Sep 2005 07:20:03 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | Thanks to the 148 people who voted. I think that's slightly less | than a 50% turnout, but it's still not too shabby. Since we all know fine well that no-one understands the condorcet voting system... Here're the pretty pictures you've all been waiting for: http://dev.gentoo.org/~ciaranm/docs/council-2005-vote-distribution.txt Some of the graphs are rather, er, amusing. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp0GiXbmqiFb.pgp Description: PGP signature
[gentoo-dev] council meetings
Dear all, First, congratulations! Now get to work! *Grin* We needed to have the new metastructure plan someplace easy to find, so I created glep 39 for it. It's probably worth re-reading, just to make sure you know what's now on your plate. The big item is that there needs to be a public meeting by the end of the month, and I'm sure that there is at least one GLEP (if not several) that needs to be voted upon. I got burnt out running the managers' meetings, so I'm afraid that I'm not volunteering to run these. It's not a difficult job, though, and I would just suggest rotating the meeting chairperson job among the council members. Some possibly useful suggestions: (a) Put the current topic of discussion in /topic, (b) Put the easy stuff early in the agenda, so that at least something gets accomplished, (c) it's okay to politely tell people that the discussion is diverging from the topic at hand (I probably should have done so more often), and (d) meetings should really have a fixed ending time as well as a fixed starting time. Although I don't want to run the meetings, I'm certainly willing to help if needed. I have high hopes for this new Council, but of course it's up to you folks to make of it what you will. Personally, I expect great things. Best, g2boojum -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgppmuf99dRXQ.pgp Description: PGP signature
[gentoo-dev] combining x86 and amd64
The recent discussion about having a real x86 arch team and combining the x86 and amd64 keywords was both interesting and provocative. Of course, this is the sort of thing that the GLEP system was meant for. Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpOrAAoHhL3q.pgp Description: PGP signature
Re: [gentoo-dev] council meetings
Grant Goodyear wrote: [Thu Sep 01 2005, 11:50:56AM CDT] We needed to have the new metastructure plan someplace easy to find, so I created glep 39 for it. It's in CVS, but it may be a bit before it shows up on www.g.o. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp6zEYdwDbV1.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Grant Goodyear wrote: The recent discussion about having a real x86 arch team and combining the x86 and amd64 keywords was both interesting and provocative. Of course, this is the sort of thing that the GLEP system was meant for. Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? Are you volunteering? :P -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Grant Goodyear wrote: Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? I'm not sure if it's really worth writing another GLEP for an april's fool... -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 19:10, Grant Goodyear wrote: Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? I hope this not. As (iirc) I already said, it's impossible to combine x86 with anything else that's not 100% source and binary compatible with itself... The reason is actually simple: x86 is, or at least was, the reference architecture for almost all programmers. There are too many packages that works *just* on x86, both at source and binary level. Using a single keyword would make us unable to mark for example helixplayer (source) x86 and -amd64 at the same time (as it's now). While it can be simple to do for sparc or ppc that has relatively less users, and with no need for binary compatibility for -bin packages, it's probably going to be a *great* pain for both users AND developers of x86 and amd64 platforms (most probably for the latter, as x86 has basically no needs for multilib and so on). Please don't do that. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpVVtvLfexL0.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Simon Stelling wrote: Grant Goodyear wrote: Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? I'm not sure if it's really worth writing another GLEP for an april's fool... Gnah, forgot to include the link: http://article.gmane.org/gmane.linux.gentoo.devel/26749/match=glep+amd64 You probably want to reuse this one, if you really like the idea, I for sure don't. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Using a single keyword would make us unable to mark for example helixplayer (source) x86 and -amd64 at the same time (as it's now). So package.mask it in the (now hypothetical) amd64 sub-profile, and it is fixed. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
I hope this not. As (iirc) I already said, it's impossible to combine x86 with anything else that's not 100% source and binary compatible with itself... The reason is actually simple: x86 is, or at least was, the reference architecture for almost all programmers. Witih amd64 becoming so widespread, this will change. There are too many packages that works *just* on x86, both at source and binary level. Doesn't the amd64 team have a set of 32-bit compat libs just to run binary packages? When running 32-bit code, isn't amd64 basically just a glorified athlon-xp? -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 19:39, Stephen P. Becker wrote: Witih amd64 becoming so widespread, this will change. You think it's a thing that changes in 2 days? Doesn't the amd64 team have a set of 32-bit compat libs just to run binary packages? When running 32-bit code, isn't amd64 basically just a glorified athlon-xp? Kernel-level code doesn't work. Some 32-bit binaries fails to work, and the emul-libs are NOT a way to say it's 32-bit... There are TOO many differences... About p.mask.. no I don't like that solution, p.mask is good for a platform profile (for example bsd's, darwin's or linux's), but not to arch level, we have -* keywords for that, haven't we? -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpbOvvCsaM1c.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Simon Stelling wrote: Stephen P. Becker wrote: Using a single keyword would make us unable to mark for example helixplayer (source) x86 and -amd64 at the same time (as it's now). So package.mask it in the (now hypothetical) amd64 sub-profile, and it is fixed. That's exactly why i don't like the idea of merging keywords: You loose the ~arch state. We weren't talking about ~arch, we were talking about -arch. Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just a 64bit kernel with a 32bit userland. For users who want that, there is already a keyword: x86. Wrong again. On mips, we have 64-bit kernels with *three* different possible userlands, n64, n32, and o32, and we do just fine (although as of right now, we haven't bothered to make any n64 stages since they would run slower than n32 and o32 on all of our supported hardware). -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 01:39 pm, Stephen P. Becker wrote: I hope this not. As (iirc) I already said, it's impossible to combine x86 with anything else that's not 100% source and binary compatible with itself... The reason is actually simple: x86 is, or at least was, the reference architecture for almost all programmers. Witih amd64 becoming so widespread, this will change. will != now maybe down the road i'd be for this, but right now i think it's just a waste of time ... too many packages suck at life ... just yesterday i fixed a new release (made in the last month) of a package which loved to cast pointers to 'int' and then try to use the result -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just a 64bit kernel with a 32bit userland. Oh yeah, I forgot, sparc32 uses a different userland than sparc64 in Gentoo. Shall I stop shooting holes in this type of argument now? :) -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 01 Sep 2005 19:42:46 +0200 Simon Stelling [EMAIL PROTECTED] wrote: Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just a 64bit kernel with a 32bit userland. However, that can't be said of mips, where one keyword covers 32- and 64-bit kernels with three different userland ABIs, each with its own set of new and interesting bugs. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
What structure are you thinking about for the 'real' x86 arch?
would there be a meta-x86 and then two sub-archs?
ie.
--real_x86--+--x86--~x86
+--amd64--~amd64
where {real_x86}={x86}INTERSECT{amd64}.. ?
Lares
On Thu, 2005-09-01 at 12:10 -0500, Grant Goodyear wrote:
The recent discussion about having a real x86 arch team and combining
the x86 and amd64 keywords was both interesting and provocative. Of
course, this is the sort of thing that the GLEP system was meant for.
Now that we have a new council that (I hope) will be active in approving
or rejecting GLEPs, perhaps someone should be writing a GLEP about
combining x86 and amd64?
-g2boojum-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Stephen P. Becker wrote: The reason is actually simple: x86 is, or at least was, the reference architecture for almost all programmers. Witih amd64 becoming so widespread, this will change. That's why I have another proposal: Let's merge x86 and amd64 keywords in about 10 years, when x86 died ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 13:39 -0400, Stephen P. Becker wrote: I hope this not. As (iirc) I already said, it's impossible to combine x86 with anything else that's not 100% source and binary compatible with itself... The reason is actually simple: x86 is, or at least was, the reference architecture for almost all programmers. Witih amd64 becoming so widespread, this will change. There are too many packages that works *just* on x86, both at source and binary level. Doesn't the amd64 team have a set of 32-bit compat libs just to run binary packages? When running 32-bit code, isn't amd64 basically just a glorified athlon-xp? No. It just has the same *instruction* set as an Athlon XP, plus SSE2 and even SSE3 in newer models. There's also the Intel EM64T stuff which is more like a P4 than an Athlon XP, since it has no 3Dnow! support. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-01-09 at 19:02 +0100, Ciaran McCreesh wrote: On Thu, 1 Sep 2005 19:50:11 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote: | Untrue. | | Can I have reasoning? Take a look at how sparc and mips currently handle packages which will run on some CPU kinds or ABIs but not others. Is it just me, it seems that only sparc/mips devs want that kind of change and non none of the x86/amd64 devs... I still dont see what practical advantage that would bring to x86/amd64 users or developers? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 1 Sep 2005 12:10:28 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | The recent discussion about having a real x86 arch team and | combining the x86 and amd64 keywords was both interesting and | provocative. Of course, this is the sort of thing that the GLEP | system was meant for. Now that we have a new council that (I hope) | will be active in approving or rejecting GLEPs, perhaps someone | should be writing a GLEP about combining x86 and amd64? Won't work. Too many people who don't have a clue what's being proposed and who don't understand the explanations. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpR7LgHo8xrL.pgp Description: PGP signature
[gentoo-dev] Re: Fixing the TERM mess
Ciaran McCreesh ciaranm at gentoo.org writes: Now, there's a slight problem. If you have TERM=shinynewterm, and you ssh to a box with an old terminfo database, you'll get a warning or error that your terminal isn't recognised when you try to use an ncurses-based application. You can either ask the sysadmin to upgrade, or you can install the relevant terminfo files into ~/.terminfo. This isn't a major problem, but the local terminfo thing isn't very well known, so some people have this silly misconception that you're either screwed or have to export a fake TERM if the box you're on doesn't recognise your terminal. The best solution to this that I can think of is to extend OpenSSH with the capability to copy terminfo information to ~/.terminfo on the remote system. This solution would have these advantages: * The actual TERM name xterm or gnome or rxvt would no longer matter at all. Applications could lie all they like and we would not be bothered. All that is necessary is that on your home system things would be set up so that the TERM value determines the right information in the local terminfo database or your own ~/.terminfo. When OpenSSH copies the information to the remote system, it would check in the remote terminfo information (both the system database and your ~/.terminfo) for an exact match on the specifications and if so reuse the name with the matching data; otherwise it would pick a fresh name following a specific convention (e.g., xterm-via-ssh-3 where -via-ssh-3 is added just to be different) and insert the data in your remote ~/.terminfo. * The correct information would always be available. No terminal application would ever have to be used with crippled specifications. * When terminal applications start up, they could choose their own name (and bump it with each revision that adds features or removes bugs) and ensure that the correct information was stored in ~/.terminfo. This would avoid the problem of stale information in the terminfo database. (Well, some cruft would accumulated in the personal ~/.terminfo area, but the entire directory could safely be deleted whenever you have no programs running on the system, e.g., at boot time.) * The terminfo database could eventually no longer matter. It would be needed only for legacy terminal applications that don't supply their own information and for terminal applications whose authors supply the wrong information (and in both cases the information would only be needed on the system the application starts on, because OpenSSH would copy the correct values to where they were needed). * The extension to OpenSSH seems not too hard to implement. OpenSSH can run infocmp to get a terminfo description as a big string. OpenSSH already has support (at least in SSH protocol version 2) for copying the values of some environment variables like TERM, so it could just reuse this same mechanism to copy the data to the remote system. On the remote machine, tic can be used to insert the terminfo description into ~/.terminfo. * Only the OpenSSH package needs to be modified. Although the various terminal applications would benefit from installing accurate self-descriptions in ~/terminfo when they start up, this is not needed. * The solution is 100% backward compatible. Existing usage remains exactly the same. No programs have to be changed other than OpenSSH. Old versions of OpenSSH would still work just as they do now; they would just be missing the new advantage. * If OpenSSH fails in copying the terminfo data into ~/.terminfo on the remote system, it can fall back to the old approach just by stripping off any -via-ssh-* suffix from the TERM value. (This means the convention for picking fresh names needs to be reversible.) * The solution would be automatically deployed worldwide through the regular updating of OpenSSH. People will tend to update OpenSSH more quickly than other packages due to the desire to keep their security up-to-date. Anyway, this solution would be another motivation for everyone to stay upgraded to the latest version of OpenSSH, which is always a good thing. * Maybe some more people would dump proprietary SSH if they don't add the feature quickly enough. :-) -- Joe Wells P.S. I don't normally read this forum at all, so if you want me to see any replies please e-mail a copy to me. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 01 Sep 2005 14:36:44 -0400 Olivier Crete [EMAIL PROTECTED] wrote: | Is it just me, it seems that only sparc/mips devs want that kind of | change and non none of the x86/amd64 devs... The people who have worked with such a system before and understand how it works and what all it can do want change. Those who don't understand the system and think that it has all kinds of problems that are really just a lack of understanding don't want it to change. | I still dont see what practical advantage that would bring to | x86/amd64 users or developers? QA. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpkV7U5E4kw0.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 20:42, Ciaran McCreesh wrote: The people who have worked with such a system before and understand how it works and what all it can do want change. Those who don't understand the system and think that it has all kinds of problems that are really just a lack of understanding don't want it to change. The firsts includes the ones that REALLY works with x86 and amd64. The latter don't give a damn about x86 and amd64 and seems just like they want to show off how much they are better than us... QA. SNR -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgp7f0w636F20.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Ciaran McCreesh wrote: [Thu Sep 01 2005, 01:41:22PM CDT] Won't work. Too many people who don't have a clue what's being proposed and who don't understand the explanations. Okay, with that statement, and an inability to find anybody else who really wants to write such a GLEP, I'm certainly willing to drop it. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpT7K0wVex6k.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Grant Goodyear wrote: The recent discussion about having a real x86 arch team and combining the x86 and amd64 keywords was both interesting and provocative. Of course, this is the sort of thing that the GLEP system was meant for. Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? -g2boojum- This will not happen. Years down the road AMD64 may absorb the remaining x86 issues, but AMD64 will certainly never be run like x86 has been. Mike Doty -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 14:36 -0400, Olivier Crete wrote: On Thu, 2005-01-09 at 19:02 +0100, Ciaran McCreesh wrote: On Thu, 1 Sep 2005 19:50:11 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote: | Untrue. | | Can I have reasoning? Take a look at how sparc and mips currently handle packages which will run on some CPU kinds or ABIs but not others. Is it just me, it seems that only sparc/mips devs want that kind of change and non none of the x86/amd64 devs... No, Yes, and Yes. I still dont see what practical advantage that would bring to x86/amd64 users or developers? Well, I guess the theory might be because then you only have one keyword and one base profile to manage - I think. --- From a quick diff, it looks like they are handled via the ABI and PROFILE_ARCH stuff, but what your average sparc/mips dev do not realise, is that most x86 devs, and probably many amd64 devs have no idea what and how the ABI stuff is used. Mostly the ABI stuff was hacked by (and still is mostly if I'm not mistaken) by Jeremy, and they mostly just use ARCH or use to apply x86/amd64 patches. So your basic problem is that: 1) They have no idea how sparc/mips does it 2) They do not see any benefits 3) They get even more confused by the half assed answers they get. So to be frank, I propose that either the alt-arch devs start explaining above instead of half-assed answers and senseless ranting, or shut up. From the amount of _usefull_ comments they have given, it does not look like its really an issue or priority for them besides having some fun. Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 20:54, Stephen P. Becker wrote: Well, merging the two arches will help solve this problem. I read this as as nobody wants to take care of x86, and we can't blame anyone because there's no one to blame, let make amd64 arch team the one to blame, as we don't have facts about x86 arch team at all. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpTpNuruxM3f.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 19:42 +0100, Ciaran McCreesh wrote: On Thu, 01 Sep 2005 14:36:44 -0400 Olivier Crete [EMAIL PROTECTED] wrote: | Is it just me, it seems that only sparc/mips devs want that kind of | change and non none of the x86/amd64 devs... The people who have worked with such a system before and understand how it works and what all it can do want change. Those who don't understand the system and think that it has all kinds of problems that are really just a lack of understanding don't want it to change. Maybe, but please give one example of such an 'explanation' that any of the pro-merge devs have given. | I still dont see what practical advantage that would bring to | x86/amd64 users or developers? QA. Possible, but once again, why will a merge give 'better' QA ? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
On Thu, 1 Sep 2005 20:54:15 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 01 September 2005 20:42, Ciaran McCreesh wrote: | The people who have worked with such a system before and understand | how it works and what all it can do want change. Those who don't | understand the system and think that it has all kinds of problems | that are really just a lack of understanding don't want it to | change. | The firsts includes the ones that REALLY works with x86 and amd64. The ones who are short-sighted and only understand simple non-split archs, yes. | The latter don't give a damn about x86 and amd64 and seems just like | they want to show off how much they are better than us... | | QA. | SNR Note the 'ratio' part. It isn't affected by a change in the number of users. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpgXQLctwhox.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-01-09 at 19:53 +0100, Ciaran McCreesh wrote: On Thu, 1 Sep 2005 20:46:46 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 01 September 2005 20:32, Ciaran McCreesh wrote: | Ideally they wouldn't be keyworded at all. | I live in a real world, not an ideal one. | | More users means more QA feedback. This means x86/amd64 will have an | *easier* job. | SNR, this unknown value that's so much important in communications... | this is when I like the school I did. So your argument is that our users are clueless morons? Many of the x86/amd64 user are... many like reiser4.. some even use love-sources... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 21:00, Martin Schlemmer wrote: Possible, but once again, why will a merge give 'better' QA ? Because you start over. You have to DO actually the QA that's missing on x86. That's true but... WHO will do that? The new merged arch team... but let my math skills try to solve this a + b = c x86 arch team + amd64 arch team = combined arch team 0 + b = b x86 arch team = 0 and this means that AMD64 arch team will have to do QA for x86, too... Yeah someone will join ... but I want to have a list of people joining before say that someone will join... -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgprse9xxrBFt.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 21:09, Ciaran McCreesh wrote: Hence the GLEP proposal. Unfortunately, too many ignorant people are jumping in and spewing out nonsense about things they don't understand before the GLEP's even written... There was one, wasn't it? And I think I answered to that with some points. I have explained my reasons for not doing so today. I have received no answer to those reasons that was not QA, more eyes means better and x86 arch team, to which I already have answered... -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpDcYy1i9q6x.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Martin Schlemmer wrote: I still dont see what practical advantage that would bring to x86/amd64 users or developers? Well, I guess the theory might be because then you only have one keyword and one base profile to manage - I think. Having just one keyword won't decrease our (our as in amd64 team) workload, nor will it increase our (our as in amd64 port) QA, it will just be the other way around. What really is confusing me is that mostly sparc/mips-devs want to push us in a direction we absolutely don't like, but we're affected by all effects, not them. And what is even more confusing, is that they make statements like I don't care about x86/amd64 So to be frank, I propose that either the alt-arch devs start explaining above instead of half-assed answers and senseless ranting, or shut up. From the amount of _usefull_ comments they have given, it does not look like its really an issue or priority for them besides having some fun. So I'm not the only one feeling assed, fine. I know ABI, but only in the context of multilib. We use it to decide whether something is 32bit or 64bit. As stated above, I can see how x86 will benefit from a merge, but the damage amd64 gets seems far bigger. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 1 Sep 2005 21:19:31 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 01 September 2005 21:09, Ciaran McCreesh wrote: | Hence the GLEP proposal. Unfortunately, too many ignorant people are | jumping in and spewing out nonsense about things they don't | understand before the GLEP's even written... | There was one, wasn't it? And I think I answered to that with some | points. I have explained my reasons for not doing so today. No, there was an April Fool's joke. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp01A17kVcdX.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 21:14 +0200, Diego 'Flameeyes' Pettenò wrote: x86 users = a lot, most of the illiterate, ricer, ranting users.. I thought that was amd64? :P Anyway, here's what *I* propose. I propose that we all just shut up and ignore this. It's obvious that there's not going to be an agreement on it, so let's drop it until there's an actual GLEP written on it. At that point, you can argue the points of the GLEP and it won't just be useless flaming. Either that, or you can take your stand and join up to form an x86 arch team and just end the need for this discussion right now. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Need an x86 tester with =1GB RAM (and some time to spare)
Hi, Theres a bug filed against gentoo-sources-2.6 which causes the system to be unreliable when running the 64GB highmem option. This bug isn't present in the vanilla kernels so it must be caused by one of the patches we apply, but I don't know which this might be. To see this bug, you need to have _some_ highmem in the system (this means = 1GB total physical RAM), be running on x86 (other arches dont have HIGHMEM option), and have the 64GB high memory support option enabled. (4gb is fine, as is lowmem) I've had this bug reproduced by a few different people, but none of them with enough time to help me diagnose this. I only have 512mb myself so I can't help. If anyone has the appropriate hardware and some time to spare slowly reverting out the Gentoo patches to help diagnose the problem, please take a look at http://bugs.gentoo.org/show_bug.cgi?id=101359 Thanks! Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 21:17 +0200, Diego 'Flameeyes' Pettenò wrote: The new merged arch team... but let my math skills try to solve this a + b = c x86 arch team + amd64 arch team = combined arch team 0 + b = b x86 arch team = 0 and this means that AMD64 arch team will have to do QA for x86, too... Hehehe... I like this explanation. It is very simple, but it does show part of the problem of such a merge. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 21:29, Chris Gianelloni wrote: I thought that was amd64? Well.. it actually is both :) -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpmVuQ8MulH5.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 21:28, Ciaran McCreesh wrote: | There was one, wasn't it? And I think I answered to that with some | points. I have explained my reasons for not doing so today. No, there was an April Fool's joke. Have to look down to the irc logs to find you said you were serious? That's why I pointed to that. If you weren't, well I'm sorry I pointed to that, please next time be more explicit with april fools... and now provide me an explaination, a solution, or something :) -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgprkDVbbxH1u.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Ciaran McCreesh wrote: No, there was an April Fool's joke. Which pretty good shows how ridiculous such a merge would be... -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On 1/9/2005 20:54:14, Stephen P. Becker ([EMAIL PROTECTED]) wrote: Is it just me, it seems that only sparc/mips devs want that kind of change and non none of the x86/amd64 devs... I still dont see what practical advantage that would bring to x86/amd64 users or developers? If you haven't figured out the reason we are pushing for this sort of thing yet, it is because x86 is unsupported in Gentoo (if you consider what all the other arches have to do to be supported). As a result, it causes the quality of the portage tree to suffer. Time and time again, it has been brought up that x86 should have an arch team, yet nobody ever acts on it. Well, merging the two arches will help solve this problem. Surely ths solution to that problem is to set up an x86 arch team, not to put such big a millstone around the neck of the amd64 team. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 01 Sep 2005 21:42:09 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | No, there was an April Fool's joke. | | Which pretty good shows how ridiculous such a merge would be... Not at all. It showed just how many silly knee-jerk reactions such a proposal would get. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpIUqM8Xf7Sc.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 21:14 +0100, Ian Leitch wrote: I think myself and tester are the only members who can be considered active at the moment. I'm happy with creating an arch team, though I don't think we'll end up with an abundance of members (x86 is far from the most popular arch among devs). Yeah, I added myself not too long back, but I still need to get my P4 up and running .. should be in the next week or two. Chris Gianelloni wrote: So would just making an x86 arch team. It would also be much less of a problem than merging x86 and amd64. How about this? I proclaim and x86 arch team now exists. It already has a security liason. $ cat /var/mail/alias/arch/x86 avenj solar tester port001 azarah -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
I think myself and tester are the only members who can be considered active at the moment. I'm happy with creating an arch team, though I don't think we'll end up with an abundance of members (x86 is far from the most popular arch among devs). Chris Gianelloni wrote: So would just making an x86 arch team. It would also be much less of a problem than merging x86 and amd64. How about this? I proclaim and x86 arch team now exists. It already has a security liason. $ cat /var/mail/alias/arch/x86 avenj solar tester port001 azarah -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mike, Mike Frysinger schrieb: | yes, assuming user wants that ... not everyone wants multilib crap on their | machine ... i know i'd prefer to have a 100% non-multilib system if i could | get away with it You can, we have the 'no-multilib' subprofile, and there is still hardened/amd64 which is not multilib, either. | -mike Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDF2i8aVNL8NrtU6IRAgUmAJ4n5zQAzqPYuoI3xakYxz+YLYCqIwCfZrUt L7WHl+Z77EmD+e1tkufHEbE= =0Dwc -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh schrieb: | On Thu, 1 Sep 2005 12:10:28 -0500 Grant Goodyear [EMAIL PROTECTED] | wrote: | | The recent discussion about having a real x86 arch team and | | combining the x86 and amd64 keywords was both interesting and | | provocative. Of course, this is the sort of thing that the GLEP | | system was meant for. Now that we have a new council that (I hope) | | will be active in approving or rejecting GLEPs, perhaps someone | | should be writing a GLEP about combining x86 and amd64? | | Won't work. Too many people who don't have a clue what's being proposed | and who don't understand the explanations. Too many people out of other projects try to achieve changes they want and put them on other people's todo lists... Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDF2ohaVNL8NrtU6IRAunnAJ4zdz33d0M6HghkrD4bWV+c86454ACgo0yq 058mbbrLLtkAgMRKlZA3xJY= =gZa5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-01-09 at 15:25 -0400, Chris Gianelloni wrote: So would just making an x86 arch team. It would also be much less of a problem than merging x86 and amd64. How about this? I proclaim and x86 arch team now exists. It already has a security liason. $ cat /var/mail/alias/arch/x86 avenj solar tester port001 azarah Seems that we even have two of our new Council members on the team. Anybody else want to join the team? Just add yourself to the alias and start paying attention to requests that are submitted to [EMAIL PROTECTED] via bugzilla. The people maintaining the x86 kernel should also join, as well as the release maintainer (chris, is that you?), the grub/lilo maintainers, etc... That would be a good start. We should also try to recruit one or two x86 arch testers, hparker has offered to help. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 12:10 -0500, Grant Goodyear wrote: The recent discussion about having a real x86 arch team and combining the x86 and amd64 keywords was both interesting and provocative. Of course, this is the sort of thing that the GLEP system was meant for. Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? -g2boojum- Just out of curiousity, what makes people think that the amd64 team will sit still for having all of x86 foisted off on them? -- Daniel Gryniewicz Gentoo AMD64 Team -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Stephen P. Becker wrote: Is it just me, it seems that only sparc/mips devs want that kind of change and non none of the x86/amd64 devs... I still dont see what practical advantage that would bring to x86/amd64 users or developers? If you haven't figured out the reason we are pushing for this sort of thing yet, it is because x86 is unsupported in Gentoo (if you consider what all the other arches have to do to be supported). As a result, it causes the quality of the portage tree to suffer. You are saying that the quality of x86 stuff in the tree is worse than the other arches? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 17:05 -0400, Olivier Crete wrote: release maintainer (chris, is that you?), the grub/lilo maintainers, Currently, yes. I'll add myself to the alias. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] x86 Architecture Team
OK, so forming an arch team for x86 seems to have won out over merging with amd64 (for the time being anyway), so lets get things underway. I have created bug #104525 for interested devs to add their names to (please CC also). Interested users may also show interest, I think tester and hparker are interested in possibly recruiting a few able fellows. Regards, Ian Leitch -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86 Architecture Team
On Thu, 2005-09-01 at 23:11 +0100, Ian Leitch wrote: Interested users may also show interest, I think tester and hparker are interested in possibly recruiting a few able fellows. I'd be more then happy to help get some ATs going to assist the devs.. -- Homer Parker Gentoo/AMD64 Arch Tester Strategic Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles
On Wed, 2005-08-31 at 09:18 -0400, Stephen P. Becker wrote: Notice that for almost everything, amd64 is barely behind x86...just a minor version number/revision or two at most. That's the ATs hard at work keeping us current ;) -- Homer Parker Gentoo/AMD64 Arch Tester Strategic Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need an x86 tester with =1GB RAM (and some time to spare)
Daniel Drake wrote: To see this bug, you need to have _some_ highmem in the system (this means = 1GB total physical RAM), be running on x86 (other arches dont have HIGHMEM option), and have the 64GB high memory support option enabled. (4gb is fine, as is lowmem) I currently have 1GB of RAM with the 4GB HIMEM on 2.6.12-gentoo-r9. I can play with it. I've had this bug reproduced by a few different people, but none of them with enough time to help me diagnose this. I only have 512mb myself so I can't help. Sounds like it's time to upgrade ;-) If anyone has the appropriate hardware and some time to spare slowly reverting out the Gentoo patches to help diagnose the problem, please take a look at http://bugs.gentoo.org/show_bug.cgi?id=101359 I can definitely do that on one of my days off work (Mondays and Tuesdays). Shouldn't be terribly difficult with the newer, smaller patchset. -- Jeff Walter Gentoo Developer [EMAIL PROTECTED] http://gentoo.org/~jeffw/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 19:10, Grant Goodyear wrote:
The recent discussion about having a real x86 arch team and combining
the x86 and amd64 keywords was both interesting and provocative.
aha? Not in the list, is it?
Of course, this is the sort of thing that the GLEP system was meant for.
Now that we have a new council that (I hope) will be active in approving
or rejecting GLEPs, perhaps someone should be writing a GLEP about
combining x86 and amd64?
This just leads me to assume you're not really a coder (wrt native programming
languages like C/C++), are you?
I mean, x86 (32bit) and amd64 (64bit) ARE NOT THE SAME ARCH.
This is simply demonstrated by all those ugly pointer-to-integer conversions
that often happen when you write on your legacy x86 architecture.
However, when you try to compile it on an amd64 e.g., you just can't as gcc
WILL bail out.
Having now a x86amd64-alike keyword instead of x86 and amd64 will just make
lots of user's emerge experiences pain ass.
Of course, OTOH, while our bugs db gets flooded with reports, this *could* be
a startup for us to know *what* packages needs fixing. But that way, we would
be jast far off enterprise.
Here's an example that works on x86 but *not* an amd64:
// g++ -o test32vs64bit test32vs64bit.cpp
#include cstdlib
int main() {
void *p = NULL;
unsigned u = (unsigned)p; // ok on x86; error on amd64
p = (void *)u; // ok on x86; error on amd64
return 0;
}
Of course, you might think WTF do some guy need this, but hey, programmers are
really creative, and use what the compiler accepts - I myself ran into this
while porting my apps/libs to amd64. And think of it, not everybody has the
money to grab one.
Congrats,
Christian Parpart.
pgpKwfrGKm0Ue.pgp
Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT] This just leads me to assume you're not really a coder (wrt native programming languages like C/C++), are you? *Grin* This sort of condescending attitude is rarely wise when it comes to dealing with Gentoo devs. Not only does it tend to annoy people (yes, I'm a tad annoyed by the presumption), but since you're still relatively new here the odds are that people know the person you're being condescending to better than they know you, and thus it just makes you look bad if you're wrong. Feel free to ask people what I do for a living, and whether they suspect that I know the difference between a 64-bit pointer and a 32-bit int. Best, g2boojum -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpeDWIP2Ahm8.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 17:05 -0400, Olivier Crete wrote: On Thu, 2005-01-09 at 15:25 -0400, Chris Gianelloni wrote: So would just making an x86 arch team. It would also be much less of a problem than merging x86 and amd64. How about this? I proclaim and x86 arch team now exists. It already has a security liason. $ cat /var/mail/alias/arch/x86 avenj solar tester port001 azarah Seems that we even have two of our new Council members on the team. Anybody else want to join the team? Just add yourself to the alias and start paying attention to requests that are submitted to [EMAIL PROTECTED] via bugzilla. The people maintaining the x86 kernel should also join, as well as the release maintainer (chris, is that you?), the grub/lilo maintainers, etc... That would be a good start. We should also try to recruit one or two x86 arch testers, hparker has offered to help. Be ready to test my packages has well. I'm very happy with the formation of the new x86 arch team i wish you the best and i think this is the way to improve Gentoo (QA, releases etc..). You guys need a doc writer too (catch one at #-doc) And of course i think AT's will have much work to do on the x86 team. -- Luis Medinas [EMAIL PROTECTED] http://dev.gentoo.org/~metalgod Gentoo Linux Developer: AMD64,Printing,Media-Optical -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Brian Harring wrote:
Round 3, fixed all uglyness.
You *will* see uglyness for the changeover from flat_list to flat_hash
if you're setting portdbapi.auxdbmodule to flat_hash, but that's a one
time hit, and is the reason we blow away the cache on portage
upgrades.
Either way, full patch, just correction of a few instances where it
user visible warnings were popping up, but not required.
~harring
I have created a patch for forward compatibility with arbitrary EAPI strings.
The only change is to substitute an integer constant EAPI_UNRECOGNIZED whenever
an unrecognized string is encountered.
Zac
Index: portage/pym/portage.py
===
--- portage.orig/pym/portage.py
+++ portage/pym/portage.py
@@ -81,7 +81,7 @@ try:
MOVE_BINARY, PRELINK_BINARY, WORLD_FILE, MAKE_CONF_FILE, MAKE_DEFAULTS_FILE, \
DEPRECATED_PROFILE_FILE, USER_VIRTUALS_FILE, EBUILD_SH_ENV_FILE, \
INVALID_ENV_FILE, CUSTOM_MIRRORS_FILE, SANDBOX_PIDS_FILE, CONFIG_MEMORY_FILE,\
- INCREMENTALS, STICKIES, EAPI
+ INCREMENTALS, STICKIES, EAPI, EAPI_UNRECOGNIZED
from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \
portage_uid, portage_gid
@@ -4542,7 +4542,10 @@ class bindbapi(fakedbapi):
try:
mylist[idx] = abs(int(mylist[idx]))
except ValueError:
-mylist[idx] = 0
+if mylist[idx]==:
+ mylist[idx] = 0
+else:
+ mylist[idx] = EAPI_UNRECOGNIZED
return mylist
@@ -4827,7 +4830,10 @@ class vardbapi(dbapi):
try:
results[idx] = abs(int(wants[idx]))
except ValueError:
-results[idx] = 0
+if wants[idx]==:
+ results[idx] = 0
+else:
+ results[idx] = EAPI_UNRECOGNIZED
return results
@@ -5313,7 +5319,10 @@ class portdbapi(dbapi):
try:
eapi = int(metadata[EAPI])
except (KeyError, ValueError):
-eapi = 0
+if metadata.has_key(EAPI) and metadata[EAPI]!=:
+ eapi = EAPI_UNRECOGNIZED
+else:
+ eapi = 0
metadata[EAPI] = eapi
if eapi != portage_const.EAPI:
# intentionally wipe keys.
@@ -5391,7 +5400,10 @@ class portdbapi(dbapi):
mylines[x] = mylines[x][:-1]
mydata[auxdbkeys[x]] = mylines[x]
- eapi = int(mydata[EAPI])
+ try:
+eapi = int(mydata[EAPI])
+ except ValueError:
+eapi = EAPI_UNRECOGNIZED
if eapi portage_const.EAPI:
# if newer version, wipe everything and negate eapi
mydata = {}
@@ -5417,7 +5429,10 @@ class portdbapi(dbapi):
returnme[idx] = abs(int(returnme[idx]))
except ValueError:
# string
-returnme[idx] = 0
+if returnme[idx]==:
+ returnme[idx] = 0
+else:
+ returnme[idx] = EAPI_UNRECOGNIZED
return returnme
Index: portage/pym/portage_const.py
===
--- portage.orig/pym/portage_const.py
+++ portage/pym/portage_const.py
@@ -44,6 +44,7 @@ INCREMENTALS=[USE,FEATURES,ACCEPT_K
STICKIES=[KEYWORDS_ACCEPT,USE,CFLAGS,CXXFLAGS,MAKEOPTS,EXTRA_ECONF,EXTRA_EINSTALL,EXTRA_EMAKE]
EAPI = 0
+EAPI_UNRECOGNIZED = 65536
# ===
# END OF CONSTANTS -- END OF CONSTANTS -- END OF CONSTANTS -- END OF CONSTANT
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Paul de Vrieze wrote: On Wednesday 31 August 2005 14:57, Brian Harring wrote: Re: tagging EAPI at the top of a file, infra would probably shoot me for doing such- till a live, fully compatible and *roughly* equivalent parser is available, portage would have to do a bit of grepping, jacking up the regen times. If in cache EAPI can be gotten from the cache. If not, I don't think it matters where in the file EAPI occurs from the standpoint of getting it's value. The only thing would be that in the future a fast EAPI parser could be made that would just look at EAPI and get its version. I could easilly write you such a parser. It is impossible write a parser for an unconstrained and unknown format that may exist in the future. If we put a constraint on the format, in order to parse the EAPI, then we contradict our original goal (to unconstrain the format). A better approach IMO would be to store the EAPI in a separate file such as metadata.xml. This would allow *absolute* flexibility in the ebuild format. Portage would be able to select an appropriate parser with no need to examine the ebuild itself. Zac -- gentoo-portage-dev@gentoo.org mailing list
