Friday, 2017-01-27

*** rburton <rburton!> has quit IRC00:03
miceopedehow do i log the output of a command in a recipe for debugging? i want to do something like bb.plain(`ls -l`)00:04
*** rburton <rburton!> has joined #yocto00:04
*** nighty <nighty!> has quit IRC00:04
*** dv_ <dv_!~quassel@> has quit IRC00:04
*** dv_ <dv_!~quassel@> has joined #yocto00:05
*** smiller6 <smiller6!~smiller6@> has joined #yocto00:19
*** smiller6 <smiller6!~smiller6@> has joined #yocto00:19
*** Crofton <Crofton!~Crofton@> has joined #yocto00:20
miceopedei'm inheriting from bin_package, and it looks like it unpacked my stuff into ${WORKDIR} instead of ${WORKDIR}/image, which is the default location of ${D}. but reading through the bin_package.bbclass looks like it untars it to ${D}. did ${D} change somehow beteween the time bin_package did it's install and my recipe is run?00:20
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:22
*** vmesons <vmesons!> has joined #yocto00:23
bluelightningmiceopede: it's using tar to copy from ${S} to ${D}00:23
*** vmeson <vmeson!> has quit IRC00:23
bluelightningmiceopede: you may wish to set subdir= and then if necessary set S accordingly00:24
bluelightningsubdir= being a parameter in the URL in SRC_URI00:24
bluelightningthat's covered in the comments at the top of bin_package.bbclass00:24
bluelightningmiceopede: re logging - anything that produces output is going into the task log - you will find that under ${T} i.e. ${WORKDIR}/temp00:25
bluelightningso you don't necessarily need to run it through bb.plain()00:25
miceopedestill don't quite understand what's going on though. bin_package_do_install() is run. it appears it untarred it to ${WORKDIR} instead of ${D}00:28
miceopededo_install_append() comes before bin_package_do_install()?00:32
bluelightningthe bin_package_do_install becomes the implementation of do_install (via EXPORT_FUNCTIONS)00:34
bluelightningthen any do_install_append()s will be appended to the end of that00:34
bluelightningthere are two tar operations going on here00:34
bluelightningone that happens in do_unpack00:34
-YoctoAutoBuilder- build #1070 of nightly-x86-64-lsb is complete: Failure [failed BuildImages_1] Build details are at
bluelightningthat's going into ${WORKDIR} - you need to add ;subdir=something to the entry in SRC_URI to put that in a subdirectory if you need that00:35
bluelightningand then if necessary set the S variable so it points to "${WORKDIR}/something"00:35
bluelightning(I say if necessary, because you could always set subdir= such that it matched the default value of S)00:36
bluelightningthen there's the second tar that happens during do_install, that's what's defined by bin_package00:36
miceopedeso ;subdir=${S}, then bin_package will pick it up in do_install?00:37
miceopedewhat is the first unpack for, then?00:37
bluelightningthe first unpack is the only way source actually gets unpacked00:37
bluelightningthe tar operation in do_install is just copying... don't be confused by the fact that tar is being used, that's just to preserve permissions, hardlinks etc.00:38
*** diego_r <diego_r!> has quit IRC00:38
miceopedei see00:39
bluelightning(I say source, I mean the contents of what you've put in SRC_URI)00:39
miceopedeok, makes sense now00:40
miceopedethanks so much00:40
bluelightningno worries00:40
bluelightningI wonder if we need a new bin_package class that sets up some of these things by default00:40
bluelightningright now it is a bit awkward00:41
*** diego_r <diego_r!> has joined #yocto00:41
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC00:42
miceopedeit's a bit confusing. i was expecting that it would be fetched to ${S}, then bin_package would extract it to ${D}00:44
miceopedemaybe that was the wrong mental model00:44
*** sameo <sameo!samuel@nat/intel/x-kqiinoawacenymdt> has quit IRC00:45
*** sgw_ <sgw_!sgw_@nat/intel/x-jgqxdbpudidqlyth> has quit IRC00:46
bluelightningI guess underlying is that it is often assumed that S controls where the source gets unpacked00:48
bluelightningit doesn't - it merely specifies where the system should expect the natural root of the source to have been unpacked00:48
bluelightning(since most source tarballs contain a subdirectory at the root and have everything underneath that)00:49
miceopedeisn't that the most obvious way of interpreting ${S}? i specify a source tarball in SRC_URI. i expect it to be in ${S}00:49
bluelightningright, and a lot of the time the default value of S and the subdirectory name used in a source tarball will match up00:50
bluelightningbut whether or not it does depends on what name was used when that tarball was created upstream, which we usually don't control00:50
bluelightningof course this is for general recipes - for bin_package recipes where you're bringing in an rpm or a tarball or similar that's laid out in the same way you want it to appear on the target, then you don't have such a subdirectory00:52
bluelightningso our default of unpacking into ${WORKDIR} isn't ideal00:52
*** nighty <nighty!> has joined #yocto00:52
bluelightningfor the bin_package scenario, I mean00:52
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC00:55
miceopedeyeah. i'll just repackage my tarball to match ${S}00:59
bluelightningor just use subdir=${BP} - there's nothing wrong with doing that01:00
bluelightningat least then you don't have to remember to put the subdirectory in if you regenerate it later01:00
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto01:05
*** smiller6 <smiller6!~smiller6@> has quit IRC01:06
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC01:09
*** jamesp <jamesp!~jamesp@> has quit IRC01:11
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto01:12
*** john4 <john4!~john@> has quit IRC01:31
*** gizero <gizero!~gizero@> has joined #yocto01:37
*** gizero <gizero!~gizero@> has quit IRC01:41
-YoctoAutoBuilder- build #1051 of nightly-x86-lsb is complete: Failure [failed BuildImages_1] Build details are at
miceopededo i need to put all my *.a files into FILES_${PN}-staticdev? or can i just add them to FILES_${PN}-dev?01:51
miceopedethey're only needed at buildtime01:51
*** paulg <paulg!> has quit IRC01:59
bluelightningmiceopede: typically they would go into ${PN}-staticdev so that ${PN}-dev doesn't fill up with them, but I don't think there's actually a QA check to prevent them going into ${PN}-dev02:01
*** csanchezdll <csanchezdll!> has quit IRC02:03
miceopede@bluelightning  what's the difference? if i put them in -staticdev, they won't get staged to the target, but if i put them in -dev, they will?02:07
bluelightningmiceopede: if by "staged" you mean installed on the target device, it depends02:08
bluelightningmiceopede: by default, neither will... if you explicitly install the -dev package, or you have dev-pkgs in IMAGE_FEATURES, then files in the -dev package will be installed02:08
bluelightningFWIW when it comes to the SDK, there -dev packages are installed by default, but not -staticdev02:09
bluelightning(by virtue of the default value of SDKIMAGE_FEATURES)02:09
miceopedehow does that make sense?02:09
bluelightningmiceopede: which, sorry?02:10
miceopedepresumably if i'm bulding the sdk, i'd want .a's in there to link against, no?02:10
bluelightningonly if you're statically linking your executable, if you aren't (and we assume most people aren't) then they are of no use at all02:11
miceopedehm... i see02:11
bluelightningin any case it's just a default, you can change SDKIMAGE_FEATURES to include "staticdev-pkgs" if you are expecting to link thing statically02:12
miceopedei see, ok02:13
miceopedeso now i added a bunch of .so's to -dev, and it complains "-dev package contains non-symlink .so:02:15
miceopedeall i have are the raw .so's02:15
miceopedethese are supposed to be symlinks..?02:15
miceopedei guess i put these into FILES_${PN} instead?02:18
manjumiceopede: .so is supposed to be symlinks02:22
manjuif you really want to have .so in -dev you can override it with INSANE_SKIP_${PN} ="dev-so"02:24
bluelightningmiceopede: the .so files are needed at runtime - so typically they go into the main package02:28
bluelightningexcept for a .so symlink without a version, that goes into the dev package02:28
bluelightning(we assume if you put libraries into the standard library paths, that you are using standard library versioning)02:29
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC02:36
*** gizero <gizero!~gizero@> has joined #yocto02:37
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto02:38
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto02:41
*** gizero <gizero!~gizero@> has quit IRC02:41
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC02:46
*** sjolley1 <sjolley1!~sjolley@> has joined #yocto02:55
*** sjolley <sjolley!~sjolley@> has quit IRC02:57
*** manju <manju!95c73efe@gateway/web/freenode/ip.> has quit IRC03:00
*** hbruce <hbruce!~hbruce@> has quit IRC03:01
*** moto-timo <moto-timo!~ttorling@> has joined #yocto03:01
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto03:01
*** hbruce <hbruce!~hbruce@> has joined #yocto03:03
*** todor <todor!todor@nat/intel/x-zvyqnrtkukkfaumj> has quit IRC03:10
*** todor <todor!todor@nat/intel/x-psskqfccgdjgzdkf> has joined #yocto03:10
*** JaMa <JaMa!~martin@> has joined #yocto03:11
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC03:13
*** sgw_ <sgw_!~sgw_@> has joined #yocto03:15
*** tripzero <tripzero!~tripzero@> has quit IRC03:15
*** MWelchUK <MWelchUK!> has quit IRC03:17
*** dreyna_ <dreyna_!> has quit IRC03:20
*** tripzero <tripzero!~tripzero@> has joined #yocto03:22
*** MWelchUK <MWelchUK!> has joined #yocto03:30
-YoctoAutoBuilder- build #1072 of nightly-x86 is complete: Failure [failed BuildImages_1] Build details are at
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC03:49
*** bavery_fn <bavery_fn!~bavery@> has quit IRC03:49
*** bavery_fn <bavery_fn!bavery@nat/intel/x-hmvdpoljdhlzwfka> has joined #yocto03:50
*** redengin <redengin!~redengin@2601:600:9200:a356:225:22ff:fe3a:aa83> has joined #yocto03:59
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto03:59
*** zeddii_home <zeddii_home!> has joined #yocto04:16
smurrayI notice the morty docs don't list python3 in the list of required packages in the quick start guide, is that an oversight?04:29
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC04:34
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto04:34
*** gizero <gizero!~gizero@> has joined #yocto04:37
*** gizero <gizero!~gizero@> has quit IRC04:42
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC05:21
*** redengin <redengin!~redengin@2601:600:9200:a356:225:22ff:fe3a:aa83> has quit IRC05:34
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC05:35
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto05:35
*** redengin <redengin!~redengin@2601:600:9200:a356:c000:7e89:a756:35c2> has joined #yocto05:37
*** morphis <morphis!> has joined #yocto05:40
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC05:43
*** sgw_ <sgw_!~sgw_@> has quit IRC06:02
khemsmurray: probably, but python3 is installed on most distros now a days06:09
smurraykhem: sure. I noticed it with a container setup I'd created with debootstrap, probably not typical.06:20
*** s65b40 <s65b40!c32a382b@gateway/web/freenode/ip.> has joined #yocto06:21
khemit wont hurt to add it though, feel free to send a patch06:21
smurraykhem: okay06:22
*** AndersD <AndersD!> has joined #yocto06:26
*** AndersD <AndersD!~anders@> has joined #yocto06:28
-YoctoAutoBuilder- build #1053 of nightly-world is complete: Success [build successful] Build details are at
*** gizero <gizero!~gizero@> has joined #yocto06:30
*** agust <agust!> has joined #yocto06:31
*** voltbit <voltbit!~acid___@> has joined #yocto06:31
*** gizero <gizero!~gizero@> has quit IRC06:34
*** qt-x <qt-x!~Thunderbi@> has joined #yocto06:36
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto06:39
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto06:40
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC06:45
*** pohly <pohly!> has joined #yocto06:49
*** s65b40 <s65b40!c32a382b@gateway/web/freenode/ip.> has quit IRC06:49
-YoctoAutoBuilder- build #776 of nightly-world-lsb is complete: Success [build successful] Build details are at
*** open-nandra <open-nandra!> has joined #yocto07:03
*** gizero <gizero!~gizero@> has joined #yocto07:07
*** freanux <freanux!~freanux@unaffiliated/freanux> has quit IRC07:18
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto07:28
*** deva <deva!~deva@> has joined #yocto07:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC07:28
*** HyP3r <HyP3r!> has quit IRC07:34
devaI am trying to figure out how to create an .imx u-boot image using mkimage -T imximage but I cannot find the "right place"(tm) to put the -T imximage argument.07:36
*** psadro <psadro!~Thunderbi@2620:107:9000:2:70c4:95ff:fe1d:9866> has quit IRC07:39
*** psadro <psadro!~Thunderbi@2620:107:9000:2:70c4:95ff:fe1d:9866> has joined #yocto07:39
*** jku <jku!~jku@> has joined #yocto07:39
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto07:44
*** t0mmy <t0mmy!> has quit IRC07:44
*** groleo <groleo!> has joined #yocto07:45
*** gizero <gizero!~gizero@> has quit IRC07:55
*** joseppc <joseppc!> has joined #yocto07:59
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto07:59
*** mckoan|away is now known as mckoan08:05
*** t0mmy <t0mmy!~tprrt@> has joined #yocto08:06
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:07
pohlybluelightning: "devtool upgrade" fails with an error about reading the non-existent recipe from workspace/recipes. Not sure whether it is related, but in the case that I am currently trying (devtool upgrade --srcrev 922421cf795d53d339862bb2d99f1a85c96ad9a3 --version 0.6.4 multipath-tools) rebasing patches fails.08:10
pohlyI guess I should file a bug...08:10
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC08:12
*** Kakounet <Kakounet!> has joined #yocto08:12
*** gizero <gizero!~gizero@> has joined #yocto08:17
ernstpdeva: doesn't IMAGE_BOOTLOADER = "u-boot" and image_type_fsl.bbclass do the right thing?08:20
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto08:22
*** rubdos <rubdos!~rubdos@2a02:2788:1036:2d::2> has quit IRC08:23
*** csanchezdll <csanchezdll!> has joined #yocto08:23
*** JoiF <JoiF!~jofr@> has joined #yocto08:24
*** rajm <rajm!> has joined #yocto08:24
*** fl0v0 <fl0v0!> has joined #yocto08:25
*** toanju <toanju!~toanju@> has joined #yocto08:28
devaernstp, I am currently using u-boot-fslc (from meta-fsl)and it08:30
devaform meta-fsl-arm08:31
devait produces u-boot-mfgtool-v2016.11+gitAUTOINC+615fdbc2b6-r0.img08:32
ernstpwhat MACHINE?08:33
devaernstp, I cannot find image_type_fsl.bbclass anywhere... do I need another layer?08:34
ernstpthat's wierd... which branch of meta-fsl-arm?08:35
devaernstp, HEAD as of a few months ago08:36
ernstpsure it's not there? in classes...?08:36
ernstpthen in conf/machine/include/ there's a bunch of defines like UBOOT_MAKE_TARGET ?= "u-boot.imx" and UBOOT_SUFFIX ?= "imx"08:37
ernstpI'm not really sure what problem you're trying to solve actually :-)08:37
*** rubdos <rubdos!> has joined #yocto08:37
*** mdnneo <mdnneo!~umaucher@> has joined #yocto08:38
devaernstp, Aah... it's called image_type*s*_fsl.bbclass :-)08:38
*** toscalix <toscalix!~toscalix@> has joined #yocto08:40
*** redengin_ <redengin_!~redengin@2601:600:9200:a356:58bd:6092:8450:aaee> has joined #yocto08:41
bluelightningpohly: if you would please, thanks08:41
*** redengin <redengin!~redengin@2601:600:9200:a356:c000:7e89:a756:35c2> has quit IRC08:42
devaI tried setting UBOOT_SUFFIX = "imx" in my bbappend and now it seem to create the .imx file but fails in a copy step:
*** sameo <sameo!~samuel@> has joined #yocto08:50
*** joshuagl <joshuagl!joshuagl@nat/intel/x-ipvdpncnafxhftna> has joined #yocto08:52
devaernstp, It appears that the UBOOT_SUFFIX is set to .img in the imx6ulevk machine file in metal-fsl-arm. Setting it in my own machine file makes the "copy to deploy" step look for an imx file, but the mkimage command still uses "-T firmware" and not "-T imximage"08:56
pohlybluelightning: See - I had a quick look through the code, but it did not become clear to me where the file should have been created at that point (if at all) or whether the call itself should create the file, so I'll leave that in your capable hands.09:00
yoctiBug 10981: normal, Undecided, ---, paul.eggleton, NEW , devtool: upgrade fails, recipe file not found09:00
ernstpdeva: clean?09:00
*** graphiqs <graphiqs!> has joined #yocto09:01
pohlyIn the meantime I am doing the recipe upgrade manually. It is a lot more work, which just goes to show how useful devtool is - when it works ;-}09:01
devaernstp, Would "bitbake -c clean u-boot-fslc" be enough? or should I clean "deeper"09:03
ernstpdeva: looks good :-)09:03
*** joseppc <joseppc!> has joined #yocto09:04
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto09:04
jkuRP: I'm looking at cross.bbclass where target_base_libdir is built with "{target_base_prefix}/${baselib}" instead of just immediately expanding ${base_libdir}. This is a problem if I modify base_libdir for usrmerge...09:04
devaernstp, Same problem09:04
jkuRP, I realize dffe253336f was 6 years ago but maybe you have some ideas?09:04
devaIt appears that the UBOOT_SUFFIX is not used by the mkimage command. Do you know where I can find it? IO have traced the 'require' tree to but it is not present in that file09:04
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto09:07
*** toanju <toanju!~toanju@> has quit IRC09:09
*** toanju <toanju!~toanju@> has joined #yocto09:10
devaernstp, The oe_mkimage function in meta/classes/image_types_uboot.bbclass does not contain the phrase  "-T firmware" but rather "-T ramdisk" so that one is not the one being called.09:13
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC09:13
ernstpdeva: the -T imximage command is in the u-boot source code...09:16
devaernstp, You mean the recipe? or the c code?09:17
devaeh... byt "c code" I of course mean the code from the u-boot git repo09:18
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC09:24
*** dreyna_ <dreyna_!> has joined #yocto09:25
*** dumb <dumb!~dumb@> has joined #yocto09:26
*** joshuagl <joshuagl!joshuagl@nat/intel/x-ipvdpncnafxhftna> has quit IRC09:26
dumbtoo much recursions while resolving '%s'; loop in '%s'" %09:27
dumbError from package class09:27
dumbcan anyone help on this ?09:27
RPjku: whatever you do, please please please don't propose immediate expansion. It causes untold problems for the cross classes and we're finally nearly free of it09:28
jkugood to know :)09:31
RPjku: looking at that commit, the basic idea is that you can add in multilib overrides and the variables all adjust themselves to the right values09:31
RPjku: if you immediately expand, the makeup of the variable is lost and they don't change09:32
jkuthanks, I'll try to figure out a fix09:33
RPjku: with usrmerge doesn't exec_prefix or base_prefix change and then these adjust?09:34
jkubase_prefix can't change because e.g. sysconfdir = "${base_prefix}/etc"09:35
RPjku: this sounds rather like a mess :(09:35
*** jku <jku!~jku@> has left #yocto09:36
*** jku <jku!~jku@> has joined #yocto09:36
*** Kakounet <Kakounet!> has quit IRC09:36
* RP tries to remember what the big advantage of usrmerge is09:36
RPjku: you probably want target_base_libdir_class-cross = "${target_exec_prefix}/${baselib}"09:37
*** sameo <sameo!~samuel@> has quit IRC09:37
*** grma <grma!~gruberm@> has joined #yocto09:43
mckoangood morning09:44
ernstpdeva: u-boot git09:46
*** ed2 <ed2!~Adium@> has joined #yocto09:49
*** dreyna_ <dreyna_!> has quit IRC09:52
*** nighty <nighty!> has quit IRC09:52
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto09:57
*** gizero <gizero!~gizero@> has quit IRC10:00
*** TobSnyder <TobSnyder!> has joined #yocto10:03
*** CTtpollard <CTtpollard!> has joined #yocto10:04
*** gizero <gizero!~gizero@> has joined #yocto10:11
*** hamis <hamis!~irfan@> has joined #yocto10:14
devaernstp, I figured out that I needed the u-boot-imx-mfgtool package instead. This however failed during compilation due to some gcc6 related issues. I have fixed those by overriding the git src options ot use a more recent version and compilation/imx image generation seem to work.10:22
devaIt now fails during deployment step with a "missing SPL" file10:22
*** Kakounet <Kakounet!> has joined #yocto10:27
*** nighty <nighty!> has joined #yocto10:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto10:29
*** rajm <rajm!> has quit IRC10:30
*** rajm <rajm!> has joined #yocto10:31
*** _william_ <_william_!> has joined #yocto10:39
*** CoLa|work <CoLa|work!~cordlandw@> has joined #yocto10:49
devaernstp, A u-boot-imx-msgtool_%.bbappend file with the following contents: fixed the issues.10:50
*** caiortp <caiortp!~inatel@> has joined #yocto10:52
*** berton <berton!~berton@> has joined #yocto10:53
*** dv_ <dv_!~quassel@> has quit IRC10:58
*** dv_ <dv_!> has joined #yocto10:58
*** gizero <gizero!~gizero@> has quit IRC10:59
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC11:10
*** arek-m <arek-m!> has joined #yocto11:11
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto11:16
*** ionte <ionte!> has quit IRC11:24
rburtoned2: i thought i had all of your patches but still get fails like  can you check ross/mut?11:25
*** ionte <ionte!> has joined #yocto11:26
JaMaanyone building recipe with hg:// in SRC_URI? here it fails with /usr/bin/env: hg: No such file or directory11:27
JaMa            d.appendVarFlag('do_fetch', 'depends', ' mercurial-native:do_populate_sysroot')11:28
JaMais there11:28
*** redengin_ <redengin_!~redengin@2601:600:9200:a356:58bd:6092:8450:aaee> has quit IRC11:29
*** redengin <redengin!~redengin@2601:600:9200:a356:58bd:6092:8450:aaee> has joined #yocto11:29
*** Kakounet1 <Kakounet1!> has joined #yocto11:36
*** Kakounet <Kakounet!> has quit IRC11:38
*** Kakounet1 is now known as Kakounet11:38
*** gizero <gizero!~gizero@> has joined #yocto11:41
*** istarilucky <istarilucky!~rlucca@> has joined #yocto11:41
*** ftonello <ftonello!~felipe@> has joined #yocto11:47
*** Anticom <Anticom!~quassel@> has joined #yocto11:50
AnticomHi all. Any recommendations on how to do building / minification of web stuff in a yocto build? Most of the tools i know of nowadays use node.js. However there doesn't seem to be a good nodejs-native for yocto (?)11:51
JaMaAnticom: there is nodejs recipe in meta-oe11:51
JaMathere is even separate layer with more node.js versions11:52
AnticomJaMa: Well i need a native package to use it on the build host. I don't want to run nodejs apps on my device11:53
JaMaand nodejs provides native as well11:53
AnticomJaMa: which one? the meta-oe one or the meta-nodejs one?11:53
JaMaprobably both11:54
*** john4 <john4!~john@> has joined #yocto11:55
LetoThe2ndsince krogoth there should be noteworthy support for node in oe, before that, we have meta-nodejs :-)11:56
JaMawe're using nodejs in meta-webos since before Dylan was released :)11:57
LetoThe2ndJaMa: yes, already saw a lot of your infrastructure there. yet i'd rather point to the, erm... more 'mainstream' ressources nowadays :)11:58
LetoThe2ndJaMa: having the npm fetches and devtool support for example seems to be really handy.11:58
JaMayes, I agree that stuff is much better now and closer to upstream11:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:59
LetoThe2ndi'll still have to look into building some NaN based module using the new structure, but so far it seems to be promising.12:00
*** gizero <gizero!~gizero@> has quit IRC12:00
AnticomLetoThe2nd: sadly we're still on jethro. So i guess going for meta-nodejs?12:02
JaMaOE @ ~/meta-openembedded $ grep BBCLASS ./meta-oe/recipes-devtools/nodejs/nodejs_0.12.7.bb12:04
JaMaBBCLASSEXTEND = "native"12:04
JaMain jethro12:04
*** joshuagl <joshuagl!~joshuagl@> has quit IRC12:05
*** voltbit <voltbit!~acid___@> has quit IRC12:05
*** voltbit <voltbit!~acid___@> has joined #yocto12:06
*** voltbit <voltbit!~acid___@> has quit IRC12:08
*** voltbit <voltbit!~acid___@> has joined #yocto12:08
*** Guest27309 <Guest27309!> has joined #yocto12:10
*** voltbit <voltbit!~acid___@> has joined #yocto12:10
*** john4 <john4!~john@> has quit IRC12:12
*** voltbit <voltbit!~acid___@> has joined #yocto12:12
*** Kakounet <Kakounet!> has quit IRC12:13
*** voltbit <voltbit!~acid___@> has joined #yocto12:14
*** AndersD <AndersD!~anders@> has quit IRC12:14
*** AndersD <AndersD!> has joined #yocto12:15
JaMaRP: do you remember reasons for immediate expansion of STAGING_DIR_HOST in allarch.bbclass and how it relates to current recipe-specific-sysroots?12:15
RPJaMa: it used to have MACHINE in it which was no doubt the reason12:16
RPJaMa: since allarch packages shouldn't depend on MACHINE. What problem are you seeing?12:16
*** hamis <hamis!~irfan@> has quit IRC12:17
*** voltbit <voltbit!~acid___@> has quit IRC12:18
JaMaI have recipe which sets PV in python function and STAGING_DIR_HOST="....luna-init/1.0-r12/recipe-sysroot" RECIPE_SYSROOT=".....luna-init/2.0.1-13-r12/recipe-sys|12:18
JaMaand because of allarch it's using STAGING_DIR_HOST value to find the dependencies and fail, because of different version directory12:18
*** voltbit <voltbit!~acid___@> has joined #yocto12:18
RPJaMa: hmm, right :/12:19
RPJaMa: we can likely remove that from allarch.bbclass now12:19
JaMaok, will try that and if it isn't enough I'll create simpler test case for oe-core12:19
*** egavinc <egavinc!> has joined #yocto12:23
RPmarquiz: the perf machines broke again and don't show how they failed, any clues what broke in master?12:26
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC12:28
mdnneohi ... strange question but is there a way I can get a binary build in another package I depend on?12:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto12:29
mdnneoso e.g. like the busybox use case there is a busybox package builds the main package and then I build a around depend on busybox copy the busybox bin to /opt/getty12:31
ed2rburton: can you drop hddimg patchset, please? that should help.12:38
*** igor1 <igor1!~igor@> has joined #yocto12:38
ed2rburton: I'll send v3 today12:38
*** Kakounet <Kakounet!> has joined #yocto12:44
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC12:48
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto12:51
marquizRP: uhh, i hadn't checked today's results, yet, let me see...12:54
*** cornel <cornel!~cornel@> has joined #yocto12:58
Anticomsry, wrong window in focus12:58
cornelis there any advantage in placing PV and maybe PR in the recipe name?12:58
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto12:59
cornelfor me it makes it harder to spot content change when also the PV or PR has changed, because instead of a diff, i just see in gerrit that one file was removed and another added12:59
marquizRP: i really need to fix error reporting of the script so that it will show bitbake output in the backtrace13:04
rburtoned2: ok, thanks13:04
rburtoncornel: pr, definitely not.  git can handle rename detection, so gerrit should be able ot.13:05
*** groleo <groleo!> has quit IRC13:06
*** Kakounet <Kakounet!> has quit IRC13:07
cornelrburton, ok, thank you13:07
rburtoncornel: if gerrit really can't then feel free to put PV in the recipe for your own stuff.  putting it in the filename is just a convenience and idiom from when OE used to contain many of releases of each recipe.13:09
cornelrburton, so its mainly there for historical reason, so to speak?13:09
*** Kakounet <Kakounet!> has joined #yocto13:12
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto13:13
rburtoncornel: its a historical convention that is helpful to easily show what version a recipe is13:14
cornelthank you very much rburton13:14
*** JosePerez <JosePerez!~jgperezc@> has joined #yocto13:16
rburtongreat, selftest is just hanging13:19
*** hamis <hamis!~irfan@> has joined #yocto13:19
*** qt-x <qt-x!~Thunderbi@> has quit IRC13:21
*** hamis_lt_u <hamis_lt_u!~irfan@> has joined #yocto13:28
*** hamis <hamis!~irfan@> has quit IRC13:30
RPmarquiz: I have no idea why its doing that, nothing else with master is afaik :(13:31
RPmarquiz: fixing the script to share that output would help13:31
marquizmust be related to build perf test re-using artefacts13:32
marquizi'm fixing the output problem atm13:32
RPmarquiz: which aretfacts? Just sstate right?13:33
RPmarquiz: it should work but worth exploring...13:33
marquiz(and downloads and cache)13:33
RPJaMa: I tried removing the expansion in allarch locally and it seems to work13:33
*** viengelm <viengelm!viengelm@nat/digia/x-ioopnpowquskfmpo> has quit IRC13:34
RPmarquiz: hm, it breaks after enabling rm_work13:34
marquizRP: i guess must be sstate as test1 build core-image-sato without problems13:34
marquizesdk test does not use rm_work13:35
*** viengelm <viengelm!viengelm@nat/digia/x-iqokfywqtaeppsds> has joined #yocto13:35
RPmarquiz: it doesn't but its broken by then!13:37
*** gizero <gizero!~gizero@> has joined #yocto13:38
RPmarquiz: are the failures for each step the same?13:39
marquizRP: basically yes13:39
RPmarquiz: local test didn't reproduce it :/13:39
marquizRP: i'm running locally, too...13:41
*** gizero <gizero!~gizero@> has quit IRC13:43
*** avalluri <avalluri!avalluri@nat/intel/x-unpthukdjbouuihg> has joined #yocto13:43
marquizRP: you're right that rm_work might actually break it13:44
*** lamego <lamego!~jose@> has joined #yocto13:45
marquizbecause the subsequent tests try to run a preparational build in the same tmpdir13:45
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC13:46
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto13:49
RPmarquiz: right, we need to figure out what the reproducer is...13:49
RPLooking at the numbers, it seems I managed to wipe 2GB of the disk usage, which raises questions about where the remaing 4GB comes from with rss13:50
*** Biliogadafr <Biliogadafr!> has joined #yocto13:50
marquizRP: 4gb is still quite a bit13:51
RPmarquiz: right13:51
marquizRP: i could investigate that, but unfortunately not before monday13:52
RPmarquiz: right, we're going to have to look into it...13:53
*** dmoseley <dmoseley!> has quit IRC13:53
RPmarquiz: getting the perf benchmarks working is first priority13:54
*** istarilucky <istarilucky!~rlucca@> has quit IRC13:55
*** egavinc <egavinc!> has quit IRC13:55
*** istarilucky <istarilucky!~rlucca@> has joined #yocto13:56
*** JPEW <JPEW!cc4da3f4@gateway/web/freenode/ip.> has joined #yocto13:57
*** arek-m <arek-m!> has quit IRC13:58
cdleonardmy NATIVELSBSTRING apparently changed from "Debian-testing" to "Debian-9.0" and all sstate broke. Is this normal?14:02
rburtonsad but true as we can't tell that debian-testing to debian-9 is in fact the same thing14:04
rburtonfeel free to symlink one to the other in the sstate cache14:04
rburtonor, use uninative, which is designed to solve this proble14:04
*** paulg <paulg!> has joined #yocto14:08
cdleonardbut when does it change? Is is from some debian update or a yocto update?14:10
*** zeddii <zeddii!~bruce@> has joined #yocto14:13
rburtonyou've gone from debian testing to debian 914:14
rburtonpresumably that's the sign that debian testing is starting to freeze for release14:14
RPfind */*/recipe-sysroot* -links 1 -type f -print0 | xargs -r0 du -aBM| awk '{sum+=$1} END {print sum}'14:18
RPmarquiz: ^^^ - that says we have 900MB of single link files in a sample workdir I tested against :/14:19
rburtonstale from updates to the master copies?14:20
*** deva <deva!~deva@> has quit IRC14:20
RPrburton: files we have to copy, then fix the paths in14:21
*** sgw_ <sgw_!~sgw_@> has joined #yocto14:22
*** heliocastro is now known as helio|afk14:26
*** falk0n <falk0n!> has joined #yocto14:26
RPand that number is clearly wrong due to rounding14:28
*** Biliogadafr1 <Biliogadafr1!> has joined #yocto14:29
*** toanju <toanju!~toanju@> has quit IRC14:29
*** Biliogadafr <Biliogadafr!> has quit IRC14:29
RPhmm, 2.5GB is the answer14:29
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:30
*** jku <jku!~jku@> has quit IRC14:31
RPand 900MB of that are .la files14:33
* RP waits for rburton to comment14:33
RPah, no 91MB14:33
*** gizero <gizero!~gizero@> has joined #yocto14:33
RPshame, that would have been an easy fix14:33
rburtonRP: NINE HUNDRED14:35
rburtonoh 9114:35
*** gizero <gizero!~gizero@> has quit IRC14:38
*** ptizoom <ptizoom!> has joined #yocto14:39
RPhmm, 1MB each time something depends on libxml2 or python due to the size of the manifest flle alone14:39
ptizoomwhy some packages require virtual/libc-native? how to bypass?14:40
RPptizoom: they shouldn't really, how did you manage to hit that?14:42
ptizoomuhmm, I added meta-debian14:43
*** gizero <gizero!~gizero@> has joined #yocto14:43
RPptizoom: that was probably your mistake. What do you need meta-debian for?14:44
ptizoomRP: meta-debian is joly good I thought they had prepared good embeded distro...14:45
*** avalluri <avalluri!avalluri@nat/intel/x-unpthukdjbouuihg> has quit IRC14:45
RPptizoom: OE provides a perfectly good starting point for an embedded distro. meta-debian has a very specific use case for long term support of old software and you probably don't want it14:47
*** madisox <madisox!> has joined #yocto14:47
RPptizoom: it does some pretty crazy things compared to standard OE14:47
rburtonRP: something happened in master, or the AB is bust: selftest hangs.14:47
*** seezer <seezer!seezer@quassel/developer/seezer> has quit IRC14:47
*** madisox <madisox!> has quit IRC14:48
ptizoomRP: OK, I will drop it out! But for my sake, is there a way other than adding "BBCLASSEXTEND = \"native\"" every where.... to ignore these libc-native dependencies?14:49
*** seezer <seezer!quassel@quassel/developer/seezer> has joined #yocto14:49
RPptizoom: no libc-native dependencies should be there at all and BBCLASSEXTEND isn't how you'd fix that anyway14:50
RPrburton: locally too?14:50
rburtonRP: haven't tried yet14:50
RPrburton: no idea offhand :(14:51
ptizoomRP: this is somewhat requested by openldap-native...14:52
rburtonptizoom: meta-debian is so far removed from oe-core that you'll have more luck asking in a specific channel14:52
ptizoomRP,rbuton: ok thanks anyway.14:53
rburton(our advice is not to use meta-debian because you think its got the software you want.  ie openldap is in meta-oe)14:54
*** AndersD <AndersD!> has quit IRC15:01
*** t0mmy <t0mmy!~tprrt@> has quit IRC15:01
*** Anticom <Anticom!~quassel@> has quit IRC15:04
*** t0mmy <t0mmy!~tprrt@> has joined #yocto15:04
*** rcw <rcw!~rwoolley@> has joined #yocto15:08
*** marka <marka!~masselst@> has joined #yocto15:09
*** t0mmy <t0mmy!~tprrt@> has quit IRC15:09
*** caiortp <caiortp!~inatel@> has quit IRC15:15
*** Crofton <Crofton!~Crofton@> has quit IRC15:20
*** open-nandra <open-nandra!> has quit IRC15:22
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC15:25
*** t0mmy <t0mmy!~tprrt@> has joined #yocto15:25
*** helio|afk is now known as heliocastro15:26
kergothdo_populate_sysroot_setscene: No suitable staging package found15:26
kergothkeep getting these lately, what's the deal?15:26
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto15:27
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC15:27
*** Strike5150 <Strike5150!18de02de@gateway/web/freenode/ip.> has joined #yocto15:28
*** JosePerez1 <JosePerez1!~jgperezc@> has joined #yocto15:28
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto15:28
gizeroRP: I did some more investigation on issues seen yesterday on esdk and the sysinitv/systemd thing. What I see here is that building from scratch (no tmp, no sstate-cache) either the image (core-image-minimal) or the esdk succeeds. Rebuilding the image (preserving tmp and sstate-cache) after configuring for systemd (no backfilling of sysinitv) works as well. On the opposite, after reconfiguration, building15:28
gizerothe esdk fails as reported yesterday (
*** caiortp <caiortp!~inatel@> has joined #yocto15:28
Strike5150Hello,  trying to add x windows to my image, started with inherit core-image.  Added some packages and now trying to add IMAGE_FEATURE x11-sato.  Is that supposed to work?15:28
gizeroAny further test I can volunteer for or should I file on bugzilla?15:29
*** grma <grma!~gruberm@> has quit IRC15:34
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC15:34
*** stephano <stephano!~stephano@> has joined #yocto15:34
*** aehs29 <aehs29!~aehernan@> has joined #yocto15:35
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC15:38
*** sgw_ <sgw_!~sgw_@> has quit IRC15:43
rburtonStrike5150: copy core-image-x11 and you'll have an image that starts x and not much else15:45
Strike5150rburton:  I want to have a core image without x11, and only add x11 on certain machine tyes15:46
RPgizero: bugzilla time. I think I know what is wrong though and may have a patch to test son15:47
RPkergoth: that shouldn't happen :(15:47
Strike5150rburton: x11-sato image feature doesn't seem to add startx.  It seems its dependant on x11/x11-base, or I don't know how to start sato15:48
kergothjust saw hundreds of them before my build started from scratch15:48
marquizRP: the failure seen in build perf test seems to be caused by rm_work15:52
marquizunfortunately i have to call it a day15:52
*** vmeson <vmeson!> has joined #yocto15:53
RPmarquiz: were you able to reproduce?15:53
*** vmesons <vmesons!> has quit IRC15:53
ed2rburton: i pushed fixes to my contrib branch ed/wic/wip15:54
rburtoned2: great15:54
ed2rburton: looking at ross/mut I'd say you didn't remove hddimg patchet from there yet.15:54
RPkergoth: different subject, I remember that we had to complicate the multiprocessing code in the cooker parser due to issues with python multiprocessing. Do you remember what the issue was?15:54
RPkergoth: I'm wondering if we can loop back now and simplify15:55
rburtoned2: no, i'll do that when i pull your bits15:55
kergothIIRC there was a bug in the version of python we were using, but it's been a while. does seem worth revisiting, considering we're on 3 now15:55
kergothit's a bit hard to remember now though :)15:55
Strike5150 packagegroup-core-x11-base : Depends: packagegroup-core-x11-utils but it is not going to be installed15:55
Strike5150When I add the contents of core-image-x11, I get this error15:56
rburtoned2: so ed/wic/wip is everything from you i should be including in mut?15:56
ed2rburton: I removed couple of patches, updated some and added new15:56
Strike5150where does packagegroup-core-x11-utils come from? how can I include it15:56
ed2rburton: yes, it contains everything that should be included in mut, but before that we should remove my hddimg patchset from there.15:57
ed2rburton: if you give me 15 minutes I can do it.15:57
*** ed21 <ed21!~Adium@> has joined #yocto16:00
rburtoned2: by hddimg you mean the 14 patch series "wic should not rely on hddimg creation'?16:01
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC16:01
*** ed2 <ed2!~Adium@> has quit IRC16:02
Strike5150Figured it out, I can simply install it like package using IMAGE_INSTALL.  Why is it not able to automagically pull in the dependancy for those?16:02
ed21rburton: yes, and some more that you cherry-picked from my branch16:02
*** ed21 is now known as ed216:02
ed2rburton: I can prepare branch for you if you want.16:04
*** hamis_lt_u <hamis_lt_u!~irfan@> has quit IRC16:04
kanavinrburton: why do we split python's standard modules into tiny packages?16:04
rburtonkanavin: because someone long ago decided it would be good for small systems to let you install the bits you need and not say all the internet parts if you never use them16:05
kanavinrburton: this is causing a very annoying process of determining which of them any given python software needs in RDEPENDS - build an image, run an image, run the software, fix the failure, repeat a million times16:06
rburtonkanavin: add python3-modules to the image16:07
rburtonthats the metapackage for "everything"16:07
kanavinrburton: is it okay if I add that to ?16:07
rburtonkanavin: for now, sure.16:08
kergothkanavin: the pythondeps script in oe-core will scan a python package to get a list of its deps. recipetool create will use it to prepopulate RDEPENDS.16:09
kergothmanual review is required, however16:09
rburtonkanavin: or, enable the package feed on your build machine and on the target copy packages as you need them.  saves the rebuild loop.16:09
kergothwell, recipetool create will do so if it sees a python buildsystem, that is, i.e. not sure if there's a way to trigger it manually if the project uses something else16:10
kergothgood idea16:10
rburtoni have PACKAGE_FEED_URIS = "http://flashheart.local/poky-master" in my local.conf, and lighttpd on my build machine sharing the deploy as /poky-master/16:10
rburtonobviously you're working on dnf so that won't work so well ;)16:10
rburtonbut you can still scp the packages out of deploy16:10
*** vmeson <vmeson!> has quit IRC16:11
*** sgw_ <sgw_!~sgw_@> has joined #yocto16:13
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto16:14
gizeroRP: I'll be happy to help with testing the patch...16:16
yoctiBug 10982: normal, Undecided, ---, ross.burton, NEW , building eSDK fails after switching from sysinitv to systemd16:16
*** vmeson <vmeson!> has joined #yocto16:16
themikenicholsonQuestion about create_sdk_files - I'm trying to add a _prepend to it from a .bbappend file.  The recipe I'm appending to already inherits a create_sdk_files_prepend from a bbclass in another layer.  I see that my .bbappend file is getting processed when I run bitbake-layers show-appends but when I run bitbake -e imagename I don't see the content of my create_sdk_files_prepend.16:16
themikenicholsonIs there something about that funciton that prevents me from prepending to it from another bbappend file or am I just trying to do something impossible?16:18
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto16:19
*** mdnneo <mdnneo!~umaucher@> has quit IRC16:20
kanavinrburton: kergoth: thanks for the hints, I think I call it a day now :)16:20
rburtongizero: if you change distro features, we really do recommend you delete tmp for this exact reason16:22
*** smiller6 <smiller6!~smiller6@> has joined #yocto16:22
RPkergoth: you'd probably understand how to simplify that code better than I would. Wish I could remember the problem :/16:28
kergothsure, will see about taking a look. i don't remember either offhand, it went through a few versions16:29
*** xulfer <xulfer!> has joined #yocto16:30
*** csanchezdll <csanchezdll!> has left #yocto16:31
gizerorburton: uhmmm... I probably missed the suggestions from the docs. But if failures are to be expected, maybe we'd better advice like the sanity checker does on misconfiguration. Anyway here the background was testing if this migrating from sysinitv to systemd can be considered reliable from a eSDK update perspective. Will move on with my test with your advice in place16:31
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:32
*** ed2 <ed2!~Adium@> has quit IRC16:34
RPrburton, gizero: its actually a grey area now. Before rss, we did have this working, albeit not widely publisied16:34
*** JoiF <JoiF!~jofr@> has quit IRC16:37
*** quandtum <quandtum!~quandtum@> has joined #yocto16:38
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC16:39
sandsmarkso, I'm trying to build an image with among other things qtdeclarative without x11, but the build fails with opkg saying «Cannot satisfy the following dependencies for qtdeclarative: *a bunch of x11 libs*»16:39
sandsmarkI downloaded the .ipkg and looked at the control file manually, and it doesn't list any of those libraries16:40
BaloneyGeek|worksandsmark: HAHA!16:40
sandsmarknor are they in the .bb files16:40
BaloneyGeek|workI just gave up about 6 hours ago16:40
BaloneyGeek|workTrying to do the same thing since Monday16:40
sandsmarkhaha, ok16:40
sandsmarktrying to upgrade an installed device now with the new packages16:41
*** smiller6_ <smiller6_!~smiller6@> has joined #yocto16:41
sandsmark«Depends: libgcc1 (>= 5.3.0), libstdc++6 (>= 5.3.0), qtbase (>= 5.8.0+git0+49dc9aa409), libc6 (>= 2.23)»16:41
*** smiller6_ <smiller6_!~smiller6@> has quit IRC16:41
sandsmarkno x11 there either16:41
BaloneyGeek|workmeta-qt5, 5.8 branch?16:42
sandsmarkgrepped through the entire source/ directory for the libraries, nothing16:42
rburtonsandsmark: if you just remove x11 from your DISTRO_FEATURES then bitbake will literally refuse to build anything touching x1116:43
sandsmarkyeah, I have removed it16:43
sandsmarkand the package is built without x11, the ipk has no references to anything x11, but opkg still complains16:43
RPsandsmark: try greping the Packages files in tmp/deploy/ipk for these x11 libs16:43
BaloneyGeek|workI was trying to do the same thing. DISTRO_FEATURES_remove = "x11 wayland" but qt5declarative still tried to link against libglx-xcb or something similar16:44
*** smiller6 <smiller6!~smiller6@> has quit IRC16:44
sandsmarkaha; cortexa9hf-neon-mx6sl/Packages:Depends: libx11-6 (>= 1.6.3), libxcb-dri2-0 (>= 1.11.1), libxfixes3 (>= 5.0.1), libxcb1 (>= 1.11.1), libx11-xcb1 (>= 1.6.3), libxext6 (>= 1.3.3), libc6 (>= 2.23), libglapi0 (>= 11.1.1), libdrm2 (>= 2.4.67), libxxf86vm1 (>= 1.1.4), libxau6 (>= 1.0.8), libexpat1 (>= 2.1.0), libxdamage1 (>= 1.1.4), libxdmcp6 (>= 1.1.2), libxcb-glx0 (>= 1.11.1)16:44
*** jairglez <jairglez!~jairdeje@> has joined #yocto16:44
sandsmarkfrom grep libx11-xcb1 {*/,}Packages16:45
*** gizero <gizero!~gizero@> has quit IRC16:45
*** rajm <rajm!> has quit IRC16:45
RPsandsmark: a bit more context should show you which package it is and then you can work it backwards from there16:47
RPsandsmark: I'm going to guess at a precompiled graphics driver or something...16:48
sandsmarkyeah, I found it, it seems like there's an outdated qtbase from one of the fsl repos that ruins things16:48
*** lemagoup <lemagoup!~lemagoup@> has quit IRC16:48
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto16:49
*** gizero <gizero!~gizero@> has joined #yocto16:51
sandsmarkthey try to be clever with the gl stuff because the imx6sl doesn't have a gpu, but I don't want gl16:51
*** dmoseley <dmoseley!> has joined #yocto16:54
*** zeenix <zeenix!~zeenix@> has quit IRC16:55
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC16:55
*** Snert <Snert!~snert_@> has quit IRC16:57
*** Snert <Snert!~snert_@> has joined #yocto16:58
*** Tenhi <Tenhi!> has quit IRC16:58
RPgizero: I have a patch you could test16:58
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC16:59
RPgizero: it depends on (or drop the workdir param)16:59
sandsmarkRP: thanks, btw17:02
sandsmarkI feel dumb for not looking in the Packages file...17:02
RPsandsmark: I've been there before ;-)17:02
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined #yocto17:03
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC17:05
*** phatina <phatina!> has quit IRC17:05
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto17:06
*** bavery_fn <bavery_fn!bavery@nat/intel/x-hmvdpoljdhlzwfka> has quit IRC17:09
*** toscalix <toscalix!~toscalix@> has quit IRC17:10
*** Circuitsoft <Circuitsoft!4b92a52b@gateway/web/freenode/ip.> has joined #yocto17:13
CircuitsoftHello - I'm trying to add more files to the linux-firmware package via a .bbappend. Do I want to write "do_unpack_append(){}" to unpack the downloaded RPM File, or is there a different function to implement?17:14
CircuitsoftCurrently, there is no do_unpack, as the SRC_URI for the original package is a git repository.17:14
*** phatina <phatina!> has joined #yocto17:14
kergothCircuitsoft: not sure what makes you think a git repo doesn't unpack.. unpack means take the sources from DL_DIR to WORKDIR, via whatever appropriate mechanism. a git repo is cloned.17:15
kergothwithout do_unpack, you'd have no sources to use to build at all17:15
kergothnot ideal naming, perhaps, but that's how it is17:16
rburtonCircuitsoft: put a .rpm in SRC_URI and set extract=1 and bitbake will unpack it for you17:16
*** phatina <phatina!> has quit IRC17:16
gizeroRP: going to give it a try, thanks!17:17
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto17:18
Circuitsoftrburton: I'm doing SRC_URI += "/uri/of/rpm" where it already contains "/uri/of/git/repo.git"17:20
CircuitsoftBut, I'll try that and see what happens. Thanks.17:20
kergoththat'll work fine.17:21
kergothbitbake can unpack any number of sources, there's no limitation17:21
*** graphiqs <graphiqs!> has quit IRC17:21
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC17:23
*** gizero <gizero!~gizero@> has quit IRC17:29
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC17:30
*** gizero <gizero!~gizero@> has joined #yocto17:31
*** ptizoom <ptizoom!> has quit IRC17:34
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC17:35
*** Kakounet <Kakounet!> has quit IRC17:38
themikenicholsonIs it not possible to have multiple instances of  xyz_prepend () {} in the same recipe?17:44
RPthemikenicholson: perfectly fine17:44
kergothprepend/append are operations, not part of the name. they're cumulative17:45
*** fl0v0 <fl0v0!> has quit IRC17:49
*** TobSnyder <TobSnyder!> has quit IRC17:50
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto17:52
themikenicholson*facepalm* another recipe in another layer was inheriting the class... The recipe i was attempting to .bbapend to was not getting pulled in at all17:55
*** bavery_fn <bavery_fn!~bavery@> has joined #yocto17:56
*** ed2 <ed2!~Adium@> has joined #yocto17:59
themikenicholsonI wasn't seeing the effects of the _prepend because it was in the wrong place.  Sorry for wasting time.18:04
*** diego_r <diego_r!> has quit IRC18:14
*** CTtpollard <CTtpollard!> has quit IRC18:15
marquizRP: came back for a brief moment18:16
marquizRP: yes, i was able to reproduce18:16
marquizjust INHERIT += "rm_work" and bitbake core-image-sato18:16
*** t0mmy <t0mmy!~tprrt@> has quit IRC18:19
*** ftonello <ftonello!~felipe@> has quit IRC18:22
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC18:24
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto18:26
*** mckoan is now known as mckoan|away18:29
marquizRP: i just fired git bisect run18:32
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto18:35
sandsmarkbah, still no go :(18:39
*** t0mmy <t0mmy!> has joined #yocto18:39
*** sameo <sameo!~samuel@> has joined #yocto18:41
sandsmarkthere I fixed it18:43
sandsmarkremoved the fsl ipk repo18:43
*** rcw <rcw!~rwoolley@> has quit IRC18:43
*** tlab <tlab!~tlab@> has joined #yocto18:49
*** JaMa <JaMa!~martin@> has quit IRC18:52
miceopedei'm using   BB_FETCH_PREMIRRORONLY = "1" to fetch from my local mirror only. there's a warning about uninative. do i need this? what is this for?18:52
CircuitsoftIs there something like depexp that shows packages instead of recipes?18:58
CircuitsoftI have something pulling in linux-firmware, which conflicts with kernel-firmware.18:58
CircuitsoftI have a few specific linux-firmware-<something> packages pulled in, but none of them conflict with kernel-firmware.18:59
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto19:02
*** paulg <paulg!> has quit IRC19:03
skrawnHow are the root filesystem user account and permissions set up? It used to be that my images would always contain a root account with no password and that account had super user permissions. Now I have to add "empty-root-password" to allow for that account to be created without a password but my root account no longer has su permissions19:07
CircuitsoftIs there a way to prevent a particular package from being installed? I have a conflict I'm trying to track down.19:08
skrawnCircuitsoft: in your local.conf file, you can add IMAGE_INSTALL_remove += "<package_name>"19:09
CircuitsoftOkay, so I get my conflict when I add linux-firmware-cxgb to my initramfs. In linux-firmware_git.bbappend, I have FILES_${PN}-cxgb = "".19:16
*** sameo <sameo!~samuel@> has quit IRC19:16
*** bavery_fn <bavery_fn!~bavery@> has quit IRC19:19
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC19:19
*** bavery_fn <bavery_fn!~bavery@> has joined #yocto19:23
*** falk0n <falk0n!> has quit IRC19:23
*** paulg <paulg!> has joined #yocto19:24
miceopedemy yocto build is refetching and rebuilding linux-yocto-rt_4.8 every single time i build, regardless of sstate cache. any idea how i can debug this? my bbappend file looks like this:
*** istarilucky <istarilucky!~rlucca@> has quit IRC19:32
*** dreyna_ <dreyna_!> has joined #yocto19:37
kergothmiceopede: see bitbake-whatchanged and bitbake -S printdiff19:38
markamiceopede: did you try to use bitbake-diffsigs to see what changed in the siginfo files?19:38
miceopede@marka i did not. let me try19:38
markakergoth's method may be easier, I haven't tried that19:39
miceopededo i need to specify that after my image? (core-image-rt)19:39
kergothbitbake-diffsigs is a standalone command, used to diff two different siginfo/sigdata files from your stamps_dir or sstate_dir19:39
miceopedeokay, let me take a look.19:40
kergothbitbake -S printdiff does a diffsigs for you. it locates the sstate which is closest to what we want, then diffs that against the current state of things19:41
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC19:43
*** joseppc <joseppc!> has joined #yocto19:51
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto19:51
*** ed2 <ed2!~Adium@> has quit IRC19:51
*** HyP3r <HyP3r!> has joined #yocto19:55
*** vmesons <vmesons!> has joined #yocto19:56
*** vmesons <vmesons!> has joined #yocto19:57
*** vmeson <vmeson!> has quit IRC19:58
*** caiortp <caiortp!~inatel@> has quit IRC19:58
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto20:03
*** ed2 <ed2!~Adium@> has joined #yocto20:07
*** ed2 <ed2!~Adium@> has quit IRC20:12
*** igor1 <igor1!~igor@> has quit IRC20:15
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC20:15
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto20:16
*** ed2 <ed2!~Adium@> has joined #yocto20:17
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC20:18
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto20:19
*** ed2 <ed2!~Adium@> has quit IRC20:30
*** ntl <ntl!> has quit IRC20:30
*** berton <berton!~berton@> has quit IRC20:32
*** ed2 <ed2!~Adium@> has joined #yocto20:33
*** ntl <ntl!> has joined #yocto20:47
*** marka <marka!~masselst@> has quit IRC20:48
ed2rburton: I've just sent v3 of my patchset:
*** skrawn <skrawn!419d2dc2@gateway/web/freenode/ip.> has quit IRC20:53
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC20:58
*** skrawn <skrawn!419d2dc2@gateway/web/freenode/ip.> has joined #yocto21:01
*** ed2 <ed2!~Adium@> has quit IRC21:02
*** skrawn <skrawn!419d2dc2@gateway/web/freenode/ip.> has quit IRC21:08
*** ed2 <ed2!~Adium@> has joined #yocto21:10
*** voltbit <voltbit!~acid___@> has quit IRC21:12
*** phoo1234567 <phoo1234567!> has joined #yocto21:14
*** ed2 <ed2!~Adium@> has quit IRC21:14
*** ed2 <ed2!Adium@nat/intel/x-ckzktzxxhjjecyfi> has joined #yocto21:15
*** ed2 <ed2!Adium@nat/intel/x-ckzktzxxhjjecyfi> has quit IRC21:21
*** skrawn <skrawn!419d2dc2@gateway/web/freenode/ip.> has joined #yocto21:24
*** _Ben <_Ben!81612d46@gateway/web/freenode/ip.> has quit IRC21:26
*** sdonohue <sdonohue!~quassel@> has joined #yocto21:28
*** skrawn <skrawn!419d2dc2@gateway/web/freenode/ip.> has quit IRC21:33
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC21:33
*** sgw_ <sgw_!~sgw_@> has quit IRC21:45
*** davis <davis!> has quit IRC21:47
*** paulg <paulg!> has quit IRC21:49
*** sgw_ <sgw_!~sgw_@> has joined #yocto21:56
*** morphis <morphis!> has quit IRC21:57
*** pohly <pohly!> has quit IRC21:59
*** sdonohue <sdonohue!~quassel@> has quit IRC22:02
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto22:05
*** agust <agust!> has quit IRC22:25
*** Circuitsoft <Circuitsoft!4b92a52b@gateway/web/freenode/ip.> has quit IRC22:32
*** paulg <paulg!> has joined #yocto22:34
*** JosePerez <JosePerez!~jgperezc@> has quit IRC22:35
*** lamego <lamego!~jose@> has quit IRC22:52
*** paulg <paulg!> has quit IRC22:58
*** JPEW <JPEW!cc4da3f4@gateway/web/freenode/ip.> has quit IRC22:59
*** bfederau <bfederau!> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC23:01
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC23:10
*** paulg <paulg!> has joined #yocto23:13
kergothhmm,  so privsep isn't working with sshd on x32 builds, but works fine otherwise23:15
*** gizero <gizero!~gizero@> has quit IRC23:17
*** quandtum <quandtum!~quandtum@> has quit IRC23:21
*** paulg <paulg!> has quit IRC23:23
* rburton is secretly confident that his new plan to solve a long standing autotools pain point is going to actually work this time23:24
rburtonjust fired an overnight build to test23:25
kergothgood luck23:25
rburtonits almost out of native land so that's a good start ;)23:28
rburtonnow bed23:28
rburtongood weekend all23:28
*** linulin <linulin!> has quit IRC23:29
*** linulin <linulin!> has joined #yocto23:29
*** bavery_fn <bavery_fn!~bavery@> has quit IRC23:44
*** Snert__ <Snert__!> has joined #yocto23:47
*** Snert_ <Snert_!> has quit IRC23:48
-YoctoAutoBuilder- build #1018 of nightly-rpm is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #1019 of nightly-arm-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1] Build details are at
-YoctoAutoBuilder- build #1004 of nightly-deb is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
*** seebs <seebs!~seebs@> has quit IRC23:52
*** seebs <seebs!> has joined #yocto23:58
-YoctoAutoBuilder- build #399 of nightly-no-x11 is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at

Generated by 2.11.0 by Marius Gedminas - find it at!