Re: [yocto] recipe to clean up files from rootfs

[Mike Looijmans]

Well, start by sharing yours first.

Be careful when naming your shell routine, sometimes OE considers parts behind 
the underscore as overrides and then it cannot find it.



On 13-12-17 07:14, Sherif Omran wrote:

hi Mike,
i could not get it to work, if you have a recipe that works, please share it. 
ROOTFS_POSTPROCESS_COMMAND seems to be buggy.


thank you



On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans > wrote:


On 11-12-17 15:18, Sherif Omran wrote:

i want to create a recipe to clean some files from the rootfile
system, but i don't know how to let this recipe run the last one
before building the rootfile system.


You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do some
last-minute filesystem cleanup.

However, in most cases it's much better to determine what recipe puts the
files there and modify the recipe or remove the package. It would help a
lot if you would reveal what files you want to remove and why.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79 
E-mail: mike.looijm...@topicproducts.com

Website: www.topicproducts.com 

Please consider the environment before printing this e-mail



-- 



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



___

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] recipe to clean up files from rootfs

[Sherif Omran]

hi Mike,
i could not get it to work, if you have a recipe that works, please share
it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.

thank you

>
>
On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans 
wrote:

> On 11-12-17 15:18, Sherif Omran wrote:
>
>> i want to create a recipe to clean some files from the rootfile system,
>> but i don't know how to let this recipe run the last one before building
>> the rootfile system.
>>
>
> You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do some
> last-minute filesystem cleanup.
>
> However, in most cases it's much better to determine what recipe puts the
> files there and modify the recipe or remove the package. It would help a
> lot if you would reveal what files you want to remove and why.
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> --
> ___
> 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-raspberrypi] core-image-minimal vs rpi-hwup-image

[Sherif Omran]

hello guys,

Core-image-minimal has 75 MB and boots in max 12 sec but lacks wifi drivers.
rpi-hwup-image has 142.MB and boots in 18 sec.

how to add wifi drivers to core-image-minimal?

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

Re: [yocto] [PATCH 08/12] upgradehelper.py: clean repo only once when recipes are specified

[Robert Yang]

On 12/12/2017 08:26 PM, Alexander Kanavin wrote:

On 12/11/2017 08:13 AM, Robert Yang wrote:

I think it's a simpler and easier to understand approach. Yes, this means 
that an updated recipe that is close to the root of dependency tree can cause 
a cascade of build failures (e.g. glibc), but the update commits for 
everything else will still be created, and the maintainer can easily revert 
the failing updates, and re-run the build. What you think?


Yes, since glibc would causes others failed to build, so I removed the commited
during upgrading, and then apply it back, I think that this is more helpful than
leave the failed commit there and causes others failed.


How about simply issuing 'git revert' after a build has failed? That's easier to 
implement than rearranging the order of commits, and the commit message can 
include a link to the build failure logs.


Sounds reasonable to me, I will update the patch.

// Robert



Alex


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

Re: [yocto] executable depends on the library that is built in the same recipe

[Rail Shafigulin]

On Mon, Dec 11, 2017 at 8:18 PM, Vineeth Karumanchi
 wrote:
> using this might help
>
> oe_libinstall -so
>

Can you elaborate more on this? I'm not quite sure what it does.


-- 
Rail Shafigulin
Software Engineer
Esencia Technologies

-- 




*ESENCIA TECHNOLOGIES, INC.*3945 Freedom Circle, Suite #360,
Santa Clara CA 95054


Phone: +1 408 736 8284 Fax: +1 408 519 3475 
http://www.esenciatech.com | http://www.lnttechservices.com


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

Re: [yocto] [ptest-runner 1/3] Makefile: libcheck now requires to link subunit

[Anibal Limon]

On 12 December 2017 at 06:24, Joshua Lock 
wrote:

> This entire series merged to master of the ptest-runner2 repository.
>
> Will you be sending a recipe update?
>

Yes, can you create the v2.1.1 tag pointing current master?

Cheers,
Anibal


>
> Thanks,
> Joshua
>
>
> On 07/12/17 18:51, Aníbal Limón wrote:
>
>> From: Aníbal Limón 
>>
>> Signed-off-by: Aníbal Limón 
>> ---
>>   Makefile | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 434b89f..1bde7be 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -22,7 +22,7 @@ TEST_SOURCES=tests/main.c tests/ptest_list.c
>> tests/utils.c $(BASE_SOURCES)
>>   TEST_OBJECTS=$(TEST_SOURCES:.c=.o)
>>   TEST_EXECUTABLE=ptest-runner-test
>>   TEST_LDFLAGS=-lm -lrt -lpthread
>> -TEST_LIBSTATIC=-lcheck
>> +TEST_LIBSTATIC=-lcheck -lsubunit
>> TEST_DATA=$(shell echo `pwd`/tests/data)
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Add optional dependancies to the recipe

[Jerome.Haxhiaj]

Hi,
I'm building a recipe for a project where the final product will depends on
The fact that some dependencies are satisfied of not.
I would like to know I there is an environment variables that list all PROVIDES 
from all the layers,
in order to parse it and get the dependencies.

Jérôme Haxhiaj
Software Engineer

EB - Driving the Future of Automotive Software
Frankfurter Ring 117, 80807 München, Germany

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

Re: [yocto] [ptest-runner 1/3] Makefile: libcheck now requires to link subunit

[Joshua Lock]

On 12/12/17 14:18, Anibal Limon wrote:



On 12 December 2017 at 06:24, Joshua Lock > wrote:


This entire series merged to master of the ptest-runner2 repository.

Will you be sending a recipe update?


Yes, can you create the v2.1.1 tag pointing current master?


Done:

http://git.yoctoproject.org/clean/cgit.cgi/ptest-runner2/tag/?id=v2.1.1

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

Re: [yocto] recipe to clean up files from rootfs

[Mike Looijmans]

On 11-12-17 15:18, Sherif Omran wrote:
i want to create a recipe to clean some files from the rootfile system, but i 
don't know how to let this recipe run the last one before building the 
rootfile system.


You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do some 
last-minute filesystem cleanup.


However, in most cases it's much better to determine what recipe puts the 
files there and modify the recipe or remove the package. It would help a lot 
if you would reveal what files you want to remove and why.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

Re: [yocto] [PATCH 08/12] upgradehelper.py: clean repo only once when recipes are specified

[Alexander Kanavin]

On 12/11/2017 08:13 AM, Robert Yang wrote:

I think it's a simpler and easier to understand approach. Yes, this 
means that an updated recipe that is close to the root of dependency 
tree can cause a cascade of build failures (e.g. glibc), but the 
update commits for everything else will still be created, and the 
maintainer can easily revert the failing updates, and re-run the 
build. What you think?


Yes, since glibc would causes others failed to build, so I removed the 
commited
during upgrading, and then apply it back, I think that this is more 
helpful than

leave the failed commit there and causes others failed.


How about simply issuing 'git revert' after a build has failed? That's 
easier to implement than rearranging the order of commits, and the 
commit message can include a link to the build failure logs.


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

Re: [yocto] [ptest-runner 1/3] Makefile: libcheck now requires to link subunit

[Joshua Lock]

This entire series merged to master of the ptest-runner2 repository.

Will you be sending a recipe update?

Thanks,
Joshua

On 07/12/17 18:51, Aníbal Limón wrote:

From: Aníbal Limón 

Signed-off-by: Aníbal Limón 
---
  Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 434b89f..1bde7be 100644
--- a/Makefile
+++ b/Makefile
@@ -22,7 +22,7 @@ TEST_SOURCES=tests/main.c tests/ptest_list.c tests/utils.c 
$(BASE_SOURCES)
  TEST_OBJECTS=$(TEST_SOURCES:.c=.o)
  TEST_EXECUTABLE=ptest-runner-test
  TEST_LDFLAGS=-lm -lrt -lpthread
-TEST_LIBSTATIC=-lcheck
+TEST_LIBSTATIC=-lcheck -lsubunit
  
  TEST_DATA=$(shell echo `pwd`/tests/data)
  


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

[yocto] Setting LDFLAGS for all packages

[Blaettler, Michael]

Hello

The problem I'm currently facing is the removal (unset) of the LDFLAGS variable 
within the glibc compile step.

A bit of background information:
I'm working on reproducible builds and found one major problem which occurs by 
many of the packages. By default, the debug information is extracted from the 
build output and stored in a separate *-dbg package. GDB wants to do a matching 
before using a debug file for debugging. This matching is currently done by 
adding a debuglink to the binary. This link contains the filename and a CRC 
checksum of the corresponding debug file. Since the debug information is very 
specific, it's almost impossible to get them reproducible. In conclusion, the 
debuglink breaks reproducibility.
A short look into the gdb documentation 
(https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html) reveals 
another possibility to link a binary with its  debug information - the 
build-id. This build-id can either be generated by the linker or can be set to 
a fixed value. To ensure reproducibility, I hashed ${PF} in an anonymous-python 
function and passed the result to the build. In this case, I can guarantee a 
reproducible output as well as splitting debug information.

Long story short:
After first successful tests I decided to make my changes upstream, by 
introducing a new variable to specify the link style for debug files. Possible 
setting would be 'debuglink', 'build-id' and 'both'.
When using the debuglink option the flag "-build-id" must be passed to the 
linker. To have a reproducible glibc, it is not possible to set this flag in 
LDFLAGS, since this variable gets removed (unset) before compilation. The next 
idea was to pass it to TARGET_CC_ARCH. According to the documentation this is 
the way to deal with such an issue. But the next problem lured right there: 
libtool usese the "compiler call" to infer the build configuration. Since the 
build-id is now inside the "compiler call", it's not possible anymore for 
libtool to infer the configuration (the build id is different for every 
package).

Before the unset-command in the glibc recipe, there's the following comment:
"-Wl,-rpath-link /lib in LDFLAGS can cause breakage if another glibc 
is in staging"
Is this still required or is it a leftover from previous version where there 
weren't recipe specific sysrots?
If not, does anybody of you know, how I could set the flag without breaking 
libtool?

Thanks in advance

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