Re: [yocto] Building kernel backports for ARM with Yocto

[Khem Raj]

On Wed, Oct 18, 2017 at 3:13 PM, Marlon Smith  wrote:
> Hi everyone,
>
> I'm trying to build the Linux backports project to get updated wifi drivers
> on an older kernel.  The problem is that when building backports, it first
> builds several tools that need to be run natively before cross-compiling the
> rest of the project.
>
> I know how to write a bitbake recipe to compile natively, and how to write
> one to build for the target, but I can't figure out how to combine the two.
> The backports project has steps for LTIB:
>
>  %Build
>  export PATH=$UNSPOOF_PATH
>
>  make menuconfig prefix=%{_prefix} \
>CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
>ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
>KLIB_BUILD=${TOP}/rpm/BUILD/linux
>
>  export PATH=$SPOOF_PATH
>
>  make prefix=%{_prefix} \
>CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
>ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
>KLIB_BUILD=${TOP}/rpm/BUILD/linux
>
>
> I believe what I need is an equivalent to the line export PATH=$UNSPOOF_PATH
> but I can't find anything in the Yocto documentation or mailing lists that
> would be equivalent to that.
>
>
> Any help would be much appreciated!

You might try this out

https://github.com/kraj/meta-himvis/blob/master/recipes-kernel/linux-backports/linux-backports_4.14-rc4.bb

it does not work out of box but with few fixes here and there it should work

>
>
> Thanks
>
>
> Marlon
>
>
> --
> ___
> 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] Building kernel backports for ARM with Yocto

[Darcy Watkins]

I tried building backports under Yocto a few years back using Yocto daisy 
branch with kernel 3.4 for x86 and kernel 3.12 for ARM.  After a fair amount of 
pain I was able to get it to sort of work.  The problem was mainly a sysroot 
arm-wrestle between kernel and backports because they both generate the same 
kernel module packages.  It was a last-one-wins arm-wrestle.  It sort of worked 
OK with daisy branch, but newer yocto versions have stricter management of 
sysroots and staging areas.

I think what we need is some sort of virtual provider or alternatives scheme to 
make this work properly.

You can also run into problems related to exports to other out-of-tree modules 
but IIRC, it would only affect an out-of-tree module with an incompatible 
license.

I was able to run a few circa kernel 3.18 backports experimentally on a kernel 
3.4 and a kernel 3.12.  Eventually we just upgraded the kernel.  Another 
project I know of used backports to update their kernel source and then created 
a recipe to build kernel from that source.

The notes/questions I had in the end were:


  *   was building backports as out-of-tree kernel modules
  *   was concerned that this wouldn’t provide updated kernel staging source, 
particularly with respect to any updated includes
  *   wasn’t sure what would be propagated into the sysroot
  *   should consider the backports use case that patches the kernel source and 
then perhaps use this to generate patchset to be added to kernel recipe 
(bbappend)
  *   otherwise need to ensure proper handling of sysroot, staging, (as well as 
a notion of providers and/or alternatives like I mentioned earlier)

I haven’t touched this in years, but perhaps it may help a bit.

I think your best bet for short term is to use it to patch the kernel and then 
capture the changes as a patchset to add to a kernel recipe.



Regards,

Darcy

Darcy Watkins ::  Senior Staff Engineer, Firmware

SIERRA WIRELESS
Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100
13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
[P2]
dwatk...@sierrawireless.com :: 
www.sierrawireless.com

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Marlon Smith
Sent: October-18-17 3:14 PM
To: yocto@yoctoproject.org
Subject: [yocto] Building kernel backports for ARM with Yocto

Hi everyone,

I'm trying to build the Linux backports project to get updated wifi drivers on 
an older kernel.  The problem is that when building backports, it first builds 
several tools that need to be run natively before cross-compiling the rest of 
the project.

I know how to write a bitbake recipe to compile natively, and how to write one 
to build for the target, but I can't figure out how to combine the two.  The 
backports project has steps for LTIB:


 %Build

 export PATH=$UNSPOOF_PATH



 make menuconfig prefix=%{_prefix} \

   CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \

   ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \

   KLIB_BUILD=${TOP}/rpm/BUILD/linux



 export PATH=$SPOOF_PATH



 make prefix=%{_prefix} \

   CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \

   ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \

   KLIB_BUILD=${TOP}/rpm/BUILD/linux



I believe what I need is an equivalent to the line export PATH=$UNSPOOF_PATH 
but I can't find anything in the Yocto documentation or mailing lists that 
would be equivalent to that.



Any help would be much appreciated!



Thanks



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

Re: [yocto] Building kernel backports for ARM with Yocto

[Marlon Smith]

Darcy, thanks for the detailed reply!
Do you remember how you were able to get it to compile in the first
place?  I end up with this error:
./kconf/conf: 1: ./kconf/conf: Syntax error: word unexpected (expecting
")")
..because backports needs to compile conf for x86_64, but instead
compiles it for ARM.  Once that step is done, it needs to compile the
rest of the project for ARM, but this error stops it.
I think I could work around the sysroot arm-wrestle because of the way
our project is built, but haven't made it to that point yet.
Here's the bb file I'm using:
---
include backports.inc
SRCBRANCH = "linux-4.2.y"
LOCALVERSION = "v4.2.6-1-0-g90118c7"
SRCREV = "90118c7656bb55243620c9dc9cc3f12582b1807f"
DEPENDS += "linux-myproject"do_configure_prepend() {
export CROSS_COMPILE=${TARGET_PREFIX}
export ARCH=${TARGET_ARCH}
export KLIB_BUILD=${STAGING_KERNEL_DIR}
export KLIB=${STAGING_DIR_TARGET}
make
}
---
On Wed, 2017-10-18 at 22:53 +, Darcy Watkins wrote:
> I tried building backports under Yocto a few years back using Yocto
> daisy branch with kernel 3.4 for x86 and kernel 3.12 for ARM.  After
> a fair amount of pain I was able to get it to sort of work.  The
> problem was mainly a sysroot arm-wrestle between kernel and backports
> because they both generate the same kernel module packages.  It was a
> last-one-wins arm-wrestle.  It sort of worked OK with daisy branch,
> but newer yocto versions have stricter management of sysroots and
> staging areas.
>  
> I think what we need is some sort of virtual provider or alternatives
> scheme to make this work properly.
>  
> You can also run into problems related to exports to other out-of-
> tree modules but IIRC, it would only affect an out-of-tree module
> with an incompatible license.
>  
> I was able to run a few circa kernel 3.18 backports experimentally on
> a kernel 3.4 and a kernel 3.12.  Eventually we just upgraded the
> kernel.  Another project I know of used backports to update their
> kernel source and then created a recipe to build kernel from that
> source.
>  
> The notes/questions I had in the end were:
>  
> was building backports as out-of-tree kernel modules
> was concerned that this wouldn’t provide updated kernel staging
> source, particularly with respect to any updated includes
> wasn’t sure what would be propagated into the sysroot
> should consider the backports use case that patches the kernel source
> and then perhaps use this to generate patchset to be added to kernel
> recipe (bbappend)
> otherwise need to ensure proper handling of sysroot, staging, (as
> well as a notion of providers and/or alternatives like I mentioned
> earlier)
>  
> I haven’t touched this in years, but perhaps it may help a bit.
>  
> I think your best bet for short term is to use it to patch the kernel
> and then capture the changes as a patchset to add to a kernel recipe.
>  
>  
>  
> Regards,
>  
> Darcy
>  
> Darcy Watkins ::  Senior Staff Engineer, Firmware
>  
> SIERRA WIRELESS
> Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604
> 231 1100
> 13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
> [P2]
> dwatk...@sierrawireless.com :: www.sierrawireless.com
>  
> From: yocto-boun...@yoctoproject.org [mailto:yocto-bounces@yoctoproje
> ct.org] On Behalf Of Marlon Smith
> Sent: October-18-17 3:14 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] Building kernel backports for ARM with Yocto
>  
> Hi everyone,
>  
> I'm trying to build the Linux backports project to get updated wifi
> drivers on an older kernel.  The problem is that when building
> backports, it first builds several tools that need to be run natively
> before cross-compiling the rest of the project.
>  
> I know how to write a bitbake recipe to compile natively, and how to
> write one to build for the target, but I can't figure out how to
> combine the two.  The backports project has steps for LTIB:
>  
>  %Build
>  export PATH=$UNSPOOF_PATH
>  
>  make menuconfig prefix=%{_prefix} \
>    CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
>    ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
>    KLIB_BUILD=${TOP}/rpm/BUILD/linux
>  
>  export PATH=$SPOOF_PATH
>  
>  make prefix=%{_prefix} \
>    CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
>    ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
>    KLIB_BUILD=${TOP}/rpm/BUILD/linux
>  
> I believe what I need is an equivalent to the line export
> PATH=$UNSPOOF_PATH but I can't find anything in the Yocto
> documentation or mailing lists that would be equivalent to that.
>  
> Any help would be much appreciated!
>  
> Thanks
>  
> Marlon-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] more efficient debug kernel

[Robert Berger]

Hi,

I usually build a debug kernel with debug info included, which makes it 
run "suboptimal". Distros build the kernel with CONFIG_DEBUG_INFO 
enables, but strip symbols out of the resulting kernel and kernel 
modules, and place them in the separate debuginfo packages. This makes 
the kernel much smaller and also makes it run more efficiently because 
of caching.


Is this possible with the Yocto kernel tooling as well?

Regards,

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

[yocto] Building kernel backports for ARM with Yocto

[Marlon Smith]

Hi everyone,

I'm trying to build the Linux backports project to get updated wifi
drivers on an older kernel.  The problem is that when building
backports, it first builds several tools that need to be run natively
before cross-compiling the rest of the project.

I know how to write a bitbake recipe to compile natively, and how to
write one to build for the target, but I can't figure out how to
combine the two.  The backports project has steps for LTIB:

 %Build
 export PATH=$UNSPOOF_PATH
 
 make menuconfig prefix=%{_prefix} \
   CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
   ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
   KLIB_BUILD=${TOP}/rpm/BUILD/linux
 
 export PATH=$SPOOF_PATH
 
 make prefix=%{_prefix} \
   CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
   ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
   KLIB_BUILD=${TOP}/rpm/BUILD/linux

I believe what I need is an equivalent to the line export
PATH=$UNSPOOF_PATH but I can't find anything in the Yocto documentation
or mailing lists that would be equivalent to that.

Any help would be much appreciated!

Thanks

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

[yocto] [meta-raspberrypi] errors in tools-testapps when targeting raspberrypi3

[Steve Pavao]

Hello,

When I target raspberrypi3 and have tools-testapps listed in 
EXTRA_IMAGE_FEATURES in my local.conf, build errors occur.

The errors come from the building of mesa-demos and gst-player.  If I remove 
those targets from packagegroup-core-tools-testapps.bb, I don’t get errors.

The errors seem to relate to required settings of these variables in local.conf 
to match available packages:

PREFERRED_PROVIDER_virtual/egl
PREFERRED_PROVIDER_virtual/libgles1
PREFERRED_PROVIDER_virtual/libgles2
PREFERRED_PROVIDER_virtual/libgl
PREFERRED_PROVIDER_virtual/mesa

I tried setting these all to the value “mesa”, but then the gstreamer build 
seemed to demand a value of “userland” for at least one of the variables.  I 
wasn’t able to resolve the conflict.

Could someone please reply with the proper value of these and other 
configuration variables possibly needed to complete this build without having 
to hack packagegroup-core-tools-testapps.bb like I did, or else supply a proper 
fix?

Here are my local.conf settings of interest.  I’m building in pyro branch for 
everything, at current head.

MACHINE ??= “raspberrypi3"
IMAGE_INSTALL_append = " apt gdbserver perfcnt-enable mdns"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks x11-base tools-debug tools-testapps 
ssh-server-dropbear package-management"

- Steve Pavao
Korg R


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

Re: [yocto] minimize size of SW update bundle

[Paul Eggleton]

On Wednesday, 18 October 2017 3:11:59 AM NZDT Marc Ferland wrote:
> On Tue, Oct 17, 2017 at 9:12 AM, Robert Berger
>  wrote:
> > Hi,
> >
> > Imagine you have only a limited bandwidth to your devices available for SW
> > update. So you would like to minimize what's uploaded (over the air) to 
your
> > devices.
> >
> > How would you do this with yocto?
> >
> > [1] and [2] might be able to do incremental updates, but maybe there are
> > more ideas out there.
> >
> > Like how would you get a diff between two release builds...
> >
> 
> Some ideas:
> 
> - SquashFS with agressive compression settings can be quite
> impressive. I was able to reduce my image size from 650MB
> (uncompressed) down to maybe 120MB. This was for a complete system
> update though.
> - The new zstd algo from facebook looks promising (haven't tried it
> yet) and might be worth investigating, I think it is supported as a
> squashfs decompressor.
> - bsdiff can generate diffs from binary files (be carefull if diffing
> compressed files, i.e.: gzip --rsyncable).
> - there's also casync (never tried it): https://github.com/systemd/casync/

FWIW I have preliminary recipes for casync and zstd here, but I'm having 
trouble with some native dependencies not being populated properly when 
casync-native is pulled in by other recipes (or -c addto_recipe_sysroot), so 
it still needs work:

http://cgit.openembedded.org/meta-openembedded-contrib/log/?h=paule/casync

Cheers,
Paul

-- 

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

Re: [yocto] [AUH] Upgrade status: 2017-10-18

[Leonardo Sandoval]

On Wed, 18 Oct 2017 14:29:08 +0300
Alexander Kanavin  wrote:

> On 10/18/2017 02:08 PM, a...@auh.yoctoproject.org wrote:
> >  TOTAL: attempted=147 succeeded=25(17.01%) failed=122(82.99%)
> 
> With this kind of success rate, should we continue to run and develop 
> the thing?
> 
> I think it's better to just send notifications to maintainers without 
> attempting to update anything, as most of the time version updates need 
> manual rebasing of patches or other tweaks anyway.
> 
> I've submitted a small script to do just that:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143510.html
> 
> Instead, I'd rather see RRS fixed/improved - lots of issues there, some 
> of them very old.

About the AUH/RSS, this is an important point to discuss on the 2.5 planning 
and the best way is to point those old bugs in this phase. 

In the upgrade area, 'devtool upgrade' helps a lot in the starting phase of the 
upgrade (rebasing patches old version into new version) but as you mentioned, 
upgrades are not as easy as changing the revisions and of course once it 
'builds', manual testing is needed, at least the basic stuff. 

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


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

[yocto] Antwort: Where to find the udevadm monitor?

[S . Jaritz]

I figured out.

udevadm monitor ist provided by the SystemV package.

Problem solved!

Stefan 


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 181
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.



Von:s.jar...@esa-grimma.de
An: yocto@yoctoproject.org
Datum:  18.10.2017 11:42
Betreff:[yocto] Where to find the udevadm monitor?
Gesendet von:   yocto-boun...@yoctoproject.org



Hej, 

Actually I am playing a bit arround with udev rules. For that I like to 
use the udevadm monitor. The udev is provided by 

/meta/recipes-core/udev/eudev_3.2.2.bb 

In this recipe there is no udevadm option. While checking, I saw it was 
once in udev-utils and been moved to udev.inc. 

https://patchwork.openembedded.org/patch/73987/ 

Since then udev has been replaced with eudev. Seems that udevadm got 
"lost" by the move from udev to eudev - or it went to an other recipe. 

My question is: 

Where to find a recipe containing udevadm/what options I need to set to 
include this program? 

Regards 

Stefan


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 181
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
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] [AUH] Upgrade status: 2017-10-18

[Alexander Kanavin]

On 10/18/2017 02:08 PM, a...@auh.yoctoproject.org wrote:

 TOTAL: attempted=147 succeeded=25(17.01%) failed=122(82.99%)


With this kind of success rate, should we continue to run and develop 
the thing?


I think it's better to just send notifications to maintainers without 
attempting to update anything, as most of the time version updates need 
manual rebasing of patches or other tweaks anyway.


I've submitted a small script to do just that:
http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143510.html

Instead, I'd rather see RRS fixed/improved - lots of issues there, some 
of them very old.



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

[yocto] [AUH] Upgrade status: 2017-10-18

[auh]

AUH finished upgrade batch the result patches/logs can be found at:
https://logs.yoctoproject.org/auh//20171017113055, next are the statistics:

Recipe upgrade statistics:

* Succeeded: 25
libdrm, 2.4.84, Otavio Salvador 
python3-numpy, 1.13.3, Jose Lamego 
libunwind, 1.2.1, Bruce Ashfield 
xkeyboard-config, 2.22, Armin Kuster 
util-linux, 2.30.2, Chen Qi 
logrotate, 3.13.0, Robert Yang 
busybox, 1.27.2, Armin Kuster 
iso-codes, 3.76, Alexander Kanavin 
assimp, 4.0.1, Jussi Kukkonen 
lttng-ust, 2.10.0, Richard Purdie 
python-setuptools, 36.6.0, Jose Lamego 
harfbuzz, 1.6.0, Maxin B. John 
glew, 2.1.0, Jussi Kukkonen 
xdg-utils, 1.1.2, Jussi Kukkonen 
libxres, 1.2.0, Armin Kuster 
wayland-protocols, 1.11, Denys Dmytriyenko 
libgudev, 232, Jussi Kukkonen 
bluez5, 5.47, Maxin B. John 
quota, 4.04, Maxin B. John 
hicolor-icon-theme, 0.17, Jussi Kukkonen 
clutter-gtk-1.0, 1.8.4, Jussi Kukkonen 
ninja, 1.8.2, Khem Raj 
libdnf, 0.11.1, Alexander Kanavin 
sysprof, 3.26.1, Alexander Kanavin 
re2c, 1.0.1, Khem Raj 
* Failed(get_env): 1
boost, 1.65.1, Alexander Kanavin 
* Failed(do_patch): 2
subversion, 1.9.7, Richard Purdie 
openssl, 1.1.0f, Alexander Kanavin 
* Failed(do_compile): 6
libxml2, 2.9.6, Hongxu Jia 
iproute2, 4.13.0, Changhyeok Bae 
dbus-test, 1.10.24, Chen Qi 
lttng-modules, 2.10.2, Richard Purdie 

gdk-pixbuf, 2.36.11, Jussi Kukkonen 
libsdl2, 2.0.6, Robert Yang 
* Failed(other errors): 107
gstreamer1.0-plugins-good, 1.12.3, Maxin B. John 
gobject-introspection, 1.54.1, Alexander Kanavin 

sed, 4.4, Chen Qi 
fontconfig, 2.12.6, Jussi Kukkonen 
bash, 4.4.12, Hongxu Jia 
lz4, 131, Denys Dmytriyenko 
gstreamer1.0-vaapi, 1.12.3, Wei Tee Ng 
freetype, 387.5, Jussi Kukkonen 
openssh, 7.6p1, Armin Kuster 
man-pages, 4.13, Hongxu Jia 
texinfo, 6.5, Leonardo Sandoval 

libproxy, 0.4.15, Maxin B. John 
libva-utils, 2.0.0, Wei Tee Ng 
gstreamer1.0-rtsp-server, 1.12.3, Maxin B. John 
liberror-perl, 0.17025, Robert Yang 
binutils, 2.29.1, Khem Raj 
debianutils, 4.8.2, Robert Yang 
gsettings-desktop-schemas, 3.24.1, Jussi Kukkonen 

psmisc, 23.1, Alexander Kanavin 
flex, 2.6.4, Chen Qi 
dtc, 7.4, Alexander Kanavin 
expect, 5.45.3, Alexander Kanavin 
qemu, 2.10.1, Leonardo Sandoval 

vala, 0.38.2, Alexander Kanavin 
e2fsprogs, 1.43.7, Robert Yang 
glib-networking, 2.54.0, Jussi Kukkonen 
gnutls, 3.6.0, Armin Kuster 
gtk+3, 3.22.24, Jussi Kukkonen 
dnf, 2.7.4, Alexander Kanavin 
expat, 2.2.4, Dengke Du 
sysstat, 11.6.0, Chen Qi 
ltp, 20170929, Dengke Du 
dbus, 1.10.24, Chen Qi 
libnsl2, 1.1.0+gitAUTOINC+1f84b0cac3, Khem Raj 
gtk-doc, 1.26, Alexander Kanavin 
libsolv, 0.6.29, Maxin B. John 

[yocto] Where to find the udevadm monitor?

[S . Jaritz]

Hej,

Actually I am playing a bit arround with udev rules. For that I like to 
use the udevadm monitor. The udev is provided by 

/meta/recipes-core/udev/eudev_3.2.2.bb

In this recipe there is no udevadm option. While checking, I saw it was 
once in udev-utils and been moved to udev.inc.

https://patchwork.openembedded.org/patch/73987/

Since then udev has been replaced with eudev. Seems that udevadm got 
"lost" by the move from udev to eudev - or it went to an other recipe.

My question is:

Where to find a recipe containing udevadm/what options I need to set to 
include this program?

Regards

Stefan


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 181
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mono 5.2.x recipe and pdb files

[Alex J Lennon]

> On 18 Oct 2017, at 07:22, Craig McQueen  wrote:
> 
> I wrote:
>> 
>> I'm trying to upgrade from mono 4.6.x to 5.2.x. I see resulting image size
>> increases by about 10 MB in my usage. It appears that a significant
>> contributing factor is the presence of *.pdb files in 5.2.x which weren't in
>> 4.6.x.
>> 
>> * Are the *.pdb files necessary?
>> * What can  be done to exclude them?
> 
> Seeing how the recipe handles *.mdb files, I made a bbappend file containing:
> 
> FILES_${PN}-dbg+= "${libdir}/mono/*/*.pdb ${libdir}/mono/*/*/*.pdb 
> ${libdir}/mono/gac/*/*/*.pdb"
> 
> That seems to do it. This should probably be added to the mono recipe files 
> for mono >= 5.0.x.
> 


Sounds good. I’ll take a look at this in the next couple of days.

Cheers,

Alex

> -- 
> Craig McQueen
> 

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

Re: [yocto] meta-mono 5.2.x recipe and pdb files

[Craig McQueen]

I wrote:
> 
> I'm trying to upgrade from mono 4.6.x to 5.2.x. I see resulting image size
> increases by about 10 MB in my usage. It appears that a significant
> contributing factor is the presence of *.pdb files in 5.2.x which weren't in
> 4.6.x.
> 
> * Are the *.pdb files necessary?
> * What can  be done to exclude them?

Seeing how the recipe handles *.mdb files, I made a bbappend file containing:

FILES_${PN}-dbg += "${libdir}/mono/*/*.pdb ${libdir}/mono/*/*/*.pdb 
${libdir}/mono/gac/*/*/*.pdb"

That seems to do it. This should probably be added to the mono recipe files for 
mono >= 5.0.x.

-- 
Craig McQueen

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