[oe] [PATCH] ncftp: fix build failures with ccdv

[jackie.huang]

From: Jackie Huang 

ccdv is an internal tool to reduce the deluge Make output
to make finding actual problems easier and it is intended
to be invoked from Makefiles only, it doesn't work for the
cross compiling, so compile it with $BUILD_CC and
corresponding CFLAGS.

And I think we don't need to enable it by default to
reduce our Make output, so add a PACKAGECONFIG for it
but disable it by default.

Signed-off-by: Jackie Huang 
---
 .../ncftp-configure-use-BUILD_CC-for-ccdv.patch| 32 ++
 .../recipes-daemons/ncftp/ncftp_3.2.5.bb   |  7 -
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 
meta-networking/recipes-daemons/ncftp/ncftp/ncftp-configure-use-BUILD_CC-for-ccdv.patch

diff --git 
a/meta-networking/recipes-daemons/ncftp/ncftp/ncftp-configure-use-BUILD_CC-for-ccdv.patch
 
b/meta-networking/recipes-daemons/ncftp/ncftp/ncftp-configure-use-BUILD_CC-for-ccdv.patch
new file mode 100644
index 000..aa59017
--- /dev/null
+++ 
b/meta-networking/recipes-daemons/ncftp/ncftp/ncftp-configure-use-BUILD_CC-for-ccdv.patch
@@ -0,0 +1,32 @@
+From 043e1a9ec83a59671ef8c4cad679dbf781e5ef98 Mon Sep 17 00:00:00 2001
+From: Jackie Huang 
+Date: Sun, 29 Nov 2015 23:37:06 -0800
+Subject: [PATCH] configure: use BUILD_CC for ccdv
+
+ccdv is intended to be invoked from Makefiles only,
+it doesn't work for the cross compiling, so compile
+it with $BUILD_CC and corresponding CFLAGS.
+
+Upstream-Status: Inappropriate [cross compile specific]
+
+Signed-off-by: Jackie Huang 
+---
+ configure | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure b/configure
+index 2f0fae0..a7e9112 100755
+--- a/configure
 b/configure
+@@ -11286,7 +11286,7 @@ panic:
+ } /* main */
+ /* eof ccdv.c */
+ EOF
+-  ${CC-cc} $DEFS $CPPFLAGS $CFLAGS "ccdv.c" -o "ccdv" >/dev/null 
2>&1
++  ${BUILD_CC} $DEFS ${BUILD_CPPFLAGS} ${BUILD_CFLAGS} "ccdv.c" -o 
"ccdv" >/dev/null 2>&1
+   rm -f ccdv.c ccdv.o ccdv.c.gz.uu ccdv.c.gz
+   strip ./ccdv >/dev/null 2>&1
+   ./ccdv >/dev/null 2>&1
+-- 
+2.3.5
+
diff --git a/meta-networking/recipes-daemons/ncftp/ncftp_3.2.5.bb 
b/meta-networking/recipes-daemons/ncftp/ncftp_3.2.5.bb
index 40b59a4..893eacb 100644
--- a/meta-networking/recipes-daemons/ncftp/ncftp_3.2.5.bb
+++ b/meta-networking/recipes-daemons/ncftp/ncftp_3.2.5.bb
@@ -5,12 +5,17 @@ LICENSE = "ClArtistic"
 LIC_FILES_CHKSUM = 
"file://ncftp/cmds.c;beginline=3;endline=4;md5=9de76faeaedc4f908082e3f8142715f4"
 DEPENDS = "ncurses"
 
-SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.orig.tar.gz"
+SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.orig.tar.gz \
+   file://ncftp-configure-use-BUILD_CC-for-ccdv.patch \
+"
 SRC_URI[md5sum] = "685e45f60ac11c89442c572c28af4228"
 SRC_URI[sha256sum] = 
"ac111b71112382853b2835c42ebe7bd59acb7f85dd00d44b2c19fbd074a436c4"
 
 inherit autotools-brokensep pkgconfig
 
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[ccdv] = "--enable-ccdv,--disable-ccdv,,"
+
 do_configure() {
 oe_runconf
 }
-- 
2.3.5

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH v2] libsoc: upgrade from version 0.6 to 0.7

[Koen Kooi]

> Op 22 nov. 2015, om 19:05 heeft Fathi Boudra  het 
> volgende geschreven:
> 
> update SRCREV
> 
> Signed-off-by: Fathi Boudra 
> ---
> changes from v1:
>  * don't ship board configs
>  * don't oe-stylize
> 
> meta-oe/recipes-support/libsoc/{libsoc_0.6.bb => libsoc_0.7.bb} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename meta-oe/recipes-support/libsoc/{libsoc_0.6.bb => libsoc_0.7.bb} (90%)
> 
> diff --git a/meta-oe/recipes-support/libsoc/libsoc_0.6.bb 
> b/meta-oe/recipes-support/libsoc/libsoc_0.7.bb
> similarity index 90%
> rename from meta-oe/recipes-support/libsoc/libsoc_0.6.bb
> rename to meta-oe/recipes-support/libsoc/libsoc_0.7.bb
> index 79c171a..3b7436f 100644
> --- a/meta-oe/recipes-support/libsoc/libsoc_0.6.bb
> +++ b/meta-oe/recipes-support/libsoc/libsoc_0.7.bb
> @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=e0bfebea12a71895ba987b2126a5"
> 
> inherit autotools
> 
> -SRCREV = "3643cf161a4b37bfbdfd05437166c4a29ac3ed8d"
> +SRCREV = "4d5c5af71e225cc4e792d2166da3f3e432b08735"
> SRC_URI = "git://github.com/jackmitch/libsoc.git"
> 
> S = "${WORKDIR}/git"
> — 

Looks good to me:

Reviewed-by: Koen Kooi 
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] OE Changelog since 2015-11-22 until 2015-11-29

[cliff . brake]

Changelog since 2015-11-22 until 2015-11-29.  Projects included in this report:

bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://github.com/Angstrom-distribution/meta-angstrom.git
meta-arago: git://arago-project.org/git/meta-arago.git
meta-atmel: https://github.com/linux4sam/meta-atmel.git
meta-beagleboard: git://github.com/beagleboard/meta-beagleboard.git
meta-browser: git://github.com/OSSystems/meta-browser.git
meta-bug: git://github.com/buglabs/meta-bug.git
meta-chicken: git://github.com/OSSystems/meta-chicken
meta-efikamx: git://github.com/kraj/meta-efikamx.git
meta-ettus: http://github.com/koenkooi/meta-ettus.git
meta-fsl-arm: git://git.yoctoproject.org/meta-fsl-arm
meta-fsl-arm-extra: git://github.com/Freescale/meta-fsl-arm-extra.git
meta-fsl-ppc: git://git.yoctoproject.org/meta-fsl-ppc
meta-guacamayo: git://github.com/Guacamayo/meta-guacamayo.git
meta-gumstix: git://github.com/gumstix/meta-gumstix.git
meta-gumstix-community: 
https://github.com/schnitzeltony/meta-gumstix-community.git
meta-handheld: git://git.openembedded.org/meta-handheld
meta-igep: http://github.com/ebutera/meta-igep.git
meta-intel: git://git.yoctoproject.org/meta-intel
meta-ivi: git://git.yoctoproject.org/meta-ivi
meta-java: git://github.com/woglinde/meta-java
meta-jetson-tk1: https://github.com/cubicool/meta-jetson-tk1.git
meta-kde: git://gitorious.org/openembedded-core-layers/meta-kde.git
meta-micro: git://git.openembedded.org/meta-micro
meta-mono: git://git.yoctoproject.org/meta-mono.git
meta-netbookpro: git://github.com/tworaz/meta-netbookpro
meta-nodejs: https://github.com/imyller/meta-nodejs.git
meta-nslu2: git://github.com/kraj/meta-nslu2
meta-opie: git://git.openembedded.org/meta-opie
meta-qt3: git://git.yoctoproject.org/meta-qt3
meta-qt5: git://github.com/meta-qt5/meta-qt5.git
meta-slugos: git://github.com/kraj/meta-slugos
meta-systemd: git://git.yoctoproject.org/meta-systemd
meta-raspberrypi: git://github.com/djwillis/meta-raspberrypi.git
meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git
meta-ti: git://git.yoctoproject.org/meta-ti
meta-webos: git://github.com/openwebos/meta-webos.git
meta-xilinx: git://git.yoctoproject.org/meta-xilinx
meta-yocto: git://git.yoctoproject.org/meta-yocto
openembedded: git://git.openembedded.org/openembedded


Changelog for bitbake:


Changelog for openembedded-core:

Alejandro Hernandez (1):
  archiver.bbclass: fix previous issue regarding work-shared for linux-yocto

Alejandro del Castillo (1):
  opkg: add cache filename length fixes

Andre McCurdy (1):
  boost.inc: remove unused parameter from get_boost_parallel_make()

Armin Kuster (1):
  libxml2: fix CVE-2015-7942 and CVE-2015-8035

Chen Qi (1):
  mktemp: raise the priority to avoid conflicting with coreutils

Christopher Larson (15):
  image_types: improve wks path specification
  qemu.bbclass: correct the fsl ppc QEMU_EXTRAOPTIONS
  qemu.bbclass: fix vardeps of QEMU_OPTIONS
  recipetool.append: don't choke on a trailing ; in a url
  systemd: for valgrind, define VALGRIND=1
  systemd: chown hwdb.bin to root:root for do_rootfs
  systemd: drop unneeded $D check in prerm
  sysprof: use packageconfig for the gui
  bluez5: enable sysvinit support
  blkspace: fix ldflags for iowatcher
  tcf-agent: obey LDFLAGS
  latencytop: obey LDFLAGS
  connman: depend on readline
  sysklogd: inhibit updatercd for non-sysvinit
  openjade-native: statically link local libs

Dan McGregor (2):
  systemd: ignore .so filenames in systemd-doc
  systemd: add machine-id to conffiles

Daniel Istrate (2):
  oeqa/selftest/signing: New test for Signing packages in the package feeds.
  oeqa/selftest/signing: Added new test for signing sstate.

Daniel McGregor (1):
  systemd: make coredump a PACKAGECONFIG

Enrico Scholz (1):
  waf.bbclass: filter out non -j from PARALLEL_MAKE

Hongxu Jia (3):
  perl: fix spaces in brackets while using CC version
  flex: fix test-bison-yylval and test-bison-yylloc failed
  logrotate: do not move binary logrotate to /usr/bin

Ioan-Adrian Ratiu (1):
  base-files: stage /etc/skel

Jens Rehsack (3):
  kernel: fix race condition between compile_kernelmodules and shared_workdir
  autotools: Allow recipe-individual configure scripts
  libusb1: upgrade from 1.0.19 to 1.0.20

Jian Liu (2):
  archiver.bbclass: add bbappend when do_ar_recipe kernel and gcc packages
  insane.bbclass: Avoid libdir QA check if PACKAGE_DEBUG_SPLIT_STYLE='debug-fi

Joe Slater (1):
  libsecret: add dependency on intltool-native

Juro Bystricky (1):
  gcc-4.9: Fix various _FOR_BUILD and related variables

Jussi Kukkonen (28):
  qemu: Backport malloc-trace disabling
  glib-2.0: Upgrade 2.44.1 -> 2.46.1
  glib-2.0: Enable more tests while cross-compiling
  glib-networking: Upgrade 2.44.0 -> 2.46.1
  atk: 

Re: [oe] [OE-core] Patchwork & patch handling improvements

[Trevor Woerner]

On 11/26/15 16:00, Paul Eggleton wrote:
> I'm also 
> trying to ensure that the patch validation is generic enough so it can live 
> in 
> OE-Core, and thus we can easily update and refine it over time in line with 
> the 
> code itself as well as encourage submitters to use the script on their own 
> changes before sending.

This all sounds like an improvement and is therefore a step in the right
direction :-)

A while back I had the idea of "porting" the kernel's "checkpatch.pl" to
The Yocto Project (it was around the same time that I was trying to
float the whole "Maintainers File" idea too, since I was also trying to
re-purpose "get-maintainer.pl" as well). About one minute into that
effort I realized the existing *.bb files were all over the place in
terms of the order of statements and the order of the blocks of
statements. At that time I found one recipe style guide from OE, and
another one from The Yocto Project, each of which described a slightly
different preference. So I asked on the mailing list and quickly
discovered that both groups prefer a different style.

I'm not saying this job isn't worth doing, but I am pointing out there's
the potential for feathers to be ruffled on both sides if someone tries
to produce a definitive style guide for recipe files and then enforces
it in an automated way. Since it is the OpenEmbedded Project's job to
provide the recipes for The Yocto Project, I'm guessing this question
needs to be decided by them? If that sounds reasonable, then maybe The
Yocto Project needs to acquiesce to OE's decision?

Instead of cross-posting, maybe this would be a good email for the new
architecture list (CC'ed)?
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [yocto] RFC: Reference updater filesystem

[Jens Rehsack]

> Am 23.11.2015 um 22:15 schrieb Mariano Lopez :
> 
> There has been interest in an image based software updater in Yocto Project. 
> The proposed solution for a image based updater is to use Stefano Babic's 
> software updater (http://sbabic.github.io/swupdate). This software do a 
> binary copy, so it is needed to have at least two partitions, these 
> partitions would be the rootfs and the maintenance partition. The rootfs it's 
> the main partition used to boot during the normal device operation, on the 
> other hand, the maintenance will be used to update the main partition.
> 
> To update the system, the user has to connect to device and boot in the 
> maintenance partition; once in the maintenance partition the software updater 
> will copy the new image in the rootfs partition. A final reboot into the 
> rootfs it is necessary to complete the upgrade.
> 
> As mentioned before the the software will copy an image to the partition, so 
> everything in that partition will be wiped out, including custom 
> configurations. To avoid the loss of configuration I explore three different 
> solutions:
> 1. Use a separate partition for the configuration.
>  a. The pro of this method is the partition is not touched during the update.
>  b. The con of this method is the configuration is not directly in rootfs 
> (example: /etc).
> 
> 2. Do the backup during the update.
>  a. The pro is the configuration is directly in rootfs.
>  b. The con is If the update fail most likely the configuration would be lost.
> 
> 3. Have an OverlayFS for the rootfs or the partition that have the 
> configuration.
>  a. The pro is the configuration is  "directly" in rootfs.
>  b. The con is there is need to provide a custom init to guarantee the 
> Overlay is mounted before the boot process.
> 
> With the above information I'm proposing to use a separate partition for the 
> configuration; this is because is more reliable and doesn't require big 
> changes in the current architecture.
> 
> So, the idea is to have 4 partitions in the media:
> 1. boot. This is the usual boot partition
> 2. data. This will hold the configuration files. Not modified by updates.
> 3. maintenance. This partition will be used to update rootfs.
> 4. rootfs. Partition used for normal operation.

That's what we currently have implemented and running in field for a while with 
a small difference:

1) We don't use Stefano Babic's software updater, but an own script which deals 
with initial software flash and later update similar - 
https://github.com/rdm-dev/meta-jens/tree/jethro/recipes-rdm/prd
2) We have integrated the updater with an update-service which can download the 
new image and install based on a manifest (signature support comes with next 
update) - 
https://github.com/rdm-dev/meta-jens/tree/jethro/recipes-rdm/system-image // 
http://www.netbsd.org/~sno/talks/nrpm/Moo-at-System-Image-Update.pdf
3) We use

boot
rootfs
maintfs
data

This layout allows us to extend data to fit the entire storage with know sizes 
for boot, rootfs and maintfs

4) Overlayfs with all serices is implemented (Update-wise, when coming from 
3.10 to 3.18 or coming from 3.0 with unionfs to overlay ...) - 
https://github.com/rdm-dev/meta-jens/tree/jethro/recipes-core/initoverlay

Feel free to use that solution if you want.

Cheers
-- 
Jens Rehsack - rehs...@gmail.com

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] Patchwork & patch handling improvements

[Paul Eggleton]

Hi Trevor,

On Mon, 30 Nov 2015 10:19:35 Trevor Woerner wrote:
> On 11/26/15 16:00, Paul Eggleton wrote:
> > I'm also
> > trying to ensure that the patch validation is generic enough so it can
> > live in OE-Core, and thus we can easily update and refine it over time in
> > line with the code itself as well as encourage submitters to use the
> > script on their own changes before sending.
> 
> This all sounds like an improvement and is therefore a step in the right
> direction :-)
> 
> A while back I had the idea of "porting" the kernel's "checkpatch.pl" to
> The Yocto Project (it was around the same time that I was trying to
> float the whole "Maintainers File" idea too, since I was also trying to
> re-purpose "get-maintainer.pl" as well). About one minute into that
> effort I realized the existing *.bb files were all over the place in
> terms of the order of statements and the order of the blocks of
> statements. At that time I found one recipe style guide from OE, and
> another one from The Yocto Project, each of which described a slightly
> different preference. So I asked on the mailing list and quickly
> discovered that both groups prefer a different style.
> 
> I'm not saying this job isn't worth doing, but I am pointing out there's
> the potential for feathers to be ruffled on both sides if someone tries
> to produce a definitive style guide for recipe files and then enforces
> it in an automated way. Since it is the OpenEmbedded Project's job to
> provide the recipes for The Yocto Project, I'm guessing this question
> needs to be decided by them? If that sounds reasonable, then maybe The
> Yocto Project needs to acquiesce to OE's decision?

I don't think there's that much of a division. I don't recall if it was you 
that raised it at the time but the issue of having two style guides did get 
rectified - I changed the one on the Yocto Project wiki to simply be a link to 
the OE style guide in June last year. It certainly didn't come about through a 
conscious decision to have a different style.

However there is a minor disagreement over indentation for shell functions 
between OE-Core and other layers - this persists because of the backporting 
pain a blanket replacement would potentially lead to. As I recall this did get 
discussed at the OE TSC level. I think that's one thing we could just not 
evaluate (or make an option) until such time as we resolve the difference - and 
I do mean to see it resolved at some point in the future.

> Instead of cross-posting, maybe this would be a good email for the new
> architecture list (CC'ed)?

Perhaps yes; I'm a bit concerned that list still doesn't have that many 
subscribers though (currently 28, two of which are the same person).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [yocto] RFC: Reference updater filesystem

[Jens Rehsack]

> 2015-11-30 14:10 GMT-02:00 Jens Rehsack :
>> 
>>> Am 23.11.2015 um 22:15 schrieb Mariano Lopez :
>>> 
>>> There has been interest in an image based software updater in Yocto 
>>> Project. The proposed solution for a image based updater is to use Stefano 
>>> Babic's software updater (http://sbabic.github.io/swupdate). This software 
>>> do a binary copy, so it is needed to have at least two partitions, these 
>>> partitions would be the rootfs and the maintenance partition. The rootfs 
>>> it's the main partition used to boot during the normal device operation, on 
>>> the other hand, the maintenance will be used to update the main partition.
>>> 
>>> To update the system, the user has to connect to device and boot in the 
>>> maintenance partition; once in the maintenance partition the software 
>>> updater will copy the new image in the rootfs partition. A final reboot 
>>> into the rootfs it is necessary to complete the upgrade.
>>> 
>>> As mentioned before the the software will copy an image to the partition, 
>>> so everything in that partition will be wiped out, including custom 
>>> configurations. To avoid the loss of configuration I explore three 
>>> different solutions:
>>> 1. Use a separate partition for the configuration.
>>> a. The pro of this method is the partition is not touched during the update.
>>> b. The con of this method is the configuration is not directly in rootfs 
>>> (example: /etc).
>>> 
>>> 2. Do the backup during the update.
>>> a. The pro is the configuration is directly in rootfs.
>>> b. The con is If the update fail most likely the configuration would be 
>>> lost.
>>> 
>>> 3. Have an OverlayFS for the rootfs or the partition that have the 
>>> configuration.
>>> a. The pro is the configuration is  "directly" in rootfs.
>>> b. The con is there is need to provide a custom init to guarantee the 
>>> Overlay is mounted before the boot process.
>>> 
>>> With the above information I'm proposing to use a separate partition for 
>>> the configuration; this is because is more reliable and doesn't require big 
>>> changes in the current architecture.
>>> 
>>> So, the idea is to have 4 partitions in the media:
>>> 1. boot. This is the usual boot partition
>>> 2. data. This will hold the configuration files. Not modified by updates.
>>> 3. maintenance. This partition will be used to update rootfs.
>>> 4. rootfs. Partition used for normal operation.
>> 
>> That's what we currently have implemented and running in field for a while 
>> with a small difference:
>> 
>> 1) We don't use Stefano Babic's software updater, but an own script which 
>> deals with initial software flash and later update similar - 
>> https://github.com/rdm-dev/meta-jens/tree/jethro/recipes-rdm/prd
>> 2) We have integrated the updater with an update-service which can download 
>> the new image and install based on a manifest (signature support comes with 
>> next update) - 
>> https://github.com/rdm-dev/meta-jens/tree/jethro/recipes-rdm/system-image // 
>> http://www.netbsd.org/~sno/talks/nrpm/Moo-at-System-Image-Update.pdf
>> 3) We use
>> 
>> boot
>> rootfs
>> maintfs
>> data
>> 
>> This layout allows us to extend data to fit the entire storage with know 
>> sizes for boot, rootfs and maintfs
>> 
>> 4) Overlayfs with all serices is implemented (Update-wise, when coming from 
>> 3.10 to 3.18 or coming from 3.0 with unionfs to overlay ...) - 
>> https://github.com/rdm-dev/meta-jens/tree/jethro/recipes-core/initoverlay
>> 
>> Feel free to use that solution if you want.

> Am 30.11.2015 um 17:54 schrieb Daniel. :
> 
> Hi,
> 
> Hey Jen, I was looking for an image upgrade solution and factory reset
> solution using overlayfs. The idea have two partitions one read-only
> with the factory image, other to hold the changes that were made by
> time. The factory reset feature should be triggered by a hided button
> that can be pressed with help of a clips. I was thinking in using an
> init ram disk to wipe out the rw partition, making the rootfs clean as
> after an image installation. The upgrader tool shold re-flash a new
> image to rootfs. Old rootfs is lost. The configuration changes that
> have been holded by overlayfs should be wiped-out too, I didn't think
> about that, is something to take in account.
> 
> Are you using overlayfs? How is it going? What difficulties you have found?

Yes, we do. All difficulties we'd found are solved in referred initoverlay
recipe. Maybe one fine I write a blog post regarding that topic ;)

> Other solution whould be using Smart package manager to upgrade the
> rootfs, but this doesn't attend my need for factory-reset.

How does that fit into an ro rootfs?

> Please tell me more about your experience with overlayfs :)

It's more stable than unionfs. There was little effort updating
systems from 3.10 with overlay patch to 4.1 with overlay builtin
kernel (work dirs must be created - 

Re: [oe] [meta-networking][PATCH] postfix.inc: fix start postfix failed while hostname is numeric

[Joe MacDonald]

[[oe] [meta-networking][PATCH] postfix.inc: fix start postfix failed while 
hostname is numeric] On 15.11.26 (Thu 18:36) Hongxu Jia wrote:

> While hostname is numeric, start postfix failed
> ...
> root@localhost:~# hostname
> 128.224.163.251
> root@localhost:~# postfix start
> postfix: warning: valid_hostname: numeric hostname: 128.224.163.251
> postfix: fatal: unable to use my own hostname
> ...
> 
> The postfix define a macro SLOPPY_VALID_HOSTNAME to allow the
> numeric hostname.

This seems like it's asking for a lot of trouble, if you either assign
your hostname to '128.224.163.251' (as it appears to be in your commit
log, but I don't know off-hand how you'd do that without writing a
program specifically for that purpose, and even then ...) or if you
assign your hostname to be '128' and the FQDN to be '128.224.163.251'.
Certainly the postfix folks think this is a sufficiently unusual and
presumably hazzard-prone to make it not even a runtime option but a
compile-time one.

Are you sure the issue you're trying to solve here won't be resolved by
applying [] throughout your .cf files?  I'm reluctant to take this patch
since it turns on a surprising feature that, my sense is, is not
desirable in common setups.

-J.

> 
> Signed-off-by: Hongxu Jia 
> ---
>  meta-networking/recipes-daemons/postfix/postfix.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-networking/recipes-daemons/postfix/postfix.inc 
> b/meta-networking/recipes-daemons/postfix/postfix.inc
> index 6d39570..f8b8e43 100644
> --- a/meta-networking/recipes-daemons/postfix/postfix.inc
> +++ b/meta-networking/recipes-daemons/postfix/postfix.inc
> @@ -67,7 +67,7 @@ export CCARGS-sasl_class-native = ""
>  export AUXLIBS-sasl_class-native = ""
>  
>  # PCRE, TLS support default
> -export CCARGS  = "${CFLAGS} -DHAS_PCRE -DUSE_TLS ${CCARGS-ldap} 
> ${CCARGS-sasl}"
> +export CCARGS  = "${CFLAGS} -DHAS_PCRE -DUSE_TLS -DSLOPPY_VALID_HOSTNAME 
> ${CCARGS-ldap} ${CCARGS-sasl}"
>  export AUXLIBS = "-lpcre -lssl -lcrypto ${AUXLIBS-sasl} ${AUXLIBS-ldap}"
>  export POSTCONF = "${STAGING_DIR_NATIVE}${sbindir_native}/postconf"
>  
> -- 
> 1.9.1
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6

[Joe MacDonald]

Hi Kai,

Can you re-submit this based on the long-lingering merge of my xl2tpd
upgrade now in master?

-J.

[[oe] [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6] On 15.11.30 (Mon 15:38) 
kai.k...@windriver.com wrote:

> From: Kai Kang 
> 
> Upgrade xl2tpd v1.3.0-46-gdf7e30e to 1.3.6.
> 
> * drop PR
> * add patch to fix build warnings with gcc 5.x:
> 
> | misc.h:68:20: warning: inline function 'swaps' declared but never defined
> 
> Signed-off-by: Kai Kang 
> ---
>  .../recipes-protocols/xl2tpd/xl2tpd.inc|   2 -
>  .../fix-inline-functions-errors-with-gcc-5.x.patch | 134 
> +
>  .../xl2tpd/{xl2tpd_git.bb => xl2tpd_1.3.6.bb}  |   4 +-
>  3 files changed, 136 insertions(+), 4 deletions(-)
>  create mode 100644 
> meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
>  rename meta-networking/recipes-protocols/xl2tpd/{xl2tpd_git.bb => 
> xl2tpd_1.3.6.bb} (15%)
> 
> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc 
> b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
> index ffec167..d2402c5 100644
> --- a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
> +++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
> @@ -8,8 +8,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
>  LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=0636e73ff0215e8d672dc4c32c317bb3"
>  
> -INC_PR = "r0"
> -
>  SRC_URI = "git://github.com/xelerance/xl2tpd.git"
>  
>  S = "${WORKDIR}/git"
> diff --git 
> a/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
>  
> b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
> new file mode 100644
> index 000..b75c912
> --- /dev/null
> +++ 
> b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
> @@ -0,0 +1,134 @@
> +Upstream-Status: Backport
> +
> +Backport from 
> https://github.com/xelerance/xl2tpd/commit/9098f64950eb22cf049058d40f647bafdb822174
> +
> +Signed-off-by: Kai Kang 
> +---
> +From 9098f64950eb22cf049058d40f647bafdb822174 Mon Sep 17 00:00:00 2001
> +From: Kai Kang 
> +Date: Wed, 23 Sep 2015 10:41:05 +0800
> +Subject: [PATCH] Fix build errors caused by inline function with gcc 5
> +
> +GCC 5 defaults to -std=gnu11 instead of -std=gnu89. And -std=gnu89
> +employs the GNU89 inline semantics, -std=gnu11 uses the C99 inline
> +semantics.
> +
> +For 'inline' fuction, it is NOT exported by C99. So error messages such as:
> +
> +| control.c:1717: undefined reference to `check_control'
> +
> +For these functions which is not referred by other compile units, make
> +them 'static inline'.
> +
> +For 'extern inline' function, it fails such as:
> +
> +| misc.h:68:20: warning: inline function 'swaps' declared but never defined
> +|  extern inline void swaps (void *, int);
> +|  ^
> +
> +Because function swaps() is referred by other compile units, it must be
> +exported. The semantics of 'extern inline' are not same between GNU89
> +and C99, so remove 'inline' attribute for compatible with GNU89.
> +
> +Ref:
> +https://gcc.gnu.org/gcc-5/porting_to.html
> +
> +Signed-off-by: Kai Kang 
> +---
> + control.c | 8 
> + misc.c| 2 +-
> + misc.h| 2 +-
> + network.c | 4 ++--
> + 4 files changed, 8 insertions(+), 8 deletions(-)
> +
> +diff --git a/control.c b/control.c
> +index b2891a9..c4a39b5 100644
> +--- a/control.c
>  b/control.c
> +@@ -1140,7 +1140,7 @@ int control_finish (struct tunnel *t, struct call *c)
> + return 0;
> + }
> + 
> +-inline int check_control (const struct buffer *buf, struct tunnel *t,
> ++static inline int check_control (const struct buffer *buf, struct tunnel *t,
> +   struct call *c)
> + {
> + /*
> +@@ -1276,7 +1276,7 @@ inline int check_control (const struct buffer *buf, 
> struct tunnel *t,
> + return 0;
> + }
> + 
> +-inline int check_payload (struct buffer *buf, struct tunnel *t,
> ++static inline int check_payload (struct buffer *buf, struct tunnel *t,
> +   struct call *c)
> + {
> + /*
> +@@ -1382,7 +1382,7 @@ inline int check_payload (struct buffer *buf, struct 
> tunnel *t,
> + #endif
> + return 0;
> + }
> +-inline int expand_payload (struct buffer *buf, struct tunnel *t,
> ++static inline int expand_payload (struct buffer *buf, struct tunnel *t,
> +struct call *c)
> + {
> + /*
> +@@ -1562,7 +1562,7 @@ void send_zlb (void *data)
> + toss (buf);
> + }
> + 
> +-inline int write_packet (struct buffer *buf, struct tunnel *t, struct call 
> *c,
> ++static inline int write_packet (struct buffer *buf, struct tunnel *t, 
> struct call *c,
> +  int convert)
> + {
> + /*
> +diff --git a/misc.c b/misc.c
> +index 3092401..af90dbf 100644
> +--- a/misc.c
>  b/misc.c
> 

Re: [oe] [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6

[Kang Kai]

On 2015年12月01日 10:00, Joe MacDonald wrote:

Hi Kai,

Can you re-submit this based on the long-lingering merge of my xl2tpd
upgrade now in master?


OK. V2 will be sent.

--Kai




-J.

[[oe] [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6] On 15.11.30 (Mon 15:38) 
kai.k...@windriver.com wrote:


From: Kai Kang 

Upgrade xl2tpd v1.3.0-46-gdf7e30e to 1.3.6.

* drop PR
* add patch to fix build warnings with gcc 5.x:

| misc.h:68:20: warning: inline function 'swaps' declared but never defined

Signed-off-by: Kai Kang 
---
  .../recipes-protocols/xl2tpd/xl2tpd.inc|   2 -
  .../fix-inline-functions-errors-with-gcc-5.x.patch | 134 +
  .../xl2tpd/{xl2tpd_git.bb => xl2tpd_1.3.6.bb}  |   4 +-
  3 files changed, 136 insertions(+), 4 deletions(-)
  create mode 100644 
meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
  rename meta-networking/recipes-protocols/xl2tpd/{xl2tpd_git.bb => 
xl2tpd_1.3.6.bb} (15%)

diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc 
b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
index ffec167..d2402c5 100644
--- a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
+++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
@@ -8,8 +8,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
  LICENSE = "GPLv2"
  LIC_FILES_CHKSUM = "file://LICENSE;md5=0636e73ff0215e8d672dc4c32c317bb3"
  
-INC_PR = "r0"

-
  SRC_URI = "git://github.com/xelerance/xl2tpd.git"
  
  S = "${WORKDIR}/git"

diff --git 
a/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
 
b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
new file mode 100644
index 000..b75c912
--- /dev/null
+++ 
b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
@@ -0,0 +1,134 @@
+Upstream-Status: Backport
+
+Backport from 
https://github.com/xelerance/xl2tpd/commit/9098f64950eb22cf049058d40f647bafdb822174
+
+Signed-off-by: Kai Kang 
+---
+From 9098f64950eb22cf049058d40f647bafdb822174 Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Wed, 23 Sep 2015 10:41:05 +0800
+Subject: [PATCH] Fix build errors caused by inline function with gcc 5
+
+GCC 5 defaults to -std=gnu11 instead of -std=gnu89. And -std=gnu89
+employs the GNU89 inline semantics, -std=gnu11 uses the C99 inline
+semantics.
+
+For 'inline' fuction, it is NOT exported by C99. So error messages such as:
+
+| control.c:1717: undefined reference to `check_control'
+
+For these functions which is not referred by other compile units, make
+them 'static inline'.
+
+For 'extern inline' function, it fails such as:
+
+| misc.h:68:20: warning: inline function 'swaps' declared but never defined
+|  extern inline void swaps (void *, int);
+|  ^
+
+Because function swaps() is referred by other compile units, it must be
+exported. The semantics of 'extern inline' are not same between GNU89
+and C99, so remove 'inline' attribute for compatible with GNU89.
+
+Ref:
+https://gcc.gnu.org/gcc-5/porting_to.html
+
+Signed-off-by: Kai Kang 
+---
+ control.c | 8 
+ misc.c| 2 +-
+ misc.h| 2 +-
+ network.c | 4 ++--
+ 4 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/control.c b/control.c
+index b2891a9..c4a39b5 100644
+--- a/control.c
 b/control.c
+@@ -1140,7 +1140,7 @@ int control_finish (struct tunnel *t, struct call *c)
+ return 0;
+ }
+
+-inline int check_control (const struct buffer *buf, struct tunnel *t,
++static inline int check_control (const struct buffer *buf, struct tunnel *t,
+   struct call *c)
+ {
+ /*
+@@ -1276,7 +1276,7 @@ inline int check_control (const struct buffer *buf, 
struct tunnel *t,
+ return 0;
+ }
+
+-inline int check_payload (struct buffer *buf, struct tunnel *t,
++static inline int check_payload (struct buffer *buf, struct tunnel *t,
+   struct call *c)
+ {
+ /*
+@@ -1382,7 +1382,7 @@ inline int check_payload (struct buffer *buf, struct 
tunnel *t,
+ #endif
+ return 0;
+ }
+-inline int expand_payload (struct buffer *buf, struct tunnel *t,
++static inline int expand_payload (struct buffer *buf, struct tunnel *t,
+struct call *c)
+ {
+ /*
+@@ -1562,7 +1562,7 @@ void send_zlb (void *data)
+ toss (buf);
+ }
+
+-inline int write_packet (struct buffer *buf, struct tunnel *t, struct call *c,
++static inline int write_packet (struct buffer *buf, struct tunnel *t, struct 
call *c,
+  int convert)
+ {
+ /*
+diff --git a/misc.c b/misc.c
+index 3092401..af90dbf 100644
+--- a/misc.c
 b/misc.c
+@@ -170,7 +170,7 @@ void do_packet_dump (struct buffer *buf)
+ printf ("}\n");
+ }
+
+-inline void swaps (void *buf_v, int len)
++void swaps (void *buf_v, int len)
+ {
+ #ifdef 

Re: [oe] [meta-python][PATCH] python-cryptography, python-cryptography-vectors: uprev

[Tim Orling]

> On Nov 30, 2015, at 7:01 PM, Mark Asselstine  
> wrote:
> 
> On Sat, Nov 28, 2015 at 9:35 AM, Mark Asselstine
>  wrote:
>> On Wed, Nov 25, 2015 at 3:11 AM, Anders Darander  
>> wrote:
>>> * Tim Orling  [151124 19:00]:
>>> 
 We have never carried a license in meta-python, rather we use the
 common-licenses from oe-core (
 http://git.openembedded.org/openembedded-core/tree/meta/files/common-licenses
 ).
>>> 
>>> Does the Unicode license exist under another name in oe-core? Otherwise,
>>> I'd assume that Mark did the right thing to add it here.
>> 
>> I will look around to see that it is not duplication. I will also try
>> to assess the number of projects out there that might eventually be
>> added to oe that would warrant us putting this in 'common-licenses'
>> off the bat.
> 
> I have looked around and still feel this is the best place for the
> license file. At any rate let me know if I should change this commit
> and I will gladly make needed adjustments.
> 
That's fine by me. I just wanted to voice my concern, as this does set a 
precedent for the layer. I also wanted some discussion on the topic. We've now 
had time for that. We can always move the license file later if that becomes 
desirable.

Thank you for investigating.

--Tim

> Thanks,
> Mark
> 
>> 
>> Mark
>> 
>>> 
>>> Cheers,
>>> Anders
>>> 
 Regards,
>>> 
 --Tim
>>> 
 On Mon, Nov 23, 2015 at 9:13 AM, Mark Asselstine <
 mark.asselst...@windriver.com> wrote:
>>> 
>>> --
>>> Anders Darander, Senior System Architect
>>> ChargeStorm AB / eStorm AB
>>> --
>>> ___
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-python][PATCH] python-cryptography, python-cryptography-vectors: uprev

[Mark Asselstine]

On Sat, Nov 28, 2015 at 9:35 AM, Mark Asselstine
 wrote:
> On Wed, Nov 25, 2015 at 3:11 AM, Anders Darander  
> wrote:
>> * Tim Orling  [151124 19:00]:
>>
>>> We have never carried a license in meta-python, rather we use the
>>> common-licenses from oe-core (
>>> http://git.openembedded.org/openembedded-core/tree/meta/files/common-licenses
>>> ).
>>
>> Does the Unicode license exist under another name in oe-core? Otherwise,
>> I'd assume that Mark did the right thing to add it here.
>
> I will look around to see that it is not duplication. I will also try
> to assess the number of projects out there that might eventually be
> added to oe that would warrant us putting this in 'common-licenses'
> off the bat.

I have looked around and still feel this is the best place for the
license file. At any rate let me know if I should change this commit
and I will gladly make needed adjustments.

Thanks,
Mark

>
> Mark
>
>>
>> Cheers,
>> Anders
>>
>>> Regards,
>>
>>> --Tim
>>
>>> On Mon, Nov 23, 2015 at 9:13 AM, Mark Asselstine <
>>> mark.asselst...@windriver.com> wrote:
>>
>> --
>> Anders Darander, Senior System Architect
>> ChargeStorm AB / eStorm AB
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-browser][PATCH] chromium: fix gcc5 compile issues

[Ian Coolidge]

I'm getting segfaults when I run google-chrome on my nitrogen6x after the
new updates. Compiles great, just segfaults. Anyone else noticing similar
problems? I'll be digging into it more, thought I'd reach out first though.

Thanks,
-Ian

On Fri, Nov 6, 2015 at 11:58 AM, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> On Fri, Nov 6, 2015 at 5:51 PM, Max Krummenacher 
> wrote:
> > Hi
> > Am Freitag, den 06.11.2015, 18:17 +0100 schrieb Martin Jansa:
> >
> >> After long time first successful chromium build in bitbake world..
> >> Thanks!
> >>
> >> Can you apply the same fix for cef3 recipes?
> >> http://errors.yoctoproject.org/Errors/Details/21442/
> >>
> >> cef3 for qemux86-64 doesn't even configure:
> >> http://errors.yoctoproject.org/Errors/Details/21501/
> >>
> > I'll try to fix this.
> >
> > It looks like this never worked for x86-64 because of a missing config
> > file.
> > One probably can reuse the i568 one.
> >
> > There seem to be additional errors to the one fixed with the packages.
> > So
> > maybe I won't be able to fix it.
>
> Send a complete patchset and we apply them all ;-)
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH v2] libsoc: upgrade from version 0.6 to 0.7

[Jack Mitchell]

On 22/11/15 18:05, Fathi Boudra wrote:

update SRCREV

Signed-off-by: Fathi Boudra 
---
  changes from v1:
   * don't ship board configs
   * don't oe-stylize

  meta-oe/recipes-support/libsoc/{libsoc_0.6.bb => libsoc_0.7.bb} | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
  rename meta-oe/recipes-support/libsoc/{libsoc_0.6.bb => libsoc_0.7.bb} (90%)

diff --git a/meta-oe/recipes-support/libsoc/libsoc_0.6.bb 
b/meta-oe/recipes-support/libsoc/libsoc_0.7.bb
similarity index 90%
rename from meta-oe/recipes-support/libsoc/libsoc_0.6.bb
rename to meta-oe/recipes-support/libsoc/libsoc_0.7.bb
index 79c171a..3b7436f 100644
--- a/meta-oe/recipes-support/libsoc/libsoc_0.6.bb
+++ b/meta-oe/recipes-support/libsoc/libsoc_0.7.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=e0bfebea12a71895ba987b2126a5"

  inherit autotools

-SRCREV = "3643cf161a4b37bfbdfd05437166c4a29ac3ed8d"
+SRCREV = "4d5c5af71e225cc4e792d2166da3f3e432b08735"
  SRC_URI = "git://github.com/jackmitch/libsoc.git"

  S = "${WORKDIR}/git"



There might be an issue building this with GCC 5.2, has this been tested? If it 
does break I can do a 0.7.1 release and we should use that with the GCC 5.2 fix 
included [1].


Cheers,
Jack

[1] 
https://github.com/jackmitch/libsoc/commit/0b863612540f67c032ef0efc417538443a00b285

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH] libjpeg-turbo: remove recipe

[Maxin B. John]

Remove libjpeg-turbo package from meta-oe as it will be moved to oe-core
to replace libjpeg package.

Signed-off-by: Maxin B. John 
---
 .../recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb| 40 --
 1 file changed, 40 deletions(-)
 delete mode 100644 meta-oe/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb

diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb 
b/meta-oe/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
deleted file mode 100644
index e79f800..000
--- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
+++ /dev/null
@@ -1,40 +0,0 @@
-DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD 
instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and 
decompression"
-HOMEPAGE = "http://libjpeg-turbo.org/;
-
-LICENSE = "BSD-3-Clause"
-LIC_FILES_CHKSUM = 
"file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
-
file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
-
file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
-"
-
-DEPENDS = "nasm-native"
-
-BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
-
-SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
-SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2"
-SRC_URI[sha256sum] = 
"4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"
-
-S = "${WORKDIR}/${BPN}-${BASEPV}"
-
-# Drop-in replacement for jpeg
-PROVIDES = "jpeg"
-RPROVIDES_${PN} += "jpeg"
-RREPLACES_${PN} += "jpeg"
-RCONFLICTS_${PN} += "jpeg"
-
-inherit autotools pkgconfig
-
-EXTRA_OECONF = "--with-jpeg8 "
-
-PACKAGES =+ "jpeg-tools libturbojpeg"
-
-DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to 
access libjpeg functionality.  These tools allow for the compression, 
decompression, transformation and display of JPEG files and benchmarking of the 
libjpeg library."
-FILES_jpeg-tools = "${bindir}/*"
-
-FILES_libturbojpeg = "${libdir}/libturbojpeg.so"
-INSANE_SKIP_libturbojpeg = "dev-so"
-
-BBCLASSEXTEND = "native"
-
-LEAD_SONAME = "libjpeg.so.8"
-- 
2.4.0

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 2/2] iscsitarget: skip the arch test for kernel modules

[Koen Kooi]

Op 25-11-15 om 09:27 schreef jackie.hu...@windriver.com:
> From: Jackie Huang 
> 
> Kernel modules may not have the same architecture as user space.

LOL

> So we tell INSANE_SKIP to skip checking the arch for the modules.
> This is consistent with other kernel modules and the kernel recipe.

Split this recipe in 2: one recipe for userspace, the other for kernel space.


-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel