rpm-5.4.16 snapshot

Jeff Johnson n3npq at mac.com
Sun Apr 24 16:53:05 CEST 2016


On Apr 24, 2016, at 6:03 AM, Elan Ruusamäe wrote:

> On 24.04.2016 12:51, Elan Ruusamäe wrote:
>> 
>> anyway, i finally installed the built version. the sasl2 error is probably from somewhere else.
>> 
>> 12:48:25 root[load: 0.00]@new-server /# rpm -q rpm
>> rpm-5.4.16-0.1.i686 
> There are 1 package to install, 1 to remove:
> I filesystem-4.0-46.i686
> R filesystem-4.0-42.i686
> Need to get 19.7KB of archives (19.7KB to download).
> 
> Retrieving th::filesystem-4.0-46.i686.rpm...
> .............................. 100.0% [19.7K (19.7K/s)]
> warn: tag Name(1000) type(0x4) != expected type(0x10006)
> warn: tag Summary(1004) type(0x7) != expected type(0x10006)
> warn: tag Buildhost(1007) type(0x4) != expected type(0x10006)

No, the above has nothing to do with I18N.

rpm-5.4.16 explicitly checks the data type on all metdata header tags.

Unfortunately, there are ancient tag number collisions between signature
and metadata headers between
	RPMSIGTAG_SIZE			RPMTAG_NAME
	RPMSIGTAG_MD5			RPMTAG_SUMMARY
	RPMSIGTAG_PAYLOADSIZE	RPMTAG_BUILDHOST
that need to be handled by marking the headerGet()/headerNext() access with
the flag HEADERGET_SIGHEADER.

The warning is there to ensure that the HEADERGET_SIGHEADER has been specified.

Presumably those messages are triggered by poldek access, not rpm.

You can also patch tagValidate() in rpmdb/tagname.c to avoid the warning message
(which is what recent RPM versions was doing) if you cannot find the place
where HEADERGET_SIGHEADER needs to be added.

> Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 1...
> Preparing... ########################################### [100%]
> Repackaging...
>   1:filesystem ########################################### [100%]
> Upgrading...
>   1:filesystem ########################################### [100%]
> Installing set #2
> 
> probably related to RPM_I18NSTRING_TYPE what jbj talked and i don't understand.
> 

Again, nothing to do with I18N, but rather disambiguating signature from metadata
header tagno's.

hth

73 de Jeff

> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



More information about the pld-devel-en mailing list