Monday, 2017-01-23

*** sameo <sameo!samuel@nat/intel/x-xrvscjmoqnqiluuw> has quit IRC00:19
*** JordonWu <JordonWu!~quassel@> has joined #yocto00:33
*** JordonWu <JordonWu!~quassel@> has quit IRC00:39
*** JordonWu <JordonWu!~quassel@> has joined #yocto00:40
*** agust <agust!> has quit IRC00:47
*** JordonWu <JordonWu!~quassel@> has quit IRC00:48
*** JordonWu <JordonWu!~quassel@> has joined #yocto00:49
*** nighty <nighty!> has joined #yocto00:54
-YoctoAutoBuilder- build #375 of nightly-musl is complete: Failure [failed Running Sanity Tests] Build details are at
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto01:12
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto02:16
*** Snert__ <Snert__!> has quit IRC02:18
*** Snert_ <Snert_!> has joined #yocto02:24
*** clopez <clopez!> has quit IRC02:30
*** raujo <raujo!465f18e6@gateway/web/freenode/ip.> has joined #yocto02:31
raujohow to compare machine type in .bb file e.g. if [ ${MACHINE} = "machineXXX" ]; then$          KBUILD_DEFCONFIG = "machineXXX_defconfig"$ throwing parsing error02:32
*** clopez <clopez!> has joined #yocto02:35
*** raujo <raujo!465f18e6@gateway/web/freenode/ip.> has quit IRC02:45
*** tlab <tlab!~tlab@> has quit IRC02:59
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC03:02
*** Snert <Snert!~snert_@> has quit IRC03:04
*** Snert <Snert!~snert_@> has joined #yocto03:05
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto03:06
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC03:10
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto03:14
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC03:15
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC03:16
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto03:20
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto03:23
-YoctoAutoBuilder- build #806 of nightly-oe-selftest is complete: Success [build successful] Build details are at
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC03:37
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto04:31
*** manuel_ <manuel_!> has quit IRC04:35
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC04:35
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC04:39
*** stryx` <stryx`!~stryx@> has joined #yocto04:40
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto04:40
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto04:43
*** thaytan <thaytan!> has joined #yocto04:46
*** manuel_ <manuel_!> has joined #yocto05:28
*** manuel_ <manuel_!> has quit IRC05:57
*** AndersD <AndersD!> has joined #yocto06:14
*** agust <agust!> has joined #yocto06:24
*** AndersD <AndersD!> has quit IRC06:34
*** AndersD <AndersD!> has joined #yocto06:35
*** AndersD <AndersD!> has quit IRC06:44
*** hamis <hamis!~irfan@> has joined #yocto06:46
*** Snert <Snert!~snert_@> has quit IRC06:47
*** Snert <Snert!~snert_@> has joined #yocto06:48
*** AndersD <AndersD!> has joined #yocto06:57
*** pohly <pohly!> has joined #yocto06:58
*** phatina <phatina!> has joined #yocto07:04
*** gizero76 <gizero76!> has quit IRC07:09
*** graphiqs <graphiqs!> has joined #yocto07:11
*** open-nandra <open-nandra!> has joined #yocto07:17
*** agust <agust!> has quit IRC07:23
*** rajm <rajm!> has joined #yocto07:32
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:36
*** lektrik <lektrik!> has left #yocto07:42
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto07:44
*** robertmarshall <robertmarshall!> has joined #yocto07:44
*** csanchezdll <csanchezdll!> has joined #yocto07:46
*** agust <agust!> has joined #yocto08:01
*** poor-man <poor-man!d97eb626@gateway/web/freenode/ip.> has joined #yocto08:02
*** fl0v0 <fl0v0!> has joined #yocto08:14
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC08:17
*** Kakounet <Kakounet!> has joined #yocto08:18
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto08:18
*** morphis <morphis!> has joined #yocto08:20
*** fl0v01 <fl0v01!> has joined #yocto08:24
*** MafiaInc <MafiaInc!~martian@> has joined #yocto08:25
*** fl0v0 <fl0v0!> has quit IRC08:25
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC08:26
*** toscalix <toscalix!~toscalix@> has joined #yocto08:27
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC08:29
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto08:32
*** JoiF <JoiF!~jofr@> has joined #yocto08:43
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC08:44
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto08:45
*** lemagoup <lemagoup!~lemagoup@> has joined #yocto08:47
*** joshuagl <joshuagl!joshuagl@nat/intel/x-qzpgpinuhrqyhfht> has joined #yocto08:48
*** sameo <sameo!~samuel@> has joined #yocto08:51
pohlybinutils-cross_2.27 compilation just failed for me:08:54
pohlysyslex_wrap.o: In function `yylex':08:54
pohlysyslex_wrap.c:(.text+0xb32): undefined reference to `yywrap'08:54
pohlycollect2: error: ld returned 1 exit status08:54
pohlyMakefile:1370: recipe for target 'sysinfo' failed08:54
pohlyThat's with OE-core master.08:54
*** Kakounet <Kakounet!> has quit IRC08:57
*** Kakounet <Kakounet!> has joined #yocto08:59
*** rajm <rajm!> has quit IRC09:01
*** robertmarshall <robertmarshall!> has quit IRC09:01
*** rajm <rajm!> has joined #yocto09:02
*** grma <grma!~gruberm@> has joined #yocto09:05
*** t0mmy <t0mmy!~tprrt@> has joined #yocto09:12
*** MiskaX <MiskaX!> has quit IRC09:12
*** psnsilva <psnsilva!> has joined #yocto09:14
*** ernstp <ernstp!uid168075@gateway/web/> has joined #yocto09:14
*** t0mmy <t0mmy!~tprrt@> has quit IRC09:16
*** john3 <john3!> has joined #yocto09:22
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto09:22
*** rburton <rburton!> has joined #yocto09:23
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@> has joined #yocto09:24
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto09:24
RPrburton: morning!09:27
RPrburton: we should talk about branches and merging patches when you have a moment09:27
*** rajm <rajm!> has quit IRC09:28
RPpohly: that it is a little odd as master seems to be building ok :/09:28
pohlyRP: my bad - I had locally updated to flex 2.6.3, which indeed is known to be incompatible with binutils (
*** florian_kc is now known as florian09:29
RPpohly: ok, that makes more sense09:29
pohly2.6.2 indeed is still save (well, relatively).09:29
*** psnsilva <psnsilva!> has quit IRC09:30
RPpohly: its all relative :)09:30
*** t0mmy <t0mmy!~tprrt@> has joined #yocto09:31
*** MiskaX <MiskaX!> has joined #yocto09:32
nrossiRP: great timing, im hitting an issue with the RSS changes. It appears EXTRA_IMAGEDEPENDS for images doesn't get properly fulfilled09:40
rburtonRP: hey09:40
RPnrossi: in that things don't end up in the image? or the sysroot? or ???09:43
RPrburton: I ended up picking a subset of mut/mut2 and pulling into -next along with a python3 fix for the ESDK issue.09:44
RPrburton: the end result built ok on the new cluster, it has issue son the main one09:44
*** Biliogadafr <Biliogadafr!> has joined #yocto09:44
nrossiRP: in the sysroot, e.g. qemu-native (if it isn't pulling in from a DEPENDS on the  wrapper)09:44
RPrburton: I did pull the kernel stuff, except the libc-headers piece09:45
RPnrossi: specifically which sysroot?09:45
nrossiRP: the native one for the image recipe09:45
RPnrossi: and probably more to the point, which wrapper :)09:45
RPnrossi: I'm guessing this wrapper is a "target" recipe (i.e. not cross/native?)09:46
nrossiRP: so image.bbclass has a DEPENDS += "qemuwrapper-cross". This is what is currently causing qemu-native to appear in the sysroot-native for image09:47
rburtonguess that needs to be the magic variable name instead09:47
RPnrossi: hmm, right. Whilst its says "cross", its not inheriting the class09:48
RPrburton: not necessarily :/09:48
nrossiRP: however the problem is that the sysroot is not populated by EXTRA_IMAGEDEPENDS as well. So e.g. qemu-helper-native is missing09:49
RPnrossi: Well, if you look at the code in image.bbclass it does d.appendVarFlag('do_build', 'depends', deps)09:51
RPnrossi: so these things only need to be available by do_build09:51
nrossiRP: sure, but is that not the default task, e.g. bitbake core-image-minimal?09:52
RPnrossi: right. I think I understand, its because do_build is noexec09:53
RPtherefore it never has its prefunc executed and the sysroot is never extended09:54
nrossiRP: I thought it might be something like that09:54
*** mckoan|away is now known as mckoan09:54
RPnrossi: a d.delVarFlag('do_build', "noexec") in that python would confirm09:54
RP(in image.bbclass)09:54
RPnrossi: or we could change it to point at do_image_complete, that might be easier09:55
nrossiRP: i tried changing the setVar to put the deps on do_rootfs and it worked as expected09:55
RPEXTRA_IMAGEDEPENDS[doc] = "A list of recipes to build that do not provide packages for installing into the root filesystem. Use this variable to list recipes that are required to build the final image, but not needed in the root filesystem.09:55
RPThat implies we should be building these things before do_image, not at do_build09:56
nrossiRP: yep, ambigious with regards to native deps being put in the sysroot09:56
*** TobSnyder <TobSnyder!> has joined #yocto09:57
RPnrossi: I guess there are two issues here, one EXTRA_IMAGEDEPENDS and the other is qemuwrapper's behaviour :/09:57
*** TobSnyder <TobSnyder!> has quit IRC09:57
nrossiRP: im not sure about qemuwrapper, i was only using it to indicate it was what was bringing in the qemu-native into the sysroot09:58
*** TobSnyder <TobSnyder!> has joined #yocto09:58
RPnrossi: so you're saying that dependency is working?09:58
RPthe trouble is qemu-native is pulled in all over :/09:58
nrossiRP: yes09:59
RPnrossi: ok, I misunderstood that bit09:59
nrossiRP: sorry, can be hard to describe these things succinctly10:00
RPnrossi: its ok, I'm also still waking up, sorry10:00
rburtonRP: the nightly-arm failure (no busybox-hwclock) looks like a non-deterministic problem, but that's can't be it right ;)10:02
RPrburton: I think its some transient issue, we've seen this before but not for a while10:03
RPrburton: happens when we change busybox10:03
RPrburton: it didn't happen on the other AB10:03
RPhmm, we have quite some number of noexec tasks with dependencies :/10:03
*** ed2 <ed2!Adium@nat/intel/x-adgcptampkdlzucp> has joined #yocto10:04
nrossiRP: Putting the EXTRA_IMAGEDEPENDS on do_image_complete as you suggested works well for reference10:05
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto10:05
RPnrossi: I'm tempted to go with do_image_complete for now10:06
*** CTtpollard <CTtpollard!> has joined #yocto10:06
BaloneyGeek|workHi! Stupid question, but I've just started building poky-based images and I'd to add a kernel parameter (quiet). Could anybody tell me where to do that?10:06
BaloneyGeek|workAll docs point to a kickstart file10:07
BaloneyGeek|workBut I've been doing builds with bitbake so I can't find the .wks files10:08
rburtonBaloneyGeek|work: APPEND+="quiet" in local.conf should work10:09
*** nighty <nighty!> has quit IRC10:11
BaloneyGeek|workrburton: Nope, it doesn't10:11
BaloneyGeek|workIt didn't rebuild the image and quemu still shows me the full kernel init output10:12
rburtonthe documentation says use APPEND10:13
RPBaloneyGeek|work: you're running the image with runqemu ?10:14
rburtonmaybe it didn't notice it had to rebuild the image - force it with bitbake someimage -C rootfs10:14
pohlyBaloneyGeek|work: "runqemu" ignores APPEND, which only ends up getting used when building full-disk images.10:14
rburtonoh yeah runqemu10:14
rburtonAPPEND only tells the bootloader what options to use, but qemu doesnt use one.10:15
rburtonrunqemu has an argument 'bootparams' to pass kernel options10:15
RPBaloneyGeek|work: something like runqemu qemux86 bootparams=quiet10:15
BaloneyGeek|workOh, that makes sense10:16
BaloneyGeek|workYep, all of that works. Thanks!10:17
*** Unier <Unier!uid41153@gateway/web/> has joined #yocto10:21
RPrburton: so do I merge -next?10:25
RPI merged in your oeqa fix btw, thanks10:25
*** Kakounet <Kakounet!> has quit IRC10:26
rburtonso there's the busybox-hwclock thing10:26
rburtonone selftest got OOMd10:26
rburtonmips test mysteriously failed10:26
RPrburton: OOM was alll ubuntu140410:27
rburtonbut the new cluster was all green so we've two transient issues to look at10:27
rburtonyeah go go go!10:27
*** Snert <Snert!~snert_@> has quit IRC10:27
rburtongot a build of arm going here to look at the busybox thing quickly10:27
rburtonmaybe it depends on what exactly type of arm is building first10:28
*** Snert <Snert!~snert_@> has joined #yocto10:28
rburtongoing to walk the dogs now i think, the world is understandably rebuilding10:29
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:32
*** geoffrey_l <geoffrey_l!> has joined #yocto10:33
*** jku <jku!~jku@> has joined #yocto10:36
*** john3 <john3!> has quit IRC10:43
*** rajm <rajm!> has joined #yocto10:46
*** Kakounet <Kakounet!> has joined #yocto10:46
*** john <john!> has joined #yocto10:47
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto10:47
*** john is now known as Guest2632510:48
RPrburton: looking at the logs, it installed busybox from do_package, then reran the package_write_* tasks. The do_package data it pulled in is corrupt in that /etc/init.d/* is missing10:52
*** berton <berton!~berton@> has joined #yocto10:53
* RP looks at systemd10:53
*** john1 <john1!> has joined #yocto10:54
*** Guest26325 <Guest26325!> has quit IRC10:56
*** Artox <Artox!~Artox@> has quit IRC10:56
RPTrouble is I can't find a systemd+qemuarm combination that would put this into sstate :/10:59
*** Fluttershy0 <Fluttershy0!~Artox@> has joined #yocto11:03
HyP3rsomeone here with device tree knowledgable? I have here a dts file which is including a dtsi file which is including a dtsi file and inside this file theres a UART defined which I want to disable. Is it just enough to remove this entry?11:07
nrossiHyP3r: You can also use -> status = "disabled";11:11
ernstpHyP3r: You don't need to edit the original, you can just overwrite it after the include11:11
ernstpwith status = "disabled";11:11
nrossiHyP3r: Yep with something like "&uartnodename { status = "disabled"; };11:12
HyP3rernstp: ah ok, so I have to create an patch which is adding this line into the dtsi file?11:12
nrossiHyP3r: no you can do it in the parent dts file, using the node name reference syntax11:14
nrossi(or the full path if so desired)11:14
*** istarilucky <istarilucky!~rlucca@> has joined #yocto11:15
HyP3rnrossi: the problem is that the parent dts file is not in my meta-layer11:15
nrossiHyP3r: is any of the dts(i) in your layer?11:16
HyP3rThe journey begins here:
HyP3rAnd this is not in my layer11:16
HyP3rWell I guess I just patch the kernel for that. No problem :)11:16
geoffrey_lHi, is it possible to ask bitbake what are the task that need to be rerun for a recipe ?11:17
HyP3rnrossi: is this the correct position to disable the uart?
nrossiHyP3r: Yep that would be the most straight forward way to modify you the device tree. Looks like you found the line to change :), change "okay" to "disabled" and you will have the change you need :)11:18
HyP3rnrossi: okay thanks11:19
*** sgw_ <sgw_!sgw_@nat/intel/x-rfisdjrmznjxadoo> has quit IRC11:19
nrossigeoffrey_l: bitbake -g, will give you a graphviz output for the tasks/packages/etc11:19
HyP3rnrossi: and whats that:
geoffrey_lnrossi: Thanks ! :)11:19
*** sgw_ <sgw_!sgw_@nat/intel/x-bqmoutcmqzvylluv> has joined #yocto11:19
nrossigeoffrey_l: ah sorry, it wont give you the tasks that need to be rerun. Depends what you need to know though11:20
HyP3rmy processor has an pin multiplexer, does it make sence to remove here everything correspondening. To make sure that the multiplexer is not affected?11:20
nrossiHyP3r: Well depends, do you want to remux the pins for a different purpose?11:20
HyP3rno my co processor is using this uart so linux shouldn't touch it11:21
RPrburton: Trouble is I can't tell what went from from this sstate object and I think the builder that created has wiped the tmpdir11:22
*** ed2 <ed2!Adium@nat/intel/x-adgcptampkdlzucp> has quit IRC11:22
RPrburton: I can see the .config from the ptest data and its not right at all11:22
nrossiHyP3r: Hmmm, you might have to make your co-processor setup the pinmux if linux doesn't set it up for you11:22
RPif the .config isn't right, hwclock disappears11:23
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC11:23
geoffrey_lnrossi: I search why in a recipe with image-side fetching do_image fail because of do_rootfs who didn't rerun. I also noticed that my base image (without fetching things) as some tasks that rerun each time, so I want to know what they are to search why.11:24
*** Rootert <Rootert!> has quit IRC11:25
*** RagBal <RagBal!> has quit IRC11:25
nrossigeoffrey_l: ah in that case bitbake-diffsigs will help you determine the cause of the rerun11:26
geoffrey_lnrossi: Thanks, I will try that :)11:26
*** RagBal <RagBal!> has joined #yocto11:26
*** fray <fray!> has quit IRC11:27
*** Rootert <Rootert!> has joined #yocto11:27
*** fray <fray!> has joined #yocto11:27
RPrburton: pretty sure this is the corrupted build:
*** Fluttershy0 is now known as Artox11:27
RPrburton: compile re-ran after being interrupted and killed in a previous build11:27
*** ed2 <ed2!Adium@nat/intel/x-oyyoudybkzwctkxx> has joined #yocto11:28
RPWhy do I say that? "WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist" and friends11:28
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC11:35
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto11:38
RPIn fact, I can guess how this happens, if you abort the compile, I'd bet it corrupts due to the suid/nosuid thing11:38
*** caiortp <caiortp!~inatel@> has joined #yocto11:55
*** nighty <nighty!> has joined #yocto12:00
RPnrossi: I squashed a fix for the depends issue into the rss commit as I merged it12:05
nrossiRP: Cool thanks, been testing the RSS on some other builds, works great so far :). Already found a dep issue with pthreads-win32 ;)12:07
RPnrossi: I suspect we're going to find a few dependency issues!12:07
RPnrossi: glad its working though and I appreciate the testing, not many people have done that12:08
*** hamis <hamis!~irfan@> has quit IRC12:16
rburtonRP: yes, i've noticed before that busybox fails to rebuild really badly thanks to the suid thing12:17
*** Snert_ <Snert_!> has quit IRC12:18
rburtonRP: i can dig into this further if you haven't already got far.12:18
rburtonRP: WARNING: initramfs-live-boot-1.0-r12 do_prepare_recipe_sysroot: Manifest /home/ross/Yocto/poky/build2/tmp/sstate-control/manifest-allarch-linux-yocto.populate_sysroot not found? <— bad?12:18
UnierHi, When I get task hash mismatch error, what are the steps to resolve this, and in which recipe should i modify? "myimage-1.0-r0 do_image: Taskhash mismatch"12:19
*** toanju <toanju!~toanju@> has joined #yocto12:19
ernstpUnier: did you add some metadata to myimage?12:22
RPrburton: I have a patch!12:22
Unierernstp: Yes there are other packages that I have added12:22
Unierernstp: Is it often metadata added to the image that causes this?12:23
ernstpUnier: yes, like DATETIME and other variables that change every run12:24
RPrburton: patch sent out and in -next12:26
RPrburton: I've pushed a few things, could you rebase mut/mut2 and see where we are?12:27
rburtoncool, good fix12:27
RPrburton: I suspect the rest of mut2 is toxic in some form12:27
Unierernstp: I do not think I have DATETIME set, I change only image features, and packages that are installed on the image12:27
rburtonRP: mut2 is 1/3rd reverts right now :)12:27
ernstpUnier: there's something called vardepsexclude that helps sometimes12:27
RPrburton: I pulled the kernel updates apart from the headers12:28
RPrburton: I think that should be safe12:28
rburtonspeaking of which12:28
ernstpUnier: oh, I only got it when I changed my image_type.bbclass to do new fancy stuff. so the _cause_ was very obvious12:28
rburtonjku: so the musl guys are navel gazing, can you write a patch for connman to inject that magic UAPI define into CFLAGS on musl?  A CFLAGS_append_libc-musl should be sufficient.12:29
ernstpUnier: well undo your changes until it works again :-)12:29
Unierernstp: I have tried PR[vardepsxeclude]="DATETIME" with no success12:29
Unierernstp: Problem is that I only get the error when I run the image build from jenkins, not when I run it manually12:29
ernstpUnier: I didn't mean you should do that exactly, more an example...12:29
ernstpUnier: oh, environment variable name collision :-)12:30
Unierernstp: Yeah, i suspect something like that indeed12:30
Unierill check12:30
ernstpthe Taskhash mismatch is a pretty horrible part of bitbake... :-)12:33
RPernstp: I agree :(12:33
ernstphad to do this little dance to get custom image names:12:34
rburtonwould be amazing if it would explode the hashes to tell you *what* changed12:34
ernstpIMAGE_NAME[vardepsexclude] = "IMAGE_NAME_VERSION"12:34
RPrburton: the trouble is that it doesn't have the original thing to compare against12:36
rburtonRP: there's a few bits left in mut which are not toxic (they're only there still as i need to send mails).  attr, xserver, container tests for example, all need a run on the AB.12:36
ernstprburton: yes please :-)12:36
rburtonernstp: patches welcome ;)12:36
RPrburton: the container tests failed on the AB test run12:37
ernstpbitbake is technically OE and not Yocto? but you're all one big family I assume :-)12:37
RPrburton: Is someone working on fixing ed btw?12:38
RPernstp: bitbake is looked after by the same people12:38
*** igor1 <igor1!~igor@> has joined #yocto12:39
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC12:39
RPrburton: mut is still revert crazy :/12:40
rburtonRP: ed is surprisingly non-trivial, need to grab lzip from meta-oe to fetch new sources.  for M2, i might just submit a src_uri change to point at our mirror.12:40
rburtonyes, i need to write a few emails, and the reverts in mut2 were a reminder12:40
RPrburton: ok, fair enough12:41
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto12:41
RPbtw, can we switch tremor to a tarball rather than svn?12:42
RPIts the only remaining reason we build subversion-native12:42
rburtonlast i looked the tarball was *very* old12:44
rburtona better question is "why do we still build tremor"12:44
RPrburton: I'd just like to create a tarball of that revision and stuff it on our mirror12:44
jkurburton: how bad is so-version going backwards (not conflicting with any previous version AFAICT though)? I'll file an upstream bug but not sure about upgrading to that version in oe-core...12:45
*** JordonWu <JordonWu!~quassel@> has quit IRC12:45
rburtonRP:  we don't build tremor in oe-core.  i say, move tremor to meta-multimedia12:46
rburtonoh balls, we do12:46
rburtoni just can't read12:46
*** Snert_ <Snert_!> has joined #yocto12:47
rburtonjku: what's the context?12:48
rburtonRP: tremor hasn't been touched for two years now.  modern hardware doesn't need non-floating-point decoding.  i propose to move tremor to meta-multimedia, disable in oe-core.12:48
jkurburton: -- I think they wanted to bump age with all the previous micro_versions, but it doesn't work like that retroactively12:49
jkuso the previous so version 0.3602.0 and that one becomes 0.3600.3 I think12:50
*** groleo <groleo!> has joined #yocto12:50
rburtonurgh i hate libtool versioning12:50
jkuyes most confusing12:51
rburtonlooking at, i presume they use major as current and minor as revision?12:51
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto12:51
rburtoni'd hold off the upgrade before talking to mathias, definitely12:52
jkuyeah sounds good12:52
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC12:54
jkurburton: m4_define([lt_current], [m4_eval(100 * gdk_pixbuf_minor_version + gdk_pixbuf_micro_version - gdk_pixbuf_interface_age)])12:54
jkuand revision is interface_age12:55
RPrburton: I have a patch to do something with tremor12:55
RPrburton: If someone else has time to remove it fine, I'm sick of waiting on subversion native though ;-)12:58
rburtonRP: have a patch to do that :)12:58
rburtonRP: well i have a patch to disable it so you'll only need svn-native for world builds, and will submit the addition to meta-multimedia shortly so when that is in we can remove it from core.12:59
*** ed2 <ed2!Adium@nat/intel/x-oyyoudybkzwctkxx> has quit IRC13:01
RPrburton: ok, just base it on top of mine. Tempted to backport mine to morty ;-)13:02
*** ed2 <ed2!Adium@nat/intel/x-lowcjgyptapdxzhw> has joined #yocto13:02
rburtonRP: yeah might be sensible13:03
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC13:04
rburtonhuh, util-linux's ptest code is mental13:06
*** madisox <madisox!~madison@2601:647:ca00:4f00:ab08:5b70:453f:209d> has joined #yocto13:07
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC13:13
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto13:18
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto13:23
*** marka <marka!> has joined #yocto13:29
HyP3rnrossi: according to the manual I should patch the device tree to make sure that the linux is not touching the uart_b. I have done that, as I told you before. But now I have to change the defargs how the bootloader call linux.13:30
HyP3rnrossi: where I can find this inside my bitbake enviroment?13:30
HyP3r"setenv defargs 'clk_ignore_unused initcall_blacklist=sram_init'"13:30
nrossiHyP3r: That's a u-boot command no? you will likely need to run that in your U-Boot console and save your environment. Or patch U-Boot's default environment for your target?13:31
HyP3rI want to patch the U-Boots default enviroment so I don't have to run this command13:36
HyP3rThis links shows only an example how to do that, if you don't want to change something inside openembedded13:36
nrossiHyP3r: You will have to create a patch for U-Boot, and then put it in a bbappend in your layer.13:38
*** aratiu <aratiu!~adi@> has quit IRC13:39
nrossiHyP3r: Or you can use 'devtool modify', it might be the workflow you are after13:41
*** ed2 <ed2!Adium@nat/intel/x-lowcjgyptapdxzhw> has quit IRC13:41
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC13:42
*** ed2 <ed2!Adium@nat/intel/x-vugmwyjtqpcdbcfw> has joined #yocto13:42
HyP3rnrossi: ok I'll search13:44
nrossiHyP3r: There is documentation of devtool here:
*** ed2 <ed2!Adium@nat/intel/x-vugmwyjtqpcdbcfw> has quit IRC13:45
*** manuel_ <manuel_!> has joined #yocto13:50
*** lamego <lamego!~jose@> has joined #yocto13:57
*** poor-man <poor-man!d97eb626@gateway/web/freenode/ip.> has quit IRC14:01
HyP3rnrossi: well okay. I have to take a look into the sources. *sigh*14:05
HyP3rnrossi: but what is devtool. Is that a new tool. In my book I read wasn't this tool mentioned.14:05
nrossiHyP3r: books? devtool has been around for a few releases of OE/Yocto now, it just automates some of the layer/recipe/metadata creation/modification14:06
HyP3rI read and
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto14:10
nrossiHyP3r: those books were probably written before devtool was really available14:10
HyP3rnrossi: ok. Is there a way to list which packages/recpies are compilated and generated when I call the image recpie?14:15
HyP3rnrossi: I don't find the uboot recpie14:15
nrossiHyP3r: depends how u-boot is built into your image, so it won't be in the manifest. Just having a quick look at the machine you are building, it should build "u-boot-nand.imx" into the deploy directory?14:19
HyP3ryeah. Its here14:20
nrossiHyP3r: The u-boot recipe for your machine is a fork called "u-boot-toradex", that is the name of the u-boot recipe thats built14:20
HyP3rnrossi: I allready searched for this image and found 3 versions of this *.bb file. I have found the fitting image for vfxxx14:21
HyP3rnrossi: bitbake -g -u foobar is also really helpful14:21
nrossiHyP3r: u-boot-toradex_v2015.04 is the one being modified setup to be compatible in the -nxp layer14:23
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto14:24
HyP3rI guess its the meta-fsl-arm-extra u-boot-toradex_2015.04.bb14:24
*** gtristan <gtristan!~tristanva@2605:8d80:6c5:424e:f860:7be6:7010:85f0> has joined #yocto14:28
nrossiHyP3r: bitbake -s, will tell you the exact version being used. I'm just guessing ;)14:28
HyP3rnrossi: what about this line? should I patch this position?
HyP3rthis akward zero termination looks like a lot of fun which user can have14:31
RPAre there any other patches people really want to see in M2?14:33
*** gtristan <gtristan!~tristanva@2605:8d80:6c5:424e:f860:7be6:7010:85f0> has quit IRC14:33
RPmarquiz: the perf testing machines don't seem to like your changes :(14:36
RPmarquiz: ImportError: No module named 'git'14:36
*** dv_ <dv_!~quassel@> has quit IRC14:40
RamoseOne basic query, if I have PACKAGECONFIG[faad]            = "--enable-faad,--disable-faad,faad2" in it means faad plugin won't build ?14:40
nrossiHyP3r: That looks like the line14:41
rburtonRamose: depends on the value of PACKAGECONFIG14:41
*** dv_ <dv_!~quassel@> has joined #yocto14:41
rburtonRamose: that line defines the 'faad' option, the value of PACKAGECONFIG decides if its enabled or not14:41
rburton(the documentaiton has a nice chapter about this)14:41
Ramoserburton:ok , under this variable PACKAGECONFIG ??= " \?14:42
*** lamego <lamego!~jose@> has quit IRC14:43
Ramoserburtin: Its defined like
* sgw_ thanks halstead very much for de-spamming mailman!14:44
Ramosesorry *rburton: it means faad won't build ?14:44
rburtonRamose: correst: faad isn't in the list, so faad is disabled.14:45
*** lamego <lamego!jose@nat/intel/x-xhsaraxokpnqochs> has joined #yocto14:45
*** paulg <paulg!> has joined #yocto14:46
Ramoserburton: ok, Let me enable it and see if its build or not14:46
Ramoserburton; Yes, its compiling , Thanks :)14:46
*** manuel_ <manuel_!> has quit IRC14:47
marquizRP: argh, yes, oeqa/utils/metadata requires python-git14:50
*** rcw <rcw!~rwoolley@> has joined #yocto14:51
RPmarquiz: I've kind of been hoping I'd get some performance numbers from somewhere for rss, but nothing yet :(14:51
marquizi was asking about this when the dep was introduced :)14:51
marquizRP: i might be able to install git there14:52
marquizpython git14:52
marquiz(i'd like to ditch that dependency, though)14:53
geoffrey_lIs there any way to skip do_rmwork for a specific task ?14:53
HyP3rnrossi: or is it better to change this line
HyP3rnrossi: I have never changed code inside the uboot. I don't know the structure14:54
*** Talorno <Talorno!~giova@> has joined #yocto14:56
nrossiHyP3r: Not sure if you can set the variable you are after via defconfig14:57
*** JosePerez <JosePerez!~jgperezc@> has joined #yocto14:58
*** gabrbedd <gabrbedd!> has quit IRC14:58
nrossigeoffrey_l: do_rmwork is a task, if you mean recipe. RM_WORK_EXCLUDE14:58
kanavinfray: rpm packages generally require /bin/sh, but in case of building the SDK that file is not present in the destination (core-image-.../sdk/image/)14:59
kanavinfray: how is the check for that overridden?14:59
*** AndersD <AndersD!> has quit IRC15:00
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto15:03
*** aratiu <aratiu!~adi@> has joined #yocto15:03
geoffrey_lnrossi: I mean task, I created a task that write in ${IMAGE_ROOTFS} and when i redo "bitbake myrecipe" do_image doesn't have some files (exept if I add do_rootfs[nostamp] = "1"). I don't know how do_rmwork actually work but I think it may be related to the files being deleted.15:03
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:04
*** gabrbedd <gabrbedd!> has joined #yocto15:06
aratiuI'm having a problem with useradd_base.bbclass, in both the do_configure and do_clean tasks of a recipe of mine which adds two users to the same group, useradd_base tries to delete the group but fails with "groupdel: cannot remove the primary group of user 'webserv'"15:06
marquizRP: fixed, next result report should be ok15:06
marquizRP: i'll dig the data for the failed buid15:07
aratiubefore trying to delete the group it deletes the first user in that group, but the group deletion itself fails because of the second group user15:07
aratiuI've googled and found found this discussion:
aratiuhas that been fixed?15:07
RPmarquiz: cool, thanks15:08
RPpohly: I did finally look into the parsing=True business and I'm pretty sure it should be in there and comparitively safe to do. bitbake-selftest passes at least15:08
pohlyRP: you're the expert ;-}15:09
*** manuel_ <manuel_!~manuel@> has joined #yocto15:12
aratiumaybe I should just add a check in useradd_base.bbclass' function perform_groupdel() if there are other users in the group don't delete it?15:14
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto15:14
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto15:16
*** Flow86 <Flow86!> has quit IRC15:16
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has quit IRC15:20
*** Flow86 <Flow86!> has joined #yocto15:20
*** alimon <alimon!~alimon@> has joined #yocto15:20
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:22
*** Talorno <Talorno!~giova@> has quit IRC15:23
pohlyShould (packaged in libgcc) be pulled into images automatically? I just had tcsd (from the trousers package) fail with: " must be installed for pthread_cancel to work".15:29
pohlyAnd indeed, it's not in my rootfs.15:29
*** open-nandra <open-nandra!> has quit IRC15:29
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:29
*** frsc <frsc!~frsc@> has joined #yocto15:34
*** groleo <groleo!> has quit IRC15:34
kergothRP: given that path replacement always happens in constructed sysroots, i wonder if we could ditch the altered prefix in native.bbclass.15:35
kergoths/always/now always/15:35
*** toanju <toanju!~toanju@> has quit IRC15:42
RPkergoth: I strongly suspect not as we still install to "/"15:43
RPkergoth: there are two parts to that trick and installing to "/" saves us *tons* of pain15:43
RPpohly: you have to RDEPEND on it from the software :(15:44
RPpohly: there is no dynamic linker markup15:44
kergothhmm, good point. changing that would be a compat issue for existing sstates, given that15:44
kergothoh well15:44
*** rcwoolley_ <rcwoolley_!~rwoolley@> has joined #yocto15:44
pohlyRP: why is glibc not having an RDPENDS for it? There is one in (checking some other glibc feature), but it is commented out.15:44
RPkergoth: Its not compatibility and more that if you don't install to "/" you have to do all the horrible hacks the do_stage () functions used to do :(15:45
RPkergoth: their runtime location needs to be the same as their install location15:45
RPpohly: because glibc doesn't need it and you only need it if you use very specific pthread API15:46
RPpohly: People have complained about this before :/ (being included unconditionally)15:46
*** rcw <rcw!~rwoolley@> has quit IRC15:47
pohlyRP: leaving it to apps to RDEPENDS on libgcc looks like the wrong solution to me. trousers might not even be compiled against glibc which needs libgcc, so why should it RDEPEND on libgcc? That's an implementation detail of glibc, and thus needs to be handled by glibc.15:47
pohlyBut I can also see how someone might want to avoid the overhead if pthread_cancel isn't used.15:48
RPpohly: what we really need is a list of pthread using functions, then the shlibs code would spot references and add the depends15:49
pohlyRP: agreed.15:49
RPer, libgcc using pthread functions15:49
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC15:50
*** davis <davis!> has quit IRC15:50
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto15:50
*** davis <davis!> has joined #yocto15:51
*** davis is now known as Guest3915415:51
pohlyRP: I filed for this15:55
yoctiBug 10954: enhancement, Undecided, ---, paul.eggleton, NEW , dynamically detect dependency on libgcc15:55
RPpohly: thanks, redirected to rburton16:00
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:02
*** Kakounet <Kakounet!> has quit IRC16:05
*** jku <jku!~jku@> has quit IRC16:06
*** Kakounet <Kakounet!> has joined #yocto16:06
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC16:06
rburtonRP: oh, last minute patch to change ed SRC_URI?16:07
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC16:12
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto16:13
*** ernstp <ernstp!uid168075@gateway/web/> has quit IRC16:18
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto16:19
*** graphiqs <graphiqs!> has quit IRC16:20
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC16:20
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto16:20
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:24
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC16:24
RPrburton: I'll take it16:30
rburtonon the list16:30
*** frsc <frsc!~frsc@> has quit IRC16:31
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC16:32
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC16:35
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC16:38
kanavinrburton: is there a bug to solve the ed issue properly?16:40
kanavinrburton: the patch hides the issue under the carpet, so some other reminder is needed16:40
rburtonthre is now16:41
*** jairglez <jairglez!~jairdeje@> has joined #yocto16:42
kanavinrburton: I need ideas for this issue:16:43
kanavin Problem 1: package nativesdk-packagegroup-sdk-host-1.0-r12.x86_64_nativesdk requires nativesdk-wayland, but none of the providers can be installed16:43
kanavin  - conflicting requests16:43
kanavin  - nothing provides /bin/sh needed by nativesdk-wayland-1.12.0-r0.x86_64_nativesdk16:43
kanavinin rpm5 world, we teach rpm5 to ignore that dependency16:43
rburtonyeah thats basically an assumed host dependency isn't it16:43
*** TobSnyder <TobSnyder!> has quit IRC16:44
kanavinrburton: it's not a host dependency, it's an SDK image dependency - rpm expects that something will install /bin/sh into /home/ak/development/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/sdk/image/, and cannot find a package that does16:45
kanavinrburton: because all packages install into that + /opt/poky/2.2/sysroots16:45
*** ed2 <ed2!~Adium@> has joined #yocto16:47
*** ythl <ythl!8b55df0a@gateway/web/freenode/ip.> has joined #yocto16:48
kanavinrburton: much of this code was written by a certain Laurentiu Palcu, and I have a hunch he's not around anymore16:49
*** dmoseley <dmoseley!> has joined #yocto16:49
ythlDoes anyone know where bitbake recipes get ${CC} from?16:51
ythlLike if I'm building for qemuarm64, where is bitbake finding a aarch64 compiler?16:51
kergothmeta/conf/bitbake.conf, like nearly every other variable16:52
*** rajm <rajm!> has quit IRC16:52
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC16:52
ythl@kergoth - thanks16:53
kergothreading it should be informative16:53
kanavinythl: bitbake -e16:53
kergothyeah, that too, bitbake -e tells you where each var was defined16:53
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto16:57
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto16:57
RPpaulg/paulg_: Which revision of master is that failure?16:58
paulg4aa6644f9297 kernel-fitimage: Use compressed ramdisks in FIT images if available16:59
*** rstreif <rstreif!> has joined #yocto16:59
RPpaulg: congratulations on finding the first post rss merge bug ;-)17:00
* fray is looking, there might be a utility called 'patchelf' can can reside the rpath17:00
fray(not sure yet)17:00
*** sameo <sameo!~samuel@> has quit IRC17:01
rburtonkanavin: i'll admit that you're now a better rpm/packaging expert that i am right now17:01
RPfray: I know what has happened here17:01
*** john1 <john1!> has quit IRC17:02
*** john3 <john3!> has joined #yocto17:02
*** Kakounet <Kakounet!> has quit IRC17:03
RPkanavin: We need a way to say "ignore this list of dependencies"17:04
RPkanavin: that is inevitable with the sdk17:04
*** fl0v01 <fl0v01!> has quit IRC17:05
*** sgw_ <sgw_!sgw_@nat/intel/x-bqmoutcmqzvylluv> has quit IRC17:05
frayya.. this patchelf can expland the rpath.. which is neat.. however, it seems to verify that the rpath you select is 'correct' before setting it, which won't really work for many of our cases..17:05
*** geoffrey_l <geoffrey_l!> has quit IRC17:06
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC17:06
RPfray: adding patchelf as a distro dependency turned out to be a pain, chrpath was the only one we could find in most distros easily17:06
frayinstead of rewriting the rpath (or runpath), it zero's the exiting one, grows the dynamic section, and moves the table to the end of the section -- allowing it to be as long as needed..17:06
RPfray: the bigger problem is that these paths its trying to rewrite are wrong17:06
fraycouldn't we just build it ourselves (looks small enough in this case)17:07
fray(I've not checke don dependencies though, if it depends on other things, that falls apart quickly)17:07
RPfray: how do you relocate the patchelf native dependencies?17:07
RPfray: we did try17:07
fraybuild it static17:07
fray(again, assuming no dependencies on other things)17:07
frayactually wouldn't have to be static.. since it's a -native  it would build with the host's libc wouldn't it?17:09
*** stephano <stephano!~stephano@> has joined #yocto17:09
frayand if it's self contained (otherwise) then all it needs is a working and host libc.. eliminaing the need for the rpath17:09
ythl@krogoth, I found where the variable is defined in meta/conf/bitbake.conf, but after I unroll all the macros, it seems like a non-existant compiler17:10
frayso ya, it's a possibility.. but it is C++, so it may require the libcxx library..17:10
fraysomething to look into, otherwise someone needs to convince debian folks to fix rpath to not just re-write but to maniuplate the ELF object in a similar way (doesn't look all that hard) and then get people to upgrade17:11
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto17:11
RPpaulg: with your failed build, could you confirm that a bitbake X(that failed) -c clean; bitbake X works ?17:11
RPfray: I think this is an existing builddir reuse problem17:11
paulgshould I copy anything aside 1st?17:11
fraymuch better then17:12
RPpaulg: you could save WORKDIR for that recipe I guess17:12
RPpaulg, fray: taking a build dir from before rss and then building in it post rss is probably how this breaks. If you have a clean tmp, its probably fine17:12
* paulg tries to avoid the nuke and pave unless required.17:13
*** john4 <john4!~john@> has joined #yocto17:14
RPpaulg: understandable, and I had thought the system had changed so much, it couldn't possibly reuse anything17:14
paulgit  did start pretty low in the build ; about 1k of 7k steps.17:15
*** john3 <john3!> has quit IRC17:16
*** ythl <ythl!8b55df0a@gateway/web/freenode/ip.> has quit IRC17:17
*** Guest4840 <Guest4840!> has joined #yocto17:17
paulgok,  as expected, a -c clean  fixed openssl-native17:17
*** john4 <john4!~john@> has quit IRC17:20
RPpaulg: and I was able to reproduce your problem by "bitbake pseudo-native" pre rss, update post rss "bitbake pseudo-native"17:22
RPfray: ^^^17:22
RPso we now know that a clean tmpdir helps with rss17:22
frayis it just native items that are broken pre/post rss?17:23
RPfray: we don't chrpath for target17:23
RPwe may as well just wipe tmpdir at this point though17:23
fraythat's what I thought.. same for nativesdk right?  so just native should be clearable..17:23
frayis there any way you can put a marker in the code that causes all of the natives to invalidate?17:24
RPfray: its all going to rebuild anyway so we may as well clean tmp17:24
fraybut will the native rebuilds also rebuild all of the target/sdk software?17:24
*** sgw_ <sgw_!~sgw_@> has joined #yocto17:24
RPfray: the natives do invalidate, I just bet that something doesn't clean properly (B != S support missing)17:24
RPfray: rss means the world totally changes17:25
RPpaulg: so the answer is to have a fresh tmpdir. I'm torn on whether we bump the tmpdir versioning for this17:28
RPI guess we should at the risk of annying anyone who already upgraded17:29
paulgI've still got that same build dir runnnig.   Odd that just those two pkgs barfed.17:29
RPpaulg: bad "make clean" support17:30
RPpaulg: I suspect we pass in new configure options and it doesn't rebuild the binaries17:31
ed2rburton: did you try to merge ? Any problems with it?17:31
ed2rburton: i was hoping it will be merged before rss patch as rebasing would be easier.17:32
RPed2: well, the rss patches are in :/17:32
ed2RP: i've noticed :(17:32
paulgstill churning along ;  about 3k of 8k done.17:33
RPpaulg: it is quite surprising its only those two17:33
RPpaulg: tempting just to bump PR on those two and call it good17:34
rburtonRP: i'd say absolutely throw in a tmpdir abi bump here17:35
paulgheh, jinxed myself.17:35
RPed2: I can give rebasing it a try if you want. I hadn't realised that patchset was pending. Has it brrn run through the AB ?17:35
paulg| ../subversion-1.9.5/subversion/libsvn_ra_serf/blame.c:25:18: fatal error: serf.h: No such file or directory17:35
paulg| compilation terminated.17:35
paulg| Makefile:761: recipe for target 'subversion/libsvn_ra_serf/blame.lo' failed17:35
paulgthat looks like a missing dependency and not RPATH17:35
RPpaulg: lets say I'm not surprised at all at subversion17:35
RPpaulg: we'll be passing in a new path and it won't have changed its config files17:36
*** ed2 <ed2!~Adium@> has quit IRC17:39
RPpaulg: did it get much further?17:44
RPpaulg: the problem may be in apr-utils-native btw17:44
RPor serf-native :/17:45
paulgstill waiting on running tasks to finish17:48
Strike5150Goodday,  My build keeps breaking on make for linux-yocto " No rule to make target 'zImage'.  Stop."  I did a bitbake -e | grep KERNEL_IMAGETYPE and its not being set anywhere is this why that happens?17:48
*** Snert <Snert!~snert_@> has quit IRC17:50
*** Snert <Snert!~snert_@> has joined #yocto17:50
*** alimon <alimon!~alimon@> has quit IRC17:51
*** jku <jku!> has joined #yocto17:54
RPStrike5150: which MACHINE are you building?17:54
paulgWARNING: No recipes available for:17:54
paulg  /home/paul/poky/meta-security/recipes-devtools/qemu/qemu_2.7.0.bbappend17:54
Strike5150RP: Trying to make a new machine based on core2-3217:54
*** mcudev <mcudev!> has joined #yocto17:54
paulgguess qemu got uprev'd17:54
Strike5150RP: I'm not doing very well :*(17:54
Strike5150I will post my machine file and the corresonding bbappend for kernel17:55
Strike5150RP: Machine.conf
Strike5150RP: linux-yocto.bbappend
Strike5150RP:  Might be a bit misleading I've commented a few things tried out different iterations in the machine.conf all resulting in the same thing17:58
RPpaulg: correct17:59
RPStrike5150: genericx86 isn't a tune so DEFAULTTUNE looks wrong18:00
*** ed2 <ed2!~Adium@> has joined #yocto18:00
ed2RP: i'll rebase it, no prob. I don't know if it was tested. I thought I missed something, that's why I asked rburton if he tried to merge it.18:01
RPStrike5150: your basic idea looks right at least18:01
Strike5150RP:  I've tried with core2-32, I'll run the build again and take it out.18:01
Strike5150RP: Nothing obvious I've missed?18:02
*** kybernesis <kybernesis!~kybernesi@> has joined #yocto18:02
RPStrike5150: been a while since I played with kernels :/18:02
RPStrike5150: I have to step afk now, sorry, hopefully someone else can spot it18:03
Strike5150RP: Ok thanks18:03
*** mckoan is now known as mckoan|away18:08
paulgsubversion is now ok after I cleansstate it and serf-native; we'll see what  blows up next18:09
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:11
*** t0mmy <t0mmy!~tprrt@> has quit IRC18:11
*** Unier <Unier!uid41153@gateway/web/> has quit IRC18:15
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC18:19
kanavinak@kanavin-desktop:~/development$ ./a.out18:21
kanavinSegmentation fault (core dumped)18:21
kanavinak@kanavin-desktop:~/development$ coredumpctl18:21
kanavinNo coredumps found.18:21
kanavinsystemd, I love you!18:21
kanavincan anyone help? :) where is the core?18:22
kanavinnevermind, sudo coredumpctl did the trick, but why on earth :-/18:25
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto18:25
*** vmeson <vmeson!> has quit IRC18:27
*** vmeson <vmeson!> has joined #yocto18:30
*** hbruce <hbruce!~hbruce@> has joined #yocto18:32
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC18:34
*** marka <marka!> has quit IRC18:36
*** ed2 <ed2!~Adium@> has quit IRC18:37
*** gnac <gnac!> has quit IRC18:39
*** gnac <gnac!> has joined #yocto18:40
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto18:45
*** kybernesis <kybernesis!~kybernesi@> has quit IRC18:53
*** sjolley <sjolley!~sjolley@> has joined #yocto18:54
mcudevI had a reference to /sources/meta-qt in my bblayers then removed it.  Another meta layer has a bbappend to qtbase, which is no longer included, generating an error.  How can I remove the processing of this recipe now that qt is not included?18:58
jkukanavin: I think it's in journald, and the required permission essentially gives you access to core dumps of all users18:59
*** grma <grma!~gruberm@> has quit IRC19:00
mcudevI should mention I am getting the error when running 'bitbake-layers show-recipes'19:01
mcudevJust learning yocto, trying to understand the structure and make minor tweaks to an existing build19:02
*** paw <paw!~afong@> has joined #yocto19:02
pawRP: hey, heard you were looking for me19:04
*** ed2 <ed2!~Adium@> has joined #yocto19:04
*** toanju <toanju!> has joined #yocto19:09
*** marka <marka!> has joined #yocto19:14
*** Amynka <Amynka!~frozen@gentoo/developer/amynka> has quit IRC19:15
*** paw <paw!~afong@> has left #yocto19:17
georgemAny meta-selinux people here? Something pushed this month seems to have broken setting selinux labels in the build for me. Just curious if anyone else has run into problems. bisecting but it's going to take quite a while.19:18
*** john1 <john1!> has joined #yocto19:20
*** Guest4840 <Guest4840!> has quit IRC19:21
*** jku <jku!> has quit IRC19:23
*** john2 <john2!~john@> has joined #yocto19:24
*** likewise <likewise!~chatzilla@> has joined #yocto19:27
*** john1 <john1!> has quit IRC19:27
*** jairglez <jairglez!~jairdeje@> has quit IRC19:33
mcudeva more focused version of my question:  We must use this layer for our board. recipes-qt/qt5/qtbase_%.bbappend requires from meta-qt layer.  the meta-qt layer was removed from bblayers.  I get a recipe parse error when I try and run bitbake.  What is the correct way to 'remove' processing of this bbappend without modifying the git repo meta-ts?19:33
*** present <present!> has joined #yocto19:34
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto19:34
*** Strike5150 <Strike5150!18de02de@gateway/web/freenode/ip.> has quit IRC19:35
*** toscalix <toscalix!~toscalix@> has quit IRC19:36
*** toscalix <toscalix!~toscalix@> has joined #yocto19:36
*** toanju <toanju!> has quit IRC19:39
*** Strike5150 <Strike5150!18de02de@gateway/web/freenode/ip.> has joined #yocto19:39
*** t0mmy <t0mmy!> has joined #yocto19:40
*** toscalix <toscalix!~toscalix@> has quit IRC19:41
*** JosePerez <JosePerez!~jgperezc@> has quit IRC19:47
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC19:53
rburtonmcudev: the neat way is for the layer doing the appending to see what layers are active before enabling its own parts, so the append is only scanned if meta-qt is present.  that needs to happen in meta-ts though.19:55
rburtoni believe theres a variable to make nonexisting bbappends a warning instead of fatal though19:56
rburtonset BB_DANGLINGAPPENDS_WARNONLY = 1 in local.conf?19:56
kergothlocal.conf would be too late19:56
kergothwait, no, that should work too19:57
kergothclearly i need more coffee19:57
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC20:00
lamegojoshuagl: are you around?20:10
rburtonkergoth: todays hack is a tiny class to add a pdb() function, call it in any bit of python and bitbake will stop and wait for you to connect over tcp to a pdb it spawned20:12
rburtonkergoth: (can't take any credit apart from the five lines to glue rpdb in though)20:12
rburton(Pdb) print(d)20:12
rburton<bb.data_smart.DataSmart object at 0x7fb0033545c0>20:12
kergothi've manually added the line in bitbake to inspect memory usage at particular points in the past20:13
*** ionte <ionte!> has quit IRC20:14
*** ionte <ionte!> has joined #yocto20:17
*** sjolley <sjolley!~sjolley@> has left #yocto20:21
*** berton <berton!~berton@> has quit IRC20:22
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto20:22
*** JosePerez <JosePerez!jgperezc@nat/intel/x-sfgsjgqhowblqiua> has joined #yocto20:23
*** jamesp <jamesp!~jamesp@> has joined #yocto20:25
*** pohly <pohly!> has quit IRC20:26
*** sgw_ <sgw_!~sgw_@> has quit IRC20:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC20:36
*** ka6sox is now known as zz_ka6sox20:38
*** lamego <lamego!jose@nat/intel/x-xhsaraxokpnqochs> has quit IRC20:39
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:39
*** caiortp <caiortp!~inatel@> has quit IRC20:41
*** sgw_ <sgw_!~sgw_@> has joined #yocto20:42
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC20:43
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:43
*** alimon <alimon!~alimon@> has joined #yocto20:45
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto20:50
*** stephano_ <stephano_!~stephano@> has joined #yocto20:55
*** stephano_ <stephano_!~stephano@> has quit IRC20:57
*** morphis <morphis!> has quit IRC20:57
*** alimon <alimon!~alimon@> has quit IRC20:58
*** stephano <stephano!~stephano@> has quit IRC20:58
*** alimon1 <alimon1!~alimon@> has joined #yocto20:58
*** alimon1 <alimon1!~alimon@> has quit IRC20:58
*** jairglez <jairglez!jairdeje@nat/intel/x-xonteoppudnzaqhg> has joined #yocto21:00
*** zz_ka6sox is now known as ka6sox21:00
*** clsulliv <clsulliv!~clsulliv@> has left #yocto21:02
*** stephano <stephano!~stephano@> has joined #yocto21:02
*** clsulliv <clsulliv!~clsulliv@> has joined #yocto21:02
mcudevkergoth: thanks, will try adding that21:03
*** toanju <toanju!> has joined #yocto21:05
*** icanicant_ <icanicant_!> has joined #yocto21:05
*** alimon <alimon!~alimon@> has joined #yocto21:06
*** icanicant_ <icanicant_!> has quit IRC21:06
*** morphis <morphis!> has joined #yocto21:09
*** stephano <stephano!~stephano@> has quit IRC21:10
*** khem <khem!~khem@unaffiliated/khem> has quit IRC21:11
*** bluelightning <bluelightning!~paul@> has joined #yocto21:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:11
*** morphis <morphis!> has quit IRC21:13
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto21:13
*** ant_home <ant_home!> has joined #yocto21:16
*** istarilucky <istarilucky!~rlucca@> has quit IRC21:18
*** lamego <lamego!~jose@> has joined #yocto21:23
*** stephano <stephano!~stephano@> has joined #yocto21:25
*** stephano <stephano!~stephano@> has quit IRC21:26
*** stephano <stephano!~stephano@> has joined #yocto21:27
miceopedeis there a way to provide authentication to SRC_URI fetching from https://, without encoding the username/password in the recipe? we want to pull some vendored binaries but do not want to check the credentials into git21:30
kergothwith recent wget, you can use a wget askpass helper21:31
kergothotherwise .netrc21:31
miceopede.netrc works for me21:32
miceopede@kergoth thanks21:32
*** john4 <john4!~john@> has joined #yocto21:34
*** rcwoolley_ <rcwoolley_!~rwoolley@> has quit IRC21:34
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC21:34
*** john2 <john2!~john@> has quit IRC21:34
mcudevBB_DANGLINGAPPENDS_WARNONLY = "true" appears to work21:36
*** igor1 <igor1!~igor@> has quit IRC21:36
khemBB_DANGLINGAPPENDS_WARNONLY if needed means some layer is misbehaving21:39
mcudevyes it is21:39
khemyou should inform the layer which is causing it21:39
mcudevwill do21:39
mcudevso is it typical for yocto to chew up 35G of hdd space for a build?21:40
khemyou are building a full platform from scratch21:41
mcudevit appears that dbg packages are huge compared to the actual package21:42
khemyou can change options to not generate debug info if you dont need it21:42
mcudevi am looking for the option that enables that21:44
mcudevnew to yocto, working with new board with yocto support provided by mfg21:44
khemRP: I am seeing this error with recipe sysroot enabled
mcudevdocumentation is "do this and don't ask questions", but we need to add packages21:45
khemRP: this package configures correctly on ubunut21:45
joshuagllamego: kind of, for a short while at least, what's up?21:45
RPkhem: not seen that before. Any idea what this "cfg" directory is? Its not any standard path I've heard of before21:46
khemmcudev: look for SELECTED_OPTIMIZATION and remove -g from it21:46
khemRP: I was looking at the first error which is something to do with regexp21:46
mcudevis the following valid in local.conf: EXTRA_IMAGE_FEATURES -= "dbg-pkgs"21:47
RPkhem: that is from recent autotools, lots of recipes do that21:47
lamegojoshuagl: Hi Joshua. Just to let you know that I closed 10875 & 10876. I couldn't reproduce and couldn't find the issue in logs.21:47
RPkhem: fatal part is aclocal: error: couldn't open directory 'cfg': No such file or directory21:47
lamegojoshuagl: we can reopened if needed of course.21:47
lamego*reopen them21:48
RPmcudev: EXTRA_IMAGE_FEATURES_remove = "dbg-pkgs" is21:48
khemRP: AC_CONFIG_HEADERS([cfg/config.h]) and AC_CONFIG_MACRO_DIR([cfg]) AC_CONFIG_AUX_DIR([cfg])21:49
khemRP: removing dbg-pkgs wont stop compiler from creating debug info21:49
khemso objects still will be large21:49
RPkhem: I didn't realise that was the question21:49
RPkhem: does the recipe set acpaths?21:50
mcudevnodejs-4.4.3-r0.cortexa9hf_neon.rpm = 3.3M21:50
mcudevnodejs-dbg-4.4.3-r0.cortexa9hf_neon.rpm = 94M21:50
RPkhem: acpaths = "cfg" might help it21:50
mcudevand I'm running in a VM on a smaller SSD, so space is starting to become an issue21:51
RPkhem: "-I cfg" even21:51
mcudevso I want to stop the dbg packages21:51
RPkhem: Its possible the autotools changes have affected this somehow21:51
RPmcudev: SELECTED_OPTIMIZATION_remove "-g" ?21:52
mcudevwill try21:57
*** t0mmy <t0mmy!> has quit IRC21:57
khemRP: I think no it does not set acpaths21:57
joshuagllamego: no problem21:59
joshuaglthanks for the notice22:01
*** mcudev <mcudev!> has quit IRC22:02
khemRP: acpaths doesnt help22:03
RPkhem: :(22:07
RPkhem: not sure why that would suddenly break. Is it a public recipe?22:08
khemautotools.bbclass is overriding my setting22:08
*** pauldevguy <pauldevguy!~pauldevgu@> has joined #yocto22:08
khemRP: yes it is22:09
khemRP: acpaths_forcevariable = "-I cfg" works22:11
RPkhem: did you set it after the inherit autotools ?22:12
khemshouldnt this be ?=22:12
RPwe should probably make it a weak default22:13
RPkhem: snap!22:13
aehs29is anyone having trouble with glibc-initial on x86 archs?22:13
aehs29is anyone ELSE*22:14
khemRP: its 12 year old setting I wonder if its set in stone :)22:14
RPaehs29: autobuilder is green...22:14
RPkhem: :D22:14
khemaehs29: you have to be specific as in describe your error first so others can relate to it22:15
aehs29RP: interestin, Im having issues with both genx86 and qemux86, on different machines22:15
aehs29khem: give me a sec22:15
aehs29khem: | checking installed Linux kernel header files... missing or too old!22:16
aehs29| configure: error: GNU libc requires kernel header files from22:16
aehs29khem: ERROR: Task (/home/aehernan/yocto/poky/meta/recipes-core/glibc/ failed with exit code '1'22:16
aehs29khem: it doesnt show up on genx86-64, Ive not tried other archs yet22:16
khemRP: there are recipes in oe-core which override acpaths
khemRP: I wonder how that code ever worked22:17
RPkhem: they set it after inherit autotools ?22:17
khemRP: I am setting it after inheriting autotools22:18
*** marka <marka!> has quit IRC22:19
RPkhem: you shouldn't need forcevariable then22:20
*** toanju <toanju!> has quit IRC22:22
JosePerezkhem: aehs29:  I also saw this issue on my machine building for qemux8622:22
*** ntl <ntl!> has quit IRC22:25
*** manju <manju!95c73efe@gateway/web/freenode/ip.> has joined #yocto22:26
khemRP: yeah order matters22:27
khemI have to only set it after inheriting autotools22:27
khemRP: I think using ?= is still a better option22:28
khemto fix the order dependency22:28
RPkhem: agreed22:29
RPkhem: its just old code22:29
khemRP: I will sent a patch to fix it22:29
RPkhem: sounds good thanks22:29
kergothAnyone seen an inability to login over ssh with morty? The server is immedidately killing the connection, saying "debug1: Killing privsep child" with nothing else useful. disabling privsep makes it successfully log in22:29
RPkergoth: no...22:30
RPpaulg: did that build work out?22:30
khemkergoth: are you using UsePrivilegeSeparation=sandbox22:33
ant_homeRP: hi there. Once patchwork swallows your patchset wrt recipe-sysroot I'll surely need your help for klcc-cross :)22:34
RPant_home: We've not talked about that in a while!22:35
ant_homeheh, just minor breakages up to now :)22:35
RPant_home: we might get lucky and it might just work22:36
ant_homelet see, I'm catching up now with the deploy dir changes22:37
ant_homebtw klcc development seems stale22:38
ant_homeso klibc22:38
ant_homeI'll spend my little time with musl in future22:38
*** stephano <stephano!~stephano@> has quit IRC22:40
khemRP: posted here
ant_homehi khem22:41
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC22:43
RPkhem: queued in -next22:43
khemRP: another problem I am seeign is when building gptfdisk22:44
khemits symlinking native .so into sysroot22:45
RPkhem: :(22:47
*** stephano <stephano!~stephano@> has joined #yocto22:47
khemcompiler says
RPkhem: we'll just have to deal with each issue in turn. Its why I've merged it now, give us time before release22:47
khemyeah thats fine22:47
khemI am helping :)22:47
*** JosePerez <JosePerez!jgperezc@nat/intel/x-sfgsjgqhowblqiua> has quit IRC22:47
RPkhem: I appreciate it. That error is odd, why would the arm compiler poke into the native sysroot? :/22:48
paulgRP, a couple other pkgs needed -c cleansstate and now I need to figure out why this new error happens:22:48
paulg| configure: error: could not find dbus-binding-tool in $PATH. You can run22:48
paulg|   ./configure DBUS_BINDING_TOOL=/path/to/dbus-binding-tool to define22:48
paulg|   a custom location for it.22:48
paulg| ERROR: configure failed22:48
paulg| ERROR: Function failed: do_configure (log file is located at /home/paul/poky/build/tmp/work/core2-64-overc-linux/xfdesktop/4.12.3-r0/temp/log.do_configure.15578)22:48
khemRP: I am reusing sstate22:49
RPpaulg: I think a clean tmp is going to be the way forward22:49
khemI wonder if that plays a role22:49
RPkhem: I'd very much any checksums match pre rss22:49
paulgyah for sure that would have been faster, but I am stubborn.  :)22:49
khemRP: I was wondering if LAYER vesion should be bumped22:49
RPpaulg: I think I'll have to bump the tmpdir version number22:49 error of today?22:50
ant_homeERROR: python3-pygobject-3.22.0-r0 do_prepare_recipe_sysroot: Function failed: extend_recipe_sysroot22:50
RPant_home: that says what failed but not how...22:50
ant_homeok, so it isnew...22:50
khemdeleted sstate now lets see a build from scratch completely22:53
RPant_home: could you apply this patch: (or change the check_call to check_output) and then rerun please. That error message doesn't help :(22:53
ant_homeyup, rebuiling22:56
RPant_home: I think I just increased the urgency of merging that one22:57
ant_homestill failing, after -c cleansstate22:57
ant_homepatch applied22:57
ant_homedo you need full log?22:57
RPant_home: one like the one you pasted above please22:58
RPant_home: should have the output for the failed command this time22:58
*** Geoff <Geoff!49111299@gateway/web/freenode/ip.> has joined #yocto23:00
*** fmeerkoetter <fmeerkoetter!> has quit IRC23:01
*** bfederau <bfederau!> has quit IRC23:01
*** bfederau <bfederau!> has joined #yocto23:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto23:01
*** Geoff is now known as Guest1563823:01
RPant_home: which version of python 3 is on your system?23:01
Guest15638hi guys, I'm working on an image that uses meta-qt5 with egl plugin for rendering.  It was all working but I recently added another layer meta-kontron for some GPIO drivers.   Now /usr/lib/dri/ has disappeared from my image.  Any tips on how to debug this?23:02
khemRP: ant_home 3.6 doesnt work well yet with master btw.23:02
RPkhem: so I heard :/23:02
khemRP: I have locked my archlinux to 3.5 for now23:03
Guest15638im gathering that it is somethign to do with the configuration of mesa and perhaps virtual providers whether it would choose to include the kms_swrast library or not23:03
ant_homeseems 2.7.2 default and 3.523:03
ant_homeUbuntu 16.04 vanilla23:03
*** agust <agust!> has quit IRC23:04
RPant_home: I'd hoped python would show the output of the failed command in the traceback but it seems not :(23:04
khemGuest15638: does meta-kontrol have bbappends for mesa23:04
ant_homeandrea@ThinkPad-T520:/oe/oe-core/build$ pyversions -i23:04
RPant_home: its python3 we care about these days (python3 --version)23:05
ant_homeI have to check how Ubuntu does it...I only know Gentoo's way23:05
RPant_home: could you share /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/temp/log.do_prepare_recipe_sysroot.27568 ?23:05
Guest15638khem: no I"m not seeing any references to mesa in meta-kontron.  The new layer has some linux kernel patches that seem fairly harmless, and a new machine file which I switched over to.  But the difference between the machine files seems minimal.23:06
Guest15638I think a while ago I was missing and I fixed it by adding mesa-megadrivers to my image23:06
khemis it changing DISTRO_FEATURES or MACHINE_FEATURES23:07
Guest15638but mesa-megadrivers is still on the image it just doesn't include that particular library now23:07
Guest15638yes it does23:07
*** lamego <lamego!~jose@> has quit IRC23:07
Guest15638its adding va-impl-intel to MACHINE_FEATURES which I think is a graphics thing23:07
Guest15638could that have broken mesa dri?23:07
khemdo you have opengl in DISTRO_FEATURES23:07
khemcould be I dont know much about meta-kontron and it doesnt seem to be open23:08
Guest15638um, is there an easy way to check that from bitbake?  I have about 10 layers so not sure whats the easy way to check the DISTRO_FEATURES for my specific image and machine23:08
RPant_home: that is definitely more helpful, the real error is in there23:09
khembitbake -e bash | grep -e "^DISTRO_FEATURES="23:09
khemGuest15638: do that with and without kontrol layer23:09
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto23:09
*** ed2 <ed2!~Adium@> has quit IRC23:10
RPant_home: does /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/recipe-sysroot/etc exist?23:11
ant_homeandrea@ThinkPad-T520:/tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0$ ls23:11
RPant_home: we need to figure out why /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/recipe-sysroot/usr/bin/postinst-ldsoconf-gobject-introspection is failing (its a script)23:12
RPant_home: you could even try running it by hand23:12
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC23:12
sgw_RP: has there been a change that would cause Taskhash mismatches when running distro_check (via INHERIT += "distrodata")?23:13
RPsgw_: no one change jumps out23:13
sgw_RP: ok, I will open a bug then, very reproduicble.23:14
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto23:15
RPant_home: are you sure /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/recipe-sysroot/etc/ exists ?23:15
ant_homeno /etc23:16
ant_homecreated that and the script runs23:17
*** rburton <rburton!> has quit IRC23:17
RPant_home: ok, I think there is simply a bug there23:18
ant_homeI've created now the dir and it compiles23:18
ant_homejust fine23:19
*** joshuagl <joshuagl!joshuagl@nat/intel/x-qzpgpinuhrqyhfht> has quit IRC23:19
RPant_home: I think this is the right fix:
RPCut and paste failure23:21
ant_homeechoing too much...23:21
*** manuel_ <manuel_!~manuel@> has quit IRC23:23
ant_homeRP: btw as of today/now klcc-cross still compiles and so its artifacts :)23:24
Guest15638khem: no differences in DISTRO_FEATURES23:24
RPant_home: ! :)23:24
ant_homesomehow kernel disappears from DEPLOYDIR on rebuild from sstate but this is minor problem :p23:26
Guest15638main difference that is relevant to graphics seems to be that meta-kontron has MACHINE_FEATURES_append  = " va-impl-intel"23:26
Guest15638and also MACHINE_HWCODECS ?= "va-intel gstreamer-vaapi-1.0"23:26
Guest15638should i try commenting those out, is it feasible that that could have caused to be missing from mesa?23:26
ant_homeRP: go forth with the changes!23:27
*** ant_home <ant_home!> has quit IRC23:27
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto23:32
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC23:33
*** nighty <nighty!> has quit IRC23:34
*** manuel_ <manuel_!> has joined #yocto23:37
* RP fires the M2 build23:42
sgw_RP: Awesome I will keep an eye on it later23:42
manjuhi all, do we know if we can build Morty on RHEL 6.8? I do see that CentOS 6.x was dropped as per documentation23:43
RPbah, still one subversion recipe in OE-Core23:45
RPmanju: I suspect there may be some issues, how serious they are I don't remember...23:46
*** present <present!> has quit IRC23:46
manjuRP: ok thanks23:48
nrossimanju: the kernel version of RHEL 6 is probably the biggest problem. If i remember correctly uninative is built for 3.2+ kernels23:52
*** likewise <likewise!~chatzilla@> has quit IRC23:54
*** Biliogadafr <Biliogadafr!> has quit IRC23:55
manjunrossi: ok, how do we find uninative build versions?23:58

Generated by 2.11.0 by Marius Gedminas - find it at!