Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 10-11-2020 09:21:53 +, Alexey Sokolov wrote: > > What instructed you to perform the migration? Was it the news-item? I > > don't think it should apply for Prefix profiles, and perhaps we should > > be happy the tool won't work. > > It was the big scary warning about the deprecation whenever I run > emerge. It contains list of steps. Ok. I don't know if we can do anything about that. > > Did it do anything to your system like creating a lib64 directory? Does > > anything work (because I have doubts on whether your system can still > > find the libs in there now). > > Yes. Attaching logs. The logs seem to indicate that it thinks all libs on your systems do not belong to any package. This suggests the tool cannot locate the VDB or something, as most of the things in the list are obviously owned by packages. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
10.11.2020 08:55, Fabian Groffen пишет: > On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: >> Hi Fabian >> I tried to migrate my prefix to 17.1, and there are issues. >> >> 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an >> error "/usr/lib is a real directory! was the migration done already?" > > I think unsymlink-lib doesn't have Prefix support, but in addition, > what unsymlink-lib is trying to achieve, is not a thing perhaps on > Prefix. > > A prefix system (at least all of mine) doesn't have libXX or lib/XX > (a.k.a. multilib) directories. The /usr-split was long ago removed, > and thus what we have is: > > lib -> usr/lib > > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does > not exist on Prefix systems. > > Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is > necessary in the best case, but going to break the Prefix system in the > worst case. > > What instructed you to perform the migration? Was it the news-item? I > don't think it should apply for Prefix profiles, and perhaps we should > be happy the tool won't work. It was the big scary warning about the deprecation whenever I run emerge. It contains list of steps. > * non-multilib is a decision dating back a decade or so, which means > effectively any Prefix install you encounter should be non-multilib > > >> 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend >> usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] >> [--rollback] [--finish] [--force-rollback] >> [--resume-finish] [-P PREFIX] [--hardlink] >> unsymlink-lib: error: Requested action requires root privileges >> >> Well, I worked it around by adding "is_root = True" to unsymlink-lib > > Did it do anything to your system like creating a lib64 directory? Does > anything work (because I have doubts on whether your system can still > find the libs in there now). Yes. Attaching logs. > >> >> 3) Step 9 (Rebuild gcc) fails: >> configure:4372: checking whether the C compiler works >> >> >> >> configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 >> >> >> >> /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: >> error while loading shared libraries: >> libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared > > Something like this I was suspecting. Can you still rollback? If you > can, I'd try that and hope it restores your system in working order. Yeah, don't worry, this is my ebuild-testing chroot. I just did "lxc restore". -- Best regards, Alexey "DarthGandalf" Sokolov Analyzing files installed into lib & lib64... directories that will be moved to /home/user/gentoo/lib/: (+ 0 files) directories whose contents will be split between /home/user/gentoo/lib/ and /home/user/gentoo/lib64/: orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/lib/: gentoo modprobe.d systemd orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/lib64/: ld-2.31.so ld-linux-x86-64.so.2 libBrokenLocale-2.31.so libBrokenLocale.so.1 libSegFault.so libanl-2.31.so libanl.so.1 libc-2.31.so libc.so.6 libcrypt-2.31.so libcrypt.so.1 libdl-2.31.so libdl.so.2 libkmod.so.2 libkmod.so.2.3.5 libm-2.31.so libm.so.6 libmemusage.so libmvec-2.31.so libmvec.so.1 libnsl-2.31.so libnsl.so.1 libnss_compat-2.31.so libnss_compat.so.2 libnss_db-2.31.so libnss_db.so.2 libnss_dns-2.31.so libnss_dns.so.2 libnss_files-2.31.so libnss_files.so.2 libnss_hesiod-2.31.so libnss_hesiod.so.2 libpcprofile.so libpthread-2.31.so libpthread.so.0 libresolv-2.31.so libresolv.so.2 librt-2.31.so librt.so.1 libthread_db-1.0.so libthread_db.so.1 libutil-2.31.so libutil.so.1 directories that will be moved to /home/user/gentoo/usr/lib/: (+ 0 files) directories whose contents will be split between /home/user/gentoo/usr/lib/ and /home/user/gentoo/usr/lib64/: orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/usr/lib/: Mcrt1.o Scrt1.o audit binutils cmake crt1.o crti.o crtn.o debug engines-1.1 gawk gcc gconv gcrt1.o gettext glibc-2.31 help2man libffi misc perl5 pkgconfig portage python-exec python3.7 systemd terminfo tmpfiles.d xml2Conf.sh orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/usr/lib64/: libBrokenLocale.a libBrokenLocale.so libacl.so libacl.so.1 libacl.so.1.1.2253 libanl.a libanl.so libasprintf.so libasprintf.so.0 libasprintf.so.0.0.0 libassuan.so libassuan.so.0 libassuan.so.0.8.3 libattr.so libattr.so.1 libattr.so.1.1.2448 libb2.so libb2.so.1 libb2.so.1.0.4 libblkid.so libblkid.so.1 libblkid.so.1.1.0 libbz2.so libbz2.so.1 libbz2.so.1.0 libbz2.so.1.0.6 libc.a libc.so libc_nonshared.a libcrypt.a libcrypt.so libcrypto.so libcrypto.so.1.1 libcurl.so libcurl.so.4 libcurl.so.4.6.0 libcurses.so
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On Tue, 2020-11-10 at 09:53 +0100, Fabian Groffen wrote: > On 10-11-2020 09:49:27 +0100, Michał Górny wrote: > > > > So what you're saying is that you've had the wrong value of SYMLINK_LIB > > > > for ages, and now you've created a meaningless 17.1 profile that chnages > > > > it but isn't actually supposed to change anything, correct? > > > > > > I guess, because the amd64 17.0 profile is deprecated with force, and I > > > had to do something ... > > > > Now that's a lie. Only the regular amd64 profiles are deprecated. > > There are no deprecation notices e.g. in the x32 profile or prefix > > profiles. > > Our profiles either directly depend on the amd64/17.0 profile, or we use > a sub-profile from amd64/17.0 profile, so if it's going to get removed, > we are having a problem, don't we? It isn't going to be removed as long as other profiles depend on it. It'll probably be re-parented. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 10-11-2020 09:49:27 +0100, Michał Górny wrote: > > > So what you're saying is that you've had the wrong value of SYMLINK_LIB > > > for ages, and now you've created a meaningless 17.1 profile that chnages > > > it but isn't actually supposed to change anything, correct? > > > > I guess, because the amd64 17.0 profile is deprecated with force, and I > > had to do something ... > > Now that's a lie. Only the regular amd64 profiles are deprecated. > There are no deprecation notices e.g. in the x32 profile or prefix > profiles. Our profiles either directly depend on the amd64/17.0 profile, or we use a sub-profile from amd64/17.0 profile, so if it's going to get removed, we are having a problem, don't we? -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On Tue, 2020-11-10 at 09:41 +0100, Fabian Groffen wrote: > On 10-11-2020 09:34:52 +0100, Michał Górny wrote: > > On Tue, 2020-11-10 at 08:55 +0100, Fabian Groffen wrote: > > > On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: > > > > Hi Fabian > > > > I tried to migrate my prefix to 17.1, and there are issues. > > > > > > > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an > > > > error "/usr/lib is a real directory! was the migration done already?" > > > > > > I think unsymlink-lib doesn't have Prefix support, but in addition, > > > what unsymlink-lib is trying to achieve, is not a thing perhaps on > > > Prefix. > > > > > > A prefix system (at least all of mine) doesn't have libXX or lib/XX > > > (a.k.a. multilib) directories. The /usr-split was long ago removed, > > > and thus what we have is: > > > > > > lib -> usr/lib > > > > > > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does > > > not exist on Prefix systems. > > > > > > > So what you're saying is that you've had the wrong value of SYMLINK_LIB > > for ages, and now you've created a meaningless 17.1 profile that chnages > > it but isn't actually supposed to change anything, correct? > > I guess, because the amd64 17.0 profile is deprecated with force, and I > had to do something ... Now that's a lie. Only the regular amd64 profiles are deprecated. There are no deprecation notices e.g. in the x32 profile or prefix profiles. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 10-11-2020 09:34:52 +0100, Michał Górny wrote: > On Tue, 2020-11-10 at 08:55 +0100, Fabian Groffen wrote: > > On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: > > > Hi Fabian > > > I tried to migrate my prefix to 17.1, and there are issues. > > > > > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an > > > error "/usr/lib is a real directory! was the migration done already?" > > > > I think unsymlink-lib doesn't have Prefix support, but in addition, > > what unsymlink-lib is trying to achieve, is not a thing perhaps on > > Prefix. > > > > A prefix system (at least all of mine) doesn't have libXX or lib/XX > > (a.k.a. multilib) directories. The /usr-split was long ago removed, > > and thus what we have is: > > > > lib -> usr/lib > > > > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does > > not exist on Prefix systems. > > > > So what you're saying is that you've had the wrong value of SYMLINK_LIB > for ages, and now you've created a meaningless 17.1 profile that chnages > it but isn't actually supposed to change anything, correct? I guess, because the amd64 17.0 profile is deprecated with force, and I had to do something ... -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On Tue, 2020-11-10 at 08:55 +0100, Fabian Groffen wrote: > On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: > > Hi Fabian > > I tried to migrate my prefix to 17.1, and there are issues. > > > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an > > error "/usr/lib is a real directory! was the migration done already?" > > I think unsymlink-lib doesn't have Prefix support, but in addition, > what unsymlink-lib is trying to achieve, is not a thing perhaps on > Prefix. > > A prefix system (at least all of mine) doesn't have libXX or lib/XX > (a.k.a. multilib) directories. The /usr-split was long ago removed, > and thus what we have is: > > lib -> usr/lib > > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does > not exist on Prefix systems. > So what you're saying is that you've had the wrong value of SYMLINK_LIB for ages, and now you've created a meaningless 17.1 profile that chnages it but isn't actually supposed to change anything, correct? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: > Hi Fabian > I tried to migrate my prefix to 17.1, and there are issues. > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an > error "/usr/lib is a real directory! was the migration done already?" I think unsymlink-lib doesn't have Prefix support, but in addition, what unsymlink-lib is trying to achieve, is not a thing perhaps on Prefix. A prefix system (at least all of mine) doesn't have libXX or lib/XX (a.k.a. multilib) directories. The /usr-split was long ago removed, and thus what we have is: lib -> usr/lib Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does not exist on Prefix systems. Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is necessary in the best case, but going to break the Prefix system in the worst case. What instructed you to perform the migration? Was it the news-item? I don't think it should apply for Prefix profiles, and perhaps we should be happy the tool won't work. * non-multilib is a decision dating back a decade or so, which means effectively any Prefix install you encounter should be non-multilib > 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend > usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] > [--rollback] [--finish] [--force-rollback] > [--resume-finish] [-P PREFIX] [--hardlink] > unsymlink-lib: error: Requested action requires root privileges > > Well, I worked it around by adding "is_root = True" to unsymlink-lib Did it do anything to your system like creating a lib64 directory? Does anything work (because I have doubts on whether your system can still find the libs in there now). > > 3) Step 9 (Rebuild gcc) fails: > configure:4372: checking whether the C compiler works > > > > configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 > > > > /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: > error while loading shared libraries: > libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared Something like this I was suspecting. Can you still rollback? If you can, I'd try that and hope it restores your system in working order. For any Prefix user, DO NOT run unsymlink-lib, I believe you should NOT NEED IT! Thanks, Fabian > object file: No such file or directory > configure:4398: $? = 1 > > > > configure:4436: result: no > > The file exists: > $ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so > /home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so > > -- > Best regards, > Alexey "DarthGandalf" Sokolov > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
07.11.2020 12:56, Fabian Groffen пишет: > On 07-11-2020 11:42:44 +, Alexey Sokolov wrote: >> 22.10.2020 20:16, Andreas K. Hüttel пишет: >>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > Users frequently are choosing the wrong profile versions in new installs > and accidentally downgrading to 17.0 with some saying they see it first. > > A simple reordering could help new installs. >>> >>> Independent of this useful change, it's probably time to deprecate the >>> amd64 >>> 17.0 profiles! >>> >> >> Prefix bootstrap script still makes new installations to use it > > This should be solved with > > b0445c0a8dd6d2f792c5bb088b154aca53868353 > a9c478dc881ee18fefc7342da994b00e60eaad8e > > on gentoo.git and > > 0d7f6b6eb00d0f51f35019846b8f79048b30be93 > > on prefix.git. > > Thanks, > Fabian > > Hi Fabian I tried to migrate my prefix to 17.1, and there are issues. 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an error "/usr/lib is a real directory! was the migration done already?" 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] [--rollback] [--finish] [--force-rollback] [--resume-finish] [-P PREFIX] [--hardlink] unsymlink-lib: error: Requested action requires root privileges Well, I worked it around by adding "is_root = True" to unsymlink-lib 3) Step 9 (Rebuild gcc) fails: configure:4372: checking whether the C compiler works configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: error while loading shared libraries: libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared object file: No such file or directory configure:4398: $? = 1 configure:4436: result: no The file exists: $ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so /home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 9, 2020 1:54:33 PM GMT+02:00, Peter Stuge wrote: >Andreas K. Hüttel wrote: >> it's probably time to deprecate the amd64 17.0 profiles! > >I for one am not so excited about the amd64 17.1 profiles. On the >surface >it appeared to me that one developer has "taken over" just about >everything, >which (regardless of the individual) can't be a good thing.. > Please wait a bit longer, I'm still working on my evil world domination plans! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 9, 2020 6:54:33 AM EST, Peter Stuge wrote: >Andreas K. Hüttel wrote: >> it's probably time to deprecate the amd64 17.0 profiles! > >I for one am not so excited about the amd64 17.1 profiles. On the >surface >it appeared to me that one developer has "taken over" just about >everything, >which (regardless of the individual) can't be a good thing.. > What does this even mean? > >Jaco Kroon wrote: >> ...just wondering where the lib32 => lib symlink comes from now. > >baselayout contains a conversion to/from lib symlink(s). > > >Kind regards > >//Peter -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
Andreas K. Hüttel wrote: > it's probably time to deprecate the amd64 17.0 profiles! I for one am not so excited about the amd64 17.1 profiles. On the surface it appeared to me that one developer has "taken over" just about everything, which (regardless of the individual) can't be a good thing.. Jaco Kroon wrote: > ...just wondering where the lib32 => lib symlink comes from now. baselayout contains a conversion to/from lib symlink(s). Kind regards //Peter
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 2020-11-09 12:09, Jaco Kroon wrote: equery has some answers that there are still stuff installed into /usr/lib32 (which will likely clear over time, and the symlink will be unmerged). There is this one potential pitfall down the line that I'm seeing, fairly certain this would have been covered and that a remerge of glibc will fix this: As a matter of fact the complete migration procedure (including cleaning up lib32 symlinks) was described in the news items introducing 17.1, for instance "2019-06-05-amd64-17-1-profiles-are-now-stable". In short, run emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32 and the lib32 symlinks should go. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
Hi Ulrich, On 2020/11/09 12:59, Ulrich Mueller wrote: >> On Mon, 09 Nov 2020, Jaco Kroon wrote: >> What is the actual "target" objective with the change? I would have >> expected (not being one to follow this too closely): >> lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts). >> lib32/ - 32-bit specific stuff (libs for 32-bit). >> lib64/ - 64-bit specific stuff (libs for 64-bit). > It is explained here: > https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale Thank you, that makes a lot of sense and answers all my questions ...just wondering where the lib32 => lib symlink comes from now. So if anybody else ends up wondering: jkroon@plastiekpoot ~ $ ls -lah /lib32 /usr/lib32 /usr/local/lib32 ls: cannot access '/usr/local/lib32': No such file or directory lrwxrwxrwx 1 root root 3 Nov 9 10:02 /lib32 -> lib lrwxrwxrwx 1 root root 3 Nov 9 10:02 /usr/lib32 -> lib equery has some answers that there are still stuff installed into /usr/lib32 (which will likely clear over time, and the symlink will be unmerged). There is this one potential pitfall down the line that I'm seeing, fairly certain this would have been covered and that a remerge of glibc will fix this: jkroon@plastiekpoot ~ $ equery belongs /lib32 /usr/lib32 ... sys-libs/glibc-2.32-r2 (/lib -> lib64) So job well done to the implementation team!! Great work thank you! Kind Regards, Jaco
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
> On Mon, 09 Nov 2020, Jaco Kroon wrote: > What is the actual "target" objective with the change? I would have > expected (not being one to follow this too closely): > lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts). > lib32/ - 32-bit specific stuff (libs for 32-bit). > lib64/ - 64-bit specific stuff (libs for 64-bit). It is explained here: https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
Hi,
Having just completed the migration on two systems I found some things
which concerns me:
1. A default/linux/amd64/17.0/desktop to
default/linux/amd64/17.1/desktop. This differs from the no-multilib in
that there are symlinks now for the various lib32 to lib. No such
symlinks on the no-mulilib systems (this makes sense, but why is lib32 a
symlink back to lib/)
2. If /usr/local/lib* doesn't exist the script bails out. This only
happened on one of the two systems I did now, specifically the
default/linux/amd64/17.0/no-multilib =>
default/linux/amd64/17.1/no-multilib one. Other systems I've just
checked seems to already have this by virtue of
/usr/local/lib{64,32}/.keep existing, but no owners of the files, so
this could be sheer dump luck. Which is never good. Sorted by manually
creating lib32 and creating the symlink as instructed. Post migrate
there is a lib/ and lib64/ folder. The complaint on this was about
/usr/local/lib32 if I recall correctly
What is the actual "target" objective with the change? I would have
expected (not being one to follow this too closely):
lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
lib32/ - 32-bit specific stuff (libs for 32-bit).
lib64/ - 64-bit specific stuff (libs for 64-bit).
What am I missing?
Kind Regards,
Jaco
On 2020/10/22 21:16, Andreas K. Hüttel wrote:
> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>> Users frequently are choosing the wrong profile versions in new installs
>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>
>>> A simple reordering could help new installs.
> Independent of this useful change, it's probably time to deprecate the amd64
> 17.0 profiles!
>
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
07.11.2020 14:39, Andreas K. Huettel пишет: > > > On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov > wrote: >> 22.10.2020 20:16, Andreas K. Hüttel пишет: >>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > Users frequently are choosing the wrong profile versions in new >> installs > and accidentally downgrading to 17.0 with some saying they see it >> first. > > A simple reordering could help new installs. >>> >>> Independent of this useful change, it's probably time to deprecate >> the amd64 >>> 17.0 profiles! >>> >> >> Prefix bootstrap script still makes new installations to use it > > Meh. Time to change that then... > Nah, Fabian has just fixed it (in another reply to my message in this thread) -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov wrote: >22.10.2020 20:16, Andreas K. Hüttel пишет: >> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: Users frequently are choosing the wrong profile versions in new >installs and accidentally downgrading to 17.0 with some saying they see it >first. A simple reordering could help new installs. >> >> Independent of this useful change, it's probably time to deprecate >the amd64 >> 17.0 profiles! >> > >Prefix bootstrap script still makes new installations to use it Meh. Time to change that then... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 07-11-2020 11:42:44 +, Alexey Sokolov wrote: > 22.10.2020 20:16, Andreas K. Hüttel пишет: > > Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: > >> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > >>> Users frequently are choosing the wrong profile versions in new installs > >>> and accidentally downgrading to 17.0 with some saying they see it first. > >>> > >>> A simple reordering could help new installs. > > > > Independent of this useful change, it's probably time to deprecate the > > amd64 > > 17.0 profiles! > > > > Prefix bootstrap script still makes new installations to use it This should be solved with b0445c0a8dd6d2f792c5bb088b154aca53868353 a9c478dc881ee18fefc7342da994b00e60eaad8e on gentoo.git and 0d7f6b6eb00d0f51f35019846b8f79048b30be93 on prefix.git. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
22.10.2020 20:16, Andreas K. Hüttel пишет: > Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: >>> Users frequently are choosing the wrong profile versions in new installs >>> and accidentally downgrading to 17.0 with some saying they see it first. >>> >>> A simple reordering could help new installs. > > Independent of this useful change, it's probably time to deprecate the amd64 > 17.0 profiles! > Prefix bootstrap script still makes new installations to use it -- Best regards, Alexey "DarthGandalf" Sokolov
[gentoo-dev] Deprecating AMD64 17.0 profiles?
Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: > On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > > Users frequently are choosing the wrong profile versions in new installs > > and accidentally downgrading to 17.0 with some saying they see it first. > > > > A simple reordering could help new installs. Independent of this useful change, it's probably time to deprecate the amd64 17.0 profiles! -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
