Re: [OE-core] [PATCH 1/1] self-hosted-image: pre-populate the builder user with poky source
Op 18 mrt. 2012, om 06:41 heeft Dexuan Cui het volgende geschreven: > [YOCTO #2065] What does that mean? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] self-hosted-image: pre-populate the builder user with poky source
Koen Kooi wrote on 2012-03-18: > > Op 18 mrt. 2012, om 06:41 heeft Dexuan Cui het volgende geschreven: > >> [YOCTO #2065] > > What does that mean? Sorry, I should have made it more clear. :-) It means bug 2065 is addressed by the patch: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2065 Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] self-hosted-image: pre-populate the builder user with poky source
Op 18 mrt. 2012, om 10:52 heeft Cui, Dexuan het volgende geschreven: > Koen Kooi wrote on 2012-03-18: >> >> Op 18 mrt. 2012, om 06:41 heeft Dexuan Cui het volgende geschreven: >> >>> [YOCTO #2065] >> >> What does that mean? > Sorry, I should have made it more clear. :-) > > It means bug 2065 is addressed by the patch: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=2065 So add that and (part of) the bug description into the commit message ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/60] Package Upgrade
On Fri, 2012-03-16 at 14:53 +0100, Koen Kooi wrote: > Op 16 mrt. 2012, om 14:45 heeft Wang, Shane het volgende geschreven: > > > I built those recipes separately, built core-image-sato on qemux86 > and qemuarm, and launched the image in the emulator and ran some > applications. > > So no checks for buildhistory changes and upgrade paths. For what its worth, several of us have been testing the pending patches rather heavily since they were proposed. They're not without issue but I think we've tracked down the problematic patches and those won't be going in (automake, pciaccess, alsa-utils). I know Saul is doing some proper testing but I also did some, mainly to experiment with buildhistory for myself. I'm hoping to see a lot more use of buildhistory by people submitting patches. I've attached the cut down output of this patch series and a lot of other pending patches against current master. In the interests of full disclosure, I did apply http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=099d5a1d4a41e6530d487ed08ab56d1b299b6142 when generating this log. This: a) Hides RRECOMMENDS/RDEPENDS changes if its only a version change and the version increased. b) Ignores FILELIST changes in -dbg packages, they seem to contain the version and just aren't interesting. and I'll be talking with Paul about integrating some filtering properly rather than my hacks :). There is still a lot of noise in the diff but this helps a lot. I did scan through it and the ones that looked like they merited further investigation to me were: packages/i586-poky-linux/dbus-glib/dbus-glib-dev: FILELIST: removed "/usr/include/dbus-1.0/dbus/dbus-glib-error-enum.h" packages/i586-poky-linux/gdk-pixbuf/gdk-pixbuf: FILELIST: removed "/usr/lib/libgdk_pixbuf_xlib-2.0.so.0.2400.0 /usr/lib/libgdk_pixbuf_xlib-2.0.so.0 /usr/lib/libgdk_pixbuf-2.0.so.0.2400.0" added "/usr/lib/libgdk_pixbuf-2.0.so.0.2400.1" packages/i586-poky-linux/gdk-pixbuf/gdk-pixbuf: RDEPENDS: removed "libxcb (>= 1.8) libx11-trim (>= 1.4.4) libxdmcp (>= 1.1.0) libxau (>= 1.0.6)" packages/i586-poky-linux/libarchive/libarchive-bin: RDEPENDS: added "libxml2 (>= 2.7.8) libcrypto (>= 1.0.0g)" packages/i586-poky-linux/libarchive/libarchive: RDEPENDS: added "libcrypto (>= 1.0.0g)" packages/i586-poky-linux/xf86-video-vmware/xf86-video-vmware: FILELIST: removed "/usr/lib/xorg/modules/drivers/vmwlegacy_drv.so" packages/i586-poky-linux/xf86-video-vmware/xf86-video-vmware: RDEPENDS: removed "libdrm (>= 2.4.31)" packages/x86_64-nativesdk-pokysdk-linux/qemu-nativesdk/qemu-nativesdk: RDEPENDS: removed "libcurl (>= 7.23.1)" packages/i586-poky-linux/python-pycurl/python-pycurl: RDEPENDS: removed "libgcrypt (>= 1.5.0)" packages/i586-poky-linux/dbus-glib/dbus-glib: RDEPENDS: added "zlib (>= 1.2.6)" packages/i586-poky-linux/gypsy/gypsy: RDEPENDS: added "zlib (>= 1.2.6)" packages/i586-poky-linux/libgalago/libgalago: RDEPENDS: added "zlib (>= 1.2.6)" packages/i586-poky-linux/python-dbus/python-dbus: RDEPENDS: added "zlib (>= 1.2.6)" but all things considered, its not a bad diff given the number of upgrades. There was also a fair bit of churn in gstreamer: packages/i586-poky-linux/clutter-gst-1.8/clutter-gst-1.8: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugin-bluetooth/gst-plugin-bluetooth: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-bad/gst-plugins-bad-meta: RDEPENDS: added "libgstcodecparsers-0.10 libgstbasecamerabinsrc-0.10" packages/i586-poky-linux/gst-plugins-bad/libgstsignalprocessor-0.10: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-adder: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-alsa: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-audioconvert: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-decodebin: RDEPENDS: removed "libgstvideo-0.10 (>= 0.10.35)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-decodebin2: RDEPENDS: removed "libgstvideo-0.10 (>= 0.10.35)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-encodebin: RDEPENDS: removed "libgstvideo-0.10 (>= 0.10.35)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-ivorbisdec: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-ogg: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-typefindfunctions: RDEPENDS: removed "libgstvideo-0.10 (>= 0.10.35)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-volume-dev: RRECOMMENDS: added "libgstpbutils-0.10-dev" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-volume: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins
Re: [OE-core] [PATCH 1/6] scripts/bitbake: ensure user is in build directory
On 16.03.2012 11:56, Paul Eggleton wrote: > On Friday 16 March 2012 01:20:44 Andreas Oberritter wrote: >> Sorry, I messed up some details. In fact, pseudo-native doesn't get >> rebuilt, but bitbake pseudo-native still gets executed for every >> machine, unless $BUILDDIR/pseudodone is present and contains >> PSEUDOBINDIR. This just wastes time and confuses users who receive a >> message saying "Pseudo is not present but is required, building this >> first before the main build". > > It takes a small amount of time just once. However if this is really an issue > perhaps we could address it directly rather than hacking around it? > BUILDDIR doesn't seem to have any other use than pointing to the 'pseudodone' file. I don't understand why it's required to run bitbake from there. >>> >>> Well, it's required that bitbake is run from the build directory and when >>> you use the setup script as intended that's where BUILDDIR points to. I >>> hadn't anticipated that anyone would be changing BUILDDIR to point to >>> anything other than the build dir, however I don't really think it's a >>> good idea to support that. >> >> That's because BUILDDIR has no meaning outside oe-core's setup scripts. >> In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or >> similar, because that's what the variable really means in this context > > The naming is such that it should point to the build directory because that's > where pseudodone is meant to be written. I think when it was introduced there > was an idea that it might be useful in other contexts, thus the naming. What is the reason for storing 'pseudodone' inside BUILDDIR? Wouldn't it better be stored inside TMPDIR by default? Isn't there any way to get rid of pseudodone completely? >> In order to verify that scripts/bitbake is called from the build >> directory, you could as well just check whether $PWD/conf/local.conf exists. > > Unfortunately it's not that simple. bitbake.conf pulls in local.conf using > "include" and not "require", thus it doesn't actually have to exist anywhere. In fact it is that simple, because If local.conf doesn't exist, oe-setup-builddir creates it. >> I'm not using oe-core's scripts, because they make assumptions about the >> directory layout that don't fit my project's needs. I think they are >> overly complex > > Could you perhaps elaborate on what needs those scripts are not fulfilling? 1.) OE-core is not my top-level directory. It's included as a git submodule. it must not contain any data not fetched from the OE-core repository (i.e. no bitbake tree, no build dirs). 2.) Switching between build directories must not involve changing the environment. >> and they display texts that seem to suit yocto's needs but at least not >> mine. > > We print these messages so that people know what to do and where to find > further information. I don't think that's unreasonable. However if you have > suggestions on how we might improve those messages or allow them to be > customised if necessary, we could look at changing them. I'd like to display none of those messages to my users. We have our own help texts that are specific to our distribution and configuration. Our setup script is based on GNU make and uses make's dependency tracking. It creates local.conf on its own. I don't want any other script to do that. I really don't want to be forced to use those OE-core scripts, if a two-line script is sufficient to fulfil my needs. This two-line script just sets up the path to bitbake and sets the location of 'pseudodone' (which already sucks - the path to bitbake should be sufficient alone). Regards, Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] what's the proper place to make comments about the bitbake manual?
i'm collecting a bunch of observations and suggestions about the current bitbake manual -- should i continue posting them to bitbake-devel, or should that list be reserved for actual bitbake developer questions rather than documentation? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/60] Package Upgrade
On 03/18/2012 06:18 AM, Richard Purdie wrote: On Fri, 2012-03-16 at 14:53 +0100, Koen Kooi wrote: Op 16 mrt. 2012, om 14:45 heeft Wang, Shane het volgende geschreven: I built those recipes separately, built core-image-sato on qemux86 and qemuarm, and launched the image in the emulator and ran some applications. So no checks for buildhistory changes and upgrade paths. For what its worth, several of us have been testing the pending patches rather heavily since they were proposed. They're not without issue but I think we've tracked down the problematic patches and those won't be going in (automake, pciaccess, alsa-utils). I know Saul is doing some proper testing but I also did some, mainly to experiment with buildhistory for myself. I'm hoping to see a lot more use of buildhistory by people submitting patches. I've attached the cut down output of this patch series and a lot of other pending patches against current master. In the interests of full disclosure, I did apply http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=099d5a1d4a41e6530d487ed08ab56d1b299b6142 when generating this log. This: a) Hides RRECOMMENDS/RDEPENDS changes if its only a version change and the version increased. b) Ignores FILELIST changes in -dbg packages, they seem to contain the version and just aren't interesting. and I'll be talking with Paul about integrating some filtering properly rather than my hacks :). There is still a lot of noise in the diff but this helps a lot. I did scan through it and the ones that looked like they merited further investigation to me were: packages/i586-poky-linux/dbus-glib/dbus-glib-dev: FILELIST: removed "/usr/include/dbus-1.0/dbus/dbus-glib-error-enum.h" packages/i586-poky-linux/gdk-pixbuf/gdk-pixbuf: FILELIST: removed "/usr/lib/libgdk_pixbuf_xlib-2.0.so.0.2400.0 /usr/lib/libgdk_pixbuf_xlib-2.0.so.0 /usr/lib/libgdk_pixbuf-2.0.so.0.2400.0" added "/usr/lib/libgdk_pixbuf-2.0.so.0.2400.1" This is packaged in the build I have, not sure what you are basing this one. packages/i586-poky-linux/gdk-pixbuf/gdk-pixbuf: RDEPENDS: removed "libxcb (>= 1.8) libx11-trim (>= 1.4.4) libxdmcp (>= 1.1.0) libxau (>= 1.0.6)" packages/i586-poky-linux/libarchive/libarchive-bin: RDEPENDS: added "libxml2 (>= 2.7.8) libcrypto (>= 1.0.0g)" packages/i586-poky-linux/libarchive/libarchive: RDEPENDS: added "libcrypto (>= 1.0.0g)" packages/i586-poky-linux/xf86-video-vmware/xf86-video-vmware: FILELIST: removed "/usr/lib/xorg/modules/drivers/vmwlegacy_drv.so" This one also seems to be packaged correctly on my build. I pushed my build history of a master world build followed by a MUT build to sgw/buildhistory if you want to look at it further. Sau! packages/i586-poky-linux/xf86-video-vmware/xf86-video-vmware: RDEPENDS: removed "libdrm (>= 2.4.31)" packages/x86_64-nativesdk-pokysdk-linux/qemu-nativesdk/qemu-nativesdk: RDEPENDS: removed "libcurl (>= 7.23.1)" packages/i586-poky-linux/python-pycurl/python-pycurl: RDEPENDS: removed "libgcrypt (>= 1.5.0)" packages/i586-poky-linux/dbus-glib/dbus-glib: RDEPENDS: added "zlib (>= 1.2.6)" packages/i586-poky-linux/gypsy/gypsy: RDEPENDS: added "zlib (>= 1.2.6)" packages/i586-poky-linux/libgalago/libgalago: RDEPENDS: added "zlib (>= 1.2.6)" packages/i586-poky-linux/python-dbus/python-dbus: RDEPENDS: added "zlib (>= 1.2.6)" but all things considered, its not a bad diff given the number of upgrades. There was also a fair bit of churn in gstreamer: packages/i586-poky-linux/clutter-gst-1.8/clutter-gst-1.8: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugin-bluetooth/gst-plugin-bluetooth: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-bad/gst-plugins-bad-meta: RDEPENDS: added "libgstcodecparsers-0.10 libgstbasecamerabinsrc-0.10" packages/i586-poky-linux/gst-plugins-bad/libgstsignalprocessor-0.10: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-adder: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-alsa: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-audioconvert: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-decodebin: RDEPENDS: removed "libgstvideo-0.10 (>= 0.10.35)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-decodebin2: RDEPENDS: removed "libgstvideo-0.10 (>= 0.10.35)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-encodebin: RDEPENDS: removed "libgstvideo-0.10 (>= 0.10.35)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-ivorbisdec: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-ogg: RDEPENDS: added "libgstpbutils-0.10 (>= 0.10.36)" packages/i586-poky-linux/gst-plugins-base/gst-plugins-base-typefindfunctions: RDEP
Re: [OE-core] [PATCH 1/1] self-hosted-image: pre-populate the builder user with poky source
Koen Kooi wrote on 2012-03-18: > > Op 18 mrt. 2012, om 10:52 heeft Cui, Dexuan het volgende geschreven: > >> Koen Kooi wrote on 2012-03-18: >>> >>> Op 18 mrt. 2012, om 06:41 heeft Dexuan Cui het volgende geschreven: >>> [YOCTO #2065] >>> >>> What does that mean? >> Sorry, I should have made it more clear. :-) >> >> It means bug 2065 is addressed by the patch: >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2065 > > So add that and (part of) the bug description into the commit message OK, please review and use the updated commit(only the commit description was updated): http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/self&id=0882b5e0adb05d4f950c721fcb80b4cff42ce079 Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] LSB support?
I have encountered a similar problem when do a clean building in another VM (running archlinux). after remove /usr//lib/libXrandr.so.2: mv /usr/lib/../lib/libXrandr.so.2 /usr/lib/../lib/libXrandr.so.2.bak I got a new error: /usr/lib/../lib/libXext.so.6: undefined reference to `memcpy@GLIBC_2.14' so IMO, it used the wrong lib path. following is the output section of 'do_compile', the key is '/usr/lib/../lib', maybe it should be '/usr/lib/../lib'. output section: Making all in gconf make[2]: Entering directory `/media/pangu/lsbt/tmp/work/x86_64-poky-linux/gconf-3.2.3-r8/GConf-3.2.3/gconf' make all-am make[3]: Entering directory `/media/pangu/lsbt/tmp/work/x86_64-poky-linux/gconf-3.2.3-r8/GConf-3.2.3/gconf' ../x86_64-poky-linux-libtool --tag=CC --mode=link x86_64-poky-linux-gcc-m64 --sysroot=/media/pangu/lsbt/tmp/sysroots/qemux86-64 -O2 -pipe -g -feliminate-unused-debug-types -Wall -DGCONF_ENABLE_DEBUG=1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o gconf-sanity-check-2 gconf-sanity-check.o libgconf-2.la -pthread -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 x86_64-poky-linux-libtool: link: x86_64-poky-linux-gcc -m64 --sysroot=/media/pangu/lsbt/tmp/sysroots/qemux86-64 -O2 -pipe -g -feliminate-unused-debug-types -Wall -DGCONF_ENABLE_DEBUG=1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o .libs/gconf-sanity-check-2 gconf-sanity-check.o -pthread -Wl,--export-dynamic ./.libs/libgconf-2.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libdbus-glib-1.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libdbus-1.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgtk-x11-2.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgdk-x11-2.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libatk-1.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpangocairo-1.0.so -L=/usr/lib /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpangoft2-1.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/../lib/libstdc++.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgdk_pixbuf-2.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgio-2.0.so -lresolv /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libcairo.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpixman-1.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpng12.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libXrender.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libX11.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libxcb.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libXau.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libXdmcp.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpango-1.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libfontconfig.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libfreetype.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libexpat.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgobject-2.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libffi.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgmodule-2.0.so /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgthread-2.0.so -lpthread /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libglib-2.0.so -lrt /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libxml2.so -ldl -lz -lm -pthread -Wl,-rpath -Wl,/usr/lib/../lib /usr/lib/../lib/libXext.so.6: undefined reference to `memcpy@GLIBC_2.14' collect2: ld returned 1 exit status make[3]: *** [gconf-sanity-check-2] Error 1 On Fri, 2012-03-16 at 23:36 +0800, Mark Hatle wrote: > On 3/16/12 12:18 AM, Ni Qingliang wrote: > > when building qemux86-64 arch core-image-lsb (distro is poky-lsb), I got > > /usr/lib/../lib/libXrandr.so.2: undefined reference to > > `memcpy@GLIBC_2.14' when 'do_compile' gconf 3.2.3. > > > > the default eglibc is 2.13, why it needs 2.14? > > Without anything further, the only guess I can make is that either you aren't > using the version of glibc you think you are, it's gotten some host > contamination, an explicit reference was added to libXrandr (doubtful), or you > are using something that was built/cached from a previous build. (i.e. did > you > build w/ eglibc 2.14/2.15 -- and then switch back to eglibc 2.13 for some > reason?) > > On 3/15/12 9:38 PM, Ni Qingliang wrote: > > first, thanks your reply. > > > > Because I can't use task-core-lsb on my device (flash space is not > > enough), I have to make a custom lsb-base image (without > > perl/python/graphics). > > > > I have checked the "linuxstdbase", and it will change the configure > > option of some packages. > > > > Indeed, I think the daemon/failure/warning fuctions should be considered > > in package lsb's RDEPENDS. > > > > what I want to know is the rdepends or where is the > > daemon/failure/
[OE-core] [PATCH 0/1] warning fix of sysvinit-inittab.
This fixed the warning in do_populate_lic task in sysvinit-inittab. The following changes since commit efd80fd23cb96ccc203893017938c1163d20b898: Richard Purdie (1): tcl: Fix bad RPATH QA warning are available in the git repository at: git://git.yoctoproject.org/poky-contrib llu/warningfix http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=llu/warningfix Lianhao Lu (1): sysvinit-inittab: Fixed license warning. .../sysvinit/sysvinit-inittab_2.88dsf.bb |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] sysvinit-inittab: Fixed license warning.
WARNING: .../sysvinit-inittab-2.88dsf-r6/sysvinit-2.88dsf/COPYING could
not be copied for some reason. It may not exist. WARN for now.
Signed-off-by: Lianhao Lu
---
.../sysvinit/sysvinit-inittab_2.88dsf.bb |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 3a716d7..85e34c8 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -11,7 +11,11 @@ S = "${WORKDIR}/sysvinit-${PV}"
INHIBIT_DEFAULT_DEPS = "1"
-do_configure() {
+do_unpack_append() {
+ bb.build.exec_func('do_copy_lic', d)
+}
+
+do_copy_lic () {
cp ${WORKDIR}/COPYING ${S}/
}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/8] alsa-utils: update to 1.0.25
On 2012年03月16日 15:25, Wang, Shane wrote: Kang Kai wrote on 2012-03-14: Update to version 1.0.25, and update patch 0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch because rejected when apply it. Signed-off-by: Kang Kai Kai, why did you drop the patch? You can port it to alsa-utils v1.0.25 code base, as I did. http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=shane/m4upgrade&id=924cdfe1a0069ff53526afe67b11cbd9405472de Hi Shane, Yes, I just update the patch and don't drop it. Maybe the comments is not clear, that I mean the patch is jejected by bitbake when run do_patch. Regards, Kai -- Shane ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] task-self-hosted: add nfs-utils and nfs-utils-client into the target
Without this, in the target, we don't have the mount.nfs utility.
Signed-off-by: Dexuan Cui
---
meta/recipes-core/tasks/task-self-hosted.bb |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/tasks/task-self-hosted.bb
b/meta/recipes-core/tasks/task-self-hosted.bb
index 586a461..d349078 100644
--- a/meta/recipes-core/tasks/task-self-hosted.bb
+++ b/meta/recipes-core/tasks/task-self-hosted.bb
@@ -3,7 +3,7 @@
#
DESCRIPTION = "Create Basic Image Tasks"
-PR = "r6"
+PR = "r7"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
@@ -123,6 +123,8 @@ RDEPENDS_task-self-hosted-extended = "\
mtools \
ncurses \
neon \
+nfs-utils \
+nfs-utils-client \
openssl \
opkg \
opkg-utils \
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] task-self-hosted: add nfs-utils and nfs-utils-client into the target
The following changes since commit 0882b5e0adb05d4f950c721fcb80b4cff42ce079: self-hosted-image: pre-populate the builder user with poky source (2012-03-19 09:31:19 +0800) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/self http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/self Dexuan Cui (1): task-self-hosted: add nfs-utils and nfs-utils-client into the target meta/recipes-core/tasks/task-self-hosted.bb |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] LSB support?
Is anybody there? Is the info enough? On Mon, 2012-03-19 at 09:47 +0800, 倪庆亮 wrote: > I have encountered a similar problem when do a clean building in another > VM (running archlinux). > > after remove /usr//lib/libXrandr.so.2: > mv /usr/lib/../lib/libXrandr.so.2 /usr/lib/../lib/libXrandr.so.2.bak > > I got a new error: > /usr/lib/../lib/libXext.so.6: undefined reference to `memcpy@GLIBC_2.14' > > so IMO, it used the wrong lib path. following is the output section of > 'do_compile', the key is '/usr/lib/../lib', maybe it should be > '/usr/lib/../lib'. > > output section: > Making all in gconf > make[2]: Entering directory > `/media/pangu/lsbt/tmp/work/x86_64-poky-linux/gconf-3.2.3-r8/GConf-3.2.3/gconf' > make all-am > make[3]: Entering directory > `/media/pangu/lsbt/tmp/work/x86_64-poky-linux/gconf-3.2.3-r8/GConf-3.2.3/gconf' > ../x86_64-poky-linux-libtool --tag=CC --mode=link > x86_64-poky-linux-gcc-m64 > --sysroot=/media/pangu/lsbt/tmp/sysroots/qemux86-64 -O2 -pipe -g > -feliminate-unused-debug-types -Wall -DGCONF_ENABLE_DEBUG=1 -Wl,-O1 > -Wl,--hash-style=gnu -Wl,--as-needed -o gconf-sanity-check-2 > gconf-sanity-check.o libgconf-2.la -pthread -Wl,--export-dynamic > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 > -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype > -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 > -lxml2 > x86_64-poky-linux-libtool: link: x86_64-poky-linux-gcc -m64 > --sysroot=/media/pangu/lsbt/tmp/sysroots/qemux86-64 -O2 -pipe -g > -feliminate-unused-debug-types -Wall -DGCONF_ENABLE_DEBUG=1 -Wl,-O1 > -Wl,--hash-style=gnu -Wl,--as-needed -o .libs/gconf-sanity-check-2 > gconf-sanity-check.o -pthread > -Wl,--export-dynamic ./.libs/libgconf-2.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libdbus-glib-1.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libdbus-1.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgtk-x11-2.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgdk-x11-2.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libatk-1.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpangocairo-1.0.so > -L=/usr/lib > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpangoft2-1.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/../lib/libstdc++.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgdk_pixbuf-2.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgio-2.0.so -lresolv > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libcairo.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpixman-1.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpng12.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libXrender.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libX11.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libxcb.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libXau.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libXdmcp.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libpango-1.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libfontconfig.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libfreetype.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libexpat.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgobject-2.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libffi.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgmodule-2.0.so > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libgthread-2.0.so -lpthread > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libglib-2.0.so -lrt > /media/pangu/lsbt/tmp/sysroots/qemux86-64/usr/lib/libxml2.so -ldl -lz -lm > -pthread -Wl,-rpath -Wl,/usr/lib/../lib > /usr/lib/../lib/libXext.so.6: undefined reference to `memcpy@GLIBC_2.14' > collect2: ld returned 1 exit status > make[3]: *** [gconf-sanity-check-2] Error 1 > > On Fri, 2012-03-16 at 23:36 +0800, Mark Hatle wrote: > > On 3/16/12 12:18 AM, Ni Qingliang wrote: > > > when building qemux86-64 arch core-image-lsb (distro is poky-lsb), I got > > > /usr/lib/../lib/libXrandr.so.2: undefined reference to > > > `memcpy@GLIBC_2.14' when 'do_compile' gconf 3.2.3. > > > > > > the default eglibc is 2.13, why it needs 2.14? > > > > Without anything further, the only guess I can make is that either you > > aren't > > using the version of glibc you think you are, it's gotten some host > > contamination, an explicit reference was added to libXrandr (doubtful), or > > you > > are using something that was built/cached from a previous build. (i.e. did > > you > > build w/ eglibc 2.14/2.15 -- and then switch back to eglibc 2.13 for some > > reason?) > > > > On 3/15/12 9:38 PM, Ni Qingliang wrote: > > > first, thanks your reply. > > > > > > Because I can't use task-core-lsb on my device (flash space is not > > > enough), I have to make a custom lsb-base image (without > > > perl/python/graphics). > > > > > > I have checked th
