hi, i'm just accidentally recognize that on rhel-6: ---------------------------------------------- # rpm -qpi rhnsd-4.9.3-2.el6.x86_64.rpm warning: rhnsd-4.9.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID f21541eb Name : rhnsd Relocations: (not relocatable) Version : 4.9.3 Vendor: Red Hat, Inc. Release : 2.el6 Build Date: Wed 24 Mar 2010 03:11:14 PM CET Install Date: (not installed) Build Host: ls20-bc2-13.build.redhat.com Group : System Environment/Base Source RPM: rhnsd-4.9.3-2.el6.src.rpm Size : 92865 License: GPLv2 Signature : RSA/8, Tue 20 Apr 2010 07:50:37 PM CEST, Key ID 938a80caf21541eb Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : https://fedorahosted.org/spacewalk Summary : CentOS Network query daemon Description : The CentOS Update Agent that automatically queries the CentOS Network servers and determines which packages need to be updated on your machine, and runs any actions. ---------------------------------------------- did you see the strange thing? (i run ths command on a centos system) so if centos just rebuild the same src.rpm then do not need to modify the package and the spec! (ok this pacakge won't be included in centos anyway, just an example) since in that case the buildhost and vendor changed because of the build system and the summary and other part will change "automagically" even if the spec file contains _hard coded_ "Red Hat". this can save same useless work..
just my 2c.
Hi,
i'm just accidentally recognize that on rhel-6:
# rpm -qpi rhnsd-4.9.3-2.el6.x86_64.rpm warning: rhnsd-4.9.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID f21541eb Name : rhnsd Relocations: (not relocatable) Version : 4.9.3 Vendor: Red Hat, Inc. Release : 2.el6 Build Date: Wed 24 Mar 2010 03:11:14 PM CET Install Date: (not installed) Build Host: ls20-bc2-13.build.redhat.com Group : System Environment/Base Source RPM: rhnsd-4.9.3-2.el6.src.rpm Size : 92865 License: GPLv2 Signature : RSA/8, Tue 20 Apr 2010 07:50:37 PM CEST, Key ID 938a80caf21541eb Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : https://fedorahosted.org/spacewalk Summary : CentOS Network query daemon Description : The CentOS Update Agent that automatically queries the CentOS Network servers and determines which packages need to be updated on your machine, and runs any actions.
did you see the strange thing? (i run ths command on a centos system) so if centos just rebuild the same src.rpm then do not need to modify the package and the spec! (ok this pacakge won't be included in centos anyway, just an example) since in that case the buildhost and vendor changed because of the build system and the summary and other part will change "automagically" even if the spec file contains _hard coded_ "Red Hat". this can save same useless work..
Seems to be pushed directly from Spacewalk repos. Guess they might 'fix' it before release.
On 07/31/2010 12:11 PM, Marcus Moeller wrote:
Hi,
i'm just accidentally recognize that on rhel-6:
# rpm -qpi rhnsd-4.9.3-2.el6.x86_64.rpm warning: rhnsd-4.9.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID f21541eb Name : rhnsd Relocations: (not relocatable) Version : 4.9.3 Vendor: Red Hat, Inc. Release : 2.el6 Build Date: Wed 24 Mar 2010 03:11:14 PM CET Install Date: (not installed) Build Host: ls20-bc2-13.build.redhat.com Group : System Environment/Base Source RPM: rhnsd-4.9.3-2.el6.src.rpm Size : 92865 License: GPLv2 Signature : RSA/8, Tue 20 Apr 2010 07:50:37 PM CEST, Key ID 938a80caf21541eb Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : https://fedorahosted.org/spacewalk Summary : CentOS Network query daemon Description : The CentOS Update Agent that automatically queries the CentOS Network servers and determines which packages need to be updated on your machine, and runs any actions.
did you see the strange thing? (i run ths command on a centos system) so if centos just rebuild the same src.rpm then do not need to modify the package and the spec! (ok this pacakge won't be included in centos anyway, just an example) since in that case the buildhost and vendor changed because of the build system and the summary and other part will change "automagically" even if the spec file contains _hard coded_ "Red Hat". this can save same useless work..
Seems to be pushed directly from Spacewalk repos. Guess they might 'fix' it before release.
it seems you don't understand it. rpm change 'on the fly' all 'Red Hat' string to the given os's vendor. if you run the above command on rhel-6 beta on the same file then it gives: ---------------------------------------------- # rpm -qpi rhnsd-4.9.3-2.el6.x86_64.rpm Name : rhnsd Relocations: (not relocatable) Version : 4.9.3 Vendor: Red Hat, Inc. Release : 2.el6 Build Date: Wed 24 Mar 2010 03:11:14 PM CET Install Date: (not installed) Build Host: ls20-bc2-13.build.redhat.com Group : System Environment/Base Source RPM: rhnsd-4.9.3-2.el6.src.rpm Size : 92865 License: GPLv2 Signature : RSA/8, Tue 20 Apr 2010 07:50:37 PM CEST, Key ID 938a80caf21541eb Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : https://fedorahosted.org/spacewalk Summary : Red Hat Network query daemon Description : The Red Hat Update Agent that automatically queries the Red Hat Network servers and determines which packages need to be updated on your machine, and runs any actions. ----------------------------------------------
On Sat, 2010-07-31 at 12:19 +0200, Farkas Levente wrote:
The CentOS Update Agent that automatically queries the CentOS Network servers and determines which packages need to be updated on your machine, and runs any actions.
< The difference is here, above and below.>
The Red Hat Update Agent that automatically queries the Red Hat Network servers and determines which packages need to be updated on your machine, and runs any actions.
--- I guess it is some sort of dynamic changing on the fly if that is true, per diff OS. Have not tried it myself though.
John
On 07/31/2010 02:05 PM, JohnS wrote:
On Sat, 2010-07-31 at 12:19 +0200, Farkas Levente wrote:
The CentOS Update Agent that automatically queries the CentOS Network servers and determines which packages need to be updated on your machine, and runs any actions.
< The difference is here, above and below.>
The Red Hat Update Agent that automatically queries the Red Hat Network servers and determines which packages need to be updated on your machine, and runs any actions.
I guess it is some sort of dynamic changing on the fly if that is true, per diff OS. Have not tried it myself though.
wouldn't the above be the exact effect of specspo ?
/* don't shoot me if I am wrong but ... */
Hi.
the rpm -qpi text which is shown is just a translation that goes through /usr/share/locale/en_US/LC_MESSAGES/redhat-dist.mo (specspo package). This is what I have traced. Scientific Linux for example kept "Red Hat" in it.
So you can try
export LANG=C
before executing the rpm -qpi xxx.rpm command and it will not be translated.
But it were nice to create such a "feature" as an RPM macro that will make it easier for rebuilders (so Fedora must do this first).
- I'm on vacation for 2 weeks beginning tomorrow. Hope that Upstream will release el6 when I return.
Greetings, B.S.
On Jul 31, 2010, at 7:20 AM, Brian Schueler wrote:
Hi.
the rpm -qpi text which is shown is just a translation that goes through /usr/share/locale/en_US/LC_MESSAGES/redhat-dist.mo (specspo package). This is what I have traced. Scientific Linux for example kept "Red Hat" in it.
So you can try
export LANG=C
before executing the rpm -qpi xxx.rpm command and it will not be translated.
Yep.
But it were nice to create such a "feature" as an RPM macro that will make it easier for rebuilders (so Fedora must do this first).
Expanding strings with a macro is trivially arranged. In fact its possible to do Requires: %%{opaqueN} >= %%{opaqueEVR} as well as %files %%{opaquebindir}/file and %post -p %%{opaqueinterpreter} for like 4-5 years now in RPM.
Note: the double'd %% to ensure that the expansion is during install, not during build. Not also that _NO_ rebuild is needed whatsoever,
I've also offered to end all the %{?dist} and %{?repo} vanity branding foolishness by doing an expansion on package identifiers.
The far far harder issue is ensuring that the right values are configured in each and every context. That's no problem that can be solved by an RPM implementation.
73 de Jeff