* [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation @ 2013-04-18 14:27 Bogdan Marinescu 2013-04-18 14:46 ` Mark Hatle 0 siblings, 1 reply; 10+ messages in thread From: Bogdan Marinescu @ 2013-04-18 14:27 UTC (permalink / raw) To: openembedded-core For some platforms (for example emenlow) the RPM installer prefers an invalid package architecture (for example i586 over core2) because /etc/rpm/platform is not properly generated (for example, i586 is listed before core2 in /etc/rpm/platform). [YOCTO #3864] Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> --- meta/classes/package_rpm.bbclass | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass index 3a29976..1bee4b1 100644 --- a/meta/classes/package_rpm.bbclass +++ b/meta/classes/package_rpm.bbclass @@ -276,7 +276,6 @@ package_install_internal_rpm () { # Setup base system configuration echo "Note: configuring RPM platform settings" mkdir -p ${target_rootfs}/etc/rpm/ - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/platform if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-18 14:27 [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation Bogdan Marinescu @ 2013-04-18 14:46 ` Mark Hatle 2013-04-18 15:10 ` Mark Hatle 2013-04-22 12:00 ` Marinescu, Bogdan A 0 siblings, 2 replies; 10+ messages in thread From: Mark Hatle @ 2013-04-18 14:46 UTC (permalink / raw) To: openembedded-core On 4/18/13 9:27 AM, Bogdan Marinescu wrote: > For some platforms (for example emenlow) the RPM installer prefers > an invalid package architecture (for example i586 over core2) because > /etc/rpm/platform is not properly generated (for example, i586 is > listed before core2 in /etc/rpm/platform). > > [YOCTO #3864] > > Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> > --- > meta/classes/package_rpm.bbclass | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass > index 3a29976..1bee4b1 100644 > --- a/meta/classes/package_rpm.bbclass > +++ b/meta/classes/package_rpm.bbclass > @@ -276,7 +276,6 @@ package_install_internal_rpm () { > # Setup base system configuration > echo "Note: configuring RPM platform settings" > mkdir -p ${target_rootfs}/etc/rpm/ > - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/platform I think this is wrong. The /etc/rpm/platform file's first line is supposed to be the equivalent of: [uname -m]-vendor-os. While uname -m doesn't match our tune namings, the concept is the same. The first line simply defines the "tune" of the platform, subsequent lines define alternative names that will run on this system. The INSTALL_PLATFORM_RPM value should be the expected value for the platform as a whole, as it's the default tune value. (Default tune value is expected to be the most accurate value. Looking at the defect: i586-poky-linux emenlow-.*-linux core2-.*-linux i686-.*-linux i586-.*-linux i486-.*-linux i386-.*-linux x86-.*-linux noarch-.*-linux.* any-.*-linux.* all-.*-linux.* The default tune value for that machine was set to i586 by "something". INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - _)${TARGET_VENDOR}-${TARGET_OS}" ${TARGET_ARCH} is similar to the output of uname -m. The error is that this particular BSP should have returned 'core2' as the TARGET_ARCH from what I can tell. Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" So the TUNE_ARCH is being set to i586. So the end result is.. Is 'TUNE_ARCH' set to i586 appropriate? It probably is, because the majority of the system seems to have a limited set of expected values for TARGET_ARCH. So, perhaps the right fix is instead of using 'TARGET_ARCH' in INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. I'd suggest trying that. (But the first line is the system architecture, following lines are alternative packages that are considered compatible.) > > if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then > for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-18 14:46 ` Mark Hatle @ 2013-04-18 15:10 ` Mark Hatle 2013-04-18 16:59 ` Richard Purdie 2013-04-22 12:00 ` Marinescu, Bogdan A 1 sibling, 1 reply; 10+ messages in thread From: Mark Hatle @ 2013-04-18 15:10 UTC (permalink / raw) To: openembedded-core On 4/18/13 9:46 AM, Mark Hatle wrote: > On 4/18/13 9:27 AM, Bogdan Marinescu wrote: >> For some platforms (for example emenlow) the RPM installer prefers >> an invalid package architecture (for example i586 over core2) because >> /etc/rpm/platform is not properly generated (for example, i586 is >> listed before core2 in /etc/rpm/platform). >> >> [YOCTO #3864] >> >> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> >> --- >> meta/classes/package_rpm.bbclass | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass >> index 3a29976..1bee4b1 100644 >> --- a/meta/classes/package_rpm.bbclass >> +++ b/meta/classes/package_rpm.bbclass >> @@ -276,7 +276,6 @@ package_install_internal_rpm () { >> # Setup base system configuration >> echo "Note: configuring RPM platform settings" >> mkdir -p ${target_rootfs}/etc/rpm/ >> - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/platform > > I think this is wrong. The /etc/rpm/platform file's first line is supposed to > be the equivalent of: [uname -m]-vendor-os. While uname -m doesn't match our > tune namings, the concept is the same. The first line simply defines the "tune" > of the platform, subsequent lines define alternative names that will run on this > system. > > The INSTALL_PLATFORM_RPM value should be the expected value for the platform as > a whole, as it's the default tune value. (Default tune value is expected to be > the most accurate value. > > Looking at the defect: > > i586-poky-linux > emenlow-.*-linux > core2-.*-linux > i686-.*-linux > i586-.*-linux > i486-.*-linux > i386-.*-linux > x86-.*-linux > noarch-.*-linux.* > any-.*-linux.* > all-.*-linux.* > > The default tune value for that machine was set to i586 by "something". > > INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - _)${TARGET_VENDOR}-${TARGET_OS}" > > ${TARGET_ARCH} is similar to the output of uname -m. The error is that this > particular BSP should have returned 'core2' as the TARGET_ARCH from what I can tell. > > Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" > > So the TUNE_ARCH is being set to i586. So the end result is.. Is 'TUNE_ARCH' > set to i586 appropriate? It probably is, because the majority of the system > seems to have a limited set of expected values for TARGET_ARCH. > > So, perhaps the right fix is instead of using 'TARGET_ARCH' in > INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. > > I'd suggest trying that. (But the first line is the system architecture, > following lines are alternative packages that are considered compatible.) Forgot one thing. The first line must be fully expanded. Subsequent lines are regex matched by the system. --Mark >> >> if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then >> for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do >> > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-18 15:10 ` Mark Hatle @ 2013-04-18 16:59 ` Richard Purdie 2013-04-18 17:32 ` Mark Hatle 0 siblings, 1 reply; 10+ messages in thread From: Richard Purdie @ 2013-04-18 16:59 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On Thu, 2013-04-18 at 10:10 -0500, Mark Hatle wrote: > On 4/18/13 9:46 AM, Mark Hatle wrote: > > On 4/18/13 9:27 AM, Bogdan Marinescu wrote: > >> For some platforms (for example emenlow) the RPM installer prefers > >> an invalid package architecture (for example i586 over core2) because > >> /etc/rpm/platform is not properly generated (for example, i586 is > >> listed before core2 in /etc/rpm/platform). > >> > >> [YOCTO #3864] > >> > >> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> > >> --- > >> meta/classes/package_rpm.bbclass | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass > >> index 3a29976..1bee4b1 100644 > >> --- a/meta/classes/package_rpm.bbclass > >> +++ b/meta/classes/package_rpm.bbclass > >> @@ -276,7 +276,6 @@ package_install_internal_rpm () { > >> # Setup base system configuration > >> echo "Note: configuring RPM platform settings" > >> mkdir -p ${target_rootfs}/etc/rpm/ > >> - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/platform > > > > I think this is wrong. The /etc/rpm/platform file's first line is supposed to > > be the equivalent of: [uname -m]-vendor-os. While uname -m doesn't match our > > tune namings, the concept is the same. The first line simply defines the "tune" > > of the platform, subsequent lines define alternative names that will run on this > > system. > > > > The INSTALL_PLATFORM_RPM value should be the expected value for the platform as > > a whole, as it's the default tune value. (Default tune value is expected to be > > the most accurate value. > > > > Looking at the defect: > > > > i586-poky-linux > > emenlow-.*-linux > > core2-.*-linux > > i686-.*-linux > > i586-.*-linux > > i486-.*-linux > > i386-.*-linux > > x86-.*-linux > > noarch-.*-linux.* > > any-.*-linux.* > > all-.*-linux.* > > > > The default tune value for that machine was set to i586 by "something". > > > > INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - _)${TARGET_VENDOR}-${TARGET_OS}" > > > > ${TARGET_ARCH} is similar to the output of uname -m. The error is that this > > particular BSP should have returned 'core2' as the TARGET_ARCH from what I can tell. > > > > Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" > > > > So the TUNE_ARCH is being set to i586. So the end result is.. Is 'TUNE_ARCH' > > set to i586 appropriate? It probably is, because the majority of the system > > seems to have a limited set of expected values for TARGET_ARCH. > > > > So, perhaps the right fix is instead of using 'TARGET_ARCH' in > > INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. > > > > I'd suggest trying that. (But the first line is the system architecture, > > following lines are alternative packages that are considered compatible.) > > Forgot one thing. The first line must be fully expanded. Subsequent lines are > regex matched by the system. We have a problem here since the machine specific packages are meant to be preferred over the "tune" specific ones by definition of the way OE has long since worked, the structure of the PACKAGE_ARCHS variable and so on. As I understand it, this will not happen with this file setup in this way. Cheers, Richard ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-18 16:59 ` Richard Purdie @ 2013-04-18 17:32 ` Mark Hatle 2013-04-19 12:18 ` Richard Purdie 0 siblings, 1 reply; 10+ messages in thread From: Mark Hatle @ 2013-04-18 17:32 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On 4/18/13 11:59 AM, Richard Purdie wrote: > On Thu, 2013-04-18 at 10:10 -0500, Mark Hatle wrote: >> On 4/18/13 9:46 AM, Mark Hatle wrote: >>> On 4/18/13 9:27 AM, Bogdan Marinescu wrote: >>>> For some platforms (for example emenlow) the RPM installer prefers >>>> an invalid package architecture (for example i586 over core2) because >>>> /etc/rpm/platform is not properly generated (for example, i586 is >>>> listed before core2 in /etc/rpm/platform). >>>> >>>> [YOCTO #3864] >>>> >>>> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> >>>> --- >>>> meta/classes/package_rpm.bbclass | 1 - >>>> 1 file changed, 1 deletion(-) >>>> >>>> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass >>>> index 3a29976..1bee4b1 100644 >>>> --- a/meta/classes/package_rpm.bbclass >>>> +++ b/meta/classes/package_rpm.bbclass >>>> @@ -276,7 +276,6 @@ package_install_internal_rpm () { >>>> # Setup base system configuration >>>> echo "Note: configuring RPM platform settings" >>>> mkdir -p ${target_rootfs}/etc/rpm/ >>>> - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/platform >>> >>> I think this is wrong. The /etc/rpm/platform file's first line is supposed to >>> be the equivalent of: [uname -m]-vendor-os. While uname -m doesn't match our >>> tune namings, the concept is the same. The first line simply defines the "tune" >>> of the platform, subsequent lines define alternative names that will run on this >>> system. >>> >>> The INSTALL_PLATFORM_RPM value should be the expected value for the platform as >>> a whole, as it's the default tune value. (Default tune value is expected to be >>> the most accurate value. >>> >>> Looking at the defect: >>> >>> i586-poky-linux >>> emenlow-.*-linux >>> core2-.*-linux >>> i686-.*-linux >>> i586-.*-linux >>> i486-.*-linux >>> i386-.*-linux >>> x86-.*-linux >>> noarch-.*-linux.* >>> any-.*-linux.* >>> all-.*-linux.* >>> >>> The default tune value for that machine was set to i586 by "something". >>> >>> INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - _)${TARGET_VENDOR}-${TARGET_OS}" >>> >>> ${TARGET_ARCH} is similar to the output of uname -m. The error is that this >>> particular BSP should have returned 'core2' as the TARGET_ARCH from what I can tell. >>> >>> Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" >>> >>> So the TUNE_ARCH is being set to i586. So the end result is.. Is 'TUNE_ARCH' >>> set to i586 appropriate? It probably is, because the majority of the system >>> seems to have a limited set of expected values for TARGET_ARCH. >>> >>> So, perhaps the right fix is instead of using 'TARGET_ARCH' in >>> INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. >>> >>> I'd suggest trying that. (But the first line is the system architecture, >>> following lines are alternative packages that are considered compatible.) >> >> Forgot one thing. The first line must be fully expanded. Subsequent lines are >> regex matched by the system. > > We have a problem here since the machine specific packages are meant to > be preferred over the "tune" specific ones by definition of the way OE > has long since worked, the structure of the PACKAGE_ARCHS variable and > so on. > > As I understand it, this will not happen with this file setup in this > way. Ordering is defined by the lines -after- the first one.. the first line is defined as the system arch. The function rpmPlaform(...) in lib/rpmrc.c controls the loading of this data. The first time through is reads the first line and sets: _platform_cpu _platform_vendor _platform_os _platform_gnu The _platform items are used by the "_host_*" requivalent macros.. this defines the core system items. Subsequent lines are then loaded and added to the regex for 'supported' platforms/package archs. (The 'arch' field in a package is useless.. it's just a key but doesn't really mean anything in RPM 5. It's the 'platform' field embedded into the package that is actually used for compatibility.) The machine ordering SHOULD come from the 'platformScore' function (also in lib/rpmrc.c). That only uses the regex to figure out the proper 'score' for a component. (roughly matches the line number in the file) That being said, this stuff doesn't actually affect smart -directly-, it only affects it indirectly. When a package is selected by smart (which has it's own ordering tools) it verified compatibility using these components. For image generate, the package order is defined by us adding the places to look one at a time. The only place I've seen a similar problem is when someone moves all of the packages into a single directory and says 'here ya go'. I don't know how smart selects which packages to favor in that case. If someone could point that out, it may turn out it's a bug in smart -- or a problem we need to fix in another way. There is a python function 'archScore'. What this does is take the package arch passed into the function, add the vendor/os from the platform (first line). It then calls the rpmPlatformScore function to get a response. But the first of removing the first line is simply wrong. It has to be set to something that represents the system and is 'similar' to uname -m, as that value may be attempted to be passed into configure or other tools if someone uses 'rpmbuild' on their target. --Mark > Cheers, > > Richard > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-18 17:32 ` Mark Hatle @ 2013-04-19 12:18 ` Richard Purdie 0 siblings, 0 replies; 10+ messages in thread From: Richard Purdie @ 2013-04-19 12:18 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On Thu, 2013-04-18 at 12:32 -0500, Mark Hatle wrote: > On 4/18/13 11:59 AM, Richard Purdie wrote: > > On Thu, 2013-04-18 at 10:10 -0500, Mark Hatle wrote: > >> On 4/18/13 9:46 AM, Mark Hatle wrote: > >>> On 4/18/13 9:27 AM, Bogdan Marinescu wrote: > >>>> For some platforms (for example emenlow) the RPM installer prefers > >>>> an invalid package architecture (for example i586 over core2) because > >>>> /etc/rpm/platform is not properly generated (for example, i586 is > >>>> listed before core2 in /etc/rpm/platform). > >>>> > >>>> [YOCTO #3864] > >>>> > >>>> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> > >>>> --- > >>>> meta/classes/package_rpm.bbclass | 1 - > >>>> 1 file changed, 1 deletion(-) > >>>> > >>>> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass > >>>> index 3a29976..1bee4b1 100644 > >>>> --- a/meta/classes/package_rpm.bbclass > >>>> +++ b/meta/classes/package_rpm.bbclass > >>>> @@ -276,7 +276,6 @@ package_install_internal_rpm () { > >>>> # Setup base system configuration > >>>> echo "Note: configuring RPM platform settings" > >>>> mkdir -p ${target_rootfs}/etc/rpm/ > >>>> - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/platform > >>> > >>> I think this is wrong. The /etc/rpm/platform file's first line is supposed to > >>> be the equivalent of: [uname -m]-vendor-os. While uname -m doesn't match our > >>> tune namings, the concept is the same. The first line simply defines the "tune" > >>> of the platform, subsequent lines define alternative names that will run on this > >>> system. > >>> > >>> The INSTALL_PLATFORM_RPM value should be the expected value for the platform as > >>> a whole, as it's the default tune value. (Default tune value is expected to be > >>> the most accurate value. > >>> > >>> Looking at the defect: > >>> > >>> i586-poky-linux > >>> emenlow-.*-linux > >>> core2-.*-linux > >>> i686-.*-linux > >>> i586-.*-linux > >>> i486-.*-linux > >>> i386-.*-linux > >>> x86-.*-linux > >>> noarch-.*-linux.* > >>> any-.*-linux.* > >>> all-.*-linux.* > >>> > >>> The default tune value for that machine was set to i586 by "something". > >>> > >>> INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - _)${TARGET_VENDOR}-${TARGET_OS}" > >>> > >>> ${TARGET_ARCH} is similar to the output of uname -m. The error is that this > >>> particular BSP should have returned 'core2' as the TARGET_ARCH from what I can tell. > >>> > >>> Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" > >>> > >>> So the TUNE_ARCH is being set to i586. So the end result is.. Is 'TUNE_ARCH' > >>> set to i586 appropriate? It probably is, because the majority of the system > >>> seems to have a limited set of expected values for TARGET_ARCH. > >>> > >>> So, perhaps the right fix is instead of using 'TARGET_ARCH' in > >>> INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. > >>> > >>> I'd suggest trying that. (But the first line is the system architecture, > >>> following lines are alternative packages that are considered compatible.) > >> > >> Forgot one thing. The first line must be fully expanded. Subsequent lines are > >> regex matched by the system. > > > > We have a problem here since the machine specific packages are meant to > > be preferred over the "tune" specific ones by definition of the way OE > > has long since worked, the structure of the PACKAGE_ARCHS variable and > > so on. > > > > As I understand it, this will not happen with this file setup in this > > way. > > Ordering is defined by the lines -after- the first one.. the first line is > defined as the system arch. > > The function rpmPlaform(...) in lib/rpmrc.c controls the loading of this data. > > The first time through is reads the first line and sets: > > _platform_cpu > _platform_vendor > _platform_os > _platform_gnu > > The _platform items are used by the "_host_*" requivalent macros.. this defines > the core system items. > > Subsequent lines are then loaded and added to the regex for 'supported' > platforms/package archs. (The 'arch' field in a package is useless.. it's just > a key but doesn't really mean anything in RPM 5. It's the 'platform' field > embedded into the package that is actually used for compatibility.) > > The machine ordering SHOULD come from the 'platformScore' function (also in > lib/rpmrc.c). That only uses the regex to figure out the proper 'score' for a > component. (roughly matches the line number in the file) > > That being said, this stuff doesn't actually affect smart -directly-, it only > affects it indirectly. When a package is selected by smart (which has it's own > ordering tools) it verified compatibility using these components. > > For image generate, the package order is defined by us adding the places to look > one at a time. The only place I've seen a similar problem is when someone moves > all of the packages into a single directory and says 'here ya go'. I don't know > how smart selects which packages to favor in that case. If someone could point > that out, it may turn out it's a bug in smart -- or a problem we need to fix in > another way. > > There is a python function 'archScore'. What this does is take the package arch > passed into the function, add the vendor/os from the platform (first line). It > then calls the rpmPlatformScore function to get a response. > > But the first of removing the first line is simply wrong. It has to be set to > something that represents the system and is 'similar' to uname -m, as that value > may be attempted to be passed into configure or other tools if someone uses > 'rpmbuild' on their target. Ok, if rpm is using the first line as the thing you'd pass to configure, then it is correct as it stands right now. However it should not be getting used by smart, or rpm as a "feed" preference. We need to find out why its doing that and stop it as it *must* honour the lower list to match how we construct the rootfs. All the evidence is that it is using that first line and hence things are breaking. Cheers, Richard ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-18 14:46 ` Mark Hatle 2013-04-18 15:10 ` Mark Hatle @ 2013-04-22 12:00 ` Marinescu, Bogdan A 2013-04-22 14:34 ` Marinescu, Bogdan A 1 sibling, 1 reply; 10+ messages in thread From: Marinescu, Bogdan A @ 2013-04-22 12:00 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3662 bytes --] On Thu, Apr 18, 2013 at 5:46 PM, Mark Hatle <mark.hatle@windriver.com>wrote: > On 4/18/13 9:27 AM, Bogdan Marinescu wrote: > >> For some platforms (for example emenlow) the RPM installer prefers >> an invalid package architecture (for example i586 over core2) because >> /etc/rpm/platform is not properly generated (for example, i586 is >> listed before core2 in /etc/rpm/platform). >> >> [YOCTO #3864] >> >> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> >> --- >> meta/classes/package_rpm.**bbclass | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/meta/classes/package_rpm.**bbclass >> b/meta/classes/package_rpm.**bbclass >> index 3a29976..1bee4b1 100644 >> --- a/meta/classes/package_rpm.**bbclass >> +++ b/meta/classes/package_rpm.**bbclass >> @@ -276,7 +276,6 @@ package_install_internal_rpm () { >> # Setup base system configuration >> echo "Note: configuring RPM platform settings" >> mkdir -p ${target_rootfs}/etc/rpm/ >> - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/* >> *platform >> > > I think this is wrong. The /etc/rpm/platform file's first line is > supposed to be the equivalent of: [uname -m]-vendor-os. While uname -m > doesn't match our tune namings, the concept is the same. The first line > simply defines the "tune" of the platform, subsequent lines define > alternative names that will run on this system. > > The INSTALL_PLATFORM_RPM value should be the expected value for the > platform as a whole, as it's the default tune value. (Default tune value > is expected to be the most accurate value. > > Looking at the defect: > > i586-poky-linux > emenlow-.*-linux > core2-.*-linux > i686-.*-linux > i586-.*-linux > i486-.*-linux > i386-.*-linux > x86-.*-linux > noarch-.*-linux.* > any-.*-linux.* > all-.*-linux.* > > The default tune value for that machine was set to i586 by "something". > > INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - > _)${TARGET_VENDOR}-${TARGET_**OS}" > > ${TARGET_ARCH} is similar to the output of uname -m. The error is that > this particular BSP should have returned 'core2' as the TARGET_ARCH from > what I can tell. > > Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" > > So the TUNE_ARCH is being set to i586. So the end result is.. Is > 'TUNE_ARCH' set to i586 appropriate? It probably is, because the majority > of the system seems to have a limited set of expected values for > TARGET_ARCH. > > So, perhaps the right fix is instead of using 'TARGET_ARCH' in > INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. > > I'd suggest trying that. (But the first line is the system architecture, > following lines are alternative packages that are considered compatible.) > > > >> if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then >> for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do >> >> > On my qemux86 image, /etc/rpm/platform looks like this: qemux86-.*-linux i586-.*-linux i486-.*-linux i386-.*-linux x86-.*-linux noarch-.*-linux.* any-.*-linux.* all-.*-linux.* The first line is not fully expanded and smart seems to make the correct choice of packages in this case. Thanks, Bogdan > > ______________________________**_________________ > Openembedded-core mailing list > Openembedded-core@lists.**openembedded.org<Openembedded-core@lists.openembedded.org> > http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core> > [-- Attachment #2: Type: text/html, Size: 5241 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-22 12:00 ` Marinescu, Bogdan A @ 2013-04-22 14:34 ` Marinescu, Bogdan A 2013-04-23 10:11 ` Marinescu, Bogdan A 0 siblings, 1 reply; 10+ messages in thread From: Marinescu, Bogdan A @ 2013-04-22 14:34 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 4701 bytes --] Further investigation reveals the fact that the problem is connected to the value returned by "rpm.archscore", which changes with the value of the first line of /etc/rpm/platform. I'm testing under qemux86 and editing /etc/rpm/platform by hand. I've traced the code to backends/rpm/base.py which contains the function getArchScore (which basically calls rpm.archscore). With this /etc/rpm/platform: i586-poky-linux core2-.*-linux qemux86-.*-linux i586-.*-linux ....... I get a score of 2 for arch core2 and 1 for i586. If I remove the first line (i586-poky-linux) and rerun smart without chaning anything else, I get a score of 1 for arch core2 and a score of 3 for i586. So that line definiteley matters, which should be a bug, if I understood Mark's e-mails correctly. Thanks, Bogdan On Mon, Apr 22, 2013 at 3:00 PM, Marinescu, Bogdan A < bogdan.a.marinescu@intel.com> wrote: > On Thu, Apr 18, 2013 at 5:46 PM, Mark Hatle <mark.hatle@windriver.com>wrote: > >> On 4/18/13 9:27 AM, Bogdan Marinescu wrote: >> >>> For some platforms (for example emenlow) the RPM installer prefers >>> an invalid package architecture (for example i586 over core2) because >>> /etc/rpm/platform is not properly generated (for example, i586 is >>> listed before core2 in /etc/rpm/platform). >>> >>> [YOCTO #3864] >>> >>> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> >>> --- >>> meta/classes/package_rpm.**bbclass | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/meta/classes/package_rpm.**bbclass >>> b/meta/classes/package_rpm.**bbclass >>> index 3a29976..1bee4b1 100644 >>> --- a/meta/classes/package_rpm.**bbclass >>> +++ b/meta/classes/package_rpm.**bbclass >>> @@ -276,7 +276,6 @@ package_install_internal_rpm () { >>> # Setup base system configuration >>> echo "Note: configuring RPM platform settings" >>> mkdir -p ${target_rootfs}/etc/rpm/ >>> - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/ >>> **platform >>> >> >> I think this is wrong. The /etc/rpm/platform file's first line is >> supposed to be the equivalent of: [uname -m]-vendor-os. While uname -m >> doesn't match our tune namings, the concept is the same. The first line >> simply defines the "tune" of the platform, subsequent lines define >> alternative names that will run on this system. >> >> The INSTALL_PLATFORM_RPM value should be the expected value for the >> platform as a whole, as it's the default tune value. (Default tune value >> is expected to be the most accurate value. >> >> Looking at the defect: >> >> i586-poky-linux >> emenlow-.*-linux >> core2-.*-linux >> i686-.*-linux >> i586-.*-linux >> i486-.*-linux >> i386-.*-linux >> x86-.*-linux >> noarch-.*-linux.* >> any-.*-linux.* >> all-.*-linux.* >> >> The default tune value for that machine was set to i586 by "something". >> >> INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - >> _)${TARGET_VENDOR}-${TARGET_**OS}" >> >> ${TARGET_ARCH} is similar to the output of uname -m. The error is that >> this particular BSP should have returned 'core2' as the TARGET_ARCH from >> what I can tell. >> >> Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" >> >> So the TUNE_ARCH is being set to i586. So the end result is.. Is >> 'TUNE_ARCH' set to i586 appropriate? It probably is, because the majority >> of the system seems to have a limited set of expected values for >> TARGET_ARCH. >> >> So, perhaps the right fix is instead of using 'TARGET_ARCH' in >> INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. >> >> I'd suggest trying that. (But the first line is the system architecture, >> following lines are alternative packages that are considered compatible.) >> >> >> >>> if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then >>> for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do >>> >>> >> > On my qemux86 image, /etc/rpm/platform looks like this: > > qemux86-.*-linux > i586-.*-linux > i486-.*-linux > i386-.*-linux > x86-.*-linux > noarch-.*-linux.* > any-.*-linux.* > all-.*-linux.* > > The first line is not fully expanded and smart seems to make the correct > choice of packages in this case. > > Thanks, > Bogdan > > >> >> ______________________________**_________________ >> Openembedded-core mailing list >> Openembedded-core@lists.**openembedded.org<Openembedded-core@lists.openembedded.org> >> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core> >> > > [-- Attachment #2: Type: text/html, Size: 6656 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-22 14:34 ` Marinescu, Bogdan A @ 2013-04-23 10:11 ` Marinescu, Bogdan A 2013-04-23 13:35 ` Marinescu, Bogdan A 0 siblings, 1 reply; 10+ messages in thread From: Marinescu, Bogdan A @ 2013-04-23 10:11 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Mark Hatle [-- Attachment #1: Type: text/plain, Size: 5689 bytes --] I've investigated this issue further. /etc/rpm/platform is parsed in rpmrc.c/rpmPlatform. It is true that the first line of /etc/rpm/platform does not get added directly to the platform list, being passed to parseCVOG instead, but after parserCVOG ends, it is added to the platform list anyway, although indirectly (mireAppend with the result of rpmExpand). After that, it stays in the platform list and it matched on subsequent calls to rpmPlatformScore, so it definitely has an impact on the way smart chooses the platform for a package. So, with all this in mind, where is the bug here? Is it in the RPM library or we really should not add that first line to the /etc/rpm/platform file? Thanks, Bogdan On Mon, Apr 22, 2013 at 5:34 PM, Marinescu, Bogdan A < bogdan.a.marinescu@intel.com> wrote: > Further investigation reveals the fact that the problem is connected to > the value returned by "rpm.archscore", which changes with the value of the > first line of /etc/rpm/platform. I'm testing under qemux86 and editing > /etc/rpm/platform by hand. I've traced the code to backends/rpm/base.py > which contains the function getArchScore (which basically calls > rpm.archscore). With this /etc/rpm/platform: > > i586-poky-linux > core2-.*-linux > qemux86-.*-linux > i586-.*-linux > ....... > > I get a score of 2 for arch core2 and 1 for i586. If I remove the first > line (i586-poky-linux) and rerun smart without chaning anything else, I get > a score of 1 for arch core2 and a score of 3 for i586. So that line > definiteley matters, which should be a bug, if I understood Mark's e-mails > correctly. > > Thanks, > Bogdan > > > > On Mon, Apr 22, 2013 at 3:00 PM, Marinescu, Bogdan A < > bogdan.a.marinescu@intel.com> wrote: > >> On Thu, Apr 18, 2013 at 5:46 PM, Mark Hatle <mark.hatle@windriver.com>wrote: >> >>> On 4/18/13 9:27 AM, Bogdan Marinescu wrote: >>> >>>> For some platforms (for example emenlow) the RPM installer prefers >>>> an invalid package architecture (for example i586 over core2) because >>>> /etc/rpm/platform is not properly generated (for example, i586 is >>>> listed before core2 in /etc/rpm/platform). >>>> >>>> [YOCTO #3864] >>>> >>>> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> >>>> --- >>>> meta/classes/package_rpm.**bbclass | 1 - >>>> 1 file changed, 1 deletion(-) >>>> >>>> diff --git a/meta/classes/package_rpm.**bbclass >>>> b/meta/classes/package_rpm.**bbclass >>>> index 3a29976..1bee4b1 100644 >>>> --- a/meta/classes/package_rpm.**bbclass >>>> +++ b/meta/classes/package_rpm.**bbclass >>>> @@ -276,7 +276,6 @@ package_install_internal_rpm () { >>>> # Setup base system configuration >>>> echo "Note: configuring RPM platform settings" >>>> mkdir -p ${target_rootfs}/etc/rpm/ >>>> - echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/ >>>> **platform >>>> >>> >>> I think this is wrong. The /etc/rpm/platform file's first line is >>> supposed to be the equivalent of: [uname -m]-vendor-os. While uname -m >>> doesn't match our tune namings, the concept is the same. The first line >>> simply defines the "tune" of the platform, subsequent lines define >>> alternative names that will run on this system. >>> >>> The INSTALL_PLATFORM_RPM value should be the expected value for the >>> platform as a whole, as it's the default tune value. (Default tune value >>> is expected to be the most accurate value. >>> >>> Looking at the defect: >>> >>> i586-poky-linux >>> emenlow-.*-linux >>> core2-.*-linux >>> i686-.*-linux >>> i586-.*-linux >>> i486-.*-linux >>> i386-.*-linux >>> x86-.*-linux >>> noarch-.*-linux.* >>> any-.*-linux.* >>> all-.*-linux.* >>> >>> The default tune value for that machine was set to i586 by "something". >>> >>> INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - >>> _)${TARGET_VENDOR}-${TARGET_**OS}" >>> >>> ${TARGET_ARCH} is similar to the output of uname -m. The error is that >>> this particular BSP should have returned 'core2' as the TARGET_ARCH from >>> what I can tell. >>> >>> Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" >>> >>> So the TUNE_ARCH is being set to i586. So the end result is.. Is >>> 'TUNE_ARCH' set to i586 appropriate? It probably is, because the majority >>> of the system seems to have a limited set of expected values for >>> TARGET_ARCH. >>> >>> So, perhaps the right fix is instead of using 'TARGET_ARCH' in >>> INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. >>> >>> I'd suggest trying that. (But the first line is the system >>> architecture, following lines are alternative packages that are considered >>> compatible.) >>> >>> >>> >>>> if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then >>>> for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do >>>> >>>> >>> >> On my qemux86 image, /etc/rpm/platform looks like this: >> >> qemux86-.*-linux >> i586-.*-linux >> i486-.*-linux >> i386-.*-linux >> x86-.*-linux >> noarch-.*-linux.* >> any-.*-linux.* >> all-.*-linux.* >> >> The first line is not fully expanded and smart seems to make the correct >> choice of packages in this case. >> >> Thanks, >> Bogdan >> >> >>> >>> ______________________________**_________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.**openembedded.org<Openembedded-core@lists.openembedded.org> >>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/** >>> openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core> >>> >> >> > [-- Attachment #2: Type: text/html, Size: 7820 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation 2013-04-23 10:11 ` Marinescu, Bogdan A @ 2013-04-23 13:35 ` Marinescu, Bogdan A 0 siblings, 0 replies; 10+ messages in thread From: Marinescu, Bogdan A @ 2013-04-23 13:35 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Mark Hatle [-- Attachment #1: Type: text/plain, Size: 6113 bytes --] I've sent another patch that attempts to fix the same bug in a different way ('rpm: change arch scoring items'). Please review it. Thanks, Bogdan On Tue, Apr 23, 2013 at 1:11 PM, Marinescu, Bogdan A < bogdan.a.marinescu@intel.com> wrote: > I've investigated this issue further. /etc/rpm/platform is parsed in > rpmrc.c/rpmPlatform. It is true that the first line of /etc/rpm/platform > does not get added directly to the platform list, being passed to parseCVOG > instead, but after parserCVOG ends, it is added to the platform list > anyway, although indirectly (mireAppend with the result of rpmExpand). > After that, it stays in the platform list and it matched on subsequent > calls to rpmPlatformScore, so it definitely has an impact on the way smart > chooses the platform for a package. So, with all this in mind, where is the > bug here? Is it in the RPM library or we really should not add that first > line to the /etc/rpm/platform file? > > Thanks, > Bogdan > > > On Mon, Apr 22, 2013 at 5:34 PM, Marinescu, Bogdan A < > bogdan.a.marinescu@intel.com> wrote: > >> Further investigation reveals the fact that the problem is connected to >> the value returned by "rpm.archscore", which changes with the value of the >> first line of /etc/rpm/platform. I'm testing under qemux86 and editing >> /etc/rpm/platform by hand. I've traced the code to backends/rpm/base.py >> which contains the function getArchScore (which basically calls >> rpm.archscore). With this /etc/rpm/platform: >> >> i586-poky-linux >> core2-.*-linux >> qemux86-.*-linux >> i586-.*-linux >> ....... >> >> I get a score of 2 for arch core2 and 1 for i586. If I remove the first >> line (i586-poky-linux) and rerun smart without chaning anything else, I get >> a score of 1 for arch core2 and a score of 3 for i586. So that line >> definiteley matters, which should be a bug, if I understood Mark's e-mails >> correctly. >> >> Thanks, >> Bogdan >> >> >> >> On Mon, Apr 22, 2013 at 3:00 PM, Marinescu, Bogdan A < >> bogdan.a.marinescu@intel.com> wrote: >> >>> On Thu, Apr 18, 2013 at 5:46 PM, Mark Hatle <mark.hatle@windriver.com>wrote: >>> >>>> On 4/18/13 9:27 AM, Bogdan Marinescu wrote: >>>> >>>>> For some platforms (for example emenlow) the RPM installer prefers >>>>> an invalid package architecture (for example i586 over core2) because >>>>> /etc/rpm/platform is not properly generated (for example, i586 is >>>>> listed before core2 in /etc/rpm/platform). >>>>> >>>>> [YOCTO #3864] >>>>> >>>>> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> >>>>> --- >>>>> meta/classes/package_rpm.**bbclass | 1 - >>>>> 1 file changed, 1 deletion(-) >>>>> >>>>> diff --git a/meta/classes/package_rpm.**bbclass >>>>> b/meta/classes/package_rpm.**bbclass >>>>> index 3a29976..1bee4b1 100644 >>>>> --- a/meta/classes/package_rpm.**bbclass >>>>> +++ b/meta/classes/package_rpm.**bbclass >>>>> @@ -276,7 +276,6 @@ package_install_internal_rpm () { >>>>> # Setup base system configuration >>>>> echo "Note: configuring RPM platform settings" >>>>> mkdir -p ${target_rootfs}/etc/rpm/ >>>>> - echo "$INSTALL_PLATFORM_RPM" > >>>>> ${target_rootfs}/etc/rpm/**platform >>>>> >>>> >>>> I think this is wrong. The /etc/rpm/platform file's first line is >>>> supposed to be the equivalent of: [uname -m]-vendor-os. While uname -m >>>> doesn't match our tune namings, the concept is the same. The first line >>>> simply defines the "tune" of the platform, subsequent lines define >>>> alternative names that will run on this system. >>>> >>>> The INSTALL_PLATFORM_RPM value should be the expected value for the >>>> platform as a whole, as it's the default tune value. (Default tune value >>>> is expected to be the most accurate value. >>>> >>>> Looking at the defect: >>>> >>>> i586-poky-linux >>>> emenlow-.*-linux >>>> core2-.*-linux >>>> i686-.*-linux >>>> i586-.*-linux >>>> i486-.*-linux >>>> i386-.*-linux >>>> x86-.*-linux >>>> noarch-.*-linux.* >>>> any-.*-linux.* >>>> all-.*-linux.* >>>> >>>> The default tune value for that machine was set to i586 by "something". >>>> >>>> INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr - >>>> _)${TARGET_VENDOR}-${TARGET_**OS}" >>>> >>>> ${TARGET_ARCH} is similar to the output of uname -m. The error is that >>>> this particular BSP should have returned 'core2' as the TARGET_ARCH from >>>> what I can tell. >>>> >>>> Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}" >>>> >>>> So the TUNE_ARCH is being set to i586. So the end result is.. Is >>>> 'TUNE_ARCH' set to i586 appropriate? It probably is, because the majority >>>> of the system seems to have a limited set of expected values for >>>> TARGET_ARCH. >>>> >>>> So, perhaps the right fix is instead of using 'TARGET_ARCH' in >>>> INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate. >>>> >>>> I'd suggest trying that. (But the first line is the system >>>> architecture, following lines are alternative packages that are considered >>>> compatible.) >>>> >>>> >>>> >>>>> if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then >>>>> for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do >>>>> >>>>> >>>> >>> On my qemux86 image, /etc/rpm/platform looks like this: >>> >>> qemux86-.*-linux >>> i586-.*-linux >>> i486-.*-linux >>> i386-.*-linux >>> x86-.*-linux >>> noarch-.*-linux.* >>> any-.*-linux.* >>> all-.*-linux.* >>> >>> The first line is not fully expanded and smart seems to make the correct >>> choice of packages in this case. >>> >>> Thanks, >>> Bogdan >>> >>> >>>> >>>> ______________________________**_________________ >>>> Openembedded-core mailing list >>>> Openembedded-core@lists.**openembedded.org<Openembedded-core@lists.openembedded.org> >>>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/** >>>> openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core> >>>> >>> >>> >> > [-- Attachment #2: Type: text/html, Size: 8463 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-04-23 13:53 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-04-18 14:27 [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation Bogdan Marinescu 2013-04-18 14:46 ` Mark Hatle 2013-04-18 15:10 ` Mark Hatle 2013-04-18 16:59 ` Richard Purdie 2013-04-18 17:32 ` Mark Hatle 2013-04-19 12:18 ` Richard Purdie 2013-04-22 12:00 ` Marinescu, Bogdan A 2013-04-22 14:34 ` Marinescu, Bogdan A 2013-04-23 10:11 ` Marinescu, Bogdan A 2013-04-23 13:35 ` Marinescu, Bogdan A
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox