Skip to contentSkip to conversation

Updates, Multilib Patches and other fixes

GIT PULL Saul Wold 6 participants 16 messages Jan 5, 2013 – Jan 9, 2013

lore
Share & tools
lore

Saul Wold

author
#0 lore raw

Richard,

Finally another collected set of patches, my network access was worse than I thought it would be the last few days.

I built these locally.

Thanks
Sau!

The following changes since commit b693f6d3d48b281fbbf71fd56996c85e23c3a9c9:

freetype: update to 2.4.11 which includes fixes for CVE-2012-{5668, 5669, 5670} (2012-12-31 09:42:49 +0000)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage

Chen Qi (1):
init-live.sh: avoid duplicate mount points for the same filesystem

Christopher Larson (6):
update-alternatives.bbclass: use absolute paths for link targets
opkg-native: obey virtual/update-alternatives-native
chkconfig: don't inherit autotools
chkconfig: obey sysconfdir, base_libdir
chkconfig: package the update-alternatives implementation chkconfig-alternatives-native-1.3.59: add recipe

Constantin Musca (8):
libpam: enable multilib
package.bbclass: don't prepend MLPREFIX to LOCALEBASEPN
eglibc-locale: enable multilib
sysstat: fix sa_lib_dir
rpm: replace /usr/lib with ${libdir}
libfm: upgrade to 1.1.0
pcmanfm: upgrade to 1.1.0
vte: add missing unpackaged files

David Nyström (1):
Added ability to parse python sources to create-recipe

Kang Kai (4):
autoconf: update RDEDENDS
perl: add sub-package perl-tests
perl: update RPROVIDES and popuate_package script
perl: update dependency creating script

Laurentiu Palcu (1):
pango: have postinstalls run at do_rootfs time

Marko Lindqvist (7):
automake: update to upstream version 1.12.6
gmp: update SRC_URI and HOMEPAGE
gmp: update to upstream version 5.1.0
mpfr: update to upstream version 3.1.1
icu: update to upstream version 50.1.1
harfbuzz: add recipe, version 0.9.9
pango: update to upstream version 1.32.5

Martin Jansa (1):
kernel.bbclass: include PE in KERNEL_IMAGE_BASE_NAME

Noor Ahsan (1):
cairo: Adds libxext in X11DEPENDS.

Robert P. J. Day (2):
lib_package.bbclass: Correct comment referring to bin directories. package.bbclass: Skip testing "packages" a second time.

Saul Wold (3):
libnl: Update to 3.2.16
glib-2.0: Update to 2.35.3
glib-networking: Update to 2.35.1

 meta/classes/kernel.bbclass                        |    2 +-
 meta/classes/lib_package.bbclass                   |    2 +-
 meta/classes/package.bbclass                       |    4 +-
 meta/classes/update-alternatives.bbclass           |    2 +-
 meta/recipes-core/eglibc/eglibc-locale.inc         |    4 +-
 .../{glib-2.0_2.34.3.bb => glib-2.0_2.35.3.bb}     |    4 +-
 meta/recipes-core/glib-2.0/glib.inc                |    2 +-
 ...working_2.28.7.bb => glib-networking_2.35.1.bb} |   10 +-
 meta/recipes-core/initrdscripts/files/init-live.sh |    9 +-
 meta/recipes-devtools/autoconf/autoconf.inc        |    1 -
 meta/recipes-devtools/autoconf/autoconf_2.69.bb    |    2 +-
 ...-compile-compile-only-optimized-byte-code.patch |   28 +-
 .../automake/automake/python-libdir.patch          |   41 +-
 .../{automake_1.12.5.bb => automake_1.12.6.bb}     |    4 +-
 meta/recipes-devtools/opkg/opkg.inc                |   10 +-
 meta/recipes-devtools/perl/perl-5.14.2/config.sh   |   18 +-
 .../recipes-devtools/perl/perl-rdepends_5.14.2.inc | 2336 +++++++++++++++++++-
 meta/recipes-devtools/perl/perl-tests.inc          |   34 +
 meta/recipes-devtools/perl/perl_5.14.2.bb          |   12 +-
 meta/recipes-devtools/rpm/rpm_5.4.9.bb             |    4 +-
 .../chkconfig-alternatives-native_1.3.59.bb        |   43 +
 .../recipes-extended/chkconfig/chkconfig_1.3.58.bb |   48 +-
 meta/recipes-extended/pam/libpam_1.1.6.bb          |   15 +-
 meta/recipes-extended/sysstat/sysstat.inc          |    6 +-
 meta/recipes-graphics/cairo/cairo.inc              |    2 +-
 meta/recipes-graphics/cairo/cairo_1.12.8.bb        |    2 +-
 meta/recipes-graphics/harfbuzz/harfbuzz_0.9.9.bb   |   27 +
 .../pango/pango-1.30.1/multilib-fix-clean.patch    |   42 -
 .../pango/pango-1.32.5/multilib-fix-clean.patch    |   60 +
 .../{pango-1.30.1 => pango-1.32.5}/no-tests.patch  |    0
 meta/recipes-graphics/pango/pango.inc              |   30 +-
 .../pango/{pango_1.30.1.bb => pango_1.32.5.bb}     |    4 +-
 .../pcmanfm/files/owl-window-menu.patch            |   81 -
 .../files/pcmanfm_fix_for_automake_1.12.patch      |   35 -
 .../{pcmanfm_0.9.10.bb => pcmanfm_1.1.0.bb}        |   11 +-
 .../gmp/{gmp => gmp-4.2.1}/configure.patch         |    0
 meta/recipes-support/gmp/gmp-5.1.0/configure.patch |  210 ++
 meta/recipes-support/gmp/gmp.inc                   |    4 +-
 .../gmp/gmp/gmp_fix_for_automake-1.12.patch        |   48 -
 .../gmp/{gmp_5.0.5.bb => gmp_5.1.0.bb}             |    5 +-
 meta/recipes-support/icu/icu_50.1.1.bb             |   11 +
 meta/recipes-support/icu/icu_50.1.bb               |   11 -
 .../libfm/libfm-0.1.17/configure_fix.patch         |   19 -
 .../libfm-0.1.17/libfm_fix_for_automake-1.12.patch |   48 -
 .../libfm-1.1.0/fix-make-parallelism-issue.patch   |   31 +
 .../libfm/{libfm_0.1.17.bb => libfm_1.1.0.bb}      |    8 +-
 .../libnl/{libnl_3.2.14.bb => libnl_3.2.16.bb}     |    4 +-
 .../mpfr-3.1.0/mpfr_fix_for_automake-1.12.patch    |   35 -
 .../long-long-thumb.patch                          |    0
 .../mpfr/{mpfr_3.1.0.bb => mpfr_3.1.1.bb}          |    7 +-
 meta/recipes-support/vte/vte.inc                   |    4 +-
 scripts/create-recipe                              |   51 +-
 52 files changed, 2944 insertions(+), 487 deletions(-)
 rename meta/recipes-core/glib-2.0/{glib-2.0_2.34.3.bb => glib-2.0_2.35.3.bb} (92%)
 rename meta/recipes-core/glib-networking/{glib-networking_2.28.7.bb => glib-networking_2.35.1.bb} (70%)
 rename meta/recipes-devtools/automake/{automake_1.12.5.bb => automake_1.12.6.bb} (90%)
 create mode 100644 meta/recipes-devtools/perl/perl-tests.inc
 create mode 100644 meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb
 create mode 100644 meta/recipes-graphics/harfbuzz/harfbuzz_0.9.9.bb
 delete mode 100644 meta/recipes-graphics/pango/pango-1.30.1/multilib-fix-clean.patch
 create mode 100644 meta/recipes-graphics/pango/pango-1.32.5/multilib-fix-clean.patch
 rename meta/recipes-graphics/pango/{pango-1.30.1 => pango-1.32.5}/no-tests.patch (100%)
 rename meta/recipes-graphics/pango/{pango_1.30.1.bb => pango_1.32.5.bb} (59%)
 delete mode 100644 meta/recipes-sato/pcmanfm/files/owl-window-menu.patch
 delete mode 100644 meta/recipes-sato/pcmanfm/files/pcmanfm_fix_for_automake_1.12.patch
 rename meta/recipes-sato/pcmanfm/{pcmanfm_0.9.10.bb => pcmanfm_1.1.0.bb} (76%)
 rename meta/recipes-support/gmp/{gmp => gmp-4.2.1}/configure.patch (100%)
 create mode 100644 meta/recipes-support/gmp/gmp-5.1.0/configure.patch
 delete mode 100644 meta/recipes-support/gmp/gmp/gmp_fix_for_automake-1.12.patch
 rename meta/recipes-support/gmp/{gmp_5.0.5.bb => gmp_5.1.0.bb} (60%)
 create mode 100644 meta/recipes-support/icu/icu_50.1.1.bb
 delete mode 100644 meta/recipes-support/icu/icu_50.1.bb
 delete mode 100644 meta/recipes-support/libfm/libfm-0.1.17/configure_fix.patch
 delete mode 100644 meta/recipes-support/libfm/libfm-0.1.17/libfm_fix_for_automake-1.12.patch
 create mode 100644 meta/recipes-support/libfm/libfm-1.1.0/fix-make-parallelism-issue.patch
 rename meta/recipes-support/libfm/{libfm_0.1.17.bb => libfm_1.1.0.bb} (75%)
 rename meta/recipes-support/libnl/{libnl_3.2.14.bb => libnl_3.2.16.bb} (90%)
 delete mode 100644 meta/recipes-support/mpfr/mpfr-3.1.0/mpfr_fix_for_automake-1.12.patch
 rename meta/recipes-support/mpfr/{mpfr-3.1.0 => mpfr-3.1.1}/long-long-thumb.patch (100%)
 rename meta/recipes-support/mpfr/{mpfr_3.1.0.bb => mpfr_3.1.1.bb} (65%)
Signature · 1 line
1.8.0.2
#1 lore raw
Quoted 3 lines · Saul Wold

Saul Wold (3):
glib-2.0: Update to 2.35.3

Is there some specific need for bleeding edge (unstable development snapshot)?

- ML

author
#2 lore raw
Quoted 7 lines · Marko Lindqvist
Quoted 3 lines · Saul Wold

Saul Wold (3):

   glib-2.0: Update to 2.35.3

Is there some specific need for bleeding edge (unstable development snapshot)?

I was updating glib-networking and it required glib 2.35.3, I had not checked (my bad that it was unstable). Even after a number of years, I loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)

We can drop both the glib and glib-networking patches.

Sau!

Quoted 4 lines

- ML

#3 lore raw
Quoted 9 lines · Saul Wold
Quoted 8 lines · Marko Lindqvist
Quoted 4 lines · Saul Wold

Saul Wold (3):

   glib-2.0: Update to 2.35.3
Quoted 6 lines
Quoted 3 lines

Is there some specific need for bleeding edge (unstable development
snapshot)?

I was updating glib-networking and it required glib 2.35.3, I had not checked (my bad that it was unstable). Even after a number of years, I loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)

With gnome way of releasing stable versions of something depending on
something that is not yet really released (has not stable release) it can be even quite frustrating. So you already have patch for glib-networking we can apply once glib is updated to 2.36.

Another challenge for http://packages.yoctoproject.org/ ?

- ML

#4 lore raw
Quoted 6 lines · Marko Lindqvist
Quoted 3 lines · Saul Wold
Quoted 1 line

Even after a number of years, I
loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)

Another challenge for http://packages.yoctoproject.org/ ?

Actually, does it even know how new major versions will be in new
directory? Asking because I don't know even if it collects the URL to check from recipes, or is that given in some specfile. At least gtk+3 recipe in meta-openembedded has that directory hardcoded ".../gtk+/3.4/gtk+-${PV}.tar.xz" so when ever updating to new major version, SRC_URI needs to be touched.
What I'm envisioning is that maybe bitbake should provide us with new
variable PM or PMV (major version) that's basically PV with last dot and everything after it removed. That would allow us to easily make many such SRC_URIs dynamic, e.g., ".../gtk+/${PM}/gtk+-${PV}.tar.xz". This would be more worthsome if it's something packages.yoctoproject.org too could benefit from.

- ML

#5 lore raw
Quoted 8 lines · Marko Lindqvist
Quoted 6 lines · Marko Lindqvist
Quoted 3 lines · Saul Wold
Quoted 1 line

Even after a number of years, I
loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)

Another challenge for http://packages.yoctoproject.org/ ?

Quoted 12 lines

Actually, does it even know how new major versions will be in new
directory? Asking because I don't know even if it collects the URL to check from recipes, or is that given in some specfile. At least gtk+3 recipe in meta-openembedded has that directory hardcoded ".../gtk+/3.4/gtk+-${PV}.tar.xz" so when ever updating to new major version, SRC_URI needs to be touched.
What I'm envisioning is that maybe bitbake should provide us with new
variable PM or PMV (major version) that's basically PV with last dot and everything after it removed. That would allow us to easily make many such SRC_URIs dynamic, e.g., ".../gtk+/${PM}/gtk+-${PV}.tar.xz". This would be more worthsome if it's something packages.yoctoproject.org too could benefit from.

That looks like SHRT_VER used in some recipes.

Cheers,

Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
#6 lore raw
Quoted 9 lines · Martin Jansa
Quoted 6 lines · Marko Lindqvist

What I'm envisioning is that maybe bitbake should provide us with new
variable PM or PMV (major version) that's basically PV with last dot and everything after it removed. That would allow us to easily make many such SRC_URIs dynamic, e.g., ".../gtk+/${PM}/gtk+-${PV}.tar.xz". This would be more worthsome if it's something packages.yoctoproject.org too could benefit from.

That looks like SHRT_VER used in some recipes.

Exactly, except that it would be provided by bitbake, and not
constructed by each recipe itself - less recipe writing work + you could count on it to always mean same thing.

- ML

#7 lore raw
Quoted 3 lines · Marko Lindqvist

Exactly, except that it would be provided by bitbake, and not constructed by each recipe itself - less recipe writing work + you could count on it to always mean same thing.

Everything but the last dot, or the first two components, or what? For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).

Ross

#8 lore raw
Quoted 6 lines · Ross Burton
Quoted 3 lines · Marko Lindqvist

Exactly, except that it would be provided by bitbake, and not constructed by each recipe itself - less recipe writing work + you could count on it to always mean same thing.

Everything but the last dot, or the first two components, or what? For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).

Ok, do we have any counter-examples where you'd want, say, three out
of four parts? One out of n? Of course there will always be need to use variables of their own in some recipes, but I'm after something that would be usable in most cases.

- ML

#9 lore raw
Quoted 6 lines · Marko Lindqvist
Quoted 5 lines · Ross Burton
Quoted 3 lines · Marko Lindqvist

Exactly, except that it would be provided by bitbake, and not constructed by each recipe itself - less recipe writing work + you could count on it to always mean same thing.

Quoted 6 lines
Quoted 1 line

Everything but the last dot, or the first two components, or what? For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).

Ok, do we have any counter-examples where you'd want, say, three out
of four parts? One out of n? Of course there will always be need to use variables of their own in some recipes, but I'm after something that would be usable in most cases.

I don't remember where but 1st of 4 is also used.
What about stuff like "1.2.3.4+gitAUTOINC"?

GNOME is quite consistent, but it still looks better defined in recipe/bbclass then having "something" defined by bitbake in all recipes and usable only in some.

Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
#10 lore raw
Quoted 14 lines · Martin Jansa
Quoted 6 lines · Marko Lindqvist
Quoted 5 lines · Ross Burton
Quoted 3 lines · Marko Lindqvist

Exactly, except that it would be provided by bitbake, and not constructed by each recipe itself - less recipe writing work + you could count on it to always mean same thing.

Quoted 6 lines
Quoted 1 line

Everything but the last dot, or the first two components, or what? For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).

Ok, do we have any counter-examples where you'd want, say, three out
of four parts? One out of n? Of course there will always be need to use variables of their own in some recipes, but I'm after something that would be usable in most cases.

Quoted 6 lines

I don't remember where but 1st of 4 is also used.
What about stuff like "1.2.3.4+gitAUTOINC"?

GNOME is quite consistent, but it still looks better defined in recipe/bbclass then having "something" defined by bitbake in all recipes and usable only in some.

Given the examples, yes. Only if external tools would benefit (=
could use bitbake defined, but not recipe constructed var), defining it bitbake side would make sense.

- ML

#11 lore raw
In reply to Saul Wold
Quoted 2 lines · Saul Wold

harfbuzz: add recipe, version 0.9.9
pango: update to upstream version 1.32.5

Is it either all or none going forward with these consolidated pulls?
I'm about to submit V2 of HarfBuzz patch fixing build occasionally being unusable for pango (namely I will add glib-2.0 to dependencies, as without glib present harfbuzz configure disables parts needed by pango). New version of pango depends on HarfBuzz so if current harfbuzz patch is not going in, neither can pango update.

- ML

#12 lore raw
In reply to Saul Wold
Quoted 67 lines · Saul Wold

Richard,

Finally another collected set of patches, my network access was worse than I thought it would be the last few days.

I built these locally.

Thanks
Sau!

The following changes since commit b693f6d3d48b281fbbf71fd56996c85e23c3a9c9:

freetype: update to 2.4.11 which includes fixes for CVE-2012-{5668, 5669, 5670} (2012-12-31 09:42:49 +0000)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage

Chen Qi (1):
init-live.sh: avoid duplicate mount points for the same filesystem

Christopher Larson (6):
update-alternatives.bbclass: use absolute paths for link targets
opkg-native: obey virtual/update-alternatives-native
chkconfig: don't inherit autotools
chkconfig: obey sysconfdir, base_libdir
chkconfig: package the update-alternatives implementation chkconfig-alternatives-native-1.3.59: add recipe

Constantin Musca (8):
libpam: enable multilib
package.bbclass: don't prepend MLPREFIX to LOCALEBASEPN
eglibc-locale: enable multilib
sysstat: fix sa_lib_dir
rpm: replace /usr/lib with ${libdir}
libfm: upgrade to 1.1.0
pcmanfm: upgrade to 1.1.0
vte: add missing unpackaged files

David Nyström (1):
Added ability to parse python sources to create-recipe

Kang Kai (4):
autoconf: update RDEDENDS
perl: add sub-package perl-tests
perl: update RPROVIDES and popuate_package script
perl: update dependency creating script

Laurentiu Palcu (1):
pango: have postinstalls run at do_rootfs time

Marko Lindqvist (7):
automake: update to upstream version 1.12.6
gmp: update SRC_URI and HOMEPAGE
gmp: update to upstream version 5.1.0
mpfr: update to upstream version 3.1.1
icu: update to upstream version 50.1.1
harfbuzz: add recipe, version 0.9.9
pango: update to upstream version 1.32.5

Martin Jansa (1):
kernel.bbclass: include PE in KERNEL_IMAGE_BASE_NAME

Noor Ahsan (1):
cairo: Adds libxext in X11DEPENDS.

Quoted 8 lines

Robert P. J. Day (2):
lib_package.bbclass: Correct comment referring to bin directories. package.bbclass: Skip testing "packages" a second time.

Saul Wold (3):
libnl: Update to 3.2.16
glib-2.0: Update to 2.35.3
glib-networking: Update to 2.35.1

Merged, apart from harfbuzz, pango, glib and glib-networking changes as per the feedback on list.

Cheers,

Richard

#13 lore raw
Quoted 7 lines · Richard Purdie
Quoted 3 lines · Saul Wold

Laurentiu Palcu (1):
pango: have postinstalls run at do_rootfs time

Merged, apart from harfbuzz, pango, glib and glib-networking changes as per the feedback on list.

I think pango can be merged. The comments on the list are about other packages that ship pango modules, in which case the qemu approach should be used.

Thanks,
Laurentiu

Quoted 11 lines

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#14 lore raw
Quoted 5 lines · Laurentiu Palcu
Quoted 2 lines · Richard Purdie
Quoted 1 line · Saul Wold
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

Laurentiu Palcu (1):
pango: have postinstalls run at do_rootfs time

Merged, apart from harfbuzz, pango, glib and glib-networking changes as per the feedback on list.

I think pango can be merged. The comments on the list are about other packages that ship pango modules, in which case the qemu approach should be used.

This was about pango update (to 1.32) to depend on harfbuzz so when
harfbuzz was dropped, pango update had to be dropped too (it wouldn't build)

- ML

#15 lore raw
Quoted 11 lines · Marko Lindqvist
Quoted 10 lines · Laurentiu Palcu
Quoted 7 lines · Richard Purdie
Quoted 3 lines · Saul Wold

Laurentiu Palcu (1):
pango: have postinstalls run at do_rootfs time

Merged, apart from harfbuzz, pango, glib and glib-networking changes as per the feedback on list.

Quoted 7 lines
Quoted 3 lines

I think pango can be merged. The comments on the list are about other packages that ship pango modules, in which case the qemu approach should be used.

This was about pango update (to 1.32) to depend on harfbuzz so when
harfbuzz was dropped, pango update had to be dropped too (it wouldn't build)

Sorry for the noise then. I missed the pango update commit line...

Thanks,
Laurentiu

Quoted 4 lines

- ML