Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.
On 04/12/2016 11:55 AM, Philip Tricca wrote:
Hello,
On 04/11/2016 05:54 AM, Joe MacDonald wrote:
This causes do_populate_sysroot error if build two or more types of
refpolicy:
$ bitbake refpolicy-minimum && bitbake refpolicy-mls
ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls is
trying to install files into a shared area when those files already exist.
Those files and their manifest location are:
I think this was always the intent with the series Philip submitted last
week (for reference, the thread is
https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
Isn't this (part of) the expected behaviour of the virtual provider
mechanism?
This is the question I think we need to figure out. My understanding
(quite possibly wrong) is that the virtual provider stuff would prevent
the installation of more than one provider. I hadn't considered the
implications for the sysroot.
Is the ability to install multiple providers in the sysroot expected? I
imagine that this problem must have been solved before in another
package with virtual providers that install the same file. I'm happy to
doing some digging here but if anyone knows of a good example I'd
appreciate a pointer.
We did discuss what it would mean to be trying out multiple
policies on a system at the same time and at the time it seemed like the
"just works" angle was more important than "buffet style" when it came
to providing policy on the image.
I guess the thing I like the most about setting the policy package up as
a virtual package is the ability to select the policy type as a distro
config. The virtual provider seemed like a natural fit as it's a pattern
that similar packages (kernel etc) use extensively.
It might be worth considering extending the changes to only do some
install steps at, say, do_rootfs but I don't know if that even makes
sense, this is really the first I've thought of it. I think Philip's
original changes are good, though, for our maintenance and for clients
of meta-selinux.
There may be a middle ground and I think that would be leaving the
configuration file as a separate package. Personally I liked the idea of
rolling the config file into the policy package as it was always a bit
awkward requiring coordination of some variables across the policy and
the config package which made it a bit brittle.
Wenzong: A few questions: What's your use case for building multiple
policy packages? Would you suggest just backing out the removal of the
config package or the whole virtual provider thing?
Hi Philip,
The virtual provider is OK, just restore the config package is the
simplest ways for fixing such issue I think.
My use cases include:
a. update refpolicy and build each type to make sure patch/build/install
work;
b. run world build with meta-selinux layer.
Thanks
Wenzong
Thanks,
Philip
/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
Please verify which recipe should provide the above files.
Philip,
Can you consider to withdraw the integration?
Thanks
Wenzong
On 04/04/2016 08:21 AM, Philip Tricca wrote:
With the virutal package there's no need for a separate recipe to build
the config. This can be generated and included as part of the policy
package.
Signed-off-by: Philip Tricca
---
.../packagegroups/packagegroup-core-selinux.bb | 1 -
.../packagegroups/packagegroup-selinux-minimal.bb | 1 -
recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
recipes-security/selinux/selinux-config_0.1.bb | 40 --
4 files changed, 28 insertions(+), 44 deletions(-)
delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb
diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 62c5a76..c6d22b7 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
packagegroup-selinux-policycoreutils \
setools \
setools-console \
- selinux-config \
selinux-autorelabel \
selinux-init \
selinux-labeldev \
diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
index 87ae686..451ae8b 100644
--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
@@ -21
Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.
Hello,
On 04/11/2016 05:54 AM, Joe MacDonald wrote:
>> This causes do_populate_sysroot error if build two or more types of
>> refpolicy:
>>
>> $ bitbake refpolicy-minimum && bitbake refpolicy-mls
>>
>> ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls is
>> trying to install files into a shared area when those files already exist.
>> Those files and their manifest location are:
>
> I think this was always the intent with the series Philip submitted last
> week (for reference, the thread is
> https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
> Isn't this (part of) the expected behaviour of the virtual provider
> mechanism?
This is the question I think we need to figure out. My understanding
(quite possibly wrong) is that the virtual provider stuff would prevent
the installation of more than one provider. I hadn't considered the
implications for the sysroot.
Is the ability to install multiple providers in the sysroot expected? I
imagine that this problem must have been solved before in another
package with virtual providers that install the same file. I'm happy to
doing some digging here but if anyone knows of a good example I'd
appreciate a pointer.
> We did discuss what it would mean to be trying out multiple
> policies on a system at the same time and at the time it seemed like the
> "just works" angle was more important than "buffet style" when it came
> to providing policy on the image.
I guess the thing I like the most about setting the policy package up as
a virtual package is the ability to select the policy type as a distro
config. The virtual provider seemed like a natural fit as it's a pattern
that similar packages (kernel etc) use extensively.
> It might be worth considering extending the changes to only do some
> install steps at, say, do_rootfs but I don't know if that even makes
> sense, this is really the first I've thought of it. I think Philip's
> original changes are good, though, for our maintenance and for clients
> of meta-selinux.
There may be a middle ground and I think that would be leaving the
configuration file as a separate package. Personally I liked the idea of
rolling the config file into the policy package as it was always a bit
awkward requiring coordination of some variables across the policy and
the config package which made it a bit brittle.
Wenzong: A few questions: What's your use case for building multiple
policy packages? Would you suggest just backing out the removal of the
config package or the whole virtual provider thing?
Thanks,
Philip
>> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
>> Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>>
>> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
>> Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>>
>> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
>> Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>> Please verify which recipe should provide the above files.
>>
>> Philip,
>>
>> Can you consider to withdraw the integration?
>>
>> Thanks
>> Wenzong
>>
>> On 04/04/2016 08:21 AM, Philip Tricca wrote:
>>> With the virutal package there's no need for a separate recipe to build
>>> the config. This can be generated and included as part of the policy
>>> package.
>>>
>>> Signed-off-by: Philip Tricca
>>> ---
>>> .../packagegroups/packagegroup-core-selinux.bb | 1 -
>>> .../packagegroups/packagegroup-selinux-minimal.bb | 1 -
>>> recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
>>> recipes-security/selinux/selinux-config_0.1.bb | 40
>>> --
>>> 4 files changed, 28 insertions(+), 44 deletions(-)
>>> delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb
>>>
>>> diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb
>>> b/recipes-security/packagegroups/packagegroup-core-selinux.bb
>>> index 62c5a76..c6d22b7 100644
>>> --- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
>>> +++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
>>> @@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
>>> packagegroup-selinux-policycoreutils \
>>> setools \
>>> setools-console \
>>> - selinux-config \
>>> selinux-autorelabel \
>>> selinux-init \
>>> selinux-labeldev \
>>> diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
>>> b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
>>> index 87ae686..451ae8b 100644
>>> --- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
>>> +++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
>>> @@ -21,7 +21,6 @@ RDEPENDS_${PN} = "\
>>> policycoreutils-semodule \
>>> policycoreutils-sestatus \
>>> policycoreutils-setfiles \
>>> - selinux-con
Re: [yocto] A lot of, seemingly, hung tasks
Thank you all. I'll try some more of the debugging if my current fix attempt (using the current sources rather than the tar file, and building the qemux86 first) don't work. I have 4 GBytes DRAM. I've never seen (at least not according to the Gnome system monitor) my current memory usage exceed 60%, and swap isn't getting touched at all. Ron O On Mon, Apr 11, 2016 at 7:52 PM, Chris Hallinan wrote: > I have very occasionally hit hung tasks, but I was usually able to identify > the exact task which was hanging, it was never "many". Note that some tasks > which may appear "hung" may be waiting for a dependency to complete. You > could try some brute force debugging...set these in local.conf: > > BB_NUMBER_THREADS = "1" > PARALLEL_MAKE = "-j1" > > Then try building again, and yes it will take a long time. > > if something is actually hanging, it would be useful to know what task, not > only the bitbake "task" but the actual process as reported by ps. A bitbake > "task" can spawn many processes as it works to complete it's job. > > In the past, once I found the hanging process, strace usually helped me > discover why. > > You mention a "low-end" 2-core machine...RAM is everything. If you're > running Linux out of memory, you get what you deserve > > Remember, poky-tiny refers to the resulting distribution you are building, > not the machine you want to build it on ;) > > -Chris > > > > On Mon, Apr 11, 2016 at 9:38 PM, Ronald Oakes wrote: >> >> It looks like it is hanging fairly consistently during the >> gcc-cross-initial-x86_64-5.2.0-r0 do_compile or do_install steps. >> I've tried stopping, cleaning, and just building >> gcc-cross-initial-x86_64, but it still hangs. >> >> I'm going to try a 32 bit build just to see if I can get past this. >> >> Ron Oakes >> >> On Mon, Apr 11, 2016 at 12:35 PM, Andre McCurdy >> wrote: >> > On Mon, Apr 11, 2016 at 11:22 AM, Ronald Oakes wrote: >> >> Over the weekend, I upgraded my connected development platform to >> >> Debian 8.4.0 from Centos 7. >> >> >> >> However, today I have yet to make a successful poky-tiny build for >> >> either coreI7-64 or qemux86-64. In each case, I've aborted the build >> >> after one or more tasks has stopped doing anything for 30 minutes or >> >> more. >> >> >> >> I define "stopped doing anything" as having not touched a file in 30 >> >> minutes, while the CPU utilization (on this 2 core, low end, ASUS >> >> VivoPC) drops very low. >> >> >> >> I've tried re-running the offending recipes and tasks individually, >> >> and cleaning and restarting from scratch, but I keep ending up with >> >> something hung. >> >> >> >> Any ideas what is up, and, more importantly, what I should do to >> >> resolve it? >> > >> > Have you used bitbake with the "--debug" option or run "ps axf" or >> > similar to see which tasks or commands are hanging? >> > >> >> Ron Oakes >> >> -- >> >> ___ >> >> yocto mailing list >> >> yocto@yoctoproject.org >> >> https://lists.yoctoproject.org/listinfo/yocto >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > > -- > Life is like Linux - it never stands still. > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC
On Mon, Apr 11, 2016 at 03:35:21PM -0700, Rudolf J Streif wrote: > Hello Everyone: > > If you attended OEDAM last Friday in San Diego, I very much hope that you > enjoyed being here. > > The Catamaran Hotel, where we held the meeting, would very much appreciate > your feedback: > > www.catamaranresort.com/trip > > I hope you all had a safe trip back home, And huge thanks to Rudi and Jefro for their help in organizing the event! -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A lot of, seemingly, hung tasks
I have very occasionally hit hung tasks, but I was usually able to identify the exact task which was hanging, it was never "many". Note that some tasks which may appear "hung" may be waiting for a dependency to complete. You could try some brute force debugging...set these in local.conf: BB_NUMBER_THREADS = "1" PARALLEL_MAKE = "-j1" Then try building again, and yes it will take a long time. if something is actually hanging, it would be useful to know what task, not only the bitbake "task" but the actual process as reported by ps. A bitbake "task" can spawn many processes as it works to complete it's job. In the past, once I found the hanging process, strace usually helped me discover why. You mention a "low-end" 2-core machine...RAM is everything. If you're running Linux out of memory, you get what you deserve Remember, poky-tiny refers to the resulting distribution you are building, not the machine you want to build it on ;) -Chris On Mon, Apr 11, 2016 at 9:38 PM, Ronald Oakes wrote: > It looks like it is hanging fairly consistently during the > gcc-cross-initial-x86_64-5.2.0-r0 do_compile or do_install steps. > I've tried stopping, cleaning, and just building > gcc-cross-initial-x86_64, but it still hangs. > > I'm going to try a 32 bit build just to see if I can get past this. > > Ron Oakes > > On Mon, Apr 11, 2016 at 12:35 PM, Andre McCurdy > wrote: > > On Mon, Apr 11, 2016 at 11:22 AM, Ronald Oakes wrote: > >> Over the weekend, I upgraded my connected development platform to > >> Debian 8.4.0 from Centos 7. > >> > >> However, today I have yet to make a successful poky-tiny build for > >> either coreI7-64 or qemux86-64. In each case, I've aborted the build > >> after one or more tasks has stopped doing anything for 30 minutes or > >> more. > >> > >> I define "stopped doing anything" as having not touched a file in 30 > >> minutes, while the CPU utilization (on this 2 core, low end, ASUS > >> VivoPC) drops very low. > >> > >> I've tried re-running the offending recipes and tasks individually, > >> and cleaning and restarting from scratch, but I keep ending up with > >> something hung. > >> > >> Any ideas what is up, and, more importantly, what I should do to > resolve it? > > > > Have you used bitbake with the "--debug" option or run "ps axf" or > > similar to see which tasks or commands are hanging? > > > >> Ron Oakes > >> -- > >> ___ > >> yocto mailing list > >> yocto@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/yocto > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- Life is like Linux - it never stands still. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC
do we have meeting minutes posted someplace? thanks tom On Mon, Apr 11, 2016 at 6:43 PM, Philip Balister wrote: > On 04/11/2016 09:35 PM, Denys Dmytriyenko wrote: > > On Mon, Apr 11, 2016 at 03:35:21PM -0700, Rudolf J Streif wrote: > >> Hello Everyone: > >> > >> If you attended OEDAM last Friday in San Diego, I very much hope that > you enjoyed being here. > >> > >> The Catamaran Hotel, where we held the meeting, would very much > appreciate your feedback: > >> > >> www.catamaranresort.com/trip > >> > >> I hope you all had a safe trip back home, > > > > And huge thanks to Rudi and Jefro for their help in organizing the event! > > > > And an even bigger thanks to everyone that came to the meeting. You are > the people that make OpenEmbedded great! > > Philip > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A lot of, seemingly, hung tasks
On Mon, Apr 11, 2016 at 6:38 PM, Ronald Oakes wrote: > It looks like it is hanging fairly consistently during the > gcc-cross-initial-x86_64-5.2.0-r0 do_compile or do_install steps. > I've tried stopping, cleaning, and just building > gcc-cross-initial-x86_64, but it still hangs. Did you try "ps axf" to determine exactly which commands within do_compile or do_install are hanging? Also, just as a sanity check, how much DRAM on your build system? > I'm going to try a 32 bit build just to see if I can get past this. > > Ron Oakes > > On Mon, Apr 11, 2016 at 12:35 PM, Andre McCurdy wrote: >> On Mon, Apr 11, 2016 at 11:22 AM, Ronald Oakes wrote: >>> Over the weekend, I upgraded my connected development platform to >>> Debian 8.4.0 from Centos 7. >>> >>> However, today I have yet to make a successful poky-tiny build for >>> either coreI7-64 or qemux86-64. In each case, I've aborted the build >>> after one or more tasks has stopped doing anything for 30 minutes or >>> more. >>> >>> I define "stopped doing anything" as having not touched a file in 30 >>> minutes, while the CPU utilization (on this 2 core, low end, ASUS >>> VivoPC) drops very low. >>> >>> I've tried re-running the offending recipes and tasks individually, >>> and cleaning and restarting from scratch, but I keep ending up with >>> something hung. >>> >>> Any ideas what is up, and, more importantly, what I should do to resolve it? >> >> Have you used bitbake with the "--debug" option or run "ps axf" or >> similar to see which tasks or commands are hanging? >> >>> Ron Oakes >>> -- >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC
On 04/11/2016 09:35 PM, Denys Dmytriyenko wrote: > On Mon, Apr 11, 2016 at 03:35:21PM -0700, Rudolf J Streif wrote: >> Hello Everyone: >> >> If you attended OEDAM last Friday in San Diego, I very much hope that you >> enjoyed being here. >> >> The Catamaran Hotel, where we held the meeting, would very much appreciate >> your feedback: >> >> www.catamaranresort.com/trip >> >> I hope you all had a safe trip back home, > > And huge thanks to Rudi and Jefro for their help in organizing the event! > And an even bigger thanks to everyone that came to the meeting. You are the people that make OpenEmbedded great! Philip -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A lot of, seemingly, hung tasks
It looks like it is hanging fairly consistently during the gcc-cross-initial-x86_64-5.2.0-r0 do_compile or do_install steps. I've tried stopping, cleaning, and just building gcc-cross-initial-x86_64, but it still hangs. I'm going to try a 32 bit build just to see if I can get past this. Ron Oakes On Mon, Apr 11, 2016 at 12:35 PM, Andre McCurdy wrote: > On Mon, Apr 11, 2016 at 11:22 AM, Ronald Oakes wrote: >> Over the weekend, I upgraded my connected development platform to >> Debian 8.4.0 from Centos 7. >> >> However, today I have yet to make a successful poky-tiny build for >> either coreI7-64 or qemux86-64. In each case, I've aborted the build >> after one or more tasks has stopped doing anything for 30 minutes or >> more. >> >> I define "stopped doing anything" as having not touched a file in 30 >> minutes, while the CPU utilization (on this 2 core, low end, ASUS >> VivoPC) drops very low. >> >> I've tried re-running the offending recipes and tasks individually, >> and cleaning and restarting from scratch, but I keep ending up with >> something hung. >> >> Any ideas what is up, and, more importantly, what I should do to resolve it? > > Have you used bitbake with the "--debug" option or run "ps axf" or > similar to see which tasks or commands are hanging? > >> Ron Oakes >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC
Hello Everyone: If you attended OEDAM last Friday in San Diego, I very much hope that you enjoyed being here. The Catamaran Hotel, where we held the meeting, would very much appreciate your feedback: www.catamaranresort.com/trip I hope you all had a safe trip back home, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH v2 2/2] raspberrypi3: set core frequency
Pegging the core frequency at 250 avoids any fluctuations of the baud rate on the console. See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=138223 Signed-off-by: Trevor Woerner --- conf/machine/raspberrypi3.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/conf/machine/raspberrypi3.conf b/conf/machine/raspberrypi3.conf index cb6056e..81301c3 100644 --- a/conf/machine/raspberrypi3.conf +++ b/conf/machine/raspberrypi3.conf @@ -9,3 +9,4 @@ MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-brcm43430" include conf/machine/raspberrypi2.conf SERIAL_CONSOLE = "115200 ttyS0" +CORE_FREQ = "250" -- 2.7.0.rc3 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH v2 1/2] raspberrypi3: serial console
The serial console on the Raspberry Pi 3 is located at /dev/ttyS0 and not
/dev/ttyAMA0.
Signed-off-by: Trevor Woerner
---
conf/machine/raspberrypi3.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/conf/machine/raspberrypi3.conf b/conf/machine/raspberrypi3.conf
index 1b73f2f..cb6056e 100644
--- a/conf/machine/raspberrypi3.conf
+++ b/conf/machine/raspberrypi3.conf
@@ -7,3 +7,5 @@ MACHINEOVERRIDES = "raspberrypi2:${MACHINE}"
MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-brcm43430"
include conf/machine/raspberrypi2.conf
+
+SERIAL_CONSOLE = "115200 ttyS0"
--
2.7.0.rc3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Help with mosquitto_1.3.4 recipe
The first time I used mosquitto_1.3.4.bb from meta-intel-iot-middleware a few months ago, it worked and I've been using it in my build since. Today, I created a new yocto build directory and having trouble getting mosquitto to build now. The directory /yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4 is empty, whereas in my original build directory, the mosquitto source is there. I don't see any errors in log.do_fetch, but the error comes during do_configure: WARNING: Could not copy license file /yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt to /yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/license-destdir/mosquitto/LICENSE.txt: [Errno 2] No such file or directory: '/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt' ERROR: Function failed: mosquitto: LIC_FILES_CHKSUM points to an invalid file: /yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt ERROR: Logfile of failure stored in: /yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/temp/log.do_configure.31424 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | DEBUG: Shell function do_configure finished | DEBUG: Executing python function do_qa_configure | NOTE: Checking autotools environment for common misconfiguration | DEBUG: Python function do_qa_configure finished | ERROR: Function failed: mosquitto: LIC_FILES_CHKSUM points to an invalid file: /yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt ERROR: Task 388 (/yocto/meta-intel-iot-middleware/recipes-connectivity/mosquitto/mosquitto_1.3.4.bb, do_configure) failed with exit code '1' Can anyone suggest where to look next to debug this? log.do_fetch doesn't show any errors. I am using fido branch of poky and this revision of meta-intel-iot-middleware: http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/commit/?id=cfdd40032ca389bc1359a8b2e13e1da8f21e2561 (before the mosquitto recipe was upgraded to 1.4) Thanks, Ed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Rename linux.inc to linux-rpi.inc Rename linux.inc to prevent it from impacting other machines
Attempting submitting this patch from my linux machine to hopefully correct
the line wrapping issue.
On Mon, Apr 11, 2016 at 11:35 AM, Alan Stice wrote:
> Signed-off-by: Alan Stice
> ---
> recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
> recipes-kernel/linux/linux-rpi.inc | 132
> +
> recipes-kernel/linux/linux.inc | 132
> -
> 3 files changed, 133 insertions(+), 133 deletions(-)
> create mode 100644 recipes-kernel/linux/linux-rpi.inc
> delete mode 100644 recipes-kernel/linux/linux.inc
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index 24e7fe2..7ab1de2 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -1,4 +1,4 @@
> -require linux.inc
> +require linux-rpi.inc
> inherit linux-raspberrypi-base
>
> DESCRIPTION = "Linux Kernel for Raspberry Pi"
> diff --git a/recipes-kernel/linux/linux-rpi.inc
> b/recipes-kernel/linux/linux-rpi.inc
> new file mode 100644
> index 000..fae78b7
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-rpi.inc
> @@ -0,0 +1,132 @@
> +DESCRIPTION = "Linux Kernel"
> +SECTION = "kernel"
> +LICENSE = "GPLv2"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> +
> +inherit kernel siteinfo
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +# Enable OABI compat for people stuck with obsolete userspace
> +ARM_KEEP_OABI ?= "1"
> +
> +# Quirk for udev greater or equal 141
> +UDEV_GE_141 ?= "1"
> +
> +# Set the verbosity of kernel messages during runtime
> +# You can define CMDLINE_DEBUG in your local.conf or distro.conf to
> override this behaviour
> +CMDLINE_DEBUG ?= '${@base_conditional("DISTRO_TYPE", "release", "quiet",
> "debug", d)}'
> +CMDLINE_append = " ${CMDLINE_DEBUG}"
> +
> +# Set a variable in .configure
> +# $1 - Configure variable to be set
> +# $2 - value [n/y/value]
> +kernel_configure_variable() {
> +# Remove the config
> +CONF_SED_SCRIPT="$CONF_SED_SCRIPT /CONFIG_$1[ =]/d;"
> +if test "$2" = "n"
> +then
> +echo "# CONFIG_$1 is not set" >> ${B}/.config
> +else
> +echo "CONFIG_$1=$2" >> ${B}/.config
> +fi
> +}
> +
> +do_configure_prepend() {
> +# Clean .config
> +echo "" > ${B}/.config
> +CONF_SED_SCRIPT=""
> +
> +# oabi / eabi support
> +if [ "${TARGET_OS}" = "linux-gnueabi" -o "${TARGET_OS}" =
> "linux-uclibceabi" ]; then
> +kernel_configure_variable AEABI y
> +if [ "${ARM_KEEP_OABI}" = "1" ] ; then
> +kernel_configure_variable OABI_COMPAT y
> +else
> +kernel_configure_variable OABI_COMPAT n
> +fi
> +else
> +kernel_configure_variable AEABI n
> +kernel_configure_variable OABI_COMPAT n
> +fi
> +
> +# Set cmdline
> +kernel_configure_variable CMDLINE "\"${CMDLINE}\""
> +
> +# Localversion
> +kernel_configure_variable LOCALVERSION "\"\""
> +kernel_configure_variable LOCALVERSION_AUTO n
> +
> +# Udev quirks
> +# Newer versions of udev mandate that sysfs doesn't have deprecated
> entries
> +if [ "${UDEV_GE_141}" = "1" ] ; then
> +kernel_configure_variable SYSFS_DEPRECATED n
> +kernel_configure_variable SYSFS_DEPRECATED_V2 n
> +kernel_configure_variable HOTPLUG y
> +kernel_configure_variable UEVENT_HELPER_PATH "\"\""
> +kernel_configure_variable UNIX y
> +kernel_configure_variable SYSFS y
> +kernel_configure_variable PROC_FS y
> +kernel_configure_variable TMPFS y
> +kernel_configure_variable INOTIFY_USER y
> +kernel_configure_variable SIGNALFD y
> +kernel_configure_variable TMPFS_POSIX_ACL y
> +kernel_configure_variable BLK_DEV_BSG y
> +kernel_configure_variable DEVTMPFS y
> +kernel_configure_variable DEVTMPFS_MOUNT y
> +fi
> +
> +# Newer inits like systemd need cgroup support
> +if [ "${KERNEL_ENABLE_CGROUPS}" = "1" ] ; then
> +kernel_configure_variable CGROUP_SCHED y
> +kernel_configure_variable CGROUPS y
> +kernel_configure_variable CGROUP_NS y
> +kernel_configure_variable CGROUP_FREEZER y
> +kernel_configure_variable CGROUP_DEVICE y
> +kernel_configure_variable CPUSETS y
> +kernel_configure_variable PROC_PID_CPUSET y
> +kernel_configure_variable CGROUP_CPUACCT y
> +kernel_configure_variable RESOURCE_COUNTERS y
> +fi
> +
> +# root-over-nfs-over-usb-eth support. Limited, but should cover some
> cases
> +# Enable this by setting a proper CMDLINE_NFSROOT_USB.
> +if [ ! -z "${CMDLINE_NFSROOT_USB}" ]; then
> +oenote "Configuring the kernel for root-over-nfs-over-usb-eth
> with CMDLINE ${CMDLINE_NFSROOT_USB}"
> +kernel_configure_variable INET y
> +kernel_configure_variable IP_PNP y
> +kernel_configure_variable USB_GADGET y
> +
[yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Rename linux.inc to linux-rpi.inc Rename linux.inc to prevent it from impacting other machines
Signed-off-by: Alan Stice
---
recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
recipes-kernel/linux/linux-rpi.inc | 132 +
recipes-kernel/linux/linux.inc | 132 -
3 files changed, 133 insertions(+), 133 deletions(-)
create mode 100644 recipes-kernel/linux/linux-rpi.inc
delete mode 100644 recipes-kernel/linux/linux.inc
diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc
index 24e7fe2..7ab1de2 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -1,4 +1,4 @@
-require linux.inc
+require linux-rpi.inc
inherit linux-raspberrypi-base
DESCRIPTION = "Linux Kernel for Raspberry Pi"
diff --git a/recipes-kernel/linux/linux-rpi.inc
b/recipes-kernel/linux/linux-rpi.inc
new file mode 100644
index 000..fae78b7
--- /dev/null
+++ b/recipes-kernel/linux/linux-rpi.inc
@@ -0,0 +1,132 @@
+DESCRIPTION = "Linux Kernel"
+SECTION = "kernel"
+LICENSE = "GPLv2"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
+
+inherit kernel siteinfo
+require recipes-kernel/linux/linux-yocto.inc
+
+# Enable OABI compat for people stuck with obsolete userspace
+ARM_KEEP_OABI ?= "1"
+
+# Quirk for udev greater or equal 141
+UDEV_GE_141 ?= "1"
+
+# Set the verbosity of kernel messages during runtime
+# You can define CMDLINE_DEBUG in your local.conf or distro.conf to override
this behaviour
+CMDLINE_DEBUG ?= '${@base_conditional("DISTRO_TYPE", "release", "quiet",
"debug", d)}'
+CMDLINE_append = " ${CMDLINE_DEBUG}"
+
+# Set a variable in .configure
+# $1 - Configure variable to be set
+# $2 - value [n/y/value]
+kernel_configure_variable() {
+# Remove the config
+CONF_SED_SCRIPT="$CONF_SED_SCRIPT /CONFIG_$1[ =]/d;"
+if test "$2" = "n"
+then
+echo "# CONFIG_$1 is not set" >> ${B}/.config
+else
+echo "CONFIG_$1=$2" >> ${B}/.config
+fi
+}
+
+do_configure_prepend() {
+# Clean .config
+echo "" > ${B}/.config
+CONF_SED_SCRIPT=""
+
+# oabi / eabi support
+if [ "${TARGET_OS}" = "linux-gnueabi" -o "${TARGET_OS}" =
"linux-uclibceabi" ]; then
+kernel_configure_variable AEABI y
+if [ "${ARM_KEEP_OABI}" = "1" ] ; then
+kernel_configure_variable OABI_COMPAT y
+else
+kernel_configure_variable OABI_COMPAT n
+fi
+else
+kernel_configure_variable AEABI n
+kernel_configure_variable OABI_COMPAT n
+fi
+
+# Set cmdline
+kernel_configure_variable CMDLINE "\"${CMDLINE}\""
+
+# Localversion
+kernel_configure_variable LOCALVERSION "\"\""
+kernel_configure_variable LOCALVERSION_AUTO n
+
+# Udev quirks
+# Newer versions of udev mandate that sysfs doesn't have deprecated entries
+if [ "${UDEV_GE_141}" = "1" ] ; then
+kernel_configure_variable SYSFS_DEPRECATED n
+kernel_configure_variable SYSFS_DEPRECATED_V2 n
+kernel_configure_variable HOTPLUG y
+kernel_configure_variable UEVENT_HELPER_PATH "\"\""
+kernel_configure_variable UNIX y
+kernel_configure_variable SYSFS y
+kernel_configure_variable PROC_FS y
+kernel_configure_variable TMPFS y
+kernel_configure_variable INOTIFY_USER y
+kernel_configure_variable SIGNALFD y
+kernel_configure_variable TMPFS_POSIX_ACL y
+kernel_configure_variable BLK_DEV_BSG y
+kernel_configure_variable DEVTMPFS y
+kernel_configure_variable DEVTMPFS_MOUNT y
+fi
+
+# Newer inits like systemd need cgroup support
+if [ "${KERNEL_ENABLE_CGROUPS}" = "1" ] ; then
+kernel_configure_variable CGROUP_SCHED y
+kernel_configure_variable CGROUPS y
+kernel_configure_variable CGROUP_NS y
+kernel_configure_variable CGROUP_FREEZER y
+kernel_configure_variable CGROUP_DEVICE y
+kernel_configure_variable CPUSETS y
+kernel_configure_variable PROC_PID_CPUSET y
+kernel_configure_variable CGROUP_CPUACCT y
+kernel_configure_variable RESOURCE_COUNTERS y
+fi
+
+# root-over-nfs-over-usb-eth support. Limited, but should cover some cases
+# Enable this by setting a proper CMDLINE_NFSROOT_USB.
+if [ ! -z "${CMDLINE_NFSROOT_USB}" ]; then
+oenote "Configuring the kernel for root-over-nfs-over-usb-eth with
CMDLINE ${CMDLINE_NFSROOT_USB}"
+kernel_configure_variable INET y
+kernel_configure_variable IP_PNP y
+kernel_configure_variable USB_GADGET y
+kernel_configure_variable USB_GADGET_SELECTED y
+kernel_configure_variable USB_ETH y
+kernel_configure_variable NFS_FS y
+kernel_configure_variable ROOT_NFS y
+kernel_configure_variable ROOT_NFS y
+kernel_configure_variable CMDLINE "\"${CMDLINE_NFSROOT_USB}\""
+fi
+
+# Activate CONFIG_LEGACY_PTYS
+kernel_configure_variable LEGACY_PTYS y
+
+# Keep this th
Re: [yocto] A lot of, seemingly, hung tasks
On Mon, Apr 11, 2016 at 11:22 AM, Ronald Oakes wrote: > Over the weekend, I upgraded my connected development platform to > Debian 8.4.0 from Centos 7. > > However, today I have yet to make a successful poky-tiny build for > either coreI7-64 or qemux86-64. In each case, I've aborted the build > after one or more tasks has stopped doing anything for 30 minutes or > more. > > I define "stopped doing anything" as having not touched a file in 30 > minutes, while the CPU utilization (on this 2 core, low end, ASUS > VivoPC) drops very low. > > I've tried re-running the offending recipes and tasks individually, > and cleaning and restarting from scratch, but I keep ending up with > something hung. > > Any ideas what is up, and, more importantly, what I should do to resolve it? Have you used bitbake with the "--debug" option or run "ps axf" or similar to see which tasks or commands are hanging? > Ron Oakes > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-chip][PATCH] u-boot-chip: fix md5sum
The u-boot master and chip/stable branches have diverged such that the md5sums of the License README files are now different. The latest master branch has added a "SIL OPEN FONT LICENSE (OFL-1.1)" license. diff: --- chip/stable-README 2016-04-10 02:05:30.783023170 -0400 +++ upstream-README 2016-04-11 13:48:34.973027406 -0400 @@ -67,4 +67,5 @@ IBM PIBS (PowerPC Initialization and IBM-pibs ibm-pibs.txt Boot Software) license ISC LicenseISC Y isc.txt https://spdx.org/licenses/ISC +SIL OPEN FONT LICENSE (OFL-1.1)OFL-1.1 Y OFL.txt https://spdx.org/licenses/OFL-1.1.html X11 LicenseX11 x11.txt https://spdx.org/licenses/X11.html Signed-off-by: Trevor Woerner --- recipes-bsp/u-boot/u-boot-chip_git.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/recipes-bsp/u-boot/u-boot-chip_git.bb b/recipes-bsp/u-boot/u-boot-chip_git.bb index 2342478..60db3e0 100644 --- a/recipes-bsp/u-boot/u-boot-chip_git.bb +++ b/recipes-bsp/u-boot/u-boot-chip_git.bb @@ -2,6 +2,8 @@ require recipes-bsp/u-boot/u-boot.inc DESCRIPTION = "U-Boot port for C.H.I.P. boards" +LIC_FILES_CHKSUM = "file://Licenses/README;md5=0507cd7da8e7ad6d6701926ec9b84c95" + DEPENDS += "dtc-native" PROVIDES += "u-boot" -- 2.7.0.rc3 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] A lot of, seemingly, hung tasks
Over the weekend, I upgraded my connected development platform to Debian 8.4.0 from Centos 7. However, today I have yet to make a successful poky-tiny build for either coreI7-64 or qemux86-64. In each case, I've aborted the build after one or more tasks has stopped doing anything for 30 minutes or more. I define "stopped doing anything" as having not touched a file in 30 minutes, while the CPU utilization (on this 2 core, low end, ASUS VivoPC) drops very low. I've tried re-running the offending recipes and tasks individually, and cleaning and restarting from scratch, but I keep ending up with something hung. Any ideas what is up, and, more importantly, what I should do to resolve it? Ron Oakes -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] clamav: fix lib version mismatch
drop lib version in package name
drop insane and remove broken symlink
Use LEAD_SONAME
Don't hard code lib version in tasks
Use native chrpath not the host provided version
Signed-off-by: Armin Kuster
---
recipes-security/clamav/clamav_0.99.1.bb | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/recipes-security/clamav/clamav_0.99.1.bb
b/recipes-security/clamav/clamav_0.99.1.bb
index 4b42361..edccc78 100644
--- a/recipes-security/clamav/clamav_0.99.1.bb
+++ b/recipes-security/clamav/clamav_0.99.1.bb
@@ -4,7 +4,7 @@ HOMEPAGE = "http://www.clamav.net/index.html";
SECTION = "security"
LICENSE = "LGPL-2.1"
-DEPENDS = "libtool db libmspack "
+DEPENDS = "libtool db libmspack chrpath-replacement-native"
LIC_FILES_CHKSUM =
"file://COPYING.LGPL;beginline=2;endline=3;md5=4b89c05acc71195e9a06edfa2fa7d092"
@@ -18,6 +18,11 @@ SRC_URI =
"http://www.clamav.net/downloads/production/${BPN}-${PV}.tar.gz \
SRC_URI[md5sum] = "cf1f3cbe62a08c9165801f79239166ff"
SRC_URI[sha256sum] =
"e144689122d3f91293808c82cbb06b7d3ac9eca7ae29564c5d148ffe7b25d58a"
+LEAD_SONAME = "libclamav.so"
+SO_VER = "7.1.1"
+
+EXTRANATIVEPATH += "chrpath-native"
+
inherit autotools-brokensep pkgconfig useradd systemd
UID = "clamav"
@@ -53,7 +58,7 @@ do_configure () {
do_compile_append() {
# brute force removing RPATH
-chrpath -d ${B}/libclamav/.libs/libclamav.so.7.1.1
+chrpath -d ${B}/libclamav/.libs/libclamav.so.${SO_VER}
chrpath -d ${B}/sigtool/.libs/sigtool
chrpath -d ${B}/clambc/.libs/clambc
chrpath -d ${B}/clamscan/.libs/clamscan
@@ -71,6 +76,7 @@ do_install_append() {
install -m 644 ${WORKDIR}/freshclam.conf ${D}/${sysconfdir}
install -m 0644 ${WORKDIR}/volatiles.03_clamav
${D}${sysconfdir}/default/volatiles/volatiles.03_clamav
sed -i -e 's#${STAGING_DIR_HOST}##g' ${D}${libdir}/pkgconfig/libclamav.pc
+rm ${D}/${libdir}/libclamav.so
}
pkg_postinst_${PN} () {
@@ -82,7 +88,7 @@ pkg_postinst_${PN} () {
PACKAGES = "${PN} ${PN}-dev ${PN}-dbg ${PN}-daemon ${PN}-doc \
-${PN}-clamdscan ${PN}-freshclam ${PN}-libclamav6 ${PN}-staticdev"
+${PN}-clamdscan ${PN}-freshclam ${PN}-libclamav ${PN}-staticdev"
FILES_${PN} = "${bindir}/clambc ${bindir}/clamscan ${bindir}/clamsubmit \
${bindir}/*sigtool ${mandir}/man1/clambc*
${mandir}/man1/clamscan* \
@@ -116,15 +122,13 @@ FILES_${PN}-dev = " ${bindir}/clamav-config
${libdir}/*.la \
FILES_${PN}-staticdev = "${libdir}/*.a"
-FILES_${PN}-libclamav6 = "${libdir}/libclamav.so* ${libdir}/libmspack.so*\
- ${docdir}/libclamav6/* "
+FILES_${PN}-libclamav = "${libdir}/libclamav.so* ${libdir}/libmspack.so*\
+ ${docdir}/libclamav/* "
FILES_${PN}-doc = "${mandir}/man/* \
${datadir}/man/* \
${docdir}/* "
-INSANE_SKIP_${PN}-libclamav6 = "dev-so"
-
USERADD_PACKAGES = "${PN}"
GROUPADD_PARAM_${PN} = "--system ${UID}"
USERADD_PARAM_${PN} = "--system -g ${GID} --home-dir \
@@ -136,4 +140,4 @@ RREPLACES_${PN} += "${PN}-systemd"
RCONFLICTS_${PN} += "${PN}-systemd"
SYSTEMD_SERVICE_${PN} = "${BPN}.service"
-RDEPENDS_${PN} += "openssl ncurses-libncurses libbz2 ncurses-libtinfo
clamav-freshclam clamav-libclamav6"
+RDEPENDS_${PN} += "openssl ncurses-libncurses libbz2 ncurses-libtinfo
clamav-freshclam clamav-libclamav"
--
2.3.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] suricata: update package to 3.0.1
- fixes for multiple stability issues
- many memory leak fixes
- Hyperscan MPM support (experimental)
Signed-off-by: Armin Kuster
---
recipes-security/suricata/{libhtp_0.5.18.bb => libhtp_0.5.19.bb} | 0
recipes-security/suricata/suricata.inc | 7 +++
recipes-security/suricata/{suricata_3.0.bb => suricata_3.0.1.bb} | 0
3 files changed, 3 insertions(+), 4 deletions(-)
rename recipes-security/suricata/{libhtp_0.5.18.bb => libhtp_0.5.19.bb} (100%)
rename recipes-security/suricata/{suricata_3.0.bb => suricata_3.0.1.bb} (100%)
diff --git a/recipes-security/suricata/libhtp_0.5.18.bb
b/recipes-security/suricata/libhtp_0.5.19.bb
similarity index 100%
rename from recipes-security/suricata/libhtp_0.5.18.bb
rename to recipes-security/suricata/libhtp_0.5.19.bb
diff --git a/recipes-security/suricata/suricata.inc
b/recipes-security/suricata/suricata.inc
index 38b9572..b46ad3d 100644
--- a/recipes-security/suricata/suricata.inc
+++ b/recipes-security/suricata/suricata.inc
@@ -2,9 +2,8 @@ HOMEPAGE = "http://suricata-ids.org/";
SECTION = "security Monitor/Admin"
LICENSE = "GPLv2"
-VER = "3.0"
+VER = "3.0.1"
SRC_URI =
"http://www.openinfosecfoundation.org/download/suricata-${VER}.tar.gz";
-SRC_URI[md5sum] = "a964af69263592c625b56f72d49e8d24"
-SRC_URI[sha256sum] =
"4b8feb398a0800c955fe24aa31ca446c539e79492155717e826473f902c8e65a"
-
+SRC_URI[md5sum] = "c5c8e5846b54546257954f3c759d9675"
+SRC_URI[sha256sum] =
"74c685f8da51b3f038a7b8185bdbed274aca25daf64ac7ea01eea60636727f26"
diff --git a/recipes-security/suricata/suricata_3.0.bb
b/recipes-security/suricata/suricata_3.0.1.bb
similarity index 100%
rename from recipes-security/suricata/suricata_3.0.bb
rename to recipes-security/suricata/suricata_3.0.1.bb
--
2.3.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] nmap: update to 7.12
Signed-off-by: Armin Kuster
---
recipes-security/nmap/{nmap_7.11.bb => nmap_7.12.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename recipes-security/nmap/{nmap_7.11.bb => nmap_7.12.bb} (94%)
diff --git a/recipes-security/nmap/nmap_7.11.bb
b/recipes-security/nmap/nmap_7.12.bb
similarity index 94%
rename from recipes-security/nmap/nmap_7.11.bb
rename to recipes-security/nmap/nmap_7.12.bb
index 27efe7b..47cd7b6 100644
--- a/recipes-security/nmap/nmap_7.11.bb
+++ b/recipes-security/nmap/nmap_7.12.bb
@@ -7,8 +7,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;beginline=7;endline=12;md5=51f7052ac85aaf1a21
SRC_URI = "http://nmap.org/dist/${BP}.tar.bz2";
-SRC_URI[md5sum] = "0dc7fcde978b4891ba9fd91d16f19fce"
-SRC_URI[sha256sum] =
"13fa971555dec00e495a5b72c1f9efa1363b8e6c7388a2f05117cb0778c0954a"
+SRC_URI[md5sum] = "0764f4dabe7cccda3c49fc3990b62a8a"
+SRC_URI[sha256sum] =
"63df082a87c95a189865d37304357405160fc6333addcf5b84204c95e0539b04"
inherit autotools-brokensep pkgconfig distro_features_check
--
2.3.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.
Hi Wenzong,
[Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into
refpolicy_common.] On 16.04.08 (Fri 16:27) wenzong fan wrote:
> This causes do_populate_sysroot error if build two or more types of
> refpolicy:
>
> $ bitbake refpolicy-minimum && bitbake refpolicy-mls
>
> ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls is
> trying to install files into a shared area when those files already exist.
> Those files and their manifest location are:
I think this was always the intent with the series Philip submitted last
week (for reference, the thread is
https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
Isn't this (part of) the expected behaviour of the virtual provider
mechanism? We did discuss what it would mean to be trying out multiple
policies on a system at the same time and at the time it seemed like the
"just works" angle was more important than "buffet style" when it came
to providing policy on the image.
It might be worth considering extending the changes to only do some
install steps at, say, do_rootfs but I don't know if that even makes
sense, this is really the first I've thought of it. I think Philip's
original changes are good, though, for our maintenance and for clients
of meta-selinux.
-J.
>
> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
> Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>
> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
> Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>
> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
> Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
> Please verify which recipe should provide the above files.
>
> Philip,
>
> Can you consider to withdraw the integration?
>
> Thanks
> Wenzong
>
> On 04/04/2016 08:21 AM, Philip Tricca wrote:
> >With the virutal package there's no need for a separate recipe to build
> >the config. This can be generated and included as part of the policy
> >package.
> >
> >Signed-off-by: Philip Tricca
> >---
> > .../packagegroups/packagegroup-core-selinux.bb | 1 -
> > .../packagegroups/packagegroup-selinux-minimal.bb | 1 -
> > recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
> > recipes-security/selinux/selinux-config_0.1.bb | 40
> > --
> > 4 files changed, 28 insertions(+), 44 deletions(-)
> > delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb
> >
> >diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb
> >b/recipes-security/packagegroups/packagegroup-core-selinux.bb
> >index 62c5a76..c6d22b7 100644
> >--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
> >+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
> >@@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
> > packagegroup-selinux-policycoreutils \
> > setools \
> > setools-console \
> >-selinux-config \
> > selinux-autorelabel \
> > selinux-init \
> > selinux-labeldev \
> >diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
> >b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
> >index 87ae686..451ae8b 100644
> >--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
> >+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
> >@@ -21,7 +21,6 @@ RDEPENDS_${PN} = "\
> > policycoreutils-semodule \
> > policycoreutils-sestatus \
> > policycoreutils-setfiles \
> >-selinux-config \
> > selinux-labeldev \
> > virtual/refpolicy \
> > "
> >diff --git a/recipes-security/refpolicy/refpolicy_common.inc
> >b/recipes-security/refpolicy/refpolicy_common.inc
> >index ba887e4..305675f 100644
> >--- a/recipes-security/refpolicy/refpolicy_common.inc
> >+++ b/recipes-security/refpolicy/refpolicy_common.inc
> >@@ -1,3 +1,5 @@
> >+DEFAULT_ENFORCING ??= "enforcing"
> >+
> > SECTION = "base"
> > LICENSE = "GPLv2"
> >
> >@@ -14,7 +16,8 @@ SRC_URI += "file://customizable_types \
> >
> > S = "${WORKDIR}/refpolicy"
> >
> >-FILES_${PN} = " \
> >+CONFFILES_${PN} += "${sysconfdir}/selinux/config"
> >+FILES_${PN} += " \
> > ${sysconfdir}/selinux/${POLICY_NAME}/ \
> > ${datadir}/selinux/${POLICY_NAME}/*.pp \
> > ${localstatedir}/lib/selinux/${POLICY_NAME}/ \
> >@@ -25,7 +28,6 @@ FILES_${PN}-dev =+ " \
> > "
> >
> > DEPENDS += "checkpolicy-native policycoreutils-native m4-native"
> >-RDEPENDS_${PN} += "selinux-config"
> >
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> >@@ -137,13 +139,37 @@ install_misc_files () {
> > oe_runmake 'DESTDIR=${D}' 'prefix=${D}${prefix}' install-headers
> > }
> >
> >+install_config () {
> >+echo "\
> >+# This file controls the state of SELinux on the system.
> >+# SELINUX= can take one of these three values:
> >+# enforcing -
