Monday, 2019-02-18

*** sagner <sagner!~ags@> has quit IRC00:08
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC00:20
*** arielm <arielm!~quassel@> has quit IRC00:23
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC00:28
*** berton_ <berton_!~berton@> has quit IRC00:29
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto00:40
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC00:55
*** HyP3r <HyP3r!> has quit IRC01:00
*** HyP3r <HyP3r!> has joined #yocto01:00
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC01:05
*** black_13 <black_13!6c0cda8d@gateway/web/freenode/ip.> has joined #yocto01:06
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto01:06
black_13what would cause a problem with connecting to the bitback server01:07
black_13or rather
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto01:21
black_13what would cause "ERROR: Unable to connect to bitbake server, or start one"01:54
black_13the most obvious is that you cant connect01:54
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC01:55
*** nighty- <nighty-!> has joined #yocto01:57
*** nighty- <nighty-!> has quit IRC02:00
*** nighty- <nighty-!> has joined #yocto02:00
*** berton <berton!~berton@> has joined #yocto02:06
black_13the reason is that i was build in a shared directory02:08
*** otavio <otavio!~otavio@> has joined #yocto02:11
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto02:11
*** onlyesterday16 <onlyesterday16!~onlyester@> has joined #yocto02:37
*** black_13 <black_13!6c0cda8d@gateway/web/freenode/ip.> has quit IRC02:39
*** ankit <ankit!~apnavik@> has joined #yocto03:12
*** chandana73 <chandana73!~ckalluri@> has joined #yocto03:47
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto04:09
*** anujm <anujm!anujm@nat/intel/x-agdxkdcahzcjlsnc> has joined #yocto04:47
*** Jackie <Jackie!~quassel@> has quit IRC04:55
*** Jackie_ <Jackie_!~quassel@> has joined #yocto04:56
*** hamis <hamis!~irfan@> has joined #yocto05:34
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:55
*** anujm <anujm!anujm@nat/intel/x-agdxkdcahzcjlsnc> has quit IRC06:07
*** agust <agust!> has joined #yocto06:49
*** chandana73 <chandana73!~ckalluri@> has quit IRC06:52
*** zino_ <zino_!> has joined #yocto07:06
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto07:09
*** TobSnyder <TobSnyder!> has joined #yocto07:35
lukmaIs there any way to see arguments of nested functions (either with bash/python) without the need to recompile everything?07:35
lukmaFor example the staging.bbclass07:35
lukmawe do have in it: python·do_populate_sysroot ->"sysroot_stage_all",·d) -> sysroot_stage_dirs·${D}·${SYSROOT_DESTDIR}$07:36
lukmaIn the debug (-v) I only see the "sysroot_stage_all" executed07:36
lukmabut no functions nested07:37
lukmaIf I add bb.note() then I do need to rebuild everything07:37
lukmais there any switch which would allow me to see the arguments?07:37
lukma(-DD neither -v is not working)07:37
*** lucaceresoli <lucaceresoli!> has joined #yocto07:51
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:51
*** varjag <varjag!> has joined #yocto08:04
*** lusus <lusus!~lusus@> has joined #yocto08:06
*** fl0v0 <fl0v0!> has joined #yocto08:07
*** lfa <lfa!~lfa@> has joined #yocto08:10
*** marble_visions <marble_visions!~user@> has quit IRC08:11
*** marble_visions <marble_visions!~user@> has joined #yocto08:13
*** gtristan <gtristan!~tristanva@> has joined #yocto08:15
*** mckoan|away is now known as mckoan08:19
*** gtristan <gtristan!~tristanva@> has quit IRC08:21
*** gtristan <gtristan!~tristanva@> has joined #yocto08:22
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto08:23
*** prabhakarlad <prabhakarlad!~prabhakar@> has left #yocto08:24
*** Bunio_FH <Bunio_FH!> has joined #yocto08:24
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto08:24
*** tristanram_ <tristanram_!3e029902@gateway/web/freenode/ip.> has joined #yocto08:24
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto08:26
*** jofr <jofr!~jofr@> has left #yocto08:32
*** sagner <sagner!~ags@> has joined #yocto08:32
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:36
*** jofr <jofr!~jofr@> has joined #yocto08:37
*** sb79a <sb79a!> has joined #yocto08:38
*** willie_ <willie_!d973313a@gateway/web/freenode/ip.> has joined #yocto08:40
*** tristanram_ <tristanram_!3e029902@gateway/web/freenode/ip.> has quit IRC08:40
*** Willie <Willie!d973313a@gateway/web/freenode/ip.> has quit IRC08:44
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:47
*** lazyape <lazyape!> has quit IRC08:52
*** sb79a <sb79a!> has quit IRC08:52
*** sb79a <sb79a!> has joined #yocto08:53
*** sb79a__ <sb79a__!> has joined #yocto09:00
*** cvasilak <cvasilak!> has joined #yocto09:01
*** sb79a <sb79a!> has quit IRC09:02
*** Saur <Saur!pkj@nat/axis/x-mknalnhnlhycryiz> has quit IRC09:10
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:13
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:19
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto09: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 unable09:20
RPwillie_: its a very simple piece of code so I suspect it is possible but you'd have to edit it09:20
*** tristanram_ <tristanram_!3e029902@gateway/web/freenode/ip.> has joined #yocto09:21
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC09: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
RPkanavin: I know you looked at this, I can't remember what the conclusion was though09:25
RPwillie_: you'd also have to look at the code drawing the progress bar as it would need to be rotated too09:25
*** Saur <Saur!pkj@nat/axis/x-glkpdjicfjpuefup> has joined #yocto09:28
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto09:28
*** Saur <Saur!pkj@nat/axis/x-glkpdjicfjpuefup> has quit IRC09:29
*** Saur <Saur!pkj@nat/axis/x-epmlgszhsiowljlp> has joined #yocto09:30
willie_@RP, turns out i could simply edit the init file!09:41
*** florian_kc is now known as florian09:49
*** gtristan <gtristan!~tristanva@> has quit IRC09:54
*** gtristan <gtristan!~tristanva@> has joined #yocto09:54
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:8028:1943:a314:4a28> has joined #yocto10:06
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:8028:1943:a314:4a28> has quit IRC10:11
kanavintristanram_, 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 right10:12
kanavintristanram_, if you have a reproducer for the issue, we could take a look10: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 think10:14
kanavintristanram_, I don't know to be honest :)10:14
kanavinmy 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
kanavinwith this, there were no visible issues and so I didn't look10:15
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:18
tristanram_kanavin: RP told me on #oe that there are no tests to check those .pyc files.10:20
kanavinI don't think so. Can you write one?10:20
kanavinhow 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
kanavintristanram_, 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 stale10:26
*** TafThorne <TafThorne!~thomas@> has left #yocto10:26
tristanram_kanavin: Can I be of any assistance with helping you to recreate this issue on your side?10:28
RPtristanram_: the trouble is we're rather constrained on people with time to look into things like this :(10:28
kanavintristanram_, I cannot promise I will solve it in good time. Too much on my plate.10:29
RPtristanram_: 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
kanavintristanram_, 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@> has quit IRC10:32
tristanram_kanavin, RP: I can try to have a look at it as one of my sideprojects :). Should I open an issue on for this?10:33
RPtristanram_: yes please, we should track it10: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!> has joined #yocto10:38
RPtristanram_: Not to be funny, but the manuals?10:38
RPtristanram_: 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 package10:39
RPtristanram_: the image is then built from the packages10:39
RPtristanram_: 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 fine10: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
RPtristanram_: 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 above10:44
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC10:47
*** cquast <cquast!~cquast@> has joined #yocto10:49
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto10:50
*** sk_tandt <sk_tandt!> has joined #yocto11:09
sk_tandtGreetings! 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 template11:12
sk_tandtThe same code works on the host11:12
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:13
*** TobSnyder <TobSnyder!> has quit IRC11:14
tristanram_RP: Ok here is the issue
yoctiBug 13186: normal, Undecided, ---, paul.eggleton, NEW , Precompiled python3 bytecode is stale11:15
tristanram_RP: It might also be possible to make use of the new python 3.7 hash based byte code invalidation mode11:16
*** TobSnyder <TobSnyder!> has joined #yocto11:16
RPtristanram_: kanavin mentioned that, we worried it meant a lot of startup overhead hashing files though11: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 solution11:18
RPtristanram_: 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
RPtristanram_: right, but what I mean is can the rootfs code tweak the python to use UNCHECKED_HASH11:20
tristanram_RP: Ah, is the EXTRA_IMAGE_FEATURES not globally available?11:21
RPtristanram_: 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@> has quit IRC11:36
*** berton <berton!~berton@> has joined #yocto11:37
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC11:38
*** onlyesterday16 <onlyesterday16!~onlyester@> has quit IRC11:43
*** prabhakarlad <prabhakarlad!~prabhakar@> has quit IRC11:46
*** berton <berton!~berton@> has quit IRC11:47
*** learningc <learningc!> has joined #yocto11:54
*** sergius_lane <sergius_lane!b4fe1144@gateway/web/cgi-irc/> has joined #yocto12:18
*** sergius_lane <sergius_lane!b4fe1144@gateway/web/cgi-irc/> has quit IRC12:18
*** User_ <User_!> has joined #yocto12:42
*** learningc <learningc!> has quit IRC12:46
*** csanchezdll <csanchezdll!> has quit IRC13:02
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:03
RPkanavin: btw, did I do the right thing in ? Not sure its quite showing up in the rrs as we'd want?13:05
*** yacar_ <yacar_!> has joined #yocto13:05
*** csanchezdll <csanchezdll!> has joined #yocto13:05
kanavinRP: at least from the AUH perspective it's right, it will skip the recipe from now on13:06
RPkanavin: I wasn't sure if that was the right variable to use...13:06
kanavinRP: we have it in several recipes in oe-core13:08
*** inisider <inisider!ad26d10b@gateway/web/freenode/ip.> has quit IRC13:08
RPkanavin: that is fine, just wanted to check, thanks13:09
*** nighty- <nighty-!> has quit IRC13:20
RPkanavin: :(13:24
*** JaMa <JaMa!~martin@> has quit IRC13:28
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto13: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 newer13:37
kanavintristanram_, 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!> has joined #yocto13:43
kanavintristanram_, check the content of actual package files in deploy-*/13:44
kanavinyou can usually 'unpack' those from the command line, not sure what package format are you using13:45
kanavintristanram_, 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_!> has quit IRC13:46
tristanram_kanavin: ok, I will take a ipk from the deploy folder and check its contents next13:48
kanavinRP: that's a centos 7 specific failure, I'll grab lunch and get back to it13:49
RPtristanram_: ar -x should "open" the ipk, its like a deb13:50
*** hamis <hamis!~irfan@> has quit IRC13:51
*** ankit <ankit!apnavik@nat/intel/x-rjctpzoqpghcyfuy> has joined #yocto13:53
tristanram_RP, kanavin: Ty, timestamp is altered in the extracted ipk14:00
tristanram_RP, kanavin: image: ok, package: ok, package-split: ok, ipk: nok14:00
*** gtristan <gtristan!~tristanva@> has quit IRC14:01
RPtristanram_: ok, that means its something to do with opkg-build in package_ipk.bbclass14:03
RPtristanram_: looking at opkg-build in the opkg-utils-native recipe, its using --mtime=@$build_date14:05
RP(to tar)14:06
tristanram_RP: the mtime argument would explain the different timestamps14:07
RPtristanram_: yes. I think this is an effort to make it reproducible which has broken the python embedded timestamp14:08
*** alinucs <alinucs!> has joined #yocto14:09
RPtristanram_: nice thing is its a shell script so you could hack it easily14:11
tristanram_RP: i could add a patch for opkg-build in my layer14:15
tristanram_RP: I'm gonna try that and see if it works for me. But I'm thinking about a less hacky fix14:18
RPtristanram_: I don't think that --mtime option should be being applied to data.tar.gz, only the control one14:19
RPtristanram_: I'm hoping Alejandro, the opkg maintainer is around later. You could put the details in the bug and cc him there14:19
sk_tandtSo, 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
kanavinsk_tandt, with gdb?14:21
LetoThe2ndsk_tandt: 1) use proper toolchain 2) use proper toolchain 3) use proper toolchain :)14:21
RPtristanram_: it was a recent change:
*** sb79a__ <sb79a__!> has quit IRC14:21
RPer, a year ago even :/14:21
LetoThe2ndsk_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 bugzilla14:21
sk_tandtLetoThe2nd, proper toolchain?14:23
LetoThe2ndsk_tandt: -> the toolchain that matches the image on the target in use, specifically its ABI14:26
LetoThe2ndsk_tandt: thats why there are ways to create an sdk/esdk14:27
sk_tandtI'm afraid I'm not following: I suppose that has a purpose only for debugging, right?14:28
LetoThe2ndsk_tandt: no. it has a purpose specifically to compile for the target14:29
sk_tandtMh, 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
kanavinsk_tandt, how did you build the binary?14:34
kanavinfor your app?14:34
LetoThe2ndsk_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@> has quit IRC14:34
LetoThe2ndsk_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_tandtkanavin, I've added DEPENDS += "gtk+3"14:35
sk_tandtLetoThe2nd, I was following the Yocto Quick Build guide, but I'm starting to assume that isn't viable?14:38
*** gtristan <gtristan!~tristanva@> has joined #yocto14:38
LetoThe2ndsk_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 mentioned14:38
LetoThe2ndsk_tandt: so, lets start at the beginning. you have an application in source, right?14:39
LetoThe2ndsk_tandt: and how are you *BUILDING* the application?14:41
*** sagner <sagner!~ags@> has joined #yocto14:41
sk_tandtAutotools, as generated by the Yocto Eclipse plugin14:42
LetoThe2ndsk_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 automatically14:43
*** User_ <User_!> has joined #yocto14:43
LetoThe2ndif 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_tandtSorry, my bad14:44
sk_tandtI did14:44
LetoThe2ndsk_tandt: so you build the image, the application gets automatically built and included, right?14:44
sk_tandtYup, I can find the executable within /usr/bin14:45
sk_tandtAnd even the files that must be copied during the installation14:45
LetoThe2ndok. so now what does that have to do with the debian vm then?14:45
*** learningc <learningc!> has quit IRC14:46
sk_tandtI wanted to figure out was was missing in the built image for the app to work14:47
sk_tandtAnd/or reproduce the problem with the source code14:48
LetoThe2ndsk_tandt: please, stop annotating the non-given asnwers. are took the binary from the target build and copied it out, or what?14:48
LetoThe2ndi 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
LetoThe2ndmy bets are that you are taking some assumuption about the system that the application shall run on somewhere, but don't check it explicitly14:53
LetoThe2ndbut starting inside gdb and waiting for a backtrace to hit might give you a hint.14:54
*** cvasilak <cvasilak!> has quit IRC14:58
*** varjag <varjag!> has quit IRC14:59
sk_tandtSorry, got back: LetoThe2nd, you're quite right, missed the balance between dumping too much and not giving enough info15:04
sk_tandtThe built executable was indeed scp'ed to the end vm, and not rebuilt15:04
sk_tandtAs for setting up gdb, will come back as soon as I have something!15:05
kanavinsk_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_tandtkanavin, nope: I did build a recipe for the app, but I tried to replicate its issues copying the built executable in a vm15:08
*** willie <willie!d973313a@gateway/web/freenode/ip.> has joined #yocto15:09
*** willie_ <willie_!d973313a@gateway/web/freenode/ip.> has quit IRC15:09
LetoThe2ndkanavin: 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
willieCan someone point on my error in this thought process.. If i set "logo.nologo" at the end of mmcargs i can succesfully boot without tux15:13
willieBut when i try to re-compile with "rootfstype=${rootfstype}" \ "logo.nologo\0"  \ at the end of mmcargs i get kernel panic15:14
willierecompiling u-boot that is15:14
*** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has quit IRC15:14
*** ankit <ankit!apnavik@nat/intel/x-rjctpzoqpghcyfuy> has quit IRC15:17
*** WillMiles <WillMiles!> has joined #yocto15:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:21
kanavinRP: fix for gdk-pixbuf sent15: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
kanavintristanram_, you need to discuss this with opkg upstream I guess15:30
*** learningc <learningc!> has joined #yocto15:43
*** User_ <User_!> has quit IRC15:46
*** sagner <sagner!~ags@> has quit IRC15:51
*** sagner <sagner!~ags@> has joined #yocto15:53
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:53
*** oob <oob!~paulg@> has joined #yocto15:53
*** willie <willie!d973313a@gateway/web/freenode/ip.> has quit IRC15:54
*** arielm <arielm!~quassel@> has joined #yocto15:54
*** arielm <arielm!~quassel@> has left #yocto15:55
*** oob <oob!~paulg@> has quit IRC15:58
*** paulg <paulg!> has quit IRC15:59
sk_tandtHow may I know if my Eclipse is pointing to the correct toolchain?16:04
LetoThe2ndsk_tandt: just don't use it :P16:04
LetoThe2ndsk_tandt: sorry to but the eclipse plugin is mostly unmaintained and problem ridden16:05
sk_tandtOh, nice! I was using it to generate the autotools configuration files: is that part of the plugin bugged ?16:08
LetoThe2ndconsider every part being bugged.16:10
sk_tandtSigh, thanks16:10
*** Bunio_FH <Bunio_FH!> has quit IRC16:13
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC16:14
*** paulg <paulg!~paulg@> has joined #yocto16:17
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto16:19
*** sk_tandt <sk_tandt!> has quit IRC16:23
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC16:26
*** adelcast <adelcast!~adelcast@> has joined #yocto16:29
*** cquast <cquast!~cquast@> has quit IRC16:30
kanavinRP: I also sent a patch for glib meson issue (core-image-full-cmdline failures)16:31
*** willie <willie!d973313a@gateway/web/freenode/ip.> has joined #yocto16:34
*** User_ <User_!> has joined #yocto16:42
*** learningc <learningc!> has quit IRC16:46
RPtristanram_: adelcast is the person we need to talk to16:48
RPadelcast: We're seeing a problem where python's cache files (pyc) are invalid which is particularly problematic in a readonly rootfs16:49
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto16:49
RPadelcast: the problem is that opkg-build changes the data.tgz mtimes of the files from
*** TobSnyder <TobSnyder!> has quit IRC16:50
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC16:50
*** yacar_ <yacar_!> has quit IRC16:54
adelcastRP: so, change the mtime makes Python think that the files are invalid?17:01
adelcastchange -> changing17:01
RPadelcast: correct17:03
RPadelcast: I'm wondering if we should only set the mtime for the outer archive and the control files/archive but not data17:03
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:03
adelcastI am looking at
kanavinadelcast, 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
kanavinif 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 mechanism17:09
kanavin(if I'm reading that opkg patch correctly)17:10
RPkanavin: I'm not sure it should happen at all for data.tar17:11
kanavinRP: right17:11
adelcastRP: if the mtime is not set on data.tar, how is the build reproducible?17:13
adelcastkanavin: that makes sense, if SOURCE_DATE_EPOCH  is not set, then we should just not even try17:15
adelcasthowever, if SOURCE_DATE_EPOCH is set, and python < 3.6, then we will hit the original problem17:16
kanavinadelcast, oe-core master has 3.7.2 now :)17:16
adelcastsweet, then that could work17:17
kanavinadelcast, I actually agree with RP - don't rewrite mtimes of files in data tarball at all17:18
kanavinthe 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 it17:20
*** WillMiles <WillMiles!> has quit IRC17:21
adelcastoh right....that does makes sense, opkg should make sure the binaries it creates are reproducible, not the binaries it consumes17:22
adelcastthat should be a simple change17:23
*** fl0v0 <fl0v0!> has quit IRC17:24
kanavinyep, I guess dropping --mtime=$build_date from data.tar line would suffice17:25
adelcastI can submit a patch shortly17:26
retoatworkI 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
RPadelcast: right, I was thinking the underlying files were the build system's remit, opkg should only worry about its own files17:42
RPadelcast: thanks for helping :)17:43
RPtristanram_: ^^^17:43
*** learningc <learningc!> has joined #yocto17:43
*** lusus <lusus!~lusus@> has quit IRC17:45
*** User_ <User_!> has quit IRC17:46
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:50
*** sagner <sagner!~ags@> has quit IRC18:03
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC18:10
*** thannoy <thannoy!> has joined #yocto18:22
kanavinRP: AUH is done :)18:26
*** gtristan <gtristan!~tristanva@> has quit IRC18:29
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:33
*** learningc <learningc!> has quit IRC18:34
RPkanavin: ah, great. I should prepare for an influx of patches then? :)18:39
kanavinin theory :)18:40
*** vdehors <vdehors!~vdehors@> has quit IRC18:41
*** vdehors_ <vdehors_!~vdehors@> has joined #yocto18:41
kanavinin practice, you'll probably have to grab most of them from /home/auh/build/upgrade-helper/20190217000703/all on the auh machine18:41
kanavinbut let's wait a few days as usual :)18:42
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto19:28
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC19: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.> has joined #yocto19:40
tristanram_adelcast: I can test it tomorrow and update the issue in bugzilla accordingly19:40
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.> has quit IRC19:40
adelcasttristanram_: that sounds great, do you have the bugzilla #?19:41
*** gtristan <gtristan!~tristanva@> has joined #yocto19:49
RPadelcast: 1318619:57
*** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC20:14
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto20:16
*** sagner <sagner!~ags@2a02:169:34b6:0:ef16:ca50:42ea:5779> has joined #yocto20:16
adelcastthanks, just added myself to the list, once I get the notification that the test passed, I can send patches20:20
*** grumble <grumble!~iceicebab@freenode/staff/grumble> has joined #yocto20:20
*** bleu <bleu!> has joined #yocto20:40
* armpit auh is done.. check20:42
armpitso are we automatically update packages that pass?20:47
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto20:50
*** ferlzc <ferlzc!~ferlzc@> has quit IRC21:25
*** Bunio_FH <Bunio_FH!> has joined #yocto21:34
*** Bunio_FH <Bunio_FH!> has quit IRC21:40
*** sjolley <sjolley!> has joined #yocto21:41
*** Bunio_FH <Bunio_FH!> has joined #yocto21:41
*** Bunio_FH <Bunio_FH!> has joined #yocto21:42
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC21:59
*** bleu <bleu!> has quit IRC22:00
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto22:00
*** Bunio_FH <Bunio_FH!> has quit IRC22:07
*** gtristan <gtristan!~tristanva@> has quit IRC22:26
RParmpit: we didn't decide to do that as yet22:27
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:32
*** GeramyL <GeramyL!d1f468b2@gateway/web/freenode/ip.> has joined #yocto22:49
GeramyLHi, 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 subprocesses22:52
GeramyLso far I can tell i'm missing this: x86_64-pokysdk-linux but I do have x86_64 executable binary22:55
neverpanicGeramyL: The command that fails is dpkg-deb -b $WORK/packages-split-meta-environment-surface-go-x86_64 $WORK/deploy-debs/x86_64-nativesdk23:05
neverpanicUnfortunately it doesn't seem to give you the stderr output, which might help you out finding why it failed23:05
GeramyLneverpanic: 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!> has quit IRC23:09
neverpanicI 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
neverpanicMay I suggest you try to reproduce this command manually and see if it prints helpful output?23:12
GeramyLneverpanic: thats a good suggestion yeah let me do that :)23:15
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC23:15
*** nerdboy <nerdboy!> has joined #yocto23:18
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto23:18
*** BlauskaerM <BlauskaerM!~Fever@> has quit IRC23:19
*** learningc <learningc!> has joined #yocto23:30
GeramyLneverpanic: sorry to ask such a dumb question, but how do you propose I run the command separately?23:52
GeramyLdpkg-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 directory23:55

Generated by 2.11.0 by Marius Gedminas - find it at!