Friday, 2013-07-26

*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:02
*** andyross <andyross!> has quit IRC00:03
*** ant_home <ant_home!> has quit IRC00:16
-YoctoAutoBuilder- build #237 of nightly-mips-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
*** frank <frank!~frank@> has quit IRC00:45
*** _julian <_julian!> has joined #yocto00:56
*** _julian_ <_julian_!> has quit IRC00:57
*** munch <munch!> has quit IRC00:59
-YoctoAutoBuilder- build #226 of build-appliance is complete: Success [build successful] Build details are at
wmatseebs: I thought CodeSOurcery toolchains required 32 bit libs?01:02
*** ericben <ericben!> has quit IRC01:04
*** ericben <ericben!> has joined #yocto01:05
-YoctoAutoBuilder- build #203 of nightly-oecore is complete: Success [build successful] Build details are at
*** mitz <mitz!> has quit IRC01:21
-YoctoAutoBuilder- build #228 of nightly-arm-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
lpappsgw_: now, yes01:21
seebswmat: They do, yes.01:22
seebsOne of the problems we appear to have is that even if you set NO32LIBS to 0, we still don't actually *try* to build 32-bit libpseudo unless the host environment has a particular 32-bit header file, which is probably a poor choice.01:22
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:22
seebsOriginally, we tried to build 32-bit libpseudo on 64-bit machines if they had that file. Then the NO32LIBS stuff got added, but the check for the file wasn't changed, so there's no way to indicate "we actually require 32-bit libpseudo and if you can't build it that is a serious problem that should be reported".01:23
wmatseebs: ah01:25
sgw_lpapp: We are making progress, I posted a patch thanks to you and kergoth for the sourcery toolchain in core, and as seebs points out we found my problem with not having a 32bit libpseudo built (different than your problem).01:25
sgw_lpapp: what we are trying to understand now is bug 4919 which is why your native build of a 32bit libpseudo is not finding the appropriate 32bit libraries from /usr/lib3201:26
yoctiBug normal, Medium, 1.5, peter.seebach, NEW , Failure when trying to build on Archlinux 64 bit host with 32 external toolchain01:26
wmatdoes it break when using meta-sourcery too?01:26
wmaton a 64bit machine01:27
sgw_wmat: Yes, I beleive it failed on my machine also, but I would have to go back and check, but now that I have the gnu/stubs-32.h it will succeed.01:28
wmathmmm, i'm surprised Mentor didn't encounter this01:28
lpappwmat: they do not use a sane distro.01:29
lpappwhere lib is the 64 bit. :)01:30
lpappi.e. the default is the system you are on.01:30
lpappsgw_: do you have an arch machine?01:30
lpappsgw_: if not, can you get one into chroot?01:31
sgw_lpapp, I am trying to build an Arch system, can you send me (by email ) a full package list that you have installed, so I don't have to go through the tap-dance of installing packages01:31
sgw_or a list that I can put on the pacstrap command line initially01:31
sgw_lpapp: I am building a VirtualBox image now01:32
lpappsgw_: sorry, I have no any clue.01:33
lpappsgw_: you can check what the requirement is for other distributions.01:33
sgw_lpapp: can you give me a list of what's installed on your system, that will go a long way to help.01:34
lpapplpapp: well, it would be useless for you.01:34
*** mitz <mitz!> has joined #yocto01:34
lpappand would hold you up for quite a while.01:35
lpappas I have tons of packages installed01:35
lpappyou probably do not need 90% of it.01:35
sgw_Not having would equally hold me up01:35
sgw_because every false start will require me to install another thing01:35
lpappsgw_: just check the requirements01:35
lpappand use pacman -Ss for them01:35
-YoctoAutoBuilder- build #228 of nightly-x86-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
lpappthat is what I would do.01:36
seebsA casual check confirms that about half of the 64-bit hosts I use have x86_64 in /usr/lib, and x86 in /usr/lib32. It doesn't matter at all.01:38
lpappseebs: well, why does it look in the wrong directory then?01:40
lpappit should look into /usr/lib3201:40
lpappbut it looks into /usr/lib01:40
seebsWell, that's a really vague and open-ended question. Why does "it" look in the wrong directory? Which "it"?01:41
lpapp02:40 < lpapp> it should look into /usr/lib3201:41
lpapp02:40 < lpapp> but it looks into /usr/lib01:41
seebsThe pseudo build specifies a -L for sqlite3 when compiling the pseudo executable which is wrong on some systems, but generally harmless if you are using the host system's sqlite, so it doesn't matter.01:41
seebsSo we have tons of successful builds where there's an extra -L which has nothing to do with anything.01:42
seebsSee, here's the thing.01:43
seebsYou said something. In that thing, you used the pronoun "it". I did not know what you were using that pronoun to refer to.01:44
seebsSo I asked you what "it" was.01:44
seebsAnd you…  *repasted the same two lines as though I had not just seen them*.01:44
seebsYou did not indicate whether you were talking about gcc, or whether you were talking about -L arguments or about some other compiler diagnostic, or whether you were talking about the runtime linker, or anything else. Instead, you insultingly repeated what you'd just said as though if I'd just read that I would have known what you were talking about.01:45
lpappsee the bugreport for details please.01:45
seebsBut that's not the case at all. Nothing in there tells me what "it" is. Nothing tells me where in the process you are observing a failure, or what the failure is.01:45
lpappit is all pasted there, really.01:45
lpappI thought you have gone through that already...01:45
seebsSee, the thing is. Without the insulting re-paste of exactly the opposite of an answer to my question, I might well.01:45
seebsBut as is, I'm going back to ignoring you because you are rude and entitled and uncooperative, and it is *not useful* to spend time trying to derive valuable information from this.01:46
*** mulhern <mulhern!> has quit IRC01:46
lpappthere is no any insult in trying to help you.01:46
*** joshc <joshc!~joshc@rhlug/joshc> has quit IRC01:46
-YoctoAutoBuilder- build #64 of minnow-lsb is complete: Failure [failed Building Images] Build details are at
lpappthanks you so much for stop helping with unblocking me!01:47
lpappthank you*01:47
lpapphack, then I cannot really say this Yocto thingie "supported".01:48
seebsI found the repasting of the exact text I'd asked for clarification of to be insulting, because it was the opposite of an answer.01:48
seebsEven just responding with "there's more details in the bug report" would be less obnoxious.01:48
lpappI am tired of having issues with every setup possible.01:48
lpapprepasting is exactly repeating "it".01:48
lpappI honestly do not know how to tell more. That is all very clear to me.01:49
lpappBesides, the bugreport was filed relatively long ago.01:49
seebs"it should look into /usr/lib32" <-- this sentence here.01:49
lpappit is not an unreal expectation to read an already existing report before asking?01:49
seebsI asked what "it" was. As in, *WHAT* should look into /usr/lib32?01:49
sgw_lpapp: I spent a good part of my day looking into this with seebs, I am working into my evening to setup a currently unsupported OS to try and test a situation that should work (lib32)01:49
seebsThe shell?01:49
seebsWe have no idea. "it" should.01:49
lpappsgw_: yeah, I appreciate that.01:49
sgw_lpapp: If you keep this up we will just punt01:50
lpappnow, that annoys me.01:50
seebsAnyway, looking at your bug report, you're ignoring a very clear error message from the compiler and focusing on the distracting but ultimately irrelevant warnings.01:50
lpappI am trying to help *after* my work gours01:50
lpappin my leisure time01:50
lpappsee, it is 02:50 am01:50
lpappand normal people sleep rather than collaborating here.01:50
seebsQuick test. Run "gcc -m32 -o hello hello.c" with a normal hello world.01:50
lpappI rather go back to sleep, I do not need this stress.01:50
lpappeverything is in the bugreport, bye01:51
seebsIf that works, and "gcc -L/usr/lib -m32 -o hello hello.c" doesn't, then you have an issue.01:51
sgw_I know it's later there, you can help by trying things, but your not willing to help that way.01:51
*** swex <swex!~swex@> has quit IRC01:51
seebsEh, the bug report comes down to "lots of irrelevant errors, also key 32-bit libraries aren't installed".01:51
seebsThe compiler will search /usr/lib32 by default on a 32-bit host. The warnings about the incompatible libraries it's skipping are irrelevant.01:52
lpappsgw_: what things, really?01:52
lpappsgw_: information is all provided I can.01:52
seebsWhat's important is that it isn't finding -lgcc and -lpthread, and if it's not finding those, that's because they're not installed.01:52
*** swex <swex!~swex@> has joined #yocto01:52
lpappsgw_: I am trying to collaborate at *02:30* am for the fuck sake01:52
lpappwill you be here at 02:30 am, hello?01:52
lpappHonestly, I do not feel appreciated even though I came here at fucking 02:3001:53
seebsI frequently am. :)01:53
lpappso good night guys01:53
seebsAnd anyway, I told you what's wrong.01:53
seebsYou can fix it or not.01:53
*** mario-goulart <mario-goulart!> has quit IRC01:54
lpappseebs: sorry, but you do not make any sense01:54
lpapp-L/usr/lib is unnecessary first of all01:54
lpappsecondly, I said gazillion times 32 bit stuff is in /usr/lib3201:54
seebsYes, we know.01:54
seebsecho "int main(void) { return 0; }" > hello.c01:55
seebsgcc -L/usr/lib32 -m64 -o h hello.c01:55
lpappI am tired, good night.01:55
lpappsee you tomorrow01:55
seebs=> A couple of "/usr/bin/ld: skipping incompatible /usr/lib32/ when searching for -lc" messages.01:55
seebsAnd it links successfully anyway.01:55
seebsBecause those messages are not errors, they are just warnings.01:55
seebsThe actual problem is that your compiler isn't finding the libraries it needs, and those diagnostics are irrelevant, because they aren't what's wrong with the compiler. Either the compiler's busted or you don't have *the right* 32-bit libraries in /usr/lib32.01:56
seebsThe most common problem with this setup is that you have runtime libraries but not development libraries for the 32-bit environment.01:56
sgw_I giess I am back to trying the arch linux.01:57
wmatseebs: is there any tests I can run to help? I'm on a 64-bit Ubuntu host with a dylan source tree and old codesourcery toolchain (same as lpapp's).02:00
sgw_wmat: we really need an Arch Linux, I have an Ubuntu system (12.10) and it's fine02:00
wmatah, ok02:00
seebsIt's pretty easy to get the same error out of others, I believe.02:01
*** joshc <joshc!~joshc@rhlug/joshc> has joined #yocto02:01
*** mario-goulart <mario-goulart!> has joined #yocto02:01
seebsPretty sure this is exactly the behavior you'd get if you had runtimes but not the -dev packages for your 32-bit stuff.02:01
seebsAnd that's a really common configuration, since most systems won't install the development stuff for 32-bit if they're 64-bit native, they just install enough runtime to run the executables.02:02
sgw_seebs, but would it have the header files for 32-bit (like the stubs-32.h) without the development libs?02:02
seebsIt's certainly possible to get some systems into that state. You could, say, have the libc-dev-32 package (whatever they call it), but omit the pthread-dev-32 and libgcc-dev-32.02:03
sgw_ah, well I am working on the arch install (both syslinux and grub failed to install, so I am kind of stuck right now)02:04
seebsThe "skipping incompatible <foo>" messages are a red herring, you can get those easily by specifying extra -L and they don't do any harm.02:04
*** sakoman <sakoman!> has quit IRC02:05
sgw_seebs: without his package list, we can't actually determine for sure if what you suggest above is correct and he was unwilling to give that list to me.02:06
sgw_I could easily install the "right things" and have it work.02:06
seebsThat's my guess. The lib/lib32 thing is a red herring, although it might not be a bad thing to fix it just to reduce the flood of irrelevant diagnostics.02:07
wmatdon't remove those warnings, just open a ticket to document this use case in the official documentation02:08
wmatif it turns out to be valid, that is02:09
seebsIt might not be a bad idea to, when specifying the exact path for the sqlite library, just drop the -L.02:10
*** silviof2 <silviof2!> has joined #yocto02:12
*** silviof1 <silviof1!> has quit IRC02:15
-YoctoAutoBuilder- build #222 of nightly-x86-64 is complete: Failure [failed Running Sanity Tests Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
*** __frank_ <__frank_!~frank@> has joined #yocto02:38
*** sakoman <sakoman!> has joined #yocto02:39
*** mitz <mitz!> has quit IRC02:39
*** mitz <mitz!> has joined #yocto02:41
*** andyross <andyross!> has joined #yocto02:53
*** sakoman <sakoman!> has quit IRC02:53
*** sakoman <sakoman!> has joined #yocto03:07
*** sakoman <sakoman!> has quit IRC03:12
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC03:16
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto03:32
-YoctoAutoBuilder- build #196 of nightly-fsl-arm-lsb is complete: Failure [failed Building Images Building Images_1 Building Images_2] Build details are at
*** seebs <seebs!> has quit IRC03:54
*** behanw <behanw!> has quit IRC03:55
*** seebs <seebs!> has joined #yocto03:58
-YoctoAutoBuilder- build #228 of nightly-x86 is complete: Failure [failed Running Sanity Tests] Build details are at
*** agust <agust!> has joined #yocto04:20
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC04:24
-YoctoAutoBuilder- build #225 of nightly-ppc-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC04:48
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto05:01
*** ericben <ericben!> has quit IRC05:04
*** ericben <ericben!> has joined #yocto05:05
*** lpapp <lpapp!> has joined #yocto05:07
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto05:07
*** andyross <andyross!> has quit IRC05:13
*** tor <tor!> has joined #yocto05:45
*** mthalmei_away is now known as mthalmei06:11
melonipoikamorning all06:13
melonipoikabasic question, does anyone know the name of the package that provides xvfb in yocto?06:13
-YoctoAutoBuilder- build #197 of nightly-fsl-arm is complete: Failure [failed Building Images_1] Build details are at
*** mthalmei is now known as mthalmei_away06:15
lpappmelonipoika: which version?06:23
lpappmelonipoika: have you checked the graphics recipes?06:24
lpappmelonipoika: check xserver-xorg.inc06:24
melonipoikai am using ti mcsdk, let me check what version of yocto it is absed06:25
lpappso it is xserver-xorg-xvfb06:26
lpappat leat with oe-core06:26
melonipoikayeah, i tried adding xserver-xorg-xvfb to my local.conf06:26
lpappadding in what sense?06:26
lpappit should build by default, no?06:27
melonipoika|  * opkg_install_cmd: Cannot install package xserver-xorg-xvfb.06:27
melonipoikathat is the error i got06:27
melonipoikai don't think so, the original image didn't ahve any x related stuff...06:28
lpappwhat image are you building?06:28
lpappis it custom or some-premade?06:28
melonipoikathe image is tidsk-server-rootfs-image.bb06:29
lpappsorry, I am afk for 20 minutes06:29
melonipoikashould i paste here the content? (17 lines)06:29
lpappok, that I do not know06:29
lpappbut if I use the default images06:29
lpappthey work ok.06:29
lpappcompare with the default ones06:29
melonipoikaifik this is the only image that is supported in keystone II hw...06:29
melonipoikaok, thanks06:30
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC06:31
*** eballetbo <eballetbo!> has joined #yocto06:51
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC07:01
*** volker <volker!> has quit IRC07:10
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC07:13
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:18
*** tbn <tbn!~tbn@> has joined #yocto07:21
*** tbn is now known as Guest6769307:21
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto07:24
lpapprburton: the cache stuff is calling for troubles07:26
lpappI was just debugging an issue because of that for hours.07:26
lpapponce cache removed, it works.07:27
lpapprburton: was getting this continuously:
lpappby cache, I mean everything except the conf folder.07:28
*** sameo <sameo!~samuel@> has joined #yocto07:33
*** slaine <slaine!~slaine@> has joined #yocto07:33
lpappkergoth: hey?07:36
lpappanother libexec arch bug?07:39
lpappfind /usr/local/arm-2009q1/ -name libexec07:40
lpappit is looking into the wrong directory again.07:40
*** ant_work <ant_work!> has joined #yocto07:50
lpapprburton: oh, and we debugged that python stuff last time as well with -e for hours07:50
lpappthat is exactly the reason why I prefer to clean cache.07:50
lpappthere are no such issues then.07:50
*** bluelightning <bluelightning!~paul@> has joined #yocto07:53
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:53
yoctiBug 4922: normal, Undecided, ---, richard.purdie, NEW , There is no clean option for bitbake or a separate util07:54
lpappkergoth: sgw_:
yoctiBug 4922: normal, Undecided, ---, richard.purdie, NEW , There is no clean option for bitbake or a separate util07:59
lpappkergoth: sgw_: *07:59
yoctiBug 4923: normal, Undecided, ---, bogdan.a.marinescu, NEW , Cross-compilation issue with libexec when building for 32 bit host on arch 64.07:59
bluelightningmorning all08:00
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto08:02
*** sakoman <sakoman!> has joined #yocto08:02
*** tsjsieb <tsjsieb!> has joined #yocto08:03
lpappwhat is prefix usually in a bb recipe?08:08
lpappI mean where is it set?08:08
lpappI see it used in a meta-sourcery bb file, but it is not set right in there.08:09
lpappand I do not find it set anywhere inside meta-sourcery.08:09
*** mckoan|away is now known as mckoan08:11
mckoangood morning08:12
*** mihai <mihai!~mihai@> has joined #yocto08:15
*** GunsNRose_ <GunsNRose_!~GunsNRose@> has joined #yocto08:17
rburtonlpapp: default prefix is set in bitbake.conf, or your distro can override that08:18
lpappit is set to /usr08:18
lpappnot sure that is correct for the cross-toolchain, really.08:18
lpappperhaps I am missing the sysroot08:18
lpappdistro = layer, I believe08:20
lpappas it is probably not specific to a distro08:20
lpappas layers are not specific to distros08:20
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC08:21
*** dzoe_ <dzoe_!> has quit IRC08:22
*** dzoe_ <dzoe_!joe@pdpc/supporter/active/dzoe> has joined #yocto08:22
*** dzoe_ is now known as dzoe08:22
lpapprburton: shouldn't the meta-sourcery layer set the prefix to the cross-toolchain?08:26
lpapprburton: or is that the prefix for the installation?08:26
lpappI am slightly confused now.08:26
*** honschu_ <honschu_!> has joined #yocto08:27
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto08:27
*** GunsNRose_ <GunsNRose_!~GunsNRose@> has quit IRC08:30
*** mihai <mihai!~mihai@> has quit IRC08:30
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto08:30
*** conditionzero <conditionzero!~Unknown@2001:6f8:12d9:13:1e4b:d6ff:fedb:207c> has joined #yocto08:30
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:31
*** zeeblex <zeeblex!~apalalax@> has joined #yocto08:32
*** belen <belen!Adium@nat/intel/x-hkoebosgyhryaidf> has joined #yocto08:37
*** smartin <smartin!> has quit IRC08:38
* lpapp is considering to open a bugreport about making shm optional08:46
lpappit has been causing so much issues for several hours now.08:46
lpappand it is very hard to get it right.08:46
bluelightninger, we can't do that08:46
bluelightningpython multiprocessing requires it08:46
lpappbluelightning: then you should not use such python instructions.08:46
lpappif any instruction needs that, that sucks huge balls.08:46
lpappthat means, the language is fundamentally broken.08:47
*** smartin <smartin!> has joined #yocto08:47
lpappbecause it gives no choice for IPC to you.08:47
lpappbut I am fairly certain it is not the case.08:47
bluelightningpython multiprocessing is a well-accepted and widely used concurrency tool08:47
lpappwhich does not work apparently right ...08:48
lpappand got no help for several hours on #archlinux, #debian, #yocto08:48
lpapphow to get it fed properly.08:48
lpappI tried everything now I had ideas.08:48
lpappso if it is this hassle, and so hard to get help, I would not consider it acceptable for everyone.08:48
lpappwhich brings back to optional.08:48
lpapppretty much no programs need that in my debian wheezy.08:49
lpappotherwise they would be broken.08:49
lpappbitbake is the first one.08:49
lpappso life can work without it.08:49
bluelightningwell, we cannot, sorry08:49
lpappyes, you can.08:49
bluelightningI don't see why it should be so hard to ensure /dev/shm exists and has the correct permissions08:49
lpappit only means a different backend.08:49
lpappbluelightning: then why have you not spoken up for about a day?08:50
lpappthe issue has been discussed here several times.08:50
lpappanyway, I am filing a bugreport.08:50
bluelightningwe have had several different concurrency mechanisms in bitbake over the years, and this one is the one that functions most efficiently and effectively08:50
lpappfor _you_08:50
lpappbut not for many others users08:50
bluelightningfor the majority of users08:50
lpappso please do not demand non-functional stuff for users.08:50
lpappyeah, whatever.08:51
lpappbugtracker does not only exist for your top priority bugs08:51
bluelightningyou assume that your experience is mirrored by a large number of others; I can assure you that in my experience helping users it is not08:51
*** mihai <mihai!~mihai@> has joined #yocto08:51
lpappoh, so your perception is right?08:51
lpappbut others' are not08:51
lpappnice joke.08:52
lpappmany users who tried to help me (pro users, that is), could not help.08:52
rburtonlpapp: all you need is a tmpfs in the right place.08:52
bluelightningmy perception is based upon years of experience helping users to use the system08:52
lpappyeah, so let us get the next users with the very same issues who are forced for silly debian chroot to suck.08:52
lpappand go away from the project because it is not working.08:52
lpappthat will be so beneficial for Yocto08:53
RPlpapp: You are the first person who has ever complained that bitbake should not be using shm (and as a bitbake maintainer, I'd likely have seen such complaints)08:54
rburtonlpapp: if SHM is broken in your chroot, you'll have great trouble running a lot of software. fix your chroot and bitbake will work.08:54
lpappRP: you are free to help me to fix it.08:56
*** belen <belen!Adium@nat/intel/x-hkoebosgyhryaidf> has quit IRC08:56
lpappI just do not have yet another day trying to fix it, honestly.08:56
lpappand I am very close to stepping away because pretty much there is no existing Yocto setup which actually works08:56
lpappI have been trying to make it work for a week in full time.08:56
rburtonlpapp: you've tried 1) an unsupported distro and 2) a broken chroot08:56
rburtonlpapp: *everyone else* in here is clearly using it fine08:57
lpappRP: and what you have seen does not mean there are no more.08:57
yoctiBug 4925: normal, Undecided, ---, richard.purdie, NEW , Add an alternative backend for IPC communication08:57
rburtonlpapp: as you're running arch, try systemd-nspawn08:57
lpappit is totally irrelevant to systemd-nspawan08:57
lpapprburton: no software is broken in my chroot just as I wrote.08:58
rburtonlpapp: anything that uses SHM will be broken08:58
lpappthe ones I actually use08:58
lpapprburton: please do not come with theoretical issues08:58
lpappwe live in a practical world.08:58
lpappwhere we need to solve problems.08:58
rburtonlpapp: listen for a minute.  your problem is that the chroot isn't correctly configured - specifically your /dev/shm is broken.  systemd-nspawn will effectivly boot the guest and in that process, init /dev/shm08:58
rburtonthat's the point, the joy, and reason for systemd-nspawn to live08:59
*** belen <belen!~Adium@> has joined #yocto08:59
rburtonchroots are *known* to have all sorts of fun problems as they don't actually boot08:59
lpappI am not sure how to put it clearly,08:59
lpappchroot *should* just work with proper bind mounts which I think I kinda have.09:00
lpappnspawn *would* probably have another issues on its own09:00
rburtonyou clearly don't have the right mounts if the permissions are wrong09:00
lpappnot to mention, I have a *lot* more experience with chroot.09:00
lpappit is "fun" to see how people argue against solution proposals, but they do not provide anything better.09:01
bluelightninglpapp: you asked for help, we're giving you advice, if you ignore it then you're on your own09:02
rburtoni've proposed 1) let us help you fix your mounts or 2) try systemd-nspawn09:02
rburtonbut now i'm going to have a run09:02
lpapprburton: 1) sorry, where?09:02
*** rburton <rburton!> has left #yocto09:02
lpapp2) Dropping what you have instead of fixing it is *not* a proposal.09:03
lpappit is a totally valid use case to use chroot for such things.09:03
*** belen <belen!~Adium@> has quit IRC09:03
lpappso, if you cannot help fixing the chroot stuff, please just implement an alternative backend when you get there.09:04
*** laur1 <laur1!~lau@> has joined #yocto09:04
*** romain_ <romain_!d96c30f9@gateway/web/freenode/ip.> has joined #yocto09:04
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.> has joined #yocto09:14
lpappbluelightning: what advice have you provided for fixing the shm mount?09:18
lpappand its writability.09:18
lpappI just went through the log, but I have not found anything.09:18
*** panda84kde <panda84kde!> has joined #yocto09:19
bluelightninglpapp: make sure it's mounted and you have write permissions there?09:20
lpappbluelightning: oh, really?09:23
ndeclpapp: how did you mount it?09:23
lpappI would not have thought that.09:23
lpappbluelightning: the question is _how_.09:23
lpappwe all know what the end result should be.09:23
lpappndec: check the bugreport.09:23
bluelightninglpapp: it's not really up to us how you set up your chroot environment09:25
ndeclpapp: ok... can you tell me again which #BUG it is?09:25
ndecit's lost in the huge irc backlog ;-)09:25
lpappndec: 09:55 < yocti> Bug 4925: normal, Undecided, ---, richard.purdie, NEW , Add an alternative backend for IPC communication09:26
yoctiBug normal, Undecided, ---, richard.purdie, NEW , Add an alternative backend for IPC communication09:26
lpappbluelightning: oh, it is not really up to make users' life easier?09:26
lpappto you*09:26
lpappthat is a very disappointing mission statement.09:26
ndeclpapp: you don't seem to mount /run/shm...09:27
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto09:27
ndecor the bug report is wrong.09:27
lpappndec: /run is mounted.09:27
bluelightninglpapp: /run is not /run/shm09:28
ndecwhat's not what i said .09:28
lpappit is09:28
lpappbut even then, I tried this: mount --bind /dev/shm /media/wheezy/run/shm09:28
*** JimBaxter <JimBaxter!> has quit IRC09:28
lpappthere is no point in mounting recursively, really.09:28
ndecnone on /run/shm type tmpfs (rw,nosuid,nodev)09:28
bluelightninglpapp: I'm afraid there is09:28
ndecand to be monone on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)09:28
ndecnone on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)09:28
ndecnone on /run/shm type tmpfs (rw,nosuid,nodev)09:28
ndecre complete09:28
ndecoops.. to be more 'complete' that was.09:28
lpappwhy that will not work is simply because it is not bind mount.09:29
lpappsee my command above please.09:29
ndecthat's from a working LXC container, where I can build OE.09:29
lpappthe bugreport is not meant to be a chroot manual though09:29
lpappit is meant to be a feature extension for a better future for people having such issues09:30
lpappso I would not like to hijack it into chroot bugfixing.09:30
lpappthat is why I did not provide all the details in there, just one of those.09:30
lpappadded this information though09:31
lpappndec: and it is 755 after that bind mount09:32
ndeceven if someone one day will accept to implement a new IPC .. which i doubt, that won't happen today. so you need to fix your chroot issue, should you want to make a build at some point.09:32
lpappand I cannot change that09:32
lpappI would not be so sure about that.09:32
ndecso, i would agree 'more' on asking yocto to provide a 'manual' to setup a chroot. that seems more reasonnable to me.09:33
lpappbut yes, obviously, it is a long term plan.09:33
lpappyou cannot provide manual for each chroot/spawn host / guest combination ...09:33
lpappyou would go haywire ...09:33
lpappso to me, that seems less reasonable. :)09:34
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC09:36
*** JimBaxter <JimBaxter!> has joined #yocto09:37
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto09:37
lpappnot even Ubuntu 12.10 is supported. :(09:43
lpappWARNING: Host distribution "Ubuntu 12.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.09:43
bluelightninglpapp: with which version now?09:43
lpappRequest account09:45
lpappYour account request has successfully been sent and is now pending review. A confirmation email has been sent to your e-mail address.09:45
lpappI thought I could help with the wiki09:45
ndeceven danny seems to have 12.10 support, at least from git.09:48
lpappapparently, it is not simply a fire and help us09:59
lpappndec: as dany a09:59
lpappas danny and dylan are fully broken for cross compilation09:59
lpappour best bet is denzil09:59
lpappwhich was not fully broken09:59
lpappthe regression was not yet introduced in there.10:00
lpappand since we do not have shm alternative10:00
lpappand since I do not know how to make chroot work10:00
lpappI got an access to an ubuntu machine over ssh.10:00
bluelightninglpapp: sorry but it's completely incorrect to say "danny and dylan are fully broken for cross compilation"10:00
lpappoh, really, so I am not having any issues with it then?10:01
lpappI just imagine them?10:01
bluelightningno, you imply that it is not capable of cross-compilation; the fact of the matter is many, people use those versions daily to cross-compile10:01
lpappalongsidfe other people who can reproduce those issues?10:01
lpappI am not referring to the "many people doing cross-compilation"10:01
bluelightningyou've had problems specifically with external toolchains, that doesn't mean you can't cross-compile10:02
lpapplet us not play word games.10:02
lpappI am clearly referring for my scenario.10:02
lpappyes, it means10:02
lpappI also had problems with internal toolchains10:02
lpappI even wrote them here.10:02
lpappfor me, there is no any setup where Yocto would work so far.10:02
lpappwith cross-compilation.10:02
lpappsorry for putting it this way, but Yocto is immature for me at this point.10:04
lpappand for those who can reproduce the issues.10:04
lpapphopefully, this will improve over time.10:04
bluelightningI'll make it clear as I have done so before, you make things harder for yourself by using host setups that aren't well-tested10:05
bluelightningbefore you say anything I know you have had other problems10:05
bluelightningbut at least half of the major problems you have had have been due to the host environment you have chosen10:06
lpapphuh, not?10:06
lpappactually, there has not been any arch specific issue so far that I can recall.10:06
lpappnot in master HEAD that is.10:06
*** volker <volker!> has joined #yocto10:07
lpappbut feel free to back your statement about this as it is unclear for me, the arch user.s10:07
lpappcould you please show me _any_ issue that was arch specific?10:08
bluelightninghow about the issue you had with host gcc 4.8? I'm still unclear on how you got that given that the patch is already in dylan for that one10:08
lpappI did not have any of that?10:09
lpappsince I am not using 4.8?10:09
lpappwe are using gcc 4.3.3 ?10:09
lpappwhat CS ships ?10:09
ndecyou are confused between host and target gcc10:10
lpappperhaps you are confusing me with net147?10:10
lpappndec: no, not at all10:10
ndecyes. you are.10:10
lpappndec: host toolchain for building for the target *is* from code sourcery10:10
lpappit would work even if there was no any toolchain installed on my arch for native x86 builds.10:10
ndecbluelightning told you about host gcc 4.8, and you answer you use gcc 4.3.3, which is the target gcc.10:10
bluelightninglpapp: I'm referring to when you switched to the internal toolchain10:10
lpappthat is where you are wrong.10:10
lpapp4.3.3 is *explicitly* not the target gcc10:10
lpappit is the x86 ELF 32 binary for the *host*.10:11
bluelightninglpapp: and no matter what, for building native tools you *are* using your native gcc 4.810:11
lpappyou seem to not understand how this works.10:11
ndecyes, it is...10:11
ndecwell, let me have some doubts about that...10:11
lpappbluelightning: internal toolchain has never been a plan to be used.10:11
lpappbluelightning: as I stated clearly, it is a complete no go10:11
lpappaccording to everyone here.10:12
lpappI made a test for out of the curiosity, but I could not care less about it.10:12
lpappso again, what issue can present for arch for the intended goal?10:13
lpapp(to get back on track)10:13
lpappmind pasting a bugreport or irc note?10:13
lpappor even email thread.10:13
* ndec lunch...10:13
bluelightninglpapp: I was including your recent attempts to use a debian chroot without completely setting it up10:14
lpappbluelightning: that is also not an intentional final goal.10:14
lpappthe final goal is to get 4.3.3 from CS and Arch 64 bit host working.10:15
lpappI do not see any arch specific issue for that.10:15
lpappand I do not think the chroot is arch specific issue either10:15
lpappI would have the same trouble on other "supported" hosts, as well.10:15
lpappI just do not see what arch specific issue happened in here for arm2009q110:15
lpappperhaps, you are right, I just need to understand.10:16
lpappto me, all the issues look generic.10:16
*** belen <belen!~Adium@> has joined #yocto10:17
bluelightningmy original point was, cross-compilation *does* work10:18
bluelightningif it did not nobody would use our system10:18
bluelightningand many successfully do10:18
bluelightningwe know there is a problem with external toolchain support out of the box with recent versions10:18
bluelightningand there are folks working on that problem10:19
bluelightningin the mean time, while I'm in here arguing with you I'm not getting any actual work done10:20
lpappactually CS cross-compilation does not work10:21
lpappand everyone could reproduce the issue.10:21
lpappnot with oe-core which belongs to Yocto.10:21
lpappbut I had more problems than that, correct.10:22
lpappnone of it is Arch specific though.10:22
lpappthose are general issues.10:22
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC10:22
lpappbluelightning: the problem is that you should not argue.10:22
lpappyou claim me being wrong, even though the bugreports are accepted by the decision makers, so probably not, and then you wonder if I try to clarify my statement in more details.10:23
bluelightningwhen someone is potentially misleading other people about the state of our project, sure I'll argue10:23
lpappfacts are speaking for themselves.10:24
lpappno need to "mislead".10:24
lpappand that is the impression from the comments on my blog post as well.10:24
lpappit is not just me thinking that Yocto is not yet mature as it is.10:25
lpappfor embeddded cross-compilation.10:25
lpappit is not just my opinion10:25
lpappand it is possibly not just me filing the bugreports, and spending a lot of time with improving things.10:25
*** e8johan <e8johan!~quassel@> has joined #yocto10:25
*** volker <volker!> has quit IRC10:28
lpappjust in case:
yoctiBug 4927: normal, Undecided, ---, saul.wold, NEW , Make Archlinux a supported host distribution10:30
*** volker <volker!> has joined #yocto10:30
RPlpapp: Remember that the people trying to help you *are* some of the decision makers on this project. Filing bug reports is good, I totally encourage that however it doesn't mean that they are verified as an issue or that people can find the time/resources to work on fixing them. I agree in an ideal world we should however the world is imperfect10:31
lpappRP: they were verified as issues yesterday.10:31
lpappRP: people were spending a day with one of them to be fixed.10:32
lpappit is just that critical...10:32
lpappcurrently 4923 is sitting on my as a blocker for arch10:34
lpappotherwise I would not need to use Ubuntu, or even Debian.10:34
*** mike23434 <mike23434!53eead1d@gateway/web/freenode/ip.> has joined #yocto10:36
*** ChanServ sets mode: +o RP10:40
RPWelcome to the Yocto Project | Learn more: | Join the community: | Yocto 1.4 (dylan) Released! | Channel logs available at
*** RP changes topic to "Welcome to the Yocto Project | Learn more: | Join the community: | Yocto 1.4 (dylan) Released! | Channel logs available at"10:41
lpappRP: thanks10:43
lpappI requested this a few days ago to be compliant with the freenode rules.10:43
lpappnice to see it happening.10:43
bluelightninglpapp: the delay was because he's on holiday and he's the only one with the ability to change it10:44
lpappbluelightning: the log could have been blocked in the meantime.10:44
lpappbluelightning: but it is solved now anyway10:44
bluelightninglpapp: I'll point you to the freenode connect message which clearly states "you may wish to keep a notice in the topic" not "you must"10:46
bluelightninglpapp: not that it's not a good idea, but let's be clear about what's stated10:46
lpappbluelightning: you might wanna contact #freenode then.10:49
lpappI have not seen a channel yet the last 10+ years who have not followed this btw.10:50
lpappit is not even ethical to publish private information about people without their agreement.10:51
bluelightningthis is not private information10:51
RPregardless, the link is in the topic now10:52
bluelightningright, and we have a pointer on our IRC page on the website10:52
lpappIf you're publishing logs on an ongoing basis, your channel topic should reflect that fact. Be sure to provide a way for users to make comments without logging,10:52
lpapp"Be sure"10:52
lpappRP: yes, thanks.10:53
*** laur1 <laur1!~lau@> has quit IRC10:58
*** swex_ <swex_!~swex@> has joined #yocto11:03
*** swex <swex!~swex@> has quit IRC11:03
*** e8johan <e8johan!~quassel@> has quit IRC11:09
ant_workjust FYI there is another log service at
ant_workthis covers #oe as well11:10
lpappant_work: good catch11:11
lpapplet me raise the issue there.11:11
*** volker <volker!> has quit IRC11:11
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC11:13
ant_work * Topic for #mtd is: fish11:17
ant_work* Topic for #mtd set by ChanServ! at Thu Mar 21 19:21:28 201311:17
ant_workI don't dare bother them ;)11:18
*** zeeblex <zeeblex!~apalalax@> has quit IRC11:18
ant_work(is not on freenode)11:18
*** zeeblex <zeeblex!~apalalax@> has joined #yocto11:19
*** laur <laur!lau@nat/intel/x-ouppzaobsewphxqq> has joined #yocto11:27
lpappright, so tmp does not contain the packagers per layer...11:31
lpappthat makes it very hard to verify the build results.11:31
ant_worklpapp: long long ago there was a wiki page like that11:34
ant_workbut it has happened that most tools are now built as -native packages11:34
*** smartin_ <smartin_!> has joined #yocto11:34
*** smartin <smartin!> has quit IRC11:35
*** honschu_ is now known as honschu11:35
lpappnot sure how that is related to my comment,11:35
lpappI would like to verify the layers one by one.11:36
ant_workis about your generic Arch stuff11:36
lpappI am more confused now. :)11:36
ant_worktake the time to open the link I posted ;)11:36
lpappI did, but it is actually fully outdated.11:37
lpappso did not bother to spend my time with it.11:37
ant_worksure, any similar page would be inesorably out of date11:37
*** belen <belen!~Adium@> has quit IRC11:37
*** Stygia <Stygia!> has joined #yocto11:38
lpappor is Yocto only supposed to build a distro image?11:38
lpappwhere can I find it?11:38
ant_workthe packages are split per ARCH11:39
ant_worknot per layer11:39
lpappthose are not exclusive ...11:39
lpapp-> /tmp/deploy seems to be the right stuff.11:40
ant_workthat's only for images/bootloaders11:40
ant_workthe packages are i.e. under /ipk11:40
*** igrigorx <igrigorx!6d644604@gateway/web/freenode/ip.> has joined #yocto11:45
*** igrigorx <igrigorx!6d644604@gateway/web/freenode/ip.> has quit IRC11:51
*** Net147 <Net147!> has joined #yocto11:53
*** panda84kde <panda84kde!> has quit IRC11:54
*** zerus <zerus!> has joined #yocto11:54
*** joeythesaint <joeythesaint!> has joined #yocto11:58
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto12:03
*** zecke <zecke!> has joined #yocto12:10
*** mulhern <mulhern!> has joined #yocto12:15
*** zerus <zerus!> has quit IRC12:16
*** panda84kde <panda84kde!> has joined #yocto12:18
*** belen <belen!~Adium@> has joined #yocto12:20
*** jackmitchell <jackmitchell!> has quit IRC12:23
* wmat gets more coffee :/12:32
*** Stygia <Stygia!> has quit IRC12:34
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto12:38
*** forcev <forcev!> has quit IRC12:40
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto12:44
*** frank <frank!~frank@> has joined #yocto12:50
*** frank <frank!~frank@> has quit IRC12:56
-YoctoAutoBuilder- build #39 of buildtools is complete: Failure [failed Building Images Publishing Artifacts] Build details are at
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-zgisxyzprsayfldl> has joined #yocto13:02
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fzhjnvjqxfmuxntx> has joined #yocto13:04
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has joined #yocto13:11
fenrigHi, I'm having trouble with imx53 (freescale) and having a /dev/fb013:11
*** behanw <behanw!> has joined #yocto13:18
mike23434witch recipe contains python libxml2 module? "python-lxml" don't work for me. I can't cross compile mesa because it requires it.13:19
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fzhjnvjqxfmuxntx> has quit IRC13:19
-YoctoAutoBuilder- build #226 of nightly-non-gpl3 is complete: Success [build successful] Build details are at
*** andyross <andyross!> has joined #yocto13:19
*** zecke <zecke!> has quit IRC13:22
-YoctoAutoBuilder- build #220 of nightly-x86-64-lsb is complete: Failure [failed Building Images] Build details are at
bluelightningmike23434: hmm, our mesa recipes in OE-Core don't need python-lxml to build AFAIK13:22
mike23434I'm not using OE-Core mesa recipes, I want to cross compile upstream mesa+etnaviv driver (vivante graphics in imx6)13:24
bluelightningmike23434: ah ok, so it is extra functionality you're enabling that needs python libxml2 bindings?13:25
*** zeeblex <zeeblex!~apalalax@> has left #yocto13:26
*** __frank_ <__frank_!~frank@> has quit IRC13:27
*** __frank_ <__frank_!~frank@> has joined #yocto13:28
mike23434glapi/gen regires libxml2, libxml2-python is mesa depency from january 201313:28
*** andyross <andyross!> has quit IRC13:32
bluelightningmike23434: hmm, looks like libxml2-python and lxml are two different things, I guess that explains why python-lxml doesn't work13:32
bluelightningmike23434: I think you may have to write a new recipe for that, but presumably you could use the python-lxml recipe as a starting point13:32
mike23434great :) how do you build mesa witchout it?13:36
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC13:37
lpappis it possible to get an image generated rather many small stuff?13:38
ndeclpapp: what is a 'small stuff'?13:38
lpappsorry, I got off for two hours13:39
lpappwe had a barbacue party. :-P13:39
ndecthe image is generated at the end of the build, when all packages are built.13:39
lpappok, so there are many small packages _and_ also the image?13:39
lpappfair enough13:39
ndecin tmp/deploy/images13:40
ndecyou have to 'bitbake' an image, of course.13:40
ndecimage are .bb files too, which has a different 'task set', and include a do_rootfs() task.13:40
ndecthat's one of them. yes.13:41
mike23434bluelightning: can i put it to some common place that nobody has to do it again after i create new recipe?13:42
*** hollisb <hollisb!> has joined #yocto13:43
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-bpqxjakwberemvgu> has joined #yocto13:44
lpappis the "tmp" layout documented somewhere?13:45
bluelightningmike23434: certainly, it would be great if you could add it into the meta-oe layer and send a patch to that does that13:46
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-bpqxjakwberemvgu> has quit IRC13:49
*** volker <volker!> has joined #yocto13:55
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC13:56
*** munch <munch!> has joined #yocto14:05
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto14:08
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fmsgmynwqumvjxxs> has joined #yocto14:13
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto14:17
lpappndec: I do not find u-boot.bin inside the /tmp folder. How can I debug it why not?14:17
lpapprun bitbake on that particular package only?14:17
ndeclpapp: does your machine specify that it needs uboot?14:17
lpappndec: ?14:18
lpappshouldn't all the recipes be built by default?14:18
ndecbitbake only builds what it is asked to build.14:18
ndecdefine 'all'?14:19
lpappall means all14:19
lpappcannot explain more14:19
lpappall the .bb stuff in every layer14:19
lpappthat belongs to a particular image.14:20
lpappI thought u-boot would be included in core-image-minimal?14:20
*** tsjsieb <tsjsieb!> has quit IRC14:23
ndeclpapp: u-boot is a machine specific param. some machine don't need it.14:26
-YoctoAutoBuilder- build #103 of nightly-qa-systemd is complete: Success [build successful] Build details are at
bluelightninglpapp: your machine config should do EXTRA_IMAGEDEPENDS += "u-boot"14:26
bluelightninglpapp: this is what meta-yocto/conf/machine/* do14:27
lpappbluelightning: also x-load, I believe.14:27
*** Corneliu <Corneliu!c0c69724@gateway/web/freenode/ip.> has joined #yocto14:27
bluelightninglpapp: in the case of beagleboard, yes; and if that's valid for your board, that too14:28
bluelightningant_work: no, EXTRA_IMAGEDEPENDS because it's not to be installed in the image, just built alongside it14:28
ant_workthe policies are in the manual14:28
ant_worksorry, I ssaw uEnv.txt is installed like this14:29
ant_workI meant target part14:29
ant_workanyway it's all in the FM14:29
*** fitzsim <fitzsim!~user@nat/cisco/x-ioyofluolunadyzh> has joined #yocto14:30
*** zecke <zecke!> has joined #yocto14:30
*** Corneliu <Corneliu!c0c69724@gateway/web/freenode/ip.> has quit IRC14:31
*** eren <eren!~eren@unaffiliated/eren> has quit IRC14:36
*** mckoan is now known as mckoan|away14:37
*** joshkurland <joshkurland!6b00909c@gateway/web/freenode/ip.> has joined #yocto14:42
*** zeddii <zeddii!~ddez@> has joined #yocto14:46
*** Umeaboy <Umeaboy!> has joined #yocto14:47
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC14:47
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.> has quit IRC14:47
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto14:48
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has quit IRC14:52
lpappis it enough to just rebuild?14:52
lpappafter uncommenting the EXTRA_IMAGEDEPENDS line?14:52
lpappI mean without deleting anything.14:53
lpappwill I get the u-boot.bin stuff?14:53
*** mike23434 <mike23434!53eead1d@gateway/web/freenode/ip.> has quit IRC14:53
*** andyross <andyross!> has joined #yocto15:00
*** davest <davest!~Adium@> has joined #yocto15:01
lpappbluelightning: ndec ^15:03
ndeci never delete everything15:04
lpappERROR: Nothing PROVIDES 'u-boot'15:06
lpappERROR: u-boot was skipped: because UBOOT_MACHINE is not set15:06
lpappERROR: u-boot was skipped: because UBOOT_MACHINE is not set15:06
lpappERROR: u-boot was skipped: because UBOOT_MACHINE is not set15:06
lpappERROR: u-boot was skipped: because UBOOT_MACHINE is not set15:06
lpapphmm, apparently, I would need to set that, too.15:06
lpappERROR: Required build target 'core-image-minimal' has no buildable providers.15:07
lpappMissing or unbuildable dependency chain was: ['core-image-minimal', 'u-boot']15:07
lpappbluelightning: has no machine ...15:08
lpappI figured out the meta-sourcery issue15:09
ndecit's a DISTRO layer.15:09
lpappsilly meta-sourcery is demanding an empty folder15:09
lpappwhich is not present for me as we use git15:09
lpappand git does not track empty folders15:09
bluelightninglpapp: my mistake, meta-yocto-bsp/conf/machine/*15:10
lpappwhy on earth does CS ship an empty folder :D :D15:10
lpappbluelightning: yeah, I just grepped in the root, and that helped to figure out meta-yocto-bsp15:10
bluelightninglpapp: re your earlier question, no need to delete anything, no15:10
lpappit does not document UBOOT_MACHINE ...15:11
lpappnor does the reference guide.15:11
*** ant_work <ant_work!> has quit IRC15:12
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fmsgmynwqumvjxxs> has quit IRC15:12
bluelightninglpapp: we can't really be expected to document every possible bootloader in the BSP guide15:12
lpapplooks like a bugreport15:12
lpappbluelightning: the variable could be defined!15:12
*** Net147 <Net147!> has quit IRC15:13
yoctiBug 4928: normal, Undecided, ---, saul.wold, NEW , No documentation for UBOOT_MACHINE15:14
*** sameo <sameo!~samuel@> has quit IRC15:17
-YoctoAutoBuilder- build #223 of nightly-x86-64 is complete: Success [build successful] Build details are at
*** ynezz <ynezz!> has quit IRC15:17
Sputlpapp: btw, several developers here use Yocto on Archlinux just fine. and on Gentoo, Debian, SuSE and kubuntu...15:17
lpappSput: me and a few others are not those developers though.15:18
lpappbluelightning: what should I put into UBOOT_MACHINE?15:18
*** ynezz <ynezz!> has joined #yocto15:18
Sputlpapp: well, just mentioning it because in your blog you mentioned it doesn't work and resort to a chroot instead. but it's definitely possible...15:20
lpappSput: if it is definitely possible, let me know how.15:21
bluelightninglpapp: looking at the recipe, it's whatever you would specify as the machine config on the u-boot make command line15:21
lpappit just does not work for us.15:22
lpappSput: and people could reproduce issues following my instructions.15:22
Sputweird. only issue I am aware of that happened here was that gcc 4.8 on the Arch host couldn't build gcc 4.7 on target, but that was fixed afaik15:22
Sputand sometimes you need to install some -native packages because the host tools are too new (bibtex-native comes to mind)15:23
Sputnot bibtex, what was it called?15:23
*** ynezz <ynezz!> has quit IRC15:23
*** ynezz <ynezz!> has joined #yocto15:24
ndecSput: lpapp initially was using denzil (or danny). which might not have the most recent fixes from master.15:24
ndecit probably gets harder and harder to use Arch for stable OE releases, as time pass.15:24
lpappSput: as I wrote in my posts implicitly, we do not use 4.815:24
lpappand we do not do native builds.15:24
lpappthat is kinda the crucial part of the post, really. :)15:25
Sputwell, that might be true (but that's probably also true for other distros)15:25
Sputlpapp: install native packages so Yocto has proper versions15:25
ndeclpapp: i am sorry.. but you are still confused by native vs host vs target...15:25
Sputno reason not to do it to make things work :)15:25
lpappSput: what do you mean?15:25
ndecSput: sure... but it depends if you want to use OE, or fix it ;-)15:25
lpappndec: dude, I have been developing for embedded for years15:25
lpappyou presented yesterday the confusion about native vs. internal.15:26
Sput-native packages go into the native sysroot. so if your host docbook or whatever it was is too new, you can still install the older version into the native sysroot, so Yocto can useit.15:26
ndeci have no doubt. but you are confused about these terms in OE.15:26
lpappusually people do native builds on arch15:26
lpappi.e. for x86 or x86_6415:26
lpappnot arm, whatsoever.15:26
lpappand that is exactly what I meant.15:26
lpappso for a very simple scenario it may work.15:27
lpappbut we are kinda ... building a next generation stuff with bleeding edge technology.15:27
Sputso are we. which is why we use the newest poky, actually15:27
Sputand have contemporary distros and not some LTS stuff :)15:27
lpappSput: that is the other thing, we do not use the newest poky.15:28
lpappwe already have a technology in place.15:28
lpappas you may know, switching core components of the stack is not 2 pounds.15:28
*** ynezz <ynezz!> has joined #yocto15:28
Sputit's not so much next generation bleeding edge then :)15:29
lpappbluelightning: right, thanks.15:29
lpappbluelightning: make foo -> foo goes to UBOOT_MACHINE15:29
lpappbluelightning: so it is probably doing MAKE $UBOOT_MACHINE in the background then.15:29
*** seebs <seebs!> has quit IRC15:29
lpappSput: it is.15:29
lpappno one has done anything yet as such.15:29
lpappand we are the number one in this industry as far as I can tell.15:29
bluelightninglpapp: that's effectively what it does yes15:29
lpapphope we can keep that position. :-)15:30
lpappall my energy goes into that.15:30
*** seebs <seebs!> has joined #yocto15:31
Sputwell, dylan fixed lots of issues for us, so you might want to consider an upgrade nonetheless15:31
lpappnot for now, no.15:32
lpappmeta-sourcery is currently broken.15:32
lpappand it has been blocking me.15:32
lpappit requires empty folders for reading, etc. :)15:32
lpappfunny, really.15:32
lpappit has to become mature before we will switch to it.15:32
lpappwhat would be more worthy is the toolchain upgrade.15:32
lpappto get C++11/C++14 features15:33
Sputwe also appreciated more or less proper systemd support15:33
lpappbluelightning: do we need to specify the enty point and load address, too?15:33
lpappbluelightning: ah, you meant this, ../meta/recipes-bsp/u-boot/       oe_runmake ${UBOOT_MACHINE}15:34
bluelightninglpapp: I have limited experience with u-boot, but based on other machine configs, probably yes15:35
lpappbluelightning: really strange.15:36
lpappbecause it is not necessary for building u-boot separately.15:36
lpappit is only necessary for things like openocd.15:37
lpappor when you update it over tftp.15:37
lpappperhaps it is possible to hard code the address into u-boot15:37
lpappwhich then cannot be changed later.15:37
lpappwhich might be just an optional feature if you otherwise plan to specify that separelty at flashing/updating time.15:37
bluelightningnot sure I'm afraid15:37
*** joshkurland <joshkurland!6b00909c@gateway/web/freenode/ip.> has quit IRC15:37
*** TuTizz <TuTizz!~TuTizz@> has quit IRC15:38
*** Guest67693 <Guest67693!~tbn@> has quit IRC15:39
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto15:39
*** darknighte_znc is now known as darknighte15:40
lpappbluelightning: it is ok15:41
*** Umeaboy <Umeaboy!> has quit IRC15:41
*** eballetbo <eballetbo!> has quit IRC15:41
lpappSput: btw, the issues are not arch related.15:42
lpappthere are general immatureness.15:42
lpappbut since I am now involved in full-time with fixing it for myself.15:42
bluelightningI think you go too far with accusations of immaturity15:42
lpappIt might be easier to move forward on this front.15:42
Sputoh, yes, there are many issues (but many have been fixed in the past two poky releases, too), not disputing that15:42
SputI was just referring to your claim that Archlinux is the problem, which it isn't.15:42
lpappthey are the issues with poky master HEAD fwiw15:42
lpappand meta-sourcery master15:43
lpappSput: the problem is that with archlinux, they do not support it.15:43
seebsOne thing I like to do when I need help from people who are familiar with a given project is use terms with strong negative connotations a lot, because people who feel insulted are much more likely to be cooperative and helpful.15:43
lpappnot even a single configuration.15:43
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nlwtupnnxapzfsaf> has joined #yocto15:43
Sputwho cares about official support for any given distro? we're engineers, we can solve that15:44
lpappSput: it is all voluntary work if there are issues which is not a reliable solution for a company.15:44
Sputfor real Yocto issues, I've found the people in this channel always very helpful15:44
lpappSput: many companies including us, of course.15:44
lpappit is not about engineers15:44
lpappyou think a lower layer than the business happens.15:44
Sputlpapp: tbh, Archlinux is not a reliable solution for a company15:44
lpapp"fixing" yourself is a lot of cost.15:44
SputRHEL would be15:44
lpappwhich a manager will not take.15:45
lpappa manager will say (rightfully) to use a supported distribution.15:45
lpappbut that goes against the engineers' own wish.15:45
Sputwhen I chose to use Gentoo at work, I did that knowing that I could not go to our IT and demand support15:45
lpapparchlinux is a reliable solution15:45
lpapphave done business for 6-7 years with it.15:45
Sputbut then I'm also not complaining if the tools we use require tinkering on my end15:45
lpappagain, it is not about your money15:46
lpappyou do not decide.15:46
lpappthe stakeholders decide.15:46
*** TuTizz <TuTizz!~TuTizz@> has quit IRC15:46
lpappengineers wish.15:47
Sputwell, you use a rolling release distro with no enterprise support for professional purposes, and then go complaining that this distro isn't supported by a project like Yocto... doesn't sound too sane to me :)15:47
Sputyet you can make it work, if you invest the time to make it work15:47
lpappno no, that is untrue15:47
lpappI am *definitely* not using Arch for enterprise.15:47
lpappas discussed here the whole day, I was using debian, and since that did not work, I use Ubuntu 12.1015:47
lpappyou are way beyond the facts. :)15:48
lpappI would love to use Archlinux, but I cannot.15:48
lpappbecause no one sells the argument the engineer like it, but upstream has no any support for it.15:48
Sputah well, I'm happily using Gentoo and Yocto does what it's supposed to do if you fix the occasional quirk, so I'm rather happy with it15:48
lpappI would not buy it either.15:49
SputI worked with MeeGo before, I'm rather glad I can use Yocto now :)15:49
*** panda84kde <panda84kde!> has quit IRC15:49
lpappsome issue with my machine.15:49
lpappMeeGo and Yocto ...15:50
lpappapple and orange ...15:50
SputI like oranges more.15:50
bluelightninglpapp: the x-load recipe declares that it's only compatible with a set list of machines using COMPATIBLE_MACHINE15:50
seebsArlo N' Janis did that one something like 20+ year ago.15:50
seebsArlo: One is hard, smooth, and red. The other is softer, with a dimpled skin, and orange.  Janis: What are you doing?  Arlo: Comparing apples and oranges.15:51
lpapp16:45 < Sput> yet you can make it work, if you invest the time to make it work -> I do not live 100 hours a day15:52
seebsOh, there's your problem.15:53
lpappif I am not allowed to work with unsupported stuff which is a reasonable decision to be fair, I cannot put anything more into it.15:53
lpappI am already involved with tons of other FOSS stuff, and I have real life, too ... ;-)15:53
bluelightninglpapp: don't we all15:54
lpappand frankly, the lack of proper Qt5 bugs me a lot more than switching to ubuntu for now.15:54
lpappbluelightning: yes15:54
*** Umeaboy <Umeaboy!> has joined #yocto15:55
*** panda84kde <panda84kde!> has joined #yocto15:55
lpappI wonder if we really need x-load.15:55
lpappI am afraid, we do.15:55
lpappI might be wrong actually.15:55
lpappif it is this stuff, we probably do not,
lpappbut I bet it is different.15:56
bluelightningentirely dependent on how your machine boots15:56
lpappbased on this, u-boot requires x-load.15:57
lpapppage 2 -> boot up process.15:57
lpappbut it is using ROM15:58
lpappif I understand correctly, x-load is usually used with nand flashes.16:00
lpappwritten into that.16:00
lpappbut we use nor flash.16:00
ndecx-load is completely deprecated.16:01
*** davest <davest!~Adium@> has quit IRC16:01
-YoctoAutoBuilder- build #195 of nightly-fsl-ppc-lsb is complete: Success [build successful] Build details are at
lpappndec: well, beagleboard seems to use it though.16:03
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC16:03
-YoctoAutoBuilder- build #236 of nightly-x32 is complete: Success [build successful] Build details are at
ndechmm. that's weird..16:03
lpapp../meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf does not though.16:03
lpappI personally just flashed the u-boot with openocd, so I did not need x-load16:05
lpappand it worked, so I will drop that for now.16:05
lpappbut I would need to get a more thorough picture on the topic later.16:05
ndecyou don't need it, because it was probably already 'there' on the board. you can't boot with just uboot.16:06
lpappyou can.16:06
lpappit was not on the board.16:06
lpappndec: spl is in the u-boot tree.16:10
ndecSPL is the replacement for x-load16:10
lpappyes, it is coming with u-boot.16:10
*** davest <davest!~Adium@> has joined #yocto16:11
lpappwho is the u-boot maintainer for oe-core?16:13
lpappis s/he lurking around in here?16:13
*** francois99 <francois99!> has quit IRC16:15
*** romain_ <romain_!d96c30f9@gateway/web/freenode/ip.> has quit IRC16:15
*** mihai <mihai!~mihai@> has quit IRC16:18
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC16:19
*** davest <davest!~Adium@> has quit IRC16:24
*** zenlinux <zenlinux!> has quit IRC16:25
*** mr_science <mr_science!> has joined #yocto16:25
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:25
-YoctoAutoBuilder- build #65 of minnow-lsb is complete: Success [build successful] Build details are at
lpappbluelightning: ndec ^16:28
ndecdon't know16:28
*** smartin_ is now known as smartin16:31
*** synthnassizer <synthnassizer!~quassel@> has quit IRC16:35
*** davest <davest!Adium@nat/intel/x-segtebhgvikcacxw> has joined #yocto16:37
*** belen <belen!~Adium@> has quit IRC16:39
*** slaine <slaine!~slaine@> has quit IRC16:41
*** andyross <andyross!> has quit IRC16:44
*** andyross <andyross!> has joined #yocto16:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:45
* mr_science smells a high-speed timing test on the horizon16:49
mr_sciencehaving sata link issues with ~10% of the motherboards...16:49
*** mulhern <mulhern!> has quit IRC16:52
*** zerus <zerus!> has joined #yocto16:57
*** zenlinux <zenlinux!> has joined #yocto16:59
-YoctoAutoBuilder- build #226 of nightly-ppc-lsb is complete: Success [build successful] Build details are at
*** zerus <zerus!> has quit IRC17:01
*** conditionzero <conditionzero!~Unknown@2001:6f8:12d9:13:1e4b:d6ff:fedb:207c> has quit IRC17:04
*** davest <davest!Adium@nat/intel/x-segtebhgvikcacxw> has quit IRC17:04
*** panda84kde <panda84kde!> has quit IRC17:06
*** mulhern <mulhern!> has joined #yocto17:06
*** ka6sox is now known as ka6sox-away17:07
-YoctoAutoBuilder- build #224 of nightly-world is complete: Success [build successful] Build details are at
*** pidge <pidge!> has joined #yocto17:10
mr_sciencethe sucky part is the lack of response from TI on the plethora of SATA problems posted by customers...17:12
mr_sciencekinda makes me never want to buy another TI part ever again...17:13
lpappmr_science: have you tried e2e?17:13
lpappusually, they are very helpful in there.17:13
lpappmr_science: also, #linux-omap?17:14
mr_sciencebeen all over the TI e2e forums17:14
mr_sciencethey tend to leave them unanswered17:14
ndecmr_science: which board?17:15
mr_science816x/am389 family17:15
mr_scienceour board is based largely on the dm8168evm17:15
*** zenlinux <zenlinux!> has quit IRC17:16
mr_scienceoveral i am definitely *not* impressed with their support17:16
ndecoh. i didn't know there was sata there17:16
*** zenlinux <zenlinux!> has joined #yocto17:17
mr_scienceeverything seems to point to noise and/or timing issues17:18
mr_sciencelike i said, it's about a 10% failure rate on boards coming from the manufacturer17:19
lpappmr_science: can you show the forum url?17:19
mr_scienceand our little hardware test suite only tests that the RTC can save/increment the clock17:20
mr_sciencesata test uses the ddt filiesystem test17:20
lpappperhaps I have been lucky with TI, but I had excellent customer support.17:21
*** Umeaboy <Umeaboy!> has quit IRC17:21
lpappexcept the fact they do not wanna support C++11 for the TI toolchain, but that is hardly support issue.17:21
mr_sciencethat's the one i posted on, but there are tons of others...17:21
mr_scienceput "sata link" in the search box...17:22
mr_sciencehaven't asked in #linux-omap yet, so i'll try that...17:23
*** walters <walters!> has joined #yocto17:24
lpappmr_science: do not forget that it is holiday season btw.17:24
-YoctoAutoBuilder- build #229 of nightly-x86 is complete: Success [build successful] Build details are at
mr_scienceoutside th US you mean?17:33
lpappmr_science: yes17:34
lpappthere are many support guys in France for instance.17:34
*** davest <davest!Adium@nat/intel/x-alktwxtgnjrapnti> has joined #yocto17:35
b1gtunaMorning everybody! including x11 in DISTRO_FEATURES is giving me a grief. GTK+ is refusing to build. I'm on Dylan. What can I do?17:37
lpappb1gtuna: what is the build error?17:37
b1gtunalpapp: one sec i was just about to pastebinit17:38
b1gtunalpapp: thanks17:38
b1gtunalpapp: it's quite large17:39
b1gtunalpapp: i tried cleanall on gtk+, still occuring as long as I have x11 in DISTRO_FEATURES17:40
lpappb1gtuna: and can you confirm you do not have this, /home/ubuntu/build/tmp/sysroots/overo/usr/lib/libXinerama.la17:40
kergothcould be a missing dependency on xinerama17:40
kergothlpapp: I have a debootstrap running to test the /usr configuration on ubuntu to see if it works there. Don't have an arch chroot handy, but i expect it's the path that's the issue, rather than the host distro. we shall see17:41
b1gtunalpapp: ls: cannot access /home/ubuntu/build/tmp/sysroots/overo/usr/lib/ No such file or directory17:42
b1gtunalpapp: so nope it's not there.. =(17:42
lpappb1gtuna: do you have /home/ubuntu/build/tmp/sysroots/overo/usr/lib/ ?17:42
b1gtunalpapp: yes it contains a lot of .la, .so files17:44
kergothb1gtuna: check the gtk recipe for a dependency on xinerama17:44
lpappb1gtuna: ok, so it is probably a missing dependency17:44
lpappis there a proper bitbake manual somewhere?17:44
b1gtunakergoth lpapp - i see doing it now thx17:45
lpappthis comes up all the time when I look for one, but it is very short, and does not cover a lot of stuff:‎17:45
lpappRP: ^17:46 -> perhaps this one?17:46
lpappkergoth: right, I am trying to write a patch for the other issue now ...17:47
lpappI just need a helpful bitbake manual.17:47
b1gtunalpapp kergoth - no dependency on xinerama, will add it and try again17:48
kergoththe bitbake manual is in the middle of being rewritten17:49
kergoth is the old one17:50
kergothbut it mostly covers recipe syntax and bitbake command syntax, most everything else is oe/yocto, not bitbake17:50
lpappsee my last comment on 492317:51
lpappwe cannot do much on our side for now.17:51
lpappwe could switch away from git to some internal mirror, but meh.17:51
lpappI think distributing an empty folder is wrong from CS.17:52
*** zecke_ <zecke_!> has joined #yocto17:52
lpappbut since it cannot be fixed for 2013.05, it has to be solved somewhere.17:52
lpappand the logical workaround place looks meta-sourcery to me.17:52
lpappbecause that is the central place what everyone would probably use.17:52
kergothI already said in comment #4 that i'd add a check for it17:52
kergothand i will17:52
lpappwell, I can help with that.17:52
lpapponce I understand the bitbake stuff.17:53
kergothI do have a day job, you realize. supporting people on irc is only part of it17:53
kergothonly so many hours in teh day17:53
kergothfair enough17:53
lpappto be honest, 4923 is higher priority for me.17:53
lpappthan 492117:53
lpapp2013.05 is just a toy project at home.17:53
lpappthe real issue is 2009q1 what we use at the company.17:53
*** zecke <zecke!> has quit IRC17:54
* lpapp g2g17:54
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC17:54
sgw_lpapp can you please attach the run.do_install.8130 from your temp directory to 4923, I want to check some17:55
kergothalready left17:55
sgw_just missed him17:55
kergothhe's had a couple valid points, but in other cases his expectations are pretty out there17:57
* kergoth rolls eyes17:57
*** zenlinux <zenlinux!> has quit IRC17:57
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nlwtupnnxapzfsaf> has quit IRC17:59
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ibnylyfsmcojltvp> has joined #yocto18:01
-YoctoAutoBuilder- build #229 of nightly-x86-lsb is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #238 of nightly-mips-lsb is complete: Success [build successful] Build details are at
b1gtunakergoth: adding xinerama to gtk+'s DEPENDS seems to have fixed. Is this a bug?18:12
kergothsounds like it, do mention w hich releas eyou're using if you open an issue18:13
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto18:13
b1gtunakergoth: i will, great thanks18:13
JaMaHave anyone seen do_populate_lic_setscene task failing in sstate_install with cp: will not create hard link `/OE/deploy/licenses/recipe' to directory `/OE/deploy/licenses/recipe' (same path)18:17
lpappsgw_: 4923 already got a change which I can test next week.18:22
sgw_lpapp: Ok, I saw that.18:22
*** andyross <andyross!> has quit IRC18:27
*** andyross <andyross!> has joined #yocto18:28
b1gtunakergoth: should i post a patch or should i simply file through bugzilla?18:29
kergothup to you18:29
b1gtunakergoth: sweet ty18:31
-YoctoAutoBuilder- build #226 of nightly-ppc is complete: Success [build successful] Build details are at
*** mulhern <mulhern!> has quit IRC18:34
sgw_kergoth: if you have some time, can you look over Qi.Chen's RO ROOTFS changes, I know they would be of interest to you.18:35
kergothI haven't had time to read his reply on my thread even, neck deep in madness :)18:36
kergothwill do when i find a moment18:36
sgw_kergoth: thanks18:36
*** zenlinux <zenlinux!> has joined #yocto18:46
*** zenlinux <zenlinux!> has quit IRC18:51
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ibnylyfsmcojltvp> has quit IRC18:51
lpappkergoth: have you seen my comment on 492118:52
*** phdeswer_ <phdeswer_!> has joined #yocto18:54
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-husrscmbonahvvdw> has joined #yocto18:55
*** davest <davest!Adium@nat/intel/x-alktwxtgnjrapnti> has quit IRC18:57
*** davest <davest!~Adium@> has joined #yocto18:57
*** zecke_ <zecke_!> has quit IRC18:58
-YoctoAutoBuilder- build #229 of nightly-arm-lsb is complete: Success [build successful] Build details are at
mr_scienceb1gtuna: did building xinerama first fix it?19:02
* mr_science scrolling...19:03
lpappmr_science: yes19:03
mr_scienceyup, just found it...19:04
mr_sciencekergoth: those are the patches i mentioned before19:04
mr_sciencecouldn't remember his name, but Qi.Chen is correct19:05
*** andyross <andyross!> has quit IRC19:21
-YoctoAutoBuilder- build #198 of nightly-fsl-arm is complete: Success [build successful] Build details are at
*** tor <tor!> has quit IRC19:59
*** Jefro <Jefro!> has joined #yocto20:08
*** posborne <posborne!ccb603ec@gateway/web/freenode/ip.> has joined #yocto20:09
posborneHey all, as you know the default Yocto root password is empty.  I want to change this so that one exists, but I'm having some trouble tracking down how to do this.  My image has shadow, but I haven't seen anything obvious looking at recipes-extended/shadow20:13
sgw_posborne: what rev are you using?20:20
posborneI'm on Dylan20:22
-YoctoAutoBuilder- build #197 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
seebsI have a tentative patch (still testing it a bit) to improve the consistency of how NO32LIBS is handled in
seebsBasically, the proposed behavior is: If NO32LIBS is 1, we just don't try to do a 32-bit build, and we say so. If NO32LIBS is unset, we try to build 32-bit if and only if stubs-32.h exists. If NO32LIBS is 0, we check for stubs-32.h, and emit a warning if we don't find it.20:25
lpappthere should be no NO32LIBS20:26
lpappit should just work automatically IMHO.20:26
seebsAnd then the actual compilation is contingent on whether we think we want to try for it, and if it fails, we have a better diagnostic in view.20:26
seebsThe background here is that for the vast majority of 64-bit systems, there's no reason at all to build a 32-bit libpseudo, and requiring everyone to have a working multilib toolchain is ridiculous.20:28
seebsThe one case where 32-bit libpseudo is needed on 64-bit hosts is when there's a compelling need to run 32-bit binaries, and the one case where that tends to come up is prebuilt toolchains (like the Code Sourcery/Mentor Graphics ones).20:29
seebsThe original behavior was to try to build 32-bit if stubs-32.h existed, but this was a source of build failures and various problems in cases where there really wasn't any need to do this anyway.20:29
seebsProblem is, when we adopted the NO32LIBS configuration thing, we never removed the check for stubs-32.h, so you could have a configuration which thought it needed 32-bit libpseudo, but silently failed to actually build one and didn't mention that it was missing something it thought it needed.20:30
*** andyross <andyross!> has joined #yocto20:30
seebsSince a couple of echoes in the pseudo-native/pseudo-nativesdk output are cheap, and the confusions caused by problems with this have been expensive, I'm adding a little extra output, including a message warning the reader (if they happen to go looking, anyway) that only a 64-bit libpseudo is being built in the common case.20:32
seebsWill send out a draft patch for review soonish.20:32
lpappthe toolchain option specifies what to build already, especially it is 32 bit, there is any doubt what it is.20:32
lpappuname -m returns the host architecture20:32
lpappit should be pretty clear that it is trying to build 32 bit on a 64 bit host if "uname -m" return x86_64, and the toolchain binary is 32 bit ELF.20:33
sgw_posborne: There was a patch for master recently to allow that, and it was discussed on the oe-core ML20:33
lpappI do not see any reason why interaction would be necessary for it to work.20:33
lpappthis NO32LIBS feels like a hackaround, but not a real solution.20:33
sgw_posborne: for dylan I have no easy answer other than add some ROOTFS_POSTPROCESS_COMMAND to your image maybe that patches the passwd file20:34
seebsThe pool of programs which you *might* need to run, which could be 32-bit binaries, is extremely large. It's not restricted to the toolchain.20:34
seebsHeck, nothing prevents a user from having a 64-bit gcc executable which calls a 32-bit cc1.20:34
mr_scienceposborne: that's exactly what i so in the older bitbake world too20:35
lpappfile works for any important executables, which is in my case gcc only, that would need to be checked.20:35
lpappI vote for removing NO32LIBS altogether for my use case, at least, but I feel the potential for removal in certain other scenarios, too.20:36
mr_sciencei also made a pwgen native recipe and use it in my custom image function to generate the root password20:36
mr_sciencesince it goes along with adding a normal user with a known password...20:36
*** Jefro1 <Jefro1!> has joined #yocto20:39
mr_scienceposborne: let me know if you'd like to know any details (it's pretty straightforward)20:40
*** Jefro <Jefro!> has quit IRC20:41
*** mulhern <mulhern!> has joined #yocto20:42
posbornemr_science sgw_ Thanks, I'll look at the latest stuff.  Before I got pulled away from my desk I was starting to look into ROOTFS_POSTPROCESS_COMMAND20:52
b1gtunaHas anyone done gdm + xfce integration? Can't shutdown as a user. Kicks me back into the login screen instead.20:52
posborneRelated, is there a good way to trace backward from a file in the sysroot to see which recipe(s) touch it?20:52
lpappkergoth: have you made any progress on the arch chroot21:00
lpappor were you able to reproduce that on ubuntu21:00
lpappI need to leave soon.21:00
seebsYou mean 4919?21:01
seebsI went and looked more closely at that because I'd been looking at the command line options. The huge pile of incompatible library directories isn't even remotely related to anything Yocto's doing except specifying "-m32" to a compiler that's not configured to know to look elsewhere for 32-bit libraries.21:02
mr_scienceposborne: much easier to link the file to a package in the runtime21:02
seebsThe only -L in there is into a bitbake library directory which is in fact the correct directory for it to specify.21:02
mr_scienceusing opkg on the running system21:02
mr_scienceposborne: let me pastebin something...21:03
*** davest <davest!~Adium@> has quit IRC21:03
lpappno, not 4919.21:03
posbornemr_science: sure, whatever works21:07
mr_sciencethis relates root password thing as opposed to tracing a file...21:08
posbornemr_science: ah, gotcha21:08
mr_science  <=  this is at the bottom of my image recipe, with some other custom stuff21:08
mr_sciencelemme thing about the other one for a sec...21:09
mr_scienceas i said, easy to go from "opkg search /usr/bin/foo" to a recipe that builds the package21:10
mr_sciencetraceability from the sysroot is a bit different...21:11
mr_scienceposborne: if you tell me what the file is i might be able to answer, but i don't have a "query sysroot" answer to the bigger question atm21:12
mr_scienceunless it's a file from one your own in-house packages21:14
posborneSure, that is fair.  In this case, I was wondering about /etc/shadow21:14
mr_sciencethe recipe is also "shadow"21:17
mr_sciencein oe-core21:17
posborneRight, initially looking at the recipe, it was hard to see that it actually generated the file.21:18
posbornemr_science: thanks for the pastebin.  building an image now to test21:18
*** zenlinux <zenlinux!> has joined #yocto21:19
mr_scienceposborne: recipes typically don't even have a function for compile or install unless they need to do something special or apply a workaround21:22
mr_scienceso looking there is a little "iffy"21:22
mr_scienceOTOH, sometimes you'll find a whole bunch of manual install stuff and file/path jiggering21:23
mr_scienceit all depends on the condition of upstream21:23
mr_sciencewhich is probably pretty obvious so i'll shutup now21:24
posbornemr_science: haha, no problem.  the help has been appreciated21:27
mr_sciencemaybe i'm stilla little numb from my lovely meeting where i was the only linux guy...21:28
mr_sciencedon't think they learned a thing, so i can't call it successful, at least from my perspective21:30
*** zerus <zerus!> has joined #yocto21:30
posbornemr_science: I'm on a couple projects like that right now; nothing more fun telling people what to type in the terminal over the phone21:30
*** davest <davest!Adium@nat/intel/x-beddoaxteprkdsml> has joined #yocto21:32
*** mulhern <mulhern!> has quit IRC21:38
mr_scienceif that's all it was i'd never have mentioned it...21:40
mr_sciencewell, maybe...21:40
mr_scienceposborne: feel free to yell at me after hours (ping nerdboy) if you have more questions21:45
mr_sciencesince i have a pretty extensive set of custom_post_process stuff21:45
* mr_science goes bowling...21:47
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-husrscmbonahvvdw> has quit IRC21:48
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC21:52
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC21:52
*** Umeaboy <Umeaboy!> has joined #yocto21:58
*** mulhern <mulhern!> has joined #yocto22:03
*** ant_home <ant_home!> has joined #yocto22:08
*** zerus <zerus!> has quit IRC22:23
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto22:23
*** eren <eren!~eren@unaffiliated/eren> has quit IRC22:25
*** davest <davest!Adium@nat/intel/x-beddoaxteprkdsml> has quit IRC22:27
*** challinan <challinan!> has quit IRC22:29
*** davest <davest!~Adium@> has joined #yocto22:30
*** andyross <andyross!> has quit IRC22:32
*** andyross <andyross!> has joined #yocto22:32
*** mulhern <mulhern!> has quit IRC22:37
*** posborne <posborne!ccb603ec@gateway/web/freenode/ip.> has quit IRC22:50
*** darknighte is now known as darknighte_znc22:52
*** andyross <andyross!> has quit IRC22:55
*** andyross <andyross!> has joined #yocto22:56
*** andyross <andyross!> has quit IRC23:04
*** andyross <andyross!> has joined #yocto23:05
*** munch <munch!> has quit IRC23:07
*** JimBaxter <JimBaxter!> has quit IRC23:13
*** mulhern <mulhern!> has joined #yocto23:14
*** hollisb <hollisb!> has quit IRC23:16
*** bluelightning <bluelightning!> has joined #yocto23:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto23:20
*** phdeswer_ <phdeswer_!> has quit IRC23:31
*** Umeaboy <Umeaboy!> has quit IRC23:35
*** mulhern <mulhern!> has quit IRC23:37
*** fitzsim <fitzsim!~user@nat/cisco/x-ioyofluolunadyzh> has quit IRC23:39
*** andyross <andyross!> has quit IRC23:44
*** andyross <andyross!> has joined #yocto23:44
*** mulhern <mulhern!> has joined #yocto23:57

Generated by 2.11.0 by Marius Gedminas - find it at!