- Its never been used beyond assignment to the internal state struct,
so in reality this is entirely free of any rpmbuild-specifics.
Meaning we could trivially lift it to librpmio for macros...
- No functional changes here
Used by rpmdsDNEVR fixing the problem of multiple tags starting with the same character. The characters match the ones used in the dependecy dependency generators during build.
This enables to handle trigger rpmds in the same way as normal
rpmds. Merging of rpmds takes into account trigger indices if
they are set and rpmdsPutToHeader()/rpmdsNewPool() puts/gets
trigger indices into/from header if resulting rpmds is trigger
rpmds.
- VFPv3D16 is a specific type of VFP, which AIUI is never a NEON,
so the test made little sense and, AIUI did not work at all, at
least for detecting NEON-class system.
Test for generic VFPv3 support instead (although this doesn't likely
make a whole lot of sense as AIUI all ARMv7 systems are supposed
to come with VFPv3 level VFP but guess it doesn't hurt either...)
- The local define for HWCAP_ARM_VFPv3D16 from commit
5a04330db8 was wrong, (1 << 13) is
actually HWCAP_ARM_VFPv3. Which is of course exactly what we want here,
but the commit looks fishy because of this.
- This is all just sooooo wonderfully arbitrary...
After looping over the hardlinks and writing their headers entries to the
archive we need to return to the first entry to make sure we do not leave out
other groups of hardlinked files that start between the group we are currently
processing
- The way manageFile() is called, fmode can never be uninitialized
but lets make gcc happy by adding a default case to the switch...
- Additionally make fmode const because it is
- 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 2d67ca74c9
- 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?
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>
- 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)
- 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
- 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.
- Commit 1bdcd05008 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...
- 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
- %__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)
- 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
- 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...
- 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.
- 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.
- 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.
- This was caused by commit 90833a57c5 but
because of another problem fixed in previous commit it didn't exhibit.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Fixes regression from commit c0aad81e9b.
- That commit added line "res = replaceSignature(...)" that sets variable
"res" to value 0. But error handling code following this line expects
this variable set to -1. So in case of error value 0 (success) was
returned but value -1 (failure) should have been returned.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
* Init then translate all strings
* Add vi to LINGUAS
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- During building of a package a dummy tag is added to the signature
header. This tag reserves some space for gpg signatures. So during
signing of the package the gpg signatures can be put in this reserved
space and it is not necessary to rewrite the whole package to make some
space for gpg signatures.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- This change shorten signing time beacause it is not necessary to
write data that should be signed, into a temporary file and then pass
this file to gpg program.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Panu Matilainen