Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Point user to additional kernel removal, instructions. See bug #581522.
On 12/27/2016 04:52 PM, Mike Pagano wrote:
> This addresses concerns that users might not realize that after an
> unmerge of kernel sources some files will need to be removed manually.
> The particular concern was specific to the files in /lib/modules/. I
> liked this solution, since it does not require a wordy explanation to be
> written in the eclass.
>
> ---
> eclass/kernel-2.eclass | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 520a4c1..29b2987 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1619,4 +1619,7 @@ kernel-2_pkg_postrm() {
> ewarn "with modified files will remain behind. By design, package
> managers"
> ewarn "will not remove these modified files and the directories they
> reside in."
> echo
> + ewarn "For more detailed kernel removal instructions, please see: "
> + ewarn "https://wiki.gentoo.org/wiki/Kernel/Removal";
> + echo
> }
>
+1
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Point user to additional kernel removal, instructions. See bug #581522.
looks like nice information to give :)
ok, for me.
On Wed, Dec 28, 2016 at 9:52 AM, Mike Pagano wrote:
> This addresses concerns that users might not realize that after an
> unmerge of kernel sources some files will need to be removed manually.
> The particular concern was specific to the files in /lib/modules/. I
> liked this solution, since it does not require a wordy explanation to be
> written in the eclass.
>
> ---
> eclass/kernel-2.eclass | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 520a4c1..29b2987 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1619,4 +1619,7 @@ kernel-2_pkg_postrm() {
> ewarn "with modified files will remain behind. By design, package
> managers"
> ewarn "will not remove these modified files and the directories they
> reside in."
> echo
> + ewarn "For more detailed kernel removal instructions, please see: "
> + ewarn "https://wiki.gentoo.org/wiki/Kernel/Removal";
> + echo
> }
> --
> 2.10.2
>
>
>
--
アリス フェッラッシィ
Alice Ferrazzi
Gentoo, If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Point user to additional kernel removal, instructions. See bug #581522.
This addresses concerns that users might not realize that after an
unmerge of kernel sources some files will need to be removed manually.
The particular concern was specific to the files in /lib/modules/. I
liked this solution, since it does not require a wordy explanation to be
written in the eclass.
---
eclass/kernel-2.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 520a4c1..29b2987 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1619,4 +1619,7 @@ kernel-2_pkg_postrm() {
ewarn "with modified files will remain behind. By design, package
managers"
ewarn "will not remove these modified files and the directories they
reside in."
echo
+ ewarn "For more detailed kernel removal instructions, please see: "
+ ewarn "https://wiki.gentoo.org/wiki/Kernel/Removal";
+ echo
}
--
2.10.2
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On Tue, 27 Dec 2016 12:04:04 -0500
Mike Gilbert wrote:
> For a typical cross-compiler build, CHOST is unchanged from the value
> typically in make.conf, but CTARGET gets set to the "cross" arch.
Yep.
> In the case where we are cross-compiling a native compiler, CHOST
> would be taken from ${ROOT}/etc/portage/make.conf, and ROOT would
> typically be something like /usr/${cross_arch}/. So I think we are
> safe there as well.
I seem to recall installing a native compiler to /usr/${cross_arch}/
resulted in file conflicts but if that's still the case, that's a
separate issue. ROOT may possibly need to change to SYSROOT but that's
also a separate issue.
> What I'm very unsure of is cross-compiling a cross-compiler CBUILD !=
> CHOST != CTARGET. That requires a bit of thought. I'm not sure we even
> really support that in toolchain.eclass though.
This is called a Canadian cross. I can't remember if I ever actually
tried one but I think your change would still be correct in this case.
We don't care about CBUILD in this context.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpd5udVmCqmF.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/12/16 11:04, Mike Gilbert wrote: > What I'm very unsure of is cross-compiling a cross-compiler CBUILD > != CHOST != CTARGET. That requires a bit of thought. I'm not sure > we even really support that in toolchain.eclass though. > Having tried this before, it doesn't work with Portage (at least as of Sep 2015). Then again, it barely works hand-hacking it manually. :) - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYYuVnAAoJEMspy1GSK50ULqUP/jotFE2oN+fYDsp5fuFhWJg/ GFk7lj/oHa2tnQ3JqzHQ+H0/uFG98U8+fPiswCuRweJUXO1P2hbRao8EGVxYw8Xt f+FporNTQg8jGkMRXzISKBAboqpCEOgLH3p8WYaGs6qmFIidHm3r6H7gg7y/bTf+ zKDUtlnEYAmwDV6zGF74d/lTBox3rbJqkZVAKkVZbzc8Y83tod9mNZL1goTBSfkF z1AcSKsNtNYlQmTe7x/0LZXZ33Wi0mEqD65TaJK5aaU7l3Hu9W6DUAcZQaPlql4u k7LkZZO2MQ+cLp68kDwxEae8ZRs/9S3bBNNH5IaI7ASdkJmPnanR22jODuQkR6C8 GNG0jJemozyTVONVAUs2FWslTxXJ/Pgdu12SnfydUci42KVvXyOtXBB7ICmo4yfN yF4p6XXeHbmlvi8xoBLxnOxSUvrtorFzqZLK/YeiUMuSbknKDhDFL9fD+gFIBZlm ABdiK5Z1AewrYf9WBmqj80u40bcYTU2SVN6xKgKoqYPkvfPEk+W93wmWaq0+6VX6 m+JV9UT+Jt1umY2WW0oDVlwW85QhXQPKFUTdByx2E6++iY3CiSXn6i+uDpwJt+0b ShS6E7rQgBxfH2rwJ0sgtBgDoqYegUgrgRDgMfvO7wfjOZsF04qH/tOYz0UGuyAV 5yubToZyJRT49dRHbv91 =hkcP -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On Tue, Dec 27, 2016 at 6:10 AM, Joakim Tjernlund
wrote:
> On Tue, 2016-12-27 at 00:22 -0800, Daniel Campbell wrote:
>> On 12/26/2016 12:22 PM, Mike Gilbert wrote:
>> > Bug: https://bugs.gentoo.org/603776
>> > ---
>> > eclass/toolchain.eclass | 8
>> > 1 file changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
>> > index 55249b00249b..97511ee12440 100644
>> > --- a/eclass/toolchain.eclass
>> > +++ b/eclass/toolchain.eclass
>> > @@ -2119,13 +2119,13 @@
>> >
>> > do_gcc_config() {
>> > if ! should_we_gcc_config ; then
>> > - env -i ROOT="${ROOT}" gcc-config --use-old --force
>> > + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old
>> > --force
>> > return 0
>> > fi
>> >
>> > local current_gcc_config target
>> >
>> > - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET}
>> > 2>/dev/null)
>> > + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config
>> > -c ${CTARGET} 2>/dev/null)
>> > if [[ -n ${current_gcc_config} ]] ; then
>> > local current_specs use_specs
>> > # figure out which specs-specific config is active
>> > @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
>> > # if the current config is invalid, we definitely want a new one
>> > # Note: due to bash quirkiness, the following must not be 1 line
>> > local curr_config
>> > - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) ||
>> > return 0
>> > + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c
>> > ${CTARGET} 2>&1) || return 0
>> >
>> > # if the previously selected config has the same major.minor (branch)
>> > as
>> > # the version we are installing, then it will probably be uninstalled
>> > # for being in the same SLOT, make sure we run gcc-config.
>> > - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S
>> > ${curr_config} | awk '{print $2}')
>> > + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}"
>> > gcc-config -S ${curr_config} | awk
>> > '{print $2}')
>> >
>> > local curr_branch_ver=$(get_version_component_range 1-2
>> > ${curr_config_ver})
>> >
>> >
>>
>> Seems like an obvious bug and fix; is there any reason passing CHOST
>> around might be a bad idea? It seems to me that it enforces the behavior
>> it's meant to have to begin with and makes it more obvious that CHOST is
>> used.
>
> Will that work for cross toolchains well?
I was hoping someone would be paying enough attention to ask this question. ;-)
I *think* it will still work for cross-toolchains. If someone can
think of a way this will break, please share.
For a typical cross-compiler build, CHOST is unchanged from the value
typically in make.conf, but CTARGET gets set to the "cross" arch.
In the case where we are cross-compiling a native compiler, CHOST
would be taken from ${ROOT}/etc/portage/make.conf, and ROOT would
typically be something like /usr/${cross_arch}/. So I think we are
safe there as well.
What I'm very unsure of is cross-compiling a cross-compiler CBUILD !=
CHOST != CTARGET. That requires a bit of thought. I'm not sure we even
really support that in toolchain.eclass though.
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On Tue, Dec 27, 2016 at 3:22 AM, Daniel Campbell wrote:
> On 12/26/2016 12:22 PM, Mike Gilbert wrote:
>> Bug: https://bugs.gentoo.org/603776
>> ---
>> eclass/toolchain.eclass | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
>> index 55249b00249b..97511ee12440 100644
>> --- a/eclass/toolchain.eclass
>> +++ b/eclass/toolchain.eclass
>> @@ -2119,13 +2119,13 @@
>>
>> do_gcc_config() {
>> if ! should_we_gcc_config ; then
>> - env -i ROOT="${ROOT}" gcc-config --use-old --force
>> + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old
>> --force
>> return 0
>> fi
>>
>> local current_gcc_config target
>>
>> - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET}
>> 2>/dev/null)
>> + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config
>> -c ${CTARGET} 2>/dev/null)
>> if [[ -n ${current_gcc_config} ]] ; then
>> local current_specs use_specs
>> # figure out which specs-specific config is active
>> @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
>> # if the current config is invalid, we definitely want a new one
>> # Note: due to bash quirkiness, the following must not be 1 line
>> local curr_config
>> - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) ||
>> return 0
>> + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c
>> ${CTARGET} 2>&1) || return 0
>>
>> # if the previously selected config has the same major.minor (branch)
>> as
>> # the version we are installing, then it will probably be uninstalled
>> # for being in the same SLOT, make sure we run gcc-config.
>> - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S
>> ${curr_config} | awk '{print $2}')
>> + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}"
>> gcc-config -S ${curr_config} | awk '{print $2}')
>>
>> local curr_branch_ver=$(get_version_component_range 1-2
>> ${curr_config_ver})
>>
>>
>
> Seems like an obvious bug and fix; is there any reason passing CHOST
> around might be a bad idea? It seems to me that it enforces the behavior
> it's meant to have to begin with and makes it more obvious that CHOST is
> used.
I am honestly not sure why the eclass is calling env -i in the first
place. It looks like vapier added that; maybe he can explain it?
Re: [gentoo-dev] The changes about the stabilization process
On Sun, 25 Dec 2016 23:32:56 +0900 Aaron Bauman wrote: > It is not necessary to use a file now. Just put the list in the "Atoms to > stabilize" as described. Well, to an extent it was more a problem I feel the *need* to use this feature already ;) Because I have some stuff that bumps into utterly crazy lengths that become entirely unreadable if you have them in the atoms panel. ( working on a keywording list atm that's gonna be 30 lines long easily ) pgpxSSFvJwkfY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On Tue, 2016-12-27 at 00:22 -0800, Daniel Campbell wrote:
> On 12/26/2016 12:22 PM, Mike Gilbert wrote:
> > Bug: https://bugs.gentoo.org/603776
> > ---
> > eclass/toolchain.eclass | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> > index 55249b00249b..97511ee12440 100644
> > --- a/eclass/toolchain.eclass
> > +++ b/eclass/toolchain.eclass
> > @@ -2119,13 +2119,13 @@
> >
> > do_gcc_config() {
> > if ! should_we_gcc_config ; then
> > - env -i ROOT="${ROOT}" gcc-config --use-old --force
> > + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old
> > --force
> > return 0
> > fi
> >
> > local current_gcc_config target
> >
> > - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET}
> > 2>/dev/null)
> > + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config
> > -c ${CTARGET} 2>/dev/null)
> > if [[ -n ${current_gcc_config} ]] ; then
> > local current_specs use_specs
> > # figure out which specs-specific config is active
> > @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
> > # if the current config is invalid, we definitely want a new one
> > # Note: due to bash quirkiness, the following must not be 1 line
> > local curr_config
> > - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) ||
> > return 0
> > + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c
> > ${CTARGET} 2>&1) || return 0
> >
> > # if the previously selected config has the same major.minor (branch) as
> > # the version we are installing, then it will probably be uninstalled
> > # for being in the same SLOT, make sure we run gcc-config.
> > - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S
> > ${curr_config} | awk '{print $2}')
> > + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}"
> > gcc-config -S ${curr_config} | awk
> > '{print $2}')
> >
> > local curr_branch_ver=$(get_version_component_range 1-2
> > ${curr_config_ver})
> >
> >
>
> Seems like an obvious bug and fix; is there any reason passing CHOST
> around might be a bad idea? It seems to me that it enforces the behavior
> it's meant to have to begin with and makes it more obvious that CHOST is
> used.
Will that work for cross toolchains well?
Jocke
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On 12/26/2016 12:22 PM, Mike Gilbert wrote:
> Bug: https://bugs.gentoo.org/603776
> ---
> eclass/toolchain.eclass | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 55249b00249b..97511ee12440 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -2119,13 +2119,13 @@
>
> do_gcc_config() {
> if ! should_we_gcc_config ; then
> - env -i ROOT="${ROOT}" gcc-config --use-old --force
> + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old
> --force
> return 0
> fi
>
> local current_gcc_config target
>
> - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET}
> 2>/dev/null)
> + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config
> -c ${CTARGET} 2>/dev/null)
> if [[ -n ${current_gcc_config} ]] ; then
> local current_specs use_specs
> # figure out which specs-specific config is active
> @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
> # if the current config is invalid, we definitely want a new one
> # Note: due to bash quirkiness, the following must not be 1 line
> local curr_config
> - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) ||
> return 0
> + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c
> ${CTARGET} 2>&1) || return 0
>
> # if the previously selected config has the same major.minor (branch) as
> # the version we are installing, then it will probably be uninstalled
> # for being in the same SLOT, make sure we run gcc-config.
> - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S
> ${curr_config} | awk '{print $2}')
> + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}"
> gcc-config -S ${curr_config} | awk '{print $2}')
>
> local curr_branch_ver=$(get_version_component_range 1-2
> ${curr_config_ver})
>
>
Seems like an obvious bug and fix; is there any reason passing CHOST
around might be a bad idea? It seems to me that it enforces the behavior
it's meant to have to begin with and makes it more obvious that CHOST is
used.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
