Wednesday, 2014-06-04

-YoctoAutoBuilder- build #124 of build-appliance is complete: Success [build successful] Build details are at
*** Squix <Squix!> has joined #yocto00:12
*** sjolley <sjolley!~sjolley@> has joined #yocto00:13
*** maxtothemax <maxtothemax!maxtothema@nat/intel/x-pycogozedrzspwwv> has quit IRC00:14
*** Jefro <Jefro!> has quit IRC00:24
*** adelcast <adelcast!~adelcast@> has quit IRC00:45
*** Daemon405 <Daemon405!> has joined #yocto00:50
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC00:50
*** Daemon405 is now known as Daemon40400:51
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto00:51
*** rburton <rburton!> has quit IRC00:56
*** rburton <rburton!> has joined #yocto01:00
*** armpit <armpit!> has quit IRC01:15
*** neabax <neabax!~neabax@> has quit IRC01:28
*** rburton <rburton!> has quit IRC01:34
*** rburton <rburton!> has joined #yocto01:35
*** rburton <rburton!> has quit IRC01:44
*** rburton <rburton!> has joined #yocto01:45
*** sameo <sameo!~samuel@> has quit IRC02:03
*** wgao <wgao!~wgao@> has joined #yocto02:07
*** rburton <rburton!> has quit IRC02:18
*** rburton <rburton!~rburton@> has joined #yocto02:19
*** jmdelos_ <jmdelos_!> has joined #yocto02:29
*** jmpdelos <jmpdelos!> has quit IRC02:29
*** simmel80___ <simmel80___!> has joined #yocto02:30
*** simmel80 <simmel80!> has quit IRC02:33
*** rburton <rburton!~rburton@> has quit IRC02:53
*** rburton <rburton!> has joined #yocto02:54
*** Cyrin <Cyrin!~LCyrin@2607:fb90:40e:c74c:4121:aae3:538b:4089> has joined #yocto03:13
*** LCyrin <LCyrin!~LCyrin@2607:fb90:407:ad68:4c86:276a:31a2:d531> has quit IRC03:16
*** armpit <armpit!> has joined #yocto03:19
*** Jefro <Jefro!> has joined #yocto03:24
*** Jefro <Jefro!> has quit IRC03:55
*** mranostay <mranostay!> has joined #yocto04:12
*** Jefro <Jefro!> has joined #yocto04:23
*** e8johan <e8johan!> has joined #yocto04:23
*** mranostay <mranostay!> has quit IRC04:25
*** melonipoika <melonipoika!> has quit IRC04:42
*** mranostay <mranostay!> has joined #yocto04:51
*** Jefro <Jefro!> has quit IRC04:56
*** mranostay <mranostay!> has quit IRC05:09
*** melonipoika <melonipoika!> has joined #yocto05:10
*** mranostay <mranostay!> has joined #yocto05:10
*** zecke <zecke!> has joined #yocto05:21
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto05:45
*** agust <agust!> has joined #yocto05:52
*** Jefro <Jefro!> has joined #yocto05:53
*** LetoTheII is now known as Letothe2nd06:41
*** freanux <freanux!~freanux@unaffiliated/freanux> has quit IRC06:48
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto06:50
rink_hi there; question06:50
rink_I'm inheriting core-image06:50
rink_and for some reason, it includes dbus which drags in virtual/libx1106:50
rink_which causes problems because I need i.MX6 vivante with FB06:50
rink_any idea how I can figure out why it does this? the dependency graph shows that dbus wants "virtual/libx11"06:51
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:56
*** jbrianceau_away is now known as jbrianceau06:56
*** diego_r <diego_r!> has joined #yocto07:04
ndecrink_: it's probably because x11 is enabled in your DISTRO_FEATURES07:04
ndecif you look at dbus recipe, you will see "PACKAGECONFIG[x11] = "--with-x --enable-x11-autolaunch,--without-x --disable-x11-autolaunch, virtual/libx11 libsm"07:05
*** zecke <zecke!> has quit IRC07:05
*** dvhart <dvhart!dvhart@nat/intel/x-zjstmegmkvwkkabs> has joined #yocto07:06
*** g1zer0 <g1zer0!> has joined #yocto07:07
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has quit IRC07:08
*** eballetbo <eballetbo!> has joined #yocto07:09
*** Jefro <Jefro!> has quit IRC07:12
rink_ndec, how can I verify that this is indeed the case ?07:20
ndecyou can check the value of DISTRO_FEATURES in your config files. if you use oe distroless or poky, then x11 is enabled by default07:21
rink_it seems this even happens with 'core-image-minimal'07:21
ndecDISTRO_FEATURES is orthogonal to image recipe07:21
ndecthe .conf files for distro, machine, local, .. that contains definition used across all recipes.07:22
ndecimage recipe are just standard recipe that pulls together binary packages07:22
ndecif dbus was built with x11 enabled , any image that uses dbus will get its x11 depends07:22
Letothe2ndmaybe bitbake -e core-image-minimal | grep DISTRO_FEATURES07:22
ndecyes, ^DISTRO_FEATURES even better07:23
Letothe2ndah right07:23
ndeci need to step out for ~30mins..07:23
*** florian_kc <florian_kc!> has joined #yocto07:25
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:25
*** florian_kc is now known as florian07:26
rink_hmm it's with DISTRO_FEATURES_DEFAULT07:28
rink_how can I get rid of it ?07:28
Letothe2ndi personally usually take poky-lsb.conf or poky-bleeding.conf, and derive my own distro config for it07:30
rink_i can inherit poky-lsb instead of core-image ?07:44
Letothe2ndnot at all, you are mixing up a distro config and an image recipe now.07:48
Letothe2ndyou create your own distro config, derived from poky-whatever. and then you point your locoal.conf's DISTRO to it.07:49
*** jwhitmore <jwhitmore!> has quit IRC07:52
rink_okay, just spent time reading through the development manual and I don't undeerstand what you mean07:58
rink_DISTRO ?== 'poky' in my local.conf fwiw07:59
rink_ however, I've added a custom layer with the kernel patch I need, which seems to work great07:59
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:59
rink_the idea was to create an image into that custom layer, which I intend to build07:59
Letothe2ndyeah thats all fine.08:02
Letothe2ndnow have a look at and its location08:02
Letothe2ndit shows you how you can easily derive your own distro configuration from poky. create something similar for your needs, and place it at the corresponding path in your layer08:03
Letothe2ndthen set it in local.conf to be used.08:03
Letothe2ndso you are able to reproductibly set distro features etc. for your stuff.08:03
rink_ah, so my layer should also hold a custom distribution08:04
Letothe2ndthats kind of the simplest way08:04
*** jwhitmore <jwhitmore!> has joined #yocto08:05
rink_sorry, this is all new to me :)08:05
Letothe2ndno problem, i've been thorugh all of this only a few weeks/months ago.08:06
rink_how do i make sure things like x11 aren' t dragged in?08:08
Letothe2ndwell remove them, and then check with bitbake -e08:09
*** kalyank <kalyank!~kalyan@> has joined #yocto08:11
*** sameo <sameo!~samuel@> has joined #yocto08:11
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC08:11
*** Squix <Squix!> has quit IRC08:11
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:12
rink_hmm seems is the culprit08:13
rink_which is included by ...08:13
rink_guess i'd better guess i'd better override that one08:16
Letothe2ndno... you can use DISTRO_FEATURES_remove, for example08:16
rink_I see DISTRO_FEATURES_DEFAULT ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x 11"08:17
rink_so, after including the poky.conf and other stuff, I'll have that as default08:17
rink_will placing DISTRO_FEATURES_remove = "x11"  after the include work ?08:17
Letothe2ndshould, IIRC08:18
rink_of course, I can always replace the DISTRO_FEATURES_DEFAULT thing, but ... dunno08:19
ndecrink_: _remove will work, it doesn't really matter if you do it before or after. _remove are processed at the end of parsing08:21
ndecif you just need to remove x11, _remove is the simplest method. if you build your own distro , and really need something custom then building DISTRO_FEATURES 'manually' is an option08:21
tasslehoffotavio: is the "    mv conf/local.conf conf/local.conf.sample08:23
tasslehoffooops. sorry08:23
tasslehoffotavio: is the "Ensure all files in sources/base are kept in sync with project root" code in setup-environment in fsl-community-bsp-base right?08:27
tasslehoffto me it seems that the cwd is not correct when that code is run08:27
*** ant_work <ant_work!> has joined #yocto08:34
rink_hmm so if I understand correctly, the reason the DISTRO_FEATURES_remove = "x11" didn't work in my own core-image recipe is that it is parsed too late08:42
rink_and bb already decided that dbus etc need x11?08:42
Letothe2ndrink_: it needs to be set in the distro or local config files. in the recipes, it would only have a local effect (and tehrefore not remove the packages.)08:45
*** bluelightning <bluelightning!~paul@> has joined #yocto08:45
*** bluelightning <bluelightning!~paul@> has quit IRC08:45
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:45
*** melonipoika <melonipoika!> has quit IRC08:48
*** volker- <volker-!~volker@unaffiliated/volker-> has quit IRC08:48
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC08:48
*** lyang0 <lyang0!~lyang001@> has quit IRC08:48
*** sgw_ <sgw_!> has quit IRC08:48
*** volker- <volker-!~volker@unaffiliated/volker-> has joined #yocto08:48
*** melonipoika <melonipoika!> has joined #yocto08:48
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto08:49
*** sgw_ <sgw_!> has joined #yocto08:49
*** lyang0 <lyang0!~lyang001@> has joined #yocto08:50
rink_btw, the instructions i followed when patching the kernel claimed you had to increment PRINC; but that gives warnings now. is that no longer needed? the linked page doesn't really help08:50
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto08:50
bluelightningmorning all08:53
bluelightningrink_: you no longer need PRINC, those instructions need updating08:54
bluelightningrink_: which instructions are those?08:54
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has joined #yocto08:55
rink_hmmm; i can't remember actually - this was done a long time ago (and got pulled off the project in between :S)08:57
bluelightningok; if you do come across it let us know08:58
rink_fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/cortexa9hf-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld: shell.o: relocation R_ARM_MOVW_ABS_NC against `forced_interactive' can not be used when making a shared object; recompile with -fPIC08:58
rink_*wonders what is that*09:01
rink_seems it only affects bash *scratches head*09:02
*** _dv_ <_dv_!> has quit IRC09:02
*** rburton <rburton!> has quit IRC09:03
*** rburton <rburton!> has joined #yocto09:08
bluelightningdoesn't mean anything to me I'm afraid...09:09
rink_hmm guess nuking the work/cortex.../bash directory to force it to rebuild messed things up09:11
rink_and cleansstate doesn't help either - how can I get bitbake to understand bash is to be rebuilt completely ?09:11
*** kevin_t <kevin_t!~Thunderbi@> has quit IRC09:11
*** JimBaxter <JimBaxter!> has quit IRC09:11
*** kevin_t <kevin_t!~Thunderbi@> has joined #yocto09:13
*** dv_ <dv_!> has joined #yocto09:13
*** akS <akS!d44db44a@gateway/web/freenode/ip.> has joined #yocto09:13
*** dv_ <dv_!> has quit IRC09:13
*** dv_ <dv_!> has joined #yocto09:13
rink_ok, guess -c cleansstate bash helped09:14
rink_seems cleansstate isn't recursive :)09:14
rink_bluelightning, btw, found the tutorial I think i followed:
rink_[btw: this is odd - force rebuilding of bash seems to fix the issue - wonder what that was all about]09:16
*** maxin <maxin!> has joined #yocto09:16
*** eliza411 <eliza411!> has quit IRC09:17
*** eliza411 <eliza411!> has joined #yocto09:17
*** _dv_ <_dv_!> has joined #yocto09:18
*** dv_ <dv_!> has quit IRC09:19
*** rburton <rburton!> has quit IRC09:23
*** falk0n <falk0n!> has joined #yocto09:24
*** rburton <rburton!> has joined #yocto09:29
*** JimBaxter <JimBaxter!> has joined #yocto09:33
*** _dv_ <_dv_!> has quit IRC09:33
*** rburton <rburton!> has quit IRC09:38
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has quit IRC09:38
*** rburton <rburton!> has joined #yocto09:39
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has joined #yocto09:44
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC09:48
*** dv_ <dv_!> has joined #yocto09:50
*** rburton <rburton!> has quit IRC09:57
*** rburton <rburton!> has joined #yocto09:58
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC10:07
*** cristianiorga <cristianiorga!~cristiani@> has quit IRC10:24
*** mulhern <mulhern!~mulhern@> has joined #yocto10:25
*** zecke <zecke!> has joined #yocto10:32
*** rburton <rburton!> has quit IRC10:33
*** rburton <rburton!> has joined #yocto10:33
*** rburton <rburton!> has quit IRC10:42
*** rburton <rburton!> has joined #yocto10:43
*** e8johan_ <e8johan_!> has joined #yocto10:47
*** e8johan <e8johan!> has quit IRC10:48
*** eliza411 <eliza411!> has quit IRC10:49
*** eliza411 <eliza411!> has joined #yocto10:49
*** halstead <halstead!> has quit IRC10:50
*** halstead <halstead!> has joined #yocto10:51
*** jaustin <jaustin!> has joined #yocto10:51
*** Squix <Squix!> has joined #yocto11:12
*** jluisn <jluisn!~quassel@> has joined #yocto11:14
*** Squix <Squix!> has quit IRC11:21
*** smartin <smartin!~smartin@> has quit IRC11:38
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-tebmcpumbjmjuotl> has joined #yocto11:48
*** smartin <smartin!~smartin@> has joined #yocto11:50
*** rburton <rburton!> has quit IRC11:54
*** rburton <rburton!> has joined #yocto11:55
*** e8johan <e8johan!> has joined #yocto12:01
*** e8johan_ <e8johan_!> has quit IRC12:02
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC12:04
*** melonipoika <melonipoika!> has quit IRC12:06
*** kroon <kroon!~kroon@> has joined #yocto12:09
*** blitz00 <blitz00!~stefans@> has joined #yocto12:20
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto12:20
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto12:21
*** jkridner <jkridner!~jkridner@> has joined #yocto12:28
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:28
*** rburton <rburton!> has quit IRC12:29
*** rburton <rburton!> has joined #yocto12:30
*** adelcast <adelcast!~adelcast@> has joined #yocto12:30
*** mawillia <mawillia!> has joined #yocto12:36
mawilliaHi.  I just updated/pulled to the latest dora branch 0a6f0dbf9476dcb4a17a210af90e2dd1a43b61aa and I notice meta-yocto/conf/distro/poky.conf still shows DISTRO_VERSION="1.5.1", and thats what shows in the Build Configuration dump on the build.  Is that expected?12:41
*** rburton <rburton!> has quit IRC12:42
mawillia(thought it was 1.5.2 now...)12:42
*** rburton <rburton!> has joined #yocto12:42
bluelightningmawillia: I think someone missed bumping the version12:44
bluelightningthere is a bug open for it:
yoctiBug 6395: normal, Undecided, ---, richard.purdie, NEW , poky version of 1.5.2 does lists 1.5.112:45
Letothe2ndBÜMP all the versions :)12:45
*** kroon <kroon!~kroon@> has quit IRC13:01
*** lcire <lcire!~eric@2a01:e35:8b8a:e010:25c8:5970:fab8:37e1> has joined #yocto13:09
*** rburton <rburton!> has quit IRC13:17
*** rburton <rburton!> has joined #yocto13:18
*** sroy <sroy!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto13:26
*** lcire <lcire!~eric@2a01:e35:8b8a:e010:25c8:5970:fab8:37e1> has left #yocto13:26
*** rcw <rcw!~rwoolley@> has joined #yocto13:29
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC13:33
*** adelcast <adelcast!~adelcast@> has quit IRC13:35
*** rburton <rburton!> has quit IRC13:51
*** rburton <rburton!> has joined #yocto13:52
*** halstead <halstead!> has quit IRC14:00
*** halstead <halstead!> has joined #yocto14:00
*** dmoseley <dmoseley!> has joined #yocto14:01
*** tyler-baker <tyler-baker!~tyler@linaro/tyler-baker> has joined #yocto14:04
*** codinho <codinho!> has joined #yocto14:06
*** codinho <codinho!~me@unaffiliated/codinho> has joined #yocto14:06
Letothe2ndi'm in the progress of making a custom u-boot recipe, and i've got a problem with the license thing: git checks out everything, but the directory seems to be empty afterwards. so the license file cannot be found :(14:07
*** kroon <kroon!~kroon@> has joined #yocto14:09
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC14:11
Letothe2ndwhat might be the reason for the fetched src directory to be empty?14:11
*** melonipoika <melonipoika!> has joined #yocto14:11
kroonCan I reuse sstate artefacts built on a Fedora system when I rebuild the same image on an Ubuntu system ?14:12
kroonOr does the build and development servers need to run the same OS ?14:12
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:15
bluelightningkroon: by default we don't share the native portions between different host OSes14:15
bluelightningbut the only issue there is when you build on a newer glibc system and then transfer native components from there over to a system with an older glibc14:15
bluelightningso if you can ensure your "source" has an old-ish version of glibc on it then you shouldn't have any problems14:16
bluelightningyou just need to set up symlinks in your sstate mirror for the host OSes you will be using on the other machines14:16
kroonbluelightning, aha .. so if we have the same OS on our development machines, we could build everything once, upload it to the server (which could have a diff. OS), and then it could share every artefact, including native ones, to all developers ?14:19
bluelightningkroon: yes14:19
kroonbluelightning, makes sense !14:19
Letothe2ndmaybe also an idea why the source dir of a git hosted packe is empty after fetch, except for the .git directory?14:23
*** rburton <rburton!> has quit IRC14:25
*** rburton <rburton!> has joined #yocto14:30
Letothe2ndor at least, how to debug the fetch-unpack process to see where it goes wrong?14:36
*** rburton <rburton!> has quit IRC14:39
*** rburton <rburton!> has joined #yocto14:40
akSLetothe2nd: you can try with: bitbake u-boot -DDD -c unpack14:46
*** kroon <kroon!~kroon@> has quit IRC14:48
*** rburton <rburton!> has quit IRC14:49
Letothe2ndakS: looks like git -c core.fsyncobjectfiles=0 clone -s -n /data/yocto/downloads/git2/fslinux.git.RSI.CortexA5.CortexA5-UBoot.git/ /home/sepp/Projekte/msr21_tan/build/tmp/work/rsi_sama5d3-poky-linux-gnueabi/u-boot-rsi/v2014.04-rsi-r0/git/ is the called signature14:49
*** rburton <rburton!~rburton@> has joined #yocto14:50
Letothe2ndwhich means that in /home/sepp/Projekte/msr21_tan/build/tmp/work/rsi_sama5d3-poky-linux-gnueabi/u-boot-rsi/v2014.04-rsi-r0/git the unpacked sources shall be. but theres nothing besides .git14:50
Letothe2ndok, interesting point in the gi2/xxx download dir, there is no FETCH_HEAD file14:58
Letothe2ndwhereas in another directory coming from the same server (and working) there is one.14:58
*** rburton <rburton!~rburton@> has quit IRC14:58
*** g1zer0 <g1zer0!> has quit IRC14:59
*** rburton <rburton!> has joined #yocto15:00
*** codinho <codinho!~me@unaffiliated/codinho> has quit IRC15:00
Letothe2ndFETCH_HEAD seems to be in all the download directories that are working.15:01
Letothe2ndhow comes that might miss?15:01
*** akS <akS!d44db44a@gateway/web/freenode/ip.> has quit IRC15:05
*** adelcast <adelcast!~adelcast@> has joined #yocto15:09
*** codinho <codinho!~me@> has joined #yocto15:14
*** codinho <codinho!~me@unaffiliated/codinho> has joined #yocto15:14
paulbarkerLetothe2nd: Is there anything useful in the relevant log.do_fetch file?15:17
paulbarkeralternatively you could try executing the same git command that bitbake is executing in an empty tmp directory and seeing what happens15:18
Letothe2ndpaulbarker: exactly the same thing happens.15:19
Letothe2ndalready tried that :(15:19
paulbarkermaybe run bitbake -DDD for a package that works and see if the git options are the same15:20
Letothe2ndpaulbarker: hm, not a bad idea.15:20
Letothe2ndpaulbarker: i've just kicked off another little longish process, but will try that next then.15:20
paulbarkeras an off-the-wall suggestion, try specifying a branch in SRC_URI, even if that is 'branch=master'15:21
*** jkridner|work <jkridner|work!~jkridner@> has joined #yocto15:23
Letothe2ndpaulbarker: i'm specifying a sha of a commit already. might try with master, yes.15:23
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC15:24
volker-I get the impression 1.6 got bloated15:29
volker-for some yet unknown reason my 1.5.1 non-x11 build, builds now in 1.6  gnome-desktop-testing15:30
*** nitink <nitink!~nitink@> has quit IRC15:39
bluelightningvolker-: we enabled ptest by default to enable running upstream-supplied tests at runtime15:42
bluelightningthe ptest packages are however not installed by default15:42
bluelightningif you would prefer not to build them at all, simply remove ptest from DISTRO_FEATURES15:42
volker-bluelightning: did -ptest get renamed to -testing?15:43
bluelightningvolker-: no15:43
volker-I was reading through the update notes but haven't read anything about it15:43
bluelightningvolker-: gnome-desktop-testing is the name of the package upstream, it's just a dependency that is needed to run some of the ptests15:44
volker-for ptests I have here a separate build15:44
bluelightningwe might have missed adding this to the migration notes15:44
volker-going through the migration notes a question raised about the atom-pc note. "The atom-pc hardware reference BSP has been replaced by a genericx86 BSP."15:46
volker-yet, the Atom here is 64bit, are not all atoms 64bit?15:47
*** pidge <pidge!> has joined #yocto15:47
bluelightningvolker-: there are actually two machines now: genericx86 is 32-bit, genericx86-64 is 64-bit15:47
volker-bluelightning: that was already the case in 1.5.115:47
volker-bluelightning: the question is more: are there Atoms that are not 64bit15:48
bluelightningabsolutely there are yes15:48
jvthe early ones were not15:48
volker-reading the release note it gives me the impression that I want to use generix86 for atoms (and not -64)15:48
bluelightningvolker-: that's not the intended meaning, FWIW15:49
bluelightningbut then, atom-pc was more of a reference for netbooks rather than any atom-based machine15:50
volker-I think I just add my notes here as feedback to the wiki15:51
volker-bluelightning: so ptests are automatically build (if not disabled), is there a way to automatically create two images: one with and one without ptests in the same run?16:03
volker-right now we have to builds for this in our 1.5.1 version.16:04
*** nitink <nitink!nitink@nat/intel/x-ttgmghatwubhvplt> has joined #yocto16:04
bluelightningvolker-: yes, you'd just have two image recipes and the second would "require" the first but also do IMAGE_FEATURES += "ptest-pkgs"16:04
bluelightningthat would add all -ptest packages corresponding to other packages in the image16:05
bluelightningalternatively you could selectively add the desired -ptest packages to IMAGE_INSTALL if you didn't want all of them16:05
*** jkridner|work is now known as jkridner16:05
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:06
*** Jefro <Jefro!> has joined #yocto16:11
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC16:12
volker-bluelightning: but I still have to execute 2x bitbake for that?16:12
*** eballetbo <eballetbo!> has quit IRC16:14
bluelightningvolker-: no, you could do bitbake image1 image2 ...16:17
*** ant_work <ant_work!> has quit IRC16:19
volker-btw, thanks for the info :)16:20
bluelightningno problem16:20
*** munch <munch!> has joined #yocto16:22
*** peachj <peachj!c0926518@gateway/web/freenode/ip.> has joined #yocto16:23
peachjMy company noticed a few days ago that base.bbclass ignores license checks for -native and most -cross packages. I posit this behavior could be incorrect as native code could inject incompatible code into the target device.16:24
peachjI also view this as fairly unlikely, but possible.16:24
peachjTo that end, I've worked with one of my colleagues to gin up a patch to let you specify LICENSE_WARNINGS in a .conf file and see warnings for any package potentially in violation of your incompatible licenses.16:25
peachjIs there any opposition to that concept?16:25
peachj(Obviously, I recognize the patch will need to be reviewed on its own merits as well.)16:26
bluelightningpeachj: what would you be specifying in LICENSE_WARNINGS ?16:27
peachjJust a True value. (I've been doing LICENSE_WARNINGS = "1" in local.conf.)16:28
peachjThat enables that warning behavior. Otherwise, the behavior is essentially unchanged.16:28
bluelightningwe might want a different name for the variable, but the general concept seems good16:30
peachjAny suggestion on the name, or you just want to wait for me to send the patch in for that?16:31
bluelightninghmm... something that more closely represents what it's warning about I guess16:32
bluelightningnaming is always a pain16:32
peachjI like naming :-)16:32
bluelightningthat's definitely better16:32
*** Jefro <Jefro!> has quit IRC16:32
volker-bluelightning: so I have a regular image; is it a bad style to create and do a "require" (and not .inc)?16:33
*** ddalex <ddalex!~ddalex@> has quit IRC16:34
bluelightningvolker-: yep that's fine, we even do that with the core-image-minimal derivatives in the core already16:34
volker-I miss the "yocto is written in this style" ;-)16:35
volker-what I never understand: why is the deploy folder stored under tmp16:36
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto16:37
Crofton|workmaybe we should have called tmp something else :)16:37
volker-the work folder with all the build folders is more tmp to me as the deploy folder16:38
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC16:38
volker-or the cache16:38
bluelightningI think the tmp naming is the confusing part16:38
bluelightningTMPDIR isn't necessarily temporary16:39
bluelightningit's just the output directory16:39
volker-it's more the consistency of using it that confuses me. buildhistory and downloads are in the folder below tmp16:40
*** ddalex <ddalex!~ddalex@> has joined #yocto16:40
bluelightningin both cases you don't want those to go away if you get rid of everything else in TMPDIR16:41
volker-but do you want the images to go away?16:42
bluelightningwell, generally I do, yes16:42
bluelightningit depends on why you are deleting TMPDIR I guess16:42
bluelightningif you prefer a different layout, you can set DEPLOY_DIR to point elsewhere16:43
volker-yes, you can move them all :)16:43
volker-Was just curious why it is this way, I never really understood it16:44
*** seebs <seebs!> has quit IRC16:48
peachjbluelightning: re: my patch. I understand I should be submitting to openembedded-core; should I still be using the create-pull-request script to submit the patch? (Haven't submitted any patches before.)16:50
*** ddalex <ddalex!~ddalex@> has quit IRC16:50
*** seebs <seebs!> has joined #yocto16:51
bluelightningpeachj: it's up to you - depends on whether you have somewhere to push the patches in order to make the pull request16:51
bluelightningfor a multi-patch series, a pull request is preferred16:51
bluelightningfor single patches it's OK to just send them with git-send-email16:52
pidgepeachj: I wouldn't mind seeing something like ADDITIONAL_LICENSE_WARNINGS = "cross native"16:53
pidgepeachj: should probably go in license.conf as well16:53
*** nitink <nitink!nitink@nat/intel/x-ttgmghatwubhvplt> has quit IRC16:54
peachjpidge: In my mind, the switch is basically, "Do I want to see all possible warnings or not?" (Essentially, this is a change for hyper paranoid folks in my company, but I imagine all companies of sufficient size have someone hyper paranoid about licenses.)16:55
peachjThe change is in base.bbclass (and only there) because the code that fatals you out for a bad license is in there. We're just adding another branch to that code if NATIVE_LICENSE_WARNINGS is set.16:56
pidgepeachj: Understandable. I think NATIVE though implies that it's only -native or -nativesdk you're warning for, right?17:00
peachjIt could, but I just couldn't think of a better word ;-) Essentially, all the packages (ending in -native or -cross or then ten other suffixes being skipped) are all actually native programs.17:01
peachjThe change I'm proposing will completely eliminate that if-statement.17:01
peachjAt least around whether the check is performed, I should say.17:01
peachjThe if-statement would then simply control whether we warn or do nothing.17:01
*** jbrianceau is now known as jbrianceau_away17:02
Letothe2ndpidge: just a short one: is there already some means in the autobuilder to also publish the generated rootfs artifacts, or do we need to come up with something ourselves?17:05
*** DarylDee <DarylDee!~quassel@> has joined #yocto17:05
pidgeLetothe2nd: PublishArtifacts should do something like what you want to do. That said, I've been talking with LCryin about refactoring it, because it's kind of not what I want it to be. Like the ext3 files, etc?17:08
*** ddalex <ddalex!~ddalex@> has joined #yocto17:09
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC17:14
*** dvhart <dvhart!dvhart@nat/intel/x-zjstmegmkvwkkabs> has quit IRC17:17
volker-seems like the qemu kernel version is different to the x86-64 kernel version17:17
*** codinho <codinho!~me@unaffiliated/codinho> has quit IRC17:17
Letothe2ndpidge: yeah basically yes. for me personally the ext3 and ubi files are relevant, but ofc that also extends to zImage, uBott, etrc.17:22
*** nitink <nitink!~nitink@> has joined #yocto17:24
pidgeLetothe2nd: yeah. we've be discussing how we do PublishArtifacts a bit. Right now, it's kind of a pain, in that it's both machine/layerversion dependent. I had discussed a while back (may have been privately) doing it via a config file similar to how we do the buildset confs.17:24
pidgeLetothe2nd: that said, pulling together your own Publisher isn't hard, as long as you know what files you want.17:25
volker-is there a reason why the openssh build throws QA Issues in the 1.6 "stable" branded version due of 'has relocations in .text'?17:25
bluelightningvolker-: known issue:
yoctiBug 6104: normal, Medium+, 1.6.1, cristian.iorga, ACCEPTED , Possible false positive QA warnings while building17:26
Letothe2ndpidge: thats what i guessed.17:26
*** Krampus <Krampus!> has quit IRC17:26
Letothe2ndpidge: yeah when i looked at the py i really wondered why it includes all those bizarre references to machine type etc.17:27
*** nitink1 <nitink1!~nitink@> has joined #yocto17:27
Letothe2ndpidge: will probably hack sth up myself then... thanks!17:27
*** diego_r <diego_r!> has quit IRC17:28
*** nitink <nitink!~nitink@> has quit IRC17:29
pidgeLetothe2nd: for now, that's probably best until I or someone else gets a chance to sit down and hack this out. We're trying to maintain at least 2 years worth of backwards compatibility on the AB, so that's why you see all the layerversion code (image location changes/machine name changes, etc)17:30
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:30
*** cbzx <cbzx!> has joined #yocto17:32
Letothe2ndpidge: ok, gotcha17:32
* Letothe2nd calls it a day now and flees17:33
*** peachj <peachj!c0926518@gateway/web/freenode/ip.> has quit IRC17:33
*** ddassg <ddassg!~ddalnx@> has joined #yocto17:34
*** ddassg1 <ddassg1!~ddalnx@> has joined #yocto17:37
*** ddassg <ddassg!~ddalnx@> has quit IRC17:37
ddassg1Hi all!17:37
*** maxtothemax <maxtothemax!maxtothema@nat/intel/x-kvnlaumfjyiygwcn> has joined #yocto17:38
ddassg1guys is there somebody that would help me with a weird bitbaking syntax error?17:38
ddassg1can't find anything on the net...17:38
*** Krampus <Krampus!> has joined #yocto17:38
ddassg1basically i get a SYNTAX error processing the second line of ANY .bb file, and the content of the line #2 is just: "DESCRIPTION ="17:42
*** sameo <sameo!~samuel@> has quit IRC17:42
ddassg1the strange thing is that with oe-core the build succeed! i've installed python and the version is 2.7.3 and the bitbake folders of ~/oe-core and ~/poky are identical17:43
*** rburton <rburton!> has quit IRC17:43
*** rburton <rburton!> has joined #yocto17:48
*** ddalnx <ddalnx!~quassel@> has joined #yocto18:05
*** zecke <zecke!> has quit IRC18:07
*** ddassg1 <ddassg1!~ddalnx@> has left #yocto18:08
*** geckos <geckos!~geckos@> has joined #yocto18:11
*** neabax <neabax!~neabax@> has joined #yocto18:12
geckosI create a new machine and included a file on machine's .conf file, the included file has the line`PREFERRED_PROVIDER_u-boot = "u-boot-variscite"'. When I run `bitbake core-image-minimal' I got this note `NOTE: multiple providers are available for u-boot (u-boot, u-boot-imx, u-boot-fslc)18:16
geckosNOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot' and the build fails beacause is trying to build wrong u-boot... If I run `bitbake -e core-image-minimal | grep PREFERRED_PROVIDER_u-boot' I got this output: ... I'm new to yocto and have no idea what is going wrong18:16
geckosAnybody can help me? Cheers :-)18:17
*** dvhart <dvhart!~dvhart@> has joined #yocto18:17
*** dvhart <dvhart!~dvhart@> has quit IRC18:18
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto18:18
*** Jefro <Jefro!> has joined #yocto18:24
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC18:28
*** falk0n <falk0n!> has quit IRC18:33
ddalnxhi guys, if somebody can help with a bitbake error, plese ring my bell. sry for question repetition, just switched irc client. thanks a million!18:34
*** Jefro <Jefro!> has quit IRC18:44
*** belen <belen!> has joined #yocto18:45
*** blloyd <blloyd!~blloyd@> has joined #yocto18:47
*** blloyd <blloyd!~blloyd@> has quit IRC18:48
*** zecke <zecke!> has joined #yocto18:51
*** fenrig <fenrig!5ee22386@gateway/web/freenode/ip.> has joined #yocto18:52
fenrigHi I have some questions regarding autoloading of kernel modules18:52
fenrigI'm using the angstrom version of yocto (v2014.06)18:52
fenrigand I'm building for the beaglebone (black)18:53
fenrigThe kernel of the beaglebone doesn't inherit the linux-yocto recipe18:53
fenrignow there should be an option "module_autoload_<modulename>"18:54
fenrigso I added this linux-mainline_3.8.bbappend18:54
fenrigin my own meta source18:54
fenrigand added the ' module_autolaod_dma-ps-eye = "dma_ps_eye" ' to this file18:55
fenrigand rebuilded the whole thing (with rootfs)18:55
fenrignow when I browse the rootfs.tar.xz then I can't findy any entry in /etc/modprobe.d18:55
zeckefenrig: well, is the module even installed?18:56
fenriginstalled and operational :D18:57
fenrigI do have to insmod it18:57
fenrigbut it works18:57
fenrigand no entry in /etc/modules-load.d18:58
fenrigI followed the hello-mod module example18:59
fenrigIt was pretty easy to add my own module :)19:00
*** belen <belen!> has quit IRC19:00
zeckefenrig: are you sure about module_autolaod_dma-ps-eye?19:01
zeckewhen the module is named with '_' the package most likely is having '_' as well?19:02
zeckein my kernel recipe I see: 'module_autoload_davinci_mmc = "davinci_mmc"'19:02
fenrigbut you're source is probably19:02
fenrigdavinci_mmc ?19:02
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto19:04
zeckefenrig: yes but your module is dma_ps_eye19:04
fenriglet me clarify19:04
zeckeand you do module_autoload_dma_ps_eye19:04
zeckeanyway, need to do other things19:04
fenrigthe recipe in yocto is called ""19:05
fenrigbut the module is compiled (and this is because of the source file naming) to "dma_ps_eye.ko"19:05
fenrigbut i'll change it for consistency19:05
zeckeokay, but that looks confusing. :)19:05
zeckeso you have a kernel recipe and a module recipe19:05
*** Jefro <Jefro!> has joined #yocto19:06
zeckeand you put the autoload for the module into the kernel recipe?19:06
fenrigeuhm no in the .bbappend of the kernel19:06
fenrigshould I place it in the kernel module recipe?19:06
zeckeI can't tell you what you should do19:07
*** Jefro <Jefro!> has joined #yocto19:07
*** freanux <freanux!~freanux@unaffiliated/freanux> has quit IRC19:07
fenrigcan you tell me what I could do?19:07
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC19:07
fenrigI'm doing this of educational reasons :p19:07
fenrigI have a presentation about android, and I made my own kernel modules for the system19:08
fenrigbut now I'd like to use my modules on a standard linux19:08
zeckefenrig: welll, git grep "module_autoload_" in meta/classes19:08
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto19:08
zeckefenrig: so the variable you want to set is looked at when creating a package for your module. As the mainline kernel will not build a package for your module, the line is not looked at19:08
zeckefenrig: so yes, putting the line into the recipe you create the module package is a good start19:09
fenrig:D yeah an answer19:09
fenriggreat man I'll try it19:09
zeckefenrig: inheriting the modules bbclass is probably another obstacle and third naming the variable correctly another thing19:10
zeckebut luckily the roundtrip time for a single module is probably better than for the entire kernel19:10
fenrigzecke: I have a package for my module already19:12
fenrigand I inherit module.bbclass, this inherits kernel-module-split.bbclass19:14
fenrigand when I grepped for the module_autoload19:14
fenrigIt returned the kernel-module-split.bbclass19:14
fenrigI followed this example for my out-of-tree module19:17
*** zecke <zecke!> has quit IRC19:28
*** zecke <zecke!> has joined #yocto19:30
*** rburton <rburton!> has quit IRC19:38
*** rburton <rburton!> has joined #yocto19:38
*** rburton <rburton!> has quit IRC19:40
*** rburton <rburton!~rburton@> has joined #yocto19:40
*** rburton <rburton!~rburton@> has quit IRC19:49
*** rburton <rburton!> has joined #yocto19:50
xerent_I'll be hosting a yocto workshop for my colleagues on monday :D19:55
*** LCyrin <LCyrin!~LCyrin@2607:fb90:40e:c74c:4121:aae3:538b:4089> has joined #yocto19:58
*** zecke <zecke!> has quit IRC19:58
*** rburton <rburton!> has quit IRC19:59
*** rburton <rburton!> has joined #yocto20:00
*** LCyrin <LCyrin!~LCyrin@2607:fb90:40e:c74c:4121:aae3:538b:4089> has quit IRC20:13
*** LCyrin <LCyrin!~LCyrin@> has joined #yocto20:14
*** armpit <armpit!> has left #yocto20:17
*** armpit <armpit!> has joined #yocto20:20
*** ant__ <ant__!> has joined #yocto20:21
*** sroy <sroy!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has quit IRC20:26
*** LCyrin <LCyrin!~LCyrin@> has quit IRC20:33
*** LCyrin <LCyrin!~LCyrin@> has joined #yocto20:35
*** behanw <behanw!> has quit IRC20:51
*** behanw <behanw!> has joined #yocto20:51
*** behanw <behanw!> has quit IRC20:56
*** behanw <behanw!> has joined #yocto20:56
*** dvhart <dvhart!~dvhart@> has joined #yocto21:00
*** cbzx <cbzx!> has quit IRC21:02
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto21:04
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC21:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:04
*** ant__ <ant__!> has quit IRC21:04
*** Jefro <Jefro!> has quit IRC21:07
*** beaver_545 <beaver_545!> has joined #yocto21:08
*** jluisn <jluisn!~quassel@> has quit IRC21:11
*** ant__ <ant__!> has joined #yocto21:11
maxtothemaxhow do I explicitly build something which is marked as ASSUME_PROVIDED?21:22
*** ddalnx <ddalnx!~quassel@> has quit IRC21:24
*** rcw <rcw!~rwoolley@> has quit IRC21:29
*** geckos <geckos!~geckos@> has quit IRC21:31
*** beaver_545 <beaver_545!> has joined #yocto21:33
*** dvhart_ <dvhart_!~dvhart@> has joined #yocto21:37
*** dvhart <dvhart!~dvhart@> has quit IRC21:38
bluelightningmaxtothemax: you can't, other than by removing it from ASSUME_PROVIDED21:39
*** jzhang <jzhang!jzhang@nat/intel/x-xdejrlbcfmypilke> has quit IRC21:39
maxtothemaxso if someone does a world build, it won't get built even then?21:40
*** rburton <rburton!> has quit IRC21:46
*** rburton <rburton!> has joined #yocto21:46
*** rburton <rburton!> has quit IRC21:56
*** rburton <rburton!> has joined #yocto21:56
*** JimBaxter <JimBaxter!> has quit IRC21:57
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto22:02
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto22:03
*** rburton <rburton!> has quit IRC22:05
*** fenrig <fenrig!5ee22386@gateway/web/freenode/ip.> has quit IRC22:06
*** rburton <rburton!> has joined #yocto22:06
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:20
*** nitink1 <nitink1!~nitink@> has quit IRC22:21
*** oneQubit <oneQubit!~oneQubit@> has quit IRC22:21
*** nitink <nitink!~nitink@> has joined #yocto22:22
*** oneQubit <oneQubit!> has joined #yocto22:29
*** rburton <rburton!> has quit IRC22:40
*** rburton <rburton!> has joined #yocto22:40
*** ant__ <ant__!> has quit IRC22:44
*** ant__ <ant__!> has joined #yocto22:45
*** ant__ <ant__!> has quit IRC22:52
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:55
*** dvhart_ <dvhart_!~dvhart@> has quit IRC23:01
*** rburton <rburton!> has quit IRC23:13
*** rburton <rburton!> has joined #yocto23:14
*** agust <agust!> has quit IRC23:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:15
*** LCyrin <LCyrin!~LCyrin@> has quit IRC23:21
*** jzhang <jzhang!~jzhang@> has joined #yocto23:33
*** seebs <seebs!> has quit IRC23:36
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC23:53
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto23:54
*** seebs <seebs!> has joined #yocto23:59

Generated by 2.11.0 by Marius Gedminas - find it at!