Spacefm
the root.log starts with DEBUG on second line, I’ve not seen that
before. Of course I’m learning, and don’t really know much yet.
The build.log and script_output.log both have a lot, I mean a lot
of “BUILDSTDERR:”.
The Lnav package does not seem to even try to build: I'm not sure but this one
looks unhappy with mock, or it isn’t feeding mock correctly,
“Build failed: mock encountered a problem.” Or maybe something I’m
not seeing.
Part of me reporting this is that I hope to learn better how to
read to logs to see what is wrong when packages don’t build. And
also to help ‘either update and keep’ or identify packages we
should remove as unworkable, to damn old, or whatever. Or move
them to an archive so someone could work on them at some future
time.
We fail on this because that's broken code. Implicit function
declaration means something is being used without a definition. C has
a dumb behavior in which it'll just accept it anyway and create an
empty definition. This is generally _not_ what you want and will cause
segfaults at runtime. Something is broken, codewise.
Getting rid of -Werror=implicit-function-declaration just hides an error in the code.
The better fix is to replace major with gnu_dev_major (and add #include <sys/sysmacros.h> near the beginning of the file if it isn't there already).
OK, this is where I admit I don’t know how
to edit spec files. " replace major with gnu_dev_major
(and add #include <sys/sysmacros.h> near the beginning of
the file if it isn’t there already)" is over my head knowledge
wise. Part of the problem is that in the past when I’ve studied
bash scripting I learn it in the moment but don’t remember what
I’ve learned because I did not use it. I suspect that is about to
change.
How would I write " replace major
with gnu_dev_major":
Also worth mentioning is that if this
package is broken as at the level of it’s code that is not
something for me to be dealing with. Me better stick to learning
.spec files and updating the simple and easy to update packages
and leave the broken stuff to people that know what they are
doing.
So thanks to AngryPenguin for help on both
of these packages. They are built and both install on my 64 bit
system. Specefm works lnav does not. It fails to run with:
and prompting me to review some bash scripting stuff I learned
in a course last year and seem to have promptly forgotten. Like
Grandpa said “to learn it you have to use it”.
So thanks to AngryPenguin for help on both
of these packages. They are built and both install on my 64 bit
system. Specefm works lnav does not. It fails to run with:
and prompting me to review some bash scripting stuff I learned
in a course last year and seem to have promptly forgotten. Like
Grandpa said “to learn it you have to use it”.