Monday, 2014-07-14

*** JDuke128 <JDuke128!~textual@> has joined #yocto00:17
*** sgw_ <sgw_!> has quit IRC00:48
nerdboyanybody know how to AC_CHECK_LIBS or similar for static libm?00:50
*** sgw_ <sgw_!> has joined #yocto01:01
*** danielki <danielki!> has quit IRC01:22
*** JDuke128 <JDuke128!~textual@> has quit IRC03:25
*** madisox <madisox!~madisox@> has quit IRC04:02
*** warthog9 <warthog9!~warthog9@> has quit IRC05:37
*** g1zer0 <g1zer0!> has joined #yocto05:56
*** danielki <danielki!> has joined #yocto06:09
*** warthog9 <warthog9!~warthog9@> has joined #yocto06:17
*** JDuke128 <JDuke128!~textual@> has joined #yocto06:22
*** [Sno] <[Sno]!~Sno]> has quit IRC06:31
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC06:35
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto06:35
*** VoiceShen <VoiceShen!~VoiceShen@> has joined #yocto06:41
VoiceShenHi All,06:41
VoiceShenI try to add gstreamer also include plugins to my image, however it is not included06:41
VoiceShenI do like this:06:42
VoiceShen+    gstreamer1.0 \06:42
VoiceShen+    gstreamer1.0-plugins-base \06:42
VoiceShen+    gstreamer1.0-plugins-good \06:42
VoiceShen+    gstreamer1.0-plugins-bad \06:42
VoiceShen+    gstreamer1.0-plugins-ugly \06:42
VoiceShenwhen I use gst-inspect to query which plugins is added06:42
VoiceShenonly coreelements is added06:43
VoiceShenany idea why good/bad/ugly plugins not added06:43
*** ant_work <ant_work!> has joined #yocto06:55
*** sjolley <sjolley!~sjolley@> has quit IRC07:06
*** sjolley <sjolley!~sjolley@> has joined #yocto07:07
*** mckoan|away is now known as mckoan07:19
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto07:19
mckoangood morning07:19
*** florian_kc is now known as florian07:19
mckoanVoiceShen: did you add them using IMAGE_INSTALL_append ?07:25
VoiceShenOh, no, I will try it07:26
VoiceShenmckoan: I put it into IMAGE_INSTALL section07:29
VoiceShenhowever, it is not included in image file07:30
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto07:46
*** fusman <fusman!~fahad@> has joined #yocto07:48
*** [Sno] <[Sno]!~Sno]> has joined #yocto08:03
erboVoiceShen: If I remember correctly you'll have to add the different -plugins-good-* to the image.08:08
erboI don't think e.g. gstreamer1.0-plugins-good pulls in the different packages that are built08:09
*** bluelightning <bluelightning!~paul@> has joined #yocto08:10
*** bluelightning <bluelightning!~paul@> has quit IRC08:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:10
*** BCMM <BCMM!> has joined #yocto08:10
*** JimBaxter <JimBaxter!> has joined #yocto08:10
*** BCMM <BCMM!> has quit IRC08:10
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:10
bluelightningmorning all08:14
Letothe2ndUGT? ;)08:15
bluelightningLetothe2nd: indeed, in which case good morning :)08:16
VoiceShenerbo: thanks, it works.08:16
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC08:28
*** VoiceShen <VoiceShen!~VoiceShen@> has left #yocto08:48
*** DarkKnight_ <DarkKnight_!> has joined #yocto08:58
*** DarkKnight <DarkKnight!> has quit IRC08:58
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has joined #yocto09:02
*** dl9pf_ <dl9pf_!> has quit IRC09:02
*** belen <belen!Adium@nat/intel/x-cqxjmwqiyithuusm> has joined #yocto09:11
*** Squix <Squix!> has quit IRC09:13
*** awafaa <awafaa!sid716@gateway/web/> has quit IRC09:20
*** jjardon_ <jjardon_!sid723@gateway/web/> has quit IRC09:21
*** diego_r <diego_r!> has joined #yocto09:21
*** jjardon_ <jjardon_!sid723@gateway/web/> has joined #yocto09:22
*** awafaa_ <awafaa_!sid716@gateway/web/> has joined #yocto09:23
*** ajtag <ajtag!> has quit IRC09:29
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC09:30
*** RagBal <RagBal!> has quit IRC09:30
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto09:31
*** diego__ <diego__!> has joined #yocto09:31
*** diego_r <diego_r!> has quit IRC09:31
*** diego__ is now known as diego_r09:31
*** dl9pf_ <dl9pf_!> has joined #yocto09:31
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC09:31
*** seezer <seezer!quassel@quassel/developer/seezer> has quit IRC09:31
*** seezer_ <seezer_!quassel@quassel/developer/seezer> has joined #yocto09:31
*** RagBal <RagBal!> has joined #yocto09:34
*** ajtag <ajtag!> has joined #yocto09:35
*** danielki <danielki!> has quit IRC10:01
*** RagBal <RagBal!> has quit IRC10:08
*** danielki <danielki!> has joined #yocto10:10
*** RagBal <RagBal!> has joined #yocto10:10
*** AlexVaduva <AlexVaduva!c1ca1642@gateway/web/freenode/ip.> has quit IRC10:21
*** jjardon_ is now known as jjardon10:23
*** e8johan <e8johan!> has joined #yocto10:52
*** danielki <danielki!> has quit IRC10:54
*** awafaa_ is now known as awafaa11:02
*** danielki <danielki!> has joined #yocto11:09
*** sameo <sameo!~samuel@> has joined #yocto11:31
*** hsychla <hsychla!> has joined #yocto11:33
*** hsychla_ <hsychla_!> has joined #yocto11:33
*** demonimin_ <demonimin_!~demonimin@unaffiliated/demonimin> has joined #yocto11:37
hsychlaHi all. We have a bbclass (that is inherited by several recipes) that copies config files to the correct location etc. Some files are not present in all recipes so we install them conditionally. Now, what happens if I add such a conditional file to the CONFFILES variable (a file in /etc/sysctl.d for example)  and  a package does not have this file?  Can I add files to the CONFFILES variable conditionally?11:37
*** mario-go` is now known as mario-goulart11:37
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC11:39
*** wrd <wrd!~Thunderbi@> has joined #yocto11:45
*** danielki <danielki!> has quit IRC11:50
*** danielki <danielki!> has joined #yocto11:51
hsychlaand: can I add a conditional dependency in my class depending of the presence of a certain file?12:05
rburtonhsychla: does CONFFILES error out if the files don't exist?12:10
hsychlawell, that was my question actually. I did not get around to testing yet12:12
rburtontest that :)12:13
rburtonFILES at least is lax about files not actually existing12:14
bluelightningCONFFILES pipes through to the package manager, so I guess it depends on whether that cares or not12:16
*** ddalex <ddalex!~ddalex@> has joined #yocto12:17
rburtonbluelightning: so i expect rpm will moan, but not sure what opkg will do12:17
rburtonwe should probably filter the conffiles list to the set of files that actually exist before passing it to the package manager12:18
*** sameo <sameo!~samuel@> has quit IRC12:20
*** challinan <challinan!> has joined #yocto12:25
*** alimon <alimon!~alimon@> has joined #yocto12:31
*** diego_r <diego_r!> has quit IRC12:57
wrdis there a good way to see whats going on when one calls bitbake?13:01
rburtondepends what you mean by "what's going on"13:02
rburtonbitbake foo |cat will show you a more verbose log13:02
wrdI want to extract the compile arguments how u-boot is built in a certain environment, but I fail to figure out where the variables are actually defined13:02
rburtonbitbake -e [recipe] will show you the variables used, and where they come from13:03
*** alimon <alimon!~alimon@> has quit IRC13:12
*** joeythesaint <joeythesaint!~joe@> has joined #yocto13:12
*** dmoseley <dmoseley!> has joined #yocto13:25
*** kscherer <kscherer!~kscherer@> has joined #yocto13:30
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has joined #yocto13:42
belenwrd: Toaster should also be able to give you a fair idea.
*** ant_work <ant_work!> has quit IRC13:48
bluelightningwrd: have a look at run.* (and log.*) in the temp directory for the workdir for the u-boot recipe13:53
bluelightningwrd: if you're not sure where the workdir is you can find that using: bitbake -e u-boot | grep ^WORKDIR=13:53
*** AlexVaduva <AlexVaduva!c1ca1642@gateway/web/freenode/ip.> has joined #yocto14:03
*** sjolley <sjolley!~sjolley@> has quit IRC14:11
wrdthank you belen bluelightning. I've fixed my issues with other means.14:14
*** blloyd <blloyd!> has joined #yocto14:15
blloydquestion: is my /media/realroot solution one that could be considered for backporting to Daisy?  If so, I don't mind doing the integration and submitting a patch.14:18
[Sno]is there a bitbake cli option which shows some information about a recipe instead of building it?14:22
blloydbitbake -e14:23
[Sno]so "bitbake -e perl" would show VERSION=5.14.3 for dora?14:24
*** dvhart <dvhart!dvhart@nat/intel/x-bcogrkspwwtecfca> has joined #yocto14:24
blloydwill show all variable settings for when the script runs instead of running it.  Great for figuring out why things aren't behaving as expected.  As well as identifying the version information when the "wrong" one being run.14:24
blloydI suggest bitbake -e perl > env.perl14:25
blloydit generates a LOT of output.  Then you can look through that file and get an idea of just what it has.14:25
*** kroon <kroon!> has quit IRC14:25
[Sno]blloyd: I want to add a new backend for a scanner for updates and a generater for cpan modules (
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has quit IRC14:26
*** captainigloo <captainigloo!~captainig@2001:41d0:8:114b::1> has quit IRC14:26
*** captainigloo <captainigloo!~captainig@2001:41d0:8:114b::1> has joined #yocto14:27
blloydyou probably will want to use the libraries bitbake uses to do a backend, and that is more than I have done with that tool to date.14:27
*** kroon <kroon!> has joined #yocto14:28
[Sno]hmm, I should take a look, yes14:28
[Sno]but the -e (I have a do_rootfs running, so I cannot check) seems suitable14:29
blloydbut are you discussing a package manager to manage end packages to a distribution?  What is the base format for the files it's packages?14:29
[Sno]blloyd: for yocto it's what bitbake does (ipk, deb, rpm, ...)14:30
[Sno]for pkgsrc it'll spits out Makefiles to generate *.pkg's14:30
[Sno]blloyd: the utility generates "*.bb" files (or should - that's the goal of Yocto/Bitbake backend)14:30
*** dvhart <dvhart!dvhart@nat/intel/x-bcogrkspwwtecfca> has quit IRC14:33
*** sjolley <sjolley!~sjolley@> has joined #yocto14:36
*** _dv_ is now known as dv_14:37
*** msm` <msm`!> has joined #yocto14:48
*** msm <msm!> has quit IRC14:51
*** alimon <alimon!> has joined #yocto14:56
*** dvhart <dvhart!~dvhart@> has joined #yocto14:57
*** AlexG <AlexG!c0c69724@gateway/web/freenode/ip.> has joined #yocto15:00
*** dvhart|2 <dvhart|2!dvhart@nat/intel/x-iqogthppsgvonypf> has joined #yocto15:00
*** g1zer0 <g1zer0!> has quit IRC15:00
*** dvhart <dvhart!~dvhart@> has quit IRC15:00
*** dvhart|2 is now known as dvhart15:00
*** AlexG_ <AlexG_!c0c69724@gateway/web/freenode/ip.> has joined #yocto15:08
*** AlexG <AlexG!c0c69724@gateway/web/freenode/ip.> has quit IRC15:11
*** fray <fray!> has quit IRC15:15
blloydand here I thought bitbake's backends were to generate distribution packages (ipk, rpm, etc) from bitbake's compilations.15:15
*** wrd <wrd!~Thunderbi@> has left #yocto15:16
*** fray <fray!> has joined #yocto15:17
*** mkeeter <mkeeter!~mkeeter@> has joined #yocto15:21
*** munch <munch!> has joined #yocto15:32
*** mcweigel <mcweigel!> has joined #yocto15:35
*** danielki <danielki!> has quit IRC15:52
*** AlexG_ <AlexG_!c0c69724@gateway/web/freenode/ip.> has quit IRC15:58
*** ant_home <ant_home!> has joined #yocto16:00
*** mckoan is now known as mckoan|away16:01
*** [Sno] <[Sno]!~Sno]> has quit IRC16:02
*** cbzx <cbzx!> has joined #yocto16:23
*** nitink <nitink!nitink@nat/intel/x-lbqghbiapsrwdpsd> has joined #yocto16:30
*** maxtothemax <maxtothemax!maxtothema@nat/intel/x-vnpzvxcwnedcxobf> has joined #yocto16:35
*** mkeeter <mkeeter!~mkeeter@> has quit IRC16:44
*** mkeeter <mkeeter!~mkeeter@> has joined #yocto16:44
*** JimBaxter <JimBaxter!> has quit IRC16:47
*** cbzx <cbzx!> has quit IRC16:53
*** fray <fray!> has quit IRC16:55
*** fray <fray!> has joined #yocto16:56
*** danielki <danielki!> has joined #yocto16:57
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:01
kergothRP: still checking sanity, but I think we might need to add SITEINFO_ENDIANNESS, SITEINFO_BITS, and SIZEOF_POINTER to the default BB_HASHBASE_WHITELIST. without doing so, any change to BUILD_ARCH will flow through and cause target signatures to change, meaning target sstates aren't reused when the build host changes (e.g. 32 to 64 bit). BUILD_ARCH itself isn't an issue since only its unexpanded form ends up in the signatures, but it's in the17:08
kergoth filenames, and the aforementioned 3 variables should all only ever change when BUILD_ARCH does, so it shouldn't harm anything to exclude them. thoughts?17:08
kergothin our test case, our target kernel sstates aren't reused between 32 and 64 bit centos hosts today17:08
kergothstill making sure adding them doesn't cause reuse where reuse shouldn't occur, though17:08
kergothobviously this wasn't an issue before the change went in to cause target signatures to be affected by changes to their native dependencies17:09
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto17:17
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto17:17
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC17:19
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto17:20
*** hyei <hyei!> has joined #yocto17:21
*** mkeeter <mkeeter!~mkeeter@> has quit IRC17:26
*** mkeeter <mkeeter!~mkeeter@> has joined #yocto17:26
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC17:29
*** LCyrin <LCyrin!~LCyrin@2607:fb90:2703:84cf:30a7:9a74:7fd9:acdf> has joined #yocto17:30
*** belen <belen!Adium@nat/intel/x-cqxjmwqiyithuusm> has quit IRC17:30
*** seebs <seebs!> has quit IRC17:32
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:33
*** seebs <seebs!> has joined #yocto17:34
*** rajesh <rajesh!~rajesh@nylug/member/rajesh> has joined #yocto17:46
*** abelloni <abelloni!> has quit IRC17:57
*** JDuke128 <JDuke128!~textual@> has quit IRC18:15
*** Crofton <Crofton!> has quit IRC18:37
*** Crofton|work <Crofton|work!> has quit IRC18:38
*** zecke <zecke!> has joined #yocto18:50
*** Crofton <Crofton!> has joined #yocto18:50
zeckeOn dora I have a severe issue. Packages are being re-built. This is a serious issue in terms of GPL compliance. What if somebody has the old binary but I only have the new sources?18:50
*** Crofton|work <Crofton|work!> has joined #yocto18:51
khemzecke: you need sources corresponding to old binary18:53
khemfor compliance18:53
khemincluding any patches and build rules18:53
*** cbzx <cbzx!> has joined #yocto18:53
zeckekhem: yes, but why is something like systemd being re-built?18:54
zeckethe recipe has not been changed, the content has not been changed, includes have not been changed, local.conf has not been changed18:54
kergothits dependencies were changed, most likely18:55
*** rajesh <rajesh!~rajesh@nylug/member/rajesh> has quit IRC18:55
zeckei probably need to run diffsigs of all packages before the build. :}18:55
zeckeor is that being put in buildstats?18:55
kergothbitbake-whatchanged -v <target>18:55
kergothor bitbake -S printdiff <target>18:55
zecke_before_ the build I assume? :)18:56
zeckeokay and printdiff is not part of dora. :)18:56
*** Crofton <Crofton!> has quit IRC18:57
kergothah, yes, that's a newer bitbake feature. bitbake-whatchanged should work if you have the STAMPS_DIR from the old build (e.g kept TMPDIR around, or saved STAMPS_DIR)18:57
*** Crofton|work <Crofton|work!> has quit IRC18:57
khemzecke: but if nothing changes in systemd then rebuilding should be fine isnt it ?18:58
khemfrom complaince POV18:58
*** belen <belen!> has joined #yocto19:01
zeckekergoth: stamps were "rebuilt". It is just the rm_work target that wants to re-run19:02
kergothtechnically the binaries wouldn't be bitwise identical, but the sources would be the same, so you'd still be in compliance due to having hte sources from the previous build, afaik19:02
zeckekhem: having two .ipk files with the same name but slightly different content is a nightmare. :}19:02
kergoththe ipk files hsouldn't have the same name, at least if you're using the PR server which you should be19:03
kergothsince PR would be auto-incremented as appropriate when the checksums change19:03
zeckekergoth: I do use the PR server. :)19:03
zeckeNOTE: Started PRServer with DBfile: /home/ortelius/poky-201310/build.sysmocom-odu/cache/prserv.sqlite3, IP:, PORT: 50415, PID: 2304019:03
zeckebut I assume.. "there were bugs in dora and I should upgrade". :)19:04
kergoththere are always bugs in any release, the only question is weighing the migration pain vs the benefit :)19:05
zeckethe pain of building edison on modern GCC was getting high enough to migrate19:05
zeckebut these kind of rebuilds freak me out. I will disable rm_work and see what happens or maybe it is the archiver I use. :}19:06
*** Crofton <Crofton!> has joined #yocto19:08
*** Crofton|work <Crofton|work!> has joined #yocto19:10
zeckenow bluez is being re-built because I build gdb. :)19:16
*** [Sno] <[Sno]!~Sno]> has joined #yocto19:17
kergothWhat would be ideal would be to track not just inputs, but also outputs. E.g. if we rebuild a task due to vars changing, but the output of the task isn't any different, then don't ripple the change out to the tasks depending on that task19:18
kergothbut it'd be decidedly  non-trivial19:18
rburtonkergoth: eg strip stuff like timestamps from binaries and md5sum them?19:19
zeckekergoth: I would be happy if the build would break and bitbake tells me why it decided to rebuild the package19:19
kergothpossibly, yeah. but we might have to track input and output paths for all tasks. we only do that for setscene covered tasks today19:20
kergothzecke: run whatchanged before your build, if it outputs anything, abort your automated build :)19:20
rburtonkergoth: redhat have a project to do reproducable builds, where they have flags and whatnot to ensure the same sources built twice produce bit-identical binaries19:20
kergothrburton: huh, that sounds interesting19:20
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto19:20
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC19:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:20
*** danielki <danielki!> has quit IRC19:27
rburtonkergoth: good old debian has a wiki
khemtimestamps are not easy to remove, especially if its opensource there is no pattern to using time stamps some use it in version string some use in seeding random seeds for g++19:33
khemand so on19:33
khemI tried it in vain last time even though most of software was proprietary19:33
blloydare there any good wikis or documents for how to manage updates in the field?  Both inside a single yocto release and allowing to upgrade to new images built with a newer yocto base?19:33
rburtonblloyd: sadly not as far as i'm aware, feel free to write one ;)19:36
khemblloyd: there is no standard update mechanism in OE/Yocto you can use Online package management like rpm/zypper dpkg/apt or opkg or use some initramfs mechanism to do image updates19:36
khemzypper is no longer supported19:37
rburtonblloyd: ideally you want some file system swap for atomic and safe updates, but everyone tends to write their own.  i've been meaning to look at ostree for this.19:38
rburtonchromeos does this, i wonder if their tooling is open19:38
kergothyeah i've been meaning to look at ostree for that too19:39
kergothpackage-level upgrades are so risky, and full reflashing is a pain19:39
zeckemaybe with systemd one can avoid this unionfs thing as well19:41
rburtonkergoth: they're still using a poky fork for the bootstrap so there's good motivation on both sides to work on it19:43
khemfor CI/CD its a good thing I suppose19:45
zeckeOT: I have a 3.2.0er vendor crap kernel and on execve... argv[3] with "a.b.c:20000" appears to be re-written to "a.b.c\020000". it doesn't appear to be libc6. I'm not sure if the application is playing with argv/prctl either19:49
zeckecrazy app. :}19:50
* zecke kicks gpsd19:51
JaMazecke: you can also use to dump all sstate signatures at interesting points and then compare the files when something unexpectedly re-builds19:58
zeckeJaMa: thanks19:58
kergothi need to play with that script more19:59
khemzecke: I would rule out kernel here20:00
khemzecke: is argv parsed using some str* functions20:01
JaMakergoth: it's just other way to create stripped copy of old STAMPS_DIR20:02
* kergoth nods20:02
kergothwe have our jenkins builds capture SSTATE_DIR for later analysis20:02
JaMaand create convenience list.M which strips MACHINE names so you can compare multiple machines20:02
JaMawe're doing the same, but with this script20:03
*** belen <belen!> has quit IRC20:03
JaMaand then we're using it also when debugging when sstate reuse is low on some developer machine20:03
JaMayou just download .tgz from last official jenkins build which populates sstate-mirror and then compare list.M files20:03
zeckekhem: yes, it is gps2udp that does strsep on argv20:06
kergothnot directly related, but we ship sstate to the customer, and we didn't want to distribute the intermediate artifacts, only the ones needed to build, so we're now incorporating a SSTATE_DIR trimming process to pare it down. the downside is what gets trimmed is what's needed to diagnose sstate reuse problems with bitbake -S printdiff, but it's worth it for release builds. The trim process is at
kergoth The key is building, wiping tmp, and building from sstate in order to get an STAMPS_DIR which only references the needed bits, not the intermediate functions like do_install20:07
* kergoth wanders off to get food20:07
khemsome have asked if bitbake can error out if a rebuild is requested secondly if a build is requested and its not found in sstate20:08
khemso basically no compile should happen20:09
khemand bitbake should error out of sstate is not found20:09
kergoththat could be interesting. setscene-only for covered tasks20:09
khemmy be a switch and not default20:10
kergothopposite of —no-setscene :)20:10
kergoth(which is a really handy argument at times)20:11
kergothFYI, after merging, we're now getting 100% reuse of target and 0% reuse of native/cross between 32 and 64 bit build environments, which wasn't the case previously (we weren't getting target reuse across 32/64 bit hosts. e.g. linux-yocto was rebuilt)20:11
*** cbzx <cbzx!> has quit IRC20:14
khemhmmm I think they all should be just TARGET vars20:15
khemzecke: is your option parser treating ':' special ?20:24
ant_homeJaMa: starnge error yu have spotted20:28
ant_homeERROR: Recipe linux-yocto-tiny-kexecboot is trying to change PV from '3.10.43+gitAUTOINC+199943142f_aa677a2d02' to '3.14.5+gitAUTOINC+602be954ac_41d5fe27dc'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir.20:28
ant_homeJaMa: mixing up 3.10 and 3.14?20:29
*** e8johan <e8johan!> has quit IRC20:39
*** tomz <tomz!tomz@nat/intel/x-ibwkhtojuxxsobmy> has quit IRC20:39
darknighteJaMa: you still maintaing the qt5 layer?20:43
*** sgw_ <sgw_!> has quit IRC20:44
darknighteJaMa: I guess it would be more correct to say the meta-qt layer.20:49
darknighteotavio: JaMa: I am trying to run the Qt5 cinematic experience on my target, but the QPA (for xcb) isn't showing up in the rootfs.20:50
darknighteotavio: JaMa: any tips?20:50
*** sgw_ <sgw_!> has joined #yocto20:58
*** ecdhe <ecdhe!> has quit IRC20:59
*** ecdhe <ecdhe!> has joined #yocto21:02
khemdarknighte: your question is not clear, is the xcb plugin thats failing ?21:03
khemto load or something21:04
darknightekhem: sorry, the plugin isn't found.21:04
darknighteI am not very familier with Qt5, but from googling around, it appears that the QPA is missing form the rootfs.21:04
darknightekhem: do you know what the name of the xcb QPA is so that I can double check?21:05
khemyou probably are missing some dependencies for libqxcb.so21:05
khemsee above21:06
* darknighte nods21:06
khemif that .so is there then do a ldd on that and see what all it needs21:06
darknightekhem: k.  confirmed.  that file is missing from the rootfs.21:06
khemand make sure those libs are there too21:06
khemoh then thats the first thing to do to include it in rfs21:07
* darknighte nods again21:07
darknightekhem: not sure how though.  not seeing a recipe specificly for the platform plugin.21:08
khemsee if your PACKAGECONFIG is right fot qtbase21:08
darknighteI specified xcb via my local.conf as follows:21:09
darknightePACKAGECONFIG_append_pn-cinematicexperience = " xcb "21:09
khemif you had 'x11' in DISTRO_FEATURES' it should have been pulled in21:10
khemthat construct is wrong too21:10
khemyou need to enable it for qtbase21:10
darknighteI noticed the conditional in the recipe on X11 and have that turned on.21:11
khemPACKAGECONFIG_append_pn-qtbase = " xcb "21:11
khemcheck the build and see if log.do_configure has xcb enabled21:11
darknighteahhh, I 've been looking at it for cinematic... standby21:12
khemqtbase is the beginnin of all qt evil that follows21:12
khemmost od the times qtbase is configured wrongly and whole platform is compiled differently21:13
khemand damn qtbase takes hours to compile21:13
* khem heads to costco21:13
darknighteheh.  I noticed the length of time on the compile for qt.21:13
darknightekhem: fwiw, xcb appears to be enabled correctly in qt-base21:14
*** scot <scot!~scot@> has quit IRC21:15
*** scot <scot!~scot@> has joined #yocto21:17
*** phantom <phantom!> has joined #yocto21:26
darknightekhem: for reference:
* darknighte goes to check package splits21:26
*** phantom is now known as phantoxeD21:26
*** vquicksilver <vquicksilver!> has joined #yocto21:32
*** vquicksilver <vquicksilver!~wolf@gentoo/contributor/vquicksilver> has joined #yocto21:32
kroondarknighte, qtbase-plugins21:34
kroondarknighte, i think thats the package with the actual qpa plugins21:35
*** sjolley <sjolley!~sjolley@> has quit IRC21:35
*** sjolley <sjolley!~sjolley@> has joined #yocto21:35
*** e8johan <e8johan!> has joined #yocto21:35
*** scot <scot!~scot@> has quit IRC21:37
kroonpersonally, i would like to have qtbase/qtdeclarative even more finer grained split up in packages21:39
*** scot <scot!~scot@> has joined #yocto21:40
kroonin my quest for having the rootfs as small as possible21:41
kroonmight not be worth it though, in these days of gigabyte discs ..21:41
*** zecke <zecke!> has quit IRC21:41
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC21:42
*** tomz <tomz!tomz@nat/intel/x-upwqmxdfuvmqxfwu> has joined #yocto21:42
*** sjolley <sjolley!~sjolley@> has quit IRC21:44
*** sjolley <sjolley!sjolley@nat/intel/x-qsksmnrcvifftpor> has joined #yocto21:46
darknightekroon: thx for the tip.  after getting the file name I managed to figure that part out.  now I have the plugins installed.21:47
*** vquicksilver <vquicksilver!~wolf@gentoo/contributor/vquicksilver> has quit IRC21:52
*** JDuke128 <JDuke128!~textual@> has joined #yocto21:53
*** melonipoika <melonipoika!> has joined #yocto21:56
*** challinan <challinan!> has quit IRC21:58
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC22:03
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto22:03
*** melonipoika <melonipoika!> has quit IRC22:07
*** LCyrin <LCyrin!~LCyrin@2607:fb90:2703:84cf:30a7:9a74:7fd9:acdf> has quit IRC22:07
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC22:09
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto22:09
*** mkeeter <mkeeter!~mkeeter@> has quit IRC22:10
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC22:17
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto22:17
*** challinan <challinan!> has joined #yocto22:20
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC22:22
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto22:22
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC22:24
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto22:25
*** sameo <sameo!~samuel@> has joined #yocto22:30
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC22:30
*** mkeeter <mkeeter!~mkeeter@2601:6:b80:5a:90b0:1fb6:4761:90f4> has joined #yocto22:30
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto22:30
*** e8johan <e8johan!> has quit IRC22:37
*** sjolley <sjolley!sjolley@nat/intel/x-qsksmnrcvifftpor> has quit IRC22:56
*** challinan <challinan!> has quit IRC23:18
*** sjolley <sjolley!~sjolley@> has joined #yocto23:24
*** ant_home <ant_home!> has quit IRC23:35
*** mkeeter <mkeeter!~mkeeter@2601:6:b80:5a:90b0:1fb6:4761:90f4> has quit IRC23:36
*** challinan <challinan!> has joined #yocto23:36
*** mkeeter <mkeeter!~mkeeter@2601:6:b80:5a:90b0:1fb6:4761:90f4> has joined #yocto23:36
*** munch <munch!> has quit IRC23:41
*** alimon <alimon!> has quit IRC23:49
*** sameo <sameo!~samuel@> has quit IRC23:51

Generated by 2.11.0 by Marius Gedminas - find it at!