"rpmkey -K" didn't show error message in case of malformed signature

- Fixes regression from commit 8cbc1bd92990b2351856a038d44d804c8ab46bd9

Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Export header magic in python module as rpm.header_magic bytes object
Try to cope with duplicate id's and names in verification (ticket #872)

- When duplicate user/groupnames or UID/GIDs are present, data can be
  inconsistent depending on which way the id/name lookup is done.
  Reporting an error when neither the file ownership or the related
  user/group entry was changed on the system seems wrong, so try
  to do better... Look up the data both ways and only fail the
  verification if data from both is wrong, but warn about duplicates
  on inconsistent results.
Fix ancient buffer overflows on macro define and undefine (RhBug:1087000)

- Both doDefine() and doUndefine() assumed the macro string would
  always fit into MACROBUFSIZ, which of course is true for any
  normal use but we cant make such assumptions.
- In the case of %define/%global there are various other overrun-issues
  that need further changes to fix.
Avoid pointless large stack alloction (RhBug:1106594)

- Within rpm itself, this allocation from 12 years ago doesn't come anywhere
  close to stack limits on Linux at least, but since we're a library
  we should be considerate to API users stack needs as well. Allocate
  the buffer from heap instead, its not performance critical either
  since this will always be limited by physical IO and digest calculation
  speed rather than a single malloc.
Fix ancient buffer overflow on unterminated macro options

- Test for terminating ')' existence before copying, otherwise we'll
  end up walking over the edge of the world.
- Return address from doDefine() on error will likely differ after
  this, whether that actually affects anything remains to be seen...
Fix libtool dependency generation with libtool >= 2.4.2

- libtool string change broke our scripts and nobody noticed for
  a long time... Related to RhBug:1061619.
Drop the experimental collection support

- The basic concept is not without merit but what was implemented here
  has been stuck in experimental state in middle of two sorta conflicting
  goals for four years now, and world has moved onward in the meanwhile.
  The sepolicy part is better handled in the new selinux plugin, and other
  action business belongs to packages (in the form of some trigger-like
  scripts or such) rather than rpm plugins.
- Deleted here, but the sepolicy plugin functionality still needs
  merging into the new selinux plugin...
- RPMTAG_COLLECTIONS left in place but tagged unimplemented as per policy
  to never actually remove tags
Initialize plugins based on DSO discovery

- %__transaction_plugins style configuration is problematic for plugins
  because we want plugins to be, well, pluggable. As in drop-in to
  enable, which is not achievable with a single macro entry. Look up
  all DSO's from the plugin dir and enable if a matching
  %__transaction_foo macro is defined.
- This isn't optimal but it'll buy us the drop-in capability, which
  is what matters most right now. We'll want to have forcability as
  well later on (ie it should be possible to require given plugins
  to be present)
Add disabler flag + --noplugins cli switch for plugins

- Always knew we'd need a plugin disabler flag sooner than later but
  didn't realize enabled plugins would fail basically the entire
  test-suite :)
- Enable --noplugins for entire test-suite for now, but eventually
  we'll need to come up with ways to test plugins as well
Handle line continuation in grabArgs() (related to RhBug:1045723)

- Commit 1bdcd0500865efd3566efd7f951228f69b58e755 to fix RhBug:1045723
  broke some funky java macros in Fedora which include line continuation
  in the argument (comments 6-7 in the bug). That it ever worked seems
  far more like luck than by design but since this seems to fix it...
Use unified libtool version for all our libraries

- Our libraries are in reality so interdependent that its not even
  possible to use them independently of others, so having them
  all follow sort of independent versioning information just doesn't
  make any sense and is a PITA everytime I need to touch the data.
- This causes librpmsign soname bump with no good reason so its
  probably "evil" and all ... so sue me, its not as if anybody
  is actually using this library outside rpm itself.
Bump library versions to match reality

- Rpm 4.11.2 is at 5:1:2. We've tonne of new APIs but none removed
  or changed incompatibly (I think, knock wood...) so no need
  for full soname bump, this brings us to libtool version 6:0:3
  in preparation for rpm 4.12
Update translations from Transifex, including two new ones
Change snapshot tarball versioning to use '-' instead of '.'

- ...just to be avoid having to fiddle with separators when going
  from snapshots to -beta, -rc etc...
Check for sys/auxv.h header, always include if present

- We'll need this to access any HWCAP_* bits for platforms that need it,
  regardless of whether getauxval() is present or not. On glibc
  systems this is likely to be equivalent, on others dunno (Solaris
  appears to have sys/auxv.h header as well)
Detect arm armv6hl, armv7hl and armv7hnl machines

Read presence of relevant extensions from hwcap. Loosely based on what's
currently in use for Fedora (armv7hl) and Pidora (armv6hl).

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Add copies for the hwcap bits we need in case not present in auxv.h
Add detection for Sparc Niagara (aka sun4v, aka sparcv9v / sparc64v)

- Loosely based on similar patch in Fedora, but use hwcap instead
  of parsing /proc/cpuinfo. Untested but hey, its only hardware
  detection. What could possibly go wrong?
Only test for ARM FPU on -mfloat-abi=hard builds

- If you dont know, you'll want to keep it that way.
  However if you know this is wrong, let me know...
- If you're still reading, the point here is supposed to be that on ARM
  there are systems with and without a hardware FPU, and then bazillion
  different ABIs which might or might not have to do with the FPU and its
  calling conventions. On any sane system this would be communicated runtime
  via hwcaps but this is ARM so what did you expect? Apparently there is
  a way to get that during runtime by parsing the ELF headers of
  /proc/self/exe but I'll leave that exercise to somebody else. So...
  we only enable the FPU capability tests which determine the arm
  architecture level when we're being compiled to -mfloat-abi=hard.
- If this all sounds crazy and convoluted, I agree. Its also entirely
  possible I've misunderstood some/all of this, uh, subtlety, so dont
  take my word for it. What do I know, I only work here.
- GCC apparently also got this wrong initially, AIUI this
  only works reliably on gcc < 4.5 which dont support hw floating point
  at all, and gcc >= 4.6 where __ARM_PCS_VFP is reliably defined when
  appropriate.
- If you're STILL reading, this glorious one-liner is supposed to
  replace the arch-dependent patch application of the kind of ARM
  detection logic added in commit 2d67ca74c9887d1cb931c1616b84c4f51ec952b5