Wednesday, 2014-08-13

*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC00:08
*** dvhart <dvhart!dvhart@nat/intel/x-clcjbazukzozdgum> has quit IRC00:10
*** Nitin <Nitin!nakamble@nat/intel/x-dfiyyyjztjqwffyn> has joined #yocto00:11
*** sjolley <sjolley!sjolley@nat/intel/x-ecffzokfbusqndnk> has quit IRC00:12
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto00:13
*** staylor <staylor!~staylor@S0106602ad0901f12.cg.shawcable.net> has joined #yocto00:17
maxtothemaxdoes anyone know if a recipe for OpenJDK exists?00:19
maxtothemaxI can't find one00:19
maxtothemaxah, found it00:26
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC00:32
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto00:32
khemmaxtothemax: yes it does. Look at meta-java00:48
khemand when you need to look for layers or recipes go to http://layers.openembedded.org/layerindex/branch/master/layers/00:49
khemand search00:49
*** slips_ <slips_!~slips@154.43.164.82.customer.cdi.no> has quit IRC00:54
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC00:57
manuel_i don’t really understand the relationship between meta-toolchain-* recipes and -c populate_sdk on my image01:00
manuel_will meta-toolchain-* package my whole sysroot? because i seem to be missing includes01:00
manuel_or is there a way to have meta-toolchain-qt5 (in my case) package the sysroot too01:00
*** sjolley <sjolley!sjolley@nat/intel/x-xwgzeshqvfvgkhbp> has joined #yocto01:01
*** zarul <zarul!~zarul@ubuntu/member/zarul> has quit IRC01:01
manuel_oh i think i need to add my packages to TOOLCHAIN_HOST_TASK01:05
*** EddyLaiTW <EddyLaiTW!~edylai@61-231-110-191.dynamic.hinet.net> has joined #yocto01:06
maxtothemaxyeah, I found it01:12
*** zarul <zarul!~zarul@ubuntu/member/zarul> has joined #yocto01:15
*** staylor <staylor!~staylor@S0106602ad0901f12.cg.shawcable.net> has quit IRC01:21
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto01:22
fray_manuel_  'meta-toolchain' provides a very basic toolchain environment, but very few (if any) libraries beyond the minimum..01:22
fray_you can think of this as a very targeted SDK with a limited purpose..01:22
fray_bitbake <image> -c populate_sdk on the otherhand is a "generic" SDK that matches your root filesystem01:22
fray_So, if you want to provide your developers with access to all of the development components for the rootfs, use the -c populate_sdk..01:23
fray_if you want to provide your developers with a limited set of APIs, use the meta-toolchaiN (or equivalent) and add only the items they should have access to01:23
*** Squix <Squix!~Squix__@p052.net059084091.tokai.or.jp> has joined #yocto01:26
*** EddyLaiTW <EddyLaiTW!~edylai@61-231-110-191.dynamic.hinet.net> has quit IRC01:28
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC01:37
*** rokka <rokka!~rokka@109.204.235.59> has joined #yocto01:42
*** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC01:43
*** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto01:44
nerdboyfray__: you know developers who know their required dependencies?  where do these people work?01:47
fray_system developers should have a good understanding of what they want to export to the application developers..01:48
fray_for those who don't know what to export, I'd recomment the full filesystem..01:48
nerdboypopulate_sdk ftw01:49
fray_for those who have planned only a limited set of APIs, then the manual meta-toolchain approach is for them01:49
fray_there is a reason I implemented populate_sdk 3 years ago..  since that is how most people work01:49
* nerdboy finds out about new deps when the nightly breaks01:49
nerdboythen i get "oh yeah, forgot about that..."01:49
fray_in the automotive world.. those guys are -very- strict about APIs..01:50
fray_so they want the target toolchain approach, not rootfs approach01:50
nerdboyseriously, the flexibility is there for limited-to-full image01:50
fray_yes01:51
nerdboymostly outside of "strict" i would use populate_sdk01:51
fray_yes, that is what I recommend for peopel to use01:51
nerdboyyou automotive/aerospace/launch guys and your "strict"01:52
* nerdboy was the launch range IV&V guy01:53
nerdboywoulda been nice to see good use of OE on some of their embedded/infra stuff01:54
fray_the other place I've seen strict is on certain consumer devices -- tablets and settop boxes where they allow applications..01:54
fray_but that isn't nearly as common as the MILS/Aero/Automotive01:54
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto01:54
nerdboytiming system, range infrastructure, comm01:54
nerdboyeven the new range safety standard doesn't include the updated software piece01:55
nerdboynasa lost funding for the third volume i guess01:55
nerdboyso it's still do178b/spark if you really want strict as in correctness01:56
nerdboyor wail on it with your own formal verification stuff01:57
fray_:)01:59
manuel_fray_: the populate-sdk doesn’t provide the nativesdk packages, can i just add those to my image?02:06
manuel_i’m trying to bbappend RDEPENDS_ to my meta-toolchain-qt5 but that seems to not work02:06
manuel_although i just bitbake -c cleaned02:06
fray_those can be added to the variable mentioned before..02:07
fray_TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host packagegroup-cross-canadian-${MACHINE}"02:07
fray_RDEPENDS won't do it (AFAIK)..02:07
manuel_ok, i looked inside the packagegroup to see how it works under the hood and it seems to use the RDEPENDS02:07
manuel_ok02:07
fray_there are two key variables in the SDK..  TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK.. (the later is automatically filled out when using the -c populate_sdk)02:07
manuel_that makes sense though because the RDEPENDS wa in the package group02:08
fray_ya, packagegroups are brought in my the explicit list (either PACKAGE_INSTALL or TOOLCHAIN_TARGET_TASK) and then rdepend to bring in additional stuff..02:08
fray_to add single packages, you can just add (_append) to the TOOLCHAIN_TARGET/HOST_TASK and it will be specific to the system or recipe02:08
manuel_cool, i’ll add that stuff to TOOLCHAIN_TARGET_TASK, try it out, then make a proper packagegroup for my needs02:08
fray_TOOLCHAIN_TARGET_TASK is things that are -target- based that go into the sysroot..  TOOLCHAIN_HOST_TASK are things installed in the host side.. i.e. cross compiler or similar tooling02:09
manuel_other related question though, if i add the nativesdk packages to my image.bb, will it get put into the toolchain when populate_sdk ?02:09
fray_(nativesdk packages are TOOLCHAIN_HOST_TASK)02:09
fray_your image.bb would need a TOOLCHAIN_HOST_TASK_append = "..."02:09
fray_that is perfectly legal to have in an image and it'll just be ignored if building a rootfs02:10
manuel_cool02:10
manuel_the meta-toolchain is basically just a recipe missing all the image stuff02:10
manuel_i’m still thinking of them a separate mechanism but they’re not02:11
fray_ya, they are the same mechanism, just different ways to express it02:11
manuel_thank you for writing that btw02:11
* fray_ notes meta-toolchain existed long before he became involved in YP..02:12
fray_it just wasn't how I wanted to work with the SDK.. thus the change02:12
manuel_for contributing to that02:12
manuel_:}02:12
fray_yup.. different usage patterns.. OE/YP is great at have a million ways to do something.. problem is making sure those million ways are known02:12
manuel_source is easy to read02:13
manuel_it’s been surprisingly easy to get some complicated stuff done02:13
manuel_but the whole “build stuff that will take hours, fix a var, build stuff that will take hours, fix a var” cycle is tedious02:13
fray_this is where you convince your boss that a faster machine will pay for itself in developer time..02:14
fray_I'm lucky enough to have such a boss..02:14
fray_developer pay/hour * time saved by faster hardware < cost of new hardware02:15
manuel_what are you building on02:15
fray_offically, dual 8-core Xeon (w/ HT) and 128 GB of ram and RAID SATA disks..02:15
manuel_as that is actually what i requested today02:15
fray_unofficially, I have a 'target' which I've turned into a builder.. dual 12 core Xeon (w/ HT) and 64 GB of ram, and RAID SATA disks..02:16
manuel_32 cores thus02:16
fray_the later is about 50% faster (on master builds) then the 8-core..02:16
manuel_target meaning (new to the lingo)02:16
fray_both around about the same GHz range.. 2.4-2.6 if I remember correctly..02:16
fray_target, the system was purchased to be a target of the oe-core building, not as a builder..02:16
fray_(it's a high-end Intel Xeon system used in data centers for network routing and monitoring... I found a 'better' purpose as a builder)02:17
fray_but since it's not an official developer system, if another person in the company needs it as a target system I have to send it to them02:17
fray_Only word of caution.. there is a kernel bug when you get over about 32 (w/ HT) virtual cores..  and buildstats doesn't work right all the time..02:18
manuel_what does a target do? just sit and run tests once a build has been created?02:18
fray_there is a DMA buffer that fills up in the kernel that reports "out of resources" and causes the buildstats module to crash02:18
fray_we have a variety of targets.. they're used for development (bootloader, kernel, and userspace), as well as regression testing and such..02:18
manuel_gotya02:19
fray_this one was originally assigned to me for kernel and userspace development.. but I finished that work a month or so ago.. and nobody else has requested it.. so I installed CentOS and turned it into a builder... :)02:19
fray_it's -really- fast with 24/48 cores02:19
manuel_that sounds tempting02:19
manuel_nice, the TOOLCHAIN_TARGET_TASK stuff worked02:20
fray_we have some actual developer machines that are comparable (Dell rack mount systems).. but they're "shared" machines.. any developer is allowed to access them..02:20
fray_we have a few large core machines dedicated to toolchain development as well..02:20
fray_all depends on the workload.. for system development cores, RAM and GHz all matter..02:20
manuel_who is we btw?02:20
fray_I work for Wind River02:20
manuel_cool02:20
fray_for kernel developers the GHz matter a lot less (in my experience) but you still want lots of cores..02:21
fray_for application developers you likely want faster CPUs and less cores.. (not always)02:21
fray_for 'test' systems (systems running tests) large cores really aren't important.. as they are usually directing remote systems to do things02:21
manuel_a few cores wouldn’t hurt our application build machine02:23
manuel_i just sent out a request for some > 24 cores machine02:24
manuel_thank you again02:24
manuel_i’m off to bed02:24
fray_ya.. the 12 core Xeons are expensive.. but they really do hel02:24
fray_ave a good evening!02:24
fray_(BTW on my 'target' I can do a full core-image-sato style build in less then 2 hours)02:25
manuel_that’s enticing02:27
khemI have haswell based box Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 16G DDR3 and my core-image-sato takes < 100 mins02:35
khemso fray_ something is wrong with your big honking machines02:35
khemDell XPS 8700 from costco under 1000 bucks gets the job done02:36
khem:)02:41
*** Nitin1 <Nitin1!~nakamble@192.55.55.37> has joined #yocto02:46
*** Nitin <Nitin!nakamble@nat/intel/x-dfiyyyjztjqwffyn> has quit IRC02:49
*** EddyLaiTW <EddyLaiTW!~edylai@61-231-110-191.dynamic.hinet.net> has joined #yocto02:53
* nerdboy relaxes to shark week on discovery channel...02:58
fray_khem, I haven't timed it in a while..02:58
fray_and I was including the populate_sdk time as well, which takes a while longer02:59
*** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto03:00
*** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC03:04
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto03:08
*** alexhairyman <alexhairyman!~alexhairy@c-174-52-148-159.hsd1.ut.comcast.net> has quit IRC03:13
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC03:19
*** manuel_ <manuel_!~manuel_@p4FDAC4A7.dip0.t-ipconnect.de> has quit IRC03:28
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC04:02
*** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has quit IRC04:17
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto04:19
*** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has joined #yocto04:19
*** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has left #yocto04:21
*** dvhart <dvhart!~dvhart@134.134.139.76> has joined #yocto04:21
*** armpit2 <armpit2!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has joined #yocto04:25
*** armpit2 <armpit2!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has quit IRC04:28
*** akuster <akuster!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has joined #yocto04:31
*** akuster <akuster!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has quit IRC04:32
*** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has joined #yocto04:55
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC05:05
*** EddyLaiTW <EddyLaiTW!~edylai@61-231-110-191.dynamic.hinet.net> has quit IRC05:05
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto05:07
*** Nitin1 <Nitin1!~nakamble@192.55.55.37> has quit IRC05:12
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC05:20
*** Daemon404 <Daemon404!~who_knows@cpc21-newt31-2-0-cust123.newt.cable.virginm.net> has joined #yocto05:21
*** fray__ <fray__!U2FsdGVkX1@gate.crashing.org> has quit IRC05:23
*** tasslehoff <tasslehoff!~Tasslehof@ti0260a430-1102.bb.online.no> has joined #yocto05:24
*** fray <fray!U2FsdGVkX1@gate.crashing.org> has joined #yocto05:25
*** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has joined #yocto05:38
*** windchester <windchester!cb6a8671@gateway/web/freenode/ip.203.106.134.113> has joined #yocto05:41
*** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto05:52
*** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has joined #yocto05:54
*** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC06:02
*** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto06:13
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto06:17
*** agust <agust!~agust@p4FDE71BA.dip0.t-ipconnect.de> has joined #yocto06:17
*** vmeson <vmeson!~quassel@128.224.252.2> has quit IRC06:28
*** vmeson <vmeson!~quassel@128.224.252.2> has joined #yocto06:28
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC06:37
*** stiandre <stiandre!~stiandre@109.247.13.242> has joined #yocto06:50
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-zfebbyaethkynhog> has joined #yocto06:55
*** jbrianceau_away is now known as jbrianceau06:55
*** kroon <kroon!~kroon@193.15.174.198> has joined #yocto07:00
*** diego_r <diego_r!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has joined #yocto07:04
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:09
*** ant_work <ant_work!~ant__@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto07:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:23
* mranostay taps mic07:23
*** EddyLaiTW <EddyLaiTW!~eddylai@61-231-110-191.dynamic.hinet.net> has joined #yocto07:23
bluelightningmorning all07:26
*** florian_kc is now known as florian07:27
mranostaybluelightning: how blue is the lightning this morning?07:33
bluelightningmranostay: it's sunny out, so not all that much :)07:34
mranostaybluelightning: where are you again?07:34
mranostayUK?07:34
* LetoThe2nd certainly can't confirm neither blue nor lightning nor sunny.07:35
LetoThe2ndjust *rain*07:35
ndecwell, if that helps you... it's raining in Nice, France ;-(07:35
mranostayndec: i like to annoy you french people by saying Nice in english :)07:35
ndechehe...07:36
bluelightningmranostay: yes, London07:36
LetoThe2ndndec: funny, cousin of mine just sent me a postcard from nice07:36
*** ddom <ddom!~ddom@p4FFD8005.dip0.t-ipconnect.de> has joined #yocto07:37
ndecLetoThe2nd: I bet it was not raining on the postcard..07:37
LetoThe2ndndec: you're guessing right07:37
*** roric <roric!~roric@83.140.117.51> has joined #yocto07:37
mranostayyou have to cover your mail before dropping in the box07:37
mranostaybut what is rain really? even portland isn't that rainly :)07:38
mranostay*rainy07:38
*** bryan__ <bryan__!3df6bac6@gateway/web/freenode/ip.61.246.186.198> has quit IRC07:42
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto07:42
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC07:47
*** belen <belen!~Adium@192.198.151.43> has joined #yocto07:50
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto07:52
*** belen <belen!~Adium@192.198.151.43> has quit IRC08:00
*** belen <belen!~Adium@192.198.151.44> has joined #yocto08:00
*** diego_ <diego_!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has joined #yocto08:03
*** diego_r <diego_r!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has quit IRC08:03
*** diego_ is now known as diego_r08:03
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC08:04
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto08:05
*** dvhart <dvhart!~dvhart@134.134.139.76> has quit IRC08:07
*** diego_r <diego_r!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has quit IRC08:10
*** diego_r <diego_r!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has joined #yocto08:10
*** manuel_ <manuel_!~manuel_@p4FDAC4A7.dip0.t-ipconnect.de> has joined #yocto08:16
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC08:16
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto08:17
*** Vincent_DIEHCO <Vincent_DIEHCO!58bade28@gateway/web/freenode/ip.88.186.222.40> has joined #yocto08:18
Vincent_DIEHCOHello, I am using bitbake to customize my rootfs (the whole distribution was initialy provided by EUKREA). I don't where to search good packages to have PULSEAUDIO completely installed. I have no pulse directory or bin in the new rootfs (already customised with cronie, logrotate, gstream, tzdata). This is same problem as in the mailing list : https://lists.yoctoproject.org/pipermail/yocto/2013-September/016119.html Should I rea08:23
*** manuel_ <manuel_!~manuel_@p4FDAC4A7.dip0.t-ipconnect.de> has joined #yocto08:25
*** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has joined #yocto08:25
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC08:29
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto08:30
*** joseppc <joseppc!~Josep@sestofw01.enea.se> has joined #yocto08:33
Vincent_DIEHCOI have also more basic question, any chance to have help ?08:33
EddyLaiTWjust ask, someone will come and help you..08:34
lpappVincent_DIEHCO: do you have some package manager on your rootfs?08:35
lpappVincent_DIEHCO: btw, your post was truncated here: Should I rea...08:36
Vincent_DIEHCOlpapp : Should I reactivate the thread  to know the issue ?08:37
Vincent_DIEHCOlpapp : I think I have not package manager in my rootfs08:38
*** ddom <ddom!~ddom@p4FFD8005.dip0.t-ipconnect.de> has quit IRC08:38
*** sameo <sameo!~samuel@192.55.55.37> has joined #yocto08:38
lpappVincent_DIEHCO: so what does bitbake -e | grep ^DISTRO_FEATURES say?08:39
*** ddom <ddom!~ddom@p4FFAB15F.dip0.t-ipconnect.de> has joined #yocto08:41
Vincent_DIEHCOlpapp : DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm libc-libm-big libc-locales libc-locale-code08:42
Vincent_DIEHCOlpapp : libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc libc-posix-wchar-io pulseaudio sysvinit"08:42
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC08:44
Vincent_DIEHCOlpapp : I only add "pulseaudio" package in my recipe08:44
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto08:45
*** windchester <windchester!cb6a8671@gateway/web/freenode/ip.203.106.134.113> has quit IRC08:47
*** AndersD <AndersD!~anders@c83-252-255-124.bredband.comhem.se> has joined #yocto08:51
Vincent_DIEHCOSomething I do not understand in my recipe : I have "alsa-utils-aplay" instead of only "alsa-utils" in my mind (same think with "gst-plugins-base-volume" and "gst-plugins-base" I added). So for a package as "pulseaudio" how to know if there are "dependancies" to explicit ? or the ones optionals ?08:58
*** windchester <windchester!cb6a8671@gateway/web/freenode/ip.203.106.134.113> has joined #yocto09:00
*** manuel_ <manuel_!~manuel_@p4FDAC4A7.dip0.t-ipconnect.de> has quit IRC09:08
*** Squix <Squix!~Squix__@p052.net059084091.tokai.or.jp> has quit IRC09:09
*** kroon <kroon!~kroon@193.15.174.198> has quit IRC09:09
*** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has quit IRC09:26
Vincent_DIEHCOlpapp: It seems there was already "pulseaudio" in DISTRO_FEATURES list before adding pulseaudio in my recipe.09:26
*** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto09:27
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:29
*** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has joined #yocto09:39
[Sno]I build my image with DISTRO_LIBC_FEATURES = "... libc-locales libc-locale-code ..." and ENABLE_BINARY_LOCALE_GENERATION=109:41
[Sno]I find several libc/localedata/de_DE* below eglibc-locale and some *.po files etc.09:44
[Sno]however - I do not find any of them below tmp/sysroots/ nor on final image09:44
[Sno]what do I have to specify to add locales to my generated image?09:44
*** belen <belen!~Adium@192.198.151.44> has quit IRC09:48
ndec[Sno]: have you checked this: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_LINGUAS09:49
*** belen <belen!~Adium@192.198.151.43> has joined #yocto09:51
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto09:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:52
[Sno]ndec: is there a way to install "all"?09:53
[Sno]I understood IMAGE_LINGUAS that it restricts to named ones09:53
ndeci don't think you can request 'all'09:55
lpapp[Sno]: based on image.bbclass, no.09:55
lpapp(but it would probably be an easy patch to extend it with some python skill)09:56
[Sno]can I somehow force utf8?09:56
[Sno]lpapp: I check that after current sprint (put an item on backlog ^^)09:56
lpapp[Sno]: GLIBC_GENERATE_LOCALES?09:57
lpappfrom the local.conf sample: #GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8"09:58
lpapp#IMAGE_LINGUAS ?= "en-gb"09:58
[Sno]lpapp: GLIBC_GENERATE_LOCALES looks really be a filter - but I give it a try, thanks (will take some time to bitbake the image)09:59
*** EddyLaiTW <EddyLaiTW!~eddylai@61-231-110-191.dynamic.hinet.net> has quit IRC10:00
*** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has quit IRC10:00
*** maxin <maxin!~majo@sestofw01.enea.se> has quit IRC10:00
*** ajtag <ajtag!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has quit IRC10:00
*** mario-goulart <mario-goulart!~user@email.parenteses.org> has quit IRC10:00
*** sullical <sullical!~sullical@134.134.139.76> has quit IRC10:00
*** DarkKnight <DarkKnight!~quassel@HSI-KBW-095-208-008-143.hsi5.kabel-badenwuerttemberg.de> has quit IRC10:00
lpappit is strange that it is not documented though in the YRM.10:00
[Sno]likely they welcome patches :D10:00
lpapp[Sno]: yeah, I am reporting it, btw, you can supply "all" to that one.10:00
[Sno]cool, thanks10:01
lpapp[Sno]: https://bugzilla.yoctoproject.org/show_bug.cgi?id=662910:06
yoctiBug 6629: normal, Undecided, ---, scott.m.rifenbark, NEW , Document GLIBC_GENERATE_LOCALES10:06
*** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has joined #yocto10:07
*** maxin <maxin!~majo@sestofw01.enea.se> has joined #yocto10:07
*** ajtag <ajtag!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has joined #yocto10:07
*** mario-goulart <mario-goulart!~user@email.parenteses.org> has joined #yocto10:07
*** sullical <sullical!~sullical@134.134.139.76> has joined #yocto10:07
*** DarkKnight <DarkKnight!~quassel@HSI-KBW-095-208-008-143.hsi5.kabel-badenwuerttemberg.de> has joined #yocto10:07
[Sno]lpapp: from python code of IMAGE_LINGUAS it probably accepts "*" :)10:11
[Sno]checking that >:-)10:11
lpapp[Sno]: I wonder how you thought that...10:15
lpappRDEPENDS accepts wildcard, you mean?10:17
[Sno]lpapp: simply add IMAGE_LINGUAS="*" to local.conf - the image.bbclass uses locale-base-%s split(getvar(IMAGE_LINGUAS))10:18
lpappyeah, I am not asking about that part, I can read python code OK :)10:19
[Sno]OK :)10:19
ivanstojanovichello :)10:19
lpappI thought RDEPENDS does not accept wildcard, but I am probably wrong then.10:19
ivanstojanovicDoes anyone know if there are somewhere qt-gstreamer recipes available? I couldn't find it :(10:19
ivanstojanovicfor gstreamer 1.0 if possible10:19
[Sno]lpapp: there're some eg. en-gb* ipk's - but maybe I understand something wrong here10:22
*** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has quit IRC10:23
*** maxin <maxin!~majo@sestofw01.enea.se> has quit IRC10:23
*** ajtag <ajtag!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has quit IRC10:23
*** mario-goulart <mario-goulart!~user@email.parenteses.org> has quit IRC10:23
*** sullical <sullical!~sullical@134.134.139.76> has quit IRC10:23
*** DarkKnight <DarkKnight!~quassel@HSI-KBW-095-208-008-143.hsi5.kabel-badenwuerttemberg.de> has quit IRC10:23
lpappivanstojanovic: hmm, close, but not cugar, I guess. Can you hack it yourself together?10:25
lpappcigar*10:25
*** windchester <windchester!cb6a8671@gateway/web/freenode/ip.203.106.134.113> has quit IRC10:30
*** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has joined #yocto10:30
*** maxin <maxin!~majo@sestofw01.enea.se> has joined #yocto10:30
*** ajtag <ajtag!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has joined #yocto10:30
*** mario-goulart <mario-goulart!~user@email.parenteses.org> has joined #yocto10:30
*** sullical <sullical!~sullical@134.134.139.76> has joined #yocto10:30
*** DarkKnight <DarkKnight!~quassel@HSI-KBW-095-208-008-143.hsi5.kabel-badenwuerttemberg.de> has joined #yocto10:30
*** belen <belen!~Adium@192.198.151.43> has quit IRC10:32
[Sno]lpapp: you're right - no package matching locale-base-* :)10:34
*** belen <belen!~Adium@192.198.151.44> has joined #yocto10:35
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC10:37
*** soderstrom <soderstrom!~soderstro@81.216.59.226> has quit IRC10:40
*** kroon <kroon!~kroon@fw.mikrodidakt.se> has joined #yocto10:46
*** pev <pev!~pev@2.31.92.235> has joined #yocto10:48
*** belen <belen!~Adium@192.198.151.44> has quit IRC10:58
*** belen <belen!~Adium@192.198.151.44> has joined #yocto10:58
lpapp[Sno]: I think it would be nice to have "all" like for the other variable. Not that I would use it on real embedded, but it can be OK for more powerful embedded.11:02
*** belen <belen!~Adium@192.198.151.44> has quit IRC11:17
*** belen <belen!~Adium@192.198.151.43> has joined #yocto11:19
*** AndersD <AndersD!~anders@c83-252-255-124.bredband.comhem.se> has quit IRC11:31
*** manuel_ <manuel_!~manuel_@pD9FDCCDD.dip0.t-ipconnect.de> has joined #yocto11:39
Vincent_DIEHCOHello, why the yocto Packages Report System (see http://packages.yoctoproject.org/) does not show result for "gst-plugins-good-wavparse"  although this package is recognized in a bitbake recipe ? I am still looking for installing pulseaudio completely, I don't know how to have pulse or pulseaudio directory / bin in the rootfs.11:52
*** roric <roric!~roric@83.140.117.51> has quit IRC11:57
lpappVincent_DIEHCO: have you checked if you have any package manager on the board?11:58
lpappOr you would like to generate pulse as part of the rootfs only?11:58
*** manuel_ <manuel_!~manuel_@pD9FDCCDD.dip0.t-ipconnect.de> has joined #yocto11:59
lpappVincent_DIEHCO: you can check the package manager e.g. with bitbake -e | grep ^PACKAGE_CLASSES12:00
lpappyou can also look for package-management in IMAGE_FEATURES12:02
Vincent_DIEHCOlpapp : result is PACKAGE_CLASSES="package_ipk" I used to build rootfs when I add a functionnality.12:02
lpappVincent_DIEHCO: bitbake -e | grep ^IMAGES_FEATURE | grep "package-management" -> is that also there?12:04
lpappVincent_DIEHCO: have you checked whether the pulseaudio package was built?12:04
Vincent_DIEHCOIMAGE_FEATURES="${EXTRA_IMAGE_FEATURES}" vincent@electronic:~/oe_dir3/setup-scripts$ echo ${EXTRA_IMAGE_FEATURES}  vincent@electronic:~/oe_dir3/setup-scripts$12:04
*** roric <roric!~roric@83.140.117.51> has joined #yocto12:06
Vincent_DIEHCOlpapp : I have some pulseaudio directories in my bitbake directory ./build/tmp-defaultsetup-eglibc-eglibc/... I don't know how to check in the rootfs.12:10
lpappCheck ./build/tmp/work/foo/pulseaudio12:11
bluelightningto find out what packages are produced by a recipe, the easiest thing is to look under packages-split under the workdir for the recipe12:11
bluelightningif you're not sure where the workdir is you can find out by running bitbake -e recipename | grep ^WORKDIR=12:12
lpappis there any bugreport to finally have an option for searching? bitbake -e recipename | grep ^WORKDIR= => bitbake -s WORKDIR?12:15
lpappI had the same issue more than a year ago, too :-)12:15
lpappbitbake --search stuff12:15
Vincent_DIEHCObitbake -e pulseaudio | grep ^WORKDIR WORKDIR="/home/vincent/oe_dir3/setup-scripts/build/tmp-defaultsetup-eglibc-eglibc/work/armv5te-oe-linux-gnueabi/pulseaudio/3.0-r0" Does it mean pulseaudio is built ?12:19
bluelightninglpapp: it's something that's pretty much already captured as part of kergoth's "bb" external tool; how we can integrate that properly has still not been determined12:19
bluelightningVincent_DIEHCO: not necessarily, no; but if that directory does exist then it likely has been12:20
lpappVincent_DIEHCO: well, find /home/vincent/oe_dir3/setup-scripts/build/tmp-defaultsetup-eglibc-eglibc/work/armv5te-oe-linux-gnueabi/pulseaudio/3.0-r0 -name pulseaudio12:20
lpapp(or whatever you are trying to get in the end)12:21
lpappif it is built, then check whether it is put into package-split as suggested, if it is there, then check the image, etc.12:21
lpappbluelightning: cli tool ?12:23
*** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC12:36
Vincent_DIEHCOlpapp : I have pulseaudio in pkgdata packages-split package (I think I do not have to upgrade my kernell 2.6.37 to have pulseaudio that's right ?)12:38
lpappVincent_DIEHCO: well, it depends ...12:38
lpappVincent_DIEHCO: beside pkgdata, there must be an image subdirectory, too.12:45
Vincent_DIEHCOlpapp : yes :./pkgdata/pulseaudio ./pkgdata/runtime/pulseaudio ./pkgdata/runtime-reverse/pulseaudio12:46
bluelightningVincent_DIEHCO: what is in packages-split ?12:47
bluelightningwhat subdirectories, that is12:47
Vincent_DIEHCOvincent@electronic:~/oe_dir3/setup-scripts/build/tmp-defaultsetup-eglibc-eglibc/work/armv5te-oe-linux-gnueabi/pulseaudio/3.0-r0$ find . -name pulseaudio12:48
Vincent_DIEHCO./packages-split/pulseaudio ./packages-split/pulseaudio-module-bluetooth-proximity/usr/lib/pulseaudio ./packages-split/libpulsecommon/usr/lib/pulseaudio ./packages-split/pulseaudio-dbg/usr/bin/.debug/pulseaudio ./packages-split/pulseaudio-dbg/usr/src/debug/pulseaudio ./packages-split/pulseaudio-dbg/usr/lib/pulseaudio ./packages-split/pulseaudio-module-alsa-card/usr/share/pulseaudio ./packages-split/pulseaudio-misc/usr/lib/pulse12:48
Vincent_DIEHCO./packages-split/pulseaudio-module-gconf/usr/lib/pulseaudio ./packages-split/pulseaudio-dev/usr/lib/pulseaudio ./packages-split/pulseaudio-server/usr/bin/pulseaudio12:48
lpappVincent_DIEHCO: you did not check the image directory.12:50
lpappalso whether the package-split directories contain what the need to.12:50
Vincent_DIEHCOthere are also results in ./package12:50
Vincent_DIEHCO./package/usr/bin/pulseaudio ./package/usr/bin/.debug/pulseaudio ./package/usr/src/debug/pulseaudio ./package/usr/lib/pulseaudio ./package/usr/share/pulseaudio12:52
Vincent_DIEHCOI am looking for the image directory path with the reference man12:53
ndecVincent_DIEHCO: what have you done to 'add' pulseaudio in your image? enabling the DISTRO_FEATURE isn't enough, you need to add the packages to the image.12:58
ndeci am not using pulse, but looking at the recipe, it seems that the binary package to add into the image is pulseaudio-server, which you should see in packages-split as indicated above12:59
Vincent_DIEHCOok, I give you some more explanation of my tool chain12:59
Vincent_DIEHCOrootfs result is in build/tmp-defaultsetup-eglibc-eglibc/deploy/images/eukrea-cpuimx25, to had packages I edited ./sources/meta-eukrea/recipes-eukrea/images/eukrea-base-image.bb13:01
Vincent_DIEHCOI never change the kernel13:01
ndecwhat change did you make in the image?13:01
ndecyou don't need to change the kernel.13:02
Vincent_DIEHCOndec : I add names of packages in IMAGE_INSTALL13:03
*** alimon <alimon!~alimon@189.154.9.211> has joined #yocto13:04
Vincent_DIEHCOndec : I did for libxml2 freetype cronie logrotate tzdata gstreamer & cie and now for pulseaudio13:04
ndecas i said, you should add pulseaudio-server13:05
*** AlexVaduva <AlexVaduva!c1ca1642@gateway/web/freenode/ip.193.202.22.66> has quit IRC13:05
ndecyou can inspect what each 'binary' package contain by looking at WORKDIR/packages-split, or possibly looking at tmp/deploy/ipk/...13:05
Vincent_DIEHCObitbake does not accept pulseaudio-server13:06
ndecyou mean as of 'bitbake pulseaudio-server'?13:07
*** AlexVaduva <AlexVaduva!c1ca1642@gateway/web/freenode/ip.193.202.22.66> has joined #yocto13:08
lpappVincent_DIEHCO: you do not have anything in DISTRO_FEATURES_BACKFILL_CONSIDERED either, right?13:08
Crofton|workFFS, it is not the poky build system!13:09
Crofton|workhttp://events.linuxfoundation.org/events/embedded-linux-conference-europe/extend-the-experience/yocto-dev-day13:09
ndechehe13:11
Vincent_DIEHCOndec : if I add pulseaudio-server after pulseaudio and others packages in the recipe, I have the error : Collected errors: |  * satisfy_dependencies_for: Cannot satisfy the following dependencies for pulseaudio-server: |  * consolekit * |  * opkg_install_cmd: Cannot install package pulseaudio-server. | ERROR: Function failed: do_rootfs13:12
Crofton|workI am cranky again this morning13:12
lpappwhich is the correct sysroot that is also put into the image? I am trying to use build/tmp/sysrootfs/foo, but apparently, it is not it.13:13
ndecVincent_DIEHCO: hmm. ok. which version of OE are you using? i should have started with that.13:13
ndeclpapp: the sysroot is not put into the image13:13
lpappndec: I know, but I am looking for exactly the same rootfs13:14
lpappsince gdb (client) and gdbserver need to work on the same.13:14
Vincent_DIEHCOlpapp : DISTRO_FEATURES_BACKFILL="pulseaudio sysvinit"13:14
ndecah. that's different then ;-)13:14
ndecit's in the image WORKDIR/rootfs13:14
lpappVincent_DIEHCO: there ya ho.13:14
lpappVincent_DIEHCO: anyway, if you had already added the pulse packages to the image, I have no clue...13:15
lpappVincent_DIEHCO: check what packages the image tries to reuse for the generation.13:15
lpappVincent_DIEHCO: the usual bitbake -e ... | grep ^IMAGE_INSTALL13:16
lpappyou can also check the manifest file ("${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest).13:17
lpappndec: different?! Why are there different rootfses generated?!13:17
ndecone is the rootfs, the other one is the sysroot that contains development files for the build13:18
lpappndec: so why would they contain e.g. different libc versions?13:18
ndechmm. what do you mean?13:19
Vincent_DIEHCOlpapp : Do you mean one package name appears in two recipe ?13:20
lpappndec: what I am seeing is that using the aforementioned sysroots for gdb on the host with the rootfs on the target and gdbserver, gdb seems to think that some core libraries are different.13:20
lpapphence, it cannot properly debug stuff.13:20
lpappndec: I honestly do not see rootfs in build/tmp/work/13:33
lpappndec: see, what I need is to set up the _same_ rootfs on the host that is burnt onto the target.13:37
lpappotherwise gdbserver + gdb will not work.13:37
*** Nitin <Nitin!~nakamble@134.134.139.76> has joined #yocto13:40
ndeclpapp: the same rootfs is in the image WORKDIR/rootfs, but it gets removed with rm_work.13:40
lpappndec: you mean in each package's chunk as zillion separate subdirectories?13:41
ndecno, i mean the 'image' WORKDIR.13:41
ndecthe image is a recipe (.bb) itself. so it has its WORKDIR too13:41
lpappI do not follow, really.13:41
lpappcan you give a concrete example?13:42
lpappa concrete path where the _whole_ rootfs is available as sysroot?13:42
lpapp(otherwise gdb + gdbserver will not work)13:42
ndectmp-eglibc/work/ifc6410-oe-linux-gnueabi/core-image-minimal/1.0-r0/rootfs13:42
ndecit's the folder where the 'rootfs' is built during do_rootfs before it gets compressed in DEPLOY13:43
lpappok, thanks.13:43
lpappndec: I am still wondering why gdb thought I would have different versions in the image and build/tmp/sysroots, but I guess it does not matter since I should not use build/tmp/sysroots...13:49
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto13:52
*** alimon <alimon!~alimon@189.154.9.211> has quit IRC13:53
*** tasslehoff <tasslehoff!~Tasslehof@ti0260a430-1102.bb.online.no> has quit IRC13:56
Vincent_DIEHCOlpapp : I do not know what I am looking for but I understand there is problem of dependance. One tool included in pulseaudio-server named consolekit cannot be provided (I don't know why) . I think this is same problem for me discussed here http://lists.openembedded.org/pipermail/openembedded-core/2012-November/071168.html my OE version is Dylan.13:59
Vincent_DIEHCOIf it is same I think I can found a "work around" somewhere in doc or mailing list.14:00
*** phantomD <phantomD!destroy@a89-154-119-158.cpe.netcabo.pt> has quit IRC14:05
*** madisox <madisox!~madisox@nat/cisco/x-xrcwfrlypytivhfr> has joined #yocto14:05
*** phantomD <phantomD!destroy@a89-154-119-158.cpe.netcabo.pt> has joined #yocto14:05
*** Nitin <Nitin!~nakamble@134.134.139.76> has quit IRC14:08
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC14:11
*** Marex__ <Marex__!~Marex@195.140.253.167> has quit IRC14:11
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC14:11
Anarkywhy do I keep having "Multiple .bb files are due to be built which each provide virtual/libgles1" while I set PREFERRED_PROVIDER_virtual/libgles1 ?14:12
*** jkridner <jkridner!~jkridner@c-98-250-189-79.hsd1.mi.comcast.net> has joined #yocto14:12
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:12
Anarkywith the same error on ligles2 and egl14:12
rburtonAnarky: you've left out a virtual/ that something - likely mesa - is providig but you're not redefining14:13
*** Guma <Guma!~Guma@96.25.148.38> has joined #yocto14:14
Anarkyrburton: ok, but what happens if I set this virtual/ to libgles-omap3 while it's not providing this virtual?14:14
*** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto14:14
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto14:16
AnarkyI just tried to add virtual/libgl and virtual/mesa to libgles-omap3 (ie everything that mesa provides) but this error is still happening14:19
rburtonif gles-omap3 doesn't support something and you don't want mesa, set it to ""14:19
rburtonand if you're still getting the error then there's a virtual still unset14:19
rburtonfeel free to pastebin your settings14:19
rburton(surprised this is still a problem with the drivers)14:20
SaurAnyone know how to use KERNEL_MODULE_PROBECONF? I cannot find any examples of how to use it in Poky or OE and there is nothing in the documentation...14:22
*** Marex <Marex!~Marex@195.140.253.167> has joined #yocto14:22
GumaHello. I have question that I need little help with. I am working with ARM board that has minimal yacto installed on it. I am creating packages with checkinstall (RPM). It all goes well so far. When I try to install such package I get warning message "warning: package postgresql-9.3.5-1.armv7l is intended for a armv7l-unknown-linux platform"14:23
GumaI did created this rpm on this board. What is wrong?14:23
lpappSaur: have you tried reading ./meta/classes/kernel-module-split.bbclass ?14:23
Saurlpapp: Yes...14:23
JaMaSaur: read the kernel-module-split.bbclass it's relatively simple to understand14:24
Gumauname -m shows armv7l. So looks like checkinstall detect it correct.14:24
JaMaSaur: for each module_conf_foo = "bar" line, you need to add "foo" in KERNEL_MODULE_PROBECONF variable14:24
lpappGuma: I am not sure if it is due to unknown... tried to specify that in the build system?14:25
SaurJaMa: Ok, so basically the same as with KERNEL_MODULE_AUTOLOAD.14:25
JaMaSaur: and "foo" is basename of the kernel module14:25
JaMaSaur: yes14:25
Anarkyrburton: I'm surprised too, I add this error few weeks ago but the PREFERRED_PROVIDER worked; here are the relevant part: http://pastebin.com/2SYN7AbH14:25
SaurOk, should be simple enough to fix then. :)14:25
lpappSaur: have you also read c56c9a2f41eac8f87f13547806edc794b77ba54e ?14:25
GumaI found /etc/rpm/platform and it contents goes not have armv7l. Who creates and updates /etc/rpm/platform14:25
Saurlpapp: Yes. :)14:26
lpapphttp://lists.openembedded.org/pipermail/openembedded-core/2014-June/093436.html14:26
Anarkyrburton: I tried to remove mesa-demos but it didn't changed anything14:26
JaMaSaur: you can also read e9cd8ba3dda624615b68c601eac04427d9483f14 and 6f8b5be646be0f3e15e215907547f11d2a23d81b in oe-core14:26
rburtonAnarky: huh, should work.  at least that's what meta-intel does for emgd.14:27
* rburton kicks a build of meta-intel to see what happens14:27
Gumalpapp: should ./configure auto detect it? Is it possible to add line to /etc/rpm/platform?14:27
rburtonAnarky: the other alternative is that something else is pulling in mesa directly14:28
JaMae.g. weston used to do it before daisy14:28
rburtonrburton: ooh, virtual/libgl didn't take effect.  i thought setting to "" would work.  set it to mesa-gl14:28
rburtonAnarky: (you can tell the libgl preference didn't kick in as it warns that there are multiple providers to pick from)14:29
bluelightningGuma: that's the other end of the process; /etc/rpm/platform is generated when the image is generated14:29
rburtonAnarky: then chase what is depending on virtual/libgl14:29
Anarkyrburton: I saw that, if I don't write anything about libgl I don't get this note14:30
rburtonAnarky: because it defaults to mesa14:30
Anarkyrburton: ok. How can I found with recipe is asking mesa?14:31
rburtonAnarky: git grep virtual/libgl should do it14:31
Gumabluelightning: image? rpm image? or kernel image? or when image is installed (rpm) just to be clear14:31
bluelightningGuma: the rootfs image14:31
Gumabluelightning: I see. Thank you14:32
bluelightningI think you may be able to add additional ones by adding them to PACKAGE_EXTRA_ARCHS14:32
Gumabluelightning: so do you have idea how to fix it? looks like checkinstall uses uname -m to detect arch to create and package rpm. And this RPM does not want install on system what was created. How to fix this? or what to change? Suggestions?14:34
*** roric <roric!~roric@83.140.117.51> has quit IRC14:34
bluelightningGuma: well, to be perfectly honest I wouldn't create packages in this manner, I'd use the build system14:34
bluelightningGuma: but if you must do it this way then you probably just need to ensure that extra architecture gets added to PACKAGE_EXTRA_ARCHS14:35
Gumabluelightning: "I'd use the build system" what build system are you referring? rpmbuild? Or some other tool?14:36
ivanstojanovichi guys, I am still trying to get the qtgstreamer recipe working...but it's tricky :( I couldn't find nothing on the internet but for the old one 0.1, I am working with 1.x. Suggestions are welcome :)14:37
bluelightningGuma: as in BitBake / OpenEmbedded, i.e. what the Yocto Project uses14:38
lpappivanstojanovic: show what you have already and what the error is.14:38
ndecbluelightning: you manage to not use the work 'poky' ;-)14:38
lpappndec: 's poky ?14:39
*** sjolley <sjolley!sjolley@nat/intel/x-xwgzeshqvfvgkhbp> has quit IRC14:39
rburtonndec: bluelightning is a master of terminology, level 314:39
bluelightningndec: poky is just a reference of that ;)14:39
ndecthe 'word'14:39
ndecterminology and politics, i guess ;-)14:40
*** roric <roric!~roric@83.140.117.51> has joined #yocto14:42
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC14:43
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:43
ivanstojanovichere is the recipe: http://pastebin.ca/283222314:43
*** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC14:43
*** eflanagan_ <eflanagan_!~eflanagan@c-24-21-207-18.hsd1.or.comcast.net> has quit IRC14:44
lpappivanstojanovic: 16-27 -> is that boilerplate really needed?14:44
*** stiandre <stiandre!~stiandre@109.247.13.242> has quit IRC14:44
ivanstojanovic@lpapp: no clue what bolierplate is :)14:46
*** ant_work <ant_work!~ant__@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC14:46
ndecivanstojanovic: it should be qt-gstreamer, not qtgstreamer, to match the upstream name. but that's a detail for now..14:47
*** joeythesaint <joeythesaint!~joe@209.141.56.162> has quit IRC14:47
lpappivanstojanovic: what happens for bitbake?14:47
ivanstojanovicthat should not be a problem I think, but I will rename it immediately anyhow14:47
*** joeythesaint <joeythesaint!~joe@209.141.56.162> has joined #yocto14:47
lpapp12-14 also looks boilerplate.14:47
lpappin addition, why inherit both qmake5 and cmake?14:47
lpappThey are different build systems, no?14:47
*** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC14:48
ivanstojanovicI added a comment (the error message after I try to bake it)14:49
Gumabluelightning: I will look into BitBake later. for now I will stay with checkinstall/rpmbuild. I just did quick grep and I can't find PACKAGE_EXTRA_ARCHS in source configure or checkinstall script. Are you refering using --arch switch in checkinstall?14:50
ivanstojanovicwhy both, I used a template I found on the internet for qt-gstreamer 0.1...it was like that there so I didn't change it14:50
bluelightningGuma: sorry, I am talking about what you'd need to set when using our build system to actually build the image14:50
Anarkyrburton: thanks for the git grep, but the only thing defining with a ?= "mesa" is qemu14:50
lpappivanstojanovic: it seems to be a cmake based project, so I would not inherit qmake.14:51
bluelightningGuma: in your case you could just edit /etc/rpm/platform I guess14:51
Gumabut when you refering to image you mean rootfs14:51
bluelightningGuma: yes14:51
*** roric <roric!~roric@83.140.117.51> has quit IRC14:53
Gumabluelightning: so PACKAGE_EXTRA_ARCHS would have to be set in my case to armv7l?14:53
ivanstojanovic@lpapp: ok, I removed qmake5, it seems it still works14:53
ivanstojanovic@lpapp: I mean, it still doesn't work :)14:54
GumaI did not build it yet. I took over someone else who is not here. So I am getting my feet wet.14:54
fray_RPM packages have an embedded canonical arch assigned to them..14:55
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC14:55
*** mranostay <mranostay!~mranostay@c-50-186-57-56.hsd1.or.comcast.net> has joined #yocto14:55
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto14:55
fray_RPM 4 uses the 'arch' field from (essentially) the filename..  this causes issues where you get hard coded lists, and have to make code changes to resolve them..14:55
bluelightningGuma: surely it would be the value that rpm is claiming is not understood - i.e. armv7l-unknown-linux14:55
fray_RPM 5 instead uses the /etc/rpm/platform file to list what the core platform is, followed by a list of compatible canonical arches..14:55
fray_(the later list can included regex values)14:56
bluelightningGuma: ^ fray_ is the expert on this area ;)14:56
lpappivanstojanovic: where can the error be seen?14:56
fray_if you (on the target) use rpm -q --yaml <package> and inspect the result you should find the arch info, such as armv7l-unknown-linux-gnueabi14:56
fray_I don't remember the field offhand, and I don't have a bootable target at the moment to find the right value14:57
ivanstojanovic@lpapp: at the same link, in the comments: http://pastebin.ca/283222314:57
fray_the /etc/rpm/platform list is ordered though..  if you have multiple packages (same name, different canonical arch, the highest in the order will be installed in the case of a conflict..)14:57
fray_this allows the system to determine the "best" fit as well.. so order does matter14:57
*** kroon <kroon!~kroon@fw.mikrodidakt.se> has quit IRC14:59
*** belen <belen!~Adium@192.198.151.43> has quit IRC14:59
lpappivanstojanovic: DEPENDS = "qtbase"?15:00
*** Vincent_DIEHCO <Vincent_DIEHCO!58bade28@gateway/web/freenode/ip.88.186.222.40> has quit IRC15:01
*** belen <belen!~Adium@192.198.151.44> has joined #yocto15:01
lpapp(and whatever else it depends on)15:01
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC15:01
ivanstojanovic@lpapp: that error has something to do with OE_QMAKE_PATH_EXTERNAL_HOST_BINS...there is an ugly hack in cmake recipe for that error...but let me check if DEPENDS = "qtbase" will change anything15:01
lpappivanstojanovic: well, if it does not, try to drop Yocto and get qt-gstreamer working manually with cmake.15:02
lpappThat would be the first step to see how it is buildsystem is supposed to work.15:02
lpappits*15:02
*** dvhart <dvhart!dvhart@nat/intel/x-rrqgnfhcyntjfbdt> has joined #yocto15:03
ivanstojanovic@lpapp: ok, let's see how that will work15:03
ivanstojanovic@lpapp: thanks :)15:03
*** belen <belen!~Adium@192.198.151.44> has quit IRC15:05
*** sjolley <sjolley!~sjolley@134.134.137.75> has joined #yocto15:06
*** dvhart <dvhart!dvhart@nat/intel/x-rrqgnfhcyntjfbdt> has quit IRC15:08
Gumafray_: I am on RPM 515:14
*** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto15:14
Gumafray_: rpm -q --yaml <package> does not work since package is not installed. And installing I get this message "warning: package postgresql-9.3.5-1.armv7l is intended for a armv7l-unknown-linux platform"15:17
GumaSo should I for now add armv7l-unknown-linux platform to /etc/rpm/platform at the very bottom?15:17
GumaAnd I am assuming the rebuilding rootfs (as bluelightning pointed out earlier) add PACKAGE_EXTRA_ARCHS="armv7l" ? So it will show up in packages?15:19
GumaIs that how this works?15:19
fray_rpm -qp --yaml <package>15:19
fray_add the 'p' for package15:19
fray_ya, if you are getting that message the internal arch is likely armv7l-unknown-linux  if you add that it should allow the install..15:20
fray_As for the PACKAGE_EXTRA_ARCHS, you'd have to add it as an "_append"15:20
fray_I'd be careful though.. AFAIK none of that is Yocto Project naming.. so the package may not be compatible with your system15:21
*** blloyd <blloyd!~blloyd@COX-66-210-177-72-static.coxinet.net> has joined #yocto15:22
GumaI just quickly added armv7l-.*-linux.* to platform and warning is gone. I got another error about error: Failed dependencies: /proc/9626 is needed by postgresql-9.3.5-1.armv7l. But I think I know what that might be. One thig at a time15:22
Gumalet me try rpm -qp15:23
Gumafray_: I see this "Arch: armv7l"15:25
fray_thats not the right field.. look further for something like canonical arch15:25
fray_(I'll see if I can find the name of the right field)15:25
fray_'Arch:' is the unused filename architecture.. it's ignored by RPM5, as it's not explicit enough for the platform checking15:26
fray_the value is 'Platform:15:28
fray_i.e.:   Platform: lib32_x86-windriver-linux-gnu15:28
fray_you can query it directly as:15:29
Gumafray_: Platform is armv7l-poky-linux-gnueabi15:29
fray_./rpm -qp --qf '%{NAME} %{PLATFORM}\n' <package>15:29
fray_there ya go.. thats the entry you need (or a wild card to match) in your /etc/rpm/platform file15:29
GumaSo I added armv7l-.*-linux.*. Should I change it to armv7l-poky-linux.*15:30
GumaI already have  arm-poky-linux-gnueabi in platform file. I will add armv7l-poky-linux-gnueabi right under it.15:32
*** roric <roric!~roric@83.140.117.51> has joined #yocto15:32
fray_yes..15:33
fray_typical file is:15:33
fray_<uname -m>-<vendor>-<os>[-<extension>]15:33
fray_regex115:33
fray_regex215:33
fray_regex315:33
fray_...15:33
fray_regexN15:33
fray_(You've also found the format of the regex)  ;)15:34
GumaYey!!!15:34
Gumaok so co correct it in next rootfs build. Should I add PACKAGE_EXTRA_ARCHS="armv7l". that correct format for BitBake?15:37
Gumafray_: Thank you for you help :)15:45
GumaAnd bluelightning :)15:45
*** dvhart <dvhart!~dvhart@134.134.139.72> has joined #yocto15:47
*** belen <belen!~Adium@192.198.151.43> has joined #yocto15:50
Gumafray_: When looking in at my package internals "rpm -pq --yaml postgresql-9.3.5-1.armv7l.rpm | grep -i 9626" I see two entries. The reason I did this is that when trying to install "rpm -Uvh postgresql-9.3.5-1.armv7l.rpm" I get this error message:15:55
Guma"/proc/9626 is needed by postgresql-9.3.5-1.armv7l"15:56
fray_that sounds like a bug in the package!15:56
fray_somehow something in the package got a link or otherwise reference to /proc/9626, which simply won't exist for you..15:56
fray_so you'll have to find and fix the package bug first..15:57
fray_there is per-file depednency information in most RPM packages..  you can query things like rpm -qp --filerequires and see if you can trace down what is requiring that and fix it15:57
GumaI think it would be checkinstall / installwatch :)15:57
*** roric <roric!~roric@83.140.117.51> has quit IRC15:57
*** fgretief <fgretief!~chatzilla@196-210-119-217.dynamic.isadsl.co.za> has joined #yocto16:04
*** ddom <ddom!~ddom@p4FFAB15F.dip0.t-ipconnect.de> has quit IRC16:05
Gumafray_: :) Is see /proc/self in it16:12
*** dvhart <dvhart!~dvhart@134.134.139.72> has quit IRC16:12
*** jbrianceau is now known as jbrianceau_away16:13
fray_ya.. that is wrong16:14
fray_package should never own or depend (directly) on proc self16:14
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC16:17
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto16:20
*** agust <agust!~agust@p4FDE71BA.dip0.t-ipconnect.de> has quit IRC16:20
*** dvhart <dvhart!dvhart@nat/intel/x-tfexphthccjqgwll> has joined #yocto16:23
*** Nitin <Nitin!nakamble@nat/intel/x-ccwgmoznulanedlc> has joined #yocto16:28
*** ajtag <ajtag!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has quit IRC16:31
*** ajtag <ajtag!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has joined #yocto16:33
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto16:51
*** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has quit IRC16:52
*** dvhart <dvhart!dvhart@nat/intel/x-tfexphthccjqgwll> has quit IRC16:57
*** dvhart <dvhart!~dvhart@134.134.139.72> has joined #yocto16:59
*** sjolley <sjolley!~sjolley@134.134.137.75> has quit IRC17:00
*** sjolley <sjolley!~sjolley@134.134.137.75> has joined #yocto17:02
maxtothemaxwhere would I suggest someone report a bug in meta-openembedded?17:16
fray_openembedded-devel@lists.openembedded.org17:26
maxtothemaxreally? that's not just patches only?17:27
fray_development discussion and patches17:27
*** Guma <Guma!~Guma@96.25.148.38> has quit IRC17:27
maxtothemaxok thanks17:30
*** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@host246-168-dynamic.14-87-r.retail.telecomitalia.it> has joined #yocto17:32
*** ddom <ddom!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has joined #yocto17:33
*** WarheadsSE <WarheadsSE!~WarheadsS@50.164.115.22> has joined #yocto17:36
WarheadsSEAnyone seen this or similar before? ERROR: The following packages could not be configured offline and rootfs is read-only: ttf-sazanami-mincho17:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:36
sgw_khem: I just discovered that we are getting some errors reported during eglibc configuration, might be related to your menu config patch (maybe)17:37
nerdboyWarheadsSE: sounds like fontcache maybe?  guess it thinks it needs to run on first boot on rw rootfs17:38
nerdboylook and see what's in the postinst file17:39
WarheadsSEhrm. A definitive WTF, because I have never once hit this before.17:39
*** Guma <Guma!~Guma@96.25.148.38> has joined #yocto17:39
nerdboyme neither17:39
WarheadsSEI've built this image recipe  a lot of times, but today, wtfbbq17:39
*** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has quit IRC17:40
nerdboydid you update build branch? add a package with a new font dep?  anything?17:40
Gumafray: Not sure if I missed answer since I got disconnected. As far as PACKAGE_EXTRA_ARCHS="armv7l" goes is that the format I should use?17:40
*** belen <belen!~Adium@192.198.151.43> has quit IRC17:41
WarheadsSENothing that is related to anything to do with fonts, fontcache, etc.17:43
WarheadsSEnerdboy: more over, wtf mate. This rootfs should not be in a RO state at the point it is doing the package configs.17:45
nerdboyno, i think it means "is configured to boot ro" so it can't do it then either17:47
nerdboyjust a guess...17:48
nerdboypkg_postinst wants to run either offline (rootfs/image creation) or on first boot up17:48
* nerdboy pulling from memories of classic17:49
WarheadsSEheh17:49
nerdboyhaven't really tried ro_rootfs with newer builds17:50
JaMayes, it's failing postinst17:50
JaMacheck with bitbake -e why your image is switcher to R-O and what try to re-execute the postinst by hand to see why it's failing17:50
JaMaoften it's because of qemu-native not working correctly17:50
JaMahttp://lists.openembedded.org/pipermail/openembedded-core/2014-July/095119.html17:51
WarheadsSEhrm.17:52
WarheadsSEdef don't have this in my srcrevs for dora @ my manifest.17:53
*** hbruce <hbruce!~hbruce@134.134.137.75> has joined #yocto17:54
JaMait's not even in master, it's just example of possible issues I was hit by17:54
WarheadsSEk, thanks for the heads up17:54
WarheadsSEdefinitely *odd*17:55
JaMain fontcache.bbclass as well as some other classes17:55
JaMas/other classes/e.g. pango17:55
*** maxtothemax <maxtothemax!~maxtothem@134.134.139.74> has quit IRC17:57
*** maxtothemax <maxtothemax!~maxtothem@134.134.139.74> has joined #yocto17:57
WarheadsSEah.. yup17:57
WarheadsSE| > Executing update_font_cache17:57
WarheadsSE| WARNING: intercept script "update_font_cache" failed, falling back to running postinstalls at first boot17:57
WarheadsSEConsidering we make squashfs images.. yeah, thats RO.17:58
lpapphi nerdboy18:01
nerdboyyo18:01
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:02
WarheadsSEJaMa: nerdboy yup..18:03
WarheadsSEthis one will be fun to hunt.18:03
JaMait's not so complicated.. just re-run the postinst manually18:06
*** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has joined #yocto18:10
*** sameo <sameo!~samuel@192.55.55.37> has quit IRC18:11
nerdboyif all else fails, package the final cache...18:16
nerdboynot the best option, but...18:17
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-zfebbyaethkynhog> has quit IRC18:18
rburtonWarheadsSE: gnar, that again.  the log might be useful.  what target machine?18:19
WarheadsSEx64 making i58618:21
nerdboyno reason fontcache shouldn't be able to run with the right perms during normal postinst..18:21
nerdboyIn Theory anyway...18:21
WarheadsSEYeah, never ever seen this before18:21
WarheadsSEEven built a different image in this same build root, same state, no problem.18:22
nerdboyi say that, but my rpi sato image is still contaminated with the wrong x-init package...18:22
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto18:23
nerdboyWarheadsSE: does your recipe inherit fontcache, or have a hard-coded postinst script?18:26
* nerdboy never even looked at fontcache.bbclass before...18:26
WarheadsSEWe don't even have any custom font packages.18:28
nerdboylooks like oe-core and poky/meta are different18:28
nerdboywhich one are you using?18:29
WarheadsSEdora oe-core18:29
nerdboymaster poky/meta18:29
nerdboymight be why i haven't seen it...18:30
*** [Sno]_ <[Sno]_!~Sno]@p578b540c.dip0.t-ipconnect.de> has joined #yocto18:33
*** dvhart <dvhart!~dvhart@134.134.139.72> has quit IRC18:35
*** khem_ <khem_!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has joined #yocto18:35
*** Nitin1 <Nitin1!~nakamble@134.134.137.75> has joined #yocto18:36
*** ajtag_ <ajtag_!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has joined #yocto18:40
*** Nitin <Nitin!nakamble@nat/intel/x-ccwgmoznulanedlc> has quit IRC18:41
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC18:41
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC18:41
*** khem <khem!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has quit IRC18:41
*** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has quit IRC18:41
*** ajtag <ajtag!~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net> has quit IRC18:41
*** [Sno]_ is now known as [Sno]18:41
*** ajtag_ is now known as ajtag18:41
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto18:41
*** Nitin <Nitin!nakamble@nat/intel/x-gofxhmowvdehjomt> has joined #yocto18:42
*** Nitin1 <Nitin1!~nakamble@134.134.137.75> has quit IRC18:44
*** manuel_ <manuel_!~manuel_@pD9FDCCDD.dip0.t-ipconnect.de> has quit IRC18:47
*** Daemon404 <Daemon404!~who_knows@cpc21-newt31-2-0-cust123.newt.cable.virginm.net> has quit IRC18:47
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto18:47
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto18:48
*** Marex <Marex!~Marex@195.140.253.167> has quit IRC18:51
* nerdboy still doing surgery on older kid's laptop18:52
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has joined #yocto18:52
nerdboywith a whole week left before school starts18:53
*** Marex <Marex!~Marex@195.140.253.167> has joined #yocto18:58
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has quit IRC19:00
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has joined #yocto19:00
*** agust <agust!~agust@p4FDE71BA.dip0.t-ipconnect.de> has joined #yocto19:07
*** Nitin1 <Nitin1!~nakamble@192.55.55.39> has joined #yocto19:38
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has quit IRC19:40
*** Nitin <Nitin!nakamble@nat/intel/x-gofxhmowvdehjomt> has quit IRC19:40
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has joined #yocto19:42
*** ant__ <ant__!~andrea@host109-40-dynamic.0-79-r.retail.telecomitalia.it> has joined #yocto19:50
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto19:52
*** LCyrin <LCyrin!~LCyrin@2607:fb90:270a:b754:14c4:900c:cfab:e402> has joined #yocto20:00
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC20:02
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has quit IRC20:12
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has joined #yocto20:13
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d> has joined #yocto20:16
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d> has quit IRC20:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:16
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto20:19
*** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has quit IRC20:19
*** dvhart <dvhart!dvhart@nat/intel/x-otmckbmxkjhglbaj> has joined #yocto20:20
*** dvhart <dvhart!dvhart@nat/intel/x-otmckbmxkjhglbaj> has quit IRC20:21
*** dvhart <dvhart!dvhart@nat/intel/x-wqnhtzedlllyoohy> has joined #yocto20:21
*** bluelightning_ <bluelightning_!~paul@167.127.187.81.in-addr.arpa> has joined #yocto20:22
*** bluelightning_ <bluelightning_!~paul@167.127.187.81.in-addr.arpa> has quit IRC20:22
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:22
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC20:22
*** dvhart <dvhart!dvhart@nat/intel/x-wqnhtzedlllyoohy> has quit IRC20:22
*** dvhart <dvhart!~dvhart@134.134.139.72> has joined #yocto20:23
*** dvhart <dvhart!~dvhart@134.134.139.72> has quit IRC20:25
*** sjolley <sjolley!~sjolley@134.134.137.75> has quit IRC20:49
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC20:49
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC20:54
*** sjolley <sjolley!~sjolley@134.134.137.75> has joined #yocto20:54
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto20:55
*** awafaa_ is now known as awafaa21:00
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC21:04
*** dburman <dburman!~dburman@173-11-42-18-Minnesota.hfc.comcastbusiness.net> has joined #yocto21:04
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto21:05
*** sjolley <sjolley!~sjolley@134.134.137.75> has quit IRC21:06
*** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto21:11
*** jkridner|work <jkridner|work!~jkridner@c-98-250-189-79.hsd1.mi.comcast.net> has joined #yocto21:12
*** jzhang <jzhang!~jzhang@134.134.139.76> has quit IRC21:12
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC21:13
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:13
*** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC21:13
*** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto21:13
*** jzhang <jzhang!~jzhang@134.134.139.76> has joined #yocto21:13
*** demonimin <demonimin!~demonimin@pro75-5-88-162-203-35.fbx.proxad.net> has joined #yocto21:14
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto21:14
*** Marex <Marex!~Marex@195.140.253.167> has quit IRC21:18
*** Marex <Marex!~Marex@195.140.253.167> has joined #yocto21:20
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC21:38
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto21:39
*** sjolley <sjolley!~sjolley@134.134.137.75> has joined #yocto21:42
*** sjolley <sjolley!~sjolley@134.134.137.75> has quit IRC21:44
khem_sgw_: what error do you see21:46
sgw_Hi khem_, hang on I will pastebin it21:47
khem_OK21:48
*** khem_ is now known as khem21:49
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC21:50
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC21:51
sgw_khem: had to rebuild, here's the output: http://pastebin.com/d9Ms96E821:56
*** dburman <dburman!~dburman@173-11-42-18-Minnesota.hfc.comcastbusiness.net> has quit IRC21:58
*** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC22:01
*** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto22:01
sgw_khem it seems like it's not parseing the option-groups files correctly, just a guess22:03
*** sjolley <sjolley!~sjolley@134.134.137.75> has joined #yocto22:04
*** Nitin1 <Nitin1!~nakamble@192.55.55.39> has quit IRC22:05
*** Nitin <Nitin!nakamble@nat/intel/x-luvtendlsxjccwck> has joined #yocto22:05
*** sjolley <sjolley!~sjolley@134.134.137.75> has quit IRC22:08
*** sjolley <sjolley!~sjolley@134.134.137.75> has joined #yocto22:09
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC22:13
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto22:15
*** ant__ <ant__!~andrea@host109-40-dynamic.0-79-r.retail.telecomitalia.it> has quit IRC22:18
seebsSo, I finally figured out a thing that's been bugging me for ages, which is that attempts to expand anything that uses TARGET_VENDOR for multilibs tend to fail.22:20
seebsIt turns out: There's a few things that happen early on (like preferred_ml_updates), which depend on TARGET_VENDOR, but TARGET_VENDOR_virtclass-multilib-foo doesn't get set until multilib_virtclass_handler_global, which doesn't execute until fairly late.22:21
seebsBut the TARGET_VENDOR values don't have any obvious reason to be contingent on a recipe being parsed.22:21
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC22:21
seebsAnd this leads me to a thing I don't quite know about the order of events, which is: If I have two handlers for ConfigParsed, can I indicate in some way that one of them needs to happen first?22:21
kergothnope. there's no way to enforce order. its possible the order *might* be reliable based on parse order / addhandler order, but i'm not certain22:22
kergothoe-lite added inter-"hook" (event handler) dependencies ala addtask, but we don't have that (yet)22:22
seebsSo, the net result is: Nothing in a ConfigParsed handler can assume that TARGET_VENDOR_virtclass-multlib-foo will be set. Even if I move the setting for those into a separate handler to run on ConfigParsed. Hmm.22:23
kergoththe multilib class by definition isn't inherited until after the recipe itself is parsed22:24
seebsOh-hoh.22:24
seebsI think I see the problem, then.22:24
seebsWell, wait. This is multilib_global.bbclass.22:24
kergothah, right. well, keep in mind that ConfigParsed gets un-finalized metadata passed to it22:25
kergothquite often a cnofigparsed handler will ahve to create a local copy and finalize it first to get appends/etc to apply22:25
seebsMostly, what it's doing is adding TARGET_VENDOR_virtclass-multlib-foo = "${TARGET_VENDOR}mlfoo", basically.22:25
seebsYeah.22:25
kergothits a common pattern -- we need to fix that, make a finalized config metadata instance get passed around to folks that need it22:25
*** sjolley <sjolley!~sjolley@134.134.137.75> has quit IRC22:25
seebsI had previously realized this was a problem, but I hadn't figured out *why* exactly, but it's killed otherwise-plausible designs before.22:25
seebsThe thing biting me right now: PREFERRED_VENDOR things using $TARGET_PREFIX don't get set correctly for multilibs.22:26
seebsBecause they get, e.g., i586-wrs-linux, instead of i586-wrsmllib32-linux.22:26
*** zarul <zarul!~zarul@ubuntu/member/zarul> has quit IRC22:31
seebsCome to think of it. Perhaps the right thing is to move the TARGET_VENDOR_* into a handler that runs on ConfigParsed, and ALSO move the preferred_ml_updates into that handler. Because that's more reasonably associated with multilib_global.bbclass than base.bbclass to begin with.22:32
*** sjolley <sjolley!sjolley@nat/intel/x-wknvrlujwhvnrtrt> has joined #yocto22:34
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto22:36
*** Guma <Guma!~Guma@96.25.148.38> has quit IRC22:36
*** Nitin <Nitin!nakamble@nat/intel/x-luvtendlsxjccwck> has quit IRC22:39
seebsOh, hey, that worked.22:42
*** Nitin1 <Nitin1!nakamble@nat/intel/x-uwyunkmqqongyflg> has joined #yocto22:43
seebsOkay, I think I have a proposed fix. In multilib_global.bbclass, add a new handler for ConfigParsed. Move the settings of TARGET_VENDOR_virtclass-multilib-* into that handler, and then have it call preferred_ml_updates().22:43
seebsWhich is moved over there from base.bbclass.22:44
seebsNet result, PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc then works.22:44
*** EddyLaiTW <EddyLaiTW!~eddylai@61-231-110-191.dynamic.hinet.net> has joined #yocto22:44
*** Nitin1 <Nitin1!nakamble@nat/intel/x-uwyunkmqqongyflg> has quit IRC22:45
*** Nitin <Nitin!~nakamble@192.55.55.39> has joined #yocto22:45
EddyLaiTWhi, I add this line"IMAGE_ROOTFS_EXTRA_SPACE = "512000" into local.conf then "bitbake core-image-full-cmdline", but there's no new .hddimg created with expected more 512MB space increated, deply/images22:48
EddyLaiTWhow to force roots rebuild after loca.conf modified?22:49
*** Nitin <Nitin!~nakamble@192.55.55.39> has quit IRC22:49
sgw_EddyLaiTW: try doing a bitbake -c clean core-image-full-cmdline22:51
*** Nitin <Nitin!~nakamble@134.134.137.75> has joined #yocto22:54
*** agust <agust!~agust@p4FDE71BA.dip0.t-ipconnect.de> has quit IRC23:00
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC23:04
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto23:07
*** Nitin <Nitin!~nakamble@134.134.137.75> has quit IRC23:13
*** zarul <zarul!~zarul@ubuntu/member/zarul> has joined #yocto23:16
*** Jefro <Jefro!~jefro@76-191-186-206.dyn.adsl.mcn.org> has joined #yocto23:33
*** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC23:53
*** Jefro <Jefro!~jefro@76-191-186-206.dyn.adsl.mcn.org> has quit IRC23:58

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!