rpm build error - build

I tried to build a rpm package which is giving me the following error
/usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/RPMS
find: invalid predicate `'
error: Bad exit status from /var/tmp/rpm-tmp.86590 (%install)
what could be the reason .can any one help me in this...Thanks

Try defining the BuildRoot variable in your spec file. The find-debuginfo script looks in to that directory several times, and will die without it.
This will usually look something like: BuildRoot: %{_tmpdir}/%{name}-%{version}-%{release}
As to your second question, I can't say without seeing spec file and sources directly, and I am by no means an RPM expert. I will recommend you to Chapter 13 of Maximum RPM(there are copies available free online), and the notes from Tom Callaway's presentation on How to make good RPM packages - I've found the spec examples here to be very helpful in the past.

In your spec you can do this at the top:
%define debug_package %{nil}
This should bypass this problem

I just hit this same problem when attempting to build on a RedHat 5.3 server. Here is what I found. The error appears to be caused by an empty RPM_BUILD_ROOT variable. Below is one offending line:
find "$RPM_BUILD_ROOT" ! -path "${debugdir}/*.debug" -type f \
\( -perm -0100 -or -perm -0010 -or -perm -0001 \) \
-print |
If RPM_BUILD_ROOT hasn't been defined, then the first argument to find is an empty string "", which causes this error. Interestingly enough, if you remove the quotes from around $RPM_BUILD_ROOT, then command works fine since the first argument would become the "!". Since it's not required to define a "BuildRoot:" in the spec file, this certainly looks like a bug to me.

Related

How can I make the GCC error messages more readable (e.g., with color)? [duplicate]

For some long errors, the gcc output is dense and has lots of line-wrapping etc. Especially when errors are subtle, it can take me 10-30 seconds of squinting to parse it with my eyes.
I've taken to pasting this in an open code-editor window to get some basic syntax highlighting and enable reformatting with regex's.
Has anyone invented a more automated method?
I use this script, called colorize:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
Then I just call it like this(using make or whatever build system):
make |& colorize
And I get color output similar to clang.
I've found colorgcc to be invaluable. By introducing coloring, it becomes much easier to mentally parse the text of gcc error messages, especially when templates are involved.
If your errors are template related, take a look at STLfilt:
http://www.bdsoft.com/tools/stlfilt.html
gccfilter does coloring & simplification of messages.
http://www.mixtion.org/gccfilter/
If you use GCC 4.9, you can add -fdiagnostics-color=auto as an additonal compilation flag. At some later version, the color has been enabled by default.
check diagcc out, you can get something like this:
If your gcc ≥ 4.9, you can use argument -fdiagnostics-color=always.
To answer your question 4 years later, clang should be mentioned here.
Here's my current hack, which mostly inserts newlines and indentation in strategic locations along with a little extra annotation, but does nothing to address STL verbosity.
Note that as currently implemented, this script does not return an error if the compiler returned one, so doing something like this will not work properly: (make && ./runApplication). This could surely be remedied by someone with better bash-fu.
#!/bin/bash
# SUBSTITUTION RULES:
# Note: All substitution rules must end in a semi-colon, inside of the closing quote
subColonSpace='s/: /:\n /g;'
subSrc='s/^src/\nsrc/;'
subError='s/error:/error:\n\n======================================\nERROR:/;'
subWarning='s/ *error: *\n/ERROR: /;'
subWarning='s/ *warning: *\n/WARNING: /;'
subNote='s/note:/\n NOTE:/g;'
subOpenTic='s/‘/\n ‘/g;'
subOpenParen='s/(/(\n /g; s/(\n *)/()/g;'
subCommaSpace='s/, /,\n /g;'
# Note: The order of these may matter
sedExpr="$subColonSpace $subSrc $subError $subWarning $subNote $subOpenTic
$subOpenParen $subCommaSpace"
makelogFile=makelog.tmp
make "$#" 2>&1 | sed "$sedExpr" | tee $makelogFile
if you like Ruby there is GilCC! GilCC is very easy to install (just copy it to the bin folder) and easy to use (just type GilCC instead of "gcc" or "make") and it works with GCC version. Unlike Perl based scripts GilCC has statistics such as # of warnings and error and compile time. You don't have to mess with .bash files and it is cross platform as long as you can run Ruby on your machine. Since it has the power of Ruby; you can make GilCC do different things such as trigger test automation, unit test or program external hardware after a successful build.
Here is the link to the download page: http://www.onlysolutionssoftware.com/gilcc/

gnu emacs ebrowse doesn't work well when viewing some large codebase

My emacs version is 27.
I think ebrowse is native c++ parser bundled with emacs, so i spent some time learning it.
I first use it to parse LevelDB, and it worked quite good, but when parsing folly, problems occured.
My command to generate BROWSE file is :
find -E . \( -regex ".*\.(h|cpp)" ! -regex ".*Test.*\.(h|cpp)" ! -regex ".*/test/.*\.(h|cpp)" \) | ebrowse
The terminal has some error message:
Then i open the file and look up the IOBuf class:
Its parsing result is wrong(i think), i couln't even enter the IOBuf class
Was there anything wrong i made? Thanks!

scrot : giblib error saving to file failed

I have installed Scrot on Centos 7,
giblib error saving to file ***.png failed
occurs for
scrot -s
Help for a solution. Thanks a lot.
Are you telling scrot to save to an explicit file?
Several things can go wrong:
you target a file that has an unsupported extensions. scrot -s asdf doesn't work. scrot -s asdf.png does.
I've seen scrot examples with quotes in the output. Special characters can mean trouble within quotes, for example ~. scrot ~/asdf.png works, scrot "~/asdf.png" doesn't work. Single quotes do not work either. That's the same as with mv, special character expansion. This gives a giblib error, which is a little confusing.
If this is your problem, do not to use quotes, use absolute pathes, or let scrot create its default file and move it afterwards as described here:
scrot -e 'mv $f ~/Pictures/screenshots'

Rename multiple files with /usr/bin/rename using regex

I have a lot of pdfs that I want to rename with /usr/bin/rename.
The files are named in the following pattern:
<rating> <a pretty long title> (<author> <year>).pdf
e.g.: +++ The discovery of some very interesting stuff (Dude 1999).pdf
rating: 1 to 5 '+' signs
year: numerical
They should be renamed into the following pattern:
<author>, <year> <rating> <a pretty long title>.pdf
e.g.: Dude, 1999 +++ The discovery of some very interesting stuff.pdf
I tried to use /usr/bin/rename and wrote this command:
rename 's/(.*)\ (.*)\ \((.*)\ (.*)\).pdf/$3, $4 $1 $2.pdf/' *.pdf
However, the command does not consider that the rating always contains '+' signs and that the year is always numerical. How can I achieve this? I tried something like ([+]{1,5}) and ([0-9]{4}), but it didn't work.
Is rename actually able to interpret something other than (.*) as the input for the variables $1 ... $n?
Thanks for your help!
This works fine for me:
rename 's/(\+{1,5}) (.*) \((.*) ([0-9]{4})\).pdf/$3, $4 $1 $2.pdf/' -- \
'Dude, 1999 +++ The discovery of some very interesting stuff.pdf'
... however your question doesn't quote the error message, so it's hard to tell what might be wrong in your situation.
Just as a warning, there are two different versions of /usr/bin/rename that are widely found on Linux systems, and which have different syntaxes. I assume that you are using the Perl one, however, since your original command worked at all. That means that you can use any Perl expression to modify the name - see perlre for more details.
Unfortunately Fedora (it's my distro) has worthless version of rename.
But I have changed it for perl version of replace utility.
You can find it at CPAN
get and untar archive and then:
# ./Build installdeps
# sudo ./Build install
!!! It actions replace original fedora rename: bin file and manual, but it can be reverted by yum reinstall and may be reverted at next fedora update
Also you can install it separately or use alternatives.

Is there any way to get readable gcc error and warning output at the command line?

For some long errors, the gcc output is dense and has lots of line-wrapping etc. Especially when errors are subtle, it can take me 10-30 seconds of squinting to parse it with my eyes.
I've taken to pasting this in an open code-editor window to get some basic syntax highlighting and enable reformatting with regex's.
Has anyone invented a more automated method?
I use this script, called colorize:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
Then I just call it like this(using make or whatever build system):
make |& colorize
And I get color output similar to clang.
I've found colorgcc to be invaluable. By introducing coloring, it becomes much easier to mentally parse the text of gcc error messages, especially when templates are involved.
If your errors are template related, take a look at STLfilt:
http://www.bdsoft.com/tools/stlfilt.html
gccfilter does coloring & simplification of messages.
http://www.mixtion.org/gccfilter/
If you use GCC 4.9, you can add -fdiagnostics-color=auto as an additonal compilation flag. At some later version, the color has been enabled by default.
check diagcc out, you can get something like this:
If your gcc ≥ 4.9, you can use argument -fdiagnostics-color=always.
To answer your question 4 years later, clang should be mentioned here.
Here's my current hack, which mostly inserts newlines and indentation in strategic locations along with a little extra annotation, but does nothing to address STL verbosity.
Note that as currently implemented, this script does not return an error if the compiler returned one, so doing something like this will not work properly: (make && ./runApplication). This could surely be remedied by someone with better bash-fu.
#!/bin/bash
# SUBSTITUTION RULES:
# Note: All substitution rules must end in a semi-colon, inside of the closing quote
subColonSpace='s/: /:\n /g;'
subSrc='s/^src/\nsrc/;'
subError='s/error:/error:\n\n======================================\nERROR:/;'
subWarning='s/ *error: *\n/ERROR: /;'
subWarning='s/ *warning: *\n/WARNING: /;'
subNote='s/note:/\n NOTE:/g;'
subOpenTic='s/‘/\n ‘/g;'
subOpenParen='s/(/(\n /g; s/(\n *)/()/g;'
subCommaSpace='s/, /,\n /g;'
# Note: The order of these may matter
sedExpr="$subColonSpace $subSrc $subError $subWarning $subNote $subOpenTic
$subOpenParen $subCommaSpace"
makelogFile=makelog.tmp
make "$#" 2>&1 | sed "$sedExpr" | tee $makelogFile
if you like Ruby there is GilCC! GilCC is very easy to install (just copy it to the bin folder) and easy to use (just type GilCC instead of "gcc" or "make") and it works with GCC version. Unlike Perl based scripts GilCC has statistics such as # of warnings and error and compile time. You don't have to mess with .bash files and it is cross platform as long as you can run Ruby on your machine. Since it has the power of Ruby; you can make GilCC do different things such as trigger test automation, unit test or program external hardware after a successful build.
Here is the link to the download page: http://www.onlysolutionssoftware.com/gilcc/