Re: [gentoo-user] Stage-3 and profile 23.x
On Monday, 25 March 2024 23:14:50 GMT Michael wrote: > On Monday, 25 March 2024 21:48:24 GMT Peter Humphrey wrote: > > On Monday, 25 March 2024 16:52:19 GMT Michael wrote: > > > The default OpenRC installation now assumes a merged-usr fs structure - > > > therefore make sure you select the appropriate profile in a new > > > installation. > > > > I was wondering about that. Now that we have 23.0 in place, are we meant > > to > > change to merged-usr? Should I run the eponymous script? > > You can, if you want to. I've installed sys-apps/merge-usr and ran it on my > OpenRC system, after I completed the migration to profile 23.0. It didn't > take any time at all: > > https://wiki.gentoo.org/wiki/Merge-usr I'd want a good reason to do so, as I can't imagine it being reversed easily - I'd need to keep a backup of /bin, /usr and so on which I could restore if necessary, then run emerge -e @world and save those directories again. Not worth the candle. There being no foreseeable prospect of the systemd bandwagon picking me up on its way by, I think I'll stick to what I know*. * For some vague approximation to 'know'. :) -- Regards, Peter.
Re: [gentoo-user] Question about emerge sync and where it all goes.
Michael wrote: > On Monday, 25 March 2024 02:58:21 GMT Dale wrote: >> Howdy, >> >> I've mentioned before that I build my packages in a chroot. I have a OS >> copy on a separate drive. I do this because of the long compile times >> of some packages. On occasion tho, I catch the tree in a bad place. >> Some conflict or other happens and I need to sync again to get fixes >> etc. Given my process tho, I don't want to sync the chroot without also >> syncing my main system because the two will not be in sync and I'll lose >> my update since it deletes files as well including any updates I did >> emerge successfully. I need the two to be identical. So, I'd like to >> sync my main system and then copy the new data over to the chroot >> without copying the rest of the OS. > What you do is duplicating effort and storage space with questionable > benefit, > besides warming up your room. I think it would be more efficient if you used > the same /var/cache/distfiles and /var/db/repos/ filesystems on both > installations. This way you'd sync once and then download any source files > once only. > > However, an even more optimised solution would be to compile packages once in > your chrooted fs with the '--buildpkg y' option and then emerge these as > binary packages from /var/cache/binpkgs/ in your production OS. An overnight > emerge in the chrooted OS will take only a few minutes on the production > system. > One reason for doing it this way, I have a backup of my OS as well. Both are generally identical. If my main hard drive were to fail, I could boot rescue media and copy what I usually chroot into over to a new drive, reinstall grub and such then boot back up. Should be back up and running in likely less than a hour, if that. I took the idea from a stage4 thing I found. I just don't compress it since I use it. After all, that 750GB hard drive is only used for hourly backups of my email. May as well put the rest of the thing to some use. The buildpkg option is kinda what happens except I let it also install and that gives me a backup OS as well. The main drive with the OS on it is a bit old. It is a drive designed for 24/7 use and years of service. Still, it could blow smoke or start making noises at any time, or run for many more years until a OS won't fit on it anymore. It's already getting pretty full. LOL Someone on this list mailed it to me years ago with my previous build I think. The updates from binary packages only takes a few minutes unless the number of packages is huge. Usually a HUGE KDE update and LOo or something added on top of that can take a hour or so. Still, much faster and more stable than trying to compile on my running OS. Things get out of sync and some programs start acting weird or won't open due to a version mismatch. >> I did this with the following command earlier. >> >> rsync -av --progress --delete /var/cache/portage/tree/* >> /backup/gentoo-build/var/cache/portage/tree/ > Your syntax for the source tree will fail to copy a couple files immediately > under /var/cache/portage/tree/ which start with "." > > It would be better if you used: > > /var/cache/portage/tree /backup/gentoo-build/var/cache/portage/tree > I edited that in my little script. The locations with rsync can be tricky. Each way that one can use gives a slightly different execution. >> As you can see, my tree location is not the default. It is located at >> /var/cache/portage/tree/. It's the same on the chroot obviously. Would >> the above command copy all the needed files/directories over that it >> needs after a emerge sync or is there more to it? The reason I think it >> needs more, when I tried to do the usual emerge -aukDN world on my main >> system, it wanted to emerge more packages than the chroot did. I >> suspect there is more to it than just the tree directory. >> >> Anyone have the details on this? Anyone know what other >> files/directories need to be copied over as well? >> >> Thanks. >> >> Dale >> >> :-) :-) > Did you diff /var/lib/portage/world between the two systems to see what > differences may be there? > > I can think of a hypothetical case where the chrooted fs may have already > emerged build time dependencies, e.g. if some emerge failed and then you > fixed/restarted it a number of times, but the production system would not yet > have such build time dependencies installed. The world file is also copied over each time. Sometimes I install something on the running OS and I also want it on the other. I keep the two pretty well synced. It could be the path change you listed above will change things. I'll know the next time I have to do this. I was even wondering if after copying the tree over, I needed to run a command to update something to make sure emerge would see the changes. I knew it was doing something different between the two but only did so after I copied the tree over. I figured I missed something, be it a file that
[gentoo-user] Re: Stage-3 and profile 23.x
On 2024-03-25, Michael wrote: > On Monday, 25 March 2024 21:48:24 GMT Peter Humphrey wrote: >> On Monday, 25 March 2024 16:52:19 GMT Michael wrote: >> >>> The default OpenRC installation now assumes a merged-usr fs structure - >>> therefore make sure you select the appropriate profile in a new >>> installation. >> >> I was wondering about that. Now that we have 23.0 in place, are we meant to >> change to merged-usr? Should I run the eponymous script? > > You can, if you want to. I've installed sys-apps/merge-usr and ran it on my > OpenRC system, after I completed the migration to profile 23.0. It didn't > take any time at all: > > https://wiki.gentoo.org/wiki/Merge-usr I'm in the process of switching two machines fom 17.1 to 23.0/split-usr [emerge @world will probably take overnight.] I've read the merge-usr page, and it looks pretty simple. But, I'm going to run 23.0 split-usr for a few weeks first -- just to make sure that the new profile hasn't broken anything. If you run OpenRC, it doesn't sound like there's any real reason you need to do the merge any time soon. If you run systemd, there's some version number cutoff where it will refuse to work on a split-usr install (IIRC). After all, the systgemd motto is "all your computer are belong to us!" -- Grant
Re: [gentoo-user] Stage-3 and profile 23.x
On Monday, 25 March 2024 21:48:24 GMT Peter Humphrey wrote: > On Monday, 25 March 2024 16:52:19 GMT Michael wrote: > > The default OpenRC installation now assumes a merged-usr fs structure - > > therefore make sure you select the appropriate profile in a new > > installation. > I was wondering about that. Now that we have 23.0 in place, are we meant to > change to merged-usr? Should I run the eponymous script? You can, if you want to. I've installed sys-apps/merge-usr and ran it on my OpenRC system, after I completed the migration to profile 23.0. It didn't take any time at all: https://wiki.gentoo.org/wiki/Merge-usr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Stage-3 and profile 23.x
On 2024.03.25 17:48, Peter Humphrey wrote: On Monday, 25 March 2024 16:52:19 GMT Michael wrote: > The default OpenRC installation now assumes a merged-usr fs structure - > therefore make sure you select the appropriate profile in a new installation. That specifically says for a new installation. I was wondering about that. Now that we have 23.0 in place, are we meant to change to merged-usr? Should I run the eponymous script? From the news item: 3. If you are currently using systemd in a split-usr configuration, then first complete the migration to the corresponding merged-usr profile of the same profile version. Details on how to do this can be found in the news item [4]. If you are currently using openrc, migrate to 23.0 first, keeping your disk layout. If you want to move from split-usr to merged-usr, do that afterwards.
Re: [gentoo-user] Stage-3 and profile 23.x
On Monday, 25 March 2024 16:52:19 GMT Michael wrote: > The default OpenRC installation now assumes a merged-usr fs structure - > therefore make sure you select the appropriate profile in a new installation. I was wondering about that. Now that we have 23.0 in place, are we meant to change to merged-usr? Should I run the eponymous script? -- Regards, Peter.
Re: [gentoo-user] Stage-3 and profile 23.x
Am Montag, 25. März 2024, 16:30:41 CET schrieb Peter Humphrey: > Hello list, > > It would be good if a stage-3 tarball were available with profile 23.x built > in. Sooner or later someone will want to build a new system with such a > profile. > > Is this in the offing? All builders now have instructions to upload 23.0 stages (which have been building silently in the background for the last weeks) on the next run. https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_timeline The "mergedusr" suffix in the stage names is going away, which means the links on the webserver have to be fixed afterwards. > > -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profiles 23.0
Le lun. 25 mars 2024, 18:44, Michael a écrit : > On Monday, 25 March 2024 17:37:40 GMT Jacques Montier wrote: > > Le lun. 25 mars 2024 à 18:18, Michael a > écrit : > > > > Therefore, you can fetch binaries from the mirrors when these have the > > > same > > > configuration as your locally compiled software to make the whole > upgrade > > > complete faster, but it remains a personal choice. > > > > Thanks Michael for your response, > > but how could i know if one package has the same configuration as my > > locally compiled software and if this one is as much tested as the > > source-based package ? > > > > -- > > Jacques Montier > > When the packages on the Gentoo binhost mirror have been compiled with > different USE flags to your choices, these packages will not be fetched > from > the mirror but compiled locally. Have a look here for more details: > > https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart > > > > Thanks a lot, Michael Regards -- Jacques
Re: [gentoo-user] New profiles 23.0
On Monday, 25 March 2024 17:37:40 GMT Jacques Montier wrote: > Le lun. 25 mars 2024 à 18:18, Michael a écrit : > > Therefore, you can fetch binaries from the mirrors when these have the > > same > > configuration as your locally compiled software to make the whole upgrade > > complete faster, but it remains a personal choice. > > Thanks Michael for your response, > but how could i know if one package has the same configuration as my > locally compiled software and if this one is as much tested as the > source-based package ? > > -- > Jacques Montier When the packages on the Gentoo binhost mirror have been compiled with different USE flags to your choices, these packages will not be fetched from the mirror but compiled locally. Have a look here for more details: https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profiles 23.0
Le lun. 25 mars 2024 à 18:18, Michael a écrit : > On Monday, 25 March 2024 17:00:18 GMT Jacques Montier wrote: > > Le lun. 25 mars 2024 à 15:41, Peter Humphrey a > > > > écrit : > > > On Saturday, 23 March 2024 17:42:29 GMT Michael wrote: > > > > 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 > > > > > > Of course I was doing that, but from the news item. My problem was > that I > > > wasn't reading straight. > > > > > > (I think I had a form of covid last month, and it's left a few loose > ends > > > - > > > mostly in my brain!) > > > > > > -- > > > Regards, > > > Peter. > > > > Hello all, > > > > I updated my profile from amd64/17.1/desktop/systemd/merged-usr to > > amd64/23.0/desktop/systemd. > > I followed the quite clear instructions without any issue. > > With emerge --ask --emptytree @world, i had to recompile 1400 packages, > so > > it took all night long !!! > > Some scare when the package 1201 failed and everything stopped (i forgot > > the keep-going option). > > Nevertheless, I rebooted and everything works fine ! Whew !!! > > > > What i understand is that Gentoo is now mostly based on binary packages. > > The sources are now the exception. > > It's the opposite of what Gentoo was before... Right ? > > > > Regards, > > > > -- > > Jacques > > Not really, Gentoo is still based on compiling from source - for those who > want to optimise/customise their systems. > > More recently pre-compiled binary packages which suit generic hardware and > software configurations are also made available for those who want to get > something up and running quickly. This makes Gentoo similar to other > binary > distributions. > > The command syntax in the instructions included "--getbinpkg" to download > pre- > built binaries, but with this note: > > "In case you are already familiar with binary packages, you should be > able to add '--getbinpkg' to the emerge calls to speed things up. > The use of binary packages is completely optional though, and also not > as much tested as the source-based upgrade path yet." > > Therefore, you can fetch binaries from the mirrors when these have the > same > configuration as your locally compiled software to make the whole upgrade > complete faster, but it remains a personal choice. Thanks Michael for your response, but how could i know if one package has the same configuration as my locally compiled software and if this one is as much tested as the source-based package ? -- Jacques Montier
Re: [gentoo-user] New profiles 23.0
On Monday, 25 March 2024 17:00:18 GMT Jacques Montier wrote: > Le lun. 25 mars 2024 à 15:41, Peter Humphrey a > > écrit : > > On Saturday, 23 March 2024 17:42:29 GMT Michael wrote: > > > 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 > > > > Of course I was doing that, but from the news item. My problem was that I > > wasn't reading straight. > > > > (I think I had a form of covid last month, and it's left a few loose ends > > - > > mostly in my brain!) > > > > -- > > Regards, > > Peter. > > Hello all, > > I updated my profile from amd64/17.1/desktop/systemd/merged-usr to > amd64/23.0/desktop/systemd. > I followed the quite clear instructions without any issue. > With emerge --ask --emptytree @world, i had to recompile 1400 packages, so > it took all night long !!! > Some scare when the package 1201 failed and everything stopped (i forgot > the keep-going option). > Nevertheless, I rebooted and everything works fine ! Whew !!! > > What i understand is that Gentoo is now mostly based on binary packages. > The sources are now the exception. > It's the opposite of what Gentoo was before... Right ? > > Regards, > > -- > Jacques Not really, Gentoo is still based on compiling from source - for those who want to optimise/customise their systems. More recently pre-compiled binary packages which suit generic hardware and software configurations are also made available for those who want to get something up and running quickly. This makes Gentoo similar to other binary distributions. The command syntax in the instructions included "--getbinpkg" to download pre- built binaries, but with this note: "In case you are already familiar with binary packages, you should be able to add '--getbinpkg' to the emerge calls to speed things up. The use of binary packages is completely optional though, and also not as much tested as the source-based upgrade path yet." Therefore, you can fetch binaries from the mirrors when these have the same configuration as your locally compiled software to make the whole upgrade complete faster, but it remains a personal choice. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profiles 23.0
Le lun. 25 mars 2024 à 15:41, Peter Humphrey a écrit : > On Saturday, 23 March 2024 17:42:29 GMT Michael wrote: > > > 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 > > Of course I was doing that, but from the news item. My problem was that I > wasn't reading straight. > > (I think I had a form of covid last month, and it's left a few loose ends > - > mostly in my brain!) > > -- > Regards, > Peter. > > > Hello all, I updated my profile from amd64/17.1/desktop/systemd/merged-usr to amd64/23.0/desktop/systemd. I followed the quite clear instructions without any issue. With emerge --ask --emptytree @world, i had to recompile 1400 packages, so it took all night long !!! Some scare when the package 1201 failed and everything stopped (i forgot the keep-going option). Nevertheless, I rebooted and everything works fine ! Whew !!! What i understand is that Gentoo is now mostly based on binary packages. The sources are now the exception. It's the opposite of what Gentoo was before... Right ? Regards, -- Jacques
Re: [gentoo-user] Stage-3 and profile 23.x
On Monday, 25 March 2024 15:30:41 GMT Peter Humphrey wrote: > Hello list, > > It would be good if a stage-3 tarball were available with profile 23.x built > in. Sooner or later someone will want to build a new system with such a > profile. > > Is this in the offing? It is already there; e.g. https://mirror.bytemark.co.uk/gentoo/releases/amd64/autobuilds/ 20240324T164906Z/stage3-amd64-desktop- openrc-20240324T164906Z.tar.xz.CONTENTS.gz >From what I recall make.profile 23.0 has been available for a while now, albeit it was previously shown as experimental (exp). NOTE: The default OpenRC installation now assumes a merged-usr fs structure - therefore make sure you select the appropriate profile in a new installation. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Stage-3 and profile 23.x
Hello list, It would be good if a stage-3 tarball were available with profile 23.x built in. Sooner or later someone will want to build a new system with such a profile. Is this in the offing? -- Regards, Peter.
[gentoo-user] genkernel not creating initramfs image file
Hello,
I'm upgrading to the new profile, so I need to get initramfs working, but
genkernel does not create the image needed.
the output is:
* Gentoo Linux Genkernel; Version 4.3.10
* Using genkernel configuration from '/etc/genkernel.conf' ...
* Running with options: --kernel-config=/usr/src/linux/.config --install
initramfs
* Working with Linux kernel 6.6.21-gentoo for x86_64
* Using kernel config file '/usr/src/linux-6.6.21-gentoo/.config' ...
* mount: >> Boot partition was temporarily mounted on '/boot' ...
* Current kernel's LOCALVERSION is set to ''; Will ignore set
--kernel-localversion value '-x86_64' because kernel was not built ...
* initramfs: >> Initializing ...
* >> Appending devices cpio data ...
* >> Appending base_layout cpio data ...
* >> Appending util-linux cpio data ...
* >> Appending eudev cpio data ...
* >> Appending auxiliary cpio data ...
* >> Appending busybox cpio data ...
* >> Appending modprobed cpio data ...
* >> Appending modules cpio data ...
* >> Deduping cpio ...
* >> Pre-generating initramfs' /etc/ld.so.cache ...
* >> Compressing cpio data (.xz) ...
xz: Reduced the number of threads from 4 to 1 to not exceed the memory usage
limit of 1965 MiB
*
* You will find the initramfs in '/boot/initramfs-6.6.21-gentoo.img'.
* WARNING... WARNING... WARNING...
* Additional kernel parameters that *may* be required to boot properly:
*
* Note:
* You have set CONFIG_CMDLINE_OVERRIDE=y.
* You will be unable to alter set kernel parameters ("root=/dev/sda4
intel_iommu=on iommu=on i8042.noloop i8042.nomux i8042.nopnp i8042.reset
msr.allow_writes=on") at runtime!
* mount: >> Automatically unmounting boot partition from '/boot' as it was
previously ...
* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
*
* Make sure you have the latest ~arch genkernel before reporting bugs.
genkernel does not fail it's execution, but no file on the directory.
I compile my kernels "by hand" (no external tools besides gcc and make), maybe
genkernel expects me to use it from start to finish for the compilation
process? What am I doing wrong?
Thanks in advance,
Dalmon Ian.
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Monday, 25 March 2024 07:04:57 GMT Dale wrote: > Overall, the devs did a really good job with the instructions. Just > have to update first as it says. It works better. ;-) I just wonder > who went through the torture of figuring out what went in what order. O_O Indeed, they've done a thorough job - and not, I assume, just the one whose name appears on the news item. -- Regards, Peter.
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: --->8 > I saw where Peter mentioned in another thread gcc failing with no error > message for him. This could be related. Nope. I was all fingers and thumbs at the time, now all straightened out. -- Regards, Peter.
Re: [gentoo-user] New profiles 23.0
On Saturday, 23 March 2024 17:42:29 GMT Michael wrote: > 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 Of course I was doing that, but from the news item. My problem was that I wasn't reading straight. (I think I had a form of covid last month, and it's left a few loose ends - mostly in my brain!) -- Regards, Peter.
Re: [gentoo-user] how to prevent ebuild from checking for available space
On 23/03/2024 09:20, Neil Bothwick wrote: 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. I've yet to set my current system up with a tmpfs, but that's my preferred setup. Iirc, my current mobo takes 4x16GB chips, so "double ram as swap" makes 128GB - I put that on every disk (I have 3 or 4), so I've probably got not far short of 1/2TB swap! So nearly all of my build spaces, I would typically have a ramdisk of maybe 128GB. As previously mentioned, it only uses what space it needs, so I guess with 32GB of real RAM, with most stuff my system wouldn't touch swap even with huge ramdisks being declared. Cheers, Wol
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
Il 25/03/24 08:04, Dale ha scritto: Here is my update. I wanted to skip the system update and change profiles first. Then do the emerge -e world which would also update anything that was new as well. I'd only have to compile once tho. Well, that may have caused a problem. It may work for some but it didn't here. I first had to do my usual emerge -auDN world and get a clean run. I had one build to fail, had to work on that. Anyway, where it says update first, it is best to do that. It might work if you don't, might not. I'm now up to the part where I recompile everything. Oh the joy. At least it is a cool night so the extra heat will keep me warm. ROFL As I noted in another thread, the profile switch involves a change in the LDFLAGS, with the addition of the 'pack-relative-relocs' option. https://rfc.archlinux.page/0023-pack-relative-relocs/ suggests that adding this flag might trigger issues with tools not up-to-date. I suppose that is why the gentoo devs instruct to rebuild binutils/gcc before 'emerge -e', and that might be the reason why your first attempt worked only partially. BTW my update to split-usr 23-0 went pretty smoothly, next will be to go with the merged-usr. raf
Re: [gentoo-user] New profile, gcc-13.2.1_p20240210 fails to build. ATTN: Peter Humphrey.
On Monday, 25 March 2024 07:04:57 GMT Dale wrote: > Paul Colquhoun wrote: > > I had the gcc compile fail, but was successful after removing the "objc" > > use flag. > > > > Unfortunately, it seemd to be required by app-arch/unar during step 16, > > rebuild world. > > > > I'm re-enbleing it and will see how it all goes. > > Here is my update. I wanted to skip the system update and change > profiles first. Then do the emerge -e world which would also update > anything that was new as well. I'd only have to compile once tho. > Well, that may have caused a problem. It may work for some but it > didn't here. I first had to do my usual emerge -auDN world and get a > clean run. I had one build to fail, had to work on that. Anyway, where > it says update first, it is best to do that. It might work if you > don't, might not. I'm trying to do the same on an old, slow PC which had not been touched for a few months now. Most packages would need updating anyway and didn't fancy spending a week to get it up to date before changing the profile, only to rebuild everything once more. We'll see how it goes ... > Overall, the devs did a really good job with the instructions. Just > have to update first as it says. It works better. ;-) A big thank you to the devs for their effort to make our life easier! signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Question about emerge sync and where it all goes.
On Monday, 25 March 2024 02:58:21 GMT Dale wrote: > Howdy, > > I've mentioned before that I build my packages in a chroot. I have a OS > copy on a separate drive. I do this because of the long compile times > of some packages. On occasion tho, I catch the tree in a bad place. > Some conflict or other happens and I need to sync again to get fixes > etc. Given my process tho, I don't want to sync the chroot without also > syncing my main system because the two will not be in sync and I'll lose > my update since it deletes files as well including any updates I did > emerge successfully. I need the two to be identical. So, I'd like to > sync my main system and then copy the new data over to the chroot > without copying the rest of the OS. What you do is duplicating effort and storage space with questionable benefit, besides warming up your room. I think it would be more efficient if you used the same /var/cache/distfiles and /var/db/repos/ filesystems on both installations. This way you'd sync once and then download any source files once only. However, an even more optimised solution would be to compile packages once in your chrooted fs with the '--buildpkg y' option and then emerge these as binary packages from /var/cache/binpkgs/ in your production OS. An overnight emerge in the chrooted OS will take only a few minutes on the production system. > I did this with the following command earlier. > > rsync -av --progress --delete /var/cache/portage/tree/* > /backup/gentoo-build/var/cache/portage/tree/ Your syntax for the source tree will fail to copy a couple files immediately under /var/cache/portage/tree/ which start with "." It would be better if you used: /var/cache/portage/tree /backup/gentoo-build/var/cache/portage/tree > As you can see, my tree location is not the default. It is located at > /var/cache/portage/tree/. It's the same on the chroot obviously. Would > the above command copy all the needed files/directories over that it > needs after a emerge sync or is there more to it? The reason I think it > needs more, when I tried to do the usual emerge -aukDN world on my main > system, it wanted to emerge more packages than the chroot did. I > suspect there is more to it than just the tree directory. > > Anyone have the details on this? Anyone know what other > files/directories need to be copied over as well? > > Thanks. > > Dale > > :-) :-) Did you diff /var/lib/portage/world between the two systems to see what differences may be there? I can think of a hypothetical case where the chrooted fs may have already emerged build time dependencies, e.g. if some emerge failed and then you fixed/restarted it a number of times, but the production system would not yet have such build time dependencies installed. 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.
Paul Colquhoun wrote: > I had the gcc compile fail, but was successful after removing the "objc" use > flag. > > Unfortunately, it seemd to be required by app-arch/unar during step 16, > rebuild world. > > I'm re-enbleing it and will see how it all goes. > > Here is my update. I wanted to skip the system update and change profiles first. Then do the emerge -e world which would also update anything that was new as well. I'd only have to compile once tho. Well, that may have caused a problem. It may work for some but it didn't here. I first had to do my usual emerge -auDN world and get a clean run. I had one build to fail, had to work on that. Anyway, where it says update first, it is best to do that. It might work if you don't, might not. I'm now up to the part where I recompile everything. Oh the joy. At least it is a cool night so the extra heat will keep me warm. ROFL Oh, where it says to emerge gcc and no dependencies, may as well go ahead and add the --nodeps bit. It has to run that way anyway so it doesn't hurt anything but it does save time since emerge doesn't need to look to see if anything else needs to be updated or you have to go back and add the option to insure it doesn't. On my rig, which isn't the fastest or slowest, it saves a couple minutes. YMMV. Overall, the devs did a really good job with the instructions. Just have to update first as it says. It works better. ;-) I just wonder who went through the torture of figuring out what went in what order. O_O Dale :-) :-)
