Re: [gentoo-user] gentoo handbook
On 2020-10-11 오후 8:55, Dale wrote: Neil Bothwick wrote: On Sat, 10 Oct 2020 22:09:00 -0400, Jude DaShiell wrote: A feature that would be useful for menuconfig would be the ability once a search is done to jump onto the desired search item directly (if the item were available at all). That's already there. Options that are available have a number next to them. Press that to jump to the option. Wow!!! O_O I never noticed that. It works too. I did a search for speak and saw a number next to the results and hit it, 1 in my case, and it went right to it. I'm not going to mention how many times I went digging to find something in the past. It embarrassing. ;-) Now that is cool. I just hope I remember to use it the next time. :/ Dale :-) :-) Just watch out and read carefully where you landed on. It could take you to the dependent option, before the specific one. For example, even if you searched 'A' and select the number left-side of 'A', it could land on option 'B' because it must enabled before you can play with 'A'. I surprised twice. First, as you did, when I first noticed I can select with the number, and Secondly, when I noticed it sometimes didn't bring me to the specified option :) -- Regards, W.H.Jeon
Re: [gentoo-user] UEFI booting again
On 10/11/20 7:37 PM, Jude DaShiell wrote: If you followed the handbook /dev/sda2 would be where the boot record lives. I don't think so, but the terminology is certainly confusing. Peter asked where efibootmgr writes something. What is on /dev/sda2 could be grub.cfg if it were mounted at /boot, and the grub booting stub (I forget the correct name, but grubx64.efi) might be on /dev/sda2 if it were mounted at /boot/EFI. However, efibootmgr doesn't mess with either of those. It deals with what is stored in the UEFI boot firmware. That entry, which is read by the UEFI at boot time, runs the entry in the EFI disk partition (usually under /boot/EFI), which then runs the kernel (and possibly initramfs) in /boot. Unfortunately, "boot record" is probably too general a term. Jack On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote: Date: Sun, 11 Oct 2020 19:21:49 From: pe...@prh.myzen.co.uk Reply-To: gentoo-user@lists.gentoo.org To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] UEFI booting again I'm still wrestling with my system and its not booting. Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot record, or whatever it's called? My machine seems unable to store what I give it, and I suspect that the BIOS ROM has failed. Big expense if so. TiA.
Re: [gentoo-user] UEFI booting again
In gentoo in order to make a uefi system is it necessary to use douefi as a boot parameter when starting the install? If so, it wasn't in the handbook I read. If not, my guess would be gentoo discovers this information for itself. --
Re: [gentoo-user] Portage being silly with kernel sources
On Sun, Oct 11, 2020 at 6:47 PM Neil Bothwick wrote: > > On Sun, 11 Oct 2020 16:58:30 -0400, Rich Freeman wrote: > > > > I too stick to stable sources, partly for the reason you give, partly > > > to avoid excessive reboots and partly because some systems use ZFS. > > > > > > % cat /etc/portage/package.accept_keywords/kernel > > > sys-kernel/gentoo-sources -~amd64 > > > sys-kernel/linux-headers -~amd64 > > > > > > Works for me. > > > > Uh, that will pull unstable kernels, at least as far as Gentoo is > > concerned. They're basically all stable as far as upstream is > > concerned. > > Not at all, it says "-~amd64" not "~amd64", removing the ~amd64 setting > that is used as default. > Ugh, I really need to get my eyes checked. You're right of course... -- Rich
Re: [gentoo-user] UEFI booting again
If you followed the handbook /dev/sda2 would be where the boot record lives. On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote: > Date: Sun, 11 Oct 2020 19:21:49 > From: pe...@prh.myzen.co.uk > Reply-To: gentoo-user@lists.gentoo.org > To: gentoo-user@lists.gentoo.org > Subject: [gentoo-user] UEFI booting again > > I'm still wrestling with my system and its not booting. > > Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot > record, or whatever it's called? My machine seems unable to store what I give > it, and I suspect that the BIOS ROM has failed. Big expense if so. > > TiA. > > > > > > > --
Re: [gentoo-user] UEFI booting again
On 23:21 Sun 11 Oct 2020, pe...@prh.myzen.co.uk wrote: I'm still wrestling with my system and its not booting. Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot record, or whatever it's called? My machine seems unable to store what I give it, and I suspect that the BIOS ROM has failed. Big expense if so. TiA. You might give it a shot like this : https://github.com/unixbhaskar/UEFI_Linux_Boot_Process_From_Userland Good luck! signature.asc Description: PGP signature
[gentoo-user] UEFI booting again
I'm still wrestling with my system and its not booting. Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot record, or whatever it's called? My machine seems unable to store what I give it, and I suspect that the BIOS ROM has failed. Big expense if so. TiA.
Re: [gentoo-user] Portage being silly with kernel sources
On Sun, 11 Oct 2020 16:58:30 -0400, Rich Freeman wrote: > > I too stick to stable sources, partly for the reason you give, partly > > to avoid excessive reboots and partly because some systems use ZFS. > > > > % cat /etc/portage/package.accept_keywords/kernel > > sys-kernel/gentoo-sources -~amd64 > > sys-kernel/linux-headers -~amd64 > > > > Works for me. > > Uh, that will pull unstable kernels, at least as far as Gentoo is > concerned. They're basically all stable as far as upstream is > concerned. Not at all, it says "-~amd64" not "~amd64", removing the ~amd64 setting that is used as default. The latest kernel I have installed is 5.4.66, which is the latest: % qlist -ICv gentoo-sources sys-kernel/gentoo-sources-5.4.66 sys-kernel/gentoo-sources-5.4.60 -- Neil Bothwick Sigh - An amplifier for people who suffer in silence pgpJbctN69NpI.pgp Description: OpenPGP digital signature
Re: [gentoo-user] What happened to my emerge -u?
On Sun, 11 Oct 2020 22:44:45 +0200, n952162 wrote: > > I don't know why it's written in such an opaque manner (a simple > > `if` would suffice), but it seems like this error is printed only if > > x86 is used and SSE2 is disabled, which doesn't make sense to me? > > Is SSE2 required for building/ running NodeJS on x86 machines? > > > > But how can my CPU be mistaken for a 32-bit machine? > > /Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ It's not your CPU type but the type of CPU you are building for. The key information from emerge --info is CHOST="i686-pc-linux-gnu" when it should be CHOST="x86_64-pc-linux-gnu" However, it is not as simple as editing make.conf, changing the CHOST of an installation is not supported, the setting is usually derived from the stage3 you started with. Backup settings and home then reinstall may be the easiest way out of this. -- Neil Bothwick When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. pgpDVLDohkpns.pgp Description: OpenPGP digital signature
Re: [gentoo-user] What happened to my emerge -u?
n952162 wrote: > > On 2020-10-11 22:57, Dale wrote: >> n952162 wrote: >>> On 2020-10-11 22:23, Dale wrote: n952162 wrote: > Apparently after a long series of checks, my emerge simply ended. > The only hint of a problem was this message: > > />>> Running pre-merge checks for net-libs/nodejs-14.4.0// > // * ERROR: net-libs/nodejs-14.4.0::gentoo failed (pretend phase):// > // * Your CPU doesn't support the required SSE2 instruction.// > // * // > // * Call stack:// > // * ebuild.sh, line 124: Called pkg_pretend// > // * nodejs-14.4.0.ebuild, line 50: Called die// > // * The specific snippet of code:// > // * (use x86 && ! use cpu_flags_x86_sse2) && \// > // * die "Your CPU doesn't support the required SSE2 > instruction."// > // * // > // * If you need support, post the output of `emerge --info > '=net-libs/nodejs-14.4.0::gentoo'`,// > // * the complete build log and the output of `emerge -pqv > '=net-libs/nodejs-14.4.0::gentoo'`.// > // * The complete build log is located at > '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/build.log'.// > // * The ebuild environment file is located at > '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/die.env'.// > // * Working directory: > '/var/tmp/portage/net-libs/nodejs-14.4.0/homedir'// > // * S: '/var/tmp/portage/net-libs/nodejs-14.4.0/work/node-v14.4.0'/ > > > Is this the problem? I'm not clear on why it's referring to x86. > Am I configured wrong? Is there a work-around? > > My CPU is: > > /$ uname -p// > //Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ > > $ uname -m > x86_64 > > This seems to be the key, /Your CPU doesn't support the required SSE2 instruction. Either your CPU doesn't support that or you have not enabled it or disabled it for some reason. This is where cpuid2cpuflags comes in handy. If you can't tell what is going on still, post *emerge --info *for that package and also the command you used that resulted in that error. That will likely show the USE flags and give the rest of us more clues to work with. Dale :-) :-) / >>> >>> Would that be different than the info output I sent in the original >>> posting? >>> >>> >> >> What might help, the listing of USE flags for that package. emerge -uvp >> /net-libs/nodejs should list the USE flags and how they are set. From >> the error, either something is set wrong for your CPU or SSE2 is >> disabled or something somewhere. It's where I'd start figuring out the >> problem. Either way, it needs to recognize your CPU and it's >> instruction sets properly. >> >> Someone else may have a better idea or ran into this and know the most >> likely cause. >> >> Dale >> >> :-) :-) >> / >> > $ pwd > /etc/portage/package.use > $ grep node * > $ lf /var/db/pkg/net-libs > gnutls-3.5.19/ http-parser-2.8.1/ libmnl-1.0.4/ libnsl-1.2.0/ > libpcap-1.8.1/ libssh2-1.8.0-r1/ libtirpc-1.0.2-r1/ > > i.e. it's not currently installed. > > And in make.conf, there's only this: > > USE="-elogind" > > > > The output of emerge -uvp net-libs/nodejs would be more helpful. Also emerge --info may help. There's a setting somewhere that needs to be changed. Dale :-) :-)
Re: [gentoo-user] What happened to my emerge -u?
On 11/10/2020 21:55, n952162 wrote: I ran into this: https://forums.gentoo.org/viewtopic-t-1108636-start-0.html but I really don't understand anything about these alternative instruction sets and would think my CPU is pretty vanilla. I mean, I hope to avoid trail-and-error approaches to solving this ... My first reaction was "have you specified x86 in make.conf?". As others have said, you need to make sure it's either x86_64, or AMD64, whatever is appropriate. I think SSE2 first appeared about the end of the Pentium era (if not earlier), so any half-way-modern cpu will have it. Dunno whether these musings will be any help, but we'll see ... Cheers, Wol
Re: [gentoo-user] What happened to my emerge -u?
On 2020-10-11 22:57, Dale wrote: n952162 wrote: On 2020-10-11 22:23, Dale wrote: n952162 wrote: Apparently after a long series of checks, my emerge simply ended. The only hint of a problem was this message: />>> Running pre-merge checks for net-libs/nodejs-14.4.0// // * ERROR: net-libs/nodejs-14.4.0::gentoo failed (pretend phase):// // * Your CPU doesn't support the required SSE2 instruction.// // * // // * Call stack:// // * ebuild.sh, line 124: Called pkg_pretend// // * nodejs-14.4.0.ebuild, line 50: Called die// // * The specific snippet of code:// // * (use x86 && ! use cpu_flags_x86_sse2) && \// // * die "Your CPU doesn't support the required SSE2 instruction."// // * // // * If you need support, post the output of `emerge --info '=net-libs/nodejs-14.4.0::gentoo'`,// // * the complete build log and the output of `emerge -pqv '=net-libs/nodejs-14.4.0::gentoo'`.// // * The complete build log is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/build.log'.// // * The ebuild environment file is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/die.env'.// // * Working directory: '/var/tmp/portage/net-libs/nodejs-14.4.0/homedir'// // * S: '/var/tmp/portage/net-libs/nodejs-14.4.0/work/node-v14.4.0'/ Is this the problem? I'm not clear on why it's referring to x86. Am I configured wrong? Is there a work-around? My CPU is: /$ uname -p// //Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ $ uname -m x86_64 This seems to be the key, /Your CPU doesn't support the required SSE2 instruction. Either your CPU doesn't support that or you have not enabled it or disabled it for some reason. This is where cpuid2cpuflags comes in handy. If you can't tell what is going on still, post *emerge --info *for that package and also the command you used that resulted in that error. That will likely show the USE flags and give the rest of us more clues to work with. Dale :-) :-) / Would that be different than the info output I sent in the original posting? What might help, the listing of USE flags for that package. emerge -uvp /net-libs/nodejs should list the USE flags and how they are set. From the error, either something is set wrong for your CPU or SSE2 is disabled or something somewhere. It's where I'd start figuring out the problem. Either way, it needs to recognize your CPU and it's instruction sets properly. Someone else may have a better idea or ran into this and know the most likely cause. Dale :-) :-) / $ pwd /etc/portage/package.use $ grep node * $ lf /var/db/pkg/net-libs gnutls-3.5.19/ http-parser-2.8.1/ libmnl-1.0.4/ libnsl-1.2.0/ libpcap-1.8.1/ libssh2-1.8.0-r1/ libtirpc-1.0.2-r1/ i.e. it's not currently installed. And in make.conf, there's only this: USE="-elogind"
Re: [gentoo-user] Portage being silly with kernel sources
On Sun, Oct 11, 2020 at 1:57 PM Neil Bothwick wrote: > > I too stick to stable sources, partly for the reason you give, partly to > avoid excessive reboots and partly because some systems use ZFS. > > % cat /etc/portage/package.accept_keywords/kernel > sys-kernel/gentoo-sources -~amd64 > sys-kernel/linux-headers -~amd64 > > Works for me. Uh, that will pull unstable kernels, at least as far as Gentoo is concerned. They're basically all stable as far as upstream is concerned. I also run zfs just about everywhere so I tend to stick to longterm kernels. I just pull them directly from git - there is a stable repo and a branch for every longterm, so all I need to do is a git pull and I get the latest one. I tend to like to manage this myself on systems where I'm using zfs, btrfs, or nvidia binary modules. -- Rich
Re: [gentoo-user] What happened to my emerge -u?
n952162 wrote: > On 2020-10-11 22:23, Dale wrote: >> n952162 wrote: >>> >>> Apparently after a long series of checks, my emerge simply ended. >>> The only hint of a problem was this message: >>> >>> />>> Running pre-merge checks for net-libs/nodejs-14.4.0// >>> // * ERROR: net-libs/nodejs-14.4.0::gentoo failed (pretend phase):// >>> // * Your CPU doesn't support the required SSE2 instruction.// >>> // * // >>> // * Call stack:// >>> // * ebuild.sh, line 124: Called pkg_pretend// >>> // * nodejs-14.4.0.ebuild, line 50: Called die// >>> // * The specific snippet of code:// >>> // * (use x86 && ! use cpu_flags_x86_sse2) && \// >>> // * die "Your CPU doesn't support the required SSE2 >>> instruction."// >>> // * // >>> // * If you need support, post the output of `emerge --info >>> '=net-libs/nodejs-14.4.0::gentoo'`,// >>> // * the complete build log and the output of `emerge -pqv >>> '=net-libs/nodejs-14.4.0::gentoo'`.// >>> // * The complete build log is located at >>> '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/build.log'.// >>> // * The ebuild environment file is located at >>> '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/die.env'.// >>> // * Working directory: >>> '/var/tmp/portage/net-libs/nodejs-14.4.0/homedir'// >>> // * S: '/var/tmp/portage/net-libs/nodejs-14.4.0/work/node-v14.4.0'/ >>> >>> >>> Is this the problem? I'm not clear on why it's referring to x86. >>> Am I configured wrong? Is there a work-around? >>> >>> My CPU is: >>> >>> /$ uname -p// >>> //Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ >>> >>> $ uname -m >>> x86_64 >>> >>> >> >> >> This seems to be the key, >> >> /Your CPU doesn't support the required SSE2 instruction. >> >> Either your CPU doesn't support that or you have not enabled it or >> disabled it for some reason. This is where cpuid2cpuflags comes in >> handy. If you can't tell what is going on still, post *emerge --info >> *for that package and also the command you used that resulted in that >> error. That will likely show the USE flags and give the rest of us >> more clues to work with. >> >> Dale >> >> :-) :-) >> / > > > Would that be different than the info output I sent in the original > posting? > > What might help, the listing of USE flags for that package. emerge -uvp /net-libs/nodejs should list the USE flags and how they are set. From the error, either something is set wrong for your CPU or SSE2 is disabled or something somewhere. It's where I'd start figuring out the problem. Either way, it needs to recognize your CPU and it's instruction sets properly. Someone else may have a better idea or ran into this and know the most likely cause. Dale :-) :-) /
Re: [gentoo-user] What happened to my emerge -u?
On 2020-10-11 21:34, n952162 wrote: Apparently after a long series of checks, my emerge simply ended. The only hint of a problem was this message: />>> Running pre-merge checks for net-libs/nodejs-14.4.0// // * ERROR: net-libs/nodejs-14.4.0::gentoo failed (pretend phase):// // * Your CPU doesn't support the required SSE2 instruction.// // * // // * Call stack:// // * ebuild.sh, line 124: Called pkg_pretend// // * nodejs-14.4.0.ebuild, line 50: Called die// // * The specific snippet of code:// // * (use x86 && ! use cpu_flags_x86_sse2) && \// // * die "Your CPU doesn't support the required SSE2 instruction."// // * // // * If you need support, post the output of `emerge --info '=net-libs/nodejs-14.4.0::gentoo'`,// // * the complete build log and the output of `emerge -pqv '=net-libs/nodejs-14.4.0::gentoo'`.// // * The complete build log is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/build.log'.// // * The ebuild environment file is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/die.env'.// // * Working directory: '/var/tmp/portage/net-libs/nodejs-14.4.0/homedir'// // * S: '/var/tmp/portage/net-libs/nodejs-14.4.0/work/node-v14.4.0'/ Is this the problem? I'm not clear on why it's referring to x86. Am I configured wrong? Is there a work-around? My CPU is: /$ uname -p// //Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ $ uname -m x86_64 I ran into this: https://forums.gentoo.org/viewtopic-t-1108636-start-0.html but I really don't understand anything about these alternative instruction sets and would think my CPU is pretty vanilla. I mean, I hope to avoid trail-and-error approaches to solving this ...
Re: [gentoo-user] What happened to my emerge -u?
On 2020-10-11 22:23, Dale wrote: n952162 wrote: Apparently after a long series of checks, my emerge simply ended. The only hint of a problem was this message: />>> Running pre-merge checks for net-libs/nodejs-14.4.0// // * ERROR: net-libs/nodejs-14.4.0::gentoo failed (pretend phase):// // * Your CPU doesn't support the required SSE2 instruction.// // * // // * Call stack:// // * ebuild.sh, line 124: Called pkg_pretend// // * nodejs-14.4.0.ebuild, line 50: Called die// // * The specific snippet of code:// // * (use x86 && ! use cpu_flags_x86_sse2) && \// // * die "Your CPU doesn't support the required SSE2 instruction."// // * // // * If you need support, post the output of `emerge --info '=net-libs/nodejs-14.4.0::gentoo'`,// // * the complete build log and the output of `emerge -pqv '=net-libs/nodejs-14.4.0::gentoo'`.// // * The complete build log is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/build.log'.// // * The ebuild environment file is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/die.env'.// // * Working directory: '/var/tmp/portage/net-libs/nodejs-14.4.0/homedir'// // * S: '/var/tmp/portage/net-libs/nodejs-14.4.0/work/node-v14.4.0'/ Is this the problem? I'm not clear on why it's referring to x86. Am I configured wrong? Is there a work-around? My CPU is: /$ uname -p// //Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ $ uname -m x86_64 This seems to be the key, /Your CPU doesn't support the required SSE2 instruction. Either your CPU doesn't support that or you have not enabled it or disabled it for some reason. This is where cpuid2cpuflags comes in handy. If you can't tell what is going on still, post *emerge --info *for that package and also the command you used that resulted in that error. That will likely show the USE flags and give the rest of us more clues to work with. Dale :-) :-) / Would that be different than the info output I sent in the original posting?
Re: [gentoo-user] What happened to my emerge -u?
On 2020-10-11 22:44, n952162 wrote: On 2020-10-11 22:39, Ashley Dixon wrote: On Sun, Oct 11, 2020 at 09:35:07PM +0100, Ashley Dixon wrote: `pkg_pretend` issues that error only if the architecture is x86 and SSE2 is enabled in the USE-flags: (use x86 && ! use cpu_flags_x86_sse2) && \ die "Your CPU doesn't support the required SSE2 instruction." Sorry, I read that line wrong. Tired. I don't know why it's written in such an opaque manner (a simple `if` would suffice), but it seems like this error is printed only if x86 is used and SSE2 is disabled, which doesn't make sense to me? Is SSE2 required for building/ running NodeJS on x86 machines? But how can my CPU be mistaken for a 32-bit machine? /Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ 02~/adm/gentoo/emerged>less /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz stepping : 10 microcode : 0xa07 cpu MHz : 1656.069 cache size : 3072 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arc> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5866.98 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz stepping : 10 microcode : 0xa07 cpu MHz : 1994.147 cache size : 3072 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arc> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5866.98 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Re: [gentoo-user] What happened to my emerge -u?
On 2020-10-11 22:39, Ashley Dixon wrote: On Sun, Oct 11, 2020 at 09:35:07PM +0100, Ashley Dixon wrote: `pkg_pretend` issues that error only if the architecture is x86 and SSE2 is enabled in the USE-flags: (use x86 && ! use cpu_flags_x86_sse2) && \ die "Your CPU doesn't support the required SSE2 instruction." Sorry, I read that line wrong. Tired. I don't know why it's written in such an opaque manner (a simple `if` would suffice), but it seems like this error is printed only if x86 is used and SSE2 is disabled, which doesn't make sense to me? Is SSE2 required for building/ running NodeJS on x86 machines? But how can my CPU be mistaken for a 32-bit machine? /Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/
Re: [gentoo-user] What happened to my emerge -u?
On 2020-10-11 22:23, Dale wrote: n952162 wrote: Apparently after a long series of checks, my emerge simply ended. The only hint of a problem was this message: />>> Running pre-merge checks for net-libs/nodejs-14.4.0// // * ERROR: net-libs/nodejs-14.4.0::gentoo failed (pretend phase):// // * Your CPU doesn't support the required SSE2 instruction.// // * // // * Call stack:// // * ebuild.sh, line 124: Called pkg_pretend// // * nodejs-14.4.0.ebuild, line 50: Called die// // * The specific snippet of code:// // * (use x86 && ! use cpu_flags_x86_sse2) && \// // * die "Your CPU doesn't support the required SSE2 instruction."// // * // // * If you need support, post the output of `emerge --info '=net-libs/nodejs-14.4.0::gentoo'`,// // * the complete build log and the output of `emerge -pqv '=net-libs/nodejs-14.4.0::gentoo'`.// // * The complete build log is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/build.log'.// // * The ebuild environment file is located at '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/die.env'.// // * Working directory: '/var/tmp/portage/net-libs/nodejs-14.4.0/homedir'// // * S: '/var/tmp/portage/net-libs/nodejs-14.4.0/work/node-v14.4.0'/ Is this the problem? I'm not clear on why it's referring to x86. Am I configured wrong? Is there a work-around? My CPU is: /$ uname -p// //Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ $ uname -m x86_64 This seems to be the key, /Your CPU doesn't support the required SSE2 instruction. Either your CPU doesn't support that or you have not enabled it or disabled it for some reason. This is where cpuid2cpuflags comes in handy. If you can't tell what is going on still, post emerge --info for that package and also the command you used that resulted in that error. That will likely show the USE flags and give the rest of us more clues to work with. Dale :-) :-) / / / /$ //cpuid2cpuflags/ /CPU_FLAGS_X86: mmx mmxext sse sse2 sse3 sse4_1 ssse3 / I forgot to include this, from /var/log/emerge.log: /1602438887: Started emerge on: Oct 11, 2020 19:54:47// //1602438887: *** emerge --verbose-conflicts --update --backtrack=100 --changed-deps=y --deep --keep-going --with-bdeps=y --reinstall=changed-use --verbose @world// //1602438960: *** exiting unsuccessfully with status '1'.// //1602438960: *** terminating.// //1602442111: Started emerge on: Oct 11, 2020 20:48:31// //1602442111: *** emerge --verbose-conflicts --update --backtrack=100 --changed-deps=y --deep --keep-going --with-bdeps=y --reinstall=changed-use --verbose @world// //1602442182: *** exiting unsuccessfully with status '1'.// //1602442182: *** terminating./ Is this business with the SSE2 instructions the thing that's causing the emerge failure?
Re: [gentoo-user] What happened to my emerge -u?
On Sun, Oct 11, 2020 at 09:35:07PM +0100, Ashley Dixon wrote: > `pkg_pretend` issues that error only if the architecture is x86 and SSE2 is > enabled in the USE-flags: > > (use x86 && ! use cpu_flags_x86_sse2) && \ > die "Your CPU doesn't support the required SSE2 instruction." Sorry, I read that line wrong. Tired. I don't know why it's written in such an opaque manner (a simple `if` would suffice), but it seems like this error is printed only if x86 is used and SSE2 is disabled, which doesn't make sense to me? Is SSE2 required for building/ running NodeJS on x86 machines? -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] What happened to my emerge -u?
On Sun, Oct 11, 2020 at 03:23:50PM -0500, Dale wrote: > This seems to be the key, > > /Your CPU doesn't support the required SSE2 instruction. > > Either your CPU doesn't support that or you have not enabled it or > disabled it for some reason. `pkg_pretend` issues that error only if the architecture is x86 and SSE2 is enabled in the USE-flags: (use x86 && ! use cpu_flags_x86_sse2) && \ die "Your CPU doesn't support the required SSE2 instruction." Considering the output of `uname -m`, I cannot imagine why `use x86` is returning true; surely `amd64` would be the appropriate flag? Strange... https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/nodejs/nodejs-14.4.0.ebuild#n50 -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] What happened to my emerge -u?
n952162 wrote: > > Apparently after a long series of checks, my emerge simply ended. The > only hint of a problem was this message: > > />>> Running pre-merge checks for net-libs/nodejs-14.4.0// > // * ERROR: net-libs/nodejs-14.4.0::gentoo failed (pretend phase):// > // * Your CPU doesn't support the required SSE2 instruction.// > // * // > // * Call stack:// > // * ebuild.sh, line 124: Called pkg_pretend// > // * nodejs-14.4.0.ebuild, line 50: Called die// > // * The specific snippet of code:// > // * (use x86 && ! use cpu_flags_x86_sse2) && \// > // * die "Your CPU doesn't support the required SSE2 > instruction."// > // * // > // * If you need support, post the output of `emerge --info > '=net-libs/nodejs-14.4.0::gentoo'`,// > // * the complete build log and the output of `emerge -pqv > '=net-libs/nodejs-14.4.0::gentoo'`.// > // * The complete build log is located at > '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/build.log'.// > // * The ebuild environment file is located at > '/var/tmp/portage/net-libs/nodejs-14.4.0/temp/die.env'.// > // * Working directory: > '/var/tmp/portage/net-libs/nodejs-14.4.0/homedir'// > // * S: '/var/tmp/portage/net-libs/nodejs-14.4.0/work/node-v14.4.0'/ > > > Is this the problem? I'm not clear on why it's referring to x86. Am > I configured wrong? Is there a work-around? > > My CPU is: > > /$ uname -p// > //Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz/ > > $ uname -m > x86_64 > > This seems to be the key, /Your CPU doesn't support the required SSE2 instruction. Either your CPU doesn't support that or you have not enabled it or disabled it for some reason. This is where cpuid2cpuflags comes in handy. If you can't tell what is going on still, post emerge --info for that package and also the command you used that resulted in that error. That will likely show the USE flags and give the rest of us more clues to work with. Dale :-) :-) /
Re: [gentoo-user] Portage being silly with kernel sources
On Sun, 11 Oct 2020 09:23:29 -0700, Daniel Frey wrote: > I have nvidia-drivers installed. It has a dependency to > virtual/linux-sources. > > The problem is it's always trying to pull in unstable packages when I > have two slotted kernels in world: > > sys-kernel/gentoo-sources:5.4.48 > sys-kernel/gentoo-sources:5.4.66 > > I tried masking kernels >5.5 but now it's trying to pull in unstable > kernel 5.4.70. Are you running ~arch globally? If so, the simple solution is to turn it off for kernel-sources. > I do not run unstable kernels, and have two stable kernels installed. > > Why is portage insistent on pulling in sys-kernel/gentoo-sources > (non-slotted) when two slotted entries already exist? Because it will always try to install the latest version that fits all your requirements. > I do not want to install unstable kernel sources as I don't use them > and am trying to spare the thousands of unnecessary writes on my SSD. > Whenever I update I check to see if there's a new stable kernel > available manually and update to it if needed. I too stick to stable sources, partly for the reason you give, partly to avoid excessive reboots and partly because some systems use ZFS. % cat /etc/portage/package.accept_keywords/kernel sys-kernel/gentoo-sources -~amd64 sys-kernel/linux-headers -~amd64 Works for me. -- Neil Bothwick (A)bort, (R)etry, (P)retend this never happened... pgpQ9XlaGvts3.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Portage being silly with kernel sources
Portage is neither silly nor smart. Will do what will be told to do. By default is tracking stable packages unless you have specified otherwise either by changing universally the tracking $ARCH in make.conf or per package in package.accept_keywords file or directory. I would guess that you've got "sys-kernel/gentoo-sources" somewhere into package.accept_keywords in the past and forgot about it. If gentoo-sources has not been manually overridden and portage complains about it then another package depends on the unstable version of gentoo-sources and trying to pull it, so you have to find which one is it.
Re: [gentoo-user] Portage being silly with kernel sources
On Sun, Oct 11, 2020 at 12:23 PM Daniel Frey wrote: > > The problem is it's always trying to pull in unstable packages when I > have two slotted kernels in world: > > sys-kernel/gentoo-sources:5.4.48 > sys-kernel/gentoo-sources:5.4.66 > > I tried masking kernels >5.5 but now it's trying to pull in unstable > kernel 5.4.70. > > I do not run unstable kernels, and have two stable kernels installed. > > Why is portage insistent on pulling in sys-kernel/gentoo-sources > (non-slotted) when two slotted entries already exist? > I'm not sure what you mean by "slotted" here. Do you mean stable? The most likely explanation is that you have ACCEPT_KEYWORDS=~amd64 somewhere, or sys-kernel/gentoo-sources somewhere in package.accept_keywords. -- Rich
Re: [gentoo-user] gentoo handbook
On Sun, 11 Oct 2020, John Covici wrote: > Date: Sun, 11 Oct 2020 12:52:34 > From: John Covici > Reply-To: gentoo-user@lists.gentoo.org > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] gentoo handbook > > On Sun, 11 Oct 2020 07:55:46 -0400, > Dale wrote: > > > > [1 ] > > Neil Bothwick wrote: > > > On Sat, 10 Oct 2020 22:09:00 -0400, Jude DaShiell wrote: > > > > > >> A feature that would be useful for menuconfig would be the ability once > > >> a search is done to jump onto the desired search item directly (if the > > >> item were available at all). > > > That's already there. Options that are available have a number next to > > > them. Press that to jump to the option. > > > > > > > > > > > > Wow!!! O_O I never noticed that. It works too. I did a search for > > speak and saw a number next to the results and hit it, 1 in my case, and > > it went right to it. I'm not going to mention how many times I went > > digging to find something in the past. It embarrassing. ;-) > > > > Now that is cool. I just hope I remember to use it the next time. :/ > > I didn't know that either and have been doing this for years! > > -- If nothing else at least three of us learned something useful today. I suppose the shortest way to explain what I did extra before running make menuconfig was to emerge espeakup. Having done that espeakup emerged about 35 packages many of which it likely would need. I'm pretty sure that step was correct, what if anything else to do after that before make menuconfig I don't yet know.
Re: [gentoo-user] gentoo handbook
On Sun, 11 Oct 2020 07:55:46 -0400, Dale wrote: > > [1 ] > Neil Bothwick wrote: > > On Sat, 10 Oct 2020 22:09:00 -0400, Jude DaShiell wrote: > > > >> A feature that would be useful for menuconfig would be the ability once > >> a search is done to jump onto the desired search item directly (if the > >> item were available at all). > > That's already there. Options that are available have a number next to > > them. Press that to jump to the option. > > > > > > > Wow!!! O_O I never noticed that. It works too. I did a search for > speak and saw a number next to the results and hit it, 1 in my case, and > it went right to it. I'm not going to mention how many times I went > digging to find something in the past. It embarrassing. ;-) > > Now that is cool. I just hope I remember to use it the next time. :/ I didn't know that either and have been doing this for years! -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
[gentoo-user] Portage being silly with kernel sources
This is one of those frustrating times where portage is trying to do something silly. I have nvidia-drivers installed. It has a dependency to virtual/linux-sources. The problem is it's always trying to pull in unstable packages when I have two slotted kernels in world: sys-kernel/gentoo-sources:5.4.48 sys-kernel/gentoo-sources:5.4.66 I tried masking kernels >5.5 but now it's trying to pull in unstable kernel 5.4.70. I do not run unstable kernels, and have two stable kernels installed. Why is portage insistent on pulling in sys-kernel/gentoo-sources (non-slotted) when two slotted entries already exist? I do not want to install unstable kernel sources as I don't use them and am trying to spare the thousands of unnecessary writes on my SSD. Whenever I update I check to see if there's a new stable kernel available manually and update to it if needed. Dan
Re: [gentoo-user] Re: Multilib ABI specific CPU use flags?
On 10/11/20 7:59 AM, Wols Lists wrote: On 11/10/20 05:42, Jonathan Yong wrote: Was it just the previous message? I canceled sending the message when I realized it wasn't signed. Google SMTP must have accepted it anyway. You can't cancel a message. Once it's left your inbox, it's gone. And Google won't/can't do anything (unless the recipient is gmail) because just as it will have gone from your outbox, it will have gone from their system before you've even realised "oh shit I didn't mean to hit send". You're effectively relying on the recipient's mail client to honour a request to throw the previous message away, and many clients either don't honour, or don't even recognise, such a request. That's why a previous mail client of mine (Turnpike), by default, wouldn't empty the outbox until the contents were at least a minute old. No, I mean the cancel button in progress box that Thunderbird shows when an email is sent, not Outlook style cancel. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] gentoo handbook
On Sun, 11 Oct 2020, Ashley Dixon wrote: > Date: Sun, 11 Oct 2020 07:30:19 > From: Ashley Dixon > Reply-To: gentoo-user@lists.gentoo.org > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] gentoo handbook > > On Sat, Oct 10, 2020 at 10:09:00PM -0400, Jude DaShiell wrote: > > missing lots of accessibility-related material. > > I've installed several other versions of Linux before and got them > > accessible using material found mostly on the internet for instructions. > > The first one was RedHat 5.0 when that was a current distribution. > > After that, slackware, debian, fedora ubuntu arch-linux coconut and jenux. > > Anyone interested could do a youtube search for gentoo, and I'm pretty > > sure you'll find I wasn't the only potential installer who ran into all > > manner of unexpected behavior. > > YouTube probably isn't the best source of information for technical > Linux > documentation. Asking here on the mailing list is always good; the > appropriate > IRC channels can be helpful, too. Gentoo does not hold your hand and provide > a > pretty GUI for every potential option and use-case, because its range of > target > consumers is far too broad. The "all manner of unexpected behaviour" > you're > encountering is just the feeling of having to do some of the > heavy-lifting > yourself, which is certainly not a negative remark on Gentoo! > > If you have a very specific and niche issue, you can also reach out directly > to > the Gentoo Accessibility Project in different forms > (#gentoo-accessibility; > accessibil...@gentoo.org; gentoo-accessibil...@lists.gentoo.org) [1]. > > > An A gentoo accessibility install podcast ought to have been available for > > this distribution many years ago. > > A podcast for all accessibility use-cases in Gentoo would, once again, be > far > too broad and help only a minority of potentially interested viewers. > A > dedicated espeak(up) page on the Gentoo wiki would be great, however. I > was > rather surprised to see that one didn't exist. > > > A feature that would be useful for menuconfig would be the ability once a > > search is done to jump onto the desired search item directly (if the item > > were available at all). > > Maybe that's communicated by colors, I don't know. > > Currently, the closest thing menuconfig provides is detailing the location > of > the `CONFIG_` option, in relation to the graphical menus one must > navigate. > Sometimes it's just easier to edit your `.config` manually; menuconfig can > be > terribly slow and cumbersome when you're only searching the option > titles. > > [1] https://wiki.gentoo.org/wiki/Project:Accessibility > > -- This problem needs handling by gentoo accessibility project and I'll take it their. If this problem gets solved, I'll probably make a podcast at least for speakup and maybe orca if I get that installed and working. It won't be of much use to gentoo, but the blinux-list may find it of interest.
Re: [gentoo-user] sys-apps/xdg-desktop-portal wants USE=screencast
On Sunday, 11 October 2020 12:34:04 BST Ashley Dixon wrote: > On Sun, Oct 11, 2020 at 12:16:18PM +0100, Michael wrote: > > The following USE changes are necessary to proceed: > > (see "package.use" in the portage(5) man page for more details) > > > > # required by kde-apps/krfb-20.04.3::gentoo[wayland] > > # required by kde-apps/kdenetwork-meta-20.04.3::gentoo > > # required by @selected > > # required by @world (argument) > > > > >=sys-apps/xdg-desktop-portal-1.8.0 screencast > > > > I don't seem to be able to disable screencast, even when I manually > > disable the USE flag for it on sys-apps/xdg-desktop-portal. Is there no > > way out of this? > > Follow the trace given by emerge: something in your @world set > requires `kdenetwork-meta`, which subsequently requires `krfb`. The latter > then requires the `screencast` flag on `xdg-desktop-portal` if, and only > if, the `wayland` flag is set. > > To remove the `screencast` requirement, disable `wayland` on `krfb`. Thanks guys, wayland was indeed pulling this in - I hadn't taken a look at the krfb ebuild until you pointed it out to me. All is emerging happily now. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] gentoo handbook
Neil Bothwick wrote: > On Sat, 10 Oct 2020 22:09:00 -0400, Jude DaShiell wrote: > >> A feature that would be useful for menuconfig would be the ability once >> a search is done to jump onto the desired search item directly (if the >> item were available at all). > That's already there. Options that are available have a number next to > them. Press that to jump to the option. > > Wow!!! O_O I never noticed that. It works too. I did a search for speak and saw a number next to the results and hit it, 1 in my case, and it went right to it. I'm not going to mention how many times I went digging to find something in the past. It embarrassing. ;-) Now that is cool. I just hope I remember to use it the next time. :/ Dale :-) :-)
Re: [gentoo-user] gentoo handbook
On Sat, 10 Oct 2020 22:09:00 -0400, Jude DaShiell wrote: > A feature that would be useful for menuconfig would be the ability once > a search is done to jump onto the desired search item directly (if the > item were available at all). That's already there. Options that are available have a number next to them. Press that to jump to the option. -- Neil Bothwick How do i find the model of my card? your nick is misleading, seriously pgpY9f4OFCd4C.pgp Description: OpenPGP digital signature
Re: [gentoo-user] sys-apps/xdg-desktop-portal wants USE=screencast
On Sun, Oct 11, 2020 at 12:16:18PM +0100, Michael wrote: > The following USE changes are necessary to proceed: > (see "package.use" in the portage(5) man page for more details) > # required by kde-apps/krfb-20.04.3::gentoo[wayland] > # required by kde-apps/kdenetwork-meta-20.04.3::gentoo > # required by @selected > # required by @world (argument) > >=sys-apps/xdg-desktop-portal-1.8.0 screencast > > I don't seem to be able to disable screencast, even when I manually disable > the USE flag for it on sys-apps/xdg-desktop-portal. Is there no way out of > this? Follow the trace given by emerge: something in your @world set requires `kdenetwork-meta`, which subsequently requires `krfb`. The latter then requires the `screencast` flag on `xdg-desktop-portal` if, and only if, the `wayland` flag is set. To remove the `screencast` requirement, disable `wayland` on `krfb`. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] sys-apps/xdg-desktop-portal wants USE=screencast
On Sun, 11 Oct 2020 12:16:18 +0100, Michael wrote: > The following USE changes are necessary to proceed: > (see "package.use" in the portage(5) man page for more details) > # required by kde-apps/krfb-20.04.3::gentoo[wayland] > # required by kde-apps/kdenetwork-meta-20.04.3::gentoo > # required by @selected > # required by @world (argument) > >=sys-apps/xdg-desktop-portal-1.8.0 screencast > > I don't seem to be able to disable screencast, even when I manually > disable the USE flag for it on sys-apps/xdg-desktop-portal. Is there > no way out of this? It's a dependency of krfb with USE=wayland wayland? ( sys-apps/xdg-desktop-portal[screencast] ) -- Neil Bothwick / For security reasons, all text in this mail is double-rot13 encrypted. / pgpmv_xtS43qJ.pgp Description: OpenPGP digital signature
Re: [gentoo-user] gentoo handbook
On Sat, Oct 10, 2020 at 10:09:00PM -0400, Jude DaShiell wrote: > missing lots of accessibility-related material. > I've installed several other versions of Linux before and got them > accessible using material found mostly on the internet for instructions. > The first one was RedHat 5.0 when that was a current distribution. > After that, slackware, debian, fedora ubuntu arch-linux coconut and jenux. > Anyone interested could do a youtube search for gentoo, and I'm pretty > sure you'll find I wasn't the only potential installer who ran into all > manner of unexpected behavior. YouTube probably isn't the best source of information for technical Linux documentation. Asking here on the mailing list is always good; the appropriate IRC channels can be helpful, too. Gentoo does not hold your hand and provide a pretty GUI for every potential option and use-case, because its range of target consumers is far too broad. The "all manner of unexpected behaviour" you're encountering is just the feeling of having to do some of the heavy-lifting yourself, which is certainly not a negative remark on Gentoo! If you have a very specific and niche issue, you can also reach out directly to the Gentoo Accessibility Project in different forms (#gentoo-accessibility; accessibil...@gentoo.org; gentoo-accessibil...@lists.gentoo.org) [1]. > An A gentoo accessibility install podcast ought to have been available for > this distribution many years ago. A podcast for all accessibility use-cases in Gentoo would, once again, be far too broad and help only a minority of potentially interested viewers. A dedicated espeak(up) page on the Gentoo wiki would be great, however. I was rather surprised to see that one didn't exist. > A feature that would be useful for menuconfig would be the ability once a > search is done to jump onto the desired search item directly (if the item > were available at all). > Maybe that's communicated by colors, I don't know. Currently, the closest thing menuconfig provides is detailing the location of the `CONFIG_` option, in relation to the graphical menus one must navigate. Sometimes it's just easier to edit your `.config` manually; menuconfig can be terribly slow and cumbersome when you're only searching the option titles. [1] https://wiki.gentoo.org/wiki/Project:Accessibility -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
[gentoo-user] sys-apps/xdg-desktop-portal wants USE=screencast
The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by kde-apps/krfb-20.04.3::gentoo[wayland] # required by kde-apps/kdenetwork-meta-20.04.3::gentoo # required by @selected # required by @world (argument) >=sys-apps/xdg-desktop-portal-1.8.0 screencast I don't seem to be able to disable screencast, even when I manually disable the USE flag for it on sys-apps/xdg-desktop-portal. Is there no way out of this? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Multilib ABI specific CPU use flags?
On 11/10/20 05:42, Jonathan Yong wrote: > Was it just the previous message? I canceled sending the message when I > realized it wasn't signed. Google SMTP must have accepted it anyway. You can't cancel a message. Once it's left your inbox, it's gone. And Google won't/can't do anything (unless the recipient is gmail) because just as it will have gone from your outbox, it will have gone from their system before you've even realised "oh shit I didn't mean to hit send". You're effectively relying on the recipient's mail client to honour a request to throw the previous message away, and many clients either don't honour, or don't even recognise, such a request. That's why a previous mail client of mine (Turnpike), by default, wouldn't empty the outbox until the contents were at least a minute old. Cheers, Wol
