| *** sagner <sagner!~ags@37.17.239.109> has quit IRC | 00:08 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 00:20 | |
| *** arielm <arielm!~quassel@201.157.98.2> has quit IRC | 00:23 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 00:28 | |
| *** berton_ <berton_!~berton@177.194.204.148> has quit IRC | 00:29 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 00:40 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-cnabhtjbhgqrlrho> has quit IRC | 00:55 | |
| *** HyP3r <HyP3r!~HyP3r@andreas-fendt.de> has quit IRC | 01:00 | |
| *** HyP3r <HyP3r!~HyP3r@andreas-fendt.de> has joined #yocto | 01:00 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 01:05 | |
| *** black_13 <black_13!6c0cda8d@gateway/web/freenode/ip.108.12.218.141> has joined #yocto | 01:06 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 01:06 | |
| black_13 | what would cause a problem with connecting to the bitback server | 01:07 |
|---|---|---|
| black_13 | or rather http://codepad.org/hKh0Bti2 | 01:07 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-kuxtivohllautawz> has joined #yocto | 01:21 | |
| black_13 | what would cause "ERROR: Unable to connect to bitbake server, or start one" | 01:54 |
| black_13 | the most obvious is that you cant connect | 01:54 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 01:55 | |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto | 01:57 | |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has quit IRC | 02:00 | |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto | 02:00 | |
| *** berton <berton!~berton@177.194.204.148> has joined #yocto | 02:06 | |
| black_13 | the reason is that i was build in a shared directory | 02:08 |
| *** otavio <otavio!~otavio@177.194.204.148> has joined #yocto | 02:11 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 02:11 | |
| *** onlyesterday16 <onlyesterday16!~onlyester@113.160.58.178> has joined #yocto | 02:37 | |
| *** black_13 <black_13!6c0cda8d@gateway/web/freenode/ip.108.12.218.141> has quit IRC | 02:39 | |
| *** ankit <ankit!~apnavik@192.55.54.42> has joined #yocto | 03:12 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto | 03:47 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 04:09 | |
| *** anujm <anujm!anujm@nat/intel/x-agdxkdcahzcjlsnc> has joined #yocto | 04:47 | |
| *** Jackie <Jackie!~quassel@60.247.85.82> has quit IRC | 04:55 | |
| *** Jackie_ <Jackie_!~quassel@60.247.85.82> has joined #yocto | 04:56 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 05:34 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-kuxtivohllautawz> has quit IRC | 05:55 | |
| *** anujm <anujm!anujm@nat/intel/x-agdxkdcahzcjlsnc> has quit IRC | 06:07 | |
| *** agust <agust!~agust@p54833194.dip0.t-ipconnect.de> has joined #yocto | 06:49 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC | 06:52 | |
| *** zino_ <zino_!~zino@2-230-204-206.ip203.fastwebnet.it> has joined #yocto | 07:06 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 07:09 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:35 | |
| lukma | Is there any way to see arguments of nested functions (either with bash/python) without the need to recompile everything? | 07:35 |
| lukma | For example the staging.bbclass | 07:35 |
| lukma | we do have in it: python·do_populate_sysroot -> bb.build.exec_func("sysroot_stage_all",·d) -> sysroot_stage_dirs·${D}·${SYSROOT_DESTDIR}$ | 07:36 |
| lukma | In the debug (-v) I only see the "sysroot_stage_all" executed | 07:36 |
| lukma | but no functions nested | 07:37 |
| lukma | If I add bb.note() then I do need to rebuild everything | 07:37 |
| lukma | is there any switch which would allow me to see the arguments? | 07:37 |
| lukma | (-DD neither -v is not working) | 07:37 |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 07:51 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:51 | |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto | 08:04 | |
| *** lusus <lusus!~lusus@62.91.23.180> has joined #yocto | 08:06 | |
| *** fl0v0 <fl0v0!~fvo@i577A6E18.versanet.de> has joined #yocto | 08:07 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 08:10 | |
| *** marble_visions <marble_visions!~user@68.183.79.8> has quit IRC | 08:11 | |
| *** marble_visions <marble_visions!~user@68.183.79.8> has joined #yocto | 08:13 | |
| *** gtristan <gtristan!~tristanva@114.207.54.12> has joined #yocto | 08:15 | |
| *** mckoan|away is now known as mckoan | 08:19 | |
| *** gtristan <gtristan!~tristanva@114.207.54.12> has quit IRC | 08:21 | |
| *** gtristan <gtristan!~tristanva@114.207.54.12> has joined #yocto | 08:22 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has joined #yocto | 08:23 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has left #yocto | 08:24 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:24 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has joined #yocto | 08:24 | |
| *** tristanram_ <tristanram_!3e029902@gateway/web/freenode/ip.62.2.153.2> has joined #yocto | 08:24 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 08:26 | |
| *** jofr <jofr!~jofr@193.182.166.3> has left #yocto | 08:32 | |
| *** sagner <sagner!~ags@46.140.72.82> has joined #yocto | 08:32 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 08:36 | |
| *** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 08:37 | |
| *** sb79a <sb79a!~sb79a@80-95-88-59.pool.digikabel.hu> has joined #yocto | 08:38 | |
| *** willie_ <willie_!d973313a@gateway/web/freenode/ip.217.115.49.58> has joined #yocto | 08:40 | |
| *** tristanram_ <tristanram_!3e029902@gateway/web/freenode/ip.62.2.153.2> has quit IRC | 08:40 | |
| *** Willie <Willie!d973313a@gateway/web/freenode/ip.217.115.49.58> has quit IRC | 08:44 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:47 | |
| *** lazyape <lazyape!~lazyape@athedsl-212890.home.otenet.gr> has quit IRC | 08:52 | |
| *** sb79a <sb79a!~sb79a@80-95-88-59.pool.digikabel.hu> has quit IRC | 08:52 | |
| *** sb79a <sb79a!~sb79a@254C6480.nat.pool.telekom.hu> has joined #yocto | 08:53 | |
| *** sb79a__ <sb79a__!~sb79a@80-95-88-59.pool.digikabel.hu> has joined #yocto | 09:00 | |
| *** cvasilak <cvasilak!~cvasilak@athedsl-307092.home.otenet.gr> has joined #yocto | 09:01 | |
| *** sb79a <sb79a!~sb79a@254C6480.nat.pool.telekom.hu> has quit IRC | 09:02 | |
| *** Saur <Saur!pkj@nat/axis/x-mknalnhnlhycryiz> has quit IRC | 09:10 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:13 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 09:19 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 09:19 | |
| willie_ | Hello, Is it possible to modify splash screen more than just to change the image with psplash? | 09:19 |
| willie_ | I would like to turn image + load bar upside down but i have so far been unable | 09:20 |
| RP | willie_: its a very simple piece of code so I suspect it is possible but you'd have to edit it | 09:20 |
| *** tristanram_ <tristanram_!3e029902@gateway/web/freenode/ip.62.2.153.2> has joined #yocto | 09:21 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 09:21 | |
| willie_ | thanks RP, are you refering to the "make-image-header" script? I'll have a look at it :) | 09:22 |
| tristanram_ | kanavin: RP told me to talk to you about this. | 09:24 |
| tristanram_ | kanavin: I think I found an issue concerning .pyc files in both the 3.5.x and the new 3.7.2 recipes: The file modification timestamp in the .pyc files lags behind the file filestamp of the actual .py files and thus precompiling them is of no use. | 09:24 |
| RP | kanavin: I know you looked at this, I can't remember what the conclusion was though | 09:25 |
| RP | willie_: you'd also have to look at the code drawing the progress bar as it would need to be rotated too | 09:25 |
| *** Saur <Saur!pkj@nat/axis/x-glkpdjicfjpuefup> has joined #yocto | 09:28 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 09:28 | |
| *** Saur <Saur!pkj@nat/axis/x-glkpdjicfjpuefup> has quit IRC | 09:29 | |
| *** Saur <Saur!pkj@nat/axis/x-epmlgszhsiowljlp> has joined #yocto | 09:30 | |
| willie_ | @RP, turns out i could simply edit the init file! | 09:41 |
| *** florian_kc is now known as florian | 09:49 | |
| *** gtristan <gtristan!~tristanva@114.207.54.12> has quit IRC | 09:54 | |
| *** gtristan <gtristan!~tristanva@114.207.54.12> has joined #yocto | 09:54 | |
| *** peacememories <peacememories!~textual@2a02:8388:8480:fd80:8028:1943:a314:4a28> has joined #yocto | 10:06 | |
| *** peacememories <peacememories!~textual@2a02:8388:8480:fd80:8028:1943:a314:4a28> has quit IRC | 10:11 | |
| kanavin | tristanram_, RP: I compared the .pyc files between two multilib installations, but I did not compare the timestamps vs the original .py files, assuming that python installation would take care of them being right | 10:12 |
| kanavin | tristanram_, if you have a reproducer for the issue, we could take a look | 10:13 |
| tristanram_ | kanavin: could it be that during the packaging process or some late build stage the .py files are copied around and thus the mtime changed? | 10:14 |
| tristanram_ | kanavin: Also, where are the .pyc generated in the python3 recipe? For python2.7 it was in distutils.bbclass i think | 10:14 |
| kanavin | tristanram_, I don't know to be honest :) | 10:14 |
| kanavin | my goal was to make builds green and tests (including on-target ones) pass, I only looked into what is going on when there were issues :) | 10:15 |
| kanavin | with this, there were no visible issues and so I didn't look | 10:15 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:18 | |
| tristanram_ | kanavin: RP told me on #oe that there are no tests to check those .pyc files. | 10:20 |
| kanavin | I don't think so. Can you write one? | 10:20 |
| kanavin | how did you discover the issue? | 10:21 |
| tristanram_ | kanavin: Possibly, but first I would have to find out where those .pyc files are generated, why the mtime of the .py files changed since the .pyc creation and fix that. Else you would just have a test which would always fail. | 10:22 |
| tristanram_ | kanavin: I most use a readonly rfs. I recently started python in verbose (python3 -vv -c"") to check where the long interpreter startup time might some from. | 10:23 |
| tristanram_ | kanavin: I was able to spot many messages like "bytecode is stale for 'site'" | 10:24 |
| kanavin | tristanram_, ah, right. | 10:24 |
| tristanram_ | Since my rfs is readonly, I have them everytime. Python3 of course works, but I think it always tries to compile py to pyc only then to find out that the rfs is readonly: '/usr/lib/python3.7/__pycache__/site.cpython-37.pyc': OSError(30, 'Read-only file system') | 10:25 |
| tristanram_ | kanavin: As my focus is on fast boot time, I think it would be better if the .pyc files where actually not stale | 10:26 |
| *** TafThorne <TafThorne!~thomas@158.255.10.131> has left #yocto | 10:26 | |
| tristanram_ | kanavin: Can I be of any assistance with helping you to recreate this issue on your side? | 10:28 |
| RP | tristanram_: the trouble is we're rather constrained on people with time to look into things like this :( | 10:28 |
| kanavin | tristanram_, I cannot promise I will solve it in good time. Too much on my plate. | 10:29 |
| RP | tristanram_: We definitely should have a bug opened for it but I know we're struggling to find people with time to work on such things :( | 10:29 |
| kanavin | tristanram_, obviously we would greatly appreciate any help from you, but the optimal way is that you look into the issue, and devise a solution and a regression test. I can promise that anything you send will be reviewed promptly :) | 10:31 |
| *** ankit <ankit!~apnavik@192.55.54.42> has quit IRC | 10:32 | |
| tristanram_ | kanavin, RP: I can try to have a look at it as one of my sideprojects :). Should I open an issue on https://bugzilla.yoctoproject.org for this? | 10:33 |
| RP | tristanram_: yes please, we should track it | 10:34 |
| tristanram_ | kanavin, RP: Ok, I will open an issue then. If I start looking into it, I would start looking into to packaging process. I did not yet look into the packaging process. Where can I find any kind of documentation on how the build output is processed and then lands in the image at the very end? | 10:37 |
| *** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has joined #yocto | 10:38 | |
| RP | tristanram_: Not to be funny, but the manuals? | 10:38 |
| RP | tristanram_: basially do_install is run under a fakeroot environment called pseudo, do_package (package.bbclass) does lots of processing of the files including splitting into packages, then do_package_write_XXX writes out the package | 10:39 |
| RP | tristanram_: the image is then built from the packages | 10:39 |
| RP | tristanram_: so first step is to look at the contents of the packages and see if the times match inside those. That would then be a rootfs or packaging issue depending on what you fine | 10:40 |
| RP | find | 10:40 |
| tristanram_ | RP: The manuals would have been among the first thinks I checked. But I just asked because there might be some "hidden" comment-based-doc in some bbclass that you might know of by heart ;) | 10:43 |
| RP | tristanram_: Our manuals are pretty comprehensive, to the point you may struggle to find the info you want. That's partly why I gave you a set of keywords above | 10:44 |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 10:47 | |
| *** cquast <cquast!~cquast@90.85.130.193> has joined #yocto | 10:49 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 10:50 | |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 11:09 | |
| sk_tandt | Greetings! I've built a GTK3 app, and integrated it in an image i cloned from core-weston (which includes gtk3-demo) : it goes into segfault as soon as it is done building the template | 11:12 |
| sk_tandt | The same code works on the host | 11:12 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 11:13 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 11:14 | |
| tristanram_ | RP: Ok here is the issue https://bugzilla.yoctoproject.org/show_bug.cgi?id=13186 | 11:15 |
| yocti | Bug 13186: normal, Undecided, ---, paul.eggleton, NEW , Precompiled python3 bytecode is stale | 11:15 |
| tristanram_ | RP: It might also be possible to make use of the new python 3.7 hash based byte code invalidation mode | 11:16 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 11:16 | |
| RP | tristanram_: kanavin mentioned that, we worried it meant a lot of startup overhead hashing files though | 11:17 |
| tristanram_ | RP: Yes, that's what I would be worried too. Even if the hash method is blake2, it might take quite some time to read every file. | 11:18 |
| tristanram_ | RP: But for "readonly" rfs, UNCHECKED_HASH might be the best solution | 11:18 |
| RP | tristanram_: we don't know a given python is going to end up on a readonly rootfs in advance. Can you set that somewhere at runtime? | 11:19 |
| tristanram_ | RP: I know in my case: EXTRA_IMAGE_FEATURES = "read-only-rootfs" | 11:20 |
| tristanram_ | RP: Why not just check if "read-only-rootfs" is set? | 11:20 |
| RP | tristanram_: right, but what I mean is can the rootfs code tweak the python to use UNCHECKED_HASH | 11:20 |
| tristanram_ | RP: Ah, is the EXTRA_IMAGE_FEATURES not globally available? | 11:21 |
| RP | tristanram_: we don't build a custom python for each image! :) | 11:22 |
| tristanram_ | RP: Hmm ok, I see. Maybe my world is just too small with only my one image ;). | 11:24 |
| *** berton <berton!~berton@177.194.204.148> has quit IRC | 11:36 | |
| *** berton <berton!~berton@177.194.204.148> has joined #yocto | 11:37 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 11:38 | |
| *** onlyesterday16 <onlyesterday16!~onlyester@113.160.58.178> has quit IRC | 11:43 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has quit IRC | 11:46 | |
| *** berton <berton!~berton@177.194.204.148> has quit IRC | 11:47 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 11:54 | |
| *** sergius_lane <sergius_lane!b4fe1144@gateway/web/cgi-irc/kiwiirc.com/ip.180.254.17.68> has joined #yocto | 12:18 | |
| sergius_lane | https://downloadlagu-mp3.club/ | 12:18 |
| *** sergius_lane <sergius_lane!b4fe1144@gateway/web/cgi-irc/kiwiirc.com/ip.180.254.17.68> has quit IRC | 12:18 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 12:42 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 12:46 | |
| *** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has quit IRC | 13:02 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 13:03 | |
| RP | kanavin: btw, did I do the right thing in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c29ec9bf57486018e61ea90fb9314fbb76879eac ? Not sure its quite showing up in the rrs as we'd want? | 13:05 |
| *** yacar_ <yacar_!~yacar_@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 13:05 | |
| *** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has joined #yocto | 13:05 | |
| kanavin | RP: at least from the AUH perspective it's right, it will skip the recipe from now on | 13:06 |
| RP | kanavin: I wasn't sure if that was the right variable to use... | 13:06 |
| kanavin | RP: we have it in several recipes in oe-core | 13:08 |
| *** inisider <inisider!ad26d10b@gateway/web/freenode/ip.173.38.209.11> has quit IRC | 13:08 | |
| RP | kanavin: that is fine, just wanted to check, thanks | 13:09 |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has quit IRC | 13:20 | |
| RP | kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/532 :( | 13:24 |
| *** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 13:28 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 13:32 | |
| tristanram_ | RP: Timestamp in "tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/python3/3.7.2-r0/image" are correct but timestamps in the tar and ubifs are newer | 13:37 |
| kanavin | tristanram_, next step is to check the timestamps in packages/ and package-split/ | 13:39 |
| tristanram_ | kanavin: those are also correct. Whats the next step? | 13:40 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 13:43 | |
| kanavin | tristanram_, check the content of actual package files in deploy-*/ | 13:44 |
| kanavin | you can usually 'unpack' those from the command line, not sure what package format are you using | 13:45 |
| kanavin | tristanram_, or you can skip to the do_rootfs step for your image and see what gets written to the rootfs/ directory in the image's ${WORKDIR} | 13:46 |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 13:46 | |
| tristanram_ | kanavin: ok, I will take a ipk from the deploy folder and check its contents next | 13:48 |
| kanavin | RP: that's a centos 7 specific failure, I'll grab lunch and get back to it | 13:49 |
| RP | tristanram_: ar -x should "open" the ipk, its like a deb | 13:50 |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 13:51 | |
| *** ankit <ankit!apnavik@nat/intel/x-rjctpzoqpghcyfuy> has joined #yocto | 13:53 | |
| tristanram_ | RP, kanavin: Ty, timestamp is altered in the extracted ipk | 14:00 |
| tristanram_ | RP, kanavin: image: ok, package: ok, package-split: ok, ipk: nok | 14:00 |
| *** gtristan <gtristan!~tristanva@114.207.54.12> has quit IRC | 14:01 | |
| RP | tristanram_: ok, that means its something to do with opkg-build in package_ipk.bbclass | 14:03 |
| RP | tristanram_: looking at opkg-build in the opkg-utils-native recipe, its using --mtime=@$build_date | 14:05 |
| RP | (to tar) | 14:06 |
| tristanram_ | RP: the mtime argument would explain the different timestamps | 14:07 |
| RP | tristanram_: yes. I think this is an effort to make it reproducible which has broken the python embedded timestamp | 14:08 |
| *** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto | 14:09 | |
| RP | tristanram_: nice thing is its a shell script so you could hack it easily | 14:11 |
| tristanram_ | RP: i could add a patch for opkg-build in my layer | 14:15 |
| tristanram_ | RP: I'm gonna try that and see if it works for me. But I'm thinking about a less hacky fix | 14:18 |
| RP | tristanram_: I don't think that --mtime option should be being applied to data.tar.gz, only the control one | 14:19 |
| RP | tristanram_: I'm hoping Alejandro, the opkg maintainer is around later. You could put the details in the bug and cc him there | 14:19 |
| sk_tandt | So, a GTK app runs perfectly with a simple scp to a fresh-minted Debian 9 VM, will segfault on Yocto in spite of any added library. Any hint on how to debug this? | 14:20 |
| kanavin | sk_tandt, with gdb? | 14:21 |
| LetoThe2nd | sk_tandt: 1) use proper toolchain 2) use proper toolchain 3) use proper toolchain :) | 14:21 |
| RP | tristanram_: it was a recent change: http://git.yoctoproject.org/cgit.cgi/opkg-utils/commit/?id=682f8c5e35b8854a9bb858b8ee1714d27e0c00db | 14:21 |
| *** sb79a__ <sb79a__!~sb79a@80-95-88-59.pool.digikabel.hu> has quit IRC | 14:21 | |
| RP | er, a year ago even :/ | 14:21 |
| LetoThe2nd | sk_tandt: besides that, strace, and check that you are using a proper toolchain :) | 14:21 |
| tristanram_ | RP: Oh, nice in that case it might be fixable this way. I will update the issue in bugzilla | 14:21 |
| sk_tandt | LetoThe2nd, proper toolchain? | 14:23 |
| LetoThe2nd | sk_tandt: -> the toolchain that matches the image on the target in use, specifically its ABI | 14:26 |
| LetoThe2nd | sk_tandt: thats why there are ways to create an sdk/esdk | 14:27 |
| sk_tandt | I'm afraid I'm not following: I suppose that has a purpose only for debugging, right? | 14:28 |
| LetoThe2nd | sk_tandt: no. it has a purpose specifically to compile for the target | 14:29 |
| sk_tandt | Mh, then I'm afraid I'm missing something. Once I've set a machine (Say, qemux86-64), added necessary layers and added packages with IMAGE_INSTALL entries, isn't everything in place? | 14:33 |
| kanavin | sk_tandt, how did you build the binary? | 14:34 |
| kanavin | for your app? | 14:34 |
| LetoThe2nd | sk_tandt: the point is rather: where are you compiling? using which toolchain, provided by whom? which headers for the libraries? | 14:34 |
| *** sagner <sagner!~ags@46.140.72.82> has quit IRC | 14:34 | |
| LetoThe2nd | sk_tandt: thats exactly why you can use -c populate_sdk to generate a toolchain that comes with the sysroot matching the image. | 14:35 |
| sk_tandt | kanavin, I've added DEPENDS += "gtk+3" | 14:35 |
| sk_tandt | LetoThe2nd, I was following the Yocto Quick Build guide, but I'm starting to assume that isn't viable? | 14:38 |
| *** gtristan <gtristan!~tristanva@110.11.179.2> has joined #yocto | 14:38 | |
| LetoThe2nd | sk_tandt: the quick build guide is good, but you are still not telling us how you are building what, and how it relates to that debian vm you mentioned | 14:38 |
| LetoThe2nd | sk_tandt: so, lets start at the beginning. you have an application in source, right? | 14:39 |
| sk_tandt | Yep! | 14:41 |
| LetoThe2nd | sk_tandt: and how are you *BUILDING* the application? | 14:41 |
| *** sagner <sagner!~ags@46.140.72.82> has joined #yocto | 14:41 | |
| sk_tandt | Autotools, as generated by the Yocto Eclipse plugin | 14:42 |
| LetoThe2nd | sk_tandt: and how are you *TRIGGERING* the autotools build? what is the very definitive, manual action that you do that starts the building process? | 14:42 |
| sk_tandt | ...should there be one? I thought adding a recipe to an image and invoking "bitbake my-image" would've done it automatically | 14:43 |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 14:43 | |
| LetoThe2nd | if you have added it to the image and are building the image, then this is the action, yes. but you haven't ever mentioned that so far. | 14:44 |
| sk_tandt | Sorry, my bad | 14:44 |
| sk_tandt | I did | 14:44 |
| LetoThe2nd | sk_tandt: so you build the image, the application gets automatically built and included, right? | 14:44 |
| sk_tandt | Yup, I can find the executable within /usr/bin | 14:45 |
| sk_tandt | And even the files that must be copied during the installation | 14:45 |
| LetoThe2nd | ok. so now what does that have to do with the debian vm then? | 14:45 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 14:46 | |
| sk_tandt | I wanted to figure out was was missing in the built image for the app to work | 14:47 |
| sk_tandt | And/or reproduce the problem with the source code | 14:48 |
| LetoThe2nd | sk_tandt: please, stop annotating the non-given asnwers. are took the binary from the target build and copied it out, or what? | 14:48 |
| LetoThe2nd | i mean, we can't see what you are doing. so if you tell or explain something, be sure to include all bits and pieces. do not take any circumstances for granted. | 14:52 |
| LetoThe2nd | my bets are that you are taking some assumuption about the system that the application shall run on somewhere, but don't check it explicitly | 14:53 |
| LetoThe2nd | but starting inside gdb and waiting for a backtrace to hit might give you a hint. | 14:54 |
| *** cvasilak <cvasilak!~cvasilak@athedsl-307092.home.otenet.gr> has quit IRC | 14:58 | |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC | 14:59 | |
| sk_tandt | Sorry, got back: LetoThe2nd, you're quite right, missed the balance between dumping too much and not giving enough info | 15:04 |
| sk_tandt | The built executable was indeed scp'ed to the end vm, and not rebuilt | 15:04 |
| sk_tandt | As for setting up gdb, will come back as soon as I have something! | 15:05 |
| kanavin | sk_tandt, so you transferred some pre-built binary into the qemu image? don't do that, write a recipe for your code, make sure the image pulls in the package produced by the recipe. | 15:07 |
| sk_tandt | kanavin, nope: I did build a recipe for the app, but I tried to replicate its issues copying the built executable in a vm | 15:08 |
| *** willie <willie!d973313a@gateway/web/freenode/ip.217.115.49.58> has joined #yocto | 15:09 | |
| *** willie_ <willie_!d973313a@gateway/web/freenode/ip.217.115.49.58> has quit IRC | 15:09 | |
| LetoThe2nd | kanavin: as far as i understood it, he copied the recipe-built binary out. hence my assumption that the autotools/build process of the app makes an assumption somewhere, and does not properly chack it. | 15:09 |
| LetoThe2nd | s/chack/check/g | 15:10 |
| willie | Can someone point on my error in this thought process.. If i set "logo.nologo" at the end of mmcargs i can succesfully boot without tux | 15:13 |
| willie | But when i try to re-compile with "rootfstype=${rootfstype}" \ "logo.nologo\0" \ at the end of mmcargs i get kernel panic | 15:14 |
| willie | recompiling u-boot that is | 15:14 |
| *** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has quit IRC | 15:14 | |
| *** ankit <ankit!apnavik@nat/intel/x-rjctpzoqpghcyfuy> has quit IRC | 15:17 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 15:21 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:21 | |
| kanavin | RP: fix for gdk-pixbuf sent | 15:24 |
| tristanram_ | RP: Just patched away the --mtime stuff and no more stale .pyc's. Only matches. Interpreter startup time on my embedded board at idle dropped from 5s to around 1s. | 15:26 |
| kanavin | tristanram_, you need to discuss this with opkg upstream I guess | 15:30 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 15:43 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 15:46 | |
| *** sagner <sagner!~ags@46.140.72.82> has quit IRC | 15:51 | |
| *** sagner <sagner!~ags@46.140.72.82> has joined #yocto | 15:53 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 15:53 | |
| *** oob <oob!~paulg@198.84.145.62> has joined #yocto | 15:53 | |
| *** willie <willie!d973313a@gateway/web/freenode/ip.217.115.49.58> has quit IRC | 15:54 | |
| *** arielm <arielm!~quassel@192.100.196.156> has joined #yocto | 15:54 | |
| *** arielm <arielm!~quassel@192.100.196.156> has left #yocto | 15:55 | |
| *** oob <oob!~paulg@198.84.145.62> has quit IRC | 15:58 | |
| *** paulg <paulg!~paulg@24-246-4-37.cable.teksavvy.com> has quit IRC | 15:59 | |
| sk_tandt | How may I know if my Eclipse is pointing to the correct toolchain? | 16:04 |
| LetoThe2nd | sk_tandt: just don't use it :P | 16:04 |
| LetoThe2nd | sk_tandt: sorry to but the eclipse plugin is mostly unmaintained and problem ridden | 16:05 |
| LetoThe2nd | *say. | 16:06 |
| sk_tandt | Oh, nice! I was using it to generate the autotools configuration files: is that part of the plugin bugged ? | 16:08 |
| LetoThe2nd | consider every part being bugged. | 16:10 |
| sk_tandt | Sigh, thanks | 16:10 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:13 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 16:14 | |
| *** paulg <paulg!~paulg@198.84.145.62> has joined #yocto | 16:17 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 16:19 | |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 16:23 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 16:26 | |
| *** adelcast <adelcast!~adelcast@130.164.62.198> has joined #yocto | 16:29 | |
| *** cquast <cquast!~cquast@90.85.130.193> has quit IRC | 16:30 | |
| kanavin | RP: I also sent a patch for glib meson issue (core-image-full-cmdline failures) | 16:31 |
| *** willie <willie!d973313a@gateway/web/freenode/ip.217.115.49.58> has joined #yocto | 16:34 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 16:42 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 16:46 | |
| RP | tristanram_: adelcast is the person we need to talk to | 16:48 |
| RP | adelcast: We're seeing a problem where python's cache files (pyc) are invalid which is particularly problematic in a readonly rootfs | 16:49 |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 16:49 | |
| RP | adelcast: the problem is that opkg-build changes the data.tgz mtimes of the files from http://git.yoctoproject.org/cgit.cgi/opkg-utils/commit/?id=682f8c5e35b8854a9bb858b8ee1714d27e0c00db | 16:50 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 16:50 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 16:50 | |
| *** yacar_ <yacar_!~yacar_@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 16:54 | |
| adelcast | RP: so, change the mtime makes Python think that the files are invalid? | 17:01 |
| adelcast | change -> changing | 17:01 |
| RP | adelcast: correct | 17:03 |
| RP | adelcast: I'm wondering if we should only set the mtime for the outer archive and the control files/archive but not data | 17:03 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:03 | |
| adelcast | I am looking at https://bugs.python.org/issue29708 | 17:05 |
| kanavin | adelcast, I think --mtime=$build_date should happen only if SOURCE_DATE_EPOCH is set. If that is the case, python3 itself will switch to hash-based mechanism automatically. | 17:08 |
| kanavin | if SOURCE_DATE_EPOCH is not set, then mtime shouldn't be set to what the date is right now, as it does nothing for reproducibility, and breaks the cache mechanism | 17:09 |
| kanavin | (if I'm reading that opkg patch correctly) | 17:10 |
| RP | kanavin: I'm not sure it should happen at all for data.tar | 17:11 |
| kanavin | RP: right | 17:11 |
| adelcast | RP: if the mtime is not set on data.tar, how is the build reproducible? | 17:13 |
| adelcast | kanavin: that makes sense, if SOURCE_DATE_EPOCH is not set, then we should just not even try | 17:15 |
| adelcast | however, if SOURCE_DATE_EPOCH is set, and python < 3.6, then we will hit the original problem | 17:16 |
| kanavin | adelcast, oe-core master has 3.7.2 now :) | 17:16 |
| adelcast | sweet, then that could work | 17:17 |
| kanavin | adelcast, I actually agree with RP - don't rewrite mtimes of files in data tarball at all | 17:18 |
| kanavin | the package manager should not be concerned with what timestamps those files have - if the goal is to have a reproducible build, then the build system that actually creates those files in the first place will take care of it | 17:20 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 17:21 | |
| adelcast | oh right....that does makes sense, opkg should make sure the binaries it creates are reproducible, not the binaries it consumes | 17:22 |
| adelcast | that should be a simple change | 17:23 |
| *** fl0v0 <fl0v0!~fvo@i577A6E18.versanet.de> has quit IRC | 17:24 | |
| kanavin | yep, I guess dropping --mtime=$build_date from data.tar line would suffice | 17:25 |
| adelcast | yeah | 17:26 |
| adelcast | I can submit a patch shortly | 17:26 |
| retoatwork | I would like to add pre-built u-boot images to my distribution. They should be included in the .swu files created for SWUpdate and therefore need to be copied into the deploy folder. The bin_package.class offers a nice solution when copying the file(s) into the sysroot - is there something similar for files supposed to end up in the deployment folder? | 17:42 |
| RP | adelcast: right, I was thinking the underlying files were the build system's remit, opkg should only worry about its own files | 17:42 |
| RP | adelcast: thanks for helping :) | 17:43 |
| RP | tristanram_: ^^^ | 17:43 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 17:43 | |
| *** lusus <lusus!~lusus@62.91.23.180> has quit IRC | 17:45 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 17:46 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 17:50 | |
| *** sagner <sagner!~ags@46.140.72.82> has quit IRC | 18:03 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 18:10 | |
| *** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto | 18:22 | |
| kanavin | RP: AUH is done :) | 18:26 |
| *** gtristan <gtristan!~tristanva@110.11.179.2> has quit IRC | 18:29 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 18:33 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 18:34 | |
| RP | kanavin: ah, great. I should prepare for an influx of patches then? :) | 18:39 |
| kanavin | in theory :) | 18:40 |
| *** vdehors <vdehors!~vdehors@91.162.62.2> has quit IRC | 18:41 | |
| *** vdehors_ <vdehors_!~vdehors@91.162.62.2> has joined #yocto | 18:41 | |
| kanavin | in practice, you'll probably have to grab most of them from /home/auh/build/upgrade-helper/20190217000703/all on the auh machine | 18:41 |
| kanavin | but let's wait a few days as usual :) | 18:42 |
| *** ferlzc <ferlzc!~ferlzc@177.76.63.8> has joined #yocto | 19:28 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 19:37 | |
| tristanram_ | adelcast: seems to be ok with removing --mtime in one line of the script "( cd $pkg_dir && tar $ogargs $tsortargs -X $tmp_dir/tarX -c $tarformat . | $compressor $compressorargs > $tmp_dir/data.tar.$cext ) || rc=$?" | 19:39 |
| *** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has joined #yocto | 19:40 | |
| tristanram_ | adelcast: I can test it tomorrow and update the issue in bugzilla accordingly | 19:40 |
| *** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has quit IRC | 19:40 | |
| adelcast | tristanram_: that sounds great, do you have the bugzilla #? | 19:41 |
| *** gtristan <gtristan!~tristanva@110.11.179.2> has joined #yocto | 19:49 | |
| RP | adelcast: 13186 | 19:57 |
| *** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC | 20:14 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 20:16 | |
| *** sagner <sagner!~ags@2a02:169:34b6:0:ef16:ca50:42ea:5779> has joined #yocto | 20:16 | |
| adelcast | thanks, just added myself to the list, once I get the notification that the test passed, I can send patches | 20:20 |
| *** grumble <grumble!~iceicebab@freenode/staff/grumble> has joined #yocto | 20:20 | |
| *** bleu <bleu!~brianleu@cpe-2606-A000-112A-43F9-18B3-BAB-661F-5CFA.dyn6.twc.com> has joined #yocto | 20:40 | |
| * armpit auh is done.. check | 20:42 | |
| armpit | so are we automatically update packages that pass? | 20:47 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 20:50 | |
| *** ferlzc <ferlzc!~ferlzc@177.76.63.8> has quit IRC | 21:25 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 21:34 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 21:40 | |
| *** sjolley <sjolley!~sjolley@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 21:41 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 21:41 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 21:42 | |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 21:59 | |
| *** bleu <bleu!~brianleu@cpe-2606-A000-112A-43F9-18B3-BAB-661F-5CFA.dyn6.twc.com> has quit IRC | 22:00 | |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 22:00 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 22:07 | |
| *** gtristan <gtristan!~tristanva@110.11.179.2> has quit IRC | 22:26 | |
| RP | armpit: we didn't decide to do that as yet | 22:27 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 22:32 | |
| *** GeramyL <GeramyL!d1f468b2@gateway/web/freenode/ip.209.244.104.178> has joined #yocto | 22:49 | |
| GeramyL | Hi, I created my own machine and kernel for a custom x86/64 tablet, it needed a lot of customization to get it to work properly and i'm also building a custom embedded application. But when I go to run bitbake -c populate_sdk core-image-sato it gives me a nice little error I was hoping one of you could help me out, it says: meta-environment-surface-go-x86_64-1.0-r8 do_package_write_deb: Fatal errors occurred in subprocesses | 22:52 |
| GeramyL | https://pastebin.com/899drCMD | 22:53 |
| GeramyL | so far I can tell i'm missing this: x86_64-pokysdk-linux but I do have x86_64 executable binary | 22:55 |
| neverpanic | GeramyL: The command that fails is dpkg-deb -b $WORK/packages-split-meta-environment-surface-go-x86_64 $WORK/deploy-debs/x86_64-nativesdk | 23:05 |
| neverpanic | Unfortunately it doesn't seem to give you the stderr output, which might help you out finding why it failed | 23:05 |
| GeramyL | neverpanic: If this is a custom machine and kernel meta-layer what would I be missing so that the sdk builds? Do you know? | 23:07 |
| *** agust <agust!~agust@p54833194.dip0.t-ipconnect.de> has quit IRC | 23:09 | |
| neverpanic | I don't know. I'm telling you, packaging fails, so that's likely a problem with your packaging, not with your machine or kernel. | 23:12 |
| neverpanic | May I suggest you try to reproduce this command manually and see if it prints helpful output? | 23:12 |
| GeramyL | neverpanic: thats a good suggestion yeah let me do that :) | 23:15 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 23:15 | |
| *** nerdboy <nerdboy!~sarnold@mobile-107-77-164-78.mobile.att.net> has joined #yocto | 23:18 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 23:18 | |
| *** BlauskaerM <BlauskaerM!~Fever@185.213.152.162> has quit IRC | 23:19 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 23:30 | |
| GeramyL | neverpanic: sorry to ask such a dumb question, but how do you propose I run the command separately? | 23:52 |
| GeramyL | dpkg-deb: error: failed to open package info file '/home/geramy/Documents/Yocto_Kiosk_Surface_Go/Surface_Go_Build/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-surface-go-x86_64/1.0-r8/packages-split/meta-environment-surface-go-x86_64/DEBIAN/control' for reading: No such file or directory | 23:55 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!