Re: [gentoo-user] how to prevent ebuild from checking for available space
On Fri, 22 Mar 2024 20:11:57 -0400 Jack wrote: > It seems the problem is that the enviroment file in the temp dir of > the build area is sourced when you run ebuild/emerge. (It's among > the first output when you run ebuild.) Since that file was created > based on the state of the ebuild when the first emerge/ebuild was > run, editing the ebuild file doesn't affect it. I ended up finding a > place to unset CHECKREQS_FAILED, and the compile is now continuing. According to check-reqs.eclass, you can also bypass the check by exporting CHECKREQS_DONOTHING=1. I assume this would work for a resumed build too. Cheers, Bryan
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Michael wrote: >> Nice to know I'm not alone. I forgot to mention, it wanted to update >> glibc first. The news item said NOT to let it do that and use the >> --nodeps option instead. So, the command I used had that option. I've >> since restarted it, just in case it finishes. I'll post back if it >> does. I find it odd that it builds fine one time but fails on others. >> Strange things happen tho. >> >> Dale >> >> :-) :-) > There's a new patch for gcc. You need to follow the guide as you did, then > resync portage to fetch the latest ebuild for gcc, before you start the > emerge > --emptytree world. This is how I managed to get ggc to build after previous > attempts with 'no error' failures. Hope this works for you. It just failed the second attempt. I'll sync again and hopefully the new ebuild will fix things. If nothing else, they working out the kinks. Since I'm in a chroot, messing up won't matter. Maybe Peter will see this, update and try again. May help him as well. Thanks. Dale :-) :-)
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Saturday, 23 March 2024 21:28:27 GMT Dale wrote: > Michael wrote: > > On Saturday, 23 March 2024 20:45:03 GMT Dale wrote: > >> I saw where Peter mentioned in another thread gcc failing with no error > >> message for him. This could be related. A solution to this may help > >> more than just me. I'm not sure how to diagnose a failure when it gives > >> no real error. Heck, having a error sometimes isn't much help. :/ I > >> might add, the errors listed above didn't stop the compile until close > >> to the end. It did seem to ignore them since it compiled a good while > >> afterwards. I'm including in case those errors lead to the failure > >> later on. They could be nothing or may be a clue. > >> > >> Open to ideas. > >> > >> Dale > >> > >> :-) :-) > > > > Hmm ... my gcc is failing on one of my installations, with no error ... > > after it built successfully once already, as part of the initial > > toolchain update.> > > :-/ > > > > OK, I'm out of ideas too. May have to sleep on this and look at it again > > tomorrow. > > Nice to know I'm not alone. I forgot to mention, it wanted to update > glibc first. The news item said NOT to let it do that and use the > --nodeps option instead. So, the command I used had that option. I've > since restarted it, just in case it finishes. I'll post back if it > does. I find it odd that it builds fine one time but fails on others. > Strange things happen tho. > > Dale > > :-) :-) There's a new patch for gcc. You need to follow the guide as you did, then resync portage to fetch the latest ebuild for gcc, before you start the emerge --emptytree world. This is how I managed to get ggc to build after previous attempts with 'no error' failures. Hope this works for you. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Michael wrote: > On Saturday, 23 March 2024 20:45:03 GMT Dale wrote: >> Howdy, >> >> I'm doing this in a chroot. This is *not* my live system. This is the >> mount info, in case it matters. >> >> <<>> >> >> >> I saw where Peter mentioned in another thread gcc failing with no error >> message for him. This could be related. A solution to this may help >> more than just me. I'm not sure how to diagnose a failure when it gives >> no real error. Heck, having a error sometimes isn't much help. :/ I >> might add, the errors listed above didn't stop the compile until close >> to the end. It did seem to ignore them since it compiled a good while >> afterwards. I'm including in case those errors lead to the failure >> later on. They could be nothing or may be a clue. >> >> Open to ideas. >> >> Dale >> >> :-) :-) > Hmm ... my gcc is failing on one of my installations, with no error ... after > it built successfully once already, as part of the initial toolchain update. > :-/ > > OK, I'm out of ideas too. May have to sleep on this and look at it again > tomorrow. Nice to know I'm not alone. I forgot to mention, it wanted to update glibc first. The news item said NOT to let it do that and use the --nodeps option instead. So, the command I used had that option. I've since restarted it, just in case it finishes. I'll post back if it does. I find it odd that it builds fine one time but fails on others. Strange things happen tho. Dale :-) :-)
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Saturday, 23 March 2024 20:45:03 GMT Dale wrote: > Howdy, > > I'm doing this in a chroot. This is *not* my live system. This is the > mount info, in case it matters. > > > root@fireball / # mount | grep gentoo > /proc on /backup/gentoo-build/proc type proc (rw,relatime) > sysfs on /backup/gentoo-build/sys type sysfs > (rw,nosuid,nodev,noexec,relatime) > debugfs on /backup/gentoo-build/sys/kernel/debug type debugfs > (rw,nosuid,nodev,noexec,relatime) > fusectl on /backup/gentoo-build/sys/fs/fuse/connections type fusectl > (rw,nosuid,nodev,noexec,relatime) > none on /backup/gentoo-build/sys/fs/cgroup type cgroup2 > (rw,nosuid,nodev,noexec,relatime,nsdelegate) > devtmpfs on /backup/gentoo-build/dev type devtmpfs > (rw,nosuid,noexec,size=10240k,nr_inodes=4104300,mode=755) > devpts on /backup/gentoo-build/dev/pts type devpts > (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > tmpfs on /backup/gentoo-build/dev/shm type tmpfs (rw,nosuid,nodev,noexec) > shm on /backup/gentoo-build/dev/shm type tmpfs > (rw,nosuid,nodev,noexec,relatime) > mqueue on /backup/gentoo-build/dev/mqueue type mqueue > (rw,nosuid,nodev,noexec,relatime) > /run on /backup/gentoo-build/run type tmpfs (rw,relatime) > tmpfs on /backup/gentoo-build/run type tmpfs (rw,size=262144k,mode=755) > root@fireball / # > > > I've following the news item with this. This is early and already it > has issues. Maybe switching is a bit early yet?? Anyway, this is what > gcc fails with: > > > make[3]: Entering directory > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/include' echo timestamp > stamp-pb > echo timestamp > stamp-host > make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h] > Error 1 (ignored) > echo 0 > stamp-namespace-version > echo 1 > stamp-visibility > echo 1 > stamp-extern-template > echo 1 > stamp-dual-abi > echo 1 > stamp-cxx11-abi > echo 1 > stamp-allocator-new > echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128 > sed -e '/^#pragma/b' \ > > > And further down, this: > > > make[3]: Leaving directory > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/include' config.status: executing libtool commands > config.status: executing generate-headers commands > make[3]: Entering directory > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux- > gnu/libstdc++-v3/include' echo timestamp > stamp-pb > echo timestamp > stamp-host > make[3]: [Makefile:1819: x86_64-pc-linux-gnu/bits/largefile-config.h] > Error 1 (ignored) > make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h] > Error 1 (ignored) > echo 0 > stamp-namespace-version > echo 1 > stamp-visibility > echo 1 > stamp-extern-template > echo 1 > stamp-dual-abi > echo 1 > stamp-cxx11-abi > echo 1 > stamp-allocator-new > echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128 > > > And even further down: > > > sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \ > -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \ > -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \ > -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \ > -e 's,^#include "\(.*\)",#include ,g' \ > < > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/libstdc > ++-v3/../libgcc/gthr-posix.h > > x86_64-pc-linux-gnu/bits/gthr-default.h > > make[3]: Leaving directory > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/include' config.status: executing libtool commands > config.status: executing generate-headers commands > make[3]: Entering directory > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux- > gnu/libstdc++-v3/include' echo timestamp > stamp-pb > echo timestamp > stamp-host > make[3]: [Makefile:1819: x86_64-pc-linux-gnu/bits/largefile-config.h] > Error 1 (ignored) > make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h] > Error 1 (ignored) > echo 0 > stamp-namespace-version > echo 1 > stamp-visibility > echo 1 > stamp-extern-template > echo 1 > stamp-dual-abi > echo 1 > stamp-cxx11-abi > echo 1 > stamp-allocator-new > echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128 > > > Very close to the end, this: > > > Makefile:901: warning: ignoring old recipe for target 'all-multi' > make[8]: Leaving directory > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux- > gnu/32/libatomic' make[8]: Entering directory > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux- > gnu/32/libatomic' true DO=install multi-do # make > /bin/mkdir -p > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib' > /bin/sh ./libtool --mode=install /usr/bin/install -c libatomic.la > '/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib' > libtool: install: /usr/bin/install -c .libs/libatomic.so.1.2.0 >
[gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Howdy,
I'm doing this in a chroot. This is *not* my live system. This is the
mount info, in case it matters.
root@fireball / # mount | grep gentoo
/proc on /backup/gentoo-build/proc type proc (rw,relatime)
sysfs on /backup/gentoo-build/sys type sysfs
(rw,nosuid,nodev,noexec,relatime)
debugfs on /backup/gentoo-build/sys/kernel/debug type debugfs
(rw,nosuid,nodev,noexec,relatime)
fusectl on /backup/gentoo-build/sys/fs/fuse/connections type fusectl
(rw,nosuid,nodev,noexec,relatime)
none on /backup/gentoo-build/sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
devtmpfs on /backup/gentoo-build/dev type devtmpfs
(rw,nosuid,noexec,size=10240k,nr_inodes=4104300,mode=755)
devpts on /backup/gentoo-build/dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /backup/gentoo-build/dev/shm type tmpfs (rw,nosuid,nodev,noexec)
shm on /backup/gentoo-build/dev/shm type tmpfs
(rw,nosuid,nodev,noexec,relatime)
mqueue on /backup/gentoo-build/dev/mqueue type mqueue
(rw,nosuid,nodev,noexec,relatime)
/run on /backup/gentoo-build/run type tmpfs (rw,relatime)
tmpfs on /backup/gentoo-build/run type tmpfs (rw,size=262144k,mode=755)
root@fireball / #
I've following the news item with this. This is early and already it
has issues. Maybe switching is a bit early yet?? Anyway, this is what
gcc fails with:
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
sed -e '/^#pragma/b' \
And further down, this:
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/include'
config.status: executing libtool commands
config.status: executing generate-headers commands
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1819: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
And even further down:
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
-e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
-e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
-e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
-e 's,^#include "\(.*\)",#include ,g' \
<
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/libstdc++-v3/../libgcc/gthr-posix.h
> x86_64-pc-linux-gnu/bits/gthr-default.h
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/include'
config.status: executing libtool commands
config.status: executing generate-headers commands
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1819: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
make[3]: [Makefile:1820: x86_64-pc-linux-gnu/bits/largefile-config.h]
Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
Very close to the end, this:
Makefile:901: warning: ignoring old recipe for target 'all-multi'
make[8]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/32/libatomic'
make[8]: Entering directory
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/32/libatomic'
true DO=install multi-do # make
/bin/mkdir -p
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib'
/bin/sh ./libtool --mode=install /usr/bin/install -c libatomic.la
'/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib'
libtool: install: /usr/bin/install -c .libs/libatomic.so.1.2.0
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib/libatomic.so.1.2.0
libtool: install: (cd
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/image/usr/lib/../lib &&
{ ln -s -f libatomic.so.1.2.0 libatomic.so.1 || { rm -f libatomic.so.1
&& ln -s libatomic.so.1.2.0 libatomic.so.1; }; })
libtool: install: (cd
Re: [gentoo-user] New profiles 23.0
Il 23/03/24 20:18, Michael ha scritto: On Saturday, 23 March 2024 19:10:28 GMT you wrote: Il 23/03/24 19:43, Michael ha scritto: On Saturday, 23 March 2024 18:29:58 GMT ralfconn wrote: Il 23/03/24 18:42, Michael ha scritto: > I suggest it would be best to take heed of the devs hard work and read the > instructions they have provided instead of winging it: > > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructio > ns I'm currently running a local merged profile: # cat /var/db/repos/local/profiles/no-multilib-hardened-desktop/parent gentoo:default/linux/amd64/17.1/no-multilib/hardened gentoo:targets/desktop $ euse -a | grep usr split-usr [+ D F ] I suppose that before step 3 of the wiki I'd need to create a new local merged profile, e.g.: #cat /var/db/repos/local/profiles/23.0-split-usr-no-multilib-hardened-desktop/ par ent gentoo:default/linux/amd64/23.0/split-usr/no-multilib/hardened gentoo:targets/split-usr/desktop Does that make sense? thanks raf Update portage and check the profiles offered by 'eselect profile list'. For example, I can see: [51] default/linux/amd64/23.0/split-usr/no-multilib/hardened (stable) which should provide what you're after. It's not a 'desktop' profile I'd think once you emerge/update the desktop environment or main packages you want, most of the desktop related USE choices will be applied anyway. In the first instance I'd select the above profile ([51]), update your toolchain and try an emerge --pretend of @world to see what USE flag differences remain. If this approach leaves you short you can always create your own merged profile as you had done. (Due to my mistake the last message was sent to me only instead of the list) Unfortunately not, the non-desktop profile is very stripped-down compared to the desktop one. There's maybe 20 or more USE flags present in my merged profile that are missing from [51]. In the meanwhile I tried to switch to my merged 23.0 profile, in step 9 binutils updates fine while gcc builds but fails to install with no error message, so for now I'm back to 'merged' 17.1. Tomorrow I'll try to analyze the install log better. BTW, the only differences comparing emerge --info before and after the switch are: LDFLAGS="-Wl,-O1 -Wl,--as-needed" vs LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs" and USE = "cli fortran" that after the switch disappear in favour of the new ones USE = "lzma zstd" (at least, in my 'crooked' local profile)
Re: [gentoo-user] New profiles 23.0
Michael wrote: > On Saturday, 23 March 2024 17:33:17 GMT Dale wrote: >> Peter Humphrey wrote: >>> On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote: On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote: > Hello list, > > Has anyone tried the profile upgrade that was notified today? I tried it > just now on a small rescue system and it failed on installing the first > binary package, complaining that my disk layout was split-usr. > > My /var is on a separate partition, for easy of file recovery, but /usr > is > not. Is this the cause of the problem? Please ignore that. Three seconds later I realised what I should have done: run emerge-usr first. >>> No, that's wrong too. I need to do a bit of head-scratching. >> I just did my weekly sync. I'm currently on this profile. >> >> >> [8] default/linux/amd64/17.1/desktop/plasma (stable) * >> >> >> To find the profile I want to upgrade to, I look for the same name but >> with the added split-usr added, for us old fuggys who still do things >> the OLD way. ;-) >> >> >> [48] default/linux/amd64/23.0/split-usr/desktop/plasma (exp) >> >> >> If one uses systemd, look for the same thing as old but with systemd. >> Same with no-multilib or some of the other options. Basically, just >> look for the same as old but with the new bits you need. >> >> I have a spare hard drive that I do my updates on. It's like a stage 4 >> thing that I update with a script, if you can call it that, right after >> syncing. I chroot in and do my updates there. If anything goes wrong, >> I just reset back to the stage 4 and try again if worse comes to worse. >> Once done, I copy the packages over to my main system and add -k to >> emerge. It makes updates a lot faster and stable. Sometimes during KDE >> updates, things can get out of sync and things stop working. Having >> packages that take a long time to compile makes that worse. The qt >> package, LOo, Firefox etc etc. You can be sure I'm going to do that >> with this update. It's gonna take long enough to do the -k bit much >> less the actual compile part. I seem to recall we have to do a emerge >> -e world with this. o_O >> >> I hope that helps you pick the correct one. I been concerned about the >> switch too. It's easy to mess up something. >> >> Dale >> >> :-) :-) > I suggest it would be best to take heed of the devs hard work and read the > instructions they have provided instead of winging it: > > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions > I just read the news item which kinda says what I posted. It listed a couple examples as well. I just went with what I have in case it would clear up any muddy waters. In my chroot, I'm to the gcc build. Dale :-) :-)
Re: [gentoo-user] New profiles 23.0
On Saturday, 23 March 2024 18:29:58 GMT ralfconn wrote: > Il 23/03/24 18:42, Michael ha scritto: > > I suggest it would be best to take heed of the devs hard work and > > read the > > > instructions they have provided instead of winging it: > > > > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions > > I'm currently running a local merged profile: > > # cat /var/db/repos/local/profiles/no-multilib-hardened-desktop/parent > gentoo:default/linux/amd64/17.1/no-multilib/hardened > gentoo:targets/desktop > > $ euse -a | grep usr > split-usr [+ D F ] > > I suppose that before step 3 of the wiki I'd need to create a new local > merged profile, e.g.: > > #cat > /var/db/repos/local/profiles/23.0-split-usr-no-multilib-hardened-desktop/par > ent gentoo:default/linux/amd64/23.0/split-usr/no-multilib/hardened > gentoo:targets/split-usr/desktop > > Does that make sense? > > thanks > > raf Update portage and check the profiles offered by 'eselect profile list'. For example, I can see: [51] default/linux/amd64/23.0/split-usr/no-multilib/hardened (stable) which should provide what you're after. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profiles 23.0
Il 23/03/24 18:42, Michael ha scritto: > I suggest it would be best to take heed of the devs hard work and read the > instructions they have provided instead of winging it: > > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions > I'm currently running a local merged profile: # cat /var/db/repos/local/profiles/no-multilib-hardened-desktop/parent gentoo:default/linux/amd64/17.1/no-multilib/hardened gentoo:targets/desktop $ euse -a | grep usr split-usr [+ D F ] I suppose that before step 3 of the wiki I'd need to create a new local merged profile, e.g.: #cat /var/db/repos/local/profiles/23.0-split-usr-no-multilib-hardened-desktop/parent gentoo:default/linux/amd64/23.0/split-usr/no-multilib/hardened gentoo:targets/split-usr/desktop Does that make sense? thanks raf
Re: [gentoo-user] New profiles 23.0
On Saturday, 23 March 2024 17:33:17 GMT Dale wrote: > Peter Humphrey wrote: > > On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote: > >> On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote: > >>> Hello list, > >>> > >>> Has anyone tried the profile upgrade that was notified today? I tried it > >>> just now on a small rescue system and it failed on installing the first > >>> binary package, complaining that my disk layout was split-usr. > >>> > >>> My /var is on a separate partition, for easy of file recovery, but /usr > >>> is > >>> not. Is this the cause of the problem? > >> > >> Please ignore that. Three seconds later I realised what I should have > >> done: run emerge-usr first. > > > > No, that's wrong too. I need to do a bit of head-scratching. > > I just did my weekly sync. I'm currently on this profile. > > > [8] default/linux/amd64/17.1/desktop/plasma (stable) * > > > To find the profile I want to upgrade to, I look for the same name but > with the added split-usr added, for us old fuggys who still do things > the OLD way. ;-) > > > [48] default/linux/amd64/23.0/split-usr/desktop/plasma (exp) > > > If one uses systemd, look for the same thing as old but with systemd. > Same with no-multilib or some of the other options. Basically, just > look for the same as old but with the new bits you need. > > I have a spare hard drive that I do my updates on. It's like a stage 4 > thing that I update with a script, if you can call it that, right after > syncing. I chroot in and do my updates there. If anything goes wrong, > I just reset back to the stage 4 and try again if worse comes to worse. > Once done, I copy the packages over to my main system and add -k to > emerge. It makes updates a lot faster and stable. Sometimes during KDE > updates, things can get out of sync and things stop working. Having > packages that take a long time to compile makes that worse. The qt > package, LOo, Firefox etc etc. You can be sure I'm going to do that > with this update. It's gonna take long enough to do the -k bit much > less the actual compile part. I seem to recall we have to do a emerge > -e world with this. o_O > > I hope that helps you pick the correct one. I been concerned about the > switch too. It's easy to mess up something. > > Dale > > :-) :-) I suggest it would be best to take heed of the devs hard work and read the instructions they have provided instead of winging it: https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profiles 23.0
Peter Humphrey wrote: > On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote: >> On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote: >>> Hello list, >>> >>> Has anyone tried the profile upgrade that was notified today? I tried it >>> just now on a small rescue system and it failed on installing the first >>> binary package, complaining that my disk layout was split-usr. >>> >>> My /var is on a separate partition, for easy of file recovery, but /usr is >>> not. Is this the cause of the problem? >> Please ignore that. Three seconds later I realised what I should have done: >> run emerge-usr first. > No, that's wrong too. I need to do a bit of head-scratching. > I just did my weekly sync. I'm currently on this profile. [8] default/linux/amd64/17.1/desktop/plasma (stable) * To find the profile I want to upgrade to, I look for the same name but with the added split-usr added, for us old fuggys who still do things the OLD way. ;-) [48] default/linux/amd64/23.0/split-usr/desktop/plasma (exp) If one uses systemd, look for the same thing as old but with systemd. Same with no-multilib or some of the other options. Basically, just look for the same as old but with the new bits you need. I have a spare hard drive that I do my updates on. It's like a stage 4 thing that I update with a script, if you can call it that, right after syncing. I chroot in and do my updates there. If anything goes wrong, I just reset back to the stage 4 and try again if worse comes to worse. Once done, I copy the packages over to my main system and add -k to emerge. It makes updates a lot faster and stable. Sometimes during KDE updates, things can get out of sync and things stop working. Having packages that take a long time to compile makes that worse. The qt package, LOo, Firefox etc etc. You can be sure I'm going to do that with this update. It's gonna take long enough to do the -k bit much less the actual compile part. I seem to recall we have to do a emerge -e world with this. o_O I hope that helps you pick the correct one. I been concerned about the switch too. It's easy to mess up something. Dale :-) :-)
Re: [gentoo-user] New profiles 23.0
On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote: > On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote: > > Hello list, > > > > Has anyone tried the profile upgrade that was notified today? I tried it > > just now on a small rescue system and it failed on installing the first > > binary package, complaining that my disk layout was split-usr. > > > > My /var is on a separate partition, for easy of file recovery, but /usr is > > not. Is this the cause of the problem? > > Please ignore that. Three seconds later I realised what I should have done: > run emerge-usr first. The advice on the e-news item is to switch to the new 23.0 profile first using the same fs structure you currently have and then to proceed with the migration to a merged-usr. Therefore if you have a split usr fs structure, you need to select a 'split- usr' 23.0 profile. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profiles 23.0
On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote: > On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote: > > Hello list, > > > > Has anyone tried the profile upgrade that was notified today? I tried it > > just now on a small rescue system and it failed on installing the first > > binary package, complaining that my disk layout was split-usr. > > > > My /var is on a separate partition, for easy of file recovery, but /usr is > > not. Is this the cause of the problem? > > Please ignore that. Three seconds later I realised what I should have done: > run emerge-usr first. No, that's wrong too. I need to do a bit of head-scratching. -- Regards, Peter.
Re: [gentoo-user] New profiles 23.0
On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote: > Hello list, > > Has anyone tried the profile upgrade that was notified today? I tried it > just now on a small rescue system and it failed on installing the first > binary package, complaining that my disk layout was split-usr. > > My /var is on a separate partition, for easy of file recovery, but /usr is > not. Is this the cause of the problem? Please ignore that. Three seconds later I realised what I should have done: run emerge-usr first. -- Regards, Peter.
[gentoo-user] New profiles 23.0
Hello list, Has anyone tried the profile upgrade that was notified today? I tried it just now on a small rescue system and it failed on installing the first binary package, complaining that my disk layout was split-usr. My /var is on a separate partition, for easy of file recovery, but /usr is not. Is this the cause of the problem? -- Regards, Peter.
Re: [gentoo-user] Terminal emulator to replace Konsole
On Fri, Mar 22, 2024 at 03:01:44PM -0500, Dale wrote: > Howdy, > > I looked in x11-terms and there is a few options, I think. I tried > looking at home pages and such but none of them mention a feature like > this but it may have it. I was wondering if anyone knows of a terminal > emulator that allows the mouse to place the cursor to edit parts or > whole sections of a command. Some of my commands are really long and it > seems the part I want to edit is always at the beginning. :/ > x11-terms/kitty can do this since it added some shell integration features (requires bash, zsh, or fish and a rc file to be loaded which is done by default), aka you can click anywhere in the command and it'll place the cursor there. The shell integration bits can also do things like open the output of the last command in a pager even if haven't done e.g. "... | less" or instantly copy it for pasting without awkwardly scrolling to select everything. Has quite a vast amount of features and configuration options, albeit it may come as a bit quirky and with a learning curve if coming from konsole (e.g. it does not even have a context menu and can only be configured by editing the .conf file directly), and is mostly intended for use with various keyboard binds than with pretty menus. -- ionen signature.asc Description: PGP signature
[gentoo-user] Re: Terminal emulator to replace Konsole
On 2024-03-23, Mickaël Bucas wrote: > I think it's not a terminal emulator feature, but rather a shell > feature. > > Some terminal programs are designed to interact with the mouse, but > bash command line, based on readline, doesn't react to mouse clicks. Agreed. > I've tried Midnight Commander in Konsole and xterm, and it actually > moves the cursor to the click position in its own command line ! > > Maybe there's an extension or set of parameters for bash or other > shells to handle mouse clicks, but I'm not aware of it. I vaguely recall that there was some sort zsh hack/addon/module that added extra mouse functionality, but I don't recall the details (I was never a zsh user). -- Grant
Re: [gentoo-user] Terminal emulator to replace Konsole
Le ven. 22 mars 2024 à 21:02, Dale a écrit : > > Howdy, > > I've been using Konsole, part of KDE, for command line stuff ever since > I started using Linux. Linux is all I've ever used. No windoze. ;-) > While Konsole is good enough for almost everything, there is one feature > I wish it had. The ability to edit with the mouse. I don't know of a > way to make it do this. The only way I know of to edit a command, left > arrow to what you want to edit and change it. I'd like to find one > where I can use the mouse to place the cursor and edit from there. Even > maybe highlight and replace. As far as I know, Konsole doesn't have > that ability. > > I looked in x11-terms and there is a few options, I think. I tried > looking at home pages and such but none of them mention a feature like > this but it may have it. I was wondering if anyone knows of a terminal > emulator that allows the mouse to place the cursor to edit parts or > whole sections of a command. Some of my commands are really long and it > seems the part I want to edit is always at the beginning. :/ > > Hoping for some ideas. > > Thanks. > > Dale > > :-) :-) > Hi I think it's not a terminal emulator feature, but rather a shell feature. Some terminal programs are designed to interact with the mouse, but bash command line, based on readline, doesn't react to mouse clicks. I've tried Midnight Commander in Konsole and xterm, and it actually moves the cursor to the click position in its own command line ! Maybe there's an extension or set of parameters for bash or other shells to handle mouse clicks, but I'm not aware of it. Best regards Mickaël Bucas
Re: [gentoo-user] how to prevent ebuild from checking for available space
On Fri, 22 Mar 2024 16:32:28 -0400, Jack wrote: > > Why not add more to the ramdisk, assuming it is a tmpfs. If it needs > > more > > than your physical memory, it will use swap, but that won't happen > > because you only need the extra space. > That's actually what I did. The problem is not how to get enough > space, it's how to resume the emerge instead of starting over, once I > have added the space. > > It was initially set to 14G (out of 32G RAM) and I added 2G. I suppose > I can add another 14G, but that would only leave 4G for the system > itself. I'm not sure how well that would work, but I suppose it's > worth a try. tmpfs only uses the space it needs, so it would appear to the ebuild that there is plenty of space, but it would only use and extra gig or two of your RAM. For me, avoiding tmpfs for big ebuilds is the least hassle, using package.env. % cat /etc/portage/package.env/chromium www-client/chromium disk-tmpdir.conf ... % cat /etc/portage/env/disk-tmpdir.conf PORTAGE_TMPDIR="/mnt/scratch" -- Neil Bothwick Linux like wigwam. No windows, no gates, Apache inside. pgpptIaai7a_R.pgp Description: OpenPGP digital signature
