Wednesday, 2014-02-05

*** l_r <l_r!> has joined #yocto00:02
*** gjohnson_ <gjohnson_!> has joined #yocto00:02
l_rI am reading the documentation00:02
l_rI already have one openembedded image.. Does yocto setup the environment to boot qemu qith a sd card controller? if yes, where is the disk file supposed to be on the host?00:04
l_rno sorry00:05
l_rbad question00:05
*** gjohnson__ <gjohnson__!> has quit IRC00:05
*** sjolley1 <sjolley1!sjolley@nat/intel/x-ikplziyllukwkguu> has joined #yocto00:07
*** sjolley <sjolley!~sjolley@> has quit IRC00:07
*** gjohnson__ <gjohnson__!> has joined #yocto00:12
*** nitink <nitink!nitink@nat/intel/x-pxxuycfzouegrcup> has joined #yocto00:13
*** gjohnson_ <gjohnson_!> has quit IRC00:16
*** d_s_e <d_s_e!> has quit IRC00:39
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto00:57
*** valik <valik!c1ca1642@gateway/web/freenode/ip.> has quit IRC01:13
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC01:18
*** joseppc <joseppc!> has quit IRC01:33
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC01:37
*** gjohnson_ <gjohnson_!> has joined #yocto01:44
kergothgah, playing with automatic python dep crap and found 20+ recipes that are either things the script can't handle, or are missing deps/rdeps on the python modules they use, between oe-core and meta-oe. time to see how much of that is true..01:46
*** abelloni <abelloni!> has quit IRC01:47
*** gjohnson__ <gjohnson__!> has quit IRC01:47
kergothmaybe thats best left as a manually run tool, since it seems to require a certain amount of manual review01:50
*** challinan <challinan!> has joined #yocto01:56
*** khem` <khem`!> has joined #yocto01:56
*** abelloni <abelloni!> has joined #yocto01:59
*** onoffon <onoffon!~khem@> has joined #yocto02:01
*** khem` <khem`!> has quit IRC02:01
*** Squix__ <Squix__!> has joined #yocto02:04
*** Squix__ <Squix__!> has left #yocto02:04
*** Squix__ <Squix__!> has joined #yocto02:05
*** jfrkuska__ <jfrkuska__!> has joined #yocto02:05
*** Squix__ <Squix__!> has quit IRC02:06
*** jfrkuska__ <jfrkuska__!> has quit IRC02:07
*** Jefro1 <Jefro1!> has quit IRC02:08
*** Squix_ <Squix_!> has joined #yocto02:09
*** Jefro <Jefro!> has joined #yocto02:10
*** Jefro <Jefro!> has quit IRC02:16
*** gjohnson__ <gjohnson__!> has joined #yocto02:23
*** gjohnson_ <gjohnson_!> has quit IRC02:27
*** onoffon <onoffon!~khem@> has quit IRC02:45
*** onoffon <onoffon!> has joined #yocto02:45
*** onoffon is now known as khem`02:45
*** jmdelos_ <jmdelos_!> has joined #yocto02:56
*** jmpdelos <jmpdelos!> has quit IRC02:57
*** jmpdelos__ <jmpdelos__!> has joined #yocto02:59
*** jmdelos_ <jmdelos_!> has quit IRC03:01
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto03:01
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC03:04
*** sakjur <sakjur!> has quit IRC03:15
*** onoffon <onoffon!~khem@> has joined #yocto03:17
*** khem` <khem`!> has quit IRC03:17
*** khem` <khem`!> has joined #yocto03:25
*** onoffon <onoffon!~khem@> has quit IRC03:26
*** gjohnson_ <gjohnson_!> has joined #yocto03:28
*** gjohnson__ <gjohnson__!> has quit IRC03:32
*** gjohnson__ <gjohnson__!> has joined #yocto03:34
*** gjohnson_ <gjohnson_!> has quit IRC03:38
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has quit IRC03:41
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto03:42
*** gjohnson_ <gjohnson_!> has joined #yocto03:47
*** gjohnson__ <gjohnson__!> has quit IRC03:50
*** behanw <behanw!~behanw@> has quit IRC03:52
*** behanw <behanw!~behanw@> has joined #yocto04:07
-YoctoAutoBuilder- build #15 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at
*** Jefro <Jefro!> has joined #yocto04:38
* mranostay yawns04:58
*** Jefro <Jefro!> has quit IRC05:05
khem`mranostay: intel has bored you05:05
*** db_imx <db_imx!62fa3acb@gateway/web/freenode/ip.> has joined #yocto05:07
*** db_imx <db_imx!62fa3acb@gateway/web/freenode/ip.> has quit IRC05:10
*** sakjur <sakjur!> has joined #yocto05:11
mranostayjust yawns :P05:12
*** Jefro <Jefro!> has joined #yocto05:24
*** e8johan <e8johan!> has joined #yocto05:27
mranostayhi Jefro05:36
*** gjohnson__ <gjohnson__!> has joined #yocto05:38
*** abelloni <abelloni!> has quit IRC05:39
*** abelloni <abelloni!> has joined #yocto05:39
*** gjohnson_ <gjohnson_!> has quit IRC05:42
*** behanw <behanw!~behanw@> has quit IRC05:49
*** Jefro <Jefro!> has quit IRC06:10
*** challinan <challinan!> has quit IRC06:12
*** challinan <challinan!> has joined #yocto06:17
*** SorenHolm <SorenHolm!> has quit IRC06:24
*** challinan <challinan!> has quit IRC06:25
*** challinan <challinan!> has joined #yocto06:43
*** Jefro <Jefro!> has joined #yocto06:52
*** tasslehoff <tasslehoff!~tasslehof@> has joined #yocto06:52
*** Jefro <Jefro!> has quit IRC06:56
*** joseppc <joseppc!> has joined #yocto07:02
*** andna <andna!~andna@> has joined #yocto07:02
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC07:04
*** Jefro <Jefro!> has joined #yocto07:09
*** Jefro <Jefro!> has quit IRC07:14
*** RP1 <RP1!~richard@> has quit IRC07:22
*** diego_r <diego_r!> has joined #yocto07:23
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:24
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:24
*** mckoan|away is now known as mckoan07:27
*** SorenHolm <SorenHolm!> has joined #yocto07:27
*** mckoan <mckoan!> has quit IRC07:27
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto07:27
*** gjohnson_ <gjohnson_!> has joined #yocto07:34
*** RP <RP!~richard@> has joined #yocto07:37
*** gjohnson__ <gjohnson__!> has quit IRC07:38
*** zecke <zecke!> has joined #yocto07:48
*** gmacario <gmacario!> has joined #yocto07:51
*** zeeblex <zeeblex!apalalax@nat/intel/x-gmpblejwsgheotwb> has joined #yocto07:52
*** gjohnson__ <gjohnson__!> has joined #yocto07:53
*** gjohnson_ <gjohnson_!> has quit IRC07:57
*** ant_work <ant_work!> has joined #yocto08:03
*** agust <agust!> has joined #yocto08:06
*** eballetbo <eballetbo!> has joined #yocto08:06
*** g1zer0 <g1zer0!> has joined #yocto08:08
*** OlivierG <OlivierG!~oguiter@> has joined #yocto08:13
*** dany <dany!> has joined #yocto08:23
*** elmi82 <elmi82!> has joined #yocto08:36
*** fpaut_ is now known as fpaut08:36
*** gjohnson_ <gjohnson_!> has joined #yocto08:44
*** gjohnson__ <gjohnson__!> has quit IRC08:48
*** smartin__ is now known as smartin08:50
diego_rkhem`, otavio: The patch you pointed me to seems to fix the Chromium build problem. I've submitted a patch; let me know if you need any modifications.
*** smartin <smartin!~smartin@> has quit IRC08:50
*** smartin <smartin!~smartin@> has joined #yocto09:05
*** sjolley1 <sjolley1!sjolley@nat/intel/x-ikplziyllukwkguu> has quit IRC09:10
*** e8johan <e8johan!> has quit IRC09:15
*** sameo <sameo!samuel@nat/intel/x-ramaxjjyhiisgcup> has joined #yocto09:21
*** florian_kc <florian_kc!> has joined #yocto09:23
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto09:23
*** gjohnson__ <gjohnson__!> has joined #yocto09:24
*** rainerschuster <rainerschuster!> has joined #yocto09:25
*** florian_kc is now known as florian09:26
*** rainerschuster <rainerschuster!> has left #yocto09:27
*** gjohnson_ <gjohnson_!> has quit IRC09:27
*** mihai <mihai!~mihai@> has joined #yocto09:28
*** bluelightning <bluelightning!~paul@> has joined #yocto09:36
*** bluelightning <bluelightning!~paul@> has quit IRC09:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:36
bluelightningmorning all09:36
*** danielki <danielki!~daniel@> has joined #yocto09:38
*** dany <dany!> has quit IRC09:41
*** dany <dany!> has joined #yocto09:47
*** belen <belen!~Adium@> has joined #yocto09:51
*** Net147 <Net147!> has joined #yocto09:52
*** Squix_ <Squix_!> has quit IRC10:11
*** ddalex <ddalex!~ddalex@> has joined #yocto10:13
*** JimBaxter <JimBaxter!> has joined #yocto10:13
*** daiane <daiane!> has quit IRC10:14
*** daiane <daiane!> has joined #yocto10:15
*** JimBaxter <JimBaxter!> has quit IRC10:19
*** silviof1 is now known as silviof10:25
*** rainerschuster1 <rainerschuster1!~Adium@> has joined #yocto10:26
-YoctoAutoBuilder- build #15 of nightly-fsl-arm is complete: Success [build successful] Build details are at
*** rainerschuster1 <rainerschuster1!~Adium@> has quit IRC10:30
*** JimBaxter <JimBaxter!> has joined #yocto10:32
*** rainerschuster <rainerschuster!> has joined #yocto10:33
*** daiane <daiane!> has quit IRC10:35
*** daiane <daiane!> has joined #yocto10:35
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:41
lpappgood morning10:41
*** gmacario <gmacario!> has quit IRC10:46
lpappbluelightning: the openssh recipe has DEPENDS = "zlib openssl", but when I use the following statement in my image, the target image does not get openssl installed for some reason, IMAGE_FEATURES += "ssh-server-openssh". It is because it depends on openssl, but not on the package that actually ships the openssl binary, just the library? Is it detected automatically?10:52
bluelightninglpapp: DEPENDS just specifies a build-time dependency; any runtime dependency will come in from dynamic linking (or an explicit RDEPENDS), so if that doesn't exist then no runtime dependency will exist10:53
lpappah, yes, that is RDEPENDS.10:54
lpappI think debian was doing the other way around10:54
lpappdepend was the runtime, and they had build-depend.10:54
lpappbluelightning: thanks.10:58
*** Squix_ <Squix_!> has joined #yocto11:00
*** rainerschuster <rainerschuster!> has left #yocto11:06
*** ddalex <ddalex!~ddalex@> has quit IRC11:08
Xzguys, having difficulties with compiling on uclibc target with -static flag11:08
lpappXz: what problems?11:08
Xzopkg shows libc-dev (0.9.33+git0+...) installed11:08
Xzhowever there is no libc.a on target11:08
Xzand linker says 'cannot find -lc'11:09
rburtonXz: .a goes into -staticdev11:09
bunkIs there some way to tell bitbake to not use colors?11:09
mckoanbluelightning: I need curl with-libssh2 are there news bout this topic?
Xzrburton: are you telling me I have to install on target 'uclibc-staticdev' ?11:10
rburtonXz: if you want to link against a .a on the target, yes11:10
bluelightningmckoan: well what I wrote still stands... you should be able to add a curl bbappend that enables libssh2 support11:11
Xzrburton: cool, I will try that, thanks11:11
mckoanbluelightning: which would be the appropriate layer?11:11
*** gmacario <gmacario!> has joined #yocto11:12
lpappmckoan: no, your layer.11:12
*** belen1 <belen1!~Adium@> has joined #yocto11:13
bluelightningbunk: I don't think there's an option for that, no... it does get disabled automatically if curses tells us that the terminal can't support > 2 colours11:13
*** belen <belen!~Adium@> has quit IRC11:14
mckoanlpapp: uh, ok I thought it was interesting for meta-networking11:14
lpappmckoan: layers ship generic stuff... customization goes into own layers, I believe.11:15
lpappalthough in this case, bluelightning suggested meta-network, so it might be ok to get some core stuff in oe-core, and more powerful thorough configuration in upper layers....11:16
bluelightningmckoan: the recipe for libssh2 itself might be (although the (older?) libssh is in meta-oe)11:16
lpappIMHO, meta-oe is a monster and it should not grow a lot further unless very necessary.11:16
bluelightningbbappends are not appropriate for layers that should only be adding recipes to build additional software, such as meta-oe and meta-networking11:16
*** sjolley <sjolley!sjolley@nat/intel/x-ossmggxdyavzpyig> has joined #yocto11:17
lpappso if any, I would vote for meta-networking, but I am not a maintainer of any of those.11:17
lpappJaMa: ok, I finally found some time to put Kevin back into the patch.11:20
TuTizzmorning all, what should I do to separate my /home (rw ext4) from my / (ro ubifs) with yocto? Should I overwrite the fstab file? bluelightning, I don't know if you remember but you recommended me to take a look at wic during the past week. Wic is not realy what I am looking for. Wic seem to be use to put an OS on a device but, if I correctly understood it, the OS need to be previously built.11:20
lpappdo _not_ use wic.11:21
lpappjust use u-boot and fstab.11:21
Xzrburton: is there any clever packagegroup that installs libc-staticdev by default?11:21
lpappTuTizz: if you use redboot or other misterious stuff, then I do not know. :)11:22
rburtonXz: not afaik.  static linking is generally a special case (and eglibc-staticdev is practically impossible to use)11:22
Xzrburton: what do you mean? how is it 'practically impossible' to staticly link eglibc?11:22
Xzrburton: it's just about compiling with -static11:23
rburtonnot when eglibc dynamically loads libraries at runtime it isn't11:23
rburtonuclibc is probably better in that respect11:23
TuTizzlpapp, yep I use u-boot11:23
*** sjolley <sjolley!sjolley@nat/intel/x-ossmggxdyavzpyig> has quit IRC11:23
lpappTuTizz: right, so just configure it.11:24
lpappand then you can keep your fstab variant in your own layer with .bbappend11:24
Xzrburton: so basically using '-static' in respect to eglibc gives only half-staticly copiled binary?11:24
lpapp(that is what we do... others might correct me if that is wrong .... but it works)11:24
rburtonXz: yep11:24
Xzrburton: I mean only part of eglibc goes actually into the binary and rest is still dynamically loaded?11:24
Xzrburton: ok11:24
rburtonXz: the NSS stuff is always dynamically loaded11:25
*** sjolley <sjolley!~sjolley@> has joined #yocto11:25
mckoanbluelightning: solved thx11:25
Xzrburton: is it the same with normal glibc?11:25
rburtonXz: see point 4 at
rburtoneglibc is normal glibc11:26
TuTizzlpapp, ok I will try that way, ty11:26
rburtonXz: as i said, uclibc is sufficiently leaner and designed for this that i expect static linking would work, if you really needed to do it.11:28
*** e8johan <e8johan!> has joined #yocto11:30
TuTizzlpapp, with your advise If I build with IMAGE_FSTYPES = "ubifs" my /home will be under ubifs too doesn't it?11:33
bunkbluelightning: Thanks for the hint, "export TERM=xterm-mono" did the trick.11:35
*** pocek_ <pocek_!> has joined #yocto11:35
lpappTuTizz: btw, why do you need ro ubifs?11:35
lpappit is the matter of a second to remount it rw.11:35
bluelightningbunk: np11:35
lpappTuTizz: yes, e.g. we use IMAGE_FSTYPES += "ubi tar.bz2 jffs2"11:35
lpappbecause we also have jffs2 partitions.11:36
lpappTuTizz: to be honest, I do not yet know what wic is good for...11:36
TuTizzI don't need it on rw.11:36
lpappI assume it abstract out the bootloader and it also writes the fstab in the same step11:36
lpappI could not imagine what else it does...11:36
TuTizzautomaticaly create your USB OS?11:37
TuTizzwith correct partition?11:37
lpappyes, which you can already do with u-boot easily and fstab modification. :)11:37
lpappand IMAGE_FSTYPES, etc.11:37
lpappI guess it will do all that in one configuration step, but you will still need to configure the things eventually.11:37
lpappI will consider it once it has a documentation what it tries to achieve. Currently, I do not understand, just assume. :)11:38
*** Squix_ <Squix_!> has quit IRC11:39
TuTizzonce I got my different image_fstype, I manually delete /home from ubifs and copy/paste it from ext3 for exemple?11:39
lpappTuTizz: I am not sure you do not need rw... are you sure?11:40
lpappwhat about package management?11:40
lpappyou will always reflash the image for an update?11:40
lpappor the package maintainer scripts are supposed to do the remount twice?11:40
TuTizzOS is for medical embedded product11:40
*** Squix_ <Squix_!> has joined #yocto11:41
TuTizzI througt that was safer if / was ro11:41
TuTizzyou will always reflash the image for an update? yes11:41
TuTizzwith u-boot11:41
lpappro is not safe IMHO11:42
lpappany scam software can remount it anytime with ease.11:42
lpappand your software should be tested in medial anyhow. :)11:42
TuTizzro boot faster too doesn't it?11:42
lpappTuTizz: ok, if an update means reflash and you can manage that remotely, that is fine.11:43
lpappTuTizz: do you have benchmark?11:43
TuTizznot yet11:43
lpappbut still, reflashing all the time would be inconvenient for me.11:43
lpappe.g. during development, it would slow me down.11:43
lpappTuTizz: have you looked into squashfs ?11:44
TuTizzI have 2 image, one for dev, one for demonstration11:44
TuTizzyes for squashfs11:44
lpappTuTizz: yes, but the developer needs to test the production image (if that is what you mean by demonstration), too.11:45
TuTizzbut I have got an eMMC and constructor recommand ubifs11:45
lpappTuTizz: even for "safe" systems?11:46
lpapp(constructor, you mean vendor?)11:46
TuTizz(manufactor, sry :( )11:47
lpappIMHO, there is no catch-all fs recommendation, but it might be that their hardware only works reliably with ubifs which would be unfortunate.11:48
TuTizzTuTizz: even for "safe" systems? did not saw anything about that :(11:48
lpappok, no worries... it was just a side-question anyway. :)11:49
*** dany <dany!> has quit IRC11:49
lpapp(ro vs. rw)11:49
TuTizzI currently use bootchart for benchmarking11:50
TuTizz(the boot time)11:51
lpappthe daemon from busybox, right?11:51
*** dany <dany!> has joined #yocto11:52
TuTizzonce I got my different image_fstype, should I manually delete /home from ubifs/squashfs partition and copy/paste it to an ext3 partition (want it on an USB device) ? (I say /home but that can be another directory like /home/foo)11:56
*** sjolley <sjolley!~sjolley@> has quit IRC11:56
lpappTuTizz: what do you mean, you can build different rootfs types without changing fstab.11:58
lpappat least for ubifs, "auto" works for me... not sure if it was jffs2 though.11:58
*** sjolley <sjolley!sjolley@nat/intel/x-ipplkzpboyhuprub> has joined #yocto11:58
lpappTuTizz: what fs do you use for /home?11:59
*** rainerschuster <rainerschuster!> has joined #yocto12:02
lpappbluelightning: how can I customize a recipe in my layer with .bbappend so that I tell the meta layer not to apply certain patch(es) in that layer?12:03
lpappbluelightning: I could probably depatch those, but I prefer preventing the needless patching.12:03
bluelightninglpapp: modifying SRC_URI is the only way I can think of12:03
lpappbluelightning: you mean rebuilding the SRC_URI variable from scratch?12:04
lpappor I can remove an element from it?12:04
lpapp(using dylan here)12:04
danielkidora has _remove :)12:04
bluelightningin dylan you can use oe_filter_out, but it's messy12:04
lpappbluelightning: ok, so it is easier to rebuild the variable, I take it?12:04
bluelightninglpapp: which patch are you removing?12:05
danielkiyou could also have another patch which reverts a previous one12:05
lpappbluelightning: meta/recipes-core/base-passwd/base-passwd-3.5.26/nobash.patch contains two different logics (hence my patch on the mailing list)12:05
lpappone of the logics does not apply to our use case (it breaks our image eventually)12:06
bluelightninglpapp: which part of it?12:06
lpappbluelightning: removing * because we do have /etc/shadow.12:06
bluelightninglpapp: if you just set the root password afterwards then surely that doesn't have any effect?12:06
lpappbluelightning: pardon?12:07
*** Squix_ <Squix_!> has quit IRC12:08
Saurbluelightning: I don't know if you know anything about this, but I saw your name in the log of buldhistory.bbclass. Today when I rebuilt my tree, it decided to rebuild everything (the only thing that had changed since yesterday were the to last commits on master of Poky). Then I suddenly got warning messages like "WARNING: Revision for tag default_R0.0.13 in package depd was changed since last build (from 740b088c94c0b5440e27160c6d3290d00e8dc15b to 65e12:08
*** Squix_ <Squix_!> has joined #yocto12:08
Saurbluelightning: When examining the SHA-1s I noticed that the first SHA-1 is the SHA-1 of the tag, and the second SHA-1 is the SHA-1 of the commit the tag refers to...12:09
*** rainerschuster <rainerschuster!> has quit IRC12:09
lpappbluelightning: we currently use ROOTFS_POSTPROCESS_COMMAND12:09
lpappbluelightning: I do not like it, and I think we should eventually use usermod, but that is how my colleague did it.12:09
lpapp(and in the long future ROOT_PASSWD)12:10
bluelightninglpapp: so why is this required? I'll agree the patches shouldn't be combined but I don't see how omitting this helps you12:10
bluelightningSaur: the patches on the top of master did change signatures, hence the rebuilding12:11
lpappbluelightning: do you understand what * is good for in the base-passwd debian mess?12:11
Saurbluelightning: Yes, that part I was expecting.12:11
bluelightningSaur: hmm, so I didn't write that part of buildhistory.bbclass (JaMa did) but it's only supposed to give you a warning when a tag in a repository you're fetching from changes its hash12:12
Saurbluelightning: But the tags did not change. It is reporting a change from the tag SHA-1 to the commit SHA-1... Maybe it has something to do with the changes RP & co did recently to the Git fetcher, and how it handles tags...12:15
bluelightningSaur: could be, I guess12:15
lpappbluelightning: perhaps we could set the password with usermod instead of this /etc/shadow hackery?12:16
lpappas far as I understand they are alternative ways.... but I might be completely off ...12:16
*** Net147 <Net147!> has quit IRC12:19
Saurbluelightning: Aha. I think 8ef24f4c in the Bitbake repo may  be the culprit. It's probably just that nothing has triggered a rebuild of those packages since, which is why I got the warnings today when the rebuilds were triggered...12:20
bunkI assume support for a CentOS version in a Yocto release implies that the same RHEL version is supported?12:21
lpappbunk: check the supported distributions in the image config.12:21
lpappbunk: are you using Poky?12:21
lpappbunk: there is no RHEL in there.12:22
lpappbunk: what is your /etc/issue saying on RHEL?12:22
bunklpapp: perhaps I should have said "expected to work" instead of "supported" in my question12:23
lpappbunk: IMHO, do not expect anything, but I am too realistic, and a bit pessimistic, too.12:24
bluelightningbunk: yes, that would be expected12:26
bunkbluelightning: thanks12:26
bluelightningbunk: but I don't think we explicitly test on RHEL during our QA process, FWIW12:26
andnaI want to write a gadget driver. With Qt I am missing linux header files (The configuration is done as described in the freescale forum). Can someone point me in the right direction what I missed or why they are not in /opt/?12:34
lpappandna: what kind of gadget driver?12:34
lpappandna: how is a gadget driver related to Qt?12:35
*** dany <dany!> has quit IRC12:35
av500a "cute gadget"12:36
lpappbluelightning: right, dylan does not have extra users... :-/12:37
lpappbluelightning: would chpasswd work intead?12:37
andnalpapp: Qt is not related to the driver.12:38
lpappandna: so what is the problem? Have you created an SDK?12:39
lpappandna: does it work with that?12:39
andnalpapp: I also tried hello-mod and this worked fine12:39
lpappit is only not working with the build system?12:39
lpappdefine hello-mod. :-)12:39
*** Squix_ <Squix_!> has quit IRC12:40
*** Squix_ <Squix_!> has joined #yocto12:41
andnalpapp: hello-mod is the example module. I added it to my image and it worked12:41
lpappandna: sure, but what does it contain?12:42
lpappI mean, does it also include the linux headers?12:42
andnaBut when i tried to include  e.g. unistd.h it is missing12:44
*** gjohnson_ <gjohnson_!> has joined #yocto12:44
lpappwell, are you trying to use a .bbappend for your module?12:45
*** ddalex <ddalex!~ddalex@> has joined #yocto12:45
*** Squix_ <Squix_!> has quit IRC12:46
*** Squix_ <Squix_!> has joined #yocto12:47
*** gjohnson__ <gjohnson__!> has quit IRC12:47
lpappandna: forked kernel recipe? Please explain your scenario more.12:50
lpappbluelightning: or we should use usermod for the ROOTFS_POSTPROCESS_COMMAND variable as opposed to extra users?12:51
otaviobluelightning: the Yocto Project QA I think does not but most vendors does.12:53
*** flynn378 <flynn378!80db310e@gateway/web/freenode/ip.> has joined #yocto12:56
*** Squix_ <Squix_!> has quit IRC12:57
*** Squix_ <Squix_!> has joined #yocto12:58
*** rainerschuster <rainerschuster!> has joined #yocto13:07
*** Squix_ <Squix_!> has quit IRC13:08
*** Squix_ <Squix_!> has joined #yocto13:09
lpappoh, LOCALCONF_VERSION and LAYER_CONF_VERSION are different things.13:14
ndecas implied by the names ;-)13:15
lpappyes, I think the confusing thing is the comment about LCONF13:16
lpappis that a mistake in the sample and should be LOCALCONF or that is a third variable?13:16
lpappor should it be LAYER_CONF, etc13:16
TuTizzre, <lpapp> TuTizz: what fs do you use for /home? ext3 or 4.13:17
*** jkridner|work <jkridner|work!> has quit IRC13:18
lpappTuTizz: I am not sure if auto works for ext3 and/or ext4.13:18
lpappTuTizz: perhaps you could test it?13:18
TuTizzlpapp, what is auto? OS autodetect the fs?13:19
lpappTuTizz: yes, e.g. rootfs               /                    auto       rw,suid,dev,exec,auto,nouser,sync  1  113:21
TuTizzok ty13:22
lpappbluelightning: I modified the sanity tested distros to this, SANITY_TESTED_DISTROS ?= " \13:24
*** diego_r <diego_r!> has quit IRC13:24
lpapp            Ubuntu-12.04 \n \13:24
lpapp            Debian-7.1 \n \13:24
lpappbluelightning: but I am still getting this, WARNING: Host distribution "Debian-7.1" 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.13:24
*** sjolley <sjolley!sjolley@nat/intel/x-ipplkzpboyhuprub> has quit IRC13:24
lpappbluelightning: is it because we still require poky, so it does not matter what we set in our distro conf?13:24
lpappah, yes, because "If A is set before the above is called, it will retain it's previous value. If A is unset prior to the above call, A will be set to aval. Note that this assignment is immediate, so if there are multiple ?= assignments to a single variable, the first of those will be used."13:25
danielkihow does this AUTOINC thing work? what do I have to do to get it expanded?13:25
ndeclpapp: yeah, that's a bit confusing. i think they go by pair. LCONF_VERSION and LAYER_CONF_VERSION go together, and it's used to check that your local generated bblayers.conf is compatible with the OE checkout you are using.13:27
ndecsimilarly CONF_VERSION and LOCALCONF_VERSION go together, for the same reason13:27
ndecand both 'pairs' are not related to each ohter.13:28
lpappstrange that we have non-talkative alternative names...13:28
*** Squix_ <Squix_!> has quit IRC13:30
*** Squix_ <Squix_!> has joined #yocto13:31
*** sjolley <sjolley!~sjolley@> has joined #yocto13:31
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto13:31
*** dlerner <dlerner!~dlerner@> has joined #yocto13:31
bluelightningdanielki: it's set during packaging automatically13:33
*** OlivierG <OlivierG!~oguiter@> has left #yocto13:33
danielkiyeah, I see it now, but how does it actually get incremented? it is always 0 for me13:33
lpappare DISTRO_EXTRA_RDEPENDS_append_qemu* necessary for getting a working SDK?13:33
lpapp(or I can remove them safely in my distro config?)13:33
bluelightningdanielki: you need to enable the PR service13:33
danielkibluelightning: hm, I just read about that. it requires a server?13:34
bluelightningdanielki: it's built into the build system, you just have to enable it, see the manual link ^13:34
lpappdanielki: is it possible from the client side to block the resource usage for icecc?13:35
lpappdanielki: i.e. the build farm would like to use my cycles, but I would like to tell it to stop it cause I need it for a local build?13:35
danielkilpapp: I think so, but I'm new to this as well13:35
danielkibluelightning: hm, so the PR service makes sure that everyone connected to it gets consistent version numbers, right?13:37
*** sjolley <sjolley!~sjolley@> has quit IRC13:37
bluelightningdanielki: yes13:37
lpappdoes Yocto have a catch-all-manual search function?13:37
lpapp(I am unlucky with google at times for some reason)13:37
danielkibluelightning: hm ok, I understand the need now, and at the same time I realize this is not an option for us :)13:37
bluelightningdanielki: why not?13:38
danielkibluelightning: because if I only enable it for me I'm subverting the purpose, and it would be overkill to ask our customer to connect to a central server we would have to set up, just for this AUTOINC convenience13:39
danielkiI guess I'll go back to manual versioning13:39
bluelightningdanielki: it's not subverting the purpose, it's intended that you use it for this even if you only have one build machine13:40
bluelightningdanielki: the point is, there's a single place for it to store the versions and they are preserved between builds13:40
danielkibluelightning: but if our customer builds the stuff themselves, they might get different version numbers?13:41
bluelightningdanielki: sure, if you don't use the same PR server there's no way around that13:42
*** ddalex <ddalex!~ddalex@> has quit IRC13:46
*** ddalex <ddalex!~ddalex@> has joined #yocto13:47
lpappah, right, another hiddem gem... EXTRAOPKGCONFIG13:49
*** Squix_ <Squix_!> has quit IRC13:51
*** Squix_ <Squix_!> has joined #yocto13:53
lpappbut Yocto is actually never using that variable in the end, insteresting...13:53
*** rainerschuster1 <rainerschuster1!~Adium@> has joined #yocto13:55
*** ant_work <ant_work!> has quit IRC13:57
*** rainerschuster <rainerschuster!> has quit IRC13:57
*** sjolley <sjolley!~sjolley@> has joined #yocto13:59
*** Squix_ <Squix_!> has quit IRC14:03
*** Squix_ <Squix_!> has joined #yocto14:03
*** sjolley <sjolley!~sjolley@> has quit IRC14:07
*** e8johan <e8johan!> has quit IRC14:11
*** sjolley <sjolley!sjolley@nat/intel/x-nadtcuxhrsfkfrgr> has joined #yocto14:11
*** behanw <behanw!~behanw@> has joined #yocto14:14
*** tasslehoff <tasslehoff!~tasslehof@> has quit IRC14:15
*** sjolley <sjolley!sjolley@nat/intel/x-nadtcuxhrsfkfrgr> has quit IRC14:19
*** rainerschuster1 <rainerschuster1!~Adium@> has quit IRC14:22
*** sjolley <sjolley!~sjolley@> has joined #yocto14:22
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tedzygmipcqfnmkl> has joined #yocto14:23
*** mulhern_ <mulhern_!> has joined #yocto14:28
*** mulhern_ <mulhern_!> has quit IRC14:29
lpapprburton: you wrote this long ago, "i'm just saying don't check into a VCS your downloads or sstate, because the files wouldn't suit that.  just http or nfs will do.14:34
lpappwhat did you mean by http?14:34
lpappThe problem is that if I put the downloads and sstate-cache to a mirror, the developer would still need to download them again which takes a lot of time.14:34
lpapp(including the CI machine)14:34
rburtonif you have many machines that want to use a central sstate/downloads cache, share it over NFS or HTTP.14:34
rburtondownloading even a webkit build over gigabit will take no more than a few seconds14:35
*** rainerschuster <rainerschuster!~Adium@> has joined #yocto14:35
rburtonby putting them into git, you're forcing everyone to do that download: not just the people who need it14:35
lpapprburton: it is only dowloaded per clone which we have done once the last half a year or so.14:36
lpappbut I agree git is not the best option for it.14:37
lpappI would prefer a mirror, but only if it is really the matter of few seconds.14:37
lpappotherwise, yes, mount looks like the fallback.14:37
*** Squix_ <Squix_!> has quit IRC14:40
*** ericbutters <ericbutters!~eric@> has quit IRC14:41
*** LetoThe2nd <LetoThe2nd!> has quit IRC14:45
*** LetoThe2nd <LetoThe2nd!~jd@unaffiliated/letothe2nd> has joined #yocto14:45
mksHello guys, please how do I cleanup kernel source from tmp/sysroot/.../kernel ?14:46
*** Crofton <Crofton!~balister@2a01:e35:2f01:edd0:3e97:eff:fe07:aac9> has joined #yocto14:46
mksok after verification "-c clean virtual/kernel" seems to do it as well14:49
lpapprburton: thanks, I will test the internal mirror because we seem to have gigabit, and only a few devs for now. :)14:50
*** jkridner <jkridner!> has joined #yocto14:50
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:50
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC14:51
*** jkridner <jkridner!> has joined #yocto14:51
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:51
lpappdanielki: how do you arrange your repository layout if I may ask? I used to have a poky-dylan and poky-denzil in the root, but now that we do not use denzil anymore, I have the gut feeling, it would be cleaner to remove the poky-dylan indirection, and put its content into the projectroot, and then our layer beside it?14:57
lpappI am wondering what the general practice is in here for Yocto users.14:57
danielkiI just have a poky directory14:58
*** sjolley <sjolley!~sjolley@> has quit IRC14:58
danielkithe directory structure is modelled after the freescale stuff14:59
danielkiour custom layer is next to the others at the top level14:59
lpappah, so you have something like this:14:59
lpappdocs meta-foo poky?15:00
danielkiwell, we have: base  meta-fsl-arm  meta-<custom name> meta-openembedded  meta-qt5  poky15:01
danielkiand use the repo tool to keep it all together15:01
lpappdanielki: do you actually use meta-yocto from poky? I am planning not to.15:01
danielkiI think we use it, yes15:01
danielkiit's on by default, and I don't care as long as it works15:02
lpappok, which freescale stuff did you mean?15:03
lpappdanielki: also, you create the build folder then beside poky, and not inside?15:03
danielkiI modified it somewhat though15:05
danielkiit's beside the sources/ folder15:05
danielki(sources contains all the repo subdirs)15:05
lpapphmm, I see, thanks.15:06
*** jackmitchell <jackmitchell!> has quit IRC15:07
lpappdanielki: not sure what source/base is.15:08
danielkilpapp: a modified version of this:
*** SorenHolm <SorenHolm!> has quit IRC15:11
lpappdanielki: ah, ok. Btw, do you also get the toolchain rebuilt every time with icecc? I guess it takes a bit of while, even with icecc, but it depends on how many contributors you can collect for icecc.15:11
*** gjohnson__ <gjohnson__!> has joined #yocto15:11
danielkino, it's not rebuilt every time15:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC15:11
lpapp(without icecc currently, it would slow our CI down quite a bit)15:11
*** jackmitchell <jackmitchell!> has joined #yocto15:12
danielkialso, parts of the toolchain are actually in the icecc blacklist15:12
*** bluelightning <bluelightning!~paul@> has joined #yocto15:12
*** bluelightning <bluelightning!~paul@> has quit IRC15:12
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto15:12
*** dguthrie <dguthrie!> has joined #yocto15:14
*** gjohnson_ <gjohnson_!> has quit IRC15:15
dguthrieIs there a way of getting a "-dbg" packaged installed in the target sysroot. I'm trying to compile against source code in another package15:15
*** sjolley <sjolley!~sjolley@> has joined #yocto15:16
*** elmi82 <elmi82!> has quit IRC15:17
*** gjohnson_ <gjohnson_!> has joined #yocto15:17
*** gjohnson_ <gjohnson_!> has quit IRC15:18
*** gjohnson_ <gjohnson_!> has joined #yocto15:18
*** sjolley <sjolley!~sjolley@> has quit IRC15:19
rburtondguthrie: if you need something in the sysroot, install it in there.15:19
rburtoni presume you wanted the dbg package as it has the source extracted in it, but packages don't exist for the sysroot15:19
*** sjolley <sjolley!~sjolley@> has joined #yocto15:20
dguthrierburton: Yes thats correct. I want to be able to do 'DEPEND = "packageA-dbg"' and get bitbake to install packageA-dbg into the target sysroot directory15:20
*** gjohnson__ <gjohnson__!> has quit IRC15:21
rburtonstrictly speaking, that's what you think your solution looks like15:21
rburtonbut as packages don't exist for the sysroot, that can't happen15:21
rburtonso you have a package B that needs source from package A to compile15:21
*** fpaut <fpaut!> has left #yocto15:22
rburtonthe tcl recipe shows how to install extra files into the sysroot15:22
dguthrierburton: thats correct. packageB depends on packageA-dbg to compile. But in the sysroots onto packageA and packageA-dev are installed15:22
rburtondguthrie: stop thinking about A-dbg, packages don't exist for the sysroot15:23
rburtonthe sysroot is populated from a subset of what the recipe installs, before packages are created15:23
*** fpaut <fpaut!> has joined #yocto15:23
dguthrierburton: I can't see in the meta/recipes-devtools/tcltk/ how to install extra pacakges into the sysroot15:25
dguthrierburton: Is there a way similar to how the kernel's source is installed in usr/src/kernel15:26
rburtondguthrie: the SYSROOT_PREPROCESS_FUNCS adding a new function that uses sysroot_stage_dir15:26
rburtondguthrie: the kernel overrides the staging code entirely, using the tcl method just adds a bit to the existing code15:27
dguthrierburton: thanks15:28
*** marius_ <marius_!~marius@> has joined #yocto15:28
rburtonstaging.bbclass is what you want - do_populate_sysroot calls sysroot_stage_all() and then every function in SYSROOT_PREPROCESS_FUNCS.15:29
rburtondguthrie: do i want to know why B depends on the sources of A?  why can't it just fetch A in its fetch task?15:30
lpapprburton: are the DISTRO_EXTRA_RDEPENDS_append_qemu* statements used for the SDK? I would like to get rid of them if it is not necessary for them since we do not use qemu explicitly. We have our own simulator, the target image, and the SDK.15:30
*** marius_ <marius_!~marius@> has quit IRC15:33
*** marius_ <marius_!~marius@> has joined #yocto15:34
*** rainerschuster1 <rainerschuster1!> has joined #yocto15:43
*** sjolley <sjolley!~sjolley@> has quit IRC15:44
*** rainerschuster <rainerschuster!~Adium@> has quit IRC15:45
LetoThe2ndtinkering with a custom image i see those errors upon creation. am i miossing some IMAGE_FEATURE here?
*** sjolley <sjolley!~sjolley@> has joined #yocto15:46
bluelightningLetoThe2nd: I suspect nothing actually causes initscripts-functions to be built15:51
bluelightningLetoThe2nd: in which case it's probably a bug :/15:51
bluelightningobviously you could just "bitbake initscripts" to fix it15:51
bluelightningto work around it, that is15:51
*** sjolley <sjolley!~sjolley@> has quit IRC15:52
LetoThe2ndbluelightning: uhhuh.15:52
LetoThe2ndbluelightning: FYI, the image recipe looks like
*** belen1 <belen1!~Adium@> has quit IRC15:53
*** sjolley <sjolley!sjolley@nat/intel/x-rnsncxwubnidpqfx> has joined #yocto15:53
LetoThe2ndlooks like the problem has been triggered by IMAGE_INSTALL += " bash", which kicked out busybox and therefore some things didn't get built16:07
LetoThe2ndso whats the correct way to get bash as shell into my image?16:07
kergoththat shouldn't "kick out" anything, it adds a recipe, that's all16:09
LetoThe2ndi agree for the "shouldn't"16:09
LetoThe2ndwhen building above pastebinned recipe from scratch, no busybox got pulled in though16:10
LetoThe2ndremoving it, busybox gets built and everything is fine again.16:12
*** Jefro <Jefro!> has joined #yocto16:18
*** marius_ <marius_!~marius@> has quit IRC16:19
*** zeeblex <zeeblex!apalalax@nat/intel/x-gmpblejwsgheotwb> has quit IRC16:25
mckoanabout this scenario where the <conf_file> should be found?16:27
*** belen <belen!~Adium@> has joined #yocto16:30
*** belen <belen!~Adium@> has quit IRC16:37
*** gjohnson__ <gjohnson__!> has joined #yocto16:38
*** Crofton <Crofton!~balister@2a01:e35:2f01:edd0:3e97:eff:fe07:aac9> has quit IRC16:39
*** gjohnson_ <gjohnson_!> has quit IRC16:42
*** Jefro <Jefro!> has quit IRC16:44
*** Jefro <Jefro!> has joined #yocto16:45
*** g1zer0 <g1zer0!> has quit IRC16:46
*** belen <belen!~Adium@> has joined #yocto16:47
khem`mckoan: the opkg.conf16:49
mckoankhem`: thx16:50
*** andna <andna!~andna@> has quit IRC16:51
*** eballetbo <eballetbo!> has quit IRC16:52
lpappopkg whatprovides requires a package name? So what is it useful for then? It prints out which package installs that package... I thought it would be useful to see for a file which package provides it?16:55
kergothSo, I've been messing with this automatic rdeps for python code stuff, and I'm starting to think maybe it should be opt-in as a part of creating a recipe, rather than always as a part of the packaging process, as it seems like the dependency detection is something that will often require manual review.16:59
khem`lpapp: use opkg search /path/to/file17:00
*** zecke <zecke!> has quit IRC17:01
lpappkhem`: ah, yes, now I recall that, thanks!17:01
* lpapp still needs to get used to the opkg options17:01
bluelightningkergoth: wouldn't it just be a QA warning type of thing, i.e. you haven't added this list of dependencies?17:04
*** mckoan is now known as mckoan|away17:04
kergothyeah, but it picks up things like win32con and the like, since it isn't smart enough to pick up the import being inside a particular conditoinal that isn't true for us. same for try/except importerror blocks which support this or that or the other thing. have to explijcitly exclude those bits whenever it happens17:07
lpapphmm, LINUX_VERSION is not written back to the .config ... is that intentional? I think it should.17:11
lpappnvm, I was wrong.17:11
lpappLINUX_VERSION_EXTENSION is used for that.17:12
*** belen <belen!~Adium@> has quit IRC17:16
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC17:17
LetoThe2ndhow can i find out what sets x11 in DISTRO_FEATURES?17:17
bluelightningLetoThe2nd: use bitbake -e | less and search for DISTRO_FEATURES, you can see the complete history of how the variable gets set17:18
*** sjolley <sjolley!sjolley@nat/intel/x-rnsncxwubnidpqfx> has quit IRC17:18
*** sjolley <sjolley!~sjolley@> has joined #yocto17:18
*** belen <belen!Adium@nat/intel/x-agzybiwwzeqkfyag> has joined #yocto17:18
*** gjohnson_ <gjohnson_!> has joined #yocto17:19
LetoThe2ndbluelightning: i see what gets set, but not where.17:20
LetoThe2ndor asking differently, can i unset it in my DISTRO?17:20
bluelightningLetoThe2nd: you're not using grep are you?17:20
LetoThe2ndbluelightning: i am. would it help if i pastebinit? ;)17:21
bluelightningLetoThe2nd: sure17:21
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC17:21
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto17:22
bluelightningLetoThe2nd: that's why I said use bitbake -e | less - then you see the full output, not just the lines that have DISTRO_FEATURES in them17:22
lpappwhat is the best of versioning images? Currently, I do not see an IMAGE_VERSION option or so.17:22
LetoThe2ndbluelightning: aaaah moment then.17:22
bluelightninglpapp: just use the normal recipe versioning..?17:22
*** gjohnson__ <gjohnson__!> has quit IRC17:23
lpappbluelightning: you mean PR?17:24
bluelightninglpapp: no I mean PV, as in what you (optionally) specify in the recipe filename17:24
*** mihai <mihai!~mihai@> has quit IRC17:25
*** sjolley <sjolley!~sjolley@> has quit IRC17:25
*** khem` <khem`!> has quit IRC17:25
*** dguthrie <dguthrie!> has quit IRC17:27
lpappbluelightning: ah, ok, you mean and I can still create the image by bitbake foo-image, right?17:27
bluelightninglpapp: yep17:28
lpappok, thanks.17:28
LetoThe2ndbluelightning: thanks, it seems to have come from DISTRO_FEATURES_DEFAULT pulled in through poky.conf - setting an other DISTRO_FEATURES_DEFAULT before requiring poky.conf seems to work. so is this a godd(TM) or bad(TM) way to solve this?17:29
*** sjolley <sjolley!~sjolley@> has joined #yocto17:30
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:31
*** sjolley <sjolley!~sjolley@> has quit IRC17:31
*** Crofton <Crofton!> has joined #yocto17:32
bluelightningLetoThe2nd: probably the easiest way on dora or later is to use DISTRO_FEATURES_remove = "x11"17:33
*** fpaut is now known as fpaut_17:33
bluelightningLetoThe2nd: of course, you can set DISTRO_FEATURES outright to just include the features you want if you prefer17:33
bluelightningyou just have to do it in the right place; which would normally be your own custom distro config17:33
LetoThe2ndbluelightning: i remember from edinburgh that _remove kind-of was work in progress. so is it considered stabel and worthwhile using for dora and later?17:34
*** sjolley <sjolley!~sjolley@> has joined #yocto17:34
rburton_remove is made of awesome17:34
bluelightningLetoThe2nd: hmm, I think it was stable at that time too, although it was new17:34
bluelightningas of dora it's in a stable release and is documented in the bitbake manual17:35
LetoThe2ndbluelightning: i'm willing to take that as "go ahead and use it" :)17:35
bluelightningLetoThe2nd: please do :)17:35
*** belen <belen!Adium@nat/intel/x-agzybiwwzeqkfyag> has quit IRC17:36
LetoThe2ndbluelightning: i've got the great freedom that our buildsystem/base for $NEXTPRODUCT still is to be defined, so there's nobody keeping me from saying "only dora and later"17:36
LetoThe2nd... which i already will probably do, as we get gcc 4.8.2 + recent valgrind/lttng then.17:37
*** belen <belen!Adium@nat/intel/x-cljslsmwmjzheukq> has joined #yocto17:37
bluelightningLetoThe2nd: freedom is nice :)17:37
rburtonLetoThe2nd: you really want to say dora or later :)17:37
* danielki agrees17:37
LetoThe2ndtesting build in progress :)17:37
LetoThe2ndrburton: hehe17:38
lpappLetoThe2nd: enjoy the freedom... will be worse. :)17:38
LetoThe2ndlpapp: depends on your job17:42
lpappyeah, maybe academic people without customer will remain free.17:43
LetoThe2ndbluelightning: in case you'd like the face connected to the nick - we also met for a moment at fosdem. pretty early saturday morning, right after booth was set up.17:43
LetoThe2ndlpapp: it all depends.17:44
*** sjolley <sjolley!~sjolley@> has quit IRC17:44
bluelightningLetoThe2nd: ah, cool :)17:46
*** danielki <danielki!~daniel@> has quit IRC17:47
*** diego_r <diego_r!> has joined #yocto17:48
*** sjolley <sjolley!sjolley@nat/intel/x-ujxqbwgucpfgpdpj> has joined #yocto17:50
*** erbo <erbo!> has quit IRC17:51
*** belen1 <belen1!Adium@nat/intel/x-lizwyhlorcpuozwm> has joined #yocto17:53
*** sjolley <sjolley!sjolley@nat/intel/x-ujxqbwgucpfgpdpj> has quit IRC17:53
*** sjolley <sjolley!~sjolley@> has joined #yocto17:54
*** belen <belen!Adium@nat/intel/x-cljslsmwmjzheukq> has quit IRC17:54
*** Crofton <Crofton!> has quit IRC17:56
*** rainerschuster1 <rainerschuster1!> has left #yocto17:57
*** sjolley <sjolley!~sjolley@> has quit IRC17:58
*** sjolley1 <sjolley1!sjolley@nat/intel/x-ptgdburcsqbmcodp> has joined #yocto17:58
*** akbennett is now known as zz_akbennett18:00
*** smartin <smartin!~smartin@> has quit IRC18:03
*** zz_akbennett is now known as akbennett18:04
*** akbennett <akbennett!akbennett@linaro/akbennett> has joined #yocto18:05
*** belen1 <belen1!Adium@nat/intel/x-lizwyhlorcpuozwm> has quit IRC18:07
*** belen <belen!~Adium@> has joined #yocto18:11
*** Crofton <Crofton!~balister@2a01:e35:2f01:edd0:3e97:eff:fe07:aac9> has joined #yocto18:11
*** Crofton <Crofton!~balister@2a01:e35:2f01:edd0:3e97:eff:fe07:aac9> has quit IRC18:12
*** smartin <smartin!~smartin@> has joined #yocto18:12
*** khem` <khem`!~khem@> has joined #yocto18:13
*** sameo <sameo!samuel@nat/intel/x-ramaxjjyhiisgcup> has quit IRC18:15
*** zecke <zecke!> has joined #yocto18:23
*** dguthrie <dguthrie!> has joined #yocto18:24
lpappbluelightning: is the local mirror anything special like a debian repository or it is just barely a storage without metadata file, and Yocto only needs to know the url, and that is about it?18:26
dguthrieI have a package which only provides header files but the "smart" utilty is giving me an error saying bothing provides the pacakge18:26
bluelightninglpapp: nothing special, just a directory containing files18:26
lpappbluelightning: ok, great, so I do not need to learn anything new like for setting up a debian repository, thanks.18:27
bluelightningdguthrie: are you sure the package actually contains files? if it ended up empty it won't exist and you'll get an error from smart18:27
dguthriebluelighting: only the -dev package contains files. If there a way of getting smart to ignore?18:29
bluelightningbluelightning: ah you mean you have a dev package and no main package but the dev package still depends on the main package18:30
*** belen <belen!~Adium@> has quit IRC18:30
bluelightninger, dguthrie ^18:30
lpappbluelightning: is it a long time to rebuild the whole sstate-cache after the download? I am wondering if I should put that into the mirror, too.18:30
*** gjohnson__ <gjohnson__!> has joined #yocto18:30
bluelightninglpapp: sstate-cache isn't rebuilt separately, if it's there and the hashes match, it'll be re-used, if not, the tasks will be executed as normal18:31
bluelightninglpapp: if you want to share it, sure you can, just use SSTATE_MIRRORS18:31
bluelightningdguthrie: if so, just set RDEPENDS_${PN}-dev = "" in the recipe18:32
dguthriebluelighting: thanks18:32
lpappbluelightning: yes, I meant if it is worth  caching.18:32
*** diego_r <diego_r!> has quit IRC18:32
bluelightninglpapp: if you're not sure what is in there I suggest you read
*** gjohnson_ <gjohnson_!> has quit IRC18:34
lpappbluelightning: ok, thanks.18:35
*** dguthrie <dguthrie!> has quit IRC18:37
*** smartin_ <smartin_!> has joined #yocto18:39
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has quit IRC18:46
*** mranosta1 <mranosta1!> has joined #yocto18:51
*** gjohnson_ <gjohnson_!> has joined #yocto18:52
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC18:52
*** mranosta1 is now known as mranostay18:53
khem`zeddii: around ?18:53
*** mranostay <mranostay!> has quit IRC18:53
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto18:53
*** nitink <nitink!nitink@nat/intel/x-pxxuycfzouegrcup> has quit IRC18:54
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto18:54
khem`I have a question w.r.t kernel and externalsrc18:55
* mranostay yawns18:55
*** gjohnson <gjohnson!> has joined #yocto18:55
mranostaykhem`: don't ask to ask18:55
khem`mranostay: it this the same one extending overnight18:55
* mranostay ducks :)18:55
*** gjohnson__ <gjohnson__!> has quit IRC18:55
khem`mranostay: I asked him to pop up his head if he is around first18:56
mranostayyeah long yawn18:56
*** gjohnson_ <gjohnson_!> has quit IRC18:58
*** sroy__ <sroy__!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto18:58
*** Crofton <Crofton!> has joined #yocto18:59
lpappbluelightning: if I understand correctly, I should use PREMIRRORS as opposed to MIRRORS to utilize my local gigabit ethernet before trying to obtain the archive from upstream?19:00
*** onoffon <onoffon!> has joined #yocto19:00
bluelightninglpapp: yes19:00
*** khem` <khem`!~khem@> has quit IRC19:01
lpappbluelightning: so what is the difference between PREMIRRORS and SOURCE_MIRROR_URL (own mirror) then?19:03
bluelightningthe latter makes use of the former19:03
lpappbluelightning: plus ?19:03
bluelightningSOURCE_MIRROR_URL just specifies a single URL (and is only enabled by own-mirrors.bbclass), whereas PREMIRRORS specifies maps from a regexes to a mirror URLs19:04
lpappbluelightning: so the latter is just minor convenience?19:05
bluelightningif you mean SOURCE_MIRROR_URL19:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:05
lpappyes, so I should probably use that then if it is available in dylan19:06
lpapp(which it is)19:06
*** sroy__ <sroy__!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has quit IRC19:07
zeddiikhem, pong19:10
*** sroy__ <sroy__!~sroy@2607:fad8:4:6:6e88:14ff:feff:5374> has joined #yocto19:13
*** nitink <nitink!~nitink@> has joined #yocto19:14
*** wrotte <wrotte!~textual@> has joined #yocto19:15
kergothout of curiosity, where in the yocto release cycle does the release get its codename?19:19
kergothdon't think19:19
kergotherm, don't think i've seen that info in the wiki19:19
*** sjolley1 <sjolley1!sjolley@nat/intel/x-ptgdburcsqbmcodp> has quit IRC19:27
*** dany <dany!~Thunderbi@> has joined #yocto19:40
LetoThe2ndshouldn't IMAGE_FEATURES += " tools-profile" pull in valgrind?19:41
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC19:41
*** sjolley <sjolley!sjolley@nat/intel/x-qzjeuwjqderrouwo> has joined #yocto19:42
mr_sciencedon't know, but valgrind isn't exactly a "profiling" tool...19:42
*** onoffon <onoffon!> has quit IRC19:43
LetoThe2ndmr_science: agreed, its what local.conf's comments say, though: #  "tools-profile"  - add profiling tools (oprofile, exmap, lttng, valgrind)19:43
mr_sciencetry it and see, i guess19:43
LetoThe2ndtried, and its not there. so i basically suspect the comment to be wrong.19:44
rburtonkergoth: normally when beth starts moaning that we need a name to tag things19:44
mr_scienceack!  stale comments19:44
rburtonkergoth: i know RP has a shortlist of 2 choices19:44
LetoThe2ndhow to find out what a specific IMAGE_FEATURE pulls in?19:45
LetoThe2ndi admit i hoped for a more automated way ;)19:46
rburtonLetoThe2nd: meta/classes/core-image.bbclass maps image features to packagegroups19:46
rburtongenerally, the mapping is "add packagegroup-core-"19:46
LetoThe2ndrburton: then it seems the comment is plain wrong.19:47
rburtonpatches welcome! :)19:47
mr_sciencecomments in local.conf are fairly important, especially to new users19:47
LetoThe2ndtools-profile maps to packagegroup-core-tools-profile...19:48
LetoThe2ndah wait, moment.19:48
kergothHmm, can someone tell me where I can find the yocto 1.6 compliance requirements text?19:49
*** gjohnson_ <gjohnson_!> has joined #yocto19:49
rburtonkergoth: the "compatible" rules?19:49
kergothwant to make sure mentor is on track for this release19:49
rburtonwere there changes for 1.6?19:50
kergoththat's a good question, and is what i was wondering :)19:50
rburtonmaybe jefro knows19:51
kergothmethinks i have some work to do for "Are hardware support, configuration (distro) policy, and recipe metadata separated into different layers which do not depend on each other?" :)19:51
kergothlayers got a bit messy19:51
rburtonthat's the one that we only just noticed with meta-yocto too :)19:52
rburtononly just in time, that is19:52
LetoThe2ndrburton: uhm, its meta/recipes-core/packagegroups/ then. that has RDEPENDS_$PN = "${VALGRIND}", which in turn is set to "".19:52
*** gjohnson <gjohnson!> has quit IRC19:52
LetoThe2ndvalgrind should do fine for arm, though (at least since a few revisions.)19:52
LetoThe2ndso maybe this is the real bug? valgrind being deactivated for arm, because during the early days of this packagegroup ARM was not supported?19:53
rburtonLetoThe2nd: if you can confirm that our valgrind works on arm, feel free to send a patch fixing that.19:53
LetoThe2ndrburton: noted, will try to verify and send tomorrow. bugtracker, list, you CC?19:54
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto19:58
*** SorenHolm <SorenHolm!> has joined #yocto20:01
*** trollixx_ <trollixx_!> has quit IRC20:07
*** trollixx <trollixx!> has joined #yocto20:07
*** gjohnson__ <gjohnson__!> has joined #yocto20:10
*** gjohnson_ <gjohnson_!> has quit IRC20:14
*** gjohnson_ <gjohnson_!> has joined #yocto20:15
bunk seems is what disabled ("fixed"...) valgrind on ARM20:15
*** gjohnson__ <gjohnson__!> has quit IRC20:17
bunkI don't know whether that's the reason here, but valgrind doesn't support ARM < ARMv720:19
*** wrotte <wrotte!~textual@> has quit IRC20:19
*** wrotte <wrotte!~textual@> has joined #yocto20:20
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC20:22
*** gjohnson__ <gjohnson__!> has joined #yocto20:23
bunkso valgrind is expected to work fine on a panda, but to crash on a Raspberry20:25
bunkLetoThe2nd: ^^^20:25
bunkrburton: ^^^20:25
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto20:25
*** OutBackDingo_ <OutBackDingo_!~quassel@unaffiliated/outbackdingo> has joined #yocto20:25
*** wrotte <wrotte!~textual@> has quit IRC20:26
*** OutBackDingo_ <OutBackDingo_!~quassel@unaffiliated/outbackdingo> has quit IRC20:26
*** zecke <zecke!> has quit IRC20:27
*** gjohnson_ <gjohnson_!> has quit IRC20:27
*** SorenHolm <SorenHolm!> has quit IRC20:28
*** SorenHolm <SorenHolm!> has joined #yocto20:30
bunklooking at the (upstream) valgrind sources it should actually give a compile error when building for < ARMv7 like Raspberry20:32
*** gjohnson_ <gjohnson_!> has joined #yocto20:44
*** gjohnson__ <gjohnson__!> has quit IRC20:48
*** sjolley <sjolley!sjolley@nat/intel/x-qzjeuwjqderrouwo> has quit IRC20:58
*** sjolley <sjolley!sjolley@nat/intel/x-dlvtpemkfkrrdjus> has joined #yocto20:59
*** JimBaxter <JimBaxter!> has quit IRC20:59
*** RP <RP!~richard@> has joined #yocto21:04
*** nitink1 <nitink1!~nitink@> has joined #yocto21:04
*** nitink <nitink!~nitink@> has quit IRC21:06
*** onoffon <onoffon!~khem@> has joined #yocto21:06
*** onoffon is now known as khem`21:06
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto21:06
khem`zeddii: I am on 1.4 and trying to use externalsrc with kernel21:06
khem`I dont see it working without changing kernel.bbclass to use O=$B21:07
khem`and cd'ing into $S before any of build tasks21:07
khem`how does this work ?21:07
mranostaykhem`: magic!21:07
*** dany <dany!~Thunderbi@> has quit IRC21:07
khem`mranostay: my crystal ball is broken today21:07
mranostaykhem`: magic 8 ball as backup?21:09
*** SorenHolm <SorenHolm!> has quit IRC21:10
zeddiikhem. it worked here when I tested in January, I'll dig up my recipe. I didn't have to hack anything (outside of my recipe).21:10
khem`hmm ok21:10
khem`this is not linux-yocto btw. its upstream kernel just inheriting kernel bbclass21:11
zeddiiyep, that's fine. I tested with a generic kernel build at the time.21:11
zeddiikhem: is your recipe pastebin'd somewhere I can see it ?21:12
khem`zeddii: I dont see us using O=${B} anywhere in kernel build tasks21:16
khem`so how do we do it21:16
khem`when we build S != B21:16
zeddiiall my kernel builds are S != B21:18
khem`hmm then where do you specify O=${B}21:22
khem`without that kernel wont build in B21:22
*** bluelightning <bluelightning!> has joined #yocto21:28
*** bluelightning <bluelightning!> has quit IRC21:28
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:28
zeddiikhem: right, it isn't done automatically .. but it could be. I just never wanted to break anyone elses's workflow.21:31
zeddiiKBUILD_OUTPUT = "${B}"21:31
zeddiiin your recipe brings it back into a properly behaving beast :)21:31
khem`for that I will have to inherit kernel-yocto21:32
khem`and probably there is more to it21:33
khem`since I am not seeing where O=${B} is set21:33
zeddiiyou just put it into your recipe for now. I can prep a patch to make O= be used for kernel.bbclass in general.21:33
zeddiikhem: as long as  KBUILD_OUTPUT is in the env, the kernel build system takes it as 0=21:33
khem`oh i see21:34
zeddiiyah, it bounces back and forth about which will win in the end (if they differ).21:34
khem`let me try it21:35
khem`zeddii: no doesnt help21:39
khem`is set to ${B}21:39
khem`zeddii: the problem is that every task has to run in $S21:39
khem`and currently default dir is $B21:39
khem`for any build task21:40
khem`so if I dont do cd ${S} this wont work again21:40
zeddiioh maybe I misunderstood the breakage.21:40
zeddiiI've externalsrc built linux-yocto and linux-mainline, I'll need to just try it again.21:41
* zeddii has to pick up some kids. will build kernel's later.21:44
khem`zeddii: I am trickling in changes to kenrel.bbclass21:44
khem`as I plough through errors21:45
*** sameo <sameo!samuel@nat/intel/x-yqznlavwswgiycvy> has joined #yocto21:50
*** gmacario <gmacario!> has quit IRC21:54
*** seebs <seebs!> has quit IRC22:02
*** gjohnson__ <gjohnson__!> has joined #yocto22:04
*** seebs <seebs!> has joined #yocto22:04
*** khem` <khem`!~khem@> has quit IRC22:06
*** gjohnson_ <gjohnson_!> has quit IRC22:06
*** gjohnson_ <gjohnson_!> has joined #yocto22:09
*** sroy__ <sroy__!~sroy@2607:fad8:4:6:6e88:14ff:feff:5374> has quit IRC22:12
*** gjohnson__ <gjohnson__!> has quit IRC22:13
-YoctoAutoBuilder- build #15 of minnow is complete: Failure [failed BuildImages Publishing Artifacts] Build details are at
*** Crofton <Crofton!> has quit IRC22:21
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC22:28
-YoctoAutoBuilder- build #16 of nightly-fsl-ppc-lsb is complete: Failure [failed BuildImages Publishing Artifacts] Build details are at
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC22:34
*** nitink <nitink!nitink@nat/intel/x-jvofdgnlpvdjikre> has joined #yocto22:36
*** nitink2 <nitink2!nitink@nat/intel/x-xdwrzghfwhmznmlq> has joined #yocto22:38
*** nitink <nitink!nitink@nat/intel/x-jvofdgnlpvdjikre> has quit IRC22:38
*** nitink1 <nitink1!~nitink@> has quit IRC22:39
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto22:40
*** nitink2 <nitink2!nitink@nat/intel/x-xdwrzghfwhmznmlq> has quit IRC22:45
*** khem` <khem`!~khem@> has joined #yocto22:49
-YoctoAutoBuilder- build #15 of nightly-fsl-ppc is complete: Failure [failed BuildImages Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
*** onoffon <onoffon!~khem@> has joined #yocto22:54
*** khem` <khem`!~khem@> has quit IRC22:54
*** onoffon is now known as khem`22:56
khem`zeddii: I think there is some patch needed22:57
-YoctoAutoBuilder- build #16 of nightly-x32 is complete: Failure [failed BuildImages Running Sanity Tests Running Sanity Tests_1] Build details are at
*** bfederau <bfederau!> has quit IRC23:01
*** gjohnson__ <gjohnson__!> has joined #yocto23:01
*** bfederau <bfederau!> has joined #yocto23:01
*** gjohnson_ <gjohnson_!> has quit IRC23:04
*** khem` <khem`!~khem@> has quit IRC23:10
*** rainerschuster <rainerschuster!> has joined #yocto23:11
*** gjohnson_ <gjohnson_!> has joined #yocto23:14
*** nitink <nitink!nitink@nat/intel/x-lozybxxibcxptowd> has joined #yocto23:16
*** gjohnson__ <gjohnson__!> has quit IRC23:18
*** smartin_ <smartin_!> has quit IRC23:19
*** reallife <reallife!> has quit IRC23:35
*** reallife <reallife!> has joined #yocto23:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:44
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:54
*** gjohnson__ <gjohnson__!> has joined #yocto23:56
*** Squix_ <Squix_!> has joined #yocto23:57
*** gjohnson_ <gjohnson_!> has quit IRC23:59

Generated by 2.11.0 by Marius Gedminas - find it at!