Re: [yocto] Does CVE-2015-7547 affect eglibc?

[Khem Raj]

Can you describe the regressions in some more detail

> On Feb 25, 2016, at 5:43 PM, Darcy Watkins  
> wrote:
> 
> Be careful about rushing out fixes. We are observing regressions in software 
> triggered by changes in glibc  behaviour.
> 
> 
> ---
> 
> Regards,
> 
> Darcy
> 
> Darcy Watkins
> Staff Engineer, Firmware
> Sierra Wireless
> http://sierrawireless.com
> [M3]
> 
>> On Feb 24, 2016, at 8:57 AM, akuster808  wrote:
>> 
>> 
>> 
>>> On 02/24/2016 08:38 AM, Mark Hatle wrote:
 On 2/23/16 6:14 PM, akuster808 wrote:
 
 
> On 02/23/2016 02:52 PM, Darcy Watkins wrote:
>> On Tue, 2016-02-23 at 13:51 -0800, Mark Hatle wrote:
>>> On 2/23/16 1:53 PM, Khem Raj wrote:
>>> On Tue, Feb 23, 2016 at 2:25 PM, Darcy Watkins
 CVE-2015-7547 glibc vulnerability has been published as affecting glibc
 since ver 2.9 (fixed in 2.23 and patched in 2.22 and 2.21).
 
 Anyone know if we need the same security fixes in eglibc?
>>> 
>>> yes you do. Eglibc was nothing but glibc+few fixes.
>> 
>> Yes this affects all eglibc version 2.9 and newer up to glibc 2.23.
>> 
>> As far as I'm aware, this affects all Yocto Project versions up to 2.0.
> 
> I will be interested in knowing which Yocto Project versions will
> receive the fixes.
 
 Master, 2.0 and 1.8 all have the fixes.
 How far back do we go in matters like this?
>>> 
>>> Official support is current (in development) and the last two releases.  So 
>>> up
>>> to about a year and a half of support.
>>> 
>>> After this point, it becomes community support.  This really means, if 
>>> someone
>>> in the community wants to continue support past the YP's support guidelines 
>>> they
>>> are welcome to do so -- but there won't be any official releases, only 
>>> checkins
>>> to the repository.
>> 
>> much better explanation than mine.
>> 
>> thanks,
>> Armin
>>> 
>>> We have done this on some OpenSSL fixes in the past, but it was based on
>>> specific requests and people submitting the fixes to be included with older
>>> versions.
>>> 
 1.7 (dizzy) I plan on doing soon. beyond that I do not know. those are
 all community supported.
 
 - armin
> 
> Thanks in advance!
> 
>> (The patch referenced by the security announcement applies to all of the
>> versions of glibc I've needed to apply it to for my customers.  A few 
>> per-line
>> tweaks might be necessary, but it was fairly easy.)
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Removing Hob for 2.1

[Khem Raj]

Go ahead
On Feb 25, 2016 6:50 PM, "Paul Eggleton" 
wrote:

> Hi folks,
>
> So we've been gearing up the Toaster web UI to replace the Hob (GTK+
> based) UI
> for some time now; Hob has basically been on life support for the past few
> releases. As of late last month in master, Toaster has the capability to
> select the packages in an image, removing the last thing that Hob could do
> that Toaster couldn't. This means it's about time we looked at removing
> Hob -
> particularly if we want to do so for the upcoming 2.1 release as we should
> really do so within the M3 development timeframe which is almost over.
>
> To recap, the reasons why Hob ought to be removed include:
>
> - The code is tightly woven into BitBake, making it fragile. This means it
> needs significant QA and maintenance on an ongoing basis.
>
> - Some of the implementation is not ideal; we'll be able to remove some
> cruft
> from BitBake and OE-Core at the same time.
>
> - It's GTK+ 2 based, not the current GTK+ 3.
>
> - Toaster is now a much more capable UI and is being actively maintained
>
> I'm maintaining a list of things we would drop together with Hob, so I
> could
> probably come up with a patchset - I just wanted to give people a heads up
> and
> double check that this is something we indeed want to do in 2.1. Any
> comments?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Removing Hob for 2.1

[Paul Eggleton]

Hi folks,

So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) UI 
for some time now; Hob has basically been on life support for the past few 
releases. As of late last month in master, Toaster has the capability to 
select the packages in an image, removing the last thing that Hob could do 
that Toaster couldn't. This means it's about time we looked at removing Hob - 
particularly if we want to do so for the upcoming 2.1 release as we should 
really do so within the M3 development timeframe which is almost over.

To recap, the reasons why Hob ought to be removed include:

- The code is tightly woven into BitBake, making it fragile. This means it 
needs significant QA and maintenance on an ongoing basis.

- Some of the implementation is not ideal; we'll be able to remove some cruft 
from BitBake and OE-Core at the same time.

- It's GTK+ 2 based, not the current GTK+ 3.

- Toaster is now a much more capable UI and is being actively maintained

I'm maintaining a list of things we would drop together with Hob, so I could 
probably come up with a patchset - I just wanted to give people a heads up and 
double check that this is something we indeed want to do in 2.1. Any comments?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Does CVE-2015-7547 affect eglibc?

[Darcy Watkins]

Be careful about rushing out fixes. We are observing regressions in software 
triggered by changes in glibc  behaviour. 


---

Regards,

Darcy

Darcy Watkins
Staff Engineer, Firmware
Sierra Wireless
http://sierrawireless.com
[M3]

> On Feb 24, 2016, at 8:57 AM, akuster808  wrote:
> 
> 
> 
>> On 02/24/2016 08:38 AM, Mark Hatle wrote:
>>> On 2/23/16 6:14 PM, akuster808 wrote:
>>> 
>>> 
 On 02/23/2016 02:52 PM, Darcy Watkins wrote:
> On Tue, 2016-02-23 at 13:51 -0800, Mark Hatle wrote:
>> On 2/23/16 1:53 PM, Khem Raj wrote:
>> On Tue, Feb 23, 2016 at 2:25 PM, Darcy Watkins
>>> CVE-2015-7547 glibc vulnerability has been published as affecting glibc
>>> since ver 2.9 (fixed in 2.23 and patched in 2.22 and 2.21).
>>> 
>>> Anyone know if we need the same security fixes in eglibc?
>> 
>> yes you do. Eglibc was nothing but glibc+few fixes.
> 
> Yes this affects all eglibc version 2.9 and newer up to glibc 2.23.
> 
> As far as I'm aware, this affects all Yocto Project versions up to 2.0.
 
 I will be interested in knowing which Yocto Project versions will
 receive the fixes.
>>> 
>>> Master, 2.0 and 1.8 all have the fixes.
>>> How far back do we go in matters like this?
>> 
>> Official support is current (in development) and the last two releases.  So 
>> up
>> to about a year and a half of support.
>> 
>> After this point, it becomes community support.  This really means, if 
>> someone
>> in the community wants to continue support past the YP's support guidelines 
>> they
>> are welcome to do so -- but there won't be any official releases, only 
>> checkins
>> to the repository.
> 
> much better explanation than mine.
> 
> thanks,
> Armin
>> 
>> We have done this on some OpenSSL fixes in the past, but it was based on
>> specific requests and people submitting the fixes to be included with older
>> versions.
>> 
>>> 1.7 (dizzy) I plan on doing soon. beyond that I do not know. those are
>>> all community supported.
>>> 
>>> - armin
 
 Thanks in advance!
 
> (The patch referenced by the security announcement applies to all of the
> versions of glibc I've needed to apply it to for my customers.  A few 
> per-line
> tweaks might be necessary, but it was fairly easy.)
> -- 
> ___
> 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] [ANNOUNCEMENT] Milestone 2 for Yocto Project 2.1 now available.

[Graydon, Tracy]

The second milestone release for Yocto Project 2.1 is available for
download now.

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.1_M2/

Thank you to everyone for your contributions.

eclipse-poky/kepler-master cf60ac293629fc8ecd6c4eb3709a6f334b499d0c
eclipse-poky/luna-master 45aa5c77523bdf051d548fff4305382942db2ebb
eclipse-poky/mars-master 1d179ddcbd1983bf7bcfe98efdcbb186bdccca4f
meta-qt3 7d958b928a4a38a186746fabbc0d8169dd8bb3a6
meta-qt4 4058b0773381f894d915ea3dfac5fe052d82a9a7
poky 152914f2983c5d69001de1d46ce99547fa1e75fe

Test report at:

https://wiki.yoctoproject.org/wiki/WW08_-_2016-02-17_-_Full_Pass_2.1_M2.rc3


Tracy Graydon
Yocto Project
Build and Release

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH] bin/release_scripts/release.py: fix milestone staging

[Graydon, Tracy]

From: Tracy Graydon 

Milestones were going into the top level of the download release directory
instead of the milestones subdirectory. Added a check for milestone releases
and now adjusts the path accordingly. Also fixed an indent issue which was
causing the master md5sum table to be generated for milestones.

Signed-off-by: Tracy Graydon 
---
 bin/release_scripts/release.py | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/bin/release_scripts/release.py b/bin/release_scripts/release.py
index 4c71e31..158c44a 100755
--- a/bin/release_scripts/release.py
+++ b/bin/release_scripts/release.py
@@ -453,7 +453,6 @@ if __name__ == '__main__':
 
 PLUGIN_DIR = os.path.join(DL_BASE, "eclipse-plugin", REL_ID)
 RELEASE_DIR = os.path.join(AB_BASE, RELEASE)
-DL_DIR = os.path.join(DL_BASE, RELEASE)
 MACHINES = os.path.join(RELEASE_DIR, "machines")
 BSP_DIR = os.path.join(RELEASE_DIR, 'bsptarballs')
 TARBALL_DIR = os.path.join(RELEASE_DIR, "tarballs")
@@ -494,18 +493,24 @@ if __name__ == '__main__':
 print "Generating the BSP tarballs."
 make_bsps(BSP_LIST, BSP_DIR)
 
-# 7) Generate the master md5sum file for the release (for all releases)
-print "Generating the master md5sum table."
-gen_rel_md5(RELEASE_DIR, REL_MD5_FILE)
+# 7) Generate the master md5sum file for the release (for all releases)
+print "Generating the master md5sum table."
+gen_rel_md5(RELEASE_DIR, REL_MD5_FILE)
 
 # 8) sync to downloads
+if REL_TYPE == "milestone":
+DL_DIR = os.path.join(DL_BASE, "milestones", RELEASE)
+print "DL_DIR for milestones: %s" %DL_DIR
+else:
+DL_DIR = os.path.join(DL_BASE, RELEASE)
+print "DL_DIR for point/major: %s" %DL_DIR
 print "Publishing release to downloads."
 sync_it(RELEASE_DIR, DL_DIR, "")
 
-# 9) Publish the ADT repo. The default is NOT to publish the ADT. The ADT 
-# is deprecated as of 2.1_M1. However, we need to retain backward 
+# 9) Publish the ADT repo. The default is NOT to publish the ADT. The ADT
+# is deprecated as of 2.1_M1. However, we need to retain backward
 # compatability for point releases, etc. We do this step after all the 
other
-#  stuff because we want the symlinks to have been converted, extraneous 
+#  stuff because we want the symlinks to have been converted, extraneous
 # files deleted, and md5sums generated.
 #
 if options.pub_adt:
-- 
2.4.3

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using the hardware graphics acceleration with qt

[Marius]

I am not sure how to get QT to use the BBB graphics acceleration. I 
assume that the linuxfb is not using the GPU features of the chip.


I am using  the BBB without desktop (x11). How do I ensure that QT uses 
the GPU. I cannot see from the recipes how to configure QT.Any examples 
will be very helpful.


Regards
Marius

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Adjust for libexecdir changes

[Trevor Woerner]

On 02/23/16 23:21, Khem Raj wrote:

You can try to use github.com/kraj/meta-raspberrypi kraj/master
I plan to test out more and more pending submissions on that branch


Thanks, and done.

It's too bad meta-raspberrypi didn't have a master-next branch :-)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Coldplug is not working as expected

[Sandy Pérez]

Hello,

I’m testing the Freescale's Yocto BSP layer (
http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/) on an
SBC2100 board manufactured by IC Nexus Co. More specifically, I’m using the
branch imx-3.10.53-1.1.1_patch which corresponds to Yocto 1.6.2 (Daisy). I
have a HUAWEI MS2131i-8 modem connected via USB to the board and some udev
rules to “mount” this device on /dev/modem. Everything work as expected
when I connect and disconnect the modem while the system is running, that
is, hotpluging is working right. However, if I reboot the system with the
modem connected, the /dev/modem link is not created; it seems like
coldpluging is not working at all.

During the boot process, a uevent file is created in the device directory
/sys/devices/soc0/soc.1/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0/tty/ttyUSB0
but it seems like nobody is using it.  Only one entry is found in the log
related to udev:

- imx6-sbc2100 daemon.info kernel: udevd[187]: starting version 182

On the other hand, if I execute the command:

# udevadm trigger --action=add

The /dev/modem link is created and everything work as expected. Am I
missing something? Must I configure something in order to trigger the
uevent after booting? Can it be related to this bub
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6ec0e55375c9687c7ead49d1e01f81b197db7108
?

All suggestions are welcome. Thanks in advance.

Regards

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Package generates RPM with lib${PN} - how to include in SDK

[Gaurang Shastri]

Hi Team,

I have one package X and recipe as X.bb, which generates RPM as
lib${X}-*.rpm

If I want this package as part of my SDK, what entry should i write in
meta-toolchain.bb file:

I tried adding "nativesdk-X" in meta-toolchain, but everytime it fails with:
ERROR: nativesdk-X not found in the base feeds (x86_64-nativesdk noarch any
all).

This is because RPM generates with the name libX-*.rpm.

Regards,
Gaurang Shastri
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Adjust for libexecdir changes

[Trevor Woerner]

On 02/24/16 15:28, Anders Darander wrote:

If the rest of the patches in that series is non-controversial, could we
have them applied? Otherwise, could we have Khem's patch applied, and
the other series rebased upon that?

We've had the master branch non-building for quite a while now...

I'm just keen to get either of those patches applied to
meta-raspberrypi. I'd like to avoid having to use a local fork as much
as possible...


+1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] : git tag and PV variable

[GUEYTAT Julien]

Perfect I'll give it a try! :)

-Message d'origine-
De : Maciej Borzecki [mailto:maciej.borze...@open-rnd.pl] 
Envoyé : mercredi 24 février 2016 19:10
À : yocto@yoctoproject.org; GUEYTAT Julien
Objet : Re: [yocto] : git tag and PV variable


> Dnia 24 luty 2016 o 17:02 Alexander Kanavin 
>  napisał(a):
>
>
> On 02/24/2016 05:35 PM, Khem Raj wrote:
> >
> > I have this command in my qmake pro files:
> >
> > VERSION = $$system(git describe --abbrev=0 --tags)
> >
> > __ __
> >
> > I would like to have the package manager follow the tag 
> > versioning.
> >
> > __ __
> >
> > Which means I would like to have something like:
> >
> > PV = "git describe --abbrev=0 --tags"
> >
> > SRC_URI = "${STUDIEL_GIT}/core.git;protocol=file;tag=${PV}"
> >
> > __ __
> >
> > It does not work for sure. What is the correct way to do this ?
> >
> >
> > ​SRC_URI is required by fetcher and there is nothing to git describe 
> > before it is fetched.​ so thats your problem.
>
> It's possible however to write an external script that updates the PV 
> version in the recipe, but it needs to be run outside of bitbake.
>

I actually wrote a class for this that works with externalsrc git packages. The 
idea was to replicate the functionality of gitpkgv but for external sources. 
The code is here:
https://github.com/open-rnd/meta-openrnd/blob/master/classes/externalgitsrc.bbclass

You just `inherit externalgitsrc` and it will set EXTERNALSRC_GIT_SRCREV and 
EXTERNALSRC_GITPKGV.

--
Maciej Borzęcki
Senior Software Engineer at Open-RnD Sp. z o.o.
www.open-rnd.pl, Facebook, Twitter
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto