[gentoo-dev] Re: News item review: X.org server upgrade
Christian Faulhammer fa...@gentoo.org posted 20090404000139.2ea5a...@terra.solaris, excerpted below, on Sat, 04 Apr 2009 00:01:39 +0200: [0] http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade- guide.xml BTW, as I'm on ~arch I had upgraded some time ago, but had been using the legacy keyboard and mouse drivers until seeing the stabilizing discussion here a few days ago. I tried using the upgrade guide to upgrade to evdev and it DID NOT WORK. I just now [1] filed the bug[2] The upgrade guide has this: First, make sure you've built xorg-server with INPUT_DEVICES=evdev. But it misses mentioning that the kernel must ALSO be built with evdev, namely, CONFIG_INPUT_EVDEV=y, in menuconfig under Device Drivers Input device support Event interface. That had me fighting all sorts of unnecessary battles for hours with hal, editing *.fdi files to merge keys, etc, only to have it STILL not work, with the xorg log saying evdev device not found or path (something or other). Finally, I thought to check the kernel config for an evdev driver. Sure enough, and it solved the problem I had spent needless hours fighting! So mentioning the evdev kernel device is IMO a blocker on the documentation. [1] I only figured out the problem after fighting with it for hours, was too tired to file a bug then, and it has only been a couple days since, during which I've been recovering and haven't even wanted to THINK about it. So I only now filed the bug. [2] [Xorg 1.5 Upgrade Guide] kernel evdev as well as xorg evdev driver http://bugs.gentoo.org/show_bug.cgi?id=264827 https://bugs.gentoo.org/show_bug.cgi?id=264827 -- 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
Re: [gentoo-dev] News item review: X.org server upgrade
Christian Faulhammer wrote: Hi, please see attached news item for review. V-Li s/emerging/updating/ Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
However, we have toyed with other ideas. One of which is to introduce IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I don't really like this idea because it exposes the use flag and we don't want it exposed to the users. If you don't want it exposed to users, then use a USE_EXPAND variable. Like zmedico said in EAPI 3 a normal use flag could be hidden but probably better to not have to migrate everything with prefix support to EAPI 3. Out of the existing USE_EXPAND variables USERLAND makes most sense to me but we could also introduce a new one too. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 13:23:24 +0300, Petteri Räty wrote: However, we have toyed with other ideas. One of which is to introduce IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I don't really like this idea because it exposes the use flag and we don't want it exposed to the users. If you don't want it exposed to users, then use a USE_EXPAND variable. Like zmedico said in EAPI 3 a normal use flag could be hidden but probably better to not have to migrate everything with prefix support to EAPI 3. Out of the existing USE_EXPAND variables USERLAND makes most sense to me but we could also introduce a new one too. USE_EXPAND does something like: USERLAND=GNU - userland_GNU For Prefix, we just need the prefix USE-flag (not prefix_XXX), hence USE_EXPAND doesn't help us. Adding prefix to use.mask (and use.force in Prefix profiles) allows us to get the desired behaviour. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
Fabian Groffen wrote: On 04-04-2009 13:23:24 +0300, Petteri Räty wrote: However, we have toyed with other ideas. One of which is to introduce IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I don't really like this idea because it exposes the use flag and we don't want it exposed to the users. If you don't want it exposed to users, then use a USE_EXPAND variable. Like zmedico said in EAPI 3 a normal use flag could be hidden but probably better to not have to migrate everything with prefix support to EAPI 3. Out of the existing USE_EXPAND variables USERLAND makes most sense to me but we could also introduce a new one too. USE_EXPAND does something like: USERLAND=GNU - userland_GNU For Prefix, we just need the prefix USE-flag (not prefix_XXX), hence USE_EXPAND doesn't help us. Adding prefix to use.mask (and use.force in Prefix profiles) allows us to get the desired behaviour. If prefix is in USERLAND then you have a userland_prefix use flag to use that can be hidden. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
Fabian Groffen wrote: On 04-04-2009 14:31:20 +0300, Petteri Räty wrote: If prefix is in USERLAND then you have a userland_prefix use flag to use that can be hidden. It is not. But can be added. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 14:54:20 +0300, Petteri Räty wrote: Fabian Groffen wrote: On 04-04-2009 14:31:20 +0300, Petteri Räty wrote: If prefix is in USERLAND then you have a userland_prefix use flag to use that can be hidden. It is not. But can be added. I think we talk about different things here. prefix is not a USERLAND. In Prefix, USERLAND=GNU. Neither do I think a something_prefix (use-expanded SOMETHING) is a useful approach. You're either using Prefix, or you don't. Hence, use prefix. Jeremy's question was about how to effectuate that, and we believe simply adding prefix to use.mask (and use.desc) in gentoo-x86 is the solution. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
Fabian Groffen wrote: On 04-04-2009 14:54:20 +0300, Petteri Räty wrote: Fabian Groffen wrote: On 04-04-2009 14:31:20 +0300, Petteri Räty wrote: If prefix is in USERLAND then you have a userland_prefix use flag to use that can be hidden. It is not. But can be added. I think we talk about different things here. prefix is not a USERLAND. In Prefix, USERLAND=GNU. Neither do I think a something_prefix (use-expanded SOMETHING) is a useful approach. You're either using Prefix, or you don't. Hence, use prefix. Jeremy's question was about how to effectuate that, and we believe simply adding prefix to use.mask (and use.desc) in gentoo-x86 is the solution. You can set USERLAND=GNU PREFIX Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
Le 03/04/2009 16:47, Jeremy Olexa a écrit : However, we have toyed with other ideas. One of which is to introduce IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I don't really like this idea because it exposes the use flag and we don't want it exposed to the users. Just of curiosity, with IUSE=prefix, how many packages would get the USE flag? If we're only talking about a few packages, I don't mind it showing up in portage. If anything, it'll help spread the word about Prefix :) Cheers, Rémi
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 14:31:20 +0300, Petteri Räty wrote: If prefix is in USERLAND then you have a userland_prefix use flag to use that can be hidden. It is not. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Real multilib support for Gentoo
Hi folks, i would like to hear about other opinions about real multilib support within our tree and package managers. From what i know, there are mainly 2 different ideas: 1. Do the main stuff in the package manager (e.g. if the ARCH is amd64 and the package has x86 keyword, the package manager adds a lib32 useflag, which would additionally install the 32bit variant of that package together with the normal 64bit install). pro:-much lesser work for package maintainers contra: -needs addition in PMS and support in the pms, which will need some work on their side 2. Do the main stuff in the ebuilds themselves (e.g. an additional eclass multilib-native.eclass, any ebuild with 32bit support would then need adaption and of course inheriting that eclass) For reference, there are some users in #gentoo-multilib-overlay, which try to implement this option in an git based overlay. the arguments are more or less the reverse of above: pro:-no need for PMS/PM support -could be started and improved at any time contra: -needs much additional work since many ebuilds need to be changed and adapted Which option do you prefer? Or does anyone have another option? Which additional arguments are there for those options? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages
Hello I would ask if I can maintainer following packages for the gentoo-amd64 arch. app-mobilephone/openmoko-dfu-util app-crypt/truecrypt media-sound/songbird Regards, stefan
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 15:21:23 +0300, Petteri Räty wrote: You can set USERLAND=GNU PREFIX Prefix is not a userland, please understand that. It's like pizza not being an elibc, or beer not being a kernel. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
Robert Buchholz schrieb:
On Monday 30 March 2009, Thomas Sachau wrote:
Ciaran McCreesh schrieb:
So far, we've got this, by agreement of the Council:
* There will be a default src_install in EAPI 3
* It will have a DOCS variable, or something along those lines.
I'd like to suggest the following too:
* If DOCS is explicitly specified, it is an error if anything in it
doesn't exist.
* If DOCS isn't explicitly specified, it isn't an error if anything
in its default, if it has one, doesn't exist.
We don't have an implementation yet. So I'll start off with this:
default_src_install() {
emake -j1 DESTDIR=${D} install
Why do you want to force -j1 here?
And i had this proposal some months ago, which noone argued against
any more (the default list may of course be extended):
...
What Ciaran added was a way to disable installation of default DOCS. The
implmenetation we discussed on the thread a while ago does not check
whether DOCS is declared but empty.
I believe the way the DOCS variable is handled in the first example of
the thread starter is good for a default_src_install although I don't
know if we really need arrays. But why not? :-)
ok, so actually it is the following:
first this part:
default_src_install() {
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
emake DESTDIR=${D} install || die emake install failed
fi
then there are 2 ideas from Ciaran:
1.:
local d
if ! declare -p DOCS /dev/null 21 ; then
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif declare -p DOCS | grep -q '^declare -a ' ; then
for d in ${do...@]} ; do
dodoc ${d}
done
else
dodoc ${DOCS}
fi
}
and 2.:
emagicdocs
emagicdocs() {
done_docs=
old_set=$(shopt | grep 'nocaseglob[[:space:]]*on')
shopt -s nocaseglob
for d in '' ${default_src_install_extra_subdi...@]} ; do
if [[ -n ${d} ]]; then
[[ -d ${d} ]] || die ${d} is not a dir
pushd ${d} /dev/null || die Failed to enter ${d}
local docdesttree=${DOCDESTTREE}
docinto ${d}
fi
for f in README Change{,s,Log} AUTHORS NEWS TODO ABOUT THANKS
{KNOWN_,}BUGS SUBMITTING \
HACKING FAQ CREDITS PKG-INFO HISTORY PACKAGING MAINTAINER{,S}
CONTRIBUT{E,OR,ORS}
RELEASE \
ANNOUNCE PORTING NOTES PROBLEMS NOTICE
${default_src_install_extra_do...@]}; do
for p in ${default_src_install_extra_prefix...@]} '' ; do
for doc in ${p}*([[:digit:]])${f}{,+([._-])*} ; do
if [[ -s ${doc} ]] ; then
for e in ${default_src_install_exclu...@]} ; do
[[ ${doc} == ${e} ]] continue 2
done
done_docs=${done_docs} ${d%/}${d:+/}${doc}
dodoc ${doc}
fi
done
done
done
if [[ -n ${d} ]]; then
docinto ${docdesttree}
popd /dev/null || die Failed to leave ${d}
fi
done
if [[ -n ${done_docs} ]] ; then
echo Installed docs ${done_docs# }
else
echo Didn't find any docs to install
fi
[[ -n ${old_set} ]] || shopt -u nocaseglob
}
Any more comments about this?
So what about this funcion for the next EAPI and also implementation
in base.eclass?
Why would you want to implement it in base.eclass when it's in EAPI=3? I
can't think of a case where inherit base would make things easier
than bumping to EAPI=3. In both cases, you might need to change logic
within your ebuild and test it.
That ideas was months ago, where EAPI-2 was just introduced and i had no idea
when a default
src_install with EAPI-3 could come in, so i suggested base.eclass as
alternative, so it could be
used earlier.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Real multilib support for Gentoo
Am Saturday 04 April 2009 14:59:22 schrieb Thomas Sachau: Hi folks, i would like to hear about other opinions about real multilib support within our tree and package managers. From what i know, there are mainly 2 different ideas: 1. Do the main stuff in the package manager (e.g. if the ARCH is amd64 and the package has x86 keyword, the package manager adds a lib32 useflag, which would additionally install the 32bit variant of that package together with the normal 64bit install). pro: -much lesser work for package maintainers contra: -needs addition in PMS and support in the pms, which will need some work on their side 2. Do the main stuff in the ebuilds themselves (e.g. an additional eclass multilib-native.eclass, any ebuild with 32bit support would then need adaption and of course inheriting that eclass) For reference, there are some users in #gentoo-multilib-overlay, which try to implement this option in an git based overlay. the arguments are more or less the reverse of above: pro: -no need for PMS/PM support -could be started and improved at any time contra: -needs much additional work since many ebuilds need to be changed and adapted Which option do you prefer? Or does anyone have another option? Which additional arguments are there for those options? If it's feasible, I'd say go with option #1 as it would impose much less work in longer terms. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 14:22:09 +0200, Rémi Cardona wrote: Le 03/04/2009 16:47, Jeremy Olexa a écrit : However, we have toyed with other ideas. One of which is to introduce IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I don't really like this idea because it exposes the use flag and we don't want it exposed to the users. Just of curiosity, with IUSE=prefix, how many packages would get the USE flag? If we're only talking about a few packages, I don't mind it showing up in portage. If anything, it'll help spread the word about Prefix :) It's more that you cannot sensibly set USE=prefix yourself, neither should you be suggested or encouraged to do so, hence it should never show up in Portage's pretend output. It's like Portage suggesting you that you can set ARCH or KERNEL to some other value yourself, and that if you emerge -e or something you can upgrade Linux to FreeBSD or x86 to ppc. While this would be great, it doesn't work. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Paludis --info does not work for me. Plz2fix. In particular, have a look at http://bugs.gentoo.org/show_bug.cgi?id=262277#c4 Where both emerge --info and paludis --info is posted. Sometimes, more is less. While it may be useful to post all the information about the package-manager for *you*, it's not helping us (bug-wranglers) any. We need one screenfull of text that concisely shows us the state of your system. We really can guess a lot from the emerge --info output. We don't really want to care which package manager you're using, apart from a discrete text. Also, we still get people who just post their paludis --info. Could you please put in *bold letters* at the top of that output that it's not the info they'll need when reporting bugs. Thanks, loki_val
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
On Sat, 4 Apr 2009 15:17:30 +0200 Peter Alfredsen loki_...@gentoo.org wrote: While it may be useful to post all the information about the package-manager for *you*, it's not helping us (bug-wranglers) any. We need one screenfull of text that concisely shows us the state of your system. There is no magic way of determining which bits of information are or are not useful. We really can guess a lot from the emerge --info output. 'guess'. Like how you have to guess what use flags are really being used for the package in question, because it doesn't tell you? Also, we still get people who just post their paludis --info. Could you please put in *bold letters* at the top of that output that it's not the info they'll need when reporting bugs. It's in bright pink at the bottom. If people aren't reading that, tell them to start paying attention or buy a mac. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Real multilib support for Gentoo
On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau to...@gentoo.org wrote: Hi folks, i would like to hear about other opinions about real multilib support within our tree and package managers. From what i know, there are mainly 2 different ideas: The proposals are not exactly these. 1. Make package managers multilib-aware [1][2]. Package managers would be able to have a default ABI (say, x86_64) and optional ones (x86). Everything would be built for the default ABI, and the package manager could build things for optional ABIs on an as needed basis. That is, if I install a 32bit binary package, the package manager will build any 32bit libraries it needs automatically. Package managers will have to expose to ebuilds a mechanism to iterate over enabled ABIs and build anything needed for each one. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - 32bit libraries are built automatically and as needed. - This system can be extended to support other kind of ABIs. Making it possible to build packages for various versions of Python/GHC/etc simultaneously. Cons: - Needs to be implemented on the PM-side and needs a new EAPI. 2. Implement multilib on the ebuild level. For amd64, this would mean adding a 'lib32' USE flag to every multilib ebuild, and use it for building 32bit libs as needed. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - Doesn't need PM changes. Cons: - Package manager won't be multilib-aware, so it won't be able to build 32bit libraries automatically and as needed. - Users will have to enable 'lib32' USE flag manually for every library they needed. Enabling 'lib32' by default is not an option since it would build tons of unneeded 32bit libraries for every user. [1] http://dev.exherbo.org/~pioto/abi-ideas.html [2] http://bugs.gentoo.org/show_bug.cgi?id=145737 Regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] Packages
On Saturday 04 April 2009 13:05:04 Ehret Stefan wrote: Hello I would ask if I can maintainer following packages for the gentoo-amd64 arch. app-crypt/truecrypt What about bug #241650? -- Timothy `Drizzt` Redaelli FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
'guess'. Like how you have to guess what use flags are really being used for the package in question, because it doesn't tell you? i'd like to ask the developers of package managers to standardize this. having packagmanager --info be the same no matter who you like best is incredibly usefull. while we are at it, emerge --info output may or may not be made even more usefull... thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages
Timothy Redaelli wrote: On Saturday 04 April 2009 13:05:04 Ehret Stefan wrote: Hello I would ask if I can maintainer following packages for the gentoo-amd64 arch. app-crypt/truecrypt What about bug #241650? the license seems to be a problem but what is with the other packages?
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Thilo Bangert bang...@gentoo.org wrote: 'guess'. Like how you have to guess what use flags are really being used for the package in question, because it doesn't tell you? i'd like to ask the developers of package managers to standardize this. having packagmanager --info be the same no matter who you like best is incredibly usefull. ++ Please, do it. Even an educated guess is better than nothing, raising the probability bug-wranglers can handle the bug even before it hits other devs' inboxes. -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpEH0FPACq8x.pgp Description: PGP signature
Re: [gentoo-dev] Real multilib support for Gentoo
Santiago M. Mola coldw...@gentoo.org said: On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau to...@gentoo.org wrote: Hi folks, i would like to hear about other opinions about real multilib support within our tree and package managers. From what i know, there are mainly 2 different ideas: The proposals are not exactly these. 1. Make package managers multilib-aware [1][2]. Package managers would be able to have a default ABI (say, x86_64) and optional ones (x86). Everything would be built for the default ABI, and the package manager could build things for optional ABIs on an as needed basis. That is, if I install a 32bit binary package, the package manager will build any 32bit libraries it needs automatically. Package managers will have to expose to ebuilds a mechanism to iterate over enabled ABIs and build anything needed for each one. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - 32bit libraries are built automatically and as needed. - This system can be extended to support other kind of ABIs. Making it possible to build packages for various versions of Python/GHC/etc simultaneously. Cons: - Needs to be implemented on the PM-side and needs a new EAPI. 2. Implement multilib on the ebuild level. For amd64, this would mean adding a 'lib32' USE flag to every multilib ebuild, and use it for building 32bit libs as needed. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - Doesn't need PM changes. Cons: - Package manager won't be multilib-aware, so it won't be able to build 32bit libraries automatically and as needed. - Users will have to enable 'lib32' USE flag manually for every library they needed. Enabling 'lib32' by default is not an option since it would build tons of unneeded 32bit libraries for every user. reading the proposals so far, it sounds to me that only the one that requires pms changes would qualify as 'real multilib support'. [1] http://dev.exherbo.org/~pioto/abi-ideas.html [2] http://bugs.gentoo.org/show_bug.cgi?id=145737 Regards, signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages
On Sat, 04 Apr 2009 16:16:29 +0200 Ehret Stefan eh...@planetpurple.net wrote: Timothy Redaelli wrote: On Saturday 04 April 2009 13:05:04 Ehret Stefan wrote: Hello I would ask if I can maintainer following packages for the gentoo-amd64 arch. app-crypt/truecrypt What about bug #241650? the license seems to be a problem but what is with the other packages? I don't think the truecrypt license is a problem if we treat the package as in my Comment 11. There are/have been a few other packages where we require each user to fetch the source individually, and I think that is the main issue here, too. Each user must be aware of the license because of some restrictions on repackaging or redistribution. We do not distribute the package at all --- we provide a means to build it and install it (when we require the user to fetch the source). At one time, at least, the sun java distribution was like this, and as I said, I think there are others. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
Jeremy Olexa wrote:
So, my recommendation is to:
1) mask the prefix USE flag in base/use.mask because no one except the
prefix profiles should use this flag.
2) unmask and force the USE flag in prefix profile.
3) add entry to use.desc.
addendum) use.{mask,force} imply that the USE flag is explicit so
there will be no QA warnings.
However, we have toyed with other ideas. One of which is to introduce
IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I
don't really like this idea because it exposes the use flag and we
don't want it exposed to the users.
Note that there are some changes in this area planned for EAPI 3.
Install app-doc/pms- with USE=eapi3-draft and see section
4.3.2 which says that there will be a new USE_EXPAND_UNPREFIXED
variable which you can use (it's only coincidental that your flag
happens to be called 'prefix' and the new variable contains PREFIX
in its name). It also says you'll be able to add your flag to
USE_EXPAND_HIDDEN so that it's not exposed to users.
Actually, after further inspection of PMS, it seems that the
IUSE_IMPLICIT is more appropriate for the 'prefix' flag since it
doesn't seem to fit into the USE_EXPAND paradigm.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAknXsucACgkQ/ejvha5XGaO5KACg2Ay3wM5joo4tr2mAuShFBXSm
tWwAoMrpEhrBIou8fO5fGPR0AN7G89LT
=Iw82
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 04 Apr 2009 12:20:09 -0700 Zac Medico zmed...@gentoo.org wrote: Actually, after further inspection of PMS, it seems that the IUSE_IMPLICIT is more appropriate for the 'prefix' flag since it doesn't seem to fit into the USE_EXPAND paradigm. Were we after keeping IUSE_IMPLICIT? That whole part is still fairly vague, since I'm not sure what Portage is going to be able to do with it in time for EAPI 3. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknXs5wACgkQ96zL6DUtXhEgvQCfdqWrdFdr0RK5zbdkgsb6/gZI ouQAoLHPSh3Ak+sdpc5KagnDMKu+KqN7 =SSd8 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: Fabian Groffen wrote: On 04-04-2009 15:21:23 +0300, Petteri Räty wrote: You can set USERLAND=GNU PREFIX Prefix is not a userland, please understand that. It's like pizza not being an elibc, or beer not being a kernel. Sure it's not a user land like GNU or BSD but I can't see why we couldn't change what USERLAND means. But why change the meaning if it's confusing an unnecessary? Perhaps it's more appropriate to set IUSE_IMPLICIT=prefix. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknXs+8ACgkQ/ejvha5XGaMyewCcD+FLwOKxRN35wmUGeUZmvg+l NDwAoMxK+MkjQO6ehHUjs5BAIu6tnq8+ =h5Hx -END PGP SIGNATURE-
[gentoo-dev] Re: News item review: X.org server upgrade
Hi, Petteri Räty betelge...@gentoo.org: Christian Faulhammer wrote: Hi, please see attached news item for review. V-Li s/emerging/updating/ Fixed. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
Zac Medico wrote: Petteri Räty wrote: Fabian Groffen wrote: On 04-04-2009 15:21:23 +0300, Petteri Räty wrote: You can set USERLAND=GNU PREFIX Prefix is not a userland, please understand that. It's like pizza not being an elibc, or beer not being a kernel. Sure it's not a user land like GNU or BSD but I can't see why we couldn't change what USERLAND means. But why change the meaning if it's confusing an unnecessary? Perhaps it's more appropriate to set IUSE_IMPLICIT=prefix. I wasn't saying we should. I just said it can be used to solve the problem. If prefix people are fine with having to be confined to EAPI 3, then I have no problem with that. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sat, 04 Apr 2009 12:20:09 -0700 Zac Medico zmed...@gentoo.org wrote: Actually, after further inspection of PMS, it seems that the IUSE_IMPLICIT is more appropriate for the 'prefix' flag since it doesn't seem to fit into the USE_EXPAND paradigm. Were we after keeping IUSE_IMPLICIT? That whole part is still fairly vague, since I'm not sure what Portage is going to be able to do with it in time for EAPI 3. Well, portage already supports the notion of IUSE_IMPLICIT internally, so it won't be much work to modify it to support whatever changes we decide to do in EAPI 3 (if any). - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknXt+8ACgkQ/ejvha5XGaNVQgCgkVtqb9+7gnvtVPjc8OaJexAh txAAn32l6SWtt2eUJ5Zzfjmcx9urrnxe =gash -END PGP SIGNATURE-
[gentoo-dev] Re: News item for review: teTeX deprecation
Hi, Heath N. Caldwell hncaldw...@gentoo.org: How about: teTeX is obsolete and has been unsupported upstream since May of 2006. All users who still have teTex installed should uninstall it and install TeXLive using the upgrade guide accessible at the following URL: http://www.gentoo.org/proj/en/tex/texlive-migration-guide.xml Nice enough. Taken. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: best way to introduce USE=prefix
On 04-04-2009 20:41:34 +0100, Ciaran McCreesh wrote: The two aren't mutually contradictory. Quite the contrary. For EAPI 3, we're aiming to make it illegal to do anything with a flag unless it's either explicitly listed in IUSE or handled via a number of special magic profile variables, so you'd either have to list it everywhere or use one of the profile variables. Once you do that, how you mask / force it is up to you, unless you need some kind of special package manager handling for that flag. Sounds to me it would be ok then to add it now in use.mask, and then EAPI 3 is done, define it in whatever special variable it needs to be added to according to the specs then. IUSE_IMPLICIT -- assuming it can be defined in the profiles -- seems like a good way to prepare for that, since it makes explicit it is implicit, IMO. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] News item for review: teTeX deprecation (repost)
Hi, Repost of news item as I forgot to cc the PR project. Commit postponed by one day. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ Title: Migration from teTeX to TeXLive Author: Christian Faulhammer fa...@gentoo.org Author: Ulrich Müller u...@gentoo.org Author: Alexis Ballier aball...@gentoo.org Content-Type: text/plain Posted: 2009-04-06 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-text/tetex teTeX is obsolete and has been unsupported upstream since May of 2006. All users who still have teTex installed should uninstall it and install TeXLive using the upgrade guide accessible at the following URL: http://www.gentoo.org/proj/en/tex/texlive-migration-guide.xml signature.asc Description: PGP signature
[gentoo-dev] News item review: X.org server 1.5 stable (repost)
Hi, Repost of news item as I forgot to cc the PR project. Commit postponed by one day. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Sat, 04 Apr 2009 17:57:54 +
Fabian Groffen (grobian) grob...@gentoo.org wrote:
grobian 09/04/04 17:57:54
Modified: flag-o-matic.eclass
Log:
backport fix for x86-macos in filter-flags from Prefix
Revision ChangesPath
1.133eclass/flag-o-matic.eclass
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.133view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.133content-type=text/plain
diff :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.132r2=1.133
Index: flag-o-matic.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- flag-o-matic.eclass 21 Jan 2009 00:42:20 - 1.132
+++ flag-o-matic.eclass 4 Apr 2009 17:57:54 - 1.133
@@ -1,6 +1,6 @@
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v 1.132
2009/01/21 00:42:20 gengor Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v 1.133
2009/04/04 17:57:54 grobian Exp $
# @ECLASS: flag-o-matic.eclass
# @MAINTAINER:
@@ -52,6 +52,12 @@
-m32 -m64 -mabi -mlittle-endian -mbig-endian -EL -EB -fPIC \
-mlive-g0 -mcmodel -mstack-bias -mno-stack-bias \
-msecure-plt -m*-toc -D* -U*
+
+ # killing these two on OSX/Intel will disable SSE, resulting in failing
+ # compilations, as the headers expect SSE to be enabled (Apple knows
what
+ # hardware they run on afterall, don't they?)
+ [[ ${CHOST} == i?86-apple-darwin* ]] \
+ ALLOWED_FLAGS=${ALLOWED_FLAGS} -march=prescott
-march=nocona
Why do these have to be specifically included? Aren't they handed by
34 export ALLOWED_FLAGS=${ALLOWED_FLAGS} -O -O0 -O1 -O2 -mcpu -march
-mtune
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: toolchain-funcs.eclass
On Saturday 04 April 2009 13:17:56 Fabian Groffen (grobian) wrote:
grobian 09/04/04 17:17:56
Modified: toolchain-funcs.eclass
Log:
Add support for all Prefix arches, in particular for gen_usr_ld_script,
and add AIX specific function, backport from Prefix
you really should have posted this to the toolchain alias before committing.
and done a whitespace check as there's incorrect mixing of leading
spaces/tabs, as well as trailing whitespace.
+ powerpc-apple-darwin*)
+ echo ppc-macos;;
these should all be on one line each
+ # Ensure /lib/${lib} exists to avoid dangling scripts/symlinks.
+ # This especially is for AIX where $(get_libname) can return
.a,
+ # so /lib/${lib} might be moved to /usr/lib/${lib} (by
accident).
+ [[ -r ${ED}/${libdir}/${lib} ]] || continue
the quotes are useless. i'm assuming ${ED} is like ${D} and you're not
reading stuff in / here.
+ *-mint*)
+ # do nothing
+ return
+ ;;
this really should be at the top of the function ... doing a case statement
inside of the for loop implies that any targets that have made it that far are
sane.
+# This function is for AIX only.
+#
+# Showing a sample IMO is the best description:
there is a documentation format for eclasses you should have used here
+ local sources=$@
this doesnt do what you think it does. it's the same as $* which means this
function does not handle quoted arguments properly.
+ local tmpdir=${TMP}/keep_aix_runtime_object-$$
+ mkdir ${tmpdir} || die
eutils already provides a function to create a temp dir
+ local origdir=$(pwd)
+ ...
+ cd ${origdir}
pushd/popd exist for a reason
+ cd ${tmpdir} || die
changing into the dir in every iteration of the loop is pointless
+ chmod +w ${so}
+ $(tc-getSTRIP) -e ${so}
+ $(tc-getAR) -q ${ED}${target} ${so}
+ eend 0 ||
+ eend 1
everything after the chmod really needs to be intended
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Real multilib support for Gentoo
On Saturday 04 April 2009 08:59:22 Thomas Sachau wrote: i would like to hear about other opinions about real multilib support within our tree and package managers. From what i know, there are mainly 2 different ideas: 1. Do the main stuff in the package manager (e.g. if the ARCH is amd64 and the package has x86 keyword, the package manager adds a lib32 useflag, which would additionally install the 32bit variant of that package together with the normal 64bit install). pro: -much lesser work for package maintainers contra: -needs addition in PMS and support in the pms, which will need some work on their side get a *working* implementation first and *then* worry about specing it. once you have something running with portage, the spec should fall naturally out. previous multilib methods attempted to spec things out without any real code and they've all just died. 2. Do the main stuff in the ebuilds themselves (e.g. an additional eclass multilib-native.eclass, any ebuild with 32bit support would then need adaption and of course inheriting that eclass) this is dead end and useless overhead, and i would reject it from any core package someone would try to merge. -mike signature.asc Description: This is a digitally signed message part.
