This is ok.
On Thu, May 5, 2016 at 9:20 PM, Jianxun Zhang
wrote:
> The "systemd-boot" is gummiboot now included into systemd project.
> The old gummiboot project supported in OE is dead.
>
> Our intention is to get a gummiboot-like EFI bootloader without
> much dependency on systemd and its featu
Thanks Mark.
Nothing is pulling vmdk into my builds. vmdk does not end up in my
IMAGE_FSTYPES or IMAGE_FSTYPES_DEBUGFS. Again, the output from bitbake
-e is fine when reverting Ross' patch and applying the patch I posted
earlier instead. With Ross' patch (only), bitbake doesn't even finish
parsing
From: Edwin Plauchu
This patch avoids unzip fails to compile with compiler flags which elevate
common string formatting issues into an error (-Wformat -Wformat-security
-Werror=format-security).
[YOCTO #9551]
Signed-off-by: Edwin Plauchu
---
meta/conf/distro/include/security_flags.inc
On 05/26/2016 04:25 PM, Saul Wold wrote:
On Thu, 2016-05-05 at 11:20 -0700, Jianxun Zhang wrote:
The "systemd-boot" is gummiboot now included into systemd project.
The old gummiboot project supported in OE is dead.
Our intention is to get a gummiboot-like EFI bootloader without
much dependenc
Armin,
Do you want me to hold off on your krogoth-next build on the AB to give you
time to include this?
-Bill
On Fri, 2016-05-27 at 11:29 -0500, George McCollister wrote:
Yes, I found the issue on krogoth.
-George
On Fri, May 27, 2016 at 11:25 AM, akuster808
mailto:akuster...@gmail.com
On Fri, May 27, 2016 at 1:27 PM, akuster808 wrote:
>
>
> On 05/27/2016 06:43 AM, Andrew Shadura wrote:
>> Upgrade U-Boot to the latest upstream version.
>> Add a patch to unbreak build on some toolchains.
>
> Are this changes appropriate for Krogoth?
I don't think so.
--
Otavio Salvador
Yes, I found the issue on krogoth.
-George
On Fri, May 27, 2016 at 11:25 AM, akuster808 wrote:
> does this affect krogoth?
>
> - armin
>
> On 05/27/2016 09:18 AM, Bruce Ashfield wrote:
>> We had a partial musb change merged into the 4.1 tree, which resulted in:
>>
>> | kernel-source/drivers/us
On 2016-05-27 12:25 PM, akuster808 wrote:
does this affect krogoth?
Yep. It isn't due to a new change. thanks for catching that.
Bruce
- armin
On 05/27/2016 09:18 AM, Bruce Ashfield wrote:
We had a partial musb change merged into the 4.1 tree, which resulted in:
| kernel-source/driver
On 05/27/2016 06:43 AM, Andrew Shadura wrote:
> Upgrade U-Boot to the latest upstream version.
> Add a patch to unbreak build on some toolchains.
Are this changes appropriate for Krogoth?
- armin
>
> Signed-off-by: Andrew Shadura
> ---
> ...utils_2016.03.bb => u-boot-fw-utils_2016.05.bb} |
does this affect krogoth?
- armin
On 05/27/2016 09:18 AM, Bruce Ashfield wrote:
> We had a partial musb change merged into the 4.1 tree, which resulted in:
>
> | kernel-source/drivers/usb/musb/musb_dsps.c:
> In function 'dsps_create_musb_pdev':
> | kernel-source/drivers/usb/musb/musb_dsps.
On 25-05-16 14:45, alexander.kana...@linux.intel.com wrote:
I'm trying to get my head around how this change will impact python2
based programs that use swig, such as gnuradio.
Does this mean all programs that use swig will need to move to python3
now?
Probably. At least nothing in meta-oe or
We had a partial musb change merged into the 4.1 tree, which resulted in:
| kernel-source/drivers/usb/musb/musb_dsps.c:
In function 'dsps_create_musb_pdev':
| kernel-source/drivers/usb/musb/musb_dsps.c:750:8:
error: 'struct musb_hdrc_config' has no member named 'maximum_speed'
| config
Updating the kernel ("opkg install kernel") does not update the
dependencies (i.e. modules) because there is no possibility to do version
enforcement in the OE recipe. Upon rebooting, the older version modules
do not load and can leave hardware in a non-functioning state (if their
drivers are not b
On 5/27/16 9:42 AM, André Draszik wrote:
> On Fr, 2016-05-27 at 09:21 -0500, Mark Hatle wrote:
>> On 5/27/16 5:54 AM, André Draszik wrote:
>>> This doesn't work for me (at least on krogoth):
>>>
>>> ERROR: poky/meta/recipes-core/images/build-appliance-
>>> image_14.0.0.bb: No IMAGE_CMD defined
Current Dev Position: YP 2.2 M1
Next Deadline: YP 2.2 cut off: June 13, 2016
SWAT team rotation: Tracy -> Alejandro
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Key Status/Updates:
*Python3 is nearly ready to merge, 4 oe-selftest issues remain and some
toaster is
On Fr, 2016-05-27 at 09:21 -0500, Mark Hatle wrote:
> On 5/27/16 5:54 AM, André Draszik wrote:
> > This doesn't work for me (at least on krogoth):
> >
> > ERROR: poky/meta/recipes-core/images/build-appliance-
> > image_14.0.0.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry
> > 'debugfs_vmdk'
Integrating the following mainline backports for better Broxton
support:
Adrian Hunter (3):
mmc: sdhci: Remove SDHCI_SDR104_NEEDS_TUNING
mmc: mmc: Attempt to flush cache before reset
mmc: mmc: Fix partition switch timeout for some eMMCs
Andy Shevchenko (12):
device propert
Hi all,
This pull request superceeds my other request by the same subject.
The only difference is that I now have a 3rd patch from Tom, that reverts
the branch name change for generic/qemux86*, since we didn't intend for
them to use the intel staging branches.
Cheers,
Bruce
The following change
To provide timely support for Intel platforms, without risking
issues with other platforms, we create intel branches from the
common variants.
i.e. We now have standard/intel, which is from standard/base
These branches will be managed like any other in the tree, and
will get common -stable, -rt,
Reverting the change that moved common-pc* to the intel staging
branches. This means that genericx86, qemux86*, etc, will continue
to use standard/base.
Signed-off-by: Tom Zanussi
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 2 +-
meta/recipes-kernel/lin
On 5/27/16 5:54 AM, André Draszik wrote:
> This doesn't work for me (at least on krogoth):
>
> ERROR: poky/meta/recipes-core/images/build-appliance-image_14.0.0.bb: No
> IMAGE_CMD defined for IMAGE_FSTYPES entry 'debugfs_vmdk' - possibly invalid
> type name or missing support class
> ERR
On Fri, May 27, 2016 at 10:58 AM, Andrew Shadura
wrote:
> Upgrade U-Boot to the latest upstream version.
> Add a patch to unbreak build on some toolchains.
>
> Signed-off-by: Andrew Shadura
> ---
Acked-by: Otavio Salvador
--
Otavio Salvador O.S. Systems
http://www
Upgrade U-Boot to the latest upstream version.
Add a patch to unbreak build on some toolchains.
Signed-off-by: Andrew Shadura
---
Changes since v1:
* Fixes Upstream-Status of the patch.
---
...utils_2016.03.bb => u-boot-fw-utils_2016.05.bb} | 4 +-
...kimage_2016.03.bb => u-boot-mkimage_2016.
On Thu, May 26, 2016 at 12:13 PM, Andrew Shadura
wrote:
> Use "-n" operation instead of comparing with an "x"-ed empty string,
> use $(...) notation instead of the deprecated backticks.
>
> Signed-off-by: Andrew Shadura
Acked-by: Otavio Salvador
--
Otavio Salvador
On 27/05/16 15:53, Otavio Salvador wrote:
>> +Upstream-Status: Inappropriate [comes from upstream's branch]
> Is this a backport? If such, please fix the value.
Oh, I didn't know that value exists. How about the yesterday's patch by
the way?
http://patchwork.openembedded.org/patch/123585/
--
Ch
On Fri, May 27, 2016 at 10:43 AM, Andrew Shadura
wrote:
> Upgrade U-Boot to the latest upstream version.
> Add a patch to unbreak build on some toolchains.
>
> Signed-off-by: Andrew Shadura
> ---
...
> +++
> b/meta/recipes-bsp/u-boot/u-boot/-video-ipu_common-fix-build-error.patch
> @@ -0,0 +
On Fri, May 27, 2016 at 03:22:01PM +0200, Martin Jansa wrote:
> On Wed, May 11, 2016 at 09:35:05AM +, g...@git.openembedded.org wrote:
> > rpurdie pushed a commit to branch master
> > in repository openembedded-core.
> >
> > commit c269547ae8e90a78349f6003385137e4145e145f
> > Author: Paul Eggl
Upgrade U-Boot to the latest upstream version.
Add a patch to unbreak build on some toolchains.
Signed-off-by: Andrew Shadura
---
...utils_2016.03.bb => u-boot-fw-utils_2016.05.bb} | 4 +-
...kimage_2016.03.bb => u-boot-mkimage_2016.05.bb} | 4 +-
.../-video-ipu_common-fix-build-error.patc
On Wed, May 11, 2016 at 09:35:05AM +, g...@git.openembedded.org wrote:
> rpurdie pushed a commit to branch master
> in repository openembedded-core.
>
> commit c269547ae8e90a78349f6003385137e4145e145f
> Author: Paul Eggleton
> AuthorDate: Tue May 10 10:25:05 2016 +1200
>
> classes/insane
Most issues were reported last week as well, there are few new ones and
the QA warning output seems to be a bit broken, but probably nobody
reads that far.
== Number of issues - stats ==
{| class='wikitable'
!|Date !!colspan='3'|Failed tasks
!!colspan='6'|Failed
This doesn't work for me (at least on krogoth):
ERROR: poky/meta/recipes-core/images/build-appliance-image_14.0.0.bb: No
IMAGE_CMD defined for IMAGE_FSTYPES entry 'debugfs_vmdk' - possibly invalid
type name or missing support class
ERROR: Failed to parse recipe:
poky/meta/recipes-core/i
On Thu, 26 May 2016, Khem Raj wrote:
> On Thu, May 26, 2016 at 11:56 AM, Robert P. J. Day
> wrote:
> >
> > i've grumbled about this before -- the *apparent* redundancy in
> > combining the "_append" and "+=" constructs -- but someone recently
> > suggested there's a use case for that that weird
On Fri, May 27, 2016 at 7:10 AM, Martin Jansa wrote:
> On Fri, May 27, 2016 at 06:55:30AM -0300, Otavio Salvador wrote:
>> On Thu, May 26, 2016 at 10:41 AM, Richard Purdie
>> wrote:
>> > On Mon, 2016-05-23 at 17:45 -0300, Otavio Salvador wrote:
>> >> This patchset leverage the OpenSSL certificate
The update-ca-certificates script uses the c_rehash utility which is
installed by openssl. Add openssl as a runtime dependency to fulfill
the utility requirement.
Signed-off-by: Otavio Salvador
---
meta/recipes-support/ca-certificates/ca-certificates_20160104.bb | 2 ++
1 file changed, 2 insert
Can you rebase to master as v1 was merged.
Cheers,
Ross
On 27 May 2016 at 10:55, Otavio Salvador wrote:
> This patchset leverage the OpenSSL certificate handling so it works
> aligned with Debian and other generic distributions regarding where
> the certificates are stored and how they are inst
On Fri, May 27, 2016 at 06:55:30AM -0300, Otavio Salvador wrote:
> On Thu, May 26, 2016 at 10:41 AM, Richard Purdie
> wrote:
> > On Mon, 2016-05-23 at 17:45 -0300, Otavio Salvador wrote:
> >> This patchset leverage the OpenSSL certificate handling so it works
> >> aligned with Debian and other gen
On Fri, May 27, 2016 at 09:26:10AM +0300, Markus Lehtonen wrote:
> The loop iterating over LICENSE_pn variables has never worked. In
> addition, the LICENSE variable is supposed to contain all licenses
> defined in LICENSE_pn variables.
Is this really true?
I've seen couple examples where LICENSE
As now the c_rehash utility is available, we can use it. This removes
the patch to disable its usage allowing for a standard SSL behaviour.
Signed-off-by: Otavio Salvador
---
Changes in v2:
- Add rdepends on openssl
...01-update-ca-certificates-remove-c-rehash.patch | 46 --
Debian and other generic distributions has moved the certificates for
sysconfdir (/etc/ssl) and made the libdir content to link for it.
This provides several advantages specially for read-only
rootfs. Another benefit is that it ensures foreign implementations
(e.g: BoringSSL, from Chromium, when r
The PLD Linux distribution has ported the c_rehash[1] utility from Perl
to Shell-Script, allowing it to be shipped by default.
1.
https://git.pld-linux.org/?p=packages/openssl.git;a=blob;f=openssl-c_rehash.sh;h=0ea22637ee6dbce845a9e2caf62540aaaf5d0761
The OpenSSL upstream intends[2] to convert t
On Thu, May 26, 2016 at 10:41 AM, Richard Purdie
wrote:
> On Mon, 2016-05-23 at 17:45 -0300, Otavio Salvador wrote:
>> This patchset leverage the OpenSSL certificate handling so it works
>> aligned with Debian and other generic distributions regarding where
>> the certificates are stored and how t
This patchset leverage the OpenSSL certificate handling so it works
aligned with Debian and other generic distributions regarding where
the certificates are stored and how they are installed.
This all started when debugging why SSL certificates were not working
properly for a customer which was us
On 27 May 2016 at 11:08, Jussi Kukkonen wrote:
> New mkdosfs has changed the default sectors-per-track it sets on a
> new image: This number is useless in our use case but mcopy has
> sanity checks to make sure image size is an integral number of
> sectors-per-track.
Just to be on the safe side:
This fixes the image build issues that were a result of my dosfstools
upgrade, sorry for not testing that one properly.
This was the first time I even looked at the image generation code,
would appreciate review from Robert or someone else more familiar
with it. There are alternative solutions (li
New mkdosfs has changed the default sectors-per-track it sets on a
new image: This number is useless in our use case but mcopy has
sanity checks to make sure image size is an integral number of
sectors-per-track.
Make sure our sector count is always divisible by sectors-per-track.
Signed-off-by:
45 matches
Mail list logo
