Friday, 2013-08-02

*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:17
*** nitink <nitink!~nitink@> has quit IRC00:18
sgw_khem:  I just tested that pcc/floor issue with 1.6-rc1 qemu and got a failure so something changed between 1.4 and 1.5 versions of qemu, I guess I could try a bisect, but maybe you have other ideas?00:21
*** munch <munch!> has quit IRC00:27
*** phdeswer_ <phdeswer_!> has quit IRC00:30
-YoctoAutoBuilder- build #231 of nightly-world is complete: Failure [failed Building Images] Build details are at
*** _julian <_julian!> has joined #yocto00:48
*** _julian_ <_julian_!> has quit IRC00:51
*** amarsman <amarsman!~marsman@> has joined #yocto00:57
*** ant_home <ant_home!> has quit IRC01:02
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto01:04
*** davest <davest!Adium@nat/intel/x-jcfupoeldehmojyw> has quit IRC01:12
*** davest <davest!Adium@nat/intel/x-swroronwqelbngek> has joined #yocto01:17
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:21
*** davest <davest!Adium@nat/intel/x-swroronwqelbngek> has quit IRC01:25
*** swex <swex!~swex@> has joined #yocto01:29
*** ash_charles <ash_charles!> has quit IRC01:31
*** Bagder <Bagder!~daniel@rockbox/developer/bagder> has quit IRC01:32
*** mulhern <mulhern!> has joined #yocto01:33
*** swex <swex!~swex@> has quit IRC01:35
*** swex <swex!~swex@> has joined #yocto01:40
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has left #yocto01:55
-YoctoAutoBuilder- build #243 of nightly-x32 is complete: Failure [failed Building Images Running Sanity Tests] Build details are at
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC02:03
-YoctoAutoBuilder- build #238 of poky-tiny is complete: Failure [failed Building Images Publishing Artifacts] Build details are at
otaviokhem: I am building gcc fix02:07
-YoctoAutoBuilder- build #231 of nightly-multilib is complete: Failure [failed Building Images Running Sanity Tests Building Images_1 Running Sanity Tests_1 Building Images_2 Running Sanity Tests_2 Building Images_3 Running Sanity Tests_3 Building Images_4] Build details are at
*** seebs <seebs!~seebs@> has quit IRC02:09
*** seebs <seebs!~seebs@> has joined #yocto02:14
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto02:16
-YoctoAutoBuilder- build #4 of eclipse-plugin-kepler is complete: Failure [failed Building Eclipse Plugin Publishing Artifacts] Build details are at
khemsgw_: are you able to get same failure on 1.6rc1 or a different one ?02:42
khemotavio: ok. Cool add your results to patch thread02:42
khemotavio: thats the qemu version02:43
khemnot YP02:43
*** zenlinux <zenlinux!> has joined #yocto02:55
*** behanw <behanw!> has quit IRC03:18
*** andyross <andyross!> has joined #yocto03:24
*** vicky <vicky!~vicky@> has joined #yocto03:36
*** andyross <andyross!> has quit IRC03:45
*** Jefro <Jefro!> has quit IRC03:48
sgw_khem, same failure with 1.6rc1, so I bisected with in the 1.4->1.5 range and came up with that commit.03:48
*** andyross <andyross!> has joined #yocto04:12
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC04:24
*** nitink <nitink!~nitink@> has joined #yocto04:26
*** mulhern <mulhern!> has quit IRC04:26
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto04:36
*** vicky_ <vicky_!~vicky@> has joined #yocto05:08
-YoctoAutoBuilder- build #239 of poky-tiny is complete: Success [build successful] Build details are at
vicky_hi yocto. i m getting error of "cannot find -lm" while compiling gcc-4.7.2. but in sysroot lib directory, there is no libm file.anyway to fix this?05:10
vicky_i m using poky distro for at91sam9x5 soc.05:10
vicky_my machine.conf at
vicky_my local.conf at
-YoctoAutoBuilder- build #234 of nightly-non-gpl3 is complete: Success [build successful] Build details are at
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC05:18
*** zecke <zecke!> has joined #yocto05:21
*** Jefro <Jefro!> has joined #yocto05:22
*** amarsman <amarsman!~marsman@> has quit IRC05:25
vicky_sorry my local.conf at
-YoctoAutoBuilder- build #244 of nightly-x32 is complete: Success [build successful] Build details are at
*** andyross <andyross!> has quit IRC05:39
*** ynezz <ynezz!> has quit IRC05:47
*** ynezz <ynezz!> has joined #yocto05:47
-YoctoAutoBuilder- build #234 of nightly-mips is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
-YoctoAutoBuilder- build #236 of nightly-x86 is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
*** Jefro <Jefro!> has quit IRC05:55
*** Jefro <Jefro!> has joined #yocto05:56
*** agust <agust!> has joined #yocto06:03
*** Jefro <Jefro!> has quit IRC06:05
*** tor <tor!> has joined #yocto06:06
*** zeeblex <zeeblex!~apalalax@> has joined #yocto06:11
*** jjardon <jjardon!uid723@gateway/web/> has quit IRC06:14
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto06:30
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:31
*** thesignal <thesignal!~deadbot@> has joined #yocto06:53
*** zecke <zecke!> has quit IRC06:55
*** eballetbo <eballetbo!> has joined #yocto06:56
thesignalhi, i'm unable to compile perl und libxml-parser-perl-native for armv7a, @perl, i get some error about miniperl not being found. i thought miniperl got replaced by a full perl implementation?06:57
*** panda84kde <panda84kde!> has joined #yocto06:57
*** zecke <zecke!> has joined #yocto06:57
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:02
*** swex_ <swex_!~swex@> has joined #yocto07:02
*** swex <swex!~swex@> has quit IRC07:02
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:05
*** elmi82 <elmi82!> has joined #yocto07:06
*** thesignal <thesignal!~deadbot@> has left #yocto07:07
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC07:12
*** slaine <slaine!~slaine@> has joined #yocto07:24
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has joined #yocto07:29
lpapp_is it possible to put the tarball next to the recipe?07:30
lpapp_or insides files?07:30
*** silviof2 <silviof2!> has quit IRC07:33
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto07:34
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has quit IRC07:35
melonipoikaqt5 question07:36
*** ant_work <ant_work!> has joined #yocto07:36
melonipoikai ahve modified to use version 5.1.0 (default is 5.0.2)07:36
melonipoikanow i need to include that file, but where?07:37
*** Bagder <Bagder!~daniel@rockbox/developer/bagder> has joined #yocto07:40
*** tbn <tbn!~tbn@> has joined #yocto07:44
*** tbn is now known as Guest2847707:44
*** bluelightning <bluelightning!~paul@> has joined #yocto07:50
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:50
*** mihai <mihai!~mihai@> has joined #yocto07:58
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto07:59
bluelightningmorning all08:00
lpappis there a recipe finder service08:01
bluelightninglpapp: there is indeed:
lpappok, nginx is not available. :(08:04
bluelightningcoincidentally someone was asking about that the other day, I don't know if they started working on one08:05
bluelightningit was mr_science in #oe08:07
*** smartin <smartin!> has joined #yocto08:07
lpappand uwsgi ?08:09
*** jjardon <jjardon!uid723@gateway/web/> has joined #yocto08:10
bluelightninghaven't heard any discussion about that one08:11
rburtonall hail the layer index08:11
rburtonwhoever wrote that was a life-saver08:12
*** jjardon <jjardon!uid723@gateway/web/> has quit IRC08:24
*** jjardon <jjardon!uid723@gateway/web/> has joined #yocto08:26
bluelightningrburton: bah, humbug :)08:28
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:30
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:34
ant_workrburton: yet the author ignored the users and did not write a proper qt frontend08:38
rburtonsome people eh08:39
rburtonanyway, should have been gtk+08:39
lpappwhat is the benefit of a qt frontend anyway08:40
lpapprburton: gtk is not cross-platform.08:41
bluelightningant_work: I could have written a qt frontend, it might have been qt2 though ;)08:41
lpappwhat do I need to check into the repostory for the downloads to work?08:55
lpappsstate-cache and tmp as well?08:55
*** belen <belen!~Adium@> has joined #yocto08:55
rburtonwhat are you trying to do?08:56
lpappas I wrote above, check downloads into the repository.08:56
rburtonjust the downloads directory then08:56
rburtontmp is where the builds happen, and will be giant and frequently changing08:57
rburtonand yes, sstate-cache is incredibly useful to share between multiple machines if you can.  that's not "downloads" though, but intermediate-stage build objects.08:57
rburtoni.e. compiled libraries it can use to build a sysroot from08:58
*** blitz00 <blitz00!~stefans@> has joined #yocto08:58
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto08:58
lpapprburton: we have some tmp committed already, and that is why I was wondering.09:02
lpappprobably I can remove it all.09:02
*** ftonello <ftonello!> has quit IRC09:03
*** ftonello <ftonello!> has joined #yocto09:03
*** wgao <wgao!~wgao@> has joined #yocto09:04
*** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.> has quit IRC09:07
lpapprburton: is that correct, then?09:11
lpappand I probably do not need "cache" either?09:14
lpappnor bitbake.lock?09:15
lpappwhat about pseudodone?09:16
ant_worklpapp: remove all the 3 above and tmp-09:17
ant_workI keep only downloads09:17
lpappant_work: why don't you keep sstate?09:17
ant_workI do prefer build from scratch09:18
ant_worksoemtimes I increase by hand the revision of my dev recipes09:18
ant_workso those would always be preferred09:18
ant_workand build from scratch just takes couple of hours09:19
lpappok, I will check in for now as is, and I can remove later.09:19
lpappthat is a lot09:19
lpappI build it within 40 minutes.09:19
lpappbut I use core-image-minimal09:19
ant_worklpapp: I build core-image-base and core-image-sato09:20
ant_workon rather old hw09:20
lpappthat makes sense, then.09:21
*** fray <fray!> has quit IRC09:21
ant_workon the last partition of the disk :/09:21
ant_worklpapp: build from sstate-cache takes just 5 mins09:22
lpappant_work: does that matter it is the last partition?09:22
lpappswap is already slow, no?09:23
ant_workit's never swapping, it's just the disk is slower on last part09:24
rburtonlpapp: pseudodone is the stamp that says its done building pseudo09:25
rburtonthe bitbake cache is a cache of the parse tree09:25
rburtonboth of which clearly shouldnt be persisted anywhere09:25
lpappant_work: any benchmark how much?09:27
lpapp(if any)09:27
rburtondepends on the disk etc etc09:27
ant_worklpapp: I can provide later09:27
*** roinn <roinn!~roinn@> has joined #yocto09:34
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto09:38
lpappant_work: k, please do not forget it as you got me curious. :-)09:39
*** eballetbo <eballetbo!> has quit IRC09:40
ant_worklpapp: I was obliged to keep Win$ on my hackintosh and it needed to be installed on first part of the second hdd09:40
ant_worklpapp: otherwise I'd set first partition of second disk for that09:40
ant_worklpapp: before you ask: raid is not an option in my case...09:41
*** ftonello <ftonello!> has quit IRC09:49
*** ftonello <ftonello!> has joined #yocto09:50
*** dRp3pP3r <dRp3pP3r!d5bf22ee@gateway/web/freenode/ip.> has joined #yocto09:51
dRp3pP3rhi everyone.09:51
dRp3pP3ri have some issues with inconsistent library dependencies09:51
dRp3pP3ron poky 9.0.109:52
lpappant_work: interesting.09:52
lpappant_work: it is not something I heard programmers talking about when optimizing stuff.09:52
ant_workwell, lets' hope HDD are the past ;)09:52
dRp3pP3rprecisely: libfm depends on and gtk.sato depends on
dRp3pP3rboth won't shut up when i feed them the other version09:53
dRp3pP3rand i don't know, how to modify the depends of libfm to be happy with .5109:54
dRp3pP3rwhich should work in practice, i think.09:54
dRp3pP3rcan someone tell me, whether this is a good idea, and if, how to modify this dependency?09:54
rburtondRp3pP3r: same problem as before, you need to rebuild libfm09:56
rburtonthat should have happened :(09:56
*** ErkiS <ErkiS!> has joined #yocto09:56
dRp3pP3rwell, tried so, but didn't work. btw: the solution didn't work for libtasn1 as well. i had to downgrade to libtasn1_3.2, which provides as needed by gnutls09:57
dRp3pP3ri mean
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto09:57
dRp3pP3r.6 is provided by libtasn1_3.309:57
*** Guest28477 <Guest28477!~tbn@> has quit IRC09:58
dRp3pP3rthe problem with icu is, that both versions are needed09:58
dRp3pP3rso downgrading is not an option this time...09:58
rburtonthe problem is that at some point you upgraded icu and libfm didn't rebuild09:58
rburton(or you've downgraded icu and gtk+ didn't rebuild)09:59
dRp3pP3rok, makes sense, than a rebuild should solve.09:59
dRp3pP3rgive me a minute, it's working :)10:00
*** belen <belen!~Adium@> has quit IRC10:00
*** ErkiS <ErkiS!> has left #yocto10:05
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:05
lpapprburton: unsubscribed from oe. If you need me, cc.10:05
*** pev <pev!~pev@> has joined #yocto10:07
*** ErkiS <ErkiS!> has joined #yocto10:08
lpappbtw, I had a question this morning about local tarballs.10:11
*** dRp3pP3r_ <dRp3pP3r_!d5bf22ee@gateway/web/freenode/ip.> has joined #yocto10:11
*** dRp3pP3r <dRp3pP3r!d5bf22ee@gateway/web/freenode/ip.> has quit IRC10:13
dRp3pP3r_rburton: you were right. that worked.10:15
dRp3pP3r_thanks. :)10:15
rburtondRp3pP3r_: would love to know why these rebuilds are not happening automatically. what release are you using?10:16
dRp3pP3r_todays snapshot of master for both, poky and oe10:16
rburtonhuh, *really* should work then10:16
*** belen <belen!~Adium@> has joined #yocto10:16
dRp3pP3r_hm. git-pulled them two hours ago.10:17
dRp3pP3r_do i see it correctly, that the root of the problem is a lower-level library is updated, but some libraries that depend on further mentioned lib don't. so they get their depends messed up?10:18
lpappany ideas?10:27
rburtonlpapp: sorry, missed the question.10:27
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.> has joined #yocto10:27
rburtondRp3pP3r_: that normally happens if the packages don't include the dependencies, so check that. gnutls/tasn i'm pretty sure do though.10:27
rburtonant_work: ?10:28
rburtonant_work: oh god what's that do_compile_append doing. i'm scared to look.10:28
rburtonlpapp: yes10:28
rburtonSRC_URI is a list of stuff10:28
dRp3pP3r_ok. include the dependecies? what do you mean?10:28
rburtonlocal, git, http, whatever.10:29
rburtondRp3pP3r_: the DEPENDS field. should be working for the packages you're seeing problems with though. :(10:29
ant_workrburton: I guess the right one is openembedded-core/tree/meta/recipes-support/icu/icu.inc10:29
simon_bHow can I bring header only recipes into an image?  I tried with glm, and when adding glm-dev to a packagegroup it complaints: "Can't install glm-dev- no package provides glm ="  which is true, but there won't be a library or so..10:29
dRp3pP3r_rburton: hm. ok. for now it works. if i come across such stuff again, i'll further investigate. thanks a lot.10:30
simon_bThinking about a fake package. is there a better way?10:30
rburtonsimon_b: RDEPENDS_${PN}-dev = ""10:30
rburtonsimon_b: a -dev package by default depends on the "main" package, but you don't want that10:31
simon_brburton: thank you. trying that.10:31
dRp3pP3r_rburton: libfm does not depend on libicu, according to libfm_1.1.0.bb10:31
rburtondRp3pP3r_: probably something else does, and that should have got rebuilt.10:32
dRp3pP3r_but gnutls does depend on libtasn1, yes10:32
dRp3pP3r_anyway, have a nce day :)10:32
*** dRp3pP3r_ <dRp3pP3r_!d5bf22ee@gateway/web/freenode/ip.> has quit IRC10:32
*** mulhern <mulhern!> has joined #yocto11:08
lpapprburton: is there any example out there?11:24
*** fray <fray!> has joined #yocto11:28
*** Crofton|work <Crofton|work!> has quit IRC11:47
rburtonlpapp: of using a tarball in SRC_URI? just use a file: url.11:49
lpapprburton: yes, any existing example would be welcome.11:49
lpapprburton: yeah, and where to put the file actually ...11:49
rburtonsame rules as patches11:49
rburtonso files/ or PN/ or PN-PV/11:49
rburtonthere is literally no difference as far as the fetching logic is concerned here11:50
rburtontarballs get extracted, patches get applied11:50
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto11:54
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto11:59
*** vicky_ <vicky_!~vicky@> has quit IRC12:07
*** melonipoika <melonipoika!> has quit IRC12:23
*** Crofton|work <Crofton|work!> has joined #yocto12:28
*** behanw <behanw!> has joined #yocto12:31
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC12:35
*** elmi82 <elmi82!> has quit IRC12:36
*** zeeblex <zeeblex!~apalalax@> has left #yocto12:46
*** ErkiS <ErkiS!> has quit IRC12:49
*** vicky <vicky!~vicky@> has quit IRC13:05
*** smartin_ <smartin_!~smartin@> has joined #yocto13:08
*** acidfu <acidfu!~nib@> has joined #yocto13:10
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto13:10
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto13:11
*** mitz <mitz!> has quit IRC13:12
*** mitz <mitz!> has joined #yocto13:14
*** ErkiS <ErkiS!> has joined #yocto13:17
ErkiShow can I conveniently get all build-essentials RPMs installed onto my target host (Gumstix Overo)? tracking down each required dependent RPM seems hopeless..13:18
otaviokhem: gcc fix looks good :)13:25
bluelightningErkiS: I mentioned this yesterday - packagegroup-core-buildessential will pull in all the necessary packages13:29
*** simar <simar!~simar@> has quit IRC13:30
*** simar <simar!~simar@> has joined #yocto13:31
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mvsurvaccwlrwfck> has joined #yocto13:33
ErkiSbluelightning, I also answered yesterday :) - getting ERROR: Nothing PROVIDES 'packagegroup-core-buildessential'13:34
bluelightningErkiS: which version of the build system are you using?13:34
*** smartin_ <smartin_!~smartin@> has quit IRC13:35
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC13:35
*** mihai <mihai!~mihai@> has quit IRC13:36
ErkiSbluelightning - not sure how to check this? last git commit is 2806646a263527ec0487ea160afd4bdc0a3c170313:37
bluelightningErkiS: ah, that's in danny (1.3)... packagegroup-core-buildessential wasn't added until the release after i.e. dylan (1.4)13:40
bluelightningErkiS: it's a pretty trivial recipe though, you could just add it on top13:40
ErkiSthank you, will try :)13:41
bluelightningErkiS: apologies for missing your reply yesterday13:41
ErkiSno problemo13:43
ErkiSdo I need to configure the target system in some way as well? the resulting RPM is tiny and doing "rpm -ivh packagegroup-core-buildessential-1.0-r0.all.rpm" complains about a number of missing dependencies13:45
lpappok, so bitbake can handle .tar.xz13:47
lpappis it a good practice to have one .bb per recipe?13:48
lpappI mean one type of .bb (might be separate version variants)13:48
bluelightningErkiS: erm, rpm doesn't automatically install dependencies13:48
lpappbecause u-boot is going against that principle for instance.13:48
bluelightninglpapp: yes, I noted that when we discussed this previously13:49
bluelightninglpapp: I don't know why that is13:49
lpappis it a good practice13:49
bluelightningthe convention is to just have one unless there is a bleeding edge git or old gplv2 version13:49
lpapperr... I think you are misunderstanding the situation.13:50
lpappI do not refer to the versions at all, I think that is fine.13:50
lpappwhat is not fine is foo.bb13:50
lpappfoo-bar.bb13:50, etc.13:50
bluelightningright, and if you recall I explained why at least one of these additional ones is needed13:50
ErkiSbluelightning, so back to my original question - how can I *conveniently* get all required RPMs installed? :)13:51
ErkiSI tried installing all listed dependencies one by one, until I ran into an absurd circular dependency where perl-module-carp depends on perl-module-exporter, which depends on perl-module-exporter-heavy, which depends on perl-module-carp and perl-module-exporter13:51
lpappbluelightning: that is irrelevant13:51
bluelightningErkiS: in danny we provided zypper as a front-end to resolve and install dependencies13:51
bluelightninglpapp: no, it isn't13:51
lpappthe question is, whether or not it is a good practice.13:51
bluelightninglpapp: it's pretty much required, because you want to build the mkimage tool for the host (native) and the actual bootloader for the target13:52
lpappbluelightning: you could you different recipe folders, really.13:52
ErkiSbluelightning: aha, so I should upgrade my yocto. is 1.3 -> 1.4 upgrade painless?13:52
lpappErkiS: depends, for me, it is not.13:53
lpappit is painful.13:53
bluelightninglpapp: we'd rather keep u-boot derived recipes in the same folder; there are plenty of other examples where we do the same thing13:53
lpappbut I use external toolchains, etc.13:53
bluelightningErkiS: as noted, in 1.4 we moved from zypper to smart, but largely the same functionality is provided13:54
* lpapp does not understand the smart thingie13:55
ErkiSbluelightning: ah, sorry, I misread you. so if I install zypper, that should help me installing the rest?13:56
lpappwhat about opkg13:57
JaMaopkg has new maintainer :)13:58
bluelightningErkiS: it should yes13:58
bluelightningJaMa: I did not hear that news...?13:59
lpappI mean that is probably the best for embedded?13:59
bluelightninglpapp: typical embedded applications, if you need a package manager at all, yes13:59
ErkiSbluelightning: unfortunately, zypper is telling me that 'gumstix' and 'Angstrom' repositories are invalid (File '/repodata/repomd.xml' not found on medium '')14:00
JaMabluelightning: Paul Barker volunteered on opkg-devel ML and is now merging pending patches14:00
bluelightningJaMa: great, that is very good news14:00
bluelightningat some point I was subscribed to that list, not sure why I'm not anymore...14:00
lpappit did not have a maintainer?!14:01
bluelightningthe last maintainer wasn't really active over the last few years no14:01
bluelightninghe did do quite a lot of work on it before then though14:01
JaMaI got couple of patches (all from oe-core) merged few months ago, but there was no development and no plans for new release14:02
bluelightningmostly it just works; but there are a few rough edges... the libopkg API rework never got properly finished for example14:03
lpappit is written in c. :(14:04
lpappwhy is it better than other package managers14:08
lpappwhat makes it minimal14:08
* lpapp used to hav a package manager written in qt14:08
rburtonJaMa: oh that's excellent news.  i wonder if he'll fill in all the TODO bits ;)14:12
rburtonlpapp: vastly less memory usage is the main reason14:12
lpappI also wonder if it is that good, why it is not the default for Yocto.14:12
lpapprburton: ?14:12
lpappless memory usage means less stuff to deal with I guess?14:12
lpappbut is that really good?14:12
rburtonmore like it is designed to use a little ram, instead of apt which assumes it can just fill ram with everything14:13
rburton(and thus can't be used on systems with low ram)14:13
rburton(ditto rpm)14:13
lpappnot sure what that means.14:13
rburtonof course if you're not putting the package manager on the target itself, then it doesn't matter.14:14
*** JaMa is now known as JaMa|Off14:14
lpappdu -sh `which pacman`14:15
lpapp108K    /usr/bin/pacman14:15
lpappI would call that lightweight.14:15
lpappand pacman is designed to use very small amount of RAM, too.14:15
lpappso again, why did we need opkg?14:15
*** tstableford <tstableford!5221da4a@gateway/web/freenode/ip.> has joined #yocto14:15
rburtonlpapp: because pacman didn't exist when opkg was written.14:16
lpapp| POD document had syntax errors at /usr/bin/core_perl/pod2man line 71.14:16
lpapp| make: *** [install_docs] Error 114:16
lpapp| ERROR: oe_runmake failed14:16
rburtonat the time opkg was written, both rpm and dpkg would OOM on the typical target14:16
lpapp| ERROR: Function failed: do_install (14:16
lpapprburton: are you actually sure14:16
tstablefordHello yocto community. I've read that yocto has systemd support but I can't find any documentation on how to enable it. Could anyone point to some instructions or throw me some hints?14:16
lpapppacman started very early.14:16
lpappat least 7-8 years ago14:17
lpappsorry, 11.514:17
lpappwhen 1.0 was released.14:17
lpappso probably 12-13 years ago when it started.14:17
rburtonif i'm wrong then i'm sorry, i wasn't around when opkg was created.14:18
rburtonif you want to write a layer to use pacman, go for it14:18
rburtonyou can do that in a standalone layer no problem14:18
lpappI do not feel the need for opkg, personally.14:19
lpappif there had been a project with such goals in mind, already.14:19
rburtondon't use it then14:20
rburtonlinux is about choice :)14:20
lpappit has to have some project mission which differs from pacman14:20
lpapppacman has been written in C, as well.14:20
*** eren <eren!~eren@unaffiliated/eren> has quit IRC14:20
lpapprburton: it is not about that.14:20
lpappI just dislike when I see projects reinventing the wheel.14:20
rburtonlpapp: welcome to the other side of "choice"14:20
*** yzhao2 <yzhao2!~yzhao2@> has quit IRC14:21
rburtonin yocto *right now* there is rpm, deb and opkg.  deb doesn't work that great.  some people demand rpm, some people refuse rpm, so use opkg.14:21
lpapphow can I disable the doc generation globally?14:21
rburtonif you want to write a pacman layer and prove how great it is, then do so.14:21
lpapprburton: write a layer for an unsupported OS? Nice joke.14:22
lpapppeople would associate pacman with arch.14:22
rburtonlpapp: so why are we discussing this then?  it sounded like you wanted to use pacman.14:22
lpappand if they see, arch is banned, they would not use pacman.14:22
lpappso then what is the point really if it gets no users.14:22
lpapprburton: no14:22
lpapprburton: I wanted to understand the existence of opkg14:23
lpappI still do not understand though. :)14:23
bluelightninglpapp: opkg has many users; it's in use not just by OpenEmbedded but also by OpenWRT and other unrelated projects14:23
lpappso, how can I ban doc for Yocto?14:24
bluelightninglpapp: it derives from ipkg which has been around since 2002 and possibly earlier14:24
lpappbluelightning: but _why_ was it born in the first place when there was such a project with such a goal in mind?14:24
tstablefordthanks bluelightning14:24
rburtonlpapp: what recipe, and what release?14:25
bluelightninglpapp: I don't know, perhaps you can ask florian ;)14:25
lpapprburton: all14:25
rburtonlpapp: re-phrase your question: why was pacman born when dpkg/rpm/ipkg/more already existed?14:25
rburtonlpapp: "because" is the usual answer14:25
rburtonbecause each one considers itself "better" by some metric14:26
lpapprburton: because it is lightweight14:26
lpappmeant for a very thin system14:26
lpappit has a lot better design.14:26
lpappand it does not have a bloated interface.14:26
lpappand it is a lot easier to deal with for packagers14:27
lpappand it was also fully community driven.14:28
lpappanother try: how can I disable the docs?14:28
lpappfully and globally for yocto14:29
bluelightninglpapp: there is no such global switch, that I know of14:29
lpappso there is another build failure in dylan, then.14:30
lpappwhich I cannot even disable. :(14:30
bluelightningwe have disabled documentation for some troublesome recipes on an individual basis14:30
lpappplease do that for openssl as well.14:30
lpappyeah, why on earth did it not make it into dylan sigh14:31
bluelightningit's in the dylan branch already, queued for 1.4.214:32
lpappyeah for ages14:33
lpappso it is useless for dylan users.14:33
bluelightningor not, as the case may be14:33
lpappsure, I should wait here sitting for weeks14:34
lpappor months for it to get released.14:34
rburtonlpapp: have you considered tracking the dylan git branch?14:35
*** ant_work <ant_work!> has quit IRC14:36
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto14:38
lpappanyway, this sounds like a new feature request14:40
lpappI would like to be able to say that I do not wanna any kind of docs.14:40
lpappand that is globally... it is an embedded board... doc would make no sense.14:40
lpappworst case scenario a local.conf entry.14:41
rburtonlpapp: the docs won't get installed unless you ask for them14:41
rburton(doc-pkgs image feature)14:41
lpappI do not wanna _build_ them,even.14:41
rburtonpotentially useful in sdk builds though14:41
lpappwhy would I build them if I do not wanna install them?14:41
lpappand have no any intention to use them.14:41
*** tstableford <tstableford!5221da4a@gateway/web/freenode/ip.> has quit IRC14:42
*** yzhao2 <yzhao2!~yzhao2@> has joined #yocto14:48
*** mulhern <mulhern!> has quit IRC14:52
*** ErkiS <ErkiS!> has left #yocto14:53
* rburton cheers at sstate14:53
*** andyross <andyross!> has joined #yocto14:57
*** munch <munch!> has joined #yocto15:03
*** Jefro <Jefro!> has joined #yocto15:06
*** zenlinux <zenlinux!> has quit IRC15:13
lpappERROR: Function failed: bar: LIC_FILES_CHKSUM points to an invalid file: /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/tmp/work/armv5te-foo-linux-gnueabi/bar/0.1-r0/bar-0.1/COPYRIGHT15:33
lpappwhy is it like that?15:33
lpappI have the COPYRIGHT in PN15:33
lpappis it mandatory to have do_make/install sections?15:36
*** roinn <roinn!~roinn@> has quit IRC15:36
rburtonthere are defaults in base.bbclass, so effectively no15:37
lpapphow can I avoid that error?15:37
rburtonpresumably your LIC_FILS_CHKSUM is wrong15:38
rburtonyou may want to use ${WORKDIR} if the path is wrong15:39
lpappbut it does not suggest any correct.15:39
rburtoni.e. if you use a relative path, it uses ${S} as the root15:39
lpappI have been told PN, files, etc are looked up by default.15:39
rburtonthey are15:39
rburtonand the fetch/unpack worked15:39
rburtonbecause LIC_FILES_CHKSUM happens after that15:40
lpappso why would I need WORKDIR then?15:40
rburtoni'm entirely guessing because you're not giving any context15:40
lpappcontext is simply file://COPYRIGHT15:41
lpappnothing magical.15:41
rburtonand the file isn't at the path it says its looking at?15:41
lpappI wonder why I need the WORKDIR15:41
*** hollisb <hollisb!> has joined #yocto15:41
lpappit works without that for SRC_URI15:41
rburtonso your LIC_FILES_CHKSUM has just file://COPYRIGHT in a LIC_FILES_CHKSUM,?15:41
lpappwhy do I need for the other one?15:41
lpappwithout WORKDIR15:41
rburtonthat's a relative path, so the implicit base is $S15:42
rburtonwhich is WORKDIR/PN-PV by default15:42
rburtonwhich is why its looking where it's looking15:42
rburtonbut that's not where the file went15:42
rburtonso your LIC_FILES_CHKSUM needs to be file://${WORKDIR}/COPYRIGHT15:42
rburton(because it's not in $S, which is the default)15:43
rburtonlpapp: did that help?15:45
Garibaldi|workHum... anyone know why when I try to run bitbake, I get stuck at "Parsing recipes: 99% |#...| ETA: 00:00:00"15:47
Garibaldi|work(this is w/ danny)15:48
Garibaldi|workand I end up with a couple of zombie python processes15:49
*** mulhern <mulhern!> has joined #yocto15:49
lpapprburton: I think it would be simpler if we did not always need to put WORKDIR in there.15:50
rburtonGaribaldi|work: huh.  try deleting build/cache15:50
rburtonlpapp: needing WORKDIR puts you in the 1% of recipes15:50
rburton99% of the time, you're checksumming a file in an extracted tarball15:50
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC15:50
rburtonwhich is why the root for relative paths is $S15:50
lpapprburton: all our custom files are like this though.15:50
rburtonlpapp: that's fine, use ${WORKDIR}15:50
lpappI would not like to, in the future15:51
rburtonthe alternative is to use ${WORKDIR} as the default, and fix 728 mentions in oe-core15:51
*** jackmitchell <jackmitchell!> has quit IRC15:52
Garibaldi|workrburton: didn't help :-(15:52
rburtonlpapp: there has to be a default root for relative paths, and the one that works for 700 mentions is preferable to the one that works for about 9 mentions15:52
lpapprburton: I think there should be an in-between solution.15:52
rburtonGaribaldi|work: huh15:52
lpapprburton: btw, if I do not use do_compile/install15:52
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC15:52
lpappapparently nothing gets built. :(15:52
lpappeven though the default "make" should be fine!15:52
rburtonlpapp: the default do_compile will run make if it can find a normal makefile15:53
rburtonlpapp: but you'll need to install yourself still15:53
lpapprburton: I do not even find a binary in the work dirt.15:54
rburtonlpapp: check the log, it will either show you it running make, or saying "nothing to compile"15:54
sgw_lpapp: Almost all open source projects that provide a LICENSE or COPYING file have that file reside in the "top-level" of their source tree, which is ${S} in oe-core, therefore our default lookup path for the LIC_FILE_CHECKSUM is to be relative to ${S}15:54
rburtonlpapp: if that happens then it couldn't find the makefile15:54
lpappsgw_: yes, so?15:55
rburtonlpapp: (base.bbclass has the default functions)15:55
lpappsgw_: I would like to have the option to simplify my job.15:55
lpapprburton: where is the log file?15:55
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto15:55
rburtonlpapp: workdir/temp/15:55
kergothheh, I hate our automatic "magic" we put in place to try to keep recipes small. it would have been better to have the base bbclass do_compile error out indicating hte user has to do something, and then add a make class, then it'd at least be explicit, and you woudln't get into a case where oyur software didn't build, but do_compile succeeded, and no package is produced15:56
kergothoh well, a bit late to do much about that15:56
rburtonkergoth: i've long suspected a "make" class is needed15:56
lpapprburton: yeah, but which file?15:56
*** zenlinux <zenlinux!> has joined #yocto15:56
kergothour default EXTRA_OEMAKE is anothe rpet peeve of mine, even though i'm the one that created it15:56
kergoththe -e stuff is.. ugh15:57
rburtonlpapp: the log files are the ones called "log.*".  then the name reflects the task that was running.15:57
lpapprburton: no compile task.15:58
lpapplog.do_cleanall           log.do_cleanall.17386     log.do_cleansstate        log.do_cleansstate.17385  log.task_order            run.do_cleanall.17386     run.do_cleansstate.1738515:58
rburtonmight be best to see your recipe then15:59
lpapprburton: nothing after SRC_URI16:00
lpappas the usual make && make install is sufficient.16:00
lpappI should have no code for default stuff.16:00
rburton"make install" isn't "usual", so you'll have to code that16:00
rburtonas i said, see base.bbclass for the defaults.16:00
lpappthat sounds bad16:00
rburtonno, it doesn't16:00
lpappyes, it does.16:00
lpappactually any package manager I have used managed to put everything into the package by default.16:01
lpappwithout explicitly specifying.16:01
lpappYocto is the first weird stuff not following that.16:01
* rburton shrugs16:02
lpappsounds like a feature request.16:02
lpappan important one.16:02
rburtondpkg doesn't by default.  if you tell it you're using "automake" it will.16:02
rburtonjust like oe16:02
lpappdpkg actually does.16:03
rburtonlpapp: there isn't a universal way of doing re-rooted installs, so there really isn't much point16:03
lpappthere is much point.16:03
lpappto avoid the boilerplate hell.16:03
rburtonone line.16:03
*** TuTizz <TuTizz!~TuTizz@> has quit IRC16:03
*** darknighte_znc is now known as darknighte16:03
lpappit does not matter how many.16:03
rburtonanyway, kernels to kick16:03
lpappif it can be automated, it should be.16:03
lpappalso, even compile does not work off-hand. :(16:04
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-afqhaidaspnalmvo> has quit IRC16:04
lpappwhat boilerplate do people need to put into do_compile to do the default stuff?16:05
* lpapp is currently blocked due to this16:08
rburtonthe default do_compile calls make. you can see the logic in base.bbclass.16:08
lpappwhy is it not working then?16:08
kergoththe most common cause of do_compile doing nothing when you have a makefile is having S set incorrectly (or the default doesnt match reality), or you're trying to build something autotools and forgot to inherit autotools, so no makefile was created16:09
lpapphow can I get more verbose stuff from bitbake for this?16:10
*** davest1 <davest1!Adium@nat/intel/x-sewolfxavaofqzbi> has joined #yocto16:10
lpapptemp/ is useless16:11
lpappand temp/../foo/ is empty.16:11
lpappwow, COPYRIGHT files have different checksums, as in really?16:12
kergoththat reminds me, we shouldn't be auto-creating S if it doesn't exist. better to fail uot with a 'this path we looked for doesn't exist, aiee' than to create and use an empty directory, and end up doing nothing quietly16:12
lpapp"No generic license file exists for: Propriate in any provider" -> what is this warning?16:13
lpappbitbake foo -c cleanall -> does not rebuilt it either.16:14
lpappwhat is going on? o_O16:14
lpappso what more can I do?16:16
lpappif I run make on the host, it just works16:16
lpappdoes it uncompress the tar.xz at all?16:17
lpapphow can I make sure?16:17
bluelightninglpapp: look in the workdir?16:17
lpappwhat do you think I have been doing?16:17
bluelightninglpapp: what do you have in there?16:18
lpappsee above, nothing, really.16:18
lpappan emptyfolder and a few useless temp/ entries.16:18
lpappempty folder*16:18
lpapptar.xz is not supported?!16:18
bluelightningkind of sounds like it has not been unpacked16:19
lpappwhy does it not support .tar.xz?16:20
lpapptar xvpf just uncompresses it fine.16:20
lpappand even if it does not support that, shouldn't it complain?16:21
lpappalso, why do I get a license warning here and not for other packages with the exactly same COPYRIGHT file?!16:23
lpappthis is all chaotic. :-)16:23
bluelightninglpapp: it most certainly does support tar.xz; if you look you'll see a number of recipes that point to tar.xz files16:24
bluelightninglpapp: the license warning is based upon the value of LICENSE not LIC_FILES_CHKSUM16:24
*** Jefro <Jefro!> has quit IRC16:24
*** blloyd <blloyd!> has joined #yocto16:27
*** francois99 <francois99!> has quit IRC16:27
*** roric <roric!> has quit IRC16:28
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:40
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC16:45
blloydIs there a way to specify one file that should not be stripped?  without either debug symbols for or an unstripped copy of libthead_db.1.so16:46
blloydcore files from a system are highly likely to not be able to get all thread information.16:46
blloydPlace that file on the end system and all crash dumps are able to be debugged in all threads.16:47
mr_sciencehave you tried installing the debug package?16:47
mr_scienceie, foo-dbg for whatever you're trying to debug...16:47
*** Crofton|work <Crofton|work!> has quit IRC16:48
blloydOf course the system debugging the crash has the debug symbols.  The system producing the core (think end user crash dump analysis) seems to also need that one file.16:48
mr_scienceand what you need isn't in another -dbg package?16:49
lpappbluelightning: I looked yesterday, however that is the only reason I can come up with.16:50
mr_scienceotherwise i think it would take some jiggering of the recipe16:50
blloydSeems it is a problem with the way threading is done.  However, without an unstripped version of that file ulimit -c unlimited and then sftping the resulting core when the dump is seen ends up with a dump with only one thread.16:50
lpappbluelightning: but you are of course more than welcome to suggest alternative bug options.16:50
bluelightninglpapp: without seeing the recipe itself I can't tell what might be going on16:50
blloydmr_science, so are you saying install the debug symbols on the system doing the debugging or install them on the end device?16:51
lpappbluelightning: I pretty much pasted the recipe here already.16:51
*** fgretief <fgretief!> has joined #yocto16:51
*** Crofton|work <Crofton|work!> has joined #yocto16:51
mr_scienceblloyd: in some case it seems like you need both16:51
lpappLICENSE = "Propriate"16:51
lpappwhat should that contain instead?16:51
mr_sciencethough i am not the remote debugging expert...16:51
bluelightninglpapp: "Proprietary" or "CLOSED"16:52
bluelightninglpapp: note that CLOSED will completely disable LIC_FILES_CHKSUM16:52
mr_sciencestill need to work through and document some of that stuff for our current classic build...16:52
lpappbluelightning: too bad it is not documented.16:53
bluelightninglpapp: it was last I checked16:53
blloydit's a limitation of gcc, and it's dealing exclusively with the file.  gcc can't use a copy that doesn't have symbols available.16:53
mr_scienceblloyd: see if installing the -dbg packages to your (non-target) sysroot does what you need16:53
lpappbluelightning: not in the reference, nor in the development manual.16:53
bluelightninglpapp: yep, in the reference manual in two separate places16:53
lpappnot in the current.16:53
blloydit doesn't.  I already have the dbg symbols16:54
bluelightninglpapp: yep16:54
mr_scienceblloyd: in both places?16:54
bluelightninglpapp: Specifying the LIC_FILES_CHKSUM Variable and the variable glossary entry for LIC_FILES_CHKSUM16:54
lpappbluelightning: not in the current, no.16:54
bluelightninglpapp: yes in the current16:54
*** panda84kde <panda84kde!> has quit IRC16:54
lpappbluelightning: nope16:54
lpappcould you please show where Proprietary is mentioned?16:55
lpappI must be blind.16:55
blloydfor everything.  For target, I can add the single file.  Already discussed with gcc group.  Basically, they suggest putting the symbols back into that file.16:55
lpappbluelightning: I do not see the word there.16:55
lpappcan you paste the sentence?16:55
bluelightninglpapp: Proprietary isn't but then there's not any special behaviour associated with it16:55
blloydThus my question: is there a way to say don't strip this file?  I missed it if there is.16:55
mr_scienceblloyd: then it sounds like you need a new recipe to build/install an unstripped version16:55
bluelightninglpapp: unlike CLOSED16:55
lpappbluelightning: then why do you recommend something without special meaning?16:56
lpappI need a special meaning.16:56
mr_scienceblloyd: yes there is, but i don't think it soes just a single file16:56
lpappclearly, Propriate and Proprietary are not the same, so some special meaning has to be there.16:56
lpappsounds like a bugreport entry.16:57
blloydrecipe wide, or PACKAGES wide?16:57
bluelightninglpapp: I assumed that "Propriate" was a mistake and what was meant was "Proprietary"; which happens to be a convention that some use16:57
mr_scienceyou can specify nostrip in a recipe, not sure if there's a way to nostrip a single lib16:57
lpappalso, how can I debug the uncompression issue?16:57
bluelightninglpapp: I'd be looking at log.do_unpack16:57
bluelightninganyway I have to go in about 5 seconds16:57
mr_scienceblloyd: one sec, looking at the busybox recipe16:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:59
lpappblloyd: there is nothing like that.16:59
lpappblloyd: sorry about that.17:00
lpapprburton: what can I check in for the CI to have the proper bblayers.conf thingie?17:00
lpappwithout our own layer, there was nothing to be checked in before, and that made the CI generate correct stuff.17:00
lpappbut we cannot use default anymore.17:00
lpappand my checked in layers conf is well ... /home/lpapp/etc... :)17:00
mr_scienceblloyd: try this17:03
mr_sciencein the recipe use PACKAGE_STRIP = "no"17:04
lpapprburton: some bitbake variable to the conf path?17:04
lpappor at least to the build folder path?17:04
lpappmr_science: hi, how are you17:04
lpappmr_science: what is the situation with nginx17:04
mr_scienceyou could try PACKAGE_STRIP_package-name = "no" and package that single file separately17:04
mr_scienceseems kinda weird to have to do that, so maybe i'm missing something...17:05
mr_sciencelpapp: haven't had a chance to build it yet, but hopefully i'll have a working version in my rpi layer this weekend17:06
Garibaldi|workgah, sorry17:07
mr_sciencelooking for vorlons?17:07
mr_sciencelpapp: i'll do it as a single commit so it should be easy to cherry-pick, format a patch, etc17:09
*** belen <belen!~Adium@> has quit IRC17:11
*** seebs <seebs!~seebs@> has quit IRC17:11
*** belen <belen!Adium@nat/intel/x-bhnfunwchnwyoyzf> has joined #yocto17:13
*** seebs <seebs!~seebs@> has joined #yocto17:15
lpappmr_science: I wanted to do it today.17:17
lpappmr_science: but if you can do it this weekend, that is better.17:17
lpappI can concentrate on other stuff. :p17:17
mr_scienceyeah, i gotta make an upgrade and re-release our hardware test image17:17
lpappgood luck to that.17:18
mr_scienceso tomorrow is way better for that stuff...17:18
lpapptake your time.17:18
lpappI will not do anything at the weekend other than playing music anyway. :)17:18
mr_sciencei need to put on some new strings17:19
mr_sciencethanks for reminding me i have more stuff to do...  ;)17:19
mr_sciencenothing else before coffee tho...17:19
mr_scienceyeah, i haven't done much lately but i bought a used ovation from one of the quality guys17:20
*** belen <belen!Adium@nat/intel/x-bhnfunwchnwyoyzf> has quit IRC17:23
lpappanyone here knowing if there is a bitbake variable holding the path to the build folder or the config folder in the build dir?17:24
lpappto put that into bblayers.conf17:24
lpappor even the poky project root, etc?17:24
lpappso that it can work on any machine after a checkout?17:24
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC17:24
*** darknighte <darknighte!> has joined #yocto17:28
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto17:28
*** ericben <ericben!> has quit IRC17:29
lpappis there a page somewhere with the bitbake variables?17:29
lpappof course I could use $PWD/../../meta-foo or so, but $PROJECT_ROOT/meta-foo would be neater17:30
*** belen <belen!~Adium@> has joined #yocto17:30
*** pidge_ <pidge_!> has joined #yocto17:30
lpappsgw_: thanks.17:33
lpappI actually think that mentioning a path is pretty useless in there.17:33
lpappwhy doesn't it just take the meta-foo stuff?17:33
lpappit is very unlikely people will refer outside poky...17:33
*** belen <belen!~Adium@> has quit IRC17:34
lpappThis variable is the Build Directory. BitBake automatically sets this variable. The OpenEmbedded build system uses the Build Directory when building images.17:40
lpappthis is almost good, but it would be nice to get the one upper, i.e. projectroot.17:40
*** phdeswer_ <phdeswer_!> has joined #yocto17:43
lpapp${TOPDIR}/../meta -> so, that is the best I can come up with, but it is still ugly. :-)17:45
mr_sciencedid i say that out loud?17:54
lpappI would even claim that if I do not specify a path, it should pick up from the "default".17:54
lpappthe oe script will know what the project root is after all.17:54
*** phdeswer_ <phdeswer_!> has quit IRC17:57
*** zenlinux <zenlinux!> has quit IRC18:00
*** slaine <slaine!~slaine@> has quit IRC18:08
*** zenlinux <zenlinux!> has joined #yocto18:08
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:11
Garibaldi|workrburton: I'm still stuck on this problem with bitbake hanging on 'parsing recipes' at 99% with 00:00:00 remaining18:21
Garibaldi|workI threw --verbose and a few -Ds in there, and the last thing I see is DEBUG: BB .../ inheriging .../core-image.bbclass18:22
Garibaldi|workI did see: DEBUG: while parsing populate_sdk_ipk, unable to handle non-literal command '${POPULATE_SDK_POST_HOST_COMMAND}'18:23
Garibaldi|workbut it's not clear to me that that's a failure18:23
Garibaldi|workand I get two python zombies that were once associated with the run18:25
Garibaldi|workand ctrl-C doesn't work18:27
Garibaldi|workI have to kill the python processes18:27
*** joeythesaint <joeythesaint!~jjm@> has quit IRC18:27
Garibaldi|work(or if anyone else has any ideas)18:30
Garibaldi|workhum, now I caused it and got no zombie processes18:31
Garibaldi|workbut all of the pythong processes are in a Sleep state18:31
Garibaldi|workS+ or Sl+18:31
blloydlpapp: just for your unlikely case.  I have a setup of parentdir/{poky,meta-mycompany,meta-testing}.  Note it is OUTSIDE the poky for reference to two metas.  I also put the build directory at /embeddedtmp, which is a separate disk, so TOPDIR has nothing at all in relation to the poky directory....18:35
blloydat should be under, oh, well.18:35
frayGaribaldi|work ya, I'e seen the same ctrl-c behavior in the past..18:36
frayit was being worked on at one point, but with Richard on vacation, I'm not sure how much it's being looked at right now..18:36
fraywe're also trying to track/reproduce another problem that looks like bitbake is just hanging (appears to be waiting forever for a socket)18:36
fraybut reproducing this is really difficult, and nothing we've done has been it reliably reproduced18:37
mr_scienceGaribaldi|work: master branch or another?18:39
*** Jefro <Jefro!> has joined #yocto18:48
Garibaldi|workthis is danny18:49
Garibaldi|workwhat's killing me is I can't find the commit in my local repo where it started failing18:49
Garibaldi|workit's almost like it's something external18:49
Garibaldi|workit doesn't always stop at the same place either18:51
Garibaldi|workat least in terms of the debug output18:51
Garibaldi|workI guess it could be related to there being multiple processes18:51
Garibaldi|worklet me try giving it just one process w/ one thread18:52
*** Jefro <Jefro!> has quit IRC18:52
*** swex__ <swex__!~swex@> has joined #yocto18:53
Garibaldi|workyeah, looks like it's still doing multithreading behind the scenes18:55
*** swex_ <swex_!~swex@> has quit IRC18:56
*** blloyd <blloyd!> has quit IRC18:58
frayahh, ya problems I'm having are all master18:58
*** blloyd <blloyd!> has joined #yocto19:00
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto19:03
*** otavio_ <otavio_!~otavio@debian/developer/otavio> has joined #yocto19:06
*** balister_ <balister_!> has joined #yocto19:08
*** khem` <khem`!> has joined #yocto19:09
mr_sciencei love our u-boot config...19:10
mr_scienceAutoboot in 1 seconds, type ctrl-C to interrupt19:10
mr_sciencegotta be quick...19:10
mr_scienceand no, i was not asked to grammar-check the output...19:11
*** pidge__ <pidge__!> has joined #yocto19:19
*** mulhern <mulhern!> has quit IRC19:20
*** pidge_ <pidge_!> has quit IRC19:20
*** zeddii <zeddii!~ddez@> has quit IRC19:20
*** khem <khem!> has quit IRC19:20
*** Crofton <Crofton!> has quit IRC19:20
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC19:20
*** jukkar <jukkar!jukka@nat/intel/x-yatttauwtthqpehh> has quit IRC19:20
lpappspeaking of which, my u-boot change did not enter the mailing list. :(19:22
lpappit is dropped after git send-email if I am not subscribed? :(19:22
*** blloyd <blloyd!> has quit IRC19:25
*** Jefro <Jefro!> has joined #yocto19:26
*** zeddii <zeddii!~ddez@> has joined #yocto19:26
*** mulhern <mulhern!> has joined #yocto19:30
* mr_science has found a new boot failure mode19:32
*** halstead <halstead!> has quit IRC19:34
*** jukkar <jukkar!jukka@nat/intel/x-qnwsfphmnmrlcmoe> has joined #yocto19:38
*** halstead <halstead!> has joined #yocto19:39
*** tor <tor!> has quit IRC19:43
*** Jefro <Jefro!> has quit IRC19:45
*** mulhern <mulhern!> has quit IRC19:49
*** Jefro <Jefro!> has joined #yocto20:01
*** nitink <nitink!~nitink@> has quit IRC20:09
*** silviof1 <silviof1!> has joined #yocto20:13
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto20:13
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC20:16
*** Jefro1 <Jefro1!> has joined #yocto20:24
*** fgretief <fgretief!> has quit IRC20:24
*** Jefro <Jefro!> has quit IRC20:24
*** nitink <nitink!nitink@nat/intel/x-nwyfqcsjnyvglesf> has joined #yocto20:30
*** bluelightning <bluelightning!> has joined #yocto20:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:36
*** darknighte is now known as darknighte_znc20:41
*** zecke <zecke!> has quit IRC20:45
*** nitink <nitink!nitink@nat/intel/x-nwyfqcsjnyvglesf> has quit IRC20:48
*** nitink <nitink!nitink@nat/intel/x-tapvxkrisanropre> has joined #yocto20:49
*** eren <eren!~eren@unaffiliated/eren> has quit IRC20:56
*** Umeaboy <Umeaboy!> has joined #yocto20:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC21:14
*** nitink <nitink!nitink@nat/intel/x-tapvxkrisanropre> has quit IRC21:20
*** ant_home <ant_home!> has joined #yocto21:22
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC21:23
*** davest1 <davest1!Adium@nat/intel/x-sewolfxavaofqzbi> has quit IRC21:25
*** nitink <nitink!nitink@nat/intel/x-wztahbxnknwicjys> has joined #yocto21:35
*** nitink <nitink!nitink@nat/intel/x-wztahbxnknwicjys> has quit IRC21:45
kergothhas anyone else notice bitbake responds terribly to ^C early on in the build process now that it restarts itself?21:46
kergothhangs up and i ahve to ^Z and kill %1 and pkill -f bitbake to clean up the mess21:46
seebsI have not been super happy with bitbake's ^C handling in general. I would, in general, prefer a best effort at "stop running now, that includes child processes". I virtually never want "please continue all the things you're doing now, just don't start new ones".21:48
kergothend up just hammering ^C until it goes away21:48
seebsAnd then there's still a ton of stuff running in the background, frequently.21:49
kergothwe've worked on it in the past, and changing the server to stop responding to ^C made things more deterministic, but the UI should do a better job of responding to it21:49
kergothwell, in the past bitbake itself did okay, but when it was spawned by the shell wrapper, it didn't always get the signal, in my experience21:49
* kergoth shrugs21:49
seebsBasically, I don't object to an interrupt handler trying to do some sort of cleanup, but the cleanup's priority should be "kill everything as fast as possible" more than "shut down gracefully over time".21:49
seebsAhh, that would make sense.21:49
kergothi had a script that called bitbake and tried to respond gracefully, i had to make the fscking thing try to forcibly kill it and every child it had open at hte time21:50
*** agust <agust!> has quit IRC21:50
kergothi should have checked advanced programming in the unix environment to freshen up though21:50
kergothseebs: heh, i think python's treatment of the signal as an exception is not ideal. what good is an exception that can show up anywhere, at any time? kind of a pain to handle without making it racey before / after the handled block21:53
kergothcourse, you can have the same concerns with a signal handler, so many it's not an issue, though its more common to 'handle and recover' from exceptions than from an exceptional signal :)21:53
* kergoth shrugs21:54
*** davest <davest!~Adium@> has joined #yocto21:55
seebsSignal handlers strike me as logically a genuinely global thing -- something where it makes sense to be able to specify at a high level that no matter what any other code thinks it might do with the signal, this code here gets it.21:56
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mvsurvaccwlrwfck> has quit IRC21:56
seebsBasically, exceptions arise from code execution and propagate up, signals arise externally and propagate down.21:56
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-qenztarvfnzrjblv> has joined #yocto21:57
kergoth generally you can only do certain things in a signal handler, its an entirely different context, hiding that behind a generic mechanism to cross that boundary seems questionable, if convenient21:57
kergothi think interruption of the initial bitbake psuedo build before its self restart seems to cause problems. it doesn't always stop the second build from running, as though something swallowed the interruption entirely21:58
* kergoth 'll have to open a bug21:58
*** hollisb <hollisb!> has quit IRC21:59
*** walters <walters!> has joined #yocto22:00
*** davest <davest!~Adium@> has quit IRC22:03
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC22:20
tlwoernerkergoth: if it's not too late to jump in on the signal handling topic... i think i would be nice if there were better handling for ^Z (SIGTSTP) too22:25
tlwoernerit would be nice if ^Z stopped the build immediately instead of the "keep doing what you're doing, just don't start anything new" behaviour (IMHO)22:25
kergothyou'd think itd propogate the stop down to its children22:29
tlwoernerfrom the cmdline it _looks_ like ^Z stops the build, but looking at the processes (and CPU usage) you can tell the current tasks are still working away22:35
* kergoth nods22:37
kergothat a guess, it stops the UI, since the UI is still attached to the tty, but the forked off server process continues along merrily22:37
* kergoth shrugs22:37
*** mulhern <mulhern!> has joined #yocto22:43
*** ant_home <ant_home!> has quit IRC22:44
*** seebs <seebs!~seebs@> has quit IRC22:56
*** Jay7 <Jay7!jay@> has quit IRC22:58
*** seebs <seebs!~seebs@> has joined #yocto23:01
*** Jay7 <Jay7!jay@> has joined #yocto23:03
*** andyross <andyross!> has quit IRC23:08
*** Umeaboy <Umeaboy!> has quit IRC23:34
*** nitink <nitink!~nitink@> has joined #yocto23:42
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-qenztarvfnzrjblv> has quit IRC23:47

Generated by 2.11.0 by Marius Gedminas - find it at!