[gentoo-dev] Lastrite: x11-misc/mkxf86config
# Samuli Suominen (28 Jan 2013) # Uncompatible with current udev and baselayout # Bug 220121 and the ones it Blocks # Removal in 30 days x11-misc/mkxf86config
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 28 January 2013 12:37, Mike Frysinger wrote:
> On Sunday 27 January 2013 13:21:27 Pacho Ramos wrote:
>> The problem is that it doesn't work so well. If I have the following at
>> src_prepare (for example):
>> src_prepare() {
>> DOC_CONTENTS="You must create a symlink rom /etc/splash/tuxonice
>> to the theme you want tuxonice to use, e.g.: \n
>> # ln -sfn /etc/splash/emergence /etc/splash/tuxonice
>> \n"
>> ...
>>
>> and I handle ${DOC_CONTENTS} with quotes, it will end writing that tabs
>> also in generated file as the contents of the variable will be put
>> as-is. On the other hand, if I don't put it between quotes
>
> forcibly normalizing whitespace for all callers is wrong imo (as is sending it
> through `fmt`). if the caller gave you content to write, it should write it.
> if the caller didn't want tabs, it shouldn't have used it in the first place.
> -mike
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 08:06:48PM +0100, Felix Kuperjans wrote: > Mike Gilbert: > > On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans > > wrote: > >> Samuli Suominen wrote: > >>> please review this news item, seems we need one after all > >> Hello Samuli, > >> > >> /dev/root is no longer available in this udev version, so people who put > >> this in their /etc/fstab might end up with an unbootable system. > >> > >> I suggest including in the news item, that /dev/root must be replaced > >> with the actual root device or LABEL=..., UUID=... and the like in > >> /etc/fstab. > >> > > fstab is not consulted for mounting the root filesystem, so it doesn't > > really matter what you have in there. Either the kernel mounts it > > based on the kernel command line, or your initramfs mounts it based on > > whatever your /init programs does. > Well, *if* a line with /dev/root is present in /etc/fstab, the system > does not boot up properly (tested it right now). > I always though such a line in /etc/fstab is needed so that fsck is run > on the root filesystem... That was an example in the fstab in the stages, but the handbook always told you to replace /dev/root with the reference to the specific root device. William pgpWHehg7YGMy.pgp Description: PGP signature
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On Sunday 27 January 2013 13:21:27 Pacho Ramos wrote:
> The problem is that it doesn't work so well. If I have the following at
> src_prepare (for example):
> src_prepare() {
> DOC_CONTENTS="You must create a symlink rom /etc/splash/tuxonice
> to the theme you want tuxonice to use, e.g.: \n
> # ln -sfn /etc/splash/emergence /etc/splash/tuxonice \n"
> ...
>
> and I handle ${DOC_CONTENTS} with quotes, it will end writing that tabs
> also in generated file as the contents of the variable will be put
> as-is. On the other hand, if I don't put it between quotes
forcibly normalizing whitespace for all callers is wrong imo (as is sending it
through `fmt`). if the caller gave you content to write, it should write it.
if the caller didn't want tabs, it shouldn't have used it in the first place.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/abs-guide: metadata.xml ChangeLog
On Sun, Jan 27, 2013 at 7:34 PM, Ryan Hill wrote: > On Sun, 27 Jan 2013 19:16:56 -0500 > Mike Gilbert wrote: > >> > If you have some kind of problem with this, I suggest you change the >> > default >> > output of metagen. >> > >> >> Seems to work just fine here. What options are you using? >> >> floppym@naomi ~ % metagen -H app-doc >> >> >> http://www.gentoo.org/dtd/metadata.dtd";> >> >> app-doc >> > > Well I'll be damned. I guess you can't trust --help output. > I guess you are referring to this: -H HERD Name of herd. If not specified, It will be empty. This requires either the -e or -m option. Which could be interpreted to mean that -H must also be accompanied by -e or -m. I think the sentence is supposed to mean that if -H is NOT specified, you must specify -e or -m.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-01-27 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-01-27 23h59 UTC. Removals: app-admin/busybox-sysklogd 2013-01-22 17:54:31 vapier net-misc/busybox-ntpd 2013-01-22 17:55:00 vapier sys-apps/busybox-watchdog 2013-01-22 17:55:35 vapier Additions: dev-python/fixtures 2013-01-21 08:30:51 prometheanfire dev-python/colorama 2013-01-21 08:51:49 prometheanfire dev-python/termcolor2013-01-21 08:57:26 prometheanfire dev-python/openstack-nose-plugin2013-01-21 09:01:41 prometheanfire dev-python/nosehtmloutput 2013-01-21 09:23:22 prometheanfire dev-python/python-cinderclient 2013-01-21 09:24:00 prometheanfire media-sound/projectm-pulseaudio 2013-01-21 20:30:10 scarabeus dev-python/pdfrw2013-01-22 16:34:23 floppym dev-perl/CPAN-Meta-Check2013-01-22 18:55:27 tove dev-perl/Test-CheckDeps 2013-01-22 18:56:19 tove virtual/pmw 2013-01-22 19:23:53 jlec net-misc/rancid 2013-01-22 23:08:39 xmw sys-power/cpupower 2013-01-23 17:10:15 ssuominen dev-python/sh 2013-01-24 01:48:27 chutzpah net-wireless/hidclient 2013-01-24 02:03:20 zerochaos dev-libs/leveldb2013-01-24 06:34:12 patrick dev-libs/replicant 2013-01-24 06:37:51 patrick sys-apps/proot 2013-01-24 08:54:46 pinkbyte app-crypt/easy-rsa 2013-01-24 09:49:12 djc www-client/weboob 2013-01-25 08:31:16 patrick media-libs/soxr 2013-01-25 10:34:21 aballier dev-ruby/acts_as_list 2013-01-25 20:01:43 flameeyes dev-ruby/rails_autolink 2013-01-25 20:50:24 flameeyes dev-ruby/flickraw 2013-01-25 21:03:25 flameeyes dev-python/wsgiref 2013-01-26 05:53:15 prometheanfire dev-python/setuptools-git 2013-01-26 06:26:32 prometheanfire sys-cluster/cinder 2013-01-26 06:27:21 prometheanfire dev-python/cmd2 2013-01-26 08:01:43 prometheanfire dev-python/cliff2013-01-26 08:05:01 prometheanfire dev-python/python-quantumclient 2013-01-26 08:06:56 prometheanfire sys-cluster/quantum 2013-01-26 08:58:44 prometheanfire sys-cluster/nova2013-01-26 09:18:28 prometheanfire sec-policy/selinux-googletalk 2013-01-26 15:19:31 swift media-video/photofilmstrip 2013-01-26 18:00:25 hwoarang gnome-extra/cameramonitor 2013-01-26 20:11:44 hwoarang net-libs/libflowmanager 2013-01-27 06:21:48 radhermit net-libs/libprotoident 2013-01-27 06:28:09 radhermit app-vim/pathogen2013-01-27 12:11:40 radhermit games-board/awale 2013-01-27 19:20:44 hasufell -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-admin/busybox-sysklogd,removed,vapier,2013-01-22 17:54:31 net-misc/busybox-ntpd,removed,vapier,2013-01-22 17:55:00 sys-apps/busybox-watchdog,removed,vapier,2013-01-22 17:55:35 Added Packages: dev-python/fixtures,added,prometheanfire,2013-01-21 08:30:51 dev-python/colorama,added,prometheanfire,2013-01-21 08:51:49 dev-python/termcolor,added,prometheanfire,2013-01-21 08:57:26 dev-python/openstack-nose-plugin,added,prometheanfire,2013-01-21 09:01:41 dev-python/nosehtmloutput,added,prometheanfire,2013-01-21 09:23:22 dev-python/python-cinderclient,added,prometheanfire,2013-01-21 09:24:00 media-sound/projectm-pulseaudio,added,scarabeus,2013-01-21 20:30:10 dev-python/pdfrw,added,floppym,2013-01-22 16:34:23 dev-perl/CPAN-Meta-Check,added,tove,2013-01-22 18:55:27 dev-perl/Test-CheckDeps,added,tove,2013-01-22 18:56:19 virtual/pmw,added,jlec,2013-01-22 19:23:53 net-misc/rancid,added,xmw,2013-01-22 23:08:39 sys-power/cpupower,added,ssuominen,2013-01-23 17:10:15 dev-python/sh,added,chutzpah,2013-01-24 01:48:27 net-wireless/hidclient,added,zerochaos,2013-01-24 02:03:20 dev-libs/leveldb,added,patrick,2013-01-24 06:34:12 dev-libs/replicant,added,patrick,2013-01-24 06:37:51 sys-apps/proot,added,pinkbyte,2013-01-24 08:54:46 app-crypt/easy-rsa,added,djc,2013-01-24 09:49:12 www-client/weboob,added,patrick,2013-01-25 08:31:16 media-libs/soxr,added,aballier,2013-01-25 10:34:21 dev-ruby/acts_as_list,added,flameeyes,2013-01-25 20:01:43 dev-ruby/rails_autolink,added,flameeyes,2013-01-25 20:50:24 dev-ruby/flickraw,added,flameeyes,2013-01-25 21:03:25 dev-python/
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/abs-guide: metadata.xml ChangeLog
On Sun, 27 Jan 2013 19:16:56 -0500 Mike Gilbert wrote: > > If you have some kind of problem with this, I suggest you change the default > > output of metagen. > > > > Seems to work just fine here. What options are you using? > > floppym@naomi ~ % metagen -H app-doc > > > http://www.gentoo.org/dtd/metadata.dtd";> > > app-doc > Well I'll be damned. I guess you can't trust --help output. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/abs-guide: metadata.xml ChangeLog
On Sun, Jan 27, 2013 at 6:06 PM, Ryan Hill wrote: > On Sun, 27 Jan 2013 22:27:20 + (UTC) > "Tim Harder (radhermit)" wrote: > >> radhermit13/01/27 22:27:20 >> >> Modified: metadata.xml ChangeLog >> Log: >> Remove redundant maintainer from metadata. >> >> (Portage version: 2.2.0_alpha161/cvs/Linux x86_64, signed Manifest commit >> with key 4AB3E85B4F064CA3) >> >> Revision ChangesPath >> 1.7 app-doc/abs-guide/metadata.xml >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-doc/abs-guide/metadata.xml?rev=1.7&view=markup >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-doc/abs-guide/metadata.xml?rev=1.7&content-type=text/plain >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-doc/abs-guide/metadata.xml?r1=1.6&r2=1.7 >> >> Index: metadata.xml >> === >> RCS file: /var/cvsroot/gentoo-x86/app-doc/abs-guide/metadata.xml,v >> retrieving revision 1.6 >> retrieving revision 1.7 >> diff -u -r1.6 -r1.7 >> --- metadata.xml 26 Jun 2012 04:57:50 - 1.6 >> +++ metadata.xml 27 Jan 2013 22:27:19 - 1.7 >> @@ -1,8 +1,5 @@ >> >> http://www.gentoo.org/dtd/metadata.dtd";> >> >> - app-doc >> - >> - app-...@gentoo.org >> - >> +app-doc >> > > > If you have some kind of problem with this, I suggest you change the default > output of metagen. > Seems to work just fine here. What options are you using? floppym@naomi ~ % metagen -H app-doc http://www.gentoo.org/dtd/metadata.dtd";> app-doc
Re: [gentoo-dev] [PATCH 2/5] Use explicit abi_* flags to select multilib targets.
On Sun, 27 Jan 2013 23:46:06 +0100 Michał Górny wrote: > Alexis, > > Following your remark, I have redesigned the loop to use MULTILIB_ABIS > list to order the ABIs. This should ensure the most valid replacement > order. Great, that's better than what I had thought about > Additionally, I have added an assertion to ensure that DEFAULT_ABI > comes last in MULTILIB_ABIS list. I'm not sure it is a good idea: it is certainly safe, but this removes the flexibility not to build for the DEFAULT_ABI. Not sure if it's sane to do so or if there is any usecase either, but since get_all_abis ensures us DEFAULT_ABI is last I don't see a need to double check it here. Alexis.
Re: [gentoo-dev] splashutils needs a maintainer
On 27.01.2013 23:06, Pacho Ramos wrote: > With spock retirement, splashutils became orphan. The problem is that it > has a lot of unresolved bugs for a long time: > https://bugs.gentoo.org/buglist.cgi?quicksearch=splashutils&list_id=1521218 > > that would need someone with more knowledge about it to maintain it (as > I don't have splash on my systems for years). > > Also looks like splashutils is no more developed, but I don't know if we > have a proper replacement for it in gentoo (most distributions are > moving to plymouth, but I haven't tried if it works ok on Gentoo) We have it, it works (or at least worked). Someone would need to implement it in genkernel initrds though as at the moment only dracut can handle it. In terms of package maintenance, I took the package from aidecoe when he dropped it to avoid it getting removed. People seem to have found issues in there now and it could use a bump. As I cannot boot my systems using dracut initrds right now, feel free to take the package (and the openrc plugin for it) and fix/bump/do whatever with it. > > Thanks for your help > -- Alex Legler Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/abs-guide: metadata.xml ChangeLog
On Sun, 27 Jan 2013 22:27:20 + (UTC) "Tim Harder (radhermit)" wrote: > radhermit13/01/27 22:27:20 > > Modified: metadata.xml ChangeLog > Log: > Remove redundant maintainer from metadata. > > (Portage version: 2.2.0_alpha161/cvs/Linux x86_64, signed Manifest commit > with key 4AB3E85B4F064CA3) > > Revision ChangesPath > 1.7 app-doc/abs-guide/metadata.xml > > file : > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-doc/abs-guide/metadata.xml?rev=1.7&view=markup > plain: > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-doc/abs-guide/metadata.xml?rev=1.7&content-type=text/plain > diff : > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-doc/abs-guide/metadata.xml?r1=1.6&r2=1.7 > > Index: metadata.xml > === > RCS file: /var/cvsroot/gentoo-x86/app-doc/abs-guide/metadata.xml,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- metadata.xml 26 Jun 2012 04:57:50 - 1.6 > +++ metadata.xml 27 Jan 2013 22:27:19 - 1.7 > @@ -1,8 +1,5 @@ > > http://www.gentoo.org/dtd/metadata.dtd";> > > - app-doc > - > - app-...@gentoo.org > - > +app-doc > If you have some kind of problem with this, I suggest you change the default output of metagen. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/5] Use explicit abi_* flags to select multilib targets.
Alexis, Following your remark, I have redesigned the loop to use MULTILIB_ABIS list to order the ABIs. This should ensure the most valid replacement order. Additionally, I have added an assertion to ensure that DEFAULT_ABI comes last in MULTILIB_ABIS list.
[gentoo-dev] [PATCH 2/2] Add an assertion for valid ABI order.
---
gx86/eclass/multilib-build.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index 96bf26f..ed8ee23 100644
--- a/gx86/eclass/multilib-build.eclass
+++ b/gx86/eclass/multilib-build.eclass
@@ -66,6 +66,10 @@ multilib_get_enabled_abis() {
local abis=( $(get_all_abis) )
+ if [[ ${abis[-1]} != ${DEFAULT_ABI} ]]; then
+ die "Assertion failed: DEFAULT_ABI (${DEFAULT_ABI}) != last ABI
(${abis[-1]})"
+ fi
+
local abi i found
for abi in "${abis[@]}"; do
for i in "${_MULTILIB_FLAGS[@]}"; do
--
1.8.1.1
[gentoo-dev] [PATCH 1/2] Order ABIs following MULTILIB_ABIS.
This ensures that profile order is preserved.
---
gx86/eclass/multilib-build.eclass | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index a6104e0..96bf26f 100644
--- a/gx86/eclass/multilib-build.eclass
+++ b/gx86/eclass/multilib-build.eclass
@@ -64,16 +64,19 @@ _multilib_build_set_globals
multilib_get_enabled_abis() {
debug-print-function ${FUNCNAME} "${@}"
- local supported_abis=$(get_all_abis)
- local i found
- for i in "${_MULTILIB_FLAGS[@]}"; do
- local abi=${i#*:}
- local flag=${i%:*}
-
- if has "${abi}" ${supported_abis} && use "${flag}"; then
- echo "${abi}"
- found=1
- fi
+ local abis=( $(get_all_abis) )
+
+ local abi i found
+ for abi in "${abis[@]}"; do
+ for i in "${_MULTILIB_FLAGS[@]}"; do
+ local m_abi=${i#*:}
+ local m_flag=${i%:*}
+
+ if [[ ${m_abi} == ${abi} ]] && use "${m_flag}"; then
+ echo "${abi}"
+ found=1
+ fi
+ done
done
if [[ ! ${found} ]]; then
--
1.8.1.1
[gentoo-dev] splashutils needs a maintainer
With spock retirement, splashutils became orphan. The problem is that it has a lot of unresolved bugs for a long time: https://bugs.gentoo.org/buglist.cgi?quicksearch=splashutils&list_id=1521218 that would need someone with more knowledge about it to maintain it (as I don't have splash on my systems for years). Also looks like splashutils is no more developed, but I don't know if we have a proper replacement for it in gentoo (most distributions are moving to plymouth, but I haven't tried if it works ok on Gentoo) Thanks for your help signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On 01/27/2013 03:26 AM, Pacho Ramos wrote: > El dom, 27-01-2013 a las 00:26 +0100, Andreas K. Huettel escribió: >> Just to keep everyone updated, ... >> >>> FYI, the new 13.0 profiles are now all available in profiles.desc, for now >>> all with status "dev" (i.e. repoman includes them only when you request >>> developer profile checking). >>> >>> This means the procedure below is complete up to and including point 5) >>> now. >>> >>> Please consider changing your profile symlink manually and testing the new >>> profile tree. In case of problems, please file a bug and assign it to me >>> (or tell me if I'm around). >>> >>> If all goes well, we'll continue in a week. >>> >> >> A small bug in repoman turned up when testing the EAPI=5 profiles, and >> therefore we will wait for the next stable portage version before the 10.0 >> profiles are deprecated. So, another 3-4 weeks to go maybe. >> >> [The only alternative would be to require all devs to run at least ~arch >> portage, since the bug only affects repoman, not emerge.] >> >> Cheers, >> Andreas >> > > Maybe other option would be to have a portage version like current > stable + repoman fix and fast stabilize as soon as possible I think the latest portage release (2.1.11.50) should be fine. It has lots of other fixes that will be nice to have in stable. I plan to file a stable request in about 1.5 weeks. -- Thanks, Zac
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, 27 Jan 2013 11:14:27 -0800 Matt Turner wrote: > On Sun, Jan 27, 2013 at 7:12 AM, Michał Górny wrote: > > 5. Solutions to specific problems > > - > > > > 1. x11-proto packages > > > > Those packages install headers to /usr/include and pkg-config files > > to /usr/lib64. This supposedly means that the headers could be > > ABI-specific; however, so far I haven't seen a single difference. > > > > Possible solutions: > > > > a) check the headers by hand, move pkg-config files to /usr/share, > > > > b) make the proto packages multilib. This will cause identical .pc > >files to be installed to lib32 & lib64 but will also enable eclass > >checks for header consistency. > > See http://lists.x.org/archives/xorg-devel/2012-September/033715.html > > In short, there seem to be a couple cases of platform-dependent > substitutions in headers, but for the most part they're platform > independent. Yes, I have seen the substitutions but so far, it seems that they give the same values for both amd64 ABIs. I'm not sure if other platforms have the same characteristics. I'd prefer just using b) now and getting back to this whenever the header check starts to fail for some platform. Then we would have to move the headers. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, Jan 27, 2013 at 7:12 AM, Michał Górny wrote: > 5. Solutions to specific problems > - > > 1. x11-proto packages > > Those packages install headers to /usr/include and pkg-config files > to /usr/lib64. This supposedly means that the headers could be > ABI-specific; however, so far I haven't seen a single difference. > > Possible solutions: > > a) check the headers by hand, move pkg-config files to /usr/share, > > b) make the proto packages multilib. This will cause identical .pc >files to be installed to lib32 & lib64 but will also enable eclass >checks for header consistency. See http://lists.x.org/archives/xorg-devel/2012-September/033715.html In short, there seem to be a couple cases of platform-dependent substitutions in headers, but for the most part they're platform independent.
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
On 27.01.2013 18:26, Mike Frysinger wrote: > On Friday 25 January 2013 18:51:44 Mike Frysinger wrote: >> i've taken Constanze' work and rewritten it a bit to be easier to use (imo) >> as most settings are now defaults > > merged. i'll move iputils over to it first and if there aren't any problems, > i'll move more over to it. > -mike Could you also add 'filecaps' to use.desc, please? Kacper signature.asc Description: OpenPGP digital signature
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El dom, 27-01-2013 a las 13:05 -0500, Mike Frysinger escribió:
> On Sunday 27 January 2013 12:47:28 Pacho Ramos wrote:
> > El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió:
> > > Currently, when people uses DOC_CONTENTS variable to place their desired
> > > messages, they are automatically reformatted by "fmt" to get proper
> > > messages (for example, splitting long lines).
> > >
> > > But, in some cases, may be useful to disable this behavior and respect
> > > strictly how DOC_CONTENTS was formatted, for example in that kind of
> > > messages telling people to run a command and, then, requiring a new line
> > > to be used. This can also be useful to append extra information to
> > > DOC_CONTENTS when, for example, additional info is needed when enabling
> > > a USE flag.
> >
> > Well, after reading man echo I see all this is not needed, I simply need
> > to use echo -e to get it understand "\n" to create new lines
>
> printf '%b' "${foo}"
> -mike
The problem is that it doesn't work so well. If I have the following at
src_prepare (for example):
src_prepare() {
DOC_CONTENTS="You must create a symlink rom /etc/splash/tuxonice
to the theme you want tuxonice to use, e.g.: \n
# ln -sfn /etc/splash/emergence /etc/splash/tuxonice \n"
...
and I handle ${DOC_CONTENTS} with quotes, it will end writing that tabs
also in generated file as the contents of the variable will be put
as-is. On the other hand, if I don't put it between quotes and, later,
pass "fmt", it will be formatted properly, without tabs and jumping to a
new line when \n is passed. In this way, echo will output a long line
with all the contents jumping to a new line when \n is found and, later,
fmt does the formatting.
But, if I use printf instead of echo:
1. If I put the variable with quotes it will be printed as-is (with
tabs).
2. If I drop the quotes, all spaces are dropped and end up with
something like:
Youmustcreateasymlinkfrom/etc/splash/tuxonicetothethemeyou
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, 27 Jan 2013 21:04:14 +0300
Sergei Trofimovich wrote:
> On Sun, 27 Jan 2013 17:30:22 +0100
> Michał Górny wrote:
>
> > On Sun, 27 Jan 2013 16:07:48 +
> > Ciaran McCreesh wrote:
> >
> > > On Sun, 27 Jan 2013 16:12:37 +0100
> > > Michał Górny wrote:
> > > >RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > > >dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> > >
> > > This looks like it might be a bit fragile. Is it something better
> > > addressed by an EAPI extension?
> >
> > I have no idea. This one's clear and simple. Not sure how you could be
> > able to do that better in EAPI.
>
> EAPI might allow lib[multiple?][use?][flags?] as an alias of
> [multiple?,use?,flags?].
I still don't think that would be really helpful.
dev-libs/libfoo[ssl][${MULTILIB_USEDEP}]
is IMO just more confusing than the usual [ssl,...] -- people start
thinking 'does it mean something special?'
Unless you mean adding the brackets to the variable itself -- but that
will be just scary...
dev-libs/libfoo${MULTILIB_USEDEP}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On Sunday 27 January 2013 12:47:28 Pacho Ramos wrote:
> El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió:
> > Currently, when people uses DOC_CONTENTS variable to place their desired
> > messages, they are automatically reformatted by "fmt" to get proper
> > messages (for example, splitting long lines).
> >
> > But, in some cases, may be useful to disable this behavior and respect
> > strictly how DOC_CONTENTS was formatted, for example in that kind of
> > messages telling people to run a command and, then, requiring a new line
> > to be used. This can also be useful to append extra information to
> > DOC_CONTENTS when, for example, additional info is needed when enabling
> > a USE flag.
>
> Well, after reading man echo I see all this is not needed, I simply need
> to use echo -e to get it understand "\n" to create new lines
printf '%b' "${foo}"
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, 27 Jan 2013 17:30:22 +0100
Michał Górny wrote:
> On Sun, 27 Jan 2013 16:07:48 +
> Ciaran McCreesh wrote:
>
> > On Sun, 27 Jan 2013 16:12:37 +0100
> > Michał Górny wrote:
> > >RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > >dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> >
> > This looks like it might be a bit fragile. Is it something better
> > addressed by an EAPI extension?
>
> I have no idea. This one's clear and simple. Not sure how you could be
> able to do that better in EAPI.
EAPI might allow lib[multiple?][use?][flags?] as an alias of
[multiple?,use?,flags?].
--
Sergei
signature.asc
Description: PGP signature
readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió:
> Currently, when people uses DOC_CONTENTS variable to place their desired
> messages, they are automatically reformatted by "fmt" to get proper
> messages (for example, splitting long lines).
>
> But, in some cases, may be useful to disable this behavior and respect
> strictly how DOC_CONTENTS was formatted, for example in that kind of
> messages telling people to run a command and, then, requiring a new line
> to be used. This can also be useful to append extra information to
> DOC_CONTENTS when, for example, additional info is needed when enabling
> a USE flag.
>
>
Well, after reading man echo I see all this is not needed, I simply need
to use echo -e to get it understand "\n" to create new lines
New patch attached
--- /home/pacho/gentoo-x86/eclass/readme.gentoo.eclass 2013-01-24 22:38:41.0 +0100
+++ /usr/portage/eclass/./readme.gentoo.eclass 2013-01-27 18:41:40.0 +0100
@@ -53,7 +53,7 @@
if [[ -n "${DOC_CONTENTS}" ]]; then
eshopts_push
set -f
- echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
+ echo -e ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
eshopts_pop
dodoc "${T}"/README.gentoo
else
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
On Friday 25 January 2013 18:51:44 Mike Frysinger wrote: > i've taken Constanze' work and rewritten it a bit to be easier to use (imo) > as most settings are now defaults merged. i'll move iputils over to it first and if there aren't any problems, i'll move more over to it. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d
On 27/01/13 18:00, Rich Freeman wrote: On Sun, Jan 27, 2013 at 10:08 AM, Samuli Suominen wrote: I see a lot of packages installing /etc/modprobe.d when it should be treated like /etc/udev, so only generated files and users own files On a related note, I just noticed that /etc/udev is loaded with orphans in my case, and I can't imagine I'm the only one. When we make moves like this we should include either news items or elogs or something to tell users to clean out the cruft, otherwise config protection tends to leave it there, and then users fail to get updates since their cruft overrides them. I assume that files that aren't user-edited can just be safely deleted? I don't have anything there myself; only had 80-net-name-slot.rules and wanted new networking scheme so deleted that one too. Most certainly 70-persistent-* cruft can go if you haven't edited them yourself. What else do you have? Currently the postinst messages of udev cover these two cases of 70- files, -cd.rules and -net.rules And you are right, if they are not user edited then they can go. There is no "rule_generator" anymore in new udev so there shouldn't be any generated files anymore either, AFAIK
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, 27 Jan 2013 16:07:48 +
Ciaran McCreesh wrote:
> On Sun, 27 Jan 2013 16:12:37 +0100
> Michał Górny wrote:
> >RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> >dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
>
> This looks like it might be a bit fragile. Is it something better
> addressed by an EAPI extension?
I have no idea. This one's clear and simple. Not sure how you could be
able to do that better in EAPI.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, 27 Jan 2013 16:12:37 +0100 Michał Górny wrote: > 5. Solutions to specific problems > - > > 1. x11-proto packages > > Those packages install headers to /usr/include and pkg-config files > to /usr/lib64. This supposedly means that the headers could be > ABI-specific; however, so far I haven't seen a single difference. > > Possible solutions: > > a) check the headers by hand, move pkg-config files to /usr/share, > > b) make the proto packages multilib. This will cause identical .pc >files to be installed to lib32 & lib64 but will also enable eclass >checks for header consistency. b) sounds like what we should do by default while lobbying upstream to do a) :) > 2. packages which install ABI-dependent headers > > e.g. libogg. The issue needs to be fixed in the specific ebuild. > > a) fix the headers, e.g.: > > typedef short ogg_int16_t; > typedef unsigned short ogg_uint16_t; > typedef int ogg_int32_t; > > to: > > #include > > typedef int16_t ogg_int16_t; > ... > > b) install the header(s) in an alternate location. With packages using >pkg-config, that would be easy. b) is not an option: this will break those that do not use pkg-config a) is the correct solution, in cooperation with upstream of course, and it shouldn't be that hard for the libogg example since, as far as I can see, they already have such typedefs for other OSes. > 3. packages which still reinvent pkg-config with their *-config > > e.g. llvm. Really painful to solve; probably will require action both > on llvm ebuild side and consumer side. > > a) long-term solution: convince upstream to use pkg-config. > > b) short-term: rename the llvm-config script and use the renamed >version for 32-bit build. yes, but b) is a mess as there will be no generic solution :(
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, 27 Jan 2013 16:12:37 +0100
Michał Górny wrote:
>RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
>dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
This looks like it might be a bit fragile. Is it something better
addressed by an EAPI extension?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] The gx86 multilib project -- masterplan
El dom, 27-01-2013 a las 16:12 +0100, Michał Górny escribió: [...] > 5. Solutions to specific problems > - > > 1. x11-proto packages > > Those packages install headers to /usr/include and pkg-config files > to /usr/lib64. This supposedly means that the headers could be > ABI-specific; however, so far I haven't seen a single difference. > > Possible solutions: > > a) check the headers by hand, move pkg-config files to /usr/share, > > b) make the proto packages multilib. This will cause identical .pc >files to be installed to lib32 & lib64 but will also enable eclass >checks for header consistency. > Currently, emul packages can install /usr/lib32/pkgconfig files (when enabling "development" USE flag). This was added because, as emul sets tend to be obsolete in a few weeks, people compiling packages against its lib32 provided libs were getting build failures due "native" pkgconfig files (usually from newer libs) were being used. Regarding /usr/include, it looks harder to solve, current emul packages simply don't provide headers at all, but it caused issues like this in the past: https://bugs.gentoo.org/show_bug.cgi?id=299490 Maybe installing headers in other place would be interesting :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d
On Sun, Jan 27, 2013 at 10:08 AM, Samuli Suominen wrote: > I see a lot of packages installing /etc/modprobe.d when it should be treated > like /etc/udev, so only generated files and users own files On a related note, I just noticed that /etc/udev is loaded with orphans in my case, and I can't imagine I'm the only one. When we make moves like this we should include either news items or elogs or something to tell users to clean out the cruft, otherwise config protection tends to leave it there, and then users fail to get updates since their cruft overrides them. I assume that files that aren't user-edited can just be safely deleted? Rich
[gentoo-dev] The gx86 multilib project -- masterplan
Hello,
Following the success of python-r1, the batch of patches I was sending
recently and some random testing, I'd like to introduce my ideas
and plans on how multilib could be introduced to gx86 in a simple
and sane manner.
My major goal with this mail is to summarize the ideas, the problems
and all the work that has been done already.
1. The USE flags and profiles
-
The first step in introducing multilib would be to provide the USE
flags necessary to control building for respective ABIs in profiles.
The current proposed patches based on simple amd64 multilib are
available in [1].
From profiles PoV:
1. Each multilib-capable arch set provides USE_EXPAND with relevant
multilib profiles.
ABI_X86="32 x32 64"
ABI_MIPS="o32 n32 n64"
2. All the USE_EXPAND variables are hidden in the base profile, and all
the flags are masked.
3. Every arch relevant to the particular set of multilib flags unmasks
and forces the flag for default ABI.
x86 -> unmasks & forces abi_x86_32
amd64 -> unmasks & forces abi_x86_64
4. Every multilib profile unmasks the flags for remaining supported
ABIs and unhides the variable.
amd64 multilib -> unmasks abi_x86_32, unhides ABI_X86
[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/83341
2. The USE flags and packages
-
The packages requesting multilib support either inherit
the multilib-build [2] or its derivative (e.g. autotools-multilib),
or implement the necessary facilities by hand.
The following common rules apply (they are all handled by the eclass):
1. Each multilib-capable ebuilds adds multilib flags for all arches
to IUSE (IUSE must be constant).
2. The relevant set of flags is enforced through profile flag masking,
forcing and USE_EXPAND hiding. Therefore, the user only sees
the flags which are really relevant.
x86, amd64 no-multilib -> no flags (hidden)
amd64 multilib -> ABI_X86="32 (64)" (latter forced)
3. The enabled set of ABIs is further filtered through MULTILIB_ABIS
set by profile. Therefore, even with users mangling the masks they
won't be able to build something irrelevant to the profile.
4. All the build and libdir details are handled by the multilib.eclass.
Therefore, all ebuilds should be ready for it already.
5. If no relevant USE flags are selected (bug-case), fallback
to default ABI is done.
[2]:http://thread.gmane.org/gmane.linux.gentoo.devel/83322
3. Inter-package dependencies
-
The inter-package dependencies are done the best way possible --
explicitly ;). The package developers are supposed to know best which
of the dependencies need having same ABIs enabled and which don't.
1. The 'regular' multilib packages are supposed to use
${MULTILIB_USEDEP} from multilib-build.eclass on all dependencies
which need multilib.
RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
The dependencies will be required to have the same ABIs enabled
as the package in question.
2. The specific cases can use the USE flags directly. For example,
binary x86 packages can depend on abi_x86_32 unconditionally:
RDEPEND="dev-libs/libfoo[abi_x86_32]"
Due to proper profile USE flag forcing/masking, that dependency is
valid both for amd64 multilib & real x86 system.
4. ABI-specific content
---
The gx86 multilib assumes that the majority of multilib packages will
install only 32-bit libraries and pkg-config files.
1. The installation of 32-bit data in libdir is done implicitly through
multilib.eclass and econf awareness of ABI variable.
2. Any other content which needs to be ABI-aware (includes, *-config
programs) need be handled by ebuilds explicitly.
3. Additionally, the autotools-multilib.eclass will ensure that headers
installed to /usr/include are consistent between ABIs.
5. Solutions to specific problems
-
1. x11-proto packages
Those packages install headers to /usr/include and pkg-config files
to /usr/lib64. This supposedly means that the headers could be
ABI-specific; however, so far I haven't seen a single difference.
Possible solutions:
a) check the headers by hand, move pkg-config files to /usr/share,
b) make the proto packages multilib. This will cause identical .pc
files to be installed to lib32 & lib64 but will also enable eclass
checks for header consistency.
2. packages which install ABI-dependent headers
e.g. libogg. The issue needs to be fixed in the specific ebuild.
a) fix the headers, e.g.:
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
to:
#include
typedef int16_t ogg_int16_t;
...
b) install the header(s) in an alternate location. With packages using
pkg-config, that would be easy.
3. packages which still reinvent pkg-config with their *-config
e.g. llvm. Really painful to solve; p
[gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d
I see a lot of packages installing /etc/modprobe.d when it should be treated like /etc/udev, so only generated files and users own files I'm suggesting converting ebuilds to install into /lib/modprobe.d and then tell users to copy it to /etc/modprobe.d for editing and replacing the run of the same from /lib/modprobe.d just like you would now copy .rules to /etc/udev/rules.d and edit them there, instead of directly in /lib/udev/rules.d/ /lib should be static, just like /usr, and should be allowed to mount RO did I miss something? if not, i'll open a Tracker to get this done (when do we get rid of /usr/portage again, and when will /usr/src be symlink to somewhere where it can be writable?)
[gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable
Currently, when people uses DOC_CONTENTS variable to place their desired
messages, they are automatically reformatted by "fmt" to get proper
messages (for example, splitting long lines).
But, in some cases, may be useful to disable this behavior and respect
strictly how DOC_CONTENTS was formatted, for example in that kind of
messages telling people to run a command and, then, requiring a new line
to be used. This can also be useful to append extra information to
DOC_CONTENTS when, for example, additional info is needed when enabling
a USE flag.
--- /home/pacho/gentoo-x86/eclass/readme.gentoo.eclass 2013-01-24 22:38:41.0 +0100
+++ ./readme.gentoo.eclass 2013-01-27 14:51:58.0 +0100
@@ -36,6 +36,12 @@
EXPORT_FUNCTIONS src_install pkg_postinst
+# @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, DOC_CONTENTS information will be strictly respected,
+# not getting it automatically formatted by fmt.
+
# @ECLASS-VARIABLE: FORCE_PRINT_ELOG
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -53,7 +59,11 @@
if [[ -n "${DOC_CONTENTS}" ]]; then
eshopts_push
set -f
- echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
+ if [[ -n "${DISABLE_AUTOFORMATTING}" ]]; then
+ echo "${DOC_CONTENTS}" > "${T}"/README.gentoo
+ else
+ echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
+ fi
eshopts_pop
dodoc "${T}"/README.gentoo
else
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCHES] x86 multilib flags, ver. 2
Michał Górny schrieb: > Hello, > > Following all the suggestions from Alexis Ballier, I have reworked > the code to remove multiple points of failure. I have also rebased it > on the common multilib-build eclass concept, and updated amd64 > no-multilib & x86 profiles as well. > > Key points: > > 1. The list of available flags and corresponding ABIs is now stored >in a single variable. Adding a new ABI is as simple as adding >a value to that variable (+ profiles). > > 2. All ABIs are validated against $(get_all_abis) list. This guarantees >that we check only the flags proper for the arch. > > 3. The USE_EXPAND is visible only on amd64 multilib profile. However, >it is also available on non-multilib amd64 & x86, with all flags >masked except for the default one which is force-enabled. > > The last point means that x86 binary packages (skype) can have > dependencies as simple as: > >dev-libs/libfoo[abi_x86_32] > > which would be valid both for amd64 multilib & x86. > > > Lets see, if i understand your plan right, without reading all your diffs: 1. you currently support amd64/multilib and show same flags on amd64/no-multilib and x86 to avoid duplicating the dependency list? If yes, will this be extended to general support for all multilib arches, only on request for specific arches or not at all? 2. How do you handle other abi-specific files like headers or binaries and cases like binaries with abi-specific content? Is it possible to preserve them for all requested abis or to preserve them for an non-default abi? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/5] Use explicit abi_* flags to select multilib targets.
On Sun, 27 Jan 2013 09:34:13 -0300
Alexis Ballier wrote:
> Very nice work; +1 on everything, it seems we'll finally get serious
> and official multilib support after all those years.
> I'm looking forward to get this in three :)
I am writing some kind of spec/summary right now.
> On Sat, 26 Jan 2013 23:08:13 +0100
> Michał Górny wrote:
> [...]
> > # @FUNCTION: multilib_get_enabled_abis
> > # @DESCRIPTION:
> > @@ -49,9 +64,20 @@ MULTILIB_USEDEP='multilib(-)?'
> > multilib_get_enabled_abis() {
> > debug-print-function ${FUNCNAME} "${@}"
> >
> > - if use multilib; then
> > - get_all_abis
> > - else
> > + local supported_abis=$(get_all_abis)
> > + local i found
> > + for i in "${_MULTILIB_FLAGS[@]}"; do
> > + local abi=${i#*:}
> > + local flag=${i%:*}
> > +
> > + if has "${abi}" ${supported_abis} && use "${flag}";
> > then
> > + echo "${abi}"
> > + found=1
> > + fi
> > + done
> > +
> > + if [[ ! ${found} ]]; then
> > + debug-print "${FUNCNAME}: no ABIs enabled, fallback
> > to ${DEFAULT_ABI}" echo ${DEFAULT_ABI}
> > fi
> > }
>
> Just one thing here: I may have missed something, but how do you ensure
> the DEFAULT_ABI is last in the list ? It seems to me you rely on the
> order of _MULTILIB_FLAGS. I'd just skip it explicitly (if the
> corresponding useflag is enabled) and print DEFAULT_ABI at the end to be
> on the safe side, if it has been skipped.
That seems like a reasonable idea. I'd have a second and third look
at the function, and see if it wouldn't be better to just iterate over
$(get_all_abis) in the outer loop.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH autotools-multilib] Check installed headers for consistency.
On Sun, 27 Jan 2013 09:44:23 -0300 Alexis Ballier wrote: > On Sun, 27 Jan 2013 12:21:01 +0100 > Michał Górny wrote: > > > The installed headers are supposed not to change between ABIs. If they > > do, we need to do something special about them or everything is going > > to end up real bad. > > > > Therefore, do a checksum of headers installed in /usr/include after > > each ABI's src_install() and die if they don't match. > > sounds a bit restrictive IMHO, but such a kind of check is probably > necessary and has to be added before the eclass is widespread. > you could probably add a way to disable those checks for the > hypothetical case there is a false positive (ie: yes the headers > differ but it doesn't matter). Well, since this is eclass and not the PMS, we can add it anytime when it becomes really necessary ;). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH autotools-multilib] Check installed headers for consistency.
On Sun, 27 Jan 2013 12:21:01 +0100 Michał Górny wrote: > The installed headers are supposed not to change between ABIs. If they > do, we need to do something special about them or everything is going > to end up real bad. > > Therefore, do a checksum of headers installed in /usr/include after > each ABI's src_install() and die if they don't match. sounds a bit restrictive IMHO, but such a kind of check is probably necessary and has to be added before the eclass is widespread. you could probably add a way to disable those checks for the hypothetical case there is a false positive (ie: yes the headers differ but it doesn't matter). Alexis.
Re: [gentoo-dev] [PATCH 2/5] Use explicit abi_* flags to select multilib targets.
Very nice work; +1 on everything, it seems we'll finally get serious
and official multilib support after all those years.
I'm looking forward to get this in three :)
On Sat, 26 Jan 2013 23:08:13 +0100
Michał Górny wrote:
[...]
> # @FUNCTION: multilib_get_enabled_abis
> # @DESCRIPTION:
> @@ -49,9 +64,20 @@ MULTILIB_USEDEP='multilib(-)?'
> multilib_get_enabled_abis() {
> debug-print-function ${FUNCNAME} "${@}"
>
> - if use multilib; then
> - get_all_abis
> - else
> + local supported_abis=$(get_all_abis)
> + local i found
> + for i in "${_MULTILIB_FLAGS[@]}"; do
> + local abi=${i#*:}
> + local flag=${i%:*}
> +
> + if has "${abi}" ${supported_abis} && use "${flag}";
> then
> + echo "${abi}"
> + found=1
> + fi
> + done
> +
> + if [[ ! ${found} ]]; then
> + debug-print "${FUNCNAME}: no ABIs enabled, fallback
> to ${DEFAULT_ABI}" echo ${DEFAULT_ABI}
> fi
> }
Just one thing here: I may have missed something, but how do you ensure
the DEFAULT_ABI is last in the list ? It seems to me you rely on the
order of _MULTILIB_FLAGS. I'd just skip it explicitly (if the
corresponding useflag is enabled) and print DEFAULT_ABI at the end to be
on the safe side, if it has been skipped.
Alexis.
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
El dom, 27-01-2013 a las 00:26 +0100, Andreas K. Huettel escribió: > Just to keep everyone updated, ... > > > FYI, the new 13.0 profiles are now all available in profiles.desc, for now > > all with status "dev" (i.e. repoman includes them only when you request > > developer profile checking). > > > > This means the procedure below is complete up to and including point 5) > > now. > > > > Please consider changing your profile symlink manually and testing the new > > profile tree. In case of problems, please file a bug and assign it to me > > (or tell me if I'm around). > > > > If all goes well, we'll continue in a week. > > > > A small bug in repoman turned up when testing the EAPI=5 profiles, and > therefore we will wait for the next stable portage version before the 10.0 > profiles are deprecated. So, another 3-4 weeks to go maybe. > > [The only alternative would be to require all devs to run at least ~arch > portage, since the bug only affects repoman, not emerge.] > > Cheers, > Andreas > Maybe other option would be to have a portage version like current stable + repoman fix and fast stabilize as soon as possible signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH autotools-multilib] Check installed headers for consistency.
The installed headers are supposed not to change between ABIs. If they
do, we need to do something special about them or everything is going to
end up real bad.
Therefore, do a checksum of headers installed in /usr/include after each ABI's
src_install() and die if they don't match.
---
gx86/eclass/autotools-multilib.eclass | 36 ++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index 90f7bee..4cd5242 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -120,5 +120,39 @@ autotools-multilib_src_test() {
}
autotools-multilib_src_install() {
- autotools-multilib_foreach_abi autotools-utils_src_install
+ autotools-multilib_secure_install() {
+ autotools-utils_src_install
+
+ # Make sure all headers are the same for each ABI.
+ autotools-multilib_cksum() {
+ find "${ED}"usr/include -type f \
+ -exec cksum {} + | sort -k2
+ }
+
+ local cksum=$(autotools-multilib_cksum)
+ local cksum_file=${T}/.autotools-multilib_cksum
+
+ if [[ -f ${cksum_file} ]]; then
+ local cksum_prev=$(< "${cksum_file}")
+
+ if [[ ${cksum} != ${cksum_prev} ]]; then
+ echo "${cksum}" > "${cksum_file}.new"
+
+ eerror "Header files have changed between ABIs."
+
+ if type -p diff &>/dev/null; then
+ eerror "$(diff -du "${cksum_file}"
"${cksum_file}.new")"
+ else
+ eerror "Old checksums in: ${cksum_file}"
+ eerror "New checksums in:
${cksum_file}.new"
+ fi
+
+ die "Header checksum mismatch, aborting."
+ fi
+ else
+ echo "${cksum}" > "${cksum_file}"
+ fi
+ }
+
+ autotools-multilib_foreach_abi autotools-multilib_secure_install
}
--
1.8.1.1
Re: [gentoo-dev] lastrites in gentoo-dev-announce only
On 27-01-2013 10:43:47 +0100, Theo Chatzimichos wrote: > Hello, > > how about sending the lastrites announcements in gentoo-dev-announce only? +1 -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-dev] lastrites in gentoo-dev-announce only
Hello, how about sending the lastrites announcements in gentoo-dev-announce only? Theo signature.asc Description: This is a digitally signed message part.
