* Unwanted dependency on X from ppp @ 2011-07-13 12:16 Mats Kärrman 2011-07-13 14:18 ` Bob Foerster 0 siblings, 1 reply; 8+ messages in thread From: Mats Kärrman @ 2011-07-13 12:16 UTC (permalink / raw) To: openembedded-devel Hi Everyone! I'm building a small "headless" embedded system with OE and the Angstrom distro. A normal rootfs build consists of about 1500 tasks. Everything fine so far. Now I wanted to include the ppp daemon in my build and thus just added "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a lot of X/display related stuff is downloaded and built. I fail to see the connection. I'm afraid I'm not using the latest trunk or release of OE but any suggestions or directions on how to find/eliminate the cause of the problem would be greatly appreciated! Best Regards, Mats ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unwanted dependency on X from ppp 2011-07-13 12:16 Unwanted dependency on X from ppp Mats Kärrman @ 2011-07-13 14:18 ` Bob Foerster 2011-07-13 15:37 ` Mats Kärrman 0 siblings, 1 reply; 8+ messages in thread From: Bob Foerster @ 2011-07-13 14:18 UTC (permalink / raw) To: openembedded-devel Hi Mats, On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote: > Hi Everyone! > > I'm building a small "headless" embedded system with OE and the Angstrom > distro. A normal rootfs build consists of about 1500 tasks. Everything fine > so far. > > Now I wanted to include the ppp daemon in my build and thus just added > "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a > lot of X/display related stuff is downloaded and built. I fail to see the > connection. > Are the X/display items you're concerned about actually making it into the final image, or just being built? If they are ending up in the image, then it will take some investigation as to why that's happening. If they're just being built there is probably not much you can do, but the following may help shed some light as to why they are built. To understand why adding ppp pulls in various X/display packages, keep in mind that what is downloaded and built does not directly correlate to what ends up in the image. Often, recipes may provide several packages which have a broad set of build time dependencies, but these don't all necessarily end up in the image. For tracking down dependencies, you can fire up the dependency explorer gui for bitbake: bitbake -g -u depexp ppp Doing this and following the trail, one sees: ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for bluez-libs) -> gst-plugins-base -> gtk+ -> libx* Given this dependency chain, we start to see why building ppp causes various gtk+ and X packages to be built. The bluez4 recipe provides a package gst-plugin-bluez, causing a build time dependency on gst-plugins-base. gst-plugins-base depends on many things, including gtk+. As a result of these dependencies, many packages end up being built. The shlibs code in OE automatically detects the run time libs required for a given package and appropriately associates run time dependencies on them. As such, unless one adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+, libx*, etc packages to make it into the final image. If they are, then there is another dependency that is pulling them into the image and needs explored. For a little bit more background on build vs run time dependencies, see [1]. Hope that helps clarify a bit. Bob [1] http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem > I'm afraid I'm not using the latest trunk or release of OE but any > suggestions or directions on how to find/eliminate the cause of the problem > would be greatly appreciated! > > Best Regards, > Mats > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unwanted dependency on X from ppp 2011-07-13 14:18 ` Bob Foerster @ 2011-07-13 15:37 ` Mats Kärrman 2011-07-13 15:59 ` Bob Foerster 2011-07-13 16:11 ` Mike Westerhof 0 siblings, 2 replies; 8+ messages in thread From: Mats Kärrman @ 2011-07-13 15:37 UTC (permalink / raw) To: openembedded-devel Thank you Bob! You're my hero, honestly! The "clean build" time concerns me though. I will need bluez components, but not gstreamer so I guess I'll set out to find a neat way to override the default bluez recipe and get rid of that dependency. // Mats ________________________________________ From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob Foerster [robert@erafx.com] Sent: Wednesday, July 13, 2011 4:18 PM To: openembedded-devel@lists.openembedded.org Subject: Re: [oe] Unwanted dependency on X from ppp Hi Mats, On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote: > Hi Everyone! > > I'm building a small "headless" embedded system with OE and the Angstrom > distro. A normal rootfs build consists of about 1500 tasks. Everything fine > so far. > > Now I wanted to include the ppp daemon in my build and thus just added > "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a > lot of X/display related stuff is downloaded and built. I fail to see the > connection. > Are the X/display items you're concerned about actually making it into the final image, or just being built? If they are ending up in the image, then it will take some investigation as to why that's happening. If they're just being built there is probably not much you can do, but the following may help shed some light as to why they are built. To understand why adding ppp pulls in various X/display packages, keep in mind that what is downloaded and built does not directly correlate to what ends up in the image. Often, recipes may provide several packages which have a broad set of build time dependencies, but these don't all necessarily end up in the image. For tracking down dependencies, you can fire up the dependency explorer gui for bitbake: bitbake -g -u depexp ppp Doing this and following the trail, one sees: ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for bluez-libs) -> gst-plugins-base -> gtk+ -> libx* Given this dependency chain, we start to see why building ppp causes various gtk+ and X packages to be built. The bluez4 recipe provides a package gst-plugin-bluez, causing a build time dependency on gst-plugins-base. gst-plugins-base depends on many things, including gtk+. As a result of these dependencies, many packages end up being built. The shlibs code in OE automatically detects the run time libs required for a given package and appropriately associates run time dependencies on them. As such, unless one adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+, libx*, etc packages to make it into the final image. If they are, then there is another dependency that is pulling them into the image and needs explored. For a little bit more background on build vs run time dependencies, see [1]. Hope that helps clarify a bit. Bob [1] http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem > I'm afraid I'm not using the latest trunk or release of OE but any > suggestions or directions on how to find/eliminate the cause of the problem > would be greatly appreciated! > > Best Regards, > Mats > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unwanted dependency on X from ppp 2011-07-13 15:37 ` Mats Kärrman @ 2011-07-13 15:59 ` Bob Foerster 2011-07-13 16:11 ` Mike Westerhof 1 sibling, 0 replies; 8+ messages in thread From: Bob Foerster @ 2011-07-13 15:59 UTC (permalink / raw) To: openembedded-devel On Wed, Jul 13, 2011 at 11:37 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote: > Thank you Bob! > > You're my hero, honestly! > No problem, happy to help! > The "clean build" time concerns me though. I will need bluez components, > but not gstreamer so I guess I'll set out to find a neat way to override > the default bluez recipe and get rid of that dependency. > > I would normally override this in my layer using amend.inc. You can probably do it with bbappend too, but I'm not too familiar with that. The basic idea to remove that dependency would be to override/modify bluez4.inc (or any other offending files): - remove gst-plugins-base from DEPENDS so gstreamer and all dependencies don't get built - fix configuring/compiling of the package after removing the dependency (like modify EXTRA_OECONF to get rid of the enable gstreamer switch) That may not be all that needs done, but that should at least get you on the right track. Enjoy! Bob // Mats > > ________________________________________ > From: openembedded-devel-bounces@lists.openembedded.org [ > openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob > Foerster [robert@erafx.com] > Sent: Wednesday, July 13, 2011 4:18 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] Unwanted dependency on X from ppp > > Hi Mats, > > On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se > >wrote: > > > Hi Everyone! > > > > I'm building a small "headless" embedded system with OE and the Angstrom > > distro. A normal rootfs build consists of about 1500 tasks. Everything > fine > > so far. > > > > Now I wanted to include the ppp daemon in my build and thus just added > > "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and > a > > lot of X/display related stuff is downloaded and built. I fail to see the > > connection. > > > > Are the X/display items you're concerned about actually making it into the > final image, or just being built? If they are ending up in the image, then > it will take some investigation as to why that's happening. If they're just > being built there is probably not much you can do, but the following may > help shed some light as to why they are built. > > To understand why adding ppp pulls in various X/display packages, keep in > mind that what is downloaded and built does not directly correlate to what > ends up in the image. Often, recipes may provide several packages which > have a broad set of build time dependencies, but these don't all > necessarily > end up in the image. > > For tracking down dependencies, you can fire up the dependency explorer gui > for bitbake: > bitbake -g -u depexp ppp > > Doing this and following the trail, one sees: > ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for > bluez-libs) -> gst-plugins-base -> gtk+ -> libx* > > Given this dependency chain, we start to see why building ppp causes > various > gtk+ and X packages to be built. The bluez4 recipe provides a package > gst-plugin-bluez, causing a build time dependency on gst-plugins-base. > gst-plugins-base depends on many things, including gtk+. As a result of > these dependencies, many packages end up being built. The shlibs code in > OE > automatically detects the run time libs required for a given package and > appropriately associates run time dependencies on them. As such, unless > one > adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+, > libx*, etc packages to make it into the final image. If they are, then > there is another dependency that is pulling them into the image and needs > explored. For a little bit more background on build vs run time > dependencies, see [1]. > > Hope that helps clarify a bit. > Bob > > [1] > > http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem > > > > > I'm afraid I'm not using the latest trunk or release of OE but any > > suggestions or directions on how to find/eliminate the cause of the > problem > > would be greatly appreciated! > > > > Best Regards, > > Mats > > > > _______________________________________________ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unwanted dependency on X from ppp 2011-07-13 15:37 ` Mats Kärrman 2011-07-13 15:59 ` Bob Foerster @ 2011-07-13 16:11 ` Mike Westerhof 2011-07-14 11:51 ` Mats Kärrman 2011-07-14 14:31 ` Dr. Michael Lauer 1 sibling, 2 replies; 8+ messages in thread From: Mike Westerhof @ 2011-07-13 16:11 UTC (permalink / raw) To: openembedded-devel; +Cc: Mats Kärrman On 7/13/2011 10:37 AM, Mats Kärrman wrote: > Thank you Bob! > > You're my hero, honestly! > > The "clean build" time concerns me though. I will need bluez components, > but not gstreamer so I guess I'll set out to find a neat way to override > the default bluez recipe and get rid of that dependency. This topic comes up for discussion now and again, and nothing really ever gets resolved. There are two camps, it seems -- I fall into the group that cares about build time as much as I care about what ends up in the image. In any case, perhaps the following incantations might be helpful; they are somewhat dated (double-check these against the current recipes!), but I used these in my local.conf to get rid of useless X11 builds on my build machines: DEPENDS_pn-bluez-libs = "dbus" EXTRA_OECONF_pn-bluez-libs = "--disable-tools --disable-network --disable-serial --disable-service --disable-usb --enable-alsa" DEPENDS_pn-bluez4 = "alsa-lib virtual/libusb0 dbus-glib libsndfile1" EXTRA_OECONF_pn-bluez4 = "--disable-gstreamer --enable-alsa --enable-usb --enable-netlink --enable-tools --enable-bccmd --enable-hid2hci --enable-dfutool --enable-hidd --enable-pand --enable-dund --disable-cups --enable-test --enable-manpages --enable-configfiles --enable-initscripts --disable-pcmciarules" DEPENDS_pn-dbus = "expat glib-2.0 virtual/libintl libsm libice" EXTRA_OECONF_X_pn-dbus = "--without-x" -Mike (mwester) > > // Mats > > ________________________________________ > From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob Foerster [robert@erafx.com] > Sent: Wednesday, July 13, 2011 4:18 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] Unwanted dependency on X from ppp > > Hi Mats, > > On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote: > >> Hi Everyone! >> >> I'm building a small "headless" embedded system with OE and the Angstrom >> distro. A normal rootfs build consists of about 1500 tasks. Everything fine >> so far. >> >> Now I wanted to include the ppp daemon in my build and thus just added >> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a >> lot of X/display related stuff is downloaded and built. I fail to see the >> connection. >> > > Are the X/display items you're concerned about actually making it into the > final image, or just being built? If they are ending up in the image, then > it will take some investigation as to why that's happening. If they're just > being built there is probably not much you can do, but the following may > help shed some light as to why they are built. > > To understand why adding ppp pulls in various X/display packages, keep in > mind that what is downloaded and built does not directly correlate to what > ends up in the image. Often, recipes may provide several packages which > have a broad set of build time dependencies, but these don't all necessarily > end up in the image. > > For tracking down dependencies, you can fire up the dependency explorer gui > for bitbake: > bitbake -g -u depexp ppp > > Doing this and following the trail, one sees: > ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for > bluez-libs) -> gst-plugins-base -> gtk+ -> libx* > > Given this dependency chain, we start to see why building ppp causes various > gtk+ and X packages to be built. The bluez4 recipe provides a package > gst-plugin-bluez, causing a build time dependency on gst-plugins-base. > gst-plugins-base depends on many things, including gtk+. As a result of > these dependencies, many packages end up being built. The shlibs code in OE > automatically detects the run time libs required for a given package and > appropriately associates run time dependencies on them. As such, unless one > adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+, > libx*, etc packages to make it into the final image. If they are, then > there is another dependency that is pulling them into the image and needs > explored. For a little bit more background on build vs run time > dependencies, see [1]. > > Hope that helps clarify a bit. > Bob > > [1] > http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem > > > >> I'm afraid I'm not using the latest trunk or release of OE but any >> suggestions or directions on how to find/eliminate the cause of the problem >> would be greatly appreciated! >> >> Best Regards, >> Mats >> >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unwanted dependency on X from ppp 2011-07-13 16:11 ` Mike Westerhof @ 2011-07-14 11:51 ` Mats Kärrman 2011-07-18 19:00 ` Petr Štetiar 2011-07-14 14:31 ` Dr. Michael Lauer 1 sibling, 1 reply; 8+ messages in thread From: Mats Kärrman @ 2011-07-14 11:51 UTC (permalink / raw) To: Openembedded-devel Thanks again, Mike & Bob, I added something in the line of Mike's suggestion to my machine conf and got the number of tasks down to just over 2200 and the build runs reasonably fast. There are still a bunch of X native related dependencies generated from dbus but I found no easy way to get rid of them. Still - a huge improvement! // Mats ________________________________________ From: Mike Westerhof [mike@mwester.net] Sent: Wednesday, July 13, 2011 6:11 PM To: openembedded-devel@lists.openembedded.org Cc: Mats Kärrman Subject: Re: [oe] Unwanted dependency on X from ppp On 7/13/2011 10:37 AM, Mats Kärrman wrote: > Thank you Bob! > > You're my hero, honestly! > > The "clean build" time concerns me though. I will need bluez components, > but not gstreamer so I guess I'll set out to find a neat way to override > the default bluez recipe and get rid of that dependency. This topic comes up for discussion now and again, and nothing really ever gets resolved. There are two camps, it seems -- I fall into the group that cares about build time as much as I care about what ends up in the image. In any case, perhaps the following incantations might be helpful; they are somewhat dated (double-check these against the current recipes!), but I used these in my local.conf to get rid of useless X11 builds on my build machines: DEPENDS_pn-bluez-libs = "dbus" EXTRA_OECONF_pn-bluez-libs = "--disable-tools --disable-network --disable-serial --disable-service --disable-usb --enable-alsa" DEPENDS_pn-bluez4 = "alsa-lib virtual/libusb0 dbus-glib libsndfile1" EXTRA_OECONF_pn-bluez4 = "--disable-gstreamer --enable-alsa --enable-usb --enable-netlink --enable-tools --enable-bccmd --enable-hid2hci --enable-dfutool --enable-hidd --enable-pand --enable-dund --disable-cups --enable-test --enable-manpages --enable-configfiles --enable-initscripts --disable-pcmciarules" DEPENDS_pn-dbus = "expat glib-2.0 virtual/libintl libsm libice" EXTRA_OECONF_X_pn-dbus = "--without-x" -Mike (mwester) > > // Mats > > ________________________________________ > From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob Foerster [robert@erafx.com] > Sent: Wednesday, July 13, 2011 4:18 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] Unwanted dependency on X from ppp > > Hi Mats, > > On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman@tritech.se>wrote: > >> Hi Everyone! >> >> I'm building a small "headless" embedded system with OE and the Angstrom >> distro. A normal rootfs build consists of about 1500 tasks. Everything fine >> so far. >> >> Now I wanted to include the ppp daemon in my build and thus just added >> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a >> lot of X/display related stuff is downloaded and built. I fail to see the >> connection. >> > > Are the X/display items you're concerned about actually making it into the > final image, or just being built? If they are ending up in the image, then > it will take some investigation as to why that's happening. If they're just > being built there is probably not much you can do, but the following may > help shed some light as to why they are built. > > To understand why adding ppp pulls in various X/display packages, keep in > mind that what is downloaded and built does not directly correlate to what > ends up in the image. Often, recipes may provide several packages which > have a broad set of build time dependencies, but these don't all necessarily > end up in the image. > > For tracking down dependencies, you can fire up the dependency explorer gui > for bitbake: > bitbake -g -u depexp ppp > > Doing this and following the trail, one sees: > ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for > bluez-libs) -> gst-plugins-base -> gtk+ -> libx* > > Given this dependency chain, we start to see why building ppp causes various > gtk+ and X packages to be built. The bluez4 recipe provides a package > gst-plugin-bluez, causing a build time dependency on gst-plugins-base. > gst-plugins-base depends on many things, including gtk+. As a result of > these dependencies, many packages end up being built. The shlibs code in OE > automatically detects the run time libs required for a given package and > appropriately associates run time dependencies on them. As such, unless one > adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+, > libx*, etc packages to make it into the final image. If they are, then > there is another dependency that is pulling them into the image and needs > explored. For a little bit more background on build vs run time > dependencies, see [1]. > > Hope that helps clarify a bit. > Bob > > [1] > http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem > > > >> I'm afraid I'm not using the latest trunk or release of OE but any >> suggestions or directions on how to find/eliminate the cause of the problem >> would be greatly appreciated! >> >> Best Regards, >> Mats >> >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unwanted dependency on X from ppp 2011-07-14 11:51 ` Mats Kärrman @ 2011-07-18 19:00 ` Petr Štetiar 0 siblings, 0 replies; 8+ messages in thread From: Petr Štetiar @ 2011-07-18 19:00 UTC (permalink / raw) To: openembedded-devel Mats Kärrman <Mats.Karrman@tritech.se> [2011-07-14 11:51:18]: > Thanks again, Mike & Bob, > > I added something in the line of Mike's suggestion to my machine conf and > got the number of tasks down to just over 2200 and the build runs reasonably > fast. There are still a bunch of X native related dependencies generated from > dbus but I found no easy way to get rid of them. Another example, here's excerpt from my ts72xx/recipes/libpcap/libpcap_1.1.1.bbappend: DEPENDS_ts72xx := "${@oe_filter_out('bluez-libs', bb.data.getVar('DEPENDS', d, 1), d)}" It filters out bluez-libs dependency for ts72xx (headless) machine. I think, that it's courtesy of kergoth (or Tartarus?) from #oe. -- ynezz ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unwanted dependency on X from ppp 2011-07-13 16:11 ` Mike Westerhof 2011-07-14 11:51 ` Mats Kärrman @ 2011-07-14 14:31 ` Dr. Michael Lauer 1 sibling, 0 replies; 8+ messages in thread From: Dr. Michael Lauer @ 2011-07-14 14:31 UTC (permalink / raw) To: openembedded-devel Mike, I think this is quite useful and should be codified as as a .inc. Cheers, :M: ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-07-18 19:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-13 12:16 Unwanted dependency on X from ppp Mats Kärrman 2011-07-13 14:18 ` Bob Foerster 2011-07-13 15:37 ` Mats Kärrman 2011-07-13 15:59 ` Bob Foerster 2011-07-13 16:11 ` Mike Westerhof 2011-07-14 11:51 ` Mats Kärrman 2011-07-18 19:00 ` Petr Štetiar 2011-07-14 14:31 ` Dr. Michael Lauer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.