Re: [gentoo-user] eselect repository and adding overlay.
Michael wrote: > On Sunday, 7 April 2024 20:17:31 BST Dale wrote: >> Howdy, >> >> A while back using overlays changed. Using eselect is supposed to be >> the new way, and easier. Either I'm missing something or something is >> missing from the docs. I tried to add voyageur to my NAS box/backup >> rig. The command to add it works fine. However, when I try to sync it, >> either just the overlay or the whole tree with eix-sync, I get this: >> > Syncing repository 'voyageur' into '/var/db/repos/voyageur'... >> /usr/bin/git clone --depth 1 >> https://cafarelli.fr/cgi-bin/cgit.cgi/voyageur-overlay/ . >> fatal: destination path '.' already exists and is not an empty directory. >> !!! git clone error in /var/db/repos/voyageur >> >> Action: sync for repo: gentoo, returned code = 0 >> Action: sync for repo: voyageur, returned code = 128 >> >> >> >> When I try to emerge something, anything will do, I start seeing this. >> >> >> >> WARNING: One or more repositories have missing repo_name entries: >> >> /var/db/repos/voyageur/profiles/repo_name >> >> NOTE: Each repo_name entry should be a plain text file containing a >> unique name for the repository on the first line. >> >> >> Shouldn't adding the overlay or syncing it fix that? Shouldn't all the >> files it needs be put there by either eselect or a sync? > If you have older files in there it may be causing a clash. I'd run: > > eselect repository remove -f voyageur > > Then check the directory /var/db/repos/ no longer contains the subdirectory > voyager. If it does remove it manually. Then add the repository afresh: > > eselect repository add voyageur > > and finally try to resync it. Should the error repeat itself, then something > must be amiss with the overlay itself and you should report it to the overlay > maintainer. > > HTH, I tested another overlay, it works. Maybe it is the voyageur overlay itself. Now to figure out how to fix it. I guess I could copy the directory from my main rig to the NAS box rig. My main rig isn't complaining. Yet. Thanks. Didn't occur to me that it was the overlay itself. :/ Dale :-) :-)
Re: [gentoo-user] eselect repository and adding overlay.
On Sunday, 7 April 2024 20:17:31 BST Dale wrote: > Howdy, > > A while back using overlays changed. Using eselect is supposed to be > the new way, and easier. Either I'm missing something or something is > missing from the docs. I tried to add voyageur to my NAS box/backup > rig. The command to add it works fine. However, when I try to sync it, > either just the overlay or the whole tree with eix-sync, I get this: > > >>> Syncing repository 'voyageur' into '/var/db/repos/voyageur'... > > /usr/bin/git clone --depth 1 > https://cafarelli.fr/cgi-bin/cgit.cgi/voyageur-overlay/ . > fatal: destination path '.' already exists and is not an empty directory. > !!! git clone error in /var/db/repos/voyageur > > Action: sync for repo: gentoo, returned code = 0 > Action: sync for repo: voyageur, returned code = 128 > > > > When I try to emerge something, anything will do, I start seeing this. > > > > WARNING: One or more repositories have missing repo_name entries: > > /var/db/repos/voyageur/profiles/repo_name > > NOTE: Each repo_name entry should be a plain text file containing a > unique name for the repository on the first line. > > > Shouldn't adding the overlay or syncing it fix that? Shouldn't all the > files it needs be put there by either eselect or a sync? If you have older files in there it may be causing a clash. I'd run: eselect repository remove -f voyageur Then check the directory /var/db/repos/ no longer contains the subdirectory voyager. If it does remove it manually. Then add the repository afresh: eselect repository add voyageur and finally try to resync it. Should the error repeat itself, then something must be amiss with the overlay itself and you should report it to the overlay maintainer. HTH, signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] systemd unit executing but not persistent later in boot
On 4/6/24 18:38, Andrew Udvare wrote: On Sat, 6 Apr 2024 at 21:32, Daniel Frey wrote: What's even stranger is if I manually start it and restart lircd it works! Have you tried adding Before=lircd.service in the [Unit] section? OK, I have finally sorted out the IR keymap/lircd/irexec/LCDd problems. It turns out the systemd units as shipped just simply do not work, at least for my hardware. The custom unit I made to apply a new keytable and protocol change was working fine. After a lot of reading about systemd units and also poring through logs, I discovered udev was triggering something related to the LCD/IR module - my custom unit was running before this happened but the udev trigger reset it to defaults (for whatever reason.) In order to fix that, I had to change my unit to this: [Unit] Description=Add custom keymap to iMon remote Requires=systemd-udevd.service systemd-udev-settle.service systemd-udev-trigger.service After=systemd-udevd.service systemd-udev-settle.service systemd-udev-trigger.service Before=lircd.service inputlircd.service irexec.service [Service] RemainAfterExit=true ExecStart=/usr/bin/ir-keytable -c -p rc-6 -w /etc/rc_keymaps/imon_mce.toml [Install] WantedBy=multi-user.target RequiredBy=lircd.service irexec.service This made the keymap change work reliably. After this lircd was working normally. I use lircd so I can use irexec to listen for the power button and just shut the computer off. Kodi is too finicky and just wouldn't turn off or it would just logout, even with the polkit policy in the wiki applied. Now, starting irexec didn't work the the shipped systemd unit either, it would just exit and not stay running. I fixed that with this custom unit: [Unit] Documentation=man:irexec(1) Documentation=http://lirc.org/html/configure.html Documentation=http://lirc.org/html/configure.html#lircrc_format Description=Handle events from IR remotes decoded by lircd(8) After=lircd.service Requires=lircd.service [Service] ; user=lirc ; group=lirc ; Hardening opts, see systemd.exec(5). Doesn't add much unless ; not running as root. If these are applicable or not depends on ; what commands irexec.lircrc invokes. ; ; NoNewPrivileges=true ; MemoryDenyWriteExecute=true ; PrivateTmp=true ; ProtectHome=true ; ProtectSystem=full Type=forking ExecStart=/usr/bin/irexec --daemon /etc/lirc/irexec.lircrc [Install] WantedBy=multi-user.target So irexec would start and actually stay running. I did also tell it to start after lircd (although I'm not 100% sure this matters - it may not.) Of course the LCD unit wouldn't start and stay running either, again the systemd unit shipped didn't work so I customized it: [Unit] Description=LCDProc (LCDd) After=network-online.target lircd.service Requires=lircd.service [Service] ExecStart=/usr/sbin/LCDd -c /etc/LCDd.conf Type=forking [Install] WantedBy=multi-user.target After all this, then Kodi wouldn't start up. I figured out quickly this was caused by lightdm starting before the network was ready, fixed with this custom unit: [Unit] Description=Light Display Manager Documentation=man:lightdm(1) After=systemd-user-sessions.service After=network-online.target Wants=network-online.target [Service] ExecStart=/usr/sbin/lightdm Restart=always IgnoreSIGPIPE=no BusName=org.freedesktop.DisplayManager [Install] Alias=display-manager.service Hopefully this may be helpful to others with HTPCs switching to systemd from openrc. In openrc nearly all of this customization isn't needed - I only modified /etc/init.d/lircd in openrc in order to load the keymap before lircd started. Dan
[gentoo-user] eselect repository and adding overlay.
Howdy, A while back using overlays changed. Using eselect is supposed to be the new way, and easier. Either I'm missing something or something is missing from the docs. I tried to add voyageur to my NAS box/backup rig. The command to add it works fine. However, when I try to sync it, either just the overlay or the whole tree with eix-sync, I get this: >>> Syncing repository 'voyageur' into '/var/db/repos/voyageur'... /usr/bin/git clone --depth 1 https://cafarelli.fr/cgi-bin/cgit.cgi/voyageur-overlay/ . fatal: destination path '.' already exists and is not an empty directory. !!! git clone error in /var/db/repos/voyageur Action: sync for repo: gentoo, returned code = 0 Action: sync for repo: voyageur, returned code = 128 When I try to emerge something, anything will do, I start seeing this. WARNING: One or more repositories have missing repo_name entries: /var/db/repos/voyageur/profiles/repo_name NOTE: Each repo_name entry should be a plain text file containing a unique name for the repository on the first line. Shouldn't adding the overlay or syncing it fix that? Shouldn't all the files it needs be put there by either eselect or a sync? Can someone give the exact steps it takes to add a overlay and it not error out? Maybe someone has some notes or something?? I've went through the docs a few times and it gets me back to this problem. Something is wrong somewhere. Oh, I tried to google this, all I find is hits about the old layman days. Doesn't really apply now. Need more up to date info. Thanks. Dale :-) :-)
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 16:08, Michael wrote: Cool, once your system is up to date you should be able to change your profile and follow the rest of the instructions. I hope all goes well. emerge --emptytree is now running well - 122 of 1534 so it has some way to go ... Cheers, Wol
Re: [gentoo-user] systemd unit executing but not persistent later in boot
On 4/6/24 18:38, Andrew Udvare wrote: On Sat, 6 Apr 2024 at 21:32, Daniel Frey wrote: What's even stranger is if I manually start it and restart lircd it works! Have you tried adding Before=lircd.service in the [Unit] section? I did, it made no difference. From what I can tell it is running before lircd. I have disabled lircd. Ran daemon-reload and rebooted. For some reason, systemctl is saying it has run and exited successfully according to the timestamps: # systemctl status ir-key-map ○ ir-key-map.service - Add custom keymap to iMon remote Loaded: loaded (/etc/systemd/system/ir-key-map.service; enabled; preset: disabled) Active: inactive (dead) since Sun 2024-04-07 08:56:18 PDT; 1min 36s ago Duration: 48ms Process: 295 ExecStart=/usr/bin/ir-keytable -c -p rc-6 -w /etc/rc_keymaps/imon_mce.toml (code=exited, status=0/SUCCESS) Main PID: 295 (code=exited, status=0/SUCCESS) CPU: 19ms Apr 07 08:56:18 htpclivingrm systemd[1]: Started Add custom keymap to iMon remote. Apr 07 08:56:18 htpclivingrm ir-keytable[295]: Read imon_mce table Apr 07 08:56:18 htpclivingrm ir-keytable[295]: Old keytable cleared Apr 07 08:56:18 htpclivingrm ir-keytable[295]: Wrote 76 keycode(s) to driver Apr 07 08:56:18 htpclivingrm ir-keytable[295]: Protocols changed to rc-6 Apr 07 08:56:18 htpclivingrm systemd[1]: ir-key-map.service: Deactivated successfully. But, it doesn't actually change the protocol. It says it has "ir-keytable[295]: Protocols changed to rc-6" but when you check manually as root it really hasn't: # ir-keytable Found /sys/class/rc/rc0/ with: Name: iMON Remote (15c2:0038) Driver: imon Default keymap: rc-imon-pad Input device: /dev/input/event8 LIRC device: /dev/lirc0 Supported kernel protocols: rc-6 imon Enabled kernel protocols: imon bus: 3, vendor/product: 15c2:0038, version: 0x0001 Repeat delay = 500 ms, repeat period = 125 ms ...and I have no idea why. Until this works, lircd will not work. If you run it manually, it will update it. It shows in the log and more importantly, if you check with ir-keytable you can see it was successful. It's bizarre. I even tried adding User= and Group= in the [Service] context and it made no difference. Dan
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 15:46, Wols Lists wrote: On 07/04/2024 13:07, Michael wrote: On Sunday, 7 April 2024 12:04:32 BST Wols Lists wrote: On 07/04/2024 11:48, Wols Lists wrote: On 07/04/2024 11:23, Michael wrote: On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote: On 07/04/2024 11:00, Wols Lists wrote: What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Just to follow up to myself, I've just done a complete update, but a lot of the dependencies are pulled in by "change-use", namely lzma, zstd. Is that fallout from the XZ debacle? Would a --no-deps be safe? Cheers, Wol Are you still on your original profile, or have you used eselect to change it to profile 23.0? If the latter, change back to your old profile, update @world, depclean and then start with the rest of the migration instructions. Just done that. See my other email. NOTHING TO UPDATE (unless I've messed up my emerge ...) Interesting ... just done this under the old profile ... thewolery /usr/local/bin # emerge --ask --oneshot sys-devel/binutils These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 3.19 s (backtrack: 0/20). Nothing to merge; quitting. Cheers, Wol Hmm ... something is amiss with your system. Normally you would get this: # emerge --ask --oneshot sys-devel/binutils These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 1.30 s (backtrack: 0/20). [ebuild R ] sys-devel/binutils-2.41-r5 Would you like to merge these packages? [Yes/No] Did you emerge any packages using the new 23.0 profile, then went back to the old profile to run the above command? No ... Ummm ... I have had trouble emerging other stuff that didn't want to work with oneshot ... Let me look at my make.conf - I had to over-ride something to get vbox-modules to emerge, this is probably the same thing ... Yup - as soon as I comment the EMERGE_DEFAULT_OPTS out I get it asking me if I want to emerge binutils. # EMERGE_DEFAULT_OPTS = "--buildpkg --deep --newuse --oneshot --usepkg" So I'm doing an emerge @world now with the old profile ... Yup - this appears to have un-bunged it - it's working as per instructions. You might want to add to the instructions to disable anything in make.conf that tampers with default settings. Cheers, Wol
Re: [gentoo-user] New profile - gentoo and binutils ...
On Sunday, 7 April 2024 15:46:18 BST Wols Lists wrote: > On 07/04/2024 13:07, Michael wrote: > > Did you emerge any packages using the new 23.0 profile, then went back to > > the old profile to run the above command? > > No ... > > Ummm ... I have had trouble emerging other stuff that didn't want to > work with oneshot ... > > Let me look at my make.conf - I had to over-ride something to get > vbox-modules to emerge, this is probably the same thing ... > > Yup - as soon as I comment the EMERGE_DEFAULT_OPTS out I get it asking > me if I want to emerge binutils. > > # EMERGE_DEFAULT_OPTS = "--buildpkg --deep --newuse --oneshot --usepkg" > > So I'm doing an emerge @world now with the old profile ... > > Cheers, > Wol Cool, once your system is up to date you should be able to change your profile and follow the rest of the instructions. I hope all goes well. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 13:07, Michael wrote: On Sunday, 7 April 2024 12:04:32 BST Wols Lists wrote: On 07/04/2024 11:48, Wols Lists wrote: On 07/04/2024 11:23, Michael wrote: On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote: On 07/04/2024 11:00, Wols Lists wrote: What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Just to follow up to myself, I've just done a complete update, but a lot of the dependencies are pulled in by "change-use", namely lzma, zstd. Is that fallout from the XZ debacle? Would a --no-deps be safe? Cheers, Wol Are you still on your original profile, or have you used eselect to change it to profile 23.0? If the latter, change back to your old profile, update @world, depclean and then start with the rest of the migration instructions. Just done that. See my other email. NOTHING TO UPDATE (unless I've messed up my emerge ...) Interesting ... just done this under the old profile ... thewolery /usr/local/bin # emerge --ask --oneshot sys-devel/binutils These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 3.19 s (backtrack: 0/20). Nothing to merge; quitting. Cheers, Wol Hmm ... something is amiss with your system. Normally you would get this: # emerge --ask --oneshot sys-devel/binutils These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 1.30 s (backtrack: 0/20). [ebuild R] sys-devel/binutils-2.41-r5 Would you like to merge these packages? [Yes/No] Did you emerge any packages using the new 23.0 profile, then went back to the old profile to run the above command? No ... Ummm ... I have had trouble emerging other stuff that didn't want to work with oneshot ... Let me look at my make.conf - I had to over-ride something to get vbox-modules to emerge, this is probably the same thing ... Yup - as soon as I comment the EMERGE_DEFAULT_OPTS out I get it asking me if I want to emerge binutils. # EMERGE_DEFAULT_OPTS = "--buildpkg --deep --newuse --oneshot --usepkg" So I'm doing an emerge @world now with the old profile ... Cheers, Wol
Re: [gentoo-user] New profile - gentoo and binutils ...
On Sunday, 7 April 2024 12:04:32 BST Wols Lists wrote: > On 07/04/2024 11:48, Wols Lists wrote: > > On 07/04/2024 11:23, Michael wrote: > >> On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote: > >>> On 07/04/2024 11:00, Wols Lists wrote: > What do I do here - "emerge binutils" (step 9) wants to emerge gcc, > which the instructions say "emerge AFTER binutils". > > With gcc it says "don't let it emerge glibc", should I apply the same > logic and not let binutils emerge gcc? > >>> > >>> Just to follow up to myself, I've just done a complete update, but a lot > >>> of the dependencies are pulled in by "change-use", namely lzma, zstd. Is > >>> that fallout from the XZ debacle? Would a --no-deps be safe? > >>> > >>> Cheers, > >>> Wol > >> > >> Are you still on your original profile, or have you used eselect to > >> change it > >> to profile 23.0? > >> > >> If the latter, change back to your old profile, update @world, > >> depclean and > >> then start with the rest of the migration instructions. > > > > Just done that. See my other email. > > > > NOTHING TO UPDATE (unless I've messed up my emerge ...) > > Interesting ... just done this under the old profile ... > > thewolery /usr/local/bin # emerge --ask --oneshot sys-devel/binutils > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > Dependency resolution took 3.19 s (backtrack: 0/20). > > > Nothing to merge; quitting. > > Cheers, > Wol Hmm ... something is amiss with your system. Normally you would get this: # emerge --ask --oneshot sys-devel/binutils These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 1.30 s (backtrack: 0/20). [ebuild R] sys-devel/binutils-2.41-r5 Would you like to merge these packages? [Yes/No] Did you emerge any packages using the new 23.0 profile, then went back to the old profile to run the above command? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 11:48, Wols Lists wrote: On 07/04/2024 11:23, Michael wrote: On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote: On 07/04/2024 11:00, Wols Lists wrote: What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Just to follow up to myself, I've just done a complete update, but a lot of the dependencies are pulled in by "change-use", namely lzma, zstd. Is that fallout from the XZ debacle? Would a --no-deps be safe? Cheers, Wol Are you still on your original profile, or have you used eselect to change it to profile 23.0? If the latter, change back to your old profile, update @world, depclean and then start with the rest of the migration instructions. Just done that. See my other email. NOTHING TO UPDATE (unless I've messed up my emerge ...) Interesting ... just done this under the old profile ... thewolery /usr/local/bin # emerge --ask --oneshot sys-devel/binutils These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 3.19 s (backtrack: 0/20). Nothing to merge; quitting. Cheers, Wol
Re: [gentoo-user] New profile - gentoo and binutils ...
On Sunday, 7 April 2024 11:48:07 BST Wols Lists wrote: > On 07/04/2024 11:23, Michael wrote: > > On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote: > >> On 07/04/2024 11:00, Wols Lists wrote: > >>> What do I do here - "emerge binutils" (step 9) wants to emerge gcc, > >>> which the instructions say "emerge AFTER binutils". > >>> > >>> With gcc it says "don't let it emerge glibc", should I apply the same > >>> logic and not let binutils emerge gcc? > >> > >> Just to follow up to myself, I've just done a complete update, but a lot > >> of the dependencies are pulled in by "change-use", namely lzma, zstd. Is > >> that fallout from the XZ debacle? Would a --no-deps be safe? > >> > >> Cheers, > >> Wol > > > > Are you still on your original profile, or have you used eselect to change > > it to profile 23.0? > > > > If the latter, change back to your old profile, update @world, depclean > > and > > then start with the rest of the migration instructions. > > Just done that. See my other email. > > NOTHING TO UPDATE (unless I've messed up my emerge ...) > > Cheers, > Wol OK, in case you haven't, I'd also run: emerge @preserved-rebuild -v -a and emerge --depclean -v -a to remove any dependencies no longer needed. Then change your profile to: [28] default/linux/amd64/23.0/desktop/plasma/systemd (stable) and continue with the emerge of binutils, gcc, glibc, libtool. You can use '--nodeps' to emerge them in the order given in the profile migration guide, although from what I've experienced this only happens with gcc and glibc. :-/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Program shutting down - where is its status held?
On Friday, 5 April 2024 16:21:15 BST Michael Orlitzky wrote:
> But barring that, you could add pre- and post-stop hooks that will let you
> know that the daemon is stopping.
>
> For example, in /etc/conf.d/boinc, you could put
>
> stop_pre(){
> touch /run/stopping-boinc
> }
> stop_post(){
> rm -f /run/stopping-boinc
> }
>
> or something like that. (I haven't tested, but the idea is sound.)
> Then, if that file exists, boinc is stopping.
Nice, neat solution. Works a charm, too.
Thanks again, Michael.
--
Regards,
Peter.
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 11:23, Michael wrote: On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote: On 07/04/2024 11:00, Wols Lists wrote: What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Just to follow up to myself, I've just done a complete update, but a lot of the dependencies are pulled in by "change-use", namely lzma, zstd. Is that fallout from the XZ debacle? Would a --no-deps be safe? Cheers, Wol Are you still on your original profile, or have you used eselect to change it to profile 23.0? If the latter, change back to your old profile, update @world, depclean and then start with the rest of the migration instructions. Just done that. See my other email. NOTHING TO UPDATE (unless I've messed up my emerge ...) Cheers, Wol
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 11:15, Michael wrote: On Sunday, 7 April 2024 11:00:49 BST Wols Lists wrote: What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Cheers, Wol Step 1: Ensure your system backups are up to date. Please also update your system fully and depclean before proceeding. Have you done this already after a fresh rsync of portage? Note that my current profile is marked experimental ... [9] default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr (exp) and I also have no stable 20 or 22 profiles to upgrade to. And "emerge --changed-use" gives me nothing to emerge. thewolery /usr/local/bin # emerge --update --deep --changed-use --newuse @world Calculating dependencies... done! Dependency resolution took 21.46 s (backtrack: 0/20). thewolery /usr/local/bin # Cheers, Wol
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 11:15, Michael wrote: On Sunday, 7 April 2024 11:00:49 BST Wols Lists wrote: What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Cheers, Wol Step 1: Ensure your system backups are up to date. Please also update your system fully and depclean before proceeding. Have you done this already after a fresh rsync of portage? YES. I've printed off the list, and am working my way down it ... My system defaults to deep, changed use, etc etc. I could revert the profile change and try again, we'll see. Cheers, Wol
Re: [gentoo-user] New profile - gentoo and binutils ...
On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote: > On 07/04/2024 11:00, Wols Lists wrote: > > What do I do here - "emerge binutils" (step 9) wants to emerge gcc, > > which the instructions say "emerge AFTER binutils". > > > > With gcc it says "don't let it emerge glibc", should I apply the same > > logic and not let binutils emerge gcc? > > Just to follow up to myself, I've just done a complete update, but a lot > of the dependencies are pulled in by "change-use", namely lzma, zstd. Is > that fallout from the XZ debacle? Would a --no-deps be safe? > > Cheers, > Wol Are you still on your original profile, or have you used eselect to change it to profile 23.0? If the latter, change back to your old profile, update @world, depclean and then start with the rest of the migration instructions. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New profile - gentoo and binutils ...
On 07/04/2024 11:00, Wols Lists wrote: What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Just to follow up to myself, I've just done a complete update, but a lot of the dependencies are pulled in by "change-use", namely lzma, zstd. Is that fallout from the XZ debacle? Would a --no-deps be safe? Cheers, Wol
Re: [gentoo-user] New profile - gentoo and binutils ...
On Sunday, 7 April 2024 11:00:49 BST Wols Lists wrote: > What do I do here - "emerge binutils" (step 9) wants to emerge gcc, > which the instructions say "emerge AFTER binutils". > > With gcc it says "don't let it emerge glibc", should I apply the same > logic and not let binutils emerge gcc? > > Cheers, > Wol Step 1: Ensure your system backups are up to date. Please also update your system fully and depclean before proceeding. Have you done this already after a fresh rsync of portage? signature.asc Description: This is a digitally signed message part.
[gentoo-user] New profile - gentoo and binutils ...
What do I do here - "emerge binutils" (step 9) wants to emerge gcc, which the instructions say "emerge AFTER binutils". With gcc it says "don't let it emerge glibc", should I apply the same logic and not let binutils emerge gcc? Cheers, Wol
