Re: [gentoo-dev] binary packages and striping
On Thursday 09 March 2006 04:12, Mike Frysinger wrote: this is kind of a pita in terms of maintenance and imo a hack ... why not just have the splitelf code skip stripped binaries Because of the number of `file` calls needed to identify stripped and non-stripped binaries, I'd say... -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpFTeQuUy01C.pgp Description: PGP signature
Re: [gentoo-dev] binary packages and striping
On Thu, 2006-03-09 at 11:28 +0100, Diego 'Flameeyes' Pettenò wrote: On Thursday 09 March 2006 04:12, Mike Frysinger wrote: this is kind of a pita in terms of maintenance and imo a hack ... why not just have the splitelf code skip stripped binaries Because of the number of `file` calls needed to identify stripped and non-stripped binaries, I'd say... Come to think of it portage-2.1_NEXT will require =pax-utils-0.1.10 (auto fixing evil rpaths) which has support for '*.a' files now (spanky rules). We can probably obsolete the need to call 'file' all together now in prepstrip. Heres a patch also which should help you track down offending programs as they occur. should catch all cases of 'install -s' also. http://tinderbox.x86.dev.gentoo.org/portage/local/patches/sys-devel/binutils/binutils-gentoo-strip-safe.patch -- solar [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] x86-fbsd keyword in main tree?
Okay, solar asked me yesterday, and I think this might be the good moment to start this out. Right now the x86-fbsd keyword is not being used in the main tree, and the whole Gentoo/FreeBSD is handled in an overlay, sharing the ~x86 keyword with standard Gentoo/Linux. Unfortunately this has a series of drawbacks: - we need to package.mask packages that could just not have ~x86-fbsd keyword at all (because being linux specifics); - we can see the last working version of a package go away because later versions are ~x86 and they don't work for us (old flex might have been an example but that's now fixed; findutils can be another example); - we cannot make sure that the deptree is satisfied. To bring ~x86-fbsd keywording in main tree, we mainly need to move a true profile in the tree, not a dummy one, mark it as indev and start the keywording. (I've already cleaned up the default-bsd/fbsd profile so that it does work with the current base/ profile. As long as virtual/libc is not in the dependencies, it shouldn't trigger any kind of problems to leave the sys-freebsd category in the overlay, if we really need to start needing that, I'll see to make the ebuild quality level. It's not going to be a quick thing, as I'm mostly alone with Gentoo/FreeBSD right now (help is always welcome), but times are mature so that I can provide a decent experience to users. Can anybody name a showstopper to this? -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpE57WpFrblQ.pgp Description: PGP signature
Re: [gentoo-dev] SLOTed MySQL or not?
Luca Longinotti wrote: As the title says, what would you prefer for the future of MySQL in Gentoo? Please take a moment to read https://forums.gentoo.org/viewtopic-t-438557.html and vote (and eventually comment on it). Thanks! http://bugs.gentoo.org/show_bug.cgi?id=125599 deprecation of Slotted MySQL Upgrade and Migration Guide -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86-fbsd keyword in main tree?
Diego 'Flameeyes' Pettenò wrote: Okay, solar asked me yesterday, and I think this might be the good moment to start this out. Right now the x86-fbsd keyword is not being used in the main tree, and the whole Gentoo/FreeBSD is handled in an overlay, sharing the ~x86 keyword with standard Gentoo/Linux. Unfortunately this has a series of drawbacks: - we need to package.mask packages that could just not have ~x86-fbsd keyword at all (because being linux specifics); - we can see the last working version of a package go away because later versions are ~x86 and they don't work for us (old flex might have been an example but that's now fixed; findutils can be another example); - we cannot make sure that the deptree is satisfied. To bring ~x86-fbsd keywording in main tree, we mainly need to move a true profile in the tree, not a dummy one, mark it as indev and start the keywording. (I've already cleaned up the default-bsd/fbsd profile so that it does work with the current base/ profile. As long as virtual/libc is not in the dependencies, it shouldn't trigger any kind of problems to leave the sys-freebsd category in the overlay, if we really need to start needing that, I'll see to make the ebuild quality level. It's not going to be a quick thing, as I'm mostly alone with Gentoo/FreeBSD right now (help is always welcome), but times are mature so that I can provide a decent experience to users. Can anybody name a showstopper to this? Yes, x86-fbsd is not a 'working'[1] profile keyword. [1]The same reason why ppc-macos has some weird and potentially dangerous profile tricks to keep their systems running. We are looking at adding PROFILE_ARCH, or use.force to the profiles to remedy the situation. Basically portage expands $ARCH into use ( so x86-fbsd has ARCH x86, and would get x86 in use, which IMHO, isn't that horrible ). However, you also don't get x86-fbsd shoved into USE, so you have to inject it elsewhere, and then users could do something stupid like -x86-fbsd in make.conf, and unset their ARCH flag = bad. PROFILE_ARCH='x86-fbsd' - would get forcefully injected into USE, OR use.force: x86-fbsd - a use flag that isn't killed by -*. Whatever the fix is we should be able to make a 2.0.54-r1 release with it, still need to talk to Zac, if anyone has any comments on this, now would be the time ;) -Alec Warner signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On Thu, 09 Mar 2006 10:20:33 -0500 Alec Warner [EMAIL PROTECTED] wrote: Basically portage expands $ARCH into use ( so x86-fbsd has ARCH x86, and would get x86 in use, which IMHO, isn't that horrible ). However, you also don't get x86-fbsd shoved into USE, so you have to inject it elsewhere, and then users could do something stupid like -x86-fbsd in make.conf, and unset their ARCH flag = bad. The profiles currently in the overlay set ARCH=x86-fbsd. Whether that's right or not is another debate, but it invalidates that particular problem. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On Thu, 9 Mar 2006 15:29:23 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: To bring ~x86-fbsd keywording in main tree, we mainly need to move a true profile in the tree, not a dummy one, mark it as indev and start the keywording. (I've already cleaned up the default-bsd/fbsd profile so that it does work with the current base/ profile. As long as virtual/libc is not in the dependencies, it shouldn't trigger any kind of problems to leave the sys-freebsd category in the overlay, if we really need to start needing that, I'll see to make the ebuild quality level. My main objection here is If it's worth doing, it's worth doing properly. I'd rather see the keywords and system ebuilds merged at the same time, so we don't end up with some half-system that has keywords in the tree but can't be installed. It's not going to be a quick thing, as I'm mostly alone with Gentoo/FreeBSD right now (help is always welcome), but times are mature so that I can provide a decent experience to users. Can anybody name a showstopper to this? As far as I'm concerned the main reason this has been almost exclusively in overlay for so long is that we can rework things much more easily without worrying about breaking backwards compatibility or upgrade paths. If it's in a state where that's not likely to be an issue any more then I'd be in favour of merging it, as long it's done right. That in itself will of course be a non-trivial task, but I can awake from my BSD-related hibernation to get it done if it's reckoned to be a good idea and unlikely to break anything. On the other hand, I don't want to do this if there are serious objections from other devs, so any opinions from outside gentoo-alt are welcome. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On Thursday 09 March 2006 16:20, Alec Warner wrote: Basically portage expands $ARCH into use ( so x86-fbsd has ARCH x86, and would get x86 in use, which IMHO, isn't that horrible ). Right now ARCH=x86-fbsd for G/FBSD, as spb already said, so it's not much of the problem. If that will change, it will with GLEP47 anyway, so that's not either a particular problem. Whatever the fix is we should be able to make a 2.0.54-r1 release with it, still need to talk to Zac, if anyone has any comments on this, now would be the time ;) Not like we're going to use 2.0.54 as it's mostly broken for Gentoo/FreeBSD... right now we need 2.1, and there will probably be more things to fix in the future, so... -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpMVqkXUBIfO.pgp Description: PGP signature
Re: [gentoo-dev] SLOTed MySQL or not?
Francesco Riosa wrote: Luca (chtekk) Longinotti, will also take care of MySQL, on my request, in a near future, then I'll stay as a backup maintainer for the time coming, or leave if needed for whatever reason. Don't be so hard on yourself. Everyone thinks you did a great job with MySQL. Only reason I think people were against the slotted versions is because it meant a change and actually reading configuration docs and actually doing something. Because emerge -uD world magically didn't make everything work with the latest upstream all of a sudden. I know I avoided the slotted upgrade for a bit just cause I didn't have time to learn anything new for a couple of days but once I did it seemed good. Forget public opinion, stick to it and support it and it will catch on. And it'll show another good power of Gentoo. Example being for hosting companies like mentioned by Alexander. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x86-fbsd keyword in main tree?
Stephen Bennett wrote: On Thu, 09 Mar 2006 10:20:33 -0500 Alec Warner [EMAIL PROTECTED] wrote: Basically portage expands $ARCH into use ( so x86-fbsd has ARCH x86, and would get x86 in use, which IMHO, isn't that horrible ). However, you also don't get x86-fbsd shoved into USE, so you have to inject it elsewhere, and then users could do something stupid like -x86-fbsd in make.conf, and unset their ARCH flag = bad. The profiles currently in the overlay set ARCH=x86-fbsd. Whether that's right or not is another debate, but it invalidates that particular problem. The problem being that your ARCH (architecture) IS x86, just as ppc-macos's architecture is ppc, and there may be patches that apply to both sets equally, and conversely things that apply to only linux. Now if GLEP47 is approved, then the point is moot ( x86 implies x86-linux, or whatever the corresponding keyword is ). If this is the tract we are going to head in I need to change the docs to reflect what ARCH really means. At present in man portage: ARCH Architecture type (x86/ppc/hppa/etc...). PROFILE_ARCH Distinguish machines classes that have the same ARCH. All sparc machines have ARCH=sparc but set this to either 'sparc32' or 'sparc64'. Ciaran had suggested pushing PROFILE_ARCH into USE, although that implies that x86? = ARCH x86 and not necessarily 'x86-linux' since anything running on x86 would have ARCH=x86. While I think the above is the 'proper' way to do things, it would require a massive migration of ebuilds in the tree, and no one has volunteered for that task, as well as making sure anything that uses 'x86' in this case runs on everything running on x86..it becomes quite complicated, even if it is the most flexable. Regardless, I'd like to reach a conclusion about this, was GLEP 47 submitted to the council for the next meeting? -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Gentoo doc developer: Josh Saddler (nightmorph)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yup. Chalk up one more for the SoCal conspiracy. ^_^ Peter Gordon wrote: Another Southern Californian, it would seem. Excellent. If you're ever in the Anaheim/Orange County Area give me a jingle. We could go for some Starbucks and head to Fry's or something. :P Welcome aboard, Josh! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEEG9yrsJQqN81j74RAlyKAKCjtDu7BaIgZj3BMLqhHYQL7Aqt5wCbB1Ic FhB3XfeZOZ6nrDamsGsJUhA= =f/qI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On 09-03-2006 12:30:33 -0500, Alec Warner wrote: Regardless, I'd like to reach a conclusion about this, was GLEP 47 submitted to the council for the next meeting? As far as I know: no. I didn't myself because I'm having a problem with ppc-macos and the upcoming x86-macos (they will probably have a lot in common) and am not completely sure whether what Diego and I proposed is actually flexible enough. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 28 Feb 2006 11:58:03 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: During that discussion we realized that having utf-8 not enabled by default and no utf8 fonts available by default causes lots of recompilation and reconfiguration. Enabling the unicode useflag in the profiles should help our international users and should not cause any problems. Are there any known bugs / problems this would trigger? Any reasons against that? Enabling support for utf-8 should be fine, but I'd like to sound a note of caution about using a utf-8 locale as a system-wide setting. Since UTF-8 contains holes in the representation (i.e. some sequences of 8-bit values are invalid), when something is asked to parse such invalid data unexpected results can ensue. For an example, see bug #125375 - it turns out that invalid sequences do not match '.' in sed regular expressions (sed-4.1.4). The other gnu tools probably behave similarly. Up to a point this is in line with the UTF-8 spec, which says, When a process interprets a code unit sequence which purports to be in a Unicode character encoding form, it shall treat ill-formed code unit sequences as an error condition, and shall not interpret such sequences as characters. (chapter 3 para 2 rule C12a). This clearly means that the invalid bytes cannot match . (or anything else for that matter). However sed should either generate an error, filter the illegal bytes out of its input, or replace them with a marker (replacement character) - instead it leaves the non-conformant bytes alone. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On Thursday 09 March 2006 20:37, Grobian wrote: As far as I know: no. I didn't myself because I'm having a problem with ppc-macos and the upcoming x86-macos (they will probably have a lot in common) and am not completely sure whether what Diego and I proposed is actually flexible enough. I don't think we have problem with flexibility, but rather with phrasing, as it's still blocked down to that point. Of course, it would help if someone from portage team would like to work on its implementation beforehand so that we can experiment the flexibility :P -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpd1cOwK7dOE.pgp Description: PGP signature
Re: [gentoo-dev] Desktop project lead nominations
Donnie Berkholz wrote: NOTE: Please post all replies on gentoo-desktop rather than gentoo-dev. It's about that time again, folks. We're going to have desktop project lead elections within the next month or so. Who's interested in running for lead? Feel free to post a bit on why you'll be the best lead ever, as well, and your philosophy on what a lead should do. If you're interested in following the process, join the -desktop list. Not having gotten any responses, I'm assuming nobody else wants to be the lead. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: binary packages and striping
On Thursday 09 March 2006 09:24, Mikey wrote: That is my point. There is nothing there to strip file a bug yet during an install I noticed it running scanelf on the entire 248 meg source tree. Kind of a pointless task, not to mention extremely wasteful of resources. yes and no scanelf will be run on $D regardless, it'll just run less times if you have RESTRICT=strip -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] Manipulating PROFILE_PATH and MAKE_CONF_FILE
portage_const.py defines finally PROFILE_PATH and MAKE_CONF_FILE. As I use portage to build on one host multiple different (embedded) systems with completely different profiles, I hacked portage_const.py to look for an environment variable and if defined use that for defining PROFILE_PATH and MAKE_CONF_FILE. Is that the right approach to go or are there other (better) options? Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systemshttp://www.vollmann.ch/ Linux for PXA270 Colibri module: http://www.vollmann.ch/en/colibri/ -- gentoo-portage-dev@gentoo.org mailing list
