| View previous topic :: View next topic |
| Author |
Message |
hackernotcracker
n00b
Joined: 13 Aug 2018
Posts: 18
Location: Oregon, USA
|
 Posted: Mon May 27, 2024 12:21 am Post subject: LLVM build, portage package constraints not failing. |
 |
|
Hi, Not sure if this is the correct forum to post in:
I'm building an llvm profile desktop machine, and comparing it against a gcc desktop machine; and having issues understanding portage's use flags and restrictions. ( They seem to have changed a bit over the last few years.... and certain bugs, never seem to get fixed even in the stage 3 tarballs. )
I'm wanting to figure out how to get portage to be more aggressive with error messages; document a few annoyances that other's a *probably* running into, (as soon as they try anything other than a simple, naive install); and possibly how/where to report portage package issues; [ ?! and (mis-)documentation issues on the gentoo site ?! ]
skip down to the next ----------------------------------- For the main question(s)
This section is all the gory details you may want to ask about.
I'm an advanced programmer/BSEE with 25+ years experience doing very complex problems. I have a fondness for building minimal systems, including embedded. Gentoo can *do* but the learning threshold is still high (2024.).
Open software, though, is about being able to fix problems, right?
Therefore, this round of masochism will be sponsored on a new ASUS Vivobook (Year 2024), M1803Q ; 8 core:
Linux localhost 5.15.159 #8 SMP Sat Mar 9 22:34:30 PST 2024 x86_64 AMD Ryzen 7 4700U with Radeon Graphics AuthenticAMD GNU/Linux. ( I've paid for it, all; so you don't have to, unless you want to. )
This computer has a 1Tb /dev/nvme0n1, a 40Gb DRAM memory, a MediaTek MT7921 Wireless Adapter
Audio: 17h/19h HD (AMD), and ACP/ACP3x/ACP6x Audio Compressor.
The GPU is AMD Radeon Vega Mobile series, Cezzane.
This is a pure AMD laptop.
I will be posting config files, so other's may enjoy the quick solutions and study it in detail...
But: I am using an older vivobook to websurf, and post here, while my new machine experiences birthing pains. 
I've broken the hard drive up into a partitioning as follows: ( with 741GiB free, still. )
| Code: |
Number Size Code Name
gpt1 260 MiB EFOO EFI system partition
gpt2 16.9 MiB 0C01 Mircrosoft Reserved
gpt3 31.0 GiB 8300 Root
gpt4 31.0 GiB 8300 Root~
gpt5 31.0 GiB 8300 Opt
gpt6 31.0 GiB 8300 home
gpt7 31.0 GiB 8300 portage
gpt8 31.0 GiB 8300 tmpbuild
gpt9 4.0 GiB 8300 linuxKernelSrc
|
There is no swap, and this is on purpose for now. I have a huge amount of ram, and I'm only going to allocate four processors during compile to prevent pipes from consuming all memory and crashing the system during builds (yes, kernel FIFO's are no longer just 4K each ... but can grow so big they EAT Gigabytes of RAM). It sucks, and is rather pointless; cause destroying a build with pipes running out of memory is worse than just slowing the compile down; Portage isn't smart enough to give an error and you will get cryptic errors that don't make sense. So, I just use "-j4", in spite of having 16 processors.
For most people, this sneaky -pipe bashing will only really become annoying when trying to compile 'rust'; ( which most people have not been able to do (without a supercomputer bank) for the last two years or so. -- and that, I suspect, is why it is a 'bin' package hiding in Gentoo's compile everything philosophy!. )
I have also built a custom kernel, with no initrd, all firmware compiled into the image; I already know the basic kernel config is good (as I use it on another vivobook, from 2022 with different firmware). The kernel has ram compression swapping built in. ( And I have some questions about filesystem choices in ram, that might exploit the compression; though that's a later issue. )
I started from two stage3 tarballs, and have two root partitions; one compiled by gcc, the other by llvm.
https://distfiles.gentoo.org/releases/amd64/autobuilds/20240519T170355Z/stage3-amd64-desktop-openrc-20240519T170355Z.tar.xz
eselect profile default/linux/amd64/23.0 (stable)
https://distfiles.gentoo.org/releases/amd64/autobuilds/20240519T170355Z/stage3-amd64-llvm-openrc-20240519T170355Z.tar.xz
eselect profile defualt/linux/amd64/23.0 llvm (stable)
This will allow me to compare, space, speed, etc. and also give me a redundant backup root, if the other one happens to fail.
All linux filesystems are BTRFS. EFI, is of course, fat -F32.
I chose 260MiB of EFI in order to install the gentoo minimal live-cd onto that partition during initial setup.
( It was a bad choice; I had to upgrade to the GUI liveCD and fight GRUB to get it to *indirectly* boot from a non gpt1 partition. Sigh, do Gentoo maintainers actually test the minimal.iso or is there not enough time to do it? )
If I did it again, I'd partition a full DVD size of 4Gb, for the EFI partition.
My make.conf is as follows:
| Code: |
CFLAGS="-march=nocona -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
MAKEOPT="-j4"
#
ACCEPT_LICENSE="-* @FREE"
GRUB_PLATFORMS="emu efi-64"
#
PKGDIR="/usr/cache/binpkgs"
DISTDIR="/usr/cache/distfiles"
PORTAGE_TMPDIR="/mnt"
#
LC_MESSAGES=C.utf8
#
USE="bluetooth dbus elogind ffmpeg fontconfig gles1 gles2 gnutls grub harfbuzz
icu jpeg lapack minizip png pulseaudio svg truetype xattr xdg xinerama
-acl -consolekit -gstreamer -jack -kde -libav -ssh1 -ssl1 -sslv2 -sslv3
-systemd -bpf"
VIDEO_CARDS="amdgpu radeonsi" # Radeon SI, according to gentoo wiki, is *required* for OpenGL hardware support.
|
Note: the X global flag is NOT issued. I'm purposely adding use flags in package.use for each package name, to build the system incrementally and test individual legacy X configuration mismatches. I'm stress testing Portage, here.
--------------------------------------------
I want to build Gentoo packages in a consistent/clean/complete way; (eg: emerge -e @world) but there are packages that may not compile on one root, that will compile on the other root~. Therefore, I need to be able to force packages to not install, selectively. Eg: Either masking them, or in the package.use directory, specifying a particular acceptable version; so as to make both roots use the exact same source code.
In older Gentoo distributions, I could write a package name with an asterisk as part of use flags: /etc/portage/package.use/cairo
| Code: |
dev-cpp/cairomm* X
xll-libs/cairo*
|
But, in the 2024 distribution of Gentoo, I'm finding that these older formats often bomb; especially if I write "dev-cpp/cairomm-* X"
In general, the asterisks no longer seem to be consistently welcome. It does work as long as asterisks are not included. So, I just 'worked' around this annoyance:
BUT:
In the purely *stable* distribution for llvm, I suddenly had a package conflict; May 24,2024. (Which shouldn't happen, right?)
The Gentoo distribution indicated that dev-python/sphinx-7.2.6 required python doclib <0.20
Except that the lowest version number of doclib, was .20.1-r1
Therefore, I got a conflict message even though I'm using a purely stable distribution where at least one package ought to have been installable without a conflict.
The obvious thing, here, (I thought) is to either use a sphinx package with a higher version number; so it will accept a higher version of doclib *or* to block the conflicting version of doclib, and force portage to 'deduce' that it must use a higher version number of sphinx; (or at least STOP the compile with a hard error. )
But neither idea stopped portage from compiling and installing the wrong package (again!).
I did: emerge --unemerge dev-python/docutils ; emerge --unemerge dev-python/docutils
THEN:
nano /etc/portage/package.mask/docutils
| Code: | | dev-python/docutils-0.21.2 |
This gave an invalid/unrecognized 'tokens' error by Portage, emerge; and I don't want to mask docutils, all versions! So, I deleted the mask file and tried:
nano /etc/portage/package.use/sphinx
| Code: | | >dev-python/sphinx-7.2.6 |
Then tried an: emerge --ask --update --deep --newuse --with-bdeps=y @world
This did not cause an error message; but it still built sphinx-7.2.6, ignoring my constraint!
Deleting the packages again, and trying:
nano /etc/portage/package.use/sphinx
| Code: | | >=dev-python/sphinx-7.3.7-r2 |
Also did not cause an error message; but portage still built sphinx-7.2.6!
It's at this point that I realized that the portage *stable* tree was in a mysteriously unstable state. I only knew one other way to proceed; I could use /etc/portage/package.accept_keywords/sphinx.
This did work, and solved the problem. However, I don't want portage *silently* building a package that does not meet constraints specified in the package.use file. Is there a switch or way to make portage more aggressive in it's error reporting so that an emerge *stops* if a requested constraint (AKA: atom prefix) can not be properly met by the stable source code ?
Additional questions/issues:
So far; I've encountered three other major problems that aren't documented in the Gentoo wikis.
#1. There is a lot of Grub confusion about where the EFI partition ought to be mounted.
Gentoo stage 3 tarballs only supply /boot -- Which is intended for legacy BIOS booting, and not the more common /efi partition.
The wiki on installing the base system says it ought to be /efi where the partition is mounted. But: Common install videos mis-place the location as /boot/efi which can cause all kinds of chaos and failures in the future when updating kernels, grub, etc.
https://www.youtube.com/watch?v=J7W9MItUSGw
I decided to mount the partition on /efi, (lowercase) exactly as the Gentoo handbook/wiki stated; and then do a sym-link: ln -s /efi /boot
This is because kernelinstall (rc version) still looks for /boot and does not follow the wiki. (May 2024).
Is this a correct approach, or does the inatallation manual really intend a different approach, and is just vaguely written?
When all else failed, I found I could do a manual grub install (after hours of head banging) with:
grub-install --target-x86_64-efi --efi-directory=/efi
grub-mkconfig -o /efi/grub/grub.cfg
Note: The grub install switch for '--efi-directory' is actually looking for the partition mount point. There *is* another directory INSIDE the /boot or /efi directory mount point, which is EFI. /efi/EFI or /boot/EFI This capital EFI directory is NOT what that grub switch is about! (Documentation headache, and I'm not sure many people even realize there is an efi EFI ambiguity! )
#2 Getting hardware acceleration to work for openGL in the 'amdGPU' configuration for Radeon cards is a documentation nightmare. I still don't have it right. The Gentoo wiki page describing the firmware I need for Cezzane, (May 2024), has a first entry that implies a firmware name that is different from a second entry, that is right.
#3 even though I have a default stage 3 tarball, and Gentoo packages often use the compressed kernel config information from the kernel to identify which kernel options were set; Gentoo can't build the /sys version of the kernel config file on a stage3, virgin, partition AKA ( without the cpio package installed). What happens without cpio ? in /usr/src/linux, executing 'make' will act as if the kernel compiled correctly, with no error message at the end; even if cpio is not installed. BUT: The kernel will not be made. (and no final error message. )
It's only after a bit of inspiration that trying echo $? will yield a surprising nonzero, after the kernel compile.
#4 (side note)
The live-CD for Gentoo, although it runs on my laptop correctly, would drop wireless internet connection randomly and not restart it properly. ( Once I had my base install of the stage 3, and used wpa_supplicant, my install had NO PROBLEMS keeping the internet connection alive. I'm using the same firmware; so it's the live-CD's upgrades which are causing the problem )
#5 (side note)
There is still a problem when doing emerge -e @world, on a virgin stage3 install, with only the make.conf file posted above added; that I get an immediate dependency loop between fontfonfig and harfbuzz. Cmon folks! Shouldn't this be in a wiki on how to fix it? Anyone who is actually doing something in their gentoo install besides following a recipe, is going to hit this problem.
I used,
USE="-harfbuzz" emerge --oneshot fontconfig # This breaks the circular dependency
emerge --upgrade --deep --newuse --with-bdeps=y @world
Looking forward to comments/suggestions.
The immediately following poster wasted bandwidth, so I suggest you skip to:
https://forums.gentoo.org/viewtopic-p-8828213.html#8828213 , where I summarize my complaint, to which you may still reply; and I begin configuration files in the post that follow.
_________________
What's the difference between a liar and a joker? A liar always claims what they said was just a joke, but a real joker just laughs.
Last edited by hackernotcracker on Fri May 31, 2024 6:19 am; edited 2 times in total |
|
| Back to top |
|
 |
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9559
Location: beyond the rim
|
| Posted: Mon May 27, 2024 10:08 am Post subject: Re: LLVM build, portage package constraints not failing. |
|
|
| hackernotcracker wrote: | nano /etc/portage/package.mask/docutils
| Code: | | dev-python/docutils-0.21.2 |
This gave an invalid tokens error by portage; and I don't want to mask docutils, all versions! So, I deleted the mask and tried:
nano /etc/portage/package.use/sphinx
| Code: | | >dev-python/sphinx-7.2.6 |
Then tried an: emerge --update --deep --newuse --with-bdeps=y @world
This did not cause an error message; but it still built sphinx-7.2.6, ignoring my constraint!
Deleting the packages again, and trying:
nano /etc/portage/package.use/sphinx
| Code: | | >=dev-python/sphinx-7.3.7-r2 |
Also did not cause an error message; but portage still built sphinx-7.2.6! |
Of course, as you added those lines to package.use, not package.mask (unless your post is wrong). Package.use isn't for masking/unmasking versions, pretty simple. The error you got from package.mask is because you didn't specify an operator. Don't know why you then jumped to the conclusion that you could only mask docutils completely. The only thing you could complain about here is that portage didn't notify you about the effectively useless package.use entries (but technically they're perfectly fine).
| Quote: | | This did work, and solved the problem. However, I don't want portage *silently* building a package that does not meet constraints specified in the package.use file. Is there a switch or way to make portage more aggressive in it's error reporting so that an emerge *stops* if a requested constraint can not be properly met by the stable source code ? |
As noted above, you didn't specify a constraint in the first place. The visibility filter is pretty strict in that regard, if a package is selected that you think should be masked it usually means that the problem is with your configuration. You can easily check that for greater-than restrictions with `emerge -p --nodeps packagename`. |
|
| Back to top |
|
|
hackernotcracker
n00b
Joined: 13 Aug 2018
Posts: 18
Location: Oregon, USA
|
| Posted: Mon May 27, 2024 8:14 pm Post subject: |
|
|
Thank you for reading my blog, wading through all I said! Let me try to follow your argument, here:
| Quote: |
Of course, as you added those lines to package.use, not package.mask (unless your post is wrong). Package.use isn't for masking/unmasking versions, pretty simple. |
The topmost line of your post says nano /etc/portage/package.mask
I think the topmost example in your post's quote of me is found in package.mask ; I'm not sure how (or if) you came to the opposite conclusion?
But: The *OTHER* lines, with nano showing /etc/portage/package.use, below it, are in package use (as you say).
So, I'm not sure what line(s) plural you are referring to; at least the top 'line' (singular) is in package mask.
| Quote: |
Package.use isn't for masking/unmasking versions, pretty simple. The error you got from package.mask is because you didn't specify an operator. |
Fascinating. If Package.use is not for masking/unmasking versions, then portage ought never place a package name and version number into the package.use directory when using --autounmask-write or --autounmask ????
Because: It did do exactly this, before I tried to selectively unmask using package use.
I was only following it's example, as I couldn't remember which directory operators ought to go in.
See the make.conf I listed; notice I put "icu" as a global USE flag. This is the international c... unicode USE flag; it's meant to add legacy unicode support to a handful of programs. It is also a package name.
ICU hardly affects install size, and is worth enabling. Since I will eventually be using some 32 bit games via SDL; I decided, for compatibility, to enable 32 bit use flags for icu. ( ICU is not used with the virgin stage-3 install; but it will be required in the future; so -- I added the package use flag abi_x86_32 to icu, *in anticipation* of what I will be doing later in this thread. )
The first time I tried to rebuild the stage 3 tarball with 'emerge -e @world'; emerge told me I had to change the *use* flags for icu. Portage did NOT produce a zz-autounmask file -- which is what my *last* laptop has (which I am using to write you,now); but rather on my new laptop, portage issued a patch to edit my icu that adds a constraint.
The behavior of Gentoo seems different.
The use file, as *re-edited* by portage (via dispatch config) is as follows:
nano /etc/portage/package.use icu
| Code: |
dev-libs/icu abi_x86_32
# required by dev-libs/libxml2-2.12.6:gentoo[icu]
# required by dev-python/lxml-5.2.1: gentoo
# required by sys-apps/systemd-utils-254.10-r1::gentoo[python_single_target_python3_11]
# required by virtual/libudev-251-r2::gento[-systemd]
# required by sys-auth/elognind-246.10-r3::gentoo
# required by @system
# required by @world (argument)
>=dev-libs/icu-74.2 abi_x86_32
|
NOTE: Only the *topmost*, singular, line was put there by me.
Portage added all comments and the constraint operator that follows to a package.use file.
That last line has an atom prefix (AKA operator) in it, and has the syntax of a constraint.
Am I mistaken? ( I make mistakes; my memory has a lot of years of changing standards flowing through it!)
If package.use is not for constraints, could you simply explain why does Portage *insist* on editing my package.use file (and aggressively STOPPING the build until I manually accept the use change) by adding constraint syntax statement to a use file?
My original line ought to work for *all* icu packages, but Portage bothered aggressively breaking the build in order to force me to add an (??irrelevant??) constraint operator ">=" ??
Is there a virus in portage?? ( I'm being facile, here. ) But whatever esoteric reason there is for this syntax issue, I can't guess it.
I do see that there is no operator in my earlier example of package.mask.
So, I infer/reason:
You're arguing I *can* specify a package without operator in package.use, without it being an error.
But I *can't* do the exact same thing in package.mask, without it being an error ?
Hmmm ... simple?
In package.accept, I discovered that I don't even need to use the "~amd64" keyword but just put a package name (atom) there, and Portage knows I want to change a constraint on that package to include a testing version of it.
Presumably Portage 'knows' because the directory is named package.accept ??
( But not if the directory is named package.mask ?? )
I wonder what it will do if I add a constraint operator "=" to package.accept ?
Back to your suggestion/teaching of what I ought/ought not have done:
Which operator ought I have used in the package.mask, then? = , <=
Would this have really made a difference? (I'll experiment here in a bit.)
I'm thinking we have >=three 'package' directories in Gentoo; all of which are talking the language of packages.
I don't remember why are there three distinct lexers parsing these directories and requiring different syntax and error reporting protocols ?
Is this duplication of work/code in Portage just a 'historical' obfuscation of syntax, or is it more than that?
The error message I was given struck me this way:
The definition of Tokens, originates from K&R 'C', way back in the 70's. ( My youthful memories are more stable than the memories made yesterday; and my sense of time gets worse as I get more things filling my brain. )
But: I think that I've entered a package name (atom) in a package directory; this is the most basic object (oops) these directories should conceptually work on. The "name" I entered is recognized by me; and it *is also* recognized by Gentoo in *either* of the other two package directories;
By K&R definition, then, there are tokens on the line that I have entered that *are* recognizable by both me and Gentoo in two places; But, not in directory package.mask.
I don't recall reading in the Gentoo handbook a different definition for Tokens, or Atoms that would rule anything I've stated as "wrong." I'm being forced to guess at the esoteric and precise meaning of yours (and the Handbooks) words.
Notice the error for putting an explicit and pure Atom in package.mask isn't "missing tokens", rather the error message is specifying either "invalid", or "unrecognized tokens."
If I'm wrong; Wouldn't a more sensible error message be, "Error lies between operator's seat and keyboard?"
I mean, Gentoo uses python; just start an interpreter and say "from __future__ import braces"
This is one of the things that make it easy to remember you're using python, and not java, C, etc.
There's more that you've said which I have not yet studied, carefully; I'll be glad to read up on the command you mentioned, next.
Thanks; truly.
I appreciate your taking the time to answer me, it's a pleasure; and I'm only responding to the first part of your post right now.
More to come...
_________________
What's the difference between a liar and a joker? A liar always claims what they said was just a joke, but a real joker just laughs.
Last edited by hackernotcracker on Wed May 29, 2024 9:48 am; edited 3 times in total |
|
| Back to top |
|
|
hackernotcracker
n00b
Joined: 13 Aug 2018
Posts: 18
Location: Oregon, USA
|
| Posted: Wed May 29, 2024 5:10 am Post subject: "Visibility Filter, Gentoo64 Handbook" |
|
|
Continued...
Ok, As I mentioned, this is a pure AMD install; AKA x86-64.
Therefore, when I did the install I read the handbook.
https://wiki.gentoo.org/wiki/Handbook:AMD64
As a second check, I watched the video called "A comfy install of Gentoo."
https://www.youtube.com/watch?v=J7W9MItUSGw".
As far as I know, the handbook is the only official document that is not a wildly inaccurate description of Gentoo works. eg: not some historical version of the document that died in a programmer flame war, and is no longer supported.
( I also checked "man emerge", and such, to see if it was updated. )
When you wrote:
| Quote: |
As noted above, you didn't specify a constraint in the first place. The visibility filter is pretty strict in that regard,
|
"The" is an adjective; "The Visibility Filter" means (to me) that you expect me to already know what it is. AKA: "The" means well-known.
Where "A" visibility filter, would be American English for a generic kind of idea that hasn't been defined clearly.
I searched the AMD64 Handbook for "Visibility Filter"; It's not on the main page.
I re-read through 10 of eleven chapters of the installation guide; "Visibility Filter" I didn't see it in any of them.
I re-watched the comfy guide, he never mentions it.
I did a web search for "Gentoo the visibility filter" -- And the first five posts were to people who didn't have a clue what it was, either. So, I give up. 
In the "man emerge", "visibility" is not used as you are using it; but as a generic idea.
It references the ebuild,5, which I glanced at; but it merely re-teaches what atoms are, and what prefix operators are.
Therefore; presently I understand:
There are three package directories, all of which use atoms; and atoms may have operators (AKA Atom prefixes) in them.
For some reason, Gentoo doesn't accept pure exact atoms, in all three package directories, without causing errors.
If there is a definite item ( The visibility filter ) which is "strict"; there has to be documentation that describes what 'strict' is; I would expect a strict filter to work the same in all three directories.
But I can't tell if there is one visibility filter or three, or ten. It's like magic ... an undefined technology that people say works because you do some kind of incantation. ( An Arthur C. Clarkism, from 1962. )
I don't know where "THE Visibility filter" jargon comes from; I don't even know why my last laptop wrote zz-autounmask files, and my new laptop is *editing* my package.use files to add operators that you seem to think 'do' nothing?
I'm not interesting in re-reading hundreds of pages of documentation for make ebuilds; which I have done in the past, in order to find a needle in a haystack.
Being retired, are you perhaps reminiscing about a version of Gentoo that is no longer? ( I don't mean to be insulting, it happens to me occasionally; and I'm grasping at straws here ... slightly frustrated, but that's normal. ).
I tried your command:
emerge -p --no-deps ...
And it occurred to me, after reading the docs on emerge (again) that -p is the same as pretend.
I'll just note:
It is just as easy to determine what will be installed by not pretending, as by pretending.
I didn't explicitly write it, in my post, but I did put "emerge --ask", which lists the exact same information as your command does; I pushed enter with yes, to test whether or not Gentoo really wouldn't install packages of a higher version in when I had clearly put operators (Atom prefixes) in package.use (after copying what Gentoo itself does); my purpose was to encourage the installing of *a* *different* package than it installed before.
So, I don't see what your command does in terms of solving my problem or answering my question.
Your command does not seem to make portage more aggressive, nor will portage stop the emerge if operators that I (or portage itself) places in the package.use directory can not be met. Rather, I have to become the visibility filter and say "no" to an interactive prompt; which means I have to read a lot of text which I might not read correctly, when I'm tired.
Automation is meant to avoid human errors; I'd rather find a better way than relying on myself.
So, let me re-ask my question:
Is there a way to make Gentoo more aggressive, and have it NOT ignore my (or it's own) operators and/or atom prefixes that are placed in the "package.use" directory?
I'm re-asking, because I wonder if you're avoiding my question, or perhaps you mean to say "no", but you can't find the right word to answer my question ?
Let me know. Inquiring minds, such as mine, like to learn.
Banging my head against the same problems every 3 to 5 years, because I've forgotten some esoteric detail every time I drop and break a laptop, isn't how I'd like to spend the remainder of my life. I doubt the majority of Gentoo users (who are, btw, guaranteed to be n00bs statistically. ) enjoy being hazed, mocked, ridiculed, etc. either. The majority of your intelligent users are going to have a memory of what they tried in the past that *worked*; and they are going to have links to the appropriate information.
Yes,
Ignorance can be cured; but stupidity is forever.
However; Since youth can't last, some have opted for immaturity. 
etc.
I am a detail oriented person. I apologize if the amount of information I am giving you is more than you can handle.
I'm not good at mind reading. I'll try to improve as I re-learn things.
_________________
What's the difference between a liar and a joker? A liar always claims what they said was just a joke, but a real joker just laughs. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9559
Location: beyond the rim
|
| Posted: Wed May 29, 2024 8:17 am Post subject: |
|
|
| hackernotcracker wrote: | Thank you for reading my blog, wading through all I said! Let me try to follow your argument, here:
| Quote: |
Of course, as you added those lines to package.use, not package.mask (unless your post is wrong). Package.use isn't for masking/unmasking versions, pretty simple. |
The topmost line of your post says nano /etc/portage/package.mask |
That was from your post, and as mentioned it didn't work due to invalid syntax.
You never said anything about using --autounmask at all, if you write "nano /etc/portage/package.use/sphinx" obviously I assume you put the content there manually. Never used --autounmask myself, but pretty sure if it suggests modifying package.use it will not put an entry there without any USE flag specifiers to solve a different problem than you described.
| Quote: | | That last line has an operator in it, and is a constraint. |
No, it is not a constraint. It just tells portage "when using >=dev-libs/icu-74.2 for anything, add abi_x86_32 to the USE variable". It may resolve some constraints specified by other ebuilds depending on dev-libs/icu though.
| Quote: | | Am I mistaken? ( I make mistakes; my memory has a lot of years of changing standards flowing through it since programmers *love* to change their rules over the years. ) |
The syntax and semantics of portage config files haven't really changed over the years, at most they were expanded and some locations were changed. One notable exception is package.keywords, but we're not talking about that here. Haven't used Gentoo for over a decade here, and those files still work the same way as they did when I left. What has been changed is that packages these days impose a lot more constraints about the configuration in an attempt to avoid build and runtime errors.
| Quote: | | If package.use is not for constraints, could you simply explain why does portage *insist* on editing my package.use file (and agressively STOPPING the build forcing me to accept) by adding a constraint to a package in the package.use directory? |
See above, it is trying to resolve a constraint imposed by the listed dependency chain. The error message that showed up before you used --autounmask-write had more details about that. But I guess just using --autounmask-write to magically solve problems is more appealing than trying to understanding what portage is telling you (I mean that, portage error messages can be pretty hard to understand if you don't know how to read them. But you never listed any of them, only your misguided solution attempts, so that is the only thing I could comment on).
| Quote: | | My original line ought to work for *all* icu packages, why then does portage bother aggressively breaking the build to add the (??irrelevant??) constraint operator ">=" ?? |
Quite the opposite: Portage tries to be minimally invasive here by limiting the change to the actual constraint imposed by the ebuild. You REALLY need to understand what package.use does, pretty sure that would have saved you a lot of time and headaches.
| Quote: | You're arguing I *can* specify a package without operator in package.use, without it being an error.
But I *can't* do the exact same thing in package.mask, without it being an error ? |
Both package.mask and package.use use the same syntax for listing packages. The error in your package.mask entry was that you tried to specify a version without an operator, that won't work in any of the /etc/portage/package.* config files (you rarely want to limit the entry to just one exact version anyway)
| Quote: | | In package.accept, I discovered that I don't even need to use the "~amd64" keyword but just put a package name there, and it knows I want to change constraints on that package to include it. Presumably it 'knows' because the directory is named package.accept ?? It's only the package (or packages) that I want to accept which the files inside must specify. |
In package.accept_keywords I added the simplification that if you don't specify any keywords after the package selector then portage will implicitly assume ~arch as that covers like 95% of the usage of that file (that was over 15 years ago by the way). You still can specify the keyword, or any other keyword though (as said above: options were expanded, but the file still works as before). And obviously package.accept_keywords has (and always had) different semantics than package.mask or package.use.
But as you're again talking about "constraint" I think we are using the term quite differently: To me a constraint is something that imposes restrictions on how portage can resolve the dependency graph. These are usually imposed by ebuilds (e.g. package X MUST be at least version Y and MUST be built with USE=foo), and the portage config files are used to resolve them. So package.mask can be used to specify constraints (it adds restrictions on which packages portage may use), but that is the only config file that can (of the regular used ones at least). Now package.use entries may result in additional constraints, but those are coming from the packages, not the configuration change itself.
| Quote: | I'm thinking we have >=three 'package' directories in Gentoo; all of which are talking the language of packages.
Why are there three distinct lexers parsing these files with different syntax and error reporting protocols ? |
Now I'll just refer you to the documentation if the explanation above doesn't suffice. |
|
| Back to top |
|
|
hackernotcracker
n00b
Joined: 13 Aug 2018
Posts: 18
Location: Oregon, USA
|
| Posted: Wed May 29, 2024 10:42 am Post subject: |
|
|
Please do include a hyperlink to any current documentation for 2024 versions of Gentoo, that will sustain your argument. I've searched gentoo.org for 'constraints.'
You haven't given me a link; and I seriously doubt there is any official (mainstream) documentation of the sort you imagine which isn't chock full of errors and examples that DON'T even work, today.
| Quote: | | You never said anything about using --autounmask at all, if you write "nano /etc/portage/package.use/sphinx" obviously I assume you put the content there manually. |
So what?
The one package you mention, package.usr/sphinx, I *did* put the content there manually. Your assumption was correct.
My use of --autounmask, elsewhere, doesn't invalidate my argument, one iota.
People can go back and read the previous posts, you're being disingenuous.
| Quote: |
Never used --autounmask myself, but pretty sure if it suggests modifying package.use it will not put an entry there without any USE flag specifiers to solve a different problem than you described. |
Please elucidate. I don't follow your grammar; it will not put an entry "there" (??package.use??) ... to solve a different problem ??
I posted an exact copy of what portage did to my file. So, your 'pretty sure' is pretty 'wrong'.
There is only one use flag, abi_x86_32, and I put it in the topmost line of the file, manually.
When I tried to do an emerge, the system stopped and said I must change the *use* flag of that package.
After emerge forced me to 'fix' a use flag; Whether or not I re-run the program with --autounmask, is totally irrelevant.
My original line was *inadequate* according to Portage; it was NOT obvious to me why, so I reran with --autounmask.
The only change to my file was a specific package number and an operator. I'm not a Gentoo writer, I have no idea why it did that.
| Quote: | | But as you're again talking about "constraint" I think we are using the term quite differently: To me a constraint is something that imposes restrictions on how portage can resolve the dependency graph. |
Yes, it is clear we are using it differently.
To me a constraint is any restriction or changeable degree of freedom itself, (regardless of it's source) when a problem is being solved. Not just for inter-dependencies of packages.
In electrical engineering, math, and in my software engineering courses; the way I use the word is how it is generically used.
Mechanical engineers are the only engineers who *might* consider constraints as being negative, only; like the novel sense you are using it.
Any operator that *changes* (either freeing, or restricting, a possible implementation for any software version) is a 'constraints' operator as used in software engineering courses at accredited colleges. It may not constrain what *you* want it to constrain, but it is a constraints operator.
There is no formal definition of 'constraint' or 'token' in the Gentoo Handbook that I linked; nor the man pages I linked.
This is why I am saying it is 'esoteric' knowledge that you are using; and you don't even recognize it.
I noted, for example, that in the book 'C', K&R and ANSI, there is defined the idea of "token" formally (This is common knowledge to programmers).
Where did you learn what "token(s)" are ? The definition was not in the handbook or manpages that I linked for your review.
The error message I was given by Gentoo, was not "syntax" error as you say. It was "unrecognized tokens".
There are obviously different lexical programs operating on , package.accept_keyword, package.use, and package.mask; and for some reason generic engineering terms that I know have become specialized in Gentoo in ways that are esoteric.
That's the only way I can imagine (and my IQ is high) that you could arrive at the conclusion that the report was a 'syntax' error. You obviously know a lot about what Gentoo wants (no disrespect here, regarding your own ability to use the system); However, present documentation doesn't make it clear what you are saying.
You somehow knew/remembered that the words "unrecognized tokens" refers to the operators even though the word "Token" is not specific to operators, and tokens technically *can* refer to atoms as defined in the Gentoo man pages.
The error message I got, in general, could mean (and I wondered if it did), "unrecognized atom".
Esoteric knowledge is not available to n00bs. And it is a hallmark of software developed by a 'few', when it becomes used by the 'many', that assumptions and knowledge of people inheriting the package are different than the ones who wrote it. Condescension merely breeds anger ; and people who don't have extensive experience, can't write good wiki pages, either.
So, it's a vicious cycle. Those who know the esoteric, won't translate, those who don't know the esoteric, can't translate.
The criteria for being esoteric is not determined by the age of the software (number of years, something has 'been' this way), Rather, esoteric is determined by the percentage (<20% or so) of active users who know the knowledge.
That's why I am amazed this stuff isn't in a FAQ, yet. Because your notion of constraints has become aging slang.
| Quote: | | No, it is not a constraint. It just tells portage "when using >=dev-libs/icu-74.2 for anything, add abi_x86_32 to the USE variable". It may resolve some constraints specified by other ebuilds depending on dev-libs/icu though. |
Sigh:
Even if I accept your reasoning; you're still wrong because the package will not compile (at all), regardless of dependencies, if the use file is not edited. So, the dependency graph can NOT BE resolved, without a change of the use flags file.
I think it would be *wrong* for Gentoo to build specified versions of the package in the >= line, without the USE flag applied; therefore the build system is *constrained* to run programs or at least set certain compiler flags during compilation of some versions of software packages.
Yes: I admit, what I saw happen is weird.
The amazing thing here, is that I added abi_x86_32 to the use flags of all package versions;
But the emerge was, stopped, in order to do what ?
add ">=" and "-74.2" to my use file.
It is stupidity or a bug that emerge would stop my emerge command if it weren't trying to force something to happen.
But: Portage definitely constrained *my* freedom as a user of the system; therefore adding >= ATOM -number was a *constraint*.
Since I've obviously torched your position; let me propose a couple of other questions to the community in general.
If I programmed emerge to add an "=" sign to all atoms in package.mask that don't have operators, but are explicit, including version number; would it confuse you, and many other programmers? AKA: Is it not obvious that a full package name in a package.mask directory, that can be exactly one version of the software, means that version of the software ought not be installed?
Or again, if this is considered popularity driven:
If 95% of all debit card purchases were found to be at fast food places, would any bank who said "we will not accept debit card purchases for hardware stores since they are not fast food" be justified? eg: Is it appropriate to limit the syntax of the page.mask directory to only what a majority of people will want to do with it?
Therefore: How many people would complain if I proposed changing the error message in 'package.mask' from "unrecognized tokens" to "syntax error"? ( That, I think, is the least contentious change. And yes, there will always be complainers. )
How many would complain if I proposed adding an automatic '=' sign to atoms that are fully explicit ?
There's >= two major reasons people resist good changes; #1 *pride/ego*, and #2 *it's too hard for them to do, themselves, so they get mad when anyone else suggests it as it might make them look bad.*.
_________________
What's the difference between a liar and a joker? A liar always claims what they said was just a joke, but a real joker just laughs.
Last edited by hackernotcracker on Fri May 31, 2024 7:54 am; edited 3 times in total |
|
| Back to top |
|
|
hackernotcracker
n00b
Joined: 13 Aug 2018
Posts: 18
Location: Oregon, USA
|
| Posted: Fri May 31, 2024 5:27 am Post subject: |
|
|
For those who'd like to replicate my experiment, here's the /etc/fstab, I am using.
I'm replacing UUID's with XXXX, since your id's will not be the same as mine.
You can find your ids with the command "blkid"
The number you want to use is the "PARTUUID=" at the end of each line.
| Code: |
PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /efi vfat defaults,noatime 0 0
PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /home btrfs defaults,compress=zlib:9,noatime 0 0
PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /usr/cache btrfs defaults,compress=lzo,noatime 0 0
PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /mnt btrfs defaults,compress=zlib:9,noatime 0 0
PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /opt btrfs defaults,compress=zlib:9,noatime 0 0
PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /usr/src/linuxKernelSrc btrfs defaults,compress=lzo,noatime 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults, size=16M 0 0
tmpfs /run tmpfs defaults, size=128M 0 0
tmpfs /tmp tmpfs nodev,nosuid,noexec,size=2048M 0 0
|
This has given me no trouble for desktop use, saves a lot of wear and tear on the hard drive (etc), and has enough temporary memory for the things I do; eg: SDL games, kicad, and Deal-ii, finite element analysis software (supercomputer scalable.)
For networking, you'll probably want a minimal /etc/wpa_supplicant/wpa_supplicant.conf
This is an example of how I have wpa_supplicant configured, while setting up the laptop.
| Code: | ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
update_config=1
network={
ssid="Your Router's Wireless name"
psk="whatever your password is"
proto=WPA # or WPA2
key_mgmt=WPA_PSK
}
network={
ssid="public library"
key_mgmt=none
id_str="open wifi"
}
|
It may be necessary to start dhcpcd, although the stage 3 tarballs I gave earlier in the thread seem to already be starting it.
| Code: | bash# rc-service dhcpcd start
|
With my system booted, I (as superuser), launch wpa_supplicant manually on the command line:
| Code: | bash# wpa_supplicant -Dnl80211 -i wlp1s0 -c /etc/wpa_supplicant/wpa_supplicant.conf &
|
Rather than depend on manually entering packages to emerge for the world database, I have created an: /etc/portage/profiles/packages file. This makes building two root partitions the same, less error prone.
Files that I don't want installed (yet), I've prefixed by a - sign. This effectively makes those packages a comment.
This file is posted in the state where only rudimentary base packages are installed (No GUI/No Audio/etc.).
I've broken the packages list into three sections, which are labeled by a fake package that I will never install, -app-admin/clog.
| Code: | -app-admin/clog # packages section: ------------------- BASE ---------------------
*app-arch/cpio # Required for kernel compile, module headers (compressed).
*app-portage/gentoolkit # equery side-effects: dbus, pam -> elogind <-, xml, icu, ...
*app-eselect/eselect-repository
*app-arch/p7zip # pkunzip, non free unrar is possible, pulls in yasm compiler (removes pillow, nasm, ... )
*app-admin/sysklogd
*sys-apps/gptfdisk
*sys-apps/usbutils
*sys-apps/net-tools # netstat, route, ... Already installed stage3, keep installed!
*sys-boot/grub
*sys-devel/bc # calculator extension ... Already installed, stage3, keep installed!
*sys-fs/btrfs-progs
*sys-fs/dosfstools
*dev-libs/dbus-glib # ???
*net-analyzer/tcpdump
*net-dns/dnsmasq
*net-ftp/ftp
*net-ftp/atftp # For tplink routers, trivital ftp daemon in.tftpd
*net-wireless/iw
*net-wireless/wpa_supplicant # For maintaining internet wireless connections
-*net-wireless/hostapd # Host access point daemon, for firewall/forwarding of internet.
*net-wireless/bluez # Bluetooth daemon
*net-misc/dhcpcd # ... Already installed, stage3, keep installed!
-*net-misc/ntp # Network time protocol
-*net-misc/bridge-utils # ???
*net-analyzer/nmap
-app-admin/clog # packages section: ---------------- LANGUAGE --------------------
-*dev-java/openjdk
*dev-vcs/git
*dev-python/pip
-app-admin/clog # packages section: ---------------- ADVANCED --------------------
-*x11-apps/xrandr
-*x11-drivers/xf86-input-mtrack
-*x11-libs/libXinerama
-*x11-misc/virtualgl # Allow gl commands to be executed, remotely, llvm ld error clCreateContext, symbol not defined, virtualgl-3.1.1
-*media-tv/v4l-utils
-*media-sound/pulseaudio # Pulse audio uses perl, XML parser, for some strange reason...!
-*media-libs/libsdl # no 2 suffix, wraps libsdl into libsdl2 for legacy games
-*media-libs/virglrenderer # Implement 3D gpu for qemu
-*media-fonts/dejavu # depends on: dev-perl/Font-TTF ?!
-app-admin/clog # packages section: ---------------- complex GUI -----------------
-*x11-apps/mesa-progs # Glxinfo, GLxgears for troubleshooting openGL
-*x11-terms/st
-*x11-terms/xterm
-*x11-wm/openbox
-*x11-misc/obconf # open box configuration program
-*x11-misc/tint2 # Icon minimizer toolbar
-*media-gfx/gimp
-*media-gfx/imagemagick
-*media-sound/pavucontrol
-*media-video/ffmpeg
-*media-video/vlc
-*app-office/libreoffice
-app-editors/gvim
-*sci-visualization/gnuplot
-*app-emulation/qemu
-*sci-electronics/kicad
|
Please note, several packages listed *already* come with the stage-3 tarball already installed.
But (I think) they were installed --oneshot, because when I do an emerge --depclean, those packages are removed.
For this reason, I've included a few package names already installed by stage 3 tarball; eg. so they become a permanent part of the world.
Notice:
I am not planning to install a full desktop, like KDE or GNOME. That would be a lot to expect from the llvm compiler, given how contentious the developers are (retired or not, see example above). I'm not *that* ambitious. I'd rather target a task that I know I can complete.
The attempt here is to make a minimal GUI system, get openGL and hardware acceleration for Radeon cards working with AMDGPU, and allow others to extend what I've done at their leisure.
_________________
What's the difference between a liar and a joker? A liar always claims what they said was just a joke, but a real joker just laughs. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9559
Location: beyond the rim
|
| Posted: Fri May 31, 2024 9:23 am Post subject: |
|
|
https://dev.gentoo.org/~zmedico/portage/doc/man/portage.5.html (or just use "man portage" on your system, that link is just an online copy).
Not bothering to read the new chapters of your book as you're clearly not looking for support but only validation of your claims. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
