[yocto] Openembedded layer index stopped updating
Hi, again me... sorry but I use index regularly to check if somebody else already created a recipe I am interested in. I think it was caused by maintenance changes. Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi_4.8.bb: Upgrade to 4.8.16
On 13 January 2017 02:04:26 GMT+00:00, Khem Raj wrote:
>On Thu, Jan 12, 2017 at 1:54 PM, Andrei Gherzan
>wrote:
>> On Thu, Jan 12, 2017 at 6:29 PM, Khem Raj wrote:
>>> Signed-off-by: Khem Raj
>>> ---
>>> recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>>> index 7511f93..be25e65 100644
>>> --- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>>> +++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>>> @@ -1,8 +1,8 @@
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>>
>>> -LINUX_VERSION ?= "4.8.15"
>>> +LINUX_VERSION ?= "4.8.16"
>>>
>>> -SRCREV = "c8af0c2f515556ef052913d552b6b11501c71996"
>>> +SRCREV = "061dccce6cf6705bbb5da29a643f4b0ad1d11630"
>>> SRC_URI =
>"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
>>> "
>>> require linux-raspberrypi.inc
>>> --
>>> 2.11.0
>>>
>>
>> Merged both to master.
>
>What do folks think about deleting all other kernel besides 4.1 4.4 and
>4.9
>
>cheers!
I haven't been able to get 4.1 to compile on master for a long time now. I've
already sent patches to update the 4.4 recipe and drop the 4.1 recipe.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building on MacOS X
Hi, > On 12 Jan 2017, at 23:59, Mark Hatle wrote: > > As far as I know pseudo and the security introduced in 10.11 that affect > preloading is likely the biggest technical problem... everything else is just > "it's not Linux”. With System Integrity Protection disabled, pseudo should still work as it did before, if that’s an acceptable step for you. If it isn’t, Apple’s new limitations can also be worked around in pseudo by hooking the exec(2) and posix_spawn(2) syscalls, checking if the binary to be executed is under system integrity protection, making a copy without the SIP-bit if it is and transparently running that copy instead. That code would need to be written, though (Let me know if you want to do that, I have the code for a different project.). It’s probably only a matter of time until Apple prevents that from working, too, though, e.g. by making some standard system tools signed binaries that no longer load preloaded libraries. HTH, Clemens -- Clemens Lang • Development Specialist BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com - BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Alexis Trolin Sitz und Registergericht: München HRB 134810 - -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Openembedded layer index stopped updating
Hi Andreas, On Fri, 13 Jan 2017 08:56:47 Andreas Müller wrote: > again me... sorry but I use index regularly to check if somebody else > already created a recipe I am interested in. > > I think it was caused by maintenance changes. You're right, we have just done an upgrade and as a result we are currently dealing with an issue updating the index, as yet I don't know what has caused it exactly because we aren't actually seeing any errors - the update process only manages to update some of the layers before it stalls and then eventually gets killed. We're working on it, apologies for the inconvenience. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi_4.8.bb: Upgrade to 4.8.16
On 13 Jan 2017 02:04, "Khem Raj" wrote:
On Thu, Jan 12, 2017 at 1:54 PM, Andrei Gherzan wrote:
> On Thu, Jan 12, 2017 at 6:29 PM, Khem Raj wrote:
>> Signed-off-by: Khem Raj
>> ---
>> recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>> index 7511f93..be25e65 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>> +++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>> @@ -1,8 +1,8 @@
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>
>> -LINUX_VERSION ?= "4.8.15"
>> +LINUX_VERSION ?= "4.8.16"
>>
>> -SRCREV = "c8af0c2f515556ef052913d552b6b11501c71996"
>> +SRCREV = "061dccce6cf6705bbb5da29a643f4b0ad1d11630"
>> SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=
rpi-4.8.y \
>> "
>> require linux-raspberrypi.inc
>> --
>> 2.11.0
>>
>
> Merged both to master.
What do folks think about deleting all other kernel besides 4.1 4.4 and 4.9
I agree.
cheers!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Openembedded layer index stopped updating
On Fri, Jan 13, 2017 at 9:55 AM, Paul Eggleton wrote: > Hi Andreas, > > On Fri, 13 Jan 2017 08:56:47 Andreas Müller wrote: >> again me... sorry but I use index regularly to check if somebody else >> already created a recipe I am interested in. >> >> I think it was caused by maintenance changes. > > You're right, we have just done an upgrade and as a result we are currently > dealing with an issue updating the index, as yet I don't know what has caused > it exactly because we aren't actually seeing any errors - the update process > only manages to update some of the layers before it stalls and then eventually > gets killed. We're working on it, apologies for the inconvenience. > Thanks and there is no inconvenience - was just a ping Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to decide which Yocto branch to use -krogoth or Jethro or any other
Hello, I am newbie to the Yocto world. I am trying to learn how to create an Embedded Linux distribution using the Yocto and so far have succeeded in building a base image for my customized board and the system is working fine. I am currently using the Yocto branch - krogoth. I checked the Yocto website for the stable releases: https://wiki.yoctoproject.org/wiki/Releases Krogoth and Jethro branches are marked as the stable versions. Since the Krogoth version is relatively new, I decided to use that. Now I am planning to create an Yocto based build system for my embedded Product. What's the influence in choosing one branch over the other. Any long term benefits or what should I keep in mind when I choose which branch to use? Any inputs on these would be helpful. cheers:) Mit freundlichen Grüßen / Best regards Vinothkumar Eswaran -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Failure Inheriting rpm_sign
On 11/01/2017, 14.33, "Chris Trobridge" wrote:
>On Mon, 2017-01-09 at 10:47 -0800, Khem Raj wrote:
>> On Fri, Jan 6, 2017 at 3:52 AM, Chris Trobridge
>> wrote:
>> > I am getting "Exception: OSError: [Errno 7] Argument list too long"
>> > for sign_rpm in the do_package_write_rpm tasks for the
>> > linux-yocto and glibc-locale recipes.
>> >
>> > This is building core-image-minimal (and also my own image) with
>> > morty (5aa481d) on Fedora 25.
>> >
>> > I have enabled the rpm signing with:
>> >
>> > INHERIT += " sign_rpm"
>> > RPM_GPG_NAME = "{name}"
>> > RPM_GPG_PASSPHRASE = "{passphrase}"
>> > IMAGE_INSTALL_append = " signing-keys-rpm"
>> >
>> > The error message makes some sense in as much as these recipes
>> > produce a lot of packages (for example, glibc-locale produces 1791
>> > packages) and the command line in the log is pretty big, although
>> > reading around I didn't find a consensus on what the max command
>> > line should be.
>> >
>> > The code to sign rpms is in meta/lib/oe/gpg_sign.py
>> > b/meta/lib/oe/gpg_sign.py and it builds up one command line with
>> > all the packages.
>> >
>> > I changed the code (patch appended) to sign each rpm in a separate
>> > command and the build completed successfully. The signing
>> > operations take a large amount of time so I think this might be a
>> > reasonable change but you may have other concerns.
>>
>> This certainly is useful, perhaps the signing bits can be moved to
>> individual
>> recipe packaging tasks that way it may be parallelized a bit
>>
>
>Thanks Raj,
>
>Something needs to be done as, unless I've messed up somewhere, you
>cannot build even core-image-minimal with rpm signing enabled so the
>sign_rpm class is effectively broken.
Signing should not break this way. Could you create a bug about this.
>The change I made works, but it's true is less efficient than signing
>rpms individually. The expense of the signature generation meant it
>wasn't inefficient to sign each package in a recipe with a separate
>command.
>
>However, looking in package_rpm.bbclass, the end of do_package_rpm()
>has:
>
>if d.getVar('RPM_SIGN_PACKAGES', True) == '1':
>bb.build.exec_func("sign_rpm", d)
>
>So, to avoid confusion, all the rpms in one recipe are packaged in
>task, and then that task calls the function sign all the packages. I
>don't know if there's a way for do_package_rpm() to spawn tasks to sign
>each package individually.
Probably an easy solution would be to sign packages in batches of, say,
100 packages. That way almost all recipes would be signed in one go. Few
packages would require multiple invocations of rpm but that shouldn't be
significant total overhead.
>I also found I needed 'IMAGE_INSTALL_append = " signing-keys-rpm"'
>local.conf, to deploy the public key but in sign_rpms.bbclass there is:
Yes, you need to add that package if you want to get the signing keys
installed in the image.
>
>do_package_index[depends] += "signing-keys:do_deploy"
>do_rootfs[depends] += "signing-keys:do_populate_sysroot"
>
>It may be this isn't quite what is required.
These are needed at build time and they do not install anything in the
final image. The first one is needed for creating rpm package feeds (or
repositories). The second one is needed needed for rpm-native to have the
correct keys when it is installing packages to create the rootfs.
Thanks,
Markus
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to decide which Yocto branch to use -krogoth or Jethro or any other
On 1/13/17 2:38 AM, Eswaran Vinothkumar (BEG-PT/PJ-IOT1) wrote: > Hello, > > I am newbie to the Yocto world. I am trying to learn how to create an > Embedded Linux distribution using the Yocto and so far have succeeded in > building a base image for my customized board and the system is working > fine. I am currently using the Yocto branch - krogoth. I checked the > Yocto website for the stable releases: > > https://wiki.yoctoproject.org/wiki/Releases > > Krogoth and Jethro branches are marked as the stable versions. Since the > Krogoth version is relatively new, I decided to use that. Now I am > planning to create an Yocto based build system for my embedded Product. latest release is morty (2.2) > > What's the influence in choosing one branch over the other. Any long > term benefits or what should I keep in mind when I choose which branch > to use? Any inputs on these would be helpful. cheers:) > You should always choose latest stable with a plan to be easily upgradable to newer release, so limit the changes to core metadata and if you do find issues and fix them then upstream the issues as soon as possible, so you dont have to forward port them when you upgrade. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [kernel-tools][PATCH] scc: Fix process_file error check
Commit 626ceac135fa66277c2fa53197be33cc9d4d7614 broke the error check in
process_file by adding in three lines that stomp on $? which print the
output file when verbose is set.
Move output file on verbose print to an elif after the error check.
Signed-off-by: George McCollister
---
tools/scc | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/scc b/tools/scc
index 4cd68a4..3d17496 100755
--- a/tools/scc
+++ b/tools/scc
@@ -246,10 +246,6 @@ process_file()
)
)
-if [ -n "${verbose}" ]; then
-cat ${scc_output_file}
-fi
-
if [ $? -ne 0 ]; then
echo "[ERROR]: processing of file $in failed"
cat ${scc_output_file}
@@ -275,6 +271,8 @@ process_file()
fi
rm -f ${scc_output_file}
exit 1
+elif [ -n "${verbose}" ]; then
+cat ${scc_output_file}
fi
rm -f ${scc_output_file}
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [kernel-tools][PATCH] scc: Fix process_file error check
On 2017-01-13 3:27 PM, George McCollister wrote:
Commit 626ceac135fa66277c2fa53197be33cc9d4d7614 broke the error check in
process_file by adding in three lines that stomp on $? which print the
output file when verbose is set.
Move output file on verbose print to an elif after the error check.
Good catch!
Merged.
My oe-core submissions are queued up at the moment, but I'll have this
in my next batch.
Bruce
Signed-off-by: George McCollister
---
tools/scc | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/scc b/tools/scc
index 4cd68a4..3d17496 100755
--- a/tools/scc
+++ b/tools/scc
@@ -246,10 +246,6 @@ process_file()
)
)
-if [ -n "${verbose}" ]; then
-cat ${scc_output_file}
-fi
-
if [ $? -ne 0 ]; then
echo "[ERROR]: processing of file $in failed"
cat ${scc_output_file}
@@ -275,6 +271,8 @@ process_file()
fi
rm -f ${scc_output_file}
exit 1
+elif [ -n "${verbose}" ]; then
+cat ${scc_output_file}
fi
rm -f ${scc_output_file}
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
