Wednesday, 2014-10-15

*** seebs <seebs!~seebs@> has joined #yocto00:26
*** sjolley <sjolley!sjolley@nat/intel/x-aipeugouqkboqopt> has quit IRC00:32
*** nitink <nitink!~nitink@> has quit IRC00:59
*** seebs <seebs!~seebs@> has quit IRC01:07
*** nitink <nitink!nitink@nat/intel/x-yrczvdkeecxdcyar> has joined #yocto01:15
*** radhus <radhus!> has quit IRC01:29
*** jjardon_ <jjardon_!sid723@gateway/web/> has joined #yocto01:29
*** demonimin_ <demonimin_!> has joined #yocto01:29
*** demonimin_ <demonimin_!~demonimin@unaffiliated/demonimin> has joined #yocto01:29
*** kscherer_ <kscherer_!~kscherer@> has joined #yocto01:30
*** ipuustin_ <ipuustin_!~ipuustin@2002:591b:2160::1> has joined #yocto01:30
*** nslu2-log_ <nslu2-log_!~nslu2-log@> has joined #yocto01:30
*** radhus <radhus!> has joined #yocto01:31
*** seebs <seebs!> has joined #yocto01:31
*** kscherer <kscherer!~kscherer@> has quit IRC01:32
*** Ptishell <Ptishell!~surply_p@> has quit IRC01:32
*** hsychla__ <hsychla__!> has quit IRC01:32
*** ancky <ancky!~ancky@2a01:4f8:d12:1d05::2> has quit IRC01:33
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC01:33
*** jjardon <jjardon!sid723@gateway/web/> has quit IRC01:33
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC01:33
*** ipuustin <ipuustin!~ipuustin@2002:591b:2160::1> has quit IRC01:33
*** nslu2-log_ is now known as nslu2-log01:33
*** jjardon_ is now known as jjardon01:33
*** ancky <ancky!~ancky@2a01:4f8:d12:1d05::2> has joined #yocto01:33
*** Ptishell <Ptishell!~surply_p@> has joined #yocto01:35
*** radhus <radhus!> has quit IRC01:38
*** surply_p <surply_p!~surply_p@> has joined #yocto01:38
*** Calchan_ <Calchan_!> has joined #yocto01:41
*** Calchan_ <Calchan_!~calchan@gentoo/developer/calchan> has joined #yocto01:41
*** mago__ <mago__!> has joined #yocto01:42
*** Calchan <Calchan!~calchan@gentoo/developer/calchan> has quit IRC01:42
*** mago_ <mago_!> has quit IRC01:42
*** jmpdelos <jmpdelos!> has quit IRC01:42
*** ecdhe <ecdhe!> has quit IRC01:42
*** cbzx <cbzx!> has quit IRC01:42
*** Ptishell <Ptishell!~surply_p@> has quit IRC01:42
*** k-s <k-s!~gustavo@enlightenment/developer/k-s> has quit IRC01:42
*** smo <smo!> has quit IRC01:42
*** radhus__ <radhus__!> has joined #yocto01:42
*** k-s[WORK] <k-s[WORK]!> has joined #yocto01:42
*** k-s[WORK] <k-s[WORK]!~gustavo@enlightenment/developer/k-s> has joined #yocto01:42
*** radhus__ is now known as radhus01:42
*** ecdhe <ecdhe!> has joined #yocto01:44
*** smo <smo!> has joined #yocto01:46
*** Calchan_ is now known as Calchan01:46
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC01:48
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto01:50
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC01:53
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto01:53
*** jmpdelos <jmpdelos!> has joined #yocto01:53
*** sjolley <sjolley!sjolley@nat/intel/x-nklwghqciqvqornb> has joined #yocto01:53
*** wgao <wgao!~wgao@> has quit IRC02:16
*** wgao <wgao!~wgao@> has joined #yocto02:25
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto02:25
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC02:34
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto02:34
*** nitink <nitink!nitink@nat/intel/x-yrczvdkeecxdcyar> has left #yocto02:45
*** orkim_ <orkim_!~orkim@unaffiliated/orkim> has quit IRC02:45
*** nitink <nitink!~nitink@> has joined #yocto02:49
*** orkim <orkim!~orkim@unaffiliated/orkim> has joined #yocto03:18
*** michael_e_brown <michael_e_brown!> has joined #yocto03:31
*** surply_p <surply_p!~surply_p@> has quit IRC03:44
*** surply_p <surply_p!~surply_p@> has joined #yocto03:45
*** jkridner|work <jkridner|work!> has quit IRC04:07
*** rjv <rjv!3df6bac6@gateway/web/freenode/ip.> has quit IRC04:10
*** Crofton|work <Crofton|work!> has quit IRC04:20
*** Crofton|work <Crofton|work!> has joined #yocto04:33
*** nitink <nitink!~nitink@> has quit IRC04:35
*** rjv16 <rjv16!3df6bac6@gateway/web/freenode/ip.> has joined #yocto05:32
*** bhav <bhav!3df6bac6@gateway/web/freenode/ip.> has joined #yocto05:33
bhavHi all05:33
*** rjv16 <rjv16!3df6bac6@gateway/web/freenode/ip.> has quit IRC05:35
*** nitink <nitink!~nitink@> has joined #yocto05:36
*** RP <RP!> has quit IRC05:45
bhavI am getting some missing symbol error with GCC-4.4.2 which I have compiled using openembedded bitbake05:45
*** zecke <zecke!~ich@> has joined #yocto05:46
bhavPlease refer to link for more details05:46
*** TobSnyder <TobSnyder!> has joined #yocto06:17
*** nitink <nitink!~nitink@> has quit IRC06:19
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC06:21
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto06:24
*** mago__ is now known as mago_06:25
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC06:26
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto06:27
*** gvy <gvy!~mike@altlinux/developer/mike> has joined #yocto06:29
*** RP <RP!~richard@> has joined #yocto06:50
*** belen <belen!~Adium@> has joined #yocto06:52
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto06:57
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto07:00
*** jbrianceau_away is now known as jbrianceau07:01
*** eballetbo <eballetbo!> has joined #yocto07:06
*** belen <belen!~Adium@> has quit IRC07:07
*** rperier <rperier!~quassel@ubuntu/member/rperier> has quit IRC07:13
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto07:14
*** rperier <rperier!~quassel@ubuntu/member/rperier> has joined #yocto07:14
*** RP <RP!~richard@> has quit IRC07:20
*** adelcast <adelcast!~adelcast@> has quit IRC07:21
*** bluelightning <bluelightning!~paul@> has joined #yocto07:24
*** bluelightning <bluelightning!~paul@> has quit IRC07:24
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:24
*** adelcast <adelcast!~adelcast@> has joined #yocto07:35
*** kbouhara <kbouhara!> has joined #yocto07:49
*** surply_p is now known as Ptishell07:54
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC08:11
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto08:13
kbouharaHello all, Im getting the following issue when adding qt5 toolchain package group to my own image packagegroup: * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-qemu-image: * qtwebkit-mkspecs * qtwebkit-qmlplugins * qtwebkit (= 5.3.2-r0) *08:16
kbouharadoes anyone faced the same issue ?08:16
bluelightningmorning all08:23
bluelightningkbouhara: I haven't but it would be worth double-checking the README file for meta-qt5 to ensure you haven't missed any configuration08:23
*** belen <belen!~Adium@> has joined #yocto08:28
*** zecke <zecke!~ich@> has quit IRC08:34
*** ddom <ddom!> has joined #yocto08:46
*** belen <belen!~Adium@> has quit IRC08:48
*** jimBaxter <jimBaxter!> has joined #yocto08:50
*** belen <belen!~Adium@> has joined #yocto08:51
*** falk0n <falk0n!~falk0n@> has joined #yocto08:53
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:02
*** tmpsantos <tmpsantos!~tmpsantos@> has joined #yocto09:04
*** bluelightning <bluelightning!~paul@> has joined #yocto09:07
*** bluelightning <bluelightning!~paul@> has quit IRC09:07
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:07
*** linu_ <linu_!ca004dc6@gateway/web/freenode/ip.> has joined #yocto09:17
*** ant_work <ant_work!> has joined #yocto09:20
kbouharabluelightning: ok I'll do that thanks09:24
*** frsc <frsc!> has joined #yocto09:31
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto09:32
lpapphi, I have never understood this dependency: gdbserver: unsatisfied recommendation for glibc-thread-db09:32
lpappit looks broken to me09:32
lpappERROR: Nothing PROVIDES 'glibc-thread-db'09:33
lpappit is probably some eglibc package instead, but I assume this ought to be fixed.09:33
*** sce <sce!> has joined #yocto09:35
sceis there a way to display my DISTRO_FEATURES var ?09:35
lpappsce: bitbake -e foo | grep ^DISTRO_FEATURES?09:36
*** phantoxe <phantoxe!> has joined #yocto09:47
*** dv__ <dv__!> has joined #yocto09:47
*** dv_ <dv_!> has quit IRC09:48
bluelightninglpapp: meta/recipes-core/eglibc/ = "glibc-thread-db"09:48
lpappbluelightning: yeah, I think that should be removed, IMHO.09:49
lpappsee above, it is source of confusion.09:49
lpappI have been looking for the package everywhere for about half an hour.09:50
lpappand could not find anywhere.09:50
bluelightningthe source *is* eglibc09:50
bluelightningthat line is from the eglibc recipe09:50
lpappoh, well, I will not argue.09:50
lpappif you think I have had fun-time looking for the package, there is nothing to discuss.09:50
lpappwill just fix it in our fork.09:51
bluelightningthat package exists here, going right back to dylan09:54
*** zecke <zecke!~ich@> has joined #yocto09:54
bluelightningit gets renamed to libthread-db1 per debian library package renaming, but that's all handled internally09:55
lpapplet us just drop the topic, you do not see my pain, and I feel it insane. We will not reach any agreement with two completely conflicting opinion.09:55
bluelightningI don't know why that library package would not exist on your system09:55
bluelightningbottom line is gdb expects that library to exist, removing the dependency would be the wrong thing to do09:55
lpappit has nooooothing to do with removing a dependency.09:57
lpappwhen opkg tells me a package is missing, I *expect* bitbake to build the package for me if I say bitbake package.09:58
lpappit *should* figure out the details.09:58
lpappthat is one serious flaw in my opinion09:58
lpappsecondly, when I say bitbake eglibc (or whatever), it does not yield any such packages, either. That is the second big problem.09:58
lpappat least these are problems for me anyhow; ymmv.09:59
lpappI have been trying to solve such a simple issue for about 40 minutes now. Still could not understand what is going on.09:59
lpappand *anyway*, when I say bitbake gdbserver, it should provide all the dependencies automatically, that is the third big problem of mine.10:00
bluelightningand normally, it does10:00
bluelightningdo you have an eglibc-thread-db directory under the packages-split directory for eglibc?10:01
lpappthe fourth big problem of mine is that I do not know why it is not optional.10:04
lpappI am not using any threading after all.10:04
lpappor is it necessary for gdbserver to keep working because it is written with threads?10:05
*** zecke <zecke!~ich@> has quit IRC10:05
lpappre 3: find ./tmp/deploy/ipk/ -name \*glibc-thread-db\* yields nothing, but I have nativesdk-eglibc/2.17-r3/packages-split/nativesdk-eglibc-thread-db10:05
bluelightninglpapp: as I said above, the package is renamed to libthread-db1 as per debian library package renaming10:07
bluelightningdo you have an eglibc-thread-db directory under the packages-split directory for eglibc?10:07
lpappwhy is it renamed and _not_ required that way with opkg?10:09
lpappthis is what I was trying to write...10:09
lpappthat is bad bad bad bad bad10:10
bluelightningopkg should know that libthread_db1 provides that10:10
lpappbut _the user_ will not know.10:10
lpappthat is the whole point I am trying to make.10:10
bluelightningthe user shouldn't have to care10:10
lpappyeah, right ...10:11
lpapphe should care about wasting an hour :)10:11
lpappto install gdbserver on the board lol10:11
bluelightningif you answer my question we can start to debug it, otherwise there's not a lot I can do10:11
lpappI think I already did, and I also do not see what to debug here.10:12
lpappit is fundamentally flawed IMHO, and should be revamped.10:12
lpappif X is the dependency, opkg should say X, no matter what.10:12
lpappyou can think of it the other way around, too, if opkg says X, no matter what, Yocto should generate that.10:12
bluelightninglike I said, normally it does10:13
lpappno no no, you said there is no eglibc-thread-db package.10:13
JaMayou can also disable debian.bbclass if you want10:13
lpapplet me put it clear:10:13
lpapp[1] opkg says eglibc-thread-db -> find ./tmp/deploy/ipkg -name \*eglibc-thread-db\* should find it10:13
lpapp[2] opkg says libthread-db110:14
lpappeverything else is "fun-time" for the end user.10:14
JaMagrep packages files so that you cover also all RPROVIDES10:14
JaMausing find to do that is stupid10:14
JaMaand not surprising that it doesn't cover all cases10:15
lpappdoing simple things to achieve the goal is not stupid IMHO10:15
lpappand _anyway_, grep will not help, see above: meta/recipes-core/eglibc/ = "glibc-thread-db"10:15
bluelightningthe point is either the package is there or it isn't, so far we haven't even been able to determine that10:15
JaMalpapp: "simple things" which searches for something else than what you need and what opkg sees _is_ stupid10:16
lpappthat _is_ stupid yes, but that means _opkg_ and/or _Yocto_ is stupid, too, in this sense.10:16
lpappit should make life hard, not difficult10:17
lpappwho cares about some debian thing.10:17
JaMapackages-split as suggested by Paul or greping Packages files is what you need and what opkg will use to determine if the runtime provider is there or not10:17
lpappit just confuses the user. I will certainly patch that out in our fork since IMHO,
lpappI understand that is what is needed, but what I am trying to write is, that is _not_ what should be needed.10:18
gebreselaisihey guys10:18
gebreselaisiany idea who should provide system-auth?10:18
gebreselaisithe pam config file?10:18
bluelightningno need to patch it out, just disable debian.bbclass... and if you don't like the dependency at all, use a bbappend to clear it, problem solved10:18
lpappthe whole system should not be this complex, since it is really superfluously unnecessary IMHO, with all due respect whoever wrote this "feature".10:18
lpappin fact, I am not even using a debian system, hack.10:19
lpappnor on the host, nor on the target, why on earth would it be automagically done like that by default?/10:19
lpappI see zero gain, and it wasted one hour of my time as well as some of yours all ...10:20
JaMabecause it's very useful for majority of distributions10:20
lpappright, we will need to agree to disagree, but I guess that is what forks are good for :)10:20
JaMaOE allows you to configure and customize what you want, you don't need to call it "fork" every body has own configuration and that's how it's supposed to be used10:21
lpappno, I do not want this debian class mess in my tree at all10:22
lpappI *do not* want it to be configurable.10:23
lpappI want it to be killed with fire in our tree, so that no one can waste the valuable developer time with it.10:23
JaMaheh, I'm off - going to watch trees grow..10:24
lpappand even if this debian mess is silently and automagically screwed up under the new user, the opkg generation *should* be modified so that opkg does report the renamed stuff.10:25
lpappI have never seen any distribution yet that reports dependency foo, but then you cannot find such a package, and rightfully so IMHO.10:26
lpappso I am not sure what majority was referred above.10:26
lpappeven in debian, if I get a missing dependency, I can find that package for installation.10:27
lpappIMHO, it is some broken debian class or something :)10:27
lpappan end user of the system is _not_ supposed to dig into oe/yocto/poky/whatever sources to install a dependency on the distribution. That is not acceptable. It is the system developer that understand the buildsystem, but the end user should _not_.10:28
lpappit is just again, anti-KISS design IMHO.10:28
lpappif any, I would personally make the default in our fork "no no debian" and give a big warning if someone enables it, but I do not see the need for enabling it altogether, personally.10:29
*** S_A <S_A!3df6bac6@gateway/web/freenode/ip.> has joined #yocto10:30
S_AHi! I need to add support of radeon driver (xf86-video-ati) in my target machine. Any idea how to add10:31
lpappI do not even mention the missing documentation for disabling a class, because that is just 100th rank issue, although it goes undocumented or at least it is very hard to discover. I have been trying to grep for it in the documentation, but nothing gives me an example, really.10:32
lpappS_A: get that from the bloated meta-oe layer10:33
lpappS_A: the layer indexer is your friend,
bluelightninglpapp: git grep INHERIT.*debian will tell you that debian.bbclass is enabled through INHERIT_DISTRO, then just set that var to a value that does not include "debian"10:35
*** belen <belen!~Adium@> has quit IRC10:35
*** belen <belen!~Adium@> has joined #yocto10:36
lpappno, it will not.10:36
bluelightninglpapp: as with the other changes, you do not need to fork in order to change it10:36
lpappI am using my own tree, I do not have the poky history. Again, I am not a poky developer, I am a poky _end user_.10:36
lpappI think there is some confusion what end user means.10:36
bluelightningwell, you can of course do as you please, I gave you the answer in any case10:36
lpappbluelightning: huh? I do not need to fork it to kill it with fire?10:37
lpappI want *my tree* to not even considerate it by default, and going even more: I do not want anyone to enable it ever.10:37
bluelightningyou do not need to fork poky in order to change things like this, you can just set variables in your distro config10:37
lpappI do not see how that can ever happen without fork.10:37
bluelightningwe do this so that you have less pain when it comes to upgrade10:37
lpappquilt has existed for decades, much less painful than finding a single dependency.10:38
bluelightningI'm not sure how that relates to this...10:38
*** b00^wk <b00^wk!> has joined #yocto10:39
*** hsychla_ <hsychla_!> has joined #yocto10:41
lpapplike I said an hour ago, we will not reach any common agreement here. We have different definitions of what end user is.10:42
lpappfrom the ground up, essentially.10:42
bluelightningour system allows for different distro policies to exist, it even makes it relatively easy for those to be applied on top of the core metadata without changing that core, saving time when that core is upgraded10:43
bluelightningthe acknowledgement that people want to be able to do different things with the system is built-in10:44
lpappyeah, I, as a distribution developer, fantastically wasted one hour after our user also wasted a significant amount of time.10:44
*** nerdboy <nerdboy!> has quit IRC10:44
lpappyou think this is wonderful, I think it is awkward, let it be so. We will not convince each other.10:45
bluelightningI do not claim it is perfect, I never would10:45
lpappbut I am used to not getting my pain heard here anyway :(10:46
bluelightningto be frank a lot of that is about how you ask for things sometimes10:47
bluelightningor how you respond when an attempt is made to help work through what the problem is10:47
JaMatrue, I'm still partially interested to see if the package was really created or missing10:48
JaMabut instead of simple answer, there is useless discussion about configuration/killing-with-fire10:48
lpappuseless for you, and marginal for me.10:48
lpappwhether it was created was completely irrelevant, but no, it was not created as I said at least twice.10:48
JaMano you didn't10:49
lpappI am sorry if you had missed it twice.10:49
lpappI gave up on writing it the third time if people do not read what I write.10:49
lpappanyway, I am off /me fixing this in the fork10:49
JaMaall you said is that there isn't a file with that filename10:49
JaMawhich isn't the same thing as "runtime provider"10:49
*** nerdboy <nerdboy!> has joined #yocto10:50
lpappin our project, there will be no such stupid time wasters.10:50
lpappthat is, what opkg will report will be the dependency, no hidden magic to confuse the user10:50
lpappYocto does not give this option to us by default, so we have to tweak, no not configure, at all.10:50
lpappconfigure means I already wasted one hour (effectively more) and our end user, too.10:51
lpappit is too late to realize this is configure.10:51
lpappthe time is already wasted; this is not acceptable.10:51
JaMaso again you're moving the discussion somewhere else and we'll never know if there is something wrong with gdbserver or not10:51
*** jonte <jonte!~Jonte@> has joined #yocto10:51
*** belen <belen!~Adium@> has quit IRC10:53
JaMaI guess not, but I don't want to waste more of my time _trying_ to help you stop wasting your time10:53
*** belen <belen!~Adium@> has joined #yocto10:53
JaMa11:34:37 < lpapp> hi, I have never understood this dependency: gdbserver: unsatisfied recommendation for glibc-thread-db10:54
JaMa11:34:41 < lpapp> it looks broken to me10:54
lpappJaMa: I do not think you understand my issue, let it be so.10:55
lpappyou think the real issue is whether libfoo-db blabla is generated.10:55
lpappwhereas that is red herring in my opinion.10:55
lpapp(that is why I linked the XY problem thread above because I think that demonstrates the situation here)10:56
bluelightninglet me explain how this could have gone10:56
bluelightningis the package produced? no it's empty and thus never exists, why? let's look at the configure output... right, we're configuring out threading, therefore that package shouldn't be expected to exist10:58
bluelightningthen we could look at trying to pick that up and not having the dependency under those circumstances10:58
bluelightningnow, I've no idea if that's what's happening, because we weren't able to follow any kind of debugging path even though doing that might seem pointless to you10:58
bluelightningit's only in digging to find the root cause (as pointed out in the link you yourself posted above) that we can get to that point10:59
lpappI wrote it several times what my root cause is. Do I really need to write it again? I can, but I do not feel appreciated by not being heard.11:00
lpapp"That is, you are trying to solve problem X, and you think solution Y would work, but instead of asking about X when you run into trouble, you ask about Y." -> My problem is X, you are asking about Y.11:01
bluelightningif you did then somehow I missed it; and saying "I already said it I won't say it again" probably takes more effort than just repeating it11:01
lpappmy problem is: why on earth do I have to install a different package than mentioned??11:01
bluelightningmaybe what you said and what I was asking about were two different things11:02
lpappyour question is: do you have the renamed package generated??11:02
bluelightningyes, I was attempting to figure out why you even got the failure11:02
lpappso, you confirm you were asking about Y, and I was interested in X, great. Now, let us not go through that again.11:03
bluelightningwhy is there no package named eglibc-thread-db or even glibc-thread-db ? because of debian renaming; and we talked about how to turn that off, which is an option that is already available11:03
*** belen <belen!~Adium@> has quit IRC11:03
lpappyes, I realized it *after* wasting my and my user's time.11:04
lpappwonderful, but not that stuff again ever.11:04
*** belen <belen!~Adium@> has joined #yocto11:04
lpappjust .... not!11:04
lpappnot not not, this is not acceptable, and I am very likely not alone.11:04
lpappwhether the libfoo-db stuff is generated is Y answer.11:04
lpappI do not care whether it is generated or not. I want opkg to report the right stuff for me * all the time * _and_ * by default *.11:05
lpappthat means, it is not configuration, it is default, when I clone Yocto.11:05
bluelightningopkg can only report what it knows, and all it knows is that a dependency exists on glibc-thread-db and nothing in all of the packages produced provides that11:05
lpappI do not care. It is unacceptable, the system needs improvement. This is not a configuration thing.11:06
lpappanyone cloning Yocto will get into this trouble without superknowledge upfront.11:06
lpappSorry, but this is not acceptable in _my_ projects with due respect whatever others do.11:06
bluelightningI think that might be an exaggeration, because just cloning and building the system to start with I don't think you could hit this error11:07
bluelightningyou have spent time making quite considerable modifications to your system including changes to poky itself, in your fork11:07
*** nerdboy <nerdboy!> has quit IRC11:07
lpappof course, none of the patches was accepted in upstream ever :)11:08
bluelightningthat is provably false11:08
bluelightningsome of your patches were not accepted, sure11:08
lpappI am probably blacklisted from contribution.11:08
lpappbut I do not care. I think I got all the information that I needed to proceed with my ideas, thanks.11:09
bluelightningnot at all, we accept reasonable changes from all community members11:09
*** nerdboy <nerdboy!> has joined #yocto11:18
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto11:23
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto11:23
*** zecke <zecke!~ich@> has joined #yocto11:26
*** blitz00 <blitz00!stefans@nat/intel/x-rpaedzfvhqxutdlr> has joined #yocto11:30
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto11:30
*** tasslehoff <tasslehoff!~Tasslehof@> has left #yocto11:35
*** ddalex <ddalex!~ddalex@> has quit IRC11:39
*** ddalex <ddalex!> has joined #yocto11:40
*** RP <RP!~richard@> has joined #yocto11:49
*** RP <RP!~richard@> has quit IRC12:05
*** ritou <ritou!52e6ff24@gateway/web/freenode/ip.> has joined #yocto12:06
ritouhas anyone built image for raspberry b+ with oe?12:08
*** zeddii_home <zeddii_home!> has joined #yocto12:09
lpappritou: yes12:10
ritoulpapp: is there any info about that somewhere? id like to crossbuild stuff for the b+ i found older posts but not sure this would work with b+ :
*** rjv16 <rjv16!3df6bac6@gateway/web/freenode/ip.> has joined #yocto12:12
rjv16Can anyone guide me to integrate Xorg graphic driver12:13
*** phantoxe <phantoxe!> has quit IRC12:17
*** phantoxe <phantoxe!> has joined #yocto12:19
*** lumag <lumag!> has joined #yocto12:27
*** likewise <likewise!~likewise@> has joined #yocto12:30
*** likewise <likewise!~likewise@> has quit IRC12:31
*** likewise <likewise!~likewise@> has joined #yocto12:33
*** likewise <likewise!~likewise@> has quit IRC12:34
scehello, does someone know why largefile in DISTRO_FEATURES is an optional distro features12:40
scehello, does someone know why largefile in DISTRO_FEATURES is an optional distro feature12:40
bluelightningsce: it's been that way for a long time; perhaps on older 32-bit systems there were memory constraint issues with having it enabled and it wasn't really needed? not sure12:42
sceokay so no know sideeffect ?12:43
bluelightningof enabling it or removing it?12:43
bluelightningit's on by default12:43
sceyes in poky.conf you mean ?12:44
scei'm having a special conf that's why it was not on12:44
scebut i wanted to confirm that there is no sideeffects12:44
bluelightningpoky.conf adds it but it's actually defaulted to on in OE-Core's defaultsetup.conf as well12:44
bluelightningno, I wouldn't think there would be any sideeffects12:45
bluelightningit's not necessarily complete for 32-bit systems, that's a separate issue though (there is a bug open to track that)12:45
sceok thx for your enlightning ;)12:46
lpappsce: because what is the point of enabling it if you do not need it?12:47
lpappit would be illogical to do so.12:47
scei need it that's the point12:47
lpappsee, in my case, I have a very small flash, so inherently, I cannot have large files.12:47
lpappI answered this: "hello, does someone know why largefile in DISTRO_FEATURES is an optional distro feature"12:48
scebut i guess my team sets originally the DISTRO_FEATURES without largefile12:48
canciis there some documentation on how EXPORT_FUNCTIONS works?12:50
lpappthe ... what?12:51
sceanyway thx alll12:52
*** rjv16 <rjv16!3df6bac6@gateway/web/freenode/ip.> has quit IRC12:52
canci(I have one bbclass here which defines do_compile() and another class which sets foo_do_compile() and uses EXPORT_FUNCTIONS - and I am not really sure if/how I can use both classes together)12:52
*** Adam_ <Adam_!3df6bac6@gateway/web/freenode/ip.> has joined #yocto12:52
cancilpapp: thank you12:52
Adam_Can anyone provide me information about how to integrate bx-org display driver in YOcto12:54
*** ritou <ritou!52e6ff24@gateway/web/freenode/ip.> has quit IRC12:56
*** gvy <gvy!~mike@altlinux/developer/mike> has quit IRC12:58
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC13:02
*** madisox <madisox!> has joined #yocto13:03
*** ddalex <ddalex!> has quit IRC13:07
*** Adam_ <Adam_!3df6bac6@gateway/web/freenode/ip.> has quit IRC13:09
*** Adam_ <Adam_!3df6bac6@gateway/web/freenode/ip.> has joined #yocto13:09
Adam_I am trying to use xorg graphics driver with the yocto project13:10
Adam_Can anyone plese help me out in integrating13:10
*** Siecje <Siecje!~Siecje@> has joined #yocto13:13
bluelightningAdam_: which graphics driver?13:22
bluelightningis there already a recipe that builds and/or packages it?13:23
*** ddalex <ddalex!~ddalex@> has joined #yocto13:24
Adam_I am having a recipe13:25
Adam_i have enabled the kernel mode settings13:26
bluelightningok, so it seems like you'd only need to add the package to your image then13:30
bluelightningsee here for several ways of doing that:
Adam_Is there any way of compilig Xorg alone13:35
*** nitink <nitink!nitink@nat/intel/x-bgciqqyzrkrpqwgn> has joined #yocto13:45
*** cbzx <cbzx!> has joined #yocto13:50
*** TobSnyder <TobSnyder!> has quit IRC13:59
*** ddalex <ddalex!~ddalex@> has quit IRC14:04
bluelightningAdam_: I guess bitbake xserver-xorg14:05
*** nitink <nitink!nitink@nat/intel/x-bgciqqyzrkrpqwgn> has quit IRC14:05
*** Gintaro <Gintaro!> has quit IRC14:20
*** likewise <likewise!~likewise@> has joined #yocto14:25
*** sce <sce!> has quit IRC14:26
*** sce <sce!> has joined #yocto14:27
*** Gintaro <Gintaro!> has joined #yocto14:37
*** SorenHolm <SorenHolm!> has joined #yocto14:42
*** b00^wk <b00^wk!> has quit IRC14:52
*** nitink <nitink!nitink@nat/intel/x-bxfoeoybmenjqmie> has joined #yocto15:04
*** ericho <ericho!Erich@nat/intel/x-cqrathqkdoohkzln> has joined #yocto15:07
*** tmpsantos <tmpsantos!~tmpsantos@> has quit IRC15:08
blloydis there a way to specify that a recipe cannot be built in parallel with any other package?  I have a very strange failure case with boost, where it fails to build when building an image, but if built as a target (cleannstate of boost first), it succeeds.  Happened multiple times now on two different boxes.15:08
icanicantI'm sure it's a FAQ but, is there any way to remove an item from DISTRO_FEATURES without having to make your own distro? (No matter how hacky)15:08
blloydhave you tried setting DISTRO_FEATURES = "FEATURES YOU NEED" in local.conf?15:10
icanicantblloyd: ah yes, doing that now, but i'd like a solution that works automatically for multiple developers15:11
blloydadd that line to a layer.conf file?15:11
icanicantblloyd: ah those are parsed at the right time. thanks, i'll give that a go.15:13
ndecnote that if you just want to remove features, you can do DISTRO_FEATURES_remove = "foo"15:14
icanicantndec: it looks like that one is not in dora15:14
blloydndec: cool.  When did _remove get added.  And is it documented?15:14
blloydbecause I haven't seen it in master docs either...15:15
bluelightningblloyd: how does boost fail?15:15
ndeci think it was added in dora.15:16
bluelightningwith regard to advertising DISTRO_FEATURES_remove, I'm wary of anything that discourages people from creating their own distro config15:16
bluelightningif anything we should be making that part easier rather than making it easy to avoid15:16
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC15:17
*** dmoseley1 <dmoseley1!> has joined #yocto15:17
bluelightningfilling up local.conf with things that belong in the distro config if left unchecked can lead to problems reproducing the same build later on another machine15:18
blloydI'm not entirely sure what fails it first time.  However, once failed I've looked and cc1plus segfaults on almost instantly on subsequent attempts to build.  I suspect it's a resource fauilure where an invalid .o or .a is left and later calls crash when using it.15:18
bluelightningblloyd: hmm... boost is quite large, is it possible you're running out of memory and the OOM killer is getting involved? a quick look at the kernel log should reveal if that's the case15:19
blloydI looked and didn't see it.  That is exactly what I suspected.  Why I asked about something to restrict it.  Cut down on resources used at the time.  But 16GB with 64GB virtual ram shouldn't run out of ram....15:20
*** frsc1 <frsc1!> has joined #yocto15:21
*** frsc_ <frsc_!> has joined #yocto15:24
*** frsc <frsc!> has quit IRC15:24
*** likewise <likewise!~likewise@> has quit IRC15:25
*** frsc1 <frsc1!> has quit IRC15:27
bluelightningblloyd: right, scratch that then15:28
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto15:28
bluelightningit sounds odd, what we'd really want is more information on that first failure15:28
bluelightningto answer your question, there is no workaround other than setting dependencies such that one must occur before the other15:29
blloydFor full disclosure: I do have a .bbappend for boost to enable some of the libraries that were not enabled by the official package.  I like how the latest package handles it's python now.15:30
bluelightningok, that might account for us not seeing the issue up to now, but it doesn't necessarily excuse us from fixing it ;)15:31
blloydthanks blue.  What I suspected, but was hopeful in case there was some new capability I hadn't noticed yet.15:31
bluelightningI guess what I'd say is, if you manage to get more info on the initial failure please file a bug to track it and include the info on what extra libs you're enabling15:32
blloydYes, especialy since I plan to propose ALL boost libraries get built, and there is a library that shouldn't be built all the time do it just like the python library is done now.15:32
*** k-s[WORK] is now known as k-s15:35
blloydfrom a diagnosing the problem standpoint, is there a somewhat easy way to see after a build completes what tasks were running in parallel?  For instance, if boost build tries to use a file that is being written by another parallel job causing the segfault, it would be helpful to know what other tasks were making sysroot mods at the time.15:37
bluelightningso, kind of15:37
bluelightningthere is support for writing out a "bootchart" style chart which shows which tasks were executing when15:37
bluelightningI wonder if that will always show enough of an overlap to be definitive though, but it may be worth looking at15:38
bluelightningthe odd thing is if it really is just do_rootfs, that shouldn't ever be making changes to the sysroot15:39
*** dmoseley1 <dmoseley1!> has quit IRC15:40
blloydshould and is are too different things, unfortunately.  But I was mostly wondering about the possibility of a auto dependency discovery adding usage of a library the image has but which boost recipe doesn't consider a dependency.  If the library isn't all the way there then it could account for a build failure that leaves bad .o files.15:43
*** ddom <ddom!> has quit IRC15:51
bluelightningright, yes that could happen15:51
bluelightningwe do have a script to check for that sort of thing but I believe it's more suited to testing in world build situations15:51
bluelightningI'm not 100% familiar with boost itself but if it does checks within configure to see what dependencies are available and actually reports what is being enabled, you could build just boost from clean (or just from sstate), then build your image and then rebuild boost and see if the configure logs (or even the output with buildhistory) are different15:53
kergothwe have a built in sanity check now for runtime deps (e.g. auto-added shlib deps) which are missing build deps, afaik, if thats what you mean by usage of a library15:54
*** T0mW <T0mW!> has quit IRC15:54
*** sjolley <sjolley!sjolley@nat/intel/x-nklwghqciqvqornb> has quit IRC15:55
bluelightningkergoth: right, in master, yes15:55
*** SorenHolm <SorenHolm!> has quit IRC15:57
*** eballetbo <eballetbo!> has quit IRC15:59
*** phantoxe <phantoxe!> has quit IRC16:03
*** phantoxe <phantoxe!> has joined #yocto16:04
*** falk0n <falk0n!~falk0n@> has quit IRC16:16
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC16:18
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto16:18
*** sjolley <sjolley!~sjolley@> has joined #yocto16:23
*** ant_work <ant_work!> has quit IRC16:54
*** jbrianceau is now known as jbrianceau_away17:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:37
*** belen <belen!Adium@nat/intel/x-ckxnxudukzokzomp> has joined #yocto17:46
*** phantoxe <phantoxe!> has quit IRC17:48
*** cbzx <cbzx!> has quit IRC17:54
*** cbzx <cbzx!> has joined #yocto17:54
*** smartin__ <smartin__!> has joined #yocto18:18
*** sce <sce!> has quit IRC18:32
*** jkridner <jkridner!~jkridner@> has joined #yocto18:43
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto18:43
*** bboozzoo1away <bboozzoo1away!> has joined #yocto18:52
*** bboozzoo_away <bboozzoo_away!> has quit IRC18:52
*** eren <eren!~eren@unaffiliated/eren> has quit IRC18:52
*** void-dev_ <void-dev_!> has joined #yocto18:53
*** void-dev <void-dev!> has quit IRC18:53
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto18:53
*** jonte <jonte!~Jonte@> has quit IRC18:53
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC18:53
*** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC18:54
*** mckoan|away <mckoan|away!> has joined #yocto18:54
*** malik_ <malik_!> has quit IRC18:56
*** Marex <Marex!~Marex@> has quit IRC18:57
*** canci <canci!> has quit IRC18:57
*** ionte <ionte!> has quit IRC18:57
*** ionte <ionte!> has joined #yocto18:57
*** ericho <ericho!Erich@nat/intel/x-cqrathqkdoohkzln> has quit IRC18:58
*** smo <smo!> has quit IRC18:58
*** lumag <lumag!> has quit IRC18:58
*** vignatti <vignatti!> has quit IRC18:58
*** DarkKnight_ <DarkKnight_!> has quit IRC18:58
*** canci <canci!> has joined #yocto18:58
*** malik <malik!> has joined #yocto18:58
*** DarkKnight <DarkKnight!> has joined #yocto18:58
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto18:58
*** Marex <Marex!~Marex@> has joined #yocto18:59
*** vignatti <vignatti!> has joined #yocto18:59
*** smo <smo!> has joined #yocto19:02
*** jonte <jonte!~Jonte@> has joined #yocto19:07
*** alimon <alimon!~alimon@> has quit IRC19:11
*** lumag <lumag!> has joined #yocto19:11
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC19:11
*** hsychla_ <hsychla_!> has quit IRC19:17
*** alimon <alimon!~alimon@> has joined #yocto19:18
*** jimBaxter <jimBaxter!> has quit IRC19:22
*** junland <junland!~junland@> has joined #yocto19:24
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto19:32
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC19:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:32
*** ericho <ericho!~Erich@> has joined #yocto19:45
*** rwoolley <rwoolley!~rwoolley@> has joined #yocto19:57
*** cbzx <cbzx!> has quit IRC20:08
*** cbzx <cbzx!> has joined #yocto20:09
*** junland <junland!~junland@> has quit IRC20:11
*** zecke <zecke!~ich@> has quit IRC20:14
*** kscherer_ <kscherer_!~kscherer@> has quit IRC20:18
*** SorenHolm <SorenHolm!> has joined #yocto20:24
*** cbzx <cbzx!> has quit IRC20:26
*** cbzx <cbzx!> has joined #yocto20:27
*** junland <junland!~junland@> has joined #yocto20:34
*** SorenHolm <SorenHolm!> has quit IRC20:43
*** junland <junland!~junland@> has quit IRC20:50
*** junland <junland!~junland@> has joined #yocto20:50
*** SorenHolm <SorenHolm!> has joined #yocto20:51
*** belen <belen!Adium@nat/intel/x-ckxnxudukzokzomp> has quit IRC20:52
*** rwoolley <rwoolley!~rwoolley@> has quit IRC20:55
*** frsc_ <frsc_!> has quit IRC20:58
*** nitink <nitink!nitink@nat/intel/x-bxfoeoybmenjqmie> has quit IRC20:59
*** Siecje <Siecje!~Siecje@> has left #yocto21:08
*** belen <belen!Adium@nat/intel/x-gvbwttyyuwaggaok> has joined #yocto21:12
*** hsychla_ <hsychla_!> has joined #yocto21:13
*** hramrach_ <hramrach_!~hramrach@gateway/tor-sasl/hramrach> has quit IRC21:18
*** belen <belen!Adium@nat/intel/x-gvbwttyyuwaggaok> has quit IRC21:19
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC21:23
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto21:30
*** RP <RP!> has joined #yocto21:31
*** smartin__ <smartin__!> has quit IRC21:32
*** cbzx <cbzx!> has quit IRC21:35
*** hramrach_ <hramrach_!~hramrach@gateway/tor-sasl/hramrach> has joined #yocto21:37
*** cbzx <cbzx!> has joined #yocto21:46
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:47
*** jkridner <jkridner!~jkridner@> has joined #yocto21:47
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:48
*** junland <junland!~junland@> has quit IRC21:49
*** cbzx <cbzx!> has quit IRC21:50
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** hsychla_ <hsychla_!> has quit IRC22:22
*** SorenHolm <SorenHolm!> has quit IRC22:38
*** edsiper <edsiper!> has joined #yocto22:41
*** nitink <nitink!nitink@nat/intel/x-jsgzslvejjnpggya> has joined #yocto22:56
*** blloyd_ <blloyd_!> has joined #yocto22:56
*** blloyd <blloyd!> has quit IRC22:57
*** madisox <madisox!> has quit IRC22:57
*** nerdboy <nerdboy!> has quit IRC23:16
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto23:16
*** likewise <likewise!~likewise@> has joined #yocto23:21
*** likewise <likewise!~likewise@> has quit IRC23:22
*** likewise <likewise!~likewise@> has joined #yocto23:22
*** likewise <likewise!~likewise@> has quit IRC23:25
*** likewise <likewise!~likewise@> has joined #yocto23:57

Generated by 2.11.0 by Marius Gedminas - find it at!